JP2001337846A - ソフトウエア品質検査支援システム及び方法 - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウエア品質検査において、効果的な試
験項目の作成ができるよう支援する。 【解決手段】 開発部門では、ウェイト設定部２１２に
より、ソフトウエア製品を構成する各サブシステムの各
業務に占めるウェイトを設定する。そして、ＦＰ（ファ
ンクションポイント）法などで求めた各業務の総試験項
目数を、設定したウェイトに従って割り振ることによ
り、各サブシステムごとの試験項目数の目標値を算出す
る。この各サブシステムごとの目標値を表示することに
より、試験担当者は、どのサブシステムをターゲットに
してどの程度の数の試験項目を作成すればよいか、判断
することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ソフトウエアの
品質検査の支援のためのシステムに関し、効果的な試験
項目の作成や抜き取り検査のサンプルの絞込の支援のた
めの技術に関する。

【０００２】

【従来の技術】ソフトウエア開発の現場では、誤りがで
きるだけ少ない高品質の商品（ソフトウエアシステム）
を提供するため、いったん作成したソフトウエアに対し
て試験を行って所期の性能が達成されているか確認し、
達成されない場合はその原因（誤り、バグ）を突き止
め、コードの修正などの処置を行っている。そして、こ
の試験、修正の作業を繰り返すことにより、ソフトウエ
アに含まれる誤りを低減している。

【０００３】ソフトウエアの試験のためには、まず、要
求性能（仕様）の各項目が実現されていることを確かめ
るための試験項目を必要なだけ設定する。そして、作成
したソフトウエアシステムにてこれら各試験項目の内容
を実施し、その試験項目の内容が正しく実行できたかど
うかを調べる。正しく実行できなかった試験項目があれ
ば、そのとき症状が障害として報告され、この報告に基
づき処置が行われる。従来、ソフトウエア試験のための
試験項目は、ソフトウエア開発部門等の担当者が、その
ソフトウエアの要求仕様から、自己の経験に基づいて作
成するのが一般的であった。また、試験自体もそのソフ
トウエアの開発部門が行うことが一般的であった。

【０００４】また、近年ソフトウエアについてもＩＳＯ
９０００シリーズなどに準拠した高度な品質保証モデル
の導入の必要性が叫ばれている。高度な品質保証を実現
するには、従来開発部門が自前で行っていたソフトウエ
ア品質管理だけでなく、第三者的な立場からソフトウエ
アの品質をチェックしたり、開発部門の品質管理自体の
質をチェックしたりする検査部門の設立が求められる。

【０００５】検査の統一性や経済性等の観点から、検査
部門は１企業（あるいは１事業所など）に１つ設けられ
るのが一般的であり、１つの検査部門が企業内にある数
多くの開発部門の開発したソフトウエアシステムを検査
することになる。このため、検査部門の検査効率の向上
は、企業のソフトウエア開発全体のサイクルを左右する
重要なファクタとなる。

【０００６】

【発明が解決しようとする課題】ソフトウエアの試験・
修正作業では、効果的な試験項目を選ばないと、ソフト
ウエアシステムに内在する誤りを効率よく見つけ出すこ
とができない。これは、試験・修正作業の効率のみなら
ず、最終的なソフトウエア商品の品質にも大きな影響を
もたらす。従来、この試験項目の設計が完全に開発者
（あるいは開発部門）の経験や勘に任されていたため、
開発者（すなわち試験項目の設計者）の能力に応じて試
験の有効性に大きなばらつきが出る場合があった。試験
項目群がソフトウエアシステムに要求される機能を網羅
的にカバーしているか、そうでないかにより、同じ項目
数の試験を実施しても、試験の効果が変わってくる。

【０００７】また、開発部門に対して第三者的な検査部
門を設けた場合、検査部門は一般に開発部門での試験・
修正の結果報告を受けて、その結果の妥当性を判断し、
必要に応じて機能レベル、ソースコードレベルの抜き取
り検査を行う。しかしながら、このような抜き取り検査
も、闇雲にサンプル抜き取りを行っていたのでは効率的
ではない。従来、抜き取り検査のサンプル絞込みは、個
々の検査者の技量によっており、検査の作業効率や効果
の面でばらつきが出る可能性があった。

【０００８】この発明は、上述のような課題を解決する
ためになされたもので、まず第１にソフトウエアシステ
ムの試験のための効果的な試験項目の設計を支援するシ
ステムを提供することを目的とする。更にこの発明は、
抜き取り検査時のサンプルの絞込みを支援するためのシ
ステムを提供することを目的とする。

【０００９】

【課題を解決するための手段】この発明に係るソフトウ
エア品質検査支援システムは、１以上の業務を複数のサ
ブシステムの組合せにより実行するソフトウエアシステ
ムについて、そのソフトウエアシステムの品質検査を支
援するためのソフトウエア品質検査支援システムであっ
て、該ソフトウエアシステムが実行する各業務ごとに、
前記各サブシステムのその業務に関するウェイトを設定
するウェイト設定手段と、前記各業務ごとに、その業務
に関する前記ソフトウエアシステムの機能検証のために
試験すべき試験項目の数を設定する試験項目数設定手段
と、前記各業務ごとに、前記試験項目数設定手段で設定
した当該業務の試験項目数と、前記ウェイト設定手段で
設定した当該業務に関する前記各サブシステムのウェイ
トと、に基づき、各業務ごとの各サブシステムの目標試
験項目数を算出する目標項目数算出手段と、前記目標項
目数算出手段で算出した各業務ごとの各サブシステムの
目標項目数を表示する目標項目表示手段と、を備えるも
のである。

【００１０】また、この発明に係るソフトウエア品質検
査支援システムは、前記各業務ごとに、その業務につい
て実施した試験項目の実施結果の入力を受け付ける試験
結果入力手段と、前記試験結果入力手段で受け付けた各
業務ごとの試験結果と、当該業務についての各サブシス
テムのウェイトと、に基づき、それら各サブシステムご
との試験実施進捗情報を求める試験進捗管理手段と、前
記試験進捗管理手段で求めた前記各サブシステムごとの
試験実施進捗情報を表示する試験進捗表示手段と、を備
えるものである。

【００１１】また、この発明に係るソフトウエア品質検
査支援システムは、前記各サブシステムの製作者を登録
する手段と、前記各サブシステムごとの目標項目数の合
計と、実際に作成された前記各サブシステムのプログラ
ム規模とに基づき、前記各サブシステムの複雑度を算出
する複雑度算出手段と、前記試験項目群の実施により検
出された各サブシステムごとの誤り数と、それら各サブ
システムのプログラム規模とに基づき、前記各サブシス
テムの誤り率を算出する誤り率算出手段と、各サブシス
テムごとの複雑度と誤り率の相関を求め、この相関と各
サブシステムの製作者との関連から、製作者能力分析情
報を作成する製作者能力分析手段と、を備えるものであ
る。

【００１２】また、この発明に係るソフトウエア品質検
査支援システムは、前記製作者能力分析情報は、複雑度
と誤り率とを２軸とする２次元空間において、前記各サ
ブシステムの製作者を、当該サブシステムの複雑度と誤
り率の組合せで規定される位置にプロットした製作者能
力表であり、前記製作者能力分析手段は、作成した前記
製作者能力表を表示する手段を有することを特徴とする
ものである。

【００１３】また、この発明に係るソフトウエア品質検
査支援システムは、前記試験項目の実施に伴う障害の報
告を受け付ける障害報告入力手段と、前記障害報告に対
して処置を行ったサブシステムについて誤り数の登録を
受け付け、各サブシステムごとに誤り数を集計する手段
と、各サブシステムのプログラム規模の入力を受け付け
る手段とを備え、前記誤り率算出手段は、前記各サブシ
ステムごとに、その誤り数とプログラム規模とに基づき
誤り率を算出することを特徴とするものである。

【００１４】また、この発明に係るソフトウエア品質検
査支援システムは、前記製作者の能力分析情報に基づ
き、前記各製作者ごとにどの複雑度レベルまでのサブシ
ステムを抜き取り検査すべきかを示す抜き取り指針を求
めて提示するガイダンス処理手段を更に備えるものであ
る。

【００１５】また、この発明に係るソフトウエア品質検
査支援システムは、前記障害報告に対して行った処置の
報告として、当該障害の原因が以前に処置した同一サブ
システムの同一箇所であることを示す重複誤り情報の入
力を受け付ける手段と、受け付けた重複誤り情報群に基
づき、各サブシステムごとの重複誤り数を集計する重複
誤り集計手段と、集計した重複誤り数に基づき、前記試
験項目群の性能の評価のための情報を生成して提示する
試験性能評価手段と、を更に備えるものである。

【００１６】また、この発明に係るソフトウエア品質検
査支援システムは、前記抜き取り検査に移行する移行基
準を記憶する手段と、前記試験結果がその移行基準を満
足しているか否かを判定し、その判定結果を出力する手
段と、を備えるものである。

【００１７】また、この発明に係るソフトウエア品質検
査支援システムは、前記試験結果が前記移行基準を満足
していない場合、その基準を満足しないサブシステムを
示したレポートを生成する手段をさらに備えるものであ
る。

【００１８】また、この発明に係るソフトウエア品質検
査支援方法は、１以上の業務を複数のサブシステムの組
合せにより実行するソフトウエアシステムについて、そ
のソフトウエアシステムの品質検査を支援するためのソ
フトウエア品質検査支援方法であって、該ソフトウエア
システムが実行する各業務ごとに、前記各サブシステム
のその業務に関するウェイトを設定するウェイト設定ス
テップと、前記各業務ごとに、その業務に関する前記ソ
フトウエアシステムの機能検証のために試験すべき試験
項目の数を設定する試験項目数設定ステップと、前記各
業務ごとに、前記試験項目数設定ステップで設定した当
該業務の試験項目数と、前記ウェイト設定ステップで設
定した当該業務に関する前記各サブシステムのウェイト
と、に基づき、各業務ごとの各サブシステムの目標試験
項目数を算出する目標項目数算出ステップと、前記目標
項目数算出ステップで算出した各業務ごとの各サブシス
テムの目標項目数を表示する目標項目数表示ステップ
と、を備える。

【００１９】また、この発明に係るソフトウエア品質検
査支援方法は、前記各サブシステムの製作者を登録する
ステップと、前記各サブシステムごとの目標項目数の合
計と、実際に作成された前記各サブシステムのプログラ
ム規模とに基づき、前記各サブシステムの複雑度を算出
する複雑度算出ステップと、前記試験項目群の実施によ
り検出された各サブシステムごとの誤り数と、それら各
サブシステムのプログラム規模とに基づき、前記各サブ
システムの誤り率を算出する誤り率算出ステップと、各
サブシステムごとの複雑度と誤り率の相関を求め、この
相関と各サブシステムの製作者との関連から、製作者能
力分析情報を作成する製作者能力分析情報作成ステップ
と、を備える。

【００２０】

【発明の実施の形態】実施の形態１．ソフトウエアシス
テム（ソフトウエア製品）は、１以上の業務のための処
理を実行するためのものであり、複数のサブシステムに
分けて開発していくことが一般的である。個々のサブシ
ステムは、それぞれ比較的単純な機能を実現するプログ
ラム（又はプログラムの組）である。個々の業務は、１
つのサブシステム、又は複数のサブシステムの組合せ、
により実現される。この逆に、１つのサブシステムが複
数の業務で兼用される場合もよくある。

【００２１】すなわち、「業務」は、そのソフトウエア
システムが実行すべき個々の振る舞いであり、ソフトウ
エアシステムの要求仕様から導き出される。これに対
し、「サブシステム」は、そのソフトウエアシステムを
物理的に構成する個々のプログラム（又はその組）であ
る。

【００２２】例えば、文書エディタという１つのソフト
ウエアシステムを考えた場合、このソフトウエアは、文
字入力、文字列検索、文書保存など様々な「業務」の実
現を目的したものである。この中で例えば「文字入力」
という業務は、入力キー認識プログラム、カナ漢字変換
システムとのインタフェースプログラム、得られた文字
コードを表示するためのプログラムなど、いくつかのサ
ブシステム（プログラム）により実現される。そして、
例えばその中の入力キー認識のためのサブシステムは、
「文字列検索」業務でも利用される。

【００２３】ソフトウエアシステムの試験は、要求仕様
が満足されているかどうかを検査するため、要求仕様に
より規定される「業務」単位に行う。

【００２４】このようなソフトウエアシステムの効果的
な品質検査の支援のため、この実施の形態では、図１に
示すソフトウエア品質検査支援システムを提供する。こ
のシステムは、ソフトウエアの開発部門での試験・修正
のサイクルを支援する開発部門システム２００、検査部
門でのソフトウエア品質検査を支援するための検査部門
システム３００、及びそれら両者の試験・検査の作業の
ために利用する諸データを管理するデータベース部１０
０とを備えている。

【００２５】データベース部１００は、障害ＤＢ（デー
タベース）１１０、進捗ＤＢ１２０、試験対応表１３０
及び試験評価表１４０を含んでいる。

【００２６】障害ＤＢ１１０は、開発部門等での試験・
修正サイクル等で出てくる障害報告やその処置報告の内
容を蓄積するデータベースである。障害ＤＢ１１０に蓄
積されるレコードのデータ構造の例を図２に示す。この
データ構造には、障害検出時に付与又は入力される情報
と、障害処置時に入力される情報とが含まれる。障害検
出時に付与又は入力される情報には、障害報告の一意な
識別番号である「障害報告番号」、その報告の内容を示
す「件名」、障害を発見したときの業務の「業務Ｉ
Ｄ」、障害の「発生日」、当該障害の起こったソフトウ
エアシステムの「製品番号」、版名、その障害を検出し
た「検出部門（及び／又は検出者）」、その障害の「現
象」の説明などがある。一方、障害処置時に入力される
情報には、その処置について回答した「回答者」、その
障害がプログラム自体の誤りであったか否かを示す「誤
り」フラグ、その障害報告が以前の報告と同一箇所の誤
りに起因すると判断された場合にセットされる「重複」
フラグ、以前にその同一箇所の誤りを報告した障害報告
の番号を示す「重複障害番号」、その以前の障害報告の
際の業務を示す「重複業務ＩＤ」、当該障害報告に対し
て行った処置を表す「処置区分」、処置のために修正し
たサブシステムを示す「修正サブシステム名」、修正の
概要を示す「修正情報」、及び修正によって改版した場
合の「修正版名」などを含んでいる。なお、障害報告が
「重複」でなかった場合は「重複障害番号」や「重複業
務ＩＤ」は空欄となり、プログラムの修正を行わなかっ
た場合は「修正サブシステム名」、「修正情報」及び
「修正版名」は空欄となる。

【００２７】進捗ＤＢ１２０は、開発部門等での試験・
修正サイクルの進捗情報を蓄積するデータベースであ
る。進捗ＤＢ１２０に蓄積されるレコードのデータ構造
の一例を図３に示す。このデータ構造には、業務の「業
務ＩＤ」、当該業務についての試験を行っている部門を
示す「検出部門」（これは一般的には開発部門自体であ
る）、この業務のために計画した試験項目の数を示す
「計画項目数」、そのうち現時点までに実施した試験項
目数を示す「実施実績数」、実施実績のうち現時点まで
に合格した試験項目数を示す「合格実績数」等の情報が
含まれる。

【００２８】試験対応表１３０は、試験項目の設計や、
各サブシステムの複雑度の算出のために用いる表であ
る。図４に試験対応表１３０の例を示す。図４の表にお
いて、各行はソフトウエアシステムを構成するサブシス
テムに対応している。この例では、ＩＤ１１０１〜１５
０１までの２７個のサブシステムを含んだソフトウエア
システムを取り扱っている。この表は、大きく分けて、
左半分の試験設計支援用の部分１３０ａと、右半分の複
雑度算出用の部分１３０ｂとから構成される。

【００２９】左半分の部分１３０ａは、各業務ごとに欄
分けされている。個々の業務の欄は、その業務に占める
各サブシステムのウェイトを設定する「ウェイト」欄
と、そのウェイトに対応した試験項目数を示す「項目
数」欄を含んでいる。ウェイトの値は、開発部門が各業
務における各サブシステムの寄与割合を考慮して設定す
る。図示の例では、ウェイトは百分率で表されており、
各業務ごとの「ウェイト」値の総和が１００．０となる
ように設定する。

【００３０】前述したように、試験項目群の設計（作
成）は、要求仕様で規定される業務ごとに行う。業務ご
とに必要な試験項目数は、要求仕様から、ＦＰ法（ファ
ンクション・ポイント法）などの公知の手法を用いて求
めることができる。すなわち、ＦＰ法等で求められるそ
の業務の機能の数に基づき、当該業務についての試験項
目の総数を決める。業務が提供する機能の数から当該業
務の試験項目の総数を決めることにより、それら提供機
能群を網羅的に試験するという目的において妥当な数の
試験項目数が分かる。ただし、この業務ごとの試験項目
の総数に合わせた数の試験項目を作成するというだけで
は、試験項目の内容に偏りが出て、試験の効果が悪くな
るおそれがある。そこで、この実施の形態では、個々の
業務ごとの試験項目の作成指針となる情報を求めてい
る。これが、各業務ごとの各サブシステムの「項目数」
の値である。

