Управление итерацией. Целью этой деятельности является получение достаточных для выполнения итерации ресурсов, разделение требуемых работ, оценка результатов итерации.
Завершение фазы. Выполняются работы, завершающие выполнение фазы. Даются ответы на следующие основные вопросы:
· Решены ли все основные проблемы предыдущей итерации?
· Известно ли состояние всех основных артефактов (см. ниже управление конфигурацией)?
· Рассмотрены ли все проблемы развертывания?
При удовлетворительном состоянии проекта выдается разрешение на переход к следующей фазе.
Завершение проекта. Руководитель проекта подготавливает проект к завершению. Готовится заключительная оценка состояния. При успешной сдаче проекта заказчик получает программный продукт в пользование. Высвобождающие ресурсы могут быть перераспределены (использованы в других проектах).
Управление конфигурацией и изменениями. Цели
Целью управления конфигурацией и изменениями является поддержание целостности артефактов с учетом возможности внесения в них изменений в соответствии с запросами на изменения. Этот вспомогательный процесс распространяется на весь жизненный цикл программного продукта и складывается из трех отдельных процессов.
Управление конфигурацией (Configuration management).
Процесс управления конфигурацией (УК) связан с определением артефактов, зависимостей между ними и конфигураций, являющихся непротиворечивыми множествами взаимосвязанных артефактов. Сюда же относятся вопросы распределения рабочих сред между участниками проекта с целью предотвращения ненужного дублирования документов. УК декларирует, что все артефакты подчиняются версионному управлению. По мере развития проекта у каждого артефакта появляются множество версий. Все они сохраняются в архиве проекта, причем ведется история изменений, в которой указывается причины и цели создания каждой версии каждого артефакта. Записанную в архив проекта версию нельзя изменить, можно лишь создать новую версию. Кроме того, знания о зависимостях между артефактами позволяют точно повторять действия при создании наборов артефактов (например, при сборке программы из отдельных файлов). Создание версий и связей поддерживается с помощью инструментальных средств УК.
УК позволяет:
· исключить возможность потери артефактов,
· обеспечить возможность «возврата назад» в случаях, когда принятые решения и полученные при их реализации версии артефактов не устраивают заказчика или разработчиков проекта,
· гарантировать точное повторение действий над группой связанных артефактов в итерациях,
· избегать дублирования артефактов и связанной с этим возможности привнесения дополнительных дефектов,
· поддерживать наблюдаемость хода выполнения работ по проекту путем предоставления нужной информации.
Управление внесением изменений
Деятельности этого процесса направлены на сбор и сохранение запросов на внесение изменений, поставляемых как участниками разработки ПС, так и внешними сторонами. Запросы на внесение изменений могут появляться по разным причинам (исправление дефекта, улучшение параметра качества продукта, например, производительности, задание дополнительных требований и т. д.) Каждый запрос на внесение изменений сохраняется в базе данных проекта и может находиться в разных состояниях в зависимости от хода выполнения работ по этому запросу (новый, зарегистрированный, принятый, завершенный и др.). Состояния запросов изменяются участниками проекта в соответствии с выделенными правами. По мере работы с запросом в него добавляется информация (например, сначала это может быть только описание дефекта, затем добавляется результаты анализа, указываются затрагиваемые артефакты, назначается исполнитель). С запросом может быть связан приоритет, позволяющий определить порядок выполнения работ по запросам на изменения.
Управление состоянием и измерениями
Этот процесс связан с управлением проектом и направлен на предоставление информации, полезной для оценки:
· Состояния, прогресса, общих тенденций и качества продукта;
· Издержек и расходов;
· Проблемных областей, требующих внимания;
· Того, что сделано и что необходимо сделать.
Вся необходимая информация находится в базе данных и архиве проекта. Руководитель работ оценивает состояние дел путем непосредственного просмотра запросов, истории версий артефактов или на основе анализа различных отчетов, формируемых инструментальным средством УК. Анализ позволяет руководителю оценить имеющиеся ресурсы и принять необходимые управленческие решения.
Деятельности
Планирование конфигурации проекта и управления изменениями. Описываются все виды деятельности, связанные с УК, которые надо выполнить. Описывается процесс контроля над изменениями.
Создание среды УК. Целью этой деятельности является создание рабочей среды, в которой будут доступны все артефакты, будет обеспечена разработка, интеграция и архивирование продукта.
Создание рабочей среды исполнителей. В пределах своей рабочей среды исполнитель получает доступ к артефактам проекта, имеет возможность вносить в них изменения и предлагать внесение изменений в проект в целом. Изменения, сделанные отдельными исполнителями, направляются в рабочую среду интеграции.
Управление версиями. При записи артефакта в архив проекта формируется его новая версия. Управление версиями предусматривает обязательное указание причин и целей создания версии. При выборе артефакта из архива можно указать конкретную версию.
Управление запросами на внесение изменений. Целью этой деятельности является обеспечение последовательного внесения изменений в проект и информирование о состоянии продукта, его изменениях и о влиянии изменений на стоимость и сроки выполнения проекта.
Наблюдение за состоянием конфигурации. Наблюдаемость процесса разработки обеспечивается путем доступа руководства проекта к хранимым артефактам и запросам на изменения, а также путем предоставления отчетов о состоянии конфигурации. При этом инструментальные средства, поддерживающие управление конфигурацией и изменениями, могут выполнять требуемые измерения. Например, можно показать процент завершенных запросов, число открытых запросов высокого приоритета и т. д.
Управление средой. Цели
Многие виды деятельностей, предусмотренные RUP, могут быть автоматизированы посредством инструментальных средств, что позволит избежать наиболее трудоемких, напряженных и подверженных ошибкам аспектов разработки ПС.
Цель процесса управления средой – процедурная и инструментальная поддержка организации, разрабатывающей ПС. Она включает:
· Выбор и приобретение инструментальных средств;
· Настройку инструментальных средств под требования организации-разработчика;
· Конфигурирование процесса;
· Усовершенствование процесса;
· Создание технических служб поддержки.
Роли и артефакты
Основным исполнителем процесса является технолог. В его обязанности входит конфигурирование процесса перед запуском проекта и усовершенствование процесса в ходе проектных работ. Поддержка аппаратной и программной среды разработки ложится на плечи системного администратора.
Главным создаваемым артефактом является план разработки, описывающий процесс, используемый в данном проекте. В нем указывается, какие артефакты, предусматриваемые в RUP, будут использоваться в проекте и каким образом.
Деятельности
Подготовка среды к реализации проекта. Выполняется оценка текущего состояния организации-разработчика и имеющейся инструментальной поддержки. Создается предварительный план разработки. Составляется перечень инструментальных средств, которые предполагается использовать при разработке. Составляется перечень шаблонов для производства основных артефактов.
Подготовка среды к итерации. Производится дополнение и уточнение плана разработки, выполняется подготовка и настройка инструментальных средств, которые будут использоваться в итерации. Составляется набор шаблонов для артефактов, создаваемых в итерации. Осуществляется подготовка сотрудников к использованию инструментальных средств.
Подготовка руководящих директив. Для каждого основного технологического процесса подготавливается набор директив на основе анализа проблем и дефектов предыдущих итераций.
Теперь, перечислим преимущества и недостатки компании-разработчика перед отдельным разработчиком.
Преимущества компании-разработчика перед отдельным разработчиком:
· Компания может "тянуть" большие и очень большие проекты. Отдельный же разработчик крупный проект может не осилить физически.
· В компании, как правило, работает группа людей с различным образованием, тем самым дополняя и развивая знания друг-друга. В компании-разработчике переплетаются знания людей различных школ. Отдельный же разработчик варится в своем соку. Основной источник знаний у него - книги и Интернет.
· Стандартизация исходного текста в компании значительно выше, чем у отдельного разработчика, т.к. в компании работает группа разработчиков.