Рациональный унифицированный процесс

В настоящее время основной технологией объекто-ориентированного проектирования и разработки ИС является рациональный унифицированный процесс (РУП) — Rational Unified Process (RUP), автором и активным пропагандистом которого является фирма Rational Software. В настоящем пункте описываются основные элементы РУП.

Общие положения

Цель РУП — обеспечить изготовление ПО высокого качества, соответствующего потребностям пользователя, в заданные сроки (или по крайней мере предсказуемые) и в пределах установленной сметы.

Основополагающим понятием в РУП является процесс (process). Процессом называется частично упорядоченное множество шагов, направленных на достижение некоторой цели. В контексте разработки ИС целью является поставка в предсказуемые сроки продукта, удовлетворяющего реальным потребностям заказчика.

В рамках РУП все многообразие деятельности на различных этапах жизненного цикла делится на несколько так называемых рабочих процессов. Каждый рабочий процесс характеризуется одинаковым типом работ и общим составом порождаемых и/или используемых артефактов (артефакт — искусственный объект, т.е. отличающийся от природного; здесь это информационный элемент, создаваемый и/или используемый в процессе проектирования и разработки ИС).

Характеристики РУП

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

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

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

· В рамках РУП существенное внимание придается анализу и разработке первоначальной архитектуры ИС, что облегчает параллельную разработку группой проектировщиков и программистов, минимизирует число серьезных изменений и увеличивает возможности многократного использования компонентов ИС.

· Работы в РУП управляются прецедентами. Прецеденты и сценарии использования системы управляют всем технологическим процессом проектирования и разработки от анализа предметной области до тестирования.

· РУП — объектно-ориентированная технология. Большинство моделей являются объектно-ориентированными и используют UML как обую систему обозначений.

· РУП поддерживает компонентно-ориентированное программирование. Компонент — это специализированный модуль или подсистема, выполняющая конкретную функцию и которая может быть использована в строго установленной архитектуре ИС, подчиняющейся общим стандартам типа COM/DCOM, CORBA и т.п.

· РУП имеет перестраиваемую конфигурацию в том смысле, что в зависимости от конкретных потребностей и масштаба проекта имеются рекомендации по изменению структуры и значимости рабочих процессов.

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

РУП как программный продукт

РУП как продукт представляет собой базу знаний в формате HTML, к которой прилагается пакет документов, описывающих процесс. База знаний позволяет, в частности, получить рекомендации по структурной организации РУП и его составляющих, технологиям работ, правилам создания различных артефактов: моделей, отчетов и т.п.

Структура РУП

РУП представляет процесс разработки ИС в двух измерениях:

· по основным потокам работ (рабочих процессов);

· по времени (по стадиям жизненного цикла ИС).

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

Описание процесса также выполняется с двух точек зрения:

· техническая точка зрения фокусирует внимание на артефактах и моделях ИС;

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

Статический аспект РУП

Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

1) моделирование бизнес-процессов (деловых процессов) — описание структуры и динамика процессов в организации-пользователя разрабатываемой ИС;

2) спецификация требований — четкое определение функциональных требований на основе прецедентов;

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

4) реализация — собственно разработка программ (модулей), автономное тестирование и интеграция;

5) тестирование — определение сценариев тестов, процедур и метрик для измерения числа ошибок, собственно тестирование системы;

6) развертывание — конфигурирование поставляемой системы в организации-пользователе;

7) управление конфигурацией — управление изменениями и поддержание целостности артефактов проекта;

8) управление проектом;

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

Первые шесть рабочих процессов — это потоки собственно разработки, последние три — потоки работ поддержки.

Рабочие процессы описываются в терминах исполнителей (работников), действий и артефактов.

· Работник — это роль, определяющая поведение и ответственность индивидуума или нескольких индивидуумов, работающих совместно как группа.

· Действие — технологическая операция, т.е. атомарная часть какой-то сложной работы. Нельзя выполнить только часть действия.

· Артефакт — искусственный объект (объект модели, документ, программы), который создается в результате выполнения действия, изменяется или используется как исходная информация.

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

Через «связанный» набор действий работника неявно также определяются и навыки, требуемые от конкретного человека для выполнения работ.

Для каждого рабочего процесса составляется диаграмма краткого обзора действий. На этой диаграмме показываются все основные действия и работники, включенные в поток работ.

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

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

Модели и виды архитектуры

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

· модель бизнес-процессов — формализует абстракцию организации;

· модель предметной области — формализует предметную область, в рамках которой работает система;

· модель прецедентов — формализует функциональные требования к ИС;

· аналитическая модель (необязательная) — формализует идею проекта;

· проектная модель — формализует словарь предметной области и области решения;

· модель процессов (необязательная) — формализует механизмы параллелизма и синхронизации в системе;

· модель развертывания — формализует топологию аппаратных средств, на которых выполняется система;

· модель реализации — описывает части, из которых собирается физическая система;

· модель тестирования — формализует способы проверки и приемки системы.

Вид — это одна из проекций модели. В РУП существует пять тесно связанных друг с другом видов системной архитектуры: с точки зрения проектирования, процессов, развертывания, реализации и прецедентов. Это так называемое представление «4+1»: вид через прецеденты связывает воедино остальные четыре вида.

Описание видов:

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

· с точки зрения процессов — содержит описание процессов и их нитей (thread), их взаимодействия и распределения объектов и классов по решаемым задачам; такое представление важно только в том случае, когда система имеет существенный параллелизм; этот вид ориентирован на системных интеграторов;

· с точки зрения развертывания — содержит описание различных физических узлов для наиболее типичных конфигураций платформы, и распределение компонентов, решающих одну задачу, по физическим узлам; данное представление важно для распределенных систем; этот вид ориентирован на системных проектировщиков;

· с точки зрения реализации — содержит модель реализации в терминах модулей пакетов и уровней и описание распределения пакетов и классов в пакетах и компонентах; этот вид ориентирован на программистов;

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

Динамический аспект РУП

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

РУП состоит из следующих четырех фаз.

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

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

3) Построение (construction) — постепенное создание ИС. В фазе построения постепенно и итеративно разрабатывается продукт, готовый к внедрению. На этом этапе описываются оставшиеся требования и критерии приемки, реализуются различные проектные решения, завершается разработка и тестирование программного комплекса. В конце фазы построения принимается решение о готовности программ, эксплуатационных площадок и пользователей к внедрению.

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

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

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

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

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