2014年3月3日月曜日

[ソフトウェア品質技術]定量的プロジェクト管理ツール(EPM-X, IPF Tools)を使ってみる

◆前回のつづき

 今回は、前回インストールしたものを使ってみることにしました。

 定量的プロジェクト管理ツール(IPF Tools)は、プロジェクトの定量的に管理するためのレポートツールです。定量管理ダッシュボート(ポータル画面)上には、5つの観点で分類されたグラフ一覧が用意されていて、プロジェクト管理に必要な情報を17個のグラフで表現してくれます。
  1. 複数プロジェクトの確認
    【R_M02】複数プロジェクトの進捗確認、【R_M03】複数プロジェクトの健全性確認
  2.  WBS管理・品質管理
    【R_S01】試験計画項目密度、【R_S02】WBS進捗推移、【R_S03】WBS進捗変化、【R_S04】EVM評価(進捗、工数)、【R_S05】ソフトウェア規模推移、【R_S06】試験進捗率、【R_S07】工数の予実、【R_S15】遅延重要タスク抽出
  3. 障害管理
    【R_S08】障害件数変化、【R_S13】障害解決予測、【R_S09】障害原因分析、【R_S10】障害発生密度、【R_S11】障害滞留状況
  4. 課題管理
    【R_S14】長期未解決課題抽出
  5. 要員負荷管理
    【R_S12】負荷状況

◆使ってみた感想

 まず、導入についてですが、IPF Toolsを既存のシステムで導入することは難しいでしょう。そもそも私の組織では、Redmineをプロジェクト管理ツールとして利用していません。バグ管理ツールやバージョン管理ツールとして利用しているので、このツールで必要なデータ(SLOC、工数、進捗率など)が蓄積されていません。(測定可能なメトリクス値なんてぜんぜん考慮して使ってないんですよね。)
 
 特に気になったのが、WBSチケットです。WBSのようにタスクを細分化して、綿密に計画を立てた重量級ウォーターフォール型の開発をしていないのでそんなチケットがありません。あと、TestLinkなどテスト管理ツールをRedmineと連携して使っている場合にテスト進捗の進捗率などを自動的に連携できないと思うので、どう連携していくかがカギとなるでしょう。

 導入するのであれば、新規で導入がベストでしょう。大事なのは、Redmineの使い方を明確にすることです。プロジェクトをどういった構成にして、どんなチケットを追加し、どんな情報をどのタイミングで入力するかなど、すべての利用者が理解していないとうまくいきません。今回の調査で参照したオンラインヘルプには、そういった情報がありませんでした。(もしかすると、他のドキュメントを調べればみつかるかもしれません)

 次に、利用についてですが、プロジェクト管理の知識が豊富な人には便利なツールだと感じました。Redmineのチケット検索で抽出するよりか、プロジェクトの状況をグラフで表示して問題を見つけて指摘した方が断然、説得力があります。

 課題となるのは、グラフの傾向と対策のルール化だと思っています。たとえば、「【R_S08】障害件数変化」で未解決障害が20件を超えたときは、異常として認識しリリース日を延長しなければならない…とかでしょうか。(優秀なプロジェクト管理者やデータサイエンティストならグラフを見ればすぐに異常を検出することができると思いますが、プロジェクトマネジメントの知識が無く、アカデミックな論理思考に弱い私には難しいですね。自動的にグラフを表示して問題点まで指摘してくれた方が私には使える(笑))

◆調べた内容

 各グラフの「目的」、「概要」、「説明」、「できること」について調べました。「できること」以外の項目は、IPF Toolsのヘルプより抜粋したものです。よくわからないときは、定量管理ダッシュボード右上にあるオンラインヘルプを見ることをお勧めします。

◆定量管理ダッシュボード


グラフ名
R_M01】定量管理ダッシュボード
目的
担当プロジェクト状況を俯瞰するグラフです。
概要
担当プロジェクトの中で、選択したプロジェクトを俯瞰します。・・・ダッシュボードに表示されたグラフタイトルを押下することにより、別ウィンドウでグラフを表示します。
説明
表示するグラフは、定量的プロジェクト管理ツールのグラフのいずれかとなります。・・・
できること
あらかじめ設定してある複数のグラフを表示できる。


◆複数プロジェクトの確認

・【R_M02】複数プロジェクトの進捗確認


