JP2013015958A - ソフトウェア開発成果物間の依存関係評価装置及び評価方法 - Google Patents

Abstract

【課題】ソフトウェア開発の成果物間の依存関係状態を評価し、作業分担の指針等を提供する。
【解決手段】ソフトウェア開発の過程でうみだされる各工程の成果物の評価方法であって、成果物の依存関係の程度を評価する依存関係分析評価部を備えている成果物の評価方法であり、依存関係状態解析部が、ソフトウェア開発における複数の工程の成果物同士の間の依存関係の状態を評価することを特徴とする。この依存関係の状態とは、単に影響の有無だけではなく、依存関係の複雑さ、たとえば絡みあいの多寡等、に関わるものとする。
【選択図】図１１Ａ

Description

本発明は、ソフトウェア開発による成果物間の依存関係の評価装置及び評価方法に係り、特に、複数の工程の成果物の間の依存関係情報を評価基準に利用するソフトウェアの評価装置及び評価方法に関する。

ソフトウェア開発において、ある仕様等を変更したときは、影響しあう仕様等をもれなく把握し、あわせて変更することが必要となる。しかし、ソフトウェア開発が大規模かつ複雑になるにつれ、その影響範囲の特定に困難が伴うために、影響範囲の特定作業が品質および効率等の開発の成果を左右する事例が増えている。

そこで、従来から、開発成果物としての設計ドキュメントないしはその内部の記述項目間の依存関係の把握を支援する方法が提供されている。

特許文献１では、変更対象のドキュメント類と相関関係を有するドキュメント類を検索するとともに特定することが可能な影響範囲検出装置および影響範囲の検出方法を提供している。

特許文献２では、設計文書（仕様書等）のファイル名を識別子として依存関係を持つファイル間の依存関係を記録し、対象のファイルを変更することによって影響を受ける可能性があるファイルを一覧化している。

特許文献３では、プログラム内部の情報を用いて依存関係を把握してプログラムモジュール間の影響強度を評価する手段を提供している。

また、非特許文献１、非特許文献２には、ネットワーク分析（複雑ネットワーク分析）に関する記述がある。

特開２０００−４７８６１号公報 特開２００９−２６５８３６号公報 特開２０１０−２８２４４１号公報

湯田聴夫:コミュニティ抽出法とその展望、 オペレーションズ・リサーチ、 53 (2008)、 529-535 鈴木 努著：Rで学ぶデータサイエンス8 ネットワーク分析、 共立出版(2009)

近年、ハードウェア価格低下とハードウェアの機能の向上にともない、ソフトウェアシステムは年々大規模化、複雑化している。ソフトウェアシステムの大規模化により、ソフトウェアの構築や保守にかかるコストが増大し、多くの労力が必要となる。保守開発等のチームの作業人員数も増える傾向にある。そのため、開発保守や改造作業において、作業分担の妥当性は開発の成否を左右する要素となっている。しかし、どの範囲の既存資産で区切って（既存資産を分離して）、解析や改修といった作業分担を行うかの判断は容易でない。

たとえば、複数の作業者に作業分担を行う際に分担した作業対象物（開発工程の成果物）同士の依存関係が強いと、作業者間の変更の競合が発生したり、分担を超えた複数領域が原因となった不具合が発生し解析に手間取ったり等、品質面および作業コストの面での問題が生じやすい。したがって分業を効率的・効果的に推進するためには、依存性が低い分離容易な単位（分離単位、あるいは分担範囲と称する）を抽出することが求められる。すなわち、その分離単位で分離した場合に、分離される部分集合内部が緊密な依存関係を有していても、部分集合の外部との依存関係が最小化された状態になることが望ましい。

そして、同一工程の成果物の依存関係だけでなく、上下流の工程の成果物間を（例えば機能と実装とを）紐づけた状態で依存関係が可視化されること、そして依存関係を最小化し分離することが望まれる状況も少なくない。機能単位での反復型開発やセル生産方式のような形態では、機能単位に割り当てられた開発作業者が下流工程もあわせて担当する状況も多く、効率的・効果的な機能別の分業の促進が期待されるからである。

また、上下流の工程の成果物間を（例えば機能と実装とを）紐づけた状態で依存関係を可視化した情報は、作業分担の指針とする以外にも、見積り（工数等の見積り）及び開発に要した工数や日数（開発実績）の計測に有効である。工程で分業し下流工程になると別の会社の別の担当者が担当するような開発体制であっても、上流工程の段階で開発工程全体を通じた見積りや、上下流の作業分担を超えた見積りは必要であるし、紐づく実装も含めた機能間の依存関係の複雑さが、品質面および作業コストの面での前記問題の発生可能性やその大きさに影響し見積りを左右する要素となるからである。さらに、その依存関係を低減し、分離できれば、ある開発の所要日数や工数等の開発実績の計測や、関連する別の開発（ある開発に対する派生開発等）の見積りが行いやすくなる。実績値の計測や見積りは開発作業全体に対してだけ行うとは限らず、機能単位や作業分担単位といった形で範囲を区切った部分についても行われるが、その場合に、相互に依存関係の少ない分離単位ごとに、開発実績の計測や見積りを実施することで、データの妥当性の向上が期待できる。規模の面では、ソースコードモジュール間の依存性が高いと、各モジュール（関数）規模をどの機能に帰属させるかの判断が難しく、見積り根拠としての妥当性が曖昧になりがちであるが、依存関係を分離できていれば、各モジュール（関数）規模の帰属を明確にしやすい。また、工数面でも、特定の機能の開発に関するトラブルで、その他の機能の開発に悪影響が及び工数的な停滞を受けると、待ち時間を除いた実質的な所要工数を、特定しにくいが、あらかじめ依存関係を分離してあれば、開発工数や所要日数を、分離された範囲ごとに対応づけやすくなり算定値の精度も向上させやすい。

上記各特許文献に記載の従来の技術は、複数工程の成果物の間の依存関係の有無を可視化する方法を提供する技術であるか、あるいは、プログラム内部等の特定の成果物の内部の依存関係を把握して影響の質的側面(複雑さ)を評価する技術である。これら従来の技術は、同じレベルの工程、例えばソースプログラム間の関係を評価するものであって、上下流の異なる工程、例えば製品の外部仕様や機能と実装、あるいは、その他の上下流の工程も含めた依存関係の複雑さを扱うものではない。このような上下流の複数工程の成果物間（例えば製品の外部仕様と実装、あるいは機能と実装）の絡みあいの複雑さの評価や依存関係の複雑性の低減させるような作業分担の指針に対しては、これらの従来技術では配慮されていない。

従来の技術により、上下流の複数工程の成果物の間の依存関係の状態を人間が把握して、適切な分離単位（依存関係が弱く相互に分離が容易な分離範囲）を探し出そうとすると、分析者の労力や分析に要する時間を多く費やしてしまう。機能と実装をまたがって依存関係の状態を分析者（ユーザが自ら把握することは、機能と実装の双方への深い理解が必要になるため、開発の規模と複雑さの拡大に伴い、一層難しくなっている。

本発明の課題は、ソフトウェア開発の上下流の工程にかかわる複数の成果物間の依存関係の検出における上記従来技術の問題点を解決し、分析者（ユーザ）に分析の目的に応じた精度の検出情報を、例えば機能と実装の双方の依存関係情報をもとに、機械的な処理により自動的に求め、双方の依存関係の状態を効率よく提示することができる、ソフトウェア開発成果物間の依存関係評価装置及び評価方法を提供することにある。

いいかえると、本発明の課題は、上下流の関係にある複数の工程の成果物にまたがった分析結果から、相対的に独立した構成要素群（モジュール）の集合体を見出すこと、上下流の関係にある複数の工程の成果物を俯瞰したスコープで「モジュール化」（独立に設計開発されうる半自律的なサブシステムに分解する操作）の指針を見出すこと、と表現できる。さらに、構成する要素の数と各要素間の関係の強さでシステムの複雑性が決まると考えると、本発明の課題は、構成要素を適切にグルーピングする指針、グループ間のインターフェースの数を減らし相互作用を弱め、複雑性を下げる指針を提示することであるともいえる。

本発明の代表的なものの一例によれば、依存関係評価装置は、ソフトウェア開発の成果物の依存関係を評価するソフトウェア開発成果物間の依存関係評価装置であって、前記ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも１つの成果物を指定する手段と、記憶装置に記憶された成果物対応づけ表を参照して、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を取得する手段と、前記指定された成果物と、前記上下流工程の他の複数の成果物間の、依存関係の複雑さを評価する手段とを備えていることを特徴とする。

本発明によれば、ソフトウェアの既存資産に関して開発の上下流の工程にかかわる複数の成果物について、分離容易性の観点で必要な情報を機械的な処理により探しやすくし、分析者（ユーザ）の労力を軽減し、分析に要する時間を短縮できる。また、分離容易性に関わる依存関係の複雑さを示す情報をユーザに図や表として可視化し提供することにより、各ユーザは、ソフトウェアの開発に関して、効率的に作業分担指針を抽出できるようになる。あるいは開発工数などの見積りを行いやすくなる。

本発明の第一の実施形態になる、ソフトウェア開発成果物間の依存関係評価装置のハードウェア構成例を示す図である。 第一の実施形態に係る、ソフトウェア開発成果物間の依存関係評価装置の機能ブロック図である。 本発明における上流工程、下流工程の関係の例を示す図である。 第一の実施形態における、開発成果物分析処理の全体のフローの概念図を示すである。 本発明における、成果物間の依存関係の例を示す図である。 第一の実施形態における、成果物対応づけ表の例を示す図である。 第一の実施の形態における、開発成果物の分析処理の全体の処理の具体的な流れを示したフローチャートである。 第一の実施形態における、成果物対応づけに関する情報を、ノードとノードをつなぐリンクで表現した図である。 第一の実施形態における、成果物解析結果表の例を示す図である。 第一の実施形態における、成果物解析結果表の他の例を示す図である。 図６のフローチャートにおける、成果物対応づけ情報と成果物解析情報取得結果を統合する処理の詳細を示すフローチャートである。 図６のフローチャートにおける、成果物対応づけ情報と成果物解析情報取得結果を統合する処理の詳細を示すフローチャートの他の例である。 第一の実施の形態における、成果物間対応づけ情報統合表の例を示す図である。 第一の実施の形態における、成果物間対応づけ情報統合表の他の例を示す図である。 第一の実施の形態における、出力画面に表示される分析・評価結果の例を示す図である。 第一の実施の形態における、出力画面に表示される分析・評価結果の他の例を示す図である。 本発明における上流工程、下流工程の関係の他の例を示す図である。 第二の実施形態における、開発成果物の分析処理の全体のフローの概念図を示すである。

本発明の代表的な実施例によれば、ソフトウェア開発の過程でうみだされる上下流の各工程の成果物の評価方法であって、成果物の依存関係の程度を評価する依存関係分析評価部を備えている成果物の評価方法であり、依存関係状態解析部が、ソフトウェア開発における上下流の複数の工程の成果物同士の間の依存関係の状態を評価することを特徴とする。この依存関係の状態とは、単に影響の有無だけではなく、依存関係の複雑さ、たとえば絡みあいの多寡等、に関わるものとする。

各工程の成果物としては、ソースコードの記述されたファイル全体、仕様書や設計書といったドキュメントなどを広範に含むものとし、さらには、その内部に含まれている、個々のモジュール、個々の仕様項目、個々の設計事項の単位を成果物と見なすことも可能とする。

本発明では、分析の目的に応じて、上下流の複数の工程の成果物の対応づけを示す情報とともに、双方の間の依存関係の状態を算出する。依存関係の状態は、開発で得られた成果物の構成要素群を周囲から分離することが容易であるか否かを示す分離容易性を評価し改善指針を得るために測定するものである。本発明では、依存関係が強く絡み合いが複雑な部分を境界にした分離は困難であり、そうでないと分離が容易であるものとして見なす。複数の工程の成果物とは、典型的には上流の機能に関わる情報（個々の機能項目や顧客要求項目）と下流の実装単位（ソースコードにおける関数などのモジュール（ソフトウェアの構成部品））であり、双方を対応づけるとは、この場合、工程の面で上下流の関係にある機能と実装との間の関係性を明らかにすることを意味する。上下流の関係にある機能と実装とを関連付けて評価し、特にそれらの間の依存関係の関係性の複雑さ、たとえば、絡みあいの程度に関わる情報を、分析の目的に応じて加工し分析者に情報提供する。

