Спиральная стратегия см пункт 1

Стратегии разработки По

Для устранения или сокращения вышеназванных недостатков к настоя-

щему времени созданы и широко используются три базовые стратегии раз-

работки ПО:

 каскадная;

 инкрементная;

 эволюционная.

Каскадная стратегия представляет собой однократный проход этапов

разработки. Данная стратегия основана на полном определении всех требова-

ний к разрабатываемому программному средству или системе в начале процес-

са разработки. Каждый этап разработки начинается после завершения преды-

дущего этапа. Возврат к уже выполненным этапам не предусматривается. Про-

межуточные продукты разработки в качестве версии программного средства

(системы) не распространяются.

Представителями моделей, реализующих каскадную стратегию, являются

каскадная и V-образная модели.

Основными достоинствами каскадной стратегии, проявляемыми при

разработке соответствующего ей проекта, являются:

1) стабильность требований в течение ЖЦ разработки;

2) необходимость только одного прохода этапов разработки, что обеспе-

чивает простоту применения стратегии;

3) простота планирования, контроля и управления проектом;

4) доступность для понимания заказчиками.

К основным недостаткам каскадной стратегии,следует отнести:

1) сложность полного формулирования требований в начале процесса

разработки и невозможность их динамического изменения на протяжении ЖЦ;

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

3) непригодность промежуточных продуктов для использования;

4) недостаточное участие пользователя в процессе разработки ПС – только в самом начале (при разработке требований) и в конце (во время приемочных испытаний); это приводит к невозможности предварительной оценки пользователем качества программного средства или системы.

Области применения каскадной стратегии определяются ее достоинствами и ограничены ее недостатками. Использование данной стратегии наиболее

эффективно в следующих случаях:

1) при разработке проектов с четкими, неизменяемыми в течение ЖЦ требованиями и понятной реализацией;

2) при разработке проектов невысокой сложности, например:

 создание программного средства или системы такого же типа, как уже разрабатывались разработчиками;

 создание новой версии уже существующего программного средства или системы;

 перенос уже существующего продукта на новую платформу;

3) при выполнении больших проектов в качестве составной части моделей ЖЦ, реализующих другие стратегии разработки

Резюме

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

2.1.3. Инкрементная стратегия разработки программных средств и систем

Инкрементная стратегия представляет собой многократный проход этапов разработки с запланированным улучшением результата. Данная стратегия основана на полном определении всех требований к разрабатываемому программному средству (системе) в начале процесса разработки. Однако полный набор требований реализуется постепенно в соответствии с планом в последовательных циклах разработки.

Результат каждого цикла называется инкрементом.

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

Результат каждого цикла разработки может распространяться в качестве очередной поставляемой версии программного средства или системы.

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

Инкрементная стратегия обычно основана на объединении элементов

каскадной модели и прототипирования. При этом использование прототипиро-

вания позволяет существенно сократить продолжительность разработки каждо-

го инкремента и всего проекта в целом.

Современной реализацией инкрементной стратегии является экстремаль-

ное программирование.

Основными достоинствами инкрементной стратегии, проявляемыми

при разработке соответствующего ей проекта, являются:

1) возможность получения функционального продукта после реализации каждого инкремента;

2) короткая продолжительность создания инкремента; это приводит к сокращению сроков начальной поставки, позволяет снизить затраты на первоначальную и последующие поставки программного продукта;

3) предотвращение реализации громоздких спецификаций требований; стабильность требований во время создания определенного инкремента; возможность учета изменившихся требований;

4) снижение рисков по сравнению с каскадной стратегией;

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

К основным недостаткам инкрементной стратегии, проявляющимся в результате ее несоответствующего применения, следует отнести:

1) необходимость полного функционального определения системы или программного средства в начале ЖЦ для обеспечения планирования инкрементов и управления проектом;

2) возможность текущего изменения требований к системе или программному средству, которые уже реализованы в предыдущих инкрементах;

