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

Раздел плана

Раздел плана

Требования к содержанию

Дополнительные комментарии

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

Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта

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

Вопросы:

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

Приложения

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

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

И т.д.

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