Скачиваний:
45
Добавлен:
29.01.2021
Размер:
5.08 Mб
Скачать
      1. Исполнение ответных стратегий

Исполнить – это немедленно реализовать те ответные стратегии на риски, которые снижают вероятность наступления рискового события, и реализовывать ответные стратегии при наступлении рисковых событий, в соответствии с выработанными планами. Входными данными для этого шага являются данные, поступающие с ходом проекта в соответствии с его планом, и ответные стратегии, выработанные на предыдущем шаге. Необходимые стратегии отрабатываются и по результатам их исполнения вносятся необходимые коррективы в план управления рисками, возможно, влияющие на дальнейший ход проекта. Результатом является возможно пересмотренный план действий от текущего момента до конца проекта.

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

На управление рисками нужно время и адекватные ресурсы, которые должны быть заложены в проектном плане. Руководители программных проектов, как правило, всегда перегружены, поэтому для того, чтобы управление рисками работало действенно и экономно (effectively and efficiently), руководители проектов должны на регулярной основе:

  • оценивать состояние проекта и связанных с ним рисков;

  • отслеживать рисковые события;

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

  • проверять результаты исполнения ответных стратегий;

и осуществлять все это как часть общего процесса управления проектом. Важными вопросами, требующими постоянного внимания руководителя проекта, являются:

  • Определен ли способ отчетности по рискам?

  • Определены ли данные, подлежащие сбору для определения рисков?

  • Определено ли, как использовать эти данные?

  • Как эти данные должны собираться?

  • Кто отвечает за сбор этих данных?

  • Как часто должны эти данные собираться?

  • Какие требуются отчеты?

  • Кому требуются отчеты о состоянии проекта и рисков в нем?

  • До какого уровня WBS должны собираться эти данные?

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

      1. Оценивание результатов исполнение ответных стратегий

Оценивать результаты – это наблюдать за отработкой ответных стратегий на риски чтобы понять, являются ли последствия стратегии теми, какие ожидались, и выявить возможности для уточнения плана управления рискам. Все это необходимо для переноса полезного опыта на другие проекты. Входными данными для этого шага служат проектный план и план управления рисками, данные по затратам и графику, технические проблемы в проекте и любые значимые данные по рисковому событию. Применяемые инструменты – различные методики, например, стандарты IEEE 982.1-1988 и другие. Для каждой рисковой стратегии необходимо определить критерии успеха и анализировать результаты ее исполнения в свете этих критериев. В процессе оценивания результатов исполнения могут измениться ранее сделанные оценки вероятности и воздействия этого и других рисков, а также появиться новые риски, что возвращает процесс к шагу 1. В свете полученных данных могут быть также пересмотрены сами ответные стратегии, что возвращает процесс к шагу 4. Все это вызывает необходимость пересмотра плана управления рисками, который необходимо утвердить и сообщить всем участникам разработки. Таким образом, выходными данными этого шага является пересмотренный план управления рисками.

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

Методики, ориентированные на продукт, используют метрики продукта, нацеленные на причинно-следственный анализ его надежности до исполнения в дополнение к надежности во время исполнения. Этими метриками являются:

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

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

  • Рост и проекция надежности: оценка изменений в отсутствии сбоев при тестировании и эксплуатации.

  • Остаточные дефекты в продукте: оценка отсутствия сбоев при разработке, тестировании и сопровождении.

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

  • Сложность: оценка усложняющих факторов в системе.

Например, уже такая простая метрика для отслеживания: TM=R1/R2×100%, где R1 – число требований, которым архитектура удовлетворяет, а R2 – число исходных требований, позволяет выявить требования, либо пропущенные в исходных требованиях, либо дополнительные к ним.

Процессно-ориентированные методики используют процессные метрики, нацеленные на практики и процедуры управления для совершения работ по разработке продукта, такие как:

  • Контроль руководства: оценка управляемости процессов разработки и сопровождения.

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

  • Оценивание рисков, выигрыша и затрат: оценивание процессных «за и против» по цене, графику и производительности.

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

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

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

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

Инспекции (inspections) имеют целью найти ошибки в их источнике – как можно ранее в процессе разработки. Они более формальны и жестки, чем обзоры и просмотры и проводятся подготовленными техническими специалистами. Как правило, инспекции требуют больше времени и ресурсов, но находят больше ошибок, чем тестирование. Более подробно инспекции рассмотрены в разделе 1.28.

Стандарт IEEE Standard Dictionary of Measures to Produce Reliable Software (IEEE Std 982.1-1988) перечисляет 39 методик для наблюдения за рисками, из которых можно выбирать наиболее подходящие для каждого данного случая.

Известный подход Боэма «Первые 10» суммирует все вышесказанное в следующих действиях:

  1. Выявить 10 самых серьезных рисков в проекте.

  2. Разработать план по разрешению каждого риска.

  3. Ежемесячно обновлять список этих рисков, планов и результатов.

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

  5. Запускать соответствующие поправочные действия при необходимости.