JP2018142048A - 品質管理方法および品質管理装置 - Google Patents

Abstract

【課題】ソフトウェア開発の各担当者のセルフチェック後のソフトウェア品質をなるべく揃えて、実機テストを実施したい。【解決手段】ソフトウェアの開発担当者の確認箇所数を含むセルフチェック結果を取得する工程と、前記セルフチェック結果に基づいて、前記ソフトウェアの品質を算出する分析工程とを含み、前記セルフチェック結果には、ソフトウェアの規模が含まれており、前記分析工程では、前記ソフトウェア規模と前記確認箇所数とに基づいて、ソフトウェア品質を算出する品質管理方法を提供する。【選択図】 図１

Description

本発明は、システム開発の品質の管理に関する。

ソフトウェア開発のプロジェクトにおいては、開発を各担当者に分担しておこなう。各担当者が開発したプログラムを合わせて試験を行い、不良がないかプログラムを実機上で稼働させて試験を行い、不良がなかった場合にはユーザに提供を行う。試験において不良があった場合には、不良個所を特定し修正する。

プログラムを稼働させて初めてわかる不良もあるが、プログラム自体を注意深く読むことでわかる不良もある。そのため、各担当者は、自身が担当したタスクに対し、セルフチェックリストを用いてセルフチェックを行い、不良を低減させることが行われている。

プログラムに対するレビュー作業は、主にコンパイラが行う構文チェックや文法チェックでは検出できないエラーを発見して取り除くことを目的としており、人手によるソースプログラムの目視チェックが主体となる。特許文献１に開示される発明は、コンパイラでは検出されないエラーを起こす可能性のあるステートメントや識別子を自動検出することによって、人手による手間を軽減するレビュー支援システムを提案している。

特許文献１に開示される発明では、チェック項目にマッチしたステートメントや識別子を予め定義しておけば、該当するステートメントや識別子をソースプログラムから検索して、該当するソースプログラム内容をその周辺の内容とともにユーザに提示してくれるので、ユーザはソースプログラム全体を見る労力が軽減される。

特開２００５−１９０３３０号公報

しかしながら、ソフトウェア開発のプロジェクトの多くの開発担当者のスキルには一般にバラツキがあり、セルフチェックへの理解度が低かったり、品質マインドが低い担当者の場合には、従来のチェックをした項目の有無(チェック印)を記入するチェックリストでは、虚偽の記載が含まれていた際に、それによって引き起こされるエラー(バグ)の検出には時間が掛かるなど難しい。

特に、大規模開発で短期間のソフトウェア開発では大量の開発要員を一気に集めるため、要員ごとの品質マインドやスキルにバラツキがある。品質マインドやスキルが低い開発要員はプロセスを適切に実施することが出来ず、開発したソフトウェアの品質は悪い。ソフトウェア開発の納期遅延のリスク、コストが増えるリスクを減らすためには、プログラムの実機テスト段階前に、各担当者のセルフチェック後のソフトウェア品質をなるべく揃えられることが重要である。

本発明は、このような課題を考慮してなされたものであり、セルフチェック結果を用いてソフトウェア品質を管理することを目的とする。

上記課題を解決するために本発明の品質管理方法は、計算機を用いてソフトウェアの品質を管理する方法であって、ソフトウェアにかかる確認箇所数を含むセルフチェック結果を取得する工程と、前記セルフチェック結果に基づいて、前記ソフトウェアの品質を算出する分析工程とを含み、前記セルフチェック結果には、ソフトウェアの規模が含まれており、前記分析工程では、前記ソフトウェア規模と前記確認箇所数とに基づいて、ソフトウェア品質を算出するように構成する。
また、本発明の他の特徴として、前記品質管理方法において、前記ソフトウェアの不良件数を含む品質チェック結果を取得する工程とを含み、前記分析工程では、前記ソフトウェアの規模と、前記確認箇所数と、品質チェック結果とに基づいて、得点を算出し、当該得点に基づくランキングを出力する。

本発明によれば、セルフチェック結果を用いてソフトウェア品質を算出することができる。

品質管理装置の構成図の例である。 セルフチェックリストの例である。 確認箇所数テーブルのデータ構成を示す図である。 不良件数テーブルのデータ構成を示す図である。 得点情報テーブルのデータ構成を示す図である。 観点重要度テーブルのデータ構成を示す図である。 重要度得点係数テーブルのデータ構成を示す図である。 ツールインタフェースのメニュー画面の例である。 件数登録フローのフローチャートである。 得点算出フローのフローチャートである。 加点分析処理のフローチャートである。 減点分析処理のフローチャートである。 観点重要度、重要度得点係数設定処理のフローチャートである。 加点分析結果を品質管理部端末に表示した画面例である。 減点分析結果を品質管理部端末に表示した画面例である。

発明の好ましい例では、ソフトウェア開発の各担当者に、図２に例示するセルフチェックリスト２００に従って、各チェック項目２０１ごとに、チェック内容に該当する対象プログラムのステートメント、または識別子ごとに、確認箇所数２０２としてカウントして、セルフチェック終了時に報告させる。これは、従来のセルフチェックでは、各チェック項目２０１ごとに対象プログラムのチェックをしたらチェック済みの意味で印を付けて報告する方式では、例えば、あるチェック項目に該当する箇所が１２箇所あったとして、担当者が全ての該当箇所をチェックしたとしても、またはその内１０箇所しかチェックしないで残りの２箇所は見逃したとしても、同じチェック済みの報告しか分からなかった問題点を改善するものである。

すなわち、発明の好ましい例では、各担当者にセルフチェックリスト２００の各チェック項目２０１（以降、セルフチェック観点と称する）ごとに、確認箇所数２０２を報告させることにより、各担当者によるセルフチェック後のソフトウェア品質を推定するための指標に役立てることを提案する。

発明の好ましい例で採用するセルフチェック観点２０１は、対象プログラムの規模(step数など)の大小に関わらず確認箇所数が１、または固定数ではなく、対象プログラムの規模の増大につれて概ね線形に確認箇所数が増大する傾向を持つ。そのような傾向を有するセルフチェック観点を複数まとめたセルフチェックリストを作成して、ソフトウェア開発部へ提供して、セルフチェック時にセルフチェック観点ごとに確認箇所数をカウントして報告する。

以下、実施例を図面を用いて説明する。

図１は、ソフトウェア開発部より報告されるプログラムのセルフチェックの確認箇所数を入力として、当該プログラムの品質を推定する指標を出力する品質管理装置１００の構成図の例である。

品質管理装置１００は計算機（サーバ）上に構成することができて、そのハードウェア構成は、ＣＰＵ（Central Processing Unit）などにより構成される演算部１１０と、ＨＤＤ（Hard Disk Drive）、フラッシュメモリなどを用いたＳＳＤ（Solid State Drive）などにより構成される記憶部１２０と、各種出力装置などにより構成される出力部１３０と、ＮＩＣ（Network Interface Card）などにより構成される通信部１４０などを備える。
通信部１４０は、ネットワーク１５０を介して複数の品質管理部端末１６０、複数の開発部端末１７０と接続されている。

演算部１１０は、記憶部１２０に記憶されている品質管理プログラム(図示せず)をロードしてＣＰＵで実行することにより以下の各機能部を実現する。
確認箇所数登録部１１１は、品質管理部員が品質管理部端末１６０から入力したプログラム別のセルフチェック観点ごとの確認箇所数を受付けて、記憶部１２０の確認箇所数記憶領域１２１に記録する。または、ソフトウェア開発部の担当者がセルフチェック後に自らの開発部端末１７０より報告した確認箇所数を受付けて、確認箇所数記憶領域１２１に記録することでもよい。