グラフ名
R_M02】複数プロジェクトの進捗確認
目的
担当プロジェクトの中で、製造進捗、又は工数の乖離幅が大きいプロジェクトを検出します。
概要
担当プロジェクトの中で、製造進捗率(SLOC)により遅れ、又は超過と判断されるプロジェクトの製造進捗率グラフ工数の予実により遅れ、又は超過と判断される工数の予実グラフを同一画面上に表示します。
説明
検出する条件は担当プロジェクトの製造進捗率(SLOC)、又は工数の予実とし、指定された条件により製造進捗率の場合は遅れ、工数の予実の場合は超過率が高い順にグラフの表示を行います。
できること
リスクのある(計画と進捗の差が大きい)プロジェクトを見つけることができる。
コメント
WBSチケットの予定工数を入力して、実工数を入力しないとうまく利用できないグラフだと思う。


・【R_M03】複数プロジェクトの健全性確認


グラフ名
R_M03】複数プロジェクトの健全性確認
目的
担当プロジェクトの状態(健全性)を一覧表示し、リスクの検出に役立てます。
概要
試験工程で担当プロジェクトの健全性を、工数、試験進捗率、障害件数、障害未解決件数について予定と実績の差異により、赤、黄、緑のアイコンで表示します。
説明
差異の判定基準・・・判定基準閾値(健全)%未満:緑色の●、判定基準閾値(健全)%~判定基準閾値(危険)%未満 :黄色の●、判定基準閾値(危険)以上:赤色の●。障害滞留状況の判定基準・・・判定基準閾値(健全)%未満:緑色の●、判定基準閾値(健全)%~判定基準閾値(危険)%未満 :黄色の●、判定基準閾値(危険)以上:赤色の●。・・・障害滞留状況はプロジェクトの中で最も滞留日数の長いもので判定します。
できること
WBSタスクの工数、進捗率、障害未解決件数などの予定の値と実績の値を見て、プロジェクトの健全度を知ることができる。
コメント
障害件数やテスト進捗数などテスト管理ツールを使用している場合、うまく連携ができないので、Redmineのカテゴリーに追加する必要がある。作業終了予定日など計画も詳細に設定する必要がある。


WBS・品質管理

・【R_S01】試験計画項目密度



グラフ名
R_S01】試験計画項目密度
目的
計画された試験項目の密度により試験項目のカバレッジを確認し、作成した試験項目の過不足の判断を行います。
概要
ソース規模(行数)に対する試験項目の密度を表示します。…表示対象のWBSタスクと、ソース規模の集計日をグラフパラメータで指定します。
説明
上限値/下限値が設定されたWBSチケットの子となるWBSチケットでは、親の上限値/下限値を適用し、グラフ上にマーカー線を表示します。
できること
対象のテスト項目タスクのカバレッジ度をヒストグラムで知ることができる。
コメント
密度が上限値を超えるとテスト項目が多すぎるし、下限値だと不足していることになるのか?


・【R_S02】WBS進捗推移


グラフ名
R_S02WBS進捗推移
目的
過去の進捗率から、今後の開発の進み具合を予測し、タスク完了予定日を把握します。
概要
パラメータで指定したWBSタスクの進捗推移を表示します。…グラフ表示期間の終了日に、未来の日付を指定した場合、進捗率の予測線を表示します。…表示対象のWBSタスクの計画値(開始日、終了予定日)と予測日(終了予定日)を一覧で表示します。
説明
進捗率はWBS情報に記録された値の統計(計画工数による加重平均)で算出します。…一覧表示したWBSタスクの状態により背景色で区別します。終了予測日が終了予定日より遅れる場合は対象の赤色、終了予測日が早い場合は青色を配色します。
できること
WBSタスクの進捗率をグラフで見ることができる。


・【R_S03】WBS進捗変化


グラフ名
R_S03WBS進捗変化
目的
最近の進捗率変化分を確認し、進捗上問題の有るタスクの確認を行います。
概要
パラメータで指定したWBSタスクの生産性変化(進捗率の変化)を表示します。
説明
進捗率実績値の折れ線グラフに重ねて、進捗変化分の棒グラフを表示します。…
できること
最近のWBSタスクの進捗率と進捗変化率(変化の大きさ)をグラフで見ることができる。


・【R_S04】EVM評価(進捗、工数)

グラフ名
R_S04EVM評価(進捗、工数)
目的
EVMにより最近の生産価値とコスト(工数)の予実を把握します。
概要
生産価値(EV)工数実績値(AC)と工数計画値(PV)のEVMグラフを描画します。
説明
当グラフではEVMの計算およびグラフ表示において、工数をコストとして使用します。…グラフ表示期間の終了日に、未来の日付を指定した場合、コスト(工数)の予測線を表示します。…グラフ表示時の完成時予測総コスト(EAC)をグラフ上にマーカー線で表示します。
できること
作業の遅れ、開発価値、コストなどを視覚的に把握することができる。
コメント
EVM (Earned Value Management)とは、プロジェクトマネジメントにおいて進捗状況の把握・管理を行う手法の一つだそうだ。これもWBSを使った見積もりが事前に必要である。


・【R_S05】ソフトウェア規模推移


グラフ名
R_S05】ソフトウェア規模推移
目的
ソース規模実績値の推移、及び計画値との対比を行い、製造工程での進捗確認、及び試験工程での品質低下の予兆がないか確認します。
概要
パラメータ指定の期間内で、現在までのソース規模の実績推移、実績変化分、予実割合を週ごとに表示します。
説明
最上位のWBSタスクをパラメータのWBSタスクに初期表示します。実績変化分は、週ごとの増加行数を表示します。
できること
SLOC (source lines of code) を基準にソフトウェア開発の規模の推移を見ることができる。また、ソースコードの規模の予想と実績を対比できる。

・【R_S06】試験進捗率


グラフ名
【R_S06】試験進捗率
目的
タスクごとの試験項目実施状況を「達成率」または「実件数」で確認し、試験の計画及び実施の進捗状況を把握します。 過去n週間の実施分を積み上げ棒グラフで表示し、直近の進捗も把握します。
概要
パラメータで指定した期間内で、週ごとの試験進捗の達成率、または実件数を積み上げ棒グラフで表示します。…グラフ表示期間の終了日に未来の日付を指定した場合、実件数グラフでは期間内にある計画値を表示します。
説明
最上位の親タスクをパラメータのWBSタスクに初期表示します。
できること
テスト工程項目数の指定期間における予定件数と実績件数を比較して見ることができる。

・【R_S07】工数の予実


グラフ名
R_S07】工数の予実
目的
現状の消化工数が計画とどれくらい乖離しているか、完成時の予想工数はどれくらいになるかを把握します。
概要
パラメータで指定した期間内で、工数の予実比較と予想工数を表示します。
説明
過去の工数の予実比較(計画はWBS期間中で線形に配分)を表示します。…グラフ表示期間により、過去分は予定と実績、未来分は予定と実績予測値を表示します。
できること
指定期間内のWBSタスクの予実工数と完了時の予想工数を予測することができる。

・【R_S15】遅延重要タスク抽出


グラフ名
R_S15】遅延重要タスク抽出
目的
予測遅延日数の大きなWBSタスクを抽出することにより、対策が必要なWBSタスクの確認を行います。
概要
WBSタスクの進捗率を基に遅延予測を行い、その予測遅延日数を表示します。
説明
WBSの開始日からの進捗変化から生産性を算出し、WBSタスクごとに予測遅延日数を算出します。…WBSの階層は考慮せず、遅れが予測されるタスクを全て表示します。
できること
予想よりも遅れている開発のタスクを見ることができる。


◆障害管理

・【R_S08】障害件数変化


グラフ名
R_S08】障害件数変化
目的
障害の発生件数、未解決件数の推移の把握、及び計画件数との対比などを行います。また、重要度別の障害発生状況、解決状況を把握します。
概要
障害の件数、未解決件数の推移を、重要度(例:軽微、中度、重大など)別の件数も含めて表示します。
説明
この機能は、3つのグラフから構成されている。
(1)    環境件数の変化
(2)    障害の内訳
(3)    未解決障害
できること
障害チケットを重要度別に週次の件数推移を把握することができる
コメント
「予定障害件数は(想定バグ密度(件数/KSLOC)×ソース規模実績値(KSLOC))で算出し、WBSタスクの予定期間内で線形に配分する。」となっている。具体的にどの数値を利用しているかだが、障害にひもづく「WBSチケット」に「SLOC計画値」というものがある。どうやらこれを基に算出しているらしいが、SLOCってどうやって計画値をだすのか非常に疑問である。


・【R_S13】障害解決予測


グラフ名
R_S13】障害解決予測
目的
WBSのタスクごとに、障害の未解決数と解決生産性から解決完了日を推定します。
概要
R_S08:障害件数変化」の子グラフですが、ナビゲーションエリアから単独での表示も可能です。
説明
製造工程、試験工程のWBSタスクで、最上位の親タスクをパラメータのWBSタスクに初期表示します。・・・進捗率(%) = (障害解決予測数/障害発生数)障害解決予測数 = (障害解決数+解決生産性)・・・過去の実績値は表示せず、現在日付の週から予測線のみを重要度別に表示します。
できること
発生している障害数に対して週ごとにどれだけ解決できるかを予測できる。
コメント
過去の障害解決履歴を基に障害解決数を求めてグラフに表示しているらしい。グラフの線は重要度ごとに表示される。100%に達した時点で対象の障害はすべて解決済みであることが前提だろう。達成率って担当者によってあいまいになるのでうちでは終了時に100%にすることしか共通ルールになっていない。

    ・【R_S09】障害原因分析



    グラフ名
    R_S09】障害原因分析
    目的
    現在の障害件数を原因別に分類し障害原因傾向を把握します。
    概要
    障害原因ごとの解決数と未解決数を表示します。表示対象のWBSタスクをグラフパラメータで指定します。
    説明
    ・・・障害原因ごとに、解決・未解決を積み上げ棒グラフで表示します。・・・
    できること
    障害数と障害の原因を把握することができる。
    コメント
    バグのチケットに原因分類のフィールドを追加して、その分類ごとに縦棒グラフを表示しているらしい。縦棒グラフを解決、未解決でカウントして表示している。階層化されたWBSカテゴリーのチケットが完了か(解決?終了?)未完了かで件数を集計してグラフにしているのだろう。


    ・【R_S10】障害発生密度


    グラフ名
    R_S10】障害発生密度
    目的
    予定障害件数に対する障害発生数の達成度により、品質の悪いWBSのタスク(機能及びモジュール)を把握します。
    概要
    パラメータで指定された表示対象のWBSタスクごとにソース規模に対する障害発生密度を表示します。・・・
    説明
    ・・・品質は達成度で判断し、達成度は、製造工程では(障害発生数/予定障害件数)、試験工程では(障害発生数/予定障害件数)×試験消化率、で算出します。
    できること
    品質の悪いタスク(モジュール)が何かを知ることができる。
    コメント
    タスクに対してどれだけのバグが予想されている、実際にどれだけ発生しているかを表すグラフらしいです。ここでも「想定バグ密度」がでてきて、「KSLOC」を算出する必要があるのだがやはり、このような情報は、測定可能なメトリクスとしてきちんと管理した組織でしか利用しなければならない。「タスクの状態が、「完了」のタスクと、「未完了」のタスクを色分けし棒グラフで表示します。」とあるが、対象のWBSチケットのステータスを「終了」にしてもグラフが反映されていないようだ。もしかすると子チケットが終了してないので終了とみなさないしくみなのかもしれない。WBSタスクに設定されており障害のチケットも終了してみたか結果の反映されなかった。どうなっているのだろうか?


    ・【R_S11】障害滞留状況

    グラフ名
    R_S11】障害滞留状況
    目的
    長期間解決されていない障害を把握します。
    概要
    WBSタスクごとに現在まで解決されていない障害件数を、滞留期間に分けて重要度別に表示します。表示対象のWBSタスクをグラフパラメータで指定します。
    説明
    障害が滞留している時間の区分け(例: 3日以上、1週間以上、1ヵ月以上、3ヵ月以上、それ以上などの期間帯)を決め、それぞれに属する障害を重要度別に色分けして表示します。
    できること
    WBSタスクの内、長期間解決されていない障害タスクを見ることができる。
    コメント
    障害チケットの中から、指定期間、終了しないで放置しておいたものをグラフで表示する。


    ◆課題管理

    ・【R_S14】長期未解決課題抽出



    グラフ名
    R_S14】長期未解決課題抽出
    目的
    長期間解決されていない課題を抽出します。
    概要
    パラメータで指定された期間を超えて未解決状態の課題を重要度別に表示します。
    説明
    課題が滞留している期間の区分け(例: 3日以上、1週間以上、1ヵ月以上、3ヵ月以上、それ以上などの期間帯)を決め、それぞれに属する課題を重要度別に色分けして表示します。・・・滞留している時間を算出する起算日は、発生日からとするか、対応完了予定日とするかはIPFDBのグラフ用情報データ集計時に変更できます。
    できること
    WBSタスクの内、長期間解決されていない課題を見ることができる。
    コメント
    課題チケット単体で見ることができない、あくまでもWBSタスク単位でチケットの重要度と件数が表示できるようだ。たとえば、テスト工程のチケットをひとまとまりのWBSタスクにした場合、テスト工程で放置されているチケットや遅延しているチケットが何件あるかを見ることができる。


    ◆要員負荷管理

    ・【R_S12】負荷状況


    グラフ名
    R_S12】負荷状況
    目的
    開発者の負荷を把握します。・・・指定期間内の作業時間が一定値(例:週40時間)を超えるか否かを表示します。
    概要
    パラメータで指定した期間内で、開発者の負荷比較を行います。・・・集計期間(開始日、終了日)、稼働時間閾値、表示種別、開発者名をグラフパラメータで指定します。
    説明
    初期表示はパラメータで指定した期間内の最上位のグループ、または開発者の累計稼働時間を表示します。
    できること
    担当者の誰に負荷がかかっているかを見ることができる。
    コメント
    作業時間数と担当者をきちんと入力する必要がある。あと、途中で担当者が変わる場合、作業時間の集計がうまくいかなくなるのでは?

    0 件のコメント:

    コメントを投稿