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