Рабочая ситуация
Торгово-сервисная компания открывает новые площадки в других городах. Действующее приложение обслуживает одну площадку и одну базу данных; его нужно развить так, чтобы выдержать рост, не остановив текущую работу.
Студент строит модель системы, описывает контекст и контейнеры, затем сравнивает два архитектурных варианта. ИИ-архитектор настаивает на масштабируемости, представитель эксплуатации — на простоте сопровождения и понятных отказах. После фиксации выбранного варианта сценарий сокращает бюджет и сроки: нужно пересмотреть решение, зафиксировать компромиссы и спланировать переход этапами.
Рабочее место
- Модель архитектуры по логике Structurizrединая модель, диаграммы контекста и контейнеров, проверка связности элементов.
- Реестр архитектурных решенийзаписи ADR с контекстом, вариантами, выбором и последствиями.
- Рабочий мессенджеробсуждение ограничений с архитектором, эксплуатацией и руководителем проекта.
Как проходит работа
- Собрать ограничения: нагрузка, данные, сроки, команда сопровождения, допустимые простои.
- Построить модель текущей системы и два целевых варианта.
- Сравнить варианты по явным критериям и записать архитектурное решение.
- После сокращения бюджета пересмотреть выбор, обновить ADR и обосновать компромиссы.
- Спланировать переход этапами, совместимыми друг с другом и с текущей эксплуатацией.
ИИ-команда
- ИИ-архитекторпредлагает масштабируемые решения, задаёт вопросы о границах контейнеров и интеграциях.
- Представитель эксплуатациитребует наблюдаемости, простых отказов и понятного порядка обновления.
- Руководитель проектаприносит сокращение бюджета и сроков, просит показать, что останется работать на каждом этапе.
Что проверяется
| Итоговый артефакт | Автоматическая проверка в заданных границах | Оценка преподавателя |
|---|---|---|
| Два варианта модели, запись архитектурного решения, этапы перехода | Связность модели, соблюдение явно заданных квот и совместимость шагов перехода в сценарии | Качество альтернатив, допущений, архитектурного обоснования и плана перехода |
Архитектурные решения оцениваются по рубрике, а не по совпадению с единственной «правильной» схемой.
Связанные дисциплины
Тренажёр подходит для дисциплин по архитектуре и технологии проектирования информационных систем и для междисциплинарного проекта по управлению ИТ-проектами.
Общая механика серии
- Рабочая ситуациясинтетические документы, данные, сроки и противоречия образуют конкретную задачу, а не свободную беседу.
- Ролевой мессенджерзаказчик, оператор, разработчик или эксплуатация располагают только сведениями своей роли; допустимые факты сценария заданы заранее.
- Первый результатстудент создаёт спецификацию, схему, код, модель или прототип, который можно сохранить и проверить.
- Изменение условийсценарный движок вводит новую версию контракта, ограничение, возмущение или новые данные; ИИ не придумывает эти события самостоятельно.
- Пересмотрстудент обновляет решение, повторяет проверки и объясняет, почему изменил или сохранил первоначальный подход.
- Безопасное исполнениепользовательский код и SQL запускаются только в изолированной среде; реальные секреты, персональные данные и производственные системы не нужны.
Ролевые ИИ-персонажи не получают скрытый ключ проверки и не выставляют итоговые баллы: вычисляемую часть результата проверяет программное ядро, открытое инженерное решение оценивает преподаватель по заранее известной рубрике.
Статус описания: Проектируется. На странице описан проектируемый тренажёр — целевой учебный сценарий, а не готовое приложение. Состав воспроизводимых сред, механика и критерии проверки согласуются с вузом; реализация и приёмка выполняются отдельно.
Названия и логотипы сторонних платформ обозначают учебные профили интерфейсов и операций и не означают поставку оригинальных продуктов, интеграцию с ними, партнёрство или одобрение правообладателей. Упоминание программ Топ-ИТ и «Приоритет-2030» обозначает область применения тренажёра, а не официальное включение в эти программы.
