Корпоративные методологии. 
Управление жизненным циклом информационных систем

IBM (Rational Unified Process, RUP)

Unified Process — методология разработки ИС/ПО, название которой переводится на русский язык как «унифицированный процесс». Унифицированный процесс разработки программного обеспечения был предложен создателями UML.

Действительно, UML предоставил разработчикам ИС и ПО унифицированный язык визуального моделирования. Но одного только UML было недостаточно. Для полного раскрытия потенциала объектно-ориентированного подхода был разработан UP — процесс производства программного обеспечения. При этом следует понимать, что если UML был стандартизирован OMG, то стандартизация UP не проводилась, даже несмотря на наличие коммерческих методологий и проработанных подходов.

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

История UP. Основой унифицированного процесса стал SEP (Software Engineering Process), который изначально использовался для определения,.

что, когда, как и кто должен делать при разработке программного обеспечения. В 1967 г. компания Ericsson начала работу по развитию SEP. Изначально подход рассматривал информационные системы в виде взаимосвязанных блоков, причем меньшие блоки образовывали связи друг с другом и «сплетались» в блоки большего размера, из которых в конечном счете и состояла И С.

Исходной посылкой подхода стал принцип «разделяй и властвуй». Действительно, масштабная информационная система чересчур сложна для понимания, поэтому требуется упростить задачу разработки. Одно из оптимальных решений — разбиение системы на блоки, каждый из которых имеет какие-либо интерфейсы и собственное внутреннее устройство, а также связь с другими блоками. Данная логика содержится и в современных версиях UP, с той лишь разницей, что большие блоки носят название подсистем, а маленькие именуются компонентами.

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

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

1980 г. ознаменовал собой новую веху в развитии объектно-ориентированного анализа и проектирования. Язык спецификации и описания (Specification and Description Language, SDL) стал одним из первых языков визуального моделирования, а спустя десять лет возникла его расширенная версия. В итоге SDL-92 стал первым стандартом объектного моделирования. Он до сих пор применяется в сфере телекоммуникационных И С.

Следующим важным этапом стал 1987 г., когда Л. Джекобсон основал компанию Objectory АВ. Взяв за основу метод компании Ericsson, А. Джекобсон сумел разработать процесс производства программного обеспечения. Новый процесс получил название «Object Factory» и буквально с первых же месяцев своего существования был хорошо встречен коммерческими организациями. Будучи коммерческим продуктом, процесс содержал всю необходимую документацию, программное средство и возможность получения консультаций от специалистов компании-разработчика.

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

В 1995 г. ситуация стала меняться. Компания Rational купила компанию А. Джекобсона и приняла решение объединить Object Factory со своими разработками. Первым значимым результатом стало создание Филиппом Крухтеном «4+1 представлений» архитектуры, которые по сей день являются фундаментом UP (хоть и неявным). Далее была выделена последовательность из 4 фаз разработки ИС и ПО: Начало, Уточнение, Построение, Внедрение. Начались активные попытки объединить преимущества водопадного и инкрементного ЖЦПО.

Со временем был сформирован новый подход, получивший название ROP (Rational Objecto? y Process). В новом подходе использовалось понятие рисков, была детализована архитектура И С, а также были детально проработаны отдельные области, в которых Object Factory был слаб. При этом UML стал языком, при помощи которого предоставлялись как отдельные модели ROP, так и весь подход в целом.

В 1998 г. возник Унифицированный процесс компании Rational (Rational Unified Process, RUP). С тех пор регулярно возникали новые версии RUP, каждая из которых учитывала ошибки и недостатки предыдущих версий.

Отдельно стоит отметить выход в 1999 г. книги Л. Джекобсона «Unified Software Development Process», в которой подробно описывался Унифицированный процесс (UP, но не RUP!). В конечном счете UP стал открытым процессом создания программного обеспечения, a RUP — коммерческой версией процесса от компании Rational.

UP и RUP. Можно сказать, что RUP — это коммерческая версия открытого подхода UP. Сегодня RUP предоставляется и поддерживается компанией IBM, которая поглотила Rational в 2003 г. RUP от IBM включает множество стандартов и инструментальных средств, которые охватывают все рабочие потоки и все фазы RUP. Таким образом, использование RUP предполагает финансовые затраты, однако существенно экономит время компании на поиск бесплатных инструментов для поддержки бесплатного UP. Кроме того, RUP характеризуется хорошим веб-окружением и наличием качественной службы поддержки от IBM.

Говорить об отличиях RUP от UP достаточно трудно, поскольку оба подхода имеют гораздо больше общего, чем отличий. Если в 1999 г. RUP был фактически коммерческой версией реализации UP, то к сегодняшнему моменту он претерпел некоторые изменения. Но во многом, как было сказано ранее, отличия сводятся к открытости или коммерческой направленности конкретного варианта Унифицированного процесса.

