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

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

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

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

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

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

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

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

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

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

В зависимости от размера проекта некоторые пункты плана могут быть пропущены.

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

• Предисловие к материалу
• Введение в управление конфигурацией программных средств
  • Базовые концепции и элементы
• Управление конфигурацией в стандартах
  • Виды стандартов

Предисловие к материалу

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

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

Вот здесь и возникает потребность перехода на иную качественную ступень. И это обусловлено не только тем, что руководство компании желает из альтруистических побуждений повысить уровень качества изделия - вовсе нет! Улучшение качества - важное условие выживания IT-компаний в современных рыночных условиях.

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

К сожалению, в российской печати и российском же Интернете практически нет достойных книг и статей, которые детально раскрывали бы Цели и Задачи процесса, описывали бы их (все материалы либо коммерческие либо банальные перепечатки слово в слово стандартов). К тому же имеет место низкая культура разработчиков, считающих УК неким видом тотального контроля над собой (если не насилия). В этом их заблуждение. Любой формализованный процесс - это не насилие, а благо, и мы надеемся это объяснить. К нашей радости, ситуация в России в плане отношения к процессу УК последний год начала резко меняться: начинаются разработки крупных программных продуктов, разработка которых невозможна без данного процесса.

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

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

Полезные ссылки перед прочтением, чтобы войти в курс дела: Проблемы разработки ПО , Осознание необходимости в УК , Что такое RUP)

Приятного чтения.

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

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

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

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

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

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

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

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

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

Затем было решено, что разрабатываемый конечный продукт будет называться «конфигурационным объектом » (configuration item ). Конфигурационные объекты (КО) могут представлять собой стол или самолет, если рассматривать оборудование, или программные средства в виде инсталляционных пакетов, если речь идет о программных средствах.

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

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

Затем они занялись определением набора документов, который является критически важным для успешной разработки. Такой набор документов должен содержать, как минимум, требования, спецификации, дизайн, модели (чертежи), перечень компонентов, тестовую документацию, исходные коды и документацию пользователя. Требовалось общее выражение для обозначения любого из этих документов или всех документов, описывающих конфигурационный объект, для проекта любого размера. Так как основное предназначение этих документов было в «идентификации конфигурации» объекта, этот набор документов назвали «конфигурационной идентификацией » (configuration identification ). Тогда это казалось разумным, но сейчас мало кто считает, что «конфигурационная идентификация» означает «документы».

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

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

Базовые процедуры управления конфигурацией

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

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

Другой способ - сравнение разрабатываемого документа с документами более высокого уровня, которые были утверждены ранее в процессе разработки. Для этой работы было использовано понятие «ревизия» (review) с добавлением слова «конфигурация». «Ревизия конфигурации» (configuration review ) представляет собой сравнение документа низкого уровня с предшествующим ему документом или документом верхнего уровня с тем, чтобы удостовериться, что документ нижнего уровня удовлетворяет всем требованиям, присутствующим в документе верхнего уровня, и нет никаких неожиданных добавлений. Это позволяет постепенно и аккуратно детализировать требования верхнего уровня в документах низкого уровня, уточняя конфигурационную идентификацию по мере разработки конфигурационного объекта.

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

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

Еще один способ гарантировать точность конфигурационной спецификации - иметь специальную группу (возможно, состоящую из одного специалиста), которая отслеживала бы все предлагаемые изменения продукта и отвергала или одобряла их. Такая деятельность получила название «контроль конфигурации » (сonfiguration сontrol ). Группы, выполняющие функции контроля конфигурации обычно получают название «Группа контроля над изменениями » (Change Control Board ) или «Группа контроля конфигурации » (Configuration Control Board , сокращенно CCB ). Среди важных функций такой группы - контроль того, что все документы являются актуальными в каждый момент времени и того, что при внесении изменения сначала изменяются документы конфигурационной идентификации, а уже после - сам объект изменений (исходный код, модель и т.п.). Изменение объекта после изменения его описания выгодно еще и тем, что исполнитель, вносящий изменение в объект, будет иметь возможность ознакомиться с описанием этого изменения до начала работы.

Другой областью ответственности управления конфигурацией стала подготовка отчетности о состоянии продукта и состоянии утвержденных изменений на протяжении всего хода работ. Эта деятельность получила название «учет состояния конфигурации » (configuration status accounting )

Базовые концепции и элементы

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

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

