Управление риском

Риск – это возможность опасности, неудачи.

Формула определения риска при создании ПО:

– вероятность неудовлетворительного результата

– потеря при неудовлетворительном результате

Управление риском включает 6 действий:

· Идентификация риска – выявление элементов риска в проекте

· Анализ риска – оценка вероятности и величины потери по каждому элементу риска

· Ранжирование риска – упорядочение элементов риска по степени их влияния

· Планирования управления риском – подготовка к работе с каждым элементом риска

· Разрешение риска – устранение или разрешение элементов риска

· Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий

Категории источников риска:

1. Проектный риск. Источники:

· Выбор бюджета, плана, человеческих ресурсов программного проекта.

· Формирование требований к программному продукту.

· Сложность, размер и структура программного проекта.

· Методика взаимодействия с заказчиком.

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

2. Технический риск. Источники:

· Трудности проектирования, реализация, формирования интерфейса, тестирования и сопровождения.

· Неточность спецификаций (неточность технических заданий для программистов и пр.)

· Техническая неопределённость или отсталость принятого решения (когда проект основан на предыдущей технологии, которая уже отходит; очень много фирм потеряли деньги, не заметив появления Android и продолжая создание ПО для предыдущих мобильных ОС).

3. Коммерческий риск. Очень редко зависит от программистов, чаще зависит от менеджеров.

· Создание продукта, не требующегося на рынке (такое бывает, когда проект создаётся не по заказу, а предпринимается попытка опередить требования, ложное чутьё).

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

· Потеря финансирования.

Для определения рисков составляется проверочный список из 10 самых главных элементов программного риска:

1. Дефицит персонала

2. Нереальное расписание и бюджет

3. Разработка неправильных функций и характеристик

4. Разработка неправильного пользовательского интерфейса

5. Слишком дорогое обрамление

6. Интенсивный поток изменений требований

7. Дефицит поставляемых компонентов

8. Недостатки в задачах, разрабатываемых смежниками (при аутсорсинге)

9. Дефицит производительности при работе в реальном времени

10. Деформирование научных возможностей (применение неверных научных теорий или недостаток верных).

Принцип Парето “80/20” для ранжирования рисков: 80% всего проектного риска приходятся на долю 20% от общего количества элементов риска. Т. е. при ранжировании рисков мы выясняем, какие риски нужно отслеживать внимательнее, какие – нет.