JP4360942B2 - ソフトウェア開発支援装置 - Google Patents

Description

この発明は、ソフトウェアの開発を支援するソフトウェア開発支援装置に関するものである。

従来の大規模ソフトウェアで新機能を追加する場合および既存機能の改良を行う場合、今回開発する機能と既存機能との関連をチェックし、変更するソースを特定する必要がある。この作業は多くの場合手作業で行うため、ベテランの設計者でないと変更するソースに漏れが生じ、後工程での不具合を引き起こす原因となってしまう。そこで、第１の従来技術に開示されているソフトウェア開発支援方式では、ソフトウェアの改造が影響を及ぼす範囲を見積もるようにしている（たとえば、特許文献１参照）。

また、ソフトウェアのソースの変更に際して、第２の従来技術には、ドキュメント変更時に他のドキュメントへ変更内容を自動的に反映させる複数ドキュメントの自動生成システムが開示されており（たとえば、特許文献２参照）、第３の従来技術には、変数依存関係を基にしてソースの変更を行うプログラム解析装置が開示されている（たとえば、特許文献３参照）。

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

しかしながら、第１の従来技術に記載のソフトウェア開発支援方式では、変更時の変更すべきソースリストの提示までは行っておらず、変更すべきソースリストは設計者によって抽出しなければならないという問題点があった。つまり、第１の従来技術では、ベテラン設計者でないと変更するソースに漏れが生じてしまうという問題点を完全には解決することができなかった。また、第２の従来技術に記載の発明にも、ソフトウェアの変更時における変更すべきソースリストの提示を行う仕組みは開示されていない。

また、人手による作業によってソフトウェアの変更するソースを特定できたとしても、どのような点に注意してソースの変更を行ったらよいのかは、ケースバイケースのため、ベテランの設計者でないと変更が難しいという問題点があった。そのため、第２の従来技術に開示されているドキュメントの変更内容の反映や、第３の従来技術におけるソースの変更は、型にはまった作業には有効であるが、場合によって変更方法が異なるようなソフトウェアの変更には有効ではない。

さらに、従来の大規模ソフトウェアで新機能を追加する場合および既存機能の改良を行う場合、ソースの変更を行った後に、関連する機能を特定して試験仕様を作成し、試験を行う必要がある。この際に、本来行うべき試験が漏れたために後工程での不具合を引き起したり、必要のない試験を行ったためにコストを超過してしまったりするなどの問題点があった。しかし、第１〜第３の従来技術には、このようなソース変更後の試験仕様の自動作成を行う仕組みについては開示されていない。

この発明は、上記に鑑みてなされたもので、ソフトウェアの新機能の開発や既存機能の改良を行う際に、変更すべきソースを特定してソフトウェアの開発や改良を行う作業者に対して提示するソフトウェア開発支援装置を得ることを目的とする。また、変更するソースに関する注意点をソフトウェアの開発や改良を行う作業者に対して提示するソフトウェア開発支援装置を得ることも目的とする。さらに、ソースの変更を行った後に変更に関連する機能を特定して試験仕様を自動的に作成するソフトウェア開発支援装置を得ることも目的とする。

上記目的を達成するため、この発明にかかるソフトウェア開発支援装置は、ネットワークを介してソフトウェアの開発を行うユーザの端末装置と接続され、前記ユーザによるソフトウェアの開発支援を行うソフトウェア開発支援装置であって、ソフトウェアのソースを格納するソース格納手段と、前記ソフトウェアについての要求仕様書を格納する要求仕様格納手段と、前記要求仕様書と、該要求仕様書に基づいて分類したソフトウェアの機能と、前記ソースとの間の関連を示す機能−リンク情報を格納する機能−リンク情報格納手段と、新たなソフトウェアの作成に当たり、前記ソース格納手段内から選択される流用元のソフトウェアのソースと、前記要求仕様格納手段から前記選択されたソフトウェアに対応する要求仕様書を新たなソフトウェア用にコピーするソフトウェア登録手段と、新たなソフトウェア用にコピーされた前記要求仕様書の内容が編集され、機能−リンク情報が更新された後に、前記新たなソフトウェア用の要求仕様書と前記流用元のソフトウェアの要求仕様書とから差分を抽出し、前記機能−リンク情報を用いて前記差分に関連するソースを抽出して前記端末装置に提示する変更ソース抽出手段と、を備えることを特徴とする。

この発明によれば、過去に作成されたソフトウェアを基にして新たなソフトウェアを作成する場合に、新たなソフトウェア用の要求仕様書を作成すると、ソフトウェアの開発を行うユーザが変更の必要のあるソースを抽出し、前記ユーザに対して提示するようにしたので、経験の少ないユーザでもソフトウェアのソースの変更を行うことができる。また、変更すべきソースが自動的に抽出されるので、ソフトウェアの開発期間の短縮を図ることができると同時に、ソースの変更漏れを防止して、作成されたソフトウェアの品質を向上させることができるという効果を有する。

以下に添付図面を参照して、この発明にかかるソフトウェア開発支援装置の好適な実施の形態を詳細に説明する。なお、以下では、最初にこの発明の概要を説明し、その後により具体的な例を挙げてこの発明の内容を説明する。

図１は、この発明にかかるソフトウェア開発支援装置の概略構成を模式的に示す図である。ソフトウェア開発支援装置１は、ソフトウェアの開発を行う開発者（以下、ユーザという）によって使用されるパーソナルコンピュータなどの情報処理端末装置（以下、端末装置という）２と、ＬＡＮ（Local Area Network）のようなネットワーク３を介して接続されている。

ソフトウェア開発支援装置１は、ネットワークを介して端末装置２と通信を行う通信部１１と、自ソフトウェア開発支援装置１に命令やデータなどの入力を行う入力部１２と、ソフトウェアのソースに関係する情報を格納するソース格納部１３と、ソースに応じた機能ツリーを格納する機能ツリー格納部１４と、ソースのリンク情報を格納するリンク情報格納部１５と、ソフトウェアの要求仕様書を格納する要求仕様格納部１６と、ソフトウェアの試験仕様書が格納される試験仕様格納部１７と、ソフトウェアの新規作成または既存のソフトウェアの改良を行うための新たなソフトウェアの登録処理を行うソフトウェア登録部１８と、ソース格納部１３に新たに格納されるソースの解析を行うソース解析部１９と、変更されるソースを抽出する変更ソース抽出部２０と、作成されたソフトウェアの試験仕様を作成する試験仕様書作成部２１と、を備えて構成される。

通信部１１は、端末装置２からのソフトウェアのソースやソフトウェアに関する要求仕様書の内容についての情報の受信や、変更ソース抽出部２０によって抽出されたソースの変更箇所の端末装置２への送信などの、ネットワークを介して接続される端末装置２との間の必要な情報の送受信を行う機能を有する。また、入力部１２は、ソフトウェア開発支援装置１からユーザが直接に、各処理部への指令や要求仕様書の変更などを行う場合に使用される入力手段である。

ソース格納部１３は、ソースの実態である実ファイルと、ソフトウェアに関するバージョン情報と、ソフトウェアを構成するソースファイルの名称であるソース名、ソースに付されたチェック項目を含むソフトウェア構成情報と、をソースごとに関連付けして格納する。ソフトウェアに関するバージョン情報は、ソフトウェアを識別する情報であり、たとえば、過去に作成されたあるソフトウェアに関する改変の履歴を示すための情報である。ソースに付されたチェック項目は、ソースファイルに記述されているチェック項目から抽出される。なお、このソース格納部１３に格納されているソフトウェア構成情報は、新たなソースが作成される以前に既に作成されているソフトウェアに関するソースが格納されている。

機能ツリー格納部１４は、ソースの有する機能を所定のまとまりごとに分類したソースの機能情報を格納している。この発明では、ソースの機能情報をツリー状に細分化した機能ツリーとして格納する場合を例示している。図２は、機能ツリーの構成の一例を示す図である。この図に示されるように、機能ツリーは、ソース（要求仕様書）内の機能を所定の基準で分類したまとまりごとに細分化していき、それぞれの機能の間に親子（包含）関係がある場合にそれらを線で結んでツリー状に表現したものである。この機能ツリーの上位から下位に向かって、機能の分類が詳細化される。以下では、この機能ツリーを構成する１つ１つのノードのことを、「機能」と呼ぶことにする。この図において、機能は、「機能１」、「機能２」、「機能３」、・・・の各ノードに大きく分類され、また「機能１」は「機能１．１」、「機能１．２」、・・・の各ノードに分類され、「機能１．１」はさらに「機能１．１．１」、「機能１．１．２」、「機能１．１．３」、・・・の各ノードに細かく分類されている。

