Оценка риска проектов программного обеспечения
1.Введение
Существует множествоопределений риска как наличие неопределенности, связанной с наступлениемнежелательного события, и ущерба, понесенного вследствие наступления этогособытия.
Риск (по определению SEI (Software EngineeringInstitute)) — это возможность понести потери.
Рискпроекта ПО — это возможность:
1) снижения качестваконечного продукта,
2) повышения стоимости егоразработки,
3) задержки окончанияразработки или срыва проекта (то есть, отказа от проекта).
Величинарискапредставляет собой R = V * P произведение величины потерь V отнежелательного события в проекте и вероятности P наступления этогособытия.
Величинапотерь V рассматривается в контексте влияния нежелательного события нахарактеристики ПО, на сложность его последующего сопровождения, а такжеэффективность, стоимость и продолжительность процесса разработки ПО, авероятность P — как степень определенности, с которой можнопрогнозировать проявление риска в проекте, то есть перерастание данного риска впроблему для проекта.
Эффективноеуправление риском состоит в принятии (по каждому риску) компромиссных решенийпо:
· учетурисков и анализу старых проектов;
· оценкетрудоемкости устранения определенного риска,
· величинепотенциального отрицательного воздействия этого риска на проект,
· вправильной оценке взаимозависимости устраняемых рисков и возможного влиянияпринятых в определенный (текущий) момент времени решений на состояние проекта вбудущем;
· резервированиив проекте времени на борьбу с рисками.
С ростомразмера и сложности проектов ПО наметилась тенденция к переходу отэвристических методов управления риском, применяемых отдельными лицами,принимающими решение (ЛПР), исходя из собственных знаний и опыта управленияразработкой ПО, к использованию систематизированных, гибких и легкоадаптируемых методов управления риском, обеспечивающих ЛПР всей необходимойинформацией для своевременной идентификации и устранения риска проекта.
2.Концепция управления риском проекта ПО
Базовымиконструкциями концепции управления риском являются:
· функцииуправления риском,
· таксономия(классификация) риска;
· методологияоценки и управления риском.
Представлениеконцепции в виде круга подчеркивает ее суть, заключающуюся в непрерывностипроцесса управления риском. Ориентация стрелок указывает направлениелогического потока информации, связывающего отдельные виды деятельности.Центральной частью концепции является коммуникация, в эффективности средств иметодов осуществления которой залог успешного выполнения всех остальных видовдеятельности и управления риском в целом.
/>
Рис. 1.Концепция управления риском
2.1 Функцииуправления риском
Таблица 1Характеристика функций управления рискомФункция Определение функция Цель функция Идентификация Процесс, в ходе которого неопределенности и проблемы проекта трансформируются в реальные риски, которые можно описать и измерить Искать и найти риски проекта ПО до того, как они перерастут в проблемы Анализ Процесс, в ходе которого устанавливаются детали рисков — величины и источники рисков, их взаимосвязи и степени важности, серьезность последствий, вероятность и время возможного проявления Преобразовать данные о рисках в информацию для принятия адекватных решений Планирование Процесс, в ходе которого принимаются решения о мерах по устранению рисков Выработать решения и план действий по каждому риску. Интегрировать эти решения и планы в единый план управления риском проекта ПО. Учет и контроль Процесс, в ходе которого собираются, обобщаются и фиксируются данные о состоянии рисков и действий по их устранению Контролировать соблюдение графика действий по риску и эффективность самого плана действий Регулирование Процесс, в ходе которого анализируются отчетные данные и принимаются решения о дальнейших действиях по риску Своевременная и эффективная коррекция отклонений в запланированных действиях по риску Коммуникация
Организация взаимодействия по управлению риском стимулирует выполнение остальных функций и гарантирует, что:
· риски и планы их устранения интерпретируются однозначно,
· информация о риске является доступной для всех членов проекта;
· любой информации о риске уделяется надлежащее внимание;
· существует эффективный диалог между менеджером и командой проекта Обеспечение непрерывной эффективной передачи информации и обратной связи со всеми функциями и на всех уровнях управления риском (включая устраняемые, неустраняемые (находящиеся под наблюдением) и вновь появляющиеся риски). Учет как внутренних, так и внешних для проекта источников информации о риске.
2.2Таксономия риска
Таксономиярискаобеспечивает базис для организации данных и изучения различных аспектов рискапроекта ПО.
Таксономияриска разрабатывалась SEI в течение трех лет и была проверена на более чем 30проектах ПО. Она составлена с учетом типовых процессов жизненного цикла (ЖЦ) ПОи охватывает наиболее общие области риска проекта, касающиеся характеристик ПО,среды и процессов разработки и ограничений проекта. Эта таксономия можетчастично видоизменяться с учетом специфики конкретного проекта.
Таксономияриска SEI имеет иерархическую структуру и систематизирует источники (области)риска по трем уровням:
· класс,
· элементкласса,
· атрибутэлемента
Классопределяет сферу деятельности по программной инженерии, с которой может бытьсвязан тот или иной риск. Элемент класса указывает конкретную область риска всоответствующей сфере деятельности. Атрибут элемента определяет фактор риска вопределенной области риска, с которым может быть связано нежелательное событие,действие или факт, являющиеся источником риска.
Таблица 2Класс источника (области) риска Характеристика класса Элемент класса Атрибут элемента 1. Технические аспекты разработки (инженерия программного продукта) Связан с процессами (работами) на стадиях ЖЦ ПО (разработка требований, проектирование, кодирование, тестирование и др.), а также характеристиками ПО (требований, проекта, кода и др.) на этих стадиях Требования Стабильность Полнота Однозначность Достоверность Реализуемость Новизна Масштабность Проект Функциональность Сложность Интерфейсы Производительность Тестируемость Аппаратные ограничения Приобретаемое ПО Кодирование и автономное тестирование Реализуемость Автономное тестирование Кодирование/реализация Интеграция и интеграционное тестирование Среда Интеграция продукта Интеграция системы Нефункциональные характеристики ПО Удобство сопровождения Надежность Защищенность Безопасность Человеческие факторы Спецификации 2. Среда и технология разработки Связан с методами, процедурами и инструментами, используемыми в ходе разработки ПО Процесс разработки Формализованность Укомплектованность Контролируемость процесса Опыт применения Контролируемость продукта
Система поддержкиразработки Мощность Укомплектованность Удобство применения Опыт применения Надежность Сопровождаемость Поставка Процесс управления Планирование Организация проекта Опыт управления Организация взаимодействия Методы управления Мониторинг Управление персоналом Обеспечение качества Управление конфигурацией Рабочая обстановка Качество работы Кооперация Коммуникация Моральный климат 3. Внешние ограничения проекта Связан с внешними для проекта факторами: наличие ресурсов разработки, условия заключаемых договоров, формы и особенности взаимодействия организаций-участников проекта ПО и др Ресурсы Сроки разработки Штат проекта Финансирование Средства разработки Условия договора Тип договора Ограничения договора Договорные зависимости Интерфейсы проекта Заказчик Смежники Соисполнители Головной исполнитель Высшее руководство Продавцы Политические принципы
Таксономияриска обеспечивает систематизацию рисков по указанным в ней аспектампрограммной инженерии и служит основой для разработки методов идентификацииисточников риска путем интервьюирования членов проекта с использованиемопросника, согласующегося с этой таксономией.
Опросник,основанный на таксономии риска (для краткости, TBQ, от Taxonomy-BasedQuestionnaire), является инструментом, применение которого гарантирует охватвсех потенциальных областей риска благодаря наличию в нем вопросов, касающихсянижнего уровня таксономии риска — атрибутов. Количество и форма задаваемыхвопросов может быть различной в зависимости от специфики проекта, выбранногометода интервьюирования и обработки его результатов. В любом случае она должнаориентироваться на максимально полное и эффективное извлечение знаний членовпроекта (включая менеджеров, проектировщиков, технический персонал и др.) орисках конкретного проекта ПО.
Таблица 3 — Список 10 главных программных рисков Программные риски Техника управления рисками 1. Провалы персонала, плохой менеджмент Поиск талантов; рабочее соревнование; построение команды; персональные договора; перекрестные тренировки; предопределение ключевых фигур. 2. Нереальные сроки и бюджеты, ошибки в планировании работ над проектом Детализированный анализ стоимости и ожидаемых сроков; оценка стоимости; пошаговая разработка; повторное использование ПО; смягчение требований. 3. Разработка неправильных программных функций, ошибки проектирования системы Организационный анализ; анализ задачи; формулирование условий; пользовательские обзоры; прототипирование; ранние пользовательские руководства. 4. Разработка ошибочного интерфейса пользователя, плохая связь с заказчиком Прототипирование; сценарии; анализ задач; классификация пользователей (функциональная, стилевая, по загрузке). 5. Потеря прибыльности, неумение заключать договора, некачественное внедрение Снижение требований; прототипирование; стоимостный анализ; оценка стоимости. 6. Неверно сформулированные требования или изменяющиеся требования Высокий порог изменений; инкапсуляция информации; пошаговая разработка (откладывает изменения на дальнейшие шаги разработки). 7. Провалы во внешнем снабжении компонентами, неверный выбор коммерческого ПО Тестирования; проверки; справочные проверки; анализ совместимости. 8. Провалы во внешне исполняемых задачах, недостаточное тестирование и плохая интеграция ПО Справочные проверки; аудит; премиальные контракты; конкурентная разработка или прототипирование; построение команды. 9. Провалы производительности Имитационное моделирование; тестирование; прототипирование; подгонка инструментария. 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Принцип управления риском Характеристика принципа управления риском 1. Разностороннее (в разных проекциях) видение предмета Формирование взгляда на предмет с разных позиций при сохранении общности целей, коллективной ответственности и распределении обязанностей; концентрация внимания на результатах 2. Коллективная работа Совместная работа для достижения общей цели; оптимальные условия проявления таланта, знаний и опыта 3. Глобальные перспективы Восприятие разработки ПО в контексте крупномасштабных работ по проекту системы; допущение как благоприятных, так и неблагоприяных перспектив реализации спецификаций продукта ПО (связанных с превышением сроков, стоимости, программными сбоями и др.) 4. Дальновидность Опережение событий, идентификация неопределенностей, предупреждение потенциальных проблем; управление проектными ресурсами и действиями в режиме предвосхищения проблем; 5. Открытое взаимодействие Поощрение свободного тока информации между всеми уровнями проекта; обеспечение возможности формального, неформального и импровизированного взаимодействия; обеспечение процесса достижения консенсуса с учетом мнений отдельных лиц (имеющих специальные знания и углубленный взгляд на проблему идентификации и управления конкретным риском) 6. Интегрированное управление Признание управления риском в качестве интегральной и жизненно важной части управления проектом; адаптация методов и инструментов управления риском к инфраструктуре и культуре проекта; 7. Непрерывность процесса Постоянство бдительности; непрерывное идентифицирование и управление рисками на всех стадиях ЖЦ проекта
2.3.3Коллективное управление риском
Этаметодология определяет дополнительные действия в деятельности по управлениюриском, которые связаны с осуществлением совместного управления риском состороны заказчика проекта ПО и его исполнителя. Ее применение обеспечиваетформирование среды, содержащей множество процессов, методов и инструментов,необходимых для совместной работы заказчика и исполнителя над непрерывнымуправлением риском в ходе ЖЦ проекта.
Методологияоснована на семи принципах управление риском (п. 2.3.2.) и философии бригаднойработы, к которым добавляет две функции — инициирование коллективной работы исобственно коллективное управление риском. Эти функции выполняются над каждымриском последовательно, но действия по управлению риском проекта в целом могутбыть как последовательными, так и параллельными, и итеративными (например,планирование для одного риска может совмещаться с идентификацией другого).
Инициироватьколлективную работу может либо заказчик, либо исполнитель. При этом обаколлектива должны осознавать необходимость соблюдения принципов коллективнойработы и ответственность за ее результаты. Коллективное управление предполагаетформализацию отношений заказчик-исполнитель и формирование обобщенных взглядовна риски ПО. Систематическое и периодическое совместное применение методовуправления риском обеспечивает единообразие в понимании рисков проекта и ихотносительной важности и получение обобщенной информации о рисках, приоритетах,метриках и планах действий.
Основныеположения трех методологий, представленных выше, послужили базисом дляформирования подхода к управлению риском проектов ПО в терминах процессауправления риском, его оргструктуры и стадий выполнения, а также необходимойинструментальной поддержки модели принятия решений при оценивании риска.
Один извозможных примеров использования процесса управления риском представлен на рис.3.
/>
Рис. 3.Пример применения процесса управления риском
3.Организационная структура управления риском
Процессуправления риском проекта ПО начинается с создания координационной группы(совета) по управлению риском проекта. Численность группы может колебаться отодного человека с частичной занятостью до нескольких человек с полнойзанятостью. Кандидатами в координационную группу могут быть члены бригадыпроекта, представители пользователей, исполнителей и соисполнителей. Лидеромэтой группы является представитель нанимаемой независимой группы экспертов,который несет ответственность за выполнение обеспечивающих функций планированияи координации в рамках метода SRE. Интерфейс организации-разработчика снезависимой группой (в лице ее лидера) осуществляется координатором действий изорганизации-разработчика. Он несет ответственность за подбор (в среде проекта)специалистов для интервьюирования и проведение брифингов при посещении организации-разработчиканезависимой группой экспертов.
Собственнодеятельность по управлению риском проекта ПО должна осуществлятьсяквалифицированным персоналом, включенным в состав проекта (бригадой проекта), араспределение ролей и ответственности за управление риском — отражаться в планеуправления риском. Один из возможных способов распределения ответственности приуправлении риском представлен на рис. 4.
В данномпримере каждый член бригады несет ответственность за непрерывный процессидентификации, оценивания и классификации рисков и формирование плановустранения рисков. Утверждают эти планы технические лидеры бригады проекта.Ответственность за отслеживание состояния рисков проекта может быть возложена ина отдельное лицо или группу лиц в проекте.
Менеджерпроекта производит ревизию и интеграцию информации о рисках, назначениеответственных за риски и планы устранения, а также обеспечивает взаимодействияс внешним окружением проекта.
Бригадапроекта периодически предоставляет отчеты о своей деятельности руководствуорганизации-заказчика. Эти результаты касаются состояния группы рисковнаибольшей важности (например, первой десятки или, в общем случае, первой Н-кирисков) и планов по их устранению. Кроме того, предоставляется информация обэффективности процесса управления риском (например, данные об интенсивностиидентификации новых рисков по отношению к интенсивности устранения рисков идр.). Детальная ревизия этой информации производится менеджером проекта напериодической и событийной основе.
/>
Рис. 4.Распределение ролей при управлении риском
Лица,осуществляющие функции управление риском проекта ПО, должны обладать знаниями вобласти программной инженерии, проблемной области, для которой разрабатываетсяПО, а также знать принципы управления риском и владеть методами и инструментамиуправления риском. Считается, что человек обладает необходимыми знаниями дляуправления риском, если:
· онпринимал участие в управлении по крайней мере одним проектом,
· применялметодологии управления риском по крайней мере для одного проекта и
· имеетопыт в соответствующей проблемной области проекта.
Если не выполняется хотябы одно из перечисленных условий, член проекта должен иметь возможностьпополнить свои знания путем обучения. Способы приобретения необходимых знанийтаковы:
· формальноеобучение. Занятия с членами проекта проводятся организацией-заказчиком илинезависимой организацией по соответствующей программе;
· неформальноеобучение. Этот вид обучения предполагает самостоятельное посещение курсов илиобучение по месту работы по соответствующей программе.
4.Разработка плана управления риском
Управлениериском конкретного проекта ПО осуществляется в соответствии с планом управленияриском, составленным с учетом рекомендаций, полученных от независимой группыэкспертов и зафиксированных в итоговом отчете о проведении оценки риска проектаПО.
Плануправления риском проекта ПО определяет, каким образом процесс управленияриском будет выполняться в рамках конкретного проекта разработки ПО, иуказывает процессы, действия, этапы работ, методы и инструменты, используемыечленами бригады проекта, ответственными за управление риском проекта ПО. Этотплан может быть частью плана управления риском системного уровня, частью планауправления проектом или самостоятельным планом. Выбор того или иного способапланирования зависит от объема и сложности проекта, состава и размеров бригадыпроекта, а также общих принципов планирования, которым следует организация,осуществляющая управление риском. План управления риском может подвергатьсямодификации при появлении новых инструментов, методов или других элементовуправления риском, необходимых для управления риском конкретного проекта.
Текущийсписок рисков и планы по их устранению не рекомендуется включать в плануправления риском проекта ПО, чтобы не пришлось непрерывно его корректировать.
/>
Рис. 5.Блок-схема принятия решения при планировании устранения риска
Таблица 4Рекомендации по содержанию плана управления рискомРаздел плана управления риском Описание Введение Определяет цели и сферу действий плана, его содержание. Здесь должны быть указаны любые предположения, ограничения и принципы реализации процессов, а также любые связанные с этим планы, документы и стандарты. Обзор процессов Краткое описание действий по управлению риском и их взаимосвязь. Определяются все потоки управления и данных, указывается, каким образом действия по управлению риском интегрируются с другими действиями по управлению проектом. Организация Включает информацию об организации работ по управлению риском проекта и распределении ответственности (обязанностей) в проекте между заказчиком, поставщиком ПО (головным исполнителем) и соисполнителями. Указывается оргструктура управления риском, которая проецирует действия по управлению риском на роли, исполняемые членами проекта по управлению риском. Определяется перечень лиц, ответственных за управление риском со стороны организации-заказчика, организации-разработчика и организаций-соисполнителей, а также перечень выполняемых ими действий (процедур) и описание конкретных ожидаемых результатов этих действий. Детали процесса
В этом разделе подробно описываются процессы и процедуры, необходимые для систематического управления риском. Эта часть плана также включает:
1) методы и инструменты, которые выбираются для поддержки каждой функции, а также критерии их выбора;
2) ссылки на другие планы, руководства и учебные материалы по любому методу или инструменту, который документирован в другом месте (например, в соответствующих документах проекта, документах уровня организации или документах заказчика);
3) все показатели (метрики) улучшения процесса, которые должны собираться и фиксироваться в отчетах (например, число открытых рисков, число рисков по классам, тренд (изменения) величины риска от момента его идентификации до закрытия, число успешных устранений, число неуспешных устранений и др.);
4) процесс, обеспечивающий оценивание и улучшение основного процесса управления риском (например, ежеквартальное оценивание эффективности применяемых методов, периодическая ревизия отчетов заказчика с целью определения их полезности и др.). Ресурсы и графики Этот раздел документирует ресурсы (например, стоимость, трудоемкость, оборудование и расходные материалы, используемое ПО), необходимые для поддержки процесса управления риском. Специфицируется утвержденный бюджет, а также источники финансирования устранения риска. В этот раздел плана включается проекция действий по управлению риском на план-график и этапы разработки проекта ПО, а также перечень всех выпускаемые рабочих продуктов, касающиеся управления риском, включая итоговые отчеты по риску, планы устранения и др. Документирование риска В этом разделе должна быть специфицирована инструментальная поддержка управления риском, указаны структуры баз данных о рисках, методы, средства и процедуры ведения баз данных, перечень входных и отчетных форм и др. Здесь также должны быть определены все процедуры и требования по составлению, обработке, контролю и ведению (хранению) относящихся к риску документов и форм.
5. Рекомендации по оценкериска проектов ПО
Анализметодологий оценки риска, предлагаемых такими зарубежными организациями, какNASA Lewis Research Center, Defense Systems Management College, DSDC (DefenseLogistics Agency Systems Design Center), BMPC (Best Manufacturing PracticesCenter), 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. Вычислениекомбинированного риска по всем элементам.
Аналогичнымобразом может быть установлен комбинированный риск проекта в целом путемопределения соотношения рисков всех атрибутов таксономии.