Software Quality.com

＜機能性＞

機能性とは、「ソフトウェアがある目的を持って求められる、必要な機能を実装している度合い 」と言えるでしょう。
ここで注意が必要なのは、顧客からあるいは供給組織からの「明示された要求＝機能」だけを捉えるのではなく、「暗に期待されている要求＝機能」も含まれるということです。
そう考えると、どうやって「暗に期待されている要求」を捉えればいいのか？困りそうですが、それらを解決してくれるのが「品質副特性」のようです。それぞれの副特性のきちんとした定義は、参考書籍をご覧下さい。

●基本的に要求されるメイン機能の存在を表す副特性

【合目的性】

「明示された仕事に対する・・・・」と定義されていますが、簡単に言うと「ユーザ要求」と「ソフトウェア設計仕様」の合致度合いを指すと考えて下さい。ですから、合目的性は「設計品質」を問うものと言えます。
合目的性を測る場合、必要なものは「要求仕様書＝ユーザ要求」と「ソフトウェア設計書類＝ソフトウェア設計仕様」となり、例えば納品後顧客からの改良要求件数の経過時間に対する頻度（経過時間にどれだけ改良要求があったか？）があげられます。
改良要求が少ない（Ｚｅｒｏに近い）ということは、改良しなくてよいだけ十分「使用目的に合っている＝合目的」ということになります。
ソフトウェアの使用者が単数の場合は、使用者側でも測定可能。ソフトウェア使用者が離れていて複数存在する場合は、供給者側でなければ測定できないでしょうね。

【正確性】

「正しい結果もしくは正しい効果、・・・・」と定義されていますが、「ソフトウェア設計仕様」と「プログラム」の合致度合いを指すと考えるといいでしょう。「正確性」は「プログラム品質」を問うものと言えます。
正確性を測る指標としての例は、操作説明書や使用マニュアルに記述された手順や機能が、実際のソフトウェアの操作・機能と一致する度合いがあります。また、ソフトウェア設計書記述の機能とソフトウェア本体に実装された機能との合致度合いもあるでしょう。
この場合、合目的性の測定指標例とは反対に「１」に近い数値の方が良いと評価できますね。

●メイン機能を補助・支援するために必要な機能に対する副特性

【相互運用性】

「同一システム内の他プログラム間や他のシステムのソフトウェアとの間で、データやコマンド等をやりとりできる度合い」を指します。実際に使用されるデータ形式（や文字コード・制御コード）の全体数と、相手のフォーマットに合致しているデータ形式（や文字コード・制御コード）の数の比率が代表的な測定指標となります。

【セキュリティ】

「ソフトウェアへの不正なアクセスを排除する機能や、ミスによる資源破壊の防止の度合い」を言います。
インターネット時代に突入した現在では、ネットワークを通じて組織外部からの不正なアクセスによる情報の漏洩、改竄、破壊等の事件が絶えません。また、外部からばかりに目が奪われがちですが、多くの不正アクセス（権限外のアクセス）は組織内部要員による犯行である（一説には全体の８割!!）ことが分かっています。
その意味で「セキュリティ」は、非常に重要な品質副特性であり、オープン系システム構築時には「必須」の要求事項と言えます。
評価指標の例としては、暗号化率（全データ数と暗号化されているデータ数の比）や権限外の不正なアクセスに対する対処の度合い（例えば全ファイル数とアクセス権限を設定して、利用者限定をしているファイル数の比）、時間単位の不正アクセス数等が考えられます。

【標準適合性】

「適合することが要求されるさまざまな規格や法律等への合致度合い」です。
例えば、データフォーマットが規格化・標準化されているような場合、実際にやりとりされているデータの全体数と、規格・標準に合致したフォーマットになっているデータ数の比率を取る方法があります。
OSI参照モデルの使用やＥＤＩ、全銀協手順等、共通的な規格に則ることが多くなってきましたので、標準適合性の利用価値がますます多くなってくると想像します。

＜信頼性＞
機能性は、「ソフトウェアがある目的を持って求められる、必要な機能を実装している度合い」を指しましたが、それに対して信頼性は「実装している機能が、あらゆる条件の下で機能要件を満たして（必要な期間）正常動作し続けることができる度合い」を指します。
ということで、一見似ている特性である「機能性」と「信頼性」の違いを簡単に言うと、

「機能性」＝機能があって、標準的なデータ・条件で動作すること＝機能の存在　　　　　　　　
「信頼性」＝存在する機能が、あらゆるデータ・条件でも正しく動作し続けること＝機能の維持

となりそうです。
信頼性の副特性の内容は以下の通りです。

【成熟性】

機能性の副特性「合目的性」に似ていますが、合目的性が仕様化された機能の存在を評価するのに対して、「成熟性」はそのソフトウェアに存在する障害の有無・量・頻度の度合いを指します。
簡単に言うと、どんなことをしても問題なく動作する度合い（例えばBUGがない）ということになりそうです。

成熟性を評価する指標の代表格は、平均故障間隔（MTBF：Ｍｅａｎ Time Between Failure）です。
これは「ソフトウェア（システム）の総稼働時間」を「故障回数」で割ったものであり、故障が起きるまでに動作している平均時間を指します。

平均故障間隔＝ソフトウェア（システム）の総稼働時間／故障回数

みなさんもご存じのとおり、この平均故障間隔：MTBFは、ハードウェアをも包含した「システムの稼働率」を計算する上で必要な要素の一つです。

（余談）
平均故障間隔の逆数（１／平均故障間隔）を「故障率」と言い、ハードウェアの場合にこれを縦軸に、システム稼働時間を横軸に取ってグラフを書くと俗に言う「バスタブ曲線」が得られます。（あくまでも一般的にですが）
この「バスタブ曲線」はハードウェアを中心としたシステムの信頼性を表す代表的なグラフです。

また、ソフトウェアテストにおいて存在する障害の摘出度合いを表す「障害収束率」も成熟性を表す指標の一つです。

障害収束率＝摘出障害件数／総障害件数

テストが進むにつれて、障害収束率は「１」に近づいていきます。
ソフトウェアのBUG収束曲線は、この指標から得られます。

（注意）
ここでいう「総障害件数」ですが、この件数はあくまでも「推定した値」を想定しているため、組織によっては使用が困難な場合があります。
総障害件数を推定するためには、その組織での開発中にどれだけBUGを埋め込んでしまっているか？を丹念に追跡していく必要があるからです。「実績数値を系統だって累積し、予測に使用すること」は、重要であることは分かっていても、なかなか難しいものですよね。

【障害許容性：フォルトトレランス】

「フォルト（欠陥）部分を実行したときに、表面上問題なく動作することができる度合い」を指します。
例えば、ソフトウェアを設計する際に指定範囲外の数値が入力された時の考慮がなされていない場合、そのまま処理を続行したら結果がおかしく出力される等障害になって返ってくるでしょう。
しかし、範囲外入力時にはエラーを表示し、範囲内入力がなされるまで再入力を要求することや、エラー入力に対して帳票上でエラー表示をすることはできるはずです。
「人間には間違いがある」ことを前提として、ソフトウェアを作り上げることは非常に重要です。
「ガーベッジイン、ガーベッジアウトは正しくない」とは、「ソフトウェア開発201の鉄則」でも言われていること。
誤った入力がされた場合、そのまま誤った出力がされるのでは良いシステムとは言えません。
「誤った入力は検知して、エラーで返す」のが良いシステムの最低要件でしょう。
その意味で、この副特性はソフトウェアにとって重要な特性の一つです。
指標としては、「誤入力・誤操作検出率＝誤入力・誤操作の総回数のうち、チェック機能により検出された回数」があります。

誤入力・誤操作検出率＝検出された誤入力・誤操作件数／誤入力・誤操作総件数

【回復性】

「障害時の回復・復旧の能力（例えば回復時間）」を指します。
ソフトウェアシステムを使う人にとっては障害がないことも重要ですが、障害発生時にいち早く回復して、使用できるようになることも重要です。
それを測る指標の代表格は、稼働率です。
稼働率は先ほど説明した平均故障間隔MTBFと平均修理時間（MTTR：Ｍｅａｔ Time To Repair＝故障が起きてから、障害を吸収して使えるようにするまでの対応時間）で算出できます。

稼働率＝平均故障間隔／（平均故障間隔＋平均修理時間）＝ＭＴＢＦ／（ＭＴＢＦ＋MTTR）