JP2002373087A - 品質管理システム - Google Patents

Abstract

(57)【要約】 【課題】品質管理者は、多岐に存在する品質評価資料か
ら総合的に判断しなくてはならない。そこには慣れなど
個人差があり時間もかかる。品質判断資料作成の自動化
と標準化が課題であった。 【解決手段及び効果】品質管理に必要な複数の指標を整
理する。本システムではテスト工程などでのそれら指標
の情報をＤＢに登録しておき、品質評価時にはその情報
を与えたルールにより1つの指標に置き換え出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】ソフトウェアのプログラムテ
スト工程に関して、複数の品質情報を一つの指標に統合
し、利用者の属性を考慮した編集を行い、マトリックス
に記号化表現し品質管理を行うプロジェクト品質管理支
援システム。

【０００２】

【従来の技術】大規模なシステムを構築する場合、その
システムの品質検査はいくつかの工程に区分される。最
初にプログラムのモジュール単位でのテスト（ＵＤ）が
行われる。次に複数のモジュールの組み合わせテスト
（ＣＤ）、複数の業務を組合せたシステムテスト（Ｓ
Ｄ）が順に行われる。最後に検査部門による製品検査
（ＳＫ）が行われる。各工程で発見されるプログラムの
不良はその重要度に応じてＡ，Ｂ，Ｃといったレベルが
付与され、レベルに応じた対策が設計部所に要求される
仕組みとなっている。こうした各工程での不良情報は不
良情報管理システムと言うシステムに登録され管理され
ている。また検査部門では設計部署のテスト工程が十分
に行われるように、設計部所がプログラムテストの為に
作成するチェックリストに対して、1キロステップあた
り何件のチェックリストを作成することとしたチェック
リスト密度に対する標準値を定め、設計部所によるテス
トの質を確保している。

【０００３】このようなソフトウェア品質管理手法に対
して、品質評価手法としては、マトリックスを用いて評
価する手法は既に存在するものの、特開平９−２６５３
９２号公報などに記載されているように不良密度やチェ
ックリスト密度などの品質評価の指標となるそのもの自
体を、プログラムやプログラムのモジュール単位にマト
リックスに表し、各品質指標１つ１つに関しての一覧表
を提供するものであった。

【０００４】

【発明が解決しようとする課題】ソフトウェアの品質管
理をする立場には、ソフトウェアの設計担当者、その取
りまとめ者、テスト部署など様々な者がいる。そのそれ
ぞれの立場で着眼点が違ったり、評価の指標が異なった
り、判断基準が異なったりする。さらにテスト工程管理
のデータはかなり複雑に、いろいろなシステムで管理さ
れているので、これらを総合判断するにも熟練が必要で
ある。本発明は上記を考慮して、品質を管理するデータ
を、参照する人の属性によって異なる形式や判断基準に
したがって編集し表示し、よりソフトウェアの品質管理
を円滑に行うことを課題とする。

【０００５】

【課題を解決するための手段】プログラムの品質を評価
する基本データとして、プログラムステップ数、チェッ
クリスト件数を 保持する。これらをテスト情報と定義
する。又、本システム利用者情報として、その利用者の
担当プログラム名・所属・職位・本人の識別情報などの
属性情報を保持する。これらを利用者属性情報と定義す
る。プログラムの検査工程で発見される該当プログラム
不良情報をプログラムの発生箇所を特定する情報ととも
に、その重要度のレベル、発生日、対策日などを対にし
て記憶するようにする。利用者が本システムにログイン
すると、利用者属性情報から担当プログラムと所属・職
位を取得する。続いて、利用者によって入力された工程
名に属するテスト情報、不良情報を抽出し評価する。そ
れぞれのデータのもつ情報に対して標準値を固定値とし
て入力しておき、各情報毎に標準値からの数値上の離れ
具合によって異常の度合いを算出する。

【０００６】テスト情報に関しては、1キロステップ当
たりのチェックリスト件数に標準値を定め、不良情報に
関しては各プログラム毎の不良重要度の件数に対し標準
値を設定する。ソフトウェアの品質はこれら複数の品質
指標によって同時に表されるのだから、算出された各指
標の異常度を１つの新指標に置き換え該当項目の品質指
標とする。置き換えられた新指標の表す異常度は、元の
指標郡個々の異常度の組み合わせによって一意的に決定
される様システムにルールを持たせておく。新指標は異
常度の高低に応じて複数のクラスに分類してそれを識別
する記号を付与する。システムはプロジェクト全体を網
羅するマトリックスの各項目にその新指標を出力する。

【０００７】

【発明の実施の形態】以下、本発明の実施例を図面によ
り詳細に説明する。

【０００８】図1は品質マップ作成システムの構成図で
ある。不良情報管理システムサーバ１０１は、テスト情
報管理テーブル１０２、不良情報管理テーブル１０３、
利用者属性管理テーブル１０４を持ち、登録されたテス
ト工程の不良の内容をＤＢに保持している。又品質マッ
プ定数・定率テーブル１０５には検査部門が設定する各
標準値があらかじめ登録されている。利用者は通常、テ
スト工程で発生したプログラム不良の内容を随時各クラ
イアントから登録し、品質情報を取得する際にも、クラ
イアントから不良情報管理システムサーバ１０１にアク
セスし作成された品質マップをクライアント画面にて照
会、印刷するというのが概要である。

【０００９】次に、不良情報管理システムサーバ１０１
内部の各テーブルについて説明する。

【００１０】図２はテスト工程のテストの実施形態を管
理するテスト情報管理テーブル１０２のテーブル図であ
る。該当プログラムの工程毎の規模とチェックリスト件
数がプログラム名２０１、工程名２０２、規模(ks)２０
３、ＣＬ総件数２０４、ＣＬ消化件数２０５、ＣＬ密度
２０６によって管理され、品質マップ作成時は定数・定
率テーブル１０５の値と比較する事により、設計部所に
よるテストの十分性を評価する指標となるテーブルであ
る。又、プログラム名２０１はワークシート品質マップ
の横軸に展開される。

【００１１】図３はプログラム不良を管理する不良情報
管理テーブルのテーブル図である。テスト工程で発見さ
れたプログラム不良の管理を、プログラム名３０１、工
程名３０２、発生日３０３、対策日３０４、レベル３０
５、不良内容３０６により行う。品質マップ作成時は、
ユーザが入力する工程名に該当するものを工程名３０２
で抽出し、対応するプログラム名３０１とその不良内容
３０６から品質マップの縦軸を決定する。これにより１
件の不良は、どの工程に関する品質マップに該当し、品
質マップマトリクス内のどの項目に該当するか一意的に
決定される。対策日３０４はその不良が修正済みである
か否か、レベル３０５はその不良の重要度を表し、品質
マップに不良の発生状態や修正状態に関する評価を与え
る。

【００１２】図４は利用者属性管理テーブルのテーブル
図であり、システム利用者の情報を管理している。ユー
ザＩＤ４０４とパスワード４０５によってユーザのログ
イン権限を管理し、プログラム名４０１と属性４０３に
よって品質マップ作成時の編集方法が決定される。具体
的には、属性４０３が設計担当者である場合には不良情
報管理テーブル１０３からの情報を同テーブル内の発生
日３０３と対策日３０４を見て、「その不良が修正済み
であるか否か」という形で取得し、品質マップも不良未
修正マトリックスとして印字されるが、属性４０３が管
理者である場合には、不良情報管理テーブル１０３から
の情報取得は同テーブル内の、対策日３０４を見ずに
「過去から現在に至るまでどの様な不良が発生してきた
か」と言う形で品質マップに展開する。利用者属性管理
テーブル１０４はこの編集方法の決定を本システムログ
イン時に行う為のテーブルである。

【００１３】図５は定数・定率テーブルのテーブル図で
あり、検査部門が設定するチェックリスト密度に関する
標準値が工程名５０１、チェックリスト標準値５０２の
形で初期登録されている。この値は前述の通り、図２の
テスト情報管理テーブルの値と比較される。

【００１４】図６、図７、図８は、品質マップ作成から
出力までの処理フローである。不良情報管理システムサ
ーバ１０１内部の４テーブルから対象となるデータを抽
出し、各テーブルの持つ複数の品質情報を１つの指標に
置き換え品質マップに出力するまでの手順を以下、詳細
に説明する。品質マップ作成システムを利用するには、
ユーザはまずクライアントより不良情報管理システム１
０１へログインをする。

