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

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

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

При электронном проектировании средствами систем CAE/CAD/CAM должны использоваться и электронные средства управления конфигурацией, отвечающие, в частности, требованиям стандарта ИСО 10303-203.

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

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

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

Эта технология предполагает выполнение следующих операций (по ИСО 10007):

· идентификацию конфигурации, т. е. присвоение ее текущей версии определенного «имени» (кодового обозначения);

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

· учет статуса конфигурации;

· проверку (аудит) конфигурации.

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

В некоторых PDM были предусмотрены следующие статусы для версий документов: рабочий – версия c таким статусом находится в работе, ее можно модифицировать; принятый – именно версия с этим статусом является основой для взаимодействия частей проекта, она служит для обмена данными между объектами, ее модификации осуществляются через рабочий статус; архивный – статус, присваиваемый предыдущим сохраняемым версиям; порождаемый – статус зарезервирован для вновь создаваемых объектов, например при синтезе проектных решений. Разработчик сам изменяет статус объектов.

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

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

Документация конфигурации (ДК, configuration documentation – CD): документация, позволяющая определить и идентифицировать функциональные, физические и эксплуатационные характеристики изделия. В качестве документации конфигурации (ДК) принято рассматривать технические требования (условия), чертежи изделия или электронные данные аналогичного назначения.

Базовая конфигурация (baseline): утвержденная в установленном порядке документация конфигурации.

Концепция изделия (КИ, Product Concept – PC): понятие, описывающее класс подобных изделий, которые предприятие предлагает заказчикам. КИ – идея изделия, отвечающая заданному набору технических требований (Specification), требованиям заказчиков («Облик изделия» или «Лицо изделия»). С точки зрения заказчика концепция изделия представляет обозначение формализованного набора требований (Specification), отражающих потребности заказчика. С точки зрения производителя концепция изделия – это обозначение семейства модификаций изделия, поставляемых на рынок.

В стандарте ИСО 10303, спецификации SPS и модели NPDM понятию объект управления конфигурацией (Объект конфигурации (ОК) – Configuration Item – CI) соответствует любое техническое или программное средство (или их комбинация), выполняющее конечную функцию (или некоторую функцию конечного изделия), выделенное для целей управления конфигурацией и обладающее определенным набором свойств (характеристик). Один объект конфигурации может входить в другой и, в свою очередь, включать в себя другие объекты конфигурации. Конфигурация в целом и составляющие ее ОК могут быть соответствующим образом документированы и утверждены. ОК обычно обозначают уникальным буквенно-цифровым идентификатором (кодом), который используется также в качестве неизменяемой части для серийных номеров и уникальной идентификации отдельных компонентов (блоков) этого ОК.

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

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

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

В общем виде управление конфигурацией согласно ИСО 10007 включает в себя 4 основных этапа, связанных с выполнением предпроектных работ, проектированием, производством и эксплуатацией (рис. 6.5).

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

· формализацию требований;

· структурирование требований;

· проверку требований на выполнимость и непротиворечивость;

· управление изменениями в требованиях.

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

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

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

Управление конфигурацией (configuration management) - техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией - это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).

Управление конфигурацией - практика системноинженерного менеджмента - она занимается поддержанием целостности системы на протяжении всего ЖЦ. В рамках этой практики выпускаются различные виды спецификаций закупаемого/изготавливаемого оборудования/изделий - BOM (bill of materials, список комплектующих).

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

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

Основные понятия

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

базис (configuration baseline) - исходная (утвержденная) конфигурация. Базис определяется на следующих этапах:

Базис	Определяется на этапе	Тип спецификации	Характеристики	Описываемый элемент
Функциональный	Выбор концепции	A	Функциональные спецификации	Система
Физический (Allocated)	Техническое проектирование	B	Проектная документация	Элемент конфигурации
Продукции (Product)	Техническое проектирование	C, D, E	Производственно-технологическая документация	Элемент конфигурации

версия/ревизия (version/revision);
элемент конфигурации (configuration item, CI) - элемент системы, который является основой для описания и формального управления проектированием системы, базовая часть системы, которая проектируется, конструируется и создается силами одной организации. Характеристики и интерфейсы CI с другими составными частями должны быть определены и контролироваться, чтобы гарантировать надлежащее функционирование CI в составе системы в целом. Различают:
- аппаратные элементы конфигурации (hardware CI - HWCI)
- элементы конфигурации программного обеспечения компьютера (computer software CI - CSCI)

Практики

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

практика выпуска (release) инженерных артефактов (например, выпуск чертежей) - можно обсуждать, является ли hand-over данных входящим в эту практику, или должен рассматриваться отдельно
практика выпуска заказных спецификаций (BOM, bill of materials)
практика запросов на изменения
практика изменения проекта
практика управления данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон - это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными).

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

Идентификация - поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items).

Именно тут обсуждаются PBS , GBS, WBS и разные системы кодировок типа RDS-PP, KKS, RTM, S1000D и т.д.

Конфигурационный учет/регистрация - административное обеспечение взаимного соответствия:
- проекта (включая требования),
- исполнительной документации (as built, "что мы думаем о реальной системе"),
- самой системы "в железе и бетоне".

Обычно обеспечивается: наличием конфигурационной базы данных (CMDB - сonfiguration management data base) административными процедурами по её ведению (в т.ч. по назначению ведущего учёт (регистратора), передаче ведения учёта от регистратора регистратору, делегированию полномочий по учёту в порядке распределенной учётной деятельности и т.д.)

Контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.

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

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

обязательную идентификацию
обязательный регламент учёта
централизованное версионирование

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

Так, любая PLM-система поддерживает управление конфигурацией. Но если в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ) , а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.

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

Управление конфигурацией требует:

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

Инструментарий

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

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

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

Конфигурационная единица (Configuration Item или CI) - любой компонент , который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение , здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг ( SLA ).

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

СI жизненного цикла - бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза.
CI услуг:
- возможности услуг - управление, организация, процессы, знания, люди;
- ресурсы услуг - капитал, системы, приложения, информация, данные, инфраструктуры и т.п.;
- модель услуг;
- пакет услуг;
- пакет релизов;
- критерии приемки услуг.
CI организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации;
внутренние СI - материальные и нематериальные активы, которые необходимы для предоставления и управления услугами;
внешние CI - требования заказчиков, соглашения, релизы поставщиков и внешние услуги;
CI интерфейсов - активы, необходимые для предоставления услуг "от начала до конца" в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами.

Рассмотрим подробнее деятельности, представленные на рис. 8.4 .

Управление и планирование

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

Идентификация конфигураций

Для идентификации конфигураций важно:

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

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

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

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

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

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

уникальный идентификатор;
тип CI;
имя/описание;
версия;
расположение;
дата поставки;
детали лицензии (в частности, дата ее истечения);
владелец/куратор;
статус;
поставщик/источник;
документация;
данные истории, например, аудиторские отчеты;
тип связей;
соответствующий SLA.

Чаще всего характеристики CI содержатся в документации к ней. Связи конфигурационных единиц отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях хранится в CMS .

Основные связи между CI:

CI является частью другой CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок";
CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью;
CI использует другой CI. Например, программа использует модуль другой программы;
CI установлена на другую CI, например, Microsoft Excel на персональный компьютер.

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

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

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

лицензионный контроль - проверяет количество людей, которые используют лицензионный продукт, следит за тем, чтобы в организации не использовались нелицензионные продукты, следит за сроками истечения лицензий и т.п.;
управление изменениями;
контроль версий активов, программного и аппаратного обеспечения, релизов, сборок и т.п.;
контроль активов - возможности, место хранения, CMS;
контроль сборки с использованием документации от CMS;
поддержка и миграция электронных данных и информации;
формирование базы активов и конфигурационных единиц перед релизом;
контроль развертывания;
инсталляция;
управление целостностью Библиотеки эталонного ПО. Библиотека эталонного ПО (Definitive Media Library (DML) - одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе управления конфигурациями. В релизе может быть использовано только программное обеспечение из DML[

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

Выделим две основные задачи в конфигурационном управлении:

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

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

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

Единицы конфигурационного управления:

Конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления (configurationmanagementitems). Вот примеры:

Пользовательская документация;

Проектная документация;

Исходные тексты ПО;

Пакеты тестов;

Инсталляционные пакеты ПО;

Тестовые отчеты.

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

Структура – набор файлов.

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

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

Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.

Элементы конфигурационного управления могут образовывать иерархию.

Управление версиями:

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

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

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

Управление сборками:

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

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

Отличаются параметры компиляции.

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

Несоответствие друг другу различных частей проекта;

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

В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из специального скирпта – build-скрипта. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continuesintegration) – то есть регулярной сборке всего проекта (как правило – каждую ночь).

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

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

Понятие baseline

Baseline – это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т.д.

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

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

Baseline может также поддерживаться непрерывной интеграцией.

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

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

08.08.2013 Никита Налютин

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

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

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

При объединении объектов конфигурации образуется их конфигурация - любая структурированная совокупность объектов разработки программной системы, представленных в виде CI, или совокупность процессов и технологических цепочек проекта по разработке программной системы, описания которых также могут быть представлены в виде CI. Процесс управления конфигурациями в различных отраслях регламентируется международными и национальными стандартами: ГОСТ Р 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 и пр. При разработке высококритичных систем применение процесса управления конфигурациями строго обязательно - цена исправления дефектов в таких системах может быть очень высока.

Стандарт ГОСТ Р 51904 был принят Госстандартом России в 2002 году и регламентирует требования к разработке и документированию встроенных систем. В нем процесс управления конфигурациями отнесен к группе интегральных процессов, необходимых для обеспечения качества выполнения процессов разработки и их выходных данных. Интегральные процессы выполняются одновременно с процессами разработки и обеспечивают непрерывную поддержку разработки. Основные цели процесса управления конфигурациями согласно ГОСТ 51904 состоят в том, чтобы обеспечить:

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

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

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

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

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

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

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

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

По своей сути ГОСТ Р 51904, область применения которого - любые встроенные системы, базируется на международном стандарте DO-178, используемом при разработке авиационных систем. Системы, разработанные в соответствии с этим стандартом, могут быть сертифицированы согласно требованиям летной годности.

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

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

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

Существуют также стандарты AS 9100/AS9006, специально адаптирующие требования системы менеджмента качества ISO к авиационной отрасли.

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

Никита Налютин ([email protected]) - менеджер по обеспечению качества, компания Experian (Москва).