Оценка риска проектов программного обеспечения

Оценка риска проектов программного обеспечения

1. Введение

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

Риск (по определению SEI (Software Engineering Institute)) - это возможность понести потери.

Риск проекта ПО - это возможность:

1) снижения качества конечного продукта,

2) повышения стоимости его разработки,

3) задержки окончания разработки или срыва проекта (то есть, отказа от проекта).

Величина риска представляет собой R = V * P произведение величины потерь V от нежелательного события в проекте и вероятности P наступления этого события.

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

Эффективное управление риском состоит в принятии (по каждому риску) компромиссных решений по:

· учету рисков и анализу старых проектов;

· оценке трудоемкости устранения определенного риска,

· величине потенциального отрицательного воздействия этого риска на проект,

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

· резервировании в проекте времени на борьбу с рисками.

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

2. Концепция управления риском проекта ПО

Базовыми конструкциями концепции управления риском являются:

· функции управления риском,

· таксономия (классификация) риска;

· методология оценки и управления риском.

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

Рис. 1. Концепция управления риском

2.1 Функции управления риском

Таблица 1 Характеристика функций управления риском

2.2 Таксономия риска

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

Таксономия риска разрабатывалась SEI в течение трех лет и была проверена на более чем 30 проектах ПО. Она составлена с учетом типовых процессов жизненного цикла (ЖЦ) ПО и охватывает наиболее общие области риска проекта, касающиеся характеристик ПО, среды и процессов разработки и ограничений проекта. Эта таксономия может частично видоизменяться с учетом специфики конкретного проекта.

Таксономия риска SEI имеет иерархическую структуру и систематизирует источники (области) риска по трем уровням:

· класс,

· элемент класса,

· атрибут элемента

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

Таблица 2

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

Опросник, основанный на таксономии риска (для краткости, TBQ, от Taxonomy-Based Questionnaire), является инструментом, применение которого гарантирует охват всех потенциальных областей риска благодаря наличию в нем вопросов, касающихся нижнего уровня таксономии риска - атрибутов. Количество и форма задаваемых вопросов может быть различной в зависимости от специфики проекта, выбранного метода интервьюирования и обработки его результатов. В любом случае она должна ориентироваться на максимально полное и эффективное извлечение знаний членов проекта (включая менеджеров, проектировщиков, технический персонал и др.) о рисках конкретного проекта ПО.

Таблица 3 - Список 10 главных программных рисков

2.3 Методология оценки и управления риском

Исследования риска - это длительный (несколько месяцев) процесс, в ходе которого предпринимаются совместные усилия ведущей организацией по вопросам управления риском (в рамках страны, определенной отрасли или государственной структуры) и организацией-клиентом:

· по изучению существующей практики разработки конкретного проекта,

· оценке альтернативных приемов управления риском,

· выработке концепции управления риском клиента,

· обучению методам управления риском

· созданию необходимой инфраструктуры и плана управления риском ПО в организации-клиенте.

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

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

· согласование целей - определение нужд и целей проекта, достижение соглашений по управлению риском,

· подготовка работ - планирование и координация предстоящих работ по оцениванию риска проекта ПО,

· оценка риска - выполнение функций управления риском и получение рекомендаций по управлению риском проекта ПО,

· подготовка к устранению риска - разработка рекомендаций по устранению рисков по всем областям устранения риска, разработка плана управления риском и приведение его в действие.

Процесс управления риском применяется независимо от стадии ЖЦ, на которой находится проект ПО, и независимо от конкретного сценария и форм организации взаимодействия заказчика, исполнителя, соисполнителей и др. при разработке проекта.

Разработано 3 методологии:

· оценивание риска ПО - SRE (от Software Risk Evaluation),

· непрерывное управление риском - CRM (от Continuous Risk Мanagement),

· коллективное управление риском - TRM (от Team Risk Management).

2.3.1 Оценивание риска ПО

Методология SRE предлагает формальный метод идентификации, анализа, контроля и устранения риска ПО, который применяется первоначально на самой ранней стадии разработки проекта ПО (еще до заключения договора с разработчиком) и затем периодически в ходе всего ЖЦ проекта. Предлагаемые SRE функции управления риском подразделяются на основные и обеспечивающие.

К основным функциям управления риском относятся:

· обнаружение,

· спецификация,

· оценивание,

· структурирование (консолидация)

· устранение рисков.

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

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

Существует много способов спецификации риска - от простого утверждения о риске до сложного высказывания с применением условных выражений вида “ЕСЛИ <условие> ТО <последствия>”, связок “И” и др. Выбор того или иного способа определяется эффективностью его практического применения для проекта и особенностями инструментальной поддержки обработки рисков.

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

Существуют различные механизмы оценивания величины риска - от простых субъективных оценок по 3-бальной шкале до строгих статистических измерений. Примеры простых механизмов оценивания величины риска представлены на рис. 2.

