Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

Подождите немного. Документ загружается.

2.9. Фазы UP 61

2.9. Фазы UP

У каждой фазы есть цель, основная деятельность с акцентом на одном

или более рабочих потоках, и контрольная точка. При обсуждении фаз

мы будем придерживаться этих двух основных понятий.

2.9.1. Начало – цели

Фаза Начало осуществляет инициирование проекта.

Цель фазы Начало – «сдвинуть проект с мертвой точки». Начало вклю

чает:

• Обоснование выполнимости – может включать разработку техниче

ского прототипа с целью проверки правильности технологических

решений или концептуального прототипа для проверки бизнестре

бований.

• Разработка экономического обоснования для демонстрации того,

что проект обеспечит выраженную в количественном отношении

коммерческую выгоду.

• Определение основных требований для создания предметной облас

ти системы.

• Выявление наиболее опасных рисков.

Основными исполнителями в данной фазе являются руководитель

проекта и архитектор системы.

2.9.2. Начало – на что обращено внимание

В фазе Начало основное внимание обращено на определение требова

ний и анализ. Однако если принято решение о создании технического

или подтверждающего концепцию прототипа, может быть проведено

некоторое проектирование и реализация. Тестирование обычно не

применяется в данной фазе, поскольку единственными программны

ми артефактами здесь являются прототипы, которые не будут больше

нигде использоваться.

2.9.3. Начало – контрольная точка:

Цели жизненного цикла

Тогда как многие SEP фокусируются на создании ключевых артефак

тов, UP применяет иной подход, ориентированный на цель. Каждая

контрольная точка устанавливает определенные цели, которые долж

ны быть выполнены для того, чтобы контрольная точка считалась

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

стве определенных артефактов.

62 Глава 2. Что такое Унифицированный процесс?

Поставляемый артефакт создается, только если он действительно необ

ходим в проекте.

Контрольной точкой фазы Начало являются Цели жизненного цикла.

Условия, которые должны быть выполнены, чтобы эта контрольная

точка была пройдена, приведены в табл. 2.1. Мы также предлагаем на

бор поставляемых артефактов, которые, возможно, потребуется соз

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

ставляемый артефакт создается, если он действительно необходим

впроекте.

Таблица 2.1

2.9.4. Уточнение – цели

Цели Уточнения можно описать следующим образом:

• создание исполняемой базовой версии архитектуры;

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

• определение атрибутов качества (скорости выявления дефектов,

приемлемые плотности дефектов и т. д.);

• выявление прецедентов, составляющих до 80% от функциональных

требований (что именно сюда входит, вы увидите в главах 3 и 4);

• создание подробного плана фазы Построение;

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

дование, штат и стоимость.

Условия принятия Поставляемые артефакты

Заинтересованные стороны согласовали

цели проекта.

Общее описание, определяющее

основные требования, характери

стики и ограничения проекта.

Заинтересованные стороны определили

и одобрили предметную область системы.

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

полненная только на 10–20%).

Заинтересованные стороны определили

и одобрили ключевые требования.

Глоссарий проекта.

Заинтересованные стороны одобрили

затраты и план работы.

Исходный план проекта.

Руководитель проекта сформировал

экономическое обоснование проекта.

Экономическое обоснование.

Руководитель проекта провел оценку

рисков.

Документ или база данных оценки

рисков.

Посредством технических исследований

и/или создания прототипа была подтвер

ждена выполнимость.

Один или более одноразовых прото

типов.

Архитектура намечена в общих чертах. Документ с исходной архитектурой.

2.9. Фазы UP 63

В задачу фазы Уточнение входит создание неполной, но рабочей версии

системы – исполняемой базовой версии архитектуры.

Основная цель фазы Уточнение – создание исполняемой базовой вер

сии архитектуры. Это реальная исполняемая система, построенная со

ответственно заданной архитектуре. Это не прототип (который уйдет

в корзину), а скорее всего, «первый срез» требуемой системы. Эта ис

полняемая базовая версия архитектуры будет дополняться по мере раз

вития проекта и разовьется в окончательную поставляемую систему

в фазах Построение и Внедрение. Поскольку следующие фазы основы

ваются на результатах Уточнения, можно сказать, что Уточнение – ре

шающая фаза. В книге этой фазе уделяется много внимания.

2.9.5. Уточнение – на что обращено внимание

В фазе Уточнение основное внимание в каждом из основных рабочих

потоков обращено на следующее:

• определение требований – детализация предметной области систе

мы и требований;

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

• проектирование – создание стабильной архитектуры;

• реализация – построение базовой версии архитектуры;

• тестирование – тестирование базовой версии архитектуры.

Итак, основное внимание в фазе Уточнение направлено на рабочие по

токи определения требований, анализа и проектирования. Реализа

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

зовой версии архитектуры.

2.9.6. Уточнение – контрольная точка:

