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
| Класс источника (области) риска | Характеристика класса | Элемент класса | Атрибут элемента |
| 1. Технические аспекты разработки (инженерия программного продукта) | Связан с процессами (работами) на стадиях ЖЦ ПО (разработка требований, проектирование, кодирование, тестирование и др.), а также характеристиками ПО (требований, проекта, кода и др.) на этих стадиях | Требования | Стабильность |
| Полнота | |||
| Однозначность | |||
| Достоверность | |||
| Реализуемость | |||
| Новизна | |||
| Масштабность | |||
| Проект | Функциональность | ||
| Сложность | |||
| Интерфейсы | |||
| Производительность | |||
| Тестируемость | |||
| Аппаратные ограничения | |||
| Приобретаемое ПО | |||
| Кодирование и автономное тестирование | Реализуемость | ||
| Автономное тестирование | |||
| Кодирование/реализация | |||
| Интеграция и интеграционное тестирование | Среда | ||
| Интеграция продукта | |||
| Интеграция системы | |||
| Нефункциональные характеристики ПО | Удобство сопровождения | ||
| Надежность | |||
| Защищенность | |||
| Безопасность | |||
| Человеческие факторы | |||
| Спецификации | |||
| 2. Среда и технология разработки | Связан с методами, процедурами и инструментами, используемыми в ходе разработки ПО | Процесс разработки | Формализованность |
| Укомплектованность | |||
| Контролируемость процесса | |||
| Опыт применения | |||
| Контролируемость продукта | |||
| Система поддержкиразработки | Мощность | ||
| Укомплектованность | |||
| Удобство применения | |||
| Опыт применения | |||
| Надежность | |||
| Сопровождаемость | |||
| Поставка | |||
| Процесс управления | Планирование | ||
| Организация проекта | |||
| Опыт управления | |||
| Организация взаимодействия | |||
| Методы управления | Мониторинг | ||
| Управление персоналом | |||
| Обеспечение качества | |||
| Управление конфигурацией | |||
| Рабочая обстановка | Качество работы | ||
| Кооперация | |||
| Коммуникация | |||
| Моральный климат | |||
| 3. Внешние ограничения проекта | Связан с внешними для проекта факторами: наличие ресурсов разработки, условия заключаемых договоров, формы и особенности взаимодействия организаций-участников проекта ПО и др | Ресурсы | Сроки разработки |
| Штат проекта | |||
| Финансирование | |||
| Средства разработки | |||
| Условия договора | Тип договора | ||
| Ограничения договора | |||
| Договорные зависимости | |||
| Интерфейсы проекта | Заказчик | ||
| Смежники | |||
| Соисполнители | |||
| Головной исполнитель | |||
| Высшее руководство | |||
| Продавцы | |||
| Политические принципы |
Таксономия риска обеспечивает систематизацию рисков по указанным в ней аспектам программной инженерии и служит основой для разработки методов идентификации источников риска путем интервьюирования членов проекта с использованием опросника, согласующегося с этой таксономией.
Опросник, основанный на таксономии риска (для краткости, TBQ, от Taxonomy-Based Questionnaire), является инструментом, применение которого гарантирует охват всех потенциальных областей риска благодаря наличию в нем вопросов, касающихся нижнего уровня таксономии риска - атрибутов. Количество и форма задаваемых вопросов может быть различной в зависимости от специфики проекта, выбранного метода интервьюирования и обработки его результатов. В любом случае она должна ориентироваться на максимально полное и эффективное извлечение знаний членов проекта (включая менеджеров, проектировщиков, технический персонал и др.) о рисках конкретного проекта ПО.