Методологии разработки программного обеспечения. Часть 3. Rational Unified Process | КомпьютерПресс

Что значит руп

План для начальной итерации проработки проекта (elaboration)

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

Analysis and design

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

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

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

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

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

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

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

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

• рекомендации на этапе анализа и проектирования;

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

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

Business modeling

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

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

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

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

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

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

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

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

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

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

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

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

• рекомендации по проведению бизнес-моделирования;

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

Deployment

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

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

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

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

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

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

• план внедрения.

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

КомпьютерПресс 1’2004

Implementation

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

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

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

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

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

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

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

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

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

Requirements

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

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

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

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

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

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

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

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

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

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

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

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

• правила системы;

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

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

• рекомендации по моделированию на этапе определения требований;

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

Аннотация

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

RUP успешно применяется в проектах любых типов и объемов. Данная статья описывает, как применять упрощенную версию RUP в небольших проектах. Мы описываем эффективные способы применения приемов экстремального программирования (XP – eXtreme Programming) в более широком контексте полного цикла проекта.

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

Исходная модель прецедентов

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

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

Как RUP, так и XP, помогают нам удостовериться, что мы не окажемся в ситуации, когда готово около 80% системы, но при этом нет ничего завершенного для передачи пользователю. Мы всегда предпочитаем иметь возможность разрабатывать системы, приносящие какую-либо пользу заказчику.

Модель прецедентов в этот момент идентифицирует прецеденты использования и актеров с минимальной детализацией или вообще без нее. Это может быть простой текст или диаграммы UML (Unified Modeling Language – универсальный язык моделирования), нарисованные от руки или с помощью графического редактора.

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

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

Короткая история

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

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

Взаимодействие с пользователями было простым и непосредственным – мы все были участниками одной сплоченной команды и не обращали внимания на формальности и документы. Также мало формальностей было и в проектировании. Код был проектом, и проект был кодом. Все было отлично!

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

Прошел год

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

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

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

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

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

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

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

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

План приемки проекта

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

Предварительный план проекта

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

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

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

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

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

• 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 — система управления тестированием, которая объединяет
все связанные с тестированием инструментальные средства, артефакты, сценарии
и данные;

Республиканское унитарное предприятие

Список рисков

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

Структура 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, поскольку этот процесс является одной из
реализаций «спирали».

Управление требованиями в RUP появляется на самых ранних
стадиях анализа. Теоретически модульная архитектура позволяет повторно использовать
код, и система получается более гибкой. В силу того что UML является объектным
языком, игнорировать модульность можно, но… несколько затруднительно.

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

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

Данное средство не является единственной реализацией UML — доступны как
коммерческие альтернативы (например, Microsoft Visio), так и бесплатные. Следует
отметить, что диалекты UML, реализованные в средствах моделирования, не всегда
совпадают: диалект Rational имеет некоторые серьезные различия, описанные как
в документации, так и в книгах по UML.

Утвержденные бизнес прецеденты

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

XP, как это описано в Planning Extreme Programming, достаточно гибко относится к тому, как проект начинается и какие роли привлекаются (в контексте существующего бизнеса или системы это представляется очевидным), но в рамках своей фазы рассмотрения (Exploration)

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

Часть 3. rational unified process

Введение

Структура RUP

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

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

   Business modeling

   Requirements

   Analysis and design

   Implementation

   Test

   Deployment