3. Термины и определения

Полный глоссарий см. в Справочнике SENAR.

Нотация конфигураций: Когда нормативные требования различаются в зависимости от конфигурации, в стандарте используется нотация [Team+: ОБЯЗАТЕЛЬНО] — требование является РЕКОМЕНДУЕТСЯ на Командном уровне, но ОБЯЗАТЕЛЬНО на Корпоративном уровне. Определения конфигураций см. в Section 11. Для начального уровня внедрения см. Основы SENAR.

3.1 AI-агент

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

AI-агенты — не стабильные детерминированные инструменты. Версии моделей различаются по возможностям, профилям галлюцинаций и качеству следования инструкциям. Смена версии модели рассматривается как изменение конфигурации (нормативные требования см. в Section 10.13).

3.2 Супервайзер

Инженер-человек, который направляет AI-агентов, верифицирует результаты, принимает архитектурные решения и обеспечивает соблюдение шлюзов качества. Основной режим работы — AI-направляемая разработка, с ручным кодированием как обоснованным исключением (Section 4.1).

3.3 Пара Супервайзер+AI

Фундаментальная производственная единица: один Супервайзер, работающий с одним или несколькими AI-агентами.

3.4 Контекст

Информация, предоставляемая AI-агенту для получения корректного результата: цель, критерии приёмки, ограничения, знания и связи прослеживаемости.

3.5 Задача

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

3.6 Исследование

Изучение вопроса без полной формальности Задачи. Исследованиям РЕКОМЕНДУЕТСЯ быть ограниченными по времени (Section 6.1). Если исследование приводит к реализации, создаётся Задача.

3.7 Сессия

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

3.8 Инкремент

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

3.9 Шлюз качества

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

3.10 Запись знаний

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

3.11 Тупиковый подход

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

3.12 Контрольная точка

Сохранение контекста в ходе Сессии для предотвращения потери работы.

3.13 Обход шлюза

Задокументированное исключение, позволяющее провести работу через Шлюз качества. Требует обоснования, признания рисков и плана устранения.

3.14 Федерация

Механизм координации нескольких пар Супервайзер+AI в рамках одного или нескольких проектов: отслеживание зависимостей, общие знания, межпроектные оповещения. Требования к федерации при управлении несколькими проектами см. в Section 5.7.

3.15 Время цикла

Время от начала Задачи до её завершения (started_at → completed_at). Отличается от Lead Time тем, что не включает время ожидания в очереди (сравните с Lead Time: created_at → completed_at).

3.16 История

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

3.17 Требование

Задокументированное, верифицируемое утверждение о потребности, возможности или ограничении системы. SENAR определяет три уровня требований: Бизнес-требование (3.18), Системное требование (3.19) и Требование к задаче (3.20). Цель Задачи и критерии приёмки образуют требования на уровне ТЗ.

3.18 Бизнес-требование (БТ)

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

3.19 Системное требование (СТ)

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

3.20 Требование к задаче (ТЗ)

Требование на уровне реализации, декомпозированное из Бизнес- или Системного требования. Соответствует цели и критериям приёмки Задачи. Самый низкий уровень формального управления требованиями; тест-кейсы — артефакты верификации, производные от ТЗ, а не отдельный уровень требований.

3.21 Иерархия требований

Цепочка декомпозиции от бизнес-потребности к единице реализации: БТ → СТ → ТЗ. Не для каждой работы нужны все уровни; глубину определяет Контекстный архитектор исходя из сложности и регуляторного контекста (см. Section 8.2).

3.22 Тестовая модель (ТМ)

Артефакт верификации, производный от Требований к задаче. Определяет способ проверки каждого ТЗ: тест-кейсы, тестовые данные, ожидаемые результаты и метод верификации (автоматический тест, ручная демонстрация, измерение). Тестовая модель — не уровень требований, а мост между требованиями и верификацией. В AI-нативной разработке AI обычно генерирует тесты из ТЗ; Супервайзер проверяет, что сгенерированные тесты действительно покрывают заявленные критерии приёмки.

Уровень формализации Тестовой модели зависит от конфигурации — см. Section 11 и QG-2 (Section 8.3) для нормативных требований.

3.23 Документация кода

Документация уровня модулей, API и архитектуры, служащая постоянным контекстом для AI-агентов. В AI-нативной разработке документация кода имеет двойную аудиторию: Супервайзеров-людей и AI-агентов. Самодостаточная, машиночитаемая документация снижает затраты на контекст для каждой Задачи и повышает качество вывода AI.

3.24 Прослеживаемость

Возможность проследить каждый инженерный артефакт до породившего его требования через цепочку связанных ссылок. Двунаправленная: каждое ТЗ прослеживается вверх до БТ; каждое БТ декомпозируется хотя бы в одно ТЗ. Полная цепочка прослеживаемости: БТ → СТ → ТЗ → ТМ → Код.

