論理および物理アーキテクチャ図を最新の状態に保つ

複数の開発者がいる分散システムを含むソフトウェア開発プロジェクトでは、論理および物理アーキテクチャの図を作成することがベストプラクティスですが、私の経験では、これらの図は常にプロジェクトの開始時に適切に管理されていますが、プロジェクトのリリース時に更新されませんメンテナンスフェーズが開始されます。

多くの分散プロセスを持つ複雑なプロジェクトの場合、最初のリリースの前であっても、誰も知識を持っていないため、ダイアグラムはすぐに古くなったり不正確になったりする傾向があります。

このような背景から、コミュニティに次の質問をしたいと思います。

1. 正確で最新の論理および物理アーキテクチャ図を作成することはどれほど重要ですか？
2. それらを最新の状態に保つのに役立つツールやプロセスはありますか？
3. それらを最新の状態に保つ責任は誰にありますか？システム管理者、開発者、QAチームはどのように貢献できますか？

私は時間の制約とリソースの問題がある現実の世界に住んでいるので、ほとんどのソフトウェアマニュアルが無視されるか時代遅れになっている理由を理解していますが、そのような条件下でも、データベースダイアグラムが作成され、最新に保たれることを絶対に主張します。通常のリレーショナルモデルではなく、ドキュメント、キーと値のペア、またはJSON / XML構造を持つエンティティで構成されている場合、それらのアイテムのオブジェクトモデルも作成および維持する必要があります。他のすべてがプロジェクトのドキュメント化作業に失敗した場合、少なくともデータベース図またはオブジェクトモデル、あるいはその両方により、何が起こっているのかを把握するためにフロントエンドに戻ることができます。

ソフトウェアドキュメントの作成と保守には多くのオプションがありますが、私のお気に入りの1つはエンタープライズアーキテクトです。包括的であり、ケース、シーケンス図、クラス図などを組み合わせて使用​​します。

これについて誰が責任を負うかについては、チームの努力と考えています。楽しんでいる人はほとんどいませんが、やらなければなりません。プロジェクトのアーキテクトまたは技術リーダーが最終的に責任を持ち、タスクを適切に委任する必要があります。