System Analyst Quest · v2

Практический атлас: системный анализ → работа в жизненном цикле → бизнес-системный анализ и архитектура. Дата пересмотра: 08.11.2026.

Это авторская последовательность обучения на основе предоставленных Map.txt и T-SQL Fundamentals с явно обозначенными дополнениями. Общепринятого единственного порядка и универсальной границы BA/SA/BSA нет: обязанности зависят от команды. Здесь главы обозначают фокус практики, а не обязательные ступени должностей.

Траектории

Траектория	Состав	Квестов	Оценка активной работы, ч
Практика SA	core	46	239–433
Рост в BSA	core, bsa, practice	59	328–591
Рост в архитектуру	core, architecture, practice	60	339–609
Весь атлас	core, bsa, architecture, practice, elective	76	445–795

Оценки — диапазоны для учебной работы с чтением, практикой и исправлениями, не подтверждённые сроки и не гарантия готовности к работе. Настройка сложной инфраструктуры и ожидание внешнего ревью могут добавить время. После первых трёх квестов пересчитай по фактическому темпу. Базу можно проходить быстрее, доказывая уже освоенное готовыми работами.

Почему такой порядок

Сначала роль, проблема, участники и AS-IS/TO-BE. Детальные требования уточняются на основе процесса, затем проверяются обратно по нему.
Перед данными и API — основы сети, типов, JSON/XML/XSD и устройства приложения. Это небольшой фундамент, не курс сетевого администратора.
Сначала модель данных и SQL; затем двухсессионные гонки, ограничения и миграции. Нельзя считать текстовое объяснение транзакции заменой её воспроизведения.
После HTTP/API — sequence-диаграммы и модель доступа. Затем асинхронные контракты, доставка, повторы и отказы.
Перед первой защитой — handoff, проверки/UAT, запуск, наблюдаемость, восстановление и оценка результата.
После первой защиты доступны две траектории роста. BSA углубляет ценность и изменения между системами; архитектура — качества, границы, распределённость и эволюцию. TOGAF идёт после архитектуры приложения/решения.
Самостоятельный кейс проверяет перенос навыка. Узкие сети, корпоративная ИБ и advanced SQL выбираются по рабочему домену.

Требования, процессы и проектирование на практике развиваются итеративно. Этот порядок задаёт первый проход; после каждого нового ограничения возвращайся к связанным артефактам. Зависимости модулей — рекомендуемые условия готовности, не запрет просмотра.

Как закрывать квест

Изучи указанный фокус; начни с одного опорного источника, остальные используй для сверки или углубления.
Сделай артефакт и приложи проверяемый результат. Выполни все критерии и ответь на вопрос защиты.
Отметка в трекере подтверждает самооценку; self-review, AI-review и внешнее ревью явно различаются.
Для каждой главы прогони контрольный сценарий из CHAPTER_CHECKPOINTS.md. Rubric 0–3 находится в SKILL_MATRIX.md.
Повторное объяснение через 1/7/21 день — предложенный ритм, а не автоматическая сертификация памяти.
Исходные и новые темы различимы: материалы Map.txt имеют номера #001–#132; добавления перечислены в materials/SUPPLEMENTS.md.

Главы

Глава	Модули	Результат главы
F. Ориентация	00	Есть рабочая среда, карта ролей и честная диагностика навыков.
BA. Бизнес-анализ и требования	01 → 03 → 02	Цель, участники, AS-IS/TO-BE, требования и приёмка согласованы между собой.
SA. Системный анализ	T → 04 → 05 → 10 → 06 → 08 → 07	Спецификация реализуема: данные, SQL, API, события и права не противоречат требованиям.
PR. SA в жизненном цикле продукта	11 → 12 → 09	Досье воспроизводимо, изменение и отказ разобраны, выполнена первая защита.
BSA. Бизнес-системный анализ	13 → 14 → B → C	Есть business case, landscape, ownership, transition plan и аналитическая витрина.
AR. Архитектура	15 → 16 → 17 → A	Есть quality scenarios, C4/arc42, ADR, capacity, resilience и enterprise roadmap.
CP. Самостоятельная практика	18	Решён незнакомый кейс; уровень подтверждён работами, а не только самооценкой.
SP. Специализации	D → E → S	Выбираются под домен и задачи; не обязательны для первой практики SA.

Глава F. Ориентация

Профессия, система, инструменты.

Чекпоинт: Есть рабочая среда, карта ролей и честная диагностика навыков.

Модуль 00. Профессия и рабочий набор

Понять границы роли, системное мышление и способ вести доказательства.

Перед модулем: нет обязательной подготовки.

00-1. Карта профессий и системы · 3–6 ч

Результат: portfolio/foundation/roles.md

Изучить: Роль аналитика; System thinking; Границы ответственности.

Различи BA, SA, BSA, product owner, QA, разработчика, solution и enterprise architect на одном кейсе.
Опиши систему как людей, процессы, данные и технологии: граница, окружение, обратная связь.
Составь RACI для 5 решений, отмечая, что реальные роли зависят от команды.
Обзорно сравни Waterfall, iterative/incremental delivery, Agile, Scrum и Kanban; объясни место анализа на всём жизненном цикле.

Условия прохождения:

[ ] Для каждой роли указан результат и зона взаимодействия.
[ ] Проблема рассмотрена на уровне всего процесса, а не одного экрана.
[ ] Есть риски локальной оптимизации и вопросы к владельцу решения.

Защита: Можно ли улучшить скорость оператора и одновременно ухудшить результат для клиента?

Map.txt: #001.

Дополнения: iiba, scrum (см. materials/SUPPLEMENTS.md).

00-2. Среда и журнал решений · 4–7 ч

Результат: portfolio/foundation/toolbox.md

Изучить: Markdown/Git; DevTools/curl; Issue tracker и база знаний.

Создай папку артефактов с навигацией, словарём и журналом решений.
Научись сохранять исходники диаграмм, читать diff и различать версии в Git; локальная учебная практика без обязательной публикации.
Выбери средства SQL Server, HTTP-запросов, BPMN/UML и проверки контрактов; запиши команды и версии.

Условия прохождения:

[ ] Есть воспроизводимый способ открыть исходники и результаты.
[ ] Продемонстрирован diff одного смыслового изменения.
[ ] Тестовые данные вымышлены, секретов нет.

Защита: Как восстановить, почему поле стало обязательным месяц назад?

Дополнения: iiba, scrum (см. materials/SUPPLEMENTS.md).

00-3. Диагностика стартовых навыков · 2–4 ч

Результат: portfolio/foundation/baseline.md

Изучить: Диагностика; Доказательства навыка; Работа с неопределённостью.

Ответь без конспекта на 6 вопросов из 00_START.md.
Сопоставь каждый ответ с примером работы, а не со знакомым термином.
Выбери первую траекторию и зафиксируй неизвестные темы; пока не назначай срок завершения.

Условия прохождения:

[ ] Отделены уже подтверждённые навыки и темы для изучения.
[ ] Ни один незнакомый блок не отмечен пройденным по самоощущению.
[ ] Есть первая сессия на 45–60 минут с одним результатом.

Защита: Что из своих знаний ты можешь показать на незнакомом кейсе?

Дополнения: iiba, scrum (см. materials/SUPPLEMENTS.md).

Глава BA. Бизнес-анализ и требования

Понять проблему до проектирования.

Чекпоинт: Цель, участники, AS-IS/TO-BE, требования и приёмка согласованы между собой.

Модуль 01. Разведка и границы

Превратить расплывчатую просьбу в понятную задачу бизнеса.

Перед модулем: 00.

01-1. Бриф проекта · 3–6 ч

Результат: portfolio/01-brief.md

Изучить: Problem statement; Business goal; Scope/context; Assumptions/constraints.

Прочитай сценарий в SCENARIO.md.
Опиши проблему, пользователей, цель и показатель результата.
Раздели границы первой версии, ограничения и предположения.

Условия прохождения:

[ ] Есть одна измеримая цель и исходная точка, даже если это учебное допущение.
[ ] Есть минимум 5 пунктов вне scope.
[ ] Предположения и неизвестные не выданы за факты.

Защита: Заказчик требует «просто сделать удобно». Какие три уточнения задашь?

Дополнения: iiba (см. materials/SUPPLEMENTS.md).

01-2. Карта участников · 3–6 ч

Результат: portfolio/02-stakeholders.md

Изучить: Stakeholder map; Power/interest; Elicitation questions; Conflicts and agreements.

Выдели клиента, оператора, мастера, владельца и внешние системы.
Составь таблицу: интерес, влияние, ожидания, способ согласования.
Подготовь 10 вопросов интервью и отметь 3 потенциальных конфликта.

Условия прохождения:

[ ] Каждое важное решение имеет согласующего.
[ ] Конфликт описан через разные интересы.
[ ] Ответы учебных ролей явно помечены как смоделированные.

Защита: Владелец хочет больше заявок, мастер — меньше перегрузки. Как уточнишь цель?

Map.txt: #005, #006.

Дополнения: iiba (см. materials/SUPPLEMENTS.md).

01-3. Чекпоинт: согласование задачи · 2–4 ч

Результат: portfolio/03-discovery-review.md

Изучить: SDLC; Discovery; Acceptance owner; Decision log.

Объясни путь задачи через discovery, анализ, разработку, проверку и эксплуатацию.
За 5 минут защити бриф и карту участников.
Запиши замечания, решения и открытые вопросы.

Условия прохождения:

[ ] Проблема отделена от предлагаемой функции.
[ ] Описано, кто и как примет результат.
[ ] Устранены противоречия между брифом и картой участников.

Защита: Заказчик добавил онлайн-оплату. Что уточнишь до включения в первую версию?

Map.txt: #001.

Дополнения: iiba (см. materials/SUPPLEMENTS.md).

Модуль 03. Бизнес-процессы и жизненный цикл

Сделать ход процесса и жизненный цикл записи видимыми.

Перед модулем: 01.

03-1. BPMN: как есть и как будет · 5–9 ч

Результат: portfolio/07-process.bpmn + экспорт PDF/SVG

Изучить: BPM vs BPMN; AS-IS/TO-BE; Pool/lane; Events/gateways; Human/document/integration-centric BPM.

Нарисуй AS-IS: запись по телефону.
Нарисуй TO-BE: онлайн-запись с подтверждением и напоминанием.
Добавь внешнего отправителя уведомлений и ветку его недоступности.

Условия прохождения:

[ ] Есть начало, конец и ответственные участники.
[ ] Sequence flow не пересекает pools; обмен между pools показан message flow.
[ ] Для развилок понятны условия и завершение альтернативных веток.

Защита: Провайдер уведомлений не отвечает. Должна ли исчезнуть сама запись?

Map.txt: #036, #037, #038, #039.

Дополнения: uml (см. materials/SUPPLEMENTS.md).

03-2. UML: сценарии и состояния · 5–9 ч

Результат: portfolio/08-models.md + исходники диаграмм

Изучить: UML use case; State machine; Transition/guard; Entity lifecycle.

Нарисуй use case diagram с границей системы и ролями, затем state diagram записи.
Для переходов укажи событие, условие, результат; раздели состояние объекта и шаг процесса.
Покажи создание, подтверждение, отмену, оказанную услугу и недопустимые переходы.

Условия прохождения:

[ ] У каждого перехода есть событие и условие.
[ ] Use case показывает цели ролей, а не порядок экранов.
[ ] Терминология и допустимые статусы согласованы с процессом.

Защита: Чем состояние «отменена» отличается от действия «отменить запись»?

Map.txt: #040, #041.

Дополнения: uml (см. materials/SUPPLEMENTS.md).

03-3. Чекпоинт: walkthrough · 2–4 ч

Результат: portfolio/09-model-review.md

Изучить: Model walkthrough; Semantic consistency; Diagram audience.

Прогони по моделям 5 черновых сценариев из discovery. Каталог детальных требований будет в модуле 02; после него вернись для сверки моделей.
Найди 3 места неоднозначности и исправь их.
Объясни, зачем каждая диаграмма нужна адресату.

Условия прохождения:

[ ] Каждая ветка заканчивается понятным результатом.
[ ] Статусы одинаково называются во всех моделях.
[ ] Нет диаграмм, созданных только ради количества.

Защита: Новый разработчик должен объяснить процесс по твоим материалам за 5 минут.

Дополнения: uml (см. materials/SUPPLEMENTS.md).

Модуль 02. Требования

Описать поведение так, чтобы разработчик и тестировщик понимали его одинаково.

Перед модулем: 03.

02-1. Каталог требований · 5–9 ч

Результат: portfolio/04-requirements.md

Изучить: Business/stakeholder/solution/transition requirements; Functional/NFR; Quality criteria; Glossary.

Различи business, stakeholder, solution и transition requirements; составь 12 функциональных требований с ID, источником и приоритетом.
Добавь 6 измеримых нефункциональных требований с условиями измерения.
Выдели бизнес-правила и словарь из 15 терминов.

Условия прохождения:

[ ] В одном требовании одна проверяемая мысль.
[ ] У каждого требования есть источник или пометка «допущение».
[ ] НФТ содержат метрику, нагрузку/контекст и порог как учебное предложение.

Защита: Перепиши «система должна работать быстро» в проверяемый критерий.

Дополнения: iiba, ireb (см. materials/SUPPLEMENTS.md).

02-2. Сценарии и приёмка · 5–9 ч

Результат: portfolio/05-use-cases.md

Изучить: Use case; User story; Acceptance criteria; Alternative flows.

Опиши создание, перенос и отмену записи.
Для каждого сценария укажи предусловия, результат, основной и альтернативные потоки.
Напиши минимум 8 критериев Given/When/Then, включая ошибки.

Условия прохождения:

[ ] Есть случай, когда слот уже занят.
[ ] Есть случай отмены после допустимого срока.
[ ] Критерии не зависят от конкретного интерфейса без причины.

Защита: Пользователь дважды нажал «Записаться». Какой результат ожидается?

Дополнения: iiba, ireb (см. materials/SUPPLEMENTS.md).

02-3. Чекпоинт: трассировка и изменение · 3–6 ч

Результат: portfolio/06-traceability.md

Изучить: Traceability; Baseline/version; Change impact; Approval.

Свяжи цель → требование → сценарий → критерий проверки; введи baseline, владельца и порядок согласования.
Обработай изменение: отмена допускается не позже чем за 2 часа.
Обнови затронутые требования и заведи журнал изменений.

Условия прохождения:

[ ] Все 12 функциональных требований связаны с проверкой.
[ ] У изменения есть затронутые сценарии и данные.
[ ] Не осталось противоречащих версий правила отмены.

Защита: Какие артефакты придётся пересмотреть, если появится предоплата?

Дополнения: iiba, ireb (см. materials/SUPPLEMENTS.md).

02-4. Правила, прототип и границы интерфейса · 5–9 ч

Результат: portfolio/requirements/rules-and-ui.md

Изучить: Decision table; Wireframe; User story и use case; Приоритизация MoSCoW.

Составь decision table для поздней отмены, прав и состояния записи; найди противоречия и недостающие комбинации.
Нарисуй low-fidelity прототип создания записи: поля, валидации, пустые/ошибочные состояния, доступность с клавиатуры.
Свяжи поля с терминами и требованиями, отдели бизнес-ограничения от решений UI.

Условия прохождения:

[ ] Для выбранных комбинаций таблица даёт единственный согласованный результат.
[ ] Есть поведение для недоступного слота и ошибки отправки.
[ ] Прототип не подменяет требования и не фиксирует лишних технологий.

Защита: Как одна и та же бизнес-валидация должна работать в UI и API?

Дополнения: iiba, ireb (см. materials/SUPPLEMENTS.md).

Глава SA. Системный анализ

Данные, контракты, поведение и защита.

Чекпоинт: Спецификация реализуема: данные, SQL, API, события и права не противоречат требованиям.

Модуль T. Технический фундамент

Получить основы сети, форматов и устройства приложения до SQL и API.

Перед модулем: 02.

T-1. Путь запроса и сеть · 6–11 ч

Результат: portfolio/foundation/network-path.md

Изучить: OSI/TCP-IP; DNS/TLS/HTTP; MAC/IP/NAT; TCP/UDP/QUIC; Сеть и прикладной доступ.

Разложи браузерный запрос на DNS, IP/порт, TCP или QUIC, TLS и HTTP, объясни условность связи с OSI.
Различи MAC/IP, public/private IP, NAT, switch/router, TCP/UDP; укажи роль VPN и firewall.
Выполни DNS lookup и curl -v на безопасном публичном ресурсе; обезличь результаты и локализуй один смоделированный отказ.

Условия прохождения:

[ ] Есть наблюдение и отдельно гипотеза о ненаблюдаемом участке.
[ ] Не утверждается, что UDP даёт надёжность TCP или NAT заменяет контроль доступа.
[ ] Объяснено различие сетевого timeout и HTTP-ответа с ошибкой.

Защита: Почему успешный ping не доказывает, что API работает?

Map.txt: #093, #094, #102, #105, #107, #108, #109, #110, #113, #116, #117, #118, #119, #122, #123, #124.

Дополнения: http, c4, xsd, json (см. materials/SUPPLEMENTS.md).

T-2. Форматы и схемы · 5–9 ч

Результат: portfolio/foundation/formats/README.md

Изучить: JSON/XML/YAML; XSD/namespaces; Типы и время.

Опиши одну запись в JSON, XML и YAML; различи отсутствие поля, null, пустую строку, число и строку.
Разбери XML namespace и простую XSD; проверь валидный и невалидный документ выбранным инструментом.
Зафиксируй UTF-8, timestamp/timezone, денежные значения и идентификаторы в словаре обмена.

Условия прохождения:

[ ] JSON/XML/YAML проверены парсерами, XML также XSD-валидатором.
[ ] Для неверного типа и обязательного поля есть фактическая ошибка проверки.
[ ] Формат данных не назван транспортным протоколом.

Защита: Значения 00123 и 123 всегда обозначают один ID?

Map.txt: #023, #024, #025.

Дополнения: http, c4, xsd, json (см. materials/SUPPLEMENTS.md).

T-3. Как устроено приложение · 4–7 ч

Результат: portfolio/foundation/system-context.md

Изучить: Client/server; C4 context/container; Cloud service models.

Нарисуй context и container-схемы: клиент, backend, БД, identity provider и уведомления.
Различи процесс, сервис, API, базу данных, контейнер C4 и контейнер Docker.
Покажи sync/async-границы и сравни IaaS/PaaS/SaaS как модели ответственности.

Условия прохождения:

