18. Модели esi и pmi управления рисками

Разработчики программных проектов тратят ресурсы и время на управление рисками для того, чтобы:

• получить конкурентные преимущества, распознавая возможности раньше;

• сфокусироваться на построении правильного продукта с первого раза;

• предотвратить нежелательные «сюрпризы»;

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

• предотвратить повторение проблем или, если они возникнут, их разрастание.

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

Существует несколько известных моделей управления рисками, из которых рассмотрим две близкие модели: ESI и PMI, обобщенная структура которых представлена на Рис. 30.

Рис. 30. Модели и управления рисками в программном проекте

Модель PMI состоит из 4-х последовательных шагов (отмеченных звездочкой на Рис. 30): выявление рисков, придание рискам числовых характеристик, разработка ответных действий по рискам и управление ответными действиями по рискам, тогда как модель ESI содержит 7 последовательных шагов: выявить, проанализировать, дать приоритеты, спланировать, исполнить, оценить и задокументировать. Кроме того, в обеих моделях предусмотрена общая непрерывная деятельность «коммуницировать», связанная с каждым шагом. Как видим, два более крупных шага модели PMI в модели ESI разделены на более мелкие шаги. Далее модель ESI будет рассмотрена подробнее.

1. Выявление рисков

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

Структура разбиения работ является хорошей основой для выявления рисков, поскольку это группировка элементов проекта, нацеленная на поставки и задающая его область, используется для разбиения проекта на обозримые куски для разумного планирования, отслеживания и управления. Высший уровень структуры разбиения работ отражает основную цель проекта, следующий уровень задает существенные моменты, необходимые для достижения этой цели; третий и последующие уровни задают этапы; элементы, находящиеся в самом низу, определяют трудозатраты на весь проект. Все эти элементы могут быть источниками рисков при внимательном рассмотрении. Эта структура очень полезна при написании контракта, поскольку обеспечивает включение в него всех требований. То же происходит при разработке предложений при ответе на запрос на предложение (Request For Proposals – RFP) или тендер. Если требования этого документа структурированы по формату WBS, то сразу обнаруживаются требования, пропущенные заказчиком, и упрощается проведение оценок по трудозатратам снизу-вверх.

Таксономические вопросники для выявления рисков разработаны в SEI и реализуют групповой подход для выявления и упорядочивания рисков при разработке программного обеспечения. Результатом является приблизительный и незаконченный перечень рисков, который затем используется для выявления областей риска, подлежащих последующему более подробному изучению. По аналогии с классической таксономией живых организмов (классификация Линнея), таксономия SEI предлагает трехуровневую иерархию рисков в программном проекте класс-элемент-атрибут, представленную на Рис. 31:

Рис. 31. Пример таксономии программных рисков

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

[Есть ли обязательные требования по времени отклика или пропускной способности?]

[22] Есть ли проблемы с производительностью по следующим направлениям:

Пропускная способность?

Диспетчеризация асинхронных событий реального времени?

Время отклика в реальном времени?

Временные линии восстановления?

Время отклика?

Ответ от БД, конкуренция, доступ?

[23] Был ли сделан анализ производительности?

(Да) [23.a] Каков уровень доверия результатам анализа?

(Нет) [23.b] Есть ли модель отслеживания производительности при

проектировании и реализации?

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

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

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

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

Номер по WBS	Событие риска	Вероят-ность	Воздей-ствие	Общий риск
1.01.01	Недостаточный анализ задач приводит к проблемам в интерфейсе пользователя
1.03.04.02	Тесты для требуемых открытых системных стандартов недоступны
2.01.03.03	Реализация новой версии 2.5 операционной системы
2.04.05	Недостаточное время для исполнения теста по системной интеграции
3.02.17.03	Использование новой методики разработки замедлит график работ