Контрольная работа: Оценка риска проектов программного обеспечения
· существует эффективный диалог между менеджером и командой проекта
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. Превышение возможностей компьютерной науки | Технический анализ; анализ прибыльности; прототипирование; справочные проверки. |
2.3 Методология оценки и управления риском
Исследования риска - это длительный (несколько месяцев) процесс, в ходе которого предпринимаются совместные усилия ведущей организацией по вопросам управления риском (в рамках страны, определенной отрасли или государственной структуры) и организацией-клиентом:
· по изучению существующей практики разработки конкретного проекта,
· оценке альтернативных приемов управления риском,
· выработке концепции управления риском клиента,
· обучению методам управления риском
· созданию необходимой инфраструктуры и плана управления риском ПО в организации-клиенте.
Поскольку управление риском, отнесено к уровню 3 модели технологической зрелости организаций-разработчиков, оценка и управление риском - это достаточно отдаленная перспектива для отечественной программной инженерии.
Процесс управления риском проекта ПО включает следующие четыре стадии:
· согласование целей - определение нужд и целей проекта, достижение соглашений по управлению риском,
· подготовка работ - планирование и координация предстоящих работ по оцениванию риска проекта ПО,
· оценка риска - выполнение функций управления риском и получение рекомендаций по управлению риском проекта ПО,
· подготовка к устранению риска - разработка рекомендаций по устранению рисков по всем областям устранения риска, разработка плана управления риском и приведение его в действие.
Процесс управления риском применяется независимо от стадии ЖЦ, на которой находится проект ПО, и независимо от конкретного сценария и форм организации взаимодействия заказчика, исполнителя, соисполнителей и др. при разработке проекта.
Разработано 3 методологии :
· оценивание риска ПО - SRE (от Software Risk Evaluation),