JP4467363B2 - 製品開発支援システムおよび方法、製品テスト支援システム、およびコンピュータプログラム - Google Patents

Description

本発明は、製品の開発のための支援を行うシステムおよび方法などに関する。

近年、製品の開発を支援するツールとして、ＣＡＳＥ（Computer Aided Software Engineering）ツールが利用されるようになった。このＣＡＳＥツールによると、開発の効率を向上させることができる。

また、ＣＡＳＥツールの問題点を補うための技術も提案されている。例えば、ＣＡＳＥツールによると、製品の品質および信頼性の定量的な評価を行うために、専門家の判断が必要であった。特許文献１に記載される方法によると、係る問題点を解決し、専門的知識を持たないユーザであっても、観測データに最も適した数理モデルに基づいて製品の品質および信頼性を容易に評価することができる。
特開２００２−５５８１５号公報

ＣＡＳＥツールは、第一工程ではＣＡＳＥツールＴ１、第二工程ではＣＡＳＥツールＴ２、…というように、製品の開発の工程ごとに最適なものが使用される。また、ＣＡＳＥツール以外にも文書管理ツールなどのソフトウェアが使用されることもある。したがって、開発スタッフは、開発中に生じた種々の情報を複数のツールのそれぞれに登録しなければならない場合がある。そうすると、登録のための作業工数が増加するとともに、入力ミスや入力漏れが生じるおそれが大きくなる。

また、障害が発生しないかどうかをチェックするためのテストの作成は、従来、開発スタッフが手作業で実施している。したがって、テストの作成工数をできるだけ減らし、かつ、必要なテストを確実に行ってミスが発生しないようにすることが要求されている。

本発明は、このような問題点に鑑み、製品の開発において複数のツールを使用した場合であっても、作業工数を抑え、かつ、ミスの発生を防止できるようにすることを目的とする。

本発明に係る製品テスト支援システムは、製品の障害の有無を判別するためのテストの実施を支援する製品テスト支援システムであって、前記テストごとに、当該テストの内容に関するテスト情報を記憶するテスト情報記憶手段と、製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を記憶する実施必須情報記憶手段と、障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と、前記テスト情報記憶手段に記憶されている前記テスト情報であって当該実施必須情報が示す実施すべきテストに関する前記各テスト情報のうちの当該テストの実施対象である構成要素を示す情報とに基づいて生成する実施必須情報生成手段と、を有することを特徴とする。

本発明は、ソフトウェアおよびハードウェアなどの製品の開発のための使用することができる。ソフトウェアの場合は、モジュール、クラス、またはオブジェクトなどが「構成要素」に該当する。ハードウェアの場合は、回路または各種機構などが「構成要素」に該当する。ソフトウェアおよびハードウェアの両方によって構成される製品の場合は、モジュール、クラス、オブジェクト、回路、または各種機構などが「構成要素」に該当する。

本発明によると、複数の種類の製品同士で一部のテストに関する情報を共用することによって、テストのための作業工数を減らすことができる。

図１は製品開発システム１００の全体的な構成の例を示す図、図２はソフトウェアおよびモジュールＭの構成の例を示す図、図３は開発支援サーバ１のハードウェア構成の例を示す図、図４は開発支援サーバ１の機能的構成の例を示す図である。

本発明に係る製品開発システム１００は、図１に示すように、開発支援サーバ１、モジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、テスト管理サーバ２Ｃ、１台または複数台の端末装置３、および通信回線４などによって構成される。開発支援サーバ１、モジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、テスト管理サーバ２Ｃ、および端末装置３は通信回線４を介して互いに接続されている。通信回線４として、ＬＡＮ、インターネット、専用線、または公衆回線などが用いられる。

この製品開発システム１００は、様々な製品の開発のために用いられる。以下、ある印刷装置ＰＤ３を制御するためのソフトウェアの開発のために製品開発システム１００が用いられる場合を例に説明する。このソフトウェアは、図２に示すように、複数のモジュールＭ（Ｍ１、Ｍ２、…）によって構成される。さらに、各モジュールＭは、複数のソースプログラム（以下、単に「ソース」と記載する。）またはこれをコンパイルして生成された機械語プログラムによって構成される。

端末装置３は、Ｗｅｂブラウザおよび開発用ツールなどがインストールされているパーソナルまたはワークステーションであって、印刷装置ＰＤ３のハードウェアの設計およびソフトウェアのプログラミングなどの作業のために使用される。

モジュール管理サーバ２Ａは、製品開発におけるモジュール管理を行うためのＣＡＳＥ（Computer Aided Software Engineering）ツールがインストールされているコンピュータである。仕様書管理サーバ２Ｂは、印刷装置ＰＤ３などの製品の仕様書の管理を行うためのＣＡＳＥツールまたは文書管理ツール（グループウェアなど）がインストールされているコンピュータである。テスト管理サーバ２Ｃは、製品開発におけるテストを行うためのＣＡＳＥツールまたはテストの管理用のツールがインストールされているコンピュータである。これらのツールとして、市販のものを使用してもよいし、独自に作成したものを使用してもよい。

開発支援サーバ１は、図３に示すように、ＣＰＵ１ａ、ＲＡＭ１ｂ、ＲＯＭ１ｃ、磁気記憶装置（ハードディスク）１ｄ、および通信インタフェースなどの各種インタフェースなどによって構成される。

磁気記憶装置１ｄには、図４に示す画面表示処理部１０１、構成判別部１０２、障害情報等入力部１０３、テスト実行部１０４、関連機器判別部１０５、障害情報検索部１０６、モジュール情報受渡部１ＥＡ、仕様書情報受渡部１ＥＢ、テスト情報受渡部１ＥＣ、および障害情報管理部１ＳＫなどの機能を実行するためのプログラムおよびデータがインストールされている。これらのプログラムおよびデータは、必要に応じてＲＡＭ１ｂにロードされ、ＣＰＵ１ａによってプログラムが実行される。

