CC BY
154
УДК 004.41/.42
ФАКТОРЫ РИСКА ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
RISK FACTORS IN THE DEVELOPMENT OF SOFTWARE
Волошин Игорь Петрович
Voloshin Igor Petrovich
кандидат технических наук, доцент, заведующий кафедрой информационных систем в экономике, ССЭИ (филиал) РЭУ им. Г.В. Плеханова, Саратов
Cand. Sc. (Technical Sciences), associate professor, head of the department of information systems in economics, Saratov socio-economic institute (branch) of Plekhanov Russian University, Saratov
e-mail: voloshin.i.p@gmail.com
Каждая фаза разработки программного обеспечения жизненного цикла является уязвимой к различным типам факторов риска. Выявление и понимание этих рисков является предварительным этапом для успешного управления рисками. Данная статья представляет собой всеобъемлющее теоретическое исследование основных факторов риска, угрожающих каждой из фаз. Был составлен исчерпывающий перечень из 58 факторов риска. Этот список отражает наиболее часто встречающиеся факторы риска, которые являются общими для большинства проектов разработки программного обеспечения.
Ключевые слова: фактор риска, этапы разработки программного обеспечения.
The paper argues that each stage of software development life cycle is vulnerable to different types of hazards. Identifying and understanding these hazards is a preliminary stage for successful risk management. The paper contains a comprehensive theoretical study of major risk factors that threaten each stage and presents an exhaustive list of 58 risk factors. The list includes most typical risk factors that are common to most software development projects.
Keywords: risk factors, software development stages.
Состав процессов жизненного цикла регламентируется международным стандартом ISO/ IEC 12207: 1995 Information Technology -Software Life Cycle Processes (Информационные технологии - Процессы жизненного цикла программного обеспечения).
Разработка программного обеспечения является рискованным процессом и подвержена рискам с самого начала проекта до окончательной приемки программного продукта. Каждый этап восприимчив к различным наборам угроз, которые могут помешать процессу разработки от успешного завершения. Для управления этими рисками необходимо адекватное понимание процесса разработки программного обеспечения в проблемы, риски и причины их возникновения. Таким образом, первый шаг в управлении этими рисками заключается в определении их.
Идентификация программного обеспечения рисков представляет собой процесс выяв-
ления предметов, которые представляют угрозу для успеха проекта программного обеспечения.
В литературе можно найти много перечней факторов риска, но большинство из этих списков относительно короткие. Тем не менее, исследователи не могут отрицать, что невозможно привести полный перечень факторов риска программного обеспечения, так как они поняли, что эти факторы риска непрерывно изменяются с течением времени и появлением новых инструментов и технологий.
Этап сбора и обработки требований является первым при создании программного обеспечения, в нем определены все системные службы, ограничения и цели. Технико-экономическое обоснование помогает в определении основных факторов риска, с которыми могут столкнуться при разработке, развертывании системы и анализе.
Факторы риска для данного этапа приведены в табл. 1.
Таблица 1
Факторы риска на этапе анализа и определения требований
Фактор риска Описание
Нереальный график Расчетное время для проекта в целом может превышать срок поставки, согласованный ранее
Окончание табл. 1
Фактор риска Описание
Нереальный бюджет Предполагаемый бюджет в основном зависит от требуемого времени, усилий и ресурсов. Стоимость проекта может превысить имеющийся бюджет
Неопределенный функционал проекта Руководитель не всегда четко определяет основные и дополнительные функциональные возможности проекта
Недостаточность ресурсов Имеющихся ресурсов (люди, инструменты, технологии) недостаточно для завершения проекта. Или проект не может быть реализован с использованием имеющихся технологий, так как предполагает использование новых технологий
Нечеткие требования Требования остаются неясными, если они непонятны аналитикам и разработчикам
Неполные требования Заказчик не может описать более 60 % от общего числа требований в начале проекта, а следовательно, в течение разработки требования будут изменяться
Неточные требования Требование являются неточными, если они не отражают реальные потребности пользователей
Игнорирование не функциональных требований Аналитики и разработчики иногда сосредотачиваются на том, что система должна делать и игнорируют, как система должна выглядеть
Конфликт пользовательских требований Несогласованность при анализе требований различными пользователями (требования могут быть не только различны, но и противоречивы)
Нечеткое описание среды функционирования Отсутствие четкого описания среды функционирования программного обеспечения
Непроверяемые требования Выполнение требования невозможно проверить
Неосуществимые требования Требование не может быть реализовано в рамках ограничений проекта (недостаточность ресурсов)
Неотслеживаемые требования Отсутствие документальных источников происхождения каждого требования для справочных целей
Различная предметно-ориентированная терминология Специалисты и разработчики приложений используют предметно-ориентированную терминологию. Но она непонятна большинству конечных пользователей, что может привести к недоразумениям между обеими сторонами
Описание требований на естественном языке Некоторые выражения, термины и потребности не могут быть выражены естественным языком
Противоречивые данные Существование несоответствия между реальными данными и задокументированными
Невозможность модификации требований Документ формируется заново, если появится необходимость внесения изменений
Конструирование является вторым этапом в создании программного обеспечения, в нем устанавливается общая архитектура системы. На этом этапе система программного обеспечения описана в терминах основных компонентов и отношений. Данный этап включает в себя
несколько видов деятельности: изучение требований документа, выбор метода архитектурного дизайна, выбор языка программирования, построение физической модели, проверка, уточнение и документирование проектных работ. Факторы риска для данного этапа приведены в табл. 2.
Таблица 2
Факторы риска на этапе конструирования
Фактор риска Описание
Документация непонятна для разработчика Если разработчик не был привлечен на первом этапе, то он может разработать систему, отличную от предполагаемой
Неправильный выбор метода проектирования Выбор метода архитектурного проектирования может влиять на выбор языка программирования и на требования к аппаратному обеспечению
Неправильный выбор языка программирования Ненадлежащий выбор языка программирования может повлиять на процесс разработки, а также снизить эксплуатационную надежность и портативность системы
Информспщонная безопасность регионов. 2016. № 3(24)
Окончание табл. 2
Фактор риска Описание
Сложная конструкция Разработчики, не имеющие достаточных навыков и опыта работы с такими системами, будут создавать сложную, непонятную конструкцию
Отсутствует опыт для многократного использования Повторное использование не всегда правильный выбор при отсутствии опыта поддержания старых компонентов с целью повторного использования
Меньше повторяемых блоков, чем ожидалось Если оценка доступных повторно используемых блоков была сделана на этапе сбора и обработки требований неточно, то эти компоненты должны быть разработаны с нуля
Трудности при проверке соответствия конструкции требованиям Разработчик затрудняется проверить соответствие полученной конструкции заявленным требованиям
Множество возможных решений Затруднения при выборе варианта решения
Некорректное проектирование При проверке конструкции может быть установлено, что конструкторская документация не соответствует некоторым требованиям
Трудности в распределении функций компонентов Система не была правильно разложена на компоненты и не были определены функции и цели для каждого компонента
Обширная спецификация Обширная спецификация компонентов обычно несущественна на этапе разработки, и следует избегать уменьшения конструкционной документации
Избыточность передаваемых данных Большой объем нетребуемых передаваемых данных может привести к снижению работоспособности системы
Неполная проектная документация Проектно-техническая документация недостаточно подробна, что не позволяет программистам работать независимо друг от друга
Большой объем проектной документации Чересчур подробная спецификация приводит к нечитаемости проектной документации
Фактическое развитие системы начинается, когда программирование переходит на этап выполнения ранее определенного дизайна в виде набора программ или программных модулей.
Этот этап включает в себя два основных направления деятельности: кодирование и тестирование блоков итерационным способом. Факторы риска для данного этапа приведены в табл. 3.
Таблица 3
Факторы риска на этапе кодирования и тестирования
Фактор риска Описание
Неверная разработка пользовательских функций Если проект документа был непоследовательным, то программисты могут неправильно закодировать пользовательские функции
Разработка неправильного пользовательского интерфейса Разработка правильного пользовательского интерфейса требует хорошего понимания потребностей пользователей и подробные спецификации в разработке
Модули разработаны разными программистами Сложность сборки отдельных модулей, разработанных разными программистами, в систему из-за различающегося образа мышления и кодирования
Неоднозначность и противоречивость кода Программист во время кодирования может не соответствовать стандартам кодирования и передовой практики в области программирования, что приведет к неоднозначности и противоречивости кода
Различные версии компонентов Могут существовать разные версии одного и того же компонента, вызывающие проблемы в интеграции
Разработка компонентов с нуля Разрабатываемый заново компонент займет больше времени и усилий, чем многократно используемый компонент
Большое количество повторяющегося кода Некоторые повторяющиеся фрагменты кода переписаны несколько раз вручную
Неопытные программисты Допущение синтаксических ошибок и получение сложного и неоднозначного кода
Окончание табл. 3
Фактор риска Описание
Высокая частота отказов в недавно разработанных компонентах Большое количество ошибок во вновь создаваемых компонентах
Код непонятен тестировщи-кам Разработчик должен выполнять модульное тестирование для исправления ошибок на промежуточном этапе
Отсутствие полных автоматизированных средств тестирования Отсутствие автоматизации тестирования приводит к увеличению продолжительности тестирования
Неформальный и плохо понимаемый процесс тестирования Процесс тестирования практикуется неформально путем адаптации интуитивных методов
Не все ошибки обнаружены при модульном тестирования Использование некоторых методов испытаний и отсутствие средств автоматизации тестирования приводит к нераскрытости некоторых ошибок в ходе модульного тестирования
Плохое документирование тестирования Тестовые случаи должны быть задокументированы автоматически при выполнении тестирования
Это заключительная фаза в проектировании ствующие неисправности. Этот этап включает
и обычно самая длинная фаза, в которой про- в себя следующие виды деятельности: монтаж,
граммное обеспечение поставляется заказчи- эксплуатацию, приемо-сдаточные испытания
ку, разворачивается, тестируется на приемле- и техническое обслуживание. Факторы риска
мость для пользователя и устраняются суще- для данного этапа приведены в табл. 4.
Таблица 4
Факторы риска на этапе внедрения
Фактор риска Описание
Проблемы установки Сотрудники не имеют достаточного объема знаний и навыков по установке данного типа систем
Воздействие на окружающую среду Трудности взаимодействия с другим программным обеспечением
Изменение окружающей среды Длительная разработка системы может привести к ситуации, когда требования к аппаратному обеспечению сильно устарели
Возникновение новых требований Во время работы системы конечные пользователи могут обнаружить, что новые требования должны быть реализованы для удовлетворения текущих реальных потребностей пользователей, бизнеса, экологических и организационных изменений
Трудности в использовании системы Длительное время продолжающиеся трудности в работе конечных пользователей вновь установленной системы могут поставить под угрозу приемлемость системы
Саботирование внедрения конечными пользователями Большое влияние на успешность завершения проекта или его неудачу оказывают конечные пользователи
Недостающие возможности Ведение приемочного тестирования конечными пользователями может найти некоторые из пропущенных необходимых потребностей в недавно установленной системе
Позднее обнаружение ошибок Обнаружение и исправление ошибок на этапе внедрения обходится дороже
Недостатки при обработке данных Когда система введена в реальную эксплуатацию, она может быть перегружена большим количеством данных, которые не могут быть обработаны из-за недостатков в системе
Трудности описания проблемы Трудности описания клиентом проблемы в программном обеспечении
Информагщонная безопасность регионов. 2016. № 3(24)
Окончание табл. 4
Фактор риска Описание
Проблемы в изменчивости системы Система может быть трудноизменяемой по своей природе из-за жесткой архитектуры или ограничений, навязанных конечными пользователями или разработчиками
Превышение бюджета Стоимость повторения этих мероприятий может превышать имеющийся бюджет, в результате чего на этапе эксплуатации и технического обслуживания бюджет можно сократить, пока система еще не принята
В этом исследовании мы попытались создать полный список факторов риска программного обеспечения, который охватывает широкий спектр угроз. Этот список может служить
в качестве контрольного, им может руководствоваться проектная группа в определении вероятных факторов риска и оказать помощь в разработке стратегий для снижения риска.
Библиографический список (References)
1. Boehm B.W. (1989) Software Risk Management. Washington, DC : IEEE Computer Society Press.
2. Gilb, T. (1988) Principles of Software Engineering Management. Wokingham : Addison-Wesley.
3. Manager's Handbook for Software Development, Revision 1. Document number SEL-84-101 / NASA Software Engineering Laboratory, Goddart Space Flight Center, Greenbelt, MD. 1990.
4. Ramsin, R. (2008) Process-Centered Review of Object-Oriented Software Development Metodologies / R. Ramsin, R. Paige // ACM Computer Surveys. February. V. 40. № 1.
5. The Standish Group. Charting the Seas of Information Technology / The Standish Group. Dennis, MA : The Standish Group, 2007.
6. Макконнелл С. Остаться в живых. Руководство для менеджера программных проектов. Библиотека программиста. СПб.: Питер, 2006. 240 с.
Makkonnell S. (2006) Ostat'sya v zhivykh. Rukovodstvo dlya menedzhera programnmykh proyektov. Bib-lioteka programmista [Software Project Survival Guide]. St Petersburg : Piter. 240 p.
7. Макконнелл С. Совершенный код. Мастер-класс. М.: Рус. Редакция ; СПб.: Питер, 2007. 896 с. Makkonnell S. (2007) Sovershennyy kod. Master-klass [Code Complete]. Moscow : Rus. Redaktsiya ;
St Petersburg : Piter. 896 p.
8. Мораско Дж. IT-проекты: фронтовые очерки. СПб.: Символ-Плюс, 2007. 384 с.
Morasko Dzh. (2007) IT-proyekty: frontovyye ocherki [IT-projects. Frontline Sketches]. St Petersburg : Simvol-Plyus, 384 p.
