Управление рисками в проектах по созданию программного обеспечения

1. Управление рисками в проектах по созданию программного обеспечения

2.

План:
1. Определение риска в программных проектах
2. Обзор общих методов оценки рисков в проектах
3. Анализ чувствительности
Сетевые диаграммы
Метод Монте-Карло
Системная динамика
4. Применимость общих методов для оценки рисков в программных
проектах
5. Методы устранения и минимизации рисков в программных
проектах
6. Вывод

3.

Определение риска в программных проектах
Риск характеризуется 3-мя факторами: вероятностью наступления
события, величиной потерь или убытков в случае наступления
события и самим событием.
Необходимо различать понятия «риск» и «неопределенность»:
Неопределенность
предполагает
наличие
абсолютно
непрогнозируемых факторов, или факторы, влияние которых на
проект непредсказуемо, неизвестно, или информация о них неполна.
Это могут быть как внутренние факторы (компетентность персонала,
ошибочность определения характеристик или метрик, и т.д.) так и
внешние (законодательство, стихийные бедствия, любой форсмажор)
Риск, в отличие от неопределенности, является прогнозируемым,
предсказуемым, и в большинстве случаев его проявления, при
принятии заблаговременных мер, можно избежать. Риск – это степень
опасности для успешного осуществления проекта.
Риски так же разделяют на внутренние и внешние.

4. Определение риска в программных проектах

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

5.

Процесс управления рисками
Процесс управления рисками делится на шесть
основных процессов:
Планирование управления рисками
Идентификация рисков
Качественный анализ рисков
Количественный анализ рисков
Планирование реагирования на риски
Мониторинг и управление рисками
Остановимся на 3х из них: Идентификация,
Качественный анализ, Количественный анализ, т.к. эти
процессы наиболее зависимы от предметной области.

6. Идентификация рисков

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

7. Идентификация рисков

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

8. Идентификация рисков

Существует несколько методик идентификации рисков. Основные из них это:
Опрос экспертов. Группа экспертов высказывает свое мнение по
поводу возможных рисков, базируясь на своем опыте и данных о
предыдущих подобных проектах компании. Данная методика имеет
несколько недостатков. Например, эксперты могут ошибаться или не
идентифицировать все риски.
Улучшение такой методики является метод Delphi. Метод заключается
в следующем:
Выделяется группа экспертов, не знающих друг друга или не имеющих
связи.
Подготавливается и распространяется перечень вопросов, относящихся
к рискам.
Проводится опрос экспертов
Результаты
опроса и статистические данные по результатам
распространяются среди экспертов
Процесс повторяется, пока эксперты не достигнут консенсуса.
Преимущество данного метода заключается в том, что все во время
процесса участники не знают друг друга, что исключает доминирования
какого-либо эксперта и навязывание своего мнения группе. Так же
эксперты не боятся высказывать свое мнение анонимно.

9.

На выходе процесса идентификации рисков управляющий проектом должен
получить следующие данные:
Источники рисков. Типичные примеры:
Изменения в требованиях к продукту во время его разработки
Ошибки проектирования (архитектуры) будущего ПО
Плохо определенные или нераспределенные роли в команде
разработчиков
Неточные или вообще отсутствующие оценки сроков и стоимости
реализации проекта
Недостаточный профессионализм команды, исполняющей проект
Возможные события при проявлении рисков, как например: незаконченность
какого-то модуля ПО к сроку, несоответствие разработанного модуля
требованиям и т.д.
Потери в случае наступления рискового события, выраженные во времени и
(или)
денежном
эквиваленте.
Например:
переписывание
модуля,
несоответствующего требованиям, займет n человеко-часов и n*(средняя ЗП
программиста) рублей.
Симптомы наступления рискового события. Например, неготовность модуля к
тестированию или неудовлетворительные результаты тестирования незадолго
перед сдачей явно указывают на то, что модуль может быть незакончен в срок.

10. Обзор методов оценки рисков в проектах

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

11.

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

12.

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

13.

Деревья решений
Идея метода заключается в постройке дерева возможных решений и
рисков, соответствующих решениям. Пример такого дерева:
Ущерб 150000$
Мат.Ожидание
ущерба 41250$
Вариант архитектуры №1
(один централизованный
сервер приложений)
Риск, связанный со
сбоем аппаратного
обеспечения
Вероятность 25%
Ущерб 75000$
Архитектура
разрабатываемого
ПО
Вероятность 15%
Риск, связанный с
производительностью
сервера приложений
Вероятность 5%
Ущерб 250000$
Мат.Ожидание
ущерба 20000$
Вариант архитектуры
№2 (распределенные
сервера приложений)
Риск, связанный с
производительностью
базы данных
Вероятность 15%
Ущерб 50000$
Риск, связанный с
несовместимостью
CASE средств
Данный метод позволяет наглядно представить даже довольно сложные
структуры рисков и решений. Недостатком данного метода является
сложность точного определения вероятностей и потерь в случае наступления
рискового события.

14.

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

15.

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

16.

17. Выводы

В работе представлено множество методов
идентификации и оценки рисков в IT
проектах. Среди методов оценки рисков
наименее применяемый и наиболее
перспективный в данный момент – метод
системной динамики.

18. Дякую за увагу!