Реклама на портале

Стандарты процесса управления конфигурациями.

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

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

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

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

Важность управления конфигурацией

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

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

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

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

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

С чего стоит начать

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

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

В целом внедрение управления конфигурацией можно разделить на 5 этапов:

  • планирование,
  • определение (в том числе исходного состояния),
  • контроль,
  • учет состояния,
  • проверка и аудит.

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

Составление плана

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

Условно можно выделить 3 основных элемента (уровня) конфигурации:

  • конфигурация;
  • актив;
  • материально-технический ресурс.

Их распределение отображено на представленной ниже диаграмме.


  • Конфигурационные единицы (CI) являются строительными блоками для критически важных сервисов, они включают в себя серверы, маршрутизаторы, программное обеспечение и системы, на которых оно построено. Чтобы управлять всем этим, требуется много времени, денег и сил, поэтому мы рекомендуем сосредоточиться только на ключевых сервисах, чтобы не переполнить CMS и CMDB лишней информацией, а занести действительно нужную.
  • Активы – ПК, ноутбуки и другая техника, которая находится на финансовом контроле, но не требует управления.
  • Материально-технические ресурсы – это различные мелкие периферийные устройства, такие как клавиатуры, мышки, флешки и тому подобное.

Последовательность – ключ к планированию

При грамотном планировании важна последовательность действий и внимание к мелочам. Например, план может содержать описание способа формирования имен CI. Имя каждой единицы для CMDB должно быть уникально и содержать ключевую информацию, которая помогает ее идентифицировать. Примером может служить такая маска: Тип CI – расположение – служба поддержки. Имя CI «MSserver-Moscow-Level3» говорит оператору Service Desk о том, что Windows Server на московской площадке недоступен и нуждается в технической поддержке третьей группой. Такой уровень информации при регистрации инцидента позволяет сразу предупредить всех пользователей сервера о проблеме, а также назначить тикет именно той группе поддержки, которая за него отвечает, что сокращает время реакции за счет сокращения стадий эскалации.

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

План конфигурации должен быть масштабируемым

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

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

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


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

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

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

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

Управление конфигурацией (УК – 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 items ). Вот примеры:

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

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

  1. Структура – набор файлов. Например, пользовательская документация в html должна включать индекс-файл и набор html -файлов, а также набор вынесенных картинок (gif или jpeg -файлы). Эта структура должна быть хорошо определена и отслеживаться при конфигурационном управлении – что все файлы не потеряны и присутствуют, имеют одинаковую версию, корректные ссылки друг на друга и т.д.
  2. Ответственное лицо и, возможно, группу тех, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией. Например, определенной программной компонентой могут в проекте пользоваться многие разработчики, но отвечать за ее разработку, исправление ошибок и пр. должен кто-то один.
  3. Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые правила, связанные, например, с правилами изменения тестов и тестовых пакетов при изменении кода.
  4. Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.

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

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

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


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

  • V1.0 – ветвь, соответствующая выпущенному релизу . Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза.
  • Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от основной ветви и замораживаются сразу после выхода пакета исправлений.
  • Upcoming (V1.1) – ветвь, соответствующая релизу , готовящемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило, действуют более строгие правила и работа в них ведется более формально.
  • Mainline – ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов.
  • WCF Experiment – ветвь, созданная для проверки некоторого технического решения, перехода на новую технологию, или внесения большого пакета изменений, потенциально нарушающих работоспособность кода на длительное время. Такие ветви, как правило, делаются доступными только для определенного круга разработчиков и убиваются по завершению работ после интеграции с основной веткой.

Сборка (построение.exe или dll файла) объединяет множество файлов, разработанных разными программистами. В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки , а из специального скирпта – build -скрипта . Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continues integration ) – то есть регулярной сборке всего проекта (как правило – каждую ночь). Как правило, процедура непрерывной интеграции включает в себя и регрессионное тестирование , и часто – создание инсталляционных пакетов.

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

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

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

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

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

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

  1. 1865 год – образован комитет, который ныне называется ITU (International Telecommunication Union ). Сейчас штаб-квартира в Женеве (Швейцария), а ITU является частью ООН. Его основная задача – стандартизация телекоммункационных протоколов и интерфейсов с целью поддержания и развития глобальной мировой телекоммуникационной сети . Самыми известными стандартами ITU являются:
  • ISDN (цифровая телефонная связь, объединяющая телефонные сервисы и передачу данных ),
  • ADSL (широко известная модемная технология, позволяющая использовать телефонную линию для выхода в Интернет , не блокируя при этом обычного телефонного сервиса ),
  • OSI (модель открытого 7-уровневого сетевого протокола , на которой базируются все современные стандартные сетевые интерфейсы и протоколы ; также является стандартом ISO ),
  • языки визуального проектирования телекоммуникационных систем, SDL и MSC , влившиеся позднее в UML .

Многие стандарты ITU переводятся на русский язык и превращаются в российские стандарты в виде ГОСТов.

  1. 1946 год – создана организация ISO (International Organization for Standardization ). Цель – содействие развитию стандартизации, а также смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услугами, способствование и развитие сотрудничества в интеллектуальной, научно-технической и экономической областях. К настоящему времени создано около 17 000 стандартов в самых разных областях промышленности – продовольственные и иные товары, различное оборудование, банковские сервисы и т.д. Вот некоторые стандарты.
  • Серия стандартов ISO 9000 . Направлены на стандартизацию качества товаров и услуг. Определение качества, определение системы поддержки качества на всех жизненных фазах изделия, товара, услуги (проектирование, разработка, коммерциализация, установка и обслуживание), описание процедур по улучшению деятельности компании, промышленного производства.
  • ISO /IEC 90003:2004 – адаптация стандартов ISO 9000 к производству ПО в русле обеспечения качества в жизненном цикле ПО.
  • ISO 9126:2001 – определение качественного ПО и различных атрибутов, описывающих это качество.

Многие стандарты ISO переводятся на русский язык и превращаются в российские стандарты в виде ГОСТов. Имеется много стандартов в области информационных технологий , а также несколько – в области программной инженерии . На соответствие стандартам ISO существует сертификация. В частности, компании сертифицируются на соответствие стандартам ISO 9000 , то есть на качественный процесс разработки ПО.

  1. 1988 год, образование организации ETSI (European Telecommunications Standards Institute), штаб-квартира в г. София Антиполис (Франция). Является независимой, некоммерческой, организацией по стандартизации в телекоммуникационной промышленности (изготовители оборудования и операторы сети) в Европе. Самые известные стандарты – GSM , система профессиональной мобильной радиосвязи TETRA .

Остановимся теперь на ряде комитетов, непосредственно связанных с разработкой ПО.

  1. 1984 год – создание SEI (Software Engineering Institute) на базе университета Карнеги-Меллон в г.Питсбурге (США). Инициатор и главный спонсор – министерство обороны США. Основная задача – стандартизация в области программной инженерии , выработка критериев для сертификации надежных и зрелых компаний (что в первую очередь интересует Минобороны США для выполнения его заказов). Самые известные продукты – стандарт CMM , CMMI , разработки в области семейства программных продуктов (product lines). Эти продукты шагнули далеко за пределы военных разработок США, их использование и развитие стало международной деятельностью. Некоторые продукты SEI стандартизованы такжеISO . На соответствие CMM /CMMI проводится сертификация.
  2. 1963 год – создание IEEE (Institute of Electrical and Electronics Engineers ). Ведет историю с конца XIX века, в контексте промышленной стандартизацией в США. Сейчас IEEE международная некоммерческая ассоциация специалистов в области техники, мировой лидер в области разработки стандартов по радиоэлектронике и электротехнике. Штаб-квартира в США, существуют многочисленные подразделения в разных странах, включая Россию. IEEE издаёт третью часть мировой технической литературы, касающейся применения радиоэлектроники, компьютеров, систем управления, электротехники, в том числе (январь 2008) 102 реферируемых научных журнала и 36 отраслевых журналов для специалистов, проводит в год более 300 крупных конференций, принимала участие в разработке около 900 действующих стандартов.
  3. 1989 год – группа американских IT-компаний (в том числе Hewlett Packard, Sun Microsystems , Canon ) организовали OMG (Object Management Group ). Сейчас включает около 800 компаний членов. Основное направление - разработка и продвижение объектно-ориентированных технологий и стандартов, в том числе для создания платформо-независимых программных приложений уровня предприятий. Известные стандарты CORBA , UML , MDA .

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

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

