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

Обновлено: 01.07.2024

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

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

Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

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

Что такое CM и зачем он нужен

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

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

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

Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.

Схема 1. Элементы, их версии и срезы-конфигурации.

CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

Так в чем же заключается такая ценность CM?

Направления ответственности CM

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

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

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

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

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

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

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

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

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	реферат
Язык	русский
Дата добавления	19.04.2014
Размер файла	74,1 K

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

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

2. Цели и задачи

3. Процедуры управления конфигурацией

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

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

4.2 Когда готовят план управления конфигурацией?

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

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

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

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

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

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

2. Цели и задачи

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

· Контроль: SCM позволяет отслеживать изменения в контролируемых объектах, обеспечивает соблюдение процесса разработки

· Управление: SCM диктует процесс автоматической идентификации в ходе всего жизненного цикла ПО, обеспечивает простоту модификации и сопровождения ПО

· Экономия средств: снижается риск потерь от ротации кадров в организации, предоставить возможность сменить организацию-разработчика без перепроектирования

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

· Контроль конфигурации: контроль над изменениями материалов

· Учёт текущего состояния: состояние документов, состояние кода, состояние отдельных задач и всего проекта в целом

· Управление процессом разработки

· Отслеживание задач и проблем (в частности, отслеживание ошибок)

3. Процедуры управления конфигурацией

Ревизия конфигурации -- процесс проверки того, что документ нижнего уровня соответствует всем требованиям документа верхнего уровня.

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

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

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

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

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

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

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

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

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

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

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

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

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

· Разработать экранные формы запросов на изменение;

· Установить политику доступа;

· Определить жизненный цикл запросов на изменение;

· Поставить данные под УК в соответствии с планом;

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

4.2 Когда готовят план управления конфигурацией?

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

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

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

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

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

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

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

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

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

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

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

Стандарт ГОСТ Р ИСО/МЭК 12207 является российским стандартом, официально введенным в действие на территории Российской Федерации.

Рассматриваемый стандарт является переводом одного из наиболее популярных международных стандартов в сфере информационных технологий – ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes.

Популярные методологии разработки ПС (такие как Rational Unified Process) основываются на ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes.

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

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

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

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

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

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

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

Подготовка процесса Должен быть разработан план управления конфигурацией. План должен определять:

работы по управлению конфигурацией;

процедуры и график выполнения данных работ;

организацию(и), ответственную(ые) за выполнение данных работ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Configuration and Change Management с точки зрения CMM и RUP Итак, мы уже коснулись требований к качественности процессов, а сейчас рассмотрим, как RUP регламентирует достижение необходимого качества. Поговорим о той части RUP, которая описывает конфигурационное управление.

Основная задача конфигурационного управления ПО — установление и поддержание целостности проектных данных на протяжении всего жизненного цикла развития проекта.

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

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

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

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

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

Цели процесса УК: 1. Управление конфигурацией происходит на плановой основе 2. Все изменения происходят управляемо

Обязательства по выполнению 1. Проект следует документированной организационной политике 1.1. Есть ответственные за выполнение проекта 1.2. УК реализуется на протяжении всего жизненного цикла (см. руп) 1.3. УК реализуется для конечных продуктов, промежуточных, экспериментальных и перспективных 1.4. Все проекты имеют собственный репозиторий 1.5. На регулярной основе проводится аудит базовых линий 1.6. На регулярной основе проводится аудит работ по управлению УК 2. Должна существовать комиссия по управлению БЛ 2.1. (задача 1) Санкционированное создание БЛ 2.2. (задача 2) Представлять интересы менеджера проекта и групп 2.3. (задача 3) Ревизия и изменение БЛ 2.4. (задача 4) Создание продуктов из БЛ 3. Необходима группа, отвечающая за координацию и реализацию УК 3.1. Создание библиотеки БЛ и управление ей 3.2. Разработка, сопровождение и распространение планов и стандартов УК 3.3. Идентификация набора продукта (под контролем) 3.4. Управление доступом к элементам 3.5. Обновление БЛ 3.6. Создание продуктов из БЛ 3.7. Запись действий по УК 3.8. Создание отчетов 4. Работы по УК должны быть обеспечены ресурсами 4.1. Назначение менеджера УК 4.2. Назначение администратора УК 4.3. Работы обеспечены инстр. Средствами и аппаратурой 5. Участники УК должны пройти обучение целям, процедурам и методам выполнения работ по УК 6. Члены группы разработки ПО должны пройти обучение по выполнению своих задач

