Файл: Методические указания по выполнению практических работ по профессиональному модулю.doc

Схема процесса управления рисками показана на рис. 6. Этот процесс состоит из че­тырех стадий.

1. 
   Определение рисков. Определяются возможные риски для проекта, для разрабатывае­мого продукта и бизнес-риски.
   
2. 
   Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций.
   
3. 
   Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.
   
4. 
   Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций.
   

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

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

Результаты процесса управления рисками документируются в виде планов управления рисками. Они должны включать описание возможных проектных рисков, их анализ и пе­речень мероприятий, необходимых для управления рисками.

Определение рисков

Определение рисков — первая стадия процесса управления рисками. На этой ста­дии описываются риски, которые могут проявиться при реализации проекта. В прин­ципе на этой стадии не должна оцениваться вероятность и значимость рисков, но на практике маловероятные риски с незначительными последствиями обычно отбрасы­ваются сразу.

Определение рисков может выполняться в режиме командной работы с использовани­ем подхода "мозговой штурм" либо основываться на опыте менеджера. При определении рисков может помочь приведенный ниже список возможных категорий рисков.

1. 
   Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.
   
2. 
   Риски, связанные с персоналом. Связаны с членами команды разработчиков.
   
3. 
   Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.
   
4. 
   Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.
   
5. 
   Риски, связанные с системными требованиями. Проявляются при изменении требова­ний, предъявляемых к разрабатываемой системе.
   
6. 
   Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.
   

---

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

Таблица 5 - Категории рисков

Категория рисков	Примеры рисков
Технологические риски	База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций. Программные компоненты, которые используются повторно, имеют дефекты, ограничивающие их функциональные воз­можности
Риски, связанные с персоналом	Невозможно подобрать работников с требуемым профессиональным уровнем. Ведущий разработчик заболел в самое критическое время.  Невозможно организовать необходимое обучение персонала
Организационные риски	В организации, выполняющей разработку ПО, произошла ре­организация, в результате чего изменились приоритеты в управлении проектом. Финансовые затруднения в организации привели к уменьше­нию бюджета проекта
Инструментальные риски	Программный код, генерируемый CASE-средствами, не эф­фективен. CASE-средства невозможно интегрировать с другими средствами поддержки проекта
Риски, связанные с системными требованиями	Изменения требований приводят к значительным повторным темными требованиями      работам по проектированию системы. Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта
Риски оценивания	Недооценки времени выполнения проекта.  Скорость выявления дефектов в системе ниже ранее запланированной.  Размер системы значительно превышает первоначально рассчитанный

Анализ рисков

При анализе для каждого определенного риска подсчитывается вероятность его про­явления и ущерб, который он может нанести. Не существует простых методов выполне­ния анализа рисков — в значительной мере он основан на мнении и опыте менеджера. Можно привести следующую шкалу вероятностей рисков и их последствий.

---

1. 
   Вероятность риска считается очень низкой, если она имеет значение менее 10%; низ­кой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
   
2. 
   Возможный ущерб от рисковых ситуаций можно подразделить на катастрофиче­ский, серьезный, терпимый и незначительный.
   

Результаты анализа рисков должны быть представлены в виде таблицы рисков, упоря­доченных по степени возможного ущерба. В табл. 6 приведен упорядоченный список рисков, описанных в табл. 5; там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, технологии создания ПО, команде разра­ботчиков и о самой организации.

Таблица 6 - Список рисков после проведения их анализа

Риск	Вероятность	Степень ущерба
Финансовые затруднения в организации привели к уменьшению бюджета проекта	Низкая	Катастрофическая
Невозможно подобрать работников с требующимся профессиональным уровнем	Высокая	Катастрофическая
Ведущий разработчик заболел в самое критическое время	Средняя	Серьезная
Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональные возможности	Средняя	Серьезная
Изменения требований приводят к значительным повторным работам по проектированию системы	Средняя	Серьезная
В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом	Высокая	Серьезная
База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций	Средняя	Серьезная
Недооценки времени выполнения проекта	Высокая	Серьезная
CASE-средства невозможно интегрировать с другими средствами поддержки проекта	Высокая	Терпимая
Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта	Средняя	Терпимая
Невозможно организовать необходимое обучение персонала	Средняя	Терпимая
Скорость выявления дефектов в системе ниже ранее спланированной	Средняя	Терпимая
Размер системы значительно превышает первона­чально рассчитанный	Высокая	Терпимая
Программный код, генерируемый CASE-средствами, неэффективен	Средняя	Незначительная

---

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

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

В некоторых статьях рекомендуется определить и отслеживать "10 верхних" рисков, но это не всегда обоснованная рекомендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а может — пятнадцать. Но, конечно, количество рисков, по которым проводится мониторинг, долж­но быть обозримым. Большое количество отслеживаемых рисков потребует огромного количества собираемой информации. Из списка рисков, представленных в табл. 6, для мониторинга следует отобрать те риски, которые могут привести к катастрофи­ческим и серьезным последствиям для вашего проекта.

Планирование рисков

Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинга после анализа рисков. Здесь также не существует общепринятых подходов для разработки таких стратегий — многое основывается на "чутье" и опыте менеджера проекта. В табл. 7 показаны возможные стратегии управле­ния основными рисками, приведенными в табл. 6.

Таблица 7 - Стратегии управления рисками

Риск	Стратегия
Финансовые проблемы организации	Подготовить краткий документ для руководства организации, показывающий важность данного проекта для достижения финансовых целей организации
Проблемы неквалифицированного персонала	Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы
Болезни персонала	Реорганизовать работу команды разработчиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками
Дефектные системные компоненты	Заменить потенциально дефектные системные компоненты покупными компонентами, гарантирующими качество работы
Изменения требований	Попытаться определить требования, наиболее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию
Реорганизация компании-разработчика	Подготовить краткий документ для руководства компании, показывающий важность данного проекта для достижения финансовых целей компании
Недостаточная производительность базы данных	Рассмотреть возможность покупки более производительной базы данных
Недооценки времени выполнения проекта	Рассмотреть вопрос о покупке системных компонентов, исследовать возможность использования генератора программного кода

---

 Существует три категории стратегий управления рисками.

1. 
   Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить меро­приятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов, описанная в табл. 7.
   
2. 
   Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов коман­ды разработчиков (см. табл. 7).
   
3. 
   Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой си­туации. В табл. 7 это стратегия поведения при возникновении финансовых про­блем у организации-разработчика.
   

Мониторинг рисков

Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать фак­торы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В табл. 8 приведены признаки, которые помогают определить тип риска.

Таблица 8 - Признаки рисков

Тип риска	Признаки
Технологические риски	Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документи­рованные технологические проблемы
Риски, связанные с персоналом	Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выпол­ненной работы
Организационные риски	Разговоры среди персонала о пассивности и недостаточной компетентности высшего руководства организации
Инструментальные риски	Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства
Риски, связанные с системными требованиями	Необходимость пересмотра многих системных требований, недовольство заказчика ПО
Риски оценивания	Изменения графика работ, многочисленные отчеты о нарушении графика работ

---