"ソフトウェア開発の成果物の依存関係を評価するソフトウェア開発成果物間の依存関係評価装置であって、前記ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも1つの成果物を指定する手段と、記憶装置に記憶された成果物対応づけ表を参照して、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を取得する手段と、前記指定された成果物と、前記上下流工程の他の複数の成果物間の、依存関係の複雑さを評価する手段とを備えていることを特徴とするソフトウェア開発成果物間の依存関係評価装置。請求項1において、前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、顧客要求もしくは機能と、実装情報との間の依存関係の複雑さであることを特徴とするソフトウェア開発成果物間の依存関係評価装置。請求項1において、前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、要求開発工程の成果物、設計工程の成果物、実装工程の成果物、試験工程の成果物のうち、任意の複数工程の成果物に定義されている記述項目相互の依存関係の複雑さであることを特徴とするソフトウェア開発成果物間の依存関係評価装置。請求項1において、前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、前記複数の成果物を構成する要素である、要求仕様、機能仕様、ソースコードに記述された関数等のモジュール、または試験工程のテスト項目のうちの、何れか複数の成果物間の依存関係の複雑さであることを特徴とするソフトウェア開発成果物間の依存関係評価装置。請求項1において、前記依存関係の複雑さを評価する手段が、連結成分ないしはクリーク等のネットワーク分析における測定対象における構成要素間の関係構造を評価する指標により、前記依存関係の複雑さを評価することを特徴とするソフトウェア開発成果物間の依存関係評価装置。請求項1において、前記依存関係の複雑さを評価する手段が、成果物の構成要素群を周囲から分離することが容易であるか否かを示す分離容易性に関わる指標で前記依存関係の複雑さを評価し、前記指標には、モジュール化の程度や容易さを評価する指標を含めることが可能であることを特徴とするソフトウェア開発成果物間の依存関係評価装置。請求項1において、前記1つの成果物を指定する入出力装置と、前記成果物対応づけ表を参照して前記成果物間の対応づけ情報を取得するための成果物間対応づけ情報取得部と、前記成果物対応づけ表を参照して前記成果物内の解析情報を取得する成果物解析情報取得部と、前記成果物間対応づけ情報と、前記成果物内解析情報とを対応づけて成果物間依存関係統合表を生成する照合統合部と、前記成果物間依存関係統合表を基に前記複数の成果物間の、依存関係の複雑さを評価する依存関係分析評価部と、前記評価結果を表示する評価結果表示部とを備えていることを特徴とするソフトウェア開発成果物間の依存関係評価装置。ソフトウェア開発の成果物の依存関係をコンピュータに行わせるソフトウェア開発成果物間の依存関係評価方法であって、前記ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも1つの成果物を指定するステップと、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を、前記コンピュータの記憶装置に記憶された成果物対応づけ表を参照して、取得するステップと、前記指定された成果物と、前記上下流工程の他の複数の成果物間の、依存関係の複雑さを評価するステップとを含むことを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項8において、前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、顧客要求もしくは機能と、実装情報との間の依存関係の複雑さであることを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項8において、前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、要求開発工程の成果物、設計工程の成果物、実装工程の成果物、試験工程の成果物のうち、任意の複数工程の成果物に定義されている記述項目相互の依存関係の複雑さであることを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項8において、前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、前記複数の成果物を構成する要素である、要求仕様、機能仕様、ソースコードに記述された関数等のモジュール、または試験工程のテスト項目のうちの、何れか複数の成果物間の依存関係の複雑さであることを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項8において、前記依存関係の複雑さを評価するステップが、連結成分ないしはクリーク等のネットワーク分析における測定対象における構成要素間の関係構造を評価する指標で実行されることを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項8において、前記依存関係の複雑さを評価するステップが、成果物の構成要素群を周囲から分離することが容易であるか否かを示す分離容易性に関わる指標で実行され、前記指標にはモジュール化の程度や容易さを評価する指標を含めることが可能であることを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項8において、前記存関係の複雑さの評価結果に基づき、分離容易性に関わる前記依存関係の複雑さを示す情報を表示画面に表示するステップを有することを特徴とするソフトウェア開発成果物間の依存関係評価方法。請求項14において、前記存関係の複雑さの評価結果に基づき、前記上下流工程にかかわる複数の成果物を、分離が容易な単位で分離して前記表示画面に表示することを特徴とするソフトウェア開発成果物間の依存関係評価方法。近年、ハードウェア価格低下とハードウェアの機能の向上にともない、ソフトウェアシステムは年々大規模化、複雑化している。ソフトウェアシステムの大規模化により、ソフトウェアの構築や保守にかかるコストが増大し、多くの労力が必要となる。保守開発等のチームの作業人員数も増える傾向にある。そのため、開発保守や改造作業において、作業分担の妥当性は開発の成否を左右する要素となっている。しかし、どの範囲の既存資産で区切って既存資産を分離して、解析や改修といった作業分担を行うかの判断は容易でない。たとえば、複数の作業者に作業分担を行う際に分担した作業対象物開発工程の成果物同士の依存関係が強いと、作業者間の変更の競合が発生したり、分担を超えた複数領域が原因となった不具合が発生し解析に手間取ったり等、品質面および作業コストの面での問題が生じやすい。したがって分業を効率的効果的に推進するためには、依存性が低い分離容易な単位分離単位、あるいは分担範囲と称するを抽出することが求められる。すなわち、その分離単位で分離した場合に、分離される部分集合内部が緊密な依存関係を有していても、部分集合の外部との依存関係が最小化された状態になることが望ましい。そして、同一工程の成果物の依存関係だけでなく、上下流の工程の成果物間を例えば機能と実装とを紐づけた状態で依存関係が可視化されること、そして依存関係を最小化し分離することが望まれる状況も少なくない。機能単位での反復型開発やセル生産方式のような形態では、機能単位に割り当てられた開発作業者が下流工程もあわせて担当する状況も多く、効率的効果的な機能別の分業の促進が期待されるからである。また、上下流の工程の成果物間を例えば機能と実装とを紐づけた状態で依存関係を可視化した情報は、作業分担の指針とする以外にも、見積り工数等の見積り及び開発に要した工数や日数開発実績の計測に有効である。工程で分業し下流工程になると別の会社の別の担当者が担当するような開発体制であっても、上流工程の段階で開発工程全体を通じた見積りや、上下流の作業分担を超えた見積りは必要であるし、紐づく実装も含めた機能間の依存関係の複雑さが、品質面および作業コストの面での前記問題の発生可能性やその大きさに影響し見積りを左右する要素となるからである。さらに、その依存関係を低減し、分離できれば、ある開発の所要日数や工数等の開発実績の計測や、関連する別の開発ある開発に対する派生開発等の見積りが行いやすくなる。実績値の計測や見積りは開発作業全体に対してだけ行うとは限らず、機能単位や作業分担単位といった形で範囲を区切った部分についても行われるが、その場合に、相互に依存関係の少ない分離単位ごとに、開発実績の計測や見積りを実施することで、データの妥当性の向上が期待できる。規模の面では、ソースコードモジュール間の依存性が高いと、各モジュール関数規模をどの機能に帰属させるかの判断が難しく、見積り根拠としての妥当性が曖昧になりがちであるが、依存関係を分離できていれば、各モジュール関数規模の帰属を明確にしやすい。また、工数面でも、特定の機能の開発に関するトラブルで、その他の機能の開発に悪影響が及び工数的な停滞を受けると、待ち時間を除いた実質的な所要工数を、特定しにくいが、あらかじめ依存関係を分離してあれば、開発工数や所要日数を、分離された範囲ごとに対応づけやすくなり算定値の精度も向上させやすい。上記各特許文献に記載の従来の技術は、複数工程の成果物の間の依存関係の有無を可視化する方法を提供する技術であるか、あるいは、プログラム内部等の特定の成果物の内部の依存関係を把握して影響の質的側面を評価する技術である。これら従来の技術は、同じレベルの工程、例えばソースプログラム間の関係を評価するものであって、上下流の異なる工程、例えば製品の外部仕様や機能と実装、あるいは、その他の上下流の工程も含めた依存関係の複雑さを扱うものではない。このような上下流の複数工程の成果物間例えば製品の外部仕様と実装、あるいは機能と実装の絡みあいの複雑さの評価や依存関係の複雑性の低減させるような作業分担の指針に対しては、これらの従来技術では配慮されていない。従来の技術により、上下流の複数工程の成果物の間の依存関係の状態を人間が把握して、適切な分離単位依存関係が弱く相互に分離が容易な分離範囲を探し出そうとすると、分析者の労力や分析に要する時間を多く費やしてしまう。機能と実装をまたがって依存関係の状態を分析者ユーザが自ら把握することは、機能と実装の双方への深い理解が必要になるため、開発の規模と複雑さの拡大に伴い、一層難しくなっている。本発明の課題は、ソフトウェア開発の上下流の工程にかかわる複数の成果物間の依存関係の検出における上記従来技術の問題点を解決し、分析者ユーザに分析の目的に応じた精度の検出情報を、例えば機能と実装の双方の依存関係情報をもとに、機械的な処理により自動的に求め、双方の依存関係の状態を効率よく提示することができる、ソフトウェア開発成果物間の依存関係評価装置及び評価方法を提供することにある。いいかえると、本発明の課題は、上下流の関係にある複数の工程の成果物にまたがった分析結果から、相対的に独立した構成要素群モジュールの集合体を見出すこと、上下流の関係にある複数の工程の成果物を俯瞰したスコープでモジュール化独立に設計開発されうる半自律的なサブシステムに分解する操作の指針を見出すこと、と表現できる。さらに、構成する要素の数と各要素間の関係の強さでシステムの複雑性が決まると考えると、本発明の課題は、構成要素を適切にグルーピングする指針、グループ間のインターフェースの数を減らし相互作用を弱め、複雑性を下げる指針を提示することであるともいえる。本発明の代表的なものの一例によれば、依存関係評価装置は、ソフトウェア開発の成果物の依存関係を評価するソフトウェア開発成果物間の依存関係評価装置であって、前記ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも1つの成果物を指定する手段と、記憶装置に記憶された成果物対応づけ表を参照して、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を取得する手段と、前記指定された成果物と、前記上下流工程の他の複数の成果物間の、依存関係の複雑さを評価する手段とを備えていることを特徴とする。本発明によれば、ソフトウェアの既存資産に関して開発の上下流の工程にかかわる複数の成果物について、分離容易性の観点で必要な情報を機械的な処理により探しやすくし、分析者ユーザの労力を軽減し、分析に要する時間を短縮できる。また、分離容易性に関わる依存関係の複雑さを示す情報をユーザに図や表として可視化し提供することにより、各ユーザは、ソフトウェアの開発に関して、効率的に作業分担指針を抽出できるようになる。あるいは開発工数などの見積りを行いやすくなる。本発明の代表的な実施例によれば、ソフトウェア開発の過程でうみだされる上下流の各工程の成果物の評価方法であって、成果物の依存関係の程度を評価する依存関係分析評価部を備えている成果物の評価方法であり、依存関係状態解析部が、ソフトウェア開発における上下流の複数の工程の成果物同士の間の依存関係の状態を評価することを特徴とする。この依存関係の状態とは、単に影響の有無だけではなく、依存関係の複雑さ、たとえば絡みあいの多寡等、に関わるものとする。各工程の成果物としては、ソースコードの記述されたファイル全体、仕様書や設計書といったドキュメントなどを広範に含むものとし、さらには、その内部に含まれている、個々のモジュール、個々の仕様項目、個々の設計事項の単位を成果物と見なすことも可能とする。本発明では、分析の目的に応じて、上下流の複数の工程の成果物の対応づけを示す情報とともに、双方の間の依存関係の状態を算出する。依存関係の状態は、開発で得られた成果物の構成要素群を周囲から分離することが容易であるか否かを示す分離容易性を評価し改善指針を得るために測定するものである。本発明では、依存関係が強く絡み合いが複雑な部分を境界にした分離は困難であり、そうでないと分離が容易であるものとして見なす。複数の工程の成果物とは、典型的には上流の機能に関わる情報個々の機能項目や顧客要求項目と下流の実装単位ソースコードにおける関数などのモジュールソフトウェアの構成部品であり、双方を対応づけるとは、この場合、工程の面で上下流の関係にある機能と実装との間の関係性を明らかにすることを意味する。上下流の関係にある機能と実装とを関連付けて評価し、特にそれらの間の依存関係の関係性の複雑さ、たとえば、絡みあいの程度に関わる情報を、分析の目的に応じて加工し分析者に情報提供する。また、複数の条件指標で依存関係を評価し、評価条件の相違を反映した複数の異なる検出結果を比較参照することで、分析の目的に応じた評価結果に関わる情報の選別に活用する。以下、本発明の実施の形態を、図面を参照して説明する。本発明における第一の実施の形態を、図1A乃至図11Bを参照しながら説明する。[システム構成]まず、本発明によるソフトウェア開発成果物の依存関係の評価方法を実施するのに適した、ソフトウェア開発成果物間の依存関係評価装置のシステム構成例を、図1A、図1Bを参照しながら説明する。本発明のソフトウェア開発成果物間の依存関係評価装置は、ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも1つの成果物を指定する手段と、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を、記憶装置に記憶された成果物対応づけ表を参照して、取得する手段と、前記指定された成果物と、前記上下流工程の他の単一あるいは複数の成果物との間の、依存関係の複雑さを評価する手段とを備えている。本発明のソフトウェア開発成果物間の依存関係評価装置は、図1Aに示すような一般的なコンピュータ上で、ソフトウェア開発の成果物の依存関係の分析をコンピュータに行わせることにより、実現される。すなわち、開発成果物の依存関係評価装置は、CPU演算処理装置100と主記憶部101と、HDD等の外部記憶装置102と、CDROMやDVDROM等の可搬性を有する可搬型記憶媒体103から情報を読み出す読取装置104と、ディスプレイ表示装置やキーボードやマウス等の入出力装置105と、通信ネットワークに接続するためのNICNetworkInterfaceCard等の通信装置106と、バス107とを備えた一般的なコンピュータ上で、ソフトウェア開発成果物間の依存関係評価プログラムを実行することで実現される。このコンピュータプログラムは、単体のコンピュータ上で実行されるように構成しても良く、あるいは、また、サーバとこのサーバにネットワークを介して接続された少なくとも1つのコンピュータとで実行されるように構成しても良い。また、入出力装置は、ユーザインターフェース機能を有するディスプレイ表示装置のように、入出力機能の一部が、一体的に構成されたものであっても良く、あるいはまた、入力装置と出力装置が独立して構成されたものであっても良い。次に、本実施形態に係る開発成果物分析手段の構成について説明する。図1Bは、本実施形態に係る依存関係の評価を行う、ソフトウェア開発成果物間の依存関係評価装置の機能ブロック図である。ソフトウェア開発成果物間の依存関係評価装置は、外部記憶装置部102と主記憶装置部101を備えている。外部記憶装置部102は、開発成果物格納部3Aと、分析関連情報格納部3Bを備える。発成果物格納部3Aには、依存関係の評価を行うソースコードなど、分析に必要な開発成果物が格納される。分析関連情報格納部3Bには、開発成果物の依存関係の解析を行う場合に利用可能な外部ツールの情報など、本実施形態の実施に必要な分析関連情報が格納されている。また、以下で説明する、成果物対応づけ表図5参照、成果物解析結果表図8A,図8B参照、及び、成果物間対応づけ情報統合表図10A,図10B参照等も格納される。主記憶装置部101は、コンピュータプログラムを保有しており、このプログラムに基づく所定の処理手順をCPUで実行することにより得られる機能ユニットとして、成果物対応づけ情報取得部5、成果物解析情報取得部6、照合統合部7、依存関係分析評価部8、評価結果表示部9を備える。主記憶装置部101は、さらに、成果物対応づけ情報取得部5及び成果物解析情報取得部6で処理するためのデータを取得し、成果物対応づけ表として記憶装置に保持する成果物前処理部4を備えている。本発明のソフトウェア開発の具体的な対象物としては、例えば、自動車制御システム、テレビ、情報処理機器等の組み込みシステムが挙げられる。本発明では、ソフトウェア開発の成果物の依存関係の分析をコンピュータに行わせるために、上流工程から下流工程にかかわる複数工程の成果物の間の対応関係を示すテーブル成果物対応づけ表を用い、前記対応関係を参照して、複数の前記成果物間の依存関係の複雑さを評価する。すなわち、入出力装置を介してユーザから与えられた、上流工程から下流工程にかかわる任意の階層の少なくとも1つの前記成果物をキーにして、他の工程の成果物との依存関係を解析する。成果物対応づけ表は、例えば事前にユーザが各工程の成果物の情報を収集してテーブル化、それをコンピュータの記憶装置に保持する。照合統合部7は、成果物対応づけ表を参照して、成果物対応づけ情報取得部5、および成果物解析情報取得部6で得られた結果を照合統合を行う。依存関係分析評価部8は、照合統合部7で処理した結果をもとにユーザの目的に応じ、上流工程から下流工程にかかわる成果物間の依存関係を分析し、評価する。評価結果表示部9は、評価部8で評価した結果を、ユーザにわかりやすく可視化し表示する。ここで、本発明における上流工程、下流工程の概念を、図2の例で説明する。本発明における上流工程、下流工程は、ソフトウェア開発の成果物の抽象度と言い換えることもできる。上流工程は、例えば自然言語等を使用した文書や図形など、一般の人が理解できる形で表現された、組み込みシステム等に対する要求や仕様を生成する工程を指す。上流工程で得られる成果物にも、漠然とした概念のレベルや、詳細な仕様書等のような具体化されたレベルがある。ここでは、顧客の要求概念を分析し抽出する工程を上流工程1、その要求を実現するための具体的な機能仕様書、設計情報、カタログ項目等を作成する工程を上流工程2、と定義する。そして、上流工程1の成果物が、顧客の要求概念を列挙し明確化した文書であり、上流工程2の成果物が、要求を実現するための具体的な機能仕様書、設計情報、カタログ項目等である、というように、工程とその成果物は対応づけられる。次に、下流工程は、コンピュータを用いて上流工程の要求仕様を実現するためのソースコード等の実装、換言するとコンピュータ言語で表現され一般の人が容易には理解できない形式で表現されたものを生成する工程を指す。そして、下流工程の成果物は、ソースコード等の実装である、として、工程とその成果物が対応づけられる。なお、上流と下流の区切りは、これに固定したものではなく、上と下の関係は、相対的なものである。たとえば、ソースコードの実装工程は下流として前述したが、試験工程に対しては相対的に上流の工程、として位置づけられることが一般的である。次に、図3に、本発明の第一の実施形態における、開発成果物分析処理の全体のフローの概念図を示す。まず、ソフトウェア開発の上下流工程の複数の成果物から、キーとなる1つもしくは複数の成果物を指定するステップ10。次に、ソフトウェア開発の上下流工程の複数の成果物間の対応づけ情報を、成果物対応づけ表を参照して、取得するステップ11。最後に、上記指定された成果物と、上下流工程の関係にある他の複数の成果物間の、依存関係の複雑さを分析評価するステップ12。なお、先に全ての成果物を対象にステップ11、12を実行してから、ステップ10に相当する1つもしくは複数の成果物を指定し、指定された成果物と他の成果物との依存関係の複雑さを分析し、評価するようにしても良い。次に、図4に、本発明における、成果物間の依存関係の例を示す。例えば、上流工程1の顧客の要求概念が、車の乗り心地が良いであった場合を想定する。車の乗り心地を改善するためのより具体的なレベルの解決策上流工程2には、さまざまな観点のアプローチが考えられる。例えば、加速性に優れていること、振動が少ないこと、騒音が少ないこと、空調が快適であること、等々が挙げられる。車の乗り心地を良くするために加速性を改善すべく、例えば、エンジンのトルク特性を変更することを想定する。この場合、エンジンのトルク特性の変更を実現するための、同じ工程階層の機能あるいは仕様として、点火系統S1、燃料系統S2、吸排気系統S3、電源系統S4等が相互に何らかの依存関係があると考えられる。また、上流工程2おいて、エンジンのトルク特性の変更は、エンジン出力の影響を受ける駆動機構制御、車体制御、起動発電制御、室内機器空調制御等にも影響を及ぼすと考えられる。従って、加速性を改善するためにエンジンの点火系統、燃料系統、吸排気系統、電源系統に変更を加えることは、駆動機構制御、車体制御、起動発電制御、室内機器空調制御との間、例えば空調機制御Sm、にも何らかの影響を与える、という依存関係の複雑さが考えられる。エンジンのトルク特性の変更は、エンジンを制御するプログラム、すなわち、下流工程の複数のソースコードに影響を与える。例えば、吸入空気量検出モジュールf1、エンジン回転数検出モジュールf2、点火時期制御モジュールf3、燃料噴射制御モジュールf4、電源制御モジュールf5等、さらには空調機制御を行うソースコードfn、が相互に何らかの依存関係がある。同様に、騒音を低減するために駆動機構制御に変更を加えることを想定すると、それは、エンジン制御、車体制御、起動発電制御、室内機器空調制御との間にも何らかの影響を与える、という依存関係が考えられる。そして、さらに、これらの依存関係は、ソースコード下流工程にも影響を与える、という複雑さがある。このように、上流工程1の車の乗り心地改善という成果物、あるいは上流工程2の点火系統、―、―という成果物と、下流工程の成果物である各ソースコードとの間には、複数の成果物が相互に絡み合う依存関係の複雑さが存在する可能性がある。従って、例えば、自動車の組み込みシステムのソフトウェア開発の開発保守や改造作業に従事する担当者を想定した場合、その担当者は、上下流工程のどの単位で既存資産の解析を行い、他の関係者との作業分担をどのように行うかについての適切な情報が得られることが望ましい。このような、複数の成果物間で相互に絡み合った上下流工程の成果物間の依存関係の複雑さを明らかにするために、本発明では、まず、成果物対応づけ表が作成され、コンピュータの記憶装置に記憶される。図5に、成果物対応づけ表250の一例を示す。この成果物対応づけ表250は、成果物対応づけ情報をテーブル化したものである。成果物対応づけ表250は、関数名欄251と仕様書項目名欄252とで構成されている。この表は、ソースコード等の実装、例えばモジュール関数が、どの機能や仕様に対応するかを示している。すなわち、1行目は、下流工程の関数f1が、上流工程の仕様S1を実現するモジュールであることを示している。逆に、上流工程の仕様をベースにして、対応する下流工程の関数を記載しても良い。なお、図5の関数名f、仕様書項目名Sの具体例は、図4の例に直接対応するものではなく、あくまでも記載の一例を示すものである。この成果物対応づけ表250は、ユーザが本システム構成の外部で作成した情報を入力してもよいし、公知の技術を用いてこの段階で生成してもよい。また、仕様書項目名欄252は、章番号等の仕様書の記載箇所を示すID情報であってもよい。なお、成果物対応づけ表250は、上下流工程の対応関係の情報が、情報の取得可能な範囲でテーブル化されていれば良い。上記した、複数の成果物が相互に複雑に絡み合った上下流工程の依存関係を考慮する必要は全くない。例えば、図4の例では、上流工程1の車の乗り心地に対する上流工程2の各成果物、例えば成果物S1~S4、及び、これらの成果物、例えばS2に対応する下流工程の成果物f1~f2、f4~f5が、情報の取得可能な範囲で順次記録されていれば良い。図6は、第一の実施の形態の全体の処理の流れを示したフローチャートである。まず、最初に、開発成果物分析手段では、ユーザにより選定された少なくとも2つのプログラムソースコードや設計文書などを文字コード変換など前処理するステップ100。そして、この結果に基づいて、成果物間対応づけ情報取得ステップ103と成果物内解析情報取得ステップ104とを実施する。双方は並列的に実施することが可能である。図7は、ステップ103の処理により、図5の対応づけ情報と同義の情報を、ノードとノードをつなぐリンクで表現した、成果物間対応づけ情報の図である。ノードが、個々の関数と個々の仕様項目に相当し、リンクがこれらの対応づけを示している。次に、この並列的な処理フローで得られた成果物間対応づけ情報と成果物内解析情報とが、対応付けられ、統合されるステップ106。なお、ステップ106の詳細については、後で説明する。この対応付け統合した結果を基に、成果物間の依存関係解析を行うステップ107。そして、ユーザの目的に応じて、成果物依存性解析結果の評価をするステップ108。さらに、評価した結果を可視化した結果として出力するステップ109。図8Aに示す成果物解析情報の表500は、図6のStep104の成果物内依存関係取得の測定結果の一例を示したものである。成果物解析情報の表500は、関数名欄501Aと、呼び出し関数名欄502Aとを備える。各行に一つの関数情報が格納される。関数名欄501Aは、縦列にファイルの格納先とファイル名を示したパス名等が格納されでもよい。呼び出し関数名欄502Aは、ソースコードには、いくつもの機能を実現するために大量の関数が定義されているが、関数名欄501Aの関数と呼び出し関係を有する関数名が記述されている。呼び出し関係を有する関数としては、関数名501A欄の関数を呼び出す関数と、関数名501A欄の関数に呼び出される関数、とに分類できるが、図8Aの呼び出し関数名欄502Aでは、両方が記述されている。図8Aの情報をもとにすると、コールグラフを作成できる。関数同士がどのような呼ばれ方をしているのかをグラフで示した物がコールグラフであり、その典型的な例が、出力画面に表示された図11Aの分析評価結果のf1~f8までのグラフである。なお、図中に入力されている関数名は一例である。関数の呼び出し関係の抽出、及び呼び出し関係の情報に基づくコールグラフ構築においては、分析関連情報格納部3Bに格納された開発成果物の依存関係の解析に適用可能な外部ツールを利用することが想定される。図9Aは、成果物対応づけ情報の結果に成果物解析情報の結果を統合する流れ図6のStep106を、詳細に示したフローチャートである。まず、検出した成果物対応づけ情報に示す結果と成果物解析情報に示す結果の情報が、開発成果物分析手段に入力されるステップS201A。次に、開発成果物分析手段において、成果物対応づけ情報の結果の1行目の関数名と、成果物解析情報の結果の1行目の関数間依存関係の測定対象の関数名を比較する。すなわち、成果物対応づけ情報結果の1行目の関数名と、成果物解析情報結果の1行目の関数名を比較するステップS204A。比較した関数名が同じかどうか確認しステップS205A、関数名が同じである場合、成果物対応づけ情報結果の右端の列に同じ関数名の呼び出し関数名を追加するステップS206A。成果物対応づけ情報結果の1行目に同じ関数名が無い場合は、成果物解析情報結果の関数名を一つ下の行へ移動しステップS210A、同じ関数名があるか確認しステップS211A、同じ関数名があるところの関数グループIDを成果物対応づけ情報結果の右端に追加するステップS212A。次に、成果物対応づけ情報結果の関数名を一つ下の行に移動するステップS207A。同様にステップS205A、ステップS206A、ステップS210、AステップS211A、ステップS212Aを繰り返し行い、成果物対応づけ情報結果の関数名を全部確認するステップS208A。最後に成果物対応づけ情報結果に呼び出し関数名を追加した結果を出力するステップS209A。この出力が、図10Aの、同じ関数名を手がかりにして成果物間対応づけ情報と成果物内解析情報を統合した表600に相当する。表600は、関数名欄601Aと、仕様書階層名602Aと、呼び出し関数名欄603Aとを備える。次に、図10Aの成果物間対応づけ情報結果と成果物間の対応づけ情報、成果物対応づけ情報を統合した表600をもとに、図6のメインフローのStep107及びStep108に相当する上下流の工程にかかわる複数の成果物間の依存性解析及び評価が実施され、その結果が、例えば、図11Aに示すような分離可否の形式で出力画面に表示される。上下流の工程にかかわる複数の成果物間の依存性解析及び評価について、図5の成果物対応づけ情報をもとに、分離容易な形態をユーザに提供する例で、作用効果を説明する。分離容易な形態の抽出には、ネットワーク分析と称される複雑ネットワーク分析とも称されるさまざまな対象における構成要素間の関係構造を探る手法に関する分析手法と分析ツールが利用可能である。依存関係分析評価部によってネットワーク分析ツールが呼び出され依存関係分析が実施されるのが、典型的な実施の形態である。ネットワーク分析とは、さまざまな対象を点と線からなるネットワークグラフとして表現し、その構造的な特徴を探る分析方法である。グラフの点は、ノード構成要素を示す点、線はリンク構成要素同士のつながりを示す線等とも呼ばれ、ノード構成要素同士の関係が一定以上の強さを有する場合にノード同士がリンクで結ばれる。関係が有るか無いかの二者択一をリンクの有無に代表させてもよい。その典型的な例が、出力画面に表示された図11Aの分析評価結果のf1~f8までのグラフである。図11Aのグラフでは、ソースコードが有する関数f1~f8をソースコードの構成要素ノードとみなし、呼び出す側の関数と呼ばれる側の関数が、相互に呼び出し関係を有すると定義し、リンクで結んでいる。そして、さらに、関数f1~f8と仕様S1~S4との対応づけをリンクで結んでいる。ネットワーク分析では、与えられたグラフの状態を分析評価する手法であり、次のような情報を抽出する。個別のノードについて、周囲のノードとの間の影響範囲の広さや強さを示すネットワーク指標たとえば次数や到達度、媒介度、結束度を算出する。ネットワークからサブグラフサブグループを抽出する。サブグループとは、その内部で他と区別できるような形で相互に結びついた集団ノードとリンクで構成される部分集合このような公知のネットワーク分析の手法を用いることで、分離容易な形態の抽出が実現できる。図11Aにおいては、連結成分をネットワーク分析によってサブグループとして抽出し、そのサブグループを分離容易な単位として出力画面に提示した様子が示されている。連結成分とは、ネットワーク内部がいくつかの部分がリンクで接続されずに分離している場合に、分離している各々の部分サブグラフを意味する。公知のネットワーク分析ツールでは、連結成分以外にも、クリーク3個以上のノードの集合において、集合内のノード全てが互いにリンクし合っているような高密度な部分集合やコミュニティクリークに限らず、構造的にサブグラフ内のノード間のリンク密度が相対的にサブグラフ外へのリンク密度よりも高いという特徴により規定されるネットワークの部分集合といったネットワーク分析の分野で知られた各種の指標や操作でサブグループを抽出することが可能であり、本発明でも利用可能である。連結成分という概念によるサブグループの識別指針は、リンクが分離していないネットワークには適用できないという欠点を有するが、連結成分以外の指標等を利用することで、連結しているグラフの内部で相対的に密度の高い部分を抽出することも可能である。たとえば、分割されたコミュニティ内のリンク辺の数とコミュニティ間の辺の数の比較により、高密度のサブグループコミュニティをうまく抽出しているかを示す指標としてネットワーク分析の指標ではモジュラリティが知られており、この指標で分離単位分離範囲を決める手法も、本発明の趣旨を逸脱しない範囲で適用可能である。以上のネットワーク分析複雑ネットワーク分析に関しては、非特許文献1、非特許文献2の引用を以って詳細な説明に代える。なお、ネットワーク分析におけるモジュラリティはモジュール化の程度を判別する指標の一つであると見なせる。モジュール化モジュラー化はネットワーク分析に関わらず広く使われている概念であり、概ね、独立に設計開発されうる半自律的なサブシステムに分解する操作や分解された状態がモジュール化と呼ばれる。モジュール化の程度や容易さを判別することが本発明の主旨であり、ネットワーク分析におけるモジュラリティは判別する指標の一例にすぎない。したがってネットワーク分析以外の指標で判別しても本発明の主旨を逸脱するものではない。図5及び図7には、仕様に対応づく情報を有する外部参照可能な関数のみが記述されている。一見すると、仕様S2~S4は相互に分離が容易なように見える。しかし、実際には、その他にも、仕様とは明示的に対応づけが管理されていないような内部的な関数が存在することが多い。このような内部関数も含めて依存関係を把握すると、出力画面に表示される分析評価結果の例図11Aのように、様相が異なる場合がある。図11Aでは、内部関数との依存関係を含めた場合に、仕様S2~S4は相互に分離が容易でなく、仕様S1だけが分離容易である様子が示されている。このように内部関数の依存関係の状態に基づくグルーピングが、適切な分担範囲の設定を可能にする効果を生じさせている。すなわち、この例では、ソフトウェアの開発において、仕様S1に関しては、その下流工程の関数グループも含めて、仕様S2~S4とは依存関係が無く、これらから容易に分離して独立に行えることを示している。一方、仕様S2~S4は、上下流工程の成果物間に複雑な相互の依存関係があり、分離せずにまとめて開発することを推奨する様子を示している。得られた分離単位は、作業分担の指針とする以外にも、有益な情報として利用可能である。たとえば、開発に要した工数や日数等の実績値の計測及び開発に要する工数や日数等の見積りに役立つ。実績値の計測や見積りは開発作業全体に対してだけでなく、機能単位や作業分担単位といった形で範囲を区切った部分についても行われることが少なくなく、その場合に、相互に依存関係の少ない分離単位ごとに、開発実績の計測や見積りを実施することで、データの妥当性の向上が期待できるからである。規模の面では、ソースコードモジュール間の依存性が高いと、各モジュール関数規模をどの機能に帰属させるかの判断が難しく、見積り根拠としての妥当性が曖昧になりがちであるが、依存関係を分離できていれば、各モジュール関数規模の帰属を明確にしやすい。ひとつのモジュール関数の規模を複数の機能に無意識的に帰属させて多重集計してしまうような見積り根拠としての妥当性を曖昧にする事象を防止しやすい。また、工数面でも、特定の機能の開発に関するトラブルで、その他の機能の開発に悪影響が及び工数的な停滞を受けると、待ち時間を除いた実質的な所要工数を、特定しにくいが、あらかじめ依存関係を分離してあれば、開発工数や所要日数を、分離された範囲ごとに対応づけやすくなり算定値の精度も向上させやすい。以上の上下流の工程にかかわる複数の成果物間の依存性解析及び評価では、機能仕様項目と実装関数を対応づけた状態で、双方をまとめて実施する手順で例示したが、先に実装関数のサブグループを抽出し、その後で、機能仕様項目と実装関数のサブグループを対応づけ、上下流の工程にかかわる複数の成果物間の依存性解析及び評価を行って分離単位を見出す手順をとってもよい。図11Bの例がこの手順の結果として得られる典型的な出力例であり、仕様と実装関数とを一体で、分離可能な範囲を分析者に認知させるために、仕様グループSG1とSG2と関数グループF1とF2の対応づけを模式的に分析者に提示した様子となっている。仕様S1~S4はSG1とSG2にグルーピングされて、関数f1~f7はF1とF2とにグルーピングされている。そして、分離容易な単位が分離単位1、分離単位2として示されている。このような分離単位の提示は、変更作業の品質と効率を高める効果を奏する。分離単位ごとに作業者が扱う範囲が分担されれば、変更作業における作業者間の競合による作業遅延などの開発上のリスク要因が低減可能になるからである。以下、図8B、図9B、図10Bを用いて、関数グループF1とF2を先に抽出する場合の手順を例示する。図8Bに示す成果物解析情報の表500は、図6のStep104の成果物内依存関係取得の測定結果の一例を示したものである。成果物解析情報の表500は、関数名欄501と、関数グループID欄502とを備える。各行に一つの関数情報が格納される。関数名欄501は、縦列にファイルの格納先とファイル名を示したパス名等が格納されでもよい。関数グループID欄502は、ソースコードの構成要素としての関数同士の依存関係の状態に基づくグループに対応づけられた識別子が格納されるものである。なお、図中に入力されている値関数グループIDや関数名は一例である。また、関数同士の依存関係の一例として関数の呼び出し関係情報を用いることが可能であり、その場合には、図8Aの情報が利用できる。依存関係の状態に基づくグループ構築においては、分析関連情報格納部3Bに格納された開発成果物の依存関係の解析を行う場合に利用可能な外部ツールを利用することが想定されるが、ここではネットワーク分析も利用できる。出力画面に表示された図11Aの分析評価結果のf1~f8までのコールグラフに等価な、隣接行列図8Aを入力にして、依存関係の粗密に応じて、その内部で他とは区別できるような形で結びついた集団サブグループを抽出可能となる。上記のツールでは、グラフの極大の連結成分やクリークやコミュニティといったサブグループが抽出でき、本発明でも利用可能である。F1とF2はサブグループの識別子に相当する。図9Bは、成果物対応づけ情報の結果に成果物解析情報の結果を統合する流れ図6のStep106を、詳細に示したフローチャートである。まず、検出した成果物対応づけ情報に示す結果と成果物解析情報に示す結果の情報が、開発成果物分析手段に入力されるステップS201。次に、開発成果物分析手段において、成果物対応づけ情報の結果の1行目の関数名と、成果物解析情報の結果の1行目の関数間依存関係の測定対象の関数名を比較する。すなわち、成果物対応づけ情報結果の1行目の関数名と、成果物解析情報結果の1行目の関数名を比較するステップS204。比較した関数名が同じかどうか確認しステップS205、関数名が同じである場合、成果物対応づけ情報結果の右端の列に同じ関数名の関数グループIDを追加するステップS206。成果物対応づけ情報結果の1行目に同じ関数名が無い場合は、成果物解析情報結果の関数名を一つ下の行へ移動しステップS210、同じ関数名があるか確認しステップS211、同じ関数名があるところの関数グループIDを成果物対応づけ情報結果の右端に追加するステップS212。次に、成果物対応づけ情報結果の関数名を一つ下の行に移動するステップS207。同様にステップS205、ステップS206、ステップS210、S211、ステップS212を繰り返し行い、成果物対応づけ情報結果の関数名を全部確認するステップS208。最後に成果物対応づけ情報結果に関数グループIDを追加した結果を出力するステップS209。この出力が、図10Bの同じ関数名601Aを手がかりにして成果物間対応づけ情報と成果物内解析情報を統合した表600に相当する。表600は、関数名欄601と、仕様書階層名602と、関数グループID603とを備える。次に、図10Bの成果物間対応づけ情報結果と成果物間の対応づけ情報、成果物対応づけ情報を統合した表600をもとに、図6のメインフローのStep107及びStep108に相当する成果物間の依存性解析及び評価が実施され、再び、ネットワーク分析によるサブグループの抽出などが行われる。その結果が、例えば、図11Bに示すような分離可否の形式で出力画面に表示される。本実施例によれば、上下流の工程にかかわる複数の成果物、例えば機能と実装、を関連付けて評価し、特にそれらの間の依存関係の関係性の複雑さ、たとえば、絡みあいの程度に関わる情報を、機械的な処理により分析の目的に応じて加工し、分析者に情報提供することができる。また、複数の条件指標で上下流の関係にある成果物間の依存関係を評価し、評価条件の相違を反映した複数の異なる検出結果を比較参照することで、分析の目的に応じた評価結果に関わる情報の選別に活用することができる。次に、本発明における第二の実施の形態を、図12A、図12Bを参照しながら説明する。第二の実施の形態のシステム構成は、第一の実施の形態のシステム構成と同じである。本実施例における上流工程、下流工程の関係の例を、図12Aに示す。上流工程に関しては、第一の実施の形態と同じである。下流工程は、下流工程1と下流工程2があり、下流工程1は、第一の実施の形態の下流工程と同じである。下流工程2は、さらに、試験工程、すなわちソースコードを実装してテストした結果である。下流工程2には、下流工程1に対応した複数のテスト項目がある。このテスト項目は、一般に、自然言語や数値等で表現されたものを指す。本実施例の場合、図5の成果物対応づけ表250に相当するものが、さらに試験工程のテスト項目を含むものとなる。次に、図12Bに、第二の実施形態における、開発成果物分析処理の全体のフローの概念図を示す。まず、ソースコードの実装テスト結果を含むソフトウェア開発の上下流工程の複数の成果物から、キーとなる1つの成果物を指定するステップ20。次に、ソフトウェア開発の上下流工程の複数の成果物テスト項目を含む間の対応づけ情報を参照するステップ21。そして、上記1つの成果物と、上下流工程の他の成果物テスト項目を含む間の、依存関係の複雑さを分析評価するステップ22。なお、先に全ての成果物を対象にステップ21、22を実行してから、1つの成果物を指定してステップ20を実行するようにしても良い。第二の実施形態では、指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、複数の成果物を構成する要素である、要求仕様、機能仕様、ソースコードに記述された関数等のモジュール、または試験工程のテスト項目のうちの、何れか複数の成果物間の依存関係の複雑さである。本実施例によれば、第一の実施の形態に加えて、実装テスト結果を含むことで、より多くの観点で、依存関係の複雑さ、たとえば絡みあいの多寡等、を評価し、分析者に情報提供することができる。以上、第一の実施の形態及び第二の実施の形態においては、依存関係を示すグラフは無向グラフの形態で例示したが、有向グラフの形態であっても、本発明の主旨を逸脱しない範囲で実施できるのは言うまでもない。"