Разработка методики и моделей управления рисками в проектах разработки программного обеспечения

На правах рукописи

Бриткин Александр Ильич

РАЗРАБОТКА МЕТОДИКИ И МОДЕЛЕЙ УПРАВЛЕНИЯ РИСКАМИ В ПРОЕКТАХ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Специальность: 08.00.13 –

«Математические и инструментальные методы экономики»

Автореферат

диссертации на соискание ученой степени

кандидата экономических наук

Москва – 2009

Работа выполнена в Московском государственном университете экономики, статистики и информатики (МЭСИ) на кафедре Математического обеспечения и администрирования информационных систем.

Научный руководитель: кандидат экономических наук, доцент

Грибанов Владимир Петрович

Официальные оппоненты: доктор экономических наук, профессор

Егорова Наталья Евгеньевна

кандидат экономических наук, доцент

Макаров Максим Геннадьевич

Ведущая организация: ГОУ ВПО «Всероссийский Заочный

Финансово-Экономический Институт»

Защита диссертации состоится « ____ » ______________ _______ г. в 14 часов на заседании диссертационного совета Д 212.151.01 в Московском государственном университете экономики, статистики и информатики по адресу: 119501, г. Москва, ул. Нежинская, 7.

С диссертацией можно ознакомиться в библиотеке Московского государственного университета экономики, статистики и информатики.

Автореферат разослан « ____ » ______________ _______ г.

Ученый секретарь диссертационного совета

кандидат технических наук, доцент И.Н. Мастяева

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

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

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

Степень научной проработанности темы. Научной разработке теоретических и методологических проблем применения математического моделирования к управлению рисками посвящены работы отечественных и зарубежных ученых (К. Гианнопоулос, Б.А. Лагоша, Е.Ю. Хрусталев, В.Н. Лившиц, Н.Е. Егорова, А.М. Дубров, В.Е. Кузнецов, В.А. Чернов, М.В. Грачева, В.В. Черкасов и др.) Однако, в работах этих ученых в основном рассмотрены вопросы, относящиеся к финансовым рискам и рискам в инвестиционных проектах. Поэтому они оказываются малоприменимы для управления рисками в проектах создания программного обеспечения в силу специфики организации процесса работ, связанной с нечеткими волатильными проектными требованиями и итеративностью проекта.

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

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

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

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

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

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

Научная новизна исследования заключается в разработке экономико-математического инструментария по анализу и оценке рисков в проектах разработки программного обеспечения, в том числе:

1. выявлены новые не рассматривавшиеся ранее специфические риски в сфере разработки программного обеспечения, в числе которых риски, связанные с организацией итеративного процесса разработки, специфические технологические риски, а также риски, возникающие при создании высокопроизводительных вычислительных систем, к которым предъявляются повышенные требования по масштабируемости, производительности и отказоустойчивости;
2. построена экономико-математическая модель оценки длительности проекта, основанная на функции распределения Вейбулла-Гнеденко, которая в отличие от существующих в риск-менеджменте подходов позволяет оценить риск незавершения проекта в срок и автоматизировать итеративный процесс анализа и снижения рисков. Применение модели дает возможность более точно на ранних стадиях прогнозировать длительность проекта;
3. создана экономико-математическая модель оценки процессных рисков, которая в отличие от существующих подходов к управлению рисками в разработке ПО, учитывает дополнительные виды рисков проекта: процессные риски задач, ролей и артефактов. Модель позволяет своевременно предупреждать рисковые ситуации в процессе разработки программного обеспечения и в реальном времени проводить расчёты процессных рисков по ходу проекта и в каждой итерации в отдельности;
4. разработан программный инструментарий анализа рисков в проектах создания ПО, отличительная особенность которого в сравнении с имеющимися программными аналогами заключается в наличии функциональности для оценки вероятности наступления рисков. Входная информация данного инструментария обеспечивается моделью архитектуры процесса.

Отмеченные результаты соответствуют пункту 1.4. «Разработка и исследование моделей и математических методов анализа микроэкономических процессов и систем: отраслей народного хозяйства, фирм и предприятий, домашних хозяйств, рынков, механизмов формирования спроса и потребления, способов количественной оценки предпринимательских рисков и обоснования инвестиционных решений» паспорта специальности 08.00.13.

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

Апробация и внедрение результатов. Подходы, разработанные в исследовании, составили основу организации управления рисками в проектах разработки ПО для управления и обработки новостной информации в РИЦ ИТАР-ТАСС. Отдельные положения и рекомендации, сформулированные в работе, используются в деятельности интернет-компании «ВебСтилл».

Результаты исследования докладывались на конференциях «Математика, информатика, естествознание в экономике и в обществе» МФЮА, 2009 и «Актуальные проблемы программной инженерии» МЭСИ, 2009.

Публикации. По теме исследования опубликовано 5 научных работ, общим объемом 2,5 п.л., отражающих основное содержание диссертации (весь объем авторский), в том числе 1 работа в научном издании, рекомендованном ВАК.

Структура работы. Диссертационная работа состоит из введения, трех глав, заключения и списка литературы. Иллюстративно-справочный материал представлен таблицами (27) и рисунками (29).

ОСНОВНЫЕ ПОЛОЖЕНИЯ ДИССЕРТАЦИИ

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

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

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

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

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

Обзор применяемых в мировой практике методик оценки проектных рисков при разработке ПО показал, что большинство из них опирается на качественный способ оценки с помощью матрицы рисков, где экспертно оценивается вероятность наступления риска и степень воздействия на цели проекта (незначительный, средний и критический ущерб). Для частного случая оценки риска невыполнения плана или бюджета проекта используется метод построения дерева решений проекта, основным практическим ограничением которого является исходная предпосылка о том, что проект должен иметь обозримое или разумное число вариантов развития. Другим применяемым методом оценки рисков, связанных с выполнением плана проекта, является Метод критического пути, в основе которого лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи. В ходе исследования также были рассмотрены наиболее известные программные продукты, которые предоставляют функции поддержки проектного риск-менеджмента, среди них: Risk Radar, Risk Register, ProRisk, RiskTrak и Issue Manager. Эти программные продукты различаются в масштабе поддержки, способах использования, а также основополагающей технологией. Большинство продуктов предоставляют средства автоматизации управления рисками в проектах с возможностью ведения репозитория рисков, регистрирования, классификации, ранжирования и мониторинга рисков в репозитории, а также генерацией отчетов.

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

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

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

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

Таблица 1.

Атрибуты риска

Атрибут	Значения
1. Среда	1. Внутренний 2. Внешний
2. Природа	1. Бизнес 2. Технический
3. Сфера	1. Проект 2. Процесс 3. Продукт
4. Уровень	1. Опасный, критический 2. Средний 3. Ограничивающий 4. Низкий 5. Незначительный
5. Область подверженности	1. Бюджет проекта 2. План проекта 3. Качество проекта
6. Время действия	1. Безотлагательный 2. Квартал 3. Год 4. Непрерывные
7. Скорость распространения	1. Низкая 2. Высокая
8. Звено управления риском	1. Процесс 2. Проект 3. Программа 4. Отдел 5. Компания
9. Срочность	1. Безотлагательный 2. Срочный 3. Несрочный
10. Затрагиваемая фаза процесса	1. Требования 2. Проектирование 3. Кодирование 4. Тестирование 5. Обучение 6. Управление качеством 7. Управление проектом

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

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

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

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

В разработанной модели время выполнения проекта, принимается за случайную величину, имеющую трёхпараметрическое распределение Вейбулла-Гнеденко. Это распределение было выбрано автором на основе проведенной аналитической работы, как наиболее подходящее для области разработки ПО. Имея выборку экспериментальных данных по проектам, автор проверил эту статистическую гипотезу с помощью критерия Колмогорова.

Функция распределения Вейбулла-Гнеденко представлена следующим образом:

(1)

где:

• – изучаемая случайная величина, в нашем случае это время выполнения проекта;
• – параметр формы;
• – параметр масштаба;
• – параметр положения.

График функции плотности распределения обладает следующими свойствами:

• при уменьшении увеличивается ширина пика графика плотности распределения;
• при увеличении график плотности распределения растягивается относительно оси ;
• при увеличении график плотности распределения сдвигается вправо.

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

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

Положим параметр равным степени волатильности требований к системе:

(2)

Параметр моделирует эффективность работы персонала проекта. При построении метрики оценки эффективности персонала автором используются факторы издержек масштаба, применяемые в рамках Конструктивной модели стоимости (COCOMO), разработанной в 70х годах Барри Боэмом. Эти факторы необходимо учитывать, поскольку крупные проекты требуют координации между большим количеством групп, которым приходится общаться между собой. С ростом размера проекта число коммуникационных связей между сотрудниками растет в квадратичной зависимости от количества участников проекта по формуле:

(3)

где CON – количество связей, NW – количество сотрудников.

Таблица 2.

Описание факторов масштаба