Оба подхода моделируют кем, когда и что выполняется в рамках создания программного обеспечения. Главные различия сводятся к изображению элементов процесса и их названиям (рис. 7.17). Для ответа на вопрос «Кто?» UP использует понятие Исполнителя (Worker), тогда как RUP оперирует категориями Ролей (Role). Также существуют отличия в названиях общих видов деятельности. В UP они называются Рабочие потоки, а в RUP — Дициплины.

Основы UP. Унифицированный процесс основан на трех аксиомах, определяющих его логику, структуру и применение. Согласно этим аксиомам, UP:

• • управляется требованиями и рисками;
• • является архитектурно-центричным;
• • является итеративным и инкрементным.

Рис. 7.17. Сравнение UP и RUP¹

Управление требованиями и рисками — часть фундамента UP. Управление требованиями рассматривается как основа основ, которая позволяет получить по завершению процесса качественную с точки зрения заказчика информационную систему. Не меньшее значение имеет и управление рисками, поскольку едва ли существуют проекты, реализация которых не была бы сопряжена с какими-либо неприятными неожиданностями, обычно приводящими к крупным финансовым затратам или временным издержкам.

Фокус на архитектуре в рамках обсуждения UP означает, что применение унифицированного процесса нацелено на создание и развитие надежной архитектуры И С. Архитектура в данном контексте включает в себя подсистемы, компоненты этих подсистем и их взаимодействие друг с другом, в результате чего обеспечивается итоговая функциональность ИС. Также констатируется, что продуманная архитектура — залог качественной ИС.^[1]

Рабочие потоки. Рабочие потоки — это основные виды деятельности в UP, которые определяют, что конкретно должно быть сделано и какие навыки или знания необходимо для этого применить. При этом рабочие потоки делятся на два типа — основные и вспомогательные. Основные рабочие потоки таковы:

• • Бизнес-моделирование — производится моделирование деятельности предприятия, формирование предметной области, общий анализ и т. п.;
• • Требования — собираются данные о том, что именно должна делать система, какой функциональностью она должна обладать;
• • Анализ и проектирование — требования уточняются, структурируются, а затем реализуются в системной архитектуре;
• • Реализация — происходит создание программной части;
• • Тестирование — созданная программная часть проверяется на ошибки и на соответствие функциональным и нефункциональным требованиям;
• • Развертывание — система развертывается на рабочих местах конечных пользователей или тестовой группы.

К вспомогательным рабочим потокам относятся:

• • Управление конфигурацией и изменениями — деятельность, нацеленная на управление версиями системы, внесение изменений, документирование запросов на изменения и т. п.;
• • Управление проектом — общая деятельность проектного управления;
• • Среда — деятельность, связанная с обеспечением рабочей среды для команды разработчиков в целом и управляющих проектом в частности.

В каждой итерации могут присутствовать все рабочие потоки, перечисленные выше. Тем не менее в ходе отдельной итерации какие-то рабочие потоки могут оказаться ненужными. К примеру, на ранних стадиях проекта практически отсутствуют рабочие потоки Тестирование, Реализация и Развертывание. А на поздних стадиях нет потребности в Бизнес-моделировании и Требованиях.

Фазы UP. Унифицированный процесс создания ИС содержит четыре основных фазы: «Начало», «Уточнение», «Построение» и «Внедрение» (рис. 7.18). Каждая фаза включает в себя одну и более итераций, а внутри каждой итерации реализуются перечисленные ранее рабочие потоки (рис. 7.19). Число итераций внутри каждой фазы зависит от контрольных точек, создание которых обусловлено общей логикой проекта. Как правило, рекомендуется делать не более 3—5 итераций внутри одной фазы, а для средних и маленьких проектов рекомендуемое число итераций снижается до 1—2. При этом считается, что средняя длительность итерации не должна превышать два-три месяца.

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

Рис. 7.18. Общая логика UP

Рис. 7.19. Распределение объема работ по фазам RUP

На рис. 7.19 отображены все фазы UP, все рабочие потоки и объем работы, который выполняется на каждой фазе. Можно увидеть, что на фазе «Начало» наибольший объем работ приходится на рабочие потоки Бизнес-моделирование, Требования и Анализ и проектирование. Управлению конфигурацией и изменениями уделяется минимальное внимание, как и Среде. А Развертывание и Тестирование практически не выполняются.

• [1] Лрлоу Дж., Нейштадт A. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование. 2-е изд. СПб.: Символ-Плюс, 2008. С. 624.