1. Документы создаются для описания продукта и являются средством управления конфигурацией продукта.
2. Изменения в продукте контролируются посредством контроля изменений в документации.
3. Изменения в продукте не производятся до тех пор, пока они не сделаны в документации.
4. До того, как быть реализованными в документации и продукте, изменения должны быть формально утверждены.
5. Все изменения должны отслеживаться.
6. Конфигурационные объекты (продукты), документы и их версии нумеруются и именуются единообразно и недвусмысленно (или уникально).
7. Ведется отчетность о состоянии изменений, документов и продуктов.
8. Каждый документ периодически сравнивается с соответствующим ему документом верхнего уровня на предмет выявления несоответствий.
9. Продукт в целом сравнивается со своим описанием (конфигурационной идентификацией) и должен этому описанию соответствовать.

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

1. Конфигурационная идентификация (концепция 1)
2. Контроль конфигурации (концепции 2, 3, 4, 5, 6)
3. Учет состояния конфигурации (концепция 7)
4. Ревизия и аудит конфигурации (концепции 8 и 9)

Такова была первоначальная концепция управления конфигурацией как для программных средств (software), так и для оборудования (hardware). Представленную здесь первоначальную терминологию дисциплины управления конфигурацией можно также найти в стандарте IEEE-STD-610. Далее будут рассмотрены стандарты, определяющие основные положения и терминологию управления конфигурацией.

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

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

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

С момента формального основания дисциплины управления конфигурацией, которое можно условно отсчитывать от даты введения стандарта IEEE-STD-610, она рассматривалась с разных точек зрения и в различных приложениях. Был накоплен богатый опыт использования процедур управления конфигурацией в различных проектах, который обобщался с точки зрения различных стандартов и моделей программной инженерии.

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

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

К основным элементам процесса управления конфигурацией можно отнести (см. рисунок 1.) следующие четыре элемента:

1. Конфигурационная идентификация.
2. Контроль конфигурации.
3. Учет состояния конфигурации.
4. Ревизия и аудит конфигурации.

Рисунок 1. Основные элементы процесса управления конфигурацией

Рассмотрим подробнее состав каждого из этих элементов.

Конфигурационная идентификация основывается на следующих составляющих:

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

Контроль конфигурации включает:

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

Учет состояния конфигурации предполагает:

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

Ревизия и аудит конфигурации включает:

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

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

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

Виды стандартов

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

Все стандарты можно условно разделить на виды, в зависимости от широты их области действия:

1. Международные стандарты, действующие без ограничений во всех странах;
2. Государственные или отраслевые стандарты, действующие для группы предприятий или организаций, объединяемых некоторыми общими признаками;
3. Внутренние стандарты предприятия, действующие для конкретного предприятия и учитывающие специфику этого предприятия.

Некоторые часто используемые международные стандарты приведены ниже (см. таблицу 1). В таблице «SCM» обозначает возможность использования стандарта для УК ПС (software configuration management), а «HCM» - для оборудования (hardware configuration management). В рассматриваемой таблице выделены три наиболее значимые области использования стандартов:

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

Таблица 1. Международные стандарты, описывающие процесс УК

Стандарты и руководства	Область действия		Описание
	Процесс приобретения	Процесс поставки/ разработки
IEEE/EIA 12207.0-1996, Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes			Устанавливает общую структуру процессов жизненного цикла (ЖЦ) программных средств.
IEEE/EIA 12207.1-1996, Lifecycle data.
IEEE/EIA 12207.2-1996, Implementation Considerations
ISO 9000-3: Quality Mgmt & Quality Assurance Stds-Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software

В качестве примера отраслевого стандарта можно привести MIL-STD-2549 «Configuration Management Data Interface», который детализирует требования для обмена данными между правительственными системами конфигурационного управления.

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

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

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

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

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

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

Управление изменениями как составная часть процесса УК

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

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

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

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

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

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

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

Один из таких стандартов - ГОСТ Р ИСО/МЭК 12207 - рассматривается ниже.

Процесс УК в стандарте ГОСТ Р ИСО/МЭК 12207

Почему при выборе стандарта, определяющего процесс управления конфигурацией, для подробного рассмотрения мы остановились на стандарте ГОСТ Р ИСО/МЭК 12207 «Информационные технологии. Процессы жизненного цикла программных средств»? Для этого есть несколько важных причин:

1. Стандарт ГОСТ Р ИСО/МЭК 12207 является российским стандартом, официально введенным в действие на территории Российской Федерации.
2. Рассматриваемый стандарт создан на основе одного из наиболее популярных международных стандартов в сфере информационных технологий - ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes.
3. Популярные методологии разработки ПС (такие как Rational Unified Process) основываются на ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes.

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

Российский стандарт ГОСТ Р ИСО/МЭК 12207 рассматривает процессы жизненного цикла (ЖЦ) программных средств (ПС) и подразделяет их на три группы:

1. Основные.
2. Вспомогательные.
3. Организационные.

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

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

Рисунок 2. Процессы жизненного цикла ПС по ГОСТ Р ИСО/МЭК 12207.

В соответствии с рассматриваемым стандартом, данный процесс состоит из следующих работ:

1. подготовка процесса;
2. определение конфигурации;
3. контроль конфигурации;
4. учет состояний конфигурации;
5. оценка конфигурации;
6. управление выпуском и поставка.

Ниже приведены краткие описания всех работ процесса.

Подготовка процесса

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

Определение конфигурации

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

Контроль конфигурации

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

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

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

Оценка конфигурации

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

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

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

Управление конфигурацией с точки зрения Capability Maturity Model

CMM (Capability Maturity Model) - модель зрелости процессов создания ПО, или эволюционная модель развития способности компании разрабатывать качественное программное обеспечение.

Изначально CMM разрабатывалась и развивалась как методика, позволяющая крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В итоге авторам удалось достичь такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, стремящихся качественно улучшить существующие процессы разработки, привести их к определенным стандартам.

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

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

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

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

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

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

(4) Управляемый уровень (managed level ). Уровень, при котором устанавливаются количественные показатели качества.

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

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

Хотя в России знают аббревиатуру СММ, в большинстве организаций не представляют себе, каким образом можно добиться качественного скачка. И дело не только в том, что неизвестно направление этого скачка, а в том, что каждой отдельно взятой компании довольно трудно выстроить свои процессы под требования CMM самостоятельно, без внешнего вмешательства. А зачем изобретать велосипед? Не проще ли взять готовый набор решений (например методологию, IBM Rational Unified Process или аналогичную), внедрить их (здесь уже можно и своими силами обойтись), получив готовый набор решений для качественного построения процесса Управления Конфигурациями, а уж затем приглашать специалистов и аттестоваться на определенный уровень? В России уже есть примеры компаний, которые аттестовались на более высокий уровень СММ именно благодаря внедрению решений на основе IBM Rational Unified Process . Вы можете найти их поиском в Интернет.

На Западе технологии компании IBM Rational сегодня уже широко используют для оптимизации процесса выпуска ПО. Причин тому несколько: во-первых, IBM Rational Software - практически единственная компания, которая четко описала весь производственный цикл по выпуску программного обеспечения (IBM Rational Unified Process), определила все возможные виды документов, сопровождающие проект, строго расписала роли (входные/выходные документы, шаблоны документов и пр.) каждого участника проекта. Во-вторых, компания создала специальное программное обеспечение для качественного исполнения как каждого этапа в отдельности, так и всего проекта в целом. Важно и то, что IBM Rational посредством RUP предлагает перейти от программирования как искусства к программированию как к науке, где все понятно и прозрачно благодаря научному подходу к разработке. По некоторым оценкам западных аналитиков, соотношение возврата капитала до и после внедрения процессов варьируется от 5:1 до 8:1.

Требования к процессу УК в СММ

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

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

Все данные из ключевых областей процесса (Key Process Area ) охватывают возможные методы исполнения функции конфигурационного управления. В СММ все качественные требования представляются именно как KPA. Каждый из этих методов четко описывает определенный участок с формализованными требованиями, а RUP способен привести этот участок в соответствие означенному требованию.

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

Ниже приведены требования CMM к процессу конфигурационного управления с вольными авторскими комментариями. Это требования 2 и 3 уровней. Хочется отметить, что внедрение УК в соответствии с RUP автоматически дает уровень 3 CMM

Цели процесса УК:

1. Управление конфигурацией происходит на плановой основе

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

2. Все изменения происходят управляемо

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

Обязательства по выполнению

1. Проект следует документированной организационной политике

1.1. Есть ответственные за выполнение проекта

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

1.2. УК реализуется на протяжении всего жизненного цикла разработки

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

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

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

1.4. Все проекты имеют собственный репозиторий

