Разработка методики и моделей управления рисками в проектах разработки программного обеспечения - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Разработка методики и моделей управления рисками в проектах разработки программного - страница №1/1



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

Бриткин Александр Ильич
РАЗРАБОТКА МЕТОДИКИ И МОДЕЛЕЙ УПРАВЛЕНИЯ РИСКАМИ В ПРОЕКТАХ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Специальность: 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.

Внедрение высокопроизводительной версии сервиса.


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


Рис. 4. Архитектура процесса разработки


(БМ – бизнес-моделирование, УТ – управление требованиями, АП – анализ и проектирование,
Р – разработка, Т – тестирование, В – внедрение, КУ – конфигурационное управление,
УП – управление проектом, УС – управление средой)
Для того, чтобы оценить время, требуемое на разработку проекта, с помощью модели, представленной формулами (1)-(7), необходимо собрать следующие исходные данные по каждой итерации: количество запланированных задач, количество реализованных задач, величины факторов масштаба, количество запланированных требований, количество запросов на изменение, а также коэффициент сложности разрабатываемой системы. В результате применения модели оценки длительности проекта, было рассчитано время, необходимое для выполнения каждой из итераций. Далее были оценены процессные риски, используя модель, заданную формулами (8)-(11). Пусть (Fi), где – это риск фазы i. Поскольку каждая фаза состоит из итераций, которые в свою очередь состоят из подпроцессов, то справедливо утверждение:
(12)
где:

  • – это величина риска всего процесса,

  • phs – это индекс фазы,

  • – это величина риска phs-той фазы процесса,

  • itr – это индекс итерации в данной фазе,

  • mitr – это максимальное количество итераций в данной фазе,

  • – это величина риска itr-той итерации phs-той фазы процесса,

  • spr – это индекс подпроцесса,

  • mspr – это максимальное количество подпроцессов в данной итерации,

  • – это величина риска spr-того подпроцесса itr-той итерации phs-той фазы процесса. Величина риска подпроцесса может быть выражена как сумма рисков всех задач, ролей и артефактов подпроцесса.

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

Определим результат управления риском (прогнозируемое снижение степени воздействия на ход реализации проекта идентифицированного i-го риска как конечный итог его обработки):
(13)

где:


  • – вероятные потери от проявления i-го необработанного идентифицированного риска;

  • – вероятные потери от проявления i-го обработанного идентифицированного риска.

Вероятные потери от проявления i-го риска выражаются как:


(14)

где:


  • – вероятность материализации i-го риска;

  • – экономический ущерб от материализации риска.

Экономический эффект характеризует превышение результатов управления рисками над затратами в процессе управления:


(15)

где:


  • – экономический эффект от внедрения методики управления рисками;

  • N – число идентифицированных обработанных рисков;

  • – результат управления i-тым риском;

  • k-тый фактический расход на обработку i-го идентифицированного риска.

Таким образом, используя формулы (13) и (15), может быть рассчитан экономический эффект применения методики управления рисками в рассматриваемом проекте, который составил 382 тыс. руб.



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

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

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

  3. Описаны методы идентификации рисков. Рассмотрена классификация рисков. Описаны факторы рисков и их свойства. Определены специфические риски для области разработки программного обеспечения.

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

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

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

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

  8. Проведена апробация разработанных экономико-математических моделей на реальных проектах разработки программного обеспечения.

  9. Рассчитан экономический эффект от внедрения методики управления рисками в общий процесс управления проектом.


По теме диссертации опубликованы следующие работы:
В изданиях, рекомендованных ВАК:

  1. Бриткин А.И. Модель оценки длительности итерационного проекта разработки программного обеспечения // Открытое образование, №4 (75), 2009 (0,6 п.л.)

В других изданиях:

  1. Бриткин А.И. Риски, связанные с внедрением технологий, в проектах разработки программного обеспечения // Социально-экономические и технические системы [Электронный ресурс], №8 (42), 2007 (0,6 п.л.)

  2. Бриткин А.И. Анализ и контроль рисков в проектах разработки программного обеспечения // Альманах современной науки и образования, ISSN 1993-5552, №1, 2008 (0,7 п.л.)

  3. Бриткин А.И. Моделирование оценки рисков в проектах создания программного обеспечения // Сборник научных трудов международной научно-практической конференции «Математика, информатика, естествознание в экономике и в обществе». – М.: МФЮА, 2009. (0,3 п.л.)

  4. Бриткин А.И. Технологические риски в проектах создания программных средств // Сборник научных трудов научно-практической конференции «Актуальные проблемы программной инженерии». – М.: МЭСИ, 2009. (0,3 п.л.)