Оновлення діаграм логічної та фізичної архітектури

У будь-якому проекті з розробки програмного забезпечення, що передбачає розподілені системи з декількома розробниками, діаграми логічної та фізичної архітектури є найкращою практикою, але, на мій досвід, ці діаграми завжди починають добре підтримуватися на початку проекту, але не оновлюються, коли проект буде випущений і починаються фази технічного обслуговування.

Для складних проектів з великою кількістю розподілених процесів діаграми, як правило, застарівають або є неточними дуже швидко ще до початкового випуску, оскільки ніхто не має всіх знань.

Враховуючи це, я хочу задати такі питання громаді:

1. Наскільки важливими є точні та сучасні діаграми логічної та фізичної архітектури?
2. Чи є інструменти та процеси, які можуть допомогти їх оновлювати?
3. Хто повинен відповідати за їх оновлення? Як можуть робити внески адміністраторів, розробників та QA команди?

Я живу в реальному світі з обмеженнями у часі та проблемами з ресурсами, тому я розумію, чому більшість програмних документів або ігнорується, або залишаються застарілими, але навіть за таких умов я абсолютно наполягаю на тому, що діаграми бази даних створюються та підтримуються актуальними. Якщо це не звичайна реляційна модель і складається з сутностей, що мають документи, пари ключів-значень або структури JSON / XML, то об'єктивну модель цих елементів також слід створювати та підтримувати. Якщо все інше не вдасться до документаційних зусиль проекту, принаймні діаграма баз даних та / або об'єктна модель (и) дозволять одному працювати назад до передньої частини, щоб зрозуміти, що відбувається.

Існує чимало варіантів створення та підтримки програмних документів, але одним з моїх улюблених є Enterprise Architect. Це всеосяжно і зв’язки разом використовують регістри, діаграми послідовності, діаграми класів та інші.

Що стосується того, хто за це відповідає, я вважаю це зусиллями команди. Мало кому досконало подобається це робити, але це потрібно зробити. В кінцевому підсумку архітектор або технічний керівник проекту повинен відповідати за нього, делегуючи завдання належним чином.