Справочник понятий сервисной модели

Этот справочник заменяет учебный corpus как публично-безопасный слой сносок. Он нужен не для обучения “с нуля”, а для того, чтобы SJM-заметки оставались самодостаточными: читатель может быстро понять термин, не переходя в закрытый или сырьевой корпус.

Зачем нужен этот слой

Держит короткие определения рядом с сервисной моделью.
Убирает зависимость SJM от внешнего учебного корпуса.
Помогает публиковать заметки в Digital Garden без ссылок на приватные summary notes.
Сохраняет смысловые сноски на testing, architecture и process modeling.

Software testing

Систематическая деятельность по получению информации о качестве сервиса и рисках его использования. В SJM это не только проверка интерфейса, но и проверка процесса, данных, статусов, SLA, поддержки, интеграций и recovery.

Test oracle

Источник ожидаемого результата. Для сервиса oracle может быть требование, SLA, регламент, база знаний, system of record, лог, мониторинг, согласованный пример или юридически проверенная формулировка.

Acceptance criteria

Условия, по которым команда и заказчик понимают, что требование или сервисный шаг можно принять. В SJM критерии приёмки должны быть связаны с клиентским статусом, внутренним workflow, данными, SLA, коммуникацией и evidence.

Entry and exit criteria

Entry criteria определяют, когда проверку или запуск можно начинать; exit criteria — когда можно считать этап завершённым. Для сервиса это readiness поддержки, доступность данных, настроенные категории обращений, мониторинг, KB и понятный regression set.

Risk-based testing

Подход, где глубина проверки зависит от риска: impact, likelihood, detectability, recoverability и customer harm. В сервисной модели это помогает проверять прежде всего те ветки, где ошибка реально вредит клиенту или операционной устойчивости.

Static testing

Проверка артефактов без запуска системы: SJM, BPMN, требования, SLA-правила, шаблоны ответов, KB-статьи, ADR, risk notes. Полезно до разработки и до релиза.

Regression testing

Повторная проверка критичных сценариев после изменения. В сервисной модели regression должен покрывать статусы, SLA, routing, уведомления, интеграции, поддержку и recovery.

Defect

Расхождение между ожидаемым и фактическим поведением. Для сервиса дефектом может быть не только баг приложения, но и неверный статус, плохая маршрутизация, неполный ответ поддержки, сломанный SLA timer или отсутствие monitoring-сигнала.

Defect report

Запись о дефекте, которая помогает понять, приоритизировать и исправить проблему. Для сервиса хороший defect report содержит ожидаемый и фактический результат, условия, шаги воспроизведения, evidence, impact, workaround, owner и связи с SJM/BPMN/test case/change request.

Root cause analysis

Поиск первопричины проблемы: что произошло, почему это произошло и как снизить вероятность повторения. В сервисной модели RCA связывает дефекты, инциденты, повторные обращения и SLA-просрочки с изменениями в процессе, системе, KB, мониторинге или требованиях.

Coverage

Явное описание того, какие части сервиса проверены. Хороший coverage для SJM включает клиентский путь, процесс, данные, интеграции, поддержку, риски и recovery.

Checklist

Набор идей проверок. В SJM чек-листы удобны для быстрого покрытия сценариев, статусов, исключений, support readiness, интеграций, SLA и recovery без преждевременной детализации каждого шага.

Test case

Формальная проверка с целью, предусловиями, входными данными, шагами, ожидаемым результатом и evidence. Для сервиса тест-кейс должен ссылаться на SJM-шаг, требование или oracle и показывать, где увидеть результат: CRM, workflow, лог, мониторинг, SLA-отчёт или тикет.

Equivalence partitioning

Разделение входных условий на группы, которые должны вести себя одинаково. Полезно для клиентских сегментов, категорий обращений, типов операций, каналов, статусов и лимитов.

Boundary value analysis

Проверка граничных значений: сроки, суммы, лимиты, возраст, количество попыток, время SLA, число документов. В сервисах ошибки часто появляются именно на границах правил.

Positive and negative testing

Positive testing проверяет нормальное использование сервиса, negative testing — отказные, неверные и исключительные условия. Для SJM важны оба слоя: positive показывает доставку обещания, negative показывает устойчивость к ошибкам, дублям, timeout, неполным данным и ручным обходам.

Test automation

Автоматизация повторяемых проверок и сбора evidence. В сервисной модели полезна для smoke/regression, SLA timers, интеграций, сверок данных, мониторинга, логов и recovery drills, но плохо заменяет анализ требований, exploratory review и человеческую оценку клиентского вреда.

Architecture characteristics

Качества системы, важные для сервиса: availability, latency, security, privacy, scalability, maintainability, observability, testability, deployability, resiliency, supportability.

Trade-off analysis

Разбор компромиссов архитектурного или процессного решения. Например, более быстрый запуск может ухудшить supportability, а более строгая безопасность может увеличить friction для клиента.

Fitness function

Проверяемый контроль архитектурного качества: метрика, тест, alert, dashboard, SLA report, checklist или synthetic check. В SJM помогает не просто назвать качество, а понять, как оно контролируется.

Architecture decision record

Короткая запись архитектурного решения: контекст, варианты, выбранное решение, последствия. Полезно для retry, fallback, source of truth, data access, routing и интеграций.

Coupling and cohesion

Coupling показывает связанность компонентов, cohesion - насколько элементы внутри границы относятся к одной задаче. Для сервиса это помогает не создавать изменения, которые ломают соседние процессы.

Modularity

Разделение сервиса на понятные части с управляемыми границами. Полезно для сопровождения, тестирования, ownership и change management.

Enterprise architecture

Описание организации, возможностей, процессов, систем и данных на уровне предприятия. Для SJM это контекст, но не замена клиентскому пути и операционной модели.

Viewpoint

Представление сервиса глазами конкретного stakeholder: клиента, поддержки, операций, IT, рисков, compliance, владельца сервиса. Один сервис требует нескольких viewpoint.

BPMN

Нотация для описания процесса: события, задачи, шлюзы, роли, потоки. В сервисной модели BPMN показывает “как течёт процесс”, но не заменяет SJM и клиентский опыт.

UML

Язык моделирования для use case, sequence, state, class/component views. В SJM полезен для сценариев, состояний заявки/операции и взаимодействия систем.

TOGAF

Enterprise architecture framework. В SJM полезен как источник мышления о capabilities, governance, roadmap и viewpoints, но не как обязательная тяжёлая методология для каждой карты.