WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 28 | 29 || 31 | 32 |   ...   | 33 |

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

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

Так, в исследовании «Хаос», проведенном Standish Group, приводятся результаты проектов разработки приложений:

• среднее превышение времени разработки — 222%;

• среднее превышение затрат на разработку — 189%;

• отставание в удовлетворении требований пользователя на месяцев.

В исследовании «Хаос» также сообщается, что лишь:

• 25% проектов внедрены успешно, • 28% проектов остановлены, • в 46% проектов возникли значительные проблемы с поставкой.

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

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

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

11.2.1. Риск и неопределенность Риск – это негативное событие вероятностного характера, отрицательно влияющее на исход проекта.

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

Например, «болезнь или увольнение менеджера проекта» – это риск, а «отсутствие опыта разработки у персонала» – это фактор.

11.2.2. Характеристики риска Первой характеристикой риска является вероятность того, что рисковое событие произойдет. Вероятности принято задавать числом от 0 до 1 или в процентах.

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

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

Существуют различные способы задания величины ущерба, наиболее простой и понятный – указать долю общего бюджета проекта, которая будет безвозвратно потеряна, если рисковое событие произойдет. В таком случае ущерб также можно задавать числом от 0 до 1 или в процентах.

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

Величина риска – это математическое ожидание ущерба.

Например, пусть вероятность рискового события «болезнь или увольнение менеджера проекта» составляет 10%, и ущерб также составляет 10%. Тогда величина риска составляет 1%. Пусть вероятность рискового события «потеря всех данных проекта» – 1%, а ущерб – 100%. Тогда величина риска также составляет 1%. Эти риски равны по величине. Если вероятность рискового события «недостаточные навыки программирования» равна 10%, а ущерб – 50%, то величина такого риска 5%, он существенно больше предыдущих.

Риски подразделяются на:

• устранимые, т.е. такие, которых с помощью специальных мер можно избежать или которые можно предотвратить;

• неустранимые, т.е. такие, повлиять на которые менеджер проекта не может.

Например, риск «потеря всех данных проекта» можно практически преодолеть, проводя резервное копирование всех данных каждый день и сохраняя резервные копии в сейфах трех разных банков. Риск «прекращение финансирования проекта в результате банкротства инвестора» менеджер проекта, как правило, предотвратить не может.

Различие между преодолением и предотвращением риска заключается в следующем:

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

• Предотвращение риска – это проведение мероприятий, в результате которых ущерб риска сводится к нулю.

В обоих случаях величина риска сводится к нулю, поэтому преодоление и предотвращение вместе называются устранением риска.

Например, риск «потеря всех данных проекта» можно преодолеть, проводя резервное копирование, а риск «болезнь или увольнение менеджера проекта» можно предотвратить, подготовив заранее и введя в курс дела еще одного резервного менеджера.

Для устранимых рисков очень важной характеристикой является стоимость мероприятий по преодолению или предотвращению риска.

Для единообразия стоимость устранения также можно задавать числом от 0 до 1 или в процентах. Например, стоимость преодоления риска «потеря всех данных проекта» можно оценить в 1%, а стоимость предотвращения риска «болезнь или увольнение менеджера проекта» более реалистично оценить в 5%.

11.2.3. Причины возникновения рисковых ситуаций Перечислим некоторые из наиболее типичных и важных причин, приводящих к возникновению рисковых ситуаций в проектах по разработке программного обеспечения. Это:

нереальная оценка требуемого времени реализации проекта и выделяемого бюджета;

нереальная оценка возможностей команды исполнителей;

недостаточное количество и квалификация команды исполнителей;

недостаточное владение исполнителями инструментарием разработки;

ошибки определения требований к разрабатываемому ПО (в т.ч. недостаточная детализация требований);

нарушения основных правил процессов разработки (например, нарушения в управлении версиями, приводящие к потере версий);

непрерывное изменение требований к разрабатываемому ПО по ходу проекта;

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

непрерывное изменение "правил игры" в команде исполнителей или группе проекта (правил коммуникации, распределения ответственности, распределения обязанностей);

ошибки проектирования архитектуры ПО;

ошибки разработки;

ошибки интеграции;

недостатки внешнего обслуживания;

технические и программные сбои;

злоумышленные действия сторонних лиц (например, "атаки" хакеров).

11.3. Порядок управления рисками программных проектов Существует множество моделей управления рисками проектов, в т.ч. проектов по разработке программного обеспечения. Все эти модели в значительной мере схожи между собой.

