CC BY
45ЧАСТНОПРАВОВЫЕ (ЦИВИЛИСТИЧЕСКИЕ) НАУКИ
УДК 347.4
DOI: 10.17072/2619-0648-2023-2-73-88
ДОГОВОР НА РАЗРАБОТКУ И ВНЕДРЕНИЕ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ:
ПРИЧИНЫ ОШИБОК И ПРАВИЛА ПРОВЕРКИ КАЧЕСТВА
О. С. Ерахтина
Кандидат юридических наук, доцент, доцент кафедры гражданского и предпринимательского права
Пермский филиал Национального исследовательского университета «Высшая школа экономики» 614070, Россия, г. Пермь, ул. Студенческая, 38
E-mail: oerahtina@hse.ru
Аннотация: в статье рассматривается проблема оценки качества программного обеспечения. Программные продукты являются объектом, ожидаемые свойства и потенциальные дефекты которого не могут быть точно охарактеризованы. Риски проявления ошибок программного обеспечения трудно прогнозировать. Столь сложный характер работ по созданию ПО обусловливает проблемность, а зачастую и невозможность указать в договоре его четкие качественные характеристики. Автор исследует элементы программного обеспечения, их функциональные характеристики; определяет причины проявления ошибок в программе и возможные способы их обнаружения и фиксации. Отдельное внимание в статье уделено вопросам о содержании и структуре технического задания на разработку ПО, а также о порядке проведения его тестирования и приемки.
Ключевые слова: элементы программного обеспечения; качество программного обеспечения; ошибки программы; техническое задание; тестирование
© Ерахтина О. С., 2023
DEVELOPMENT AND IMPLEMENTATION OF SOFTWARE: CAUSES OF ERRORS AND QUALITY TESTING RULES
O. S. Erahtina
National Research University Higher School of Economics Perm
38, Studencheskaya st., Perm, 614070, Russia
E-mail: oerahtina@hse.ru
Abstract: the article considers the problem of assessing the quality of software. Software products are a complex object, the expected properties and potential defects of which cannot be accurately characterized. The risks of manifestation of software errors are difficult to predict. The complex nature of the work on creating on the complexity is determined, and often the inability to determine in the contract its clear qualitative characteristics. The author explores software elements, their functional characteristics; determines the causes of errors in the program, possible ways to identify and fix them. Separate attention in the article is paid to issues about the content and structure of the technical specifications for the development of software, as well as the procedure for conducting its testing and acceptance. Keywords: software elements; software quality; program errors; technical specifications; testing
На данном этапе информационно-технологического развития решение задачи повышения уровня качества программных разработок приобретает первостепенное значение. Сегодня профессиональная деятельность практически в любой области немыслима без использования программного обеспечения (ПО), применение прикладного и системного ПО призвано качественно и оперативно решать профессиональные задачи. Однако процессы создания (разработки) и внедрения программного обеспечения, а также порядок заключения и исполнения договоров в данной сфере практически не регулируются российским гражданским законодательством. В отсутствие надлежащего правового регулирования стороны сами определяют требования к качеству ПО, порядку его приемки, а также условия ответственности разработчика. При этом, как показывает практика и отмечается в научной литературе1, договоры на разработку и внедрение ПО серьезно ограничивают
1 Liability in Software Engineering: Overview of the LISE Approach and Illustration on a Case Study / D. Métayer, M. Maarek, E. Mazza [et al.] // ICSE 10: Proceedings of the 32nd ACM/IEEE International
или даже полностью исключают ответственность разработчика за качество программного обеспечения. Для объяснения необходимости ограничения ответственности разработчиков приводится следующий аргумент: программные продукты являются сложным универсальным объектом, ожидаемые свойства и потенциальные дефекты которого не могут быть точно охарактеризованы.
Действительно, программное обеспечение является особым интеллектуальным продуктом и для его разработки требуются специальные высококвалифицированные знания. Комплексный характер работ по созданию ПО и плохо прогнозируемые риски проявления его ошибок обусловливают сложность, а зачастую невозможность определения в договоре четких качественных характеристик основных элементов ПО. Дефекты и уязвимости программы не всегда могут быть выявлены рядовой проверкой. Вместе с тем, не замеченные пользователем на этапе приемки, они могут стать критичными для последующей работы ПО.
На вопрос о том, можно ли создать программное обеспечение, которое не содержит ошибок, специалисты в сфере информационных технологий (IT) не дают оптимистичных ответов. Джейк Моррисон, управляющий директор Cogini - компании по разработке инновационных приложений, отвечает так: «Можно создать программное обеспечение, не содержащее ошибок, но, вообще говоря, более важно, чтобы вы, представив программное обеспечение пользователям, могли развивать его в соответствии с их потребностями»2. За исключением относительно простых вещей, очень сложно получить программное обеспечение на основе заранее определенных параметров. Разработчик микросхем Intel Кристофер Ф. Кларк приводит пример, когда ему потребовалось двадцать семь месяцев, чтобы придумать решение, которое лишь незначительным образом исправило ошибку программы: девять месяцев поиска ошибки, девять месяцев переписывания и повторного тестирования, чтобы найти ошибку, которая появилась в процессе переписывания, и еще девять месяцев, чтобы придумать приемлемое (не оптимальное!) ре-
Conference on Software Engineering. Cape Town, South Africa, 1-8 May 2010. Vol. 1. NY: Association for Computing Machinery, 2010. Pp. 135-144. URL: https://www.researchgate.net/publication/ 220266149_Liability_in_software_engineering_overview_of_the_LISE_approach_and_illustration_ on_a_case_study.
2 What is Meant by Reproducing a Bug in Software Development? URL: https://translated.turbo-pages.org/proxy_u/en-ru.ru.86f9bb11-63898b82-66eda2a9-74722d776562/https/www.quora.com/ What-is-meant-by-reproducing-a-bugin-software-Development.
шение, - но через двадцать семь месяцев он отказался от этой идеи3. М. Виноградов, один из основателей АМ Lab, также отмечает, что программы без ошибок - нонсенс. Для разработчиков вопрос обычно состоит не в том, существуют ли ошибки, а в том, насколько целесообразен выпуск программы в таком виде в данный момент времени. Решение о моменте выхода программы основывается на компромиссе между страхом потерять пользователей из-за ошибок и недоработок в программе и страхом «отдать» потенци-
4
альных пользователей конкурентам из-за задержки с выпуском .
Специалисты в сфере IT-разработок также едины в мнении о том, что чем сложнее программа, тем выше вероятность ошибок. Более того, не всегда именно реальные ошибки разработчика приводят к ошибкам программы. Последние могут возникать, в частности, из-за ошибки в проектировании программы либо при написании ее исходного кода, из-за неправильной настройки ПО, вследствие несанкционированного изменения режима работы устройств и программ либо несанкционированного внедрения и использования неучтенных программ с последующим неучтенным расходованием ресурсов (захват оперативной памяти), из-за атак безопасности и по многим другим причинам.
Таким образом, существует большая вероятность материализации риска ошибки в работе программы. При этом чем сложнее программа, тем сложнее определить причину такой ошибки. И все же при решении вопроса о наличии оснований для привлечения разработчика к ответственности за нарушение требований к качеству ПО вопрос о причине ошибки, допущенной программой, является ключевым.
Однако несмотря на то, что ограничение в ответственности разработчика за качество программных продуктов имеет объективное объяснение, очевидно, что такая практика не будет способствовать разработке высококачественного ПО. Индустрия программного обеспечения должна иметь достаточные экономические и правовые стимулы для применения строгих правил разработки и проверки качества ПО.
Цель данной статьи - определить причины программных ошибок и основные правила проверки качества программного обеспечения.
3 What is Meant by Reproducing a Bug in Software Development?..
4 Виноградов М. Правовое регулирование оборота компьютерных программ. URL: http://www. amlab.ru/law/paper_pravo_content.htm.
Структурно-функциональный анализ понятия «программное обеспечение»
На наш взгляд, определение требований к качественным характеристикам программного обеспечения и условий ответственности за их нарушение должно быть основано на структурно-функциональном анализе понятия «программное обеспечение». Гражданский кодекс РФ данное понятие не определяет. Вместе с тем в статье 1261 ГК РФ содержится определение понятия «программа для ЭВМ». Анализируя его, К. С. Головин выделяет следующие элементы компьютерной программы:
- объективная форма,
- исходный текст,
- объектный код,
- подготовительные материалы,
- совокупность данных и команд,
- порождаемые аудиовизуальные отображения5.
Приведем краткую характеристику каждого из названных элементов. В отличие от других объектов авторского права, объективная форма выражения программы для ЭВМ тесно связана с возможностью ее восприятия человеком при помощи компьютера. В соответствии с ГОСТ Р 54593-2011 исходный код - «компьютерная программа в текстовом виде на каком-либо языке программирования»6. Объектный код - это машиночитаемая версия исходного кода для исполнения ЭВМ. «Преобразование исходного кода в объектный... происходит с помощью компиляции, а обратно - с помощью декомпиляции; оба действия являются техническими приемами, которые необходимы для преобразования кодов с изменением кодировки и структу-ры»7. Подготовительные материалы создаются в процессе написания программы для ЭВМ, обычно на стадии проектирования. К ним относятся черновики исходного кода, схемы взаимодействия модулей программы, тестовые версии программы и другие материалы. Компьютерную программу образует
5 Головин К. С. Характеристика и классификация элементов программы для ЭВМ // Общество, образование, наука в современных парадигмах развития: материалы III Нац. науч.-практ. конф. (17-18 октября 2022 г.). Керчь: КГМТУ, 2022. С. 321. URL: https://www.kgmtu.ru/documents/ nauka/obchshestvo_obrazovanie_nauka_v_sovremennyh_paradigmah_razvytiya-2022.pdf.
6 Информационные технологии. Свободное программное обеспечение. Общие положения: ГОСТ Р 54593-2011: нац. стандарт Рос. Федерации: утв. и введ. в действие Приказом Росстан-дарта от 6 дек. 2011 г. № 718-ст: дата введ. 2012-01-01. М.: Стандартинформ, 2018. С. 2.
7 Головин К. С. Указ. соч. С. 322.
совокупность алгоритма и команд для его реализации. Последовательное выполнение команд приводит к решению поставленной пользователем задачи. Аудиовизуальные отображения также являются элементом программы для ЭВМ. Одна из их форм - графический интерфейс, необходимый для взаимодействия человека с программой, ввода и вывода информации.
Полагаем, что структурно-функциональный анализ конкретной компьютерной программы на этапе ее разработки позволит установить четкие требования к каждому из ее элементов. Кроме того, он позволит распределить риски и ответственность между сторонами договора на разработку и внедрение программного обеспечения. Как показывает практика, в большинстве случаев сбои в программе возникают из-за ошибок, допущенных разработчиком в ее исходном коде. Очевидно, что ответственность за такого рода ошибки должна быть возложена на разработчика. В ряде случаев причиной сбоя может стать некорректная работа компилятора, вырабатывающего некорректный код. Вопрос об ответственности разработчика за такую ошибку требует отдельного исследования.
Соотношение понятий «программа для ЭВМ» и «программное обеспечение»
В научной литературе нет единого мнения о том, как соотносятся между собой понятия «программа для ЭВМ» и «программное обеспечение». Так, например, А. И. Савельев отождествляет данные понятия и указывает на то, что на практике широко применяется «понятие "программное обеспечение" (software), более характерное для среды IT-специалистов и бизнес-сооб-щества»8. М. А. Рожкова, напротив, отмечает, что программное обеспечение, помимо собственно программы (совокупности программ), включает в свой состав дополнительные материалы, необходимые для его эффективного использования. Вместе с тем различия между обозначенными понятиями для целей права, по ее мнению, не являются принципиальными, что позволяет
9
рассматривать эти термины как синонимичные, взаимозаменяемые .
8 Савельев А. И. Актуальные вопросы судебной практики в сфере оборота программного обеспечения в России // Вестник Высшего Арбитражного Суда Российской Федерации. 2013. № 4. С. 5.
9 Рожкова М. А. Понятие компьютерной программы (программы для ЭВМ) в российском праве (подробный комментарий к статье 1261 Гражданского кодекса) // Право цифровой экономики - 2022: ежегодник-антология. М.: Статут, 2022. С. 41.
В контексте настоящего исследования данный вывод представляется спорным. ГОСТ 19781-9010 определено, что программное обеспечение есть «совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ» (п. 5). Схожее определение содержится и в ГОСТ Р 51904-2002: в пункте 3.47 указано, что программное обеспечение представляет собой «совокупность компьютерных
программ и программных документов, необходимых для эксплуатации этих
11
программ» .
Как утверждает А. А. Алексейчук, с технической точки зрения под программным обеспечением понимают совокупность:
- одной или нескольких компьютерных программ;
- библиотек (совокупность ресурсов различной природы, используемых компьютерной программой);
- связанных с компьютерными программами данных иной природы12.
Таким образом, программное обеспечение может включать в себя одну или несколько программ для ЭВМ, а также иные элементы: тексты, изображения, звуки, базы данных, мультимедийные продукты и др.
Для определения требований к качеству ПО выявление всех его структурных элементов имеет важное значение. Необходимо, в частности, учитывать, что программисты, как правило, пользуются в своих программах сторонними библиотеками. Библиотека - это код на конкретном языке (библиотечный код), который вызывается другим кодом на этом же языке (клиентский код). Данное разделение является значимым, так как у каждой из этих частей своя зона ответственности. В настоящей работе не исследуются причины возникновения ошибок в работе библиотек и других элементах ПО и возможные способы их выявления и устранения. Вместе с тем решение данных вопросов представляется важным при определении правил разработки и проверки качества ПО.
10 Обеспечение систем обработки информации программное. Термины и определения. Единая система программной документации: ГОСТ 19781-90: утв. и введ. в действие Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 27 авг. 1990 г. № 2467: дата введ. 1992-01-01. М.: Стандартинформ, 2010. С. 1.
11 Программное обеспечение встроенных систем. Общие требования к разработке и документированию: ГОСТ Р 51904-2002: утв. и введ. в действие Постановлением Госстандарта России от 25 июня 2002 г. № 247-ст: дата введ. 2003-07-01. М.: Стандартинформ, 2005. С. 3.
12 Алексейчук А. А. Подходы к квалификации сложного программного обеспечения // Право цифровой экономики - 2020: ежегодник-антология. М.: Статут, 2020. С. 347.
Основные требования к качеству программного обеспечения
Качество программного обеспечения - совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности13.
Обеспечение качества (quality assurance) - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения информационных систем и реализуемых на разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества выпускаемого продукта.
Обеспечение качества программного обеспечения представляет собой сложный и многоэтапный процесс. На первом этапе необходимо определить требования к качественным характеристикам. В стандарте ISO 912614 выделено шесть основных характеристик качества ПО:
- функциональность (functionality),
- надежность (reliability),
- удобство использования (usability),
- эффективность (efficiency),
- удобство сопровождения (maintainability),
- переносимость (portability).
Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Так, атрибутами функциональности являются способность к взаимодействию, функциональная пригодность, соответствие стандартам, защищенность, точность. Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126-1:200115 определяет наборы метрик для оценки каждого атрибута. Например, для измерения функциональной пригодности используется метрика «полнота реализации функций» (процент реализованных функций по отношению к перечисленным в требованиях), а для определения зрелости программы - показатель «отношение числа обнаруженных дефектов к прогнозируемому».
Как уже было указано, определение требований к качеству программного обеспечения осуществляется в несколько этапов. На первом этапе выявляются требования к программному обеспечению. Сторонам необходимо
13 ISO 8402 1994. Quality management and quality assurance.
14 ISO 9126. International standard for the evaluation of software quality.
15 ISO 9126-1:2001. Quality model.
составить представление о том, кто будет конечным пользователем продукта и для решения каких целей бизнеса создается ПО; изучить среду, в которой продукт будет использован; определить потребности и ожидания пользователя. На втором этапе разрабатывается технический прототип, тестирование которого позволит определить, верно ли заявлены требования к создаваемому ПО. На третьем этапе проводится детальный анализ требований к ПО. Требования распределяются по компонентам ПО, выявляются некорректные, избыточные и недостающие требования, согласовываются приоритеты их реализации16. Реализация менее приоритетных требований будет возможна на этапе улучшения готового продукта. На четвертом этапе осуществляется документирование и утверждение требований к ПО.
Техническое задание на разработку ПО
Основным документом, в котором определяются качественные характеристики программного обеспечения, является техническое задание (ТЗ), которое содержит не только требования к качеству продукта, но и требования к документации, информацию о стадии и этапах разработки, порядке контроля и приемки ПО. При разработке ТЗ следует также руководствоваться ГОСТами17.
В ТЗ формулируются исходные требования заказчика: назначение и цели создания ПО, основные характеристики и требования к каждому элементу ПО, требования к эксплуатации и техническому обслуживанию ПО. Здесь также определяются порядок, содержание, этапы и сроки выполнения работ, ожидаемые результаты18. При этом должны быть указаны объективные критерии, по которым впоследствии можно было бы определить, выполнен ли тот или иной этап работ, достигнуты ли ожидаемые результаты.
16 Особенности разработки требований к программному обеспечению / Ж. Даниярулы, М. Рыс-паева, М. Кажиманова [и др.] // Science and Technology Research: сб. ст. II Междунар. науч.-практ. конф. (15 марта 2021 г.). Петрозаводск: МЦНП «Новая наука», 2021. С. 47-56.
17 Техническое задание. Требования к содержанию и оформлению: ГОСТ 19.201-78: утв. и введ. в действие Постановлением Государственного комитета СССР по стандартам от 18 дек. 1978 г. № 3351: дата введ. 1980-01-01. М.: Стандартинформ, 2010. С. 1; Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы: ГОСТ 34.602-89: утв. и введ. в действие Постановлением Государственного комитета СССР по стандартам от 24 марта 1989 г. № 661: дата введ. 1990-01-01. М.: Стандартинформ, 2009. С. 2.
18 Как правило, суды удовлетворяют требования об устранении недостатков в разработанном ПО при условии, что техническое задание предусматривает все надлежащие характеристики. См., например: Постановление Арбитражного суда Уральского округа от 14 окт. 2016 г. № Ф09-9185/16 по делу № A50-80/2016.
В разработке технического задания должны участвовать как представители заказчика, так и представители исполнителя. Однако, как правило, на этапе заключения договора заказчик с ГОСТами не знаком и плохо представляет, каким характеристикам должен отвечать результат работ, не говоря уже о том, как провести оценку атрибутов качественных характеристик ПО. ТЗ составляет разработчик, используя документацию своих предыдущих проектов. При этом недобросовестный разработчик может установить к результату работ «размытые требования», которые при возникновении спора допускают неоднозначное толкование.
Отдельные пункты техзадания могут изменяться и уточняться по согласованию сторон. Все изменения, дополнения и уточнения формулировок должны быть обязательно согласованы с заказчиком. В случае обнаружения в процессе эксплуатации ПО неточностей или ошибок в исходных данных неизбежно возникнет необходимость определения степени вины каждой из сторон договора.
Грамотно составленное ТЗ предоставит заказчику возможность последующего контроля за соблюдением требований к качеству ПО. Поэтому очень важно, чтобы все атрибуты качественных характеристик ПО, а также способы оценки контроля были ему понятны. И каждый пункт ТЗ должен однозначно трактоваться как заказчиком, так и исполнителем. В определенной мере этому будет способствовать включение в ТЗ глоссария.
Тестирование и приемка ПО
Тестирование - деятельность, направленная на обнаружение дефектов в программном обеспечении. Под дефектом или ошибкой безопасности следует понимать каждое отдельное несоответствие ПО установленным требованиям к безопасности19. Тестирование ПО также необходимо проводить в соответствии с требованиями ГОСТов20. Предварительные испытания организуются в присутствии заказчика, которому пошагово демонстрируется исполнение требований ТЗ.
19 Надежность в технике. Термины и определения: ГОСТ Р 27.002-2009: утв. и введ. в действие Приказом Федерального агентства по техническому регулированию и метрологии от 9 дек. 2009 г. № 649-ст: дата введ. 2011-01-01. М.: Стандартинформ, 2011. С. 2.
20 Информационная технология. Виды испытаний автоматизированных систем: ГОСТ 34.603-92: утв. и введ. в действие Постановлением Комитета стандартизации и метрологии СССР от 17 февр. 1992 г. № 161: дата введ. 1993-01-01. М.: Стандартинформ, 2009; Программа и методика испытаний. Требования к содержанию и оформлению: ГОСТ 19.301-79: утв. и введ. в действие Постановлением Государственного комитета СССР по стандартам от 11 дек. 1979 г. № 4753: дата введ. 1981-01-01. М.: Стандартинформ, 2010.
Определение однозначного, исчерпывающего перечня ожидаемых действий программного обеспечения является довольно сложной задачей, поэтому тестирование и приемка ПО производятся в несколько этапов. На первом этапе демонстрируется работоспособность ПО в соответствии с техническим заданием. Завершается первый этап тестирования подписанием протокола с указанием в нем перечня необходимых доработок ПО. После устранения замечаний осуществляется повторное тестирование ПО, которое завершается подписанием либо еще одного протокола с указанием на необходимые доработки ПО, либо акта приемки в опытную, а затем в промышленную эксплуатацию. Заказчик также может отказаться от подписания акта, указав на выявленные недостатки.
Однако заметим: если ошибки не были выявлены на этапе тестирования, равно как если все ошибки, выявленные на этапе тестирования, были устранены разработчиком, это не обеспечит стопроцентной гарантии корректности работы программы в течение обусловленного договором периода. Дефекты могут выявляться при определенных обстоятельствах в процессе эксплуатации ПО. Тестирование только снижает вероятность наличия дефектов в программном обеспечении, но не гарантирует их отсутствия21.
Классификация ошибок программного обеспечения
Как указывает Е. Б. Дроботун, применительно к надежности программного обеспечения «ошибка - это погрешность или искажение кода программы... которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования»22.
Классификация ошибок (обобщение их по типам) проводится по разным критериям. Как правило, она необходима для управления процессом обнаружения и исправления ошибок.
Ошибки программного обеспечения подразделяются на три основных
типа:
- ошибки ПО по своей природе (характеру);
- ошибки ПО по их критичности;
- ошибки ПО по их приоритету.
Так, например, по характеру различают: функциональные ошибки (вызывают сбои в работе всего ПО или его отдельного модуля); ошибки уровня
21 Фундаментальная теория тестирования. URL: https://habr.com/ru/post/549054/.
22Дроботун Е. Б. Критичность ошибок в программном обеспечении и анализ их последствий // Фундаментальные исследования. 2009. № 4-S. С. 73.
интеграции (возникают при объединении двух или более программных модулей); ошибки, влияющие на производительность ПО (скорость, объем используемой памяти).
Существует несколько подходов к классификации ошибок по степени критичности. Так, Е. Б. Дроботун, основываясь на ГОСТ 51901.12-200723, делит ошибки на критические, существенные и несущественные. Критическая ошибка с высокой вероятностью влечет за собой прекращение функционирования программного обеспечения (его отказ). Проявление существенной ошибки влечет снижение эффективности функционирования ПО и может вызвать прекращение его функционирования (отказ). Несущественная ошибка способна снизить эффективность функционирования ПО и практически не приводит к возникновению отказа в нем (вероятность этого очень низка)24.
По степени приоритетности различают: ошибки с низким приоритетом (не оказывают серьезного влияния на работу программного обеспечения), ошибки со средним приоритетом (оказывают довольно серьезное влияние на работу ПО, но не мешают пользователю продолжить выполнение поставленной задач) и ошибки с высоким приоритетом (серьезно влияют на работу ПО и требуют немедленного исправления).
Сопровождение и техническое обслуживание ПО (SLA25)
Как уже было указано, одна из основных специфических особенностей программного обеспечения состоит в том, что его ошибки могут выявляться при определенных обстоятельствах в процессе эксплуатации. Кроме того, существует риск, что техническое задание не будет учитывать всех необходимых особенностей сервиса, поскольку зачастую они тоже могут быть выявлены только при эксплуатации ПО. В связи с этим в договоре на разработку и внедрение ПО должны быть подробно описаны условия технического обслуживания. В частности, необходимо определить объем техобслуживания, указать, как пользователи будут запрашивать изменения или информировать о проблемах. В договоре также следует указать сроки устранения выявленных ошибок (в зависимости от их приоритета). Как правило, в договор вклю-
23 Менеджмент риска. Метод анализа видов и последствий отказов: ГОСТ 51901.12-2007: утв. и введ. в действие Приказом Федерального агентства по техническому регулированию и метрологии от 27 дек. 2007 г. № 572-ст: дата введ. 2008-09-01. М.: Стандартинформ, 2008.
24Дроботун Е. Б. Указ. соч. С. 73-74.
25 Service Level Agreement, SLA - соглашение об уровне обслуживания.
чается и условие о том, что пользователь не вправе самостоятельно устранять ошибки ПО и вносить в него какие-либо изменения.
Период технического обслуживания зависит от характеристик ПО и в среднем составляет от одного месяца до одного года. Вместе с тем обслуживание и поддержка ПО необходимы не только для исправления ошибок, но и в целях улучшения его функциональности, адаптации к внешним изменениям.
Причины ошибок ПО и способы их выявления
Вопрос о причинах ошибок является ключевым при распределении рисков и ответственности между разработчиком и заказчиком за сбои в работе программы.
Прежде всего, при решении данного вопроса необходимо различать ошибки разработчика и ошибки программы. Как ранее было указано, ошибки программы могут возникать по разным причинам26: из-за ошибок разработчика в проектировании ПО либо при написании исходного кода, вследствие нарушения заказчиком требований безопасности применения ПО и несанкционированного вмешательства в его работу, из-за атак безопасности и т.д. Поэтому при возникновении сбоев в работе ПО нужно установить причину инцидента. Данная проблема становится все более актуальной вследствие возрастания сложности и разнообразия задач использования ПО.
В междисциплинарном исследовательском проекте LISE (Liability in Software Engineering) с участием юристов и специалистов по информационным технологиям предлагаются способы определения лица, виновного в инциденте. В проекте представлен специальный алгоритм для фиксирования процессов разработки и эксплуатации ПО27. В частности, предусмотрено использование журналов регистрации, позволяющих отслеживать и анализировать алгоритм создания ПО и, соответственно, определить причины его дефектов. Но для получения возможности использования журнальных файлов в качестве доказательств в суде сторонам еще задолго до возникновения спора необходимо определить все технические шаги для создания файлов журналов, способов их хранения и перечень средств, используемых для обеспечения их подлинности и целостности.
С. С. Коротких и К. С. Синюшин, изучая данный вопрос в контексте разработки государственных цифровых сервисов, указывают на необходимость
26 О дестабилизирующих факторах ПО см.: Черников Б. Ф. Управление качеством программного обеспечения: учеб. М.: Форум: ИНФРА-М, 2012. С. 19-25.
27 Liability in Software Engineering: Overview of the LISE Approach and Illustration on a Case Study...
внедрения независимого аудита таких сервисов техническими специалистами релевантного профиля28.
При возникновении спора о качестве ПО и причинах сбоев в его работе следует также отметить значимость экспертизы. В то же время, как справедливо указывает А. И. Савельев, не нужно переоценивать возможности экспертизы в исследовании вопросов о качестве разработанной программы: ее потенциал весьма ограничен в случаях, когда заказчику была передана разработанная программа вместе с исходным кодом, а спор касается скрытых недостатков и возник уже после подписания акта приемки сторонами. Основная проблема заключается в отсутствии «эталонной» программы, которую можно взять на экспертизу29.
Соглашаясь с данным выводом, необходимо вместе с тем указать, что при рассмотрении споров о качестве программного обеспечения суды, как
30 п
правило, назначают экспертизу . Практика рассмотрения споров о качестве ПО показывает, что суды ставят перед экспертами следующие вопросы:
1. Соответствуют ли объем и состав разработанного ПО требованиям и параметрам, установленным договором?
2. Способно ли программное обеспечение в том виде, в котором оно разработано, нормально функционировать и корректно выполнять операции, для которых оно создавалось в соответствии с договором?
3. Имеются ли в программном обеспечении в том виде, в котором оно разработано, недостатки и ошибки, наличие которых исключает возможность нормального функционирования указанного ПО и корректного выполнения операций, для которых оно создавалось в соответствии с договором?
4. Изменялось ли программное обеспечение в том виде, в котором оно разработано, кем-либо, за исключением разработчика?
5. Имеются ли признаки удаления, блокирования либо модификации данных внедренного программного продукта, внесения изменений в систему, форматирования системы?
28 Коротких С. С., Синюшин К. С. Грани ответственности: заказчик, разработчик, пользователь // Этика и «цифра»: этические проблемы цифровых технологий: аналит. доклад / Центр подготовки руководителей и команд цифровой трансформации; РАНХиГС. URL: https://cdto.ranepa. ru/reports/ethics/2021/7-1-grani-otvetstvennosti-zakazchik-razrabotchik-polzovatel7734130907.
29 Савельев А. И. Указ. соч.
30 См., например: Решение Арбитражного суда города Москвы от 22 июня 2016 г. по делу № А40-91171/15-5-733; Решение Арбитражного суда Саратовской области от 29 апр. 2021 г. по делу № А57-4773/2020; Решение Арбитражного суда Московской области от 2 июля 2021 г. по делу № А41-50802/20.
Заключение
Несмотря на то что ошибка есть имманентное свойство текущей версии программы, довольно часто сбои в работе ПО возникают из-за ошибок разработчиков. Так что сложившуюся практику ограничения ответственности разработчиков за качество создаваемого ПО нельзя признать отвечающей потребностям рынка IT-разработок.
Вопрос определения требований к разработке и проверке качества программного обеспечения является комплексным, многоаспектным и требует междисциплинарного изучения. Будучи сложным интеллектуальным продуктом, программное обеспечение состоит из нескольких взаимосвязанных элементов, и это необходимо учитывать при определении требований к его качеству. Основным документом, в котором отражаются качественные характеристики каждого элемента ПО, выступает техническое задание. В ТЗ необходимо также определить атрибуты качественных характеристик и метрики оценки каждого атрибута.
Формирование однозначного, исчерпывающего перечня ожидаемых действий ПО является весьма сложной задачей, поэтому тестирование и приемка ПО осуществляется в несколько этапов и на каждом из них необходимо составление протокола испытаний. При этом тестирование снижает вероятность наличия ошибок, но не гарантирует их отсутствия.
Вопрос о причине ошибки остается ключевым при распределении рисков и ответственности между разработчиком и заказчиком за сбои в работе программы. Поскольку сбои могут произойти по различным причинам (в частности, из-за ошибок разработчика, вследствие нарушения заказчиком требований безопасности применения ПО, из-за атак безопасности), необходимо использовать журнал регистрации, позволяющий отслеживать и анализировать алгоритм создания ПО и процесс его эксплуатации, и по возможности прибегать к независимому аудиту создаваемого ПО.
Библиографический список
Алексейчук А. А. Подходы к квалификации сложного программного обеспечения // Право цифровой экономики - 2020: ежегодник-антология. М.: Статут, 2020. С. 346-368.
Головин К. С. Характеристика и классификация элементов программы для ЭВМ // Общество, образование, наука в современных парадигмах развития: материалы III Нац. науч.-практ. конф. (17-18 октября 2022 г.). Керчь:
КГМТУ, 2022. С. 318-326. URL: https://www.kgmtu.ru/documents/nauka/ob-chshestvo_obrazovanie_nauka_v_sovremennyh_paradigmah_razvytiya-2022.pdf.
Дроботун Е. Б. Критичность ошибок в программном обеспечении и анализ их последствий // Фундаментальные исследования. 2009. № 4-S. С. 73-74.
Коротких С. С., Синюшин К. С. Грани ответственности: заказчик, разработчик, пользователь // Этика и «цифра»: этические проблемы цифровых технологий: аналит. доклад / Центр подготовки руководителей и команд цифровой трансформации; РАНХиГС. URL: https://cdto.ranepa.ru/reports/ethics/2021/ 7-1-grani-otvetstvennosti-zakazchik-razrabotchik-polzovatel.
Особенности разработки требований к программному обеспечению / Ж. Даниярулы, М. Рыспаева, М. Кажиманова [и др.] // Science and Technology Research: сб. ст. II Междунар. науч.-практ. конф. (15 марта 2021 г.). Петрозаводск: МЦНП «Новая наука», 2021. С. 47-56.
Рожкова М. А. Понятие компьютерной программы (программы для ЭВМ) в российском праве (подробный комментарий к статье 1261 Гражданского кодекса) // Право цифровой экономики - 2022: ежегодник-антология. М.: Статут, 2022. С. 10-61.
Савельев А. И. Актуальные вопросы судебной практики в сфере оборота программного обеспечения в России // Вестник Высшего Арбитражного Суда Российской Федерации. 2013. № 4. С. 4-36.
Черников Б. Ф. Управление качеством программного обеспечения: учеб. М.: Форум: ИНФРА-М, 2012.
Liability in Software Engineering: Overview of the LISE Approach and Illustration on a Case Study / D. Métayer, M. Maarek, E. Mazza [et al.] // ICSE 10: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering. Cape Town, South Africa, 1-8 May 2010. Vol. 1. NY: Association for Computing Machinery, 2010. Pp. 135-144. URL: https://www.researchgate.net/ publiction/220266149_Liability_in_software_engineering_overview_of_the_LISE_ approach_and_illustration_on_a_case_study.
Информация для цитирования
Ф Ерахтина О. С. Договор на разработку и внедрение программного обеспе-— чения: причины ошибок и правила проверки качества // Ex jure. 2023. № 2. С. 73-88. DOI: 10.17072/2619-0648-2023-2-73-88.
^ Erahtina O. S. Development and Implementation of Software: Causes of Errors Ш and Quality Testing Rules. Ex jure. 2023. № 2. Pp. 73-88. DOI: 10.17072/26190648-2023-2-73-88.
