JP2008003985A - 開発支援システム、開発支援方法および開発支援プログラム - Google Patents

Abstract

【課題】修正後に実施すべきテストケースを必要最小限の範囲で抽出する。
【解決手段】開発支援システムにおいて、影響範囲管理データベースを予め作成して記憶しておく。影響範囲管理データベースには、「要求」（または「プログラム」）ごとに、当該要求（またはプログラム）が修正された場合に影響がある範囲を格納する。すなわち、「要求」と、当該要求が修正された場合に修正する必要があるプログラムと、修正後に実施しなければならないテストケースとを関連付ける。また、「プログラム」と、当該プログラムが修正された場合に実施しなければならないテストケースとを関連付ける。例えば、障害が発生してプログラムの修正が指示されたときに、修正される「プログラム」を特定し、当該「プログラム」の影響範囲を影響範囲管理データベースから取得して、取得した影響範囲に含まれるテストケースのみを、再動作試験として実施する。
【選択図】図１１

Description

本発明は、プログラムの開発を支援する技術に関する。

プログラムを開発する工程では、作成したプログラムが正常に動作するか否かを確認するために、様々な動作試験が行われる。すなわち、プログラムの開発においては、様々な動作試験を行うことにより、プログラムの不具合（バグ）を検出しては、これを修正する作業が繰り返し行われる。

そして、動作試験における試験の内容（例えばプログラムに与える条件等）は、１つ１つの動作試験に対応した「テストケース」を作成することによって定められる。言い換えれば、複数のテストケースに従ってプログラムの動作試験をそれぞれ行い、全てのテストケースにおいて、動作試験の結果が良好であれば、当該プログラムを合格とする。

一方、通常のプログラム（メインプログラム）は、複数のプログラム（関数プログラム）の集合体として開発される。すなわち、テストケースに従ってメインプログラムの不具合を検出した場合、検出した不具合に応じて、関数プログラム（１つまたは複数）の修正作業が行われる。その後、再度、テストケースに従ってメインプログラムの動作試験（再動作試験）を行い、検出された不具合が治癒したか否かを確認する。

特開２００２−２０７６１５号公報

ところが、１つのプログラムに対して、通常、複数のテストケースが定められているため、不具合が検出されたテストケースにおいて当該不具合が治癒していても、他のテストケース（例えば、すでに結果が良好であったテストケース）において、新たな不具合が発生する場合もある。すなわち、プログラムを修正したことによる影響は、複数のテストケースに及ぶ場合があるため、不具合を検出したテストケースについてのみ、再動作試験を実施しただけでは不十分な場合がある。

しかし、障害が発生した場合に、当該障害に応じて修正される関数プログラムの組合せは様々であり、複数のテストケースから影響のあるテストケースのみを抽出することは困難である。一方で、１つのメインプログラムに対して定められるテストケースは膨大であり、障害が発生するたびに、これを全てやりなおすことは非効率的である。

本発明は、上記課題に鑑みなされたものであり、プログラム等の修正後に実施すべきテストケースを必要最小限の範囲で抽出することを目的とする。

上記の課題を解決するため、請求項１の発明は、プログラムの開発を支援する開発支援システムであって、オペレータの指示入力を受け付ける入力部と、前記入力部が受け付けた指示入力に基づいて、プログラムごとに当該プログラムの影響範囲を予め保存しておく影響範囲管理部と、前記入力部が受け付けたプログラム修正を指示する指示入力に基づいて、前記プログラム修正を指示する指示入力から修正対象プログラムを特定し、前記影響範囲管理部に保存されているプログラムの影響範囲の中から、前記修正対象プログラムの影響範囲を取得する取得部と、前記取得部によって取得された修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が前記修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定する特定部とを備えることを特徴とする。

また、請求項２の発明は、請求項１の発明に係る開発支援システムであって、前記影響範囲管理部は、前記入力部が受け付けた指示入力に基づいて、プログラムに対する要求ごとに当該要求の影響範囲を予め保存しておき、前記取得部は、前記入力部が受け付けた要求修正をを指示する指示入力に基づいて、前記要求修正を指示する指示入力から修正対象要求を特定し、前記影響範囲管理部に保存されている要求の影響範囲の中から、前記修正対象要求の影響範囲を取得し、前記取得部によって取得された修正対象要求の影響範囲に基づいて、前記要求修正を指示する指示入力に基づく修正が前記修正対象要求について完了した後に実施すべきテストケースを影響テストケースとして特定することを特徴とする。

また、請求項３の発明は、プログラムの開発を支援する開発支援システムであって、オペレータの指示入力を受け付ける入力部と、前記入力部が受け付けた指示入力に基づいて、プログラムに対する要求ごとに当該要求の影響範囲を予め保存しておく影響範囲管理部と、前記入力部が受け付けた要求修正を指示する指示入力に基づいて、前記要求修正を指示する指示入力から修正対象要求を特定し、前記影響範囲管理部に保存されている要求の影響範囲の中から、前記修正対象要求の影響範囲を取得する取得部と、前記取得部によって取得された修正対象要求の影響範囲に基づいて、前記要求修正を指示する指示入力に基づく修正が前記修正対象要求について完了した後に実施すべきテストケースを影響テストケースとして特定する特定部とを備えることを特徴とする。

また、請求項４の発明は、請求項２または３の発明に係る開発支援システムであって、要求の影響範囲には、前記要求を修正することにより修正が必要となるプログラムが示されていることを特徴とする。

また、請求項５の発明は、請求項１ないし４のいずれかの発明に係る開発支援システムであって、前記入力部は、前記修正対象プログラムに対する修正が完了したことを示す修正済み情報を受け付け、前記修正済み情報に基づいて、前記影響テストケースが実施可能であるか否かを判定することを特徴とする。

また、請求項６の発明は、プログラムの開発を支援する開発支援方法であって、オペレータの指示入力を受け付ける入力工程と、前記入力工程において受け付けた指示入力に基づいて、プログラムごとに当該プログラムの影響範囲を予め保存しておく影響範囲保存工程と、前記入力工程において受け付けたプログラム修正を指示する指示入力に基づいて、前記プログラム修正を指示する指示入力から修正対象プログラムを特定し、前記影響範囲管理部に保存されているプログラムの影響範囲の中から、前記修正対象プログラムの影響範囲を取得する取得工程と、前記取得工程において取得された修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が前記修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定する特定工程とを備えることを特徴とする。

また、請求項７の発明は、コンピュータ読み取り可能な開発支援プロクラムであって、前記開発支援プログラムの前記コンピュータによる実行は、前記コンピュータに、オペレータの指示入力を受け付ける入力工程と、前記入力工程において受け付けた指示入力に基づいて、プログラムごとに当該プログラムの影響範囲を予め保存しておく影響範囲保存工程と、前記入力工程において受け付けたプログラム修正を指示する指示入力に基づいて、前記プログラム修正を指示する指示入力から修正対象プログラムを特定し、前記影響範囲管理部に保存されているプログラムの影響範囲の中から、前記修正対象プログラムの影響範囲を取得する取得工程と、前記取得工程において取得された修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が前記修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定する特定工程とを実行させることを特徴とする。

請求項１および２および４ないし７に記載の発明では、プログラムごとに当該プログラムの影響範囲を予め保存しておき、修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定することにより、プログラムの修正がされたときに、当該修正によって必要となるテストケースを容易に確認できる。したがって、プログラムに対して漏れのないテストを実施することができ、品質のよいプログラム開発が行える。

請求項３に記載の発明では、入力部が受け付けた指示入力に基づいて、プログラムに対する要求ごとに当該要求の影響範囲を予め保存しておき、修正対象要求の影響範囲に基づいて、要求修正を指示する指示入力に基づく修正が修正対象要求について完了した後に実施すべきテストケースを影響テストケースとして特定することにより、要求の修正がされたときに、当該修正によって必要となるテストケースを容易に確認できる。したがって、漏れのないテストを実施することができ、品質のよいプログラム開発が行える。

請求項４に記載の発明では、要求の影響範囲には、要求を修正することにより修正が必要となるプログラムが示されていることにより、要求の修正がされたときに、当該要求の修正によって修正が必要となるプログラムを容易に確認できる。したがって、修正が必要なプログラムを適切に修正できる。

請求項５に記載の発明では、修正対象プログラムに対する修正が完了したことを示す修正済み情報を受け付け、修正済み情報に基づいて、影響テストケースが実施可能であるか否かを判定することにより、修正後の動作確認が実施できるか否かを容易に判定できる。

以下、本発明の好適な実施の形態について、添付の図面を参照しつつ、詳細に説明する。

＜１． 第１の実施の形態＞
図１は、本発明に係る開発支援システム１を示す図である。図１に示す管理・設計部門とは、開発支援システム１において開発（生産）するプログラム（以下、「製品プログラム」と称する）を設計し、当該製品プログラムに関する様々な情報を管理する部門であり、管理装置２が配置される。また、プログラミング部門とは、製品プログラムを実際に制作する部門であり、プログラミング装置３が配置される。さらに、評価部門とは、プログラミングされた製品プログラムに対する動作試験（および再動作試験）を行うことにより当該製品プログラムの評価を行う部門であって、評価装置４が配置される。

すなわち、開発支援システム１は、主に管理装置２、プログラミング装置３および評価装置４から構成され、これらが互いにネットワーク９０によってデータ通信可能な状態で接続された構造を有している。なお、管理装置２や評価装置４は、複数の装置により実現されてもよい。また、プログラミング装置３は、２台に限定されるものではなく、１台であってもよいし、さらに多くのプログラミング装置３が配置されていてもよい。

図２は、管理装置２の構成を示す図である。

管理装置２は、ＣＰＵ２１、記憶部２２、入力部２６、表示部２７および通信部２８を備え、一般的なパーソナルコンピュータとしての機能を有する。詳細は後述するが、管理装置２は、主に管理者および設計者によって操作され、製品プログラムに関する情報を一元的に管理するために使用される。

ＣＰＵ２１は、各種データの演算を行って、管理装置２の各構成を制御する。記憶部２２は、主にプログラム２３０を記憶するＲＯＭ２３、ＣＰＵ２１の一時的なワーキングエリアとして使用されるＲＡＭ２４、および比較的大容量のデータを長期的に記憶するハードディスク２５を備える。

図３は、管理装置２の機能ブロックを示す図である。図３に示すデータベース管理部２１０が、ハードディスク２５に記憶された各種データベースを管理するため、主にＣＰＵ２１がプログラム２３０に従って動作することにより実現される機能ブロックである。

データベース管理部２１０について説明する前に、まず、管理装置２のハードディスク２５に記憶される各種データベースについて説明する。

ハードディスク２５には、図３に示すように、要求管理データベース２５０、プログラム管理データベース２５１、テストケース管理データベース２５２、影響範囲管理データベース２５３および障害管理データベース２５４が記憶される。

要求管理データベース２５０は、個々の「要求」を識別する識別子（以下、「要求ＩＤ」と称する）と、当該要求ＩＤによって識別される要求に関する情報とを関連付けて保存するためのデータベースである。すなわち、要求管理データベース２５０を構成する各レコードは、要求ごとに設けられており、これらのレコードに格納される情報は要求ＩＤを用いて検索することが可能である。要求管理データベース２５０には、製品プログラムについて作成されるすべての要求が登録される。

なお、要求とは、製品プログラムに対する要求（仕様等）であり、プログラム管理の上位に位置する概念である。具体的には、件名、概要説明、詳細記述、開発ステータス、進捗状況等を含むが詳細は後述する。

プログラム管理データベース２５１は、個々の「関数プログラム」を識別する識別子（以下、「プログラムＩＤ」と称する）と、当該プログラムＩＤによって識別される関数プログラムに関する情報とを関連付けて保存するためのデータベースである。すなわち、プログラム管理データベース２５１を構成する各レコードは、関数プログラムごとに設けられており、これらのレコードに格納される情報はプログラムＩＤを用いて検索することが可能である。プログラム管理データベース２５１には、製品プログラムについて作成されるすべての関数プログラムが登録される。

なお、関数プログラムとは、製品プログラムを構成する複数の関数に対応するプログラムである。以下の説明において、関数プログラムを単にプログラムと略する場合がある。また、関数プログラムに関する情報とは、具体的には、プログラムカテゴリ、プログラム項目名、プログラム内容等を含むが詳細は後述する。

テストケース管理データベース２５２は、個々の「テストケース」を識別する識別子（以下、「テストケースＩＤ」と称する）と、当該テストケースＩＤによって識別されるテストケースに関する情報とを関連付けて保存するためのデータベースである。すなわち、テストケース管理データベース２５２を構成する各レコードは、テストケースごとに設けられており、これらのレコードに格納される情報はテストケースＩＤを用いて検索することが可能である。テストケース管理データベース２５２には、製品プログラムについて作成されるすべてのテストケースが登録される。

なお、テストケースとは、製品プログラム（または関数プログラム）を検査するための動作試験を規定するものである。また、テストケースに関する情報とは、具体的には、テストカテゴリ、テスト項目名、テスト内容、作成者等を含むが詳細は後述する。

影響範囲管理データベース２５３は、「プログラムＩＤ」と、当該プログラムＩＤによって識別される関数プログラムの影響範囲とを関連付けて保存するためのデータベースである。また、影響範囲管理データベース２５３は、「要求ＩＤ」と、当該要求ＩＤによって識別される要求の影響範囲とを関連付けて保存する。

すなわち、影響範囲管理データベース２５３を構成する各レコードは、関数プログラムおよび要求ごとに設けられており、これらのレコードに格納される情報はプログラムＩＤおよび要求ＩＤを用いて検索することが可能である。

なお、関数プログラムの影響範囲とは、当該関数プログラムについての修正が影響を及ぼす範囲であり、具体的には、当該関数プログラムが修正された場合に、実施しなければならないテストケース（以下、「影響テストケース」と称する）である。また、要求の影響範囲とは、当該要求についての修正が影響を及ぼす範囲であり、具体的には、当該要求が修正された場合に、修正されなければならない関数プログラムと、実施しなければならないテストケースとである。

障害管理データベース２５４は、個々の「障害」を識別する識別子（以下、「障害ＩＤ」と称する）と、当該障害ＩＤによって識別される障害に関する情報とを関連付けて保存するためのデータベースである。すなわち、障害管理データベース２５４を構成する各レコードは、障害ごとに設けられており、これらのレコードに格納される情報は障害ＩＤを用いて検索することが可能である。

なお、ここに言う障害とは、テストケースに従って製品プログラム（または関数プログラム）の動作試験を行ったときに発生するものである。また、障害に関する情報とは、具体的には、障害項目名、障害内容、発見テストケースＩＤ（当該障害を発見したテストケースのテストケースＩＤ）、発見者、重要度等を含むが詳細は後述する。

データベース管理部２１０は、登録情報２４０に示されるデータベースＩＤに基づいて、当該データベースＩＤによって識別されるデータベースに新しいレコードを作成する。さらに、作成した新たなレコードに登録情報２４０に示される各種情報を格納することによって、当該データベースに登録情報２４０を登録する。

なお、データベースＩＤとは、ハードディスク２５に記憶されているデータベース（要求管理データベース２５０、プログラム管理データベース２５１、テストケース管理データベース２５２、影響範囲管理データベース２５３および障害管理データベース２５４）を個々に識別する識別子である。

また、データベース管理部２１０は、更新情報２４１に示されるデータベースＩＤに基づいて、当該データベースＩＤによって識別されるデータベースを更新する。より詳しくは、すでに当該データベースに登録されているレコードに格納されている情報を、当該更新情報２４１に含まれる情報によって書き換える。

さらに、データベース管理部２１０は、閲覧要求（図示せず）に基づいて、閲覧情報２４２を生成する。閲覧要求には、閲覧を要求した要求元を示す識別子（以下、「要求元ＩＤ」と称する）と、閲覧を要求するデータベースを示すデータベースＩＤと、当該データベースＩＤによって識別されるデータベースのレコードを示す識別子（以下、「閲覧レコードＩＤ」と称する）とが含まれる。

データベース管理部２１０は、閲覧要求に含まれるデータベースＩＤと、閲覧レコードＩＤとに基づいて、当該データベースＩＤによって識別されるデータベースを検索する。そして、閲覧レコードＩＤによって識別される当該データベースのレコードに格納されている情報を抽出して、閲覧情報２４２を生成する。

このようにして生成される閲覧情報２４２には、データベースに格納されている情報のうち、閲覧要求によって閲覧を要求された情報と、閲覧を要求した要求元ＩＤ（閲覧情報２４２の伝達先を示す情報となる）とが含まれる。すなわち、データベース管理部２１０は、ハードディスク２５に記憶されている各データベースの検索エンジンとしての機能を有している。

なお、本実施の形態における開発支援システム１では、要求元ＩＤとは、管理装置２、プログラミング装置３または評価装置４を識別する情報となる。また、閲覧レコードＩＤは、閲覧を要求する情報が格納されているデータベースごとに異なる情報であり、例えば、要求ＩＤ、プログラムＩＤ、テストケースＩＤあるいは障害ＩＤ等である。

また、登録情報２４０、更新情報２４１および閲覧要求は、入力部２６から取得されるだけでなく、通信部２８を介してプログラミング装置３や評価装置４から取得される場合もある。同様に、閲覧情報２４２は、表示部２７に表示されるだけでなく、通信部２８を介してプログラミング装置３や評価装置４に送信される場合もある。

図２に戻って、入力部２６は、キーボードやマウス等から構成され、オペレータによって操作されることによって、オペレータからの様々な指示や情報を受け付ける。

表示部２７は、一般的なディスプレイであって、各種データを画面に表示する。特に、表示部２７は、閲覧情報２４２を表示する。

通信部２８は、管理装置２をネットワーク９０に接続する機能を有する。これにより、管理装置２は、プログラミング装置３および評価装置４との間でデータ通信を行うことができる。

図４は、プログラミング装置３の構成を示す図である。プログラミング装置３は、主にプログラマによって操作され、製品プログラム（関数プログラム）を制作するために使用されるとともに、プログラム情報３４０を入力するためにも使用される。なお、プログラム情報３４０は、プログラムＩＤと、当該プログラムＩＤによって識別される関数プログラムに関する情報とを含む。

プログラミング装置３は、ＣＰＵ３１、記憶部３２、入力部３６、表示部３７および通信部３８を備え、一般的なパーソナルコンピュータとしての機能を有する。なお、詳細は図示しないが、プログラミング装置３は、製品プログラム（関数プログラム）を作成するためのツール（エディタ、コンパイラ、リンカおよびデバッガ等）を有している。

ＣＰＵ３１は、各種データの演算を行って、プログラミング装置３の各構成を制御する。記憶部３２は、主にプログラム３３０を記憶するＲＯＭ３３、ＣＰＵ３１の一時的なワーキングエリアとして使用されるＲＡＭ３４、および比較的大容量のデータを長期的に記憶するハードディスク３５を備える。ハードディスク３５には、例えば、プログラマが制作した関数プログラム等が保存される。

入力部３６は、キーボードやマウス等から構成され、オペレータ（プログラマ）によって操作されることによって、オペレータからの様々な指示や情報を受け付ける。特に、オペレータは、入力部３６を操作することにより、プログラム情報３４０を入力する。

表示部３７は、一般的なディスプレイであって、各種データを画面に表示する。特に、表示部３７は、閲覧情報２４２を表示する。表示部３７に表示される閲覧情報２４２としては、例えば、関数プログラムに対する修正を指示する情報等が考えられる。

通信部３８は、プログラミング装置３をネットワーク９０に接続する機能を有する。これにより、プログラミング装置３は、管理装置２および評価装置４との間でデータ通信を行うことができる。

図５は、評価装置４の構成を示す図である。評価装置４は、主に試験者によって操作され、製品プログラム（関数プログラム）に対するテストケースを実施するために使用されるとともに、評価情報４４０を入力するためにも使用される。なお、評価情報４４０は、テストケースＩＤと、当該テストケースＩＤによって識別されるテストケースを実施した際の結果に関する情報とを含む。

評価装置４は、ＣＰＵ４１、記憶部４２、入力部４６、表示部４７および通信部４８を備え、一般的なパーソナルコンピュータとしての機能を有する。なお、詳細は図示しないが、評価装置４は、製品プログラム（関数プログラム）の動作試験に必要な構成（例えば、製品プログラムが動作する装置）を有している。

ＣＰＵ４１は、各種データの演算を行って、評価装置４の各構成を制御する。記憶部４２は、主にプログラム４３０を記憶するＲＯＭ４３、ＣＰＵ４１の一時的なワーキングエリアとして使用されるＲＡＭ４４、および比較的大容量のデータを長期的に記憶するハードディスク４５を備える。

入力部４６は、キーボードやマウス等から構成され、オペレータ（試験者）によって操作されることによって、オペレータからの様々な指示や情報を受け付ける。特に、オペレータは、入力部４６を操作することにより、評価情報４４０を入力する。

表示部４７は、一般的なディスプレイであって、各種データを画面に表示する。特に、表示部４７は、閲覧情報２４２を表示する。表示部４７に表示される閲覧情報２４２としては、例えば、テストケースの一覧表等が考えられる。

通信部４８は、評価装置４をネットワーク９０に接続する機能を有する。これにより、評価装置４は、管理装置２およびプログラミング装置３との間でデータ通信を行うことができる。

以上が、本実施の形態における開発支援システム１の構成および機能の説明である。

次に、開発支援システム１の動作について説明する。

図６は、管理装置２のデータベースに情報を登録する動作を簡略的に示す流れ図である。

登録処理が開始されると、まず、オペレータによって入力される情報（入力情報）を受け付け（ステップＳ１）、入力が終了するまでステップＳ１を繰り返す（ステップＳ２）。なお、入力情報の受付は、入力部２６，３６，４６のいずれかによって行われる。

入力が終了すると、入力情報に基づいて登録情報２４０を生成する（ステップＳ３）。なお、登録情報２４０が管理装置２以外の装置（プログラミング装置３または評価装置４）において生成される場合は、生成された登録情報２４０が管理装置２に送信される。すなわち、開発支援システム１において生成された登録情報２４０は、管理装置２のＲＡＭ２４に伝達される。

次に、管理装置２のデータベース管理部２１０が、ＲＡＭ２４に伝達された登録情報２４０をデータベースに登録する（ステップＳ４）。

さらに、開発支援システム１は、登録処理を終了するか否かを判定し（ステップＳ５）、処理を継続する場合は、ステップＳ１に戻って処理を繰り返す。一方、登録処理を終了する場合は、当該処理を終了する。

図６に示す登録処理を、各データベースごとに具体的に説明する。

＜要求管理データベース２５０への登録処理＞
要求管理データベース２５０に新たな「要求」を登録する処理は、主に設計者によって管理装置２を使用することにより実行される。ただし、プログラミング装置３を使用して実行されてもよい。

まず、設計者は、登録処理を開始する際に、要求管理データベース２５０への登録処理を選択する。次に、ステップＳ１において、入力部２６を操作することにより、入力情報として、「要求ＩＤ」、「要求カテゴリ」、「要求項目名」、「要求内容」等を入力する。なお、「要求ＩＤ」は、要求管理データベース２５０への登録処理が選択されたときに、例えば管理装置２によって自動的に付与されてもよい。

入力が終了すると（ステップＳ２においてＹｅｓ）、入力情報に基づいて登録情報２４０が生成される。なお、先述のように、登録情報２４０には、登録先を示すデータベースＩＤが付加される。ここでは要求管理データベース２５０を示すデータベースＩＤが登録情報２４０に付加される。

データベース管理部２１０は、生成された登録情報２４０に含まれるデータベースＩＤを参照することにより、当該登録情報２４０の登録先のデータベースが要求管理データベース２５０であることを確認する。また、登録情報２４０に含まれる「要求ＩＤ」を取得して、要求管理データベース２５０に、取得した「要求ＩＤ」によって識別されるレコードを新たに追加する。さらに、新たに追加したレコードの各項目に、登録情報２４０に含まれる情報を適宜格納する。

図７は、要求管理データベース２５０に新たに登録されたレコードを例示する図である。図７に例示するように、要求管理データベース２５０には複数の項目が設けられる。これらの項目のうち、登録時に情報が格納されるのは、登録情報２４０に含まれる情報に対応する項目と、「リンク済み」を示す項目とであって、それ以外の項目に情報は格納されない。

なお、「リンク済み」項目とは、当該「要求」について、すでに要求の影響範囲が入力（登録）されたか否かを示す情報が格納される項目である。新たな「要求」が要求管理データベース２５０に登録された時点では、当該要求の影響範囲は未だ影響範囲管理データベース２５３に登録されていない。したがって、「要求」の登録時において、データベース管理部２１０は、「リンク済み」項目に「未」を示す情報を格納する。

このようにして、新たな「要求」が要求管理データベース２５０に登録される。設計者は、さらに「要求」を登録する場合には、要求管理データベース２５０への登録処理を継続するよう指示を入力する。これにより、開発支援システム１は、ステップＳ１に戻って処理を繰り返す。

必要な「要求」をすべて登録した場合、設計者は、要求管理データベース２５０への登録処理を終了するよう指示を入力する。これにより、開発支援システム１は、要求管理データベース２５０への登録処理を終了する。

＜プログラム管理データベース２５１への登録処理＞
プログラム管理データベース２５１に新たな「関数プログラム」を登録する処理は、主に設計者によって管理装置２を使用することにより実行される。ただし、関数プログラムを制作する過程において、新たな関数プログラムが必要になる場合も多々あるので、プログラマがプログラミング装置３を使用して実行してもよい。

まず、設計者は、登録処理を開始する際に、プログラム管理データベース２５１への登録処理を選択する。次に、ステップＳ１において、入力部２６を操作することにより、入力情報として、「プログラムＩＤ」、「プログラムカテゴリ」、「プログラム項目名」、「プログラム内容」等を入力する。なお、「プログラムＩＤ」は、プログラム管理データベース２５１への登録処理が選択されたときに、例えば管理装置２によって自動的に付与されてもよい。

入力が終了すると（ステップＳ２においてＹｅｓ）、入力情報に基づいて登録情報２４０が生成される。なお、先述のように、登録情報２４０には、登録先を示すデータベースＩＤが付加される。ここではプログラム管理データベース２５１を示すデータベースＩＤが登録情報２４０に付加される。

データベース管理部２１０は、生成された登録情報２４０に含まれるデータベースＩＤを参照することにより、当該登録情報２４０の登録先のデータベースがプログラム管理データベース２５１であることを確認する。また、登録情報２４０に含まれる「プログラムＩＤ」を取得して、プログラム管理データベース２５１に、取得した「プログラムＩＤ」によって識別されるレコードを新たに追加する。さらに、新たに追加したレコードの各項目に、登録情報２４０に含まれる情報を適宜格納する。

図８は、プログラム管理データベース２５１に新たに登録されたレコードを例示する図である。図８に例示するように、プログラム管理データベース２５１には複数の項目が設けられる。これらの項目のうち、登録時に情報が格納されるのは、登録情報２４０に含まれる情報に対応する項目と、「リンク済み」を示す項目とであって、それ以外の項目に情報は格納されない。

なお、「リンク済み」項目とは、当該「プログラム」について、すでにプログラムの影響範囲が入力（登録）されたか否かを示す情報が格納される項目である。新たな「プログラム」がプログラム管理データベース２５１に登録された時点では、当該プログラムの影響範囲は未だ影響範囲管理データベース２５３に登録されていない。したがって、「プログラム」の登録時において、データベース管理部２１０は、「リンク済み」項目に「未」を示す情報を格納する。

このようにして、新たな「プログラム」がプログラム管理データベース２５１に登録される。設計者は、さらに「プログラム」を登録する場合には、プログラム管理データベース２５１への登録処理を継続するよう指示を入力する。これにより、開発支援システム１は、ステップＳ１に戻って処理を繰り返す。

必要な「プログラム」をすべて登録した場合、設計者は、プログラム管理データベース２５１への登録処理を終了するよう指示を入力する。これにより、開発支援システム１は、プログラム管理データベース２５１への登録処理を終了する。

＜テストケース管理データベース２５２への登録処理＞
テストケース管理データベース２５２に新たな「テストケース」を登録する処理は、主に設計者によって管理装置２を使用することにより実行される。ただし、製品プログラムを評価する過程において、新たなテストケースが必要になる場合も多々あるので、試験者が評価装置４を使用することにより実行してもよい。

まず、設計者は、登録処理を開始する際に、テストケース管理データベース２５２への登録処理を選択する。次に、ステップＳ１において、入力部２６を操作することにより、入力情報として、「テストケースＩＤ」、「テストカテゴリ」、「テスト項目名」、「テスト内容」、「作成者」等を入力する。なお、「テストケースＩＤ」は、テストケース管理データベース２５２への登録処理が選択されたときに、例えば管理装置２によって自動的に付与されてもよい。

入力が終了すると（ステップＳ２においてＹｅｓ）、入力情報に基づいて登録情報２４０が生成される。なお、先述のように、登録情報２４０には、登録先を示すデータベースＩＤが付加される。ここではテストケース管理データベース２５２を示すデータベースＩＤが登録情報２４０に付加される。

データベース管理部２１０は、生成された登録情報２４０に含まれるデータベースＩＤを参照することにより、当該登録情報２４０の登録先のデータベースがテストケース管理データベース２５２であることを確認する。また、登録情報２４０に含まれる「テストケースＩＤ」を取得して、テストケース管理データベース２５２に、取得した「テストケースＩＤ」によって識別されるレコードを新たに追加する。さらに、新たに追加したレコードの各項目に、登録情報２４０に含まれる情報を適宜格納する。

図９は、テストケース管理データベース２５２に新たに登録されたレコードを例示する図である。図９に例示するように、テストケース管理データベース２５２には複数の項目が設けられる。これらの項目のうち、登録時に情報が格納されるのは、登録情報２４０に含まれる情報に対応する項目のみであって、それ以外の項目に情報は格納されない。

このようにして、新たな「テストケース」がテストケース管理データベース２５２に登録される。設計者は、さらに「テストケース」を登録する場合には、テストケース管理データベース２５２への登録処理を継続するよう指示を入力する。これにより、開発支援システム１は、ステップＳ１に戻って処理を繰り返す。

必要な「テストケース」をすべて登録した場合、設計者は、テストケース管理データベース２５２への登録処理を終了するよう指示を入力する。これにより、開発支援システム１は、テストケース管理データベース２５２への登録処理を終了する。

＜影響範囲管理データベース２５３への登録処理＞
影響範囲管理データベース２５３に新たな「影響範囲」を登録する処理は、「要求」の影響範囲を登録する場合と、「プログラム」の影響範囲を登録する場合とがある。

まず、設計者は、登録処理を開始する際に、影響範囲管理データベース２５３への登録処理を選択する。影響範囲管理データベース２５３への登録処理が選択されると、データベース管理部２１０は、要求管理データベース２５０およびプログラム管理データベース２５１をサーチし、「リンク済み」項目に「未」を示す情報が格納されているレコードを抽出して、表示部２７に一覧表示させる。すなわち、未だリンク済みとなっていない「要求」および「プログラム」を一覧表示する。

図１０は、影響範囲が未登録の「要求」および「プログラム」をＩＤを用いて一覧表示する例を示す図である。

次に、設計者は、入力部２６を操作して、表示された一覧から所望する「要求」または「プログラム」を選択する。図１０では、「R03」という要求ＩＤで識別される要求を、「影響範囲」を登録する「要求」として選択する例を示す。このように、一覧から選択されることにより、影響範囲を登録する「要求」または「プログラム」が指定される。ただし、任意の「要求ＩＤ」または「プログラムＩＤ」を入力することによって、直接指定してもよい。

設計者が「要求ＩＤ」を指定した場合、さらに当該「要求ＩＤ」によって識別される要求について、「要求の影響範囲」を入力する。「要求の影響範囲」としては「プログラムＩＤ」と、「テストケースＩＤ」とが入力され得る。

「要求の影響範囲」として入力される「プログラムＩＤ」は、当該要求が修正された場合に、その影響により修正が必要となるプログラムを示すプログラムＩＤである。また、「要求の影響範囲」として入力される「テストケースＩＤ」は、当該要求が修正された場合に、その影響により再度実行しなければならないテストケース（影響テストケース）を示すテストケースＩＤである。

一方、設計者が「プログラムＩＤ」を指定した場合、さらに当該「プログラムＩＤ」によって識別されるプログラムについて、「プログラムの影響範囲」を入力する。「プログラムの影響範囲」としては「テストケースＩＤ」が入力され得る。「プログラムの影響範囲」として入力される「テストケースＩＤ」は、当該プログラムが修正された場合に、その影響により再度実行しなければならなくなるテストケース（影響テストケース）を示すテストケースＩＤである。

図１０に示す例では、「要求ＩＤ」が選択されているので、「要求の影響範囲」として「プログラムＩＤ」および「テストケースＩＤ」を入力できる。ここでは、「テストケースＩＤ」を２つ（T01,T02）入力したものとして説明する。

入力が終了すると（ステップＳ２においてＹｅｓ）、入力情報に基づいて登録情報２４０が生成される。なお、先述のように、登録情報２４０には、登録先を示すデータベースＩＤが付加される。ここでは影響範囲管理データベース２５３を示すデータベースＩＤが登録情報２４０に付加される。

データベース管理部２１０は、生成された登録情報２４０に含まれるデータベースＩＤを参照することにより、当該登録情報２４０の登録先のデータベースが影響範囲管理データベース２５３であることを確認する。また、登録情報２４０に含まれる「要求ＩＤ」または「プログラムＩＤ」を取得して、影響範囲管理データベース２５３に、取得した「要求ＩＤ」または「プログラムＩＤ」によって識別されるレコードを新たに追加する。さらに、新たに追加したレコードの各項目に、登録情報２４０に含まれる情報を適宜格納する。

図１１は、影響範囲管理データベース２５３に新しいレコードが登録された状態を例示する図である。図１１に例示するように、影響範囲管理データベース２５３には、「要求」または「プログラム」ごとに、「影響範囲」項目が設けられる。図１１に示す例では、「要求ＩＤ」が「R03」で示されるレコードが新たに登録されており、当該レコードの「影響範囲」の項目には、「T01,T02」という２つの「テストケースＩＤ」が格納されている。

このようにして、新たな「影響範囲」が影響範囲管理データベース２５３に登録される。なお、「要求の影響範囲」を登録した場合、データベース管理部２１０は、要求管理データベース２５０を検索して、当該要求の「リンク済み」項目に「済み」を示す情報を格納する。また、「プログラムの影響範囲」を登録した場合、データベース管理部２１０は、プログラム管理データベース２５１を検索して、当該プログラムの「リンク済み」項目に「済み」を示す情報を格納する。

次に、さらに続けて「影響範囲」を登録する場合（図１０に示す一覧に他のＩＤが表示されている場合）、設計者は、影響範囲管理データベース２５３への登録処理を継続するよう指示を入力する。

これにより、開発支援システム１は、ステップＳ１に戻って処理を繰り返す。ただし、すでに「要求の影響範囲」を登録した「R03」の要求ＩＤで識別される要求は、「リンク済み」の項目が「済み」となっているので、未登録の一覧には表示されない。

必要な「影響範囲」をすべて登録した場合、設計者は、影響範囲管理データベース２５３への登録処理を終了するよう指示を入力する。これにより、開発支援システム１は、影響範囲管理データベース２５３への登録処理を終了する。

このようにして、本実施の形態における開発支援システム１では、要求管理データベース２５０に登録されている全ての「要求」、およびプログラム管理データベース２５１に登録されている全ての「プログラム」について、それぞれ「影響範囲」が登録される。

＜障害管理データベース２５４への登録処理＞
障害管理データベース２５４に新たな「障害」を登録する処理は、主に試験者が評価装置４を操作することにより行われる。ただし、障害管理データベース２５４への登録処理は、テスト結果を入力する処理が行われるときに、間接的に実行されるので、別途後述する。

＜テストを実施するときの動作（動作確認処理）＞
図１２は、製品プログラム（または関数プログラム）の動作確認処理を示す流れ図である。開発支援システム１では、評価部門の試験者が評価装置４を操作することにより、製品プログラム（または関数プログラム）の動作試験が実施される。

まず、試験者は、評価装置４の入力部４６を操作することにより、テスト（動作試験）を開始する指示を与える。これにより、評価装置４は、テストケース管理データベース２５２に登録されているテストケースの一覧を送信するように一覧要求を管理装置２に送信する（ステップＳ１１）。この動作は、評価装置４から管理装置２に閲覧要求を行うことを意味する。

管理装置２は、評価装置４からの当該閲覧要求を受信すると、テストケース管理データベース２５２に登録されている情報に基づいて閲覧情報２４２を生成し、評価装置４に送信する。

評価装置４は、閲覧情報２４２を受信するまで待機しており（ステップＳ１２）、当該閲覧情報２４２を受信すると、受信した閲覧情報２４２に基づいて、当該テストケースの一覧を表示部４７に表示する（ステップＳ１３）。

これにより、試験者は、テストケース管理データベース２５２に、どのようなテストケースが登録されているかを容易に確認することができる。すなわち、実施するテストケースを容易に選択できる。

試験者は、表示部４７に表示されたテストケースの一覧から、所望するテストケースを選択する。評価装置４は、試験者によって選択がされるまで待機しており（ステップＳ１４）、当該選択がされることにより、評価装置４は、選択されたテストケースを識別するテストケースＩＤを含む閲覧要求を管理装置２に送信する（ステップＳ１５）。なお、以下では「テストケースＩＤ」として、「T01」を送信する例について説明する。

ステップＳ１５において送信された閲覧要求を受信すると、管理装置２のデータベース管理部２１０は、テストケース管理データベース２５２を検索し、当該テストケースＩＤによって識別されるテストケースのレコードを抽出して、閲覧情報２４２を生成する。さらに管理装置２の通信部２８は、生成された閲覧情報２４２を評価装置４に送信する。

評価装置４は、閲覧情報２４２を受信するまで待機しており（ステップＳ１６）、閲覧情報２４２を受信すると、当該閲覧情報２４２に基づいて、選択したテストケースに関する情報を表示部４７に表示する（ステップＳ１７）。

図１３は、テストケースに保存されている情報の内容が表示される例を示す図である。このように、開発支援システム１では、テストケースを実行する前に、実行するテストケース（ここに示す例ではテストケースＩＤが「T01」）に関する情報が表示部４７に表示される。したがって、試験者は、表示部４７に表示されたテストケースに関する情報（特に「テスト内容」の項目に格納されている情報）を、動作試験の前に、確認することができる。

図１３に示す例では、「結果」の項目に何も格納されていないことから、未だ当該テストケースは実行されていないことが分かる。また、「発生した障害ＩＤ」、「障害修正項目」および「障害修正状況」の各項目には、当該テストケースを実行することによって障害が発生しない限り情報が格納されることはない。したがって、未だ実行されていない当該テストケースに関してこれらの情報が格納されていることはない。

次に、評価装置４は、試験者の操作に従って、製品プログラムの動作試験を行い（ステップＳ１８）、試験が終了したか否かを判定する（ステップＳ１９）。そして、動作試験が終了するまで、動作試験を行いつつ待機し、試験が終了すると（ステップＳ１９においてＹｅｓ）、動作確認処理を終了する。

＜テスト結果を入力する動作（結果入力処理）＞
図１４は、結果入力処理を示す流れ図である。結果入力処理とは、テストケースを実行することにより、動作確認処理を行った結果を入力する処理である。開発支援システム１では、評価部門の試験者が評価装置４を操作することにより、結果入力処理が行われる。

まず、試験者は、評価装置４の入力部４６を操作することにより、結果入力処理を開始する指示を与える。これにより、評価装置４は、ステップＳ１１と同様にテストケースの一覧を送信するように一覧要求を管理装置２に送信する（ステップＳ２１）。

管理装置２は、評価装置４からの当該閲覧要求を受信すると、テストケース管理データベース２５２に登録されている情報に基づいて閲覧情報２４２を生成し、評価装置４に送信する。

評価装置４は、閲覧情報２４２を受信するまで待機しており（ステップＳ２２）、当該閲覧情報２４２を受信すると、受信した閲覧情報２４２に基づいて、当該テストケースの一覧を表示部４７に表示する（ステップＳ２３）。実行されたテストケースは、必ずテストケース管理データベース２５２に登録されているので、このとき表示される一覧には、必ず結果を入力しようとするテストケースが表示される。

これにより、試験者は、テストケース管理データベース２５２に、どのようなテストケースが登録されているかを容易に確認することができるとともに、結果を入力しようとするテストケースを容易に選択できる。

試験者は、表示部４７に表示されたテストケースの一覧から、所望するテストケースを選択する。評価装置４は、試験者によって選択がされるまで待機しており（ステップＳ２４）、当該選択がされることにより、評価装置４は、選択されたテストケースを識別するテストケースＩＤを入力情報（評価情報４４０）として取得する（ステップＳ２５）。なお、以下では「テストケースＩＤ」として、「T01」が選択された例について説明する。

試験者がテストケースＩＤに続いて、入力したテストケースＩＤによって識別されるテストケースを実行した結果を、入力部４６を操作することにより入力する。これにより、評価装置４は、動作試験の「結果」を受け付ける（ステップＳ２６）。本実施の形態では、「結果」として、良好な結果を示す「ＯＫ」、または障害発生を示す「ＮＧ」のいずれかが入力される。

次に、入力された「結果」が「ＯＫ」か否かを判定し（ステップＳ２７）、「ＯＫ」でない場合は、結果の詳細内容を受け付ける（ステップＳ２８）。ここで、結果の詳細内容の具体例としては、例えば、「障害項目名」、「障害内容」、「発見者」「重要度」等である。一方、「結果」が「ＯＫ」である場合は（ステップＳ２６においてＹｅｓ）、ステップＳ２８をスキップする。

次に、ステップＳ２５，Ｓ２６，Ｓ２８において入力された入力情報に基づいて、評価情報４４０を作成し、通信部４８が管理装置２に向けて送信し（ステップＳ２９）、結果入力処理を終了する。なお、評価情報４４０には、結果を入力する「テストケースＩＤ」、および当該テストケースＩＤで識別されるテストケースを実行した「結果」等が必ず含まれ、「結果」が「ＮＧ」の場合は、さらに「結果の詳細内容」が含まれる。

＜テスト結果を登録する動作（結果登録処理）＞
図１５は、結果登録処理を示す流れ図である。結果登録処理とは、結果入力処理により入力された情報をテストケース管理データベース２５２や、障害管理データベース２５４に格納する処理である。開発支援システム１では、管理装置２が、評価部門の評価装置４から送信された評価情報４４０を受信することにより、結果登録処理が行われる。

まず、通信部２８が評価情報４４０を受信すると、受信した評価情報４４０から更新情報２４１を生成し、ＲＡＭ２４に転送する。このとき生成される更新情報２４１には、テストケース管理データベース２５２のデータベースＩＤが含まれ、さらに、評価情報４４０に含まれるテストケースＩＤと、「結果」を示す情報（「ＯＫ」または「ＮＧ」）とが含まれる。

評価情報４４０が生成されると、データベース管理部２１０が当該評価情報４４０に基づいて、テストケース管理データベース２５２を検索し、当該テストケースＩＤによって識別されるテストケースの「結果」の項目に、当該テストケースの結果を示す情報を格納する（ステップＳ３１）。これにより、テストケース管理データベース２５２が更新される。

次に、評価情報４４０に含まれる「結果」が「ＯＫ」か否かを判定し（ステップＳ３２）、「ＯＫ」であれば、結果登録処理を終了する。

一方、「結果」が「ＯＫ」でない場合（ステップＳ３２においてＮｏ）、管理装置２は、障害が発生したと判断し、当該障害を識別するための障害ＩＤを自動的に付与し（ステップＳ３３）、付与した障害ＩＤに基づいて更新情報２４１を生成する。このとき生成される更新情報２４１には、テストケース管理データベース２５２のデータベースＩＤ、評価情報４４０に含まれるテストケースＩＤ、および「発生した障害ＩＤ」として付与された障害ＩＤが含まれる。

評価情報４４０が生成されると、データベース管理部２１０が当該評価情報４４０に基づいて、テストケース管理データベース２５２を検索し、当該テストケースＩＤによって識別されるテストケースの「発生した障害ＩＤ」の項目に、ステップＳ３３において付与された障害ＩＤを格納する（ステップＳ３４）。これによっても、テストケース管理データベース２５２が更新される。

図１６は、動作試験において障害が発生したテストケースに関するテストケース管理データベース２５２を例示する図である。

図９と図１６とを比較すれば明らかなように、テストケースの登録処理によって登録されたテストケースのレコード（図９）が、結果登録処理によって「発生した障害ＩＤ」の項目と「結果」の項目とに情報が格納され、更新されている。

このように、テストケース管理データベース２５２に登録されているテストケースは、当該テストケースに従った動作試験が実施されて、その結果が結果入力処理によって入力され、結果登録処理によって登録されることにより、その「結果」項目に動作試験の結果を示す情報が格納される。また、動作試験において障害が発生した場合は、「結果」項目に「ＮＧ」が格納されるとともに、当該テストケースを実施することにより発生した障害を示す障害ＩＤが、「発生した障害ＩＤ」の項目に格納される。

次に、管理装置２は、付与した障害ＩＤに基づいて登録情報２４０を生成する。このとき生成される登録情報２４０には、障害管理データベース２５４のデータベースＩＤ、評価情報４４０に含まれる「結果の詳細内容」、および付与された障害ＩＤが含まれる。

登録情報２４０が生成されると、データベース管理部２１０が、当該登録情報２４０に含まれるデータベースＩＤに基づいて、検索対象のデータベースを障害管理データベース２５４と判定する。そして、障害管理データベース２５４に、当該登録情報２４０に含まれる障害ＩＤによって識別される障害のレコードを新たに追加するとともに、当該登録情報２４０に含まれる「結果の詳細内容」を新たに追加したレコードに格納する。このようにして、データベース管理部２１０は、障害管理データベース２５４に「障害」を登録する（ステップＳ３５）。

図１７は、障害管理データベース２５４に新たに追加されたレコードを例示する図である。図１７に示すように、障害管理データベース２５４には、複数の項目が設けられ、登録情報２４０（評価情報４４０）に含まれる情報が格納される。

このように、「結果」が「ＮＧ」となっている評価情報４４０を受信することにより、管理装置２は障害管理データベース２５４への登録処理を実行する。なお、障害管理データベース２５４に新たなレコード（障害）が登録されたとき、未だ、「再テスト担当者」は決定されていないので「未定」を示す情報が自動的に格納される。また、「修正状況」についても、未だ、障害に対する対策も決定されていないので、「修正検討中」を示す情報が自動的に格納される。

障害管理データベース２５４への登録処理（ステップＳ３５）が終了すると、管理装置２は、結果登録処理を終了する。

＜修正指示を入力における動作＞
図１８および図１９は、修正入力処理を示す流れ図である。修正入力処理は、発生した障害に対する修正指示を入力する処理であり、主に設計者が管理装置２を使用することにより実行される。

まず、設計者は、修正入力処理を開始する指示を入力部２６を操作することにより入力する。これに応じて、入力部２６が障害管理データベース２５４の一覧表を要求する閲覧要求を作成し、データベース管理部２１０が当該閲覧要求に基づいて障害管理データベース２５４を検索し、障害管理データベース２５４に登録されている障害の一覧表を閲覧情報２４２として生成する。さらに、生成された閲覧情報２４２を表示部２７が表示する（ステップＳ４０）。このようにして、設計者によって修正入力処理の開始が指示されると、管理装置２の表示部２７に障害の一覧表が表示される。

設計者は、表示部２７に表示された障害の一覧表を確認しながら、修正指示を入力する障害を、当該一覧表から選択する。障害が選択されると、管理装置２はステップＳ４１においてＹｅｓと判定し、選択された障害の障害ＩＤを取得する（ステップＳ４２）。

次に、選択した障害に対する対策が決まると、設計者は、入力部２６を操作して「要求ＩＤ」あるいは「プログラムＩＤ」を入力することにより、修正対象を１つ入力する。これにより、管理装置２は、修正を行うにあたっての修正対象となる「要求」あるいは「プログラム」を１つ受け付ける（ステップＳ４３）。このとき、表示部２７に「要求」および「プログラム」の一覧表を表示し、当該一覧表から選択することにより、修正対象を入力するようにしてもよい。

修正対象を受け付けると、管理装置２が、ステップＳ４３で受け付けた修正対象は「要求」か否かを判定する（ステップＳ４４）。ステップＳ４４における判定は、例えば、ステップＳ４３において入力されたＩＤ（要求ＩＤかプログラムＩＤか）に基づいて行う。

ステップＳ４３において受け付けた修正対象が「要求」でない場合（すなわち「プログラム」である場合）、当該プログラムに対する修正内容を受け付け、受け付けた修正内容をプログラム管理データベース２５１に格納する（ステップＳ４５）。

具体的には、まず、設計者に対して修正内容を入力するように要求し、この要求に対して入力された情報を、当該プログラムに対する修正内容として受け付ける。さらに、ステップＳ４３において入力されたプログラムＩＤに基づいて、データベース管理部２１０がプログラム管理データベース２５１を検索し、当該プログラムＩＤによって識別されるレコードの「修正内容」の項目に、受け付けた修正内容を格納する。これにより、プログラム管理データベース２５１が更新される。

図２０は、プログラム管理データベース２５１が更新された様子を例示する図である。図２０は、図８に示すレコードを修正入力処理により更新した例を示す。

修正指示がされるプログラムは、ステップＳ４３においてプログラムＩＤが入力されたプログラムであり、図２０では、「P01」で識別されるプログラムについて修正指示がされている。「修正内容」の項目には、ステップＳ４５で受け付けた修正内容が格納されている。また、修正入力処理によって「修正内容」が格納されたので、「修正状況」の項目に「指示済み」を示す情報が自動的に格納されている。さらに、「修正指示障害ＩＤ」は、どの「障害」に対する対策として当該修正が指示されたかを示す項目であって、ステップＳ４２において取得した障害ＩＤが格納される。

なお、１つのプログラムが、複数の障害の対策として、それぞれ修正指示を受ける場合がある。したがって、「修正指示障害ＩＤ」、「修正内容」および「修正状況」は、修正指示を受けるたびに、図２０に示すように欄が追加される。

次に、修正指示をしたプログラムの影響範囲を取得し（ステップＳ４６）、取得した影響範囲を影響テストケースとして、格納する（ステップＳ４７）。

具体的には、当該プログラムのプログラムＩＤに基づいて、データベース管理部２１０が影響範囲管理データベース２５３を検索し、当該プログラムＩＤによって識別されるレコードの「影響範囲」の項目に格納されている情報を取得する。なお、プログラムの影響範囲としては、テストケースＩＤのみ格納されているので、格納されているテストケースＩＤによって識別されるテストケースが影響テストケースである。

図１１に示す影響範囲管理データベース２５３の例では、「P01」のプログラムＩＤによって識別されるレコード（プログラム）の「影響範囲」の項目には、「T01」および「T03」が格納されている。したがって、ここに示す例では、ステップＳ４６において、影響範囲として「T01」と「T03」とが取得され、これらが影響テストケースとなる。

すなわち、データベース管理部２１０は、ステップＳ４２で取得した障害ＩＤに基づいて、障害管理データベース２５４を検索し、修正指示を与えた障害の「影響テストケースＩＤ」の項目に、影響範囲として取得したテストケースＩＤを格納する。

図２１は、障害管理データベース２５４が更新された様子を例示する図である。図２１は、図１７に示すレコードを修正入力処理により更新した例を示す。

修正指示の元となった障害は、ステップＳ４２において障害ＩＤが入力された障害であり、図２１では、「E01」で識別される障害の対策として修正指示がされている。「影響テストケース」の項目には、先述のように、「T01」と「T03」とが格納されている。また、修正入力処理によって「修正内容」が格納されたので、「修正状況」の項目に「指示済み」を示す情報が自動的に格納されている。

このように、修正指示がプログラムに対してされる場合において、ステップＳ４７によって、当該プログラムが修正されることによって、再度実行しなければならない影響テストケースが格納される。これにより、オペレータは、障害管理データベース２５４に登録されている障害の「影響テストケース」を確認することにより、当該障害について必要なテストケースを容易に把握することができる。したがって、当該障害に対する修正が完了した後に、漏れのない動作試験を行うことができる。したがって、品質のよいプログラムを開発することができる。

また、障害の「修正状況」を確認することにより、当該障害に対しては、すでに修正が指示されていることが容易に確認できる。したがって、ステップＳ４１等において、修正指示を入力する「障害」を選択する場合に、必要な「障害」を容易に選択することができる。

影響テストケースを障害管理データベース２５４に格納すると、さらに、データベース管理部２１０は、当該影響テストケースを示すテストケースＩＤに基づいて、テストケース管理データベース２５２を検索する。そして、当該テストケースＩＤによって識別されるレコードの「障害修正項目」に、ステップＳ４２で取得した障害ＩＤと、ステップＳ４３で取得した修正対象を示すプログラムＩＤとを関連付けて格納する。また、当該レコードの「障害修正状況」に、「障害修正項目」と関連付けて「指示済み」を示す情報を格納する。

図２２は、テストケース管理データベース２５２のレコードが更新される様子を例示する図である。図２１に示した例では、影響テストケースのテストケースＩＤは、「T01」と「T03」である。したがって、図２２では、テストケース管理データベース２５２の「T01」と「T03」とで識別されるレコードがそれぞれ更新されている。

図２２から明らかなように、テストケースＩＤ「T03」で識別されるテストケースは、「結果」が「ＯＫ」となっており、動作試験において結果が良好であったことが容易に確認できる。この場合、当該テストケースを実施したときにおいて「障害」は発生していないので、「発生した障害ＩＤ」も格納されていない。

しかし、図２１に示したように、開発支援システム１では、障害管理データベース２５４には、「T03」のテストケースのように良好な結果が得られたテストケースであっても、影響範囲管理データベース２５３に基づいて、「影響テストケース」にそのテストケースＩＤが格納される。したがって、「E01」の障害についての修正作業が完了した後に、再度、「T03」のテストケースによる動作試験を実施しなければならないことが容易に把握できる。したがって、漏れのない動作試験を実施できるので、品質のよいプログラムを開発することができる。

なお、テストケースは、１つの障害に対して複数の修正項目（修正対象）が選択される場合がある。また、他のテストケースにおいて発生した障害（すなわち複数の障害）に対してそれぞれ修正項目が選択される場合もある。したがって、「障害修正項目」およびこれに関連付けられる「障害修正状況」は、適宜、複数格納できるようになっている。

管理装置２は、当該障害に対する対策に必要な全ての修正対象に対して修正指示が終了したか否かを判定し（ステップＳ５６）、未だ修正指示を入力していない修正対象が残っている場合は、ステップＳ４３からの処理を繰り返し、全ての修正対象について処理を終了している場合は、修正入力処理を終了する。

一方、ステップＳ４３において受け付けた修正対象が「要求」であった場合、当該要求に対する修正内容を受け付け、受け付けた修正内容を要求管理データベース２５０に格納する（ステップＳ４８）。

具体的には、まず、管理装置２は表示部２７にメッセージ等を表示することにより、修正内容を入力するように要求し、この要求に対して入力された情報を、当該要求に対する修正内容として受け付ける。さらに、ステップＳ４３において入力された要求ＩＤに基づいて、データベース管理部２１０が要求管理データベース２５０を検索し、当該要求ＩＤによって識別されるレコードの「修正内容」の項目に、受け付けた修正内容を格納する。これにより、要求管理データベース２５０が更新される。

図２３は、要求管理データベース２５０が更新された様子を例示する図である。図２３は、図７に示すレコードを修正入力処理により更新した例を示す。

修正指示がされる要求は、ステップＳ４３において要求ＩＤが入力された要求であり、図２３は、「R01」で識別される要求について修正指示がされていることを示している。「修正内容」の項目には、ステップＳ４８で受け付けた修正内容が格納されている。また、修正入力処理によって「修正内容」が格納されたので、「修正状況」の項目に「指示済み」を示す情報が自動的に格納されている。さらに、「修正指示障害ＩＤ」は、どの「障害」に対する対策として当該修正が指示されたかを示す項目であって、ステップＳ４２において取得した障害ＩＤが格納される。

なお、要求においてもプログラムと同様に、複数の障害の対策として、それぞれ修正指示を受ける場合がある。したがって、「修正指示障害ＩＤ」、「修正内容」および「修正状況」は、修正指示を受けるたびに、欄が追加される。

次に、修正指示をした要求の影響範囲を取得し（ステップＳ４９）、取得した影響範囲をのうち、影響テストケースを格納する（ステップＳ５０）。

具体的には、当該要求の要求ＩＤに基づいて、データベース管理部２１０が影響範囲管理データベース２５３を検索し、当該要求ＩＤによって識別されるレコードの「影響範囲」の項目に格納されている情報を取得する。なお、要求の影響範囲としては、テストケースＩＤのみならず、プログラムＩＤも格納されている場合がある。ここでは、要求の「影響範囲」として格納されているテストケースＩＤによって識別されるテストケースのみを影響テストケースとする。

図１１に示す影響範囲管理データベース２５３の例では、「R01」の要求ＩＤによって識別されるレコード（要求）の「影響範囲」の項目には、「P01」、「T02」および「T03」が格納されている。したがって、ここに示す例では、ステップＳ４６において、影響範囲として「P01」、「T02」および「T03」が取得され、これらのうち「T02」および「T03」が影響テストケースとなる。言い換えれば、「P01」のプログラムＩＤで示されるプログラムの「影響範囲」は、ステップＳ５０では影響テストケースとはしない。

すなわち、データベース管理部２１０は、ステップＳ４２で取得した障害ＩＤに基づいて、障害管理データベース２５４を検索し、修正指示を与えた障害の「影響テストケースＩＤ」の項目に、「要求の影響範囲」として取得したテストケースＩＤを格納する。

また、このとき影響テストケースのテストケースＩＤに基づいて、テストケース管理データベース２５２を検索し、当該テストケースＩＤによって識別されるレコードの「障害修正項目」および「障害修正状況」を更新する。

図２４は、テストケース管理データベース２５２のレコードが更新される様子を例示する図である。図２４に示すように、「T02」および「T03」のテストケースについて、「障害修正項目」および「障害修正状況」が格納され、更新されている。

次に、ステップＳ４９で取得した「要求の影響範囲」にプログラムが含まれているか否かを判定し（ステップＳ５１）、プログラムが含まれていない場合は、ステップＳ５６からの処理を実行する。

「要求の影響範囲」にプログラムが含まれている場合（ステップＳ５１においてＹｅｓ）、当該プログラムの一覧を表示部２７に表示する（ステップＳ５２）。具体的には、「要求の影響範囲」として取得したプログラムＩＤを表示部２７に一覧表示する。

これにより、設計者は要求を修正することによって影響がでるプログラムを容易に確認することができる。このようなプログラムは、当該障害に対する対策において修正指示が必要となる確率が比較的高いと言える。開発支援システム１においても、修正指示が必要な「プログラム」や「要求」は、オペレータが判断して決定しなければならない。しかし、開発支援システム１は、修正指示の必要性が高いプログラムを一覧表示することによって、オペレータは修正指示が必要なプログラムについて、漏れなく確実に修正指示を行うことができる。

さらに、一覧表示から選択されたプログラムについて、修正内容を受け付け、受け付けた修正内容をプログラム管理データベース２５１に格納する（ステップＳ５３）。

具体的には、管理装置２は表示部２７にメッセージ等を表示することにより、修正内容を入力するように要求し、この要求に対して入力された情報を、当該プログラムに対する修正内容として受け付ける。さらに、ステップＳ４９において「要求の影響範囲」として取得したプログラムＩＤに基づいて、データベース管理部２１０がプログラム管理データベース２５１を検索し、当該プログラムＩＤによって識別されるレコードの「修正内容」の項目に、受け付けた修正内容を格納する。これにより、「要求の影響範囲」として取得されたプログラムについても、必要であれば（選択されれば）、プログラム管理データベース２５１が更新され、修正内容が格納される。

ステップＳ５２において一覧表示されたプログラム（「要求の影響範囲」として取得されたプログラム）のうち、修正指示が必要な全プログラムについてステップＳ５３が終了すると、管理装置２はステップＳ５４においてＹｅｓと判定する。なお、ステップＳ５４の判定は、設計者が入力部２６を操作して入力する情報に基づいて行う。

次に、管理装置２は、要求の影響範囲に含まれる全プログラムについて、影響範囲管理データベース２５３から「影響範囲」を取得し、これらを影響テストケースとして障害管理データベース２５４に格納する（ステップＳ５５）。すなわち、修正指示が要求に対してされる場合においても、ステップＳ５０，Ｓ５５によって、当該要求が修正されることによって、再度実行しなければならない影響テストケースが格納される。

これにより、オペレータは、障害の「影響テストケース」を確認することにより、必要なテストケースを容易に把握することができる。したがって、当該障害に対する修正が完了した後に、漏れのない動作試験を行うことができる。したがって、品質のよいプログラムを開発することができる。

ステップＳ５５において影響テストケースを格納すると、ステップＳ４７，Ｓ５０と同様に、影響テストケースのテストケースＩＤに基づいて、テストケース管理データベース２５２を更新する。

さらに、管理装置２は、当該障害に対する対策に必要な全ての修正対象に対して修正指示が終了したか否かを判定し（ステップＳ５６）、未だ修正指示を入力していない修正対象が残っている場合は、ステップＳ４３からの処理を繰り返し、全ての修正対象について処理を終了している場合は、修正入力処理を終了する。

なお、詳細は説明を省略したが、障害に対する対策において、新たな「要求」や「プログラム」を追加する必要がある場合や、要求（あるいはプログラム）の影響範囲が変化する場合には、修正入力処理のステップＳ４３を実行する前に、要求管理データベース２５０、プログラム管理データベース２５１、あるいは影響範囲管理データベース２５３への登録処理を必要に応じて実行すればよい。

＜修正作業における動作＞
開発支援システム１においては、「要求」を修正する作業と、「プログラム」を修正する作業はほぼ同様に行われる。以下では、プログラムを修正する作業を例に、開発支援システム１における修正作業を説明する。

図２５は、修正作業処理における動作を示す流れ図である。なお、修正作業処理は、プログラミング部門のプログラマが、プログラミング装置３の入力部３６を操作して、修正作業処理を開始する指示を入力することにより、開始される。

修正作業処理が開始されると、プログラミング装置３は、管理装置２に対してプログラムの一覧について閲覧要求を行う。これに応じて、管理装置２からは、プログラム管理データベース２５１に登録されているプログラムの一覧を含む閲覧情報２４２が送信される。プログラムの一覧を含む閲覧情報２４２を受信すると、プログラミング装置３は、当該閲覧情報２４２に基づいて、プログラムの一覧表を表示部３７に表示する。

次に、プログラマは、入力部３６を操作して、表示された一覧から所望のプログラムを選択する。この操作に応じて、プログラミング装置３は、当該選択されたプログラムのプログラムＩＤとともに、当該プログラムについての閲覧要求を管理装置２に送信する。

この閲覧要求に対して、管理装置２から、当該プログラムのレコードに格納されている情報を含む閲覧情報２４２が送信され、これを受信したプログラミング装置３は、当該閲覧情報２４２を表示部３７に表示する（ステップＳ６１）。これにより、プログラマは、所望のプログラムについて、プログラム管理データベース２５１に格納されている情報を閲覧することができる。

図２０に示す例のように、プログラムについて修正指示がされている場合、その内容が、「修正内容」の項目に表示される。これにより、プログラマは、プログラムについて修正指示があったことを確認できるとともに、その内容についても把握することができる。

次に、プログラマは、「修正内容」として表示されている情報に従って、当該プログラムの修正作業を行う。

プログラミング装置３はこの修正作業を受け付けつつ（ステップＳ６２）、修正作業が終了したか否かを判定し（ステップＳ６３）、修正作業が終了するまでステップＳ６２の処理を継続する。

プログラマによるプログラムの修正作業が終了すると、ステップＳ６３においてＹｅｓと判定し、修正状況を受け付ける（ステップＳ６４）。具体的には、修正状況を示す情報の入力を促すメッセージを表示部３７に表示し、これに応じて入力された情報を修正状況を示す情報として受け付ける。

プログラミング装置３は、プログラマが選択したプログラム（修正作業を行ったプログラム）のプログラムＩＤと、修正指示の元となった障害ＩＤ（修正指示障害ＩＤ）と、受け付けた情報とに基づいてプログラム情報３４０を生成する。

ステップＳ６４では、例えば、「修正中」、あるいは「修正済み」等の情報がプログラム情報３４０に含まれる。なお、１つのプログラムについて、複数の修正指示が表示されている場合は、各修正指示ごとにプログラム情報３４０が生成される。

プログラム情報３４０が生成されると、プログラミング装置３は生成したプログラム情報３４０を管理装置２に送信する。管理装置２の通信部２８がプログラム情報３４０を受信すると、データベース管理部２１０が、プログラム情報３４０に含まれるプログラムＩＤに基づいて、プログラム管理データベース２５１を検索する。そして、当該プログラムＩＤによって識別されるレコードの「修正状況」の項目に、プログラム情報３４０に含まれる修正状況を示す情報を格納する。

このように、データベース管理部２１０は、プログラム情報３４０に基づいて、プログラム管理データベース２５１を更新する（ステップＳ６５）。すなわち、プログラマの修正作業の進捗に応じて、当該プログラムの「修正状況」の項目に、入力された修正状況を示す情報が格納される。

次に、データベース管理部２１０は、テストケース管理データベース２５２を更新する（ステップＳ６６）。具体的には、プログラム情報３４０に含まれる修正指示障害ＩＤとプログラムＩＤとに基づいて、テストケース管理データベース２５２の「障害修正項目」を検索し、「障害修正項目」の項目に当該障害ＩＤとプログラムＩＤとが関連付けて格納されている障害修正項目を抽出する。さらに、抽出した障害修正項目に関連付けられている「修正状況」の項目に、プログラム情報３４０に含まれる修正状況を示す情報を格納する。これにより、テストケース管理データベース２５２に格納されている「障害修正状況」が更新される。

さらに、データベース管理部２１０は、障害管理データベース２５４を更新する（ステップＳ６７）。具体的には、障害管理データベース２５４に登録されている障害ごとに、「影響テストケースＩＤ」に示される全てのテストケースＩＤを取得する。次に、障害ごとに取得したテストケースＩＤに基づいて、テストケース管理データベース２５２を検索し、当該テストケースＩＤに示されるレコードの「障害修正状況」に格納される情報が全て「修正済み」となっている場合にのみ、当該障害の「修正状況」を「修正済み」に更新する。

すなわち、テストケースのレコードにおいて、「障害修正状況」の項目が全て「修正済み」となっている場合には、当該テストケースに従って動作確認を実施することが可能である。この状態のテストケースを「実施可能テストケース」と称する。

そして、ある障害について、動作確認処理（後述）が可能であるためには、「影響テストケースＩＤ」の項目によって示される全てのテストケースが「実施可能テストケース」となっている必要がある。したがって、データベース管理部２１０は、先述の処理によって、障害ごとに、全ての影響テストケースが「実施可能テストケース」となっているか否かを検出し、この場合にのみ、当該障害の「修正状況」を「修正済み」に更新する。

このように、開発支援システム１では、プログラマによる修正作業の進捗状況が、各データベース（プログラム管理データベース２５１、テストケース管理データベース２５２および障害管理データベース２５４）に格納されるので、必要に応じて、修正状況を容易に確認できる。

障害管理データベース２５４の更新が終了すると、修正作業処理を終了するか否か判定し（ステップＳ６８）、さらに修正作業処理を継続する場合は、ステップＳ６１に戻って処理を繰り返す。一方、修正作業処理を終了する場合は、処理を終了する。

＜再動作確認処理＞
プログラムの開発過程では、テストケースに従って動作確認を行い、これにより障害が発生した場合、当該障害に対する対策（修正作業）が完了した時点で、再度、動作確認を行う必要がある。

試験者は、評価装置４の入力部４６を操作して、再動作確認処理を開始する指示を入力することにより、当該処理を開始する。この指示に応じて、評価装置４は、これまでに発生した障害の一覧を閲覧するための閲覧要求を管理装置２に送信する。