[ ] Видны внешние системы и владельцы.
[ ] У каждого блока есть назначение и данные взаимодействия.
[ ] C4 container не сводится к Docker или конкретному серверу.

Защита: Как изменятся обязанности команды при переходе от IaaS к PaaS?

Map.txt: #022.

Дополнения: http, c4, xsd, json (см. materials/SUPPLEMENTS.md).

Модуль 04. Данные и целостность

Спроектировать данные, которые сохраняют бизнес-правила.

Перед модулем: T.

04-1. ER-модель · 5–9 ч

Результат: portfolio/10-data-model.md + ERD

Изучить: Entities/attributes/relationships; PK/FK/cardinality; Normalization 1NF–3NF; Data dictionary.

Выдели клиента, мастера, услугу, слот и запись; различи relation/table и обзорно разбери назначение правил Кодда без заучивания списка.
Определи ключи, связи и обязательность; добавь словарь полей.
Доведи модель до 3NF и покажи один устранённый пример аномалии.

Условия прохождения:

[ ] Кардинальности и nullable-поля явно указаны.
[ ] Типы и единицы измерения определены.
[ ] Правило вместимости слота сформулировано как инвариант; реализацию конкурентного контроля отложи до модуля 10.

Защита: Мастер оказывает несколько услуг. Почему строка с перечнем услуг проблематична?

Map.txt: #009, #010, #011.

Дополнения: mongo (см. materials/SUPPLEMENTS.md).

04-3. Чекпоинт: выбор хранилища · 3–6 ч

Результат: portfolio/12-storage-adr.md

Изучить: Relational/document/key-value; BCNF/4NF/5NF/6NF: обзор; Access patterns; Storage ADR.

Сравни relational, document и key-value для трёх типов данных проекта.
Выбери основное хранилище и запиши ADR с компромиссами.
Объясни 1NF–3NF, обзорно BCNF/4NF/5NF и отдельно границы применимости 6NF; высокие нормальные формы не обязательная цель каждой схемы.
Обзорно сгруппируй типы из статьи «15 types»: graph, time-series, search, column, vector и другие; для каждого укажи характерную задачу, не углубляясь в администрирование.

Условия прохождения:

[ ] Выбор привязан к запросам и целостности.
[ ] Есть хотя бы одна отвергнутая альтернатива с причиной.
[ ] Основной источник истины указан явно.

Защита: Почему все данные проекта необязательно хранить в MongoDB?

Map.txt: #007, #009, #010, #011.

Дополнения: mongo (см. materials/SUPPLEMENTS.md).

04-4. Document model на MongoDB · 6–11 ч

Результат: portfolio/data/mongodb-model.md

Изучить: MongoDB collections/documents; Embedding/reference; Access patterns и schema validation.

Спроектируй документ каталога услуг и два варианта связи мастеров: embedding и references.
Запиши 3 примера MongoDB query/aggregation и необходимые indexes/validation; выполни их на учебных данных выбранной среды.
Сравни требования к целостности, росту документа и запросам с relational-моделью.

Условия прохождения:

[ ] Есть BSON/JSON-примеры и реальные результаты трёх запросов.
[ ] Описано, что происходит при обновлении вложенных данных.
[ ] MongoDB не объявлена не имеющей схемы, транзакций или ограничений вообще.

Защита: Почему выбор document DB не отменяет моделирование данных?

Map.txt: #015.

Дополнения: mongo (см. materials/SUPPLEMENTS.md).

Модуль 05. SQL-лаборатория

Научиться проверять гипотезы и качество данных запросами.

Перед модулем: 04.

05-1. SELECT, JOIN, NULL · 14–24 ч

Результат: portfolio/sql/01-select.sql + результаты

Изучить: Book chapters 1–3; SELECT logical order; NULL/3-valued logic; JOIN/aggregation/date filters.

Изучи главы 1–3 T-SQL Fundamentals: модель, SELECT, JOIN.
Создай учебную схему и данные: ≥5 клиентов, ≥3 мастеров, ≥12 записей, включая NULL и отмены.
Реши 10 запросов: фильтр, период, сортировка, LEFT JOIN, клиенты без записей, группировка.

Условия прохождения:

[ ] В каждом запросе записан ожидаемый результат на учебных данных.
[ ] LEFT JOIN сохраняет нужные строки без совпадений.
[ ] Объяснено различие NULL, пустой строки и отсутствующей строки.

Защита: Почему COUNT(*) после LEFT JOIN может дать неожиданный результат?

Дополнения: sql (см. materials/SUPPLEMENTS.md).

05-2. Подзапросы, CTE и окна · 16–28 ч

Результат: portfolio/sql/02-analysis.sql + результаты

Изучить: Book chapters 4–7: selected sections; EXISTS/subquery; CTE/views; UNION/INTERSECT/EXCEPT; Window functions; pivoting в S-1.

Изучи выбранные разделы глав 4–7: подзапросы, CTE/derived tables, set operators и оконные функции. APPLY, PIVOT и grouping sets оставь для S-1.
Реши 8 задач: повторные клиенты, загрузка мастеров, топ услуг, последняя запись клиента.
Сверь два разных способа решения одной задачи на пограничных данных.

Условия прохождения:

[ ] Нет случайного размножения строк в агрегатах.
[ ] Для равных значений сортировки определён нужный порядок или политика ties.
[ ] Есть ручная проверка результата минимум на 3 строках.

Защита: Как выбрать последнюю запись клиента, если время у двух записей совпало?

Дополнения: sql (см. materials/SUPPLEMENTS.md).

05-3. DML, ограничения и безопасное изменение · 8–14 ч

Результат: portfolio/sql/03-transactions.sql + протокол

Изучить: Book chapter 8; DML/DDL/DCL/TCL; Constraints; Basic transaction.

Изучи главу 8; выполни INSERT/UPDATE/DELETE на собственной учебной схеме с PK/FK/UNIQUE/CHECK.
Покажи простую транзакцию BEGIN/COMMIT/ROLLBACK; обработку ошибок и конкурентность разберёшь в модуле 10.
Отдельно сравни DDL/DML/DCL/TCL и учебный термин DQL; не выводи поведение команды из одной классификационной метки.

Условия прохождения:

[ ] Указаны СУБД, версия, схема и команды запуска.
[ ] Есть успешная операция и фактический отказ нарушения ограничения.
[ ] Приложены входные данные, запросы и ожидаемые/фактические результаты.

Защита: Почему SELECT можно встретить и в категории DQL, и в DML?

Map.txt: #014.

Дополнения: sql (см. materials/SUPPLEMENTS.md).

Модуль 10. Конкурентность, производительность и эволюция данных

Закрепить SQL на гонках, запросах и изменениях схемы.

Перед модулем: 05.

04-2. Транзакции и гонки · 9–16 ч

Результат: portfolio/11-concurrency.md

Изучить: ACID; Isolation/locks/deadlocks; Race condition; SQL Server row versioning; Error handling.

Изучи главу 10: ACID, locks, blocking, isolation, row versioning и deadlocks; для TRY/CATCH используй соответствующий раздел главы 11.
В двух сессиях воспроизведи гонку за один слот; покажи чередование шагов и исправление через ограничения и транзакционный протокол.
Проверь отмену, повторное бронирование и rollback после ошибки; изоляцию объясняй для своей СУБД, не как универсальную реализацию.

Условия прохождения:

[ ] Есть реальные результаты двух сессий до исправления и после него.
[ ] Ошибка не оставляет открытой транзакции или частичной записи.
[ ] Корректно повторное занятие слота после отмены; стратегия предотвращает двойную активную запись.

Защита: Как сохранить возможность заново занять слот после отмены прежней записи?

Map.txt: #012, #013.

Дополнения: sql, patterns (см. materials/SUPPLEMENTS.md).

10-1. Индекс и план запроса · 6–11 ч

Результат: portfolio/data/query-performance.md

Изучить: Index/selectivity; EXPLAIN/execution plan; Query patterns.

Выбери запрос расписания, оцени селективность и предложи индекс.
Сними execution plan и измерение до/после на синтетическом наборе осмысленного размера.
Разбери стоимость записи, covering/composite index, N+1 и пагинацию.

Условия прохождения:

[ ] Сохранены план, объём данных и условия измерения.
[ ] Не сделан вывод о производительности по времени единственного маленького запроса.
[ ] Объяснены компромиссы индекса и ответственность аналитика за требования, а не tuning всей БД.

Защита: Почему индекс на каждую колонку может ухудшить систему?

Дополнения: sql, patterns (см. materials/SUPPLEMENTS.md).

10-2. Изменение схемы без потери смысла · 6–11 ч

Результат: portfolio/data/schema-migration.md

Изучить: Schema evolution; Data migration; Temporal tables: обзор.

Добавь статус и новое обязательное поле в существующие данные по expand/contract-плану.
Опиши backfill, совместимость версий, контроль качества и rollback/roll-forward.
Для истории сравни audit/event log и system-versioned temporal tables из главы 9; temporal не подменяет бизнес-время.

Условия прохождения:

[ ] Есть порядок изменений и проверка старых записей.
[ ] Указано, какие изменения обратимы, а где нужен roll-forward.
[ ] История и текущая истина разделены.

Защита: Как добавить NOT NULL поле, когда старые клиенты его не присылают?

Дополнения: sql, patterns (см. materials/SUPPLEMENTS.md).

Модуль 06. Контракт API

Дать разработчику проверяемый договор взаимодействия систем.

Перед модулем: 10.

06-1. HTTP руками · 4–7 ч

Результат: portfolio/13-http-lab.md

Изучить: HTTP methods/status/headers; Idempotent vs safe; DNS/TLS transport errors.

Проследи DNS → TCP/TLS → HTTP на одном запросе в DevTools/curl.
Разбери метод, путь, заголовки, тело и код ответа.
Сравни GET, POST, PUT, PATCH, DELETE и смысл идемпотентности.

Условия прохождения:

[ ] Есть реальный обезличенный запрос и ответ.
[ ] Различены ошибки клиента, сервера и транспорта.
[ ] Повтор запроса разобран через бизнес-эффект.

Защита: Почему timeout не доказывает, что создание записи не произошло?

Map.txt: #030, #031.

Дополнения: http, oas, uml, json (см. materials/SUPPLEMENTS.md).

06-2. OpenAPI-контракт · 7–12 ч

Результат: portfolio/api/openapi.yaml

Изучить: OpenAPI; JSON Schema; Resource design; Pagination/errors/version.

Опиши 6 операций: услуги, слоты, создание, просмотр, перенос и отмена записи; перенос должен сохранять согласованные бизнес-инварианты.
Определи JSON-схемы, обязательность, время с часовым поясом, пагинацию и ошибки.
Добавь примеры успеха и конфликтов; выбери поддерживаемую валидатором версию OpenAPI.

Условия прохождения:

[ ] Контракт проходит выбранный валидатор; инструмент и версия указаны.
[ ] Описаны 400/401/403/404/409 там, где применимы.
[ ] Статусы, ID и правила совпадают с ERD и требованиями.

Защита: Как клиент поймёт, что слот уже забронировал другой человек?

Map.txt: #030, #031.

Дополнения: http, oas, uml, json (см. materials/SUPPLEMENTS.md).

06-3. Чекпоинт: mock и contract review · 4–7 ч

Результат: portfolio/api/requests.http + протокол

Изучить: Mock; Contract validation; Requests/responses; Limits of mock verification.

Подними mock из контракта выбранным инструментом.
Выполни минимум 8 запросов: основные операции, некорректные данные и занятый слот; mock-ограничения запиши отдельно.
Сравни ответы со схемами; отдельно укажи поведение, которое mock не проверяет.

Условия прохождения:

[ ] Сохранены команды воспроизведения и фактические ответы.
[ ] Ошибки имеют стабильные коды и понятную структуру.
[ ] Mock не выдан за работающую бизнес-логику или проверку гонок.

Защита: Можно ли по контракту реализовать клиент без устных пояснений?

Дополнения: http, oas, uml, json (см. materials/SUPPLEMENTS.md).

06-4. UML sequence по API-контракту · 5–9 ч

Результат: portfolio/api/sequence.md

Изучить: UML sequence; alt/opt/loop; Контракт и runtime-сценарий.

Построй sequence diagram создания записи с UI, backend, БД и провайдером уведомлений.
Покажи alt/opt/loop, timeout, конфликт и повтор; корректно различи sync/async-вызовы.
Сверь сообщения с OpenAPI и состояниями объекта, не рисуй неизвестные внутренние алгоритмы как факты.

Условия прохождения:

[ ] Есть связь каждого существенного сообщения с операцией или событием.
[ ] Описаны результаты при потере ответа.
[ ] Состояния и ошибки совпадают с требованиями и данными.

Защита: Что меняется в sequence, если ответ клиенту потерян после commit?

Map.txt: #040, #041.

Дополнения: http, oas, uml, json (см. materials/SUPPLEMENTS.md).

06-5. Эволюция API и внешние callbacks · 6–11 ч

Результат: portfolio/api/evolution.md

Изучить: API compatibility; Idempotency; Webhooks.

Спроектируй совместимое и несовместимое изменение API; зафиксируй versioning/deprecation.
Разбери idempotency key, TTL ключа, повтор с другим телом, pagination, filters и stable error codes.
Опиши webhook: подпись, повторы, дедупликацию и порядок доставки как требования; конкретный механизм подписи проверь по документации выбранного провайдера.

Условия прохождения:

[ ] Есть тест старого клиента на новом контракте.
[ ] Ключ идемпотентности связан с субъектом, операцией и результатом.
[ ] Публичный callback не считается доверенным только по URL.

Защита: Ключ тот же, но тело запроса другое: какой результат получит клиент?

Дополнения: http, oas, uml, json (см. materials/SUPPLEMENTS.md).

Модуль 08. Доступ и безопасность

Ограничить доступ и описать требования к защите данных.

Перед модулем: 06.

08-1. Кто что может · 7–12 ч

Результат: portfolio/17-access.md

Изучить: Authentication vs authorization; RBAC/resource ownership; OAuth 2.0/OIDC/SAML; Auth code + PKCE; Token validation.

Составь матрицу ролей: клиент, мастер, оператор, администратор.
Различи authentication/authorization, OAuth 2.0, OIDC, SAML и access/ID token.
Разбери попытку клиента открыть чужую запись и действия уволенного оператора.
Нарисуй Authorization Code + PKCE для выбранного клиента; перечисли проверки issuer/audience/expiry/signature и роль state/nonce по применимой спецификации, не реализуя свой протокол.

Условия прохождения:

[ ] Права проверяются по ресурсу, а не только по наличию роли.
[ ] ID token не подменяет access token для API.
[ ] Описаны истечение сессии и отзыв доступа.

Защита: Пользователь меняет bookingId в URL. Где должна остановиться атака?

Map.txt: #050, #053, #054, #055, #056, #057, #058, #059, #051, #052, #060, #061.

Дополнения: oidc, oauth, owasp (см. materials/SUPPLEMENTS.md).

08-2. Модель угроз и сеть · 5–9 ч

Результат: portfolio/18-security.md

Изучить: CIA/threat model; Trust boundary; Symmetric/asymmetric encryption; Hash/signature; TLS and data minimization.

Определи активы, границы доверия и 5 угроз с мерами.
Расширь HTTPS-схему из T-1 границами доверия, точками аутентификации/авторизации и доступом к БД; не рисуй сеть заново без новой цели.
Опиши аудит, минимизацию данных, сроки хранения и различие hashing/encryption.

Условия прохождения:

[ ] Секреты и персональные данные не попадают в примеры логов.
[ ] Каждая мера связана с конкретной угрозой.
[ ] Понятно, какие компоненты доступны извне и зачем.

Защита: Почему VPN или firewall сами по себе не запрещают читать чужую запись?

Map.txt: #062, #064, #065, #066, #067, #068.

Дополнения: oidc, oauth, owasp (см. materials/SUPPLEMENTS.md).

08-3. Чекпоинт: требования к защите · 3–6 ч

Результат: portfolio/19-security-review.md

Изучить: Security acceptance; BOLA/BFLA; Audit/access lifecycle; Threat → requirement → test.

Сопоставь угрозы, требования, меры и проверки.
Составь 6 негативных тестов доступа и аудита.
Отметь юридические и регуляторные вопросы как требующие отдельной проверки.

Условия прохождения:

[ ] Есть проверки горизонтального и вертикального повышения привилегий.
[ ] Прописана ожидаемая реакция на каждый отказ доступа.
[ ] Учебное решение не объявлено соответствующим нормативам без проверки.

Защита: Какие события понадобятся, чтобы расследовать массовую отмену записей?

Map.txt: #050, #053, #054, #055, #056, #057, #058, #059.

Дополнения: oidc, oauth, owasp (см. materials/SUPPLEMENTS.md).

Модуль 07. Архитектура и интеграции

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

Перед модулем: 08.

07-1. Архитектурное решение · 4–7 ч

Результат: portfolio/14-architecture.md

Изучить: Monolith/SOA/microservices; Serverless; Architecture decision; Service boundaries.

Уточни context/container-схему из T-3: границы владения данными и взаимодействия, внешние провайдеры.
Сравни модульный монолит, SOA и микросервисы для масштаба учебного проекта.
Поясни место IaaS/PaaS/SaaS и serverless, не смешивая эти категории.

Условия прохождения:

[ ] У каждого компонента есть ответственность.
[ ] Нет дополнительного сервиса без задачи, которую он решает.
[ ] Записан ADR с ограничениями и последствиями.

Защита: Что станет сложнее, если разнести маленький проект на 8 микросервисов?

Map.txt: #020, #021.

Дополнения: async (см. materials/SUPPLEMENTS.md).

07-2. Надёжные уведомления · 6–11 ч

Результат: portfolio/15-integration.md + схема сообщения

Изучить: Message/event; At-least-once; Retry/DLQ; Outbox and consumer dedup.

Опиши событие BookingCreated с eventId, bookingId, occurredAt и версией.
Разбери таймаут, повторную доставку, недоступный consumer, DLQ и порядок сообщений.
Опиши надёжную связь записи в БД и отправки события, например через outbox.

Условия прохождения:

[ ] Повторная доставка не создаёт повторного бизнес-эффекта без контроля.
[ ] Есть retry-политика и ответственный за разбор DLQ.
[ ] Событие не теряется молча между commit и отправкой.

Защита: Событие доставлено дважды, а подтверждение обработки потеряно. Что произойдёт?

Map.txt: #035.

Дополнения: async (см. materials/SUPPLEMENTS.md).

07-3. Чекпоинт: кэш и отказ · 3–6 ч

Результат: portfolio/16-failure-review.md

Изучить: Cache-aside/TTL/invalidation; Cold/warm cache; Write-through/write-back/write-around; Stale data/failures.

Определи, что можно кэшировать: каталог и/или доступность слотов.
Объясни cold/warm cache, TTL, invalidation и стратегии записи.
Прогони недоступность кэша, устаревший слот и отказ брокера.

Условия прохождения:

[ ] Кэш не является единственной защитой от двойной записи.
[ ] Для каждого отказа есть ожидаемый результат и сигнал мониторинга.
[ ] Определены источник истины и допустимая устарелость.

Защита: Кэш показывает свободный слот, но БД уже занята. Как ведёт себя система?

Map.txt: #016, #017, #018.

Дополнения: async (см. materials/SUPPLEMENTS.md).

07-4. Контракт события и AsyncAPI · 6–11 ч

Результат: portfolio/integration/asyncapi.yaml + review.md

Изучить: AsyncAPI; Queue/topic/pub-sub; Contract evolution.

Опиши каналы, сообщения, payload, correlation ID, operation и схему эволюции в поддерживаемой версии AsyncAPI.
Сравни queue/topic, broker/queue, pub-sub, routing и competing consumers на уведомлении и отчётности.
Проверь контракт валидатором и составь сценарии compatibility, poison message и replay.

Условия прохождения:

[ ] Контракт валиден в указанной версии инструмента.
[ ] Схема payload и стратегия изменений не ломают старого consumer без процедуры миграции.
[ ] Порядок, доставка и дедупликация не обещают exactly-once для всей бизнес-цепочки.

Защита: Почему подтверждение брокеру и бизнес-эффект нужно рассматривать вместе?

Map.txt: #035.

Дополнения: async (см. materials/SUPPLEMENTS.md).

Глава PR. SA в жизненном цикле продукта

Разработка, проверка, запуск и эксплуатация.

Чекпоинт: Досье воспроизводимо, изменение и отказ разобраны, выполнена первая защита.

Модуль 11. Передача в разработку и качество

Сделать спецификацию рабочим договором команды.

Перед модулем: 07.

11-1. Пакет задачи и декомпозиция · 5–9 ч

Результат: portfolio/delivery/handoff.md

Изучить: Backlog; Refinement; DoR/DoD; Technical writing.

Собери пакет задачи для разработчика: контекст, сценарий, API, данные, права, NFR и критерии.
Разбей изменение на вертикальные срезы backlog; отдели оценку аналитика от оценки реализации.
Определи Definition of Ready/Done как договорённости учебной команды, согласующих и журнал вопросов.

Условия прохождения:

[ ] Каждый срез даёт наблюдаемое поведение.
[ ] Не осталось скрытых обязательных решений только в переписке.
[ ] Разработчик может назвать входы, выходы и случаи ошибки по пакету.

Защита: Как декомпозировать отмену, чтобы не получить «БД готова», но неработающий сценарий?

Дополнения: iiba, ireb, scrum (см. materials/SUPPLEMENTS.md).

11-2. Стратегия проверки и UAT · 6–11 ч

Результат: portfolio/delivery/test-matrix.md

Изучить: Verification/validation; UAT; Traceability; Тест-дизайн.

Свяжи требования с unit/integration/contract/system/UAT-проверками на уровне ответственности.
Используй equivalence classes, boundary values и decision table для отмены и доступа.
Составь UAT-план: роли, данные, сценарии, ожидаемый результат, дефекты и критерии выхода.

Условия прохождения:

[ ] Тестирование требований отличается от проверки реализации и от решения о приёмке.
[ ] Есть негативные, граничные и нефункциональные сценарии.
[ ] Ожидаемое поведение известно до запуска теста.

Защита: Зелёные contract tests означают, что бизнес принял продукт?

Дополнения: iiba, ireb, scrum (см. materials/SUPPLEMENTS.md).

11-3. Ревью без устных костылей · 4–7 ч

Результат: portfolio/delivery/review-log.md

Изучить: Facilitation; Review; Conflict resolution.

Проведи walkthrough спецификации с позиций QA, backend и поддержки; при одиночной работе пометь симуляцию.
Заведи замечания с тяжестью, вопросом, решением и ответственным.
Исправь минимум 3 найденных дефекта и обнови связанные артефакты.

Условия прохождения:

[ ] Не выдуманы реальные участники ревью.
[ ] Исправления видны в diff и трассировке.
[ ] Открытые блокирующие вопросы не названы закрытыми.

Защита: Что делать, если QA и разработчик одинаково понимают неоднозначное требование, но по-разному с заказчиком?

Дополнения: iiba, ireb, scrum (см. materials/SUPPLEMENTS.md).

Модуль 12. Эксплуатация и изменение работающей системы

Увидеть результат после разработки и предусмотреть восстановление.

Перед модулем: 11.

12-1. Наблюдаемость и инцидент · 6–11 ч

Результат: portfolio/operations/observability.md

Изучить: Observability; Runbook; Incident analysis.

Определи logs/metrics/traces и correlation ID для сквозного бронирования.
Составь диагностический сценарий «клиенту timeout, запись создана» с фактами и гипотезами.
Опиши алерты, владельцев и runbook; не логируй содержимое токенов и личные данные.

Условия прохождения:

[ ] Каждый сигнал отвечает на конкретный вопрос.
[ ] Не смешаны бизнес-аудит и debug-log.
[ ] Есть путь эскалации и критерий восстановления.

Защита: Какие данные свяжут клиентский запрос, транзакцию и событие?

Дополнения: iiba, otel, slo (см. materials/SUPPLEMENTS.md).

12-2. SLO, восстановление и запуск · 6–11 ч

Результат: portfolio/operations/release-recovery.md

Изучить: SLI/SLO/SLA; RTO/RPO; Cutover/rollback.

Выбери SLI/SLO и отдели их от SLA; сформулируй окно измерения и исключения.
Опиши RTO/RPO, backup/restore, критерии приёмки восстановления и degradation.
Составь release/cutover checklist, rollback-условия, feature flag и обучение пользователей.

Условия прохождения:

[ ] SLO измерим через определённый сигнал, а не только обещание.
[ ] Backup не считается проверенным без restore-проверки.
[ ] Есть ответственность и проверка целостности после запуска/отката.

Защита: Что означает «потерять не больше 15 минут данных» и как это проверить?

Дополнения: iiba, otel, slo (см. materials/SUPPLEMENTS.md).

12-3. Оценка эффекта после запуска · 5–9 ч

Результат: portfolio/operations/outcome-review.md

Изучить: Solution evaluation; Product metrics; Feedback loop.

Свяжи исходную цель с adoption, completion rate, no-show и операционными метриками.
Составь план сбора baseline и сравнения после изменения; отдели корреляцию от доказанного эффекта.
Разбери жалобу пользователей и создай обоснованную заявку на изменение.

Условия прохождения:

[ ] У метрики есть формула, период и источник данных.
[ ] План учитывает качество данных и внешние факторы.
[ ] Новая функция обоснована эффектом или проверяемой гипотезой.

Защита: Записей стало больше, но доход не вырос: какие объяснения проверишь?

Дополнения: iiba, otel, slo (см. materials/SUPPLEMENTS.md).

Модуль 09. Чекпоинт системного аналитика

Собрать связное решение и защитить его под изменением.

Перед модулем: 12.

09-1. Сборка досье · 4–7 ч

Результат: portfolio/README.md

Изучить: Portfolio navigation; Cross-artifact consistency; Reproducible verification.

Собери навигацию: бриф, требования, модели, ERD, SQL, API/события, ADR, доступ, тесты, передача и эксплуатация.
Проверь названия, статусы, поля и бизнес-правила на согласованность.
Составь список ограничений и неразрешённых вопросов.

Условия прохождения:

[ ] Все ссылки и исходники доступны.
[ ] Заявленные SQL/API-проверки воспроизводимы.
[ ] Учебные допущения отделены от подтверждённых фактов.

Защита: Выбери одно требование и проследи его до API, данных и теста.

09-2. Босс: заявка на изменение · 5–9 ч

Результат: portfolio/20-change-request.md

Изучить: Capacity invariants; Change impact; Regression/compatibility.

Добавь групповую запись с лимитом вместимости.
Оцени влияние на требования, BPMN, ERD, SQL, API и гонки.
Обнови нужные артефакты и составь регрессионные проверки.

Условия прохождения:

[ ] Изменение затрагивает не только один endpoint.
[ ] Учтено одновременное занятие последних мест.
[ ] Есть аргументированный порядок внедрения и обратной совместимости.

Защита: Какие части старого контракта можно сохранить и какой ценой?

09-3. Защита первого проекта · 3–6 ч

Результат: portfolio/21-defense.md

Изучить: Solution defense; Trade-offs; Evidence and limitations.

Проведи 15-минутную защиту решения без чтения определений.
Ответь на 5 случайных challenge-вопросов предыдущих квестов.
Запиши замечания, исправления и выбери продолжение: BSA, архитектура или самостоятельный кейс. Это первая защита, а не завершение профессии.

Условия прохождения:

[ ] Можешь объяснить компромиссы и отвергнутые варианты.
[ ] Нет критических противоречий между артефактами.
[ ] Указан результат ревью: self-review, AI-review или реальный внешний reviewer.

Защита: Владелец просит запустить завтра: что сократишь, сохранив целостность и доступ?

Глава BSA. Бизнес-системный анализ

Ценность и изменения между системами.

Чекпоинт: Есть business case, landscape, ownership, transition plan и аналитическая витрина.

Модуль 13. Бизнес-анализ: стратегия и ценность

Уметь обосновывать изменение до выбора IT-решения.

Перед модулем: 09.

13-1. Варианты решения и business case · 7–12 ч

Результат: portfolio/bsa/business-case.md

Изучить: Strategy analysis; Build/buy; Business case; TCO/ROI.

Для сети филиалов сравни: ничего не менять, изменить процесс, купить продукт, разработать своё.
Составь value proposition, затраты/выгоды, риски, допущения и простую модель TCO/ROI/payback.
Проведи sensitivity analysis для двух неопределённых параметров; отдели сценарный расчёт от финансового прогноза.

Условия прохождения:

[ ] Сравнение включает не-IT альтернативу.
[ ] Все числа явно учебные или имеют проверяемый источник.
[ ] Результат меняется при проверяемых допущениях, показаны границы точности.

Защита: Когда лучший выбор — не разрабатывать систему?

Дополнения: iiba (см. materials/SUPPLEMENTS.md).

13-2. Исследование и фасилитация · 6–11 ч

Результат: portfolio/bsa/research-plan.md

Изучить: Elicitation; Facilitation; Hypothesis testing.

Составь план elicitation: интервью, наблюдение, workshop, анализ документов; объясни выбор.
Подготовь agenda и технику разрешения конфликта владельца филиала и центрального офиса.
Различи problem statement, hypothesis, факт и решение; спроектируй проверку самой рискованной гипотезы.

Условия прохождения:

[ ] У каждого метода есть вопрос, выборка и ограничения.
[ ] Есть процедура подтверждения результатов участниками.
[ ] Мнения не выданы за статистическую репрезентативность.

Защита: Все участники workshop согласились: этого достаточно для достоверного вывода?

Map.txt: #005, #006.

Дополнения: iiba (см. materials/SUPPLEMENTS.md).

13-3. Приоритеты и проверка ценности · 6–11 ч

Результат: portfolio/bsa/value-roadmap.md

Изучить: Prioritization; Outcome roadmap; BA planning/monitoring.

Разложи цели на outcomes, инициативы и измерения; сравни MoSCoW и weighted scoring.
Составь roadmap по результатам, зависимостям и рискам, а не только списку функций.
Опиши plan мониторинга BA-работы и оценки пользы после запуска.

Условия прохождения:

[ ] У каждой инициативы есть связь с целью и проверка эффекта.
[ ] Вес критерия и допущения в scoring видны.
[ ] Изменение приоритета можно объяснить новыми данными.

Защита: Как защитить отказ от любимой функции руководителя без спора «мне кажется»?

Дополнения: iiba (см. materials/SUPPLEMENTS.md).

Модуль 14. Бизнес-системный анализ предприятия

Связать бизнес-процессы, приложения, данные и организационное изменение.

Перед модулем: 13.

14-1. System landscape и ownership · 7–12 ч

Результат: portfolio/bsa/landscape.md

Изучить: BSA; Application landscape; Master data; End-to-end analysis.

Продолжи кейс до сети филиалов с CRM, ERP, ECM, identity provider, billing и BI.
Создай каталог систем, интерфейсов, master/reference data, владельцев и SLA взаимодействий.
Опиши end-to-end процесс и точки разрыва ответственности между командами.

Условия прохождения:

[ ] У сущностей определены system of record и владелец качества.
[ ] Landscape отличается от внутреннего container-view одного приложения.
[ ] Дублирование функций и данных отмечено как риск, а не автоматически как ошибка.

Защита: Какая система владеет «клиентом», если CRM и ERP используют разные ID?

Map.txt: #051, #052, #060, #061.

Дополнения: iiba, ecm (см. materials/SUPPLEMENTS.md).

A-2. Жизненный цикл документа · 3–6 ч

Результат: portfolio/branches/ecm.md

Изучить: CLM vs ECM; Document lifecycle; Version/metadata; Retention/access/audit.

Опиши создание, согласование, версионирование, хранение и удаление документа.
Определи права и метаданные.
Разбери конфликт версий и журнал аудита.

Условия прохождения:

[ ] Есть владелец документа и срок хранения как согласуемое правило.
[ ] Версии различимы.
[ ] Удаление согласовано с требованиями к аудиту.

Защита: Что делать, если мастер и оператор правят один документ?

Map.txt: #019.

Дополнения: iiba, ecm (см. materials/SUPPLEMENTS.md).

14-2. Gap analysis и переходное состояние · 8–14 ч

Результат: portfolio/bsa/transition.md

Изучить: Gap analysis; Transition requirements; Migration/cutover; Change management.

Сравни AS-IS и TO-BE по процессам, данным, интеграциям и ролям.
Определи transition requirements: очистка/миграция данных, обучение, параллельная работа, cutover.
Разбери reconcile двух источников и согласование владельцами филиалов.

Условия прохождения:

[ ] У каждого gap есть изменение, риск и критерий закрытия.
[ ] Есть migration mapping, правила качества и сверка итогов.
[ ] Transition requirement не перепутан с постоянной функцией.

Защита: Как проверить, что перенос 100 тысяч клиентов не потерял и не задвоил сущности?

Дополнения: iiba, ecm (см. materials/SUPPLEMENTS.md).

Модуль B. Другие способы интеграции

Узнать контрактные отличия SOAP, GraphQL и RPC.

Перед модулем: 14.

B-1. SOAP и XML · 8–14 ч

Результат: portfolio/branches/soap.md

Изучить: XML/XSD; SOAP envelope/fault; WSDL contract; Legacy integration.

На базе XML/XSD из T-2 опиши SOAP Envelope, Header, Body и Fault для legacy-партнёра.
Покажи роль XSD, namespaces, WSDL и SOAP Fault.
Сравни интеграцию с HTTP API проекта.

Условия прохождения:

[ ] XML синтаксически корректен и проверен парсером.
[ ] Отличены XML, SOAP, WSDL и XSD.
[ ] Есть пример ошибки контракта.

Защита: Что изменится при добавлении обязательного XML-поля?

Map.txt: #023, #024, #025, #026, #027, #028, #029.

Дополнения: xsd (см. materials/SUPPLEMENTS.md).

B-2. GraphQL и RPC · 7–12 ч

Результат: portfolio/branches/graphql-rpc.md

Изучить: GraphQL schema/query/mutation; RPC/gRPC/IDL/protobuf; Deadline/errors; API style comparison.

Опиши GraphQL schema и запрос клиента с записями.
Опиши эквивалентный RPC/gRPC-вызов, роль IDL/protobuf, deadline и отличие transport от стиля API.
Сравни выбор по связности, потребителям и эволюции контракта.

Условия прохождения:

[ ] Есть аргументированный выбор для двух разных ситуаций.
[ ] Рассмотрены авторизация полей и стоимость запроса.
[ ] GraphQL не назван прямым доступом клиента к БД.

Защита: Когда один HTTP endpoint не означает один вид операции?

Map.txt: #032, #033, #034.

Дополнения: xsd (см. materials/SUPPLEMENTS.md).

Модуль C. Аналитические данные

Спроектировать движение данных в отчётность.

Перед модулем: 14, 05.

C-1. От события к витрине · 8–14 ч

Результат: portfolio/branches/etl.md

Изучить: ETL/ELT; Warehouse/lake/mart; Dimensional model/grain; OLTP vs OLAP.

Различи warehouse, lake и mart; добавь многомерную модель.
Опиши ETL/ELT-пайплайн отчёта по загрузке мастеров.
Выбери зерно факта и измерения; перечисли проверки качества.

Условия прохождения:

[ ] Зерно таблицы фактов сформулировано одной фразой.
[ ] Отчёт сверяется с операционными данными.
[ ] Нет двойного счёта при повторной загрузке.

Защита: Как поздняя отмена изменит вчерашнюю отчётность?

Map.txt: #008, #042, #043, #044, #045, #046, #047, #048, #049.

C-2. Перезапуск загрузки · 8–14 ч

Результат: portfolio/branches/data-quality.md

Изучить: Incremental load/watermark; Replay/backfill; Data quality/lineage; Tool selection.

Опиши инкрементальную загрузку и watermark.
Разбери дубли, пропуски, поздние данные и изменение схемы.
Сравни ETL/ELT-инструменты по connectors, объёму, latency, эксплуатации и стоимости. Ссылка «2025» сейчас ведёт на обновляемую подборку; условия перепроверь при выборе.
Выполни маленькую загрузку через SQL, Python или ETL-инструмент на 10+ учебных записях, включая дубли, пустые значения и позднюю отмену; запусти повторно и сравни итоги.

Условия прохождения:

[ ] Есть стратегия replay/backfill.
[ ] Есть наблюдаемость задержек и ошибок.
[ ] Выбор инструмента обоснован объёмом и эксплуатацией.
[ ] Есть исходные данные, код/конфигурация, две фактические загрузки и сверка показателей без задвоения.

Защита: Как исправить три дня неверной выгрузки без дубликатов?

Map.txt: #042, #043, #044, #045, #046, #047, #048, #049.

Глава AR. Архитектура

Solution → data/security → enterprise.

Чекпоинт: Есть quality scenarios, C4/arc42, ADR, capacity, resilience и enterprise roadmap.

Модуль 15. Архитектура решения: границы и компромиссы

Перейти от одной спецификации к обоснованному устройству системы.

Перед модулем: 09.

15-1. Качества, ограничения и варианты · 7–12 ч

Результат: portfolio/architecture/drivers.md

Изучить: Quality scenarios; Trade-off analysis; Architecture drivers.

Выдели architecturally significant requirements, constraints и quality attribute scenarios.
Сравни минимум 3 варианта решения по latency, availability, security, changeability, cost.
Объясни выбор критериев и чувствительность результата к весам/нагрузке.

Условия прохождения:

[ ] Каждое качество имеет стимул, среду, реакцию и меру.
[ ] Есть архитектурные риски и отвергнутые варианты.
[ ] Высокая сложность не считается преимуществом сама по себе.

Защита: Что ты пожертвуешь ради более низкой задержки и почему?

Map.txt: #020, #021.

Дополнения: c4, patterns, ddd (см. materials/SUPPLEMENTS.md).

15-2. Домен и границы компонентов · 8–14 ч

Результат: portfolio/architecture/domain-boundaries.md

Изучить: DDD; Bounded contexts; C4; Modular design.

Построй bounded contexts, язык и context map для записи, услуг, клиентов и расчётов.
Сравни modular monolith и отдельные сервисы; выдели владение данными и контрактные границы.
Нарисуй C4 context/container и нужный component view; event storming используй как технику исследования.

Условия прохождения:

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

Защита: Должны ли «клиент» в маркетинге и «клиент» в расчётах иметь одну модель?

Дополнения: c4, patterns, ddd (см. materials/SUPPLEMENTS.md).

15-3. Оценка нагрузки и deployment · 8–14 ч

Результат: portfolio/architecture/capacity.md

Изучить: Capacity planning; Horizontal/vertical scaling; Deployment; Cost model.

Оцени peak RPS, concurrent requests, объём хранения, трафик и рост по явным допущениям.
Построй deployment-view: балансировщик, stateless/stateful части, сеть, хранилища и отказ одного узла.
Сравни VM/container/serverless и модель затрат без вымышленных текущих тарифов.

Условия прохождения:

[ ] Показаны формулы, единицы и источники чисел.
[ ] Репликация/масштабирование не объявлены бесплатными.
[ ] Условия наблюдаемости и проверки capacity включены в план.

Защита: Почему 100 тысяч пользователей не равны 100 тысячам запросов в секунду?

Map.txt: #022.

Дополнения: c4, patterns, ddd (см. materials/SUPPLEMENTS.md).

Модуль 16. Распределённые системы и надёжность

Обосновать поведение при частичных отказах и несогласованности.

Перед модулем: 15.

16-1. Согласованность и репликация · 8–14 ч

Результат: portfolio/architecture/consistency.md

Изучить: Consistency; Replication; CAP; Sharding.

Разбери stale reads, read-your-writes, replication lag и network partition на расписании и отчёте.
Объясни CAP в условиях partition; сравни выбранные consistency guarantees по операциям.
Опиши replica, partition/sharding и failover, не подменяя ими backup.

Условия прохождения:

[ ] Гарантии сформулированы для конкретных операций.
[ ] Нет правила «CAP — выбери любые два всегда».
[ ] Показано влияние stale read на пользователя и бизнес-инвариант.

Защита: Можно ли разрешить устаревшее расписание и всё равно исключить двойную запись?

Дополнения: owasp, slo, patterns (см. materials/SUPPLEMENTS.md).

16-2. Saga, outbox и обработка сбоев · 9–16 ч

Результат: portfolio/architecture/distributed-workflow.md

Изучить: Saga; Outbox/inbox; Resilience patterns.

Добавь предоплату как учебное расширение; опиши запись, оплату и уведомление в разных системах.
Сравни saga orchestration/choreography, compensation, outbox/inbox и deduplication.
Задай timeouts, retry/backoff/jitter, circuit breaker, bulkhead и ручное восстановление.

Условия прохождения:

[ ] Компенсация не названа универсальным rollback реального мира.
[ ] Повторы и частичные успехи покрыты сценариями.
[ ] Есть владелец зависших процессов и аудит.

Защита: Что делать, если деньги списаны, а подтверждение бронирования не дошло?

Дополнения: owasp, slo, patterns (см. materials/SUPPLEMENTS.md).

16-3. Security и data architecture review · 7–12 ч

Результат: portfolio/architecture/security-data-review.md

Изучить: Zero trust: принципы; Multi-tenancy; Data/security architecture.

Пересмотри trust boundaries, identity federation, tenant isolation и принцип least privilege.
Укажи encryption in transit/at rest, key management и границы ответственности по угрозам.
Оцени cache consistency, OLTP/OLAP-разделение и риски пересылки персональных данных.

Условия прохождения:

[ ] Для каждой меры есть угроза, owner и проверка.
[ ] Ключи и секреты не появляются в артефактах.
[ ] Архитектурная схема не заменяет security assessment или юридическую проверку.

Защита: Почему одна role=admin недостаточна для изоляции нескольких компаний?

Дополнения: owasp, slo, patterns (см. materials/SUPPLEMENTS.md).

Модуль 17. Архитектурная документация и эволюция

Представить и защитить решение перед разными аудиториями.

Перед модулем: 16.

17-1. Архитектурное досье · 8–14 ч

Результат: portfolio/architecture/arc42.md

Изучить: arc42; ADR; Views/viewpoints.

Подготовь документ по arc42: goals, constraints, context, strategy, building blocks, runtime, deployment, crosscutting concepts, decisions, quality, risks и glossary.
Сделай ADR для 3 значимых решений с альтернативами и последствиями.
Выбери нужные уровни C4; не рисуй все уровни без адресата.

Условия прохождения:

[ ] Документ отвечает на вопросы разработки, эксплуатации и владельца продукта.
[ ] Диаграммы согласованы с контрактами и данными.
[ ] Риски и технический долг перечислены с последствиями.

Защита: Как отличить зафиксированное решение от временной гипотезы?

Дополнения: c4, arc42, patterns (см. materials/SUPPLEMENTS.md).

17-2. Эволюция и стоимость изменений · 7–12 ч

Результат: portfolio/architecture/evolution-roadmap.md

Изучить: Architecture evolution; Strangler; TCO/tech debt.

Спланируй переход от монолита к выбранному целевому состоянию по business need.
Сравни strangler, anti-corruption layer и параллельную работу при миграции legacy.
Оцени переходные состояния, стоимость поддержки, migration risks и критерии остановки.

Условия прохождения:

[ ] Каждый этап даёт полезный результат и имеет rollback/roll-forward.
[ ] Старые интеграции и данные не исчезают из плана.
[ ] Есть критерии, по которым миграцию можно не начинать.

Защита: Какой риск создаёт полная замена legacy одним релизом?

Дополнения: c4, arc42, patterns (см. materials/SUPPLEMENTS.md).

17-3. Архитектурный совет · 5–9 ч

Результат: portfolio/architecture/review-defense.md

Изучить: Architecture review; Risk analysis; Communication.

Проведи 20-минутную защиту и разбор одного отказа, одного изменения и одного превышения нагрузки.
Запиши замечания по качествам, безопасности, данным, эксплуатации и цене.
Пересмотри один ADR после нового ограничения и покажи diff.

Условия прохождения:

[ ] Компромиссы объяснены через требования.
[ ] Неизвестное признано с планом проверки.
[ ] Ревью явно обозначено как self/AI/реальное внешнее.

Защита: Уменьши бюджет вдвое: какое качество или scope поменяешь и с кем согласуешь?

Дополнения: c4, arc42, patterns (см. materials/SUPPLEMENTS.md).

Модуль A. Корпоративная архитектура

Понять TOGAF и управление документами в контексте организации.

Перед модулем: 17.

A-1. TOGAF без зубрёжки · 5–9 ч

Результат: portfolio/branches/togaf.md

Изучить: TOGAF ADM: обзор; Business/data/application/technology views; Governance.

Разбери ADM на обзорном уровне.
Сопоставь business/data/application/technology views с кейсом.
Покажи, чего не хватает, чтобы считать это архитектурой предприятия.

Условия прохождения:

[ ] Есть связь целей и архитектурных решений.
[ ] Упомянуты заинтересованные стороны и governance.
[ ] Учебная схема не выдана за полное применение TOGAF.

Защита: Как изменится решение для сети из 100 филиалов?

Map.txt: #002, #003, #004.

A-3. Enterprise roadmap и governance · 7–12 ч

Результат: portfolio/architecture/enterprise-roadmap.md

Изучить: TOGAF ADM; Business capabilities; Enterprise governance.

Соотнеси business/data/application/technology architecture с сетью филиалов.
Построй capability map, baseline/target и переходные состояния с зависимостями.
Объясни ADM, architecture governance, standards, exceptions и управление требованиями в масштабе предприятия.

Условия прохождения:

[ ] Capability не подменена приложением или оргподразделением.
[ ] Есть владелец переходов и процедура исключений.
[ ] Это учебная EA-модель, не обещание сертификации или полного внедрения TOGAF.

Защита: Почему архитектура одного приложения ещё не enterprise architecture?

Map.txt: #002, #003, #004.

Глава CP. Самостоятельная практика

Новый домен, портфолио, следующий уровень.

Чекпоинт: Решён незнакомый кейс; уровень подтверждён работами, а не только самооценкой.

Модуль 18. Самостоятельный проект и профессиональная проверка

Проверить перенос навыка в новый домен и подготовить доказательства для работы.

Перед модулем: 09.

18-1. Незнакомый домен: складской резерв · 12–21 ч

Результат: portfolio/independent/README.md

Изучить: Transfer learning; Новый домен; Самостоятельное решение.

Возьми новый кейс: сеть пунктов проката резервирует физические экземпляры оборудования на интервалы времени.
Самостоятельно собери discovery, требования, процесс, модель данных, API, интеграцию и проверки без копирования сущностей Slot.
Для BSA добавь cross-system transition plan; для архитектуры — quality/capacity/trade-off review.

Условия прохождения:

[ ] Есть новые инварианты: пересечение интервалов, ремонт, возврат с опозданием.
[ ] Использована трассировка и показаны ограничения.
[ ] Scope реалистично ограничен; полноценный код продукта не обязателен.

Защита: Почему модель фиксированного слота нельзя механически перенести на прокат оборудования?

18-2. Портфолио и интервью · 6–11 ч

Результат: portfolio/independent/portfolio-review.md

Изучить: Portfolio; Interview; Skills evidence.

Подготовь краткий кейс: проблема, твоя роль, решения, доказательства и ограничения.
Реши 3 новых live-задачи по SQL, требованиям и API без готового шаблона.
Сопоставь требования 5 актуальных вакансий выбранного рынка со своими доказательствами; не делай вывод о рынке по одной вакансии.

Условия прохождения:

[ ] Учебный кейс не выдан за коммерческий опыт.
[ ] Видны реальные исходники и протоколы проверки.
[ ] Пробелы помечены честно; нет обещания должности по числу чекбоксов.

Защита: Объясни за 2 минуты одно неудачное решение и его исправление.

18-3. Следующий цикл развития · 3–6 ч

Результат: portfolio/independent/development-plan.md

Изучить: Deliberate practice; Domain knowledge; Feedback.

Оцени навыки по rubric 0–3 из SKILL_MATRIX.md и выдели 3 слабых места.
Выбери доменную специализацию: финтех, e-commerce, B2B/SaaS, государственные системы или данные.
Спланируй следующий небольшой кейс или задачу с внешней обратной связью.

Условия прохождения:

[ ] Следующие шаги привязаны к конкретным пробелам.
[ ] План содержит практику, проверку и пересмотр по фактам.
[ ] Даты и нагрузка согласуются с доступным временем, не придумываются.

Защита: Как поймёшь, что учёба улучшила качество твоих решений, а не только словарь?

Глава SP. Специализации

Сети, корпоративная ИБ, продвинутый SQL.

Чекпоинт: Выбираются под домен и задачи; не обязательны для первой практики SA.

Модуль D. Сети глубже

Перевести сетевые термины в диагностику доступности.

Перед модулем: T.

D-1. Сетевая карта · 5–9 ч

Результат: portfolio/branches/network.md

Изучить: Subnet/VLAN/private VLAN/DMZ; Switch/bridge/router; LAN/WAN/cloud/SD-WAN; Topology/casting/transmission modes.

Разложи путь запроса по OSI/TCP-IP; различи MAC/IP, bridge/switch/router.
Разбери public/private IP, subnet, NAT, VLAN/private VLAN и DMZ.
Сопоставь LAN/WAN, wired/wireless, cloud networking, SD-WAN, топологии и режимы передачи.

Условия прохождения:

[ ] Схема показывает адресацию, маршрутизацию и границы сегментов.
[ ] Не смешаны уровни канала, сети и транспорта.
[ ] Пояснено, что VLAN не заменяет прикладную авторизацию.

Защита: Почему доступность IP ещё не означает доступность приложения?

Map.txt: #095, #096, #097, #098, #099, #100, #101, #103, #106, #111, #112, #114, #115, #120, #121, #125, #126, #127, #128, #129, #130, #131, #132.

D-2. Разбор инцидента · 4–7 ч

Результат: portfolio/branches/network-incident.md

Изучить: Network troubleshooting; OSI/TCP-IP; LLC/PDU: обзор; Session/presentation/application; Network history: optional.

Опиши диагностику DNS failure, TCP timeout, TLS failure и HTTP 502.
Обзорно объясни LLC/PDU, session/presentation/application layers и application protocols; отличи OSI-модель от реального стека. Историю сетей изучи по желанию.
Составь порядок сбора фактов и эскалации; история сетей — обзор по желанию.

Условия прохождения:

[ ] У каждого симптома есть проверка и следующий шаг.
[ ] Сетевые ошибки отделены от ошибок приложения.
[ ] Команды и реальные наблюдения обезличены.

Защита: Клиент видит timeout, а сервер утверждает, что обработал запрос. Какие данные нужны?

Map.txt: #092, #093, #094, #102, #105, #107, #108, #109, #110, #113, #116, #117, #118, #119, #122, #123, #124, #095, #096, #097, #098, #099, #100, #101, #103, #104, #111, #112, #114, #120, #121, #125, #126, #127, #128, #129, #130, #131, #132.

Модуль E. Корпоративная ИБ

Различать средства защиты и регуляторный контекст.

Перед модулем: 08.

E-1. Карта средств защиты · 5–9 ч

Результат: portfolio/branches/enterprise-security.md

Изучить: DLP/EDR/firewall/IDS/IPS; SIEM/SOC/ISMS; Threat intelligence; Cryptography history: optional.

Сопоставь DLP, EDR, firewall, IDS/IPS, SIEM, SOC, ISMS и threat intelligence.
Для каждого укажи задачу, входные сигналы и ограничение.
Свяжи средства с 5 угрозами проекта; криптографию и историю изучай обзорно.

Условия прохождения:

[ ] Система управления ИБ отделена от технического продукта.
[ ] Детектирование отделено от предотвращения.
[ ] Средства не обещают универсальной защиты.

Защита: Что увидят SIEM, EDR и приложение при одной и той же атаке?

Map.txt: #063, #069, #070, #071, #072, #073, #074, #075, #076, #077, #078, #079, #080, #081, #082, #083, #084, #085, #090, #091.

E-2. Платежи: отдельный контекст · 4–7 ч

Результат: portfolio/branches/payments.md

Изучить: SCA/3DS2/PSD2: domain context; Provider/region applicability; Requirements questions.

Обзорно разбери SCA, 3-D Secure и PSD2 по ссылкам исходника.
Отдели требования провайдера, региона и своего продукта.
Составь список вопросов к специалисту перед добавлением оплаты.

Условия прохождения:

[ ] Нет заявления, что PSD2 автоматически применяется к этому учебному проекту.
[ ] Не сохраняются реальные платёжные реквизиты.
[ ] Применимость норм отмечена как требующая актуальной проверки.

Защита: Почему нельзя переносить регуляторные требования другого рынка без проверки?

Map.txt: #086, #087, #088, #089.

Модуль S. SQL глубже по книге

Углубить SQL там, где этого требует работа с данными.

Перед модулем: 10.

S-1. Продвинутые выборки и temporal · 10–17 ч

Результат: portfolio/branches/sql-advanced.sql

Изучить: Book chapters 5–7,9; Advanced SQL.

Вернись к главам 5–7: APPLY, views/TVF, PIVOT/UNPIVOT, GROUPING SETS/ROLLUP/CUBE.
Сделай 4 задачи отчётности и сравни с простыми SELECT/GROUP BY.
По главе 9 проверь system-versioned temporal tables и отличи system time от business validity.

Условия прохождения:

[ ] Есть исполняемые примеры и проверка результата.
[ ] Различены переносимый SQL и T-SQL-специфичные конструкции.
[ ] Денормализованный отчёт не подменяет transactional model.

Защита: Можно ли восстановить бизнес-событие только по system time?

Дополнения: sql (см. materials/SUPPLEMENTS.md).

S-2. Программируемые объекты и ошибки · 10–17 ч

Результат: portfolio/branches/sql-programming.sql

Изучить: Book chapter 11; Programmable objects; Error handling.

По главе 11 разбери batches/GO, variables, temp tables, procedures, functions и triggers.
Покажи TRY/CATCH и безопасную параметризацию dynamic SQL; сравни set-based и cursor подходы.
Опиши обязанности аналитика при чтении существующей DB-логики и риски скрытого поведения triggers.

Условия прохождения:

[ ] Ошибка корректно завершает транзакцию.
[ ] Пользовательский ввод не склеивается в SQL-код.
[ ] Пример и анализ не требуют освоения роли DBA для окончания базового маршрута.

Защита: Почему повтор SELECT не всегда объяснит изменение, сделанное триггером?

Дополнения: sql (см. materials/SUPPLEMENTS.md).

Соответствие материалам и пределы обзора

Подробная проверка v1 и решений v2: AUDIT.md. Каждая из 132 ссылок сопоставлена конкретным квестам в materials/COVERAGE.md; это план учебной обработки, а не заявление, что тема уже усвоена. Разобраны все заголовки/URL Map.txt. При повторном извлечении текст получен для 118 страниц; просмотрены фрагменты и отдельно проверены проблемные места. Остальные 14 не объявлены прочитанными. Полная редакционная проверка каждой статьи не проводилась.

Книга проверена по всему оглавлению, введению и выбранным разделам. План всех 11 глав и приложения: materials/BOOK_PLAN.md. Она не прочитана постранично целиком. HTTP-доступность, содержательный обзор и прохождение обучения — три разных статуса.

SA Quest · учебная программа v2 · 08.11.2026