(Примечание: здесь приводятся только основные требования к процессу. В стандарте СММ их существенно больше. Пропуски отмечены символами "*". Более подробную информацию о стандарте можно получить на сайте SEI-CMM)

4. Работы по УК должны быть обеспечены ресурсами

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

4.1. Назначение менеджера УК

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

4.2. Назначение администратора УК

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

4.3. Работы обеспечены инструментальными средствами и оборудованием

5. Участники УК должны пройти обучение целям, процедурам и методам выполнения работ по УК

6. Члены группы разработки ПО должны пройти обучение по своим задачам

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

Операции

1. Для каждого проекта готовится план УК

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

1.1. План разрабатывается на ранних стадиях общего планирования проекта

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

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

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

1.3. План должен быть доступен и управляем в части его изменений

3. Устанавливается библиотечная система УК, служащая репозиторием проекта

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

3.1. Многоуровневая поддержка контроля УК

3.2. Хранение и извлечение элементов конфигурации

3.3. Совместное использование элементов группами разработчиков

3.4. Помощь в применении производственных стандартов УК

3.5. Хранение и извлечение архивных версий

3.6. Обеспечение корректного создания продуктов

3.7. Хранение и обновление записей по УК

3.8. Поддержка создания отчетов

3.9. Поддержка структуры и содержимого библиотеки

4. Идентификация промежуточных программных продуктов, находящихся в системе УК

4.1. Выбор элементов на основании документированных критериев

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

4.3. Определяются характеристики каждого блока конфигурации

4.4. Определяются базовые линии

4.5. Для каждого блока определена стадия разработки, на которой он помещается в систему УК

4.6. Определен ответственный за каждый элемент

6. Изменение базовых версий (baseline) происходит подконтрольно, в соответствии с документированной процедурой

6.1. Выполнение проверок и регрессионных тестов

6.2. Внесение в библиотеку базовых версий лишь утвержденных блоков конфигурации

6.3. Внесение и извлечение блоков конфигурации не нарушает целостность проекта

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

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

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

8. Запись статуса элементов конфигурации в соответствии с документированной процедурой

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

8.2. Иметь возможность восстановить прежние версии файлов

8.3. Ведение истории изменений

Измерения и анализ

1. Выполнение измерений и использование их результатов для определения состояния работ по УК

Все, с чем мы сталкиваемся в жизни, можно измерить. Процесс УК не исключение - его тоже можно измерить. Мало того, ЕГО НУЖНО измерять. Ведь при активной работе в репозитории (хранилище) скапливается огромное число статистических сведений. Формирование отчетов и аналитических срезов - есть неотъемлемая часть как процесса разработки вообще, так и УК в частности. Ведь только на основе анализа собранной статистики можно принимать решения о дальнейших действиях. СММ оговаривает только самые важные срезы и отчеты.

1.1. Отчеты по количеству запросов за единицу времени

1.2.Отчеты по выполнению этапов работ по УК в сравнении с планом

1.3. Отчеты по объему выполненных работ по УК

1.4. Отчеты по ресурсам

Вместо заключения

Хочется напомнить, что здесь приведены только самые основные ключи СММ. Остальное смотрите в стандарте.

Но перед тем, как вы закроете данную статью - выпишите требования к процессу, выдвигаемые СММ и сравните с тем, как обстоят дела в вашей компании. Мы будем рады, если хотя бы 50% требований у вас совпало!

Если это не так, то вам нужно серьезно задуматься над улучшением процесса УК.

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

Потом все чуть-чуть повзрослели. Появились и начали как-то использоваться redmine/jira/etc, git/svn, jenkins, spinx-docs/rubydoc/doxygen/etc, wiki, unit тесты. Появились подпроекты, стенд подрос. Production сервачков стало несколько. Админ поднял salt/puppet/etc, мониторинг, сидит в своем логове как паук, правит конфиги на salt-master и дергает оттуда state.highstate.

Жизнь

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

Стадий жизненного цикла всего семь.

1. Conceptual design. На этом этапе надо понять, что вообще надо делать.
2. Architectural design. На этом этапе надо понять как это нужно делать.
3. Implementation. Это непостредсвтенно кодинг и unit тестирование.
4. Verification. Проверка того, что все задуманные функции программа выполняет.
5. Validation. Проверка того, что программой таки можно пользоваться. Из предыдущего пункта это внезапно не следует.
6. Ввод в эксплуатацию. В нее обычно входят выкатка релиза, миграция данных, обучение пользователей.
7. Собственно сама эксплуатация.
8. Вывод из эксплуатации

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

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

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

Что может сломаться?

Версии библиотек. Собрались, набросали диаграмку классов, договорились использовать libcrutch. Одна команда давно и долго сидела на libcrutch-1.0, вторая о ней только узнала и скачала из Интернета libcrutch-2.0. А выясниться это только на интеграционном тестировании. Словить bug можно даже на отличиях libcrutch-1.2.14 и libcrutch-1.2.15. А всякие LD_PRELOAD или docker только подливают масла в огонь. Даже если проект весь из себя на микросервисах, в интерфейсы может быть венесен обмен данными, полученными из libcrutch и имеющими в разных версиях разный формат.

Несоответствие версий компонент. Одни пилят libbase, другие libManagementFacade. В процессе выяснилось, что в libbase-1.14.3 есть мелкий но коварный bug. Поговорили, поправили, забыли. Тестировались на libbase-1.14.4, а в релиз ушло libbase-1.14.3.

Изменение конфигурации окружения. Один POST запрос внезапно начал работать долго. Посмотрели, он не такой уж и важный, пусть себе поработает.Увеличили в nginx таймаут ожидания ответа backend"а. Админ на стенде поправил и забыл. Выкатились и опять старые баги ловить, но теперь уже в боевых условиях.

Изменение проектных решений. Начинали делать под Windows, потом прониклись идеями RMS"а, решили перейти на Ubuntu, но до всех решение не довели. Начали собирать, все принесли deb пакеты, а кто-то, кто был в танке, exe"шник.

Потеря значимого для пользователя функционала. Принесли новую версию, долго рассказывали про смену дизайна, про новые фреймворки, про передовые алгоритмы. Пользователи послушали, головой покивали, и сказали: «Это все хорошо, но вы для нас по нашей просьбе формочку делали. Раньше она была пятым подпунктом в третьем пункте меню, где она теперь?» Потеряли на каком-то merge request"е.

Что делать

Программистам очень повезло, что есть git. Основной удар он берет на себя и от них самих требуется совсем чуть-чуть.

1. Определить все компоненты, которые нужны для функционирования проекта, убедиться, что они корректно версионируются. Конфигурация в первом приближении это список компонент и их версий.
2. Понять как обеспечивается перенос конфигурации со стенда в production.
3. Начать управление требованиями. Вообще говоря, управление требованиями это отдельный процесс. В рамках управления конфигурацией нужно убедиться, что для каждого компонента, попавшего в релизный набор, прилагается документация, в которой точно описаны требования, предъявленные к этому компоненту, и их cтатуcы: выполнено, не выполнено, выполнено частично, с оговорками.
4. Да и вообще у каждого компонента должна быть документация, которая описывает что как и зачем он делает.

На этапе завершения conceptual design"а , когда специалисты предметники говорят: «Такая система нам нужна!», - технари в один голос заявляют «Сделаем!», - менеджеры дают отмашку: «Ресурсы выделим - делайте!», - нужно убедиться, что согласованное описание системы из головы экспертов вынуто, на требования порезано и в документацию положено. В процессе разработки это описание будет меняться. Надо убедиться, что описание версионируется. Неплохой вариант, если это текст, забрать его в git

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

На этапе разработки нужно убедиться, что код документируется. Неплохо на модули заводить отдельные документы (в git), которые описывают требования к ним и их особенности поведения. Оставлять много информации в redmine/jira не стоит. После допила большой фичи, перед merge"ом в master, нужно убедиться, что ее описание из task tracker"а корректно перенесено в документацию. Просто потому, что через некоторое время в рамках другой задачи поведение может поменяться и собирать документацию по нескольким задачам будет сложно. Task tracker целостную картину не обеспечивает.

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

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

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

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

Про этап эксплуатации все понятно. Надо просто следовать инструкциям производителя.

На этапе вывода из эксплуатации надо убедиться, что все нужные данные вынуты.

Про сборку и salt/puppet. Это вторая линия обороны (сразу после git"а) Рабочая схема применения примерно такая:

1. Убедиться, что ситуация с каждым сторонним пакетом ясна: откуда взято, какая версия, какие патчи накладывались. Если какая-то редиска (нехороший человек) приклеивает одинаковые версии на физически разные файлики, его надо убедить, что он не прав, или на всю его продукцию наклеивать дополнительную версию.
2. Если все rpm"ки скидываются в один репозиторий, нужно убедиться, что понятно, какая именно версия будет накатана. Неплохой вариант - иметь скрипт пересборки всего репозитория и наклеивать версию на весь репозиторий целиком. Другой - версию указывать явно в манифесте/sls-файле. Кстати, у puppet"а есть bug, ресурс package не умеет версию понижать. Почему им не стыдно, я не знаю.
3. Все манифесты/sls файлы храняться в git. В pillar для salt или параметры классов для puppet выносится только то, что отличает стенд от продакшена. Такими вещами, например, являются ulr"ы web сервисов, параметры наподобии shared_buffers для postgres, флаги, включающие debug режим. Все остальное безжаластно hard"кодится. Параметры задаются один раз при развертывании стенда и в дальнейшем меняются редко. sls файлы воспринимаются как код, он накатывается на стенд, тестируется и в неизменном виде переносится в production.

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

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

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

Факторы, влияющие на структуру плана управления конфигурацией и его детализацию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 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	Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ.	Зачастую, можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов: Какова характеристика подконтрольных конфигурационных элементов? Чем должны управлять интерфейсы высокого уровня? Каковы временные рамки проекта? Каковы доступные ресурсы? Каковы подконтрольные сущности?
	Definitions, Acronyms, and Abbreviations	Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа «План конфигурационного управления». Для предоставления этой информации можно воспользоваться ссылками на словарь проекта	Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее глоссарий – это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе. Здесь необходимо отразить и объяснить все термины УК и разрабатываемого продукта. Необходимо помнить, что хороший глоссарий позволит всем находиться в одном терминологическом пространстве. Вопросы : Определения легки и понятны всем участникам проекта? Есть ли список, на который можно легко сослаться? Необходимо ли определять данный термин?
1.4 Ссылки	References	Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в «Плане конфигурационного управления». Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы.	План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе, документы RUP, стандарты, международные и отраслевые стандарты). Вопросы : Используются ли в плане положения, методики политики, уже используемые в организации? Действительно ли ссылка необходима в плане?
1.5 Обзор	Overview	Обзор документа по разделам	Необходимо понимать, что не все участники проекта будут читать документ «от корки до корки». Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли.
	Software Configuration Management	Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации. Количество подразделов и их вложенность могут отличаться от приведенных ниже
	Organization, Responsibilities, and Interfaces	Указывается, кто будет ответственным за выполнение различных задач конфигурационного управления, описанных в ходе процессов конфигурационного управления	Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о распределенной разработке в нескольких географических точках. Эффективное дополнение данного раздела – подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса что можно выполнять отдельному участнику проекту. А что для него запрещено. Обычно для этого выбирают способ описания либо только доступных операций либо только запрещенных. В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения. В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика. Вопросы : Каковы возможности организации по штату для выполнения операций УК? Какова структура управления? Каков стиль управления? Кто будет ответственен за выполнение операций? Какие организационные изменения могут быть в течении жизни плана УК? Каковы планы по поддержке текущей организационной структуры? Какой уровень поддержки необходим для осуществления плана УК? Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно? Как распределяется ответственность при возникновении нештатных ситуаций? Имеются ли особенности для этого проекта, которые могут повлиять на бизнес? Какие действия выполняет группа CCB в проектном управлении при планировании? Прозрачно ли описаны роли участников?
	Tools, Environment, and Infrastructure	Рассматривается рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта. Описываются инструменты и процедуры, которые нужно использовать для версионного контроля объектов конфигурационного управления, создаваемых в ходе жизненного цикла проекта или программного продукта. Вопросы, рассматриваемые при настройке рабочей среды конфигурационного управления: ожидаемый размер данных по программному продукту; распределение рабочей команды; расположение серверов и рабочих станций.	Детальное описание данного пункта позволит, во-первых, понять самим какие средства разработки используются в компании (зачастую до начала внедрения в большой компании никто кроме начальника отдела разработки не представляет полного списка средств). Полный учет средств необходим еще и для того, чтобы определить методы интеграции средств разработки со средствами УК, ведь известно, что любое средство УК имеет ограниченные возможности по интеграции со средствами разработки. Задача менеджера УК и администратора в этом случае заключается в том, чтобы выбрать сторонние разработки, которые делают интеграцию либо более полной, либо просто добавляют саму интеграцию в используемое средство разработки + в средство УК. Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности. Как вариант: сервер Linux, клиенты Windows. Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства. Вопросы : Каковы организационные интерфейсы? Как взаимодействую процессы? Каков перечень процессов для взаимодействия? Каковы интерфейсы между применяемыми средствами автоматизации? Каковы зависимости между ними? Есть ли аппаратные зависимости? Где определены документы, регламентирующие процесс? Они утверждены? Каковы процедуры внесения изменений в эти документы? Каковы задействованные ресурсы (человечески, оборудование)?
	The Configuration Management Program
	Configuration Identification	Вопросы : Доступны ли стандартные методы идентификации? В чем состоит используемая схема идентификации объектов УК? Связаны ли программные и аппаратные идентификации (для встроенных систем)? Какие спецификации и планы управления должны быть идентифицированы? Необходима ли специальная схема идентификации чтобы отслеживать ПС третьей стороны? Есть ли разница в идентификации элементов в зависимости от типа приложений? Есть ли подтипы (например, компилятор С++ может работать с файлами c, cpp, h, hpp и др)? Идентифицируются ли и хранятся скрипты автоматизированного тестирования?
