Методологические основы

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

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

2. 
   Этапы и процедуры при управлении
   конфигурацией программных средств
   

• 
  Конфигурационное управление в значительной степени обеспечено, если ПС имеет четкую структуру, а его компоненты — унифицирован­ные интерфейсы по управлению и информации. Для этого правила мо­дульно-иерархического построения ПС должны детализироваться, до уров­ня конкретных методик создания и оформления модулей, компонентов и межмодульного взаимодействия. При этом унифицированные межмодуль­ные интерфейсы целесообразно, по возможности, упрощать и ослаблять, а также подготавливать условия для их проверок при реальном функциони­ровании программ. Проектирование ПС сверху вниз и последующее сохра­нение четкой структуры интерфейсов значительно облегчают управление конфигурацией и продлевают срок жизни версий комплексов программ. Регистрация и учет истории этого процесса обеспечивает возможность его контроля и пошагового восстановления выполненных изменений (отката) при выявлении вторичных дефектов, внесенных в процессе разработки модификаций для очередной базовой версии программного продукта. Та­кие дефекты обычно обусловлены одновременным, нескоординирован- ным внесением групп изменений несколькими специалистами или поте­рей некоторых изменений в определенной версии ПС. Это возможно при одновременной разработке или корректировке различных версий ЕК, пред­назначенных для использования в различных, но определенных версиях сложных комплексов программ.
  
• 
  Модификация, учет и тиражирование версий требует больших затрат. Поэтому при выпуске каждой новой базовой версии разработчики стре­мятся обеспечить преемственность ее функций и компонентов с предыду­щими версиями, а также рассматривается возможность и подготавливает­ся решение для возможного прекращения модификаций некоторой уста­ревшей версии ПС или ее конкретных компонентов. В результате развития сложного комплекса программ среди всего множества версий для каждого ПС (или компонента) в архиве тиражирования и обеспечения сохранности образуется зона сопровождения — комплект конфигураций, доступных для изменений базовых версий программного продукта. Число таких со­провождаемых базовых версий разработчика конфигураций или глубина сопровождения практически всегда не менее двух версий и редко превы­шает четыре версии. Для крупномасштабных ПС это соответствует рацио­нальному времени жизни и тиражирования каждой очередной базовой версии программного продукта около 1—2 лет.
  
• 
  В стандартах, регламентирующих конфигурационное управление ПС (см. Приложение 1), представлен комплекс процедур и состав специали­стов, организующих эти процессы, — рис. 16.2. Конкретное предприятие, в зависимости от стоящих перед ним задач и ЖЦ ПС, может выбрать соответствующую группу процессов и процедур для достижения своей конкретной цели управления конфигурацией. Множество процедур в стан­дартах сконструировано так, что возможна их адаптация в соответ­ствии с характеристиками проектов и внешней среды ПС. Для реали­зации на практике приведенных выше концепций и процедур, требований и планов сопровождения и управления конфигурацией программных средств необходимы организационные мероприятия, гарантирующие уча­стникам проектов определенную культуру, дисциплину разработки и вы­полнения модификаций. Такая организационная система должна обеспе­чивать специалистам разной квалификации и роли в проекте возможность взаимодействия при решении требуемых комплексных задач, для накопле­ния, хранения и обмена упорядоченной информацией о состоянии и изме­
  
• 
  нениях компонентов проекта. Формализация обмена информацией долж­на повысить ответственность специалистов за корректность ее содержа­ния, оперативность формирования и изменения, качество процессов транс­формации и реализации данных и документов в жизненном цикле ПС.
  
• 
  
  
• 
  Рис. 16.2
  
• 
  В процессе эксплуатации п-й версии ПС у каждого w-го пользователя могут появляться некоторые претензии к ее функционированию, которые квалифицируются им как ошибки или дефекты эталонной или собствен­ной версии (см. рис. 16.2). Для общения с пользователями и накопления информации о выявляемых недостатках в тиражируемых сложных ПС целесообразно выделение группы аналитиков высокой квалификации, ов­ладевших всеми функциональными возможностями данного ПС.
  
•