論理および物理アーキテクチャ図を最新の状態に保つ
複数の開発者がいる分散システムが関係するソフトウェア開発プロジェクトでは、論理アーキテクチャと物理アーキテクチャの図を用意することがベストプラクティスですが、私の経験では、これらの図はプロジェクトの開始時に常に適切に維持されていますが、プロジェクトがリリースされても更新されません。メンテナンスフェーズが始まります。
多くの分散プロセスを持つ複雑なプロジェクトの場合、誰もすべての知識を持っているわけではないため、最初のリリースの前であっても、ダイアグラムは非常に早く古くなったり不正確になったりする傾向があります。
このような背景から、コミュニティに次の質問をしたいと思います。
- 正確で最新の論理および物理アーキテクチャ図を使用することはどのくらい重要ですか？
- それらを最新の状態に保つのに役立つツールとプロセスはありますか？
- 誰がそれらを最新の状態に保つ責任がありますか？システム管理者、開発者、QAチームはどのように貢献できますか？
私は時間の制約とリソースの問題がある現実の世界に住んでいるので、ほとんどのソフトウェアドキュメントが無視されるか、古くなっている理由を理解していますが、そのような状況下でも、データベースダイアグラムが作成され、最新の状態に保たれることを強く主張しています。通常のリレーショナルモデルではなく、ドキュメント、キーと値のペア、またはJSON/XML構造を持つエンティティで構成されている場合は、それらのアイテムのオブジェクトモデルも作成して保守する必要があります。他のすべてがプロジェクトのドキュメンテーション作業に失敗した場合、少なくともデータベースダイアグラムまたはオブジェクトモデル、あるいはその両方により、何が起こっているのかを理解するためにフロントエンドにさかのぼって作業できます。
ソフトウェアドキュメントの作成と管理には多くのオプションがありますが、私のお気に入りの1つはEnterprise Architectです。包括的であり、ユースケース、シーケンス図、クラス図などを結び付けます。
誰がこれを担当するかについては、チームの努力だと思います。それを完全に楽しんでいる人はほとんどいないが、それは行われなければならない。プロジェクトのアーキテクトまたはテクニカルリードは、最終的にはプロジェクトに責任を持ち、タスクを適切に委任する必要があります。