4.1 Водопад – классическая модель разработки

Рисунок 3

Модель водопада — модель процесса разработки ПО, в которой этапы разработки проходят в строгой последовательности, процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Автором модели является У. У. Ройс, опубликовавший модель в 1970 году.

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

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

4.2 Итеративная модель разработки

Рисунок 4

Итеративный подход заключается в выполнении работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Итеративный подход акцентирует работу команды в более предсказуемом и повторяемом направлении. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка.

Итеративный подход имеет целый ряд преимуществ, перед моделью водопада, среди них:

• Снижение риска не учесть какое-либо требование, всегда можно добавить требование на следующей итерации;

• Более равномерная загрузка участников проекта;

• Возможность работать только над самыми приоритетными направлениями;

• Использование накопленного опыта на последующих итерациях;

• Возможность использовать обратную связь с клиентами и вводить обновления реально отвечающие текущим желаниям потребителей;

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

Пример реализации итеративного подхода — методология Rational Unified Process.

4.3 Методология rup

Rational Unified Process (RUP) — итеративная методология разработки программного обеспечения, созданная компанией Rational Software.

Рисунок 5¹

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

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

В основе RUP лежат следующие принципы:

• Итеративная разработка

• Контроль за изменениями

• Управление требованиями (требования должны определяться пользователями)

• Использование компонентов (сложный проект должен быть разделен на простые части)

• Визуальное моделирование (использование визуальных схем и диаграмм упрощает постановку задачи)

• Контроль качества (постоянное тестирование основных частей проекта)

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