【００１５】ステップ６００にてシステムは利用者情報
管理テーブルを用いて、クライアント画面より入力され
たユーザＩＤ、パスワードと、ユーザＩＤ４０４、パス
ワード４０５のマッチングを行いユーザの認証を行うだ
けでなく、ユーザＩＤ４０４をキーに属性４０３を保持
する。データが存在しない場合は、ユーザＩＤ或いはパ
スワードが存在しない旨のエラーメッセージをクライア
ント画面へ返す。

【００１６】続いてステップ６１０、ステップ６２０で
は、テスト情報管理テーブルによる処理を行う。まずス
テップ６１０でユーザによってクライアント画面より入
力された工程名と、テスト情報管理テーブル１０２内部
の工程名２０２とをマッチングをかける。一致する工程
名２０２が存在する場合は、工程名２０２をキーに同テ
ーブル内のプログラム名２０１を品質マップ横軸の項目
欄に印字処理を行う。1件もデータが無い場合には、対
象工程に関してテスト対象物の登録が不完全である旨ク
ライアント画面にエラーメッセージを返す。本処理によ
り品質マップのマトリックス横軸が決定され、以降の処
理では、プログラム名をキーに横軸を選択する。その後
は処理によって、プログラム名だけをキーに品質マップ
のマトリックス横軸全体への処理を行う場合と、横軸決
定後に不良内容からマトリックス縦軸を決定する処理と
分かれる。

【００１７】ステップ６２０では品質マップのマトリッ
クス行全体に関する処理を行う。ステップ６１０で品質
マップに展開されたプログラム名２０１と工程名２０２
をキーにＣＬ総件数２０４とＣＬ消化件数２０５により
テスト工程の進捗状況を評価する。ＣＬ総件数２０４＞
ＣＬ消化件数２０５である場合にはＣＬ未消化項目有り
と判断し、ステップ６２１で品質マップの該当プログラ
ムの行に対して×印を印字する。ＣＬ総件数２０４＝Ｃ
Ｌ消化件数２０５である場合には全項目消化と判断し、
次ぎの評価に進む。

【００１８】ステップ６３０、ステップ６４０、ステッ
プ６５０では不良情報管理テーブルを用いて、発生した
不良に関する評価を行う。ここでは既に印字されている
品質マップのマトリックス横軸に関してプログラム名を
キーに探し、さらに縦軸をテーブル内の不良内容から決
定する処理を行う。

【００１９】ステップ６３０では、Ａレベル不良の評価
を行う。プログラム名３０１と工程名３０２をキーにレ
ベル３０５の中のＡ不良を抽出する。該当データがある
場合にはステップ６３１にてそのレコードの不良内容３
０６を読み、品質マップの縦軸を決定し、品質マップに
×印を印字する。Ａ不良のレコードが存在しない場合に
は次のステップに進む。

【００２０】ステップ６４０ではＢ、Ｃ不良の評価を行
う。プログラム名３０１と工程名３０２をキーにレベル
３０５の中のＢ、Ｃ不良を抽出する。該当データがある
場合には該当工程の総不良件数と、品質マップ上の各項
目毎の件数を算出する。総不良件数は工程名３０２をキ
ーにレコード件数をカウントし、品質マップの各項目毎
の件数はプログラム名３０１と工程名３０２、不良内容
３０６をキーにカウントする。品質マップへの印字は不
良発生件数によって下記の判断に分岐する。総不良件数
に対して、品質マップ該当項目の不良件数が１０％以上
である場合はステップ６４１にて品質マップの該当項目
に×印を印字する。１０％未満である場合はステップ６
４２にて△印を印字する。Ｂ、Ｃ不良のレコードが存在
しない場合にはステップ６４３にて品質マップに○印を
印字する。

【００２１】ステップ６５０では不良修正確認を行う。
まず工程名３０２をキーに対策日３０４を読む。対策日
３０４がスペースであるレコードは不良修正未完了と判
断し、該当レコードのプログラム名３０１、不良内容３
０６から特定される品質マップ該当箇所に印字されてい
る記号をそのままにして置く。それ以外のレコードは対
策日３０４に日付の入力があるので、品質マップの該当
項目上の不良は全件修正済みと判断し、処理方法は次の
判断に委ねられる。

