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

Тема предмета: «Управление требованиями, рисками, изменениями и конфигурацией проекта»

Тема реферата: «Управление конфигурацией проекта»

 

Содержание

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

 

 

Введение

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Изменения в продукте контролируются посредством контроля изменений в документации.

3. Изменения в продукте не производятся до тех пор, пока они не сделаны в документации.

4. До того, как быть реализованными в документации и продукте, изменения должны быть формально утверждены.

5. Все изменения должны отслеживаться.

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

7. Ведется отчетность о состоянии изменений, документов и продуктов.

8. Каждый документ периодически сравнивается с соответствующим ему документом верхнего уровня на предмет выявления несоответствий.

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

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

1. Конфигурационная идентификация (концепция 1)

2. Контроль конфигурации (концепции 2, 3, 4, 5, 6)

3. Учет состояния конфигурации (концепция 7)

4. Ревизия и аудит конфигурации (концепции 8 и 9)

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