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), является инструментом, применение которого гарантирует охват всех потенциальных областей риска благодаря наличию в нем вопросов, касающихся нижнего уровня таксономии риска - атрибутов. Количество и форма задаваемых вопросов может быть различной в зависимости от специфики проекта, выбранного метода интервьюирования и обработки его результатов. В любом случае она должна ориентироваться на максимально полное и эффективное извлечение знаний членов проекта (включая менеджеров, проектировщиков, технический персонал и др.) о рисках конкретного проекта ПО.