図３は、標準的なサーバ−クライアントモデルのソフトウェアの場合における機能ツリーの構造の一例を示す図である。標準的なサーバ−クライアントモデルにおいては、ソフトウェアの機能は３階層に分解される。その１階層目の機能は総合的な機能を示す「メニュー」に関するものであり、２階層目の機能は「メニュー」に含まれる機能のうち表示される画面が異なる機能ごとに分類した「画面」に関するものであり、そして３階層目の機能は「画面」内に配置される「ボタン」に関するものである。この３階層目の「ボタン」は、システムが起動してイベントが生じるための起点となるものである。つまり、「ボタン」に示される機能が実行されることによってシステムが起動する。ここでは、機能ツリー格納部１４に格納される機能情報は、図３に示されるような標準的なサーバ−クライアントモデルのソフトウェアの場合における機能ツリーの構造を有するものとして説明を行う。

この機能ツリーにおいて、ソフトウェアの有する機能は、ソースを作成する前の時点では要求仕様書に記述された機能であるので、実際には、機能ツリーは後述する要求仕様書に基づいてユーザによって作成される。また、新たなソフトウェアの作成のためにコピーされた機能ツリーは、そのソフトウェアに関するソースの変更箇所の特定処理が行われる前に、ユーザによって要求仕様書に基づいたツリー構造に変更され、機能ツリーを構成する各機能は、要求仕様書内の内容を示す情報と関連付けされている必要がある。なお、この機能ツリー格納部１４にも、既に作成されているソフトウェアに関する機能ツリーが格納されているものとする。

リンク情報格納部１５は、ソース間の関連付けや、ソースと関数との関連付け、ソースと機能ツリーの最下層を構成する機能との関連付けなどを含むリンク情報を格納する。なお、特許請求の範囲における機能−リンク情報格納手段は、機能ツリー格納部１４とリンク情報格納部１５に対応し、同じく機能−リンク情報は、機能ツリーなどの機能情報とリンク情報に対応している。

要求仕様格納部１６は、ソフトウェアに対して要求される仕様が所定の形式で記述された要求仕様書を格納する。この要求仕様書は、新たに作成するソフトウェア（以下、新たなソフトウェアという）に要求される仕様がユーザによって作成される。この要求仕様格納部１６にも、既に作成されているソフトウェアについての要求仕様書が格納されているものとする。また、新たなソフトウェアの作成のためにコピーされた要求仕様書は、そのソフトウェアに関するソースの変更箇所の特定処理が行われる前に、新たなソフトウェア用にユーザによって変更されている必要がある。

試験仕様格納部１７は、作成されたソフトウェアに関して行うべき試験の内容が記述された試験仕様を格納する。この試験仕様は、既に作成されたそれぞれのソフトウェアに対して作成されているものであり、ソフトウェアを構成するソースごとに試験仕様が作成されている。ただし、作成されるソフトウェア全てに対して作成されている必要はなく、たとえば基となるソフトウェアが同一のものであれば（バージョンが異なるがソフトウェアの名称が同じソフトウェアであれば）、同一の試験仕様書を利用することができる。また、新たに作成されるソフトウェアに対して作成した試験仕様書を格納してもよい。この試験仕様格納部１７にも既に作成されているソフトウェアについての試験仕様書が格納されているものとする。

ソフトウェア登録部１８は、新たに作成されるソフトウェアまたは改良を行うソフトウェアをこのソフトウェア開発支援装置１に登録する機能を有する。具体的には、ソース格納部１３から流用元となるソフトウェア（以下、流用元のソフトウェアという）がユーザによって選択されると、流用元のソフトウェアについてのソースの実ファイル、ソフトウェア構成情報、機能ツリーおよび要求仕様書をコピーし、新たなソフトウェアに付されるバージョン番号と対応付けしてそれぞれの格納部に格納する処理を行う。なお、新たなソフトウェアに関して格納された要求仕様書は、ユーザによってたとえばネットワーク３を介して呼び出され、新たなソフトウェアに関して要求される仕様に変更される。また、機能ツリーもユーザによってたとえばネットワーク３を介して呼び出され、要求仕様書に基づいてツリー構造が変更される。このとき、要求仕様書の記載内容と機能ツリーの各機能との対応関係が、ユーザによって要求仕様書内に記録される。

ソース解析部１９は、ソフトウェア登録部１８によってソースが新たにコピーされたとき、またはソースが変更されたときを起点としてそのソースについての解析を行う。具体的には、ソースとソースとの間の関係や、関数とソースとの関係、また機能ツリーの最下層の機能とソース（関数）との対応関係を抽出して、それらの対応付けを含むリンク情報を作成して、リンク情報格納部１５に格納する。

変更ソース抽出部２０は、新たなソフトウェアについて、流用元のソフトウェアとの違いを両者の要求仕様書に基づいて抽出し、変更すべきソースを機能ツリー、リンク情報およびソフトウェア構成情報を利用して特定して、ユーザに対して提示する機能を有する。また、変更ソース抽出部２０は、抽出したソースについてのチェック項目をソース格納部１３のソフトウェア構成情報から抽出して、ユーザに対して提示する機能も有する。これにより、新たなソフトウェアの作成時において、流用元のソフトウェアのソースの変更すべき箇所がユーザ対して提示される。また、その際の注意事項もあわせて提示される。

試験仕様書作成部２１は、ユーザによるソース変更処理の後に、新たなソフトウェアのうち変更されたソースに関する試験仕様書を、流用元のソフトウェアのバージョン番号の試験仕様書を基に作成し、ユーザに対して提示する機能を有する。これによって、新たなソフトウェアのソース変更後に行うべき試験の内容のみ、すなわち変更されたソースに関して行うべき試験の内容のみ、がユーザに対して提示される。

つぎに、このようなソフトウェア開発支援装置１を用いたソフトウェアの作成手順について説明する。図４は、ソフトウェアの作成手順を示すフローチャートである。まず、端末装置２からユーザによってソフトウェアの作成の指示が入力されると、ソフトウェア開発支援装置１のソフトウェア登録部１８は、ソース格納部１３に格納されているソフトウェアのバージョン情報を一覧にしてユーザの端末装置２に表示する（ステップＳ１）。ユーザは、このバージョン情報の一覧から新規に作成しようとしているソフトウェア（新たなソフトウェア）の基となるソフトウェアのバージョン情報を選択する。このユーザによる選択結果を受けると、ソフトウェア開発支援装置１のソフトウェア登録部１８は、選択されたバージョンのソフトウェアについてのソースの実ファイル、ソースに関するチェック項目を含むソフトウェア構成情報、機能ツリーおよび要求仕様書のコピーを作成して、それぞれの格納部に新たなソフトウェアのバージョンと対応付けて格納する（ステップＳ２）。このとき、ソース解析部１９は、ソース格納部１３内に新たにソースがコピーされたので、コピーされたソースについてソース解析を行い、その結果をリンク情報としてリンク情報格納部１５に新たに作成されるソフトウェアに関連付けて格納する。

この後、ユーザによって、コピーされた要求仕様書、機能ツリーなどの内容が新たなソフトウェアに合わせて変更される。具体的には、要求仕様書を新たなソフトウェアに要求される仕様に合わせて変更し、この変更に合わせて機能ツリーも変更する。またこのとき、機能ツリーの各機能と要求仕様書に記載される内容との間の対応付けも行われる。これらの変更結果が反映されたものが、それぞれ機能ツリー格納部１４、要求仕様格納部１６に格納される（ステップＳ３）。

つぎに、ユーザから変更するソースの抽出の指示を受けると、ソフトウェア開発支援装置１の変更ソース抽出部２０は、変更されるソースを抽出する処理を行い（ステップＳ４）、その結果をユーザに対して提示する。このとき、ソースの変更に関する注意事項であるチェック項目をユーザに対して提示してもよい。ユーザは、ソフトウェア開発支援装置１から提示された変更すべきソースを、チェック項目が表示されている場合にはそれを参照しながら変更する。この変更内容は、ソース格納部１３の対応するソースに反映される（ステップＳ５）。ソース解析部１９は、ソースが変更されたので、変更されたソースについてソース解析を行い、その結果をリンク情報格納部１５に上書き保存する。

ソースの変更処理の終了後、ユーザの端末装置２から変更したソースに関する試験仕様書の作成の指示を受けると、ソフトウェア開発支援装置１の試験仕様書作成部２１は、試験仕様格納部１７から抽出した流用元のソフトウェアについての試験仕様に基づいて、上記のステップＳ４で抽出されたソースに関係する試験仕様を抽出して、新たなソフトウェア用の試験仕様書を作成し、ユーザの端末装置２に提示する（ステップＳ６）。ユーザは、提示された試験仕様書を基にして新たなソフトウェアの試験を行い、ソフトウェアの作成処理が終了する。

ここで、上記ステップＳ４における変更ソース抽出処理について、図５のフローチャートを参照しながら詳細に説明する。まず、ソフトウェア開発支援装置１の変更ソース抽出部２０は、ユーザからソースの変更箇所の抽出処理の実行の命令を受けると、新たなソフトウェアの要求仕様書と、該新たなソフトウェアの基となったバージョンのソフトウェア（流用元のソフトウェア）の要求仕様書とを要求仕様格納部１６から抽出する（ステップＳ１１）。抽出した新たなソフトウェアと流用元のソフトウェアの要求仕様書を比較し、差分を抽出する（ステップＳ１２）。その差分を解析し、差分がどの機能ツリーのどの機能に該当するのか、つまりどの機能が変更されたのかを特定する。この特定は、要求仕様書の内容と機能ツリーの各機能との間の関係が対応付けされているので、要求仕様書上の差分の位置から、機能ツリーにおける位置（機能）が特定され、さらにその位置（機能）から機能ツリーを上位から下位へとたどり、最下層の機能を抽出することによって行われる（ステップＳ１３）。これは、最下層の機能は、イベントが生じるための起点に該当し、対応する関数が必ず存在することによるものである。その後、リンク情報格納部１５とソース格納部１３を参照して、最下層の機能に対応するソースと、それに関連するソースを抽出する（ステップＳ１４）。そして、抽出したソースを一覧で表示し（ステップＳ１５）、変更ソース抽出処理が終了する。

なお、変更ソース抽出部２０は、ステップＳ１４において、ソース格納部１３のソフトウェア構成情報から、抽出したソースに対応するチェック項目もソースと同時に抽出し、ステップＳ１５において、抽出したソース一覧とともに該ソースの変更時における注意事項としてのチェック項目も表示するようにしてもよい。

また、上記ステップＳ６における試験仕様書作成処理について、図６のフローチャートを参照しながら説明する。まず、ソフトウェア開発支援装置１の試験仕様書作成部２１は、ユーザから試験仕様書作成処理の実行の命令を受けると、流用元のソフトウェアについての試験仕様を試験仕様格納部１７から抽出し、その内容をコピーして新たなソフトウェア用の試験仕様書のデータを作成する（ステップＳ２１）。このとき、流用元のソフトウェアの試験仕様書の内容と流用元の機能ツリーの各機能とは対応付けがなされており、この流用元の機能ツリーと新たなソフトウェア用の機能ツリーとの対応関係から、新たなソフトウェアの機能ツリーと流用元の試験仕様書の内容との間の関連付けが行われる。さらに、試験仕様書作成部２１は、作成された試験仕様の中から、上記ステップＳ１４で変更ソース抽出部２０によって抽出されたソースと対応付けられた試験仕様を抽出する（ステップＳ２２）。ここで、試験仕様格納部１７に格納されている各試験仕様はソースと予め対応付けられており、この対応関係は、コピーされたもの（新たなソフトウェア）でもその関係は維持されるので、試験仕様書作成部２１は、ステップＳ１４で抽出されたソースの情報を得ることができれば、そのソースに対応する試験仕様を得ることができる。そして、試験仕様書作成部２１は、抽出された試験仕様を所定の形式に配置した試験仕様書を作成し（ステップＳ２３）、ユーザに対して提示して試験仕様書作成処理が終了する。

以上が、この発明のソフトウェア開発支援装置１の構成と動作処理の概要である。以下では、標準的なサーバ−クライアントシステムにおけるソフトウェア開発支援装置の具体例を説明する。ここでは、Ｗｅｂシステムのように、ユーザの端末装置からグラフィカルユーザインタフェースを通じてソフトウェアの開発支援を行う場合を例に挙げる。

図７は、ソフトウェア開発支援装置の構成の一例を模式的に示す図である。図１と同様に端末装置２が接続されたＬＡＮ３ａに、ソフトウェア開発支援装置１ａが接続されている。このソフトウェア開発支援装置１ａは、バージョン管理データベース３１、ソース管理データベース３２、機能ツリーデータベース３３、リンク情報データベース３４、要求仕様データベース３５、試験仕様データベース３６、データベースインタフェース部３７、バージョン一覧表示部３８、バージョン登録部３９、ソース解析部４０、要求仕様書作成部４１、機能ツリー作成部４２、ソース管理部４３、試験仕様書作成部４４および端末インタフェース部４５を備えて構成される。なお、各データベース３１〜３６は、ソフトウェア開発支援装置１ａ内に設けられる必要はなく、ソフトウェア開発支援装置１ａとは別個の記憶装置に作成してもよい。

バージョン管理データベース３１は、ソフトウェアのバージョン情報を管理するバージョンテーブルを有して構成される。図８は、バージョンテーブルの構成の一例を示す図である。この例のバージョンテーブルは、フィールドとして「バージョンＩＤ」、「バージョン名」、「基になったバージョンＩＤ」を有している。「バージョンＩＤ」は、ソースのバージョンを一意に識別することが可能な識別子であり、この例では各バージョンに対して数字を割り当てている。「バージョン名」は、ソフトウェアに対してユーザが付けるバージョンの情報であり、任意の文字列が入力される。この「バージョン名」は、「バージョンＩＤ」と異なり、主にユーザなどの人間によるバージョン情報の識別に用いられるものである。「基になったバージョンＩＤ」は、情報が格納されるソフトウェアの基になったソフトウェアのバージョンＩＤを示すものである。すなわち、情報が格納されるソフトウェアのコピー元（流用元）であるソフトウェアのバージョンＩＤである。この基になったバージョンＩＤは、ユーザが選択するものであるが、ユーザが選択しなかった場合には空欄となる。

ソース管理データベース３２は、ソフトウェアを構成するソースに関する情報を管理するソーステーブルと、ソースに付随するチェック項目を管理するソースチェック項目テーブルと、ソースの実ファイルと、を格納する。図９−１は、ソーステーブルの構成の一例を示す図であり、図９−２は、ソースチェック項目テーブルの構成の一例を示す図である。

ソーステーブルは、フィールドとして「ソースＩＤ」、「ソース名」、「バージョンＩＤ」、「変更フラグ」、「関連する機能ツリーＩＤ」、「実ファイルの場所」を有している。「ソースＩＤ」は、ソースを一意に識別することが可能な識別子であり、この例では各ソースに対して数字を割り当てている。「ソース名」は、ソースのソースファイル名である。「バージョンＩＤ」は、情報が格納されるソースが含まれるソフトウェアのバージョンを識別する識別子であり、バージョンテーブルで管理されるバージョンＩＤが使用される。「変更フラグ」は、ソースが変更されたか否かを示すフラグであり、「０」が入力されるときは変更がないことを示し、「１」が入力されるときは変更されたことを示している。「関連する機能ツリーＩＤ」は、ソースに関連する機能ツリーを識別するためのフィールドであり、後述する機能ツリーデータベース３３で使用される機能ツリートップＩＤまたは機能ツリーデータＩＤが使用される。「実ファイルの場所」は、ソースが格納される場所であり、パス名で記述される。

ソースチェック項目テーブルは、フィールドとして「ソースＩＤ」、「チェック項目ＩＤ」、「チェック項目」を有している。「ソースＩＤ」は、ソーステーブルで管理されているソースＩＤであり、チェック項目の対象となるソースを示している。「チェック項目ＩＤ」は、ソースＩＤに対応するソースの中でチェック項目を識別する識別子である。チェック項目は１つのソースに対して１つとは限らず、複数存在してもよい。ここでは、ソースＩＤに対して連番となるように番号付けがなされている。これらの「ソースＩＤ」と「チェック項目ＩＤ」の組合せで１つのキーとなり、後述するチェック項目を識別する。「チェック項目」は、ソースに関して注意すべき事項を示す項目であり、たとえば、ソースの変更時の注意しなければならない事項や、ソースに対して決められた事項などである。

ソースの実ファイルは、このソース管理データベース３２に格納され、ソース名と実ファイルの場所によってソーステーブルと対応付けがされている。なお、格納されるソースの実ファイルには、ファイルの最終更新者と更新日が属性として記憶されるものとする。

機能ツリーデータベース３３は、上述した図３に示される３階層の機能ツリーをデータベースとして管理しており、１階層目の機能を管理する機能ツリートップテーブルと、２階層目以下の機能を管理する機能ツリーデータテーブルの２つのテーブルから構成される。図１０−１は、機能ツリートップテーブルの構成の一例を示す図であり、図１０−２は、機能ツリーデータテーブルの構成の一例を示す図である。

機能ツリートップテーブルは、フィールドとして「機能ツリートップＩＤ」、「バージョンＩＤ」、「機能ツリートップ名称」を有している。「機能ツリートップＩＤ」は、機能ツリーの１番上の階層を一意に識別する識別子であり、この例ではアルファベットの後に連番を付した文字列を使用している。「バージョンＩＤ」は、バージョン管理データベース３１のバージョンテーブルで管理されるバージョンＩＤである。これにより、機能ツリーはソフトウェアと対応付けされる。「機能ツリートップ名称」は、ユーザによって機能ツリーを識別するために付される名称であり、ユーザが機能ツリーを編集する際に任意に入力することができる。

