| Сокращение | Расшифровка |
| ВСК (CSA) | Вычисление Статусов Конфигураций |
| ГК (QA) | Гарантия Качества |
| ДОВ (VDD) | Документ Описания Версий |
Этот документ предназначен для:
Управление конфигурациями определяется как процесс, с помощью которого администрация программы или проекта может систематически идентифицировать, устанавливать связи, сопровождать и управлять различными компонентами программы или проекта. Этот процесс гарантирует целостность компонент и трассируемость всех изменений, возникающих в любой момент жизненного цикла программы или проекта.
Управление конфигурациями позволяет команде разработчиков программы или проекта точно определять статус любой компоненты во все время ее жизненного цикла и позволяет перевоссоздать любую версию в любой момент времени. Компонентами могут быть любые комбинации аппаратуры, программ, обслуживания и обучения.
Управление конфигурациями построено как композиция четырех подпроцессов, функционирующих одновременно:
Эти процессы описаны в разделе 2. Там же содержится предлагаемая схема Плана Управления Конфигурациями, важного документа, который определяет параметры управления конфигурациями, связанные с командой разработчиков: организацию, распределение ответственности, процедуры и работы.
Метод управления конфигурациями обеспечивает порядок, в котором применяются техническое и административное руководство, и наблюдение, для того, чтобы:
Так как применение этого метода требует от команды разработчиков программы или проекта большого объема взаимосвязей, члены команды должны проявить максимум общечеловеческих достоинств, таких как такт и способность договариваться. В связи с этим управление конфигурациями можно рассматривать как искусство и, точно так же, как техническую дисциплину.
Этот метод предлагает достаточное количество деталей, которые полезны для больших, сложных программ или проектов. Например, в качестве примера предлагается большое число трассировочных записей. При более ограниченных потребностях метод может быть адаптирован к более ограниченному варианту.
Следующие термины важны для понимания управления конфигурациями:
Объекты Конфигурации: Объектами конфигурации являются все основные результаты деятельности по разработке программы или проекта. Такие результаты идентифицируются и управляются с помощью управления конфигурациями. Объекты конфигурации могут включать аппаратуру, программы, документацию, обучение и обслуживание. Объектам конфигурации могут быть присвоены номера для простоты прослеживаний.
Заметим, что термин "компонент" используется в этом документе в очень обобщенном смысле, связываясь с некоторой частью общего решения. Термин "система" используется для обозначения полного решения, которое может включать программы, аппаратуру и другие компоненты.
Схема: Схема - это "мгновенный снимок", замороженная конфигурация спецификаций или результатов, находящихся в разработке. Схема может быть представлена документом или набором документов. Создание схемы фактически представляет собой определение результирующего условия, возникающего при завершении каждого из основных шагов процесса разработки. Когда процесс разработки переходит от одного шага к другому, специфические для этого шага результаты (документы, спецификации или продукты) пересматривают, чтобы убедиться в их качестве и связях (трассируемость) с предыдущими результатами. Специфические версии объектов конфигурации, принадлежащие им, идентифицируются. Когда (и если) результаты шага прошли процедуру обзора, они становятся схемой и теперь готовы к дальнейшей работе. Эти схемы в дальнейшем подлежат формальному управлению изменениями, что позволяет гарантировать трассируемость объектов конфигурации так, чтобы изменениями можно было управлять адекватно.
Управление Изменениями: Процесс управления изменениями определяет оценку и трассировку запросов на изменения, анализ потенциального влияния изменений и принятие решений по внесению изменений в объекты конфигурации. Между управлением изменениями и управлением конфигурациями должен быть эффективный интерфейс. Реализация запросов на изменения должна включать трассировку данного изменения через процесс управления конфигурациями.
Версии и Редакции: Эти термины часто взаимозаменяемы. В данном документе термин "версия" используется прежде всего для ссылок на каждое уникальное появление объекта конфигурации, которому присвоен уникальный идентификационный номер. Редакцией здесь называется специфическая версия объекта конфигурации, предназначенная для "внешнего" использования. Редакциями будут версии объектов, образующие комплект системы для внутреннего тестирования или для передачи заказчику. Формальная версия-редакция называется просто "формальной редакцией".
Трассируемость: Трассируемостью называется возможность идентифицировать и историю, и текущее состояние (статус) каждого объекта конфигурации в любой точке жизненного цикла программы или проекта. Необходимой также является и возможность трассировки объектов конфигурации относительно требований заказчика, как они изложены в Спецификации Требований.
Гарантия Качества: Гарантия качества включает в себя те процедуры и деятельности, которые позволяют гарантировать, что каждый объект будет реализован в ходе практической работы с требуемым качеством; гарантии основываются на верификации материалов, конструкции и постоянной проверке того, что объект удовлетворяет всем требованиям программы/проекта и подготовленным спецификациям.
Система управления конфигурациями должна быть дружелюбна по отношению к пользователям; кроме того, она должна представлять собой простейшую систему, способную достичь требуемого уровня управления, требующую минимум документов и форм. Система соответствует текущей работе, если она реализует корректное и адекватное управление, но не противостоит творческой свободе разработчиков.
Процесс управления внутренними конфигурациями должен взаимодействовать должным образом с аналогичными процессами партнеров по разработке, включенных в программу/проект. Методология управления должна быть достаточно гибкой, чтобы обеспечить координацию этих (быть может, разнородных) процессов и определить все их последовательные интерфейсные точки.
Роль управления конфигурациями в рамках общей управленческой структуры программы/проекта зависит прежде всего от общего объема работ. Управление конфигурациями тесно завязано c некоторыми другими процессами, включая технологию (собственно разработку), управление изменениями и ГК. Этот процесс является центральным для управления всеми программными или проектными файлами, так как он централизует управление изменениями в этих файлах. Кроме того, он гарантирует своевременность обмена информацией между всеми подразделениями организации.
Взаимодействие управления конфигурациями и управления изменениями представляет собой хороший пример тесной связи между различными процессами и управлением конфигурациями. Когда запрос на изменение попадает в процесс управления изменениями, об этом событии уведомляется менеджер конфигураций. Это позволяет менеджеру конфигураций модифицировать запись, относящуюся к ВСК; затем объект от начала до конца прослеживается процессом управления конфигурации, пока не будет завершена его обработка процессом управления изменениями. Разработчик завершает задачу, затребованную процессом управления изменениями, и затем уведомляет менеджер конфигураций об этом. В заключение менеджер конфигураций передает изменение в ГК для последующей окончательной верификации. В действительности существует неявный контакт между разработчиком и ГК в ходе внесения изменения.
Когда система управления конфигурациями установлена, первым вопросом в организации будет следующий: "Где должна быть помещено управление конфигурации в нашей иерархии, чтобы был достигнут максимальный эффект?" Это место должно быть достаточно высоким в организационной иерархии, чтобы обеспечить соответствующие возможности узнать и повлиять, и одновременно достаточно близким к собственно разработке, чтобы выполнять свои задачи. Слишком высокое место имеет склонность к созданию эффекта "башни из слоновой кости": функция будет слишком удалена от производственного уровня. Слишком низкое место может вызвать чрезмерные возможности наблюдения и влияния на ежедневную деятельность. Ни одно из этих решений не является наилучшим; для каждой организации должна быть сделана попытка приспособить базовые процессы к конкретным условиям.
Например, если организация одновременно разрабатывает множество проектов или программ, она может создать в рамках своей административной структуры высокоуровневую функцию, ответственную за определение стандартного множества процедур и средств, которые затем приспосабливаются к специфическим потребностям программ или проектов. После этого каждый менеджер конфигурации будет нести ответственность за высокоуровневое управление конфигурацией своего проекта или программы, как это предусматривается установленными процедурами.
Заметим, что собственно организация должна оставаться внешней по отношению к команде разработчиков и технологической группе, так что персонал, относящийся к уровню организации, может сохранить независимые перспективы и осуществлять формальное управление над всеми процессами, проходящими в организации. Однако специфическая функция поддержки, подобная управлению программной конфигурации, может быть передана технологической группе.
При меньших объемах разработок масштаб этой иерархии соответственно понижается; для очень маленьких или краткосрочных проектов менеджер проекта может выполнять все или большую часть функций управления конфигурациями.
Организация управления конфигурациями может быть поделена на несколько функций со специфическими обязанностями. Одному человеку может поручено выполнение нескольких функций (таким образом, заголовок этого документа относится скорее к функции, чем к роли конкретного члена команды разработчиков). Персонал, ответственный за каждую функцию, разрабатывает и реализует линии поведения и процедуры для своих функций и гарантирует их выполнение.
Этими функциями являются:
Административный контроль и планирование конфигураций: Ответственные за эту функцию специалисты обязаны обеспечить написание процедур, сопровождение разнообразных файлов управления конфигурациями и модификацию (по мере необходимости) записей ВСК.
Управление данными: Эта функция управляет и прослеживает всю программную/проектную корреспонденцию и внешнюю документацию. Управление данными также контролирует все номера, присваиваемые документам, программам и аппаратуре.
Библиотеки: В принципе могут быть выделены программные библиотекари, библиотекари документации и аппаратные библиотекари, в зависимости от типов объектов, определения которых должны быть запомнены в управляемой памяти. Нести ответственность за реализацию этой функции может как один человек, так и несколько.
Управление программными конфигурациями: Эта функция реализует управление всеми разработанными кодами и всей документацией, связанной с разработкой программ.
Управление аппаратными конфигурациями: Эта функция реализует управление всей аппаратурой. Последняя может включать покупное оборудование.
Обработка изменений является ключевым назначением внутреннего управления конфигурациями программы или проекта. Такая функция обычно поручается Подразделению Управления Конфигурациями, которое определяет схему результатов разработки и интегрирует все изменения к ней (после согласования всех последствий и анализа, проводимого процессом управления изменениями). Обязанности и организацию этого подразделения фиксируют в его уставе.
Подразделение Управления Конфигурациями может передать часть своих полномочий низкоуровневым подразделениям для обработки любого влияния на изменения внутренних схем и согласования воздействий исходных изменений. Рассмотрим ряд возможных примеров подразделений, ответственных перед Подразделением Управления Конфигурациями:
Подразделение Управления Программными Конфигурациями или Подразделение Обзора Программных Конфигураций: Обрабатывает все изменения, относящиеся к программам и обращенные к объектам внутренней схемы.
Подразделение Управления Аппаратными Конфигурациями: Обрабатывает все изменения, относящиеся к покупному оборудованию и потенциально способные повлиять на программную или аппаратную разработку.
Подразделение Управления Интерфейсами: Специализируется на обработке всех изменений как во внешних интерфейсах, так и во внутренних.
Библиотеки управления конфигурациями используются для обеспечения гарантий по надлежащей идентификации, управлению, вычислению статуса, сохранности и восстановлению компьютерных программных продуктов, аппаратных технологических чертежей, документации, средств и прочих полезных/необходимых объектов. Реально может быть использована любая комбинация (или интеграция) следующих четырех типов библиотек:
Библиотеки поддержки программных компонент: Эти библиотеки содержат поддерживающие материалы, используемые для помощи отдельным разработчикам программ при сохранении управления над результатами своей собственной работы без необходимости во внешнем управлении и деятельности, связанной с обработкой изменений. Магнитные ленты или какой-либо иной носитель со старыми версиями должны быть сохраняться, пока разработчик продолжает вносить изменения в программные компоненты или документы; в случаях необратимых неприятностей с системным диском, например, остается доступной вся исходная информация.
Головные библиотеки: Эти библиотеки находятся под жестким контролем со стороны управления конфигурациями. Они содержат все объекты, необходимые для управления хранением формально принятых программ и документов. Любая совокупность программных компонент и/или документов из такой библиотеки могут быть модифицированы только через обработку их формальным процессом управления изменениями.
Программные хранилища или архивы: Библиотеки этого типа являются общей памятью, в которой хранятся все объявленые созданными или закупленными программы и документы. Все программы и документация помещаются в такое хранилище для постоянного хранения в соответствие с условиями контракта или в соответствие с внутренними требованиями.
Технологические библиотеки: Библиотеки этого типа предназначены для сохранения всех средств, предусматриваемых применяемой технологией разработки. Объекты хранения включают средства для анализа риска, математические подпрограммы, программные модели, средства для оценки стоимости и другие программные средства, имеющие потенциальное значение для будущих проектов.
При разработке конкретной библиотечной структуры персонал управления конфигурациями должен установить процедуры архивации и запоминания на внешних носителях для восстановления объектов при возможных несчастьях.
Процесс управления конфигурациями состоит из следующих подпроцессов:
Менеджеры программы или проекта должны планировать сроки и ресурсы для управления конфигурациями в самом начале жизненного цикла разрабатываемой системы. Эта задача включает распределение ответственностей за каждую из работ, связанных с каждым из названных подпроцессов, и обеспечением гарантий того, что все предусматриваемые здесь работы определены и включены в План Управления Конфигурациями (схема этого документа приводится в конце данного раздела).
Рассматриваемые здесь различные процедуры на практике используются в разных формах, гибко, в зависимости от потребностей программы или проекта. Фундаментальным критерием применения процедур является следующее условие: Может ли "судьба" каждого объекта конфигурации быть прослежена в течении всего жизненного цикла программы или проекта?
Процесс идентификации конфигураций требует выполнения следующих шагов:
Дальнейшее содержание данного раздела посвящено детальному рассмотрению этих шагов.
Каждый объект программы или проекта, который может изменять свое представление, содержание, структуру или статус, подпадает под управление конфигурациями и, таким образом, должен быть определен с самого начала программы или проекта. Такими объектами (и процессами для их определения) являются:
Корреспонденция: Команда разработчиков должна сохранять записи для прослеживания всей корреспонденции, хоть как-то связанной с разработкой, включая входящую и исходящую почту, телексы и факсы. Записи должны фиксировать любую связь между объектами (например, запрос-ответ, действие-реакция). Возможна необходимость в обработке множественных записей, создаваемых на основе всего комплекта корреспонденции разработки.
Версии документов: Обычно документы, создаваемые в ходе разработки программы или проекта, претерпевают ряд изменений, каждое из которых должно быть трассируемым и управляемым. Такими документами являются:
Для управления множеством версий таких документов могут быть использованы различные библиотечные средства. Существует несколько подобных средств, аналогичных рассматриваемым в следующем разделе программным библиотекам.
Команды разработчиков, связанные с большими и сложными разработками и реализациями, обычно передают под контроль конфигурационного управления еще и проектные или программные планы, тестовые материалы, отчеты (обзорные, аудитные, проблемные), запросы на изменения, обучающие материалы, планы передач заказчику готовых материалов и пр.
Версии программных систем: Программные системы состоят из множества уровней. Множество подсистем может быть объединено в систему, а множество модулей - в подсистему. Любая комбинация этих объектов может образовать схему. После создания начальной схемы команда разработчиков создает первую из многих версий программы. Повторно используемые программные компоненты, образующие, как правило, отдельные слои, такие как системы управления базами данных, системы формирования отчетов, системы управления экранными формами и пр., не модифицируются, а обрабатывается (каждая по-отдельности) как отдельная подсистема.
Когда программа готова для передачи из одной стадии разработки в другую (например, объект благополучно прошел проверку в рамках интеграционного тестирования), созданная версия или программа прослеживается по номеру версии, который идентифицирует объект для этой специфической деятельности. Такой подход позволяет команде разработчиков пересоздавать эту версию - или любую другую версию - по мере необходимости в любое время. Запись ВСК, называемая далее Запись Кодового Индекса, может быть полезной при прослеживании версий программы.
Текущий уровень разработки определяется либо любой заданной версией программы, содержащей все файлы, необходимые для полной системы, либо только некоторыми файлами, необходимыми для тестирования измененных или разработанных кодов. По этой причине персонал конфигурационного управления разбивает систему на наименее возможные объекты.
Различные средства управления программными конфигурациями, доступные на рынке сегодня, допускают такой уровень управления программными компонентами. Одно из таких средств - DEC/Система Управления Кодами (DEC/CMS). Описание процесса, приведенное ниже, показывает, как такая библиотечная система может быть использована для управления различными программными версиями, создаваемыми в ходе разработки:
Программные версии документируются с использованием редакционных записей или записей ДОВ. ДОВ содержит полный список версий, список всех проведенных изменений, определения всех новых функций и свойств, определение аппаратной конфигурации, необходимой для запуска и эксплуатации системы, а также все специальные изменения, необходимые для подключения отсутствующих в данный момент программных компонент.
Создание и сопровождение иерархической структуры системы для специфических программ или проектов требует наличия у средств поддержки следующих факторов:
Версии аппаратных компонент: Управление аппаратной конфигурацией аналогично управлению программной, рассмотренной в предудыщем разделе. Дополнительная проблема связана с прослеживанием аппаратной конфигурации, используемой при разработке программы. Изменение аппаратной компоненты может влиять на поведение программы, и наоборот, изменение в программе может вызвать изменение в поведении аппаратуры. Детальные записи вычислений статуса конфигурации необходимы для прослеживания этих изменений.
Номер системной версии может быть присвоен аппаратной конфигурации, на которой система была собрана. (Используется идентификатор продукта вместо нового идентификатора.) Заметим, однако, что команды, работающие над системной интеграцией, часто нуждаются в группировке специфического набора аппаратных компонент в один конфигурационный объект. Этот шаг особенно важен, когда стандартные аппаратные компоненты интегрируются некоторым специфическим образом для удовлетворения системных требований.
Планы аппаратных конфигураций: Команда разработчиков программы/проекта в любой момент процесса разработки может поместить рисунок, отражающий специфическую аппаратную конфигурацию, под конфигурационое управление.
Обучающие материалы: Обучающие материалы непосредственно связываются со схемой. Множество версий обучающих компонент часто бывают необходимы для согласования множества схем, зависимых от времени реализаций и плана реализации. Обучающие материалы включают много взаимозависимых компонент, таких как диалоговые инструкции, классы, видео- и аудио-ленты, компакт-диски и учебные программы. Каждая компонента обучающих материалов должна находится под конфигурационным управлением как отдельный объект.
Обслуживающие компоненты: Обслуживающие компоненты включают все результаты лабораторных работ, которые заказчик оплачивает, но они не входят в какие-либо передаваемые ему программные/проектные объекты. Обучающие материалы могут рассматриваться как один из типов обслуживающих материалов. Однако для программ системной интеграции обучение играет настолько важную роль, что обучающие материалы предпочтительнее выделять из остальных обслуживающих материалов.
Поддерживающие элементы: К поддерживающим элементам относятся все объекты, которые входят в передаваемый заказчику комплект материалов, но не являются непосредственно программными или проектными. Примерами таких объектов являются небольшие программные средства и приспособления. Такие объекты, даже если они необходимы, могут не быть идентифицированы в спецификации передаваемых заказчику материалов.
Поддерживающие элементы включают также тестовые данные, планы, данные, связанные с историей разработки, установки системных параметров и начальные файлы данных системы.
Тот, кому поручена эта область деятельности, каждому объекту конфигурации присваивает идентификационный номер ID. Схема наименования, применяемая для идентификационных номеров, чаще всего включает следующие данные:
Предложения по конкретной схеме наименования можно найти в разделе 3.
Менеджер программы или проекта определяет схемы для удовлетворения специфических потребностей. Следующие три схемы, как правило, создаются в определенных точках жизненного цикла:
Во время любого процесса разработки менеджер программы/проекта может решиться на создание и использование внутренней схемы. Такая схема обеспечивает моментальный снимок состояния разработки в некоторый момент времени. Моменты времени задаются программным/проектным менеджером как точки инициализации контролирующих действий функции управления конфигурациями. Это обычно происходит, например, после того, как программный объект благополучно пройдет тестирование, но перед тем, как этот объект объявляется готовым к интеграции с другими объектами той же самой подсистемы. Такой точкой также является точка, в которой подразделения, подчиненные Подразделению Контроля за Конфигурациями, становятся активными.
Управление конфигурациями непосредственно взаимодействует с процессом управления изменений. Первоначально этот шаг обеспечивает информацией управление изменениями о влиянии предлагаемого изменения. Когда (и если) это изменение принимается, процесс управления конфигурациями гарантирует, что объекты конфигурации, на которые влияет данное изменение, будут пересмотрены, для чего он подготовит соответствующие идентификационные номера, а затем будет модифицирована и схема, на которую изменение оказало влияние. Таким образом, управление конфигурациями обрабатывает объекты конфигурации и контролирует редакции и схемы. Эти два шага обсуждаются более детально в следующих подразделах. Еще более детальную информацию можно найти в Digital Program Methodology Technique: Change Control. Процесс обработки изменений управляется Подразделением Контроля за Конфигурациями.
Большинство конфигурационных объектов в ходе жизненного цикла программы-проекта терпят изменения. Как только эти изменения возникают, формируется "дерево" версий, представляющее варианты объекта по степени "зрелости" и расширения. Каждая новая ветвь и лист такого дерева представляют новую версию объекта. Только последняя корректная версия любого объекта должна распространяться по разработчикам в ответ на их запросы, устаревшие версии должны быть архивированы.
Когда объект передается под контроль функции управления конфигурациями, обычно возникают следующие вопросы:
Успешность управления конфигурациями зависит от дисциплины членов команды разработчиков при выполнении ими процедур для проверки объектов конфигурации внутри и вне различных библиотек. Системы управления библиотеками позволяют гарантировать, что модификации одного и того же объекта конфигурации не могут проводится одновременно различными разработчиками и что история каждого объекта может быть прослежена. Подразделение Контроля Конфигурациями наблюдает за состояниями всех используемых библиотек и работой процедур доступа к ним.
Для отладки в библиотеке доступна лишь полная версия схемы. Разработчики могут отлаживать "схемную" версию объекта конфигурации, и именно к ней адресуются планируемые разработчиками модификации. Когда разработчик возвращает модифицированную версию объекта в библиотеку, они могут сопроводить ее дополнительным комментарием, если сочтут это необходимым. Либо разработчики сами, либо автоматические библиотечные средства фиксируют дату, время, имя пользователя и другую информацию каждый раз при обработке очередного доступа к объекту. Библиотечные автоматические средства должны быть так спроектированы, чтобы можно было гарантировать, что без явного указания пользователей невозможно иметь в отладке одновременно несколько различных копий одного объекта. Для большей информации о библиотеках рекомендуется смотреть раздел 1.3.
Разработчики часто модифицируют схемы - особенно утверждаемые или иначе результирующие схемы. Такие изменения необходимы, как только создаются новые версии различных объектов конфигурации. Базовая копия каждой модифицированной схемы помещается в библиотеку. Заметим, что влияние изменений на внутренние схемы обычно обрабатывается подразделениями, подотчетными Подразделению Контроля за Конфигурациями.
Модифицированные схемы могут передаваться заказчику как актуальные на некоторых интервалах. Такие изменения могут отражать изменения в объектах конфигурации, вызванные устранением дефектов, улучшением характеристик или расширением функциональных возможностей. Каждая новая версия может быть сделана общедоступной передачей ее заказчику для установки. Каждая версия схемы должна быть уникально идентифицирована. Для дальнейшей детализации рекомендуется обратиться к разделу 3.
После того, как изменение объекта конфигурации санкционировано, должна возникнуть некоторая временная задержка на время реализации изменения. ВСК есть механизм, используемый для прослеживания эволюции каждого объекта системы и его текущего статуса, соотносящегося со спецификациями, обозначенными в общедоступной схемной документации и письменными соглашениями. ВСК подчеркивают условие ко всему продукту в любой момент времени жизненного цикла его разработки и используются для контроля развития программы/проекта. ВСК обеспечивает программного/проектного менеджера большим количеством информации о его продукте, включая то, как он разрабатывается и все ли требуемые свойства действительно реализованы. В конечном счете, ВСК обеспечивает документацию о статусе каждого объекта конфигурации в любой момент процесса разработки.
Разработчики несут ответственность за состояние ВСК за счет своих действий, связанных с процессами управления конфигурациями. Средством, наиболее часто используемым в вычислени статусов, являются базы данных трассируемости, которые специально разрабатываются для прослеживания следующих типов данных:
Упомянутая база данных должна поддерживаться постоянно. Кроме того, она должна быть спроектирована так, чтобы способствовать различным типам поисков. Например, разработчик должен иметь возможность искать в базе данных изменения по схеме, по объекту конфигурации или по дате реализации. База данных также должна поддерживать создание различных отчетов, которые, например, касаться различны схем, содержания конкретной схемы или определения объекта конфигурации.
Такая база данных должна поддерживать очевидную связь между процессами управления изменениями и управления конфигурациями. Эта связь должна содержать следующую информацию:
Вычисление статуса как функция увеличивает свою сложность по мере развития разработки. Так как эта сложность в основном выражается в быстром росте объемов данных, которые записываются и обрабатываются, разработчики часто используют автоматические процессы, генерирующие отчеты о статусах.
Менеджеры программы/проекта должны быть уверены, что требуемое управление конфигурацией реализуется - другими словами, все принятые изменения реализованы, а результат представляет собой то, что специфицировано в его проектной документации. Для достижения необходимо высокого уровня доверия они планируют регулярные аудиты и обзоры конфигурационного управления. Требования для этих аудитов и обзоров обычно специфицируются в Плане Управления Конфигурациями, но также они могут быть заданы в планах программы, проекта или качества, как это покажется подходящим. Ответственность за нормальную реализацию аудитов конфигураций лежит на менеджере конфигураций, если эта должность предусмотрена, а если нет - на менеджере программы/проекта или менеджере качества.
Аудитам конфигураций адресуются следующие вопросы, относящиеся к измененным объектам конфигурации:
План Управления Конфигурациями может существовать самостоятельно или как приложение к Плану Программы/Проекта, в зависимости от локальных процедур или специфических требований заказчика. Рекомендуемый формат Плана Управления Конфигурациями имеет следующий вид:
1. Введение
1.1 Назначене
Определяется назначение Плана Управления Конфигурациями.
1.2 Область Действия
Определяются объекты, находящиеся под контролем Управления Конфигурациями, а также организация, деятельности и фазы жизненного цикла, к которым применяются пункты Плана.
1.3 Понятия и Сокращения
Определяются (или приводятся ссылки на определения) все понятия и сокращения, необходимые для правильной интерпретации пунктов Плана.
1.4 Литература
Приводится полный список всех документов, содержание которых используется где-либо в Плане Управления Конфигурациями. Специфицируются источники, в которых объекты ссылок могут быть найдены.
2. Обзор Управления
2.1 Организация
Описывается организационная структура функции управления конфигурациями. В частности, определяются:
2.2 Ответственности
Определяются лица, несущие персональную ответственность за идентификацию, контроль, вычисление статуса, обзоры и аудиты объектов конфигурации. Определяется ответственность Подразделения Контроля за Конфигурациями и другими организационными компонентами, если они предусмотрены.
2.3 Управление Интерфейсами
Определяются принятые правила для:
2.4 Реализация
Определяются основные вехи реализации Плана Управления Конфигурациями. Примерами таких вех могут служить:
2.5 Интеграция Управления Конфигурациями
Определяет использование всех средств управления конфигурациями. Объясняет, как система управления конфигурациями будет сосуществовать с другими средствами разработки и будет полностью интегрирована в процесс жизненного цикла.
2.6 Применяемые Порядок и Процедуры
Определяет все, что связано с установленным порядком в управлении конфигурациями, согласованными директивами и процедурами, реализуемыми как часть этого плана. Определяются установленные процедуры управления конфигурациями. Примерами могут служить:
3. Деятельности Управления Конфигурациями
3.1 Идентификация Конфигураций
Определяет схемы решения и связанные с ними специфические фазы жизненного цикла. Для каждой схемы должно быть описано:
Рассматриваются детальные процедуры для выбора заголовков, меток, номеров и для каталогизации всех объектов конфигурации.
3.2 Контроль Конфигураций
Определяются методы, используемые для обработки запросов на изменения, включая:
Определяются процедуры, которые должны быть использованы для конфигураций интерфейсов с программами и проектами, находящимися вне области действия этого Плана Управления Конфигурациями. Устанавливаются управляющие процедуры для объектов, косвенно связанных с разработкой (например, для стандартных процедур или для систем, разработанных/купленных заказчиком).
3.3 Вычисление Статуса Конфигурации
Определяется, как именно информация о статусе объектов конфигурации собирается, верифицируется, запоминается, обрабатывается и используется в отчетах. Идентифицируются периодические отчеты, которые должны выпускаться на эту тему, и то, как эти отчеты должны распространяться. Определяются возможности для динамических запросов на хранимые данные, если это предусматривается.
Описываются способы реализации любых особых требований к вычислению статуса, задаваемых заказчиком. Информация, которая обычно предусматривается для передачи заказчику, включает:
3.4 Аудиты/Обзоры Конфигураций
Определяет роль функции управления конфигурациями в аудитах и обзорах, которые будут проведены в специфицированных точках жизненного цикла. Идентифицирует объекты конфигурации, которые должны быть рассмотрены во время каждого из аудитов и обзоров. Устанавливает процедуры, которые должны быть использованы для идентификации и решения проблем, возникающих при проведении этих аудитов и обзоров.
4. Методы, Способы и Средства
Определяет методы, способы и средства, используемые для поддержки управления конфигурациями программы/проекта. В качестве примера рассмотрите вопрос: Может ли быть использовано библиотечное средство, подобное CMS?
5. Управление Соразработчиками и Поставщиками
Описываются условия договоренностей, обеспечивающих гарантию того, что программные компоненты, создаваемые соразработчиками и покупаемые у поставщиков, будут соответствовать требованиям управления конфигурациями. Как минимум, соразработчики и поставщики должны подготовить и реализовать свои собственные планы управления конфигурациями в соответствии с тем планом, который описан здесь.
6. Сбор и Сохранение Записей
Идентифицирует документацию управления конфигурациями, которая будет подерживаться. Устанавливает методы и возможности, которые будут использоваться для сохранения и сопровождения этой документации (например, идентифицируется любая возможность постороннего восстановления, которой в принципе можно будет пользоваться в будущем). Назначается период хранения.
Команды программ/проектов выбирают схемы именования, которые должны соответствовать специфике работ по созданию или реализации. Некоторые предложения по возможным выборам приводятся ниже.
Корреспонденция, предложение 1: Идентификационный номер каждой компоненты корреспонденции должен включать:
Таким образом, F OFC 004 IBM 02 может быть идентификационным номером для четвертого факса, посланного программной/проектной командой компании OFC и адресованного фирме IBM, и в рамках всех факсов, адресованных IBM, это - второй по порядку.
Корреспонденция, предложение 2: Если существует кратковременная память для корреспонденции, то схема именования должна упростить архивацию корреспонденции:
Таким образом, имя CCN 91 01 F OFC 08 есть идентификационный номер восьмого объекта корреспонденции, полученной в январе 1991 года, который представляется факсом из фирмы OFC.
Документация: Для документации, хранимой в электронном формате, файлы могут сопровождаться с использованием тех же средств управления версиями, которые используются для других файлов.
Нумерация каждого официализированного документа должна быть уникальной. Варианты для таких систем нумерации включают:
Digital Program Methodology Techniques
Configuration Management
Part Number: EF-B6504-50
Doc. Rev. A, 1-Oct-1992
Meth. Rev.: Version 1.1