JP4502535B2 - ソフトウエア品質検査支援システム及び方法 - Google Patents
ソフトウエア品質検査支援システム及び方法 Download PDFInfo
- Publication number
- JP4502535B2 JP4502535B2 JP2001080595A JP2001080595A JP4502535B2 JP 4502535 B2 JP4502535 B2 JP 4502535B2 JP 2001080595 A JP2001080595 A JP 2001080595A JP 2001080595 A JP2001080595 A JP 2001080595A JP 4502535 B2 JP4502535 B2 JP 4502535B2
- Authority
- JP
- Japan
- Prior art keywords
- subsystem
- test
- quality inspection
- target
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、ソフトウエアの品質検査の支援のためのシステムに関し、効果的な試験項目の作成や抜き取り検査のサンプルの絞込の支援のための技術に関する。
【０００２】
【従来の技術】
ソフトウエア開発の現場では、誤りができるだけ少ない高品質の商品（ソフトウエアシステム）を提供するため、いったん作成したソフトウエアに対して試験を行って所期の性能が達成されているか確認し、達成されない場合はその原因（誤り、バグ）を突き止め、コードの修正などの処置を行っている。そして、この試験、修正の作業を繰り返すことにより、ソフトウエアに含まれる誤りを低減している。
【０００３】
ソフトウエアの試験のためには、まず、要求性能（仕様）の各項目が実現されていることを確かめるための試験項目を必要なだけ設定する。そして、作成したソフトウエアシステムにてこれら各試験項目の内容を実施し、その試験項目の内容が正しく実行できたかどうかを調べる。正しく実行できなかった試験項目があれば、そのとき症状が障害として報告され、この報告に基づき処置が行われる。従来、ソフトウエア試験のための試験項目は、ソフトウエア開発部門等の担当者が、そのソフトウエアの要求仕様から、自己の経験に基づいて作成するのが一般的であった。また、試験自体もそのソフトウエアの開発部門が行うことが一般的であった。
【０００４】
また、近年ソフトウエアについてもＩＳＯ９０００シリーズなどに準拠した高度な品質保証モデルの導入の必要性が叫ばれている。高度な品質保証を実現するには、従来開発部門が自前で行っていたソフトウエア品質管理だけでなく、第三者的な立場からソフトウエアの品質をチェックしたり、開発部門の品質管理自体の質をチェックしたりする検査部門の設立が求められる。
【０００５】
検査の統一性や経済性等の観点から、検査部門は１企業（あるいは１事業所など）に１つ設けられるのが一般的であり、１つの検査部門が企業内にある数多くの開発部門の開発したソフトウエアシステムを検査することになる。このため、検査部門の検査効率の向上は、企業のソフトウエア開発全体のサイクルを左右する重要なファクタとなる。
【０００６】
【発明が解決しようとする課題】
ソフトウエアの試験・修正作業では、効果的な試験項目を選ばないと、ソフトウエアシステムに内在する誤りを効率よく見つけ出すことができない。これは、試験・修正作業の効率のみならず、最終的なソフトウエア商品の品質にも大きな影響をもたらす。従来、この試験項目の設計が完全に開発者（あるいは開発部門）の経験や勘に任されていたため、開発者（すなわち試験項目の設計者）の能力に応じて試験の有効性に大きなばらつきが出る場合があった。試験項目群がソフトウエアシステムに要求される機能を網羅的にカバーしているか、そうでないかにより、同じ項目数の試験を実施しても、試験の効果が変わってくる。
【０００７】
また、開発部門に対して第三者的な検査部門を設けた場合、検査部門は一般に開発部門での試験・修正の結果報告を受けて、その結果の妥当性を判断し、必要に応じて機能レベル、ソースコードレベルの抜き取り検査を行う。しかしながら、このような抜き取り検査も、闇雲にサンプル抜き取りを行っていたのでは効率的ではない。従来、抜き取り検査のサンプル絞込みは、個々の検査者の技量によっており、検査の作業効率や効果の面でばらつきが出る可能性があった。
【０００８】
この発明は、上述のような課題を解決するためになされたもので、まず第１にソフトウエアシステムの試験のための効果的な試験項目の設計を支援するシステムを提供することを目的とする。更にこの発明は、抜き取り検査時のサンプルの絞込みを支援するためのシステムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
この発明に係るソフトウエア品質検査支援システムは、１以上の業務を複数のサブシステムの組合せにより実行するソフトウエアシステムについて、そのソフトウエアシステムの品質検査を支援するためのソフトウエア品質検査支援システムであって、該ソフトウエアシステムが実行する各業務ごとに、前記各サブシステムのその業務に関するウェイトを記憶すると共に、前記各業務ごとに、その業務に関する前記ソフトウエアシステムの機能検証のために試験すべき試験項目の数を記憶する記憶手段と、前記各業務ごとに、前記記憶手段に記憶された当該業務の試験項目数と、前記記憶手段に記憶された当該業務に関する前記各サブシステムのウェイトと、に基づき、各業務ごとの各サブシステムの目標試験項目数を算出する目標項目数算出手段と、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を表示する目標項目表示手段と、を備えるものである。
【００１０】
また、この発明に係るソフトウエア品質検査支援システムは、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を、各サブシステムごとにそれら各業務にわたって合計することにより、各サブシステムごとの合計目標試験項目数を計算する合計目標試験項目数計算手段と、前記各業務ごとに、その業務について実施した試験項目の数の入力を受け付ける試験結果入力手段と、前記試験結果入力手段で受け付けた各業務ごとの、前記実施した試験項目の数に、当該業務についての各サブシステムのウェイトを乗ずることにより、それら各サブシステムごとの、実施した試験項目の数を表す試験実施進捗情報を求める試験進捗管理手段と、前記試験進捗管理手段で求めた前記各サブシステムごとの試験実施進捗情報と、前記合計目標試験項目数計算手段で求めた前記各サブシステムごとの合計目標試験項目数とを対比可能に表示する試験進捗表示手段と、を備えるものである。
【００１１】
また、この発明に係るソフトウエア品質検査支援システムは、前記各サブシステムの製作担当チームの登録を受け付けるチーム登録受付手段と、前記各サブシステムごとの目標項目数の合計を、実際に作成された前記各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの複雑度を算出する複雑度算出手段と、前記試験項目群の実施により検出された各サブシステムごとの誤り数を、それら各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの誤り率を算出する誤り率算出手段と、各サブシステムごとの複雑度と誤り率と、各サブシステムの製作担当チームと、の関連を表す製作担当チーム能力分析情報を作成する製作担当チーム能力分析手段と、を備えるものである。
【００１２】
また、この発明に係るソフトウエア品質検査支援システムは、前記製作担当チーム能力分析情報は、複雑度と誤り率とを２軸とする２次元空間において、前記各サブシステムの製作担当チームを、当該サブシステムの複雑度と誤り率の組合せで規定される位置にプロットした製作担当チーム能力表であり、前記製作担当チーム能力分析手段は、作成した前記製作担当チーム能力表を表示する手段を有することを特徴とするものである。
【００１３】
また、この発明に係るソフトウエア品質検査支援システムは、前記試験項目の実施に伴う障害の報告を受け付ける障害報告入力手段と、前記障害報告に対して処置を行ったサブシステムについて誤り数の登録を受け付け、各サブシステムごとに誤り数を集計する手段と、各サブシステムのプログラム規模の入力を受け付ける手段とを備え、前記誤り率算出手段は、前記各サブシステムごとに、その誤り数とプログラム規模とに基づき誤り率を算出することを特徴とするものである。
【００１４】
また、この発明に係るソフトウエア品質検査支援システムは、前記製作担当チーム能力分析情報に基づき、前記各製作担当チームごとにどの複雑度レベルまでのサブシステムを抜き取り検査すべきかを示す抜き取り指針を求めて提示するガイダンス処理手段を更に備えるものである。
【００１５】
また、この発明に係るソフトウエア品質検査支援システムは、前記障害報告に対して行った処置の報告として、当該障害の原因が以前に処置した同一サブシステムの同一箇所であることを示す重複誤り情報の入力を受け付ける手段と、受け付けた重複誤り情報群に基づき、各サブシステムごとの重複誤り数を集計する重複誤り集計手段と、集計した各サブシステムごとの重複誤り数を、前記目標項目数算出手段が算出した当該サブシステムの目標試験項目数で除することにより、各サブシステムごとの重複誤り率を計算し、計算した各サブシステムごとの重複誤り率を提示する試験性能評価手段と、を更に備えるものである。
【００１６】
また、この発明に係るソフトウエア品質検査支援システムは、前記各サブシステムを前記抜き取り検査の対象とするための誤り率に関する基準を記憶する手段と、前記各サブシステムの前記誤り率が、前記各サブシステムを前記抜き取り検査の対象とするための前記誤り率に関する基準を満足しているか否かを判定し、その判定結果を出力する手段と、を備えるものである。
【００１７】
また、この発明に係るソフトウエア品質検査支援システムは、前記試験結果が前記移行基準を満足していない場合、その基準を満足しないサブシステムを示したレポートを生成する手段をさらに備えるものである。
【００１８】
また、この発明に係るソフトウエア品質検査支援方法は、１以上の業務を複数のサブシステムの組合せにより実行するソフトウエアシステムについて、そのソフトウエアシステムの品質検査を支援するためにソフトウエア品質検査支援システムが実行するソフトウエア品質検査支援方法であって、前記ソフトウエア品質検査支援システムは、該ソフトウエアシステムが実行する各業務ごとに、前記各サブシステムのその業務に関するウェイトを記憶すると共に、前記各業務ごとに、その業務に関する前記ソフトウエアシステムの機能検証のために試験すべき試験項目の数を記憶する記憶手段と、を備え、前記ソフトウエア品質検査方法は、前記ソフトウエア品質検査支援システムが備える目標項目数算出手段が、前記各業務ごとに、前記試験項目数記憶手段に記憶された当該業務の試験項目数と、前記ウェイト設定記憶手段に記憶された当該業務に関する前記各サブシステムのウェイトと、に基づき、各業務ごとの各サブシステムの目標試験項目数を算出する目標項目数算出ステップと、前記ソフトウエア品質検査支援システムが備える目標項目表示手段が、前記目標項目数算出ステップで算出された各業務ごとの各サブシステムの目標試験項目数を表示する目標項目数表示ステップと、前記ソフトウエア品質検査支援システムが備える合計目標試験項目数計算手段が、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を、各サブシステムごとにそれら各業務にわたって合計することにより、各サブシステムごとの合計目標試験項目数を計算するステップと、前記ソフトウエア品質検査支援システムが備える試験結果入力手段が、前記各業務ごとに、その業務について実施した試験項目の数の入力を受け付けるステップと、前記ソフトウエア品質検査支援システムが備える試験進捗管理手段が、前記試験結果入力手段で受け付けた各業務ごとの、前記実施した試験項目の数に、当該業務についての各サブシステムのウェイトを乗ずることにより、それら各サブシステムごとの、実施した試験項目の数を表す試験実施進捗情報を求めるステップと、前記ソフトウエア品質検査支援システムが備える試験進捗表示手段が、前記試験進捗管理手段で求めた前記各サブシステムごとの試験実施進捗情報と、前記合計目標試験項目数計算手段で求めた前記各サブシステムごとの合計目標試験項目数とを対比可能に表示するステップと、を備える。
【００１９】
また、この発明に係るソフトウエア品質検査支援方法は、前記ソフトウエア品質検査支援システムが備えるチーム登録受付手段が、前記各サブシステムの製作担当チームの登録するを受け付けるステップと、前記ソフトウエア品質検査支援システムが備える複雑度算出手段が、前記各サブシステムごとの目標項目数の合計を、実際に作成された前記各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの複雑度を算出する複雑度算出ステップと、前記ソフトウエア品質検査支援システムが備える誤り率算出手段が、前記試験項目群の実施により検出された各サブシステムごとの誤り数を、それら各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの誤り率を算出する誤り率算出ステップと、前記ソフトウエア品質検査支援システムが備える製作担当チーム能力分析手段が、各サブシステムごとの複雑度と誤り率と、各サブシステムの製作担当チームと、の関連を表す製作担当チーム能力分析情報を作成する製作担当チーム能力分析情報作成ステップと、を備える。
【００２０】
【発明の実施の形態】
実施の形態１．
ソフトウエアシステム（ソフトウエア製品）は、１以上の業務のための処理を実行するためのものであり、複数のサブシステムに分けて開発していくことが一般的である。個々のサブシステムは、それぞれ比較的単純な機能を実現するプログラム（又はプログラムの組）である。個々の業務は、１つのサブシステム、又は複数のサブシステムの組合せ、により実現される。この逆に、１つのサブシステムが複数の業務で兼用される場合もよくある。
【００２１】
すなわち、「業務」は、そのソフトウエアシステムが実行すべき個々の振る舞いであり、ソフトウエアシステムの要求仕様から導き出される。これに対し、「サブシステム」は、そのソフトウエアシステムを物理的に構成する個々のプログラム（又はその組）である。
【００２２】
例えば、文書エディタという１つのソフトウエアシステムを考えた場合、このソフトウエアは、文字入力、文字列検索、文書保存など様々な「業務」の実現を目的したものである。この中で例えば「文字入力」という業務は、入力キー認識プログラム、カナ漢字変換システムとのインタフェースプログラム、得られた文字コードを表示するためのプログラムなど、いくつかのサブシステム（プログラム）により実現される。そして、例えばその中の入力キー認識のためのサブシステムは、「文字列検索」業務でも利用される。
【００２３】
ソフトウエアシステムの試験は、要求仕様が満足されているかどうかを検査するため、要求仕様により規定される「業務」単位に行う。
【００２４】
このようなソフトウエアシステムの効果的な品質検査の支援のため、この実施の形態では、図１に示すソフトウエア品質検査支援システムを提供する。このシステムは、ソフトウエアの開発部門での試験・修正のサイクルを支援する開発部門システム２００、検査部門でのソフトウエア品質検査を支援するための検査部門システム３００、及びそれら両者の試験・検査の作業のために利用する諸データを管理するデータベース部１００とを備えている。
【００２５】
データベース部１００は、障害ＤＢ（データベース）１１０、進捗ＤＢ１２０、試験対応表１３０及び試験評価表１４０を含んでいる。
【００２６】
障害ＤＢ１１０は、開発部門等での試験・修正サイクル等で出てくる障害報告やその処置報告の内容を蓄積するデータベースである。障害ＤＢ１１０に蓄積されるレコードのデータ構造の例を図２に示す。このデータ構造には、障害検出時に付与又は入力される情報と、障害処置時に入力される情報とが含まれる。障害検出時に付与又は入力される情報には、障害報告の一意な識別番号である「障害報告番号」、その報告の内容を示す「件名」、障害を発見したときの業務の「業務ＩＤ」、障害の「発生日」、当該障害の起こったソフトウエアシステムの「製品番号」、版名、その障害を検出した「検出部門（及び／又は検出者）」、その障害の「現象」の説明などがある。一方、障害処置時に入力される情報には、その処置について回答した「回答者」、その障害がプログラム自体の誤りであったか否かを示す「誤り」フラグ、その障害報告が以前の報告と同一箇所の誤りに起因すると判断された場合にセットされる「重複」フラグ、以前にその同一箇所の誤りを報告した障害報告の番号を示す「重複障害番号」、その以前の障害報告の際の業務を示す「重複業務ＩＤ」、当該障害報告に対して行った処置を表す「処置区分」、処置のために修正したサブシステムを示す「修正サブシステム名」、修正の概要を示す「修正情報」、及び修正によって改版した場合の「修正版名」などを含んでいる。なお、障害報告が「重複」でなかった場合は「重複障害番号」や「重複業務ＩＤ」は空欄となり、プログラムの修正を行わなかった場合は「修正サブシステム名」、「修正情報」及び「修正版名」は空欄となる。
【００２７】
進捗ＤＢ１２０は、開発部門等での試験・修正サイクルの進捗情報を蓄積するデータベースである。進捗ＤＢ１２０に蓄積されるレコードのデータ構造の一例を図３に示す。このデータ構造には、業務の「業務ＩＤ」、当該業務についての試験を行っている部門を示す「検出部門」（これは一般的には開発部門自体である）、この業務のために計画した試験項目の数を示す「計画項目数」、そのうち現時点までに実施した試験項目数を示す「実施実績数」、実施実績のうち現時点までに合格した試験項目数を示す「合格実績数」等の情報が含まれる。
【００２８】
試験対応表１３０は、試験項目の設計や、各サブシステムの複雑度の算出のために用いる表である。図４に試験対応表１３０の例を示す。図４の表において、各行はソフトウエアシステムを構成するサブシステムに対応している。この例では、ＩＤ１１０１〜１５０１までの２７個のサブシステムを含んだソフトウエアシステムを取り扱っている。この表は、大きく分けて、左半分の試験設計支援用の部分１３０ａと、右半分の複雑度算出用の部分１３０ｂとから構成される。
【００２９】
左半分の部分１３０ａは、各業務ごとに欄分けされている。個々の業務の欄は、その業務に占める各サブシステムのウェイトを設定する「ウェイト」欄と、そのウェイトに対応した試験項目数を示す「項目数」欄を含んでいる。ウェイトの値は、開発部門が各業務における各サブシステムの寄与割合を考慮して設定する。図示の例では、ウェイトは百分率で表されており、各業務ごとの「ウェイト」値の総和が１００．０となるように設定する。
【００３０】
前述したように、試験項目群の設計（作成）は、要求仕様で規定される業務ごとに行う。業務ごとに必要な試験項目数は、要求仕様から、ＦＰ法（ファンクション・ポイント法）などの公知の手法を用いて求めることができる。すなわち、ＦＰ法等で求められるその業務の機能の数に基づき、当該業務についての試験項目の総数を決める。業務が提供する機能の数から当該業務の試験項目の総数を決めることにより、それら提供機能群を網羅的に試験するという目的において妥当な数の試験項目数が分かる。ただし、この業務ごとの試験項目の総数に合わせた数の試験項目を作成するというだけでは、試験項目の内容に偏りが出て、試験の効果が悪くなるおそれがある。そこで、この実施の形態では、個々の業務ごとの試験項目の作成指針となる情報を求めている。これが、各業務ごとの各サブシステムの「項目数」の値である。
【００３１】
すなわち、この実施の形態のシステムは、ＦＰ法等で求められた個々の業務の試験項目総数を試験対応表（図４）の「項目数」の「合計」に入力することにより、その項目総数を各サブシステムの「ウェイト」欄の値に従って割り振っていく。この結果得られた値が当該業務における各サブシステムの試験「項目数」である。図４を参照すると、例えば「業務１」の試験項目の総数は１７５０と設定されており、この「業務１」において「１１０２サブシステム」が占めるウェイトは１０．０％と設定されている。したがって、システムは、「業務１」に関する「１１０２サブシステム」をターゲットとした試験項目数の目標値（すなわち、目標項目数）を１７５．０個（＝１７５０×０．１０）と決定し、これを「項目数」欄に設定する。この場合、試験項目作成者は、「業務１」の１７５０項目のうち、「１１０２サブシステム」を利用する試験項目を１７５個以上作成すればよいことが分かる。同様に、ウェイトが３．０％である「１１０７サブシステム」の「項目数」は５２．５個と決定される。このように、１つの業務全体の試験項目数の目標値を、各サブシステムのウェイトに従って割り振っていき、このような割り振り処理を各業務ごとに行う。
【００３２】
このように、この実施の形態では、各業務ごとの試験項目を作成する際に、試験項目の総数だけでなく、各サブシステムをターゲットとした試験項目が幾つ必要かを示す情報を求めて提示することができる。したがって、試験項目設計者は、試験項目作成のための有用な指針が得られ、従来よりも効果的な試験項目群を設計できる。
【００３３】
なお、サブシステムをターゲットにした試験項目を作成するとはいっても、実際にはその試験項目は様々なサブシステムの連携により実現されることが多いので、その試験項目は当該サブシステムのみについてのものではなく、当該「業務」全体についてのものとして取り扱う。要求仕様が実現されているかという観点が重要なので、試験項目の実施は業務単位で行われる。
【００３４】
「合計」欄Ａには、そのようにして求めた各サブシステムの目標項目数を全業務にわたって合計した値が設定される。
【００３５】
試験対応表１３０の右半分の部分１３０ｂは、各サブシステムの複雑度を求めるための部分である。複雑度は、サブシステム（プログラム）の作成の困難さを示す指標値である。この複雑度を求めるため、この試験対応表１３０では、各サブシステムごとに「試験対象規模ＫＬ」（Ｃ）、「試験密度」（Ｂ）、及び「自動生成等のＫＬ」（Ｄ）の値を入力する。「試験対象規模ＫＬ」は、当該サブシステムのソースコードのうち、人手により作成したコードのライン数であり、単位はＫＬ（キロライン＝千行）である。人手により作成したものなので、本来の試験の対象という意味で、試験対象規模ＫＬと呼ぶ。「試験密度」は、ソースコードのライン数に応じて定められる、必要な試験項目の密度であり、単位は「項目数／ＫＬ」である。「試験密度」は、企業ごと、あるいは事業所ごとに、経験的に定めた基準であり、各企業等の経験の蓄積が反映されたある程度信頼性の高い値である。「自動生成等のＫＬ」は、当該サブシステムのソースコードのうち、プログラム自動生成システムによる自動生成等により作成したソースコードのＫＬ数である。これら各欄の値は、各サブシステムのソースコードの最初の版が完成した段階で、この試験対応表１３０に登録される。
【００３６】
「試験対象規模ＫＬ」と「自動生成等のＫＬ」の和が、サブシステムの実装上のソースコードのＫＬ数である。この実装上のソースコードのＫＬ数に「試験密度」を乗じることにより、試験対応表１３０の「実装上の確認項目数」（Ｅ）の値が計算される。この「実装上の確認項目数」は、実装ソースコードを事業所基準の「試験密度」に従って試験するとしたときの試験項目数である。
【００３７】
各サブシステムの「複雑度」（Ｆ）は、次式に従って算出される。
【００３８】
［数式１］
Ｆ＝｛１＋ｌｏｇ（Ｃ）｝・Ａ／Ｅ
この算出式の右辺前半の｛１＋ｌｏｇ（Ｃ）｝（Ｃは「試験対象規模ＫＬ」、すなわち人手で作成したライン数）は、ソースコードのライン数が多くなればなるほど生産性が低くなる（特に１００〜１０００ＫＬの間で生産性が急激に低下する）という経験則を反映した因子であり、Ｃの値が大きくなるほどその値は大きくなる。
【００３９】
一方、右辺後半のＡ／Ｅ（Ａは目標試験項目数の「合計」。Ｅは「実装上の確認項目数」）は、同じ機能を実現するプログラムであれば短いコードの方が洗練されており、作成が困難であるという経験則を反映した因子である。試験項目数は、サブシステムが持つ機能の数を反映していると考えられる。「実装上の確認項目数」Ｅは、ソースコードのライン数から見て、サブシステムが事業所等の基準でどの程度の機能数に対応するかを表した数値と見ることができる。これに対し、ウェイトに従って求めた目標項目数の「合計」Ａは、そのサブシステムが実現していると考えられる機能数に対応した数値とみることができる。したがって、それらの比Ａ／Ｅは、（実現した機能）／（コードのライン数に見合った機能）と見ることができ、この値が大きいほど、少ないライン数で多くの機能を実現している洗練されたコードであるといえる。
【００４０】
したがって、それら２つの因子を乗算して得られた複雑度Ｆは、２つの基準を反映した値となっており、値が大きくなるほど作成の困難なサブシステム（プログラム）であると言える。この複雑度Ｆは、開発部門でのソフトウエアシステムの開発が完了した段階で求めることができる。そして、複雑度Ｆは、後に検査部門で抜き取り検査のサンプル絞込をする際に利用される。
【００４１】
次に、図５を参照して試験評価表１４０について説明する。この試験評価表１４０は、開発部門での試験・修正サイクルの進捗管理のために用いられる。この表１４０は、図５に示すように、「試験進捗評価」セクションと「品質評価」セクションとの２つに大きく分けられる。「試験進捗評価」セクションは、試験の進捗状態に関する諸項目を含んだ欄であり、試験の進捗度を示す「試験実施進捗」欄、障害の処置状況を示す「障害処置進捗」欄、及び現時点での障害発見数からみて最終的に発見されるであろう障害数を示す「完了時障害数予測」欄、から構成される。ソフトウエアシステムを構成する各サブシステムごとに、これら各欄の値が設定される。
【００４２】
「試験実施進捗」欄は、「実施実績」Ａ１、「合格実績」Ａ２、「合格計画」Ｂ、「最終見通し」Ｃ、「進捗率」、「消化率」、及び「障害」数Ｄの欄を含んでいる。「実施実績」Ａ１は、これまでに実施した試験項目の数を示す。「合格実績」Ａ２は、Ａ１のうち、合格した試験項目数を示す。「合格計画」Ｂは、予め定めたスケジュールからみて現時点で合格しているべき試験項目数を示す。「最終見通し」Ｃは、最終的に実施・合格すべき試験項目数を示し、これは試験対応表１３０の目標試験項目数の「合計」Ａに等しい。「進捗率」は、現時点の実際の合格試験項目数の計画値に対する割合であり、Ａ２／Ｂを百分率で示した値である。「消化率」は、現時点の実際の試験項目数の「最終見通」に対する割合であり、Ａ２／Ｃを百分率で示した値となっている。そして、「障害」は、現時点までに報告された障害の数を示している。
【００４３】
「障害処置進捗」欄は、「未処置」数、「処置」数Ｅ、「処置率」の欄を含んでいる。「処置」数は、報告された障害のうち、処置が完了したものの数を示す。「処置」の中にある「誤り」数Ｆは、「処置」した障害のうち、プログラムの「誤り」が原因であったものの数である。障害の中には、プログラムの「誤り」以外（例えば試験者が動作条件を間違ったために起こった障害など）のものもあるので、このような区別を設けている。プログラムに「誤り」があった場合、プログラム修正の処置がとられる。「未処置」数は、報告された障害のうち未処置のものの数である。そして、「処置率」は報告された障害のうち処置済みのものの割合を示す百分率である。
【００４４】
また、「品質評価」セクションは、「システム生産量」欄、「現状推定品質」欄、及び「完了時推定品質」欄から構成される。
【００４５】
「システム生産量」Ｇは、サブシステムのソースコードのうち、人手により作成したコードのライン数（単位ＫＬ）である。
【００４６】
「現状推定品質」欄は、現時点での各サブシステムの推定品質に関する欄であり、「誤り件数」Ｈ、「試験密度」及び「誤り率」の欄を含んでいる。「誤り件数」Ｈは、現時点で報告されている全障害を処置したときに見つかるであろう「誤り」の総数である（＝Ｄ・Ｆ／Ｅ）。「試験密度」は、現時点までに実施した試験項目のソースコード１ＫＬ当たりの数である。「誤り率」は、現時点の推定誤り総数をサブシステムのソースコードのＫＬ数で割ったものであり、１ＫＬ当たりの誤り数を示している。
【００４７】
「完了時推定品質」欄は、現状の傾向がそのまま続いたと仮定した場合の、試験完了時点（全試験項目が合格した時点）での各サブシステムの推定品質を示している。この欄も、「現状推定品質」欄と同様、「誤り件数」I、「試験密度」、及び「誤り率」の欄を含んでいる。「完了時推定品質」の「誤り件数」Ｉは、現状での誤りの発見率（Ｆ／Ｅ）に、「完了時障害数予測」値を乗じたものである。「試験密度」は、最終的な試験項目数をサブシステムのＫＬ数で割ったものである。そして、「誤り率」は、試験完了時の推定「誤り件数」Ｉを、サブシステムのＫＬ数で割ったものである。
【００４８】
更に試験評価表１４０には、各サブシステムごとに、そのサブシステムの開発を担当している製作担当チームのコードが登録される。
【００４９】
この試験評価表１４０は、障害ＤＢ１１０や進捗ＤＢ１２０に登録された情報に基づき随時作成、更新される。例えば、「障害」数Ｄや「処置」数Ｅ、「誤り」数Ｆなどは、障害ＤＢ１１０に登録された障害報告のレコードを集計して求められる。また、「実施実績」Ａ１や「合格実績」Ａ２などは、進捗ＤＢ１２０の該当項目から求められる。また、「最終見通し（目標試験項目数）」Ｃや「システム生産量」Ｇには、試験対応表１３０の「合計（項目数合計）」Ａや「試験対象規模ＫＬ」Ｃの情報が登録される。「合格計画」Ｂは、別途定められている試験スケジュールから求めて登録される。
【００５０】
なお、障害報告や試験進捗のレコードは「業務」ごとに分類されているが、この試験評価表１４０には、１つのソフトウエアシステムが実現する全業務の障害数や合格実績などの現時点での集計結果（及びそれに基づく推定結果）が表示される。
【００５１】
ここで、試験項目は業務単位で実行されるので、進捗ＤＢ１２０には試験項目の実施実績数や合格実績数などの試験結果が業務単位でしか登録されない。この実施の形態では、業務単位で登録された実施実績数や合格実績数を、試験対応表１３０に設定されたウェイトを用いて割り振ることにより、各サブシステムごとの実施実績数と合格実績数を割り出している。これを全業務にわたって累計した結果が、試験評価表１４０（図５）の各サブシステムの「実施実績」及び「合格実績」の値となる。このように、業務単位での試験結果をウェイトを用いて各サブシステムに割り振り、それを集計して表示することにより、試験担当者は、抽象的な「業務」単位の試験進捗だけでなく、物理的な実体としての「サブシステム」（プログラム）単位での試験進捗を把握することができる。
【００５２】
開発部門での試験・修正サイクルで最終的にすべての試験項目について合格したと判断されると、試験評価表１４０の「現状推定品質」欄と「完了時推定品質」欄の各項目の値が同じになり、これが開発部門での最終的な試験結果の１要素となる。
【００５３】
以上、データベース部１００で管理される各データの内容について説明した。ここで再び図１に戻り、この実施の形態のシステム構成を説明する。
【００５４】
開発部門システム２００は、開発部門がソフトウエアシステムの試験・修正のサイクルを進めていく際に用いるシステムであり、入力処理部２１０、表示処理部２３０及び演算処理部２５０を含んでいる。
【００５５】
入力処理部２１０は、データベース部１００に各種情報を入力するための機構であり、ウェイト設定部２１２、試験項目数設定部２１４、プログラム規模入力部２１６、製作者登録部２１８、障害報告入力部２２０及び試験結果入力部２２２を含む。ウェイト設定部２１２は、試験対応表１３０（図４）に対し、各業務に占める各サブシステムのウェイトを設定するための入力機構である。開発部門の担当者は、各業務の内容と各サブシステムの機能とを考慮して各々のウェイト値を定め、入力する。試験項目数設定部２１４は、試験対応表１３０の各業務の欄の「項目数」の合計値の欄に、値を設定するための入力機構である。ここには、ＦＰ法などの公知の手法を用いて求めた当該業務のための試験項目の総数が設定される。プログラム規模入力部２１６は、試験対応表１３０（図４）の「試験対象規模ＫＬ」や「自動生成等のＫＬ」など、作成された各サブシステムのプログラム規模の値を入力するための機構である。製作者登録部２１８は、試験評価表１４０（図５）における各サブシステムの製作担当チームを入力するための機構である。障害報告入力部２２０は、障害ＤＢ１１０に対するデータの入力機構である。試験・修正サイクルにおいて障害が検出されたり、その障害に対して処置を行った場合、試験担当者や障害対策担当者は、この障害報告入力部２２０を用いてその障害や処置の内容を障害ＤＢ１１０に入力する。試験結果入力部２２２は、進捗ＤＢ１２０に対するデータの入力機構である。試験担当者は、試験項目の実施の結果（例えば実施した項目数やそのうち合格した項目数など）を、定期的にあるいは随時、この試験結果入力部２２２から入力する。
【００５６】
演算処理部２５０は、データベース部１００のデータに対して各種の演算処理を行って、試験進捗やソフトウエア品質に関する各種情報を求め、それをまとめるための機構である。演算処理部２５０は、目標項目数算出部２５２、試験進捗管理部２５４、誤り数集計部２５６、誤り率算出部２５８及び複雑度算出部２６０を含む。目標項目数算出部２５２は、試験対応表１３０に、各業務ごとの総試験項目数と、その業務における各サブシステムのウェイトとが設定されると、それらに基づき各業務における各サブシステムの目標項目数を算出し、その値を試験対応表１３０の「項目数」欄に設定する。試験進捗管理部２５４は、ユーザからの指示に応じ、進捗ＤＢ１２０及び障害ＤＢ１１０の現時点までの蓄積情報を集計し、試験評価表１４０を作成又は更新する。誤り数集計部２５６は、障害ＤＢ１１０のレコード群から「誤り」の数を、ソフトウエアシステム全体、及び各サブシステムごとに集計する。誤り率算出部２５８は、集計した「誤り」数に基づき「誤り率」を算出する。すなわち、誤り率算出部２５８は、試験評価表１４０（図５）における「現状推定品質」欄や「完了時推定品質」欄の各項目の算出処理を行う。
【００５７】
表示処理部２３０は、目標項目数表示手段である試験対応表表示部２３２と、試験進捗表示手段である試験評価表表示部２３４と、を含む。前者は試験対応表１３０を表示し、後者は試験評価表１４０を表示する。試験対応表１３０の表示により、開発部門の試験担当者は、各サブシステムにそれぞれどの程度の重みを置いて試験項目群を作成したらよいかが分かり、より効果的な試験項目の設計の助けとなる。また、試験評価表１４０の表示により、試験担当者や管理者は各サブシステムごとの試験の進捗状況を把握することができ、従来よりもきめ細かい試験進捗の管理が可能となる。
【００５８】
次に、検査部門システム３００について説明する。検査部門システム３００において、製作者能力分析部３１０は、試験対応表１３０と試験評価表１４０の情報に基づいて、開発部門の各製作担当チームの能力分析を行う。能力分析は、各製作担当チームが作成したサブシステムの複雑度と誤り率の相関に基づき行う。すなわち、試験評価表１４０における各サブシステムの「誤り率」と「製作担当チーム」の情報と、試験対応表１３０における各サブシステムの「複雑度」との情報を組み合わせ、それらの相関関係を求める。能力分析は開発部門での試験の完了後に行うので、ここで用いる「誤り率」は、試験評価表１４０の「現状推定品質」欄又は「完了時推定品質」欄のどちらの「誤り率」を用いてもよい（既にすべての試験項目について合格となっているはずなので、推定値ではなく確定値となっている）。図６は、各サブシステムの製作担当チーム、誤り率及び複雑度をまとめた表である。製作者能力分析部３１０は、この表を作成し、更に図７に示すような各製作担当チームごとの誤り率と複雑度の相関関係を表す製作者能力表３１２を生成する。この製作者能力表３１２は、サブシステムの誤り率及び複雑度をそれぞれ複数段階に分け、各サブシステムの（誤り率，複雑度）の組合せに対応する位置に、そのサブシステムの製作担当チームを表したものである。例えば、図６によれば、１１０１サブシステムは、誤り率が０．７１で複雑度が２．２３、製作担当チームがＡなので、図７の製作者能力表では、誤り率０（すなわち０〜１）、複雑度２（すなわち２〜３）の欄に製作担当チームＡが表されている。
【００５９】
作成された製作者能力表３１２は、能力表表示部３１４に表示される。この製作者能力表３１２の表示は、抜き取り検査のサンプル絞込のために有用な情報となる。例えば、図７の例では、Ａチームは、複雑度が２までは誤り率がゼロ台であり、複雑度３に上がっても誤り率が２以下であることが分かる。したがって、ここから、Ａチームの作ったサブシステムは、複雑度２以下については抜き取り検査の必要がなく、複雑度３のサブシステムからいくつかサンプルを抜き出して検査するなどの方針が立てられる。また、Ｃチームは、複雑度が２になると誤り率が急増しており、これから複雑度２以上のサブシステムはすべて検査した方がよいなどの方針が得られる。また、Ｄチームは製作したサブシステムが１つしかないので、誤り率ゼロ台という今回の結果の信憑性はそれほど高いものとは言えない。したがって、この場合はそのサブシステムを検査する必要があるなどと判断できる。また、Ｂチームは、複雑度３という複雑なサブシステムで誤り率がゼロ台であるにもかかわらず、複雑度１で誤り率が１台のケースがあり、複雑度によらず誤り率がばらついている。このため、Ｂチームについては、チーム内部の個別担当者レベルなどでの原因究明が必要などとの判断ができる。ばらつきの原因が究明できれば、Ｂチームの各サブシステムの試験結果をその原因レベル（例えば個別担当者が誰かなど）で更に細かく分析し、その原因レベルの分類ごとに抜き取り検査の絞込を行えばよい。
【００６０】
以上、この実施の形態のソフトウエア品質検査支援システムの構成について説明した。次に、このシステムを用いた品質検査の作業手順を説明する。この手順は、大きく分けて開発部門での試験・修正サイクルのフェーズと、その開発部門での試験結果を検査部門で検証するフェーズとに分けられる。
【００６１】
図８は、主として開発部門のフェーズの作業手順を示している。まず最初に、対象となるソフトウエアシステム用に障害ＤＢ１１０及び進捗ＤＢ１２０を準備する（Ｓ１０）。この障害ＤＢ１１０、進捗ＤＢ１２０は、検査部門が定めた所定形式に準拠したものとする。次に、試験対応表１３０を設計する（Ｓ１１）。このＳ１１の手順を図９を用いて更に詳しく説明する。
【００６２】
Ｓ１１では、まず開発部門の試験担当者は、要求仕様書などから当該ソフトウエアの実現すべき「業務」群を求めて試験対応表１３０（図４参照）に設定する（Ｓ１１０）。更に、各「業務」ごとの総試験項目数をＦＰ法等により求め、これを試験対応表１３０の各業務の「項目数」の「合計」欄に設定する（Ｓ１１０）。また、ソフトウエアシステムを構成する各サブシステムを、試験対応表１３０の各行に設定していく（Ｓ１１２）。そして、試験対応表１３０の各業務ごとに、各サブシステムの占めるウェイトを設定する（Ｓ１１４）。ウェイトの設定が完了すると、目標項目数算出部２５２が、各業務における各サブシステムに関する試験項目の目標数を算出する（Ｓ１１６）。そして、この算出された目標項目数が、試験対応表１３０に登録される（Ｓ１１８）。
【００６３】
このようにして試験対応表１３０ができると、次に試験担当者は、この試験対応表を参照しつつ、各業務についての試験項目群を作成する（Ｓ１２）。このとき、試験対応表における各業務の各サブシステムの目標項目数の情報が、試験項目作成の指針となる。
【００６４】
次に、試験評価表１４０（図５）を作成する（Ｓ１３）。この最初の段階では、試験評価表はほとんど空欄である。
【００６５】
このようにして障害ＤＢ１１０、進捗ＤＢ１２０、試験対応表１３０及び試験評価表１４０の準備が終わると、作成した試験項目を順次実施していき、その結果を各ＤＢに登録していく（Ｓ１４）。この試験において障害が検出されると、それが報告され、修正等の処置がなされる。このような試験・修正のサイクルを、全試験項目について合格の結果が得られるまで繰り返す（Ｓ１５）。全項目について合格となると、開発部門では所定品質のソフトウエアシステムが完成したとして、検査部門にその検証を求める。
【００６６】
検査部門の作業手順は図１０に示される。検査部門は、開発部門から検証を求められると、まずデータベース部１００から試験結果の試験対応表１３０及び試験評価表１４０を取得する（Ｓ２０）。製作者能力分析部３１０が、その試験結果から、各サブシステムの製作担当チーム、誤り率、複雑度の情報を抽出し（Ｓ２２）、製作者能力表３１２を作成する（Ｓ２４）。作成された製作者能力表３１２は、能力表表示部３１４により表示される（Ｓ２６）。検査部門の担当者は、この製作者能力表３１２を見て、抜き取り検査を行うサブシステムを絞り込む（Ｓ２８）。そして、絞り込んだサブシステムを抜き取り、そのソースコードの検査などを行う（Ｓ３０）。
【００６７】
以上、この実施の形態のシステム構成及び処理手順について説明した。以上説明したように、この実施の形態によれば、まずウェイト設定により試験項目の作成指針となる各サブシステムごとの目標試験項目数が得られるので、効果的な試験項目群の設計の助けとなる。また、業務ごとに実施される試験項目の結果を、そのウェイトに従って各サブシステムに分配し、各サブシステムごとの試験進捗状況を提示できるので、物理的な実体としての「サブシステム」（プログラム）単位での試験進捗を把握することができ、試験進捗の管理をよりきめ細かく行うことが可能になる。また、この実施の形態では、各サブシステムの複雑度と誤り率とに基づき製作者能力表を作成して表示することができ、この表示は、抜き取り検査のサンプル絞込において有用な指針となる。
【００６８】
なお、この実施の形態では、図７のような製作者能力表３１２により製作担当チームの能力傾向を表現したが、このような表の代わりに、誤り率、複雑度をそれぞれ軸とするグラフの形で表現してもよい。
【００６９】
また、製作者能力表は、抜き取り検査のサンプル絞込だけでなく、様々な用途に応用可能である。例えば、この表から能力が高いチーム（複雑度が高くても誤り率が低いチーム）、能力が低いチームを求め、次のソフトウエアの開発の際に、能力が高いチームほど難しいプログラムの作成に従事させるなど、開発体制づくりに役立てることができる。また、プログラム作成教育などにおいて、カリキュラムを進めていく際、作成したプログラムに対して試験を行わせ、その結果に基づきこのような能力表を作成することにより、達成度をチェックすることができる。
【００７０】
実施の形態２．
次に、この発明の実施の形態２について説明する。図１１は、実施の形態２に係るソフトウエア品質検査支援システムの構成を示す機能ブロック図である。図１１において、図１に示した構成と同様の構成要素については同一符号を付してその説明を省略する。
【００７１】
図１１のシステムは、図１に示した実施の形態１のシステムに対して、検査部門システム３００の機能を拡張したものである。すなわち、この実施の形態では、検査部門システム３００に、ガイダンス処理部３２０と抜き取り基準記憶部３２２とが新たに設けられている。
【００７２】
ガイダンス処理部３２０は、製作者能力分析部３１０で得られた分析結果（例えば製作者能力表３１２の情報）に基づき、抜き取り検査のサンプル絞込の指針を提示する手段である。実施の形態１では、担当者が製作者能力表３１２の表示を読み取って抜き取り検査の方針を決めていたが、この実施の形態では、「Ｃチームは複雑度２以上のサブシステムを全件検査した方がよいと判断されます」などと、具体的な抜き取り対象絞込の指針を提示する。
【００７３】
どのような指針を提示するかの基準となる情報は、抜き取り基準記憶部３２２に記憶されている。この抜き取り基準記憶部３２２には、例えば「誤り率がゼロ台しかない複雑度については、抜き取りを行わない」、「誤り率が３を超える複雑度については全件抜き取りを行う」、などのルールが登録されている。ガイダンス処理部３２０は、製作者能力の分析結果に対し、このルールを適用することにより、各製作担当チームごとにどの複雑度のサブシステムをどの程度抜き取って検査したらよいか、等の指針を表示する。
【００７４】
この実施の形態２によれば、より具体的な抜き取り検査の指針が得られるので、担当者の負担を軽減することができる。とくにソフトウエアシステムが大規模になるほど、このような具体的な指針の提示は大きな助けとなる。
【００７５】
実施の形態３．
次に、この発明の実施の形態３について説明する。図１２は、実施の形態３に係るソフトウエア品質検査支援システムの構成を示す機能ブロック図である。図１２において、図１に示した構成と同様の構成要素については同一符号を付してその説明を省略する。
【００７６】
図１２のシステムは、図１に示した実施の形態１のシステムに対して、検査部門システム３００の機能を拡張したものである。この実施の形態では、検査部門システム３００に、重複誤り集計部３３０と試験性能評価部３３２とが新たに設けられている。
【００７７】
この実施の形態３では、開発部門の試験結果から、各製作担当チームの能力だけでなく、試験に用いた試験項目群の適切さ（試験性能と呼ぶ）を分析し、その試験結果の妥当性を検証する。
【００７８】
試験性能は、重複誤りによって判定する。複数の障害報告の原因が、ソフトウエアシステムの同じ部分の誤りであった場合、その誤りを重複誤りという。重複誤りは、障害ＤＢ１１０の障害報告（図２参照）の「重複」フラグから割り出すことができる。重複誤りは、別々の試験項目で同じ誤りに起因する障害が検出されたことを意味する。これは、本来なら１つの試験項目で十分検出できている誤りに対し、複数の試験項目が作成されていたことを意味する。試験項目は、ＦＰ法などにより予め総数を決めているので、このような重複的な試験項目が存在すれば、他の部分についての試験項目の密度がその分薄くなっていることになる。したがって、重複誤りの比率が高いほど、開発部門で作成した試験項目群の性能が悪く、ひいては開発部門での試験結果（試験対応表や試験評価表など）の信頼性が低いことを意味する。そこで、この実施の形態では、重複誤りの程度に基づき試験性能を判断し、開発部門での試験結果の信頼性を判断する。
【００７９】
重複誤り集計部３３０は、障害ＤＢ１１０のレコードから、重複誤りの数を集計する。この集計は、サブシステム単位で行う。すなわち、障害ＤＢ１１０のレコード（図２参照）で、「重複」フラグが重複誤りを示す値にセットされているものを見つけ、それらのうち「修正サブシステム名」を同じくするものの数を各サブシステムごとに集計する。
【００８０】
試験性能評価部３３２は、その集計結果をもとに、各サブシステムごとの重複誤り率を算出する。図１３は、この重複誤り率の算出の方法を説明するための図である。各サブシステムの重複誤り率は、当該サブシステムの重複誤り数の、当該サブシステムの試験項目数（すなわちウェイトから求めた目標項目数）に対する百分率として求める。このようにして求めた重複誤り率は、当該サブシステムをターゲットとして作成した試験項目のうち、どの程度が重複して無駄となっているかを示している。
【００８１】
検査部門の担当者は、この重複誤り率の分布を見て、試験性能を判断する。例えば、すべてのサブシステムの重複誤り率が３以下であれば、開発部門での試験が信頼性の高い網羅的なものであったなど判断できる。このように、開発部門での試験が妥当だと判断した場合は、検査部門は、その試験結果に基づいて前述した抜き取り検査の処理を行う。これに対し、開発部門での試験性能が低いと判断した場合は、検査部門は、開発部門に対して試験のやり直しなどを指示するなどの処置をする。この場合、例えば、重複誤り率が許容限度以上に高いサブシステムを指摘し、そのサブシステムをターゲットとした試験項目を追加作成するなどの指示を行うことができる。そして、検査部門は、この再試験の結果を開発部門から受け取り、再度その結果から試験性能を判断し、十分な試験性能だと判断すれば抜き取り検査に進む。
【００８２】
このように、この実施の形態によれば、重複誤りの集計結果をもとに、網羅的な信頼性の高い試験がなされたかを判断することができるので、信頼性の低い試験結果をベースに抜き取り検査を行うなどの無駄をなくすことができる。
【００８３】
実施の形態４．
以上の実施の形態では、検査部門は、図１４に示すように開発部門での試験実施（Ｓ３００）の結果を受けて検査を実施し（Ｓ３１０）、その合否を判定している（Ｓ３２０）。この手順では、開発部門自身が試験段階での合否判定を行っており、検査部門は、開発部門による合格の旨の自己判定をそのまま受け入れて抜き取り、抜き取り検査などの検査処理を開始している。
【００８４】
ところが、仮にこの検査部門の自己判定に誤りがあるなどして実際には合格水準に達していない項目があった場合、検査部門の検査でも不合格になる可能性が高い。検査部門による検査には一般に数日から十数日程度の期間が必要なので、このようなケースでは時間のロスになる可能性が高い。
【００８５】
そこで、この実施の形態では、そのようなロスを未然に防ぐために、図１５に示すように、検査部門において、検査実施（Ｓ３１０）の前に、受入判定（Ｓ３３０）のステップを設けた。この受入判定では、開発部門からの検証依頼に応じ、開発部門での試験結果を調べ、試験結果レベルで所定の品質を満足しているかどうか判断する。
【００８６】
図１６は、この実施形態のシステム構成例を示す図である。この構成例は、実施の形態１のシステムをベースにしたものであり、検査部門システム３００に受入判定部３４０を設けた以外は、実施の形態１と同様のシステムである。
【００８７】
受入判定部３４０は、開発部門側からのソフトウエア検査依頼を受け入れるかどうかの判定処理の支援を行う。この受入判定支援処理では、担当者が受入判定対象の検査依頼を指定して受入判定部３４０を起動すると、受入判定部３４０は、その依頼に係るソフトウエアの試験評価表１４０の情報をデータベース部１００から取得し、その評価表１４０に示される試験結果が所定の基準を満足しているかを判定する。この基準は、例えば最終的な誤り率（残存誤り率）が予め定めたしきい値以下になっているなどのルールである。もちろん、誤り率以外の試験結果の特徴値について受入判定基準を設けることも可能である。この判定基準は、ソフトウエア全体についての特徴値について定めることもできるし、サブシステム単位の基準として定めることもできる。サブシステム単位の場合、個別のサブシステムごとに別々のしきい値を定めることも可能である。このような受入判定基準は、検査部門での抜き取り検査に移行するための移行基準ともいえる。このような受入判定基準は、予め策定され、検査部門システム３００に登録されている。受入判定部３４０は、試験結果の各特徴値がその判定基準を満足しているかどうかを調べる。
【００８８】
なお、この受入判定の際に、開発部門から検査部門への提出書類が揃っているか否かや、その書類に記載されている内容に不備がないかなどを調べ、このような点についての不備がないことを確認してから検査にはいるようにすれば、さらに検査の無駄を防止できる。ただし、このような書類等の項目は、一般にコンピュータによる自動判定が困難であり、人手により行うが、この人手による処理を受入判定部３４０により支援するようにすることも好適である。例えば、人手による判定項目やその手順などをユーザに対して表示し、ユーザがこれを参照しながら作業を進めるようにするなどである。なお、開発部門から検査部門への提出書類を定型化、電子化すれば、このようなチェック作業のかなりの部分を自動化することも可能である。
【００８９】
さて、受入判定部３４０では、このような自動的及び人手による個々の判定項目の判定結果を総合して、全体としての受入判定を行う。すべての項目が合格である場合は、制作者能力分析部３１０等による検査処理（Ｓ３１０）に移行する許可を出す。
【００９０】
一方、不合格の項目があれば、受入判定部３４０は、検査依頼が受け入れられないと判定し、その判定結果を検査部門の担当者に表示したり、あるいは依頼側の開発部門に対して通知したりする。なお、この場合、受入判定部３４０は、例えばどのサブシステムのどの特徴値が不合格であったかなど、不合格の項目についての説明を記載したレポートを自動作成し、それを不合格の旨の通知に対応づけて、開発部門側に通知する。このレポートに、不合格項目についての達成課題（例えば誤り率などの目標値や、その目標値と現状との差など）を含めれば、開発部門側での修正作業の参考とすることができる。
【００９１】
このように、この実施の形態４によれば、開発部門での試験の結果が予め定めた基準を満足しているかの判定を支援するツール（受入判定部３４０）を検査部門システム３００に設けたので、開発部門側での不備などによる無駄な検査の実行を低減することができる。
【００９２】
なお、ここでは実施の形態１をベースに受入判定部３４０を付加した例を説明したが、当業者には明らかなように、実施の形態２や３の検査部門システム３００に同様の受入判定部３４０を設けることも可能である。
【００９３】
また、以上の実施の形態１〜４では、開発部門に開発部門システム２００を設けたが、この開発部門システム２００と同等の機能を、ＷＷＷ（ワールド・ワイド・ウェブ）のウェブサービスとして提供することも可能である。図１７は、このようなウェブベースでの試験支援のシステム例を示す図である。この例では、実施の形態１等で開発部門システム２００に実装されていた入力処理部２１０，表示処理部２３０，演算処理部２５０が、ＷＷＷサーバ４００内のアプリケーションとして実装されている。これらは、例えばＣＧＩ（Common Gateway Interface）アプリケーションとして実装される。
【００９４】
各開発部門は、ウェブブラウザ（開発部門ブラウザ６００）を用い、インターネット５００を介してこのＷＷＷサーバ４００にアクセスする。すると、ＷＷＷサーバ４００は、ユーザ認証用のウェブページを開発部門ブラウザ６００に送り、ユーザＩＤやパスワードなどの認証情報の入力を求める。これに対して開発部門ブラウザ６００から認証情報が送信されてくると、ＣＧＩなどで実現されるユーザ認証部２７０がその認証情報を基にユーザ認証を行う。このため、開発部門は予めＷＷＷサーバ４００にユーザ登録を行っておく。ユーザ認証で正当なユーザと判断された場合、ＷＷＷサーバ４００は、サブシステムの数やウェイト、試験項目数など試験設計のための入力項目を入力するためのウェブページや、当該ユーザの既に作成されている試験対応表や試験評価表の内容を表示するウェブページや、それらの表にデータを入力するためのウェブページなどを、要求に応じてそのユーザに提供する。このとき、表示処理部２３０は、データベース部１００に登録された当該ユーザ（開発部門）の登録情報から、そのユーザの試験対応表や試験評価表などを表示したウェブページを作成する。また入力処理部２１０は、入力用ウェブページにて入力されたデータを、データベース部１００の当該ユーザの登録情報に反映させる。演算処理部２５０は、入力データに応じ、前述のようにして試験評価表その他の各種項目の値を計算し、データベース部１００の登録データに反映させる。なお、演算処理部２５０は、ＷＷＷサーバ４００に実装する代わりに、データベース部１００に実装することも好適である。
【００９５】
このようなＷＷＷサーバ４００をベースとした仕組みを設けることにより、開発部門は、実施の形態１などの場合のように大規模な開発部門システム２００を持たなくても、ＷＷＷのブラウザを持つだけで、上記各実施の形態と同等の支援処理を受けることができる。したがって、検査部門と開発部門が別会社の場合などにも、容易に本発明に係るシステムを展開することができる。
【００９６】
また、このようなＷＷＷベースの仕組みにおいて、検査部門システム３００からＷＷＷサーバ４００にアクセスし、各開発部門の試験対応表や試験評価表を閲覧できるようにすることも好適である。これには、検査部門に対し閲覧のみを許す権限を付与し、ＷＷＷサーバ４００のユーザ認証により検査部門からのアクセスと判断された場合には、各開発部門の試験評価表等の表示のみを許すようにすればよい。このようにすることにより、検査部門は、各開発部門の試験進捗状況（これは開発の進捗状況ととらえることもできる）を随時確認することができ、開発部門からの検査依頼の到来に備えたり、あるいは検査依頼の来る前に、試験評価表などから読みとれる事項などについて開発部門にアドバイスをしたりするなどの対処をとることが可能になる。
【００９７】
【発明の効果】
この発明は、以上説明したように構成されているので、以下に示すような効果を奏する。
【００９８】
この発明によれば、業務単位の試験項目数だけでなく、サブシステム単位の試験項目数が目安として提示できるので、ユーザはこの情報を参照することにより効果的な試験項目群を作成できる。
【００９９】
また、この発明によれば、業務ごとの試験結果を受け付け、それをサブシステム単位にブレークダウンして提示できるので、ユーザは、試験の進捗状況を、物理的な実体であるサブシステムの単位で把握することができ、きめ細かな試験進捗の管理が可能になる。
【０１００】
また、この発明によれば、試験結果に基づき各サブシステムを製作した各製作者の能力情報を求め、それを表示することができるので、ユーザはその表示により、各製作者の作成したサブシステムをどの程度検査（例えば抜き取り検査）すればよいかなどを判断できる。
【０１０１】
また、この発明によれば、各サブシステムの製作者を、当該サブシステムの複雑度と誤り率の組合せで規定される位置にプロットした製作者能力表を表示することにより、ユーザは、製作者の能力を視覚的に容易に把握することができる。
【０１０２】
また、この発明によれば、誤り数を集計する手段と、プログラム規模を入力する手段を設けたので、集計した誤り数とプログラム規模とに基づき誤り率を算出することができる。
【０１０３】
また、この発明によれば、製作者能力の分析結果に基づき、抜き取り検査の対象の絞込のための指針を提示するガイダンス処理手段を設けたので、ユーザは抜き取り対象の絞込をより容易に行うことができる。
【０１０４】
また、この発明によれば、重複誤りを集計し、その結果に基づき、試験項目の性能評価を行うことができるので、その評価結果をもとに、試験結果自体の信頼性を判断することができる。
【０１０５】
また、この発明によれば、試験結果が抜き取り検査への移行基準を満足するかどうかを判定し、その判定結果を出力することで、移行基準を満足しないうちに抜き取り検査に移ることを抑制し、無駄な検査を低減することができる。
【０１０６】
また、この発明によれば、移行基準を満足しないサブシステムを示したレポートを作成することで、どのサブシステムについて修正を行えばよいかなどの目安を提供することができる。
【図面の簡単な説明】
【図１】 実施の形態のソフトウエア品質検査支援システムの全体構成を示す機能ブロック図である。
【図２】 障害ＤＢのレコードのデータ構造の一例を示す図である。
【図３】 進捗ＤＢのレコードのデータ構造の一例を示す図である。
【図４】 試験対応表の一例を示す図である。
【図５】 試験評価表の一例を示す図である。
【図６】 各サブシステムの製作担当チーム、誤り率、及び複雑度を抽出した表を示す図である。
【図７】 製作担当チーム、誤り率及び複雑度の相関関係を表す製作者能力表を示す図である。
【図８】 開発部門での作業手順を示すフローチャートである。
【図９】 試験対応表の設計作業の詳細手順を示すフローチャートである。
【図１０】 検査部門の作業手順を示すフローチャートである。
【図１１】 実施の形態２のシステム構成を示す機能ブロック図である。
【図１２】 実施の形態３のシステム構成を示す機能ブロック図である。
【図１３】 重複誤り率の算出の方法を説明するための図である。
【図１４】 実施の形態１などでの開発部門から検査部門への移行の流れを示した図である。
【図１５】 実施の形態４での開発部門から検査部門への移行の流れを示した図である。
【図１６】 実施の形態４のシステム構成を示す機能ブロック図である。
【図１７】 各実施の形態のシステムにおけるサービスをＷＷＷサーバにて提供する形態を説明する図である。
【符号の説明】
１００ データベース部、１１０ 障害ＤＢ、１２０ 進捗ＤＢ、１３０ 試験対応表、１４０ 試験評価表、２００ 開発部門システム、２１０ 入力処理部、２１２ ウェイト設定部、２３０ 表示処理部、２５０ 演算処理部、３００ 検査部門システム、３１０ 製作者能力分析部、３１２ 製作者能力表、３１４ 能力表表示部。
【発明の属する技術分野】
この発明は、ソフトウエアの品質検査の支援のためのシステムに関し、効果的な試験項目の作成や抜き取り検査のサンプルの絞込の支援のための技術に関する。
【０００２】
【従来の技術】
ソフトウエア開発の現場では、誤りができるだけ少ない高品質の商品（ソフトウエアシステム）を提供するため、いったん作成したソフトウエアに対して試験を行って所期の性能が達成されているか確認し、達成されない場合はその原因（誤り、バグ）を突き止め、コードの修正などの処置を行っている。そして、この試験、修正の作業を繰り返すことにより、ソフトウエアに含まれる誤りを低減している。
【０００３】
ソフトウエアの試験のためには、まず、要求性能（仕様）の各項目が実現されていることを確かめるための試験項目を必要なだけ設定する。そして、作成したソフトウエアシステムにてこれら各試験項目の内容を実施し、その試験項目の内容が正しく実行できたかどうかを調べる。正しく実行できなかった試験項目があれば、そのとき症状が障害として報告され、この報告に基づき処置が行われる。従来、ソフトウエア試験のための試験項目は、ソフトウエア開発部門等の担当者が、そのソフトウエアの要求仕様から、自己の経験に基づいて作成するのが一般的であった。また、試験自体もそのソフトウエアの開発部門が行うことが一般的であった。
【０００４】
また、近年ソフトウエアについてもＩＳＯ９０００シリーズなどに準拠した高度な品質保証モデルの導入の必要性が叫ばれている。高度な品質保証を実現するには、従来開発部門が自前で行っていたソフトウエア品質管理だけでなく、第三者的な立場からソフトウエアの品質をチェックしたり、開発部門の品質管理自体の質をチェックしたりする検査部門の設立が求められる。
【０００５】
検査の統一性や経済性等の観点から、検査部門は１企業（あるいは１事業所など）に１つ設けられるのが一般的であり、１つの検査部門が企業内にある数多くの開発部門の開発したソフトウエアシステムを検査することになる。このため、検査部門の検査効率の向上は、企業のソフトウエア開発全体のサイクルを左右する重要なファクタとなる。
【０００６】
【発明が解決しようとする課題】
ソフトウエアの試験・修正作業では、効果的な試験項目を選ばないと、ソフトウエアシステムに内在する誤りを効率よく見つけ出すことができない。これは、試験・修正作業の効率のみならず、最終的なソフトウエア商品の品質にも大きな影響をもたらす。従来、この試験項目の設計が完全に開発者（あるいは開発部門）の経験や勘に任されていたため、開発者（すなわち試験項目の設計者）の能力に応じて試験の有効性に大きなばらつきが出る場合があった。試験項目群がソフトウエアシステムに要求される機能を網羅的にカバーしているか、そうでないかにより、同じ項目数の試験を実施しても、試験の効果が変わってくる。
【０００７】
また、開発部門に対して第三者的な検査部門を設けた場合、検査部門は一般に開発部門での試験・修正の結果報告を受けて、その結果の妥当性を判断し、必要に応じて機能レベル、ソースコードレベルの抜き取り検査を行う。しかしながら、このような抜き取り検査も、闇雲にサンプル抜き取りを行っていたのでは効率的ではない。従来、抜き取り検査のサンプル絞込みは、個々の検査者の技量によっており、検査の作業効率や効果の面でばらつきが出る可能性があった。
【０００８】
この発明は、上述のような課題を解決するためになされたもので、まず第１にソフトウエアシステムの試験のための効果的な試験項目の設計を支援するシステムを提供することを目的とする。更にこの発明は、抜き取り検査時のサンプルの絞込みを支援するためのシステムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
この発明に係るソフトウエア品質検査支援システムは、１以上の業務を複数のサブシステムの組合せにより実行するソフトウエアシステムについて、そのソフトウエアシステムの品質検査を支援するためのソフトウエア品質検査支援システムであって、該ソフトウエアシステムが実行する各業務ごとに、前記各サブシステムのその業務に関するウェイトを記憶すると共に、前記各業務ごとに、その業務に関する前記ソフトウエアシステムの機能検証のために試験すべき試験項目の数を記憶する記憶手段と、前記各業務ごとに、前記記憶手段に記憶された当該業務の試験項目数と、前記記憶手段に記憶された当該業務に関する前記各サブシステムのウェイトと、に基づき、各業務ごとの各サブシステムの目標試験項目数を算出する目標項目数算出手段と、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を表示する目標項目表示手段と、を備えるものである。
【００１０】
また、この発明に係るソフトウエア品質検査支援システムは、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を、各サブシステムごとにそれら各業務にわたって合計することにより、各サブシステムごとの合計目標試験項目数を計算する合計目標試験項目数計算手段と、前記各業務ごとに、その業務について実施した試験項目の数の入力を受け付ける試験結果入力手段と、前記試験結果入力手段で受け付けた各業務ごとの、前記実施した試験項目の数に、当該業務についての各サブシステムのウェイトを乗ずることにより、それら各サブシステムごとの、実施した試験項目の数を表す試験実施進捗情報を求める試験進捗管理手段と、前記試験進捗管理手段で求めた前記各サブシステムごとの試験実施進捗情報と、前記合計目標試験項目数計算手段で求めた前記各サブシステムごとの合計目標試験項目数とを対比可能に表示する試験進捗表示手段と、を備えるものである。
【００１１】
また、この発明に係るソフトウエア品質検査支援システムは、前記各サブシステムの製作担当チームの登録を受け付けるチーム登録受付手段と、前記各サブシステムごとの目標項目数の合計を、実際に作成された前記各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの複雑度を算出する複雑度算出手段と、前記試験項目群の実施により検出された各サブシステムごとの誤り数を、それら各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの誤り率を算出する誤り率算出手段と、各サブシステムごとの複雑度と誤り率と、各サブシステムの製作担当チームと、の関連を表す製作担当チーム能力分析情報を作成する製作担当チーム能力分析手段と、を備えるものである。
【００１２】
また、この発明に係るソフトウエア品質検査支援システムは、前記製作担当チーム能力分析情報は、複雑度と誤り率とを２軸とする２次元空間において、前記各サブシステムの製作担当チームを、当該サブシステムの複雑度と誤り率の組合せで規定される位置にプロットした製作担当チーム能力表であり、前記製作担当チーム能力分析手段は、作成した前記製作担当チーム能力表を表示する手段を有することを特徴とするものである。
【００１３】
また、この発明に係るソフトウエア品質検査支援システムは、前記試験項目の実施に伴う障害の報告を受け付ける障害報告入力手段と、前記障害報告に対して処置を行ったサブシステムについて誤り数の登録を受け付け、各サブシステムごとに誤り数を集計する手段と、各サブシステムのプログラム規模の入力を受け付ける手段とを備え、前記誤り率算出手段は、前記各サブシステムごとに、その誤り数とプログラム規模とに基づき誤り率を算出することを特徴とするものである。
【００１４】
また、この発明に係るソフトウエア品質検査支援システムは、前記製作担当チーム能力分析情報に基づき、前記各製作担当チームごとにどの複雑度レベルまでのサブシステムを抜き取り検査すべきかを示す抜き取り指針を求めて提示するガイダンス処理手段を更に備えるものである。
【００１５】
また、この発明に係るソフトウエア品質検査支援システムは、前記障害報告に対して行った処置の報告として、当該障害の原因が以前に処置した同一サブシステムの同一箇所であることを示す重複誤り情報の入力を受け付ける手段と、受け付けた重複誤り情報群に基づき、各サブシステムごとの重複誤り数を集計する重複誤り集計手段と、集計した各サブシステムごとの重複誤り数を、前記目標項目数算出手段が算出した当該サブシステムの目標試験項目数で除することにより、各サブシステムごとの重複誤り率を計算し、計算した各サブシステムごとの重複誤り率を提示する試験性能評価手段と、を更に備えるものである。
【００１６】
また、この発明に係るソフトウエア品質検査支援システムは、前記各サブシステムを前記抜き取り検査の対象とするための誤り率に関する基準を記憶する手段と、前記各サブシステムの前記誤り率が、前記各サブシステムを前記抜き取り検査の対象とするための前記誤り率に関する基準を満足しているか否かを判定し、その判定結果を出力する手段と、を備えるものである。
【００１７】
また、この発明に係るソフトウエア品質検査支援システムは、前記試験結果が前記移行基準を満足していない場合、その基準を満足しないサブシステムを示したレポートを生成する手段をさらに備えるものである。
【００１８】
また、この発明に係るソフトウエア品質検査支援方法は、１以上の業務を複数のサブシステムの組合せにより実行するソフトウエアシステムについて、そのソフトウエアシステムの品質検査を支援するためにソフトウエア品質検査支援システムが実行するソフトウエア品質検査支援方法であって、前記ソフトウエア品質検査支援システムは、該ソフトウエアシステムが実行する各業務ごとに、前記各サブシステムのその業務に関するウェイトを記憶すると共に、前記各業務ごとに、その業務に関する前記ソフトウエアシステムの機能検証のために試験すべき試験項目の数を記憶する記憶手段と、を備え、前記ソフトウエア品質検査方法は、前記ソフトウエア品質検査支援システムが備える目標項目数算出手段が、前記各業務ごとに、前記試験項目数記憶手段に記憶された当該業務の試験項目数と、前記ウェイト設定記憶手段に記憶された当該業務に関する前記各サブシステムのウェイトと、に基づき、各業務ごとの各サブシステムの目標試験項目数を算出する目標項目数算出ステップと、前記ソフトウエア品質検査支援システムが備える目標項目表示手段が、前記目標項目数算出ステップで算出された各業務ごとの各サブシステムの目標試験項目数を表示する目標項目数表示ステップと、前記ソフトウエア品質検査支援システムが備える合計目標試験項目数計算手段が、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を、各サブシステムごとにそれら各業務にわたって合計することにより、各サブシステムごとの合計目標試験項目数を計算するステップと、前記ソフトウエア品質検査支援システムが備える試験結果入力手段が、前記各業務ごとに、その業務について実施した試験項目の数の入力を受け付けるステップと、前記ソフトウエア品質検査支援システムが備える試験進捗管理手段が、前記試験結果入力手段で受け付けた各業務ごとの、前記実施した試験項目の数に、当該業務についての各サブシステムのウェイトを乗ずることにより、それら各サブシステムごとの、実施した試験項目の数を表す試験実施進捗情報を求めるステップと、前記ソフトウエア品質検査支援システムが備える試験進捗表示手段が、前記試験進捗管理手段で求めた前記各サブシステムごとの試験実施進捗情報と、前記合計目標試験項目数計算手段で求めた前記各サブシステムごとの合計目標試験項目数とを対比可能に表示するステップと、を備える。
【００１９】
また、この発明に係るソフトウエア品質検査支援方法は、前記ソフトウエア品質検査支援システムが備えるチーム登録受付手段が、前記各サブシステムの製作担当チームの登録するを受け付けるステップと、前記ソフトウエア品質検査支援システムが備える複雑度算出手段が、前記各サブシステムごとの目標項目数の合計を、実際に作成された前記各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの複雑度を算出する複雑度算出ステップと、前記ソフトウエア品質検査支援システムが備える誤り率算出手段が、前記試験項目群の実施により検出された各サブシステムごとの誤り数を、それら各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの誤り率を算出する誤り率算出ステップと、前記ソフトウエア品質検査支援システムが備える製作担当チーム能力分析手段が、各サブシステムごとの複雑度と誤り率と、各サブシステムの製作担当チームと、の関連を表す製作担当チーム能力分析情報を作成する製作担当チーム能力分析情報作成ステップと、を備える。
【００２０】
【発明の実施の形態】
実施の形態１．
ソフトウエアシステム（ソフトウエア製品）は、１以上の業務のための処理を実行するためのものであり、複数のサブシステムに分けて開発していくことが一般的である。個々のサブシステムは、それぞれ比較的単純な機能を実現するプログラム（又はプログラムの組）である。個々の業務は、１つのサブシステム、又は複数のサブシステムの組合せ、により実現される。この逆に、１つのサブシステムが複数の業務で兼用される場合もよくある。
【００２１】
すなわち、「業務」は、そのソフトウエアシステムが実行すべき個々の振る舞いであり、ソフトウエアシステムの要求仕様から導き出される。これに対し、「サブシステム」は、そのソフトウエアシステムを物理的に構成する個々のプログラム（又はその組）である。
【００２２】
例えば、文書エディタという１つのソフトウエアシステムを考えた場合、このソフトウエアは、文字入力、文字列検索、文書保存など様々な「業務」の実現を目的したものである。この中で例えば「文字入力」という業務は、入力キー認識プログラム、カナ漢字変換システムとのインタフェースプログラム、得られた文字コードを表示するためのプログラムなど、いくつかのサブシステム（プログラム）により実現される。そして、例えばその中の入力キー認識のためのサブシステムは、「文字列検索」業務でも利用される。
【００２３】
ソフトウエアシステムの試験は、要求仕様が満足されているかどうかを検査するため、要求仕様により規定される「業務」単位に行う。
【００２４】
このようなソフトウエアシステムの効果的な品質検査の支援のため、この実施の形態では、図１に示すソフトウエア品質検査支援システムを提供する。このシステムは、ソフトウエアの開発部門での試験・修正のサイクルを支援する開発部門システム２００、検査部門でのソフトウエア品質検査を支援するための検査部門システム３００、及びそれら両者の試験・検査の作業のために利用する諸データを管理するデータベース部１００とを備えている。
【００２５】
データベース部１００は、障害ＤＢ（データベース）１１０、進捗ＤＢ１２０、試験対応表１３０及び試験評価表１４０を含んでいる。
【００２６】
障害ＤＢ１１０は、開発部門等での試験・修正サイクル等で出てくる障害報告やその処置報告の内容を蓄積するデータベースである。障害ＤＢ１１０に蓄積されるレコードのデータ構造の例を図２に示す。このデータ構造には、障害検出時に付与又は入力される情報と、障害処置時に入力される情報とが含まれる。障害検出時に付与又は入力される情報には、障害報告の一意な識別番号である「障害報告番号」、その報告の内容を示す「件名」、障害を発見したときの業務の「業務ＩＤ」、障害の「発生日」、当該障害の起こったソフトウエアシステムの「製品番号」、版名、その障害を検出した「検出部門（及び／又は検出者）」、その障害の「現象」の説明などがある。一方、障害処置時に入力される情報には、その処置について回答した「回答者」、その障害がプログラム自体の誤りであったか否かを示す「誤り」フラグ、その障害報告が以前の報告と同一箇所の誤りに起因すると判断された場合にセットされる「重複」フラグ、以前にその同一箇所の誤りを報告した障害報告の番号を示す「重複障害番号」、その以前の障害報告の際の業務を示す「重複業務ＩＤ」、当該障害報告に対して行った処置を表す「処置区分」、処置のために修正したサブシステムを示す「修正サブシステム名」、修正の概要を示す「修正情報」、及び修正によって改版した場合の「修正版名」などを含んでいる。なお、障害報告が「重複」でなかった場合は「重複障害番号」や「重複業務ＩＤ」は空欄となり、プログラムの修正を行わなかった場合は「修正サブシステム名」、「修正情報」及び「修正版名」は空欄となる。
【００２７】
進捗ＤＢ１２０は、開発部門等での試験・修正サイクルの進捗情報を蓄積するデータベースである。進捗ＤＢ１２０に蓄積されるレコードのデータ構造の一例を図３に示す。このデータ構造には、業務の「業務ＩＤ」、当該業務についての試験を行っている部門を示す「検出部門」（これは一般的には開発部門自体である）、この業務のために計画した試験項目の数を示す「計画項目数」、そのうち現時点までに実施した試験項目数を示す「実施実績数」、実施実績のうち現時点までに合格した試験項目数を示す「合格実績数」等の情報が含まれる。
【００２８】
試験対応表１３０は、試験項目の設計や、各サブシステムの複雑度の算出のために用いる表である。図４に試験対応表１３０の例を示す。図４の表において、各行はソフトウエアシステムを構成するサブシステムに対応している。この例では、ＩＤ１１０１〜１５０１までの２７個のサブシステムを含んだソフトウエアシステムを取り扱っている。この表は、大きく分けて、左半分の試験設計支援用の部分１３０ａと、右半分の複雑度算出用の部分１３０ｂとから構成される。
【００２９】
左半分の部分１３０ａは、各業務ごとに欄分けされている。個々の業務の欄は、その業務に占める各サブシステムのウェイトを設定する「ウェイト」欄と、そのウェイトに対応した試験項目数を示す「項目数」欄を含んでいる。ウェイトの値は、開発部門が各業務における各サブシステムの寄与割合を考慮して設定する。図示の例では、ウェイトは百分率で表されており、各業務ごとの「ウェイト」値の総和が１００．０となるように設定する。
【００３０】
前述したように、試験項目群の設計（作成）は、要求仕様で規定される業務ごとに行う。業務ごとに必要な試験項目数は、要求仕様から、ＦＰ法（ファンクション・ポイント法）などの公知の手法を用いて求めることができる。すなわち、ＦＰ法等で求められるその業務の機能の数に基づき、当該業務についての試験項目の総数を決める。業務が提供する機能の数から当該業務の試験項目の総数を決めることにより、それら提供機能群を網羅的に試験するという目的において妥当な数の試験項目数が分かる。ただし、この業務ごとの試験項目の総数に合わせた数の試験項目を作成するというだけでは、試験項目の内容に偏りが出て、試験の効果が悪くなるおそれがある。そこで、この実施の形態では、個々の業務ごとの試験項目の作成指針となる情報を求めている。これが、各業務ごとの各サブシステムの「項目数」の値である。
【００３１】
すなわち、この実施の形態のシステムは、ＦＰ法等で求められた個々の業務の試験項目総数を試験対応表（図４）の「項目数」の「合計」に入力することにより、その項目総数を各サブシステムの「ウェイト」欄の値に従って割り振っていく。この結果得られた値が当該業務における各サブシステムの試験「項目数」である。図４を参照すると、例えば「業務１」の試験項目の総数は１７５０と設定されており、この「業務１」において「１１０２サブシステム」が占めるウェイトは１０．０％と設定されている。したがって、システムは、「業務１」に関する「１１０２サブシステム」をターゲットとした試験項目数の目標値（すなわち、目標項目数）を１７５．０個（＝１７５０×０．１０）と決定し、これを「項目数」欄に設定する。この場合、試験項目作成者は、「業務１」の１７５０項目のうち、「１１０２サブシステム」を利用する試験項目を１７５個以上作成すればよいことが分かる。同様に、ウェイトが３．０％である「１１０７サブシステム」の「項目数」は５２．５個と決定される。このように、１つの業務全体の試験項目数の目標値を、各サブシステムのウェイトに従って割り振っていき、このような割り振り処理を各業務ごとに行う。
【００３２】
このように、この実施の形態では、各業務ごとの試験項目を作成する際に、試験項目の総数だけでなく、各サブシステムをターゲットとした試験項目が幾つ必要かを示す情報を求めて提示することができる。したがって、試験項目設計者は、試験項目作成のための有用な指針が得られ、従来よりも効果的な試験項目群を設計できる。
【００３３】
なお、サブシステムをターゲットにした試験項目を作成するとはいっても、実際にはその試験項目は様々なサブシステムの連携により実現されることが多いので、その試験項目は当該サブシステムのみについてのものではなく、当該「業務」全体についてのものとして取り扱う。要求仕様が実現されているかという観点が重要なので、試験項目の実施は業務単位で行われる。
【００３４】
「合計」欄Ａには、そのようにして求めた各サブシステムの目標項目数を全業務にわたって合計した値が設定される。
【００３５】
試験対応表１３０の右半分の部分１３０ｂは、各サブシステムの複雑度を求めるための部分である。複雑度は、サブシステム（プログラム）の作成の困難さを示す指標値である。この複雑度を求めるため、この試験対応表１３０では、各サブシステムごとに「試験対象規模ＫＬ」（Ｃ）、「試験密度」（Ｂ）、及び「自動生成等のＫＬ」（Ｄ）の値を入力する。「試験対象規模ＫＬ」は、当該サブシステムのソースコードのうち、人手により作成したコードのライン数であり、単位はＫＬ（キロライン＝千行）である。人手により作成したものなので、本来の試験の対象という意味で、試験対象規模ＫＬと呼ぶ。「試験密度」は、ソースコードのライン数に応じて定められる、必要な試験項目の密度であり、単位は「項目数／ＫＬ」である。「試験密度」は、企業ごと、あるいは事業所ごとに、経験的に定めた基準であり、各企業等の経験の蓄積が反映されたある程度信頼性の高い値である。「自動生成等のＫＬ」は、当該サブシステムのソースコードのうち、プログラム自動生成システムによる自動生成等により作成したソースコードのＫＬ数である。これら各欄の値は、各サブシステムのソースコードの最初の版が完成した段階で、この試験対応表１３０に登録される。
【００３６】
「試験対象規模ＫＬ」と「自動生成等のＫＬ」の和が、サブシステムの実装上のソースコードのＫＬ数である。この実装上のソースコードのＫＬ数に「試験密度」を乗じることにより、試験対応表１３０の「実装上の確認項目数」（Ｅ）の値が計算される。この「実装上の確認項目数」は、実装ソースコードを事業所基準の「試験密度」に従って試験するとしたときの試験項目数である。
【００３７】
各サブシステムの「複雑度」（Ｆ）は、次式に従って算出される。
【００３８】
［数式１］
Ｆ＝｛１＋ｌｏｇ（Ｃ）｝・Ａ／Ｅ
この算出式の右辺前半の｛１＋ｌｏｇ（Ｃ）｝（Ｃは「試験対象規模ＫＬ」、すなわち人手で作成したライン数）は、ソースコードのライン数が多くなればなるほど生産性が低くなる（特に１００〜１０００ＫＬの間で生産性が急激に低下する）という経験則を反映した因子であり、Ｃの値が大きくなるほどその値は大きくなる。
【００３９】
一方、右辺後半のＡ／Ｅ（Ａは目標試験項目数の「合計」。Ｅは「実装上の確認項目数」）は、同じ機能を実現するプログラムであれば短いコードの方が洗練されており、作成が困難であるという経験則を反映した因子である。試験項目数は、サブシステムが持つ機能の数を反映していると考えられる。「実装上の確認項目数」Ｅは、ソースコードのライン数から見て、サブシステムが事業所等の基準でどの程度の機能数に対応するかを表した数値と見ることができる。これに対し、ウェイトに従って求めた目標項目数の「合計」Ａは、そのサブシステムが実現していると考えられる機能数に対応した数値とみることができる。したがって、それらの比Ａ／Ｅは、（実現した機能）／（コードのライン数に見合った機能）と見ることができ、この値が大きいほど、少ないライン数で多くの機能を実現している洗練されたコードであるといえる。
【００４０】
したがって、それら２つの因子を乗算して得られた複雑度Ｆは、２つの基準を反映した値となっており、値が大きくなるほど作成の困難なサブシステム（プログラム）であると言える。この複雑度Ｆは、開発部門でのソフトウエアシステムの開発が完了した段階で求めることができる。そして、複雑度Ｆは、後に検査部門で抜き取り検査のサンプル絞込をする際に利用される。
【００４１】
次に、図５を参照して試験評価表１４０について説明する。この試験評価表１４０は、開発部門での試験・修正サイクルの進捗管理のために用いられる。この表１４０は、図５に示すように、「試験進捗評価」セクションと「品質評価」セクションとの２つに大きく分けられる。「試験進捗評価」セクションは、試験の進捗状態に関する諸項目を含んだ欄であり、試験の進捗度を示す「試験実施進捗」欄、障害の処置状況を示す「障害処置進捗」欄、及び現時点での障害発見数からみて最終的に発見されるであろう障害数を示す「完了時障害数予測」欄、から構成される。ソフトウエアシステムを構成する各サブシステムごとに、これら各欄の値が設定される。
【００４２】
「試験実施進捗」欄は、「実施実績」Ａ１、「合格実績」Ａ２、「合格計画」Ｂ、「最終見通し」Ｃ、「進捗率」、「消化率」、及び「障害」数Ｄの欄を含んでいる。「実施実績」Ａ１は、これまでに実施した試験項目の数を示す。「合格実績」Ａ２は、Ａ１のうち、合格した試験項目数を示す。「合格計画」Ｂは、予め定めたスケジュールからみて現時点で合格しているべき試験項目数を示す。「最終見通し」Ｃは、最終的に実施・合格すべき試験項目数を示し、これは試験対応表１３０の目標試験項目数の「合計」Ａに等しい。「進捗率」は、現時点の実際の合格試験項目数の計画値に対する割合であり、Ａ２／Ｂを百分率で示した値である。「消化率」は、現時点の実際の試験項目数の「最終見通」に対する割合であり、Ａ２／Ｃを百分率で示した値となっている。そして、「障害」は、現時点までに報告された障害の数を示している。
【００４３】
「障害処置進捗」欄は、「未処置」数、「処置」数Ｅ、「処置率」の欄を含んでいる。「処置」数は、報告された障害のうち、処置が完了したものの数を示す。「処置」の中にある「誤り」数Ｆは、「処置」した障害のうち、プログラムの「誤り」が原因であったものの数である。障害の中には、プログラムの「誤り」以外（例えば試験者が動作条件を間違ったために起こった障害など）のものもあるので、このような区別を設けている。プログラムに「誤り」があった場合、プログラム修正の処置がとられる。「未処置」数は、報告された障害のうち未処置のものの数である。そして、「処置率」は報告された障害のうち処置済みのものの割合を示す百分率である。
【００４４】
また、「品質評価」セクションは、「システム生産量」欄、「現状推定品質」欄、及び「完了時推定品質」欄から構成される。
【００４５】
「システム生産量」Ｇは、サブシステムのソースコードのうち、人手により作成したコードのライン数（単位ＫＬ）である。
【００４６】
「現状推定品質」欄は、現時点での各サブシステムの推定品質に関する欄であり、「誤り件数」Ｈ、「試験密度」及び「誤り率」の欄を含んでいる。「誤り件数」Ｈは、現時点で報告されている全障害を処置したときに見つかるであろう「誤り」の総数である（＝Ｄ・Ｆ／Ｅ）。「試験密度」は、現時点までに実施した試験項目のソースコード１ＫＬ当たりの数である。「誤り率」は、現時点の推定誤り総数をサブシステムのソースコードのＫＬ数で割ったものであり、１ＫＬ当たりの誤り数を示している。
【００４７】
「完了時推定品質」欄は、現状の傾向がそのまま続いたと仮定した場合の、試験完了時点（全試験項目が合格した時点）での各サブシステムの推定品質を示している。この欄も、「現状推定品質」欄と同様、「誤り件数」I、「試験密度」、及び「誤り率」の欄を含んでいる。「完了時推定品質」の「誤り件数」Ｉは、現状での誤りの発見率（Ｆ／Ｅ）に、「完了時障害数予測」値を乗じたものである。「試験密度」は、最終的な試験項目数をサブシステムのＫＬ数で割ったものである。そして、「誤り率」は、試験完了時の推定「誤り件数」Ｉを、サブシステムのＫＬ数で割ったものである。
【００４８】
更に試験評価表１４０には、各サブシステムごとに、そのサブシステムの開発を担当している製作担当チームのコードが登録される。
【００４９】
この試験評価表１４０は、障害ＤＢ１１０や進捗ＤＢ１２０に登録された情報に基づき随時作成、更新される。例えば、「障害」数Ｄや「処置」数Ｅ、「誤り」数Ｆなどは、障害ＤＢ１１０に登録された障害報告のレコードを集計して求められる。また、「実施実績」Ａ１や「合格実績」Ａ２などは、進捗ＤＢ１２０の該当項目から求められる。また、「最終見通し（目標試験項目数）」Ｃや「システム生産量」Ｇには、試験対応表１３０の「合計（項目数合計）」Ａや「試験対象規模ＫＬ」Ｃの情報が登録される。「合格計画」Ｂは、別途定められている試験スケジュールから求めて登録される。
【００５０】
なお、障害報告や試験進捗のレコードは「業務」ごとに分類されているが、この試験評価表１４０には、１つのソフトウエアシステムが実現する全業務の障害数や合格実績などの現時点での集計結果（及びそれに基づく推定結果）が表示される。
【００５１】
ここで、試験項目は業務単位で実行されるので、進捗ＤＢ１２０には試験項目の実施実績数や合格実績数などの試験結果が業務単位でしか登録されない。この実施の形態では、業務単位で登録された実施実績数や合格実績数を、試験対応表１３０に設定されたウェイトを用いて割り振ることにより、各サブシステムごとの実施実績数と合格実績数を割り出している。これを全業務にわたって累計した結果が、試験評価表１４０（図５）の各サブシステムの「実施実績」及び「合格実績」の値となる。このように、業務単位での試験結果をウェイトを用いて各サブシステムに割り振り、それを集計して表示することにより、試験担当者は、抽象的な「業務」単位の試験進捗だけでなく、物理的な実体としての「サブシステム」（プログラム）単位での試験進捗を把握することができる。
【００５２】
開発部門での試験・修正サイクルで最終的にすべての試験項目について合格したと判断されると、試験評価表１４０の「現状推定品質」欄と「完了時推定品質」欄の各項目の値が同じになり、これが開発部門での最終的な試験結果の１要素となる。
【００５３】
以上、データベース部１００で管理される各データの内容について説明した。ここで再び図１に戻り、この実施の形態のシステム構成を説明する。
【００５４】
開発部門システム２００は、開発部門がソフトウエアシステムの試験・修正のサイクルを進めていく際に用いるシステムであり、入力処理部２１０、表示処理部２３０及び演算処理部２５０を含んでいる。
【００５５】
入力処理部２１０は、データベース部１００に各種情報を入力するための機構であり、ウェイト設定部２１２、試験項目数設定部２１４、プログラム規模入力部２１６、製作者登録部２１８、障害報告入力部２２０及び試験結果入力部２２２を含む。ウェイト設定部２１２は、試験対応表１３０（図４）に対し、各業務に占める各サブシステムのウェイトを設定するための入力機構である。開発部門の担当者は、各業務の内容と各サブシステムの機能とを考慮して各々のウェイト値を定め、入力する。試験項目数設定部２１４は、試験対応表１３０の各業務の欄の「項目数」の合計値の欄に、値を設定するための入力機構である。ここには、ＦＰ法などの公知の手法を用いて求めた当該業務のための試験項目の総数が設定される。プログラム規模入力部２１６は、試験対応表１３０（図４）の「試験対象規模ＫＬ」や「自動生成等のＫＬ」など、作成された各サブシステムのプログラム規模の値を入力するための機構である。製作者登録部２１８は、試験評価表１４０（図５）における各サブシステムの製作担当チームを入力するための機構である。障害報告入力部２２０は、障害ＤＢ１１０に対するデータの入力機構である。試験・修正サイクルにおいて障害が検出されたり、その障害に対して処置を行った場合、試験担当者や障害対策担当者は、この障害報告入力部２２０を用いてその障害や処置の内容を障害ＤＢ１１０に入力する。試験結果入力部２２２は、進捗ＤＢ１２０に対するデータの入力機構である。試験担当者は、試験項目の実施の結果（例えば実施した項目数やそのうち合格した項目数など）を、定期的にあるいは随時、この試験結果入力部２２２から入力する。
【００５６】
演算処理部２５０は、データベース部１００のデータに対して各種の演算処理を行って、試験進捗やソフトウエア品質に関する各種情報を求め、それをまとめるための機構である。演算処理部２５０は、目標項目数算出部２５２、試験進捗管理部２５４、誤り数集計部２５６、誤り率算出部２５８及び複雑度算出部２６０を含む。目標項目数算出部２５２は、試験対応表１３０に、各業務ごとの総試験項目数と、その業務における各サブシステムのウェイトとが設定されると、それらに基づき各業務における各サブシステムの目標項目数を算出し、その値を試験対応表１３０の「項目数」欄に設定する。試験進捗管理部２５４は、ユーザからの指示に応じ、進捗ＤＢ１２０及び障害ＤＢ１１０の現時点までの蓄積情報を集計し、試験評価表１４０を作成又は更新する。誤り数集計部２５６は、障害ＤＢ１１０のレコード群から「誤り」の数を、ソフトウエアシステム全体、及び各サブシステムごとに集計する。誤り率算出部２５８は、集計した「誤り」数に基づき「誤り率」を算出する。すなわち、誤り率算出部２５８は、試験評価表１４０（図５）における「現状推定品質」欄や「完了時推定品質」欄の各項目の算出処理を行う。
【００５７】
表示処理部２３０は、目標項目数表示手段である試験対応表表示部２３２と、試験進捗表示手段である試験評価表表示部２３４と、を含む。前者は試験対応表１３０を表示し、後者は試験評価表１４０を表示する。試験対応表１３０の表示により、開発部門の試験担当者は、各サブシステムにそれぞれどの程度の重みを置いて試験項目群を作成したらよいかが分かり、より効果的な試験項目の設計の助けとなる。また、試験評価表１４０の表示により、試験担当者や管理者は各サブシステムごとの試験の進捗状況を把握することができ、従来よりもきめ細かい試験進捗の管理が可能となる。
【００５８】
次に、検査部門システム３００について説明する。検査部門システム３００において、製作者能力分析部３１０は、試験対応表１３０と試験評価表１４０の情報に基づいて、開発部門の各製作担当チームの能力分析を行う。能力分析は、各製作担当チームが作成したサブシステムの複雑度と誤り率の相関に基づき行う。すなわち、試験評価表１４０における各サブシステムの「誤り率」と「製作担当チーム」の情報と、試験対応表１３０における各サブシステムの「複雑度」との情報を組み合わせ、それらの相関関係を求める。能力分析は開発部門での試験の完了後に行うので、ここで用いる「誤り率」は、試験評価表１４０の「現状推定品質」欄又は「完了時推定品質」欄のどちらの「誤り率」を用いてもよい（既にすべての試験項目について合格となっているはずなので、推定値ではなく確定値となっている）。図６は、各サブシステムの製作担当チーム、誤り率及び複雑度をまとめた表である。製作者能力分析部３１０は、この表を作成し、更に図７に示すような各製作担当チームごとの誤り率と複雑度の相関関係を表す製作者能力表３１２を生成する。この製作者能力表３１２は、サブシステムの誤り率及び複雑度をそれぞれ複数段階に分け、各サブシステムの（誤り率，複雑度）の組合せに対応する位置に、そのサブシステムの製作担当チームを表したものである。例えば、図６によれば、１１０１サブシステムは、誤り率が０．７１で複雑度が２．２３、製作担当チームがＡなので、図７の製作者能力表では、誤り率０（すなわち０〜１）、複雑度２（すなわち２〜３）の欄に製作担当チームＡが表されている。
【００５９】
作成された製作者能力表３１２は、能力表表示部３１４に表示される。この製作者能力表３１２の表示は、抜き取り検査のサンプル絞込のために有用な情報となる。例えば、図７の例では、Ａチームは、複雑度が２までは誤り率がゼロ台であり、複雑度３に上がっても誤り率が２以下であることが分かる。したがって、ここから、Ａチームの作ったサブシステムは、複雑度２以下については抜き取り検査の必要がなく、複雑度３のサブシステムからいくつかサンプルを抜き出して検査するなどの方針が立てられる。また、Ｃチームは、複雑度が２になると誤り率が急増しており、これから複雑度２以上のサブシステムはすべて検査した方がよいなどの方針が得られる。また、Ｄチームは製作したサブシステムが１つしかないので、誤り率ゼロ台という今回の結果の信憑性はそれほど高いものとは言えない。したがって、この場合はそのサブシステムを検査する必要があるなどと判断できる。また、Ｂチームは、複雑度３という複雑なサブシステムで誤り率がゼロ台であるにもかかわらず、複雑度１で誤り率が１台のケースがあり、複雑度によらず誤り率がばらついている。このため、Ｂチームについては、チーム内部の個別担当者レベルなどでの原因究明が必要などとの判断ができる。ばらつきの原因が究明できれば、Ｂチームの各サブシステムの試験結果をその原因レベル（例えば個別担当者が誰かなど）で更に細かく分析し、その原因レベルの分類ごとに抜き取り検査の絞込を行えばよい。
【００６０】
以上、この実施の形態のソフトウエア品質検査支援システムの構成について説明した。次に、このシステムを用いた品質検査の作業手順を説明する。この手順は、大きく分けて開発部門での試験・修正サイクルのフェーズと、その開発部門での試験結果を検査部門で検証するフェーズとに分けられる。
【００６１】
図８は、主として開発部門のフェーズの作業手順を示している。まず最初に、対象となるソフトウエアシステム用に障害ＤＢ１１０及び進捗ＤＢ１２０を準備する（Ｓ１０）。この障害ＤＢ１１０、進捗ＤＢ１２０は、検査部門が定めた所定形式に準拠したものとする。次に、試験対応表１３０を設計する（Ｓ１１）。このＳ１１の手順を図９を用いて更に詳しく説明する。
【００６２】
Ｓ１１では、まず開発部門の試験担当者は、要求仕様書などから当該ソフトウエアの実現すべき「業務」群を求めて試験対応表１３０（図４参照）に設定する（Ｓ１１０）。更に、各「業務」ごとの総試験項目数をＦＰ法等により求め、これを試験対応表１３０の各業務の「項目数」の「合計」欄に設定する（Ｓ１１０）。また、ソフトウエアシステムを構成する各サブシステムを、試験対応表１３０の各行に設定していく（Ｓ１１２）。そして、試験対応表１３０の各業務ごとに、各サブシステムの占めるウェイトを設定する（Ｓ１１４）。ウェイトの設定が完了すると、目標項目数算出部２５２が、各業務における各サブシステムに関する試験項目の目標数を算出する（Ｓ１１６）。そして、この算出された目標項目数が、試験対応表１３０に登録される（Ｓ１１８）。
【００６３】
このようにして試験対応表１３０ができると、次に試験担当者は、この試験対応表を参照しつつ、各業務についての試験項目群を作成する（Ｓ１２）。このとき、試験対応表における各業務の各サブシステムの目標項目数の情報が、試験項目作成の指針となる。
【００６４】
次に、試験評価表１４０（図５）を作成する（Ｓ１３）。この最初の段階では、試験評価表はほとんど空欄である。
【００６５】
このようにして障害ＤＢ１１０、進捗ＤＢ１２０、試験対応表１３０及び試験評価表１４０の準備が終わると、作成した試験項目を順次実施していき、その結果を各ＤＢに登録していく（Ｓ１４）。この試験において障害が検出されると、それが報告され、修正等の処置がなされる。このような試験・修正のサイクルを、全試験項目について合格の結果が得られるまで繰り返す（Ｓ１５）。全項目について合格となると、開発部門では所定品質のソフトウエアシステムが完成したとして、検査部門にその検証を求める。
【００６６】
検査部門の作業手順は図１０に示される。検査部門は、開発部門から検証を求められると、まずデータベース部１００から試験結果の試験対応表１３０及び試験評価表１４０を取得する（Ｓ２０）。製作者能力分析部３１０が、その試験結果から、各サブシステムの製作担当チーム、誤り率、複雑度の情報を抽出し（Ｓ２２）、製作者能力表３１２を作成する（Ｓ２４）。作成された製作者能力表３１２は、能力表表示部３１４により表示される（Ｓ２６）。検査部門の担当者は、この製作者能力表３１２を見て、抜き取り検査を行うサブシステムを絞り込む（Ｓ２８）。そして、絞り込んだサブシステムを抜き取り、そのソースコードの検査などを行う（Ｓ３０）。
【００６７】
以上、この実施の形態のシステム構成及び処理手順について説明した。以上説明したように、この実施の形態によれば、まずウェイト設定により試験項目の作成指針となる各サブシステムごとの目標試験項目数が得られるので、効果的な試験項目群の設計の助けとなる。また、業務ごとに実施される試験項目の結果を、そのウェイトに従って各サブシステムに分配し、各サブシステムごとの試験進捗状況を提示できるので、物理的な実体としての「サブシステム」（プログラム）単位での試験進捗を把握することができ、試験進捗の管理をよりきめ細かく行うことが可能になる。また、この実施の形態では、各サブシステムの複雑度と誤り率とに基づき製作者能力表を作成して表示することができ、この表示は、抜き取り検査のサンプル絞込において有用な指針となる。
【００６８】
なお、この実施の形態では、図７のような製作者能力表３１２により製作担当チームの能力傾向を表現したが、このような表の代わりに、誤り率、複雑度をそれぞれ軸とするグラフの形で表現してもよい。
【００６９】
また、製作者能力表は、抜き取り検査のサンプル絞込だけでなく、様々な用途に応用可能である。例えば、この表から能力が高いチーム（複雑度が高くても誤り率が低いチーム）、能力が低いチームを求め、次のソフトウエアの開発の際に、能力が高いチームほど難しいプログラムの作成に従事させるなど、開発体制づくりに役立てることができる。また、プログラム作成教育などにおいて、カリキュラムを進めていく際、作成したプログラムに対して試験を行わせ、その結果に基づきこのような能力表を作成することにより、達成度をチェックすることができる。
【００７０】
実施の形態２．
次に、この発明の実施の形態２について説明する。図１１は、実施の形態２に係るソフトウエア品質検査支援システムの構成を示す機能ブロック図である。図１１において、図１に示した構成と同様の構成要素については同一符号を付してその説明を省略する。
【００７１】
図１１のシステムは、図１に示した実施の形態１のシステムに対して、検査部門システム３００の機能を拡張したものである。すなわち、この実施の形態では、検査部門システム３００に、ガイダンス処理部３２０と抜き取り基準記憶部３２２とが新たに設けられている。
【００７２】
ガイダンス処理部３２０は、製作者能力分析部３１０で得られた分析結果（例えば製作者能力表３１２の情報）に基づき、抜き取り検査のサンプル絞込の指針を提示する手段である。実施の形態１では、担当者が製作者能力表３１２の表示を読み取って抜き取り検査の方針を決めていたが、この実施の形態では、「Ｃチームは複雑度２以上のサブシステムを全件検査した方がよいと判断されます」などと、具体的な抜き取り対象絞込の指針を提示する。
【００７３】
どのような指針を提示するかの基準となる情報は、抜き取り基準記憶部３２２に記憶されている。この抜き取り基準記憶部３２２には、例えば「誤り率がゼロ台しかない複雑度については、抜き取りを行わない」、「誤り率が３を超える複雑度については全件抜き取りを行う」、などのルールが登録されている。ガイダンス処理部３２０は、製作者能力の分析結果に対し、このルールを適用することにより、各製作担当チームごとにどの複雑度のサブシステムをどの程度抜き取って検査したらよいか、等の指針を表示する。
【００７４】
この実施の形態２によれば、より具体的な抜き取り検査の指針が得られるので、担当者の負担を軽減することができる。とくにソフトウエアシステムが大規模になるほど、このような具体的な指針の提示は大きな助けとなる。
【００７５】
実施の形態３．
次に、この発明の実施の形態３について説明する。図１２は、実施の形態３に係るソフトウエア品質検査支援システムの構成を示す機能ブロック図である。図１２において、図１に示した構成と同様の構成要素については同一符号を付してその説明を省略する。
【００７６】
図１２のシステムは、図１に示した実施の形態１のシステムに対して、検査部門システム３００の機能を拡張したものである。この実施の形態では、検査部門システム３００に、重複誤り集計部３３０と試験性能評価部３３２とが新たに設けられている。
【００７７】
この実施の形態３では、開発部門の試験結果から、各製作担当チームの能力だけでなく、試験に用いた試験項目群の適切さ（試験性能と呼ぶ）を分析し、その試験結果の妥当性を検証する。
【００７８】
試験性能は、重複誤りによって判定する。複数の障害報告の原因が、ソフトウエアシステムの同じ部分の誤りであった場合、その誤りを重複誤りという。重複誤りは、障害ＤＢ１１０の障害報告（図２参照）の「重複」フラグから割り出すことができる。重複誤りは、別々の試験項目で同じ誤りに起因する障害が検出されたことを意味する。これは、本来なら１つの試験項目で十分検出できている誤りに対し、複数の試験項目が作成されていたことを意味する。試験項目は、ＦＰ法などにより予め総数を決めているので、このような重複的な試験項目が存在すれば、他の部分についての試験項目の密度がその分薄くなっていることになる。したがって、重複誤りの比率が高いほど、開発部門で作成した試験項目群の性能が悪く、ひいては開発部門での試験結果（試験対応表や試験評価表など）の信頼性が低いことを意味する。そこで、この実施の形態では、重複誤りの程度に基づき試験性能を判断し、開発部門での試験結果の信頼性を判断する。
【００７９】
重複誤り集計部３３０は、障害ＤＢ１１０のレコードから、重複誤りの数を集計する。この集計は、サブシステム単位で行う。すなわち、障害ＤＢ１１０のレコード（図２参照）で、「重複」フラグが重複誤りを示す値にセットされているものを見つけ、それらのうち「修正サブシステム名」を同じくするものの数を各サブシステムごとに集計する。
【００８０】
試験性能評価部３３２は、その集計結果をもとに、各サブシステムごとの重複誤り率を算出する。図１３は、この重複誤り率の算出の方法を説明するための図である。各サブシステムの重複誤り率は、当該サブシステムの重複誤り数の、当該サブシステムの試験項目数（すなわちウェイトから求めた目標項目数）に対する百分率として求める。このようにして求めた重複誤り率は、当該サブシステムをターゲットとして作成した試験項目のうち、どの程度が重複して無駄となっているかを示している。
【００８１】
検査部門の担当者は、この重複誤り率の分布を見て、試験性能を判断する。例えば、すべてのサブシステムの重複誤り率が３以下であれば、開発部門での試験が信頼性の高い網羅的なものであったなど判断できる。このように、開発部門での試験が妥当だと判断した場合は、検査部門は、その試験結果に基づいて前述した抜き取り検査の処理を行う。これに対し、開発部門での試験性能が低いと判断した場合は、検査部門は、開発部門に対して試験のやり直しなどを指示するなどの処置をする。この場合、例えば、重複誤り率が許容限度以上に高いサブシステムを指摘し、そのサブシステムをターゲットとした試験項目を追加作成するなどの指示を行うことができる。そして、検査部門は、この再試験の結果を開発部門から受け取り、再度その結果から試験性能を判断し、十分な試験性能だと判断すれば抜き取り検査に進む。
【００８２】
このように、この実施の形態によれば、重複誤りの集計結果をもとに、網羅的な信頼性の高い試験がなされたかを判断することができるので、信頼性の低い試験結果をベースに抜き取り検査を行うなどの無駄をなくすことができる。
【００８３】
実施の形態４．
以上の実施の形態では、検査部門は、図１４に示すように開発部門での試験実施（Ｓ３００）の結果を受けて検査を実施し（Ｓ３１０）、その合否を判定している（Ｓ３２０）。この手順では、開発部門自身が試験段階での合否判定を行っており、検査部門は、開発部門による合格の旨の自己判定をそのまま受け入れて抜き取り、抜き取り検査などの検査処理を開始している。
【００８４】
ところが、仮にこの検査部門の自己判定に誤りがあるなどして実際には合格水準に達していない項目があった場合、検査部門の検査でも不合格になる可能性が高い。検査部門による検査には一般に数日から十数日程度の期間が必要なので、このようなケースでは時間のロスになる可能性が高い。
【００８５】
そこで、この実施の形態では、そのようなロスを未然に防ぐために、図１５に示すように、検査部門において、検査実施（Ｓ３１０）の前に、受入判定（Ｓ３３０）のステップを設けた。この受入判定では、開発部門からの検証依頼に応じ、開発部門での試験結果を調べ、試験結果レベルで所定の品質を満足しているかどうか判断する。
【００８６】
図１６は、この実施形態のシステム構成例を示す図である。この構成例は、実施の形態１のシステムをベースにしたものであり、検査部門システム３００に受入判定部３４０を設けた以外は、実施の形態１と同様のシステムである。
【００８７】
受入判定部３４０は、開発部門側からのソフトウエア検査依頼を受け入れるかどうかの判定処理の支援を行う。この受入判定支援処理では、担当者が受入判定対象の検査依頼を指定して受入判定部３４０を起動すると、受入判定部３４０は、その依頼に係るソフトウエアの試験評価表１４０の情報をデータベース部１００から取得し、その評価表１４０に示される試験結果が所定の基準を満足しているかを判定する。この基準は、例えば最終的な誤り率（残存誤り率）が予め定めたしきい値以下になっているなどのルールである。もちろん、誤り率以外の試験結果の特徴値について受入判定基準を設けることも可能である。この判定基準は、ソフトウエア全体についての特徴値について定めることもできるし、サブシステム単位の基準として定めることもできる。サブシステム単位の場合、個別のサブシステムごとに別々のしきい値を定めることも可能である。このような受入判定基準は、検査部門での抜き取り検査に移行するための移行基準ともいえる。このような受入判定基準は、予め策定され、検査部門システム３００に登録されている。受入判定部３４０は、試験結果の各特徴値がその判定基準を満足しているかどうかを調べる。
【００８８】
なお、この受入判定の際に、開発部門から検査部門への提出書類が揃っているか否かや、その書類に記載されている内容に不備がないかなどを調べ、このような点についての不備がないことを確認してから検査にはいるようにすれば、さらに検査の無駄を防止できる。ただし、このような書類等の項目は、一般にコンピュータによる自動判定が困難であり、人手により行うが、この人手による処理を受入判定部３４０により支援するようにすることも好適である。例えば、人手による判定項目やその手順などをユーザに対して表示し、ユーザがこれを参照しながら作業を進めるようにするなどである。なお、開発部門から検査部門への提出書類を定型化、電子化すれば、このようなチェック作業のかなりの部分を自動化することも可能である。
【００８９】
さて、受入判定部３４０では、このような自動的及び人手による個々の判定項目の判定結果を総合して、全体としての受入判定を行う。すべての項目が合格である場合は、制作者能力分析部３１０等による検査処理（Ｓ３１０）に移行する許可を出す。
【００９０】
一方、不合格の項目があれば、受入判定部３４０は、検査依頼が受け入れられないと判定し、その判定結果を検査部門の担当者に表示したり、あるいは依頼側の開発部門に対して通知したりする。なお、この場合、受入判定部３４０は、例えばどのサブシステムのどの特徴値が不合格であったかなど、不合格の項目についての説明を記載したレポートを自動作成し、それを不合格の旨の通知に対応づけて、開発部門側に通知する。このレポートに、不合格項目についての達成課題（例えば誤り率などの目標値や、その目標値と現状との差など）を含めれば、開発部門側での修正作業の参考とすることができる。
【００９１】
このように、この実施の形態４によれば、開発部門での試験の結果が予め定めた基準を満足しているかの判定を支援するツール（受入判定部３４０）を検査部門システム３００に設けたので、開発部門側での不備などによる無駄な検査の実行を低減することができる。
【００９２】
なお、ここでは実施の形態１をベースに受入判定部３４０を付加した例を説明したが、当業者には明らかなように、実施の形態２や３の検査部門システム３００に同様の受入判定部３４０を設けることも可能である。
【００９３】
また、以上の実施の形態１〜４では、開発部門に開発部門システム２００を設けたが、この開発部門システム２００と同等の機能を、ＷＷＷ（ワールド・ワイド・ウェブ）のウェブサービスとして提供することも可能である。図１７は、このようなウェブベースでの試験支援のシステム例を示す図である。この例では、実施の形態１等で開発部門システム２００に実装されていた入力処理部２１０，表示処理部２３０，演算処理部２５０が、ＷＷＷサーバ４００内のアプリケーションとして実装されている。これらは、例えばＣＧＩ（Common Gateway Interface）アプリケーションとして実装される。
【００９４】
各開発部門は、ウェブブラウザ（開発部門ブラウザ６００）を用い、インターネット５００を介してこのＷＷＷサーバ４００にアクセスする。すると、ＷＷＷサーバ４００は、ユーザ認証用のウェブページを開発部門ブラウザ６００に送り、ユーザＩＤやパスワードなどの認証情報の入力を求める。これに対して開発部門ブラウザ６００から認証情報が送信されてくると、ＣＧＩなどで実現されるユーザ認証部２７０がその認証情報を基にユーザ認証を行う。このため、開発部門は予めＷＷＷサーバ４００にユーザ登録を行っておく。ユーザ認証で正当なユーザと判断された場合、ＷＷＷサーバ４００は、サブシステムの数やウェイト、試験項目数など試験設計のための入力項目を入力するためのウェブページや、当該ユーザの既に作成されている試験対応表や試験評価表の内容を表示するウェブページや、それらの表にデータを入力するためのウェブページなどを、要求に応じてそのユーザに提供する。このとき、表示処理部２３０は、データベース部１００に登録された当該ユーザ（開発部門）の登録情報から、そのユーザの試験対応表や試験評価表などを表示したウェブページを作成する。また入力処理部２１０は、入力用ウェブページにて入力されたデータを、データベース部１００の当該ユーザの登録情報に反映させる。演算処理部２５０は、入力データに応じ、前述のようにして試験評価表その他の各種項目の値を計算し、データベース部１００の登録データに反映させる。なお、演算処理部２５０は、ＷＷＷサーバ４００に実装する代わりに、データベース部１００に実装することも好適である。
【００９５】
このようなＷＷＷサーバ４００をベースとした仕組みを設けることにより、開発部門は、実施の形態１などの場合のように大規模な開発部門システム２００を持たなくても、ＷＷＷのブラウザを持つだけで、上記各実施の形態と同等の支援処理を受けることができる。したがって、検査部門と開発部門が別会社の場合などにも、容易に本発明に係るシステムを展開することができる。
【００９６】
また、このようなＷＷＷベースの仕組みにおいて、検査部門システム３００からＷＷＷサーバ４００にアクセスし、各開発部門の試験対応表や試験評価表を閲覧できるようにすることも好適である。これには、検査部門に対し閲覧のみを許す権限を付与し、ＷＷＷサーバ４００のユーザ認証により検査部門からのアクセスと判断された場合には、各開発部門の試験評価表等の表示のみを許すようにすればよい。このようにすることにより、検査部門は、各開発部門の試験進捗状況（これは開発の進捗状況ととらえることもできる）を随時確認することができ、開発部門からの検査依頼の到来に備えたり、あるいは検査依頼の来る前に、試験評価表などから読みとれる事項などについて開発部門にアドバイスをしたりするなどの対処をとることが可能になる。
【００９７】
【発明の効果】
この発明は、以上説明したように構成されているので、以下に示すような効果を奏する。
【００９８】
この発明によれば、業務単位の試験項目数だけでなく、サブシステム単位の試験項目数が目安として提示できるので、ユーザはこの情報を参照することにより効果的な試験項目群を作成できる。
【００９９】
また、この発明によれば、業務ごとの試験結果を受け付け、それをサブシステム単位にブレークダウンして提示できるので、ユーザは、試験の進捗状況を、物理的な実体であるサブシステムの単位で把握することができ、きめ細かな試験進捗の管理が可能になる。
【０１００】
また、この発明によれば、試験結果に基づき各サブシステムを製作した各製作者の能力情報を求め、それを表示することができるので、ユーザはその表示により、各製作者の作成したサブシステムをどの程度検査（例えば抜き取り検査）すればよいかなどを判断できる。
【０１０１】
また、この発明によれば、各サブシステムの製作者を、当該サブシステムの複雑度と誤り率の組合せで規定される位置にプロットした製作者能力表を表示することにより、ユーザは、製作者の能力を視覚的に容易に把握することができる。
【０１０２】
また、この発明によれば、誤り数を集計する手段と、プログラム規模を入力する手段を設けたので、集計した誤り数とプログラム規模とに基づき誤り率を算出することができる。
【０１０３】
また、この発明によれば、製作者能力の分析結果に基づき、抜き取り検査の対象の絞込のための指針を提示するガイダンス処理手段を設けたので、ユーザは抜き取り対象の絞込をより容易に行うことができる。
【０１０４】
また、この発明によれば、重複誤りを集計し、その結果に基づき、試験項目の性能評価を行うことができるので、その評価結果をもとに、試験結果自体の信頼性を判断することができる。
【０１０５】
また、この発明によれば、試験結果が抜き取り検査への移行基準を満足するかどうかを判定し、その判定結果を出力することで、移行基準を満足しないうちに抜き取り検査に移ることを抑制し、無駄な検査を低減することができる。
【０１０６】
また、この発明によれば、移行基準を満足しないサブシステムを示したレポートを作成することで、どのサブシステムについて修正を行えばよいかなどの目安を提供することができる。
【図面の簡単な説明】
【図１】 実施の形態のソフトウエア品質検査支援システムの全体構成を示す機能ブロック図である。
【図２】 障害ＤＢのレコードのデータ構造の一例を示す図である。
【図３】 進捗ＤＢのレコードのデータ構造の一例を示す図である。
【図４】 試験対応表の一例を示す図である。
【図５】 試験評価表の一例を示す図である。
【図６】 各サブシステムの製作担当チーム、誤り率、及び複雑度を抽出した表を示す図である。
【図７】 製作担当チーム、誤り率及び複雑度の相関関係を表す製作者能力表を示す図である。
【図８】 開発部門での作業手順を示すフローチャートである。
【図９】 試験対応表の設計作業の詳細手順を示すフローチャートである。
【図１０】 検査部門の作業手順を示すフローチャートである。
【図１１】 実施の形態２のシステム構成を示す機能ブロック図である。
【図１２】 実施の形態３のシステム構成を示す機能ブロック図である。
【図１３】 重複誤り率の算出の方法を説明するための図である。
【図１４】 実施の形態１などでの開発部門から検査部門への移行の流れを示した図である。
【図１５】 実施の形態４での開発部門から検査部門への移行の流れを示した図である。
【図１６】 実施の形態４のシステム構成を示す機能ブロック図である。
【図１７】 各実施の形態のシステムにおけるサービスをＷＷＷサーバにて提供する形態を説明する図である。
【符号の説明】
１００ データベース部、１１０ 障害ＤＢ、１２０ 進捗ＤＢ、１３０ 試験対応表、１４０ 試験評価表、２００ 開発部門システム、２１０ 入力処理部、２１２ ウェイト設定部、２３０ 表示処理部、２５０ 演算処理部、３００ 検査部門システム、３１０ 製作者能力分析部、３１２ 製作者能力表、３１４ 能力表表示部。
Claims (10)
- １以上の業務を複数のサブシステムの組合せにより実行するソフトウエアシステムについて、そのソフトウエアシステムの品質検査を支援するためのソフトウエア品質検査支援システムであって、
該ソフトウエアシステムが実行する各業務ごとに、前記各サブシステムのその業務に関するウェイトを記憶すると共に、前記各業務ごとに、前記ソフトウエアシステムの要求仕様から求められる当該業務に関する前記ソフトウエアシステムの機能検証のために試験すべき試験項目の数を記憶する記憶手段と、
前記各業務ごとに、前記記憶手段に記憶された当該業務の試験項目数と、前記記憶手段に記憶された当該業務に関する前記各サブシステムのウェイトと、に基づき、各業務ごとの各サブシステムの目標試験項目数を算出する目標項目数算出手段と、
前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を表示する目標項目表示手段と、
前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を、各サブシステムごとにそれら各業務にわたって合計することにより、各サブシステムごとの合計目標試験項目数を計算する合計目標試験項目数計算手段と、
前記各業務ごとに、その業務について実施した試験項目の数の入力を受け付ける試験結果入力手段と、
前記試験結果入力手段で受け付けた各業務ごとの、前記実施した試験項目の数に、当該業務についての各サブシステムのウェイトを乗ずることにより、それら各サブシステムごとの、実施した試験項目の数を表す試験実施進捗情報を求める試験進捗管理手段と、
前記試験進捗管理手段で求めた前記各サブシステムごとの試験実施進捗情報と、前記合計目標試験項目数計算手段で求めた前記各サブシステムごとの合計目標試験項目数とを対比可能に表示する試験進捗表示手段と、
を備えるソフトウエア品質検査支援システム。 - 前記各サブシステムの製作担当チームの登録を受け付けるチーム登録受付手段と、
前記各サブシステムごとの目標項目数の合計を、実際に作成された前記各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの複雑度を算出する複雑度算出手段と、
前記試験項目群の実施により検出された各サブシステムごとの誤り数を、それら各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの誤り率を算出する誤り率算出手段と、
各サブシステムごとの複雑度と誤り率と、各サブシステムの製作担当チームと、の関連を表す製作担当チーム能力分析情報を作成する製作担当チーム能力分析手段と、
を備える請求項１記載のソフトウエア品質検査支援システム。 - 前記製作担当チーム能力分析情報は、複雑度と誤り率とを２軸とする２次元空間において、前記各サブシステムの製作担当チームを、当該サブシステムの複雑度と誤り率の組合せで規定される位置にプロットした製作担当チーム能力表であり、
前記製作担当チーム能力分析手段は、作成した前記製作担当チーム能力表を表示する手段を有することを特徴とする請求項２記載のソフトウエア品質検査支援システム。 - 前記試験項目の実施に伴う障害の報告を受け付ける障害報告入力手段と、
前記障害報告に対して処置を行ったサブシステムについて誤り数の登録を受け付け、各サブシステムごとに誤り数を集計する手段と、
各サブシステムのプログラム規模の入力を受け付ける手段と、
を備え、
前記誤り率算出手段は、前記各サブシステムごとに、その誤り数とプログラム規模とに基づき誤り率を算出することを特徴とする請求項２記載のソフトウエア品質検査支援システム。 - 前記製作担当チーム能力分析情報に基づき、前記各製作担当チームごとにどの複雑度レベルまでのサブシステムを抜き取り検査すべきかを示す抜き取り指針を求めて提示するガイダンス処理手段を更に備える請求項２記載のソフトウエア品質検査支援システム。
- 前記障害報告に対して行った処置の報告として、当該障害の原因が以前に処置した同一サブシステムの同一箇所であることを示す重複誤り情報の入力を受け付ける手段と、
受け付けた重複誤り情報群に基づき、各サブシステムごとの重複誤り数を集計する重複誤り集計手段と、
集計した各サブシステムごとの重複誤り数を、前記目標項目数算出手段が算出した当該サブシステムの目標試験項目数で除することにより、各サブシステムごとの重複誤り率を計算し、計算した各サブシステムごとの重複誤り率を提示する試験性能評価手段と、
を更に備える請求項４記載のソフトウエア品質検査支援システム。 - 前記各サブシステムを前記抜き取り検査の対象とするための誤り率に関する基準を記憶する手段と、
前記各サブシステムの前記誤り率が、前記各サブシステムを前記抜き取り検査の対象とするための前記誤り率に関する基準を満足しているか否かを判定し、その判定結果を出力する手段と、
を備える請求項５記載のソフトウエア品質検査支援システム。 - 前記試験結果が前記移行基準を満足していない場合、その基準を満足しないサブシステムを示したレポートを生成する手段をさらに備える請求項７記載のソフトウエア品質検査支援システム。
- １以上の業務を複数のサブシステムの組合せにより実行するソフトウエアシステムについて、そのソフトウエアシステムの品質検査を支援するためにソフトウエア品質検査支援システムが実行するソフトウエア品質検査支援方法であって、
前記ソフトウエア品質検査支援システムは、
該ソフトウエアシステムが実行する各業務ごとに、前記各サブシステムのその業務に関するウェイトを記憶すると共に、前記各業務ごとに、前記ソフトウエアシステムの要求仕様から求められる当該業務に関する前記ソフトウエアシステムの機能検証のために試験すべき試験項目の数を記憶する記憶手段と、
を備え、前記ソフトウエア品質検査方法は、
前記ソフトウエア品質検査支援システムが備える目標項目数算出手段が、前記各業務ごとに、前記記憶手段に記憶された当該業務の試験項目数と、前記記憶手段に記憶された当該業務に関する前記各サブシステムのウェイトと、に基づき、各業務ごとの各サブシステムの目標試験項目数を算出する目標項目数算出ステップと、
前記ソフトウエア品質検査支援システムが備える目標項目表示手段が、前記目標項目数算出ステップで算出された各業務ごとの各サブシステムの目標試験項目数を表示する目標項目数表示ステップと、
前記ソフトウエア品質検査支援システムが備える合計目標試験項目数計算手段が、前記目標項目数算出手段で算出した各業務ごとの各サブシステムの目標試験項目数を、各サブシステムごとにそれら各業務にわたって合計することにより、各サブシステムごとの合計目標試験項目数を計算するステップと、
前記ソフトウエア品質検査支援システムが備える試験結果入力手段が、前記各業務ごとに、その業務について実施した試験項目の数の入力を受け付けるステップと、
前記ソフトウエア品質検査支援システムが備える試験進捗管理手段が、前記試験結果入力手段で受け付けた各業務ごとの、前記実施した試験項目の数に、当該業務についての各サブシステムのウェイトを乗ずることにより、それら各サブシステムごとの、実施した試験項目の数を表す試験実施進捗情報を求めるステップと、
前記ソフトウエア品質検査支援システムが備える試験進捗表示手段が、前記試験進捗管理手段で求めた前記各サブシステムごとの試験実施進捗情報と、前記合計目標試験項目数計算手段で求めた前記各サブシステムごとの合計目標試験項目数とを対比可能に表示するステップと、
を備えるソフトウエア品質検査支援方法。 - 前記ソフトウエア品質検査支援システムが備えるチーム登録受付手段が、前記各サブシステムの製作担当チームの登録を受け付けるステップと、
前記ソフトウエア品質検査支援システムが備える複雑度算出手段が、前記各サブシステムごとの目標項目数の合計を、実際に作成された前記各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの複雑度を算出する複雑度算出ステップと、
前記ソフトウエア品質検査支援システムが備える誤り率算出手段が、前記試験項目群の実施により検出された各サブシステムごとの誤り数を、それら各サブシステムのプログラム規模で除することにより得られる値に基づき、前記各サブシステムの誤り率を算出する誤り率算出ステップと、
前記ソフトウエア品質検査支援システムが備える製作担当チーム能力分析手段が、各サブシステムごとの複雑度と誤り率と、各サブシステムの製作担当チームと、の関連を表す製作担当チーム能力分析情報を作成する製作担当チーム能力分析情報作成ステップと、
を備える請求項９記載のソフトウエア品質検査支援方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001080595A JP4502535B2 (ja) | 2000-03-23 | 2001-03-21 | ソフトウエア品質検査支援システム及び方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000081316 | 2000-03-23 | ||
| JP2000-81316 | 2000-03-23 | ||
| JP2001080595A JP4502535B2 (ja) | 2000-03-23 | 2001-03-21 | ソフトウエア品質検査支援システム及び方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001337846A JP2001337846A (ja) | 2001-12-07 |
| JP4502535B2 true JP4502535B2 (ja) | 2010-07-14 |
Family
ID=26588128
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001080595A Expired - Fee Related JP4502535B2 (ja) | 2000-03-23 | 2001-03-21 | ソフトウエア品質検査支援システム及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4502535B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4907237B2 (ja) * | 2006-06-22 | 2012-03-28 | 大日本スクリーン製造株式会社 | テスト工数見積装置およびプログラム |
| US8838607B2 (en) | 2012-10-17 | 2014-09-16 | International Business Machines Corporation | Software system test case creation |
| JP6161367B2 (ja) * | 2013-04-01 | 2017-07-12 | 三菱電機株式会社 | 情報処理装置及び情報処理方法及びプログラム |
| JP6209985B2 (ja) * | 2014-02-10 | 2017-10-11 | 富士通株式会社 | 製品設計支援プログラム、製品設計支援方法および製品設計支援装置 |
| JP6528389B2 (ja) * | 2014-11-17 | 2019-06-12 | 富士通株式会社 | 依存情報提供プログラム、依存情報提供装置及び依存情報提供方法 |
| CN105302573A (zh) * | 2015-11-20 | 2016-02-03 | 浪潮集团有限公司 | 一种用于功能验证平台的功能点匹配设置自动化平台的搭建方法 |
| JP6891780B2 (ja) * | 2017-11-29 | 2021-06-18 | トヨタ自動車株式会社 | ソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラム |
| JP6975086B2 (ja) * | 2018-03-29 | 2021-12-01 | 株式会社日立ソリューションズ | 品質評価方法および品質評価装置 |
| CN112148721B (zh) * | 2020-09-25 | 2022-08-19 | 新华三大数据技术有限公司 | 数据检核方法、装置、电子设备及存储介质 |
| CN114218060A (zh) * | 2022-02-22 | 2022-03-22 | 龙旗电子(惠州)有限公司 | 终端设备的性能测试方法及装置 |
-
2001
- 2001-03-21 JP JP2001080595A patent/JP4502535B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001337846A (ja) | 2001-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Zhou et al. | Fault analysis and debugging of microservice systems: Industrial survey, benchmark system, and empirical study | |
| US8375364B2 (en) | Size and effort estimation in testing applications | |
| Athanasiou et al. | Test code quality and its relation to issue handling performance | |
| Anda et al. | Towards an inspection technique for use case models | |
| Shatnawi | A quantitative investigation of the acceptable risk levels of object-oriented metrics in open-source systems | |
| US7895470B2 (en) | Collecting and representing knowledge | |
| US6799145B2 (en) | Process and system for quality assurance for software | |
| US20090070734A1 (en) | Systems and methods for monitoring software application quality | |
| Bhattacharya et al. | Assessing programming language impact on development and maintenance: A study on C and C++ | |
| US7757125B2 (en) | Defect resolution methodology and data defects quality/risk metric model extension | |
| US7451051B2 (en) | Method and system to develop a process improvement methodology | |
| Wagner | A literature survey of the quality economics of defect-detection techniques | |
| Lenhard et al. | Exploring the suitability of source code metrics for indicating architectural inconsistencies | |
| US20150039386A1 (en) | Method and system for risk assessment analysis | |
| US9208006B2 (en) | Recovery Maturity Model (RMM) for readiness-based control of disaster recovery testing | |
| JP4502535B2 (ja) | ソフトウエア品質検査支援システム及び方法 | |
| Kadry | A new proposed technique to improve software regression testing cost | |
| Chopra | Software testing: a self-teaching introduction | |
| JP6975086B2 (ja) | 品質評価方法および品質評価装置 | |
| Chopra | Software quality assurance: a self-teaching introduction | |
| Vassallo | Enabling continuous improvement of a continuous integration process | |
| Layman et al. | A case study of measuring process risk for early insights into software safety | |
| KR100939351B1 (ko) | 장애 관리 장치 및 방법 | |
| US7668680B2 (en) | Operational qualification by independent reanalysis of data reduction patch | |
| Gong et al. | A systematic map on verifying and validating software process simulation models |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061219 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20061219 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090220 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091027 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100126 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100326 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100420 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100420 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4502535 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130430 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130430 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140430 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |