ВВЕДЕНИЕ

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

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

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

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

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

---

ГЛАВА 1. ПОНЯТИЕ, СУЩНОСТЬ И ПРАВОВАЯ ПРИРОДА ЭКСПЕРТИЗЫ КОМПЬЮТЕРНОЙ ПРОГРАММЫ

1.1. Экспертиза компьютерной программы как самостоятельный вид экспертной деятельности

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

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

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

Сущность экспертизы компьютерной программы раскрывается через несколько взаимосвязанных аспектов.

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

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

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

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

Самостоятельность экспертизы компьютерной программы как вида экспертной деятельности подтверждается следующими признаками:

• специфический объект исследования — программное обеспечение, его компоненты, документация, среды функционирования, результаты испытаний;

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

• специальные методы — методы программной инженерии, тестирования, анализа кода, моделирования, которые не используются или используются ограниченно в других видах экспертиз;

• особый субъектный состав — эксперты, обладающие познаниями в области информационных технологий и программирования;

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

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

1.2. Правовая природа экспертизы компьютерной программы

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

Судебная экспертиза компьютерной программы назначается судом в порядке, предусмотренном процессуальным законодательством. В арбитражном процессе это регулируется главой 7 Арбитражного процессуального кодекса Российской Федерации, в гражданском процессе — главой 7 Гражданского процессуального кодекса Российской Федерации. Судебная экспертиза компьютерной программы может быть назначена как по ходатайству сторон, так и по инициативе суда, если для разрешения возникающих вопросов требуются специальные знания. Эксперт, проводящий судебную экспертизу компьютерной программы, предупреждается об уголовной ответственности за дачу заведомо ложного заключения, что повышает степень достоверности и ответственности его выводов.

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

Правовая природа экспертизы компьютерной программы также раскрывается через её соотношение с иными правовыми институтами:

• институт доказывания: заключение экспертизы компьютерной программы является доказательством, подлежащим оценке судом по правилам статей 67, 68, 71 Арбитражного процессуального кодекса Российской Федерации;

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

• институт интеллектуальной собственности: программное обеспечение является объектом авторского права, и экспертиза компьютерной программы может затрагивать вопросы авторства, правомерности использования, наличия заимствований;

• институт государственных закупок: значительная часть споров связана с исполнением контрактов по Федеральному закону «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». Экспертиза компьютерной программы здесь выступает инструментом контроля качества исполнения контракта.

Особенностью правовой природы экспертизы компьютерной программы является её выраженный технико-юридический дуализм. С одной стороны, эксперт оперирует техническими категориями — алгоритмы, структуры данных, интерфейсы, протоколы, метрики. С другой стороны, выводы эксперта должны быть сформулированы в юридически значимых терминах — «соответствует», «не соответствует», «работоспособно», «неработоспособно», «имеется дефект», «причина неисправности». Это требует от эксперта не только глубоких технических знаний, но и понимания правового контекста спора.

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

Наконец, правовая природа экспертизы компьютерной программы включает ответственность эксперта. За дачу заведомо ложного заключения эксперт несёт уголовную ответственность; за некачественное проведение экспертизы — дисциплинарную и гражданско-правовую. Это создаёт дополнительные гарантии достоверности результатов экспертизы компьютерной программы.

1.3. Соотношение судебной и досудебной экспертизы компьютерной программы

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

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

Досудебная экспертиза компьютерной программы проводится по инициативе стороны вне рамок судебного процесса. Она может быть организована как:

• заключение специалиста, привлекаемого стороной для оценки качества программного продукта;

• независимый аудит программного обеспечения;

• техническое исследование, проводимое экспертной организацией по договору;

• рецензия на ранее проведённую экспертизу.

Досудебная экспертиза компьютерной программы не имеет заранее установленной доказательственной силы. Её результаты могут быть представлены в суд, но суд оценивает их критически, особенно если экспертиза проведена по заказу заинтересованной стороны. Вместе с тем досудебная экспертиза компьютерной программы играет важную роль:

• она позволяет стороне оценить перспективы спора;

• она может стать основанием для направления претензии;

• она может побудить контрагента к добровольному урегулированию;

• она может быть использована для обоснования ходатайства о назначении судебной экспертизы;

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

Соотношение судебной и досудебной экспертизы компьютерной программы можно представить в виде таблицы:

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

1.4. Место экспертизы компьютерной программы в системе экспертных исследований

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

Нематериальная природа объекта. Программное обеспечение не имеет физической формы; оно существует в виде кода, записанного на носителе, но его сущность — алгоритмы, логика, функциональность — нематериальна. Это создаёт сложности при фиксации объекта, его идентификации, определении границ исследования.

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

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

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

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

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

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

Таким образом, экспертиза компьютерной программы может рассматриваться как самостоятельный вид экспертной деятельности, обладающий собственным предметом, объектом, методами и субъектным составом. Её выделение в отдельный вид обусловлено потребностями практики и развитием информационных технологий.

1.5. Значение экспертизы компьютерной программы для разрешения споров между разработчиком и заказчиком

Споры между разработчиком программного обеспечения и заказчиком — одна из наиболее сложных категорий дел в арбитражной и гражданско-правовой практике. Сложность обусловлена несколькими факторами:

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

• размытость требований. Технические задания часто формулируются нечётко, допускают различные толкования. Это порождает конфликт между заказчиком, который считает, что разработчик не выполнил требования, и разработчиком, который утверждает, что требования были выполнены, но заказчик их субъективно интерпретирует;

• проблема разграничения ответственности. Неисправность программного обеспечения может быть вызвана действиями разработчика (ошибки в коде), действиями заказчика (некорректная эксплуатация, изменение среды), действиями третьих лиц (вредоносное программное обеспечение, атаки), обстоятельствами непреодолимой силы. Установление истинной причины требует экспертного исследования;

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

• высокая стоимость спора. Государственные и муниципальные контракты на создание программного обеспечения исчисляются миллионами и миллиардами рублей. Ошибка в разрешении спора может привести к значительным потерям для бюджета или для бизнеса.

Именно в этих условиях экспертиза компьютерной программы приобретает ключевое значение. Она позволяет:

• установить факт исполнения или неисполнения обязательств. Эксперт определяет, создан ли программный продукт, передан ли он заказчику, соответствует ли он условиям контракта;

• установить факт надлежащего или ненадлежащего исполнения. Эксперт выявляет дефекты, оценивает их критичность, определяет, препятствуют ли они использованию продукта по назначению;

• установить причину неисправности. Эксперт определяет, является ли неисправность следствием действий разработчика, заказчика или третьих лиц;

• установить объём и стоимость выполненных работ. Эксперт оценивает, какая часть работ выполнена, какова их рыночная стоимость, соразмерна ли она уплаченной сумме;

• установить наличие или отсутствие заимствований. Эксперт проверяет, не использован ли в программном продукте чужой код, нарушены ли авторские права;

• оценить качество документации. Эксперт проверяет полноту и корректность технической документации, руководств пользователя, инструкций по развёртыванию.

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

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

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

---

ГЛАВА 2. ПРЕДМЕТ, ОБЪЕКТЫ И ЗАДАЧИ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНОЙ ПРОГРАММЫ

2.1. Предмет экспертизы компьютерной программы

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

Предмет экспертизы компьютерной программы не является статичным; он определяется вопросами, поставленными перед экспертом судом или стороной. Вместе с тем можно выделить типовые группы фактов, установление которых составляет содержание экспертизы компьютерной программы:

Факты, относящиеся к созданию программного продукта:

• создан ли программный продукт как таковой;

• соответствует ли он техническому заданию (функциональным, техническим, эксплуатационным требованиям);

• обладает ли он признаками оригинальности или является компиляцией чужих разработок;

• завершена ли разработка или она находится в промежуточной стадии.

Факты, относящиеся к работоспособности программного продукта:

• функционирует ли программный продукт в предусмотренной среде;

• обеспечивает ли он выполнение заявленных функций;

• соответствует ли производительность заявленным характеристикам;

• имеются ли критические дефекты, препятствующие использованию.

Факты, относящиеся к причинам неисправностей:

• обусловлена ли неисправность ошибками в коде;

• вызвана ли она некорректной настройкой или эксплуатацией;

• является ли она следствием несовместимости с другими программными продуктами;

• могла ли она быть вызвана внешним воздействием.

Факты, относящиеся к документации:

• соответствует ли документация фактическому состоянию программного продукта;

• достаточна ли она для эксплуатации и сопровождения;

• содержит ли она необходимые сведения о требованиях, ограничениях, настройках.

Факты, относящиеся к объёму и стоимости работ:

• какие работы фактически выполнены;

• какова их рыночная стоимость;

• соответствует ли стоимость выполненных работ уплаченной сумме;

• имело ли место неосновательное обогащение одной из сторон.

Факты, относящиеся к соблюдению технологических процессов:

• соблюдались ли стандарты разработки;

• проводилось ли тестирование;

• велось ли версионное控制;

• соблюдались ли требования информационной безопасности.

Предмет экспертизы компьютерной программы тесно связан с предметом доказывания по делу. Суд, назначая экспертизу, формулирует вопросы, которые должны быть разрешены экспертом. Эти вопросы должны быть:

• в пределах специальных знаний эксперта;

• сформулированы чётко и однозначно;

• направлены на установление обстоятельств, имеющих значение для дела;

• не требовать правовой оценки.

Например, вопрос «Является ли разработчик виновным в неисполнении контракта?» является неправомерным, поскольку требует правовой оценки. Вопрос «Имеются ли в программном продукте дефекты, препятствующие его использованию по назначению, и какова причина их возникновения?» является правомерным, поскольку требует специальных знаний.

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

2.2. Объекты экспертизы компьютерной программы

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

К объектам экспертизы компьютерной программы относятся:

Программный код:

• исходный код (тексты программ на языках программирования);

• объектный код (результат компиляции);

• исполняемые файлы;

• скрипты, конфигурационные файлы, файлы разметки.

Документация:

• техническое задание;

• проектная документация;

• архитектурная документация;

• руководство пользователя;

• руководство администратора;

• инструкции по развёртыванию;

• описание API;

• схемы баз данных.

Артефакты разработки:

• репозитории систем контроля версий;

• журналы изменений;

• протоколы тестирования;

• отчёты о дефектах;

• системы отслеживания задач.

Артефакты эксплуатации:

• журналы работы системы (логи);

• метрики производительности;

• отчёты об ошибках;

• обращения пользователей;

• акты приёмки.

Средства разработки и тестирования:

• интегрированные среды разработки;

• компиляторы;

• отладчики;

• системы автоматизированного тестирования.

Аппаратное обеспечение:

• серверы;

• рабочие станции;

• сетевое оборудование;

• носители информации.

Договорные документы:

• государственные и муниципальные контракты;

• договоры подряда;

• дополнительные соглашения;

• акты сдачи-приёмки;

• переписка сторон.

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

• сохранность исходных объектов;

• создание резервных копий;

• документирование состояния объектов;

• использование проверенных инструментов.

Объекты экспертизы компьютерной программы могут быть представлены в различных формах:

• натуральной — носители информации, аппаратные средства;

• документальной — договоры, акты, технические задания;

• электронной — файлы, базы данных, журналы;

• виртуальной — облачные сервисы, виртуальные машины, контейнеры.

Эксперт должен уметь работать со всеми формами представления объектов, применять соответствующие методы и инструменты.

2.3. Задачи экспертизы компьютерной программы

Задачи экспертизы компьютерной программы определяются её предметом и конкретными вопросами, поставленными перед экспертом. Можно выделить следующие группы задач:

Идентификационные задачи:

• установление тождества программного продукта, представленного на экспертизу, и продукта, созданного по контракту;

• установление автора (авторов) программного кода;

• установление источника происхождения программного кода;

• установление факта использования сторонних компонентов.

Диагностические задачи:

• установление технического состояния программного продукта;

• выявление дефектов и их классификация;

• определение причин возникновения дефектов;

• установление факта работоспособности или неработоспособности;

• определение соответствия требованиям технического задания.

Ситуационные задачи:

• реконструкция процесса разработки;

• установление последовательности действий разработчика;

• определение момента возникновения дефекта;

• установление причинно-следственных связей между действиями и последствиями.

Классификационные задачи:

• отнесение программного продукта к определённому классу;

• определение типа архитектуры;

• определение используемых технологий;

• определение соответствия стандартам.

Оценочные задачи:

• оценка качества программного продукта;

• оценка полноты документации;

• оценка производительности;

• оценка безопасности;

• оценка объёма и стоимости работ.

Нормативные задачи:

• установление соответствия программного продукта обязательным требованиям;

• установление соответствия стандартам разработки;

• установление соответствия требованиям информационной безопасности;

• установление соответствия условиям контракта.

Каждая из этих задач требует применения определённых методов и инструментов. Например, для идентификационных задач используется анализ кода, сравнение хеш-сумм, анализ метаданных. Для диагностических задач — тестирование, анализ журналов, статический анализ. Для ситуационных задач — анализ репозиториев, восстановление хронологии, анализ переписки.

Задачи экспертизы компьютерной программы должны быть чётко сформулированы и понятны эксперту. Некорректно поставленные задачи могут привести к ошибочным выводам или к отказу эксперта от дачи заключения.

2.4. Вопросы, разрешаемые экспертизой компьютерной программы

Вопросы, разрешаемые экспертизой компьютерной программы, можно условно разделить на несколько категорий:

Вопросы о создании программного продукта:

1. Создан ли программный продукт, предусмотренный контрактом?

2. Соответствует ли программный продукт техническому заданию?

3. Является ли программный продукт оригинальным?

4. Использованы ли в программном продукте сторонние компоненты, и если да, то какие?

5. Завершена ли разработка программного продукта?

Вопросы о работоспособности:

6. Работоспособен ли программный продукт в предусмотренной среде?

7. Выполняет ли программный продукт заявленные функции?

8. Соответствует ли производительность программного продукта заявленным характеристикам?

9. Имеются ли в программном продукте критические дефекты?

Вопросы о причинах неисправностей:

10. Какова причина неисправности программного продукта?

11. Является ли неисправность следствием ошибок разработчика?

12. Является ли неисправность следствием некорректной эксплуатации?

13. Является ли неисправность следствием внешнего воздействия?

14. Могла ли неисправность возникнуть при соблюдении всех требований?

Вопросы о документации:

15. Соответствует ли документация фактическому состоянию программного продукта?

16. Достаточна ли документация для эксплуатации программного продукта?

17. Содержит ли документация необходимые сведения?

Вопросы об объёме и стоимости работ:

18. Какие работы фактически выполнены?

19. Какова рыночная стоимость выполненных работ?

20. Соответствует ли стоимость выполненных работ уплаченной сумме?

Вопросы о соблюдении технологий:

21. Соблюдались ли стандарты разработки?

22. Проводилось ли тестирование?

23. Велось ли версионное控制?

24. Соблюдались ли требования информационной безопасности?

Вопросы о пригодности к использованию:

25. Пригоден ли программный продукт для использования по назначению?

26. Возможно ли использование программного продукта без доработки?

27. Какие доработки необходимы для приведения программного продукта в соответствие с требованиями?

Перечень вопросов не является исчерпывающим; в каждом конкретном деле он определяется судом или стороной с учётом обстоятельств спора. Важно, чтобы вопросы были:

• в пределах специальных знаний эксперта;

• конкретными и однозначными;

• направленными на установление обстоятельств, имеющих значение для дела;

• не требующими правовой оценки.

2.5. Пределы компетенции эксперта при проведении экспертизы компьютерной программы

Компетенция эксперта при проведении экспертизы компьютерной программы ограничена его специальными знаниями. Эксперт не вправе:

• давать правовую оценку действиям сторон;

• устанавливать виновность или невиновность;

• определять юридические последствия;

• решать вопросы, относящиеся к исключительной компетенции суда.

Вместе с тем эксперт обладает широкими полномочиями в технической сфере. Он вправе:

• выбирать методы и инструменты исследования;

• запрашивать дополнительные материалы;

• знакомиться с материалами дела;

• заявлять ходатайства;

• отказаться от дачи заключения, если вопросы выходят за пределы его знаний;

• давать пояснения по своему заключению.

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

Важным является вопрос о соотношении технических и правовых аспектов в заключении эксперта. Эксперт не должен подменять суд и делать выводы о наличии или отсутствии состава правонарушения, о наличии или отсутствии задолженности, о законности действий сторон. Его задача — установить факты, которые суд впоследствии квалифицирует юридически.

Например, эксперт может установить, что «программный продукт не соответствует пункту 3.2 технического задания, а именно не обеспечивает выполнение функции X». Это технический факт. Суд на основе этого факта делает вывод о ненадлежащем исполнении обязательства. Эксперт не должен писать «разработчик не исполнил обязательство», поскольку это правовая квалификация.

Таким образом, пределы компетенции эксперта при проведении экспертизы компьютерной программы определяются границей между специальными техническими знаниями и правовой оценкой. Соблюдение этой границы — залог допустимости заключения эксперта в качестве доказательства.

---

ГЛАВА 3. МЕТОДОЛОГИЯ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНОЙ ПРОГРАММЫ

3.1. Общенаучные методы в экспертизе компьютерной программы

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

К общенаучным методам, применяемым в экспертизе компьютерной программы, относятся:

Диалектический метод — основа познания. Он требует рассматривать программный продукт в развитии, во взаимосвязи с другими объектами, с учётом противоречий. Диалектический подход позволяет избежать односторонности, увидеть проблему в целом.

Анализ и синтез. Анализ предполагает разложение программного продукта на составные части (модули, функции, классы, методы) и их изучение. Синтез — соединение полученных знаний в единую картину. В экспертизе компьютерной программы анализ и синтез применяются на всех этапах: от изучения кода до формулирования выводов.

Индукция и дедукция. Индукция — движение от частного к общему (от конкретных фактов к обобщениям). Дедукция — движение от общего к частному (от общих принципов к конкретным выводам). Эксперт использует оба метода: индукцию — при сборе и обобщении фактов, дедукцию — при применении общих закономерностей к конкретному случаю.

Абстрагирование и конкретизация. Абстрагирование позволяет выделить существенные свойства программного продукта, отвлекаясь от несущественных. Конкретизация — наполнение абстрактных понятий конкретным содержанием. Эти методы помогают эксперту выделить главное в сложной системе.

Моделирование. Создание модели программного продукта или процесса его разработки позволяет имитировать различные сценарии, проверять гипотезы, прогнозировать поведение системы. Моделирование особенно полезно, когда невозможно непосредственно исследовать объект (например, из-за его изменчивости или сложности).

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

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

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

Измерение. Количественная оценка характеристик программного продукта (производительность, время отклика, потребление ресурсов) требует применения методов измерения. Измерения должны быть точными, воспроизводимыми и документированными.

Формализация. Представление знаний о программном продукте в формализованном виде (схемы, таблицы, диаграммы) облегчает их анализ и восприятие. Формализация позволяет перейти от качественных описаний к количественным.

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

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

3.2. Специальные методы экспертизы компьютерной программы

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

Статический анализ кода. Предполагает изучение исходного кода без его выполнения. Цели: выявление синтаксических ошибок, нарушений стандартов, потенциальных уязвимостей, «мёртвого» кода, избыточности. Инструменты: линтеры, статические анализаторы, инструменты проверки стиля.

Динамический анализ. Предполагает выполнение кода с целью изучения его поведения. Цели: выявление ошибок времени выполнения, утечек памяти, проблем производительности. Инструменты: отладчики, профилировщики, системы трассировки.

Тестирование. Целенаправленная проверка программного продукта на соответствие требованиям. Виды тестирования:

• функциональное (проверка функций);

• интеграционное (проверка взаимодействия модулей);

• системное (проверка системы в целом);

• нагрузочное (проверка производительности);

• стресс-тестирование (проверка устойчивости);

• регрессионное (проверка после изменений);

• приёмочное (проверка соответствия критериям приёмки).

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

Анализ метрик. Измерение количественных характеристик кода: количество строк, цикломатическая сложность, связанность, сцепление, дублирование. Метрики позволяют оценить качество кода, его поддерживаемость, сложность.

Анализ зависимостей. Изучение связей между модулями, библиотеками, компонентами. Позволяет выявить критические зависимости, конфликты версий, уязвимости.

Анализ журналов. Изучение логов работы системы. Позволяет восстановить хронологию событий, выявить ошибки, определить причины сбоев.

Анализ репозиториев. Изучение истории изменений в системах контроля версий. Позволяет установить, когда и какие изменения вносились, кем, с какой целью.

Сравнительный анализ. Сравнение программного продукта с эталоном, аналогом, требованиями. Позволяет выявить различия, несоответствия, заимствования.

Экспертная оценка. Привлечение экспертов для оценки качества, удобства, безопасности программного продукта. Применяется, когда количественные методы недостаточны.

Формальные методы. Использование математических моделей для доказательства свойств программного продукта. Применяются для критически важных систем.

Аудит информационной безопасности. Проверка программного продукта на соответствие требованиям безопасности, выявление уязвимостей, оценка рисков.

Юзабилити-тестирование. Оценка удобства использования программного продукта. Применяется, когда качество определяется не только функциональностью, но и удобством.

Анализ документации. Проверка полноты, корректности, актуальности документации. Сопоставление документации с фактическим состоянием продукта.

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

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

3.3. Инструментальные средства экспертизы компьютерной программы

Инструментальные средства экспертизы компьютерной программы — это программные и аппаратные средства, используемые экспертом для исследования объектов. К ним относятся:

Средства анализа кода:

• статические анализаторы (SonarQube, Checkmarx, Coverity);

• линтеры (ESLint, Pylint, JSHint);

• инструменты проверки стиля (Checkstyle, StyleCop);

• инструменты поиска дублирования (Simian, PMD).

Средства тестирования:

• фреймворки модульного тестирования (JUnit, NUnit, pytest);

• инструменты функционального тестирования (Selenium, Cypress);

• инструменты нагрузочного тестирования (JMeter, LoadRunner);

• инструменты тестирования API (Postman, SoapUI).

Средства отладки и профилирования:

• отладчики (GDB, WinDbg, Visual Studio Debugger);

• профилировщики (JProfiler, dotTrace, Valgrind);

• инструменты трассировки (strace, ltrace).

Средства реверс-инжиниринга:

• дизассемблеры (IDA Pro, Ghidra);

• декомпиляторы (JD-GUI, dotPeek);

• инструменты анализа бинарного кода.

Средства анализа журналов:

• системы сбора и анализа логов (ELK Stack, Splunk);

• инструменты визуализации логов;

• инструменты поиска аномалий.

Средства работы с репозиториями:

• системы контроля версий (Git, SVN, Mercurial);

• инструменты анализа истории (GitLog, GitStats);

• инструменты визуализации ветвления.

Средства анализа зависимостей:

• менеджеры зависимостей (Maven, Gradle, npm);

• инструменты анализа уязвимостей (OWASP Dependency-Check);

• инструменты построения графов зависимостей.

Средства моделирования:

• инструменты построения диаграмм (PlantUML, Draw.io);

• инструменты имитационного моделирования;

• инструменты анализа архитектуры.

Средства документирования:

• инструменты создания отчётов;

• инструменты фиксации доказательств (хеширование, цифровая подпись);

• инструменты создания резервных копий.

Аппаратные средства:

• компьютеры и серверы;

• средства хранения данных;

• сетевое оборудование;

• средства защиты информации.

Инструментальные средства должны быть:

• легальными (лицензионными или свободными);

• проверенными (сертифицированными, если требуется);

• документированными (с фиксацией версий и настроек);

• воспроизводимыми (результаты должны быть воспроизводимы).

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

3.4. Этапы проведения экспертизы компьютерной программы

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

Этап 1. Подготовительный.

• изучение постановления о назначении экспертизы (или договора на проведение экспертизы);

• уяснение вопросов, поставленных перед экспертом;

• определение объектов исследования;

• проверка достаточности материалов;

• заявление ходатайств о предоставлении дополнительных материалов;

• планирование исследования;

• подбор методов и инструментов.

Этап 2. Фиксация объектов.

• обеспечение сохранности объектов;

• создание резервных копий;

• вычисление хеш-сумм;

• фотографирование, составление описаний;

• документирование состояния объектов.

Этап 3. Анализ документации.

• изучение технического задания;

• изучение проектной документации;

• изучение договора (контракта);

• изучение актов приёмки;

• изучение переписки сторон;

• сопоставление документации с фактическим состоянием.

Этап 4. Анализ программного кода.

• статический анализ;

• динамический анализ;

• анализ структуры;

• анализ метрик;

• анализ зависимостей;

• выявление дефектов.

Этап 5. Тестирование.

• разработка тест-кейсов;

• проведение функционального тестирования;

• проведение нагрузочного тестирования;

• проведение регрессионного тестирования;

• фиксация результатов.

Этап 6. Анализ причин неисправностей.

• изучение журналов;

• анализ сбоев;

• моделирование ситуаций;

• установление причинно-следственных связей.

Этап 7. Оценка объёма и стоимости работ.

• определение фактически выполненных работ;

• оценка трудозатрат;

• оценка рыночной стоимости;

• сопоставление с уплаченной суммой.

Этап 8. Синтез результатов.

• обобщение полученных данных;

• формулирование промежуточных выводов;

• проверка гипотез;

• оценка достоверности.

Этап 9. Составление заключения.

• оформление вводной части;

• оформление исследовательской части;

• формулирование выводов;

• оформление приложений.

Этап 10. Допрос эксперта (при необходимости).

• дача пояснений в суде;

• ответы на вопросы сторон;

• обоснование выводов.

Каждый этап должен быть документирован. Это обеспечивает прозрачность экспертизы компьютерной программы и возможность её проверки.

3.5. Оценка достоверности результатов экспертизы компьютерной программы

Достоверность результатов экспертизы компьютерной программы — ключевое требование, предъявляемое к заключению эксперта. Оценка достоверности осуществляется по нескольким критериям:

Научная обоснованность.

• применялись ли научно обоснованные методы;

• соответствуют ли методы современному уровню науки и техники;

• корректно ли методы применены.

Полнота исследования.

• все ли объекты исследованы;

• все ли вопросы рассмотрены;

• достаточно ли материалов для выводов.

Объективность.

• беспристрастен ли эксперт;

• нет ли заинтересованности;

• не допущено ли односторонности.

Проверяемость.

• можно ли воспроизвести исследование;

• описаны ли методы и инструменты;

• зафиксированы ли результаты.

Логическая непротиворечивость.

• согласуются ли выводы с исследовательской частью;

• нет ли внутренних противоречий;

• соблюдена ли логика изложения.

Компетентность эксперта.

• обладает ли эксперт необходимыми знаниями;

• имеет ли опыт в данной области;

• соответствует ли квалификация сложности задач.

Соблюдение процессуальных требований.

• соблюдены ли права сторон;

• предупреждён ли эксперт об ответственности;

• соблюдены ли сроки.

Оценка достоверности может проводиться:

• судом;

• сторонами;

• другими экспертами (рецензирование);

• вышестоящей инстанцией.

При оценке достоверности учитываются:

• наличие сертификатов, лицензий;

• репутация эксперта и экспертного учреждения;

• сложность и новизна задач;

• возможность проверки выводов.

В случае сомнений в достоверности может быть назначена:

• дополнительная экспертиза (для разъяснения или дополнения);

• повторная экспертиза (для проверки выводов);

• комиссионная экспертиза (несколькими экспертами);

• комплексная экспертиза (с участием специалистов разных областей).

Достоверность экспертизы компьютерной программы — необходимое условие её доказательственной силы. Только достоверное заключение может быть положено в основу судебного решения.

---

ГЛАВА 4. ПРАВОВОЕ РЕГУЛИРОВАНИЕ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНОЙ ПРОГРАММЫ

4.1. Нормативная база судебной экспертизы компьютерной программы

Правовое регулирование судебной экспертизы компьютерной программы осуществляется на нескольких уровнях:

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

Федеральный закон «О государственной судебно-экспертной деятельности в Российской Федерации» — устанавливает общие принципы организации и производства судебной экспертизы, права и обязанности эксперта, требования к заключению, порядок назначения.

Арбитражный процессуальный кодекс Российской Федерации — регулирует назначение и проведение экспертизы в арбитражном процессе (статьи 55, 82, 83, 86, 87, 88, 89, 107, 109, 110).

Гражданский процессуальный кодекс Российской Федерации — регулирует назначение и проведение экспертизы в гражданском процессе (статьи 79, 80, 81, 82, 83, 84, 85, 86, 87, 168, 187).

Кодекс административного судопроизводства Российской Федерации — регулирует назначение и проведение экспертизы по административным делам (статьи 76, 77, 78, 79, 80).

Уголовно-процессуальный кодекс Российской Федерации — регулирует назначение и проведение экспертизы по уголовным делам (статьи 57, 58, 70, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207).

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

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

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

Важнейшие принципы судебной экспертизы:

• законность;

• соблюдение прав и свобод человека и гражданина;

• независимость эксперта;

• объективность, всесторонность и полнота исследования;

• научная обоснованность.

Эти принципы в полной мере применимы к экспертизе компьютерной программы.

4.2. Особенности назначения экспертизы компьютерной программы в арбитражном процессе

Арбитражный процесс — основная площадка для разрешения споров между разработчиком и заказчиком программного обеспечения. Назначение экспертизы компьютерной программы в арбитражном процессе имеет ряд особенностей.

Основания назначения. Согласно статье 82 Арбитражного процессуального кодекса Российской Федерации, экспертиза назначается, если для разрешения возникающих вопросов требуются специальные знания. Суд назначает экспертизу по ходатайству лица, участвующего в деле, или с согласия лиц, участвующих в деле. Если сторона уклоняется от участия в экспертизе, суд вправе признать факт, для выяснения которого экспертиза была назначена, установленным или опровергнутым.

Порядок назначения.

1. Сторона заявляет ходатайство о назначении экспертизы.

2. Суд рассматривает ходатайство, заслушивает мнения сторон.

3. Суд формулирует вопросы, подлежащие разрешению экспертом.

4. Суд выбирает экспертное учреждение или эксперта.

5. Суд выносит определение о назначении экспертизы.

6. Определение направляется в экспертное учреждение.

7. Эксперт проводит исследование.

8. Заключение направляется в суд.

Права сторон.

• заявлять отвод эксперту;

• предлагать вопросы для эксперта;

• знакомиться с определением о назначении экспертизы;

• знакомиться с заключением эксперта;

• ходатайствовать о назначении дополнительной или повторной экспертизы;

• задавать вопросы эксперту в судебном заседании.

Обязанности эксперта.

• провести исследование объективно, полно, всесторонне;

• дать обоснованное заключение;

• не разглашать сведения, ставшие известными в связи с экспертизой;

• явиться по вызову суда для дачи пояснений.

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

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

Особенности экспертизы компьютерной программы.

• необходимость предоставления эксперту доступа к программному коду, документации, среде функционирования;

• необходимость обеспечения сохранности объектов;

• сложность формулирования вопросов;

• длительность исследования;

• высокая стоимость.

4.3. Государственные и муниципальные контракты как основание для экспертизы компьютерной программы

Значительная часть споров, требующих экспертизы компьютерной программы, связана с исполнением государственных и муниципальных контрактов на создание программного обеспечения. Правовой основой таких контрактов является Федеральный закон «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (44-ФЗ).

Особенности государственных и муниципальных контрактов на создание программного обеспечения:

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

• формализованность. Контракт содержит чёткие требования к результату, срокам, порядку приёмки, ответственности;

• обязательность технического задания. Техническое задание является неотъемлемой частью контракта и определяет требования к программному продукту;

• регламентированная приёмка. Приёмка осуществляется в порядке, установленном контрактом и законом. Может создаваться приёмочная комиссия;

• ответственность за неисполнение. За неисполнение или ненадлежащее исполнение контракта предусмотрены штрафы, пени, включение в реестр недобросовестных поставщиков;

• контроль со стороны государственных органов. Финансовый контроль, контроль в сфере закупок, прокурорский надзор.

Типичные споры:

• разработчик не передал программный продукт;

• программный продукт не соответствует техническому заданию;

• программный продукт неработоспособен;

• документация неполна или не соответствует продукту;

• работы выполнены не в полном объёме;

• стоимость работ завышена;

• нарушены сроки выполнения работ.

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

Особенности экспертизы компьютерной программы по контрактам:

• необходимость анализа технического задания на предмет его полноты и однозначности;

• необходимость сопоставления фактического состояния продукта с требованиями;

• необходимость оценки объёма и стоимости фактически выполненных работ;

• необходимость учёта особенностей бюджетного финансирования;

• необходимость оценки соблюдения требований информационной безопасности.

Значение экспертизы компьютерной программы для государственных и муниципальных заказчиков:

• подтверждение факта неисполнения или ненадлежащего исполнения контракта;

• обоснование требований о взыскании штрафов, пеней, убытков;

• обоснование отказа от исполнения контракта;

• обоснование включения разработчика в реестр недобросовестных поставщиков;

• защита бюджетных средств от неэффективного расходования.

4.4. Процессуальные права и обязанности участников экспертизы компьютерных программ

Участники экспертизы компьютерной программы обладают определёнными процессуальными правами и обязанностями.

Эксперт:

• права: знакомиться с материалами дела; заявлять ходатайства; участвовать в судебных заседаниях; задавать вопросы; отказаться от дачи заключения, если вопросы выходят за пределы его знаний; обжаловать действия суда, ущемляющие его права;

• обязанности: провести исследование; дать обоснованное заключение; явиться по вызову; не разглашать сведения; соблюдать сроки; обеспечить сохранность объектов.

Суд:

• права: назначать экспертизу; выбирать эксперта; формулировать вопросы; отводить эксперта; оценивать заключение; назначать дополнительную или повторную экспертизу;

• обязанности: обеспечить соблюдение прав участников; создать условия для проведения экспертизы; оценить заключение по правилам статьи 71 Арбитражного процессуального кодекса Российской Федерации.

Стороны:

• права: заявлять ходатайство о назначении экспертизы; предлагать вопросы; отводить эксперта; знакомиться с заключением; ходатайствовать о дополнительной или повторной экспертизе; задавать вопросы эксперту;

• обязанности: предоставлять материалы; не препятствовать экспертизе; нести расходы.

Иные участники:

• специалисты;

• переводчики;

• свидетели.

Соблюдение прав и обязанностей участников — условие законности и обоснованности экспертизы компьютерной программы.

4.5. Ответственность эксперта при проведении экспертизы компьютерных программ

Ответственность эксперта при проведении экспертизы компьютерной программы может быть:

• уголовной;

• административной;

• дисциплинарной;

• гражданско-правовой.

Уголовная ответственность наступает за дачу заведомо ложного заключения (статья 307 Уголовного кодекса Российской Федерации). Наказание: штраф, обязательные работы, исправительные работы, арест. Эксперт предупреждается об уголовной ответственности перед началом экспертизы.

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

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

Гражданско-правовая ответственность наступает за причинение ущерба вследствие некачественной экспертизы. Эксперт или экспертное учреждение может быть обязано возместить убытки.

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

---

ГЛАВА 5. ЭКСПЕРТИЗА КОМПЬЮТЕРНЫХ ПРОГРАММ В ДОСУДЕБНОМ ПОРЯДКЕ

5.1. Понятие и значение досудебной экспертизы компьютерной программы

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

Значение досудебной экспертизы компьютерной программы:

• позволяет стороне оценить перспективы спора;

• формирует доказательственную базу;

• обосновывает претензию;

• побуждает контрагента к урегулированию;

• помогает сформулировать вопросы для судебной экспертизы;

• сокращает сроки и стоимость судебного разбирательства.

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

5.2. Порядок проведения досудебной экспертизы компьютерной программы

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

1. Заключение договора. Определяются объект, предмет, задачи, сроки, стоимость, ответственность.

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

3. Фиксация объектов. Эксперт фиксирует состояние объектов, создаёт резервные копии, вычисляет хеш-суммы.

4. Проведение исследования. Эксперт применяет методы и инструменты, собирает данные.

5. Составление заключения. Эксперт оформляет результаты в виде заключения.

6. Передача заключения заказчику. Заказчик использует заключение по своему усмотрению.

Досудебная экспертиза компьютерной программы может проводиться в форме:

• аудита — комплексной проверки программного продукта;

• ревизии — проверки соответствия требованиям;

• рецензии — оценки ранее проведённой экспертизы;

• консультации — разъяснения отдельных вопросов.

5.3. Заключение специалиста как результат досудебной экспертизы компьютерной программы

Заключение специалиста — документ, в котором отражаются результаты досудебной экспертизы компьютерной программы. Оно должно содержать:

Вводную часть:

• сведения о заказчике;

• сведения об эксперте (организации);

• основания проведения экспертизы;

• объект исследования;

• вопросы, поставленные перед экспертом.

Исследовательскую часть:

• описание объектов;

• описание методов и инструментов;

• описание хода исследования;

• полученные данные;

• анализ данных;

• выявленные факты.

Выводы:

• ответы на поставленные вопросы;

• обоснование выводов;

• ограничения исследования.

Приложения:

• таблицы;

• схемы;

• распечатки;

• акты фиксации.

Заключение специалиста должно быть:

• научно обоснованным;

• полным;

• объективным;

• проверяемым;

• логически непротиворечивым.

5.4. Использование результатов досудебной экспертизы компьютерной программы в суде

Результаты досудебной экспертизы компьютерной программы могут быть использованы в суде следующими способами:

Как письменное доказательство. Суд оценивает заключение специалиста наряду с другими доказательствами.

Как основание для назначения судебной экспертизы. Суд может учесть выводы досудебной экспертизы при формулировании вопросов.

Как основание для ходатайства о вызове специалиста. Специалист может быть вызван в суд для дачи пояснений.

Как основание для оспаривания выводов судебной экспертизы. Если судебная экспертиза противоречит досудебной, сторона может ходатайствовать о повторной экспертизе.

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

5.5. Преимущества и недостатки досудебной экспертизы компьютерной программы

Преимущества:

• оперативность;

• меньшая стоимость;

• свобода в выборе эксперта;

• возможность повлиять на формулирование вопросов;

• возможность использовать результаты для претензионной работы.

Недостатки:

• отсутствие процессуального статуса;

• критическое отношение суда;

• риск ангажированности эксперта;

• ограниченность материалов;

• невозможность обязать другую сторону предоставить материалы.

---

ГЛАВА 6. ЦЕНЫ И СРОКИ ПРОВЕДЕНИЯ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНОЙ ПРОГРАММЫ

6.1. Факторы, определяющие стоимость экспертизы компьютерной программы

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

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

Объём исходного кода и документации. Прямая зависимость стоимости от объёма исследуемого материала очевидна: чем больше кода, тем больше времени требуется на его анализ. Аналогично обстоит дело с документацией — техническое задание, проектная документация, руководства пользователя и администратора, описания API могут исчисляться сотнями и тысячами страниц. Их изучение, сопоставление и анализ формируют существенную часть трудозатрат.

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

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

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

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

Срочность проведения. Если экспертиза компьютерной программы требуется в сжатые сроки, эксперт вынужден отвлекать дополнительные ресурсы, работать в ускоренном режиме, что отражается на стоимости. Срочность может увеличить цену на двадцать-пятьдесят процентов и более.

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

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

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

6.2. Диапазоны стоимости экспертизы компьютерной программы

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

Простые экспертизы. Исследование небольшого программного продукта, состоящего из нескольких тысяч строк кода, с ограниченным числом вопросов (два-три), при наличии полного доступа к материалам. Стоимость таких экспертиз может составлять от нескольких десятков тысяч до ста-ста пятидесяти тысяч рублей. Сроки проведения — от одной до двух недель.

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

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

Комплексные экспертизы. Исследование, требующее привлечения экспертов разных специальностей (программистов, экономистов, специалистов по безопасности), проведения сложных экспериментов, анализа больших объёмов данных. Стоимость может достигать десятков миллионов рублей. Сроки — от трёх месяцев до года.

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

6.3. Структура стоимости экспертизы компьютерной программы

Стоимость экспертизы компьютерной программы складывается из нескольких составляющих.

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

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

Стоимость расходных материалов. Носители информации, расходные материалы для печати, канцелярские товары.

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

Стоимость оборудования. Если требуется приобретение или аренда специального оборудования, эти затраты включаются в стоимость.

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

Транспортные расходы. Доставка объектов, выезды на место.

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

6.4. Факторы, определяющие сроки проведения экспертизы компьютерной программы

Сроки проведения экспертизы компьютерной программы, как и стоимость, зависят от множества факторов.

Сложность объекта. Чем сложнее программный продукт, тем больше времени требуется на его изучение. Крупные системы с множеством компонентов требуют месяцы работы.

Объём материалов. Большой объём кода и документации увеличивает сроки.

Количество вопросов. Каждый вопрос требует времени на исследование и формулирование вывода.

Необходимость проведения испытаний. Развёртывание, настройка, тестирование, моделирование — всё это требует времени.

Доступность материалов. Если материалы предоставлены полно и своевременно, сроки сокращаются. Если приходится запрашивать дополнительные материалы, сроки увеличиваются.

Загруженность эксперта. Если эксперт занят другими делами, сроки могут увеличиваться.

Срочность. При необходимости сроки могут быть сокращены за счёт привлечения дополнительных ресурсов, но это увеличивает стоимость.

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

Сезонность. В периоды отпусков сроки могут увеличиваться.

6.5. Ориентировочные сроки проведения экспертизы компьютерной программы

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

Экспертизы средней сложности. От двух недель до одного месяца. Включают анализ кода, тестирование, анализ документации, ответы на пять-десять вопросов.

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

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

Следует учитывать, что сроки, установленные судом, могут быть продлены при наличии уважительных причин. Эксперт вправе заявить ходатайство о продлении срока, если объём работы превышает первоначальные оценки.

6.6. Порядок оплаты экспертизы компьютерной программы

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

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

Формы оплаты. Безналичный расчёт, наличный расчёт (в установленных пределах), оплата по аккредитиву, иные формы, не противоречащие законодательству.

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

6.7. Возмещение расходов на экспертизу компьютерной программы

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

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

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

Разумность расходов. Суд вправе снизить размер возмещаемых расходов, если признает их чрезмерными. Критерии разумности: сложность дела, объём исследования, рыночные цены на аналогичные услуги.

6.8. Особенности ценообразования при экспертизе компьютерной программы по государственным и муниципальным контрактам

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

Государственные расценки. Если экспертиза компьютерной программы проводится государственным экспертным учреждением, стоимость может определяться утверждёнными расценками.

Конкурентные процедуры. При выборе эксперта для государственного заказчика могут проводиться конкурентные процедуры (аукцион, конкурс, запрос котировок), что влияет на стоимость.

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

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

6.9. Способы оптимизации стоимости и сроков экспертизы компьютерной программы

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

Полнота предоставляемых материалов. Предоставление эксперту полного доступа к коду, документации, среде функционирования сокращает сроки и стоимость.

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

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

Выбор квалифицированного эксперта. Опытный эксперт работает быстрее и качественнее, что в конечном итоге снижает общие затраты.

Сотрудничество сторон. Если стороны сотрудничают с экспертом, предоставляют материалы, отвечают на вопросы, сроки сокращаются.

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

6.10. Риски, связанные с ценой и сроками экспертизы компьютерной программы

Риск недооценки сложности. Если эксперт недооценил сложность объекта, сроки и стоимость могут быть превышены.

Риск неполноты материалов. Если материалы предоставлены не в полном объёме, экспертиза компьютерной программы может затянуться.

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

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

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

Риск неоплаты. При досудебной экспертизе существует риск неоплаты услуг заказчиком.

6.11. Договор на проведение экспертизы компьютерной программы: существенные условия о цене и сроках

Предмет договора. Описание объектов исследования, вопросов, задач.

Стоимость услуг. Общая стоимость, порядок расчёта, валюта, налоги.

Порядок оплаты. Аванс, этапы, окончательный расчёт, формы оплаты.

Сроки. Начало, окончание, промежуточные сроки, порядок продления.

Ответственность за нарушение сроков. Штрафы, пени, иные меры.

Порядок изменения стоимости. Условия пересмотра цены.

Порядок разрешения споров. Претензионный порядок, подсудность.

Конфиденциальность. Обязательства по сохранению тайны.

Права на результаты. Кому принадлежат результаты экспертизы компьютерной программы.

6.12. Практические рекомендации по формированию бюджета и планированию сроков

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

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

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

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

---

ГЛАВА 7. ТРЕБОВАНИЯ, КОТОРЫЕ СУДЫ ПРЕДЪЯВЛЯЮТ К ЭКСПЕРТАМ, ВЫПОЛНЯЮЩИМ ЭКСПЕРТИЗУ КОМПЬЮТЕРНЫХ ПРОГРАММ

7.1. Общие требования к эксперту

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

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

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

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

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

7.2. Квалификационные требования, предъявляемые судами

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

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

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

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

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

Владение методами и инструментами. Эксперт должен уметь применять статический и динамический анализ кода, тестирование, реверс-инжиниринг, анализ метрик, анализ зависимостей, анализ журналов, моделирование, аудит безопасности. Он должен владеть инструментальными средствами: статическими анализаторами, фреймворками тестирования, отладчиками, профилировщиками, дизассемблерами, декомпиляторами, системами сбора и анализа логов, системами контроля версий.

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

Постоянное повышение квалификации. Информационные технологии развиваются стремительно. Эксперт должен постоянно повышать квалификацию: изучать новые языки, технологии, инструменты, методы, стандарты. Участие в конференциях, семинарах, курсах, публикация научных работ, участие в профессиональных сообществах — формы поддержания и развития квалификации.

7.3. Специализация экспертов

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

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

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

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

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

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

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

Эксперты по экономике IT-проектов. Специализируются на оценке объёма, трудозатрат, стоимости выполненных работ, сопоставлении с рыночными ценами.

Эксперты по интеграциям. Специализируются на анализе взаимодействия программных продуктов, оценке корректности интеграций, выявлении проблем совместимости.

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

7.4. Требования к эксперту в судебном процессе

В судебном процессе к эксперту предъявляются дополнительные требования, обусловленные процессуальной формой.

Процессуальная правосубъектность. Эксперт должен быть способен нести процессуальные обязанности: явиться по вызову суда, дать обоснованное заключение, ответить на вопросы, не разглашать сведения.

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

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

Объективность. Эксперт обязан проводить исследование объективно, всесторонне, полно, не поддаваясь давлению, не допуская односторонности.

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

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

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

Ответы на вопросы. Эксперт должен уметь чётко, аргументированно отвечать на вопросы суда и сторон, разъяснять свои выводы, обосновывать применённые методы.

7.5. Требования к эксперту при досудебной экспертизе компьютерной программы

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

Договорная основа. Отношения между заказчиком и экспертом регулируются договором. Эксперт должен чётко понимать свои права и обязанности, объём работы, сроки, стоимость.

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

Полнота и объективность. Эксперт должен провести исследование полно, всесторонне, объективно, не допуская умолчания о фактах, противоречащих позиции заказчика.

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

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

7.6. Ответственность эксперта

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

Уголовная ответственность. За дачу заведомо ложного заключения эксперт несёт ответственность по статье 307 Уголовного кодекса Российской Федерации. Наказание: штраф, обязательные работы, исправительные работы, арест. Эксперт предупреждается об ответственности перед началом экспертизы.

Административная ответственность. За невыполнение требований суда, нарушение порядка проведения экспертизы, неповиновение законному распоряжению суда могут применяться меры административной ответственности.

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

Гражданско-правовая ответственность. Эксперт или экспертная организация может быть обязана возместить убытки, причинённые некачественной экспертизой. Основания: неисполнение или ненадлежащее исполнение договора, причинение вреда.

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

7.7. Сертификация и аккредитация экспертов

Сертификация и аккредитация — формальные механизмы подтверждения квалификации эксперта.

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

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

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

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

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

7.8. Формирование комиссии экспертов

Для проведения сложной комплексной экспертизы компьютерной программы может формироваться комиссия экспертов.

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

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

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

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

Порядок работы. Комиссия работает по плану, утверждённому руководителем. Проводятся рабочие встречи, обсуждаются промежуточные результаты, разрешаются спорные вопросы.

Оформление заключения. Заключение комиссии подписывается всеми экспертами. Эксперт, не согласный с выводами, вправе представить особое мнение.

Преимущества комиссии. Полнота исследования, разносторонность анализа, взаимная проверка, повышение достоверности.

Недостатки комиссии. Увеличение сроков, стоимости, сложность координации, риск разногласий.

7.9. Критерии выбора эксперта заказчиком

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

Квалификация. Образование, опыт, знания, навыки, сертификаты, публикации, репутация.

Специализация. Соответствие специализации эксперта характеру задач.

Опыт экспертной деятельности. Участие в судебных и досудебных экспертизах, знание процессуальных требований.

Независимость. Отсутствие заинтересованности, связей со сторонами, конфликта интересов.

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

Сроки. Способность провести экспертизу компьютерной программы в требуемые сроки.

Стоимость. Соответствие стоимости рыночным ценам, обоснованность расценок.

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

Готовность к судебному оспариванию. Способность защитить свои выводы в суде.

Доступность. Возможность оперативной связи, готовность к консультациям.

7.10. Критерии выбора эксперта судом

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

Компетентность. Наличие специальных знаний, необходимых для разрешения вопросов.

Независимость. Отсутствие заинтересованности, связей со сторонами.

Беспристрастность. Способность дать объективное заключение.

Опыт. Наличие опыта проведения аналогичных экспертиз.

Репутация. Положительная репутация в профессиональном сообществе.

Сроки. Способность провести экспертизу в сроки, установленные судом.

Стоимость. Разумность стоимости экспертизы.

Загруженность. Наличие ресурсов для проведения экспертизы.

Согласие сторон. Мнение сторон учитывается при выборе эксперта.

Процессуальные требования. Соответствие кандидатуры требованиям процессуального законодательства.

7.11. Повышение квалификации экспертов

Повышение квалификации — непрерывный процесс, обеспечивающий соответствие эксперта современному уровню знаний.

Формы повышения квалификации:

• обучение на курсах, семинарах, тренингах;

• участие в конференциях, форумах, симпозиумах;

• изучение научной литературы, публикаций, стандартов;

• участие в профессиональных сообществах;

• обмен опытом с коллегами;

• самообразование;

• участие в разработке методик;

• публикация научных работ;

• преподавание;

• стажировки.

Направления повышения квалификации:

• новые языки программирования;

• новые технологии разработки;

• новые инструменты анализа;

• новые методологии тестирования;

• новые стандарты;

• новые требования безопасности;

• изменения законодательства;

• процессуальные аспекты.

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

7.12. Типичные ошибки экспертов и способы их предотвращения

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

Ошибки в методах. Применение неподходящих методов, некорректное применение, недостаточная обоснованность. Предотвращение: тщательный выбор методов, проверка их применимости, документирование.

Ошибки в фиксации объектов. Неполная фиксация, отсутствие резервных копий, утрата объектов. Предотвращение: тщательная фиксация, создание копий, документирование.

Ошибки в оценке. Недооценка или переоценка сложности, неверная интерпретация данных. Предотвращение: коллегиальная проверка, консультации, повторный анализ.

Ошибки в оформлении. Несоответствие требованиям, неполнота, противоречия. Предотвращение: знание требований, проверка, редактирование.

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

Ошибки в сроках. Нарушение сроков, необоснованное продление. Предотвращение: реалистичное планирование, своевременное информирование, резерв времени.

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

---

ГЛАВА 8. ДЕСЯТЬ ПРАКТИЧЕСКИХ КЕЙСОВ ПО ПРОВЕДЕНИЮ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНЫХ ПРОГРАММ

Кейс 1. Государственный контракт на создание портала государственных услуг

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

Задачи экспертизы компьютерной программы. Установить, соответствует ли портал техническому заданию; имеются ли критические дефекты, препятствующие использованию; какова причина дефектов; какой объём работ фактически выполнен.

Методы. Анализ технического задания и проектной документации; статический анализ исходного кода; развёртывание портала в тестовой среде; функциональное тестирование; нагрузочное тестирование; анализ журналов; проверка интеграций.

Ход исследования. Эксперт изучил техническое задание, содержащее более двухсот функциональных требований. Сопоставление с фактическим состоянием портала показало, что реализовано около семидесяти процентов требований. Критические дефекты выявлены в модуле авторизации, в формах заявлений, в интеграции с ведомственными системами. Нагрузочное тестирование показало, что портал не выдерживает расчётной нагрузки: время отклика превышает допустимое в пять раз. Анализ кода выявил нарушения архитектуры, дублирование, отсутствие обработки ошибок.

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

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

Кейс 2. Муниципальный контракт на разработку мобильного приложения

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

Задачи экспертизы компьютерной программы. Установить, соответствует ли приложение техническому заданию; работоспособно ли оно; какова причина неисправностей; связаны ли они с действиями разработчика или заказчика.

Методы. Анализ технического задания; анализ исходного кода; тестирование на различных версиях операционной системы; анализ журналов; моделирование действий пользователя.

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

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

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

Кейс 3. Корпоративный контракт на внедрение ERP-системы

Фабула. Крупное предприятие заключило договор с системным интегратором на внедрение ERP-системы. Стоимость — двести пятьдесят миллионов рублей. Срок — восемнадцать месяцев. После внедрения система работала нестабильно: периодические сбои, потеря данных, медленная работа, ошибки в финансовой отчётности. Заказчик потребовал устранения дефектов, интегратор настаивал на том, что система работоспособна, а проблемы вызваны некачественными данными заказчика.

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

Методы. Анализ договора и технического задания; анализ архитектуры; анализ кода; анализ базы данных; нагрузочное тестирование; анализ журналов; проверка целостности данных; анализ миграций.

Ход исследования. Эксперт изучил архитектуру системы, выявил нарушения проектных решений: отсутствие кэширования, неоптимальные запросы к базе данных, отсутствие индексов, дублирование данных. Нагрузочное тестирование показало, что система не выдерживает расчётной нагрузки. Анализ журналов выявил регулярные ошибки, связанные с блокировками, таймаутами, переполнением памяти. Проверка целостности данных выявила расхождения, возникшие из-за ошибок в миграциях.

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

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

Кейс 4. Спор о заимствовании кода

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

Задачи экспертизы компьютерной программы. Установить, имеется ли заимствование кода; каков объём заимствования; является ли код оригинальным; нарушены ли права третьих лиц.

Методы. Сравнительный анализ кода; анализ метрик; анализ комментариев; анализ стиля; анализ истории репозитория; поиск в открытых источниках.

Ход исследования. Эксперт провёл сравнение переданного кода с кодом продукта третьего лица. Выявлены совпадения в структуре, названиях переменных, комментариях, последовательности операторов. Объём совпадений — около сорока процентов. Анализ стиля показал различие в оформлении, что свидетельствует о копировании с последующей адаптацией. Анализ истории репозитория выявил, что часть кода была добавлена единовременно, без промежуточных версий, что нетипично для оригинальной разработки.

Выводы. Имеется заимствование кода в объёме около сорока процентов. Код не является полностью оригинальным. Права третьих лиц нарушены.

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

Кейс 5. Спор о причинах неисправности программного обеспечения

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

Задачи экспертизы компьютерной программы. Установить причину неисправности; связана ли она с действиями разработчика или заказчика; могла ли она возникнуть при соблюдении всех требований.

Методы. Анализ кода; анализ журналов; анализ конфигурации; моделирование ситуации; тестирование.

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

Выводы. Причина неисправности — ошибка в коде разработчика. Неисправность могла возникнуть при соблюдении всех требований. Действия заказчика не являются причиной неисправности.

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

Кейс 6. Спор о соответствии программного продукта техническому заданию

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

Задачи экспертизы компьютерной программы. Установить, соответствует ли система техническому заданию; все ли требования реализованы; имеются ли отклонения.

Методы. Анализ технического задания; анализ кода; функциональное тестирование; сопоставление требований и реализации.

Ход исследования. Эксперт составил матрицу соответствия: каждое требование технического задания сопоставлено с фактической реализацией. Установлено, что из ста двадцати требований реализованы девяносто, частично реализованы пятнадцать, не реализованы пятнадцать. Часть реализованных требований выполнена с отклонениями. Критические требования, касающиеся безопасности и целостности данных, реализованы не в полном объёме.

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

Результат. Суд признал контракт неисполненным, взыскал аванс, штраф, расходы на экспертизу компьютерной программы.

Кейс 7. Спор о качестве документации

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

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

Методы. Анализ документации; сопоставление с продуктом; экспертная оценка.

Ход исследования. Эксперт изучил руководство пользователя, руководство администратора, описание API, инструкцию по развёртыванию. Сопоставление с фактическим состоянием продукта выявило расхождения: описанные функции отсутствуют, реальные функции не описаны, интерфейсы отличаются от описанных, настройки не соответствуют рекомендуемым. Руководство администратора не содержит сведений о резервном копировании, восстановлении, мониторинге. Описание API неполно.

Выводы. Документация не соответствует фактическому состоянию продукта. Она недостаточна для эксплуатации и сопровождения. Не содержит необходимых сведений.

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

Кейс 8. Спор об объёме и стоимости выполненных работ

Фабула. Заказчик расторг договор с разработчиком в одностороннем порядке, потребовал возврата аванса. Разработчик утверждал, что выполнил значительный объём работ, и потребовал оплаты. Стороны не могли договориться об объёме и стоимости фактически выполненных работ.

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

Методы. Анализ кода; оценка трудозатрат; сравнительный анализ; экономическая оценка.

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

Выводы. Фактически выполнено около пятидесяти процентов работ. Рыночная стоимость выполненных работ — около сорока пяти процентов от суммы договора. Уплаченный аванс превышает стоимость выполненных работ.

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

Кейс 9. Спор о соблюдении требований информационной безопасности

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

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

Методы. Аудит безопасности; сканирование уязвимостей; пентест; анализ кода; анализ конфигурации; анализ документации.

Ход исследования. Эксперт провёл сканирование уязвимостей, выявил критические уязвимости в веб-приложении: SQL-инъекции, межсайтовый скриптинг, небезопасная аутентификация, отсутствие шифрования чувствительных данных. Пентест подтвердил возможность несанкционированного доступа к персональным данным. Анализ конфигурации выявил использование устаревших версий библиотек с известными уязвимостями. Анализ кода выявил отсутствие валидации входных данных, хранение паролей в открытом виде.

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

Результат. Суд признал контракт неисполненным, взыскал аванс, штраф, расходы на экспертизу компьютерной программы.

Кейс 10. Спор о работоспособности программного обеспечения после обновления

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

Задачи экспертизы компьютерной программы. Установить причину неработоспособности; связано ли это с обновлением; могла ли проблема возникнуть при соблюдении всех требований.

Методы. Анализ журналов; анализ кода; анализ конфигурации; тестирование; моделирование.

Ход исследования. Эксперт изучил журналы, восстановил хронологию: неработоспособность возникла непосредственно после установки обновления. Анализ кода обновления выявил несовместимость с предыдущей версией: изменён формат данных, не предусмотрена миграция, изменены интерфейсы без обратной совместимости. Анализ конфигурации показал, что настройки заказчика соответствуют рекомендациям. Тестирование воспроизвело проблему.

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

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

---

ГЛАВА 9. СУДЕБНАЯ ИЛИ НЕЗАВИСИМАЯ ЭКСПЕРТИЗА КОМПЬЮТЕРНЫХ ПРОГРАММ – ВСЕ ЗА И ПРОТИВ, ВСЕ ПЛЮСЫ И МИНУСЫ

9.1. Постановка проблемы выбора

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

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

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

9.2. Судебная экспертиза компьютерной программы: преимущества

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

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

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

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

Возможность отвода. Стороны вправе заявить отвод эксперту, если имеются сомнения в его беспристрастности, компетентности или наличии конфликта интересов. Это дополнительная гарантия объективности.

Возможность постановки вопросов сторонами. Каждая сторона вправе предложить свои вопросы для эксперта. Суд учитывает эти предложения при формулировании окончательного перечня вопросов. Это позволяет охватить все аспекты спора.

Возможность вызова эксперта в суд. Эксперт может быть вызван в судебное заседание для дачи пояснений. Стороны вправе задавать ему вопросы, оспаривать его выводы, требовать обоснования. Это обеспечивает состязательность и проверяемость.

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

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

Обязательность исполнения. Заключение судебной экспертизы, вступившее в законную силу вместе с судебным актом, обязательно для сторон. Оно не может быть проигнорировано или оспорено во внесудебном порядке.

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

9.3. Судебная экспертиза компьютерной программы: недостатки

Длительность. Назначение судебной экспертизы требует времени: заявление ходатайства, рассмотрение его судом, выбор эксперта, вынесение определения, направление материалов, проведение исследования, возврат заключения. Весь этот процесс может занять месяцы. В сложных случаях сроки увеличиваются до года и более. Это затягивает разрешение спора.

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

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

Ограниченность вопросов. Эксперт отвечает только на вопросы, поставленные судом. Если сторона не предложила важный вопрос, а суд его не включил, эксперт его не рассмотрит. Это может привести к неполноте исследования.

Загруженность экспертов. Государственные экспертные учреждения нередко перегружены. Это приводит к задержкам, спешке, снижению качества. Эксперт может быть вынужден работать одновременно над несколькими делами, что отражается на глубине исследования.

Бюрократизм. Судебная экспертиза связана с бюрократическими процедурами: оформление определения, переписка, отчётность. Это увеличивает сроки и снижает гибкость.

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

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

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

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

9.4. Независимая экспертиза компьютерной программы: преимущества

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

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

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

Контроль со стороны заказчика. Сторона может контролировать ход экспертизы, требовать промежуточных результатов, обсуждать методы, вносить коррективы. Это повышает удовлетворённость результатом.

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

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

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

Возможность формирования доказательственной базы. Независимая экспертиза позволяет собрать доказательства, которые впоследствии могут быть представлены в суд. Она помогает определить предмет судебной экспертизы, сформулировать вопросы, подготовить материалы.

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

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

9.5. Независимая экспертиза компьютерной программы: недостатки

Отсутствие процессуального статуса. Заключение независимой экспертизы компьютерной программы не является судебным доказательством. Оно представляется как письменное доказательство или иной документ, который суд оценивает критически. Суд не обязан принимать его выводы.

Критическое отношение суда. Суды нередко относятся к независимым экспертизам с недоверием, особенно если они проведены по заказу заинтересованной стороны. Считается, что эксперт мог быть ангажирован, что выводы односторонни, что исследование недостаточно глубоко. Это снижает доказательственную силу.

Отсутствие уголовной ответственности. Независимый эксперт не предупреждается об уголовной ответственности за дачу заведомо ложного заключения. Это снижает гарантии достоверности. Хотя эксперт несёт гражданско-правовую ответственность по договору, это менее серьёзный стимул.

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

Ограниченность материалов. Независимый эксперт получает только те материалы, которые предоставит заказчик. Если заказчик не имеет доступа к части материалов или не считает нужным их предоставить, эксперт не может провести полное исследование. У него нет полномочий требовать материалы у другой стороны.

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

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

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

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

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

9.6. Сравнительная таблица преимуществ и недостатков

9.7. Факторы, влияющие на выбор формы экспертизы компьютерной программы

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

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

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

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

Финансовые возможности. Судебная экспертиза дороже, но расходы могут быть возмещены. Независимая экспертиза дешевле, но расходы несёт заказчик.

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

Стратегия стороны. Если сторона намерена урегулировать спор без суда, достаточно независимой экспертизы. Если сторона готовится к судебному разбирательству, необходима судебная экспертиза.

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

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

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

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

9.8. Комбинированная стратегия

Оптимальной стратегией нередко является комбинирование независимой и судебной экспертизы компьютерной программы.

Этап первый: независимая экспертиза. На досудебной стадии проводится независимая экспертиза. Она позволяет:

• оценить перспективы спора;

• выявить сильные и слабые стороны позиции;

• сформировать доказательственную базу;

• подготовить претензию;

• определить вопросы для судебной экспертизы;

• выбрать эксперта для судебной экспертизы;

• оценить стоимость и сроки.

Этап второй: претензионная работа. На основе результатов независимой экспертизы направляется претензия. Если контрагент готов урегулировать спор, дело завершается без суда.

Этап третий: судебная экспертиза. Если спор переходит в суд, назначается судебная экспертиза. Вопросы, сформулированные на основе независимой экспертизы, ставятся перед судебным экспертом. Результаты независимой экспертизы представляются в суд как доказательство.

Этап четвёртый: рецензирование. Если судебная экспертиза приходит к неблагоприятным выводам, проводится рецензирование. Рецензия выявляет ошибки, противоречия, необоснованные выводы. На её основе заявляется ходатайство о дополнительной или повторной экспертизе.

Этап пятый: дополнительные экспертизы. При необходимости назначаются дополнительные или повторные экспертизы. Комбинированная стратегия позволяет максимально использовать преимущества обеих форм и минимизировать недостатки.

9.9. Тактические соображения

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

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

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

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

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

9.10. Риски и способы их минимизации

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

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

Риск оспаривания судебной экспертизы. Минимизируется участием в формулировании вопросов, предоставлением полных материалов, контролем за ходом экспертизы, своевременным заявлением ходатайств.

Риск затягивания сроков. Минимизируется своевременным заявлением ходатайств, предоставлением материалов, взаимодействием с экспертом, контролем сроков.

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

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

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

---

ГЛАВА 10. ПРИМЕРЫ ВОПРОСОВ, КОТОРЫЕ АРБИТРАЖНЫЙ СУД ИЛИ ЗАКАЗЧИК ЭКСПЕРТИЗЫ МОЖЕТ ЗАДАВАТЬ ЭКСПЕРТАМ ПРИ НАЗНАЧЕНИИ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНЫХ ПРОГРАММ

10.1. Вопросы о факте создания программного продукта

1. Создан ли программный продукт, предусмотренный условиями договора (государственного или муниципального контракта)?

2. Имеется ли в наличии программный продукт как результат работ, переданный заказчику?

3. Возможно ли идентифицировать программный продукт, представленный на экспертизу, как результат, созданный именно по данному договору?

4. Является ли программный продукт завершённым или он находится в промежуточной стадии разработки?

5. Соответствует ли фактически созданный программный продукт составу работ, предусмотренному техническим заданием?

6. Имеются ли в программном продукте компоненты, не предусмотренные техническим заданием?

7. Возможно ли использование программного продукта по назначению без дополнительной доработки?

8. Является ли программный продукт оригинальной разработкой или он представляет собой компиляцию ранее существовавших решений?

9. Содержит ли программный продукт признаки незавершённости, свидетельствующие о том, что разработка не была доведена до конца?

