13. Соответствие
13.1 Заявление о соответствии
Для заявления о соответствии SENAR организация ОБЯЗАНА:
a) определить применимую конфигурацию: Начальная, Командная или Корпоративная (Section 11); b) реализовать все требования уровня ОБЯЗАТЕЛЬНО применимой конфигурации; c) задокументировать все нереализованные требования уровня РЕКОМЕНДУЕТСЯ с обоснованием; d) хранить свидетельства реализации (аудиторские записи, данные метрик, записи трекера задач).
Заявление о соответствии ОБЯЗАНО использовать следующий формат: «[Организация] соответствует SENAR v[версия], конфигурация [Configuration], [самодекларация | независимая оценка коллегами | независимый аудит], по состоянию на [дата].»
13.2 Уровни соответствия
| Уровень | Описание | Свидетельства |
|---|---|---|
| Самодекларация | Организация самостоятельно оценивает себя по требованиям SENAR | Запись внутренней оценки |
| Независимая оценка коллегами | Оценка проводится практиком SENAR из другой организации | Отчёт коллегиальной оценки |
| Независимый аудит | Оценка квалифицированным аудитором с опытом оценки процессов программной инженерии | Формальный аудиторский отчёт |
Организации МОГУТ заявлять любой уровень соответствия. Более высокие уровни дают более весомые свидетельства для заинтересованных сторон, клиентов и регуляторов.
13.3 Основы SENAR
Команды, практикующие Основы SENAR, не обязаны соответствовать данному Стандарту, но им рекомендуется переход на Начальную конфигурацию (Foundation) по мере готовности. Соответствие Основам SENAR заявляется отдельно по документу Основы SENAR.
Этим задаётся и то, как читать всякий столбец «Базовая» в настоящем Стандарте, и сказано это здесь и более нигде. Такие столбцы информативны. Обязательства настоящего Стандарта начинаются с Начальной (11.4). Там, где столбец «Базовая» называет уровень — как это делает шкала свойств шлюза в 8.6, — он называет, каким этот уровень был бы на таком масштабе, чтобы строка Начальной читалась как шаг от чего-то. Требованием к кому-либо он не является, и ни одно заявление о соответствии по нему не оценивается. То, чего Основы требуют от шлюза, лежит в документе Основ, в его собственном регистре и без машинерии настоящего Стандарта — см. там «Три вещи, которые делают шлюз шлюзом», где стоят (a), (c) и (e), те три, что работают в текстовом редакторе: документ из восьми правил, обзаведшийся процедурой Обхода шлюза, перестал бы быть тем, что выбрали его читатели. Разделы, несущие столбец «Базовая», несут отсылку к настоящему подразделу вместо повторения довода.
13.4 Частичное соответствие
Организации МОГУТ заявлять о частичном соответствии, указывая, каким разделам они соответствуют (например, «Соответствие SENAR Командная (Team) для Разделов 6, 8, 9 и 10»). Заявления о частичном соответствии ОБЯЗАНЫ явно перечислять включённые разделы, и этот перечень ОБЯЗАН сопровождать заявление везде, где заявление публикуется. Заявление, изложенное в формате 13.1 без перечня разделов, есть заявление о ПОЛНОМ соответствии названной конфигурации — что бы ни говорила внутренняя запись оценки.
Заявления о частичном соответствии ОБЯЗАНЫ включать как минимум Разделы 6 (Единицы работы), 8 (Шлюзы качества), 9 (Метрики) и 10 (Операционные правила) — они составляют неделимое ядро практики SENAR. Заявление, охватывающее только определительные разделы (Разделы 1–4), не является валидным заявлением о частичном соответствии.
Заявление о частичном соответствии, включающее Section 8, ОБЯЗАНО включать Section 8.6 ЦЕЛИКОМ. Свойства шлюза неделимы: там, где свойство обязательно на заявленной конфигурации и отсутствует, получается не частично соответствующий шлюз, а проверка, не удовлетворяющая определению шлюза (8.6). Заявить критерии 8.1–8.5, опустив 8.6, значит заявить форму шлюзов без их существа.
13.5 Обработка несоответствий
Когда требование уровня ОБЯЗАТЕЛЬНО невозможно выполнить, организация ОБЯЗАНА задокументировать несоответствие: обоснование, признание рисков, план устранения и одобрение лицом, старшим по отношению к инициатору. Записи о несоответствиях отличаются от операционных Обходов шлюзов (Section 3.13) — они действуют на уровне процесса, а не задачи.
13.6 Поддержание соответствия
Организациям РЕКОМЕНДУЕТСЯ повторно оценивать соответствие на каждой Ретроспективе инкремента (Section 7.7). Там, где эта церемония не проводится — Начальная её опускает (11.1), — организациям РЕКОМЕНДУЕТСЯ повторно оценивать соответствие на каждом Обзоре качества (7.4), и именно этот интервал 8.6(g) читает как пол хранения записей. Заявления о соответствии РЕКОМЕНДУЕТСЯ пересматривать после существенных изменений процессов, смены поколения модели AI (Section 10.13) или перехода между уровнями конфигураций.
Переоценка, требуемая редакцией 1.4
Заявление о соответствии, сделанное против редакции ранее 1.4, против Section 8.6 не оценивалось, потому что этих свойств тогда не существовало. Организации, держащие заявление уровня Командная или Корпоративная, ОБЯЗАНЫ провести переоценку прежде всего против 8.6(b). Шлюз, размещённый после объявленного им эффекта — на проверке, на слиянии или в любой точке, где эффект уже произошёл, — является детективным контролем и 8.6(b) не удовлетворяет, а 8.6(b) ОБЯЗАТЕЛЬНО с Командной.
Часть заявлений, действительных по прежним редакциям, по настоящей недействительна. Это следствие того, что требование сформулировано, а не того, что оно ужесточено: до 8.6 размещение не было задано, поэтому заявление можно было сделать, не задав вопроса. Переоценка требуется, а не рекомендуется. Там, где требование выполнить нельзя, действует 13.5 — несоответствие документируется с обоснованием, признанием риска, планом устранения и одобрением старшего, а заявление исправляется, а не поддерживается. Нотация конфигураций Раздела 3, исправленная в той же редакции, переоценки не требует: ключ приведён к значению, которое всякое его употребление в Разделах 4–13 уже несло, поэтому уровень ни одного требования не изменился.
13.7 Механически проверяемые клаузы
Соответствие большей части настоящего стандарта оценивается чтением: описаний процессов, записей и заявлений о том, что организация делает. Свойства шлюза из Section 8.6 сформулированы здесь в том виде, в каком оценивающий может проверить их против СВИДЕТЕЛЬСТВА, а не против описания. Такой характер имеют не только они — 8.2 (осиротевшие требования), 10.10 (прослеживаемость), 10.13 (идентификатор модели за Сессию), 10.15(c) (зафиксированные находки) и 6.2 (атрибуты Задачи) разрешимы по данным трекера и системы контроля версий, — но именно для этих свидетельство задано настоящим разделом. Они перечислены, чтобы заявитель знал, что хранить, а оценивающий — что спрашивать.
Дальнейшее проверяемо ровно в той мере, в какой записи, требуемые 8.6(g), существуют, полны и сохранены. Эти обязанности установлены там, а не здесь, и оценивающий, чей заявитель не может их предъявить, обнаружил не проходящий шлюз, а неоцениваемое заявление.
| Свойство | Что предъявляется | Как проверяется |
|---|---|---|
| a) Объявленный предотвращаемый эффект | Определение шлюза, называющее эффект | Объявление существует, и к нему можно приложить конкретное предлагаемое действие |
| b) Превентивное размещение | Аудиторские записи (8.6(g)) по шлюзу и по объявленному эффекту | Вердикт зафиксирован до эффекта, а не после |
| c) Соответствие вердикта состоянию | Аудиторская запись, указывающая состояние, для которого вынесен вердикт | Ни один вердикт не применён к состоянию, отличному от названного им |
| d) Привязка к измеренному дайджесту | Зафиксированный дайджест и артефакты, которые он называет | Дайджест, пересчитанный по этим артефактам, равен зафиксированному значению |
| e) Отказ в запрещающее состояние | Записи прогонов, не давших вердикта, и проверки, от которых шлюз зависел, с результатом каждой (8.6(g)) | Ни в одном таком случае положительный вердикт не зафиксирован и не использован как основание; ни один вердикт не является положительным, пока проверка, от которой он зависел, результата не дала; а там, где шлюз размещён превентивно, объявленный эффект был предотвращён |
Они различаются степенью механичности, и различие не скрывается: (d) пересчитываем оценивающим, у которого есть артефакты и запись о множестве, покрытом дайджестом; (b), (c) и (e) разрешимы по записям, требуемым 8.6(g), — об исполнении шлюза и о допуске эффекта, — и ни по чему иному; (a) — проверка наличия плюс тест применимости из 8.6(a), которому нужен читатель.
Два ограничения уместны здесь, а не в самостоятельном открытии читателя. Первое: (d) устанавливает, что зафиксированный дайджест и множество артефактов соответствуют друг другу; оба производит заявитель, поэтому пересчёт показывает внутреннюю согласованность, а не момент фиксации. Второе, сказанное в 8.3 применительно к самому шлюзу: ни одна из этих проверок не является аттестацией против участника, намеренного ввести в заблуждение. Это контроли против расхождения свидетельства с тем, что оно описывает. Оценивающему, ищущему уверенность против намеренного заявителя, следует смотреть на уровень соответствия (13.2) и на то, кто произвёл записи, а не на ещё одну строку этой таблицы.
Настоящий раздел ничего не добавляет к Section 13.2. Три уровня соответствия не изменены, четвёртый не вводится. Меняется то, что на любом из них часть оценки может опираться на свидетельство, а не на утверждение.
NOTE: Настоящий стандарт не определяет схемы сертификации, не ведёт реестра заявителей и не требует платной оценки. Заявление о соответствии делает сама организация, по 13.1. Ничто в настоящем разделе не создаёт органа и не делает оценку третьей стороной условием заявления о соответствии.