Факультет информационных технологий
Скачать 225.74 Kb.
|
| НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ____________________________________________________________________________________________________________________ Экономика и управление программными проектами Управление рисками программных проектов. Студент группы 12226 Альперин Борис Новосибирск, 2013 СодержаниеВведение 3 Основные понятия 3 Категории рисков 4 Цель управления рисками 4 Планирование управления рисками 4 Идентификация рисков 6 Сбор информации о рисках 7 Контрольные списки рисков 8 Качественный анализ рисков 9 Количественный анализ рисков 10 Планирование реагирования на риски 10 Основные риски и способы реагирования 11 Риски, связанные с требованиями 12 Технологические риски 13 Риски, связанные с квалификацией 13 Политические риски 13 Мониторинг и контроль рисков 14 Заключение 14 Литература 16 ВведениеУправление рисками является одним из важнейших этапов любого программного проекта. Риски так или иначе присутствуют во всех программных проектах (например, риск того, что основного разработчика переедет грузовик), и игнорировать риски – дело проигрышное. Риски и выгоды всегда ходят рука об руку. Компании, избегающие рисков и концентрирующие усилия только на том, что наверняка умеют делать хорошо, подготавливают благодатную почву для своих конкурентов. Проект полон рисков потому, что он протаптывает новые, нехоженые тропы. Он может расширить возможности так, что конкурентам будет уже нечем ответить. Большие риски приносят и большие выгоды, особенно в разработке программного обеспечения. В реферате показано, как идентифицировать, управлять и наблюдать за рисками, какие бывают риски, а также способы реагирования. Грамотное управление рисками:
Основные понятияВ PMBOOK[1] дается такое определение риска: «Риск - неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта». В силу специфики отрасли, программная инженерия остается и, в ближайшем будущем, будет оставаться производством с высоким уровнем рисков. Разница между риском и проблемой состоит в том, что риск - это проблема, которая еще не возникла, а проблема - это материализовавшийся риск. Риск имеет следующие характеристики:
Риск всегда характеризуется вероятностью наступления и последствиями. Например, всегда есть вероятность того, что метеорит упадет на офис компании-разработчика ПО, и это будет иметь катастрофические последствия для проекта. Однако вероятность наступления этого события настолько мала, что большинстве проектов этот риск принимается, и им не пытаются управлять. Категории рисковВыделяют две категории рисков:
Неизвестные риски - это непредвиденные обстоятельства. Единственное, что можно предпринять в этом случае - это создать управленческий резерв бюджета проекта на случай незапланированных, но потенциально возможных изменений. На расходование этого резерва менеджер проекта, как правило, обязан получать одобрение вышестоящего руководства. Управленческие резервы на непредвиденные обстоятельства не входят в базовый план по стоимости проекта, но включаются в бюджет проекта. Они не распределяются по проекту, как бюджет, и поэтому не учитываются при расчете освоенного объема. Цель управления рискамиДевиз разработчиков ПО из Microsoft: «Мы не боремся с рисками - мы ими управляем». Цели управления рисками проекта - снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий. Адекватное управление рисками в компании – признак зрелости производственных процессов. В [2] процесс управления рисками характеризуется так: «Рассматривать только благоприятные сценарии и встраивать их в план проекта – настоящее ребячество. И все же мы постоянно так поступаем. …Если тех, кто говорит о возможных проблемах до открытия проекта, называют troublemakers, а тех, кто сдает проект спустя 2 месяца после обещанного срока, работая при этом по 60-80 часов в неделю, – героями, то у вас плохая команда». Отказываться от управления проектными рисками это все равно, что в кинотеатре не иметь огнетушителей и плана эвакуации на случай пожара. Планирование управления рискамиУправление рисками - это определенная деятельность, которая выполняется в проекте от его начала до завершения. Как и любая другая работа в проекте, управление рисками требует времени и затрат ресурсов. Поэтому эта работа обязательно должна планироваться. Планирование управления рисками – это процесс определения подходов и планирования операций по управлению рисками проекта. Тщательное и подробное планирование управления рисками позволяет:
Планирование управления рисками должен быть завершено на ранней стадии планирования проекта, поскольку оно крайне важно для успешного выполнения других процессов. Исходными данными для планирования управления рисками служат:
План управления рисками обычно включает в себя следующие элементы:
Рисунок 1. Иерархическая классификация рисков проекта Шкала оценки воздействия отражает значимость риска (таблица 1) в случае его возникновения. Шкала оценки воздействия может различаться в зависимости от потенциально затронутой риском цели, типа и размера проекта, принятыми в организации стратегиями и его финансовым состоянием, а также от чувствительности организации к конкретному виду воздействий.
Таблица 1. Пример шкалы оценки воздействий рисков Хотя риск может воздействовать и на сроки проекта, и на качество получаемого продукта, но все эти отклонения могут быть оценены в денежном эквиваленте. Например, последствия задержка по срокам для заказной разработки может быть выражена в сумме денежных санкций, определенных в контракте. Для оценки вероятности наступления риска может быть применена похожая шкала (таблица 2).
Таблица 2. Пример шкалы оценки вероятности осуществления риска. Еще одной важной характеристикой риска является близость его наступления. Естественно, что при прочих равных условиях рискам, которые могут осуществиться уже завтра, следует сегодня уделять больше внимания, чем тем, которые могут произойти не ранее, чем через полгода. Для шкалы оценки близости риска может быть применена, например, следующая градация: очень скоро, не очень скоро, очень нескоро. Идентификация рисковИдентификация рисков – это выявление рисков, способных повлиять на проект, и документальное оформление их характеристик. Это итеративный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться новые риски. Исходные данные для выявления и описания характеристик рисков могут браться из разных источников. В первую очередь это информация о проблемах и рисках из предыдущих проектах в организации. Следует помнить, что проблемы завершенных и выполняемых проектов, это, как правило, риски в новых проектах. Другим источником данных о рисках проекта может служить разнообразная информация из открытых источников, научных работ, маркетинговая аналитика и другие исследовательские работы в данной области. Наконец, многие форумы по программированию могут дать бесценную информацию о возникших ранее проблемах в похожих проектах. Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев и допущений. Как правило, в описании содержания проекта перечисляются принятые допущения - факторы, которые для целей планирования считаются верными, реальными или определенными без привлечения доказательств. Неопределенность в допущениях проекта следует также обязательно рассматривать в качестве потенциального источника возникновения рисков проекта. Анализ допущения позволяет идентифицировать риски проекта, происходящие от неточности, несовместимости или неполноты допущений. Сбор информации о рискахДля сбора информации о рисках могут применяться различные подходы. Среди этих подходов наиболее распространены:
Цель опроса экспертов – идентифицировать и оценить риски с помощью опроса подходящих квалифицированных специалистов. Специалисты высказывают своё мнение о рисках и дают им оценку, исходя из своих знаний, опыта и имеющейся информации. Этот метод может помочь избежать повторного наступления на одни и те же грабли. Перед опросом эксперт должен получить всю необходимую вводную информацию. Деятельность экспертов необходимо направлять, задавая вопросы. Во время опроса вся информация, выдаваемая экспертом, должна записываться и сохраняться. При работе с несколькими экспертами выходная информация обобщается и доводится до сведения всех задействованных экспертов. К участию в мозговом штурме привлекаются квалифицированные специалисты, которым дают «домашнее задание» - подготовить свои суждения по определенной категории рисков. Затем проводится общее собрание, на котором специалисты по очереди высказывают свои мнения о рисках. Важно: споры и замечания не допускаются, что позволяет отделить процесс генерации идей от их последующей фильтрации. Таким образом, возможно описание более полной картины рисков. Все отобранные риски записываются, группируются по типам и характеристикам, каждому риску дается определение. Цель мозгового штурма – составить первичный перечень возможных рисков для последующего отбора и анализа. Метод Дельфи во многом похож на метод мозгового штурма. Однако есть важные отличия. Во-первых, при применении этого метода эксперты участвуют в опросе анонимно. Поэтому результат характеризуется меньшей субъективностью, меньшей предвзятостью и меньшим влиянием отдельных экспертов. Во-вторых, опрос экспертов проводится в несколько этапов. На каждом этапе модератор рассылает анкеты, собирает и обрабатывает ответы. Результаты опроса рассылаются экспертам снова для уточнения их мнений и оценок. Такой подход позволяет достичь некоего общего мнения специалистов о рисках. Для быстрого выявления рисков можно воспользоваться еще одной из методик социометрии является известной как "Карточки Кроуфорда" [3]. Суть этой методики в следующем: собирается группа экспертов 7-10 человек. Каждому участнику раздается по десять карточек. Ведущий задает вопрос: "Какой риск является наиболее важным в этом проекте?" Все респонденты должны записать наиболее, по их мнению, важный риск в данном проекте. При этом никакого обмена мнениями не должно быть. Ведущий делает небольшую паузу, после чего вопрос повторяется. Участник не может повторять в ответе один и тот же риск. После того как вопрос прозвучит десять раз, в распоряжении ведущего появятся от 70 до 100 карточек с ответами. Если группа подобрана хорошо (в том смысле, что в нее входят люди с различными точками зрения), вероятность того, что участники эксперимента укажут большинство значимых для проекта рисков, весьма высока. Остается составить список названных рисков и раздать его участникам для внесения изменений и дополнений. Контрольные списки рисковВ качестве источника информации при выявлении рисков могут служить различные доступные контрольные списки рисков проектов разработки ПО, которые следует проанализировать на применимость к данному конкретному проекту. Например, Б.Боэм [4] приводит список 10 наиболее распространенных рисков программного проекта:
Демарко и Листер приводят свой список из пяти наиболее важных источников рисков любого проекта разработки ПО:
Не существует исчерпывающих контрольных списков рисков программного проекта, поэтому необходимо внимательно анализировать особенности каждого конкретного проекта. Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик: причины, условия, последствий и ущерба. За процессом идентификации рисков следует процесс их качественного анализа. Качественный анализ рисковКачественный анализ рисков включает в себя расстановку рангов для идентифицированных рисков. При анализе вероятности и влияния предполагается, что никаких мер по предупреждению рисков не производится. Качественный анализ рисков включает:
Ранг риска определяется произведением веса вероятности и значимости последствий. Для оценки рисков необходима точная и адекватная информация. Использование неточной информации ведет к ошибкам в оценке. Неверная оценка риска также является риском. Критерии оценки качества используемой при анализе информации выглядят следующим образом:
Результатом качественного анализа рисков является их подробное описание (таблица 3)
Таблица 3. Пример описания риска Результаты качественного анализа используются в ходе последующего количественного анализа рисков и планирования реагирования на риски. Количественный анализ рисковКоличественный анализ производится в отношении тех рисков, которые в процессе качественного анализа были квалифицированы как имеющие высокий и средний ранг. Для количественного анализа рисков могут быть использованы следующие методы:
Анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным влиянием на проект. В процессе анализа устанавливается, в какой степени неопределенность каждого элемента проекта отражается на исследуемой цели проекта, если остальные неопределенные элементы принимают базовые значения. Дерево решений описывает рассматриваемую ситуацию с учетом каждой возможности выбора и последующего сценария событий. Дуги дерева помечаются вероятностями и затратами при развитии событий по тому или иному сценарию Критерием для принятия решения служит математическое ожидание потерь для этого решения. При моделировании рисков проекта используется модель для определения последствий от воздействия подробно описанных неопределенностей на результаты проекта в целом. Моделирование обычно проводится с помощью метода Монте-Карло. Интересный пример подобной модели - система Riskology от Демарко и Листера, который иллюстрирует применение метода Монте-Карло для получения информации о том, какой запас времени будет необходим для того, чтобы преодолеть влияние всех неуправляемых рисков проекта. Планирование реагирования на рискиПланирование реагирования на риски – это процесс разработки путей и определения действий по увеличению возможностей и снижению угроз для целей проекта. Данный процесс начинается после проведения качественного и количественного анализа рисков. Запланированные операции по реагированию на риски должны соответствовать серьезности риска, быть экономически эффективными в решении проблемы, своевременными, реалистичными в контексте проекта и согласованными со всеми участниками. Возможно четыре метода реагирования на риски:
Уклонение от риска предполагает изменение плана управления проектом таким образом, чтобы исключить угрозу, вызванную негативным риском, оградить цели проекта от последствий риска или ослабить цели, находящиеся под угрозой (например, уменьшить содержание проекта). Некоторые риски, возникающие на ранних стадиях проекта, можно избежать при помощи уточнения требований, получения дополнительной информации или проведения экспертизы. Например, уклониться от риска можно, если отказаться от реализации рискованного функционального требования или самостоятельно разработать необходимый программный компонент, вместо ожидания поставок продукта от субподрядчика. Передача риска подразумевает переложение негативных последствий угрозы с ответственностью за реагирование на риск на третью сторону. Передача риска просто переносит ответственность за его управление другой стороне, но риск при этом никуда не девается. Передача риска практически всегда предполагает выплату премии за риск стороне, принимающей на себя риск. Например, заказ на стороне разработки рискованного компонента по фиксированной цене. В IT часто приходится формулировать риски в виде допущений, тем самым передавая его заказчику. Например, оценивая проект внедрения, можно сделать допущение о том, что производитель не изменит стоимость лицензий на базовое ПО. Снижение рисков предполагает понижение вероятности или последствий негативного рискованного события до приемлемых пределов. Принятие предупредительных мер по снижению вероятности наступления риска или его последствий часто оказываются более эффективными, нежели усилия по устранению негативных последствий, предпринимаемые после наступления события риска. Например, раннее разрешение архитектурных рисков снижает потери при досрочном закрытии проекта. Или регулярная ревизия поставок заказчиком может снизить вероятность риска его неудовлетворенности конечным результатом. Если в проектной команде высока вероятность увольнения сотрудников, то введение на начальной стадии в проект дополнительных (избыточных) людских ресурсов снижает потери при увольнении членов команды, поскольку не будет затрат на обучение новых участников. И, наконец, принятие риска означает, что команда проекта осознанно приняла решение не изменять план управления проектом в связи с риском или не нашла подходящей стратегии реагирования. Мы вынуждены принимать все «неизвестные риски». Принятие - это то, что происходит, когда мы вообще не управляем рисками. Если же мы управляем рисками, то мы можем страховать риски, закладывая резерв в оценки срока завершения и трудозатрат. Основные риски и способы реагированияСогласно [5], риски программных проектов можно разделить на четыре основные категории:
Риски, связанные с требованиямиПроцесс разработки программного обеспечения начинается с определения требований и вариантов использования системы. Основная проблема заключается в том, что некоторые ключевые требования, которые требуются для реализации системы могут быть пропущены, поскольку пользователи могут посчитать их настолько очевидными, что не их даже не нужно упоминать. Другие требования не так поняты разработчиками. В итого создаваемая система будет выполнять не то, что хотели пользователи. К часто упускаемым требованиям можно отнести:
Как правило, эти требования «всплывают» при подготовке и проведении приемо-сдаточных испытаний и могут сильно задержать проект по времени и увеличить трудозатраты на его реализацию. Чтобы этого не происходило, следует достигать соглашения с заказчиком по всем перечисленным пунктам предпочтительнее еще на стадии инициации проекта. Например, если требования портируемости продукта на разные аппаратно-программные платформы нет, то это целесообразно включить в раздел концепции с допущениями проекта. Если вероятность изменений требований проекта высока, то возможны следующие подходы для реагирования на данный риск:
Если в проекте недостаточно квалифицированных специалистов, то можно снизить последствия этого риска, применив следующие действия:
При планировании работ по проекту часто «забывают»:
Технологические рискиЭта группа рисков объединяет риски, связанные с используемыми технологиями. Риски зависят от того, какие технологии вы планируете применить, используются ли в компании выбранные средства, насколько эти технологии отработаны или это "только что испеченные пирожки". Наилучший вариант оценить технологические риски - это создать прототип для проверки новых технологий. Риски, связанные с квалификациейХотя этой группе рисков обычно уделяют мало внимания, когда как она не менее важна, чем остальные. Насколько сотрудники, которые участвуют в проекте, опытны в применяемых технологиях? Есть ли опыт ведения аналогичных проектов, достаточен ли опыт менеджера проекта? Проект не могут спасти гении-одиночки, если основная масса участников проекта - дилетанты. Если программисты не разбираются в UML диаграммах, а аналитики только их и создают, то проект можно даже не начинать. Руководитель проекта должен оценить риски и организовать обучение еще до начала проекта, чтобы не терять время на ошибки в будущем. Опытные наставники уже знают, как обойти большинство ошибок, которые встречаются на пути разработчики, поэтому их опыт позволит сэкономить значительные средства, даже если это не очевидно. Политические рискиЭто очень опасная группа рисков, которая с высокой вероятностью может привести к краху проекта даже если все другие "подводные камни" будут обойдены. Каждый человек имеет свои цели деятельности, которые не всегда совпадают с целями руководителя проекта. Саботаж, обычно не выставляемый напоказ, может загубить любой проект. Если руководитель структурного подразделения в непосредственном подчинении которого находится участник проекта не считает нужным выделять время своего подчиненного на конкретные работы в проекте, то это очень большой риск. Сотрудники компаний, руководители больших и малых подразделений часто ведут тонкую политическую игру, целью которой может быть продвижение по служебной лестнице и получение максимальной возможной власти. Эти действия весьма далеки от целей конкретного проекта, поэтому тихое противодействие отдельных сотрудников или неформальных групп может свести на нет все усилия менеджера проекта. Например, в одном проекте наблюдалось открытое противостояние внедрению новой программной системы со стороны главного бухгалтера, что привело к многим неприятным последствиям. Для разрешения этой группы рисков необходима в первую очередь поддержка руководства. Затем, если участники проекта частично заняты своими основными обязанностями и у них есть собственный руководитель, то насчет проведения работ по проекту необходимо решать вопрос именно с руководителем. Менеджер проекта должен решить, что и к какому сроку нужно сделать, а руководитель подразделения должен решить кто это будет делать и когда. Мониторинг и контроль рисковУправление рисками должно осуществляться на протяжении всего проекта. Не вести мониторинг рисков в ходе проекта – все равно, что не следить за уровнем топлива при поездке на автомобиле. Мониторинг и управление рисками – это процесс идентификации, анализа и планирования реагирования на новые риски, отслеживания ранее идентифицированных рисков, а также проверки, исполнения операций реагирования на риски и оценка эффективности этих операций. В процессе мониторинга и управления рисками используются различные методики, например, анализ трендов и отклонений, для выполнения которых необходимы количественные данные об исполнении, собранные в процессе выполнения проекта. Мониторинг и управление рисками включает в себя следующие задачи:
Пересмотр рисков должен проводиться регулярно, согласно расписанию. Управление рисками проекта должно быть одним из пунктов повестки дня всех совещаний команды проекта. Неплохо начинать каждое совещание с вопроса: «Ну и какие еще неприятности нас ожидают?» Аудит рисков предполагает изучение и предоставление в документальном виде результатов оценки эффективности мероприятий по реагированию на риски, относящихся к идентифицированным рискам, изучение основных причин их возникновения, а также оценку эффективности процесса управления рисками. Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта могут использоваться анализ освоенного объема и другие методы анализа отклонений проекта и трендов. На основании результата анализа можно прогнозировать потенциальные отклонения проекта на момент его завершения по показателям стоимости и расписания. Отклонения от базового плана могут указывать на последствия, вызванные как угрозами, так и благоприятными возможностями. ЗаключениеУправление рисками – одна из основных деятельностей при управлении программным проектом. Отказываться от управления рисками в проекте равнозначно не иметь огнетушителей и плана эвакуации на случай пожара. Цели управления рисками проекта - снижение вероятности возникновения и значимости воздействия неблагоприятных для проекта событий. Адекватное управление рисками в компании – признак зрелости производственных процессов. Риски тесно связаны с выгодой от проекта – проект без рисков может быть успешным, но он «подготавливает благодатную почву для конкурентов». Наоборот, проект полон рисков потому, что он ведет вас нехожеными тропами. Он может расширить возможности так, что конкурентам будет уже нечем ответить. Большие риски приносят и большие выгоды, особенно в разработке программного обеспечения. Грамотное управление рисками является залогом успешного завершения проекта. Оно позволяет:
Литература
|
Добавить документ в свой блог или на сайт
Похожие:
 | Факультет информационных технологий утверждаю Рабочая программа предназначена для бакалавров кафедр Информатики и математики и Информационных технологий как очной, так и заочной... | | Факультет информационных технологий утверждаю Рабочая программа предназначена для бакалавров кафедр Информатики и математики и Информационных технологий как очной, так и заочной... |
| «московский психолого-социальный университет» факультет информационных технологий утверждаю Рабочая программа предназначена для бакалавров кафедр Информатики и математики и Информационных технологий очной и заочной формы... | | Факультет информационный технологий утверждаю Рабочая программа предназначена для бакалавров кафедр Информатики и математики и Информационных технологий очной и заочной формы... |
| Факультет информационных технологий утверждаю Ефимов Павел Павлович, кандидат педагогических наук, кафедра "Информационных технологий", для студентов 4,5-го курсов, обучающихся... | | Применение информационных технологий в системе образования Понятие информационных технологий. Роль средств новых информационных технологий в образовании 10 |
| Российской Федерации Самарский государственный архитектурно-строительный... Системный анализ – новая, находящаяся в стадии формирования наука о закономерностях развития сложных естественных и искусственных... | | Вероника Игоревна Использование информационных технологий в гуманитарных... Мвц межвузовский центр новых информационных технологий в гуманитарном образовании |
 | Применение технологий olap и Data Mining для поддержки принятия стратегических решений в вузе Дагестанский государственный университет, факультет информатики и информационных технологий, Махачкала, Россия | | Ноу впо институт государственного управления, права и инновационных... Введение. Алгоритм. Программа. Язык программирования Паскаль. Техника безопасности |
| Факультет информационных технологий Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования | | Применение информационных технологий на уроках английского языка... Возможности использования информационно-коммуникативных технологий в обучении английскому языку 17 |
| Факультет информационных систем и технологий Методическая разработка рекомендована для педагогов дополнительного образования детей | | Выпускная работа по «Основам информационных технологий» Реферат: «Применение информационных технологий в исследовании и описании безэквивалентной лексики» 6 |
| Выпускная работа по «Основам информационных технологий» Место и роль информационных технологий при формировании туристического продукта 6 | | Выпускная работа по «Основам информационных технологий» Использование информационных технологий в преподавании русского языка как иностранного |
