テクニカルデザインドキュメントのツールと標準

Question

現在、私の同僚がテクニカルデザインドキュメントに使用しているツールと標準を知りたいと思います。

私の会社では、私たちはクライアントとサーバーのwin-appsだけを提供していましたが、私たちの設計ドキュメント用のテンプレートがありました。私たちのテンプレートは、常にデータベースダイアグラム、次にUIモックアップ、フィールドマッピング、機能の説明などから始まりました.WordとVisioでは十分なものがありました。しかし、最近では、Wiki、UMLダイアグラム、プロトタイピングツールなどを組み合わせています。設計者がプロジェクトごとに特定の瞬間に合ったツールや標準を自由に選択できるようにするのは良いことだと思いますか？または、企業がこれを強制して標準化すべきですか？

Answer 1

設計文書の背後にある理由は、関与するすべての人に明確なコミュニケーションを提供するためです。したがって、建築家としてどのようなツールを選んでも、完成した製品は、関係者全員と後でメンテナーが読む必要があります。したがって、少なくともいくつかのかなり標準的なツールを選択することは理にかなっています。それはまだ数年後になるでしょう。

しかし、設計ドキュメントは一般的に、プロジェクトやシステムを立ち上げたりするのに使われます。その後、よく文書化されたコードといくつかの基本的な文書で十分であるはずです。おそらくドキュメントの構成にもっと注意を払い、人々が将来何を探しているのかを簡単に見つけることができます。ドキュメントを格納するための何らかの標準的なリポジトリ構造/システムを強制するのに役立ちますが、必ずしもすべての種類のテンプレートをドキュメント化する必要はありません。コンテンツではなく、ツールに焦点を当てます。

Answer 2

あなたのプロジェクトがクッキーカッターでない限り、現在の仕事に最適なツールの組み合わせを適用するだけです。つまり、緩い（大まかなガイドライン）か狭い（特定の状況に適用される）基準がおそらく正当化されるだろう。

Answer 3

リード開発者またはチームメンバー（後で記録される可能性があります）間の徹底的な議論は、私の意見ではどのドキュメントよりもずっと価値があります。彼らに道具を選ぶ自由を与え、早い段階で高度な技術的意思決定の要約を書くように頼んでください。これは、後でプロジェクトの文書化の基礎となります。技術的な設計書類は時代遅れになり、書き込むのに時間がかかります。

Answer 4

アーキテクチャー時に指定されたツールと標準が、設計の文書化方法を説明する1組であるべきだと思います。これらのことを文書化するための標準を持つことは本当に重要です。さもなければ、彼らは道端で落ちる傾向があります。設計ドキュメントが異種である場合、本当にデザインを最もよく知っている必要がある人は、本当に必要なときに本当に必要なデザイン情報を見つけることができない可能性があります。

つまり、ツールと標準の選択は、それぞれの組織によって異なります。組織のために何が働いても、それは正しいものです。標準（およびある程度はツール）に一貫性がある限り、個々の組織に選ばれたものはすべてそれらに適しています。それはただ決定され、施行される必要があります。