8. Шлюзы качества

Автоматизированные точки контроля. Реализуются как код, а не чеклисты. Чеклист проверки AI-вывода см. в Гиде SENAR.

8.1 QG-0: Контекстный шлюз (начало Задачи)

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

Критерии ОБЯЗАТЕЛЬНЫ: цель определена, критерии приёмки верифицируемы, связь с требованием или историей установлена (ОБЯЗАТЕЛЬНО), тип работы назначен.

Критерии ОБЯЗАТЕЛЬНЫ (Командная+): критерии приёмки являются независимо верифицируемыми (каждый может быть протестирован или измерен отдельно); в критерии приёмки включён хотя бы один негативный сценарий (ошибочный случай, некорректный ввод или граничное условие).

Критерии ОБЯЗАТЕЛЬНЫ (все конфигурации, задачи безопасности): задачи, затрагивающие аутентификацию, пользовательский ввод, хранение данных, платежи или внешние API, ОБЯЗАНЫ декларировать поверхность угроз и включать хотя бы один критерий приёмки по безопасности. См. Основы SENAR (Стартовый шлюз, критерий 5) и Section 8.7.

РЕКОМЕНДУЕТСЯ: план, оценка сложности, выявленные релевантные знания.

NOTE: Начальная конфигурация наследует требования Стартового шлюза из Базовой (границы области, негативный сценарий), хотя выше они перечислены как критерии ОБЯЗАТЕЛЬНО уровня «Командная+». На Начальном уровне QG-0 = проверки Стартового шлюза Базовой + структура QG-0 Стандарта. Критерии «Командная+» (независимо верифицируемые КП, негативный сценарий) уже практикуются на Базовом уровне; Начальная формализует их как критерии шлюза.

8.2 QG-1: Шлюз требований (уровень Истории/Инкремента)

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

Критерии ОБЯЗАТЕЛЬНЫ [Командная+]: Бизнес-требование (БТ) существует и утверждено; декомпозиция до Требований к задаче (ТЗ) выполнена на нужную глубину; все ТЗ имеют верифицируемые критерии приёмки; нет осиротевших требований (без Задач реализации).

Критерии РЕКОМЕНДУЕТСЯ (Командная+: ОБЯЗАТЕЛЬНО): требования удовлетворяют согласованности (нет противоречий между ТЗ в рамках Истории); требования удовлетворяют достаточности (покрыты нормальные, граничные и ошибочные сценарии); нефункциональные требования специфицированы, где применимо (производительность, безопасность, доступность).

Глубина декомпозиции

Контекстный архитектор ОБЯЗАН определять глубину декомпозиции [Командная+] с учётом сложности и регуляторного контекста:

NOTE: Для простых функций (БТ → ТЗ, 2 уровня) см. Основы SENAR.

Свойства качества требований

Требования, подаваемые на QG-1, ОБЯЗАНЫ быть верифицируемыми (каждое можно протестировать, измерить или продемонстрировать). Требованиям РЕКОМЕНДУЕТСЯ (Командная+: ОБЯЗАТЕЛЬНО) удовлетворять:

a) Согласованность — отсутствие противоречий с существующими требованиями того же или более высокого уровня; b) Достаточность — набор ТЗ полностью покрывает родительское требование (СТ или БТ); c) Неизбыточность — отсутствие дублирующих требований между Историями; d) Прослеживаемость — каждое ТЗ прослеживается вверх до БТ; каждое БТ декомпозируется хотя бы в одно ТЗ.

Управление изменениями требований

NOTE: Управление изменениями требований применяется в конфигурации Командная+.

Когда утверждённое БТ или СТ изменяется после начала реализации:

a) изменение ОБЯЗАНО быть задокументировано с обоснованием и указанием лица, утвердившего его; b) анализ воздействия ОБЯЗАН выявить все нижестоящие требования и Задачи, затронутые изменением; c) затронутые Задачи, уже находящиеся в состоянии done, ОБЯЗАНЫ быть помечены для повторной верификации — их одобрение QG-2 аннулируется; d) изменённое требование ОБЯЗАНО повторно пройти QG-1 до начала новой реализации; e) Супервайзеры затронутых Задач ОБЯЗАНЫ быть уведомлены об изменении.

Масштабирование: на Командном уровне анализ воздействия ОБЯЗАН поддерживаться инструментарием (связи «родитель/потомок» требований). На Корпоративном уровне изменения требований ОБЯЗАНЫ быть под контролем версий и подчиняться ревью изменений (см. Section 11.3, Требования-как-код).

8.3 QG-2: Шлюз реализации (Задача завершена)

Критерии ОБЯЗАТЕЛЬНЫ: CI проходит, тесты проходят, статический анализ проходит (включая проверку типов, где применимо), нет новых нарушений линтера, критерии приёмки верифицированы Супервайзером, уязвимости безопасности не обнаружены инструментами сканирования.

РЕКОМЕНДУЕТСЯ: покрытие соответствует порогу, нет дублирования, документация обновлена, запись знаний создана при наличии решения/тупикового подхода. Командная+: сгенерированные тесты проверяются на соответствие Тестовой модели (ТМ) — AI-сгенерированные тесты ОБЯЗАНЫ покрывать заявленные критерии приёмки, а не просто достигать покрытия.

РЕКОМЕНДУЕТСЯ (Командная+: ОБЯЗАТЕЛЬНО): манифесты зависимостей, изменённые AI (package.json, requirements.txt, go.mod, Cargo.toml и т.п.), проверяются на галлюцинированные пакеты — несуществующие в официальном реестре или ведущие к неожиданному мейнтейнеру, с опечатками в именах (близкие по написанию к легитимным) и путаницу зависимостей (коллизии внутренних и публичных пространств имён).

8.4 QG-3: Шлюз верификации (слияние — конфигурации Командная+)

Критерии ОБЯЗАТЕЛЬНЫ: приёмочные тесты проходят, сканирование безопасности чистое, регрессий нет, код проверен (по уровню риска — см. 8.7).

РЕКОМЕНДУЕТСЯ: производительность в рамках SLA, соответствие требованиям доступности, межсервисная интеграция верифицирована.

Минимальные критерии проверки AI-вывода

На QG-3 ОБЯЗАНЫ выполняться следующие AI-специфичные проверки:

a) сгенерированный код не вызывает несуществующие API, методы или флаги CLI (проверка на галлюцинации); b) все импортируемые пакеты существуют в манифесте зависимостей проекта (валидация зависимостей); c) сгенерированный код следует архитектурным паттернам и конвенциям проекта (соответствие паттернам); d) сгенерированные тесты покрывают заявленные критерии приёмки, а не просто достигают покрытия (валидность тестов); e) в сгенерированном коде отсутствуют захардкоженные учётные данные, API-ключи или секреты (проверка секретов).

Эти критерии заменяют зависимость от информационного Чеклиста проверки AI-вывода в Гиде SENAR нормативными минимальными требованиями.

8.5 QG-4: Шлюз приёмки (релиз)

Критерии ОБЯЗАТЕЛЬНЫ: проведён Обзор поставки ИЛИ зафиксировано одобрение заинтересованной стороны; QG-3 по-прежнему проходит; стейджинг-окружение (среда, эквивалентная продакшену) верифицировано; приёмка заинтересованной стороной зафиксирована.

8.6 Правила применения

a) шлюзы ОБЯЗАНЫ быть автоматизированы везде, где возможно; критерии, требующие человеческого суждения, требуют явного зафиксированного одобрения; b) каждое прохождение шлюза ОБЯЗАНО порождать аудиторскую запись; c) шлюзы НЕ ДОЛЖНЫ обходиться без задокументированного Обхода шлюза (обоснование + риск + план устранения + одобрение старшего); d) организациям РЕКОМЕНДУЕТСЯ отслеживать частоту Обходов шлюза.

8.7 Проверка на основе рисков

Проверка безопасности для изменений высокого риска: для изменений, затрагивающих аутентификацию, обработку платежей, персональные данные или криптографию, проверка безопасности ОБЯЗАНА выполняться на ВСЕХ уровнях конфигурации, а не только Корпоративная. Это обязательное (ОБЯЗАТЕЛЬНО) требование вне зависимости от размера команды. Организации, разрабатывающие системы, критичные с точки зрения безопасности, ОБЯЗАНЫ внедрять контроли безопасности (QG-3 с Минимальными критериями проверки AI-вывода, проверка кода по уровню риска) вне зависимости от конфигурации.

8.8 Конвейер шлюзов

Исследование ──► (есть результат?) ──► Задача
Задача ──► [QG-0] ──► active ──► [QG-2] ──► done
                                  │
                         (Team+) [QG-3] ──► merged
                                  │
                                [QG-4] ──► released

История/Инкремент: [QG-1] ──► approved ──► Задачи созданы

8.9 Сводка

NOTE: Основы SENAR определяют QG-0 (Контекстный шлюз) и QG-2 (Шлюз реализации) как два шлюза качества. Начальная конфигурация наследует оба шлюза из Базовой (Section 11.1).

8.10 Перекрёстная ссылка по требованиям безопасности

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

NOTE: «Все конфигурации» означает, что требование применяется вне зависимости от размера команды — включая команды Начальной конфигурации. Нормативное утверждение о применимости проверки безопасности см. в 8.7.