Классические модели процессов создания ПО

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

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

Каскадная модель

Первая разработанная модель процесса создания программного обеспечения была аналогом моделей других инженерных процессов. Это наиболее известная модель жизненного цикла программного обеспечения — каскадная, или модель «водопада» (waterfall model), которую часто называют эквивалентом модели процесса в строительной промышленности (рис. 2.3).

Рис. 2.3. Каскадная модель разработки программного обеспечения.

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

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

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

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

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

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

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