Информатизация бизнеса. Управление рисками - [17]

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

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

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

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

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

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

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

Рис. 6. Спиральная модель

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

Глава 3 Улучшение качества ПО и снижение рисков

3.1. Понятие качества и его многомерность

Качество – наиболее важная характеристика программных продуктов. Зачастую качество является основным критерием выбора поставщика, программного обеспечения, информационных технологий. В ходе ИТ-проекта существует много возможностей для потери первоначально задуманного качества решения. Каждый этап жизненного цикла – инициация, внедрение, обновление, обслуживание – представляет особые риски для качества, которые необходимо учитывать. Специалистами отмечено, что вклад в качество, осуществленный на ранних стадиях, имеет более сильное влияние на конечный продукт, чем на поздних стадиях. При этом тестирование и измерение качества должны происходить на всех стадиях жизненного цикла, так же как и постоянное отслеживание и сравнение промежуточных этапов с первоначальным планом. Контроль качества ИТ-приложений на протяжении всего жизненного цикла позволяет ИТ-организациям соотнести процессы обеспечения качества с коммерческими результатами.

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

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