Посоветуйте как оформить документацию по обмену данными между системами.(Прочитано 13146 раз)
Стоит задача разработать обмен между двумя системами.
Нужно описать архитетуру обмена: состав мигрирующих данных, правила миграции, правила синхронизации, права доступа к вводу данных пользователями.
Подскажите как это дело оформить.



А какова цель, преследуемая этим описанием, и кто будет потребителем результата?
Исходя из этого и следует описывать.



Если вас никто не направит к более современным документам, попробуйте посмотреть  ГОСТ 19 и 34. Понимаю, что пользоваться ими непросто, но это лучше, чем совсем ничего.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Стоп. 474 задал правильный вопрос - кто потребитель. Давай дождемся ответа.

А чисто гипотетически можно предложить нарисовать Д взаимодействия м\у элементами и текстом описать входящие\выходящие данные и правила трансформации
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Нужно разработать документ "Архитектура обмена данными". Какие есть варианты оформления такой документации? Не хочется делать самопал в произвольной форме, а хотелось бы оформить согласно какой то нотации.



Чего только не напридумывает руководство различного уровня и заказчики :-). Главное назвать это громко -- "Архитектура <чего-то>" ... слово-то какое наукообразное!
Вобщем именно такой архитектуры "обмена данными", как таковой, не существует. Более того, не вполне понятно назначение такого документа.
 По классике выделяют бизнес-архитектуру, архитектуру информации и данных, архитектуру приложений (и в ее рамка программную архитектуру) и технологическую архитектуру. Иногда отдельно выделяют т.н. архитектуру безопасности, хотя по мне она "размазана" по всем вышеперечисленным архитектурам и выделять ее отдельно нет смысла -- просто остальные архитектуры следует проектировать с учетом требований информационной и прочей безопасности.  Следовательно, некоего стандарта на именно такого рода ДОКУМЕНТ не следует ожидать.
По сути, обмениваться данными может либо бизнес-процесс, либо какие-то информационные системы, зачастую в рамках некоего бизнес-процесса (если речь не идет о бакапах и прочих "технических" делах ...). Кроме этого, архитектура призвана в статической своей части показать интерфейсы различных компонент и в динамической части -- в рамках чего и каким образом эти компоненты взаимодействуют. Очевидно, что в процессе взаимодействия будет происходить обмен данными, который можно явно выделить.

Говоря о нотациях, можно использовать различные подходы -- от DFD, до UML Activity with object flow и Sequence\collaboration ...
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



vacoola, Вы ведь подобный вопрос уже задавали здесь недавно? В чем смысл повторения?



Объединил две темы
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Для начала, извините за повторение. Думал что никто не отвечает и написал еще раз. Проверял по RSS правда.

Потребителем будут руководство проекта и технические специалисты со стороны заказчика.
Главная цель понятно описать логику обмена понятную заказчику . А главное - подписать этот документ и и использовать его как аргументацию того что клиент должен заплатить за последующие до(пере)работки.
Ну и второстепенная цель - постановка задач разработчикам (но это уже на последующие проекты)



 



Возьмите для этого SRS. Там как раз будут и цели проекта и ФТ и БПр и НеФТ. + еще нарисуйте диаграмму взаимодействия между системами, в ФТ укажите что нужна такая-то передача данных между такими-то Системами и ссылка на раздел БПр, где будет расписаны правила трансформации данных.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19