Марк Паулк - Модель зрелости процессов разработки программного обеспечения

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

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

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

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

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

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

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

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

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

измерения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

заказчик,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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