Рис. 2. Матрица трехуровневой оценки риска

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

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

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

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

2.3.2 Непрерывное управление риском

Эта методология основана на определенных принципах управления риском в ходе всего ЖЦ проекта и не зависит от конкретных применяемых методов и инструментов оценки и устранения риска. Семь принципов управления риском таковы:

Таблица 3

2.3.3 Коллективное управление риском

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

Методология основана на семи принципах управление риском (п. 2.3.2.) и философии бригадной работы, к которым добавляет две функции - инициирование коллективной работы и собственно коллективное управление риском. Эти функции выполняются над каждым риском последовательно, но действия по управлению риском проекта в целом могут быть как последовательными, так и параллельными, и итеративными (например, планирование для одного риска может совмещаться с идентификацией другого).

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

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

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

Рис. 3. Пример применения процесса управления риском

3. Организационная структура управления риском

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

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

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

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

Бригада проекта периодически предоставляет отчеты о своей деятельности руководству организации-заказчика. Эти результаты касаются состояния группы рисков наибольшей важности (например, первой десятки или, в общем случае, первой Н-ки рисков) и планов по их устранению. Кроме того, предоставляется информация об эффективности процесса управления риском (например, данные об интенсивности идентификации новых рисков по отношению к интенсивности устранения рисков и др.). Детальная ревизия этой информации производится менеджером проекта на периодической и событийной основе.

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

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

· он принимал участие в управлении по крайней мере одним проектом,

· применял методологии управления риском по крайней мере для одного проекта и

· имеет опыт в соответствующей проблемной области проекта.

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

· формальное обучение. Занятия с членами проекта проводятся организацией-заказчиком или независимой организацией по соответствующей программе;

· неформальное обучение. Этот вид обучения предполагает самостоятельное посещение курсов или обучение по месту работы по соответствующей программе.

4. Разработка плана управления риском

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

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

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

Рис. 5. Блок-схема принятия решения при планировании устранения риска

Таблица 4 Рекомендации по содержанию плана управления риском

5. Рекомендации по оценке риска проектов ПО

Анализ методологий оценки риска, предлагаемых такими зарубежными организациями, как NASA Lewis Research Center, Defense Systems Management College, DSDC (Defense Logistics Agency Systems Design Center), BMPC (Best Manufacturing Practices Center), SEI и др. показал, что все они схожи в подходах к оцениванию риска, расходятся в принципах ранжирования рисков и в целом основываются на предложенной SEI таксономии риска, модифицируя перечень вопросов TBQ и меняя их форму.

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

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

Вопросы для проведения интервьюирования сформулированы в такой форме, чтобы на каждый из них можно было дать однозначный ответ: “Да”, “Нет”, “Частично”, “Не знаю”, или “Не применим”.

Ответ “Да” свидетельствует об отсутствии риска, суть которого сформулирована в вопросе.

Ответ “Нет” или “Не знаю” свидетельствует о наличии риска.

Ответ “Частично” также свидетельствует о наличии риска, но дает возможность эксперту, оценивающему риск, указать вес вопроса, отличный от предлагаемого максимального веса.

Ответ “Не применим” соответствует неправомерности задания вопроса для данного проекта и не учитывается при оценке риска.

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

Метод оценки риска BMPC включает следующие шаги:

1. Вычисление ранга риска R по одному атрибуту. Ранг риска атрибута R вычисляется исходя из количества вопросов, на которые был дан ответ “Да” или “Частично”. Определяется сумма весов этих ответов. Затем вычисляется общая сумма весов всех вопросов для атрибута (вес атрибута), за исключением вопросов с ответами “Не применим”. После этого находится процентное соотношение этих сумм по следующей формуле

R = (å_i=1,k Vдi / (å_j=1,n Vi - å_j=1,t Vнi))*100,

где Vдi – вес вопроса с ответом “Да” или “Частично”, к – количество таких ответов,

Vi – вес каждого вопроса, n – общее количество вопросов в атрибуте;

Vнi – вес вопроса с ответом “Не применим”, t – количество таких ответов.

2. Вычисление уровня риска атрибута U.

Если ранг риска R = 100%-70%, то уровень риска U – низкий.

Если ранг риска R = 69%-30%, то уровень риска U – средний.

Если ранг риска R = 29%-0%, то уровень риска U – высокий.

3. Вычисление ранга и уровня риска каждого атрибута.

Вычисление комбинированного риска элемента таксономии путем определения соотношения рисков атрибутов этого элемента и составление шкалы (или столбчатой диаграммы).

Например, элемент “Требования” состоит из 7 атрибутов (приложение.1). Если по пяти атрибутам был получен высокий риск, а по 2 – средний, то соотношение рисков на шкале будет 2/7 для среднего и 5/7 для высокого риска.

4. Вычисление комбинированного риска по всем элементам.

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