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

Эта исполняемая базовая версия архитектуры будет дополняться по мере развития проекта и разовьется в окончательную поставляемую системув фазах Построение и Внедрение. Поскольку следующие фазы основываются на результатах Уточнения, можно сказать, что Уточнение – решающая фаза. В книге этой фазе уделяется много внимания.2.9.5. Уточнение – на что обращено вниманиеВ фазе Уточнение основное внимание в каждом из основных рабочихпотоков обращено на следующее:•определение требований – детализация предметной области системы и требований;•анализ – выяснение, что необходимо построить;•проектирование – создание стабильной архитектуры;•реализация – построение базовой версии архитектуры;•тестирование – тестирование базовой версии архитектуры.Итак, основное внимание в фазе Уточнение направлено на рабочие потоки определения требований, анализа и проектирования. Реализация приобретает значение в конце фазы при создании исполняемой базовой версии архитектуры.2.9.6.

Уточнение – контрольная точка:Архитектура жизненного циклаКонтрольная точка – Архитектура жизненного цикла. Условия принятия контрольной точки перечислены в табл. 2.2.Таблица 2.2Условия принятияПоставляемые артефактыСоздана гибкая надежная исполняемая базо Исполняемая базовая версиявая версия архитектуры.архитектуры.Исполняемая базовая версия архитектуры Статическая UMLмодель.демонстрирует, что важные риски были вы Динамическая UMLмодель.явлены и учтены.UMLмодель прецедентов.Представление продукта стабилизировалось. Общее описание проекта.Оценка рисков пересмотрена.Обновленная оценка рисков.64Глава 2.

Что такое Унифицированный процесс?Таблица 2.2 (продолжение)Условия принятияПоставляемые артефактыЭкономическое обоснование проекта пере Обновленное экономическоесмотрено и одобрено всеми заинтересованны обоснование проекта.ми сторонами.Создан достаточно детальный план проекта, Обновленный план проекта.что обеспечило возможность сформулировать реалистичную заявку на затраты времени, денег и ресурсов в следующих фазах.Заинтересованные стороны одобрили планпроекта.Проведена проверка экономического обосно Экономическое обоснованиевания проекта согласно плану проекта.проекта.Заинтересованные стороны достигли согла Подписанный документ.шения о продолжении проекта.2.9.7. Построение – целиПостроение превращает исполняемую базовую версию архитектуры в законченную рабочую систему.Цель фазы Построение – завершить определение требований, анализи проектирование и развить исполняемую базовую версию архитектуры, созданную в фазе Уточнение, в завершенную систему.

Главная проблема Уточнения – поддержание целостности архитектуры систе+мы. Очень часто при установлении сроков поставки и переходе к написанию кода начинается пренебрежение формальностями, что приводитк нарушению архитектурного представления, низкому качеству конечной системы и высоким затратам на обслуживание. Конечно, таких последствий следует избегать.2.9.8. Построение – на что обращено вниманиеОсновное внимание в этой фазе уделено рабочему потоку реализации.В других рабочих потоках делается ровно столько, чтобы завершитьопределение требований, анализ и проектирование. Тестирование становится более важным: каждый новый инкремент надстраивается надпредыдущим, поэтому здесь необходимо как тестирование отдельныхэлементов, так и совместное тестирование. Подводя итог, мы можемкратко охарактеризовать работу, выполняемую в каждом рабочем потоке, следующим образом:•определение требований – выявление всех неучтенных требований;•анализ – завершение аналитической модели;•проектирование – завершение модели проектируемой системы;652.9.

Фазы UP••реализация – создание базовой функциональности;тестирование – тестирование базовой функциональности.2.9.9. Построение – контрольная точка:Базовая функциональностьПо существу, эта контрольная точка очень проста – программная система готова к бетатестированию пользователем. Условия принятияданной контрольной точки приведены в табл. 2.3.Таблица 2.3Условия принятияПоставляемые артефактыПрограммный продукт достаточно стабилен Программный продукт.и качественен для распространения среди UMLмодель.пользователей.Тестовый комплект.Заинтересованные стороны одобрили и гото Руководство для пользователя.вы к введению программного продукта в свое Описание данной версии.окружение.Расхождения реальных расходов с предпола План проекта.гаемыми приемлемы.2.9.10. Внедрение – целиВнедрение направлено на развертывание законченной системы в сообществе пользователей.Внедрение начинается, когда завершено бетатестирование и системаокончательно развернута.

Сюда относится устранение всех дефектов,обнаруженных при бетатестировании, и подготовка к массовому выпуску программного обеспечения на все пользовательские сайты. Целиэтой фазы можно обобщить следующим образом:• исправление дефектов;• подготовка пользовательских сайтов под новое программное обеспечение;• настройка работоспособности программного обеспечения на пользовательских сайтах;• изменение программного обеспечения в случае возникновения непредвиденных проблем;• создание руководств для пользователей и другой документации;• предоставление пользователям консультаций;• проведение послепроектного анализа.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. Что мы узнали•••••67UP (и RUP) должны настраиваться под каждый конкретный проектпутем добавления внутренних стандартов и др.UP – это современный SEP, который является:• управляемым рисками и прецедентами (требованиями);• архитектуроцентричным;• итеративным и инкрементным.В UP программное обеспечение создается через итерации:• каждая итерация подобна минипроекту, создающему часть системы;• для создания окончательной системы итерации надстраиваютсядруг над другом.В каждой итерации пять основных рабочих потоков:• определение требований – выяснение того, что должна делатьсистема;• анализ – конкретизация и структурирование требований;• проектирование – реализация требований в архитектуре системы (как система это делает);• реализация – построение программного обеспечения;• тестирование – проверяется, работает ли должным образом реализация.В UP четыре фазы, каждая из которых заканчивается важной контрольной точкой:• Начало – проект сдвигается с «мертвой точки»: Цели жизненного цикла;• Уточнение – развитие архитектуры системы: Архитектура жизненного цикла;• Построение – построение программного обеспечения: Базоваяфункциональность;• Внедрение – развертывание программного обеспечения в пользовательской среде: Выпуск продукта.IIОпределение требований3Рабочий поток определения требований3.1.

План главыВ этой главе рассматривается все, что необходимо для понимания требований, предъявляемых к системе. Здесь вводится понятие требований и обсуждаются детали рабочего потока определения требованийв UP. Также представлено расширение UP для работы с требованиямибез применения прецедентов UML.3.2. Рабочий поток определения требованийКак показано на рис. 3.2, большая часть работы в процессе определения требований выполняется в фазах Начало и Уточнение в самом начале жизненного цикла проекта. Это и не удивительно, поскольку невозможно продвигаться вперед, за фазу Уточнение, до тех пор, пока неизвестно, хотя бы приблизительно, что предполагается разрабатывать!До начала работы над ОО анализом и проектированием уже необходимо иметь некоторое представление о том, что должно получиться в результате.

Именно в этом состоит цель рабочего потока определениятребований. С точки зрения ОО аналитика или дизайнера его цель –это поиск и достижение соглашения о функциях системы, написанного на языке пользователей системы. Создание высокоуровневой спецификации того, что должна делать система, – это часть процесса выра+ботки требований (requirements engineering).Большая часть работы с требованиями проводится в начале проекта,в фазах Начало и Уточнение.У любой заданной системы может быть множество различных заинтересованных сторон: разные типы пользователей, специалисты по эксплуатации, штат по обслуживанию, продаже, управлению и т. д. ВыраРис. 3.1. План главы3.6.1. Модель требованийelseelseизучаем детали рабочегопотока определения требованийelseизучаем, какое место рабочий потокопределения требований занимает в UP3.8.

Что мы узналиelse3.7.3. Анкеты3.7.2. Интервью3.7.1. Выяснение требований3.7. Поиск требований3.6.5. Атрибуты требований3.7.4. Семинар по определению требованийучимся находить требования3.6.3. Функциональные и нефункциональные требования3.4. Детализация рабочего потокаопределения требований3.2. Рабочий поток определения требований3.6.4. Организация требований3.6. Определение понятия требованияизучаем, почему требования так необходимы3.6.2. Правильно сформированные требования3.5. Важное значение определения требований3.3.