特許第6919980号(P6919980)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

<>
  • 特許6919980-品質管理方法および品質管理装置 図000003
  • 特許6919980-品質管理方法および品質管理装置 図000004
  • 特許6919980-品質管理方法および品質管理装置 図000005
  • 特許6919980-品質管理方法および品質管理装置 図000006
  • 特許6919980-品質管理方法および品質管理装置 図000007
  • 特許6919980-品質管理方法および品質管理装置 図000008
  • 特許6919980-品質管理方法および品質管理装置 図000009
  • 特許6919980-品質管理方法および品質管理装置 図000010
  • 特許6919980-品質管理方法および品質管理装置 図000011
  • 特許6919980-品質管理方法および品質管理装置 図000012
  • 特許6919980-品質管理方法および品質管理装置 図000013
  • 特許6919980-品質管理方法および品質管理装置 図000014
  • 特許6919980-品質管理方法および品質管理装置 図000015
  • 特許6919980-品質管理方法および品質管理装置 図000016
  • 特許6919980-品質管理方法および品質管理装置 図000017
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6919980
(24)【登録日】2021年7月28日
(45)【発行日】2021年8月18日
(54)【発明の名称】品質管理方法および品質管理装置
(51)【国際特許分類】
   G06F 8/70 20180101AFI20210805BHJP
【FI】
   G06F8/70