【００３１】すなわち、この実施の形態のシステムは、
ＦＰ法等で求められた個々の業務の試験項目総数を試験
対応表（図４）の「項目数」の「合計」に入力すること
により、その項目総数を各サブシステムの「ウェイト」
欄の値に従って割り振っていく。この結果得られた値が
当該業務における各サブシステムの試験「項目数」であ
る。図４を参照すると、例えば「業務１」の試験項目の
総数は１７５０と設定されており、この「業務１」にお
いて「１１０２サブシステム」が占めるウェイトは１
０．０％と設定されている。したがって、システムは、
「業務１」に関する「１１０２サブシステム」をターゲ
ットとした試験項目数の目標値（すなわち、目標項目
数）を１７５．０個（＝１７５０×０．１０）と決定
し、これを「項目数」欄に設定する。この場合、試験項
目作成者は、「業務１」の１７５０項目のうち、「１１
０２サブシステム」を利用する試験項目を１７５個以上
作成すればよいことが分かる。同様に、ウェイトが３．
０％である「１１０７サブシステム」の「項目数」は５
２．５個と決定される。このように、１つの業務全体の
試験項目数の目標値を、各サブシステムのウェイトに従
って割り振っていき、このような割り振り処理を各業務
ごとに行う。

【００３２】このように、この実施の形態では、各業務
ごとの試験項目を作成する際に、試験項目の総数だけで
なく、各サブシステムをターゲットとした試験項目が幾
つ必要かを示す情報を求めて提示することができる。し
たがって、試験項目設計者は、試験項目作成のための有
用な指針が得られ、従来よりも効果的な試験項目群を設
計できる。

【００３３】なお、サブシステムをターゲットにした試
験項目を作成するとはいっても、実際にはその試験項目
は様々なサブシステムの連携により実現されることが多
いので、その試験項目は当該サブシステムのみについて
のものではなく、当該「業務」全体についてのものとし
て取り扱う。要求仕様が実現されているかという観点が
重要なので、試験項目の実施は業務単位で行われる。

【００３４】「合計」欄Ａには、そのようにして求めた
各サブシステムの目標項目数を全業務にわたって合計し
た値が設定される。

【００３５】試験対応表１３０の右半分の部分１３０ｂ
は、各サブシステムの複雑度を求めるための部分であ
る。複雑度は、サブシステム（プログラム）の作成の困
難さを示す指標値である。この複雑度を求めるため、こ
の試験対応表１３０では、各サブシステムごとに「試験
対象規模ＫＬ」（Ｃ）、「試験密度」（Ｂ）、及び「自
動生成等のＫＬ」（Ｄ）の値を入力する。「試験対象規
模ＫＬ」は、当該サブシステムのソースコードのうち、
人手により作成したコードのライン数であり、単位はＫ
Ｌ（キロライン＝千行）である。人手により作成したも
のなので、本来の試験の対象という意味で、試験対象規
模ＫＬと呼ぶ。「試験密度」は、ソースコードのライン
数に応じて定められる、必要な試験項目の密度であり、
単位は「項目数／ＫＬ」である。「試験密度」は、企業
ごと、あるいは事業所ごとに、経験的に定めた基準であ
り、各企業等の経験の蓄積が反映されたある程度信頼性
の高い値である。「自動生成等のＫＬ」は、当該サブシ
ステムのソースコードのうち、プログラム自動生成シス
テムによる自動生成等により作成したソースコードのＫ
Ｌ数である。これら各欄の値は、各サブシステムのソー
スコードの最初の版が完成した段階で、この試験対応表
１３０に登録される。

【００３６】「試験対象規模ＫＬ」と「自動生成等のＫ
Ｌ」の和が、サブシステムの実装上のソースコードのＫ
Ｌ数である。この実装上のソースコードのＫＬ数に「試
験密度」を乗じることにより、試験対応表１３０の「実
装上の確認項目数」（Ｅ）の値が計算される。この「実
装上の確認項目数」は、実装ソースコードを事業所基準
の「試験密度」に従って試験するとしたときの試験項目
数である。

【００３７】各サブシステムの「複雑度」（Ｆ）は、次
式に従って算出される。

【００３８】［数式１］ Ｆ＝｛１＋ｌｏｇ（Ｃ）｝・Ａ／Ｅ この算出式の右辺前半の｛１＋ｌｏｇ（Ｃ）｝（Ｃは
「試験対象規模ＫＬ」、すなわち人手で作成したライン
数）は、ソースコードのライン数が多くなればなるほど
生産性が低くなる（特に１００〜１０００ＫＬの間で生
産性が急激に低下する）という経験則を反映した因子で
あり、Ｃの値が大きくなるほどその値は大きくなる。

【００３９】一方、右辺後半のＡ／Ｅ（Ａは目標試験項
目数の「合計」。Ｅは「実装上の確認項目数」）は、同
じ機能を実現するプログラムであれば短いコードの方が
洗練されており、作成が困難であるという経験則を反映
した因子である。試験項目数は、サブシステムが持つ機
能の数を反映していると考えられる。「実装上の確認項
目数」Ｅは、ソースコードのライン数から見て、サブシ
ステムが事業所等の基準でどの程度の機能数に対応する
かを表した数値と見ることができる。これに対し、ウェ
イトに従って求めた目標項目数の「合計」Ａは、そのサ
ブシステムが実現していると考えられる機能数に対応し
た数値とみることができる。したがって、それらの比Ａ
／Ｅは、（実現した機能）／（コードのライン数に見合
った機能）と見ることができ、この値が大きいほど、少
ないライン数で多くの機能を実現している洗練されたコ
ードであるといえる。

【００４０】したがって、それら２つの因子を乗算して
得られた複雑度Ｆは、２つの基準を反映した値となって
おり、値が大きくなるほど作成の困難なサブシステム
（プログラム）であると言える。この複雑度Ｆは、開発
部門でのソフトウエアシステムの開発が完了した段階で
求めることができる。そして、複雑度Ｆは、後に検査部
門で抜き取り検査のサンプル絞込をする際に利用され
る。

【００４１】次に、図５を参照して試験評価表１４０に
ついて説明する。この試験評価表１４０は、開発部門で
の試験・修正サイクルの進捗管理のために用いられる。
この表１４０は、図５に示すように、「試験進捗評価」
セクションと「品質評価」セクションとの２つに大きく
分けられる。「試験進捗評価」セクションは、試験の進
捗状態に関する諸項目を含んだ欄であり、試験の進捗度
を示す「試験実施進捗」欄、障害の処置状況を示す「障
害処置進捗」欄、及び現時点での障害発見数からみて最
終的に発見されるであろう障害数を示す「完了時障害数
予測」欄、から構成される。ソフトウエアシステムを構
成する各サブシステムごとに、これら各欄の値が設定さ
れる。

【００４２】「試験実施進捗」欄は、「実施実績」Ａ
１、「合格実績」Ａ２、「合格計画」Ｂ、「最終見通
し」Ｃ、「進捗率」、「消化率」、及び「障害」数Ｄの
欄を含んでいる。「実施実績」Ａ１は、これまでに実施
した試験項目の数を示す。「合格実績」Ａ２は、Ａ１の
うち、合格した試験項目数を示す。「合格計画」Ｂは、
予め定めたスケジュールからみて現時点で合格している
べき試験項目数を示す。「最終見通し」Ｃは、最終的に
実施・合格すべき試験項目数を示し、これは試験対応表
１３０の目標試験項目数の「合計」Ａに等しい。「進捗
率」は、現時点の実際の合格試験項目数の計画値に対す
る割合であり、Ａ２／Ｂを百分率で示した値である。
「消化率」は、現時点の実際の試験項目数の「最終見
通」に対する割合であり、Ａ２／Ｃを百分率で示した値
となっている。そして、「障害」は、現時点までに報告
された障害の数を示している。

【００４３】「障害処置進捗」欄は、「未処置」数、
「処置」数Ｅ、「処置率」の欄を含んでいる。「処置」
数は、報告された障害のうち、処置が完了したものの数
を示す。「処置」の中にある「誤り」数Ｆは、「処置」
した障害のうち、プログラムの「誤り」が原因であった
ものの数である。障害の中には、プログラムの「誤り」
以外（例えば試験者が動作条件を間違ったために起こっ
た障害など）のものもあるので、このような区別を設け
ている。プログラムに「誤り」があった場合、プログラ
ム修正の処置がとられる。「未処置」数は、報告された
障害のうち未処置のものの数である。そして、「処置
率」は報告された障害のうち処置済みのものの割合を示
す百分率である。

【００４４】また、「品質評価」セクションは、「シス
テム生産量」欄、「現状推定品質」欄、及び「完了時推
定品質」欄から構成される。

【００４５】「システム生産量」Ｇは、サブシステムの
ソースコードのうち、人手により作成したコードのライ
ン数（単位ＫＬ）である。

【００４６】「現状推定品質」欄は、現時点での各サブ
システムの推定品質に関する欄であり、「誤り件数」
Ｈ、「試験密度」及び「誤り率」の欄を含んでいる。
「誤り件数」Ｈは、現時点で報告されている全障害を処
置したときに見つかるであろう「誤り」の総数である
（＝Ｄ・Ｆ／Ｅ）。「試験密度」は、現時点までに実施
した試験項目のソースコード１ＫＬ当たりの数である。
「誤り率」は、現時点の推定誤り総数をサブシステムの
ソースコードのＫＬ数で割ったものであり、１ＫＬ当た
りの誤り数を示している。

【００４７】「完了時推定品質」欄は、現状の傾向がそ
のまま続いたと仮定した場合の、試験完了時点（全試験
項目が合格した時点）での各サブシステムの推定品質を
示している。この欄も、「現状推定品質」欄と同様、
「誤り件数」I、「試験密度」、及び「誤り率」の欄を
含んでいる。「完了時推定品質」の「誤り件数」Ｉは、
現状での誤りの発見率（Ｆ／Ｅ）に、「完了時障害数予
測」値を乗じたものである。「試験密度」は、最終的な
試験項目数をサブシステムのＫＬ数で割ったものであ
る。そして、「誤り率」は、試験完了時の推定「誤り件
数」Ｉを、サブシステムのＫＬ数で割ったものである。

【００４８】更に試験評価表１４０には、各サブシステ
ムごとに、そのサブシステムの開発を担当している製作
担当チームのコードが登録される。

【００４９】この試験評価表１４０は、障害ＤＢ１１０
や進捗ＤＢ１２０に登録された情報に基づき随時作成、
更新される。例えば、「障害」数Ｄや「処置」数Ｅ、
「誤り」数Ｆなどは、障害ＤＢ１１０に登録された障害
報告のレコードを集計して求められる。また、「実施実
績」Ａ１や「合格実績」Ａ２などは、進捗ＤＢ１２０の
該当項目から求められる。また、「最終見通し（目標試
験項目数）」Ｃや「システム生産量」Ｇには、試験対応
表１３０の「合計（項目数合計）」Ａや「試験対象規模
ＫＬ」Ｃの情報が登録される。「合格計画」Ｂは、別途
定められている試験スケジュールから求めて登録され
る。

【００５０】なお、障害報告や試験進捗のレコードは
「業務」ごとに分類されているが、この試験評価表１４
０には、１つのソフトウエアシステムが実現する全業務
の障害数や合格実績などの現時点での集計結果（及びそ
れに基づく推定結果）が表示される。

【００５１】ここで、試験項目は業務単位で実行される
ので、進捗ＤＢ１２０には試験項目の実施実績数や合格
実績数などの試験結果が業務単位でしか登録されない。
この実施の形態では、業務単位で登録された実施実績数
や合格実績数を、試験対応表１３０に設定されたウェイ
トを用いて割り振ることにより、各サブシステムごとの
実施実績数と合格実績数を割り出している。これを全業
務にわたって累計した結果が、試験評価表１４０（図
５）の各サブシステムの「実施実績」及び「合格実績」
の値となる。このように、業務単位での試験結果をウェ
イトを用いて各サブシステムに割り振り、それを集計し
て表示することにより、試験担当者は、抽象的な「業
務」単位の試験進捗だけでなく、物理的な実体としての
「サブシステム」（プログラム）単位での試験進捗を把
握することができる。

【００５２】開発部門での試験・修正サイクルで最終的
にすべての試験項目について合格したと判断されると、
試験評価表１４０の「現状推定品質」欄と「完了時推定
品質」欄の各項目の値が同じになり、これが開発部門で
の最終的な試験結果の１要素となる。

【００５３】以上、データベース部１００で管理される
各データの内容について説明した。ここで再び図１に戻
り、この実施の形態のシステム構成を説明する。

【００５４】開発部門システム２００は、開発部門がソ
フトウエアシステムの試験・修正のサイクルを進めてい
く際に用いるシステムであり、入力処理部２１０、表示
処理部２３０及び演算処理部２５０を含んでいる。

【００５５】入力処理部２１０は、データベース部１０
０に各種情報を入力するための機構であり、ウェイト設
定部２１２、試験項目数設定部２１４、プログラム規模
入力部２１６、製作者登録部２１８、障害報告入力部２
２０及び試験結果入力部２２２を含む。ウェイト設定部
２１２は、試験対応表１３０（図４）に対し、各業務に
占める各サブシステムのウェイトを設定するための入力
機構である。開発部門の担当者は、各業務の内容と各サ
ブシステムの機能とを考慮して各々のウェイト値を定
め、入力する。試験項目数設定部２１４は、試験対応表
１３０の各業務の欄の「項目数」の合計値の欄に、値を
設定するための入力機構である。ここには、ＦＰ法など
の公知の手法を用いて求めた当該業務のための試験項目
の総数が設定される。プログラム規模入力部２１６は、
試験対応表１３０（図４）の「試験対象規模ＫＬ」や
「自動生成等のＫＬ」など、作成された各サブシステム
のプログラム規模の値を入力するための機構である。製
作者登録部２１８は、試験評価表１４０（図５）におけ
る各サブシステムの製作担当チームを入力するための機
構である。障害報告入力部２２０は、障害ＤＢ１１０に
対するデータの入力機構である。試験・修正サイクルに
おいて障害が検出されたり、その障害に対して処置を行
った場合、試験担当者や障害対策担当者は、この障害報
告入力部２２０を用いてその障害や処置の内容を障害Ｄ
Ｂ１１０に入力する。試験結果入力部２２２は、進捗Ｄ
Ｂ１２０に対するデータの入力機構である。試験担当者
は、試験項目の実施の結果（例えば実施した項目数やそ
のうち合格した項目数など）を、定期的にあるいは随
時、この試験結果入力部２２２から入力する。

【００５６】演算処理部２５０は、データベース部１０
０のデータに対して各種の演算処理を行って、試験進捗
やソフトウエア品質に関する各種情報を求め、それをま
とめるための機構である。演算処理部２５０は、目標項
目数算出部２５２、試験進捗管理部２５４、誤り数集計
部２５６、誤り率算出部２５８及び複雑度算出部２６０
を含む。目標項目数算出部２５２は、試験対応表１３０
に、各業務ごとの総試験項目数と、その業務における各
サブシステムのウェイトとが設定されると、それらに基
づき各業務における各サブシステムの目標項目数を算出
し、その値を試験対応表１３０の「項目数」欄に設定す
る。試験進捗管理部２５４は、ユーザからの指示に応
じ、進捗ＤＢ１２０及び障害ＤＢ１１０の現時点までの
蓄積情報を集計し、試験評価表１４０を作成又は更新す
る。誤り数集計部２５６は、障害ＤＢ１１０のレコード
群から「誤り」の数を、ソフトウエアシステム全体、及
び各サブシステムごとに集計する。誤り率算出部２５８
は、集計した「誤り」数に基づき「誤り率」を算出す
る。すなわち、誤り率算出部２５８は、試験評価表１４
０（図５）における「現状推定品質」欄や「完了時推定
品質」欄の各項目の算出処理を行う。

【００５７】表示処理部２３０は、目標項目数表示手段
である試験対応表表示部２３２と、試験進捗表示手段で
ある試験評価表表示部２３４と、を含む。前者は試験対
応表１３０を表示し、後者は試験評価表１４０を表示す
る。試験対応表１３０の表示により、開発部門の試験担
当者は、各サブシステムにそれぞれどの程度の重みを置
いて試験項目群を作成したらよいかが分かり、より効果
的な試験項目の設計の助けとなる。また、試験評価表１
４０の表示により、試験担当者や管理者は各サブシステ
ムごとの試験の進捗状況を把握することができ、従来よ
りもきめ細かい試験進捗の管理が可能となる。

【００５８】次に、検査部門システム３００について説
明する。検査部門システム３００において、製作者能力
分析部３１０は、試験対応表１３０と試験評価表１４０
の情報に基づいて、開発部門の各製作担当チームの能力
分析を行う。能力分析は、各製作担当チームが作成した
サブシステムの複雑度と誤り率の相関に基づき行う。す
なわち、試験評価表１４０における各サブシステムの
「誤り率」と「製作担当チーム」の情報と、試験対応表
１３０における各サブシステムの「複雑度」との情報を
組み合わせ、それらの相関関係を求める。能力分析は開
発部門での試験の完了後に行うので、ここで用いる「誤
り率」は、試験評価表１４０の「現状推定品質」欄又は
「完了時推定品質」欄のどちらの「誤り率」を用いても
よい（既にすべての試験項目について合格となっている
はずなので、推定値ではなく確定値となっている）。図
６は、各サブシステムの製作担当チーム、誤り率及び複
雑度をまとめた表である。製作者能力分析部３１０は、
この表を作成し、更に図７に示すような各製作担当チー
ムごとの誤り率と複雑度の相関関係を表す製作者能力表
３１２を生成する。この製作者能力表３１２は、サブシ
ステムの誤り率及び複雑度をそれぞれ複数段階に分け、
各サブシステムの（誤り率，複雑度）の組合せに対応す
る位置に、そのサブシステムの製作担当チームを表した
ものである。例えば、図６によれば、１１０１サブシス
テムは、誤り率が０．７１で複雑度が２．２３、製作担
当チームがＡなので、図７の製作者能力表では、誤り率
０（すなわち０〜１）、複雑度２（すなわち２〜３）の
欄に製作担当チームＡが表されている。

【００５９】作成された製作者能力表３１２は、能力表
表示部３１４に表示される。この製作者能力表３１２の
表示は、抜き取り検査のサンプル絞込のために有用な情
報となる。例えば、図７の例では、Ａチームは、複雑度
が２までは誤り率がゼロ台であり、複雑度３に上がって
も誤り率が２以下であることが分かる。したがって、こ
こから、Ａチームの作ったサブシステムは、複雑度２以
下については抜き取り検査の必要がなく、複雑度３のサ
ブシステムからいくつかサンプルを抜き出して検査する
などの方針が立てられる。また、Ｃチームは、複雑度が
２になると誤り率が急増しており、これから複雑度２以
上のサブシステムはすべて検査した方がよいなどの方針
が得られる。また、Ｄチームは製作したサブシステムが
１つしかないので、誤り率ゼロ台という今回の結果の信
憑性はそれほど高いものとは言えない。したがって、こ
の場合はそのサブシステムを検査する必要があるなどと
判断できる。また、Ｂチームは、複雑度３という複雑な
サブシステムで誤り率がゼロ台であるにもかかわらず、
複雑度１で誤り率が１台のケースがあり、複雑度によら
ず誤り率がばらついている。このため、Ｂチームについ
ては、チーム内部の個別担当者レベルなどでの原因究明
が必要などとの判断ができる。ばらつきの原因が究明で
きれば、Ｂチームの各サブシステムの試験結果をその原
因レベル（例えば個別担当者が誰かなど）で更に細かく
分析し、その原因レベルの分類ごとに抜き取り検査の絞
込を行えばよい。

【００６０】以上、この実施の形態のソフトウエア品質
検査支援システムの構成について説明した。次に、この
システムを用いた品質検査の作業手順を説明する。この
手順は、大きく分けて開発部門での試験・修正サイクル
のフェーズと、その開発部門での試験結果を検査部門で
検証するフェーズとに分けられる。

【００６１】図８は、主として開発部門のフェーズの作
業手順を示している。まず最初に、対象となるソフトウ
エアシステム用に障害ＤＢ１１０及び進捗ＤＢ１２０を
準備する（Ｓ１０）。この障害ＤＢ１１０、進捗ＤＢ１
２０は、検査部門が定めた所定形式に準拠したものとす
る。次に、試験対応表１３０を設計する（Ｓ１１）。こ
のＳ１１の手順を図９を用いて更に詳しく説明する。

【００６２】Ｓ１１では、まず開発部門の試験担当者
は、要求仕様書などから当該ソフトウエアの実現すべき
「業務」群を求めて試験対応表１３０（図４参照）に設
定する（Ｓ１１０）。更に、各「業務」ごとの総試験項
目数をＦＰ法等により求め、これを試験対応表１３０の
各業務の「項目数」の「合計」欄に設定する（Ｓ１１
０）。また、ソフトウエアシステムを構成する各サブシ
ステムを、試験対応表１３０の各行に設定していく（Ｓ
１１２）。そして、試験対応表１３０の各業務ごとに、
各サブシステムの占めるウェイトを設定する（Ｓ１１
４）。ウェイトの設定が完了すると、目標項目数算出部
２５２が、各業務における各サブシステムに関する試験
項目の目標数を算出する（Ｓ１１６）。そして、この算
出された目標項目数が、試験対応表１３０に登録される
（Ｓ１１８）。

【００６３】このようにして試験対応表１３０ができる
と、次に試験担当者は、この試験対応表を参照しつつ、
各業務についての試験項目群を作成する（Ｓ１２）。こ
のとき、試験対応表における各業務の各サブシステムの
目標項目数の情報が、試験項目作成の指針となる。

【００６４】次に、試験評価表１４０（図５）を作成す
る（Ｓ１３）。この最初の段階では、試験評価表はほと
んど空欄である。

【００６５】このようにして障害ＤＢ１１０、進捗ＤＢ
１２０、試験対応表１３０及び試験評価表１４０の準備
が終わると、作成した試験項目を順次実施していき、そ
の結果を各ＤＢに登録していく（Ｓ１４）。この試験に
おいて障害が検出されると、それが報告され、修正等の
処置がなされる。このような試験・修正のサイクルを、
全試験項目について合格の結果が得られるまで繰り返す
（Ｓ１５）。全項目について合格となると、開発部門で
は所定品質のソフトウエアシステムが完成したとして、
検査部門にその検証を求める。

【００６６】検査部門の作業手順は図１０に示される。
検査部門は、開発部門から検証を求められると、まずデ
ータベース部１００から試験結果の試験対応表１３０及
び試験評価表１４０を取得する（Ｓ２０）。製作者能力
分析部３１０が、その試験結果から、各サブシステムの
製作担当チーム、誤り率、複雑度の情報を抽出し（Ｓ２
２）、製作者能力表３１２を作成する（Ｓ２４）。作成
された製作者能力表３１２は、能力表表示部３１４によ
り表示される（Ｓ２６）。検査部門の担当者は、この製
作者能力表３１２を見て、抜き取り検査を行うサブシス
テムを絞り込む（Ｓ２８）。そして、絞り込んだサブシ
ステムを抜き取り、そのソースコードの検査などを行う
（Ｓ３０）。

【００６７】以上、この実施の形態のシステム構成及び
処理手順について説明した。以上説明したように、この
実施の形態によれば、まずウェイト設定により試験項目
の作成指針となる各サブシステムごとの目標試験項目数
が得られるので、効果的な試験項目群の設計の助けとな
る。また、業務ごとに実施される試験項目の結果を、そ
のウェイトに従って各サブシステムに分配し、各サブシ
ステムごとの試験進捗状況を提示できるので、物理的な
実体としての「サブシステム」（プログラム）単位での
試験進捗を把握することができ、試験進捗の管理をより
きめ細かく行うことが可能になる。また、この実施の形
態では、各サブシステムの複雑度と誤り率とに基づき製
作者能力表を作成して表示することができ、この表示
は、抜き取り検査のサンプル絞込において有用な指針と
なる。

【００６８】なお、この実施の形態では、図７のような
製作者能力表３１２により製作担当チームの能力傾向を
表現したが、このような表の代わりに、誤り率、複雑度
をそれぞれ軸とするグラフの形で表現してもよい。

【００６９】また、製作者能力表は、抜き取り検査のサ
ンプル絞込だけでなく、様々な用途に応用可能である。
例えば、この表から能力が高いチーム（複雑度が高くて
も誤り率が低いチーム）、能力が低いチームを求め、次
のソフトウエアの開発の際に、能力が高いチームほど難
しいプログラムの作成に従事させるなど、開発体制づく
りに役立てることができる。また、プログラム作成教育
などにおいて、カリキュラムを進めていく際、作成した
プログラムに対して試験を行わせ、その結果に基づきこ
のような能力表を作成することにより、達成度をチェッ
クすることができる。

【００７０】実施の形態２．次に、この発明の実施の形
態２について説明する。図１１は、実施の形態２に係る
ソフトウエア品質検査支援システムの構成を示す機能ブ
ロック図である。図１１において、図１に示した構成と
同様の構成要素については同一符号を付してその説明を
省略する。

【００７１】図１１のシステムは、図１に示した実施の
形態１のシステムに対して、検査部門システム３００の
機能を拡張したものである。すなわち、この実施の形態
では、検査部門システム３００に、ガイダンス処理部３
２０と抜き取り基準記憶部３２２とが新たに設けられて
いる。

【００７２】ガイダンス処理部３２０は、製作者能力分
析部３１０で得られた分析結果（例えば製作者能力表３
１２の情報）に基づき、抜き取り検査のサンプル絞込の
指針を提示する手段である。実施の形態１では、担当者
が製作者能力表３１２の表示を読み取って抜き取り検査
の方針を決めていたが、この実施の形態では、「Ｃチー
ムは複雑度２以上のサブシステムを全件検査した方がよ
いと判断されます」などと、具体的な抜き取り対象絞込
の指針を提示する。

【００７３】どのような指針を提示するかの基準となる
情報は、抜き取り基準記憶部３２２に記憶されている。
この抜き取り基準記憶部３２２には、例えば「誤り率が
ゼロ台しかない複雑度については、抜き取りを行わな
い」、「誤り率が３を超える複雑度については全件抜き
取りを行う」、などのルールが登録されている。ガイダ
ンス処理部３２０は、製作者能力の分析結果に対し、こ
のルールを適用することにより、各製作担当チームごと
にどの複雑度のサブシステムをどの程度抜き取って検査
したらよいか、等の指針を表示する。

【００７４】この実施の形態２によれば、より具体的な
抜き取り検査の指針が得られるので、担当者の負担を軽
減することができる。とくにソフトウエアシステムが大
規模になるほど、このような具体的な指針の提示は大き
な助けとなる。

【００７５】実施の形態３．次に、この発明の実施の形
態３について説明する。図１２は、実施の形態３に係る
ソフトウエア品質検査支援システムの構成を示す機能ブ
ロック図である。図１２において、図１に示した構成と
同様の構成要素については同一符号を付してその説明を
省略する。

【００７６】図１２のシステムは、図１に示した実施の
形態１のシステムに対して、検査部門システム３００の
機能を拡張したものである。この実施の形態では、検査
部門システム３００に、重複誤り集計部３３０と試験性
能評価部３３２とが新たに設けられている。

【００７７】この実施の形態３では、開発部門の試験結
果から、各製作担当チームの能力だけでなく、試験に用
いた試験項目群の適切さ（試験性能と呼ぶ）を分析し、
その試験結果の妥当性を検証する。

【００７８】試験性能は、重複誤りによって判定する。
複数の障害報告の原因が、ソフトウエアシステムの同じ
部分の誤りであった場合、その誤りを重複誤りという。
重複誤りは、障害ＤＢ１１０の障害報告（図２参照）の
「重複」フラグから割り出すことができる。重複誤り
は、別々の試験項目で同じ誤りに起因する障害が検出さ
れたことを意味する。これは、本来なら１つの試験項目
で十分検出できている誤りに対し、複数の試験項目が作
成されていたことを意味する。試験項目は、ＦＰ法など
により予め総数を決めているので、このような重複的な
試験項目が存在すれば、他の部分についての試験項目の
密度がその分薄くなっていることになる。したがって、
重複誤りの比率が高いほど、開発部門で作成した試験項
目群の性能が悪く、ひいては開発部門での試験結果（試
験対応表や試験評価表など）の信頼性が低いことを意味
する。そこで、この実施の形態では、重複誤りの程度に
基づき試験性能を判断し、開発部門での試験結果の信頼
性を判断する。

【００７９】重複誤り集計部３３０は、障害ＤＢ１１０
のレコードから、重複誤りの数を集計する。この集計
は、サブシステム単位で行う。すなわち、障害ＤＢ１１
０のレコード（図２参照）で、「重複」フラグが重複誤
りを示す値にセットされているものを見つけ、それらの
うち「修正サブシステム名」を同じくするものの数を各
サブシステムごとに集計する。

【００８０】試験性能評価部３３２は、その集計結果を
もとに、各サブシステムごとの重複誤り率を算出する。
図１３は、この重複誤り率の算出の方法を説明するため
の図である。各サブシステムの重複誤り率は、当該サブ
システムの重複誤り数の、当該サブシステムの試験項目
数（すなわちウェイトから求めた目標項目数）に対する
百分率として求める。このようにして求めた重複誤り率
は、当該サブシステムをターゲットとして作成した試験
項目のうち、どの程度が重複して無駄となっているかを
示している。

【００８１】検査部門の担当者は、この重複誤り率の分
布を見て、試験性能を判断する。例えば、すべてのサブ
システムの重複誤り率が３以下であれば、開発部門での
試験が信頼性の高い網羅的なものであったなど判断でき
る。このように、開発部門での試験が妥当だと判断した
場合は、検査部門は、その試験結果に基づいて前述した
抜き取り検査の処理を行う。これに対し、開発部門での
試験性能が低いと判断した場合は、検査部門は、開発部
門に対して試験のやり直しなどを指示するなどの処置を
する。この場合、例えば、重複誤り率が許容限度以上に
高いサブシステムを指摘し、そのサブシステムをターゲ
ットとした試験項目を追加作成するなどの指示を行うこ
とができる。そして、検査部門は、この再試験の結果を
開発部門から受け取り、再度その結果から試験性能を判
断し、十分な試験性能だと判断すれば抜き取り検査に進
む。

【００８２】このように、この実施の形態によれば、重
複誤りの集計結果をもとに、網羅的な信頼性の高い試験
がなされたかを判断することができるので、信頼性の低
い試験結果をベースに抜き取り検査を行うなどの無駄を
なくすことができる。

【００８３】実施の形態４．以上の実施の形態では、検
査部門は、図１４に示すように開発部門での試験実施
（Ｓ３００）の結果を受けて検査を実施し（Ｓ３１
０）、その合否を判定している（Ｓ３２０）。この手順
では、開発部門自身が試験段階での合否判定を行ってお
り、検査部門は、開発部門による合格の旨の自己判定を
そのまま受け入れて抜き取り、抜き取り検査などの検査
処理を開始している。

【００８４】ところが、仮にこの検査部門の自己判定に
誤りがあるなどして実際には合格水準に達していない項
目があった場合、検査部門の検査でも不合格になる可能
性が高い。検査部門による検査には一般に数日から十数
日程度の期間が必要なので、このようなケースでは時間
のロスになる可能性が高い。

【００８５】そこで、この実施の形態では、そのような
ロスを未然に防ぐために、図１５に示すように、検査部
門において、検査実施（Ｓ３１０）の前に、受入判定
（Ｓ３３０）のステップを設けた。この受入判定では、
開発部門からの検証依頼に応じ、開発部門での試験結果
を調べ、試験結果レベルで所定の品質を満足しているか
どうか判断する。

【００８６】図１６は、この実施形態のシステム構成例
を示す図である。この構成例は、実施の形態１のシステ
ムをベースにしたものであり、検査部門システム３００
に受入判定部３４０を設けた以外は、実施の形態１と同
様のシステムである。

【００８７】受入判定部３４０は、開発部門側からのソ
フトウエア検査依頼を受け入れるかどうかの判定処理の
支援を行う。この受入判定支援処理では、担当者が受入
判定対象の検査依頼を指定して受入判定部３４０を起動
すると、受入判定部３４０は、その依頼に係るソフトウ
エアの試験評価表１４０の情報をデータベース部１００
から取得し、その評価表１４０に示される試験結果が所
定の基準を満足しているかを判定する。この基準は、例
えば最終的な誤り率（残存誤り率）が予め定めたしきい
値以下になっているなどのルールである。もちろん、誤
り率以外の試験結果の特徴値について受入判定基準を設
けることも可能である。この判定基準は、ソフトウエア
全体についての特徴値について定めることもできるし、
サブシステム単位の基準として定めることもできる。サ
ブシステム単位の場合、個別のサブシステムごとに別々
のしきい値を定めることも可能である。このような受入
判定基準は、検査部門での抜き取り検査に移行するため
の移行基準ともいえる。このような受入判定基準は、予
め策定され、検査部門システム３００に登録されてい
る。受入判定部３４０は、試験結果の各特徴値がその判
定基準を満足しているかどうかを調べる。

【００８８】なお、この受入判定の際に、開発部門から
検査部門への提出書類が揃っているか否かや、その書類
に記載されている内容に不備がないかなどを調べ、この
ような点についての不備がないことを確認してから検査
にはいるようにすれば、さらに検査の無駄を防止でき
る。ただし、このような書類等の項目は、一般にコンピ
ュータによる自動判定が困難であり、人手により行う
が、この人手による処理を受入判定部３４０により支援
するようにすることも好適である。例えば、人手による
判定項目やその手順などをユーザに対して表示し、ユー
ザがこれを参照しながら作業を進めるようにするなどで
ある。なお、開発部門から検査部門への提出書類を定型
化、電子化すれば、このようなチェック作業のかなりの
部分を自動化することも可能である。

【００８９】さて、受入判定部３４０では、このような
自動的及び人手による個々の判定項目の判定結果を総合
して、全体としての受入判定を行う。すべての項目が合
格である場合は、制作者能力分析部３１０等による検査
処理（Ｓ３１０）に移行する許可を出す。

【００９０】一方、不合格の項目があれば、受入判定部
３４０は、検査依頼が受け入れられないと判定し、その
判定結果を検査部門の担当者に表示したり、あるいは依
頼側の開発部門に対して通知したりする。なお、この場
合、受入判定部３４０は、例えばどのサブシステムのど
の特徴値が不合格であったかなど、不合格の項目につい
ての説明を記載したレポートを自動作成し、それを不合
格の旨の通知に対応づけて、開発部門側に通知する。こ
のレポートに、不合格項目についての達成課題（例えば
誤り率などの目標値や、その目標値と現状との差など）
を含めれば、開発部門側での修正作業の参考とすること
ができる。

【００９１】このように、この実施の形態４によれば、
開発部門での試験の結果が予め定めた基準を満足してい
るかの判定を支援するツール（受入判定部３４０）を検
査部門システム３００に設けたので、開発部門側での不
備などによる無駄な検査の実行を低減することができ
る。

【００９２】なお、ここでは実施の形態１をベースに受
入判定部３４０を付加した例を説明したが、当業者には
明らかなように、実施の形態２や３の検査部門システム
３００に同様の受入判定部３４０を設けることも可能で
ある。

【００９３】また、以上の実施の形態１〜４では、開発
部門に開発部門システム２００を設けたが、この開発部
門システム２００と同等の機能を、ＷＷＷ（ワールド・
ワイド・ウェブ）のウェブサービスとして提供すること
も可能である。図１７は、このようなウェブベースでの
試験支援のシステム例を示す図である。この例では、実
施の形態１等で開発部門システム２００に実装されてい
た入力処理部２１０，表示処理部２３０，演算処理部２
５０が、ＷＷＷサーバ４００内のアプリケーションとし
て実装されている。これらは、例えばＣＧＩ（Common G
ateway Interface）アプリケーションとして実装され
る。

【００９４】各開発部門は、ウェブブラウザ（開発部門
ブラウザ６００）を用い、インターネット５００を介し
てこのＷＷＷサーバ４００にアクセスする。すると、Ｗ
ＷＷサーバ４００は、ユーザ認証用のウェブページを開
発部門ブラウザ６００に送り、ユーザＩＤやパスワード
などの認証情報の入力を求める。これに対して開発部門
ブラウザ６００から認証情報が送信されてくると、ＣＧ
Ｉなどで実現されるユーザ認証部２７０がその認証情報
を基にユーザ認証を行う。このため、開発部門は予めＷ
ＷＷサーバ４００にユーザ登録を行っておく。ユーザ認
証で正当なユーザと判断された場合、ＷＷＷサーバ４０
０は、サブシステムの数やウェイト、試験項目数など試
験設計のための入力項目を入力するためのウェブページ
や、当該ユーザの既に作成されている試験対応表や試験
評価表の内容を表示するウェブページや、それらの表に
データを入力するためのウェブページなどを、要求に応
じてそのユーザに提供する。このとき、表示処理部２３
０は、データベース部１００に登録された当該ユーザ
（開発部門）の登録情報から、そのユーザの試験対応表
や試験評価表などを表示したウェブページを作成する。
また入力処理部２１０は、入力用ウェブページにて入力
されたデータを、データベース部１００の当該ユーザの
登録情報に反映させる。演算処理部２５０は、入力デー
タに応じ、前述のようにして試験評価表その他の各種項
目の値を計算し、データベース部１００の登録データに
反映させる。なお、演算処理部２５０は、ＷＷＷサーバ
４００に実装する代わりに、データベース部１００に実
装することも好適である。

【００９５】このようなＷＷＷサーバ４００をベースと
した仕組みを設けることにより、開発部門は、実施の形
態１などの場合のように大規模な開発部門システム２０
０を持たなくても、ＷＷＷのブラウザを持つだけで、上
記各実施の形態と同等の支援処理を受けることができ
る。したがって、検査部門と開発部門が別会社の場合な
どにも、容易に本発明に係るシステムを展開することが
できる。

【００９６】また、このようなＷＷＷベースの仕組みに
おいて、検査部門システム３００からＷＷＷサーバ４０
０にアクセスし、各開発部門の試験対応表や試験評価表
を閲覧できるようにすることも好適である。これには、
検査部門に対し閲覧のみを許す権限を付与し、ＷＷＷサ
ーバ４００のユーザ認証により検査部門からのアクセス
と判断された場合には、各開発部門の試験評価表等の表
示のみを許すようにすればよい。このようにすることに
より、検査部門は、各開発部門の試験進捗状況（これは
開発の進捗状況ととらえることもできる）を随時確認す
ることができ、開発部門からの検査依頼の到来に備えた
り、あるいは検査依頼の来る前に、試験評価表などから
読みとれる事項などについて開発部門にアドバイスをし
たりするなどの対処をとることが可能になる。

【００９７】

【発明の効果】この発明は、以上説明したように構成さ
れているので、以下に示すような効果を奏する。

【００９８】この発明によれば、業務単位の試験項目数
だけでなく、サブシステム単位の試験項目数が目安とし
て提示できるので、ユーザはこの情報を参照することに
より効果的な試験項目群を作成できる。

【００９９】また、この発明によれば、業務ごとの試験
結果を受け付け、それをサブシステム単位にブレークダ
ウンして提示できるので、ユーザは、試験の進捗状況
を、物理的な実体であるサブシステムの単位で把握する
ことができ、きめ細かな試験進捗の管理が可能になる。

【０１００】また、この発明によれば、試験結果に基づ
き各サブシステムを製作した各製作者の能力情報を求
め、それを表示することができるので、ユーザはその表
示により、各製作者の作成したサブシステムをどの程度
検査（例えば抜き取り検査）すればよいかなどを判断で
きる。

【０１０１】また、この発明によれば、各サブシステム
の製作者を、当該サブシステムの複雑度と誤り率の組合
せで規定される位置にプロットした製作者能力表を表示
することにより、ユーザは、製作者の能力を視覚的に容
易に把握することができる。

【０１０２】また、この発明によれば、誤り数を集計す
る手段と、プログラム規模を入力する手段を設けたの
で、集計した誤り数とプログラム規模とに基づき誤り率
を算出することができる。

【０１０３】また、この発明によれば、製作者能力の分
析結果に基づき、抜き取り検査の対象の絞込のための指
針を提示するガイダンス処理手段を設けたので、ユーザ
は抜き取り対象の絞込をより容易に行うことができる。

【０１０４】また、この発明によれば、重複誤りを集計
し、その結果に基づき、試験項目の性能評価を行うこと
ができるので、その評価結果をもとに、試験結果自体の
信頼性を判断することができる。

【０１０５】また、この発明によれば、試験結果が抜き
取り検査への移行基準を満足するかどうかを判定し、そ
の判定結果を出力することで、移行基準を満足しないう
ちに抜き取り検査に移ることを抑制し、無駄な検査を低
減することができる。

【０１０６】また、この発明によれば、移行基準を満足
しないサブシステムを示したレポートを作成すること
で、どのサブシステムについて修正を行えばよいかなど
の目安を提供することができる。

【図面の簡単な説明】

【図１】 実施の形態のソフトウエア品質検査支援シス
テムの全体構成を示す機能ブロック図である。

【図２】 障害ＤＢのレコードのデータ構造の一例を示
す図である。

【図３】 進捗ＤＢのレコードのデータ構造の一例を示
す図である。

【図４】 試験対応表の一例を示す図である。

【図５】 試験評価表の一例を示す図である。

