CC BY
22
В заключение отметим, что определение ГП достигнутой величины оценки уровня зрелости по результатам самооценивания, проводимого в каждой ПГ с использованием паспорта СП, явилось удобным, наглядным и, как показала практика, эффективным средством отслеживания хода понимания, освоения и выполнения требований СП всеми сотрудниками ИДУ. По результатам самооценивания ГП имела возможность своевременно определять и ставить новые задачи по улучшению СП, включая отказ от обнаруженных неудачных свойств СП.
ГП, определяя набор основных характеристик статуса СП по уровням зрелости для паспорта СП,
руководствовалась принципом разумной достаточности и исходила из обеспечения возможности упрощенного самооценивания по сравнению с оцениванием внешней комиссией. При этом в ГП не ставилась задача доказательства полноты и достаточности набора характеристик статуса СП, включенного в его паспорт. Успешное завершение оценивания ИДУ на достижение третьего уровня зрелости внешней авторитетной комиссией в ноябре 1995 г. подтвердило разумность такого подхода к определению способа отслеживания хода внедрения СП в повседневную работу по выполнению проектов ПИ в ИДУ.
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ В ПРОЕКТЕ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин
Современные программные изделия (ПИ) представляют собой очень сложные программные системы, для которых только одно составление однозначных и хорошо понятных требований заказчика является трудной задачей. Поэтому важное значение при проведении проектов ПИ имеет набор средств и процедур, обеспечивающих однозначную классификацию компонентов ПИ, однозначное определение конфигурации будущего ПИ, контроль за принятой конфигурацией и ее изменениями. При этом предполагается необходимость в постоянной отчетности о состоянии конфигурации создаваемого ПИ.
Набор таких средств и процедур принято называть системой управления конфигурацией (системой конфигурационного управления (КУ)). Чтобы извлечь максимум пользы из имеющихся в мировой практике [1-3] методологии и методов ее построения, требуется приспособить их к конкретным условиям, то есть в каждой организации, выпускающей качественные ПИ и стремящейся избежать неисчислимые ошибки при их разработке и сопровождении, должна быть создана своя система КУ.
Содержание деятельности по управлению конфигурацией показано на рисунке 1.
Рассмотрим сначала функцию идентификации конфигурации. Для точной идентификации конфигурации ПИ необходимо ввести процедуру классификации выпускаемых продуктов и идентификационного контроля (контроля за соблюдением правил именования файлов и присвоения идентификаторов компонентам ПИ).
В ИДУ в эту процедуру были введены такие понятия, как
программное изделие, версия и сборка ПИ, отражающие специфику работы именно ИДУ. В соответствии с принятой процедурой разные ПИ предназначены для получения различных возможностей, разные версии одного ПИ обеспечивают различные свойства при равных возможностях, а разные сборки одной версии ПИ обеспечивают различную степень корректности выполнения требований заказчика.
При организации идентификационного контроля следует исходить из необходимости обеспечения возможности однозначного определения уникального идентификатора каждого компонента ПИ и из того, что идентификаторы должны служить еще и для управления базой данных компонентов ПИ.
На практике оправдала себя иерархическая структура идентификаторов [1]. Определение идентификаторов компонентов ПИ в этом случае осуще-
Отчет о состоянии конфигурации ПИ
К1 К2
Версия А
Недостатки
Улучшения ^ -►
Запрос
на изменения^ Ид ентификацга
конфигурации
Идентификация изменений
В архив
Подготовка изменений
Оценивание
1
Управление конфигурацией
Совет по управлению
конфигурацией
_Да_
Разрешение
на изменение
_±_
Верс
Версия Б
Рис. 2. Укрупненная структура системы КУ
ствляется путем их составления при движении по принятой иерархической структуре идентификаторов сверху вниз. В процессе присвоения идентификаторов следует избегать смешения описательной ин-
формации и информации о структуре.
Контроль за конфигурацией заключается в установлении исходной конфигурации ПИ, то есть в осуществлении идентификации всех его компонентов, и в последующем постоянном контроле за изменениями конфигурации ПИ.
Внесение каждого изменения приводит к определенным последствиям, которые необходимо оценивать и учитывать. Например, для создания нового ПИ необходимы новые документы, руководства и т.д. Для реализации новой версии требуется пересмотр, добавление или исключение некоторых компонентов ПИ. Если требуется новая сборка версии ПИ, большая часть компонентов ПИ вообще не подвергается изменению.
Остальные деятельности, приведенные на рисунке 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.
УПРАВЛЕНИЕ УЛУЧШЕНИЕМ СТАНДАРТНОГО ПРОЦЕССА И КА ЧЕСТВОМ ПРОГРАММНЫХ ИЗДЕЛИЙ
АН. Домарацкий
Как известно,* описание модели СММ представляет собой развернутый перечень требований по составлению и способам реализации содержания дея-тельностей в каждой ключевой области многоуровневой структуры модели.
Задача разработки, внедрения и сопровождения стандартного процесса (СП) в организации, производящей программные изделия (ПИ), должна быть разбита на несколько этапов. При этом необходимо исходить из того, что внедрение СП не является главной целью, СП - всего лишь средство достижения поставленной перед организацией цели (например стать лучшей в классе выпускаемых ПИ). Кроме того, следует уделять постоянное внимание улучшению внедренного СП для обеспечения возможности непрерывного повышения качества ПИ, увеличения производительности и сокращения жизненного цикла разработок.
На первом этапе освоения методологии СММ перед организацией должны быть поставлены реальные цели по достижению в хронологическом порядке уровней зрелости модели СММ и составлен долгосрочный план внедрения СП. Наш опыт показывает, что при целеустремленной, интенсивной, с соблюдением строгой дисциплины выполнения всех предписанных процедур, правил, программ и остальных составляющих СП организация может достичь третьего уровня зрелости за 1,5-2 года с начала работы по правилам модели СММ, четвертого - за 3-4 года, пя-
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.
того - за 4-5 лет.
На втором этапе необходимо выбрать из множества требований ключевых областей уровней модели СММ (с учетом всех пяти уровней зрелости) наиболее подходящее подмножество для конкретных условий работы данной организации (определить СП организации - рис.1), выделить из выбранных требований наиболее актуальные для реализации в первую очередь (реально начинать с достижения сразу третьего уровня зрелости). Далее осуществить разработку, внедрение, поддержку и постоянное улучшение определенного СП. При этом для повышения эффективности продвижения вверх по уровням зрелости целесообразно вводить элементы 4 и 5 уровней модели СММ даже при целевом достижении второго уровня зрелости.
Внедрение, поддержка, сопровождение и улучшение СП организации начинается с измерения реальных метрик определенного СП. Как правило, в начале работы эти метрики далеки по значениям от целевых, но это не должно служить поводом к разочарованию. Далее по установленным метрикам следует определить реальные характеристики и свойства СП, зафиксировать базовую версию СП, а затем обеспечить возможность систематического управления улучшением СП. При этом базовая версия, регулярный сбор и анализ реальных текущих метрик являются основой для выработки и осуществления мероприятий по управлению улучшением СП.
Под систематическим управлением улучшением СП подразумевается ежедневная деятельность, направленная на контроль состояния СП, выявление и устранение его недостатков, создание условий для повышения производительности разработки ПИ, сокращения жизненного цикла и повышения качества ПИ.
После внедрения и достижения поставленных на втором этапе целевых показателей СП, можно приступить к реализации последующих этапов внедрения методологии СММ. На этих этапах осуществляется доопределение компонентов СП для обеспе-
Множество тре-
бований второго
уровня / ✓ —
Множество тре-
\ / / ) \ \ / бований четвертого
уровня
Множество требований СП |
Множество тре- Множество тре-
бовании пятого 7 / -ч^ бований третьего
уровня уровня
Рис. 1. Определение СИ для конкретных условий ¡работы организации