3) сложность планирования и распределения работ;

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

график работ или снизить качество программного продукта.

Области применения инкрементной стратегии определяются ее достоинствами и ограничены ее недостатками. Использование данной стратегии наиболее эффективно в следующих случаях:

1) при разработке проектов, в которых большинство требований можно сформулировать заранее, но часть из них могут быть уточнены через определенный период времени;

2) при разработке сложных проектов с заранее сформулированными требованиями; для них разработка системы или программного средства за один цикл связана с большими трудностями;

3) при необходимости быстро поставить на рынок продукт, имеющий базовые функциональные свойства;

4) при разработке проектов с низкой или средней степенью рисков;

5) при выполнении проекта с применением новых технологий.

Резюме

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

определяемые правильностью выбора данной стратегии по отношению к кон-

кретному проекту

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

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

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

Для итеративного уточнения требований при применении прототипирования в цикле разработки должен участвовать заказчик.

Представителями моделей, реализующих эволюционную стратегию, являются, например, спиральные модели

Основными достоинствами эволюционной стратегии, проявляемыми

при разработке соответствующего ей проекта, являются:

1) возможность уточнения и внесения новых требований в процессе раз-

работки;

2) пригодность промежуточного продукта для использования;

3) возможность управления рисками;

4) обеспечение широкого участия пользователя в проекте, начиная с ранних этапов, что минимизирует возможность разногласий между заказчиками и разработчиками и обеспечивает создание продукта высокого качества;

5) реализация преимуществ каскадной и инкрементной стратегий.

К недостаткам эволюционной стратегии, проявляемым при ее несоответствующем выборе, следует отнести:

1) неизвестность точного количества необходимых итераций и сложность определения критериев для продолжения процесса разработки на следующей итерации; это может вызвать задержку реализации конечной версии системы или программного средства;

2) сложность планирования и управления проектом;

3) необходимость активного участия пользователей в проекте, что реально не всегда осуществимо;

4) необходимость в мощных инструментальных средствах и методах

прототипирования;

5) возможность отодвигания решения трудных проблем на последующие

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

Использование данной стратегии наибо-

лее эффективно в следующих случаях:

1) при разработке проектов, для которых требования слишком сложны,

неизвестны заранее, непостоянны или требуют уточнения;

2) при разработке сложных проектов, в том числе:

 больших долгосрочных проектов;

 проектов по созданию новых, не имеющих аналогов ПС или систем;

 проектов со средней и высокой степенью рисков;

 проектов, для которых нужна проверка концепции, демонстрация

технической осуществимости или промежуточных продуктов;

3) при разработке проектов, использующих новые технологии.

В подразд. 2.5 рассмотрены модели ЖЦ, реализующие эволюционную

стратегию разработки ПС и систем.

Резюме

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

При эволюционной стратегии часто используется прототипирование. Эволюционная стратегия имеет достоинства и недостатки, определяемые правильностью

выбора данной стратегии по отношению к конкретному проекту.

Этапы разработки ПО

Анализ требований к проекту

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

В рамках данного этапа не только фиксируются требования заказчика, но и проводится их формирование – клиентам подбирается оптимальное решение их проблем, определяется необходимая степень автоматизации, выявляются наиболее актуальные для автоматизации бизнес-процессы.

При анализе требований определяются сроки и стоимость разработки ПО, формируется и подписывается ТЗ на разработку программного обеспечения.

Проектирование

На основе предыдущего этапа проводится проектирование системы. Эта методология проектирования соединяет в себе объектную декомпозицию, приемы представления физической, логической, а также динамической и статической моделей системы.

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

Реализация

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

Тестирование продукта

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

Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

установка системы,

обучение пользователей,

эксплуатация.

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

Поддержка функционирования ПО должна осуществляться группой технической поддержки разработчика.

Жизненный цикл ПО

В соответствии со стандартом СТБ ИСО/МЭК 12207–2003 под жизненным циклом программного средства или системы подразумевается совокупность процессов, работ и задач, включающая в себя разработку, эксплуатацию и сопровождение программного средства или системы и охватывающая их жизнь от формулирования концепции до прекращения использования. ЖЦ ПС состоит из процессов. Каждый процесс ЖЦ разделен на набор работ. Каждая работа разделена на набор задач.

Процессы ЖЦ ПС делятся на три группы:

 основные;

 вспомогательные;

 организационные.

Основные процессы жизненного цикла – это процессы, которые реализуются под управлением основных сторон, участвующих в жизненном цикле программных средств. Основными сторонами являются заказчик, поставщик, разработчик, оператор и персонал сопровождения программных продуктов. К основным процессам относится пять процессов:

 заказ;

 поставка;

 разработка;

 эксплуатация;

 сопровождение

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

 документирование;

 управление конфигурацией;

 обеспечение качества;

 верификация;

 аттестация;

 совместный анализ;

 аудит;

 решение проблем.

Вспомогательные процессы вызываются другими процессами ЖЦ

Организационные процессы жизненного цикла – это процессы, предназначенные для создания в некоторой организации и совершенствования организационных структур, охватывающих процессы жизненного цикла и соответствующий персонал. К организационным процессам относится четыре процесса:

 управление;

 создание инфраструктуры;

 усовершенствование;

 обучение

Планирование процесса разработки

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

5) Каскадная стратегия см пункт 1

Руководство проектом

Руководство проектом определяет сущность процесса разработки от его начала до конца.
Оно обеспечивает:

1. · оценку объема предстоящих работ

2. · оценку требуемых ресурсов

3. · оценку возможных рисков

4. · составляет или корректирует план работ

5. · определяет первоочередные задачи

6. · устанавливает вехи – точки контроля промежуточных результатов

В начале работы над проектом необходимо:

1. · установить цели и проблемную область проекта;

2. · рассмотреть и обсудить возможные варианты решения;

3. · выявить технические, организационные и материальные ограничения

Руководство программным проектом — первый слой процесса конструирования ПО. Термин «слой» подчеркивает, что руководство определяет сущность процесса разработки от его начала до конца. Принцип руководства иллюстрирует рис. 2.1.

На этом рисунке прямоугольник обозначает процесс конструирования, в нем выделены этапы, а вверху, над каждым из этапов, размещен слой деятельности «руководство программным проектом».
Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ.

Управление рисками

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

Упрощенно риск можно понимать как вероятность проявления каких-либо неблагоприятных обстоятельств, негативно влияющих на реализацию проекта. Можно выделить три типа рисков.

1. Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта.

2. Риски для разрабатываемого продукта, влияющие на качество или производительность разрабатываемого программного продукта.

3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам.

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

Многие типы рисков способны повлиять на любые программные проекты, эти риски приведены в таблице 4.1.

 

Таблица 4.1 – Возможные риски программных проектов

Риск	Типы риска	Описание риска
Текучесть разработчиков	Риск для проекта	Опытные разработчики покидают проект до его завершения
Изменение в управлении организацией	Риск для проекта	Организация меняет свои приоритеты в управлении проектом
Неготовность аппаратных средств	Риск для проекта	Аппаратные средства, которые необходимы для проекта, не поступили вовремя или не готовы к эксплуатации
Изменение требований	Риск для проекта и для разрабатываемого продукта	Появление большого количества непредвиденных изменений в требованиях, предъявляемых к разрабатываемому ПО
Задержка в разработке спецификации	Риск для проекта и для разрабатываемого продукта	Спецификации основных интерфейсов подсистем не поступили к разработчикам в соответствии с графиком работ
Недооценка размера разрабатываемой системы	Риск для проекта и для разрабатываемого продукта	Размер системы значительно превысил первоначальную оценку
Недостаточная эффективность CASE-средств	Риск для разрабатываемого продукта	CASE-средства, предназначенные для поддержки проекта, оказались менее эффективными, чем ожидалось
Изменения в технологии разработки ПО	Бизнес-риск	Основные технологии построения программной системы заменяются новыми
Появление конкурирующего программного продукта	Бизнес-риск	На рынке программных продуктов до окончания проекта появилась конкурирующая программная система

Схема процесса управления рисками показана на рисунке 4.1. Этот процесс состоит из четырех стадий.

1. Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес-риски.

2. Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций.

3. Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.

4. Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций.

Рисунок 4.1 – Схема процесса управления рисками

 

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

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

Определение рисков

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

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

1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.

2. Риски, связанные с персоналом. Связаны с членами команды разработчиков.

3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.

4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.

5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.

6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.

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

 

 

Таблица 4.2 – Категории рисков

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

 

Анализ рисков

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

1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.

2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный.

Результаты анализа рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного ущерба. В таблице 4.2 приведен упорядоченный список рисков, описанных в таблице 4.1; там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, технологии создания ПО, команде разработчиков и о самой организации.

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

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

Таблица 4.3 – Список рисков после проведения их анализа

Риск	Вероятность*	Степень ущерба
Финансовые затруднения в организации привели к уменьшению бюджета проекта	Низкая	Катастрофическая
Невозможно подобрать работников с требующимся профессиональным уровнем	Высокая	Катастрофическая
Ведущий разработчик заболел в самое критическое время	Средняя	Серьезная
Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональные возможности	Средняя	Серьезная
Изменения требований приводят к значительным повторным работам по проектированию системы	Средняя	Серьезная
В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом	Высокая	Серьезная
База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций	Средняя	Серьезная
Недооценки времени выполнения проекта	Высокая	Серьезная
CASE-средства невозможно интегрировать с другими средствами поддержки проекта	Высокая	Терпимая
Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта	Средняя	Терпимая
Невозможно организовать необходимое обучение персонала	Средняя	Терпимая
Скорость выявления дефектов в системе ниже ранее спланированной	Средняя	Терпимая
Размер системы значительно превышает первона­чально рассчитанный	Высокая	Терпимая
Программный код, генерируемый CASE-средствами, неэффективен	Средняя	Незначительная

 

Из списка рисков, представленных в таблице 4.3, для мониторинга следует отобрать те риски, которые могут привести к катастрофическим и серьезным последствиям для вашего проекта.

Планирование рисков

Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинга после анализа рисков. В таблице 4.4 показаны возможные стратегии управления основными рисками, приведенными в таблице 4.3.

 

Таблица 4.4 – Стратегии управления рисками

Риск	Стратегия
Финансовые проблемы организации	Подготовить краткий документ для руководства организации, показывающий важность данного проекта для достижения финансовых целей организации
Проблемы неквалифицированного персонала	Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы
Болезни персонала	Реорганизовать работу команды разработчиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками
Дефектные системные компоненты	Заменить потенциально дефектные системные компоненты покупными компонентами, гарантирующими качество работы
Изменения требований	Попытаться определить требования, наиболее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию
Реорганизация компании-разработчика	Подготовить краткий документ для руководства компании, показывающий важность данного проекта для достижения финансовых целей компании
Недостаточная производительность базы данных	Рассмотреть возможность покупки более производительной базы данных
Недооценки времени выполнения проекта	Рассмотреть вопрос о покупке системных компонентов, исследовать возможность использования генератора программного кода

 

 

Существует три категории стратегий управления рисками.

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

2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков (табл. 4.4).

3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 4.4 это стратегия поведения при возникновении финансовых проблем у организации-разработчика.

Мониторинг рисков

Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В таблице 4.5 приведены признаки, которые помогают определить тип риска.

 

Таблица 4.5 – Признаки рисков

Тип риска	Признаки
Технологические риски	Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документи­рованные технологические проблемы
Рис