Архитектура жизненного цикла

Контрольная точка – Архитектура жизненного цикла. Условия при

нятия контрольной точки перечислены в табл. 2.2.

Таблица 2.2

Условия принятия Поставляемые артефакты

Создана гибкая надежная исполняемая базо

вая версия архитектуры.

Исполняемая базовая версия

архитектуры.

Исполняемая базовая версия архитектуры

демонстрирует, что важные риски были вы

явлены и учтены.

Статическая UMLмодель.

Динамическая UMLмодель.

UMLмодель прецедентов.

Представление продукта стабилизировалось. Общее описание проекта.

Оценка рисков пересмотрена. Обновленная оценка рисков.

64 Глава 2. Что такое Унифицированный процесс?

Таблица 2.2 (продолжение)

2.9.7. Построение – цели

Построение превращает исполняемую базовую версию архитектуры в за

конченную рабочую систему.

Цель фазы Построение – завершить определение требований, анализ

и проектирование и развить исполняемую базовую версию архитекту

ры, созданную в фазе Уточнение, в завершенную систему. Главная про

блема Уточнения – поддержание целостности архитектуры систе+

мы. Очень часто при установлении сроков поставки и переходе к напи

санию кода начинается пренебрежение формальностями, что приводит

к нарушению архитектурного представления, низкому качеству ко

нечной системы и высоким затратам на обслуживание. Конечно, та

ких последствий следует избегать.

2.9.8. Построение – на что обращено внимание

Основное внимание в этой фазе уделено рабочему потоку реализации.

В других рабочих потоках делается ровно столько, чтобы завершить

определение требований, анализ и проектирование. Тестирование ста

новится более важным: каждый новый инкремент надстраивается над

предыдущим, поэтому здесь необходимо как тестирование отдельных

элементов, так и совместное тестирование. Подводя итог, мы можем

кратко охарактеризовать работу, выполняемую в каждом рабочем по

токе, следующим образом:

• определение требований – выявление всех неучтенных требований;

• анализ – завершение аналитической модели;

• проектирование – завершение модели проектируемой системы;

Условия принятия Поставляемые артефакты

Экономическое обоснование проекта пере

смотрено и одобрено всеми заинтересованны

ми сторонами.

Обновленное экономическое

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

Создан достаточно детальный план проекта,

что обеспечило возможность сформулиро

вать реалистичную заявку на затраты време

ни, денег и ресурсов в следующих фазах.

Заинтересованные стороны одобрили план

проекта.

Обновленный план проекта.

Проведена проверка экономического обосно

вания проекта согласно плану проекта.

Экономическое обоснование

проекта.

Заинтересованные стороны достигли согла

шения о продолжении проекта.

Подписанный документ.

2.9. Фазы UP 65

• реализация – создание базовой функциональности;

• тестирование – тестирование базовой функциональности.

2.9.9. Построение – контрольная точка:

Базовая функциональность

По существу, эта контрольная точка очень проста – программная сис

тема готова к бетатестированию пользователем. Условия принятия

данной контрольной точки приведены в табл. 2.3.

Таблица 2.3

2.9.10. Внедрение – цели

Внедрение направлено на развертывание законченной системы в сооб

ществе пользователей.

Внедрение начинается, когда завершено бетатестирование и система

окончательно развернута. Сюда относится устранение всех дефектов,

обнаруженных при бетатестировании, и подготовка к массовому вы

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

этой фазы можно обобщить следующим образом:

• исправление дефектов;

• подготовка пользовательских сайтов под новое программное обес

печение;

• настройка работоспособности программного обеспечения на пользо

вательских сайтах;

• изменение программного обеспечения в случае возникновения не

предвиденных проблем;

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

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

• проведение послепроектного анализа.

Условия принятия Поставляемые артефакты

Программный продукт достаточно стабилен

и качественен для распространения среди

пользователей.

Программный продукт.

UMLмодель.

Тестовый комплект.

Заинтересованные стороны одобрили и гото

вы к введению программного продукта в свое

окружение.

Руководство для пользователя.

Описание данной версии.

Расхождения реальных расходов с предпола

гаемыми приемлемы.

План проекта.

66 Глава 2. Что такое Унифицированный процесс?

2.9.11. Внедрение – на что обращено внимание

Основное внимание концентрируется на рабочих потоках реализации и

тестирования. Для исправления всех ошибок проектирования, выяв

ленных при бетатестировании, выполняется существенный объем про

ектирования. Надо стремиться к тому, чтобы в фазе Внедрение рабочие

потоки определения требований и анализа оставались практически не

задействованными. В противном случае с проектом не все в порядке.

• Определение требований – не проводится.

• Анализ – не проводится.

• Проектирование – изменение конструкции в случае выявления

проблем при бетатестировании.

• Реализация – настройка ПО под пользовательский сайт и исправле

ние проблем, не выявленных при бетатестировании.

