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

Обновлено: 07.07.2024

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

В результате каждой итерации получается работающая, но не полнофункциональная система, которая еще не является коммерческой и не подлежит распространению. Продолжительность создания коммерческой версии программной системы составляет 10 – 15 итераций.

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

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

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

Унифицированный процесс состоит из четырех фаз: начала, развития, конструирования и передачи (рис. 1):

Название фазы	Содержание фазы
Начало (inception)	Определение начального видения проблемы, прецедентов, а так же оценка сложности проекта.
Развитие (elaboration)	Формирование более полного видения проблемы, итеративная реализация базовой архитектуры системы, создание наиболее критичных компонентов (разрешение высоких рисков), определение основных требований и оформление их в виде системы прецедентов, получение более реалистичных оценок сложности проекта и сроков.
Конструирование (construction)	Итеративная реализация менее критичных и более простых элементов, подготовка к развертыванию системы.
Передача (transition)	Бета-тестирование и развертывание системы.

Рис. 1. Фазы рационального унифицированного процесса (RUP) разработки программного обеспечения

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

Рис. 2. Фазы и дисциплины рационального унифицированного процесса (RUP) разработки программного обеспечения

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

Можно привести пример короткой двухнедельной итерации. В первый день происходит осмысление задач и требований текущей итерации. Проводится обратное проектирование, например, при помощи пакета CASE-технологий Rational Rose, в результате чего будут получены диаграммы на языке UML, описывающие уже имеющуюся часть системы. Во второй день программистами проводится объектно-ориентированное проектирование той части системы, которая будет реализована в результате данной итерации. Тогда же выявляются возможные шаблоны проектирования, которые могут быть использованы при реализации этой части системы. Так же проводится совместное обсуждение результатов проектирования. Оставшиеся дни отводятся на реализацию (собственно написание программного кода на целевом алгоритмическом языке), отладку, тестирование, рефакторинг и интеграцию созданной части в систему.

Итак, основными свойствами унифицированного процесса являются:

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

Рациональный унифицированный процесс является наиболее предпочтительным при создании систем автоматизированного проектирования (САПР), CASE-систем, систем с элементами искусственного интеллекта, а также, систем поддержки структурно-параметрического синтеза объектов.

Аннотация: Рассматриваются в деталях модели разработки ПО, предлагаемые в рамках унифицированного процесса разработки Rational (RUP) и экстремального программирования (XP).

"Тяжелые" и "легкие" процессы разработки

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

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

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

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

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

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

Исторически 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.

Резюме

Исторический

В 1987 году Ивар Якобсон создал Objectory AB, чтобы продавать объектно-ориентированный метод разработки под названием Objectory Process. Этот метод является результатом подхода, ориентированного на компоненты, который он разрабатывал с 1967 года в компании Ericson . Objectory основан на сценариях использования , концепции, разработанной Якобсоном. Затем метод следует систематическому подходу, направленному на последовательность моделей OOSE для достижения программной реализации.

В 1992 году Грейди Буч , сотрудник компании Rational Software, опубликовал метод объектно-ориентированной разработки Буча . Он состоит из языка графического моделирования , итеративного процесса разработки и набора передовых практик .

В 1995 году Rational Software приобрела Objectory AB и объединила два метода разработки под названием Rational Objectory Process. Компания также наняла Джеймса Рамбо , создателя языка моделирования OMT .

Принципы

Характеристики

Единый процесс - это метод разработки программного обеспечения, характеризующийся:

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

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

Жизненный цикл проекта

У каждого проекта есть четыре фазы жизненного цикла , каждая из которых разделена на несколько итераций:

Единый процесс отстаивает подход, основанный на оценке рисков, с поиском через различные итерации, чтобы разрешить самые большие неопределенности в качестве приоритета.

Цепочка мероприятий

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

Требования: исследование субъектов и вариантов использования, приоритезация, описание вариантов использования, прототипирование пользовательского интерфейса и структурирование модели вариантов использования;

Анализ: анализ архитектуры, анализ вариантов использования, анализ классов и анализ пакетов;
Дизайн: проектирование архитектуры, проектирование вариантов использования, проектирование классов и проектирование подсистем;
Реализация (реализация): реализация архитектуры, системная интеграция, реализация подсистемы, реализация класса и выполнение модульных тестов;
Тестирование: планирование тестирования, разработка тестов, реализация тестов, выполнение интеграционных тестов, выполнение системных тестов и оценка тестов.

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

Унифицированный процесс также определяет роли для субъектов, участвующих в этих действиях (например, архитектор, разработчик компонентов, разработчик пользовательского интерфейса и т. Д.). Однако авторы подчеркивают, что это роли, а не люди; Таким образом, один и тот же член команды может совмещать несколько ролей. Единый процесс, наконец, определяет серию артефактов, то есть результатов проекта.

Итерационное планирование

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

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

Операция

Управление прецедентами использует диаграммы прецедентов ( DCU ), дополненные текстовыми описаниями. Из DCUs, то анализ, проектирование, развертывание, внедрение и тестирование модели получены . Из этих моделей возникает архитектура системы. Также предлагается систематический подход для вывода вариантов использования из классов анализа и проектирования в соответствии со схемой контроля объектов и границ . Это также сценарии использования, которые позволят разрабатывать сценарии тестирования, поскольку новое программное обеспечение должно обеспечивать выполнение запланированных сценариев использования. Таким образом, DCU являются моделями, которые гарантируют согласованность процесса разработки, выступая в качестве общей нити для всех действий.

Действия по моделированию основаны на UML . Этот язык моделирования охватывает структурные и динамические аспекты архитектуры и дизайна программного обеспечения. Это облегчает моделирование компонентов с использованием объектно-ориентированного подхода . Создатели UML также стояли у истоков единого процесса, который должен был дополнить UML полным и универсальным процессом разработки [исх. необходимо] .

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

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

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

Варианты единого процесса

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

Общие названия и сокращения:

ИЛИ ЖЕ

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

RUP расширяет цепочки действий, чтобы также покрыть

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

ВЕРШИНА

Agile Unified Process (AUP) - это упрощенный вариант UP, который включает гибкие практики, такие как разработка через тестирование (TDD). Таким образом, он охватывает последовательные этапы и вехи в конце этапа единого процесса, но усиливает гибкий подход, рекомендуя обновление плана в конце каждого этапа, внедрение потенциально доступной для публикации версии в конце. каждого этапа, конца каждой итерации и применения принципов Agile-манифеста . Следовательно, использование моделей в качестве артефакта документации ограничивается моделью требований и моделью проекта. AUP обогащает моделирование требований бизнес-моделями. Далее метод рекомендует сконцентрировать моделирование на контурах и избегать деталей, которые можно легко вывести из кода. AUP доступен бесплатно в Интернете в виде сжатого архива, но не поддерживается с 2006 года.

EssUP

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

Практики, определенные EssUP, сгруппированы в 8 тематических семейств: команда, продукт, жизненный цикл, итерации, сценарии использования 2.0, архитектура, компоненты и выполнение тестов. EssUP доступен в Интернете.

Позиционирование

Сравнение с другими методами

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

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

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

Отзывы

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

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

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

Эволюции

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

10. ОСНОВЫ УНИФИЦИРОВАННОГО ПРОЦЕССА

10.1. Структура Унифицированного процесса

Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО (авторы Ивар Якобсон, Гради Буч и Джеймс Рамбо). Она отвечает "на вопросы когда, как, кто, что и с помощью чего реализуется проект" [30], а именно содержит описание:

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

- видов деятельности (как) – работ, осуществляемых исполнителями;

Рис. 10.1. Вид деятельности

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

Рис. 10.2. Исполнитель

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

Рис. 10.3. Примеры артефактов

- используемых утилит (с помощью чего) – программных продуктов, рекомендуемых при выполнении работ.

10.2. Технологические процессы

Рис. 10.4. Спиральная стратегия жизненного цикла

Каждый виток характеризуется приращением (инкрементом) функциональности системы и одинаковым набором технологических процессов и стадий (рис. 10.5, в Унифицированном процессе – фаз). В рамках одной стадии также используется идея спиральной разработки. Перед началом выполнения каждой стадии планируется количество итераций, каждая из которых характеризуется некоторым приращением результатов. В рамках одной итерации выполняются основные процессы, начиная от формирования требований и заканчивая внедрением [29, 30].

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

Рис. 10.5. Интенсивность процессов при создании версии информационной системы

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

Уточнение (англ. elaboration). Целью фазы является разработка архитектуры и моделей проектируемой системы, основным результатом – технический проект.

Конструирование (англ. construction). Целью фазы является разработка действующей версии системы, основным результатом – версия системы.

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

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

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

Вспомогательные технологические процессы обеспечивают выполнение основных и рассмотрены во второй части и в [5].

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

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

Как было отмечено выше, технологический процесс представляется в виде диаграммы. На рис. 10.6 показан пример диаграммы, отображающей обобщенную схему процесса "Управление проектом" [30].

Рис. 10.6. Обобщенная схема технологического процесса "Управление проектом"

10.3. Артефакты

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

Таблица 10.1. Краткая характеристика моделей

Процесс	Модель	Назначение
Формирование требований	Модель вариантов использования	Отображает существенные функциональные требования к системе в форме, удобной для всех заинтересованных лиц. Под существенными требованиями понимаются требования, реализация которых принесет пользователям ощутимый и значимый результат. Наименее формальная, но управляет всем процессом разработки.
Анализ требований	Модель анализа	Детализирует варианты использования с точки зрения организации внутренней архитектуры системы, а именно: состава основных сущностей (классов анализа) и взаимодействия между ними. Класс анализа – укрупненный класс (сущность), который в дальнейшем будет разбит на составляющие.
Проектирование	Модель проектирования	Содержит полное детализированное описание внутренней архитектуры и алгоритмов работы системы. Применяется внутри организации, разрабатывающей систему.
Реализация	Модель реализации	Содержит описание исполняемой системы: компонентов (исходных текстов программ, исполняемых модулей, таблиц БД и т.д.) и схемы развертывания системы.
Тестирование	Модель тестирования	Предназначена для проверки соответствия полученного ПО требованиям.

Модели описывают проектируемую систему с различных точек зрения и на разном уровне абстракции. При этом некоторые элементы (например, диаграммы или классы) могут одновременно входить в разные модели. Более того, один и тот же элемент может входить в две и более моделей с разной степенью детализации.

Модели могут быть вложены друг в друга. Вложенность моделей изображается двумя способами.

Рис. 10.8. Способы отображения вложенности моделей

В Унифицированном процессе набор получаемых артефактов, как и технологический процесс, также может отображаться в виде диаграммы. На следующем рисунке показан пример диаграммы артефактов для процесса "Управление проектом" [30].

Рис. 10.9. Диаграмма артефактов технологического процесса "Управление проектом"

10.4. Утилиты

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

- управление требованиями – IBM Rational RequisitePro;

- визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE;

- разработку – IBM Rational RapidDeveloper;

- конфигурационное управление – IBM Rational ClearCase;

- управление изменениями – IBM Rational ClearQuest;

- автоматизированное документирование – IBM Rational SoDA;

- автоматизированное тестирование – IBM Rational TeamTest, IBM Rational TestFactory, IBM Rational Robot, IBM Rational PurifyPlus, IBM Rational SiteCheck и IBM Rational SiteLoad.

Методологической основой использования перечисленных продуктов является IBM Rational Unified Process (IBM RUP) – "электронный аналог" Унифицированного процесса. IBM RUP поставляется в виде "on-line" документации (размещаемой в Web базы знаний), что позволяет его использовать во внутренней сети организации с целью приобщения всех сотрудников к полезной информации, и состоит:

- из руководств для всех членов коллектива разработчиков и каждого временного интервала жизненного цикла ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне и в виде подробных наставлений по повседневной деятельности;

- рекомендаций по использованию инструментальных средств, автоматизирующих стадии жизненного цикла ПО;

- примеров и шаблонов для Rose, которые служат руководствами по тому, как "правильно" проектировать систему;

- шаблонов для SoDA, которые помогают автоматизировать документирование ПО;

- шаблонов Microsoft Word, которые предназначены для поддержки документации по всем стадиям и работам жизненного цикла ПО;

- планов в формате Microsoft Project, отражающих итерационную разработку;

- Development Kit (англ. – комплект разработки), содержащего описание возможностей по конфигурации и расширения IBM RUP для специфических нужд проекта;

- доступа к Resource Center, содержащего последние публикации, обновления, подсказки, методики, а также ссылки на add-on (англ. – расширения) и сервисы;

- книги Филиппа Кратчена "Введение в Rational Unified Process" [30]. Книга содержит более 200 страниц и является хорошим вводным руководством к Унифицированному процессу и базе знаний.

IBM RUP ориентирован на всех участников проекта. На следующем рисунке приведена стартовая страница продукта RUP.

Рис. 10.10. Стартовая страница RUP

Ключевым продуктом для автоматизации технологического процесса "Проектирование" является IBM Rational Rose, которое представляет собой классическое Case-средство. К основным возможностям Rose относятся:

- прямое проектирование – построение модели системы в виде диаграмм UML и глоссария;

- кодогенерация – получение кода программы на основе модели системы. Поддерживаются: С++, Ada, Java, Visual Basic, CORBA 1 /IDL 2 . Сторонние производители разрабатывают специальные мосты к не входящим в стандартную поставку языкам (например, к Object Pascal);

- генерация схем БД для Oracle, скриптов DDL 3 и документов XML 4 ;

- обратное проектирование (реинжиниринг) – получение модели на основе кода программы, БД, скрипта или документа;

- синхронизация модели и ее физической реализации для поддержания итеративной разработки системы.

IBM Rational Rose позиционируется для использования аналитиками, проектировщиками и разработчиками.

Для разработки программ рекомендуется использовать среду разработки программного обеспечения IBM Rational RapidDeveloper.

Аналогичная линейка продуктов, поддерживающая ключевые процессы жизненного цикла, выпускается компанией Borland (Borland Together Designer, Borland Together Architect, Borland StarTeam, Borland CaliberRM и др.).

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

1 CORBA – Common Object Request Broker Architecture (общая объектная архитектура брокеров запроса).

2 IDL – Interface Definition Language (язык описания интерфейсов).

3 DDL – Data Definition Language (язык определения данных, составная часть SQL). SQL – Structured Query Language (структурированный язык запросов).

4 XML – eXtensible Markup Language (расширяемый язык разметки).

10.5. Базовые концепции Унифицированного процесса

Базовыми концепциями Унифицированного процесса являются следующие [29, 30]:

- разработка ведется итеративно;

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

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

- использование визуального моделирования в целях создания полного и согласованного описания всех аспектов разрабатываемой системы (моделей). В качестве базового средства создания моделей используется UML;

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

Вопросы для самопроверки

1. Дайте краткую характеристику основных составляющих Унифицированного процесса: технологических процессов, исполнителей, артефактов, утилит.

Читайте также: