Рубрики

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

Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа (полная версия)

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




Долго ждал… и все же решил опубликовать полный вариант данной статьи. Разработка Плана Управления Конфигурациями — важная часть процесса разработки (по тексту вы пойте почему и зачем). Многие не разрабатывают данный документ, так как считают, что умные и большие документы нужны только в больших поектах… а мы маленькие — нам это не надо. Эта статья покажет, что данное утверждение говорит просто о НЕЗРЕЛОСТИ команды (подразделения, компании, района, города, государства, континента, планеты… — нужное — подчеркнуть :) , а сам документ может быть как формальным (большим и занудным), так и  неформальным (маленьким и понятным). Только вот быть-то он должен :)

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

Отличие этой (полной) версии от опубликованных уже (на сайте IBM, на сайте СМ-Консалт и в блоге) заключено во второй части, а именно в примерах содержимого различных планов управления конфигурациями. Я просто попытался переработать большую часть виденных и писанных мною и коллегами планов УК и сделать некие выжимки — представить примеры. То есть первая часть описывает, что и как должно быть отражено в плане УК, а вторая показывает как это было сделано в разных РЕАЛЬНЫХ документах.

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

Работа была проделана большая, можно сказать, фундаментальная. Честно говоря все это писалось для книги по управлению конфигурациями, но загруженность моя в проектах такова, что времени на книгу просто не остается… потому приходится «причесывать» книжный материал и время от времени публиковать статьи. Может когда-нибудь будет времени побольше и получится все всести воедино… мечты :)

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

Комментарии не просто приветствуются, а очень и очень важны и нужны.

Приятного чтения :)

Авторы: Новичков Александр, Лапыгин Дмитрий

Оглавление:

  • Что такое план?
  • Кто пишет план?
  • Когда готовят план УК?
  • Поддержка плана в актуальном состоянии
  • План УК в стандартах
  • Стандартизация и классификация
  • Структура типового плана УК с комментариями к разделам
  • Полнота плана УК в зависимости от объема проекта и его типа
  • Как заставить участников читать план?
  • Примеры содержимого (выдержки из разных планов)
  • Примеры структур планов
  • Финальный план УК государственной компании
  • Финальный план УК системного интегратора
  • Начальная версия плана УК билинговой компании
  • Структура плана для разработки системы в реальном масштабе времени

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

Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится…

Что такое план Управления Конфигурациями?

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

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

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

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

Кто пишет план?

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

Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана – Менеджер УК.

Менеджер Управления Конфигурациями — ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.

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

Техническое применение плана (реализация плана в средствах поддержки УК)

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

  • Установить средства;
  • Разработать экранные формы запросов на изменение;
  • Установить политику доступа;
  • Определить жизненный цикл запросов на изменение;
  • Поставить данные под УК в соответствии с планом;
  • И т.д.

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

Когда готовят план УК?

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

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

Поддержка плана в актуальном состоянии

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

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

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

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

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

План УК в стандартах

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

Таблица 1 – Определение структуры плана УК в стандартах

Стандарт

Определяет содержимое плана?

Комментарии

ГОСТ Р ИСО/МЭК 12207

НЕТ

Оговаривается только наличие плана.

CMM/CMMI

НЕТ

Требований к содержимому плана и его структуре нет, но по большому счету вся модель один в один представляет собой «скелет» плана УК.

ISO 10007-95

Частично

«Приложение «А»» (нормативное) определяет рекомендуемую структуру и содержание программы управления конфигурацией.

IEEE Std 828-1990 и Std 1042-1987

ДА

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

Microsoft Solution Frameworks

ДА

Rational Unified Process

ДА

Естественно, RUP не совсем стандарт в полном смысле этого слова, но по сути стандарт «де факто». Требования к плану, шаблоны планов и примеры планов отражены в нем в полной мере и представляют агрегированный опыт по отраслям экономики.

Стандартизация и классификация

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

Рассмотрим факторы, влияющие на структуру плана УК:

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

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

Таблица 2 — факторы, влияющие на структуру плана УК и его детализацию

Фактор Возможные значения Воздействие, описание
Тип проекта Разработка модели (прототипа)

Проект сопровождения ПС

Коммерческий (с сопровождением)

Коммерческий без сопровождения

Субподрядный

Наличие нескольких офисов (регионально распределенная разработка) Один офис

Более одного

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

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

Относительный размер проекта Малый

Средний

Большой

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

Основные системы УК (как правило, только отслеживание версий)

Генераторы отчетов (обычно встроенные)

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

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

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

Также большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам.

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

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

Продвинутые, интегрированные

Тоже что и выше. Плюс средства управления изменениями

Встроенные средства сборки и аудита

Разрозненные
Уровень формализации (как процессов организации, так и тип контроля плана) Высокий

Средний

Низкий

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

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

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

Структура типового плана УК с комментариями к разделам

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

Таблица 4 – Структура плана УК

Раздел плана Раздел плана Требования к содержанию Дополнительные комментарии
1. Введение Introduction Введение в план УК представляет собой обзор содержания документа. Включает цели, область действия, определения, акронимы, сокращения, ссылки и обзор плана конфигурационного управления Введение позволяет сделать документ более читаемым – объяснить основные моменты и расставить правильные акценты.
1.1 Назначение
Purpose Содержит назначение документа «План конфигурационного управления» Как правило, в назначение можно включить описание целей, которые решает данный план. Ведь план, в зависимости от размеров проекта, от географической распределенности также может различаться.
1.2 Область применения Scope Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ.
Зачастую, можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов:

  • Какова характеристика подконтрольных конфигурационных элементов?
  • Чем должны управлять интерфейсы высокого уровня?
  • Каковы временные рамки проекта?
  • Каковы доступные ресурсы?
  • Каковы подконтрольные сущности?
1.3 Определения, акронимы и сокращения Definitions, Acronyms, and Abbreviations Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа «План конфигурационного управления». Для предоставления этой информации можно воспользоваться ссылками на словарь проекта Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее глоссарий – это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе.

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

Вопросы:

  • Определения легки и понятны всем участникам проекта?
  • Есть ли список, на который можно легко сослаться?
  • Необходимо ли определять данный термин?
1.4 Ссылки References Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в «Плане конфигурационного управления». Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы. План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе, документы RUP, стандарты, международные и отраслевые стандарты).

Вопросы:

  • Используются ли в плане положения, методики политики, уже используемые в организации?
  • Действительно ли ссылка необходима в плане?
1.5 Обзор
Overview Обзор документа по разделам Необходимо понимать, что не все участники проекта будут читать документ «от корки до корки». Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли.
2. Конфигурационное управление программным продуктом Software Configuration Management Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации.

Количество подразделов и их вложенность могут отличаться от приведенных ниже

2.1 Организация, распределение ответственностей и взаимодействия Organization, Responsibilities, and Interfaces Указывается, кто будет ответственным за выполнение различных задач конфигурационного управления, описанных в ходе процессов конфигурационного управления Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о распределенной разработке в нескольких географических точках.

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

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

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

В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика.

Вопросы:

  • Каковы возможности организации по штату для выполнения операций УК?
  • Какова структура управления?
  • Каков стиль управления?
  • Кто будет ответственен за выполнение операций?
  • Какие организационные изменения могут быть в течении жизни плана УК?
  • Каковы планы по поддержке текущей организационной структуры?
  • Какой уровень поддержки необходим для осуществления плана УК?
  • Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно?
  • Как распределяется ответственность при возникновении нештатных ситуаций?
  • Имеются ли особенности для этого проекта, которые могут повлиять на бизнес?
  • Какие действия выполняет группа CCB в проектном управлении при планировании?
  • Прозрачно ли описаны роли участников?
2.2 Инструментарий, рабочая среда и инфраструктура Tools, Environment, and Infrastructure Рассматривается рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта.
Описываются инструменты и процедуры, которые нужно использовать для версионного контроля объектов конфигурационного управления, создаваемых в ходе
жизненного цикла проекта или программного продукта.

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

ожидаемый размер данных по программному продукту;

распределение рабочей команды;

расположение серверов и рабочих станций.

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

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

Как вариант: сервер Linux, клиенты Windows.

Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства.

Вопросы:

  • Каковы организационные интерфейсы?
  • Как взаимодействую процессы?
  • Каков перечень процессов для взаимодействия?
  • Каковы интерфейсы между применяемыми средствами автоматизации?
  • Каковы зависимости между ними?
  • Есть ли аппаратные зависимости?
  • Где определены документы, регламентирующие процесс?
  • Они утверждены?
  • Каковы процедуры внесения изменений в эти документы?
  • Каковы задействованные ресурсы (человечески, оборудование)?
3. Программа конфигурационного управления The Configuration Management Program
3.1 Конфигурационная идентификация Configuration Identification Вопросы:

  • Доступны ли стандартные методы идентификации?
  • В чем состоит используемая схема идентификации объектов УК?
  • Связаны ли программные и аппаратные идентификации (для встроенных систем)?
  • Какие спецификации и планы управления должны быть идентифицированы?
  • Необходима ли специальная схема идентификации чтобы отслеживать ПС третьей стороны?
  • Есть ли разница в идентификации элементов в зависимости от типа приложений?
  • Есть ли подтипы (например, компилятор С++ может работать с файлами c, cpp, h, hpp и др)?
  • Идентифицируются ли и хранятся скрипты автоматизированного тестирования?
3.1.1 Методы идентификации Identification Methods Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должно быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую — спонтанно. Цель описания — выработать новую более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места.
3.1.2 Базовые версии проекта Project Baselines Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения.
Описывается, в какой точке жизненного цикла проекта или продукта должны создаваться базовые версии. Наиболее общие базовые версии должны быть в конце каждой из фаз обследования, проработки проекта, построения системы и передачи в эксплуатацию. Базовые версии также могут создаваться в конце итераций внутри различных фаз или даже чаще.

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

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

Обратите особое внимание на данный пункт – без него невозможна эффективная работа.

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

Вопросы:

  • Какой способ выбора базовых версий используется?
  • Для всех ли элементов базовые версии строятся по одинаковы правилам?
  • Кто разрешает создание базовых версий?
  • Кто физически создает базовую версию?
  • Как и по какому шаблону создаются базовые версии?
  • Как осуществляется продвижение базовых версий?
  • Как и кем осуществляется проверка базовых версий?
  • Какова периодичность проверок?
  • Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений?
  • Есть ли иерархия между объектами? Какая?
3.2 Контроль конфигураций и изменений Configuration and Change Control Как известно процесс УК состоит из двух частей – управление изменениями и управления версиями.

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

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

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

Вопросы:

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


3.2.1 Отработка и утверждение запросов на изменение
Change Request Processing and Approval Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений. Определяются типы запросов. Как правило это: Дефект, Запрос на расширение, Задача и Заявка. Состав типов может существенно меняться, главное не сводить все управление изменениями к одному типу запросов (очень часто кроме как Дефектами компании ничем не управляют)
3.2.2 Группа управления изменениями Change Control Board (CCB) Описывается, кто входит в состав группы управления изменениями и процедуры, которым она следует, для  отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы. Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не решаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется CCB.

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

Вопросы:

  • Каковы пределы полномочий группы?
  • Одна группа на все проекты или несколько групп — каждая на свой проект?
  • Если несколько, то, каким образом они сотрудничают друг с другом?
  • Есть ли иерархия CCB?
  • Кто отвечает за коммуникации между CCB?
  • Будет ли поддерживать система УК специальные запросы для организации встреч и выпуска протоколов по результатам?
  • Есть ли потребность в выработки регламента для ограничения действий группы (жесткий регламент встреч с высокой степенью формализма)?
  • Как различаются уровни привилегий в группе?
  • Меняет ли введение группы CCB установленный порядок принятия решений в организации?
  • Введены ли в состав CCB все ключевые участники, включая менеджера УК, менеджера проекта, лидера тестировщиков, лидера разработчиков и архитекторов?
  • Каковы процедуры устранения разногласий (выпуск протокола разногласий или нечто иное)?
  • Автоматизирована ли данная процедура?
3.3 Учет состояния конфигурации Configuration Status Accounting
3.3.1 Хранение материалов проекта и выпуск релизов
Project Media Storage and Release Process Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств.

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

3.3.2 Отчеты и проверки Reports and Audits Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации.

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

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

Здесь необходимо определить отчеты по ролям участников проекта и описать их формат.

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

Вопросы:

  • Есть ли необходимость в более чем одной ревизии для каждой базовой версии?
  • Вовлечены ли субподрядчики в ревизию?

Отчеты:

Вопросы:

  • Какие метрики собираются в ходе проекта?
  • Какие типы отчетов необходимо иметь?
  • Способы представления отчетной информации?
  • Есть ли внешние отчетные документы для клиентов?
  • Дифференцируются ли отчеты в зависимости от типа выполняемой участником роли в проекте?
  • Доступны ли отчеты?
  • Какие будут предусмотрены формальные шаги для получения отчетов?
  • Какие типы нотификационных сообщений будут применяться?
  • Отслеживаются ли тенденции в проекте? По каким отчетам?
  • Как ведется учет (статически, динамически)?
  • Какие средства используются для получения отчетов (допускается использование любого числа систем для получения достоверной Ии понятной информации о ходе проекта)?
3.3.3 Документирование Documents Раздел определяет способы и типы документов
3.3.3.1 Описание версии Version Description Данный документ описывает диски, CD или другие носители, используемые для поставки ПО.

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

Примерный состав документов:

  • Архив релизов с описанием (Release Media);
  • Описание релиза (Release Notes);
  • Описание функций;
  • Перечень решенных проблем в релизе;
  • Перечень новых возможностей;
  • Инструкция по установке ПО;
  • Инвентаризация, опись.

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

3.3.3.2 Документирование процесса CM Documents Общие документы, требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс. Типовые документы для данного раздела:

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

Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК.

4. Этапы Milestones Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта.
5. Обучение и ресурсы Training and Resources Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач
6. Субподрядчики и контроль программного обеспечения со стороны поставщиков Subcontractor and Vendor Software Control Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта К работе над проектом могут привлекаться субподрядчики. Данный раздел описывает каким образом будет происходить работа с субподрядчиком.

Вопросы:

  • Разработка ведется только в одно организации или в обеих?
  • Каковы процедуры корректировки дефектов в разрабатываемом продукте?
  • Автоматизированы ли они (полностью или частично)?
  • Какие изменения допустимо вносить Заказчику в исходные тексты после получения продукта?
  • Ставится ли в известность об этом субподрядчик, и в какой мере?
  • Когда и как выполняются ревизии?
  • Какой набор инструментальных средств используется Заказчиком и Субподрядчиком?
  • Необходимы ли дополнительные модули синхронизаций (для тех случаев когда Заказчик и Подрядчик используют разные системы УК от разных производителей)?
  • Как контролируется Субподрядная организация?
  • Кто отвечает за работу с Субподрядчиком?
  • Работает ли субподрядчик по своим процессам или Заказчик обязывает его работать по собственным?
  • Как решаются конфликты?
  • Разрешено ли Субподрядчику осуществлять полную сборку продукта у себя, или Заказчик выделяет стенд для сборки на своей территории?
  • Допускается ли Субподрядчик к справочной информации Заказчика (доступ к реальным базам данных, справочникам)?
Приложения Состав приложений не определяется стандартами. Обычно включает в себя такие документы как:

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

И т.д.

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

Полнота плана УК в зависимости от объема проекта и его типа

Японская мудрость гласит: «Чем завтра сто, лучше сегодня пятьдесят». Применительно к плану УК ее можно перефразировать как: «Лучше полплана сегодня, чем полный завтра».

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

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

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

Применяется следующая градация:

  • Малый — в этом проекте участвуют 2-7 разработчиков, тестировщиков почти нет, либо разработчики сами выполняют тестирование. Также в данную категорию могут попасть проекты, в которых нет параллельной разработки – то есть у каждого разработчика есть свой круг решаемых задач. Роли определены не четко. Команда находится в одной комнате;
  • Средний – это проект, в котором участвуют более 6 разработчиков. Ведется разработка коробочных продуктов на продажу. В команде есть выделенные роли: разработчики, тестировщики, аналитики, системные аналитики. Разделение достаточно четкое, но есть совмещение ролей. Все участники находятся в одном офисе, но в разных рабочих комнатах.
  • Крупный – тоже, что и средний, но возможно, работа над проектом ведется с несколькими субподрядчиками. Сама компания разбросана по нескольким регионам. В компании много параллельно идущих проектов.

Применена следующая градация:

  • Обязательность пункта – нужен ли данный пункт плана в проекте данного типа, можно ли отказаться от пункта без ущерба целостности логической стройности плана УК.
  • Детальность изложения – насколько глубоко необходимо проработать раздел. Какова его детальность? Нужно ли вносить дополнительные подпункты, раскрывающие значения основных пунктов?
  • Формальность изложения – этот пункт больше относится к стилю и коррелируется с детальностью и обязательностью. Для желательного раздела в маленьком проекте допускается нестрогий стиль изложения.

Таблица 3 – обязательность, формальность и глубина изложения пунктов плана УК.

Раздел плана

Тип проекта

Малый

Средний

Крупный

1. Введение

1.1 Назначение О НД НФ О СД Ф О СД Ф
1.2 Область применения О НД НФ О СД Ф О СД Ф
1.3 Определения, акронимы и сокращения Ж НД НФ О СД Ф О СД Ф
1.4 Ссылки П
О СД О СД Ф
1.5 Обзор Ж СД НФ О СД Ф О ВД Ф
2. Конфигурационное управление программным продуктом


2.1 Организация, распределение ответственностей и взаимодействия О СД Ф О СД Ф О ВД Ф
2.2 Инструментарий, рабочая среда и инфраструктура О СД НФ О СД Ф О ВД Ф
3. Программа конфигурационного управления
3.1 Конфигурационная идентификация О СД НФ О СД Ф О ВД Ф
3.1.1 Методы идентификации О СД НФ О СД Ф О ВД Ф
3.1.2 Базовые версии проекта О СД НФ О СД Ф О ВД Ф
3.2 Контроль конфигураций и изменений


3.2.1 Отработка и утверждение запросов на изменение Ж СД НФ О СД Ф О ВД Ф
3.2.2 Группа управления изменениями Ж СД НФ О СД Ф О ВД Ф
3.3 Учет состояния конфигурации
3.3.1 Хранение материалов проекта и выпуск релизов Ж СД НФ О СД Ф О ВД Ф
3.3.2 Отчеты и проверки Ж НД НФ О СД Ф О ВД Ф
3.3.3 Документирование
3.3.3.1 Описание версии О НД НФ О СД Ф О ВД Ф
3.3.3.2 Документирование процесса П П О ВД Ф
4. Этапы Ж НД НФ О СД Ф О ВД Ф
5. Обучение и ресурсы Ж НД НФ О СД Ф О ВД Ф
6. Субподрядчики и контроль программного обеспечения со стороны поставщиков П П О ВД Ф
Приложения П Ж НД НФ О ВД Ф

Сокращения к таблице:

О – обязательно; Ж – желательно, П – можно пропустить.

ВД – высокая детальность, СД – средняя детальность, НД – низкая детальность.

Ф – формально, НФ – неформально.

Как заставить участников читать план?

Подобная проблема встречается во всех организациях и касается не только плана. Зачастую исполнители не читают инструкций, планов, методик и всех прочих документов, так как считают это бесполезной тратой времени. Либо график работ настолько плотный, что просто не остается рабочего времени на чтение, а свободно тратить на «белиберду» никто не хочет. Руководство в попытках решить проблему, как правило, ограничивается только административными мерами (запугивание, обязаловка… и т.д.), что есть не совсем правильно. Жизненный опыт показывает, что нужно комбинировать сразу несколько методов, посредством которых можно заставить специалистов прочитать НМО, причем сделать так, чтобы инициатива исходила от них самих.

Опишем основные методы:

Таблица 4 – методы и принципы воздействия на исполнителей

Тип метода

Принцип

Административный

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

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

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

Составить опросный лист в виде теста, который позволит проконтролировать по основным позициям знания документа и основных принципов в нем изложенных (обыкновенного теста на 1,5-2 страницы вполне достаточно)

Руководители на всех уровнях сами должны сами наравне с остальными изучать документы

Процессно-административный

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

Выделить из большого документа (план УК + приложения) основные положения на 6-7 страниц. Основные положения позволят загруженным специалистам потратить меньше времени на понимание основных идей

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

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

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

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

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

Примеры содержимого (выдержки из разных планов)

Мы долго мучались над данным разделом: включать его в книгу или не включать? Ведь любой «живой» план УК является неотъемлемой частью организации и являет собой описание процесса разработки, что может являться (и должно являться) секретом для всех окружающих.

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

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

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

1. Введение

Настоящий документ предназначен для планирования и документирования процессов управления конфигурацией и управления изменениями в проекте «***»

В соответствии с ГОСТ Р ИСО/МЭК 12207 процесс УК включает в себя как задачи идентификации и контроля конфигураций ПС. Так и задачи контроля внесения изменений в ПС. План конфигурационного управления (ПКУ) описывает все задачи контроля конфигурации и изменений, которые будут выполняться в ходе проекта. ПКУ определяет последовательность выполнения задач, ролевые функции и ответственность участников проекта, и требуемые ресурсы, включая персонал, инструментарий и оборудование.

1.1 Назначение

(вариант 1)

Целью настоящего документа является определение, адаптация и описания процессов управления конфигурацией и изменениями при внедрении технологии фирмы IBM Rational Software для пилотного проекта создания и сопровождения системы «***».

(вариант 2)

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

1.2 Область применения

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

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

1.3 Определения, акронимы и сокращения

(вариант 1)

Термин

Толкование

VOB-сервер

(VOB Server)

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

Базовая линия

(Baseline)

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

(вариант 2)

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

Версионное хранилище (VOB, versioned object base) – репозиторий, хранящий версии файлов и директорий, результаты сборки и ассоциированные с ними метаданные.

1.5 Обзор содержания

Настоящий документ состоит из следующих разделов:

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

2. Конфигурационное управление программным продуктом

2.1. Организация, распределение ответственности и взаимодействия

(пример 1)

№ п/п

Роль

Обязанность

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

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

Менеджер УК

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

(Пример 2)

В ходе проекта разработки ПС УК применяется для поддержки всех основных процессов жизненного цикла ПС.

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

  • группа планирования;
  • группа мониторинга;
  • группа методологии;
  • группа проектирования;

    ***

    ***

    ***

В процессе УК используются следующие ролевые функции:

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

    ***

    ***

    ***

(пример 4)

Всеми полномочиями по управлению проектом и качеству наделяется группа проектного офиса, находящаяся в рамках организации. Тестирование осуществляет внешняя подрядная организация (она же Заказчик ПО).

Отел УК предоставляет проектному офису квалифицированный персонал для осуществления действий по УК и всю необходимую координацию совместных действий.

Рабочая организация делится на три группы: «Разработчики», «Технические писатели». Внешняя – «Тестировщики».

Все группы подчиняются менажеру проектного офиса.

Менеджер проектного офиса ответственен за все проектные решения. Он является председателем CCB.


Рисунок 1 – Иерархия проектных групп

***

***

***

(пример 4)

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


Рисунок 2 – Иерархия проектных групп

***

***

***

2.1.1 Взаимодействие участников проекта

(пример 1 — мультирегион)

Все участники проекта взаимодействуют на основе распределенного Репозитория в одном из двух режимов:

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

Локальный режим взаимодействия обеспечивается локально расположенными версионными хранилищами, входящими в состав репозитория, и стандартным интерфейсом Rational ClearCase и Rational ClearQuest.

Глобальный режим взаимодействия обеспечивается географически распределенными версионными хранилищами, входящими в состав репозитория и синхронизируемыми с помощью Rational ClearCase MultiSite. Для доступа к репозиторию пользователей используется стандартный интерфейс Rational ClearCase и веб-интерфейс Rational ClearQuest.

***
***

***

  1. Политика полномочий

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

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

Ставить элементы под УК могут:

  • Файлы польз. док. – тех. Писатели;
  • Файлы исходных текстов – Разработчики;
  • Проектная документация – Аналитики, Архитекторы, Разработчики (ПЗ);
  • Модели – Аналитики, Архитекторы;
  • Бинарники – Интеграторы;
  • Тестовые Скрипты – Тестировщики;
  • Планы – Архитектор (Рук.проекта).

Все операции с метками имеет право делать только интегратор.

Бренчи может создавать только интегратор.

Создавать или изменять профили может только интегратор или менеджер конфигурации.

(пример 1 формирование таблицы политики доступа. Отталкиваясь от ролей)

Роль

Объект

Разрешенное событие

Интегратор Все объекты VOB Rename, rmtype, mklbtype, mklabel, rmlabel, Mkbrtype, rmbranch, Rmelem, rmdir.
Бинарные файлы winkin
Исходные файлы merge –to <ПотокИнтеграции>,

merge –out <Поток БагФикс> -to <Поток Разработки>

Менеджер конфигурации
Все объекты Mkvob, rmvob, mktrtype, rmtype, mkcomp, rmcomp, Mkpool, rmpool, mkattype, rmattype, mkhltype
Профиль
Файлы и директории на уровне ОС Chown, chgrp

***
***

***
(пример 2 — формирование таблицы политики доступа. Отталкиваясь от операций)

Операции

Тип операции (pre-op/ post-op)

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

check-out

Pre-op

  1. Установить предварительную, необязательную на данном этапе ассоциацию с запросом на изменение.
check-in

Pre-op

  1. Установить ассоциацию с запросом на изменение.
  2. Проверка заполнения комментария к создаваемой версии элемента
rmattr

Pre-op

  1. Сообщение об ошибке «Данная операция не допустима! Обратитесь к Администратору УК.»
  2. Запрет действия.
rmhlink

Pre-op

  1. Сообщение об ошибке «Данная операция не допустима! Обратитесь к Администратору УК.»
  2. Запрет действия.
rmlabel

Pre-op

  1. Сообщение об ошибке «Данная операция доступна только Администратору УК. Обратитесь к нему для решения проблемы. Для удаления необходимо сформировать Поручение на удаление администратору УК»
  2. Запрет действия.
rmtrigger

Pre-op

  1. Сообщение об ошибке «Данная операция не допустима! Обратитесь к Администратору УК.»
  2. Запрет действия.

***
***

***

2.2 Инструментарий, рабочая среда и инфраструктура

***

***

***

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

Продукт

Назначение

Rational ClearQuest

Контроль изменений, планирование работ

Rational ClearCase

Версионный контроль

Rational SoDA

Автоматическая генерация проектной документации

Rational RequisitePro

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

Rational Rose

Разработка моделей ПС

Visual Studio 6.0

Средство разработки

Borland Delphi

Средство разработки

Microsoft Word
Numega Bound Checker

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

***

***

***

2.2.1 Рабочая среда

Окружение инструментария УК:

  • Операционная система Windowd 2000 Advanced Server для серверов ClearCase и ClearQuest.
  • СУБД MS SQL Server для хранилища данных ClearQuest
  • Операционная система Windows 2000 Professional / Windows XP Professional для клиентов. MS Office XP.
  • Все сервера и рабочие места являются членами домена Development.

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

Примечание:

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

2.2.2 Программно-аппаратный комплекс

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

  • Сетевое имя сервера/рабочей станции.
  • Используемая операционная система.
  • Используемое ПС.

2.2.3 Интерфейсы и интеграция

В проектах определяются используемые интерфейсы взаимодействия инструментов конфигурационного управления и управления изменениями для следующих пар взаимодействия:

  • Rational RequisitePro и ClearCase – интеграция на основе периодического внесения артефактов управления требованиями под версионный контроль в составе базовых версий.
  • Rational RequisitePro и ClearQuest – интеграция на основе стандартной схемы ClearQuest Enterprise, поставляемой Rational.
  • ***

***

***

***

2.2.4 Инфраструктура

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

БД ClearQuest используется для хранения запросов на изменения, возникающих в ходе проекта. Все проекты используют единую базу данных и единую схему обработки запросов на изменения.

БД ClearQuest входит в состав центрального репозитория и не реплицируется в локальные репозитории рабочих групп.

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

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

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

3.1 Конфигурационная идентификация

3.1.1 Методы идентификации

В процессе управления конфигурацией рассматриваются учетные элементы конфигурации, представленные в виде:

  • Файлов;
  • Директорий;
  • Наборов файлов и директорий.

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

Для идентификации учетных элементов в целом используются следующие типы метаданных:

  • Тип учетного элемента;
  • Наименование атрибута, установленного на учетный элемент;
  • Значение атрибута, установленного на учетный элемент.

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

  • Номер версии и наименование ветви учетного элемента;.
  • Метка, установленная на версию учетного элемента;
  • Наименование атрибута, установленного на учетный элемент или его версию;
  • Значение атрибута, установленного на учетный элемент или его версию.

3.1.1.2 Объекты идентификации

Рассматриваются следующие основные группы объектов конфигурационной идентификации:

  • Операционная система;
  • Программные средства;
  • Артефакты проекта, подразделяемые на следующие группы:
    • Артефакты управления требованиями;
    • Артефакты проектирования;
    • Артефакты разработки;
    • Артефакты тестирования;
    • Документация.

