スキーマ開発者は、所属部署・組織の変更管理プロセスの設計と計画をし、
そのプロセスを実装するスキーマを作成する責任を担っています。
設計と計画は、次のタスクから成り立っています。
- 状態遷移モデルを設計します。 状態遷移モデルは、変更依頼がその始まりから完了まで
進行していく状態を識別します。
状態の例には、[Submitted(登録済み)]、[Assigned(アサイン済み)]、[Resolved(解決済み)] が含まれます。
- ユーザーの役割を識別し、どのようにワークフローに適合するかを定義します。
例えば、プロジェクト マネージャーが変更依頼をアサインして、開発者が
変更依頼を調べて解決し、品質管理者が解決された変更依頼を
検証します。
- 所属部署・組織が必要とする情報を記録するために変更依頼の
レコード タイプに追加するフィールドを識別します。
Rational® ClearQuest® には、直ちに使用できる複数のスキーマがあります。 一般に
スキーマ開発者が、所属部署・組織に固有な変更管理プロセスを実装するために
これらのスキーマの 1 つをカスタマイズします。 スキーマのカスタマイズは、次のタスクから
成り立っています。
- 変更依頼のレコード タイプにフィールドを追加します。
- ボタンやリスト ボックスなどのフィールドとコントロールを追加することによって、
レコード フォームの外観を変更します。
- 状態遷移モデルを反映する変更依頼のレコード タイプに状態とアクションを
追加します。 アクションは、変更依頼をある状態から他の状態に
移動します。 例えば、アサイン アクションは、変更依頼を
submitted (登録済み) 状態から assigned (アサイン済み) 状態に移動します。
- フック スクリプトを書いて、ワークフローをカスタマイズします。 フック スクリプトは、
Perl または Visual Basic で書かれたコードで、Rational ClearQuest は、固有のユーザー アクションに応答して
これを実行します。 例えば、フィールドに関連付けられたフック スクリプトが、
指定された範囲内の整数を入力するようユーザーに要求します。
- 電子メールによる通知を有効にします。これによってユーザーが変更依頼を更新するたびに、
他のユーザーはその変更に関する電子メールを受信します。
- 機能を追加するために、または Rational ClearQuest を他の製品と統合できるようにするために
パッケージを適用します。 Rational ClearQuest のパッケージは、フィールド、フォーム コントロール、
フックなどの定義セットで、スキーマに適用して素早く機能を追加することが
できます。 例えば、添付ファイルのパッケージは、変更依頼のレコード フォームに
ユーザーが関連したファイルを添付できるためのタブを追加します。 その他のパッケージは、IBM® Rational ClearCase®、IBM Rational RequisitePro®、IBM Rational TestManager などの、他の製品との統合を可能にするために必要な定義を
追加します。