Похожие презентации:
Управление рисками в проектах по созданию программного обеспечения
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
проектах. Среди методов оценки рисков
наименее применяемый и наиболее
перспективный в данный момент – метод
системной динамики.