Главная » UML » Увеличение масштаба временной шкалы

0

Если то, что хорошо работало в трехмесячном проекте, переносится на трехлетний проект, то на этот проект будут влиять не только рассмотренные выше переменные обстоятельства, но и другие малозаметные эффекты, связанные с человеческим фактором. Разработчики программного обеспечения, которые знают, что через два-три месяца они увидят вещественные результаты своей работы, могут четко представлять действительный результат. В этом случае обратная связь по качеству осуществляется очень быстро. При выявлении в процессе работы незначительных ошибок разработчикам не приходится возвращаться слишком далеко для исправления этих огрехов.

Рассмотрим теперь место разработчиков в следующей ситуации: процесс, рассчитанный на трехлетний цикл разработки, находится в середине фазы проектирования. Задача— завершить проект в течение четырех месяцев. Чтобы убедиться, что конечный продукт последовательного процесса готов и работает, присутствие разработчиков вообще не нужно. Прогресс измеряется страницами или диаграммами, а не операционными свойствами. Не существует ничего волнующего, ничего материального.

Поскольку дефекты будут обнаружены значительно позднее, во время тестов или итераций (которые, возможно, будут выполнены года через полтора), то и возможность обратной связи по качеству текущего действия крайне мала. Разработчики имеют очень мало благоприятных возможностей для улучшения собственной работы. Более того, если в тексте требований обнаруживаются непонятные моменты, то это означает, что разработчикам приходится восстанавливать в памяти обсуждения и решения, принятые месяцы назад. Неудивительно, что мотивировать эти решения сейчас будет трудновато. А если исходные исполнители уже давно не работают Над проектом, а контракт с заказчиком нельзя ни изменить, ни разорвать?

Разработчики имеют только по одной попытке для произведения каждого вида деятельности, а возможности поучиться на собственных ошибках практически нет. Проект нужно создать с первой попытки, и лучше, чтобы эта попытка была удачной. Вы никогда не проектировали подобных систем? Очень плохо! Запрограммировать результат нужно с первой попытки, и лучше бы, чтобы эта попытка была удачной. Язык программирования для вас нов? Работайте дольше и изучайте его свойства. Протестировать полученную систему нужно за один раз, и желательно, чтобы в этот раз не было сбоев. Новая система и никто не знает, как в действительности она должна работать? Что ж, это поймете вы. Если в проекте представляются новые технологии или инструментальные средства либо задействованы новые люди, то последовательный процесс не даст вам свободы изучения и реализации.

Помещение документации на полки

Целью каждого этапа последовательного процесса, за исключением последнего, является производство и завершение промежуточного артефакта (как правило, печатного документа), который рецензируется, утверждается, фиксируется, а после этого используется как отправная точка следующего этапа. На практике последовательные процессы акцентируют внимание на производстве и фиксации документации. Допускается некоторая ограниченная обратная связь с предыдущим этапом, но изменение результатов ранних этапов (вследствие обратной связи) считается разрушительным. Это относится к нежеланию изменять требования и терять видение конечного продукта, которое, как правило, стараются фиксировать, особенно в продолжительных проектах.

Объемное планирование против временного

Довольно часто важнейшим фактором успеха проекта разработки программного обеспечения является своевременность. Во многих отраслях промышленности своевременная сдача продукта с последующим внесением небольших изменений (ввод новых функций) значительно важнее сдачи завершенной, полнофункциональной, совершенной системы. Чтобы добиться своевременности, содержание системы нужно согласовывать динамически, удаляя или откладывая некоторые функции, что позволяет высвободить дополнительное время. При линейном подходе нельзя получить существенного изменения графика работ, если в середине фазы реализации решить удалить функцию X. Причина в том, что некоторое время и работа уже были потрачены на определение, проектирование и кодирование этой функции. Именно поэтому линейная модель и не подходит для использования в работе компаний, предпочитающих временной график работ (например, за три месяца требуется сделать три первых пункта списка, после чего отводится два месяца не следующие два и т.д.), а не объемный (когда на весь объем работ выделяется, например, девять месяцев).

Исходя из этих и еще нескольких причин, которые будут описаны позднее, организации-разработчики программного обеспечения испробовали другой подход.

 

По теме:

  • Комментарии