JP6333160B2 - プロジェクト評価装置及びプロジェクト評価方法及びプロジェクト評価プログラム - Google Patents

Description

本発明は、プロジェクト評価装置及びプロジェクト評価方法及びプロジェクト評価プログラムに関するものである。

ソフトウェア開発プロジェクトには、高品質、低コスト、短納期が求められる。しかし、ソフトウェア開発プロジェクトは、近年、大規模化、複雑化している。ソフトウェア開発では、最終製品が開発の途中段階では見えにくく、多くが人のスキルに依存した作業になる。設計レビューの強化、試験項目数の増加により品質が向上することが期待できるが、作業量の増加が必要になり、その結果、担当者の作業時間が増加して担当者雇用のコストが増加したり、開発期間が長期化したりする。コストを抑えるため、設計の検討時間の短縮化、レビューや試験項目数の削減を安易に行えば、設計検討不足やコーディングミスによる障害が多くなり、品質が低下する。また、試験時の障害検出により修正時間が増加するか、又は、障害を残したまま製品が市場に出てリコールが発生し、リコールの対処に多大な費用が必要になると、結果的にコストが高くなる。したがって、ソフトウェア開発プロジェクトでは、ＱＣＤ（品質、コスト、納期）のバランスをとることが重要である。ソフトウェア開発プロジェクト以外のプロジェクトについても同様である。

従来、ＱＣＤのうち、コストに着目してプロジェクトの生産性を評価する技術がある（例えば、特許文献１参照）。この従来の技術では、プロジェクトで生成された成果物の規模と、プロジェクトに投入されたリソースから、オペレーションズリサーチ技術の１つである包絡分析法（ＤＥＡ）による効率値をプロジェクトごとに算出することで、プロジェクトの生産性を評価する。ここで、成果物とは、設計書の頁数やソースコードのライン数等のことである。リソースとは、担当者の作業時間のことである。

特開２０１１−２１５９２７号公報

ソフトウェア開発プロジェクトのように、大部分の作業がコーディング等の手作業であり、人の思考に大きく依存するプロジェクトでは、どのような状況で、どのような作業をしたかを考慮して評価を行わなければ、ＱＣＤが悪かった場合の原因を特定したり、問題となる作業を改善したりすることができない。しかし、従来の技術では、どのような状況で、どのような作業をしたかを考慮していない。即ち、従来の技術では、プロジェクトに従事する者の行動を考慮した評価を行っていない。また、従来の技術では、ＱＣＤのバランスを考慮した評価も行っていない。

本発明は、プロジェクトに従事する者の行動を考慮した評価結果を得ることを目的とする。

本発明の一の態様に係るプロジェクト評価装置は、
ソフトウェアを開発する複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の情報である従事者情報を記憶するデータベースと、
前記複数のプロジェクトのそれぞれについて、前記データベースに記憶された従事者情報に基づき、プロジェクトに従事する者の行動を模擬するシミュレータと、
前記シミュレータによる模擬の結果から、前記複数のプロジェクトを評価する評価部とを備える。

本発明では、シミュレータが、複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の行動を模擬し、評価部が、その模擬の結果から、複数のプロジェクトを評価する。このため、本発明によれば、プロジェクトに従事する者の行動を考慮した評価結果を得ることができる。

実施の形態１に係るプロジェクト評価装置の構成を示すブロック図。 実施の形態１に係るシミュレータの構成を示すブロック図。 実施の形態１に係るプロジェクト評価装置の動作を示すフローチャート。 実施の形態１に係るシミュレータの設定値の例を示す表。 実施の形態１に係る模擬結果のデータ形式の例を示す表。 １入力２出力の場合のＤＥＡの効率値のプロット例を示すグラフ。 実施の形態１に係る模擬結果と効率値とのデータ形式の例を示す表。 実施の形態１に係る模擬結果に対する分析結果の例を示す表。 実施の形態１に係る修正処理の手順を示すフローチャート。 実施の形態１に係るパラメータ修正表の例。 実施の形態１に係るＱＣＤに対応する予測値とＤＥＡの効率値とをグラフィカルに表示する例を示す図。 実施の形態２に係るプロジェクト評価装置の動作を示すフローチャート。 本発明の実施の形態に係るプロジェクト評価装置のハードウェア構成の例を示す図。

以下、本発明の実施の形態について、図を用いて説明する。なお、各図中、同一又は相当する部分には、同一符号を付している。実施の形態の説明において、同一又は相当する部分については、説明を適宜省略又は簡略化する。

実施の形態１．
まず、本実施の形態の概要を説明する。
（１）本実施の形態では、複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の行動を模擬し、その模擬の結果から、複数のプロジェクトを評価する。即ち、プロジェクトに従事する者の行動を考慮した評価を行う。
（２）本実施の形態では、プロジェクト計画について、シミュレーションによりＱＣＤ（品質、コスト、納期）を統合して定量的に評価を行う。即ち、ＱＣＤのバランスを考慮した評価を行う。
（３）本実施の形態では、プロジェクト計画の評価結果を用いて、シミュレーションの設定内容を修正し、実績データに基づいた模擬結果の評価を行う。
（４）本実施の形態では、プロジェクト計画に基づき、複数の模擬結果を包絡分析法（ＤＥＡ）により評価し、傾向をＱＣＤと効率値との４次元で表示する。

次に、本実施の形態の詳細として、本実施の形態に係る装置の構成、本実施の形態に係る装置の動作、本実施の形態の効果を順番に説明する。

＊＊＊構成の説明＊＊＊
以下では、図１を用いて、本実施の形態に係る装置であるプロジェクト評価装置１００の構成を説明する。

図１に示すように、プロジェクト評価装置１００は、データベース１１０、シミュレータ１２０、評価部１３０、分析部１４０、修正部１５０、出力部１６０を備える。

データベース１１０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトに従事する者の情報である従事者情報を記憶する。ｎは、本実施の形態で評価の対象となるプロジェクトの数を表し、ｎ≧２となる任意の整数である。複数のプロジェクトＰ１〜Ｐｎは、それぞれ何らかの目標を達成するために複数の人間が行動する計画であれば、どのようなプロジェクトであってもよい。本実施の形態では、複数のプロジェクトＰ１〜Ｐｎは、それぞれソフトウェアを開発するプロジェクトである。

シミュレータ１２０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、データベース１１０に記憶された従事者情報に基づき、プロジェクトに従事する者の行動を模擬する。ここで、プロジェクトに従事する者には、プロジェクトの管理者と作業者とが含まれる。本実施の形態では、シミュレータ１２０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトに従事する者の行動として、特に、プロジェクトの管理者が作業者に出す指示を模擬する。

シミュレータ１２０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトに従事する者の行動を模擬することで、プロジェクトで開発されるソフトウェアの障害数と、プロジェクトでソフトウェアの開発にかかる工数と、プロジェクトでソフトウェアの開発が遅延する日数との複数種類の予測値のうち、少なくとも１種類の予測値を算出する。本実施の形態では、シミュレータ１２０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、上記複数種類の予測値を全て算出する。上記複数種類の予測値は、それぞれＱＣＤに対応する。具体的には、障害数は、品質に対応する。障害数が少ないほど、品質が高いことになる。開発にかかる工数は、コストに対応する。工数が少ないほど、コストが低いことになる。開発が遅延する日数は、納期に対応する。日数が少ないほど、納期が短いことになる。納期とは、開発が完了する時期のことである。開発の途中段階で評価を行う場合は、進捗を納期として扱う。即ち、開発が遅延する日数は、進捗にも対応する。日数が少ないほど、進捗が早いことになる。

評価部１３０は、シミュレータ１２０による模擬の結果から、複数のプロジェクトＰ１〜Ｐｎを評価する。具体的には、評価部１３０は、シミュレータ１２０により模擬された行動の回数と、シミュレータ１２０により算出された予測値とから、複数のプロジェクトＰ１〜Ｐｎの効率値を算出することで、複数のプロジェクトＰ１〜Ｐｎを評価する。効率値を算出する方法としては、任意の方法を用いることができる。本実施の形態では、評価部１３０は、シミュレータ１２０により模擬された行動の回数を入力値とし、上記複数種類の予測値を出力値とし、包絡分析法を用いて複数のプロジェクトＰ１〜Ｐｎの効率値を算出する。

分析部１４０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、上記複数種類の予測値と、評価部１３０により算出された効率値との関係を分析する。

修正部１５０は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトの実績に応じて、データベース１１０に記憶された従事者情報を修正する。

出力部１６０は、分析部１４０による分析の結果を出力する。

プロジェクト評価装置１００は、データベース１１０として、プロジェクト計画データベース１１１、実績データベース１１２、模擬結果データベース１１３、分析結果データベース１１４を備える。

プロジェクト計画データベース１１１は、ソフトウェア開発における開発対象、障害検出率、工程、コスト、開発人員等のプロジェクトを実施するために決定した開発計画の情報を保存する。この情報には、前述した従事者情報も含まれる。プロジェクト計画データベース１１１は、プロジェクトの模擬をする際のパラメータや、シミュレータ１２０の初期値設定のデータを提供する。

実績データベース１１２は、ソフトウェアの開発プロジェクトの実行により定期的に収集した実績データを保存する。実績データベース１１２は、模擬やパラメータ修正時に実績データを提供する。実績データベース１１２は、実績データとして、作業者ごとに、ソースコードの作成量や作業時間、レビューや試験で検出された障害数や誤り数等のＱＣＤに関連するデータを保存する。

シミュレータ１２０は、プロジェクト計画データベース１１１に保存された開発計画の情報、実績データベース１１２に保存された実績データの入力を受けて、プロジェクト完了までの状況、完了した状況を模擬し、完了時のプロジェクトの状態を出力する。本実施の形態では、シミュレータ１２０は、プロジェクトの管理者と作業者とをエージェントとして動作させる。シミュレータ１２０は、開発計画の情報から各エージェントの個人設定を行い、各エージェントの動作結果を集計して、プロジェクト完了までの進捗状況、完了時の状態を模擬結果として出力する。

模擬結果データベース１１３は、シミュレータ１２０の模擬結果のデータを保存する。模擬結果データベース１１３は、プロジェクトの評価時、シミュレータ１２０のパラメータ変更処理時にデータを提供する。

評価部１３０は、実績データベース１１２に保存された実績データ又は模擬結果データベース１１３に保存されたシミュレータ１２０の模擬結果についてプロジェクトの評価を行う。本実施の形態では、評価部１３０は、評価対象のマネジメントの効率性を算出することが可能な包絡分析法を用いてプロジェクトの効率値を算出する。それぞれのプロジェクトは、包絡分析法の意思決定主体（Ｄｅｃｉｓｉｏｎ・Ｍａｋｉｎｇ・Ｕｎｉｔ：ＤＭＵ）として捉えられる。評価部１３０は、それぞれのプロジェクトについて、包絡分析法の入力である管理者の指示回数と包絡分析法の出力である障害数、工数、遅延の日数、及び、プロジェクトの外乱因子を用いて効率値を算出する。

分析部１４０は、評価部１３０による効率値の算出結果を統計処理により分析し、分析結果のデータを出力する。本実施の形態では、包絡分析法が利用されるため、入力値と出力値と効率値との組み合わせでデータが作成される。分析部１４０は、入力値と出力値と効率値との関係やシミュレータ１２０の入力値と出力値との関連等の分析を行う。

分析結果データベース１１４は、分析部１４０から出力された分析結果を保存する。分析結果データベース１１４は、シミュレータ１２０のパラメータの修正や結果表示のため、必要なデータを出力する。

修正部１５０は、プロジェクト計画データベース１１１に保存された開発計画の情報、実績データベース１１２に保存された実績データ、分析結果データベース１１４に保存された分析結果を用いて、シミュレータ１２０に設定されたパラメータを評価し、評価結果からパラメータを修正する。修正部１５０は、修正後のパラメータをシミュレータ１２０に入力する。

出力部１６０は、分析結果データベース１１４に保存された分析結果を表示する。同時に、出力部１６０は、プロジェクト計画データベース１１１に保存された開発計画の情報が示す計画値、実績データベース１１２に保存された実績データが示す実績値、模擬結果データベース１１３に保存されたシミュレータ１２０の模擬結果を表示する。

以下では、図２を用いて、シミュレータ１２０の構成を説明する。

本実施の形態では、ソフトウェア開発プロジェクトのプログラム作成工程の模擬を実行するシミュレータ１２０を用いて、プロジェクトの評価を行う。シミュレータ１２０は、プロジェクトの管理者と開発を担当する作業者との模擬を行う。

図２に示すように、シミュレータ１２０は、模擬実行部１２１、プロジェクト状況データベース１２２、イベントルール群データベース１２３、イベント発火制御部１２４、管理者模擬エージェント部１２５、データ入出力部１２６を備える。

模擬実行部１２１は、模擬を実行する。模擬実行部１２１は、模擬において、定義された作業者エージェントが日々作成するプログラムのライン数と障害数とを算出する。模擬実行部１２１は、計画された総ライン数まで模擬を実施する。

プロジェクト状況データベース１２２は、プロジェクトの進捗状況として、模擬実行部１２１が算出したライン数と障害数とを記憶する。

イベントルール群データベース１２３は、実際のプロジェクトと同様に発生する外乱として、障害発生数増減イベント、作業効率低下イベント、仕様変更イベントの定義情報を記憶する。障害発生数増減イベントは、エージェントとして動作する作業者が作成するプログラムに発生する障害の数が増加又は減少するイベントである。作業効率低下イベントは、エージェントとして動作する作業者の作業効率が低下し、作業者が作成するプログラムのライン数が減少するイベントである。仕様変更イベントは、エージェントとして動作する作業者が作成するプログラムの仕様が変更になり、総ライン数が増加又は減少するイベントである。

イベント発火制御部１２４は、イベントルール群データベース１２３に定義情報が記憶されたイベントを選択し、選択したイベントを模擬実行部１２１に通知する。

管理者模擬エージェント部１２５は、作業者エージェントへ指示を行う管理者エージェントを動作させる。管理者模擬エージェント部１２５は、プロジェクト状況データベース１２２に記憶されているプロジェクトの進捗状況から、作業が遅れていると判断すると、残業指示を行う。残業指示とは、計画された工数よりも多い工数の作業を行うように指示することである。管理者模擬エージェント部１２５は、残業指示の実際の処理としては、模擬実行部１２１内の作業者エージェントの作業効率を、より低い値に変更する。

データ入出力部１２６は、プロジェクト状況データベース１２２に記憶されたプロジェクトの最終的な進捗状況を、模擬結果のデータとして模擬結果データベース１１３に送信し、登録する。また、データ入出力部１２６は、プロジェクト計画データベース１１１に保存された開発計画の情報、実績データベース１１２に保存された実績データの入力を受ける。入力値には、イベント発火や管理者指示を決定するための設定値が含まれている。データ入出力部１２６は、その設定値を用いて、模擬実行部１２１、イベント発火制御部１２４、管理者模擬エージェント部１２５のパラメータを設定したり、変更したりする。

＊＊＊動作の説明＊＊＊
以下では、図３〜１１を用いて、プロジェクト評価装置１００の動作を説明する。プロジェクト評価装置１００の動作は、本実施の形態に係るプロジェクト評価方法に相当する。プロジェクト評価装置１００の動作は、本実施の形態に係るプロジェクト評価プログラムの処理手順に相当する。

図３のＳ００１が実行される前に、プロジェクト計画が立案され、プロジェクト計画のデータがプロジェクト計画データベース１１１に記憶されているものとする。

図３のＳ００１〜Ｓ００４は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトに従事する者の情報である従事者情報をデータベース１１０から取得し、取得した従事者情報に基づき、プロジェクトに従事する者の行動を模擬するシミュレーションである。

Ｓ００１において、プロジェクト計画データベース１１１に記憶されている計画値がシミュレータ１２０に設定される。シミュレータ１２０には、プログラム作成工程に必要なデータが設定される。

図４に、シミュレータ１２０の設定値の例を示す。

図４の例では、シミュレータ１２０の設定値の項目として、「開発ライン数」のように数値で明確に示される計画値と、「要員スキル」や「管理者特性」のように模擬でのエージェントの動作特性を決定する定性的、主観的で定量値として定義できない模擬パラメータとが定義される。

シミュレータ１２０に用いる計画値としては、「要員数」、「管理者経験回数」、「開発ライン数」、「開発工数」、「期間」、「障害予定数」が定義される。「要員数」は、プロジェクトに従事する作業者の数である。「管理者経験回数」は、プロジェクトに従事する管理者の過去のプロジェクト経験回数である。「開発ライン数」は、プロジェクトで作成されるプログラムのライン数である。「開発工数」は、プロジェクトでプログラムの作成にかかる工数である。「期間」は、プロジェクトでプログラムの作成に要する日数である。「障害予定数」は、プロジェクトで作成されるプログラムから検出される障害の数である。「要員数」、「管理者経験回数」は、従事者情報の例である。

シミュレータ１２０に用いる模擬パラメータとしては、「開発方式」、「要員スキル」、「管理者特性」、「プログラム難易度」が定義される。「開発方式」としては、流用開発と新規開発とが想定され、新規開発は１、流用開発は２で示される。「要員スキル」は、作業員のプログラミング経験、開発工事の経験を考慮し、５段階として、最も低いスキルが１、最も高いスキルが５で示される。「管理者特性」は、シミュレータ１２０内で指示の回数及びタイミングを模擬するためのパラメータであり、規範型、オペレーション遅れ型、場当たり型とし、順に１、２、３で示される。それぞれの型について管理者エージェントが指示を出す基準等がシミュレータ１２０内のイベントルール群データベース１２３に定義され、イベント発火制御部１２４により参照される。「プログラム難易度」は、計画時に開発対象や機能等から３段階で設定され、１が平易、２が標準、３が難を示す。「要員スキル」、「管理者特性」は、従事者情報の例である。

Ｓ００２において、シミュレータ１２０は、計画値に基づき、模擬を実行する。シミュレータ１２０は、設定された模擬パラメータに従い、計画された開発ライン数を達成するまでの作業時間から作業工数、作り込んだプログラムの障害数を算出する。作業工数は、コスト（Ｃ）に対応する。障害数は、品質（Ｑ）に対応する。シミュレータ１２０は、各エージェントの１日の作業時間から作業完了までの日数を計算し、納期遅れの日数を算出する。日数は、進捗（Ｄ）に対応する。シミュレータ１２０内では、進捗に応じて管理者エージェントが残業指示を行う。シミュレータ１２０には、プロジェクトの進捗を妨げる外乱因子がイベントとして設定され、確率的に発生させられる。イベントルール群データベース１２３には、イベントとして、障害発生数増減イベント、残業指示により作業員の作業効率が低下する作業効率低下イベント、仕様変更によりプログラムのライン数が増減する仕様変更イベントが用意される。イベント発火制御部１２４は、プロジェクト状況データベース１２２に記憶された進捗状況に基づき、確率的にイベントを発生させ、プロジェクトの進捗に影響を与える。

Ｓ００３において、シミュレータ１２０は、模擬結果を模擬結果データベース１１３に保存する。結果は、入力値と出力値とのペアで保存される。

図５に、模擬結果のデータ形式の例を示す。

図５の例において、「入力値」は、管理者エージェントの残業指示回数である。「出力値１」は、計画ライン数作成完了時の障害数である。「出力値２」は、計画ライン数作成完了までの全作業員の作業時間、即ち、作業工数である。「出力値３」は、計画ライン数作成完了時の計画日数から超過した日数である。「出力値４」は、外乱イベントの発生回数である。

Ｓ００４において、シミュレータ１２０は、１度の模擬結果を保存した後、模擬を継続するかを判断する。継続する場合、フローはＳ００２に戻る。そして、シミュレータ１２０が、模擬を初期状態から実行する。シミュレータ１２０による模擬は、確率的に管理者の指示や外乱を発生させる。そのため、傾向を分析するためにも、模擬を複数回実施し、模擬結果のデータを作成及び保存することが望ましい。模擬を実施する回数は、予め任意の数に指定されているものとする。指定回数の模擬が実行された場合、フローはＳ００５に進む。

図３のＳ００５は、Ｓ００１〜Ｓ００４のシミュレーションによる模擬の結果から、複数のプロジェクトＰ１〜Ｐｎを評価する評価処理である。

Ｓ００５において、評価部１３０は、模擬結果データベース１１３から入力値と出力値とからなるデータセット単位で評価を行う。評価部１３０は、ＤＥＡを用いて評価処理を行い、各データセットについて効率値を算出する。具体的には、評価部１３０は、模擬結果の逆数をＤＥＡの評価式に入力し、ＤＥＡでの効率値を算出する。ここで、ＤＥＡは、複数のＤＭＵの効率性を相対的に比較する分析方法である。ＤＥＡは、ＤＭＵの多入力多出力に対応し、入力値に対する出力値の割合を効率値として表現する。ＤＥＡで得られた効率値を比較することで複数のＤＭＵの評価を行うことができる。

ＤＥＡの評価式としては、任意の数式を用いることができる。本実施の形態では、以下のＣＣＲ（チャーンズ・クーパー・ローズ）モデルの評価式を用いる。

ｎ：ＤＭＵの個数
ｓ：ＤＥＡの出力項目数
ｍ：ＤＥＡの入力項目数
ｙ_ｒｊ：ｊ番目のＤＭＵにより使用されるｒ番目の出力値
ｘ_ｉｊ：ｊ番目のＤＭＵにより使用されるｉ番目の入力値
ｕ_ｒ：特定ＤＭＵに対するｒ番目の出力値への重み付けベクトル
ｖ_ｉ：特定ＤＭＵに対するｉ番目の入力値への重み付けベクトル
ｚ_ｊ：ｊ番目のＤＭＵの効率値

上記の評価式において、シミュレータ１２０により模擬されたプロジェクトＰｊの管理者の指示の回数が入力値ｘ_１ｊとなる。シミュレータ１２０により算出された、プロジェクトＰｊで開発されるソフトウェアの障害数の予測値、プロジェクトＰｊでソフトウェアの開発にかかる工数の予測値、プロジェクトＰｊでソフトウェアの開発が遅延する日数の予測値、及び、シミュレータ１２０によりイベントが発生させられた回数が出力値ｙ_１ｊ〜ｙ_４ｊとなる。そして、プロジェクトＰｊの出力値ｙ_１ｊ〜ｙ_４ｊのそれぞれに可変の係数である重み付けベクトルを掛けて、総和の最大値である効率値ｚ_ｊが求められる。それぞれの係数の値は、ＤＭＵごとに、効率値ｚ_ｊが最大となるように決定される。効率値ｚ_ｊが１の場合、ｊ番目のＤＭＵであるプロジェクトＰｊは効率的フロンティアということになり、効率値ｚ_ｊが１未満の場合、プロジェクトＰｊは非効率的フロンティアということになる。

図６に、入力値が１つ、出力値が２つの場合のＤＥＡの効率値をグラフにプロットした例を示す。このグラフは、２次元のグラフとなる。

図６の例において、Ａ〜Ｇの円は、ＤＭＵを示している。グラフの外側の実線上にあるＤＭＵは、入力値、出力値１，２のバランスの取り方によって効率値が最大になるＤＭＵであり、効率的フロンティアと定義される。例えば、Ａで示されるＤＭＵは、出力値１に対して出力値２の比率が高く、その比率において最も効率の良い効率的フロンティアのＤＭＵである。破線の矢印上にあるＤＭＵは、矢印の方向について効率的フロンティアより効率が悪いＤＭＵであり、非効率フロンティアと定義される。例えば、Ｅで示されるＤＭＵは、破線の矢印の方向について効率値が効率的フロンティアの７０％である非効率フロンティアのＤＭＵである。入力値、出力値の数に応じた次元数のベクトルとして効率値という同一尺度でＤＭＵを相対的に評価することが可能である。本実施の形態では、評価部１３０が、模擬結果データベース１１３から得られる模擬結果についてＤＥＡの効率値を前述した評価式を用いて算出し、プロジェクトを相対的に評価する。評価部１３０は、算出した効率値を模擬結果データベース１１３に追加保存する。図７には、図５の例と同じ模擬結果と、その模擬結果に対する効率値とのデータ形式の例を示している。

図３のＳ００６及びＳ００７は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、Ｓ００１〜Ｓ００４のシミュレーションにより算出された複数種類の予測値と、Ｓ００５の評価処理により算出された効率値との関係を分析する分析処理である。

Ｓ００６において、分析部１４０は、各模擬結果の効率値を用いて、プロジェクトの分析を行う。本実施の形態では、分析部１４０は、重回帰分析を実施し、効率値算出モデルを作成する。外乱となるイベントの発生、管理者の指示のタイミングは、シミュレータ１２０内のパラメータにより確率的に算出される。模擬を複数回実施し、それら複数回の模擬結果から重回帰分析を行うことで、プロジェクトのプログラム作成工程の計画値に対する評価を的確に行うことができる。図８には、図７の例における４回の模擬結果に対する重回帰分析の結果を示している。

Ｓ００７において、分析部１４０は、複数回の模擬結果に対する分析結果を複数回の模擬結果の分析データとして分析結果データベース１１４に保存する。

図３のＳ００８は、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトの実績に応じて、データベース１１０に記憶された従事者情報等を修正する修正処理である。

Ｓ００８において、修正部１５０は、シミュレータ１２０のパラメータの修正を行う。

図９に、具体的な修正処理の手順を示す。

図９のＳ０１０において、修正部１５０は、模擬結果と、模擬結果に対応した効率値とを模擬結果データベース１１３から取得する。Ｓ０１１において、修正部１５０は、Ｓ０１０で取得した模擬結果に対応した分析結果を分析結果データベース１１４から取得する。Ｓ０１２において、修正部１５０は、シミュレータ１２０のパラメータに適用されている計画値と、パラメータ修正表とをプロジェクト計画データベース１１１から取得する。Ｓ０１３において、修正部１５０は、プロジェクトのプログラム作成工程の実績データを実績データベース１１２から取得する。Ｓ０１４において、修正部１５０は、実績データが存在する工程に関連したパラメータの評価を、主にＳ０１０で取得した効率値とＳ０１２で取得したパラメータ修正表とを参照して実施する。修正対象パラメータ及び修正タイミングの条件は、プロジェクト及びシミュレータ１２０に応じて定義され、修正部１５０のパラメータとして設定される。Ｓ０１５において、条件が一致すれば、Ｓ０１６において、修正部１５０は、シミュレータ１２０内の該当するパラメータを修正する。

ここで、「要員スキル」のパラメータ修正表を例に挙げて、Ｓ０１４〜Ｓ０１６の具体的な処理を説明する。図１０には、パラメータ修正表の例を示している。プログラム作成工程の実績データが実績データベース１１２に登録されている場合、修正部１５０は、分析結果のうち効率値の最頻値を求める。修正部１５０は、算出した効率値の最頻値と各作業員の実績データとを参照してパラメータ修正表に一致する条件を調査する。条件に一致した場合には、修正部１５０は、シミュレータ１２０内の作業者エージェントの登録されている「要員スキル」に関するパラメータを修正する。例えば、あるプロジェクトにおいて、「進捗」が計画より２日以上進んでおり、「残業時間」が１週間で１人当たり０時間であり、「検出誤り」が１ページ当たり２件以下であり、かつ、「効率値」が０．９５以上であるとき、現在シミュレータ１２０で用いられている「要員スキル」の値に１が加算される。なお、「検出誤り」は、作成されている設計書等の成果物のレビュー結果から判断される。「検出誤り」には、記述ミス、抜け等がある。「要員スキル」の値に１が加算されるということは、作業能力を良くすると同意することである。

図３のＳ００９は、Ｓ００６及びＳ００７の分析処理による分析の結果を出力する出力処理である。

Ｓ００９において、出力部１６０は、ユーザの要求に応じて、分析結果データベース１１４に保存された分析結果を出力する。本実施の形態では、出力部１６０は、プロジェクトの計画値や特性、効率値の最頻値に近い模擬結果であるＱＣＤの各値を出力する。

図１１に、ＱＣＤに対応する予測値とＤＥＡの効率値とをグラフィカルに表示する例を示す。

図１１の例では、ＱＣＤの各値を３つの軸とした３次元グラフ上に、効率値に対応する球が表示されている。球の位置がＱＣＤの各値、球の大きさが効率値を示す。

＊＊＊効果の説明＊＊＊
本実施の形態では、シミュレータ１２０が、複数のプロジェクトＰ１〜Ｐｎのそれぞれについて、プロジェクトに従事する者の行動を模擬し、評価部１３０が、その模擬の結果から、複数のプロジェクトＰ１〜Ｐｎを評価する。このため、本実施の形態によれば、プロジェクトに従事する者の行動を考慮した評価結果を得ることができる。

本実施の形態では、ソフトウェア開発プロジェクトの計画値からプロジェクトの模擬を行い、包絡分析法等の手法でＱＣＤの３項目のデータ分析をすることで、属人的なプロジェクトを客観的に評価することができる。よって、プロジェクトの管理者の経験や技能に頼らず、定量的な評価を行うことができる。即ち、従来は主観的、経験則的であったプロジェクトの評価を、シミュレータ１２０とＤＥＡに代表されるような多入力多出力の分析が可能な評価方法を組み合わせることで、品質、コスト、進捗の３つの視点を統合してかつ定量的に行うことが可能になる。

本実施の形態では、シミュレータ１２０が、プロジェクトの計画や実績データを基に、プロジェクトの進捗や障害発生等の品質を模擬し、その模擬の結果が、評価部１３０に入力され、評価部１３０が、模擬の結果や実績データを評価する。そして、修正部１５０が、プロジェクトの実績データからシミュレータ１２０内の処理で用いられるパラメータの設定値を修正する。このため、本実施の形態によれば、シミュレータ１２０の模擬結果を、より現実に即したものに改善することができる。

実施の形態２．
本実施の形態について、主に実施の形態１との差異を説明する。

ソフトウェア開発のプロジェクトでは、計画時の評価と同様に、プロジェクト実行中に実行結果を基にしたプロジェクトの完了時の予測と評価が重要である。本実施の形態では、プロジェクトの実績データをシミュレータ１２０に取り込み、プロジェクトの進捗状況に応じた模擬結果の評価を行う。

以下では、図１２を用いて、本実施の形態に係るプロジェクト評価装置１００の動作を説明する。プロジェクト評価装置１００の動作は、本実施の形態に係るプロジェクト評価方法に相当する。プロジェクト評価装置１００の動作は、本実施の形態に係るプロジェクト評価プログラムの処理手順に相当する。

図１２のＳ００１〜Ｓ００９については、図３のＳ００１〜Ｓ００９と同様である。

Ｓ００１で計画値がシミュレータ１２０に設定された後、図１２のＳ０１７において、シミュレータ１２０は、実績データベース１１２に設定されたプロジェクトの模擬対象工程の実績データが存在するかを確認する。本実施の形態では、プログラム作成工程が模擬対象工程である。確認の結果、該当する実績データがない場合、実施の形態１と同様に、Ｓ００２以降でシミュレータ１２０が模擬を実施する。該当する実績データがある場合、フローはＳ０１８に進む。

図１２のＳ０１８において、修正部１５０は、図９に示した修正処理の手順と同様の手順で、実績データによるシミュレータ１２０のパラメータの修正を実施する。

図１２のＳ０１９において、修正部１５０は、実績データをシミュレータ１２０に設定する。具体的には、修正部１５０は、プログラム作成工程でこれまでに作成したプログラムのライン数、これまでに作り込んだプログラムの障害数、作業工数、作業日時をシミュレータ１２０の開始初期値として、シミュレータ１２０内のデータ入出力部１２６を通して、プロジェクト状況データベース１２２に設定する。

図１２のＳ０２０において、修正部１５０は、シミュレータ１２０の開始日時を実績データで記録された日時の直後から開始できるように設定する。この設定は、のちに繰り返し模擬を実行する際の開始日時として評価が完了するまで維持する。開始日時の設定後は、実施の形態１と同様に、Ｓ００２以降でシミュレータ１２０が模擬を指定回数実施する。

以上のように、本実施の形態では、シミュレータ１２０の模擬結果のみの評価だけではなく、プロジェクトの進捗に応じて、実績データを加味した模擬と評価とを実施することが可能となる。

以下では、図１３を用いて、本発明の実施の形態に係るプロジェクト評価装置１００のハードウェア構成の例を説明する。

図１３の例において、プロジェクト評価装置１００は、コンピュータであり、出力装置９１０、入力装置９２０、記憶装置９３０、処理装置９４０といったハードウェアを備える。ハードウェアは、本発明の実施の形態の説明において「部」として説明するものによって利用される。

出力装置９１０は、例えば、ＬＣＤ（Ｌｉｑｕｉｄ・Ｃｒｙｓｔａｌ・Ｄｉｓｐｌａｙ）等の表示装置、プリンタ、通信モジュールである。出力装置９１０は、本発明の実施の形態の説明において「部」として説明するものによってデータ、情報、信号の出力又は送信のために利用される。

入力装置９２０は、例えば、キーボード、マウス、タッチパネル、通信モジュールである。入力装置９２０は、本発明の実施の形態の説明において「部」として説明するものによってデータ、情報、信号の入力又は受信のために利用される。

記憶装置９３０は、例えば、ＲＯＭ（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ・Ｓｔａｔｅ・Ｄｒｉｖｅ）である。記憶装置９３０には、プログラム９３１、ファイル９３２が記憶される。プログラム９３１には、本発明の実施の形態の説明において「部」として説明するものの処理を実行するプログラムが含まれる。ファイル９３２には、本発明の実施の形態の説明において「部」として説明するものによって演算、加工、読み取り、書き込み、利用、入力、出力等が行われるデータ、情報、信号等が含まれる。

処理装置９４０は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）である。処理装置９４０は、バス等を介して他のハードウェアデバイスと接続され、それらのハードウェアデバイスを制御する。処理装置９４０は、記憶装置９３０からプログラム９３１を読み出し、プログラム９３１を実行する。処理装置９４０は、本発明の実施の形態の説明において「部」として説明するものによって演算、加工、読み取り、書き込み、利用、入力、出力等を行うために利用される。

