Рубрики

Свежие записи

Управление конфигурациями в Rational Unified Process. Один из вариантов перевода

GD Star Rating
loading...
GD Star Rating
loading...




Данный материал представляет собой перевод Rational Unified Process в части описания дисциплины управления конфигурациями. Ранее я публиковал более укороченную запись, где приводил в качестве примера только основные концепции и роли.

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

К слову сказать, данный материал НЕ привязан к средствам автоматизации конфигурационного управления, так что его смело можно брать за основу при описании процессов организации, так как чем автоматизирован процесс — ClearCase, Subversion, CVS, PVCS, MS TFS — не важно.

Резюмируя: статья будет полезна всем, кто захочет оформить (формализовать, описать) процесс управления конфигурациями, взяв за основу Rational Unified Process. Кстати обратите внимание на логичность и стройность предлагаемого процесса, а для себя сделайте небольшое резюме: ведь по-крупному в RUP ничего нет принципиально нового  - все, что здесь описано и так применяется в организациях. Вопрос только объема и уровня формализации :)

Оглавление

Введение

Термины

см. глоссарий

Дисциплина «Управление конфигурацией и изменениями»

Перефразируя модель зрелости процессов Института программной инженерии (SEI CMM), можно сказать, что дисциплина Управление конфигурацией и изменениями контролирует изменения и обеспечивает взаимосвязь артефактов проекта.


Рисунок 1 Куб УК.

Дисциплина «Управление конфигурацией и изменениями» включает:

  • идентификацию объектов УК (ОУК);
  • ограничение возможности изменения ОУК;
  • аудит изменений, произведенных с ОУК;
  • определение конфигураций ОУК и управление этими конфигурациями.

Методы, процессы и инструментальные средства, используемые для поддержки дисциплины «Управление конфигурацией и изменениями» в организации, могут рассматриваться как Система УК организации.

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

Система УК — необходимая и неотъемлемая часть всего процесса разработки.

Цели

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

Одновременная модификация

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

Ограниченное уведомление

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

Многочисленные версии

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

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

Некоторые прямые выгоды системы УК:

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

Кроме того, система УК сохраняет детальную информацию по самому процессу разработки: кто создал конкретную версию (когда и почему), какая версия исходного кода использовалась при конкретной сборке продукта и другую подобную информацию.

Взаимодействие с другими дисциплинами

Система УК организации используется на протяжении всего жизненного цикла продукта — от фазы «Начало» до фазы «Передача». В качестве репозитория рабочих материалов организации, система УК содержит текущие и предшествующие версии исходных файлов и артефактов дисциплины «Требования», дисциплины «Анализ и проектирование» и дисциплины «Реализация», что определяет определенную версию системы или компонента системы.

Структура директорий продукта, представленная в системе УК, содержит все артефакты, требуемые для разработки продукта. Таким образом, дисциплина «Управление конфигурацией и изменениями» связанна со всеми другими дисциплинами и обеспечивает сохранение в репозитории всех артефактов, получаемых в результате выполнения этих процессов.

Процесс

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

На рисунке 6.1 представлена диаграмма действий процесса УКИ.


Рисунок 2 Диаграмма действий процесса УКИ.

Первые две работы (Планирование проектной конфигурации и контроля изменений, и Создание проектной среды УК) выполняются в начале проекта. Остальные в течении жизненного цикла проекта.

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

Работы

Роли

Задачи

Артефакты

Входящие

Исходящие

Планирование проектной конфигурации и контроля изменений

Менеджер конфигурации

Ввод в действие правил УК

План создания продукта

План УК

Прецедент разработки

План УК

Создание плана УК

План создания продукта

План УК

Прецедент разработки

Менеджер изменений

Ввод в действие процесса контроля изменений

План УК

План УК

План создания продукта

Прецедент разработки

Инфраструктура разработки

Создание среды проектного УК

Менеджер конфигурации

Развертывание среды УК

План УК

Репозиторий проекта

План создания продукта

Прецедент разработки

Инфраструктура разработки

Модель реализации

План итерации

Интегратор

Создание интеграционных рабочих пространств

Репозиторий проекта

Рабочее пространство

Прецедент разработки

Проектные руководства

Управление базовыми версиями и релизами

Менеджер конфигурации

Создание инсталляционного пакета

Список версий компонент релиза

Инсталляционный пакет

Сборка

Модель развертывания системы

План развертывания

Документация поддержки пользователя

Инсталляционные артефакты

Репозиторий проекта

Описание релиза

Учебные материалы

Интегратор

Создание базовых версий

Репозиторий проекта

Рабочее пространство

Проектные руководства

План разработки продукта

Поручение

Рабочее пространство

Продвижение базовых версий системы

Рабочее пространство

Рабочее пространство

Репозиторий проекта»

Репозиторий проекта

План разработки продукта

Рабочее пространство

Репозиторий проекта»

Проектные руководства

Изменения и передача объектов УК

Участник проекта

Создание рабочего пространства разработки

нет

Рабочее пространство

Внесение изменений

Поручение

Рабочее пространство

Рабочее пространство

Передача изменений

Рабочее пространство

Рабочее пространство

Репозиторий проекта

Обновление рабочего пространства

Репозиторий проекта

Рабочее пространство

Рабочее пространство

Интегратор

Создание базовых версий

см. выше

см. выше

Продвижение базовых версий

см. выше

см. выше

Мониторинг и отчетность по состоянию конфигурации

Менеджер конфигурации

Формирование отчета о состоянии конфигурации

План УК

Данные о состоянии проекта

Репозиторий проекта

Аудит конфигурации системы

План УК

Результаты аудита конфигурации

Репозиторий проекта

Управление запросами на изменение

Участник проекта

Внесение запроса на изменение

Нет

Запрос на изменение

Модификация запроса на изменение

Запрос на изменение

Запрос на изменение

Менеджер изменений

Рецензирование запроса на изменение

Запрос на изменение

Запрос на изменение

Подтверждение состояния Отклонено или Дубликат для запроса на изменение

Запрос на изменение

Запрос на изменение

Аналитик тестирования

Верификация изменений в собранном релизе

Запрос на изменение

Запрос на изменение

Сборка

Результаты тестирования

Журнал тестирования

Менеджер проекта

Распределение работ

см. дисциплину «Управление проектом»

см. дисциплину «Управление проектом»

Концепции

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

Концепция «Управление конфигурацией и запросами на изменение»

Данная концепция описывает границы и процессы управления конфигурацией и запросами на изменение.

Ниже перечислены главные аспекты системы УК:

  • управление запросами на изменение (УЗИ);
  • отчет о статусе конфигурации;
  • управление конфигурацией (УК);
  • отслеживание изменений;
  • выбор версии;
  • производство программного обеспечения.

На рисунке 3 отражены главные аспекты Системы УК.


Рисунок 3 Куб УК

Управление запросами на изменение (УЗИ)

Требует от инфраструктуры организации оценки стоимости и графика работ, связанных с изменениями, оценки влияния требуемого изменения на существующий продукт. Управление артефактами Запрос на изменение относится к работе ГРИ или ГКИ.

Учет конфигурационного статуса (результаты измерений)

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

Управление конфигурацией (УК)

Описывает структуру продукта и определяет его составляющие, которые являются версионными сущностями в процессе УК. Цель УК — определение конфигурации, сборка и проставление меток, а также объединение версионных сущностей в структурные составляющие, по которым отслеживаются изменения от версии к версии.

Отслеживание изменений

Описывает, что было сделано с компонентами, по какой причине, и когда. Он служит как история и объяснение изменений. Это отличается от оценки влияния предполагаемых изменений, как описано в УЗИ.

Выбор версий

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

Выбор версии основывается на «конфигурационной идентификации».

Производство программного обеспечения

При производстве программного обеспечение необходима автоматизация этапов компиляции, тестирования и изготовления программного обеспечения для распространения.

RUP описывает всеобъемлющую Систему УК, которая охватывает все аспекты УК. Эффективным процессом УК может являться процесс, который:

  • встроен в процесс разработки программного обеспечения;
  • помогает управлять развитием продуктов по разработке программного обеспечения;
  • позволяет разработчикам выполнять задания УК с минимальным вовлечением в процесс разработки.

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

Другой целью процесса УК является гарантия того, что уровень управления за каждым из артефактов, основан на уровне завершенности продукта. По мере завершения продукта, авторизация изменений переходит от Исполнителя к Интегратору подсистем или систем, затем к Менеджеру проекта и окончательно к заказчику.

Для большей эффективности проекта важно гарантировать, что руководители, связанные с процессом УЗИ, понимают границы завершенности продукта.

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

Концепция «Рабочее пространство»

Рабочее пространство (РП)- это личная область содержащая код над, которым работает данный разработчик в относительной изоляции от других разработчиков и в соответствии со стандартами принятыми в проекте.

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

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

РП каждого разработчика должно быть изолировано для редактирования, компилирования, тестирования и отладки. Однако, изоляция рабочего пространства должна быть относительна, а не абсолютна:

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

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

РП может быть абсолютно закрытым для отдельного разработчика, или разделенным среди коллектива разработчиков по сети.

В дополнение к предоставлению доступа к исходным версиям, РП должно предоставлять изолированное хранилище для файлов созданных во время периода разработки:

  • рабочие (взятые из под контроля) версии файлов;
  • исполняемые файлы;
  • другие закрытые объекты рабочего пространства – код, директории с тестами, файлы с тестовыми данными.

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

На рисунке 4 представлен Куб УК с точки зрения концепции «Рабочее пространство».


Рисунок 4 Куб УК с точки зрения рабочих пространств.

Рабочие конфигурации

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

Представления

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

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

РП, иногда также называемое представлением, позволяет разработчикам проводить и тестировать изменения закрыто от других членов коллектива разработчиков, перед тем как эти изменения станут им доступными.

Существуют два типа представлений:

  • статическое представление;
  • динамическое представление.

Статические представления обеспечивают разработчику стабильную и не изменяющуюся рабочую среду аналогично дереву директорий на жестком диске. Статическое представление заполняется копиями соответствующих версий файлов из одного или нескольких репозиториев проекта. Некоторые люди используют термин «песочница» для такого дерева директорий. Когда разработчик захочет посмотреть на изменения сделанные другими членами команды, он обновляет своё представление. Этот стиль работы характеризуется как модель активного опроса сообщений, т.к. он предполагает активное перемещение необходимой информации, в отличие от мгновенного обновления информации через автоматические механизмы обновления.

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

  • дисковое пространство на клиентском месте ограничено;
  • вы хотите получить преимущество от разделения объектов;
  • коллектив разработчиков должен работать с последними версиями кода. Это свойство особенно полезно для интеграции, которая требует новейших версий данного ПО.

    Концепция «Интеграционные рабочие пространства (ИРП) и рабочие пространства разработки (РПР)»

Системы обычно разрабатываться командами разработчиков работающих вместе и параллельно. Для того чтобы это было возможным необходимы следующие рабочие пространства:

  • РПР для каждого Исполнителя;
  • ИРП подсистемы для команды;
  • ИРП уровня системы для Интегратора.

    РПР

Исполнитель разрабатывает подсистемы и их компоненты в личном рабочем пространстве. Однако для компиляции, линковки, запуска и тестирования кода одной подсистемы необходимы части остальных подсистем. Так как Исполнитель не нуждается в полном коде всей системы, то другие подсистемы физически не присутствуют в его личном РП. Поэтому внутренние релизы всех подсистем находятся в общем репозитории. В случае необходимости Исполнитель указывает в отдельном файле типа «makefile» путь к данным подсистемам.


Рисунок 5 РПР

ИРП для команды

Иногда подсистему разрабатывает команда Исполнителей. В данном случае Исполнители должны провести интеграцию своих элементов в подсистему перед интеграцией полной системы. Такие интеграции производятся в ИРП для команды. В данном случае роль Интегратора выполняет один из членов команды.

ИРП уровня системы для Интеграторов

Интеграторы системы могут добавлять в ИРП элементы системы или подсистемы инкрементально.


Рисунок 6 ИРП уровня системы, в котором подсистемы добавлялись инкрементально

Концепция «Управление запросами на изменение»

Управление запросами на изменение — это процесс, который стандартизирует методы и процедуры используемые для эффективной и быстрой обработки всех изменений, с целью минимизации расходов связанных с изменениями продукта.

Запрос на изменение

Запрос на изменение (ЗИ) — формально описанный артефакт, используемый для отслеживания всех запросов заинтересованных в разработке лиц (включая новые функции, расширенные запросы, ошибки, измененные требования и т.п.), с информацией о статусе запроса в течение всего жизненного цикла проекта. Вся история изменений поддерживается с помощью ЗИ, включая все изменения состояний с датами и причинами изменений. Эта информация будет доступна для любых рецензирований и окончательного закрытия.

Группа контроля изменений