10. Соответствует ли структура программного продукта проектной документации, представленной разработчиком?

10.2. Вопросы о соответствии программного продукта техническому заданию

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

12. Какие требования технического задания реализованы в программном продукте полностью?

13. Какие требования технического задания реализованы частично?

14. Какие требования технического задания не реализованы вовсе?

15. Соответствуют ли функциональные характеристики программного продукта требованиям технического задания?

16. Соответствуют ли технические характеристики программного продукта требованиям технического задания?

17. Соответствуют ли эксплуатационные характеристики программного продукта требованиям технического задания?

18. Имеются ли отклонения от требований технического задания, и если да, то в чём они выражаются?

19. Являются ли выявленные отклонения существенными или несущественными?

20. Возможно ли устранение выявленных отклонений без существенной переработки программного продукта?

21. Соответствует ли программный продукт требованиям, предъявляемым к аналогичным продуктам?

22. Соответствует ли программный продукт обязательным требованиям, установленным нормативными правовыми актами?

23. Соответствует ли программный продукт требованиям государственных или отраслевых стандартов?

24. Соответствует ли программный продукт требованиям информационной безопасности, предусмотренным техническим заданием?

25. Соответствует ли программный продукт требованиям по защите персональных данных, предусмотренным техническим заданием?

10.3. Вопросы о работоспособности программного продукта

26. Работоспособен ли программный продукт в предусмотренной договором среде функционирования?

27. Выполняет ли программный продукт все функции, заявленные в техническом задании?

28. Выполняет ли программный продукт функции, предусмотренные документацией?

29. Соответствует ли производительность программного продукта требованиям технического задания?

30. Соответствует ли время отклика программного продукта требованиям технического задания?

31. Выдерживает ли программный продукт расчётную нагрузку, предусмотренную техническим заданием?

32. Обеспечивает ли программный продукт сохранность и целостность обрабатываемых данных?

33. Обеспечивает ли программный продукт корректную работу с базами данных?

34. Обеспечивает ли программный продукт корректную работу с внешними системами и интеграциями?

35. Имеются ли в программном продукте функции, которые не работают или работают некорректно?

36. Имеются ли в программном продукте функции, которые работают нестабильно, с периодическими сбоями?

37. Возможно ли использование программного продукта в режиме, предусмотренном техническим заданием, без возникновения ошибок?

38. Возможно ли использование программного продукта несколькими пользователями одновременно без возникновения конфликтов?

39. Обеспечивает ли программный продукт корректную работу при различных конфигурациях среды функционирования?

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

10.4. Вопросы о дефектах программного продукта

41. Имеются ли в программном продукте дефекты?

42. Какие именно дефекты имеются в программном продукте?

43. Являются ли выявленные дефекты критическими, то есть препятствующими использованию программного продукта по назначению?

44. Являются ли выявленные дефекты существенными, то есть влияющими на функциональность, но не препятствующими использованию?

45. Являются ли выявленные дефекты несущественными, то есть не влияющими на функциональность?

46. Каково количество выявленных дефектов?

47. Какова степень критичности каждого выявленного дефекта?

48. Возможно ли использование программного продукта при наличии выявленных дефектов?

49. Возможно ли использование программного продукта при наличии выявленных дефектов без риска потери данных?

50. Возможно ли использование программного продукта при наличии выявленных дефектов без риска нарушения безопасности?

51. Возможно ли устранение выявленных дефектов силами разработчика?

52. Какова ориентировочная трудоёмкость устранения выявленных дефектов?

53. Какова ориентировочная стоимость устранения выявленных дефектов?

54. Какова ориентировочная длительность устранения выявленных дефектов?

55. Возможно ли устранение выявленных дефектов без нарушения целостности программного продукта?

10.5. Вопросы о причинах неисправностей программного продукта

56. Какова причина неисправности программного продукта?

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

58. Является ли неисправность следствием ошибок, допущенных заказчиком при эксплуатации программного продукта?

59. Является ли неисправность следствием некорректной настройки программного продукта?

60. Является ли неисправность следствием несовместимости программного продукта с другими программными средствами?

61. Является ли неисправность следствием несовместимости программного продукта с аппаратным обеспечением?

62. Является ли неисправность следствием внешнего воздействия, в том числе вредоносного?

63. Является ли неисправность следствием обстоятельств непреодолимой силы?

64. Могла ли неисправность возникнуть при соблюдении всех требований технического задания и рекомендаций разработчика?

65. Могла ли неисправность возникнуть при соблюдении всех правил эксплуатации, установленных разработчиком?

66. Имеется ли причинно-следственная связь между действиями разработчика и возникшей неисправностью?

67. Имеется ли причинно-следственная связь между действиями заказчика и возникшей неисправностью?

68. Имеется ли причинно-следственная связь между действиями третьих лиц и возникшей неисправностью?

69. Является ли неисправность единственной или имеются несколько независимых причин?

70. Является ли неисправность устранимой, и если да, то каким образом?

10.6. Вопросы о причинах возникновения дефектов

71. Какова причина возникновения каждого выявленного дефекта?

72. Связан ли дефект с ошибкой в исходном коде?

73. Связан ли дефект с ошибкой в проектировании архитектуры?

74. Связан ли дефект с ошибкой в проектировании базы данных?

75. Связан ли дефект с ошибкой в реализации интерфейсов?

76. Связан ли дефект с ошибкой в обработке исключительных ситуаций?

77. Связан ли дефект с отсутствием валидации входных данных?

78. Связан ли дефект с некорректной работой с памятью?

79. Связан ли дефект с некорректной работой с ресурсами?

80. Связан ли дефект с некорректной работой с сетевыми соединениями?

81. Связан ли дефект с использованием устаревших или несовместимых библиотек?

82. Связан ли дефект с нарушением стандартов разработки?

83. Связан ли дефект с недостаточным тестированием?

84. Связан ли дефект с недостаточной документированностью?

85. Мог ли дефект быть выявлен при надлежащем тестировании?

10.7. Вопросы о качестве исходного кода

86. Соответствует ли исходный код программного продукта требованиям, предъявляемым к качеству кода?

87. Соответствует ли исходный код стандартам оформления, принятым в разработке?

88. Имеются ли в исходном коде нарушения структурной целостности?

89. Имеются ли в исходном коде признаки дублирования?

90. Имеются ли в исходном коде признаки избыточности?

91. Имеются ли в исходном коде «мёртвые» участки, не используемые при выполнении?

92. Какова цикломатическая сложность исходного кода?

93. Какова связанность модулей исходного кода?

94. Каково сцепление модулей исходного кода?

95. Соответствует ли читаемость исходного кода требованиям, предъявляемым к сопровождаемому коду?

96. Имеются ли в исходном коде комментарии, соответствующие фактическому содержанию кода?

97. Имеются ли в исходном коде признаки копирования из сторонних источников?

98. Имеются ли в исходном коде признаки использования сгенерированного кода?

99. Имеются ли в исходном коде признаки использования обфускации?

100. Возможно ли сопровождение исходного кода силами сторонних специалистов?

10.8. Вопросы о качестве документации

101. Соответствует ли документация программного продукта фактическому состоянию продукта?

102. Является ли документация полной?

103. Является ли документация корректной?

104. Является ли документация актуальной?

105. Содержит ли документация описание всех функций программного продукта?

106. Содержит ли документация описание всех интерфейсов программного продукта?

107. Содержит ли документация описание всех настроек программного продукта?

108. Содержит ли документация описание требований к среде функционирования?

109. Содержит ли документация описание порядка развёртывания?

110. Содержит ли документация описание порядка резервного копирования и восстановления?

111. Содержит ли документация описание порядка мониторинга?

112. Содержит ли документация описание порядка устранения неисправностей?

113. Содержит ли документация описание мер по обеспечению безопасности?

114. Достаточна ли документация для эксплуатации программного продукта?

115. Достаточна ли документация для сопровождения программного продукта?

10.9. Вопросы об архитектуре программного продукта

116. Соответствует ли архитектура программного продукта требованиям технического задания?

117. Соответствует ли архитектура программного продукта проектной документации?

118. Является ли архитектура программного продукта монолитной или модульной?

119. Обеспечивает ли архитектура программного продукта возможность масштабирования?

120. Обеспечивает ли архитектура программного продукта возможность горизонтального масштабирования?

121. Обеспечивает ли архитектура программного продукта возможность вертикального масштабирования?

122. Обеспечивает ли архитектура программного продукта отказоустойчивость?

123. Обеспечивает ли архитектура программного продукта возможность резервного копирования?

124. Обеспечивает ли архитектура программного продукта возможность восстановления?

125. Обеспечивает ли архитектура программного продукта возможность интеграции с внешними системами?

126. Обеспечивает ли архитектура программного продукта возможность расширения функциональности?

127. Имеются ли в архитектуре программного продукта единые точки отказа?

128. Имеются ли в архитектуре программного продукта узкие места?

129. Имеются ли в архитектуре программного продукта избыточные компоненты?

130. Соответствует ли архитектура программного продукта современным требованиям к аналогичным системам?

10.10. Вопросы о производительности программного продукта

131. Соответствует ли производительность программного продукта требованиям технического задания?

132. Соответствует ли время отклика программного продукта требованиям технического задания?

133. Соответствует ли пропускная способность программного продукта требованиям технического задания?

134. Выдерживает ли программный продукт расчётную нагрузку?

135. Выдерживает ли программный продукт пиковую нагрузку?

136. Выдерживает ли программный продукт нагрузку, превышающую расчётную?

137. Имеются ли в программном продукте узкие места, ограничивающие производительность?

138. Имеются ли в программном продукте неоптимальные запросы к базе данных?

139. Имеются ли в программном продукте неоптимальные алгоритмы?

140. Имеются ли в программном продукте избыточные вычисления?

141. Имеются ли в программном продукте проблемы с кэшированием?

142. Имеются ли в программном продукте проблемы с управлением памятью?

143. Имеются ли в программном продукте проблемы с управлением ресурсами?

144. Соответствует ли производительность программного продукта производительности аналогичных продуктов?

145. Возможно ли повышение производительности программного продукта без существенной переработки?

10.11. Вопросы о безопасности программного продукта

146. Соответствует ли программный продукт требованиям информационной безопасности, предусмотренным техническим заданием?

147. Имеются ли в программном продукте уязвимости?

148. Какие именно уязвимости имеются в программном продукте?

149. Являются ли выявленные уязвимости критическими?

150. Возможно ли использование выявленных уязвимостей для несанкционированного доступа?

151. Возможно ли использование выявленных уязвимостей для несанкционированного изменения данных?

152. Возможно ли использование выявленных уязвимостей для несанкционированного удаления данных?

153. Возможно ли использование выявленных уязвимостей для нарушения работоспособности?

154. Обеспечивает ли программный продукт защиту от SQL-инъекций?

155. Обеспечивает ли программный продукт защиту от межсайтового скриптинга?

156. Обеспечивает ли программный продукт защиту от подделки межсайтовых запросов?

157. Обеспечивает ли программный продукт защиту от несанкционированного доступа?

158. Обеспечивает ли программный продукт разграничение прав доступа?

159. Обеспечивает ли программный продукт шифрование чувствительных данных?

160. Обеспечивает ли программный продукт журналирование действий пользователей?

10.12. Вопросы о защите персональных данных

161. Соответствует ли программный продукт требованиям законодательства о персональных данных?

162. Обрабатывает ли программный продукт персональные данные?

163. Какие категории персональных данных обрабатываются?

164. Обеспечивает ли программный продукт согласие субъектов на обработку персональных данных?

165. Обеспечивает ли программный продукт возможность отзыва согласия?

166. Обеспечивает ли программный продукт возможность уничтожения персональных данных?

167. Обеспечивает ли программный продукт хранение персональных данных на территории Российской Федерации?

168. Обеспечивает ли программный продукт защиту персональных данных при передаче?

169. Обеспечивает ли программный продукт защиту персональных данных при хранении?

170. Обеспечивает ли программный продукт разграничение доступа к персональным данным?

10.13. Вопросы об объёме и стоимости выполненных работ

171. Какие работы фактически выполнены разработчиком?

172. Каков объём фактически выполненных работ?

173. Соответствует ли объём фактически выполненных работ объёму, предусмотренному договором?

174. Какова рыночная стоимость фактически выполненных работ?

175. Соответствует ли стоимость фактически выполненных работ сумме, уплаченной заказчиком?

176. Имеется ли неосновательное обогащение на стороне разработчика?

177. Имеется ли неосновательное обогащение на стороне заказчика?

178. Какова стоимость работ, которые остались невыполненными?

179. Какова стоимость работ, которые выполнены с ненадлежащим качеством?

180. Какова стоимость работ по устранению выявленных дефектов?

10.14. Вопросы о соблюдении технологических процессов

181. Соблюдались ли разработчиком стандарты разработки программного обеспечения?

182. Соблюдались ли разработчиком методологии управления проектами?

183. Проводилось ли разработчиком тестирование программного продукта?

184. Каков объём проведённого тестирования?

185. Соответствует ли объём тестирования требованиям технического задания?

186. Вёлся ли разработчиком версионный контроль исходного кода?

187. Вёлся ли разработчиком учёт дефектов?

188. Вёлся ли разработчиком учёт изменений требований?

189. Проводилось ли разработчиком документирование хода работ?

190. Проводилось ли разработчиком рецензирование кода?

191. Проводилось ли разработчиком автоматизированное тестирование?

192. Проводилось ли разработчиком нагрузочное тестирование?

193. Проводилось ли разработчиком тестирование безопасности?

194. Проводилось ли разработчиком приёмочное тестирование?

195. Соблюдались ли разработчиком сроки, предусмотренные договором?

10.15. Вопросы о соблюдении требований контрактной системы

196. Соответствует ли программный продукт требованиям государственного или муниципального контракта?

197. Соответствует ли программный продукт требованиям технического задания, являющегося приложением к контракту?

198. Соответствует ли программный продукт требованиям к качеству, установленным контрактом?

199. Соответствует ли программный продукт требованиям к гарантийным обязательствам, установленным контрактом?

200. Соответствует ли программный продукт требованиям к сопровождению, установленным контрактом?

201. Соответствует ли программный продукт требованиям к передаче прав, установленным контрактом?

202. Соответствует ли программный продукт требованиям к передаче документации, установленным контрактом?

203. Соответствует ли программный продукт требованиям к обучению пользователей, установленным контрактом?

204. Соответствует ли программный продукт требованиям к вводу в эксплуатацию, установленным контрактом?

205. Соответствует ли программный продукт требованиям к импортозамещению, установленным контрактом?

10.16. Вопросы о пригодности программного продукта к использованию

206. Пригоден ли программный продукт для использования по назначению?

207. Пригоден ли программный продукт для использования в предусмотренной среде?

208. Пригоден ли программный продукт для использования предусмотренным кругом пользователей?

209. Пригоден ли программный продукт для использования с предусмотренными данными?

210. Пригоден ли программный продукт для использования с предусмотренной нагрузкой?

211. Пригоден ли программный продукт для использования без дополнительной доработки?

212. Пригоден ли программный продукт для использования без дополнительного обучения пользователей?

213. Пригоден ли программный продукт для использования без дополнительной настройки?

214. Пригоден ли программный продукт для использования в течение предусмотренного срока?

215. Пригоден ли программный продукт для использования с учётом выявленных дефектов?

10.17. Вопросы о возможности устранения выявленных недостатков

216. Возможно ли устранение выявленных недостатков?

217. Какие недостатки возможно устранить?

218. Какие недостатки невозможно устранить?

219. Какова трудоёмкость устранения выявленных недостатков?

220. Какова стоимость устранения выявленных недостатков?

221. Какова длительность устранения выявленных недостатков?

222. Возможно ли устранение недостатков силами разработчика?

223. Возможно ли устранение недостатков силами третьих лиц?

224. Возможно ли устранение недостатков без нарушения целостности программного продукта?

225. Возможно ли устранение недостатков без нарушения сроков, предусмотренных договором?

10.18. Вопросы о разграничении ответственности

226. Имеется ли вина разработчика в возникновении выявленных недостатков?

227. Имеется ли вина заказчика в возникновении выявленных недостатков?

228. Имеется ли вина третьих лиц в возникновении выявленных недостатков?

229. Имеется ли вина обеих сторон в возникновении выявленных недостатков?

230. Какова степень вины каждой стороны?

231. Мог ли разработчик предотвратить возникновение недостатков?

232. Мог ли заказчик предотвратить возникновение недостатков?

233. Действовал ли разработчик добросовестно?

234. Действовал ли заказчик добросовестно?

235. Имеются ли обстоятельства, освобождающие стороны от ответственности?

10.19. Вопросы о соответствии программного продукта требованиям импортозамещения

236. Соответствует ли программный продукт требованиям импортозамещения?

237. Использованы ли в программном продукте иностранные компоненты?

