8.1. Управление требованиями

Группа ключевых процессов для уровня 2: повторяемый уровень.

Цель управления требованиями состоит в том, чтобы заказчик и разработчики смогли полностью согласовать требования, выдвигаемые к проекту разработки ПО.

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

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

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

 

Цели

Цель 1

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

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

 

Обязательства по выполнению

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

В рамках этих практик системные требования, отнесенные к ПО, называются «установленными требованиями».

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

Эта политика обычно состоит из следующих положений:

1. Установленные требования должны быть документированы.

2. Установленные требования рассматриваются:

? производственными менеджерами,

? другими задействованными группами.

Примеры групп, задействованных в проекте:

группа системного тестирования,

разработки ПО (включая все подгруппы, например, проектирования ПО),

системного проектирования,

обеспечения качества ПО,

управления конфигурацией ПО,

управления документацией.

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

 

Необходимые предпосылки

Предпосылка 1 Для каждого проекта устанавливается сфера ответственности за анализ системных требований и их отнесение к оборудованию, ПО и другим компонентам системы.

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

Эта сфера ответственности включает в себя следующее:

1. Управление системными требованиями, их документирование и отнесение к соответствующим элементам в течение всего проекта.

2. Влияние на изменения системных требований и их отнесение к элементам проекта.

Предпосылка 2 Установленные требования должны быть документированы.

К установленным требованиям относятся следующие:

1. Требования нетехнического характера (т. е. соглашения, условия и договорные сроки), которые определяют операции проекта разработки ПО либо влияют на них.

Примеры соглашений, условий и договорных сроков: поставляемые продукты, сроки поставки, этапы проекта.

2. Технические требования к ПО. Примеры технических требований:

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

3. Критерии приемки, по которым будет оценено соответствие программных продуктов установленным требованиям.

Предпосылка 3 На управление установленными требованиями должны быть выделены соответствующие ресурсы и финансирование.

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

2. Действия по управлению требованиями должны быть обеспечены вспомогательными инструментальными средствами.

Примеры вспомогательных инструментальных средств:

электронные таблицы,

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

инструментарий для отслеживания изменений,

инструментарий для управления тестированием.

Предпосылка 4 Члены группы разработки ПО и других смежных групп должны пройти соответствующее обучение для выполнения своих задач по управлению требованиями.

Примеры тем учебных занятий:

используемые в проекте методы, стандарты и процедуры;

предметная область.

 

Выполняемые операции

Операция 1 Группа разработки ПО рассматривает установленные требования до их внедрения в проект.

1. Выявляются пропущенные пункты требований.

2. Выполняется проверка установленных требований на:

выполнимость и возможность реализации в виде программы,

четкость и корректность формулировки,

отсутствие противоречий между требованиями,

возможность тестирования.

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

4. Все вытекающие из установленных требований обязательства обсуждаются вместе с задействованными группами.

Примеры групп, задействованных в проекте:

разработки ПО (включая все подгруппы, например, проектирования ПО),

оценки составляющих проекта,

системного проектирования,

системного тестирования,

обеспечения качества ПО,

управления конфигурацией ПО,

управления контрактами,

управления документацией.

Практики, связанные с обсуждением обязательств, содержатся в описании Операции № 6 группы ключевых процессов «Планирование проекта».

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

Установленные требования:

1. являются управляемыми и контролируемыми;

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

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

2. являются основой для создания плана разработки ПО;

3. являются основой для разработки требований к ПО.

Операция 3 Изменения установленных требований рассматриваются и вносятся в проект разработки ПО.

1. Оценивается влияние на существующие обязательства по выполнению и обсуждаются их необходимые изменения.

? Изменения внешних обязательств сотрудников и групп проверяются высшим руководством.

Практики, связанные с внешними обязательствами организации, содержатся в описании Операции № 4 группы ключевых процессов «Планирование проекта» и Операции № 3 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

? Изменения обязательств внутри организации обсуждаются вместе с задействованными группами.

Практики, связанные с обсуждением изменений обязательств, содержатся в описании Операций № 5–7 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

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

выявляются,

проходят общую оценку,

оцениваются по связанным с ними рискам,

документируются,

планируются,

доводятся до сведения задействованных групп и отдельных сотрудников,

отслеживаются до своего завершения.

 

Измерения и анализ

Измерение 1 Выполнение измерений и использование их результатов для определения статуса операций по управлению установленными требованиями.

Примеры измерений:

определение статуса каждого из установленных требований;

определение статуса изменений установленных требований;

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

 

Проверка внедрения

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

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

Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 2 Регулярные и событийные проверки менеджером проекта операций по управлению установленными требованиями.

Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

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

См. группу ключевых процессов «Обеспечение качества ПО». Минимальное содержание этих проверок и/или аудитов:

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

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

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

 

8.2. Планирование проекта

Группа ключевых процессов для уровня 2: повторяемый уровень.

Цель планирования проекта заключается в создании обоснованных планов разработки ПО и для управления выполнением проекта разработки.

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

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

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

 

Цели

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

Цель 2 Планирование и документирование работ и обязательств по проекту разработки.

Цель 3 Принятие задействованными в проекте группами и сотрудниками обязательств, связанных с проектом разработки ПО.

 

Обязательства по выполнению

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

Обязательство 2 Проект следует документированной организационной политике по планированию проектов разработки ПО.

Эта политика обычно состоит из следующих положений:

1. Планирование проекта разработки должно выполняться на основе системных требований, отнесенных к ПО. См. описание Операции № 2 группы ключевых процессов «Управление требованиями».

2. Обязательства по проекту обсуждаются:

менеджером проекта,

производственным менеджером проекта,

другими производственными менеджерами.

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

4. Задействованные группы рассматривают следующие аспекты проекта:

оценки объема ПО,

оценки объема работ и затрат,

графики выполнения работ,

другие обязательства.

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

5. Высшее руководство просматривает все внешние обязательства по проекту, принимаемые группами и отдельными сотрудниками.

6. Полученный документ плана разработки ПО является управляемым и контролируемым. Термин «план разработки ПО» используется в этом тексте для обозначения общего плана по управлению проектом разработки. Термин «разработка» не исключает сопровождения ПО или проектов поддержки и должен правильно интерпретироваться в контексте каждого проекта.

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

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

 

Необходимые предпосылки

Предпосылка 1 Для проекта разработки должен быть подготовлен и утвержден документ технического задания.

1. Техническое задание раскрывает следующие вопросы:

объем работ,

технические цели и задачи,

определение заказчиков и конечных пользователей,

применяемые стандарты,

распределение обязанностей,

ограничения и цели по затратам и срокам,

зависимость проекта от других организаций,

ограничения и цели по использованию ресурсов,

другие ограничения и цели при разработке и/или сопровождению.

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

2. Техническое задание рассматривается:

менеджером проекта,

производственным менеджером проекта,

другими производственными менеджерами,

другими задействованными группами.

3. Документ технического задания должен быть управляемым и контролируемым.

Предпосылка 2 Обязанности по созданию плана разработки ПО должны быть распределены.

1. Производственный менеджер проекта непосредственно или косвенным образом координирует планирование проекта разработки.

2. Сферы ответственности за промежуточные программные продукты и операции распределяются и назначаются производственным менеджерам отслеживаемым и учитываемым образом.

Примеры промежуточных программных продуктов:

передаваемые, при необходимости, внешнему заказчику или конечным пользователям;

используемые другими инженерными группами;

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

Предпосылка 3 Процесс подготовки плана проекта должен быть обеспечен соответствующими ресурсами и финансированием.

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

2. Процесс подготовки плана проекта обеспечивается вспомогательными инструментальными средствами.

Примеры вспомогательных инструментальных средств:

электронные таблицы,

модели получения оценочных результатов,

программы производственного и календарного планирования проекта.

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

 

Выполняемые операции

Операция 1 Группа разработки принимает участие в разработке предложения по проекту.

1. Группы разработки ПО участвует в следующих действиях:

подготовка и подача предложения.

представление и обсуждение предложения,

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

2. Группа разработки ПО рассматривает предлагаемые обязательства по проекту.

Примеры проектных обязательств:

технические цели и задачи проекта;

техническое решение системы и разработки;

бюджет, график и ресурсы разработки;

используемые при разработке стандарты и процедуры.

Операция 2 Создание плана разработки ПО инициируется на ранних стадиях общего планирования проекта и выполняется параллельно ему.

Операция 3 Группа разработки вместе с другими задействованными группами участвует в общем планировании проекта на протяжении всего его жизненного цикла.

1. Группа разработки рассматривает планы проектного уровня.

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

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

Примеры жизненных циклов разработки:

«водопад»,

«водопад» с перекрытием,

«спираль»,

серийный выпуск,

единый прототип/«водопад» с перекрытием.

Операция 6 Подготовка проектного плана разработки ПО в соответствии с документированной процедурой.

Эта процедура обычно определяет следующие действия:

1. Основой для плана разработки ПО служат следующие документы:

стандарты, применяемые заказчиком;

стандарты, используемые в проекте;

утвержденное техническое задание;

установленные требования.

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

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

Примеры других инженерных групп: системного проектирования, проектирования аппаратного обеспечения, системного тестирования.

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

4. План разработки ПО рассматривается:

менеджером проекта,

производственным менеджером проекта,

другими производственными менеджерами,

другими задействованными группами.

5. Документ плана разработки ПО должен быть управляемым и контролируемым.

Операция 7 Документирование плана проекта разработки ПО.

В ключевых практиках этот план (или совокупность планов) называется планом разработки ПО.

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

План разработки ПО раскрывает следующие вопросы:

1. Назначение, объем, цели и задачи проекта разработки.

2. Выбор жизненного цикла разработки.

3. Идентификация выбранных процедур, методов и стандартов разработки и сопровождения ПО.

Примеры стандартов и процедур разработки:

планирование разработки ПО,

управление конфигурацией ПО,

обеспечение качества ПО,

проектирование архитектуры ПО,

отслеживание и решение выявленных проблем, измерения при разработке.

4. Идентификация разрабатываемых промежуточных программных продуктов.

5. Оценки объема промежуточных программных продуктов и объема их изменений.

6. Оценки объема работ по проекту и затрат на их выполнение.

7. Оценка предполагаемого использования критических компьютерных ресурсов.

8. Календарные графики проекта разработки, включая определение ключевых точек и процедур проверки. 9. Идентификация и оценка рисков по выполнению проекта разработки.

10. Планы по использованию в проекте специализированных средств и вспомогательного инструментария.

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

См. описание Операции № 4 группы ключевых процессов «Управление конфигурацией ПО».

Операция 9 Оценочный расчет объема промежуточных программных продуктов (или изменений этого объема) в соответствии с документированной процедурой.

Эта процедура обычно определяет следующие действия:

1. Проведение оценки объема для всех основных промежуточных программных продуктов и операций.

Примеры оценочного расчета объема ПО:

оценка по функциональным точкам,

по реализованным возможностям,

по количеству строк кода,

по количеству пунктов требований,

по количеству страниц документации.

Примеры видов промежуточных продуктов и операций, для которых выполняются оценки объема:

системное ПО и вспомогательные программы,

промежуточные продукты, как предназначенные для поставки заказчику, так и внутреннего пользования,

программные и непрограммные промежуточные продукты (например, документы),

операции по разработке, проверке и утверждению промежуточных продуктов.

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

3. По возможности, используются данные по результатам прошлых проектов.

4. Предположения по оценкам объема документируются.

5. Оценки объема документируются, проверяются и согласуются.

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

менеджер проекта,

производственный менеджер проекта,

другие производственные менеджеры.

Операция 10 Получение оценок объема проектных работ и затрат в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Оценки объема проектных работ и затрат зависят от оценок объема промежуточных программных продуктов (или объема изменений).

2. Для оценок по возможности используются данные по производительности (прошлых и/или текущих проектов). Источники и обоснования этих данных документируются.

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

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

Примеры значимых затрат на создание промежуточных программных продуктов:

расходы на зарплату,

накладные расходы,

командировочные расходы,

расходы на использование машинных ресурсов.

3. Оценки объема работ, потребности в персонале и затрат базируются на прежнем опыте.

По возможности следует использовать подобные проекты.

Рассчитываются фазы операций по времени.

Оценки объема работ, потребностей в персонале и затрат распределяются по жизненному циклу ПО.

4. Полученные оценки и предположения документируются, проверяются и согласуются.

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

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

Эта процедура обычно определяет следующее:

1. Идентификация критических компьютерных ресурсов.

Примеры критических компьютерных ресурсов:

объем оперативной памяти,

требуемая мощность процессора,

пропускная способность каналов связи.

2. На оценку критических компьютерных ресурсов влияют следующие оценки:

объем промежуточных программных продуктов,

рабочая нагрузка процессора,

интенсивность потока информации (трафик).

3. Оценки предполагаемого использования критических компьютерных ресурсов документируются, проверяются и согласуются.

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

Эта процедура обычно определяет следующее:

1. График разработки, который зависит от:

оценки предполагаемого объема промежуточных программных продуктов (или объема их изменений),

объема работ и затрат по проекту.

2. Составление графика разработки базируется на прежнем опыте:

по возможности следует использовать подобные проекты.

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

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

5. Предположения, выдвинутые при создании графика, должны документироваться.

6. График разработки документируется, проверяется и согласуется.

Операция 13 Выявление, оценка и документирование рисков по проекту разработки, связанных с затратами, графиком и техническими аспектами проекта.

1. Анализ и определение значительности рисков на основании их потенциального влияния на проект. 2. Определение страховочных действий, связанных с рисками.

Примеры страховочных действий:

внесение в график резерва по времени;

создание альтернативных планов укомплектования персоналом;

создание альтернативных планов по использованию дополнительного аппаратного обеспечения.

Операция 14 Подготовка планов по использованию в проекте специализированных средств и вспомогательного инструментария.

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

Примеры специализированных средств и вспомогательного инструментария разработки:

хост-компьютеры и периферийное оборудование для разработки ПО,

компьютеры и периферийное оборудование для тестирования ПО,

целевая операционная среда,

другое вспомогательное ПО.

2. Распределение обязанностей и обсуждение соглашений по приобретению или разработке этих средств и инструментов.

3. Планы рассматриваются всеми задействованными группами.

Операция 15 Документирование данных по планированию разработки.

1. Документируемая информация включает в себя сами оценки и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и определения их обоснованности.

2. Записи данных по плану разработки ПО должны быть управляемыми и контролируемыми.

 

Измерения и анализ

Измерение 1 Выполнение измерений и использование их результатов для определения состояния работ по планированию проекта разработки.

Примеры измерений:

определение степени выполнения этапов работ по планированию разработки в сравнении с планом;

определение объема выполненных работ по планированию разработки и использованных при этом ресурсов.

 

Проверка внедрения

Проверка 1 Регулярная проверка высшим руководством выполнения работ по планированию разработки.

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

1. Проверка технических, финансовых, кадровых аспектов и выполнения графика работ.

2. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.

3. Изучение рисков проекта разработки.

4. Поручение и проверка задач, а также отслеживание их выполнения.

5. Подготовка итогового отчета по результатам каждой проверки и распространение его среди задействованных групп и сотрудников.

Проверка 2 Регулярные и событийные проверки работ по планированию проекта разработки со стороны менеджера проекта.

1. В проверках принимают участие представители задействованных групп.

2. Сравнение статуса и текущих результатов работ по планированию проекта разработки с техническим заданием по проекту и установленными требованиями.

3. Рассмотрение зависимостей между группами.

4. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.

5. Рассмотрение рисков проекта разработки.

6. Поручение и проверка действий, а также отслеживание их выполнения.

7. Подготовка итогового отчета по результатам каждой проверки и распространение его среди задействованных групп и сотрудников.

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

См. группу ключевых процессов «Обеспечение качества ПО». Минимальное содержание проверок и/или аудитов:

1. Мероприятия по оценочному расчету и планированию проекта разработки.

2. Мероприятия по обсуждению и принятию обязательств по проекту.

3. Мероприятия по подготовке плана разработки ПО.

4. Стандарты, используемые при подготовке плана разработки ПО.

5. Содержание плана разработки ПО.

 

8.3. Отслеживание хода проекта и контроль над ним

Группа ключевых процессов для уровня 2: повторяемый уровень.

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

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

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

 

Цели

Цель 1 Сравнение фактических результатов и показателей с запланированными.

Цель 2 В случае значительного отклонения фактических результатов и показателей от запланированных — применение корректирующих действий и контроль над их выполнением.

Цель 3 Согласование изменений производственных обязательств с задействованными группами и сотрудниками.

 

Обязательства по выполнению

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

Эта политика обычно состоит из следующих положений:

1. Отслеживание хода проекта должно выполняться на основе документированного плана разработки ПО.

2. Менеджер проекта должен постоянно информироваться о состоянии проекта разработки и возникающих проблемах.

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

4. Изменения производственных обязательств вносятся при участии задействованных групп и согласуются с ними.

Примеры задействованных групп:

группа разработки ПО (включая все подгруппы, например, проектирования ПО, оценки составляющих проекта, системного проектирования),

системного тестирования,

обеспечения качества ПО,

управления конфигурацией ПО,

управления контрактами,

управления документацией.

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

 

Необходимые предпосылки

Предпосылка 1 План разработки ПО должен быть документирован и утвержден.

Практики, связанные с планом разработки ПО, содержатся в описании Операций № 6 и № 7 группы ключевых процессов «Планирование проекта».

Предпосылка 2 Менеджер проекта назначает конкретных сотрудников, ответственных за промежуточные программные продукты и производственные операции.

Распределяемые сферы ответственности охватывают следующие аспекты:

1. Разрабатываемые промежуточные программные продукты или предоставляемые услуги.

2. Объемы работ и затрат, необходимые для выполнения производственных операций.

3. График выполнения производственных операций.

4. Бюджет производственных операций.

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

1. На производственных менеджеров и ведущих специалистов возлагаются конкретные обязанности по отслеживанию хода проекта.

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

Примеры вспомогательных инструментальных средств:

электронные таблицы,

программы производственного и календарного планирования проекта.

Предпосылка 4 Производственные менеджеры должны пройти обучение управлению техническими и кадровыми аспектами проекта разработки.

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

Предпосылка 5 Линейные менеджеры должны получить ориентацию в технических аспектах проекта разработки.

Примеры ориентирования:

инженерные стандарты и процедуры проекта разработки;

предметная область проекта.

 

Выполняемые операции

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

Практики, связанные с содержанием плана разработки ПО, содержатся в описании Операции № 7 группы ключевых процессов «Планирование проекта».

К плану разработки ПО выдвигаются следующие требования:

1. Этот план должен обновляться по ходу проекта, отражая его результаты и, в частности, завершение этапов.

2. К плану разработки ПО получают постоянный доступ:

группа разработки ПО (включая все подгруппы, например, проектирования ПО),

производственные менеджеры,

менеджер проекта,

высшее руководство,

другие задействованные группы.

Операция 2 Пересмотр плана разработки ПО в соответствии с документированной процедурой.

Практики, связанные с созданием плана разработки ПО, содержатся в описании Операции № 6 группы ключевых процессов «Планирование проекта».

Эта процедура обычно определяет следующее:

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

2. Обновление плана разработки ПО выполняется с целью учета в нем всех новых обязательств по проекту и изменений прежних обязательств.

3. План разработки ПО должен проходить проверку после каждого исправления.

4. Документ плана разработки ПО должен быть управляемым и контролируемым. «Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта (т. е. реализован контроль версий), а внесение изменений происходит управляемым образом (т. е. реализовано управление изменениями).

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

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

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

Примеры групп, связанных с разработкой ПО:

группа обеспечения качества ПО,

управления конфигурацией ПО,

управления документацией.

Операция 5 Отслеживание объема промежуточных программных продуктов (или объема их изменений) и применение корректирующих действий в случае необходимости.

Практики, связанные с оценочным расчетом объема, содержатся в описании Операции № 9 группы ключевых процессов «Планирование проекта».

1. Отслеживается объем всех основных промежуточных программных продуктов (или объем их изменений).

2. Фактический объем кода (сгенерированного, полностью протестированного и переданного заказчику) сравнивается с оценками, содержащимися в плане разработки ПО.

3. Фактический объем переданной заказчику документации сравнивается с оценками, содержащимися в плане разработки ПО.

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

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

Операция 6 Отслеживание объема работ и затрат по проекту, при необходимости — применение корректирующих действий.

Практики, связанные с оценочным расчетом затрат, содержатся в описании Операции № 10 группы ключевых процессов «Планирование проекта».

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

2. Себестоимость разработки отслеживается и сравнивается с оценками, содержащимися в плане разработки ПО.

3. Трудозатраты и укомплектование персоналом сравниваются с оценками, содержащимися в плане разработки ПО.

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

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

Практики, связанные с оценочным расчетом использования компьютерных ресурсов, содержатся в описании Операции № 11 группы ключевых процессов «Планирование проекта».

1. Фактические и планируемые показатели использования критических компьютерных ресурсов отслеживаются и сравниваются с оценками для всех основных компонентов ПО в соответствии с планом разработки.

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

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

Практики, связанные с составлением календарного графика, содержатся в описании Операции № 12 группы ключевых процессов «Планирование проекта».

1. Степень фактического выполнения проектных работ, этапов и других обязательств сравнивается с планом разработки ПО.

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

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

Операция 9 Отслеживание технических операций по проекту разработки, при необходимости — применение корректирующих действий.

1. Разработчики регулярно докладывают своему линейному менеджеру о техническом состоянии разработки.

2. Содержимое успешных сборок продукта сравнивается с планом разработки ПО.

3. Отчет о проблемах, выявленных в промежуточных программных продуктах, документируется и направляется по назначению. 4. Отчеты о проблемах отслеживаются до разрешения вопросов.

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

Практики, связанные с выявлением рисков, содержатся в описании Операции № 13 группы ключевых процессов «Планирование проекта».

1. Приоритеты и действия по снижению рисков уточняются по мере поступления дополнительной информации.

2. Менеджер проекта регулярно проверяет области с высокой степенью риска.

Операция 11 Документирование фактических данных измерений и данных по изменению плана проекта.

Практики, связанные с документированием данных по проекту, содержатся в описании Операции № 15 группы ключевых процессов «Планирование проекта».

1. Записи включают в себя оценочные данные и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и проверки их обоснованности.

2. Данные по изменениям в плане проекта разработки должны быть управляемыми и контролируемыми.

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

Операция 12 Группа разработки ПО регулярно проводит внутренние проверки в целях отслеживания хода технических работ, планов, производительности и проблем и их сравнения с планом разработки ПО.

В этих проверках принимают участие:

1. Линейные менеджеры и подчиненные им ведущие специалисты.

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

Операция 13 Проведение на определенных этапах проекта формальных проверок достигнутых результатов в соответствии с документированной процедурой.

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

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

В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.

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

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

5. Результатом этих проверок является выявление существенных проблем, определение действий и решений, а также их документирование.

6. В ходе проверок изучаются риски проекта разработки.

7. В случае необходимости, по результатам проверок уточняется план разработки ПО.

 

Измерения и анализ

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

Примеры измерений: определение объема трудозатрат и других ресурсов, вложенных в выполнение работ по отслеживанию хода проекта и контролю над ним; определение статуса изменений плана разработки

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

 

Проверка внедрения

Проверка 1 Регулярная проверка высшим руководством выполнения работ по отслеживанию хода проекта и контролю над ним.

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

1. Проверка технических, финансовых, кадровых аспектов и выполнения графика.

2. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.

3. Изучение рисков проекта разработки.

4. Поручение и проверка действий, а также отслеживание их выполнения.

5. Подготовка итогового отчета по результатам каждой проверки и его распространение среди задействованных групп.

Проверка 2 Регулярные и событийные проверки менеджером проекта работ по отслеживанию хода проекта и контролю над ним.

1. В проверках принимают участие представители задействованных групп.

2. Технические, финансовые, кадровые аспекты и показатели календарного графика сравниваются с планом разработки ПО.

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

4. Обсуждение зависимостей между группами.

5. Изучение конфликтов и проблем, не решаемых на более низких уровнях руководства.

6. Изучение рисков проекта разработки.

7. Поручение и проверка задач, а также отслеживание их выполнения.

8. Подготовка итогового отчета по результатам каждой проверки и его распространение среди задействованных групп.

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

См. группу ключевых процессов «Обеспечение качества ПО».

Минимальное содержание проверок и/или аудитов:

1. Мероприятия по пересмотру и изменению обязательств.

2. Мероприятия по изменению плана разработки ПО.

3. Содержание измененного плана разработки ПО.

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

5. Мероприятия по проведению плановых технических и административных проверок.

 

8.4. Управление производственным субподрядом

Группа ключевых процессов для уровня 2: повторяемый уровень.

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

Управление производственным субподрядом включает в себя выбор субподрядчика, принятие взаимных обязательств с ним, отслеживание и проверку производительности и результатов его работы. Эти практики охватывают управление как субподрядом, связанным с разработкой исключительно программного продукта, так и управление программной частью субподряда, который включает в себя ПО, аппаратное обеспечение и, возможно, другие системные компоненты.

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

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

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

 

Цели

Цель 1 Выбор генеральным подрядчиком квалифицированных субподрядчиков.

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

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

Цель 4 Отслеживание генеральным подрядчиком фактических результатов работы и производительности субподрядчика относительно принятых им обязательств.

 

Обязательства по выполнению

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

Эта политика обычно состоит из следующих положений:

1. При выборе субподрядчиков и управлении договорами по субподряду используются документированные стандарты и процедуры.

2. Управление субподрядом основывается на заключенных договорах.

3. Изменения обязательств по субподряду принимаются при участии и согласии как генерального подрядчика, так и субподрядчика.

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

1. Менеджер по субподряду должен обладать знаниями и опытом в разработке ПО или иметь в своем распоряжении подчиненных, обладающих такими знаниями и опытом.

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

Технический объем передаваемых на субподряд работ определяется группами системного проектирования и разработки ПО.

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

3. В сферу ответственности менеджера по субподряду входит следующее:

выбор субподрядчика,

управление субподрядом,

организация поддержки поставленных субподрядных продуктов.

 

Необходимые предпосылки

Предпосылка 1 Процесс выбора субподрядчика и управления субподрядом должен быть обеспечен соответствующими ресурсами и финансированием.

1. Производственным менеджерам и другим сотрудникам должны быть назначены конкретные обязанности по управлению субподрядом.

2. Работы по управлению субподрядом должны быть обеспечены вспомогательными инструментальными средствами.

Примеры вспомогательных инструментальных средств:

модели получения оценочных результатов,

электронные таблицы,

программы управления проектом и его календарного планирования.

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

Примеры тем учебных занятий:

подготовка и планирование субконтракта,

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

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

выбор субподрядчика,

управление субподрядом.

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

Примеры ориентирования:

предметная область,

применяемые технологии разработки, используемые инструменты разработки,

используемые методики,

применяемые стандарты,

используемые процедуры.

 

Выполняемые операции

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

Эта процедура обычно определяет следующее:

1. Выбор программных продуктов и работ для передачи на субподряд основывается на сбалансированной оценке технических и нетехнических характеристик проекта.

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

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

2. Для составления спецификации субподрядных работ, применяемых стандартов и процедур используются следующие проектные документы:

техническое задание,

системные требования, отнесенные к ПО,

требования к ПО,

план разработки ПО,

стандарты и процедуры разработки.

3. Техническое задание на субподряд:

подготавливается,

проверяется,

согласуется.

Примеры сотрудников, в чьи обязанности входит проверка и согласование технического задания на субподряд:

менеджер проекта,

производственный менеджер проекта,

ответственные производственные менеджеры,

менеджер по управлению конфигурацией ПО,

менеджер по обеспечению качества ПО,

менеджер субподряда.

исправляется по мере необходимости,

является управляемым и контролируемым.

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

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

Практики, связанные со стандартным содержанием технического задания, содержатся в описании Предпосылки № 1 группы ключевых процессов «Планирование проекта».

4. План выбора субподрядчика подготавливается одновременно с техническим заданием на субподряд и исправляется по мере необходимости.

Операция 2 В соответствии с документированной процедурой проводится выбор субподрядчика на основании оценки его способности выполнить определенную работу.

В этой процедуре оцениваются следующие факторы:

1. Поданные предложения по планируемому субподряду.

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

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

4. Возможности по разработке ПО и управлению разработкой.

Примером метода оценки возможностей субподрядчика может служить метод SEI для оценки продуктивности процесса разработки (Software Capability Evaluation).

5. Наличие персонала для выполнения работы.

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

7. Доступные ресурсы.

Примеры ресурсов:

производственные помещения,

аппаратное обеспечение,

программное обеспечение,

средства обучения.

Операция 3 Договор между генеральным подрядчиком и субподрядчиком используется в качестве основы для управления субподрядом.

Документы договора:

1. Условия договора.

2. Техническое задание.

Практики, связанные со стандартным содержанием технического задания, содержатся в описании Предпосылки № 1 группы ключевых процессов «Планирование проекта».

3. Требования к разрабатываемым продуктам.

4. Список зависимостей между субподрядчиком и генеральным подрядчиком.

5. Перечень продуктов, поставляемых субподрядчиком генеральному подрядчику.

Примеры продуктов:

исходный код,

план разработки ПО,

среда эмуляции,

проектная документация,

план приемочного тестирования.

6. Условия внесения исправлений в продукты.

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

Операция 4 Представленный субподрядчиком документированный план разработки ПО рассматривается и утверждается генеральным подрядчиком.

1. Этот план разработки ПО раскрывает (непосредственно или по ссылке) соответствующие позиции из аналогичного плана генерального подрядчика.

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

Практики, связанные с содержанием плана разработки ПО, содержатся в описании Операции № 7 группы ключевых процессов «Планирование проекта».

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

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

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

Операция 7 Регулярные проверки состояния работ и координационные совещания, проводимые совместно руководителями генерального подрядчика и субподрядчика.

1. Субподрядчик по мере необходимости получает информацию о потребностях и запросах заказчиков и конечных пользователей продукта.

В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.

2. Технические, финансовые, кадровые аспекты и показатели календарного графика субподрядчика сравниваются с его планом разработки ПО.

3. Рассматривается использование критических компьютерных ресурсов проекта. Вклад субподрядчика в текущие оценочные расчеты отслеживается и сравнивается с расчетами для каждого компонента ПО в соответствии с документированной процедурой.

4. Рассматриваются критические зависимости и обязательства между разработчиками субподрядчика и его другими группами.

5. Рассматриваются критические зависимости и обязательства между генеральным подрядчиком и субподрядчиком.

Обсуждение обязательств носит взаимный характер.

6. Рассматриваются несоответствия по договору о субподряде.

7. Рассматриваются проектные риски, связанные с субподрядной работой.

8. Изучаются конфликты и проблемы, которые субподрядчик не может решить самостоятельно.

9. Поручение и проверка корректирующих действий, а также отслеживание их выполнения.

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

Эти проверки:

1. Дают субподрядчику информацию о потребностях и запросах заказчиков и конечных пользователей.

2. Позволяют отслеживать технические операции субподрядчика.

3. Позволяют убедиться в том, что субподрядчик интерпретирует и реализует технические требования в соответствии с требованиями генерального подрядчика.

4. Контролируют выполнение обязательств.

5. Контролируют своевременность решения технических проблем.

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

Эта процедура обычно определяет следующее:

1. Проверки предварительно планируются и документируются в техническом задании.

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

3. Определяются и документируются значительные проблемы, предпринятые действия и принятые решения.

4. Изучаются риски разработки.

5. По мере необходимости уточняется план субподрядчика по разработке ПО.

Операция 10 Группа обеспечения качества со стороны генерального подрядчика отслеживает мероприятия субподрядчика по обеспечению качества ПО в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

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

Группа обеспечения качества со стороны генерального подрядчика выборочно проверяет ход работ и продукты субподрядчика.

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

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

Операция 11 Мероприятия субподрядчика по управлению конфигурацией ПО отслеживаются соответствующей группой генерального подрядчика согласно документированной процедуре.

Эта процедура обычно определяет следующее:

1. Регулярно проверяется адекватность планов, ресурсов, процедур и стандартов субподрядчика по управлению конфигурацией ПО.

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

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

Операция 12 В ходе процесса поставки программных продуктов, отданных на субподряд, генеральный подрядчик проводит их приемочное тестирование в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Генеральный подрядчик и субподрядчик определяют, рассматривают и утверждают процедуры и критерии приемки для каждого продукта до начала тестирования.

2. Результаты приемочных тестов документируются.

3. Для любого программного продукта, не прошедшего приемочное тестирование, составляется план корректирующих действий.

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

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

 

Измерения и анализ

Измерение 1 Выполнение измерений и использование их результатов для определения состояния работ по управлению субподрядом.

Примеры измерений:

расходы на работы по управлению субподрядом в сравнении с плановыми значениями,

фактические даты поставки продуктов, отданных на субподряд, в сравнении с запланированными,

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

 

Проверка внедрения

Проверка 1 Регулярная проверка высшим руководством выполнения работ по управлению субподрядом.

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

Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 2 Регулярные и событийные проверки менеджером проекта работ по управлению субподрядом.

Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

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

См. группу ключевых процессов «Обеспечение качества ПО».

Минимальное содержание проверок и/или аудитов:

1. Мероприятия по выбору субподрядчика.

2. Работы по управлению субподрядом.

3. Мероприятия по координации работ по управлению конфигурацией между генеральным подрядчиком и субподрядчиком.

4. Проведение плановых проверок с участием субподрядчика.

5. Проведение проверок по завершению ключевых этапов проекта или стадий работы по субподряду.

6. Процесс приемки программных продуктов от субподрядчика.

 

8.5. Обеспечение качества ПО

Группа ключевых процессов для уровня 2: повторяемый уровень.

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

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

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

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

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

 

Цели

Цель 1 Планирование работ по обеспечению качества ПО.

Цель 2 Объективная проверка соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям.

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

Цель 4 Передача на рассмотрение высшему руководству вопросов несоответствия, не решаемых на уровне проекта.

 

Обязательства по выполнению

Обязательство 1 Проект следует документированной организационной политике по обеспечению качества ПО.

Эта политика обычно состоит из следующих положений.

1. Группа обеспечения качества контролирует работу по всем проектам разработки в организации.

2. Группа обеспечения качества имеет канал отчетности перед высшим руководством, который независим от:

менеджера проекта,

группы разработки ПО,

других групп, связанных с разработкой ПО.

Примеры групп, связанных с разработкой ПО:

группа управления конфигурацией ПО,

группа управления документацией.

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

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

3. Высшее руководство регулярно проверяет деятельность группы обеспечения качества и ее результаты.

 

Необходимые предпосылки

Предпосылка 1 Необходимо наличие группы, ответственной за координацию и реализацию в проекте процесса обеспечения качества ПО (т. е. группы SQA).

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

Предпосылка 2 Работы по обеспечению качества должны быть обеспечены соответствующими ресурсами и финансированием.

1. Для руководства специфической деятельностью по обеспечению качества в проекте назначается специальный менеджер.

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

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

3. Работы по обеспечению качества обеспечиваются вспомогательными инструментальными средствами.

Примеры вспомогательных инструментальных средств:

рабочие станции,

СУБД,

электронные таблицы,

средства проведения аудита.

Предпосылка 3 Члены группы обеспечения качества должны пройти обучение для выполнения своих задач.

Примеры тем учебных занятий: навыки и практические методы разработки ПО; роли и сферы ответственности группы разработки

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

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

 

Выполняемые операции

Операция 1 Для каждого проекта по разработке ПО подготавливается план работ по обеспечению качества в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. План обеспечения качества разрабатывается на ранних стадиях общего планирования проекта и параллельно с ним.

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

3. Документ плана обеспечения качества должен быть управляемым и контролируемым. «Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта (т. е. реализован контроль версий), а внесение изменений происходит управляемым образом (т. е. реализовано управление изменениями).

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

Операция 2 Группа обеспечения качества выполняет свои работы в соответствии с планом обеспечения качества.

План охватывает следующие вопросы:

1. Сфера ответственности и полномочия группы обеспечения качества.

2. Ресурсы, требующиеся группе обеспечения качества (включая персонал, инструменты и инженерные средства).

3. Календарный план и финансирование работ группы обеспечения качества.

4. Участие группы обеспечения качества в составлении плана разработки ПО, стандартов и процедур проекта.

5. Оценки, выполняемые группой обеспечения качества.

Примеры оцениваемых продуктов и работ:

рабочее ПО и вспомогательные программы,

продукты как предназначенные для поставки заказчику, так и внутреннего пользования,

программные и непрограммные продукты (например, документы),

операции по разработке и проверке продукта (например, выполнение сценариев тестирования),

мероприятия, проводимые после создания продукта.

6. Аудиты и проверки, проводимые группой обеспечения качества.

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

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

9. Документация, требуемая от группы обеспечения качества.

10. Способ и периодичность предоставления отзывов по результатам мероприятий по обеспечению качества для группы разработки ПО и других смежных групп.

Операция 3 Группа обеспечения качества участвует в подготовке и обсуждении плана разработки ПО, стандартов и процедур проекта.

1. Группа обеспечения качества рассматривает планы, стандарты и процедуры проекта и консультирует участников проекта по следующим вопросам:

соответствие организационной политике,

соответствие внешним стандартам и требованиям (например, стандартам, обусловленным техническим заданием),

стандарты, подходящие для применения в проекте, темы, которые должны быть рассмотрены в плане разработки ПО,

другие вопросы, имеющие отношение к проекту.

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

Операция 4 Группа обеспечения качества проверяет производственный процесс разработки ПО на соответствие требованиям.

1. Ход производственного процесса сравнивается с планом разработки ПО и установленными стандартами и процедурами разработки.

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

2. Отклонения от требований выявляются, документируются и отслеживаются до их устранения. 3. Контролируется выполнение корректирующих действий.

Операция 5 Группа обеспечения качества проводит аудит определенных промежуточных программных продуктов на соответствие требованиям.

1. Поставляемые программные продукты оцениваются до того, как они будут переданы заказчику.

2. Промежуточные программные продукты проверяются на соответствие установленным стандартам, процедурам и требованиям договора.

3. Отклонения от требований выявляются, документируются и отслеживаются до их устранения. 4. Контролируется выполнение корректирующих действий.

Операция 6 Группа обеспечения качества регулярно докладывает разработчикам о результатах своей работы.

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

Эта процедура обычно определяет следующее:

1. Отклонения от плана разработки ПО и установленных стандартов и процедур проекта документируются и, по возможности, устраняются при участии ведущих специалистов, производственных менеджеров или менеджера проекта.

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

3. Проблемы несоответствий, поставленные перед руководителем высшего звена, периодически рассматриваются до своего разрешения.

4. Документация по вопросам несоответствий должна быть управляемой и контролируемой.

Операция 8 Группа обеспечения качества проводит регулярные обсуждения своих мероприятий и их результатов (по возможности — совместно с представителями заказчика по вопросам обеспечения качества).

 

Измерения и анализ

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

Примеры измерений:

выполнение этапов работ по обеспечению качества в сравнении с планом;

определение объема выполненных работ по обеспечению качества и израсходованных при этом ресурсов в сравнении с запланированными значениями;

количество проведенных аудитов продуктов и проверок хода работ в сравнении с запланированным.

 

Проверка внедрения

Проверка 1 Регулярная проверка высшим руководством работ по обеспечению качества.

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

Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 2 Регулярные и событийные проверки менеджером проекта работ по обеспечению качества.

Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 3 Периодическая проверка экспертами, независимыми от группы обеспечения качества, проводимых ею мероприятий и выходных документов.

 

8.6. Управление конфигурацией ПО

Группа ключевых процессов для уровня 2: повторяемый уровень

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

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

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

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

 

Цели

Цель 1 Управление конфигурацией ПО происходит на плановой основе.

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

Цель 3 Изменения в определенных промежуточных программных продуктах происходят управляемым образом.

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

 

Обязательства по выполнению

Обязательство 1 Проект следует документированной организационной политике управления конфигурацией ПО (Software Configuration Management, SCM).

Эта политика обычно состоит из следующих положений:

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

2. Управление конфигурацией ПО реализуется в течение всего жизненного цикла проекта.

3. Управление конфигурацией ПО реализуется для конечных программных продуктов, определенных внутренних промежуточных программных продуктов, а также определенных вспомогательных инструментальных средств, используемых внутри проекта (например, компиляторов).

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

В этих практиках содержание данного репозитария называется «библиотекой базовых линий конфигурации».

Инструменты и процедуры доступа к этому репозитарию называются «системой управления библиотекой конфигураций».

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

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

5. Регулярно проводится аудит базовых линий и работ по управлению конфигурацией ПО.

 

Необходимые предпосылки

