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