3.1.1 Методы идентификации	Identification Methods	Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д	Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должно быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую - спонтанно. Цель описания - выработать новую более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места.
3.1.2 Базовые версии проекта	Project Baselines	Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения. Описывается, в какой точке жизненного цикла проекта или продукта должны создаваться базовые версии. Наиболее общие базовые версии должны быть в конце каждой из фаз обследования, проработки проекта, построения системы и передачи в эксплуатацию. Базовые версии также могут создаваться в конце итераций внутри различных фаз или даже чаще. Определяется, кто может создавать базовые версии и что входит в их состав (обычно это интегратор, но может быть и по-другому)	Здесь описывается то, каким образом будет происходить сама работа в средстве УК. Как будут ставиться метки, как выпускаться релизы. Сколько ветвей для реализации проекта будет использовано, и по какому принципу ветви будут именоваться. Обратите особое внимание на данный пункт – без него невозможна эффективная работа. При проработке пункта учитывается региональная раздробленность команды (влияет состав команд, количество регионов), интенсивность внесения изменений, количество выпускаемых релизов за единицу времени. Соответственно, в зависимости от данных показателей выбирается наиболее эффективный способ управления конфигурациями, что и отражается в данном разделе. Вопросы : Какой способ выбора базовых версий используется? Для всех ли элементов базовые версии строятся по одинаковы правилам? Кто разрешает создание базовых версий? Кто физически создает базовую версию? Как и по какому шаблону создаются базовые версии? Как осуществляется продвижение базовых версий? Как и кем осуществляется проверка базовых версий? Какова периодичность проверок? Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений? Есть ли иерархия между объектами? Какая?
	Configuration and Change Control	Как известно процесс УК состоит из двух частей – управление изменениями и управления версиями. Управление изменениями – неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов. Данный раздел содержит полно описание всех запросов на изменения, включая атрибуты и жизненный цикл. Подробное описание – залог успешно построенного процесса УК. Очень часто для отслеживания существенных событий в проекте, применяют уведомления различного вида. Как правило, это уведомления по электронной почте (например при исправлении ошибки тестер получает уведомление и может приступить к тестированию). Укажите все типы уведомлений, которые применяются в проекте. Вопросы : Какие типы запросов планируется использовать в процессе УК? Каков полный цикл запросов на изменения? Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации? В какой информации, возможно, будут нуждаться члены CCB? Каковы основные ожидания от автоматизации управления изменениями? При иерархической проектной структуре как будут приниматься решения по запросу? Необходимо ли управлять всеми запросами на изменения? Каков уровень детальности управления будет выбран (сколько шагов/этапов)? Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описание изменений на уровне файлов)? Как исходный текст ассоциируется с запросом? Будет ли применена система оповещений?
	Change Request Processing and Approval	Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений.	Определяются типы запросов. Как правило это: Дефект, Запрос на расширение, Задача и Заявка. Состав типов может существенно меняться, главное не сводить все управление изменениями к одному типу запросов (очень часто кроме как Дефектами компании ничем не управляют)
	Change Control Board (CCB)	Описывается, кто входит в состав группы управления изменениями и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы.	Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не решаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется CCB. В данном разделе необходимо описать состав участников (как правило, это аналитик или постановщик, лидер группы разработчиков, лидер группы тестировщик и представитель отдела маркетинга) и периодичность заседаний. Например группа CCB может собираться каждую неделю (по регламенту) либо по возникшей потребности (не рекомендуется). Вопросы : Каковы пределы полномочий группы? Одна группа на все проекты или несколько групп - каждая на свой проект? Если несколько, то, каким образом они сотрудничают друг с другом? Есть ли иерархия CCB? Кто отвечает за коммуникации между CCB? Будет ли поддерживать система УК специальные запросы для организации встреч и выпуска протоколов по результатам? Есть ли потребность в выработки регламента для ограничения действий группы (жесткий регламент встреч с высокой степенью формализма)? Как различаются уровни привилегий в группе? Меняет ли введение группы CCB установленный порядок принятия решений в организации? Введены ли в состав CCB все ключевые участники, включая менеджера УК, менеджера проекта, лидера тестировщиков, лидера разработчиков и архитекторов? Каковы процедуры устранения разногласий (выпуск протокола разногласий или нечто иное)? Автоматизирована ли данная процедура?
	Configuration Status Accounting
	Project Media Storage and Release Process	Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств. Описание процесса выпуска релизов включает их содержание, для кого они предназначены и имеются ли какие-либо известные проблемы и инструкции по инсталляции (можно вынести в отдельное приложение)
