Введение
в Ratonal Unified Process
Введение
|
|
Большинство авторов приблизительно одинаково оценивают главную причину такого положения вещей. Это - возросшая сложность создаваемых систем. Проявлениями этой сложности являются не только увеличение размеров и функциональности. Не меньше, если не больше, проблем порождается частой сменой потребностей пользователей и ростом требований к качеству систем.
Традиционные способы разрешения проблемы сложности, такие как увеличение коллективов разработчиков, их специализация, распределение работ в чистом виде, ведут к еще большим трудностям согласования результатов и сборки готовых систем.
Серьезным шагом к победе над сложностью явилось появление объектно-ориентированного программирования (ООП). Но только шагом. Появление ООП не устранило проблем недостаточного взаимопонимания разработчиков и пользователей, неэффективного управления разработкой в условиях изменяющихся требований, неконтролируемости изменений в процессе выполнения работ, субъективности в оценке качества продуктов разработки и т.д.
И, тем не менее, 26% проектов заканчиваются успешно! Почему же все остальные снова и снова наступают на те же грабли? Почему они настойчиво продолжают учиться только на своих ошибках? Ведь решение лежит на поверхности: нужно сформировать и документировать набор проверенных на практике принципов, методов и процессов качественной и производительной работы над проектами по созданию программного обеспечения.
Эту миссию взвалила на свои плечи корпорация Rational Software и ее идеологи, столпы объектно- ориентированного подхода Grady Booch, Ivar Jacobson и James Rumbaugh. Rational Software выпустила в продажу Rational Unified Process, базу знаний, представляющую собой путеводитель для всех участников проекта по разработке большой программной системы. Далее, Rational Software выпустила комплект Rational Suite, ядром которого является Rational Unified Process, а остальные компоненты обеспечивают его инструментальную поддержку. И, наконец, Rational Software определила перечень продуктов других фирм, с которыми Rational Unified Process также тесно интегрирован.
Таким образом, вполне правомерно говорить о Rational Software технологии разработки программного обеспечения. Целью цикла публикаций, начинаемого этой статьей, является представление специалистам Rational Software технологии.
Я хочу подчеркнуть, что этот цикл не носит рекламного характера. В статьях цикла будут описываться принципы и приемы действий, способы использования рекомендуемых Rational Software инструментальных средств, приводиться примеры. Вы сможете попробовать применить полученные знания в своей работе. Если у Вас есть инструменты Rational Software - хорошо. Если нет - рисуйте диаграммы и планы на промокашках. Вы быстро убедитесь, что это хорошо, но мало. И тогда Вы сами, без всякой рекламы, обратитесь на наш сайт www.interface.ru, где представлены все необходимые сведения для приобретения нужных Вам продуктов.
Статьи цикла предполагается публиковать приблизительно раз в две недели. Формат публикации позволяет устанавливать гиперссылки внутри и между статьями. Поэтому, при появлении новых статей, возможно появление новых версий уже опубликованных. Это может быть связано как с появлением ссылок, так и с необходимостью уточнений или устранения ошибок. Я очень рассчитываю на обратную связь с читателями.
По окончании цикла Вы сможете напечатать на своем принтере маленькую книжку под условным названием «Введение в Rational Unified Process». А может быть, к этому времени появится локализованная русская версия Rational Unified Process. При дальнейшем чтении Вы убедитесь, что это было бы очень полезно!
С уважением,
Леонид Новиков
(novikov@interface.ru)
А теперь приступим...
Процесс - частично упорядоченный набор шагов, которые нужно проделать для достижения цели; при разработке программного обеспечения цель состоит в формировании или расширении существующего программного изделия.
Когда программная система разрабатывается на пустом месте, ее разработка Њ это процесс создания системы из требований. Но как только система приняла какую-то форму (или в наших терминах, когда система прошла начальный цикл развития), то любая доразработка - это процесс приспособления системы к новым или изменившимся требованиям. Разработка и все последующие доразработки составляют жизненный цикл системы.
Rational Unified Process обеспечивает строгий подход к назначению задач
и ответственности в пределах группы разработки. Его цель состоит
в том, чтобы гарантировать высокое качество программного продукта, отвечающего
потребностям конечных пользователей, в пределах предсказуемого временного
графика и бюджета.
 |
