Эта процедура обычно определяет следующее:
1. Этапы, задачи, обязательства, критические зависимости, укомплектование персоналом, затраты и проверки распределяются в графике в соответствии с производственным процессом проекта.
Календарный график разработки идентифицирует конкретные задачи и этапы, чье завершение можно определить объективно (т. е. возможно бинарное определение в виде «да/нет»).
Для учета потребностей различных групп и сотрудников разрабатываются различные уровни детализации графика, связанные друг с другом соответствующим образом.
2. Определяются и обсуждаются критические зависимости, после чего они отражаются в календарном графике разработки.
Критические зависимости могут возникать как внутри группы разработки ПО (т. е. между подгруппами), так и между группой разработки и другими задействованными группами.
3. Определяются критические последовательности, после чего они отражаются в календарном графике разработки. 4. Критические зависимости проекта и критические последовательности календарного графика регулярно отслеживаются. 5. Для каждой критической последовательности устанавливается специфический документированный пороговый критерий, при ожидаемом превышении которого требуется принятие соответствующих мер.
Примеры принимаемых мер:
анализ и моделирование компромиссных вариантов функций, качества, затрат, графика, персонала и других ресурсов;
определение страховочных действий и, по возможности, внесение резерва времени в график;
оценка влияния предполагаемых действий на все критические зависимости;
распространение информации о принятых решениях между всеми задействованными группами.
Операция 10. Выявление, оценка, документирование рисков проекта разработки и управление ими проводится в соответствии с документированной процедурой.
Основные практики, связанные с выявлением и отслеживанием рисков, содержатся в описании Операции № 13 группы ключевых процессов «Планирование проекта» и Операции № 10 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Примеры областей, в которых риски могут с большой вероятностью привести к срыву проекта: календарный график, затраты, функциональные возможности разрабатываемой системы, пропускная способность или реальная производительность, надежность и доступность, использование критических компьютерных ресурсов.
Примеры работ по управлению рисками: раннее выявление проектных задач с высокой степенью риска; определение событий, порождающих риски или повышающих их вероятность; создание прототипов или ранняя реализация модулей с высокой степенью риска; тщательное отслеживание индикаторов ключевых рисков проекта.
Эта процедура обычно определяет следующее:
1. Документируется план управления рисками разработки, который затем используется для выявления рисков и управления ими.
Примеры вопросов, рассматриваемых в плане управления рисками:
необходимые ресурсы (включая персонал и инструментальные средства);
методы управления рисками (т. е. выявление, анализ, определение приоритетов, планирование, мониторинг и устранение);
список выявленных рисков (включая оценку, приоритет, статус и планируемые действия);
график управления рисками;
обязанности и полномочия; метод и периодичность распространения информации о статусе рисков и связанных с ними мероприятиях;
измерения.
2. Планирование страховочных действий основывается на производственном процессе проекта и выполняется в течение всего жизненного цикла разработки.
Примеры областей, в которых проводится планирование страховочных действий:
определение вариантов,
оценка влияния вариантов,
техническая осуществимость вариантов,
распределение резервов управления,
критерии принятия решений о реализации вариантов.
3. Для каждого риска разработки, по возможности, определяются альтернативные решения и критерии выбора альтернатив.
4. Первый вариант и основные изменения плана по управлению рисками проходят экспертную оценку.
См. группу ключевых процессов «Экспертные оценки».
5. Документ плана управления рисками должен быть управляемым и контролируемым.
6. Риски отслеживаются, переоцениваются и перепланируются на определенных этапах проекта, в определенных точках контроля рисков и при планировании значительных изменений, влияющих на проект разработки ПО.
При проведении этих переоценок проверяются и пересматриваются приоритеты рисков и планы по управлению рисками.
Информация, полученная при отслеживании рисков, используется для уточнения оценок рисков и планов по управлению рисками.
7. Группа разработки ПО, а также другие задействованные группы и отдельные лица должны получать информацию о рисках разработки, планах по управлению рисками и результатах действий по снижению рисков.
Примеры групп и отдельных лиц, задействованных в проекте:
заказчик,
субподрядчики,
конечные пользователи,
группа оценки объема составляющих проекта,
системного проектирования,
системного тестирования,
обеспечения качества ПО,
управления конфигурацией ПО,
управления договорами,
управления документацией.
Операция 11 Периодически выполняются проверки проекта в целях определения действий, требуемых для приведения в соответствие хода и результатов разработки с текущими и планируемыми потребностями бизнеса, заказчика и конечных пользователей.
Примеры действий:
ужесточение календарного графика,
изменение системных требований в ответ на изменения рыночной ситуации или потребностей заказчика и конечных пользователей,
прекращение проекта.
В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.
Измерения и анализ
Измерение 1. Выполнение измерений и использование их результатов для определения эффективности работ по интегрированному управлению разработкой ПО.
Примеры измерений:
объем выполненных на текущий момент работ по управлению проектом в сравнении с запланированным;