本発明の実施の形態の説明において「部」として説明するものは、「部」を「回路」、「装置」、「機器」に読み替えたものであってもよい。また、本発明の実施の形態の説明において「部」として説明するものは、「部」を「工程」、「手順」、「処理」に読み替えたものであってもよい。即ち、本発明の実施の形態の説明において「部」として説明するものは、ソフトウェアのみ、ハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせで実現される。ソフトウェアは、プログラム９３１として、記憶装置９３０に記憶される。プログラム９３１は、本発明の実施の形態の説明において「部」として説明するものとしてコンピュータを機能させるものである。或いは、プログラム９３１は、本発明の実施の形態の説明において「部」として説明するものの処理をコンピュータに実行させるものである。

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、いくつかを組み合わせて実施しても構わない。或いは、これらの実施の形態のうち、いずれか１つ又はいくつかを部分的に実施しても構わない。例えば、これらの実施の形態の説明において「部」として説明するもののうち、いずれか１つのみを採用してもよいし、いくつかの任意の組み合わせを採用してもよい。なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

１００ プロジェクト評価装置、１１０ データベース、１１１ プロジェクト計画データベース、１１２ 実績データベース、１１３ 模擬結果データベース、１１４ 分析結果データベース、１２０ シミュレータ、１２１ 模擬実行部、１２２ プロジェクト状況データベース、１２３ イベントルール群データベース、１２４ イベント発火制御部、１２５ 管理者模擬エージェント部、１２６ データ入出力部、１３０ 評価部、１４０ 分析部、１５０ 修正部、１６０ 出力部、９１０ 出力装置、９２０ 入力装置、９３０ 記憶装置、９３１ プログラム、９３２ ファイル、９４０ 処理装置。

Claims (7)

1. ソフトウェアを開発する複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の情報である従事者情報を記憶するデータベースと、
   前記複数のプロジェクトのそれぞれについて、前記データベースに記憶された従事者情報に基づき、プロジェクトに従事する者の行動を模擬することで、プロジェクトで開発されるソフトウェアの障害数と、プロジェクトでソフトウェアの開発にかかる工数と、プロジェクトでソフトウェアの開発が遅延する日数との複数種類の予測値のうち、少なくとも１種類の予測値を算出するシミュレータと、
   前記シミュレータにより模擬された行動の回数を入力値とし、前記シミュレータにより算出された予測値を出力値とし、包絡分析法を用いて前記複数のプロジェクトの効率値を算出することで、前記複数のプロジェクトを評価する評価部とを備えるプロジェクト評価装置。
2. 前記シミュレータは、前記複数のプロジェクトのそれぞれについて、前記複数種類の予測値を算出し、
   前記評価部は、前記シミュレータにより模擬された行動の回数を入力値とし、前記複数種類の予測値を出力値とし、包絡分析法を用いて前記複数のプロジェクトの効率値を算出する、請求項１に記載のプロジェクト評価装置。
3. 前記複数のプロジェクトのそれぞれについて、前記複数種類の予測値と、前記評価部により算出された効率値との関係を分析する分析部と、
   前記分析部による分析の結果を出力する出力部と
   をさらに備える、請求項２に記載のプロジェクト評価装置。
4. 前記シミュレータは、前記複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の行動として、プロジェクトの管理者が作業者に出す指示を模擬する、請求項１から３のいずれか１項に記載のプロジェクト評価装置。
5. 前記複数のプロジェクトのそれぞれについて、プロジェクトの実績に応じて、前記データベースに記憶された従事者情報を修正する修正部をさらに備える、請求項１から４のいずれか１項に記載のプロジェクト評価装置。
6. シミュレータが、ソフトウェアを開発する複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の情報である従事者情報をデータベースから取得し、取得した従事者情報に基づき、プロジェクトに従事する者の行動を模擬することで、プロジェクトで開発されるソフトウェアの障害数と、プロジェクトでソフトウェアの開発にかかる工数と、プロジェクトでソフトウェアの開発が遅延する日数との複数種類の予測値のうち、少なくとも１種類の予測値を算出し、
   評価部が、前記シミュレータにより模擬された行動の回数を入力値とし、前記シミュレータにより算出された予測値を出力値とし、包絡分析法を用いて前記複数のプロジェクトの効率値を算出することで、前記複数のプロジェクトを評価するプロジェクト評価方法。
7. コンピュータに、
   ソフトウェアを開発する複数のプロジェクトのそれぞれについて、プロジェクトに従事する者の情報である従事者情報をデータベースから取得し、取得した従事者情報に基づき、プロジェクトに従事する者の行動を模擬することで、プロジェクトで開発されるソフトウェアの障害数と、プロジェクトでソフトウェアの開発にかかる工数と、プロジェクトでソフトウェアの開発が遅延する日数との複数種類の予測値のうち、少なくとも１種類の予測値を算出するシミュレーションと、
   前記シミュレーションにより模擬された行動の回数を入力値とし、前記シミュレーションにより算出された予測値を出力値とし、包絡分析法を用いて前記複数のプロジェクトの効率値を算出することで、前記複数のプロジェクトを評価する評価処理と
   を実行させるプロジェクト評価プログラム。

Images