Классификация и анализ рисков разработки программного обеспечения

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

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

На сегодняшний день существует большое количество определений и классификаций рисков [1; 2; 3].

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

Рисунок 1 – Риски проектного управления

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

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

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

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

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

Проектные риски

Риски появления новых требований

Риски декомпозиции спецификации

Риски неправильно определённых системных требований

Риски использования нестабильных технологий

Неспособность справиться со сложностью проекта

Рисунок 2 – Классификация проектных рисков

Риск появления новых требований возникает в процессе разработки ПО, когда появляются всё новые и новые требования, которые отодвигают сроки и оценку конкрентных задач. Это негативно сказывается на общей стоимости проекта и приводит к ошибкам в планировании. Обычно, чтобы минимизировать данный риск, используется вовлечение клиентов и их представителей в процесс разработки ПО. Происходит постоянное планирование и обсуждение функционала по каждому этапу, модулю, задаче. Архитектура программы проектируется таким образом, чтобы обеспечивать универсальность, гибкость, расширяемость, низкую связность и модульность. Риск противоречивости в требованиях (декомпозиция спецификации) – это риски, связанные с выявлением противоречивости в требованиях заказчика на этапе программирования или интеграции проекта. Например, один представитель клиента предложил в каком-то модуле реализовать функционал, который невозможно реализовать, так как другой представитель того же клиента предлагает функционал, накладывающий ограничение на первый или, вообще, ставит под сомнение возможность его реализации. Для уменьшения последствий от таких рисков рекомендуется более тщательная работа именно со стороны менеджера проекта. Ему необходимо более квалифицированно подходить к обследованию требований заказчика, договоров, решений, постоянно повышать свой уровень квалификации в этой области. Также хорошо зарекомендовал себя аппарат для формализации, анализа, моделирования и согласования требований с заказчиком, например, диаграммы вариантов использования, IDEF-диграмм, UML-диграмм и т.д.

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

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

Риски, связанные с неспособностью упростить саму структуру проекта.

Некоторые особенности (например, справиться

Иногда

со сложностью

проекта.

проект бывает

настолько

сложным, что команда может

с ним не

справиться. Это может быть обусловлено как неправильно подобранным средством реализации проекта, так и ошибками в

возможность продавать проект по модели SaaS) могут в корне изменить выбор команды относительно средств реализации проекта.

Кадровые и деликтные риски также можно структурировать на две группы (рисунок 3).

Рисунок 3 – Классификация кадровых и деликтных рисков

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

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

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

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

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

Рисунок 4 – Классификация спекулятивных рисков разработки ПО

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

Риски изменения коньюктуры рынка обусловлены изменением экономической ситуации, которая складывалась на рынке при планировании. При этом могли закладываться факторы актуальные на момент планирования, а их изменение не было учтено. Например, возникновение экономического кризиса, может быть причиной для снижения потребительского спроса на товары или услуги, которые являются результатом проекта разработки ПО, а выйти из такого проекта с минимальными потерями достаточно сложно. Также в результате сложной экономической ситуации поставщики материалов и услуг для проекта могут изменить цены (как снизить, так и поднять), что повлияет на общую стоимость проекта, и т.д. Валютные риски – это риски, связанные с возможным возникновением убытков или дополнительных доходов вследствие неблагоприятного или благоприятного изменения курсов иностранных валют. Таким рискам, как правило, подвержены участники международных экономических отношений. Если проект, к примеру, реализуется международной компанией, главный офис которой располагается в США, а офис разработчиков – в РФ, то из-за изменения курса рубля стоимость проекта изменится. В качестве стратегии управления этим риском можно выбрать, например, хеджирование, в качестве хеджирующей операции – форвардный контракт с банком на поставку валюты на дату завершения проекта. В целом структуру рисков разработки ПО можно увидеть на рисунке 5.

Рисунок 5 – Риски разработки ПО

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

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