私たちは常に関数やクラスを書きますが、そのロジックは非常に複雑です。これらの構造が仕様化されていないと、あとで自分たちでもアイデアを把握するのが難しくなります。
複雑な関数やクラスの仕様をどのように記述しますか?
リンクだけでなく、あなた自身の経験について教えてください。ありがとうございます。
18320 次
4 に答える
13
機能仕様に関する最大の課題は、形式そのものではなく、仕様を推進するもの (要件) や仕様に基づいて構築されるもの (テスト ケース、ドキュメント) との同期を維持することだと思います。
そのため、私はこの問題を紙ベースではなくモデルベースのアプローチで処理することを好みます。
私は UML モデリング ツール (Sparx Systems の Enterprise Architect ですが、多くのツールも同様に機能します) を使用して、プロジェクトのすべての成果物を 1 か所に取り込み、それらの間のトレーサビリティを作成します。Enterprise Architect では、要件成果物から設計成果物へのトレーサビリティを作成できます (たとえば、両方を同じ図に配置し、マウス ドラッグで一方から他方へのコネクタを作成するだけです)。
私の「機能仕様」は、実際にはアクティビティ図の集まりであり、システム内のユース ケースごとに 1 つです。各ユース ケースは、そのユース ケースを必要とする 1 つ以上の要件に関連付けられています。エンド ユーザーでさえ、アクティビティ図をたどって検証するのは簡単だと思います (従来の紙ベースの機能仕様を、エンド ユーザーに読んでもらい、理解して検証するのはもちろん、どれだけ簡単に理解してもらえるでしょうか?)
同様の方法で、アクティビティ図 (ユース ケース) からクラス図などの特定の設計成果物へのトレーサビリティを作成できます。
QA は、テスト ケースをモデル化し、テスト ケースからユース ケースへのトレーサビリティを作成できます。このようにして、テスト ケースがない (または十分なテスト ケースがない) ユース ケースがあるかどうかを確認します。
ツールとしての Enterprise Architect の優れた点は、これらのすべての成果物が SQL データベースに格納されていることです。そのため、時間をかけて作成したいくつかのクエリを実行するだけで成果物を見つけることができます。
于 2009-08-28T23:43:10.240 に答える
12
Joel on Software をチェックしてください。そしてここに。そしてここに。実際の例もあります。
于 2009-08-28T23:39:54.100 に答える