Материал: DO178 Учебное пособие_в183

5. Исполнение ответных стратегий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзоры (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. Запускать соответствующие поправочные действия при необходимости.

7. Документирование действий по рискам

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

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

Ключ к успеху – удобная для всех участников система документации! При создании таких документов полезно держать в виду следующие два вопроса: «Если меня завтра не станет, то может ли кто-либо разобраться в этом?» и «Можно ли заполнить эту форму или отчет в конце рабочего дня в пятницу?» Если ответом на второй вопрос будет: «Можно, но плохо именно в этот момент», то плохо будет всегда, так что это верный знак того, что надо что-то менять в подходе к составлению таких отчетов и документов.

Практический подход к документированию управления рисками руководствуется следующими принципами:

1. Документирование – это непрерывный процесс

2. У документации различные пользователи: она дает исторический след проекта, дает сводки «усвоенных уроков» и функционирует как механизм коммуникации между прикосновенными лицами.

3. Документация должна быть: текущей, точной и полной, ясной и лаконичной.

4. Руководствуйтесь здравым смыслом при документировании.

5. Распространяйте свою документацию и читайте документацию других.

8. Заключительное оценивание рисков

По завершении программного проекта очень полезно провести заключительное оценивание рисков в нем как часть ретроспективного обзора (post-mortem review) выполненного проекта, как успешного, так и неуспешного.

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

1. Затраты, график, производительность: Каковы «усвоенные уроки»? Удовлетворен ли заказчик? Каковы последствия данного проекта для будущих проектов и будущего организации?

2. Признание и награждение отличившихся участников проекта.

3. Оценивание степени достижения целей проекта.

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

В зависимости от качества таких оцениваний, могут создаваться или сокращаться будущие риски в новых проектах, меняться в ту или иную сторону образ и репутация данной организации-разработчика. Такая работа способствует созданию возможностей на будущее через возможные усовершенствования в контракте, позиционирование данной организации как разработчика и улучшение связи с общественностью (public relations).

Выявленные в результате такого оценивания типы рисков и рисковых событий уточняют сами риски и могут относиться к следующим категориям:

деловые риски – несут вероятность как выигрыша, так и потерь – это нормальные риски ведения дела;

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

внешние события – вне контроля или влияния со стороны разработчиков:

• непредсказуемые – регуляторные, природные катаклизмы, окружающая среда, общественный интерес;

• предсказуемые – колебания рынка, валют, инфляция, налогообложение;

внутренние события – в рамках контроля или влияния разработчиков:

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

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

• технические – экспертиза, зрелость технологии, размер и сложность, требования интеграции/инсталляции, настройка на потребителя, сопровождение;

• юридические – неоднозначность в контракте, невозможность выполнить, право копирования, торговые секреты, патенты, лицензии.

Разумеется, разработчики могут влиять только на риски, находящиеся под их контролем. В Табл. 17 приводится примерный перечень таких рисков и соответствующих инструментов для управления ими.

Табл. 17. Риски, контролируемые разработчиками

К десяти самым серьезным рискам в программном проекте обычно относят следующие:

1. Неточность метрик – значения метрик, служащие основой для анализа и принятия решений, могут оказаться неточными.

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

3. Чрезмерное давление графика – этапы поставок спланированы с превышением нагрузки на исполнителей.

4. Некомпетентность руководства – no comment

5. Неадекватность оценки затрат – затраты на разработку оценены неверно.

6. Синдром «серебряной пули» – мнение, что существует одно решение для всех проблем в проекте.

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

8. Низкое качество – no comment

9. Низкая производительность труда – фактическая производительность труда оказалась меньше расчетной

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