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

В ходе проектирования код программного продукта и проектная документация разрастаются по двум направлениям:

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

• вширь (новые версии имеющихся модулей и ресурсов, вспомогательные ресурсы, например, программы- заглушки при восходящем проектировании, утилиты и т.д.).

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

Таблица 19.2

Элементы конфигурации программного проекта

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

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

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

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

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

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

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

Другой стиль описания: в модуле оставляется только идентифицирующие характеристики, а все остальное переносится в специальный документ «Описание варианта программного модуля». Таким образом, пара CI: «описание…» и «код…» рассматривается как единый элемент конфигурации.

Чтобы иметь возможность оценить состояние разработки и по ошибке не включить в сборку неготовый элемент, каждый CI должен иметь характеристику, отражающую степень его завершенности. Например, для программного модуля эта характеристика может принимать значения: «в стадии разработки»; «готов к локальному тестированию»; «прошел локальное тестирование»; «готов для сборки» (т.е. автор считает, что его модуль можно включать в сборку более крупного модуля или новой версии программного продукта).

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

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

Чтобы обеспечить правильность управления конфигурацией, выполнения всех перечисленных выше требований и процедур, еще до начала реализации проекта (т.е. до появления его конфигурации) следует разработать документ: «План управления конфигурацией» (Software Configuration Management Plan (SCMP)) и включить в него все требования и процедуры.

Электронная документация

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

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

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