Сравнительный анализ методологий

Комплексный проект может включать в себя этапы работ с поставками в совершенно разных индустриях. Зачастую успешность комплексного проекта зависит от того, насколько правильно руководитель проекта выбрал подходящую методологию и смог ее внедрить для достижения требуемых результатов на конкретно взятом этапе.-Воропаев В. И. Управление проектами в России. — М.: Аланс, 2005.

• -Либерзон В. И. Основы управления проектами
• -Манн И. М. Как овладеть искусством управления проектами. — М., Управление компанией, 2010
• -Арчибальд Рассел Д. Управление высокотехнологичными программами и проектами. М.: АЙТИ системный интегратор, Изд-во ДМК, 2002

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

В настоящее время в управлении проектами эта методология является классической. Waterfall — один из самых первых и устоявшихся подходов.

Она содержит набор стандартных фаз, которые подразумевают чёткую последовательность:

Сбор требований (Requirements).

Планирование (Design).

Разработка/Внедрение (Implementation).

Тестирование (Verification/Test).

Поддержка (Maintenance).

Основной принцип — последующая фаза не может начаться, если не окончена предыдущая.

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

Разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.

Анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т. п.

Реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.

Тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.

Развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.

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

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

Насколько эффективным оказался такой подход? Он хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения. Благодаря этому она часто используется в больших организациях (таких как Министерство обороны США и NASA) при строгих требованиях к надежности создаваемого ПО.

Недостатки:

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

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

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

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

Модель водопада является правильным выбором для типовых, шаблонных проектов или при наличии жестких требований к качеству (например, при создании критических систем). Но всё же недостатки данной модели очень существенны, и для разработки коммерческого программного обеспечения существуют более эффективные методологии.-Аскар Рахимбердиев. Современные процессы разработки программного обеспечения. RSDN Magazine #4−2006.