3.1.1.3 Виды файлов

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

Описание Тип файлов Расширения
C or C++ source file cplusplus_source *.cpp; *.c
C or C++ header file cplusplus_include *.hpp; *.h
Pascal source file pascal *.pas
XML file** xml *.xml; *.xsl
Module definition file module_definition *.def
Visual Studio project file devstudio_project_file *.vcproj
Visual Studio solution file devstudio_solution_file *.sln
Source Control file* vspscc_file *.vspscc
Assembler language source file assembler *.asm

Используются следующие правила наименования элементов и метаданных (исключая автоматически создаваемые метаданные):

  • Версионное хранилище. Имя версионного хранилища может состоять из букв, цифр и символа подчеркивания «_».
  • Ветвь. Имя ветви начинается с буквы и может содержать буквы, числа и символ «_». В наименовании ветви отражается ее функциональность (например, bug_fix). Используются только строчные буквы, чтобы по регистру отличать названия меток от названий ветвей.
  • Метка. Имя метки начинается с буквы и может содержать буквы, числа и символ «_». Используются только заглавные буквы, чтобы по регистру отличать названия меток от названий ветвей.
  • Атрибут. Имя атрибута начинается с буквы и может содержать буквы, числа и символ «_». В наименовании атрибута отражается его функциональность.

3.1.2 Базовые версии проекта

***

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

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

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

***

3.1.2.1 Принципы создания меток

***

  1. Все метки создаются заглавными латинскими буквами.
  2. Метка соответствует правилам именования билдов и релизов, а именно:
  • номер релиза состоит из 3-х частей X.YY.ZZZ;
  • X – номер версии;
  • YY – номер подверсии. При изменении номера версии обнуляется;
  • ZZZ – номер сборки. Сквозная нумерация от начала проекта.

На отлаженные версии в отладочном потоке ставится метка с префиксом BR.

***

3.1.2.2 Принципы создания ответвлений (бренчей)

***

Существует несколько типов бренчей:

Название типа бренча Описание Правила наименования Доступ
  1. Главный бренч
Является начальной точкой. main Никто
  1. Интеграционный бренч
Основной бренч проекта, в который интегрируются все изменения и в котором содержится сформированная версия проекта в целом. Интегратор Интегратор
  1. Бренч исправлений
Для каждого билда создается отдельный бренч исправлений. Все исправления должны осуществляться в данном бренче и затем интегрироваться в интеграционный бренч. После этого в интеграционном бренче проставляется метка и формируется фикс к данному билду. fixes_[MAJ]_[MIN]_[BLD] Разработчики, которые должны произвести определенные изменения

3.2 Контроль конфигурации и изменений

3.2.1 Отработка и утверждение запросов на изменение

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

3.2.1.1 Типы запросов на изменение

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

  • Запрос на развитие ПС. Этот тип запроса создается вручную и служит для регистрации запросов на внесение изменений, поступивших от пользователей или созданных участниками проекта;
  • Дефект. Этот тип запроса может генерироваться автоматически и служит для идентификации ошибок, обнаруженных в процессе тестирования. Используется для интеграции со средствами тестирования (Test Manager);
  • Задача. ***
  • Поручение. ***
  • Проект. ***

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

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

Запросы на изменения помещаются в записи БД ClearQuest «Enhancement Request» («Запрос на Развитие») или «Defect» («Дефект»).

Все запросы на изменения требований относятся к типу запроса на развитие ПС и регистрируются в качестве «Enhancement Request», затем анализируются, утверждаются и назначаются на исполнение.

Каждому назначенному на исполнение запросу «Enhancement Request», который разбивается на несколько заданий, ставится в соответствие один или более запросов типа «Defect», которые соответствую заданиям, выданным исполнителям для реализации первоначального запроса. Эти запросы связываются соотношением «parent-child», где «Enhancement Request» выступает как «parent», а «Defect» — как «child».

Такая связь позволяет определять готовность первоначального запроса на основании данных об исполнении заданий, связанных с ним. Первоначальный запрос закрывается только после того, как будут исполнены и закрыты все связанные с ним запросы типа «Defect».

3.2.1.1.1 Дефект

Атрибуты запроса типа «Дефект» представлены ниже

Атрибут

Описание

Id

Уникальный идентификатор дефекта в базе данных

State

Состояние дефекта

Инициатор

Идентификатор пользователя, инициировавшего дефект

Дата инициации

Дата инициации дефекта

Наименование

Короткое наименование дефекта

Детальное описание

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

Решить до

Дата, до которой дефект должен быть обработан и исправлен

Приоритет

Относительный приоритет дефекта

Важность

Важность дефекта

Исполнитель

Идентификатор пользователя, ответственного организацию исправления дефекта

Подсистема

Подсистема, которая должна быть модифицирована для исправления дефекта

***

***

***

Диаграмма активности Дефекта

Диаграмма активности записи «Дефект»

Описание действий, представленных на схеме, дано ниже

Описание действий по обработке Дефектов

Действие

Описание

Внести

Участники проекта подают запросы на устранение дефектов

Рассмотреть

Запрос в состоянии «Внесено» поступает на рассмотрение Руководителю проекта или Группе. Руководитель назначает ответственного либо разработчика, либо аналитика (в зависимости от типа дефекта) для исполнения запроса и далее направляет запрос:

  • В состояние «Подробнее»;
  • В состояние «Отложено»;
  • В состояние «Отклонено»;
  • В состояние «Анализируется»

***

***

***

Диаграмма состояний Дефекта


Диаграмма состояний записи «Дефект»

***
***

***

(Пример 2)

***
***

***