なお、図１では開発支援サーバ１、モジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、およびテスト管理サーバ２Ｃをそれぞれ独立したサーバ機で実現している例を示しているが、これらの一部または全部を１〜３台のサーバ機で実現することも可能である。または、図４の各部を複数台のサーバ機に分散して実現することも可能である。

以下、図４の開発支援サーバ１の各部およびモジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、およびテスト管理サーバ２Ｃの処理内容などについて、詳細に説明する。

図５はモジュールデータベースＤＢＭの例を示す図、図６は履歴情報７３の例を示す図、図７は仕様書データベースＤＢＳの例を示す図、図８はテスト定義情報７６の例を示す図、図９は実施必須情報７７ｃの例を示す図、図１０は実施必須情報７７ｃを生成するための処理の流れの例を説明するフローチャート、図１１は実施必須情報７７ａ、７７ｂの例を示す図である。

モジュール管理サーバ２Ａは、モジュールＭ（Ｍ１、Ｍ２、…）ごとにモジュールデータベースＤＢＭ（ＤＢＭ１、ＤＢＭ２、…）を有しており、各モジュールＭのソースおよびその変更履歴などを管理している。例えば、モジュールＭ１のモジュールデータベースＤＢＭ１には、図５に示すような版数情報７０、構成情報７１、ソースファイル７２、履歴情報７３、および排他フラグ７４などが格納されている。各モジュールデータベースＤＢＭには、各々を区別するためのデータベース名が付されている。

版数情報７０は、そのモジュールＭ全体の版数に関する情報である。「版数」は、そのモジュールＭの版、バージョン、エディション、または世代を意味する。版数情報７０は、そのモジュールＭの内容が変更されるごとに更新される。本実施形態では、最初に出来上がった時点の版数を「第１版」とし、以降、バグを修正しまたは機能を改良するなどしてモジュールＭの内容が変更されるごとに「第２版」、「第３版」、…、と更新される。そのほか、版数情報７０には、そのモジュールＭが作成された日時（つまり、第１版が作成された日時）および版数が更新された日時を示す情報が含まれている。構成情報７１は、図２に示すような、そのモジュールＭのソースの構成を示している。

ソースファイル７２は、そのモジュールＭを構成するソースごとに設けられており、そのソースのソースコードが記録されている。ソースファイル７２は、ソースの内容が変更されるごとに更新される。

履歴情報７３は、図６に示すように、１つまたは複数のレコードからなり、そのモジュールＭを構成するソースごとに与えられている。レコードは、ソースの内容が変更されるごとに新たに生成される。ただし、「版数」が「第１版」であるレコードは、そのソースが生成され、それに伴って履歴情報７３が生成されたときに、生成される。

「版数」は、そのソースのバージョンなどを意味し、そのソースが変更されるごとに「第２版」、「第３版」、…、と順に付与される。例えば、図６の履歴情報７３の場合は、「第８版」までのレコードがあるので、これまでに７回の変更があったことが分かる。「変更日時」は、そのソースのソースファイル７２が変更された日付および時刻を示している。「担当者」は、変更の作業を行った開発スタッフを示している。

「変更内容」は、そのソースのソースファイル７２の内容がどのように更新（変更）されたのかを示している。つまり、更新後のソースファイル７２と更新前のソースファイル７２との差分情報である。

図５の排他フラグ７４は、そのソースのソースファイル７２の内容を変更してもよいか否かを示している。排他フラグ７４が「０」のときは、変更してもよいことを意味する。「１」のときは、変更の禁止を意味する。いずれか１人のユーザ（開発スタッフ）がそのソースファイル７２をオープンすると排他フラグ７４が「１」になり、クローズすると「０」になる。「１」の間は、他のユーザはソースファイル７２の内容を閲覧することはできるが、変更することはできない。つまり、排他制御が掛かる。

そのほか、モジュール管理サーバ２Ａは、印刷装置ＰＤ３にいずれのモジュールＭが使用されているのかを示す装置モジュール情報８０を有している。また、開発済みまたは開発中の他の製品の装置モジュール情報８０も有している。

仕様書管理サーバ２Ｂは、図７に示すような仕様書データベースＤＢＳを有しており、印刷装置ＰＤ３の仕様書Ｓ（Ｓ１、Ｓ２、…）に関する情報を管理している。仕様書データベースＤＢＳには、仕様書Ｓごとの仕様書データ７５ａおよび履歴情報７５ｂが格納されている。

仕様書データ７５ａは、印刷装置ＰＤ３の各モジュールＭの機能またはモジュールＭ同士の連携などに関する事項を示すテキストまたは図表などのデータである。履歴情報７５ｂは、仕様書データ７５ａの変更履歴を示している。履歴情報７５ｂは、図６に示すソースについての履歴情報７３のフォーマットと基本的に同じフォーマットを有しており、１つまたは複数のレコードからなる。つまり、履歴情報７５ｂの各レコードには、仕様書Ｓの版数、今回の変更内容（差分情報）、変更日時、および担当者などの情報が格納される。

テスト管理サーバ２Ｃは、図８に示すようなテスト定義情報７６および図９に示すようなテスト実施必須情報７７などを有しており、製品の開発中および開発後に実行するテストに関する情報を管理している。

テスト定義情報７６は、複数のレコードからなる。原則として、１つのテストに対して１つのレコードが与えられている。「テストＩＤ」は、そのテストを識別するための識別情報である。「テスト内容」は、そのテストの内容、例えば、テストの実施手順、テストの対象に該当するモジュールＭの識別情報、および期待される結果などを示すデータである。開発支援サーバ１または端末装置３によって自動に実施することができるテストの場合は、そのテストのプログラム（実行ファイル）が含まれる。

「版数」は、そのテストのバージョンなどを意味し、そのテストの内容が変更されるごとに「第２版」、「第３版」、…、と順に付与される。第２版以降のテストにも、１つずつレコードが与えられる。したがって、テストの内容が変更された場合は、その数に応じてそのテストのレコードが増えることになる。

実施必須情報７７は、製品を開発するにあたって、どのテストを実施する必要があるのかを示している。図９に示す実施必須情報７７ｃは、印刷装置ＰＤ３の実施必須情報７７である。「実施要否」の「要」の記号は、そのレコードに対応するテストを実施する必要があることを示している。

実施必須情報７７を、開発スタッフが各テストの実施の有無をすべて指定することによって用意してもよいが、全部または一部のテストの実施の有無を開発支援サーバ１またはテスト管理サーバ２Ｃに行わせることによって用意してもよい。この場合は、図１０のフローチャートに示すような手順で実施必須情報７７が生成される。

例えば、２種類の印刷装置ＰＤ１、ＰＤ２が既に製品化されており、開発フェーズにおいてそれぞれ図１１に示すような実施必須情報７７ａ、７７ｂに基づいてテストが実施されたとする。実施必須情報７７ａ、７７ｂのテストＩＤは、図９に示す印刷装置ＰＤ３の実施必須情報７７の場合と同様に、図８のテスト定義情報７６のテストＩＤに対応（リンク）している。そして、今から、印刷装置ＰＤ３の実施必須情報７７ｃを生成しようとしている。

図１０において、開発支援サーバ１は、印刷装置ＰＤ１、ＰＤ２の一方または両方で使用されるモジュールＭの中から、印刷装置ＰＤ３でも使用されるモジュールＭを、各装置の装置モジュール情報８０を参照することによって検索する（＃１０１）。テスト定義情報７６の中から、見つかったモジュールＭが実施対象であるテストを検索する（＃１０２）。つまり、印刷装置ＰＤ１またはＰＤ２の開発フェーズにおいて、そのモジュールＭの動作確認のために用いられたテストを検索する。

ステップ＃１０１、＃１０２の処理の結果、テストＩＤが「Ｔ００１」〜「Ｔ００５」である５つのテストが見つかったとする。これらのテストを、印刷装置ＰＤ３の開発に必要なテストとして指定する（＃１０５）。ただし、実施必須情報７７ａ、７７ｂを参照し、テストＩＤが「Ｔ００４」であるテストのように、版数が２つ以上あるテストが見つかった場合は、最新の版数のテストを必要なテストとして指定する（＃１０３でＹｅｓ、＃１０４）。

そして、印刷装置ＰＤ３で新たに追加されたモジュールＭに関するテスト、印刷装置ＰＤ１、ＰＤ２では実施しなかったテスト、およびその他必要なテストを追加指定する（＃１０６）。追加指定は、開発支援サーバ１が自動で行う場合と開発スタッフが判断して行う場合とがある。

このようにして、印刷装置ＰＤ３の開発に必要なテストが指定され、図９に示すような印刷装置ＰＤ３の実施必須情報７７ｃが生成される。

図１２は障害データベースＤＢＨの例を示す図、図１３はテスト結果テーブルＴＢ１の例を示す図、図１４は操作前の障害報告画面ＨＧ１の例を示す図、図１５は情報の入力などがなされた後の障害報告画面ＨＧ１の例を示す図、図１６はエディタ画面ＨＧ２の例を示す図、図１７は検索条件指定画面ＨＧ３の例を示す図である。

図４に戻って、開発支援サーバ１のモジュール情報受渡部１ＥＡ、仕様書情報受渡部１ＥＢ、およびテスト情報受渡部１ＥＣは、それぞれ、モジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、およびテスト管理サーバ２Ｃとの間で情報（データ）のやり取りを適宜行う。

障害情報管理部１ＳＫは、図１２に示すような障害データベースＤＢＨを有しており、開発中または開発後に発見した障害に関する情報を管理している。なお、図１２では、紙面の都合により、障害データベースＤＢＨを２つに分割して記載している。障害報告ＩＤが主キーであり、１、２段目の同じ障害報告ＩＤを有する行同士が１組になって１つのレコードをなしている。障害情報等入力部１０３は、端末装置２から送信されてきた情報を受信して受け付ける処理を行う。つまり、端末装置２からの情報の入力処理を行う。

開発スタッフは、自分の担当するモジュールＭの開発中に適宜、図８のテスト定義情報７６の「テスト内容」および図９の実施必須情報７７に従って必須のテストを実施し、障害が発生しないかどうかをチェックする。例えば、ジャム（紙詰まり）が起こった場合にその旨を示す信号を発信するモジュールＭを作成した場合は、実際にそのモジュールＭを印刷装置ＰＤ３にインストールしておき、わざとジャムを起こさせる。そして、期待される結果が得られるか否かつまり信号を発信か否かをチェックする。または、エミュレータに適用してチェックする。

通信プロトコルのテストのように、開発スタッフの手を介さずに自動で実施することができるテストの場合は、テスト実行部１０４がテスト定義情報７６の「テスト内容」に書かれているプログラムに従ってテストを行う。複数のテストを纏めて自動実行するようにしてもよい。または、一部または全部のテストを外部の装置（例えば、テスト管理サーバ２Ｃ）によって自動実行するようにしてもよい。

テストの結果は、図１３に示すように、テスト結果テーブルＴＢ１に格納される。テスト結果テーブルＴＢ１の内容は、テスト実行部１０４がテストを行った場合はその結果に応じて自動的に更新され、開発スタッフが行った場合は開発スタッフが所定の画面に結果を入力することによって更新される。

期待通りの結果が得られなかった場合つまり障害が発生した場合は、開発スタッフは、次のようにその障害についての報告を行う。まず、端末装置３を操作してＷｅｂブラウザまたは開発用ツールなどを起動させ、開発支援サーバ１にアクセスする。すると、端末装置３には、図１４に示すような障害報告画面ＨＧ１が表示される。この障害報告画面ＨＧ１を表示するための画面データは、画面表示処理部１０１によって端末装置３に送信される。後に説明する各画面を表示するための画面データも同様である。

