Идентификация риска — выявление элементов риска в проекте.
В результате идентификации формируется список элементов риска, специфичных для данного проекта.
Выделяют три категории источников риска: проектный риск, технический риск, коммерческий риск.
Источниками проектного риска являются:
q выбор бюджета, плана, человеческих ресурсов программного проекта;
q формирование требований к программному продукту;
q сложность, размер и структура программного проекта;
q методика взаимодействия с заказчиком.
К источникам технического риска относят:
q трудности проектирования, реализации, формирования интерфейса, тестирования и сопровождения;
q неточность спецификаций;
q техническая неопределенность или отсталость принятого решения.
Главная причина технического риска — реальная сложность проблем выше предполагаемой сложности.
Источники коммерческого риска включают:
q создание продукта, не требующегося на рынке;
q создание продукта, опережающего требования рынка (отстающего от них);
q потерю финансирования.
Лучший способ идентификации — использование проверочных списков риска, которые помогают выявить возможный риск.
На практике каждый элемент списка снабжается комментарием — набором методик для предотвращения источника риска.
После идентификации элементов риска следует количественно оценить их влияние на программный проект, решить вопросы о возможных потерях. Эти вопросы решаются на шаге анализа риска.
Анализ риска — оценка вероятности и величины потери по каждому элементу риска.
В ходе анализа оценивается вероятность возникновения и величина потери для каждого выявленного элемента риска. В результате вычисляется влияние элемента риска на проект.
Планирование структуры распределения работ и используемых ресурсов.
Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.
Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для последующих параллельных задач.
Системный анализ проводится с целью:
1) выяснения потребностей заказчика;
2) оценки выполнимости системы;
3) выполнения экономического и технического анализа;
4) распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);
5) определения стоимости и ограничений планирования;
6) создания системной спецификации.
В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация.
Анализ требований дает возможность:
1) определить функции и характеристики программного продукта;
2) обозначить интерфейс продукта с другими системными элементами;
3) определить проектные ограничения программного продукта;
4) построить модели: процесса, данных, режимов функционирования продукта;
5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.
Результаты анализа сводятся в спецификацию требований к программному продукту.