あなたはどのような重要なデザイン成果物を制作していますか?[閉まっている]

Question

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

私が現在取り組んでいるプロジェクトは、8 年以上にわたって制作されています。この Web アプリケーションは、それ以来、積極的に強化され、維持されてきました。当社では CMMI ベースのポリシーとプロセスを導入しており、実践の一部は明確に定義されていますが、設計段階はほとんど見落とされてきました。ベストプラクティス、誰か？

Answer 1

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

一般的なサーバーベースの「エンタープライズ アプリケーション」の場合、最低限次のようなものが必要です。

• 詳細な機能設計文書 (別名仕様)。一般的にはジョエルの考えに沿ったものです。 WhatsTimeIsIt の仕様例, ただし、おそらくいくつかの UML ユースケース図が含まれています。
• ソフトウェアの技術設計文書。必ずしもシステムを 100% カバーできる詳細な内容ではありませんが、すべての主要な領域について詳細に説明されており、すべての設計上の決定事項が含まれています。UML マニアとしては、パッケージ図、コンポーネント図、主要な機能クラス図、そしておそらくいくつかのシーケンス図に沿ったたくさんの図が見られると嬉しいでしょう。
• インフラストラクチャ設計ドキュメント。おそらく、概念的な設計には UML 配置図が使用され、より物理的なものにはネットワーク図が使用される可能性があります。

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

それらの有用性に関して、私の哲学は常に、開発チームは常に電話番号を渡すことなくサポート チームにアプリケーションを引き渡せるべきだというものでした。デザインアーティファクトが、アプリケーションが何を行うのか、どのように行うのか、どこで行うのかを明確に示していない場合、サポートチームがアプリケーションに対して狂犬病と同じ配慮と注意を払うことになることがわかります。

ソフトウェアが完成した後に開発チームからサポートチームに引き渡す慣行を正当化するつもりはないことを言っておかなければなりません。 終了した, 、あらゆる種類の興味深い問題が提起されていますが、私は経営陣が望むのであればそれが可能であるべきだと言っているだけです。

Answer 2

実用的なコードとホワイトボードの図面。

:P

Answer 3

デザインは開発中および開発後に大きく変更されるため、慎重に作成したドキュメントのほとんどはソース管理内で朽ち果て、コードが本番環境になると、役立つというよりもほとんど邪魔になります。私は、設計ドキュメントは良好なコミュニケーションに必要であり、何かを開発する際に自分の考えを明確にするために必要であると考えていますが、その後、設計ドキュメントを適切に維持するには大変な努力が必要です。

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

Answer 4

私たちのモデル (ビジネス プロセス アプリケーションにかなり固有) では、設計アーティファクトには次のものが含まれます。

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

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

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

Answer 5

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

Answer 6

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

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

私は設計仕様のさまざまな情報を確認するのが好きです。

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

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