【図６】 各サブシステムの製作担当チーム、誤り率、
及び複雑度を抽出した表を示す図である。

【図７】 製作担当チーム、誤り率及び複雑度の相関関
係を表す製作者能力表を示す図である。

【図８】 開発部門での作業手順を示すフローチャート
である。

【図９】 試験対応表の設計作業の詳細手順を示すフロ
ーチャートである。

【図１０】 検査部門の作業手順を示すフローチャート
である。

【図１１】 実施の形態２のシステム構成を示す機能ブ
ロック図である。

【図１２】 実施の形態３のシステム構成を示す機能ブ
ロック図である。

【図１３】 重複誤り率の算出の方法を説明するための
図である。

【図１４】 実施の形態１などでの開発部門から検査部
門への移行の流れを示した図である。

【図１５】 実施の形態４での開発部門から検査部門へ
の移行の流れを示した図である。

【図１６】 実施の形態４のシステム構成を示す機能ブ
ロック図である。

【図１７】 各実施の形態のシステムにおけるサービス
をＷＷＷサーバにて提供する形態を説明する図である。

【符号の説明】

１００ データベース部、１１０ 障害ＤＢ、１２０
進捗ＤＢ、１３０ 試験対応表、１４０ 試験評価表、
２００ 開発部門システム、２１０ 入力処理部、２１
２ ウェイト設定部、２３０ 表示処理部、２５０ 演
算処理部、３００ 検査部門システム、３１０ 製作者
能力分析部、３１２ 製作者能力表、３１４ 能力表表
示部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 高野 茂樹 東京都千代田区丸の内二丁目２番３号 三 菱電機株式会社内 (72)発明者 佐藤 忠勝 東京都千代田区丸の内二丁目２番３号 三 菱電機株式会社内 Ｆターム(参考） 5B042 HH19 HH20 NN01 NN21 5B076 EC10

Claims (11)

【特許請求の範囲】
1. 【請求項１】 １以上の業務を複数のサブシステムの組
   合せにより実行するソフトウエアシステムについて、そ
   のソフトウエアシステムの品質検査を支援するためのソ
   フトウエア品質検査支援システムであって、 該ソフトウエアシステムが実行する各業務ごとに、前記
   各サブシステムのその業務に関するウェイトを設定する
   ウェイト設定手段と、 前記各業務ごとに、その業務に関する前記ソフトウエア
   システムの機能検証のために試験すべき試験項目の数を
   設定する試験項目数設定手段と、 前記各業務ごとに、前記試験項目数設定手段で設定した
   当該業務の試験項目数と、前記ウェイト設定手段で設定
   した当該業務に関する前記各サブシステムのウェイト
   と、に基づき、各業務ごとの各サブシステムの目標試験
   項目数を算出する目標項目数算出手段と、 前記目標項目数算出手段で算出した各業務ごとの各サブ
   システムの目標項目数を表示する目標項目表示手段と、 を備えるソフトウエア品質検査支援システム。
2. 【請求項２】 前記各業務ごとに、その業務について実
   施した試験項目の実施結果の入力を受け付ける試験結果
   入力手段と、 前記試験結果入力手段で受け付けた各業務ごとの試験結
   果と、当該業務についての各サブシステムのウェイト
   と、に基づき、それら各サブシステムごとの試験実施進
   捗情報を求める試験進捗管理手段と、 前記試験進捗管理手段で求めた前記各サブシステムごと
   の試験実施進捗情報を表示する試験進捗表示手段と、 を備える請求項１に記載のソフトウエア品質検査支援シ
   ステム。
3. 【請求項３】 前記各サブシステムの製作者を登録する
   手段と、 前記各サブシステムごとの目標項目数の合計と、実際に
   作成された前記各サブシステムのプログラム規模とに基
   づき、前記各サブシステムの複雑度を算出する複雑度算
   出手段と、 前記試験項目群の実施により検出された各サブシステム
   ごとの誤り数と、それら各サブシステムのプログラム規
   模とに基づき、前記各サブシステムの誤り率を算出する
   誤り率算出手段と、 各サブシステムごとの複雑度と誤り率の相関を求め、こ
   の相関と各サブシステムの製作者との関連から、製作者
   能力分析情報を作成する製作者能力分析手段と、 を備える請求項１又は請求項２記載のソフトウエア品質
   検査支援システム。
4. 【請求項４】 前記製作者能力分析情報は、複雑度と誤
   り率とを２軸とする２次元空間において、前記各サブシ
   ステムの製作者を、当該サブシステムの複雑度と誤り率
   の組合せで規定される位置にプロットした製作者能力表
   であり、 前記製作者能力分析手段は、作成した前記製作者能力表
   を表示する手段を有することを特徴とする請求項３記載
   のソフトウエア品質検査支援システム。
5. 【請求項５】 前記試験項目の実施に伴う障害の報告を
   受け付ける障害報告入力手段と、 前記障害報告に対して処置を行ったサブシステムについ
   て誤り数の登録を受け付け、各サブシステムごとに誤り
   数を集計する手段と、 各サブシステムのプログラム規模の入力を受け付ける手
   段と、 を備え、 前記誤り率算出手段は、前記各サブシステムごとに、そ
   の誤り数とプログラム規模とに基づき誤り率を算出する
   ことを特徴とする請求項３記載のソフトウエア品質検査
   支援システム。
6. 【請求項６】 前記製作者の能力分析情報に基づき、前
   記各製作者ごとにどの複雑度レベルまでのサブシステム
   を抜き取り検査すべきかを示す抜き取り指針を求めて提
   示するガイダンス処理手段を更に備える請求項３記載の
   ソフトウエア品質検査支援システム。
7. 【請求項７】 前記障害報告に対して行った処置の報告
   として、当該障害の原因が以前に処置した同一サブシス
   テムの同一箇所であることを示す重複誤り情報の入力を
   受け付ける手段と、 受け付けた重複誤り情報群に基づき、各サブシステムご
   との重複誤り数を集計する重複誤り集計手段と、 集計した重複誤り数に基づき、前記試験項目群の性能の
   評価のための情報を生成して提示する試験性能評価手段
   と、 を更に備える請求項５記載のソフトウエア品質検査支援
   システム。
8. 【請求項８】 前記抜き取り検査に移行する移行基準を
   記憶する手段と、 前記試験結果がその移行基準を満足しているか否かを判
   定し、その判定結果を出力する手段と、 を備える請求項６記載のソフトウエア品質検査支援シス
   テム。
9. 【請求項９】 前記試験結果が前記移行基準を満足して
   いない場合、その基準を満足しないサブシステムを示し
   たレポートを生成する手段をさらに備える請求項８記載
   のソフトウエア品質検査支援システム。
10. 【請求項１０】 １以上の業務を複数のサブシステムの
    組合せにより実行するソフトウエアシステムについて、
    そのソフトウエアシステムの品質検査を支援するための
    ソフトウエア品質検査支援方法であって、 該ソフトウエアシステムが実行する各業務ごとに、前記
    各サブシステムのその業務に関するウェイトを設定する
    ウェイト設定ステップと、 前記各業務ごとに、その業務に関する前記ソフトウエア
    システムの機能検証のために試験すべき試験項目の数を
    設定する試験項目数設定ステップと、 前記各業務ごとに、前記試験項目数設定ステップで設定
    した当該業務の試験項目数と、前記ウェイト設定ステッ
    プで設定した当該業務に関する前記各サブシステムのウ
    ェイトと、に基づき、各業務ごとの各サブシステムの目
    標試験項目数を算出する目標項目数算出ステップと、 前記目標項目数算出ステップで算出した各業務ごとの各
    サブシステムの目標項目数を表示する目標項目数表示ス
    テップと、 を備えるソフトウエア品質検査支援方法。
11. 【請求項１１】 前記各サブシステムの製作者を登録す
    るステップと、 前記各サブシステムごとの目標項目数の合計と、実際に
    作成された前記各サブシステムのプログラム規模とに基
    づき、前記各サブシステムの複雑度を算出する複雑度算
    出ステップと、 前記試験項目群の実施により検出された各サブシステム
    ごとの誤り数と、それら各サブシステムのプログラム規
    模とに基づき、前記各サブシステムの誤り率を算出する
    誤り率算出ステップと、 各サブシステムごとの複雑度と誤り率の相関を求め、こ
    の相関と各サブシステムの製作者との関連から、製作者
    能力分析情報を作成する製作者能力分析情報作成ステッ
    プと、 を備える請求項１０記載のソフトウエア品質検査支援方
    法。