📌 Введение
- IT-экспертиза качества разработки системы лояльности представляет собой комплексное исследование программного обеспечения, архитектуры, исходного кода, баз данных, интеграций и технической документации, направленное на установление соответствия созданной системы условиям договора, техническому заданию, заявленной функциональности и требованиям к надёжности. 💻🔎
- Система лояльности может использоваться для начисления бонусов, предоставления скидок, формирования персональных предложений, присвоения клиентских уровней, выпуска купонов, проведения акций и анализа покупательской активности. Она может работать как самостоятельное приложение либо быть частью интернет-магазина, кассовой системы, CRM, мобильного приложения или корпоративной платформы.
Объектом экспертизы может быть как полностью завершённая система, так и отдельный модуль:
▪️ регистрация участников;
▪️ выпуск виртуальных карт;
▪️ начисление бонусов;
▪️ списание баллов;
▪️ расчёт скидок;
▪️ управление уровнями клиентов;
▪️ обработка возвратов;
▪️ проведение маркетинговых акций;
▪️ интеграция с кассами;
▪️ обмен данными с интернет-магазином;
▪️ личный кабинет;
▪️ мобильное приложение;
▪️ административная панель;
▪️ аналитическая отчётность.
Необходимость экспертизы возникает, если заказчик считает, что исполнитель нарушил сроки, не реализовал часть функций, допустил критические ошибки, передал нестабильный продукт или создал систему, которую невозможно полноценно использовать в бизнесе. Исполнитель, напротив, может утверждать, что работы завершены, а проблемы связаны с неправильной эксплуатацией, изменением требований, действиями сотрудников заказчика или неисправностью сторонних сервисов.
Особенно сложными являются споры, в которых формально основные экраны и функции существуют, но система неправильно рассчитывает бонусы, допускает двойное списание, теряет транзакции, медленно обрабатывает операции или не обеспечивает согласованность данных между кассами, сайтом и мобильным приложением.
IT-эксперт не определяет юридическую виновность заказчика, разработчика, интегратора или оператора системы. Он отвечает на технические вопросы:
▪️ какие функции фактически реализованы;
▪️ соответствует ли продукт техническому заданию;
▪️ имеются ли ошибки в программном коде;
▪️ правильно ли организованы интеграции;
▪️ обеспечивается ли защита данных;
▪️ возможно ли промышленное использование системы;
▪️ какие недостатки требуют устранения;
▪️ каков объём фактически выполненных работ. ⚖️
Наиболее объективное исследование проводится при наличии исходного кода, репозитория, базы данных, журналов событий, проектной документации, тестовых сценариев и доступа к рабочей или резервной среде. Исследование только пользовательского интерфейса не позволяет полноценно установить причины ошибок и оценить качество внутренней реализации.
До начала экспертизы не рекомендуется удалять журналы, переустанавливать серверы, обновлять программное обеспечение или вносить изменения в исходный код без фиксации. Необходимо создать резервные копии и сохранить контрольные версии исследуемых материалов.
Значительный опыт проведения подобных исследований накоплен специалистами Союза «Федерация судебных экспертов», которые выполняют независимые и судебные IT-экспертизы программных продуктов, информационных систем, мобильных приложений, баз данных и интеграционных решений. 📚
📖 Раздел 1. Когда требуется экспертиза системы лояльности
Экспертиза необходима, если между заказчиком и разработчиком возникли разногласия относительно объёма, качества или результата выполненных работ.
Наиболее распространённые основания:
▪️ система не соответствует техническому заданию;
▪️ часть функций отсутствует;
▪️ бонусы начисляются неправильно;
▪️ баллы списываются несколько раз;
▪️ не учитываются возвраты;
▪️ возникают отрицательные бонусные балансы;
▪️ данные между кассами и сайтом расходятся;
▪️ клиенты получают неправильный уровень;
▪️ персональные предложения формируются с ошибками;
▪️ система работает слишком медленно;
▪️ приложение регулярно становится недоступным;
▪️ интеграции работают нестабильно;
▪️ отсутствует заявленная отчётность;
▪️ разработчик не передал исходный код;
▪️ невозможно продолжить разработку силами другой команды;
▪️ документация отсутствует или не соответствует системе;
▪️ возник спор о проценте готовности;
▪️ требуется определить стоимость устранения недостатков;
▪️ дело рассматривается в суде.
Экспертиза может потребоваться и после приёмки работ, если скрытые ошибки проявились только при массовой эксплуатации.
Например, система может корректно работать на тестовых данных, но при одновременном обращении тысяч пользователей возникают блокировки, дублирование операций и потеря бонусных транзакций.
📂 Раздел 2. Какие компоненты исследуются
Система лояльности обычно состоит из нескольких взаимосвязанных компонентов.
Эксперт может исследовать:
▪️ серверную часть;
▪️ пользовательский интерфейс;
▪️ административную панель;
▪️ мобильное приложение;
▪️ веб-приложение;
▪️ базу данных;
▪️ программные интерфейсы;
▪️ интеграционные модули;
▪️ механизм авторизации;
▪️ расчёт бонусов;
▪️ обработку скидок;
▪️ управление акциями;
▪️ модуль сегментации;
▪️ отчётность;
▪️ журналирование;
▪️ систему уведомлений;
▪️ инфраструктуру развёртывания;
▪️ систему резервного копирования;
▪️ средства мониторинга;
▪️ техническую документацию.
Если система интегрирована с внешними сервисами, дополнительно исследуются:
▪️ кассовое программное обеспечение;
▪️ интернет-магазин;
▪️ CRM;
▪️ ERP;
▪️ платёжные сервисы;
▪️ мобильное приложение;
▪️ сервис отправки сообщений;
▪️ программа складского учёта;
▪️ аналитическая платформа;
▪️ система идентификации клиентов.
Ошибка может находиться не в основном модуле лояльности, а в механизме обмена данными с другим продуктом. Поэтому компоненты необходимо исследовать как единую информационную систему.
📑 Раздел 3. Какие документы необходимо предоставить эксперту
Для объективного исследования желательно подготовить полный комплект договорных и технических материалов.
Обычно предоставляются:
▪️ договор разработки;
▪️ техническое задание;
▪️ приложения к договору;
▪️ спецификации;
▪️ календарный план;
▪️ смета;
▪️ описание этапов;
▪️ протоколы встреч;
▪️ дополнительные соглашения;
▪️ пользовательские сценарии;
▪️ требования к интеграциям;
▪️ архитектурная документация;
▪️ дизайн-макеты;
▪️ схема базы данных;
▪️ документация программных интерфейсов;
▪️ тестовые сценарии;
▪️ отчёты о тестировании;
▪️ акты выполненных работ;
▪️ акты приёмки;
▪️ перечни замечаний;
▪️ отчёты об ошибках;
▪️ переписка сторон;
▪️ документы об изменении требований;
▪️ сведения о доступах;
▪️ материалы судебного дела.
Особое значение имеет актуальная редакция технического задания. В ходе проекта требования часто дополняются через переписку, протоколы встреч и задачи в системе управления разработкой.
Эксперт должен установить, какие изменения были согласованы, а какие представляли собой односторонние пожелания одной из сторон.
📝 Раздел 4. Значение технического задания
Техническое задание является основным документом для оценки соответствия результата.
В нём желательно определить:
▪️ цели создания системы;
▪️ категории пользователей;
▪️ функциональные модули;
▪️ правила начисления бонусов;
▪️ правила списания;
▪️ срок действия баллов;
▪️ порядок возврата;
▪️ уровни лояльности;
▪️ механизмы идентификации клиента;
▪️ правила проведения акций;
▪️ требования к интерфейсу;
▪️ интеграции;
▪️ производительность;
▪️ отказоустойчивость;
▪️ безопасность;
▪️ отчётность;
▪️ порядок приёмки;
▪️ критерии готовности.
Если требования сформулированы расплывчато, например «создать современную и удобную систему», установить техническое соответствие значительно сложнее.
Чем точнее описаны формулы, сценарии и ожидаемые результаты, тем объективнее эксперт может проверить их реализацию.
🎯 Раздел 5. Проверка бизнес-логики программы лояльности
Бизнес-логика определяет, как система рассчитывает бонусы, скидки и клиентские уровни.
Эксперт проверяет:
▪️ формулы начисления;
▪️ правила округления;
▪️ минимальную сумму покупки;
▪️ максимальный размер начисления;
▪️ ограничение списания;
▪️ приоритет скидок;
▪️ совместимость акций;
▪️ сроки действия бонусов;
▪️ дату сгорания;
▪️ возврат товаров;
▪️ отмену покупки;
▪️ частичный возврат;
▪️ обмен товаров;
▪️ ручные корректировки;
▪️ перенос баланса;
▪️ начисление приветственных бонусов;
▪️ изменение клиентского уровня.
Особенно важны пограничные сценарии.
Например:
▪️ покупка совершена в последний день акции;
▪️ возврат оформлен после сгорания бонусов;
▪️ чек частично оплачен баллами;
▪️ клиент одновременно участвует в нескольких программах;
▪️ заказ разделён на несколько доставок;
▪️ покупка отменена после начисления бонусов;
▪️ операция повторно поступила из кассы.
Ошибки в таких сценариях могут приводить к финансовым потерям, конфликтам с клиентами и искажению бухгалтерской или управленческой отчётности.
💳 Раздел 6. Экспертиза начисления и списания бонусов
Эксперт исследует полный жизненный цикл бонусной операции.
Проверяются:
▪️ момент создания транзакции;
▪️ основание начисления;
▪️ сумма покупки;
▪️ применённый коэффициент;
▪️ срок активации;
▪️ статус баллов;
▪️ списание;
▪️ резервирование;
▪️ отмена;
▪️ возврат;
▪️ восстановление;
▪️ сгорание;
▪️ ручная корректировка.
Система должна обеспечивать прослеживаемость каждой операции.
Для каждой транзакции желательно иметь:
▪️ уникальный идентификатор;
▪️ дату и время;
▪️ клиента;
▪️ основание;
▪️ сумму;
▪️ статус;
▪️ источник;
▪️ связанный заказ или чек;
▪️ пользователя либо сервис, выполнивший действие.
Если бонусный баланс хранится только как итоговое число без истории операций, установить происхождение расхождений и восстановить корректный баланс значительно сложнее.
🔄 Раздел 7. Обработка возвратов и отмен
Возвраты являются одним из наиболее сложных процессов в системе лояльности.
Возможные ошибки:
▪️ бонусы не списываются после возврата;
▪️ списанные баллы не возвращаются клиенту;
▪️ возврат учитывается дважды;
▪️ частичный возврат отменяет все начисление;
▪️ система не учитывает скидку;
▪️ возвращается неправильное количество баллов;
▪️ операция выполняется при закрытом бонусном счёте;
▪️ возврат из кассы не поступает в систему;
▪️ отмена и возврат обрабатываются одинаково.
Эксперт моделирует разные сценарии и сравнивает фактический результат с согласованными правилами.
Необходимо учитывать, что технически возврат может поступать от кассовой системы, интернет-магазина или оператора вручную. Ошибка может возникать на любом этапе обмена.
🔗 Раздел 8. Проверка интеграций
Система лояльности редко работает изолированно.
Эксперт проверяет интеграцию с:
▪️ кассовыми системами;
▪️ интернет-магазином;
▪️ CRM;
▪️ мобильным приложением;
▪️ программой складского учёта;
▪️ системой управления заказами;
▪️ сервисами отправки сообщений;
▪️ аналитикой;
▪️ платёжными сервисами;
▪️ партнёрскими платформами.
Исследуются:
▪️ формат сообщений;
▪️ обязательные поля;
▪️ авторизация;
▪️ обработка ошибок;
▪️ повторная отправка;
▪️ защита от дублирования;
▪️ очереди сообщений;
▪️ тайм-ауты;
▪️ синхронизация;
▪️ журналирование;
▪️ совместимость версий.
Типичная проблема возникает, когда внешний сервис повторно отправляет сообщение после временной ошибки, а система лояльности воспринимает его как новую покупку и повторно начисляет бонусы.
Для предотвращения таких ситуаций необходимо использовать уникальные идентификаторы и механизм идемпотентной обработки операций.
🗄️ Раздел 9. Экспертиза базы данных
База данных содержит сведения о клиентах, бонусных счетах, операциях, акциях и настройках.
Эксперт исследует:
▪️ структуру таблиц;
▪️ связи;
▪️ типы данных;
▪️ индексы;
▪️ ограничения;
▪️ уникальность;
▪️ транзакционность;
▪️ журнал изменений;
▪️ резервное копирование;
▪️ миграции;
▪️ производительность запросов;
▪️ целостность данных.
Возможные дефекты:
▪️ дублирование клиентов;
▪️ несколько бонусных счетов на одного пользователя;
▪️ отсутствие связи между заказом и начислением;
▪️ отрицательные балансы;
▪️ потеря транзакций;
▪️ неверные временные зоны;
▪️ ошибки округления;
▪️ отсутствие ограничений;
▪️ несогласованность таблиц;
▪️ медленные запросы.
Если операции изменения баланса выполняются без полноценной транзакции, сбой между отдельными этапами может привести к частично сохранённым данным.
Например, запись о списании создаётся, но общий баланс не обновляется либо изменяется дважды.
🧑💻 Раздел 10. Исследование исходного кода
Анализ исходного кода позволяет установить качество внутренней реализации и причины ошибок.
Эксперт проверяет:
▪️ структуру проекта;
▪️ читаемость;
▪️ модульность;
▪️ повторение кода;
▪️ обработку ошибок;
▪️ журналирование;
▪️ работу с базой данных;
▪️ защиту от повторных операций;
▪️ проверку входных данных;
▪️ использование библиотек;
▪️ наличие временных решений;
▪️ тестируемость;
▪️ комментарии;
▪️ соблюдение архитектурных принципов.
Само наличие неидеального или стилистически неоднородного кода не всегда означает ненадлежащее качество результата.
Эксперт должен установить, приводит ли конкретный недостаток к:
▪️ ошибкам;
▪️ нестабильности;
▪️ невозможности сопровождения;
▪️ угрозам безопасности;
▪️ чрезмерной сложности развития;
▪️ невыполнению условий договора.
Если договор предусматривает передачу промышленного продукта с возможностью дальнейшего сопровождения, хаотичная структура и отсутствие документации могут иметь существенное значение.
📚 Раздел 11. Репозиторий и история разработки
Система контроля версий позволяет установить:
▪️ кто вносил изменения;
▪️ когда они были внесены;
▪️ какие функции реализовывались;
▪️ исправлялись ли ошибки;
▪️ существовали ли отдельные ветки;
▪️ какая версия передана заказчику;
▪️ какие изменения появились после приёмки;
▪️ были ли удалены отдельные модули.
Эксперту могут предоставляться:
▪️ копия репозитория;
▪️ история изменений;
▪️ журналы сборок;
▪️ запросы на слияние;
▪️ комментарии разработчиков;
▪️ метки версий;
▪️ сведения о релизах;
▪️ задачи, связанные с изменениями.
История разработки помогает определить фактическую готовность системы на конкретную дату.
Например, функция могла присутствовать в демонстрационной версии, но быть удалена из релиза из-за критических ошибок.
🧪 Раздел 12. Проверка тестирования
Эксперт оценивает, проводилось ли тестирование и насколько оно охватывало значимые сценарии.
Исследуются:
▪️ модульные тесты;
▪️ интеграционные тесты;
▪️ функциональные сценарии;
▪️ приёмочные испытания;
▪️ нагрузочные тесты;
▪️ проверки безопасности;
▪️ регрессионное тестирование;
▪️ отчёты об ошибках;
▪️ протоколы приёмки;
▪️ тестовые данные.
Недостаточный набор тестов не всегда сам по себе доказывает дефект результата. Однако отсутствие проверки критических финансовых сценариев может свидетельствовать о ненадлежащем процессе разработки.
Особое значение имеют тесты:
▪️ двойного списания;
▪️ повторной доставки сообщений;
▪️ параллельных операций;
▪️ возвратов;
▪️ сгорания баллов;
▪️ изменения уровня клиента;
▪️ восстановления после сбоя;
▪️ массового начисления.
📈 Раздел 13. Нагрузочное тестирование
Система лояльности может работать корректно при малом числе пользователей, но становиться нестабильной в период массовых акций.
Эксперт проверяет:
▪️ количество одновременных запросов;
▪️ среднее время ответа;
▪️ максимальное время ответа;
▪️ процент ошибок;
▪️ нагрузку на базу данных;
▪️ использование процессора;
▪️ использование памяти;
▪️ очереди;
▪️ блокировки;
▪️ скорость обработки транзакций.
Особенно важны сценарии:
▪️ массовая распродажа;
▪️ начисление бонусов после рекламной кампании;
▪️ одновременная работа большого числа касс;
▪️ массовая отправка уведомлений;
▪️ сгорание бонусов по расписанию;
▪️ формирование крупного отчёта.
Если в техническом задании установлены показатели производительности, эксперт сравнивает фактические результаты с этими значениями.
При отсутствии конкретных цифр оценка проводится с учётом назначения системы и ожидаемого масштаба эксплуатации.
🛡️ Раздел 14. Информационная безопасность
Система лояльности может содержать персональные данные, историю покупок и бонусные активы клиентов.
Эксперт проверяет:
▪️ механизм авторизации;
▪️ разграничение прав;
▪️ защиту паролей;
▪️ шифрование соединения;
▪️ безопасность программных интерфейсов;
▪️ защиту токенов;
▪️ журнал доступа;
▪️ действия администраторов;
▪️ ограничение попыток входа;
▪️ защиту от подбора;
▪️ резервное копирование;
▪️ удаление данных;
▪️ управление секретами.
Возможные риски:
▪️ просмотр чужого бонусного счёта;
▪️ изменение баланса без полномочий;
▪️ массовое начисление баллов;
▪️ выгрузка клиентской базы;
▪️ использование общего административного пароля;
▪️ отсутствие журнала действий;
▪️ подмена запросов;
▪️ несанкционированное применение купонов.
Если бонусы имеют фактическую денежную ценность, отсутствие должной защиты может привести к прямым финансовым потерям.
👥 Раздел 15. Управление клиентскими профилями
Эксперт исследует:
▪️ регистрацию;
▪️ подтверждение телефона или электронной почты;
▪️ объединение профилей;
▪️ изменение контактных данных;
▪️ блокировку;
▪️ удаление;
▪️ восстановление;
▪️ перенос баланса;
▪️ присоединение карты;
▪️ идентификацию на кассе.
Частая проблема — создание нескольких аккаунтов одного клиента из-за различного написания номера телефона, адреса электронной почты или использования разных каналов регистрации.
Если система не умеет корректно объединять профили, клиент теряет часть истории и бонусов.
Объединение также должно предотвращать ошибочное присвоение чужого баланса и сохранять историю всех операций.
📊 Раздел 16. Уровни лояльности и сегментация
Система может присваивать клиенту статус в зависимости от:
▪️ суммы покупок;
▪️ количества заказов;
▪️ периода активности;
▪️ категории товаров;
▪️ участия в акциях;
▪️ индивидуальных критериев.
Эксперт проверяет:
▪️ правильность расчётного периода;
▪️ момент перехода;
▪️ понижение уровня;
▪️ сохранение статуса;
▪️ обработку возвратов;
▪️ исключение отменённых заказов;
▪️ временные зоны;
▪️ массовый перерасчёт.
Ошибка может возникнуть, если система считает календарный год вместо скользящего периода либо не исключает возвращённые товары.
Сегментация должна использовать актуальные и согласованные данные. Если информация обновляется с задержкой, клиент может получить предложение, не соответствующее его фактическому поведению.
🎟️ Раздел 17. Купоны, промокоды и маркетинговые акции
Эксперт проверяет:
▪️ генерацию кодов;
▪️ уникальность;
▪️ срок действия;
▪️ ограничения;
▪️ количество применений;
▪️ привязку к клиенту;
▪️ совместимость со скидками;
▪️ минимальную сумму;
▪️ категорию товаров;
▪️ отмену;
▪️ восстановление после возврата;
▪️ защиту от перебора.
Возможные ошибки:
▪️ один купон применяется несколько раз;
▪️ код действует после окончания акции;
▪️ скидка применяется к исключённым товарам;
▪️ промокод используется другим клиентом;
▪️ купон не восстанавливается после отмены;
▪️ несколько скидок суммируются вопреки правилам;
▪️ массовая генерация создаёт повторяющиеся коды.
Эксперт сопоставляет фактическое поведение с правилами маркетинговой кампании и техническими требованиями.
📱 Раздел 18. Мобильное приложение и личный кабинет
Если программа лояльности доступна клиенту через приложение или сайт, исследуются:
▪️ регистрация;
▪️ отображение баланса;
▪️ история операций;
▪️ виртуальная карта;
▪️ штрихкод или QR-код;
▪️ персональные предложения;
▪️ уведомления;
▪️ изменение профиля;
▪️ восстановление доступа;
▪️ работа без стабильного интернета.
Типичные недостатки:
▪️ баланс обновляется с задержкой;
▪️ операции отображаются не полностью;
▪️ приложение показывает старый уровень;
▪️ QR-код не принимается кассой;
▪️ пользователь видит чужие данные;
▪️ уведомления направляются неправильному адресату;
▪️ приложение регулярно завершает работу с ошибкой.
Эксперт проверяет не только внешний вид, но и обмен приложения с сервером.
📨 Раздел 19. Уведомления клиентам
Система может отправлять:
▪️ электронные письма;
▪️ сообщения;
▪️ push-уведомления;
▪️ сообщения в мессенджерах;
▪️ сервисные уведомления.
Проверяются:
▪️ основание отправки;
▪️ получатель;
▪️ содержимое;
▪️ время;
▪️ защита от повторной отправки;
▪️ отказ пользователя;
▪️ очередь;
▪️ обработка ошибки;
▪️ журнал доставки.
Ошибка может приводить к многократной отправке одного сообщения, уведомлению о чужой покупке или предоставлению неверных сведений о бонусах.
При массовой кампании важно контролировать нагрузку и исключать повторную рассылку после временного сбоя.
🖥️ Раздел 20. Административная панель
Административный интерфейс используется для настройки правил и управления программой.
Эксперт проверяет:
▪️ разграничение прав;
▪️ создание акций;
▪️ изменение правил;
▪️ ручное начисление;
▪️ ручное списание;
▪️ блокировку клиента;
▪️ отчёты;
▪️ импорт и экспорт;
▪️ журнал действий;
▪️ подтверждение критических операций.
Опасным недостатком является возможность изменять бонусный баланс без фиксации автора, времени и основания.
Административные действия должны быть прослеживаемыми. Желательно, чтобы критические операции требовали подтверждения или дополнительного согласования.
📊 Раздел 21. Отчётность и аналитика
Эксперт оценивает:
▪️ отчёт по начислениям;
▪️ отчёт по списаниям;
▪️ неиспользованные бонусы;
▪️ сгорание;
▪️ активность клиентов;
▪️ эффективность акций;
▪️ уровни программы;
▪️ возвраты;
▪️ финансовые показатели;
▪️ экспорт данных.
Необходимо проверить, совпадают ли отчёты с первичными операциями базы данных.
Типичные ошибки:
▪️ двойной учёт;
▪️ неправильный период;
▪️ отсутствие отменённых операций;
▪️ несовпадение итогов;
▪️ неверное округление;
▪️ смешение временных зон;
▪️ потеря части данных при экспорте.
Красивое отображение диаграмм не подтверждает достоверность аналитики. Эксперт проверяет алгоритм формирования показателей.
☁️ Раздел 22. Инфраструктура и развёртывание
Качество системы зависит не только от программного кода, но и от инфраструктуры.
Исследуются:
▪️ серверы;
▪️ облачная платформа;
▪️ контейнеры;
▪️ настройки сети;
▪️ балансировщики;
▪️ база данных;
▪️ резервное копирование;
▪️ мониторинг;
▪️ журналирование;
▪️ автоматизация развёртывания;
▪️ разделение тестовой и рабочей среды.
Возможные недостатки:
▪️ единственная точка отказа;
▪️ отсутствие резервной копии;
▪️ хранение секретов в коде;
▪️ ручное обновление;
▪️ отсутствие мониторинга;
▪️ смешение тестовых и рабочих данных;
▪️ невозможность быстрого восстановления;
▪️ потеря журналов после перезапуска.
Если исполнитель обязался создать готовую к промышленной эксплуатации систему, инфраструктура также входит в оценку качества результата.
💾 Раздел 23. Резервное копирование и восстановление
Эксперт проверяет:
▪️ периодичность копирования;
▪️ состав резервной копии;
▪️ место хранения;
▪️ шифрование;
▪️ срок хранения;
▪️ автоматический контроль;
▪️ тестовое восстановление;
▪️ документированную процедуру.
Факт создания файлов резервной копии ещё не означает, что данные можно восстановить.
Необходимо проверить:
▪️ целостность;
▪️ актуальность;
▪️ совместимость версии;
▪️ наличие ключей;
▪️ доступность файлов;
▪️ время восстановления.
Для системы лояльности потеря базы данных может привести к утрате клиентских балансов и истории операций, поэтому восстановление является критически важным требованием.
📚 Раздел 24. Техническая документация
Комплект документации может включать:
▪️ описание архитектуры;
▪️ инструкцию пользователя;
▪️ руководство администратора;
▪️ документацию программных интерфейсов;
▪️ схему базы данных;
▪️ порядок развёртывания;
▪️ процедуру резервного копирования;
▪️ описание мониторинга;
▪️ перечень зависимостей;
▪️ руководство разработчика;
▪️ список известных ограничений.
Отсутствие документации может сделать систему зависимой от первоначальной команды и затруднить исправление ошибок.
Эксперт устанавливает:
▪️ соответствует ли документация фактической версии;
▪️ достаточно ли её для эксплуатации;
▪️ возможно ли развернуть продукт;
▪️ описаны ли ключевые интеграции;
▪️ переданы ли необходимые доступы.
Наличие большого объёма формальных документов не гарантирует их качества, если они устарели или описывают другую версию продукта.
📦 Раздел 25. Передача исходного кода и прав доступа
При завершении проекта заказчику могут передаваться:
▪️ исходный код;
▪️ репозиторий;
▪️ история изменений;
▪️ инструкции по сборке;
▪️ доступ к серверам;
▪️ база данных;
▪️ резервные копии;
▪️ ключи и сертификаты;
▪️ учётные записи;
▪️ документация;
▪️ сборочные файлы.
Эксперт проверяет, достаточно ли переданных материалов для:
▪️ запуска;
▪️ сопровождения;
▪️ исправления ошибок;
▪️ создания новой версии;
▪️ переноса на другую инфраструктуру.
Передача только готового исполняемого файла может быть недостаточной, если договор предусматривает передачу исходного кода и возможность самостоятельного развития системы.
📐 Раздел 26. Как определяется объём фактически выполненных работ
В споре о проценте готовности эксперт разделяет систему на функциональные и технические компоненты.
Оцениваются:
▪️ наличие функции;
▪️ полнота реализации;
▪️ работоспособность;
▪️ соответствие требованиям;
▪️ интеграция;
▪️ тестирование;
▪️ документация;
▪️ готовность к эксплуатации.
Функция не считается полностью выполненной только потому, что для неё создан экран.
Например, модуль акции может иметь интерфейс настройки, но:
▪️ не рассчитывать скидку;
▪️ не передавать её на кассу;
▪️ не обрабатывать возврат;
▪️ не формировать отчёт;
▪️ не сохранять историю изменений.
Процент готовности должен определяться по объективной методике и учитывать значимость отдельных модулей, а не только количество экранов или строк кода.
💰 Раздел 27. Как оценивается стоимость устранения недостатков
Эксперт может определить объём работ, необходимых для приведения системы в требуемое состояние.
В расчёт могут включаться:
▪️ исправление бизнес-логики;
▪️ переработка интеграций;
▪️ очистка данных;
▪️ восстановление транзакций;
▪️ оптимизация базы;
▪️ разработка тестов;
▪️ устранение уязвимостей;
▪️ переработка архитектуры;
▪️ документирование;
▪️ настройка инфраструктуры;
▪️ перенос данных;
▪️ повторное тестирование;
▪️ развёртывание;
▪️ техническое сопровождение перехода.
Следует разграничивать:
▪️ устранение дефектов;
▪️ реализацию первоначально согласованной функции;
▪️ новые пожелания заказчика;
▪️ модернизацию продукта.
Новая функция, не предусмотренная исходным объёмом, не должна автоматически включаться в стоимость исправления недостатков.
📋 Раздел 28. Какие вопросы поставить перед экспертом
Возможные формулировки:
▪️ соответствует ли система условиям договора;
▪️ соответствует ли она техническому заданию;
▪️ какие функции реализованы;
▪️ какие функции отсутствуют;
▪️ имеются ли программные ошибки;
▪️ правильно ли выполняется начисление бонусов;
▪️ правильно ли производится списание;
▪️ корректно ли обрабатываются возвраты;
▪️ имеются ли случаи дублирования транзакций;
▪️ обеспечивается ли целостность данных;
▪️ соответствуют ли интеграции согласованным требованиям;
▪️ пригодна ли система для промышленной эксплуатации;
▪️ соответствует ли производительность назначению;
▪️ имеются ли критические уязвимости;
▪️ достаточна ли техническая документация;
▪️ передан ли полный исходный код;
▪️ возможно ли сопровождение другой командой;
▪️ каков объём фактически выполненных работ;
▪️ являются ли недостатки устранимыми;
▪️ какие работы необходимы для устранения;
▪️ какова стоимость исправления;
▪️ связано ли нарушение работы с действиями разработчика или внешнего сервиса.
Не рекомендуется ставить вопросы:
▪️ кто виновен в срыве проекта;
▪️ должен ли суд взыскать оплату;
▪️ является ли договор расторгнутым;
▪️ имеются ли основания для штрафа;
▪️ действовал ли исполнитель недобросовестно.
Такие вопросы относятся к правовой оценке суда.
⚠️ Раздел 29. Типичные ошибки заказчика
Наиболее распространённые ошибки:
▪️ отсутствие подробного технического задания;
▪️ устное согласование изменений;
▪️ смешение разных редакций требований;
▪️ отсутствие критериев приёмки;
▪️ приёмка по демонстрации;
▪️ отсутствие тестовых сценариев;
▪️ эксплуатация без резервного копирования;
▪️ передача общих административных паролей;
▪️ отсутствие контроля репозитория;
▪️ неполучение исходного кода;
▪️ удаление журналов;
▪️ изменение системы до экспертизы;
▪️ предоставление только скриншотов ошибок;
▪️ отсутствие фиксации версии;
▪️ формулировка общих претензий.
Вместо утверждения «система не работает» следует зафиксировать:
▪️ дату и время;
▪️ пользователя;
▪️ действие;
▪️ исходные данные;
▪️ ожидаемый результат;
▪️ фактический результат;
▪️ скриншот;
▪️ технический журнал;
▪️ идентификатор операции.
Такая фиксация значительно повышает доказательственное значение материалов.
⚠️ Раздел 30. Типичные ошибки разработчика
Исполнитель также может допускать ошибки в организации проекта и передаче результата.
К ним относятся:
▪️ отсутствие фиксации изменений;
▪️ работа без системы контроля версий;
▪️ отсутствие технической документации;
▪️ использование единственного сервера;
▪️ хранение доступов у одного сотрудника;
▪️ отсутствие автоматических тестов;
▪️ отсутствие журналирования;
▪️ обновление рабочей системы без резервной копии;
▪️ смешение тестовых и рабочих данных;
▪️ передача неподготовленного релиза;
▪️ отсутствие протокола приёмочных испытаний;
▪️ невозможность воспроизвести сборку;
▪️ зависимость от личных аккаунтов разработчиков.
Если исполнитель заявляет о полной готовности продукта, но не может развернуть систему из переданных исходников, это может указывать на неполноту результата.
⚖️ Раздел 31. Значение IT-экспертизы для суда
Экспертное заключение позволяет:
▪️ установить фактический объём разработки;
▪️ проверить соответствие техническому заданию;
▪️ выявить критические ошибки;
▪️ разграничить дефекты и новые требования;
▪️ определить качество интеграций;
▪️ подтвердить потерю или искажение данных;
▪️ оценить пригодность к эксплуатации;
▪️ определить процент готовности;
▪️ проверить передачу исходного кода;
▪️ установить объём исправлений;
▪️ рассчитать стоимость завершения;
▪️ подготовить техническую основу претензии;
▪️ обосновать требования заказчика;
▪️ проверить возражения исполнителя.
Экспертное заключение оценивается вместе с договором, техническим заданием, актами, перепиской, репозиторием, отчётами об ошибках и другими доказательствами.
Если часть недостатков вызвана сторонними сервисами, эксперт должен определить, правильно ли разработчик предусмотрел обработку таких отказов.
📝 Раздел 32. Чек-лист подготовки к экспертизе
Сохраните технические материалы:
▪️ исходный код;
▪️ репозиторий;
▪️ базу данных;
▪️ резервные копии;
▪️ журналы;
▪️ конфигурацию;
▪️ сборочные файлы;
▪️ документацию;
▪️ тестовые данные.
Зафиксируйте версии:
▪️ дату;
▪️ номер сборки;
▪️ идентификатор изменения;
▪️ адрес среды;
▪️ список компонентов;
▪️ версии библиотек;
▪️ конфигурацию базы.
Соберите договорные документы:
▪️ договор;
▪️ техническое задание;
▪️ приложения;
▪️ дополнительные соглашения;
▪️ календарный план;
▪️ акты;
▪️ протоколы встреч;
▪️ переписку.
Зафиксируйте ошибки:
▪️ опишите сценарий;
▪️ сохраните скриншот;
▪️ запишите видео;
▪️ укажите пользователя;
▪️ сохраните идентификатор операции;
▪️ приложите журнал;
▪️ укажите ожидаемый результат.
Не изменяйте объект без фиксации:
▪️ не удаляйте журналы;
▪️ не очищайте базу;
▪️ не обновляйте систему;
▪️ не меняйте код;
▪️ не переустанавливайте серверы;
▪️ не удаляйте учётные записи;
▪️ создайте резервную копию.
Подготовьте вопросы:
▪️ о соответствии договору;
▪️ о реализованных функциях;
▪️ об ошибках;
▪️ о качестве кода;
▪️ о готовности;
▪️ о стоимости исправления.
📚 Раздел 33. Практика проведения IT-экспертиз систем лояльности
Кейс 1. Двойное начисление бонусов при повторной отправке кассовой операции 💳
После запуска программы лояльности компания обнаружила, что некоторым клиентам бонусы начислялись дважды за одну покупку.
Разработчик утверждал, что кассовая система отправляла повторные запросы и проблема не относилась к созданному им программному обеспечению.
Эксперты Союза «Федерация судебных экспертов» исследовали журналы касс, программные интерфейсы, базу данных и исходный код системы лояльности.
Было установлено, что кассовое программное обеспечение действительно повторяло запрос при отсутствии своевременного ответа.
Однако каждая операция содержала уникальный номер чека, который система лояльности могла использовать для проверки повторной обработки.
В программном коде такая проверка отсутствовала. Каждый запрос воспринимался как новая покупка.
Эксперты установили, что повторная передача сообщения являлась штатным сценарием интеграционного взаимодействия, а система лояльности не имела необходимой защиты от дублирования.
В заключении были определены объём ошибочно начисленных бонусов, способ восстановления балансов и необходимые изменения программного кода.
Кейс 2. Неправильная обработка возвратов интернет-магазина 🔄
Покупатели возвращали часть товаров из заказов, но начисленные бонусы списывались полностью либо не списывались вообще.
Заказчик считал, что система лояльности реализована с ошибками. Исполнитель ссылался на неполные данные со стороны интернет-магазина.
Эксперты исследовали техническое задание, формат обмена, журналы операций и несколько десятков возвратов.
Было установлено, что интернет-магазин передавал информацию о каждом возвращённом товаре и фактической сумме возврата.
Однако система лояльности использовала идентификатор всего заказа и не учитывала отдельные позиции.
При первом возврате она полностью отменяла начисление, а последующие операции игнорировала.
Эксперты пришли к выводу, что входных данных было достаточно для корректного расчёта, но бизнес-логика программы не поддерживала согласованный сценарий частичного возврата.
Кейс 3. Расхождение бонусных балансов между приложением и кассой 📱
Клиенты жаловались, что в мобильном приложении отображается один баланс, а на кассе доступно другое количество бонусов.
Разработчик приложения утверждал, что он отображает сведения, полученные от сервера. Разработчик серверной части считал причиной кэширование в приложении.
Эксперты исследовали приложение, программные интерфейсы, базу данных и систему кэширования.
Серверный программный интерфейс иногда получал сведения не из основной базы, а из кэша, срок обновления которого составлял несколько часов.
После списания бонусов касса работала с основной базой, а приложение продолжало отображать старое значение.
Дополнительно механизм принудительного обновления не очищал серверный кэш.
Эксперты установили, что проблема находилась в серверной архитектуре, а не только в мобильном интерфейсе.
Для устранения требовалось изменить механизм обновления и обеспечить единый источник актуального баланса.
Кейс 4. Система формально разработана, но не готова к промышленной эксплуатации 🖥️
Исполнитель продемонстрировал основные функции и потребовал подписать акт. Заказчик отказался, поскольку система регулярно становилась недоступной при тестировании большого количества пользователей.
Эксперты изучили договор, техническое задание, исходный код, инфраструктуру и результаты нагрузочных испытаний.
Функции регистрации, начисления и списания были реализованы. Однако база данных не имела необходимых индексов, а отдельные отчёты блокировали операции клиентов.
При увеличении нагрузки время ответа возрастало до нескольких минут, после чего приложение завершало работу с ошибками.
Автоматическое восстановление отсутствовало, журналы хранились только локально и удалялись после перезапуска.
В техническом задании содержалось требование о поддержке одновременной работы значительного числа касс и пользователей.
Эксперты признали, что функциональная разработка выполнена частично, но система не соответствует требованиям производительности и эксплуатационной готовности.
Кейс 5. Комплексная экспертиза системы лояльности при арбитражном споре ⚖️
Крупная розничная компания заказала разработку единой системы лояльности для магазинов, интернет-сайта и мобильного приложения. После запуска возникли массовые жалобы клиентов, расхождения балансов и ошибки в маркетинговых акциях.
Заказчик отказался оплачивать финальный этап и потребовал возмещения расходов. Исполнитель заявил, что основные функции реализованы, а ошибки вызваны постоянным изменением требований и действиями сторонних подрядчиков.
Специалисты Союза «Федерация судебных экспертов» исследовали:
▪️ договор;
▪️ несколько редакций технического задания;
▪️ протоколы встреч;
▪️ исходный код;
▪️ историю репозитория;
▪️ базу данных;
▪️ интеграции;
▪️ мобильное приложение;
▪️ журналы касс;
▪️ систему управления задачами;
▪️ тестовые отчёты;
▪️ рабочую инфраструктуру.
Эксперты установили несколько групп недостатков.
Часть функций действительно менялась по инициативе заказчика и не была оформлена дополнительными соглашениями. Такие пожелания не могли автоматически оцениваться как первоначальные обязательства разработчика.
Одновременно ряд базовых функций был прямо предусмотрен техническим заданием, но реализован некорректно.
В системе отсутствовала единая модель бонусной транзакции. Разные каналы создавали операции в различных форматах, из-за чего возвраты и отмены обрабатывались неодинаково.
Механизм защиты от повторных запросов отсутствовал, что приводило к двойному начислению.
Перерасчёт клиентских уровней выполнялся один раз в сутки, хотя по требованиям изменение должно было отражаться после покупки.
Административная панель позволяла вручную изменять баланс без обязательного указания основания и без полноценного журнала действий.
Нагрузочное тестирование до запуска не проводилось. В период массовой акции база данных перегружалась, а сообщения из очереди обрабатывались с задержкой.
Документация программных интерфейсов не соответствовала фактической версии, а часть доступа к инфраструктуре находилась в личных аккаунтах разработчиков.
При этом основные пользовательские интерфейсы, регистрация, базовое начисление и значительная часть интеграций были реализованы.
Эксперты разделили объём работ на категории:
▪️ выполненные и работоспособные функции;
▪️ реализованные с устранимыми дефектами;
▪️ формально присутствующие, но неготовые к эксплуатации;
▪️ отсутствующие функции первоначального задания;
▪️ дополнительные пожелания заказчика;
▪️ недостатки документации и передачи системы.
Для каждого компонента был определён процент технической готовности и трудоёмкость исправления.
Экспертиза позволила суду разграничить первоначальные обязательства и дополнительные требования, оценить фактически выполненный объём и установить обоснованную стоимость завершения проекта. 📚
🏁 Раздел 34. Заключение
IT-экспертиза качества разработки системы лояльности позволяет установить, соответствует ли созданный программный продукт договору и техническому заданию, правильно ли реализованы бизнес-правила и пригодна ли система для промышленной эксплуатации.
Экспертиза должна охватывать не только пользовательские экраны, но и:
▪️ исходный код;
▪️ базу данных;
▪️ интеграции;
▪️ журналы событий;
▪️ инфраструктуру;
▪️ безопасность;
▪️ тестирование;
▪️ техническую документацию;
▪️ историю разработки.
Наличие работающего интерфейса не означает, что функция полностью реализована. Необходимо проверить расчёты, возвраты, повторные операции, согласованность данных, обработку ошибок и формирование отчётности.
Особое значение имеют техническое задание и документы об изменении требований. Эксперт должен разграничить первоначально согласованные функции, последующие дополнения и новые пожелания заказчика.
Перед экспертизой необходимо сохранить исходный код, репозиторий, базу данных, журналы, резервные копии и конфигурацию конкретной версии. Изменение системы без фиксации может затруднить установление её состояния на спорную дату.
Экспертное заключение помогает определить фактический объём выполненных работ, критичность ошибок, возможность устранения недостатков, степень готовности и стоимость завершения проекта.
Исследование может использоваться при подготовке претензии разработчику, отказе от приёмки, расчёте стоимости исправлений, взыскании убытков, защите позиции исполнителя и рассмотрении спора в суде.
Значительный опыт проведения подобных исследований накоплен Союзом «Федерация судебных экспертов», специалисты которого выполняют независимые и судебные IT-экспертизы систем лояльности, интернет-магазинов, мобильных приложений, CRM, баз данных, программных интеграций и корпоративных информационных систем любой сложности. 📚
Полную контактную информацию, телефон, адрес офиса и дополнительные сведения по данному вопросу можно найти на официальном сайте ✅ https://krimexpert.ru
Задавайте любые вопросы