クイック・リファレンス

すぐに開始したい方のために、このクイック・リファレンスでは、基本となる重要な概念、用語、およびビジュアル要素を説明しています。

このトピックには、以下のセクションが含まれます。

用語および概念

Rational Team Concert™ 成果物は、リポジトリーに保管されます。リ ポジトリーには、許可されたユーザーのみがアクセスできます。

リポ ジトリーには、プロジェクトの成果物を参照するプロ ジェクト・エリアが含まれます。 各プロジェクトには関連するプロセスがあり、プロセスはプロジェクトの実行 方法を制御したり、Jazz™ の動作方法をカスタマイズします。 プロセスはプロセス構成およびプロセス記述によっ て定義されます。 プロセス構成は、 プロジェクトの反復およびこれらの反復の間に プロジェクトが動作する方法を定義します。 プロセス記述は、プロセスを 説明する Web サイトに対応します。

このダイアグラムは、プロジェクト・エリア、チーム
・エリア、ストリーム、リポジトリー・ワークスペース、お
よびその他のチーム成果物の間の大まかな関係を表しま
す。

スクラム、OpenUp、および Simple という、 いくつかの事前定義プロセスがあり、これらから選択で きます。 また、独自のプロセスを 定義したり、既存の定義を変更することもできます。 詳しくは 、プロセス・テンプレートを参照してください。

プロジェクト・エリア内から、プロジェクトの成果物にアクセスできます。

プロジェクト・エリアは 、一連のチーム・エリアに分解されます。チーム・エリア は、プロジェクトに携わるチームを表します。 チーム・エリアごとに、チーム ・メンバーおよびメンバーがチーム内で担うプロセス役割のリストがあります。 ユーザーは、 複数のチームのメンバーになることが可能です。 各チーム・エリアでは、チームとそのサブチームのプロセ スを調整するためのプロセスのカスタマイズを定義で きます。

単純なプロジェクトの場合、すべての アクティビティーは単一のストリームを持つ、単一の メイン予定表上にあります。保守アクティビティー のような作業用に、追加の予定表を作成することができます。それぞれの予定表には、独自のチーム・エリアおよびプロセスのカスタマイズがあります。

計画された 作業は、ワークアイテムで記述されます。 プロジェクト・エリアで 使用されるワークアイテムのタイプは、プロセスによって定義されます。例えば、スクラム・プロセスは、以下のワークアイテム・タイプを定義します。

  • 問題点
  • タスク
  • ストーリー
  • Epic
  • Track Build Item
  • Impediment
  • 導入項目
  • レトロスペクティブ

各ワークアイテム・タイプが、独自の状態遷移およびカス タム・フィールドを持つことができます。 ワークアイテムはワークアイテム・カテゴリーごとに分けられるため 、機能エリアごとにワークアイテムを編成できます。 各プロジェクト・エリアでは、使用 可能なワークアイテム・カテゴリーのリストを定義します。 各チーム・エリアは、チームが担当す る機能エリアのワークアイテム・カテゴリーに関連付けられています。

ワークアイテムは、照 会を実行して、検索できます。 照会はユーザー専用にすることも、チームと共用す ることもできます。

プロジェクト・エリアの作業は、一連 の反復で行われます。各反復には、開始日および終了日を設定できます。 反復の 1 つは、プロセスによって現在の反復として定義されます。 作業の計画時に、ワークアイテムを特定 の反復の対象にします。 反復計画を作成することで、1 つの反復を対象とする必要がある、すべての作業の計画 を立てることができます。 リリース・プランで、反復に分解されるリリースについての全体的な作業を計画できます。

個人用の リポジトリー・ワークスペースを使用して、ソース管理下にあるプロジェクト・ファイルを処理します。 ファイルおよびフォ ルダーをコンピューター上にコピーするには、リポジトリー・ ワークスペースをロードします。 Jazz Team Server は、変更セットを使用してソース管理ファイル に行ったすべての変更を追跡します。各変更セットは、変更されたファイルやフォルダーを含み、コメントが記載され、変更の原因となった関連するワークアイテムを参照しています。変更セットをチェックインすると、変更されたファイルとフォルダーが IDE ワークスペースからリポジトリー・ワークスペースにアップロードされます。チェックインされた変更セットは、リポジトリーに保管されますが、変更セットを提出するまでは開発チームの他のメンバーと共用されません。チェックインと提出プ ロセスによって、変更に対する保護が強化され、即座 に提出しなくても引き続き変更が可能であるという柔 軟性が確保されます。

チーム は、ストリームを使用してプロジェクト・ファ イルのマスター・コピーを保管します。各リポジト リー・ワークスペースには、コピーが保持されます。 リポジトリー・ワーク スペースおよびチームのストリームは、フローによっ て接続されます。 変更をマスター・コピーに取り込むには、 変更セットをリポジトリー・ワークスペースからストリームに 提出します。これらは、発信変更セットです。 着信変更セットは、他 のチーム・メンバーからストリームに送信された変更セ ットです。 着信変更セットを受け入れて、変更をリポジトリー ・ワークスペースおよび IDE ワークスペースに取り込みます。

ソース管理ファイル・ベースは、規則的に累積された (前に構築されたすべての変更セットをベースにした) 変更セットで構築されます。変更ヒストリーは、リポジトリー・ワークスペースまたはストリームに送信された一連の変更セットです。

ソース管理ファイル・ベースは 1 つ以上の個別のコンポーネントに分割できます。コンポーネントごとに、フォルダーとファイルの独自のツリーおよび独自の変更ヒストリーが存在します。 単純なリポジトリー・ワークスペースおよびストリ ームは、単一のコンポーネントから構成されます。 複数のコンポーネントは、チームで階層化ソフトウェアを構築する場合に便利です。これは、それぞれの部分が独立に近い状態で発展して別個にデプロイされるためです。

関心のある時点を取り込むには、リポジトリー・ ワークスペース内で個々のコンポーネントの ベースラインを作成します。 すべてのコンポーネント全体で同時ベースラインを 取り込むには、 スナップショットを作成します。

各チームは、独自の チーム・エリアに関連するビルド定義内に記述される ビルドを持つことができます。 ビルド定義では、ビルドの 間隔、使用するビルド・スクリプト、およびファイル の取り出しに使用するリポジトリー・ワークスペース を指定します。 ビルドは、さまざまなビルド・エンジ ンで実行できます。 ビルドを、リリースにレベル上げする ことができます。 その後で、ユーザーはワークアイテムを特定 のリリースごとに分けることができます。

フィードを使用して、同僚がどのような作業を しているのか、または何が他のチー ムで行われているかを認識できます。 リポジトリー内の成果物が変更されると、フィードに イベント通知が自動的に送信されます。

クライアント

以下のいずれのクライアント・ユーザー・インターフェースでも作業できます。


フィードバック

この情報はお役に立ちましたか? Jazz.net でフィードバックをお送り頂けます (登録が必要です): フォーラムにコメントを記入したり、バグを送信したりすることができます。