Идентификация элементов конфигурации

Выполняется с помощью методов структуризации, классификации и именования элементов в составе системы и ее версий. При проведении идентификации проводится:

– определение стратегии идентификации для получения учтенной версии системы;

– именование составных элементов частей и всей конфигурации системы;

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

– ведение версии системы (или ее частей) и документирование;

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

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

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

– конфигурации продукта и ее версий;

– контролируемых единиц конфигурации и их версий;

– всех составляющих конфигурационного базиса и их редакций.

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

Управление версиями

Версия системы включает элементы конфигурации и версию системы для передачи получателю [6, 7]. Управление версиями состоит в выполнении действий:

– интеграции или композиции корректной и окончательной версии системы из элементов конфигурации, которые реализованы на этапах ЖЦ. Функционирование кода системы зависит от аппаратных средств и инструментов, с помощью которых строилась система;

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

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

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

Ярким примеромформирования 21 версии на ОС 360 (1965-1980гг.) является фирма IBM. В ОС постоянно и поэтапно добавлялись новые функциональные возможности и вносились изменения в предыдущую версию при ее эксплуатации [13]. Над развитием дополнительных возможностей данной ОС и внесением изменений в предыдущую версию постоянно работал коллектив фирмы. Трудоемкость разработки очередной версии ОС считалась пропорциональной интервалу времени между регистрациями очередных версий и принималась за единицу измерения сложности создания новой версии [7].

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

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

В результате появилось понятие «критической массы» или критической сложности модифицируемой системы. Если при модернизации и выпуске очередной версии системы объем доработок превышает «критический», то возрастает вероятность ухудшения характеристик системы или необходимость введения промежуточной версии с внесением некоторых изменений. «Критический» объем доработок ОС–360 около 200 модулей оставался постоянным, несмотря на рост квалификации коллектива, совершенствование технических и программных средств и др. В первых версиях объем доработок составлял 20% модулей, а в последних версиях снизился до 5%.