ソフトウェアの品質（その４：プログラムの品質）

一般的なプログラムの品質特性は、
ISO／IEC　JTC1／SC7　DP9126（1990.1）ソフトウェア品質特性
（機能性、信頼性、使用性、効率性、保守性、移植性）の中で述べられている通りである。

従来、品質向上活動としては、特に信頼性に着目し、
ソフトウェア開発における欠陥の除去を目的として、
設計結果のレビューやプログラムの試験による品質状況の把握と残存欠陥数の予測を行うことが一般的に行われてきた。
しかし、ソフトウェアの普及とあいまってソフトウェアの保守性が問題視され、
また、対話型のソフトウェアが主流になったことから、
ソフトウェアの使用性が重視されるなど、
品質に関する認識が高まり、
上記の特性により品質を管理することが大切である。

このような品質特性の作り込みのために、
『プロジェクト管理』＊に則り工程ごとの品質作り込みの徹底や「各種レビュー」を行う。

基本的な考え方の流れはその１：ソフトウェアのライフサイクル「顧客システムのライフサイクル」参照。

＊：ＰＭ（Project Management）とは、一連の技法、プロセスを駆使して、プロジェクトを効果的に定義し、計画し、実施し、管理することである。

プログラムの品質水準

下記の水準を目安として品質管理をするが、
最終の目標は、無欠陥（ＺＤ：Zero Defects）であると言うことはいうまでもない。
これらの水準は、該当するプログラム分野ごとに定期的に見直しを行い設定する必要がある。

・共通品質目標値
社外品質（社外での事故件数等）、
社内品質（設計内での作り込み不良件数等）
などの目標値設定を行い品質の管理を行う。

・固有品質目標値
プログラム分野ごとに固有（PCL＊件数等）の品質目標値を定め品質の管理を行う。

プログラムの開発規模の管理
定量的評価を行うに当り目標値の設定や密度を算出するベース（母数）となる開発規模は、非常に重要でありこの値が品質評価を左右すると言っても過言ではない。
一般的に開発規模は、誰もが分かりやすいステップを用い、キロステップ（ｋｓ）を単位として評価します。

１ステップ＝１ライン（行）でカウント
開発規模＝新規製造ステップ数＋自動生成ステップ数＋改造ステップ数＋流用改造ステップ数

問題は、改造プログラムの場合、
改造母体が大きくなるとより複雑さが増し、
「バグは、開発ステップ数の２乗に比例する」
と言われ規模が大きくなるにつれ予測が難しくなります。
改造プログラムの場合は改造母体の品質を考慮し目標値管理が必要です。

＊：チェックリスト（ＰＣＬ）件数の目標値管理
チェックリストの十分性を定量的に評価するための指標となる値です。

（１）チェックリスト作成の量的目標値
プログラムステップ数当りのチェック項目作成の粗密度の基準値です。
机上デバッグ（ＤＤ：デスクデバック（ソースコードを机上で確認するテスト方法））は、対象外ですが、開発言語によっては大きな効果が期待出来ます。
単体テスト１００、結合テスト２０、システムテスト１０、ビジネスサイクルテスト５、この数値は参考まで、プロジェクトの特性や類似プロジェクトの実績値を基に、目標値の設定を行う必要があります。

（２）チェックリスト作成の質的目標値
量的に十分性はあっても、片寄りがあっては意味がありません。
そこで、限界値／境界値、異常系等のチェック項目を着実に設定し、網羅性のあるチェックリストを作成するための質的基準値です。
正常系４０～６０％：組合せ項目を含む。また、業務チェックによるエラー応答は正常系とみなします。
限界値／境界値１０％～３０％
異常系１５％～３０％：ＤＢ障害、論理矛盾などの確認項目です。
インタ－フェース系５％～１０％：共通モジュールや他機能（処理）とのインターフェースの確認項目です。
なお、この数値は参考まで、プロジェクトの特性や類似プロジェクトの実績値を基に、
目標値の設定を行う必要があります。

【摘出不良に対する目標値】
テスト工程において不良を摘出する目標で、また、
摘出不良の十分性を定量的に評価するための指標となる値です。
机上デバッグ／単体テスト（ＤＤ）５～１０：机上デバッグ、単体テストで、全体の６０％以上の不良摘出を目標としています。
結合テスト１～３
システムテスト１
ビジネスサイクルテスト０．５
なお、この数値は参考まで、プロジェクトの特性や類似プロジェクトの実績値を基に、目標値の設定を行う必要があります。