JP4744220B2 - 開発支援システム、および開発支援プログラム。 - Google Patents

開発支援システム、および開発支援プログラム。 Download PDF

Info

Publication number
JP4744220B2
JP4744220B2 JP2005218739A JP2005218739A JP4744220B2 JP 4744220 B2 JP4744220 B2 JP 4744220B2 JP 2005218739 A JP2005218739 A JP 2005218739A JP 2005218739 A JP2005218739 A JP 2005218739A JP 4744220 B2 JP4744220 B2 JP 4744220B2
Authority
JP
Japan
Prior art keywords
development
test
verification
information
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005218739A
Other languages
English (en)
Other versions
JP2007034796A (ja
Inventor
政信 山香
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chugoku Electric Power Co Inc
Original Assignee
Chugoku Electric Power Co Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Chugoku Electric Power Co Inc filed Critical Chugoku Electric Power Co Inc
Priority to JP2005218739A priority Critical patent/JP4744220B2/ja
Publication of JP2007034796A publication Critical patent/JP2007034796A/ja
Application granted granted Critical
Publication of JP4744220B2 publication Critical patent/JP4744220B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/30Computing systems specially adapted for manufacturing

Landscapes

  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、1つのシステムのソフトウェアの開発を外部の開発会社に委託する場合において、開発の過程もしくは納品時に要求仕様の満足度または完成度をチェックするシステム、方法もしくはプログラムに関し、特に開発を1つまたは複数の開発会社に委託した場合において、開発の過程および納品時に委託した開発会社の開発成果物の要求仕様の満足度をチェックし、発注した開発物の完成度を判定することで開発支援を行う開発支援システム、および開発支援プログラムに関する。
従来、ソフトウェアの開発手法としては、ウォーターフォール型開発モデル、プロトタイプ型開発モデル、スパイラル型開発モデル、プロセス型開発モデルなどが存在している。どの開発モデルを用いて開発を行ったとしても要求仕様の内容が正しく実現されているかということが開発物の納入の際に重要なポイントである。ソフトウェア開発の受託会社が発注者の要求仕様を間違って理解して開発を行った場合は、開発に手戻りが発生してしまう。
要求仕様書が明確に定義されていない場合は、納品物を検収する際にも正確な検収ができないため、検収した後に実際に納品物を動作させてから要求仕様を満足していないことが判明することが頻繁に発生する。特許文献1は、ソフトウェア開発に際し、ソフトウェア仕様確認サーバを用意し、プロトタイピングで仕様確認を行いながら要求仕様を明確にしてソフトウェアを完成させるという方式を提案している。図18は従来のウォーターフロー型開発モデルの開発工程表を示している。
特許文献2は、ソフトウェア開発プロジェクトの管理者と開発者がその開発の進捗状況を自動管理する手法を提案している。特許文献3は、ソフトウェア開発プロジェクトの発足に際して、事前に要求仕様を定義しその要求仕様書に関して定量的および定性的に判断できる項目をファイルとしてあらかじめ作成しておき、該ファイルに基づきプロジェクトの進捗状況を管理するという手法を提案している。特許文献4は、ソフトウェア開発の進捗管理と、開発担当者の業務の負荷分散・状況把握を行う手法を提案している。
特開平10−320186号公報 特開2002−366674号公報 特開平08−234977号公報 特開2004−94827号公報
ところが、上記従来の方法で発注者と受注者が互いに納得できるソフトウェア開発の管理を行うための手法は確立していない。特許文献1で提案されているプロトタイプ型開発モデルを用いたソフトウェア仕様確認サーバでは、発注者および受注者で要求仕様をまとめながら開発を進めていくため仕様自体はお互いに認識されたものにはなるが、開発物の納品の際に開発物の仕様が要求仕様を満足しているかを判断できるものではない。
納品の際には、受注者が作成した試験結果報告書を発注者が確認するしかなく、例えば有る程度自動的に開発物の完成度を納品前の検証試験時などに確認する方法を提供していない。よって納品される開発成果物には要求仕様と異なる不具合を内在している可能性は皆無とは言えずフィールドテストもしくはお客様へ開発物によるサービスなどを提供する際に不具合が発見される可能性が無いと言えないことは明らかである。
特許文献3も同様に事前に要求仕様を定義しその要求仕様書に関して定量的および定性的に判断できる項目をファイルとしてあらかじめ作成しておき、該ファイルに基づきプロジェクトの進捗状況を管理するという手法のみでは、開発成果物の納品時に、納品物が要求仕様と異なる不具合を内在してうるかどうかは発注者は分からない。よって検収に時間を要して開発物の完成度を前記ファイルと比較して検証を行うという作業が必要となる。
本発明はかかる従来の問題に鑑みてなされたものであり、ソフトウェア開発を1つもしくは複数の開発会社に発注するに際して、開発過程での開発物の仕様確認を行うことができ、さらに納品に際しての開発成果物の要求仕様に対する完成度の確認を行えるような指標を事前に発注者および受注者が共同して作成し、前記指標に従って自動的に開発物の検証を行うことで開発物の仕様の完成度を判定できる開発支援システム、および開発支援プログラムを提供することを目的とする。
上記目的を達成するため、本発明に関わる開発支援システムは、開発物に対する入力情報とその入力に対応する開発物からの出力情報から構成される納品定義項目を設け、通信ネットワークを経由した外部からの要求に応じて入力情報を受信し、前記入力情報をパラメータとして開発物を起動し、開発物からの出力情報を受信し、前記出力情報を通信ネットワークを介して外部に送信する検証支援手段と、前記検証支援手段に通信ネットワークを介して入力情報を送信し、前記検証支援手段からの出力情報を受信し、前記入力情報と前記出力情報により前記納品定義項目を参照し開発物の完成度を判定する自動検証手段とを備えたことを特徴とする。
さらに好ましくは、自動検証手段および検証支援手段は、開発物全体または個々の開発物の単位で検証を行うように構成するのも良い。また、複数の拠点に複数の検証支援手段が存在し、自動検証手段は前記複数の拠点の検証支援手段に入力情報を送信し、自動検証手段は、複数の検証支援手段より受信する複数の出力情報により前記納品定義項目を参照し開発物の完成度を判定するように構成するのも好ましい。
本発明では、納品定義項目を記載した例えば納品定義書に従って開発を行い、開発の過程もしくは納品時に納品定義書に基づいて開発物全体および個々の開発物の検証を外部の自動検証手段から開発の受注者の検証支援手段に指示することで検証を行うシステムを提供する。これにより開発に際して個々の開発および開発全体の要求仕様の定義を納品定義項目から判断することが可能となり、思い込みの開発などを行う危険性を防ぐことができる。さらに納品以前に個々の開発物および開発全体の検証が可能となる。また複数の拠点での開発を行うことも可能となり、複数の拠点で行った開発物の検証も納品前および納品時に遠隔から行うことができる。
さらに、複数の拠点に存在する検証支援手段において各々の拠点の開発物の出力情報が他の拠点の入力情報になる場合に、自動検証手段は、各々の拠点の検証支援手段に対してあらかじめ決められた順序に従って入力情報を送信し、該拠点の検証支援手段からの出力情報を受信してさらに次の拠点の入力情報として送信し、最後の拠点の検証支援手段からの出力情報または全拠点の出力情報により前記納品定義項目を参照し各拠点の開発物の完成度を判定するように構成するのも良い。
さらに、複数の拠点に存在する検証支援手段において各々の拠点の開発物の出力情報が他の拠点の入力情報になる場合に、各拠点の検証支援手段は、出力情報を次の入力として必要としている次の拠点に入力情報として送信し、最後の拠点は出力情報を自動検証手段に送信し、自動検証手段は、受信した出力情報により納品定義項目を参照し、一連の開発物の完成度を判定するように構成するのも好ましい。
本発明により、1つの開発において関連した開発を複数の拠点で行う場合に、一拠点の結果を元に次の拠点の検証が行える。この連続した拠点の一連の検証は、自動検証手段が各々の拠点の開発物の検証の結果を各々の拠点の検証支援手段が受信し、さらに自動検証手段に送信する一連の作業を通して行う。また、検証支援手段が次の拠点に直接入力情報を送信することで一連の開発物の検証を連続して行うことが可能となる。
さらに本発明に関わる開発支援システムは、開発物に対する入力情報および入力時刻とその入力に対応する開発物からの出力情報および出力時刻から構成される納品定義項目を設け、通信ネットワークを経由した外部からの要求に応じて入力情報を受信し、前記入力情報をパラメータとして開発物を起動する際にその時刻を記憶し、開発物からの出力情報を受信したときにその時刻を記憶し、さらに前記記憶した入力した時の時刻および出力を受信したときの時刻を通信ネットワークを介して外部に送信する検証支援手段と、前記検証支援手段に通信ネットワークを介して入力情報を送信し、前記検証支援手段から受信する前記入力情報を受信したときの時刻と、開発物から出力情報を受信したときの時刻および該出力情報に基づき前記納品定義項目を参照し開発物の完成度を判定する自動検証手段とを備えたことを特徴とする。
本発明により、各開発物の検証を通信ネットワークを介して外部から検証を行う拠点に入力情報を送信し、該拠点の検証支援手段が検証対象の開発物を起動する際にその時刻を取得し、且つ開発物からの出力情報を受信した時にその時刻を取得し開発物の時間的性能を測定することで開発物の完成度を測ることができる。
さらに好ましくは、自動検証手段および検証支援手段は、開発物全体もしくは個々の開発物単位で開発物の検証を行うように構成するのも良い。また、複数の拠点に複数の検証支援手段が存在し、自動検証手段は前記複数の拠点の検証支援手段に入力情報を送信し、複数の検証支援手段より受信する前記入力したときの時刻と前記出力情報を受けたときの時刻を含む複数の出力情報により納品定義項目を参照し開発物の完成度を判定するように構成するのも好ましい。
さらに、複数の拠点に存在する検証支援手段に対し、各々の拠点の開発物の出力情報が他の拠点の入力情報になる場合に、各々の拠点の検証支援手段に対してあらかじめ決められた順序に従って入力情報を送信し、その拠点の検証支援手段からの出力情報を受信してさらに次の拠点の入力情報として送信し、全拠点の入力した時刻と出力を受信したときの時刻を含む出力情報により前記納品定義項目を参照し各拠点の開発物の完成度を判定するように構成するのも好ましい。また、複数の拠点内に前記拠点での開発に関する納品定義項目を有し、該拠点内の検証支援手段は、前記納品定義項目に基づいて入力情報をパラメータとして開発物を起動し、開発物からの出力情報を基に前記納品定義項目を参照して開発物の完成度を判定するのも好ましい。
本発明により、個々の開発物および全開発物の検証を通信ネットワークを介して行うことができ、開発が複数の拠点にまたがっている時においても複数拠点の検証支援手段が測定した開発物の時間的性能を計測することができ開発物の時間的性能の完成度を判定することができる。さらに1つの拠点の出力が次の拠点の入力になる場合に、一連の拠点で行われる開発物の検証の際の時間計測をそれぞれ入手し、一連の開発全体の時間的計測を基に時間的性能を判定することができる。
さらに、開発を複数の部分に分割し、それぞれの開発を複数の拠点の開発会社に委託する場合において、発注側が管理するサーバに委託を行う開発それぞれについての納品定義項目を設け、各開発会社は前記サーバで管理されている納品定義項目に対して、自己の開発に関する納品定義内容にのみ遠隔で書き込みが許可され、拠点内部で検証を行う際には前記サーバから該拠点に関連する納品定義項目をダウンロードし、検証支援手段はダウンロードした納品定義項目を基に検証を行うように構成するのも良い。
加えて前記サーバ上に存在する各拠点に関する納品定義項目への検証内容を該当する拠点の構成員が遠隔で書き込み可能とし、納品定義項目に新たな書き込みが有った際に、あらかじめ登録されている電子メールアドレスに新たな記載が有ったことを通知する納品定義項目修正通知手段を有することも好ましい。
また、複数の検証項目が納品定義項目に定義されていた場合に、検証の結果を前記納品定義項目を基に参照するに際して、全ての検証項目ごとに検証の結果をレポートとして出力し、あらかじめ決められたメールアドレスにメール送信するのも好ましい。さらに、通信ネットワークとしてインターネットを利用することも好ましい。さらに好ましくは、開発物の完成度は、前記納品定義項目に定義された1つのテスト項目に複数の確認項目がある場合は、確認項目ごとに設定された合格判定基準にしたがって判定された全確認項目の合格率が合格基準を超えている場合に合格と決定するのも良い。
本発明により、通信ネットワークを介して通信可能なサーバ上に要求仕様である納品定義項目を登録した場合に、該納品項目の内容を発注者および受注者で相互に決定するに際し、複数の拠点に存在する開発会社の担当者が自分が担当する分の納品項目定義を遠隔で読み書きできるが、他の開発会社の納品定義項目の内容を修正することはできないようにすることができるので、セキュリティを確保した上で納品定義に関して共同作業ができる。
また、検証結果をレポートとして自動的にメールで送信することができるため検証の確認も早く行うことができる。また、テスト項目の確認項目ごと設定された合否判定基準参照して合格となった項目数の合計値の割合を判定することで発注者および受注者が確認した判定基準を満足するかどうかを自動的に判定することができる。
上記目的を達成するため、本発明に関わる開発支援プログラムは、開発ソフトウェアの仕様確認を外部から行うサーバ上で動作するプログラムであって、通信ネットワークを経由した外部からの要求に応じて入力情報を受信し、前記入力情報をパラメータとして開発物を起動し、開発物からの出力情報を通信ネットワークを介して外部に送信する第1の処理と、前記第1の処理に通信ネットワークを介して入力情報を送信し、前記第1の処理からの出力情報を受信し、前記入力情報と前記出力情報により前記納品定義項目を参照し開発物の完成度を判定する第2の処理と、をサーバ上で実行させることを特徴とする。
さらに前記第2の処理は、複数の開発拠点に存在する前記第1の処理に入力情報を送信し、前記複数拠点の第1の処理が送信する複数の出力情報を受信し、前記送信した複数の入力情報と、前記受信した複数の出力情報により前記納品定義項目を参照して開発物の完成度を判定するのも好ましい。
さらに好ましくは、前記第1の処理の出力情報が次の拠点の入力情報となる場合に、前記第2の処理は、あらかじめ決められた順序に従って順序正しく次の前記第1の処理に入力情報を送信し、該当の拠点の前記第1の処理からの出力情報をさらに次の拠点の前記第1の処理の入力情報として送信し、最後の拠点からの出力情報もしくは全拠点からの出力情報により前記納品定義項目を参照して各拠点の開発物の完成度および一連の開発物の完成度を判定するように構成する。
また、前記第1の処理の出力情報が次の拠点の入力情報となる場合に、前記第2の処理は、あらかじめ決められた順序に従って第1番目の前記第1の処理に入力情報を送信し、該拠点の前記第1の処理は出力情報を次の拠点の前記第1の処理に入力情報として送信し、最後の拠点からの出力情報に基づいて前記納品定義項目を参照して各拠点の開発物の完成度および一連緒開発物の完成度を判定するように構成するのも好ましい。
以上説明したように本発明によれば、ソフトウェア開発の発注者および受注者の双方が開発成果物の完成度合いを正確に判断することができる。発注側として納品物の評価内容を納品以前に特定しているため、開発に際し発注側と受注側の開発物の仕様の勘違いなどを防止することが可能である。また開発の過程や納品時に開発物の検証を自動的に行うことができ、発注者および受注者双方にとって仕様の確認が容易であり且つ要求仕様の準拠の度合いを容易に判断することができる。
また、開発を複数の開発会社に発注した場合は、一つの開発会社の開発物の出力結果を他の開発会社の開発物の入力へとすることができるので、各々の開発会社の開発物の検証を実態に合った環境で且つ早い段階で行うことが可能となる。よって今まではフィールドテストで発見されていたような不具合を早めに発見することができることとなり、今まで遅い段階で発生していた手戻り不具合の発生を防止することができ、満足度の高いソフトウェアの開発を提供することができる。
さらに外部に開かれた例えばインターネット環境を利用することを可能としているため、開発の発注者と受注者が地理的に離れた場所に拠点を構えている場合においても、環境に依存せずに開発の発注および受注が可能であり、開発物の要求仕様に対する満足度をインターネット経由で判定することが可能である。よって、開発物の管理も容易となり、各々の関連ある開発物の検証を各々の拠点で行うことができ、工数の削減にもつながる。
以下、本発明を実施するための最良の形態について説明する。図1は本発明の第1の実施の形態に関わる開発支援システムおよび受注会社の端末の機能ブロック図である。図1において開発を請け負う受注会社の端末5は、通信ネットワーク4を介しては開発支援システム1とつながっている。ここで通信ネットワーク4は例えば従来の専用線を用いた専用のネットワークもしくは、ADSL(Asymmetric Digital Subscriber Line)、FTTH(Fiber To The Home)、CATV(Cable TV)などの回線を利用したインターネット網などである。
さらにインターネット網の場合などはセキュリティの問題および外部からの攻撃に備えるため、図2に示すようにF/W(Firewall)が備わっていたりする。またインターネットを利用する場合は、通信を平文でおこなうと内容が漏れてしまうため、IPSec(Security Architecture for Internet Protocol)やPPTP(Point-to-Point Tunneling Protocol)などを用いてVPN(Virtual Private Network)を構築していたり、通信に際してSSL(Secure Socket Layer)など暗号化を用いるなどの対策が施されている。このようにこれから説明する端末5と開発支援システム1間は通信ネットワーク4としてインターネット回線を利用する場合は暗号化されて通信が行われる場合がある。
開発支援システム1は図1の機能ブロック図に示すように、発明を実現するために、各種のデータもしくはデータベースを長期的または一時的に保存する記憶部14、機能を実現するために前記記憶部14に保存されている情報を利用したり、情報を一時的に記憶部14に保存したり、通信ネットワーク4からの情報などに基づいて各種演算を行う中演算処理部13、開発支援システム1とインタラクティブに相互作用するヒューマンインタフェース機能を有する入力部15および表示部16、さらに外部の端末5と通信ネットワーク4を介して情報の送受信を行う送受信部12から構成されている。
中央演算処理部13はさらに、以下に述べる手段(機能)を備えている。送受信処理手段(機能)131は、外部からの情報の送受信を送受信部12と通信することで行う機能を有し、例えばTCP/IPなどの通信プロトコルの終端を行う機能を有する。入出力処理手段(機能)132は、入力部15からの入力と、中央演算処理部13からの出力を処理する機能を有しする。データ入出力手段(機能)133は、入力部15からもしくは外部の端末5の入力部55から通信ネットワーク4を介して入力される情報と、中央演算処理部13からの情報を出力部16もしくは通信ネットワーク4を介して外部の端末5に送信する機能を有する。
自動検証手段(機能)134は、記憶部14に保存される納品定義データベース(DB)142、検証順序データベース(DB)143、性能試験データベース(DB)144および開発関連データベース(DB)145に記憶されているデータに基づいて外部に存在する開発を請け負う受注会社の開発拠点に存在する検証支援手段(機能)533に登録されているテストを行わせる機能を有する。検証順序制御手段(機能)135は、あらかじめ決められている例えば図7に示すような検証順序に従って順序良く検証を行わせる機能を有する。
納品定義項目修正通知手段(機能)136は、開発支援システム1内に存在する納品定義データベース(DB)142もしくは受注会社の端末5内に存在する納品定義データベース(DB)542に新たな納品定義が追加されたり、修正されたりしたときに自動的にあらかじめ決められた携帯端末を含む電子メール、電話などの通信手段を用いて通知する機能を有する。
記憶部14はさらに、以下に述べるデータベースもしくはデータを保存する。開発会社データベース(DB)141は、図に示す会社ID、会社名、住所、電話番号、会社の電子メールアドレスおよび該会社が属しているドメイン名もしくは開発で使用する端末5のIPアドレスなどから構成される受注会社の会社情報を保存する。納品定義データベース(DB)142は、図5に示すように各開発のIDごとに、該発注に関する開発ID、該開発が内在する複数の納品定義書全体を示す大納品定義IDおよび進捗情報を有している。

大納品定義IDは、さらに1つの開発に関してテストで確認すべき要求仕様が登録される納品定義IDに分かれ、さらに各々の納品定義IDは該当する部分の開発を発注する開発会社の会社IDと詳細な納品定義内容を備えている。図6は、詳細な納品定義内容の例を示している。納品定義に含まれる項目は図6に示すように例えば項目番号、項目の概略を説明する項目概略、要求仕様に合致しているかを確認するための情報としての確認内容(入力情報の場合もある)、満足度を図るための確認事項(期待する出力情報である場合もある)および、項目の開発工程、入出力系や性能などの分野を表す属性、受注者および発注者が確認した日などの欄が設けられている。
検証順序データベース(DB)143は、1つのテスト項目を確認するのに動作する全ての個々の開発を順に記載しており、テストに際してはその記載順にテストを行うことで自動的に最終的なテスト結果が得られるように構成されるデータベースである。検証順序DB143の内容は図7に示すように、各々のテスト項目に対応して発注した開発の開発モジュールID、該開発をテストする際に入力情報として必要な入力情報、テストの際に出力が期待される出力情報、さらに該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールの開発モジュールID、テストが終了した際に該テストが成功裏に完了したかを受注側が確認したときに記載する受注者確認日、受注確認日と同様に該テスト完了時に発注者側がテストが成功であったと判断するときに記載する発注者確認日から構成されている。
さらに次にテストを行う開発モジュールのポインタの先には同様な構成のデータが1つのテストに関してテストが終了するに至るまでリンクされており、次の開発モジュールIDにはテストの完了を示す場合は例えば"FF"が記載されているものとする。もしくはアスキー文字列で"END"などと記載されていても良い。
性能試験データベース(DB)144は、図8に示すように本実施の形態では、図7に示す検証順序DB143の構成に加えてテストにおいて「期待する所要時間」とテストに「要した時間」の欄が追加になっている。本実施の形態では、検証順序DB143の構成に追加という形式であるが、1つ1つテスト行う場合は順序は必要が無い。開発関連データベース(DB)145は、本実施の形態では図9に示すように1つの開発を複数の開発モジュールに分け受注会社に発注する際の開発の最小単位を表している。
開発IDごとに該開発IDで分けている最小単位の開発モジュールのIDが存在し、さらに各々の開発モジュールごとにその開発モジュールを受注する開発会社の会社IDとその開発モジュールが使用する複数の開発モジュールの開発モジュールIDから構成される。本実施の形態では関連モジュールはその開発モジュールが使用する開発モジュールと規定しているが、その開発モジュールを使用する上位の開発モジュールを規定していても良い。図7および8に示す開発モジュールIDはその関係が図9に示されている。開発支援システム1は以上のように構成されている。
次に開発拠点側の端末5について図1を用いてその機能ブロックを説明する。構成としては開発支援システム1と同様であり、概略としては通信ネットワーク4を介して開発支援システム1と情報の送受信を行う送受信部52、さまざまな情報を解析して入力情報や、保存しているデータなどから演算して処理を行う中央演算処理部53、開発側でテストを行うのに必要な情報を保存する記憶部54、端末5との万マシンインタフェースを司る入力部55と表示部56から構成されている。
さらに中演算処理部53は、以下に述べる機能を有する各手段から構成されている。送受信処理手段(機能)531は、送受信部52と情報の送受信を行い、例えばTCP/IPなどの通信プロトコルの終端の制御を行う。入出力処理手段(機能)532は、入力部55と表示部56と入出力情報を制御する。検証支援手段(機能)533は、開発支援システム1からの入力情報をパラメータとして開発物を起動して開発物からの出力情報を取得したり、もしくは端末5の記憶部54内に保存されたその端末に特有の納品定義DB542および検証順序DB543を参照して開発物にパラメータを入力情報として渡して開発物を起動し、開発物からの出力情報を取得し、該出力情報を開発支援システム1内の自動検証手段(機能)134に送信する機能を有する。
検証順序制御手段(機能)534は、図7に示す検証順序に従って検証を行うに際し、当該拠点の検証における出力情報を次の開発モジュールへと直接送信する機能を有する。記憶部54は以下に示すように複数のデータベースを有している。納品定義DB542は、当該拠点内で検証を行う際に使用される当該拠点のみのデータベースでありその内容は開発支援システム1内の納品定義DB142のサブセットである。検証順序DB543は前述したように次の開発モジュールに検証の出力を送信するのに使用されるデータベースであり、内容は開発支援システム1の検証順序DB143のサブセットである。
図2は開発支援で使用する納品定義DB142および542の関係を示している。開発支援システム1内の納品定義DB142は開発に関して全開発拠点の開発案件のテスト項目を有している。各開発拠点である「い社」、「ろ社」、「は社」は納品定義DB542として1つの開発案件に対して自分の開発案件の分のみの納品定義を有している。本実施の形態を示す図2では、1つの開発案件である「第1システム開発案件」に対して上記「い社」、「ろ社」、「は社」の3社に開発を委託しており、例えば「い社」には開発のA機能とB機能を発注し、「ろ社」にはC機能のみを発注し、「は社」にはD機能およびE機能を発注していることを示している。よって各社の納品定義DB542には、「い社」はA機能とB機能の情報を有し、「ろ社」はC機能、「は社」はDおよびE機能の情報を有している。また、納品定義の登録・修正および、テストにおける利用方法などについては以降に述べる。
図3は本実施の形態における開発支援システムの業務フローの概略を示している。本実施の形態では、まず発注を受けた開発会社が開発における確認用テスト項目を作成し(S31)、開発支援システム1内のデータベースに納品定義として登録される。登録された確認用テスト項目の内容のチェックは発注者が行い(S32)、抜けなどの問題があれば「発注者確認用テスト項目」として受注者に登録を指示する(S35)。
指示を受けた受注開発会社は指示を受けた内容を「確認用テスト項目」に追記したり修正したりする。このように納品定義はスパイラル型開発モデルのような開発手法で改善されながら完成させる。追記・修正された「確認用テスト項目」は再度発注者によってチェックされ要求仕様を満足できるものであれば一旦完成し、開発後に受注側および発注側が検査を行い、問題が無ければ納品され、発注者が検収を行い一連の発注による開発が完了する。図3は上記のように受注開発に関する一連の流れを示している。
開発支援システム1および開発拠点の端末5は以上のように構成され、以下に各々の動作について説明する。図10は納品定義DB142、542に記載する「確認用テスト項目」の記載を開始するところから、記載終了後に開発を開始し、総合テストおよびフィールドテストにおいて、前記記載した納品定義DB142、542に記載されている「確認用テスト項目」を参照して検証を行い、納品してから検証までという一連の作業をフローで表したものである。
図10を用いて受注開発支援に関する一連の作業フローの概略を説明する。図10において、向かって左端からそれぞれ、各拠点の端末5、開発支援システム1、発注側端末を表している。各拠点の端末5は複数存在するものであるが図10においては1つの端末についてのみ説明している。また発注側端末としては、システムに直接入力可能な開発支援システム1の入力部5でも良いし、発注側端末としてインターネットを利用し、開発支援システム1がWWWで情報の送受信が可能になっている場合はインターネットに接続される端末であればどこに存在しても良い。本実施の形態では、インターネットを利用した発注側端末であるものとする。
図3で説明したように、各開発拠点の端末5から「確認用テスト項目」入力する(S101a)。入力された「確認用テスト項目」は通信ネットワーク4を介して開発支援システム1の送受信部12、送受信処理手段131を経由して、データ入出力手段133が受信し(S101b)、データ入出力手段133はその受信した「確認用テスト項目」の内容を図5および図6に記載の納品定義DB142に書き込む(S102b)。新たにテスト項目が書き込まれたり修正されたりした場合は、開発支援システム1の納品定義項目修正通知手段(機能)136が追加・修正があったことをあらかじめ決められたあて先にあらかじめ決められた方法で通知する(S103b)。例えば各拠点の開発会社のプロジェクトリーダおよび発注側の担当者に電子メールで通知するなどである。
各拠点のプロジェクトリーダおよび発注の担当者は納品定義DB142もしくは542に追加・修正があったという通知を受信し(S102a、S102c)、必要があれば追加・修正された内容を確認することができる。この場合、この追加・修正通知自体に修正内容の一部を内容として含ませておくこともできるし、追加・修正があったことのみの通知で詳細は開発支援システム1にログインし確認するという手順を踏んでも良い。各拠点側の「確認用テスト項目」が全て入力されたかを判断し(S103a)、完了していない場合はステップS101aに戻り次のテスト項目の内容の入力を行うことになる。
またテスト項目の入力は本実施の形態のように1項目ずつ開発支援システム1に入力される方法でも良いし、全ての項目もしくは項目のまとまりを各拠点の端末側で行い、ある時点で開発支援システム1に入力すると方法でも良い。もしくはテスト項目自体はファイルとして作成しそのファイルを開発支援システム1に送信するという方法でも良い。全項目の入力が済んだ後に投入した「確認用テスト項目」の内容を確認する(S104a)。投入したテスト項目の内容が良くなければ再度最初に戻りステップS101aのテスト項目の入力を行う。図10では投入した テスト項目の内容の確認を全ての項目の投入が済んだ後に行うようになっているが、途中でテスト項目の確認を随時行うように構成しても良い。
受注側の担当者がテスト項目の入力と確認を終了した時は、各拠点の開発側の端末5はテスト項目の入力および確認が完了したことを開発支援システム1に通知する(S105a)。開発支援システム1はテスト項目の入力および確認完了の情報を受信し(S104b)、発注側のあらかじめ決められたあて先にあらかじめ決められた方法でテスト項目の入力および確認が終了したことを通知する(S105b)。本実施の形態の場合は、例えばあらかじめ決められたあて先としては該当開発の発注担当者であり、あらかじめ決められた通知方法としては音声合成されたメッセージを発注担当者の携帯電話機に電話をかけて通知するというのでも良い。もしくは開発支援システム1で自動的に発注側に通知するのではなく、受注した開発会社の担当者が直接発注側の担当者に電話もしくは電子メールなどで通知するという方法でも良い。
テスト項目の入力および確認が完了したことの通知を受けた発注側の担当者は、開発支援システム1にログインし「確認用テスト項目」の内容の確認を行い、その結果として「OK」もしくは「NG」を開発支援システム1に通知し(S106c)、開発支援システム1はその受信した(S106b)内容を各拠点の開発会社のプロジェクトリーダなどに電子メールなどを用いて通知する(S107b)。もしくは開発支援システム1にログインしたときに通知が確認できるように構成されても良い。本実施の形態では「NG」であった場合の業務フローについては記載していないが、上述の各拠点の開発端末からテスト項目を入力するところ(S101a)から再度開始することになる。
発注側の確認が「OK」の場合(S106a)、受注側の開発会社は開発に着手する。この開発は前記投入した「確認用テスト項目」に従って、要求仕様を確認しながら行う(S107a)。もしこの開発段階で仕様を修正する必要があるなどの仕様上の問題が発見された場合は、発注側の担当者に通知した上で図10の業務フローを最初から行うことになる。また発注側端末の業務フローにテスト項目の入力(S101c)が存在するが、受注側の開発会社と共同して納品定義である「確認用テスト項目」を作成する場合はこのように発注側でもテスト項目の入力という一連の作業を行う(S101c〜S104c)こともできることを示している。
開発の着手については、本実施の形態のようにテスト項目の入力と確認が完了していなければ行えないとしても良いし、あるまとまったテスト項目の入力と確認が行われた時点でその部分の開発を着手するという開発の手法を用いても良い。
次に開発が完了し総合テストを行う際には、本実施の形態では受注側の開発会社から発注側の担当者に電子メールや電話などの手段を用いて通知を行うかもしくは図10には図示していないが、開発完了を開発支援システム1に登録することで開発支援システム1が自動的にあらかじめ決められた担当者にあらかじめ決められた方法で通知するという手順を行っても良い。この後は、開発側および発注側で前記入力した納品定義DB142、542に定義されている「確認用テスト項目」に基づいて総合テストを行い(S10Aa、S108b)、さらにフィールドテストを行う(S10Ba、S109b)。同様に発注側でも総合テスト(S108c、S108b)とフィールドテストを行っても良い(S109c、S109b)。但しお互いに同じ試験を行うのが好ましくない環境である場合はどちらかの試験のみが行える、もしくはどちらかしか行えないというように開発支援システム1にて制限もしくはオプションを加えることも良い。また、上記納品定義DB142、542に記載されているテスト項目の検証は開発中に随時行うとしても良い。
テストで結果が「確認用テスト項目」に投入されている内容を満足すれば、受注側の担当者は開発物を納入し(S10Ba)、発注側の担当者は納品物に対して検収を行う。上記「総合テスト」および「フィールドテスト」の詳細な内容については後で述べる。受注開発に関する業務のフローの概略は以上説明したように行い、以下により詳細な内容を説明する。
次に図11を用いて本実施の形態のおける納品定義DB142に「確認用テスト項目」を入力する際の動作フローについて説明する。まず開発拠点の端末5から担当者が例えばインターネットを利用してWEBブラウザにて開発支援システム1のURL(Universal Resource Locator)をアクセスする(S111a)ことで開発支援システム1にログインする。開発支援システム1はアクセスを受付け(S111b)、ログイン画面を作成して端末5に送信する(S112b)。
端末5は受信したログイン画面を表示する(S113a)。図12に表示されるログイン画面を示す。図中121は例えばWEBブラウザの内容表示枠内に表示される内容であり、122の部分に示すように、開発支援システム1にログインするためのユーザIDとパスワードの入力を求められる。この画面にてユーザIDとパスワードを入力し(S113a)、「ログイン」釦を押下すると、入力した内容が開発支援システム1に送信される。前述したようにインターネットを介してユーザIDおよびパスワードを送信する場合は、本実施の形態ではフロー上には詳細に記載していないが、情報の漏洩を防ぐため暗号化の通信プロトコルを用いて暗号化されている。
開発支援システム1はユーザIDおよびパスワードを受信し(S113b)、ユーザIDおよびパスワードが正しいかを判断する(S114a)。ユーザIDもしくはパスワードが合致していなければエラー画面を作成して端末5に送信し(S115b)、処理を終了する。エラー画面を受信した(S113a)端末5は、受信したエラー画面を表示(S114a)し、処理を終了する。
ユーザIDとパスワードが合致した場合は、そのログインしてきたユーザが所属する開発会社を特定してその開発拠点に合った納品定義DB142内の「確認用テスト項目を編集できる画面を作成して端末5に送信する(S116b)。納品定義内容の表示画面を受信した端末5は、受信した表示画面を表示する(S115a)。
次に開発側の端末5の操作者であるプロジェクトリーダなどが納品定義の内容として「確認用テスト項目」に記入すると、その記入した情報が通信ネットワークを介して開発支援システム1へ送信される(S117a)。全てのテスト項目の入力が終了するまで(S118a)「確認テスト項目」の記入を継続する。開発支援システム1は受信した「確認用テスト項目」の内容を反映し(S118b)、再度入力を反映した新たな画面を作成して端末5に送信する(S116a)。上記動作を「確認用テスト項目」の入力が終了するまで行う。
納品定義内容の入力が終了した場合、端末5は終了したことを開発支援システム1に通知する(S119a)。入力終了の通知を受けた(S119b)開発支援システム1は、納品定義が修正されたことをあらかじめ決められたあて先にあらかじめ決められた方法で通知する。納品定義が追加・修正になった場合には、図20に示すように各々の納品定義IDについて通知するあて先とそのあて先それぞれについて通知先の氏名、所属する会社名、電話番号FAX番号、電子メールアドレスおよび通知の際に所望する通知方法などが登録されている「納品定義修正時に通知するあて先一覧」を参照して通知を行う。
次に図13を用いて自動検証手段134と検証支援手段533とがお互いに通信して検証を行う動作について説明する。図13においては検証支援手段533はその出力を自動検証手段134に通知するという構成になっている。まず自動検証手段134は図5に示す内容の納品定義DB142から該当する検証支援手段533の入力情報を入手する(S131b)し、入力情報を対応する拠点に送信する(S132b)。各拠点の検証支援手段533は通信ネットワーク4を介して送受信部52、送受信処理手段531を経由して入力情報を受信し(S131a)、その入力情報をパラメータとして開発物を起動する(S132a)。
開発物が起動した後に出力する出力情報を受信し、検証支援手段533はその出力内容を自動検証手段134に送信する(S133a)。出力情報を受信した(S133b)自動検証手段134は、テスト結果を図7および図8に示す開発モジュール単位のテストの「期待される出力情報」と比較判定し「検証結果」の欄に合格の場合は「OK」(S136b)、不合格の場合は「NG」(S137b)などと書き込む。この作業を予定している全試験が終了するまで継続する(S138b)。
上述したように図13に示すテスト項目の検証のフローは自動検証手段134が各テスト項目の出力情報を取得し次の検証を行うという構成である。よって図14に示すように開発を複数の開発会社A、B、Cに発注し、各拠点に存在する開発会社が作成した開発物が互いに関連があり、ある開発会社の開発物の出力情報が他の開発会社の開発物のテスト項目の入力情報になっている場合は、図13で説明した動作は図14に示すフローのように行われ、上記互いに関連のある開発物の一連のテスト項目を行うことができる。
この場合、発注者は、開発支援システム1の入力部15を使用するか、WEBブラウザを用いてインターネット上に存在する端末を用いてを検証を開始する。まず納品定義DB142より「確認用テスト項目」からテストに関する最初の入力情報を入手し、最初の開発物を有する開発会社A宛に入力情報を送信する(S141a)。入力情報を受信した開発会社Aの検証支援手段533は受信した(S141b)入力情報をパラメータとして開発物を起動する(S142b)。
開発会社Aの検証支援手段533は開発物からの出力情報を受信し(S143b)、その出力情報を発注者が起動している自動検証手段134に送信する(S144b)。出力情報を受信した自動検証手段134は、納品定義DBに記載されている「確認用テスト項目」を参照し次の開発物を抽出し、開発会社Aから受信した出力情報を開発会社Bに送信する(S143a)。さらに入力情報を受信した開発会社Bの検証支援手段533は開発会社Aと同様に受信した入力情報をパラメータとして開発物を起動し(S142c)、開発物からの出力情報を受信し(S143c)、その出力情報を自動検証手段134に送信する(S144c)。
次に自動検証手段134は同様に納品定義DB142を参照し次のテストを行う先が開発会社Cの開発物であることを知り、開発会社Bの開発物からの出力情報を開発会社Cに送信する。開発会社Cの検証支援手段533は、図14の開発会社Bの検証支援手段533が行った処理を同様に行い(S142d〜S144d)、さらに自動検証手段134は開発会社Bに対して同様にテストを行う(S147a、S145c〜S148c)。
図14では、一連のテストはこれで終了し発注者側の自動検証手段134は途中で受信した出力情報および最終的に受信した出力情報をもって納品定義DB142を参照することで一連のテストの結果を得ることができる。上記一連のテストは図7に示す検証順序DB143に定義された順に行われ、結果の判断もこの検証順序DB143の「期待する出力情報」を出力結果と比較検討することでテスト結果が得られることになる。
次に開発側拠点の検証支援手段533が、自分の開発物の出力情報を入力情報として必要としている開発物に対して自動検証手段134を経由せずに直接出力情報を入力情報として送信するという検証の形式について図15および図16を用いて述べる。図14と同様にまず自動検証手段134は納品定義DB142に記載されている「確認用テスト項目」を参照して拠点対応の入力情報を入手(S151b)、入手した入力情報を対応する開発拠点に送信する(S152b)。この時、該当する開発拠点の図4に示す開発会社DB141よりドメイン名もしくは固定のグローバルIPアドレスを入手し情報を送信するものである。
入力情報を受信した(S151a)開発拠点の検証支援手段533は、受信した入力情報をパラメータとして開発物を起動し(S152a)、結果として出力情報を得る(S154a)。得た出力情報と図7および図8に記載している納品定義DB142内の「期待される出力情報」と比較検討しその結果を合格の場合は「OK」(S157a)、不合格の場合は「NG」と記載する(S158a)。次に納品定義DB142を参照して次の開発物を抽出し出力情報を次の拠点に送信する(S159a)。図15中最左端のフロー図は一連のテストが終了し最後に結果を自動検証手段134に送信している(S159a)の部分が中心の開発拠点の検証支援手段533のフロー図と異なる点である。
図15の動作フロー図に基づき図16の一連のテストのシーケンス図の概略動作を説明する。図16のテストシーケンス図は開発拠点の検証支援手段533が、テストが行われた際の開発物からの出力情報を次の開発物の入力情報として直接次の拠点に送信しているところが図14と異なる点である。まず自動検証手段134は納品定義DB142を参照して入力情報を入手し(S161a)、最初のテストを行う開発会社Aの開発物をテストするために入手した入力情報を開発会社Aに送信する(S161a)。
送信された入力情報は、通信ネットワーク4を介して、さらに送受信部52、送受信処理手段531を経て開発会社Aの検証支援手段533が受信する(S161b)。開発会社Aの検証支援手段533は受信した入力情報をパラメータとして開発物を起動する(S162b)。開発物内でテストが完了し出力情報を受信した(S163b)検証支援手段533は、自分が有する納品定義DB542を参照して次に起動させるべき開発物とその開発物を開発している開発拠点を抽出し、出力情報を入力情報として次のテスト対象の開発物を開発している拠点である開発会社Bに送信する(S164b)。
その後は次のテスト対象の開発物を有する開発会社Bでも同様に入力情報を受信し(S161c)、その入力情報をパラメータとして開発物を起動し(S162c)、開発物からの出力情報を取得し(S163c)、自分が所有する納品定義DB542を参照して次のテスト対象の開発物とその開発物の開発担当である開発会社を特定し、取得した出力情報を入力情報として次の開発拠点に送信する(S164c)。その後の図16における動作フローである開発会社Cでのステップ161d〜164dまで、さらに開発会社BのステップS165c〜168cまでは前述と同様の動作を行う。
但し、開発会社Bのステップ168cは、自分が所有する納品定義DB542を参照するが、次の拠点が無いことを判断し検証の元である自動検証手段134を備えた開発支援システム1に出力情報を送信する(S168c)。自動検証手段134は出力情報を受信し(S162a)、納品定義DB142を参照して一連の開発物の判定を行う(S163a)。上記一連の動作において、各開発会社でのテスト項目の検証の結果は各検証支援手段533が図7のテスト対象の開発モジュール単位に設けられている「検証結果」に記入し、全体のテスト項目の検証の結果は自動検証手段134がテスト全体の結果に記入する。
各開発拠点の検証結果は各開発拠点内の納品定義DB542に記載されるが、この納品定義DB542は例えば一連のテストが終了時に開発支援システム1内の納品定義DB142に通知され内容の更新が行われる。
次に検証終了後にレポートを作成し通知する機能について図17を用いて説明する。図17は、「確認用テスト項目」の検証が終了したときには、例えば周期的にもしくは検証終了のタイミングでレポートを作成し、あらかじめ決められたあて先にあらかじめ決められた方法で通知する機能を説明する動作フロー図である。まず、レポート作成手段137は、納品定義DB142に従って「確認用テスト項目」の検証を行うことを自動検証手段134に指示する(S171)。このテストについては前述した通りである。図7および図8に記入されている入力情報、出力情報、期待される出力情報、検証結果などの一覧を例えば開発モジュール単位で全てのテスト項目の処理が終了するまでレポート形式に出力する(S173、S174)。作成した全テスト項目分のテスト結果のレポートをあらかじめ決められた全てのあて先にあらかじめ決められた方法で通知する(S174、S175)。レポートとして図21に例を示す。
開発物の完成度は、図23ないし図25に示しているように各テスト項目が複数の確認項目を有する場合は、合格した割合などをあらかじめ決められた合格判定基準に照会してテスト項目として合格したかどうかを判定する。よって納品定義項目の内容はあらかじめ発注者と受注者間で内容を確認した上で決定しているので正確な完成度合いが分かる。同様に時間的な性能を確認するテストにおいてもその開発物および一連の開発物の完成度を判定することができる。
本発明による第1の実施の形態は以上のように構成され動作する。
本実施の形態によれば、開発の前段階で開発の要求仕様となる部分の「確認用テスト項目」を納品定義DB142内に作成し発注者および受注者間で承認し、開発に際しては前記納品定義DB142内の「確認用テスト項目」を参照しながら開発を行えるので仕様の間違いが少なく、意思の疎通が図れた開発が可能となる、さらに開発終了時にも前記「確認用テスト項目」を用いて自動的に試験が可能であるので、工数の削減が図れる。
次に本発明の第2の実施の形態について図22を用いて説明する。第2の実施の形態は、第1の実施の形態に加えて、テストを行う際に入力情報と、入力情報をパラメータとして開発物を起動する際の時刻を記録し、開発物からの出力情報を受ける際に時刻を記録して、各開発物の時間的な性能および、全システムの時間的な性能を計測するシステムである。以下、図22を用いて説明する。図22は基本的に図14と比較してステップ143x、143y、143z、147yの部分のみが異なる。上記ステップでは図14に加えて開発物を起動する際の時刻と、開発物から出力情報を受けた時の時刻を取得し出力情報として自動検証システム142に送信する。
本発明による第2の実施の形態は以上のように構成され動作する。
本実施の形態によれば、一連の「確認用テスト項目」をテストする際に個々の開発モジュールの時間的な性能を同時に検証することができ、システム全体としての時間的な性能も計測することができる。
なお、第2の実施の形態では、一連の開発モジュールのテストにおいて、出力結果を開発支援システム1の自動検証手段134に送信しているが、図16で説明したように個々の開発会社の検証支援手段533は、開発物から取得した出力情報を次の開発物の入力情報として直接送信することも可能である。
ソフトウェア開発を行う産業において利用可能である。
本発明の第1の実施の形態に関わる、制御局および拠点端末を含む開発支援システムの機能ブロック図である。 図1のデータベースの関連図である。 図1の開発支援システムの業務フロー図である。 図1の開発会社DBである。 図1の納品定義DBである。 図1の納品定義DBの詳細な内容である。 図1の検証順序DBである。 図1の性能試験DBである。 図1の開発関連DBである。 図1の概要通信シーケンス図である。 図1の納品定義を入力するシーケンス図である。 図1の開発支援システムにログインする際に表示される画面である。 図1の自動検証手段がテストを複数の拠点に対して行う際のフロー図である。 図1の自動検証手段がテストを複数の拠点に対して行う際の通信シーケンスである。 図1の検証支援手段が直接次の拠点の検証支援手段に制御を渡す際のフロー図である。 図1の検証支援手段が直接次の拠点の検証支援手段に制御を渡す際の通信シーケンスである。 図1の開発支援システムが検証が終了した際にレポートを作成し出力する際のフロー図である。 従来の受注開発管理を示す表である。 第1の実施の形態での受注開発管理を示す表である。 第1の実施の形態の納品定義修正時に通知するあて先一覧である。 第1の実施の形態のテスト結果レポートの例である。 第2の実施の形態における動作フロー図である。 第1および第2の実施の形態における完成度の測定基準を示す図である。 第1および第2の実施の形態における時間的性能に関する完成度の測定基準を示す図である。 第1および第2の実施の形態におおける一連のテストの完成度の測定基準を示す図である。
符号の説明
1 開発支援システム
4 通信ネットワーク
5 拠点端末
12、52 送受信部
13、53 中央演算処理部
14、54 記憶部
15、55 入力部
16、56 表示部
131、531 送受信処理手段
132、532 入出力処理手段
133 データ入出力手段
134 自動検証手段
533 検証支援手段
135、534 検証順序制御手段
136 納品定義項目修正通知手段
137 レポート作成手段
141 開発会社DB
142、542 納品定義DB
143、543 検証順序DB
144 性能試験DB
145 開発関連DB

Claims (4)

  1. 複数の開発会社の夫々に備えられた端末と、通信ネットワークを介して前記端末から送られてくる情報に基づいて開発ソフトウェアの完成度を判定するサーバとを有する開発支援システムであって、
    前記サーバは、
    開発会社IDに前記端末のアドレスを関連付けて保存する開発会社DBと、
    納品定義IDごとに、開発会社ID、テスト項目、要求仕様に合致しているかを確認するための入力情報、期待する出力情報、開発工程、入出力系や性能などの分野を表す属性、受注者および発注者が確認した日を関連付けた納品定義項目を保存する納品定義DBと、
    テスト項目ごとに該テストを実行するために動作すべき開発モジュールのID、該開発モジュールをテストする際に必要な前記入力情報、該入力情報に対する前記出力情報、該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールのIDを関連付けて保存する検証順序DBと、
    納品定義IDごとに、電子メール、電話番号、および通知方法を関連付けたあて先一覧を保存する手段と、
    前記端末から送られてきた納品定義項目を前記納品定義DBに保存するデータ入出力手段と、
    前記端末から前記納品定義DBへ書き込み可能とし、前記納品定義DBに新たな書き込みがあった際に、前記あて先一覧を参照して、前記通知方法に基づいて電子メールアドレスあるいは電話番号へ新たな書き込みがあったことを通知する納品定義項目修正通知手段と、
    前記検証順序DBの検証順序に従って検証を行わせる開発モジュールのIDを取得する検証順序制御手段と、
    前記検証順序DBから検証を行わせる開発モジュールの入力情報を取得し、当該入力情報を対応する開発会社の端末に送信し、その後、当該端末からテスト結果として送られてくる出力情報を受信し、該テスト結果を前記検証順序DBの該入力情報に対する前記出力情報と比較判定して合格、不合格を判定し、さらに合格したテスト項目の割合をあらかじめ決められた合格判定基準と比較して開発ソフトウェアの完成度を算出する自動検証手段と、を備え、
    前記端末は、
    開発ソフトウェアに対する納品定義項目を入力するする入出力処理手段と、
    入力した納品定義項目を前記サーバへ送信する送受信処理手段と、
    前記サーバから送られてくる入力情報を受信し、その入力情報をパラメータとして開発ソフトウェアを起動し、その後、開発ソフトウェアが出力する出力情報を前記サーバに送信する検証支援手段と、
    を備えたことを特徴とする開発支援システム。
  2. 前記自動検証手段は、各々の開発会社の端末から送られてきた開発ソフトウェアの出力情報を次の開発会社の開発ソフトウェアの入力情報として該次の開発会社の端末へ送信することを特徴とする請求項1に記載の開発支援システム。
  3. 前記サーバは、テスト項目ごとに該テストを実行するために動作すべき開発モジュールのID、該開発モジュールをテストする際に入力情報として必要な入力情報、テストの際に出力が期待される出力情報、該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールのID、期待する所要時間、テストに要した時間とを関連付けて保存する性能試験DBを備え、
    前記端末の前記検証支援手段は、前記入力情報をパラメータとして開発ソフトウェアを起動したときの時刻と、開発ソフトウェアからの出力情報を受信したときの時刻とを前記サーバへ送信し、
    前記サーバの前記自動検証手段は、前記端末から受信した開発ソフトウェアを起動したときの時刻、開発ソフトウェアからの出力情報を受信したときの時刻からテストに要した時間を算出して前記性能試験DBに保存すると共に、該テストに要した時間と前記期待する所用時間とを比較して合格、不合格を判定することを特徴とする請求項1または2に記載の開発支援システム。
  4. 開発会社IDに端末のアドレスを関連付けて保存する開発会社DBと、納品定義IDごとに、開発会社ID、テスト項目、要求仕様に合致しているかを確認するための入力情報、期待する出力情報、開発工程、入出力系や性能などの分野を表す属性、受注者および発注者が確認した日を関連付けた納品定義項目を保存する納品定義DBと、テスト項目ごとに該テストを実行するために動作すべき開発モジュールのID、該開発モジュールをテストする際に必要な前記入力情報、該入力情報に対する前記出力情報、該開発モジュールが出力する情報を入力情報として用いる次に起動されるべき開発モジュールのIDを関連付けて保存する検証順序DBと、納品定義IDごとに、電子メール、電話番号、および通知方法を関連付けたあて先一覧を保存する手段とを有し、複数の開発会社の夫々に備えられた端末から通信ネットワークを介して送られてくる情報に基づいて開発ソフトウェアの完成度を判定するサーバ上で動作するプログラムであって、
    前記端末から送られてきた納品定義項目を前記納品定義DBに保存するデータ入出力処理と、
    前記端末から前記納品定義DBへ書き込み可能とし、前記納品定義DBに新たな書き込みがあった際に、前記あて先一覧を参照して、前記通知方法に基づいて電子メールアドレスあるいは電話番号へ新たな書き込みがあったことを通知する納品定義項目修正通知処理と、
    前記検証順序DBの検証順序に従って検証を行わせる開発モジュールのIDを取得する検証順序制御処理と、
    前記検証順序DBから検証を行わせる開発モジュールの入力情報を取得し、当該入力情報を対応する開発会社の端末に送信し、その後、当該端末からテスト結果として送られてくる出力情報を受信し、該テスト結果を前記検証順序DBの該入力情報に対する前記出力情報と比較判定して合格、不合格を判定し、さらに合格したテスト項目の割合をあらかじめ決められた合格判定基準と比較して開発ソフトウェアの完成度を算出する自動検証処理と、
    をサーバ上で実行させることを特徴とする開発支援プログラム。
JP2005218739A 2005-07-28 2005-07-28 開発支援システム、および開発支援プログラム。 Expired - Fee Related JP4744220B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005218739A JP4744220B2 (ja) 2005-07-28 2005-07-28 開発支援システム、および開発支援プログラム。

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005218739A JP4744220B2 (ja) 2005-07-28 2005-07-28 開発支援システム、および開発支援プログラム。

Publications (2)

Publication Number Publication Date
JP2007034796A JP2007034796A (ja) 2007-02-08
JP4744220B2 true JP4744220B2 (ja) 2011-08-10

Family

ID=37793965

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005218739A Expired - Fee Related JP4744220B2 (ja) 2005-07-28 2005-07-28 開発支援システム、および開発支援プログラム。

Country Status (1)

Country Link
JP (1) JP4744220B2 (ja)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1165888A (ja) * 1997-08-19 1999-03-09 Casio Comput Co Ltd ソフトウェア試験装置および記憶媒体
JP2000003291A (ja) * 1998-06-12 2000-01-07 Toray Ind Inc プログラム開発支援システム
JP2000132425A (ja) * 1998-10-26 2000-05-12 Hitachi Ltd ソフトウェアテスト方法
JP2000284952A (ja) * 1999-03-30 2000-10-13 Mitsubishi Electric Corp ソフトウェア生成試験連携機構
JP2001229049A (ja) * 2000-02-17 2001-08-24 Hitachi Ltd 自動問合せ型端末シミュレータ
JP2002358214A (ja) * 2001-06-01 2002-12-13 Toshiba Corp ソフトウェアテスト装置、ソフトウェアテストプログラム、ソフトウェアテスト方法及びソフトウェアテストシステム
JP2003044276A (ja) * 2001-07-26 2003-02-14 Mitsubishi Electric Corp ソフトウェア開発管理装置、ソフトウェア開発管理方法、ソフトウェア開発管理方法をコンピュータに実行させるためのプログラム及びソフトウェア開発管理方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
JP2003177942A (ja) * 2001-12-12 2003-06-27 Mitsubishi Electric Corp ソフトウェア単体試験の支援方法及び支援装置
JP2003271418A (ja) * 2002-03-11 2003-09-26 Empirix Inc ウエブベースのソフトウエアオブジェクトのテスト方法
JP2004126899A (ja) * 2002-10-02 2004-04-22 Canon I-Tech Inc ソフトウエアのテストシステム
JP4154289B2 (ja) * 2003-06-20 2008-09-24 富士通株式会社 不具合検出方法

Also Published As

Publication number Publication date
JP2007034796A (ja) 2007-02-08

Similar Documents

Publication Publication Date Title
Shahin et al. Beyond continuous delivery: an empirical investigation of continuous deployment challenges
US20140278244A1 (en) System and method for providing user guidance for electronic device processing
WO2001016721A2 (en) A system, method and article of manufacture for managing an environment of a development architecture framework
JP2002312518A (ja) 航空機の不適合部品の管理システムおよびその方法
KR20070113168A (ko) 시스템 구축 가이드 시스템
JP2006511855A (ja) コンテント管理システム
JP2020098556A (ja) 検証用注釈処理作業を用いた実施用注釈処理作業の検証方法及び装置
CN111966426A (zh) 一种api对接方法、系统、设备及存储介质
JP2008501158A (ja) ワークフロー可用なリンク・アクティブ化のためのシステムおよび方法
US20080162636A1 (en) System and method for replying to questions on-line
JP2004145715A (ja) コンピュータの保守システムおよび保守方法
US20230231900A1 (en) Webtier as a service
JP4744220B2 (ja) 開発支援システム、および開発支援プログラム。
CN112015715A (zh) 工业互联网数据管理服务测试方法及系统
KR102330804B1 (ko) 소프트웨어 개발 원가검증 시스템
KR20090038981A (ko) 장애 관리 장치 및 방법
CN111523808B (zh) 模型集中化管理方法及系统、设备、存储介质
JP2009104588A (ja) システム構築ガイドシステム
Mrabet NDT-Link
CA3153912A1 (en) Workflow for self provisioning smart well controller
KR19990064587A (ko) 인터넷을 사용한 실시간 게임분석 시장 조사 방법
Das et al. Using ISO 90003 for software “design and development” in large virtual teams
JP6946530B2 (ja) 本番作業に基づいた検証用クラウドソーシング作業を提供する方法及び装置
JP4371674B2 (ja) システムセットアップ方式、セットアップ方法、およびそのプログラム
JP2003131875A (ja) ソフトウェア開発支援サーバ及び利用端末及びソフトウェア開発支援システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080122

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100531

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100713

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100913

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110426

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110510

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140520

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4744220

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140520

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees