🔴 Введение: предотвращение дефектов как наиболее эффективная стратегия управления качеством

📋 Согласно стандартам управления проектами (PMBOK, ISO 31000) и данным инженерной практики, стоимость исправления дефекта программного обеспечения (ПО) экспоненциально возрастает по мере его обнаружения на поздних этапах жизненного цикла. Если ошибка, выявленная на этапе анализа требований, стоит 1 условную единицу, то на этапе тестирования готового продукта её исправление может стоить в 50-100 раз дороже. Именно поэтому предпроектная экспертиза ПО или прототипа (макета, wireframes, архитектурных схем) на соответствие техническому заданию (ТЗ) до начала основной разработки (кодинга) является наиболее эффективной стратегией минимизации финансовых, правовых и технических рисков. Данный вид экспертизы позволяет выявить противоречия, неоднозначности, пробелы в требованиях и технологические ограничения на этапе, когда их устранение требует минимальных затрат.

Раздел 1. Объекты предпроектной экспертизы и её цели

1.1. Техническое задание (ТЗ) как основной объект исследования

Техническое задание (ТЗ) представляет собой нормативно-технический документ, определяющий требования к создаваемому программному продукту. В рамках предпроектной экспертизы анализируются:

• Функциональные требования(Use Cases, User Stories).
• Нефункциональные требования(производительность — время отклика, capacity — нагрузка, безопасность — стандарты шифрования, масштабируемость, сопровождаемость, удобство использования).
• Требования к интерфейсу(UI/UX, макеты).
• Требования к интеграции(API, форматы обмена данными: JSON, XML, Protocol Buffers, очереди сообщений: RabbitMQ, Kafka).
• Требования к документации(руководство пользователя, администратора, API-документация).

Цель экспертизы ТЗ — верификация и валидация требований на предмет их полноты, непротиворечивости, однозначности и тестируемости (testability).

1.2. Прототип как объект верификации

Прототип (макет) — это интерактивная или статическая модель будущего интерфейса. Экспертиза прототипа включает:

• Сравнение функциональности прототипа с ТЗ(построение traceability matrix — матрицы трассировки).
• Анализ юзабилити (usability) и эргономики(соответствие ГОСТ Р ИСО 9241-210-2016).
• Выявление неучтенных сценариев(edge cases, альтернативные потоки).

Раздел 2. Методология предпроектной экспертизы

2.1. Инспекция ТЗ (Fagan Inspection)

Метод формальной инспекции (Fagan inspection), разработанный в IBM, предполагает:

2.2. Матрица трассировки требований (Traceability Matrix)

Матрица трассировки — это таблица, связывающая требования ТЗ с элементами прототипа.

Раздел 3. Выявляемые типы дефектов и рисков

Раздел 4. Экономическая эффективность предпроектной экспертизы

Раздел 5. Практические примеры (кейсы)

📁 Кейс №1 (Противоречие в ТЗ для интернет-магазина)

Фабула: Заказчик и разработчик не могли согласовать стоимость проекта. Экспертиза ТЗ выявила противоречие: «Система должна хранить историю всех действий пользователя неограниченно долго» и «Размер базы данных не должен превышать 10 ГБ».

Решение: Скорректировали требования: ограничили глубину хранения истории до 2 лет, увеличили бюджет на СХД (систему хранения данных). Экономия — предотвращение споров на 1,5 млн руб.

📁 Кейс №2 (Отсутствие валидации телефонных номеров)

Фабула: В ТЗ не было требования на валидацию телефонных номеров в форме регистрации. Разработчик не реализовал проверку. В production (продакшен) стали попадать лиды с несуществующими номерами («111-111»). Экспертиза ТЗ до начала разработки, дополнение требованиями валидации.

📁 Кейс №3 (Несовместимость технологий)

Фабула: Заказчик требовал интеграцию с 1С через веб-сервисы (SOAP). Экспертиза показала, что сервер 1С не поддерживает современные стандарты безопасности (TLS 1.2) без дополнительных модулей, что увеличило бы стоимость в 2 раза. Разработчик отказался от проекта.

Раздел 6. Часто задаваемые вопросы

❓ Вопрос 1. Можно ли провести экспертизу, если ТЗ написано в виде wiki-страницы (Confluence, Notion) или PDF без структуры?

✅ Да. Эксперт может извлечь требования из любой формы (структурированной или нет). Однако отсутствие четкой структуры (пронумерованных требований) увеличивает время анализа (на 20-30%).

❓ Вопрос 2. Что делать, если прототип создан в Figma, а ТЗ — в PDF?

📐 Эксперт создает матрицу трассировки в Excel, связывая фреймы Figma с пунктами ТЗ.

❓ Вопрос 3. Должен ли эксперт иметь доступ к исходному коду (если он уже есть)?

🖥️ На стадии предпроектной экспертизы исходный код обычно отсутствует (разработка еще не началась). Если есть ранний прототип (типа MVP), эксперт может его проанализировать.

Заключение и итоговые рекомендации

🎯 Предпроектная экспертиза ПО и прототипа — это не «дополнительная трата», а инвестиция с гарантированной окупаемостью (High ROI), позволяющая избежать дорогостоящих переделок, судебных споров с подрядчиком и репутационных потерь.

Памятка для заказчика предпроектной экспертизы:

✅ Проводите экспертизу ТЗ и прототипа ДО того, как начнется разработка (до старта программирования).

✅ Включайте в договор с разработчиком условие, что выявленные предпроектной экспертизой несоответствия должны быть устранены за счет исполнителя, если они являются ошибкой в ТЗ заказчика (техническое задание — заказчика).

✅ Требуйте от разработчика предоставить план тестирования (Test Plan), который покрывает все функциональные требования ТЗ.

📞 Для заказа предпроектной экспертизы ПО (ТЗ, прототипа, архитектуры), для консультации по вашему конкретным случаю и предварительного расчета стоимости, пожалуйста, заполните форму на нашем официальном сайте или свяжитесь с нашими специалистами. Приглашаем вас в офис Союза «Федерация судебных экспертов».

🌐 Все необходимые ресурсы: образцы чек-листов (checklist) для проверки ТЗ, шаблоны матриц трассировки, перечни вопросов для эксперта — доступны по адресу: https://centrexp.ru/.