UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
2.7.2. Базовые версии и инкременты Каждая итерация UP формирует базовую версию. Это версия для внут реннего (или внешнего) использования набора рассмотренных и утвер жденных артефактов, сгенерированных в данной итерации. Каждая базовая версия: • предоставляет базу для дальнейшего рассмотрения и разработки; Определение требований Анализ Проектирование Реализация Тестирование UP определяет пять основных рабочих потоков Оценка Планирование Характерные для проекта... Итерация другие рабочие потоки Рис. 2.5. Возможные рабочие потоки итерации 2.8. Структура UP 59 • может изменяться только через формальные процедуры управле ния конфигурацией и изменениями. Инкременты – это просто разница между двумя последовательными базовыми версиями. Это шаги по направлению к окончательной вы пускаемой системе. 2.8. Структура UP В UP четыре фазы, каждая из которых имеет свои контрольные точки. На рис. 2.6 показана структура UP. Жизненный цикл проекта разделен на четыре фазы: Начало, Уточнение, Построение и Внедрение, каждая из которых имеет свои контрольные точки. В каждой фазе может быть одна или более итераций, в каждой итерации выполняются пять ос новных и любое количество дополнительных рабочих потоков. Точное число итераций в фазе зависит от размера проекта, но каждая итера ция должна длиться не более двух трех месяцев. Приведенный при мер является типовым для среднего проекта продолжительностью около 18 месяцев. Как видно из рис. 2.6, UP состоит из последовательности четырех фаз, каждая из которых завершается важной контрольной точкой: • Начало (Inception) – цели жизненного цикла; • Уточнение (Elaboration) – архитектура жизненного цикла; • Построение (Construction) – базовая функциональность; • Внедрение (Transition) – выпуск продукта. По мере прохождения этих фаз UP объем работы, выполняемый в каж дом из пяти рабочих потоков, меняется. Рисунок 2.7 – ключ к пониманию принципа работы UP. Вверху пока заны фазы. В крайнем левом столбце – пять основных рабочих пото ков. Внизу изображены итерации. Кривые показывают относитель Цели жизненного цикла Начало Архитектура жизненного цикла Уточнение Базовая функцио нальность Построение Выпуск продукта Внедрение Контрольная точка Фаза Итерации Итер 1 Итер 2 Итер 3 Итер 4 Итер 5 Итер 6 П Р T A Т Пять основных рабочих потоков Рис. 2.6. Структура UP 60 Глава 2. Что такое Унифицированный процесс? ный объем работы, выполняемый в каждом из пяти основных рабочих потоков по мере прохождения проекта по фазам. Объем работы, выполняемый в каждом из основных рабочих потоков, меняется в зависимости от фазы. Как показано на рис. 2.7, в фазе Начало большая часть работы выпада ет на определение требований и анализ. В фазе Уточнение основной акцент перемещается на требования, анализ и проектирование. Оче видно, что в фазе Построение основное внимание направлено на проек тирование и реализацию. И наконец, в фазе Внедрение главными ста новятся реализация и тестирование. UP – процесс, ориентированный на цели в большей степени, чем на соз дание поставляемых артефактов. Одной из замечательных особенностей UP является то, что он ориенти рован на цели, а не на создание поставляемых артефактов. Каждая фа за завершается контрольной точкой, состоящей из набора условий, ко торым надо удовлетворить, и эти условия могут включать или не включать, в зависимости от конкретных потребностей проекта, созда ние отдельного, готового к поставке продукта. Далее приводится краткий обзор каждой фазы UP. Начало Уточнение Построение Внедрение Определение требований Анализ Проектирование Реализация Тестирование Предварительные итерации Шаг 1 Шаг 2 Шаг n Шаг n+1 Шаг n+2 Шаг m Шаг m+1 Объем работы Рис. 2.7. Относительный объем работы, выполняемый в каждом из пяти рабочих потоков по мере прохождения проекта по фазам.Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства Addison Wesley 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 четыре фазы, каждая из которых заканчивается важной конт рольной точкой: • Начало – проект сдвигается с «мертвой точки»: Цели жизненно го цикла; • Уточнение – развитие архитектуры системы: Архитектура жиз ненного цикла; • Построение – построение программного обеспечения: Базовая функциональность; • Внедрение – развертывание программного обеспечения в пользо вательской среде: Выпуск продукта. II Определение требований |