17. Понятие гибкого унифицированного процесса проектирования

Гибкий унифицированный процесс.

По определению гибкий унифицированный процесс (в дальнейшем просто унифицированный

процесс) детерминированный набор необязательных видов деятельности и артефактов. Однако на

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

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

1. Выбирается лишь небольшой набор видов деятельности и артефактов унифицированного

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

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

2. В силу итеративного характера унифицированного процесса анализ требований и

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

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

обратной связи.

3. Применение языка UML вместе с приемами гибкого моделирования.

4. Детальное планирование выполняется итеративно от итерации к итерации.

К отличительным особенностям унифицированного процесса можно также отнести следующие

принципы:

1. Оценка рисков и ключевых моментов проекта на ранних итерациях.

2. Постоянный отклик пользователей. Обратная связь и модификация требований.

3. Построение общей базовой архитектуры на ранних итерациях.

4. Постоянный контроль качества, раннее и качественное тестирование в реальных условиях.

5. Применение прецедентов.

6. Визуализация программной модели с помощью uml.

18. Фазы и дисциплины унифицированного процесса проектирования, распределение работ на различных фазах для основных дисциплин

Фазы унифицированного процесса.

В рамках унифицированного процесса работа над проектом включает 4 фазы:

1. Начало (inception) Определение начального видения проекта, прецедентов, определение сложности задачи.

2. Развитие (elaboration). Формирование более полного видения проекта, итеративная реализация базовой архитектуры. Создание наиболее критичных компонентов. Идентификация основных требований. Получение более реалистичных оценок.

3. Конструирование (construction). Итеративная реализация оставшихся менее критичных и простых компонентов, подготовка к развертыванию.

4. Передача. Бетта тестирование и развертывание. Веха (milestone) – конец итерации, где получены важные решения и оценки. Release – стабильно работающая часть ПО. Инкремент – разница между релизом и двух последующих итераций. Finale production release – система готова для коммерческого использования.

Дисциплины унифицированного процесса.

Дисциплина – набор видов деятельности и связанных с ними артефактов в рамках одного этапа

работы над проектом.

Артефакт – любой результат работы, например код, текстовые документы, диаграммы, модели…

Дисциплины:

1. Бизнес моделирование. – эта дисциплина подразумевает разработку модели предметной

области (domain model), которая является визуальным представлением наиболее важных

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

2. Требование - в рамках этой дисциплины создается модель прецедентов и дополнительная

спецификация, которая отражает функциональные и нефункциональные требования.

3. Проектирование – в этой модели создается модель проектирования, которая отображает

программные объекты.

4. Реализация – в рамках этой дисциплины выполняется программирование и построение

дисциплины, но не ее развертывание.

5. Тестирование, развёртывание, конфигурация и управление изменениями, …, окружение.

Окружение предполагает установку необходимых средств и настройку процессов для данного проекта.