Software Quality.com

 

 

ソフトウェアは「目に見えないモノ」ですので、その評価は現時点でも非常に難しい課題の一つです。
見えないからこそ、ソフトウェア品質の評価は重要となります。 その難題に一つの光明を見いだしたのが皆さんもご存じのISO/IEC9126(JIS X 0129)　ソフトウェア品質特性（Ｑｕａｌｉｔｙ Characteristics）　です。
（正式名称は「Information technology software product evaluation:Quality characteristics and guidlines for their use」）
この規格は1991年（JISは1994年）に発行され、多くの人が存在（名前だけ？）を知っているのですが、その難解さ故利用されることは少ないようにも思います。
そこで、Software Quality.comではこのソフトウェア品質特性をある程度かみ砕いて解説することにしました。
この解説で品質特性を利用した有意義な評価を実現する組織が増え、ソフトウェア品質向上に役立つことができれば幸いです。

参考文献

     「ソフトウェア品質評価ガイドブック」           日本規格協会

     「ソフトウェア品質保証の考え方と実践」     日科技連

 

1.ソフトウェア品質モデルの歴史
ソフトウェアの（製品）品質を推し量る指標については、「障害がないことだけに偏っていた時代」と「特性による評価手法の提言と使用の時代」に分けることが出来ます。
1973年ウルフ（Ｗｕｌｆ）が世界で初めてソフトウェア品質をモデル化しました。
「障害がないことだけを意識していた時代からの脱却」がここから始まりました。
とはいえ、「信頼性」が入っていなかったこと等まだまだ不完全な定義となっていたようです。
その後、アメリカ国防省の要請を受けたベーム（Ｂｏｅｈｍ）は、1976年に「ベームのソフトウェア品質モデル」を発表しました。
このモデルは、その後のソフトウェア品質モデルの基礎となる階層構造（主たる特性が複数有り、その一つ一つの特性には複数の副特性があるという考え方）を採用した、画期的なモデルです。
1977年には、ウォルタース（Walters）とマコール（ＭｃＣａｌｌ）が「クライテリア：25種類」－「ファクタ：11種類」－「有用性：3種類」という3階層の品質モデル（FCMモデル）を発表。
それ以外にも予算が十分確保された大規模プロジェクトを想定した［SQM：Ｓｏｆｔｗａｒｅ Quality Metrics]や、1985年日本電気で開発された「SQMAT」、ＩＢＭで開発された「SQUALAS」、１９８７年ヴァージニア工科大学のOPA、1988年バジル（Ｂａｓｉｌｉ）のGQM（Ｇｏａｌ・Qｕａｌｉｔｙ・Mｅｔｒｉｃｓ）モデル等の品質モデルが提唱されています。
それらの提唱された品質モデルの良い点・問題点を吸収し、世界表通の品質モデルの必要性を満たすために1991年発行されたのがISO/IEC9126です。
日本ではこの世界規格を1994年1月にJIS X 0129として発行しました。

 

2.ソフトウェア品質特性・副特性の構造
ISO/IEC9126-1:2001では、ソフトウェア品質を示す特性に「外部・内部品質を表す特性」とそれをさらにブレイクダウンした「品質副特性」を定めています。

品質特性	品質副特性	主な内容
機能性	合目的性 正確性 相互運用性 セキュリティ 標準適合性	目的から求められる必要な機能の実装の度合い
信頼性	成熟性 障害許容性 回復性 標準適合性	機能が正常動作し続ける度合い
使用性	理解性 習得性 運用性 魅力性 標準適合性	分かりやすさ、使いやすさの度合い
効率性	時間効率性 資源効率性 標準適合性	目的達成のために使用する資源の度合い
保守性	解析性 変更性 安定性 試験性 標準適合性	保守（改訂）作業に必要な努力の度合い
移植性	環境適応性 設置性 共存性 置換性 標準適合性	別環境へ移した際そのまま動作する度合い

   　
全部で品質特性が６種類、品質副特性が２７種類存在します。

 

3.ソフトウェア品質の捉え方
ソフトウェア品質を捉えるには、「2つの主たる視点」と「2つの補完する視点」が存在します。
主たる2つの視点とは「設計品質」（外部品質）と「プログラム品質」（内部品質）です。
「製品品質」というとどうしても「プログラム品質」だけを捉えてしまいがちですが、ソフトウェア品質モデルの「品質」の捉え方は「設計品質」をも包含しています。

 

 

