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