Предпосылка 1 Должна существовать или быть создана комиссия по управлению базовыми линиями проекта (т. е. комиссия по управлению конфигурацией ПО, Software Configuration Control Board, SCCB).

Задачи комиссии SCCB:

1. Санкционирование создания базовых линий, выявление конфигураций и их элементов.

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

Примеры групп, задействованных в проекте:

обеспечения качества аппаратного обеспечения,

управления конфигурацией аппаратного обеспечения,

проектирования аппаратного обеспечения,

производственного проектирования,

разработки ПО (включая все подгруппы, например, проектирования ПО),

системного проектирования,

системного тестирования,

обеспечения качества ПО,

управления конфигурацией ПО,

управления договорами,

управления документацией.

3. Ревизия и санкционирование изменений базовых линий.

4. Санкционирование создания продуктов из элементов библиотеки базовых линий.

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

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

Группа управления конфигурацией ПО координирует или реализует следующие задачи:

1. Создание библиотеки базовых линий проекта и управление ею.

2. Разработка, сопровождение и распространение планов, стандартов и процедур по управлению конфигурацией.

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

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

5. Обновление базовых линий конфигурации.

6. Создание продуктов из элементов библиотеки базовых линий.

7. Запись действий по управлению конфигурацией ПО.

8. Создание и распространение отчетов по управлению конфигурацией.

Предпосылка 3 Работы по управлению конфигурацией ПО должны быть обеспечены соответствующими ресурсами и финансированием.

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

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

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

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

Предпосылка 5 Члены группы разработки ПО и других смежных групп должны пройти обучение выполнению своих задач по управлению конфигурацией.

Примеры групп, связанных с разработкой ПО:

группа обеспечения качества ПО,

группа управления документацией.

Примеры тем учебных занятий:

стандарты,

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

роль, сфера ответственности и полномочия группы управления конфигурацией ПО.

 

Выполняемые операции

Операция 1 Для каждого проекта по разработке ПО готовится план управления конфигурацией в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

2. План управления конфигурацией ПО рассматривается задействованными группами.

3. Документ плана управления конфигурацией ПО должен быть управляемым и контролируемым.

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

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

Операция 2 Документированный и утвержденный план управления конфигурацией используется в качестве основы для выполнения работ по SCM.

План охватывает следующие вопросы:

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

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

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

Задачи, решаемые данной библиотечной системой:

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

2. Хранение и извлечение отдельных элементов/блоков конфигурации. 3. Обеспечение совместного использования и передачи элементов/блоков конфигурации между задействованными группами и между уровнями контроля внутри библиотеки. 4. Помощь в применении производственных стандартов к элементам/блокам конфигурации. 5. Хранение и извлечение архивных версий отдельных элементов/блоков конфигурации. 6. Обеспечение корректного создания продуктов на основе элементов из библиотеки базовых линий. 7. Хранение, обновление и предоставление записей по управлению конфигурацией. 8. Поддержка создания отчетов по управлению конфигурацией. 9. Поддержка структуры и содержимого библиотеки.

Примеры функций поддержки библиотеки:

резервное копирование/восстановление библиотечных файлов,

восстановление библиотечной системы после сбоев.

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

1. Выбор отдельных элементов/блоков конфигурации на основании документированных критериев.

Примеры промежуточных программных продуктов, которые можно определить в качестве элементов/блоков конфигурации:

документация по процессу (т. е. планы, стандарты или процедуры), требования к ПО, архитектура ПО, модули программного кода, процедуры тестирования ПО,

программная система, созданная для проведения тестирования ПО,

программная система, созданная для передачи заказчику или конечным пользователям,

компиляторы, другие вспомогательные инструментальные средства.

2. Элементам/блокам конфигурации присваиваются уникальные идентификаторы.

3. Определяются характеристики каждого элемента/блока конфигурации.

4. Определяются базовые линии, которым принадлежат элементы/блоки конфигурации.

5. Для каждого элемента/блока конфигурации определяется стадия разработки, на которой он помещается в систему управления конфигурацией.

6. Определяется ответственный за каждый элемент/блок конфигурации (т. е. его владелец с точки зрения управления конфигурацией).

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

Операция 6 Изменения базовых линий контролируются в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

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

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

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

Операция 7 Создание продуктов на основе библиотеки базовых линий и контролирование их выпуска в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Комиссия SCCB санкционирует создание продуктов на основе библиотеки базовых линий.

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

Операция 8 Запись статуса элементов/блоков конфигурации в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

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

2. Ведение текущего статуса и истории (т. е. истории изменений и других действий) для всех элементов/блоков конфигурации.

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

Примеры отчетов:

протоколы совещаний комиссии SCCB,

краткое описание и статус запроса на изменение,

краткое описание и статус отчета о проблемах (включая решения проблем),

краткое описание изменений базовых линий,

история изменений элементов/блоков конфигурации,

статус базовой линии конфигурации,

результаты аудитов базовых линий.

Операция 10 Проведение аудитов базовых линий конфигурации в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Аудит должен быть подготовлен соответствующим образом.

2. Проводится оценка целостности базовых линий.

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

4. Проверяется полнота и корректность содержимого библиотеки базовых линий.

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

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

7. Действия, рекомендуемые по результатам аудита, отслеживаются до их завершения.

 

Измерения и анализ

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

Примеры измерений:

количество запросов на изменение, обрабатываемое за единицу времени;

выполнение этапов работ по управлению конфигурацией в сравнении с планом;

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

 

Проверка внедрения

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

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

Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 2. Регулярные и событийные проверки менеджером проекта работ по управлению конфигурацией ПО.

Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 3. Регулярный аудит базовых линий, проводимый группой управления конфигурацией ПО в целях проверки их соответствия определяющей документации.

Проверка 4. Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов SCM и выполнение отчетов по их результатам.

См. группу ключевых процессов «Обеспечение качества ПО».

Минимальное содержание проверок и/или аудитов:

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

группы управления конфигурацией ПО, комиссии SCCB,

группы разработки ПО,

других групп, связанных с разработкой ПО.

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