3.25 Провайдер модели AI

Внешний сервис, предоставляющий возможности инференса AI-моделей (облачные API, локальные серверы моделей). Провайдеры моделей AI — де-факто поставщики: модель AI является основным производственным инструментом, эквивалентным компилятору. Возможности, ограничения и ценообразование модели меняются по решению провайдера, вне контроля организации.

3.26 Версия модели AI

Конкретный релиз модели AI, идентифицируемый обозначением провайдера. Смена версии может повлиять на качество вывода, стоимость и поведение модели. Версии различаются по возможностям, профилям галлюцинаций, стоимости и качеству следования инструкциям. Базовые значения метрик (FPSR, стоимость/задача) зависят от версии — требования к рекалибровке см. в Section 10.13.

3.27 Расползание области

Незапланированные изменения в реализации Задачи, выходящие за рамки заявленной цели и критериев приёмки. В AI-нативной разработке расползание области проявляется, когда AI-агент правит код за пределами определённых границ, добавляет незапрошенные функции или рефакторит код, не покрытый Задачей.

3.28 Галлюцинация (AI)

Вывод AI, который выглядит правдоподобно, но фактически некорректен: ссылки на несуществующие API, методы, флаги CLI или пакеты; выдуманные пути к файлам; уверенные, но ошибочные утверждения о поведении системы. В контексте зависимостей галлюцинированный пакет — пакет, которого нет в официальном реестре или который ведёт к неожиданному мейнтейнеру.

3.29 WSJF (Weighted Shortest Job First)

Метод приоритизации: отношение Стоимости задержки к Размеру работы. Применяется при Планировании инкремента (Section 7.1) для упорядочивания пула задач. Заимствован из SAFe без изменений.

3.30 Поток создания ценности

Сквозной поток от запроса заинтересованной стороны до поставленного, верифицированного программного обеспечения. В Корпоративной конфигурации (Enterprise) Инкременты группируются по потокам создания ценности с едиными бюджетами (Section 11.3).

3.31 Состязательное ревью

Независимая проверка результатов AI агентом, не имеющим доступа к контексту сессии или ходу рассуждений генерирующего агента. См. Section 10.15, L3.

3.32 Диспетчеризация агента

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

3.33 Профиль агента

Именованный набор скриптов, разрешений и контекста, определяющий возможности и границы AI-агента для конкретной функции. См. Section 5.2.

3.34 Структурированный протокол инструментов

Протокол структурированного взаимодействия AI-агентов с сервисами платформы: самоописывающиеся схемы инструментов, атомарные операции и журналирование аудита. См. Section 5.5.

NOTE: Примеры подходящих протоколов: Model Context Protocol (MCP), вызов функций OpenAI, пользовательские API.

3.35 Операционный скрипт

Структурированная инструкция на естественном языке: как AI-агент выполняет конкретное действие. Содержит триггер, предусловия, алгоритм, постусловия и выходные данные. См. Section 5.3.

3.36 Adversarial Detection Rate (ADR)

Число критических находок состязательного ревью на одну задачу, прошедшую ревью L3. Формула: adversarial_critical_findings / L3_reviewed_tasks. См. Section 9.2.

3.37 Стандарты кода

Документ с обязательными правилами качества кода, загружаемый в контекст AI-агента. Охватывает безопасность, архитектуру, базы данных, API, конкурентность и паттерны тестирования. См. Section 10.15, L2.

3.38 Скрытый дефект

AI-сгенерированный код, который выглядит корректным — проходит автоматические проверки, валидацию типов и самопроверку — но содержит скрытые дефекты (обход защиты, логические ошибки, архитектурные нарушения), обнаруживаемые только при независимом состязательном ревью. Скрытые дефекты возникают, когда AI генерирует код по паттернам, а не на основе семантического понимания. См. Section 10.15.

3.39 FPSR (First-Pass Success Rate)

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

3.40 Обзор качества

Проверка в конце Инкремента: метрики, открытые дефекты, покрытие базы знаний, полнота прослеживаемости. Нормативные требования см. в Section 7.4.

3.41 Менеджер потока

Роль Супервайзера: межкомандная координация, отслеживание зависимостей и эффективность потока в рамках Федерации. Определение и обязанности см. в Section 4.4.

3.42 Контекстный архитектор

Роль Супервайзера: проектирование и поддержание архитектуры знаний, стратегий загрузки контекста и стандартов документации для эффективной AI-направляемой работы. Определение и обязанности см. в Section 4.2.

3.43 Инженер знаний

Роль Супервайзера: фиксация, структурирование и поддержание Записей знаний, тупиковых подходов и повторно используемых паттернов организации. Определение и обязанности см. в Section 4.3.

3.44 Инженер верификации

Роль Супервайзера: проектирование Тестовой модели, проведение состязательных ревью, контроль соблюдения Шлюзов качества. Определение и обязанности см. в Section 4.5.