• Тестирование – бетатестирование и приемочные испытания на поль

зовательском сайте.

2.9.12. Внедрение – контрольная точка: Выпуск продукта

Это последняя контрольная точка: бетатестирование, приемочные ис

пытания и исправление дефектов завершены, продукт выпущен и при

нят в сообществе пользователей. Условия принятия этой контрольной

точки приведены в табл. 2.4.

Таблица 2.4

2.10. Что мы узнали

• Процесс производства программного обеспечения (SEP) превращает

требования пользователя в ПО, определяя кто что делает и когда.

• Унифицированный процесс (UP) разрабатывается с 1967 года. Это

сложившийся открытый SEP от авторов UML.

• Унифицированный процесс компании Rational (RUP) – это коммер

ческое расширение UP. Он полностью совместим с UP, но более пол

ный и детализированный.

Условия принятия Поставляемые артефакты

Бетатестирование завершено, необходимые

изменения сделаны и пользователи соглас

ны с тем, что система успешно развернута.

Сообщество пользователей активно исполь

зует продукт.

Программный продукт.

Стратегии поддержки продукта согласованы

с пользователями и реализованы.

План поддержки пользователя.

Обновленные руководства для

пользователей.

2.10. Что мы узнали 67

• UP (и RUP) должны настраиваться под каждый конкретный проект

путем добавления внутренних стандартов и др.

• UP – это современный SEP, который является:

• управляемым рисками и прецедентами (требованиями);

• архитектуроцентричным;

• итеративным и инкрементным.

• В UP программное обеспечение создается через итерации:

• каждая итерация подобна минипроекту, создающему часть сис

темы;

• для создания окончательной системы итерации надстраиваются

друг над другом.

• В каждой итерации пять основных рабочих потоков:

• определение требований – выяснение того, что должна делать

система;

• анализ – конкретизация и структурирование требований;

• проектирование – реализация требований в архитектуре систе

мы (как система это делает);

• реализация – построение программного обеспечения;

• тестирование – проверяется, работает ли должным образом реа

лизация.

• В UP четыре фазы, каждая из которых заканчивается важной конт

рольной точкой:

• Начало – проект сдвигается с «мертвой точки»: Цели жизненно

го цикла;

• Уточнение – развитие архитектуры системы: Архитектура жиз

ненного цикла;

• Построение – построение программного обеспечения: Базовая

функциональность;

• Внедрение – развертывание программного обеспечения в пользо

вательской среде: Выпуск продукта.

Определение требований

Рабочий поток определения требований

3.1. План главы

В этой главе рассматривается все, что необходимо для понимания тре

бований, предъявляемых к системе. Здесь вводится понятие требова

ний и обсуждаются детали рабочего потока определения требований

в UP. Также представлено расширение UP для работы с требованиями

без применения прецедентов UML.

3.2. Рабочий поток определения требований

Как показано на рис. 3.2, большая часть работы в процессе определе

ния требований выполняется в фазах Начало и Уточнение в самом на

чале жизненного цикла проекта. Это и не удивительно, поскольку не

возможно продвигаться вперед, за фазу Уточнение, до тех пор, пока не

известно, хотя бы приблизительно, что предполагается разрабатывать!

До начала работы над ОО анализом и проектированием уже необходи

мо иметь некоторое представление о том, что должно получиться в ре

зультате. Именно в этом состоит цель рабочего потока определения

требований. С точки зрения ОО аналитика или дизайнера его цель –

это поиск и достижение соглашения о функциях системы, написанно

го на языке пользователей системы. Создание высокоуровневой специ

фикации того, что должна делать система, – это часть процесса выра+

ботки требований (requirements engineering).

Большая часть работы с требованиями проводится в начале проекта,

вфазах Начало и Уточнение.

У любой заданной системы может быть множество различных заинте

ресованных сторон: разные типы пользователей, специалисты по экс

плуатации, штат по обслуживанию, продаже, управлению и т. д. Выра

72 Глава 3. Рабочий поток определения требований

else

изучаем, какое место рабочий поток

определения требований занимает в UP

изучаем различные типы требований

изучаем детали рабочего

потока определения требований

изучаем, почему требования так необходимы

учимся находить требования

3.2. Рабочий поток определения требований

3.3. Требования, предъявляемые к программному

обеспечению – метамодель

3.4. Детализация рабочего потока

определения требований

3.5. Важное значение определения требований

3.6. Определение понятия требования

3.6.1. Модель требований

3.6.2. Правильно сформированные требования

3.6.3. Функциональные и нефункциональные требования

3.6.4. Организация требований

3.6.5. Атрибуты требований

3.7. Поиск требований

3.7.1. Выяснение требований

3.7.2. Интервью

3.7.3. Анкеты

3.7.4. Семинар по определению требований

3.8. Что мы узнали

Рис. 3.1. План главы