また、複数の条件（指標）で依存関係を評価し、評価条件の相違を反映した複数の異なる検出結果を比較参照することで、分析の目的に応じた評価結果に関わる情報の選別に活用する。
以下、本発明の実施の形態を、図面を参照して説明する。

本発明における第一の実施の形態を、図１Ａ乃至図１１Ｂを参照しながら説明する。

［システム構成］
まず、本発明によるソフトウェア開発成果物の依存関係の評価方法を実施するのに適した、ソフトウェア開発成果物間の依存関係評価装置のシステム構成例を、図１Ａ、図１Ｂを参照しながら説明する。
本発明のソフトウェア開発成果物間の依存関係評価装置は、ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも１つの成果物を指定する手段と、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を、記憶装置に記憶された成果物対応づけ表を参照して、取得する手段と、前記指定された成果物と、前記上下流工程の他の単一あるいは複数の成果物との間の、依存関係の複雑さを評価する手段とを備えている。本発明のソフトウェア開発成果物間の依存関係評価装置は、図１Ａに示すような一般的なコンピュータ上で、ソフトウェア開発の成果物の依存関係の分析をコンピュータに行わせることにより、実現される。すなわち、開発成果物の依存関係評価装置は、ＣＰＵ（演算処理装置）１００と主記憶部１０１と、HDD等の外部記憶装置１０２と、CD-ROMやDVD-ROM等の可搬性を有する可搬型記憶媒体１０３から情報を読み出す読取装置１０４と、ディスプレイ（表示装置）やキーボードやマウス等の入出力装置１０５と、通信ネットワークに接続するためのNIC（Network Interface Card）等の通信装置１０６と、バス１０７とを備えた一般的なコンピュータ上で、「ソフトウェア開発成果物間の依存関係評価」プログラムを実行することで実現される。このコンピュータプログラムは、単体のコンピュータ上で実行されるように構成しても良く、あるいは、また、サーバとこのサーバにネットワークを介して接続された少なくとも１つのコンピュータとで実行されるように構成しても良い。また、入出力装置は、ユーザインターフェース機能を有するディスプレイ（表示装置）のように、入出力機能の一部が、一体的に構成されたものであっても良く、あるいはまた、入力装置と出力装置が独立して構成されたものであっても良い。

次に、本実施形態に係る開発成果物分析手段の構成について説明する。
図１Ｂは、本実施形態に係る依存関係の評価を行う、ソフトウェア開発成果物間の依存関係評価装置の機能ブロック図である。ソフトウェア開発成果物間の依存関係評価装置は、外部記憶装置部１０２と主記憶装置部１０１を備えている。

外部記憶装置部１０２は、開発成果物格納部３Ａと、分析関連情報格納部３Ｂを備える。発成果物格納部３Ａには、依存関係の評価を行うソースコードなど、分析に必要な開発成果物が格納される。

分析関連情報格納部３Ｂには、開発成果物の依存関係の解析を行う場合に利用可能な外部ツールの情報など、本実施形態の実施に必要な分析関連情報が格納されている。

また、以下で説明する、成果物対応づけ表（図５参照）、成果物解析結果表（図８Ａ，図８Ｂ参照）、及び、成果物間対応づけ情報統合表（図１０Ａ，図１０Ｂ参照）等も格納される。

主記憶装置部１０１は、コンピュータプログラムを保有しており、このプログラムに基づく所定の処理手順をＣＰＵで実行することにより得られる機能（ユニット）として、成果物対応づけ情報取得部５、成果物解析情報取得部６、照合・統合部７、依存関係分析評価部８、評価結果表示部９を備える。主記憶装置部１０１は、さらに、成果物対応づけ情報取得部５及び成果物解析情報取得部６で処理するためのデータを取得し、成果物対応づけ表として記憶装置に保持する成果物前処理部４を備えている。本発明のソフトウェア開発の具体的な対象物としては、例えば、自動車制御システム、テレビ、情報処理機器等の組み込みシステムが挙げられる。

本発明では、ソフトウェア開発の成果物の依存関係の分析をコンピュータに行わせるために、上流工程から下流工程にかかわる複数工程の成果物の間の対応関係を示すテーブル（成果物対応づけ表）を用い、前記対応関係を参照して、複数の前記成果物間の依存関係の複雑さを評価する。すなわち、入出力装置を介してユーザから与えられた、上流工程から下流工程にかかわる任意の階層の少なくとも１つの前記成果物をキーにして、他の工程の成果物との依存関係を解析する。成果物対応づけ表は、例えば事前にユーザが各工程の成果物の情報を収集してテーブル化、それをコンピュータの記憶装置に保持する。

照合・統合部７は、成果物対応づけ表を参照して、成果物対応づけ情報取得部５、および成果物解析情報取得部６で得られた結果を照合・統合を行う。
依存関係分析評価部８は、照合・統合部７で処理した結果をもとにユーザの目的に応じ、上流工程から下流工程にかかわる成果物間の依存関係を分析し、評価する。
評価結果表示部９は、評価部８で評価した結果を、ユーザにわかりやすく可視化し表示する。

ここで、本発明における上流工程、下流工程の概念を、図２の例で説明する。本発明における上流工程、下流工程は、ソフトウェア開発の成果物の抽象度と言い換えることもできる。

上流工程は、例えば自然言語等を使用した文書や図形など、一般の人が理解できる形で表現された、組み込みシステム等に対する要求や仕様を生成する工程を指す。上流工程で得られる成果物にも、漠然とした概念のレベルや、詳細な仕様書等のような具体化されたレベルがある。ここでは、顧客の要求概念を分析し抽出する工程を上流工程１、その要求を実現するための具体的な機能仕様書、設計情報、カタログ項目等を作成する工程を上流工程２、と定義する。そして、上流工程１の成果物が、顧客の要求概念を列挙し明確化した文書であり、上流工程２の成果物が、要求を実現するための具体的な機能仕様書、設計情報、カタログ項目等である、というように、工程とその成果物は対応づけられる。