ここで、開発スタッフは、障害に関する情報を入力する。まずは、テキストボックスＴＸ１０に、障害が発生した日時を入力する。何も入力しない場合は、現在の日時が入力されたものとして取り扱う。テキストボックスＴＸ１３には、実施したテストのテストＩＤを入力する。なお、テスト以外で発見された障害（例えば、開発後に消費者から報告を受けた障害）の場合は、入力する必要はない。

プルダウンメニューＭＮ１をクリックする。すると、製品開発システム１００で取り扱っている装置の一覧表が表示されるので、その中からテストを実施した装置を選択する。選択された装置は開発支援サーバ１に伝えられる。

開発スタッフは、プルダウンメニューＭＮ２をクリックする。すると、プルダウンメニューＭＮ１で選択された装置で使用されるモジュールＭの一覧表が表示されるので、その中から不具合があったモジュールＭを選択する。この一覧表は、その装置の装置モジュール情報８０に基づいて表示される。

プルダウンメニューＭＮ２で選択されたモジュールＭは、開発支援サーバ１に伝えられる。構成判別部１０２は、テキストボックスＴＸ１０に入力された日時または現在の日時におけるそのモジュールＭの構成要素（つまりソース）および各ソースの版数を、そのモジュールＭのモジュールデータベースＤＢＭ（図５参照）に格納されている構成情報７１および各ソースの履歴情報７３（図６参照）に基づいて判別する。さらに、版数情報７０に基づいてその日時におけるモジュールＭの版数を判別する。そのモジュールＭについて記載されている仕様書Ｓの、その日時の版数を、各仕様書Ｓの仕様書データ７５ａおよび履歴情報７５ｂ（図７参照）に基づいて判別する。関連機器判別部１０５は、そのモジュールＭを共通に使用している他の装置を、モジュール管理サーバ２Ａに記憶されている各装置モジュール情報８０に基づいて判別する。

構成判別部１０２による判別結果に基づいて、障害報告画面ＨＧ１の領域ＲＹ１には、図１５のように、プルダウンメニューＭＮ２で選択されたモジュールＭのソースの一覧が表示され、領域ＲＹ２には、そのモジュールＭについて記載されている仕様書Ｓの一覧が表示される。ソースまたは仕様書の名称の後の括弧書きは、ソースまたは仕様書の、テキストボックスＴＸ１０で指定された日時における版数を示している。表示ボックスＨＢ１には、そのモジュールＭのその日時における版数が表示される。また、関連機器判別部１０５による判別結果に基づいて、領域ＲＹ３には、そのモジュールＭを使用する他の装置の一覧が表示される。

これにより、開発スタッフは、障害が発生した時点でモジュールＭがどのようなソースによって構成されていたのかおよびそのモジュールＭがいずれの仕様書Ｓに基づいているのかの両方を１つの画面で容易に確認することができる。

さらに、開発スタッフは、不具合（障害の原因）があったソースまたは仕様書Ｓに対応するチェックボックスＣＢ１またはＣＢ２にチェックマークを入れて選択しておく。テキストボックスＴＸ１１およびＴＸ１２に、それぞれ、障害の内容および原因を入力する。テキストボックスＴＸ１４に、障害を取り除くために行った対策の内容を入力する。印刷装置ＰＤ３以外の装置の中で、今後の開発またはユーザサポートなどのために注意を要するものがあれば、領域ＲＹ３の中からそれに対応するチェックボックスＣＢ３にチェックマークを入れておく。

そして、更新ボタンＢＮ１２をクリックする。すると、端末装置３は、障害報告画面ＨＧ１で選択され、入力され、または表示された内容を障害報告情報７８として開発支援サーバ１に送信する。

開発支援サーバ１において、障害情報等入力部１０３が障害報告情報７８を受信すると、障害情報管理部１ＳＫは、新たなレコードを生成し、このレコードに対して障害ＩＤを発行する。そして、障害報告情報７８に示されるテストＩＤ、装置名、障害の日時、障害が起きたモジュール名およびその版数、仕様書名およびその版数、障害内容、原因、および関連装置に関する情報などを、そのレコードの各フィールドに格納する。これと並行して、テスト実行部１０４によってテストを行ったのではなければ、図１３のテスト結果テーブルＴＢ１のそのテストＩＤに対応する「結果」フィールドの値を「否」に更新する。

なお、障害報告画面ＨＧ１において、障害に関する項目のすべてに回答できないことがある。例えば、いずれのモジュールＭが原因で障害が発生しているのかを直ちに断定することができない場合は、プルダウンメニューＭＮ２からモジュールＭを選択することはできない。また、直ちに原因を特定することができない場合は、テキストボックスＴＸ１２への入力を行うことができない。このような場合は、最初は、障害が発生した時点で知り得る情報だけを入力しまたは選択すればよい。そして、分かり次第、順次、入力しまたは選択すればよい。このとき、図１２の、その障害に係るレコードの各フィールドには、順次、情報が格納されていくことになる。

開発スタッフは、障害についてのすべての項目に回答し、障害データベースＤＢＨのその障害のレコードを埋めることができたら、障害報告画面ＨＧ１の確定ボタンＢＮ１１をクリックする。すると、そのレコードの内容が責任者の端末装置３に通知される。責任者は、その内容を確認した後、その内容が正しいことを承認する旨を開発支援サーバ１に通知する。これにより、そのレコードの「承認フラグ」が「未承認」から「承認」に更新される。

障害についての報告の作業と並行して、開発スタッフは、障害が発生しなくなるようにモジュールＭまたは仕様書Ｓを修正する作業を行う。障害報告画面ＨＧ１の領域ＲＹ１の中から修正したいソースの名称の上をクリックして選択すると、図１６に示すエディタ画面ＨＧ２がその開発スタッフの端末装置３に表示される。テキストボックスＴＸ２１には、既定値として、そのソースのソースファイル７２の内容（ソースコード）が入力されている。なお、選択したソースの版数が最新版でない場合は、そのソースの履歴情報７３に基づいてソースファイル７２の内容がその版数の時点にまで復元され、これが既定値として入力される。

開発スタッフは、テキストボックスＴＸ２１のソースの内容を修正した後、テキストボックスＴＸ２２にそのソースの次の版数を入力し、テキストボックスＴＸ２３に自分の名前を入力する。そして、更新ボタンＢＮ２１をクリックすると、テキストボックスＴＸ２１〜ＴＸ２３の内容がソース更新情報７９ａとして開発支援サーバ１に送信される。

ただし、そのソースファイル７２に対応する排他フラグ７４が「１」である場合は、他の開発スタッフがそのソースファイル７２を使用しているので、排他制御される。したがって、ソースファイル７２を閲覧することはできるが、更新することはできない。この場合は、他の開発スタッフによるソースファイル７２の使用が終わって排他フラグ７４が「０」になるまで修正の作業を始めることはできない。

モジュール管理サーバ２Ａは、ソース更新情報７９ａを受信すると、そのソースの更新前のソースファイル７２の内容を、そのソース更新情報７９ａに含まれるソースコードに置き換えるとともに、そのソースの履歴情報７３（図６参照）に新規のレコードを作成し、このレコードに変更内容（つまり、更新前後の差分）、変更日時、版数、および担当者に関する情報を格納する。

開発スタッフは、他のソースについて修正する必要がある場合は、同様にして作業を繰り返せばよい。このようにして、不具合のあるモジュールＭを修正し、障害に対応することができる。

仕様書Ｓについても、モジュールＭの修正と同様に作業を行えばよい。すなわち、図１５の障害報告画面ＨＧ１の領域ＲＹ２の中から修正したい仕様書Ｓの名称の上をクリックすると、図１６のエディタ画面ＨＧ２と同様のエディタ画面が表示される。ここで、開発スタッフは、仕様書Ｓの内容を修正する。すると、修正内容などが仕様書更新情報７９ｂとして開発支援サーバ１に送信される。仕様書管理サーバ２Ｂは、仕様書更新情報７９ｂに基づいてその仕様書Ｓの仕様書データ７５ａおよび履歴情報７５ｂを更新する。

このようにして、開発スタッフは、モジュールＭまたは仕様書Ｓを修正し、障害が発生しないように対処することができる。

テスト実行部１０４によってテストを自動実行した場合は、障害データベースＤＢＨの各項目のうち必然的に分かる項目についての情報は自動入力される。例えば、テストの結果に基づいて障害の原因が自ずと分かる場合は、「原因」の項目（フィールド）にその原因の情報を自動入力する。

一方、テストの結果が期待通りであった場合は、テスト通過報告画面（図示しない）に、そのテストのテストＩＤを入力する。これにより、テスト結果テーブルＴＢ１のそのテストＩＤに対応する「結果」フィールドの値が「良」に更新される。また、モジュールＭまたは仕様書Ｓの修正後に再度テストを行い、期待通りの結果が得られた場合も、同様に、テスト通過報告画面にテストＩＤを入力する。

図１２の障害データベースＤＢＨに蓄積された障害に関する情報は、今後の印刷装置ＰＤ３または他機種の開発およびフィールドサービスやコールセンターでの顧客サポートのための資料として用いることができる。開発スタッフおよび顧客サポートの担当者は、次のようにして障害データベースＤＢＨの検索を行うことができる。

開発スタッフは、所定の操作を行って図１７に示すような検索条件指定画面ＨＧ３を自分の端末装置３に表示させる。項目リストＬＴ３１の中から検索のキーにする項目をクリックして選択する。すると、選択された項目に応じて選択肢リストＬＴ３２、範囲指定ボックスＴＸ３１、日付指定ボックスＴＸ３２、およびキーワード指定ボックスＴＸ３３のうちのいずれか１つのみが選択または入力が可能な状態（アクティブ）になり、残りの３つは選択および入力が不可能な状態（グレー表示）になる。

例えば、「装置名」が選択されると、選択肢リストＬＴ３２がアクティブになるとともに、残りの３つがグレー表示になる。このとき、選択肢リストＬＴ３２には、障害データベースＤＢＨの「装置名」のフィールドに格納されている装置名が一覧表示される。または、「モジュール版数」が選択されると、範囲指定ボックスＴＸ３１がアクティブになる。「発生日」が選択されると、日付指定ボックスＴＸ３２がアクティブになる。「障害内容」が選択されると、キーワード指定ボックスＴＸ３３がアクティブになる。

開発スタッフは、アクティブになったリストまたはテキストボックスに検索条件とする値（キー）を選択しまたは入力し、条件追加ボタンＢＮ３１をクリックする。すると、条件表示ボックスＨＢ３に、その検索条件が追加表示される。複数の項目をキーにしてＡＮＤ検索またはＯＲ検索を行いたい場合は、上に述べた操作を繰り返し行って条件表示ボックスＨＢ３に検索条件を追加するとともに、ボタン群ＲＢ３の中からＡＮＤ検索およびＯＲ検索のいずれかの検索方法に対応するボタンを選択しておく。そして、検索条件の追加および検索方法の選択が完了すると、検索実行ボタンＢＮ３２をクリックする。

すると、条件表示ボックスＨＢ３の内容およびボタン群ＲＢ３で選択された検索方法を示す情報が、検索条件設定情報８１として開発支援サーバ１に送信される。

図４の障害情報検索部１０６は、送信されてきた検索条件設定情報８１に基づいて、障害データベースＤＢＨの検索を行う。検索は、公知のデータベース検索の手法によって行えばよい。そして、端末装置３には、検索結果を示す画面が表示される。なお、検索条件設定情報８１を開発支援サーバ１または端末装置３にファイルとして保存しておき、再検索を行いたいときに呼び出すことができるようにしてもよい。

図１８は製品開発システム１００の全体の処理の流れの例を説明するフローチャート、図１９は新たなテストを登録する際に実行する処理の流れの例を説明するフローチャートである。

次に、製品開発システム１００の処理の流れを、印刷装置ＰＤ３用のソフトウェアを開発するために使用される場合を例に、フローチャートを参照して説明する。

図１８において、開発スタッフは、印刷装置ＰＤ３の仕様書Ｓを作成し、その仕様書に則してモジュールＭを作成する。製品開発システム１００は、これらの仕様書ＳおよびモジュールＭを、それぞれ、仕様書データベースＤＢＳ（図７参照）およびモジュールデータベースＤＢＭ（図５参照）に登録する（＃１）。

開発スタッフは、仕様書ＳおよびモジュールＭの作成と並行してまたは作成後に、開発中のソフトウェアに障害がないか否かを調べるためのテストの準備を行う（＃２）。このとき、製品開発システム１００は、図８のようなテスト定義情報７６を生成する。テスト定義情報７６の全部または一部を、前に図１０で説明したように、他の装置のテストで使用されたテストの中から必要なものを自動的に選択するようにしてもよい。

必要に応じて順次テストを実施する（＃３）。期待通りの結果が得られたテストについては（＃４でＮｏ）、そのテストの結果が「良」であるとテスト結果テーブルＴＢ１（図１３参照）に登録する（＃５）。

期待通りの結果が得られなかったテストについては（＃４でＹｅｓ）、開発スタッフからの報告に基づいて障害に関する情報を障害データベースＤＢＨ（図１２参照）に登録するとともに（＃６）、そのテストの結果が「否」であるとテスト結果テーブルＴＢ１に登録する（＃７）。開発スタッフが障害の原因をなくすために仕様書ＳまたはモジュールＭの内容を修正すると、製品開発システム１００は、その仕様書Ｓの仕様書データ７５ａおよび履歴情報７５ｂ（図７参照）を更新し、またはそのモジュールＭの版数情報７０および修正されたソースのソースファイル７２および履歴情報７３（図５参照）を更新する（＃８）。そして、再度テストを行い、期待通りの結果が得られた場合は、そのテストの結果が「良」であるとテスト結果テーブルＴＢ１に登録する（＃３、＃４でＮｏ、＃５）。

実施すべきすべてのテストが終了し、すべての結果が「良」となったら（＃９でＹｅｓ）、開発フェーズが終了する。

製品の開発フェーズの間または開発フェーズ後に、ステップ＃２で準備したテストでは発見することができなかった障害が発見されることがある。この場合は、その製品または関連製品のために、例えば図１９に示すような手順でその障害の有無をチェックする新たなテストを用意するのが望ましい。

開発スタッフは、新たなテストの実施手順を立案しまたはプログラムを作成する。製品開発システム１００は、新たなテストＩＤを発行し、そのテストの内容をテスト定義情報７６に登録する（図１９の＃２０１）。そのテストが開発中の製品のために必要であれば（＃２０２でＹｅｓ）、そのテストの「実施要否」の値が「要」になるように、その製品の実施必須情報７７（図９参照）を更新する。関連製品でも同じような障害が発生するおそれがある場合は（＃２０４Ｙｅｓ）、そのテストによってその障害の発生の有無を調べることができるのであれば（＃２０５でＹｅｓ）、その関連製品の実施必須情報７７を、そのテストの「実施要否」の値が「要」になるように更新する（＃２０６）。ほかにも新たなテストを追加登録した場合は（＃２０７でＹｅｓ）、そのテストについてステップ＃２０２〜＃２０６の処理を繰り返し行う。

本実施形態によると、製品の開発において複数のツールを使用した場合であっても、作業工数を抑え、かつ、ミスの発生を防止することができる。

また、複数の種類の製品同士で一部のテストに関する情報を共用することによって、テストのための作業工数を減らすことができる。図１０で説明した処理を行うことによって、開発済みの製品または開発中の製品について実施したテストに関する情報に基づいて、これから開発する製品についてどのテストを実施すべきかを容易に知得することができる。図１７の検索条件指定画面ＨＧ３によると、データベース同士の連携について知識が無いユーザであっても容易に情報の検索を行うことができる。

本実施形態では、本発明に係る製品開発システム１００をソフトウェアの開発のための使用する場合を例に説明したが、ソフトウェア以外の製品、例えばハードウェア製品などに使用することも可能である。

本実施形態では、開発支援サーバ１とモジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、およびテスト管理サーバ２Ｃとの連携を行う場合を例に説明したが、これ以外の組合せで連携を行うことも可能である。例えば、開発会議の議事録を管理するツールまたはハードウェアモジュールを管理するツールなどと連携を行ってもよい。

本実施形態では、複数の版数のあるテスト（図８の「テストＩＤ＝００４」参照）の場合は、最新のテストを採用したが、古いテストを参照するようにしてもよい。

製品開発システム１００を特開２００２−５５８１５号公報に記載されるような信頼性を評価するための装置（ソフトウェア開発支援装置）と連携させてもよい。これにより、本発明の製品開発システム１００によって得られた障害データベースＤＢＨ（図１２参照）などに蓄積された情報を、ソフトウェア開発支援装置によって解析し、開発中のソフトウェアの信頼性を評価して製品の品質を向上させることができる。

その他、製品開発システム１００、開発支援サーバ１、モジュール管理サーバ２Ａ、仕様書管理サーバ２Ｂ、テスト管理サーバ２Ｃの全体または各部の構成、処理内容、処理順序、データベースの構成などは、本発明の趣旨に沿って適宜変更することができる。
（付記１）製品の開発を支援するための製品開発支援システムであって、
前記製品の構成要素の指定を受け付ける指定受付手段と、
前記製品の構成要素ごとにその設計に関する設計情報を管理する第一のシステムから、前記指定に係る前記構成要素の所定の日時における前記設計情報を取得する設計情報取得手段と、
前記製品の仕様書に関する仕様書情報を管理する第二のシステムから、前記製品の前記所定の日時における前記仕様書情報を取得する仕様書情報取得手段と、
取得した前記所定の日時における前記設計情報と前記仕様書情報とを表示するための処理を実行する表示手段と、
を有することを特徴とする製品開発支援システム。
（付記２）前記第一のシステムは、前記製品の構成要素の設計の変更が行われた場合に、当該変更後の当該構成要素を当該変更前の当該構成要素と区別するための第一の識別情報を記憶し、
前記第二のシステムは、前記製品の仕様書の内容の変更が行われた場合に、当該変更後の当該仕様書を当該変更前の当該仕様書と区別するための第二の識別情報を記憶し、
前記設計情報取得手段は、前記設計情報として、前記第一の識別情報を取得し、
前記仕様書情報取得手段は、前記仕様書情報として、前記第二の識別情報を取得する、
付記１記載の製品開発支援システム。
（付記３）前記指定受付手段は、前記製品の構成要素とともに日時の指定を受け付け、
前記設計情報取得手段は、前記指定受付手段によって日時の指定が受け付けられた場合は当該日時における前記設計情報を前記所定の日時における前記設計情報として取得し、受け付けられなかった場合は最新の前記設計情報を前記所定の日時における前記設計情報として取得し、
前記仕様書情報取得手段は、前記指定受付手段によって日時の指定が受け付けられた場合は当該日時における前記仕様書情報を前記所定の日時における前記仕様書情報として取得し、受け付けられなかった場合は最新の前記仕様書情報を前記所定の日時における前記仕様書情報として取得する、
付記１または付記２記載の製品開発支援システム。
（付記４）前記製品の前記構成要素の障害に関する障害情報を記憶する障害情報記憶手段を有し、
前記表示手段は、前記構成要素の前記障害情報を入力するための入力フォームを、前記所定の日時における当該構成要素の前記設計情報および前記仕様書情報とともに表示するように処理を実行し、
前記障害情報記憶手段は、前記入力フォームで入力された前記障害情報を記憶する、
付記１ないし付記３のいずれかに記載の製品開発支援システム。
（付記５）前記製品の障害の有無を判別するテストを実施するためのテスト実施手段と、
前記テストごとの実施結果を記憶する実施結果記憶手段と、を有し、
前記表示手段は、障害が生じた前記テストの識別情報を入力するための入力領域が設けられた前記入力フォームを表示するように処理を実行し、
前記実施結果記憶手段は、前記入力領域に入力された前記テストの識別情報に基づいて当該テストの前記実施結果を記憶する、
付記４記載の製品開発支援システム。
（付記６）製品の障害の有無を判別するためのテストの実施を支援する製品テスト支援システムであって、
前記テストごとに、当該テストの内容に関するテスト情報を記憶するテスト情報記憶手段と、
製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を記憶する実施必須情報記憶手段と、
障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と前記テスト情報記憶手段に記憶されている前記各テスト情報とに基づいて生成する実施必須情報生成手段と、
を有することを特徴とする製品テスト支援システム。
（付記７）前記テスト情報記憶手段は、前記テストの内容の変更が行われた場合は、当該テストの当該変更前の前記テスト情報および当該変更後の前記テスト情報の両方を記憶し、
前記実施必須情報生成手段は、実施すべき前記テストの前記テスト情報が前記実施必須情報記憶手段に複数記憶されている場合は、当該テスト情報のうちの最新のものに基づいて当該テストを実施すべきであることを示す前記実施必須情報を生成する、
付記６記載の製品テスト支援システム。
（付記８）前記実施必須情報記憶手段は、新規の前記テストの前記テスト情報が前記テスト情報記憶手段に追加された場合に、当該実施必須情報記憶手段が記憶している前記各実施必須情報のうちの、当該新規の前記テストの実施が必要な前記製品の前記実施必須情報を、当該テストを実施すべきであることを示すように更新する、
付記６または付記７記載の製品テスト支援システム。
（付記９）前記テストをコンピュータプログラムに基づいて実施するテスト実施手段を有し、
全部または一部の前記テストの前記テスト情報には、当該テストを実施するためのコンピュータプログラムが含まれており、
前記テスト実施手段は、全部または一部の前記テストを、当該テストの前記テスト情報に基づいて実施する、
付記６ないし付記８のいずれかに記載の製品テスト支援システム。
（付記１０）製品の開発を支援するための製品開発支援方法であって、
前記製品の構成要素の指定を受け付けるステップと、
前記製品の構成要素ごとにその設計に関する設計情報を管理する第一のシステムから、前記指定に係る前記構成要素の所定の日時における前記設計情報を取得するステップと、
前記製品の仕様書に関する仕様書情報を管理する第二のシステムから、前記製品の前記所定の日時における前記仕様書情報を取得するステップと、
取得した前記所定の日時における前記設計情報と前記仕様書情報とを表示するための処理を実行するステップと、
を有することを特徴とする製品開発支援方法。
（付記１１）製品の開発を支援するためのコンピュータに用いられるコンピュータプログラムであって、
前記製品の構成要素の指定を受け付けるステップと、
前記製品の構成要素ごとにその設計に関する設計情報を管理する第一のシステムから、前記指定に係る前記構成要素の所定の日時における前記設計情報を取得する処理と、
前記製品の仕様書に関する仕様書情報を管理する第二のシステムから、前記製品の前記所定の日時における前記仕様書情報を取得する処理と、
取得した前記所定の日時における前記設計情報と前記仕様書情報とを表示するための処理と、
をコンピュータに実行させるためのコンピュータプログラム。
（付記１２）製品の障害の有無を判別するためのテストの実施を支援する製品テスト支援方法であって、
前記テストごとに、当該テストの内容に関するテスト情報をテスト情報記憶手段に記憶させておき、製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を実施必須情報記憶手段に記憶させておき、
障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と前記テスト情報記憶手段に記憶されている前記各テスト情報とに基づいて生成する、
ことを特徴とする製品テスト支援方法。
（付記１３）製品の障害の有無を判別するためのテストの実施を支援する製品テスト支援システムであって、
前記テストごとに、当該テストの内容に関するテスト情報をテスト情報記憶手段に記憶させる処理と、
製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を実施必須情報記憶手段に記憶させる処理と、
障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と前記テスト情報記憶手段に記憶されている前記各テスト情報とに基づいて生成する処理と、
をコンピュータに実行させるためのコンピュータプログラム。