Качество продукта или сервиса , предназначенного потребителю, определяется в стандарте ISO 9000 :2005 как степень соответствия его характеристик требованиям - обязательным или подразумеваемым.

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

  • Наладка качественного процесса, другими словами совершенствование процесса. Для комплексного улучшения процессов в компании (подход technology push ) компаниями-разработчиками ПО используются стандарты CMM /CMMI , а также по стандартам серии ISO 9000 (с последующей официальной сертификацией ). Применяются и локальные стратегии, менее дорогостоящие и более направленные на решение отдельных проблем (подход organization pull ).
  • Формальные методы 1) – использование математических формализмов для доказательства корректности , спецификации, проверки формального соответствия, автоматической генерации и т.д.:
    • доказательство правильности работы программ,
    • проверка на моделях определенных свойств (model cheking),
    • статический анализ кода по дереву разбора программы (например, проверка корректности кода по определенным критериям – аккуратная работа с памятью, поиск мертвого кода и пр.),
    • модельно-ориентированное тестирование (model-based testing ): автоматическая генерация тестов и тестового окружения по формальным спецификациям требований к системе) и т.д.

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

  • Исследование и анализ динамических свойств ПО. Например, широко используется профилирование – исследование использования системой памяти, ее быстродействие и др. характеристик путем запуска и непосредственных наблюдений в виде графиков , отчетов и пр. В частности, этот подход используется при распараллеливании программ, при поиске "узких" мест. Еще пример – область, называемая "моделирование и анализ производительности " (performance modeling and analysis ). Здесь моделируется нагрузочное окружение системы (число одновременных пользователей системы, сетевой трафик и пр.) и наблюдается поведение системы.
  • Обеспечение качества кода. Сюда относится целый комплекс различных мероприятий и методов. Вот некоторые, самые известные из них.
    • Разработка стандартов оформления кода в проекте и контроль за соблюдением этих стандартов. Сюда входят правила на создание идентификаторов переменных , методов и имен классов, на оформление комментариев, правила использования стандартных для проекта библиотек и т.д.
    • Регулярный рефакторинг для предотвращения образования из кода "вермишели". Существует тенденция ухудшения структуры кода при внесении в него новой функциональности, исправления ошибок и пр. Появляется избыточность , образуются неиспользуемые или слабо используемые фрагменты , структура становится запутанной и трудной для понимания. Рефакторинг – это регулярная деятельность по переписыванию кода, но не с целью добавления новой функциональности, а для улучшения его структуры. Рефакторинг появился в контексте "гибких" методов, в данный момент активно поддерживается различными средами разработки ПО.
    • Различные варианты инспекции кода, например, техника peer code review . Последняя заключается в том, что код каждого участника проекта, выборочно, читается и обсуждается на специальных встречах (code review meetings), и делается это регулярно. Практика показывает, что в целом код улучшается.
    • Еcть еще такой подход, как "вычитка" кода, используемый, например, при разработке критических систем реального времени. Ею занимаются также разработчики, но их роль в данном проекте – вычитка, а не разработка.
  • Тестирование. Самый распространенный способ контроля качества ПО, представленный, фактически, в каждом программном проекте.

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

