Функции управления риском




Оценка риска проектов программного обеспечения


Введение

 

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

Риск (по определению SEI (Software Engineering Institute)) - это возможность понести потери.

Риск проекта ПО - это возможность:

1) снижения качества конечного продукта,

2) повышения стоимости его разработки,

3) задержки окончания разработки или срыва проекта (то есть, отказа от проекта).

Величина риска представляет собой R = V * P произведение величины потерь V от нежелательного события в проекте и вероятности P наступления этого события.

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

Эффективное управление риском состоит в принятии (по каждому риску) компромиссных решений по:

· учету рисков и анализу старых проектов;

· оценке трудоемкости устранения определенного риска,

· величине потенциального отрицательного воздействия этого риска на проект,

· в правильной оценке взаимозависимости устраняемых рисков и возможного влияния принятых в определенный (текущий) момент времени решений на состояние проекта в будущем;

· резервировании в проекте времени на борьбу с рисками.

С ростом размера и сложности проектов ПО наметилась тенденция к переходу от эвристических методов управления риском, применяемых отдельными лицами, принимающими решение (ЛПР), исходя из собственных знаний и опыта управления разработкой ПО, к использованию систематизированных, гибких и легко адаптируемых методов управления риском, обеспечивающих ЛПР всей необходимой информацией для своевременной идентификации и устранения риска проекта.

 


Концепция управления риском проекта ПО

 

Базовыми конструкциями концепции управления риском являются:

· функции управления риском,

· таксономия (классификация) риска;

· методология оценки и управления риском.

Представление концепции в виде круга подчеркивает ее суть, заключающуюся в непрерывности процесса управления риском. Ориентация стрелок указывает направление логического потока информации, связывающего отдельные виды деятельности. Центральной частью концепции является коммуникация, в эффективности средств и методов осуществления которой залог успешного выполнения всех остальных видов деятельности и управления риском в целом.

 

Рис. 1. Концепция управления риском

Функции управления риском

 

Таблица 1 Характеристика функций управления риском

Функция Определение функция Цель функция
Идентификация Процесс, в ходе которого неопределенности и проблемы проекта трансформируются в реальные риски, которые можно описать и измерить Искать и найти риски проекта ПО до того, как они перерастут в проблемы
Анализ Процесс, в ходе которого устанавливаются детали рисков - величины и источники рисков, их взаимосвязи и степени важности, серьезность последствий, вероятность и время возможного проявления Преобразовать данные о рисках в информацию для принятия адекватных решений
Планирование Процесс, в ходе которого принимаются решения о мерах по устранению рисков Выработать решения и план действий по каждому риску. Интегрировать эти решения и планы в единый план управления риском проекта ПО.
Учет и контроль Процесс, в ходе которого собираются, обобщаются и фиксируются данные о состоянии рисков и действий по их устранению Контролировать соблюдение графика действий по риску и эффективность самого плана действий
Регулирование Процесс, в ходе которого анализируются отчетные данные и принимаются решения о дальнейших действиях по риску Своевременная и эффективная коррекция отклонений в запланированных действиях по риску
Коммуникация Организация взаимодействия по управлению риском стимулирует выполнение остальных функций и гарантирует, что: · риски и планы их устранения интерпретируются однозначно, · информация о риске является доступной для всех членов проекта; · любой информации о риске уделяется надлежащее внимание; · существует эффективный диалог между менеджером и командой проекта Обеспечение непрерывной эффективной передачи информации и обратной связи со всеми функциями и на всех уровнях управления риском (включая устраняемые, неустраняемые (находящиеся под наблюдением) и вновь появляющиеся риски). Учет как внутренних, так и внешних для проекта источников информации о риске.

 

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. Превышение возможностей компьютерной науки Технический анализ; анализ прибыльности; прототипирование; справочные проверки.


Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-12-28 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: