出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。記事の信頼性向上にご協力をお願いいたします。（2019年8月）

ソフトウェア品質（ソフトウェアひんしつ、英: Software quality）は、ソフトウェアの品質を指し、プログラマの観点からはソースコードの品質、エンドユーザーの観点からはアプリケーションソフトウェアの品質を意味する。

ソフトウェア品質の定義は様々である。ジェラルド・ワインバーグは著書 Quality Software Management: Systems Thinking v. 1 で「品質とは誰かにとっての価値である」と書いている。この定義は品質が本来主観的なものであることを強調している。同じソフトウェアであっても人によって品質の感じ方は全く異なる。この定義の利点は、ソフトウェア開発チームに「このソフトウェアは誰のために作っているのか?」とか「彼らにとって価値とは何か?」といった疑問を抱かせる点にある。

品質を「目的への適合性」と定義する場合、品質を測定するのに使うべき尺度（属性）を決定する際に、そのソフトウェアの目的を考慮する必要があることを意味する。
概要
ソフトウェア製品品質

商品品質

要求仕様やプログラム仕様への適合性（後述する「ソフトウェアの信頼性」に関連する）


スケーラビリティ

正当性


完全性

バグが無いこと

フォールトトレラントシステム

拡張性

保守性


ソフトウェアドキュメンテーション

ソースコード品質

コンピュータにとっては、きれいに書かれたソースコードという概念には意味が無い。しかし人間にとっては、プログラムがどう書かれているかはそれを保守する際に重要な意味を持つ。様々なプログラミング作法は、可読性や言語固有の規約を強調してソースコードの保守性を向上させ、デバッグや修正を容易にする。他にもうまく書かれたコードという概念には、コードが管理可能な部分に論理的に分割されていることなども含まれる。

可読性

ソフトウェア保守、ソフトウェアテスト、デバッグ、バグ修正、改造、移植の容易性

複雑すぎないこと

リソース（記憶装置、CPU）を過度に必要としないこと

コンパイルやlintでの警告数

適切なコメント

品質向上の手法: リファクタリング
CLEAN

デビッド・スコット・バーンスタインは、レガシーコードからの脱却で良いソフトウェアの土台となる5つのコード品質として以下を挙げ、CLEANと名付けている。[1]

Cohesive（凝集性）：特性が明確に定義されているべき

Loosely Coupled（疎結合）：はっきりした責務を担うべき

Encapsulated（カプセル化）：実装は隠蔽されるべき

Assertive（断定的）：オブジェクトの状態は自分自身が管理すべき

Nonredundant（非冗長）オブジェクトの定義は一度だけにすべき

ソフトウェアの信頼性

ソフトウェアの信頼性（reliability）は、ソフトウェア品質を測る重要な尺度であり観点である。品質（quality）という用語には主観的（定性的）要素が含まれるが、ソフトウェアの信頼性は客観的な基準で測定可能である。このような測定基準を一般にソフトウェアメトリックと呼ぶ。ソフトウェアの信頼性改善の実際の作業は、ソフトウェア開発を扱いやすく理解可能なものにするという圧力によってなされてきたもので、収益を求めてのものではない。しかし、ソフトウェア産業の成熟と共に、ユーザーがソフトウェア製品に期待する品質レベルは高くなり、信頼性の確保が収益に繋がるという状況ができつつある。

組み込みシステムでは、ソフトウェアの問題は単なる不便以上の問題を生じる。場合によっては人命にも関わる。その原因はユーザインタフェースの貧弱さから直接的なバグまで様々である。多くの人命に関わったプログラムのバグについては、Levenson の論文 Medical Devices: The Therac-25[※ 1] に詳しい。結果として、ソフトウェアの信頼性に関する要求仕様が生まれた。アメリカ合衆国では、アメリカ食品医薬品局 (FDA) と連邦航空局 (FAA) がソフトウェア開発についてその種の要求仕様を策定している。
信頼性の目標

