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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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