📌 Введение

IT-экспертиза соответствия техническому заданию системы управления проектами представляет собой комплексное исследование программного продукта, направленное на установление того, реализованы ли предусмотренные договором функции, соответствует ли фактическая архитектура согласованным требованиям, обеспечивается ли стабильная работа системы и может ли заказчик использовать её по назначению. 💻🔎

• Система управления проектами может включать задачи, этапы, сроки, диаграммы, рабочие пространства, уведомления, отчётность, учёт трудозатрат, управление документами, согласование результатов, интеграцию с корпоративными сервисами и разграничение прав пользователей. В сложных решениях такая система становится центральной средой, через которую компания контролирует проекты, ресурсы, бюджеты и взаимодействие сотрудников.
• Необходимость экспертизы возникает, когда заказчик считает, что разработчик не выполнил техническое задание, реализовал только внешнюю часть интерфейса, допустил критические ошибки либо передал продукт, непригодный для промышленной эксплуатации. Исполнитель может возражать, что основные функции созданы, а замечания относятся к новым пожеланиям, изменениям бизнес-процессов или неправильной эксплуатации.
• В подобных спорах недостаточно проверить, открывается ли система и можно ли создать задачу. Необходимо установить, соответствует ли фактическое поведение каждого модуля согласованным сценариям, сохраняется ли целостность данных, правильно ли работают права доступа, уведомления, отчёты, интеграции и фоновые процессы.

Эксперт должен разграничить несколько категорий:

▪️ функции, полностью соответствующие техническому заданию;

▪️ функции, реализованные частично;

▪️ формально присутствующие, но неработоспособные модули;

▪️ отсутствующие требования;

▪️ ошибки, препятствующие эксплуатации;

▪️ несущественные недостатки интерфейса;

▪️ новые требования, появившиеся после заключения договора;

▪️ исходные противоречия самого технического задания.

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

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

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

До начала исследования не рекомендуется удалять журналы, обновлять программную платформу, исправлять ошибки или менять конфигурацию без фиксации. Каждое изменение способно повлиять на результат и затруднить восстановление состояния системы на дату приёмки.

Значительный опыт проведения подобных исследований накоплен специалистами Союза «Федерация судебных экспертов», которые выполняют независимые и судебные IT-экспертизы систем управления проектами, корпоративных платформ, CRM, информационных порталов, программных интеграций и баз данных. 📚

🏛️ Раздел 1. Когда требуется экспертиза системы управления проектами

Экспертиза необходима, если между заказчиком и исполнителем возник спор о фактическом объёме, качестве или готовности разработанного программного продукта.

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

Исследование требуется и в тех случаях, когда отдельные функции присутствуют, но работают не так, как предусмотрено техническим заданием. Система может отправлять уведомления не тем пользователям, неправильно рассчитывать просрочку, терять вложения, изменять статусы без фиксации или формировать недостоверные показатели.

Основаниями для экспертизы также становятся:

▪️ отсутствие части модулей;

▪️ неполная реализация ролей;

▪️ ошибки при создании и редактировании задач;

▪️ неправильный расчёт сроков;

▪️ потеря пользовательских данных;

▪️ отсутствие журнала изменений;

▪️ нестабильная работа интеграций;

▪️ низкая производительность;

▪️ отсутствие документации;

▪️ непередача исходного кода;

▪️ невозможность развернуть систему из переданных материалов;

▪️ спор о проценте готовности;

▪️ необходимость определить стоимость завершения;

▪️ отказ заказчика от подписания акта;

▪️ спор о гарантийном устранении ошибок.

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

📑 Раздел 2. Значение технического задания для экспертной оценки

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

Качественное техническое задание обычно содержит:

▪️ цели разработки;

▪️ описание пользователей;

▪️ перечень модулей;

▪️ функциональные сценарии;

▪️ правила обработки данных;

▪️ требования к интерфейсу;

▪️ роли и права;

▪️ интеграции;

▪️ требования к производительности;

▪️ требования к безопасности;

▪️ порядок тестирования;

▪️ критерии завершённости.

Если документ ограничивается формулировкой «разработать удобную систему управления проектами», эксперт не сможет объективно определить, каким именно должен быть каждый модуль. В таком случае исследуются приложения, протоколы встреч, переписка, макеты и иные материалы, конкретизирующие содержание обязательств.

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

Особенно важно разграничивать исправление дефекта и добавление новой функции. Если изначально предусматривался только один ответственный по задаче, требование назначать несколько исполнителей может являться новой разработкой, а не устранением недостатка.

📂 Раздел 3. Какие материалы необходимо предоставить эксперту

Для полноценного исследования требуется сочетание договорной, технической и цифровой документации.

Эксперту желательно предоставить:

▪️ договор разработки;

▪️ техническое задание;

▪️ приложения;

▪️ дополнительные соглашения;

▪️ спецификации;

▪️ календарный план;

▪️ дизайн-макеты;

▪️ пользовательские сценарии;

▪️ архитектурную документацию;

▪️ схемы базы данных;

▪️ описание программных интерфейсов;

▪️ акты выполненных работ;

▪️ протоколы приёмочных испытаний;

▪️ перечни замечаний;

▪️ переписку сторон;

▪️ отчёты об ошибках;

▪️ материалы судебного дела.

Из цифровых объектов могут потребоваться:

▪️ исходный код;

▪️ репозиторий;

▪️ база данных;

▪️ резервные копии;

▪️ журналы событий;

▪️ конфигурационные файлы;

▪️ сборочные материалы;

▪️ тестовые данные;

▪️ доступ к рабочей среде;

▪️ доступ к тестовой среде;

▪️ система управления задачами разработки.

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

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

🔎 Раздел 4. Порядок проведения IT-экспертизы

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

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

Например, требование «пользователь должен получать уведомление при изменении срока задачи» преобразуется в проверяемый сценарий:

1. Создать задачу.
2. Назначить исполнителя.
3. Изменить срок.
4. Проверить формирование уведомления.
5. Проверить получателя, содержание и время отправки.

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

Дополнительно исследуются:

▪️ база данных;

▪️ права доступа;

▪️ журналы;

▪️ исходный код;

▪️ интеграции;

▪️ производительность;

▪️ безопасность;

▪️ документация;

▪️ возможность развёртывания.

Каждое выявленное несоответствие должно быть воспроизводимым. В заключении указываются начальные условия, последовательность действий, ожидаемый и фактический результат.

📋 Раздел 5. Формирование матрицы соответствия требованиям

Матрица соответствия является одним из наиболее эффективных инструментов экспертного исследования. Она позволяет системно проверить каждое требование и избежать субъективной оценки продукта в целом.

В таблице или рабочем документе для каждого пункта фиксируются:

▪️ номер требования;

▪️ формулировка;

▪️ источник;

▪️ способ проверки;

▪️ фактический результат;

▪️ статус соответствия;

▪️ выявленные отклонения;

▪️ критичность;

▪️ подтверждающие материалы.

Статусы могут быть следующими:

▪️ выполнено полностью;

▪️ выполнено частично;

▪️ формально реализовано, но неработоспособно;

▪️ не реализовано;

▪️ невозможно проверить;

▪️ требование противоречиво;

▪️ относится к дополнительному объёму.

Матрица не должна превращаться в механический подсчёт количества функций. Разные требования имеют разную значимость. Отсутствие изменения цвета кнопки несопоставимо по последствиям с потерей данных или нарушением прав доступа.

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

Такой подход позволяет обоснованно определить не только количество несоответствий, но и реальную степень готовности программного продукта.

🗂️ Раздел 6. Проверка управления проектами и рабочими пространствами

Базовым объектом системы является проект. Эксперт проверяет полный жизненный цикл его создания, настройки, ведения и завершения.

Исследуются:

▪️ создание проекта;

▪️ изменение параметров;

▪️ назначение руководителя;

▪️ добавление участников;

▪️ установка сроков;

▪️ выбор шаблона;

▪️ архивирование;

▪️ восстановление;

▪️ удаление;

▪️ разграничение доступа.

Проект должен сохранять предусмотренные атрибуты: название, описание, период, статус, приоритет, ответственных и связанные документы.

Если техническое задание предусматривает разные типы проектов, проверяется, меняются ли доступные поля, маршруты согласования и отчётность в зависимости от выбранного типа.

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

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

Формальное наличие кнопки «Создать проект» не означает завершённость модуля, если невозможно полноценно управлять участниками, сроками и состоянием проекта.

✅ Раздел 7. Экспертиза модуля задач и подзадач

Модуль задач обычно является центральным элементом системы управления проектами. Его соответствие проверяется особенно подробно.

Эксперт исследует:

▪️ создание задачи;

▪️ редактирование;

▪️ удаление;

▪️ назначение исполнителя;

▪️ установку срока;

▪️ приоритет;

▪️ статус;

▪️ описание;

▪️ вложения;

▪️ комментарии;

▪️ подзадачи;

▪️ зависимости;

▪️ повторяющиеся задачи;

▪️ наблюдателей.

Важно проверить не только пользовательский интерфейс, но и бизнес-логику. Например, система не должна позволять завершить родительскую задачу, если незавершённые подзадачи блокируют её закрытие и такой запрет предусмотрен заданием.

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

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

Проверяется и сохранность истории. Пользователь не должен иметь возможности незаметно изменить срок, исполнителя или содержание задачи, если по техническому заданию все изменения подлежат журналированию.

📅 Раздел 8. Сроки, календарное планирование и зависимости

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

Эксперт устанавливает, учитываются ли:

▪️ рабочие дни;

▪️ выходные;

▪️ праздничные дни;

▪️ часовые пояса;

▪️ персональные графики;

▪️ перенос сроков;

▪️ зависимости;

▪️ контрольные точки;

▪️ просрочка.

Ошибка в расчёте сроков способна привести к недостоверной отчётности и неправильному управлению проектом.

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

Если проект ведётся в нескольких часовых поясах, проверяется единообразие хранения и отображения даты. Одна и та же задача не должна иметь разные сроки у разных участников без предусмотренной причины.

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

Отдельно исследуется календарное представление, диаграмма Ганта и иные визуальные инструменты. Они должны отображать реальные данные, а не формировать отдельную несогласованную копию расписания.

👥 Раздел 9. Роли пользователей и разграничение прав доступа

Система может содержать конфиденциальные данные о проектах, бюджетах, сотрудниках и документах. Поэтому модуль ролей является не только функциональным, но и защитным компонентом.

Эксперт проверяет права:

▪️ администратора;

▪️ руководителя;

▪️ менеджера проекта;

▪️ исполнителя;

▪️ наблюдателя;

▪️ внешнего пользователя;

▪️ аудитора;

▪️ гостя.

Для каждой роли формируется набор разрешённых и запрещённых действий.

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

Проверяется не только скрытие кнопок в интерфейсе. Пользователь не должен получать доступ к запрещённым данным через прямой адрес, программный интерфейс или изменение параметров запроса.

Особенно опасна ситуация, когда система визуально ограничивает роль, но сервер фактически выполняет запрещённую операцию. Такое несоответствие является уязвимостью, а не обычным интерфейсным недостатком.

Эксперт исследует наследование ролей, временный доступ, блокировку учётных записей и фиксацию административных действий.

🔔 Раздел 10. Уведомления и коммуникации внутри системы

Уведомления обеспечивают своевременное информирование участников о назначении задач, изменении сроков, комментариях, согласованиях и просрочке.

Эксперт проверяет:

▪️ события, вызывающие уведомление;

▪️ перечень получателей;

▪️ содержание сообщения;

▪️ время отправки;

▪️ канал доставки;

▪️ пользовательские настройки;

▪️ защиту от дублирования;

▪️ журнал отправки.

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

Недостатком является не только отсутствие сообщения. Ошибочное уведомление может раскрыть конфиденциальные сведения постороннему пользователю или создать ложное представление об изменении проекта.

Эксперт моделирует повторные события, массовые изменения и сбои внешнего почтового сервиса. Проверяется, повторяет ли система отправку, фиксирует ли ошибку и не создаёт ли десятки одинаковых сообщений.

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

📊 Раздел 11. Отчётность, аналитика и учёт трудозатрат

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

Эксперт проверяет отчёты:

▪️ о статусах проектов;

▪️ о просроченных задачах;

▪️ о загрузке сотрудников;

▪️ о затраченных часах;

▪️ о выполнении этапов;

▪️ о бюджете;

▪️ о рисках;

▪️ о производительности команд.

Если система ведёт учёт времени, исследуются ручное и автоматическое внесение трудозатрат, правила округления, корректировка записей и согласование руководителем.

Типичные ошибки:

▪️ двойной учёт времени;

▪️ включение удалённых задач;

▪️ неправильный период;

▪️ потеря части данных;

▪️ несоответствие итогов детализации;

▪️ неверная фильтрация;

▪️ ошибка часового пояса;

▪️ отсутствие разграничения доступа.

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

Если предусмотрен экспорт, проверяется полнота файлов, кодировка, структура столбцов и соответствие данных экранному отчёту.

📁 Раздел 12. Документы, вложения и журнал изменений

Система управления проектами часто используется как хранилище договоров, технических материалов, отчётов, изображений и результатов работ.

Эксперт проверяет:

▪️ загрузку файлов;

▪️ допустимые форматы;

▪️ ограничения размера;

▪️ скачивание;

▪️ удаление;

▪️ версии документов;

▪️ права доступа;

▪️ поиск;

▪️ антивирусную проверку;

▪️ сохранность ссылок.

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

Журнал изменений должен отвечать на вопросы:

▪️ кто выполнил действие;

▪️ когда оно выполнено;

▪️ какой объект изменён;

▪️ что было до изменения;

▪️ что стало после;

▪️ с какого сеанса или устройства поступило действие.

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

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

🔗 Раздел 13. Интеграции с внешними корпоративными системами

Система управления проектами может взаимодействовать с электронной почтой, календарём, корпоративным каталогом, CRM, ERP, бухгалтерской системой, мессенджерами и облачными хранилищами.

Эксперт устанавливает:

▪️ какие интеграции предусмотрены;

▪️ какие фактически подключены;

▪️ как выполняется авторизация;

▪️ какие данные передаются;

▪️ как обрабатываются ошибки;

▪️ как исключаются дубли;

▪️ ведётся ли журнал обмена.

Например, интеграция с календарём должна не только создавать событие, но и корректно обновлять либо удалять его при изменении задачи.

Интеграция с корпоративным каталогом пользователей должна обрабатывать увольнение сотрудника, изменение подразделения и блокировку учётной записи.

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

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

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

⚡ Раздел 14. Производительность, стабильность и масштабируемость

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

Эксперт оценивает:

▪️ время загрузки страниц;

▪️ скорость создания задач;

▪️ формирование отчётов;

▪️ работу поиска;

▪️ одновременные действия пользователей;

▪️ потребление ресурсов;

▪️ количество ошибок;

▪️ стабильность фоновых процессов.

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

Причинами снижения производительности могут быть:

▪️ неэффективные запросы;

▪️ отсутствие индексов;

▪️ неправильное кэширование;

▪️ недостаточные серверные ресурсы;

▪️ блокировки базы данных;

▪️ неоптимальная архитектура;

▪️ чрезмерное количество внешних обращений.

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

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

🛡️ Раздел 15. Информационная безопасность и сохранность данных

Техническое задание может содержать требования к защите информации, резервному копированию и восстановлению после сбоя.

Эксперт проверяет:

▪️ авторизацию;

▪️ политику паролей;

▪️ многофакторную защиту;

▪️ управление сессиями;

▪️ разграничение прав;

▪️ шифрование;

▪️ журналы безопасности;

▪️ резервное копирование;

▪️ восстановление;

▪️ хранение секретных ключей.

Особое значение имеет защита от несанкционированного доступа к проектам и вложениям. Нельзя ограничиваться проверкой интерфейса: прямые запросы к программному интерфейсу также должны контролировать права.

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

Если копии создаются, но хранятся на том же сервере без защиты от удаления, это может не соответствовать требованиям надёжности.

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

Критическая уязвимость может существенно снижать степень готовности системы даже при наличии всей заявленной функциональности.

🧑‍💻 Раздел 16. Исходный код, документация и возможность сопровождения

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

Исследуются:

▪️ структура репозитория;

▪️ история изменений;

▪️ сборочные инструкции;

▪️ зависимости;

▪️ конфигурационные шаблоны;

▪️ миграции базы;

▪️ автоматические тесты;

▪️ документация;

▪️ лицензионные ограничения;

▪️ доступы.

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

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

Отсутствие комментариев само по себе не всегда означает ненадлежащее качество. Однако хаотичная архитектура, скрытые зависимости, жёстко заданные пароли и отсутствие инструкций способны сделать сопровождение другой командой практически невозможным.

Проверяется и документация пользователей и администраторов. Она должна соответствовать фактической версии, а не описывать ранее запланированный или уже изменённый интерфейс.

📋 Раздел 17. Какие вопросы поставить перед экспертом

Перед экспертом следует ставить конкретные технические вопросы, позволяющие сопоставить систему с договорной документацией.

Возможные формулировки:

▪️ Соответствует ли система управления проектами требованиям технического задания?

▪️ Какие требования реализованы полностью, частично или не реализованы?

▪️ Какие функциональные модули фактически присутствуют в системе?

▪️ Соответствует ли модуль управления проектами согласованным сценариям?

▪️ Корректно ли реализованы задачи, подзадачи и зависимости?

▪️ Правильно ли рассчитываются сроки и просрочка?

▪️ Соответствует ли система ролей и прав доступа техническому заданию?

▪️ Корректно ли работают уведомления?

▪️ Достоверно ли формируются отчёты и аналитические показатели?

▪️ Обеспечивается ли сохранность вложений и история изменений?

▪️ Соответствуют ли внешние интеграции согласованным требованиям?

▪️ Обеспечивает ли система требуемую производительность?

▪️ Имеются ли критические ошибки или уязвимости?

▪️ Соответствует ли резервное копирование установленным требованиям?

▪️ Переданы ли полный исходный код и техническая документация?

▪️ Возможно ли развернуть систему из переданных материалов?

▪️ Пригодна ли система для промышленной эксплуатации?

▪️ Каков фактический процент технической готовности?

▪️ Какие недостатки являются устранимыми?

▪️ Какой объём работ необходим для завершения разработки?

▪️ Какова стоимость технически необходимых исправлений?

▪️ Какие замечания относятся к новым требованиям, не предусмотренным первоначальным заданием?

Не рекомендуется ставить вопросы о виновности сторон, расторжении договора, взыскании оплаты или правомерности отказа от приёмки. Такие выводы делает суд.

📚 Раздел 18. Подробные практические кейсы

🔹 Кейс 1. Формально готовая система без полноценного разграничения прав

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

При тестировании заказчик обнаружил, что сотрудники одного подразделения могут открывать проекты другого подразделения через прямые ссылки.

Эксперты Союза «Федерация судебных экспертов» исследовали техническое задание, роли пользователей, программный интерфейс и серверную часть.

В интерфейсе запрещённые проекты не отображались. Однако сервер не проверял права при запросе конкретного идентификатора проекта.

Пользователь мог изменить номер в адресе и получить описание, файлы и комментарии конфиденциального проекта.

Эксперты установили, что визуальное разграничение реализовано, но серверный механизм защиты отсутствует. Недостаток был признан критическим, поскольку создавал риск несанкционированного доступа к корпоративной информации.

🔹 Кейс 2. Неправильный расчёт сроков и просроченных задач

Заказчик обнаружил, что система массово отмечает задачи просроченными раньше установленного срока.

Исполнитель утверждал, что пользователи неправильно задают даты.

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

Сроки хранились в универсальном формате, но при отображении и автоматической проверке система повторно применяла смещение времени.

Для сотрудников, находившихся в другом часовом поясе, задача становилась просроченной за несколько часов до фактического окончания рабочего дня.

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

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

🔹 Кейс 3. Отчётность не соответствовала первичным данным

Система формировала отчёт о загрузке сотрудников, на основании которого руководство распределяло новые проекты. Пользователи заметили, что показатели не совпадают с фактическими задачами.

Эксперты провели контрольный расчёт и сопоставили отчёт с базой данных.

Было установлено, что удалённые задачи продолжали учитываться в загрузке. Повторяющиеся задачи, напротив, включались только один раз независимо от количества созданных экземпляров.

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

Интерфейс отчёта работал без ошибок, однако его содержание было недостоверным.

Экспертиза показала, что формальное наличие аналитического модуля не означает соответствия техническому заданию, если алгоритм расчёта реализован неправильно.

🔹 Кейс 4. Переданный исходный код не позволял развернуть систему

После завершения проекта заказчик решил передать сопровождение другой компании. Новый подрядчик не смог развернуть систему из предоставленного репозитория.

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

Эксперты исследовали репозиторий, рабочий сервер, конфигурацию и историю изменений.

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

Часть секретных параметров была жёстко задана на рабочем сервере и не описана в документации.

Контрольное развёртывание завершалось ошибками и не обеспечивало работу уведомлений и файлового хранилища.

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

🔹 Кейс 5. Комплексная экспертиза корпоративной системы управления проектами

Крупная организация заказала разработку платформы, объединяющей управление проектами, задачами, документами, трудозатратами, бюджетами, отчётностью и корпоративными интеграциями.

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

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

▪️ договор;

▪️ несколько редакций технического задания;

▪️ протоколы совещаний;

▪️ репозиторий;

▪️ исходный код;

▪️ рабочую систему;

▪️ тестовую среду;

▪️ базу данных;

▪️ интеграции;

▪️ отчёты об ошибках;

▪️ историю задач разработки;

▪️ техническую документацию.

Эксперты сформировали матрицу, включавшую несколько сотен функциональных и нефункциональных требований.

Базовые операции с проектами и задачами были реализованы. Пользователи могли создавать проекты, назначать исполнителей, устанавливать сроки, добавлять комментарии и прикреплять файлы.

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

Учёт трудозатрат был реализован частично. Пользователь мог ввести время, но согласование руководителем и защита от одновременного списания часов на разные проекты отсутствовали.

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

Интеграция с корпоративным каталогом создавала пользователей, однако не блокировала их после увольнения.

Система уведомлений формировала большое количество дублирующих писем при массовом изменении задач.

Отчёты о просрочке не учитывали праздничные дни, а показатели загрузки сотрудников расходились с первичными данными.

Нагрузочное тестирование показало устойчивую работу при нескольких десятках пользователей, но при одновременной работе предусмотренного количества сотрудников время ответа возрастало до нескольких минут.

Исходный код был передан, однако документация не соответствовала последней версии, а инструкции по развертыванию отсутствовали.

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

Эксперты разделили результаты на несколько категорий:

▪️ полностью выполненные функции;

▪️ частично реализованные модули;

▪️ формально присутствующие, но функционально незавершённые элементы;

▪️ отсутствующие требования первоначального задания;

▪️ критические ошибки;

▪️ устранимые недостатки;

▪️ новые пожелания заказчика;

▪️ противоречивые требования документации.

Для каждого компонента была определена техническая готовность, критичность и примерная трудоёмкость исправления.

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

📝 Подготовка системы к экспертному исследованию

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

Желательно сохранить:

▪️ резервную копию базы данных;

▪️ копию исходного кода;

▪️ журналы;

▪️ конфигурацию;

▪️ файлы пользователей;

▪️ тестовые данные;

▪️ историю репозитория;

▪️ отчёты об ошибках;

▪️ документацию;

▪️ переписку.

Не следует исправлять ошибки, обновлять библиотеки или менять настройки без создания отдельной доказательной копии.

Каждое замечание рекомендуется описывать как полноценный сценарий:

▪️ роль пользователя;

▪️ исходное состояние;

▪️ последовательность действий;

▪️ ожидаемый результат;

▪️ фактический результат;

▪️ дата и время;

▪️ снимки экрана;

▪️ записи журналов.

Необходимо предоставить тестовые учётные записи для разных ролей и обеспечить безопасный доступ к рабочей либо изолированной копии системы.

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

🏁 Заключение

IT-экспертиза соответствия техническому заданию системы управления проектами позволяет объективно установить, какие требования реализованы, какие выполнены частично и какие отсутствуют.

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

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

Основным инструментом исследования является матрица соответствия, в которой каждое требование связывается с конкретным способом проверки и фактическим результатом.

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

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

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

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

Исследование может использоваться при отказе от приёмки, предъявлении претензии разработчику, взыскании стоимости доработки, защите позиции исполнителя и рассмотрении судебного спора.

Значительный опыт проведения подобных исследований накоплен Союзом «Федерация судебных экспертов», специалисты которого выполняют независимые и судебные IT-экспертизы систем управления проектами, корпоративных платформ, CRM, ERP, баз данных, программных интеграций и информационных систем любой сложности. 📚

Полную контактную информацию, телефон и адрес офиса, а также дополнительные сведения по данному вопросу можно найти на официальном сайте 🔴 https://krimexpert.ru