CC BY
79
УДК: 338.004.65 ГРНТИ: 20.15; 06.81; 84.15
СТРАТЕГИИ УПРАВЛЕНИЯ РИСКАМИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Е. В. Муравьев
Санкт-Петербургский государственный экономический университет Россия, 191023 г. Санкт-Петербург, ул. Садовая, 21
Н Муравьев Евгений Вячеславович - muravev.mail@gmail.com
В этой статье рассматривается проблема управления рисками в программных проектах. Описываются типичные области возникновения рисков, а также предлагаются стратегии управления рисками, подходящие для широкого круга предприятий и программных проектов с различным количеством связанных рисков, что закладывает основу для определения общего подхода к управлению рисками в ходе программных проектов.
Ключевые слова: управление рисками, разработка программного обеспечения, анализ рисков, риски, жизненный цикл программного обеспечения, программный проект.
RISK MANAGEMENT STRATEGIES FOR SOFTWARE DEVELOPMENT E. V. Muravev
Saint Petersburg State University of Economics 21 Sadovaya St, 191023 St. Petersburg, Russia
El Evgeniy Muravev - muravev.mail@gmail.com
This article considers the problem of risk management in software projects, describes typical risk impact areas, and propose risk management strategies suitable for a wide range of enterprises and software projects with a different amount of associated risks, which lays the foundation for a general approach to risk management in software projects.
Keywords: risk management, software development, risk analysis, risks, software life cycle, software project.
Введение. Многие проекты по разработке программного обеспечения имеют очень высокий уровень рисков и угроз провала в течение всего их жизненного цикла. Программные проекты сталкиваются с такими типами рисков, как операционные, технологические, рисками, связанными с методами управления, угрозами отказа потребителя от программного продукта и пр. [5]. Управление рисками должно начинаться с первых стадий проекта. Неправильное управление рисками может привести к негативным последствиям как для компании-разработчика, так и для клиентов [7]. Целью работы является описание процессов управления рисками на различных этапах проекта по созданию программного обеспечения и определение подхода к управлению рисками в виде стратегий, подходящих для различных проектов по разработке ПО (программного обеспечения).
В статье показано, что управление рисками должно быть частью каждого программного проекта, и только снижение уровня рисков приводит к успешной разработке программного обеспечения.
Риски в разработке программного обеспечения. Условия на глобальном рынке программного обеспечения требуют нового уровня удобства использования, качества, надежности и производительности от программных решений [2]. Создание качественного программного обеспечения в жестких условиях глобального рынка программного обеспечения сопряжено с высоким уровнем риска.
Риск может быть определен как «вероятность несения потерь или убытков» [10, с. 33], а убытки в ходе проекта по разработке ПО определяются как «негативное воздействие на проект, которое может быть выражено в виде снижения качества конечного продукта, увеличение затрат, срыв сро-
ков завершения, потери доли рынка или полного провала» [10, с. 33]. Для каждого риска существует два аспекта: вероятность возникновения риска и убытки связанные с ним. Указанные аспекты используются для оценки воздействия проявления риска (Risk Exposure, RE) [10, с. 33] следующим образом:
RE = P х L
потери потери
(1)
Где:
КЕ - это количественная оценка воздействия риска на проект,
Р - вероятность наступления риска,
потери 1 II'
L - убытки, связанные с наступлением нежелатель-
потери 1 ' 1
ного события.
Риск проекта - вероятное событие в будущем, которое может оказать отрицательное воздействие на достижение целевых показателей реализуемого проекта [6].
Разработка программного обеспечения специфична с точки зрения управления рисками, поскольку риски в разработке программного обеспечения могут разбиваться на большое число категорий [6]. Поэтом важно не столько определение категорий риска, сколько идентификация и описание как можно большего количества рисков в проекте. В связи с этим предлагается классифицировать риски проектов по разработки программного обеспечения в соответствии с основными областями их возникновения.
Для большинства проектов разработки ПО можно определить пять основных областей возникновения риска: использование новых и непроверенных технологий, требования к ПО, архитектура ПО, производительность ПО,
Есопот^ | Juvenis scientia 2018 № 4
11
организационная и нефункциональная области [1].
Наиболее важная область возникновения риска связана с использованием новых технологий. Большинство проектов включают использование новых технологий в процессе разработки. Неправильное их включение в процесс обычно приводит к сбою в проекте. Квалификация - основная проблема, связанная с использованием новых технологий [7]. Значимость знаний о технологиях, участвующих в проекте разработки программного обеспечения, часто игнорируется. Знание технологических особенностей того или иного нового средства или подхода в разработке позволяют минимизировать риск, связанный с их использованием. Команда разработчиков должна обладать достаточной квалификацией для эффективного использования новых технологических возможностей.
Вторая важная область возникновения риска связана с требованиями к программному обеспечению. Часто очень сложно разработать программное решение, которое полностью соответствует ожиданиям пользователей. Чтобы разработать программное решение в соответствии с ожиданиями пользователей, команда разработчиков должна сформировать максимально полный набор пользовательских требований. Требования, которые должны определять весь процесс разработки, можно разделить на функциональные и нефункциональные. Функциональные требования определяют возможности программного решения, в то время как нефункциональные требования определяют уровень качества и ограничения, которым оно должно соответствовать.
Процесс идентификации требований длительный и сложный, поэтому часто возникает необходимость изменения требований при реализации проекта. Изменение требований является серьезной проблемой при разработке программного обеспечения, поскольку изменение одного или нескольких требований может повлиять на все программное решение и привести к срыву сроков проекта [6].
Третьей важной областью возникновения риска является архитектура программного обеспечения. Архитектура программного обеспечения должна быть определена на ранних этапах разработки, чтобы обеспечить качественное программное решение. Однако возможно такое, что программная архитектура, определенная на ранних этапах разработки, не удовлетворяет всем требованиям, установленным на программном решении. Архитектуру ПО можно проверить только с помощью прототипа программного обеспечения, который может быть реализован только на более поздних этапах разработки.
Четвертая область возникновения риска связана с производительностью ПО. Для удовлетворения нефункциональных требований программное решение должно иметь удовлетворительную производительность. Производительность программного решения может быть протестирована только на приближенном к реальному программному окружению. Поэтом необходимо сделать прогнозы производительности программного обеспечения на ранних этапах разработки.
Пятую область возникновения риска можно рассматривать как организационную и нефункциональную. Риски, связанные с этой областью, можно охарактеризовать как организационные проблемы и проблемы, связанные с ресурсами проекта и графиком работ. Жёстко фиксированный график проекта может стать риском, потому что существует множество непредвиденных событий, которые могут вы-
звать задержку в реализации программного обеспечения. Задача управления - определить график проекта, чтобы удовлетворить как клиентов, так и разработчиков. Каждый программный проект должен иметь достаточное количество участников проекта с надлежащей компетенцией и всеми необходимыми ресурсами для запланированного завершения.
В зависимости от области возникновения риска и типа риска, его можно избежать, ограничить, снизить уровень воздействия или контролировать. Наилучшим способом решения проблем является полное избежание рисков. Существует целый ряд рисков, которые можно полностью избежать, используя различные технологии, изменяя требования или планы проектов. Следующим способом управления рисками, связанных с проектом, является их ограничение. Воздействие риска можно ограничить только небольшой частью проекта. Чтобы уменьшить зону воздействия, необходимо определить риски и внести некоторые изменения в проект в отношении используемых технологий и ресурсов. Это допустимый способ устранения рисков, которых нельзя избежать.
Существует множество рисков, которых нельзя избежать или ограничить. Эти риски следует смягчить (снизить) или контролировать. Некоторые риски для проекта могут быть снижены путем реализации прототипа программного обеспечения [1].
Если риски не могут быть снижены, их следует постоянно контролировать, чтобы отслеживать их проявление. Для этих рисков следует предусмотреть планы на случай непредвиденных обстоятельств, определить последовательность действий, которые необходимо принять, если риски материализуются. Риски, которые не могут быть смягчены, представляют серьезную угрозу для разработки программного обеспечения, поэтому их следует считать очень важными.
Устранение рисков требует много времени. Для успешного планирования и реализации проекта, подверженного рискам, требуется организовать управление рисками как непрерывную деятельность на протяжении всего проекта.
Управление рисками. Процесс управления и снижения рисков связан с предотвращением больших убытков при разработке ПО [5]. Процесс управления рисками должен начинаться с идентификации риска [3]. Цель идентификации риска - выявить все факторы, которые могут привести к провалу проекта. Эти факторы связаны с технологиями, используемыми в проекте, процессом разработки и организационными факторами. Эти области следует контролировать, чтобы предусмотреть все риски. Необходимо документально зафиксировать все детали, связанные с обнаруженным риском, такие как описание риска, вероятность возникновения риска, затраты, связанные с материализованным риском, а также возможные решения и стратегии избежания.
Второй этап процесса управления рисками - оценка негативного воздействия для каждого риска. Риски следует классифицировать в зависимости от степени воздействия, чтобы выбрать наиболее приоритетные риски для решения. Риски с разрушительным воздействием должны оцениваться до рисков с низким уровнем воздействия. Это важно, потому что риски с сильным негативным влиянием следует учитывать на ранних этапах разработки, когда затраты, связанные с возможным провалом проекта, меньше, чем на более поздних этапах разработки.
После оценки риска следующим шагом является сни-
жение рисков. Снижение рисков - попытка избежать или предупредит последствия материализации риска. Существуют три основные стратегии смягчения рисков: предотвращение риска, снижение и передача.
Последним шагом в процессе управления рисками является составление плана действий. Этот шаг включает все действия, необходимые для предотвращения риска или сокращения убытков при его материализации [6у].
Стратегии управления рисками. Основываясь на оценке рисков для программного проекта, можно определить три стратегии управления рисками: осторожную, типичную и гибкую [1].
Осторожная стратегия управления рисками предназначена для новых и малоопытных организаций, программные проекты которых связаны с новыми и непроверенными технологиями [1]. Типичная стратегия управления рисками подходит для зрелых организаций, имеющих опыт работы в разработке программного обеспечения и проверенный стек используемых технологий, но проекты которых могут иметь большое количество рисков. Гибкая стратегия управления рисками подходит для опытных организаций по разработке программного обеспечения, чьи проекты формально определены и основаны на проверенных технологиях.
Чтобы успешно внедрить осторожную стратегию управления рисками, организация должна определить конкретные роли управления рисками в проекте, то есть должны быть выделены члены проекта, основная деятельность которых связана с управлением рисками. Члены проектной группы должны тщательно ранжировать риски, постоянно отслеживать их и определять действия, связанные с их возможной материализацией.
Задачи по управлению рисками в стратегии осторожного управления рисками представлена на рисунке 1 с использованием диаграммы активности UML
Рисунок 2. Диаграмма активности типичной стратегии управления рисками
Основное различие между осторожной и типичной стратегией в том, что типичная стратегия управления рисками предполагает, что большая часть рисков в проекте легко устраняется, в то время как стратегия осторожного управления предполагает большое количество критических рисков. Управление рисками согласно типичной стратегии должно проводиться в основном на командном и организационном уровнях. Эта стратегия риска не требует отдельных ролей по управлению рисками. В этой стратегии описание рисков и политика ранжирования менее формальны, поскольку риски должны определяться и оцениваться командой управления проектами. Стратегия предназначена для обработки нерегулярно возникающих рисков. Задачи по управлению рисками в типичной стратегии представлены на рисунке 2.
Гибкая стратегия управления рисками выбирается для зрелой организации с формально определенными проектами, которые используют известные и проверенные технологии и имеют хорошую организацию [1]. Эта стратегия предполагает небольшое количество приемлемых рисков. Планы снижения рисков определяются только для нескольких важных рисков, что позволяет минимизировать объем работы, необходимой для управления рисками, поскольку в зрелых организациях уровень воздействия рисков относительно небольшой. Управление рисками должно проводиться в основном на организационном уровне. Риски
Определение реле и длч управленил ри [хами
...
Оценка ранее рЕЕрешенных рыскав
Рисунок 1. Диаграмма активности стратегии острожного управления рисками
Типичная стратегия управления рисками стратегия управления рисками должна использоваться на программных проектах с более-менее известными технологий и опытными людьми [1]. Уровень приемлемых рисков для этой стратегии является средним. В соответствии с этой стратегией риски должны определяться поэтапно в зависимости от прогресса проекта.
ЕгВДЗНИ БЫГШЛНДКИСП Н Е эр гани^ацирннр^. уррвне
Идентификации и списание ргсксе
Рисунок 3. Диаграмма активности гибкой стратегии управления рисками
Economics | Juvenis scientia 2018 № 4
13
определяются в начале проекта и являются, как правило, известными. Гибкая стратегия предназначена для достижения успешного управления рисками путем подстраивания имеющихся практик снижения рисков для новых проектов. Задачи по управлению рисками для гибкой стратегии управления рисками представлены на рисунке 3.
Выбор подходящей стратегии управления рисками должен в первую очередь основываться на организационном опыте и качестве организации проекта, но также следует учитывать сложность проекта по разработке ПО, использование новых технологий, стабильность требований и компетенцию участников проекта.
Заключение. Риски присутствуют в каждом проекте по
ЛИТЕРАТУРА
разработке программного обеспечения, потому что разработка тесно связана с использованием новых технологий, а шансы на успех проекта зависят от его успешной организации и качественного управления рисками. В работе показаны области возникновения рисков и предложены три стратегии управления рисками, подходящие для различных программных проектов, на основе обобщения опыта представленного в литературе по данной теме.
Предлагаемые стратегии определяют действия, необходимые для успешного управления рисками, которые позволят как можно скорее идентифицировать риски в ходе проектов и решать проблемы, связанные с материализацией рисков.
1. Boban M., Pozgaj Z., Sertic H. Strategies for successful software development risk management // Management: journal of contemporary management issues. 2017. Vol. 8. No. 2. Pp. 77-91.
2. Кияев В.И. Стандартизация, метрология и качество разработки программного обеспечения и информационных технологий. Монография. СПб: Изд-во СПбГЭУ, 2016. 475 С.
3. Николаенко В.С. Внедрение риск-менеджмента в ИТ-проекты // Государственное управление. Электронный вестник. 2016. № 54 С.63-88.
4. Смирнов А.А. и др. Проблемы анализа и оценки рисков информационной деятельности // Системы обработки информации. 2016. №.3. С. 40-42.
5. Mohapatra B.R., Panda J.K. A Study on the Strategic Risk Management in Software Engineering Projects // International Journal of Advanced Research in Computer Science and Management Studies. 2016. Vol. 4. No 2.
6. Липаев В.В. Анализ и сокращение рисков проектов программных средств. М.: ФиС, 1983. 360 с.
7. Bannerman P. L. Risk and risk management in software projects: A reassessment // J. of Systems and Software. 2008. Vol. 81. No 12. Pp. 2118-2133.
8. Rumbaugh J., Jacobson I., Booch G. Unified modeling language reference manual, Pearson Higher Education, 2004.
9. Herbsleb, J.D., & Moitra, D. Global software development // IEEE Software, 2001. March/April, Pp. 16-20
10. Boehm B.W. Software risk management: principles and practices //IEEE software. 1991. Vol. 8. No 1. Pp. 32-41.
Поступила в редакцию 05.04.2018