Отличительные особенности реализации используемой в проекте схемы:

  • Используются два типа записи:
  1. Запрос на развитие
  2. Дефект
  • Для автоматизации процессов используется инструментальное средство ClearQuest
  • Для работы с БД запросов на изменение и дефектов используется СУБД Oracle версии 8.* или выше.
  • Используется единая последовательность отработки запросов на изменения и дефектов, включая перечень возможных состояний и действий, переводящих запись из одного состояния в другое.
  • Типы записей «запрос на развитие» и «дефект» отличаются по:
  1. Составу полей;
  2. Используемым формам интерфейса пользователя;
  3. Скриптам, автоматически запускаемым при наступлении определенных событий с записью.
  • Заполнение полей производится двумя способами:
  1. Автоматизированным. Данный способ возможен при интеграции ClearQuest со средствами тестирования Rational. При автоматизированном заполнении частично заполняются некоторые поля в соответствии с контекстом тестирования;
  2. Ручным. Основной способ, при котором контроль над всеми полями лежит на человеке.
  • В запросах допускается использование комбинирования способов заполнения

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

Состав основных полей представлен отдельно для каждого типа записи.

Описание процедуры обработки запросов на развитие ПС и дефектов

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

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

Порядок выполнения процедуры

***
***

***

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

***
***

***


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

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

Запрос в состоянии «Представлен» поступает на рассмотрение Руководителя проекта. Далее, руководитель проекта, который должен назначить ответственного разработчика для исполнения запроса, в соответствии с важностью запроса и его значимости для проекта, выполняет следующее:

  • поручает выполнение Запроса конкретному разработчику — «Назначить»;
  • завершает выполнение Запроса — «Закрыть».

***
***

***

Описание состояний

Настоящее представление уточняет порядок выполнения процедуры в части детализации описания состояний Запроса.

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

Описание состояний Запроса на устранение дефекта

Состояние

Полномочная роль

Допустимые параметры

Обязательные параметры

1 Представлен Инициатор запроса Важность

Новое сопровождение

Описание дефекта

Проявление дефекта

Содержание дефекта

Детальное описание

Важность

Описание дефекта

2 Назначен Руководитель проекта Новое сопровождение

Проявление дефекта

Разработчик

Детальное описание

3 Открыт Разработчик Новое сопровождение

Проявление дефекта

4 Реализован Разработчик Новое сопровождение

Проявление дефекта

Новое сопровождение

***
***

***

3.2.2 Группа управления изменениями

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

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

Основная цель деятельности группы управления изменениями – обеспечение целостности ПС на протяжении всего жизненного цикла. В ее состав входят представители всех рабочих групп.

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

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

3.3 Учет состояния конфигурации

3.3.1 Хранение материалов проекта и выпуск релизов

Материалы проекта находятся под версионным контролем. Структура версионных хранилищ определяется в зависимости от типа хранилища:

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

3.3.1.1 Резервирование данных

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

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

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

3.3.2 Отчеты и проверки

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

Используются следующие типы отчетов:

  • Отчеты по срокам, которые показывают данные о сроках пребывания заданий и запросов в том или ином состоянии.
  • Отчеты по количеству, которые показывают данные о количестве заданий и запросов, имеющих определенные параметры
  • Отчеты о тенденциях, которые показывают данные о соотношении заданий и запросов, отличающихся по какому-либо параметру и за определенный период. Например, открытых и закрытых.

    В проекте используются следующие отчеты

Название отчета Параметры Описание
Информация по пользователям
  • Пользователи
  • Период времени
Данный отчет необходим для получения информации по изменениям, которые произвели пользователи за указанный период времени.

В отчете будет содержаться следующая информация:

  • Список действий, которые совершал пользователь
  • Список файлов и версий, которые пользователь создал или изменил
  • Изменения, которые пользователь произвел.
  • Число и список checkout файлов
Информация по файлам
  • Файлы
  • Период времени
Данный отчет необходим для получения информации по изменениям, которые были произведены в файлах за указанный период времени.

В отчете будет содержаться следующая информация:

  • Список пользователей, которые работали с файлом;
  • Список действий, произведенных над файлом;
  • Изменения, которые производили пользователи;
  • Находится ли файл в checkout и в каком количестве.
Submitted enhancements
  • Запрос на расширение
Отчет по запросам на изменение, которые были созданы. Все запросы из данного отчета должны периодически выноситься на обсуждение CCB для принятия решения о дальнейшей их судьбе.
Approved enhancements
  • Запрос на расширение
Запросы на изменение, принятые CCB для реализации. Менеджер проекта должен постоянно следить за запросами из данного списка и руководить процессом реализации запросов в жизнь. Также запросы из данного списка могут быть обсуждены CCB для выяснения причин, по которым еще не принято решение по реализации.
Отчет по срокам зарегистрированных Количество вновь зарегистрированных запросов за период
Отчет по закрытым запросам Количество закрытых запросов за период
Отчет по состояниям за период Количество запросов по всем состояниям за период
Отчет по количеству запросов Количество открытых запросов на данный момент
Отчет о тенденциях в проекте Соотношение количества открытых запросов к закрытым

4. Этапы

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

В проекте участвуют специалисты «***», выполняющие ролевые функции, определяемые для каждой группы проекта и представленные в приложении

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

Примечания:

В разделах не рассмотрены следующие разделы:

Структура каталогов изделия

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

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

Финальный план УК государственной компании

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

1.    Введение

1.1.    Цель документа

1.2.    Нормативная основа

1.3.    Сведения о документе

1.4.    Термины, сокращения и определения

2.    Идентификация объектов конфигурационного управления

2.1.    Разрабатываемые конфигурации продукта

2.2.    Описание платформ разработки

2.3.    Физическая архитектура системы

2.4.    Идентификация подсистем

2.5.    Описание инструментальных средств

2.6.    Описание объектов конфигурационного управления

2.7.    Структура базы данных конфигурационного управления

2.8.    Стандарт именования

3.    Порядок сборки и формирования версий

3.1.    Взаимозависимости подсистем

3.2.    Порядок разработки

3.3.    Порядок сборки

3.4.    Порядок формирования версий

4.    Распределение ролей в проекте

4.1.    Руководитель проекта

4.2.    Интегратор (ответственный за управление конфигурацией проекта)

4.3.    Руководители подпроектов

4.4.    Права доступа

Финальный план УК системного интегратора

Данный план был разработан для компании системного интегратора. Основная особенность плана – использование средства IBM Rational ClearCase сразу в двух вариантах — базовом и UCM. Обычно выбирается только одна модель работ в проекте, но в данном случае пришлось выбирать сразу обе.

  1. Введение
    1. Цель
    2. Область действия
    3. Определения, акронимы и аббревиатуры
    4. Ссылки
    5. Обзор
  2. Организация и рабочая среда процессов конфигурационного управления
    1. Организация процессов конфигурационного управления
    2. Ролевые функции в процессе конфигурационного управления
    3. Инструментарий и рабочая среда
    4. Рабочая среда
    5. УК в режиме базового (base) ClearCase
  3. Архитектура проекта конфигурационного управления
    1. Регионы
    2. Версионные хранилища
    3. Разделение доступа к объектам
  4. Настройка рабочего пространства
  5. Программа конфигурационного управления
  6. Конфигурационная идентификация
  7. Выпуск релизов
  8. Контроль изменений и конфигурации
  9. Процессы конфигурационного управления в жизненном цикле проекта
  10. Интеграция средств УК с другими средствами:
    1. Интеграция ClearCase и ClearQuest
    2. Интеграция ClearCase и RequisitePro
    3. Интеграция ClearQuest и Bound Checker
  11. УК в режиме UCM
  12. Архитектура проекта конфигурационного управления
    1. Регионы
    2. Версионные хранилища
    3. Разделение доступа к ОКУ
  13. Проекты UCM
    1. Потоки
    2. Настройка рабочего пространства
  14. Программа конфигурационного управления
    1. Конфигурационная идентификация
      1. Выпуск релизов
      2. Контроль изменений и конфигурации
    2. Интеграция ClearCase с другими инструментами Rational
    3. Интеграция ClearCase и ClearQuest
    4. Интеграция ClearCase и RequisitePro
  15. Управление изменениями
  16. Репозиторий ClearQuest
  17. Типы запросов на изменение
  18. Enhancement Request
  19. Defect
  20. Схема обработки запросов на разных стадиях проекта
  21. Типы записей, используемые в режиме Base ClearCase
  22. Типы записей, используемые в режиме UCM
  23. Стадия ТЗ – Inception
  24. Стадия «Технический проект» (ТП – Elaboration)
  25. Стадия «Рабочий проект» (РП – Construction)
  26. Стадия «Ввод в действие» (ВД– Transition)
  27. Учет состояния конфигурации
  28. Хранение материалов проекта
  29. Отчеты и аудит
  30. Этапы
  31. Обучение участников проекта
  32. Создание рабочей среды конфигурационного управления проектом
  33. Отработка процессов конфигурационного управления
  34. Доработка технологии конфигурационного управления
  35. Контроль программного обеспечения от поставщиков

Начальная версия плана УК билинговой компании

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

1.Введение

2.Описание основных процессов системы конфигурационного управления

2.1     Информационные хранилища

2.2    Структура проекта

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

2.4     Основные процессы

2.5    Ролевые функции и обязанности участников процесса УК

3. Накопление, обобщение и анализ информации

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

Данный пример показывает гипотетический план из стандарта IEEE Std 828-1990. Особенности плана:

  1. Обеспечить разработку систему управления в реальном времени среднего размера для управления транспортными средствами. Датчики используются для ввода информации в систему, а показы используются, чтобы поддержать человеко-машинный интерфейс.
  2. Длительность проект примерно 3-3,5 года
  3. Большинство работ выполняется в главном офисе подрядчика с некоторой работой, выполняемой в соседнем филиале
  4. У компании есть большой опыт в плане УК.
  1. Введение
    1. Цели
    2. Scope
    3. Акронимы и определения
    4. Ссылки
  2. Управление
    1. Организация
    2. Обязательства по выполнению SCM
      1. Конфигурационная идентификация
      2. Конфигурационный контроль
      3. Отслеживание статуса
      4. Проверки и аудит
      5. Configuration Control Board
    3. Выполнение Плана УК
      1. CCB
      2. Базовые версии
      3. Списки и процедуры отчетов и аудитов
      4. Управление Конфигурациями средств разработки
      5. Применяемая политика, директивы и процедуры
  3. Действия УК
    1. Конфигурационная идентификация
      1. Документирование
      2. Части ПО
      3. Конфигурационная идентификация функциональных базовых версий
      4. Конфигурационная идентификация базовых версий в разработке
      5. Конфигурационная идентификация продуктовых базовых версий (законченных)
    2. Контроль конфигурации
      1. Функции CCB
      2. Запросы на изменение
      3. Авторизация изменений
      4. Автоматизация запросов на изменение
    3. Учет статуса
    4. Аудит
      1. Функциональный аудит
      2. Физический аудит
      3. Просмотр
    5. Инструментальные средства процесса УК
    6. Управление субподрядчиком
      1. Программное обеспечение Заказчика
      2. Программное обеспечение Субподрядчика
      3. Совместное ПО

ПРИЛОЖЕНИЯ

Приложение А «Управление запросами на изменения»

Приложение Б «Создание начальной базовой версии»

Приложение В «Процедура изменений»

Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа (полная версия), 10.0 out of 10 based on 3 ratings

Связные и просто интересные записи:

Метки: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, атрибут, версии, взаимодействие, видео, внедрение, времени, заказчик, изменение, изменениями, инструмент, инструменты, клиент, код, коммуникации, конфигурации, конфигурациями, метрики, небо, обсуждение, оператор, план, планирование, ПО, подряд, подход, поле, проект, процесс, регламент, система, сложность, состояние, специалист, стандарт, субподряд, требования, труд, УК, управление, фактор

3 comments to Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа (полная версия)

Leave a Reply

 

 

 

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