Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2007 г.

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

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

Александр Новичков, www.cmcons.com

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

Что такое план УК?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт

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

Комментарии

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

НЕТ

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

CMM/CMMI

НЕТ

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

ISO 10007-95

Частично

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

IEEE Std 828-1990 и Std 1042-1987

ДА

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

Microsoft Solution Frameworks

ДА

 

Rational Unified Process

ДА

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

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

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

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

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

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

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

Фактор

Возможные значения

Воздействие, описание

Тип проекта

Разработка модели (прототипа)

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

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

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

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

 

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

Один офис

Более одного

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

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

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

Малый

Средний

Большой

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

Количество конфигурационных элементов

 

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

Количество компонентов и подсистем

 

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

Фаза жизненного цикла

 

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

Модель разработки

 

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

Доступность (наличие) средств УК и иных смежных средств

Базовые

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

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

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

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

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

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

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

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

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

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

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

Разрозненные

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

Высокий

Средний

Низкий

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

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

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


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

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

Таблица 3 - Структура плана УК

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

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

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

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

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

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

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

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

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

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

Раздел плана

Тип проекта

Малый

Средний

Крупный

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. Субподрядчики и контроль программного обеспечения со стороны поставщиков П     П     О ВД Ф
Приложения П     Ж НД НФ О ВД Ф

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

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

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

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

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...