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

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

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

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

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

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

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

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

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

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

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

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

анализ чувствительности

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

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

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

Системная динамика

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

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

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