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

В этой модели были выделены различные шаги разработки

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

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

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

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

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

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

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

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

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

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

Еще одно понятие программной инженерии – рабочий продукт – (work product) – любой артефакт, произведенный в процессе разработки ПО, например, файл или набор файлов, документы, сервисы, процессы, спецификации, счета и т.д. Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что первый необязательно материален и осязаем (not to be engineered), хотя может быть таковым. Нематериальный рабочий продукт – это, как правило, некоторый налаженный процесс – промышленный процесс производства какой-либо продукции, учебный процесс в университете (на факультете, на кафедре) и т.д.

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

Остановимся чуть детальнее на промежуточных рабочих продуктах. Компонента ПО, созданная в проекте одним разработчиком и предоставленная для использования другому разработчику, оказывается рабочим продуктом. Ее надо минимально протестировать, поправить имена интерфейсных классов и методов, быть может, убрать лишнее, не имеющее отношение к функциональности данной компоненты, разделить public и private, и т.д. То есть проделать некоторую дополнительную работу, которую, быть может, разработчик и не стал бы делать, если бы продолжал использовать компоненту только сам. Объем этих дополнительных работ существенно возрастает, если компонента должна быть представлена для использования в разработке, например, в другой центр разработки (например, иностранным партнерам, что является частой ситуацией в оффшорной разработке). Итак, изготовление хороших промежуточных рабочих продуктов очень важно для успешности проекта, но требует дополнительной работы от их авторов. Работать одному, не предоставляя рабочих продуктов – легче и для многих предпочтительнее. Но работа в команде требует накладных издержек, в том числе и в виде трат на создание промежуточных рабочих продуктов.

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