Группа контроля изменений (ГКИ) – коллектив, который наблюдает за процессом изменений и состоит из представителей всех заинтересованных групп, включая заказчиков, разработчиков и пользователей. В небольшом проекте эту роль может играть один член коллектива, как, например, Менеджер проекта или Архитектор системы. В RUP эта роль называется Менеджер изменений.

Совещание ГКИ

Совещание ГКИ по пересмотру – смысл этого совещания заключается в просмотре зарегестрированных
ЗИ. На совещании определяется обоснованность ЗИ. В случае если запрос обоснован, производится определение принадлежности изменения к текущей или другой версии. Определение основывается на приоритете, графике, ресурсах, уровне усилий, риске, серьезности и любого другого критерия определенного коллективом. Обычно такое совещание происходит раз в неделю. Если объем ЗИ существенно увеличивается, или приближается выпуск версии, совещания могут происходить ежедневно. Обычно во время Совещаний ГКИ обязательными его членами являются Менеджер тестирования, Менеджер разработки и представитель маркетингового отдела. Остальные участники приглашаются на встречу по мере необходимости.

Форма регистрации запроса на изменение

Эта форма появляется, ЗИ впервые регистрируется. На форме отображаются только те поля, которые необходимо заполнить регистратору запроса.

Объединенная форма регистрации запроса на изменение

Эта форма отображается, когда ЗИ, который уже был зарегистрирован, пересматривается. Она содержит все необходимые для описания ЗИ поля.

Этап работ, связанный с артефактами ЗИ, описан в задаче «Ввод в действие процесса контроля изменений». Однако следующая модель описывает состояния ЗИ при движении через все этапы работ, и показывает кто уведомляется об изменениях артефакта во время жизненного цикла.

Пример диаграммы действий для ЗИ.


Рисунок 7 Пример диаграммы действий для ЗИ

Описание действий:

Действие

Описание

Ответственность

Регистрация ЗИ

Любое заинтересованное в разработке проекта лицо может зарегистрировать ЗИ. ЗИ регистрируется в системе отслеживания ЗИ (например, Rational ClearQuest) и помещается в очередь просмотра ГКИ, путем установки состояния запроса на изменение как Зарегистрированный.

Регистратор

Пересмотр ЗИ

Цель этой деятельности заключается в пересмотре представленных ЗИ. Начальный пересмотр содержимого ЗИ осуществляется на Совещании ГКИ для определения обоснованности запроса. В случае если запрос обоснован, производится определение принадлежности изменения к области текущей версии. Определение основывается на приоритете, графике, ресурсах, уровне усилий, риске, серьезности и любого другого критерия определенного группой.

ГКИ

Подтверждение дублирования или отклонение.

Если подозревается, что ЗИ является дубликатом или отклоняется как неправильный запрос (например, ошибка оператора, невоспроизводимость, того, как он работает и т.п.), то назначается член ГКИ для подтверждения Дублирования запроса или его отклонения и для сбора информации при регистрации, если это требуется.

Член ГКИ

Обновление ЗИ

Если требуется дополнительная информация для оценки ЗИ, или если ЗИ отклоняется на любом этапе процесса (например, как дубликат, отклоненный, и т.п.), уведомляется регистратор, который может обновить ЗИ новой информацией. Обновленный ЗИ перерегистрируется в очередь просмотра ГКИ для рассмотрения новых данных.

Регистратор

Назначение и планирование работ

Как только ЗИ открыт, Менеджер проекта назначает работу соответствующему члену коллектива разработчика, в зависимости от типа запроса (например, расширенный запрос, дефект, изменения документации, дефект теста и т.п.) – и делает все необходимые обновления в графике проекта.

Менеджер проекта

Выполнение изменений

Назначенный работник выполняет ряд работ, определенных внутри соответствующего этапа разработки ПО (например, этапа определения требований, анализа и проектирования, реализации, производства документации пользователя, проектирования теста и т.п.) запрошенных изменений. Эти работы включают весь обычный спектр работ и тестирование компонент в соответствии с методологией разработки ПО. После этого ЗИ помечается как разрешенный.

Назначенный член команды разработчиков

Проверка изменений в тестовой сборке

После выполнения изменений выбранным работником из коллектива разработчиков (Системным
аналитиком, Исполнителем, Тестировщиком, Техническим писателем и т.п.) изменения помещаются в очередь на тестирование, что бы быть назначенными Тестировщику и проверенными при отладочной сборке продукта.

Тестировщик

Проверка изменений в релизной сборке

Когда разрешенные изменения будут проверены при отладочной сборке продукта, ЗИ помещают в очередь версии для проверки при сборке релиза продукта, для формирования заметок к версии и т.п. и Закрытия ЗИ.

Член ГКИ (Интегратор системы)

Пример диаграммы состояний для ЗИ

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


Рисунок 8 Диаграмма состояний PB

Описание состояний ЗИ:

Состояние

Определение

Управление доступом

Зарегистрирован

Это состояние появляется как результат следующей деятельности:

  • регистрации нового ЗИ;
  • обновления существующего ЗИ;
  • рассмотрения отложенного ЗИ для новой версии.

ЗИ помещается в очередь просмотра ГКИ. В результате этого действия запросу не назначается владелец.

Все пользователи

Отложен

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

Администратор ГКИ

Менеджер проекта

Дублирован

В этот состоянии ЗИ считается повторением другого ЗИ, который уже был зарегистрирован. ЗИ могут быть переведены в это состояние администратором ГКИ или членом коллектива, назначенным для его разрешения. Когда ЗИ переводится в состояние дублирован, лицо сформировавшее этот запрос будет запомнено ( в таблице Attachments в ClearQuest). Регистратор с самого начала должен запросить базу данных ЗИ на наличие дублированных запросов, прежде чем регистрировать ЗИ. Это существенно сократит время при работе с ЗИ. Регистраторы, которые регистрирую Дублирующие
ЗИ, должны быть занесены в лист извещений первоначального ЗИ для будущего их уведомления относительно резолюций.

Администратор ГКИ

Менеджер проекта

QE Manager

Разработчики

Отклонен

ЗИ в этом состоянии определяется на совещании ГКИ или назначенным лицом на предмет: запрос обоснован или требуется более детальная информация от регистратора. Если ЗИ уже открыт, то он удаляется из очереди запросов с резолюциями и в дальнейшем снова будет пересмотрен.

Для этого назначается член ГКИ. От регистратора не требуется предпринимать какие-либо действия без крайней необходимости, в этом случае состояние ЗИ переводится в состояние Дополнительная информация. ЗИ будет снова пересмотрен на совещании ГКИ при появлении новой информации. Если подтверждается неправильность запроса, то он переводится ГКИ в состояние Закрыт и регистратор извещается о его закрытии.

Администратор ГКИ

Менеджер проекта

Менеджер разработки

Менеджер тестирования

Дополнительная информация

Существует недостаточно данных для подтверждения обоснованности отклонения или дублирования ЗИ.

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

Администратор ГКИ

Открыт

В этом состоянии ЗИ относится к текущей версии и ждет своего разрешения. ЗИ заносится в список резолюций. ЗИ определяется как назначенный в очередь. Члены совещания – единственные кто может открыть ЗИ в очереди резолюций. Если обнаружены более приоритетные ЗИ, об этом немедленно следует извести руководителя QE или разработки. В этом случае они могут решить собраться на экстренную встречу ГКИ или немедленно открыть ЗИ в очереди резолюций.

Администратор ГКИ

Менеджер проекта

Менеджер разработки

QE Department

Назначен

За Открытий
ЗИ отвечает Менеджер проекта. Он назначает работников в соответствие с типом запроса и изменяет график работ и прочее.

Менеджер проекта

Разрешен

Означает, что разрешение этого ЗИ завершено и сейчас ЗИ готов для проверки. Если регистратор был членом отдела QE, то владелец автоматически изменяется на члена QE зарегистрировавшего ЗИ; иначе владелец меняется на Руководителя QE для переназначения.

Администратор ГКИ

Менеджер проекта

Менеджер разработки

QE Manager

Отдел разработчиков

Не прошел тестирование

В данное состояние переводится ЗИ не прошедший тест или в отладочной сборке или в сборке версии. Владелец ЗИ автоматически изменяется на члена коллектива, который разрешил ЗИ.

Администратор ГКИ

QE Department

Проверен

В этом состоянии ЗИ уже был проверен в отладочной сборке и готов для включения в версию.

Администратор ГКИ

QE Department

Закрыт

ЗИ больше не принимается во внимание. Это заключительное состояние, в которое может перейти ЗИ. Только Администратор ГКИ имеет право закрыть ЗИ. Когда ЗИ
Закрыт, регистратор получит уведомление по электронной почте с окончательным состоянием ЗИ. ЗИ Закрывают в следующих случаях:

  • после того, как проверенное разрешение утверждается при сборке версии;
  • в случае Отклонения
    ЗИ;
  • в случае когда ЗИ рассматривается как Дубликат уже существующего ЗИ.

В письме регистратор уведомляется о Дубликате
ЗИ и добавляется к этому ЗИ для будущих уведомлений (см. определения состояний Отклонение и Дублирован). Если регистратор желает оспорить закрытие ЗИ, ЗИ должен быть обновлен и перерегистрирован ГКИ.

Администратор ГКИ

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


Рисунок 9 Куб УК в контексте ЗИ.

Концепция «Unified change management»

Unified change management (UCM) –метод Rational Software для управления изменениями в системе разработки ПО, от требований к релизу. UCM охватывает жизненный цикл разработки, определяя как управлять ЗИ, проектировать модели, документацию, компоненты, тестовые примеры и исходный код.

Одним из основных аспектов модели UCM является то, что она унифицирует деятельности, используемые для планирования и просмотра состояния проекта и артефактов, подверженных изменению. Модель UCM реализована через процесс и инструментарий. Продукты Rational ClearCase и Rational ClearQuest являются основной технологической поддержкой UCM. ClearCase управляет всеми артефактами создаваемыми в проекте по разработке ПО, включая как системные артефакты, и артефакты проекта. ClearQuest управляет заданиями проекта, дефектами и требованиями для расширений (в основном относящихся к деятельностям) и предоставляет средства по созданию отчетов и диаграмм, необходимых для отслеживания состояния проекта.

Концепция «Отчет по статусу конфигурации»

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

Учет конфигурационного статуса (Configuration Status Accounting) – используется для описания «состояния» продукта основанного на типе, числе, частоте появления и серьезности найденных и зафиксированных ошибок во время разработки продукта. Полученные метрики являются полезными при определении состояния завершенности проекта.

Существует четыре принципиальных источника для отчетов по конфигурационному статусу ПО:

  • ЗИ;
  • Сборки;
  • Описания версий;
  • аудиты.

Отчеты по ЗИ

Имена состояний являются базой для отчета по статистике ЗИ (старение, распределение или тенденция) как описано на соответствующих этапах процесса управления запросами на изменение.

Отчеты, основанные на ЗИ, могут быть разнесены по следующим категориям:

Старение (Отчеты по времени)

Как долго различные ЗИ были открыты? Какова задержка между нахождением дефектов в версии и их исправлением?

Распределение запросов по категориям (Численные отчеты)

Число запросов в категориях: по владельцу, приоритету, состоянию исправлены?

Тренд (Отчеты по времени и количеству)

Каково общее число дефектов найденных и исправленных за все время? Какова частота обнаружения и исправления дефектов? Каков «качественный промежуток» в терминах обнаруженных дефектов против исправленных? Каково среднее время исправления дефекта?


Рисунок 10 Куб УК в разрезе отчетов по ЗИ

Отчеты по Сборкам

Отчеты по Сборкам включают список всех файлов, их местоположение, включенные в сборку изменения для конкретной версии ПО.

Отчеты по Сборкам могут поддерживаться как на системном так и на уровне подсистемы.

Отчеты по Описанию версий

Описания версии – артефакт определяющий детали версии ПО. Как минимум в это описание должно быть включено следующее:

  • носитель версии (физический носитель, документы);
  • носитель содержимого по (листинги файлов);
  • все уникальные данные;
  • инструкции по инсталляции;
  • возможные проблемы и известные ошибки.

Аудиты

Существует два вида ревизий применяемых в УК:

  • аудит физической конфигурации;
  • аудит функциональной конфигурации.

Ревизия физической конфигурации определяет составляющие продукта развернутого в репозитории проекта.

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

Концепция «Структура директорий продукта»

Структура директорий продукта (СДП) — служит логически разделенным хранилищем для всех относящихся к продукту версий артефактов. Артефакты появляются в результате жизненного цикла процесса разработки, и разрабатываются для каждой составляющей части (компонента) всей системы.

На рисунке 11 показано, что Система «Х» состоит из «N» подсистем. Каждая подсистема, в свою очередь, состоит из «N» компонентов. СДП предоставляет общее хранилище для различных артефактов, которые необходимы для разработки каждой части всей системы.


Рисунок 11 Структура системы

В RUP артефакты сгруппированы и описаны в терминах дисциплин:

  • дисциплина Бизнес моделирование;
  • дисциплина Требования;
  • дисциплина Анализ и проектирование;
  • дисциплина Реализация;
  • дисциплина Тестирование;
  • дисциплина Внедрение;
  • дисциплина Управление конфигурацией и изменениями;
  • дисциплина Управление
    проектом;
  • дисциплина Среда.

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

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

СДП уровня системы

Хотя опытный проектировщик ПО имеет представление относительно структуры системы, основные компоненты ее появляются как результат деятельности в дисциплине Анализ и проектирование, которые затем уточняются.

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

System Requirements

Системные требования.

Models

Модели

Use-Case Model

Модель прецедентов

Use-Case Package

Пакет прецедентов

User Interface Prototype

Прототип пользовательского интерфейса

Database

База Данных.

Requirements Attributes

Атрибуты требований

Documents

Документы

Vision

Концепция

Glossary

Глоссарий

Stakeholder Requests

Запросы заинтересованных лиц

Supplementary Specifications

Дополнительные спецификации

Software Requirement Specs

Спецификации программных требований

Reports

Отчеты

Use-Case Model Survey

Обзор модели прецедентов

Use-Case Report

Отчет по прецедентам

System Design and Implementation

Системное проектирование и реализация

Models

Модели

Analysis Model

Модель стадии анализа

Use-Case Realization

Реализация прецедентов

Design Model

Модель стадии проектирования

Design Subsystem

Проектирование подсистемы

Interface

Интерфейс

Test Package

Пакет тестов

Data Model

Модель Данных

Workload Analysis Document

Документ: Анализ Рабочей загрузки

Documents

Документы

Software Architecture Document

Документ: Архитектура программного обеспечения

Design Model Survey

Обзор модели стадии проектирования

Subsystem-1

Подсистема-1

Subsystem Directory Structure

Структура директории подсистемы 1

Subsystem-N

Подсистема-N

Subsystem Directory Structure

Структура подсистемы N

System Integration

Системная интеграция

Plans

Планы

Integration Build Plan

План интеграции

Libraries

Библиотеки

System Test

Системный тест

Test Plan

План тестирования

Test Cases

Примеры Тестов

Test Procedures

Тестовые Процедуры

Test Data

Данные Теста

Test Results

Результаты Теста

System Deployment

Внедрение Системы

Deployment Plan

План внедрения

Documents

Документация

Release Notes

Примечания к версии

Manuals

Руководство пользователя

End User Support Material

Материал для конечного пользователя

Training Materials

Обучающие материалы

Installation Artifacts

Инсталляционные данные

System Management

Управление Системой

Plans

Планы

Software Development Plan

План разработки ПО

Iteration Plan

План Итераций

Requirements Management Plan

План управления требованиями

Risk List

Лист рисков

Risk Management Plan

План управления рисками

Development Case

Условия разработки

Infrastructure Plan

План инфраструктуры

Product Acceptance Plan

План принятия продукта

Configuration Management Plan

План управления конфигурацией

Documentation Plan

План документации

QA Plan

QA план

Problem Resolution Plan

План разрешения проблем

Subcontractor Management Plan

План управления подрядчиками

Process Improvement Plan

План усовершенствования процессом разработки

Measurement Plan

План измерений

Assessments

Оценки

Iteration Assessment

Оценка итераций

Development Organization Assessment

Оценка организации разработки

Status Assessment

Оценка Статуса

Tools

Инструментарий

Development

Environment Tools

Инструментарий разработки среды

Editors

Редакторы

Compilers

Компиляторы

Configuration Management Tools

Инструментарий управления конфигурацией

Rational ClearCase

Средство УК

Requirements Management Tools

Инструментарий управления требованиями

Rational RequisitePro

Visual Modeling Tools

Инструментарий визуального моделирования

Rational Rose

Средство моделирования

Test Tools

Инструментарий тестирования

Rational Test Factory

Средство тестирования

Defect Tracking

Отслеживание дефектов

Rational ClearQuest

Средство управления артефактами «Запрос на изменение»

Standards & Guidelines

Стандарты и рекомендации

Requirements

Требования

Requirements Attributes

Атрибуты требований

Use-Case Modeling Guidelines

Рекомендации по моделированию функций

User Interface

Пользовательский интерфейс

Design

Проектирование

Design Guidelines

Рекомендации по проектированию

Implementation

Реализация

Programming Guidelines

Рекомендации по реализации

Documentation

Документация

Manual Style guide

Руководство

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

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

СДП уровня подсистем

Информация в СДП уровня подсистемы относится непосредственно к разработке определенной подсистемы. Количество «реализаций» СДП уровня подсистемы напрямую связано с количеством подсистем полученных в результате работ в дисциплине Анализ и проектирование.

Обобщенный вид СДП уровня подсистемы имеет следующий вид:

Subsystem-N Requirements

Требования к Системе-N

Models

Модели

Use-Case Model

Функциональная модель

Use-Case Package

Пакет функций

Use-Case Storyboard

Функции пользовательского интерфейса

Use-Case (text)

Текст функций

User Interface Prototype

Прототип Пользовательского Интерфейса

Database

База данных

Requirements Attributes

Атрибуты Требований

Documents

Документация

Vision

Перспективы развития

Glossary

Глоссарий

Stakeholder Requests

Запросы заинтересованных лиц

Supplementary Specifications

Дополнительные Спецификации

Software Requirement Specs

Спецификации на Требования к ПО

Reports

Отчеты

Use-Case Model Survey

Обзор Функциональной модели

Use-Case Report

Отчет по функциям системы

Subsystem-N Design and Implementation

Проектирование и реализация Подсистемы-N

Models

Модели

Analysis Model

Модель стадии анализа

Use Case Realization

Реализация функций

Subsystem Design Model

Модель стадии проектирования

Design Packages

Пакеты модели проектирования

Interface Packages

Интерфейсные Пакеты

Test Packages

Пакеты тестов

Implementation Model

Модель этапа Реализации

Data Model

Модель Данных

Workload Model

Рабочая Модель

Documents

Документация

Software Architecture Document

Документ: Архитектуры ПО

Workload Model

Рабочая Модель

Reports

Отчеты

Use-Case Realization Report

Отчет о Реализации функций

Component-1

Компонент-1

Component-1 Directory

Директория Компонента-1

Component-N

Компонент-N

Component-N Directory

Директория Компонента-N

Subsystem-N Integration

Интеграция Подсистемы-N

Plans

Планы

Subsystem Integration Build Plan

План интегрирования подсистемы

Libraries

Библиотеки

Subsystem-N Test

Отладка Подсистемы-N

Test Plan

План Тестирования

Test Cases

Примеры тестов

Test Procedures

Тестовые Процедуры

Test Results

Результаты Тестирования

Test Data

Данные Тестирования

СДП уровня компонента

Количество компонентов является результатом решений при проектировании подсистемы. Для каждого разработанного компонента можно использовать следующую СДП уровня компонента.

Component

Компонент

Source Code

Исходный Код

Object/Executable Code

Объектный/Исполняемый Код

Interfaces

Интерфейсы

Test Code

Отладочный Код

Executable Test Scripts

Исполняемые отладочные скрипты

Test Data

Тестовые Данные

Test Results

Результаты тестов

Одним из преимуществ группировки директорий, описанным выше способом, является представление информации в контексте разрабатываемой компоненты, как на текущем уровне, так и на уровне выше.

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

Концепция «Метод продвижения»

Метод продвижения определяет как информация о продукте связанна с уровнем продвижения, а также устанавливает набор разрешений для доступа и утверждения.

По мере выполнения проекта качество и стабильность базовой версии улучшаются. Уровень продвижения
(УП) – это атрибут базовой версии, который используется для оценки ее качества или стабильности. Атрибуты и уровни базовой версии могут быть определены в проекте, однако, некоторые примерные уровни продвижения таковы:

  • протестированная интеграция;
  • протестированная система;
  • протестированное принятие;
  • производство.

Уровни определены для отражения прогресса от низшего до высшего качества. Действие изменения уровня продвижения базовой версии называют продвижением или понижением базовой версии.

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

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

Концепция «Определение базовых версий»

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

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

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

Воспроизводимость

Возможность вернуться во времени и воспроизвести данную версию системы ПО или воспроизвести предшествующую среду разработки.

Трассируемость

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

Отчет

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

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

Существует несколько преимуществ при создании базовых версий:

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

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

Базовую версию следует делать в конце каждой итерации (вспомогательная веха) и в конце каждой фазы жизненного цикла проекта.

  • Lifecycle Objectives Milestone (фаза Начало) – веха после начальной фазы или контрольная точка целей жизненного цикла;
  • Lifecycle Architecture Milestone (фаза Развитие) – веха после фазы уточнения требований или контрольная точка архитектуры жизненного цикла;
  • Initial Operational Capability Milestone (фаза Конструирование) — фаза после фазы детального проектирования или контрольная точка начальных функций;
  • Product Release Milestone (фаза Передача) — веха после фазы внедрения или контрольная точка версии продукта;

Роли

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

Роль обычно выполняет один работник, или группа людей работающая как команда. Член проектной команды обычно выполняет несколько ролей. Учтите что Роль это не человек и не всегда соответствует должностям, Роли описывают сколько работников требуется в проекте и ответственности этих работников. Назначение ролей производится Менеджером проекта при планировании работ.

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

Роль «Менеджер конфигурации»

Менеджер конфигурации занимается полным обеспечением инфраструктуры УК и среды для разработки продукта. Функция УК поддерживает задачу разработки продукта, с тем чтобы разработчики и Интегратор имели соответствующие рабочие пространства для выполнения и тестирования своей работы, и для того, чтобы все артефакты были доступны для включения должным образом в инсталляционный пакет. Менеджер конфигурации должен следить за тем, чтобы среда УК облегчала рецензирование продукта и задачи изменения и отслеживания дефектов. Также в обязанности Менеджера конфигурации входит написание Плана УК и формирование статистического отчета о состоянии работ на основании запросов на изменение.

На рисунке 12 представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.


Рисунок 12 Задачи и артефакты

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

Несколько примеров, как назначать на данную роль:

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

Роль «Менеджер контроля изменений»

В обязанности Менеджера контроля изменений входит наблюдение за процессом УИ. Эту роль обычно исполняет ГКИ, состоящая из представителей всех заинтересованных сторон, включая заказчиков, разработчиков, и пользователей. В маленьких проектах, эту роль может играть один член команды, например, Менеджер проекта или Архитектор.

Менеджер контроля изменений также занимается определением процесса УЗИ, который формализован в План УК.

На рисунке 3.2 представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.


Рисунок 13 Задачи и артефакты

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

Роль «Интегратор»

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

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


Рисунок 14 Задачи и артефакты

От сотрудника выполняющего эту роль требуется:

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

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

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

Роль «Участник проекта»

Участник проекта в RUP, обладая правами доступа, может регистрировать и проверять в системе УК любой связанный с продуктом артефакт поддержки. Он также может представлять на рассмотрение ЗИ и делать исправления в своих ЗИ.

На рисунке 3.4 представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.


Рисунок 15 Задачи и артефакты

Участник проекта может выполнять любой член проектной команды назначенный хотя бы на одну из ролей RUP.Соответственно требования к сотруднику определяться назначенной ролью, а также знанием задач выполняемых ролью Участник проекта.

Роль Участник проекта выполняется всеми членами проектной команды. Поэтому назначение данной роли происходит по умолчанию.

Артефакты

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

  • документ, например, План УК проекта или документ Архитектура системы;
  • модель, например, Модель реализации;
  • элемент модели, т.е. элемент внутри модели, например, класс или подсистема.

Артефакт «План УК»

План УК описывает все задачи дисциплины Управление конфигурацией и изменениями, которые будут выполняться в течение жизненного цикла проекта или программного продукта. Он детально описывает расписание задач, распределение полномочий и требуемые ресурсы (включая персонал, инструментальные средства и компьютерное обеспечение).

Цель Плана УК — определить или указать шаги и задачи, которые описывают, как дисциплина Управление конфигурацией и изменениями реализуется при разработке программного продукта.

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

Менеджер конфигурации отвечает за полноту Плана УК и должен обеспечить, чтобы были указаны:

  • выполняемые задачи;
  • расписание выполнения задач;
  • распределение ответственности;
  • требуемые ресурсы (персонал, инструментальные средства, среда разработки и инфраструктура).

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

  • просто ссылаться на содержание других документов;
  • раскрыть детали в этом плане и представить краткий обзор в других планах. Могут быть полезны ссылки на План УК из других планов. Это часто хорошо работает в больших проектах с отдельным подразделением, ответственным за УК;
  • подобрать разделы документа так, чтобы они описывали те области, которые не упоминаются где-либо еще.

Ниже представлены разделы План УК и соответствующие им артефакты, в которых может содержаться сходная информация:

Раздел плана управления требованиями

Сходный по содержанию артефакт

Определения, акронимы и аббревиатуры

Словарь проекта

Организация работ, распределение ответственности и интерфейсы

План разработки продукта

