ソフトウェア品質
デビッド・スコット・バーンスタインは、レガシーコードからの脱却で良いソフトウェアの土台となる5つのコード品質として以下を挙げ、CLEANと名付けている。
Cohesive(凝集性):特性が明確に定義されているべき
Loosely Coupled(疎結合):はっきりした責務を担うべき
Encapsulated(カプセル化):実装は隠蔽されるべき
Assertive(断定的):オブジェクトの状態は自分自身が管理すべき
Nonredundant(非冗長)オブジェクトの定義は一度だけにすべき
無駄な情報がないことを意味する。メモリ容量が限られている環境では重要である。また、コードの行数を削減することも様々な意味で重要である。同じ機能を実現するコードが繰り返し出現する箇所をサブルーチン化することで改善される。また、文書についても同様のことが言える。
ソフトウェア品質の測定には様々な観点がある。しかし、万人が納得する測定の観点は珍しい。人によってはソフトウェア品質の定量的測定が必須であるとされるが、他の人は定量的測定が有効な場面は限られると考えており、そのため定性的測定を好む。真に望ましい測定を行うことの難しさはソフトウェアテストの分野の権威が何人か書いている。例えば、Cem Kaner(英語版) の Software Engineering Metrics: What Do They Measure and How Do We Know? と Douglass Hoffman The Darker Side of Metrics がある。
よく使われるメトリックの例として、検出バグ数がある。バグの少ないソフトウェアはバグの多いソフトウェアに比べて品質が高いとされる。以下のような質問の回答を考えることで、このメトリックが特定の場面で役立つかどうかを考えることができる。
どんなバグが多いのか? ソフトウェアの目的の違いを考慮しているか? ソフトウェアの規模や複雑さの違いを考慮しているか?
バグの重大性を考慮しているか? 障害の重大性やユーザーへの影響によって重み付けしているか?
ソフトウェアの技術的品質に加えて、エンドユーザーの経験もソフトウェアの品質を決定する。この種のソフトウェア品質をユーザビリティと呼ぶ。ソフトウェア製品のユーザビリティを定量化することは困難である。ユーザビリティを定性的に明らかにするための重要な質問を以下に列挙する。
ユーザインタフェースは直観的か?
単純な操作はやさしいか?
複雑な操作は適切か?
エラーメッセージは分かりやすいか?
ウィジェットは期待通りに動作するか?
文書は十分か?
ユーザインタフェースの反応性は良いか?
また、有料か無料かを問わず、サポートが得られるかどうかもソフトウェアのユーザビリティを左右する。
不正なアクセスからデータやプログラム自身が守られているか? セキュリティポリシーを操作者が設定可能か? 適切なセキュリティ機構を備えているか? そのセキュリティ機構の実装は正しいか? 攻撃を想定した設計になっているか? 脆弱性の原因となるような問題(バッファオーバーラン、書式文字列問題など)をはらんでいないか?
ソフトウェア品質(ソフトウェアひんしつ、英: Software quality)は、ソフトウェアの品質を指し、プログラマの観点からはソースコードの品質、エンドユーザーの観点からはアプリケーションソフトウェアの品質を意味する。
ソフトウェア品質の定義は様々である。ジェラルド・ワインバーグは著書 Quality Software Management: Systems Thinking v. 1 で「品質とは誰かにとっての価値である」と書いている。この定義は品質が本来主観的なものであることを強調している。同じソフトウェアであっても人によって品質の感じ方は全く異なる。この定義の利点は、ソフトウェア開発チームに「このソフトウェアは誰のために作っているのか?」とか「彼らにとって価値とは何か?」といった疑問を抱かせる点にある。
品質を「目的への適合性」と定義する場合、品質を測定するのに使うべき尺度(属性)を決定する際に、そのソフトウェアの目的を考慮する必要があることを意味する。