CC BY
58
Посилання на статтю_
Князева Е.А. Конфигурационное управление проектами разработки программного обеспечения / Е.А. Князева // Управлшня проектами та розвиток виробництва: Зб.наук.пр. - Луганськ: вид-во СНУ iм. В.Даля, 2005 - №4(16). С. 87-93._
УДК 658:35:07
Е.А. Князева
КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Представлены базовые концепции и элементы, на которых основывается процесс управления конфигурацией. Предлагается новый подход к качественному конфигурационному управлению проектами. Рис. 1, табл. 1, ист. 6.
Ключевые слова: управление конфигурацией, конфигурационная идентификация, контроль конфигурации, учет состояния конфигурации, ревизия и аудит конфигурации.
О.А. Князева
КОНФ1ГУРАЦ1ЙНЕ УПРАВЛ1ННЯ ПРОЕКТАМИ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Представлено базовi концепцп' та елементи, на яких засновано процес управлЫня конф^ура^ею. Запропоновано новий пщхщ до ягасного конф^урацмного управлшня проектами. Рис. 1, табл. 1, дж. б.
E.A. Kniazeva
CONFIGURATION MANAGEMENT OF SOFT WEAR PROJECTS
Base conceptions and elements of the configuration management process are lighted. A new approach to the qualitative configuration project management is proposed.
Постановка проблемы в общем виде. Рано или поздно любой долгосрочный проект, связанный с разработкой программного обеспечения, разрастается до необъятных размеров, становится трудно управляемым и трудно прогнозируемым. Руководство предприятия больше не в состоянии отслеживать конкретную деятельность подчиненных. Но, пожалуй, самая главная проблема в том, что руководящий состав не имеет четкого представления о качестве выпускаемого продукта. Подчиненные же, в свою очередь, лишены всестороннего осознания поставленных проектных задач, руководствуясь в своей работе не научной базой, а вдохновением и порывами души.
Вполне вероятно, что даже в таком случае определенный контроль над проектом, с той или иной долей успеха, возможен. Однако определить качественный уровень выходного изделия становится очень трудно.
"Управлшня проектами та розвиток виробництва", 2005, № 4(16)
1
Вот здесь и возникает потребность перехода на иную качественную ступень, так как улучшение качества - важное условие выживания IT-компаний в современных рыночных условиях [1].
Одна из дисциплин, которая позволит существенно повысить как качество самого процесса разработки, так и качество выходного продукта - управление конфигурацией, которая является основополагающей дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы проекта, вносимые в них изменения и информация о состоянии отдельных задач и всего проекта в целом. Успех проекта в большой степени зависит от того, насколько хорошо построен процесс управления конфигурацией, который может как спасти проект, так и похоронить его, если сам процесс УК работает плохо.
Анализ последних исследований и публикаций, посвященных решению данной проблем, на которые опирается автор. С момента формального основания дисциплины управления конфигурацией, которое можно условно отсчитывать от даты введения стандарта IEEE-STD-610, она рассматривалась с разных точек зрения и в различных приложениях. Был накоплен богатый опыт использования процедур управления конфигурацией в различных проектах, который обобщался с точки зрения различных стандартов и моделей программной инженерии.
Для определения основных положений процесса управления конфигурацией представляется разумным воспользоваться существующими стандартами, описывающими процесс УК [2,3,4,5]. При этом следует определить тот стандарт, который будет в наибольшей степени соответствовать потребностям конкретного предприятия.
Все стандарты можно условно разделить на виды в зависимости от широты их области действия:
- международные стандарты, действующие без ограничений во всех странах;
- государственные или отраслевые стандарты, действующие для группы предприятий или организаций, объединяемых некоторыми общими признаками;
- внутренние стандарты предприятия, действующие для конкретного предприятия и учитывающие специфику этого предприятия.
Некоторые часто используемые международные стандарты приведены ниже (таблица 1). В таблице «SCM» обозначает возможность использования стандарта для УК ПС (software configuration management), а «HCM» - для оборудования (hardware configuration management).
Таблица 1
Стандарты и руководства Область действия Описание
Процесс приобретения Процесс поставки/ разработки
IEEE/EIA 12207.0-1996, Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology-Software Lifecycle Processes SCM, SW SCM, SW Устанавливает общую структуру процессов жизненного цикла (ЖЦ) программных средств
IEEE/EIA 12207.1-1996, Lifecycle data. SCM, SW SCM, SW Представляет рекомендации о характере данных, которые должны сохраняться при
2 "Управлшня проектами та розвиток виробництва", 2005, № 4(16)
выполнении задач и работ, приведенных в IEEE/EIA 12207.0
IEEE/EIA 12207.2-1996, Implementation Considerations SCM, SW SCM, SW Представляет рекомендации по реализации требований стандарта IEEE/EIA 12207.0
ISO 9000-3: Quality Mgmt & Quality Assurance Stds-Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software SCM, SW Излагает рекомендации по применению ISO 9001 в организациях, разрабатывающих, поставляющих и сопровождающих программное обеспечение(ПО)
В рассматриваемой таблице выделены три наиболее значимые области использования стандартов:
- процесс приобретения, в ходе которого определяется степень совместимости приобретаемого продукта с уже эксплуатирующимися в организации системами и оборудованием;
- процесс поставки/разработки продукта, для которого особенно важным является согласованность действий поставщика/разработчика и заказчика продукта при определении конфигурационной идентификации, ревизий и аудита конфигурации, согласовании изменений, вносимых в продукт;
- данные - эта область действия стандартов достаточно специфическая и касается в первую очередь установления согласованных форматов и правил их изменения при обмене данными между различными подразделениями или организациями.
В качестве примера отраслевого стандарта можно привести MIL-STD-2549 «Configuration Management Data Interface», который детализирует требования для обмена данными между правительственными системами конфигурационного управления.
Международные и отраслевые стандарты не дают возможности напрямую применять описываемый в них процесс на уровне предприятия, так как само описание процесса УК в них приведено недостаточно подробно для прямого использования.
Обычная практика использования таких стандартов состоит в их адаптации для нужд конкретного предприятия. При адаптации стандарта определяется, в какой степени он будет использоваться на предприятии - полностью; за исключением определенных ситуаций; отдельные положения стандарта. Далее положения стандарта детализируются и дополняются с учетом специфики конкретного предприятия.
Для детализации процесса УК при его адаптации можно использовать методологии, разработанные различными международными организациями и фирмами (например, Rational Unified Process). Такие методологии обычно содержат более детальное описание процесса и часто имеют руководства по применению инструментальных средств автоматизации, что существенно упрощает адаптацию методологии. Впрочем, бывают ситуации, когда специфика предприятия настолько отличается от общих правил, предлагаемых методологией, что проще детализировать процесс УК самостоятельно, без привязки к какой-либо методологии.
Итогом такой адаптации обычно является внутренний стандарт предприятия на процесс управления конфигурацией. Таким образом, прослеживается следующая цепочка:
"Управлшня проектами та розвиток виробництва", 2005, № 4(16)
3
- международный стандарт - определение общих положений процесса УК;
- методология, соответствующая выбранным общим положенням, -детализация процесса УК на основе проверенных на опыте многих компаний принципов и правил;
- стандарт предприятия - уточнение процесса и его адаптации к нуждам конкретного предприятия.
Стандарт предприятия требует серьезной проработки своих положений, и работа по вводу его в действие обычно занимает несколько лет. До момента ввода в действие стандарта предприятия в проектах могут действовать отдельные нормативные и организационно-распорядительные документы.
Выделение не решенных ранее частей общей проблемы, которым посвящена данная статья. К сожалению, на сегодняшний день имеет место низкая культура разработчиков, считающих УК неким видом тотального контроля над собой, если не насилия. И в этом их глубочайшее заблуждение, так как любой формализованный процесс - это не насилие, а необходимость. В последнее время ситуация в плане отношения к процессу УК в нашей стране начала резко меняться: начинаются разработки крупных программных продуктов, разработка которых невозможна без данного процесса, а это в свою очередь вызывает необходимость перехода на иную качественную ступень. Однако очень мало литературы, в которой были бы доступно описаны основы процесса УК, все материалы либо коммерческие, либо банальные перепечатки слово в слово стандартов.
Цель работы - ближе познакомить специалистов по разработке программных проектов с базовыми концепциями, на которых основывается процесс управления конфигурацией, более доступно раскрыть его цели и задачи, предложить новый подход к качественному конфигурационному управлению, что в свою очередь поможет им сделать верные шаги в направлении успешной разработки проекта в целом.
Изложение основного материала исследования с полным обоснованием научных результатов. С момента формального основания дисциплины управления конфигурацией она рассматривалась с разных точек зрения и в различных приложениях [6], в ней были воплощены следующие важные концепции:
1. Документы создаются для описания продукта и являются средством управления конфигурацией продукта.
2. Изменения в продукте контролируются посредством контроля изменений в документации.
3. Изменения в продукте не производятся до тех пор, пока они не сделаны в документации.
4. До того как быть реализованными в документации и продукте, изменения должны быть формально утверждены.
5. Все изменения должны отслеживаться.
6. Конфигурационные объекты (продукты), документы и их версии нумеруются и именуются единообразно и недвусмысленно (или уникально).
7. Ведется отчетность о состоянии изменений, документов и продуктов.
8. Каждый документ периодически сравнивается с соответствующим ему документом верхнего уровня на предмет выявления несоответствий.
9. Продукт в целом сравнивается со своим описанием (конфигурационной идентификацией) и должен этому описанию соответствовать.
Используя введенную выше терминологию управления конфигурацией, эти концепции были сгруппированы в следующие основные четыре элемента управления конфигурацией (рисунок 1):
4
"Управлшня проектами та розвиток виробництва", 2005, № 4(16)
1. Конфигурационная идентификация артефактов (рабочих материалов), используемых или создаваемых в ходе проекта (концепция 1).
2. Контроль конфигурации, включая информацию о воздействии изменений на организационную и управленческую структуру, текущие приоритеты заданий, ресурсы и состояние проекта (концепции 2, 3, 4, 5, 6).
3. Учет состояния конфигурации на основе состояния артефактов, используемых в разработке, при выпуске готовых версий ПС или их сопровождении (концепция 7).
4. Ревизия и аудит конфигурации, в ходе которой оценивается состояние и готовность продукта (концепции 8 и 9).
Рассмотрим подробнее состав каждого из этих элементов.
Конфигурационная идентификация основывается на следующих составляющих:
- правила идентификации и нумерации - что и каким образом идентифицируется;
- идентификация требований к продукту - каким образом идентифицируются требования к ПС;
- идентификация изменений в данных - каким образом идентифицируются изменения в данных;
- базовые версии - создаются для фиксации стабильных состояний системы и используются как кандидаты на релиз ПС;
- спецификации и диаграммы - документы, описывающие конфигурационную спецификацию ПС и диаграммы, используемые для этих же целей;
- идентификация данных по релизам - методы, позволяющие однозначно сопоставить элементы конфигурации ПС и их версии с определенным релизом ПС.
Рис. 1. Основные элементы процесса управления конфигурацией
"Управлшня проектами та розвиток виробництва", 2005, № 4(16)
5
Контроль конфигурации включает:
- критерии утверждения изменений - определяют формальные критерии, на основании которых принимается решение об утверждении или отклонении предложенного изменения;
- спецификации, модели, документация и т.п. - все эти элементы конфигурации подвержены изменениям и находятся в сфере действия контроля конфигурации;
- процедуры контроля конфигурации - утвержденные процедуры, которым должны следовать участники проекта;
- организация контроля изменений - организационная составляющая процесса, определяющая ответственность участников проекта при выполнении процедур контроля конфигурации.
Учет состояния конфигурации предполагает:
- ведение истории изменений конфигурации продукта - определяет кто, когда и какие изменения делал;
- ведение истории состояний утвержденных изменений - показывает, как менялись состояния утвержденных изменений от момента утверждения и до момента завершения их отработки;
- ведение истории верификации конфигурации - хранит данные обо всех проведенных верификациях и их результаты;
- учет авторизации изменений - указывает на то, кто отвечает за сделанные изменения.
Ревизия и аудит конфигурации включает:
- формальные квалификационные ревизии - определяют соответствие элементов конфигурации предъявляемым к ним формальным требованиям, например, соответствие определенному шаблону документа;
- функциональный аудит конфигурации - определяет соответствие конфигурации ПС функциональным требованиям, предъявляемым к продукту;
- физический аудит конфигурации - определяет наличие или отсутствие отдельных элементов в составе конфигурации.
Можно заметить, что в том или ином виде данные элементы процесса УК уже реализованы на любом предприятии, однако лишь использование нового подхода к конфигурационному управлению проектами позволит организовать их наиболее качественным образом и тем самым извлечь из них максимум пользы. В то же время слабо реализованные процессы могут не только не улучшить качества управления инфраструктурой, но и привести к обратному эффекту путем предоставления неточной информации и внесения неконтролируемых изменений.
Вместе с этим никакие технологии не будут работать сами по себе и не смогут помочь достичь положительного результата в случае слабой продуманности процессов и неподготовленности персонала.
Выводы из данного исследования и перспективы дальнейших исследований в данном направлении. Таким образом, основные элементы процесса УК, описанные выше, дают возможность не только осуществлять определенный контроль над проектом, но и повысить качество выходного изделия. Благодаря использованию базовых концепций и элементов процесса, проект становится легко управляемым и прогнозируемым, позволяя своевременно и осознанно принимать необходимые решения для постановки новых задач на протяжении всего жизненного цикла проекта.
Используя концепцию разработки и внедрения стандарта предприятия, предполагается на основе базовых принципов процесса управления
6
"Управлшня проектами та розвиток виробництва", 2005, № 4(16)
конфигурацией, разработать и внедрить стандарт предприятия процесса управления конфигурацией, который позволит формализовать и стандартизировать деятельность организации по управлению конфигурацией в проекте реформирования государственной службы.
ЛИТЕРАТУРА
1. Марри Кантор. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения.- М.: Издательский дом "Вильямс", 2002. - 173 с.
2. Контроль якост - Керiвництво з управлшня конфнгура^ею. Мiжнародний стандарт ISO 10007: Перше видання 1995-04-15. - 15 с.
3. Документ процедура управлшня конфнгура^ею PR-OPD-27 v1.0 вщ 23 липня 2002 року. - Центр космiчних та вшськово-морських систем у м.Сан-^его. - 21 с.
4. Оценка и Аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/ITC TR 15504- CMM): Пер. с англ. - М.: Книга и бизнес, 2001. - 348 с.
5. ДСТУ 3918-1999 (ISO/IEC 12207). 1нформацмш технологи. Процеси життевого циклу програмного забезпечення. - Чинний вщ 2000-07-01. - К.: Державний стандарт УкраТни, 1995. - 47 с.
6. Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда И. Шафер. Управление программными проектами: Пер. с англ. - М.: Издательский дом "Вильямс", 2003. - 1125 с.
Стаття надмшла до редакцп 30.11.2005 р.
"Управлшня проектами та розвиток виробництва", 2005, № 4(16)
7