Инструментальные средства, поддержка среды разработки и инфраструктура

Прецедент разработки

План разработки продукта

План инфраструктуры

Проведение аудита и отчетность

Прецедент разработки

План контроля метрик проекта,

План обеспечения качества

Этапы

План разработки продукта

План итерации

Обучение и ресурсы

План разработки продукта

Кроме того, УК требованиями может быть частично или полностью раскрыто в Плане управления требованиями.

Артефакт «Репозиторий проекта»

Репозиторий проекта хранит все версии файлов и директорий проекта. Он также хранит все производные данные и метаданные, ассоциированные с файлами и директориями.

Репозиторий проекта хранит все файлы и директории, находящиеся под управлением инструментальных средств УК проекта. Репозиторий проекта является глобальным ресурсом, который должен быть доступен для большинства «клиентских мест» проекта.

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

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

Ключевые характеристики оборудования (в порядке приоритета) для репозитория проекта:

Требования к памяти

Память — один из наиболее дешевых вариантов повышения производительности инструментария УК. Эмпирическое правило определения требуемого для сервера объема памяти — полный объем базы данных репозитория проекта, деленный на 2. Например, 1MB основной памяти должно быть достаточно для кэширования и фоновой записи базы данных размером 2MB. Делается предположение, что половина данных в репозитории проекта может быть в активном доступе в любой момент времени.

Серверу следует иметь не менее 256MB. На стороне клиента, рабочей станции каждого разработчика следует иметь не менее 128MB основной памяти.

Внимание, эти данные устарели!

Требования к чтению/записи жесткого диска

Жесткий диск. Второе наиболее часто встречающееся узкое место в производительности среды УК — скорость, с которой данные могут быть записаны/прочитаны в ходе интенсивных операций, таких как внесение (check-in) извлечение (check-out) данных и создание базовой версии. Хорошая идея — иметь выделенный контроллер и канал для каждого диска.

  • Пропускная способность сети

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

Дисковое пространство репозитория проекта

В зависимости от размеров проекта, может использоваться один или несколько репозиториев, и каждый репозиторий проекта может содержать десятки тысяч файлов и директорий. Число файлов в любом репозитории проекта будет зависеть от мощности компьютера, на котором работает сервер репозитория, и от ожидаемого числа пользователей, которые будут одновременно к нему подключаться. Репозиторий проекта, используемый для разработки и активного чтения/записи кода, может содержать меньше элементов, чем реже изменяемый репозиторий, не имеющий такой высокой частоты обращений пользователей. Для репозитория проекта разработки программного продукта можно ожидать, что он будет хранить приблизительно от 3000 до 5000 элементов.

Хорошим эмпирическим правилом для определения дискового пространства растущего репозитория будет сохранение 50% свободного дискового пространства, выделением 2-х гигабайтов хранилища под каждый репозиторий проекта.

Репозиторий проекта следует располагать на выделенном сервере. Это значит, что сервер репозитория проекта не следует использовать для:

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

Репозиторий проекта устанавливается на ранней стадии проекта и сопровождается в ходе всего жизненного цикла.

Менеджер конфигурации является главным хранителем репозитория проекта. Он должен быть уверен, что репозиторий постоянно сохраняется в резервной копии и архивируется в соответствии с правилами УК проекта (см. задачу Ввод в действие правил УК).

Адаптацию этого артефакта следует документировать в Плане УК.

Артефакт «Запрос на изменение»

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

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

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

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

Цель дефекта — сообщить детали проблемы, сделать возможным ее решение и отследить возможные рецидивы. Следующие роли используют ЗИ:

  • Системный аналитик использует запросы на изменение, идентифицируемые как доработки, для определения новых свойств программного продукта;
  • Менеджер проекта — для назначения заданий;
  • Тестировщик — для идентификации и описания дефектов, обнаруженных при тестировании;
  • Исполнитель — для анализа дефектов и отыскания ошибок или причин запроса на изменение;
  • Проектировщик тестирования — для планирования тестирования, верификации решенных запросов на изменение и анализа собранных дефектов для измерения качества программного продукта и процесса.

Пример формы запроса на изменение.

Идентификация

  • проект;
  • номер ЗИ;
  • тип запроса на изменение: (проблема или улучшение);
  • заголовок;
  • дата внесения;
  • инициатор;
  • приоритет запроса на изменение.

Текущая проблема

  • описание текущей проблемы;
  • серьезная ошибка;
  • неудобство;
  • улучшение;
  • новое требование;
  • условия обнаружения проблемы;
  • текущая среда разработки: оборудование;
  • операционная система;
  • компилятор;
  • источник текущей проблемы;
  • издержки от текущей проблемы.

Предложенное изменение (инициатор)

  • описание предложенного изменения;
  • оценка стоимости реализации предложенного изменения.

Предложенное изменение (группа оценки изменения)

  • действие;
  • одобрено;
  • не одобрено;
  • отсрочено;
  • описание предложенного изменения;
  • затрагиваемые элементы конфигурации;
  • категория;
  • исправление;
  • улучшение;
  • новые свойства;
  • другое.

Решение

  • предполагаемая цена реализации предложенного изменения;
  • программист;
  • время реализации изменения;
  • анализ;
  • реализация;
  • тестирование;
  • документация;
  • число изменяемых строк кода.

Оценка

  • методы тестирования;
  • инспекция;
  • анализ;
  • демонстрация;
  • тестирование;
  • платформы тестирования;
  • сценарии тестирования:

Местонахождение команды оценки изменений

  • одобренные и принятые изменения.

Процедуры УК часто учреждаются или устанавливаются на ранней стадии жизненного цикла проекта. Как таковые, ЗИ, которые являются неотъемлемой частью процесса изменений, могут появиться в любой момент в ходе проекта.

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

Любой участник проекта должен иметь возможность внести ЗИ. Однако, ЗИ должен быть просмотрен и одобрен как действительный куратором того, кто вносит ЗИ. Окончательное решение по ЗИ принимается командой оценки изменений или ГКИ.

Менеджер изменений отвечает за полноту информации по дефекту, обеспечивая, что:

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

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

Артефакт «Рабочее пространство»

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

Рабочее пространство разработки — это персональная рабочая область, в которой участник проекта может изменять артефакты, при этом изменения не становятся немедленно доступны другим пользователям.

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

Цель рабочего пространства — обеспечение доступа к артефактам и ресурсам, требуемым для разработки и сборки поставляемого программного продукта. Рабочее пространство разработчика относится к «индивидуальным» областям, где разработчики могут создавать и тестировать код в относительной изоляции от других разработчиков. Интеграционное рабочее пространство относится к общим областям, куда поставляется индивидуальные результаты для встраивания в итоговый продукт в процессе сборки или создания базовых версий.

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

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

Рабочее пространство разработки может быть создано любым Участником проекта. Интеграционное рабочее пространство создается Интегратором.

Адаптацию этого артефакта следует документировать в Плане УК.

Артефакт «Результаты аудита конфигурации»

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

Отчет о результатах аудита конфигурации преследует следующие цели:

  • определить соответствие разработанного программного продукта требованиям к его функциональности;
  • удостовериться в физическом наличии требуемых артефактов.

Краткая схема документа.

Введение

  • дата проведения аудита;
  • цель проведения аудита;
  • общая оценка.

Аудит физической конфигурации

  • идентификация базовой версии;
  • пропущенные артефакты.

Аудит функциональной конфигурации

  • натестированные требования;
  • невыполненные требования;
  • открытые запросы на изменение.

Действия по корректировке

  • действие;
  • исполнитель;
  • контрольный срок;
  • периодичность.

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

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

Подумайте о документировании корректирующих действий в виде ЗИ. Формат документа определяется в План УК.

Задачи

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

Задачи это единицы работы которые могут выполнять сотрудники играющие Роль. Задачи имеют четкие цели, обычно выраженные в создании или обновлении ряда артефактов. Каждая задача связанна с определенной Ролью. Длительность задачи варьируется от 2 часов до двух дней, в задаче участвует одна Роль, и затрагивается небольшой ряд Артефактов. Задачи необходимо использовать как элементы планирования. Если задача очень мала, то её следует пренебречь, если же Задача очень велика, следует планировать её по частям.

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

Задача «Ввод в действие правил УК»

Исполнители

Менеджер конфигурации

Входящие

План создания продукта

Прецедент разработки

План УК

Исходящие

План УК

Периодичность

Процедуры управления изменениями в проекте устанавливаются с начала фазы «Развитие» после утверждения проекта и затем пересматриваются в ходе жизненного цикла проекта в начале фаз Конструирование и Передача.

Руководства

Создание базовых версий с помощью Rational ClearCase

Настройка правил с помощью Rational ClearCase

Таблица 6.1 Основные данные задачи

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

Ниже изложено пошаговое выполнение задачи:

Шаг «Определение правил конфигурационной идентификации»

Цель данного шага — идентификация и сохранение артефактов в защищенном репозитории.

Конфигурационная идентификация — ключевая часть УК и определяется IEEE как элемент УК, состоящий из выбора объекта УК для системы и записи их функциональных и физических характеристик в технической документации». В терминах УК понятие конфигурационной идентификации означает возможность найти и правильно идентифицировать версию любого артефакта проекта быстро и без затруднений. Отрицательные последствия использования неэффективной системы конфигурационной идентификации измеряются в терминах потерянного времени и качества.

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

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

