Сергей Авдошин - Информатизация бизнеса. Управление рисками Страница 14

Методология RAD (Rapid Application Development) идеально подходит для быстрой разработки приложений (до 6 месяцев) с использованием ограниченной команды специалистов. Поскольку методология предполагает активное вовлечение пользователей в процесс разработки, отсутствие базовых навыков в области информационных технологий может стать ключевым риском в процессе разработки. Фаза построения и разработки приложения происходит крайне быстро, поэтому существуют определенные риски внесения изменений – дополнительных требований и пожеланий, которые практически невозможно реализовать из-за ограниченных сроков реализации. Также методологии быстрой разработки приложений и экстремального программирования (XP) характеризуются наличием сильного менеджера проекта. Его роль становится ключевой, поэтому крайне важно уделять внимание организационным аспектам, взаимодействию коллектива, компетентности команды.

По сравнению с монументальными методологиями, в гибких (Scrum, Crystal, Open Source, ASD) очевидно прослеживается меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Легкие методологии дают возможность обрабатывать большие объемы информации, относящиеся к проекту, в процессе неформального, непосредственного, личного общения, а не с помощью документации. При этом отсутствие документации может быть ограничением использования методологии в государственных учреждениях или организациях, требующих высокой степени формализации и документирования. Поскольку практически все гибкие методологии ориентированы на максимально неформальный подход к разработке, зачастую возможны спорные вопросы при реализации тех или иных изменений, расстановке приоритетов.

При этом легкие методологии также отличаются друг от друга – Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология «Adaptive Software Development» разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках). Scrum характерен активным воздействием внешних лиц по отношению к рабочей группе, при этом у заказчика сохраняется максимальный приоритет. Заказчик продукта сам решает, как оформить бэклог продукта, выбирает требования для следующей итерации. При этом несоблюдение базовых принципов, заложенных в Scrum, таких как самонаправляемые команды, обязательная расстановка приоритетов или еженедельные обновления, может привести к срыву проекта.

2.4. Риски в жизненном цикле программного обеспечения

Анализ методологий в области разработки ПО и опыт менеджеров ИТ-проектов подсказывает, что для эффективной реализации ИТ-проектов обязателен анализ жизненного цикла.

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

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

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

Существует множество видов моделей жизненного цикла ПО. Поскольку универсальной модели нет, разработчики нередко прибегают к комбинированию моделей, чтобы использовать возможные преимущества. Как правило, все модели включают все стадии ЖЦ ПО и связаны с методологиями проектирования (модель синхронизации и стабилизации – MSF, каскадная и спиральная модель – RUP и т. д.).

Выбор той или иной модели зависит от характера и масштаба проекта (объем, сроки), планируемой ИТ-архитектуры, степени сопровождаемости ПО и прочих факторов. В свою очередь, выбранная модель жизненного цикла окажет влияние на скорость разработки и качество продукта, стоимость и время выхода на рынок, стратегию управления изменениями, стратегию управления рисками в процессе разработки.

Наиболее прогрессивной в настоящее время является спиральная модель, которая обладает рядом преимуществ, по сравнению с другими моделями, и характеризуется повышенным вниманием к управлению рисками. По мнению автора спиральной модели Барри Боэма, «главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта».

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

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