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

5. Укорененность во времени – восприятие риска меняется со временем:

• риск – это только будущее явление;

• время влияет на восприятие риска;

• риски обратимы.

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

• нулевой риск обычно не рассматривается;

• суждения людей о рисках не совпадают с большей частью методологий по статистическому измерению рисков;

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

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

• многие люди полагают, что они более уверены, чем на самом деле;

• многие обнаруживают неспособность пересмотреть начальные оценки в свете новых данных;

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

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

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

По этим признакам разработчики делятся на три группы: избегающих риски (предпочитающие работать только в области низких рисков); на «золотую середину» (принимающих только низкие и умеренные риски); и на «игроков» (не исключающих и высокие риски).

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

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] Есть ли модель отслеживания производительности при

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

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

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

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

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

2. Анализ рисков

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

Входными данными для этого второго шага являются примерный список рисков, полученный на предыдущем шаге, а также все его входные данные. Специфическими применяемыми инструментами служат ожидаемая ценность в денежном выражении (Expected Monetary Value – EMV), деревья решений, диаграммы Исикавы (Kaoru Ishikawa) «рыбий скелет» (fishbone) и другие. В результате исполнения этого шага уточняются значения переменных, описывающих систему, выявляются различные последствия в случае наступления рисковых событий, оценивается сила каждого риска и уменьшается (но не исключается полностью!) область неожиданностей. Выходом этого шага является уточненный список полностью проанализированных рисков.

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

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

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

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

• средний (желтый цвет) – данное рисковое событие способно вызвать серьезное нарушение графика, рост затрат или снижение производительности; однако при особом внимании к поставщикам и тесном сотрудничестве с заказчиком эти трудности преодолимы;

• низкий (зеленый цвет) – данное рисковое событие малоспособно вызвать серьезное нарушение графика, рост затрат или снижение производительности; обычное внимание к поставщикам и сотрудничество с заказчиком эти трудности вероятнее всего преодолеют.

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

Количественная форма выражает риски, используя числовую дробь для представления вероятности их наступления или, наоборот, ненаступления. Например: «Есть 10%-ая вероятность, что интеграционная фаза тестирования будет задержана на 3 недели». Однако что это значит на самом деле для вполне определенного единичного события? На практике используется соединение качественной и количественной оценок риска, приведенное в Табл. 16.

Табл. 16. Соединение качественной и количественной оценки риска

При анализе риска необходимо оценить величину потерь для проекта и организации в целом в случае его наступления. При этом определяется характер потерь: будут ли потери физические, политические, экономические или комбинация всех этих типов; размер потерь: серьезность (объем) и распределение (что именно покрывают потери); и время потерь (их хронология): будут ли потери немедленными или растянуты во времени.

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

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