状態モデルの設計に関する考慮事項

このトピックでは、効果的な状態モデルにするために設計フェーズで対処する必要がある問題点について説明します。

デッド エンド

モデルの状態の中に、 変更依頼がそこに遷移しても、そのまま何もされずに見落とされる可能性がある状態が 存在しないことを確認してください。例えば、Postponed という状態がモデルに存在するのに、 この状態のレコードの処理が誰にもアサインされていないと、 通知も修正もされない変更依頼が発生します。

このような問題の 原因は微妙でわかりづらい可能性があります。例えば、Open 状態の変更依頼の処理に 3 人のエンジニアがアサインされており、 コンポーネント フィールドの値はそれぞれ赤、緑、青であるとします。 この場合、コンポーネント フィールドの値が黄またはブランクの変更依頼が 登録されると、その変更依頼は誰にも気付かれません。

状態の数

状態の数が少なく、開発アクティビティが多いモデルと、状態の数が多く、開発アクティビティが少ないモデルとの間の、トレードオフを入念に考慮する必要があります。 例えば、変更依頼のライフサイクルのいくつかのポイントで 確認アクティビティが発生する場合、確認アクティビティを各状態の一部として含めるのではなく、 確認という 1 つの状態として作成することも可能です。これらのアクティビティを 1 つの状態にグループ化することにより、 確認処理が適切に行われたかどうかを容易に確かめることができます。反対に、多数の状態を作成すると、 モデルが扱いにくくなり、保守が難しくなります。

重複レコード

Duplicate アクションは、 重複レコードのセット内の 1 レコードをアクティブ レコードとしてマークして、 それ以外のレコードを重複としてマークする手段を提供します。 重複としてマークされたレコードは修正できません。 このアクションにより、同じ変更依頼に対するすべての操作を 1 つの レコードで追跡できます。このアクションは、組み込みフィールドを使用します。 また、フォームに重複先コントロールと重複元コントロールを追加して、Duplicate アクションと Unduplicate アクションを 作成することでスキーマに追加できます。 Unduplicate アクションは、レコードの状態を、重複としてマークされる前の 状態に戻します。

事前定義のスキーマ

特定の機能や構成が組み込まれた さまざまな事前定義のスキーマが用意されています。スキーマを作成する場合、これらのスキーマをたたき台に使用できますが、 その際、事前定義されたスキーマの機能と目的の要件との違いを十分に比較検討してください。 事前定義されたスキーマについて詳しくは、「Rational ClearQuest の事前定義されたスキーマ」を参照してください。

並行開発

よく使用される成果物を共有する 複数の製品 (または製品種別) を並行開発する場合、 それを支援するスキーマの設計はとても困難です。設計にあたっては、 例えば、レポートされた障害が共有する成果物に起因しており、複数の製品に修正が必要な場合に、どのように情報を収集し、対応するか、また、(スケジュールが異なる可能性がある) 複数のビルドが必要な場合に、現在の障害の状態をどのように追跡するかといった状況を見込んで対処する必要があります。

単一レコードを使用してさまざまな作業を追跡するという 方法は、効果的なアプローチではありません。

代替のアプローチとして、 影響を受ける各製品に複数のレコードを登録するという方法があります。この方法だと、各アクティビティの状態を個別に追跡できます。 入力された最初のレコードに Save Default Values メカニズムを使用し、 それ以降のレコードには Load を使用すると、各コピーに対するデータ エントリの重複を 回避できます。(この機能は、Rational ClearQuest Web クライアントでは使用できません。) 欠点は、各レコードがほかのレコードから隔離されるため、 関連する別の問題に対する作業との調整を行わないと、作業が無駄になる可能性があることです。

より効果的な方法は、 階層構造を使用することです。この場合は、親レコードで問題を特徴付け、 子レコードを使用してそれぞれの製品、種別、バージョンの問題を追跡します。 レコード タイプは、親と子で異なっていてもかまいません。 一部のスキーマは、親と子に同じレコード タイプを使用して、 すべての情報を子に格納できるようにします (これにより、親子間の移動を省きます)。 その他のスキーマは、他の影響を受ける他の製品、種別、バージョンに共通する問題に対応し、それらの状態を追跡するためのある種の覚え書として、単純な子レコード タイプを使用します。 階層構造を使用するスキーマについて詳しくは、Rational ClearQuest ALM の使用 スキーマに関する資料を参照してください。


フィードバック