RUP. Фаза проектирования (Проработка). Цели и итерации. Рецензирование проекта.

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

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

Главная цель разделяется на 4 крупные цели:

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

К концу фазы начало должно быть подробно описано около 20% наиболее важных вариантов использования. Для остальных вариантов использования должны быть краткие описания. К концу фазы проектирования должно быть завершено примерно 80% вариантов использования (ВИ).Если ВИ очень прост или похож на другой, то его можно не описывать и отложить до конца фазы построения. Для главных ВИ нужно создать прототип и протестировать его с пользователем, чтобы посмотреть как пользователь будет работать с приложением. В результате подробного описания ВИ скорее всего будут найдены др. ВИ, которые нужно добавить в используемый приоритет. Следует также постоянно обновлять словарь, в котором будут отражены осн. понятия, которые необходимо знать как работает система.

2. Спроектировать реализовать и проверить базовую архитектуру.

А) Определить элементы архитектуры. Прежде чем придумать архитектуру необходимо рассмотреть возможность использования архитектуры базы. Если такой возможности нет необходимо принять следующие проектные решения.

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

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

- реализация и тестирование исполняемой архитектуры – частичная реализация системы, созданная для того, чтобы показать, что архитектура может обеспечить ключевые функции и демонстрировать нужные показатели.

Б) Спроектировать критичные варианты использования.

В) Объединить классы, обеспечить архитектурный охват, спроецировать БД. Архитектурный охват – часть стратегии по снижению рисков в целях сведения к минимальному неожиданных проблем в будущем.

Г) Создать схему выполнения процессов, потоков, физ. Распределения.

Д) Определить архитектурный механизм. Это типовые конкретные решения часто встречающихся проблем. Создавая их мы можем решить самые общие трудные проблемы, а потом все члены команды ими пользовались.

Е) Реализовать и тестировать критические ВИ. В ходе проектирования ВИ необходимо добавить код и протестировать его.

Ж) Проводить интеграцию компонентов.

3. Снизить существенные риски и дать более точную оценку сроков стоимости.

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

4. Уточнить прецедент разработки и фазу разработки.

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

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

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

1 Интеграция проектирования:

1. Для снижения самых критических рисков спроектировать, реализовать и протестировать небольшое число критичных сценариев. Для определения необходимого типа архитектуры и архитектурных механизмов.

2. Определить, реализовать и протестировать небольшой первоначальный набор архитектурных механизмов.

3. Выполнить предварительный логический дизайн БД.

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

5. Тестировать столько, сколько нужно, чтобы подтвердить уменьшение архитектурных рисков.

2 Интеграция проектирования:

1. Исправлять все, что было не в порядке в 1-ой интеграции.

2. Спроектировать, реализовать и протестировать оставшихся важных с архитектурной точки зрения сценарий.

3. Проработать и реализовать параллельное выполнение процесса потоки и физическое распределение.

4. Определить, реализовать и протестировать оставшиеся архитектурный механизм.

5. Спроектировать и реализовать черновую версию БД.

6. Подробно расписать 2-ую половину вариантов использования, которую нужно специфицировать в фазе проектирования.

7. Протестировать, оценить и усовершенствовать архитектуру так, чтобы она могла выступать как стабильный базис.

Изменения вносить можно, но следует избегать больших переработок. Если стабильного состояния архитектуры достичь не удалось нужно добавить еще одну итерацию.

 

Рецензирование проекта.

Включает в себя оценку следующих моментов:

10. Является ли концепция и требования проекта стабильными.

11. Является ли стабильной архитектура.

12. Проверенны ли основные подходы, которые будут использоваться при тестировании и оценки системы.

13. Показало ли тестирование и оценка исполняемых прототипов, что основные риски устранены.

14. Является ли планы итерации на фазе построения достаточно подробными и точными.

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

16. Приемлема ли разница запланированных и реальных расходов.

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