(57)【要約】      （修正有）【課題】データの入力に際し開発者等に過度の負担や高いスキルなしで、プログラムの開発状況をタイムリーに提示可能なシステムを提供する。【解決手段】問題指摘対象プログラムを特定する入力欄と、問題の深刻度や要因等の属性を表す複数の選択肢を備えた評価対象選択項目が複数設定された問題指摘情報登録用画面を送信する手段と、ユーザ端末30から送信された問題指摘情報を問題指摘情報ＤＢ22に格納する手段と、選択項目の各選択肢ごとの重み係数を格納する定義情報ＤＢ14と、格納されたプログラム毎の問題指摘情報の件数を、選択肢ごとに集計する処理と、各選択肢の件数に重み係数を適用して、選択項目ごとの評価点を算出する処理と、この評価点が記載された集計表を生成する処理を実行する演算処理部24と、集計表を含む画面をユーザ端末30に送信するWeb処理部26とを備えたプログラムの開発状況評価システム10。【選択図】図１
2009193186.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末に対して、少なくとも問題指摘対象プログラムを特定するための入力欄と、問題の深刻度や要因等の属性を表す複数の選択肢を備えた評価対象選択項目が複数設定された問題指摘情報登録用画面を送信する手段と、
ユーザ端末から送信された問題指摘情報を、問題指摘情報記憶手段に格納する手段と、
上記評価対象選択項目の各選択肢ごとに設定された重み係数を格納しておく記憶手段と、
上記問題指摘情報記憶手段に格納されたプログラム毎の問題指摘情報の件数を、選択肢ごとに集計する集計手段と、
各選択肢の件数に上記重み係数を適用して、評価対象選択項目ごとの評価点を算出する評価点算出手段と、
この評価点が記載された画面をユーザ端末に送信する手段と、
を備えたことを特徴とするプログラムの開発状況評価システム。
【請求項２】
上記問題指摘対象プログラムを特定するための入力欄が、プログラムの最小単位を特定するための入力欄と、当該最小単位のプログラムが属する１または複数の上位階層を特定するための入力欄からなり、
上記集計手段は、問題指摘情報の件数をプログラムの最小単位及び上位階層単位で集計し、
上記評価点算出手段は、各選択項目の評価点をプログラムの最小単位及び上位階層単位で算出することを特徴とする請求項１に記載のプログラムの開発状況評価システム。
【請求項３】
各評価対象選択項目に対応した軸を備え、各軸にそれぞれの評価点をプロットしたレーダーチャートを生成する手段と、
このレーダーチャートを含む画面をユーザ端末に送信する手段と、
を備えたことを特徴とする請求項１または２に記載のプログラムの開発状況評価システム。
【請求項４】
上記問題指摘情報登録用画面には、問題の対策状況を示す複数の選択肢を備えた選択項目と、問題の指摘日を特定するための入力欄を備えており、
各問題指摘情報の累積件数を指摘日に沿ってプロットした不良成長曲線と、対策が完了した問題指摘情報の累積件数を指摘日に沿ってプロットした対処完了曲線が表示されたグラフを生成する手段と、
このグラフを含む画面をユーザ端末に送信する手段と、
を備えたことを特徴とする請求項１〜３の何れかに記載のプログラムの開発状況評価システム。
【請求項５】
少なくとも一部の評価対象選択項目の評価点を項目別診断点に変換するためのルールを設定しておく記憶手段と、
上記評価対象選択項目別の評価点にこの変換ルールを適用して、項目別の診断点を算出する手段と、
全項目別診断点を加算して、プログラム別の診断点を導く手段と、
この診断点が記載された画面をユーザ端末に送信する手段と、
を備えたことを特徴とする請求項１〜４の何れかに記載のプログラムの開発状況評価システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はプログラムの開発状況評価システムに係り、特に、バグ等の問題指摘情報に基づいてコンピュータプログラムの品質を判定・評価する機能を備えたシステムに関する。
【背景技術】
【０００２】
コンピュータプログラムが複雑化・大規模化するに従い、多くの人員が開発に投入され、細分化された多数のモジュール単位でそれぞれの開発が進行するようになってきており、プログラム全体での品質を常時把握することが、最終的に当該プロジェクトを成功に導くために不可欠となっている。
【０００３】
例えば、特許文献１においては、ソフトウェアの品質予定データと実績データとを比較してプロジェクトの評価値を算出し、この評価値が一定の品質基準を満たしていない場合には電子メールで品質管理担当者に通報する機能を備えたソフトウェア品質評価システムが開示されている。
【特許文献１】特開２００３−３４５９１８
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この結果、品質管理担当者は、問題発生の可能性が高いプロジェクトを迅速に認識することができ、素早い対応が可能となる。
しかしながら、このソフトウェア品質評価システムの運用に際して、各開発担当者には事前に作業工数、規模、エラー数、レビュー工数、終了日の予定データを、基本設計、詳細設計、コーディングのフェーズ毎に入力することが求められ、極めて煩雑な作業の押し付けとなることはもちろんのこと、正確なデータの入力には高いスキルが求められる点で問題があった。
【０００５】
この発明は、このような従来の問題を解決するために案出されたものであり、データの入力に際してプログラムの開発者等に過度の負担を与えることなく、また高いスキルを求めることもなく、開発プログラムの品質や現状をタイムリーに提示することが可能な技術の実現を目的としている。
【課題を解決するための手段】
【０００６】
上記の目的を達成するため、請求項１に記載したプログラムの開発状況評価システムは、ユーザ端末に対して、少なくとも問題指摘対象プログラムを特定するための入力欄と、問題の深刻度や要因等の属性を表す複数の選択肢を備えた評価対象選択項目が複数設定された問題指摘情報登録用画面を送信する手段と、ユーザ端末から送信された問題指摘情報を、問題指摘情報記憶手段に格納する手段と、上記評価対象選択項目の各選択肢ごとに設定された重み係数を格納しておく記憶手段と、上記問題指摘情報記憶手段に格納されたプログラム毎の問題指摘情報の件数を、選択肢ごとに集計する集計手段と、各選択肢の件数に上記重み係数を適用して、評価対象選択項目ごとの評価点を算出する評価点算出手段と、この評価点が記載された画面（HTMLファイル）をユーザ端末に送信する手段とを備えたことを特徴としている。
【０００７】
請求項２に記載したプログラムの開発状況評価システムは、請求項１のシステムであって、さらに上記問題指摘対象プログラムを特定するための入力欄が、プログラムの最小単位（例えば「モジュール」）を特定するための入力欄と、当該最小単位のプログラムが属する１または複数の上位階層（例えば「管理」や「システム」）を特定するための入力欄からなり、上記集計手段は、問題指摘情報の件数をプログラムの最小単位及び上位階層単位で集計し、上記評価点算出手段は、各選択項目の評価点をプログラムの最小単位及び上位階層単位で算出することを特徴としている。
【０００８】
請求項３に記載したプログラムの開発状況評価システムは、請求項１または２のシステムであって、さらに、各評価対象選択項目に対応した軸を備え、各軸にそれぞれの評価点をプロットしたレーダーチャートを生成する手段と、このレーダーチャートを含む画面をユーザ端末に送信する手段とを備えたことを特徴としている。
【０００９】
請求項４に記載したプログラムの開発状況評価システムは、請求項１〜３のシステムであって、さらに上記問題指摘情報登録用画面には、問題の対策状況を示す複数の選択肢を備えた選択項目と、問題の指摘日を特定するための入力欄を備えており、各問題指摘情報の累積件数を指摘日に沿ってプロットした不良成長曲線と、対策が完了した問題指摘情報の累積件数を指摘日に沿ってプロットした対処完了曲線が表示されたグラフを生成する手段と、このグラフを含む画面をユーザ端末に送信する手段とを備えたことを特徴としている。
【００１０】
請求項５に記載したプログラムの開発状況評価システムは、請求項１〜４のシステムであって、さらに、少なくとも一部の評価対象選択項目の評価点を項目別診断点に変換するためのルールを設定しておく記憶手段と、上記評価対象選択項目別の評価点にこの変換ルールを適用して、項目別の診断点を算出する手段と、全項目別診断点を加算して、プログラム別の診断点を導く手段と、この診断点が記載された画面をユーザ端末に送信する手段とを備えたことを特徴としている。
【発明の効果】
【００１１】
請求項１に記載したプログラムの開発状況評価システムの場合、プログラムの開発担当者あるいはテスト担当者は、バグ等の問題を発見した時点で、問題指摘情報登録用画面を通じて対象となるプログラム及び問題の属性を入力するだけで登録が完了し、あとはシステムの側で自動的に問題指摘情報の集計及び評価点の算出を実行する仕組みを備えている。
しかも、問題の属性を入力するに際しては、予め設定された選択肢の中から該当のものを選択するだけで済むため、忙しい業務の合間であっても簡単に入力を済ますことができる。
また、プロジェクトマネージャ等の管理者は、上記の評価点を参照することにより、プログラム開発の現状やプログラムの品質を正確に把握することができ、増員等の必要な措置を迅速に執ることが可能となる。
【００１２】
請求項２に記載したプログラムの開発状況評価システムの場合、プログラムモジュール単位及びその上位階層（例えば、管理、システム等）単位で評価点が算出される仕組みであるため、管理者は様々な粒度でプログラム開発の現状や品質を把握することが可能となる。
【００１３】
請求項３に記載したプログラムの開発状況評価システムの場合、上記の評価点がレーダーチャートによって表示されるため、プログラム開発の現状や品質を視覚的に認識可能となる。
【００１４】
請求項４に記載したプログラムの開発状況評価システムによれば、不良成長曲線と対処完了曲線との開き具合により、一目でバグ等の解決状況を認識することが可能となる。
【００１５】
請求項５に記載したプログラムの開発状況評価システムによれば、選択項目毎の評価点のみならず、各評価点に基づいて対象プログラム全体の評価が示されるため、プログラム開発の現状を総合的な観点から認識することが可能となる。
【発明を実施するための最良の形態】
【００１６】
図１は、この発明に係るプログラムの開発状況評価システム10の全体構成を示すブロック図であり、定義情報登録部12と、定義情報ＤＢ14と、テスト情報登録部16と、テスト情報ＤＢ18と、問題指摘情報登録部20と、問題指摘情報ＤＢ22と、演算処理部24と、Web処理部26とを備えている。
【００１７】
上記の定義情報登録部12、テスト情報登録部16、問題指摘情報登録部20、演算処理部24、及びWeb処理部26は、サーバコンピュータのCPU が、OS及び専用のアプリケーションプログラムに従って必要な処理を実行することによって実現される。
また、上記の定義情報ＤＢ14、テスト情報ＤＢ18、問題指摘情報ＤＢ22は、同コンピュータのハードディスク内に設けられている。
このシステム10は、１台のサーバコンピュータによって構成することもできるが、相互にネットワーク接続された複数のサーバコンピュータによって構成することもできる。
【００１８】
このシステム10は、インターネットやイントラネット等の通信ネットワーク28を介して、多数のユーザ端末30と接続されている。
ユーザ端末30は、プログラムの開発担当者やテスト担当者、プロジェクトマネージャなど一定の権限を有する者が操作するものであり、OS及びWebブラウザプログラムが搭載されたPC等より構成される。
【００１９】
上記のWeb処理部26は、所謂Webサーバ機能を提供するものであり、各種の入力画面や表示画面を生成し、ユーザ端末30に送信する処理の他、各ユーザのログイン時の認証処理、各ユーザ端末30から送信された入力データを定義情報登録部12、テスト情報登録部16、問題指摘情報登録部20に渡す処理、演算処理部24から送信された算出結果データを表示するための画面を生成し、ユーザ端末30に送信する処理等を実行する。
【００２０】
つぎに、図２及び図３のフローチャートに従い、このシステム10の処理手順について説明する。
まず、プロジェクトマネージャ等の管理者は、システム10に対して事前に各種定義情報を登録しておくことが求められる。
すなわち、管理者の操作するユーザ端末30から定義情報登録のリクエストを受信したWeb処理部26は、定義情報登録用の画面を生成し、ユーザ端末30に送信する（Ｓ10、Ｓ12）。
【００２１】
図示は省略したが、この定義情報登録用画面には、複数の評価対象選択項目についての重み係数を設定する入力フィールドや、各評価対象選択項目に係る評価点に基づいて項目別診断点を算出する際の変換ルールを設定する入力フィールド等が設けられている。重み係数や変換ルールの詳細に関しては、後述する。
ユーザ端末30から送信された定義情報を、Web処理部26経由で受け取った定義情報登録部12は、これらを定義情報ＤＢ14に格納する（Ｓ14）。
【００２２】
また、プログラムの開発担当者やテスト担当者には、システム10に対して事前にプログラムテストの項目情報を登録しておくことが求められる。
すなわち、ユーザ端末30からテスト項目情報登録のリクエストを受信したWeb処理部26は、テスト項目情報登録用の画面を生成し、ユーザ端末30に送信する（Ｓ16、Ｓ18）。
【００２３】
図示は省略したが、このテスト項目情報登録用画面には、単体テスト、結合テスト、総合テスト、システムテスト等の各段階毎に、具体的なテスト項目を設定する入力フィールドが設けられている。
ユーザ端末30から送信されたテスト項目情報をWeb処理部26経由で受け取ったテスト情報登録部16は、これらをテスト情報ＤＢ18に格納する（Ｓ20）。
【００２４】
また、プログラムの開発担当者やテスト担当者には、システム10に対してプログラムテストの実施情報を適時登録することが求められる。
すなわち、ユーザ端末30からテスト実施情報登録のリクエストを受信したWeb処理部26は、テスト実施情報登録用の画面を生成し、ユーザ端末30に送信する（Ｓ22、Ｓ24）。
【００２５】
図示は省略したが、この登録用画面には、単体テスト、結合テスト、総合テスト、システムテストの各段階毎に、消化したテスト項目及びテスト実施日を入力するためのフィールドが設けられている。
ユーザ端末30から送信されたテスト実施情報をWeb処理部26経由で受け取ったテスト情報登録部16は、これらをテスト情報ＤＢ18に格納する（Ｓ26）。
【００２６】
さらに、プログラムの開発担当者やテスト担当者には、システム10に対して開発プログラムに関するバグ等の問題を指摘する情報を適時登録することが求められる。
すなわち、ユーザ端末30から問題指摘情報登録のリクエストを受信したWeb処理部26は、問題指摘情報登録用の画面を生成し、ユーザ端末30に送信する（Ｓ28、Ｓ30）。
【００２７】
図４及び図５は、問題指摘情報登録用画面40の一例を示すものであり、システム10によって自動的に採番されるユニークな管理番号が表示されると共に、各種のテキスト入力項目や選択項目が設けられている。
ここで指摘される「問題」としては、プログラムに含まれる誤りや不具合であるバグが典型例であるが、その他にも、機能の追加や修正あるいはハードウエアの不良等に基づき、プログラムに何らかの対策を施す必要が生じた場合を広く含む概念である。
以下、主な入力項目及び選択項目の意義について説明する。
【００２８】
「指摘者名」・・・バグ等の問題（以下「バグ等」）を最初に発見したユーザの氏名を入力する欄。
「開発者名」・・・バグ等を指摘されたモジュールの開発担当者の氏名を入力する欄。
「管理名」・・・バグ等を指摘されたモジュールが属する上位のプログラム形態である管理の名前を入力する欄。
「モジュール名」・・・バグ等を指摘されたモジュールの名前を入力する欄。
「発生日」・・・バグ等を指摘された日付を記入する欄。
「判明日」・・・問題の原因が判明した日付を記入する欄。
「確認日」・・・不良の修正及びテストが完了した日付、または指摘ミスが判明した日付を記入する欄。
「対策状況」・・・バグ等の指摘に対する現在の状況を選択入力する欄であり、「A. 調査中」、「B. 判明」、「C. 対策完了」の選択肢が設定されている。
「判定」・・・今回のバグ等の類型を選択入力する欄であり、「A. ソフト不良」、「B. 仕様」、「C. 指摘ミス」、「D. 機能追修（機能の追加、修正、変更）」、「E. ハード不良」の選択肢が設定されている。
「現象・要求」・・・不良の現象、機能追加要求等の具体的内容をフリーワードで入力する欄。
「原因・方法」・・・不良の原因や機能追加要求等の実現方法をフリーワードで入力する欄。
「修正内容」・・・実際に行った修正の処理方式等をフリーワードで入力する欄。
「発生Ver:」・・・バグ等を指摘されたモジュールのバージョン情報を入力する欄。
「修正Ver:」・・・修正を施した結果、モジュールのバージョンが更新された場合に、新たなバージョン情報を入力する欄。
「重要度」・・・今回のバグ等のシステム全体に与える影響の大きさを選択入力する欄であり、「A. 重大不良」、「B. 機能不良」、「C. 軽微不良」の選択肢が設定されている。
「要因」・・・今回のバグ等の直接的な原因を選択入力する欄であり、「A. 不注意」、「B. 仕様不備」、「C. 検討不足」、「D. 理解不足」の選択肢が設定されている。
「作り込み」・・・今回のバグ等の種が開発工程のどの段階で仕込まれたのかを選択入力する欄であり、「A. プロジェクト計画」、「B. 基本設計」、「C. 機能設計」、「D. 詳細設計」、「E. コーディング」の選択肢が設定されている。
「規約・ツール」・・・今回のバグ等が規約違反や決められたツールの不使用に基づくものである場合に選択入力する欄であり、「A. 規約違反」、「B. ツール不使用」の選択肢が設定されている。
「形態」・・・今回のバグ等の形態を選択入力する欄であり、「A. デグレード」、「B. 修正不十分」、「C. 新規不良」、「D. 潜在不良」、「E. ドキュメント」の選択肢が設定されている。
「デバッグ工程」・・・今回のバグ等がテスト工程のどの段階で指摘されたのかを選択入力する欄であり、「A. 机上」、「B. 単体」、「C. 結合」、「D. 総合」、「E. システムテスト」の選択肢が設定されている。
【００２９】
このような問題指摘情報登録用画面40に対しユーザは、必要な入力項目に文字列を打鍵入力したり、選択項目中のラジオボタンにチェックを入れていく。
例えば、開発担当者自身が単体テスト前に自らバグ等を発見した場合には、「指摘者名」及び「開発者名」の入力欄に自己の氏名を入力する。
また、「モジュール名」の入力欄にバグ等が発生したモジュールの識別コードを入力すると同時に、「管理名」の入力欄に当該モジュールが属する管理の識別コードを入力する。
つぎに開発担当者は、「対策状況」の選択欄において「A. 調査中」の選択肢にチェックを入れると共に、「判定」の選択欄において「A. ソフト不良」の選択肢にチェックを入れる。
【００３０】
引き続き開発担当者は、現時点で入力あるいは選択可能な各項目に対する入力・選択を行う。例えば、「発生Ver:」入力欄に当該モジュールの現バージョン情報を入力する。また、「重要度」選択欄の「C. 軽微不良」、「要因」選択欄の「A. 不注意」、「作り込み」選択欄の「E. コーディング」、「規約・ツール」選択欄の「規約違反」、「形態」選択欄の「C. 新規不良」、「デバッグ工程」選択欄の「A. 机上」、の各ラジオボタンにチェックを入れる。
【００３１】
必要な項目に対する入力及び選択を完了した開発者が「登録」ボタン42をクリックすると、ユーザ端末30からWeb処理部26に対して問題指摘情報が送信される。
Web処理部26経由で問題指摘情報を受け取った問題指摘情報登録部20は（Ｓ30）、これを問題指摘情報ＤＢ22に格納する（Ｓ32）。
【００３２】
図６は、問題指摘情報のデータ構造を示すものであり、管理番号を筆頭に、対策状況、判定、現象・要求、原因・方法、修正内容、指摘者名、管理名、モジュール名、開発者名、発生日、…重要度、要因、作り込み、規約・ツール、形態、デバッグ工程等のデータ項目を備えている。
【００３３】
開発担当者は、一旦登録した問題指摘情報に対して、いつでも追加・修正を行うことができる。
例えば、対策状況について当初「A. 調査中」としていたところ、対策内容が判明した時点で「B. 判明」にチェックを入れ直し、対策が完了した時点で「C. 対策完了」に最終的なチェックを入れることができる。
また、対策を施したことによって当該モジュールのバージョンに変更が生じた場合には、「修正Ver:」入力欄に新たなバージョンを追記する必要がある。
【００３４】
問題指摘情報は、複数のユーザによって登録・更新することもできる。
例えば、バグ等の発見者が単体テストを実施中のテスト担当者であった場合、まずはこのテスト担当者によって「指摘者名」、「発生日」、「現象・要求」、「発生Ver:」、「重要度」、「デバッグ工程」の各項目に対する入力・選択が行われ、問題指摘情報の新規登録がなされる。
その後、テスト担当者からの連絡を受けた開発担当者は、ユーザ端末30からシステム10に接続し、管理番号を入力して当該問題指摘情報登録用画面40を呼び出し、残りの項目に対する入力・選択を続ける。
【００３５】
以上のようにして、問題指摘情報ＤＢ22に格納された問題指摘情報については、権限のあるユーザは何時でも参照することができる。
すなわち、開発中のシステムの現状を把握しておきたいと考えたプロジェクトマネージャがシステム10にアクセスし、サービスメニューから「集計表の作成」を選択すると、このリクエストを受けた演算処理部24は（Ｓ34）、問題指摘情報ＤＢ22に格納された問題指摘情報の件数を、各選択項目の選択肢別、プログラムモジュール別、管理別、システム別に集計し（Ｓ36）、特定の選択項目（評価対象選択項目）については、それぞれの件数に基づいて選択項目別の評価点を算出し（Ｓ38）、さらにモジュール別・管理別・システム別の診断点を算出した後（Ｓ40）、これらの算出結果が記載された集計表を生成する（Ｓ42）。
つぎに、演算処理部24から算出結果である集計表を受け取ったWeb処理部26は、集計表が埋め込まれた表示用画面を生成し、ユーザ端末30に送信する（Ｓ44）。
【００３６】
図７は、この集計表44の一例を示すものであり、モジュール毎（AA, BB, CC, XX, YY, ZZ）、管理毎（A, X）及びシステム毎に、問題指摘情報の登録件数が「指摘合計」欄に表示されている。
また、「対策状況」、「判定」、「重要度」、「要因」、「作り込み」、「規約・ツール」、「形態」、「デバッグ工程」の各選択項目については、それぞれの選択肢毎の指摘件数がモジュール単位、管理単位、システム単位で表示されている。
さらに、「重要度」、「要因」、「作り込み」、「規約・ツール」、「形態」、「デバッグ工程」の各評価対象選択項目については、それぞれの評価点がモジュール単位、管理単位、システム単位で表示されている。
【００３７】
例えば、管理Aに属するモジュールAAの「重要度」項目についてみると、「重大不良」が１件で評価点が「5.0」であることが読み取れる。
また、管理Aのレベルで「重要度」項目をみると、「重大不良」が１件、「機能不良」が３件、「軽微不良」が３件、評価点が「2.4」と表示されている。
また、管理Xに属するモジュールYYの「重要度」項目には、「機能不良」が２件、「軽微不良」が３件、評価点が「1.8」と表示されている。
さらに、管理Xも含めたシステム全体のレベルで「重要度」項目をみると、「重大不良」が４件、「機能不良」が１０件、「軽微不良」が８件、評価点が「2.8」であることが読み取れる。
【００３８】
各選択項目に設定された「評価点」は、各選択肢の件数と定義情報ＤＢ14に格納された各選択肢の重み係数との積をそれぞれ算出し、それらの和を当該選択項目の全件数で除することによって算出される。
各選択肢の重み係数は、例えば図８のように設定されている。
以下に、幾つかの具体的な計算例を示す。
【００３９】
［管理A−モジュールBBの要因評価点］
（不注意２件×重み係数２＋仕様不備１件×重み係数４＋検討不足１件×重み係数３＋理解不足１件×重み係数３）÷５件＝2.8
【００４０】
［管理Aのデバッグ工程評価点］
（机上１件×重み係数１＋単体０件×重み係数２＋結合０件×重み係数３＋総合２件×重み係数４＋システムテスト４件×重み係数５）÷７件≒4.1
【００４１】
［システム全体の作り込み評価点］
（プロジェクト計画２件×重み係数３＋基本設計４件×重み係数３＋機能設計０件×重み係数２＋詳細設計３件×重み係数２＋コーディング１３件×重み係数１）÷２２件≒1.7
【００４２】
各選択肢に設定された重み係数は、そのシステムに与える深刻度の大きさに比例して高い数値が設定されているため、各選択項目の評価点が高いほど重篤な状態であることが示されている。
また、評価点はモジュール単位、管理単位、システム全体というように、階層構造を備えたプログラムのレベル毎に表示される。
したがって、プロジェクトマネージャは、この集計表44に表示された各選択項目の評価点の数値を概観することにより、システム開発全体における問題箇所を即座に把握することができ、応援要員の手配等の対応が可能となる。
【００４３】
この集計表44には、モジュール単位、管理単位及びシステム単位で「診断点」が表示されている。この診断点は、規約・ツール評価点を除いた重要度評価点、要因評価点、作り込み評価点、形態評価点、デバッグ評価点に対し、所定の変換処理を施して項目別診断点を算出した後、各項目別診断点を加算することによって求められる。
以下に、変換ルールの一例を示す。
評価点０〜1.9→項目別診断点０
評価点２〜3.6→項目別診断点１
評価点3.7〜5.0→項目別診断点２
つぎに、具体的な診断点の算出例を示す。
【００４４】
［モジュールAAの診断点］
重要度の項目別診断点(２)＋要因の項目別診断点(１)＋作り込みの項目別診断点(０)＋形態の項目別診断点(２)＋デバッグ工程の項目別診断点(２)＝７
［モジュールYYの診断点］
重要度の項目別診断点(０)＋要因の項目別診断点(１)＋作り込みの項目別診断点(１)＋形態の項目別診断点(１)＋デバッグ工程の項目別診断点(２)＝５
［システム全体の診断点］
重要度の項目別診断点(１)＋要因の項目別診断点(１)＋作り込みの項目別診断点(０)＋形態の項目別診断点(１)＋デバッグ工程の項目別診断点(１)＝４
【００４５】
診断点が高いほど当該モジュール、管理またはシステムについて問題が大きいことを示しているため、次回の開発プロジェクトにおいては技術者の増員等の対策を講じることが可能となる。
【００４６】
上記の集計表44は、指摘を受けた全てのバグ等に基づいて生成される例を示したが、集計表44の生成をリクエストする際に、プロジェクトマネージャは対策が完了した案件については集計対象から除くように集計条件を設定することができる。
この場合、演算処理部24は「対策状況」について「調査中」及び「判明」のチェックがついている問題指摘情報のみを問題指摘情報ＤＢ22から抽出し、集計表44を生成する。
この結果、現時点における問題の分布を概観することが可能となる。
【００４７】
プロジェクトマネージャは、システム10に対して評価対象選択項目に係るレーダーチャートの表示をリクエストすることもできる。
すなわち、プロジェクトマネージャがシステム10にアクセスし、サービスメニューから「レーダーチャートの表示」を選択すると、このリクエストを受けた演算処理部24は（Ｓ46）、各評価対象選択項目の評価点に基づいてレーダーチャートを生成する（Ｓ48）。
そして、Web処理部26がこのレーダーチャートを埋め込んだ画面を生成し、ユーザ端末30に送信する（Ｓ50）。
【００４８】
図９はその画面50の一例を示すものであり、「重要度」、「要因」、「作り込み」、「規約・ツール」、「形態」、「デバッグ工程」の各評価対象項目に対応した軸を備えたレーダーチャート52が表示されている。
このレーダーチャート52においては、モジュールAA、BB、CCの評価点が各軸にプロットされているが、プロジェクトマネージャは画面下部の対象設定欄54のチェックボックスにチェックを入れ、「表示の変更」ボタン56をクリックすることにより、レーダーチャート52上に表示させるグラフをAA、BB、CC、XX、YY、ZZ、管理A、管理X、システムの各単位で切り替えることができる。
【００４９】
このレーダーチャート52においては、グラフ（多角形）の面積が小さいものほど問題が少ないことを示している。
このため、プロジェクトマネージャはこのレーダーチャート52を観察することにより、モジュール単位、管理単位、システム単位の各レベルにおいてプログラムの開発状況やプログラムの品質を視覚的に把握することが可能となる。
【００５０】
また、デフォルトでは全期間に亘る問題指摘情報に基づいてグラフが描かれているが、プロジェクトマネージャは画面下部の期間設定欄58で第１の期間及び第２の期間を指定し、「表示の変更」ボタン56をクリックすることにより、レーダーチャート上に期間限定の問題指摘情報に基づいて算出されたグラフを表示させることができる。
【００５１】
例えば、プロジェクトマネージャが対象設定欄54に「モジュールAA」を設定すると共に、期間設定欄58の第１の期間として「2007/08/15〜2007/10/25」を設定し、第２の期間として「2007/10/26〜2007/12/29」を設定した場合、演算処理部24は第１の期間内に発生したモジュールAの問題指摘情報に基づいて第１のグラフを生成すると共に、第２の期間内に発生したモジュールAの問題指摘情報に基づいて第２のグラフを生成し、これらのグラフを同一のレーダーチャート52上に表示させる。
【００５２】
このレーダーチャート52が表示された画面50を閲覧することにより、プロジェクトマネージャは両期間におけるグラフ面積・形状の変化から、プログラム開発の状況の推移（向上または退歩）を視覚的に認識することが可能となる。
【００５３】
プロジェクトマネージャは、システム10に対して不良成長グラフの表示をリクエストすることもできる。
すなわち、プロジェクトマネージャがシステム10にアクセスし、サービスメニューから「不良成長グラフの表示」を選択すると、このリクエストを受けた演算処理部24は（Ｓ52）、テスト情報ＤＢ18に格納された情報と、問題指摘情報ＤＢ22に格納された情報に基づいて不良成長グラフを生成する（Ｓ54）。つぎに、Web処理部26によってこの不良成長グラフを埋め込んだ画面が生成され、ユーザ端末30に送信される（Ｓ56）。
【００５４】
図１０は、この画面60の一例を示すものであり、縦軸に「テスト項目件数」及び「不良件数」が設定されると共に、横軸に指摘日が設定され、不良成長曲線、対処完了曲線、テスト消化曲線が描画された不良成長グラフ62が埋め込まれている。
【００５５】
グラフ62中の不良成長曲線は、全問題指摘情報の累積件数を指摘日に沿ってプロットすることによって描かれている。
また対処完了曲線は、各指摘日までに対策が完了したもの、あるいは指摘ミスが確定したものの累積件数をプロットすることによって描かれている。
したがって、プロジェクトマネージャは、この不良成長グラフ62中の不良成長曲線と対処完了曲線との乖離状況を観察することにより、未解決不良の量を視覚的に認識することが可能となる。
なお、「テスト消化曲線」は、テスト情報ＤＢ18に格納されたテスト項目情報の累積件数からテスト実施情報の累積件数を減算することにより、描かれる。
【００５６】
この不良成長グラフ62の場合、デフォルトではシステム単位での不良成長曲線、対処完了曲線、テスト消化曲線が描かれているが、プロジェクトマネージャは画面下部の対象設定欄64の任意のチェックボックスにチェックを入れ、「表示の変更」ボタン66をクリックすることにより、不良成長グラフ62上に表示させる各曲線をAA、BB、CC、XX、YY、ZZ、管理A、管理Xの各単位で切り替えることができる。
【００５７】
上記の実施形態においては、重要度、要因、作り込み、規約・ルール、形態、デバッグ工程の各選択項目について評価点を算出する例を示したが、これらはあくまでも評価対象選択項目の一例であり、他の選択項目について評価点を算出するようにシステム10を構成することも当然に可能である。
また、評価対象選択項目の選択肢やそれぞれの重み係数についても特に限定はなく、システム10の運用者が自由に設定することができる。
さらにシステム10の運用者は、診断点算出の基準となる評価対象項目の選定や、項目別診断点の変換ルールについても適宜変更可能であることは言うまでもない。
【図面の簡単な説明】
【００５８】
【図１】この発明に係るプログラムの開発状況評価システムの全体構成を示すブロック図である。
【図２】このシステムの処理手順を示すフローチャートである。
【図３】このシステムの処理手順を示すフローチャートである。
【図４】問題指摘情報登録用画面の一例を示す図である。
【図５】問題指摘情報登録用画面の一例を示す図である。
【図６】問題指摘情報のデータ構造を示す図である。
【図７】集計表の一例を示す図である。
【図８】重み係数の設定例を示す図である。
【図９】レーダーチャートの一例を示す図である。
【図１０】不良成長グラフの一例を示す図である。
【符号の説明】
【００５９】
10    プログラムの開発状況評価システム
12    定義情報登録部
14    定義情報ＤＢ
16    テスト情報登録部
18    テスト情報ＤＢ
20    問題指摘情報登録部
22    問題指摘情報ＤＢ
24    演算処理部
26    Web処理部
28    通信ネットワーク
30    ユーザ端末
40    問題指摘情報登録用画面
42    「登録」ボタン
44    集計表
50    レーダーチャート表示用画面
52    レーダーチャート
54    対象設定欄
56    「表示の変更」ボタン
58    期間設定欄
60    不良成長グラフ表示用画面
62    不良成長グラフ
64    対象設定欄
66    「表示の変更」ボタン
【図１】
2009193186.tif 000003
【図２】
2009193186.tif 000004
【図３】
2009193186.tif 000005
【図４】
2009193186.tif 000006
【図５】
2009193186.tif 000007
【図６】
2009193186.tif 000008
【図７】
2009193186.tif 000009
【図８】
2009193186.tif 000010
【図９】
2009193186.tif 000011
【図１０】
2009193186.tif 000012