不良件数登録部１１２は、品質管理部員が加点分析(後述する)結果より品質に疑いのあるプログラムの検査(テスト)の結果、または外注品のプログラムの受入れ検査の結果より、不良と判明した件数を入力したデータを受付けて、記憶部１２０の不良件数記憶領域１２２に記録する。

得点算出部１１３は、確認箇所数記憶領域１２１、及び不良件数記憶領域１２２に記録したデータを読み出して、セルフチェック観点別の重要度から決められた得点係数(後述する)を乗じて、加点(後述する)、減点(後述する)、総得点(後述する)を算出して、記憶部１２０の得点情報記憶領域１２３に記録する。

加点分析部１１４は、得点情報記憶領域１２３に記録した加点を読み出して、規模割りの加点を算出して、規模割り加点の大小にて順位を付けた加点分析結果を作成して、品質管理部端末１６０へ表示すると共に、記憶部１２０の加点分析結果記憶領域１２６に記録する。また、出力部１３０より加点分析結果を帳票に出力する。

減点分析部１１５は、得点情報記憶領域１２３に記録した総得点を読み出して、担当者ごとに総得点を集計して、規模割りの総得点を算出して、規模割り総得点の大小にて担当者に順位を付けた減点分析結果を作成して、品質管理部端末１６０へ表示すると共に、記憶部１２０の減点分析結果記憶領域１２７に記録する。また、出力部１３０より減点分析結果を帳票に出力する。

観点重要度、重要度得点係数設定部１１６は、品質管理部員が品質管理部端末１６０より、予めセルフチェック観点ごとの重要度、及び重要度ごとの得点係数を入力する設定を受付けて、記憶部１２０の観点重要度記憶領域１２４、及び重要度得点係数記憶領域１２５に記録する。

記憶部１２０は、確認箇所数１２１、不良件数１２２、得点情報１２３、観点重要度１２４、重要度得点係数１２５、加点分析結果１２６、減点分析結果１２７の各情報を記憶する記憶領域を有する。

図３は、確認箇所数テーブル１２１のデータ構成を示す。確認箇所数テーブル１２１のデータ項目欄である管理番号１２１ａは記録するプログラム単位に付けたデータレコードの管理番号であり、担当者氏名１２１ｂはプログラムの開発担当者氏名であり、責任者氏名１２１ｃは担当者のリーダであり、開発回次１２１ｄはプロジェクトにおける開発ロットを表わす開発単位であり、プログラムＩＤ１２１ｅはプログラム固有の識別名称であり、開発規模１２１ｆは開発プログラムのstep数などであり、担当確認箇所数１(１２１ｇ)はセルフチェック観点１に関して担当者がチェックした確認箇所数であり、責任者確認箇所数１(１２１ｈ)はセルフチェック観点１に関して責任者がチェックした確認箇所数から担当確認箇所数１を引いた差分であり、担当確認箇所数ｎ(１２１ｋ)はセルフチェック観点ｎに関して担当者がチェックした確認箇所数であり、責任者確認箇所数ｎ(１２１ｌ)はセルフチェック観点ｎに関して責任者がチェックした確認箇所数から担当確認箇所数ｎを引いた差分である。

図４は、不良件数テーブル１２２のデータ構成を示す。不良件数テーブル１２２は、管理番号１２２ａ、担当者氏名１２２ｂ、責任者氏名１２２ｃ、開発回次１２２ｄ、プログラムＩＤ１２２ｅ、開発規模１２２ｆ、品質管理部によるプログラムの検査(テスト)の結果、セルフチェック観点に該当する不良を新たに発見した件数を格納する観点該当不良件数１２２ｇ、品質管理部によるプログラムの検査(テスト)の結果、セルフチェック観点に該当しない不良を新たに発見した件数を格納する観点外不良件数１２２ｈ、などのデータ項目欄を有する。

