РИСКИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ - Студенческий научный форум

VIII Международная студенческая научная конференция Студенческий научный форум - 2016

РИСКИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Сыч Г.Л. 1
1ХГУЭП, Хабаровск, Россия
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF
В настоящее время российскими компаниями накоплен огромный опыт по управлению проектами в области разработки ПО, но, несмотря на это, процесс управления рисками даже в самых развитых компаниях в этой области организовано недостаточно. Даже информацию о рисках, возникающих в процессе разработки ПО, их появление, описание и классификацию достаточно сложно найти в научной литературе. Поставим задачу выявить, описать и классифицировать риски разработки программного обеспечения (ПО), а также кратко сформулируем возможность стратегии управления ими.

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

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

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

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

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

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

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

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

Риск противоречивости в требованиях (декомпозиция спецификации) – это риски связанные с выявлением противоречивости в требованиях заказчика на этапе программирования или интеграции проекта.

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

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

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

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

Риск смены сотрудников, когда проект покидают ключевые сотрудники, которые максимально владеют информацией.

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

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

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

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

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

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

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

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

Просмотров работы: 6647