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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

измерения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

заказчик,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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