ВВЕДЕНИЕ

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • описание API;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • отладчики;

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

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

   • серверы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Специальные методы программной экспертизы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• судом;

• сторонами;

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Заключение специалиста как результат досудебной программной экспертизы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Выводы:

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

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

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

4. Приложения:

   • таблицы;

   • схемы;

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

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

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

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

• полным;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

---

ГЛАВА 6. ПРОГРАММНАЯ ЭКСПЕРТИЗА В СУДЕБНОМ ПРОЦЕССЕ

6.1. Назначение судебной программной экспертизы

Судебная программная экспертиза назначается определением суда. Определение должно содержать:

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

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

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

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

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

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

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

6.2. Права и обязанности эксперта в судебном процессе

Эксперт в судебном процессе обладает правами:

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

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

• участвовать в судебных заседаниях;

• задавать вопросы;

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

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

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

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

• явиться по вызову;

• не разглашать сведения;

• соблюдать сроки.

6.3. Исследование заключения эксперта в судебном заседании

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

Суд оценивает заключение по внутреннему убеждению, основанному на всестороннем, полном, объективном исследовании всех доказательств.

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

Суд оценивает заключение по критериям:

• допустимость;

• достоверность;

• достаточность.

Суд проверяет:

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

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

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

• обоснованность выводов;

• непротиворечивость.

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

6.5. Дополнительная и повторная программная экспертиза

Дополнительная экспертиза назначается при недостаточной ясности или полноте заключения. Она поручается тому же или другому эксперту.

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

Комиссионная экспертиза проводится несколькими экспертами одной специальности.

Комплексная экспертиза проводится экспертами разных специальностей.

---

ГЛАВА 7. ТИПОВЫЕ ПРЕДМЕТЫ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ ПО СПОРАМ МЕЖДУ РАЗРАБОТЧИКОМ И ЗАКАЗЧИКОМ

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

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

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

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

• все ли функции, предусмотренные техническим заданием, реализованы?

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

• имеются ли отклонения, и если да, то какие?

Методы:

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

• анализ программного кода;

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

• сравнительный анализ.

Сложности:

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

• противоречия в требованиях;

• изменения требований в ходе разработки.

7.2. Споры о работоспособности программного продукта

Работоспособность — способность программного продукта выполнять заданные функции в определённых условиях.

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

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

• выполняет ли он заданные функции?

• соответствует ли производительность требованиям?

• имеются ли критические дефекты?

Методы:

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

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

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

• моделирование.

Сложности:

• зависимость от среды;

• изменчивость;

• субъективность оценки.

7.3. Споры о причинах неисправностей программного обеспечения

Установление причин неисправностей — сложная задача, требующая глубоких знаний.

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

• какова причина неисправности?

• связана ли она с действиями разработчика?

• связана ли она с действиями заказчика?

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

Методы:

• анализ кода;

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

• реверс-инжиниринг;

• моделирование.

Сложности:

• множественность причин;

• отсроченность проявления;

• отсутствие достаточных данных.

7.4. Споры о качестве документации

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

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

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

• достаточна ли она для эксплуатации?

• содержит ли она необходимые сведения?

Методы:

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

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

• экспертная оценка.

7.5. Споры об объёме и стоимости выполненных работ

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

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

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

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

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

Методы:

• анализ кода;

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

• сравнительный анализ;

• экономическая оценка.

---

ГЛАВА 8. ПРОГРАММНАЯ ЭКСПЕРТИЗА ПО СПОРАМ, СВЯЗАННЫМ С ГОСУДАРСТВЕННЫМИ И МУНИЦИПАЛЬНЫМИ КОНТРАКТАМИ

8.1. Особенности споров по государственным и муниципальным контрактам

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

• публичный характер;

• формализованность;

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

• регламентированная приёмка;

• контроль со стороны государства.

8.2. Программная экспертиза на стадии приёмки

Приёмка — критическая стадия исполнения контракта. Программная экспертиза на этой стадии позволяет:

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

• выявить дефекты;

• обосновать отказ от приёмки;

• обосновать подписание акта.

8.3. Программная экспертиза при расторжении контракта

Расторжение контракта — крайняя мера. Программная экспертиза позволяет:

• установить факт существенного нарушения;

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

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

• обосновать требования о возмещении убытков.

8.4. Программная экспертиза при взыскании штрафов и пеней

Штрафы и пени — меры ответственности за нарушение контракта. Программная экспертиза позволяет:

• установить факт нарушения;

• определить причину нарушения;

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

• обосновать размер штрафа.

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

Включение в реестр — серьёзное последствие для разработчика. Программная экспертиза позволяет:

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

• определить причину;

• оценить добросовестность разработчика.

---

ГЛАВА 9. ПРОГРАММНАЯ ЭКСПЕРТИЗА КАК ИНСТРУМЕНТ ЗАЩИТЫ ПРАВ ЗАКАЗЧИКА

9.1. Права заказчика при неисполнении или ненадлежащем исполнении контракта

Заказчик вправе:

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

• требовать возмещения убытков;

• требовать уплаты штрафов, пеней;

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

• обратиться в суд.

9.2. Роль программной экспертизы в защите прав заказчика

Программная экспертиза позволяет заказчику:

• доказать факт неисполнения;

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

• обосновать размер убытков;

• обосновать отказ от контракта;

• защитить бюджетные средства.

9.3. Доказывание факта неисполнения контракта

Для доказывания факта неисполнения необходимо установить:

• отсутствие результата работ;

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

• несоответствие результата требованиям.

9.4. Доказывание факта ненадлежащего исполнения контракта

Для доказывания факта ненадлежащего исполнения необходимо установить:

• наличие дефектов;

• критичность дефектов;

• причину дефектов;

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

9.5. Доказывание причинно-следственной связи между действиями разработчика и наступившими последствиями

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

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

• могли ли эти действия привести к последствиям;

• имелись ли иные причины.

---

ГЛАВА 10. ПРОГРАММНАЯ ЭКСПЕРТИЗА КАК ИНСТРУМЕНТ ЗАЩИТЫ ПРАВ РАЗРАБОТЧИКА

10.1. Права разработчика при необоснованных претензиях заказчика

Разработчик вправе:

• требовать оплаты выполненных работ;

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

• доказывать надлежащее исполнение;

• требовать возмещения убытков.

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

Программная экспертиза позволяет разработчику:

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

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

• доказать отсутствие своей вины;

• обосновать размер вознаграждения.

10.3. Доказывание факта выполнения работ

Для доказывания факта выполнения работ необходимо установить:

• наличие результата;

• передачу результата;

• соответствие результата требованиям.

10.4. Доказывание отсутствия вины разработчика

Для доказывания отсутствия вины необходимо установить:

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

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

• добросовестность разработчика.

10.5. Доказывание необоснованности претензий заказчика

Для доказывания необоснованности претензий необходимо установить:

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

• отсутствие критических дефектов;

• субъективность претензий.

---

ГЛАВА 11. ТЕХНИЧЕСКИЕ АСПЕКТЫ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ

11.1. Анализ исходного кода

Анализ исходного кода — важнейший метод программной экспертизы. Он позволяет:

• выявить дефекты;

• оценить качество;

• установить авторство;

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

11.2. Анализ архитектуры программного продукта

Архитектура — основа программного продукта. Её анализ позволяет:

• оценить соответствие требованиям;

• выявить узкие места;

• оценить масштабируемость;

• оценить безопасность.

11.3. Тестирование программного продукта

Тестирование — основной метод проверки работоспособности. Виды тестирования:

• функциональное;

• интеграционное;

• системное;

• нагрузочное;

• стресс-тестирование.

11.4. Анализ документации

Документация — источник сведений о продукте. Её анализ позволяет:

• проверить полноту;

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

• проверить актуальность.

11.5. Анализ среды функционирования

Среда функционирования влияет на работоспособность. Её анализ позволяет:

• выявить несовместимости;

• оценить достаточность ресурсов;

• оценить безопасность.

---

ГЛАВА 12. ОРГАНИЗАЦИОННЫЕ АСПЕКТЫ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ

12.1. Организация проведения программной экспертизы

Организация включает:

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

• заключение договора;

• передачу объектов;

• планирование;

• контроль сроков.

12.2. Взаимодействие эксперта с участниками процесса

Эксперт взаимодействует:

• с судом;

• со сторонами;

• со специалистами;

• с третьими лицами.

12.3. Документирование программной экспертизы

Документирование включает:

• фиксацию объектов;

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

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

• оформление заключения.

12.4. Сроки проведения программной экспертизы

Сроки определяются:

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

• объёмом;

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

• загруженностью эксперта.

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

Стоимость определяется:

• трудоёмкостью;

• квалификацией эксперта;

• срочностью;

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

---

ГЛАВА 13. ЭТИЧЕСКИЕ АСПЕКТЫ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ

13.1. Независимость и беспристрастность эксперта

Независимость — ключевое требование. Эксперт не должен быть заинтересован в исходе дела.

13.2. Конфиденциальность

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

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

Ответственность — гарантия достоверности.

13.4. Этика взаимодействия с участниками процесса

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

13.5. Недопустимость конфликта интересов

Конфликт интересов недопустим. Эксперт должен заявить самоотвод.

---

ГЛАВА 14. ПРОБЛЕМЫ И ТРУДНОСТИ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ

14.1. Сложность объектов исследования

Программное обеспечение сложно, многогранно, изменчиво.

14.2. Недостаточность методического обеспечения

Отсутствуют единые методики.

14.3. Проблема разграничения ответственности

Сложно разграничить ответственность разработчика и заказчика.

14.4. Проблема фиксации объектов

Объекты изменчивы, их сложно зафиксировать.

14.5. Проблема оценки достоверности

Оценка достоверности субъективна.

---

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

15.1. Рекомендации заказчику

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

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

• проводить приёмку;

• привлекать экспертов.

15.2. Рекомендации разработчику

• документировать ход работ;

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

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

• сотрудничать с экспертом.

15.3. Рекомендации эксперту

• обеспечивать независимость;

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

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

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

15.4. Рекомендации суду

• чётко формулировать вопросы;

• выбирать квалифицированного эксперта;

• обеспечивать условия;

• оценивать заключение критически.

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

Вопросы должны быть:

• конкретными;

• однозначными;

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

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

---

ГЛАВА 16. ПРОГРАММНАЯ ЭКСПЕРТИЗА В КОНТЕКСТЕ ЦИФРОВОЙ ЭКОНОМИКИ

16.1. Роль программного обеспечения в современной экономике

Программное обеспечение — критический ресурс.

16.2. Государственная политика в сфере информационных технологий

Политика направлена на развитие, импортозамещение, безопасность.

16.3. Программная экспертиза как инструмент контроля качества

Экспертиза обеспечивает контроль.

16.4. Программная экспертиза и защита интеллектуальной собственности

Экспертиза защищает права.

16.5. Программная экспертиза и информационная безопасность

Экспертиза выявляет уязвимости.

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

ТРЕБОВАНИЯ К ЭКСПЕРТАМ, КОТОРЫЕ ВЫПОЛНЯЮТ ПРОГРАММНУЮ ЭКСПЕРТИЗУ

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

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

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

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

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

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

Квалификационные требования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к эксперту при досудебной экспертизе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стоимость. Соответствие стоимости рыночным ценам, обоснованность расценок.

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

Готовность к судебному оспариванию. Способность защитить свои выводы в суде.

Доступность. Возможность оперативной связи, готовность к консультациям.

Критерии выбора эксперта судом

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

Компетентность. Наличие специальных знаний, необходимых для разрешения вопросов.

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

Беспристрастность. Способность дать объективное заключение.

Опыт. Наличие опыта проведения аналогичных экспертиз.

Репутация. Положительная репутация в профессиональном сообществе.

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

Стоимость. Разумность стоимости экспертизы.

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

Согласие сторон. Мнение сторон учитывается при выборе эксперта.

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

Повышение квалификации экспертов

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

Формы повышения квалификации:

• обучение на курсах, семинарах, тренингах;

• участие в конференциях, форумах, симпозиумах;

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

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

• обмен опытом с коллегами;

• самообразование;

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

• публикация научных работ;

• преподавание;

• стажировки.

Направления повышения квалификации:

• новые языки программирования;

• новые технологии разработки;

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

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

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

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

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

• процессуальные аспекты.

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

Типичные ошибки экспертов и способы их предотвращения

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

Ошибки в методах. Применение неподходящих методов, некорректное применение, недостаточная обоснованность. Предотвращение: тщательный выбор методов, проверка их применимости, документирование.

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

Ошибки в оценке. Недооценка или переоценка сложности, неверная интерпретация данных. Предотвращение: коллегиальная проверка, консультации, повторный анализ.

Ошибки в оформлении. Несоответствие требованиям, неполнота, противоречия. Предотвращение: знание требований, проверка, редактирование.

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

Ошибки в сроках. Нарушение сроков, необоснованное продление. Предотвращение: реалистичное планирование, своевременное информирование, резерв времени.

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

---

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

Кейс 1. Государственный контракт на создание портала государственных услуг

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

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

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

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

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

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

Кейс 2. Муниципальный контракт на разработку мобильного приложения

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

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

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

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

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

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

Кейс 3. Корпоративный контракт на внедрение ERP-системы

Фабула. Крупное предприятие заключило договор с системным интегратором на внедрение ERP-системы. Стоимость — двести пятьдесят миллионов рублей. Срок — восемнадцать месяцев. После внедрения система работала нестабильно: периодические сбои, потеря данных, медленная работа, ошибки в финансовой отчётности. Заказчик потребовал устранения дефектов, интегратор настаивал на том, что система работоспособна, а проблемы вызваны некачественными данными заказчика.

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

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

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

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

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

Кейс 4. Спор о заимствовании кода

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

Задачи экспертизы. Установить, имеется ли заимствование кода; каков объём заимствования; является ли код оригинальным; нарушены ли права третьих лиц.

Методы. Сравнительный анализ кода; анализ метрик; анализ комментариев; анализ стиля; анализ истории репозитория; поиск в открытых источниках.

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

Выводы. Имеется заимствование кода в объёме около сорока процентов. Код не является полностью оригинальным. Права третьих лиц нарушены.

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

Кейс 5. Спор о причинах неисправности программного обеспечения

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

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

Методы. Анализ кода; анализ журналов; анализ конфигурации; моделирование ситуации; тестирование.

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

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

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

Кейс 6. Спор о соответствии программного продукта техническому заданию

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

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

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

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

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

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

Кейс 7. Спор о качестве документации

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

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

Методы. Анализ документации; сопоставление с продуктом; экспертная оценка.

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

Выводы. Документация не соответствует фактическому состоянию продукта. Она недостаточна для эксплуатации и сопровождения. Не содержит необходимых сведений.

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

Кейс 8. Спор об объёме и стоимости выполненных работ

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

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

Методы. Анализ кода; оценка трудозатрат; сравнительный анализ; экономическая оценка.

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

Выводы. Фактически выполнено около пятидесяти процентов работ. Рыночная стоимость выполненных работ — около сорока пяти процентов от суммы договора. Уплаченный аванс превышает стоимость выполненных работ.

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

Кейс 9. Спор о соблюдении требований информационной безопасности

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

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

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

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

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

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

Кейс 10. Спор о работоспособности программного обеспечения после обновления

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

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

Методы. Анализ журналов; анализ кода; анализ конфигурации; тестирование; моделирование.

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

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

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

---

СУДЕБНАЯ ИЛИ НЕЗАВИСИМАЯ ПРОГРАММНАЯ ЭКСПЕРТИЗА – ВСЕ ЗА И ПРОТИВ, ВСЕ ПЛЮСЫ И МИНУСЫ

Постановка проблемы выбора

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

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

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

Судебная программная экспертиза: преимущества

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

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

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

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

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

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

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

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

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

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

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

Судебная программная экспертиза: недостатки

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

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

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

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

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

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

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

Риск некачественного заключения. Судебный эксперт может допустить ошибки, применить неподходящие методы, сделать необоснованные выводы. Исправление требует дополнительной или повторной экспертизы, что снова требует времени и средств.

Ограниченность процессуальных возможностей. Сторона не может напрямую взаимодействовать с экспертом, задавать ему вопросы вне судебного заседания, предоставлять дополнительные материалы. Всё опосредовано судом.

Зависимость от суда. Суд может отказать в назначении экспертизы, если сочтёт, что вопросы не требуют специальных знаний или не имеют значения для дела. Это лишает сторону возможности получить экспертное заключение.

Независимая программная экспертиза: преимущества

Оперативность. Независимая программная экспертиза проводится по договору, без процессуальных формальностей. Сторона сама выбирает эксперта, согласует сроки, получает результат в удобное время. Это позволяет быстро оценить перспективы спора и подготовиться к судебному разбирательству.

Гибкость. Сторона может свободно формулировать вопросы, изменять их, добавлять новые, расширять или сужать предмет исследования. Эксперт может выходить за пределы первоначальных вопросов, если это необходимо для полного исследования.

Свобода выбора эксперта. Сторона выбирает эксперта по своему усмотрению, учитывая его квалификацию, опыт, специализацию, репутацию, стоимость, сроки. Она может привлечь узкого специалиста, который глубоко разбирается в конкретной технологии.

Контроль со стороны заказчика. Сторона может контролировать ход экспертизы, требовать промежуточных результатов, обсуждать методы, вносить коррективы. Это повышает удовлетворённость результатом.

Возможность конфиденциальности. Независимая экспертиза может проводиться конфиденциально, без раскрытия информации третьим лицам. Это важно, когда речь идёт о коммерческой тайне, персональных данных, государственной тайне.

Меньшая стоимость. Независимая экспертиза, как правило, дешевле судебной, поскольку отсутствуют процессуальные издержки, бюрократические расходы, оплата государственных пошлин. Сторона платит только за работу эксперта.

Возможность использования для претензионной работы. Результаты независимой экспертизы могут быть использованы для направления претензии, проведения переговоров, обоснования позиции. Это позволяет урегулировать спор без суда.

Возможность формирования доказательственной базы. Независимая экспертиза позволяет собрать доказательства, которые впоследствии могут быть представлены в суд. Она помогает определить предмет судебной экспертизы, сформулировать вопросы, подготовить материалы.

Отсутствие привязки к процессу. Независимая экспертиза не зависит от процессуальных сроков, действий суда, позиции других сторон. Она проводится тогда, когда это нужно заказчику.

Возможность рецензирования. Независимый эксперт может провести рецензию на заключение судебной экспертизы, выявить ошибки, противоречия, необоснованные выводы. Это оружие в руках стороны, оспаривающей судебную экспертизу.

Независимая программная экспертиза: недостатки

Отсутствие процессуального статуса. Заключение независимой программной экспертизы не является судебным доказательством. Оно представляется как письменное доказательство или иной документ, который суд оценивает критически. Суд не обязан принимать его выводы.

Критическое отношение суда. Суды нередко относятся к независимым экспертизам с недоверием, особенно если они проведены по заказу заинтересованной стороны. Считается, что эксперт мог быть ангажирован, что выводы односторонни, что исследование недостаточно глубоко. Это снижает доказательственную силу.

Отсутствие уголовной ответственности. Независимый эксперт не предупреждается об уголовной ответственности за дачу заведомо ложного заключения. Это снижает гарантии достоверности. Хотя эксперт несёт гражданско-правовую ответственность по договору, это менее серьёзный стимул.

Риск ангажированности. Независимый эксперт зависит от заказчика материально, связан с ним договором. Это создаёт риск того, что эксперт будет склонен делать выводы в пользу заказчика. Репутационные риски частично сдерживают эту тенденцию, но не устраняют её полностью.

Ограниченность материалов. Независимый эксперт получает только те материалы, которые предоставит заказчик. Если заказчик не имеет доступа к части материалов или не считает нужным их предоставить, эксперт не может провести полное исследование. У него нет полномочий требовать материалы у другой стороны.

Отсутствие возможности опроса сторон. Независимый эксперт не может допросить представителей другой стороны, получить от них объяснения, запросить документы. Это ограничивает возможности исследования.

Риск оспаривания. Заключение независимой экспертизы может быть оспорено другой стороной в суде. Суд может назначить судебную экспертизу, которая придёт к иным выводам. В этом случае расходы на независимую экспертизу окажутся напрасными.

Отсутствие обязательности. Заключение независимой экспертизы не обязательно для другой стороны, для суда, для третьих лиц. Оно носит рекомендательный характер.

Ограниченность использования в качестве доказательства. Суд может отказать в приобщении заключения независимой экспертизы к материалам дела, если сочтёт его недопустимым или неотносимым. Он может не придать ему доказательственного значения.

Риск некачественного заключения. Независимый эксперт может быть недостаточно квалифицирован, применить неподходящие методы, допустить ошибки. Заказчик несёт риск, выбирая эксперта.

Сравнительная таблица преимуществ и недостатков

Факторы, влияющие на выбор формы экспертизы

Выбор между судебной и независимой программной экспертизой определяется совокупностью факторов.

Стадия спора. На досудебной стадии предпочтительна независимая экспертиза, поскольку она позволяет быстро оценить перспективы, сформировать позицию, подготовить претензию. На судебной стадии предпочтительна судебная экспертиза, поскольку она имеет процессуальный статус.

Характер вопросов. Если вопросы требуют глубокого технического исследования, экспериментов, доступа к материалам другой стороны, предпочтительна судебная экспертиза. Если вопросы касаются оценки уже имеющихся материалов, достаточно независимой экспертизы.

Наличие материалов. Если сторона располагает полным доступом к материалам (код, документация, журналы, среда), независимая экспертиза может быть эффективной. Если материалы находятся у другой стороны или у третьих лиц, требуется судебная экспертиза, обладающая полномочиями запрашивать материалы.

Финансовые возможности. Судебная экспертиза дороже, но расходы могут быть возмещены. Независимая экспертиза дешевле, но расходы несёт заказчик.

Сроки. Если сроки критичны, предпочтительна независимая экспертиза. Если сроки не критичны, можно использовать судебную.

Стратегия стороны. Если сторона намерена урегулировать спор без суда, достаточно независимой экспертизы. Если сторона готовится к судебному разбирательству, необходима судебная экспертиза.

Сложность объекта. Для сложных объектов предпочтительна судебная экспертиза, обладающая большими возможностями. Для простых объектов достаточно независимой.

Конфиденциальность. Если требуется конфиденциальность, предпочтительна независимая экспертиза. Судебная экспертиза предполагает раскрытие информации.

Репутация эксперта. Если сторона может привлечь авторитетного эксперта, независимая экспертиза может быть убедительной. Если нет, предпочтительна судебная.

Позиция другой стороны. Если другая сторона настроена на сотрудничество, возможна независимая экспертиза по согласованию. Если другая сторона конфликтует, необходима судебная экспертиза.

Комбинированная стратегия

Оптимальной стратегией нередко является комбинирование независимой и судебной программной экспертизы.

Этап первый: независимая экспертиза. На досудебной стадии проводится независимая экспертиза. Она позволяет:

• оценить перспективы спора;

• выявить сильные и слабые стороны позиции;

• сформировать доказательственную базу;

• подготовить претензию;

• определить вопросы для судебной экспертизы;

• выбрать эксперта для судебной экспертизы;

• оценить стоимость и сроки.

Этап второй: претензионная работа. На основе результатов независимой экспертизы направляется претензия. Если контрагент готов урегулировать спор, дело завершается без суда.

Этап третий: судебная экспертиза. Если спор переходит в суд, назначается судебная экспертиза. Вопросы, сформулированные на основе независимой экспертизы, ставятся перед судебным экспертом. Результаты независимой экспертизы представляются в суд как доказательство.

Этап четвёртый: рецензирование. Если судебная экспертиза приходит к неблагоприятным выводам, проводится рецензирование. Рецензия выявляет ошибки, противоречия, необоснованные выводы. На её основе заявляется ходатайство о дополнительной или повторной экспертизе.

Этап пятый: дополнительные экспертизы. При необходимости назначаются дополнительные или повторные экспертизы. Комбинированная стратегия позволяет максимально использовать преимущества обеих форм и минимизировать недостатки.

Тактические соображения

Для заказчика. Заказчик, требующий признания контракта неисполненным, заинтересован в судебной экспертизе, поскольку она имеет процессуальный статус. Однако перед подачей иска целесообразно провести независимую экспертизу, чтобы убедиться в обоснованности требований. Если независимая экспертиза подтверждает позицию, можно подавать иск и ходатайствовать о назначении судебной экспертизы.

Для разработчика. Разработчик, оспаривающий претензии заказчика, заинтересован в независимой экспертизе, поскольку она позволяет быстро и недорого оценить ситуацию. Если независимая экспертиза подтверждает позицию разработчика, можно представить её заказчику и попытаться урегулировать спор. Если спор переходит в суд, разработчик может ходатайствовать о назначении судебной экспертизы или оспаривать выводы судебной экспертизы с помощью рецензии.

Для государственного заказчика. Государственный заказчик, расходующий бюджетные средства, заинтересован в судебной экспертизе, поскольку она обеспечивает процессуальный статус и возможность возмещения расходов. Однако проведение независимой экспертизы перед подачей иска позволяет обосновать требования и избежать неэффективного расходования средств.

Для муниципального заказчика. Муниципальный заказчик, ограниченный в средствах, может начать с независимой экспертизы, чтобы оценить перспективы, а затем, при необходимости, инициировать судебную.

Для коммерческого заказчика. Коммерческий заказчик, заинтересованный в скорости и конфиденциальности, может предпочесть независимую экспертизу, особенно если спор невелик по сумме. Для крупных споров целесообразна судебная экспертиза.

Риски и способы их минимизации

Риск некачественной независимой экспертизы. Минимизируется тщательным выбором эксперта, проверкой его квалификации, опыта, репутации, ознакомлением с образцами заключений.

Риск ангажированности. Минимизируется выбором эксперта, не связанного со сторонами, проверкой его независимости, привлечением нескольких экспертов, использованием рецензирования.

Риск оспаривания судебной экспертизы. Минимизируется участием в формулировании вопросов, предоставлением полных материалов, контролем за ходом экспертизы, своевременным заявлением ходатайств.

Риск затягивания сроков. Минимизируется своевременным заявлением ходатайств, предоставлением материалов, взаимодействием с экспертом, контролем сроков.

Риск необоснованных расходов. Минимизируется планированием бюджета, выбором оптимального соотношения цены и качества, использованием комбинированной стратегии.

Риск утраты доказательств. Минимизируется своевременной фиксацией объектов, созданием резервных копий, документированием.

Риск неблагоприятного исхода. Минимизируется тщательной подготовкой, привлечением квалифицированных юристов и экспертов, проработкой позиции, учётом всех обстоятельств.

Выводы по выбору формы экспертизы

Судебная и независимая программная экспертиза не являются взаимоисключающими. Они дополняют друг друга. Оптимальная стратегия предполагает комбинирование: независимая экспертиза на досудебной стадии, судебная — на судебной. Это позволяет использовать преимущества обеих форм и минимизировать недостатки.

Выбор конкретной формы определяется стадией спора, характером вопросов, наличием материалов, финансовыми возможностями, сроками, стратегией стороны, сложностью объекта, требованиями конфиденциальности, репутацией эксперта, позицией другой стороны.

Независимая программная экспертиза целесообразна, когда:

• спор находится на досудебной стадии;

• требуется оперативность;

• материалы доступны;

• финансовые ресурсы ограничены;

• важна конфиденциальность;

• необходимо сформировать доказательственную базу;

• стороны настроены на урегулирование.

Судебная программная экспертиза целесообразна, когда:

• спор перешёл в суд;

• требуется процессуальный статус доказательства;

• материалы находятся у другой стороны;

• необходимы полномочия по запросу материалов;

• финансовые ресурсы позволяют нести расходы;

• требуется обязательность выводов;

• стороны конфликтуют.

В конечном счёте выбор определяется конкретными обстоятельствами дела. Квалифицированный юрист, знакомый с практикой программной экспертизы, поможет выбрать оптимальную стратегию и минимизировать риски.

---

ПРИМЕРЫ ВОПРОСОВ, КОТОРЫЕ АРБИТРАЖНЫЙ СУД ИЛИ ЗАКАЗЧИК ЭКСПЕРТИЗЫ МОЖЕТ ЗАДАВАТЬ ЭКСПЕРТАМ ПРИ НАЗНАЧЕНИИ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ

Вопросы о факте создания программного продукта

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. Выполняет ли программный продукт все функции, заявленные в техническом задании?

28. Выполняет ли программный продукт функции, предусмотренные документацией?

29. Соответствует ли производительность программного продукта требованиям технического задания?

30. Соответствует ли время отклика программного продукта требованиям технического задания?

31. Выдерживает ли программный продукт расчётную нагрузку, предусмотренную техническим заданием?

32. Обеспечивает ли программный продукт сохранность и целостность обрабатываемых данных?

33. Обеспечивает ли программный продукт корректную работу с базами данных?

34. Обеспечивает ли программный продукт корректную работу с внешними системами и интеграциями?

35. Имеются ли в программном продукте функции, которые не работают или работают некорректно?

36. Имеются ли в программном продукте функции, которые работают нестабильно, с периодическими сбоями?

37. Возможно ли использование программного продукта в режиме, предусмотренном техническим заданием, без возникновения ошибок?

38. Возможно ли использование программного продукта несколькими пользователями одновременно без возникновения конфликтов?

39. Обеспечивает ли программный продукт корректную работу при различных конфигурациях среды функционирования?

40. Обеспечивает ли программный продукт корректную работу на различных версиях операционной системы, предусмотренных техническим заданием?

Вопросы о дефектах программного продукта

41. Имеются ли в программном продукте дефекты?

42. Какие именно дефекты имеются в программном продукте?

43. Являются ли выявленные дефекты критическими, то есть препятствующими использованию программного продукта по назначению?

44. Являются ли выявленные дефекты существенными, то есть влияющими на функциональность, но не препятствующими использованию?

45. Являются ли выявленные дефекты несущественными, то есть не влияющими на функциональность?

46. Каково количество выявленных дефектов?

47. Какова степень критичности каждого выявленного дефекта?

48. Возможно ли использование программного продукта при наличии выявленных дефектов?

49. Возможно ли использование программного продукта при наличии выявленных дефектов без риска потери данных?

50. Возможно ли использование программного продукта при наличии выявленных дефектов без риска нарушения безопасности?

51. Возможно ли устранение выявленных дефектов силами разработчика?

52. Какова ориентировочная трудоёмкость устранения выявленных дефектов?

53. Какова ориентировочная стоимость устранения выявленных дефектов?

54. Какова ориентировочная длительность устранения выявленных дефектов?

55. Возможно ли устранение выявленных дефектов без нарушения целостности программного продукта?

Вопросы о причинах неисправностей программного продукта

56. Какова причина неисправности программного продукта?

57. Является ли неисправность следствием ошибок, допущенных разработчиком при создании программного продукта?

58. Является ли неисправность следствием ошибок, допущенных заказчиком при эксплуатации программного продукта?

59. Является ли неисправность следствием некорректной настройки программного продукта?

60. Является ли неисправность следствием несовместимости программного продукта с другими программными средствами?

61. Является ли неисправность следствием несовместимости программного продукта с аппаратным обеспечением?

62. Является ли неисправность следствием внешнего воздействия, в том числе вредоносного?

63. Является ли неисправность следствием обстоятельств непреодолимой силы?

64. Могла ли неисправность возникнуть при соблюдении всех требований технического задания и рекомендаций разработчика?

65. Могла ли неисправность возникнуть при соблюдении всех правил эксплуатации, установленных разработчиком?

66. Имеется ли причинно-следственная связь между действиями разработчика и возникшей неисправностью?

67. Имеется ли причинно-следственная связь между действиями заказчика и возникшей неисправностью?

68. Имеется ли причинно-следственная связь между действиями третьих лиц и возникшей неисправностью?

69. Является ли неисправность единственной или имеются несколько независимых причин?

70. Является ли неисправность устранимой, и если да, то каким образом?

Вопросы о причинах возникновения дефектов

71. Какова причина возникновения каждого выявленного дефекта?

72. Связан ли дефект с ошибкой в исходном коде?

73. Связан ли дефект с ошибкой в проектировании архитектуры?

74. Связан ли дефект с ошибкой в проектировании базы данных?

75. Связан ли дефект с ошибкой в реализации интерфейсов?

76. Связан ли дефект с ошибкой в обработке исключительных ситуаций?

77. Связан ли дефект с отсутствием валидации входных данных?

78. Связан ли дефект с некорректной работой с памятью?

79. Связан ли дефект с некорректной работой с ресурсами?

80. Связан ли дефект с некорректной работой с сетевыми соединениями?

81. Связан ли дефект с использованием устаревших или несовместимых библиотек?

82. Связан ли дефект с нарушением стандартов разработки?

83. Связан ли дефект с недостаточным тестированием?

84. Связан ли дефект с недостаточной документированностью?

85. Мог ли дефект быть выявлен при надлежащем тестировании?

Вопросы о качестве исходного кода

86. Соответствует ли исходный код программного продукта требованиям, предъявляемым к качеству кода?

87. Соответствует ли исходный код стандартам оформления, принятым в разработке?

88. Имеются ли в исходном коде нарушения структурной целостности?

89. Имеются ли в исходном коде признаки дублирования?

90. Имеются ли в исходном коде признаки избыточности?

91. Имеются ли в исходном коде «мёртвые» участки, не используемые при выполнении?

92. Какова цикломатическая сложность исходного кода?

93. Какова связанность модулей исходного кода?

94. Каково сцепление модулей исходного кода?

95. Соответствует ли читаемость исходного кода требованиям, предъявляемым к сопровождаемому коду?

96. Имеются ли в исходном коде комментарии, соответствующие фактическому содержанию кода?

97. Имеются ли в исходном коде признаки копирования из сторонних источников?

98. Имеются ли в исходном коде признаки использования сгенерированного кода?

99. Имеются ли в исходном коде признаки использования обфускации?

100. Возможно ли сопровождение исходного кода силами сторонних специалистов?

Вопросы о качестве документации

101. Соответствует ли документация программного продукта фактическому состоянию продукта?

102. Является ли документация полной?

103. Является ли документация корректной?

104. Является ли документация актуальной?

105. Содержит ли документация описание всех функций программного продукта?

106. Содержит ли документация описание всех интерфейсов программного продукта?

107. Содержит ли документация описание всех настроек программного продукта?

108. Содержит ли документация описание требований к среде функционирования?

109. Содержит ли документация описание порядка развёртывания?

110. Содержит ли документация описание порядка резервного копирования и восстановления?

111. Содержит ли документация описание порядка мониторинга?

112. Содержит ли документация описание порядка устранения неисправностей?

113. Содержит ли документация описание мер по обеспечению безопасности?

114. Достаточна ли документация для эксплуатации программного продукта?

115. Достаточна ли документация для сопровождения программного продукта?

Вопросы об архитектуре программного продукта

116. Соответствует ли архитектура программного продукта требованиям технического задания?

117. Соответствует ли архитектура программного продукта проектной документации?

118. Является ли архитектура программного продукта монолитной или модульной?

119. Обеспечивает ли архитектура программного продукта возможность масштабирования?

120. Обеспечивает ли архитектура программного продукта возможность горизонтального масштабирования?

121. Обеспечивает ли архитектура программного продукта возможность вертикального масштабирования?

122. Обеспечивает ли архитектура программного продукта отказоустойчивость?

123. Обеспечивает ли архитектура программного продукта возможность резервного копирования?

124. Обеспечивает ли архитектура программного продукта возможность восстановления?

125. Обеспечивает ли архитектура программного продукта возможность интеграции с внешними системами?

126. Обеспечивает ли архитектура программного продукта возможность расширения функциональности?

127. Имеются ли в архитектуре программного продукта единые точки отказа?

128. Имеются ли в архитектуре программного продукта узкие места?

129. Имеются ли в архитектуре программного продукта избыточные компоненты?

130. Соответствует ли архитектура программного продукта современным требованиям к аналогичным системам?

Вопросы о производительности программного продукта

131. Соответствует ли производительность программного продукта требованиям технического задания?

132. Соответствует ли время отклика программного продукта требованиям технического задания?

133. Соответствует ли пропускная способность программного продукта требованиям технического задания?

134. Выдерживает ли программный продукт расчётную нагрузку?

135. Выдерживает ли программный продукт пиковую нагрузку?

136. Выдерживает ли программный продукт нагрузку, превышающую расчётную?

137. Имеются ли в программном продукте узкие места, ограничивающие производительность?

138. Имеются ли в программном продукте неоптимальные запросы к базе данных?

139. Имеются ли в программном продукте неоптимальные алгоритмы?

140. Имеются ли в программном продукте избыточные вычисления?

141. Имеются ли в программном продукте проблемы с кэшированием?

142. Имеются ли в программном продукте проблемы с управлением памятью?

143. Имеются ли в программном продукте проблемы с управлением ресурсами?

144. Соответствует ли производительность программного продукта производительности аналогичных продуктов?

145. Возможно ли повышение производительности программного продукта без существенной переработки?

Вопросы о безопасности программного продукта

146. Соответствует ли программный продукт требованиям информационной безопасности, предусмотренным техническим заданием?

147. Имеются ли в программном продукте уязвимости?

148. Какие именно уязвимости имеются в программном продукте?

149. Являются ли выявленные уязвимости критическими?

150. Возможно ли использование выявленных уязвимостей для несанкционированного доступа?

151. Возможно ли использование выявленных уязвимостей для несанкционированного изменения данных?

152. Возможно ли использование выявленных уязвимостей для несанкционированного удаления данных?

153. Возможно ли использование выявленных уязвимостей для нарушения работоспособности?

154. Обеспечивает ли программный продукт защиту от SQL-инъекций?

155. Обеспечивает ли программный продукт защиту от межсайтового скриптинга?

156. Обеспечивает ли программный продукт защиту от подделки межсайтовых запросов?

157. Обеспечивает ли программный продукт защиту от несанкционированного доступа?

158. Обеспечивает ли программный продукт разграничение прав доступа?

159. Обеспечивает ли программный продукт шифрование чувствительных данных?

160. Обеспечивает ли программный продукт журналирование действий пользователей?

Вопросы о защите персональных данных

161. Соответствует ли программный продукт требованиям законодательства о персональных данных?

162. Обрабатывает ли программный продукт персональные данные?

163. Какие категории персональных данных обрабатываются?

164. Обеспечивает ли программный продукт согласие субъектов на обработку персональных данных?

165. Обеспечивает ли программный продукт возможность отзыва согласия?

166. Обеспечивает ли программный продукт возможность уничтожения персональных данных?

167. Обеспечивает ли программный продукт хранение персональных данных на территории Российской Федерации?

168. Обеспечивает ли программный продукт защиту персональных данных при передаче?

169. Обеспечивает ли программный продукт защиту персональных данных при хранении?

170. Обеспечивает ли программный продукт разграничение доступа к персональным данным?

Вопросы об объёме и стоимости выполненных работ

171. Какие работы фактически выполнены разработчиком?

172. Каков объём фактически выполненных работ?

173. Соответствует ли объём фактически выполненных работ объёму, предусмотренному договором?

174. Какова рыночная стоимость фактически выполненных работ?

175. Соответствует ли стоимость фактически выполненных работ сумме, уплаченной заказчиком?

176. Имеется ли неосновательное обогащение на стороне разработчика?

177. Имеется ли неосновательное обогащение на стороне заказчика?

178. Какова стоимость работ, которые остались невыполненными?

179. Какова стоимость работ, которые выполнены с ненадлежащим качеством?

180. Какова стоимость работ по устранению выявленных дефектов?

Вопросы о соблюдении технологических процессов

181. Соблюдались ли разработчиком стандарты разработки программного обеспечения?

182. Соблюдались ли разработчиком методологии управления проектами?

183. Проводилось ли разработчиком тестирование программного продукта?

184. Каков объём проведённого тестирования?

185. Соответствует ли объём тестирования требованиям технического задания?

186. Вёлся ли разработчиком версионный контроль исходного кода?

187. Вёлся ли разработчиком учёт дефектов?

188. Вёлся ли разработчиком учёт изменений требований?

189. Проводилось ли разработчиком документирование хода работ?

190. Проводилось ли разработчиком рецензирование кода?

191. Проводилось ли разработчиком автоматизированное тестирование?

192. Проводилось ли разработчиком нагрузочное тестирование?

193. Проводилось ли разработчиком тестирование безопасности?

194. Проводилось ли разработчиком приёмочное тестирование?

195. Соблюдались ли разработчиком сроки, предусмотренные договором?

Вопросы о соблюдении требований контрактной системы

196. Соответствует ли программный продукт требованиям государственного или муниципального контракта?

197. Соответствует ли программный продукт требованиям технического задания, являющегося приложением к контракту?

198. Соответствует ли программный продукт требованиям к качеству, установленным контрактом?

199. Соответствует ли программный продукт требованиям к гарантийным обязательствам, установленным контрактом?

200. Соответствует ли программный продукт требованиям к сопровождению, установленным контрактом?

201. Соответствует ли программный продукт требованиям к передаче прав, установленным контрактом?

202. Соответствует ли программный продукт требованиям к передаче документации, установленным контрактом?

203. Соответствует ли программный продукт требованиям к обучению пользователей, установленным контрактом?

204. Соответствует ли программный продукт требованиям к вводу в эксплуатацию, установленным контрактом?

205. Соответствует ли программный продукт требованиям к импортозамещению, установленным контрактом?

Вопросы о пригодности программного продукта к использованию

206. Пригоден ли программный продукт для использования по назначению?

207. Пригоден ли программный продукт для использования в предусмотренной среде?

208. Пригоден ли программный продукт для использования предусмотренным кругом пользователей?

209. Пригоден ли программный продукт для использования с предусмотренными данными?

210. Пригоден ли программный продукт для использования с предусмотренной нагрузкой?

211. Пригоден ли программный продукт для использования без дополнительной доработки?

212. Пригоден ли программный продукт для использования без дополнительного обучения пользователей?

213. Пригоден ли программный продукт для использования без дополнительной настройки?

214. Пригоден ли программный продукт для использования в течение предусмотренного срока?

215. Пригоден ли программный продукт для использования с учётом выявленных дефектов?

Вопросы о возможности устранения выявленных недостатков

216. Возможно ли устранение выявленных недостатков?

217. Какие недостатки возможно устранить?

218. Какие недостатки невозможно устранить?

219. Какова трудоёмкость устранения выявленных недостатков?

220. Какова стоимость устранения выявленных недостатков?

221. Какова длительность устранения выявленных недостатков?

222. Возможно ли устранение недостатков силами разработчика?

223. Возможно ли устранение недостатков силами третьих лиц?

224. Возможно ли устранение недостатков без нарушения целостности программного продукта?

225. Возможно ли устранение недостатков без нарушения сроков, предусмотренных договором?

Вопросы о разграничении ответственности

226. Имеется ли вина разработчика в возникновении выявленных недостатков?

227. Имеется ли вина заказчика в возникновении выявленных недостатков?

228. Имеется ли вина третьих лиц в возникновении выявленных недостатков?

229. Имеется ли вина обеих сторон в возникновении выявленных недостатков?

230. Какова степень вины каждой стороны?

231. Мог ли разработчик предотвратить возникновение недостатков?

232. Мог ли заказчик предотвратить возникновение недостатков?

233. Действовал ли разработчик добросовестно?

234. Действовал ли заказчик добросовестно?

235. Имеются ли обстоятельства, освобождающие стороны от ответственности?

Вопросы о соответствии программного продукта требованиям импортозамещения

236. Соответствует ли программный продукт требованиям импортозамещения?

237. Использованы ли в программном продукте иностранные компоненты?

238. Какие именно иностранные компоненты использованы?

239. Возможно ли замена иностранных компонентов на отечественные аналоги?

240. Какова трудоёмкость замены иностранных компонентов?

241. Какова стоимость замены иностранных компонентов?

242. Соответствует ли программный продукт требованиям реестра отечественного программного обеспечения?

243. Возможно ли включение программного продукта в реестр отечественного программного обеспечения?

244. Имеются ли в программном продукте компоненты с лицензиями, не допускающими коммерческое использование?

245. Имеются ли в программном продукте компоненты с лицензиями, требующими раскрытия исходного кода?

Вопросы о соответствии программного продукта требованиям доступности

246. Соответствует ли программный продукт требованиям доступности для инвалидов?

247. Обеспечивает ли программный продукт возможность использования лицами с нарушениями зрения?

248. Обеспечивает ли программный продукт возможность использования лицами с нарушениями слуха?

249. Обеспечивает ли программный продукт возможность использования лицами с нарушениями опорно-двигательного аппарата?

250. Соответствует ли программный продукт требованиям к альтернативному тексту для изображений?

251. Соответствует ли программный продукт требованиям к контрастности?

252. Соответствует ли программный продукт требованиям к навигации с клавиатуры?

253. Соответствует ли программный продукт требованиям к семантической разметке?

254. Соответствует ли программный продукт требованиям к масштабируемости шрифтов?

255. Соответствует ли программный продукт требованиям к озвучиванию элементов?

Вопросы о соответствии программного продукта требованиям по защите детей

256. Соответствует ли программный продукт требованиям по защите детей?

257. Собирает ли программный продукт избыточные данные о детях?

258. Содержит ли программный продукт рекламу, не соответствующую возрасту?

259. Содержит ли программный продукт контент, не соответствующий возрасту?

260. Обеспечивает ли программный продукт родительский контроль?

261. Обеспечивает ли программный продукт защиту от нежелательных контактов?

262. Обеспечивает ли программный продукт защиту от вредоносного контента?

263. Соответствует ли программный продукт требованиям к обработке данных детей?

264. Соответствует ли программный продукт требованиям к согласию родителей?

265. Соответствует ли программный продукт требованиям к удалению данных детей?

Вопросы о соответствии программного продукта требованиям по хранению данных

266. Соответствует ли программный продукт требованиям по хранению данных на территории Российской Федерации?

267. Хранятся ли данные, обрабатываемые программным продуктом, на территории Российской Федерации?

268. Передаются ли данные, обрабатываемые программным продуктом, за пределы Российской Федерации?

269. Использует ли программный продукт облачные сервисы иностранных провайдеров?

270. Использует ли программный продукт серверы, расположенные за пределами Российской Федерации?

271. Возможно ли перенесение данных на серверы, расположенные на территории Российской Федерации?

272. Какова трудоёмкость перенесения данных?

273. Какова стоимость перенесения данных?

274. Соответствует ли программный продукт требованиям к резервному копированию данных?

275. Соответствует ли программный продукт требованиям к уничтожению данных?

Вопросы о соответствии программного продукта требованиям по лицензированию

276. Соответствует ли использование компонентов программного продукта условиям их лицензий?

277. Какие лицензии использованы в программном продукте?

278. Имеются ли в программном продукте компоненты с лицензиями, требующими раскрытия исходного кода?

279. Имеются ли в программном продукте компоненты с лицензиями, не допускающими коммерческое использование?

280. Имеются ли в программном продукте компоненты с лицензиями, не допускающими распространение?

281. Переданы ли заказчику лицензии на использование компонентов?

282. Имеются ли у заказчика права на использование всех компонентов?

283. Имеются ли риски нарушения лицензий?

284. Возможно ли замена компонентов с проблемными лицензиями?

285. Какова трудоёмкость замены компонентов?

Вопросы о соответствии программного продукта требованиям по сопровождению

286. Соответствует ли программный продукт требованиям по сопровождению, предусмотренным договором?

287. Осуществляется ли сопровождение программного продукта?

288. Каков объём сопровождения?

289. Соответствует ли объём сопровождения требованиям договора?

290. Имеются ли у разработчика обязательства по сопровождению?

291. Имеются ли у разработчика ресурсы для сопровождения?

292. Имеются ли у разработчика специалисты для сопровождения?

293. Имеется ли у разработчика документация для сопровождения?

294. Имеется ли у разработчика доступ к исходному коду для сопровождения?

295. Возможно ли сопровождение программного продукта силами третьих лиц?

Вопросы о соответствии программного продукта требованиям по обучению пользователей

296. Соответствует ли программный продукт требованиям по обучению пользователей?

297. Проводилось ли обучение пользователей?

298. Каков объём обучения?

299. Соответствует ли объём обучения требованиям договора?

300. Имеются ли материалы для обучения пользователей?

301. Соответствуют ли материалы для обучения требованиям?

302. Достаточны ли материалы для обучения?

303. Возможно ли обучение пользователей силами заказчика?

304. Возможно ли обучение пользователей силами третьих лиц?

305. Имеются ли у заказчика ресурсы для обучения пользователей?

Вопросы о соответствии программного продукта требованиям по вводу в эксплуатацию

306. Соответствует ли программный продукт требованиям по вводу в эксплуатацию?

307. Проводился ли ввод в эксплуатацию?

308. Соответствует ли ввод в эксплуатацию требованиям договора?

309. Имеются ли документы о вводе в эксплуатацию?

310. Соответствуют ли документы о вводе в эксплуатацию требованиям?

311. Имеются ли у заказчика ресурсы для ввода в эксплуатацию?

312. Имеются ли у заказчика специалисты для ввода в эксплуатацию?

313. Имеется ли у заказчика инфраструктура для ввода в эксплуатацию?

314. Возможен ли ввод в эксплуатацию силами заказчика?

315. Возможен ли ввод в эксплуатацию силами третьих лиц?

Вопросы о соответствии программного продукта требованиям по гарантийным обязательствам

316. Соответствует ли программный продукт требованиям по гарантийным обязательствам?

317. Имеются ли гарантийные обязательства разработчика?

318. Каков срок гарантийных обязательств?

319. Соответствует ли срок гарантийных обязательств требованиям договора?

320. Имеются ли случаи обращения за гарантийным обслуживанием?

321. Соответствуют ли действия разработчика по гарантийному обслуживанию требованиям договора?

322. Имеются ли у разработчика обязательства по устранению дефектов в гарантийный период?

323. Исполняются ли обязательства по устранению дефектов?

324. Имеются ли основания для отказа от гарантийного обслуживания?

325. Имеются ли основания для продления гарантийного периода?

Вопросы о соответствии программного продукта требованиям по передаче прав

326. Соответствует ли передача прав на программный продукт требованиям договора?

327. Переданы ли заказчику исключительные права на программный продукт?

328. Переданы ли заказчику права на использование программного продукта?

329. Соответствует ли объём переданных прав требованиям договора?

330. Имеются ли у разработчика обязательства по передаче прав?

331. Исполнены ли обязательства по передаче прав?

332. Имеются ли у заказчика документы, подтверждающие передачу прав?

333. Имеются ли у заказчика права на модификацию программного продукта?

334. Имеются ли у заказчика права на распространение программного продукта?

335. Имеются ли у заказчика права на сублицензирование программного продукта?

Вопросы о соответствии программного продукта требованиям по передаче документации

336. Соответствует ли передача документации требованиям договора?

337. Передана ли заказчику документация?

338. Соответствует ли объём переданной документации требованиям договора?

339. Соответствует ли качество переданной документации требованиям договора?

340. Имеются ли у заказчика документы, подтверждающие передачу документации?

341. Имеются ли у заказчика замечания к переданной документации?

342. Соответствуют ли замечания заказчика требованиям договора?

343. Имеются ли у разработчика обязательства по доработке документации?

344. Исполнены ли обязательства по доработке документации?

345. Возможно ли использование программного продукта без переданной документации?

Вопросы о соответствии программного продукта требованиям по качеству

346. Соответствует ли качество программного продукта требованиям договора?

347. Соответствует ли качество программного продукта требованиям технического задания?

348. Соответствует ли качество программного продукта требованиям стандартов?

349. Соответствует ли качество программного продукта требованиям, предъявляемым к аналогичным продуктам?

350. Имеются ли у заказчика замечания к качеству программного продукта?

351. Соответствуют ли замечания заказчика требованиям договора?

352. Имеются ли у разработчика обязательства по повышению качества?

353. Исполнены ли обязательства по повышению качества?

354. Возможно ли использование программного продукта при имеющемся качестве?

355. Возможно ли повышение качества без существенной переработки?

Вопросы о соответствии программного продукта требованиям по срокам

356. Соответствуют ли сроки выполнения работ требованиям договора?

357. Соблюдены ли сроки начала работ?

358. Соблюдены ли сроки окончания работ?

359. Соблюдены ли промежуточные сроки?

360. Имеются ли нарушения сроков?

361. Каковы причины нарушения сроков?

362. Связаны ли нарушения сроков с действиями разработчика?

363. Связаны ли нарушения сроков с действиями заказчика?

364. Связаны ли нарушения сроков с действиями третьих лиц?

365. Имеются ли основания для освобождения от ответственности за нарушение сроков?

Вопросы о соответствии программного продукта требованиям по стоимости

366. Соответствует ли стоимость работ требованиям договора?

367. Соответствует ли стоимость работ рыночной стоимости?

368. Имеется ли завышение стоимости работ?

369. Имеется ли занижение стоимости работ?

370. Соответствует ли стоимость работ объёму выполненных работ?

371. Имеются ли основания для изменения стоимости работ?

372. Имеются ли основания для перерасчёта стоимости работ?

373. Имеются ли основания для возврата части уплаченных средств?

374. Имеются ли основания для доплаты за выполненные работы?

375. Имеются ли основания для взыскания неосновательного обогащения?

Вопросы о соответствии программного продукта требованиям по ответственности

376. Имеются ли основания для привлечения разработчика к ответственности?

377. Имеются ли основания для привлечения заказчика к ответственности?

378. Имеются ли основания для взыскания штрафа?

379. Имеются ли основания для взыскания пеней?

380. Имеются ли основания для взыскания убытков?

381. Имеются ли основания для расторжения договора?

382. Имеются ли основания для отказа от исполнения договора?

383. Имеются ли основания для одностороннего расторжения договора?

384. Имеются ли основания для включения разработчика в реестр недобросовестных поставщиков?

385. Имеются ли основания для освобождения от ответственности?

Вопросы о соответствии программного продукта требованиям по урегулированию споров

386. Имеются ли основания для досудебного урегулирования спора?

387. Имеются ли основания для проведения переговоров?

388. Имеются ли основания для заключения мирового соглашения?

389. Имеются ли основания для проведения медиации?

390. Имеются ли основания для обращения в третейский суд?

391. Имеются ли основания для обращения в арбитражный суд?

392. Имеются ли основания для обращения в суд общей юрисдикции?

393. Имеются ли основания для обращения в государственные органы?

394. Имеются ли основания для обращения в правоохранительные органы?

395. Имеются ли основания для обращения в международные инстанции?

Вопросы о соответствии программного продукта требованиям по дальнейшему использованию

396. Возможно ли дальнейшее использование программного продукта?

397. Возможно ли дальнейшее использование программного продукта без разработчика?

398. Возможно ли дальнейшее использование программного продукта с другим разработчиком?

399. Возможно ли дальнейшее развитие программного продукта?

400. Возможно ли дальнейшее сопровождение программного продукта?

401. Возможно ли дальнейшее масштабирование программного продукта?

402. Возможно ли дальнейшее расширение функциональности?

403. Возможно ли дальнейшее повышение производительности?

404. Возможно ли дальнейшее повышение безопасности?

405. Возможно ли дальнейшее использование программного продукта после устранения выявленных недостатков?

---

ПРАКТИЧЕСКИЕ ПРИМЕРЫ СЛОЖНОСТЕЙ ВЫПОЛНЕНИЯ ПРОГРАММНОЙ ЭКСПЕРТИЗЫ

Инструментальные сложности

Пример 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. Противодействие заказчика. Заказчик, опасаясь, что экспертиза выявит его собственную вину в неисправностях, пытался ограничить доступ эксперта к среде функционирования, скрыть журналы, исказить информацию. Эксперт столкнулся с неполнотой данных.

Пример 28. Конфликт между сторонами. Стороны находились в остром конфликте, отказывались от сотрудничества, обменивались взаимными обвинениями. Эксперт оказался втянутым в конфликт, вынужден был лавировать, что затруднило работу.

Пример 29. Давление на эксперта. Представители разработчика оказывали на эксперта неформальное давление: предлагали вознаграждение за «правильные» выводы, угрожали судебным преследованием, пытались дискредитировать. Эксперт был вынужден заявить о давлении и просить защиты.

Пример 30. Публичная критика эксперта. После представления заключения разработчик организовал публичную кампанию против эксперта: публикации в СМИ, обращения в профессиональные сообщества, жалобы в квалификационные комиссии. Эксперт понёс репутационные потери.

Пример 31. Конфликт интересов. Выяснилось, что эксперт ранее работал в организации, связанной с разработчиком. Сторона заявила отвод. Эксперт не сообщил о конфликте интересов своевременно, что подорвало доверие к его заключению.

Пример 32. Разногласия внутри комиссии экспертов. Комиссия экспертов не смогла прийти к единому мнению. Часть экспертов настаивала на одних выводах, часть — на других. Пришлось оформлять особое мнение, что снизило убедительность заключения.

Пример 33. Несогласие эксперта с вопросами. Эксперт счёл часть вопросов выходящими за пределы его компетенции и отказался на них отвечать. Сторона, инициировавшая экспертизу, восприняла это как уклонение от ответа, что вызвало конфликт.

Пример 34. Обвинение в ангажированности. Заказчик обвинил эксперта в ангажированности в пользу разработчика, ссылаясь на то, что эксперт ранее участвовал в проектах разработчика. Эксперт отрицал ангажированность, но обвинение подорвало доверие к заключению.

Пример 35. Отказ от оплаты. Заказчик отказался оплатить работу эксперта, сославшись на неудовлетворительное качество заключения. Эксперт был вынужден взыскивать оплату через суд, что потребовало дополнительных затрат.

Пример 36. Угрозы в адрес эксперта. Разработчик, недовольный выводами эксперта, направил в его адрес угрозы. Эксперт был вынужден обратиться в правоохранительные органы, что отвлекло его от работы.

Пример 37. Конфликт с судом. Эксперт не согласился с действиями суда, ограничившего его доступ к материалам. Конфликт с судом затруднил работу, потребовал обжалования действий суда.

Пример 38. Конфликт с представителями сторон. Представители сторон вели себя агрессивно, перебивали эксперта, оскорбляли его. Эксперт был вынужден прервать судебное заседание, что затянуло процесс.

Пример 39. Разногласия с заказчиком. Заказчик настаивал на определённых выводах, эксперт не мог их подтвердить. Разногласия привели к конфликту, заказчик отказался принимать заключение.

Пример 40. Проблемы с третьими лицами. Третьи лица, чьи интересы затрагивались экспертизой, пытались влиять на эксперта, предоставляли недостоверную информацию, оспаривали его выводы.

Финансовые сложности

Пример 41. Недостаточность бюджетных средств. Государственный заказчик не предусмотрел в бюджете расходы на программную экспертизу. При необходимости проведения экспертизы средства пришлось изыскивать дополнительно, что затянуло процесс.

Пример 42. Отказ от авансирования. Экспертная организация отказалась начинать работу без аванса. Заказчик не имел средств для аванса. Экспертиза не была начата, сроки нарушены.

Пример 43. Завышение стоимости. Экспертная организация завысила стоимость экспертизы. Заказчик не мог оплатить. Пришлось искать другого эксперта, что увеличило сроки.

Пример 44. Непредвиденные расходы. В ходе экспертизы выяснилась необходимость дополнительных исследований, не предусмотренных первоначальным договором. Стоимость экспертизы возросла, что потребовало согласования дополнительного финансирования.

Пример 45. Отсутствие финансирования у стороны. Сторона, заявившая ходатайство о назначении экспертизы, не имела средств для оплаты. Суд был вынужден отложить рассмотрение дела, что затянуло процесс.

Пример 46. Невозмещение расходов. Сторона, выигравшая дело, не смогла возместить расходы на экспертизу с проигравшей стороны из-за отсутствия у неё средств. Расходы остались некомпенсированными.

Пример 47. Спор о стоимости. Стороны спорили о разумности стоимости экспертизы. Суд был вынужден назначать судебную финансовую экспертизу для оценки разумности расходов, что увеличило сроки и расходы.

Пример 48. Бюджетные ограничения. Государственный заказчик не мог оплатить экспертизу из-за ограничений бюджетного финансирования. Пришлось переносить сроки, искать альтернативные источники.

Пример 49. Изменение стоимости в ходе экспертизы. Стоимость экспертизы возросла в ходе работы из-за изменения объёма задач. Заказчик отказался оплачивать дополнительные расходы. Возник спор, потребовавший судебного разрешения.

Пример 50. Неоплата государственной пошлины. Сторона не оплатила государственную пошлину, что привело к оставлению иска без движения. Экспертиза не была назначена в срок.

Пример 51. Отсутствие средств на повторную экспертизу. После неудовлетворительного заключения первоначальной экспертизы у стороны не оказалось средств на повторную экспертизу. Дело было разрешено на основе имеющихся доказательств.

Пример 52. Проблемы с распределением расходов. Суд распределил расходы на экспертизу между сторонами, но одна из сторон отказалась их возмещать. Потребовалось исполнительное производство.

Пример 53. Двойные расходы. Из-за ошибок первоначальной экспертизы потребовалась повторная, что привело к двойным расходам. Стороны понесли дополнительные финансовые потери.

Пример 54. Скрытые расходы. В ходе экспертизы выявились скрытые расходы: на приобретение оборудования, на оплату труда привлечённых специалистов, на командировки. Заказчик не был готов к таким расходам.

Пример 55. Валютные риски. Экспертная организация использовала иностранное оборудование и программное обеспечение, стоимость которых зависела от валютного курса. Колебания курса привели к удорожанию экспертизы.

Юридические сложности

Пример 56. Коллизия норм. Нормы процессуального законодательства и законодательства о контрактной системе по-разному регулировали порядок назначения экспертизы. Эксперт столкнулся с неопределённостью, которую пришлось разрешать суду.

Пример 57. Пробелы в законодательстве. Законодательство не содержало норм, регулирующих отдельные аспекты программной экспертизы. Эксперту пришлось действовать по аналогии, что создало риск оспаривания.

Пример 58. Неопределённость правового статуса. Правовой статус программного обеспечения как объекта экспертизы не был чётко определён. Эксперт столкнулся с трудностями при определении границ исследования.

Пример 59. Спор о подсудности. Стороны спорили о подсудности дела, что затянуло назначение экспертизы. Эксперт не мог начать работу до разрешения спора.

Пример 60. Спор о применимом праве. Стороны спорили о применимом праве, поскольку одна из них была иностранной. Эксперт столкнулся с необходимостью учитывать нормы иностранного права, что выходило за пределы его компетенции.

Пример 61. Оспаривание допустимости доказательства. Сторона оспорила допустимость заключения эксперта, ссылаясь на нарушения при его получении. Суд был вынужден оценивать допустимость, что затянуло процесс.

Пример 62. Оспаривание компетенции эксперта. Сторона оспорила компетенцию эксперта, ссылаясь на отсутствие у него специальных знаний. Суд был вынужден проверять квалификацию, что затянуло процесс.

Пример 63. Оспаривание методов. Сторона оспорила методы, применённые экспертом, ссылаясь на их ненаучность. Суд был вынужден оценивать научную обоснованность методов, что потребовало привлечения дополнительных специалистов.

Пример 64. Оспаривание выводов. Сторона оспорила выводы эксперта, ссылаясь на их необоснованность. Суд был вынужден оценивать обоснованность, что затянуло процесс.

Пример 65. Необходимость толкования технического задания. Техническое задание содержало нечёткие формулировки, допускающие различные толкования. Эксперт столкнулся с необходимостью толкования, что выходило за пределы его компетенции.

Пример 66. Необходимость толкования договора. Договор содержал противоречивые условия. Эксперт столкнулся с необходимостью толкования, что являлось прерогативой суда.

Пример 67. Спор о праве на программное обеспечение. Стороны спорили о принадлежности прав на программное обеспечение. Эксперт столкнулся с необходимостью учитывать правовые аспекты, что выходило за пределы его компетенции.

Пример 68. Спор о лицензиях. Стороны спорили о лицензиях на компоненты программного обеспечения. Эксперт столкнулся с необходимостью анализировать лицензионные условия, что требовало юридических знаний.

Пример 69. Спор о персональных данных. Стороны спорили о соблюдении требований по защите персональных данных. Эксперт столкнулся с необходимостью учитывать нормы законодательства о персональных данных, что требовало юридических знаний.

Пример 70. Спор о государственной тайне. Программное обеспечение содержало сведения, составляющие государственную тайну. Эксперт столкнулся с необходимостью соблюдать режим секретности, что ограничило возможности исследования.

Организационные сложности

Пример 71. Отсутствие квалифицированных экспертов. На рынке отсутствовали эксперты, обладающие необходимой квалификацией. Пришлось привлекать специалистов из других регионов, что увеличило сроки и расходы.

Пример 72. Загруженность эксперта. Эксперт был загружен другими делами. Проведение экспертизы затянулось, сроки были нарушены.

Пример 73. Болезнь эксперта. Эксперт заболел в ходе проведения экспертизы. Работа приостановилась, сроки были нарушены.

Пример 74. Увольнение эксперта. Эксперт уволился из экспертной организации в ходе проведения экспертизы. Пришлось передавать дело другому эксперту, что увеличило сроки.

Пример 75. Отсутствие помещения. Экспертная организация не имела подходящего помещения для проведения исследования. Пришлось искать помещение, что увеличило сроки и расходы.

Пример 76. Отсутствие оборудования. Экспертная организация не имела необходимого оборудования. Пришлось приобретать или арендовать, что увеличило сроки и расходы.

Пример 77. Отсутствие программных средств. Экспертная организация не имела лицензий на необходимые программные средства. Пришлось приобретать, что увеличило сроки и расходы.

Пример 78. Проблемы с доступом к интернету. Экспертная организация не имела надёжного доступа к интернету, необходимого для исследования веб-приложений. Работа затруднилась.

Пример 79. Проблемы с электропитанием. Отключения электроэнергии привели к потере промежуточных результатов. Пришлось повторять часть работы.

Пример 80. Проблемы с сохранностью объектов. Объекты исследования были утрачены или повреждены в ходе транспортировки. Пришлось восстанавливать их по копиям, что снизило достоверность.

Пример 81. Проблемы с координацией. Несколько экспертов, привлечённых к работе, не смогли скоординировать свои действия. Возникли разногласия, которые пришлось разрешать руководителю.

Пример 82. Проблемы с коммуникацией. Заказчик и эксперт не смогли наладить эффективную коммуникацию. Вопросы оставались без ответов, что затянуло работу.

Пример 83. Проблемы с документооборотом. Документы терялись, задерживались, оформлялись некорректно. Это затянуло процесс.

Пример 84. Проблемы с отчётностью. Эксперт несвоевременно представлял промежуточные отчёты. Заказчик не мог контролировать ход работы.

Пример 85. Проблемы с приёмкой. Заказчик отказался принимать работу, ссылаясь на несоответствие требованиям. Пришлось дорабатывать, что увеличило сроки.

Технические сложности

Пример 86. Невоспроизводимость дефекта. Дефект проявлялся периодически, при определённых условиях, которые не удавалось воспроизвести. Эксперт не смог подтвердить наличие дефекта.

Пример 87. Зависимость от внешних систем. Программный продукт зависел от внешних систем, недоступных эксперту. Оценка работоспособности оказалась неполной.

Пример 88. Зависимость от данных. Программный продукт зависел от данных, которые заказчик не предоставил. Эксперт не смог провести полноценное тестирование.

Пример 89. Зависимость от конфигурации. Программный продукт работал по-разному в зависимости от конфигурации. Эксперт не смог проверить все конфигурации.

Пример 90. Зависимость от версии. Программный продукт работал по-разному в зависимости от версии операционной системы. Эксперт не смог проверить все версии.

Пример 91. Сложность архитектуры. Архитектура программного продукта была настолько сложна, что эксперт не смог полностью её понять. Выводы оказались поверхностными.

Пример 92. Сложность алгоритмов. Алгоритмы, использованные в программном продукте, были настолько сложны, что эксперт не смог их проанализировать. Пришлось привлекать дополнительных специалистов.

Пример 93. Сложность интеграций. Интеграции программного продукта с внешними системами были настолько сложны, что эксперт не смог их проверить. Оценка оказалась неполной.

