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