作業とビルドのトラッキング

これらのトピックでは、ベースラインとビルド レコードを作成する方法、アクティビティ、タスク、要求のトラッキングと完了の方法について説明します。

プロジェクトのレコード タイプは、実際の製品リリースの生産のトラッキングに使用することができます。プロジェクトには、製品名、リリース情報、プロジェクトに関連付けられたすべての反復のセットが含まれます。また、プロジェクトのコンポーネント情報も含むことがあります。

ソース コードが修正されるごとに、アプリケーションのビルドおよび検証が行なわれ、テストを開始できる品質にされます。ビルドの検証が行なわれるとすぐに、テストのためのテスト サーバーにデプロイされます。ソース コードの変更のデリバー、アプリケーションのビルド、およびテストのパターンは、リリースの範囲や大きさ (たとえば、既存のアプリケーションの抜本的な改訂であるか、パッチやホットフィックスであるか) にかかわらず実施されます。エラーが検出されると、障害がログに記録され、ソース コードが修正されて障害は修正されます。アプリケーションは再びビルドされ、テストのためにテスト サーバーに戻してデプロイされる必要があります。

ALM ベースラインビルドのレコードは、IBM® Rational® ClearCase/ClearQuest Unified Change Management (UCM) 統合を使用するプロジェクトでもそうでないプロジェクトでも使用することができます。ベースラインとビルドのレコードはプロジェクト、製品リリース、または顧客へ情報を確実に配信するために使用することもできます。たとえば、ベースラインとビルドのレコードは、情報を「開発」から「テスト」へ自動転送し、テスト担当者にどの製品ビルドに個別の要求に対するフィックスが含まれているかを通知することができます。

ALM スキーマは、反復型の並行開発とテストが行なわれるワークフロー モデルをサポートします。変更はビルドされ、次のようにテストが行なわれます。

このパターンでは、すべてのアクティビティが関連しています。開発者が機能性をインプリメントして障害を修正しているときに、リリース エンジニアはビルドに組み込むソースが何で、いつビルドを実施するか (つまり、予想される作業がいつ完了するか) を知っておく必要があります。ビルドで問題が発生すると、リリース エンジニアは、問題の原因がビルド スクリプトそのものにあるのか、開発チームが原因のエラーであるかを特定する必要があります。同時に、テスト担当者はテストに適したビルドができる時期、そのビルドに含まれる機能、ビルドに対して実行するテストについて知る必要があります。障害が報告されるたびに、元の要求を振り返って参照すると同時に、障害を明らかにするために使用されるテスト ケースについて知る必要があります。そして、開発者が障害を修正してコードをデリバーすると、再びこのサイクルが開始されます。

ソフトウェア開発プロジェクトでは、定期的にビルドが発生します。開発チームにとって共通の問いは、ビルドにインプリメントされるものが何で、ビルドでテストされるのは何かということです。ビルド レコードによって、チームがそれぞれのビルドに関する情報とその状態について収集することができます。ベースライン レコードによって、それぞれのビルドでデリバーされたアクティビティが何であるかトラッキングすることができ、またこれを使用して所定の時点でのアクティビティの状態を収集することができます。ベースライン、ビルド、アクティビティのレコードを使用することで、テスト担当者は、何をテストし、どのテストがビルドに対して実行されているかをトラッキングすることができます。

関連概念
概説
プロジェクトの操作
作業管理
サンプル データ
ALM レコード タイプの必須フィールド
関連タスク
管理者の概要

フィードバック