Фактор	Обозначение	Описание
Предсказуемость	PREC	Отражает наличие у организации опыта в проектах такого типа. Низкий уровень означает, что опыт отсутствует. Сверхвысокий – что данная область является полностью знакомой для организации.
Связность команды	TEAM	Отражает сплоченность группы разработчиков, работающих над проектом. Очень низкий уровень означает, что взаимодействия между разработчиками очень трудные, сверхвысокий - сплоченную группу, без проблем во взаимодействии.
Зрелость процесса	PMAT	Отражает зрелость процессов в организации согласно модели CMM. Вычисление этого фактора выполняется по вопроснику CMM из расчета взвешенного среднего значения.

Выразим эффективность работы персонала через количество реализованных задач IFQ (для текущей итерации), количества запланированных задач PFQ (для текущей итерации) и факторов издержек масштаба ( – предсказуемость, – связность команды, – зрелость процессов, все принимают значения от 0 до 1):

(4)

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

(5)

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

С помощью Конструктивной модели стоимости COCOMO сложность проекта можно выразить как:

(6)

(7)

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

Таким образом, было построено распределение случайной величины длительности проекта, которое выражается через формулы (1), (3), (4), (6) и (7). Все параметры, используемые при расчётах, являются объективными параметрами процесса, что позволяет автоматизировать оценку риска незавершения проекта в срок.

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

Элементами модели, как основными сущностями процесса, автором были выделены:

• процесс разработки ПО;
• задача – атомарная задача из тех, на которые декомпозирован процесс (составление технической спецификации, проектирование ПО, разработка ПО, тестирование и т.п.);
• артефакт – конечный либо промежуточный рабочий продукт, который производится и используется во время разработки проекта. Артефакты используются для сбора и передачи информации в проекте;
• роль – абстрактное определение совокупности представленных задач и содержащихся артефактов. Сами роли не являются личностями, они описывают поведение и обязанности этих личностей в бизнесе. Индекс производительности роли – характеристика действующего субъекта, исполнителя. Среди факторов влияющих на индекс можно выделить: знания (практические и теоретические), навыки и т.п.

Рис. 1. Элементы модели

Величина риска (как математического ожидания ущерба) задачи А в соответствии с формулой (8) оценивается как отношение произведения поправочного коэффициента k и количества других задач процесса, для которых входными артефактами являются выходные артефакты задачи A (AFL), к произведению индекса производительности ролей (), отвечающих за задачу (в ходе калибровки, основываясь на статистических данных нескольких проектов, автором была определена величина поправочного коэффициента как 2735).

(8 )

Производительность роли может быть рассчитана по ранее введенной формуле (4).

Величина риска артефакта AR в соответствии с формулой (9) определяется как отношение произведения поправочного коэффициента k и количества задач, в которых артефакт является входным (ARN), к произведению количества составляющих артефакта (ATR) и индекса производительности ролей, отвечающих за артефакт ().

(9)

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

(10)

Величина риска всего процесса S в соответствии с формулой (11) вычисляется как сумма рисков всех задач процесса, артефактов процесса и ролей, задействованных в процессе:

(11)

где S – процесс, AC – задача, TPAC – общее количество задач в процессе, AR – артефакт, TPAR – общее количество артефактов в процессе, W – роль, TPW – общее количество ролей в процессе.

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

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

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

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

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

Рис. 2. Методика управления рисками в итеративном проекте создания программного обеспечения

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

В рамках исследования автором было разработано программное обеспечение (в виде VBA-макроса для Microsoft Excel) для автоматизации расчётов оценки рисков проекта. Для оценки длительности проекта и итераций исходными данными являются параметры модели, представленной формулами (1)-(7), и данные об архитектуре процесса (количество фаз и итераций проекта).

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

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

Рис. 3. Компонентная диаграмма разработанного программного инструментария

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

Таблица 3.

Фазы и итерации процесса разработки

Фаза	Итерация
Фаза разработки технического задания. На этом этапе должна быть обеспечена согласованность заинтересованных лиц на всех этапах жизненного цикла проекта.	Итерация №1. Разработка технического задания и макета сервиса.
Фаза разработки технического проекта. На этом этапе команда должна получить базовую версию архитектуры системы.	Итерация №2. Разработка технического проекта и горизонтального прототипа сервиса.
Фаза разработки системы. На этом этапе определяются оставшиеся требования, и происходит завершение построения системы на основе базовой версии архитектуры.	Итерация №3. Разработка вертикального прототипа (альфа-версии) сервиса.
	Итерация №4. Разработка бета-версии сервиса.
Фаза внедрения системы. Основное внимание в фазе внедрения системы сосредоточено на продвижении программного обеспечения к конечному пользователю.	Итерация №5. Разработка публичной версии сервиса.
	Итерация №6. Внедрение высокопроизводительной версии сервиса.