<система>[<A>]_[<подсистема>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<система> обозначает систему

<A> Обозначение для трехбуквенного сокращения, различных типов артефактов, используемых при создании системы. Например,

PLN

Планы проекта

REQ

Файлы управления требованиями

USC

Сценарии

MOD

Файлы моделей

SRC

Файлы исходного кода

INT

Общие интерфейсы

TST

Скрипты и результаты тестирования

DOC

Документация (пользовательская, техническая)

BIN

Исполняемый код

<подсистема> обозначает каждую подсистему

<A> Обозначение для трехбуквенного сокращения, различных типов артефактов, используемых при создании подсистемы. В соответствии с представленной выше таблицей:

R|A|B

Указывает релиз, альфа или бета

<X>

Число, обозначающее основной релиз (т.е. 1)

<Y>

Число (дополнительно), обозначающее второстепенный релиз (часто номер сборки)

<Z>

Число (дополнительно), обозначающее альтернативный релиз (патчи, портирование и т.д.)

BL

Указывает базовый уровень (внутренний релиз)

#

Число для внутренних релизов

Вот несколько примеров:

T2K_R1.0

Релиз 1 системы Thorn 2000

T2K_GUI_R2.0.BL5

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

T2K_B1.1

Бета-релиз 1.1 системы Thorn 2000

T2K_R2.0.BL16

Внутренняя базовая версия №16 системы Thorn 2000, предназначенная для создания релиза 2

T2K_R1.0.5

Выпущенный релиз системы Thorn 2000

Шаг «Определение практики установления базовой версии»

Базовая версия обеспечивает стабильную опору и фиксацию состояния артефактов проекта. Концепция Определение базовых версий описывает, когда в ходе проекта надо создавать базовые версии. Этот шаг обеспечивает дальнейшее практическое руководство.

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

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

  • базовую версию подсистемы со ВСЕМИ версиями файлов и директорий, которые должны быть модифицированы в подсистеме или подсистемах;

или

  • базовую версию системы с ОДНОЙ версией файлов и директорий во всех подсистемах.

В общем случае, следует облегчать управление релизами, создавая базовые версии системы как на значительных, так и на второстепенных этапах проекта или же создавая базовые версии подсистем по мере необходимости или более часто, если это потребуется. На практике считается нормальным создание новой базовой версии, если изменилось не менее 30% компонент подсистемы.

Шаг «Определение практики архивирования»

Цель этого этапа — обеспечение создания резервной копии и сохранение в заранее определенном хранилище программного обеспечения и материалов (основных документов) проекта. Значение архивов проявляется при необходимости повторного использования компонент или в аварийной ситуации. Поэтому архивы требуется обновлять регулярно на главных и второстепенных этапах проекта.

Правила именования меток, описанные ранее на шаге «Определение правил конфигурационной идентификации», могут быть использованы при создании меток архивов. Однако, может потребоваться дополнительная информация о том, где хранятся архивные данные. Например:

СЕРИЙНЫЙ НОМЕР

123456789

ТОМ

1 из 3

ХРАНИЛИЩЕ

B5

ДАТА АРХИВИРОВАНИЯ

99-June-21

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

Задача «Создание плана УК»

Исполнители

Менеджер конфигурации

Входящие

План создания продукта

Прецедент разработки

Исходящие

План УК

Периодичность

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

Руководства

Создание модели реализации с помощью Rational ClearCase

Создание модели реализации UCM с помощью Rational ClearCase

Таблица 6.2 Основные данные задачи

Цели задачи:

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

Ниже изложено пошаговое выполнение задачи:

Шаг «Создание плана управления конфигурациями»

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

План УК это документ который полностью описывает все задачи связанные с УК. Шаблон предназначен для использования в качестве руководства по созданию такого плана. Каждый раздел должен соответствовать содержанию данного конкретного проекта или программного продукта. Не следует ни излишне усложнять задачу создания плана, ни планировать излишние процедуры и бюрократические правила для персонала проекта.

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

Шаг «Рецензирование и утверждение плана УК»

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

План УК разрабатывается как только утверждаются Концепция системы и Бизнес-план. Он создается параллельно с другими планами руководителем проекта и рассматривается всеми заинтересованными группами.

Хотя План УК утверждается Менеджером проекта, он должен быть рассмотрен всеми зависимыми от него сторонами. Например, его следует рассмотреть Менеджеру конфигурации, ключевым разработчикам и Интегратору.

Шаг «Поддержка плана УК»

Цель шага гарантировать соответствие Плана УК текущей ситуации в проекте.

План УК должен пересматриваться в ходе проекта в начале каждой фазы (фазы Конструирование и Передача) для того, чтобы обеспечить соответствие стратегии УК и уровня развития проекта.

План УК следует поместить под версионный контроль в поддиректорию «планы» в структуре директорий программного продукта.

Задача «Ввод в действие процесса контроля за изменениями»

Исполнители

Менеджер изменений

Входящие

План УК

План создания продукта»;

Прецедент разработки»;

Инфраструктура разработки».

Исходящие

План УК

Периодичность

Процедуры управления изменениями в проекте устанавливаются с начала фазы Развитие после утверждения проекта и затем пересматриваются в ходе жизненного цикла проекта в начале фаз Конструирование и Внедрение.

Руководства

Определение уведомлений об изменениях и рецензировании с помощью Rational ClearQuest

Внедрение процесса управления запросами на изменение с помощью Rational ClearQuest

Внесение запроса на изменение с помощью Rational ClearQuest

Извлечение (checking out) и внесение (checking in) объектов УК в Rational ClearCase

Таблица 6.2 Основные данные задачи

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

Ниже изложено пошаговое выполнение задачи:

Шаг «Ввод в действие процесса запроса на изменение»

Процедуры управления изменениями гарантируют, что предлагаемые изменения системы оценены и одобрены должным образом.

Заполнение формы запроса на изменение.

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

Анализ запроса на изменение.

Когда ЗИ внесен, он подвергается анализу с тем, чтобы удостовериться, что он обоснован и что можно передать его на рассмотрение соответствующему техническому или управленческому персоналу. ЗИ должен быть рассмотрен на различных уровнях в команде разработчиков. Руководитель группы рассматривает и утверждает ЗИ, внесенные кем-либо из его команды, однако, если существо запроса вне компетенции команды, запрос эскалируется на следующий уровень рецензирования. Если изменение затрагивает деятельность нескольких разных рабочих групп, оно рассматривается ГКИ. В RUP роль Менеджера изменений используется для представления роли, выполняемой ГКИ.

Время от времени зарегистрированный системный сбой может быть обусловлен скорее неправильными действиями пользователя, чем реализацией системы. Также может быть, что о «проблеме» уже сообщалось раньше, и ее уже приняли к рассмотрению.

Результатом шага «анализ» является либо принятие запроса на изменение к исполнению, либо его отклонение по причине неправильной информации, повторения другого запроса, или несоответствия целям данного проекта, или полномочиям разработчиков.

Оценка стоимости запроса на изменение

Для принятых изменений следующим шагом является оценка стоимости изменений, основанная на их воздействии на всю систему и на простоте реализации ЗИ.

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

Реализация запроса на изменение

Как только ЗИ утвержден, изменения могут быть внесены в программное обеспечение. Исправленное ПО затем подвергается проверке на гарантию качества для того, чтобы убедиться, что изменения сделаны в соответствии с установленными в проекте правилами и не влияют негативно на другие элементы существующего программного обеспечения.

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

Сохранение истории изменений

При внесении изменений в ПО важно, чтобы сохранялась история сделанных изменений.

Эффективный путь — сохранять историю изменений в начале кода каждой компоненты ПО и вместе с артефактами «Запрос на изменение».

Шаг «Ввод в действие группы управления изменениям»

Цель данного шага — создание группы контроля изменений, которая будет утверждать все изменения в базовых версиях объектов УК. Команда должна убедиться, что все предложенные изменения прошли соответствующий технический анализ, были рассмотрены и задокументированы для того, чтобы отслеживать их состояние и проводить аудит.

Заседания ГКИ проводятся регулярно или при возникновении срочной потребности.

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

Выбор членов группы»

Цель этого шага — образовать ГКИ, состоящую из «нужных людей», пользующихся авторитетом среди сослуживцев и обладающих достаточным опытом для предотвращения неблагоразумных или дорогостоящих изменений. ГКИ должна включать представителей всех заинтересованных лиц и организаций, таких как:

  • пользователи;
  • разработчики;
  • группа тестирования;
  • руководство проекта.

Назначение руководителя ГКИ

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

Решения ГКИ следует получать на основании консенсуса всегда, когда это возможно. Группа динамично отражает кооперативный характер проекта разработки. Роль руководителя — создание такого кооперативного подхода и проведение самостоятельных действий, если это необходимо.

Проведение заседаний для оценки предложенных изменений

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

Шаг «Определение протокола сообщений о рассмотрении изменений»

Цель протокола сообщений о рассмотрении изменений — гарантировать извещение соответствующих членов команды о внесении артефактов «Запрос на изменение». Также на данном шаге необходимо решить, кто должен работать с различными артефактами.

На входе этого шага — список артефактов, которые требуется разработать в ходе проекта.

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

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

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

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

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

Задача «Развертывание среды УК»

Исполнители

Менеджер конфигурации

Входящие

План УК

План создания продукта

Прецедент разработки

Инфраструктура разработки

Модель реализации

План итерации

Исходящие

Репозиторий проекта

Периодичность

Процедуры управления изменениями в проекте устанавливаются с начала фазы Развитие после утверждения проекта и затем пересматриваются в ходе жизненного цикла проекта в начале фаз Конструирование и Передача.

Руководства

Архивация требований с помощью Rational RequisitePro

Извлечение (checking out) и внесение (checking in) объектов УК в Rational ClearCase

Создание базовой версии проекта Rational RequisitePro

Создание мультисайтов с помощью Rational ClearCase

Создание мультисайтов с помощью Rational ClearQuest

Создание связи м/у УК и УЗИ с помощью Rational ClearQuest и Rational ClearCase

Создание модели реализации с помощью Rational ClearCase

Создание модели реализации UCM с помощью Rational ClearCase».

Таблица 6.2 Основные данные задачи

Цели задачи:

  • обеспечение поддержки рабочей среды, в которой программный продукт разрабатывается и собирается. Задача состоит из 2-х частей: сначала обеспечивается аппаратная поддержка рабочей среды, а затем — технологическая поддержка среды разработки;
  • настройка среды УК включает выделение аппаратных ресурсов (серверы и дисковое пространство) и инсталляцию инструментальных средств УК;
  • настройка среды разработки включает создание репозиториев, настройку структуры директорий продукта и загрузку существующих данных в систему УК. Начальный вариант среды разработки служит в качестве базовой версии для задач дальнейшей разработки программного продукта.

Ниже изложено пошаговое выполнение задачи:

Шаг «Развертывание аппаратных ресурсов среды УК»

Цель шага — выделение аппаратных ресурсов, необходимых для инсталляции и настройки инструментария УК.

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

Ключевые требования (в порядке приоритета) для определения аппаратной конфигурации, предназначенной для сервера, который обеспечивает доступ к актуальным данным в репозитории проекта, представлены ниже:

  • требования к памяти;
  • требования к скорости чтения/записи диска;
  • скорость передачи данных в сети;
  • дисковое пространство для репозитория проекта.

Информация по каждому из этих пунктов представлена в описании артефакта «Репозиторий проекта»

Шаг «Разметка архитектуры репозитория»

Структура директорий продукта логически организуется для обеспечения места хранения всех относящихся к проекту артефактов.

Структура директорий продукта служит логически смонтированным местом расположения всех артефактов проекта. Структура директории (которая служит как репозиторий проекта) зависит от числа подсистем, входящих в систему, и числа компонент в каждой подсистеме.

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

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

Задача УК — обеспечить, чтобы для каждого разрабатываемого компонента имелось место в структуре директорий, и чтобы имелось достаточно места для хранения артефактов, которые будут разработаны при реализации проекта. УК предполагает построение структуры директорий с учетом взаимосвязей ее внутренних элементов. Компоненты должны иметь ясно определенные интерфейсы с другими частями системы и иметь возможность независимо от них собираться и тестироваться. Основная причина — позволить вести разработку систем параллельно разным командам. Цель — значительно ускорить разработку, повысить возможности повторного использования и упростить сопровождение системы.

Шаг «Создание начального набора элементов в версионном хранилище»

Цель — создание первоначальной базовой версии артефактов проекта.

Даже в проектах, не использующих УК, имеется понятие о структуре директорий и существующем наборе материалов, постоянно используемых в проекте. Цель — экспортировать/импортировать существующие материалы в/из структуру, созданную для разработки программного продукта.

Шаг «Определение уровней зрелости базовой версии»

Базовая версия — одна из версий репозитория проекта. Качество или состояние этой базовой версии определяется ее уровнем зрелости. Все элементы, хранящиеся в репозитории проекта, имеют единый набор «легальных» уровней зрелости. Это обеспечивает согласуемость определения уровня продвижения в разных проектах.

Более подробно материал представлен в описании концепции «Базовые версий».

Задача «Создание интеграционного рабочего пространства»

Исполнители

Интегратор

Входящие

Репозиторий проекта

Прецедент разработки

Проектные руководства

Исходящие

Рабочее пространство

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Создание интеграционных и сборочных рабочих пространств с помощью Rational ClearCase

Доступ к Rational ClearCase из Rational Rose

Таблица 6.2 Основные данные задачи

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

В соответствии с определенным в проекте Прецедентом разработки разработчики создают компоненты и передают их из своего рабочего пространства в интеграционное рабочее пространство проекта. Интеграторы собирают переданные в интеграционное рабочее пространство компоненты и создают Сборки. При создании новой базовой версии
Интегратору требуется «закрыть» интеграционное рабочее пространство, чтобы гарантировать стабильный состав файлов в нем и чтобы разработчики не могли добавить в него новые файлы.

Имеется 2 типа представлений, ассоциирующихся с интеграционным рабочим пространством, это динамические представления, и статические представления.

Динамическое представление обеспечивает немедленный прозрачный доступ к файлам и директориям репозитория проекта. Статическое представление копирует файлы и директории из репозитория проекта на рабочую станцию разработчика.

Для интеграционного рабочего пространства следует использовать динамическое представление. Это гарантирует роли «Интегратор» доступ к последним версиям файлов и директорий, переданных разработчиками.

Задача «Создание инсталяционного пакета»

Исполнители

Менеджер конфигурации

Входящие

Список версий компонент релиза

Сборка

Модель развертывания системы

План развертывания

Документация поддержки пользователя

Инсталляционные артефакты

Репозиторий проекта

Описание релиза

Учебные материалы

Исходящие

Инсталляционный пакет

Периодичность

По мере надобности как часть итерационного процесса разработки.


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

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

В этой задаче Менеджер конфигурации создает копию передаваемых артефактов, находящихся под версионным контролем в репозитории проекта и входящих в базовую версию продукта, на подходящем носителе информации для развертывания в требуемой среде. Носителем информации может быть CD-ROM или, в случае загрузки через Интернет, архивированная копия, готовая к загрузке.

Задача «Создание базовых версий»

Исполнители

Интегратор

Входящие

Репозиторий проекта

Проектные руководства

План разработки продукта

Поручение

Рабочее пространство

Исходящие

Рабочее пространство

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Создание базовых версий с помощью Rational ClearCase

Доступ к Rational ClearCase из Rational Rose

Сравнение и слияние моделей Rational Rose с помощью интегратора моделей

Создание базовых версий проекта Rational RequisitePro


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

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

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

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

Задача «Продвижение базовых версий системы»

Исполнители

Интегратор

Входящие

Рабочее пространство

Репозиторий проекта

План разработки продукта

Проектные руководства

Исходящие

Рабочее пространство

Репозиторий проекта

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Продвижение базовых версий проекта с помощью Rational ClearCase

Доступ к Rational ClearCase из Rational Rose


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

Ниже изложено пошаговое выполнение задачи:

Шаг «Выбор для базовой версии подходящего состояния»

Базовые версии помогают синхронизировать командную работу в проекте. Они обеспечивают доступ к самым последним версиям материалов проекта. Поэтому базовые версии должны создаваться регулярно в соответствии с установленными в проекте правилами УК.

Базовые версии могут именоваться в соответствии с фазой или итерацией, в ходе которой они были созданы. В этом случае имя базовой версии может выглядеть как «BL-название продукта-X-c2», подразумевая, что эта базовая версия создана в конце второй итерации фазы Конструирование.

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

  • пройдено интеграционное тестирование;
  • пройдено системное тестирование;
  • пройдены приемочные испытания;
  • готово к поставке.

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

Задача «Создание рабочего пространства разработки»

Исполнители

Участник проекта

Входящие

Рабочее пространство

Исходящие

Рабочее пространство

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Создание рабочих пространств для разработки с помощью Rational ClearCase

Доступ к Rational ClearCase из Rational Rose


Целями данной задачи являются:

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

Являясь членом команды проекта, вы знаете над чем вам работать и куда передавать результаты так, чтобы они могли быть интегрированы и протестированы вместе с результатами других участников команды проекта. Проект обычно имеет одно рабочее пространство общего доступа и несколько индивидуальных рабочих пространств для разработки. Индивидуальное рабочее пространство разработки позволяет разработчику работать над задачей независимо от других участников проекта.

Разработчик присоединяется к проекту и получает доступ к определенным артефактам и интеграционному рабочему пространству. Следующий шаг для разработчиков — создать индивидуальное рабочее пространство разработки и наполнить его содержимым базовой версии проекта, как основой для начала работы. Базовая версия проекта создается ролью «Менеджер конфигурации» при настройке среды УК, поддерживающей среду разработки.

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

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

Разработчики обновляют свои индивидуальные рабочие пространства, получая доступ к набору версий артефактов, входящих в набор версий артефактов из новой базовой версии. Периодически, когда качество и стабильность базовой версии возрастает, атрибут, показывающий уровень зрелости базовой версии, изменяется для отражения текущего уровня зрелости. Могут использоваться такие значения атрибута, как «собрано», «протестировано» и «готово к поставке»; значения атрибута определяются при установке правил УК в проекте.

Задача «Внесение изменений»

Исполнители

Участник проекта

Входящие

Поручение

Рабочее пространство

Исходящие

Рабочее пространство

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Доступ к Rational ClearCase из Rational Rose

Извлечение (checking out) и внесение (checking in) объектов УК в Rational ClearCase

Displaying Artifacts Related to Specific Objects on a Diagram Using Rational ProjectConsole

Setting Up Version Control using Rational Rose RealTime with Rational ClearCase

Using UCM Change Sets with Rational ClearCase

Viewing Requirement History Using Rational RequisitePro

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

Поручение от руководителей проекта является отправной точкой для любой работы, выполняемой в проекте. Получив Поручение, участник команды обычно планирует свою работу, создавая список своих задач («to do») с датами исполнения, соответствующими указанным в поручении датам.

Следующий шаг для ответственного исполнителя поручения — получить артефакты, требующиеся для выполнения работы или создать артефакты, которые надо поместить под версионный контроль.

Проекты обычно поддерживают версионный контроль артефактов, хранимых в централизованном репозитории с ограниченным доступом. Операции «check-in» и «check-out» позволяют разработчикам получить определенную версию артефакта, сделать в нем изменения и вновь внести его в качестве последней версии в версионное хранилище. Цель этого шага — удостовериться, что разработчики следуют процедуре «check-in» и «check-out» при внесении изменений в версии артефактов, находящихся под версионный контролем.

Базовые операции УК, выполняемые всеми членами команды разработчиков:

  • «Check-out» – дает право на изменение элемента.
  • «Check-in» – сохраняет новую версию измененного элемента и делает изменения доступными для операции «check-out», выполняемой другим участником команды. Рекомендуется установить правило, чтобы каждое внесение изменений сопровождалось кратким комментарием, описывающим сделанные изменения;
  • «Add to source control» – помещает новый файл или директорию под версионный контроль, создавая начальную версию;
  • «Deliver» – передает изменения Интегратору;
  • «Rebase» – делает изменения, произведенные другими разработчиками, доступными вам.

Разработчик обычно работает следующим образом:

  • выполняет операцию «Check-out» с файлами, которые нужно изменить;
  • производит изменения;
  • самостоятельно проверяет сделанные изменения;
  • получает одобрение на сделанные изменения;
  • вносит изменения в версионное хранилище;
  • предоставляет изменения для общего доступа.

Различные типы операции «Check-out».

По умолчанию операция «Check-out» над элементом предоставляет эксклюзивное право создания новой версии этого элемента. Это называется зарезервированным извлечением (reserved checkout). При этом предотвращаются попытки других пользователей также выполнить эту операцию.

В случае параллельной разработки использование не зарезервированного извлечения (unreserved checkout) позволяет выполнять операцию «Check-out» над файлом, даже если кто-то другой уже извлек файл.

Некоторые организации постоянно используют стиль разработки «первым пришел — первым обслужили», при котором несколько пользователей выполняют не зарезервированное извлечение одного и того же элемента . Любой из них может затем внести файл в хранилище, создав его новую версию. Остальные должны объединять (merge) свои изменения с изменениями, внесенными раньше, перед тем, как создать следующую версию файла.

Задача «Передача изменений»

Исполнители

Участник проекта

Входящие

Рабочее пространство

Исходящие

Рабочее пространство

Репозиторий проекта

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Delivering Your Work Using Rational ClearCase

Извлечение (checking out) и внесение (checking in) объектов УК в Rational ClearCase

Доступ к Rational ClearCase из Rational Rose

Добавление элементов под версионный контроль с помощью Rational ClearCase


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

Шаг «Подготовка к передаче»

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

Хорошее правило для проекта — потребовать от разработчика обновлять свое рабочее пространство в соответствии с текущей рекомендованной базовой версией перед передачей результатов его работы в интеграционное рабочее пространство проекта. Цель этого требования — заставить разработчика проверить работоспособность сделанных им изменений на последней утвержденной базовой версии до того, как он передаст свои изменения в интеграционное рабочее пространство проекта. Такая практика минимизирует количество слияний версий, которые требуется делать при выполнении операции передачи изменений.

Другое хорошее правило — убедиться, что все файлы находятся в состоянии «checked-in» перед передачей изменений. Это предохраняет от появления «потерянных» файлов, которые не участвуют в сборке продукта, но могут потребоваться при следующей модификации.

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

В правилах проекта следует определить, кто проводит ревизию данных артефактов и какого уровня качества они должны достичь для того, чтобы их можно было использовать остальным членам команды проекта. Некоторые советы по проведению ревизии даны в руководстве «Рецензирование». Многие артефакты в RUP имеют «контрольные точки», которые могут использоваться для оценки качества конкретного артефакта. Например, если обнаружено, что количество контрольных точек для данного артефакта меньше установленного числа, он направляется на доработку и, таким образом, не годится для «продвижения».

Шаг «Передача изменений»

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

Шаг «Изменение состояния поручения»

Изменение состояния Поручения (например, перевод в состояние «завершено», если вся работа сделана) определяется артефактом «План УК» проекта.

Задача «Обновление рабочего пространства»

Исполнители

Участник проекта

Входящие

Репозиторий проекта

Рабочее пространство

Исходящие

Рабочее пространство

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Обновление вашей рабочей области с помощью Rational ClearCase

Доступ к Rational ClearCase из Rational Rose»;

Сравнение базовых версий с помощью Rational ClearCase


Цель задачи — гарантировать, что члены рабочей команды проекта работают с самыми новыми версиями файлов. Идея состоит в том, чтобы обновить файлы, отображаемые в рабочем представлении (рабочем пространстве) на основе рекомендованной базовой версии.

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

Каждый участник команды, имеющий обновленное представление, может работать над любым артефактом по стандартному процессу «операция check-out, редактирование, сборка продукта, отладка, операция check-in», как описано в описании задачи «Внесение изменений».

Задача «Формирование отчета о состоянии конфигурации»

Исполнители

Менеджер конфигурации

Входящие

План УК

Репозиторий проекта

Исходящие

Данные о состоянии проекта

Периодичность

По мере надобности как часть итерационного процесса разработки.

Руководства

Сравнение базовых версий с помощью Rational ClearCase

Reporting Defect Trends and Status Using Rational ClearQuest

Reporting Review and Work Status Using Rational ClearQuest

Viewing the History of a Defect Using Rational ClearQuest

Working with Charts Using Rational ClearQuest

Working with Queries Using Rational ClearQuest


Цели задачи:

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

Шаг «Отчет о тенденциях по состоянию конфигурации и ошибок»

Проектные данные по ошибкам рапортуются в соответствии с тем, как определены требования к отчету о состоянии конфигурации проекта или продукта в задаче «Ввод в действие правил УК».

Задача «Аудит конфигурации системы»

Исполнители

Менеджер конфигурации

Входящие

План УК

Репозиторий проекта

Исходящие

Результаты аудита конфигурации

Периодичность

В соответствии с артефактом «План УК» — обычно выполняется после системного тестирования и перед приемо-сдаточными испытаниями.

Руководства

Сравнение базовых версий с помощью Rational ClearCase

Reporting Defect Trends and Status Using Rational ClearQuest

Reporting Review and Work Status Using Rational ClearQuest

Viewing the History of a Defect Using Rational ClearQuest

Working with Charts Using Rational ClearQuest

Working with Queries Using Rational ClearQuest


Цели задачи:

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

Пошаговое выполнение задачи:

Шаг «Проведение аудита физической конфигурации»

Аудит физической конфигурации идентифицирует компоненты продукта, предназначенные для распространения из репозитория проекта. Выполняются следующие шаги:

  • идентификация базовой версии для распространения (обычно только имя и/или номер, но может быть также полный список всех компонент с указанием их версий);
  • подтверждение того, что все требуемые артефакты, указанные в описании процесса разработки проекта, имеются в базовой версии. Перечень пропущенных артефактов приводится в отчете по результатам аудита конфигурации.

Другие уровни аудита физической конфигурации

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

Шаг «Проведение аудита функциональной конфигурации»

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

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

Шаг «Отчет по результатам аудита»

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

  • идентификация корректирующих действий. Идентификация источника противоречий и соответствующих корректирующих действий может потребовать проведения интервью с различными членами команды проекта;
  • для пропущенных артефактов соответствующее действие обычно — поместить этот артефакт под конфигурационный контроль или создать артефакт «Запрос на изменение» или задачу для разработки отсутствующего артефакта;
  • для требований, проваливших тестирование, или не тестировавшихся вовсе, можно переадресовать требование для более поздней базовой версии или договорится о его удалении из набора требований;
  • для незакрытых артефактов «Запрос на изменение», может потребоваться просто закрыть запрос или провести его дальнейшее тестирование или переадресовать его к более поздней базовой версии;
  • для каждого корректирующего действия назначьте ответственного и определите дату завершения.

Задача «Внесение запроса на изменение»

Исполнители

Участник проекта

Входящие

ЗИ

Репозиторий проекта

Исходящие

Периодичность

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

Руководства

Внесение запроса на изменение с помощью Rational ClearQuest

Доп. информация

Управление запросами на изменение

Цель использования стандартного и документированного процесса управления изменениями — гарантия того, что изменения, производимые в ходе проекта, согласуются друг с другом и что заинтересованные лица информированы о состоянии продукта, проводимых изменениях, их стоимости и воздействии на рабочее расписание. Участник проекта может инициировать артефакт «Запрос на изменение» для любого объекта УК в течение жизненного цикла проекта.

Шаг «Заполнение формы запроса на изменение»

Форма ЗИ является формально регистрируемым артефактом, который используется для отслеживания запросов (включая запросы новой функциональности, запросы на доработку, ошибки, запросы на отработку изменившихся требований и т.д.) вместе с информацией о состоянии запроса в течение жизненного цикла проекта. Вся история изменений хранится вместе с ЗИ, включая все изменения состояний вместе с датой и причиной изменения. Эта информация доступна при повторной ревизии запроса и при его закрытии. Пример формы запроса на изменение представлен в описании ЗИ.

Шаг «Внесение запроса на изменение»

Как только ЗИ заполнен он должен быть зарегистрирован в соответствии с установленным процессом управления запросами на изменение. Любое участвующее в проекте заинтересованное лицо может зарегистрировать ЗИ. ЗИ помещается в систему учета запросов (т.е., ClearQuest) и размещается в очереди на рассмотрение ГКИ, при этом ЗИ переходит в состояние Зарегистрирован.

Задача «Модификация запроса на изменение»

Исполнители

Участник проекта

Входящие

ЗИ

Исходящие

ЗИ

Периодичность

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

Руководства

Внесение запроса на изменение с помощью Rational ClearQuest

Доп. информация

Управление запросами на изменение


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

Шаг «Вызов формы запроса на изменение»

Форма ЗИ является формально регистрируемым артефактом, который используется для отслеживания запросов (включая запросы новой функциональности, запросы на доработку, ошибки, запросы на отработку изменившихся требований и т.д.) вместе с информацией о состоянии запроса в течение жизненного цикла проекта. Вся история изменений хранится вместе с ЗИ, включая все изменения состояний вместе с датой и причиной изменения. Эта информация доступна при повторной ревизии запроса и при его закрытии. Пример формы запроса на изменение представлен в описании ЗИ.

Шаг «Модификация и сохранение измененного запроса»

Если для запроса на изменение требуется дополнительная информация (состояние Требуется уточнение) или если ЗИ отклонен на какой-либо стадии процесса (т.е., переведен в состояние Дублирован, Отклонен и т.п.), об этом уведомляется инициатор запроса, который может дополнить свой запрос новой информацией. Затем модифицированный ЗИ повторно переводится в состояние Зарегистрирован и помещается в очередь на рецензирование ГКИ для анализа новых данных.

Задача «Рецензирование запроса на изменение»

Исполнители

Менеджер изменений

Входящие

ЗИ

Исходящие

ЗИ

Периодичность

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

Руководства

Формирование отчетов по рецензированию и состоянию работ с помощью Rational ClearQuest

Доп. информация

Управление запросами на изменение


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

Шаг «Подготовка расписания заседаний ГКИ»

ГКИ предназначена для надзора за процессом управления изменениями и состоит из представителей всех заинтересованных сторон, включая заказчиков, разработчиков и пользователей. В небольшом проекте эту роль может исполнять один человек, такой как руководитель проекта или архитектор системы. В RUP это представлено в описании роли «Менеджер изменений».

Назначение таких заседаний — рецензирование внесенных запросов на изменение. Первоначальный анализ содержания запроса на изменение выполняется в ходе заседания для определения обоснованности запроса. Если запрос обоснован, далее выясняется, соответствует ли запрос рамкам релиза, определяемым приоритетом, расписанием, ресурсами, уровнем усилий, риском, срочностью и другими подобными критериями, выработанными этой группой. Такие заседания обычно проводятся еженедельно. При существенном росте количества запросов на изменение или при приближении срока выпуска релиза заседания могут проводиться чаще — вплоть до ежедневных. Обычно в заседаниях ГКИ участвуют Менеджер тестирования, Менеджер разработки, представитель отдела маркетинга. Другие участники могут быть востребованы членами группы при необходимости.

Шаг «Получение запросов на изменение для рецензирования»

Форма ЗИ — формально регистрируемый артефакт, используемый для отслеживания всех запросов (включая запросы новой функциональности, доработки, ошибки, изменение управления требованиями и т.п.), вместе с информацией об их статусе в жизненном цикле проекта. Вся история изменений сохраняется вместе с запросом, включая все состояния запроса с причиной и датой перехода в это состояние. Это информация может использоваться при повторных ревизиях и при закрытии запроса. Пример формы запроса на изменение представлен в описании ЗИ.

Шаг «Рецензирование внесенных запросов на изменение»

Цель этой задачи — рецензирование внесенных запросов на изменение. В такое состояние запрос попадает в следующих случаях: 1) внесен новый ЗИ, 2) изменен существующий ЗИ или 3) произошла ревизия отложенного ЗИ в новом релизе. ЗИ помещается в очередь рецензирования ГКИ. При этом исполнитель запроса не назначается.

