Программные продукты и системы

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

Набор таких средств и процедур принято называть системой управления конфигурацией (системой конфигурационного управления (ку)). Чтобы извлечь максимум пользы из имеющихся в мировой практике [1-3] методологии и методов ее построения, требуется приспособить их к конкретным условиям, то есть в каждой организации, выпускающей качественные ПИ и стремящейся избежать неисчислимые ошибки при их разработке и сопровождении, должна быть создана своя система КУ.

Содержание деятельности по управлению конфигурацией показано на рисунке 1.

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

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

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

На практике оправдала себя иерархическая структура идентификаторов [1]. Определение идентификаторов компонентов ПИ в этом случае осуществляется путем их составления при движении по принятой иерархической структуре идентификаторов сверху вниз. В процессе присвоения идентификаторов следует избегать смешения описательной информации и информации о структуре.

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

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

Остальные деятельности, приведенные на рисунке 1, не требуют дополнительных пояснений.

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

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

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

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

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

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

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

Если применить все средства и методы, описанные в модели СММ, приспособив их к конкретным условиям работы организации, то конфигурационное управление должно давать удовлетворительные результаты, не будучи ни избыточным, ни чересчур узким. КУ имеет настолько большое значение для разработки ПИ, что следует обязательно использовать рекомендации модели СММ для обеспечения управляемости состоянием компонентов ПИ и ПИ в целом. Если нет опыта работы по КУ, то целесообразно осуществить знакомство с существующими методами и средствами, например [3]. Это поможет быстрее понять требования ключевой области "Управление конфигурацией" модели СММ и поможет решить вопрос, что включать в собственную систему КУ в той или иной организации.

Реализация системы КУ облегчается введением в структуру организации группы процесса, на которую возлагаются и другие обязанности.

Список литературы

1. Гантер Р. Методы управления проектированием программного обеспечения. – М.: Мир, 1981. - 392 с.

2. Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software.

3. US Departament of Defense, Military Standard - Configuranijn Management Practices for Systems, Equipment, Munitions, and Computer Programs, MIL STD-483 (USAF), USG-DOD, Washington, 1970.