Навигация
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),
· непрерывное управление риском - CRM (от Continuous Risk Мanagement),
· коллективное управление риском - TRM (от Team Risk Management).
Похожие работы
... на 61 страницах машинописного текста, содержит 4 рисунка, 13 таблиц. Во «Введении» обоснована актуальность темы, определены цели и задачи, предмет исследования. В первой главе «Оценка рисков инвестиционного проекта: качественный и количественный подходы» рассматриваются теоретические основы и характеристика качественного и количественного подходов, методы оценки рисков проекта, а так же ...
... достаточно стабильна, факторы, влияющие на ее изменения, предопределены спецификой отрасли и предсказуемы. На основании анализа безубыточности можно заключить, что затраты на производство и реализацию программного обеспечения фирмы «Квестор плюс» окупятся и принесут прибыль при достижении необходимого объема производства, как и вложение инвестиций в деятельность компании. Целью проекта является ...
... "легче разработать новый программный продукт". Это связано со следующими проблемами: 1. Обычному программисту сложно разобраться в чужом исходном коде 2. Реинжиниринг чаще всего дороже разработки нового программного обеспечения, т.к. требуется убрать ограничения предыдущих версий, но при этом оставить совместимость с предыдущими версиями 3. Реинжиниринг не может сделать ...
... , в ней сочетаются лучшие средства для управления, делопроизводства, финансов, бухгалтерии предприятия. В данной дипломной работе предложен метод оценки экономической целесообразности производства ПЭВМ с помощью электронной модели, созданной с помощью одного из компонентов MS Office программы MS Excel (электронные таблицы). 2. ПРИМЕНЕНИЕ ЭЛЕКТРОННЫХ ТАБЛИЦ MS EXCEL ДЛЯ СОЗДАНИЯ ЭЛЕКТРОННОЙ МОДЕЛИ ...
0 комментариев