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

• 🔎 Суть данной экспертной деятельности заключается в выявлении и интерпретации цифровых следов, оставленных разработчиками в процессе работы над проектом. К таким следам относятся журналы систем контроля версий (таких как Git, Subversion), записи в системах управления задачами (Jira, YouTrack, Redmine), временные метки файлов в файловых системах, автоматические журналы сборки и развертывания, а также метаданные документов и чертежей. Эксперт выступает в роли цифрового криминалиста, который по крупицам собирает информацию, сопоставляет временные интервалы и восстанавливает хронологию разработки. При этом критически важно отделять автоматические процессы (например, ночные сборки, выполняемые CI/CD системами без участия человека) от непосредственно ручного труда программистов, тестировщиков и аналитиков, поскольку только последние должны учитываться при определении объема выполненных работ по договору.
• 📊 Основной сложностью в подобных экспертизах является проблема доказывания того, что предъявленный код или программный продукт был создан именно в рамках конкретного договора, а не позаимствован из открытых источников или создан до заключения контракта. Для решения этой задачи эксперты Союза «Федерация судебных экспертов» используют методы стилометрии кода — анализа уникального почерка программиста, включающего предпочтения в именовании переменных, структуре отступов, способах обработки исключений и даже частоте использования комментариев. Кроме того, применяются хеш-функции для сравнения бинарных сборок и проверки их идентичности с эталонными версиями. Комплексный подход, включающий несколько независимых методов верификации, позволяет с высокой степенью достоверности установить авторство и хронологию создания каждой функциональной части системы.
• 📅 Не менее важным аспектом является разделение объема работ по этапам жизненного цикла разработки: анализ требований, проектирование архитектуры, непосредственное кодирование, модульное тестирование, интеграционное тестирование, документирование и внедрение. Каждый из этих этапов имеет свою трудоемкость и стоимость, которые должны быть отражены в актах выполненных работ. Эксперт проверяет, не происходит ли «смешения» этапов, когда подрядчик выдает проектирование за кодирование или наоборот, чтобы искусственно завысить оплату. Для этого проводится сопоставление времени, затраченного на каждую деятельность, по данным логов активности пользователей в интегрированных средах разработки (IDE), что дает объективную картину распределения человеческих часов.
• 🌐 Отдельной областью исследования является проверка заявленного объема работ в распределенных командах, где разработчики физически находятся в разных часовых поясах. Эксперт анализирует временные штампы коммитов в системе контроля версий, сопоставляя их с заявленными рабочими графиками. Если разработчик фиксирует код в 3 часа ночи по своему местному времени, но при этом в табеле указан стандартный 8-часовой рабочий день, это может указывать либо на использование фрилансеров, либо на неучтенную сверхурочную работу, что влияет на расчет стоимости. Однако важно различать такие случаи и ситуации, когда ночные коммиты являются результатом автоматизированных процессов или плановых релизов, для чего эксперту приходится анализировать контекст каждого изменения.
• ⚡️ Компьютерно-техническая экспертиза также активно применяется при проверке миграции данных и интеграции с внешними системами. Часто подрядчик заявляет о выполнении большого объема работ по настройке API-шлюзов, трансформации данных и созданию ETL-процессов (извлечение, преобразование, загрузка). Эксперт проверяет фактическое наличие и активность этих интеграций, анализируя сетевые логи, журналы обращений к базе данных и показатели пропускной способности каналов. Если заявленный объем интеграций не подтверждается реальным сетевым трафиком или количеством обращений к внешним ресурсам, эксперт делает обоснованный вывод о завышении объемов работ, что влечет пересмотр финансовых обязательств заказчика.

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

• 📜 Экспертное исследование объемов IT-работ опирается на широкий спектр нормативных документов, включая Федеральный закон № 73-ФЗ «О государственной судебно-экспертной деятельности», а также ведомственные методические рекомендации Министерства юстиции РФ в области компьютерных экспертиз. Кроме того, применяются отраслевые стандарты в сфере программной инженерии, такие как ISO/IEC 12207 (процессы жизненного цикла программных средств) и ISO/IEC 25010 (модели качества систем и программного обеспечения). Важным элементом является использование Методики определения трудоемкости разработки программного обеспечения, адаптированной под российские реалии и основанной на функциональных точках (FP-метрика). Эксперт Союза «Федерация судебных экспертов» обязан указать в своем заключении, на какие именно нормативные акты он ссылается при проведении расчетов, чтобы обеспечить юридическую обоснованность выводов и их соответствие судебной практике.

Раздел 2. Постановка задач и формулирование вопросов суда

• 📑 Процесс начинается с тщательного изучения определения суда или постановления следователя, в которых перечислены конкретные вопросы, требующие разрешения. Типичные вопросы включают: «Соответствует ли объем фактически выполненных работ объему, заявленному в акте сдачи-приемки?», «Сколько человеко-часов фактически затрачено на разработку программного модуля X?», «Имеются ли признаки искусственного завышения объема кода (избыточное дублирование, бесполезные циклы, неиспользуемые функции)?». Эксперт должен сформулировать вопросы в своей исследовательской части максимально четко, иногда переформулируя их для большей технической точности (с уведомлением об этом суда). От правильной постановки задачи напрямую зависит глубина анализа и полнота ответов.

Раздел 3. Изучение технического задания и проектной документации

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

Раздел 4. Анализ системы контроля версий (Git, SVN, Mercurial)

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

Раздел 5. Исследование логов систем автоматической сборки и CI/CD

• 🔧 Современная разработка немыслима без систем непрерывной интеграции и доставки (Jenkins, GitLab CI, GitHub Actions). Логи этих систем хранят информацию о каждой автоматической сборке: время старта и окончания, успешность прохождения тестов, артефакты сборки. Эксперт сопоставляет даты сборок с датами коммитов, чтобы проверить, действительно ли каждое изменение кода собиралось и тестировалось, как это предусмотрено регламентом. Если в проекте заявлен большой объем работ по автоматизации, но в логах зафиксировано небольшое количество сборок, это является признаком того, что либо работы не проводились, либо они выполнялись локально (без учета в системе), что должно быть дополнительно проверено через журналы локальных машин разработчиков.

Раздел 6. Верификация активности разработчиков по журналам IDE и учетным записям

🖥️ Интегрированные среды разработки (Visual Studio, IntelliJ IDEA, VS Code) часто ведут локальные журналы активности, фиксирующие открытие файлов, сохранения, время нахождения в фокусе. Эксперт при наличии доступа к рабочим станциям разработчиков может извлечь эти данные и построить тепловые карты активности. Это позволяет отделить активные часы кодирования от пассивных (чтение документации или совещания). В судебной практике такие данные считаются высокодостоверными, так как их практически невозможно сфальсифицировать без заметных следов вмешательства. Однако эксперт должен помнить о законах о персональных данных и использовать эту информацию только в рамках судебного поручения, предварительно обезличивая данные.

Раздел 7. Анализ метаданных файлов и временных штампов

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

Раздел 8. Изучение журналов доступа к базам данных и серверам

🗄️ Для проектов с серверной частью критически важны логи доступа к базам данных (MySQL, PostgreSQL, Oracle). Эксперт запрашивает журналы запросов, временные метки и информацию о количестве выполненных операций. Если по проекту заявлена миграция данных и настройка производительности, в логах должны быть следы выполнения длительных DDL-операций (создание таблиц, индексов) или массового обновления данных. Отсутствие таких записей при наличии соответствующих пунктов в отчетных документах является грубым несоответствием и однозначно свидетельствует о завышении объемов работ. Также анализируется IP-адресация подключений, чтобы подтвердить, что работы выполнялись именно с заявленных рабочих мест.

Раздел 9. Оценка качества и полноты тестовой документации

🧪 Тестирование — неотъемлемая часть разработки, занимающая до 30–40 процентов всего времени проекта. Эксперт проверяет наличие, полноту и актуальность тестовой документации: чек-листы, тест-кейсы, отчеты о дефектах. В системах управления тестированием (TestRail, Zephyr) фиксируется время создания каждого кейса, время выполнения и статус прохождения. Если подрядчик заявляет о большом объеме тестирования, но в системе зарегистрировано лишь несколько тестовых прогонов, либо все тесты выполнены в течение одного дня, это указывает на формальное отношение к процессу. Эксперт также проверяет соответствие тестов требованиям покрытия кода — какие процентные соотношения были достигнуты, и соответствуют ли они заявленным в проектной документации.

Раздел 10. Сравнение исходного кода с открытыми репозиториями (detection of plagiarism)

🕵️ Одна из частых проблем — использование готового open-source кода без указания авторства и без адаптации под специфику заказчика, при этом выставление его как полностью оригинальной разработки. Эксперт использует специализированные инструменты (наподобие MOSS от Стэнфорда или локальные утилиты сравнения AST-деревьев) для проверки кода на плагиат и заимствования. Если обнаруживается, что 70-80 процентов кода взято из публичных репозиториев без существенных модификаций, а объем работ рассчитан как для написания с нуля, это является грубым нарушением договорных обязательств. Однако эксперт должен учитывать, что использование библиотек и фреймворков является стандартной практикой, и оценивать следует только стоимость работ по их адаптации и интеграции, а не стоимость самого кода библиотек.

Раздел 11. Анализ трудоемкости на основе сложности алгоритмов (метод функциональных точек)

📐 Для объективной оценки трудоемкости эксперты применяют метод функциональных точек, разработанный Международной организацией по функциональному размеру (IFPUG). Метод основан на подсчете внешних входов, выходов, запросов, внутренних файлов и внешних интерфейсов. Каждый элемент получает весовой коэффициент сложности (низкий, средний, высокий), после чего вычисляется общее количество функциональных точек, которое затем пересчитывается в человеко-часы по стандартным таблицам производительности (например, 10–15 функциональных точек на человеко-месяц). Этот метод позволяет получить объективную величину трудозатрат, не зависящую от субъективного мнения сторон, и является золотым стандартом в крупных судебных IT-спорах в практике Союза «Федерация судебных экспертов».

Раздел 12. Анализ заявленных и фактических метрик производительности

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

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

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

Раздел 14. Анализ времени, затраченного на исправление ошибок (баг-фиксинг)

🐞 Журналы задач (Issues) в системах трекинга содержат всю историю дефектов: время создания, время фиксации, время закрытия, количество переоткрытий. Эксперт анализирует, сколько времени ушло на исправление критических и незначительных ошибок, и сравнивает это с нормативами, принятыми в отрасли (например, критический баг должен быть исправлен за 1-2 дня, косметический — до 5 дней). Если время исправления значительно превышает нормативное, это может свидетельствовать о низкой квалификации разработчиков или о плохой архитектуре, что ведет к необоснованному завышению объемов работ (так как переделка оплачивается как новая работа). Эксперт в своем заключении отражает данное несоответствие с приложением таблиц расчета отклонений.

Раздел 15. Исследование метрик повторного использования кода (code reuse)

🔄 Повторное использование ранее написанных модулей — это экономически эффективная практика, но она должна быть отражена в снижении стоимости конкретной задачи. Эксперт проводит статический анализ кода на наличие дублирующихся блоков (с помощью инструментов PMD, SonarQube, Clone Detective). Если обнаруживается, что 30-40 процентов кода является копией других модулей проекта или предыдущих проектов подрядчика, то трудоемкость разработки должна быть пересчитана с понижающим коэффициентом. В отчете эксперт детально описывает каждый обнаруженный случай дублирования, оценивает затраты на написание дублируемого кода и вычитает их из общего объема заявленных работ, приводя соответствующую таблицу пересчета.

Раздел 16. Оценка сложности интеграции с внешними системами и API

🔗 Современные системы редко существуют в изоляции; они интегрируются с платежными шлюзами, CRM-системами, сервисами рассылок и государственными порталами. Эксперт проверяет логи обращений к внешним API: сколько уникальных эндпоинтов было задействовано, каков объем переданных данных, настроены ли механизмы повторных попыток и обработки ошибок. Если по документации заявлена интеграция с 20 внешними сервисами, а в логах фиксируются обращения только к 5, то это грубое несоответствие. Эксперт строит диаграммы сетевого взаимодействия и сравнивает их с проектными схемами, указывая на отсутствующие звенья. Это особенно важно в судебных делах, где цена вопроса может составлять миллионы рублей.

Раздел 17. Проверка согласованности версий и релизных циклов

📦 Процесс разработки обычно организован в виде релизных циклов (спринтов). Эксперт анализирует историю релизных меток в системе контроля версий, планы релизов в Jira и фактические даты выкаток на стейджинг (промежуточный) и продакшен-серверы. Несоответствие между плановыми и фактическими датами, а также наличие «горячих» исправлений вне очереди может указывать на низкое качество планирования или на то, что работы выполнялись рывками, что нарушает стандартные циклы и может свидетельствовать о привлечении неквалифицированных кадров. Эксперт фиксирует все отклонения в графике работ и анализирует их влияние на итоговый объем.

Раздел 18. Исследование логов безопасности и аудита доступа

🔐 Для систем с высокими требованиями безопасности (банковские, медицинские) наличие логов доступа является обязательным. Эксперт анализирует, кто, когда и с каких IP-адресов заходил на сервера разработки. Если в актах указано, что работы выполнялись командой из 5 разработчиков, а в логах фигурирует только 2 уникальных пользователя, это явное несоответствие. Кроме того, эксперт проверяет наличие записей о попытках несанкционированного доступа, которые могли бы указывать на взлом и фальсификацию данных. Данный раздел особенно важен при расследовании инсайдерских инцидентов, связанных с IT-подрядчиками.

Раздел 19. Экономический анализ стоимости человеко-часов в контексте региона

💲 Даже при подтверждении объема работ возникает вопрос о стоимости часа. Эксперт не является ценообразователем, но он может провести сравнительный анализ заявленной стоимости с рыночной стоимостью аналогичных услуг в данном регионе, используя данные сайтов по поиску работы и рейтинговые обзоры зарплат (например, Хабр Карьера, HeadHunter). Если стоимость заявленного часа в 2-3 раза превышает среднерыночную для специалистов соответствующего уровня, это является основанием для рекомендации суду пересмотреть финансовую часть. Эксперт оформляет этот анализ как отдельный раздел, который учитывается при вынесении решения о разумности и обоснованности расходов.

Раздел 20. Применение методов машинного обучения для классификации коммитов

🤖 В крупных проектах с тысячами коммитов ручной анализ невозможен. Эксперты Союза «Федерация судебных экспертов» используют специализированные алгоритмы машинного обучения для автоматической категоризации коммитов: «рефакторинг», «новый функционал», «исправление ошибок», «обновление документации», «изменение конфигурации». Это позволяет агрегировать данные по категориям и видеть, какой тип работ преобладает. Если в проекте заявлен огромный объем нового функционала, но модель классифицирует большинство коммитов как «обновление документации» или «рефакторинг», это является сильным доказательством завышения. Алгоритмы обучаются на заранее размеченных данных и проходят валидацию, что делает их методологически обоснованными.

Раздел 21. Анализ коммуникационной активности в переписке и чатах

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

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

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

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

Кейс 1. Спор о завышении объема работ по разработке CRM-системы для логистической компании
Логистический оператор заключил договор на разработку кастомной CRM-системы с интеграцией 1С и транспортной биржей. Стоимость работ составила 18 миллионов рублей, и подрядчик представил акты с детализацией в 4500 человеко-часов. Заказчик заподозрил завышение и обратился в Союз «Федерация судебных экспертов». Эксперты выполнили полный анализ репозитория Git и обнаружили, что фактическое число коммитов от основных разработчиков составляет всего 320, а среднее количество измененных строк на коммит не превышает 15, что характерно для начальной стадии или косметических правок. Более того, в логах Jira было выявлено, что 40 процентов заведенных задач были закрыты с комментарием «дублируется» или «отложено». Эксперты применили метод функциональных точек и выяснили, что для заявленной функциональности достаточно 2100 человеко-часов при средней производительности команды. Дополнительно был проведен анализ исходного кода на предмет плагиата: 65 процентов модулей оказались скопированы из open-source проекта с минимальными изменениями. Эксперты подготовили детальное заключение с таблицами пересчета, где стоимость была снижена до 9,2 миллионов рублей. Суд принял это заключение как основу для решения, а подрядчик был обязан вернуть излишне уплаченную сумму, а также понес судебные издержки.

Кейс 2. Определение объема работ по мобильному приложению при отсутствии системы контроля версий
В небольшом стартапе разработка мобильного приложения для доставки еды велась без использования Git (по требованию заказчика, считавшего это излишним). После расторжения договора возник спор о том, сколько же реально было сделано, так как подрядчик требовал оплаты за «полный цикл», а заказчик утверждал, что приложение наполовину сырое. Эксперты Союза «Федерация судебных экспертов» столкнулись с отсутствием истории коммитов, но вместо этого провели исследование временных меток файлов APK-сборок, обнаруженных на сервере разработчика, а также логов Firebase Crashlytics, где фиксировались сессии пользователей. Оказалось, что первая сборка была сгенерирована только через 4 месяца после старта проекта, а не через 2 недели, как утверждал подрядчик. Также эксперты проанализировали XML-макеты интерфейсов: многие экраны содержали заглушки (текст-плейсхолдеры), что указывает на незавершенность. С помощью статического анализа было подсчитано количество конечных точек API, фактически задействованных в приложении (их оказалось 8 вместо заявленных 18). В своем заключении эксперты привели график фактической активности, основанный на датах модификации файлов на сервере, и сделали вывод, что реальный объем выполненных работ составляет не более 65 процентов от заявленного. Суд назначил выплату в размере 1,8 миллиона рублей вместо затребованных 3 миллионов, что устроило обе стороны.

Кейс 3. Спор о выполненных работах по миграции данных и репликации баз данных для банка
Банк-клиент заказал миграцию своей клиентской базы из устаревшей СУБД в современное облачное хранилище с настройкой синхронной репликации, объем работ был оценен в 5 миллионов рублей. Однако после завершения проекта производительность упала, и банк обратился в Союз «Федерация судебных экспертов» с подозрением, что миграция была выполнена не в полном объеме. Эксперты запросили у обеих сторон полные логи дампов и репликаций. Анализ показал, что полный бэкап исходной базы был создан однократно, а инкрементальные бэкапы за весь период разработки отсутствовали в журналах. Более того, были запрошены логи сетевого трафика на порты репликации: за 3 месяца работы зафиксировано всего 12 часов активного трафика, тогда как по регламенту эта операция должна занимать не менее 120 часов из-за большого объема данных (2 терабайта). Эксперты выявили, что репликация была настроена только на уровне схемы таблиц, без переноса хранимых процедур и триггеров, которые составляли ключевую бизнес-логику. В итоге был произведен перерасчет: фактическая стоимость выполненных работ по миграции без полноценной репликации была определена как 1,2 миллиона рублей, а оставшиеся 3,8 миллиона подлежали возврату. Это заключение было подкреплено скриншотами логов и сравнительной таблицей нормативов времени для операций такого объема.

Кейс 4. Оценка работ по разработке чат-бота с искусственным интеллектом (на базе NLP)
Консалтинговая фирма заказала разработку интеллектуального чат-бота для поддержки клиентов, способного обрабатывать сложные запросы с использованием библиотек глубокого обучения. Подрядчик сдал работу за 6 месяцев, выставив акт на 8 тысяч человеко-часов. Однако после внедрения бот показал уровень понимания запросов всего в 60 процентов, а не 95, как было в ТЗ. Эксперты Союза «Федерация судебных экспертов» провели исследование репозитория обученных моделей (весовых коэффициентов нейросетей). Оказалось, что обучение производилось только на одном датасете размером 5 тысяч фраз, тогда как в ТЗ было оговорено использование датасета на 50 тысяч фраз. В логах обучения, сохраненных в TensorBoard, эксперты увидели, что обучение остановилось на 3-й эпохе, хотя требовалось не менее 20 для достижения заявленного качества. Более того, код содержал готовые решения из библиотеки Rasa, адаптированные лишь поверхностно. Эксперты применили метод COCOMO II для оценки трудоемкости и получили значение в 2200 человеко-часов на написание адаптационного слоя и интеграцию. Суд принял экспертное заключение, снизив сумму выплаты до 2,6 миллиона рублей, а оставшаяся часть была признана необоснованным обогащением.

Кейс 5. Анализ работ по созданию корпоративного портала с искусственным завышением строк кода
Подрядчик представил акты, где объем кода составлял 250 тысяч строк, заявив о выдающейся сложности. Заказчик заподозрил накрутку. Эксперт Союза «Федерация судебных экспертов» выполнил глубокий статический анализ с помощью инструмента SonarQube. Выяснилось, что более 70 тысяч строк являются автоматически сгенерированными классами ORM (Object-Relational Mapping), которые генерируются утилитами за секунды и не требуют ручного программирования. Еще 50 тысяч строк — это многочисленные комментарии на иностранном языке, скопированные из туториалов, и пустые строки. Очищенный от этого «шума» объем уникального осмысленного кода составил всего 60 тысяч строк, что соответствует 4-месячной работе одного разработчика, а не команды из 5 человек на 8 месяцев. Эксперт также проанализировал структуру базы данных: она содержала таблицы, которые нигде не используются в коде, что является классическим признаком «мусора», добавляемого для объема. В заключении был произведен пересчет трудозатрат с использованием метрики «действительный строковый код» (Logical SLOC), и общая стоимость была снижена на 40 процентов. Суд согласился с доводами эксперта, и подрядчик был обязан выплатить разницу в виде компенсации заказчику.

Раздел 24. Оформление экспертного заключения и его ключевые элементы

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

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

⚠️ Для подрядчика игнорирование выводов объективной компьютерно-технической экспертизы грозит не только финансовыми потерями (возврат переплаты, штрафы), но и репутационными рисками, а также возможным включением в реестр недобросовестных поставщиков, что закрывает доступ к государственным тендерам в будущем. Для заказчика несвоевременное заказ экспертизы или ее отсутствие может привести к переплате, списанию средств и отсутствию рычагов влияния на недобросовестного исполнителя. Именно поэтому своевременное обращение к профессиональным экспертам Союза «Федерация судебных экспертов» является не просто юридической формальностью, а стратегически важным шагом, позволяющим защитить свои интересы и восстановить справедливость в сфере высоких технологий. Цифровые следы не лгут, но для их расшифровки нужна квалификация и опыт, которыми обладает исключительно наша команда.

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

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте ✅ https://bneks.ru