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

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

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

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

Оглавление. Часть 1.

• Введение
  
• Аббревиатуры и сокращения
• Дисциплина «Управление конфигурацией и изменениями»
• Цели
• Взаимодействие с другими дисциплинами
• Процесс
• Связь между работами, ролями, выполняемыми задачами и артефактами
• Концепции
• Концепция «Управление конфигурацией и запросами на изменение»
• Концепция «Рабочее пространство»
• Концепция «Интеграционные рабочие пространства (ИРП) и рабочие пространства разработки (РПР)»
• Концепция «Управление запросами на изменение»
• Концепция «Unified change management»
• Концепция «Отчет по статусу конфигурации»
• Концепция «Структура директорий продукта»
• Концепция «Метод продвижения»
• Концепция «Определение базовых версий»
• Роли
• Роль «Менеджер конфигурации»
• Роль «Менеджер контроля изменений»
• Роль «Интегратор»
• Роль «Участник проекта»
• Роль Участник проекта выполняется всеми членами проектной команды. Поэтому назначение данной роли происходит по умолчанию
  

Введение

Аббревиатуры и сокращения

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

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

Куб УК.

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс

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

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

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

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

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

Концепции

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

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

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

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

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

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

Куб УК

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

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

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

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

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

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

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

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

Выбор версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РПР

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

РПР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма состояний PB

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

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

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

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

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

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

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

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

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

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

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

Отчеты по ЗИ

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

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

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

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

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

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

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

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

Куб УК в разрезе отчетов по ЗИ

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

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

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

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

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

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

Аудиты

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

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

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

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

Детально деятельность по выполнению ревизий описана в параграфе 6.14.

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

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

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

Структура системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отчет

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

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

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

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

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

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

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

Роли

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

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

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

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

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

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

Задачи и артефакты

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

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

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

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

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

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

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

Задачи и артефакты

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

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

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

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

Задачи и артефакты

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

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

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

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

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

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

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

Задачи и артефакты

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

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

Метки:change, clearcase, clearquest, CM, configuration, defect, ibm, ieee, it, management, microsoft, ms, process, project, rational, req, request, rose, rup, soda, software, sql, state, tools, unified, атрибут, версии, взаимодействие, видео, внедрение, времени, заказчик, изменение, изменениями, инструмент, инструменты, клиент, код, коммуникации, конфигурации, конфигурациями, метрики, небо, обсуждение, оператор, план, планирование, ПО, подряд, подход, поле, проект, процесс, регламент, система, сложность, состояние, специалист, стандарт, субподряд, требования, труд, УК, управление, фактор

Связанные записи

• Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа (полная версия) (0)
• Switched Network (SN) Configuration Management Plan (0)
• Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest (0)
• Программное обеспечение IBM Rational. Методология и инструментальные средства разработки программных систем (0)
• NOAA. Configuration Management Plan (0)