Учебный курс «Технологии программирования. Курс на базе Microsoft Solutions Framework (msf)»

Федеральное агентство по образованию РФ

ГОУ ВПО Нижегородский государственный университет им. Н.И. Лобачевского

Факультет Вычислительной математики и кибернетики

Кафедра Математического обеспечения ЭВМ

УЧЕБНЫЙ КУРС

«Технологии программирования.
Курс на базе Microsoft Solutions Framework (MSF)»

для подготовки по направлению «Информационные технологии»

оценка рисков

Нижний Новгород

2006

Содержание^¹

оценка рисков 1

1. Возможные риски 3

2. Классификация рисков 4

3. Анализ и приоритезация рисков 6

1.Возможные риски

1.1.Описание

Целью фазы выявления рисков является создание проектной группой^² списка имеющихся рисков проекта. Этот список должен в максимально-возможной степени охватывать все факторы, влияющие на проект.

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

В процессе выявления рисков проектная группа старается четко сформулировать и перечислить все имеющиеся в проекте риски. На начальной стадии проекта может быть организован семинар или мозговой штурм с целью выявления рисков, возникающих в новых условиях. Как минимум, в результате процесса выявления рисков должны быть получены их четкие, однозначные и согласованные формулировки, представленные в виде списка рисков (рекомендуемое представление – табличное) – см. следующий раздел.

1.2.ToDo

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

	Наименование риска	Комментарий
1
2
3
4

2.Классификация рисков

2.1.Описание

Первое. Выяснить, каково происхождение каждого выявленного риска.

Примеры источников рисков:

Люди

Заказчики (customers)

Конечные потребители (конечные пользователи, end users)

Спонсоры

Заинтересованные стороны

Персонал

Организация

Профессиональная квалификация

Политика

Мораль

Процессы

Цели и задачи

Принятие решений

Характеристики проекта

Бюджет, затраты, сроки

Требования (requirements)

Проектирование (design)

Реализация (building)

Тестирование (testing)

Технологии

Безопасность

Среда разработки и тестирования

Инструментарий

Внедрение

Сопровождение

Операционная среда

Доступность

Внешние условия

Законодательство

Индустриальные стандарты

Конкуренция

Экономические условия

Технология

Бизнес-условия

Второе. Формулировка риска – это выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта (текущим положением дел) и потенциально возможным, еще не случившимся событием или ситуацией. Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать.

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

Первопричина	Условие	Последствие	Приносимый ущерб
Нехватка кадров	Могут быть объединены роли разработчиков и тестировщиков	В программном продукте будет содержаться больше ошибок	Заказчик будет менее доволен результатом
Изменения в технологии	Разработчикам придется использовать новый язык программирования	Увеличится затрачиваемое на разработку время	Наш продукт будет представлен на рынке в более поздние сроки, что приведет к захвату части рынка конкурентами
Организация работы	Часть группы разработчиков находится в Лондоне, а часть – в Лос-Анжелесе	Обмен информацией внутри группы затрудняется	Задержки в сроках сдачи готового продукта и дополнительные трудозатраты

2.2.ToDo

В результате общего обсуждения в команде классифицируйте выявленные на предыдущем этапе риски: выделите категории связанных рисков, сгруппируйте их. Для каждого риска выявите причину, условие возникновения, возможные последствия, возможный ущерб (помните, что “ущерб” может быть и положительным). Для каждой категории рисков составьте таблицу указанного выше вида.

3.Анализ и приоритезация рисков

3.1.Описание

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

Во время этого этапа проектная группа рассматривает риски из списка, составленного при их выявлении, задает приоритеты и формирует главную таблицу рисков.

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

Вероятность риска (risk probability) – это мера возможности того, что последствие риска, описанное в его формулировке, действительно наступит. Это может быть простейшая градация “низко-средне-высоко”, отображаемая в отдельно взятые численные значения (17%, 50%, 84%), либо же сложные оценки таких выражений как “почти невозможно”, “маловероятно”, “возможно”, “почти наверняка” и т.д.

Угроза риска (risk impact) представляет собой меру серьезности негативных последствий, уровень убытков или оценку потенциальных возможностей, связанных с риском. Угроза должна быть непосредственным числовым выражением последствия риска, описанного в его формулировке. Она может оцениваться в денежных единицах или же по некоторой субъективной шкале.

В иных ситуациях предпочтительна субъективная пятибалльная или десятибалльная шкала для оценки угрозы рисков.

Пример:

Оценка	Денежное выражение
1	до $100
2	$100-$1000
3	$1000-$10,000
4	$10,000-$100,000
5	$100,000-$1,000,000

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

Анализ рисков предоставляет проектной группе приоритезированный список рисков, который необходим на этапе планирования. Как было сказано выше, дисциплина управления рисками MSF называет его главной таблицей рисков (master risk list).

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

Приоритет	Причина	Последствие	Вероятность	Угроза	Ожидаемая величина
1	Затянутый временной график проекта	Потеря финансирования в конце года	80%	3	2.4
2	Отсутствие стандартов кодирования для нового языка програм-мирования	Выпуск продукта, содержащего ошибки	45%	2	0.9
3	Отсутствие специфи-кации требований в письменном виде	Некоторые требования не будут реализованы	30%	2	0.6

3.2.ToDo

В результате общего обсуждения в команде проанализируйте сформулированные на предыдущем этапе риски. Выберите и зафиксируйте в данном разделе меры для градации вероятностей и угроз рисков. Для каждого риска задайте вероятность его реализации и возможную угрозу в выбранных единицах. Для каждой категории (см. предыдущий этап) рисков сформируйте главную таблицу рисков указанного выше вида.

1 В документе использованы материалы белых книг (white papers) “MSF Process Model”, “MSF Risk Management Discipline”, “MSF Team Model” (http://www.microsoft.com/msf), их переводов “Модель процессов MSF”, “Дисциплина управления рисками MSF”, “Модель проектной группы MSF” выполненных в 2003 году корпораций eLine Software (http://www.elinesoftware.com), а также официальных курсов Microsoft 2710B и 1846A.

2 Здесь и далее термины “проектная группа” и “команда” считаются синонимами.

Содержание1