(57)【要約】【課題】プロジェクト計画および見積もりの精度を向上可能なプロジェクト管理システムを得ること。【解決手段】仕様書体系内の開発要素および依存関係を改訂すべき指示を検出した場合に、変更がなされた開発要素または依存関係に対応させて仕様構造情報ＤＢ３を更新し、その操作内容を出力する構造改訂処理部１と、仕様構造情報ＤＢ３におけるリソース情報を更新し、その操作内容を出力する情報改訂処理部２と、仕様書体系内の開発要素と開発要素間の依存関係，およびリソース情報を蓄積するための仕様構造情報ＤＢ３と、構造改訂処理部１による操作内容および情報改訂処理部２による操作内容を含む仕様構造改訂履歴データを作成し、当該仕様構造改訂履歴データを仕様構造改訂履歴ＤＢ５に格納する履歴記録部４と、仕様構造改訂履歴データを蓄積するための仕様構造改訂履歴記憶部５と、を備える。【選択図】図１
2010266934.tif 000002
【特許請求の範囲】
【請求項１】
仕様書体系内の開発要素名、開発要素の識別子、および開発要素の設計または検証を行うために必要なリソースを特定する情報であるリソース情報の対応関係と、前記開発要素間の依存関係の種類、依存関係にある開発要素の識別子、およびリソース情報の対応関係と、をデータとして蓄積するための仕様構造情報記憶手段と、
反映させるべき仕様書体系データである投入データを添付した、仕様書体系内の開発要素および依存関係を改訂すべき指示である改訂指示、を検出した場合に、当該投入データおよび前記仕様構造情報記憶手段が保持するデータを比較して、変更がなされた開発要素または依存関係に対応する前記仕様構造情報記憶手段内のデータを更新し、当該仕様構造情報記憶手段に対して行った操作内容である構造処理結果データを出力する構造改訂処理手段と、
前記構造改訂処理手段により検出された改訂指示に基づいて、前記仕様構造情報記憶手段内のデータにおける前記リソース情報を更新し、当該仕様構造情報記憶手段に対して行った操作内容である情報処理結果データを出力する情報改訂処理手段と、
前記構造改訂処理手段による操作内容、および前記情報改訂処理手段による操作内容を含む仕様構造改訂履歴データを蓄積するための仕様構造改訂履歴記憶手段と、
前記構造処理結果データおよび前記情報処理結果データに基づいて、前記仕様構造改訂履歴データを作成し、当該仕様構造改訂履歴データを前記仕様構造改訂履歴記憶手段に格納する履歴記録手段と、
を備えることを特徴とするプロジェクト管理システム。
【請求項２】
前記仕様構造情報記憶手段には、さらに、仕様構造が改訂された日時と改訂版の識別子である版識別子とを対応付ける版管理情報を保持することとし、
さらに、
工程および見積もりを出力すべき旨の指示であってかつ対象とする版識別子および開発要素が指定された指示である工程見積もり出力指示を検出した場合に、前記仕様構造情報記憶手段から当該版識別子に該当する仕様構造情報データを読み出し、前記仕様構造改訂履歴記憶手段から仕様構造改訂履歴データを読み出し、読み出した各データに基づいて任意の時点における仕様書体系の構造である再現仕様構造データを生成する構成管理手段と、
開発要素間の依存関係から構成される依存関係のパスを示すデータである開発依存関係パスデータを蓄積するための開発依存関係パス記憶手段と、
前記構成管理手段にて生成された再現仕様構造データに基づいて開発依存関係パスデータを作成し、当該開発依存関係パスデータを前記開発依存関係パス記憶手段に保存する開発依存関係抽出手段と、
前記工程見積もり出力指示において指定される開発要素をキーに、前記構成管理手段にて生成された再現仕様構造データから当該開発要素が含まれるデータを抽出し、開発要素の依存関係において依存する開発要素が依存される開発要素より時間的に後になるように開発要素を線形に並べた木構造を作成し、また、前記仕様構造情報記憶手段から当該開発要素をキーにリソース情報を読み出し、当該リソース情報を当該木構造に関連付け、当該リソース情報に対応する重み付けを行った工程データを出力する工程出力手段と、
前記工程見積もり出力指示において指定される開発要素をキーに前記再現仕様構造データから当該開発要素が含まれるデータを抽出し、開発要素の依存関係において依存する開発要素が依存される開発要素より時間的に後になるように開発要素を線形に並べた木構造を作成し、また、前記仕様構造情報記憶手段から当該開発要素をキーにリソース情報を読み出し、当該リソース情報を当該木構造に関連付け、当該リソース情報に基づいて、当該木構造に対応させて、当該開発要素ごとの見積もりまたは当該見積もりの総和を出力する見積もり出力手段と、
を備えることを特徴とする請求項１に記載のプロジェクト管理システム。
【請求項３】
さらに、
改訂があった開発要素間の依存関係のパターンを示すデータである開発依存関係パターンデータを蓄積するための開発依存関係パターン記憶手段と、
最適な工程および見積もりを出力すべき旨の最適出力指示を検出した場合に、前記開発依存関係パス記憶手段から、所定の条件に沿ったレコードを抽出してリソース情報を付加した開発依存関係パターンデータを作成し、当該開発依存関係パターンデータを前記開発依存関係パターン記憶手段に保存する開発依存関係パターン抽出手段と、
前記工程出力手段から工程データを受け取り、前記見積もり出力手段から開発要素ごとの見積もりを受け取った場合に、当該工程データの各工程に見積もりを対応付け、前記開発依存関係パターン記憶手段から開発依存関係パターンデータを読み出し、当該工程データの木構造において、当該開発依存関係パターンデータにて依存関係の始点である開発要素から終点である開発要素までが含まれる箇所を検索し、当該箇所について、前記開発依存関係パターン記憶手段に保存された開発依存関係パターンデータに付加されたリソース情報に基づいて見積もりを決定し、当該工程データの工程に対応付けられた見積もりと比較して少ない方の見積もりを有する工程を採用し、その結果を最適な工程データとして出力する最適工程出力手段と、
前記見積もり出力手段からの見積もりデータを受け取ると、前記開発依存関係パターン記憶手段から開発依存関係パターンデータを読み出し、当該見積もりデータにおける木構造において、当該開発依存関係パターンデータにて依存関係の始点である開発要素から終点である開発要素までが含まれる箇所を検索し、当該箇所について、前記開発依存関係パターン記憶手段に保存された開発依存関係パターンデータに付加されたリソース情報に基づいて見積もりを決定し、前記木構造に対応付けられた見積もりと比較して少ない方の見積もりを採用し、その結果を最適な見積もりデータとして出力する最適見積もり出力手段と、
を備えることを特徴とする請求項２に記載のプロジェクト管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、製品開発についてのプロジェクト管理を行うプロジェクト管理システムに関する。
【背景技術】
【０００２】
従来、ソフトウェア開発においてプロジェクト計画（スコープ、制約条件、ＷＢＳ、品質計画、検証計画）を行うにあたっては、工数を見積もるための様々な方法が提案されており、たとえば、下記特許文献１では、以下のような見積もり方法が提案されている。まず、画面上のコントロールを実装する際のソフトウェアの開発に要する工数を特定可能とする見積用コントロールを定義する。そして、見積対象のソフトウェアがディスプレイに表示する画面上のコントロールに対してユーザが割り付けた、見積用コントロールに基づいて、ソフトウェアの開発工数を見積もる。
【０００３】
一般には、プロジェクトの管理者は、見積もりにあたって以前のプロジェクトのプロジェクト計画，全体の実績工数，不具合の数、などを参考にする。また、プロジェクト計画を行う部門、または業界標準におけるプロジェクト計画のテンプレートを使用することが多い。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１６４３１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来の技術によれば、特定の箇所の変更，モジュールの追加開発，不具合修正、といった作業について工程計画や見積もりを行う場合にも、標準工程や平均値を参考にすることとなる。したがって、これによりプロジェクト計画を策定した場合には、工程に含まれる項目，実施の順番などが実態と合わない、という問題があった。また、同様に見積もりを行った場合には、工程に含まれる項目，全体の規模，工数，残存不具合数などが実態と合わない、という問題があった。
【０００６】
本発明は、上記に鑑みてなされたものであって、プロジェクト計画および見積もりの精度を向上可能なプロジェクト管理システムを得ることを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明は、仕様書体系内の開発要素名、開発要素の識別子、および開発要素の設計または検証を行うために必要なリソースを特定する情報であるリソース情報の対応関係と、前記開発要素間の依存関係の種類、依存関係にある開発要素の識別子、およびリソース情報の対応関係と、をデータとして蓄積するための仕様構造情報記憶手段と、反映させるべき仕様書体系データである投入データを添付した、仕様書体系内の開発要素および依存関係を改訂すべき指示である改訂指示、を検出した場合に、当該投入データおよび前記仕様構造情報記憶手段が保持するデータを比較して、変更がなされた開発要素または依存関係に対応する前記仕様構造情報記憶手段内のデータを更新し、当該仕様構造情報記憶手段に対して行った操作内容である構造処理結果データを出力する構造改訂処理手段と、前記構造改訂処理手段により検出された改訂指示に基づいて、前記仕様構造情報記憶手段内のデータにおける前記リソース情報を更新し、当該仕様構造情報記憶手段に対して行った操作内容である情報処理結果データを出力する情報改訂処理手段と、前記構造改訂処理手段による操作内容、および前記情報改訂処理手段による操作内容を含む仕様構造改訂履歴データを蓄積するための仕様構造改訂履歴記憶手段と、前記構造処理結果データおよび前記情報処理結果データに基づいて、前記仕様構造改訂履歴データを作成し、当該仕様構造改訂履歴データを前記仕様構造改訂履歴記憶手段に格納する履歴記録手段と、を備えることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、改訂の状況を把握し、履歴を辿ることができることになり、プロジェクト計画を実行するための情報を抽出しやすくなる、という効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施の形態におけるプロジェクト管理システムの構成例を示す図である。
【図２】図２は、仕様構造情報ＤＢ内の仕様構造データの構成例を示す図である。
【図３】図３は、仕様構造データを説明するための模式図である。
【図４】図４は、仕様構造改訂履歴ＤＢが保持するデータ構造の一例を示す図である。
【図５】図５は、再現仕様構造データの構成例を示す図である。
【図６】図６は、開発依存関係パスデータの構成例を示す図である。
【図７】図７は、開発依存関係パスデータを説明するための模式図である。
【図８】図８は、実施の形態２におけるプロジェクト管理システムの構成例を示す図である。
【図９】図９は、開発依存関係パターンデータの構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下に、本発明にかかるプロジェクト管理システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１１】
実施の形態１．
図１は、本実施の形態におけるプロジェクト管理システムの構成例を示す図である。図１のプロジェクト管理システムは、構造改訂処理部１と、情報改訂処理部２と、仕様構造情報ＤＢ３と、履歴記録部４と、仕様構造改訂履歴ＤＢ５と、構成管理部６と、開発依存関係抽出部７と、開発依存関係パスＤＢ８と、工程出力部９と、リソース見積もり出力部１０とを備える。
【００１２】
構造改訂処理部１は、ユーザなどの操作により、仕様書体系内の開発要素を改訂（追加、削除、修正）すべき指示（改訂指示）を検出すると、「開発要素」または「依存関係」の変更をチェックし、仕様構造情報ＤＢ３内の仕様構造データ（後述）を更新する。情報改訂処理部２は、構造改訂処理部１からの指示により、仕様構造情報ＤＢ３内の仕様構造データにおけるリソース情報（またはリソース情報へのリンク）を更新する。仕様構造情報ＤＢ３は、仕様書体系内の仕様書やソースコード階層内の開発要素の情報を管理し、また、開発要素間の依存関係を管理する仕様構造データ（詳細後述）を保持する。履歴記録部４は、仕様書体系内の開発要素が改訂された場合に、構造改訂処理部１および情報改訂処理部２の操作内容に基づいて、仕様構造改訂履歴データを作成し、当該仕様構造改訂履歴データを仕様構造改訂履歴ＤＢ５に格納する。仕様構造改訂履歴５は、構造改訂処理部１による操作内容および、情報改訂処理部２による操作内容を備える仕様構造改訂履歴データを蓄積する。
【００１３】
構成管理部６は、仕様構造情報ＤＢ３および仕様構造改訂履歴ＤＢ５からデータを読み出し、任意の時点における仕様書体系の構造（以下、「再現仕様構造データ」ともいう）を再現する。開発依存関係抽出部７は、開発（追加、流用、不具合改修）により仕様書体系の開発要素が改訂された際に、改訂された開発要素を含めた依存関係をたどり、開発要素間の依存関係の連鎖（パス）を示すデータである開発依存関係パスデータを作成し、当該データを開発依存関係パスＤＢ８に記録する。開発依存関係パスＤＢ８は、開発依存関係パスデータを蓄積する。
【００１４】
工程出力部９は、構成管理部６からの出力である再現仕様構造データに基づいて、指定される開発要素の工程を算出する。リソース見積もり出力部１０は、同様に、構成管理部６からの出力である再現仕様構造データに基づいて、指定される開発要素の見積もりを算出する。
【００１５】
ここで、依存関係とは、開発要素（項目，記述，関数，データ（変数，定数など））と、その開発要素が影響を与える対象または影響を与えられる対象となる開発要素との、関係の種類を示す情報である。関係の種類とは、たとえば、「ＡはＢを参照する」，「ＡはＢを呼び出す」，「ＡはＢを変更する」，「ＡはＢを実装する」，「Ａを改訂するとＢに影響がある」といった、依存のパターンを示す情報である。また、リソース情報とは、開発要素について設計または検証を行うために必要なリソースを特定する情報である。具体的には、工数，（出力帳表などの）ページ数，（プログラムソースの）ライン数，前回リリース以降報告された不具合の数、といった、規模や品質を表す指標などの情報である。以下では、一例として、リソース情報は「工数」の値であるとする。
【００１６】
図２は、仕様構造情報ＤＢ３内の仕様構造データの構成例を示す図である。図２の仕様構造データは、たとえば、「レコードＩＤ」，「日時」，「開発要素／依存関係の種類」，「開発要素ＩＤ（１）」，「開発要素名」，「開発要素ＩＤ（２）」，「リソース情報（リソース情報リンク）」などの項目を備える。「レコードＩＤ」は、レコードの識別子である。「日時」は、たとえば、プロジェクト管理システムが処理を開始した時点のシステム時刻であって、仕様構造データの版管理（詳細後述）をするために用いる。「開発要素／依存関係の種類」は、開発要素の種類（機能，関数，変数など）または、上述の依存関係の種類である。開発要素を登録するエントリの場合、開発要素ＩＤ（１）に開発要素として「機能Ｆ１」などのＩＤがセットされる。依存関係を登録するエントリの場合、開発要素ＩＤ（１）および（２）には、たとえば、依存関係がある開発要素として、それぞれ「機能Ｆ１」，「パラメータＰ１」などのＩＤがセットされる。「開発要素名」には、開発要素ＩＤ（１）に入る開発要素の名称，たとえば、上記「機能Ｆ１」などが入る。また、「リソース情報（リソース情報リンク）」は、上述同様である。「リソース情報」は、実際の値ではなく、不具合管理ツールや工程管理ツール（いずれも図示せず）など、リソースが保持される参照先へのリンクでもよい。
【００１７】
図３は、仕様構造データを説明するための模式図である。図３の例では、仕様書階層（その１）である＜仕様＞と、仕様書階層（その２）である＜ソースコード＞とにより、仕様書体系が構成される場合を説明する。たとえば、図３の仕様書階層その１において、機能Ｆ１は、パラメータＰ１を参照する。この場合、機能Ｆ１とパラメータＰ１について、仕様構造データに登録されるエントリは、「開発要素である機能Ｆ１」，「開発要素であるパラメータＰ１」，および「機能Ｆ１がパラメータＰ１を参照するという依存関係」、である。また、機能Ｆ２は、パラメータＰ１およびＰ３を参照する。したがって、この場合、仕様構造データに登録されるエントリは、パラメータＰ１が既に登録されていたとすれば、「開発要素である機能Ｆ２」，「開発要素であるパラメータＰ３」，「機能Ｆ２がパラメータＰ１を参照するという依存関係」，「機能Ｆ２がパラメータＰ３を参照するという依存関係」、である。なお、依存関係を登録する場合の開発要素ＩＤ（１）と開発要素ＩＤ（２）は１対１であるとし、機能Ｆ２がパラメータＰ１およびＰ３を参照する関係は、同一のエントリでは登録しない。
【００１８】
また、図３に示すように、＜仕様＞は、＜関数呼び出し階層＞と＜大域変数・データ構造＞とを備える。ここで、＜関数呼び出し階層＞は、関数を階層的に管理するイメージである。たとえば、図３には、＜仕様＞の機能Ｆ１と、＜関数呼び出し階層＞における関数ｆ１との間に依存関係が示されるが、当該依存関係は、「機能Ｆ１は、関数ｆ１として具体化される」（または、機能Ｆ１は、関数ｆ１に対応する）といった関係である。一方、＜大域変数・データ構造＞は、変数やデータを管理するイメージである。たとえば、図３には、＜仕様＞のパラメータＰ１と、＜大域変数・データ構造＞における構造体Ｓ２との間に依存関係が示されるが、当該依存関係は、「パラメータＰ１は、構造体Ｓ２として具体化される」といった関係である。さらに、図３には、＜関数呼び出し階層＞の関数ｆ３−２と＜大域変数・データ構造＞のデータｄ２との間に依存関係が示されるが、当該依存関係は、たとえば、「関数ｆ３−２は、データｄ２を読み出す」および「関数ｆ３−２は、データｄ２を変更する」といった関係である。
【００１９】
ユーザは、これらの開発要素および依存関係を、ソフトウェア解析ツールなどを使用して仕様書体系から抽出し、図２の「開発要素／依存関係の種類」，「開発要素ＩＤ（１）」，「開発要素ＩＤ（２）」に該当する抽出結果を得て、当該抽出結果に図２の「リソース情報（リソース情報リンク）」に該当する情報を付加し、プロジェクト管理システムへの反映させるべき仕様書体系データである投入データを作成する。
【００２０】
具体的には、ソフトウェア解析ツールでは、たとえば、開発要素名「Ｆ１」，開発要素の種類が「機能」，「Ｆ１」の開発要素ＩＤ、といった情報が抽出される。また、開発要素名「ｆ１」，開発要素の種類が「関数」，「ｆ１」の開発要素ＩＤ、といった情報が抽出される。さらに、開発要素名「Ｆ１」は、開発要素名「ｆ１」を参照するという依存関係（依存関係の種類を特定）がある、といった情報が抽出される。ここで、たとえば、開発要素名「Ｆ１」が、単純に追加される開発要素である場合、仕様構造情報ＤＢ３への登録の際には、「開発要素／依存関係の種類」＝「関数」，「開発要素名」＝「Ｆ１」がセットされ、開発要素ＩＤが未採番であれば、開発要素ＩＤ（１）＝システムで決められた採番体系（詳細後述）に基づく識別子、がセットされることとなる。
【００２１】
そして、ユーザは、当該投入データを指定して、プロジェクト管理システムへのユーザインタフェースなどからの操作により、改訂内容をプロジェクト管理システムに反映させるために上述の改訂指示を出す。
【００２２】
つづいて、以上のように構成されたプロジェクト管理システムの動作について説明する。構造改訂処理部１は、上記の改訂指示を検出すると、投入データに含まれる「開発要素／依存関係の種類」，「開発要素ＩＤ（１）」および「開発要素ＩＤ（２）」に合致するエントリがあるかどうかチェックすることで、開発要素または依存関係に変更があるかどうかをチェックする。変更があった場合には、仕様構造情報ＤＢ３内の仕様構造データに対し、変更を反映させる。
【００２３】
たとえば、開発要素が追加された（仕様構造情報ＤＢ３内に当該開発要素が登録されていない）場合には、その開発要素に、上述の採番体系に則ってＩＤを付与してエントリを登録し、投入データ内でその開発要素の依存関係が含まれていれば、当該依存関係のエントリを「追加」する。具体的には、上述の例でいえば、図２の「開発要素／依存関係の種類」に投入データの「依存関係の種類」＝「参照する」を，「開発要素ＩＤ（１）」に開発要素「Ｆ１」のＩＤを，「開発要素ＩＤ（２）」に開発要素「ｆ１」のＩＤをセットする。なお、仕様構造情報ＤＢ３に新たなエントリを登録する場合、「日時」には、構造改訂処理部１が改訂指示を検出したときのシステム時刻を、プロジェクト管理システムが処理を開始した時刻としてセットする。
【００２４】
また、たとえば、開発要素が削除されている（仕様構造情報ＤＢ３内に当該開発要素が登録されるが、投入データにない）場合には、その開発要素のエントリを「削除」する。たとえば、改訂の内容が、モジュール名や関数名の変更である場合には、開発要素のエントリを「削除」および「追加」することとなる。また、依存関係が修正されている（仕様構造情報ＤＢ３内に、当該開発要素の依存関係が登録されているが、依存関係の種類または開発要素ＩＤ（２）が、投入データと異なる）場合には、依存関係のエントリを「修正」する。また、たとえば、投入データに新たな依存関係が含まれる場合には、当該依存関係のエントリを「追加」する。構造改訂処理部１は、投入データにかかる処理が完了すると、処理対象となったエントリについて、「開発要素／依存関係の種類」，「開発要素ＩＤ（１）」，「開発要素ＩＤ（２）」のデータと、仕様構造情報ＤＢ３に対する操作の種別（追加／削除／修正）とを、構造処理結果データとして履歴記録部４に出力する。また、処理が完了した旨を、情報改訂処理部２に通知する。
【００２５】
また、情報改訂処理部２は、構造改訂処理部１から上記通知を受けると、自身の処理を開始する。具体的には、投入データに含まれる「開発要素／依存関係の種類」，「開発要素ＩＤ（１）」および「開発要素ＩＤ（２）」に合致するエントリを、仕様構造情報ＤＢ３の仕様構造データから抽出し、当該エントリに紐付けられたリソース情報またはリソース情報へのリンクを改訂する。たとえば、新たに登録されたエントリについてリソース情報を入力する場合は、「追加」操作となる。また、既にリソース情報が入力されたエントリに、データ内容が異なるリソース情報を入力する場合は、「修正」操作となる。また、既にリソース情報が入力されたエントリに、データ内容がスペースであるリソース情報を入力する場合は、「削除」操作となる。情報改訂処理部２は、投入データにかかる処理が完了すると、処理対象となったエントリについて、「開発要素／依存関係の種類」，「開発要素ＩＤ（１）」，「開発要素ＩＤ（２）」のデータと、仕様構造情報ＤＢ３に対する操作の種別（追加／削除／修正）とを、情報処理結果データとして履歴記録部４に出力する。
【００２６】
履歴記録部４は、構造改訂処理部１から構造処理結果データを受けとり、情報改訂処理部２から情報処理結果データを受けとると、構造処理結果データおよび情報処理結果データから仕様構造改訂履歴データを作成し、当該仕様構造改訂履歴データを仕様構造改訂履歴ＤＢ５に登録する。
【００２７】
図４は、仕様構造改訂履歴ＤＢ５が保持するデータ構造の一例を示す図である。仕様構造改訂履歴ＤＢ５は、たとえば、「レコードＩＤ」，「日時」，「開発要素／依存関係の種類」，「構造改訂処理部の操作」，「情報改訂処理部の操作」，「ベースにした開発要素のＩＤ（複数）」などの項目を備える。「レコードＩＤ」は、レコードの識別子である。「日時」は、図２の同項目と同じである。「開発要素／依存関係の種類」は、上述同様である。「構造改訂処理部の操作」は、構造改訂処理部１の操作内容であって、「追加／削除／修正」が入る。「情報改訂処理部の操作」は、情報改訂処理部２の操作内容であって、「追加／削除／修正」が入る。「ベースにした開発要素のＩＤ（複数）」は、構造改訂処理部１から処理対象となったエントリについて通知される構造処理結果データ、に含まれる開発要素のＩＤである。「修正」操作の場合は、「開発要素ＩＤ（１）」および「開発要素ＩＤ（２）」の項目値である。「追加」操作の場合は、「開発要素ＩＤ（１）」のみとなる。「削除」操作の場合は、仕様構造情報ＤＢ３から削除したエントリの「開発要素ＩＤ（１）」である。
【００２８】
ここまでの処理により、仕様構造の改訂を仕様構造改訂履歴ＤＢ５に格納することができる。管理者などのユーザは、仕様構造改訂履歴ＤＢ５の仕様構造改訂履歴データを管理し参照することで、改訂の状況を把握し、履歴を辿ることができるので、プロジェクト計画を実行するための情報を抽出しやすくなる、という効果がある。
【００２９】
つづいて、構成管理部６の動作を説明する。構成管理部６は、たとえば、ユーザによる、工程および見積もりを算出すべき旨の指示である工程見積もり出力指示により起動して、処理を実行する。構成管理部６は、仕様構造情報ＤＢ３から仕様構造データを読み出し、また、仕様構造改訂履歴ＤＢ５から仕様構造改訂履歴データを読み出し、ある時点での仕様書体系の構造を再現して、再現した仕様構造データ（以下、「再現仕様構造データ」）を出力する。なお、ユーザは、既に述べた改訂指示を出す際に、まとめて工程見積もり出力指示を出してもよい。
【００３０】
本プロジェクト管理システムにおける履歴管理は、以下のような考え方に基づいて実施する。これにより、必要な時点の再現仕様構造データを生成することが可能である。
【００３１】
ここで、図２で示した全ての開発要素および依存関係に対する採番体系を説明する。各開発要素などは、版に関係なくフラットに識別子（ＩＤ）が振られ、さらに、たとえば末尾や冒頭に、版を示す情報が付加される。版を示す情報は、たとえば版番号である。ＩＤには、さらに作成日時を含めてもよい。
【００３２】
ところで、ユーザは、上述の工程見積もり出力指示を出すにあたり、版を指定する版指定情報を入力する。たとえば、改訂が行われない開発もあるので、特に指定がない場合は、１版，すなわち格納される全データを対象とした仕様を再現する指示と解釈できる。版の指定の仕方は、どのようでもよく、たとえば、版番号を指定する，最新版を指定する，最新の１つ前の版を指定する，日時を指定してそれ以前の最新版を要求する、などがある。
【００３３】
仕様構造情報ＤＢ３は、さらに、版番号と日時とを対応付けた版管理情報を保持する。上記の場合、構成管理部６は、工程見積もり出力指示を検知すると、当該工程見積もり出力指示に含まれる版指定情報を抽出し、仕様構造情報ＤＢ３が保持する版管理情報から、当該版指定情報に対応する版番号を取得する。そして、構成管理部６は、再現仕様構造データを生成するにあたり、当該版番号を用いる。
【００３４】
構成管理部６は、仕様構造改訂履歴ＤＢ５から、仕様構造改訂履歴データのうち、図４で示す「日時」が上記版番号に合致するエントリを読み出す。そして、これらのエントリに基づいて再現仕様構造データを生成する。図５は、再現仕様構造データの構成例を示す図である。図５のデータは、たとえば、「レコードＩＤ」，「ベースにした開発要素／依存関係のＩＤ」，「作成した開発要素／依存関係のＩＤ」，「日時その１」，「日時その２」、などを備える。「レコードＩＤ」は、レコードの識別子である。「ベースにした開発要素／依存関係のＩＤ」は、改訂にあたりベースとした開発要素などのＩＤである。「作成した開発要素／依存関係のＩＤ」は、改訂により作成された開発要素などのＩＤである。「日時その１」および「日時その２」は、図４の仕様構造改訂履歴データの「日時」である。
【００３５】
具体的には、構成管理部６は、読み出した仕様構造改訂履歴データの「構造処理改訂部の操作」を参照する。構造処理改訂部の操作が「追加」であった場合、「ベースにした開発要素／依存関係のＩＤ」にスペースを、「作成した開発要素／依存関係のＩＤ」に、仕様構造改訂履歴データの「ベースにした開発要素のＩＤ」をセットする。構造処理改訂部の操作が「削除」であった場合、「ベースにした開発要素／依存関係のＩＤ」に仕様構造改訂履歴データの「ベースにした開発要素のＩＤ」を、「作成した開発要素／依存関係のＩＤ」にスペースをセットする。構造処理改訂部の操作が「修正」であった場合、「ベースにした開発要素／依存関係のＩＤ」に仕様構造改訂履歴データの「ベースにした開発要素のＩＤ」のうち開発要素ＩＤ（１）に該当する値を、「作成した開発要素／依存関係のＩＤ」に仕様構造改訂履歴データの「ベースにした開発要素のＩＤ」のうち開発要素ＩＤ（２）に該当する値をセットする。
【００３６】
さらに、構成管理部６は、「ベースにした開発要素／依存関係のＩＤ」が「開発要素ＩＤ（１）」に合致するエントリを仕様構造情報ＤＢ３において検索し、当該エントリの「日時」を取得して、「日時その１」とする。また、構成管理部６は、「作成した開発要素／依存関係のＩＤ」が「開発要素ＩＤ（１）」に合致するエントリを仕様構造情報ＤＢ３において検索し、当該エントリの「日時」を取得して、「日時その２」とする。
【００３７】
構成管理部６は、このようにして、入力された版指定情報に該当する、再現仕様構造データを生成する。なお、本実施の形態では、版番号は識別のためにのみ用いるが、実質的には、開発要素間の版ごとの依存関係と、各開発要素の作成日時が必要である。したがって、版番号は、一意であればよく、ファイル管理用のフロントエンドプログラムなどで適宜定めてよい。
【００３８】
再現仕様構造データにより、開発要素間には、版毎に、以下に示す様々な依存関係が定まる。依存関係は、１：Ｎ（Ｎは１以上）である。改版を重ねると、版依存関係の組合せの連鎖が出来上がる。
【００３９】
たとえば、２版において、開発要素ＩＤ＃２が開発要素ＩＤ＃１を元に作成（改版）された場合には、「ベースにした開発要素／依存関係のＩＤ」が“ＩＤ＃１”，「日時その１」がＩＤ＃１の日時であり、さらに、「作成した開発要素／依存関係のＩＤ」が“ＩＤ＃２”，「日時その２」がＩＤ＃２の日時であるデータが生成される。さらに３版において、開発要素ＩＤ＃３が開発要素ＩＤ＃１を元に作成（改版）された場合には、「ベースにした開発要素／依存関係のＩＤ」が“ＩＤ＃１”，「作成した開発要素／依存関係のＩＤ」が“ＩＤ＃２”というデータが生成される。一方、たとえば、３版において、開発要素ＩＤ＃３が、開発要素ＩＤ＃１および開発要素ＩＤ＃２を元に作成（改版）された場合には、「ベースにした開発要素／依存関係のＩＤ」が“ＩＤ＃１”，「作成した開発要素／依存関係のＩＤ」が“ＩＤ＃３”というデータ、および「ベースにした開発要素／依存関係のＩＤ」が“ＩＤ＃２”，「作成した開発要素／依存関係のＩＤ」が“ＩＤ＃３”というデータが生成される。
【００４０】
構成管理部６の処理に戻り、構成管理部６は、上記のように作成した再現仕様構造データを、開発依存関係抽出部７、および工程出力部９とリソース見積もり出力部１０とに出力する。
【００４１】
つづいて、構成管理部６から再現仕様構造データを受信した開発依存関係抽出部７の処理を説明する。ユーザは、上記工程見積もり出力指示を出すにあたり、工程などを作成する対象とする開発要素を指定する。開発要素は、たとえば、機能名や関数名を特定する方法で指定可能である。
【００４２】
開発依存関係抽出部７は、指定された開発要素をキーに、仕様構造情報ＤＢ３から開発要素ＩＤ（図２の開発要素ＩＤ（１））を取得し、当該開発要素ＩＤを「ベースにした開発要素／依存関係のＩＤ」として図５の再現仕様構造データを検索する。そして、図５における「作成した開発要素／依存関係のＩＤ」を抽出する。さらに、抽出した「作成した開発要素／依存関係のＩＤ」をたどり、開発要素間を結ぶ依存関係のパス、すなわち依存関係の連鎖（パス）を把握する。そして、当該パスについて、依存関係ごとに、改訂がなされた開発要素間の依存関係を示す開発依存関係パスデータを作成し、当該開発依存関係パスデータを開発依存関係パスＤＢ８に保存する。当該開発依存関係パスデータを参照することで、改訂により影響があった依存関係の状況を把握することができる。
【００４３】
図６は、開発依存関係パスデータの構成例を示す図である。図６のデータは、「レコードＩＤ」，「開発要素ＩＤ」，「依存関係のある開発要素ＩＤ」（複数），「依存関係のＩＤ（種類）」，「依存関係の頻度」といった項目を備える。「レコードＩＤ」は、レコードの識別子である。「開発要素ＩＤ」は、たとえば、パスの始点となる開発要素（パス内の他の開発要素に影響を与える始点となる開発要素）のＩＤである。「依存関係のある開発要素ＩＤ」とは、パス内において、始点となる開発要素と依存関係のある開発要素のＩＤであって、複数登録できる。「依存関係ＩＤ（種類）」とは、パス内の依存関係のうちそのレコードＩＤで管理する依存関係のＩＤである。「依存関係の頻度」とは、当該レコードが示すパスにおいて、「開発要素ＩＤ」に該当する開発要素を改訂することで、影響があった依存関係の数、すなわち影響の発生頻度である。
【００４４】
図７は、開発依存関係パスデータを説明するための模式図である。図７に示すように、たとえば、機能Ｆ３が改訂された開発要素である場合、機能Ｆ３を始点とするパスとして、「関数ｆ３」〜「関数ｆ３−１および関数ｆ３−２」〜「データｄ２」、がある。この場合、機能Ｆ３の開発要素ＩＤを図６の「開発要素ＩＤ」とし、他の要素を「依存関係のある開発要素のＩＤ」（複数）に登録する。依存関係の種類には、「開発要素ＩＤ」である関数ｆ３からみた他の開発要素との依存関係の種類が入る。依存関係の種類が複数にある場合、同一パスについて複数の開発依存関係パスデータを作成する。
【００４５】
また、図７に示すように、たとえば、パラメータＰ３が改訂された開発要素である場合、「パラメータＰ３」〜「関数ｆ１−１」〜「関数ｆ１−１−１」〜「構造体Ｓ１」、というパスと、「パラメータＰ３」〜「データｄ１」というパスと、「パラメータＰ３」〜「構造体Ｓ１」というパスと、が存在する。この場合、パラメータＰ３の開発要素ＩＤを図６の「開発要素ＩＤ」とし、複数のパスについて、さらに依存関係の種類に応じて、パスごとに１以上の開発依存関係パスデータを作成する。
【００４６】
つづいて、構成管理部６から再現仕様構造データを受信した工程出力部９の処理を説明する。工程出力部９は、再現仕様構造データと、ユーザにより指定された開発要素（複数）とを入力として動作する。工程出力部９は、再現仕様構造データにおける開発要素間の依存関係をもとに、開発要素の木構造を作成する。木構造を作成にあたっては、依存する開発要素が依存される開発要素より時間的に後になるよう、開発要素を線形に並べる。また、工程出力部９は、仕様構造情報ＤＢ３から、各開発要素ＩＤをキーにリソース情報を読み出し、当該リソース情報に基づいて、開発要素にリソース情報（ここでは、工数）を関連付ける。そして、出力データとして、たとえば、開発要素を縦または横に並べて、開発要素に対応するリソース情報（工数）を並べた工程データを作成し、リソース情報（工数）に比例した重み付けをした結果を出力する。ここで、各開発要素にかかる作業スケジュールが「工程」となる。出力では、たとえば、出力帳票である工程表における欄や作業工程を示す線を、重み付けにしたがった長さに調節して出力する。
【００４７】
また、構成管理部６から再現仕様構造データを受信したリソース見積もり部１０の処理を説明する。リソース見積もり部１０は、再現仕様構造データと、ユーザにより指定された開発要素（複数）とを入力として動作する。リソース見積もり部１０は、再現仕様構造データにおける開発要素間の依存関係をもとに、上述同様に、開発要素の木構造を作成する。リソース見積もり部１０は、仕様構造情報ＤＢ３から開発要素ＩＤをキーにリソース情報（またはリソース情報リンク）を読み出し、当該リソース情報（工数）を、各開発要素に関連付ける。そして、開発要素ごとに見積もり（工数）を算出する。さらに、全ての見積もりを加算した総見積もり（全工数）を算出する。ここで、リソース情報に直接工数が指定されず、ソースコードのライン数，仕様書のページ数，残存不具合数、などが指定される場合には、これらを直接見積もりとするか、または、所定の規則で重み付けした工数を、見積もりとして算出する。また、工数を算出するだけでなく、残存不具合数などの情報をさらに算出し、工数に添えてもよい。リソース見積もり部１０は、このように算出した見積もりを、開発要素の木構造に対応させて出力する。また、たとえば、工程出力部９が出力する工程表などに添えて出力してもよい。
【００４８】
以上説明したように、本実施の形態では、工程計画策定および見積もり算出にあたって、開発要素についてのリソースの情報および依存関係を示す情報をデータベースに蓄積し、また、各開発要素の改訂履歴をデータベースに保存することとし、指定された改訂版の仕様構造情報データを再現して、工程および見積もりの算出に用いる構成とした。また、開発要素の依存関係に基づいて、直接関係する要素以外に必要となる設計，検証といった要素を網羅的に抽出し、工程の策定にあたっては、実態にあった各開発要素の順番を出力する構成とした。また、工程の各開発要素に関連付けられた情報（工数，ページ数，不具合数など）を用いて、実態にあった工程項目ごと、および全体工程の工数や、残存不具合数を出力する構成とした。
【００４９】
これにより、プロジェクト計画を実行し、また、管理するための情報を抽出しやすくなり、プロジェクト計画（スコープ，制約条件，ＷＢＳ，品質計画，検証計画）にかかる計画書の質を向上させ、また、見積りの精度を向上させることが可能となる。
【００５０】
実施の形態２．
実施の形態１では、改訂版の仕様構造情報データを再現し、開発要素のリソース情報および依存関係を示す情報を用いて工程策定および見積もり算出を実行することとした。本実施の形態では、改変が発生した依存関係のパターンを抽出し、当該依存関係のパターンを用いて、最適な工程策定および見積もり算出を実行する場合を説明する。
【００５１】
図８は、本実施の形態におけるプロジェクト管理システムの構成例を示す図である。図８のプロジェクト管理システムは、図１のプロジェクト管理システムと比較すると、さらに、開発依存関係パターン抽出部１１と、開発依存関係パターンＤＢ１２と、最適工程出力部１３と、最適リソース見積もり出力部１４と、を備える。
【００５２】
開発依存関係パターン抽出部１１は、開発依存関係パスＤＢ８から、所定の条件に沿ったレコードを抽出して、改訂があった開発要素間の依存関係のパターンを示すデータである開発依存関係パターンデータを作成し、開発依存関係パターンＤＢ１２に保存する。開発依存関係パターンＤＢ１２は、開発依存関係パターンデータを蓄積する。最適工程出力部１３は、工程出力部９の出力および、開発依存関係パターンＤＢ１２が保持するデータに基づいて、最適な工程を出力する。また、最適リソース見積もり出力部１４は、リソース見積もり出力部１０の出力および、開発依存関係パターンＤＢ１２が保持するデータに基づいて、最適な見積もりを算出し出力する。
【００５３】
図９は、開発依存関係パターンデータの構成例を示す図である。図９のデータは、「レコードＩＤ」，「開発要素ＩＤ」，「依存関係のある開発要素ＩＤ」（複数），「依存関係ＩＤ（種類）」，「リソース情報（リソース情報リンク）」といった項目を備える。「レコードＩＤ」は、レコードの識別子である。「開発要素のＩＤ」，「依存関係のある開発要素ＩＤ」（複数），「依存関係ＩＤ（種類）」は、図６と同じである。「リソース情報（リソース情報リンク）」は、この開発依存関係パターンを開発（検証，設計なども含む）するために必要なリソースの情報である。
【００５４】
つづいて、以上のように構成されたプロジェクト管理システムの動作を説明する。ユーザが、実施の形態１の処理実行後に、開発要素を指定して最適な工程および工数の出力を指示する最適出力指示が入力されると、これを検知した開発依存関係パターン抽出部１１は、開発依存関係パスＤＢ８のデータを読み出す。そして、所定の条件にしたがって、以下のようなデータを抽出する。なお、ユーザは、上述の工程見積もり出力指示とともに最適出力指示を出してもよい。
【００５５】
たとえば、仕様書階層の同レベル（機能，関数，構造体など）における開発要素一般について、「依存関係ＩＤ（種類）」が、「Ａを改訂したらＢに影響した」タイプであり、かつ、「依存関係の頻度」が所定の数以上であるデータを抽出する。この場合には、その仕様書階層の同レベルについて、開発要素の共通Ｉ／Ｆを洗練化することが必要である。
【００５６】
また、たとえば、仕様書階層の同レベルにおける開発要素一般について、変更が多いデータを抽出する。具体的には、たとえば、機能，関数，構造体、といった開発要素の種類ごとに、「依存関係の頻度」を積算し、所定数以上となる開発要素の種類（たとえば、「関数」など）があった場合には、同レベルにある開発要素（たとえば、関数など）を精査して共通部分を括り出し、ライブラリ化することが必要である。
【００５７】
また、たとえば、「依存関係ＩＤ（種類）」が、「Ａを改訂してＢに影響した」タイプの依存関係であり、かつ、「依存関係のある開発要素のＩＤ（複数）」に開発要素ＩＤが登録される（上記Ｂとして参照される）、といったデータが所定数以上である場合には、Ｂとなる開発要素について、他の開発要素とのＩ／Ｆの洗練化が必要である。
【００５８】
開発依存関係パターン抽出部１１は、上記のようなデータを抽出すると、開発要素の共通Ｉ／Ｆ洗練化，開発要素のライブラリ化，特定の開発要素におけるＩ／Ｆの洗練化、といった作業において、当該作業を設計／検証などするために必要なリソース情報、またはリソース情報へのリンクを取得する。リソース情報とする場合は、たとえば、作業に含まれる開発要素を「開発要素ＩＤ（１）」として、仕様構造情報ＤＢ３の該当するデータ内の「リソース情報」を読み出し、当該リソース情報の工数を加算して、加算結果を調整して取得する。たとえば、一括で開発することにより負荷が軽減されるので７掛けとする、などが考えられる。また、リソース情報へのリンクとする場合は、たとえば、工程管理ツール（図示せず）などから、仕様書階層，開発要素の種類，作業の種類などを指定してリンクを取得する。
【００５９】
そして、開発依存関係パターン抽出部１１は、開発依存関係パスＤＢ８のデータのうち、「開発要素ＩＤ」，「依存関係のある開発要素ＩＤ」（複数），「依存関係ＩＤ（種類）」と、当該「リソース情報」または「リソース情報へのリンク」とをセットした開発依存関係パターンデータを作成する。開発依存関係パターン抽出部１１は、当該開発依存関係パターンデータを開発依存関係パターンＤＢ１２に保存する。また、最適工程およびリソースを出力するよう、最適工程出力部１３および最適リソース見積もり出力部１４に通知する。
【００６０】
最適工程出力部１３は、開発依存関係パターン抽出部１１から指示を受けると、ユーザの最適出力指示において指定された開発要素（複数）を入力として動作する。最適工程出力部１３は、当該開発要素の開発要素ＩＤをキーに、開発依存関係パターンＤＢ１２から「開発要素ＩＤ」および「依存関係のある開発要素ＩＤ」（複数）と、「リソース情報」とを取得する。リソース情報へのリンクが登録されている場合には、当該リンク先からリソース情報を取得する。
【００６１】
最適工程出力部１３は、指定された開発要素（複数）について、工程出力部９から通知される工程、およびリソース見積もり部１０から通知される見積もりを対にする。そして、開発依存関係パターンＤＢ１２から取得したデータを用いて、最適な工程を得るための処理を行う。
【００６２】
たとえば、工程出力部９が出力する工程において、開発要素Ａについての作業の後に、開発要素Ｂの作業、つづいて開発要素Ｃの作業が、並べられて出力された場合を考える。こうした場合に、たとえば、開発要素Ｂの工数が、「２人日」であり、開発要素Ｃの工数が、「３人日」であったとする。この場合、開発要素ＢおよびＣの工程が終了するまでに、５日かかる。一方、開発要素Ａ，ＢおよびＣが、仕様書階層の同レベルにある開発要素（たとえば、関数など）であって、ライブラリ化が必要であると判断され、開発依存関係パターンＤＢ１２に登録されているとする。ここで、開発依存関係パターンデータのリソース情報、すなわち、ライブラリ化に必要な工数が、「４人日」だったとする。この場合、開発要素ＢとＣについて個別に作業を行うことに比べ、ライブラリ化の作業を行う場合、工数が「１人日」削減できることとなる。
【００６３】
具体的には、最適工程出力部１３は、工程および見積もりの対のなかから、開発依存関係パターンＤＢ１２から取得した「開発要素のＩＤ」を始点とし、「依存関係のある開発要素のＩＤ」（複数）を終点とする箇所を検索する。そして、当該箇所について、開発依存関係パターンＤＢ１２の「リソース情報」に基づいて見積もりを算出し、当該見積もりと、リソース見積もり部１０から取得した見積もりとを比較し、少ない方の見積もりを有する工程を採用する。このような処理を、開発依存関係パターンＤＢ１２から取得した全てのデータを用いて行う。そして、工程および見積もりの全ての対を、リソースが最も小さくなるように作成し直し、当該工程を最適な工程として出力する。
【００６４】
最適リソース見積もり出力部１４は、開発依存関係パターン抽出部１１から指示を受けると、ユーザの最適出力指示において指定された開発要素（複数）を入力として動作する。最適リソース見積もり出力部１４は、当該開発要素の開発要素ＩＤをキーに、開発依存関係パターンＤＢ１２から「開発要素のＩＤ」および「依存関係のある開発要素のＩＤ」（複数）と、「リソース情報」とを取得する。リソース情報へのリンクが登録されている場合には、当該リンク先からリソース情報を取得する。
【００６５】
また、最適リソース見積もり出力部１４は、指定された開発要素（複数）について、リソース見積もり出力部１０から通知される、開発要素の作業ごとの見積もりを取得する。そして、最適リソース見積もり出力部１４は、開発依存関係パターンＤＢ１２から取得したデータを用いて、最適な見積もりを得るための処理を行う。
【００６６】
具体的には、最適リソース見積もり出力部１４は、上述同様、開発要素の作業ごとの見積もりのなかから、開発依存関係パターンＤＢ１２から取得した「開発要素ＩＤ」を上流の作業とし、「依存関係のある開発要素ＩＤ」（複数）を下流の作業とする箇所を検索する。そして、当該箇所について、開発依存関係パターンＤＢ１２の「リソース情報」に基づいて見積もりを決定し、当該見積もりと、リソース見積もり部１０から取得した見積もりとを比較し、少ない方の見積もりを採用する。このような処理を、開発依存関係パターンＤＢ１２から取得した全てのデータを用いて行う。そして、開発要素の作業ごとのリソース見積もりを、見積もりが最も小さくなるように作成し直し、当該リソース見積もりを最適なリソース見積もりとして出力する。
【００６７】
以上説明したように、本実施の形態では、工程計画策定および見積もり算出にあたって、改訂がなされた開発要素間の依存関係を示す開発依存関係パスデータから、改訂があった開発要素間の依存関係のパターンを示す開発依存関係パターンデータを作成し、通常通りに得られた工程およびリソース見積もりを、開発依存関係パターンデータを用いて最適な工程およびリソース見積もりに最適化する構成とした。
【００６８】
これにより、実施の形態１の効果に加えて、プロジェクト計画を実行するにあたって、工程やリソース見積もりの精度をさらに向上させることが可能となる。
【産業上の利用可能性】
【００６９】
以上のように、本発明にかかるプロジェクト管理システムは、プロジェクト計画を策定する場合に有用であり、特に、工程および見積もりを策定する場合に適している。
【符号の説明】
【００７０】
１  構造改訂処理部
２  情報改訂処理部
３  仕様構造情報ＤＢ
４  履歴記録部
５  仕様構造改訂履歴ＤＢ
６  構成管理部
７  開発依存関係抽出部
８  開発依存関係パスＤＢ
９  工程出力部
１０  リソース見積もり出力部
１１  開発依存関係パターン抽出部
１２  開発依存関係パターンＤＢ
１３  最適工程出力部
１４  最適リソース見積もり出力部
【図１】
2010266934.tif 000003
【図２】
2010266934.tif 000004
【図３】
2010266934.tif 000005
【図４】
2010266934.tif 000006
【図５】
2010266934.tif 000007
【図６】
2010266934.tif 000008
【図７】
2010266934.tif 000009
【図８】
2010266934.tif 000010
【図９】
2010266934.tif 000011