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