3

さまざまなプロジェクトで、分析フェーズで開発したユースケースモデルがプロジェクトの要件をカバーしていることを確認する必要がありました。そのために、要件ステートメント（一意に識別される）とユースケース（これも一意に識別される）の間である程度のトレーサビリティを得ることができました。場合によっては、トレーサビリティを有効にすることは、私が良い投資であると私が考えた（そして後で証明した）いくつかの追加の努力を意味しました。

さて、私が直面した最大の問題は、後で（変更要求の結果として、またはユースケースの変更の結果として）状況が変化し始めたときに、このトレーサビリティを維持することでした。

トレーサビリティ維持のためのベストプラクティスのアイデアはありますか？

（プロジェクトの他の項目に適用できます-たとえば、ユースケースとテストケース、または要件と受け入れテストケース）

後で編集 ツールが役立つかもしれませんが、トレーサビリティのギャップやエラーを検出することはできません。ナビゲーション...多分、しかし、変更を適用した後のトレーサビリティが最新または正しいという保証はありません。

4

5 に答える 5

4

トレーサビリティは、要件を管理するのが最も難しいものの 1 つであると思います。まず、要件が正しいことを確認することに次ぐものです。私の経験では、最高のトレーサビリティ ツールは人間です。

万能薬はありません。過去に私を助けてくれたもののいくつかのヒント。

  • ドキュメントは、誰もが簡単に取り出せる中央の場所に保管してください。それが Sharepoint であろうと、wiki であろうと、ネットワーク ドライブであろうと、私は気にしません (ただし、可能であれば、バージョン管理を提供するものが好きです)。古いコピーを使用したり、開発者の邪魔をしたりするのではなく、答えを求めてそこに行くことを誰もが知っているように、それを 1 か所に保管し、それを丸ごと売り込みます。
  • アーティファクトまたはそれらの機能グループを管理するための中心的な連絡先がある場合、それは非常に役立ちます。それらと問題を理解している人は、どこに行くべきか、何を更新するべきか、そして引き継がなければならない依存関係があるかどうかを知っています。
  • アーティファクトの管理者は、アーティファクトにコミットし、それらを最新の状態に保つ必要があります。サイトにいくつかの要件ドキュメントを設定してから 1 年経った今でも、それらを最新の状態に保っています。ほとんどの開発者がそれをしなければならないことを恐れていることは知っていますが、それから 1 年経った今でも、それらを振り返って、機能要件が時間の経過とともにどのように変化したかを確認することから恩恵を受けています。
  • 必須ではありませんが、時間の経過に伴う変更をすばやく特定できると便利です。ドキュメント プロセッサのバージョン追跡機能がある場合は、それを使用してください。そうでない場合は、少なくともドキュメントの変更ログを含めるか、バージョン番号への参照を使用して新しいテキストにマークを付けるだけです。
  • 過去に、他のドキュメントやアーティファクトへの参照など、依存関係の参照をアーティファクトに入れようとしましたが、それらが古くなっているか、追跡するのが難しく、更新されていないことがよくありました。規律はこれを克服することができますが、私たちのほとんどはやるべきことが多すぎますよね? したがって、ドキュメント/アーティファクト間の相互参照を構築することは、ツールまたはまだリリースされていない無料の要件管理ユーティリティが必要な場所だと思います:)
于 2009-10-20T20:39:05.253 に答える
1

維持するトレーサビリティには、システム要件からサブシステム要件、設計要件、検証要件（最も重要なもの）、コード要件、問題要件など、さまざまな種類があります。

Word、Excel、および優れた問題追跡システムは大いに役立ちます。しかし、トレーサビリティを示す必要がある場合、それらは苦痛になる可能性があります。トレーサビリティを手動で維持することは、エラーが発生しやすく、労働集約的です。IBM Doorsシステムは、私がこれまで使用した中で最高のツールです。しかし、それらは高価です。最近、非常にうまく機能するシステムUltimateTraceを見つけました。

于 2011-12-05T23:11:36.830 に答える
1

私たちは 3 年前に、Rational ツールを使用して要件を記述しました。これらのツールでは、多くの機能がトレーサビリティに関係しています。

これらのツールの使いやすさは完璧ではないことがわかりました。それらは私たちが必要とする基本的な機能を提供してくれましたが、それらの制限を回避するために多くの時間を失いました.

コードまでのトレーサビリティについて質問されていないと思いますので、回答から除外します。

ステートメントとユースケースの一意の ID について言及しているように、それらを管理するために既にツールを使用している可能性があります。

本質的に、単純なリレーショナル モデル (おそらくデータベース内) は、一意に識別されたピース間の関係をカバーできます。

それを行う簡単なツールを探します。1 人だけが変更できる場合、それは単に Excel シートである可能性があります。

2 つのドキュメント タイプをリンクするだけでは、おそらく十分ではないことに注意してください。
ステートメント、ユース ケース、テスト ケース、要件、および受け入れテスト ケースの 5 つのタイプについて言及されました。
いくつかのステップを含むビューを得るために、推移性 (リレーショナルの世界ではテーブルを結合するため) が常に必要でした。

于 2009-10-19T13:47:31.010 に答える
0

最善の方法は、バグトラッカーを使用することだと思います。各要件はバグとして追跡され、開発の変更はそれに関連付けられ、変更はバグノートで保持できます。

多くのバグトラッカーでは、複数のバグを (重複などとして) 関連付けることができるため、これを使用して個別の要件を結合し、個別に追跡するために分離することができます。

他のすべての成果物を SCM に保存する場合 (つまり、設計ドキュメントなど)、要件に関連付けることで、これらも追跡できます。

これらすべてを支援するツールがありますが、これらの「完全なライフサイクル」ツールは、1 つのアプリであまりにも多くのことを実行しようとするか、または一緒に「統合」する関連アプリとして非常に高価であるため、実際には使用できないことがわかりました。

于 2010-05-06T22:14:49.127 に答える
0

要件ステートメントと各ユース ケースにバージョン # を追加する必要があります。最新のものはすべてに伝達され、簡単にアクセスできる場所 (物理的および/またはコンピューター/Web) に保存されます。以前の要件ステートメントおよび/またはユース ケースが何であったか、いつ変更されたか、誰が、誰によって承認されたかを含む変更ドキュメントを追加する必要があります。

したがって、要件仕様とユースケースを見ると、最新のビューがあり、変更について質問がある場合は、参照する変更ドキュメントがあります (履歴情報で要件またはユースケース仕様に負担をかけないでください。ただし、簡単にアクセスできる意味のある形式で、参照として歴史的な情報を保管してください)

于 2009-10-20T19:57:41.117 に答える