Высшая Школа Экономики Факультет Бизнес-Информатики Отделение Программной ИнженерииТимаков Антон Группа 171мУРПО Реферат на тему «Управление рисками в проектах по созданию программного обеспечения»СодержаниеВведениеОпределение риска в программных проектахОбзор общих методов оценки рисков в проектахАнализ чувствительностиСетевые диаграммыМетод Монте-КарлоСистемная динамикаПрименимость общих методов для оценки рисков в программных проектахМетоды устранения и минимизации рисков в программных проектахВыводВведение Управление проектными рисками (в применении к общим проектам, в основном связанных со строительством или промышленным производством) стало активно развиваться в 50х годах прошлого века, в основном на Западе. Появление анализа проектных рисков было связано в первую очередь с увеличивающейся технической сложностью проектов. Технические проблемы проектов усложняли работу не только инженеров, но и инвесторов, финансистов и топ-менеджеров, далеких от инженерных подробностей проектов. Всевозможные задержки, заминки и случайности в сложных и четко распланированных по расписанию проектах заставляли увеличивать бюджеты и смещать сроки реализации. Все это заставило менеджеров проектов и инвесторов осознать, что проектные риски можно и нужно анализировать. В современном мире анализ рисков проекта стал неотъемлемой частью обоснования проекта, а в науке управления проектами четко обосновалась глава про управление рисками. Управление рисками описано во многих работах, посвященных управлению проектами. Самым известным, наверное, можно считать PMBOK (Project Management Body Of Knowledge), написанный PMI (Project Management Institute – Институт Управления Проектами). Управление рисками так же описано в P2M японской ассоциации управления проектами PMAJ (Project Management Association of Japan). Для того чтобы качественно управлять рисками необходимо качественно и количественно их описать. Как правило, качественное описание рисков можно сделать просто из здравого ума и технического опыта архитекторов и дизайнеров технической части проекта. Гораздо труднее описать риски количественно. Анализ проектных рисков так же очень востребован в программной инженерии по нескольким причинам. Во-первых, практически все, без исключения, фирмы по производству программного обеспечения имеют проектно-ориентированную бизнес модель. Во-вторых, программное обеспечение практически с самого начала стало сложным и сверхсложным продуктом, требующим большого количества человеко-часов работы высококвалифицированного персонала, что не может не вызывать ошибки, задержки и связанные с этим риски. В мире программного обеспечения наблюдалась такая же эволюция, как и в промышленности. Первоначальные методологии и модели жизненного цикла программного обеспечения были взяты из промышленности и предполагали: Составление четкого списка требований 100% планирование и проектирование будущего программного продукта Непосредственно реализация (написание кода) Ввод в эксплуатацию Непосредственно эксплуатация Вывод из эксплуатации, утилизация Но при использовании этой модели жизненного цикла в программной инженерии стало понятно, что нарушения графиков происходят чаще, чем в обычных строительных проектах, что ведет к частым пересмотрам и сдвигам проектных графиков и бюджетов. Результатом анализа рисков данной модели и методологии разработки программного обеспечения стала кардинальная смена жизненного цикла программного обеспечения, а так же методик его разработки и технической поддержки и, по сути, создание новой бизнес-модели продажи продукта заказчику. На смену данной методологии разработки программного обеспечения (называемой так же «водопадной») пришли такие методологии, как «Agile». Основной идеей «гибких» Agile методологий является использование нескольких итераций для тестирования и последовательной «подгонки» продукта под требования заказчика. Наилучшей аналогией Agile методологий вне мира программного обеспечения является работа конструкторских бюро. Создание новой модели самолета\танка\автомобиля\любого образца вооружения обязательно проходит серию испытаний, после чего возвращается обратно в КБ для доработки и исправления недочетов, после чего серия испытаний повторяется и итерации повторяются до тех пор, пока не будет достигнут нужный уровень качества. ^ Определение риска в программных проектах Риск характеризуется 3мя факторами: вероятностью наступления события, величиной потерь или убытков в случае наступления события и самим событием. Необходимо различать понятия «риск» и «неопределенность»:Неопределенность предполагает наличие абсолютно непрогнозируемых факторов, или факторы, влияние которых на проект непредсказуемо, неизвестно, или информация о них неполна. Это могут быть как внутренние факторы (компетентность персонала, ошибочность определения характеристик или метрик, и т.д.) так и внешние (законодательство, стихийные бедствия, любой форс-мажор)Риск, в отличие от неопределенности, является прогнозируемым, предсказуемым, и в большинстве случаев его проявления, при принятии заблаговременных мер, можно избежать. Риск – это степень опасности для успешного осуществления проекта. Риски так же разделяют на внутренние и внешние. ^ Внутренние риски – это рисковые события, появления которых зависит от внутренних факторов выполнения проекта. Такие риски может контролировать и предотвращать команда проекта (например, определение продолжительности работ, подбор кадров, составление сметы затрат и т.д.)^ Внешние риски – это те рисковые события, которые лежат за пределами контроля и влияния команды проекта (например, влияние рынка, новое законодательство, стихийное бедствие и др.) Обычно понятие риска сопряжено только с возможностью потерь или убытков. Однако некоторые риски могут иметь и положительные результаты для проекта. ^ Процесс управления рисками Институт PMI описывает системный подход к процессу управления рисками, который описан в PMBOK. Процесс управления рисками делится на шесть основных процессов: Планирование управления рисками Идентификация рисков Качественный анализ рисков Количественный анализ рисков Планирование реагирования на риски Мониторинг и управление рискамиОстановимся на 3х из них: Идентификация, Качественный анализ, Количественный анализ, т.к. эти процессы наиболее зависимы от предметной области и рассмотрим их более подробно в контексте программной инженерии. ^ Идентификация рисков Если рассматривать идентификацию рисков как процесс, то, как и у любого процесса, у него должны быть исходные данные и некоторый конкретный результат. В данном случае входом процесса идентификации рисков будут: Подробное описание проекта, что включает в себя: требование, первоначальную архитектуру создаваемого ПО, описание конфигурации аппаратного обеспечения, описание программных инструментов, которые будут использоваться для создания программного обеспечения. Всевозможные оценки сроков, времени и стоимости создания модулей и компонентов будущего проекта. Отчеты о предыдущих проектах, выполненных компанией. Данные о проделанных компанией проектах помогают точнее идентифицировать риски. Правило вести архив с отчетами по предыдущим проектам выполняется далеко не всеми компаниями. Из наиболее крупных и известных компаний, которые поддерживают данную практику, можно назвать IBM. В большинстве компаний опыт по проделанным проектам есть только непосредственно у менеджеров проектов, и нигде документально не зафиксирован. Это означает, что при смене менеджера проектов в компании пропадает и весь его опыт по ведению проектов. Внимательное изучение структуры сбоев и сетевых диаграмм, имеющих отношение к планам управления предыдущих проектов, помогает составить перечень потенциально узких мест проекта. Иногда всего лишь эскизный набросок рассматриваемого процесса помогает выявить зоны риска. Как правило, для проекта среднего и большого размера количество всевозможных рисков очень велико. И без классификации и структуризации рисков управлять и минимизировать действие рисков практически невозможно. Главным инструментом для структуризации большого количества рисков является определение источников рисков, т.к. источников рисков, как правило, немного. Главными источниками риска для программных проектов являются: способность разрабатываемого ПО к поддержке (легкость внесения изменений, легкость разрешения проблем на сервере заказчика и т.д.), программистский аспект и технический аспект. Риски технического характера играют основную роль при разработке ПО т.к. разработка ПО входит в число высокотехнологичных отраслей, что означает повышенную зависимость от технологий. Программистские риски возникают в том случае, если предпринимаются попытки управления программным проектом. По мере того, как разработка программного продукта приближается к завершению, все большее значение приобретают риски, связанные с поставкой ПО, его установкой и методикой поддержки. Существует несколько методик идентификации рисков. Основные из них - это:^ Опрос экспертов. Группа экспертов высказывает свое мнение по поводу возможных рисков, базируясь на своем опыте и данных о предыдущих подобных проектах компании. Данная методика имеет несколько недостатков. Например, эксперты могут ошибаться или не идентифицировать все риски. Улучшение такой методики является метод Delphi. Метод заключается в следующем: Выделяется группа экспертов, не знающих друг друга или не имеющих связи. Подготавливается и распространяется перечень вопросов, относящихся к рискам. Проводится опрос экспертов Результаты опроса и статистические данные по результатам распространяются среди экспертов Процесс повторяется, пока эксперты не достигнут консенсуса. Преимущество данного метода заключается в том, что все во время процесса участники не знают друг друга, что исключает доминирования какого-либо эксперта и навязывание своего мнения группе. Так же эксперты не боятся высказывать свое мнение анонимно. На выходе процесса идентификации рисков управляющий проектом должен получить следующие данные: Источники рисков. Типичные примеры: Изменения в требованиях к продукту во время его разработки Ошибки проектирования (архитектуры) будущего ПО Плохо определенные или нераспределенные роли в команде разработчиков Неточные или вообще отсутствующие оценки сроков и стоимости реализации проекта Недостаточный профессионализм команды, исполняющей проект Возможные события при проявлении рисков, как например: незаконченность какого-то модуля ПО к сроку, несоответствие разработанного модуля требованиям и т.д. Потери в случае наступления рискового события, выраженные во времени и (или) денежном эквиваленте. Например: переписывание модуля, несоответствующего требованиям, займет n человеко-часов и n*(средняя ЗП программиста) рублей. Симптомы наступления рискового события. Например, неготовность модуля к тестированию или неудовлетворительные результаты тестирования незадолго перед сдачей явно указывают на то, что модуль может быть незакончен в срок. ^ Обзор методов оценки рисков в проектах Задачей количественного и качественного анализа риска является определение: Определение вероятности рискового события Определение величины ущерба, в случае наступления рискового события Определение действий для предотвращения рисковых событий. Определение реагирования на рисковые события в случае наступления Существует несколько методик для определения необходимых действий для предотвращения рисковых событий. ^ 1. Анализ чувствительности Один из самых распространенных на данный момент методов количественного анализа рисков является анализ чувствительности. Суть метода заключается в том, чтобы посчитать изменение одного из глобальных параметров (время или стоимость) проекта при изменении одного из входных параметров (количество ресурсов, персонала, денег, заданное время на создание или проектирование одного из блоков, и т.д.). Данный метод позволяет определить параметр, к которому время исполнения или бюджет проекта наиболее чувствителен. Т.е. снижение диапазона возможных вариации самых чувствительных параметров помогает снизить и диапазон возможных вариации главных параметров (время и стоимость) проекта, что делает проект более управляемым и стойким к внешним воздействиям.^ 2. Деревья решений Идея метода заключается в постройке дерева возможных решений и рисков, соответствующих решениям. Пример такого дерева:Данный метод позволяет наглядно представить даже довольно сложные структуры рисков и решений. Недостатком данного метода является сложность точного определения вероятностей и потерь в случае наступления рискового события. ^ 3. Метод Монте-Карло Метод Монте-Карло исправляет основной недостаток предыдущего метода, а именно невозможность точного определения ущерба и вероятности риска. В данном методе вероятности и ущербы задаются функциями распределения вероятности возникновения рискового события (как правило, все функции распределения – гауссовские). Данный метод на порядок сложнее для расчетов, но, при этом, дает более полную картину для управления рисками в проекте. Кроме того, данный метод легко обсчитывается с применением компьютеров. ^ 4. Системная динамика Пожалуй, самый новый метод моделирования проекта, позволяющий наиболее комплексно описать проект и с помощью имитационного моделирования процессов, протекающих в проекте, определить источники риска и даже количественно описать их. Пример описания проекта по разработке ПО с использованием системной динамики, ориентированный на моделирование изменения требований к разрабатываемому ПО: Основной недостаток метода – необходимость большего количества времени для построения модели. Другая проблема - необходимость «притирки» модели - уточнения коэффициентов и параметров модели. В итоге: метод более ресурсоемкий по сравнению с другими методами, но предоставляет более полную и ясную картину рисков проекта. Вывод В работе представлено множество методов идентификации и оценки рисков в IT проектах. Среди методов оценки рисков наименее применяемый и наиболее перспективный в данный момент – метод системной динамики. ^ Список литературы Управление проектами по созданию программного обеспечения. Уокер Ройс. Лори, 2007г. Управление проектами. Руководство по подготовке к сдаче сертификационного экзамена РМР. Майкл В.Ньюэлл. Кудиц-Образ, 2006г. Управление программными проектами. Достижение оптимального качества при минимуме затрат. Роберт Т.Фатрелл, Дональд Ф.Шафер, Линда И.Шафер. Вильямс, 2004г. Software Engineering Body of Knowledge (SWEBOK), IEEE, 2004. Project Management Body of Knowledge (PMBOK), PMI Standard Committee Software Risk Management, Ronald P.Higuera, Yacov Y.Haimes. Software Engineering Institute, Carnegie Mellon University, 1996.