Государственные и коммерческие заказчики регулярно сталкиваются с ситуацией:
автоматизированная информационная система (АИС) принята по акту, но работает не так, как оговаривалось в техническом задании (ТЗ).
Функционал не соответствует требованиям, производительность ниже заявленной, интеграции «сырые», а безопасность данных под вопросом. При этом подписать акт приемки зачастую вынуждают обстоятельства - иначе срыв сроков проекта или штрафные санкции.
Однако юридически значимая проверка АИС на соответствие ТЗ - это не тестирование силами штатных IT-специалистов заказчика.
Это процедура, результаты которой можно использовать в:
арбитражном процессе (если поставщик отказывается устранять недостатки);
досудебной претензии и переговорах;
внутреннем расследовании причин некорректной работы системы.
В этой статье разберем:
что такое объективная проверка АИС по ТЗ;
почему тестирование разработчика и приемочная комиссия - не доказательство в суде;
как проводится компьютерно-техническая экспертиза (СКТЭ) АИС;
как заказчику минимизировать риски еще на стадии составления ТЗ.
1. Почему проверка АИС по ТЗ - это всегда междисциплинарная задача
Техническое задание - это юридический документ, но его исполнение лежит в области IT.
Основные сложности:
ТЗ часто написано неформально, содержит противоречия или нечеткие критерии («удобный интерфейс», «быстрая работа», «масштабируемость»).
Разработчик утверждает, что «все работает согласно ТЗ», но по факту бизнес-логика нарушена.
Ряд требований невозможно проверить «ручным» тестированием - нужен анализ кода, логов, архитектуры БД.
Именно поэтому простая приемочная комиссия или акт тестирования силами QA заказчика имеют низкую доказательную силу в арбитраже.
Суд потребует:
объективной методики;
документированной процедуры проверки;
вывода специалиста, обладающего компетенцией в области компьютерно-технических исследований.
2. Что включает профессиональная проверка АИС на соответствие ТЗ
Полноценная компьютерно-техническая экспертиза (или досудебное исследование) АИС должна ответить на вопросы:
2.1 Соответствие функционала
Реализованы ли все функции, перечисленные в ТЗ?
Соответствует ли их реализация описанным алгоритмам, входным и выходным данным?
Есть ли избыточная функциональность, создающая риски безопасности или нестабильности?
Надежность (отсутствие критических ошибок, время восстановления).
Безопасность (контроль доступа, шифрование, защита от инъекций).
Масштабируемость (проверяется косвенно через архитектурные решения).
2.3 Соответствие технической документации
Сравниваются:
исходные коды (на предмет заимствований, недокументированных модулей);
структура баз данных;
схемы интеграций;
API-спецификации.
2.4 Наличие скрытых дефектов
Обнаруживаются:
программные закладки;
недекларированные возможности (НДВ);
«костыли», которые поломаются при нагрузке.
Важно: такая проверка должна проводиться с использованием аттестованных методик и, по возможности, специализированного ПО (например, для сравнения исходных кодов).
Эксперт ЛЦИ в данном случае выступает как независимая сторона, не заинтересованная ни в заказчике, ни в разработчике.
3. Типичные ситуации, когда требуется проверка АИС на соответствие ТЗ
3.1 Приемка государственного или крупного коммерческого контракта
Госконтракты (44-ФЗ, 223-ФЗ) и крупные B2B-сделки требуют строгого подтверждения выполнения работ.
Если вы подписали акт, а потом обнаружили несоответствия - доказать нарушение будет в разы сложнее.
Экспертиза ДО подписания - золотой стандарт.
3.2 Трудовой спор или корпоративный конфликт
Ситуация: систему разрабатывала внутренняя команда или подрядчик, а после увольнения ключевых IT-специалистов выяснилось, что АИС не соответствует ТЗ и не может сопровождаться.
Экспертиза нужна для определения объема переделок и виновных.
3.3 Споры об интеллектуальной собственности
Разработчик утверждает, что создал уникальный код, а на деле - копипаст из open-source с нарушением лицензий или ворованный код.
Проверка АИС на соответствие ТЗ включает анализ оригинальности исходных кодов.
3.4 Внесудебное урегулирование спора
Досудебное исследование часто заставляет разработчика пойти на мировую, не доводя дело до арбитража.
Заключение независимого компьютерно-технического эксперта - весомый аргумент в переговорах.
4. Чем компьютерно-техническая экспертиза отличается от обычного тестирования