Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
План занятия (90 минут)
Цели
- Научить превращать ТЗ в матрицу требование → evidence → статус с консервативной расстановкой четырёх статусов.
- Показать, как обезличенный кандидат (CodeScoring) разбирается по режимам (OSA Proxy / плагины репозитория / CLI-агент / IDE), и почему «поддерживается» без режима — ловушка.
- Отработать перевод спорных требований (qmake, статическая линковка, OSA Proxy по всем пакетным менеджерам, готовые бинарники) в проверяемые сценарии пилота и критерии Go/No-Go.
Материалы
- Текст ТЗ (разделы 3.3–3.5, поставка, требования к исполнителю) — раздаётся как рабочая таблица.
- Заготовка матрицы и Матрица соответствия требованиям OSA SCA.
- OSA Proxy и поддержанные экосистемы, C C++ build scan make cmake qmake, Ограничения готовых бинарников, Критерии Go No-Go после пилота.
- Публичная документация продукта (docs.codescoring.ru) и реестровая карточка — как образцы evidence типа «документация».
Тайминг
| Мин | Блок | Формат | Содержание |
|---|---|---|---|
| 0–10 | Вводный кейс | разбор | Поставщик ответил «да» на все пункты ТЗ. Через месяц пилота выясняется, что Conan нельзя завести в OSA Proxy. Где была ошибка процесса оценки? |
| 10–30 | Теория: методика | лекция | Три типа evidence; четыре статуса; правило консервативности; разделение ТЗ по режимам продукта. |
| 30–45 | Демо матрицы | демо | Преподаватель на проекторе расставляет статусы по 4–5 строкам ТЗ, показывая, как «поддерживается Conan» расщепляется на SCA-манифест (да) и OSA Proxy (риск). |
| 45–70 | ПЗ: своя матрица | работа в парах | Каждая пара берёт назначенный блок требований (OSA-политики / OSA Proxy / SCA C/C++ / поставка) и заполняет матрицу, формулируя сценарий пилота для каждого частично/риск. |
| 70–85 | Сборка пилота и Go/No-Go | обсуждение | Пары сводят сценарии в программу пилота; формулируют стоп-условия Go/No-Go (например: qmake-сборка не даёт корректного графа → No-Go по C/C++ блоку). |
| 85–90 | Рефлексия | плёнка | Что из решений должно лечь в регламент Организации и в протокол пилота. |
Ход (детали активных блоков)
- Демо (30–45). Показать на одной строке оба исхода: SCA-манифест Conan распознаётся, но требование «Firewall для Conan» в proxy-режиме переходит в
риск несоответствия. Подчеркнуть: статус ставится к режиму, а не к «продукту вообще». - ПЗ (45–70). Жёсткое правило: устный ответ на демо не может быть финальным статусом обязательного требования — только промежуточным с обязательным сценарием пилота или запросом письменной гарантии.
- Go/No-Go (70–85). Каждое стоп-условие должно быть бинарным и наблюдаемым на артефакте (SBOM, граф, отчёт политики, реестр unresolved), а не оценочным.
Контрольная точка
Слушатель умеет: (1) для произвольного требования ТЗ назвать режим продукта, тип evidence и статус; (2) превратить спорное требование в сценарий пилота с наблюдаемым результатом; (3) сформулировать критерий Go/No-Go, который нельзя «замылить». Переход к практике: 03 Практическая работа, П31. Пилот CodeScoring make CMake qmake.