Операции 1. Для каждого проекта готовится план УК 1.1. План разрабатывается на ранних стадиях общего планирования проекта 1.2. План рассматривается задействованными группами и рецензируется ими 1.3. План должен быть доступен, управляем и конфигурируем 2. Документированный и утвержденный план УК используется в качестве основы для всех действий (охватывает следующие вопросы) 2.1. Выполняемые работы по УК 2.2. График работ 2.3. Сферы ответственности 2.4. Ресурсы 2.5. Требования и работы по УК, выполняемые группой разработки ПО и смежными группами 3. Устанавливается библиотечная система УК, служащая репозиторием БЛ (задачи) 3.1. Многоуровневая поддержка контроля УК 3.2. Хранение и извлечение элементов конфигурации 3.3. Совместное использование элементов группами 3.4. Помощь в применении производственных стандартов УК 3.5. Хранение и извлечение архивных версий 3.6. Обеспечение корректного создания продуктов 3.7. Хранение и обновление записей по УК 3.8. Поддержка создания отчетов 3.9. Поддержка структуры и содержимого библиотеки 4. Идентификация промежуточных программных продуктов, находящихся в системе УК 4.1. Выбор элементов на основании документированных критериев 4.2. Элементам репозитория назначаются уникальные идентификаторы 4.3. Определяются характеристики каждого блока конфигурации 4.4. Определяются базовые линии 4.5. Для каждого блока определена стадия разработки, на которой он помещается в систему УК 4.6. Определен ответственный за каждый элемент 5. Запросы обслуживаются. Отчеты составляются 6. Изменение базовых линий происходит подконтрольно, в соответствии с документированной процедурой 6.1. Выполнение проверок и регрессионных тестов 6.2. Внесение в библиотеку БЛ лишь утвержденных блоков конфигурации 6.3. Внесение и извлечение блоков конфигурации не нарушает целостность проекта 7. Создание продуктов на основе ББЛ и контролирование их выпуска в соответствии с документированной процедурой 7.1. Комиссия контролирует создание продуктов на основе ББЛ 7.2. Все элементы создаются только из блоков конфигурации, содержащихся в ББЛ 8. Запись статуса элементов конфигурации в соответствии с документированной процедурой 8.1. Запись действий по УК производится с детальностью, достаточной для того, чтобы иметь в наличии статус всех элементов 8.2. Иметь возможность восстановить прежние версии 8.3. Ведение истории изменений 9. Разработка стандартных отчетов, документирующих операции УК 9.1. протоколы совещаний 9.2. краткое описание запросов 9.3. краткое описание проблем 9.4. краткое описание базовых линий 9.5. история изменений 9.6. результаты аудита БЛ

Измерения и анализ 1. Выполнение измерений и использование их результатов для определения состояния работ по УК 1.1. количество запросов за единицу времени 1.2. выполнение этапов работ по УК в сравнении с планом 1.3. объем выполненных работ по УК 1.4. ресурсы

Проверка внедрения 1. Регулярная проверка высшим руководством по УК 2. Регулярные и событийные проверки менеджером проекта работ по УК 3. Регулярный аудит БЛ (проверка на соответствии документации)

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

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

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

Конфигурационная единица (сonfiguration item или CI) — элемент инфраструктуры или объект, связанный с элементами инфраструктуры (например, RFC), который находится/ должен находиться под контролем процесса управления конфигурациями. Конфигурационными единицами могут являться любые элементы, которыми необходимо управлять с точки зрения жизненного цикла ИТ-услуги. Точных рекомендаций по тому, что считать конфигурационной единицей, не существует. Однако различные источники (в том числе ITIL) дают подсказки: это может быть аппаратное и программное обеспечение, документация и даже персонал. То есть любой ИТ-актив, сервисный компонент или любой другой элемент, который задействован на протяжении жизненного цикла ИТ-услуги.

Конфигурационная база данных (Configuration Management Database или CMDB) — база данных, содержащая все необходимые сведения по всем CI и о связях между ними. Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.

Базисная конфигурация (сonfiguration baseline или CB) — конфигурация продукта/ системы в определенный момент времени, отражающая структуру и детали этого продукта/ системы. Базисная конфигурация позволяет восстановить состояние продукта/ системы. По сути это актуальное состояние Конфигурационной Единицы.

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

Управление конфигурациями (Configuration Management) — процесс хранения технической информации о CI и связях между ними. Это процесс, который отвечает за необходимые конфигурационные элементы для оказания ИТ услуги и за их связи с управлением. Этой информацией управляют через конфигурационные элементы на протяжении всего жизненного цикла.

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

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

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

Сбор информации о каждом конфигурационном элементе
Определение и анализ связей и взаимодействий между разными конфигурационными элементами
Накопление информации в специальные базы данных управления конфигурациями (CMDB Configuration Management Database), где хранятся записи о конфигурациях на протяжении всего их жизненного цикла.
Контроль целостности системы после каждого изменения конфигураций
Постоянное слежение за ИТ инфраструктурой и ее анализ

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

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

разработка правил учета элементов ИТ-инфраструктуры;
осуществление учета в соответствии с разработанными правилами;
разработка правил получения/предоставления информации и проверки точности;
осуществление повседневной деятельности в соответствии с разработанными правилами.

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

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

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

Существует несколько различных подходов к построению CMDB:

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

Создание собственной системы — наиболее гибкий и полный вариант. Основным его недостатками является высокая ресурсоемкость.

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

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

Часто внедрение подходов библиотеки ITIL приносит успех, если начинать внедрение с Управления конфигурациями и Управления изменениями (Configuration & Change Management). Такая связка логична, потому что эти процессы наиболее взаимозависимы и при этом сильно влияют на другие процессы. С одной стороны информация об актуальной конфигурации ИТ-сервисов, хранящаяся в CMDB, является необходимым условием для Управления инцидентами и других процессов, как оперативных (Управление проблемами, изменениями, релизами), так и тактических (Управление уровнем сервиса, финансами, мощностью, доступностью, непрерывностью). С другой — без эффективного Управления изменениями невозможно достичь главной цели Управления конфигурациями – актуальности данных в CMDB.

Выполнил: студент Налимова М.В. группа ИТ-41 Принял: преподаватель Сазонова Г. А.

2012 учебный год

Конфигурация ресурсов и её модель………………………………………….5

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

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

Формирование базовой линии конфигурации проекта. 14

Базаданных конфигурации. 15

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

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

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

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

Читайте также: