開発支援システム、開発支援方法及び開発支援プログラム

【課題】開発対象システムについて作成された管理票に基づいて、システム開発の管理を支援するための開発支援システム、開発支援方法及び開発支援プログラムを提供する。
【解決手段】テスト工程管理サーバ20の制御部21は、不良管理票(発生)の入力処理、対応システムの登録処理、不良管理票(対応)の入力処理を実行する。また、制御部21は、仕様変更管理票(発生)の入力処理、対応システムの登録処理、仕様変更管理票(対応)の入力処理を実行する。更に、制御部21は、テスト日誌の入力処理、進捗情報の算出処理を実行する。そして、報告書を作成する場合、制御部21は、登録システムを特定し、不良管理票、テスト日誌を用いて報告書を作成し出力する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、開発対象システムについて作成された管理票に基づいて、システム開発の管理を支援するための開発支援システム、開発支援方法及び開発支援プログラムに関する。
【背景技術】
【0002】
企業内で用いられる業務システムの開発管理においては、各種管理票が利用されている。また、このようなシステムの開発においても、多様なテストが行なわれている。このようなテストの進捗状況を管理するために、各種報告書を作成する場合がある。そこで、ソフトウェアのテスト結果の報告書の自動作成及びテスト結果に基づいてテスト計画の変更処理を行なうテスト結果の報告書自動作成装置が検討されている(例えば、特許文献1参照)。この文献に記載された技術では、テスト実行手段のテスト実行結果を分析して集計し蓄積する。そして、テスト結果を分析して集計し、ワープロソフト等の一般のソフトウェアに使用できる形式のデータ形式に変換して出力する。
【0003】
また、予定入力シート、報告出力シート及び実績シートを作成するソフトウェア品質管理システムも検討されている(例えば、特許文献2参照)。この文献に記載された技術では、入力された予定値と、過去に記録した品質管理項目から決定した目標値・目標の許容範囲を入力シートに記述し、これらを報告出力シートに転記する。入力された実績値を実績シートへ記述し、工程単位毎に集計した実績値の集計値を報告出力シートに記述する。そして、予定値と集計値を比較し、その差が前記許容範囲か否かを判定し、その判定結果を報告出力シートに記述する。
【0004】
また、ソフトウェアの開発において、ユーザが、修正目的に応じて簡単に編集可能なソフトウェア開発支援装置も検討されている(例えば、特許文献3参照)。この文献に記載されたソフトウェア開発支援装置では、ソフトウェアの開発支援において、修正が行われたソフトウェアコードである編集ファイルとオリジナルファイルとを比較し、編集ファイルの修正された箇所と当該修正箇所に該当するオリジナルファイルの修正該当箇所を対応付けた修正対応箇所データを生成する。そして、ユーザが入力した修正に対して、報告書から自動的に抽出した修正目的を提示し、修正内容を修正目的によって管理する。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開平6−89202号公報(第1頁、図1)
【特許文献2】特開2007−279965号公報(第1頁、図1)
【特許文献3】特開2009−53778号公報(第1頁、図1)
【発明の概要】
【発明が解決しようとする課題】
【0006】
規模が大きいシステム開発を行なう場合、複数の拠点や部署において別個にソフトウェアを開発し、これらを統合管理して目的の業務を実現するためのシステム構築する場合がある。この場合、テスト期間中においては、テストの進捗状況をまとめ、実施状況についての情報を関係者で共有する必要がある。
【0007】
そこで、各開発拠点や部署において、情報共有のための会議を開催している。このような会議を開催する場合、システム開発の規模が大きい場合、会議の準備、管理者の参加にかかる手間やコストが大きくなる。
【0008】
特に、各開発における報告書は、システム開発に参加している各開発担当者がテスト日誌、テストにおける不良管理票や仕様変更管理票等に基づいて作成している。しかしながら、テスト日誌や、不良管理票や仕様変更管理票の数は膨大であり、個別に内容を確認することか困難な場合がある。また、上述の会議のために、これらの管理票をまとめた資料を作り直す手間がかかっていた。
【0009】
更に、テスト実施状況の全体感を取りまとめ、タイムリーに関係者に報告する必要がある。また、発生した不良や仕様変更等、他のシステムに影響がある事項については関係者に展開する必要がある。
【0010】
本発明は、上記課題を解決するためになされたものであり、その目的は、開発対象システムについて作成された管理票に基づいて、システム開発の管理を支援するための開発支援システム、開発支援方法及び開発支援プログラムを提供することにある。
【課題を解決するための手段】
【0011】
上記問題点を解決するために、請求項1に記載の発明は、利用者情報に関連づけて、開発対象システムの識別情報を記憶するシステムマスタ情報記憶手段と、利用者情報に関連づけて、開発対象システムに関連するシステムの識別情報を記憶するグループ情報記憶手段と、システム開発の管理において、利用者によって作成され、システムの識別情報が記録された管理票を記憶する管理票記憶手段と、クライアント端末に接続された制御手段とを備えた開発支援システムであって、前記制御手段が、クライアント端末から利用者情報を取得し、前記システムマスタ情報記憶手段及びグループ情報記憶手段から、前記利用者情報に関連付けられたシステムの識別情報を取得する手段と、前記管理票記憶手段から、前記取得したシステムの識別情報が記録された管理票を抽出する手段と、前記抽出した管理票を集約した評価結果を含めた報告書を作成し、前記クライアント端末に出力する手段とを備えたことを要旨とする。
【0012】
請求項2に記載の発明は、請求項1に記載の開発支援システムにおいて、開発において使用されるキーワードを記憶した用語記憶手段を更に備え、前記制御手段が、前記管理票において、前記用語記憶手段に記録されたキーワードを抽出し、前記キーワードの出現状況を記録した報告書を作成することを特徴とすることを要旨とする。
【0013】
請求項3に記載の発明は、請求項1又は2に記載の開発支援システムにおいて、前記管理票には、進捗状況に関する情報が記録されており、前記制御手段が、前記管理票に記録された進捗状況に基づいて進捗率を算出し、前記進捗率を含めた報告書を作成することを要旨とする。
【0014】
請求項4に記載の発明は、請求項1〜3のいずれか一つに記載の開発支援システムにおいて、前記管理票には、事象が発生した原因システムの識別情報と、この事象の影響に応じて対応が必要な対応システムの識別情報が記録されており、前記制御手段が、利用者情報に関連づけられた、開発対象システムの識別情報を特定し、前記管理票記憶手段に記録された前記管理票の原因システムの識別情報と対応システムの識別情報との組み合わせにおいて、前記開発対象システムの識別情報がいずれか一方の識別情報として記録された管理票を特定し、他方のシステムの識別情報が前記グループ情報記憶手段に記録されていない場合には、利用者に対して、前記他方のシステムの識別情報について、前記グループ情報記憶手段への登録の提案を行なう手段とを更に備えたことを要旨とする。
【0015】
請求項5に記載の発明は、請求項1〜4のいずれか一つに記載の開発支援システムにおいて、開発対象システムの識別情報を取得した場合、前記開発対象システムに関連付けられた関連システムを特定し、前記関連システムについて、前記管理票を用いて不良発生状況を特定し、前記不良発生状況において不良発生回数が基準数より多いと判定した場合には、前記開発対象システムに関して注意喚起を行なうことを要旨とする。
【0016】
請求項6に記載の発明は、請求項1〜5のいずれか一つに記載の開発支援システムにおいて、前記管理票には、開発対象システムにおいて用いられるプログラムのバージョン情報が記録されており、前記制御手段が、開発対象システムのプログラムのリリース承認情報を取得した場合、前記開発対象システムの管理票を取得し、前記管理票において最新バージョンを特定し、リリース可能バージョンとして登録する手段を更に備えたことを要旨とする。
【0017】
請求項7に記載の発明は、利用者情報に関連づけて、開発対象システムの識別情報を記憶するシステムマスタ情報記憶手段と、利用者情報に関連づけて、開発対象システムに関連するシステムの識別情報を記憶するグループ情報記憶手段と、システム開発の管理において、利用者によって作成され、システムの識別情報が記録された管理票を記憶する管理票記憶手段と、クライアント端末に接続された制御手段とを備えた開発支援システムを用いて、システム開発を支援するための方法であって、前記制御手段が、クライアント端末から利用者情報を取得し、前記システムマスタ情報記憶手段及びグループ情報記憶手段から、前記利用者情報に関連付けられたシステムの識別情報を取得する段階と、前記管理票記憶手段から、前記取得したシステムの識別情報が記録された管理票を抽出する段階と、前記抽出した管理票を集約した評価結果を含めた報告書を作成し、前記クライアント端末に出力する段階とを実行することを要旨とする。
【0018】
請求項8に記載の発明は、利用者情報に関連づけて、開発対象システムの識別情報を記憶するシステムマスタ情報記憶手段と、利用者情報に関連づけて、開発対象システムに関連するシステムの識別情報を記憶するグループ情報記憶手段と、システム開発の管理において、利用者によって作成され、システムの識別情報が記録された管理票を記憶する管理票記憶手段と、クライアント端末に接続された制御手段とを備えた開発支援システムを用いて、システム開発を支援するためのプログラムであって、前記制御手段を、クライアント端末から利用者情報を取得し、前記システムマスタ情報記憶手段及びグループ情報記憶手段から、前記利用者情報に関連付けられたシステムの識別情報を取得する手段、前記管理票記憶手段から、前記取得したシステムの識別情報が記録された管理票を抽出する手段、前記抽出した管理票を集約した評価結果を含めた報告書を作成し、前記クライアント端末に出力する手段として機能させることを要旨とする。
【0019】
(作用)
請求項1、7又は8に記載の発明によれば、制御手段が、クライアント端末から利用者情報を取得し、システムマスタ情報記憶手段及びグループ情報記憶手段から、利用者情報に関連付けられたシステムの識別情報を取得する。次に、管理票記憶手段から、取得したシステムの識別情報が記録された管理票を抽出する。そして、抽出した管理票を集約した評価結果を含めた報告書を作成し、クライアント端末に出力する。これにより、開発対象システムに関連するシステムの開発状況を一括して把握することができる。なお、グループ情報記憶手段には、開発対象システムに関連する既存のシステムを登録しておくことにより、既存のシステムについての状況を報告書に含めることも可能である。
【0020】
請求項2に記載の発明によれば、制御手段が、管理票において、用語記憶手段に記録されたキーワードを抽出し、キーワードの出現状況を記録した報告書を作成する。大規模なシステム開発においては、管理票の数が膨大になる。そこで、報告書において、共通したキーワードの出現状況(例えば、出現頻度等)を含めることにより、システム開発状況を提供することができる。
【0021】
請求項3に記載の発明によれば、制御手段が、管理票に記録された進捗状況に基づいて進捗率を算出し、進捗率を含めた報告書を作成する。これにより、進捗率を通じて、システム開発の遅れについての情報を提供することができる。
【0022】
請求項4に記載の発明によれば、制御手段が、利用者情報に関連づけられた、開発対象システムの識別情報を特定する。次に、管理票記憶手段に記録された管理票の原因システムの識別情報と対応システムの識別情報との組み合わせにおいて、開発対象システムの識別情報がいずれか一方の識別情報として記録された管理票を特定する。そして、他方のシステムの識別情報がグループ情報記憶手段に記録されていない場合には、利用者に対して、他方のシステムの識別情報について、グループ情報記憶手段への登録の提案を行なう。これにより、管理票に記録された情報を用いて、関連性があるシステムを特定し、これらのシステムに関する管理票の一元管理を促すことができる。ここで、事象には、後述するように不良や仕様変更等がある。
【0023】
請求項5に記載の発明によれば、制御手段が、開発対象システムの識別情報を取得した場合、開発対象システムに関連付けられた関連システムを特定し、関連システムについて、管理票を用いて不良発生状況を特定する。そして、不良発生が多いシステムの場合には、開発対象システムに関して注意喚起を行なう。これにより、開発対象システムの関連システムにおいて不良が発生しやすいシステムが含まれる場合には、開発担当者に対して注意喚起することができる。
【0024】
請求項6に記載の発明によれば、制御手段が、管理対象システムの承認情報を取得した場合、管理対象システムの管理票を取得する。そして、管理票において最新バージョンを特定し、リリース可能バージョンとして認定する。これにより、管理票を用いてシステム開発状況を把握し、的確なシステムリリースを行なうことができる。
【発明の効果】
【0025】
本発明によれば、開発対象システムについて作成された管理票に基づいて、システム開発の管理を支援するための開発支援システム、開発支援方法及び開発支援プログラムを提供することができる。
【図面の簡単な説明】
【0026】
【図1】本発明の実施形態のシステム概略図。
【図2】本実施形態の管理情報記憶部に記録された各情報の説明図。
【図3】本実施形態で用いる情報の説明図であって、(a)は部署マスタ情報、(b)はシステムマスタ情報、(c)は案件情報、(d)は関連システム情報、(e)はグループ登録情報、(f)はユーザマスタ情報、(g)はテスト件数予定情報、(h)はテスト日誌情報、(i)はテスト件数実績情報の説明図。
【図4】本実施形態で用いる情報の説明図であって、(a)は不良管理票(発生)情報、(b)は不良管理票(対応)情報、(c)は不良対応内容情報、(d)は仕様変更管理票(方針)情報、(e)は仕様変更管理票(対応)情報、(f)は仕様変更対応内容情報の説明図。
【図5】本実施形態の処理手順の説明図。
【図6】本実施形態の処理手順の説明図。
【図7】本実施形態の処理手順の説明図。
【図8】本実施形態の処理手順の説明図。
【図9】本実施形態の処理手順の説明図。
【発明を実施するための形態】
【0027】
以下、本発明を具体化した一実施形態を、図1〜図9に従って説明する。本実施形態では、複数の部署が連携して行なわれるシステム開発において、各部署において作成された管理票を用いて、システム開発案件のテスト期間中における修正開発(不良対応や仕様変更)の管理を行なうために用いる開発支援システム、開発支援方法及び開発支援プログラムとして説明する。本実施形態では、管理票として、システム開発に影響を与える事象(不良発生や仕様変更)を管理するための不良管理票、仕様変更管理票、日々のテスト状況を記録するテスト日誌を用いる。そして、目標の業務処理システムを構築するために、複数のシステム開発やテストが並行して進められ、これらのシステムの開発管理を統合して行なう場合を想定する。
【0028】
本実施形態では、図1に示すように、テスト工程管理サーバ20を用いる。このテスト工程管理サーバ20は、ネットワークを介して、クライアント端末10に接続される。
クライアント端末10は、システム開発の関係者(各システム開発を行なう開発担当者、各部署の管理者、システム開発全体の推進事務担当者)が用いるコンピュータ端末である。このクライアント端末10は、図示しないディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。開発担当者は、このクライアント端末10を用いて、テスト日誌、不良管理票、仕様変更管理票を作成し、テスト工程管理サーバ20にアップロードする。管理者は、このクライアント端末10を用いて、自部署の開発状況を管理するとともに、他部署の開発状況についての情報を入手し、自部署の開発に対する影響を検討する。推進事務担当者は、クライアント端末10を用いて、各開発部署のテスト日誌や不良管理票、仕様変更管理票を取りまとめ、報告書を作成する。
【0029】
テスト工程管理サーバ20は、システム開発におけるテスト期間中の品質管理を支援するためのサーバコンピュータである。このテスト工程管理サーバ20は、制御部21、管理情報記憶部22、用語辞書記憶部23、関連性評価記憶部24、設計情報記憶部25、ライブラリ記憶部26を備えている。
【0030】
ここで、制御部21は、CPU、RAM、ROM(図示せず)等から構成された制御手段を備えており、後述する処理(不良管理段階、仕様変更管理段階、日誌管理段階、グループ登録段階、関連性評価段階、修正開発支援段階、報告書出力段階、ライブラリ管理段階等の各処理)を行なう。そして、制御部21は、図1に示すように、開発支援プログラムにより、アクセス制御手段210、日誌管理手段211、不良管理手段212、仕様変更管理手段213、グループ管理手段214、関連性評価手段215、修正開発支援手段216、報告書出力手段217、ライブラリ管理手段218として機能する。
【0031】
アクセス制御手段210は、クライアント端末10からのアクセスに応じて、ユーザを特定し、後述する各手段に処理を引き継ぐ処理を実行する。
日誌管理手段211は、開発担当者が作成したテスト日誌を取得し、管理情報記憶部22に記録する処理を実行する。更に、日誌管理手段211は、テストの進捗状況を評価する処理を実行する。
【0032】
不良管理手段212は、開発担当者が作成した不良管理票を取得し、管理情報記憶部22に記録する処理を実行する。
仕様変更管理手段213は、開発担当者が作成した仕様変更管理票を取得し、管理情報記憶部22に記録する処理を実行する。
【0033】
グループ管理手段214は、関連システムの関係者(開発担当者や管理者)に情報を提供するために、複数のシステムのグルーピングを行なう処理を実行する。
関連性評価手段215は、キーワードを用いて、関連性があるシステムを検索する処理を実行する。この関連性評価手段215は、関連性があるシステムにおいて用いられる共通キーワードを特定するために、基準語句数に関するデータを保持している。
【0034】
修正開発支援手段216は、修正開発(不良対応や仕様変更)において、不良発生の頻度が高いシステムが関連する場合に注意喚起を行なう処理を実行する。この修正開発支援手段216は、不良発生の頻度を評価するために、不良発生についての基準数に関するデータを保持している。
【0035】
報告書出力手段217は、管理票を集約した評価結果を含めた報告書を作成し、各部署に対して提供する報告書を作成する処理を実行する。
ライブラリ管理手段218は、開発の進捗状況に応じて、開発対象システムのリリースを管理する処理を実行する。
【0036】
管理情報記憶部22は、システムマスタ情報記憶手段、グループ情報記憶手段、管理票記憶手段として機能し、システム開発のテスト期間中における各開発の評価を支援するための各種データが記録される。本実施形態では、図2に示すように、部署マスタ情報D01〜仕様変更対応内容情報D32が記録される。各情報の内容については、図3、図4を用いて説明する。
【0037】
部署マスタ情報D01には、システム開発に関わる各部署を管理するためのマスタデータが記録される。この部署マスタ情報D01は、システム開発に関わる部署が決定されて登録された場合に記録される。この部署マスタ情報D01は、図3(a)に示すように、部署コード、部署名に関するデータを含んで構成される。
【0038】
部署コードデータ領域には、各部署を特定するための識別子に関するデータが記録される。
部署名データ領域には、この部署の名称に関するデータが記録される。
【0039】
システムマスタ情報D02には、開発対象システムの識別情報が記録されたマスタデータが記録される。このシステムマスタ情報D02は、開発対象システムが決定されて登録された場合に記録される。このシステムマスタ情報D02は、図3(b)に示すように、部署コード、システムコード、システム名に関するデータを含んで構成される。
部署コードデータ領域には、このシステムの開発を担当する部署(利用者情報)を特定するための識別子に関するデータが記録される。
システムコードデータ領域には、各開発対象システムを特定するための識別子(識別情報)に関するデータが記録される。なお、開発対象システムに関連する既存のシステムについて登録しておいてもよい。
システム名データ領域には、このシステムの名称に関するデータが記録される。
【0040】
案件情報D03には、システム開発に関わる案件についてのマスタデータが記録される。この案件情報D03は、システム開発案件が決定されて登録された場合に記録される。この案件情報D03は、図3(c)に示すように、案件名、案件番号、主管部署コードに関するデータを含んで構成される。
【0041】
案件名データ領域には、各案件の名称に関するデータが記録される。
案件番号データ領域には、この案件を特定するための識別子に関するデータが記録される。
主管部署コードデータ領域には、この案件を主管する部署を特定するための識別子に関するデータが記録される。
【0042】
関連システム情報D04には、開発対象システムについて関連するシステムを特定するためのデータが記録される。この関連システム情報D04は、各案件において関連するシステムが登録された場合に記録される。この関連システム情報D04は、図3(d)に示すように、案件名、案件番号、システムコード、部署コード、開発規模に関するデータを含んで構成される。
【0043】
案件名データ領域には、各案件の名称に関するデータが記録される。
案件番号データ領域には、この案件を特定するための識別子に関するデータが記録される。
【0044】
システムコードデータ領域には、この案件において開発を行なうシステムを特定するための識別子に関するデータが記録される。ここでは、同じ案件番号が付与された関連システム情報D04に記録されたシステムは、相互に関連性がある。
【0045】
部署コードデータ領域には、このシステム開発に係わる部署を特定するための識別子に関するデータが記録される。
開発規模データ領域には、このシステム開発の規模を特定するための数量(ステップ数やプログラム本数等)に関するデータが記録される。
【0046】
グループ登録情報D05には、開発対象システムに関連するシステムの識別情報が記録され、各部署において報告書の閲覧を希望する関連システムを特定するためのデータが記録される。このグループ登録情報D05は、報告書の閲覧希望を取得した場合に記録される。このグループ登録情報D05は、図3(e)に示すように、グループID、グループ名、部署コード、登録システムコードに関するデータを含んで構成される。
【0047】
グループIDデータ領域には、各グループを特定するための識別子に関するデータが記録される。
グループ名データ領域には、各グループの名称を特定するための識別子に関するデータが記録される。
【0048】
部署コードデータ領域には、この報告書の閲覧を希望した部署を特定するための識別子に関するデータが記録される。
登録システムコードデータ領域には、この部署において報告書の閲覧を希望した対象システムを特定するための識別子に関するデータが記録される。なお、このデータ領域には、開発対象システムに関連する既存のシステムを登録しておくことも可能である。
【0049】
ユーザマスタ情報D06には、システム開発に関わる各開発担当者や管理者、推進事務担当者についてのマスタデータが記録される。このユーザマスタ情報D06は、システム開発に関わる各担当者や管理者、推進事務担当者が決定されて登録された場合に記録される。このユーザマスタ情報D06は、図3(f)に示すように、ユーザID、パスワード、氏名、部署コード、システムコード、権限フラグに関するデータを含んで構成される。
【0050】
ユーザIDデータ領域には、各担当者や管理者を特定するための識別子に関するデータが記録される。
パスワードデータ領域には、各担当者や管理者のユーザ認証を行なうためのパスワードに関するデータが記録される。
【0051】
氏名データ領域には、このユーザの名前に関するデータが記録される。
部署コードデータ領域には、このユーザが属する部署を特定するための識別子に関するデータが記録される。
【0052】
システムコードデータ領域には、このユーザが担当するシステムを特定するための識別子に関するデータが記録される。
権限フラグデータ領域には、このシステム開発において、担当システムの権限を特定するための識別子に関するデータが記録される。
【0053】
テスト件数予定情報D10には、システム開発におけるテストの実施予定に関するデータが記録される。このテスト件数予定情報D10は、システム開発において実施されるテストの予定が登録された場合に記録される。このテスト件数予定情報D10は、図3(g)に示すように、システムコード、工程、部署コード、実施予定日、実施予定件数、実施予定件数(累計)に関するデータを含んで構成される。
【0054】
システムコードデータ領域には、開発対象システムを特定するための識別子に関するデータが記録される。
工程データ領域には、このシステム開発においてテストが実施される工程を特定するための識別子に関するデータが記録される。この工程により、開発の進度を特定することができる。
【0055】
部署コードデータ領域には、このテストを行なう部署を特定するための識別子に関するデータが記録される。
実施予定日データ領域には、テストを実施する予定年月日に関するデータが記録される。
【0056】
実施予定件数データ領域には、この実施予定日において実施されるテスト件数に関するデータが記録される。
実施予定件数(累計)データ領域には、この予定日までに実施されるテスト件数の累計に関するデータが記録される。
【0057】
テスト日誌情報D11には、開発担当者によって作成されたテスト日誌に関するデータが記録される。このテスト日誌情報D11は、テスト日誌が登録された場合に記録される。このテスト日誌情報D11は、図3(h)に示すように、システムコード、工程、部署コード、実施日、起票者、テスト内容、遅延発生状況、問題発生状況に関するデータを含んで構成される。
【0058】
システムコードデータ領域には、このテスト日誌の対象となるシステムを特定するための識別子に関するデータが記録される。
工程データ領域には、テスト日誌の対象となる工程を特定するための識別子に関するデータが記録される。
【0059】
部署コードデータ領域には、このテスト日誌を作成した開発担当者が属する部署を特定するための識別子に関するデータが記録される。
実施日データ領域には、このテスト日誌におけるテストを実施した年月日に関するデータが記録される。
【0060】
起票者データ領域には、このテスト日誌を作成した開発担当者を特定するための識別子(ユーザID)に関するデータが記録される。
テスト内容データ領域には、システム開発にけるテストの内容に関するデータが記録される。
【0061】
遅延発生状況データ領域には、テストの進捗状況において遅延の有無や、その遅延内容に関するデータが記録される。
問題発生状況データ領域には、テスト日誌の対象であるテストにおいて問題発生の有無や、その問題内容に関するデータが記録される。
【0062】
テスト件数実績情報D12には、システム開発において行なわれたテストの実績に関するデータが記録される。このテスト件数実績情報D12は、システム開発においてテスト日誌が登録された場合に記録される。このテスト件数実績情報D12は、図3(i)に示すように、システムコード、工程、部署コード、実施日、実施件数、実施件数(累計)、進捗率に関するデータを含んで構成される。
【0063】
システムコードデータ領域には、開発対象システムを特定するための識別子に関するデータが記録される。
工程データ領域には、このシステム開発においてテストが実施される工程を特定するための識別子に関するデータが記録される。
【0064】
部署コードデータ領域には、このテストを行なった部署を特定するための識別子に関するデータが記録される。
実施日データ領域には、テストが実施された年月日に関するデータが記録される。
実施件数データ領域には、この実施日において実施されたテスト件数に関するデータが記録される。
【0065】
実施件数(累計)データ領域には、この実施日までに実施されたテスト件数の累計に関するデータが記録される。
進捗率データ領域には、テストの実施件数(累計)を、テスト件数予定情報D10の実施予定件数(累計)によって除算した進捗率に関するデータが記録される。
【0066】
不良管理票(発生)D20には、テストにおいて発生した不良についての管理票に関するデータが記録される。この不良管理票(発生)D20は、テストにおいて発生した不良が発見された場合に記録される。この不良管理票(発生)D20は、図4(a)に示すように、不良管理番号、件名、工程、システムコード、作成日、部署コード、不良概要に関するデータを含んで構成される。
【0067】
不良管理番号データ領域には、各不良を特定するための識別子に関するデータが記録される。
件名データ領域には、不良の内容を表わした名称に関するデータが記録される。
工程データ領域には、不良が発生した工程を特定するための識別子に関するデータが記録される。
【0068】
システムコードデータ領域には、不良が発生したシステム(原因システム)を特定するための識別子に関するデータが記録される。
作成日データ領域には、この不良管理票を作成した年月日に関するデータが記録される。
【0069】
部署コードデータ領域には、この不良を発見した部署を特定するための識別子に関するデータが記録される。
不良概要データ領域には、発生した不良の内容に関するデータが記録される。
【0070】
不良管理票(対応)D21には、テストにおいて発生した不良に対する対応についての管理票に関するデータが記録される。この不良管理票(対応)D21は、不良に対して対応すべきシステムの登録が行なわれた場合に生成されて記録される。この不良管理票(対応)D21は、図4(b)に示すように、不良管理番号、枝番号、システムコード、作成日、部署コード、原因、対応に関するデータを含んで構成される。
不良管理番号データ領域には、テストにおいて発生した不良を特定するための識別子に関するデータが記録される。
枝番号データ領域には、不良に対する対応を特定するための識別子に関するデータが記録される。本実施形態では、一つの不良に対して、複数の対応が必要な場合があるため、個別の対応を識別するために枝番号が用いられる。
【0071】
システムコードデータ領域には、発生した不良に対して対応すべきシステム(対応システム)を特定するための識別子に関するデータが記録される。
作成日データ領域には、この不良管理票を作成した年月日に関するデータが記録される。
【0072】
部署コードデータ領域には、不良に対して対応を行なった部署を特定するための識別子に関するデータが記録される。
原因データ領域には、発生した不良の原因に関するデータが記録される。
対応データ領域には、不良に対して行なわれた対応(プログラム変更、類似見直しや再発防止策の策定)に関するデータが記録される。
【0073】
不良対応内容情報D22には、不良に対する対応において作成されたプログラムやドキュメントに関するデータが記録される。この不良対応内容情報D22は、不良に対する対応についてのプログラムやドキュメントが登録された場合に記録される。この不良対応内容情報D22は、図4(c)に示すように、不良管理番号、枝番号、システムコード、対応ファイル、バージョン、対応区分、対応日に関するデータを含んで構成される。
【0074】
不良管理番号データ領域には、テストにおいて発生した不良を特定するための識別子に関するデータが記録される。
枝番号データ領域には、不良に対する対応を個別に特定するための識別子に関するデータが記録される。
【0075】
システムコードデータ領域には、不良対応を行なったシステムを特定するための識別子に関するデータが記録される。
対応ファイルデータ領域には、不良対応に用いたプログラムを特定するためのデータ(プログラム識別子)や、不良対応に関するドキュメントを特定するためのデータ(ドキュメント識別子)が記録される。
【0076】
バージョンデータ領域には、不良対応によって作成されたプログラムやドキュメントのバージョンに関するデータが記録される。
対応区分データ領域には、不良対応の種類を特定するための識別子に関するデータが記録される。
対応日データ領域には、不良対応を実施した年月日に関するデータが記録される。
【0077】
仕様変更管理票(方針)D30には、仕様変更予定システムの方針についての管理票に関するデータが記録される。この仕様変更管理票(方針)D30は、システム開発における仕様変更の方針が決定されて登録された場合に記録される。この仕様変更管理票(方針)D30は、図4(d)に示すように、仕様変更管理番号、件名、工程、システムコード、作成日、部署コード、変更内容、影響内容に関するデータを含んで構成される。
【0078】
仕様変更管理番号データ領域には、各仕様変更を特定するための識別子に関するデータが記録される。
件名データ領域には、仕様変更の内容を表わした名称に関するデータが記録される。
工程データ領域には、仕様変更を行なう工程を特定するための識別子に関するデータが記録される。
【0079】
システムコードデータ領域には、仕様変更を行なうシステム(原因システム)を特定するための識別子に関するデータが記録される。
作成日データ領域には、この仕様変更管理票を作成した年月日に関するデータが記録される。
【0080】
部署コードデータ領域には、仕様変更を行なう部署を特定するための識別子に関するデータが記録される。
変更内容データ領域には、仕様変更の内容に関するデータが記録される。
影響内容データ領域には、仕様変更により発生が予測される影響の内容に関するデータが記録される。
【0081】
仕様変更管理票(対応)D31には、開発対象システムの仕様変更に対する対応についての管理票に関するデータが記録される。この仕様変更管理票(対応)D31は、仕様変更に対して対応すべきシステムの登録が行なわれた場合に生成されて記録される。この仕様変更管理票(対応)D31は、図4(e)に示すように、仕様変更管理番号、枝番号、システムコード、作成日、部署コード、留意事項に関するデータを含んで構成される。
【0082】
仕様変更管理番号データ領域には、システム開発における仕様変更を特定するための識別子に関するデータが記録される。
枝番号データ領域には、この仕様変更に含まれる個別対応を特定するための識別子に関するデータが記録される。本実施形態では、一つの仕様変更に対して、複数の対応が必要な場合があるため、個別の対応を識別するために枝番号が用いられる。
【0083】
システムコードデータ領域には、仕様変更に対して対応すべきシステム(対応システム)を特定するための識別子に関するデータが記録される。
作成日データ領域には、この仕様変更管理票を作成した年月日に関するデータが記録される。
【0084】
部署コードデータ領域には、仕様変更に対して対応を行なった部署を特定するための識別子に関するデータが記録される。
留意事項データ領域には、この対応における留意すべき事項に関するデータが記録される。
【0085】
仕様変更対応内容情報D32には、仕様変更に対する対応において作成されたプログラムやドキュメントに関するデータが記録される。この仕様変更対応内容情報D32は、仕様変更に対する対応についてのプログラムやドキュメントが登録された場合に記録される。この仕様変更対応内容情報D32は、図4(f)に示すように、仕様変更管理番号、枝番号、システムコード、対応ファイル、バージョンに関するデータを含んで構成される。
【0086】
仕様変更管理番号データ領域には、システム開発における仕様変更を特定するための識別子に関するデータが記録される。
枝番号データ領域には、この仕様変更に対する対応を個別に特定するための識別子に関するデータが記録される。
【0087】
システムコードデータ領域には、仕様変更を行なったシステムを特定するための識別子に関するデータが記録される。
対応ファイルデータ領域には、仕様変更の対応に用いたプログラムを特定するためのデータ(プログラム識別子)や、仕様変更の対応に関するドキュメントを特定するためのデータ(ドキュメント識別子)が記録される。
バージョンデータ領域には、仕様変更によって作成されたプログラムやドキュメントのバージョンに関するデータが記録される。
【0088】
用語辞書記憶部23は用語記憶手段として機能する。この用語辞書記憶部23には、管理票に含まれる可能性があるキーワードが記録されている。具体的には、不良管理票や仕様変更管理票において、その内容(原因や対応等)を説明するために用いられる語句(キーワード)が記録されている。
【0089】
関連性評価記憶部24には、各システムの関連性を評価するための評価実績データが記録されている。この評価実績データは、原因システムのシステムコード及び対応システムのシステムコードの組み合わせにおいて、不良発生時に共通して用いられたキーワード(共通キーワード)に関するデータが記録される。
【0090】
設計情報記憶部25には、各システムの設計情報が記録される。この設計情報においては、各システムから出力される情報、この情報が入力されるシステムについてのインターフェース情報が含まれる。このインターフェース情報に基づいて、相互に関連するシステムのシステムコードを特定することができる。
【0091】
ライブラリ記憶部26には、最新バージョン記憶部とリリース可能バージョン記憶部が設けられている。最新バージョン記憶部には、システム開発において作成されたプログラムやドキュメントの最新バージョンが記録される。リリース可能バージョン記憶部には、テストを完了し、本番環境で利用可能なバージョンのプログラムやドキュメントが記録される。
【0092】
上記のように構成されたシステムを用いて、システム開発におけるテストの評価を支援する場合の処理手順について、図5〜図9を用いて説明する。ここでは、概要、関連性評価処理、修正開発支援処理、報告書出力処理、ライブラリ管理処理の順番に説明する。
【0093】
(概要)
まず、図5を用いて、処理の概要を説明する。ここでは、不良管理処理、仕様変更管理処理、テスト日誌管理処理、グループ登録処理の順番で説明する。
【0094】
〔不良管理処理〕
テストにおいて不良を発見した場合、テスト工程管理サーバ20の制御部21は、不良管理票(発生)の入力処理を実行する(ステップS1−1)。具体的には、開発担当者は、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、開発担当者のユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「不良管理票(発生)入力」を選択する。
【0095】
この場合、制御部21のアクセス制御手段210は、不良管理手段212に処理を引き継ぐ。そして、不良管理手段212は、クライアント端末10のディスプレイに不良管理票入力画面を出力する。この不良管理票入力画面には、発生欄と対応欄とが含まれる。開発担当者は、この不良管理票入力画面の発生欄において、ユーザマスタ情報D06に登録されているシステムのテストにおいて発見した不良内容(件名、工程、システムコード、作成日、部署コード、不良概要等)を入力する。発生欄において完了入力が行なわれた場合、制御部21の不良管理手段212は、不良管理番号を採番し、不良管理票(発生)D20を生成して管理情報記憶部22に登録する。
【0096】
次に、テスト工程管理サーバ20の制御部21は、対応システムの登録処理を実行する(ステップS1−2)。具体的には、制御部21の不良管理手段212は、管理情報記憶部22において、原因システムのシステムコードが記録された関連システム情報D04を取得する。そして、不良管理手段212は、同じ案件番号が付与された関連システム情報D04に記録されているシステムコードを取得する。そして、不良管理手段212は、これらのシステムコードに関連付けて、設計情報記憶部25に記録されたインターフェース情報を含めた一覧表示をクライアント端末10のディスプレイに出力する。この場合、開発担当者は、一覧表示から不要なシステムコードを削除したり、必要なシステムコードを追加したりすることにより、対応が必要なシステムのみを選択する。一覧表示において完了入力が行なわれた場合、制御部21の不良管理手段212は、選択された各システムコードに対応する不良管理番号に対して、枝番号を採番する。そして、不良管理手段212は、対応システム毎に不良管理票(対応)D21を生成して管理情報記憶部22に登録する。更に、ここでは、後述する修正開発支援処理を実行する。
【0097】
次に、テスト工程管理サーバ20の制御部21は、不良管理票(対応)の入力処理を実行する(ステップS1−3)。具体的には、対応システムの開発担当者は、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、開発担当者のユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「不良管理票(対応)入力」を選択する。
【0098】
この場合、制御部21のアクセス制御手段210は、不良管理手段212に処理を引き継ぐ。そして、不良管理手段212は、クライアント端末10のディスプレイに不良管理票入力画面を出力する。この不良管理票入力画面には、発生欄と対応欄とが含まれる。開発担当者は、この不良管理票入力画面において、ユーザマスタ情報D06に登録されているシステム(自身が担当する対応システム)の対応欄に、不良に対する対応内容(作成日、部署コード、原因、対応等)を入力する。ここで、不良対応のために作成した対応ファイル(プログラムやドキュメント)がある場合には、対応欄に添付する。
【0099】
対応欄において完了入力が行なわれた場合、制御部21の不良管理手段212は、対応欄に入力された内容を、不良管理票(対応)D21に記録する。更に、対応ファイルが添付されている場合には、不良管理手段212は、不良対応内容情報D22を生成し、管理情報記憶部22に登録する。更に、不良管理手段212は、ライブラリ記憶部26の最新バージョン記憶部に記録された対応ファイルを更新する。この場合、対応ファイルに対してシステムコード、バージョンを関連付けておく。
【0100】
〔仕様変更管理処理〕
仕様変更を行なう場合、テスト工程管理サーバ20の制御部21は、仕様変更管理票(方針)の入力処理を実行する(ステップS1−4)。具体的には、開発担当者は、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、開発担当者のユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「仕様変更管理票(方針)入力」を選択する。
【0101】
この場合、制御部21のアクセス制御手段210は、仕様変更管理手段213に処理を引き継ぐ。そして、仕様変更管理手段213は、クライアント端末10のディスプレイに仕様変更管理票入力画面を出力する。この仕様変更管理票入力画面には、方針欄と対応欄とが含まれる。開発担当者は、この仕様変更管理票入力画面の方針欄において、ユーザマスタ情報D06に登録されているシステムの仕様変更内容(件名、工程、システムコード、作成日、部署コード、変更内容、影響内容等)を入力する。方針欄において完了入力が行なわれた場合、制御部21の仕様変更管理手段213は、仕様変更管理番号を採番し、仕様変更管理票(方針)D30を生成して管理情報記憶部22に登録する。
【0102】
次に、テスト工程管理サーバ20の制御部21は、対応システムの登録処理を実行する(ステップS1−5)。具体的には、制御部21の仕様変更管理手段213は、管理情報記憶部22において、原因システムのシステムコードが記録された関連システム情報D04を取得する。そして、仕様変更管理手段213は、同じ案件番号が付与された関連システム情報D04に記録されているシステムコードを取得する。そして、仕様変更管理手段213は、これらのシステムコード関連付けて、設計情報記憶部25に記録されたインターフェース情報を含めた一覧表示をクライアント端末10のディスプレイに出力する。この場合、開発担当者は、一覧表示から不要なシステムコードを削除したり、必要なシステムコードを追加したりすることにより、対応が必要なシステムのみを選択する。一覧表示において完了入力が行なわれた場合、制御部21の仕様変更管理手段213は、選択された各システムコードに対して、仕様変更管理番号に対して、枝番号を採番する。そして、仕様変更管理手段213は、対応システム毎に仕様変更管理票(対応)D31を生成して管理情報記憶部22に登録する。更に、ここでも、後述する修正開発支援処理を実行する。
【0103】
次に、テスト工程管理サーバ20の制御部21は、仕様変更管理票(対応)の入力処理を実行する(ステップS1−6)。具体的には、対応システムの開発担当者は、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、開発担当者のユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「仕様変更管理票(対応)入力」を選択する。
【0104】
この場合、制御部21のアクセス制御手段210は、仕様変更管理手段213に処理を引き継ぐ。そして、仕様変更管理手段213は、クライアント端末10のディスプレイに仕様変更管理票入力画面を出力する。この仕様変更管理票入力画面には、方針欄と対応欄とが含まれる。開発担当者は、この仕様変更管理票入力画面において、ユーザマスタ情報D06に登録されているシステム(自身が担当する対応システム)の対応欄に、仕様変更に対する対応内容(作成日、部署コード、留意事項等)を入力する。ここで、仕様変更に対する対応のために作成した対応ファイル(プログラムやドキュメント)がある場合には、対応欄に添付する。
【0105】
対応欄において完了入力が行なわれた場合、制御部21の仕様変更管理手段213は、対応欄に入力された内容を、仕様変更管理票(対応)D31に記録する。更に、対応ファイルが添付されている場合には、仕様変更管理手段213は、仕様変更対応内容情報D32を生成し、管理情報記憶部22に登録する。更に、仕様変更管理手段213は、ライブラリ記憶部26の最新バージョン記憶部に記録された対応ファイルを更新する。この場合、対応ファイルに対してシステムコード、バージョンを関連付けておく。
【0106】
〔テスト日誌管理処理〕
テスト日誌の登録を行なう場合、テスト工程管理サーバ20の制御部21は、テスト日誌の入力処理を実行する(ステップS1−7)。具体的には、開発担当者は、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、開発担当者のユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「テスト日誌入力」を選択する。
【0107】
この場合、制御部21のアクセス制御手段210は、日誌管理手段211に処理を引き継ぐ。日誌管理手段211は、クライアント端末10のディスプレイに、ユーザマスタ情報D06に登録されているシステムコードの日誌入力画面を出力する。開発担当者は、この日誌入力画面において、テスト内容(システムコード、工程、部署コード、実施日、実施件数等)を入力する。
【0108】
日誌入力画面において更新入力が行なわれた場合、制御部21の日誌管理手段211は、日誌入力画面に入力されたシステムコード、工程、部署コードが記録された不良管理票(発生)D20、仕様変更管理票(方針)D30を管理情報記憶部22から抽出する。更に、日誌管理手段211は、不良管理票(発生)D20の不良管理番号に対応する不良管理票(対応)D21、仕様変更管理票(方針)D30の仕様変更管理番号に対応する仕様変更管理票(対応)D31を管理情報記憶部22から抽出する。そして、日誌管理手段211は、日誌入力画面の参考欄に各管理票の内容を出力する。
【0109】
更に、テスト工程管理サーバ20の制御部21は、進捗情報の算出処理を実行する(ステップS1−8)。具体的には、制御部21の日誌管理手段211は、日誌入力画面に入力されたシステムコード、工程、部署コードが記録されたテスト件数予定情報D10を、管理情報記憶部22から抽出する。次に、日誌管理手段211は、入力された実施日が実施予定日データ領域に記録されたテスト件数予定情報D10を特定する。そして、日誌管理手段211は、このテスト件数予定情報D10に記録されている実施予定件数、実施予定件数(累計)を取得する。
【0110】
更に、日誌管理手段211は、日誌入力画面に入力されたシステムコード、工程、部署コードが記録されたテスト件数実績情報D12を、管理情報記憶部22から抽出する。次に、日誌管理手段211は、実施日データ領域に記録された日付が直近のテスト件数実績情報D12を特定する。そして、日誌管理手段211は、このテスト件数実績情報D12に記録されている実施件数、実施件数(累計)を取得する。
【0111】
次に、日誌管理手段211は、取得したテスト件数実績情報D12に記録されている実施件数、実施件数(累計)に対して、日誌入力画面に入力された実施件数を加算して、現在の実施件数、実施件数(累計)を算出する。次に、日誌管理手段211は、現在の実施件数(累計)を実施予定件数(累計)で除算して、進捗率を算出する。そして、日誌管理手段211は、実施予定件数、実施予定件数(累計)、実施件数(累計)、進捗率を日誌入力画面に表示する。
【0112】
この場合、開発担当者は、クライアント端末10のディスプレイに表示された参考欄や進捗率等を参照して、日誌入力画面において、テスト内容、遅延発生状況、問題発生状況等を入力する。
【0113】
そして、日誌入力画面において完了入力が行なわれた場合、制御部21の日誌管理手段211は、日誌入力画面に設定された情報を記録したテスト日誌情報D11、テスト件数実績情報D12を生成する。そして、日誌管理手段211は、テスト日誌情報D11、テスト件数実績情報D12を管理情報記憶部22に登録する。
【0114】
〔グループ登録処理〕
また、関連システムのグループ登録を行なう場合、テスト工程管理サーバ20の制御部21は、グループ登録依頼処理を実行する(ステップS1−9)。具体的には、開発担当者は、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、開発担当者のユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「グループ登録」を選択する。
【0115】
この場合、制御部21のアクセス制御手段210は、グループ管理手段214に処理を引き継ぐ。そして、グループ管理手段214は、ユーザマスタ情報D06の部署コードが記録されているシステムマスタ情報D02からシステムコードを取得する。
【0116】
次に、グループ管理手段214は、管理情報記憶部22から、このシステムコードが記録されている不良管理票(発生)D20、不良管理票(対応)D21、仕様変更管理票(方針)D30、仕様変更管理票(対応)D31を抽出する。この場合、原因システム及び対応システムのシステムコードの組み合わせにより、不良発生や仕様変更において影響がある関連システムを特定する。
【0117】
次に、テスト工程管理サーバ20の制御部21は、登録システムとの比較処理を実行する(ステップS1−10)。具体的には、制御部21のグループ管理手段214は、ユーザマスタ情報D06に記録されている部署コードを取得する。そして、グループ管理手段214は、部署コードが記録されているグループ登録情報D05を、管理情報記憶部22から抽出する。次に、グループ管理手段214は、グループ登録情報D05に記録されている登録システムコードと、先に特定した関連システムのシステムコードとを比較する。
【0118】
次に、テスト工程管理サーバ20の制御部21は、グルーピング提案処理を実行する(ステップS1−11)。具体的には、制御部21のグループ管理手段214は、特定した関連システムのシステムコードが、グループ登録情報D05に記録されていない場合、グループ管理手段214は、クライアント端末10に対して、グルーピングを提案するメッセージを出力する。このメッセージには、ステップS1−10の比較結果において、グループ登録情報D05に記録されていなかったシステムコードを含める。
【0119】
そして、テスト工程管理サーバ20の制御部21は、グループ更新処理を実行する(ステップS1−12)。具体的には、制御部21のグループ管理手段214は、クライアント端末10から、システムコードを含んだ登録指示を取得した場合、グループ登録情報D05の登録システムコードデータ領域に、このシステムコードに追加登録する。
【0120】
(関連性評価処理)
次に、図6を用いて、関連性評価処理を説明する。ここでは、不良管理票を用いて、関連性があるシステムを予測する。
【0121】
まず、テスト工程管理サーバ20の制御部21は、関連システムの特定処理を実行する(ステップS2−1)。具体的には、制御部21の関連性評価手段215は、設計情報記憶部25に記録されたインターフェース情報に基づいて、情報の入出力が行なわれる、相互に関連性があるシステムのシステムコードを特定する。
【0122】
次に、テスト工程管理サーバ20の制御部21は、関連システムの更新処理を実行する(ステップS2−2)。具体的には、制御部21の関連性評価手段215は、特定したシステムコードが記録されている評価実績データを、関連性評価記憶部24から取得する。次に、関連性評価手段215は、両方のシステムコードが記録された評価実績データが登録されていない場合には、新たに評価実績データを生成し、記録する。
【0123】
次に、テスト工程管理サーバ20の制御部21は、不良発生頻度が高いかどうかについての判定処理を実行する(ステップS2−3)。具体的には、制御部21の関連性評価手段215は、評価対象期間内の作成日が記録された不良管理票(発生)D20を抽出する。そして、関連性評価手段215は、抽出した不良管理票(発生)D20を用いて不良発生件数を算出し、発生頻度基準件数と比較する。そして、不良発生件数が発生頻度基準数よりも多い場合には、不良発生頻度が高いと判定する。
【0124】
不良発生頻度が低いと判定した場合(ステップS2−3において「NO」の場合)、テスト工程管理サーバ20の制御部21は、関連性評価処理を終了する。
一方、不良発生頻度が高いと判定した場合(ステップS2−3において「YES」の場合)、テスト工程管理サーバ20の制御部21は、共通キーワードの抽出処理を実行する(ステップS2−4)。具体的には、制御部21の関連性評価手段215は、用語辞書記憶部23の中に記録されているキーワードを用いて、不良発生頻度が高い期間の不良管理票(発生)D20の不良概要データ領域に記録されている語句数を計数する。そして、関連性評価手段215は、語句数が基準語句数より多い語句を共通キーワードとして特定する。
【0125】
次に、テスト工程管理サーバ20の制御部21は、共通キーワードを含む不良管理票の検索処理を実行する(ステップS2−5)。具体的には、制御部21の関連性評価手段215は、特定した共通キーワードが不良概要データ領域に記録されている不良管理票(発生)D20を抽出する。この場合には、不良発生頻度が高い期間以外の期間の不良管理票(発生)D20についても用いる。
【0126】
次に、テスト工程管理サーバ20の制御部21は、不良管理票を用いて関連性評価の更新処理を実行する(ステップS2−6)。具体的には、制御部21の関連性評価手段215は、抽出した不良管理票(発生)D20にシステムコードが記録されているシステムを関連システムとして特定する。そして、関連性評価手段215は、両者のシステムコードが記録されている評価実績データに共通キーワードを記録する。
【0127】
(修正開発支援処理)
次に、図7を用いて、修正開発支援処理を説明する。この処理においては、不良管理票を用いて、修正開発(不良対応や仕様変更)における注意喚起を行なう。この処理は、クライアント端末10において、対応システムの登録処理(ステップS1−2、S1−5)を実行する場合に行なわれる。
【0128】
まず、テスト工程管理サーバ20の制御部21は、修正開発対象の特定処理を実行する(ステップS3−1)。具体的には、制御部21の修正開発支援手段216は、管理情報記憶部22において、修正開発対象システムの不良管理票(発生)D20、仕様変更管理票(方針)D30を抽出し、システムコードを特定する。
【0129】
次に、テスト工程管理サーバ20の制御部21は、関連システムの特定処理を実行する(ステップS3−2)。具体的には、制御部21の修正開発支援手段216は、このシステムコードが記録された関連システム情報D04を特定する。そして、修正開発支援手段216は、同じ案件番号が付与された関連システム情報D04に記録されているシステムコードを取得することにより、関連システムを特定する。
【0130】
そして、関連システムの中で、順次、処理対象システムを特定し、以下の処理を繰り返す。
ここでは、テスト工程管理サーバ20の制御部21は、不良発生状況の取得処理を実行する(ステップS3−3)。具体的には、制御部21の修正開発支援手段216は、処理対象システムのシステムコードが記録された不良管理票(発生)D20を、管理情報記憶部22から抽出する。ここでは、予め定められた所定期間の不良管理票(発生)D20を抽出する。
【0131】
次に、テスト工程管理サーバ20の制御部21は、不良発生頻度が高いかどうかについての判定処理を実行する(ステップS3−4)。具体的には、制御部21の修正開発支援手段216は、抽出した不良管理票(発生)D20の総数をカウントする。そして、総数が基準数以上の場合には不良発生頻度が高いと判定する。
【0132】
不良発生頻度が高いと判定した場合(ステップS3−4において「YES」の場合)、テスト工程管理サーバ20の制御部21は、注意喚起処理を実行する(ステップS3−5)。具体的には、制御部21の修正開発支援手段216は、開発担当者のクライアント端末10のディスプレイに、不良発生頻度が高いことを示すメッセージを出力する。一方、不良発生頻度が低いと判定した場合(ステップS3−4において「NO」の場合)、テスト工程管理サーバ20の制御部21は、この関連システムについての処理を終了する。
【0133】
(報告書出力処理)
次に、図8を用いて、報告書出力処理を説明する。
報告書を作成する場合、テスト工程管理サーバ20の制御部21は、報告書作成依頼の取得処理を実行する(ステップS4−1)。具体的には、ユーザは、クライアント端末10を用いて、テスト工程管理サーバ20にアクセスする。この場合、テスト工程管理サーバ20の制御部21のアクセス制御手段210は、クライアント端末10のディスプレイに、ユーザ認証画面を出力し、このユーザのユーザID、パスワードを取得する。このユーザID、パスワードがユーザマスタ情報D06に登録されている場合、クライアント端末10のディスプレイに、メニュー画面を出力する。このメニュー画面において、「報告書作成」を選択する。この場合、制御部21のアクセス制御手段210は、報告書出力手段217に処理を引き継ぐ。
【0134】
次に、テスト工程管理サーバ20の制御部21は、報告対象システムの特定処理を実行する(ステップS4−2)。制御部21の報告書出力手段217は、このユーザのユーザマスタ情報D06に記録されている部署コードを取得し、この部署コードが記録されているシステムマスタ情報D02を管理情報記憶部22から抽出する。そして、報告書出力手段217は、抽出したシステムマスタ情報D02のシステムコードデータ領域に記録されているシステムコード(自システムのシステムコード)を取得する。更に、報告書出力手段217は、この部署コードが記録されているグループ登録情報D05を管理情報記憶部22から抽出する。そして、報告書出力手段217は、抽出したグループ登録情報D05の登録システムコードデータ領域に記録されているシステムコード(他システムのシステムコード)を取得する。そして、システムマスタ情報D02、グループ登録情報D05の登録システムコードデータ領域から取得したシステムコードを用いて報告対象システムとして特定する。
【0135】
まず、不良管理票、仕様変更管理票について以下の処理を実行する。
ここでは、テスト工程管理サーバ20の制御部21は、対応件数の算出処理を実行する(ステップS4−3)。具体的には、制御部21の報告書出力手段217は、自システムのシステムコードが記録されている不良管理票(発生)D20を特定して、自システムの不良発生件数を算出する。更に、報告書出力手段217は、自システムのシステムコードが記録されている仕様変更管理票(方針)D30を特定して、この仕様変更管理票(方針)D30の数により、自システムの仕様変更件数を算出する。次に、報告書出力手段217は、自システムのシステムコードが記録されている不良管理票(対応)D21を特定して、不良による自システムの不良対応件数を算出する。更に、報告書出力手段217は、自システムのシステムコードが記録されている仕様変更管理票(対応)D31を特定して、仕様変更による自システムの仕様変更対応件数を算出する。
【0136】
次に、報告書出力手段217は、自システムにおいて発生した不良や仕様変更に応じて、自システムで対応した件数を算出する。更に、自システムにおいて発生した不良や仕様変更に応じて、他システムで対応した件数を算出する。更に、他システムにおいて発生した不良や仕様変更に応じて、自システムで対応した件数を算出する。
【0137】
次に、テスト工程管理サーバ20の制御部21は、不良管理票、仕様変更管理票に含まれるキーワード抽出処理を実行する(ステップS4−4)。具体的には、制御部21の報告書出力手段217は、報告対象システムのシステムコードが記録されている不良管理票(発生)D20の不良概要データ領域や、不良管理票(対応)D21の原因データ領域や対応データ領域に含まれるキーワードを、工程に関連付けて抽出する。更に、報告書出力手段217は、報告対象システムのシステムコードが記録されている仕様変更管理票(方針)D30の変更内容データ領域、影響内容データ領域や、仕様変更管理票(対応)D31の留意事項データ領域に含まれるキーワードを、工程に関連付けて抽出する。
【0138】
次に、テスト工程管理サーバ20の制御部21は、キーワード分布の算出処理を実行する(ステップS4−5)。具体的には、制御部21の報告書出力手段217は、このシステム開発の工程毎に、出現した各キーワードの総数を算出して、キーワード分布を作成する。
【0139】
次に、テスト日誌について以下の処理を実行する。
ここでは、テスト工程管理サーバ20の制御部21は、テスト日誌に含まれるキーワード抽出処理を実行する(ステップS4−6)。具体的には、制御部21の報告書出力手段217は、テスト日誌情報D11のテスト内容や遅延発生状況、問題発生状況に記録されているキーワードを抽出する。
【0140】
次に、テスト工程管理サーバ20の制御部21は、キーワード分布の算出処理を実行する(ステップS4−7)。具体的には、制御部21の報告書出力手段217は、このシステム開発の工程毎に、出現した各キーワードの総数を算出して、キーワード分布を作成する。
【0141】
次に、テスト工程管理サーバ20の制御部21は、進捗率の評価処理を実行する(ステップS4−8)。具体的には、制御部21の報告書出力手段217は、この工程におけるテストの進捗率を、テスト件数実績情報D12から取得する。次に、報告書出力手段217は、抽出したキーワードの分布と、進捗率とを関連付ける。
【0142】
次に、テスト工程管理サーバ20の制御部21は、報告対象システムの進捗状況の比較処理を実行する(ステップS4−9)。具体的には、制御部21の報告書出力手段217は、取得した各登録システムの進捗率を比較した比較表を生成する。
【0143】
次に、テスト工程管理サーバ20の制御部21は、報告書の提供処理を実行する(ステップS4−10)。具体的には、制御部21の報告書出力手段217は、報告書を作成し、クライアント端末10のディスプレイに出力する。この報告書には、自システムの不良発生件数、他システムの不良による対応件数、登録システム毎に不良管理票やテスト日誌に含まれるキーワード分布、キーワード評価結果、進捗率の評価結果、進捗率の比較表を含める。
【0144】
(ライブラリ管理処理)
次に、図9を用いて、ライブラリ管理処理を説明する。
まず、テスト工程管理サーバ20の制御部21は、承認処理を実行する(ステップS5−1)。具体的には、新たにプログラムをリリースする場合には、管理者は、クライアント端末10を用いてテスト工程管理サーバ20にアクセスする。そして、クライアント端末10を用いて、プログラムを特定して承認入力を行なう。この場合、クライアント端末10は、テスト工程管理サーバ20に対して、プログラムのリリース指示を送信する。このリリース指示には、リリース対象のプログラムを特定するためのデータ(プログラム識別子)を含める。この場合、テスト工程管理サーバ20の制御部21のライブラリ管理手段218が、リリース指示を取得する。
【0145】
次に、テスト工程管理サーバ20の制御部21は、バージョン情報の取得処理を実行する(ステップS5−2)。具体的には、制御部21のライブラリ管理手段218は、リリース対象のプログラム識別子について、ライブラリに記録されているプログラムのバージョン情報を取得する。
【0146】
次に、テスト工程管理サーバ20の制御部21は、対応済みデータの抽出処理を実行する(ステップS5−3)。具体的には、制御部21のライブラリ管理手段218は、リリース対象のプログラム識別子が記録された不良管理票(対応)D21、仕様変更管理票(対応)D31を、管理情報記憶部22から抽出する。次に、ライブラリ管理手段218は、不良管理票(対応)D21の不良管理番号に対応する不良対応内容情報D22、仕様変更管理票(対応)D31の仕様変更管理番号に対応する仕様変更対応内容情報D32に記録されているバージョン情報を取得する。
【0147】
次に、テスト工程管理サーバ20の制御部21は、バージョン情報が一致しているかどうかについての判定処理を実行する(ステップS5−4)。具体的には、制御部21のライブラリ管理手段218は、ライブラリに記録されているプログラムのバージョン情報と、不良対応内容情報D22、仕様変更対応内容情報D32から取得したバージョン情報と比較する。
【0148】
両者のバージョン情報が一致している場合(ステップS5−4において「YES」の場合)、テスト工程管理サーバ20の制御部21は、リリース可能バージョンとして登録処理を実行する(ステップS5−5)。具体的には、制御部21のライブラリ管理手段218は、最新バージョンをリリース可能バージョン記憶部に移し替える。このリリース可能バージョン記憶部に登録されているプログラムについては、本番システム領域に転送されて、本番システムにおいて利用されることになる。
【0149】
一方、両者のバージョン情報が一致していない場合(ステップS5−4において「NO」の場合)、テスト工程管理サーバ20の制御部21は、注意喚起処理を実行する(ステップS5−6)。具体的には、制御部21のライブラリ管理手段218は、バージョンが一致してないことを示すメッセージを、管理者のクライアント端末10に出力する。
【0150】
本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態では、テスト工程管理サーバ20の制御部21は、不良管理票(発生)の入力処理(ステップS1−1)、対応システムの登録処理(ステップS1−2)を実行する。そして、制御部21は、不良管理票(対応)の入力処理を実行する(ステップS1−3)。これにより、システム開発におけるテストにおいて発生した不良情報及び対応状況を一元管理することができる。
【0151】
(2)本実施形態では、テスト工程管理サーバ20の制御部21は、仕様変更管理票(方針)の入力処理(ステップS1−4)、対応システムの登録処理(ステップS1−5)を実行する。そして、制御部21は、仕様変更管理票(対応)の入力処理を実行する(ステップS1−6)。これにより、システム開発において生じた仕様変更及び対応状況を一元管理することができる。
【0152】
(3)本実施形態では、テスト工程管理サーバ20の制御部21は、テスト日誌の入力処理を実行する(ステップS1−7)。更に、制御部21は、不良管理票(発生)D20、不良管理票(対応)D21、仕様変更管理票(方針)D30、仕様変更管理票(対応)D31を管理情報記憶部22から抽出し、日誌入力画面の参考欄に各管理票の内容を出力する。更に、制御部21は、進捗情報の算出処理を実行する(ステップS1−8)。これにより、システム開発におけるテスト日誌を一元管理することで、効率的に進捗状況を把握することができる。更に、開発者においては、不良管理票や仕様変更管理票、進捗状況を参照して、テスト日誌を作成することができる。
【0153】
(4)本実施形態では、テスト工程管理サーバ20の制御部21は、グループ登録依頼処理を実行する(ステップS1−9)。ここでは、不良管理票や仕様変更管理票に記録された原因システム及び対応システムのシステムコードの組み合わせにより、不良発生や仕様変更において影響がある関連システムを特定することができる。
【0154】
更に、テスト工程管理サーバ20の制御部21は、登録システムとの比較処理(ステップS1−10)、グルーピング提案処理(ステップS1−11)を実行する。これにより、関連性があるシステムを登録しておくことにより、自システムに影響を与える可能性がある他システムの状況を把握することができる。
【0155】
(5)本実施形態では、関連性評価処理において、不良発生頻度が高いと判定した場合(ステップS2−3において「YES」の場合)、テスト工程管理サーバ20の制御部21は、共通キーワードの抽出処理を実行する(ステップS2−4)。次に、制御部21は、共通キーワードを含む不良管理票の検索処理(ステップS2−5)、不良管理票を用いて関連性評価の更新処理(ステップS2−6)を実行する。これにより、不良管理票や仕様変更管理票に記録されているキーワードを用いて、関連性があるシステムを特定することができる。そして、この関連性評価結果を用いて、システム点検時等において、併せて点検することが望ましいシステムを特定することができる。
【0156】
(6)本実施形態では、修正開発支援処理において、テスト工程管理サーバ20の制御部21は、修正開発対象の特定処理(ステップS3−1)、関連システムの特定処理(ステップS3−2)を実行する。次に、制御部21は、不良発生状況の取得処理を実行する(ステップS3−3)。そして、不良発生頻度が高いと判定した場合(ステップS3−4において「YES」の場合)、テスト工程管理サーバ20の制御部21は、注意喚起処理を実行する(ステップS3−5)。これにより、不良発生頻度が高いシステムに関連する修正開発について注意喚起することができる。
【0157】
(7)本実施形態では、報告書出力処理において、テスト工程管理サーバ20の制御部21は、対応件数の算出処理を実行する(ステップS4−3)。これにより、不良や仕様変更に応じて影響が大きいシステムを特定することができる。
【0158】
更に、制御部21は、テスト日誌に含まれるキーワード抽出処理(ステップS4−6)、キーワード分布の算出処理(ステップS4−7)、進捗率の評価処理(ステップS4−8)を実行する。これにより、進捗状況の適否をキーワードにより評価することができる。
【0159】
更に、制御部21は、報告対象システムの進捗状況の比較処理を実行する(ステップS4−9)。これにより、進捗状況の進度が揃っていないシステムを把握することができる。
【0160】
(8)本実施形態では、ライブラリ管理処理において、テスト工程管理サーバ20の制御部21は、承認処理(ステップS5−1)、対応済みデータの抽出処理(ステップS5−2)、バージョンのマッチング処理(ステップS5−3)を実行する。バージョンが一致している場合(ステップS5−4において「YES」の場合)、テスト工程管理サーバ20の制御部21は、リリース可能バージョンとして認定処理を実行する(ステップS5−5)。これにより、不良管理票や仕様変更管理票を用いて、的確なバージョンを特定し、プログラムのリリースを行なうことができる。
【0161】
なお、上記各実施形態は以下のように変更してもよい。
・ 上記実施形態では、テスト工程管理サーバ20の制御部21は、報告対象システムの進捗状況の比較処理を実行する(ステップS4−9)。これに代えて、テスト工程管理サーバ20の制御部21は、前回報告の状況の比較処理を実行するようにしてもよい。この場合には、利用者毎に、出力した報告書を記録しておく。そして、新たに報告書を作成する場合には、先の報告書と比較して、比較結果を出力する。これにより、前回の報告書を作成時からの変化を把握することができる。
【0162】
・ 上記実施形態では、テスト工程管理サーバ20の制御部21は、進捗率の評価処理を実行する(ステップS4−8)。具体的には、制御部21の報告書出力手段217は、この工程におけるテストの進捗率を、テスト件数実績情報D12から取得する。次に、報告書出力手段217は、抽出したキーワードの分布と、進捗率とを関連付ける。ここで、不良や仕様変更に対する対応件数と進捗率を関連付けるようにしてもよい。対応件数が多い場合には、テストの進捗が遅れることがあるので、この遅れの原因を把握することができる。
【0163】
・ 上記実施形態では、テスト工程管理サーバ20の制御部21は、グルーピング提案処理を実行する(ステップS1−11)。この場合、原因システム及び対応システムのシステムコードの組み合わせにより、不良発生や仕様変更において影響がある関連システムを特定する。そして、制御部21のグループ管理手段214は、特定した関連システムのシステムコードが、グループ登録情報D05に記録されていない場合、グループ管理手段214は、クライアント端末10に対して、グルーピングを提案するメッセージを出力する。これに加えて、関連性評価記憶部24に記録されている評価実績データを用いて、メッセージを出力することも可能である。この場合には、グルーピング提案メッセージに、グループ登録情報D05に記録されていない関連システムについて、関連性評価記憶部24に記録されている共通キーワードを含める。これにより、共通キーワードを参照して、グループ登録の要否を判断することができる。
【0164】
・ 上記実施形態では、不良発生頻度が高いと判定した場合(ステップS2−3において「YES」の場合)、テスト工程管理サーバ20の制御部21は、共通キーワードの抽出処理を実行する(ステップS2−4)。そして、テスト工程管理サーバ20の制御部21は、共通キーワードを含む不良管理票の検索処理(ステップS2−5)、不良管理票を用いて関連性評価の更新処理(ステップS2−6)を実行する。ここで、キーワードを用いて、システム開発における通常状態とは異なる事態発生を検知するようにしてもよい。この場合、テスト工程管理サーバ20に、標準情報記憶手段としての出現パターン記憶部を設けておく。この出現パターン記憶部には、開発担当者が作成するテスト日誌、不良管理票、仕様変更管理票において利用されるキーワード(標準パターン)が記録される。標準パターンにおいては、システム開発の各工程において、一般的に利用されるキーワードや出現頻度が記録されている。
【0165】
そして、報告書出力処理において、テスト工程管理サーバ20の制御部21は、キーワードの評価処理を実行する。具体的には、制御部21の報告書出力手段217は、標準パターンを出現パターン記憶部から取得する。次に、報告書出力手段217は、標準パターンと、今回のシステム開発におけるキーワード分布とを比較する。そして、報告書出力手段217は、標準パターンと分布が一致するキーワードについては、標準的な不良発生や仕様変更と判断する。一方、標準パターンと異なる分布を有するキーワードについては、注意すべきキーワードとして特定し、注意すべきキーワードを報告書の中に含める。通常、初期段階や最終段階等の工程によって発生する不良や仕様変更は異なる。従って、各工程に応じた、不良管理票や仕様変更管理票に記録されたキーワードの出現状況によって、開発状況を評価することができる。
【0166】
・ 上記実施形態では、関連性評価処理を、不良管理票を用いて実行する。ここで、仕様変更管理票を用いて、関連性評価処理を行なうようにしてもよい。
【符号の説明】
【0167】
10…クライアント端末、20…テスト工程管理サーバ、21…制御部、210…アクセス制御手段、211…日誌管理手段、212…不良管理手段、213…仕様変更管理手段、214…グループ管理手段、215…関連性評価手段、216…修正開発支援手段、217…報告書出力手段、218…ライブラリ管理手段、22…管理情報記憶部、23…用語辞書記憶部、24…関連性評価記憶部、25…設計情報記憶部、26…ライブラリ記憶部。

【特許請求の範囲】
【請求項1】
利用者情報に関連づけて、開発対象システムの識別情報を記憶するシステムマスタ情報記憶手段と、
利用者情報に関連づけて、開発対象システムに関連するシステムの識別情報を記憶するグループ情報記憶手段と、
システム開発の管理において、利用者によって作成され、システムの識別情報が記録された管理票を記憶する管理票記憶手段と、
クライアント端末に接続された制御手段とを備えた開発支援システムであって、
前記制御手段が、
クライアント端末から利用者情報を取得し、前記システムマスタ情報記憶手段及びグループ情報記憶手段から、前記利用者情報に関連付けられたシステムの識別情報を取得する手段と、
前記管理票記憶手段から、前記取得したシステムの識別情報が記録された管理票を抽出する手段と、
前記抽出した管理票を集約した評価結果を含めた報告書を作成し、前記クライアント端末に出力する手段と
を備えたことを特徴とする開発支援システム。
【請求項2】
開発において使用されるキーワードを記憶した用語記憶手段を更に備え、
前記制御手段が、前記管理票において、前記用語記憶手段に記録されたキーワードを抽出し、前記キーワードの出現状況を記録した報告書を作成することを特徴とする請求項1に記載の開発支援システム。
【請求項3】
前記管理票には、進捗状況に関する情報が記録されており、
前記制御手段が、前記管理票に記録された進捗状況に基づいて進捗率を算出し、前記進捗率を含めた報告書を作成することを特徴とする請求項1又は2に記載の開発支援システム。
【請求項4】
前記管理票には、事象が発生した原因システムの識別情報と、この事象の影響に応じて対応が必要な対応システムの識別情報が記録されており、
前記制御手段が、
利用者情報に関連づけられた、開発対象システムの識別情報を特定し、
前記管理票記憶手段に記録された前記管理票の原因システムの識別情報と対応システムの識別情報との組み合わせにおいて、前記開発対象システムの識別情報がいずれか一方の識別情報として記録された管理票を特定し、
他方のシステムの識別情報が前記グループ情報記憶手段に記録されていない場合には、利用者に対して、前記他方のシステムの識別情報について、前記グループ情報記憶手段への登録の提案を行なう手段と
を更に備えたことを特徴とする請求項1〜3のいずれか一つに記載の開発支援システム。
【請求項5】
開発対象システムの識別情報を取得した場合、前記開発対象システムに関連付けられた関連システムを特定し、
前記関連システムについて、前記管理票を用いて不良発生状況を特定し、
前記不良発生状況において不良発生回数が基準数より多いと判定した場合には、前記開発対象システムに関して注意喚起を行なうことを特徴とする請求項1〜4のいずれか一つに記載の開発支援システム。
【請求項6】
前記管理票には、開発対象システムにおいて用いられるプログラムのバージョン情報が記録されており、
前記制御手段が、
開発対象システムのプログラムのリリース承認情報を取得した場合、前記開発対象システムの管理票を取得し、
前記管理票において最新バージョンを特定し、リリース可能バージョンとして登録する手段を更に備えたことを特徴とする請求項1〜5のいずれか一つに記載の開発支援システム。
【請求項7】
利用者情報に関連づけて、開発対象システムの識別情報を記憶するシステムマスタ情報記憶手段と、
利用者情報に関連づけて、開発対象システムに関連するシステムの識別情報を記憶するグループ情報記憶手段と、
システム開発の管理において、利用者によって作成され、システムの識別情報が記録された管理票を記憶する管理票記憶手段と、
クライアント端末に接続された制御手段とを備えた開発支援システムを用いて、システム開発を支援するための方法であって、
前記制御手段が、
クライアント端末から利用者情報を取得し、前記システムマスタ情報記憶手段及びグループ情報記憶手段から、前記利用者情報に関連付けられたシステムの識別情報を取得する段階と、
前記管理票記憶手段から、前記取得したシステムの識別情報が記録された管理票を抽出する段階と、
前記抽出した管理票を集約した評価結果を含めた報告書を作成し、前記クライアント端末に出力する段階と
を実行することを特徴とする開発支援方法。
【請求項8】
利用者情報に関連づけて、開発対象システムの識別情報を記憶するシステムマスタ情報記憶手段と、
利用者情報に関連づけて、開発対象システムに関連するシステムの識別情報を記憶するグループ情報記憶手段と、
システム開発の管理において、利用者によって作成され、システムの識別情報が記録された管理票を記憶する管理票記憶手段と、
クライアント端末に接続された制御手段とを備えた開発支援システムを用いて、システム開発を支援するためのプログラムであって、
前記制御手段を、
クライアント端末から利用者情報を取得し、前記システムマスタ情報記憶手段及びグループ情報記憶手段から、前記利用者情報に関連付けられたシステムの識別情報を取得する手段、
前記管理票記憶手段から、前記取得したシステムの識別情報が記録された管理票を抽出する手段、
前記抽出した管理票を集約した評価結果を含めた報告書を作成し、前記クライアント端末に出力する手段
として機能させることを特徴とする開発支援プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2013−97450(P2013−97450A)
【公開日】平成25年5月20日(2013.5.20)
【国際特許分類】
【出願番号】特願2011−237528(P2011−237528)
【出願日】平成23年10月28日(2011.10.28)
【出願人】(592131906)みずほ情報総研株式会社 (187)
【Fターム(参考)】