238. Какие именно иностранные компоненты использованы?

239. Возможна ли замена иностранных компонентов на отечественные аналоги?

240. Какова трудоёмкость замены иностранных компонентов?

241. Какова стоимость замены иностранных компонентов?

242. Соответствует ли программный продукт требованиям реестра отечественного программного обеспечения?

243. Возможно ли включение программного продукта в реестр отечественного программного обеспечения?

244. Имеются ли в программном продукте компоненты с лицензиями, не допускающими коммерческое использование?

245. Имеются ли в программном продукте компоненты с лицензиями, требующими раскрытия исходного кода?

10.20. Вопросы о соответствии программного продукта требованиям доступности

246. Соответствует ли программный продукт требованиям доступности для инвалидов?

247. Обеспечивает ли программный продукт возможность использования лицами с нарушениями зрения?

248. Обеспечивает ли программный продукт возможность использования лицами с нарушениями слуха?

249. Обеспечивает ли программный продукт возможность использования лицами с нарушениями опорно-двигательного аппарата?

250. Соответствует ли программный продукт требованиям к альтернативному тексту для изображений?

251. Соответствует ли программный продукт требованиям к контрастности?

252. Соответствует ли программный продукт требованиям к навигации с клавиатуры?

253. Соответствует ли программный продукт требованиям к семантической разметке?

254. Соответствует ли программный продукт требованиям к масштабируемости шрифтов?

255. Соответствует ли программный продукт требованиям к озвучиванию элементов?

10.21. Вопросы о соответствии программного продукта требованиям по защите детей

256. Соответствует ли программный продукт требованиям по защите детей?

257. Собирает ли программный продукт избыточные данные о детях?

258. Содержит ли программный продукт рекламу, не соответствующую возрасту?

259. Содержит ли программный продукт контент, не соответствующий возрасту?

260. Обеспечивает ли программный продукт родительский контроль?

261. Обеспечивает ли программный продукт защиту от нежелательных контактов?

262. Обеспечивает ли программный продукт защиту от вредоносного контента?

263. Соответствует ли программный продукт требованиям к обработке данных детей?

264. Соответствует ли программный продукт требованиям к согласию родителей?

265. Соответствует ли программный продукт требованиям к удалению данных детей?

10.22. Вопросы о соответствии программного продукта требованиям по хранению данных

266. Соответствует ли программный продукт требованиям по хранению данных на территории Российской Федерации?

267. Хранятся ли данные, обрабатываемые программным продуктом, на территории Российской Федерации?

268. Передаются ли данные, обрабатываемые программным продуктом, за пределы Российской Федерации?

269. Использует ли программный продукт облачные сервисы иностранных провайдеров?

270. Использует ли программный продукт серверы, расположенные за пределами Российской Федерации?

271. Возможно ли перенесение данных на серверы, расположенные на территории Российской Федерации?

272. Какова трудоёмкость перенесения данных?

273. Какова стоимость перенесения данных?

274. Соответствует ли программный продукт требованиям к резервному копированию данных?

275. Соответствует ли программный продукт требованиям к уничтожению данных?

10.23. Вопросы о соответствии программного продукта требованиям по лицензированию

276. Соответствует ли использование компонентов программного продукта условиям их лицензий?

277. Какие лицензии использованы в программном продукте?

278. Имеются ли в программном продукте компоненты с лицензиями, требующими раскрытия исходного кода?

279. Имеются ли в программном продукте компоненты с лицензиями, не допускающими коммерческое использование?

280. Имеются ли в программном продукте компоненты с лицензиями, не допускающими распространение?

281. Переданы ли заказчику лицензии на использование компонентов?

282. Имеются ли у заказчика права на использование всех компонентов?

283. Имеются ли риски нарушения лицензий?

284. Возможна ли замена компонентов с проблемными лицензиями?

285. Какова трудоёмкость замены компонентов?

10.24. Вопросы о соответствии программного продукта требованиям по сопровождению

286. Соответствует ли программный продукт требованиям по сопровождению, предусмотренным договором?

287. Осуществляется ли сопровождение программного продукта?

288. Каков объём сопровождения?

289. Соответствует ли объём сопровождения требованиям договора?

290. Имеются ли у разработчика обязательства по сопровождению?

291. Имеются ли у разработчика ресурсы для сопровождения?

292. Имеются ли у разработчика специалисты для сопровождения?

293. Имеется ли у разработчика документация для сопровождения?

294. Имеется ли у разработчика доступ к исходному коду для сопровождения?

295. Возможно ли сопровождение программного продукта силами третьих лиц?

10.25. Вопросы о соответствии программного продукта требованиям по обучению пользователей

296. Соответствует ли программный продукт требованиям по обучению пользователей?

297. Проводилось ли обучение пользователей?

298. Каков объём обучения?

299. Соответствует ли объём обучения требованиям договора?

300. Имеются ли материалы для обучения пользователей?

301. Соответствуют ли материалы для обучения требованиям?

302. Достаточны ли материалы для обучения?

303. Возможно ли обучение пользователей силами заказчика?

304. Возможно ли обучение пользователей силами третьих лиц?

305. Имеются ли у заказчика ресурсы для обучения пользователей?

10.26. Вопросы о соответствии программного продукта требованиям по вводу в эксплуатацию

306. Соответствует ли программный продукт требованиям по вводу в эксплуатацию?

307. Проводился ли ввод в эксплуатацию?

308. Соответствует ли ввод в эксплуатацию требованиям договора?

309. Имеются ли документы о вводе в эксплуатацию?

310. Соответствуют ли документы о вводе в эксплуатацию требованиям?

311. Имеются ли у заказчика ресурсы для ввода в эксплуатацию?

312. Имеются ли у заказчика специалисты для ввода в эксплуатацию?

313. Имеется ли у заказчика инфраструктура для ввода в эксплуатацию?

314. Возможен ли ввод в эксплуатацию силами заказчика?

315. Возможен ли ввод в эксплуатацию силами третьих лиц?

10.27. Вопросы о соответствии программного продукта требованиям по гарантийным обязательствам

316. Соответствует ли программный продукт требованиям по гарантийным обязательствам?

317. Имеются ли гарантийные обязательства разработчика?

318. Каков срок гарантийных обязательств?

319. Соответствует ли срок гарантийных обязательств требованиям договора?

320. Имеются ли случаи обращения за гарантийным обслуживанием?

321. Соответствуют ли действия разработчика по гарантийному обслуживанию требованиям договора?

322. Имеются ли у разработчика обязательства по устранению дефектов в гарантийный период?

323. Исполняются ли обязательства по устранению дефектов?

324. Имеются ли основания для отказа от гарантийного обслуживания?

325. Имеются ли основания для продления гарантийного периода?

10.28. Вопросы о соответствии программного продукта требованиям по передаче прав

326. Соответствует ли передача прав на программный продукт требованиям договора?

327. Переданы ли заказчику исключительные права на программный продукт?

328. Переданы ли заказчику права на использование программного продукта?

329. Соответствует ли объём переданных прав требованиям договора?

330. Имеются ли у разработчика обязательства по передаче прав?

331. Исполнены ли обязательства по передаче прав?

332. Имеются ли у заказчика документы, подтверждающие передачу прав?

333. Имеются ли у заказчика права на модификацию программного продукта?

334. Имеются ли у заказчика права на распространение программного продукта?

335. Имеются ли у заказчика права на сублицензирование программного продукта?

10.29. Вопросы о соответствии программного продукта требованиям по передаче документации

336. Соответствует ли передача документации требованиям договора?

337. Передана ли заказчику документация?

338. Соответствует ли объём переданной документации требованиям договора?

339. Соответствует ли качество переданной документации требованиям договора?

340. Имеются ли у заказчика документы, подтверждающие передачу документации?

341. Имеются ли у заказчика замечания к переданной документации?

342. Соответствуют ли замечания заказчика требованиям договора?

343. Имеются ли у разработчика обязательства по доработке документации?

344. Исполнены ли обязательства по доработке документации?

345. Возможно ли использование программного продукта без переданной документации?

10.30. Вопросы о соответствии программного продукта требованиям по качеству

346. Соответствует ли качество программного продукта требованиям договора?

347. Соответствует ли качество программного продукта требованиям технического задания?

348. Соответствует ли качество программного продукта требованиям стандартов?

349. Соответствует ли качество программного продукта требованиям, предъявляемым к аналогичным продуктам?

350. Имеются ли у заказчика замечания к качеству программного продукта?

351. Соответствуют ли замечания заказчика требованиям договора?

352. Имеются ли у разработчика обязательства по повышению качества?

353. Исполнены ли обязательства по повышению качества?

354. Возможно ли использование программного продукта при имеющемся качестве?

355. Возможно ли повышение качества без существенной переработки?

10.31. Вопросы о соответствии программного продукта требованиям по срокам

356. Соответствуют ли сроки выполнения работ требованиям договора?

357. Соблюдены ли сроки начала работ?

358. Соблюдены ли сроки окончания работ?

359. Соблюдены ли промежуточные сроки?

360. Имеются ли нарушения сроков?

361. Каковы причины нарушения сроков?

362. Связаны ли нарушения сроков с действиями разработчика?

363. Связаны ли нарушения сроков с действиями заказчика?

364. Связаны ли нарушения сроков с действиями третьих лиц?

365. Имеются ли основания для освобождения от ответственности за нарушение сроков?

10.32. Вопросы о соответствии программного продукта требованиям по стоимости

366. Соответствует ли стоимость работ требованиям договора?

367. Соответствует ли стоимость работ рыночной стоимости?

368. Имеется ли завышение стоимости работ?

369. Имеется ли занижение стоимости работ?

370. Соответствует ли стоимость работ объёму выполненных работ?

371. Имеются ли основания для изменения стоимости работ?

372. Имеются ли основания для перерасчёта стоимости работ?

373. Имеются ли основания для возврата части уплаченных средств?

374. Имеются ли основания для доплаты за выполненные работы?

375. Имеются ли основания для взыскания неосновательного обогащения?

10.33. Вопросы о соответствии программного продукта требованиям по ответственности

376. Имеются ли основания для привлечения разработчика к ответственности?

377. Имеются ли основания для привлечения заказчика к ответственности?

378. Имеются ли основания для взыскания штрафа?

379. Имеются ли основания для взыскания пеней?

380. Имеются ли основания для взыскания убытков?

381. Имеются ли основания для расторжения договора?

382. Имеются ли основания для отказа от исполнения договора?

383. Имеются ли основания для одностороннего расторжения договора?

384. Имеются ли основания для включения разработчика в реестр недобросовестных поставщиков?

385. Имеются ли основания для освобождения от ответственности?

10.34. Вопросы о соответствии программного продукта требованиям по урегулированию споров

386. Имеются ли основания для досудебного урегулирования спора?

387. Имеются ли основания для проведения переговоров?

388. Имеются ли основания для заключения мирового соглашения?

389. Имеются ли основания для проведения медиации?

390. Имеются ли основания для обращения в третейский суд?

391. Имеются ли основания для обращения в арбитражный суд?

392. Имеются ли основания для обращения в суд общей юрисдикции?

393. Имеются ли основания для обращения в государственные органы?

394. Имеются ли основания для обращения в правоохранительные органы?

395. Имеются ли основания для обращения в международные инстанции?

10.35. Вопросы о соответствии программного продукта требованиям по дальнейшему использованию

396. Возможно ли дальнейшее использование программного продукта?

397. Возможно ли дальнейшее использование программного продукта без разработчика?

398. Возможно ли дальнейшее использование программного продукта с другим разработчиком?

399. Возможно ли дальнейшее развитие программного продукта?

400. Возможно ли дальнейшее сопровождение программного продукта?

401. Возможно ли дальнейшее масштабирование программного продукта?

402. Возможно ли дальнейшее расширение функциональности?

403. Возможно ли дальнейшее повышение производительности?

404. Возможно ли дальнейшее повышение безопасности?

405. Возможно ли дальнейшее использование программного продукта после устранения выявленных недостатков?

---

ГЛАВА 11. СЛОЖНОСТИ ВЫПОЛНЕНИЯ ЭКСПЕРТИЗЫ КОМПЬЮТЕРНЫХ ПРОГРАММ

11.1. Инструментальные сложности

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

Пример 2. Устаревшие технологии. Программный продукт создан на языке и фреймворке, снятых с поддержки. Современные инструменты анализа с этим кодом не работают. Эксперт искал устаревшие версии инструментов, настраивал окружение, изучал недоступную документацию — это увеличило сроки и снизило достоверность.

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

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

Пример 5. Большой объём кода. Продукт содержал несколько миллионов строк. Полный анализ в разумные сроки невозможен, пришлось применять выборочный анализ и автоматизированные средства с приблизительными результатами.

Пример 6. Повреждённые данные. Журналы работы системы оказались частично утрачены и искажены. Восстановить полную хронологию событий и точное время возникновения неисправности не удалось.

11.2. Процедурные сложности

Пример 7. Некорректная формулировка вопросов. Суд поставил вопрос: «Является ли разработчик виновным в неисполнении контракта?» Вопрос требует правовой оценки, выходящей за пределы компетенции эксперта. Пришлось заявлять ходатайство о переформулировке, что затянуло процесс.

Пример 8. Неполнота материалов. Суду предоставили только часть материалов, не включив техническое задание и акты приёмки. Ключевые документы отсутствовали, пришлось запрашивать дополнительные материалы, что увеличило сроки.

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

Пример 10. Изменение вопросов в ходе экспертизы. Суд добавил новые вопросы и исключил часть первоначальных. Эксперт был вынужден перестраивать исследование, что увеличило трудоёмкость и сроки.

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

11.3. Конфликтные сложности

Пример 12. Противодействие разработчика. Разработчик, предвидя неблагоприятные выводы, не предоставлял материалы, затягивал ответы на запросы, оспаривал действия эксперта. Эксперт тратил время на преодоление противодействия вместо исследования.

Пример 13. Давление на эксперта. Представители разработчика предлагали вознаграждение за «правильные» выводы, угрожали судебным преследованием. Эксперт заявил о давлении и просил защиты.

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

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

11.4. Финансовые сложности

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

Пример 17. Непредвиденные расходы. В ходе экспертизы выяснилась необходимость дополнительных исследований, не предусмотренных договором. Стоимость возросла, потребовалось согласование дополнительного финансирования.

Пример 18. Двойные расходы. Из-за ошибок первоначальной экспертизы потребовалась повторная, что привело к двойным расходам. Стороны понесли дополнительные финансовые потери.

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

11.5. Юридические сложности

Пример 20. Пробелы в законодательстве. Законодательство не содержало норм, регулирующих отдельные аспекты экспертизы компьютерной программы. Эксперту пришлось действовать по аналогии, что создало риск оспаривания.

Пример 21. Необходимость толкования технического задания. Техническое задание содержало нечёткие формулировки, допускающие различные толкования. Эксперт столкнулся с необходимостью толкования, что выходило за пределы его компетенции.

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

Пример 23. Оспаривание методов. Сторона оспорила методы, применённые экспертом, ссылаясь на их ненаучность. Потребовалось привлечение дополнительных специалистов для оценки научной обоснованности методов.

11.6. Организационные сложности

Пример 24. Отсутствие квалифицированных экспертов. На рынке отсутствовали эксперты нужной квалификации. Пришлось привлекать специалистов из других регионов, что увеличило сроки и расходы.

Пример 25. Загруженность эксперта. Эксперт был загружен другими делами, экспертиза затянулась, сроки нарушены.

Пример 26. Увольнение эксперта. Эксперт уволился из экспертной организации в ходе проведения экспертизы. Дело пришлось передавать другому эксперту, что увеличило сроки.

Пример 27. Проблемы с сохранностью объектов. Объекты исследования были утрачены или повреждены при транспортировке. Пришлось восстанавливать их по копиям, что снизило достоверность.

11.7. Технические сложности

Пример 28. Невоспроизводимость дефекта. Дефект проявлялся периодически, при определённых условиях, которые не удавалось воспроизвести. Подтвердить наличие дефекта не удалось.

Пример 29. Зависимость от внешних систем. Продукт зависел от внешних систем, недоступных эксперту. Оценка работоспособности оказалась неполной.

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

Пример 31. Нестабильность. Продукт работал нестабильно, результаты тестирования различались при повторных запусках. Воспроизводимые результаты получить не удалось.

Пример 32. Отсутствие аналогов. Продукт не имел аналогов, с которыми можно было бы сравнить. Оценить его соответствие современному уровню не удалось.

11.8. Методологические сложности

Пример 33. Отсутствие методики. Утверждённой методики проведения экспертизы компьютерной программы не существовало. Эксперт разрабатывал методику самостоятельно, что создало риск оспаривания.

Пример 34. Противоречивость методик. Существующие методики противоречили друг другу. Эксперт не смог выбрать, какой из них следовать.

Пример 35. Субъективность оценки. Методика предполагала субъективную оценку, результаты которой зависели от эксперта. Это снизило объективность выводов.

Пример 36. Неоднозначность выводов. Результаты анализа допускали различные интерпретации. Категоричные выводы сделать не удалось.

11.9. Этические сложности

Пример 37. Конфликт между истиной и интересом заказчика. Заказчик ожидал определённых выводов, но результаты исследования противоречили его ожиданиям. Эксперт оказался перед выбором: сообщить истину или угодить заказчику.

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

Пример 39. Некомпетентность. Эксперт взялся за работу, выходящую за пределы его компетенции. Выводы оказались необоснованными, что привело к негативным последствиям.

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

---

ГЛАВА 12. РЕЦЕНЗИИ И РЕЦЕНЗИРОВАНИЕ В ЭКСПЕРТИЗЕ КОМПЬЮТЕРНЫХ ПРОГРАММ

12.1. Сущность рецензирования заключения экспертизы компьютерной программы

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

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

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

12.2. Рецензирование недостоверной и лживой экспертизы компьютерной программы

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

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

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

Польза рецензии при оспаривании ложной экспертизы компьютерной программы. Рецензия позволяет стороне:

• получить профессиональную оценку заключения от независимого специалиста;

• сформулировать конкретные, проверяемые доводы против заключения;

• обосновать ходатайство о назначении повторной экспертизы;

• подготовить вопросы для допроса эксперта в суде;

• привлечь внимание суда к нарушениям, которые иначе могли остаться незамеченными;

• создать доказательственную базу для оспаривания заключения как недопустимого доказательства.

12.3. Структура и содержание рецензии на заключение экспертизы компьютерной программы

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

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

Описательная часть. Кратко излагается содержание рецензируемого заключения: какие вопросы были поставлены, какие методы применены, какие выводы сделаны. Это необходимо для того, чтобы читатель рецензии понимал, что именно критикуется.

Критическая часть. Основная часть рецензии. Здесь рецензент анализирует заключение по следующим направлениям:

• соответствие требованиям законодательства о судебной экспертной деятельности;

• полнота и достаточность исследованных материалов;

• корректность выбора и применения методов;

• обоснованность выводов;

• наличие логических, методических, арифметических ошибок;

• соответствие выводов исследовательской части;

• соблюдение пределов компетенции эксперта;

• наличие признаков недостоверности или предвзятости.

Каждое замечание должно быть конкретным, проверяемым и подкреплённым ссылкой на норму, стандарт, методику или фактическое противоречие. Голословная критика без указания на конкретные нарушения не имеет доказательственной силы.

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

12.4. Правовой статус рецензии как доказательства

Правовой статус рецензии в судебном процессе является предметом продолжающейся дискуссии и неоднозначной судебной практики.

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

Оценка рецензии судом. Вместе с тем рецензия не может быть произвольно исключена из процесса. Верховный Суд Российской Федерации в Определении от 25 января 2018 г. № 305-ЭС17-11486 указал, что ходатайство о приобщении к материалам дела рецензии, составленной для опровержения выводов экспертизы, не может быть отклонено, поскольку это лишает сторону возможности доказать свои возражения. Неприобщение рецензии и отказ в проведении повторной экспертизы были признаны неправомерными.

В Определении Верховного Суда Российской Федерации от 10 октября 2014 г. № 305-ЭС14-3484 сформулирована позиция, согласно которой рецензия, полученная во внесудебном порядке и составленная после получения результатов судебной экспертизы, не обладает необходимой доказательственной силой в подтверждение заявленных требований. Она не может являться доказательством, опровергающим выводы судебной экспертизы, поскольку рецензирование экспертных заключений не предусмотрено процессуальным законодательством.

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

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

Конституционный принцип состязательности. Конституционный Суд Российской Федерации в Определении от 20 июля 2021 г. № 1593-О указал, что придание особого доказательственного значения заключению (рецензии) стороны в деле, пусть и обладающей специальными знаниями, исходя из конституционного принципа состязательности и равноправия сторон, является недопустимым. Это означает, что рецензия не может автоматически опровергать судебную экспертизу, но и судебная экспертиза не имеет заранее установленной силы перед рецензией.

12.5. Процессуальные возможности использования рецензии

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

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

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

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

Обоснование недопустимости заключения. Если рецензия выявила процессуальные нарушения (отсутствие предупреждения об ответственности, выход за пределы компетенции, использование недопустимых методов), сторона может заявить о недопустимости заключения как доказательства.

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

12.6. Проблемы и ограничения рецензирования

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

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

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

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

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

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

12.7. Стратегия использования рецензии

Оптимальная стратегия использования рецензии включает следующие этапы.

Этап первый: получение заключения. Сторона получает заключение экспертизы компьютерной программы, знакомится с ним, оценивает его выводы.

Этап второй: принятие решения о рецензировании. Если выводы заключения неблагоприятны для стороны и есть основания сомневаться в их обоснованности, принимается решение о заказе рецензии. Если заключение явно обоснованно, рецензирование может быть бесперспективным.

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

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

Этап пятый: приобщение рецензии к делу. Сторона заявляет ходатайство о приобщении рецензии к материалам дела с обоснованием её значения для дела.

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

Этап седьмой: допрос эксперта. Если рецензия выявила конкретные противоречия, сторона ходатайствует о вызове эксперта для дачи пояснений. Вопросы, подготовленные на основе рецензии, позволяют проверить обоснованность выводов эксперта.

12.8. Рецензия и повторная экспертиза компьютерной программы: соотношение

Рецензия и повторная экспертиза — разные инструменты, решающие разные задачи. Рецензия отвечает на вопрос, обоснованно ли заключение. Повторная экспертиза отвечает на вопрос по существу: каковы фактические обстоятельства дела.

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

Бывает и обратный результат: рецензия показывает, что заключение обоснованно, и оспаривать его бесперспективно. Это экономит расходы на повторную экспертизу, которая подтвердила бы прежние выводы.

12.9. Значение рецензирования для экспертизы компьютерной программы

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

• выявлять ошибки и нарушения, допущенные экспертами;

• повышать ответственность экспертов;

• обеспечивать состязательность процесса;

• помогать суду в оценке заключений;

• защищать права сторон от недобросовестных экспертиз.

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

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

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

---

ГЛАВА 13. ПРИБОРЫ И ИНОЕ ДИАГНОСТИЧЕСКОЕ ОБОРУДОВАНИЕ  

13.1. Общая характеристика диагностического обеспечения экспертизы компьютерной программы

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

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

13.2. Аппаратные средства вычислительной техники

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

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

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

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

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

13.3. Средства хранения и фиксации данных

Важнейшей задачей экспертизы компьютерной программы является обеспечение сохранности объектов исследования. Для этого применяются средства хранения и фиксации данных.

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

Средства write-blocker. Для работы с носителями информации, содержащими исследуемые объекты, применяются аппаратные и программные блокираторы записи. Они исключают возможность случайного или намеренного изменения данных на носителе в ходе экспертизы. Применение блокираторов записи особенно важно при исследовании носителей, изъятых в ходе следственных действий.

Средства вычисления хеш-сумм. Для подтверждения целостности объектов экспертизы компьютерной программы вычисляются хеш-суммы. Хеш-сумма представляет собой уникальное значение, вычисляемое по содержимому файла. Любое изменение файла приводит к изменению хеш-суммы. Эксперт фиксирует хеш-суммы объектов до начала исследования и после его завершения, что позволяет доказать, что объекты не были изменены.

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

Средства документирования. Для фиксации состояния объектов применяются фото- и видеосъёмка, средства создания скриншотов, средства протоколирования. Фотографии экранов, распечатки журналов, видеозаписи экспериментов становятся приложениями к заключению эксперта.

13.4. Средства защиты информации

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

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

Средства разграничения доступа. Для ограничения доступа к объектам экспертизы применяются системы разграничения прав пользователей. Эксперт должен иметь доступ только к тем объектам, которые необходимы для исследования.

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

Средства защиты от утечек. Для предотвращения утечек информации применяются системы защиты от утечек данных. Они контролируют передачу информации за пределы защищённого периметра.

13.5. Сетевое оборудование

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

Коммутаторы и маршрутизаторы. Применяются для создания локальной сети, в которой развёртывается исследуемый программный продукт. Коммутаторы обеспечивают соединение устройств, маршрутизаторы — передачу данных между сетями.

Средства анализа трафика. Для исследования сетевого взаимодействия применяются анализаторы трафика (снифферы). Они позволяют захватывать и анализировать пакеты данных, выявлять ошибки протоколов, обнаруживать подозрительную активность.

Средства имитации сети. Для моделирования различных сетевых условий (задержки, потери пакетов, ограничения пропускной способности) применяются программные и аппаратные имитаторы сети. Они позволяют проверить, как программный продукт ведёт себя в неблагоприятных сетевых условиях.

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

13.6. Испытательные стенды

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

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

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

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

13.7. Измерительные программные комплексы

Измерение характеристик программного продукта — важная задача экспертизы компьютерной программы. Для этого применяются измерительные программные комплексы.

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

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

Средства нагрузочного тестирования. Эти средства создают нагрузку на программный продукт и измеряют его реакцию. Они позволяют определить предельную нагрузку, время отклика, пропускную способность, устойчивость к пиковым нагрузкам.

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

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

13.8. Инструменты анализа кода

Анализ кода — центральная задача экспертизы компьютерной программы. Для её решения применяются инструменты статического и динамического анализа.

Статические анализаторы. Статические анализаторы исследуют исходный код без его выполнения. Они выявляют синтаксические ошибки, нарушения стандартов, потенциальные уязвимости, «мёртвый» код, дублирование, избыточность. Примерами таких инструментов являются SonarQube, Checkmarx, Coverity.

Линтеры. Линтеры проверяют код на соответствие стилевым требованиям, выявляют потенциальные ошибки, предупреждают о подозрительных конструкциях. Примерами являются ESLint, Pylint, JSHint.

Инструменты поиска дублирования. Эти инструменты выявляют повторяющиеся фрагменты кода. Примерами являются Simian, PMD.

Инструменты анализа метрик. Эти инструменты вычисляют количественные характеристики кода: количество строк, цикломатическую сложность, связанность, сцепление. Они позволяют оценить качество кода и его сопровождаемость.

Отладчики. Отладчики позволяют выполнять код пошагово, устанавливать точки останова, просматривать значения переменных, анализировать состояние программы. Примерами являются GDB, WinDbg, Visual Studio Debugger.

Профилировщики. Профилировщики измеряют характеристики выполнения программы. Примерами являются JProfiler, dotTrace, Valgrind.

Средства трассировки. Средства трассировки записывают последовательность вызовов функций и системных вызовов. Примерами являются strace, ltrace.

13.9. Инструменты тестирования

Тестирование — важнейший метод экспертизы компьютерной программы. Для его проведения применяются специализированные инструменты.

Фреймворки модульного тестирования. Эти фреймворки позволяют создавать и выполнять тесты отдельных модулей программного продукта. Примерами являются JUnit, NUnit, pytest.

Инструменты функционального тестирования. Эти инструменты имитируют действия пользователя и проверяют реакцию программного продукта. Примерами являются Selenium, Cypress.

Инструменты нагрузочного тестирования. Эти инструменты создают нагрузку на программный продукт и измеряют его реакцию. Примерами являются JMeter, LoadRunner.

Инструменты тестирования API. Эти инструменты позволяют отправлять запросы к программным интерфейсам и анализировать ответы. Примерами являются Postman, SoapUI.

Инструменты тестирования безопасности. Эти инструменты выявляют уязвимости программного продукта. Примерами являются OWASP ZAP, Burp Suite.

Инструменты тестирования мобильных приложений. Эти инструменты позволяют тестировать приложения для мобильных устройств. Примерами являются Appium, Espresso.

Инструменты тестирования доступности. Эти инструменты проверяют соответствие программного продукта требованиям доступности для лиц с ограниченными возможностями. Примерами являются axe, WAVE.

13.10. Инструменты реверс-инжиниринга

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

Дизассемблеры. Дизассемблеры преобразуют объектный код в язык ассемблера. Примерами являются IDA Pro, Ghidra.

Декомпиляторы. Декомпиляторы преобразуют объектный код в исходный код на языке высокого уровня. Примерами являются JD-GUI, dotPeek.

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

Инструменты деобфускации. Эти инструменты восстанавливают обфусцированный код, делая его читаемым.

13.11. Инструменты анализа журналов

Журналы работы системы — важный источник информации для экспертизы компьютерной программы. Для их анализа применяются специальные инструменты.

Системы сбора и анализа логов. Эти системы собирают журналы из различных источников, индексируют их, обеспечивают поиск и визуализацию. Примерами являются ELK Stack, Splunk.

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

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

13.12. Инструменты работы с репозиториями

Репозитории систем контроля версий содержат историю изменений программного кода. Для их анализа применяются специальные инструменты.

Системы контроля версий. Примерами являются Git, SVN, Mercurial.

Инструменты анализа истории. Эти инструменты позволяют изучать историю изменений, выявлять авторов, определять время внесения изменений. Примерами являются GitLog, GitStats.

Инструменты визуализации ветвления. Эти инструменты представляют историю ветвления в графическом виде, что облегчает понимание процесса разработки.

13.13. Инструменты анализа зависимостей

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

Менеджеры зависимостей. Примерами являются Maven, Gradle, npm.

Инструменты анализа уязвимостей. Эти инструменты проверяют зависимости на наличие известных уязвимостей. Примерами являются OWASP Dependency-Check.

Инструменты построения графов зависимостей. Эти инструменты визуализируют связи между компонентами программного продукта.

13.14. Инструменты моделирования

Моделирование позволяет эксперту проверить гипотезы, не прибегая к реальному запуску программного продукта. Для моделирования применяются специальные инструменты.

Инструменты построения диаграмм. Примерами являются PlantUML, Draw.io.

Инструменты имитационного моделирования. Эти инструменты позволяют моделировать поведение системы в различных условиях.

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

13.15. Средства документирования результатов

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

Средства создания отчётов. Эти средства позволяют формировать отчёты, содержащие текстовые описания, таблицы, диаграммы, скриншоты.

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

Средства создания резервных копий. Эти средства позволяют создавать копии объектов экспертизы для обеспечения их сохранности.

Средства протоколирования. Эти средства фиксируют все действия эксперта в ходе исследования, что обеспечивает проверяемость и воспроизводимость.

13.16. Требования к приборам и диагностическому оборудованию

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

Легальность. Все программные и аппаратные средства должны быть приобретены легально, иметь лицензии или быть свободными. Использование нелицензионного программного обеспечения недопустимо.

Проверенность. Средства должны быть проверены, при необходимости — сертифицированы. Эксперт должен быть уверен в достоверности результатов, получаемых с их помощью.

Документированность. Применение средств должно документироваться: какие средства использованы, какие версии, какие настройки, какие результаты получены.

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

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

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

13.17. Особенности приборного обеспечения при экспертизе компьютерной программы по государственным и муниципальным контрактам

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

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

Требования к импортозамещению. В ряде случаев к приборному обеспечению предъявляются требования импортозамещения. Это означает, что должны использоваться отечественные программные и аппаратные средства.

Требования к сертификации. Отдельные средства должны быть сертифицированы в системе сертификации средств защиты информации.

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

---

ГЛАВА 14. ГЛОССАРИЙ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ

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

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

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

Независимая экспертиза компьютерной программы — синоним досудебной экспертизы; исследование, проводимое вне рамок судебного процесса, не имеющее процессуального статуса судебного доказательства.

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

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

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

Заключение эксперта — документ, оформленный по результатам экспертизы компьютерной программы, содержащий вводную, исследовательскую части и выводы, подписанный экспертом и удостоверенный в установленном порядке.

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

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

Исследовательская часть заключения — часть заключения, в которой описываются объекты исследования, применённые методы и инструменты, ход исследования, полученные результаты.

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

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

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

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

Исходный код — текст программы на языке программирования, доступный для чтения и изменения человеком.

Объектный код — результат компиляции исходного кода, представленный в машинно-читаемой форме.

Исполняемый файл — файл, содержащий программу в форме, готовой к выполнению вычислительной системой.

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

Государственный контракт — договор, заключаемый государственным заказчиком от имени Российской Федерации или субъекта Российской Федерации в целях обеспечения государственных нужд.

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

Заказчик — лицо, заказывающее создание программного продукта: государственный орган, муниципалитет, коммерческое предприятие, учреждение.

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

Неисполнение обязательства — полное невыполнение разработчиком работ, предусмотренных договором.

Ненадлежащее исполнение обязательства — выполнение работ с нарушением требований к качеству, объёму, срокам, предусмотренных договором.

Работоспособность — способность программного продукта выполнять заданные функции в определённых условиях.

Дефект — несоответствие программного продукта требованиям, приводящее к нарушению его функционирования.

Критический дефект — дефект, препятствующий использованию программного продукта по назначению.

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

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

Причина неисправности — фактор, приведший к возникновению неисправности программного продукта.

Причинно-следственная связь — объективная связь между действиями (бездействием) и наступившими последствиями, устанавливаемая экспертом.

Тестирование — целенаправленная проверка программного продукта на соответствие требованиям.

Функциональное тестирование — проверка выполнения программным продуктом заданных функций.

Интеграционное тестирование — проверка взаимодействия модулей программного продукта.

Системное тестирование — проверка программного продукта как единого целого.

Нагрузочное тестирование — проверка производительности программного продукта при различных нагрузках.

Стресс-тестирование — проверка устойчивости программного продукта при экстремальных нагрузках.

Регрессионное тестирование — проверка программного продукта после внесения изменений.

Приёмочное тестирование — проверка соответствия программного продукта критериям приёмки, установленным заказчиком.

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

Статический анализ — анализ исходного кода без его выполнения.

Динамический анализ — анализ программного продукта путём его выполнения.

Реверс-инжиниринг — восстановление исходного кода или архитектуры программного продукта по объектному коду.

Дизассемблирование — преобразование объектного кода в язык ассемблера.

Декомпиляция — преобразование объектного кода в исходный код на языке высокого уровня.

Обфускация — намеренное запутывание исходного кода для затруднения его анализа.

Деобфускация — восстановление обфусцированного кода.

Метрика кода — количественная характеристика исходного кода (количество строк, цикломатическая сложность, связанность, сцепление, дублирование).

Цикломатическая сложность — метрика, измеряющая количество независимых путей выполнения в программе.

Связанность модулей — метрика, измеряющая степень зависимости модулей друг от друга.

Сцепление модулей — метрика, измеряющая степень внутренней связности элементов модуля.

Дублирование кода — наличие в программном продукте повторяющихся фрагментов кода.

«Мёртвый» код — участки кода, которые не используются при выполнении программы.

Архитектура программного продукта — структура программного продукта, определяющая состав компонентов и связи между ними.

Монолитная архитектура — архитектура, при которой программный продукт представляет собой единое целое.

Микросервисная архитектура — архитектура, при которой программный продукт состоит из множества независимых сервисов.

Единая точка отказа — компонент, выход из строя которого приводит к отказу всей системы.

Масштабируемость — способность программного продукта увеличивать производительность при увеличении ресурсов.

Горизонтальное масштабирование — увеличение производительности путём добавления серверов.

Вертикальное масштабирование — увеличение производительности путём добавления ресурсов существующему серверу.

Отказоустойчивость — способность программного продукта сохранять работоспособность при отказах отдельных компонентов.

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

Время отклика — время, затрачиваемое программным продуктом на выполнение операции.

Пропускная способность — количество операций, выполняемых программным продуктом в единицу времени.

Уязвимость — недостаток программного продукта, позволяющий нарушить его безопасность.

Информационная безопасность — состояние защищённости информации, обрабатываемой программным продуктом.

Персональные данные — любая информация, относящаяся к прямо или косвенно определённому физическому лицу.

Защита персональных данных — комплекс мер, направленных на обеспечение безопасности персональных данных.

Импортозамещение — замена иностранного программного обеспечения отечественным.

Реестр отечественного программного обеспечения — перечень программного обеспечения, происходящего из Российской Федерации.

Лицензия — документ, определяющий условия использования программного продукта.

Проприетарная лицензия — лицензия, ограничивающая права пользователя на использование, изменение и распространение программного продукта.

Свободная лицензия — лицензия, предоставляющая пользователю широкие права на использование, изменение и распространение программного продукта.

Версионный контроль — система учёта изменений исходного кода.

Репозиторий — хранилище исходного кода и истории его изменений.

Ветвление — создание независимой линии разработки в системе версионного контроля.

Слияние — объединение изменений из разных ветвей разработки.

Журнал работы системы — файл, содержащий записи о событиях, происходящих в программном продукте.

Логирование — процесс записи событий в журнал.

Мониторинг — процесс наблюдения за работой программного продукта.

Резервное копирование — процесс создания копий данных для восстановления в случае утраты.

Восстановление — процесс возврата программного продукта или данных в работоспособное состояние.

Миграция данных — процесс переноса данных из одной системы в другую.

Целостность данных — состояние данных, при котором они сохраняют свою полноту и корректность.

Валидация — проверка входных данных на соответствие установленным требованиям.

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

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

API (интерфейс программирования приложений) — набор правил и инструментов, позволяющих программам взаимодействовать друг с другом.

Интеграция — процесс объединения программных продуктов для совместной работы.

Совместимость — способность программного продукта работать в определённой среде без конфликтов.

Конфигурация — совокупность настроек программного продукта и среды его функционирования.

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

Развёртывание — процесс установки и настройки программного продукта в среде функционирования.

Ввод в эксплуатацию — процесс начала использования программного продукта по назначению.

Сопровождение — процесс поддержания работоспособности программного продукта после ввода в эксплуатацию.

Гарантийное обслуживание — обслуживание программного продукта в течение гарантийного срока.

Техническая документация — совокупность документов, описывающих программный продукт.

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

Руководство администратора — документ, описывающий порядок настройки и сопровождения программного продукта.

Проектная документация — совокупность документов, описывающих проектные решения.

Эксплуатационная документация — совокупность документов, описывающих порядок эксплуатации программного продукта.

Матрица соответствия — таблица, сопоставляющая требования технического задания с фактической реализацией.

Актуальность документации — соответствие документации фактическому состоянию программного продукта.

Полнота документации — наличие в документации всех необходимых сведений.

Корректность документации — отсутствие в документации ошибок и противоречий.

Юзабилити — удобство использования программного продукта.

Доступность — возможность использования программного продукта лицами с ограниченными возможностями.

Альтернативный текст — текстовое описание изображения, используемое для озвучивания.

Контрастность — различие в яркости или цвете элементов интерфейса.

Семантическая разметка — разметка, отражающая смысловую структуру документа.

Скрин-ридер — программа, озвучивающая содержимое экрана для незрячих пользователей.

Аудит — комплексная проверка программного продукта.

Ревизия — проверка соответствия программного продукта требованиям.

Пентест — тестирование на проникновение, имитирующее действия злоумышленника.

Сканирование уязвимостей — автоматизированный поиск уязвимостей.

SQL-инъекция — уязвимость, позволяющая внедрять SQL-код в запросы.

Межсайтовый скриптинг (XSS) — уязвимость, позволяющая внедрять вредоносный скрипт в веб-страницу.

Подделка межсайтовых запросов (CSRF) — уязвимость, позволяющая выполнять действия от имени пользователя.

Шифрование — преобразование данных для защиты от несанкционированного доступа.

Аутентификация — процесс проверки подлинности пользователя.

Авторизация — процесс проверки прав пользователя.

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

Журналирование действий — запись действий пользователей в журнал.

Компрометация — нарушение безопасности программного продукта.

Утечка данных — несанкционированная передача данных третьим лицам.

Потеря данных — утрата данных вследствие сбоя или иных причин.

Восстановление данных — процесс возврата утраченных данных.

Уничтожение данных — процесс безвозвратного удаления данных.

Хранение данных — процесс размещения данных на носителях.

Облачный сервис — сервис, предоставляющий вычислительные ресурсы через интернет.

Сервер — компьютер, предоставляющий ресурсы другим компьютерам.

Виртуальная машина — программная эмуляция компьютера.

Контейнер — изолированная среда выполнения программного продукта.

Микросервис — независимый компонент программного продукта, выполняющий определённую функцию.

Прокси-сервер — промежуточный сервер, перенаправляющий запросы.

Балансировщик нагрузки — устройство или программа, распределяющая нагрузку между серверами.

Кэширование — сохранение результатов вычислений для ускорения последующих обращений.

Индекс базы данных — структура, ускоряющая поиск данных.

Транзакция — группа операций, выполняемых как единое целое.

Блокировка — механизм, предотвращающий одновременное изменение данных.

Таймаут — ограничение времени выполнения операции.

Переполнение памяти — ситуация, при которой программе не хватает памяти.

Утечка памяти — ситуация, при которой программа не освобождает выделенную память.

Профилирование — измерение характеристик работы программы.

Трассировка — запись последовательности выполнения программы.

Отладка — процесс поиска и устранения дефектов.

Отладчик — инструмент для отладки программ.

Линтер — инструмент для статического анализа кода.

Статический анализатор — инструмент для автоматического анализа кода.

Компилятор — программа, преобразующая исходный код в объектный.

Интерпретатор — программа, выполняющая исходный код без компиляции.

Фреймворк — программная платформа, определяющая структуру приложения.

Библиотека — набор программных компонентов, используемых при разработке.

Зависимость — компонент, необходимый для работы программного продукта.

Менеджер зависимостей — инструмент для управления зависимостями.

Конфликт версий — ситуация, при которой разные компоненты требуют разных версий одной зависимости.

Устаревшая зависимость — компонент, поддержка которого прекращена.

Уязвимая зависимость — компонент, содержащий известные уязвимости.

Открытый исходный код — исходный код, доступный для изучения и изменения.

Закрытый исходный код — исходный код, недоступный для изучения и изменения.

Проприетарное программное обеспечение — программное обеспечение, права на которое принадлежат правообладателю.

Свободное программное обеспечение — программное обеспечение, распространяемое на условиях свободных лицензий.

Отечественное программное обеспечение — программное обеспечение, происходящее из Российской Федерации.

Иностранное программное обеспечение — программное обеспечение, происходящее из-за рубежа.

Судебное доказательство — сведения о фактах, полученные в установленном законом порядке и используемые судом для установления обстоятельств дела.

Письменное доказательство — документ, содержащий сведения об обстоятельствах, имеющих значение для дела.

Допустимость доказательства — соответствие доказательства требованиям закона.

Достоверность доказательства — соответствие доказательства действительности.

Достаточность доказательств — совокупность доказательств, позволяющая суду сделать вывод об обстоятельствах дела.

Оценка доказательств — процесс определения судом относимости, допустимости, достоверности и достаточности доказательств.

Судебные издержки — расходы, связанные с рассмотрением дела в суде.

Распределение судебных расходов — порядок отнесения судебных издержек на стороны.

Возмещение расходов — компенсация понесённых стороной расходов.

Разумность расходов — соответствие расходов сложности дела и рыночным ценам.

Ходатайство — обращение стороны к суду с просьбой о совершении процессуального действия.

Отвод — заявление о недопустимости участия лица в процессе.

Дополнительная экспертиза — экспертиза, назначаемая при недостаточной ясности или полноте заключения.

Повторная экспертиза — экспертиза, назначаемая при сомнениях в обоснованности заключения.

Комиссионная экспертиза — экспертиза, проводимая несколькими экспертами одной специальности.

Комплексная экспертиза — экспертиза, проводимая экспертами разных специальностей.

Особое мнение эксперта — мнение эксперта, не согласного с выводами других экспертов.

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

Уголовная ответственность эксперта — ответственность за дачу заведомо ложного заключения.

Гражданско-правовая ответственность эксперта — ответственность за причинение ущерба вследствие некачественной экспертизы.

Дисциплинарная ответственность эксперта — ответственность за нарушение служебной дисциплины.

Административная ответственность эксперта — ответственность за невыполнение требований суда.

Профессиональная ответственность эксперта — ответственность перед профессиональным сообществом.

Сертификация эксперта — подтверждение соответствия квалификации эксперта требованиям профессиональных стандартов.

Аккредитация эксперта — официальное признание компетентности эксперта уполномоченным органом.

Реестр экспертов — перечень квалифицированных экспертов.

Квалификация эксперта — совокупность образования, опыта, знаний и навыков эксперта.

Компетенция эксперта — круг вопросов, которые эксперт вправе разрешать.

Пределы компетенции — границы, за которые эксперт не вправе выходить.

Независимость эксперта — отсутствие заинтересованности эксперта в исходе дела.

Беспристрастность эксперта — способность эксперта дать объективное заключение.

Конфликт интересов — ситуация, при которой эксперт заинтересован в определённом исходе дела.

Самоотвод эксперта — отказ эксперта от участия в деле при наличии конфликта интересов.

Конфиденциальность — обязанность эксперта сохранять в тайне сведения, ставшие известными в связи с экспертизой.

Научная обоснованность — соответствие методов и выводов эксперта современному уровню науки и техники.

Проверяемость — возможность воспроизведения исследования и проверки выводов.

Логическая непротиворечивость — отсутствие внутренних противоречий в заключении.

Полнота исследования — исследование всех объектов и вопросов.

Объективность исследования — отсутствие односторонности и предвзятости.

Всесторонность исследования — учёт всех обстоятельств, имеющих значение.

Методология экспертизы компьютерной программы — система методов, приёмов и средств, используемых экспертом.

Общенаучные методы — методы познания, применяемые во всех науках (анализ, синтез, индукция, дедукция, моделирование, эксперимент).

Специальные методы — методы, заимствованные из области программирования и информационных технологий.

Инструментальные средства — программные и аппаратные средства, используемые экспертом.

Фиксация объектов — обеспечение сохранности объектов исследования и документирование их состояния.

Резервное копирование объектов — создание копий объектов для обеспечения их сохранности.

Хеш-сумма — значение, вычисляемое по содержимому файла и используемое для проверки его целостности.

Цифровая подпись — средство подтверждения подлинности документа.

Этапы проведения экспертизы — последовательность действий эксперта от подготовки до оформления заключения.

Подготовительный этап — этап изучения постановления, определения объектов, планирования исследования.

Аналитический этап — этап анализа объектов исследования.

Синтетический этап — этап обобщения результатов исследования.

Заключительный этап — этап оформления заключения.

Сроки проведения экспертизы — время, необходимое для проведения исследования.

Стоимость экспертизы — денежное выражение затрат на проведение исследования.

Ценообразующие факторы — факторы, влияющие на стоимость экспертизы.

Трудоёмкость — количество затрат труда, необходимых для проведения экспертизы.

Трудозатраты — выраженное в человеко-часах или человеко-днях количество труда.

Накладные расходы — расходы, связанные с организацией деятельности экспертной организации.

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

Аванс — предварительная оплата экспертизы.

Окончательный расчёт — оплата экспертизы по завершении работы.

Поэтапная оплата — оплата экспертизы по мере выполнения этапов.

Спор между разработчиком и заказчиком — конфликт, возникающий при исполнении договора на создание программного продукта.

Претензия — письменное требование стороны к контрагенту об устранении нарушений.

Претензионный порядок — обязательная процедура досудебного урегулирования спора.

Мировое соглашение — соглашение сторон о прекращении спора.

Медиация — процедура урегулирования спора с участием посредника.

Третейский суд — негосударственный орган разрешения споров.

Арбитражный суд — государственный орган разрешения экономических споров.

Суд общей юрисдикции — государственный орган разрешения гражданских споров.

Апелляция — пересмотр решения суда вышестоящей инстанцией.

Кассация — проверка законности решения суда вышестоящей инстанцией.

Надзор — пересмотр решения суда в порядке надзора.

Исполнительное производство — процедура принудительного исполнения судебного акта.

---

ГЛАВА 15. ВЫВОДЫ И ЗАКЛЮЧЕНИЕ

Проведённое исследование позволяет сформулировать итоговые положения, имеющие как теоретическое, так и практическое значение для развития института экспертизы компьютерной программы.

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

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

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

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

Приглашение к сотрудничеству

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

Мы приглашаем к сотрудничеству:

• государственные органы и учреждения, осуществляющие закупки программного обеспечения и нуждающиеся в контроле качества исполнения контрактов;

• муниципальные образования, реализующие проекты цифровизации и сталкивающиеся с необходимостью оценки результатов работ;

• министерства и ведомства, реализующие крупные IT-проекты и заинтересованные в независимой оценке их результатов;

• коммерческие предприятия, заключившие договоры на разработку программного обеспечения и нуждающиеся в защите своих прав;

• разработчиков программного обеспечения, которым требуется доказать надлежащее исполнение обязательств перед заказчиком;

• юридические фирмы и адвокатские бюро, сопровождающие споры в сфере информационных технологий;

• арбитражных управляющих, нуждающихся в оценке программных продуктов в рамках процедур банкротства;

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

Мы готовы провести:

• судебную экспертизу компьютерной программы по определению суда;

• досудебную (независимую) экспертизу компьютерной программы по инициативе заказчика;

• рецензирование заключений других экспертных организаций;

• аудит программного обеспечения;

• оценку объёма и стоимости выполненных работ;

• оценку соответствия программного продукта техническому заданию;

• установление причин неисправностей программного обеспечения;

• выявление заимствований и нарушений лицензий;

• оценку информационной безопасности;

• оценку соответствия требованиям импортозамещения;

• иные виды исследований в области программного обеспечения.

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

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