現代の工学分野の技術をソフトウェア開発に適用するため、ソフトウェアの品質を客観的に判断する方法が必要とされる。これは、誰が見てもコンピュータソフトウェアは予定通りの動作をしないという一般的観測結果に基づいた動機である。言い換えれば、ソフトウェアは何らかの問題を抱えていると不適当な動作を見せる。その原因は処理中のデータの問題だったり、ソフトウェアが動作するハードウェアの問題だったり、操作者などがそのマシンに悪影響を及ぼしたためだったりする。経済活動や生産プロセス、生命維持に直接関わるシステムなどのより重要なソフトウェアでは、ソフトウェアの信頼性を評価する必要性も大きくなる。

あるソフトウェアアプリケーションの重要さの度合いによらず、ソフトウェアは我々の生活のあらゆる面に深く浸透している。我々の社会基盤がソフトウェアに依存している限り、この浸透は続くと予想される。社会基盤がソフトウェアへの依存を強めるにつれて、ソフトウェアの信頼性のレベルの向上が求められるようになってきた。すなわち、ソフトウェアは意図したように動作すべきであり、常に改良が求められる。
信頼性への挑戦

前節の循環しているような文章は偶然ではない。これはソフトウェアの信頼性の測定に関する基本的問題を表している。信頼性は判断が難しく、特に事前にソフトウェアがどう使われるかを正確に想定することは難しい。問題は、従来ならば人間が担っていたであろう役割をソフトウェアが代替しているという共通の概念的錯覚から生じる。この問題は2つのレベルに分けられる。第一に、最新のソフトウェアは人間にはできないようなことを実行し、特に人間に比較するとその信頼性は非常に高い。第二に、ソフトウェアは人間の精神的な面を代替することはできない。つまり、融通を利かせるとか、常識を働かせるとか、概念的なことを理解する能力はない。

それにもかかわらず、多くのソフトウェアプログラムは何らかの目的を持つと見なすことができる。目的が明確に定義されるならば、ソフトウェアにある環境であるデータを与えたときに、予測される結果と実際の結果を比較することでその信頼性を客観的に判断することができることが期待される。しかし今のところ、プログラムに環境とデータを与えたときに、予測される結果や実際の結果を正確に求めることが可能かどうか定かではない。そして、そのような手段がなければ、プログラムの信頼性を確実性をもって決定することはできない。

しかし、実際のプログラムやプログラムの理論的記述について、その環境や入力による振る舞いを明らかにしようという試みはこれまでも数多くなされてきた。ソフトウェアの信頼性を改善するためのその種の試みは、実際のソフトウェア開発では様々な工程（要求仕様、設計、プログラミング、テスト、実行時評価）に適用される。ソフトウェアの理論的な信頼性の研究は、主に正当性の概念を扱い、形式言語やオートマトンといった計算機科学の数学的分野から派生している。
プログラム開発における信頼性
要求仕様

プログラムの開発者が「どう動作すべきか」を事前または開発中に詳細に把握していなければ、それが望ましい動作をすることは期待できない。どの程度詳細に把握すべきかは議論の余地がある。完璧な詳細さという考え方は魅力的だが、実際問題としては現実的ではない。なぜなら、「こうあるべき」という要求仕様は試行錯誤的に変化するものだからである。

事前に要求仕様をうまく記述できるかどうかは信頼性の分かれ目であり、要求仕様の形式化（モデリング言語などの利用）が採用されるのはそのためである。また、プログラマ以外の専門家でない人々にそのソフトウェアの振る舞いを正しく伝達する手段でもある。実際には、プログラマも「どう動作するか」を事前に把握していないことが多く、それが要求仕様に関する議論を困難にしている。
設計

要求仕様がプログラムがすべきことを記述するのに対して、ソフトウェア設計ではプログラムがそれをどのようにすべきかを記述する。設計工程の有用性には異論もあるが、信頼性の観点からはソフトウェア設計工程の重要性が指摘されている。