TOPプロジェクト管理> 5 作業担当者による不具合の修正
StarTeam
Borland StarTeamによる構成管理

第3回:障害対応時の変更要求ワークフロー
著者:ボーランド  富山 義明   2006/1/23
前のページ  1  2  3  4
5 作業担当者による不具合の修正

   引き続き「DDeveloper」ユーザで作業を続けます。不具合を修正するために、いくつかのファイルをチェックアウトして修正を行います。後から修正内容がわかるように、変更要求アイテムに解決方法についての記述を行います。
変更要求アイテムに解決方法についての記述
図9:変更要求アイテムに解決方法についての記述

   記述したら修正した複数のファイルをチェックインします。チェックイン時のダイアログにおいて、「処理アイテムをリンクおよび固定する」をチェックし、さらに「選択した処理アイテムを解決/終了/完了としてマークする」にチェックを入れます。

「チェックイン」確認
図10:「チェックイン」確認
(画像をクリックすると別ウィンドウに拡大図を表示します)

   アクティブ処理アイテムとして設定していた変更要求アイテムのステータスが「解決」状態になり、さらにこのチェックイン操作の対象となった複数のファイルと変更要求アイテムの間にリンクが張られるようになります。

リンクが張られていることの確認
図11:リンクが張られていることの確認
(画像をクリックすると別ウィンドウに拡大図を表示します)

   このことを確認するには、右上ペインで「変更要求」タブを選択し、メニューから「ウィンドウ → 更新」を選びます。そして、右上ペインで先ほどの変更要求アイテムを選択した状態で、右下ペインで「リンク」タブを選択します。図11のように変更要求アイテムのステータスが更新され、変更要求アイテムとファイルアイテムの間にリンクが張られていることがわかります。

※注4: ここではチェックイン操作と同時にリンクを作成する方法を紹介しましたが、StarTeamではメニューからの操作でリンクを作成することも可能です。

   終わったらメニューから「プロジェクト → 終了」を選択し、クロスプラットフォームクライアントを終了します。


6 テスト担当者による不具合の修正の検証

   クロスプラットフォームクライアントを使い、「StarDraw」プロジェクトに対して「TTester」ユーザでログインします。右上ペインで「変更要求」タブを選択すると、自分に割り当てられた変更要求が太字で表示されているのがわかります。アイテムを開けてみると図12のようになっています。

アイテムの内容
図12:アイテムの内容

   テスト担当者が最新版のファイルを自分の環境にチェックアウトして確認作業を行い、この不具合が修正されていることが確認できたら「ステータス」を「解決」から「検証終了(解決)」に更新します。

※注5: ここで担当者が「TTester」になっているのかについて補足説明をします。これはStarTeam上に定義されているデフォルトのワークフローが動いたからです。デフォルトのワークフローでは、変更要求アイテムのステータスが「解決」になった場合に、自動的に「担当者」をそのアイテムを最初に作成した人に設定します。

   今回の例では、最初に変更要求アイテムを作成したのが「TTester」ユーザだったので、「DDeveloper」がステータスを「解決」にした時点で「担当者」として「TTester」が割り当てられました。これはデフォルトのワークフローの動きですので、ワークフローのカスタマイズを行えば、この動きを変えることも可能です。

   終わったら、メニューから「プロジェクト → 終了」を選択し、クロスプラットフォームクライアントを終了します。


7 プロジェクト管理者による変更要求のクローズ

   クロスプラットフォームクライアントを使い、「StarDraw」プロジェクトに対して「MManager」ユーザでログインします。右上ペインで「変更要求」タブを選択し、当該変更要求のステータスを「検証終了(解決)」から「対応完了(解決)」に更新します。変更したらメニューから「プロジェクト → 終了」を選択し、クロスプラットフォームクライアントを終了します。


8 ビルド管理者によるラベルの付加

   クロスプラットフォームクライアントを使い、「StarDraw」プロジェクトに対して「MManager」ユーザでログインします。メニューから「ビュー → ラベル」を選択して「ラベル」ダイアログを開き、この画面で新しいビューラベル「Build 9」を[ビルドラベル]として作成します。すると、先ほど対応完了になった変更要求アイテムの中の、「以下のビルドで対応」の部分に、「Build 9」が設定されます。

変更要求のビルドの変更
図13:変更要求のビルドの変更

   これでこの変更要求アイテムがどのビルドで発見され、どのビルドで修正されたかという情報が記録されたわけです。

   今回紹介した障害対応のフローはStarTeamの機能としては基本的なものですが、実際のプロジェクトにおいて十分効果を発揮するものです。これは、StarTeamが単なるファイルのバージョン管理と障害管理を足しあわせたものではなく、その間の密な関係を維持するシステムになっていることをあらわしています。

前のページ  1  2  3  4


ボーランド株式会社 富山 義明
著者プロフィール
ボーランド株式会社  富山 義明
プロダクトビジネス本部 プロダクト・マネージャ
東京大学大学院理学系専攻科博士課程中退、理学修士。1992年日立CE(現日立IT)入社後、セキュリティビジネスセンタ長等を経て、2000年外資系企業へ。2003年、ボーランドに入社し、その後、アプリケーション開発の管理系製品の説明で国内を飛び回っている。


INDEX
第3回:障害対応時の変更要求ワークフロー
  はじめに
  障害対応時の作業フロー
  3 プロジェクト管理者による作業担当者の割り当て
5 作業担当者による不具合の修正