Преглед на файлове

Добавление черновика для УрФУ

SVI преди 2 седмици
родител
ревизия
802b018ba6
променени са 1 файла, в които са добавени 78 реда и са изтрити 0 реда
  1. 78 0
      draft_urfy.md

+ 78 - 0
draft_urfy.md

@@ -0,0 +1,78 @@
+# УрФУ. Календарно-тематический план
+
+## Часть 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 минуты презентует свое архитектурное решение и доказывает:
+
+* что оно оптимально в рамках заданных ограничений.
+* готово к сжатию
+* сопротивляется нарушениям
+* готово к масштабированию с минимальными вложениями.