Пример 94. Сложность данных. Структура данных была настолько сложна, что эксперт не смог её проанализировать. Пришлось ограничиться выборочным анализом.

Пример 95. Сложность безопасности. Система безопасности была настолько сложна, что эксперт не смог её полностью проверить. Оценка уязвимостей оказалась неполной.

Пример 96. Большой объём данных. Объём данных, подлежащих анализу, был настолько велик, что эксперт не смог их обработать в разумные сроки. Пришлось применять автоматизированные средства, которые дают приблизительные результаты.

Пример 97. Высокая нагрузка. Программный продукт работал под высокой нагрузкой, которую не удалось воспроизвести в лабораторных условиях. Оценка производительности оказалась неточной.

Пример 98. Нестабильность. Программный продукт работал нестабильно, результаты тестирования различались при повторных запусках. Эксперт не смог получить воспроизводимые результаты.

Пример 99. Устаревание. Программный продукт устарел, технологии, на которых он основан, вышли из употребления. Эксперт не смог найти специалистов, способных оценить продукт.

Пример 100. Отсутствие аналогов. Программный продукт не имел аналогов, с которыми можно было бы сравнить. Эксперт не смог оценить его соответствие современному уровню.

Методологические сложности

Пример 101. Отсутствие методики. Не существовало утверждённой методики проведения программной экспертизы. Эксперт был вынужден разрабатывать методику самостоятельно, что создало риск оспаривания.

Пример 102. Противоречивость методик. Существующие методики противоречили друг другу. Эксперт не смог выбрать, какой из них следовать.

Пример 103. Неприменимость методики. Методика, разработанная для одного типа программного обеспечения, оказалась неприменима к другому типу. Эксперт не смог её использовать.

Пример 104. Устаревание методики. Методика устарела и не учитывала современных технологий. Эксперт не смог её применить.

Пример 105. Субъективность оценки. Методика предполагала субъективную оценку, результаты которой зависели от эксперта. Это снизило объективность выводов.

Пример 106. Отсутствие критериев. Не существовало чётких критериев оценки качества программного обеспечения. Эксперт был вынужден руководствоваться собственным усмотрением.

Пример 107. Отсутствие эталонов. Не существовало эталонов, с которыми можно было бы сравнить программный продукт. Эксперт не смог оценить его соответствие уровню.

Пример 108. Отсутствие метрик. Не существовало метрик, позволяющих количественно оценить качество программного продукта. Эксперт был вынужден ограничиться качественными оценками.

Пример 109. Сложность интерпретации. Результаты анализа были сложны для интерпретации. Эксперт не смог сделать однозначные выводы.

Пример 110. Неоднозначность выводов. Результаты анализа допускали различные интерпретации. Эксперт не смог сделать категоричные выводы.

Этические сложности

Пример 111. Конфликт между истиной и интересом заказчика. Заказчик ожидал определённых выводов, но результаты исследования противоречили его ожиданиям. Эксперт оказался перед выбором: сообщить истину или угодить заказчику.

Пример 112. Давление со стороны заказчика. Заказчик настаивал на изменении выводов. Эксперт отказался, что привело к конфликту и отказу заказчика от оплаты.

Пример 113. Давление со стороны разработчика. Разработчик угрожал эксперту судебным преследованием, если выводы будут неблагоприятными. Эксперт был вынужден обратиться за защитой.

Пример 114. Конфиденциальность. Эксперт получил доступ к сведениям, составляющим коммерческую тайну. Возник риск разглашения, что потребовало особых мер предосторожности.

Пример 115. Конфликт интересов. Эксперт имел личные или деловые связи со стороной. Он не заявил самоотвод, что подорвало доверие к его заключению.

Пример 116. Некомпетентность. Эксперт взялся за работу, выходящую за пределы его компетенции. Выводы оказались необоснованными, что привело к негативным последствиям.

Пример 117. Халатность. Эксперт отнёсся к работе формально, не провёл должного исследования. Заключение оказалось поверхностным.

Пример 118. Предвзятость. Эксперт изначально имел предубеждение против одной из сторон. Это отразилось на выводах, что привело к оспариванию заключения.

Пример 119. Коррупция. Эксперт принял вознаграждение за определённые выводы. Это стало известно, что привело к уголовному преследованию.

Пример 120. Разглашение. Эксперт разгласил сведения, ставшие известными в связи с экспертизой. Это причинило ущерб сторонам и подорвало доверие к эксперту.

---

РЕЦЕНЗИИ И РЕЦЕНЗИРОВАНИЕ В ПРОГРАММНОЙ ЭКСПЕРТИЗЕ

Сущность рецензирования заключения программной экспертизы

Рецензирование заключения программной экспертизы представляет собой самостоятельный вид экспертной деятельности, направленный на профессиональную проверку уже выполненного исследования. Рецензия — это документ, в котором специалист, обладающий познаниями в соответствующей области, анализирует заключение эксперта на предмет его обоснованности, полноты, методической корректности и соответствия требованиям законодательства. В контексте программной экспертизы рецензент исследует, насколько правильно эксперт проанализировал программный код, документацию, журналы работы системы, насколько обоснованно применил методы тестирования и статического анализа, насколько выводы соответствуют исследовательской части.

Рецензирование не является повторной экспертизой. Повторная экспертиза предполагает новое исследование тех же объектов по тем же вопросам и назначается судом. Рецензент же не проводит исследование заново, не устанавливает факты самостоятельно, не заменяет первоначальное заключение своим. Его задача — показать, что выводам эксперта нельзя доверять, выявить конкретные нарушения, ошибки, противоречия, которые ставят под сомнение достоверность заключения.

Потребность в рецензировании возникает в следующих ситуациях. Сторона спора получает заключение судебной или досудебной программной экспертизы, которое содержит выводы, противоречащие её позиции. Сторона подозревает, что эксперт был некомпетентен, применил неподходящие методы, проигнорировал существенные материалы дела или действовал предвзято. Сторона намерена оспорить заключение в суде, но не знает, на какие именно нарушения указать. Во всех этих случаях рецензия становится инструментом, позволяющим превратить смутное сомнение в конкретные, юридически значимые доводы.

Рецензирование недостоверной и лживой экспертизы

Особое значение рецензирование приобретает тогда, когда речь идёт о недостоверной, недобросовестной или откровенно ложной программной экспертизе, выполненной сторонней экспертной организацией. Такая экспертиза может быть результатом некомпетентности, халатности или прямого сговора с одной из сторон.

Признаки недостоверной программной экспертизы. Рецензент должен уметь выявлять характерные признаки, свидетельствующие о недостоверности заключения. К ним относятся: отсутствие описания объектов исследования или их неполное описание; ссылки на методы и инструменты, которые фактически не применялись или не могли быть применены; выводы, не вытекающие из исследовательской части; противоречия между разными частями заключения; игнорирование материалов дела, имеющих существенное значение; использование устаревших или неприменимых методик; отсутствие проверяемых расчётов и обоснований; подмена технических выводов правовыми оценками; выход за пределы компетенции эксперта.

Лживая экспертиза. Если эксперт умышленно исказил факты, сделал выводы, заведомо не соответствующие действительности, это не просто некачественная экспертиза, а уголовно наказуемое деяние. Рецензия в таком случае должна не только указать на ошибки, но и продемонстрировать их системный, направленный характер, свидетельствующий об умысле. Например, если эксперт утверждает, что программный продукт работоспособен, но в заключении отсутствуют следы проведения тестирования, или если эксперт ссылается на проанализированные журналы, которые фактически не были ему предоставлены, — это признаки фальсификации.

Польза рецензии при оспаривании ложной экспертизы. Рецензия позволяет стороне:

• получить профессиональную оценку заключения от независимого специалиста;

• сформулировать конкретные, проверяемые доводы против заключения;

• обосновать ходатайство о назначении повторной экспертизы;

• подготовить вопросы для допроса эксперта в суде;

• привлечь внимание суда к нарушениям, которые иначе могли остаться незамеченными;

• создать доказательственную базу для оспаривания заключения как недопустимого доказательства.

Структура и содержание рецензии на заключение программной экспертизы

Рецензия на заключение программной экспертизы должна соответствовать определённым требованиям к структуре и содержанию. Наиболее распространённая структура включает вводную, описательную, критическую части и выводы.

Вводная часть. Указываются сведения о рецензенте (образование, квалификация, опыт), сведения о рецензируемом заключении (кем выполнено, когда, по какому делу), основания проведения рецензирования, перечень материалов, изученных рецензентом. Рецензент должен подтвердить, что он обладает необходимой квалификацией для оценки именно программной экспертизы.

Описательная часть. Кратко излагается содержание рецензируемого заключения: какие вопросы были поставлены, какие методы применены, какие выводы сделаны. Это необходимо для того, чтобы читатель рецензии понимал, что именно критикуется.

Критическая часть. Основная часть рецензии. Здесь рецензент анализирует заключение по следующим направлениям:

• соответствие требованиям законодательства о судебной экспертной деятельности;

• полнота и достаточность исследованных материалов;

• корректность выбора и применения методов;

• обоснованность выводов;

• наличие логических, методических, арифметических ошибок;

• соответствие выводов исследовательской части;

• соблюдение пределов компетенции эксперта;

• наличие признаков недостоверности или предвзятости.

Каждое замечание должно быть конкретным, проверяемым и подкреплённым ссылкой на норму, стандарт, методику или фактическое противоречие. Голословная критика без указания на конкретные нарушения не имеет доказательственной силы.

Выводы. Рецензент формулирует итоговую оценку: соответствует ли заключение требованиям, предъявляемым к программной экспертизе; имеются ли нарушения, влияющие на достоверность выводов; может ли заключение быть использовано как доказательство. Выводы рецензии не должны подменять выводы экспертизы; рецензент не устанавливает факты заново, а оценивает, можно ли доверять уже установленным.

Правовой статус рецензии как доказательства

Правовой статус рецензии в судебном процессе является предметом продолжающейся дискуссии и неоднозначной судебной практики.

Рецензия не является самостоятельным доказательством. Процессуальное законодательство и законодательство об экспертной деятельности не предусматривают рецензирование экспертных заключений как отдельный вид доказательств. Рецензия не является заключением эксперта, поскольку не получена в порядке, установленном процессуальным законом. Она представляет собой субъективное мнение специалиста относительно мнения другого специалиста.

Оценка рецензии судом. Вместе с тем рецензия не может быть произвольно исключена из процесса. Верховный Суд Российской Федерации в Определении от 25 января 2018 г. № 305-ЭС17-11486 указал, что ходатайство о приобщении к материалам дела рецензии, составленной для опровержения выводов экспертизы, не может быть отклонено, поскольку это лишает сторону возможности доказать свои возражения. Неприобщение рецензии и отказ в проведении повторной экспертизы были признаны неправомерными.

В Определении Верховного Суда Российской Федерации от 10 октября 2014 г. № 305-ЭС14-3484 сформулирована позиция, согласно которой рецензия, полученная во внесудебном порядке и составленная после получения результатов судебной экспертизы, не обладает необходимой доказательственной силой в подтверждение заявленных требований. Она не может являться доказательством, опровергающим выводы судебной экспертизы, поскольку рецензирование экспертных заключений не предусмотрено процессуальным законодательством.

Рецензия как письменное доказательство. В арбитражном процессе рецензия может быть приобщена к материалам дела в качестве письменного доказательства. Согласно части 1 статьи 89 Арбитражного процессуального кодекса Российской Федерации, иные документы и материалы допускаются в качестве доказательств, если содержат сведения об обстоятельствах, имеющих значение для правильного рассмотрения дела. Рецензия, содержащая анализ заключения эксперта и указание на конкретные нарушения, содержит такие сведения.

В Постановлении Арбитражного суда Дальневосточного округа от 21 июня 2023 г. по делу № А37-675/2021 суд указал, что рецензия по своему содержанию не является экспертным заключением, представляет собой оплаченное стороной субъективное мнение специалиста, но подлежит оценке наряду с другими доказательствами.

Рецензия как основание для ходатайств. Основная процессуальная функция рецензии — служить обоснованием для заявления ходатайств: о назначении повторной или дополнительной экспертизы, о вызове эксперта для допроса, о признании заключения недопустимым доказательством. Рецензия помогает суду понять, имеются ли основания сомневаться в обоснованности заключения.

Конституционный принцип состязательности. Конституционный Суд Российской Федерации в Определении от 20 июля 2021 г. № 1593-О указал, что придание особого доказательственного значения заключению (рецензии) стороны в деле, пусть и обладающей специальными знаниями, исходя из конституционного принципа состязательности и равноправия сторон, является недопустимым. Это означает, что рецензия не может автоматически опровергать судебную экспертизу, но и судебная экспертиза не имеет заранее установленной силы перед рецензией.

Практика Верховного Суда. Определение Верховного Суда Российской Федерации от 25 января 2018 г. № 305-ЭС17-11486 создало важный прецедент: заключение специалиста, составленное с целью опровержения выводов экспертизы и содержащее подробный анализ экспертного заключения, имеет отношение к делу и подлежит приобщению. Требования к оформлению такого заключения законом не установлены, а потому оно не может быть признано недопустимым доказательством только на основании его внесудебного характера. Неприобщив рецензию и не дав оценку её содержательной части, суд лишает сторону возможности доказать свои возражения.

Процессуальные возможности использования рецензии

Рецензия на заключение программной экспертизы может быть использована в судебном процессе следующими способами.

Приобщение к материалам дела как письменного доказательства. Сторона заявляет мотивированное ходатайство о приобщении рецензии к материалам дела. В ходатайстве указываются конкретные нарушения, выявленные рецензией, со ссылками на нормы и методики. Рецензия приобщается в качестве иного документа или письменного доказательства.

Обоснование ходатайства о назначении повторной экспертизы. Если рецензия выявила существенные нарушения, сторона заявляет ходатайство о назначении повторной экспертизы. Рецензия прилагается к ходатайству как обоснование сомнений в обоснованности первоначального заключения. Суд оценивает доводы рецензии при решении вопроса о назначении повторной экспертизы.

Подготовка к допросу эксперта. На основе рецензии сторона формулирует вопросы для допроса эксперта в судебном заседании. Вопросы должны быть направлены на выявление противоречий, на проверку методов, на обоснование выводов. Под давлением конкретных вопросов эксперт может признать ограничения своего исследования или неточности в расчётах.

Обоснование недопустимости заключения. Если рецензия выявила процессуальные нарушения (отсутствие предупреждения об ответственности, выход за пределы компетенции, использование недопустимых методов), сторона может заявить о недопустимости заключения как доказательства.

Подготовка письменных возражений. Рецензия используется как основа для письменных возражений на заключение эксперта. Возражения должны содержать конкретные доводы, подкреплённые ссылками на рецензию.

Проблемы и ограничения рецензирования

Отсутствие законодательного регулирования. Рецензирование экспертных заключений не урегулировано процессуальным законодательством. Это создаёт неопределённость в правовом статусе рецензии и порождает противоречивую судебную практику.

Критическое отношение судов. Многие суды относятся к рецензиям с недоверием, рассматривая их как субъективное мнение, оплаченное заинтересованной стороной. Рецензия не может заменить судебную экспертизу и не имеет заранее установленной силы.

Риск ангажированности рецензента. Рецензент, как и эксперт, может быть ангажирован. Если рецензия выполнена по заказу стороны, существует риск, что рецензент будет искать только недостатки, игнорируя сильные стороны заключения.

Ограниченность материалов. Рецензент анализирует только те материалы, которые ему предоставлены. Если сторона не имеет доступа к полному тексту заключения или к материалам, бывшим в распоряжении эксперта, рецензия может быть неполной.

Невозможность замены экспертизы. Рецензия не может заменить повторную экспертизу. Даже самая убедительная рецензия не устанавливает факты заново; она лишь показывает, почему выводам эксперта нельзя доверять. Для установления фактов требуется новое экспертное исследование.

Проблема квалификации рецензента. Рецензент должен обладать квалификацией не ниже, чем эксперт, чьё заключение он проверяет. Если рецензент менее компетентен, его критика может быть неубедительной.

Стратегия использования рецензии

Оптимальная стратегия использования рецензии включает следующие этапы.

Этап первый: получение заключения. Сторона получает заключение программной экспертизы, знакомится с ним, оценивает его выводы.

Этап второй: принятие решения о рецензировании. Если выводы заключения неблагоприятны для стороны и есть основания сомневаться в их обоснованности, принимается решение о заказе рецензии. Если заключение явно обоснованно, рецензирование может быть бесперспективным.

Этап третий: выбор рецензента. Рецензент должен обладать квалификацией в области программной экспертизы, иметь опыт рецензирования, быть независимым от сторон спора. Важно, чтобы рецензент имел подтверждённые компетенции, соответствующие предмету оспариваемой экспертизы.

Этап четвёртый: проведение рецензирования. Рецензенту предоставляются заключение эксперта и материалы, которые были в распоряжении эксперта. Рецензент анализирует заключение, выявляет нарушения, формулирует выводы.

Этап пятый: приобщение рецензии к делу. Сторона заявляет ходатайство о приобщении рецензии к материалам дела с обоснованием её значения для дела.

Этап шестой: использование рецензии. В зависимости от результатов рецензирования сторона заявляет ходатайство о повторной экспертизе, о вызове эксперта, о признании заключения недопустимым, либо использует рецензию для подготовки возражений.

Этап седьмой: допрос эксперта. Если рецензия выявила конкретные противоречия, сторона ходатайствует о вызове эксперта для дачи пояснений. Вопросы, подготовленные на основе рецензии, позволяют проверить обоснованность выводов эксперта.

Рецензия и повторная экспертиза: соотношение

Рецензия и повторная экспертиза — разные инструменты, решающие разные задачи. Рецензия отвечает на вопрос, обоснованно ли заключение. Повторная экспертиза отвечает на вопрос по существу: каковы фактические обстоятельства дела.

Практический порядок обычно таков: сначала заказывается рецензия, которая обосновывает ходатайство о повторной экспертизе. Если суд удовлетворяет ходатайство, назначается повторная экспертиза. Заказывать повторное исследование до рецензии имеет смысл лишь тогда, когда очевидно, что спор всё равно упрётся в существо.

Бывает и обратный результат: рецензия показывает, что заключение обоснованно, и оспаривать его бесперспективно. Это экономит расходы на повторную экспертизу, которая подтвердила бы прежние выводы.

Значение рецензирования для программной экспертизы

Рецензирование играет важную роль в обеспечении качества программной экспертизы. Оно позволяет:

• выявлять ошибки и нарушения, допущенные экспертами;

• повышать ответственность экспертов;

• обеспечивать состязательность процесса;

• помогать суду в оценке заключений;

• защищать права сторон от недобросовестных экспертиз.

Рецензирование не заменяет судебный контроль, но дополняет его. Оно даёт сторонам инструмент для профессионального оспаривания заключений, а суду — дополнительную информацию для оценки доказательств.

В условиях сложности и технической специфичности программной экспертизы рецензирование становится особенно востребованным. Судья, не обладающий специальными знаниями в области программирования, не может самостоятельно оценить, насколько обоснованно эксперт проанализировал код, применил методы тестирования, интерпретировал результаты. Рецензия помогает суду понять, какие вопросы требуют дополнительного исследования, какие нарушения являются существенными, можно ли доверять выводам эксперта.

Таким образом, рецензирование заключения программной экспертизы представляет собой важный процессуальный инструмент, позволяющий сторонам защищать свои права, а суду — принимать законные и обоснованные решения. Несмотря на отсутствие законодательного регулирования и неоднозначную судебную практику, рецензия при правильном оформлении и обосновании может существенно повлиять на исход дела, особенно когда речь идёт о недостоверной или ложной экспертизе.

---

ГЛОССАРИЙ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ

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. Дефект — несоответствие программного продукта требованиям, приводящее к нарушению его функционирования.

28. Критический дефект — дефект, препятствующий использованию программного продукта по назначению.

29. Существенный дефект — дефект, влияющий на функциональность программного продукта, но не препятствующий его использованию.

30. Несущественный дефект — дефект, не влияющий на функциональность программного продукта.

31. Причина неисправности — фактор, приведший к возникновению неисправности программного продукта.

32. Причинно-следственная связь — объективная связь между действиями (бездействием) и наступившими последствиями, устанавливаемая экспертом.

33. Тестирование — целенаправленная проверка программного продукта на соответствие требованиям.

34. Функциональное тестирование — проверка выполнения программным продуктом заданных функций.

35. Интеграционное тестирование — проверка взаимодействия модулей программного продукта.

36. Системное тестирование — проверка программного продукта как единого целого.

37. Нагрузочное тестирование — проверка производительности программного продукта при различных нагрузках.

38. Стресс-тестирование — проверка устойчивости программного продукта при экстремальных нагрузках.

39. Регрессионное тестирование — проверка программного продукта после внесения изменений.

40. Приёмочное тестирование — проверка соответствия программного продукта критериям приёмки, установленным заказчиком.

41. Автоматизированное тестирование — тестирование с использованием программных средств, не требующее постоянного участия человека.

42. Статический анализ — анализ исходного кода без его выполнения.

43. Динамический анализ — анализ программного продукта путём его выполнения.

44. Реверс-инжиниринг — восстановление исходного кода или архитектуры программного продукта по объектному коду.

45. Дизассемблирование — преобразование объектного кода в язык ассемблера.

46. Декомпиляция — преобразование объектного кода в исходный код на языке высокого уровня.

47. Обфускация — намеренное запутывание исходного кода для затруднения его анализа.

48. Деобфускация — восстановление обфусцированного кода.

49. Метрика кода — количественная характеристика исходного кода (количество строк, цикломатическая сложность, связанность, сцепление, дублирование).

50. Цикломатическая сложность — метрика, измеряющая количество независимых путей выполнения в программе.

51. Связанность модулей — метрика, измеряющая степень зависимости модулей друг от друга.

52. Сцепление модулей — метрика, измеряющая степень внутренней связности элементов модуля.

53. Дублирование кода — наличие в программном продукте повторяющихся фрагментов кода.

54. «Мёртвый» код — участки кода, которые не используются при выполнении программы.

55. Архитектура программного продукта — структура программного продукта, определяющая состав компонентов и связи между ними.

56. Монолитная архитектура — архитектура, при которой программный продукт представляет собой единое целое.

57. Микросервисная архитектура — архитектура, при которой программный продукт состоит из множества независимых сервисов.

58. Единая точка отказа — компонент, выход из строя которого приводит к отказу всей системы.

59. Масштабируемость — способность программного продукта увеличивать производительность при увеличении ресурсов.

60. Горизонтальное масштабирование — увеличение производительности путём добавления серверов.

61. Вертикальное масштабирование — увеличение производительности путём добавления ресурсов существующему серверу.

62. Отказоустойчивость — способность программного продукта сохранять работоспособность при отказах отдельных компонентов.

63. Производительность — характеристика программного продукта, определяющая скорость выполнения операций.

64. Время отклика — время, затрачиваемое программным продуктом на выполнение операции.

65. Пропускная способность — количество операций, выполняемых программным продуктом в единицу времени.

66. Уязвимость — недостаток программного продукта, позволяющий нарушить его безопасность.

67. Информационная безопасность — состояние защищённости информации, обрабатываемой программным продуктом.

68. Персональные данные — любая информация, относящаяся к прямо или косвенно определённому физическому лицу.

69. Защита персональных данных — комплекс мер, направленных на обеспечение безопасности персональных данных.

70. Импортозамещение — замена иностранного программного обеспечения отечественным.

71. Реестр отечественного программного обеспечения — перечень программного обеспечения, происходящего из Российской Федерации.

72. Лицензия — документ, определяющий условия использования программного продукта.

73. Проприетарная лицензия — лицензия, ограничивающая права пользователя на использование, изменение и распространение программного продукта.

74. Свободная лицензия — лицензия, предоставляющая пользователю широкие права на использование, изменение и распространение программного продукта.

75. Версионный контроль — система учёта изменений исходного кода.

76. Репозиторий — хранилище исходного кода и истории его изменений.

77. Ветвление — создание независимой линии разработки в системе версионного контроля.

78. Слияние — объединение изменений из разных ветвей разработки.

79. Журнал работы системы — файл, содержащий записи о событиях, происходящих в программном продукте.

80. Логирование — процесс записи событий в журнал.

81. Мониторинг — процесс наблюдения за работой программного продукта.

82. Резервное копирование — процесс создания копий данных для восстановления в случае утраты.

83. Восстановление — процесс возврата программного продукта или данных в работоспособное состояние.

84. Миграция данных — процесс переноса данных из одной системы в другую.

85. Целостность данных — состояние данных, при котором они сохраняют свою полноту и корректность.

86. Валидация — проверка входных данных на соответствие установленным требованиям.

87. Исключительная ситуация — событие, возникающее в ходе выполнения программы и требующее специальной обработки.

88. Обработка исключительных ситуаций — механизм, позволяющий программе корректно реагировать на исключительные ситуации.

89. API (интерфейс программирования приложений) — набор правил и инструментов, позволяющих программам взаимодействовать друг с другом.

90. Интеграция — процесс объединения программных продуктов для совместной работы.

91. Совместимость — способность программного продукта работать в определённой среде без конфликтов.

92. Конфигурация — совокупность настроек программного продукта и среды его функционирования.

93. Среда функционирования — совокупность аппаратных и программных средств, обеспечивающих работу программного продукта.

94. Развёртывание — процесс установки и настройки программного продукта в среде функционирования.

95. Ввод в эксплуатацию — процесс начала использования программного продукта по назначению.

96. Сопровождение — процесс поддержания работоспособности программного продукта после ввода в эксплуатацию.

97. Гарантийное обслуживание — обслуживание программного продукта в течение гарантийного срока.

98. Техническая документация — совокупность документов, описывающих программный продукт.

99. Руководство пользователя — документ, описывающий порядок использования программного продукта.

100. Руководство администратора — документ, описывающий порядок настройки и сопровождения программного продукта.

101. Проектная документация — совокупность документов, описывающих проектные решения.

102. Эксплуатационная документация — совокупность документов, описывающих порядок эксплуатации программного продукта.

103. Матрица соответствия — таблица, сопоставляющая требования технического задания с фактической реализацией.

104. Актуальность документации — соответствие документации фактическому состоянию программного продукта.

105. Полнота документации — наличие в документации всех необходимых сведений.

106. Корректность документации — отсутствие в документации ошибок и противоречий.

107. Юзабилити — удобство использования программного продукта.

108. Доступность — возможность использования программного продукта лицами с ограниченными возможностями.

109. Альтернативный текст — текстовое описание изображения, используемое для озвучивания.

110. Контрастность — различие в яркости или цвете элементов интерфейса.

111. Семантическая разметка — разметка, отражающая смысловую структуру документа.

112. Скрин-ридер — программа, озвучивающая содержимое экрана для незрячих пользователей.

113. Аудит — комплексная проверка программного продукта.

114. Ревизия — проверка соответствия программного продукта требованиям.

115. Пентест — тестирование на проникновение, имитирующее действия злоумышленника.

116. Сканирование уязвимостей — автоматизированный поиск уязвимостей.

117. SQL-инъекция — уязвимость, позволяющая внедрять SQL-код в запросы.

118. Межсайтовый скриптинг (XSS) — уязвимость, позволяющая внедрять вредоносный скрипт в веб-страницу.

119. Подделка межсайтовых запросов (CSRF) — уязвимость, позволяющая выполнять действия от имени пользователя.

120. Шифрование — преобразование данных для защиты от несанкционированного доступа.

121. Аутентификация — процесс проверки подлинности пользователя.

122. Авторизация — процесс проверки прав пользователя.

123. Разграничение доступа — механизм, ограничивающий доступ пользователей к ресурсам.

124. Журналирование действий — запись действий пользователей в журнал.

125. Компрометация — нарушение безопасности программного продукта.

126. Утечка данных — несанкционированная передача данных третьим лицам.

127. Потеря данных — утрата данных вследствие сбоя или иных причин.

128. Восстановление данных — процесс возврата утраченных данных.

129. Уничтожение данных — процесс безвозвратного удаления данных.

130. Хранение данных — процесс размещения данных на носителях.

131. Облачный сервис — сервис, предоставляющий вычислительные ресурсы через интернет.

132. Сервер — компьютер, предоставляющий ресурсы другим компьютерам.

133. Виртуальная машина — программная эмуляция компьютера.

134. Контейнер — изолированная среда выполнения программного продукта.

135. Микросервис — независимый компонент программного продукта, выполняющий определённую функцию.

136. Прокси-сервер — промежуточный сервер, перенаправляющий запросы.

137. Балансировщик нагрузки — устройство или программа, распределяющая нагрузку между серверами.

138. Кэширование — сохранение результатов вычислений для ускорения последующих обращений.

139. Индекс базы данных — структура, ускоряющая поиск данных.

140. Транзакция — группа операций, выполняемых как единое целое.

141. Блокировка — механизм, предотвращающий одновременное изменение данных.

142. Таймаут — ограничение времени выполнения операции.

143. Переполнение памяти — ситуация, при которой программе не хватает памяти.

144. Утечка памяти — ситуация, при которой программа не освобождает выделенную память.

145. Профилирование — измерение характеристик работы программы.

146. Трассировка — запись последовательности выполнения программы.

147. Отладка — процесс поиска и устранения дефектов.

148. Отладчик — инструмент для отладки программ.

149. Линтер — инструмент для статического анализа кода.

150. Статический анализатор — инструмент для автоматического анализа кода.

151. Компилятор — программа, преобразующая исходный код в объектный.

152. Интерпретатор — программа, выполняющая исходный код без компиляции.

153. Фреймворк — программная платформа, определяющая структуру приложения.

154. Библиотека — набор программных компонентов, используемых при разработке.

155. Зависимость — компонент, необходимый для работы программного продукта.

156. Менеджер зависимостей — инструмент для управления зависимостями.

157. Конфликт версий — ситуация, при которой разные компоненты требуют разных версий одной зависимости.

158. Устаревшая зависимость — компонент, поддержка которого прекращена.

159. Уязвимая зависимость — компонент, содержащий известные уязвимости.

160. Открытый исходный код — исходный код, доступный для изучения и изменения.

161. Закрытый исходный код — исходный код, недоступный для изучения и изменения.

162. Проприетарное программное обеспечение — программное обеспечение, права на которое принадлежат правообладателю.

163. Свободное программное обеспечение — программное обеспечение, распространяемое на условиях свободных лицензий.

164. Отечественное программное обеспечение — программное обеспечение, происходящее из Российской Федерации.

165. Иностранное программное обеспечение — программное обеспечение, происходящее из-за рубежа.

166. Судебное доказательство — сведения о фактах, полученные в установленном законом порядке и используемые судом для установления обстоятельств дела.

167. Письменное доказательство — документ, содержащий сведения об обстоятельствах, имеющих значение для дела.

168. Допустимость доказательства — соответствие доказательства требованиям закона.

169. Достоверность доказательства — соответствие доказательства действительности.

170. Достаточность доказательств — совокупность доказательств, позволяющая суду сделать вывод об обстоятельствах дела.

171. Оценка доказательств — процесс определения судом относимости, допустимости, достоверности и достаточности доказательств.

172. Судебные издержки — расходы, связанные с рассмотрением дела в суде.

173. Распределение судебных расходов — порядок отнесения судебных издержек на стороны.

174. Возмещение расходов — компенсация понесённых стороной расходов.

175. Разумность расходов — соответствие расходов сложности дела и рыночным ценам.

176. Ходатайство — обращение стороны к суду с просьбой о совершении процессуального действия.

177. Отвод — заявление о недопустимости участия лица в процессе.

178. Дополнительная экспертиза — экспертиза, назначаемая при недостаточной ясности или полноте заключения.

179. Повторная экспертиза — экспертиза, назначаемая при сомнениях в обоснованности заключения.

180. Комиссионная экспертиза — экспертиза, проводимая несколькими экспертами одной специальности.

181. Комплексная экспертиза — экспертиза, проводимая экспертами разных специальностей.

182. Особое мнение эксперта — мнение эксперта, не согласного с выводами других экспертов.

183. Предупреждение об ответственности — процессуальное действие, обеспечивающее осведомлённость эксперта о последствиях ложного заключения.

184. Уголовная ответственность эксперта — ответственность за дачу заведомо ложного заключения.

185. Гражданско-правовая ответственность эксперта — ответственность за причинение ущерба вследствие некачественной экспертизы.

186. Дисциплинарная ответственность эксперта — ответственность за нарушение служебной дисциплины.

187. Административная ответственность эксперта — ответственность за невыполнение требований суда.

188. Профессиональная ответственность эксперта — ответственность перед профессиональным сообществом.

189. Сертификация эксперта — подтверждение соответствия квалификации эксперта требованиям профессиональных стандартов.

190. Аккредитация эксперта — официальное признание компетентности эксперта уполномоченным органом.

191. Реестр экспертов — перечень квалифицированных экспертов.

192. Квалификация эксперта — совокупность образования, опыта, знаний и навыков эксперта.

193. Компетенция эксперта — круг вопросов, которые эксперт вправе разрешать.

194. Пределы компетенции — границы, за которые эксперт не вправе выходить.

195. Независимость эксперта — отсутствие заинтересованности эксперта в исходе дела.

196. Беспристрастность эксперта — способность эксперта дать объективное заключение.

197. Конфликт интересов — ситуация, при которой эксперт заинтересован в определённом исходе дела.

198. Самоотвод эксперта — отказ эксперта от участия в деле при наличии конфликта интересов.

199. Конфиденциальность — обязанность эксперта сохранять в тайне сведения, ставшие известными в связи с экспертизой.

200. Научная обоснованность — соответствие методов и выводов эксперта современному уровню науки и техники.

201. Проверяемость — возможность воспроизведения исследования и проверки выводов.

202. Логическая непротиворечивость — отсутствие внутренних противоречий в заключении.

203. Полнота исследования — исследование всех объектов и вопросов.

204. Объективность исследования — отсутствие односторонности и предвзятости.

205. Всесторонность исследования — учёт всех обстоятельств, имеющих значение.

206. Методология программной экспертизы — система методов, приёмов и средств, используемых экспертом.

207. Общенаучные методы — методы познания, применяемые во всех науках (анализ, синтез, индукция, дедукция, моделирование, эксперимент).

208. Специальные методы — методы, заимствованные из области программирования и информационных технологий.

209. Инструментальные средства — программные и аппаратные средства, используемые экспертом.

210. Фиксация объектов — обеспечение сохранности объектов исследования и документирование их состояния.

211. Резервное копирование объектов — создание копий объектов для обеспечения их сохранности.

212. Хеш-сумма — значение, вычисляемое по содержимому файла и используемое для проверки его целостности.

213. Цифровая подпись — средство подтверждения подлинности документа.

214. Этапы проведения экспертизы — последовательность действий эксперта от подготовки до оформления заключения.

215. Подготовительный этап — этап изучения постановления, определения объектов, планирования исследования.

216. Аналитический этап — этап анализа объектов исследования.

217. Синтетический этап — этап обобщения результатов исследования.

218. Заключительный этап — этап оформления заключения.

219. Сроки проведения экспертизы — время, необходимое для проведения исследования.

220. Стоимость экспертизы — денежное выражение затрат на проведение исследования.

221. Ценообразующие факторы — факторы, влияющие на стоимость экспертизы.

222. Трудоёмкость — количество затрат труда, необходимых для проведения экспертизы.

223. Трудозатраты — выраженное в человеко-часах или человеко-днях количество труда.

224. Накладные расходы — расходы, связанные с организацией деятельности экспертной организации.

225. Прибыль экспертной организации — часть стоимости экспертизы, остающаяся после покрытия расходов.

226. Аванс — предварительная оплата экспертизы.

227. Окончательный расчёт — оплата экспертизы по завершении работы.

228. Поэтапная оплата — оплата экспертизы по мере выполнения этапов.

229. Спор между разработчиком и заказчиком — конфликт, возникающий при исполнении договора на создание программного продукта.

230. Претензия — письменное требование стороны к контрагенту об устранении нарушений.

231. Претензионный порядок — обязательная процедура досудебного урегулирования спора.

232. Мировое соглашение — соглашение сторон о прекращении спора.

233. Медиация — процедура урегулирования спора с участием посредника.

234. Третейский суд — негосударственный орган разрешения споров.

235. Арбитражный суд — государственный орган разрешения экономических споров.

236. Суд общей юрисдикции — государственный орган разрешения гражданских споров.

237. Апелляция — пересмотр решения суда вышестоящей инстанцией.

238. Кассация — проверка законности решения суда вышестоящей инстанцией.

239. Надзор — пересмотр решения суда в порядке надзора.

240. Исполнительное производство — процедура принудительного исполнения судебного акта.

---

ВЫВОДЫ И ЗАКЛЮЧЕНИЕ

Проведённое исследование позволяет сформулировать ряд итоговых положений, имеющих как теоретическое, так и практическое значение.

Программная экспертиза представляет собой самостоятельный вид экспертной деятельности, обладающий собственным предметом, объектами, методами и субъектным составом. Её выделение обусловлено объективными потребностями правоприменительной практики, связанными с ростом числа споров между разработчиками программного обеспечения и заказчиками — коммерческими предприятиями, государственными учреждениями, министерствами, ведомствами и муниципалитетами. Программная экспертиза позволяет установить факты исполнения или неисполнения обязательств, надлежащего или ненадлежащего исполнения требований государственных и муниципальных контрактов, причины неисправностей программного обеспечения, объём и стоимость фактически выполненных работ.

В монографии рассмотрены понятие, сущность и правовая природа программной экспертизы, её предмет, объекты и задачи, методология, правовое регулирование, особенности судебной и досудебной форм, типовые предметы исследования, специфика споров по государственным и муниципальным контрактам, вопросы защиты прав заказчика и разработчика, технические, организационные и этические аспекты, проблемы и рекомендации, требования к экспертам, практические кейсы, вопросы цены и сроков, рецензирование заключений, а также глоссарий терминов.

Программная экспертиза является развивающимся институтом. Её значение будет возрастать по мере дальнейшей цифровизации экономики, государственного управления и общественных отношений. Споры, связанные с созданием и использованием программного обеспечения, становятся всё более сложными, затрагивают значительные финансовые ресурсы, требуют применения специальных знаний. Без квалифицированной программной экспертизы разрешение таких споров невозможно.

Настоящая монография адресована судьям, арбитражным управляющим, юристам, специализирующимся на IT-спорах, экспертам в области информационных технологий, государственным и муниципальным заказчикам, руководителям коммерческих организаций, научным работникам и студентам. Автор стремился к максимальной практической ориентированности работы, не в ущерб теоретической глубине и методологической строгости.

Приглашение к сотрудничеству

В условиях роста числа споров, связанных с созданием, внедрением и сопровождением программного обеспечения, особую актуальность приобретает своевременное и качественное проведение программной экспертизы. Государственные органы, муниципалитеты, министерства, ведомства, коммерческие предприятия, учреждения и организации, столкнувшиеся с необходимостью установления фактов неисполнения или ненадлежащего исполнения обязательств по контрактам на создание программного продукта, могут обратиться к нам за проведением судебной или независимой программной экспертизы.

Мы приглашаем к сотрудничеству:

• государственные органы и учреждения, осуществляющие закупки программного обеспечения и нуждающиеся в контроле качества исполнения контрактов;

• муниципальные образования, реализующие проекты цифровизации и сталкивающиеся с необходимостью оценки результатов работ;

• министерства и ведомства, реализующие крупные IT-проекты и заинтересованные в независимой оценке их результатов;

• коммерческие предприятия, заключившие договоры на разработку программного обеспечения и нуждающиеся в защите своих прав;

• разработчиков программного обеспечения, которым требуется доказать надлежащее исполнение обязательств перед заказчиком;

• юридические фирмы и адвокатские бюро, сопровождающие споры в сфере информационных технологий;

• арбитражные управляющие, нуждающиеся в оценке программных продуктов в рамках процедур банкротства;

• суды, рассматривающие дела, требующие специальных знаний в области программирования.

Мы готовы провести:

• судебную программную экспертизу по определению суда;

• досудебную (независимую) программную экспертизу по инициативе заказчика;

• рецензирование заключений других экспертных организаций;

• аудит программного обеспечения;

• оценку объёма и стоимости выполненных работ;

• оценку соответствия программного продукта техническому заданию;

• установление причин неисправностей программного обеспечения;

• выявление заимствований и нарушений лицензий;

• оценку информационной безопасности;

• оценку соответствия требованиям импортозамещения;

• иные виды исследований в области программного обеспечения.

Наши специалисты обладают необходимой квалификацией, опытом и инструментальными средствами для проведения экспертиз любой сложности. Мы гарантируем объективность, полноту и научную обоснованность выводов, соблюдение сроков, конфиденциальность, готовность защитить свои выводы в суде.

Мы открыты для сотрудничества и готовы обсудить условия проведения экспертизы с учётом особенностей каждого конкретного дела. Обращайтесь к нам — мы поможем разобраться в сложных вопросах программной экспертизы и защитить ваши законные права и интересы.