Что такое конфигурационное управление

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

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

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

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

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

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

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

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

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

Так что же такое SCM? Наиболее простое и в то же время достаточно полное определение того, что такое конфигурационное управление, содержится в документации к PVCS.

“Конфигурационное управление, - считает фирма Intersolv (разработчик PVCS), - это организация изменений и управления изменением компонентов в процессе разработки программного обеспечения”.

Это некоторая сквозная деятельность (активность, “вспомогательный процесс” в терминологии стандарта ISO 12207-1), выполняемая в течение всего производственного процесса. Определение не учитывает конфигурационного управления на этапе поддержки информационной системы, но оно вполне достаточно для выявления характерных черт SCM.

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

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

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

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

Стандарт IEEE Std-828 и заменивший его IEEE Std-1042;

Стандарт ANSI, основанный на IEEE Std-828.

Стандарт ISO 12207, основанный на IEEE Std-828.

На основании упомянутых (или иных - например, корпоративных) стандартов для каждого проекта разрабатываются документы, содержащие в себе методику конфигурационного управления. Эти стандарты и методики учитывают сложный характер современной групповой разработки программных проектов. В SCMP (SoftWare Configuration Management Plan) детально расписываются все действия, обязанности и ответственность участников проекта по отношению к SCM.

Действующие в России стандарты (19-я и 34-я серии ГОСТов) не содержат предписаний, касающихся конфигурационного управления, хотя советская программная инженерия выработала оригинальные подходы - достаточно упомянуть сборочное программирование, представляющее собой систему как проектирования, так и конфигурационного управления. В отсутствие национальных стандартов должны применяться стандарты международные, в частности, по отношению к конфигурационному управлению документом прямого действия является ISO 12207-2.

Организация процесса разработки. Современные способы организации разработки ПО далеки от наивного представления о программе, как о результате того, что программист что-то пишет.

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

Это разделение процесса разработки на “действия” (терминология ISO 12207-1), соответствующее этапам жизненного цикла, дополняется распределением задач по отдельным исполнителям и группам. Разнообразие действий, задач и исполнителей образует среду современной организации разработки.

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

Ниже мы будем рассматривать почти исключительно PVCS. Средства PVCS очень широко распространены и фактически стали стандартом в области конфигурационного управления. Мне даже приходилось слышать, как SourceSafe (средство версионного хранения фирмы Microsoft) называли PVCS’ом.

ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПО И КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ

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

Куда вносятся изменения?

Кто вносит изменения?

Какова процедура внесения изменений?

Как процедура внесения изменений связана с объектом изменения, этапом разработки, лицом, вносящим изменения?

Жизненный цикл. Жизненный цикл современной разработки состоит из ряда стадий (фаз), на которых могут изменяться не только исходные коды, но и другие объекты.

Рассмотрим вначале каскадный жизненный цикл разработки ПО. В нем выделяют обычно следующие этапы:

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

Проектирование (на этом этапе создается и/или изменяется представление о создаваемой программной системе в виде тех или иных методик проектирования; также на этапе детального проектирования (дизайна) могут создаваться первоначальные версии исходных текстов;

Кодирование (на этом этапе создаются и изменяются исходные тексты, а также исполняемые, т. е. коды, непосредственно используемые для исполнения машиной [если они отличны от исходных кодов]);

Тестирование (на этом этапе создаются тестовые процедуры, включая тестовые данные, а также результаты их выполнения);

Сопровождение (на этом этапе изменения как таковые не вносятся [внесение изменений здесь можно рассматривать как кратковременный откат к предшествующим этапам], основной рассматриваемый объект - выпускаемые версии).

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

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

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

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

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

Организация хранения объектов конфигурационного управления - один из важнейших вопросов конфигурационного управления. Исторически именно его решали методики конфигурационного управления. Ядром большинства средств SCM являются средства хранения версий.

Георгий Серяков

(Окончание следует)

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

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

Конфигурационная единица (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[