ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Управление конфигурацией в проекте программных изделий

Статья опубликована в выпуске журнала № 4 за 1998 год.[ 23.12.1998 ]
Аннотация:
Abstract:
Авторы: Баранов С.Н. () - , , , Ласточкин Н.К. () - , , , Домарацкий А.Н. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 5893
Версия для печати
Выпуск в формате PDF (1.35Мб)

Размер шрифта:       Шрифт:

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

Набор таких средств и процедур принято называть системой управления конфигурацией (системой конфигурационного управления (ку)). Чтобы извлечь максимум пользы из имеющихся в мировой практике [1-3] методологии и методов ее построения, требуется приспособить их к конкретным условиям, то есть в каждой организации, выпускающей качественные ПИ и стремящейся избежать неисчислимые ошибки при их разработке и сопровождении, должна быть создана своя система КУ.

Содержание деятельности по управлению конфигурацией показано на рисунке 1.

Рассмотрим сначала функцию идентификации конфигурации. Для точной идентификации конфигурации ПИ необходимо ввести процедуру классификации выпускаемых продуктов и идентификационного контроля (контроля за соблюдением правил именования файлов и присвоения идентификаторов компонентам ПИ).

В ИДУ в эту процедуру были введены такие понятия, как программное изделие, версия и сборка ПИ, отражающие специфику работы именно ИДУ. В соответствии с принятой процедурой разные ПИ предназначены для получения различных возможностей, разные версии одного ПИ обеспечивают различные свойства при равных возможностях, а разные сборки одной версии ПИ обеспечивают различную степень корректности выполнения требований заказчика.

Рис. 2. Укрупненная структура системы КУ

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

На практике оправдала себя иерархическая структура идентификаторов [1]. Определение идентификаторов компонентов ПИ в этом случае осуществляется путем их составления при движении по принятой иерархической структуре идентификаторов сверху вниз. В процессе присвоения идентификаторов следует избегать смешения описательной информации и информации о структуре.

Контроль за конфигурацией заключается в установлении исходной конфигурации ПИ, то есть в осуществлении идентификации всех его компонентов, и в последующем постоянном контроле за изменениями конфигурации ПИ.

Рис. 1. Содержание деятельности по КУ

Внесение каждого изменения приводит к определенным последствиям, которые необходимо оценивать и учитывать. Например, для создания нового ПИ необходимы новые документы, руководства и т.д. Для реализации новой версии требуется пересмотр, добавление или исключение некоторых компонентов ПИ. Если требуется новая сборка версии ПИ, большая часть компонентов ПИ вообще не подвергается изменению.

Остальные деятельности, приведенные на рисунке 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.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1004&lang=
Версия для печати
Выпуск в формате PDF (1.35Мб)
Статья опубликована в выпуске журнала № 4 за 1998 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: