13.6 Заключение

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

Распечатка сводки по проекту – это наиболее быстрый способ получения главной информации о проекте без создания настраиваемого отчета. Более сложные отчет могут быть созданы с использованием SoDA (см. Главу 12 «Документация»).

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

Перемещение и копирование проектов может быть полезным при организации структуры каталогов.

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

Более детальную информацию об этой информации можно найти в Руководствt Пользователя Rational RequisitePro – Rational RequisitePro User’s Guide[IBM03d].

Ссылки

[IBM03d] Rational RequisitePro User’s Guide, Version 2003.06.00, IBM Corporation, 2003.

Глава 14

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

В RUP (Rational Unified Process)

Эта глава объясняет, каким образом представленные в данной книге подходы к управлению требованиями могут соответствовать IBM Rational Unified Process (RUP). Глава также рассматривает применение подхода пирамиды к процессам без итераций (таким, как модель Водопада - Waterfall) и показывает, как перейти от этих процессов в RUP.

14.1 Rational Unified Process (RUP)

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

У этого процесса есть два измерения, как показано на Рисунке 14.1. По горизонтальной оси располагаются четыре фазы: Inception (Начальная), Elaboration (Проектирование), Construction (Построение) и Transition (Внедрение). Каждая фаза состоит из одной или более итераций. На каждой итерации выполняются действия из различных областей: Бизнес-Моделирование (Business Modeling), Requirements (Требования), Анализ и Проектирование (Analysis and Design), Реализация (Implementation), Тестирование (Testing), Развертывание (Deployment), Конфигурация (Configuration) и Управление Изменениями (Change Management), Управление Проектом (Project Management) и Программная Среда (Environment). Эти области представлены на вертикальной оси. Они относятся к определенным действиям, артефактам, исполнителям, а также технологическому процессу.

В RUP мы выполняем работу параллельно во всех областях. Например, на стадии Проектирования, пока Разработчики кодируют некоторую функциональность, Специалисты по требованиям работают над остальными требованиями, Тестеры готовят тестовые сценарии, Менеджеры Проектов пересматривают планы, и т.д. На каждой из этих четырех фазах работа производится по всем областям, однако основное движение идет в направлении: от Моделирования и Требований в Начальной фазе, к Реализации и Тестированию в фазе Построения, а затем к Развертыванию в фазе Внедрения. Все стадии (кроме Развертывания) начинаются в Начальной фазе. Даже Реализация и Тестирование (на которых мы проводим больше времени в фазе Построения) начинаются в Начальной фазе и доходят до Внедрения. График, показанный на Рисунке 14.1, часто называют «диаграммой вершин» RUP. Размер вершин отражает соответствующие усилия, потраченные на конкретную задачу на определенной точке жизненного цикла.

Рисунок 14.1. Два измерения RUP [RUP04].

В конце каждой фазы должна быть достигнута особая контрольная точка (milestone) [WES03]. Таблица 14.1. представляет эти контрольные точки:

Таблица 14.1. Контрольные точки и Акценты Фаз RUP.

Название Фазы	Название Контрольной Точки	Акцент Фазы
Начальная	Объекты Жизненного Цикла	Понимание области применения. Достижение соглашений по проекту. (Мы должны быть уверены, что все оговорено и что проект стоит дальнейших инвестиций). Для этого нам необходимо высокоуровневое представление объема работ, план (расписание), отношение стоимость/прибыль и описание рисков.
Проектирование	Архитектура Жизненного Цикла	Формализация требований. Архитектурный дизайн. Доказательство того, что архитектура способна поддерживать требования. Как правило, нужно реализовать от 20 до 30% системы, чтобы проверить архитектуру и уменьшить риски.
Построение	Начальное Рабочие Состояние	Разработка рабочей версии системы. Завершение всей функциональности.
Внедрение	Релиз Проекта	Развертывание финальной версии системы.

Каждая итерация планируется отдельно. В начале каждой итерации готовится План Итераций (Iteration Plan). Он предоставляет детальное описание действий, которые будут выполнены, определяет работников и указывает, какие артефакты будут созданы. Каждая итерация производит некоторую тестируемую часть системы, которая постепенно добавляется в финальный проект. Артефакты могут быть в следующей форме:

• Рабочее программное обеспечение.

• Модели (Use Case Model – Модель Сценариев Использования, Object Model – Объектная Модель и т.д.), обычно описанные в UML.

• Документы (Запросов Заинтересованных Лиц, Концепции и т.д.).

Для определения того, насколько успешно проведена итерация, можно провести в конце каждой итерации Оценку Итерации (Iteration Assessment).

Следующие шесть принципов составляют фундамент RUP:

• Итеративный процесс разработки программного обеспечения.

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

• Использование архитектур на основе компонентов.

• Визуальное моделирование программного обеспечения (в UML).

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

• Управление изменениями (Это включает управление «действиями» и «конфигурацией» - управление процессом изменений, а также измененных артефактов).

Вы можете настроить RUP для Вашего конкретного проекта. Простая версия может быть использована для небольших проектов [POL03], а более полный RUP можно применять к большим проектам. Вы можете использовать продукт IBM, который также называется «Rational Unified Process», чтобы облегчить настройку процесса [KRO03]. Это огромная HTML-система поддержки, которая включает шаблоны, инструкции, списки проверок, руководства по инструментам и путеводители.

Инструменты IBM Rational (такие как RequisitePro и Rational Rose) могут оказать существенную помощь в реализации RUP. Тем не менее, RUP может также применяться к тем проектам, которые не используют инструменты IBM Rational.

14.2 Пирамида Требований и RUP

Отношения между действиями, относящимися к определенной области, представлены в RUP в форме технологического процесса. Рисунок 14.2. показывает технологический процесс для области Требований [KRU00].

Соответствие высокоуровневых действий этого технологического процесса пирамиде требований:

• Анализ проблем и Понимание Потребностей Заинтересованных Лиц – это два верхних уровня пирамиды. Они определяют процесс создания документа Концепции (Vision), а также извлечение функциональных особенностей из потребностей заинтересованных лиц.

• Определение Системы относится к созданию третьего уровня (сценарии использования и дополнительные требования).

• Уточнение Определений Системы добавляет больше деталей на третий уровень.

• Управление Объемом Работ Системы состоит из расстановки приоритетов требованиям на каждом уровне, а также распределения требований по релизам.

• Управление Изменениями Требований находится само по себе. Если Вы формируете требования в форме пирамиды и устанавливаете трассировку (связь), управление изменениями требований становится довольно ясным.

Рисунок 14.2. Технологический процесс требований [RUP04].

Технологические процессы отражают только высокоуровневые действия. Диаграммы деталей технологических процессов показывают действия более подробно, как показано на Рисунке 14.3. Порядок действий не показан, т.к. обычно многие из них выполняются одновременно. Таблица 14.2 приводит список всех действий RUP в области требований и их соответствие пирамиде. Некоторые действия определены в RUP более детально. Например, шаг создания Сценариев Использования (Use Cases, см. Глава 7 «Создание Сценариев Использования (Use Cases»)) содержит следующие действия RUP: Найти Действующих Лиц и Сценарии Использования, Структурировать Модель Сценариев Использования, Установить Приоритеты Сценариям Использования, Детализировать Сценарии Использования.

Рисунок 14.3. Диаграмма деталей технологического процесса.

Таблица 14.2. Действия в Области Требований RUP .

RUP Действие	Работник	Отношение к Пирамиде
Разработка Плана Управления Требованиями	Системный аналитик	Выполняется вначале, перед созданием пирамиды (см. Главу 3).
Сбор Потребностей Заинтересованных Лиц	Системный аналитик	Создание верхнего уровня пирамиды (см. Главу 5).
Создание Общего Словаря	Системный аналитик	Не связано с определенным элементом пирамиды. Обычно выполняется на уровне создания Концепции.
Разработка Концепции	Системный аналитик	Концепция создается в то же время, когда на втором уровне пирамиды определяются функциональные особенности (см. Главу 6).
Поиск Действующих Лиц и Сценариев Использования	Системный аналитик	Выполняется в начале создания сценариев использования (см. Главу 7).
Детали Сценариев Использования	Специалист по требованиям	Выполняется в начале создания сценариев использования (см. Главу 7).
Структурирование Модели Сценариев Использования	Системный аналитик	Выполняется в начале создания сценариев использования (см. Главу 7).
Расстановка Приоритетов Сценариям Использования	Архитектор системы	Выполняется в начале создания сценариев использования (см. Главу 7).
Детали Требований Программного Обеспечения	Специалист по требованиям	Создание дополнительных требований (см. Главу 8).
Обзор Требований	Технический обозреватель	Будет применено к требованиям на всех уровнях.
Управление Зависимостями	Системный аналитик	Будет применено к требованиям на всех уровнях и к трассировке между требованиями.

Помимо действий области требований, также важными являются действия, относящиеся к проектированию и тестированию.

Несколько действий по проектированию на основе сценариев использования и других требований вместе с исполнителями, кто предположительно будет выполнять эти действия (см. Главу 11 «Объектно-Ориентированное Проектирование»):

• Анализ Сценариев Использования (дизайнер)

• Определение Элементов Дизайна (архитектор системы)

• Проектирование Классов (дизайнер)

• Обзор Дизайна (технический обозреватель)

Следующие действия по тестированию относятся к извлечению тестовых сценариев из сценариев использования (см. Главу 8 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования» (Use Cases)), а также из дополнительных требований (см. Главу 10 «Создание Тестовых Сценариев (Test cases) из Дополнительных Требований):

• Определение Идей Тестирования (аналитик по тестированию)

• Определение Детали Тестирования (аналитик по тестированию)

• Выполнение Тестирования (тестер)

• Анализ Неудачных Тестов (аналитик по тестированию)

• Определение Результатов Тестирования (аналитик по тестированию)

• Реализация Структуры Тестирования (дизайнер по тестированию)

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

Начальная фаза (Inception)

На Начальной фазе (Inception) делается акцент на бизнес-моделировании и сборе требований. Обычно Начальная фаза состоит из одной или двух итераций. К концу фазы собирается основная часть (85%) потребностей заинтересованных лиц. Создается начальная версия документа Концепции (Vision); разрабатывается диаграмма Сценариев Использования (Use Case); создается начальная версия документа Спецификации Сценариев Использования (Use Case Specification); определяется большинство сценариев (алгоритмов, scenario), а также создается Дополнительная Спецификация (Supplementary Specification). В общем случае, создается примерно от 15 до 50 страниц документации. Этого вполне достаточно для понимания общей области применения приложения и технологического процесса. Рисунок 14.1. показывает, какие части пирамиды были определены. Вы можете удивиться, почему некоторые сценарии помечены как определенные, хотя еще не были созданы Сценарии Использования, из которых они трассируются. Причина в том, что для определения сценария (алгоритма) достаточно начальных сценариев использования. Детали, которые будут описаны в Спецификации Сценариев Использования (Use Case Specification), могут быть добавлены позже. Сценарии использования еще не окончены, но некоторые сценарии (алгоритмы) могут быть уже получены из них.

Рисунок 14.4. Часть пирамиды, выполненная на Начальной фазе (Inception).

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

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

Рисунок 14.5. Часть пирамиды, выполненная на последней итерации Начальной фазы (Inception).

Проектирование (Elaboration)

Цели фазы Проектирования (Elaboration) – это минимизировать большинство рисков и спроектировать архитектуру системы (см. Рисунок 14.6). На этой фазе определяется основная часть (от 80 до 90%) функциональных особенностей, сценариев использования и дополнительных требований. Как Вы видите, многие сценарии (алгоритмы) и тестовые сценарии отмечены как завершенные. Это означает, что созданы тестовые сценарии. Некоторые из них будут выполнены на фазе Проектирования, а остальные – на фазе Построения (Construction). При использовании метода Водопада (Waterfall), тестовые сценарии создаются и выполняются на фазе Тестирования. В итеративной разработке лучше создавать тестовые сценарии пораньше. Тогда если в процессе создания тестовых сценариев будет обнаружено пропущенное требование, еще не поздно будет добавить и реализовать его. В процессе этой фазы также завершается основная часть проектирования (см. Рисунок 14.7). Некоторые диаграммы классов отмечены как завершенные, но созданы еще не все соответствующие диаграммы взаимодействия. Это означает, что эти классы спроектированы только частично. Тем не менее, даже частично спроектированные классы могут быть реализованы и включены в рабочую часть приложения.

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

Рисунок 14.6. Элементы пирамиды, выполненные в течение фазы Проектирования (Elaboration).

Рисунок 14.7. Элементы пирамиды, выполненные к концу фазы Проектирования (Elaboration).

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

Построение (Construction)

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

На фазе Построения создается рабочая версия системы. Это наиболее длинная и ресурсоемкая фаза. К ее окончанию выполняются все оставшиеся требования. Создаются оставшиеся тестовые сценарии, заканчивается тестирование (см. Рисунок 14.8). На ранних итерациях фазы Построения заканчивается разработка диаграмм, как показано на Рисунке 14.9.

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

Рисунок 14.8. Все элементы пирамиды, выполненные к концу фазы Построения (Construction).

Рисунок 14.7. Диаграммы, выполненные на ранних итерациях фазы Построения (Construction).

Внедрение (Transition)

На фазе Внедрения (Transition) строится финальная версия системы, разворачивается и поставляется заказчику. Ключевой точкой этой фазы является финальный продукт, поэтому все требования должны быть реализованы и протестированы. Так как все элементы пирамиды предположительно должны быть выполнены на фазе Построения (Construction), пирамида не изменяется на фазе Внедрения.

14.3 Пирамида Требований и Модель Водопада (Waterfall)

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

На фазе Сбора Требований (Requirements Elicitation), показанной на Рисунке 14.10, собираются все потребности заинтересованных лиц.

На фазе Анализа (Analysis), показанной на Рисунке 14.11, бизнес-аналитики извлекают все функциональные особенности из потребностей. На этой фазе также определяются сценарии использования и дополнительные требования.

Рисунок 14.10. На фазе Сбор Требований (Requirements Elicitation) модели Водопада (Waterfall) создается верхний уровень пирамиды.

Рисунок 14.11. На фазе Анализа (Analysis) модели Водопада (Waterfall) создаются функциональные особенности, сценарии использования и дополнительные требования.

П ри разработке с использованием модели Водопада в конце фазы Проектирования (Design) завершается создание всех диаграмм (см. Рисунок 14.12).

Рисунок 14.12. Элементы пирамиды, выполненные к концу фазы Проектирования (Design) модели Водопада (Waterfall).

На фазе Тестирования (Testing), показанной на Рисунке 14.13, мы разрабатываем тестовые сценарии и выполняем их. Если сценарии (алгоритмы) не были созданы на фазе Проектирования, они будут созданы на фазе Тестирования. К концу фазы будут запущены все тестовые сценарии. Если обнаружены некие ошибки, они должны быть исправлены и протестированы заново.

Рисунок 14.13. Элементы пирамиды, выполненные к концу фазы Тестирования (Testing) модели Водопада (Waterfall).

Имейте в виду, что определение сценариев (алгоритмов) необходимо для создания тестовых сценариев, также и как для создания диаграмм последовательностей. В жизненном цикле модели Водопада проектирование (и соответствующие диаграммы) создаются перед тестовыми сценариями, потому сценарии (алгоритмы) необходимы на фазе Проектирования (Design). Тем не менее, в RUP создание тестовых сценариев происходит достаточно часто на фазе Проектирования (Elaboration), иногда даже перед разработкой UML- диаграмм. В этом случае исполнители, выполняющие тестовые сценарии, и дизайнеры должны решить, кто будет извлекать сценарии (алгоритмы) из сценариев использования. Хорошей практикой считается извлечение сценариев сразу же после того, как создаются сценарии использования (на фазе Анализа - Analysis).

14.4 Переход от модели Водопада к RUP с Использованием Пирамиды Требований

Большое различие между процессом в модели Водопада (Waterfall) и RUP – порядок, в котором мы проходим по пирамиде требований. В модели Водопада мы движемся горизонтально, пока не будет закончен весь уровень. В итеративных методах на каждой итерации мы движемся вертикально, завершая часть каждого уровня. Разница заключается в порядке, в котором выполняются определенные задачи. Каждая итерация RUP включает несколько требований: сбор, анализ, проектирование, кодирование, тестирование и развертку.

Главный шаг в переходе от Водопада к RUP - это смена порядка, в котором создаются элементы пирамиды. Создаваемые в течение проекта документы изменять не нужно. У нас могут быть: Документ Требований Бизнеса - Концепция (Business Requirements Document - Vision), Спецификация Требований Программного Обеспечения – Сценарии Использования и Дополнительная Спецификация (Software Requirements Specification - Use Cases and Supplementary Specification), Тестовые Сценарии (Test Cases) и т.д. Может потребоваться дополнительная документация, такая как Планы Итераций (Iteration Plans).

Помимо реализации итеративной разработки, для полной реализации RUP необходимо использовать все лучшие практики:

• Итеративный процесс разработки программного обеспечения: Мы введем итерации путем изменения порядка создания элементов пирамиды. Перед каждой итерацией должен быть создан План Итерации (Iteration Plan). В конце каждой итерации выполняется Оценка Итерации (Iteration Assessment).

• Управление требованиями: Использование подхода пирамиды, представленного в этой книге, позволяет эффективно управлять требованиями и трассировкой (связями) между различными типами требований. Желательно использование RequisitePro.

• Использование архитектур на основе компонентов: Предлагается использование объектно-ориентированного проектирования. В зависимости от платформы и архитектуры системы, компоненты могут формироваться из различных сущностей (такие как архитектуры EJBs и J2EE).

• Визуальное моделирование программного обеспечения (в UML): Использование UML и любого инструмента для создания диаграмм (например, одного из инструментов IBM Rational: Rose, Software Architect, Data Architect или Software Modeler) способствует процессу проектирования (см. Главу 11).

• Непрерывная проверка качества: Глава 1 «Управление Требованиями» представляет атрибуты хороших требований, а Глава 6 «Разработка Документа Концепции (Vision)» представляет несколько примеров исправления требований. При разработке тестовых сценариев мы должны быть уверены, что финальный набор тестовых сценариев покрывает все требования системы (см. подход в Главе 9).

• Управление изменениями: После представления нового требования должна быть проверена трассировка (связь). Использование подхода пирамиды, в особенности с RequisitePro, способствует реализации трассировки. Использование инструмента по управлению изменениями, такого как IBM Rational ClearQuest, а также системы контроля версий, такой как IBM Rational ClearCase, помогает контролировать и отслеживать изменения.

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