Процесс управления рисками должен быть тесно интегрирован с общим жизненным циклом проекта. Оценка рисков может быть начата на этапе выработки концепций, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и рамок. С появлением каждого нового ограничения или допущения, связанного с проектом, начинает появляться все больше и больше рисков. Проектная группа должна инициировать мероприятия по обнаружению рисков как можно раньше. По результатам шагов анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план. Ход выполнения этих планов должен подвергаться мониторингу в рамках стандартного процесса управления проектом.
Риски возникают на протяжении всего жизненного цикла проекта, это требует проведения новых шагов анализа и планирования. Члены проектных групп должны постоянно искать возникающие в проекте риски и предоставлять их на рассмотрение всей команды. Также члены проектных групп постоянно должны следить за ходом выполнения принятых в отношении рисков планов. Шаги анализа рисков, так же как и внесение изменений в планы по управлению рисками, чаще всего будут периодическими мероприятиями, проводимыми проектной группой.
Существует множество видов моделей жизненного цикла ПО. Поскольку универсальной модели нет, разработчики нередко прибегают к комбинированию моделей, чтобы использовать возможные преимущества. Как правило, все модели включают все стадии ЖЦ ПО и связаны с методологиями проектирования (модель синхронизации и стабилизации – MSF, каскадная и спиральная модель – RUP и т. д.).
Выбор той или иной модели зависит от характера и масштаба проекта (объем, сроки), планируемой ИТ-архитектуры, степени сопровождаемости ПО и прочих факторов. В свою очередь, выбранная модель жизненного цикла окажет влияние на скорость разработки и качество продукта, стоимость и время выхода на рынок, стратегию управления изменениями, стратегию управления рисками в процессе разработки.
Наиболее прогрессивной в настоящее время является спиральная модель, которая обладает рядом преимуществ, по сравнению с другими моделями, и характеризуется повышенным вниманием к управлению рисками. По мнению автора спиральной модели Барри Боэма, «главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта».
Согласно концепции спиральной модели, каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем анализируются возможные риски, уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали (рис. 6).
Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Спиральная модель позволяет пользователям увидеть систему уже на ранних этапах, при этом обеспечивается определение непреодолимых рисков без особых дополнительных затрат.
При всех многочисленных достоинствах спиральной модели существует и ряд недостатков. Например, если проект имеет низкую степень риска или небольшие размеры, модель может оказаться слишком дорогостоящей и сложной для использования. В ряде случаев использование модели может оказаться дорогостоящим, по сравнению с другими моделями жизненного цикла (каскадной, итерационной), за счет новых витков спирали, на которых учитываются ответная реакция и пожелания заказчика, а также необходимости привлечения высокопрофессиональных кадров для оценки рисков.
Независимо от выбора модели жизненного цикла желательно уделять внимание рискам на каждом этапе, начиная с выработки концепции и заканчивая эксплуатацией системы. На ранних этапах, как правило, доминируют риски, связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. С течением времени начинают играть важную роль технологические риски, связанные с реализацией проекта. Затем внимание переходит к рискам поддержки и сопровождения.
Глава 3
Улучшение качества ПО и снижение рисков
3.1. Понятие качества и его многомерность