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

Цели:

1. Снизить стоимость разработки и добиться определенного параллелизма в работе команд разработчиков. Автоматизировать использование ресурсов и избегать создание ненужного кода при переработках.

2. Разработать итеративным методом окончательный продукт готовый к предоставлению сообществу пользователей.

Цель1: Экономическая эффективность разработки ПО яв-ся целью всех фаз. Создавать ПО эффективно возможно только если в фазе проектирования была создана стабильная архитектура. Надежная архитектура разделяет области ответственности на четкие подсис-мы. Разработчики должны понимать всю сис-му, но могут концентрироваться в 1-ую очередь на своей части. Организация вокруг архитектора облегчает общение, т.к. большая его часть происходит внутри команды, отвечающей за систему. Общение команды происходит через группу архитекторов, которые занимаются проблемами общего хар-ра и вопросами взаимодействия между подсис-ми. Для упрощения общения также нужно иметь одну команду интеграции.

Цель 2:

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

2. Завершить проектирование. Во всех итерациях построения необходимо концентрироваться на завершении проектирования набора компонентов подсис-мы и наборов вариантов использования. На 1-х итерациях акцент следует делать на борьбе с рисками связанных с интерфейсами производительности, требованиями и удобством применения. На более поздних итерациях следует концентрироваться на полноте реализованного.

3.Спроектировать БД. Нужно доработать БД (добавить индексов, представления и не должно быть крупных переработок в БД). Это было бы признаком нестабильности архитектуры, т.е. признаков машин законченных на ранних стадиях.

4.Реализовать код и проводить модульное тестирование. Планирование итерации определяется тем, какие варианты использования и когда решено реализовать и тестировать. Реализация вариантов использования осуществляется по компонентам.

5.Проводить интеграцию и системное тестирование. При создании выпуска компонент интегрируется в порядке указанного в плане интеграции. Перед тем, как проводить полное тестирование проводиться минимальное интеграционное тестирование и этим занимается группа интеграции.

6.Раннее внедрение и обратная связь. Чтобы не выпускать продукт в неподготовленном виде необходимо: а) показать некоторым пользователям основные ключевые возможности системы. Б) привести несколько пользователей на место разработки или на тестовую площадку и понаблюдать за его работой с системой. В) предоставить некоторым пользователям ранний доступ к дистрибутивам приложения. Главным результатом раннего внедрения и обратной связи яв-ся сведения о том, верны ли требования, удобно ли или производительна ли программа и каких возможностей не хватает.

7.Подготовка к выпуску β-версии. Оно состоит из 2-х целей: а) тестируется контролируемая реальная реализация приложения. Б) обеспечивается предварительный просмотр готового продукта.

Рецензирование проекта. Вопросы данной контрольной точки: 1.явл-ся ли данный продукт стабильным и зрелым на столько что его можно предъявить сообществу пользователей. 2.Готовы ли все заинтересованные лица к передачи продукта сообществу пол-ей. 3.Приемлемо ли соотношение реальных и запланированных расходов.

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