Исправление черновика для УрФУ

draft_urfy.md

@@ -1,78 +1,52 @@
-# УрФУ. Календарно-тематический план
+# УрФУ. Календарно-тематический план спецкурса
 
-## Часть 1 Методология и контекст
+**Дисциплина**: Прикладная информатика (Спецкурс: Архитектура систем в условиях ресурсных ограничений)
 
-### 1.1 Лекция "Архитектура как синтез в условиях противоречий"
+**Объем**: 18 академических часов (5 лекций, 4 практических занятия)
 
-Теория: Почему «идеальной» архитектуры не существует. Виды противоречий в конкретных условиях бизнеса:
+**Базовый инструмент**: Авторский архитектурный фреймворк AfRel
 
-* бюджет деньги/время:
-  + исследование рынка
-  + постановку целей
-  + формирование задач,
-  + организация процессов,
-  + формирование бизнес-архитектуры,
-  + формирование системной архитектуры,
-  + формирование архитектуры безопасности,
-  + архитектуры мониторинга и реагирования,
-  + подбор кадров,
-  + оборудование,
-  + разработку,
-  + тестирование,
-  + непрерывное развёртывание и доставку,
-  + сопровождение,
-  + выведение из эксплуатации.
+## Часть 1. Методология и контекст
 
-Введение в ваш авторский фреймворк.
+### 1.1 Лекция 1. Архитектура как синтез в условиях противоречий (2 часа)
 
-### 1.2 Лекция "Методика построения архитектуры в условиях правовых, экономических, ресурсных ограничений"
+* **Теория**: Почему «идеальной» архитектуры не существует в реальном бизнесе. Классификация противоречий в условиях жестких ограничений (бюджет, время, ресурсы).
+* **Жизненный цикл системы через призму ограничений**: от исследования рынка и формирования бизнес-архитектуры до системного проектирования, безопасности, мониторинга, непрерывного развертывания (CI/CD), сопровождения и выведения из эксплуатации. Подбор кадров и инфраструктурного оборудования под лимиты проекта.
+* **Введение в авторский фреймворк AfRel**: философия, ключевые аксиомы и цели.
 
-Теория: Как выявить материальные и измеримые ограничения проекта. Выявление системных требований (NFR) в условиях дефицита ресурсов. Матрица ролей и ответственностей. Реестры объектов ответственности, процессы производства. Дорожная карта, перспективный план, план-график работ, планирование расходов.
+### 1.2 Лекция 2. Методика построения архитектуры в условиях ограничений (2 часа)
 
-На дом: Студенты получают описание бизнес-кейса (например: "Стартап вашей мечты с бюджетом в 0 рублей на инфраструктуру, но он должен обеспечить вас зарплатой").
+* **Теория**: Выявление материальных ограничений и формирование NFR. Управленческий контур: матрица **RACI**, реестры, картирование процессов, планирование ресурсов.
+* **Домашнее задание**: Выбор сквозного кейса (стартап с нулевым бюджетом на инфраструктуру).
 
-## Часть 2. Индивидуальное проектирование руками
+## Часть 2. Индивидуальное проектирование и расчеты (Практика)
 
-### 2.1 (Лекция 3): Проектирования при дефиците ресурсов
+### 2.1 Лекция 3. Паттерны проектирования при дефиците ресурсов (2 часа)
 
-Теория: Архитектурный фреймворк **AfRel**, позволяющие экономить на каждом этапе (бизнес-процесс, архитектура, софт, интеграция, железо). Этапы каждого уровня (измеримая задача, риски, действия, планирование работ и исполнение, приёмка). Выбор модели по результатам ТЭП (Serverless|Microservices|ModuleMonolith), использование готовых Open-Source SaaS/PaaS). Шаблоны диалектических решений.
+* **Теория**: Экономия на всех уровнях по методологии **AfRel**: задачи, риски, действия. Инженерные компромиссы: `Serverless` vs `Microservices` vs `Monolith`, использование Open-Source.
 
-### 2.2 (Практика 1): Моделирование AS-IS / TO-BE.Практика: Индивидуальная работа
+### 2.2 Практика 1. Моделирование целевого состояния (AS-IS / TO-BE) (2 часа)
 
-Студенты анализируют свой кейс по архитектурному фреймворку **AfRel**, фиксируют ограничения и строят верхнюю часть многоуровневой архитектуру предприятия (в markdown, Miro, Draw.io, PlantUML, UMLet, VS Code).
+* **Практика**: Самостоятельный анализ кейса через **AfRel**, фиксация граничных условий и проектирование верхнеуровневой архитектуры (Markdown, Miro, PlantUML).
 
-### 2.3 Пара 5 (Лекция 4): Оценка стоимости и рисков архитектуры
+### 2.3 Лекция 4. Экономика архитектуры: TCO и риски (2 часа)
 
-Теория: Как посчитать стоимость владения системой (TCO). Как оценить риски "бизнес-процессного", "архитектурного", "программного", "интеграционного", "инфраструктурного" долга и долга низкой квалификации (потери) исполнителей, который мы сознательно закладываем ради экономии времени или денег.
+* **Теория**: Расчет совокупной стоимости владения (TCO). Классификация техдолга по **AfRel**. Управление рисками: приоритеты, снижение, антикризисные сценарии.
 
-Меры по приоритизации рисков, снижению рисков, меры по устранению реализованных рисков, противоаварийные планы и тренировки.
+### 2.4 Практика 2. Детализация архитектуры и расчет TCO (2 часа)
 
-### 2.4 Пара 6 (Практика 2): Детализация архитектуры и расчет TCO
+* **Практика**: Детализация модулей, компонентов и инфраструктуры. Защита технико-экономического обоснования (ТЭО) выбранного стека.
 
-Практика: Студенты детализируют компоненты системы, формируют модули, разбивают по единицам развёртывания, описывают интеграции, планируют инфраструктуру и защищают расчеты: почему выбран именно этот стек под заданные ограничения, почему именно на этом этапе.
+## Часть 3. Валидация, стресс-тестирование и защита
 
-## Часть 3. Валидация и защита
+### 3.1 Лекция 5. Защита архитектурных решений (Architecture Review) (2 часа)
 
-### 3.1 Пара 7 (Лекция 5): Защита архитектурных решений (Architecture Review)
+* **Теория**: Аргументация решений, сведение к бизнес-метрикам (**ROI**, **Time-to-Market**), подготовка документов (**RFC**/**ADR**).
 
-Теория: Как продавать архитектуру бизнесу и команде разработки. Типичные ошибки при презентации технических компромиссов. Подготовка к защите.
+### 3.2 Практика 3. Стресс-тестирование концепции (Краш-тест) (2 часа)
 
-* обобщение модели системы на уровне бюджет/время -> выход на окупаемость, ROI.
-* подготовка презентации и сопроводительная записка по концепту проекта
-* подготовка к прениям и дискуссиям.
+* **Практика**: Симуляция: резкое сокращение бюджета/сроков или кратный рост нагрузки. Перестройка модели по **AfRel** под новые вводные.
 
-### 3.2 Пара 8 (Практика 3): Стресс-тестирование концепции (Краш-тест)
+### 3.3 Практика 4. Финальная защита проектов (2 часа)
 
-Практика: Вы выступаете в роли «вредного заказчика/инвестора» или . Студенты за пару должны адаптировать свою схему по архитектурному фреймворку "AfRel".
-
-* вводите новое внезапное ограничение («Бюджет урезали еще в два раза, а сроки сократили»)
-* "Круто! А теперь масштабируем в 200 раз!"
-
-### 3.3 Пара 9 (Практика 4): Защита проектов
-
-Практика: Индивидуальная защита. Студент за 3–4 минуты презентует свое архитектурное решение и доказывает:
-
-* что оно оптимально в рамках заданных ограничений.
-* готово к сжатию
-* сопротивляется нарушениям
-* готово к масштабированию с минимальными вложениями.
+* **Практика**: Питч-сессия. Доказательство оптимальности системы по **AfRel** (cost-cutting, resilience, масштабируемость).