В итеративном и инкрементальном жизненном цикле (см. рис. 1.3) разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса: построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение. Разработчики допускают, что не все требования к системе известны в начале жизненного цикла. Корректировки возможны на любом этапе.
Такой тип жизненного цикла позволяет уменьшить риск. Технические риски оцениваются и группируются по приоритетам на ранней стадии цикла и корректируются во время разработки каждой версии. Риски закреплены за каждой версией таким образом, что успешное завершение версии уменьшает риск, закрепленный за ней. Процесс планируется так, чтобы наибольшие риски были рассмотрены в первую очередь. Построение системы подобным образом выявляет и уменьшает риски на раннем этапе жизненного цикла. Результат такой модели жизненного цикла — уменьшение риска и затрат[4]
.Для поддержки управления итеративным и инкрементальным жизненным циклом разработки используется методика Rational Unified Process, с помощью которой можно подробно описать технические и организационные аспекты создания программного обеспечения на стадиях определения требований к системе, анализа и проектирования.
Методология Rational Unified Process структурирована в двух направлениях:
время (разделение жизненного цикла на фазы и версии);
компоненты процесса (создание необходимого набора средств для выполнения четко определенных задач).
Оба направления должны быть хорошо проработаны для получения успешного проекта.
Работа над проектом состоит из следующих временных этапов:
В разрезе компонентов процесс делится на следующие стадии:
Каждая стадия в разрезе компонентов процесса обычно применяется к конкретной фазе временного направления (см. рис. 1.4.). Однако степень применения каждого компонента зависит от этапа разработки. Например, вы можете испытать концептуальный прототип системы на стадии задумки, и тогда вам потребуется не только определение требований — необходимо будет провести анализ, проектирование, реализацию и тестирование, чтобы завершить создание прототипа. Важность анализа выявляется на этапе проработки.
Сначала предпочтительно выпустить несколько версий. Они обычно используются для проверки аналитических решений в области архитектуры системы. Таким образом, вы не только анализируете проблему. На стадии создания система строится с помощью серии версий. При любой структуре разработки дополнительные вопросы всегда возникают неожиданно, что требует проведения нового анализа.
Диаграмма должна быть основным руководством для отражения жизненного цикла вашего проекта. Основная мысль заключается в следующем: если вы только думаете над тем, что собираетесь создавать, в то время когда уже пишете код, вероятно, у вас возникнут проблемы. Заметьте, что тестирование применяется в ходе всего итерационного процесса. То есть вы не ждете, когда весь код будет написан для проверки его работы.
В этой книге применяется упрощенная версия Rational Unified Process, в которой сделан акцент на использовании языка UML для получения и документального описания решений на стадиях задумки и проработки проекта. В последних главах кратко рассказывается об этапе создания. Несмотря на то что тестирование — неотъемлемая часть процесса разработки, его описание выходит за рамки данной книги.