Таксономия риска

Таксономия риска обеспечивает базис для организации данных и изучения различных аспектов риска проекта ПО.

Таксономия риска разрабатывалась SEI в течение трех лет и была проверена на более чем 30 проектах ПО. Она составлена с учетом типовых процессов жизненного цикла (ЖЦ) ПО и охватывает наиболее общие области риска проекта, касающиеся характеристик ПО, среды и процессов разработки и ограничений проекта. Эта таксономия может частично видоизменяться с учетом специфики конкретного проекта.

Таксономия риска SEI имеет иерархическую структуру и систематизирует источники (области) риска по трем уровням:

ü класс,

ü элемент класса,

ü атрибут элемента

Класс определяет сферу деятельности по программной инженерии, с которой может быть связан тот или иной риск. Элемент класса указывает конкретную область риска в соответствующей сфере деятельности. Атрибут элемента определяет фактор риска в определенной области риска, с которым может быть связано нежелательное событие, действие или факт, являющиеся источником риска.

Таблица 2

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

Таксономия риска обеспечивает систематизацию рисков по указанным в ней аспектам программной инженерии и служит основой для разработки методов идентификации источников риска путем интервьюирования членов проекта с использованием опросника, согласующегося с этой таксономией.

Опросник, основанный на таксономии риска (для краткости, TBQ, от Taxonomy-Based Questionnaire), является инструментом, применение которого гарантирует охват всех потенциальных областей риска благодаря наличию в нем вопросов, касающихся нижнего уровня таксономии риска - атрибутов. Количество и форма задаваемых вопросов может быть различной в зависимости от специфики проекта, выбранного метода интервьюирования и обработки его результатов. В любом случае она должна ориентироваться на максимально полное и эффективное извлечение знаний членов проекта (включая менеджеров, проектировщиков, технический персонал и др.) о рисках конкретного проекта ПО.

Таблица 3 - Список 10 главных программных рисков

 
Программные риски Техника управления рисками  
1. Провалы персонала, плохой менеджмент Поиск талантов; рабочее соревнование; построение команды; персональные договора; перекрестные тренировки; предопределение ключевых фигур.  
2. Нереальные сроки и бюджеты, ошибки в планировании работ над проектом Детализированный анализ стоимости и ожидаемых сроков; оценка стоимости; пошаговая разработка; повторное использование ПО; смягчение требований.  
3. Разработка неправильных программных функций, ошибки проектирования системы Организационный анализ; анализ задачи; формулирование условий; пользовательские обзоры; прототипирование; ранние пользовательские руководства.  
4. Разработка ошибочного интерфейса пользователя, плохая связь с заказчиком Прототипирование; сценарии; анализ задач; классификация пользователей (функциональная, стилевая, по загрузке).  
5. Потеря прибыльности, неумение заключать договора, некачественное внедрение Снижение требований; прототипирование; стоимостный анализ; оценка стоимости.  
6. Неверно сформулированные требования или изменяющиеся требования Высокий порог изменений; инкапсуляция информации; пошаговая разработка (откладывает изменения на дальнейшие шаги разработки).  
7. Провалы во внешнем снабжении компонентами, неверный выбор коммерческого ПО Тестирования; проверки; справочные проверки; анализ совместимости.  
8. Провалы во внешне исполняемых задачах, недостаточное тестирование и плохая интеграция ПО Справочные проверки; аудит; премиальные контракты; конкурентная разработка или прототипирование; построение команды.  
9. Провалы производительности Имитационное моделирование; тестирование; прототипирование; подгонка инструментария.  
10. Превышение возможностей компьютерной науки Технический анализ; анализ прибыльности; прототипирование; справочные проверки.  
     

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: