(57)【特許請求の範囲】
【請求項１】
複数の開発会社の夫々に備えられた端末と、通信ネットワークを介して前記端末から送られてくる情報に基づいて開発ソフトウェアの完成度を判定するサーバとを有する開発支援システムであって、
前記サーバは、
開発会社ＩＤに前記端末のアドレスを関連付けて保存する開発会社ＤＢと、
納品定義ＩＤごとに、開発会社ＩＤ、テスト項目、要求仕様に合致しているかを確認するための入力情報、期待する出力情報、開発工程、入出力系や性能などの分野を表す属性、受注者および発注者が確認した日を関連付けた納品定義項目を保存する納品定義ＤＢと、
テスト項目ごとに該テストを実行するために動作すべき開発モジュールのＩＤ、該開発モジュールをテストする際に必要な前記入力情報、該入力情報に対する前記出力情報、該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールのＩＤを関連付けて保存する検証順序ＤＢと、
納品定義ＩＤごとに、電子メール、電話番号、および通知方法を関連付けたあて先一覧を保存する手段と、
前記端末から送られてきた納品定義項目を前記納品定義ＤＢに保存するデータ入出力手段と、
前記端末から前記納品定義ＤＢへ書き込み可能とし、前記納品定義ＤＢに新たな書き込みがあった際に、前記あて先一覧を参照して、前記通知方法に基づいて電子メールアドレスあるいは電話番号へ新たな書き込みがあったことを通知する納品定義項目修正通知手段と、
前記検証順序ＤＢの検証順序に従って検証を行わせる開発モジュールのＩＤを取得する検証順序制御手段と、
前記検証順序ＤＢから検証を行わせる開発モジュールの入力情報を取得し、当該入力情報を対応する開発会社の端末に送信し、その後、当該端末からテスト結果として送られてくる出力情報を受信し、該テスト結果を前記検証順序ＤＢの該入力情報に対する前記出力情報と比較判定して合格、不合格を判定し、さらに合格したテスト項目の割合をあらかじめ決められた合格判定基準と比較して開発ソフトウェアの完成度を算出する自動検証手段と、を備え、
前記端末は、
開発ソフトウェアに対する納品定義項目を入力するする入出力処理手段と、
入力した納品定義項目を前記サーバへ送信する送受信処理手段と、
前記サーバから送られてくる入力情報を受信し、その入力情報をパラメータとして開発ソフトウェアを起動し、その後、開発ソフトウェアが出力する出力情報を前記サーバに送信する検証支援手段と、
を備えたことを特徴とする開発支援システム。
【請求項２】
前記自動検証手段は、各々の開発会社の端末から送られてきた開発ソフトウェアの出力情報を次の開発会社の開発ソフトウェアの入力情報として該次の開発会社の端末へ送信することを特徴とする請求項１に記載の開発支援システム。
【請求項３】
前記サーバは、テスト項目ごとに該テストを実行するために動作すべき開発モジュールのＩＤ、該開発モジュールをテストする際に入力情報として必要な入力情報、テストの際に出力が期待される出力情報、該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールのＩＤ、期待する所要時間、テストに要した時間とを関連付けて保存する性能試験ＤＢを備え、
前記端末の前記検証支援手段は、前記入力情報をパラメータとして開発ソフトウェアを起動したときの時刻と、開発ソフトウェアからの出力情報を受信したときの時刻とを前記サーバへ送信し、
前記サーバの前記自動検証手段は、前記端末から受信した開発ソフトウェアを起動したときの時刻、開発ソフトウェアからの出力情報を受信したときの時刻からテストに要した時間を算出して前記性能試験ＤＢに保存すると共に、該テストに要した時間と前記期待する所用時間とを比較して合格、不合格を判定することを特徴とする請求項１または２に記載の開発支援システム。
【請求項４】
開発会社ＩＤに端末のアドレスを関連付けて保存する開発会社ＤＢと、納品定義ＩＤごとに、開発会社ＩＤ、テスト項目、要求仕様に合致しているかを確認するための入力情報、期待する出力情報、開発工程、入出力系や性能などの分野を表す属性、受注者および発注者が確認した日を関連付けた納品定義項目を保存する納品定義ＤＢと、テスト項目ごとに該テストを実行するために動作すべき開発モジュールのＩＤ、該開発モジュールをテストする際に必要な前記入力情報、該入力情報に対する前記出力情報、該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールのＩＤを関連付けて保存する検証順序ＤＢと、納品定義ＩＤごとに、電子メール、電話番号、および通知方法を関連付けたあて先一覧を保存する手段とを有し、複数の開発会社の夫々に備えられた端末から通信ネットワークを介して送られてくる情報に基づいて開発ソフトウェアの完成度を判定するサーバ上で動作するプログラムであって、
前記端末から送られてきた納品定義項目を前記納品定義ＤＢに保存するデータ入出力処理と、
前記端末から前記納品定義ＤＢへ書き込み可能とし、前記納品定義ＤＢに新たな書き込みがあった際に、前記あて先一覧を参照して、前記通知方法に基づいて電子メールアドレスあるいは電話番号へ新たな書き込みがあったことを通知する納品定義項目修正通知処理と、
前記検証順序ＤＢの検証順序に従って検証を行わせる開発モジュールのＩＤを取得する検証順序制御処理と、
前記検証順序ＤＢから検証を行わせる開発モジュールの入力情報を取得し、当該入力情報を対応する開発会社の端末に送信し、その後、当該端末からテスト結果として送られてくる出力情報を受信し、該テスト結果を前記検証順序ＤＢの該入力情報に対する前記出力情報と比較判定して合格、不合格を判定し、さらに合格したテスト項目の割合をあらかじめ決められた合格判定基準と比較して開発ソフトウェアの完成度を算出する自動検証処理と、
をサーバ上で実行させることを特徴とする開発支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１つのシステムのソフトウェアの開発を外部の開発会社に委託する場合において、開発の過程もしくは納品時に要求仕様の満足度または完成度をチェックするシステム、方法もしくはプログラムに関し、特に開発を１つまたは複数の開発会社に委託した場合において、開発の過程および納品時に委託した開発会社の開発成果物の要求仕様の満足度をチェックし、発注した開発物の完成度を判定することで開発支援を行う開発支援システム、および開発支援プログラムに関する。
【背景技術】
【０００２】
従来、ソフトウェアの開発手法としては、ウォーターフォール型開発モデル、プロトタイプ型開発モデル、スパイラル型開発モデル、プロセス型開発モデルなどが存在している。どの開発モデルを用いて開発を行ったとしても要求仕様の内容が正しく実現されているかということが開発物の納入の際に重要なポイントである。ソフトウェア開発の受託会社が発注者の要求仕様を間違って理解して開発を行った場合は、開発に手戻りが発生してしまう。
【０００３】
要求仕様書が明確に定義されていない場合は、納品物を検収する際にも正確な検収ができないため、検収した後に実際に納品物を動作させてから要求仕様を満足していないことが判明することが頻繁に発生する。特許文献１は、ソフトウェア開発に際し、ソフトウェア仕様確認サーバを用意し、プロトタイピングで仕様確認を行いながら要求仕様を明確にしてソフトウェアを完成させるという方式を提案している。図１８は従来のウォーターフロー型開発モデルの開発工程表を示している。
【０００４】
特許文献２は、ソフトウェア開発プロジェクトの管理者と開発者がその開発の進捗状況を自動管理する手法を提案している。特許文献３は、ソフトウェア開発プロジェクトの発足に際して、事前に要求仕様を定義しその要求仕様書に関して定量的および定性的に判断できる項目をファイルとしてあらかじめ作成しておき、該ファイルに基づきプロジェクトの進捗状況を管理するという手法を提案している。特許文献４は、ソフトウェア開発の進捗管理と、開発担当者の業務の負荷分散・状況把握を行う手法を提案している。
【特許文献１】特開平１０−３２０１８６号公報
【特許文献２】特開２００２−３６６６７４号公報
【特許文献３】特開平０８−２３４９７７号公報
【特許文献４】特開２００４−９４８２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところが、上記従来の方法で発注者と受注者が互いに納得できるソフトウェア開発の管理を行うための手法は確立していない。特許文献１で提案されているプロトタイプ型開発モデルを用いたソフトウェア仕様確認サーバでは、発注者および受注者で要求仕様をまとめながら開発を進めていくため仕様自体はお互いに認識されたものにはなるが、開発物の納品の際に開発物の仕様が要求仕様を満足しているかを判断できるものではない。
【０００６】
納品の際には、受注者が作成した試験結果報告書を発注者が確認するしかなく、例えば有る程度自動的に開発物の完成度を納品前の検証試験時などに確認する方法を提供していない。よって納品される開発成果物には要求仕様と異なる不具合を内在している可能性は皆無とは言えずフィールドテストもしくはお客様へ開発物によるサービスなどを提供する際に不具合が発見される可能性が無いと言えないことは明らかである。
【０００７】
特許文献３も同様に事前に要求仕様を定義しその要求仕様書に関して定量的および定性的に判断できる項目をファイルとしてあらかじめ作成しておき、該ファイルに基づきプロジェクトの進捗状況を管理するという手法のみでは、開発成果物の納品時に、納品物が要求仕様と異なる不具合を内在してうるかどうかは発注者は分からない。よって検収に時間を要して開発物の完成度を前記ファイルと比較して検証を行うという作業が必要となる。
【０００８】
本発明はかかる従来の問題に鑑みてなされたものであり、ソフトウェア開発を１つもしくは複数の開発会社に発注するに際して、開発過程での開発物の仕様確認を行うことができ、さらに納品に際しての開発成果物の要求仕様に対する完成度の確認を行えるような指標を事前に発注者および受注者が共同して作成し、前記指標に従って自動的に開発物の検証を行うことで開発物の仕様の完成度を判定できる開発支援システム、および開発支援プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明に関わる開発支援システムは、開発物に対する入力情報とその入力に対応する開発物からの出力情報から構成される納品定義項目を設け、通信ネットワークを経由した外部からの要求に応じて入力情報を受信し、前記入力情報をパラメータとして開発物を起動し、開発物からの出力情報を受信し、前記出力情報を通信ネットワークを介して外部に送信する検証支援手段と、前記検証支援手段に通信ネットワークを介して入力情報を送信し、前記検証支援手段からの出力情報を受信し、前記入力情報と前記出力情報により前記納品定義項目を参照し開発物の完成度を判定する自動検証手段とを備えたことを特徴とする。
【００１０】
さらに好ましくは、自動検証手段および検証支援手段は、開発物全体または個々の開発物の単位で検証を行うように構成するのも良い。また、複数の拠点に複数の検証支援手段が存在し、自動検証手段は前記複数の拠点の検証支援手段に入力情報を送信し、自動検証手段は、複数の検証支援手段より受信する複数の出力情報により前記納品定義項目を参照し開発物の完成度を判定するように構成するのも好ましい。
【００１１】
本発明では、納品定義項目を記載した例えば納品定義書に従って開発を行い、開発の過程もしくは納品時に納品定義書に基づいて開発物全体および個々の開発物の検証を外部の自動検証手段から開発の受注者の検証支援手段に指示することで検証を行うシステムを提供する。これにより開発に際して個々の開発および開発全体の要求仕様の定義を納品定義項目から判断することが可能となり、思い込みの開発などを行う危険性を防ぐことができる。さらに納品以前に個々の開発物および開発全体の検証が可能となる。また複数の拠点での開発を行うことも可能となり、複数の拠点で行った開発物の検証も納品前および納品時に遠隔から行うことができる。
【００１２】
さらに、複数の拠点に存在する検証支援手段において各々の拠点の開発物の出力情報が他の拠点の入力情報になる場合に、自動検証手段は、各々の拠点の検証支援手段に対してあらかじめ決められた順序に従って入力情報を送信し、該拠点の検証支援手段からの出力情報を受信してさらに次の拠点の入力情報として送信し、最後の拠点の検証支援手段からの出力情報または全拠点の出力情報により前記納品定義項目を参照し各拠点の開発物の完成度を判定するように構成するのも良い。
【００１３】
さらに、複数の拠点に存在する検証支援手段において各々の拠点の開発物の出力情報が他の拠点の入力情報になる場合に、各拠点の検証支援手段は、出力情報を次の入力として必要としている次の拠点に入力情報として送信し、最後の拠点は出力情報を自動検証手段に送信し、自動検証手段は、受信した出力情報により納品定義項目を参照し、一連の開発物の完成度を判定するように構成するのも好ましい。
【００１４】
本発明により、１つの開発において関連した開発を複数の拠点で行う場合に、一拠点の結果を元に次の拠点の検証が行える。この連続した拠点の一連の検証は、自動検証手段が各々の拠点の開発物の検証の結果を各々の拠点の検証支援手段が受信し、さらに自動検証手段に送信する一連の作業を通して行う。また、検証支援手段が次の拠点に直接入力情報を送信することで一連の開発物の検証を連続して行うことが可能となる。
【００１５】
さらに本発明に関わる開発支援システムは、開発物に対する入力情報および入力時刻とその入力に対応する開発物からの出力情報および出力時刻から構成される納品定義項目を設け、通信ネットワークを経由した外部からの要求に応じて入力情報を受信し、前記入力情報をパラメータとして開発物を起動する際にその時刻を記憶し、開発物からの出力情報を受信したときにその時刻を記憶し、さらに前記記憶した入力した時の時刻および出力を受信したときの時刻を通信ネットワークを介して外部に送信する検証支援手段と、前記検証支援手段に通信ネットワークを介して入力情報を送信し、前記検証支援手段から受信する前記入力情報を受信したときの時刻と、開発物から出力情報を受信したときの時刻および該出力情報に基づき前記納品定義項目を参照し開発物の完成度を判定する自動検証手段とを備えたことを特徴とする。
【００１６】
本発明により、各開発物の検証を通信ネットワークを介して外部から検証を行う拠点に入力情報を送信し、該拠点の検証支援手段が検証対象の開発物を起動する際にその時刻を取得し、且つ開発物からの出力情報を受信した時にその時刻を取得し開発物の時間的性能を測定することで開発物の完成度を測ることができる。
【００１７】
さらに好ましくは、自動検証手段および検証支援手段は、開発物全体もしくは個々の開発物単位で開発物の検証を行うように構成するのも良い。また、複数の拠点に複数の検証支援手段が存在し、自動検証手段は前記複数の拠点の検証支援手段に入力情報を送信し、複数の検証支援手段より受信する前記入力したときの時刻と前記出力情報を受けたときの時刻を含む複数の出力情報により納品定義項目を参照し開発物の完成度を判定するように構成するのも好ましい。
【００１８】
さらに、複数の拠点に存在する検証支援手段に対し、各々の拠点の開発物の出力情報が他の拠点の入力情報になる場合に、各々の拠点の検証支援手段に対してあらかじめ決められた順序に従って入力情報を送信し、その拠点の検証支援手段からの出力情報を受信してさらに次の拠点の入力情報として送信し、全拠点の入力した時刻と出力を受信したときの時刻を含む出力情報により前記納品定義項目を参照し各拠点の開発物の完成度を判定するように構成するのも好ましい。また、複数の拠点内に前記拠点での開発に関する納品定義項目を有し、該拠点内の検証支援手段は、前記納品定義項目に基づいて入力情報をパラメータとして開発物を起動し、開発物からの出力情報を基に前記納品定義項目を参照して開発物の完成度を判定するのも好ましい。
【００１９】
本発明により、個々の開発物および全開発物の検証を通信ネットワークを介して行うことができ、開発が複数の拠点にまたがっている時においても複数拠点の検証支援手段が測定した開発物の時間的性能を計測することができ開発物の時間的性能の完成度を判定することができる。さらに１つの拠点の出力が次の拠点の入力になる場合に、一連の拠点で行われる開発物の検証の際の時間計測をそれぞれ入手し、一連の開発全体の時間的計測を基に時間的性能を判定することができる。
【００２０】
さらに、開発を複数の部分に分割し、それぞれの開発を複数の拠点の開発会社に委託する場合において、発注側が管理するサーバに委託を行う開発それぞれについての納品定義項目を設け、各開発会社は前記サーバで管理されている納品定義項目に対して、自己の開発に関する納品定義内容にのみ遠隔で書き込みが許可され、拠点内部で検証を行う際には前記サーバから該拠点に関連する納品定義項目をダウンロードし、検証支援手段はダウンロードした納品定義項目を基に検証を行うように構成するのも良い。
【００２１】
加えて前記サーバ上に存在する各拠点に関する納品定義項目への検証内容を該当する拠点の構成員が遠隔で書き込み可能とし、納品定義項目に新たな書き込みが有った際に、あらかじめ登録されている電子メールアドレスに新たな記載が有ったことを通知する納品定義項目修正通知手段を有することも好ましい。
【００２２】
また、複数の検証項目が納品定義項目に定義されていた場合に、検証の結果を前記納品定義項目を基に参照するに際して、全ての検証項目ごとに検証の結果をレポートとして出力し、あらかじめ決められたメールアドレスにメール送信するのも好ましい。さらに、通信ネットワークとしてインターネットを利用することも好ましい。さらに好ましくは、開発物の完成度は、前記納品定義項目に定義された１つのテスト項目に複数の確認項目がある場合は、確認項目ごとに設定された合格判定基準にしたがって判定された全確認項目の合格率が合格基準を超えている場合に合格と決定するのも良い。
【００２３】
本発明により、通信ネットワークを介して通信可能なサーバ上に要求仕様である納品定義項目を登録した場合に、該納品項目の内容を発注者および受注者で相互に決定するに際し、複数の拠点に存在する開発会社の担当者が自分が担当する分の納品項目定義を遠隔で読み書きできるが、他の開発会社の納品定義項目の内容を修正することはできないようにすることができるので、セキュリティを確保した上で納品定義に関して共同作業ができる。
【００２４】
また、検証結果をレポートとして自動的にメールで送信することができるため検証の確認も早く行うことができる。また、テスト項目の確認項目ごと設定された合否判定基準参照して合格となった項目数の合計値の割合を判定することで発注者および受注者が確認した判定基準を満足するかどうかを自動的に判定することができる。
【００２５】
上記目的を達成するため、本発明に関わる開発支援プログラムは、開発ソフトウェアの仕様確認を外部から行うサーバ上で動作するプログラムであって、通信ネットワークを経由した外部からの要求に応じて入力情報を受信し、前記入力情報をパラメータとして開発物を起動し、開発物からの出力情報を通信ネットワークを介して外部に送信する第１の処理と、前記第１の処理に通信ネットワークを介して入力情報を送信し、前記第１の処理からの出力情報を受信し、前記入力情報と前記出力情報により前記納品定義項目を参照し開発物の完成度を判定する第２の処理と、をサーバ上で実行させることを特徴とする。
【００２６】
さらに前記第２の処理は、複数の開発拠点に存在する前記第１の処理に入力情報を送信し、前記複数拠点の第１の処理が送信する複数の出力情報を受信し、前記送信した複数の入力情報と、前記受信した複数の出力情報により前記納品定義項目を参照して開発物の完成度を判定するのも好ましい。
【００２７】
さらに好ましくは、前記第１の処理の出力情報が次の拠点の入力情報となる場合に、前記第２の処理は、あらかじめ決められた順序に従って順序正しく次の前記第１の処理に入力情報を送信し、該当の拠点の前記第１の処理からの出力情報をさらに次の拠点の前記第１の処理の入力情報として送信し、最後の拠点からの出力情報もしくは全拠点からの出力情報により前記納品定義項目を参照して各拠点の開発物の完成度および一連の開発物の完成度を判定するように構成する。
【００２８】
また、前記第１の処理の出力情報が次の拠点の入力情報となる場合に、前記第２の処理は、あらかじめ決められた順序に従って第１番目の前記第１の処理に入力情報を送信し、該拠点の前記第１の処理は出力情報を次の拠点の前記第１の処理に入力情報として送信し、最後の拠点からの出力情報に基づいて前記納品定義項目を参照して各拠点の開発物の完成度および一連緒開発物の完成度を判定するように構成するのも好ましい。
【発明の効果】
【００２９】
以上説明したように本発明によれば、ソフトウェア開発の発注者および受注者の双方が開発成果物の完成度合いを正確に判断することができる。発注側として納品物の評価内容を納品以前に特定しているため、開発に際し発注側と受注側の開発物の仕様の勘違いなどを防止することが可能である。また開発の過程や納品時に開発物の検証を自動的に行うことができ、発注者および受注者双方にとって仕様の確認が容易であり且つ要求仕様の準拠の度合いを容易に判断することができる。
【００３０】
また、開発を複数の開発会社に発注した場合は、一つの開発会社の開発物の出力結果を他の開発会社の開発物の入力へとすることができるので、各々の開発会社の開発物の検証を実態に合った環境で且つ早い段階で行うことが可能となる。よって今まではフィールドテストで発見されていたような不具合を早めに発見することができることとなり、今まで遅い段階で発生していた手戻り不具合の発生を防止することができ、満足度の高いソフトウェアの開発を提供することができる。
【００３１】
さらに外部に開かれた例えばインターネット環境を利用することを可能としているため、開発の発注者と受注者が地理的に離れた場所に拠点を構えている場合においても、環境に依存せずに開発の発注および受注が可能であり、開発物の要求仕様に対する満足度をインターネット経由で判定することが可能である。よって、開発物の管理も容易となり、各々の関連ある開発物の検証を各々の拠点で行うことができ、工数の削減にもつながる。
【発明を実施するための最良の形態】
【００３２】
以下、本発明を実施するための最良の形態について説明する。図１は本発明の第１の実施の形態に関わる開発支援システムおよび受注会社の端末の機能ブロック図である。図１において開発を請け負う受注会社の端末５は、通信ネットワーク４を介しては開発支援システム１とつながっている。ここで通信ネットワーク４は例えば従来の専用線を用いた専用のネットワークもしくは、ＡＤＳＬ(Asymmetric Digital Subscriber Line)、ＦＴＴＨ(Fiber To The Home)、ＣＡＴＶ(Cable TV)などの回線を利用したインターネット網などである。
【００３３】
さらにインターネット網の場合などはセキュリティの問題および外部からの攻撃に備えるため、図２に示すようにＦ／Ｗ(Firewall)が備わっていたりする。またインターネットを利用する場合は、通信を平文でおこなうと内容が漏れてしまうため、ＩＰＳｅｃ(Security Architecture for Internet Protocol)やＰＰＴＰ(Point-to-Point Tunneling Protocol)などを用いてＶＰＮ(Virtual Private Network)を構築していたり、通信に際してＳＳＬ(Secure Socket Layer)など暗号化を用いるなどの対策が施されている。このようにこれから説明する端末５と開発支援システム１間は通信ネットワーク４としてインターネット回線を利用する場合は暗号化されて通信が行われる場合がある。
【００３４】
開発支援システム１は図１の機能ブロック図に示すように、発明を実現するために、各種のデータもしくはデータベースを長期的または一時的に保存する記憶部１４、機能を実現するために前記記憶部１４に保存されている情報を利用したり、情報を一時的に記憶部１４に保存したり、通信ネットワーク４からの情報などに基づいて各種演算を行う中演算処理部１３、開発支援システム１とインタラクティブに相互作用するヒューマンインタフェース機能を有する入力部１５および表示部１６、さらに外部の端末５と通信ネットワーク４を介して情報の送受信を行う送受信部１２から構成されている。
【００３５】
中央演算処理部１３はさらに、以下に述べる手段（機能）を備えている。送受信処理手段（機能）１３１は、外部からの情報の送受信を送受信部１２と通信することで行う機能を有し、例えばＴＣＰ／ＩＰなどの通信プロトコルの終端を行う機能を有する。入出力処理手段（機能）１３２は、入力部１５からの入力と、中央演算処理部１３からの出力を処理する機能を有しする。データ入出力手段（機能）１３３は、入力部１５からもしくは外部の端末５の入力部５５から通信ネットワーク４を介して入力される情報と、中央演算処理部１３からの情報を出力部１６もしくは通信ネットワーク４を介して外部の端末５に送信する機能を有する。
【００３６】
自動検証手段（機能）１３４は、記憶部１４に保存される納品定義データベース（ＤＢ）１４２、検証順序データベース（ＤＢ）１４３、性能試験データベース（ＤＢ）１４４および開発関連データベース（ＤＢ）１４５に記憶されているデータに基づいて外部に存在する開発を請け負う受注会社の開発拠点に存在する検証支援手段（機能）５３３に登録されているテストを行わせる機能を有する。検証順序制御手段（機能）１３５は、あらかじめ決められている例えば図７に示すような検証順序に従って順序良く検証を行わせる機能を有する。
【００３７】
納品定義項目修正通知手段（機能）１３６は、開発支援システム１内に存在する納品定義データベース（ＤＢ）１４２もしくは受注会社の端末５内に存在する納品定義データベース（ＤＢ）５４２に新たな納品定義が追加されたり、修正されたりしたときに自動的にあらかじめ決められた携帯端末を含む電子メール、電話などの通信手段を用いて通知する機能を有する。
【００３８】
記憶部１４はさらに、以下に述べるデータベースもしくはデータを保存する。開発会社データベース（ＤＢ）１４１は、図４に示す会社ＩＤ、会社名、住所、電話番号、会社の電子メールアドレスおよび該会社が属しているドメイン名もしくは開発で使用する端末５のＩＰアドレスなどから構成される受注会社の会社情報を保存する。納品定義データベース（ＤＢ）１４２は、図５に示すように各開発のＩＤごとに、該発注に関する開発ＩＤ、該開発が内在する複数の納品定義書全体を示す大納品定義ＩＤおよび進捗情報を有している。
【００３９】
大納品定義ＩＤは、さらに１つの開発に関してテストで確認すべき要求仕様が登録される納品定義ＩＤに分かれ、さらに各々の納品定義ＩＤは該当する部分の開発を発注する開発会社の会社ＩＤと詳細な納品定義内容を備えている。図６は、詳細な納品定義内容の例を示している。納品定義に含まれる項目は図６に示すように例えば項目番号、項目の概略を説明する項目概略、要求仕様に合致しているかを確認するための情報としての確認内容（入力情報の場合もある）、満足度を図るための確認事項（期待する出力情報である場合もある）および、項目の開発工程、入出力系や性能などの分野を表す属性、受注者および発注者が確認した日などの欄が設けられている。
【００４０】
検証順序データベース（ＤＢ）１４３は、１つのテスト項目を確認するのに動作する全ての個々の開発を順に記載しており、テストに際してはその記載順にテストを行うことで自動的に最終的なテスト結果が得られるように構成されるデータベースである。検証順序ＤＢ１４３の内容は図７に示すように、各々のテスト項目に対応して発注した開発の開発モジュールＩＤ、該開発をテストする際に入力情報として必要な入力情報、テストの際に出力が期待される出力情報、さらに該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールの開発モジュールＩＤ、テストが終了した際に該テストが成功裏に完了したかを受注側が確認したときに記載する受注者確認日、受注確認日と同様に該テスト完了時に発注者側がテストが成功であったと判断するときに記載する発注者確認日から構成されている。
【００４１】
さらに次にテストを行う開発モジュールのポインタの先には同様な構成のデータが１つのテストに関してテストが終了するに至るまでリンクされており、次の開発モジュールＩＤにはテストの完了を示す場合は例えば"ＦＦ"が記載されているものとする。もしくはアスキー文字列で"ＥＮＤ"などと記載されていても良い。
【００４２】
性能試験データベース（ＤＢ）１４４は、図８に示すように本実施の形態では、図７に示す検証順序ＤＢ１４３の構成に加えてテストにおいて「期待する所要時間」とテストに「要した時間」の欄が追加になっている。本実施の形態では、検証順序ＤＢ１４３の構成に追加という形式であるが、１つ１つテスト行う場合は順序は必要が無い。開発関連データベース（ＤＢ）１４５は、本実施の形態では図９に示すように１つの開発を複数の開発モジュールに分け受注会社に発注する際の開発の最小単位を表している。
【００４３】
開発ＩＤごとに該開発ＩＤで分けている最小単位の開発モジュールのＩＤが存在し、さらに各々の開発モジュールごとにその開発モジュールを受注する開発会社の会社ＩＤとその開発モジュールが使用する複数の開発モジュールの開発モジュールＩＤから構成される。本実施の形態では関連モジュールはその開発モジュールが使用する開発モジュールと規定しているが、その開発モジュールを使用する上位の開発モジュールを規定していても良い。図７および８に示す開発モジュールＩＤはその関係が図９に示されている。開発支援システム１は以上のように構成されている。
【００４４】
次に開発拠点側の端末５について図１を用いてその機能ブロックを説明する。構成としては開発支援システム１と同様であり、概略としては通信ネットワーク４を介して開発支援システム１と情報の送受信を行う送受信部５２、さまざまな情報を解析して入力情報や、保存しているデータなどから演算して処理を行う中央演算処理部５３、開発側でテストを行うのに必要な情報を保存する記憶部５４、端末５との万マシンインタフェースを司る入力部５５と表示部５６から構成されている。
【００４５】
さらに中演算処理部５３は、以下に述べる機能を有する各手段から構成されている。送受信処理手段（機能）５３１は、送受信部５２と情報の送受信を行い、例えばＴＣＰ／ＩＰなどの通信プロトコルの終端の制御を行う。入出力処理手段（機能）５３２は、入力部５５と表示部５６と入出力情報を制御する。検証支援手段（機能）５３３は、開発支援システム１からの入力情報をパラメータとして開発物を起動して開発物からの出力情報を取得したり、もしくは端末５の記憶部５４内に保存されたその端末に特有の納品定義ＤＢ５４２および検証順序ＤＢ５４３を参照して開発物にパラメータを入力情報として渡して開発物を起動し、開発物からの出力情報を取得し、該出力情報を開発支援システム１内の自動検証手段（機能）１３４に送信する機能を有する。
【００４６】
検証順序制御手段（機能）５３４は、図７に示す検証順序に従って検証を行うに際し、当該拠点の検証における出力情報を次の開発モジュールへと直接送信する機能を有する。記憶部５４は以下に示すように複数のデータベースを有している。納品定義ＤＢ５４２は、当該拠点内で検証を行う際に使用される当該拠点のみのデータベースでありその内容は開発支援システム１内の納品定義ＤＢ１４２のサブセットである。検証順序ＤＢ５４３は前述したように次の開発モジュールに検証の出力を送信するのに使用されるデータベースであり、内容は開発支援システム１の検証順序ＤＢ１４３のサブセットである。
【００４７】
図２は開発支援で使用する納品定義ＤＢ１４２および５４２の関係を示している。開発支援システム１内の納品定義ＤＢ１４２は開発に関して全開発拠点の開発案件のテスト項目を有している。各開発拠点である「い社」、「ろ社」、「は社」は納品定義ＤＢ５４２として１つの開発案件に対して自分の開発案件の分のみの納品定義を有している。本実施の形態を示す図２では、１つの開発案件である「第１システム開発案件」に対して上記「い社」、「ろ社」、「は社」の３社に開発を委託しており、例えば「い社」には開発のＡ機能とＢ機能を発注し、「ろ社」にはＣ機能のみを発注し、「は社」にはＤ機能およびＥ機能を発注していることを示している。よって各社の納品定義ＤＢ５４２には、「い社」はＡ機能とＢ機能の情報を有し、「ろ社」はＣ機能、「は社」はＤおよびＥ機能の情報を有している。また、納品定義の登録・修正および、テストにおける利用方法などについては以降に述べる。
【００４８】
図３は本実施の形態における開発支援システムの業務フローの概略を示している。本実施の形態では、まず発注を受けた開発会社が開発における確認用テスト項目を作成し（Ｓ３１）、開発支援システム１内のデータベースに納品定義として登録される。登録された確認用テスト項目の内容のチェックは発注者が行い（Ｓ３２）、抜けなどの問題があれば「発注者確認用テスト項目」として受注者に登録を指示する（Ｓ３５）。
【００４９】
指示を受けた受注開発会社は指示を受けた内容を「確認用テスト項目」に追記したり修正したりする。このように納品定義はスパイラル型開発モデルのような開発手法で改善されながら完成させる。追記・修正された「確認用テスト項目」は再度発注者によってチェックされ要求仕様を満足できるものであれば一旦完成し、開発後に受注側および発注側が検査を行い、問題が無ければ納品され、発注者が検収を行い一連の発注による開発が完了する。図３は上記のように受注開発に関する一連の流れを示している。
【００５０】
開発支援システム１および開発拠点の端末５は以上のように構成され、以下に各々の動作について説明する。図１０は納品定義ＤＢ１４２、５４２に記載する「確認用テスト項目」の記載を開始するところから、記載終了後に開発を開始し、総合テストおよびフィールドテストにおいて、前記記載した納品定義ＤＢ１４２、５４２に記載されている「確認用テスト項目」を参照して検証を行い、納品してから検証までという一連の作業をフローで表したものである。
【００５１】
図１０を用いて受注開発支援に関する一連の作業フローの概略を説明する。図１０において、向かって左端からそれぞれ、各拠点の端末５、開発支援システム１、発注側端末を表している。各拠点の端末５は複数存在するものであるが図１０においては１つの端末についてのみ説明している。また発注側端末としては、システムに直接入力可能な開発支援システム１の入力部５でも良いし、発注側端末としてインターネットを利用し、開発支援システム１がＷＷＷで情報の送受信が可能になっている場合はインターネットに接続される端末であればどこに存在しても良い。本実施の形態では、インターネットを利用した発注側端末であるものとする。
【００５２】
図３で説明したように、各開発拠点の端末５から「確認用テスト項目」入力する（Ｓ１０１ａ）。入力された「確認用テスト項目」は通信ネットワーク４を介して開発支援システム１の送受信部１２、送受信処理手段１３１を経由して、データ入出力手段１３３が受信し（Ｓ１０１ｂ）、データ入出力手段１３３はその受信した「確認用テスト項目」の内容を図５および図６に記載の納品定義ＤＢ１４２に書き込む（Ｓ１０２ｂ）。新たにテスト項目が書き込まれたり修正されたりした場合は、開発支援システム１の納品定義項目修正通知手段（機能）１３６が追加・修正があったことをあらかじめ決められたあて先にあらかじめ決められた方法で通知する（Ｓ１０３ｂ）。例えば各拠点の開発会社のプロジェクトリーダおよび発注側の担当者に電子メールで通知するなどである。
【００５３】
各拠点のプロジェクトリーダおよび発注の担当者は納品定義ＤＢ１４２もしくは５４２に追加・修正があったという通知を受信し（Ｓ１０２ａ、Ｓ１０２ｃ）、必要があれば追加・修正された内容を確認することができる。この場合、この追加・修正通知自体に修正内容の一部を内容として含ませておくこともできるし、追加・修正があったことのみの通知で詳細は開発支援システム１にログインし確認するという手順を踏んでも良い。各拠点側の「確認用テスト項目」が全て入力されたかを判断し（Ｓ１０３ａ）、完了していない場合はステップＳ１０１ａに戻り次のテスト項目の内容の入力を行うことになる。
【００５４】
またテスト項目の入力は本実施の形態のように１項目ずつ開発支援システム１に入力される方法でも良いし、全ての項目もしくは項目のまとまりを各拠点の端末側で行い、ある時点で開発支援システム１に入力すると方法でも良い。もしくはテスト項目自体はファイルとして作成しそのファイルを開発支援システム１に送信するという方法でも良い。全項目の入力が済んだ後に投入した「確認用テスト項目」の内容を確認する（Ｓ１０４ａ）。投入したテスト項目の内容が良くなければ再度最初に戻りステップＳ１０１ａのテスト項目の入力を行う。図１０では投入した  テスト項目の内容の確認を全ての項目の投入が済んだ後に行うようになっているが、途中でテスト項目の確認を随時行うように構成しても良い。
【００５５】
受注側の担当者がテスト項目の入力と確認を終了した時は、各拠点の開発側の端末５はテスト項目の入力および確認が完了したことを開発支援システム１に通知する（Ｓ１０５ａ）。開発支援システム１はテスト項目の入力および確認完了の情報を受信し（Ｓ１０４ｂ）、発注側のあらかじめ決められたあて先にあらかじめ決められた方法でテスト項目の入力および確認が終了したことを通知する（Ｓ１０５ｂ）。本実施の形態の場合は、例えばあらかじめ決められたあて先としては該当開発の発注担当者であり、あらかじめ決められた通知方法としては音声合成されたメッセージを発注担当者の携帯電話機に電話をかけて通知するというのでも良い。もしくは開発支援システム１で自動的に発注側に通知するのではなく、受注した開発会社の担当者が直接発注側の担当者に電話もしくは電子メールなどで通知するという方法でも良い。
【００５６】
テスト項目の入力および確認が完了したことの通知を受けた発注側の担当者は、開発支援システム１にログインし「確認用テスト項目」の内容の確認を行い、その結果として「ＯＫ」もしくは「ＮＧ」を開発支援システム１に通知し（Ｓ１０６ｃ）、開発支援システム１はその受信した（Ｓ１０６ｂ）内容を各拠点の開発会社のプロジェクトリーダなどに電子メールなどを用いて通知する（Ｓ１０７ｂ）。もしくは開発支援システム１にログインしたときに通知が確認できるように構成されても良い。本実施の形態では「ＮＧ」であった場合の業務フローについては記載していないが、上述の各拠点の開発端末からテスト項目を入力するところ（Ｓ１０１ａ）から再度開始することになる。
【００５７】
発注側の確認が「ＯＫ」の場合（Ｓ１０６ａ）、受注側の開発会社は開発に着手する。この開発は前記投入した「確認用テスト項目」に従って、要求仕様を確認しながら行う（Ｓ１０７ａ）。もしこの開発段階で仕様を修正する必要があるなどの仕様上の問題が発見された場合は、発注側の担当者に通知した上で図１０の業務フローを最初から行うことになる。また発注側端末の業務フローにテスト項目の入力（Ｓ１０１ｃ）が存在するが、受注側の開発会社と共同して納品定義である「確認用テスト項目」を作成する場合はこのように発注側でもテスト項目の入力という一連の作業を行う（Ｓ１０１ｃ〜Ｓ１０４ｃ）こともできることを示している。
【００５８】
開発の着手については、本実施の形態のようにテスト項目の入力と確認が完了していなければ行えないとしても良いし、あるまとまったテスト項目の入力と確認が行われた時点でその部分の開発を着手するという開発の手法を用いても良い。
【００５９】
次に開発が完了し総合テストを行う際には、本実施の形態では受注側の開発会社から発注側の担当者に電子メールや電話などの手段を用いて通知を行うかもしくは図１０には図示していないが、開発完了を開発支援システム１に登録することで開発支援システム１が自動的にあらかじめ決められた担当者にあらかじめ決められた方法で通知するという手順を行っても良い。この後は、開発側および発注側で前記入力した納品定義ＤＢ１４２、５４２に定義されている「確認用テスト項目」に基づいて総合テストを行い（Ｓ１０Ａａ、Ｓ１０８ｂ）、さらにフィールドテストを行う（Ｓ１０Ｂａ、Ｓ１０９ｂ）。同様に発注側でも総合テスト（Ｓ１０８ｃ、Ｓ１０８ｂ）とフィールドテストを行っても良い（Ｓ１０９ｃ、Ｓ１０９ｂ）。但しお互いに同じ試験を行うのが好ましくない環境である場合はどちらかの試験のみが行える、もしくはどちらかしか行えないというように開発支援システム１にて制限もしくはオプションを加えることも良い。また、上記納品定義ＤＢ１４２、５４２に記載されているテスト項目の検証は開発中に随時行うとしても良い。
【００６０】
テストで結果が「確認用テスト項目」に投入されている内容を満足すれば、受注側の担当者は開発物を納入し（Ｓ１０Ｂａ）、発注側の担当者は納品物に対して検収を行う。上記「総合テスト」および「フィールドテスト」の詳細な内容については後で述べる。受注開発に関する業務のフローの概略は以上説明したように行い、以下により詳細な内容を説明する。
【００６１】
次に図１１を用いて本実施の形態のおける納品定義ＤＢ１４２に「確認用テスト項目」を入力する際の動作フローについて説明する。まず開発拠点の端末５から担当者が例えばインターネットを利用してＷＥＢブラウザにて開発支援システム１のＵＲＬ（Universal Resource Locator）をアクセスする（Ｓ１１１ａ）ことで開発支援システム１にログインする。開発支援システム１はアクセスを受付け（Ｓ１１１ｂ）、ログイン画面を作成して端末５に送信する（Ｓ１１２ｂ）。
【００６２】
端末５は受信したログイン画面を表示する（Ｓ１１３ａ）。図１２に表示されるログイン画面を示す。図中１２１は例えばＷＥＢブラウザの内容表示枠内に表示される内容であり、１２２の部分に示すように、開発支援システム１にログインするためのユーザＩＤとパスワードの入力を求められる。この画面にてユーザＩＤとパスワードを入力し（Ｓ１１３ａ）、「ログイン」釦を押下すると、入力した内容が開発支援システム１に送信される。前述したようにインターネットを介してユーザＩＤおよびパスワードを送信する場合は、本実施の形態ではフロー上には詳細に記載していないが、情報の漏洩を防ぐため暗号化の通信プロトコルを用いて暗号化されている。
【００６３】
開発支援システム１はユーザＩＤおよびパスワードを受信し（Ｓ１１３ｂ）、ユーザＩＤおよびパスワードが正しいかを判断する（Ｓ１１４ａ）。ユーザＩＤもしくはパスワードが合致していなければエラー画面を作成して端末５に送信し（Ｓ１１５ｂ）、処理を終了する。エラー画面を受信した（Ｓ１１３ａ）端末５は、受信したエラー画面を表示（Ｓ１１４ａ）し、処理を終了する。
【００６４】
ユーザＩＤとパスワードが合致した場合は、そのログインしてきたユーザが所属する開発会社を特定してその開発拠点に合った納品定義ＤＢ１４２内の「確認用テスト項目を編集できる画面を作成して端末５に送信する（Ｓ１１６ｂ）。納品定義内容の表示画面を受信した端末５は、受信した表示画面を表示する（Ｓ１１５ａ）。
【００６５】
次に開発側の端末５の操作者であるプロジェクトリーダなどが納品定義の内容として「確認用テスト項目」に記入すると、その記入した情報が通信ネットワークを介して開発支援システム１へ送信される（Ｓ１１７ａ）。全てのテスト項目の入力が終了するまで（Ｓ１１８ａ）「確認テスト項目」の記入を継続する。開発支援システム１は受信した「確認用テスト項目」の内容を反映し（Ｓ１１８ｂ）、再度入力を反映した新たな画面を作成して端末５に送信する（Ｓ１１６ａ）。上記動作を「確認用テスト項目」の入力が終了するまで行う。
【００６６】
納品定義内容の入力が終了した場合、端末５は終了したことを開発支援システム１に通知する（Ｓ１１９ａ）。入力終了の通知を受けた（Ｓ１１９ｂ）開発支援システム１は、納品定義が修正されたことをあらかじめ決められたあて先にあらかじめ決められた方法で通知する。納品定義が追加・修正になった場合には、図２０に示すように各々の納品定義ＩＤについて通知するあて先とそのあて先それぞれについて通知先の氏名、所属する会社名、電話番号ＦＡＸ番号、電子メールアドレスおよび通知の際に所望する通知方法などが登録されている「納品定義修正時に通知するあて先一覧」を参照して通知を行う。
【００６７】
次に図１３を用いて自動検証手段１３４と検証支援手段５３３とがお互いに通信して検証を行う動作について説明する。図１３においては検証支援手段５３３はその出力を自動検証手段１３４に通知するという構成になっている。まず自動検証手段１３４は図５に示す内容の納品定義ＤＢ１４２から該当する検証支援手段５３３の入力情報を入手する（Ｓ１３１ｂ）し、入力情報を対応する拠点に送信する（Ｓ１３２ｂ）。各拠点の検証支援手段５３３は通信ネットワーク４を介して送受信部５２、送受信処理手段５３１を経由して入力情報を受信し（Ｓ１３１ａ）、その入力情報をパラメータとして開発物を起動する（Ｓ１３２ａ）。
【００６８】
開発物が起動した後に出力する出力情報を受信し、検証支援手段５３３はその出力内容を自動検証手段１３４に送信する（Ｓ１３３ａ）。出力情報を受信した（Ｓ１３３ｂ）自動検証手段１３４は、テスト結果を図７および図８に示す開発モジュール単位のテストの「期待される出力情報」と比較判定し「検証結果」の欄に合格の場合は「ＯＫ」（Ｓ１３６ｂ）、不合格の場合は「ＮＧ」（Ｓ１３７ｂ）などと書き込む。この作業を予定している全試験が終了するまで継続する（Ｓ１３８ｂ）。
【００６９】
上述したように図１３に示すテスト項目の検証のフローは自動検証手段１３４が各テスト項目の出力情報を取得し次の検証を行うという構成である。よって図１４に示すように開発を複数の開発会社Ａ、Ｂ、Ｃに発注し、各拠点に存在する開発会社が作成した開発物が互いに関連があり、ある開発会社の開発物の出力情報が他の開発会社の開発物のテスト項目の入力情報になっている場合は、図１３で説明した動作は図１４に示すフローのように行われ、上記互いに関連のある開発物の一連のテスト項目を行うことができる。
【００７０】
この場合、発注者は、開発支援システム１の入力部１５を使用するか、ＷＥＢブラウザを用いてインターネット上に存在する端末を用いてを検証を開始する。まず納品定義ＤＢ１４２より「確認用テスト項目」からテストに関する最初の入力情報を入手し、最初の開発物を有する開発会社Ａ宛に入力情報を送信する（Ｓ１４１ａ）。入力情報を受信した開発会社Ａの検証支援手段５３３は受信した（Ｓ１４１ｂ）入力情報をパラメータとして開発物を起動する（Ｓ１４２ｂ）。
【００７１】
開発会社Ａの検証支援手段５３３は開発物からの出力情報を受信し（Ｓ１４３ｂ）、その出力情報を発注者が起動している自動検証手段１３４に送信する（Ｓ１４４ｂ）。出力情報を受信した自動検証手段１３４は、納品定義ＤＢに記載されている「確認用テスト項目」を参照し次の開発物を抽出し、開発会社Ａから受信した出力情報を開発会社Ｂに送信する（Ｓ１４３ａ）。さらに入力情報を受信した開発会社Ｂの検証支援手段５３３は開発会社Ａと同様に受信した入力情報をパラメータとして開発物を起動し（Ｓ１４２ｃ）、開発物からの出力情報を受信し（Ｓ１４３ｃ）、その出力情報を自動検証手段１３４に送信する（Ｓ１４４ｃ）。
【００７２】
次に自動検証手段１３４は同様に納品定義ＤＢ１４２を参照し次のテストを行う先が開発会社Ｃの開発物であることを知り、開発会社Ｂの開発物からの出力情報を開発会社Ｃに送信する。開発会社Ｃの検証支援手段５３３は、図１４の開発会社Ｂの検証支援手段５３３が行った処理を同様に行い（Ｓ１４２ｄ〜Ｓ１４４ｄ）、さらに自動検証手段１３４は開発会社Ｂに対して同様にテストを行う（Ｓ１４７ａ、Ｓ１４５ｃ〜Ｓ１４８ｃ）。
【００７３】
図１４では、一連のテストはこれで終了し発注者側の自動検証手段１３４は途中で受信した出力情報および最終的に受信した出力情報をもって納品定義ＤＢ１４２を参照することで一連のテストの結果を得ることができる。上記一連のテストは図７に示す検証順序ＤＢ１４３に定義された順に行われ、結果の判断もこの検証順序ＤＢ１４３の「期待する出力情報」を出力結果と比較検討することでテスト結果が得られることになる。
【００７４】
次に開発側拠点の検証支援手段５３３が、自分の開発物の出力情報を入力情報として必要としている開発物に対して自動検証手段１３４を経由せずに直接出力情報を入力情報として送信するという検証の形式について図１５および図１６を用いて述べる。図１４と同様にまず自動検証手段１３４は納品定義ＤＢ１４２に記載されている「確認用テスト項目」を参照して拠点対応の入力情報を入手（Ｓ１５１ｂ）、入手した入力情報を対応する開発拠点に送信する（Ｓ１５２ｂ）。この時、該当する開発拠点の図４に示す開発会社ＤＢ１４１よりドメイン名もしくは固定のグローバルＩＰアドレスを入手し情報を送信するものである。
【００７５】
入力情報を受信した（Ｓ１５１ａ）開発拠点の検証支援手段５３３は、受信した入力情報をパラメータとして開発物を起動し（Ｓ１５２ａ）、結果として出力情報を得る（Ｓ１５４ａ）。得た出力情報と図７および図８に記載している納品定義ＤＢ１４２内の「期待される出力情報」と比較検討しその結果を合格の場合は「ＯＫ」（Ｓ１５７ａ）、不合格の場合は「ＮＧ」と記載する（Ｓ１５８ａ）。次に納品定義ＤＢ１４２を参照して次の開発物を抽出し出力情報を次の拠点に送信する（Ｓ１５９ａ）。図１５中最左端のフロー図は一連のテストが終了し最後に結果を自動検証手段１３４に送信している（Ｓ１５９ａ）の部分が中心の開発拠点の検証支援手段５３３のフロー図と異なる点である。
【００７６】
図１５の動作フロー図に基づき図１６の一連のテストのシーケンス図の概略動作を説明する。図１６のテストシーケンス図は開発拠点の検証支援手段５３３が、テストが行われた際の開発物からの出力情報を次の開発物の入力情報として直接次の拠点に送信しているところが図１４と異なる点である。まず自動検証手段１３４は納品定義ＤＢ１４２を参照して入力情報を入手し（Ｓ１６１ａ）、最初のテストを行う開発会社Ａの開発物をテストするために入手した入力情報を開発会社Ａに送信する（Ｓ１６１ａ）。
【００７７】
送信された入力情報は、通信ネットワーク４を介して、さらに送受信部５２、送受信処理手段５３１を経て開発会社Ａの検証支援手段５３３が受信する（Ｓ１６１ｂ）。開発会社Ａの検証支援手段５３３は受信した入力情報をパラメータとして開発物を起動する（Ｓ１６２ｂ）。開発物内でテストが完了し出力情報を受信した（Ｓ１６３ｂ）検証支援手段５３３は、自分が有する納品定義ＤＢ５４２を参照して次に起動させるべき開発物とその開発物を開発している開発拠点を抽出し、出力情報を入力情報として次のテスト対象の開発物を開発している拠点である開発会社Ｂに送信する（Ｓ１６４ｂ）。
【００７８】
その後は次のテスト対象の開発物を有する開発会社Ｂでも同様に入力情報を受信し（Ｓ１６１ｃ）、その入力情報をパラメータとして開発物を起動し（Ｓ１６２ｃ）、開発物からの出力情報を取得し（Ｓ１６３ｃ）、自分が所有する納品定義ＤＢ５４２を参照して次のテスト対象の開発物とその開発物の開発担当である開発会社を特定し、取得した出力情報を入力情報として次の開発拠点に送信する（Ｓ１６４ｃ）。その後の図１６における動作フローである開発会社Ｃでのステップ１６１ｄ〜１６４ｄまで、さらに開発会社ＢのステップＳ１６５ｃ〜１６８ｃまでは前述と同様の動作を行う。
【００７９】
但し、開発会社Ｂのステップ１６８ｃは、自分が所有する納品定義ＤＢ５４２を参照するが、次の拠点が無いことを判断し検証の元である自動検証手段１３４を備えた開発支援システム１に出力情報を送信する（Ｓ１６８ｃ）。自動検証手段１３４は出力情報を受信し（Ｓ１６２ａ）、納品定義ＤＢ１４２を参照して一連の開発物の判定を行う（Ｓ１６３ａ）。上記一連の動作において、各開発会社でのテスト項目の検証の結果は各検証支援手段５３３が図７のテスト対象の開発モジュール単位に設けられている「検証結果」に記入し、全体のテスト項目の検証の結果は自動検証手段１３４がテスト全体の結果に記入する。
【００８０】
各開発拠点の検証結果は各開発拠点内の納品定義ＤＢ５４２に記載されるが、この納品定義ＤＢ５４２は例えば一連のテストが終了時に開発支援システム１内の納品定義ＤＢ１４２に通知され内容の更新が行われる。
【００８１】
次に検証終了後にレポートを作成し通知する機能について図１７を用いて説明する。図１７は、「確認用テスト項目」の検証が終了したときには、例えば周期的にもしくは検証終了のタイミングでレポートを作成し、あらかじめ決められたあて先にあらかじめ決められた方法で通知する機能を説明する動作フロー図である。まず、レポート作成手段１３７は、納品定義ＤＢ１４２に従って「確認用テスト項目」の検証を行うことを自動検証手段１３４に指示する（Ｓ１７１）。このテストについては前述した通りである。図７および図８に記入されている入力情報、出力情報、期待される出力情報、検証結果などの一覧を例えば開発モジュール単位で全てのテスト項目の処理が終了するまでレポート形式に出力する（Ｓ１７３、Ｓ１７４）。作成した全テスト項目分のテスト結果のレポートをあらかじめ決められた全てのあて先にあらかじめ決められた方法で通知する（Ｓ１７４、Ｓ１７５）。レポートとして図２１に例を示す。
【００８２】
開発物の完成度は、図２３ないし図２５に示しているように各テスト項目が複数の確認項目を有する場合は、合格した割合などをあらかじめ決められた合格判定基準に照会してテスト項目として合格したかどうかを判定する。よって納品定義項目の内容はあらかじめ発注者と受注者間で内容を確認した上で決定しているので正確な完成度合いが分かる。同様に時間的な性能を確認するテストにおいてもその開発物および一連の開発物の完成度を判定することができる。
本発明による第１の実施の形態は以上のように構成され動作する。
【００８３】
本実施の形態によれば、開発の前段階で開発の要求仕様となる部分の「確認用テスト項目」を納品定義ＤＢ１４２内に作成し発注者および受注者間で承認し、開発に際しては前記納品定義ＤＢ１４２内の「確認用テスト項目」を参照しながら開発を行えるので仕様の間違いが少なく、意思の疎通が図れた開発が可能となる、さらに開発終了時にも前記「確認用テスト項目」を用いて自動的に試験が可能であるので、工数の削減が図れる。
【００８４】
次に本発明の第２の実施の形態について図２２を用いて説明する。第２の実施の形態は、第１の実施の形態に加えて、テストを行う際に入力情報と、入力情報をパラメータとして開発物を起動する際の時刻を記録し、開発物からの出力情報を受ける際に時刻を記録して、各開発物の時間的な性能および、全システムの時間的な性能を計測するシステムである。以下、図２２を用いて説明する。図２２は基本的に図１４と比較してステップ１４３ｘ、１４３ｙ、１４３ｚ、１４７ｙの部分のみが異なる。上記ステップでは図１４に加えて開発物を起動する際の時刻と、開発物から出力情報を受けた時の時刻を取得し出力情報として自動検証システム１４２に送信する。
本発明による第２の実施の形態は以上のように構成され動作する。
【００８５】
本実施の形態によれば、一連の「確認用テスト項目」をテストする際に個々の開発モジュールの時間的な性能を同時に検証することができ、システム全体としての時間的な性能も計測することができる。
【００８６】
なお、第２の実施の形態では、一連の開発モジュールのテストにおいて、出力結果を開発支援システム１の自動検証手段１３４に送信しているが、図１６で説明したように個々の開発会社の検証支援手段５３３は、開発物から取得した出力情報を次の開発物の入力情報として直接送信することも可能である。
【産業上の利用可能性】
【００８７】
ソフトウェア開発を行う産業において利用可能である。
【図面の簡単な説明】
【００８８】
【図１】本発明の第１の実施の形態に関わる、制御局および拠点端末を含む開発支援システムの機能ブロック図である。
【図２】図１のデータベースの関連図である。
【図３】図１の開発支援システムの業務フロー図である。
【図４】図１の開発会社ＤＢである。
【図５】図１の納品定義ＤＢである。
【図６】図１の納品定義ＤＢの詳細な内容である。
【図７】図１の検証順序ＤＢである。
【図８】図１の性能試験ＤＢである。
【図９】図１の開発関連ＤＢである。
【図１０】図１の概要通信シーケンス図である。
【図１１】図１の納品定義を入力するシーケンス図である。
【図１２】図１の開発支援システムにログインする際に表示される画面である。
【図１３】図１の自動検証手段がテストを複数の拠点に対して行う際のフロー図である。
【図１４】図１の自動検証手段がテストを複数の拠点に対して行う際の通信シーケンスである。
【図１５】図１の検証支援手段が直接次の拠点の検証支援手段に制御を渡す際のフロー図である。
【図１６】図１の検証支援手段が直接次の拠点の検証支援手段に制御を渡す際の通信シーケンスである。
【図１７】図１の開発支援システムが検証が終了した際にレポートを作成し出力する際のフロー図である。
【図１８】従来の受注開発管理を示す表である。
【図１９】第１の実施の形態での受注開発管理を示す表である。
【図２０】第１の実施の形態の納品定義修正時に通知するあて先一覧である。
【図２１】第１の実施の形態のテスト結果レポートの例である。
【図２２】第２の実施の形態における動作フロー図である。
【図２３】第１および第２の実施の形態における完成度の測定基準を示す図である。
【図２４】第１および第２の実施の形態における時間的性能に関する完成度の測定基準を示す図である。
【図２５】第１および第２の実施の形態におおける一連のテストの完成度の測定基準を示す図である。
【符号の説明】
【００８９】
１  開発支援システム
４  通信ネットワーク
５  拠点端末
１２、５２  送受信部
１３、５３  中央演算処理部
１４、５４  記憶部
１５、５５  入力部
１６、５６  表示部
１３１、５３１  送受信処理手段
１３２、５３２  入出力処理手段
１３３  データ入出力手段
１３４  自動検証手段
５３３  検証支援手段
１３５、５３４  検証順序制御手段
１３６  納品定義項目修正通知手段
１３７  レポート作成手段
１４１  開発会社ＤＢ
１４２、５４２  納品定義ＤＢ
１４３、５４３  検証順序ＤＢ
１４４  性能試験ＤＢ
１４５  開発関連ＤＢ
【図１】
0004744220.tif 000002
【図２】
0004744220.tif 000003
【図３】
0004744220.tif 000004
【図４】
0004744220.tif 000005
【図５】
0004744220.tif 000006
【図６】
0004744220.tif 000007
【図７】
0004744220.tif 000008
【図８】
0004744220.tif 000009
【図９】
0004744220.tif 000010
【図１０】
0004744220.tif 000011
【図１１】
0004744220.tif 000012
【図１２】
0004744220.tif 000013
【図１３】
0004744220.tif 000014
【図１４】
0004744220.tif 000015
【図１５】
0004744220.tif 000016
【図１６】
0004744220.tif 000017
【図１７】
0004744220.tif 000018
【図１８】
0004744220.tif 000019
【図１９】
0004744220.tif 000020
【図２０】
0004744220.tif 000021
【図２１】
0004744220.tif 000022
【図２２】
0004744220.tif 000023
【図２３】
0004744220.tif 000024
【図２４】
0004744220.tif 000025
【図２５】
0004744220.tif 000026