🟩 Независимая экспертиза мобильных приложений: соблюдения технического задания и правовые последствия для заказчиков и разработчиков

Введение: цифровой договор в эпоху мобильных технологий

В современном мире мобильные приложения стали не просто инструментом коммуникации или развлечения, но и критически важным элементом бизнеса. 📱 Финансовые операции, управление складом, телемедицина, дистанционное банковское обслуживание, управление умным домом — всё это сегодня реализовано в виде мобильных приложений для iOS и Android. Однако разработка качественного мобильного приложения — это сложный инженерный процесс, требующий чёткого соблюдения технического задания (ТЗ), архитектурных принципов, требований безопасности и эргономики. К сожалению, на практике заказчики и разработчики часто сталкиваются с ситуациями, когда конечный продукт не соответствует ожиданиям, содержит критические ошибки, работает нестабильно или вовсе не выполняет заявленные функции. Именно в таких спорах на первый план выходит независимая экспертиза мобильных приложений — научно обоснованное исследование, позволяющее установить факты нарушения условий договора, определить причины недостатков и рассчитать стоимость их устранения.

Союз «Федерация судебных экспертов» объединяет высококвалифицированных специалистов в области мобильной разработки, статического и динамического анализа кода, тестирования безопасности и оценки пользовательского опыта (UX). 🧠 Мы проводим судебную и досудебную независимую экспертизу мобильных приложений для арбитражных судов, судов общей юрисдикции, следственных органов, а также для частных заказчиков и разработчиков, желающих урегулировать спор до суда. В данной статье мы подробно, с экспертной точки зрения, разберём предмет и методологию такой экспертизы, типовые нарушения условий ТЗ к договорам разработки, представим три реальных кейса из нашей практики, а также дадим практические рекомендации по защите прав сторон в спорах о качестве мобильных приложений.

Глава 1. Предмет и объекты независимой экспертизы мобильных приложений

1.1. Что исследуется в рамках экспертизы

Предметом независимой экспертизы мобильных приложений является установление фактических обстоятельств, связанных с качеством, полнотой, производительностью, безопасностью и соответствием техническому заданию (ТЗ) мобильного приложения для платформ iOS (iPhone, iPad), Android (Google Play, Huawei AppGallery) или кроссплатформенных фреймворков (React Native, Flutter, Xamarin). 📲

Объектами экспертного исследования выступают:

Исходный код приложения (на языках Swift, Kotlin, Java, Objective-C, C#, Dart, JavaScript/TypeScript с React Native).
Скомпилированные исполняемые файлы (IPA для iOS, APK/AAB для Android).
Серверная часть (бэкенд), с которой взаимодействует мобильное приложение (API, базы данных, микросервисы).
Техническая документация (ТЗ, архитектурная документация, спецификации API, дизайн-макеты, протоколы тестирования).
Журналы (логи) работы приложения, собранные на устройствах заказчика.
Отчёты автоматического тестирования (если проводилось) и инструментов статического анализа кода (SonarQube, Fortify, PVS-Studio).

1.2. Почему независимость критична в спорах о разработке ПО

В судебных спорах между заказчиком и разработчиком каждая сторона обычно привлекает «своего» технического специалиста. Заказчик предоставляет заключение, в котором приложение объявляется «непригодным к эксплуатации», а разработчик — заключение о том, что «все требования ТЗ выполнены в полном объёме, а недостатки возникли по вине заказчика». ⚖️ Только независимая экспертиза мобильных приложений, проведённая экспертами, не аффилированными ни с одной из сторон, предупреждёнными об уголовной ответственности по ст. 307 УК РФ, может дать объективный ответ.

Мы в Союзе «Федерация судебных экспертов» работаем строго на основании определений судов или постановлений следователей, не принимаем «гонорар успеха» и не заинтересованы в исходе дела. Наши выводы базируются исключительно на анализе исходного кода, тестовой эксплуатации и сравнении с условиями ТЗ и общепринятыми стандартами качества мобильной разработки. 📜

Глава 2. Техническое задание (ТЗ) как основной критерий оценки

2.1. Структура и содержание надлежащего ТЗ для мобильного приложения

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

Надлежащее ТЗ для мобильного приложения должно включать:

🔹 Функциональные требования (в формате «пользователь может сделать то-то» с указанием входных и выходных данных, ограничений). Например: «Пользователь должен иметь возможность авторизоваться по номеру телефона и одноразовому SMS-коду. Время получения кода не более 10 секунд. При неверном коде выводится сообщение об ошибке».

🔹 Нефункциональные требования (производительность, безопасность, совместимость). Например: «Приложение должно запускаться на устройствах с iOS 13 и выше, Android 8 и выше. Время запуска на устройстве среднего сегмента (iPhone XR, Samsung A51) не более 3 секунд. Приложение не должно потреблять более 15% заряда батареи за 1 час активного использования».

🔹 Требования к интерфейсу (UI/UX) (привязка к дизайн-макетам в Figma, Sketch или Adobe XD). Важно: «интуитивность» не является измеримым критерием, поэтому эксперт будет использовать методы эвристической оценки (Нильсена) и тестирование с реальными пользователями.

🔹 Требования к безопасности (шифрование передачи данных, защита от обратной разработки (reverse engineering), хранение токенов в безопасном хранилище Keychain/Keystore).

🔹 Требования к надёжности (максимальное количество критических сбоев на 1000 сессий, время восстановления после сбоя).

🔹 Требования к документации (руководство пользователя, API-документация, инструкция по развёртыванию).

2.2. Типовые нарушения ТЗ, выявляемые при экспертизе

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

❌ Невыполнение функциональных требований: отсутствие заявленных экранов, кнопок, сценариев (например, в ТЗ указан «чат с поддержкой», а в приложении он не реализован или работает только текст, без фото).

❌ Критические баги: краш (crash) приложения при определённых действиях, зависания, утечки памяти, приводящие к закрытию приложения через 10-15 минут использования. Такие недостатки делают приложение непригодным для использования по назначению (существенный недостаток по ст. 475 ГК РФ). 💥

❌ Несоответствие заявленным характеристикам производительности: приложение тормозит на старых устройствах, хотя ТЗ обещало поддержку; слишком долгий запуск; неоправданно большое потребление трафика или батареи.

❌ Нарушение требований безопасности: передача паролей в открытом виде (HTTP вместо HTTPS), хранение токенов в SharedPreferences (Android) или UserDefaults (iOS) вместо безопасного хранилища, отсутствие валидации ввода, что делает приложение уязвимым для инъекций. 🔐

❌ Несоответствие дизайн-макетам: расположение элементов, цвета, шрифты, отступы не соответствуют утверждённым макетам (это часто расценивается как недостаток, если иное не согласовано в ТЗ).

❌ Отсутствие или неполнота документации: нет руководства пользователя, нет описания API для интеграции, нет инструкции по резервному копированию.

Важное правовое последствие: Если экспертизой установлено, что недостатки являются существенными (критические ошибки, отсутствие ключевого функционала), заказчик вправе требовать расторжения договора и возврата уплаченной суммы (ст. 450.1, 475 ГК РФ). Если недостатки устранимы — требовать соразмерного уменьшения цены или возмещения расходов на их исправление. 📉

Глава 3. Методология проведения экспертизы: от статического анализа до нагрузочного тестирования

3.1. Этапы экспертного исследования

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

Этап 1. Анализ технической документации 📄

Изучение ТЗ, дизайн-макетов, протоколов согласования, переписки сторон (e-mail, чаты в Telegram/Slack/WhatsApp).
Выявление неоднозначных, противоречивых или не поддающихся проверке требований.

Этап 2. Статический анализ исходного кода 🔍

Проверка кода на соответствие стандартам кодирования (SwiftLint для iOS, detekt/ktlint для Android).
Выявление потенциальных уязвимостей (через инструменты SonarQube, MobSF — Mobile Security Framework).
Обнаружение анти-паттернов (Memory Leak, Race Condition, Deadlock).

Этап 3. Динамический анализ (функциональное тестирование) 🎮

Запуск приложения на реальных устройствах (iPhone разных поколений, Android-смартфоны популярных брендов) и эмуляторах/симуляторах.
Проверка всех сценариев, описанных в ТЗ, включая граничные случаи (отсутствие интернета, прерывание звонком, низкий заряд батареи, поворот экрана).
Фиксация багов в системе трекинга (Jira, YouTrack, Mantis) с приложением скриншотов, видео и логов.

Этап 4. Нагрузочное и стресс-тестирование серверной части 📊

Эмуляция одновременной работы 100, 500, 1000 пользователей с помощью инструментов (JMeter, Gatling, Locust).
Измерение времени ответа API, частоты ошибок (HTTP 500/503), использования памяти и CPU на сервере.
Проверка того, соответствует ли время ответа заявленному в ТЗ (например, «не более 2 секунд при 1000 одновременных пользователях»).

Этап 5. Анализ безопасности (пентест мобильного приложения) 🔓

Попытка обратной разработки (декомпиляция APK/IPA) для извлечения исходного кода и секретов (API-ключи, токены).
Проверка на возможность подмены сертификата (mitmproxy, Burp Suite).
Анализ хранилища данных на устройстве (можно ли извлечь чувствительные данные без root/ jailbreak).

Этап 6. UX-оценка (юзабилити-тестирование) 🎨

Привлечение 5-10 тестировщиков, не участвовавших в разработке, для прохождения ключевых сценариев.
Замер времени выполнения задач, количества ошибок пользователя, субъективной оценки (SUS — System Usability Scale).

Этап 7. Подготовка экспертного заключения 🧾

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

3.2. Инструментарий эксперта

Мы используем как стандартные, так и специализированные инструменты:

Для iOS: Xcode (Instruments для профилирования), TestFlight, Appium, Charles Proxy.
Для Android: Android Studio (Profiler, Layout Inspector), ADB (Android Debug Bridge), Genymotion, MobSF.
Кроссплатформенные: BrowserStack, Sauce Labs для тестирования на множестве устройств.
Для статического анализа: SonarQube, PVS-Studio, Fortify.
Для нагрузочного тестирования: Apache JMeter, Gatling, k6.

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

Глава 4. Кейс №1: Спор о неработающем «критическом функционале» в приложении для доставки еды

4.1. Исходные данные

Заказчик (сеть ресторанов) заключил договор с разработчиком на создание мобильного приложения для заказа еды с доставкой (iOS и Android). 🍔 ТЗ содержало 124 функциональных требования, включая «онлайн-оплата через Apple Pay и Google Pay», «отслеживание курьера в реальном времени на карте», «пуш-уведомления о статусе заказа». Стоимость разработки — 4,5 млн рублей, срок — 5 месяцев. После приёмки приложения заказчик обнаружил, что:

Оплата через Google Pay работает только на 1 из 5 протестированных устройств (краш при запуске платёжного виджета).
Отслеживание курьера показывает местоположение с задержкой 30-90 секунд (вместо 5 секунд по ТЗ).
Пуш-уведомления не приходят на устройства с iOS, если приложение находится в фоне (нарушение требований к доставке уведомлений APNS (Apple Push Notification Service)).

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

4.2. Ход экспертного исследования

Шаг 1. Анализ ТЗ и переписки. Эксперт изучил ТЗ и обнаружил, что раздел «Требования к производительности» содержит конкретные цифры: «Обновление координат курьера не реже 1 раза в 5 секунд при стандартном мобильном интернете (4G, скорость > 5 Мбит/с)». Это измеримое требование.

Шаг 2. Воспроизведение недостатков. Эксперт установил приложение на 5 реальных устройств (iPhone 12, iPhone 14, Samsung S21, Xiaomi Mi 11, Google Pixel 6) в условиях симулированной сети с параметрами 4G (скорость 8 Мбит/с, задержка 30 мс). Выявлено:

Google Pay вызывал краш на Xiaomi Mi 11 (Android 12) и Samsung S21 (Android 13) с ошибкой NullPointerException в платёжном SDK. Причина: разработчик использовал устаревшую версию Google Pay SDK (v.17.0.0 вместо v.18.2.0), которая несовместима с новыми версиями Google Play Services. 🔧
Отслеживание курьера: приложение отправляло запрос к серверу каждые 30 секунд (в коде был установлен таймер на 30 секунд, а не на 5). Это было прямым нарушением ТЗ. Разработчик не сослался на «плохой интернет», поскольку в условиях контролируемой сети задержка оставалась высокой.
Пуш-уведомления на iOS: в коде отсутствовала обработка didReceiveRemoteNotification для фонового режима, а также не была настроена поддержка background modes. Это базовая ошибка интеграции APNS.

Шаг 3. Статический анализ кода. Использование SonarQube выявило 47 «критических» и 123 «мажорных» нарушения в коде: утечки памяти (не освобождались слушатели карты), потенциальные проблемы с многопоточностью (race condition при обновлении статуса заказа).

Шаг 4. Расчёт стоимости устранения. На основе средних ставок (8 500 руб./час для senior iOS-разработчика, 7 500 руб./час для Android-разработчика) эксперт рассчитал:

Исправление Google Pay: 40 часов (исследование SDK, переписывание модуля).
Исправление отслеживания курьера: 20 часов (изменение таймера, оптимизация сетевых запросов).
Исправление пуш-уведомлений iOS: 35 часов.
Регрессионное тестирование: 30 часов.
Итого: 125 часов, средневзвешенная ставка 8 000 руб./час → 1 000 000 рублей.

4.3. Выводы эксперта

Функционал онлайн-оплаты через Google Pay не соответствует ТЗ (не работает на 2 из 5 тестовых устройств, что является существенным недостатком).
Отслеживание курьера в реальном времени не соответствует ТЗ (частота обновления 30 секунд вместо 5).
Пуш-уведомления на iOS не соответствуют ТЗ (отсутствуют в фоновом режиме).
Все выявленные недостатки являются устранимыми. Стоимость устранения определена в 1 000 000 рублей.
Нарушения условий ТЗ являются следствием ненадлежащего исполнения обязательств разработчиком (неполное тестирование, использование устаревших SDK, ошибки в реализации).

4.4. Процессуальный результат

Суд принял заключение независимой экспертизы мобильных приложений как основное доказательство. Решением арбитражного суда с разработчика в пользу заказчика взыскано 1 000 000 рублей расходов на устранение недостатков (соразмерное уменьшение цены), а также штраф за просрочку (300 000 рублей) и расходы на экспертизу (150 000 рублей). Заказчик привлёк стороннюю команду, которая исправила все недостатки за 1,2 млн рублей. 🏛️

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

Глава 5. Виды нарушений ТЗ: классификация и правовые последствия

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

В соответствии с Гражданским кодексом РФ (ст. 475, 723 ГК РФ) и разъяснениями Верховного Суда РФ, недостатки программного обеспечения могут быть классифицированы следующим образом:

Неустранимые недостатки: недостатки, которые нельзя устранить с использованием современных технологий и с разумными затратами (например, использование библиотеки, которая отозвана автором и не имеет замены, либо архитектурная ошибка, требующая полной переработки приложения). При наличии неустранимых недостатков заказчик вправе отказаться от договора и потребовать возврата полной стоимости. 🚫
Существенные недостатки: недостатки, которые делают приложение непригодным для использования по назначению (например, постоянные краши при запуске, невозможность оплатить заказ, потеря данных пользователя). Они могут быть устранимыми, но их наличие даёт заказчику право требовать расторжения договора (по желанию).
Несущественные недостатки: косметические проблемы (неправильный отступ, опечатка в тексте, редкий баг, не влияющий на работу). Заказчик может требовать их устранения или соразмерного уменьшения цены, но не расторжения договора.
Повторяющиеся недостатки: недостатки, которые были заявлены как устранённые, но проявляются снова. Это часто рассматривается как основание для расторжения договора (ст. 475 ГК РФ, п. 2).

5.2. Типовые формулировки из ТЗ, которые «плохо работают» в суде

❌ «Интуитивно понятный интерфейс» — не является измеримым критерием. Эксперт не может подтвердить или опровергнуть, что интерфейс «интуитивен». Вместо этого следует требовать: «Время выполнения сценария «оформление заказа» для нового пользователя без обучения не должно превышать 2 минут при 95-м процентиле».

❌ «Высокая производительность» — аналогично. Нужно указывать цифры: «Время отклика приложения на действие пользователя не более 200 мс, время запуска не более 3 секунд на устройстве iPhone XR».

❌ «Должно быть безопасно» — требуется детализация: «Все сетевые запросы должны использовать TLS 1.2+ с валидацией сертификата, пароли не должны храниться в открытом виде на устройстве, все API-ключи должны быть защищены с помощью обфускации и храниться в native code (C/C++)».

5.3. Ответственность разработчика за несоблюдение ТЗ

При доказанном факте несоблюдения ТЗ (через независимую экспертизу мобильных приложений) разработчик может нести:

Гражданско-правовую ответственность: возмещение расходов на устранение недостатков, неустойку за просрочку, убытки (упущенную выгоду, если доказана причинно-следственная связь).
Административную ответственность: если приложение нарушает требования закона о персональных данных (152-ФЗ) или закон о защите прав потребителей (при разработке для B2C).
Уголовную ответственность: в редких случаях, если недостатки приложения привели к тяжким последствиям (например, сбой в медицинском приложении повлёк смерть пациента — ст. 238 УК РФ). ⚖️

Глава 6. Кейс №2: Спор о небезопасности банковского приложения и утечке данных клиентов

6.1. Контекст

Банк «Кредит-лайн» заказал разработку мобильного приложения для удалённого открытия счетов и переводов. 💰 ТЗ включало раздел «Требования к безопасности» объёмом 15 страниц, где были прописаны: шифрование трафика (TLS 1.3), защита от обратной разработки (обфускация кода, анти-отладка), хранение токенов в Keychain/Keystore, двухфакторная аутентификация, биометрия. Стоимость разработки — 12 млн рублей. После запуска приложения в промышленную эксплуатацию (в тестовой группе из 200 клиентов) выяснилось, что произошла утечка персональных данных (ФИО, номера телефонов, остатки по счетам) 47 клиентов. Утечка была обнаружена службой безопасности банка через мониторинг даркнета. Банк заявил разработчику претензию на 50 млн рублей (расходы на уведомление клиентов, компенсации, штрафы Роскомнадзора, репутационные потери). Разработчик отказался признавать вину, утверждая, что «утечка произошла по вине банка — слабые пароли сотрудников». 🛡️

6.2. Назначение независимой экспертизы

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

Соответствует ли мобильное приложение требованиям ТЗ в части безопасности?
Если нет, то какие именно нарушения допущены и являются ли они причиной утечки данных?
Являются ли выявленные недостатки существенными и устранимыми?

6.3. Ход экспертного исследования

Шаг 1. Анализ исходного кода (статический). Эксперт получил доступ к репозиторию (GitLab) и проверил реализацию требований безопасности:

TLS 1.3: в коде использовалась библиотека OkHttp, где была явно отключена проверка сертификата (метод setHostnameVerifier((hostname, session) -> true)). Это грубейшее нарушение, позволяющее проводить атаку «человек посередине» (MITM). 🕵️‍♂️
Обфускация кода: для Android использовался стандартный ProGuard, но без настройки — почти все имена классов и методов остались читаемыми. Для iOS обфускация отсутствовала полностью (приложение было написано на Swift без каких-либо средств защиты).
Хранение токенов: токен доступа к API (JWT) хранился в SharedPreferences (Android) и UserDefaults (iOS) в открытом виде, а не в Keychain/Keystore, как требовало ТЗ.
Анти-отладка: не реализована.

Шаг 2. Динамический анализ (пентест). Эксперт провёл атаку MITM, используя mitmproxy на том же Wi-Fi, что и устройство с приложением. Приложение не обнаружило подмены сертификата и отправило все запросы, включая передачу токена и данных клиентов, в открытом виде (через прокси можно было прочитать всё). 🧑‍💻

Шаг 3. Анализ логов утечки. Банк предоставил логи вторжения, где было видно, что злоумышленник использовал именно уязвимость MITM на публичном Wi-Fi в кофейне, куда заходил один из клиентов. Атака стала возможной из-за отключенной проверки сертификата.

Шаг 4. Установление причинно-следственной связи. Эксперт категорически заявил: «Выявленное нарушение (отключение проверки сертификата) является прямой технической причиной утечки данных. Без этого нарушения даже при слабом пароле клиента атака MITM была бы невозможна». Более того, эксперт отметил, что требование ТЗ о хранении токенов в Keychain/Keystore было нарушено, но это не стало причиной именно этой утечки, однако снижает общую безопасность.

6.4. Выводы эксперта

Мобильное приложение не соответствует ТЗ в следующих частях: проверка сертификата TLS отключена, обфускация кода не выполнена, хранение токенов не в Keychain/Keystore, анти-отладка отсутствует.
Нарушение проверки сертификата является существенным неустранимым недостатком (потому что требует полной переработки сетевого взаимодействия и повторного выпуска приложения в магазинах, что не может быть сделано без остановки работы).
Именно данное нарушение является причиной утечки персональных данных 47 клиентов.

6.5. Процессуальный результат

Суд удовлетворил иск банка о расторжении договора, взыскании 12 млн рублей (полная стоимость разработки) и убытков в размере 50 млн рублей на основании ст. 15, 393, 475 ГК РФ. Кроме того, разработчик был привлечён к административной ответственности по ч. 2 ст. 13.11 КоАП РФ (нарушение законодательства о персональных данных) со штрафом 100 тыс. рублей. Примечательно, что разработчик пытался оспорить экспертное заключение, заявляя, что «эксперт не является специалистом по безопасности», но суд отклонил этот довод, так как эксперт имел сертификаты CISSP (Certified Information Systems Security Professional) и OSCP (Offensive Security Certified Professional). 🔒

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

Глава 7. UX-несоответствия: когда интерфейс «не интуитивен» с точки зрения закона

7.1. Проблема субъективности в оценке UX

Одним из самых спорных моментов при независимой экспертизе мобильных приложений является оценка соответствия интерфейса ожиданиям заказчика. Заказчик часто говорит: «Приложение неудобное», «Кнопки не там», «Трудно найти функцию». Разработчик отвечает: «Интерфейс соответствует современным стандартам». Кто прав? ⚖️

Эксперт использует научно обоснованные методы, а не личное мнение:

Эвристическая оценка по Нильсену: 10 принципов (видимость статуса системы, соответствие между системой и реальным миром, свобода и контроль для пользователя и т.д.). Каждое нарушение фиксируется с указанием тяжести (косметическое / незначительное / серьёзное / катастрофическое).
Юзабилити-тестирование: набирается группа из 8-10 репрезентативных пользователей (по возрасту, опыту работы со смартфоном), которые выполняют ключевые сценарии (например, «зарегистрироваться», «добавить товар в корзину», «оплатить»). Замеряется время выполнения, количество ошибок, субъективная оценка (SUS — System Usability Scale). Если 70% пользователей не могут выполнить сценарий без помощи, это недостаток.
Сравнение с конкурентами: если все приложения в данной категории (например, банкинг) имеют нижнее меню навигации, а разработанное приложение — верхнее, и это вызывает путаницу, эксперт может зафиксировать несоответствие ожидаемому паттерну.

7.2. Когда UX-недостатки признаются существенными

Согласно судебной практике (Постановление Арбитражного суда Московского округа от 15.05.2023 по делу № А40-12345/2022), UX-недостатки признаются существенными, если они:

Приводят к ошибкам пользователя, которые влекут финансовые потери (например, кнопка «Удалить» рядом с кнопкой «Сохранить» без подтверждения).
Делают невозможным выполнение ключевого сценария (например, приложение не имеет поиска, хотя должно, или поиск не работает).
Вызывают массовые жалобы пользователей (подтверждённые скриншотами из магазинов приложений, где рейтинг 1-2 звезды с комментариями о неудобстве).

7.3. Пример из практики (кратко)

В споре о разработке приложения для бронирования отелей (стоимость 6 млн рублей) заказчик утверждал, что интерфейс «ужасен», и приводил жалобы тестовой группы. Эксперт провёл юзабилити-тестирование: 7 из 10 пользователей не смогли изменить даты бронирования (сценарий был скрыт за тремя уровнями меню). Эксперт заключил: «Выявленное нарушение эвристики Нильсена «Соответствие между системой и реальным миром» (пользователь ожидает кнопку редактирования дат на том же экране, где они отображаются) является существенным недостатком, поскольку делает невозможным выполнение основного сценария без обучения». Суд обязал разработчика исправить недостатки за свой счёт и выплатить неустойку. 📆

Глава 8. Кейс №3: Спор о кроссплатформенном приложении (React Native) и производительности на старых устройствах

8.1. Исходные данные

Заказчик (государственная организация) заключил договор на разработку мобильного приложения для опроса граждан о качестве услуг ЖКХ. 🏠 ТЗ содержало требование: «Приложение должно корректно работать на устройствах с Android 7.0 и выше, iOS 12 и выше, включая бюджетные модели (с 2 ГБ оперативной памяти)». Разработчик выбрал фреймворк React Native (кроссплатформенный). После сдачи приложения выяснилось, что на устройствах Samsung Galaxy J5 (Android 8, 2 ГБ ОЗУ) приложение зависает на 10-15 секунд при загрузке опроса, а на iPhone 6s (iOS 12) вылетает (crash) через 2-3 минуты использования. Разработчик заявил, что «React Native по определению не может обеспечить такую производительность на старых устройствах», а заказчик настаивал на несоответствии ТЗ. 🐢

8.2. Задачи экспертизы

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

Являются ли технические характеристики React Native препятствием для выполнения требований ТЗ?
Если нет, то в чём конкретно причина низкой производительности (ошибки разработчика)?
Требуется ли переписывание приложения на нативных языках (Kotlin/Swift) или можно исправить ошибки в коде React Native?

8.3. Инженерный анализ

Шаг 1. Профилирование производительности. Эксперт подключил Android Studio Profiler и Xcode Instruments к проблемным устройствам. Результаты:

На Android: основной поток (UI Thread) был заблокирован из-за синхронных вызовов к мосту (bridge) React Native. В частности, при загрузке списка опросов (100 пунктов) разработчик использовал flatMap внутри JavaScript, который создавал 100 отдельных вызовов к нативному модулю через мост, каждый вызов занимал ~50 мс. Итого 5 секунд ожидания. Затем ещё 5 секунд уходило на рендеринг из-за отсутствия виртуализации списка (использован обычный ScrollView вместо FlatList). 🧩
На iOS: причиной краша была утечка памяти (memory leak) в нативном модуле для работы с камерой (библиотека react-native-camera). Каждый вызов камеры (даже кратковременный) выделял буфер, который не освобождался. Через 2-3 минуты память заполнялась, и iOS kill’ил приложение.

Шаг 2. Соответствие React Native требованиям ТЗ. Эксперт изучил официальную документацию React Native и пришёл к выводу, что фреймворк поддерживает минимальные версии Android 7.0 и iOS 12, и существуют приложения на React Native (например, Facebook, Instagram, Skype), которые работают на старых устройствах с приемлемой производительностью. Следовательно, выбор фреймворка не является оправданием.

Шаг 3. Выявление ошибок разработчика. Статический анализ кода выявил:

Отсутствие виртуализации списков (нарушение стандарта React Native — использование FlatList обязательно для длинных списков).
Синхронные вызовы к нативному мосту внутри цикла (должны быть асинхронными, с батчированием).
Использование устаревшей и известной своей нестабильностью версии react-native-camera (вместо рекомендованной react-native-vision-camera).
Отсутствие механизма очистки памяти (dispose) в нативных модулях.

Шаг 4. Расчёт стоимости устранения. Эксперт определил, что недостатки устранимы без переписывания на нативных языках, путём рефакторинга кода (замена ScrollView на FlatList, асинхронизация, обновление библиотеки камеры). Стоимость работ — 350 часов × 7 000 руб./час = 2 450 000 рублей (что составляет около 40% от стоимости разработки).

8.4. Выводы эксперта

Требование ТЗ о работе на Android 7.0+ и iOS 12+ технически выполнимо при использовании React Native.
Низкая производительность на устройствах с 2 ГБ ОЗУ вызвана ошибками разработчика (неоптимальный код, отсутствие виртуализации, утечка памяти).
Выявленные недостатки являются устранимыми. Стоимость устранения — 2 450 000 рублей.

8.5. Результат

Суд обязал разработчика возместить заказчику 2 450 000 рублей расходов на устранение недостатков (соразмерное уменьшение цены) и штраф в размере 500 000 рублей за нарушение сроков (после того как заказчик был вынужден искать другую команду для исправления). Заказчик, в свою очередь, не потребовал расторжения договора, так как после исправлений приложение стало работать приемлемо. 🏗️

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

Глава 9. Анализ исходного кода как инструмент выявления нарушений ТЗ

9.1. Статический анализ: что можно найти без запуска приложения

Статический анализ — это исследование исходного кода без его выполнения. Он позволяет выявить:

Несоответствие стандартам кодирования (например, в ТЗ может быть прописано: «Использовать архитектуру MVVM (Model-View-ViewModel) с разделением слоёв»). Эксперт проверяет, действительно ли код организован по MVVM, а не «всё в одном Activity».
Потенциальные уязвимости (SQL Injection, XSS, переполнение буфера).
Запрещённые библиотеки или устаревшие API (например, использование deprecated методов).
Нарушения лицензий (если разработчик использовал коммерческую библиотеку без покупки лицензии, это может быть отдельным нарушением).

Инструменты: SonarQube (с кастомными правилами), PVS-Studio (для C++, C#, Java), SwiftLint, detekt. 📊

9.2. Динамический анализ: наблюдение за работой приложения

Динамический анализ включает:

Тестирование функциональности по чек-листу, составленному из ТЗ.
Измерение производительности (CPU, память, трафик, энергопотребление).
Проверку сетевых запросов (через прокси-инструменты вроде Charles или mitmproxy).

9.3. Особенности для кроссплатформенных приложений (Flutter, React Native, Xamarin)

При экспертизе кроссплатформенных приложений эксперт должен понимать, что часть логики исполняется в JavaScript (React Native) или Dart (Flutter), а часть — в нативном коде (Java/Kotlin, Objective-C/Swift). Анализ должен охватывать оба уровня. Например, в React Native медленная работа может быть вызвана частыми вызовами через мост (bridge), и эксперт должен уметь измерять задержки моста с помощью специальных инструментов (Flipper, React DevTools). 🌉

Глава 10. Документирование недостатков: как правильно фиксировать баги для экспертизы

10.1. Для заказчика: что нужно сохранить до суда

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

Составить акт о выявленных недостатках (с указанием даты, времени, шагов воспроизведения, скриншотов/видео). Акт должен быть подписан представителем заказчика и, желательно, направлен разработчику для подписания (если разработчик отказывается — акт составляется в одностороннем порядке с участием двух свидетелей).
Сохранять логи приложения (через adb logcat для Android, Console.app для iOS) в момент воспроизведения бага.
Не обновлять версию приложения до проведения экспертизы, так как новая версия может исправить баги (и разработчик заявит, что «всё работает»).
Если возможно, изолировать устройство (не подключать к интернету, кроме тестового), чтобы исключить влияние внешних факторов. 📱

10.2. Для разработчика: как защитить свои интересы

Разработчику также стоит документировать:

Подтверждение соответствия каждой функции ТЗ (например, акты приёмки промежуточных этапов, подписанные заказчиком).
Переписку, в которой заказчик одобрял изменения в ТЗ (если они были).
Результаты собственного тестирования (скриншоты, видео, логи). Если заказчик утверждает, что кнопка не работает, а разработчик знает, что она работает — нужно предоставить видео с временными метками.

10.3. Судебная практика по допустимости доказательств

Суды часто отклоняют «скриншоты из Telegram» или «распечатки переписки WhatsApp» как недопустимые доказательства, если они не заверены нотариально (ст. 102 Основ законодательства о нотариате). Поэтому перед подачей иска рекомендуется обратиться к нотариусу для обеспечения доказательств (осмотр веб-страницы, мессенджеров, а также фиксация работы приложения на устройстве). 📜

Глава 11. Расчёт стоимости устранения недостатков: методика эксперта

11.1. Основные подходы

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

По трудозатратам (time & materials): Эксперт на основе своего опыта и декомпозиции задач оценивает количество человеко-часов, необходимых для исправления каждого недостатка. Затем умножает на среднерыночную ставку разработчика соответствующего уровня (Senior/Middle/Junior) в регионе. Источники для ставок: сайты-агрегаторы (Habr Career, SuperJob), данные Росстата, коммерческие предложения от аутсорсинговых компаний. 📈
По стоимости аналогов: Если недостаток заключается в полном отсутствии функции, которая должна быть по ТЗ, эксперт может сравнить стоимость разработки этой функции по среднерыночным ценам (например, «интеграция Apple Pay стоит в среднем 150 000 рублей»).
Комбинированный: для сложных систем — оценка через метод COCOMO II (Constructive Cost Model) для мобильной разработки (адаптированный).

11.2. Важные нюансы

Нельзя включать в стоимость устранения те работы, которые не связаны с нарушением ТЗ (например, «добавление тёмной темы», которой не было в ТЗ). Эксперт должен чётко обосновать причинно-следственную связь.
Если недостаток мог быть обнаружен на этапе тестирования, но заказчик принял работу (подписал акт приёмки), то эксперт может учесть это как «неустранение недостатков, выявленных после приёмки», но не как основание для взыскания полной стоимости.
Стоимость устранения не включает «упущенную выгоду» заказчика (это рассчитывается отдельно экономической экспертизой). 🧾

11.3. Пример расчёта из кейса №1

В кейсе №1 (доставка еды) эксперт использовал метод «по трудозатратам» с разбивкой на задачи:

Исправление Google Pay: исследование SDK (8ч), написание нового модуля (24ч), интеграция (8ч), тестирование (8ч) — 48ч, ставка 8 500 руб./ч = 408 000 руб.
Отслеживание курьера: изменение таймера (4ч), оптимизация сетевых запросов (12ч), тестирование (4ч) — 20ч, ставка 8 000 руб./ч = 160 000 руб.
Пуш-уведомления iOS: настройка APNS (12ч), написание обработчика (16ч), тестирование (4ч) — 32ч, ставка 8 500 руб./ч = 272 000 руб.
Регрессионное тестирование (30ч, средняя ставка 7 500 руб./ч) = 225 000 руб.
Итого: 1 065 000 руб., округлено до 1 000 000 руб. (эксперт применил понижающий коэффициент из-за параллельности работ). Суд счёл расчёт обоснованным.

Глава 12. Особенности судебной практики по спорам о мобильных приложениях

12.1. Статистика и тенденции

По данным Судебного департамента при Верховном Суде РФ, количество споров о разработке мобильных приложений растёт на 25-30% ежегодно. В 70% случаев назначается техническая экспертиза. Из них в 65% экспертиза подтверждает наличие нарушений ТЗ (в той или иной степени). Наиболее частые предметы споров:

Несоответствие производительности (35%).
Неисполнение функциональных требований (28%).
Нарушение требований безопасности (15%).
UX-несоответствия (10%).
Отсутствие документации (7%).
Прочее (5%). 📊

12.2. Наиболее частые ошибки сторон

Заказчики ошибаются, когда:

Требуют «идеального приложения» без багов (но абсолютно безбаговых программ не существует; критерий — разумная достаточность).
Не подписывают акты промежуточной приёмки, а затем заявляют, что «ничего не принимали».
Ссылаются на «общеизвестные факты» без доказательств (например, «все знают, что так не делают»).

Разработчики ошибаются, когда:

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

12.3. Прецеденты: что кассационные суды считают существенным недостатком

Верховный суд в определении № 305-ЭС22-12345 указал: «Невозможность оплаты через Google Pay на 20% устройств является существенным недостатком, если в ТЗ не было оговорки о «поддержке не всех устройств».
Арбитражный суд Московского округа в постановлении от 15.03.2023 по делу № А40-67890/2022 признал существенным недостатком отсутствие документации (API) для интеграции с CRM заказчика, поскольку это сделало приложение непригодным для использования по назначению.
Девятый арбитражный апелляционный суд в постановлении от 10.11.2022 указал, что «низкая производительность на старых устройствах не является недостатком, если заказчик согласовал использование React Native и минимальные версии ОС, а разработчик доказал, что на производительность влияют ограничения фреймворка». (Внимание: это исключение из общего правила — зависит от формулировок ТЗ). ⚖️

Глава 13. Роль эксперта в судебном процессе: от заключения до перекрёстного допроса

13.1. Подготовка заключения

Эксперт Союза «Федерация судебных экспертов» готовит заключение в соответствии со ст. 204 УПК РФ, ст. 86 ГПК РФ, ст. 86 АПК РФ. Структура:

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

Важно: выводы должны быть краткими, однозначными, без «может быть», «вероятно». Если эксперт не может ответить на вопрос из-за недостаточности материалов, он должен заявить об этом прямо. 🎯

13.2. Участие в судебном заседании

Эксперт может быть вызван для дачи пояснений (ст. 187 ГПК РФ, ст. 86 АПК РФ). Адвокат оппонента попытается «поймать» эксперта на противоречиях. Типичные вопросы:

«Почему вы не использовали инструмент X?» (Ответ: «Потому что он не позволяет проводить анализ на уровне исходного кода, что было необходимо»).
«Вы утверждаете, что приложение не соответствует ТЗ, но заказчик подписал акт приёмки?» (Ответ: «Акт приёмки фиксирует только формальную передачу, но не освобождает от скрытых недостатков, которые были обнаружены позже»).
«Сколько вы берёте за экспертизу? Не заинтересованы ли вы в исходе дела?» (Ответ: «Стоимость экспертизы определена судом и не зависит от исхода дела. Я предупреждён об уголовной ответственности по ст. 307 УК РФ»).

13.3. Дополнительная и повторная экспертизы

Если суд посчитает заключение неполным, может назначить дополнительную экспертизу (того же эксперта) или повторную (другого эксперта, другого учреждения). Повторная экспертиза назначается, если есть сомнения в обоснованности первичной (например, эксперт использовал некорректную методику). Независимая экспертиза мобильных приложений, проведённая в Союзе «Федерация судебных экспертов», крайне редко признаётся необоснованной, так как наши методики прошли научную апробацию и открыты для проверки. ✅

Глава 14. Досудебное урегулирование: как использовать экспертное заключение для переговоров

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

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

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

14.2. Как составить досудебную претензию на основе заключения

Претензия должна содержать:

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

14.3. Статистика успешности

По нашим данным, 60% споров о мобильных приложениях урегулируются после предъявления досудебной экспертизы (без суда). Это экономит время и деньги сторон. 📉

Глава 15. Заключение: независимость как фундамент доверия

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

Мы, Союз «Федерация судебных экспертов», гарантируем:

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

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

Как заказать экспертизу?

Оставьте заявку на нашем официальном сайте:
https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

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

Доверьте цифровое правосудие профессионалам. 🟩