Комментарии 9
Насколько достаточно верхнеуровневой детализации которая понятна бизнесу для планирования разработки ИТ специалистами (разработчикам, аналитикам, PO). Понимают ли команды разработки что нужно реализовывать что бы планировать проект, бюджет и тд
Конечно, у команды разработки возникают вопросы к большей детализации задачи, но тут я стараюсь все-таки разделись этап оценки и планирования и системный анализ по решению.
Например, некоторым командам не достаточно 1 уровня C4 модели, поэтому делаю 2 уровень, так как для их системы это влияет на на оценку.
Также практически все команды для оценки просят протоколы для взаимодействия систем, потому что это влияет на сложность разработки.
Получается я стараюсь искать баланс в схеме и достаточное отображение, чтобы команды оценили доработку и запланировали. Без такой схемы планирование, бюджет, оценка не получается у команда (пробовали по документу бизнес требований делать оценки, не вышло)
Интересный подход, но у меня к вам вопрос: смогли бы вы сами на основе вашей схемы оценить, сколько под приведённый вами пример нужно заложить в бюджет? Железо, разработка, поддержка.
Команды разработки справляются с оценками по такой схеме, закладывают ресурсы на аналитику, разработку, тестирование.
Железо и сопровождение также возможно верхнеуровнево заложить бюджет по планируемой нагрузке объём хранимых данных и тд.
То есть к такой диаграмме ещё как правило идёт описание с ключевыми моментами решения - нагрузка, количество пользователей и тд, то что как раз помогает оценить.
Подскажите, а в вашей практике какие схемы использовались, что получить оценку от команд?
Насколько правильно рисовать стрелку между Администратором системы и "Единое окно КЦ"?
Кажется, что UseCase#2 - это взаимодействие Администратора с квадратиками "Метрики" и "Логирование", а в самой системе он не работает, либо это не описано.
Администратор взаимодействует с модулем "Модуль метрики бизнес-события" в самой системе "Единое окно КЦ", который показывает метрики по работе пользователей в системе. На данной схеме он не отражен с целью упрощения схемы.
Также Администратор взаимодействует с системой метрики, эту стрелочку дополню на схемы в статьей. Спасибо за комментарий!
У меня 2 вопроса:
На C2 2-го уровня стрелки от экторов идут до системы "Единое окно", а не до входящих в неё модулей. Просьба уточнить, это было сделано намеренно?
Я верно понял, что у вас в банке заказчик задачу приносят именно архитектору? Или я неверно трактовал вводные?
Да, показано верхнеуровневое взаимодействие Actor -> Система, чтобы упростить схему, так как Оператор КЦ может взаимодействовать и с другими модулями системы, но можно показать и с конкретном модулем. Аналогично и Администратор
Да, по процессу заказчик приходит к архитектору для проработки верхнеуровневой архитектуре (vision), далее этот документ по процессу согласуется с заинтересованными командами и уже поступает в детальную проработку системному аналитику. В этой статье есть подробнее про "Непрерывный цикл производства" https://habr.com/ru/companies/alfa/articles/768160/
Проектирование интеграции. Чек-лист — как подготовить архитектурное решение