AS
Можно посмотреть на классику С4 https://c4model.com/
Size: a a a
2019 October 16
K
делаем.. включаем: диаграмму развертывания, диаграмму компонент (с дата флоу) + описание компонент и сервисов, далее - значимые сиквенс-диаграммы, интеграционные обмены - какие должны быть/используются/переиспользуются, описание реализации нфт требований (отказоустойчивость, масштабирование, резервирование)
K
и там может быть включено - описание модели данных, ограничения/допущения
AP
Коллеги, всем доброго дня) Возникла необходимость в составлении такого документа, как High Level Design (HLD), на уже существующую систему, новую для нас. Лежать инфа будет в конфлюенсе.
Сталкивались ли вы с таким документов и что в нем описывали?
Сталкивались ли вы с таким документов и что в нем описывали?
Немножко зависит от того, кто его будет читать. Я вообще считаю, что документы должны быть писаны не по абстрактным стандартам, а с целью донести нужную информацию конкретным ролям\людям.
Мы традиционно включали следующие разделы
- краткое описание проекта + ссылки на документы (обычно БФТ или другие входные требования)
- риски и ограничения
- интеграционную картинку (вот её смотрят все)
- верхреуровневые сценарии (система 1 вызывает систему 2...)
- список систем и верхреуровневый список доработок\изменений в них, ответственные за доработки (сюда смотрит большинство, после нахождения своей системы на картинке)
- оценку по сайзингу\влиянию
- (опционально) ссылки или документы, связанные с участвующими системами - спеки, названия методов, всё что угодно
Мы традиционно включали следующие разделы
- краткое описание проекта + ссылки на документы (обычно БФТ или другие входные требования)
- риски и ограничения
- интеграционную картинку (вот её смотрят все)
- верхреуровневые сценарии (система 1 вызывает систему 2...)
- список систем и верхреуровневый список доработок\изменений в них, ответственные за доработки (сюда смотрит большинство, после нахождения своей системы на картинке)
- оценку по сайзингу\влиянию
- (опционально) ссылки или документы, связанные с участвующими системами - спеки, названия методов, всё что угодно
AT
Спасибо!
Смотрю, в этом фреймворке вообще много интересного
https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Artifacts.html
Смотрю, в этом фреймворке вообще много интересного
https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Artifacts.html
DK
Немножко зависит от того, кто его будет читать. Я вообще считаю, что документы должны быть писаны не по абстрактным стандартам, а с целью донести нужную информацию конкретным ролям\людям.
Мы традиционно включали следующие разделы
- краткое описание проекта + ссылки на документы (обычно БФТ или другие входные требования)
- риски и ограничения
- интеграционную картинку (вот её смотрят все)
- верхреуровневые сценарии (система 1 вызывает систему 2...)
- список систем и верхреуровневый список доработок\изменений в них, ответственные за доработки (сюда смотрит большинство, после нахождения своей системы на картинке)
- оценку по сайзингу\влиянию
- (опционально) ссылки или документы, связанные с участвующими системами - спеки, названия методов, всё что угодно
Мы традиционно включали следующие разделы
- краткое описание проекта + ссылки на документы (обычно БФТ или другие входные требования)
- риски и ограничения
- интеграционную картинку (вот её смотрят все)
- верхреуровневые сценарии (система 1 вызывает систему 2...)
- список систем и верхреуровневый список доработок\изменений в них, ответственные за доработки (сюда смотрит большинство, после нахождения своей системы на картинке)
- оценку по сайзингу\влиянию
- (опционально) ссылки или документы, связанные с участвующими системами - спеки, названия методов, всё что угодно
А насколько у вас были сложные сценарии?
ОК
Спасибо!
Смотрю, в этом фреймворке вообще много интересного
https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Artifacts.html
Смотрю, в этом фреймворке вообще много интересного
https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Artifacts.html
Да, довольно таки все продумано.
ОК
Вот здесь хорошо жизненный цикл визуализирован
AT
AP
А насколько у вас были сложные сценарии?
в чём измерять сложность?)
KG
в болящих жопках ( 3 жопки из 5 )
DK
в чём измерять сложность?)
С точки зрения описания. Это было в текстовом виде или use case, например?
DK
в болящих жопках ( 3 жопки из 5 )
Сложность проекта - 100 Мбж
AP
С точки зрения описания. Это было в текстовом виде или use case, например?
в личку кинул пример. Ну текст и текст, человекочитаемое верхреуровневое описание сценариев
AL
Коллеги, всем доброго дня) Возникла необходимость в составлении такого документа, как High Level Design (HLD), на уже существующую систему, новую для нас. Лежать инфа будет в конфлюенсе.
Сталкивались ли вы с таким документов и что в нем описывали?
Сталкивались ли вы с таким документов и что в нем описывали?
HLD - писали. Состав был такой:
- Контекст автоматизируемой деятельности. Текстовое описание + ЕР-Модельки. Выражает основания для глоссария проекта.
- Окружение разрабатываемого решения. Контекстная диаграмма. Сущности и интерфейсы. Выражает скоуп продукта (часть).
- Модель сценариев взаимодействия с окружением. Выражает скоуп продукта. Ещё один кусок.
- Опорная архитектура и типовые технические решения для самых важных сценариев взаимодействия. Выражает основания для принятия детальных технических решений и базовые гипотезы о том как делать продукт. Описывали в виде модели потоков (всего, что сквозь нас идёт), и некоторых обоснований.
- В области стэка давали перечень ключевых технологий и архитектурных принципов плюс их обоснование.
Но у нас это была разработка нового решения.
- Контекст автоматизируемой деятельности. Текстовое описание + ЕР-Модельки. Выражает основания для глоссария проекта.
- Окружение разрабатываемого решения. Контекстная диаграмма. Сущности и интерфейсы. Выражает скоуп продукта (часть).
- Модель сценариев взаимодействия с окружением. Выражает скоуп продукта. Ещё один кусок.
- Опорная архитектура и типовые технические решения для самых важных сценариев взаимодействия. Выражает основания для принятия детальных технических решений и базовые гипотезы о том как делать продукт. Описывали в виде модели потоков (всего, что сквозь нас идёт), и некоторых обоснований.
- В области стэка давали перечень ключевых технологий и архитектурных принципов плюс их обоснование.
Но у нас это была разработка нового решения.
AL
Плюс конечно куча инфы по назначению и скоупу документа, лист изменений и согласования.
DK
Мм, контекст автоматизируемой деятельности и ер-модельки - это то, что нам может очень пригодиться.
DK
Саша, спасибо) и вообще всем огромное спасибо за развёрнутые советы!