このFAQでは、開発プロジェクトでRational ClearCaseとRational ClearQuestを併用する際の基本的な事柄について取り上げます。
RationalのUnified Change Management （UCM）は、Rational Unified Processの主要コンポーネントであり、最良のソフトウェア・プラクティスを実現するための包括的なフレームワークです。Rational
SuiteおよびRational ClearCaseは、いずれもUnified Change Managementをサポートしています。UCMの基盤、またはUCMを実現している技術は、Rationalの統合型変更管理ソリューションであるRational
ClearCaseとRational ClearQuestです。Rational UCMソリューションは、開発の全ライフサイクルを通じて、画期的なレベルで変更を自動処理し、チームのコラボレーションを促進します。
UCMは、容易に適用でき、チームのあらゆる役割に合わせて最適化されている事前定義プロセスを介して、クロスファンクショナル（部門横断型）チームを統合します。UCMは、ClearCaseおよびClearQuestと協働し、各メンバー専用のワークスペースとTo
Doリストを自動設定します。したがって、分析者、テスト担当者、開発者、リリース・エンジニアの役割を問わず、プロジェクト・スコープや優先度、あらゆるプロジェクトに関連付けられているすべてのアクティビティーを容易に理解することができます。
UCMでは、プロジェクトの状況と作業負荷がチーム・メンバー全員に自動通知されるため、常に、チーム・メンバー全員が同じ理解を共有できます。プロジェクト管理者は、プロジェクト状態を体系化すると共に、作業負荷を検証し、プロジェクト完了日を予測することができます。
統合担当者やリリース・エンジニアは、UCMを活用して、プロジェクトの品質を確約できます。ソフトウェア再利用やビルド管理を通じて、一貫性を確保しながら、システムを構築できます。ClearCase
UCMコンポーネントとベースラインを使用することにより、ビルド関連の難題も大幅に軽減されます。
はい。Rational ClearCaseとClearQuestを併用した場合、ClearCase内に保存されている簡易アクティビティーは、ユーザーに非表示になります。ClearCaseダイアログからプロパティ・シートを表示する場合も、ClearQuestのエンティティのみが使用されます。基本的に、ClearQuestデザイナーからのあらゆるタイプのエンティティに対して、UCMを実行できます。UCM環境でClearQuestを使用する際の大きな利点として、異なる状態の多様なタイプを定義し、障害や拡張機能など、様々なデータを収集できるという点があります。
ClearQuestでは、スケジュール済みのアクティビティー、割り当て、状態、ユーザー定義によるフィールド、フォーム、役割、セキュリティが提供されます。ClearCaseでは、すべての新規オブジェクト、UCMインフラストラクチャ、プロジェクト、コンポーネント、ベースライン、変更セット、ストリームなどが提供されます。詳細については、「UCM
for ClearCase Customer」プレゼンテーションをご覧ください。
MAINとは、新規VOBにある1つのブランチ・タイプであり、長期的に、多くのユーザーがMAINブランチにコードを集約することが考えられます。小規模または新規UCM顧客の場合、統合ストリームが主なラインです。さらに、既存のClearCase作業の続行を許可するために、UCMがMAINにとって代わることはありません。UCM
1のMAINブランチへのマージは、ベースClearCase findmergeオプションによって、UCMのコンテキスト外で実行されます。
undoには様々なレベルがあります。UCM 1の場合、デリバー中に変更のデリバーを中止したり、統合ストリームへのチェックイン前にデリバーを中止できます。UCMの初回リリースの場合、ベースラインに組み込まれた変更は、UCMを介して削除することはできません。ただし、"Remove
change set X"という新規アクティビティーを作成し、減法マージを用いて新規バージョンを作成すれば、旧バージョンを削除できます。その後、この変更をデリバー/ベースライン化します。
UCMプロジェクト・ポリシーで、デリバー中のチェックアウトを許可することができます。このような動作を許可するか否かについては、プロジェクト・リーダが決定し、本ポリシーを設定できます。
リベースの実行中はチェックアウトできません（リベースの中止操作をサポートしやすくするため）。チェックアウトを許可するには、すべてのチェックアウト済みファイルをUCMに保存する必要が生じます（一部のファイルにリベースによる影響が及ぶ場合、マージが必要となるため）。将来的なリリースでは、このような機能が提供されることも考えられますが、UCMの現行リリースでは、リベースの実行中、開発ストリームでチェックアウトを実行することはできません。
ベースClearCase内のラベル数や属性数と同様、ベースライン数の多少による不備はありません。
同じストリーム内で作業している場合にのみ、2人の開発者が同じアクティビティーに対して作業を行うことができます。
"unjoin"操作はありません。ユーザーは、自身のビューと開発ストリームを削除できます。
リベース操作では、プロジェクトの推奨ポリシー要件に適合している最新のベースラインが推奨されます。
リベース操作では、常にベースラインにリベースされます。
いいえ。ClearCaseには、ストリーム間で特定のアクティビティーを移動させるための自動化機能は備わっていません。ストリーム間のアクティビティー移動は、追加マージを用いて、手動で行います。
いいえ。UCM ストリームで行われた変更は、1つのアクティビティーに関連付けられます。UCMでClearQuestが有効になっている場合、関係（すなわち、親/子）を作成して、1つのアクティビティーの変更セットに対して、複数のリファレンスを確立することができますが、変更セットそのものは単一のアクティビティーに関連付けられます。
はい。1つのストリームには、0〜n個のビューを割り当てることができます。"プロジェクトに参加"
ウイザードにおいて、開発ストリームと開発ビューが作成されます。ユーザーによってストリームまたはビューの一方の名前が設定された場合を除き、ストリームとビューには同じ名前が付けられます。さらに、各開発者には、最低1つの統合ビューがプロジェクトの統合ストリームに割り当てられます。
プロジェクトでClearQuestが有効化されている場合でも、UCMの変更セット情報は、すべてClearCase内に保存されます。ClearQuestでは、ClearCaseビューを介してアクティビティーを参照することにより、変更セット情報が表示されます。ビュー・コンテキストが利用できない場合は、ClearCase/ClearQuestの連携により、利用可能なビューが検出されます。適切なClearCaseビューが検出されない場合、変更セット情報がClearQuestに表示されない場合があります。
| 
