В споре о разработке или внедрении недостаточно назвать систему «некачественной». Технический вывод должен связывать конкретное требование с версией базы, условиями проверки и наблюдаемым результатом. Это направление экспертизы БД и СУБД сопоставляет структуру данных, программные объекты и измеримые характеристики с документами, которыми стороны описали ожидаемый результат.
Если система продолжает дорабатываться, до новых релизов сохраните относящиеся к спору сборки, схему, конфигурацию, журналы и редакции документации. Более позднее состояние не заменит версию, которая фактически передавалась на проверку.
Когда нужна экспертиза соответствия БД техническому заданию
Исследование проводят в договорных и судебных спорах о конкретном результате разработки, доработки, внедрения или сопровождения базы. Оно не заменяет своевременных приёмочных испытаний: эксперт ретроспективно работает только с тем состоянием системы и теми документами, которые удалось сохранить.
- не реализованы таблицы, коллекции, связи, отчёты, процедуры или интеграции;
- данные сохраняются не полностью либо нарушаются ограничения;
- версии сторон отличаются, а состав переданного результата оспаривается;
- функция работает иначе, чем описано в ТЗ;
- есть спор о правах доступа, журналировании, резервировании или отказоустойчивости;
- заказчик и подрядчик по-разному объясняют дефект;
- нужно отделить недостаток БД от приложения и инфраструктуры.
Если спор охватывает весь программный продукт, исходный код и пользовательские функции, применяют экспертизу программного обеспечения. Проект целиком, включая бизнес-процессы, интеграции и эксплуатацию, может потребовать экспертизы корпоративной информационной системы. Если основной вопрос касается истории конкретных записей и операций, выбирают экспертизу изменений и удаления данных. Предметы исследований разграничивают заранее, чтобы без проверки не приписать базе данных дефект интерфейса или сервера приложений.
Предмет и пределы компетенции
Предметом является соответствие фактически реализованных элементов и свойств названным техническим требованиям на определённую дату. Эксперт устанавливает, существует ли объект, воспроизводится ли функция, в чём проявляется отклонение и с каким техническим механизмом оно связано. Если данных недостаточно, чтобы установить причину, эксперт указывает подтверждённые признаки и проверенные альтернативные объяснения.
Эксперт по БД не решает, нарушил ли подрядчик договор, является ли недостаток юридически существенным, кто виновен и каков размер убытков. Он также не выбирает между противоречащими друг другу редакциями договора по правовым основаниям. Эти вопросы разрешает уполномоченный орган или суд в установленном порядке; стоимость исправления может потребовать участия специалиста по сметам, оценке или экономическому анализу.
Какие объекты исследуются
Исследуемый объект должен отражать состояние системы на дату, указанную в вопросах или исходных условиях. Для него фиксируют источник, сборку или коммит, версию схемы, дату развёртывания, конфигурацию и контрольные суммы полученных файлов с указанием алгоритма. Для дампа, резервной копии или снимка отдельно описывают способ обеспечения согласованности, время начала и окончания, состояние сервиса, охват томов и контрольную точку либо позицию журнала. Свойства доработанной после спора системы нельзя автоматически переносить на ранее переданный результат.
Структура и логика базы
Исследуются схемы, таблицы и коллекции, типы, ключи, связи, ограничения, индексы, представления, процедуры, функции, триггеры, задания и роли. Каждый объект сопоставляют с конкретным пунктом ТЗ, моделью данных и согласованными изменениями, а не с общим представлением о желательной архитектуре.
Связанный код и интерфейсы
Если требование реализовано совместно приложением и СУБД, нужны запросы, ORM-модели, API, ETL, интеграционные модули и конфигурация. Фиксируются точная версия кода или исполняемой сборки, зависимости и параметры запуска. Исследуют компоненты, влияющие на спорный результат. Если этого недостаточно, отдельно обосновывают необходимость комплексной экспертизы ПО.
Тестовая и эксплуатационная среда
Для воспроизведения фиксируют версии СУБД и ОС, ресурсы, параметры, объём и состав данных, права, профиль нагрузки и связанные сервисы. Для измеримых нефункциональных требований также задают продолжительность и число повторов, прогрев, конкурентность, точку измерения, способ агрегации и допустимый разброс. Условия берут из согласованной методики испытаний, документов о приёмке или зафиксированной рабочей среды. Результат теста нельзя распространять на условия, не воспроизведённые на стенде.
Документы и материалы
Технический объект исследуется вместе с документами, определявшими ожидаемый результат. Для каждой редакции устанавливают происхождение и временную связь с ходом работ: финальное ТЗ может не совпадать с приложением к договору или состоянием требований на дату приёмки. Применимую редакцию задаёт назначивший орган или согласованное внесудебное задание; при отсутствии такого указания технический результат описывают для каждой представленной редакции.
- договор, ТЗ, спецификации, модель данных и архитектурные решения;
- дополнительные соглашения, запросы на изменение, решения по ним и протоколы согласования;
- критерии приёмки, SLA, методики и протоколы испытаний;
- акты, переписка, баг-трекер, заявки и релизные заметки;
- версии базы, относящиеся к спорным датам, схемы, дампы и сведения о развёртывании;
- исходный код и репозиторий в необходимой части;
- тестовые данные, сценарии и ожидаемые результаты;
- журналы ошибок и мониторинга, история конфигурации, релизов и миграций схемы.
Для первого обращения достаточно описания задачи и перечня материалов. Рабочую базу, исходный код, пароли и ключи передают только после согласования объёма доступа и защищённого канала.
Историческое соблюдение SLA, доступности, RPO и RTO проверяют по данным за заданный период: нужны правило расчёта, интервалы наблюдения, сведения об инцидентах, фактической нагрузке и исключаемом времени. Разовый тест текущего стенда сам по себе не подтверждает показатели прошлого периода.
Если документы противоречат друг другу, эксперт описывает, как меняется технический результат при каждой заданной редакции, либо просит назначивший орган уточнить исходное условие. Неопределённое требование нельзя произвольно дополнять «лучшими практиками». Стандарт или документацию продукта используют только после обоснования их применимости и не выдают их за согласованное сторонами условие.
Как проводится проверка
Сначала составляют матрицу прослеживаемости: «редакция и пункт требования — объект реализации — условия и метод проверки — ожидаемое и фактическое состояние — подтверждающий материал — правило оценки — статус — ограничения». Для каждого пункта заранее задают критерий, по которому можно отличить соответствие от отклонения.
Эксперт фиксирует объект и среду, анализирует структуру, выполняет документированные запросы и позитивные, негативные либо граничные сценарии, если они следуют из требования. Перед каждым повтором фиксируют или восстанавливают исходное состояние данных, транзакций, кэшей и связанных сервисов; порядок сценариев и число повторов указывают в протоколе. При невоспроизводимом дефекте проверяется влияние данных, прав, конфигурации, приложения, интеграции и инфраструктуры.
Опасные и нагрузочные тесты проводят на изолированном стенде. На рабочей базе допустимы заранее согласованные неразрушающие наблюдения; исключение требует обоснования отсутствия альтернативы и отдельного плана контроля и восстановления. В заключении приводят команды, параметры, исходное состояние, тестовые данные, порядок и время запусков, версии средств, сырые результаты, правило их обработки и существенные отличия стенда.
Какие вопросы поставить перед экспертом
Вопрос связывает пункт документа с конкретным объектом и измеримым свойством. До назначения экспертизы можно отделить технические задачи от правовых и распределить их по специальностям.
Укажите редакцию ТЗ, номер пункта, дату, относящуюся к спору, экземпляр базы, функцию и условия теста. Не объединяйте в одном вопросе структуру, производительность, стоимость работ и виновность. Окончательный круг вопросов судебной экспертизы определяет назначающий орган.
- Имеется ли в указанной версии предусмотренный объект?
- Обеспечивает ли указанная функция измеримый результат, предусмотренный названным пунктом ТЗ?
- Соответствуют ли перечисленные элементы структуры и ограничения названным положениям модели данных?
- Воспроизводится ли указанное отклонение в зафиксированной версии при заданных исходных данных и последовательности действий?
- Если отклонение воспроизводится, каково его техническое проявление?
- Чем технически вызвано отклонение и какие альтернативные объяснения проверены?
- Если отклонение установлено, в каких предусмотренных ТЗ сценариях и при каких исходных данных оно препятствует выполнению указанной функции?
- Соответствуют ли роли и права указанным техническим требованиям?
- Какая из представленных версий содержит указанные согласованные элементы?
- Какие требования не допускают технической проверки и почему?
- Какие дополнительные объекты нужны для проверки оставшихся требований?
Вопрос «качественно ли выполнена работа?» заменяют проверкой конкретных пунктов. Вместо «нарушил ли исполнитель договор?» сопоставляют реализацию и названные требования. Размер возврата или убытков выходит за пределы ИТ-исследования.
Если заключение толкует договор, приписывает подрядчику мотив или прямо определяет виновность, следует проверить пределы компетенции автора и влияние такого суждения на ответы. Вопросы о допросе эксперта, назначении дополнительной или повторной экспертизы и допустимости документа разрешаются по правилам соответствующего вида судопроизводства, а не автоматически при любой неточности.
Связь с миграцией и производительностью
Если ТЗ предусматривало перенос данных, полноту и корректность переноса между исходной и целевой базами исследуют в рамках экспертизы миграции баз данных. Если спор относится к измеримому времени отклика, нагрузке и отказам, применяют экспертизу производительности и сбоев СУБД.
В комплексном исследовании сначала разграничивают объекты и методы специалистов, а затем сводят результаты. Необходимые специальности определяются задачами исследования; при судебной экспертизе состав экспертов устанавливает назначивший орган.
Предварительный прогноз и итоговый документ
На предварительном этапе изучают ТЗ, перечень версий, несколько спорных требований и возможность воспроизвести условия проверки. Это позволяет оценить, какие пункты проверяемы, каких материалов не хватает и нужны ли специалисты по программному обеспечению, оценке или другому профилю.
После процессуального назначения результат оформляется как заключение эксперта; исследование по договору завершается внесудебным документом. В итоговом документе приводят матрицу требований, описание объектов и среды, методы, результаты тестов, выявленные отклонения и ограничения. Новые версии и пояснения по уже назначенной судебной экспертизе передают через назначивший орган.
От чего зависят срок и стоимость
На трудоёмкость влияют число требований и версий, определённость ТЗ, объём кода и схемы, необходимость восстановить среду, подготовить тестовые данные, проверить интеграции и привлечь специалистов другого профиля. Точный расчёт возможен после просмотра комплекта материалов и уточнения границ задачи. Содержательный предварительный прогноз заказывается отдельно; его формат, стоимость и срок согласуют заранее.
Проведение экспертизы по уголовному делу
Судебная экспертиза по уголовному делу производится государственными судебными экспертами и иными экспертами из числа лиц, обладающих специальными знаниями.
Согласно постановлению Пленума Верховного Суда Российской Федерации от 21 декабря 2010 г. № 28 «О судебной экспертизе по уголовным делам», негосударственными судебно-экспертными учреждениями признаются некоммерческие организации, созданные на основании Гражданского кодекса Российской Федерации и Федерального закона «О некоммерческих организациях» и ведущие судебно-экспертную деятельность согласно своим уставам.
По сведениям организации, проведение судебных экспертиз предусмотрено её уставом (см. действующую редакцию в разделе «Документы организации»). Это само по себе не означает автоматического поручения любой экспертизы. Возможность поручить конкретное исследование определяет назначающий орган.
В случаях, перечисленных пунктом 5 постановления № 28, когда экспертизу по уголовному делу назначает суд, ему следует мотивировать в определении или постановлении поручение исследования учреждению либо конкретному лицу. Пункт 5 постановления № 28 связывает выбор негосударственного учреждения с невозможностью провести исследование в государственном учреждении, обслуживающем соответствующую территорию: например, из-за отсутствия нужного специалиста, материально-технической базы или специальных условий, либо с отводом компетентных государственных учреждений. Дополнительно учитываются квалификация эксперта, основания для отвода и действующий перечень экспертиз, выполняемых только государственными судебно-экспертными организациями.
