Различные подходы к составу и наименованию стадий

ГОСТ 34	Барри У. Боэм[7]	Oracle CDM	Rational Unified Process
Формирование требований к АС. Разработка концепции АС. Техническое задание	Анализ осуществимости системы. Планирование и анализ требований к ПО	Стратегия. Анализ	Начальная стадия (Inception)
Эскизный проект. Технический проект	Проектирование изделия. Детальное проектирование	Проектирование	Разработка (Elaboration)
Рабочая документация	Кодирование	Реализация	Конструирование (Construction)
Ввод в действие. Сопровождение АС	Внедрение. Функционирование (эксплуатация) и сопровождение	Внедрение. Эксплуатация и сопровождение	Ввод в действие (Transition)

Как видно из табл. 1.1, наименования стадий в различных подходах во многом схожи и не отражают их внутреннее содержание, которое полностью определяется используемой моделью ЖЦ ПО.

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью ЖЦ ПО.

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

Крайним случаем модели ЖЦ можно считать так называемую модель «черного ящика» (black box), или «code and fix» (кодирование и исправление), что фактически означает отсутствие какой-либо модели (рис. 1.3). В этом случае выделить какие-либо рациональные стадии в процессе разработки ПО не представляется возможным, поскольку отсутствует планирование и организации работ.

Программистский фольклор, тем не менее, выделяет в такой модели следующие стадии:

· начало проекта;

· безудержный энтузиазм;

· разочарование;

· хаос;

· поиски виновных;

· наказание невиновных;

· награждение непричастных;

· определение требований к системе.

Рис. 1.3. Модель «черного ящика»

1.3.1

КАСКАДНАЯ МОДЕЛЬ ЖЦ

В 1970 г. эксперт в области ПО Уинстон Ройс опубликовал получившую широкую известность статью, в которой он излагал свое мнение о методике, которая позднее получила название «модель водопада» (waterfall model), или «каскадная модель» (рис. 1.4). Эта модель была разработана с учетом ограничений «тяжелых» процессов, налагавшихся на разработчиков государственными контрактами того времени. Многие ошибочно полагают, что в своей статье Ройс выступил в защиту однопроходной последовательной схемы. На самом же деле он рекомендовал подход, несколько отличный от того, который в конечном итоге вылился в концепцию «водопада» с ее строгой последовательностью стадий анализа требований, проектирования и разработки. Впоследствии эта модель была регламентирована множеством нормативных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34. Принципиальными свойствами так называемой «чистой» каскадной модели являются следующие:

· фиксация требований к системе до ее сдачи заказчику;

· переход на очередную стадию проекта только после того, как будет полностью завершена работа на текущей стадии, без возвратов на пройденные стадии.

Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Преимущества применения каскадной модели заключаются в следующем:

· на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

· выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

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

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

Рис. 1.4. Каскадная модель жизненного цикла ПО

Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает вид, изображенный на рис. 1.5.

Основными недостатками каскадного подхода являются:

· позднее обнаружение проблем;

· выход из календарного графика, запаздывание с получением результатов;

· избыточное количество документации;

· невозможность разбить систему на части (весь продукт разрабатывается за один раз);

· высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.

Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: 1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; 2) за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

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

Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.

В чем же заключается первоисточник проблем, связанных с каскадным подходом? Он, как уже отмечалось во введении, в заблуждении, что разработка ПО имеет много общего со строительными или инженерными проектами, например со строительством мостов. В строительных проектах задачи выполняются строго последовательно.

Рис. 1.5. Реальный процесс разработки ПО

Например, нельзя заложить опору моста до тех пор, пока не будут вырыты ямы для них. Настил моста не может начаться до тех пор, пока не будет завершено строительство опор. В ранних подходах к процессу разработки ПО использовались те же принципы:

1. Группа аналитиков собирала и документировала требования.

2. Когда требования были утверждены, начиналось проектирование.

3. После утверждения проекта начиналось написание кода.

4. Каждая строка кода подлежала проверке. Если ее утверждали, то ее разрешалось интегрировать в продукт.

В этом заключается «чистый» каскадный подход. В свое время его расхваливали как процесс, позволяющий сделать разработку ПО более рентабельной. Считалось, что если написание кода начинать до утверждения проекта, то некоторые работы по созданию кода будут выполнены напрасно. На практике оказалось, что «строительный» подход привел к наиболее ярким примерам неудач при разработке ПО.

Первая проблема такого подхода заключается в том, что задачи по разработке ПО не так легко спланировать и определить, как задачи строительного проекта. При строительстве моста очень легко определить, когда, к примеру, этап настила выполнен наполовину. При написании кода гораздо труднее узнать, когда же он готов хотя бы наполовину. При строительстве моста очень легко оценить, какое время займет настил одного пролета, а при написании кода никто не знает, насколько большим будет конечный код и сколько времени займет написание и отладка определенной части кода.

Вторая проблема вызвана тем, что при каскадном подходе все действия по разработке системы являются последовательными: завершение одной задачи происходит до начала новой. Завершение одной задачи означает, что полученный результат — безукоризненный и что персонал, выполнявший эту задачу, может перейти к следующему проекту (как строителей после завершения одного объекта «перебрасывают» на другой). Несмотря на то что при строительстве какого-либо объекта (например, моста) можно сказать, что определенный этап работ был завершен, нельзя быть уверенным в том, что при этом были соблюдены все требования. Опыт показывает — практически всегда можно быть уверенным в том, что какие-то требования не соблюдались. Аналогичным образом при выполнении программного проекта всегда будут обнаруживаться какие-то недостатки в документации.

Попытки преобразовать действия по разработке ПО в последовательную форму всегда приводят к одному из двух возможных результатов: ранняя неудача или поздняя неудача. Успешные результаты бывают очень редко. Раннюю неудачу терпят наиболее «строго выполняемые» проекты. В таких случаях один из наиболее ранних промежуточных этапов, а именно составление спецификации требований или спецификаций проекта, никогда не будет выполнен. При каждом пересмотре документов возникают новые проблемы и сомнения, обнаруживаются недостатки и задаются вопросы, на которые нельзя дать ответы.

Наиболее распространенным результатом каскадного подхода к разработке ПО является поздняя неудача. Кажется, что проекты выполняются нормально, но только до тех пор, пока работы не вступят в завершающий этап, и тогда выясняется, что потребители недовольны созданным продуктом.

1.3.2.