Высшая Школа Экономики
Факультет Бизнес-Информатики
Отделение Программной Инженерии
Тимаков Антон
Группа 171мУРПО
Реферат на тему
«Управление рисками в проектах по созданию программного обеспечения»
Содержание
1. Введение
2. Определение риска в программных проектах
3. Обзор общих методов оценки рисков в проектах
3.1 Анализ чувствительности
3.2 Сетевые диаграммы
3.3 Метод Монте-Карло
3.4 Системная динамика
4. Применимость общих методов для оценки рисков в программных проектах
5. Методы устранения и минимизации рисков в программных проектах
6. Вывод
Введение
Управление проектными рисками (в применении к общим проектам, в основном связанных со строительством или промышленным производством) стало активно развиваться в 50х годах прошлого века, в основном на Западе.
Появление анализа проектных рисков было связано в первую очередь с увеличивающейся технической сложностью проектов. Технические проблемы проектов усложняли работу не только инженеров, но и инвесторов, финансистов и топ-менеджеров, далеких от инженерных подробностей проектов. Всевозможные задержки, заминки и случайности в сложных и четко распланированных по расписанию проектах заставляли увеличивать бюджеты и смещать сроки реализации. Все это заставило менеджеров проектов и инвесторов осознать, что проектные риски можно и нужно анализировать. В современном мире анализ рисков проекта стал неотъемлемой частью обоснования проекта, а в науке управления проектами четко обосновалась глава про управление рисками.
Управление рисками описано во многих работах, посвященных управлению проектами. Самым известным, наверное, можно считать PMBOK (Project Management Body Of Knowledge), написанный PMI (Project Management Institute – Институт Управления Проектами). Управление рисками так же описано в P2M японской ассоциации управления проектами PMAJ (Project Management Association of Japan).
Для того чтобы качественно управлять рисками необходимо качественно и количественно их описать. Как правило, качественное описание рисков можно сделать просто из здравого ума и технического опыта архитекторов и дизайнеров технической части проекта. Гораздо труднее описать риски количественно.
Анализ проектных рисков так же очень востребован в программной инженерии по нескольким причинам. Во-первых, практически все, без исключения, фирмы по производству программного обеспечения имеют проектно-ориентированную бизнес модель. Во-вторых, программное обеспечение практически с самого начала стало сложным и сверхсложным продуктом, требующим большого количества человеко-часов работы высококвалифицированного персонала, что не может не вызывать ошибки, задержки и связанные с этим риски.
В мире программного обеспечения наблюдалась такая же эволюция, как и в промышленности. Первоначальные методологии и модели жизненного цикла программного обеспечения были взяты из промышленности и предполагали:
Но при использовании этой модели жизненного цикла в программной инженерии стало понятно, что нарушения графиков происходят чаще, чем в обычных строительных проектах, что ведет к частым пересмотрам и сдвигам проектных графиков и бюджетов. Результатом анализа рисков данной модели и методологии разработки программного обеспечения стала кардинальная смена жизненного цикла программного обеспечения, а так же методик его разработки и технической поддержки и, по сути, создание новой бизнес-модели продажи продукта заказчику.
На смену данной методологии разработки программного обеспечения (называемой так же «водопадной») пришли такие методологии, как «Agile». Основной идеей «гибких»
Agile методологий является использование нескольких итераций для тестирования и последовательной «подгонки» продукта под требования заказчика. Наилучшей аналогией Agile методологий вне мира программного обеспечения является работа конструкторских бюро. Создание новой модели самолета\танка\автомобиля\любого образца вооружения обязательно проходит серию испытаний, после чего возвращается обратно в КБ для доработки и исправления недочетов, после чего серия испытаний повторяется и итерации повторяются до тех пор, пока не будет достигнут нужный уровень качества.
Определение риска в программных проектах
Риск характеризуется 3мя факторами: вероятностью наступления события, величиной потерь или убытков в случае наступления события и самим событием.
Необходимо различать понятия «риск» и «неопределенность»:
Неопределенность предполагает наличие абсолютно непрогнозируемых факторов, или факторы, влияние которых на проект непредсказуемо, неизвестно, или информация о них неполна. Это могут быть как внутренние факторы (компетентность персонала, ошибочность определения характеристик или метрик, и т.д.) так и внешние (законодательство, стихийные бедствия, любой форс-мажор)
Риск, в отличие от неопределенности, является прогнозируемым, предсказуемым, и в большинстве случаев его проявления, при принятии заблаговременных мер, можно избежать. Риск – это степень опасности для успешного осуществления проекта.
Риски так же разделяют на внутренние и внешние.
Внутренние риски – это рисковые события, появления которых зависит от внутренних факторов выполнения проекта. Такие риски может контролировать и предотвращать команда проекта (например, определение продолжительности работ, подбор кадров, составление сметы затрат и т.д.)
Внешние риски – это те рисковые события, которые лежат за пределами контроля и влияния команды проекта (например, влияние рынка, новое законодательство, стихийное бедствие и др.)
Обычно понятие риска сопряжено только с возможностью потерь или убытков. Однако некоторые риски могут иметь и положительные результаты для проекта.
Процесс управления рисками
Институт PMI описывает системный подход к процессу управления рисками, который описан в PMBOK. Процесс управления рисками делится на шесть основных процессов:
Остановимся на 3х из них: Идентификация, Качественный анализ, Количественный анализ, т.к. эти процессы наиболее зависимы от предметной области и рассмотрим их более подробно в контексте программной инженерии.
Идентификация рисков
Если рассматривать идентификацию рисков как процесс, то, как и у любого процесса, у него должны быть исходные данные и некоторый конкретный результат. В данном случае входом процесса идентификации рисков будут:
Внимательное изучение структуры сбоев и сетевых диаграмм, имеющих отношение к планам управления предыдущих проектов, помогает составить перечень потенциально узких мест проекта. Иногда всего лишь эскизный набросок рассматриваемого процесса помогает выявить зоны риска.
Как правило, для проекта среднего и большого размера количество всевозможных рисков очень велико. И без классификации и структуризации рисков управлять и минимизировать действие рисков практически невозможно. Главным инструментом для структуризации большого количества рисков является определение источников рисков, т.к. источников рисков, как правило, немного. Главными источниками риска для программных проектов являются: способность разрабатываемого ПО к поддержке (легкость внесения изменений, легкость разрешения проблем на сервере заказчика и т.д.), программистский аспект и технический аспект. Риски технического характера играют основную роль при разработке ПО т.к. разработка ПО входит в число высокотехнологичных отраслей, что означает повышенную зависимость от технологий. Программистские риски возникают в том случае, если предпринимаются попытки управления программным проектом. По мере того, как разработка программного продукта приближается к завершению, все большее значение приобретают риски, связанные с поставкой ПО, его установкой и методикой поддержки.
Существует несколько методик идентификации рисков. Основные из них - это:
Опрос экспертов. Группа экспертов высказывает свое мнение по поводу возможных рисков, базируясь на своем опыте и данных о предыдущих подобных проектах компании. Данная методика имеет несколько недостатков. Например, эксперты могут ошибаться или не идентифицировать все риски.
Улучшение такой методики является метод Delphi. Метод заключается в следующем: