Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на предыдущих стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает иной вид (рис.
3).
Рисунок 3. Итерационный процесс создания программного обеспечения
Изображенную схему можно отнести к отдельной модели — модели с промежуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя увеличивают весь период разработки.
Основным недостатком каскадной модели, в том числе итерационной, является существенное запаздывание с получением результатов и, как следствие, высокий риск создания системы, не удовлетворяющей и изменившимся потребностям пользователей. Это объяснятся двумя причинами:
— пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;
— за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.
В рамках каскадного подхода требования к ЭИС фиксируются в виде технического задания на все время ее создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. Пользователи могут получить систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.
Заключение
На основе изложенного можно сделать вывод, что принципиальной особенностью каскадного подхода является: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии.
Каждая стадия завершается выпуском комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.
Таким образом, у каскадной модели есть один существенный недостаток — очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему и поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений. Результатом такого конфликта стало появление модели с промежуточным контролем, которую представляют или как самостоятельную модель, или как вариант каскадной модели. Эта модель характеризуется межэтапными корректировками, удлиняющими период разработки изделия, но повышающими надежность.
Список литературы
Бэгьюли Ф. Управление проектом: пер. с англ. — М.: Гранд, 2004.
Грей К. Ф., Ларсон Э. У. Управление проектами: практ. руководство: пер. с англ. М., 2003.
Кэмпбелл К. А. Управление проектом на одной страницеКларк А. — М.: Вильямс, 2008.
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности. — М.: Омега-Л, 2008.
Мазур И. И. Управление проектами / И. И. Мазур, В.
Д. Шапиро, Н. Г. Ольдерогге. — М.: Омега-Л., 2008.
Ципес Г. Л. Проекты и управление проектами в современной компании: Учебное пособие. — М.: Олимп-Бизнес, 2009.
Приложение
Планирование
Формирование требований
Конструирование
Анализ и проектирование
Поддержка и эксплуатация
Интеграция и тестирование
План
Спецификация
Дизайн
Код
Продукт
