4.​ Спонсоры, разработчики и пользователи должны поддерживать устойчивый темп развития проекта независимо друг от друга.

5.​ Простота — лучшее решение то, которое проще в реализации и поддержке.

6.​ Самоорганизация команд — лучшие идеи рождаются в командах, которые сами управляют своей работой.

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

Гибкий унифицированный процесс (Unified Process, UP) — это метод используемый в гибких моделях жизненного цикла разработки для проектов с неявными требованиями и высокими рисками изменений.

Вот основные особенности, делающие унифицированный процесс гибким:

1.​ Выбор только нужных элементов. Из всех возможных видов деятельности и артефактов выбираются лишь те, что реально полезны. Нет необходимости создавать всё подряд — если артефакт не улучшает результат, его можно опустить.

2.​ Итеративность. Работа идёт по циклам (итерациям), и требования с проектными решениями уточняются по ходу проекта, на основе обратной связи.

3.​ UML и гибкое моделирование. В процессе активно используется язык UML для визуализации системы и применяются приёмы гибкого (агильного) моделирования.

4.​ Раннее выявление рисков. На первых итерациях команда оценивает ключевые риски и возможные проблемы.

5.​ Вовлечённость пользователей. Постоянная обратная связь от пользователей помогает своевременно корректировать требования.

6.​ Контроль качества. Качество проверяется постоянно, с ранним и реалистичным тестированием.

7.​ Использование прецедентов. Сценарии использования системы (use cases) применяются для анализа требований и планирования.

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

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

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

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

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

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

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

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

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

релизом и двух последующих итераций. Finale production release – система готова для коммерческого использования.

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

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

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

Дисциплины:

1.​ Бизнес моделирование – эта дисциплина подразумевает разработку модели предметной области (domain model), которая является визуальным представлением наиболее важных сущностей из предметной области и их взаимосвязей для разрабатываемых приложений.

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

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

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

5.​ Тестирование, развертывание, конфигурация и управление изменениями, …, окружение. Окружение предполагает установку необходимых средств и настройку процессов для данного проекта.

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

Начальная фаза – краткий период формирования общего видения

и рамок проекта. Он включает в себя анализ примерно 10% прецедентов,

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

Следующие артефакты могут создаваться на начальной фазе или в начале фазы развития:

1.​ Видение и финансовые оценки проекта. Описываются общие задачи и ограничения, оценивается стоимость проекта и приводится заключение.

2.​ Модель прецедентов. Описываются функциональные требования, на начальной стадии (фазе) определяются имена всех прецедентов, и 10% из них описываются подробно.

3.​ Словарь терминов. Содержит ключевую терминологию по данной предметной области и словарь.

4.​ Перечень рисков и план управления ими. Описываются экономические, технические риски, риски, связанные с организацией и планированием ресурсами, а также методы их преодоления.