artifacts - どのような重要なデザイン アーティファクトを作成しますか?

Question

ソフトウェア開発ライフサイクルの過程で、どのような重要な設計成果物を作成しますか? それらがあなたの練習に不可欠な理由は何ですか?

私が現在取り組んでいるプロジェクトは、8年以上にわたって生産されています。この Web アプリケーションは、その間、積極的に拡張および保守されてきました。CMMI ベースのポリシーとプロセスが導入されており、実践の一部が明確に定義されていますが、設計段階はほとんど見過ごされてきました。ベストプラクティス、誰ですか？

Answer 1

過去に多くのウォーターフォールプロジェクトに取り組み、最近では多くのアドホックでアジャイルなプロジェクトに取り組んできましたが、プロジェクトの詳細に実際に依存しているとは言えませんが、作成したいデザインアーティファクトがいくつかあります（方法論/チーム構造/タイムスケール/ツールなど）。

一般的なサーバーベースの「エンタープライズアプリケーション」の場合、最低限、次のようなものにしたいと思います。

• 詳細な機能設計ドキュメント（別名仕様）。一般に、JoelのWhatsTimeIsItのサンプル仕様に沿ったものですが、おそらくいくつかのUMLユースケース図があります。
• ソフトウェア技術設計ドキュメント。100％のシステムカバレッジについては必ずしも詳細ではありませんが、すべての主要な領域で詳細に説明され、すべての設計上の決定が含まれています。少しUMLフリークなので、パッケージ図、コンポーネント図、主要な機能クラス図、そしておそらくいくつかのシーケンス図が適切に投入された線に沿ってたくさんの写真を見るのは素晴らしいことです。
• インフラストラクチャ設計ドキュメント。おそらく、概念設計のためのUML配置図と、より物理的なもののためのネットワーク図があります。

私がドキュメントと言うとき、上記のいずれかが複数のドキュメントに分割されているか、おそらくwiki/他のツールに保存されている可能性があります。

それらの有用性については、開発チームは電話番号を渡さなくても、常にアプリケーションをサポートチームに渡せるようにする必要があるというのが私の哲学です。デザインアーティファクトがアプリケーションの機能、実行方法、および実行場所を明確に示していない場合、サポートチームは、猛烈な犬と同じようにアプリに注意を払うことになります。

ソフトウェアを開発チームからサポートチームに引き渡すという慣行を立証しているわけではありません。これは、あらゆる種類の興味深い問題を引き起こします。管理者が望むなら、それは可能であるはずだと言っています。

Answer 2

作業コード...とホワイトボードの図面。

:P

Answer 3

デザインは開発中とその後に大きく変化するため、慎重に作成されたドキュメントのほとんどはソース管理で腐敗し、コードが本番環境に入ると、ヘルプよりもほとんど障害になります。デザインドキュメントは、コミュニケーションを図り、何かを開発する際の考え方を明確にするために必要だと思いますが、その後は、適切に維持するために多大な努力が必要です。

ホワイトボードの写真を撮り、JPEGをソース管理に保存します。これらは私の最高のデザインドキュメントの一部です！

Answer 4

私たちのモデル（ビジネスプロセスアプリケーションにかなり固有）では、設計成果物には次のものが含まれます。

• 各エンティティと属性に関するコメントを含むドメインデータモデル
• 各エンティティのすべての変更および作成トリガー、計算された属性、バリデーター、およびその他のビジネスロジックをリストしたプロパティファイル
• 画面定義のセット（ビューモデル）

しかし、これらは本当にデザインアーティファクトとしてカウントされますか？私たちのフレームワークは、これらの定義がシステムの実際のコードを生成するために使用されるようなものであるため、おそらく設計を超えています。

しかし、それらが二重の役割を果たしているという事実は、定義上、最新であり、常にコードと同期しているため、強力です。

Answer 5

これ自体は設計ドキュメントではありませんが、単体テストには、テストするコードがどのように機能するかを「説明する」という 2 つの目的があります。これの良いところは、ビルドが成功するには単体テストに合格する必要があるため、決して時代遅れにならないことです。

Answer 6

次の理由から、古き良き時代の設計仕様に取って代わるものはないと思います。

• これは、アプリケーションをどのように構築するかを他の人に伝える手段として機能します。
• 頭からアイデアを引き出すことができるので、同時に何百万ものことを追跡することを心配する必要はありません.
• プロジェクトを一時停止して後で戻る必要がある場合、思考プロセスを最初からやり直すことにはなりません。

デザインスペックでさまざまな情報を見るのが好きです：

• 当面の課題に対するアプローチの一般的な説明
• アプリケーションをどのように監視しますか?
• セキュリティ上の懸念事項とその対処方法
• フローチャート/シーケンス図
• 未解決の問題
• 既知の制限

単体テストは、アプリケーション開発に含める必要がある素晴らしい、ほぼ間違いなく重要な項目ですが、これらすべてのトピックを網羅しているわけではありません。