以下に添付図面を参照して、この発明にかかるソフトウェア開発支援装置の好適な実施の形態を詳細に説明する。なお、以下では、最初にこの発明の概要を説明し、その後により具体的な例を挙げてこの発明の内容を説明する。
図1は、この発明にかかるソフトウェア開発支援装置の概略構成を模式的に示す図である。ソフトウェア開発支援装置1は、ソフトウェアの開発を行う開発者(以下、ユーザという)によって使用されるパーソナルコンピュータなどの情報処理端末装置(以下、端末装置という)2と、LAN(Local Area Network)のようなネットワーク3を介して接続されている。
ソフトウェア開発支援装置1は、ネットワークを介して端末装置2と通信を行う通信部11と、自ソフトウェア開発支援装置1に命令やデータなどの入力を行う入力部12と、ソフトウェアのソースに関係する情報を格納するソース格納部13と、ソースに応じた機能ツリーを格納する機能ツリー格納部14と、ソースのリンク情報を格納するリンク情報格納部15と、ソフトウェアの要求仕様書を格納する要求仕様格納部16と、ソフトウェアの試験仕様書が格納される試験仕様格納部17と、ソフトウェアの新規作成または既存のソフトウェアの改良を行うための新たなソフトウェアの登録処理を行うソフトウェア登録部18と、ソース格納部13に新たに格納されるソースの解析を行うソース解析部19と、変更されるソースを抽出する変更ソース抽出部20と、作成されたソフトウェアの試験仕様を作成する試験仕様書作成部21と、を備えて構成される。
通信部11は、端末装置2からのソフトウェアのソースやソフトウェアに関する要求仕様書の内容についての情報の受信や、変更ソース抽出部20によって抽出されたソースの変更箇所の端末装置2への送信などの、ネットワークを介して接続される端末装置2との間の必要な情報の送受信を行う機能を有する。また、入力部12は、ソフトウェア開発支援装置1からユーザが直接に、各処理部への指令や要求仕様書の変更などを行う場合に使用される入力手段である。
ソース格納部13は、ソースの実態である実ファイルと、ソフトウェアに関するバージョン情報と、ソフトウェアを構成するソースファイルの名称であるソース名、ソースに付されたチェック項目を含むソフトウェア構成情報と、をソースごとに関連付けして格納する。ソフトウェアに関するバージョン情報は、ソフトウェアを識別する情報であり、たとえば、過去に作成されたあるソフトウェアに関する改変の履歴を示すための情報である。ソースに付されたチェック項目は、ソースファイルに記述されているチェック項目から抽出される。なお、このソース格納部13に格納されているソフトウェア構成情報は、新たなソースが作成される以前に既に作成されているソフトウェアに関するソースが格納されている。
機能ツリー格納部14は、ソースの有する機能を所定のまとまりごとに分類したソースの機能情報を格納している。この発明では、ソースの機能情報をツリー状に細分化した機能ツリーとして格納する場合を例示している。図2は、機能ツリーの構成の一例を示す図である。この図に示されるように、機能ツリーは、ソース(要求仕様書)内の機能を所定の基準で分類したまとまりごとに細分化していき、それぞれの機能の間に親子(包含)関係がある場合にそれらを線で結んでツリー状に表現したものである。この機能ツリーの上位から下位に向かって、機能の分類が詳細化される。以下では、この機能ツリーを構成する1つ1つのノードのことを、「機能」と呼ぶことにする。この図において、機能は、「機能1」、「機能2」、「機能3」、・・・の各ノードに大きく分類され、また「機能1」は「機能1.1」、「機能1.2」、・・・の各ノードに分類され、「機能1.1」はさらに「機能1.1.1」、「機能1.1.2」、「機能1.1.3」、・・・の各ノードに細かく分類されている。
図3は、標準的なサーバ−クライアントモデルのソフトウェアの場合における機能ツリーの構造の一例を示す図である。標準的なサーバ−クライアントモデルにおいては、ソフトウェアの機能は3階層に分解される。その1階層目の機能は総合的な機能を示す「メニュー」に関するものであり、2階層目の機能は「メニュー」に含まれる機能のうち表示される画面が異なる機能ごとに分類した「画面」に関するものであり、そして3階層目の機能は「画面」内に配置される「ボタン」に関するものである。この3階層目の「ボタン」は、システムが起動してイベントが生じるための起点となるものである。つまり、「ボタン」に示される機能が実行されることによってシステムが起動する。ここでは、機能ツリー格納部14に格納される機能情報は、図3に示されるような標準的なサーバ−クライアントモデルのソフトウェアの場合における機能ツリーの構造を有するものとして説明を行う。
この機能ツリーにおいて、ソフトウェアの有する機能は、ソースを作成する前の時点では要求仕様書に記述された機能であるので、実際には、機能ツリーは後述する要求仕様書に基づいてユーザによって作成される。また、新たなソフトウェアの作成のためにコピーされた機能ツリーは、そのソフトウェアに関するソースの変更箇所の特定処理が行われる前に、ユーザによって要求仕様書に基づいたツリー構造に変更され、機能ツリーを構成する各機能は、要求仕様書内の内容を示す情報と関連付けされている必要がある。なお、この機能ツリー格納部14にも、既に作成されているソフトウェアに関する機能ツリーが格納されているものとする。
リンク情報格納部15は、ソース間の関連付けや、ソースと関数との関連付け、ソースと機能ツリーの最下層を構成する機能との関連付けなどを含むリンク情報を格納する。なお、特許請求の範囲における機能−リンク情報格納手段は、機能ツリー格納部14とリンク情報格納部15に対応し、同じく機能−リンク情報は、機能ツリーなどの機能情報とリンク情報に対応している。
要求仕様格納部16は、ソフトウェアに対して要求される仕様が所定の形式で記述された要求仕様書を格納する。この要求仕様書は、新たに作成するソフトウェア(以下、新たなソフトウェアという)に要求される仕様がユーザによって作成される。この要求仕様格納部16にも、既に作成されているソフトウェアについての要求仕様書が格納されているものとする。また、新たなソフトウェアの作成のためにコピーされた要求仕様書は、そのソフトウェアに関するソースの変更箇所の特定処理が行われる前に、新たなソフトウェア用にユーザによって変更されている必要がある。
試験仕様格納部17は、作成されたソフトウェアに関して行うべき試験の内容が記述された試験仕様を格納する。この試験仕様は、既に作成されたそれぞれのソフトウェアに対して作成されているものであり、ソフトウェアを構成するソースごとに試験仕様が作成されている。ただし、作成されるソフトウェア全てに対して作成されている必要はなく、たとえば基となるソフトウェアが同一のものであれば(バージョンが異なるがソフトウェアの名称が同じソフトウェアであれば)、同一の試験仕様書を利用することができる。また、新たに作成されるソフトウェアに対して作成した試験仕様書を格納してもよい。この試験仕様格納部17にも既に作成されているソフトウェアについての試験仕様書が格納されているものとする。
ソフトウェア登録部18は、新たに作成されるソフトウェアまたは改良を行うソフトウェアをこのソフトウェア開発支援装置1に登録する機能を有する。具体的には、ソース格納部13から流用元となるソフトウェア(以下、流用元のソフトウェアという)がユーザによって選択されると、流用元のソフトウェアについてのソースの実ファイル、ソフトウェア構成情報、機能ツリーおよび要求仕様書をコピーし、新たなソフトウェアに付されるバージョン番号と対応付けしてそれぞれの格納部に格納する処理を行う。なお、新たなソフトウェアに関して格納された要求仕様書は、ユーザによってたとえばネットワーク3を介して呼び出され、新たなソフトウェアに関して要求される仕様に変更される。また、機能ツリーもユーザによってたとえばネットワーク3を介して呼び出され、要求仕様書に基づいてツリー構造が変更される。このとき、要求仕様書の記載内容と機能ツリーの各機能との対応関係が、ユーザによって要求仕様書内に記録される。
ソース解析部19は、ソフトウェア登録部18によってソースが新たにコピーされたとき、またはソースが変更されたときを起点としてそのソースについての解析を行う。具体的には、ソースとソースとの間の関係や、関数とソースとの関係、また機能ツリーの最下層の機能とソース(関数)との対応関係を抽出して、それらの対応付けを含むリンク情報を作成して、リンク情報格納部15に格納する。
変更ソース抽出部20は、新たなソフトウェアについて、流用元のソフトウェアとの違いを両者の要求仕様書に基づいて抽出し、変更すべきソースを機能ツリー、リンク情報およびソフトウェア構成情報を利用して特定して、ユーザに対して提示する機能を有する。また、変更ソース抽出部20は、抽出したソースについてのチェック項目をソース格納部13のソフトウェア構成情報から抽出して、ユーザに対して提示する機能も有する。これにより、新たなソフトウェアの作成時において、流用元のソフトウェアのソースの変更すべき箇所がユーザ対して提示される。また、その際の注意事項もあわせて提示される。
試験仕様書作成部21は、ユーザによるソース変更処理の後に、新たなソフトウェアのうち変更されたソースに関する試験仕様書を、流用元のソフトウェアのバージョン番号の試験仕様書を基に作成し、ユーザに対して提示する機能を有する。これによって、新たなソフトウェアのソース変更後に行うべき試験の内容のみ、すなわち変更されたソースに関して行うべき試験の内容のみ、がユーザに対して提示される。
つぎに、このようなソフトウェア開発支援装置1を用いたソフトウェアの作成手順について説明する。図4は、ソフトウェアの作成手順を示すフローチャートである。まず、端末装置2からユーザによってソフトウェアの作成の指示が入力されると、ソフトウェア開発支援装置1のソフトウェア登録部18は、ソース格納部13に格納されているソフトウェアのバージョン情報を一覧にしてユーザの端末装置2に表示する(ステップS1)。ユーザは、このバージョン情報の一覧から新規に作成しようとしているソフトウェア(新たなソフトウェア)の基となるソフトウェアのバージョン情報を選択する。このユーザによる選択結果を受けると、ソフトウェア開発支援装置1のソフトウェア登録部18は、選択されたバージョンのソフトウェアについてのソースの実ファイル、ソースに関するチェック項目を含むソフトウェア構成情報、機能ツリーおよび要求仕様書のコピーを作成して、それぞれの格納部に新たなソフトウェアのバージョンと対応付けて格納する(ステップS2)。このとき、ソース解析部19は、ソース格納部13内に新たにソースがコピーされたので、コピーされたソースについてソース解析を行い、その結果をリンク情報としてリンク情報格納部15に新たに作成されるソフトウェアに関連付けて格納する。
この後、ユーザによって、コピーされた要求仕様書、機能ツリーなどの内容が新たなソフトウェアに合わせて変更される。具体的には、要求仕様書を新たなソフトウェアに要求される仕様に合わせて変更し、この変更に合わせて機能ツリーも変更する。またこのとき、機能ツリーの各機能と要求仕様書に記載される内容との間の対応付けも行われる。これらの変更結果が反映されたものが、それぞれ機能ツリー格納部14、要求仕様格納部16に格納される(ステップS3)。
つぎに、ユーザから変更するソースの抽出の指示を受けると、ソフトウェア開発支援装置1の変更ソース抽出部20は、変更されるソースを抽出する処理を行い(ステップS4)、その結果をユーザに対して提示する。このとき、ソースの変更に関する注意事項であるチェック項目をユーザに対して提示してもよい。ユーザは、ソフトウェア開発支援装置1から提示された変更すべきソースを、チェック項目が表示されている場合にはそれを参照しながら変更する。この変更内容は、ソース格納部13の対応するソースに反映される(ステップS5)。ソース解析部19は、ソースが変更されたので、変更されたソースについてソース解析を行い、その結果をリンク情報格納部15に上書き保存する。
ソースの変更処理の終了後、ユーザの端末装置2から変更したソースに関する試験仕様書の作成の指示を受けると、ソフトウェア開発支援装置1の試験仕様書作成部21は、試験仕様格納部17から抽出した流用元のソフトウェアについての試験仕様に基づいて、上記のステップS4で抽出されたソースに関係する試験仕様を抽出して、新たなソフトウェア用の試験仕様書を作成し、ユーザの端末装置2に提示する(ステップS6)。ユーザは、提示された試験仕様書を基にして新たなソフトウェアの試験を行い、ソフトウェアの作成処理が終了する。
ここで、上記ステップS4における変更ソース抽出処理について、図5のフローチャートを参照しながら詳細に説明する。まず、ソフトウェア開発支援装置1の変更ソース抽出部20は、ユーザからソースの変更箇所の抽出処理の実行の命令を受けると、新たなソフトウェアの要求仕様書と、該新たなソフトウェアの基となったバージョンのソフトウェア(流用元のソフトウェア)の要求仕様書とを要求仕様格納部16から抽出する(ステップS11)。抽出した新たなソフトウェアと流用元のソフトウェアの要求仕様書を比較し、差分を抽出する(ステップS12)。その差分を解析し、差分がどの機能ツリーのどの機能に該当するのか、つまりどの機能が変更されたのかを特定する。この特定は、要求仕様書の内容と機能ツリーの各機能との間の関係が対応付けされているので、要求仕様書上の差分の位置から、機能ツリーにおける位置(機能)が特定され、さらにその位置(機能)から機能ツリーを上位から下位へとたどり、最下層の機能を抽出することによって行われる(ステップS13)。これは、最下層の機能は、イベントが生じるための起点に該当し、対応する関数が必ず存在することによるものである。その後、リンク情報格納部15とソース格納部13を参照して、最下層の機能に対応するソースと、それに関連するソースを抽出する(ステップS14)。そして、抽出したソースを一覧で表示し(ステップS15)、変更ソース抽出処理が終了する。
なお、変更ソース抽出部20は、ステップS14において、ソース格納部13のソフトウェア構成情報から、抽出したソースに対応するチェック項目もソースと同時に抽出し、ステップS15において、抽出したソース一覧とともに該ソースの変更時における注意事項としてのチェック項目も表示するようにしてもよい。
また、上記ステップS6における試験仕様書作成処理について、図6のフローチャートを参照しながら説明する。まず、ソフトウェア開発支援装置1の試験仕様書作成部21は、ユーザから試験仕様書作成処理の実行の命令を受けると、流用元のソフトウェアについての試験仕様を試験仕様格納部17から抽出し、その内容をコピーして新たなソフトウェア用の試験仕様書のデータを作成する(ステップS21)。このとき、流用元のソフトウェアの試験仕様書の内容と流用元の機能ツリーの各機能とは対応付けがなされており、この流用元の機能ツリーと新たなソフトウェア用の機能ツリーとの対応関係から、新たなソフトウェアの機能ツリーと流用元の試験仕様書の内容との間の関連付けが行われる。さらに、試験仕様書作成部21は、作成された試験仕様の中から、上記ステップS14で変更ソース抽出部20によって抽出されたソースと対応付けられた試験仕様を抽出する(ステップS22)。ここで、試験仕様格納部17に格納されている各試験仕様はソースと予め対応付けられており、この対応関係は、コピーされたもの(新たなソフトウェア)でもその関係は維持されるので、試験仕様書作成部21は、ステップS14で抽出されたソースの情報を得ることができれば、そのソースに対応する試験仕様を得ることができる。そして、試験仕様書作成部21は、抽出された試験仕様を所定の形式に配置した試験仕様書を作成し(ステップS23)、ユーザに対して提示して試験仕様書作成処理が終了する。
以上が、この発明のソフトウェア開発支援装置1の構成と動作処理の概要である。以下では、標準的なサーバ−クライアントシステムにおけるソフトウェア開発支援装置の具体例を説明する。ここでは、Webシステムのように、ユーザの端末装置からグラフィカルユーザインタフェースを通じてソフトウェアの開発支援を行う場合を例に挙げる。
図7は、ソフトウェア開発支援装置の構成の一例を模式的に示す図である。図1と同様に端末装置2が接続されたLAN3aに、ソフトウェア開発支援装置1aが接続されている。このソフトウェア開発支援装置1aは、バージョン管理データベース31、ソース管理データベース32、機能ツリーデータベース33、リンク情報データベース34、要求仕様データベース35、試験仕様データベース36、データベースインタフェース部37、バージョン一覧表示部38、バージョン登録部39、ソース解析部40、要求仕様書作成部41、機能ツリー作成部42、ソース管理部43、試験仕様書作成部44および端末インタフェース部45を備えて構成される。なお、各データベース31〜36は、ソフトウェア開発支援装置1a内に設けられる必要はなく、ソフトウェア開発支援装置1aとは別個の記憶装置に作成してもよい。
バージョン管理データベース31は、ソフトウェアのバージョン情報を管理するバージョンテーブルを有して構成される。図8は、バージョンテーブルの構成の一例を示す図である。この例のバージョンテーブルは、フィールドとして「バージョンID」、「バージョン名」、「基になったバージョンID」を有している。「バージョンID」は、ソースのバージョンを一意に識別することが可能な識別子であり、この例では各バージョンに対して数字を割り当てている。「バージョン名」は、ソフトウェアに対してユーザが付けるバージョンの情報であり、任意の文字列が入力される。この「バージョン名」は、「バージョンID」と異なり、主にユーザなどの人間によるバージョン情報の識別に用いられるものである。「基になったバージョンID」は、情報が格納されるソフトウェアの基になったソフトウェアのバージョンIDを示すものである。すなわち、情報が格納されるソフトウェアのコピー元(流用元)であるソフトウェアのバージョンIDである。この基になったバージョンIDは、ユーザが選択するものであるが、ユーザが選択しなかった場合には空欄となる。
ソース管理データベース32は、ソフトウェアを構成するソースに関する情報を管理するソーステーブルと、ソースに付随するチェック項目を管理するソースチェック項目テーブルと、ソースの実ファイルと、を格納する。図9−1は、ソーステーブルの構成の一例を示す図であり、図9−2は、ソースチェック項目テーブルの構成の一例を示す図である。
ソーステーブルは、フィールドとして「ソースID」、「ソース名」、「バージョンID」、「変更フラグ」、「関連する機能ツリーID」、「実ファイルの場所」を有している。「ソースID」は、ソースを一意に識別することが可能な識別子であり、この例では各ソースに対して数字を割り当てている。「ソース名」は、ソースのソースファイル名である。「バージョンID」は、情報が格納されるソースが含まれるソフトウェアのバージョンを識別する識別子であり、バージョンテーブルで管理されるバージョンIDが使用される。「変更フラグ」は、ソースが変更されたか否かを示すフラグであり、「0」が入力されるときは変更がないことを示し、「1」が入力されるときは変更されたことを示している。「関連する機能ツリーID」は、ソースに関連する機能ツリーを識別するためのフィールドであり、後述する機能ツリーデータベース33で使用される機能ツリートップIDまたは機能ツリーデータIDが使用される。「実ファイルの場所」は、ソースが格納される場所であり、パス名で記述される。
ソースチェック項目テーブルは、フィールドとして「ソースID」、「チェック項目ID」、「チェック項目」を有している。「ソースID」は、ソーステーブルで管理されているソースIDであり、チェック項目の対象となるソースを示している。「チェック項目ID」は、ソースIDに対応するソースの中でチェック項目を識別する識別子である。チェック項目は1つのソースに対して1つとは限らず、複数存在してもよい。ここでは、ソースIDに対して連番となるように番号付けがなされている。これらの「ソースID」と「チェック項目ID」の組合せで1つのキーとなり、後述するチェック項目を識別する。「チェック項目」は、ソースに関して注意すべき事項を示す項目であり、たとえば、ソースの変更時の注意しなければならない事項や、ソースに対して決められた事項などである。
ソースの実ファイルは、このソース管理データベース32に格納され、ソース名と実ファイルの場所によってソーステーブルと対応付けがされている。なお、格納されるソースの実ファイルには、ファイルの最終更新者と更新日が属性として記憶されるものとする。
機能ツリーデータベース33は、上述した図3に示される3階層の機能ツリーをデータベースとして管理しており、1階層目の機能を管理する機能ツリートップテーブルと、2階層目以下の機能を管理する機能ツリーデータテーブルの2つのテーブルから構成される。図10−1は、機能ツリートップテーブルの構成の一例を示す図であり、図10−2は、機能ツリーデータテーブルの構成の一例を示す図である。
機能ツリートップテーブルは、フィールドとして「機能ツリートップID」、「バージョンID」、「機能ツリートップ名称」を有している。「機能ツリートップID」は、機能ツリーの1番上の階層を一意に識別する識別子であり、この例ではアルファベットの後に連番を付した文字列を使用している。「バージョンID」は、バージョン管理データベース31のバージョンテーブルで管理されるバージョンIDである。これにより、機能ツリーはソフトウェアと対応付けされる。「機能ツリートップ名称」は、ユーザによって機能ツリーを識別するために付される名称であり、ユーザが機能ツリーを編集する際に任意に入力することができる。
機能ツリーデータテーブルは、フィールドとして「機能ツリーデータID」、「バージョンID」、「機能ツリーデータ名称」、「機能ツリー親ID」、「階層数」を有している。「機能ツリーデータID」は、機能ツリーの2階層目以下のノードを一意に識別する識別子であり、この例ではアルファベットの後に連番を付した文字列を使用している。「バージョンID」は、バージョン管理データベース31のバージョンテーブルで管理されるバージョンIDである。「機能ツリーデータ名称」は、ユーザによって機能ツリーを構成するそれぞれの機能を識別するための名称であり、ユーザが機能ツリーを編集する際に任意に入力することができる。「機能ツリー親ID」は、情報が格納される機能の親にあたる機能を示すものであり、機能ツリートップテーブルの機能ツリートップIDまたはこの機能ツリーデータテーブルの機能ツリーデータIDが使用される。これによって、機能間の親子関係が把握され、機能ツリーを再現することができる。「階層数」は、該機能が機能ツリーの何階層目に属するかを示すものである。
リンク情報データベース34は、ソースで使用される関数を管理するソース−関数間の関連テーブルと、関数間の呼び出しを管理する関数間の呼び出し関連テーブルと、ソース間のインクルード関係を管理するソース間のインクルード関連テーブルと、イベントとイベントが呼び出す関数を関連付けるイベント−関数間の関連テーブルと、を含んで構成される。図11−1は、ソース−関数の関連テーブルの構成の一例を示す図であり、図11−2は、関数間の呼び出し関連テーブルの構成の一例を示す図であり、図11−3は、ソース間のインクルード関連テーブルの構成の一例を示す図であり、図11−4は、イベント−関数の関連テーブルの構成の一例を示す図である。
ソース−関数間の関連テーブルは、フィールドとして「関数ID」、「バージョンID」、「関数名」、「ソースID」を有している。「関数ID」は、関数を一意に識別するための識別子であり、ここでは関数に対して数字を付している。「バージョンID」は、バージョン管理データベース31のバージョンテーブルで管理されているバージョンIDであり、関数が使用されるソフトウェアを示している。「関数名」は、ソース内にある関数の名称である。「ソースID」は、ソース管理データベース32のソーステーブルで管理されているソースIDであり、関数が使用されるソースを示している。
関数間の呼び出し関連テーブルは、フィールドとして「関数ID」と「呼び出し関数ID」を有している。「関数ID」はソース−関数間の関連テーブルで管理されている関数IDである。「呼び出し関数ID」は当該関数が、その関数内で呼び出している関数IDである。この呼び出し関数IDに格納される関数IDも、ソース−関数間の関連テーブルで管理されている関数IDが使用される。なお、複数の関数を呼び出している場合には、1つの関数IDに対して複数の呼び出し関数IDが存在することとなる。
ソース間のインクルード関連テーブルは、フィールドとして「ソースID」と「インクルードソースID」を有している。「ソースID」は、ソース管理データベース32のソーステーブルで管理されているソースIDであり、「インクルードソースID」も同様である。このソース間のインクルード関連テーブルは、あるソースにおいて、別のソースをインクルードしている場合に、インクルードしているソースのソースIDとリンク付けするテーブルである。なお、あるソースが、複数のソースをインクルードしている場合には、1つのソースIDに対して複数のインクルードソースIDが存在することとなる。
イベント−関数の関連テーブルは、フィールドとして「機能ツリーデータID」と「関数ID」を有している。「機能ツリーデータID」は、機能ツリーデータベース33の機能ツリーデータテーブルで管理されている機能ツリーデータIDである。「関数ID」は、ソース−関数の関連テーブルで管理されている関数IDと同一のものである。このイベント−関数の関連テーブルは、機能ツリーの最下層の機能と関数とを関連付けするものである。上述したように、機能ツリーの最下層の機能は、システムが起動するための起点となるものであり、起点となるイベントが関数を呼び出す際に、このテーブルが使用される。なお、1つのイベント(機能ツリーの最下層の機能ツリーデータID)に対して呼び出される関数は必ず1つだけ存在する。なお、イベント−関数の関連テーブルの情報の新しいバージョン用のレコードは、バージョン登録時に流用元のソフトウェアのイベント−関数の関連テーブルを基に自動的に作成されるが、機能ツリー編集時に、ユーザによって更新することも可能である。
要求仕様データベース35は、ソフトウェアのあるバージョンに対応する要求仕様書の実体ファイルと、その要求仕様書の実体ファイルの場所を管理する要求仕様テーブルによって構成される。この例では、要求仕様書は、UML(Unified Modeling Language;統一モデリング言語)で記述されるものとする。このUMLで定義されたユースケースモデルは、ユースケース定義書により記述される。ユースケース定義書の中には、ユースケース図、アクティビティ図、イベントフローなどがある。このソフトウェア開発支援装置1aで管理する要求仕様書は、各ユースケースが章となり、ユースケースごとのイベントフロー(シナリオ)が節となる構造となっている。図12は、要求仕様書の構造および要求仕様書の一例を示す図である。この図12において、節であるイベントフロー(シナリオ)において、文章中に「E101」などの表現が見られるが、これは文章が機能ツリーのどの機能に対応するかを、機能ツリーの機能に付された識別子(機能ツリートップIDまたは機能ツリーデータID(以下では、機能ツリートップIDと機能ツリーデータIDを区別する必要がない場合には、機能IDという))を用いて示すものである。機能IDのみ(たとえば、E101)で機能記述の開始位置を示しており、「スラッシュ(/)+機能ID」(たとえば、/E101)で機能記述の終了位置を示している。これにより、要求仕様書内の文章や図などの構成要素と機能ツリーの機能とが対応付けられる。また、この例では、要求仕様書の実体はXML(eXtensible Markup Language)ファイルであるものとする。図13は、図12に示される要求仕様書をXMLで記述したファイルの内容を示す図である。XMLファイルでは、要求仕様書の章、節(UMLで記述された要求仕様書におけるユースケースとイベントフローにそれぞれ対応するもの)が表現されており、ファイルの内容中の<E101>や</E101>で、その内容がどの機能に対応するかを表現している。
図14は、要求仕様テーブルの構成の一例を示す図である。要求仕様テーブルは、フィールドとして「要求仕様ID」、「バージョンID」、「XML実ファイル」を有している。「要求仕様ID」は、要求仕様書を一意に識別するための識別子である。「バージョンID」は、バージョン管理データベース31のバージョンテーブルで管理されているバージョンIDである。これによって、ソフトウェアと該ソフトウェアについての要求仕様書とが対応付けされる。「XML実ファイル」は、要求仕様書の実体ファイルであるXMLファイルが保管されているパスを表している。
試験仕様データベース36は、ソフトウェアに対して実行される試験仕様を記述した試験仕様書を格納するデータベースであり、試験仕様テーブルから構成される。図15は、試験仕様書の構造の一例を示す図である。この試験仕様書は、ソフトウェアの機能ごとに確認すべき事項が列挙された構成となっている。図16は、試験仕様テーブルの構成の一例を示す図である。試験仕様テーブルは、フィールドとして「試験仕様ID」、「参照元機能ツリーデータID」、「機能ツリーデータID」、「試験仕様」を有している。「試験仕様ID」は、試験仕様書を一意に識別するための識別子である。「参照元機能ツリーデータID」は、ソフトウェアを登録するときにコピー元となった流用元のソフトウェアについての機能ツリーデータベース33で管理されている機能IDである。「機能ツリーデータID」は、ソフトウェアの機能ツリーの各機能について機能ツリーデータベース33で管理されている機能IDである。「試験仕様」は、試験仕様の詳細を格納している。以上に示されるように、試験仕様は、ソフトウェアの機能ごとに予め作成されている。なお、この試験仕様テーブルの新たなソフトウェア用のレコードは、試験仕様抽出時に参照元バージョン(すなわち、流用元のソフトウェアのバージョン)の試験仕様を基にして作成され、試験仕様書画面において更新される。また、この試験仕様は、新たなソフトウェアが作成される際にその内容を作成してもよい。
以上説明したバージョン管理データベース31、ソース管理データベース32、機能ツリーデータベース33、リンク情報データベース34、要求仕様データベース35および試験仕様データベース36には、既に作成されたソフトウェアについての情報が予め格納されている状態にあるものとする。
端末インタフェース部45は、ソフトウェアの開発を行うユーザの端末装置2に対して、ソフトウェア開発の支援を行うための情報を、LANを介して送受信する機能を有する。また、データベースインタフェース部37は、後述する各処理部が上記の各データベースにアクセスするためのインタフェースとなる部分である。
バージョン一覧表示部38は、ユーザによる新規のソフトウェアの作成または既存のソフトウェアの改良に関する各種の処理のインタフェースとなるバージョン一覧画面を表示し、ユーザからの指示を受け付ける機能を有する。
図17は、バージョン一覧画面の一例を示す図である。バージョン一覧画面170には、自装置内に格納されているソフトウェアのバージョンを一覧表示するバージョン一覧表示領域171と、このバージョンの一覧から作成するまたは変更するソフトウェアの基となるバージョンを選択するラジオボタン172と、ユーザが実行することのできる処理を実行するための5つのボタン173〜177と、が配置されている。バージョン一覧表示領域171には、バージョン管理データベース31のバージョンテーブル内から抽出されたバージョン名が表示される。ラジオボタン172は、バージョン一覧表示領域171の中からバージョンを1つだけ選択することができるボタンである。「バージョン追加」ボタン173は、バージョン登録部39と関連付けされており、このボタンを押す(クリックする)とバージョン登録部39が起動される。「要求仕様書」ボタン174は、要求仕様書作成部41と関連付けされており、このボタンを押すと要求仕様書作成部41が起動される。「機能ツリー」ボタン175は、機能ツリー作成部42と関連付けされており、このボタンを押すと機能ツリー作成部42が起動される。「ソース一覧」ボタン176は、ソース管理部43と関連付けされており、このボタンを押すとソース管理部43が起動される。「試験仕様書」ボタン177は、試験仕様書作成部44と関連付けされており、このボタンを押すと試験仕様書作成部44が起動される。
バージョン登録部39は、新たなソフトウェアの作成指示をユーザから受けると、流用元のソフトウェアについてのソフトウェア構成情報、機能ツリー、リンク情報および要求仕様書をコピーして、新たなソフトウェアに対応付けしてそれぞれのデータベース32〜35に格納する機能を有する。
図18は、バージョン登録画面の一例を示す図である。バージョン登録画面180には、追加するバージョン名を入力するための文字入力フィールド181と、追加するバージョンの流用元バージョンを選択するための選択入力フィールド182と、2つのボタン183,184が設けられている。文字入力フィールド181は、新たなソフトウェアについてのバージョン名を入力するためのフィールドであり、選択入力フィールド182は、新たなソフトウェアを作成するにあたり流用元となるソフトウェアのバージョンを選択入力するフィールドである。この選択入力フィールド182には、バージョン管理データベース31のバージョンテーブル内の「バージョン名」に格納されている内容が一覧表示される。「登録」ボタン183は、上記文字入力フィールド181と選択入力フィールド182に入力された内容の登録処理を実行し、バージョン一覧画面170に戻る処理を行うボタンである。「キャンセル」ボタン184は、上記文字入力フィールドと選択入力フィールドに入力された内容の登録処理を実行しないで、バージョン一覧画面170に戻る処理を行うボタンである。
ソース解析部40は、新たにソースがコピーされたときまたはソースの内容が変更されたときに、そのソースを解析し、ソース−関数間の関連、関数間の呼び出し関連、ソース間のインクルード関連を抽出し、リンク情報データベース34に格納する機能を有する。また、機能ツリーを利用してその最下層の機能(イベント)と関数の間の関連も抽出し、リンク情報データベース34のイベント−関数の関連テーブルに格納する機能も有する。
要求仕様書作成部41は、ユーザによる新たなソフトウェアについての要求仕様書の作成指示を受けると、その新たなソフトウェアの要求仕様書を編集するための要求仕様書画面を表示する機能を有する。この要求仕様書の編集は、要求仕様データベース35に格納されている要求仕様の内容の変更や追加のほかに、対応する機能ツリーの各機能と要求仕様の内容との間の対応付けを含む。編集された内容は、要求仕様データベース35の該当するソフトウェアに関する内容に反映される。
図19は、要求仕様書画面の一例を示す図である。要求仕様書画面190には、要求仕様データベース35に格納される要求仕様書の実体ファイルの内容が表示され、3つのボタン191〜193が設けられている。「保存」ボタン191は、画面に表示された要求仕様書画面190を保存する処理を行う。「機能ツリー」ボタン192は、この要求仕様書と関連付けされている機能ツリーを機能ツリーデータベース33から抽出し、その機能ツリーの機能と要求使用書の内容との関連付けを行うための機能挿入画面を表示する。「戻る」ボタン193は、図17のバージョン一覧画面170に戻る処理を実行する。
図20は、機能挿入画面の一例を示す図である。機能挿入画面200は、要求仕様書画面190で表示された要求仕様書に記述された内容をツリー表示するツリー表示領域201と、3つのボタン203〜205が設けられている。ツリー表示領域201のツリー状に表示された各機能にはラジオボタン202が設けられており、これらのうちの1つの機能を選択することができる。「開始位置挿入」ボタン203は、ラジオボタン202で選択された機能の開始位置を図19の要求仕様書に登録する処理を行う。「終了位置挿入」ボタン204は、同じくその機能の終了位置を図19の要求仕様書に登録する処理を行う。「戻る」ボタン205は、図19の要求仕様書画面190に戻る処理を実行する。
機能ツリー作成部42は、ユーザによる新たなソフトウェアについての機能ツリーの作成指示を受けると、その新たなソフトウェアの機能ツリーを作成するための画面を表示する機能を有する。作成された内容は、機能ツリーデータベース33の該当するソフトウェアに関する内容に反映される。
図21は、機能ツリー画面の一例を示す図である。機能ツリー画面210は、ソフトウェアのあるバージョンの機能ツリーを作成するための上部画面211と、機能の追加、更新用の下部画面215と、から構成される。上部画面211には、図17のバージョン一覧画面170のバージョン一覧表示領域171で選択されたソフトウェアのバージョンの機能ツリー212と、複数のボタン214が表示されている。この機能ツリー212の各機能にはラジオボタン213が設けられており、このラジオボタン213で機能ツリー212の中の1つの機能のみが選択され、選択された機能に対してボタン214で種々の処理を実行する。たとえば、「追加」ボタン214aは、機能ツリー212に新たに機能を追加する処理を行い、「削除」ボタン214bは、ラジオボタン213で選択された機能を削除する処理を行う。また、下部画面215では、上部画面211で選択された機能の名称の編集や、関数の変更などの変更処理を行うことが可能なオブジェクトが設けられている。
ソース管理部43は、ユーザによる新たなソフトウェアについてのソースの変更指示を受けると、そのソフトウェアを構成するソースの一覧をソース管理データベース32から抽出して、ソース一覧画面を表示する機能を有する。また、ユーザによる変更されるソースの抽出の指示を受けると、変更されるソースの一覧を表示したソース一覧画面を表示する機能も有する。さらに、ソース一覧画面から選択されたソースの編集を行う画面を提供し、その結果変更された内容をソース管理データベース32に反映させる機能も有する。
図22は、ソース一覧画面の一例を示す図である。ソース一覧画面220は、予め設定された条件またはユーザによって設定された条件を満たすあるバージョンのソースの一覧を表示するソース一覧表示領域221と、流用元のソフトウェアから新たなソフトウェアを作成する場合に、変更されるソースの抽出を実行する「変更ソース抽出」ボタン222と、抽出されたソースの変更を行う画面を表示する「ソース変更」ボタン223と、図17のバージョン一覧画面170に戻る「戻る」ボタン224と、を備えている。
試験仕様書作成部44は、ユーザによる新たなソフトウェアについての試験仕様書の作成指示を受けると、変更したソースが他の機能に及ぼす影響を特定し、どの機能の試験を実施したらよいかを選択し、試験仕様書を自動的に生成してユーザの端末装置2に試験仕様書画面として表示する機能を有する。このとき、試験仕様書作成部44は、新たなソフトウェアのコピー元である流用元のソフトウェアについての試験仕様を試験仕様データベース36からコピーしたものに基づいて、試験仕様書の作成を行う。
図23は、試験仕様書画面の一例を示す図である。試験仕様書画面230は、試験仕様の内容を表示する試験仕様表示部231と、ソースが変更された箇所の試験仕様を抽出する「試験仕様抽出」ボタン232と、試験仕様書画面230に表示された内容を保存する「保存」ボタン233と、図17のバージョン一覧画面170に戻る「戻る」ボタン234と、を備えている。
このような構成を有するソフトウェア開発支援装置1aは、中央演算処理装置、メモリ、ハードディスクなどを備える情報処理端末によって構成することができる。
ここで、各処理部の動作について説明する。最初に、バージョン一覧表示部38の動作処理について説明する。ユーザの端末装置2からソフトウェア開発支援装置1aにアクセスがあると、バージョン一覧表示部38は、図17に示されるようなバージョン一覧画面170を表示する。そして、このバージョン一覧表示領域171中のいずれかのボタン173〜177がユーザによって選択されると、そのボタンに関連付けされた処理部による処理が実行される。
つぎに、バージョン登録部39の動作処理について説明する。図24は、バージョン登録部によるバージョン登録の処理手順を示すフローチャートである。図17のバージョン一覧画面170のバージョン追加ボタン173が押される(クリックされる)と、バージョン登録部39は図18に示されるようなバージョン登録画面180を表示する(ステップS101)。ユーザによって図18のバージョン登録画面180のバージョン名の文字入力フィールド181と流用元バージョンの選択入力フィールド182が入力され、登録ボタン183が押されると、バージョン登録部39は、そのバージョン名と流用元バージョンのバージョンIDを取得する(ステップS102)。バージョン登録部39は、取得したバージョン名を有する新たなソフトウェア用のレコードを、バージョン管理データベース31に挿入する(ステップS103)。また、要求仕様データベース35から流用元のソフトウェアのバージョンのXML実ファイルの場所を取得し、取得したXML実ファイルをコピーするとともに、要求仕様データベース35に新たなソフトウェアのバージョン用のレコードを挿入する(ステップS104)。ついで、バージョン登録部39は、機能ツリーデータベース33の機能ツリートップテーブルと機能ツリーデータテーブルから流用元バージョンのデータを取得し、取得したデータのコピーを新しいバージョン用のレコードとして機能ツリートップテーブルと機能ツリーデータテーブルに挿入する(ステップS105)。
また、ソース管理データベース32のソーステーブルから流用元バージョンのソース名、実ファイルの場所を取得してメモリに保持する。その後、取得したデータに基づいてソースのコピーを行い、ソースの内容を新しいバージョン用のレコードとしてソーステーブルに挿入し、さらに、コピーしたソース内のある位置に所定の形式に則って記述されている内容から、ソーステーブルの「関連する機能ツリーID」とソースチェック項目テーブルのレコードを作成する(ステップS106)。図25は、ソースの記述内容の一例を示す図である。このソースの記述内容において、たとえば、行251に示されるように「//kinou()」で始まる行に機能の内容が表示されているものとし、この機能に対して関連する機能ツリーIDが作成される。なお、関連する機能ツリーIDの作成にあたっては、すでに作成された機能ツリーIDと重複しないように、機能ツリーデータベース33が参照される。また、行252に示されるように、「//check(n)」(nはなくてもよく、ある場合には数字など)で始まる行に、このソースに関するチェック項目が記述される。バージョン登録部39は、このようなソース中の所定の文字列を検出し、その文字列の後に続くテキストをソースチェック項目テーブルに格納する。そして、バージョン登録部39は、以上の処理が終了すると図17のバージョン一覧画面170を表示し(ステップS107)、バージョン登録処理を終了する。なお、ステップS101でユーザによって流用元のバージョンが選択されなかった場合には、それぞれのデータベースのテーブルには空の情報が挿入され、ユーザはそれぞれのテーブルをはじめから作成する。
つぎに、要求仕様書作成部41の動作処理について説明する。図26は、要求仕様書作成部による要求仕様書画面の表示処理手順を示すフローチャートである。図17のバージョン一覧画面170において、バージョン一覧表示領域171中のいずれかのバージョンがラジオボタン172で選択された状態で要求仕様書ボタン174が押されると、要求仕様書作成部41は、選択されたソフトウェアのバージョンのバージョンIDをバージョン管理データベース31から取得する(ステップS111)。ついで、バージョンIDを用いて、要求仕様データベース35からそのバージョンIDに対応する要求仕様書が記述されたXML実ファイルの場所を取得する(ステップS112)。取得したXML実ファイルを解析し(ステップS113)、図19に示されるような要求仕様書画面190をユーザの端末装置2に表示し(ステップS114)、要求仕様書画面190の表示処理が終了する。
図27は、要求仕様書作成部による機能挿入画面の表示処理手順を示すフローチャートである。図19の要求仕様書画面190において、要求仕様書の内容が表示された領域中のいずれかの位置にカーソルが置かれた状態で機能ツリーボタン192が押されると、要求仕様書作成部41は、要求仕様書画面190内のカーソルの位置を取得するとともに、表示されている要求仕様書のバージョンIDを要求仕様データベース35から取得する(ステップS121)。ついで、機能ツリーデータベース33の機能ツリートップテーブルと機能ツリーデータテーブルを参照して、取得したバージョンIDと同じデータを取得し(ステップS122)、その内容に基づいて機能ツリーを作成する(ステップS123)。そして、図20に示されるような作成した機能ツリーを含む機能挿入画面200をユーザの端末装置2に表示し(ステップS124)、機能挿入画面200の表示処理を終了する。
図28は、要求仕様書作成部による要求仕様書への機能の開始位置挿入処理手順を示すフローチャートである。図20の機能挿入画面200において開始位置挿入ボタン203が押されると、要求仕様書作成部41は、機能挿入画面200内のラジオボタン202で選択された機能の機能IDを、機能ツリーデータベース33から取得する(ステップS131)。また、図27のステップS121で取得した要求仕様書画面190内のカーソルの位置を取得する(ステップS132)。この場合、ユーザは、図19の要求仕様書画面190内で、機能の開始位置に対応する位置にカーソルを合わせているものとする。ついで、要求仕様書作成部41は、ステップS132で取得したカーソル位置に対応する要求仕様書のMXL実ファイル内の位置に、機能が記述される開始位置であることを示すタグを挿入する(ステップS133)。この開始位置を示すタグとして、ここでは“<”+機能ID+“>”の書式を有するものとする。そして、開始位置を示すタグが挿入された要求仕様書画面190をユーザの端末装置2に表示し(ステップS134)、要求仕様書への機能の開始位置挿入処理を終了する。
図29は、要求仕様書作成部による要求仕様書への機能の終了位置挿入処理手順を示すフローチャートである。図20の機能挿入画面200において終了位置挿入ボタン204が押されると、要求仕様書作成部41は、機能挿入画面200内のラジオボタン202で選択された機能の機能IDを、機能ツリーデータベース33から取得する(ステップS141)。また、図27のステップS121で取得した要求仕様書画面190内のカーソルの位置を取得する(ステップS142)。この場合、ユーザは、図19の要求仕様書画面190内で、機能の終了位置に対応する位置にカーソルを予め合わせているものとする。ついで、要求仕様書作成部41は、ステップS142で取得したカーソル位置に対応する要求仕様書のMXL実ファイル内の位置に、機能が記述された内容の終了位置であることを示すタグを挿入する(ステップS143)。この終了位置を示すタグとして、ここでは“</”+機能ID+“>”の書式を有するものとする。そして、終了位置を示すタグが挿入された要求仕様書画面190をユーザの端末装置2に表示し(ステップS144)、要求仕様書への機能の終了位置挿入処理を終了する。
図30は、要求仕様書作成部による要求仕様書の保存処理手順を示すフローチャートである。図19の要求仕様書画面190において保存ボタン191が押されると、要求仕様書作成部41は、要求仕様書画面190内の情報を取得するとともに、この要求仕様書に対応するバージョンIDを取得する(ステップS151)。ついで、要求仕様データベース35から取得したバージョンIDに対応する要求仕様所のXML実ファイルの場所を取得する(ステップS152)。そして、要求仕様書画面190内のデータを取得したXML実ファイルの場所に保存して(ステップS153)、要求仕様書の保存処理を終了する。
つぎに、機能ツリー作成部42の動作処理について説明する。図31は、機能ツリー作成部による機能ツリー画面の表示処理手順を示すフローチャートである。図17のバージョン一覧画面170において、バージョン一覧表示領域171中のいずれかのバージョンが選択された状態で機能ツリーボタン175が押されると、機能ツリー作成部42は、選択されたソフトウェアのバージョンのバージョンIDをバージョン管理データベース31から取得する(ステップS161)。ついで、機能ツリーデータベース33の機能ツリートップテーブルと機能ツリーデータテーブルを参照して、取得したバージョンIDと同じデータを取得し(ステップS162)、その内容に基づいて機能ツリーを作成する(ステップS163)。そして、図21に示されるような作成した機能ツリーを含む機能ツリー画面210をユーザの端末装置2に表示し(ステップS164)、機能ツリー画面210の表示処理を終了する。
図32は、機能ツリー作成部による機能ツリーの保存処理手順を示すフローチャートである。図21の機能ツリー画面210において保存ボタン214cが押されると、機能ツリー作成部42は、機能ツリー画面210内の機能ツリーに関するデータを取得するとともに、表示されている機能ツリーに関するバージョンIDを取得する(ステップS171)。ついで、取得した機能ツリーに関するデータの内容を、取得したバージョンIDに対応する機能ツリーデータベース33の機能ツリートップテーブルと機能ツリーデータテーブルに保存する(ステップS172)。このとき、イベント(機能ツリーの最下層の機能)を保存する必要がある場合には、ソース解析部40によってソース解析が実行され、イベント−関数の関連テーブルの内容も更新される(ステップS173)。以上で、機能ツリーの保存処理が終了する。
つぎに、ソース管理部43の動作処理について説明する。図33は、ソース管理部によるソース一覧画面の表示処理手順を示すフローチャートである。図17のバージョン一覧画面170において、バージョン一覧表示領域171中のいずれかのバージョンが選択された状態でソース一覧ボタン176が押されると、ソース管理部43は、選択されたソフトウェアのバージョンのバージョンIDをバージョン管理データベース31から取得し(ステップS181)、ソース管理データベース32のソーステーブルから取得したバージョンIDを有するソースIDを取得する(ステップS182)。ついで、取得したソースIDごとに、ソース名、変更フラグ、実ファイルの場所を取得し(ステップS183)、メモリに保持する。また、ソースチェック項目テーブルからステップS182で取得したソースIDごとにチェック項目も取得する(ステップS184)。さらに、ソースの実ファイルが格納されている場所から、ステップS182で取得したソースIDごとに、ソースの実ファイルの最終更新者と更新日を取得する(ステップS185)。以上のステップS183〜S184で取得した情報を用いて、図22に示されるようなソース一覧画面220を作成し、ユーザの端末装置2に表示して(ステップS186)、ソース一覧画面220の表示処理が終了する。
図34は、ソース管理部による変更するソースを抽出する処理手順を示すフローチャートである。図22のソース一覧画面220において変更ソース抽出ボタン222が押されると、ソース管理部43は、表示されているソースについてのバージョンIDを取得する(ステップS191)。また、ソース管理部43は、取得したバージョンIDを用いて、バージョン管理データベース31のバージョンテーブルから基になったソフトウェア(すなわち、流用元のソフトウェア)のバージョンIDを取得する(ステップS192)。ついで、要求仕様データベース35から選択しているソフトウェアのバージョンID(ステップS191で取得)と流用元のソフトウェアのバージョンID(ステップS192で取得)のXML実ファイルのパスを取得する(ステップS193)。選択されたソフトウェアと流用元のソフトウェアのバージョンのXML実ファイルの場所にアクセスして、XML実ファイルをメモリにロードする(ステップS194)。
その後、ソース管理部43は、選択されたソフトウェアと流用元のソフトウェアのXML実ファイル(要求仕様書)を比較して、その差分を抽出する(ステップS195)。抽出された差分を解析し、差分が機能ツリーのどの機能に該当するか、つまり選択されたソフトウェアにおいて流用元のソフトウェアのどの機能が変更されたものなのかを特定する(ステップS196)。なお、この機能の変更箇所の特定方法は、差分が機能開始位置を示すタグと機能終了位置を示すタグによって特定されるどの範囲に含まれているかを検出することによって、その差分がどの機能に該当するかを特定する。その後、機能ツリーを基にして、機能ツリーを上位から下位へとたどり、変更がどのイベント(すなわち機能ツリーの最下層の機能)に関連するかを特定する(ステップS197)。
イベントが特定されると、ソース管理部43はつぎに示す3つ流れで変更すべきソースをリストアップする(ステップS198〜S205)。まず1つ目は、リンク情報データベース34のイベント−関数の関連テーブルから特定されたイベント(すなわちイベントに対応する機能の機能ID)を用いて関数IDをリストアップし(ステップS198)、リストアップした関数IDを用いてソース−関数の関連テーブルから関連するソースをリストアップする(ステップS199)。つぎに2つ目は、イベント−関数の関連テーブルから特定されたイベント(すなわちイベントに対応する機能の機能ID)を用いて関数IDをリストアップし(ステップS200)、リストアップした関数IDを用いてソース−関数の関連テーブルから関連するソースIDをリストアップし(ステップS201)、さらに、ソース間のインクルード関連テーブルからリストアップしたソースIDを用いて関連するソースをリストアップする(ステップS202)。そして3つ目は、イベント−関数の関連テーブルから特定されたイベント(すなわちイベントに対応する機能の機能ID)を用いて関数IDをリストアップし(ステップS203)、リストアップした関数IDを用いて関数間の呼び出し関連テーブルから関連する関数IDをリストアップし(ステップS204)、さらに、ソース−関数の関連テーブルからステップS203でリストアップした関数IDを用いて関連するソースをリストアップする(ステップS205)。
以上の変更すべきソースのリストアップが終了すると、ソース管理部43は、ステップS199,S202,S205でリストアップされたソースをマージする(ステップS206)。その後、ソース管理部43は、以上の結果を受けてソーステーブルの変更フラグを更新して、ユーザの端末装置2にソース一覧画面220を再表示し(ステップS207)、変更するソースの抽出処理を終了する。
図35は、ソース管理部によるソースの実ファイルの表示処理手順を示すフローチャートである。図22のソース一覧画面220において、いずれかのソースが選択された状態でソース変更ボタン223が押されると、ソース管理部43は、選択されたソースのソースIDを取得する(ステップS211)。ついで、ソース管理データベース32のソーステーブルを参照し、取得したソースIDに対応するソースの実ファイルの場所を取得する(ステップS212)。その後、取得したソースの実ファイルの場所にアクセスして、ソースの実ファイルをユーザの端末装置2に表示し(ステップS213)、ソースの実ファイルの表示処理を終了する。なお、ユーザは、端末装置2から表示されたソースの実ファイルの内容の変更を行う。
つぎに、試験仕様書作成部44の動作処理について説明する。図36は、試験仕様書作成部による試験仕様書画面の表示処理手順を示すフローチャートである。図17のバージョン一覧画面170において、バージョン一覧表示領域171中のいずれかのバージョンが選択された状態で試験仕様書ボタン177が押されると、試験仕様書作成部44は、選択されたソフトウェアのバージョンのバージョンIDをバージョン管理データベース31から取得する(ステップS221)。このバージョンIDを基に機能ツリーデータベース33を参照して、機能ID(機能ツリートップIDまたは機能ツリーデータID)を取得する(ステップS222)。その後、取得した機能IDでループして、試験仕様データベース36を用いて試験仕様IDを取得する(ステップS223)。そして、試験仕様データベース36から試験仕様IDに対応する試験仕様を抽出し、所定の形式に加工した試験仕様書画面230をユーザの端末装置2に表示し(ステップS224)、試験仕様書画面230の表示処理を終了する。
図37は、試験仕様書作成部による試験仕様抽出の処理手順を示すフローチャートである。図23の試験仕様書画面230において試験仕様抽出ボタン232が押されると、表示している試験仕様書画面230についてのバージョンIDを取得する(ステップS231)。ついで、ソース管理データベース32のソーステーブルから、取得したバージョンIDを有し、変更フラグが「1」(すなわち、変更されたソース)の「関連する機能ツリーデータID」を抽出する(ステップS232)。その後、ステップS232で抽出した関連する機能ツリーデータIDと同じ機能ツリーデータIDを有するレコードの参照元機能ツリーデータIDを試験仕様データベース36から抽出する(ステップS233)。ついで、ステップS233で抽出した参照元機能ツリーデータIDに対応する試験仕様を試験仕様データベース36から抽出する(ステップS234)。そして、抽出した試験仕様を所定の形式に加工した試験仕様書画面230をユーザの端末装置2に表示し(ステップS235)、試験仕様抽出処理を終了する。
図38は、試験仕様書作成部による試験仕様書の保存処理手順を示すフローチャートである。図23の試験仕様書画面230において保存ボタン233が押されると、試験仕様書作成部44は、表示されている試験仕様書画面230内の情報を取得する(ステップS241)。ついで、表示されている試験仕様書に対応する機能IDを取得する(ステップS242)。そして、取得した機能IDと同じ機能IDを有する試験仕様データベース36内のレコードに、ステップS241で取得した情報を保存し(ステップS243)、試験仕様書の保存処理を終了する。
この実施の形態によれば、新たなソフトウェアと流用元のソフトウェアの要求仕様書を解釈して変更すべきソースを特定して提示するようにしたので、ユーザがどのソースを直すべきかを検討する作業の支援を行うことができる。その結果、ソフトウェアの開発期間の短縮が図れるとともに、ソースの変更漏れを防止して、ソフトウェアの品質向上に貢献することができるという効果を有する。
また、ソース変更時に、そのソースを変更する際の注意点をユーザに対して提示するようにしたので、経験の豊富なユーザでなくても、ソースの変更を容易に行うことができるという効果を有する。また、これによって、開発するユーザに依存しない安定した品質のソフトウェアの開発を行うことができるという効果も有する。
さらに、ソース変更後の試験仕様書を自動的に作成するようにしたので、本来行うべき試験の試験漏れ防止や、必要のない試験を実行することによるコストの超過を防ぐことができるという効果を有する。