本発明は、上に述べたように、各作業工程で発生する情報を上手く管理することによって、作業効率を向上させるとともにミスの発生を防止する。特に、製品開発の作業工程が多い場合において、好適に用いられる。

製品開発システムの全体的な構成の例を示す図である。 ソフトウェアおよびモジュールの構成の例を示す図である。 開発支援サーバのハードウェア構成の例を示す図である。 開発支援サーバの機能的構成の例を示す図である。 モジュールデータベースの例を示す図である。 履歴情報の例を示す図である。 仕様書データベースの例を示す図である。 テスト定義情報の例を示す図である。 実施必須情報の例を示す図である。 実施必須情報を生成するための処理の流れの例を説明するフローチャートである。 実施必須情報の例を示す図である。 障害データベースの例を示す図である。 テスト結果テーブルの例を示す図である。 操作前の障害報告画面の例を示す図である。 情報の入力などがなされた後の障害報告画面の例を示す図である。 エディタ画面の例を示す図である。 検索条件指定画面の例を示す図である。 製品開発システムの全体の処理の流れの例を説明するフローチャートである。 新たなテストを登録する際に実行する処理の流れの例を説明するフローチャートである。

符号の説明

１ 開発支援サーバ（製品開発支援システム、製品テスト支援システム）
２Ａ モジュール管理サーバ（第一のシステム）
２Ｂ 仕様書管理サーバ（第二のシステム）
２Ｃ テスト管理サーバ（テスト情報記憶手段、実施必須情報記憶手段）
１０１ 画面表示処理部（表示手段）
１０３ 障害情報等入力部（指定受付手段）
１ＥＡ モジュール情報受渡部（設計情報取得手段）
１ＥＢ 仕様書情報受渡部（仕様書情報取得手段）
１ＥＣ テスト情報受渡部（テスト情報取得手段）
Ｍ モジュール（構成要素）
ＰＤ３ 印刷装置（製品）
Ｓ 仕様書

Claims (6)

1. 製品の障害の有無を判別するためのテストの実施を支援する製品テスト支援システムであって、
   前記テストごとに、当該テストの内容に関するテスト情報を記憶するテスト情報記憶手段と、
   製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を記憶する実施必須情報記憶手段と、
   障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と、前記テスト情報記憶手段に記憶されている前記テスト情報であって当該実施必須情報が示す実施すべきテストに関する前記各テスト情報のうちの当該テストの実施対象である構成要素を示す情報とに基づいて生成する実施必須情報生成手段と、
   を有することを特徴とする製品テスト支援システム。
2. 前記テスト情報記憶手段は、前記テストの内容の変更が行われた場合は、当該テストの当該変更前の前記テスト情報および当該変更後の前記テスト情報の両方を記憶し、
   前記実施必須情報生成手段は、実施すべき前記テストの前記テスト情報が前記実施必須情報記憶手段に複数記憶されている場合は、当該テスト情報のうちの最新のものに基づいて当該テストを実施すべきであることを示す前記実施必須情報を生成する、
   請求項１記載の製品テスト支援システム。
3. 前記実施必須情報記憶手段は、新規の前記テストの前記テスト情報が前記テスト情報記憶手段に追加された場合に、当該実施必須情報記憶手段が記憶している前記各実施必須情報のうちの、当該新規の前記テストの実施が必要な前記製品の前記実施必須情報を、当該テストを実施すべきであることを示すように更新する、
   請求項１または請求項２記載の製品テスト支援システム。
4. 前記テストをコンピュータプログラムに基づいて実施するテスト実施手段を有し、
   全部または一部の前記テストの前記テスト情報には、当該テストを実施するためのコンピュータプログラムが含まれており、
   前記テスト実施手段は、全部または一部の前記テストを、当該テストの前記テスト情報に基づいて実施する、
   請求項１ないし請求項３のいずれかに記載の製品テスト支援システム。
5. 製品の障害の有無を判別するためのテストの実施を支援する製品テスト支援方法であって、
   前記テストごとに、当該テストの内容に関するテスト情報を記憶するテスト情報記憶手段と、製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を記憶する実施必須情報記憶手段と、実施必須情報生成手段と、を備える製品テスト支援システムが、
   前記実施必須情報生成手段によって、
   障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と、前記テスト情報記憶手段に記憶されている前記テスト情報であって当該実施必須情報が示す実施すべきテストに関する前記各テスト情報のうちの当該テストの実施対象である構成要素を示す情報とに基づいて生成する
   ことを特徴とする製品テスト支援方法。
6. 製品の障害の有無を判別するためのテストの実施を支援するためのコンピュータに用いられるコンピュータプログラムであって、
   前記コンピュータに、
   前記テストごとに、当該テストの内容に関するテスト情報をテスト情報記憶手段に記憶させる処理と、
   製品ごとに、前記テストのうちのいずれを実施すべきかを示す実施必須情報を実施必須情報記憶手段に記憶させる処理と、
   障害の有無を判別したい製品の前記実施必須情報を、当該製品のいずれか１つまたは複数の構成要素と同じ構成要素を有する他の製品の前記実施必須情報記憶手段に記憶されている前記実施必須情報と、前記テスト情報記憶手段に記憶されている前記テスト情報であって当該実施必須情報が示す実施すべきテストに関する前記各テスト情報のうちの当該テストの実施対象である構成要素を示す情報とに基づいて生成する処理と、
   を実行させるためのコンピュータプログラム。

Images