Унифицированный процесс разработки RUP. Унифицированный процесс

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

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

Экстремальное программирование , наоборот, представляет так называемые "живые" (agile) методы разработки , называемые также "легкими" процессами. Они делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте, а также выступают против разработки дополнительных документов, не вносящих непосредственного вклада в получение готовой работающей программы.

Унифицированный процесс Rational

RUP , является довольно сложной, детально проработанной итеративной моделью жизненного цикла ПО .

Исторически RUP является развитием модели процесса разработки, принятой в компании Ericsson в 70–80-х годах XX века. Эта модель была создана Джекобсоном (Ivar Jacobson), впоследствии, в 1987 году, основавшим собственную компанию Objectory AB именно для развития технологического процесса разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. После вливания Objectory в Rational в 1995 году разработки Джекобсона были интегрированы с работами Ройса (Walker Royce, сын автора "классической" каскадной модели ), Крухтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимся параллельно универсальным языком моделирования (Unified Modeling Language, UML) .

RUP основан на трех ключевых идеях:

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

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

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

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

Унифицированный процесс Rational - это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation , которую в 2003 году купила IBM .

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

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

К примеру, RUP используется в системе управления онлайн-обучением TAP University . Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.

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

Что такое унифицированный процесс Rational (RUP)?

Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.

RUP оптимизирует командную работу – обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Это помогает быстрее справиться с критическими проблемами. Благодаря этому команда легко находит общий язык в процессе работы над проектом.

RUP ориентирован на создание и поддержание моделей – вместо написания большого количества бумажной документации при использовании RUP методологии создаются модели – семантические представления разрабатываемого командой программного обеспечения.

RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.

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

Шесть основополагающих принципов RUP

В основе RUP лежит шесть главных принципов :

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

Структура RUP

Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:

Работники – «Кто»

Элемент «работник » определяет поведение и ответственность всех членов команды, сконцентрированных на общей цели – создании искусственных объектов (артефактов ). В RUP работник – это скорее роль, определяющая, как индивидуумы должны выполнять свою работу. Работник не только производит определённые действия, но также владеет набором артефактов.

Действия – «Как»

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

Артефакты (искусственные объекты) – «Что»

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

Рабочий процесс – «Когда»

Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:

Жизненный цикл RUP

Жизненный цикл RUP разбит на четыре основных фазы, в каждой из которых ведётся работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение.

1. Фаза начала проекта

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

1. Уточнение

Цель этой фазы - анализ требований к системе и её архитектуры, разработка плана проекта и устранение элементов наивысшего риска. Это самая важная фаза из всех, поскольку она знаменует переход от низкого уровня риска к высокому. В рамках этой фазы команда решает, переходить ли к фазе построения (разработке и написанию кода ) или нет.

1. Построение

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

1. Внедрение

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

В конце каждой фазы существует отметка завершения этапа (Project Milestone ) - момент, когда ваша команда оценивает, достигнуты ли поставленные цели. При этом команда принимает важные решения, влияющие на ход следующей фазы.

Rational Unified Process (RUP) - это основа технологии разработки ПО, разработанная и продаваемая компанией Rational Software. Он включает в себя передовой мировой опыт разработки ПО, и обеспечивает дисциплинарный подход к распределению и управлению задачами и областями ответственности в организации, занимающейся разработкой ПО. Применяя этот процесс, команды разработчиков программ смогут создавать высококачественное ПО, отвечающее потребностям своих конечных пользователей, и делать это в рамках предсказуемого графика и бюджета.

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

В основе Rational Unified Process лежат несколько фундаментальных принципов, собранные из множества успешных проектов:

· Начинайте вести наступление на главные риска раньше и ведите его непрерывно, или они сами пойдут в наступление на вас.

· Обеспечьте выполнение требований заказчиков.

· Сконцентрируйтесь на исполняемой программе.

· Приспосабливайтесь к изменениям с самого начала проекта.

· Рано закладывайте исполняемую архитектуру.

· Стройте систему из компонентов.

· Работайте вместе как одна команда.

· Сделайте качество образом жизни, а не запоздалой идеей.

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

RUP обеспечивает структурированный подход к итеративной разработке , разделяя проект на четыре фазы: Начало, Проектирование, Построение и Внедрение. Каждая фаза сопровождается так называемой вехой, - контрольной точкой процесса, в которой проверяется достижение целей очередной фазы, и принимается решение о переходе (или не переходе) в следующую фазу. Каждая из четырех фаз RUP, таким образом, имеет веху и четко определенный набор целей. Эти цели используются для определения того, какие задачи выполнять и какие артефакты создавать. Каждая фаза концентрируется строго на том, что единственно необходимо для достижения бизнес целей фазы.

Все элементы процесса – роли, задачи, артефакты и связанные с ними концепции, руководства и шаблоны сгруппированы в логические контейнеры, называемые Дисциплинами (Disciplines). В стандартном продукте RUP дисциплин всего девять. К ним относятся: бизнес – моделирование, управление требованиями, управление проектом, управление изменениями и среда.

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

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

· бизнес – модель . Определяет абстракцию организации, для которой создается система;

· модель области определения . Фиксирует контекстное окружение системы;

· модель Use Case . Определяет функциональные требования к системе.

· модель анализа . Интерпретирует требования к системе в терминах проектной модели;

· проектная модель . Определяет словарь предметной области проблемы и ее решения;

· модель размещения . Определяет аппаратную топологию, в которой исполняется система;

· модель реализации . Определяет части, которые используются для сборки и реализации физической системы;

· тестовая модель . Определяет тестовые варианты для проверки системы;

· модель процессов . Определяет параллелизм в системе и механизмы синхронизации.

Технические артефакты подразделяются на четыре основных набора:

· набор требований. Описывает, что должна делать система;

· набор проектирования.

· набор реализаций. Описывает сборку разработанных программных компонентов;

· набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.

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

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

Набор реализаций группирует все данные о программных элементах, образующих систему (программный код, файлы конфигурации, файлы данных, программные компоненты, информацию о сборке системы).

Набор размещения группирует всю информацию об упаковке, отправке, установке и запуске системы.

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

Показатель Риска = Вероятность (НУ) *Потеря (НУ).

Управление риском включает шесть действий:

1. Идентификация риска – выявление элементов риска в проекте.

2. Анализ риска – оценка вероятности и величины потери по каждому элементу риска.

3. Ранжирование риска - упорядочение элементов риска по степени их влияния.

4. Планирование управления риском – подготовка к работе с каждым элементом риска.

5. Разрешение риска – устранение или разрешение элементов риска.

6. Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.

Первые три действия относятся к этапу оценивания риска, последние три действия – к этапу контроля риска.

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

Введение

ациональный унифицированный процесс (Rational Unified Process, RUP) - одна из спиральных методологий разработки программного обеспечения. Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).

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

RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта - анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.

Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно соответствует определенной версии модели программного обеспечения. Каждая из итераций (workflow) содержит элементы управления жизненным циклом программного обеспечения: анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение. В этом смысле RUP является реализацией спиральной модели, хотя довольно часто изображается в виде графика-таблицы. Ниже мы приведем основные компоненты процесса.

Для успешного процесса разработки необходимы три составляющие (рис. 1): процесс (process), нотация (notation) и набор утилит (tools). Процесс описывает, что мы делаем, в каком порядке и каким образом; нотация является средством общения; набор утилит помогает автоматизировать процесс и управлять им.

Рис. 1. Треугольник успеха

В RUP представлены все три компонента. Сначала рассмотрим функции нотации, которые производят следующие действия:

Осуществляет «склеивание» процесса в единое целое;

Является языковым средством принятия решений, которые не очевидны из исходного кода;

Предоставляет семантику для отображения важных стратегических и тактических решений;

Предлагает форму, достаточную для того, чтобы размышлять, а потом принимать решения и средства автоматизации процесса для того, чтобы манипулировать формализованными данными.

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

Структура RUP

UP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). К сожалению, в русском языке нет установившейся терминологии, поэтому в дальнейшем мы будем использовать английские термины, сопровождая их переводом на русский язык. На рис. 2 представлено широко распространенное изображение фаз RUP. Целями каждой из данных фаз являются:

Inception — понимание, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;

Elaboration — понимание, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;

Construction — создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);

Transition — создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.

Рис. 2. Фазы RUP

Это фазы управления эволюцией продукта - итерациями жизненного цикла. RUP предполагает приближение к конечной цели, но, в отличие от классического стандарта ISO (методология «водопад»), где transition является конечной фазой, каждая из фаз может повторяться несколько раз, отражая изменение требований заказчика продукта.

Методология RUP основана на девяти основных потоках (workflow), являющихся элементами итерации жизненного цикла ПО:

Business modeling (бизнес-анализ) - предполагает анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей;

Requirements (требования) — формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases (пользовательских историй) — формальное отображение требований пользователя в UML. Результатом являются документы уровня менеджмента;

Analysis and design (анализ и моделирование) - предполагает перевод собранных требований в формализованную программную модель. Результатом является описание системы на фазе реализации (технический проект) - это документы уровня разработчиков системы. Язык формализации - Unified Modelling Language (UML), о котором речь пойдет ниже. В процессе итеративной разработки эволюционировать будет продукт именно этого потока - модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов. Здесь имеется в виду тот факт, что результатом разработки является не модель, а исполняемый код, поэтому заказчик обычно не очень любит платить за моделирование, так как модели не являются продуктом, который ему нужен);

Implementation (реализация, кодирование) - предполагает собственно написание кода. Элементы кода в RUP уже созданы на этапе анализа и дизайна, так как средство реализации UML - Rational Rose - позволяет создавать элементы кода на нескольких языках программирования. Методология - объектно-ориентированное программирование;

Test (тестирование) — предполагает тестирование продукта на данной итерации. Стоит специально отметить, что regression testing (возвратное тестирование, тестирование «неухудшения» продукта) в данном случае должно содержать все актуальные тесты от предыдущей итерации и приемосдаточные тесты от предыдущей transition-фазы;

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

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

Preliminary interna — это фактически документы, выпускаемые техническим советом для менеджеров предприятия. Основная цель начальных этапов — заключение контракта или соглашения о намерениях. Дальнейшие итерации — собственно начало работы коллектива разработчиков, который имеет время и ресурсы для построения формальных моделей. UML в данном случае имеет средства, позволяющие отображать модель на элементы кода. Например, дерево объектов отображается непосредственно, вариации зависят от мощности реализации выбранного разработчиками языка программирования, а также от совпадения взглядов Г.Буча и разработчиков данного языка на объектную модель. То же самое относится к методам.

Теперь рассмотрим элементы, касающиеся поддержки продукта, - core supporting workflows:

Configuration management (управление конфигурацией и изменениями) - мощный слой административных действий, направленных на управление версиями продукта, что предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, корпоративные стандарты разработки кода и документации, отслеживание изменений и ошибок (bug tracking); тесно связан с тестированием и поддержкой пользователей (customers support);

Management (управление проектом) - предполагает набор административных действий управления проектом согласно идеологии RUP, используются средства управления проектом (см. ниже список продуктов Rational);

Environment (окружение) — предполагает создание и поддержку средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).

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

Управление требованиями;

Использование модульных архитектур;

Визуальное моделирование;

Проверка качества;

Отслеживание изменений.

Практики не являются непосредственно частью процесса RUP, но настоятельно рекомендованы к использованию. Часть практик прямо вытекает из идеологии RUP. Так, итеративная разработка заложена в структуру RUP, поскольку этот процесс является одной из реализаций «спирали». Управление требованиями в RUP появляется на самых ранних стадиях анализа. Теоретически модульная архитектура позволяет повторно использовать код, и система получается более гибкой. В силу того что UML является объектным языком, игнорировать модульность можно, но… несколько затруднительно. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Кроме того, модели являются средствами коммуникации между разработчиками, но для этого разработчики должны говорить на UML, что предполагает определенный тренинг. Визуальное моделирование часто осуществляется с помощью инструмента Rational Rose, что позволяет получать набор весьма полезных документов для менеджеров, системных администраторов, разработчиков, тестировщики, генерировать элементы кода. Данное средство не является единственной реализацией UML - доступны как коммерческие альтернативы (например, Microsoft Visio), так и бесплатные. Следует отметить, что диалекты UML, реализованные в средствах моделирования, не всегда совпадают: диалект Rational имеет некоторые серьезные различия, описанные как в документации, так и в книгах по UML.

Продукты, поддерживающие RUP

иже перечислены самые известные продукты, поддерживающие Rational Unified Process:

Rational Rose — CASE-средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта — Rational Rose RealTime — позволяет на выходе получить исполняемый модуль;

Rational Requisite Pro — средство управления требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения;

Rational ClearQuest — продукт для управления изменениями и отслеживания дефектов в проекте (bug tracking), тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой;

Rational SoDA — продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приведение документации к уже существующим стандартам (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, - средства тестирования и отладки:

Rational Purify — весьма мощное средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++,

Rational Visual Quantify — средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО,

Rational Visual PureCoverage - автоматически определяет области кода, которые не подвергаются тестированию;

Rational ClearCase — продукт для управления конфигурацией программ (Rational’s Software Configuration Management, SCM), позволяющий производить версионный контроль всех документов проекта. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite Pro поддерживает обновления и отслеживает изменения в требованиях для группы разработчиков;

SQA TeamTest — средство автоматизации тестирования;

Rational TestManager — система управления тестированием, которая объединяет все связанные с тестированием инструментальные средства, артефакты, сценарии и данные;

Rational Robot — инструмент для создания, модификации и автоматического запуска тестов;

SiteLoad, SiteCheck — средства тестирования Web-сайтов на производительность и наличие неработающих ссылок;

Rational PerformanceStudio - измерение и предсказание характеристик производительности систем.

Артефакты и роли

еотъемлемую часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role). Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты - это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов - начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п. Ниже приведен набор артефактов (моделей, документов и т.п.) для каждого из потоков.

Business modeling

Модель бизнес-процессов — определение бизнес-требований к разрабатываемой системе;

Модель структуры предприятия - артефакт для разработки функциональной модели системы;

Модели документов, бизнес-сущностей, модели сценариев бизнес-функций, модели состояний бизнес-сущностей - для проектирования пользовательского интерфейса, БД системы; представляют собой описание статического и динамического состояний системы с различных точек зрения;

Модели бизнес-правил — артефакт используется для моделирования правил в ПО.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, Microsoft Project:

Оценка организации заказчика, структура бизнеса;

Словарь терминов предметной области;

Набор бизнес-правил;

Коммерческое предложение;

Спецификации бизнес-функций;

План работ на этапе бизнес-моделирования;

Запросы на изменение.

Requirements

Артефакты-модели — используется Rational Rose:

Модель функции системы;

Модель сценариев функций системы;

Модель интерфейсов пользователя;

Модель сценариев работы пользователя системы;

Модель выходных форм;

Модель правил системы.

План управления требованиями;

Словарь терминов системы;

Спецификация на программную систему;

Спецификация на функции системы;

Правила системы;

Запросы заинтересованных лиц;

План работ на этапе определения требований к системе;

Запросы на изменение.

Analysis and design

Артефакты-модели — используется Rational Rose:

Логическая модель данных;

Физическая модель данных;

Модель спецификаций компонентов системы;

Сценарии взаимодействия классов, реализующих компоненты системы.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

Архитектура программного обеспечения;

Спецификации программных компонентов;

План работ на этапе анализа и проектирования;

Запросы на изменение.

Implementation

Артефакты-модели — используется Rational Rose:

Компонентная модель приложения.

Артефакты-код — используются Rational Rose, средства программирования, текстовые процессоры:

Элементы генерации кода, полученные в Rational Rose;

Собственно код приложения;

Документация.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

План сборки приложения;

План работ на этапе реализации.

Test

Артефакты-модели — используется Rational Rose:

Модель тестовых примеров;

Функциональная модель тестовой программы;

Модель спецификации компонентов тестовой программы;

Сценарии взаимодействия классов, реализующих взаимодействие компонентов тестовой программы.

Описание тестовых примеров;

План тестирования;

План работ на этапе тестирования;

Запросы на изменение.

Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Deployment

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

Обучающие материалы;

Документы по инсталляции;

Описание версий системы;

План внедрения.

Следующая статья данного цикла будет посвящена языку Unified Modelling Language (UML).

Унифицированный Процесс разработки компании Rational (Rational Unified Process, RUP) – это сумма различных видов деятельности, необходимых для преобразования требований пользователей в программную систему, . Его абстрактное и развёрнутое представление показано на рис. 7.2.

Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным программным продуктом. Прецеденты или варианты использования (use-case) ‑ это последовательности действий, выполняемых программной системой для получения наблюдаемого результата.

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

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

(а )

Рис. 7.2. Унифицированный процесс разработки ПО (а ‑ абстрактное представление, б – развёрнутое представление основных процессов RUP)

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

Для разработки графических представлений (моделей) программной системы RUP использует Унифицированный Язык Моделирования (UML). Фактически UML является неотъемлемой частью RUP ‑ они и разрабатывались совместно.

Однако действительно специфичные аспекты RUP-процесса заключаются в трех словосочетаниях - управляемый вариантами использования , архитектурно-ориентированный , итеративный и инкрементный . Это то, что делает Унифицированный процесс уникальным.

Полное представление программной системы в RUP включает девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы (рис 7.3):

1. модель бизнес-процессов , которая формализует абстракцию организации (со всеми вариантами использования управляющей ПС и их связями с пользователями);

2. модель прецедентов - формализует функциональные требования к системе;

3. модель предметной области или бизнес-модель , описывающую контекст системы.

4. модель анализа , которая имеет две цели - уточнить детали вариантов использования и создать первичное распределение поведения системы по набору объектов, предоставляющих различные варианты поведения;

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

6. модель проектирования , которая определяет: (а ) ‑ статическую структуру системы, такую, как подсистемы, классы и интерфейсы, и (b ) ‑ варианты использования, реализованные в виде коопераций между подсистемами, классами и интерфейсами;

7. модель реализации , которая включает в себя компоненты (представленные исходным кодом) и раскладку классов по компонентам;

8. модель развертывания , которая определяет физические компьютеры - узлы сети и раскладку компонентов по этим узлам;

9. модель тестирования , которая описывает варианты тестов для проверки вариантов использования;

Рис. 7.3. Модели RUP (в форме соответствующих UML-диаграмм)
и их связи,

Все эти модели связаны. Вместе они полностью описывают программную систему. Элементы одной модели имеют трассировочные зависимости вперед и назад, организуемые с помощью связей с другими моделями (см. рис. 7.3). Например, вариант использования (в модели вариантов использования) может быть оттрассирован на соответствующую реализацию варианта использования (в модели проектирования) и вариант тестирования (в модели тестирования). Трассировка облегчает понимание и внесение изменений. UML-диаграммы, созданные в процессе RUP-разработки, дают полное представление о программном продукте).

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