当該閲覧要求に応じて、管理装置２のデータベース管理部２１０は、障害管理データベース２５４に登録されている障害の一覧を含む閲覧情報２４２を生成し、評価装置４に送信する。

当該閲覧情報２４２を受信した評価装置４は、受信した閲覧情報２４２を表示部４７に表示する。これにより、試験者は、障害管理データベース２５４に登録されている障害を容易に把握できる。

次に、試験者は、入力部４６を操作して、障害の一覧から所望する障害（再動作確認する障害）を選択する。これにより、評価装置４は選択された障害を識別する障害ＩＤを取得し、取得した障害ＩＤとともに、当該障害を閲覧するための閲覧要求を管理装置２に送信する。

この閲覧要求に応じて、管理装置２のデータベース管理部２１０は、障害管理データベース２５４を検索して、当該障害ＩＤによって識別されるレコードを抽出する。さらに抽出したレコードに基づいて閲覧情報２４２を生成し、評価装置４に送信する。

当該閲覧情報２４２を受信した評価装置４は、受信した閲覧情報２４２を表示部４７に表示する。これにより、試験者は、所望する障害の情報を閲覧することができる。

次に、評価装置４は、閲覧情報２４２に示される「修正状況」の項目が「修正済み」を示す情報となっているか否かを判定し、「修正済み」となっていない場合には、当該障害について再動作確認処理を実施することができないことを表示部４７に表示し、処理を終了する。

一方、「修正済み」を示す情報となっている場合は、当該障害の「影響テストケースＩＤ」に格納されている全てのテストケースＩＤに基づいて、管理装置２に閲覧要求を送信し、これにより受信した閲覧情報２４２を表示部４７に表示する。これにより、表示部４７には、全ての影響テストケースのレコードに格納されている情報が表示される。したがって、試験者は、当該障害について、再動作確認を行うためのテスト内容を容易に把握することができる。したがって、漏れのない動作試験を実施することができ、品質のよいプログラムを開発することができる。

＜２． 変形例＞
以上、本発明の実施の形態について説明してきたが、本発明は上記実施の形態に限定されるものではなく様々な変形が可能である。

例えば、本実施の形態では、制作されるプログラムに関する情報の入力と、当該プログラムの制作とが、いずれもプログラミング装置３において行われる。しかし、開発支援システム１は、制作されるプログラムに関する情報を取得することができれば十分なので、プログラムの制作は、外部の他の装置において行われてもよい。

同様に、本実施の形態では、テストケースの結果に関する情報の入力と、当該テストケースの実施とが、いずれも評価装置４において行われる。しかし、開発支援システム１は、テストケースの結果に関する情報を取得することができれば十分なので、テストケースの実施は、外部の他の装置において行われてもよい。

また、上記実施の形態では、プログラミング装置３と評価装置４との間においてもデータ通信が可能であると説明した。しかし、各データベースが管理装置２に記憶されている場合、プログラミング装置３および評価装置４は、管理装置２との間でデータ通信が可能であれば十分である。すなわち、プログラミング装置３と評価装置４との間は、データ通信が可能でなくともよい。

また、上記実施の形態では、５つのデータベースを構築するとして説明したが、必要な情報を容易に管理することが可能であれば、データベースの構造はこれに限られるものではない。例えば、「影響範囲」という項目を要求管理データベース２５０およびプログラム管理データベース２５１の各レコードにそれぞれ設け、影響範囲管理データベース２５３に格納している情報を、当該項目に格納してもよい。このように構成すれば、影響範囲管理データベース２５３を他のデータベースと独立して設けなくてもよい。

本発明に係る開発支援システムを示す図である。 管理装置の構成を示す図である。 管理装置の機能ブロックを示す図である。 プログラミング装置の構成を示す図である。 評価装置の構成を示す図である。 管理装置のデータベースに情報を登録する動作を簡略的に示す流れ図である。 要求管理データベースに新たに登録されたレコードを例示する図である。 プログラム管理データベースに新たに登録されたレコードを例示する図である。 テストケース管理データベースに新たに登録されたレコードを例示する図である。 影響範囲が未登録の「要求」および「プログラム」をＩＤを用いて一覧表示する例を示す図である。 影響範囲管理データベースに新しいレコードが登録された状態を例示する図である。 製品プログラム（または関数プログラム）の動作確認処理を示す流れ図である。 テストケースに保存されている情報の内容が表示される例を示す図である。 結果入力処理を示す流れ図である。 結果登録処理を示す流れ図である。 動作試験において障害が発生したテストケースに関するテストケース管理データベースを例示する図である。 障害管理データベースに新たに追加されたレコードを例示する図である。 修正入力処理を示す流れ図である。 修正入力処理を示す流れ図である。 プログラム管理データベースが更新された様子を例示する図である。 障害管理データベースが更新された様子を例示する図である。 テストケース管理データベースのレコードが更新される様子を例示する図である。 要求管理データベースが更新された様子を例示する図である。 テストケース管理データベースのレコードが更新される様子を例示する図である。 修正作業処理における動作を示す流れ図である。

符号の説明

１ 開発支援システム
２ 管理装置
２１０ データベース管理部
２２ 記憶部
２３０ プログラム
２４０ 登録情報
２４１ 更新情報
２４２ 閲覧情報
２５０ 要求管理データベース
２５１ プログラム管理データベース
２５２ テストケース管理データベース
２５３ 影響範囲管理データベース
２５４ 障害管理データベース
２６，３６，４６ 入力部
２７，３７，４７ 表示部
３ プログラミング装置
３３０ プログラム
３４０ プログラム情報
４ 評価装置
４３０ プログラム
４４０ 評価情報
９０ ネットワーク

Claims (7)

1. プログラムの開発を支援する開発支援システムであって、
   オペレータの指示入力を受け付ける入力部と、
   前記入力部が受け付けた指示入力に基づいて、プログラムごとに当該プログラムの影響範囲を予め保存しておく影響範囲管理部と、
   前記入力部が受け付けたプログラム修正を指示する指示入力に基づいて、前記プログラム修正を指示する指示入力から修正対象プログラムを特定し、前記影響範囲管理部に保存されているプログラムの影響範囲の中から、前記修正対象プログラムの影響範囲を取得する取得部と、
   前記取得部によって取得された修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が前記修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定する特定部と、
   を備えることを特徴とする開発支援システム。
2. 請求項１に記載の開発支援システムであって、
   前記影響範囲管理部は、前記入力部が受け付けた指示入力に基づいて、プログラムに対する要求ごとに当該要求の影響範囲を予め保存しておき、
   前記取得部は、前記入力部が受け付けた要求修正をを指示する指示入力に基づいて、前記要求修正を指示する指示入力から修正対象要求を特定し、前記影響範囲管理部に保存されている要求の影響範囲の中から、前記修正対象要求の影響範囲を取得し、
   前記取得部によって取得された修正対象要求の影響範囲に基づいて、前記要求修正を指示する指示入力に基づく修正が前記修正対象要求について完了した後に実施すべきテストケースを影響テストケースとして特定することを特徴とする開発支援システム。
3. プログラムの開発を支援する開発支援システムであって、
   オペレータの指示入力を受け付ける入力部と、
   前記入力部が受け付けた指示入力に基づいて、プログラムに対する要求ごとに当該要求の影響範囲を予め保存しておく影響範囲管理部と、
   前記入力部が受け付けた要求修正を指示する指示入力に基づいて、前記要求修正を指示する指示入力から修正対象要求を特定し、前記影響範囲管理部に保存されている要求の影響範囲の中から、前記修正対象要求の影響範囲を取得する取得部と、
   前記取得部によって取得された修正対象要求の影響範囲に基づいて、前記要求修正を指示する指示入力に基づく修正が前記修正対象要求について完了した後に実施すべきテストケースを影響テストケースとして特定する特定部と、
   を備えることを特徴とする開発支援システム。
4. 請求項２または３に記載の開発支援システムであって、
   要求の影響範囲には、前記要求を修正することにより修正が必要となるプログラムが示されていることを特徴とする開発支援システム。
5. 請求項１ないし４のいずれかに記載の開発支援システムであって、
   前記入力部は、前記修正対象プログラムに対する修正が完了したことを示す修正済み情報を受け付け、
   前記修正済み情報に基づいて、前記影響テストケースが実施可能であるか否かを判定することを特徴とする開発支援システム。
6. プログラムの開発を支援する開発支援方法であって、
   オペレータの指示入力を受け付ける入力工程と、
   前記入力工程において受け付けた指示入力に基づいて、プログラムごとに当該プログラムの影響範囲を予め保存しておく影響範囲保存工程と、
   前記入力工程において受け付けたプログラム修正を指示する指示入力に基づいて、前記プログラム修正を指示する指示入力から修正対象プログラムを特定し、前記影響範囲管理部に保存されているプログラムの影響範囲の中から、前記修正対象プログラムの影響範囲を取得する取得工程と、
   前記取得工程において取得された修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が前記修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定する特定工程と、
   を備えることを特徴とする開発支援方法。
7. コンピュータ読み取り可能な開発支援プロクラムであって、前記開発支援プログラムの前記コンピュータによる実行は、前記コンピュータに、
   オペレータの指示入力を受け付ける入力工程と、
   前記入力工程において受け付けた指示入力に基づいて、プログラムごとに当該プログラムの影響範囲を予め保存しておく影響範囲保存工程と、
   前記入力工程において受け付けたプログラム修正を指示する指示入力に基づいて、前記プログラム修正を指示する指示入力から修正対象プログラムを特定し、前記影響範囲管理部に保存されているプログラムの影響範囲の中から、前記修正対象プログラムの影響範囲を取得する取得工程と、
   前記取得工程において取得された修正対象プログラムの影響範囲に基づいて、前記プログラム修正を指示する指示入力に基づく修正が前記修正対象プログラムについて完了した後に実施すべきテストケースを影響テストケースとして特定する特定工程と、
   を実行させることを特徴とする開発支援プログラム。

Images