レコード設定

レコード タイプのシステム全体の設定を使用して、セキュリティ ポリシーを管理およびカテゴリー化し、作業プロセスに適用することができます。
以下のタイプのシステム全体の設定は、プロジェクトと作業の両方を管理するためのものです。

ALMSecurityPolicy レコードは、カテゴリと関連付けられ、プロジェクトとも関連付けられます。カテゴリを参照するプロジェクトが作成されるためです。 コンポーネント開発を行うチームでは、1 つ以上のオファリングの一部として、それぞれが独自のカテゴリとリリースを持つ、複数のコンポーネントが存在する場合があります。この場合、カテゴリと SecurityPolicy 間の 1 対 1 の関係によって、一部のレコードが、それを確認する必要がある人物に対して表示されなくなることがあります。 可視性の問題を回避するには、1 つの大きな ClearQuest ユーザー グループを ratl_context_groups 参照として SecurityPolicy に含めるか、コンポーネントで作業しているすべての開発チームが共有する SecurityPolicy によって参照されるすべてのユーザー グループを含む、各コンポーネントごとのユーザー グループを SecurityPolicy が持つ必要があります。 1 つの大きなグループを使用するのではなく、小さいグループのセットを維持し (あるいは SecurityPolicy を Everyone グループに設定して)、コンポーネントの構造によってグループと SecurityPolicy レコードを編成することにより、パフォーマンス上の利点も得られます。

コンポーネント開発の例

新規開発作業の、バージョンの付いたそれぞれの部分は、コンポーネントを指定するカテゴリと、そのカテゴリのバージョンを指定するリリースを持つプロジェクトにすることができます。

顧客が、開発チームによって製作された重要な製品に問題を発見します。この製品 (オファリングと呼ばれます) には複数のコンポーネントが含まれ、各コンポーネントは別のチームによって開発されています。顧客は、問題を発見すると、オファリングのコンポーネントではなく、オファリングに問題があると考えます。チーム リーダーが、そのオファリングに対する要求についての選別プロセスに従い、要求を確認すると、次のことがわかります。
  • 問題は、オファリングに含まれるコンポーネントにあります。コンポーネントの集合でしかなく、含まれているコンポーネントにあるもの以外に独自のコードを持たないオファリングではなく、コンポーネントで問題を修正する必要があります。
  • コンポーネントが修正されたら、オファリングに新バージョンのコンポーネントを含める必要があります。オファリングの新バージョンは、少なくとも問題を発見した顧客に (ほとんどの場合は他のすべての顧客にも) 提供する必要があります。
選別チームは、特定のカテゴリとリリース (たとえば、カテゴリ = 'OfferingA' とリリース = '1.0') のプロジェクトに対して入力される ALMRequest と関連する、2 つの ALMTask レコードを作成します。
  • プロジェクト カテゴリ = 'OfferingA'、リリース = '1.1' の ALMTask
  • プロジェクト カテゴリ = 'ComponentZ'、リリース = '3.4' の ALMTask
選別チームは、プロジェクト カテゴリ ='OfferingA'、リリース = '1.0' の ALMBaseline レコードを最初に確認します。これらの値は ALMRequest が FoundInProject として識別したものであるためです。また、ALMBaseline の [ComposedOfBaselines] フィールドにリストされている 'ComponentZ' のリリースが、リリース = '3.3' であることがわかります。

'ComponentZ' の ALMTask についてアクティビティが作成され、ソリューションの開発、文書化、およびテストが行われます。ALMBaseline レコードは、実際のベースラインがプロジェクト カテゴリ = 'ComponentZ'、リリース = '3.4' について作成されるときに作成され、2 番目の ALMBaseline がプロジェクト カテゴリ = 'OfferingA'、リリース = '1.1' について作成されます。その ALMBaseline レコードには、プロジェクト カテゴリ = 'ComponentZ'、リリース = '3.4' である ComposedOfBaselines 値 (別のベースライン レコード) があります。

BTBuild は、プロジェクト カテゴリ = 'OfferingA'、リリース = '1.1' である ALMBaseline について作成されます。テスト担当者は、プロジェクト カテゴリ = 'OfferingA'、リリース = '1.1' であるタスクのアクティビティ フォーム コントロールに表示される「開発」アクティビティの Build 列および Composite.Build 列に、BTBuild が表示されていることが確認できます。複合ベースラインから少なくともビルドの ID が生成されていることがわかり、そのビルドの名前がクエリーの結果セットに表示されます。コンポーネントのテスト担当者とオファリングのテスト担当者の両方が、複合ベースラインに基づいたビルドが存在することが確認できます。

複合ベースライン レコードにおいて、コンポーネントは [ComposedOfBaselines] フィールドにリストされます。


フィードバック