次に、下流工程は、コンピュータを用いて上流工程の要求仕様を実現するためのソースコード等の実装、換言するとコンピュータ言語で表現され一般の人が容易には理解できない形式で表現されたものを生成する工程を指す。そして、下流工程の成果物は、ソースコード等の実装である、として、工程とその成果物が対応づけられる。

なお、「上流」と「下流」の区切りは、これに固定したものではなく、「上」と「下」の関係は、相対的なものである。たとえば、ソースコードの実装工程は「下流」として前述したが、試験工程に対しては相対的に「上流」の工程、として位置づけられることが一般的である。

次に、図３に、本発明の第一の実施形態における、開発成果物分析処理の全体のフローの概念図を示す。

まず、ソフトウェア開発の上下流工程の複数の成果物から、キーとなる１つもしくは複数の成果物を指定する（ステップ１０）。次に、ソフトウェア開発の上下流工程の複数の成果物間の対応づけ情報を、成果物対応づけ表を参照して、取得する（ステップ１１）。最後に、上記指定された成果物と、上下流工程の関係にある他の複数の成果物間の、依存関係の複雑さを分析・評価する（ステップ１２）。なお、先に全ての成果物を対象にステップ１１、１２を実行してから、ステップ１０に相当する１つもしくは複数の成果物を指定し、指定された成果物と他の成果物との依存関係の複雑さを分析し、評価するようにしても良い。

次に、図４に、本発明における、成果物間の依存関係の例を示す。
例えば、上流工程１の顧客の要求概念が、「車の乗り心地が良い」であった場合を想定する。「車の乗り心地」を改善するためのより具体的なレベルの解決策（上流工程２）には、さまざまな観点のアプローチが考えられる。例えば、「加速性」に優れていること、「振動」が少ないこと、「騒音」が少ないこと、「空調」が快適であること、等々が挙げられる。

「車の乗り心地」を良くするために「加速性」を改善すべく、例えば、エンジンのトルク特性を変更することを想定する。この場合、エンジンのトルク特性の変更を実現するための、同じ工程（階層）の機能あるいは仕様として、「点火系統（Ｓ１）」、「燃料系統（Ｓ２）」、「吸排気系統（Ｓ３）」、「電源系統（Ｓ４）」等が相互に何らかの依存関係があると考えられる。

また、上流工程２おいて、エンジンのトルク特性の変更は、エンジン出力の影響を受ける「駆動機構制御」、「車体制御」、「起動・発電制御」、「室内機器・空調制御」等にも影響を及ぼすと考えられる。従って、「加速性」を改善するためにエンジンの「点火系統」、「燃料系統」、「吸排気系統」、「電源系統」に変更を加えることは、「駆動機構制御」、「車体制御」、「起動・発電制御」、「室内機器・空調制御」との間、例えば「空調機制御（Ｓｍ）」、にも何らかの影響を与える、という依存関係の複雑さが考えられる。

エンジンのトルク特性の変更は、エンジンを制御するプログラム、すなわち、下流工程の複数のソースコードに影響を与える。例えば、吸入空気量検出モジュール（ｆ１）、エンジン回転数検出モジュール（ｆ２）、点火時期制御モジュール（ｆ３）、燃料噴射制御モジュール（ｆ４）、電源制御モジュール（ｆ５）等、さらには空調機制御を行う「ソースコード（ｆｎ）」、が相互に何らかの依存関係がある。

同様に、「騒音」を低減するために「駆動機構制御」に変更を加えることを想定すると、それは、「エンジン制御」、「車体制御」、「起動・発電制御」、「室内機器・空調制御」との間にも何らかの影響を与える、という依存関係が考えられる。そして、さらに、これらの依存関係は、ソースコード（下流工程）にも影響を与える、という複雑さがある。

このように、上流工程１の「車の乗り心地」改善という成果物、あるいは上流工程２の「点火系統」、―、―という成果物と、下流工程の成果物である各ソースコードとの間には、複数の成果物が相互に絡み合う依存関係の複雑さが存在する可能性がある。従って、例えば、自動車の組み込みシステムのソフトウェア開発の開発保守や改造作業に従事する担当者を想定した場合、その担当者は、上下流工程のどの単位で既存資産の解析を行い、他の関係者との作業分担をどのように行うかについての適切な情報が得られることが望ましい。

このような、複数の成果物間で相互に絡み合った上下流工程の成果物間の依存関係の複雑さを明らかにするために、本発明では、まず、成果物対応づけ表が作成され、コンピュータの記憶装置に記憶される。

図５に、成果物対応づけ表２５０の一例を示す。この成果物対応づけ表２５０は、成果物対応づけ情報をテーブル化したものである。成果物対応づけ表２５０は、関数名欄２５１と仕様書項目名欄２５２とで構成されている。この表は、ソースコード等の実装、例えばモジュール（関数）が、どの機能や仕様に対応するかを示している。

すなわち、1行目は、下流工程の関数f1が、上流工程の仕様S1を実現するモジュールであることを示している。逆に、上流工程の仕様をベースにして、対応する下流工程の関数を記載しても良い。なお、図５の関数名ｆ、仕様書項目名Ｓの具体例は、図４の例に直接対応するものではなく、あくまでも記載の一例を示すものである。
この成果物対応づけ表２５０は、ユーザが本システム構成の外部で作成した情報を入力してもよいし、公知の技術を用いてこの段階で生成してもよい。
また、仕様書項目名欄２５２は、章番号等の仕様書の記載箇所を示すID情報であってもよい。

なお、成果物対応づけ表２５０は、上下流工程の対応関係の情報が、情報の取得可能な範囲でテーブル化されていれば良い。上記した、複数の成果物が相互に複雑に絡み合った上下流工程の依存関係を考慮する必要は全くない。例えば、図４の例では、上流工程１の「車の乗り心地」に対する上流工程２の各成果物、例えば成果物（Ｓ１）〜（Ｓ４）、及び、これらの成果物、例えば（Ｓ２）に対応する下流工程の成果物（ｆ１）〜（ｆ２）、（ｆ４）〜（ｆ５）が、情報の取得可能な範囲で順次記録されていれば良い。

図６は、第一の実施の形態の全体の処理の流れを示したフローチャートである。
まず、最初に、開発成果物分析手段では、ユーザにより選定された少なくとも２つのプログラム（ソースコードや設計文書など）を文字コード変換など前処理する（ステップ１００）。そして、この結果に基づいて、成果物間対応づけ情報取得（ステップ１０３）と成果物内解析情報取得（ステップ１０４）とを実施する。双方は並列的に実施することが可能である。

図７は、ステップ１０３の処理により、図５の対応づけ情報と同義の情報を、ノードとノードをつなぐリンクで表現した、成果物間対応づけ情報の図である。ノードが、個々の関数と個々の仕様項目に相当し、リンクがこれらの対応づけを示している。

次に、この並列的な処理フローで得られた成果物間対応づけ情報と成果物内解析情報とが、対応付けられ、統合される（ステップ１０６）。なお、ステップ１０６の詳細については、後で説明する。

この対応付け統合した結果を基に、成果物間の依存関係解析を行う（ステップ１０７）。そして、ユーザの目的に応じて、成果物依存性解析結果の評価をする（ステップ１０８）。さらに、評価した結果を可視化した結果として出力する（ステップ１０９）。

図８Ａに示す成果物解析情報の表５００は、図６のＳｔｅｐ１０４の成果物内依存関係取得の測定結果の一例を示したものである。成果物解析情報の表５００は、関数名欄５０１Ａと、呼び出し関数名欄５０２Ａとを備える。各行に一つの関数情報が格納される。
関数名欄５０１Ａは、縦列にファイルの格納先とファイル名を示したパス名等が格納されでもよい。
呼び出し関数名欄５０２Ａは、ソースコードには、いくつもの機能を実現するために大量の関数が定義されているが、関数名欄５０１Ａの関数と呼び出し関係を有する関数名が記述されている。

呼び出し関係を有する関数としては、関数名５０１Ａ欄の関数を呼び出す関数と、関数名５０１Ａ欄の関数に呼び出される関数、とに分類できるが、図８Ａの呼び出し関数名欄５０２Ａでは、両方が記述されている。図８Ａの情報をもとにすると、コールグラフを作成できる。関数同士がどのような呼ばれ方をしているのかをグラフで示した物がコールグラフであり、その典型的な例が、出力画面に表示された図１１Ａの分析・評価結果のf1〜f8までのグラフである。
なお、図中に入力されている関数名は一例である。

関数の呼び出し関係の抽出、及び呼び出し関係の情報に基づくコールグラフ構築においては、分析関連情報格納部３Ｂに格納された開発成果物の依存関係の解析に適用可能な外部ツールを利用することが想定される。
図９Ａは、成果物対応づけ情報の結果に成果物解析情報の結果を統合する流れ（図６のＳｔｅｐ１０６）を、詳細に示したフローチャートである。

まず、検出した成果物対応づけ情報に示す結果と成果物解析情報に示す結果の情報が、開発成果物分析手段に入力される（ステップＳ２０１Ａ）。

次に、開発成果物分析手段において、成果物対応づけ情報の結果の１行目の関数名と、成果物解析情報の結果の１行目の関数間依存関係の測定対象の関数名を比較する。

すなわち、成果物対応づけ情報結果の１行目の関数名と、成果物解析情報結果の１行目の関数名を比較する（ステップＳ２０４Ａ)。比較した関数名が同じかどうか確認し（ステップＳ２０５Ａ）、関数名が同じである場合、成果物対応づけ情報結果の右端の列に同じ関数名の呼び出し関数名を追加する（ステップＳ２０６Ａ)。

成果物対応づけ情報結果の１行目に同じ関数名が無い場合は、成果物解析情報結果の関数名を一つ下の行へ移動し（ステップＳ２１０Ａ）、同じ関数名があるか確認し（ステップＳ２１１Ａ）、同じ関数名があるところの関数グループIDを成果物対応づけ情報結果の右端に追加する（ステップＳ２１２Ａ）。

次に、成果物対応づけ情報結果の関数名を一つ下の行に移動する（ステップＳ２０７Ａ)。同様にステップＳ２０５Ａ、ステップＳ２０６Ａ、ステップS２１０、ＡステップＳ２１１Ａ、ステップＳ２１２Ａを繰り返し行い、成果物対応づけ情報結果の関数名を全部確認する（ステップＳ２０８Ａ)。最後に成果物対応づけ情報結果に呼び出し関数名を追加した結果を出力する（ステップＳ２０９Ａ)。

この出力が、図１０Ａの、同じ関数名を手がかりにして成果物間対応づけ情報と成果物内解析情報を統合した表６００に相当する。表６００は、関数名欄６０１Ａと、仕様書階層名６０２Ａと、呼び出し関数名欄６０３Ａとを備える。

次に、図１０Ａの成果物間対応づけ情報結果と成果物間の対応づけ情報、成果物対応づけ情報を統合した表６００をもとに、図６のメインフローのＳｔｅｐ１０７及びＳｔｅｐ１０８に相当する上下流の工程にかかわる複数の成果物間の依存性解析及び評価が実施され、その結果が、例えば、図１１Ａに示すような分離可否の形式で出力画面に表示される。

上下流の工程にかかわる複数の成果物間の依存性解析及び評価について、図５の成果物対応づけ情報をもとに、分離容易な形態をユーザに提供する例で、作用・効果を説明する。

分離容易な形態の抽出には、ネットワーク分析と称される（複雑ネットワーク分析とも称される）さまざまな対象における構成要素間の関係構造を探る手法に関する分析手法と分析ツールが利用可能である。依存関係分析評価部によってネットワーク分析ツールが呼び出され依存関係分析が実施されるのが、典型的な実施の形態である。

ネットワーク分析とは、さまざまな対象を点と線からなるネットワーク（グラフ）として表現し、その構造的な特徴を探る分析方法である。グラフの点は、ノード（構成要素を示す点）、線はリンク（構成要素同士のつながりを示す線）等とも呼ばれ、ノード（構成要素）同士の関係が一定以上の強さを有する場合にノード同士がリンクで結ばれる。関係が有るか無いかの二者択一をリンクの有無に代表させてもよい。その典型的な例が、出力画面に表示された図１１Ａの分析・評価結果のf1〜f8までのグラフである。図１１Ａのグラフでは、ソースコードが有する関数（ｆ１〜ｆ８）をソースコードの構成要素（ノード）とみなし、呼び出す側の関数と呼ばれる側の関数が、相互に呼び出し関係を有すると定義し、リンクで結んでいる。そして、さらに、関数（ｆ１〜ｆ８）と仕様（S1〜S4）との対応づけをリンクで結んでいる。

ネットワーク分析では、与えられたグラフの状態を分析評価する手法であり、次のような情報を抽出する。
・個別のノードについて、周囲のノードとの間の影響範囲の広さや強さを示すネットワーク指標（たとえば次数や到達度、媒介度、結束度）を算出する。
・ネットワークからサブグラフ（サブグループ）を抽出する。サブグループとは、その内部で他と区別できるような形で相互に結びついた集団（ノードとリンクで構成される部分集合）
このような公知のネットワーク分析の手法を用いることで、分離容易な形態の抽出が実現できる。図１１Ａにおいては、連結成分をネットワーク分析によってサブグループとして抽出し、そのサブグループを分離容易な単位として出力画面に提示した様子が示されている。連結成分とは、ネットワーク内部がいくつかの部分がリンクで接続されずに分離している場合に、分離している各々の部分（サブグラフ）を意味する。

公知のネットワーク分析ツールでは、連結成分以外にも、クリーク（３個以上のノードの集合において、集合内のノード全てが互いにリンクし合っているような高密度な部分集合）やコミュニティ（クリークに限らず、構造的にサブグラフ内のノード間のリンク密度が相対的にサブグラフ外へのリンク密度よりも高いという特徴により規定されるネットワークの部分集合）といったネットワーク分析の分野で知られた各種の指標や操作でサブグループを抽出することが可能であり、本発明でも利用可能である。連結成分という概念によるサブグループの識別指針は、リンクが分離していないネットワークには適用できないという欠点を有するが、連結成分以外の指標等を利用することで、連結しているグラフの内部で相対的に密度の高い部分を抽出することも可能である。たとえば、分割されたコミュニティ内のリンク（辺）の数とコミュニティ間の辺の数の比較により、高密度のサブグループ（コミュニティ）をうまく抽出しているかを示す指標としてネットワーク分析の指標では「モジュラリティ」が知られており、この指標で分離単位（分離範囲）を決める手法も、本発明の趣旨を逸脱しない範囲で適用可能である。

以上のネットワーク分析（複雑ネットワーク分析）に関しては、非特許文献１、非特許文献２の引用を以って詳細な説明に代える。

なお、ネットワーク分析における「モジュラリティ」はモジュール化の程度を判別する指標の一つであると見なせる。「モジュール化（モジュラー化）」はネットワーク分析に関わらず広く使われている概念であり、概ね、独立に設計開発されうる半自律的なサブシステムに分解する操作や分解された状態が「モジュール化」と呼ばれる。「モジュール化」の程度や容易さを判別することが本発明の主旨であり、ネットワーク分析における「モジュラリティ」は判別する指標の一例にすぎない。したがってネットワーク分析以外の指標で判別しても本発明の主旨を逸脱するものではない。

図５及び図７には、仕様に対応づく情報を有する外部参照可能な関数のみが記述されている。一見すると、仕様S2〜S4は相互に分離が容易なように見える。

しかし、実際には、その他にも、仕様とは明示的に対応づけが管理されていないような内部的な関数が存在することが多い。このような内部関数も含めて依存関係を把握すると、出力画面に表示される分析・評価結果の例（図１１Ａ）のように、様相が異なる場合がある。
図１１Ａでは、内部関数との依存関係を含めた場合に、仕様S2〜S4は相互に分離が容易でなく、仕様S１だけが分離容易である様子が示されている。このように内部関数の依存関係の状態に基づくグルーピングが、適切な分担範囲の設定を可能にする効果を生じさせている。すなわち、この例では、ソフトウェアの開発において、仕様S１に関しては、その下流工程の関数グループも含めて、仕様S2〜S4とは依存関係が無く、これらから容易に分離して独立に行えることを示している。一方、仕様S2〜S4は、上下流工程の成果物間に複雑な相互の依存関係があり、分離せずにまとめて開発することを推奨する様子を示している。

得られた分離単位は、作業分担の指針とする以外にも、有益な情報として利用可能である。たとえば、開発に要した工数や日数等の実績値の計測及び開発に要する工数や日数等の見積りに役立つ。実績値の計測や見積りは開発作業全体に対してだけでなく、機能単位や作業分担単位といった形で範囲を区切った部分についても行われることが少なくなく、その場合に、相互に依存関係の少ない分離単位ごとに、開発実績の計測や見積りを実施することで、データの妥当性の向上が期待できるからである。規模の面では、ソースコードモジュール間の依存性が高いと、各モジュール（関数）規模をどの機能に帰属させるかの判断が難しく、見積り根拠としての妥当性が曖昧になりがちであるが、依存関係を分離できていれば、各モジュール（関数）規模の帰属を明確にしやすい。ひとつのモジュール（関数）の規模を複数の機能に無意識的に帰属させて多重集計してしまうような見積り根拠としての妥当性を曖昧にする事象を防止しやすい。また、工数面でも、特定の機能の開発に関するトラブルで、その他の機能の開発に悪影響が及び工数的な停滞を受けると、待ち時間を除いた実質的な所要工数を、特定しにくいが、あらかじめ依存関係を分離してあれば、開発工数や所要日数を、分離された範囲ごとに対応づけやすくなり算定値の精度も向上させやすい。

以上の上下流の工程にかかわる複数の成果物間の依存性解析及び評価では、機能（仕様項目）と実装（関数）を対応づけた状態で、双方をまとめて実施する手順で例示したが、先に実装（関数）のサブグループを抽出し、その後で、機能（仕様項目）と実装（関数）（のサブグループ）を対応づけ、上下流の工程にかかわる複数の成果物間の依存性解析及び評価を行って分離単位を見出す手順をとってもよい。図１１Ｂの例がこの手順の結果として得られる典型的な出力例であり、仕様と実装（関数）とを一体で、分離可能な範囲を分析者に認知させるために、仕様グループ（SG1とSG2）と関数グループ（F1とF2）の対応づけを模式的に分析者に提示した様子となっている。仕様（S1〜S4）はSG1とSG2にグルーピングされて、関数（f1〜f7）はF1とF2とにグルーピングされている。そして、分離容易な単位が分離単位１、分離単位２として示されている。このような分離単位の提示は、変更作業の品質と効率を高める効果を奏する。分離単位ごとに作業者が扱う範囲が分担されれば、変更作業における作業者間の競合による作業遅延などの開発上のリスク要因が低減可能になるからである。

