Методы управления проектом, риском и конфигурацией

11.3.2. Идентификация элементов конфигурации

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

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

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

При идентификации используется библиотека элементов, версий и изменений системы. Основу идентификации составляет конфигурационный базис - набор формально рассмотренной и утвержденной конфигурационной документации как основы для дальнейшего развития или разработки системы.

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

• конфигурации продукта и ее версий;
• контролируемых единиц конфигурации и их версий;
• всех составляющих конфигурационного базиса и их редакций.

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

11.3.3. Управление версиями и контроль конфигурации

Версия системы включает элементы конфигурации и систему для передачи получателю [11.6, 11.7].

Управление версиями состоит в:

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

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

Примером формирования 21 версий ОС-360 (1965-1980 гг.) является фирма IBM. В каждую версию ОС постоянно добавлялись новые функциональные возможности путем внесения изменений в предыдущую версию после анализа ее экспериментальной эксплуатации [11.13]. Над развитием дополнительных возможностей этой ОС и внесением изменений в предыдущую версию постоянно работал коллектив фирмы. Трудоемкость разработки очередной версии ОС считалась пропорциональной интервалу времени между регистрируемыми очередными версиями и принималась за единицу измерения сложности создания новой версии [11.7].

В качестве меры трудоемкости сопровождения и создания очередной версии использовалось число модулей (ограниченных размеров со стандартизованным описанием), подвергающихся изменениям и дополнениям. Кроме того, оценивалась интенсивность работ по созданию версии, которая измерялась числом измененных модулей в единицу времени. После 12 лет постоянных изменений в ОС, 21-я версия работала стабильно, в нее почти не вносились изменения, так как отсутствовали претензии со стороны пользователей ОС.Метрический анализ процесса развития ОС-360 позволил установить, что объем среднего прироста системы на каждую версию соответствовал примерно 200 модулям. При этом общий объем увеличился от 1 тыс. модулей в первых версиях до 5 тыс. модулей в последних версиях. Когда уровень прироста сложности был большим, для устранения ошибок или дополнительных корректировок иногда создавались промежуточные версии с меньшим числом изменений.

В результате разработки ОС-360 было сформулировано понятие "критической массы" или критической сложности модифицируемой системы. Если при модернизации и выпуске очередной версии системы объем доработок превышает "критический", то возрастает вероятность ухудшения характеристик системы или необходимость введения промежуточной версии с внесением незначительных изменений. "Критический" объем доработок ОС-360 около 200 модулей оставался постоянным, несмотря на рост квалификации коллектива, совершенствование технических и программных средств и т.п. В первых версиях объем доработок составлял 20% модулей, а в последних версиях снизился до 5%.

Контроль конфигурации - это проверка и управление изменениями системы при формировании версии и эксплуатации. Процесс создания продукта включает непрерывные корректировки, которые имеют отношение к уже согласованному и/или утвержденному базису конфигурации. В этом плане предметом проведения контроля конфигурации являются:

• изменения в базис конфигурации и связанная с ними корректировка конфигурации;
• дефекты и отклонения в конфигурации продукта относительно утвержденного базиса.

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

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

1. Регистрация предложения /запроса на изменение.
2. Анализ влияния предложенного изменения на имеющийся задел, объем, трудоемкость, график и стоимость работ по проекту.
3. Принятие решения на изменение (удовлетворить, отказать или отложить).
4. Реализация утвержденного изменения и его верификация.

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

Для устранения дефектов и выявленных отклонений проводится:

• регистрация информации о полученном дефекте/отклонении;
• анализ и диагностика места и причины дефекта/отклонения, оценка объема, трудоемкости, сроков и стоимости переделок;
• принятие решения по устранению дефекта/отклонения, реализация и верификация этих недостатков.

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

Наиболее удобной формой реализации такого управленческого решения - руководящий совет по контролю конфигурации (Configuration Control Board).

11.3.4. Учет статуса и аудит конфигурации

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

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

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

Аудит конфигурации. Аудит - это ревизия или проверка очередной версии ПО перед сдачей системы заказчику, а также рассмотрение и оценка документации (данных, сводок, отчетов и др.). Он включает:

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

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

Контрольные вопросы и задания

1. Какие задачи решаются в менеджменте проекта?
2. Определите процесс планирования менеджмента проекта.
3. Определите понятие управления риском.
4. Объясните стратегию оценки стоимости продукта по Боэму.
5. Что понимается под процессом управления конфигурацией ПО?
6. Приведите основные задачи управления конфигурацией.Дайте общую характеристику понятий идентификации, учета статуса.
7. Какие действия выполняются в процессе управления версиями ПО?
8. Сформулируйте основные задачи учета и аудита конфигурации проекта.