Блог компании "Лаборатория Цифровых Исследований"

Проверка автоматизированной информационной системы (АИС) на соответствие техническому заданию

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

1. Почему проверка АИС по ТЗ - это всегда междисциплинарная задача

Техническое задание - это юридический документ, но его исполнение лежит в области IT.
Основные сложности:
  • ТЗ часто написано неформально, содержит противоречия или нечеткие критерии («удобный интерфейс», «быстрая работа», «масштабируемость»).
  • Разработчик утверждает, что «все работает согласно ТЗ», но по факту бизнес-логика нарушена.
  • Ряд требований невозможно проверить «ручным» тестированием - нужен анализ кода, логов, архитектуры БД.
Именно поэтому простая приемочная комиссия или акт тестирования силами QA заказчика имеют низкую доказательную силу в арбитраже.
Суд потребует:
  • объективной методики;
  • документированной процедуры проверки;
  • вывода специалиста, обладающего компетенцией в области компьютерно-технических исследований.

2. Что включает профессиональная проверка АИС на соответствие ТЗ

Полноценная компьютерно-техническая экспертиза (или досудебное исследование) АИС должна ответить на вопросы:

2.1 Соответствие функционала

  • Реализованы ли все функции, перечисленные в ТЗ?
  • Соответствует ли их реализация описанным алгоритмам, входным и выходным данным?
  • Есть ли избыточная функциональность, создающая риски безопасности или нестабильности?

2.2 Соответствие нефункциональным требованиям

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

2.3 Соответствие технической документации

Сравниваются:
  • исходные коды (на предмет заимствований, недокументированных модулей);
  • структура баз данных;
  • схемы интеграций;
  • API-спецификации.

2.4 Наличие скрытых дефектов

Обнаруживаются:
  • программные закладки;
  • недекларированные возможности (НДВ);
  • «костыли», которые поломаются при нагрузке.
Важно: такая проверка должна проводиться с использованием аттестованных методик и, по возможности, специализированного ПО (например, для сравнения исходных кодов).
Эксперт ЛЦИ в данном случае выступает как независимая сторона, не заинтересованная ни в заказчике, ни в разработчике.

3. Типичные ситуации, когда требуется проверка АИС на соответствие ТЗ

3.1 Приемка государственного или крупного коммерческого контракта

Госконтракты (44-ФЗ, 223-ФЗ) и крупные B2B-сделки требуют строгого подтверждения выполнения работ.
Если вы подписали акт, а потом обнаружили несоответствия - доказать нарушение будет в разы сложнее.
Экспертиза ДО подписания - золотой стандарт.

3.2 Трудовой спор или корпоративный конфликт

Ситуация: систему разрабатывала внутренняя команда или подрядчик, а после увольнения ключевых IT-специалистов выяснилось, что АИС не соответствует ТЗ и не может сопровождаться.
Экспертиза нужна для определения объема переделок и виновных.

3.3 Споры об интеллектуальной собственности

Разработчик утверждает, что создал уникальный код, а на деле - копипаст из open-source с нарушением лицензий или ворованный код.
Проверка АИС на соответствие ТЗ включает анализ оригинальности исходных кодов.

3.4 Внесудебное урегулирование спора

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

4. Чем компьютерно-техническая экспертиза отличается от обычного тестирования

Критерий
Обычное тестирование QA
СКТЭ для суда / сделки
Цель
Найти баги
Установить юридический факт несоответствия ТЗ
Методика
Внутренняя, может меняться
Апробированная, документированная, воспроизводимая
Фиксация
Отчет для разработки
Заключение эксперта с соответствием процессуальным нормам
Исследование кода
Поверхностно
Глубокий анализ исходных кодов, архитектуры, БД
Доказательная сила в суде
Практически нулевая
Высокая (если экспертиза проведена по нормам)

5. Как подготовиться к проверке АИС экспертом (чек-лист для заказчика)

Чтобы экспертиза прошла быстро, дешево и дала максимально сильный результат:
  • Соберите исходную документацию
  • Техническое задание (все версии и приложения).
  • Протоколы согласования изменений требований (если были).
  • Схемы взаимодействия подсистем, описание интеграций.
  • Предоставьте доступ к системе
  • Тестовый или продуктивный контур (лучше - оба).
  • Исходные коды (с историей изменений в Git или другой VCS).
  • Логи работы системы за характерный период.
  • Четко сформулируйте вопросы эксперту
Например:
  • «Реализован ли в АИС механизм X в соответствии с разделом 3.2 ТЗ?»
  • «Соответствует ли время отклика Y пункту 5.1 ТЗ при Z одновременных пользователях?»
  • «Имеются ли в исходных кодах фрагменты, не относящиеся к описанному в ТЗ функционалу?»
  • Зафиксируйте состояние системы
  1. Желательно сделать битовую копию дисков, снимки БД, конфигурации.
  2. Это исключит версию разработчика: «вы проверяли не ту версию».
Когда это особенно важно
Если дело уже близко к суду, должна назначаться судебная компьютерно-техническая экспертиза.
Но предварительное досудебное исследование позволяет:
  • оценить перспективы дела;
  • скорректировать вопросы к эксперту;
  • иногда избежать суда вообще.

6. Почему эксперты ЛЦИ - правильный выбор для проверки АИС по ТЗ

Лаборатория цифровых исследований специализируется именно на компьютерно-технических экспертизах, а не на «общих» исследованиях.
Ключевые преимущества для проверки АИС:
  • Глубокая экспертиза в анализе исходных кодов
Собственное ПО «Студия Цифровых Исследований» позволяет объективно сравнивать код с ТЗ и выявлять плагиат / недокументированные модули.
  • Опыт с 2016 года
Более 250 заключений, включая сложные арбитражные процессы и споры о защите интеллектуальных прав.
  • Преподаватели ведущих вузов (МГЮА, МГТУ им. Баумана)
Эксперты ЛЦИ не просто практикуют, но и формируют стандарты СКТЭ в России.
  • Индивидуальный подход
Нет шаблонных решений — для каждого ТЗ разрабатывается своя процедура проверки.
  • Прозрачная методика
Которую можно защищать в суде, а не «магический черный ящик».

7. Вместо заключения: три главных совета заказчику

  1. Не подписывайте акт приемки без хотя бы минимальной независимой проверки соответствия АИС ТЗ. После подписания ваши шансы в суде падают в разы.
  2. Различайте тестирование и экспертизу. Первое - для разработки, второе - для юриста и суда. Не экономьте на виде исследования.
  3. Проверяйте не только функционал, но и код. Многие проблемы АИС лежат в архитектуре, заимствованиях, закладках и «скелетах в шкафу» исходников.