図５は、得点情報テーブル１２３のデータ構成を示す。得点情報テーブル１２３は、管理番号１２３ａ、担当者氏名１２３ｂ、責任者氏名１２３ｃ、開発回次１２３ｄ、プログラムＩＤ１２３ｅ、開発規模１２３ｆ、確認箇所数テーブル１２１からデータを読み出しプログラムに対する担当者(および責任者)のセルフチェックの結果の評価点を格納する加点１２３ｇ、品質管理部によるプログラムの検査(テスト)の結果発見された不良に伴うマイナスの評価点を格納する減点１２３ｈ、加点と減点から算出する総得点１２３ｉ、などのデータ項目欄を有する。

図６は、観点重要度テーブル１２４のデータ構成を示す。観点重要度テーブル１２４は、セルフチェック観点の識別番号を表す観点番号１２４ａ、該当セルフチェック観点に関するセルフチェックに割り当てられた重要度のランクを表す重要度１２４ｂのデータ項目欄を有する。

図７は、重要度得点係数テーブル１２５のデータ構成を示す。重要度得点係数テーブル１２５は、観点重要度テーブル１２４で各セルフチェック観点に割り当てられた重要度のランクを表す重要度１２５ａ、各重要度のランクに対応させて加点、減点を計算する際の重み付けを表す得点係数を格納する得点１２５ｂのデータ項目欄を有する。

図８は、品質管理部端末１６０に表示されるツールインタフェースのメニュー画面３００の例である。品質管理部員が実行する工程を起動するために、ツールのメニュー(３０１−３０５)を選択する。

図９は、件数登録フローのフローチャートである。品質管理部員はツールインタフェース画面３００から「件数情報登録」３０１を選択（Ｓ１０）して件数登録処理を起動する。

ステップＳ１１において、品質管理部員がソフトウェア開発部より報告されたプログラムのセルフチェックの結果を登録する（または、外注のソフトウェアの納入を受けた場合には外注先からプログラムのセルフチェックの結果の報告を受けて登録する）場合は、確認箇所数登録部１１１が起動して、モジュール情報（プログラムID、規模）、およびセルフチェック結果の入力を受付ける。
また、品質管理部員がプログラムの検査(テスト)の結果を登録する場合は、不良件数登録部１１２が起動して、モジュール情報（プログラムID、規模）、および不良件数の入力を受付ける。

ステップＳ１２において、確認箇所数登録部１１１がモジュール情報、セルフチェック結果を確認箇所数テーブル１２１に登録する。
ステップＳ１３において、不良件数登録部１１２がモジュール情報、不良件数を不良件数テーブル１２２に登録する。
ステップＳ１４において、品質管理部端末１６０上にデータが登録されたことを通知する
図１３は、観点重要度、重要度得点係数設定部１１６が品質管理部による観点重要度、および重要度得点係数の設定を受付けて、観点重要度テーブル１２４、重要度得点係数テーブル１２５に登録する処理のフローチャートである。品質管理部員はツールインタフェース画面３００から「観点重要度・重要度得点係数設定」３０５を選択（Ｓ５０）して得点算出処理を起動する。

ステップＳ５１において、品質管理部員は重要度１２５ａごとに得点係数１２５ｂを設定する。特に大事にしているセルフチェック観点には優先順位を付けて、得点係数を大きくする。重要度Ｘは観点該当不良件数に掛ける得点係数を設定し、重要度Ｙは観点外不良件数に掛ける得点係数を設定する。

ステップＳ５２において、品質管理部員はセルフチェック観点１２４ａごとに重要度１２４ｂを設定する。開発時間(セルフチェック時間)が限られている中で、重要なものからチェックをしてもらいために得点係数に重みの差を設けている。セルフチェックの確認がしづらい、手間がかかるものに点数を高くする。

ステップＳ５３において、品質管理部端末１６０より入力されたデータを受付けて、観点重要度テーブル１２４、重要度得点係数テーブル１２５に登録する。

