1. Водопадная модель

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

Первой фазой является концептуализация, т.е., поиск и разработка концепции данного программного продукта. Затем следует распределение системных ресурсов; т.е., отображение (привязка) предполагаемой реализации этой концепции к системным ресурсам, необходимым будущему программному продукту для его функционирования.

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

Поддержка – Support

Рис. 7. Водопадная модель

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

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

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

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

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

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

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

1. Модель способствует определению требований до проектирования системы – надо определить, что система должна делать ДО ее создания;

2. Модель способствует проектированию программного обеспечения ДО построения его компонентов – надо спланировать, как именно компоненты будут взаимодействовать между собой и по каким интерфейсам ДО их создания;

3. Модель определяет, какие именно рабочие продукты должен поставить данный процесс разработки – надо сгенерировать стандартный набор поставок, которые должны быть тестируемы и смогут помочь в дальнейшем сопровождении данного программного продукта;

4. Модель дает возможность руководству проектом тщательно отслеживать его продвижение – руководство должно располагать базовыми стандартами для измерения качества продукта и производительности, как самого процесса разработки, так и разработчиков;

5. Модель снижает затраты на разработку и сопровождение – все предыдущее этому способствует;

6. Модель дает возможность организации-разработчику быть более структурированной и управляемой.

Благодаря следованию какой-либо известной модели ЖЦ, организация-разработчик получает следующие преимущества:

1. Улучшается качество продукта через согласованность в его разработке – продукт определяется как состоящий из всех поставляемых рабочих продуктов его жизненного цикла;

2. Облегчается управление проектами – сравнение с известными стандартами выявляет проблемы, требующие решения;

3. Облегчается отслеживание состояния проекта – определение деятельностей и заданий в процессе является средством знать, что именно было сделано, за какое время и какими ресурсами;

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

5. По мере исправления организационных слабостей растет уровень зрелости организации-разработчика – когда недостатки процесса исправляются, организация переходит на более высокий уровень зрелости, как это определяется моделями зрелости CMM/CMMI.

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

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

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

4. Пошаговая модель

Пошаговая (Incremental) модель (Рис. 10) напоминает V-образную, но построена на идее так называемого эволюционного прототипа (evolutionary prototype) и состоит из последовательности шагов от 1 до N. На шаге 1 готовится некоторый зародыш будущего продукта, в котором реализуется очень ограниченное количество функций. В последующих шагах от 2 до N этот прототип наращивается до полного объема спецификаций, какой был задан изначально.

Каждый шаг исполняется по V-образной модели, но с учетом уже имеющихся наработок на предыдущем шаге. В отличие от обобщенной модели, здесь на первой же фазе каждого шага идет разработка "тестов приемки", которые либо разрабатываются, либо берутся уже готовыми от заказчика. Таким образом, в отличие от V-образной модели, в которой приемочное тестирование выполняется на завершении разработки, здесь вопрос: "На чем будут тестироваться последовательные версии продукта и что будет критерием их приемки заказчиком?" изучается и решается первым делом. Изначально эти тесты применяются к продуктам поставщиков и возможных конкурентов, а в конце каждого шага – к очередной версии разрабатываемого продукта, который в этой модели называется демонстрационным прототипом (demo).

После определения и подготовки тестов идет «спуск» по фазам анализа требований, предварительного проектирования (аналог высокоуровневого), детального проектирования и кодирования, а затем «подъем» по фазам модульного тестирования, интеграционного тестирования, и системного, как и в V-образной модели. Завершается шаг приемо-сдаточными испытаниями с учетом тестов, накопленных на предыдущих шагах, и тестов для функциональности, добавленной на данном шаге.

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

Рис. 10. Пошаговая модель

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

5. Спиральная модель Боэма

Спиральная (spiral) модель была предложена Боэмом еще в середине 1980-х годов. Ее главная особенность – выделение анализа рисков в отдельные шаги разработки, которая представляет собой повторяющиеся циклы, раскручиваемые, подобно спирали (Рис. 11). Каждый виток начинается с анализа рисков и построения очередного прототипа системы, эти риски проясняющего. После устранения с помощью рассмотрения этих прототипов всех неясностей, выявленных в анализе рисков, разрабатывается концепция, составляются планы по требованиям к системе и планы по жизненному циклу. На следующем витке спирали в свете полученных новых данных заново проводится анализ рисков в изменившейся ситуации и на основании него, если заказчик соглашается, создается следующий прототип.

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

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

Рис. 11. Спиральная модель Боэма

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