Rational Rose 2000 и UML. Визуальное моделирование

Успешно разработанный проект удовлетворяет или превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и может быть адаптирован к изменению условий. Жизненный цикл разработки должен способствовать творческим и новаторским идеям. В то же время для своевременного завершения процесс разработки должен контролироваться. «Творчество естественно для создания всех хорошо структурированных объектно-ориентированных архитектур, но если разработчиков не контролировать, то они, возможно, никогда не достигнут конечного результата. Значит, для эффективной работы коллектива нужна дисциплина. Но слишком жесткая дисциплина приводит к развитию бюрократии, которая, в свою очередь, душит новаторские идеи»[3]. Правильно управляемый итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль и поддерживает творческий процесс на нужном уровне.

Что такое итеративная и инкрементальная разработка

В итеративном и инкрементальном жизненном цикле (см. рис. 1.3) разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса: построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение. Разработчики допускают, что не все требования к системе известны в начале жизненного цикла. Корректировки возможны на любом этапе.

Рис. 1.3. Итеративная и инкрементальная разработка

Такой тип жизненного цикла позволяет уменьшить риск. Технические риски оцениваются и группируются по приоритетам на ранней стадии цикла и корректируются во время разработки каждой версии. Риски закреплены за каждой версией таким образом, что успешное завершение версии уменьшает риск, закрепленный за ней. Процесс планируется так, чтобы наибольшие риски были рассмотрены в первую очередь. Построение системы подобным образом выявляет и уменьшает риски на раннем этапе жизненного цикла. Результат такой модели жизненного цикла — уменьшение риска и затрат[4].

Методология Rational Unified Process

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

Методология Rational Unified Process структурирована в двух направлениях:

  время (разделение жизненного цикла на фазы и версии);

  компоненты процесса (создание необходимого набора средств для выполнения четко определенных задач).

Оба направления должны быть хорошо проработаны для получения успешного проекта.

Работа над проектом состоит из следующих временных этапов:

  задумка (inception) — определение общей идеи проекта;

  проработка (elaboration) — планирование необходимых работ и ресурсов, указание особенностей и создание архитектуры;

  создание (construction) — построение продукта при помощи серии последовательных версий;

  переходный период (transition) — поставка продукта пользователям (производство, распространение, обучение).

В разрезе компонентов процесс делится на следующие стадии:

  построение бизнес-модели (business modeling) — определение необходимых возможностей системы и потребностей пользователей;

  определение требований к системе (requirements) — изложение общей идеи системы совместно с функциональными и нефункциональными условиями ее работы;

  анализ (analysis) и проектирование (design) — описание способов исполнения системы на этапе реализации;

  реализация (implementation) — кодирование и генерация работающих программных модулей системы;

  тестирование (test) — проверка функционирования системы;

  внедрение (deployment) — поставка системы конечным пользователям и их обучение.

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

Рис. 1.4. Стадии разработки

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