図１０は、得点算出部１１３が確認箇所数テーブル１２１、及び不良件数テーブル１２２に記録したデータを読み出して、加点、減点、総得点を算出して、得点情報テーブル１２３に登録する処理のフローチャートである。品質管理部員はツールインタフェース画面３００から「得点算出実行」３０２を選択（Ｓ２０）して得点算出処理を起動する。

ステップＳ２１において、確認箇所数テーブル１２１からセルフチェック観点ごとの担当確認箇所数、責任者確認箇所数を抽出する。
ステップＳ２２において、観点重要度テーブル１２４、重要度得点係数テーブル１２５よりセルフチェック観点ごとの重要度と得点係数を抽出する
ステップＳ２３において、確認箇所数（担当者確認箇所数と責任者確認箇所数の合算値）と、観点ごとの得点係数を掛け合わせ合算して加点(Ap)を次式(数１)で算出する。

ここで、Ap：加点、ｉ：セルフチェック観点番号(＝１〜ｎ)、Npi：セルフチェック観点ｉに関して担当者がチェックした確認箇所数、Nri：セルフチェック観点ｉに関して責任者がチェックした確認箇所数(この値は担当者がチェックした確認箇所数を責任者が後で修正した差分値が格納される)、Sfi：セルフチェック観点ｉに割り当てられた得点係数。
ステップＳ２４において、算出した加点(Ap)を得点情報テーブル１２３に登録する。
ステップＳ２５において、不良件数テーブル１２２から観点該当不良件数、観点外不良件数を抽出する。
ステップＳ２６において、重要度得点係数テーブル１２５より観点該当不良件数に対しては重要度Ｘの得点係数、及び観点外不良件数に対しては重要度Ｙの得点係数を抽出する。

ステップＳ２７において、不良件数と得点係数を掛け合わせ合算して減点(Dp)を次式(数２)で算出する。
（数２） Dp＝Ndv・Sfx＋Ndo・Sfy
ここで、Dp：減点、Ndv：観点該当不良件数、Ndo：観点外不良件数、Sfx：重要度Ｘの得点係数、Sfy：重要度Ｙの得点係数。
ステップＳ２８において、算出した減点(Dp)を得点情報テーブル１２３に登録する。

ステップＳ２９において、加点と減点を合算し総得点として得点情報テーブル１２３に登録する。
なお、不良件数テーブルが未登録でも本処理は実行可能。不良件数が０なので「減点」が０になり、実質的には加点計算のみになる。

また、品質管理部員が加点分析(後述する)結果より品質に疑いのあるプログラムの検査(テスト)の結果、不良件数を登録して本処理を実行した場合には、既に加点計算は終わっていて得点情報テーブル１２３に登録されているので、その場合には減点計算、総得点計算のみを実行する。

図１１は、加点分析部１１４が実行する加点分析処理のフローチャートを示す。品質管理部員はツールインタフェース画面３００から「加点分析実行」３０３を選択（Ｓ３０）して加点分析処理を起動する。

ステップＳ３１において、加点分析部１１４が得点情報テーブル１２３よりモジュール情報（プログラムID、規模）、加点を抽出する。

ステップＳ３２において、Ｓ３１で抽出した各プログラムごとの加点を同等に評価するために、加点を該当プログラムの規模で割った規模割加点、および抽出した全てのプログラムの規模割加点の中央値を算出する。

ステップＳ３３において、図１４に示すような加点分析結果を品質管理部端末１６０に表示する。例えば、１つのプロジェクトに係る全てのプログラムのセルフチェック結果から算出した加点のデータを、プログラムの規模で割って算出した規模割加点４０１を添えて、全てのプログラムごとのデータを配列する。

