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

Содержание

Введение

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

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

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

Сетевые диаграммы

Метод Монте-Карло

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

Применимость общих методов для оценки рисков в программных проектах

Методы устранения и минимизации рисков в программных проектах

Вывод

 

Введение

Управление проектными рисками (в применении к общим проектам, в основном связанных со строительством или промышленным производством) стало активно развиваться в 50х годах прошлого века, в основном на Западе.

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

Управление рисками описано во многих работах, посвященных управлению проектами. Самым известным, наверное, можно считать PMBOK (Project Management Body Of Knowledge), написанный PMI (Project Management Institute – Институт Управления Проектами). Управление рисками так же описано в P2M японской ассоциации управления проектами PMAJ (Project Management Association of Japan).

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

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

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

· Составление четкого списка требований

· 100% планирование и проектирование будущего программного продукта

· Непосредственно реализация (написание кода)

· Ввод в эксплуатацию

· Непосредственно эксплуатация

· Вывод из эксплуатации, утилизация

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

На смену данной методологии разработки программного обеспечения (называемой так же «водопадной») пришли такие методологии, как «Agile». Основной идеей «гибких»

Agile методологий является использование нескольких итераций для тестирования и последовательной «подгонки» продукта под требования заказчика. Наилучшей аналогией Agile методологий вне мира программного обеспечения является работа конструкторских бюро. Создание новой модели самолета\танка\автомобиля\любого образца вооружения обязательно проходит серию испытаний, после чего возвращается обратно в КБ для доработки и исправления недочетов, после чего серия испытаний повторяется и итерации повторяются до тех пор, пока не будет достигнут нужный уровень качества.

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

Риск характеризуется 3мя факторами: вероятностью наступления события, величиной потерь или убытков в случае наступления события и самим событием.

Необходимо различать понятия «риск» и «неопределенность»:

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

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

Риски так же разделяют на внутренние и внешние.

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

Внешние риски – это те рисковые события, которые лежат за пределами контроля и влияния команды проекта (например, влияние рынка, новое законодательство, стихийное бедствие и др.)

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