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






