AfRel/draft_urfy.md

УрФУ. Календарно-тематический план

Часть 1 Методология и контекст

1.1 Лекция "Архитектура как синтез в условиях противоречий"

Теория: Почему «идеальной» архитектуры не существует. Виды противоречий в конкретных условиях бизнеса:

• бюджет деньги/время:
  • исследование рынка
  • постановку целей
  • формирование задач,
  • организация процессов,
  • формирование бизнес-архитектуры,
  • формирование системной архитектуры,
  • формирование архитектуры безопасности,
  • архитектуры мониторинга и реагирования,
  • подбор кадров,
  • оборудование,
  • разработку,
  • тестирование,
  • непрерывное развёртывание и доставку,
  • сопровождение,
  • выведение из эксплуатации.

Введение в ваш авторский фреймворк.

1.2 Лекция "Методика построения архитектуры в условиях правовых, экономических, ресурсных ограничений"

Теория: Как выявить материальные и измеримые ограничения проекта. Выявление системных требований (NFR) в условиях дефицита ресурсов. Матрица ролей и ответственностей. Реестры объектов ответственности, процессы производства. Дорожная карта, перспективный план, план-график работ, планирование расходов.

На дом: Студенты получают описание бизнес-кейса (например: "Стартап вашей мечты с бюджетом в 0 рублей на инфраструктуру, но он должен обеспечить вас зарплатой").

Часть 2. Индивидуальное проектирование руками

2.1 (Лекция 3): Проектирования при дефиците ресурсов

Теория: Архитектурный фреймворк AfRel, позволяющие экономить на каждом этапе (бизнес-процесс, архитектура, софт, интеграция, железо). Этапы каждого уровня (измеримая задача, риски, действия, планирование работ и исполнение, приёмка). Выбор модели по результатам ТЭП (Serverless|Microservices|ModuleMonolith), использование готовых Open-Source SaaS/PaaS). Шаблоны диалектических решений.

2.2 (Практика 1): Моделирование AS-IS / TO-BE.Практика: Индивидуальная работа

Студенты анализируют свой кейс по архитектурному фреймворку AfRel, фиксируют ограничения и строят верхнюю часть многоуровневой архитектуру предприятия (в markdown, Miro, Draw.io, PlantUML, UMLet, VS Code).

2.3 Пара 5 (Лекция 4): Оценка стоимости и рисков архитектуры

Теория: Как посчитать стоимость владения системой (TCO). Как оценить риски "бизнес-процессного", "архитектурного", "программного", "интеграционного", "инфраструктурного" долга и долга низкой квалификации (потери) исполнителей, который мы сознательно закладываем ради экономии времени или денег.

Меры по приоритизации рисков, снижению рисков, меры по устранению реализованных рисков, противоаварийные планы и тренировки.

2.4 Пара 6 (Практика 2): Детализация архитектуры и расчет TCO

Практика: Студенты детализируют компоненты системы, формируют модули, разбивают по единицам развёртывания, описывают интеграции, планируют инфраструктуру и защищают расчеты: почему выбран именно этот стек под заданные ограничения, почему именно на этом этапе.

Часть 3. Валидация и защита

3.1 Пара 7 (Лекция 5): Защита архитектурных решений (Architecture Review)

Теория: Как продавать архитектуру бизнесу и команде разработки. Типичные ошибки при презентации технических компромиссов. Подготовка к защите.

• обобщение модели системы на уровне бюджет/время -> выход на окупаемость, ROI.
• подготовка презентации и сопроводительная записка по концепту проекта
• подготовка к прениям и дискуссиям.

3.2 Пара 8 (Практика 3): Стресс-тестирование концепции (Краш-тест)

Практика: Вы выступаете в роли «вредного заказчика/инвестора» или . Студенты за пару должны адаптировать свою схему по архитектурному фреймворку "AfRel".

• вводите новое внезапное ограничение («Бюджет урезали еще в два раза, а сроки сократили»)
• "Круто! А теперь масштабируем в 200 раз!"

3.3 Пара 9 (Практика 4): Защита проектов

Практика: Индивидуальная защита. Студент за 3–4 минуты презентует свое архитектурное решение и доказывает:

• что оно оптимально в рамках заданных ограничений.
• готово к сжатию
• сопротивляется нарушениям
• готово к масштабированию с минимальными вложениями.