АНАЛИЗ ТРЕБОВАНИЙ ПРОЦЕССА УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ В ПРОЕКТАХ К ИСПОЛЬЗУЕМЫМ ПРОГРАММНЫМ ИНСТРУМЕНТАМ

Постановка проблемы

Успешное завершение проекта зависит прежде всего от уровня согласованности элементов проекта его цели, а так же между собой и факторами дальнего окружения [1]. Для достижения этого состояния в сфере управления проектами (УП) используется процесс управления конфигурацией (УК), целью которого является поддержка общей целостности проекта [1,2,4] в течении его жизненного цикла. Эффективные программные инструменты (ПИ) используемые для УП должны предоставлять возможности для автоматизации деятельности команды проекта по УК в проекте. Возникает вопрос: в какой степени существующие ПИ поддерживают требования предъявляемые к ним процессом УК в проектах? Получив ответ на этот вопрос, можно определить области для улучшения в используемых ПИ и тем самым повысить их эффективность.

Анализ последних исследований и публикаций

Анализ современных исследований и научных публикаций в сфере УП [2-10] показал, что исследования с целью оценки степени поддержки указанных требований не проводились.

Нерешенные ранее части общей проблемы

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

Формулирование цели статьи

Целью статьи является выявление требований предъявляемых процессом управления конфигурацией в проектах к используемым в сфере управления проектами программным инструментам. В дальнейшем мы будем употреблять сочетание «программный инструмент» имея в виду только те, которые используются в сфере УП.

Изложение основного материала

Нами установлено [1], что в сфере УП на самом высоком уровне можно выделить три объекта, информация о конфигурации которых необходима для успешного завершения проекта: продукт проекта, проект и его окружение. Для управления выделенными объектами общий процесс УК в проекте дифференцируется на три вида: процесс УК продукта, процесс УК проекта и процесс УК окружения проекта. Согласно [1,2,3,4,9,10], каждый из указанных процессов в той или иной мере реализует следующие подпроцессы: планирования и управления, идентификации, контроля, учета состояния и аудита конфигурации. Каждый из этих подпроцессов имеет свои особенности обусловленные природой объекта процесса УК.

Так как цели и общие принципы УК различных объектов¹ одинаковы, то для достижения цели исследования можно обобщить требования предъявляемые каждым видом процесса УК к программным инструментам и классифицировать эти требования по выделенным подпроцессам.

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

Планирование и управление процессом УК

Главной целью всего процесса УК является поддержка согласованного состояния объекта в течении ЖЦ проекта.

Для дальнейшего изложения дадим определение термина «согласованность» с точки зрения рассматриваемого процесса. Под согласованностью одного объекта с другим будем понимать такое состояние этих объектов, когда заданные характеристики одного объекта (любого из 2-х) получаются из заданных характеристик другого, с некоторой допустимой степенью точности, по заданному отображению. Под согласованностью нескольких объектов между собой будем понимать такое состояние этих объектов, когда заданные характеристики любого из них получаются из заданных характеристик любого другого, с некоторой допустимой степенью точности, по заданному отображению.

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

1. Возможность указания минимально необходимого уровня согласованности объекта, который нужно поддерживать в течении ЖЦ проекта.

2. Возможность указания допустимой вероятности отклонения от максимально уровня согласованности объекта в течении ЖЦ проекта.

3. Возможность многопользовательского режима работы.

4. Возможность удаленного режима работы.

5. Автоматический расчет метрик как процесса УК, так и других процессов УП при фиксации изменений к какому-либо контролируемому элементу.

Идентификация конфигурации

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

1. Возможность задания структуры и взаимосвязей между компонентами объекта.

2. Возможность определения оптимального множества единиц конфигурации.

3. Возможность определения оптимальной структуры конфигурационной документации объекта.

В дальнейшем изложении под контролируемыми элементами будем понимать как единицы конфигурации, так и конфигурационную документацию.

Контроль конфигурации

Этот подпроцесс служит для управления изменениями к контролируемым элементам в течении ЖЦ проекта. Поэтому можно выделить следующие требования с позиции этого подпроцесса:

1. Возможность автоматической регистрации запроса на изменение.

2. Возможность задания типов изменений, для указания уровня полномочий необходимых для утверждения таких изменений.

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

4. Возможность предоставления информации, во время изменения какой-либо единицы конфигурации, о всех других связанных с ней единицах конфигурации: о тех, которые зависят от изменяемой ЕК и о тех, от которых зависит сама изменяемая ЕК.

5. Возможность контроля за ходом реализации принятого советом решения.

Учет состояния конфигурации

Целью этого подпроцесса является сбор и предоставление информации о статусе каждого контролируемого элемента и каждом изменении в течении ЖЦ проекта. Поэтому можно выделить следующие требования с позиции этого подпроцесса:

1. Возможность автоматического учёта всех состояний контролируемых элементов и всех изменений этих состояний.

2. Возможность выдачи информации о любом состоянии в прошлом любой единицы конфигурации и о причинах изменений этих состояний.

3. Возможность восстановления указанного состояния контролируемого элемента.

Аудит конфигурации

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

1. Предоставление всей конфигурационной документации для выбранной единицы конфигурации.

2. Возможность автоматической регистрации результатов конфигурационного аудита.

Возможность автоматического создания запроса на изменение по результатам конфигурационного аудита.

Выводы

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

Литература:

1. Морозов В.В., Рудницкий С.И. Концептуальная модель процесса управления конфигурацией в проектах // «Восточно-Европейский журнал передовых технологий» № 1/10(61) ч.3 2013, стр.187-193.

2. Practice Standard for Project Configuration Management ©2007 Project Management Institute, Four Campus Boulevard, Newton Square, PA 19073-3299 USA, 53 p.

3. Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newton Square, PA 19073-3299 USA/США, 388 с.

4. MIL-HDBK-61. Military Handbook. Configuration Management Guidance. USA. Department of Defense, 1997.

5. Бушуев С.Д. Креативные технологии управления проектами и программами: монография / ред. С. Д. Бушуев. - К. : Саммит - Книга, 2010. - 768 с. : ил.

6. Морозов В.В. Формування, управління та розвиток команди проекту (поведінкової компетенції): навч. посібн. / В.В. Морозов, А.М. Чередніченко, Т.І. Шпільова; за ред. В.В. Морозова; Ун-т економіки та права «КРОК». – К. Таксон, 2009. – 464 с.: іл.

7. Арчибальд Р. Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд; пер. с англ. Мамонтова Е.В.; под. ред. Баженова А.Д., Арефьева А.О. - 3-е изд., перераб. и доп. - М.: Компания АйТи; ДМК Пресс, 2004. -472 с, ил.

8. Милошевич Д. Набор инструментов для управления проектами / Драган 3. Милошевич; пер. с англ. Мамонтова Е. В.; под ред. Неизвестного С. И. - М. : Компания АйТи ДМК Пресс, 2006. - 729 с.

9. H.R. Berlack, Software Configuration Management, John Wiley & Sons, 1992.

10. Leon Alexis Software Configuration Management Handbook, Second Edition. Norwood: Artech House Publishers, 2005. – 352 p.

Научный руководитель:

к.т.н., профессор, Морозов Виктор Владимирович.