Mise à jour des diagrammes d'architecture logique et physique

Dans tout projet de développement logiciel impliquant des systèmes distribués avec plusieurs développeurs, avoir des diagrammes d'architecture logique et physique est la meilleure pratique, mais d'après mon expérience, ces diagrammes commencent toujours par être bien entretenus au début d'un projet, mais ne sont pas mis à jour au fur et à mesure que le projet est publié. et les phases de maintenance démarrent.

Pour les projets complexes avec beaucoup de processus distribués, les diagrammes ont tendance à devenir obsolètes ou inexacts très rapidement même avant la version initiale, car personne n'a toutes les connaissances.

Compte tenu de ce contexte, je veux poser les questions suivantes à la communauté:

1. Quelle est l'importance d'avoir des diagrammes d'architecture logique et physique précis et à jour?
2. Existe-t-il des outils et des processus qui peuvent aider à les maintenir à jour?
3. Qui devrait être responsable de leur mise à jour? Comment les administrateurs système, les développeurs et les équipes d'assurance qualité peuvent-ils contribuer?

Je vis dans le monde réel avec des contraintes de temps et des problèmes de ressources, donc je comprends pourquoi la plupart des documentations logicielles sont ignorées ou laissées à jour, mais même dans ces conditions, j'insiste absolument pour que des diagrammes de base de données soient créés et tenus à jour. Si ce n'est pas un modèle relationnel habituel et se compose d'entités avec des documents, des paires clé-valeur ou des structures JSON / XML, un modèle d'objet de ces éléments doit également être créé et maintenu. Si tout le reste échoue dans les efforts de documentation d'un projet, au moins un diagramme de base de données et / ou des modèles d'objet permettront de travailler en arrière vers le front-end pour comprendre ce qui se passe.

Il existe de nombreuses options pour créer et gérer des documents logiciels, mais l'une de mes préférées est Enterprise Architect. Il est complet et relie les cas d'utilisation, les diagrammes de séquence, les diagrammes de classes et autres.

Quant à savoir qui est responsable de cela, je considère que c'est un effort d'équipe. Peu de gens aiment vraiment le faire, mais cela doit être fait. L'architecte ou le responsable technique d'un projet devrait en dernier ressort en être responsable, en déléguant les tâches de manière appropriée.