【００２２】修正済みの不良情報に関する評価は利用者
属性管理テーブル１０４を用いてステップ６６０、ステ
ップ６６１、ステップ６６２によって行われる。ステッ
プ６６０では、先のステップ６００で保持した属性４０
３によって分岐を行う。属性４０３が設計担当者である
場合にはステップ６６１に分岐し、工程名３０２、プロ
グラム名３０１、不良内容３０６から品質マップ該当箇
所を特定し記号を◎に変換する。これにより品質マップ
は設計担当者に対して該当箇所に残作業が無いことを明
示する。又、属性４０３が管理者である場合にはステッ
プ６６２に分岐し、修正済み不良に関しても印字記号の
変換は行わない。このことは品質管理者に対して品質マ
ップが、1工程内のプログラム修正の履歴を表し、工程
内トータルの品質把握材料となる必要が有る事に起因し
ている為である。

【００２３】ステップ６７０ではＣＬ密度の評価分岐を
行う。テスト情報管理テーブル１０２内部の工程名２０
２をキーに1レコードづつ読み、ＣＬ密度２０６とテス
ト情報定数・定率テーブル１０５の工程名５０１と一致
する箇所のＣＬ密度標準値５０２を比較する。ＣＬ密度
２０６がＣＬ密度標準値５０２の１／２未満である場合
は、ステップ６７１にて品質マップ上に印字されている
全ての記号に対し、◎印ならば△印、△印ならば×印と
変換する。これは、ＣＬ密度２０６がＣＬ密度標準値５
０２の半分にも満たないテストでは、テスト結果の信頼
性に欠けるものと判断するからであり、品質マップ上に
ある評価記号をより品質の悪い意味を示す方に下方修正
する。ＣＬ密度２０６がＣＬ密度標準値５０２の１／２
以上の場合はテスト結果の信頼性は十分と判断し、既に
品質マップに印字されている評価記号に変換処理は行わ
ず、次ステップに進む。

【００２４】ステップ６８０にて品質マップ下方の欄に
不良密度(件/ks)の出力を行う。工程内の総不良件数は
ステップ６４０で取得した、不良情報管理テーブル１０
３の中の工程名３０２をキーとしたレコード件数であ
り、工程内の総対象プログラムステップ数はテスト情報
管理テーブル１０２の中の工程名２０２をキーに各レコ
ードの規模(ks)２０３の総和である。最後にステップ６
９０の画面出力処理となる。

【００２５】品質マップへの出力結果が図９である。項
番１の管理者用品質マップを例に説明する。品質マップ
は横軸を不良内容、横軸をプログラム名とするマトリッ
クスである。図中の縦軸９００は帳票固定値であるが、
横軸９１０は品質マップ作成時に図６のステップ６１０
にて自動生成される。検証対象ステップ数と不良密度の
算出は図８のステップ６８０で行われる。

【００２６】項番１の管理者用品質マップと設計担当者
用品質マップでは、９３１と９３２に違いが見られる。
これは設計担当者用品質マップでは、修正済みの不良評
価で図７のステップ６６０の判断で６６１に分岐してい
る為、９３２の通り◎印の印字となっているが、管理者
用品質マップでは同判断で６６２に分岐している為、９
３１の通り印字記号を変換せず△印の印字となるからで
ある。また９４１と９４２に違いが見られないのは、設
計担当者用品質マップで◎になっていない事から不良が
未修正である事に他ならない。

【００２７】

【発明の効果】利用者の属性から、品質情報の編集方法
を設計担当者用とプロジェクト管理者用のロジック選択
をする為、同じ情報に対してそれぞれの立場で必要とな
る品質管理データを利用者に提供する。どちらの場合
も、プロジェクト全体に対して複数の品質情報を１つの
指標で表現するだけでなく、◎、△、×の３種類で品質
を表現する為、専門知識に依存せずプロジェクトの問題
箇所を把握することが出来る。又、それら品質情報の編
集は本システムが行う為、管理データをタイムリーに作
成出来るので、問題点の早期対応が実現されるだけでな
く、品質評価の標準化を可能としオープンなプロジェク
ト管理をも実現する。プロジェクト管理者にとっては、
「今までどこに、どれだけプログラム不良が発生した
か」と言う弱点箇所の傾向を知ることができ、設計担当
者へは、「今どこでプログラム不良が発生しているか、
或いはどこのプログラム修正が完了したか」と言うプロ
グラム修正状況を表すチェックリストの提供を実現す
る。

【図面の簡単な説明】

【図１】品質マップ作成システム構成図。

【図２】テスト工程の実施形態を管理するテスト情報管
理テーブルのテーブル図。

【図３】テスト工程で摘出された不良情報を管理する不
良情報管理テーブルのテーブル図。

【図４】品質マップの編集条件である利用者の属性を管
理する利用者属性管理テーブルのテーブル図。

【図５】品質マップ作成時に使用する標準値を登録する
定数・定率テーブルのテーブル図。

【図６】品質情報を品質マップに記号化編集する際のロ
ジックを示したフロー図。

【図７】品質情報を品質マップに記号化編集する際のロ
ジックを示したフロー図。

【図８】品質情報を品質マップに記号化編集する際のロ
ジックを示したフロー図。

【図９】品質マップレイアウト図。

【符号の説明】

１０１…不良情報管理システムサーバ １０２…テスト情報管理テーブル １０３…不良情報管理テーブル １０４…利用者属性管理テーブル １０５…定数・定率テーブル ２０１…プログラム名 ２０２…工程名 ２０３…規模(ks) ２０４…ＣＬ総件数 ２０５…ＣＬ消化件数 ２０６…ＣＬ密度 ３０１…プログラム名 ３０２…工程名 ３０３…発生日 ３０４…対策日 ３０５…レベル ３０６…不良内容 ４０１…プログラム名 ４０２…氏名 ４０３…属性 ４０４…ユーザＩＤ ４０５…パスワード ５０１…工程名 ５０２…ＣＬ密度標準値 ６００…利用者情報を利用者情報属性管理テーブルから
取得 ６１０…テスト情報管理テーブルでの工程名 ６２０…ＣＬ消化確認の判断 ６２１…未消化ＣＬ項目ありの場合の処理 ６３０…Ａ不良の評価の判断 ６３１…Ａ不良が1件以上ある場合の処理 ６４０…Ｂ，Ｃ不良の評価の判断 ６４１…全不良数に対してＢ，Ｃ不良の発生が１０％以
上である場合の処理 ６４２…全不良数に対してＢ，Ｃ不良の発生が１０％未
満である場合の処理 ６４３…不良が全く発生しなかった場合の処理 ６５０…不良修正の判断 ６５１…未修正の不良が存在する場合の処理 ６６０…利用者属性の判断 ６６１…利用者属性が設計担当者で かつ 不良が全て修
正済みである場合の処理 ６６２…利用者属性が管理者である場合の処理 ６７０…ＣＬ密度評価の判断 ６７１…ＣＬ密度が標準値×１／２以下である場合の処
理 ６８０…品質マップへの不良密度（全不良数／規模）の
出力処理 ６９０…画面への品質マップ出力処理

Claims (2)

【特許請求の範囲】
1. 【請求項１】ソフトウェア開発の中のプログラムテスト
   工程において、プログラムの品質を表す指標である様々
   なプログラム不良の内容、テストの十分性を示す値であ
   るテスト対象物に対するテスト項目件数、さらにテスト
   の進捗状況に関する情報を、それらが登録され管理され
   るデータベースから入力し、それぞれの指標における品
   質の異常度を検出し、１つの新指標に纏める為の要素と
   し、各要素に関して、1要素でも異常値があれば新指標
   は必ず異常値を示すようにし、全ての要素が正常値であ
   る場合のみ新指標に正常値を与え、新指標は異常度の高
   低に応じて複数のクラスに分類してそれを識別する記号
   を付与し、プロジェクト全体を網羅するマトリックスに
   表現することを特徴とする品質管理システム。
2. 【請求項２】請求項１記載の品質情報を必要とする利用
   者の属性を判断し、それによってプログラムの品質情報
   の表示方法を変え、同一のワークシートに２種類の品質
   評価方法を行うことを特徴とする品質管理システム。