また、補完する2つの視点とは「プロセス品質」と「利用時の品質」です。

この2つについては別途解説します。

 

4.ソフトウェア品質モデルの使い方
ISO9126規格にはたくさんの特性・副特性が定義されています。
これまでまったく使用してこなかった組織が、いきなり使用して、ソフトウェア品質を評価することは現実的ではありません。ではどうやって使うべきか？？？
ISO9126は、どちらかというと品質特性要素を網羅的に並べ立てた内容ですので、まずは特徴的な要素から選択して使うのがいいでしょう。

まずは対象のソフトウェアに要求される特徴的な品質副特性を抽出して、抽出された副特性毎に数値化した基準値を当てはめ、実際に作り上げたソフトウェアで測っていく・・・ということです。
特徴的な要素で測定できるようになったら、特徴的な要素以外の要素を含む全体で捉えた計測を行なうなどの段階的な対応も考慮するべきです。

注意点は、それまで品質評価をやっていなかったのに、いきなり体系的かつ網羅的なソフトウェア品質評価を目指すようなやり方は避けた方がいい場合が多いということです。
この方法は燃え尽きるか、非効率的になるか、無理をしたために事務的で無意味な評価（やればいいんだろう的な評価）になりかねません。
はじめて使ってみる場合には、いくつかの特徴的・代表的で、かつ理解できて使えそうな副特性で始めてみることです。
そして慣れてきたら、副特性要素全体の方向へ進むことです。
くれぐれも「評価する」ことが事務処理やその場のやり過ごし、目的にならないようにして下さい。計測はあくまでも何かの目的を果たすための手段でしかありません。

「評価結果を使って、ソフトウェア品質の舵取りを行う」ために実施できれば、きっとすばらしい効果があるでしょう。目的ありきです。これらの情報を参考にして下さい。

 

5.品質特性に見るソフトウェアの性質
何かを管理し、制御するには、管理・制御の対象が「何か？」「どんなものか？」を知ることが必要になります。
例えば、”羊飼い”は多くの羊を巧みに操る（管理・制御する）必要がありますが、羊がどんな生き物で、何に興味を示すのか？どんな行動パターンを取り、何が好きで、何が嫌いか？等を十分に理解して、場面に応じて使いこなすことが要求されるはずです。
同じ理由で、ソフトウェアを管理・制御するには、ソフトウェアとは何か？どんなものか？を知ることが必要になります。ここでは「品質特性」という切り口を中心に、ソフトウェアの性質を整理してみます。

理解を進めるために、（ソフトウェアの性質を表す上で）ハードウェアの性質と比較することとしましょう。
ソフトウェア品質特性には、上記の通り「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」が存在します。以下は、品質特性毎の相違点です。（私が感じている視点です）

ソフトウェアは、一度作られた部分の「経年変化」がありません。
「そうは言っても、時間が経てばソフトウェアで構築されたシステムもだんだんおかしくなっていくじゃないか！」という方がいるかもしれませんが、それは時間が経過する毎にソフトウェアの内容を”変化させることが度重なる”ことで起こっています。
ここでの違いは「ソフトウェア自体に変化を加えるか否か？」です。
私が言っている「経年変化なし」は、変化を加えない前提です。ハードウェアと比較するために、話を同じ土俵にのせるためにそうしています。

品質特性には記述がありませんが、実際のソフトウェアは目に見えません。
「コードで見えるじゃないか！」「画面上で動作が見えるじゃないか！」と言う方がいるかもしれませんが、コードはコンピュータが実際に動作するしかけを便宜的に人が命令するための表記方法にすぎません。

コンピュータは目に見えないところでコードを翻訳し、その内容に従って動作しているわけです。

その部分は簡単には目で見ることができません。
また、画面上に展開される動作自体はソフトウェアが行っているうちの「人とのインターフェース部分」だけです。
裏の方では入力された情報を元にした計算や判断、格納や出力等が行われています。

これまた直接見ることが出来ないモノです。

品質特性に話を戻しますが、もう一つの大きな特徴は保守性にあります。
ハードウェアはソフトウェアよりは容易に機能拡張をすることができません。
ソフトウェアはそのハンドリングの良さ故に「変化する」ことを当たり前として保守性を捉えています。

これらがソフトウェアの特徴です。
これらの特徴を把握した上で、管理や制御を考えていかなければならないわけです。

参考にしてください。