ソフトウェアの品質とはなにか
ソフトウェアの品質
オブジェクト指向入門 第2版 原則・コンセプトの第1章のまとめです。
工学の目的は品質である。したがって、ソフトウェア工学は、品質の高いソフトウェアの生産を意味する。
ソフトウェアにおける品質には2種類ある。
- 内的品質要因
- コンピュータの専門家にしか認識されない品質要因
- 外的品質要因
- ソフトウェアを利用するユーザが認識できる品質要因
最終的な問題は 外的 な品質要因である。いくつかある外的品質を達成しやすくするために、内的な品質要因と関係はあるが、本質を見失ってはならない。
外的品質要因
以下に上げる要因は特に重要な要因であり、オブジェクト指向ソフトウェアが目指すべき使命*1である。
正確さ
正確さとは仕様によって定義されているとおりに仕事を実行するソフトウェア製品の能力である。
この要因が守られていない製品はそれ以外の要因を無意味とする。ナニワトモアレ、仕様通りの動きを行うべきである。 また、正確さは 前提条件依存 である。下の層が正しいという前提で実装する方法であり、問題の関心を分離し、問題に集中する唯一の現実的な方法である。
頑丈さ
頑丈さとは異常な条件に対して適切に対応するソフトウェアシステムの能力である。
正しさの補完的な要因。 仕様以外 のところで起きることに対する能力である。予見できる異常な状態は、異常な状態とは言えず、 正確さ の範疇であることを留意する。
拡張性
拡張性とは仕様の変更に対するソフトウェア製品の適応のしやすさである。
ソフトウェアは変化する。 変わりやすさがある 。伝統的なソフトウェア工学では、変化に対して十分な考慮がないが、現代のソフトウェア工学では、変化を許容する。 拡張性を向上するためには、2つの原則がある。
- 設計の単純さ: シンプルな方が変更に適応をしやすい
- 非集中化:モジュールの自治性(基準/規則/原則に応じている)場合、変更後の全体への連鎖反応を減らせる
互換性
互換性とは、ソフトウェアの要素、ほかのソフトウェア要素との組み合わせやすさである。
ソフトウェアは他のソフトウェアと相互に作用し合う。ソフトウェアがそれ単体で存在するものではない。よって、互換性が重要である。 設計の同質化と、プロトコルが一致することを目指す。
効率性
効率性とは、処理時間、内部記憶および外部記憶上の空間、通信装置で使用する帯域幅などのハードウェア資源をできる限り必要としないソフトウェアシステムの能力である。
効率性は以下の理由によって無視をできない。
- 来年、50%機能が向上するハードウェアが存在しても、向上分は他の機能にあてがわれるため。ハードウェアの性能向上に依存することは運任せてきなところがある。
- 良いアルゴリズムであれば、ハードウェアの性能向上の恩恵を受けやすい
- 効率性が 正確さ に影響を与えるケースがあるため。天気予報のシミュレーションに24時間かかってしまったら、正確さがないがしろにされていることになる
効率化に対するソフトウェア業界は2つの態度に分かれる。固着する人と軽視する人。バランスを取らねばならない。
可搬性
可搬性とは多様なハードウェアおよびソフトウェア環境へのソフトウェア製品の移植のしやすさである。
使いやすさ
使いやすさとは、経験も資格も異なる人々がいかに容易にソフトウェア製品の利用法を学習し、問題解決に応用できるかである。これにはインストールや、操作、監視の容易さも含まれる。
成功したソフトウェアは、最初に意図したユーザより広い範囲のユーザに使用される様になる。よって、ユーザについての前提条件はできるだけ作らないほうがよい。 ユーザは人類で、読むこと、マウスを動かすこと、ボタンをクリックすること、ゆっくりとキーボード入力することのみを前提条件とする
古典的で有名な例を2つあげると、 FortranはIBM 704のプログラミングをするエンジニアと科学者の小さなグループの問題を解決するツールとして考えられていた。Unixはベル研究所内部で使用する意図で作られた
機能性
機能性とは、そのシステムが提供できるサービスの範囲である。 プロジェクトリーダーが直面する最も困難な課題の1つは、どの程度の機能性があれば十分かを判断することである。この業界では 機能主義 という呼び方で知られているが、より多くの機能を求める圧力は常に存在する。
機能主義の問題は2つの分けることができる。簡単な問題とより困難な問題である。 簡単な方は、「新しい機能の追加によって使いやすさが損なわれ、一貫性が失われるということ」である。 新しい機能の追加によって複雑になったというユーザの声を鵜呑みにしてはならない。私にとって不要だが、他者にとっては不可欠な機能である可能性がある。
難しい方は、「機能に集中するあまり他の品質要因を忘れがちになること」である。 より多くの機能を追加する場合、 熱狂的な競争の中で全体的な品質は見失われてしまう 。
適時性
適時性とはユーザが必要としているとき、または、必要とする前にソフトウェアシステムをリリースできることである。
偉大なソフトウェアでも、機を逃せばターゲットそのものを失う恐れがある。適時性は常に圧力がある。
番外: 保守性
保守は、ソフトウェア製品が納品された後に発生するものであるため、ソフトウェアの方法論を論じる場合はあまり語られない。ただし、 ソフトウェアにかかるコストの70%は保守に費やされているため、この側面を無視したソフトウェアの品質研究は完全とは言えない
保守コストの内訳は1位はユーザ要求の変更である。つまり、 ソフトウェアは変化する 。仕様のみならず、納品され一時期でも使用されていたソフトウェアすら変化する。2位は、データフォーマットの変更である。
なぜデータフォーマットの変更にコストがかかるのか
プログラムのある部分がデータ構造を知っている...ということが問題ではない。そもそもプログラムとは、内部処理をする過程で データにアクセスしなければならない 。内部でアクセスされるデータ構造が変更される場合、データのアクセスが行われる各所は、 そのデータがどんなデータであるか を 前提条件として 、プログラム全体に埋め込まれているためである。
これは、仕様変更の概念的大きさと釣り合わない大規模なプログラム変更の必要性を示唆する。
また、研究により以下のことがわかっている
- 効率性向上のための修正は割合が少ない。ひとたびシステムが動作すると、システムを破壊するよりはそっとしておくことを選ぶことが多い。
- 新しい環境への移植の割合も少ない。可搬性については、2種類しかなく、中間は少ない。つまり、 もともと可搬性を考えられて作られたプログラム とそうでないプログラムである。後者はあまりにもコストがかかるので、誰もやらない。
特に重要な事柄
- 正確さと頑丈さ: 上記でも述べられている通り、他の要因をナシにするほど大事な事柄である。実現のために、体系的なソフトウェア構築、形式的な仕様、CI/CD、そもそもの欠陥に気づける各種仕組み(型、例外処理など)などがある。この2つの要因をあわせて 信頼性 とも言う
- 拡張性と再利用性: ソフトウェアをモット変えやすく。この2つの要因をあわせて モジュール性 とも言う