Rational Unified Process - это итеративный
процесс. Создавать современные сложные программные системы последовательно,
т.е. сначала определять все проблемы, затем принимать все проектные решения,
формировать программное обеспечение и, наконец, проверять изделие, невозможно.
Итерационный подход позволяет улучшать понимание проблемы через
последовательные усовершенствования и с приращением конкретизировать эффективные
решения. Этот подход обеспечивает большую гибкость при учете новых требований
или тактических изменений в деловых целях, и позволяет проекту заранее
идентифицировать и разрешать риски.
|
|
Rational Unified Process - это управляемый
процесс. Итерационный подход предполагает управление
требованиями и управление изменениями, чтобы по всем пунктам вовремя
гарантировать общее понимание ожидаемых функциональных возможностей, ожидаемый
уровень качества и гарантировать наилучшее управление связанными затратами
и графиками выполнения.
|
|
Rational Unified Process заключается в создании
и обслуживании моделей. Rational Unified Process фокусирует внимание
не на создании большого количества бумажных документов, а на развитии и
эксплуатации моделей - семантически богатых представлений программной системы
при ее разработке.
|
|
Rational Unified Process сосредотачивает внимание
на первоначальной разработке и компоновке устойчивой архитектуры
программы, которая облегчает параллельную разработку, минимизирует переделки,
увеличивает возможность многократного использования и надежность эксплуатации.
Эта архитектура используется для планирования использования и управления
развитием программных компонентов.
|
|
Действия при выполнении Rational Unified Process
управляются прецедентами. Понятия прецедентов и сценария управляют
технологическим маршрутом от делового моделирования и требований до испытаний,
и обеспечивают связанные и доступные для анализа маршруты разработки и
поставки системы.
|
|
Rational Unified Process поддерживает объектно-ориентированную
технологию. Некоторые из моделей являются объектно-ориентированными
моделями, которые базируются на понятиях объектов, классов и зависимостей
между ними. Эти модели, подобно многим другим техническим искусственным
объектам (артефактам), используют Унифицированный
Язык Моделирования (UML) как общую систему обозначений.
|
|
Rational Unified Process поддерживает компонентно-ориентированное
программирование. Компоненты - это нетривиальные модули или подсистемы,
которые выполняют конкретную функцию и могут быть смонтированы в строго
очерченной архитектуре, специальной или некоторой общедоступной инфраструктуре
компонентов, типа Internet, CORBA, COM/DCOM, для которых появляется индустрия
многократно используемых компонентов.
|
|
Rational Unified Process - это процесс с перестраиваемой
конфигурацией. Никакой одиночный процесс не подходит для всех случаев
разработки программного обеспечения. Rational Unified Process удовлетворяет
и маленькие группы разработчиков и большие организации. Rational Unified
Process основан на простой и корректной архитектуре, которая обеспечивает
общность для семейства процессов, и все же может быть изменена ради приспособления
к конкретным ситуациям. Он содержит рекомендации по конфигурированию процесса
для удовлетворения потребностей данной организации.
|
|
Rational Unified Process поощряет объективно
осуществляемое управление качеством. Оценка качества всех действий
и их участников, формируемая в процессе, использует объективные измерения
и критерии.
|
|
Rational Unified Process поддерживается инструментальными средствами, которые автоматизируют большинство действий процесса. Инструментальные средства используются для создания и обслуживания различных артефактов процесса разработки программного обеспечения: визуального моделирования, программирования, испытаний и так далее. Они неоценимы в поддержке всей бухгалтерии, связанной с управлением изменениями и управлением конфигурацией, которыми сопровождается каждая итерация. |
Впоследствии мы более подробно охарактеризуем каждое из этих качеств Rational Unified Process.
|
интерактивная
версия базы знаний в формате HTML, к которой приложен
|
|
комплект документов, описывающих процесс.
|
База знаний содержит описания архитектуры процесса и его составляющих (стадий разработки и потоков работ), технологии работы, правил создания различных артефактов: моделей, отчетов, планов и т.д. и порядка использования средств инструментальной поддержки.
Интерактивная версия содержит настраиваемые шаблоны, которые позволяют использовать информацию, порожденную в процессе работы над проектом, для создания отчетных документов с использованием Microsoft Word, Microsoft Project и Microsoft FrontPage.
Для работы с интерактивной версией Rational Unified Process на Вашем компьютере должен быть установлен Netscape Navigator или Microsoft Internet Explorer. Ниже показан один из экранов Rational Unified Process, на котором Вы можете узнать типичные для подобного рода продуктов средства управления.
В одной из следующих статей мы подробно остановимся на интерактивных возможностях Rational Unified Process и попытаемся смоделировать его работу.
|
По содержанию действий участников групп разработки
(по основным потокам работ).
|
|
Во времени (по стадиям жизненного цикла разрабатываемой
системы).
|
Процесс организован по содержанию (основные потоки работ) и во времени (стадии).
| Примечание:
|
Установите курсор на надписи «Организация во времени». Если Вы нажмете кнопку мыши, Вы перейдете в начало раздела «Структура жизненного цикла». Такой способ ссылок мы будем использовать очень часто. Поэтому, увидев на иллюстрации объект, о котором Вы хотите получить дополнительную информацию прямо сейчас, проверьте, не имеет ли он ссылки. |
Первое измерение представляет статический аспект процесса: оно описано в терминах основных потоков работ (исполнители, действия, их последовательность и так далее).
Второе измерение представляет динамический аспект процесса, поскольку оно выражено в терминах циклов, стадий, итераций и этапов.
Описание процесса выполняется с двух различных точек зрения:
|
Техническая точка зрения фокусируется
на артефактах и представлениях, связанных с разрабатываемым изделием.
|
|
Организационная точка зрения фокусируется
на времени, бюджете, людях и других экономических соображениях.
|
| Примечание:
|
Обратите внимание, что в этом изложении мы считаем деловое моделирование частью процесса разработки программного обеспечения. Это так, если Вы выполняете ограниченное деловое моделирование специально, чтобы выяснить требования к прикладной программе. Но деловое моделирование может быть выполнено и совершенно отдельно, с первичной целью заново спроектировать организацию, а не только сформировать новые прикладные программы. В этом последнем случае деловое моделирование должно рассматривается как его собственный процесс. |
|
Деловое моделирование
|
|
Требования
|
|
Анализ и проектирование
|
|
Выполнение
|
|
Испытание
|
|
Развертывание
|
|
Управление конфигурацией и изменением
|
|
Управление проектом
|
|
Среда
|
Основные потоки работ описаны в терминах работников, действий и артефактов.
|
Работник определяет поведение и ответственности
индивидуума или нескольких индивидуумов, работающих вместе как группа.
Это - важное отличие, потому что обычно о работнике думают как о конкретном
человеке или группе. В Rational Unified Process, работник - больше роль,
которая определяет, как индивидуумы должны выполнять работу.
|
|
Действие - это самая маленькая часть
работы, которая относится к делу; его можно интерпретировать как «техническую
операцию» работника. Далее, невозможно выполнить только часть действия,
хотя в пределах действия может существовать некоторая необязательная операция.
Такое разделение работы облегчает возможность контролировать разработку.
Гораздо лучше (проще) знать, что в проекте реализованы три из пяти действий,
чем то, что выполнено 60 % проекта.
|
|
Артефакты - искусственные объекты (конструкции
моделирования и документы), которые действия выделяют, поддерживают или
используют как исходную информацию.
|
С каждым работником ассоциируется набор «связанных» действий; связанность означает, что действия будут лучше выполнены этим индивидуумом. Ответственности каждого работника обычно определяются относительно некоторых артефактов, например документов. Примеры работников: аналитик делового процесса, проектировщик, архитектор или инженер-технолог.
Каждый работник имеет свой собственный набор действий
и артефактов
| Примечание:
|
В интерактивной версии Rational Unified Process щелчок на любой пиктограмме инициирует переход к описанию соответствующего объекта. Например, щелчок на пиктограмме артефакта Глоссарий (см. выше) откроет страницу с описанием структуры глоссария, требованиями к его содержанию, рекомендациями по использованию инструментальной поддержки и т.д. |
Через связанный набор действий работник неявно определяет также и навыки, необходимые для исполнения работ.
Для каждого основного потока работ представляется диаграмма краткого обзора действий. Эта диаграмма показывает все действия и всех работников, включенных в поток работ.
Для каждого основного потока работ представлена диаграмма краткого обзора артефактов. Эта диаграмма показывает все артефакты и всех работников, включенных в поток работ.
Типовая диаграмма краткого обзора артефактов (поток
работ делового моделирования)
Для большинства из основных потоков работ Вы найдете также диаграммы
деталей потока работ, которые показывают группировки действий, которые
часто выполняются вместе. Эти диаграммы показывают соответствующих работников,
артефакты ввода и вывода и выполняемые действия. Диаграммы деталей потоков
работ представляются по следующим причинам:
|
Действия потока работ не выполняются ни в
строго определенной очередности, ни внезапно. Обычно Вы работаете параллельно
больше, чем над одним действием и при этом рассматриваете больше, чем один
артефакт. Диаграмма деталей потока работ показывает, как часто Вы выполняете
поток работ или организуете совещания группы при выполнении потока работ.
Обычно для основного потока работ представлено несколько диаграмм деталей
потока работ.
|
|
Бывает слишком сложно показать артефакты ввода
и вывода для всех действий основного потока работ на одной диаграмме. Диаграмма
деталей потока работ позволяет нам показать одновременно действия и артефакты
для некоторой части потока работ.
|
|
Основные потоки работ не полностью независимы
друг от друга. Например, интеграция происходит в обоих потоках работ: и
выполнения, и испытания. В действительности Вы никогда не делаете одно
без другого. Диаграмма деталей потока работ может показывать группу действий
и артефактов в потоке работ вместе со связанными действиями из другого
потока работ.
|
Типовая диаграмма деталей потока работ (поток работ
делового моделирования)
|
Начало
|
|
Уточнение
|
|
Конструирование
|
|
Переход
|
Каждая стадия заканчивается четко определенной вехой - временной точкой, в которой должны быть приняты некоторые критические решения, а поэтому ключевые цели должны быть достигнуты.
Первый цикл выполнения этих четырех стадий для данного изделия называют начальным циклом разработки. Если жизненный цикл изделия на этом не завершается, существующее изделие разовьется в своем следующем поколении, повторив ту же последовательность стадий: начала, уточнения, конструирования и перехода. Этот период называется «эволюцией». Циклы развития, которые следуют за начальным циклом развития, называются «эволюционными циклами».
В конце начальной стадии Вы исследуете требования жизненного цикла проекта и решаете, следует ли продолжать разработку.
В конце стадии уточнения Вы детально исследуете цели и контекст системы, архитектурные решения и способы разрешения главных рисков.
В конце стадии конструирования Вы решаете, все ли программное обеспечение, рабочие места и пользователи готовы и работоспособны.
В конце переходной стадии Вы решаете, достигнуты ли цели жизненного цикла, и возможно, запускаете другой цикл разработки. Это также та точка, в которой Вы можете проанализировать некоторые из уроков, полученных в процессе разработки проекта.
Каждая итерация содержит все аспекты разработки программного обеспечения и повторяет все основные потоки работ. Но акценты на основных потоках работ различны, в зависимости от стадии разработки.
Это положение иллюстрируется следующей диаграммой, где показана трудоемкость каждого из основных потоков работ по мере Вашего продвижения от итерации к итерации через все четыре стадии.
Главное следствие такого итерационного подхода - артефакты, описанные ранее, обогащаются и через какое-то время становятся полностью зрелыми, как это показано на следующей диаграмме.