機能ツリーデータテーブルは、フィールドとして「機能ツリーデータＩＤ」、「バージョンＩＤ」、「機能ツリーデータ名称」、「機能ツリー親ＩＤ」、「階層数」を有している。「機能ツリーデータＩＤ」は、機能ツリーの２階層目以下のノードを一意に識別する識別子であり、この例ではアルファベットの後に連番を付した文字列を使用している。「バージョンＩＤ」は、バージョン管理データベース３１のバージョンテーブルで管理されるバージョンＩＤである。「機能ツリーデータ名称」は、ユーザによって機能ツリーを構成するそれぞれの機能を識別するための名称であり、ユーザが機能ツリーを編集する際に任意に入力することができる。「機能ツリー親ＩＤ」は、情報が格納される機能の親にあたる機能を示すものであり、機能ツリートップテーブルの機能ツリートップＩＤまたはこの機能ツリーデータテーブルの機能ツリーデータＩＤが使用される。これによって、機能間の親子関係が把握され、機能ツリーを再現することができる。「階層数」は、該機能が機能ツリーの何階層目に属するかを示すものである。

リンク情報データベース３４は、ソースで使用される関数を管理するソース−関数間の関連テーブルと、関数間の呼び出しを管理する関数間の呼び出し関連テーブルと、ソース間のインクルード関係を管理するソース間のインクルード関連テーブルと、イベントとイベントが呼び出す関数を関連付けるイベント−関数間の関連テーブルと、を含んで構成される。図１１−１は、ソース−関数の関連テーブルの構成の一例を示す図であり、図１１−２は、関数間の呼び出し関連テーブルの構成の一例を示す図であり、図１１−３は、ソース間のインクルード関連テーブルの構成の一例を示す図であり、図１１−４は、イベント−関数の関連テーブルの構成の一例を示す図である。

ソース−関数間の関連テーブルは、フィールドとして「関数ＩＤ」、「バージョンＩＤ」、「関数名」、「ソースＩＤ」を有している。「関数ＩＤ」は、関数を一意に識別するための識別子であり、ここでは関数に対して数字を付している。「バージョンＩＤ」は、バージョン管理データベース３１のバージョンテーブルで管理されているバージョンＩＤであり、関数が使用されるソフトウェアを示している。「関数名」は、ソース内にある関数の名称である。「ソースＩＤ」は、ソース管理データベース３２のソーステーブルで管理されているソースＩＤであり、関数が使用されるソースを示している。

関数間の呼び出し関連テーブルは、フィールドとして「関数ＩＤ」と「呼び出し関数ＩＤ」を有している。「関数ＩＤ」はソース−関数間の関連テーブルで管理されている関数ＩＤである。「呼び出し関数ＩＤ」は当該関数が、その関数内で呼び出している関数ＩＤである。この呼び出し関数ＩＤに格納される関数ＩＤも、ソース−関数間の関連テーブルで管理されている関数ＩＤが使用される。なお、複数の関数を呼び出している場合には、１つの関数ＩＤに対して複数の呼び出し関数ＩＤが存在することとなる。

ソース間のインクルード関連テーブルは、フィールドとして「ソースＩＤ」と「インクルードソースＩＤ」を有している。「ソースＩＤ」は、ソース管理データベース３２のソーステーブルで管理されているソースＩＤであり、「インクルードソースＩＤ」も同様である。このソース間のインクルード関連テーブルは、あるソースにおいて、別のソースをインクルードしている場合に、インクルードしているソースのソースＩＤとリンク付けするテーブルである。なお、あるソースが、複数のソースをインクルードしている場合には、１つのソースＩＤに対して複数のインクルードソースＩＤが存在することとなる。

イベント−関数の関連テーブルは、フィールドとして「機能ツリーデータＩＤ」と「関数ＩＤ」を有している。「機能ツリーデータＩＤ」は、機能ツリーデータベース３３の機能ツリーデータテーブルで管理されている機能ツリーデータＩＤである。「関数ＩＤ」は、ソース−関数の関連テーブルで管理されている関数ＩＤと同一のものである。このイベント−関数の関連テーブルは、機能ツリーの最下層の機能と関数とを関連付けするものである。上述したように、機能ツリーの最下層の機能は、システムが起動するための起点となるものであり、起点となるイベントが関数を呼び出す際に、このテーブルが使用される。なお、１つのイベント（機能ツリーの最下層の機能ツリーデータＩＤ）に対して呼び出される関数は必ず１つだけ存在する。なお、イベント−関数の関連テーブルの情報の新しいバージョン用のレコードは、バージョン登録時に流用元のソフトウェアのイベント−関数の関連テーブルを基に自動的に作成されるが、機能ツリー編集時に、ユーザによって更新することも可能である。

要求仕様データベース３５は、ソフトウェアのあるバージョンに対応する要求仕様書の実体ファイルと、その要求仕様書の実体ファイルの場所を管理する要求仕様テーブルによって構成される。この例では、要求仕様書は、ＵＭＬ（Unified Modeling Language；統一モデリング言語）で記述されるものとする。このＵＭＬで定義されたユースケースモデルは、ユースケース定義書により記述される。ユースケース定義書の中には、ユースケース図、アクティビティ図、イベントフローなどがある。このソフトウェア開発支援装置１ａで管理する要求仕様書は、各ユースケースが章となり、ユースケースごとのイベントフロー（シナリオ）が節となる構造となっている。図１２は、要求仕様書の構造および要求仕様書の一例を示す図である。この図１２において、節であるイベントフロー（シナリオ）において、文章中に「Ｅ１０１」などの表現が見られるが、これは文章が機能ツリーのどの機能に対応するかを、機能ツリーの機能に付された識別子（機能ツリートップＩＤまたは機能ツリーデータＩＤ（以下では、機能ツリートップＩＤと機能ツリーデータＩＤを区別する必要がない場合には、機能ＩＤという））を用いて示すものである。機能ＩＤのみ（たとえば、Ｅ１０１）で機能記述の開始位置を示しており、「スラッシュ（／）＋機能ＩＤ」（たとえば、／Ｅ１０１）で機能記述の終了位置を示している。これにより、要求仕様書内の文章や図などの構成要素と機能ツリーの機能とが対応付けられる。また、この例では、要求仕様書の実体はＸＭＬ（eXtensible Markup Language）ファイルであるものとする。図１３は、図１２に示される要求仕様書をＸＭＬで記述したファイルの内容を示す図である。ＸＭＬファイルでは、要求仕様書の章、節（ＵＭＬで記述された要求仕様書におけるユースケースとイベントフローにそれぞれ対応するもの）が表現されており、ファイルの内容中の＜Ｅ１０１＞や＜／Ｅ１０１＞で、その内容がどの機能に対応するかを表現している。

図１４は、要求仕様テーブルの構成の一例を示す図である。要求仕様テーブルは、フィールドとして「要求仕様ＩＤ」、「バージョンＩＤ」、「ＸＭＬ実ファイル」を有している。「要求仕様ＩＤ」は、要求仕様書を一意に識別するための識別子である。「バージョンＩＤ」は、バージョン管理データベース３１のバージョンテーブルで管理されているバージョンＩＤである。これによって、ソフトウェアと該ソフトウェアについての要求仕様書とが対応付けされる。「ＸＭＬ実ファイル」は、要求仕様書の実体ファイルであるＸＭＬファイルが保管されているパスを表している。

試験仕様データベース３６は、ソフトウェアに対して実行される試験仕様を記述した試験仕様書を格納するデータベースであり、試験仕様テーブルから構成される。図１５は、試験仕様書の構造の一例を示す図である。この試験仕様書は、ソフトウェアの機能ごとに確認すべき事項が列挙された構成となっている。図１６は、試験仕様テーブルの構成の一例を示す図である。試験仕様テーブルは、フィールドとして「試験仕様ＩＤ」、「参照元機能ツリーデータＩＤ」、「機能ツリーデータＩＤ」、「試験仕様」を有している。「試験仕様ＩＤ」は、試験仕様書を一意に識別するための識別子である。「参照元機能ツリーデータＩＤ」は、ソフトウェアを登録するときにコピー元となった流用元のソフトウェアについての機能ツリーデータベース３３で管理されている機能ＩＤである。「機能ツリーデータＩＤ」は、ソフトウェアの機能ツリーの各機能について機能ツリーデータベース３３で管理されている機能ＩＤである。「試験仕様」は、試験仕様の詳細を格納している。以上に示されるように、試験仕様は、ソフトウェアの機能ごとに予め作成されている。なお、この試験仕様テーブルの新たなソフトウェア用のレコードは、試験仕様抽出時に参照元バージョン（すなわち、流用元のソフトウェアのバージョン）の試験仕様を基にして作成され、試験仕様書画面において更新される。また、この試験仕様は、新たなソフトウェアが作成される際にその内容を作成してもよい。

以上説明したバージョン管理データベース３１、ソース管理データベース３２、機能ツリーデータベース３３、リンク情報データベース３４、要求仕様データベース３５および試験仕様データベース３６には、既に作成されたソフトウェアについての情報が予め格納されている状態にあるものとする。

端末インタフェース部４５は、ソフトウェアの開発を行うユーザの端末装置２に対して、ソフトウェア開発の支援を行うための情報を、ＬＡＮを介して送受信する機能を有する。また、データベースインタフェース部３７は、後述する各処理部が上記の各データベースにアクセスするためのインタフェースとなる部分である。

バージョン一覧表示部３８は、ユーザによる新規のソフトウェアの作成または既存のソフトウェアの改良に関する各種の処理のインタフェースとなるバージョン一覧画面を表示し、ユーザからの指示を受け付ける機能を有する。

図１７は、バージョン一覧画面の一例を示す図である。バージョン一覧画面１７０には、自装置内に格納されているソフトウェアのバージョンを一覧表示するバージョン一覧表示領域１７１と、このバージョンの一覧から作成するまたは変更するソフトウェアの基となるバージョンを選択するラジオボタン１７２と、ユーザが実行することのできる処理を実行するための５つのボタン１７３〜１７７と、が配置されている。バージョン一覧表示領域１７１には、バージョン管理データベース３１のバージョンテーブル内から抽出されたバージョン名が表示される。ラジオボタン１７２は、バージョン一覧表示領域１７１の中からバージョンを１つだけ選択することができるボタンである。「バージョン追加」ボタン１７３は、バージョン登録部３９と関連付けされており、このボタンを押す（クリックする）とバージョン登録部３９が起動される。「要求仕様書」ボタン１７４は、要求仕様書作成部４１と関連付けされており、このボタンを押すと要求仕様書作成部４１が起動される。「機能ツリー」ボタン１７５は、機能ツリー作成部４２と関連付けされており、このボタンを押すと機能ツリー作成部４２が起動される。「ソース一覧」ボタン１７６は、ソース管理部４３と関連付けされており、このボタンを押すとソース管理部４３が起動される。「試験仕様書」ボタン１７７は、試験仕様書作成部４４と関連付けされており、このボタンを押すと試験仕様書作成部４４が起動される。

バージョン登録部３９は、新たなソフトウェアの作成指示をユーザから受けると、流用元のソフトウェアについてのソフトウェア構成情報、機能ツリー、リンク情報および要求仕様書をコピーして、新たなソフトウェアに対応付けしてそれぞれのデータベース３２〜３５に格納する機能を有する。

図１８は、バージョン登録画面の一例を示す図である。バージョン登録画面１８０には、追加するバージョン名を入力するための文字入力フィールド１８１と、追加するバージョンの流用元バージョンを選択するための選択入力フィールド１８２と、２つのボタン１８３，１８４が設けられている。文字入力フィールド１８１は、新たなソフトウェアについてのバージョン名を入力するためのフィールドであり、選択入力フィールド１８２は、新たなソフトウェアを作成するにあたり流用元となるソフトウェアのバージョンを選択入力するフィールドである。この選択入力フィールド１８２には、バージョン管理データベース３１のバージョンテーブル内の「バージョン名」に格納されている内容が一覧表示される。「登録」ボタン１８３は、上記文字入力フィールド１８１と選択入力フィールド１８２に入力された内容の登録処理を実行し、バージョン一覧画面１７０に戻る処理を行うボタンである。「キャンセル」ボタン１８４は、上記文字入力フィールドと選択入力フィールドに入力された内容の登録処理を実行しないで、バージョン一覧画面１７０に戻る処理を行うボタンである。

ソース解析部４０は、新たにソースがコピーされたときまたはソースの内容が変更されたときに、そのソースを解析し、ソース−関数間の関連、関数間の呼び出し関連、ソース間のインクルード関連を抽出し、リンク情報データベース３４に格納する機能を有する。また、機能ツリーを利用してその最下層の機能（イベント）と関数の間の関連も抽出し、リンク情報データベース３４のイベント−関数の関連テーブルに格納する機能も有する。

要求仕様書作成部４１は、ユーザによる新たなソフトウェアについての要求仕様書の作成指示を受けると、その新たなソフトウェアの要求仕様書を編集するための要求仕様書画面を表示する機能を有する。この要求仕様書の編集は、要求仕様データベース３５に格納されている要求仕様の内容の変更や追加のほかに、対応する機能ツリーの各機能と要求仕様の内容との間の対応付けを含む。編集された内容は、要求仕様データベース３５の該当するソフトウェアに関する内容に反映される。

図１９は、要求仕様書画面の一例を示す図である。要求仕様書画面１９０には、要求仕様データベース３５に格納される要求仕様書の実体ファイルの内容が表示され、３つのボタン１９１〜１９３が設けられている。「保存」ボタン１９１は、画面に表示された要求仕様書画面１９０を保存する処理を行う。「機能ツリー」ボタン１９２は、この要求仕様書と関連付けされている機能ツリーを機能ツリーデータベース３３から抽出し、その機能ツリーの機能と要求使用書の内容との関連付けを行うための機能挿入画面を表示する。「戻る」ボタン１９３は、図１７のバージョン一覧画面１７０に戻る処理を実行する。

図２０は、機能挿入画面の一例を示す図である。機能挿入画面２００は、要求仕様書画面１９０で表示された要求仕様書に記述された内容をツリー表示するツリー表示領域２０１と、３つのボタン２０３〜２０５が設けられている。ツリー表示領域２０１のツリー状に表示された各機能にはラジオボタン２０２が設けられており、これらのうちの１つの機能を選択することができる。「開始位置挿入」ボタン２０３は、ラジオボタン２０２で選択された機能の開始位置を図１９の要求仕様書に登録する処理を行う。「終了位置挿入」ボタン２０４は、同じくその機能の終了位置を図１９の要求仕様書に登録する処理を行う。「戻る」ボタン２０５は、図１９の要求仕様書画面１９０に戻る処理を実行する。

機能ツリー作成部４２は、ユーザによる新たなソフトウェアについての機能ツリーの作成指示を受けると、その新たなソフトウェアの機能ツリーを作成するための画面を表示する機能を有する。作成された内容は、機能ツリーデータベース３３の該当するソフトウェアに関する内容に反映される。

図２１は、機能ツリー画面の一例を示す図である。機能ツリー画面２１０は、ソフトウェアのあるバージョンの機能ツリーを作成するための上部画面２１１と、機能の追加、更新用の下部画面２１５と、から構成される。上部画面２１１には、図１７のバージョン一覧画面１７０のバージョン一覧表示領域１７１で選択されたソフトウェアのバージョンの機能ツリー２１２と、複数のボタン２１４が表示されている。この機能ツリー２１２の各機能にはラジオボタン２１３が設けられており、このラジオボタン２１３で機能ツリー２１２の中の１つの機能のみが選択され、選択された機能に対してボタン２１４で種々の処理を実行する。たとえば、「追加」ボタン２１４ａは、機能ツリー２１２に新たに機能を追加する処理を行い、「削除」ボタン２１４ｂは、ラジオボタン２１３で選択された機能を削除する処理を行う。また、下部画面２１５では、上部画面２１１で選択された機能の名称の編集や、関数の変更などの変更処理を行うことが可能なオブジェクトが設けられている。

ソース管理部４３は、ユーザによる新たなソフトウェアについてのソースの変更指示を受けると、そのソフトウェアを構成するソースの一覧をソース管理データベース３２から抽出して、ソース一覧画面を表示する機能を有する。また、ユーザによる変更されるソースの抽出の指示を受けると、変更されるソースの一覧を表示したソース一覧画面を表示する機能も有する。さらに、ソース一覧画面から選択されたソースの編集を行う画面を提供し、その結果変更された内容をソース管理データベース３２に反映させる機能も有する。

図２２は、ソース一覧画面の一例を示す図である。ソース一覧画面２２０は、予め設定された条件またはユーザによって設定された条件を満たすあるバージョンのソースの一覧を表示するソース一覧表示領域２２１と、流用元のソフトウェアから新たなソフトウェアを作成する場合に、変更されるソースの抽出を実行する「変更ソース抽出」ボタン２２２と、抽出されたソースの変更を行う画面を表示する「ソース変更」ボタン２２３と、図１７のバージョン一覧画面１７０に戻る「戻る」ボタン２２４と、を備えている。

試験仕様書作成部４４は、ユーザによる新たなソフトウェアについての試験仕様書の作成指示を受けると、変更したソースが他の機能に及ぼす影響を特定し、どの機能の試験を実施したらよいかを選択し、試験仕様書を自動的に生成してユーザの端末装置２に試験仕様書画面として表示する機能を有する。このとき、試験仕様書作成部４４は、新たなソフトウェアのコピー元である流用元のソフトウェアについての試験仕様を試験仕様データベース３６からコピーしたものに基づいて、試験仕様書の作成を行う。

図２３は、試験仕様書画面の一例を示す図である。試験仕様書画面２３０は、試験仕様の内容を表示する試験仕様表示部２３１と、ソースが変更された箇所の試験仕様を抽出する「試験仕様抽出」ボタン２３２と、試験仕様書画面２３０に表示された内容を保存する「保存」ボタン２３３と、図１７のバージョン一覧画面１７０に戻る「戻る」ボタン２３４と、を備えている。

このような構成を有するソフトウェア開発支援装置１ａは、中央演算処理装置、メモリ、ハードディスクなどを備える情報処理端末によって構成することができる。

ここで、各処理部の動作について説明する。最初に、バージョン一覧表示部３８の動作処理について説明する。ユーザの端末装置２からソフトウェア開発支援装置１ａにアクセスがあると、バージョン一覧表示部３８は、図１７に示されるようなバージョン一覧画面１７０を表示する。そして、このバージョン一覧表示領域１７１中のいずれかのボタン１７３〜１７７がユーザによって選択されると、そのボタンに関連付けされた処理部による処理が実行される。

つぎに、バージョン登録部３９の動作処理について説明する。図２４は、バージョン登録部によるバージョン登録の処理手順を示すフローチャートである。図１７のバージョン一覧画面１７０のバージョン追加ボタン１７３が押される（クリックされる）と、バージョン登録部３９は図１８に示されるようなバージョン登録画面１８０を表示する（ステップＳ１０１）。ユーザによって図１８のバージョン登録画面１８０のバージョン名の文字入力フィールド１８１と流用元バージョンの選択入力フィールド１８２が入力され、登録ボタン１８３が押されると、バージョン登録部３９は、そのバージョン名と流用元バージョンのバージョンＩＤを取得する（ステップＳ１０２）。バージョン登録部３９は、取得したバージョン名を有する新たなソフトウェア用のレコードを、バージョン管理データベース３１に挿入する（ステップＳ１０３）。また、要求仕様データベース３５から流用元のソフトウェアのバージョンのＸＭＬ実ファイルの場所を取得し、取得したＸＭＬ実ファイルをコピーするとともに、要求仕様データベース３５に新たなソフトウェアのバージョン用のレコードを挿入する（ステップＳ１０４）。ついで、バージョン登録部３９は、機能ツリーデータベース３３の機能ツリートップテーブルと機能ツリーデータテーブルから流用元バージョンのデータを取得し、取得したデータのコピーを新しいバージョン用のレコードとして機能ツリートップテーブルと機能ツリーデータテーブルに挿入する（ステップＳ１０５）。

また、ソース管理データベース３２のソーステーブルから流用元バージョンのソース名、実ファイルの場所を取得してメモリに保持する。その後、取得したデータに基づいてソースのコピーを行い、ソースの内容を新しいバージョン用のレコードとしてソーステーブルに挿入し、さらに、コピーしたソース内のある位置に所定の形式に則って記述されている内容から、ソーステーブルの「関連する機能ツリーＩＤ」とソースチェック項目テーブルのレコードを作成する（ステップＳ１０６）。図２５は、ソースの記述内容の一例を示す図である。このソースの記述内容において、たとえば、行２５１に示されるように「//kinou()」で始まる行に機能の内容が表示されているものとし、この機能に対して関連する機能ツリーＩＤが作成される。なお、関連する機能ツリーＩＤの作成にあたっては、すでに作成された機能ツリーＩＤと重複しないように、機能ツリーデータベース３３が参照される。また、行２５２に示されるように、「//check(n)」（ｎはなくてもよく、ある場合には数字など）で始まる行に、このソースに関するチェック項目が記述される。バージョン登録部３９は、このようなソース中の所定の文字列を検出し、その文字列の後に続くテキストをソースチェック項目テーブルに格納する。そして、バージョン登録部３９は、以上の処理が終了すると図１７のバージョン一覧画面１７０を表示し（ステップＳ１０７）、バージョン登録処理を終了する。なお、ステップＳ１０１でユーザによって流用元のバージョンが選択されなかった場合には、それぞれのデータベースのテーブルには空の情報が挿入され、ユーザはそれぞれのテーブルをはじめから作成する。

つぎに、要求仕様書作成部４１の動作処理について説明する。図２６は、要求仕様書作成部による要求仕様書画面の表示処理手順を示すフローチャートである。図１７のバージョン一覧画面１７０において、バージョン一覧表示領域１７１中のいずれかのバージョンがラジオボタン１７２で選択された状態で要求仕様書ボタン１７４が押されると、要求仕様書作成部４１は、選択されたソフトウェアのバージョンのバージョンＩＤをバージョン管理データベース３１から取得する（ステップＳ１１１）。ついで、バージョンＩＤを用いて、要求仕様データベース３５からそのバージョンＩＤに対応する要求仕様書が記述されたＸＭＬ実ファイルの場所を取得する（ステップＳ１１２）。取得したＸＭＬ実ファイルを解析し（ステップＳ１１３）、図１９に示されるような要求仕様書画面１９０をユーザの端末装置２に表示し（ステップＳ１１４）、要求仕様書画面１９０の表示処理が終了する。

図２７は、要求仕様書作成部による機能挿入画面の表示処理手順を示すフローチャートである。図１９の要求仕様書画面１９０において、要求仕様書の内容が表示された領域中のいずれかの位置にカーソルが置かれた状態で機能ツリーボタン１９２が押されると、要求仕様書作成部４１は、要求仕様書画面１９０内のカーソルの位置を取得するとともに、表示されている要求仕様書のバージョンＩＤを要求仕様データベース３５から取得する（ステップＳ１２１）。ついで、機能ツリーデータベース３３の機能ツリートップテーブルと機能ツリーデータテーブルを参照して、取得したバージョンＩＤと同じデータを取得し（ステップＳ１２２）、その内容に基づいて機能ツリーを作成する（ステップＳ１２３）。そして、図２０に示されるような作成した機能ツリーを含む機能挿入画面２００をユーザの端末装置２に表示し（ステップＳ１２４）、機能挿入画面２００の表示処理を終了する。

図２８は、要求仕様書作成部による要求仕様書への機能の開始位置挿入処理手順を示すフローチャートである。図２０の機能挿入画面２００において開始位置挿入ボタン２０３が押されると、要求仕様書作成部４１は、機能挿入画面２００内のラジオボタン２０２で選択された機能の機能ＩＤを、機能ツリーデータベース３３から取得する（ステップＳ１３１）。また、図２７のステップＳ１２１で取得した要求仕様書画面１９０内のカーソルの位置を取得する（ステップＳ１３２）。この場合、ユーザは、図１９の要求仕様書画面１９０内で、機能の開始位置に対応する位置にカーソルを合わせているものとする。ついで、要求仕様書作成部４１は、ステップＳ１３２で取得したカーソル位置に対応する要求仕様書のＭＸＬ実ファイル内の位置に、機能が記述される開始位置であることを示すタグを挿入する（ステップＳ１３３）。この開始位置を示すタグとして、ここでは“＜”＋機能ＩＤ＋“＞”の書式を有するものとする。そして、開始位置を示すタグが挿入された要求仕様書画面１９０をユーザの端末装置２に表示し（ステップＳ１３４）、要求仕様書への機能の開始位置挿入処理を終了する。

図２９は、要求仕様書作成部による要求仕様書への機能の終了位置挿入処理手順を示すフローチャートである。図２０の機能挿入画面２００において終了位置挿入ボタン２０４が押されると、要求仕様書作成部４１は、機能挿入画面２００内のラジオボタン２０２で選択された機能の機能ＩＤを、機能ツリーデータベース３３から取得する（ステップＳ１４１）。また、図２７のステップＳ１２１で取得した要求仕様書画面１９０内のカーソルの位置を取得する（ステップＳ１４２）。この場合、ユーザは、図１９の要求仕様書画面１９０内で、機能の終了位置に対応する位置にカーソルを予め合わせているものとする。ついで、要求仕様書作成部４１は、ステップＳ１４２で取得したカーソル位置に対応する要求仕様書のＭＸＬ実ファイル内の位置に、機能が記述された内容の終了位置であることを示すタグを挿入する（ステップＳ１４３）。この終了位置を示すタグとして、ここでは“＜／”＋機能ＩＤ＋“＞”の書式を有するものとする。そして、終了位置を示すタグが挿入された要求仕様書画面１９０をユーザの端末装置２に表示し（ステップＳ１４４）、要求仕様書への機能の終了位置挿入処理を終了する。

図３０は、要求仕様書作成部による要求仕様書の保存処理手順を示すフローチャートである。図１９の要求仕様書画面１９０において保存ボタン１９１が押されると、要求仕様書作成部４１は、要求仕様書画面１９０内の情報を取得するとともに、この要求仕様書に対応するバージョンＩＤを取得する（ステップＳ１５１）。ついで、要求仕様データベース３５から取得したバージョンＩＤに対応する要求仕様所のＸＭＬ実ファイルの場所を取得する（ステップＳ１５２）。そして、要求仕様書画面１９０内のデータを取得したＸＭＬ実ファイルの場所に保存して（ステップＳ１５３）、要求仕様書の保存処理を終了する。

つぎに、機能ツリー作成部４２の動作処理について説明する。図３１は、機能ツリー作成部による機能ツリー画面の表示処理手順を示すフローチャートである。図１７のバージョン一覧画面１７０において、バージョン一覧表示領域１７１中のいずれかのバージョンが選択された状態で機能ツリーボタン１７５が押されると、機能ツリー作成部４２は、選択されたソフトウェアのバージョンのバージョンＩＤをバージョン管理データベース３１から取得する（ステップＳ１６１）。ついで、機能ツリーデータベース３３の機能ツリートップテーブルと機能ツリーデータテーブルを参照して、取得したバージョンＩＤと同じデータを取得し（ステップＳ１６２）、その内容に基づいて機能ツリーを作成する（ステップＳ１６３）。そして、図２１に示されるような作成した機能ツリーを含む機能ツリー画面２１０をユーザの端末装置２に表示し（ステップＳ１６４）、機能ツリー画面２１０の表示処理を終了する。

図３２は、機能ツリー作成部による機能ツリーの保存処理手順を示すフローチャートである。図２１の機能ツリー画面２１０において保存ボタン２１４ｃが押されると、機能ツリー作成部４２は、機能ツリー画面２１０内の機能ツリーに関するデータを取得するとともに、表示されている機能ツリーに関するバージョンＩＤを取得する（ステップＳ１７１）。ついで、取得した機能ツリーに関するデータの内容を、取得したバージョンＩＤに対応する機能ツリーデータベース３３の機能ツリートップテーブルと機能ツリーデータテーブルに保存する（ステップＳ１７２）。このとき、イベント（機能ツリーの最下層の機能）を保存する必要がある場合には、ソース解析部４０によってソース解析が実行され、イベント−関数の関連テーブルの内容も更新される（ステップＳ１７３）。以上で、機能ツリーの保存処理が終了する。

つぎに、ソース管理部４３の動作処理について説明する。図３３は、ソース管理部によるソース一覧画面の表示処理手順を示すフローチャートである。図１７のバージョン一覧画面１７０において、バージョン一覧表示領域１７１中のいずれかのバージョンが選択された状態でソース一覧ボタン１７６が押されると、ソース管理部４３は、選択されたソフトウェアのバージョンのバージョンＩＤをバージョン管理データベース３１から取得し（ステップＳ１８１）、ソース管理データベース３２のソーステーブルから取得したバージョンＩＤを有するソースＩＤを取得する（ステップＳ１８２）。ついで、取得したソースＩＤごとに、ソース名、変更フラグ、実ファイルの場所を取得し（ステップＳ１８３）、メモリに保持する。また、ソースチェック項目テーブルからステップＳ１８２で取得したソースＩＤごとにチェック項目も取得する（ステップＳ１８４）。さらに、ソースの実ファイルが格納されている場所から、ステップＳ１８２で取得したソースＩＤごとに、ソースの実ファイルの最終更新者と更新日を取得する（ステップＳ１８５）。以上のステップＳ１８３〜Ｓ１８４で取得した情報を用いて、図２２に示されるようなソース一覧画面２２０を作成し、ユーザの端末装置２に表示して（ステップＳ１８６）、ソース一覧画面２２０の表示処理が終了する。

図３４は、ソース管理部による変更するソースを抽出する処理手順を示すフローチャートである。図２２のソース一覧画面２２０において変更ソース抽出ボタン２２２が押されると、ソース管理部４３は、表示されているソースについてのバージョンＩＤを取得する（ステップＳ１９１）。また、ソース管理部４３は、取得したバージョンＩＤを用いて、バージョン管理データベース３１のバージョンテーブルから基になったソフトウェア（すなわち、流用元のソフトウェア）のバージョンＩＤを取得する（ステップＳ１９２）。ついで、要求仕様データベース３５から選択しているソフトウェアのバージョンＩＤ（ステップＳ１９１で取得）と流用元のソフトウェアのバージョンＩＤ（ステップＳ１９２で取得）のＸＭＬ実ファイルのパスを取得する（ステップＳ１９３）。選択されたソフトウェアと流用元のソフトウェアのバージョンのＸＭＬ実ファイルの場所にアクセスして、ＸＭＬ実ファイルをメモリにロードする（ステップＳ１９４）。

その後、ソース管理部４３は、選択されたソフトウェアと流用元のソフトウェアのＸＭＬ実ファイル（要求仕様書）を比較して、その差分を抽出する（ステップＳ１９５）。抽出された差分を解析し、差分が機能ツリーのどの機能に該当するか、つまり選択されたソフトウェアにおいて流用元のソフトウェアのどの機能が変更されたものなのかを特定する（ステップＳ１９６）。なお、この機能の変更箇所の特定方法は、差分が機能開始位置を示すタグと機能終了位置を示すタグによって特定されるどの範囲に含まれているかを検出することによって、その差分がどの機能に該当するかを特定する。その後、機能ツリーを基にして、機能ツリーを上位から下位へとたどり、変更がどのイベント（すなわち機能ツリーの最下層の機能）に関連するかを特定する（ステップＳ１９７）。

イベントが特定されると、ソース管理部４３はつぎに示す３つ流れで変更すべきソースをリストアップする（ステップＳ１９８〜Ｓ２０５）。まず１つ目は、リンク情報データベース３４のイベント−関数の関連テーブルから特定されたイベント（すなわちイベントに対応する機能の機能ＩＤ）を用いて関数ＩＤをリストアップし（ステップＳ１９８）、リストアップした関数ＩＤを用いてソース−関数の関連テーブルから関連するソースをリストアップする（ステップＳ１９９）。つぎに２つ目は、イベント−関数の関連テーブルから特定されたイベント（すなわちイベントに対応する機能の機能ＩＤ）を用いて関数ＩＤをリストアップし（ステップＳ２００）、リストアップした関数ＩＤを用いてソース−関数の関連テーブルから関連するソースＩＤをリストアップし（ステップＳ２０１）、さらに、ソース間のインクルード関連テーブルからリストアップしたソースＩＤを用いて関連するソースをリストアップする（ステップＳ２０２）。そして３つ目は、イベント−関数の関連テーブルから特定されたイベント（すなわちイベントに対応する機能の機能ＩＤ）を用いて関数ＩＤをリストアップし（ステップＳ２０３）、リストアップした関数ＩＤを用いて関数間の呼び出し関連テーブルから関連する関数ＩＤをリストアップし（ステップＳ２０４）、さらに、ソース−関数の関連テーブルからステップＳ２０３でリストアップした関数ＩＤを用いて関連するソースをリストアップする（ステップＳ２０５）。

以上の変更すべきソースのリストアップが終了すると、ソース管理部４３は、ステップＳ１９９，Ｓ２０２，Ｓ２０５でリストアップされたソースをマージする（ステップＳ２０６）。その後、ソース管理部４３は、以上の結果を受けてソーステーブルの変更フラグを更新して、ユーザの端末装置２にソース一覧画面２２０を再表示し（ステップＳ２０７）、変更するソースの抽出処理を終了する。

図３５は、ソース管理部によるソースの実ファイルの表示処理手順を示すフローチャートである。図２２のソース一覧画面２２０において、いずれかのソースが選択された状態でソース変更ボタン２２３が押されると、ソース管理部４３は、選択されたソースのソースＩＤを取得する（ステップＳ２１１）。ついで、ソース管理データベース３２のソーステーブルを参照し、取得したソースＩＤに対応するソースの実ファイルの場所を取得する（ステップＳ２１２）。その後、取得したソースの実ファイルの場所にアクセスして、ソースの実ファイルをユーザの端末装置２に表示し（ステップＳ２１３）、ソースの実ファイルの表示処理を終了する。なお、ユーザは、端末装置２から表示されたソースの実ファイルの内容の変更を行う。

つぎに、試験仕様書作成部４４の動作処理について説明する。図３６は、試験仕様書作成部による試験仕様書画面の表示処理手順を示すフローチャートである。図１７のバージョン一覧画面１７０において、バージョン一覧表示領域１７１中のいずれかのバージョンが選択された状態で試験仕様書ボタン１７７が押されると、試験仕様書作成部４４は、選択されたソフトウェアのバージョンのバージョンＩＤをバージョン管理データベース３１から取得する（ステップＳ２２１）。このバージョンＩＤを基に機能ツリーデータベース３３を参照して、機能ＩＤ（機能ツリートップＩＤまたは機能ツリーデータＩＤ）を取得する（ステップＳ２２２）。その後、取得した機能ＩＤでループして、試験仕様データベース３６を用いて試験仕様ＩＤを取得する（ステップＳ２２３）。そして、試験仕様データベース３６から試験仕様ＩＤに対応する試験仕様を抽出し、所定の形式に加工した試験仕様書画面２３０をユーザの端末装置２に表示し（ステップＳ２２４）、試験仕様書画面２３０の表示処理を終了する。

図３７は、試験仕様書作成部による試験仕様抽出の処理手順を示すフローチャートである。図２３の試験仕様書画面２３０において試験仕様抽出ボタン２３２が押されると、表示している試験仕様書画面２３０についてのバージョンＩＤを取得する（ステップＳ２３１）。ついで、ソース管理データベース３２のソーステーブルから、取得したバージョンＩＤを有し、変更フラグが「１」（すなわち、変更されたソース）の「関連する機能ツリーデータＩＤ」を抽出する（ステップＳ２３２）。その後、ステップＳ２３２で抽出した関連する機能ツリーデータＩＤと同じ機能ツリーデータＩＤを有するレコードの参照元機能ツリーデータＩＤを試験仕様データベース３６から抽出する（ステップＳ２３３）。ついで、ステップＳ２３３で抽出した参照元機能ツリーデータＩＤに対応する試験仕様を試験仕様データベース３６から抽出する（ステップＳ２３４）。そして、抽出した試験仕様を所定の形式に加工した試験仕様書画面２３０をユーザの端末装置２に表示し（ステップＳ２３５）、試験仕様抽出処理を終了する。

図３８は、試験仕様書作成部による試験仕様書の保存処理手順を示すフローチャートである。図２３の試験仕様書画面２３０において保存ボタン２３３が押されると、試験仕様書作成部４４は、表示されている試験仕様書画面２３０内の情報を取得する（ステップＳ２４１）。ついで、表示されている試験仕様書に対応する機能ＩＤを取得する（ステップＳ２４２）。そして、取得した機能ＩＤと同じ機能ＩＤを有する試験仕様データベース３６内のレコードに、ステップＳ２４１で取得した情報を保存し（ステップＳ２４３）、試験仕様書の保存処理を終了する。

この実施の形態によれば、新たなソフトウェアと流用元のソフトウェアの要求仕様書を解釈して変更すべきソースを特定して提示するようにしたので、ユーザがどのソースを直すべきかを検討する作業の支援を行うことができる。その結果、ソフトウェアの開発期間の短縮が図れるとともに、ソースの変更漏れを防止して、ソフトウェアの品質向上に貢献することができるという効果を有する。

また、ソース変更時に、そのソースを変更する際の注意点をユーザに対して提示するようにしたので、経験の豊富なユーザでなくても、ソースの変更を容易に行うことができるという効果を有する。また、これによって、開発するユーザに依存しない安定した品質のソフトウェアの開発を行うことができるという効果も有する。

さらに、ソース変更後の試験仕様書を自動的に作成するようにしたので、本来行うべき試験の試験漏れ防止や、必要のない試験を実行することによるコストの超過を防ぐことができるという効果を有する。

以上のように、この発明にかかるソフトウェア開発支援装置は、過去に作成されたソフトウェアを基にして新たなソフトウェアを作成する場合、または過去に作成されたソフトウェアのバージョンアップを行う場合に有用であり、特に、複数の端末装置がネットワークを介して接続された環境下で、内容の類似したソフトウェアの開発を行っているネットワークに適している。

この発明によるソフトウェア開発支援装置の概略構成を模式的に示す図である。 機能ツリーの構成の一例を示す図である。 標準的なサーバ−クライアントモデルのソフトウェアの場合における機能ツリーの構造の一例を示す図である。 ソフトウェアの作成手順を示すフローチャートである。 変更ソース抽出処理の手順を示すフローチャートである。 試験仕様書作成処理の手順を示すフローチャートである。 ソフトウェア開発支援装置の構成の一例を模式的に示す図である。 バージョンテーブルの構成の一例を示す図である。 ソーステーブルの構成の一例を示す図である。 ソースチェック項目テーブルの構成の一例を示す図である。 機能ツリートップテーブルの構成の一例を示す図である。 機能ツリーデータテーブルの構成の一例を示す図である。 ソース−関数の関連テーブルの構成の一例を示す図である。 関数間の呼び出し関連テーブルの構成の一例を示す図である。 ソース間のインクルード関連テーブルの構成の一例を示す図である。 イベント−関数の関連テーブルの構成の一例を示す図である。 要求仕様書の構造および要求仕様書の一例を示す図である。 図１２に示される要求仕様書をＸＭＬで記述したファイルの内容を示す図である。 要求仕様テーブルの構成の一例を示す図である。 試験仕様書の構造の一例を示す図である。 試験仕様テーブルの構成の一例を示す図である。 バージョン一覧画面の一例を示す図である。 バージョン登録画面の一例を示す図である。 要求仕様書画面の一例を示す図である。 機能挿入画面の一例を示す図である。 機能ツリー画面の一例を示す図である。 ソース一覧画面の一例を示す図である。 試験仕様書画面の一例を示す図である。 バージョン登録部によるバージョン登録の処理手順を示すフローチャートである。 ソースの記述内容の一例を示す図である。 要求仕様書作成部による要求仕様書画面の表示処理手順を示すフローチャートである。 要求仕様書作成部による機能挿入画面の表示処理手順を示すフローチャートである。 要求仕様書作成部による要求仕様書への機能の開始位置挿入処理手順を示すフローチャートである。 要求仕様書作成部による要求仕様書への機能の終了位置挿入処理手順を示すフローチャートである。 要求仕様書作成部による要求仕様書の保存処理手順を示すフローチャートである。 機能ツリー作成部による機能ツリー画面の表示処理手順を示すフローチャートである。 機能ツリー作成部による機能ツリーの保存処理手順を示すフローチャートである。 ソース管理部によるソース一覧画面の表示処理手順を示すフローチャートである。 ソース管理部による変更するソースを抽出する処理手順を示すフローチャートである。 ソース管理部によるソースの実ファイルの表示処理手順を示すフローチャートである。 試験仕様書作成部による試験仕様書画面の表示処理手順を示すフローチャートである。 試験仕様書作成部による試験仕様抽出の処理手順を示すフローチャートである。 試験仕様書作成部による試験仕様書の保存処理手順を示すフローチャートである。

符号の説明

１，１ａ ソフトウェア開発支援装置
２ 端末装置
３ ネットワーク
３ａ ＬＡＮ
１１ 通信部
１２ 入力部
１３ ソース格納部
１４ 機能ツリー格納部
１５ リンク情報格納部
１６ 要求仕様格納部
１７ 試験仕様格納部
１８ ソフトウェア登録部
１９，４０ ソース解析部
２０ 変更ソース抽出部
２１ 試験仕様書作成部
３１ バージョン管理データベース
３２ ソース管理データベース
３３ 機能ツリーデータベース
３４ リンク情報データベース
３５ 要求仕様データベース
３６ 試験仕様データベース
３７ データベースインタフェース部
３８ バージョン一覧表示部
３９ バージョン登録部
４１ 要求仕様書作成部
４２ 機能ツリー作成部
４３ ソース管理部
４４ 試験仕様書作成部
４５ 端末インタフェース部

Claims (3)

1. ネットワークを介してソフトウェアの開発を行うユーザの端末装置と接続され、前記ユーザによるソフトウェアの開発支援を行うソフトウェア開発支援装置であって、
   ソフトウェアのソースを格納するソース格納手段と、
   前記ソフトウェアについての要求仕様書を格納する要求仕様格納手段と、
   前記要求仕様書と、該要求仕様書に基づいて分類したソフトウェアの機能と、前記ソースとの間の関連を示す機能−リンク情報を格納する機能−リンク情報格納手段と、
   新たなソフトウェアの作成に当たり、前記ソース格納手段内から選択される流用元のソフトウェアのソースと、前記要求仕様格納手段から前記選択されたソフトウェアに対応する要求仕様書を新たなソフトウェア用にコピーするソフトウェア登録手段と、
   新たなソフトウェア用にコピーされた前記要求仕様書の内容が編集され、機能−リンク情報が更新された後に、前記新たなソフトウェア用の要求仕様書と前記流用元のソフトウェアの要求仕様書とから差分を抽出し、前記機能−リンク情報を用いて前記差分に関連するソースを抽出して前記端末装置に提示する変更ソース抽出手段と、
   を備えることを特徴とするソフトウェア開発支援装置。
2. 前記ソース格納手段は、ソースごとに該ソースに関しての注意事項を含むチェック項目情報をさらに格納し、
   前記ソフトウェア登録手段は、新たなソフトウェアの作成に当たり、流用元のチェック項目情報も新たなソフトウェア用にさらにコピーし、
   前記変更ソース抽出手段は、前記抽出したソースについてのチェック項目情報も前記ソース格納手段から抽出して、前記ソースとともに前記端末装置に提示する機能をさらに有することを特徴とする請求項１に記載のソフトウェア開発支援装置。
3. 前記ソフトウェアのソースごとに試験すべき項目がまとめられた試験仕様を格納する試験仕様格納手段と、
   前記新たなソフトウェアについてのソースが変更された後に、前記流用元のソフトウェアの試験仕様のうち前記変更ソース抽出手段によって抽出されたソースに関連する試験仕様を前記試験仕様書格納手段から抽出し、前記端末装置に提示する試験仕様書作成手段と、
   をさらに備えることを特徴とする請求項１または２に記載のソフトウェア開発支援装置。
   
   
   

Images