以下、図８Ｂ、図９Ｂ、図１０Ｂを用いて、関数グループ（F1とF2）を先に抽出する場合の手順を例示する。

図８Ｂに示す成果物解析情報の表５００は、図６のＳｔｅｐ１０４の成果物内依存関係取得の測定結果の一例を示したものである。成果物解析情報の表５００は、関数名欄５０１と、関数グループID欄５０２とを備える。各行に一つの関数情報が格納される。
関数名欄５０１は、縦列にファイルの格納先とファイル名を示したパス名等が格納されでもよい。
関数グループID欄５０２は、ソースコードの構成要素としての関数同士の依存関係の状態に基づくグループに対応づけられた識別子が格納されるものである。なお、図中に入力されている値（関数グループID）や関数名は一例である。また、関数同士の依存関係の一例として関数の呼び出し関係情報を用いることが可能であり、その場合には、図８Ａの情報が利用できる。

依存関係の状態に基づくグループ構築においては、分析関連情報格納部３Ｂに格納された開発成果物の依存関係の解析を行う場合に利用可能な外部ツールを利用することが想定されるが、ここではネットワーク分析も利用できる。

出力画面に表示された図１１Ａの分析・評価結果のf1〜f8までのコールグラフに等価な、隣接行列（図８Ａ）を入力にして、依存関係の粗密に応じて、その内部で他とは区別できるような形で結びついた集団（サブグループ）を抽出可能となる。上記のツールでは、グラフの極大の連結成分やクリークやコミュニティといったサブグループが抽出でき、本発明でも利用可能である。F1とF2はサブグループの識別子に相当する。

図９Ｂは、成果物対応づけ情報の結果に成果物解析情報の結果を統合する流れ（図６のＳｔｅｐ１０６）を、詳細に示したフローチャートである。

まず、検出した成果物対応づけ情報に示す結果と成果物解析情報に示す結果の情報が、開発成果物分析手段に入力される（ステップＳ２０１）。

次に、開発成果物分析手段において、成果物対応づけ情報の結果の１行目の関数名と、成果物解析情報の結果の１行目の関数間依存関係の測定対象の関数名を比較する。

すなわち、成果物対応づけ情報結果の１行目の関数名と、成果物解析情報結果の１行目の関数名を比較する（ステップＳ２０４)。比較した関数名が同じかどうか確認し（ステップＳ２０５）、関数名が同じである場合、成果物対応づけ情報結果の右端の列に同じ関数名の関数グループIDを追加する（ステップＳ２０６)。

成果物対応づけ情報結果の１行目に同じ関数名が無い場合は、成果物解析情報結果の関数名を一つ下の行へ移動し（ステップＳ２１０）、同じ関数名があるか確認し（ステップＳ２１１）、同じ関数名があるところの関数グループIDを成果物対応づけ情報結果の右端に追加する（ステップＳ２１２）。

次に、成果物対応づけ情報結果の関数名を一つ下の行に移動する（ステップＳ２０７)。同様にステップＳ２０５、ステップＳ２０６、ステップS２１０、Ｓ２１１、ステップＳ２１２を繰り返し行い、成果物対応づけ情報結果の関数名を全部確認する（ステップＳ２０８)。最後に成果物対応づけ情報結果に関数グループID を追加した結果を出力する（ステップＳ２０９)。

この出力が、図１０Ｂの同じ関数名６０１Ａを手がかりにして成果物間対応づけ情報と成果物内解析情報を統合した表６００に相当する。表６００は、関数名欄６０１と、仕様書階層名６０２と、関数グループID ６０３とを備える。

次に、図１０Ｂの成果物間対応づけ情報結果と成果物間の対応づけ情報、成果物対応づけ情報を統合した表６００をもとに、図６のメインフローのＳｔｅｐ１０７及びＳｔｅｐ１０８に相当する成果物間の依存性解析及び評価が実施され、再び、ネットワーク分析によるサブグループの抽出などが行われる。その結果が、例えば、図１１Ｂに示すような分離可否の形式で出力画面に表示される。

本実施例によれば、上下流の工程にかかわる複数の成果物、例えば機能と実装、を関連付けて評価し、特にそれらの間の依存関係の関係性の複雑さ、たとえば、絡みあいの程度に関わる情報を、機械的な処理により分析の目的に応じて加工し、分析者に情報提供することができる。また、複数の条件（指標）で上下流の関係にある成果物間の依存関係を評価し、評価条件の相違を反映した複数の異なる検出結果を比較参照することで、分析の目的に応じた評価結果に関わる情報の選別に活用することができる。

次に、本発明における第二の実施の形態を、図１２Ａ、図１２Ｂを参照しながら説明する。
第二の実施の形態のシステム構成は、第一の実施の形態のシステム構成と同じである。

本実施例における上流工程、下流工程の関係の例を、図１２Ａに示す。
上流工程に関しては、第一の実施の形態と同じである。下流工程は、下流工程１と下流工程２があり、下流工程１は、第一の実施の形態の下流工程と同じである。下流工程２は、さらに、試験工程、すなわちソースコードを実装してテストした結果である。下流工程２には、下流工程１に対応した複数のテスト項目がある。このテスト項目は、一般に、自然言語や数値等で表現されたものを指す。本実施例の場合、図５の成果物対応づけ表２５０に相当するものが、さらに試験工程のテスト項目を含むものとなる。

次に、図１２Ｂに、第二の実施形態における、開発成果物分析処理の全体のフローの概念図を示す。

