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

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

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

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

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

3. Политика ведения управления конфигурацией, т.е. процедуры управления измене­ниями и версиями.

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

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

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

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

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

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

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

PLC-TOOLS/ПРАВКА/ФОРМЫ/ОТОБРАЖЕНИЕ/ИНТЕРФЕЙСЫ/КОД

PLC-TOOLS/ПPABKA/CПPABKA/ЗАПPOC/OKHO_СПРАВКИ/FR-l

Начальная часть имени — это название проекта PLC-TOOLS. В проекте разрабатыва­ются четыре отдельных средства (рис. 2). Имя средства используется в следующей час­ти имени. Каждое средство создается из именованных модулей. Такое разбиение продол­жается до тех пор, пока не появится ссылка на официальный документ базового уровня. Листья дерева иерархии документов являются официальными документами проекта. На рис. 2 показано, что для каждого объекта требуется три формальных документа. Это описание объектов (документ ОБЪЕКТЫ), код компонента (документ КОД) и набор тес­тов для этого кода (документ ТЕСТЫ).

Рис. 2. Иерархия конфигурации

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

Дата добавления: 2015-07-13