В редакции PMBOK – 2000, управление рисками это «систематические процессы, связанные с идентификацией, анализом рисков и принятием решений, которые обеспечивают минимизацию негативных последствий наступления рисковых событий и максимизацию вероятности и последствий наступления позитивных событий».

Рис. 1. Управление рисками по PMBOK Процесс управления рисками включает в себя • Планирование управления рисками – планирование деятельности по управлению рисками проекта, включая набор методов, средств и организации управления рисками.

• Идентификация факторов риска – определение рисков, способных повлиять на проект, и документирование их характеристик.

• Оценка рисков – качественный и количественный анализ рисков с целью определения их влияния на проект.

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

• Мониторинг и контроль риска – мониторинг наступления рисковых событий, определение новых рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков.

11.3.1. Основные модели управления рисками программных проектов Общие методы анализа рисков в сложных системах регламентированы стандартом ГОСТ Р 51901 — "Управление надежностью. Анализ риска технологических систем". Основной задачей стандарта является обоснование решений, касающихся анализа риска реализации проектов и технологий сложных систем. Хотя стандарт и не направлен исключительно на проекты разработки программного обеспечения, изложенные в нем рекомендации могут быть применены и в таких проектах.

Управление рисками в жизненном цикле программных проектов специально регламентировано международными стандартами ISO «Процессы жизненного цикла программных средств» и ISO «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем», которые целесообразно использовать при разработке комплексов программ. В стандарте ISO 15504 содержится специальный раздел "МАН.4. Процесс управления рисками", назначением которого является регламентирование и планирование процессов выявления и устранения рисков на протяжении всего жизненного цикла программного изделия.

Software Engineering Institute (SEI) разработал модель управления рисками при разработке программного обеспечения, частично вошедшую в PMBoK Guide 2000, включающую в себя как требования упомянутых стандартов, так и известные "хорошие практики" (best practices) управления рисками. Подготовку управления рисками проекта эта модель рекомендует проводить в следующей последовательности:

постановка целей управления рисками в соответствии с целями проекта;

планирование и координация работ по оценке рисков проекта (выделение группы экспертов для оценки рисков, подготовка и планированиие интервью с исполнителями с целью выявления рисков в результатах их деятельности);

идентификация и оценка рисков (обнаружение возможных рисковых ситуаций и оценивание влияния рисков на проект);

подготовка к устранению рисков (разработка мероприятий по сокращению или устранению рисков и подготовка отчета с рекомендациями для руководства проекта по анализу и управлению рисками);

разработка плана управления рисками, включающего • списки рисков по этапам или работам проекта, • методы, процессы и инструменты, применяемые для сокращения или устранения рисков, • организацию и распределение ответственности за управление рисками, а также за обеспечение допустимого уровня рисков проекта.

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

1. Идентификация рисков:

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

2. Анализ рисков (определение качественных, а лучше – количественных характеристик риска, ранжирование рисков по приоритетам).

3. Планирование ответов на риски – действий по уменьшению или устранению риска.

4. Отслеживание рисков – контроль текущих рисков, корректировка планов по снижению риска, и просмотр результатов выполненных мероприятий плана управления рисками.

5. Подготовка и реализация планов дальнейшего снижения и ликвидации рисков проекта.

11.3.2. Выявление, идентификация и анализ рисков Прежде, чем с риском можно что-то сделать, он должен быть идентифицирован.

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

Для обнаружения рисков необходим скептический склад ума.

Идентификация риска сродни проведению инспектирований – глобальному поиску дефектов в плане разработки. Для идентификации рисков полезно иметь контрольных списк (checklist, шаблон) рисков сходных проектов.

Специалистами по управлению рисками в результате исследований были предложены следующие глобальные категории рисков, характерные для самых простых проектов разработки программных продуктов:

Недостаточная вовлеченность в проект высшего руководства.

Невозможность привлечения реальных и адекватных пользователей.

Непонимание требований разработчиками.

Изменение области применения или целей проекта.

Нехватка знаний или навыков у персонала.

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

Каждый идентифицированный риск должен с радостью восприниматься командой проекта, так как в этом случае с ним можно начать что-то делать.

Настоящей проблемой являются риски, которые не удалось идентифицировать.

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

Менеджер проекта имеет дело с рисками, которые можно классифицировать следующим образом:

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

Pages:     | 1 |   ...   | 28 | 29 || 31 | 32 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.