Планирование рисков
Номер по WBS |
Событие риска |
Вероят-ность |
Воздей- |
Общий риск |
Ответные стратегии |
ствие |
|
||||
|
|
|
|
|
|
1.01.01 |
Недостаточный анализ задач приводит |
Средняя |
Высокое |
Высокий |
Использовать JAD для |
|
к проблемам в интерфейсе |
|
|
|
выявле-ния исходных |
|
пользователя |
|
|
|
требований |
|
|
|
|
|
|
1.03.04.02 |
Тесты для требуемых открытых |
Низкая |
Задержка 4 |
Высокий |
Применить анна-лиз задач |
|
системных стандартов недоступны |
|
недели |
|
для по-нимания пользо- |
|
|
|
|
|
вательской среды |
|
|
|
|
|
|
2.01.03.03 |
Реализация новой версии 2.5 |
Средняя |
$50K + 1 |
Средний |
Создать прототип |
|
операционной системы |
|
неделя |
|
|
|
|
|
|
|
|
2.04.05 |
Недостаточное время для исполнения |
Высокая |
Отказ |
Средний |
Использовать доступное |
|
теста по системной интеграции |
|
заказчика – 2 |
|
сверхурочное время |
|
|
|
месяца |
|
|
|
|
|
|
|
|
3.02.17.03 |
Использование новой методики |
вероят-ность |
$10K + 2 |
Низкий |
Разработать |
|
разработки замедлит график работ |
25% |
недели на |
|
альтернативный график |
|
|
|
обучение |
|
для некоторых |
|
|
|
|
|
деятельностей |
|
|
|
|
|
|
СПИИ РАН |
42 |
Исполнение ответных стратегий
Исполнить выбранные стратегии – это немедленно реализовать те ответные стратегии на риски, которые снижают вероятность наступления рискового события, и реализовывать ответные стратегии при наступлении рисковых событий, в соответствии с выработанными планами. Входными данными для этого шага являются данные, поступающие с ходом проекта в соответствии с его планом, и ответные стратегии, выработанные на предыдущем шаге. Необходимые стратегии отрабатываются и по результатам их исполнения вносятся необходимые коррективы в план управления рисками, возможно, влияющие на дальнейший ход проекта. Результатом является возможно пересмотренный план действий от текущего момента до конца проекта.
Входными данными для этого шага служат проектный план и план управления рисками, проектные ресурсы, информация о рисковых событиях, стоимость, график и технические данные, связанные с проектом, инструментом – сами рисковые стратегии, которые отрабатываются как часть исполнения проекта. При возможности выбора очередности в исполнении первыми реализуются стратегии, нацеленные на снижение вероятности риска или его воздействия, или на уклонение от риска, затем отрабатываются и другие стратегии по мере актуализации рисковых событий. При этом надо обязательно информировать членов группы и других заинтересованных лиц о состоянии плана по рискам и документировать все рисковые события и предпринятые по ним ответные действия. В историческом разрезе очень полезно создать и регулярно обновлять файл «усвоенных уроков» (lessons learnt).
СПИИ РАН |
43 |
Исполнение ответных стратегий
Цель постоянного наблюдения за рисковыми событиями – предотвратить их наступление и предпринять действия быстрого реагирования, если рисковое событие все же наступит. Причинами, вызывающими необходимость такого постоянного наблюдения являются постоянные изменения в проекте, затрагивающие его кадры, среду, организацию, требования заказчика, технический прогресс и использование ресурсов.
Методики, ориентированные на продукт, используют метрики продукта, нацеленные на причинно-следственный анализ его надежности до исполнения в дополнение к надежности во время исполнения. Этими метриками являются:
Ошибки, дефекты и сбои: число дефектов, вызванных человеческим фактором, ошибками в программе, наблюдаемым неправильным функционированием.
Среднее время между сбоями и частота сбоев: производные метрики по дефектам и времени их наступления.
Рост и проекция надежности: оценка изменений в отсутствии сбоев при тестировании и эксплуатации.
Остаточные дефекты в продукте: оценка отсутствия сбоев при разработке, тестировании и сопровождении.
Полнота и согласованность: оценка присутствия и согласованности всех необходимых программных частей.
Сложность: оценка усложняющих факторов в системе.
СПИИ РАН |
44 |
Исполнение ответных стратегий
Стандарт IEEE Standard Dictionary of Measures to Produce Reliable Software (IEEE Std 982.1-1988) перечисляет 39 методик для наблюдения за рисками, из которых можно выбирать наиболее подходящие для каждого данного случая.
Известный подход Боэма «Первые 10» суммирует все вышесказанное в следующих действиях:
1.Выявить 10 самых серьезных рисков в проекте. 2.Разработать план по разрешению каждого риска.
3.Ежемесячно обновлять список этих рисков, планов и результатов.
4.На ежемесячных обзорах проекта сообщать о состоянии самых серьезных рисков – сравнивать их состояние и ранги с аналогичными данными за предыдущий месяц.
5.Запускать соответствующие поправочные действия при необходимости.
СПИИ РАН |
45 |
Заключительное оценивание рисков
В зависимости от качества оценивания рисков, могут создаваться или сокращаться будущие риски в новых проектах, меняться в ту или иную сторону образ и репутация данной организации-разработчика. Такая работа способствует созданию возможностей на будущее через возможные усовершенствования в контракте, позиционирование данной организации как разработчика и улучшение связи с общественностью (public relations).
Выявленные в результате такого оценивания типы рисков и рисковых событий уточняют сами риски и могут относиться к следующим категориям:
деловые риски – несут вероятность как выигрыша, так и потерь – это нормальные риски ведения дела;
чистые риски – несут вероятность только потерь – часто могут быть застрахованы страховыми компаниями;
внешние события – вне контроля или влияния со стороны разработчиков:непредсказуемые – регуляторные, природные катаклизмы, окружающая среда,
общественный интерес;предсказуемые – колебания рынка, валют, инфляция, налогообложение;
внутренние события – в рамках контроля или влияния разработчиков:
финансовые – затраты на запуск, бюджет заказчика, точность требований, ценовая политика, время выхода на рынок, тип контракта, движение наличности;
по графику – ползучие требования, кадры, реалистичность, доступность оборудования и технологий, трудности запуска, каскадные задержки, неадекватное планирование;
технические – экспертиза, зрелость технологии, размер и сложность, требования интеграции/ инсталляции, настройка на потребителя, сопровождение;
юридические – неоднозначность в контракте, невозможность выполнить, право копирования, торговые секреты, патенты, лицензии.
СПИИ РАН |
46 |
Заключительное оценивание рисков
СПИИ РАН |
47 |
Заключительное оценивание рисков
К десяти самым серьезным рискам в программном проекте обычно относят следующие:
Неточность метрик – значения метрик, служащие основой для анализа и принятия решений, могут оказаться неточными.
Неадекватность измерений – измерения метрик, служащих основой для анализа и принятия решений, могут быть проведены с ошибками.
Чрезмерное давление графика – этапы поставок спланированы с превышением нагрузки на исполнителей.
Некомпетентность руководства – no comment
Неадекватность оценки затрат – затраты на разработку оценены неверно. Синдром «серебряной пули» – мнение, что существует одно решение для всех
проблем в проекте.
Ползучесть требований пользователя – в процессе разработки меняются исходные требования, вызывая необходимость переделок или отказа от части уже выполненных работ
Низкое качество – no comment
Низкая производительность труда – фактическая производительность труда оказалась меньше расчетной
Отмененные проекты – проект прекращен по не зависящим от исполнителей причинам, что очень демотивирует команду для следующих проектов.
СПИИ РАН |
48 |
Заключительное оценивание рисков
|
Системы управления информацией |
|
Системное программное обеспечение |
80 |
Ползучесть требований пользователя |
70 |
Долгосрочный график (>3 лет) |
65 |
Чрезмерное давление графика |
65 |
Неадекватность оценки затрат |
60 |
Низкое качество |
60 |
Избыточный документооборот |
55 |
Превышение затрат |
50 |
Подверженные ошибкам модули |
50 |
Неадекватное конфигурационное управление |
35 |
Отмененные проекты |
|
Программное обеспечение военного |
|
Программное обеспечение по контракту |
|
назначения |
|
|
|
|
|
|
90 |
Избыточный документооборот |
60 |
Высокие затраты на сопровождение |
85 |
Низкая производительность труда |
50 |
Трения между подрядчиком и клиентом |
75 |
Долгосрочный график (>3 лет) |
45 |
Ползучесть требований пользователя |
70 |
Ползучесть требований пользователя |
30 |
Неожиданные критерии приемки |
45 |
Неиспользуемое программное обеспечение |
20 |
Право собственности на программное |
|
|
|
обеспечение и поставки |
|
Программное обеспечение пользователя |
|
Коммерческое программное обеспечение |
||
80 |
|
Непередаваемые приложения |
70 |
|
Неадекватная документация пользователя |
|
|
|
|
|
|
65 |
|
Скрытые ошибки |
55 |
|
Низкая удовлетворенность пользователя |
|
|
|
|
|
|
60 |
|
Несопровождаемое программное |
50 |
|
Избыточное время выхода на рынок |
|
|
обеспечение |
|
|
|
50 |
|
Избыточные приложения |
45 |
|
Вредные действия конкурентов |
20 |
|
Право собственности на программное |
30 |
|
Расходы на судебные разбирательства |
|
|
обеспечение и поставки |
|
|
|
СПИИ РАН |
49 |
Заключительное оценивание рисков
Ползучесть требований пользователя: прототипирование, совместное проектирование приложения (Joint Application Development – JAD), информационная инженерия (Information Engineering – IE).
Давление графика, долгосрочный график, время выхода на рынок: технологии планирования, технологии для сокращения графика (готовые модули, повторное использование компонентов, системы САПР, объектно-ориентированные анализ, проектирование и средства кодирования, информационная инженерия и быстрая разработка приложений), структурный анализ, инспекции и обзоры.
Превышение затрат: технологии точных оценок, технологии, снижающие стоимость разработки, передача проектов на сторону (outsourcing).
Низкое качество и модули с ошибками: средства оценки качества и надежности методы предотвращения дефектов, методы устранения дефектов, программы измерения качества.
Высокая стоимость сопровождения: анализаторы структурной сложности, средства реструктуризации (для языков COBOL и C), средства обратного восстановления (reverse engineering), анализ модулей с ошибками и удаление их.
В то же время ряд рисков сопротивляется любым известным стратегиям, и для которых есть только паллиативные решения:
Чрезмерный документооборот: военные и другие стандарты, в прошлом бумага была дешевле компьютерной памяти, решению может помочь развитие технологий.
Неадекватная пользовательская документация: процент людей, умеющих хорошо писать документацию, не слишком высок, документация получается лучше у больших компаний, графический интерфейс (GUI) и мультимедийность могут поменять подходы к документации.
Низкая удовлетворенность пользователя: GUI, эксперты по интерфейсу, улучшение пользовательской документации, улучшение функций подсказки (HELP).
Трения между заказчиком и клиентом: партнерство, управление рисками в команде.
Юридические проблемы: обсуждать проблемы на переговорах, нанимать юристов, понимающих вопросы ПО, прибегать к посредничеству до арбитража и спора в суде.
СПИИ РАН |
50 |
2.Методологические, методические и технологические основы решения проблем управления рисками в программном проекте.
СПИИ РАН |
51 |