Microsoft Solutions Framework Официальное издание Белая книга



страница6/17
Дата17.10.2016
Размер0,74 Mb.
1   2   3   4   5   6   7   8   9   ...   17

Цели


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

Исходные данные


Исходными данными фазы выявления рисков являются имеющиеся знания как об общих, так и о специфических для данного проекта рисках, из областей связанных с бизнесаом, технологиитехнологиями, менеджментаорганизациями, и внешнейвнешнихми средыусловийями. Дополнительные факторы, которым должно быть уделено внимание: имеющийся у команды опыт, применяемые внутри организации подходы к рискам, выраженные в виде правил и существующих нормативных актахинструкций, а также вся информация о проекте, известная на текущий данный момент, включая его историю и текущее состояние положение дел. Проектная группа может также использовать любые другие источники – внимание должно быть уделено всемуиспользованозадействовано все, что может помочь выявлению рисков. На начальном этапе проекта с целью выявления рисков полезно проводить коллективный мозговоймозговые штурмы, неформальные дискуссии или даже формальные семинары с участием различных заинтересованных сторон лиц для ознакомления с их видением взглядами на рискови и открываемыхе проектом возможностейи. Также могут оказаться полезными отраслевые схемы классификации рисков, такие как таксономия рисков SEI,9, проектные перечничеклисты (checklists),10, сводки сводные отчетовы о о предшествующих проектах и другие опубликованные источники и отраслевые руководства.

// Тут будет картинка

  1. Выявление рисков

Шаги по выявлению рисков


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

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



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

Структурированный подход


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

Классификация рисков


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

Люди

ПотребителиЗаказчики (customers)

Конечные потребителипользователи (конечные пользователи, end users)

Спонсоры

Заинтересованные стороны

КадрыПерсонал

Организация

Профессиональная квалификация

Политика

Мораль

Процессы

Цели и задачи

Принятие решений

Характеристики проекта

Бюджет, затраты, временные ограничениясроки

Требования (requirements)

Проектирование (design)

ПостроениеРеализация (building)

Тестирование (testing)

Технологиия

Безопасность

Среда разработки и тестирования

Инструментарий

Внедрение

Сопровождение

Операционная среда

Доступность

Внешние условия

Законодательство

Нормативные актыИндустриальные стандарты

Конкуренция

Экономические условия

Технология

Бизнес-условия

Существует множество классификаций общих рисков проектов по разработке программного обеспечения. Хорошо известны и часто цитируются Barry Boehm11, Caper Jones12, и SEI Software Risk Taxonomy13, описывающие источники таких рисков.

Также имеются детализованные списки областей рисков, покрывающихпокрывающие определенное количество составляющих проекта, представленные с большей детализацией. Риски календарного планирования – это одна из всеобщих областей рисков, с которой сталкиваются все проектные группы. Исчерпывающий обзор таких рисков, затрагивающих проекты в области разработки программного обеспечения, был составлен Steve McConnel.14

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

Прочие источники информации о рисках проектов включают в себя базы данных рисков индустриальных проектов, такие как Software Engineering Information Repository (SEIR)17, и внутренние корпоративные базы знаний по рискамх, составляемые в рамках предприятия.




Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   17


База данных защищена авторским правом ©grazit.ru 2017
обратиться к администрации

    Главная страница