Понятие риска в программных проектах

Риск программного проекта – это те причины, из-за которых проект может быть неуспешным. Это могут быть технические риски, проектные риски, экономические риски.

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

Риски могут угрожать проекту в целом, создаваемому программному продукту или организации-разработчику. Можно выделить три типа рисков.

 

1. Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта.

2. Риски для разрабатываемого продукта, влияющие на качество или производительность разрабатываемого программного продукта.

3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам.

 

Конечно, эти типы рисков могут пересекаться. Например, если опытный программист покидает проект, это будет риском для проекта (поскольку задерживается срок сдачи готового продукта), риском для продукта (так как новый программист, заменивший ушедшего, может оказаться не слишком опытным и сделать ошибки в программе) и бизнес-риском (поскольку задержка данного проекта может негативно повлиять на будущие деловые контакты между заказчиком и организацией-разработчиком).

Схемапроцесса управления рисками показана на рис. 1. Этот процесс состоит из четырех стадий.

 

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

2. Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций.

3. Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.

4. Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций.

 

Рис. 1. Процесс управления рисками

Определение рисков

 

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

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

 

1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.

2. Риски, связанные с персоналом. Связаны с членами команды разработчиков.

3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.

4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.

5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.

6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.

1. Анализ риска

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

 

1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.

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

Разрешение риска

Планирование рисков

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

Существует три категории стратегий управления рисками.

 

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

2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков (см. табл. 4).

3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 4 это стратегия поведения при возникновении финансовых проблем у организации-разработчика.

Наблюдение за риском

Мониторинг рисков

 

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

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

Наблюдение за риском

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

Таблица 5. Признаки рисков

 

Тип риска	Признаки
Технологические риски	Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документированные технологические проблемы
Риски, связанные с персоналом	Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выполненной работы
Организационные риски	Разговоры среди персонала о пассивности и недостаточной компетентности высшего руководства организации
Инструментальные риски	Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства
Риски, связанные с системными требованиями	Необходимость пересмотра многих системных требований, недовольство заказчика ПО
Риски оценивания	Изменения графика работ, многочисленные отчеты о нарушении графика работ

 

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

Характеристики дефектов

 

Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.

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

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

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

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

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

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

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

- рассчитывать необходимую эффективность контрмер и дополнительных средств оперативной защиты от потенциальных дефектов и не выявленных ошибок;

- оценивать требующиеся ресурсы ЭВМ по расширению памяти и производительности, с учетом затрат на реализацию контрмер при модификации и устранении ошибок и рисков.

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

Идентификатор дефекта.

ИДЕНТИФИКАЦИЯ ДЕФЕКТА – распознавание дефекта и оценка
его значимости в пределах системы.

Проект дефекта

 

Срочность дефекта

 

Категория дефекта

Серьезность дефекта

Автор дефекта