Первоначальный анализ содержания запроса на изменение производится на заседании ГКИ для определения обоснованности запроса. Если запрос обоснован, далее выясняется, соответствует ли запрос рамкам релиза, определяемым приоритетом, расписанием, ресурсами, уровнем усилий, риском, срочностью и другими подобными критериями, установленными этой группой.

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

Если определено, что ЗИ дублирует другой запрос, зарегистрированный ранее, его следует адресовать администратору ГКИ или специально назначенному для разрешения таких запросов исполнителю. Когда ЗИ переводится в состояние дублирован, сохраняется номер запроса, который он дублирует (в разделе «Приложения» формы ClearQuest). Инициатору запроса следует выполнить поиск аналогичного запроса в базе данных до того, как его зарегистрировать. Это избавит от необходимости выполнять несколько шагов при рассмотрении запроса и сэкономит время. Инициаторов дублирующих запросов следует добавлять в список нотификации первичного запроса для их извещении о результате решения.

Иногда ЗИ определяется на заседании ГКИ или исполнителем, которому назначен запрос как ошибочный или требующий дополнительной информации от инициатора. Уже назначенный на исполнение запрос (открыт) удаляется из очереди на решение и будет рассмотрен заново. ГКИ предназначена для подтверждения этих действий. От инициатора не требуется никаких действий, пока в этом нет необходимости, тогда состояние запроса на изменение будет изменено на требуется уточнение. ЗИ будет вновь рассмотрен на заседании ГКИ при получении новой информации. При подтверждении ошибочности запроса он будет закрыт группой управления изменениями с извещением инициатора запроса.

Если ЗИ определяется как «соответствующий» текущему релизу, он переводится в состояние открыт и ожидает своего решения. Запрос должен быть исполнен до начала следующего этапа. Это определяется наличием запроса в «очереди на исполнение». Только участники заседания имеют право поместить ЗИ в очередь на исполнение. При определении высшего или следующего за ним приоритета ЗИ к нему следует немедленно привлечь внимание инженера службы качества или руководителя проекта. В этот момент они могут решить провести экстренное заседание ГКИ или просто немедленно открыть ЗИ и поместить его в очередь на исполнение.

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

Задача «Подтверждение состояния Отклонено или Дубликат для запроса на изменение)

Исполнители

Менеджер изменений

Входящие

ЗИ

Исходящие

ЗИ

Периодичность

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

Руководства

Формирование отчетов по рецензированию и состоянию работ с помощью Rational ClearQuest

Внесение запроса на изменение с помощью Rational ClearQuest

Доп. информация

Управление запросами на изменение


Назначенный ГКИ (CCB) администратор должен подтверждать или отклонять запросы на изменения, которые предположительно являются неправильными или дублируют ранее зарегистрированные запросы.

Шаг «Вызов формы запроса на изменение»

Форма ЗИ является формально регистрируемым артефактом, который используется для отслеживания всех запросов (включая новые возможности, запросы на доработку, ошибки, изменение требований, и т.д.) вместе с соответствующей информацией о состоянии с точки зрения жизненного цикла проекта. Хранится вся история изменений запроса, включая все изменения состояния запроса, вместе с датой и причиной проведения изменений. Эта информация может быть использована при пересмотре или закрытии запроса. Пример формы запроса на изменение содержится в описании ЗИ.

Шаг «Подтверждение обоснованности запроса или его дублирования»

Если ГКИ (CCB) предполагает, что ЗИ является Дубликатом или должен быть Отклонен как неправильный (т.е. ошибка оператора, ситуация не воспроизводится и т.д.), то уполномоченный от ГКИ (CCB) получает задание рассмотреть ЗИ и, при подтверждении предположения, утвердить его в состоянии Отклонен или Дубликат. При необходимости нужно собрать дополнительную информацию от того, кто внес ЗИ.

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

Шаг «Обновление состояния запроса на изменение»

В зависимости от результатов исследования запроса на изменение, возможны следующие варианты:

  • утвержденный в состоянии Дубликат или Отклонен
    ЗИ закрывается (состояние Closed ) (с извещением того, кто внес запрос);
  • от человека, внесшего запрос, запрашивается дополнительная информация (состояние More Info);
  • информация в запросе на изменение обновляется с тем, чтобы показать, почему он не утвержден как неправильный или дублирующий запрос, а затем направляется на повторное рассмотрение (состояние Submitted) в группу управления изменениями (CCB) на рецензирование (review).

Задача «Верификация изменений в собранном релизе»

Исполнители

Тестовый аналитик

Входящие

ЗИ

Сборка

Журнал тестирования

Исходящие

ЗИ

Результаты тестирования

Периодичность

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

Руководства

Формирование отчетов по рецензированию и состоянию работ с помощью Rational ClearQuest

Viewing the History of a Defect Using Rational ClearQuest

Доп. информация

Управление запросами на изменение


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

Ниже изложено пошаговое выполнение задачи:

Шаг «Выполнение запроса на изменение»

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

Шаг «Верификация изменений при в тестовой сборке»

После того, как назначенный исполнитель (аналитик, разработчик, Тестировщик, технический писатель и т.д.) исполнил ЗИ, изменения помещаются в очередь на тестирование, чтобы Тестировщик произвел их верификацию при сборочном тестировании программного продукта. ЗИ, который был верифицирован при сборочном тестировании программного продукта, готов для включения в релиз. ЗИ, который провалился при сборочном тестировании или при тестировании собранного релиза, переводится в состояние «Тестирование провалено». Владелец автоматически заменяется на того, кто исполнял ЗИ.

Шаг «Верификация изменений в релизной сборке»

Как только изменения были верифицированы при сборочном тестировании программного продукта, ЗИ помещается в очередь релиза для верификации в сравнении с имеющейся сборкой программного продукта, описанием особенностей следующего релиза и т.д. и закрытия ЗИ.

Закрытый ЗИ не требует внимания. Это последнее состояние запроса на изменение, которое ему присваивается. Только администратор ГКИ имеет право закрыть артефакт ЗИ. Когда ЗИ закрыт, его инициатор получает уведомление по электронной почте с описанием окончательного состояния запроса. ЗИ может быть закрыт: 1) после того, как его решение верифицировано и утверждено в сборе релиза программного продукта, 2) когда он отклонен, 3) при подтверждении того, что запрос дублирует уже существующий ЗИ. В последнем случае инициатор будет информирован о изначальном ЗИ и будет добавлен в список для уведомления этого ЗИ (см. определение состояний «отклонен» и «дублирован» для подробной информации). Если инициатор желает оспорить закрытие, ЗИ должен быть обновлен и заново зарегистрирован для рассмотрения группой управления изменениями.

Шаг «Оценка и проверка результатов»

Цель проверить то что задача завершена верно и результирующие артефакты приемлемы.

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

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

Задача «Распределение работ»

Данная задача описана в документе «Управление проектом»

Работы

Для всех дисциплин существует диаграмма Работ, которая представляет сгруппированные Задачи, выполняющиеся одновременно. Эти диаграммы показывают задействованные Артефакты, Роли и Задачи.

Работа «Планирование проектной конфигурации и контроля изменений»

Цели данной работы:

  • установить правила УК для проекта;
  • установить правила контроля изменений в продукте для проекта;
  • документировать эту информацию в Плане УК (входит в состав План разработки продукта).

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

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

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


Рисунок 16

Данная работа обычно выполняется в первой итерации каждой фазы. Основной упор делается в фазе Конструирование и фазе Передача, хотя в зависимости от рода проекта выполнение работы может быть важным в фазе Начало и фазе Развитие.

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

Данную работу выполняют Менеджер конфигурации и Менеджер контроля изменений.

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

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

Работа «Создание проектной среды УК»

Цель этой задачи — обеспечить рабочее окружение среды разработки, создавая и настраивая репозитории данных, на основе которых весь продукт может быть разработан, собран, готов к эксплуатации и повторному использованию. Для этого требуется гарантировать, что основные артефакты доступны разработчикам и сотрудникам выполняющим роли «Интегратор» в различных частных и общедоступных рабочих пространствах по мере надобности , и затем нужным образом создать базовые версии и сохранить их для повторного использования.

Настройка процедур УК для поддержки среды разработки включает создание структуры директорий продукта, репозиториев, рабочих пространств (для разработчиков и для сотрудников выполняющих роли «Интегратор») и выделение аппаратных ресурсов (серверов и дискового пространства).


Рисунок 17

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

Это работа обязательна для выполнения. Независимо от формализации проекта сначала работе будет отводится меньше внимания чем на более поздних этапах. Учтите что в применимости к существующим средам УК данная работа выполняется для адаптации под данную фазу.

Данную работу выполняют Менеджер конфигурации и Интегратор.

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

Интегратор должен гарантировать, что артефакты, полученные от разработчиков, протестированы достаточно для того, чтобы использоваться при сборке продукта. Он должен знать установленные в проекте правила УК, сборки продукта и практику тестирования.

Работа «Управление базовыми версиями и релизами»

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

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


Рисунок 18

Обычно данная работа начинается в фазе Развитие, а в фазе Конструирование и фазе Передача она выполняется наиболее активно. Некоторые артефакты фазы «Начало» нуждаются в базовой версии, но этот случай не является общим. Создание и управление несколькими базовыми версиями может произойти внутри одной итерации, причем на любом её этапе.

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

Данную работу выполняют Менеджер конфигурации и Интегратор.

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

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

Работа «Изменения и передача объектов УК»

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

Работа фокусируется на том:

  • как участник проекта может создавать рабочее пространство, получать доступ к артефактам проекта, изменять эти артефакты, предоставлять сделанные им в продукте изменения для интеграции и получать доступ к новой версии продукта;
  • каким образом роль «Интегратор» может из своего рабочего пространства собирать продукт, создавать базовые версии и делать их доступными остальной команде разработчиков;


Рисунок 19

Обычно работа начинается в фазе «Начало» и продолжается на протяжении всего жизненного цикла проекта.

Данная работа обязательна к выполнению. Её выполняют Участник проекта и Интегратор.

Участник проекта представляет одну из набора ролей методологии RUP (аналитики, разработчики, тестировщики, менеджеры или дополнительные роли), т.е. часть проектной команды, и может вносить изменения в артефакты (объекты УК).

Сотрудник выполняющий роль Интегратор (как указано в описаниях других дисциплин) должен обеспечить, чтобы полученные от разработчика артефакты прошли достаточное тестирование с тем, чтобы они могли быть использованы при сборке продукта. Он должен понимать установленные в проекте правила УК и методы тестирования.

Работа «Мониторинг и отчетность по состоянию конфигурации

Цели работы:

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


Обычно работа начинается в фазе Начало и продолжается на протяжении всего жизненного цикла проекта.

Данная работа обязательна к выполнению. Независимо от формализованности проекта данная работа варьируется от менее формализованной к более формализованной и становится более сложной при росте проекта.

Данную работу выполняет Менеджер конфигурации.

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

Работа «Управление запросами на изменение»

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


Рисунок 20

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

Данная работа обязательна к выполнению.

ГКИ, наблюдающая за процессом изменений, состоит из представителей всех заинтересованных сторон, включая заказчиков, разработчиков и пользователей. В небольшом проекте эту роль может играть один человек, такой как Менеджер проекта или Архитектор системы. В методологии RUP — это Менеджер контроля изменений.

Подробное изложение этих концепций, рекомендуемые действия и состояния запросов на изменение представлено в разделе концепция «Управление изменениями».

Управление конфигурациями в Rational Unified Process. Один из вариантов перевода, 10.0 out of 10 based on 4 ratings

Связные и просто интересные записи:

Метки:activity, architect, change, chart, clearcase, clearquest, CM, configuration, defect, ibm, ieee, it, loc, management, microsoft, ms, package, plan, process, project, rational, req, request, rose, rup, soda, software, sql, state, tools, unified, атрибут, версии, взаимодействие, видео, внедрение, времени, заказчик, изменение, изменениями, инструмент, инструменты, клиент, код, коммуникации, конфигурации, конфигурациями, курс, лекция, метрики, небо, обсуждение, оператор, отношения, план, планирование, ПО, подряд, подход, поле, программа, программирование, проект, процесс, регламент, система, сложность, состояние, специалист, стандарт, субподряд, требования, тренинг, труд, УК, управление, фактор

14 comments to Управление конфигурациями в Rational Unified Process. Один из вариантов перевода

  • Вот что примечательно в продуктах IBM Rational — это основательность и монструозность подхода.

    Что взять мой любимый ClearCase, что RUP вот опять же — главная характеристика, которая приходит в голову — это «МНОГО» :) Ну то есть вот предусмотрено всё и если быть в теме, то ничего больше и не нужно, у Рэшнл есть всё что надо, на любой случай.

    Сторонний наблюдатель же ужасе закроет и даже не будет пытаться что-то понимать. А если и будет — то только по сильной необходимости. Потому что — МНОГО :)

    Чем людей привлекает Agile как процесс или вот тот же git как система контроля версий — там МАЛО и относительно ПРОСТО. И они на это «ведутся». Они как лемминги идут туда где проще, где уже есть все знакомые, не желая знать при этом, что есть более совершенные процессы и инструменты, заточенные под любые нужды.
    Хотя замечу справедливости ради, что совершенные процессы нужны далеко не всегда :)

    Тем не менее, как старый активист антиброуновского движения, с интересом почитал перевод :) Уже пару дней хочу с небольшими комментариями дать ссылку-рассказ у себя в блоге.
    Если не возражаете, ещё кину ссылку на форумы RSDN.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    • Спасибо за пост :)
      Да, действительно много. НО. Преподавая еще в школе я предлагал старшеклассникам описать алгоритм от пробуждения до прихода в школа. Там тоже получалось много, после того как все описывалось :)
      Просто все, на самом деле, относительно. Я сам не могу себя считать ни сторонником RUP, ни сторонником Agile, ни сторонником ГОСТ. Я сторонник взвешенного выбора в зависимости от ситуации и от конкретной компании: от ее целей и задач.
      Приходилось видеть достаточно компаний, которые получили отравление RUP-ом, и также массу (но чуть меньшую :) , которых Agile не смог удовлетворить.
      Насчет нужности процессов готов поспорить :)
      Я могу согласиться на то, что процессы не всегда должны быть детально описаны, но являясь механизмом движения компании (группы, индивида) вперед — они должны быть идеальными :)
      В ближайшее время я поищу и опубликую материал где слов МАЛО, имеено для сравнения.
      Против распространения материала со ссылкой на источник — не возражаю. Даже за :)

      GD Star Rating
      loading...
      GD Star Rating
      loading...
  • Под первой частью готов подписаться — взвешенный выбор всегда подскажет как правильно. Серебряной пули, как известно, нет — так что инструмент и процесс выбирается под задачу.

    И, кстати, да — много букв получается когда сам того не хочешь. Доводилось мне описывать в письменном виде SCM-политику для команд с несколько десятков человек. Причем политику де-факто, которая работала и которую надо было лишь структурировать для дальнейших изменений. В общем, как ни старался писать только по существу, чтоб понятно было и индусам, и русским — а всё равно немало получалось :)
    Тем не менее, писать кратко и понятно вполне можно, тут уж зависит от писателя :)

    А насчет идеала — ну, не сказал бы. Часто читаю комментарии людей, работающих с примитивными практиками — например, не использующих ветки в своей работе. Для меня — дикость, однако рассмотрение ситуации показывает, что и без веток процесс отлажен. И если внести в него изменения — он будет идеален, но затраты на его изменения окупятся совсем не сразу, как ни печально. Поэтому остается лишь согласиться с тем, что в данных случаях можно пренебречь идеалом :)
    Главное — время от времени делать переоценку процессов и тулов, чтобы не пропустить момент, подходящий для качественных изменений.

    P.S. «материал где слов МАЛО» — очень интересен, хочется посмотреть :)

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    • Упс, промазал мимо треда… Но, думаю понятно, что ответ был на коммент :)

      GD Star Rating
      loading...
      GD Star Rating
      loading...
    • Именно! Я бы даже сказал, что вначале выбирается процесс, потом под него подбирают инструмент :)
      Некоторое время назад я делал доклад для конференции, потом на его основе сделал статью » Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational » вот там как раз я привожу примеры адаптации RUP в зависимости от масштаба организации.
      Краткость — сестра таланта «Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа (полная версия)«.
      А с идеалом, на самом деле, все хитрее :)
      Есть то, что можно назвать «стерильный идеал». Сам по себе он является маяком, направлением. Но «перемещаться» надо по реальности, внося коррективы. «Гладко было на бумаге, да подвели овраги» — так можно охарактеризовать внедрение идеала :) Все равно в жизни будет все далеким от идеала. Но его надо хотя бы знать, чтобы была отправная точка в действиях.
      А насчет веток — отдельная история… у нас были проекты в которых и версионная система была не нужна, не то что ветки. Еще раз повторюсь: если по процессу ветки не требуются, а в идеале они нужны, то это не повод переламывать процесс :)
      Про переоценку полностью согласен! Единственное «но!» — не делать переоценку ради переоценки — не пересматривать процесс каждый день с целью его улучшения. У меня были и такие примеры… аж страшно :)

      Мне трудно даются материалы с малым количеством букв. Но я стараюсь :)

      GD Star Rating
      loading...
      GD Star Rating
      loading...
      • Да, процесс важнее, это факт.

        Масштаб RUP — конечно, это же универсальная штука. Но, повторюсь, народ пугается «многабуков», и не важно, что процесс можно адаптировать под их потребности.

        По остальному — ну просто просто телепатия какая-то, прям мои мысли :) ))

        P.S. К слову про мало букв — скромно пиарю свой бложик :) В статьях по основам SCM
        http://scm-notes.blogspot.com/p/software-configuration-management.html
        попытался как можно более понятно описать своё понимание управления конфигурацией ПС, выработанное за несколько лет работы по направлению. Попытался кратко, и вроде даже понятно получилось :) Будет интересно послушать мнение профессионала, который в отрасли SCM гораздо дольше меня.

        GD Star Rating
        loading...
        GD Star Rating
        loading...
        • Да, RUP — энциклопедия, справочник. Правда, говорят, что хороший режиссер сможет экранизировать даже справочник :) Но в моём опыте, все же, такого не было. RUP — лишь сборник рекомендаций, из которых, по кубику выстраивается (адаптируется процесс). Просто я «давно сижу» и многое вижу. RUP внедряю с 1999го года. Так вот, пик интереса к технологии Rational пришелся на 2001-2003 годы. Все ждали: «вот возьмем мы RUP» и будет хорошо. Взяли все, но хорошо стало единицам — тем единицам, которые правильно из большенного RUPа сделали свою адаптацию. Потом была мода на XP, сейчас на Agile… Очень многие ищут не совсем методологию, а «таблетку счастья» — выпил и порядок уже на утро. Никто не хочет даже думать о том, как адаптировать методологию. Вернее некоторые думают, но не все :)
          Ваши публикации в RSDN видел :)
          Даже Ваши рекомендовал знакомым, не находящимся в моей непосредственной досягаемости, которым надо было получить понимание SCM. А телепатия — это хорошо. Хорошо тем, что специалисты какой-то области смотрят похоже на профессиональные вопросы: да, каждый по-своему, возможно, с разных точен зрения, но непременно в одну сторону :)

          GD Star Rating
          loading...
          GD Star Rating
          loading...
          • Кстати, да, я про РУП узнал как раз на рубеже веков, тогда думали — серебряная пуля, на этот раз по-любому последняя :) Однако ж нет. Интересно, если людям рассказывать про методологии и не указывать их названия — какая из методик будет популярнее? :) )))

            Насчет статей — спасибо за рекомендации :)

            GD Star Rating
            loading...
            GD Star Rating
            loading...
          • Просто за 10 летнюю практику внедрений становишься циником.
            Многие говорят, что внедрили RUP, а на самом деле внедрили отдельные инструменты и взяли пару шаблонов документов. У РУП есть своя идеология — «дух»… и если этого нет, то означает не более чем простую, механическую установку.
            Дальше больше — многие заказчики считали, что у них Экстремальное программирование… дай бог им здоровья :)
            Подавляющее большинство считало, что XP — это когда ничего не описано, все делается в последний момент, а в проекте есть мудрый наставник — ментор. Это также смешно :) XP очень неплохая методология для определенной категории проектов, но и в ней есть ДУХ — это и парное программирование, и итерационность, и наличие представителя заказчика в команде и общий код.
            Ну, думали, что у больших компаний с ГОСТами будет порядок… где там… половина компаний, декларируя, что «мы работаем по гостам» вообще мало представляют, что это такое. У нас был клиент, который знание госта на оформление конструкторской документации выдавал за сокральное знание, помогающее писать ТЗ :)

            Если устроить закрытый показ методологии, то победит та, где не надо много писать и где все будет просто и понятно :)
            Это как с детьми в школе: если лежат две книги — толстая и тонкая, то, разумеется, на вопрос «какая лучше?» ответ будет — тонкая :) Она же меньше :)

            GD Star Rating
            loading...
            GD Star Rating
            loading...
          • Ну как сказать…. сегодня agile «проталкивают» именитые вендоры, выпускают под них специфические тулы, говорят, что по этим правилам живут их девелоперы (причем не одни сотни). При выборе методологии конечно же многое зависит от внутреннего климата проекта:
            1. Часто возникают конфликты, меняется персонал, с заказчиком не всегда можно найти общий язык — используем формальную методологию.
            2. Высокий уровень согласованности и настроения внутри команды, определены и прозрачны механизмы общения с заказчиком — тут и уровень формальности можно понижать.

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

            GD Star Rating
            loading...
            GD Star Rating
            loading...
          • А вот тут большой вопрос :)
            Возвращаясь к своему учительскому опыту скажу, что если хочешь, чтоб ученики тебя любили, то не надо никого ни о чем спрашивать, не ставить оценок, не давать заданий на дом, и, по-хорошему, ничему не учить… и так далее. Этим можно заработать популярность на какое-то время…, до тех пор пока не прорежутся у учеников мозги и они сами не поймут, что от такой учебы больше вреда, чем пользы… У всех нас есть в памяти строгие учителя в школе, строгие преподы в ВУЗе… Которых мы ненавидели тогда, а спустя годы в сердцах говорим спасибо :)
            С производителями сейчас примерно также — есть популярная методология. Игнорировать этот факт невозможно. Соответственно, если я предлагаю инструмент, поддерживающий что-то модное, то у меня идут продажи.

            А насчет того, что вендоры сами «нюхают» то, что нам продают, то я могу вспомнить тот факт, что Microsoft лет 10 назад хвастался, что для своих внутренних проектов они используют ПО Rational… а с годами выяснилось, что PR отдел слегка преувеличил :)

            GD Star Rating
            loading...
            GD Star Rating
            loading...
  • Vladimir

    В самом начале опечатка: «MS TSF» -> «MS TFS».

    GD Star Rating
    loading...
    GD Star Rating
    loading...

Leave a Reply to Александр

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free