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

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

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

Цели

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

Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.

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

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

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

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

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

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

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

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

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

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

Высшее руководство:

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

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

3. Устанавливает стратегии управления и реализации действий по разработке и усовершенствованию производственного процесса.

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

Высшее руководство:

1. Обеспечивает соответствие СППО бизнес-целям и стратегиям организации.

2. Дает рекомендации по определению приоритетов при разработке и усовершенствовании производственного процесса.

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

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

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

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

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

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

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

Наиболее общим примером такой группы является группа инженерии производственного процесса (SEPG).

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

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

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

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

составление кода,

тестирование ПО,

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

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

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

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

Примеры специализированных областей:

повторное использование ПО,

технология автоматизированной разработки ПО (CASE),

измерения,

разработка учебных курсов.

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

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

инструменты статистического анализа,

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

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

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

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

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

практические методы разработки ПО;

методы контролирования процесса;

управление изменениями в рамках организации;

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

внедрение новых технологий.

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

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

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

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

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

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

Примером метода оценки продуктивности ППО может служить метод оценки производственного процесса (Software Process Assessment), разработанный институтом SEI.

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

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

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

группы или сотрудники, ответственные за реализацию изменений.

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

Данный план:

1. Использует в качестве исходных данных планы действий по оценке производственного процесса и других инициатив по усовершенствованию организации.

2. Определяет необходимые мероприятия и график их проведения.

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

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

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

6. Проверяется и согласуется производственными менеджерами и руководителями высшего звена.

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

Эта координация касается разработки и усовершенствования следующих процессов:

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

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

2. Производственные процессы проекта.

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

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

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

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

Операции № 5 группы ключевых процессов «Определение производственного процесса организации».

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

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

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

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

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

Операция 7. Группы, задействованные во внедрении производственных процессов, информируются о мероприятиях по разработке и усовершенствованию процессов, проводимых в рамках организации и проектов.

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

электронные доски объявлений по производственным процессам,

экспертные комиссии по процессам,

рабочие группы,

совещания по обмену информацией,

обзоры,

группы усовершенствования процессов,

неформальные обсуждения.

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

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

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

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

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

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

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

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

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

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

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

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

9.2. Определение производственного процесса организации

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

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

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

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

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

Цели

Цель 1. Разработка и сопровождение стандартного производственного процесса организации.

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

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

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

Основные средства ППО:

стандартный производственный процесс организации,

инструкции и критерии для адаптации СППО к конкретному проекту,

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

база данных ППО,

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

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

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

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

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

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

Примеры собираемой информации:

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

накопленный опыт,

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

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

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

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

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

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

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

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

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

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

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

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

практика и методы разработки ПО,

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

моделирование процессов.

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

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

Операция 1. Разработка и сопровождение СППО происходит в соответствии с документированной процедурой.

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

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

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

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

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

Примеры областей разработки ПО:

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

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

составление кода,

тестирование ПО,

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

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

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

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

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

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

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

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

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

Примеры источников изменений:

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

результаты адаптации СППО к конкретному проекту,

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

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

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

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

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

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

9. Описание СППО помещается в систему управления конфигурацией.

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

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

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

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

Примеры элементов процесса:

элемент оценки ПО,

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

элемент кодирования,

элемент экспертной оценки.

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

2. Описание каждого элемента процесса содержит ответы на следующие вопросы:

необходимые процедуры, практики, методы и технологии;

применяемые стандарты процессов и продуктов;

распределение ответственности за внедрение процесса;

необходимые инструменты и ресурсы;

исходные данные;

создаваемые промежуточные программные продукты;

промежуточные программные продукты, подлежащие экспертной оценке;

критерии готовности и завершения;

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

3. Описание отношений между элементами процесса касается следующих вопросов:

очередность,

интерфейсы,

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

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

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

«водопад»,

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

«спираль»,

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

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

1. Жизненные циклы ПО должны быть совместимы с СППО.

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

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

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

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

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

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

1. Инструкции и критерии адаптации касаются следующих вопросов:

выбор и адаптация жизненного цикла ПО для проекта;

адаптация СППО с учетом жизненного цикла ПО и характеристик проекта;

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

Примеры адаптации:

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

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

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

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

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

Операция 5. Формирование и сопровождение базы данных производственного процесса организации (ППО).

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

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

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

трудоемкости разработки и затрат;

фактические данные по объему ПО, трудоемкости разработки и затратам;

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

измерения качества ПО;

охват и эффективность экспертных оценок;

охват и эффективность тестирования;

меры по повышению надежности ПО;

количество и серьезность недостатков, обнаруженных в требованиях к ПО;

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

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

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

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

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

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

Операция 6. Формирование и сопровождение библиотеки документации по производственным процессам.

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

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

стандарты проекта,

процедуры проекта,

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

проектные планы измерений,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

статус выполнения этапов календарного плана разработки и сопровождения ППО,

затраты на работы по определению процесса.

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

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

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

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

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

2. Контроль и использование СППО и связанных с ним основных средств.

9.3. Программа обучения

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

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

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

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

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

Цели

Цель 1. Мероприятия по обучению проводятся на плановой основе.

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

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

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

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

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

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

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

проведение семинаров,

машинное обучение,

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

формализованные программы наставничества,

обучающие видеофильмы.

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

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

Примеры внешних источников обучения:

обучение, проводимое заказчиком,

коммерческие учебные курсы,

академические программы,

профессиональные конференции,

семинары.

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

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

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

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

Примеры элементов программы обучения:

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

учебные материалы,

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

проведение обучения,

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

оценка обучения,

ведение данных по обучению.

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

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

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

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

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

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

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

3. Проведение обучения обеспечивается соответствующими помещениями.

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

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

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

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

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

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

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

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

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

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

1. Набор необходимых навыков и время, к которому они потребуются.

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

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

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

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

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

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

изучение конкретных приложений и требований к проекту,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

группа обучения,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Описание следующих процедур:

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

регистрация слушателей и их участие в обучении,

ведение записей по проведенному обучению,

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

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

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

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

Примеры вопросов, раскрываемых в описании курса:

предполагаемая аудитория слушателей,

подготовка к участию в обучении,

цели обучения,

продолжительность обучения,

планы занятий,

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

процедуры периодической оценки эффективности обучения,

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

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

2. Проверка материалов учебного курса.

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

эксперты по обучению,

эксперты по предметным областям,

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

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

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

Операция 6. Ведение записей по проводимому обучению.

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

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

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

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

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

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

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

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

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

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

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

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

отзывы слушателей по учебным курсам,

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

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

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

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

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

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

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

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

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

3. Корректность ведения записей по обучению.

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

5. Следование плану обучения в рамках организации.

9.4. Интегрированное управление разработкой ПО

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

использование базы данных ППО,

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Жизненный цикл ПО:

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

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

при необходимости модифицируется в соответствии с принятыми в организации инструкциями и критериями адаптации;

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

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

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

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

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

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

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

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

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

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

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

1. Документирование и систематическое рассмотрение изменений, вызываемых следующими источниками:

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

изменениями, предложенными группой разработки проекта,

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

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

Примеры сотрудников, проверяющих изменения:

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

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

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

Примеры сотрудников, утверждающих изменения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры несоответствий и проблем:

различия в уровнях зрелости процессов,

несовместимость процессов,

различные экономические факторы.

Операция 5. Использование базы данных ППО для планирования и оценочных расчетов для проекта разработки.

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

Примеры информации, содержащейся в базе данных ППО:

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

трудоемкость разработки,

затраты на разработку,

календарный график,

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

технические работы.

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

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

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

записи обоснований достоверности оценочных расчетов проекта.

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

Примеры записываемой проектной информации:

описание задачи,

сделанные предположения,

оценочные расчеты,

пересмотренные оценки,

фактические данные измерений,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры характеристик проекта:

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

объем и сложность системы,

стабильность требований,

хост-среда разработки,

целевая среда системы,

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

доступность ресурсов,

другие специфические ограничения.

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

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

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

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

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

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

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

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

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

Документируются источники и обоснования оценок.

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

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

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

3. Доступные компьютерные ресурсы распределяются по компонентам ПО.

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

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

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

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

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

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

Календарный график разработки идентифицирует конкретные задачи и этапы, чье завершение можно определить объективно (т. е. возможно бинарное определение в виде «да/нет»).

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

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

Критические зависимости могут возникать как внутри группы разработки ПО (т. е. между подгруппами), так и между группой разработки и другими задействованными группами.

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

Примеры принимаемых мер:

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

определение страховочных действий и, по возможности, внесение резерва времени в график;

оценка влияния предполагаемых действий на все критические зависимости;

распространение информации о принятых решениях между всеми задействованными группами.

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

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

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

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

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

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

Примеры вопросов, рассматриваемых в плане управления рисками:

необходимые ресурсы (включая персонал и инструментальные средства);

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

список выявленных рисков (включая оценку, приоритет, статус и планируемые действия);

график управления рисками;

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

измерения.

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

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

определение вариантов,

оценка влияния вариантов,

техническая осуществимость вариантов,

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

критерии принятия решений о реализации вариантов.

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

4. Первый вариант и основные изменения плана по управлению рисками проходят экспертную оценку.

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

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

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

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

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

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

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

заказчик,

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

конечные пользователи,

группа оценки объема составляющих проекта,

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

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

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

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

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

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

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

Примеры действий:

ужесточение календарного графика,

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

прекращение проекта.

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

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

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

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

объем выполненных на текущий момент работ по управлению проектом в сравнении с запланированным;

периодичность, причины и масштаб работ по перепланированию;

для каждого выявленного риска разработки — фактическая величина нежелательных последствий в сравнении с расчетной;

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

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

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

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

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

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

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

Как минимум, проверяется следующее:

1. Процесс разработки и пересмотра производственного процесса проекта.

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

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

4. Процессы сбора и предоставления соответствующих данных для базы данных ППО.

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

9.5. Инженерия разработки программного продукта

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

В число задач входят:

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

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

составление кода,

тестирование,

поддержка ПО.

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

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

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

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

справочные системы,

графические инструменты,

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

текстовые процессоры.

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

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

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

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

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

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

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

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

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

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

языки описания архитектуры.

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

редакторы,

компиляторы,

генераторы перекрестных ссылок,

средства печати.

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

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

генераторы тестов,

тестовые драйверы,

тестовые профайлеры,

символьные отладчики,

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

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

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

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

принципы анализа требований к ПО;

существующие требования к имеющемуся и поддерживаемому ПО;

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

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

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

концепции разработки архитектуры;

существующая архитектура имеющегося и поддерживаемого ПО;

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

Примеры обучения для выполнения кодирования:

применяемые языки программирования;

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

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

Примеры обучения тестированию ПО и другим методам контроля:

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

планирование тестов;

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

критерии готовности и завершения тестов;

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

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

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

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

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

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

составление кода,

тестирование,

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

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

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

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

Примеры ориентации:

инструменты и методы разработки ПО,

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

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

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

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

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

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

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

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

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

Документируются обоснования выбора конкретного инструмента или метода.

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

Примеры моделей управления конфигурацией:

модели внесения/извлечения данных,

композиционные модели,

транзакционные модели,

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

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

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

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

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

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

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

Примеры методик анализа требований:

функциональная декомпозиция,

объектно-ориентированная декомпозиция,

изучение альтернатив,

имитация,

моделирование,

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

разработка сценариев.

3. Документируются результаты анализа требований и обоснования выбранного варианта.

4. Требования к ПО анализируются на реализуемость, понятность, непротиворечивость, возможность тестирования и полноту (если имеется в виду набор требований).

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

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

5. Требования к ПО документируются.

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

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

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

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

9. Документ требований к ПО рассматривается и утверждается.

Примеры сотрудников, рассматривающих и утверждающих документ требований к ПО:

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

менеджер по системному проектированию,

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

менеджер по тестированию ПО.

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

11. Документ требований к ПО помещается в систему управления конфигурацией.

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

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

Архитектура ПО состоит из системной архитектуры и архитектуры программы.

1. Создание и проверка критериев разработки архитектуры ПО.

Примеры критериев разработки архитектуры ПО:

возможность проверки,

соблюдение стандартов для архитектуры ПО,

удобство реализации,

простота,

удобство планирования реализации.

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

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

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

стандарты интерфейсов операционной системы,

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

стандарты сетевых интерфейсов.

4. Для проектирования архитектуры ПО используются эффективные методы.

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

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

структурные модели,

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

объектно-ориентированное проектирование,

системный анализ.

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

Системная архитектура описывает программную структуру верхнего уровня с четко определенными внутренними и внешними интерфейсами.

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

7. На основании системной архитектуры разрабатывается подробная архитектура программного комплекса.

8. Документируется описание архитектуры ПО (т. е. документируется собственно системная архитектура и детальная архитектура программы).

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

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

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

10. Документ, описывающий архитектуру ПО, помещается в систему управления конфигурацией.

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

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

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

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

2. Для создания кода используются эффективные методы программирования. Примеры методов программирования: структурированное программирование, повторное использование кода.

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

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

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

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

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

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

Операция 5. Тестирование ПО выполняется в соответствии с производственным процессом проекта.

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

2. Тестирование ПО осуществляется с помощью эффективных методов.

3. Адекватность тестирования определяется следующими факторами:

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

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

модульное тестирование,

интеграционное тестирование,

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

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

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

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

функциональная («черный ящик»),

структурная («прозрачный ящик»),

статистическая.

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

Примеры тестового покрытия:

покрытие операторов,

покрытие путей,

покрытие ветвей,

профиль использования.

4. Для каждого уровня тестирования ПО устанавливаются и используются критерии готовности к тестированию.

Примеры критериев, определяющих готовность к тестированию:

до проведения интеграционного тестирования программные модули должны успешно пройти экспертную оценку и модульное тестирование,

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

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

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

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

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

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

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

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

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

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

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

Операция 7. Планирование и выполнение системного и приемочного тестирования ПО в целях демонстрации его соответствия требованиям.

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

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

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

Примеры работ по подготовке тестирования:

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

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

разработка тестовых драйверов,

разработка симуляторов.

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

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

общий подход к тестированию и проверке;

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

требования к испытательному оборудованию, оснащению и поддержке процесса тестирования;

критерии приемки.

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

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

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

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

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

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

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

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

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

Примеры методов и инструментов:

использование текстовых процессоров,

изучение сценариев,

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

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

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

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

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

5. Документация подвергается экспертной оценке. См. группу ключевых процессов «Экспертные оценки».

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

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

Операция 9. Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта.

Примеры собираемых и анализируемых данных:

описание дефекта,

категория дефекта,

серьезность дефекта,

модули, содержащие дефект,

модули, подверженные влиянию дефекта,

операция, в которой проявился дефект,

экспертная оценка или тестовые сценарии, выявившие дефект,

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

ожидаемые и фактические результаты, выявляющие дефект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменения отслеживаются до своей реализации.

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

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

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

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

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

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

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

статус каждого установленного требования в течение всего проекта;

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

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

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

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

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

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

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

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

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

1. Проверка следующих качеств требований к ПО:

полнота,

корректность,

непротиворечивость,

осуществимость,

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

2. Выполнение критериев готовности и завершения для каждой задачи разработки ПО.

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

4. Выполнение требуемого тестирования.

5. Выполнение системного и приемочного тестирования ПО в соответствии с документированными планами и процедурами.

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

7. Успешное выполнение тестов и запись их результатов.

8. Документирование, отслеживание и принятие мер по устранению обнаруженных проблем и недостатков.

9. Отслеживание установленных требований до требований к ПО, архитектуры, кода и тестовых сценариев.

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

9.6. Межгрупповая координация

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

текстовые процессоры,

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

графические инструменты,

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

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

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

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

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

формирование групп;

управление группами;

установление, стимулирование коллективной работы и содействие ей;

групповая динамика.

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

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

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

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

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

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

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

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

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

2. Обсуждение критических зависимостей.

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

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

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

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

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

В состав системных требований и архитектуры входит следующее:

общие системные требования,

системная конфигурация (т. е. аппаратное и программное обеспечение, другие системные компоненты),

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

определения интерфейсов между этими системными компонентами.

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

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

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

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

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

решение конфликтов проектного уровня и выяснение вопросов, касающихся системных требований и архитектуры;

разработка совместных рекомендаций для решения проблем;

изучение вопросов, касающихся организации процессов и затрагивающих все инженерные группы проекта.

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

1. Данный план является базовой линией для:

календарного графика проекта,

договорных и технических аспектов проекта,

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

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

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

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

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

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

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

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

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

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

что должно быть подготовлено,

кто должен это подготовить,

когда это должно быть подготовлено,

критерии приемки.

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

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

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

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

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

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

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

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

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

Примеры межгрупповых проблем:

несовместимые календарные графики,

неадекватное финансирование,

технические риски,

дефекты системной архитектуры и требований,

проблемы системного уровня.

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

Участники этих проверок и совещаний решают следующие задачи:

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

2. Проверка хода технических работ проекта.

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

4. Проверка выполнения обязательств.

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

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

Операции № 10 группы ключевых процессов «Интегрированное управление разработкой ПО».

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

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

Примеры фактических измерений:

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

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

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

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

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

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

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

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

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

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

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

2. Управление межгрупповыми проблемами.

9.7. Экспертные оценки

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

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

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

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

Цели

Цель 1. Планирование работ по проведению экспертных оценок.

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

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

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

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

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

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

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

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

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

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

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

описания процессов.

3. Экспертные оценки проводятся под руководством ведущих экспертов, опытных в их проведении.

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

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

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

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

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

1. Подготовка и распространение материалов экспертной оценки.

2. Руководство проведением экспертной оценки.

3. Рассмотрение материалов.

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

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

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

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

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

цели, принципы и методы экспертных оценок;

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

критерии готовности к экспертной оценке и ее завершения;

проведение экспертной оценки;

отчетность по результатам экспертной оценки;

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

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

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

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

типы экспертных оценок (например, проверки требований к ПО, архитектуры ПО, кода и процедур тестирования ПО);

цели, принципы и методы экспертных оценок;

роли экспертов; определение трудоемкости подготовки и проведения экспертных оценок.

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

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

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

Эти планы определяют:

1. Промежуточные программные продукты, подлежащие экспертной оценке.

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

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

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

Операция 2. Проведение экспертных оценок в соответствии с документированной процедурой.

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

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

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

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

Примеры соответствующей исходной информации:

цели промежуточного программного продукта,

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

соответствующие требования к архитектурному модулю,

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

3. Участникам экспертной оценки назначаются роли.

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

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

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

Контрольные списки адаптируются к конкретному типу промежуточного продукта и экспертной оценки.

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

соответствие стандартам и процедурам,

полнота,

корректность,

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

возможности поддержки.

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

6. Действия, определенные в ходе экспертной оценки, отслеживаются до своего выполнения.

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

Операция 3. Запись данных о ходе и результатах экспертных оценок.

Примеры данных:

идентификация проверенного промежуточного программного продукта,

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

размер и состав группы экспертов,

время, выделенное каждому эксперту на подготовку к оценке,

продолжительность совещания по экспертной оценке,

типы и количество обнаруженных и устраненных дефектов,

трудоемкость доработки.

Измерения и анализ

Измерение 1. Выполнение измерений и использование их результатов для определения статуса работ по проведению экспертных оценок.

Примеры измерений:

количество выполненных экспертных оценок в сравнении с планом,

общая трудоемкость выполненных экспертных оценок в сравнении с планом,

количество проверенных промежуточных продуктов в сравнении с планом.

Проверка внедрения

Проверка 1. Проведение группой обеспечения качества (SQA) проверок и/или аудитов работ и промежуточных продуктов, связанных с экспертными оценками, и выполнение отчетов по их результатам.

См. группу ключевых процессов «Обеспечение качества ПО».

Минимальное содержание этих проверок и/или аудитов:

1. Проведение запланированных экспертных оценок.

2. Адекватное обучение ведущих экспертов для выполнения их ролей.

3. Полученное обучение или наличие опыта в выполнении своих ролей у экспертов.

4. Следование процессу подготовки, проведения экспертных оценок и выполнения действий по их результатам.

5. Своевременная подача полных и точных отчетов по результатам экспертных оценок.

Оглавление