3.3.2 Отчеты и проверки Reports and Audits	Reports and Audits	Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации. Отчеты используются для получения данных о «качестве программного продукта» в любой заданный момент времени жизненного цикла программного продукта или проекта. Отчетность по дефектам, основанная на запросах на изменения, может обеспечить некоторые удобные индикаторы качества и, следовательно, предостеречь менеджеров и разработчиков об определенных критических областях процесса разработки.	Отчетам следует уделить особое внимание. Только по отчетам можно проследить ход выполнения работ. Здесь необходимо определить отчеты по ролям участников проекта и описать их формат. Также рекомендуется сформировать регламент сбора отчета, то есть с какой периодичностью собираются метрики (в реальном времени, раз в день… итд). Желательно выделить различные типы отчетов и периодичность сбора их метрик. Вопросы : Есть ли необходимость в более чем одной ревизии для каждой базовой версии? Вовлечены ли субподрядчики в ревизию? Отчеты : Вопросы: Какие метрики собираются в ходе проекта? Какие типы отчетов необходимо иметь? Способы представления отчетной информации? Есть ли внешние отчетные документы для клиентов? Дифференцируются ли отчеты в зависимости от типа выполняемой участником роли в проекте? Доступны ли отчеты? Какие будут предусмотрены формальные шаги для получения отчетов? Какие типы нотификационных сообщений будут применяться? Отслеживаются ли тенденции в проекте? По каким отчетам? Как ведется учет (статически, динамически)? Какие средства используются для получения отчетов (допускается использование любого числа систем для получения достоверной Ии понятной информации о ходе проекта)?
3.3.3 Документирование	Documents	Раздел определяет способы и типы документов
3.3.3.1 Описание версии	Version Description	Данный документ описывает диски, CD или другие носители, используемые для поставки ПО. Также данный раздел также определяет состав документов поставляемых с версией ПО и доступных для конечных пользователей.	Примерный состав документов: Архив релизов с описанием (Release Media); Описание релиза (Release Notes); Описание функций; Перечень решенных проблем в релизе; Перечень новых возможностей; Инструкция по установке ПО; Инвентаризация, опись. Данный пункт может содержать основные правила формирования документов, отражать способ выпуска документов (ручной, автоматический). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. Перечень приведенных документов относится к выпуску ПС для каждой версии, релиза, патча. В зависимости от выбранной модели выпуска состав документов. А также их детальность могут различаться.
	CM Documents	Общие документы, требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс.	Типовые документы для данного раздела: Описание системы, в которой используется ПС; Описание административного управления программными средствами системы; Руководство системного администратора; Руководство пользователя; Паспорт на ПС (общие сведения о ПС. основные характеристики, комплектность, акты о приемке и снятии с эксплуатации… итд). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК.
4. Этапы	Milestones	Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления	В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта.
5. Обучение и ресурсы	Training and Resources	Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач
	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. Субподрядчики и контроль программного обеспечения со стороны поставщиков	П	П	О	ВД	Ф
Приложения	П	Ж	НД	НФ	О	ВД	Ф

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

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

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

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

Ресурсы для скачивания

static.content.url=http://www.сайт/developerworks/js/artrating/

ArticleID=208482

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