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

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

Риск (по определению SEI (Software Engineering Institute)) - это возможность понести потери.

Риск проекта ПО - это возможность:

1) снижения качества конечного продукта,

2) повышения стоимости его разработки,

3) задержки окончания разработки или срыва проекта (то есть, отказа от проекта).

Риски могут быть “известные” – те, которые определены, оценены, для которых возможно планирование. Риски “неизвестные” – те, которые не идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть.

На самом верхнем уровне можно выделить три основные группы:

• риск проектирования;

• технический риск;

• бизнес-риск (деловой риск).

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

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

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

Можно предложить также следующую категоризацию рисков:

• риски связанные с требованиями;

• технологические риски;

• риски связанные с квалификацией персонала;

• политические риски.

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

Риски связанные с требованиями

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

Это происходит из-за того, что группа людей, которые заказывают программную системы и та группа людей, которая делает её, не совпадают друг с другом. То, что одни считают очевидным, другие вообще не знают. Для одних некоторая деталь системы является лишь мелкой технической проблемой, другие же считают её ключевой в проекте. Между разработчиком и заказчиком возникает прослойка, которая состоит в перепаде уровней знаний и методов. Заказчик, из-за отсутствия у него опыта разработчиков, даже может не знать о некоторых свойствах системы, которые ему обязательно понадобятся.

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

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