Программная инженерия. Теория и практика

Водопадная модель. Была предложена в 1970 г. Винстоном Ройсом. Фактически впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о создании ПО в виде анализа системы и ее кодирования.

Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование (рис. 2).

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

Рис. 2. Водопадная модель процесса разработки ПО

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

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

• отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности трудности поддержки итеративного процесса разработки;

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

• интеграция всех результатов разработки происходит в конце процесса, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;

• невозможность ознакомления пользователей и заказчика с вариантами системы во время разработки. Тем самым они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;

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

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