(57)【要約】【課題】  プロジェクト評価にて、数値属性のデータに基づいてカテゴリ属性の指標を効率的かつ精度よく見積もる。【解決手段】  第１処理は第１指標に係るデータを第２指標に係るデータに変換し第１の評価値とする第１の評価工程であり、第２処理は第１指標に係るデータあるいはそれ以外の指標に係るデータにもとづき第１の評価工程とは異なる方法で第２指標に係るデータを取得し第２の評価値とする第２の評価工程であり、第３処理は前記第２の評価値を用いて前記第１の評価値を再評価する演算処理を行う第３の評価工程であり、第４処理は前記第１指標に係るデータ、前記第１の評価値、前記第２指標あるいは前記第２の評価値の一つあるいは複数を蓄積するデータベース構築工程であるプロジェクト評価方法及びシステム。【選択図】  図３
2015014856.tif 000002
【特許請求の範囲】
【請求項１】
評価対象とする単一あるいは複数のプロジェクトの夫々に関する第１指標に係るデータと、第１指標に係るデータあるいはそれ以外の指標に係るデータによって得られるデータである第２指標に係るデータとを用いる、プロジェクトの評価方法であって、
コンピュータ装置が実行する第１処理、第２処理、第３処理及び第４処理を含み、
前記第１処理は、第１指標に係るデータを第２指標に係るデータに変換し第１の評価値とする第１の評価工程であり、
前記第２処理は、第１指標に係るデータあるいはそれ以外の指標に係るデータにもとづき第１の評価工程とは異なる方法で第２指標に係るデータを取得し第２の評価値とする第２の評価工程であり、
前記第３処理は、前記第２の評価値を用いて前記第１の評価値を再評価する演算処理を行う第３の評価工程であり、
前記第４処理は、前記第１指標に係るデータ、前記第１の評価値、前記第２指標、あるいは前記第２の評価値の一つあるいは複数を蓄積するデータベース構築工程である、ことを特徴とするプロジェクト評価方法。
【請求項２】
請求項１において、
前記第２指標がカテゴリ型属性を有する指標であり、評価結果の不確実さの存在を表現する属性値を有し、
前記第１指標が数値型属性あるいはカテゴリ型属性を有する指標である、ことを特徴とするプロジェクト評価方法。
【請求項３】
請求項２において、
前記カテゴリ型属性を有する指標が、品質・コスト・納期の出来栄えに関するカテゴリ、あるいはプロジェクトのフェーズゲートの通過可否のいずれか一つあるいは複数である、ことを特徴とするプロジェクト評価方法。
【請求項４】
請求項１乃至請求項３において、
コンピュータ装置が対話的入力支援手段を備え、
前記第２の評価工程が対話的入力支援手段を用いた評価者による入力によって第２指標に係るデータを取得する処理を含む、ことを特徴とするプロジェクト評価方法。
【請求項５】
請求項１乃至請求項４において、
前記第３の評価工程の再評価処理が、前記データベースに蓄積されたデータ群を用いる３つの処理である予測モデルを構築する処理、特徴パターンを発見する処理、クラスタリングを行う処理のうち、単一あるいは複数の処理を含むことを特徴とするプロジェクト評価方法。
【請求項６】
請求項１乃至請求項５において、
前記第２の評価工程にて、第２指標に係る取得データとして、評価入力者の属性に関わる情報やプロジェクトの従事者に関わる属人的情報に係るデータを含み、
前記第３の評価工程の再評価にて、前記属人的情報に係るデータを参照する、ことを特徴とするプロジェクト評価方法。
【請求項７】
評価対象とする単一あるいは複数のプロジェクトの夫々に関する第１指標に係るデータと、第１指標に係るデータあるいはそれ以外の指標に係るデータによって得られるデータである第２指標に係るデータとを用いる、プロジェクトの評価システムであって、
第１指標に係るデータを第２指標に係るデータに変換し第１の評価値とする第１の評価手段と、
第１指標に係るデータあるいはそれ以外の指標に係るデータにもとづき第１の評価手段とは異なる方法で第２指標に係るデータを取得し第２の評価値とする第２の評価手段と、
前記第２の評価値を用いて前記第１の評価値を再評価する演算処理を行う第３の評価手段と、
前記第１指標に係るデータ、前記第１の評価値、前記第２指標、あるいは前記第２の評価値の一つあるいは複数を蓄積するデータベース構築手段と、を備えることを特徴とするプロジェクト評価システム。
【請求項８】
請求項７において、
前記第２指標がカテゴリ型属性を有する指標であり、評価結果の不確実さの存在を表現する属性値を有し、
前記第１指標が数値型属性あるいはカテゴリ型属性を有する指標である、ことを特徴とするプロジェクト評価システム。
【請求項９】
請求項８において、
前記カテゴリ型属性を有する指標が、品質・コスト・納期の出来栄えに関するカテゴリ、あるいはプロジェクトのフェーズゲートの通過可否のいずれか一つあるいは複数である、ことを特徴とするプロジェクト評価システム。
【請求項１０】
請求項７乃至請求項９において、
コンピュータ装置が対話的入力支援手段を備え、
前記第２の評価手段が対話的入力支援手段を用いた評価者による入力によって第２指標に係るデータを取得する処理を含む、ことを特徴とするプロジェクト評価システム。
【請求項１１】
請求項７乃至請求項１０において、
前記第３の評価手段の再評価処理が、前記データベースに蓄積されたデータ群を用いる３つの処理である予測モデルを構築する処理、特徴パターンを発見する処理、クラスタリングを行う処理のうち、単一あるいは複数の処理を含むことを特徴とするプロジェクト評価システム。
【請求項１２】
請求項７乃至請求項１１において、
前記第２の評価手段にて、第２指標に係る取得データとして、評価入力者の属性に関わる情報やプロジェクトの従事者に関わる属人的情報に係るデータを含み、
前記第３の評価手段の再評価にて、前記属人的情報に係るデータを参照する、ことを特徴とするプロジェクト評価システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの開発においてソフトウェアの品質管理方法及びシステムに関するものである。
【背景技術】
【０００２】
ソフトウェア開発のプロジェクト管理においては開発中のソフトウェアの出来栄えを評価して、フェーズ移行等をコントロールすることが多い。組織的活動としてのソフトウェア開発の評価では、合理的な判断の根拠を組織的に共有することが必要である。特許文献１では、レビュー実施回数や課題件数や不具合件数に基づいてフェーズ移行の可否を判断する場合、コンポーネントの開発規模、難易度、担当者のスキルといったパラメータが曖昧なために、適確なフェーズ移行の判断が困難である点を課題に挙げている。その上で、特許文献１では、課題の解決手段として、開発規模、難易度、担当者のスキルといったパラメータは作業タスクの工数と密接な関係があることを利用し、作業工数に基づいて、単位工数あたりのレビュー実施回数、課題件数、不具合件数などを算出するアプローチをとっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２０７０２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
プロジェクトの評価では、レビュー実施回数や課題件数や不具合件数といった数値属性で示される指標に係るデータをもとに、フェーズ移行の可否が評価される。また、同様に、進行中のプロジェクトの進捗管理を行う際には、レビュー実施回数や課題件数や不具合件数といった数値属性の指標に係るデータを、開発の途中段階で経時的に取得してその変化の傾向を把握し、プロジェクト終了時の品質・コスト・納期に関する良し悪しや目標への到達可否、を予測的に判定する。
【０００５】
これらの評価工程においては、数値属性のデータに基づいてカテゴリ属性の指標（「可／否」「良／悪」）を効率的かつ精度よく見積もることが、課題となる。ソフトウェア開発プロジェクトの評価に関わる次の状況を踏まえ、この課題に対応することが望まれる。
【０００６】
（１）ソフトウェア開発では、反復型の開発プロセスの採用等、開発途中の仕様変更などの計画変更を許容する事案が増えている。開発途中の仕様変更等は、計画時点の見積りや進行途中段階の評価、さらには完了時点の予測に対する前提を崩す要因となるが、このような見積りや予測のリスク増に対応する手段が十分ではない。
【０００７】
（２）機械化で同質的な反復作業で構成される製造工程等に比べ、労働集約的要素の強いソフトウェア開発プロジェクトは、属人的な要素を暗黙的に多く備える。その為、対象となるデータの同質性を確保し、再現性をもって定量的に状況を評価することや、組織全体で評価結果の根拠を共有することが容易でなく、見積りや予測の計算の支障となりやすいが、前記属人的な要素を明示的に把握する手段が十分ではない。
【０００８】
（３）大量生産の製造ラインから得られる品質管理データの計測等と比べ、ソフトウェア開発プロジェクトでは、短期間に多頻度のデータ計測機会を得ることが一般に難しく、評価に寄与するサンプル数を確保しにくい。その為、平均値等の統計学的な指標を活用する要件に関わる、一定以上のサンプル数の存在を、満足することが困難である。同様に、計画時点の見積りの類推根拠に活用できる量の実績データ群を得にくい。
【０００９】
（４）ソフトウェア開発プロジェクトにおいては、その属人性の強い状況を反映し、その評価においても評価者の経験に依拠した暗黙的な「良／否」等の判定がなされることが少なくない。プロジェクト評価に係る数値データを計測していたとしても数値データの最終的な「良／否」等のカテゴリ判定への対応づけは、暗黙的な経験に依拠する場合が少なくない。その為、カテゴリ属性の指標を目的変数と設定し数値属性等を説明変数とするような、カテゴリ属性に係る明示的で共有可能な計算工程が、ソフトウェア開発プロジェクトの評価では十分に具備されていないことが一般的である。
【課題を解決するための手段】
【００１０】
上記課題を解決する為、本発明におけるプロジェクト評価方法及びシステムでは、上記の課題に対して、品質等を説明する連続的な数値（以下「第１指標に係るデータ」）を、品質等の良し悪しや、良否の判別の付かない中間といったカテゴリ属性の属性値（以下「第２指標に係るデータ」）に仕分ける際に、第１指標に係るデータを第２指標に係るデータに変換し第１の評価値とする第１の評価工程（評価手段）とともに、第１指標に係るデータあるいはそれ以外の指標に係るデータにもとづき第１の評価工程（評価手段）とは異なる方法で第２指標に係るデータを取得し第２の評価値とする第２の評価工程（評価手段）を備え、さらに、前記第２の評価値を用いて前記第１の評価値を再評価する演算処理を行う第３の評価工程（評価手段）を備える。
【００１１】
本発明の第１の評価工程（評価手段）では、仕様変更等の不確実性（リスク）や類推根拠の存在しない個別プロジェクト固有の状況に起因する評価（見積り）の曖昧さを織り込み、第２の評価工程（評価手段）及び第３の評価工程（評価手段）で、不確実性（リスク）や曖昧さを漸進的に明確化することを、主に意図している。その為に、第１の評価工程（評価手段）において、標準偏差（分散）や、カテゴリ属性における「可／否」「良／悪」の間の中間領域を評価値として取得し不確実さや見積りにおける判断等の曖昧さの存在を表現可能にする。その上で、第２の評価工程（評価手段）では、分散やカテゴリ属性における中間領域として評価された評価値を、別のタイミングと視点にて再評価し、後続の第３の評価工程（評価手段）とあわせて、カテゴリ属性における中間領域等で表現された評価の曖昧さを段階的に減らす。
【００１２】
本発明における第２の評価工程（評価手段）においては、対話的評価支援手段を備え、第２の評価値とともに属人的に保有されている評価に関わる情報を蓄積することも可能にする。
本発明における第３の評価工程（評価手段）においては、第２の評価値や付随する属人的な情報からパラメータを精査・分析および更新を行う「パラメータ抽出手段」を備える。そして、蓄積した根拠情報をもとに第１の評価値の更新、及び第１の評価工程における評価基準の更新を行う。
【００１３】
本発明の第３の評価工程（評価手段）におけるカテゴリ属性に係る評価値や評価基準の更新においては、予測モデルを構築する処理、特徴パターンを発見する処理、クラスタリングを行う処理のうち、単一あるいは複数の処理を含む。これらはサンプル数が比較的少なくて済むという点で、カテゴリ属性の見積りや予測における強みを有する。数値属性向けに多用される平均値等の統計計算との併用も可能である。
【００１４】
同一の開発内での後続の判断、後続のプロジェクトでは、更新された基準を参照することがきる。パラメータの算出には、例としてテスト管理に用いられる累積バグ数をグラフ化したバグ曲線の傾きを用いてパラメータを算出する。
【発明の効果】
【００１５】
上記手段によって、同一の対象に対するカテゴリ指標等の係る複数の評価値（第１の評価工程（評価手段）による評価結果と第２の評価工程（評価手段）による評価結果）を照合することが可能になり、さらに第２の評価工程（評価手段）で評価に関わる属人性の高い要因情報を取得容易になる。結果として、開発プロジェクトの見積りや評価に関し、属人性の高い要素も含めた根拠の増加や開発組織内での共有が促進され、プロジェクトにおける計画変更等の不確実性（リスク）に対する見積りやリスクを抱えたプロジェクトの進捗管理の的確性や再現性が向上する。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態に係わる各情報処理装置のハードウェア構成の一例を示す図である。
【図２】本発明の実施形態に係わる機能ブロック図である。
【図３】本発明の実施形態に係わる全体の概要図である。
【図４】本発明の図３の対話的評価支援手段２２の工程についてのフロー図である。
【図５】本発明の図３のパラメータ抽出手段２５の工程についてのフロー図である。
【図６】本発明の全体の流れを示したフローチャートを示す図である。
【図７】本発明の実施形態に係わる３領域（A,B,C）に判定するための、振分け基準の設定についてのフローである。
【図８】本発明の実施形態に係わる３領域（A,B,C）に分ける工程を詳細化したフロー図である。
【図９】本発明の実施形態に係わる分類されたBを２領域（A,C）の判定についての詳細化したフロー図である。
【図１０】本発明の実施形態に係わる振り分け基準を設定する設定画面の一例を示す図である。
【図１１】本発明の実施形態に係わる開発されたソフトウェアに関わるデータを示す図である。
【図１２】本発明の実施形態に係わるAと判定されたデータ構造を示す図である。
【図１３】本発明の実施形態に係わるCと判定されたデータ構造を示す図である。
【図１４】本発明の実施形態に係わる判定変更画面表示を示す図である。
【図１５】本発明の実施形態に係わるBと判定された結果のB判定のデータ構造を示す図である。
【図１６】本発明の実施形態に係わる振り分け基準でBと判別されたものを、ユーザが判定する際に担当者情報を入力するユーザ情報のデータ構造を示した図である。
【図１７】本発明の実施形態に係わるユーザ情報を活用した事例を示した図である。
【図１８】本発明の実施形態に係わる開発されたソフトウェアファイルデータを判定した結果をグラフで表示した例を示す図である。
【図１９】本発明の実施形態に係わる開発時期に応じて開発ソフトウェアの品質評価の判定時期を示す図である。
【図２０】本発明の実施形態に係わる図１９で示されたグラフ図の結果を表として示した一例を示す図である。
【図２１】本発明の実施形態に係わるバグ曲線を例としている示す図である。
【図２２】本発明の実施形態に係わる振り分け基準を設定について具体的に説明した図である。
【図２３】本発明の実施形態に係わるユーザがバグ曲線の他に追加情報が欲しい場合に、情報を追加し組み合せて表示できる具体例を示す図である。
【図２４】本発明の実施形態に係わるプロジェクトの進行度での或る属性に対する評価結果の一例を示す図である。図２４の各レコードの評価は、図１４の判定変更画面による原判定結果に相当するものである。
【図２５】本発明の実施形態に係わる図１４の判定変更画面による再判定結果における「良」「悪」が併記された図である。
【図２６】本発明の実施形態に係わる図２４の情報からパターンを抽出した結果の一形態を示した図である。
【図２７】本発明の実施形態に係わる図２５の情報からパターンを抽出した結果の一形態である。
【図２８】本発明の実施形態に係わる図２４の「良」「悪」「グレー」の３つの領域に振り分ける際に参照された或る属性（指標）の評価値を示す図である
【図２９】本発明の実施形態に係わる図２８の表をグラフとしてプロットした図である。
【図３０】本発明の実施形態に係わる新たな境界と領域の所在を示した図である。
【発明を実施するための形態】
【実施例１】
【００１７】
以下、本発明の実施の形態を、図面を参照して説明する。
【００１８】
本発明における方法は、図１に示すような、CPU１００と主記憶部１０１と、HDD等の外部記憶装置１０２と、CD-ROMやDVD-ROM等の可搬性を有する可搬型記憶媒体１０３から情報を読み出す読取装置１０４とディスプレイ、キーボードやマウス等の入出力装置１０５と、通信ネットワークに接続するためのNIC（Network Interface Card）等の通信装置１０６と、を備えた一般的なコンピュータで実現される。
【００１９】
図２は、開発中のソフトウェアファイルの品質を評価する開発ソフトウェア情報品質評価手段構成を示す機能ブロック図である。図１の１０２の外部記憶装置部１と図１の１００の主記憶装置部２を、備える。
【００２０】
外部装置記憶部１は、開発ソフトウェア情報格納部３を備える。開発ソフトウェア情報格納部３には、開発中のソフトウェアファイルデータが格納される。
【００２１】
主記憶装置部２は、条件設定部４、照合部５、判定部６、判定結果表示部７、再判定部８、パラメータ抽出部９、パラメータ更新部１０とを、備える。
【００２２】
条件設定部４は、開発ソフトウェア情報データを照合部５で照合を行うために、条件設定画面上で品質評価を判定するための品質評価条件の設定を行う。
【００２３】
判定部６で判定された開発ソフトウェア情報を判定結果表示部７でユーザにわかりやすく結果を可視化し表示する。
【００２４】
判定部６で判定された結果の内、ユーザによって再判定が必要な場合に再判定部８で再判定を行う。ユーザによって再判定された結果の判定条件のパラメータを抽出部９で抽出する。抽出した品質評価用パラメータをパラメータ更新部１０で更新する。
（本発明で用いられるユーザとは、プロジェクトに従事する人であり、再判定を担当する作業者やプロジェクトをまとめる管理者のことを称す。）
図３は、本実施例に係る全体の概要図を示した図である。図２の３の開発ソフトウェア情報格納部に格納されている開発ソフトウェア情報２０を入力として、開発ソフトウェア情報データの品質評価を行う品質評価手段の工程２１を実施する。品質評価を行う際、基準となる品質評価条件を設定し、開発ソフトウェア情報データと設定した基準とを照合し、設定した３領域（A,B,C）に判別する。品質評価条件は、図１０の判定基準設定画面から条件設定を行う。
【００２５】
設定した品質評価条件によって、例えば過去のデータをもとに設定した基準をAと判定し、CはAの基準を明らかに満たしていない場合とし、BはAあるいはCのどちらにも判定できない場合とする。
【００２６】
B判定を、担当ユーザ２８によって、目視によってAあるいはCを再判定する。担当ユーザは、「関連情報要求」操作において評価結果表示手段工程２７によって必要な情報を表示する。「関連情報要求」操作により、ユーザが必要とする対応するBのデータNo.の画像データを要求し、判定Aの基準値のバグ曲線と照合し、AあるいはCを判定する。ユーザが確認したいB判定の情報を要求する工程は、対話的評価支援手段工程２２で行われる。対話的評価支援手段工程では、ユーザが確認したい画像データを「関連情報要求」２９により要求し、「関連情報を取得」３０によって要求したデータを取得する。対話的評価支工程の具体的な流れは、図１５の判定Bのデータ表５００の「判定に用いられた画像データ」欄に設置されている「拡大表示」ボタン５０７を押すことで、図１４の４０１の画面が開き、ユーザが確認したいデータNo.の画像データを表示し確認することができる。
【００２７】
また、B判定となった結果を、ユーザがAあるいはCに再判定することも図１４の４０１判定変更画面から入力することができる。
【００２８】
ユーザが必要なデータを要求し、ユーザが再判定を行う際、「判定とその理由、ユーザ情報を付加」操作によって、氏名、チーム名、経験年数、などのユーザ情報も入力する。ユーザが判定した結果が履歴データ２３としてバグ曲線などのグラフ画像およびユーザ情報も格納される。
【００２９】
この履歴データをもとにパラメータ抽出手段工程２５においてユーザが判定した判定基準のパラメータを抽出し、品質評価用のパラメータ２６として、更新される。
また開発プロジェクト完了後の社外不良情報などが格納された格納ファイル２４の情報を利用し、ユーザが判定した結果がプロジェクト完了後にどのような結果となったかを相関し、パラメータを分析することも可能である。
【００３０】
更に、担当ユーザ、チームごと、あるいは経験年数などによってユーザの判定の傾向などを分析し、パラメータに反映させることも可能である。
【００３１】
図３では、指標としてバグ曲線を例として記載しているが、本発明の全体の概要フローを図２とともに説明する。
【００３２】
なお、この説明において、前記評価工程１は、次に示す図６のステップ１とステップ１０によって構成されるものとして示されており、前記評価工程２は、次に示す図６のステップ１１とステップ１２によって構成されるものとして示されている。また、前記評価工程３は、図６のステップ１２-１とステップ１３によって構成されるものとして示されている。
【００３３】
開発されたソフトウェアを３領域（A,B,C）に分けるために、振り分け基準を設定する（ステップ１）。  開発ソフトウェアを振り分け基準によって３領域（A,B,C）に分ける（ステップ１０）。Aは、ある基準値を満たしているものとし、Cはある基準値を満たしていない場合とし、BはAあるいはCにどちらにも判定できない場合とする。
【００３４】
次に領域Bに振り分けられた値を、担当ユーザの判断により、後から入力される振り分け指定情報によってAかCに振分ける（ステップ１１）。AかCに振分けられた領域Bの画像データが履歴データとして格納される（ステップ１２）。ユーザによって後から振り分けられた再判定結果から品質評価用のパラメータを抽出する（ステップ１２-１）。
【００３５】
後から入力された振り分け指定情報を用いて抽出した品質評価用のパラメータを３領域（A,B,C）の振り分け基準として更新する（ステップ１３）。
【００３６】
またステップ１２では、担当ユーザが判定する際に、１４のボックスに示すように担当ユーザ情報も図１６で例示しているような入力項目などを入力するため、担当ユーザ情報も同時に収集することが可能になっている。この収集した情報の活用によって、ステップ１２-１の品質評価用のパラメータを抽出する際に、ボックス１５のようにユーザの経験年数によっての差異、チームごとによる差異、過去のプロジェクト経験による差異などの担当ユーザによる判定の傾向の分析も行うことが可能となっている。
【００３７】
１.１［評価工程１の説明］
評価工程１を構成する図６のステップ１とステップ１０の詳細フローを図（図７、図８）とともに説明する。
【００３８】
図７は、図６のステップ１の開発されたソフトウェアファイルデータを３領域（A,B,C）に判定するための、振分け基準の設定について詳細化したフローである。
【００３９】
図１０の判定基準設定画面を開き（ステップ２０）、表示画面からA判定の指標となる曲線を選択する（ステップ２１）。図１０では、バグ曲線を選択した例を示す。
【００４０】
表示画面上の指標となる曲線のA判定を決定する下限値を入力する（ステップ２２）。次に表示画面上のC判定を決定する上限値を入力する（ステップ２３）。その後で、担当ユーザ情報を入力する（ステップ２３-２）。
【００４１】
表示画面上の実行ボタンを押し、条件設定が完了する（ステップ２４）。
【００４２】
ここで述べた上限値および下限値については、図２１に詳細を示す。図２１のグラフ図はバグ曲線を例としている。縦軸に累積バグ数（件数）、横軸に日数が示され、過去の実績に照らし合わせて設定したA判定の基準となるバグ曲線が示されており、基準となるラインのA判定の傾きを下限値とし、A判定の傾きよりも大きな傾きを上限値とし決定し、上限値の傾きがC判定の傾きとなる。A判定の傾きよりも大きく、C判定の傾きよりも小さい傾きが、B判定として判定される。
【００４３】
図８は、ステップ１０の開発されたソフトウェアを振り分け基準によって３領域（A,B,C）に分ける工程を詳細化したフローである。
【００４４】
開発されたソフトウェアからデータを１つ取得し、取得したソフトウェアファイルデータをD１とする（ステップ１０１）。取得したソフトウェアのデータD１と過去のデータをもとに設定した判定基準Mと比較、照合し（ステップ１０２）、取得したソフトウェアデータD１が判定基準Mの範囲であるかを確認する（ステップ１０３）。判定基準の範囲内（取得したデータD１＝M）であれば、修得データD１を「A」として判定し格納する（ステップ１０５）。
【００４５】
Aの判定基準Mの範囲内でなかった場合は、取得したデータD１がC判定の傾き（上限値）ｋ１の範囲内かを確認する（ステップ１０６）。C判定の傾きｋ１の範囲内であれば、取得データD１を「C」として判定し格納する（ステップ１０７）
取得データが判定「A」、「C」のどちらにも当てはまらなかった場合は「B」と判定され、判定「B」に格納される（ステップ１０８）。開発されたソフトウェアの全てのデータを３領域に判定し、終了する（ステップ１０９）。全データが判定されていない場合は、ステップ１０１に戻り、次のデータを一つ取得し、同様に３領域のどれに当てはまるかを判定する。
【００４６】
図１０は、図６のステップ１の振り分け基準を設定する設定画面の一例を示す「判定基準設定画面」の一実施の形態である。
【００４７】
A判定の指標となる指標曲線を選択する。例としてバグ曲線を選択した例を示す。バグ曲線、テスト消化曲線の両方の曲線を選択することも可能である。
【００４８】
「その他」の参照ボックスは、バグ曲線、テスト消化曲線の他に指標となる成長曲線などを参照したい場合に選択することができる。
過去のデータを指標にしたい場合も「過去のデータ」参照ボックスから過去のデータを参照し、バグ曲線線、およびテスト消化曲線を作成することも可能である。
上限値、および下限値は前記図７を説明する際に説明を記載したので、省略する。
【００４９】
図１１は、図８のステップ１０１の開発されたソフトウェアに関わるデータを示す。
【００５０】
開発されたソフトウェアのデータ表２００は、左の縦列から順に開発されたソフトウェアのデータNo.（２０１）、プロジェクト名（２０２）、機能名（２０３）、データNo. に対応する画像データ（２０４）が格納される。２０２のプロジェクト名は、開発されているソフトウェアのプロジェクト名が格納され、２０３の機能名は、データNo.がどの機能について開発されたかの機能名が格納される。
【００５１】
２０４の画像データには、データNo. に対応する画像データ、およびA判定の基準のベースとなるラインが格納される。
【００５２】
次に、前記図６のステップ１とステップ１０にもとづく評価工程１に関し、図（図１８，図２０，図２１，図２２）とともに具体的な評価対象や評価結果等を例示することで説明を補足する。
【００５３】
図１８は、開発ソフトウェア情報データを判定した結果をグラフで表示した例を示す。
【００５４】
図１８はバグ曲線を指標とした場合の表示例を示しており、縦軸が累積バグ数（件数）、横軸が日数を示す。バグ曲線は、成長曲線で示され、開発初期段階では、累積バグ数が多く、傾きの角度が急であり、開発の終盤に近づく程、累積バグ数の件数が落ち着き穏やかな傾きとなる。本発明では、開発が終盤に近づき急な傾きから、累積バグ数の件数が落ち着き穏やかになり始めたところを傾きの開始点（図１８の７０１）とし、図１０の判定基準設定画面でA判定の傾きを設定する。
【００５５】
図１０の判定基準設定画面でA判定の指標となる基準線を選択し、上限値、および下限値を入力することでA判定の基準ラインとC判定のラインが決定する。図１０の判定基準設定画面で上限値、および下限値を入力すると、下限値によってA判定の傾きが決定し（図２１の９０１）、A判定の下限値の傾きから上限値のC判定の傾き（図２１の９０２）が決まる。
【００５６】
図１８では、過去の実績も参照しA判定の基準となるバグ曲線を参照したものであり、過去の実績のデータのバグ曲線を参照することもできる（図１０の２１０）。
【００５７】
図１８では、開発ソフトウェア情報データのうち、開発してから３０日目のデータ（X１）の品質評価についての判定結果を示し、例としてグラフ上にa点、b点、c点としてそれぞれ表示している。a点はA判定のライン上に乗っていることよりA判定となり、c点はC判定のライン上に乗っていることよりC判定となる。b点はA判定のライン、およびC判定のライン上に乗っておらず、A判定のラインよりも傾きが大きく、C判定のラインよりも傾きが小さい位置に存在するので、B判定となる。
【００５８】
a点、b点、c点は座標軸で位置を表示することができ、a点は（X１、Y１）、ｂ点は（X１、Y２）、c点は（X１、Y３）となる。図２１で具体的に示した数字のX軸とY軸で示すと、a点は（３０、１３５）、ｂ点は（３０、１７０）、c点は（３０、２２５）となる。図２１の具体的な数字をもとにA判定の傾き（下限値）は、（３０-１５）÷（１３５-１００）＝０.４２・・・となる。C判定の傾き（上限値）は、（３０-１５）÷（２２５-１００）＝０.１２となる。A判定の傾き（下限値）、およびC判定の傾き（上限値）を、図１０の判定基準設定画面の「上限値」（図１０の２１１）に０.４２、「下限値」（図１０の２１２）に０.１２など設定したい数値を入力する。
【００５９】
図１９は、開発時期に応じて開発ソフトウェアの品質評価の判定する場合を示す。
【００６０】
図１８では図１９の開発中盤時期（７０２）の開発ソフトウェアの品質評価の判定基準のA判定、C判定、およびB判定について説明をしたが、開発序盤時期（７０１）のX軸のXs日、開発中盤時期（７０２）のX軸のX１日、開発終盤時期（７０３）のX軸のX２日のそれぞれの開発時期に応じて、開発ソフトウェアの品質評価の判定を行うことも可能である。
【００６１】
品質評価の判定したい開発日数のX軸を変更することで、図１８で示した開発中盤期と同様に判定基準の傾きを図１０の判定基準設定画面で設定し、開発ソフトウェアの品質評価の判定をすることも可能である。
【００６２】
図２０は、図１９で示されたグラフ図の結果を表として示した一例である。
左から順に縦列に、表示された「グラフNo.」、開発ソフトウェア情報「データ名」、開発ソフトウェア情報「データのグラフ上の座標位置」、品質判定結果についての項目が示された表である。
【００６３】
開発ソフトウェア情報「データ名」には図１８で表示されていたa点、b点、c点が示されている。それぞれのデータの品質判定結果を品質評価判定結果の欄にA判定、あるいはB判定、あるいはC判定のいずれかを示す。
【００６４】
開発ソフトウェア情報「データのグラフ上の座標位置」には、各データにおけるX軸、Y軸、傾きで示し、図１９の開発中盤であれば、図１８に示した累積バグ数が穏やかになりかけてきた地点のX軸のX０を開始点として判定Aの傾きが決まる。開発序盤および開発終盤の傾きにおいても開発中盤と同様に、品質判定を行いたいX軸の開発日数における開発ソフトウェアのデータのY軸である累積バグ数がどこであるかを確認し、A判定の傾きを基準として、他のデータの座標位置の傾きを決めてA判定、C判定、B判定を決定する。  
【００６５】
傾きについての詳細は図２１に示した。
【００６６】
図２１のグラフ図はバグ曲線を例としている。縦軸に累積バグ数（件数）、横軸に日数が示され、過去の実績に照らし合わせて設定したA判定の基準となるバグ曲線が示されている。基準となるラインのA判定の傾きを下限値とし、A判定の傾きよりも大きな傾きを上限値とし決定し、上限値の傾きがC判定の傾きとなる。A判定の傾きよりも大きく、C判定の傾きよりも小さい傾きが、B判定として判定される。具体的な説明としては図１８に記載した。
【００６７】
図２２に図２１を具体的に説明した例を示す。図１０の振り分け基準を設定する設定画面で下限値としてA判定の傾きを１.５と設定した場合、X軸が３（横）、Y軸が２（高さ）のラインとして表示される。上限値としてC判定の傾きを０.６として設定した場合、X軸が３（横）、Y軸が５（高さ）のラインとして表示される。Y軸の開始点は判定A、判定Cともに同じとする。
【００６８】
B判定の傾きは、C判定の高さ５の半分の高さ２.５より小さく、A判定の高さ２よりも大きいとした範囲の高さにおける傾きをB判定のラインとして表示する。
【００６９】
C判定の座標を（X１, Y２）、A判定の座標を（X１，Y１）とした時（図２２の座標に表記）、B判定の範囲は、Y１／X１＜B判定＜（Y２／２）／X１となる。
【００７０】
ここでの例として、傾きでA判定のバグ曲線を基準のラインとして設定しているが、面積や角度を利用する方法を用いても良い。
【００７１】
図２１で定義したA判定の傾き、およびC判定の傾きは、図５のステップ４４、４８、５６に記載がある標準偏差を考慮することができる。ゆえにA判定の傾き、およびC判定の傾きに標準偏差の範囲で幅を持たせることが可能であり、その標準偏差の範囲で判定基準を設定することもできる。
【００７２】
１.２［評価工程２の説明］
評価工程２についてのフローを（図４）とともに説明する。図３の対話的評価支援手段２２はここで用いられる。また、ここで説明するフローは、評価工程２を構成する図６のステップ１１とステップ１２の詳細フローに相当する。
【００７３】
図３の品質評価手段２１の工程によって３領域（A,B,C）に判別された結果の内、B判定として図１５のB判定のデータ表５００を取得する（ステップ３０）。B判定のデータ表５００からデータを１つ取得する（ステップ３１）。取得したB判定のデータに対応する画像データを図３の「関連情報要求」操作により、ユーザが要求する（ステップ３２）。図１５のB判定のデータ表５００の「判定に用いられた画像データ」欄に設置されている「拡大表示」ボタン５０７をユーザが押すことで対応する画像データが要求される。図１４の４０１の判定変更画面が開き、要求された画像データが出力される（ステップ３３）。図３の「判定とその理由、ユーザ情報を付加」操作によって、出力された画像データをユーザが見て、図１４の４０１の判定変更画面の４０３の「A」ボタンあるいは４０４の「C」ボタンのどちらかをユーザが押し再判定する（ステップ３４）。AあるいはCに再判定した理由を図１４の４０５の「再判定理由」ボタンを押し入力する（ステップ３５）。 AあるいはCに再判定した画像データ、およびユーザが再判定した理由が履歴データに格納される（ステップ３７）。B判定のデータ表５００に表示されている全てのデータについて再判定を行い終了する（ステップ３６）。
【００７４】
図１４は、判定変更画面表示を示す。図６のステップ１０でBとして判定された表示画面（４０１）は、図１４の左側の原判定結果表示画面として表示される。原判定結果表示画面には、判定されたBに対応するグラフが表示される。図６のステップ１０で得られたB判定のデータを担当ユーザにより、AあるいはBとして再判定される（図６のステップ１１）。AあるいはCと再判定した理由を「再判定理由」（４０５）ボタンを押すことで、入力することができる。
【００７５】
図１４では、原判定結果Bに対し、担当ユーザがAとして再判定した場合を例として示した。担当ユーザの入力後の表示画面が手動入力後の画面として図１４の右側のように表示される（４０２）。
【００７６】
また、ユーザが再判定を行う際には、「判定変更画面表示」では、図１６に示すような担当ユーザ情報を入力し、ユーザの付加情報を付加することもできる。図３の３１の「判定とその理由・ユーザ情報を付加」の工程に対応づけられる。
【００７７】
図１６は、振り分け基準でBと判別されたものを、ユーザが判定する際に担当者情報を入力するユーザ情報表６００を示したものである。
【００７８】
左の列より、入力項目（作業開始日、作業終了日、担当チーム、氏名、性別などのユーザ情報を担当ユーザが右隣の「担当ユーザ入力」欄に入力する）、「担当ユーザ入力」欄、「入力項目から得られる情報」についての項目がある。担当ユーザは、左端の「入力項目」に沿って対応する項目を右隣の「担当ユーザ入力」欄に入力する。入力項目には、作業開始日、作業終了日、担当チーム、経験年数などの項目がある。
【００７９】
ユーザが作業ごとに毎回同じ情報を入力することは、ユーザに作業負担を強いてしまうため、決まった項目の入力作業はバーコード入力を導入することも可能である。
但し、入力項目の「AあるいはCを判断した理由」はユーザが入力することが必要であるため、その都度ユーザが各自入力する。 ユーザ情報表６００は、担当ユーザが入力後、図３の履歴データ２３に評価した画像データと共に格納される。
【００８０】
以上の入力結果等は、図１２、図１３、図１５に示すようなデータ構造を有するデータベースに格納される。
【００８１】
図１２は、図６のステップ１１でAと判定されたデータ構造を示す。判定Aのデータ表３００は、左の縦列から順にAと判定されたデータNo.（３０１）、プロジェクト名（３０２）、機能名（３０３）判定に用いられた画像データ（３０４）、判定結果（３０５）が格納される。３０４の画像データには、データNo. に対応する画像データ、およびA判定の基準のベースとなるラインが格納される。
【００８２】
画像データを詳細に確認したい場合には、「拡大表示」ボタン（３０６）を押し、画像データを拡大し、表示させることができる。
【００８３】
図１３は、図６のステップ１１でCと判定されたデータ構造を示す。判定Cのデータ表４００は、図１２の判定Aのデータ表３００と同様のデータ構造であるため、説明を省略する。
【００８４】
図１５は、図６のステップ１０でBと判定された結果のB判定のデータ構造を示したデータ表５００である。左の列より、データNo（５０１）、図６のステップ１０での判定結果（５０２）、プロジェクト名（５０３）、機能名（５０４）、判定に用いられた画像データ（５０５）担当ユーザによる手動入力の結果（５０６）をそれぞれ示す。
【００８５】
図２３は、ユーザがバグ曲線の他に追加情報が欲しい場合に、情報を追加し組み合せて表示できる具体例を示す。ここでは、消化残数テスト数を追加した場合を示す。ユーザが追加情報を組み合わせたい場合には、図１０の判定基準設定画面からテスト消化曲線を選択すると表示される。テスト消化曲線は縦軸に追加される。
【００８６】
１.３  [評価工程３の説明] 
図１７は図１６のユーザ情報の活用に関わる図である。
【００８７】
例えばチームごとでどのような差があるかなどを可視化することに利用することもできる。図１７ではY軸に品質、X軸に解析処理速度を示した例である。ここでは、チームの経験年数が影響し、品質と解析処理速度にも影響していることが分かり、例えば、００３チームの経験年数の低いチームは品質と解析処理速度ともに他のチームよりも劣っていることが分かる。００３チームに経験年数の高い人を増員するなど、作業の指針にもつながる。
【００８８】
図５のステップ４１のユーザ情報をもとにパラメータを抽出する際にも、図１７の可視化図を参照にし、ユーザのどの情報を取得しパラメータを抽出すれば良いかなども参考になる。図１７を参照すると、００１チームの再判定情報をもとにパラメータを抽出すると、より高品質な判定条件を設定することができる。
【００８９】
図５は、図３のパラメータ抽出手段２５の工程についてのフロー図を示した。
【００９０】
図３の品質評価手段２１の工程によって３領域（A,B,C）に判別された結果の内、B判定となった結果をユーザによってAあるいはC判定に再判定された結果をもとにパラメータを抽出する工程の詳細を示している。
【００９１】
パラメータを抽出する流れにはユーザ情報を利用するかしないかの２種類あり、ユーザ情報を利用しない際、ユーザが再判定した判定Aと判定Cのデータの全部の傾きを求めたい場合（ステップ４０）と、ユーザ情報を利用したい際、ユーザの取得情報をもとに判定Aおよび判定Cの傾きを求めたい 場合（ステップ４１）である。
【００９２】
（１）ユーザが再判定した判定Aと判定Cのデータの全部の傾きを求めたい場合（ステップ４０）は、ユーザが再判定した判定Aのデータを全て取得し（ステップ４２）、全判定Aのデータの傾きを求める（ステップ４３）。判定Aの傾きの平均値と標準偏差を求め（ステップ４４）、判定Aの傾きのパラメータとする（ステップ４５）。同様に再判定Cの傾きのパラメータを取得する（ステップ４６、４７、４８、４９）。判定Aおよび判定Cの傾きのパラメータを図３の２６の品質評価パラメータに格納する（ステップ５０）。３領域（A,B,C）に 判別において品質評価条件設定する際に上記パラメータを参照し、パラメータを更新する（ステップ５１）。
【００９３】
（２）ユーザの取得情報をもとに判定Aおよび判定Cの傾きを求めたい場合（ステップ４１）は、ユーザが入力したユーザ情報とユーザが再判定したA判定およびC判定の画像データが格納されている図３の２３の履歴データから、ユーザの経験年数に応じて傾きのパラメータを求めたいか（ステップ５３）、あるいはチーム別情報をもとにパラメータを取得したいか（ステップ５４）、あるいは過去のプロジェクト経験をもとにパラメータを取得したいか（ステップ５５）、などのユーザ情報をもとにパラメータを取得することが可能である。
【００９４】
例えば、図１６のユーザ情報の入力項目の経験年数欄に１０年、５年、１年と入力されており、その中で経験年数の高いユーザが再判定したパラメータを取得したい場合は、経験年数１０年のユーザの再判定情報から傾きのパラメータを取得することができる。
【００９５】
ユーザ情報をもとにA判定およびC判定のデータを取得し、傾きを求め、A判定およびC判定の傾きの平均値と標準偏差を求め（ステップ５６）、ユーザの情報をもとにしたパラメータを抽出する（ステップ５７）。抽出したパラメータを品質評価パラメータに格納し（ステップ５０）、３領域（A,B,C）に 判別において品質評価条件設定する際に上記パラメータを参照し、パラメータを更新する（ステップ５１）。
【実施例２】
【００９６】
評価工程３に関して本発明の第二の実施の形態を示す。第３の評価工程におけるカテゴリ属性に係る評価値や評価基準の更新において、予測モデルを構築する処理、特徴パターンを発見する処理、クラスタリングを行う処理のうち、単一あるいは複数の処理を含む形態として示す。これらは精度の面と、サンプル数が比較的少なくて済むという効率性の面で、カテゴリ属性の見積りや予測における利点を有する。数値属性向けに多用される平均値等の統計計算との併用も可能である。
【００９７】
以下の形態では、相関ルール分析を用いているが、カテゴリ属性を目的変数として扱うに適する手法として知られる判別分析等、他の分析手法を用いてもよい。
【００９８】
図２４、図２５において、各行がレコード１件に対応し、レコードの単位としては、
a  プロジェクト１件
b  プロジェクト内のチーム１件
c  反復開発スタイルのプロジェクトの一反復単位
等が該当しうる。各レコードには、プロジェクトの進行度（ここでは、一例として完了までの２５%、５０%、７５％、９０%時点）での或る属性に対する評価結果（評価値）が記録されている。
【００９９】
図２４、図２５は、各レコードの評価値として「良」、「悪」、あるいは、どちらともいえない（「グレー」）のカテゴリが記録されている状況を、示している。
【０１００】
図２４の各レコードの評価は、図１４の判定変更画面による原判定結果に相当するものである。ここで「良」「グレー」「悪」は各々、図１４の「A」「B」「C」に相当すると見なせる。
【０１０１】
図２５においても、図２４と同様に、「良」「グレー」「悪」は図１４の「A」「B」「C」に各々相当するが、図２５では、さらに、図１４の判定変更画面による再判定結果における「良」「悪」が併記されている。その読み方を図２５におけるレコードNo７の５０パーセント時点に対する記録内容である「グレー*良」を用いて説明すると次のようになる。「グレー*良」における「*」は、セパレータを意味する記号であり、この両側に２つの情報がつながれた書式で記録されている。左側は図１４の原判定結果に相当する評価値であり、それが「グレー」、右側は図１４の再判定結果に相当し、それが「良」、であることを各々意味している。また、再判定を実施しないことも本発明の趣旨を逸脱しない想定範囲内で想定可能であり、再判定未実施の場合は「*」の右側に「−」が記録されている。ここでは、原判定結果が「良」あるいは「悪」の場合は再判定を実施せず、「グレー」の場合のみ再判定を実施した状況を示している。
【０１０２】
さらに、図２４、図２５における「完了時点」の列には、各レコードに関わる評価対象となっているプロジェクト全体あるいはその一部が完了時点あるいは完了以降の状態が記録されている。
【０１０３】
たとえば、前記b,cのようなプロジェクト内部が一単位になっている場合には、プロジェクト内部の前記一単位が完了した段階での状態が記録されていてもよいし、プロジェクト全体（前記aに相当するスコープ）が完了した段階での状態が記録されてあってもよい。
【０１０４】
図２６、図２７は、図２４、図２５のデータセットからパターンを抽出した例示である。
【０１０５】
図２６は、図２４の情報からパターンを抽出した結果の一形態である。
【０１０６】
図２７は、図２５の情報からパターンを抽出した結果の一形態である。
【０１０７】
これらのパターンの抽出には相関ルール分析を用いている。supportやconfidenceは、相関ルールに係るパターンの選別を行う指標である。この値が大きいほど、頻出するパターンである。
【０１０８】
図２６、図２７では、confidence=１.０かつsupport ≧０.２５を満たすパターンのみを抽出している。 その上でconfidenceが第一優先のソート基準、supportが第二優先のソート基準でパターンがソートされた状態が示されている。
【０１０９】
以下、相関ルール分析、supportの定義、confidenceの定義を概説する（概説においては、加藤，羽室，他：「データマイニングとその応用」，朝倉書店，２００８を参考にした）。
【０１１０】
相関ルールは、XとYとの関係性をルール化したものであり、「X⇒Y」によって与えられる。「XならばY」と読まれ、Xをルールの条件部、Yを結論部と呼ぶ。たとえば｛A,B｝⇒｛D｝は、「AとBが同時に共起するならば、Dも共起する」、ことを意味する。ここで、｛A,B｝はアイテム集合と呼ばれ、個々のAやBはアイテムと呼ばれる。
【０１１１】
ここで、supportは、相関ルールの支持度とも呼ばれる指標であり、次のように定式化される：support（｛A,B｝⇒｛D｝） = （{A,B,D}を含むトランザクション数）÷（全トランザクション数） 
条件部と結論部のアイテム集合が多くのトランザクション（レコード）に出現すれば、それらのアイテム集合の間の関連性が強いとするのが支持度の考え方である。
【０１１２】
次にconfidenceは、相関ルールの確信度とも呼ばれ、条件部Xのアイテム集合を含むトランザクション数に対するX∪Yを含むトランザクション数の割合を意味する指標であり、次のように定式化される：confidence （｛A,B｝⇒｛D｝） = （{A,B,D}を含むトランザクション数）÷（{A,B}を含むトランザクション数） 
これは、条件部のアイテムの出現を条件としたときの結論部のアイテムが出現する条件付き確率を意味する。
【０１１３】
相関ルール分析においては、最小支持度及び最小確信度を与えたとき、双方を満たす相関ルールが注目すべき相関ルールと解釈し、該当する相関ルールを抽出し列挙することが多い。
【０１１４】
なお、以下の説明では、「相関ルール」を「パターン」とも呼称する。
【０１１５】
図２６は、入力評価を含まないデータから抽出されたパターンであり、図２７は、入力評価を加えたデータから抽出されたパターンであるが、双方を比較すると、入力評価を加えたデータから抽出されたパターン（図２７）では、supportやconfidence に関わる条件（ここでは、confidence=１.０かつsupport ≧０.２５）を満たすパターンが追加されていることがわかる。パターン数の増加は、暗黙的な経験から抽出した経験則が増えたことを示すものと解釈できる。
【０１１６】
図２７のNo.９のパターンは、図２５のレコードNo.７，No.８の２件のレコードから発見されたパターンである。レコードNo.７，No.８とレコードNo.４の主要な違いは、５０パーセント時点での再判定結果に関わるものであり、双方には
・レコードNo.７，No.８：  ５０パーセント時点での再判定結果＝「良」
・レコードNo.４：  ５０パーセント時点での再判定結果＝「悪」
という差分が存在する。
【０１１７】
以下、図２７に抽出されたパターンを用いて、基準を変更する形態を示す。
ここでは、「良」「悪」は、組織ルール等として個別プロジェクトの状況不問で規定された、全プロジェクトが守るべき領域である。一方で、その中間領域「グレー」の判断は、プロジェクトの個別事情を反映しやすく、「良」「悪」の予測精度が悪い傾向がみられるといった状況設定を想定する。
【０１１８】
そして、最新のプロジェクトの評価において、「グレー」から、「良」「悪」に再振り分けを行う為の基準変更を行う状況を想定する。
【０１１９】
図２８は、図２４の「良」「悪」「グレー」の３つの領域に振り分ける際に参照された或る属性（指標）の評価値である（評価値は測定値等であってもよい）。図には図２４のすべてのレコードではなく、レコードNo.４, No.７， No.８が抜粋されている。また、各時点に対する「良」「悪」の領域境界の定義値も例示されている。
【０１２０】
これらの評価値は、成長曲線の各時点の座標値でもよいし、各時点の変化量を示す値でもよい。成長曲線の例としては、バグの累積件数や残課題数の時系列推移等が想定しうる。
【０１２１】
図２９は、図２８の表をグラフとしてプロットした図である。レコードNo.４, No.７， No.８のすべての点において「良」領域と「悪」領域の間の中間領域（＝「グレー」）に位置する状態が可視化されている。
【０１２２】
この状態で基準の変更の一形態は次のように実施される。
【０１２３】
この形態では、パターンNo.９に該当するレコードの中の最大値を線分として接続し、その線分を領域間の新たな境界として設定する。具体的には、パターンに該当するレコードNo.７，No.８及び「良」領域の境界（上限）の期間１と期間２の値を比較し各期間の最大値を特定し（ここでは、期間１の最大が「良」領域の境界（上限）の値、期間２の最大がレコードNo.８の値）、それらを接続する。そして、その結果得られる線分を「良」領域と「グレー」領域との間の新たな境界として設定する。
【０１２４】
図２９、図３０ともに斜線部分の領域が前記「グレー」領域であり、図３０に変更後の新たな境界と領域の所在が示されている。図３０では、図２９に比べ、「グレー」領域が縮小していることが確認できる。
【０１２５】
なお、図３０において、パターンNo.９が言及しない期間３と期間４は、従来の境界を維持した状態となっている。すなわち、図３０における図２９からの変更区間は、期間１と期間２の間の境界だけである。そして、その新しい境界を規定する線分と、変更前から維持されている期間３と期間４の境界を規定する線分との間を、直線で接続することで、「良」領域と「グレー」領域との間の線引きを行っている。
【０１２６】
評価工程３で変更された基準に従い、評価済みのプロジェクトを再評価することも本発明の趣旨を逸脱しない範囲で実施可能である。そのフローを図（図９）とともに説明する。ここでは、変更された基準線が「悪」下限（C判定）の傾きの２分の１が「悪」（C判定）と「良」（A判定）の境界になった場合の状況で示す。図３０の説明で言及した「グレー」領域の縮小がさらに強化された結果「グレー」領域は消滅したものとなっており、図９は、基準変更前に図６のステップ１１で分類された「グレー」判定（B判定）を、基準変更後にAかCに評価しなおすフローとして示されている。
【０１２７】
まず、図６のステップ１０で分類されたBのデータの中からデータを１つ取得する（ステップ１２１）。取得したデータをB１とする。
【０１２８】
取得したBのデータB１に対し、判定基準M、および上限値として設定したC判定の傾きk１と比較、照合する（ステップ１２２）。
【０１２９】
取得したBのデータB１がC判定の傾きk１の２分の１よりも小さいかを確認し（ステップ１２３）、２分の１よりも小さい場合は、判定を「A」とする（ステップ１２４）。それ以外は「C」と判定する（ステップ１２５）。分類されたBの全データを「A」、あるいは「C」の２領域に判定し終えたら終了する（ステップ１２６）。
【符号の説明】
【０１３０】
１００…ＣＰＵ、１０１…外部記憶装置、１０２…可搬型記憶媒体、１０４…読取装置、１０５…入出力装置、１０６…通信装置。
【図１】
2015014856.tif 000003
【図２】
2015014856.tif 000004
【図３】
2015014856.tif 000005
【図４】
2015014856.tif 000006
【図５】
2015014856.tif 000007
【図６】
2015014856.tif 000008
【図７】
2015014856.tif 000009
【図８】
2015014856.tif 000010
【図９】
2015014856.tif 000011
【図１０】
2015014856.tif 000012
【図１１】
2015014856.tif 000013
【図１２】
2015014856.tif 000014
【図１３】
2015014856.tif 000015
【図１４】
2015014856.tif 000016
【図１５】
2015014856.tif 000017
【図１６】
2015014856.tif 000018
【図１７】
2015014856.tif 000019
【図１８】
2015014856.tif 000020
【図１９】
2015014856.tif 000021
【図２０】
2015014856.tif 000022
【図２１】
2015014856.tif 000023
【図２２】
2015014856.tif 000024
【図２３】
2015014856.tif 000025
【図２４】
2015014856.tif 000026
【図２５】
2015014856.tif 000027
【図２６】
2015014856.tif 000028
【図２７】
2015014856.tif 000029
【図２８】
2015014856.tif 000030
【図２９】
2015014856.tif 000031
【図３０】
2015014856.tif 000032