Понятие риска в программных проектах

Инкрементная модель, спиральная модель разработки ПО: жизненный цикл, достоинства и недостатки.

Инкрементная модель объединяет в себе достоинства двух подходов: классического подхода и макетирования.

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

Для каждого инкремента выполняется:

– Анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;

– Проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;

– Разработка,

– Тестирование.

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

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

Риск программного проекта – это те причины, из-за которых проект может быть неуспешным. Это могут быть технические риски, проектные риски, экономические риски. Это понятие такой науки как «Управление рисками».

 

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

Сама по себе спиральная модель не простая в реализации.

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

Поэтому реально в проектах не так часто используют спиральную модель

Понятие риска в программных проектах

Риск программного проекта – это те причины, из-за которых проект может быть неуспешным. Это могут быть технические риски, проектные риски, экономические риски.

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

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

 

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

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

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

 

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

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

 

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

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

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

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

 

Рис. 1. Процесс управления рисками

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

 

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

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

 

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

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

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

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

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

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

1. Анализ риска

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

 

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

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

Разрешение риска

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

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

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

 

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

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

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

Наблюдение за риском

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

 

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

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

Способы обхода дефекта

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

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

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

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

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

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

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

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

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

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

Принципиальные и технические возможности, точность реализации свойств и измерения значений характеристик ПС, а также общие ресурсы конкретного проекта всегда ограничены в соответствии с их содержанием и возможностями заказчика и разработчиков. Это определяет рациональные диапазоны значений каждого риска, которые могут быть выбраны для проекта ПС на основе требований заказчика, здравого смысла, а также путем анализа пилотных проектов и прецедентов в спецификациях требований реализованных проектов. При ограниченности ресурсов проекта ПС распределение приоритетов должно становиться более строгим и могут снижаться приоритеты характеристик, для реализации которых ресурсов недостаточно. В результате формируется полный набор требуемых функциональных и конструктивных характеристик, свойств и Для управления рисками и детального сопоставительного оценивания выбранных характеристик качества целесообразно каждому из них присваивать коэффициент или приоритет влияния на функциональную пригодность. Группа квалифицированных экспертов из состава заказчиков, потенциальных пользователей и/или разработчиков должны оценивать и устанавливать значения таких коэффициентов – рисков (приоритетов) в пределах унифицированной шкалы, например, от единицы до десяти, для конкретного проекта ПС. Точность определения коэффициентов вряд ли может превышать 10%, поэтому количество градаций шкалы целесообразно не больше десяти. Аналогично, по такой же шкале экспертами целесообразно оценивать относительные затраты ресурсов, которые следует выделять на реализацию сокращения рисков. Для каждого вида рисков отношение коэффициента влияния на функциональную пригодность к относительным затратам на его достижение можно рассматривать как обобщенный уровень приоритета требований к сокращению риска.