各プログラムのセルフチェックを担当する担当者、および責任者が忠実に責務を果たしたと仮定するならば、各プログラムの規模に応じた確認箇所数が報告され、それらの確認箇所数から算出される加点も各プログラムの規模に応じた値となる。それらの加点を同等に評価するために、加点を該当プログラムの規模で割った規模割加点で表すと、多少の誤差、ばらつきの範囲で、各プログラムの規模割加点が近い値を示すことがこれまでの経験から分かっている。もし、規模割加点の値が他のプログラムの規模割加点の値と比較して、極端に小さい値を示す場合は、担当者がセルフチェックの理解度が低く、セルフチェックが適正に行われておらず、確認箇所数が少なく報告されていることが考えられる。
また、規模割加点の値が他のプログラムの規模割加点の値と比較して、極端に大きな値を示す場合は、担当者がセルフチェックを誤って理解して、間違った確認箇所数を多く報告したか、確認箇所数を虚偽の報告をしたなどが考えられる。いずれの場合にも、プログラムの品質は低いことが予想される。よって、加点分析結果では、全プログラムの規模割加点の値の中央値４０２を算出して表示する。この規模割加点中央値から、上下に所定値以上に外れた規模割加点を持つプログラムは品質が低いと予測して、品質管理部の検査(テスト)の対象とする。さらに、規模割加点４０１とその中央値４０２から、品質予測を品質管理装置１００で算出して表示させてもよい。

この例では、プログラムごとに分析を行っているが、担当者または責任者(担当者のグループ)ごとに加点分析を行ってもよい。適切な確認箇所数はプログラムに依存することがあり、規模割加点４０１にある程度のばらつきが出てしまう。一方で、一つの開発プロジェクトに含まれるプログラム同士では規模割加点は近い値になっていると考えられ、また品質は担当者やそのグループごとに依存すると考えられる。そのため、担当者やそのグループごとの品質が、規模割加点に反映されやすいと考えられる。

図１１のステップＳ３３に戻り、加点分析部１１４は、加点分析結果を記憶部１２０の加点分析結果記憶領域１２６に記録する。
ステップＳ３４において、加点分析部１１４は、加点分析結果を出力部１３０より帳票に出力する。

図１２は、減点分析部１１５が実行する減点分析処理のフローチャートを示す。品質管理部員はツールインタフェース画面３００から「減点分析実行」３０４を選択（Ｓ４０）して減点分析処理を起動する。

ステップＳ４１において、減点分析部１１５が得点情報テーブル１２３よりモジュール情報（プログラムID、規模）、総得点を抽出する。

ステップＳ４２において、Ｓ４１で抽出した担当者ごとの総得点を同等に評価するために、総得点を該当プログラムの規模で割った担当者別規模割総得点、全ての担当者の規模割総得点中央値４０４を算出する。

ステップＳ４３において、図１５に示すような減点分析結果を品質管理部端末１６０に表示する。例えば、１つのプロジェクトに係る全ての開発担当者がセルフチェックをした結果より算出した加点と、および品質管理部が検査(テスト)を実施した結果より判明した不良数より算出した減点とを総計した総得点を担当者別に集計して、更に担当者別の総得点を該当プログラムの規模で割って算出した規模割総得点４０３を算出して、規模割総得点４０３が大きいもの順に担当者を配列することが考えられる。担当者別に代えて、責任者別（担当者のグループ別）に集計してもよい。

この規模割総得点４０３が大きい担当者の方が、開発したプログラムの品質は高いと評価できる。加点分析において、品質が高い担当者はセルフチェックの確認箇所数も多い（適切）し、不良が少ないからである。セルフチェックの確認箇所数に虚偽申告を行った場合、加点分析にて品質が疑われ、品質管理部が検査を行って不良が判明し、減点されるからである。また、プログラムの不良が少なくても、セルフチェックの確認箇所数に不正の意図を感じるほど大きくずれている場合、減点等のペナルティを課してもよい。

図１２のステップＳ４３において、減点分析部１１５は、減点分析結果を記憶部１２０の減点分析結果記憶領域１２７に記録する。
ステップＳ４４において、減点分析部１１５は、減点分析結果を出力部１３０より帳票に出力する。

