ＳＷ品質まとめ③ソフトウェア品質特性
未完成ですが、随時更新していこうと思いますので、いったん書ける範囲で書いておきます。あらかじめ申しておきますと、現時点での完成度は２割もありません（例を作るのが面倒で…）。
まずは大分類であるソフトウェア品質特性について見てみましょう。
ソフトウェア品質特性（ISO 9126-1 / JIS X 9126-1）は、大きく６種に分類されています。これらは概念であって、必ずしもすべての特性を用いるわけではありませんし、そのまま開発に当てはめても測定が困難なものであったり、人によって価値意識が異なるものもあったりして、上手くマッチングしないケースもあります。
ですが、少なくともこれらの品質特性のどれとも合致しないような品質観点は、ソフトウェア品質を保証することができないものです。理解しておくかどうかは、そのまま『モノづくり』全体の品質にも影響を与えることでしょう。
■機能性：「要求された機能を備えているか」
指定された条件の下で利用するとき、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力のこと。ソフトウェアが必要性を満たすために何をするか、実現された機能に過不足がないかを示すもの。ここでの必要性には、暗に期待されている必要性も含まれます。たとえば、要求仕様書に明確に記述されているか否かには依存しません。
■信頼性：「特定条件下においてどのくらい信頼できる製品か」
指定された条件の下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力のこと。信頼性では、狭義の平均故障間隔などで示される概念だけでなく、ソフトウェアに潜在していた障害による誤動作からの回復、ならびに障害に対する許容性に対する概念も含まれています。
■使用性：「どのくらい使いやすくできているか」
指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力のこと。いわゆる「使い勝手」、「使いやすさ」、「操作性」の概念。一般的にシステムテストにおいて業務シナリオを確認することや、ユーザーによる受入検査を行うのはこの観点を確認するため、テストなどでも大いに検討されます。
■効率性：「どのくらい限られたリソースを効率よく使えているか」
明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力のこと。つまり、定められた条件下でいかに速く処理できるか、単位時間内にどれだけ多くのトランザクションを処理できるか、またいかに資源を有効に使用するかを示すもの。速度的な性能もさることながら、ハードディスクやメモリの使用量（スケーラビリティ）なども問われることになります。
■保守性：「どのくらいメンテナンスしやすいか」
修正のしやすさに関するソフトウェア製品の能力のこと。修正は、是正もしくは向上、または環境の変化、要求仕様の変更および機能仕様の場合もあり、ソフトウェアの誤りが短期間に修正され使用可能となれば利用者にとっても有益ということになります。
一部の「テスト」だけすれば品質が保証されていると勘違いしているＱＡにとっては、鬼門となる観点。テストは原則として動作させたときの"アウトプット"しか確認できないため、こうした観点は軽視されることが多い。
■移植性：「どのくらい他環境に順応しやすいか」
ある環境から他の環境に移すためのソフトウェア製品の能力のこと。環境には組織、ハードウェアまたはソフトウェアの環境を含めてもいいでしょう。要するに、別の環境へどれだけ容易に移せるかを示します。
データ構成の移植（移行）容易性などは非常に重要で、システムは長くても10年もすれば殆どの場合が老朽化に伴う再構築（リプレース）されることになりますが、その際、新システムの開発の中で最も重要なのは旧システムで活用してきた資産（データ）の再活用です。このことをイメージできないデータモデル設計などは非常に嫌われ、リピーターにはなってくれないかもしれません。
「バグがないこと」という観点は、“機能性”（プログラムが要求仕様通りに正しく動作するか）または、“信頼性”（実装している機能が指定された条件下で正しく動作し続けるか）のごく一部でしかないことがわかります。
現在は、規格が移行されており、ISO 25010：2005にてソフトウェア品質が定義されていますが、若干複雑化しているため、まずは基本コンセプトを把握する上でも、ISO 9126からしっかりと学んでおくと良いでしょう。
これらはソフトウェア品質を検討する時点で、揺るがない指標となります。このような品質観点の基準を最初に持っておかなければ、モノ作りの作業内で「どうやったら品質が向上するか？」を検討することすらできません。
各品質特性の依存性
この６つの品質特性は、それぞれ利用時の品質・外部品質・内部品質に深く影響していくことになりますが、この中の１つ「保守性」に注目しましょう。その他の品質特性はこの「保守性」に依存しているという一面を持ち合わせています。
ソフトウェアは常に「変更」にさらされています。作ったらそれで終わりというわけではありません。そのためソフトウェア本来が持つ要求事項に対する品質とは別に、保守性が保たれていることはプロダクト（=製品）の本質としてまず大前提であると言えます。
内部品質が成立しないと外部品質を保証できない、という依存関係がある以上、これらの品質副特性は必ず一定以上満たされていることがソフトウェア品質を保証する上で必要な要件となります。
機能性 -functionality-
一言で言えば「お客さまがシステムに対して求める目的に、適合しているかどうか」になります。システムテストを実施する上では欠かしてはならない観点です。同時に、正しくお客さまの目的を理解していないと、テスト設計が行えないということであり、お客様が求めていること、お客様に対してシステムが提供する価値に対して正しい認識をすることがシステムテストにおけるスタート地点となります。
■合目的性 -suitability-
ユーザーがシステムに対して求めている目的（要求）に適合しているかどうかの指標です。「顧客要求事項」を漏れなく取り込めているかどうかに他なりません。設計工程、設計書とは元来、この要求事項をチャンクダウンしたものです。ですから、仕様書や設計書とのトレーサビリティを確認することが最も重要な保証観点となります。
なんとなく動けばいいわけではなく、またなんとなく満足すればいいというものではないのです。
■正確性 -accuracy-
入力に対して常に期待する出力をするかどうかの指標です。機能によって実施される処理やアウトプットに対して、ブレやズレが発生しないこと、あるいは要求事項の定める許容範囲内であることを保証しなければなりません。
個々のソフトウェア機能に関しての正確性は、結合テストで網羅されているべき観点ですが、システム環境でそれらが変わりなく機能しているかを確認する意味で、システムテストにおいても必要な観点になります。特にテスト環境上のプラットフォームが異なる場合は、それまでの工程で確認されたものであっても、再度実施する必要があるでしょう。
■相互運用性 -interoperability-
テスト対象のシステムから見て、「外部」との連携が期待通りに行えるかどうかの指標です。一般的に"他システム"・"機器"だけをターゲットにしやすいですが、業務との連携やその前後に起こりうる人の行動なども対象となることがあります。
そういう意味では、単独で動作するシステムの場合には考慮する必要がないかもしれません。
しかし昔の完全なスタンドアロンＰＣでもない限り、通常は考慮しなくていいシチュエーションというのはそうそう存在しません。ただし、行うべきは他システムとの連携のタイミングやデータ転送の設定などのテストであって、連携するデータを想定したソフトウェア機能に関するテストについては、スタブやドライバを用いて結合テストまでには終わっていなくてはなりません。
■機密性 -security-
許可されたユーザーのみが必要なデータにアクセスできるかどうかの指標です。これは、システム利用上の観点と、インフラを含むシステム運用上の観点の２種類があります。
ソフトウェア機能として必要なセキュリティ要件を満たしているかどうかの確認については、おそらく結合テスト。システム全体として必要なセキュリティ要件を満たしているかどうかを確認するのは、システムテストの役割になるでしょう。またシステムの要求されるセキュリティ要件はさまざまなため、各フェーズに合わせたテスト内容の検討が必要となります。
■標準適合性 -functionality compliance-
機能性に関する法規、業界標準、規格にソフトウェアが沿っているかの指標です。意外と誰からも軽視されやすい観点がこれです。
顧客ごとに様々なニーズ（顧客要求事項）があり、そのニーズに照らし合わせて機能を実装することになりますが、顧客要求事項を満たしさえすれば、製品として認められるわけではありません。
法令や規格、業界の標準などに準拠していなければ、顧客自体が損害を被ることになりかねないからです。たとえば、”通貨レートの妥当性”、”消費税の計算”や、”元号の変更”などがこれにあたります。
金額を取り扱う場合、「小数点以下の数字をどうしなければならないか？」といった課題は、お客さまの要求に合わせるのではなく、利用する国の法律によって定められていたりするので、注意が必要です。
ここから先、全５項はファイルにて。
3. ソフトウェア品質特性
3.1 各品質特性の依存性
3.2 機能性 -functionality-
3.2.1. 合目的性 -suitability-
3.2.2. 正確性 -accuracy-
3.2.3. 相互運用性 -interoperability-
3.2.4. 機密性 -security-
3.2.5. 標準適合性 -functionality compliance-
3.3 信頼性 -reliability-
3.3.1. 成熟性 -maturity-
3.3.2. 障害許容性 -fault tolerance-
3.3.3. 回復性 -recoverability-
3.3.3. 標準適合性 -reliability compliance-
3.4 使用性 -usability-
3.4.1. 理解性 -understandability-
3.4.2. 習得性 -learnability-
3.4.3. 運用性 -operability-
3.4.4. 魅力性 -attractiveness-
3.4.5. 標準適合性 -usability compliance-
3.5 効率性 -efficiency-
3.5.1. 時間効率性 -time behavior-
3.5.2. 資源効率性 -resource utilization-
3.5.3. 標準適合性 -efficiency compliance-
3.6 保守性 -maintainability-
3.6.1. 解析性 -analyzability-
3.6.2. 変更性 -stability-
3.6.3. 試験性 -testability-
3.6.4. 標準適合性 -testability-
3.7 移植性 -portability-
3.7.1. 順応性 -adaptability-
3.7.2. 設置性 -install ability-
3.7.3. 共存性 -co-existence-
3.7.4. 置換性 -replace ability-
3.7.5. 標準適合性 -portability compliance-
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。