Управление версиями
Версия системы включает элементы конфигурации и версию системы для передачи получателю [6, 7]. Управление версиями состоит в выполнении действий:
– интеграции или композиции корректной и окончательной версии системы из элементов конфигурации, которые реализованы на этапах ЖЦ. Функционирование кода системы зависит от аппаратных средств и инструментов, с помощью которых строилась система;
– выбора инструментария построения версии, оценки возможностей среды и средств автоматизации процесса построения отдельных версий с корректной конфигурацией программного обеспечения и данных;
– управления вариантами версий из совокупности готовых идентифицированных элементов системы, удовлетворяющие заданным требованиям заказчика на систему.
При формировании версий системы учитываются ограничения на разработку системы во время этапов ЖЦ, которые, как правило, порождают ряд отклонений от требований на разработку элементов конфигурации системы. Например, принимается решение об изменении конфигурации способом, который не совпадает с предложенным и согласованным с заказчиком. Когда новая версия системы получена, заказчику передаются версия, конфигурация, документация и инструменты управления версиями для самостоятельного внесения изменений в эти элементы в процессе сопровождения системы.
Ярким примером формирования 21 версии на ОС 360 (1965-1980гг.) является фирма IBM. В ОС постоянно и поэтапно добавлялись новые функциональные возможности и вносились изменения в предыдущую версию при ее эксплуатации [13]. Над развитием дополнительных возможностей данной ОС и внесением изменений в предыдущую версию постоянно работал коллектив фирмы. Трудоемкость разработки очередной версии ОС считалась пропорциональной интервалу времени между регистрациями очередных версий и принималась за единицу измерения сложности создания новой версии [7].
В качестве меры трудоемкости сопровождения и создания очередной версии использовалось число модулей (ограниченных размеров со стандартизованным описанием), подвергающихся изменениям и дополнениям.
Кроме того, оценивалась интенсивность работ по созданию версии, которая измерялась числом измененных модулей в единицу времени. После 12 лет постоянных изменений в ОС, 21 версия работала более стабильно, в нее почти не вносились изменения, так как претензий со стороны пользователей в основном не поступало.
Метрический анализ процесса развития ОС 360 позволил установить, что объем среднего прироста системы на каждую версию соответствовал примерно 200 модулям. При этом общий объем увеличился от 1 тыс. модулей в первых версиях до 5 тыс. модулей в последних версиях. Когда уровень прироста сложности был большим, для устранения ошибок или дополнительных корректировок иногда создавались промежуточные версии с меньшим числом изменений.
В результате появилось понятие «критической массы» или критической сложности модифицируемой системы. Если при модернизации и выпуске очередной версии системы объем доработок превышает «критический», то возрастает вероятность ухудшения характеристик системы или необходимость введения промежуточной версии с внесением некоторых изменений. «Критический» объем доработок ОС–360 около 200 модулей оставался постоянным, несмотря на рост квалификации коллектива, совершенствование технических и программных средств и др. В первых версиях объем доработок составлял 20% модулей, а в последних версиях снизился до 5%.