まず、ソースコードの実装テスト結果を含むソフトウェア開発の上下流工程の複数の成果物から、キーとなる１つの成果物を指定する（ステップ２０）。次に、ソフトウェア開発の上下流工程の複数の成果物（テスト項目を含む）間の対応づけ情報を参照する（ステップ２１）。そして、上記１つの成果物と、上下流工程の他の成果物（テスト項目を含む）間の、依存関係の複雑さを分析・評価する（ステップ２２）。

なお、先に全ての成果物を対象にステップ２１、２２を実行してから、１つの成果物を指定してステップ２０を実行するようにしても良い。

第二の実施形態では、指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、複数の成果物を構成する要素である、要求仕様、機能仕様、ソースコードに記述された関数等のモジュール、または試験工程のテスト項目のうちの、何れか複数の成果物間の依存関係の複雑さである。

本実施例によれば、第一の実施の形態に加えて、実装テスト結果を含むことで、より多くの観点で、依存関係の複雑さ、たとえば絡みあいの多寡等、を評価し、分析者に情報提供することができる。

以上、第一の実施の形態及び第二の実施の形態においては、依存関係を示すグラフは無向グラフの形態で例示したが、有向グラフの形態であっても、本発明の主旨を逸脱しない範囲で実施できるのは言うまでもない。

３A…開発成果物格納部、３Ｂ…分析関連情報格納部、４…成果物前処理部５…成果物対応づけ情報取得部、６…成果物解析情報取得部、７…照合・統合部、８…依存関係分析評価部、９…評価結果表示部、１００…ＣＰＵ、１０１…主記憶装置、１０２…外部記憶装置、１０３…可搬型記憶媒体、１０４…読取装置、１０５…入出力装置、１０６…通信装置、２００…成果物対応づけ表、５００…成果物解析結果表、６００…成果物間依存関係統合表。

Claims (15)

1. ソフトウェア開発の成果物の依存関係を評価するソフトウェア開発成果物間の依存関係評価装置であって、
   前記ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも１つの成果物を指定する手段と、
   記憶装置に記憶された成果物対応づけ表を参照して、前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を取得する手段と、
   前記指定された成果物と、前記上下流工程の他の複数の成果物間の、依存関係の複雑さを評価する手段とを備えている
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
2. 請求項１において、
   前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、顧客要求もしくは機能と、実装情報との間の依存関係の複雑さである
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
3. 請求項１において、
   前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、要求開発工程の成果物、設計工程の成果物、実装工程の成果物、試験工程の成果物のうち、任意の複数工程の成果物に定義されている記述項目相互の依存関係の複雑さである
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
4. 請求項１において、
   前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、前記複数の成果物を構成する要素である、要求仕様、機能仕様、ソースコードに記述された関数等のモジュール、または試験工程のテスト項目のうちの、何れか複数の成果物間の依存関係の複雑さである
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
5. 請求項１において、
   前記依存関係の複雑さを評価する手段が、
   連結成分ないしはクリーク等のネットワーク分析における測定対象における構成要素間の関係構造を評価する指標により、前記依存関係の複雑さを評価する
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
6. 請求項１において、
   前記依存関係の複雑さを評価する手段が、
   成果物の構成要素群を周囲から分離することが容易であるか否かを示す分離容易性に関わる指標で前記依存関係の複雑さを評価し、
   前記指標には、モジュール化の程度や容易さを評価する指標を含めることが可能である
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
7. 請求項１において、
   前記１つの成果物を指定する入出力装置と、
   前記成果物対応づけ表を参照して前記成果物間の対応づけ情報を取得するための成果物間対応づけ情報取得部と、
   前記成果物対応づけ表を参照して前記成果物内の解析情報を取得する成果物解析情報取得部と、
   前記成果物間対応づけ情報と、前記成果物内解析情報とを対応づけて成果物間依存関係統合表を生成する照合・統合部と、
   前記成果物間依存関係統合表を基に前記複数の成果物間の、依存関係の複雑さを評価する依存関係分析評価部と、
   前記評価結果を表示する評価結果表示部とを備えている
   ことを特徴とするソフトウェア開発成果物間の依存関係評価装置。
8. ソフトウェア開発の成果物の依存関係をコンピュータに行わせるソフトウェア開発成果物間の依存関係評価方法であって、
   前記ソフトウェア開発の上下流工程にかかわる複数の成果物から、キーとなる少なくとも１つの成果物を指定するステップと、
   前記ソフトウェア開発の上下流工程にかかわる複数の成果物間の対応づけ情報を、前記コンピュータの記憶装置に記憶された成果物対応づけ表を参照して、取得するステップと、
   前記指定された成果物と、前記上下流工程の他の複数の成果物間の、依存関係の複雑さを評価するステップとを含む
   ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
9. 請求項８において、
   前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、顧客要求もしくは機能と、実装情報との間の依存関係の複雑さである
   ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
10. 請求項８において、
    前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、要求開発工程の成果物、設計工程の成果物、実装工程の成果物、試験工程の成果物のうち、任意の複数工程の成果物に定義されている記述項目相互の依存関係の複雑さである
    ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
11. 請求項８において、
    前記指定された成果物と上下流工程にかかわる他の複数の成果物間の依存関係の複雑さは、前記複数の成果物を構成する要素である、要求仕様、機能仕様、ソースコードに記述された関数等のモジュール、または試験工程のテスト項目のうちの、何れか複数の成果物間の依存関係の複雑さである
    ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
12. 請求項８において、
    前記依存関係の複雑さを評価するステップが、
    連結成分ないしはクリーク等のネットワーク分析における測定対象における構成要素間の関係構造を評価する指標で実行される
    ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
13. 請求項８において、
    前記依存関係の複雑さを評価するステップが、
    成果物の構成要素群を周囲から分離することが容易であるか否かを示す分離容易性に関わる指標で実行され、
    前記指標にはモジュール化の程度や容易さを評価する指標を含めることが可能である
    ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
14. 請求項８において、
    前記存関係の複雑さの評価結果に基づき、分離容易性に関わる前記依存関係の複雑さを示す情報を表示画面に表示するステップを有する
    ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。
15. 請求項１４において、
    前記存関係の複雑さの評価結果に基づき、前記上下流工程にかかわる複数の成果物を、分離が容易な単位で分離して前記表示画面に表示する
    ことを特徴とするソフトウェア開発成果物間の依存関係評価方法。

Images