【請求項の数】4
【全頁数】16
(21)【出願番号】特願2017-34345(P2017-34345)
(22)【出願日】2017年2月27日
(65)【公開番号】特開2018-142048(P2018-142048A)
(43)【公開日】2018年9月13日
【審査請求日】2020年1月16日
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001689
【氏名又は名称】青稜特許業務法人
(72)【発明者】
【氏名】羽田 達哉
(72)【発明者】
【氏名】中山 仁
(72)【発明者】
【氏名】床 直紀
【審査官】 渡辺 順哉
(56)【参考文献】
【文献】 特開2000−056961(JP,A)
【文献】 特開平09−319611(JP,A)
【文献】 特開2013−109403(JP,A)
【文献】 特開2007−265005(JP,A)
【文献】 特開2012−027761(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 8/00−8/77
G06F 9/44−9/445
(57)【特許請求の範囲】
【請求項1】
計算機を用いてソフトウェアの品質を管理する方法であって、
ソフトウェアの開発の各担当者が、ソフトウェアの作成時に、セルフチェックリストに従って、各セルフチェック観点ごとに、チェック内容に該当する対象プログラムのステートメント、または識別子ごとに、確認箇所数としてカウントして、報告したセルフチェック結果を取得して、登録する工程と、
前記セルフチェック結果に基づいて、各セルフチェック観点ごとの確認箇所数と、セルフチェック観点の重要度を表す得点係数を掛けて、合算して、ソフトウェアごとの加点を算出する工程と、
前記ソフトウェアごとの加点を、ソフトウェアの規模で割った規模割加点を算出する工程と、
各対象ソフトウェアごとの少なくとも担当者、加点、および規模割加点の一覧を表示するとともに、規模割加点中央値を算出して表示する加点分析工程と、
前記加点分析工程で表示された加点分析結果の一覧において、規模割加点中央値から上下に所定値以上に外れた規模割加点を持つソフトウェアは品質が低いと予測して、検査(テスト)の対象として品質管理部へ送り、検査(テスト)完了後、検査結果を取得する工程と、
前記検査結果のうち、各ソフトウェアの不良数を、セルフチェック観点に該当する不良の数を観点該当不良件数、セルフチェック観点に該当しない不良の数を観点外不良件数として登録する工程と、
各ソフトウェアの観点該当不良件数、および観点外不良件数に対して、それぞれ対応する得点係数を掛け合わせて合算して減点を算出して、登録する工程と、
登録されている各ソフトウェアの加点と減点を合算して総得点として登録する工程と、
前記各ソフトウェアの担当者ごとの総得点を、ソフトウェアの規模で割った担当者別規模割総得点を算出する工程と、
各担当者ごとの少なくとも総得点、および規模割総得点の一覧を表示するとともに、規模割総得点中央値を算出して表示する減点分析工程と、
を有することを特徴とする品質管理方法。
【請求項2】
請求項1において、
前記ソフトウェアの開発の各担当者が、各セルフチェック観点ごとに、確認箇所数をカウントして報告するのとは別に、責任者が、同じセルフチェックリストに従って、各セルフチェック観点ごとに確認箇所数をカウントして、報告したセルフチェック結果を取得して、責任者がチェックした確認箇所数から担当者確認箇所数を引いた差分を責任者確認箇所数として登録する工程を更に有し、
前記ソフトウェアごとの加点を算出する工程では、各セルフチェック観点ごとの担当者確認箇所数と責任者確認箇所数との合計に得点係数を掛けて、合算して、ソフトウェアごとの加点を算出することを特徴とする品質管理方法。
【請求項3】
計算機を用いてソフトウェアの品質を管理する装置であって、
ソフトウェアの開発の各担当者が、ソフトウェアの作成時に、セルフチェックリストに従って、各セルフチェック観点ごとに、チェック内容に該当する対象プログラムのステートメント、または識別子ごとに、確認箇所数としてカウントして、報告したセルフチェック結果を取得して、登録する確認箇所数登録部と、
前記セルフチェック結果に基づいて、各セルフチェック観点ごとの確認箇所数と、セルフチェック観点の重要度を表す得点係数を掛けて、合算して、ソフトウェアごとの加点を算出して登録する得点算出部と、
前記ソフトウェアごとの加点を、ソフトウェアの規模で割った規模割加点を算出し、各対象ソフトウェアごとの少なくとも担当者、加点、および規模割加点の一覧を表示するとともに、規模割加点中央値を算出して表示する加点分析部と、
前記加点分析部で表示された加点分析結果の一覧において、規模割加点中央値から上下に所定値以上に外れた規模割加点を持つソフトウェアは品質が低いと予測して、検査(テスト)の対象として品質管理部へ送り、検査(テスト)完了後、検査結果を取得し、前記検査結果のうち、各ソフトウェアの不良数を、セルフチェック観点に該当する不良の数を観点該当不良件数、セルフチェック観点に該当しない不良の数を観点外不良件数として登録する不良件数登録部と、
前記得点算出部は、更に、各ソフトウェアの観点該当不良件数、および観点外不良件数に対して、それぞれ対応する得点係数を掛け合わせて合算して減点を算出して、登録し、登録されている各ソフトウェアの加点と減点を合算して総得点として登録を行い、
前記各ソフトウェアの担当者ごとの総得点を、ソフトウェアの規模で割った担当者別規模割総得点を算出し、各担当者ごとの少なくとも総得点、および規模割総得点の一覧を表示するとともに、規模割総得点中央値を算出して表示する減点分析部と、
を備えることを特徴とする品質管理装置。
【請求項4】
請求項において、
前記確認箇所数登録部は、前記ソフトウェアの開発の各担当者が、各セルフチェック観点ごとに、確認箇所数をカウントして報告するのとは別に、責任者が、同じセルフチェックリストに従って、各セルフチェック観点ごとに確認箇所数をカウントして、報告したセルフチェック結果を取得して、責任者がチェックした確認箇所数から担当者確認箇所数を引いた差分を責任者確認箇所数として更に登録し、
前記得点算出部は、各セルフチェック観点ごとの担当者確認箇所数と責任者確認箇所数との合計に得点係数を掛けて、合算して、ソフトウェアごとの加点を算出することを特徴とする品質管理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、システム開発の品質の管理に関する。
【背景技術】
【0002】
ソフトウェア開発のプロジェクトにおいては、開発を各担当者に分担しておこなう。各担当者が開発したプログラムを合わせて試験を行い、不良がないかプログラムを実機上で稼働させて試験を行い、不良がなかった場合にはユーザに提供を行う。試験において不良があった場合には、不良個所を特定し修正する。
【0003】
プログラムを稼働させて初めてわかる不良もあるが、プログラム自体を注意深く読むことでわかる不良もある。そのため、各担当者は、自身が担当したタスクに対し、セルフチェックリストを用いてセルフチェックを行い、不良を低減させることが行われている。
【0004】
プログラムに対するレビュー作業は、主にコンパイラが行う構文チェックや文法チェックでは検出できないエラーを発見して取り除くことを目的としており、人手によるソースプログラムの目視チェックが主体となる。特許文献1に開示される発明は、コンパイラでは検出されないエラーを起こす可能性のあるステートメントや識別子を自動検出することによって、人手による手間を軽減するレビュー支援システムを提案している。
【0005】
特許文献1に開示される発明では、チェック項目にマッチしたステートメントや識別子を予め定義しておけば、該当するステートメントや識別子をソースプログラムから検索して、該当するソースプログラム内容をその周辺の内容とともにユーザに提示してくれるので、ユーザはソースプログラム全体を見る労力が軽減される。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2005−190330号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、ソフトウェア開発のプロジェクトの多くの開発担当者のスキルには一般にバラツキがあり、セルフチェックへの理解度が低かったり、品質マインドが低い担当者の場合には、従来のチェックをした項目の有無(チェック印)を記入するチェックリストでは、虚偽の記載が含まれていた際に、それによって引き起こされるエラー(バグ)の検出には時間が掛かるなど難しい。
【0008】
特に、大規模開発で短期間のソフトウェア開発では大量の開発要員を一気に集めるため、要員ごとの品質マインドやスキルにバラツキがある。品質マインドやスキルが低い開発要員はプロセスを適切に実施することが出来ず、開発したソフトウェアの品質は悪い。ソフトウェア開発の納期遅延のリスク、コストが増えるリスクを減らすためには、プログラムの実機テスト段階前に、各担当者のセルフチェック後のソフトウェア品質をなるべく揃えられることが重要である。
【0009】
本発明は、このような課題を考慮してなされたものであり、セルフチェック結果を用いてソフトウェア品質を管理することを目的とする。
【課題を解決するための手段】
【0010】
上記課題を解決するために本発明の品質管理方法は、計算機を用いてソフトウェアの品質を管理する方法であって、ソフトウェアにかかる確認箇所数を含むセルフチェック結果を取得する工程と、前記セルフチェック結果に基づいて、前記ソフトウェアの品質を算出する分析工程とを含み、前記セルフチェック結果には、ソフトウェアの規模が含まれており、前記分析工程では、前記ソフトウェア規模と前記確認箇所数とに基づいて、ソフトウェア品質を算出するように構成する。
また、本発明の他の特徴として、前記品質管理方法において、前記ソフトウェアの不良件数を含む品質チェック結果を取得する工程とを含み、前記分析工程では、前記ソフトウェアの規模と、前記確認箇所数と、品質チェック結果とに基づいて、得点を算出し、当該得点に基づくランキングを出力する。
【発明の効果】
【0011】
本発明によれば、セルフチェック結果を用いてソフトウェア品質を算出することができる。
【図面の簡単な説明】
【0012】
図1】品質管理装置の構成図の例である。
図2】セルフチェックリストの例である。
図3】確認箇所数テーブルのデータ構成を示す図である。
図4】不良件数テーブルのデータ構成を示す図である。
図5】得点情報テーブルのデータ構成を示す図である。
図6】観点重要度テーブルのデータ構成を示す図である。
図7】重要度得点係数テーブルのデータ構成を示す図である。
図8】ツールインタフェースのメニュー画面の例である。
図9】件数登録フローのフローチャートである。
図10】得点算出フローのフローチャートである。
図11】加点分析処理のフローチャートである。
図12】減点分析処理のフローチャートである。
図13】観点重要度、重要度得点係数設定処理のフローチャートである。
図14】加点分析結果を品質管理部端末に表示した画面例である。
図15】減点分析結果を品質管理部端末に表示した画面例である。
【発明を実施するための形態】
【0013】
発明の好ましい例では、ソフトウェア開発の各担当者に、図2に例示するセルフチェックリスト200に従って、各チェック項目201ごとに、チェック内容に該当する対象プログラムのステートメント、または識別子ごとに、確認箇所数202としてカウントして、セルフチェック終了時に報告させる。これは、従来のセルフチェックでは、各チェック項目201ごとに対象プログラムのチェックをしたらチェック済みの意味で印を付けて報告する方式では、例えば、あるチェック項目に該当する箇所が12箇所あったとして、担当者が全ての該当箇所をチェックしたとしても、またはその内10箇所しかチェックしないで残りの2箇所は見逃したとしても、同じチェック済みの報告しか分からなかった問題点を改善するものである。
【0014】
すなわち、発明の好ましい例では、各担当者にセルフチェックリスト200の各チェック項目201(以降、セルフチェック観点と称する)ごとに、確認箇所数202を報告させることにより、各担当者によるセルフチェック後のソフトウェア品質を推定するための指標に役立てることを提案する。
【0015】
発明の好ましい例で採用するセルフチェック観点201は、対象プログラムの規模(step数など)の大小に関わらず確認箇所数が1、または固定数ではなく、対象プログラムの規模の増大につれて概ね線形に確認箇所数が増大する傾向を持つ。そのような傾向を有するセルフチェック観点を複数まとめたセルフチェックリストを作成して、ソフトウェア開発部へ提供して、セルフチェック時にセルフチェック観点ごとに確認箇所数をカウントして報告する。
【0016】
以下、実施例を図面を用いて説明する。
【実施例1】
【0017】
図1は、ソフトウェア開発部より報告されるプログラムのセルフチェックの確認箇所数を入力として、当該プログラムの品質を推定する指標を出力する品質管理装置100の構成図の例である。
【0018】
品質管理装置100は計算機(サーバ)上に構成することができて、そのハードウェア構成は、CPU(Central Processing Unit)などにより構成される演算部110と、HDD(Hard Disk Drive)、フラッシュメモリなどを用いたSSD(Solid State Drive)などにより構成される記憶部120と、各種出力装置などにより構成される出力部130と、NIC(Network Interface Card)などにより構成される通信部140などを備える。
通信部140は、ネットワーク150を介して複数の品質管理部端末160、複数の開発部端末170と接続されている。
【0019】
演算部110は、記憶部120に記憶されている品質管理プログラム(図示せず)をロードしてCPUで実行することにより以下の各機能部を実現する。
確認箇所数登録部111は、品質管理部員が品質管理部端末160から入力したプログラム別のセルフチェック観点ごとの確認箇所数を受付けて、記憶部120の確認箇所数記憶領域121に記録する。または、ソフトウェア開発部の担当者がセルフチェック後に自らの開発部端末170より報告した確認箇所数を受付けて、確認箇所数記憶領域121に記録することでもよい。
【0020】
不良件数登録部112は、品質管理部員が加点分析(後述する)結果より品質に疑いのあるプログラムの検査(テスト)の結果、または外注品のプログラムの受入れ検査の結果より、不良と判明した件数を入力したデータを受付けて、記憶部120の不良件数記憶領域122に記録する。
【0021】
得点算出部113は、確認箇所数記憶領域121、及び不良件数記憶領域122に記録したデータを読み出して、セルフチェック観点別の重要度から決められた得点係数(後述する)を乗じて、加点(後述する)、減点(後述する)、総得点(後述する)を算出して、記憶部120の得点情報記憶領域123に記録する。
【0022】
加点分析部114は、得点情報記憶領域123に記録した加点を読み出して、規模割りの加点を算出して、規模割り加点の大小にて順位を付けた加点分析結果を作成して、品質管理部端末160へ表示すると共に、記憶部120の加点分析結果記憶領域126に記録する。また、出力部130より加点分析結果を帳票に出力する。
【0023】
減点分析部115は、得点情報記憶領域123に記録した総得点を読み出して、担当者ごとに総得点を集計して、規模割りの総得点を算出して、規模割り総得点の大小にて担当者に順位を付けた減点分析結果を作成して、品質管理部端末160へ表示すると共に、記憶部120の減点分析結果記憶領域127に記録する。また、出力部130より減点分析結果を帳票に出力する。
【0024】
観点重要度、重要度得点係数設定部116は、品質管理部員が品質管理部端末160より、予めセルフチェック観点ごとの重要度、及び重要度ごとの得点係数を入力する設定を受付けて、記憶部120の観点重要度記憶領域124、及び重要度得点係数記憶領域125に記録する。
【0025】
記憶部120は、確認箇所数121、不良件数122、得点情報123、観点重要度124、重要度得点係数125、加点分析結果126、減点分析結果127の各情報を記憶する記憶領域を有する。
【0026】
図3は、確認箇所数テーブル121のデータ構成を示す。確認箇所数テーブル121のデータ項目欄である管理番号121aは記録するプログラム単位に付けたデータレコードの管理番号であり、担当者氏名121bはプログラムの開発担当者氏名であり、責任者氏名121cは担当者のリーダであり、開発回次121dはプロジェクトにおける開発ロットを表わす開発単位であり、プログラムID121eはプログラム固有の識別名称であり、開発規模121fは開発プログラムのstep数などであり、担当確認箇所数1(121g)はセルフチェック観点1に関して担当者がチェックした確認箇所数であり、責任者確認箇所数1(121h)はセルフチェック観点1に関して責任者がチェックした確認箇所数から担当確認箇所数1を引いた差分であり、担当確認箇所数n(121k)はセルフチェック観点nに関して担当者がチェックした確認箇所数であり、責任者確認箇所数n(121l)はセルフチェック観点nに関して責任者がチェックした確認箇所数から担当確認箇所数nを引いた差分である。
【0027】
図4は、不良件数テーブル122のデータ構成を示す。不良件数テーブル122は、管理番号122a、担当者氏名122b、責任者氏名122c、開発回次122d、プログラムID122e、開発規模122f、品質管理部によるプログラムの検査(テスト)の結果、セルフチェック観点に該当する不良を新たに発見した件数を格納する観点該当不良件数122g、品質管理部によるプログラムの検査(テスト)の結果、セルフチェック観点に該当しない不良を新たに発見した件数を格納する観点外不良件数122h、などのデータ項目欄を有する。
【0028】
図5は、得点情報テーブル123のデータ構成を示す。得点情報テーブル123は、管理番号123a、担当者氏名123b、責任者氏名123c、開発回次123d、プログラムID123e、開発規模123f、確認箇所数テーブル121からデータを読み出しプログラムに対する担当者(および責任者)のセルフチェックの結果の評価点を格納する加点123g、品質管理部によるプログラムの検査(テスト)の結果発見された不良に伴うマイナスの評価点を格納する減点123h、加点と減点から算出する総得点123i、などのデータ項目欄を有する。
【0029】
図6は、観点重要度テーブル124のデータ構成を示す。観点重要度テーブル124は、セルフチェック観点の識別番号を表す観点番号124a、該当セルフチェック観点に関するセルフチェックに割り当てられた重要度のランクを表す重要度124bのデータ項目欄を有する。
【0030】
図7は、重要度得点係数テーブル125のデータ構成を示す。重要度得点係数テーブル125は、観点重要度テーブル124で各セルフチェック観点に割り当てられた重要度のランクを表す重要度125a、各重要度のランクに対応させて加点、減点を計算する際の重み付けを表す得点係数を格納する得点125bのデータ項目欄を有する。
【0031】
図8は、品質管理部端末160に表示されるツールインタフェースのメニュー画面300の例である。品質管理部員が実行する工程を起動するために、ツールのメニュー(301−305)を選択する。
【0032】
図9は、件数登録フローのフローチャートである。品質管理部員はツールインタフェース画面300から「件数情報登録」301を選択(S10)して件数登録処理を起動する。
【0033】
ステップS11において、品質管理部員がソフトウェア開発部より報告されたプログラムのセルフチェックの結果を登録する(または、外注のソフトウェアの納入を受けた場合には外注先からプログラムのセルフチェックの結果の報告を受けて登録する)場合は、確認箇所数登録部111が起動して、モジュール情報(プログラムID、規模)、およびセルフチェック結果の入力を受付ける。
また、品質管理部員がプログラムの検査(テスト)の結果を登録する場合は、不良件数登録部112が起動して、モジュール情報(プログラムID、規模)、および不良件数の入力を受付ける。
【0034】
ステップS12において、確認箇所数登録部111がモジュール情報、セルフチェック結果を確認箇所数テーブル121に登録する。
ステップS13において、不良件数登録部112がモジュール情報、不良件数を不良件数テーブル122に登録する。
ステップS14において、品質管理部端末160上にデータが登録されたことを通知する
図13は、観点重要度、重要度得点係数設定部116が品質管理部による観点重要度、および重要度得点係数の設定を受付けて、観点重要度テーブル124、重要度得点係数テーブル125に登録する処理のフローチャートである。品質管理部員はツールインタフェース画面300から「観点重要度・重要度得点係数設定」305を選択(S50)して得点算出処理を起動する。
【0035】
ステップS51において、品質管理部員は重要度125aごとに得点係数125bを設定する。特に大事にしているセルフチェック観点には優先順位を付けて、得点係数を大きくする。重要度Xは観点該当不良件数に掛ける得点係数を設定し、重要度Yは観点外不良件数に掛ける得点係数を設定する。
【0036】
ステップS52において、品質管理部員はセルフチェック観点124aごとに重要度124bを設定する。開発時間(セルフチェック時間)が限られている中で、重要なものからチェックをしてもらいために得点係数に重みの差を設けている。セルフチェックの確認がしづらい、手間がかかるものに点数を高くする。
【0037】
ステップS53において、品質管理部端末160より入力されたデータを受付けて、観点重要度テーブル124、重要度得点係数テーブル125に登録する。
【0038】
図10は、得点算出部113が確認箇所数テーブル121、及び不良件数テーブル122に記録したデータを読み出して、加点、減点、総得点を算出して、得点情報テーブル123に登録する処理のフローチャートである。品質管理部員はツールインタフェース画面300から「得点算出実行」302を選択(S20)して得点算出処理を起動する。
【0039】
ステップS21において、確認箇所数テーブル121からセルフチェック観点ごとの担当確認箇所数、責任者確認箇所数を抽出する。
ステップS22において、観点重要度テーブル124、重要度得点係数テーブル125よりセルフチェック観点ごとの重要度と得点係数を抽出する
ステップS23において、確認箇所数(担当者確認箇所数と責任者確認箇所数の合算値)と、観点ごとの得点係数を掛け合わせ合算して加点(Ap)を次式(数1)で算出する。
【0040】
【数1】
【0041】
ここで、Ap:加点、i:セルフチェック観点番号(=1〜n)、Npi:セルフチェック観点iに関して担当者がチェックした確認箇所数、Nri:セルフチェック観点iに関して責任者がチェックした確認箇所数(この値は担当者がチェックした確認箇所数を責任者が後で修正した差分値が格納される)、Sfi:セルフチェック観点iに割り当てられた得点係数。
ステップS24において、算出した加点(Ap)を得点情報テーブル123に登録する。
ステップS25において、不良件数テーブル122から観点該当不良件数、観点外不良件数を抽出する。
ステップS26において、重要度得点係数テーブル125より観点該当不良件数に対しては重要度Xの得点係数、及び観点外不良件数に対しては重要度Yの得点係数を抽出する。
【0042】
ステップS27において、不良件数と得点係数を掛け合わせ合算して減点(Dp)を次式(数2)で算出する。
(数2) Dp=Ndv・Sfx+Ndo・Sfy
ここで、Dp:減点、Ndv:観点該当不良件数、Ndo:観点外不良件数、Sfx:重要度Xの得点係数、Sfy:重要度Yの得点係数。
ステップS28において、算出した減点(Dp)を得点情報テーブル123に登録する。
【0043】
ステップS29において、加点と減点を合算し総得点として得点情報テーブル123に登録する。
なお、不良件数テーブルが未登録でも本処理は実行可能。不良件数が0なので「減点」が0になり、実質的には加点計算のみになる。
【0044】
また、品質管理部員が加点分析(後述する)結果より品質に疑いのあるプログラムの検査(テスト)の結果、不良件数を登録して本処理を実行した場合には、既に加点計算は終わっていて得点情報テーブル123に登録されているので、その場合には減点計算、総得点計算のみを実行する。
【0045】
図11は、加点分析部114が実行する加点分析処理のフローチャートを示す。品質管理部員はツールインタフェース画面300から「加点分析実行」303を選択(S30)して加点分析処理を起動する。
【0046】
ステップS31において、加点分析部114が得点情報テーブル123よりモジュール情報(プログラムID、規模)、加点を抽出する。
【0047】
ステップS32において、S31で抽出した各プログラムごとの加点を同等に評価するために、加点を該当プログラムの規模で割った規模割加点、および抽出した全てのプログラムの規模割加点の中央値を算出する。
【0048】
ステップS33において、図14に示すような加点分析結果を品質管理部端末160に表示する。例えば、1つのプロジェクトに係る全てのプログラムのセルフチェック結果から算出した加点のデータを、プログラムの規模で割って算出した規模割加点401を添えて、全てのプログラムごとのデータを配列する。
【0049】
各プログラムのセルフチェックを担当する担当者、および責任者が忠実に責務を果たしたと仮定するならば、各プログラムの規模に応じた確認箇所数が報告され、それらの確認箇所数から算出される加点も各プログラムの規模に応じた値となる。それらの加点を同等に評価するために、加点を該当プログラムの規模で割った規模割加点で表すと、多少の誤差、ばらつきの範囲で、各プログラムの規模割加点が近い値を示すことがこれまでの経験から分かっている。もし、規模割加点の値が他のプログラムの規模割加点の値と比較して、極端に小さい値を示す場合は、担当者がセルフチェックの理解度が低く、セルフチェックが適正に行われておらず、確認箇所数が少なく報告されていることが考えられる。
また、規模割加点の値が他のプログラムの規模割加点の値と比較して、極端に大きな値を示す場合は、担当者がセルフチェックを誤って理解して、間違った確認箇所数を多く報告したか、確認箇所数を虚偽の報告をしたなどが考えられる。いずれの場合にも、プログラムの品質は低いことが予想される。よって、加点分析結果では、全プログラムの規模割加点の値の中央値402を算出して表示する。この規模割加点中央値から、上下に所定値以上に外れた規模割加点を持つプログラムは品質が低いと予測して、品質管理部の検査(テスト)の対象とする。さらに、規模割加点401とその中央値402から、品質予測を品質管理装置100で算出して表示させてもよい。
【0050】
この例では、プログラムごとに分析を行っているが、担当者または責任者(担当者のグループ)ごとに加点分析を行ってもよい。適切な確認箇所数はプログラムに依存することがあり、規模割加点401にある程度のばらつきが出てしまう。一方で、一つの開発プロジェクトに含まれるプログラム同士では規模割加点は近い値になっていると考えられ、また品質は担当者やそのグループごとに依存すると考えられる。そのため、担当者やそのグループごとの品質が、規模割加点に反映されやすいと考えられる。
【0051】
図11のステップS33に戻り、加点分析部114は、加点分析結果を記憶部120の加点分析結果記憶領域126に記録する。
ステップS34において、加点分析部114は、加点分析結果を出力部130より帳票に出力する。
【0052】
図12は、減点分析部115が実行する減点分析処理のフローチャートを示す。品質管理部員はツールインタフェース画面300から「減点分析実行」304を選択(S40)して減点分析処理を起動する。
【0053】
ステップS41において、減点分析部115が得点情報テーブル123よりモジュール情報(プログラムID、規模)、総得点を抽出する。
【0054】
ステップS42において、S41で抽出した担当者ごとの総得点を同等に評価するために、総得点を該当プログラムの規模で割った担当者別規模割総得点、全ての担当者の規模割総得点中央値404を算出する。
【0055】
ステップS43において、図15に示すような減点分析結果を品質管理部端末160に表示する。例えば、1つのプロジェクトに係る全ての開発担当者がセルフチェックをした結果より算出した加点と、および品質管理部が検査(テスト)を実施した結果より判明した不良数より算出した減点とを総計した総得点を担当者別に集計して、更に担当者別の総得点を該当プログラムの規模で割って算出した規模割総得点403を算出して、規模割総得点403が大きいもの順に担当者を配列することが考えられる。担当者別に代えて、責任者別(担当者のグループ別)に集計してもよい。
【0056】
この規模割総得点403が大きい担当者の方が、開発したプログラムの品質は高いと評価できる。加点分析において、品質が高い担当者はセルフチェックの確認箇所数も多い(適切)し、不良が少ないからである。セルフチェックの確認箇所数に虚偽申告を行った場合、加点分析にて品質が疑われ、品質管理部が検査を行って不良が判明し、減点されるからである。また、プログラムの不良が少なくても、セルフチェックの確認箇所数に不正の意図を感じるほど大きくずれている場合、減点等のペナルティを課してもよい。
【0057】
図12のステップS43において、減点分析部115は、減点分析結果を記憶部120の減点分析結果記憶領域127に記録する。
ステップS44において、減点分析部115は、減点分析結果を出力部130より帳票に出力する。
【0058】
システム開発では、プログラム規模あたりで発生する確認箇所数(チェックリストで担当者、責任者が定義する)は大きく変動しないことを本発明では前提としている。したがって、プログラム規模あたりの確認箇所数を評価し、その値が大きくずれている場合には、担当者の理解度が低い、セルフチェックが不適当ということが考えられ、従ってプログラム品質も低いことが予想される。
【0059】
プログラムによっては品質が高いが、プログラムの性質から、加点分析結果において規模割加点の値が規模割加点の値の中央値402から数値がずれるものもあると考えられるが、品質が疑われるプログラムを品質管理者が実際に検査(テスト)で不良チェックを行うに際して、不良チェック対象プログラムを決める目安にはなる。品質が高いプログラムは不良が少なく、減点が少なくなる。
【0060】
図15において、規模割総得点を高くするには、1)適切にセルフチェックを行い適切な確認箇所数を記入し、2)不良を少なくする、ということが有効である。ランキング形式で記載し、これを各開発担当者に公開することで、各担当者の意識を向上させる。担当者は、開発作業をきちんと理解し、きちんとセルフチェックを報告し、不良の少ないプログラムを作成することで、品質が向上する。
【0061】
本実施例によれば、他社に外注したプログラムの受入れ検査をする場合に、他社から報告されるセルフチェック結果を用いて、どのサンプルプログラムを受入れ検証すべきかを、受入れ品の品質を受け入れ前に目安を付けることができる。
【0062】
本実施例によれば、システム開発担当者は、プログラムの品質のみならずセルフチェック自体の品質も可視化されるため、プログラムおよびセルフチェックの品質マインドが向上すると考えられる。これによって、各プログラムを合わせての試験より前に不良を低減して、試験開始後の進捗遅れを防止することができる。また、各担当者のプログラム作成時点で、品質を含めた進捗を管理できるため、遅延リスクを抽出して対策することができる。また、品質を見える化することで、担当者の品質意識を向上させることができる。
【0063】
本実施例では、ソフトウェアの品質、およびソフトウェアのセルフチェックの品質を可視化して、管理する方法とその装置を説明しているが、ソフトウェアに限らずに、ハードウェアも含めて一般のプロダクトを製造する上で、作業手順通りにやったかどうか、作業手順の良し悪しを管理する手法に適用できると考えられる。
その場合のセルフチェック観点としては、プロダクトの特定の機能をチェックするというのではなく、なるべく普遍的な共通の機能をチェックするようなセルフチェック観点を採用することが本実施例の有効性を出せる条件と考えられる。
【実施例2】
【0064】
実施例1では、加点計算に際し、担当者の確認箇所数と責任者の確認箇所数の両方を用いた計算を行っている。すなわち、責任者のレビューが終わった時点でのソフトウェアの品質を評価している(担当者と責任者の評価を行っている。ただし、責任者がレビューを行わない場合が多数あり、責任者の確認箇所数が無い場合には、担当者のみの評価となる)。実施例2では、担当者の確認箇所数のみで加点計算を行う。これによって、担当者の評価を行うことができる。有能な担当者は加点が妥当な値になり、理解が少なかったり、ごまかしを行った場合には、加点数値が少なくなったり多くなったりする。
【実施例3】
【0065】
実施例2の変更案として、責任者の確認箇所数のみを用いて、加点計算を行ってもよい。この場合、責任者の確認箇所数は担当者の確認箇所数からの差分であり、その絶対値が大きいほど責任者が修正した値が大きいということになる。加点計算には、責任者の確認箇所数の絶対値を用いる。加点が大きいほど、責任者の役割が大きいということになる。ただし、担当者が有能であれば責任者の修正は少なくなる点には考慮が必要であり、たとえば、担当者の能力を考慮して評価するなどが必要になる。
【符号の説明】
【0066】
100 品質管理装置
110 演算部
111 確認箇所数登録部
112 不良件数登録部
113 得点算出部
114 加点分析部
115 減点分析部
116 観点重要度、重要度得点係数設定部
120 記憶部
121 確認箇所数記憶領域(確認箇所数テーブル)
122 不良件数記憶領域(不良件数テーブル)
123 得点情報記憶領域(得点情報テーブル)
124 観点重要度記憶領域(観点重要度テーブル)
125 重要度得点係数記憶領域(重要度得点係数テーブル)
126 加点分析結果記憶領域
127 減点分析結果記憶領域
130 出力部
140 通信部
150 ネットワーク
160 品質管理部端末
170 開発部端末
200 セルフチェックリスト
201 チェック項目(セルフチェック観点)
202 担当者確認箇所数
300 ツールインタフェースのメニュー画面
301 ツールのメニュー「件数情報登録」
302 ツールのメニュー「得点算出実行」
303 ツールのメニュー「加点分析実行」
304 ツールのメニュー「減点分析実行」
305 ツールのメニュー「観点重要度・重要度得点係数設定」
401 規模割加点
402 規模割加点中央値
403 規模割総得点
404 規模割総得点中央値
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15