システム開発では、プログラム規模あたりで発生する確認箇所数（チェックリストで担当者、責任者が定義する）は大きく変動しないことを本発明では前提としている。したがって、プログラム規模あたりの確認箇所数を評価し、その値が大きくずれている場合には、担当者の理解度が低い、セルフチェックが不適当ということが考えられ、従ってプログラム品質も低いことが予想される。

プログラムによっては品質が高いが、プログラムの性質から、加点分析結果において規模割加点の値が規模割加点の値の中央値４０２から数値がずれるものもあると考えられるが、品質が疑われるプログラムを品質管理者が実際に検査(テスト)で不良チェックを行うに際して、不良チェック対象プログラムを決める目安にはなる。品質が高いプログラムは不良が少なく、減点が少なくなる。

図１５において、規模割総得点を高くするには、１）適切にセルフチェックを行い適切な確認箇所数を記入し、２）不良を少なくする、ということが有効である。ランキング形式で記載し、これを各開発担当者に公開することで、各担当者の意識を向上させる。担当者は、開発作業をきちんと理解し、きちんとセルフチェックを報告し、不良の少ないプログラムを作成することで、品質が向上する。

本実施例によれば、他社に外注したプログラムの受入れ検査をする場合に、他社から報告されるセルフチェック結果を用いて、どのサンプルプログラムを受入れ検証すべきかを、受入れ品の品質を受け入れ前に目安を付けることができる。

本実施例によれば、システム開発担当者は、プログラムの品質のみならずセルフチェック自体の品質も可視化されるため、プログラムおよびセルフチェックの品質マインドが向上すると考えられる。これによって、各プログラムを合わせての試験より前に不良を低減して、試験開始後の進捗遅れを防止することができる。また、各担当者のプログラム作成時点で、品質を含めた進捗を管理できるため、遅延リスクを抽出して対策することができる。また、品質を見える化することで、担当者の品質意識を向上させることができる。

本実施例では、ソフトウェアの品質、およびソフトウェアのセルフチェックの品質を可視化して、管理する方法とその装置を説明しているが、ソフトウェアに限らずに、ハードウェアも含めて一般のプロダクトを製造する上で、作業手順通りにやったかどうか、作業手順の良し悪しを管理する手法に適用できると考えられる。
その場合のセルフチェック観点としては、プロダクトの特定の機能をチェックするというのではなく、なるべく普遍的な共通の機能をチェックするようなセルフチェック観点を採用することが本実施例の有効性を出せる条件と考えられる。

実施例１では、加点計算に際し、担当者の確認箇所数と責任者の確認箇所数の両方を用いた計算を行っている。すなわち、責任者のレビューが終わった時点でのソフトウェアの品質を評価している（担当者と責任者の評価を行っている。ただし、責任者がレビューを行わない場合が多数あり、責任者の確認箇所数が無い場合には、担当者のみの評価となる）。実施例２では、担当者の確認箇所数のみで加点計算を行う。これによって、担当者の評価を行うことができる。有能な担当者は加点が妥当な値になり、理解が少なかったり、ごまかしを行った場合には、加点数値が少なくなったり多くなったりする。

実施例２の変更案として、責任者の確認箇所数のみを用いて、加点計算を行ってもよい。この場合、責任者の確認箇所数は担当者の確認箇所数からの差分であり、その絶対値が大きいほど責任者が修正した値が大きいということになる。加点計算には、責任者の確認箇所数の絶対値を用いる。加点が大きいほど、責任者の役割が大きいということになる。ただし、担当者が有能であれば責任者の修正は少なくなる点には考慮が必要であり、たとえば、担当者の能力を考慮して評価するなどが必要になる。

１００ 品質管理装置
１１０ 演算部
１１１ 確認箇所数登録部
１１２ 不良件数登録部
１１３ 得点算出部
１１４ 加点分析部
１１５ 減点分析部
１１６ 観点重要度、重要度得点係数設定部
１２０ 記憶部
１２１ 確認箇所数記憶領域（確認箇所数テーブル）
１２２ 不良件数記憶領域（不良件数テーブル）
１２３ 得点情報記憶領域（得点情報テーブル）
１２４ 観点重要度記憶領域（観点重要度テーブル）
１２５ 重要度得点係数記憶領域（重要度得点係数テーブル）
１２６ 加点分析結果記憶領域
１２７ 減点分析結果記憶領域
１３０ 出力部
１４０ 通信部
１５０ ネットワーク
１６０ 品質管理部端末
１７０ 開発部端末
２００ セルフチェックリスト
２０１ チェック項目（セルフチェック観点）
２０２ 担当者確認箇所数
３００ ツールインタフェースのメニュー画面
３０１ ツールのメニュー「件数情報登録」
３０２ ツールのメニュー「得点算出実行」
３０３ ツールのメニュー「加点分析実行」
３０４ ツールのメニュー「減点分析実行」
３０５ ツールのメニュー「観点重要度・重要度得点係数設定」
４０１ 規模割加点
４０２ 規模割加点中央値
４０３ 規模割総得点
４０４ 規模割総得点中央値

Claims (8)

1. 計算機を用いてソフトウェアの品質を管理する方法であって、
   ソフトウェアにかかる確認箇所数を含むセルフチェック結果を取得する工程と、
   前記セルフチェック結果に基づいて、前記ソフトウェアの品質を算出する分析工程と、
   を含み、
   前記セルフチェック結果には、ソフトウェアの規模が含まれており、
   前記分析工程では、前記ソフトウェア規模と前記確認箇所数とに基づいて、ソフトウェア品質を算出することを特徴とする品質管理方法。
2. 請求項１において、
   前記ソフトウェアの不良件数を含む品質チェック結果を取得する工程と、を含み、
   前記分析工程では、前記ソフトウェアの規模と、前記確認箇所数と、品質チェック結果とに基づいて、得点を算出し、当該得点に基づくランキングを出力することを特徴とする品質管理方法。
3. 請求項１において、
   前記確認箇所数は、複数のセルフチェック観点に基づく複数の確認箇所数を含んでおり、
   前記複数の確認箇所数を、セルフチェック観点ごとに定められた重みづけを行って加点数値を算出し、
   前記加点数値と前記ソフトウェア規模とを比較して、ソフトウェア品質を算出することを特徴とする品質管理方法。
4. 請求項３において、
   前記ソフトウェアの不良件数を含む品質チェック結果を取得する工程と、を含み、
   前記品質チェック結果に含まれる不良件数に対して定められた重みづけを行って減点数値を算出し、
   前記加点数値と前記減点数値とを総計して総得点を算出し、
   前記総得点と前記ソフトウェア規模とを比較して、開発担当者のソフトウェア品質を算出することを特徴とする品質管理方法。
5. 請求項３において、
   前記確認箇所数には、開発担当者の確認箇所数と責任者の確認箇所数とが含まれていることを特徴とする品質管理方法。
6. 請求項５において、
   前記開発担当者の確認箇所数と責任者の確認箇所数の差分に基づいて、得点を算出してランキングを出力することを特徴とする品質管理方法。
7. 計算機を用いてソフトウェアの品質を管理する装置であって、
   ソフトウェアにかかるセルフチェック結果の確認箇所数を取得する確認箇所数取得部と、
   前記セルフチェック結果の確認箇所数と前記ソフトウェアの規模とを比較して、ソフトウェア品質を算出する分析部とを備えることを特徴とする品質管理装置。
8. 請求項７において、
   前記ソフトウェアの不良件数を含む品質チェック結果を取得する不良件数取得部と、を備え、
   前記分析部は、前記ソフトウェアの規模と、前記確認箇所数と、不良件数とに基づいて、得点を算出し、当該得点に基づくランキングを出力することを特徴とする品質管理装置。

Images