•Место и роль категорий неопределенность» и «риск»

•в современной структуре научных знаний

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

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

раньше;

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

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

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

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

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

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

•Место и роль категорий неопределенность» и «риск»

•в современной структуре научных знаний

ESI – Educational Services Institute

http://www.esi-intl.com

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

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

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

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

Риск в программной разработке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.01.01Недостаточный анализ задач приводит к проблемам в интерфейсе пользователя

1.03.04.02Тесты для требуемых открытых системных стандартов недоступны

2.01.03.03Реализация новой версии 2.5 операционной системы

2.04.05Недостаточное время для исполнения теста по системной интеграции

3.02.17.03Использование новой методики разработки замедлит график работ

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

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

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

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

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

Пример повествовательного описания рисков:

Решаемо при изменении в графике или критериях производительности За пределами текущих практик Вероятная неудача Главная проблема

План тестирования еще не обдуман Соответствует текущему уровню Некоторый успех, но с неопределенностями

Решаемо без изменений в графике или критериях производительности План тестирования обдуман, но тестирование еще не завершено Решаемо

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

Решаемо без существенных изменений в графике или критериях производительности

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

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

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

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

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

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