－ １ － ソフトウェア品質管理について １．品質とは 品質とは古典的には、「設計規格に対する適合度（適合品質）」 と考えられていたが、現在では、「ユーザの満足度（設計品質＋適 合品質）」であると言われている。 それは又、「当り前品質」と「魅 力的品質」に分けられる。 当り前品質とは、「それが満たされるのは当然であり、満たされ なければ不満を引き起こす品質要素」であり、魅力的品質とは、 「それが満たされれば満足感を与え、満たされなくても仕方がない と受け取られる品質要素」である。 ソフトウェアにおける品質についても同様のことが言える。 高 品質のソフトウェアとは、バグが少ないということは当然であるが、 それだけでは十分でなく、使いやすく理解しやすいものでなけれ ばならない。 また、ソフトウェア製品という場合は、「プログラム＋ドキュメント」 であり、最近ではソフトウェアの品質として、ドキュメントの品質が 重要視されてきている。 ２．ソフトウェアの特質 ソフトウェアの特質として一般的に良く言われることは、 ・一品生産で長い期間をかけて徐々に出来上がる。（ビルの建築 工事等に類似） ・ビルの場合は、徐々に出来上がっていくのが見えるが、ソフトウェ アの場合は実体が見え難く、定量的な把握が困難である。 と言われている。 また、工業製品の開発工程との比較を図１に 示す。 工業 製品 設計 試作 製造 テスト 商品化 出荷 設計誤り 製造誤り ｿﾌﾄ 設計 製造 テスト ｳｪｱ 設計誤り 製造誤り 設計誤り ３．ソフトウェアの品質管理 ソフトウェアというものは、前項で述べたように長い期間をかけて 徐々に出来上がっていくものであり、完成して初めて機能確認が 可能となる。 しかし、完成してからでないと、設計の誤りや要求定義の誤りが 発見できないとなると、費用の増大や納期の遅延は図り知れない ものとなる。 （家が完成してから、使い勝手が悪いので間取りを変更しろと言 う人は、いないだろう） その対策としては、 ・エラーの未然防止（設計努力） ・盛り込まれたエラーの早期検出（摘出努力） のニ方面からのアプローチが必要である。 ①エラーの未然防止 エラーは、難しく凝ったプログラムを作成しようとする場合に発生 することが多い。 したがって誤りを未然に防止するためには、理 解しやすいプログラムとすることが必要であり、そのための手法と しては、 ・因果グラフ ・構造化設計 ・ＨＣＰチャート ・高水準言語 等があげられる。 ②盛り込まれたエラーの早期検出 ソフトウェアというものは、徐々に出来上がっていくものではある が、その中身を見ると図２に示すように、要求分析、要求定義、設 計、製造の各工程に分かれている。 したがって工程の区分及び生産物を明確化し、工程が完了する ごとに、当該工程の生産物を複数の関係者の間でレビューするこ とにより、エラーの早期検出・次工程への持越防止を図る必要が ある。 現実世界 抽象世界 分 析 定 義 要求仕様 基本仕様 Ｗｈａｔ 検 査 出荷 図１ 工業製品とソフトウェアの開発工程の比較 工業製品の場合は、 ・試作品により機能確認を行った後で商品化されるため、出荷段 階で検出される不良は、ほとんどが製造誤りに起因するものに限 定される。 一方、ソフトウェアの場合は、プロトタイピング等の例外を除き、 ・設計を終了した段階での機能確認は不可能であり、テスト段階 で検出される不良には、設計誤りと製造誤りの双方が含まれる。 Ｓ６２．０８．０５ 設 計 ユーザ 運 用 製 造 製 品 詳細仕様 Ｈｏｗ 図２ ソフトウェア開発のライフサイクル 以上、述べたように、ソフトウェアの品質向上には、ニ方面から のアプローチが必要となるが、エラーの未然防止については、設 計・製造（ドキュメンテーション）技術に委ねることとして、ここでは、 以下、盛り込まれたエラーの早期検出について述べる。 (1)レビュー レビューは、先に述べたようにエラーの早期検出を目的として行 うものであり、レビューを効果あるものとするためには、以下のこと がレビュー実施の前提条件となる。 ①設計者の思考過程を視覚化し、他の設計者でもその適否が判 定できるようなドキュメントが作成されていること。 ②設計者自身の自主トレースは終えていること。 ③レビューの対象となるドキュメントが明確であること。 （生産物と出荷物、レビュー対象物の明確化） また、レビューに当たっての注意事項としては、 ①レビュー資料は事前に配布すること。（レビュー席上での差替え は不可） ②関係メンバーの経験結集により、幅広い見地からのチェックを 行うこと。 ③レビュー委員は、必ずコメント票を提出すること。 ④レビュー結果を整理分析し、エラーの再発を防止するため、 チェックリストへ反映すること。 なお、レビューの効果としては、品質の向上に寄与するほか、 ①エラーの早期検出による開発費用の逓減及び開発期間の短縮 が図れる。 ②メンバー間のコンセンサスが確保できる。 ③新人教育の場となる。 等が考えられる。 (2)試験 試験工程は、要求仕様に基づいて設計・製造と詳細化してきた ものを、一つのシステムに統合していく過程（図３参照）である。 試験工程における留意事項としては、 ①各試験工程に対応した設計工程で、試験項目を選定する。 ②机上デバッグとマシンデバッグの特長（表１参照）を把握して実 施する。 ③テスト内容の十分性を検討する。 ・試験密度（規模／項目数） ・試験時間数（時間数／項目数） ③テスト結果の十分性を検討する。 ・バグ密度（バグ数／規模） ・バグ収束率（バグ数／収束値） ・バグ摘出率（バグ数／期待値） 等が考えられる。 －参考文献－ (1)「ＱＣの基本」（品質管理ｾﾐﾅｰﾃｷｽﾄ）日科技連１９８６ (2)「ｿﾌﾄｳｪｱの品質管理」（電子通信学会誌）１９８３．４ (3)「ﾌﾟﾛｸﾞﾗﾑ開発管理」（オーム社、国友義久）１９８２ (4)「製造・バグの減らし方」 （品質管理ｾﾐﾅｰﾃｷｽﾄ）１９８６ (5)「ベル研究所における品質保証の新たな展開」（外国通信技術） １９８４．８ (6)「通信ｿﾌﾄｳｪｱの品質管理と標準化」（標準化と品質管理） １９８４．１１ － ２ － 基本設計 機能設計 基 本 設計書 機 能 設計書 試 験 仕様書 試 験 仕様書 総合試験 結合試験 詳細化 詳細設計 統合化 詳 細 設計書 試 験 仕様書 単体試験 参考１ 品質管理の基本原則（１／２） 参考１ 品質管理の基本原則（２／２） 原 則 解 説 原 則 解 説 品質第一 生産性を先に追求すると、レビューの実行面や 品質管理面（実態の把握・分析等）の作業が疎か になり勝ちである。 その結果、問題点後工程まで潜在化することに なり、問題点が表面化した段階では手遅れとなっ たり、間に合ったとしても手戻りが大きくなり、結果 的に工数の増大、生産性低下を招く恐れがある。 ・データの測定、評価尺度を統一する。 ことである。 そうでなければ、他との比較自体、 無意味なものとなり、また、真の原因追求及び対 策にも結びつかなくなる。 品質の追求！ 〔生産性は後からついてくる！〕 製 造 図３ ソフトウェアの開発工程 表１ 机上デバッグとマシンデバッグの比較 机上デバッグ マシンデバッグ 悪い箇所を発見 悪い現象を発見 （原因追究が必要） １回のランで複数箇所を発見 基本的に１回のランで１現象 可能 並行実施が可能 直列的な実施 （マシンに無関係） （マシン等の制約） 十分な検討時間が確保可能 十分な検討時間確保が困難 （マシン時間に無関係） （マシン時間の圧迫） 論理の複雑なものは時間が 論理が複雑でも短時間で かかる 済む 悪い箇所を見落とす恐れが 実行部分は保証できる ある ユーザ指向 製品は、バグや欠陥がなければ即“良い製品”と いうことにはならない。 物づくりに当たっては、常 に使う人の立場に立って考えることが基本である そうでなければ、“ユーザの満足”は得られず、 そういうものは製品であったとしても商品とはなり 得ない。 そのためには営業部門の役割として、製品をた だ売るのみではなく、ユーザの要求を「早く正確に 開発部門に伝達する」ことが要求される。 源流管理 大量生産品であれば、出荷時点で厳しい選別検 査を行うことによって、不良品の出荷を防止し、出 荷製品の品質を一定レベルに保つことは可能か も知れない。 しかし、その結果、検査に要する経費が増大す るとともに、不合格品作成に要する経費が“ムダ” となり、それらの経費が全て出荷製品に転嫁され ることになる。 また、ソフトウェアの場合は、一品生産であるた め、出荷時点での選別検査では対応できない。 最終ユーザに満足のいく製品を提供するために は、少なくとも、当該工程の生産物が次工程の人 に満足のいく形で引き継がれることを最低限の条 件である。 そのためには、次工程との風通しを良くして、意 思の疎通を図ることが重要である。 事実に基づく 物事を改善するためには、まず、実態を把握し、 管理 問題点及びその原因を追求することから始まる。 製品開発においても同様であり、開発における実 態をデータとして捉え、 ・当初計画との予実差分析及び対策 ・他の製品等との差異分析及び対策 を進めることにより、製品の品質向上を図ることが 可能となる。 この場合に重要なことは、 ・事実をデータとして捉える。 人間性尊重 現状の製品設計においては頭脳労働が主体で あり、その出来、不出来は人の要素に大きく依存 している。 特にソフトウェアについては、製造工 程についても、まだ大半が人に依存している状態 である。 したがって、製品の品質向上を図るためには、 当然、長期的な展望に立っての「人材の確保・育 成」が必要となる。 また、人は機械と違って「知恵と意欲を働かせる ことによって、自分自身の仕事を改善する力」を 持っていることから、この力をいかに十分に発揮 させるかが、企業にとっても個人にとっても、非常 に重要な問題となる。 参考２ 米国における開発チームの例 ユ ー ザ ＳＥ 要求仕様書 ＰＭ プロジェクト プ ラ ン 開発者 設計ﾄﾞｷｭﾒﾝﾄ プログラム ライタ ユーザーズ マニュアル テスタ テスト・プラン
© Copyright 2024 Paperzz
