ソフトウェアの品質

ソフトウェア工学の文脈では、ソフトウェア品質は2つの関連しているが異なる概念を指します。^{[引用が必要]}

• ソフトウェアの機能品質は、機能要件や仕様に基づいて、特定の設計にソフトウェアがどれだけ適合しているかを反映します。 ^{[1]この属性は、ソフトウェアの目的への適合性、または市場での競合製品との比較で価値のある}製品としてどの程度優れているかを表すこともできます。^{[2]これは、}適切なソフトウェアが作成された度合いです。
• ソフトウェアの構造品質とは、堅牢性や保守性など、機能要件の実現をサポートする非機能要件をソフトウェアがどの程度満たしているかを指します。ソフトウェアが必要に応じてどの程度動作するかということに大きく関係しています。

構造品質の多くの側面は、ソフトウェアの内部構造、ソースコード（ソフトウェアメトリクスを参照）^[3] 、ユニットレベル、システムレベル（エンドツーエンドテストと呼ばれることもある^{[4] ）の分析を通じて}静的にのみ評価できます。これは、実際には、そのアーキテクチャが、オブジェクト管理グループ（OMG）によるこのトピックに関する論文で概説されているソフトウェアアーキテクチャの健全な原則に準拠しているかどうかです。^[5]

ユーザビリティなどの構造的品質は、動的にのみ評価できます(ユーザーまたはユーザーに代わって行動する他の人がソフトウェア、または少なくともプロトタイプまたは部分的な実装と対話します。段ボールで作成された模擬バージョンとの対話でさえ、そのようなバージョンはプロトタイプと見なすことができるため、動的テストになります)。信頼性などの他の側面は、ソフトウェアだけでなく基礎となるハードウェアにも関係する可能性があるため、静的および動的の両方で評価できます (ストレス テスト)。^[要出典]

自動テストと適合関数を使用すると、品質に関連する属性の一部を維持するのに役立ちます。^[6]

機能品質は通常は動的に評価されますが、静的テスト（ソフトウェアレビューなど）を使用することもできます。^[要出典]

歴史的に、ソフトウェア品質管理に適用される属性と測定基準の構造、分類、用語は、ISO 9126とそれに続くISO/IEC 25000規格から派生または抽出されてきました。 ^[7]これらのモデル（モデルを参照）に基づいて、ITソフトウェア品質コンソーシアム（CISQ）は、ソフトウェアがビジネス価値を提供するために必要な5つの主要な望ましい構造特性を定義しました：^[8]信頼性、効率性、セキュリティ、保守性、および（適切な）サイズ。^{[9] [10] [11]}

ソフトウェア品質の測定は、ソフトウェア プログラムまたはシステムがこれら 5 つの側面のそれぞれに沿ってどの程度評価されているかを定量化します。ソフトウェア品質の総合的な測定は、定性的または定量的なスコアリング スキーム、またはその両方の組み合わせと、優先順位を反映する重み付けシステムによって計算できます。ソフトウェア品質を線形連続体上に位置付けるこの見方は、「重大なプログラミング エラー」の分析によって補完されます。重大なプログラミング エラーは、特定の状況下では壊滅的な停止やパフォーマンスの低下を引き起こし、総合的な測定に基づく評価に関係なく、特定のシステムを使用できなくする可能性があります。システム レベルで見つかったこのようなプログラミング エラーは、製造上の問題の最大 90 パーセントを占めますが、ユニット レベルでは、はるかに多くても、プログラミング エラーは製造上の問題の 10 パーセント未満を占めます ( 90-90 ルールも参照)。その結果、W. Edwards Demingが述べたように、システム全体のコンテキストのないコード品質の価値は限られています。^{[引用が必要]}

ソフトウェア品質の測定値を表示、調査、分析、伝達するために、情報視覚化の概念と技術は、特に複数のソフトウェア品質測定値を相互に、またはソフトウェアやシステムのコンポーネントに関連付ける必要がある場合に便利な視覚的でインタラクティブな手段を提供します。たとえば、ソフトウェアマップは、 「ソフトウェア開発、ソフトウェア品質、およびシステムダイナミクスに関する情報を表現し、組み合わせることができる」特殊なアプローチを表しています。^[12]

ソフトウェア品質は、ソフトウェアプロジェクトのリリースフェーズでも重要な役割を果たします。具体的には、リリースプロセス（パッチプロセスも含む）の品質と確立、^{[13] [14]} 構成管理^[15]は、全体的なソフトウェアエンジニアリングプロセスの重要な部分です。^{[16] [17] [18]}

ソフトウェアの品質は、少なくとも 2 つの主な観点によって決まります。

• リスク管理: ソフトウェア障害は不便以上のものを引き起こします。ソフトウェア エラーは人命を奪う可能性があります (例:ソフトウェア バグの一覧を参照)。原因は、ユーザー インターフェイスの設計不良から直接的なプログラミング エラーまで多岐にわたります。^{[19] [20] [21]}たとえば、 Boeing 737 のケースや意図しない加速のケース^{[22] [23]}またはTherac-25 のケースを参照してください。^[24]これにより、特定の種類のソフトウェアの開発、特に歴史的には重要なインフラストラクチャを制御する医療機器やその他のデバイスに組み込まれたソフトウェアの開発が求められました。「[組み込みソフトウェアを作成するエンジニアは] Java プログラムがガベージ コレクションを実行してユーザー インターフェイスを更新するために 3 分の 1 秒間停止するのを見て、飛行機が空から落ちていくのを思い浮かべます。」^[25]米国では、連邦航空局(FAA) 内の FAA 航空機認証サービスがソフトウェア プログラム、ポリシー、ガイダンス、トレーニングを提供し、航空機製品 (「製品」は航空機、エンジン、またはプロペラ) に影響を与えるソフトウェアと複雑な電子ハードウェアに重点を置いています。^[26] DO-178C、ISO 26262、IEC 62304などの認証規格がガイドラインを提供している。
• コスト管理: 他の工学分野と同様に、優れたソフトウェア品質によって管理されているソフトウェア製品やサービスは、維持コストが低く、理解しやすく、差し迫ったビジネスニーズに応じてコスト効率よく変更できます。^[27]業界データによると、コアビジネスアプリケーション（エンタープライズリソースプランニング（ERP）、顧客関係管理（CRM）、金融サービスの大規模トランザクション処理システムなど）のアプリケーション構造の品質が低いと、コストとスケジュールの超過が発生し、やり直しという形で無駄が生じます（ムダ（日本語の用語）を参照）。^{[28] [29] [30]}さらに、構造品質の低さは、破損したデータ、アプリケーションの停止、セキュリティ侵害、パフォーマンスの問題による影響の大きいビジネスの混乱と強く相関しています。^[31]
  • CISQ は、品質の低さによるコストについて、次のような影響を報告しています。
    • 2020年には2兆800億ドル^{[32] [33]}
    • 2018年は2兆8,400億ドル
  • IBMの2020年データ侵害コストレポートでは、データ侵害の平均的な世界コストは次のように推定されています。^{[34] [35]}
    • 386万ドル

ソフトウェア品質とは、「ソフトウェア製品が要件に適合する能力」です。^{[36] [37]}一方、他の人にとっては、顧客創造や価値創造と同義です。 ^{[38] [39]}あるいは欠陥レベルですらあります。^[40]ソフトウェア品質の測定は、プロセス品質、内部および外部特性を含む製品品質、そして最後にソフトウェアの効果である使用時の品質の3つの部分に分けられます。^[41]

ASQでは、次のような定義が用いられている。「ソフトウェア品質とは、ソフトウェア製品の望ましい特性を記述するものである。欠陥管理と品質特性という2つの主要なアプローチがある。^」[42]

ソフトウェアアシュアランス（SA）は、資産とそれを達成するためのプロセスの両方をカバーします。^[43]

• [正当な] ソフトウェアには、意図的に設計された脆弱性も、ライフサイクルのどの時点でも偶然に挿入された脆弱性もなく、ソフトウェアが意図したとおりに機能するという確信
• ソフトウェアライフサイクルプロセスと製品が要件、標準、および手順に準拠していることを保証する、計画的かつ体系的な一連の活動。

プロジェクトマネジメント協会のPMBOKガイド「ソフトウェア拡張」では、 「ソフトウェア品質」そのものではなく、ソフトウェア品質保証（SQA）を「他のソフトウェアプロセスを監査し、それらのプロセスが遵守されていることを確認する継続的なプロセス（たとえば、ソフトウェア品質管理計画を含む）」と定義しています。一方、ソフトウェア品質管理（SCQ）は、「開発中または修正中のソフトウェアの品質要件に対する作業成果物の満足度を保証するために、方法、ツール、技術を適用することに気を配ること」を意味します。^[44]

歴史上記憶に残る品質の最初の定義は、20世紀初頭のシューハートによるものである。「品質には2つの共通の側面がある。1つは、人間の存在とは無関係な客観的現実として物の品質を考慮することである。もう1つは、客観的現実の結果として私たちが考え、感じ、感知することである。言い換えれば、品質には主観的な側面がある。」^[45]

キッチンハムとプフリーガーは、デイヴィッド・ガービンの教えをさらに報告し、品質に関する5つの異なる視点を特定しています。^{[46] [47]}

• 超越論的観点は、品質の形而上学的側面を扱っています。この品質観では、品質とは「私たちが理想として目指すものでありながら、完全に実現することは決してできないもの」です。^[48]定義することは困難ですが、かつて連邦判事が猥褻について述べた「見ればわかる」という言葉に似ています。^[49]
• ユーザーの視点は、特定の使用状況に対する製品の適切性に関係しています。超越的な視点が空想的であるのに対し、ユーザーの視点はより具体的で、ユーザーのニーズを満たす製品の特性に基づいています。^[48]
• 製造の観点からは、品質は要件への適合として表されます。品質のこの側面は、ISO 9001などの規格で強調されており、ISO 9001では品質を「一連の固有の特性が要件を満たす程度」と定義しています（ISO/IEC 9001 ^[50]）。
• 製品の観点では、製品の固有の特性を測定することによって品質を評価できることを意味します。
• 品質の最後の観点は価値に基づいています。^[38]この観点は、品質の異なる観点が、さまざまな利害関係者にとって異なる重要性や価値を持つ可能性があることを認識しています。

製品、ほとんどすべての製品の品質を定義しようとする試みに内在する問題は、巨匠ウォルター・A・シューハートによって述べられました。品質を定義することの難しさは、ユーザーの将来のニーズを測定可能な特性に変換し、ユーザーが支払う価格で満足感を与える製品を設計し、生産できるようにすることです。これは簡単なことではなく、その試みがかなり成功したと感じた途端、消費者のニーズが変化し、競合他社が参入してきたことなどに気付くのです。^[51]

—  W. エドワーズ デミング

品質は顧客が決めるものであり、エンジニアやマーケティング、経営全般が決めるものではない。品質は、顧客が製品やサービスに対して実際に体験したことに基づいており、顧客の要求事項（明示的か非明示的か、意識的か単に感知されたか、技術的に運用可能か完全に主観的か）に照らして測定され、競争の激しい市場において常に変化する目標を表している。^[52]

品質という言葉には複数の意味がある。この言葉は主に2つの意味で使われている。1. 品質とは、顧客のニーズを満たし、それによって製品に満足感を与える製品の特徴である。2. 品質とは、欠陥がないことである。しかし、このようなハンドブックでは、品質という言葉を「使用に適していること」という短い定義に標準化するのが便利である。^[53]

トム・デマルコは、「製品の品質は、それが世界をどれだけ良い方向に変えるかによって決まる」と提唱しています。^[要出典]これは、ソフトウェアの品質を決定する上で、構造的な品質よりも機能的な品質とユーザー満足度の方が重要であるという意味に解釈できます。

ジェラルド・ワインバーグが『品質ソフトウェア管理：システム思考』で作ったもう一つの定義は、「品質とは、ある人にとっての価値である」というものである。^{[54] [55]}

品質を定義する際の課題の1つは、「誰もがそれを理解していると感じている」ことであり^[56]、ソフトウェア品質の他の定義は、ビジネスで使用される品質の概念のさまざまな説明を拡張することに基づく可能性があります。

ソフトウェア品質は、品質保証や問題解決管理^[57]、品質管理^[58] 、DevOpsと混同されることもよくあります。前述の領域と重複していますが（PMIの定義も参照）、テストだけでなくプロセス、管理、改善、評価などにも焦点を当てている点で特徴的です。^[58]

このセクションで紹介した概念は、構造的品質と機能的品質の両方に適用できますが、後者の測定は基本的にソフトウェアテストを通じて行われます。^[59]テストだけでは不十分です。ある調査によると、「個々のプログラマーは、自分のソフトウェアのバグを見つけるのに50％未満の効率しかなく、ほとんどのテストの効率は35％にすぎません。これにより、[ソフトウェア]品質を判断することが困難になります。」^[60]

ソフトウェア品質の測定は、システムまたはソフトウェアがどの程度望ましい特性を備えているかを定量化することです。これは、定性的または定量的、あるいはその両方の組み合わせで実行できます。どちらの場合も、望ましい特性ごとに、ソフトウェアまたはシステムに存在する測定可能な属性のセットがあり、その特性と相関関係があり、関連付けられる傾向があります。たとえば、移植性に関連付けられている属性は、プログラム内のターゲット依存ステートメントの数です。より正確には、品質機能展開アプローチを使用すると、これらの測定可能な属性は、上記のソフトウェア品質定義の「何」を実現するために実施する必要がある「方法」です。

ソフトウェア品質管理に適用される属性とメトリックの構造、分類、用語は、ISO 9126-3とそれに続く ISO/IEC 25000:2005 品質モデルから派生または抽出されています。主な焦点は内部構造品質にあります。サブカテゴリは、ビジネス アプリケーション アーキテクチャや、データ アクセスや操作、トランザクションの概念などの技術的特性などの特定の領域を処理するために作成されています。

ソフトウェア品質特性とその測定可能な属性間の依存関係ツリーは、右の図に示されています。ここでは、ユーザー (右) またはビジネス システムの所有者にとって重要な 5 つの特性のそれぞれが、測定可能な属性 (左) に依存しています。

• アプリケーションアーキテクチャの実践
• コーディングの実践
• アプリケーションの複雑さ
• ドキュメント
• ポータビリティ
• 技術および機能ボリューム

プログラミングエラーと製造欠陥の相関関係から、基本的なコードエラーがソースコード全体のエラーの92%を占めていることが明らかになりました。これらの多数のコードレベルの問題は、最終的には製造時の欠陥のわずか10%を占めるに過ぎません。アーキテクチャレベルでの不適切なソフトウェアエンジニアリングの実践は、全体の欠陥のわずか8%を占めるに過ぎませんが、問題の修正に費やされる労力の半分以上を消費し、製造時の深刻な信頼性、セキュリティ、効率の問題の90%につながります。^{[61] [62]}

^{既存のソフトウェア指標の多くは、ソースコードを解析して個々の命令[63]、}トークン^[64]、制御構造（複雑性）、オブジェクト^[65]などを解析したアプリケーションの構造要素をカウントします。

ソフトウェア品質の測定は、システムまたはソフトウェアがこれらの側面でどの程度評価されているかを定量化することです。分析は、定性的または定量的アプローチ、あるいはその両方を組み合わせて実行して、総合的なビューを提供することができます (たとえば、測定対象の要素間の相対的な重要性を反映する加重平均を使用)。

ソフトウェア品質を線形連続体として捉えるこの考え方は、個別の重大なプログラミングエラーの特定によって補完される必要がある。これらの脆弱性はテストケースで不合格にならないかもしれないが、特定の状況下では壊滅的な停止、パフォーマンスの低下、セキュリティ侵害、データの破損、その他さまざまな問題^[66]につながる可能性のある悪い習慣の結果であり、集計された測定値に基づく評価に関係なく、特定のシステムを事実上使用に適さないものにする。脆弱性のよく知られた例としては、共通弱点列挙^[67]がある。これは、アプリケーションをセキュリティ侵害にさらすソースコードの脆弱性のリポジトリである。

重要なアプリケーション特性の測定には、上の図に示すように、アプリケーションのアーキテクチャ、コーディング、インライン ドキュメントの構造的属性の測定が含まれます。したがって、各特性は、アプリケーション内のさまざまな抽象化レベルの属性の影響を受けます。ビジネスに影響する品質成果の貴重な予測子にするには、特性の測定値の計算にこれらすべてを含める必要があります。上の図に示されている特性測定値を計算する階層化アプローチは、Boehm と TRW の同僚によって最初に提案され (Boehm、1978) ^[68]、ISO 9126 および 25000 シリーズ標準で採用されているアプローチです。これらの属性は、アプリケーション ソース コードの静的分析の解析結果から測定できます。信頼性やパフォーマンス効率などのアプリケーションの動的特性でさえ、その原因はアプリケーションの静的構造にあります。

構造品質の分析と測定は、システムの概念的および論理的アーキテクチャを定義する原則と標準に関連して、ソース コード、アーキテクチャ、ソフトウェア フレームワーク、データベース スキーマを分析することによって実行されます。これは、主に実装の考慮事項に関係し、デバッグおよびテストアクティビティ 中に重要な、開発ツールによって通常実行される基本的なローカル コンポーネント レベルのコード分析とは異なります。

信頼性が低い根本的な原因は、優れたアーキテクチャとコーディング プラクティスに準拠していないことにあります。この非準拠は、アプリケーションの静的な品質属性を測定することで検出できます。アプリケーションの信頼性の基礎となる静的属性を評価すると、ビジネス リスクのレベルと、アプリケーションを運用したときに発生する可能性のあるアプリケーションの障害や欠陥の可能性を推定できます。

信頼性を評価するには、少なくとも次のソフトウェア エンジニアリングのベスト プラクティスと技術的属性をチェックする必要があります。

アプリケーション アーキテクチャと使用されるサードパーティ コンポーネント (外部ライブラリやフレームワークなど) に応じて、配信されたソフトウェアの信頼性をより適切に評価できるように、上記のベスト プラクティスのリストに沿ってカスタム チェックを定義する必要があります。

信頼性と同様に、パフォーマンスの非効率性の原因は、アプリケーションの静的な品質属性を測定することで検出できる、優れたアーキテクチャおよびコーディング プラクティスの違反にあることがよくあります。これらの静的属性は、特に複雑なアルゴリズムや膨大な量のデータを処理するために高い実行速度を必要とするアプリケーションの場合、潜在的な運用パフォーマンスのボトルネックと将来のスケーラビリティの問題を予測します。

パフォーマンス効率を評価するには、少なくとも次のソフトウェア エンジニアリングのベスト プラクティスと技術的属性を確認する必要があります。

• アプリケーションアーキテクチャの実践
• 高価なリソースや遠隔地のリソースとの適切なやり取り
• データアクセスパフォーマンスとデータ管理
• メモリ、ネットワーク、ディスクスペースの管理
• コーディング規約の遵守^[69] (ベストコーディング規約)

ソフトウェアの品質にはソフトウェアのセキュリティが含まれます。^[70]多くのセキュリティ上の脆弱性は、SQLインジェクションやクロスサイトスクリプティングなどの不適切なコーディングやアーキテクチャの慣行に起因しています。^{[71] [72]これらは、CWE、 [73]}およびカーネギーメロン大学のSEI /コンピュータ緊急センター（CERT）によって維持されているリストに詳しく文書化されています。^[69]

セキュリティを評価するには、少なくとも次のソフトウェア エンジニアリングのベスト プラクティスと技術的属性を確認する必要があります。

• セキュリティを考慮した開発プロセスの強化と実装、管理。例：セキュリティ開発ライフサイクル（Microsoft）やIBMのセキュアエンジニアリングフレームワーク。^[74]
• セキュアアプリケーションアーキテクチャの実践^{[75] [76]}
• 多層設計コンプライアンス
• セキュリティのベストプラクティス（入力検証、SQLインジェクション、クロスサイトスクリプティング、アクセス制御など）^{[77] [78]}
• 安全で優れたプログラミングプラクティス^[69]
• エラーと例外の処理

保守性には、モジュール性、理解可能性、変更可能性、テスト可能性、再利用可能性、および開発チーム間での移転可能性の概念が含まれます。これらは、コードレベルでは重大な問題という形をとりません。むしろ、保守性の低さは、ドキュメント、複雑さの回避戦略、および基本的なプログラミング手法におけるベストプラクティスに対する何千もの小さな違反の結果であることが多く、クリーンで読みやすいコードと整理されていない読みにくいコードの違いを生み出します。^[79]

保守性を評価するには、次のソフトウェア エンジニアリングのベスト プラクティスと技術的属性を確認する必要があります。

保守性は、保守性の欠如から生じるコストを表現するウォード・カニンガムの技術的負債の概念と密接に関連しています。保守性が低い理由は、無謀対慎重、意図的対不注意に分類できます。 ^{[80] [81]}多くの場合、開発者の能力不足、時間や目標の不足、不注意、ドキュメント、特に保守可能なソースコードの作成コストと利点の不一致に起因します。^[82]

ソフトウェアのサイズを測定するには、データベース構造スクリプト、データ操作ソース コード、コンポーネント ヘッダー、構成ファイルなど、ソース コード全体を正しく収集する必要があります。測定するソフトウェアのサイズには、基本的に、技術的なサイズ (フットプリント) と機能的なサイズの 2 種類があります。

• ソフトウェアの技術的なサイジング方法はいくつかあり、広く説明されています。最も一般的な技術的なサイジング方法は、テクノロジごとのコード行数(#LOC)、ファイル数、関数数、クラス数、テーブル数などであり、そこからバックファイアリング機能ポイントを計算できます。
• 機能サイズを測定する最も一般的な方法は、機能ポイント分析です。機能ポイント分析は、ユーザーの観点からソフトウェア成果物のサイズを測定します。機能ポイントのサイズ設定は、ユーザーの要件に基づいて行われ、開発者/見積り担当者向けのサイズと価値 (提供される機能) の両方を正確に表し、顧客に提供されるビジネス機能を反映します。この方法には、ユーザーが認識できる入力、出力、およびデータ ストアの識別と重み付けが含まれます。サイズ値は、ソフトウェアの配信とパフォーマンスを定量化および評価するためのさまざまな基準 (機能ポイントあたりの開発コスト、機能ポイントあたりの配信された欠陥、スタッフ 1 か月あたりの機能ポイント) と組み合わせて使用​​できます。

ファンクション ポイント分析のサイズ設定標準は、国際ファンクション ポイント ユーザー グループ ( IFPUG ) によってサポートされています。ソフトウェア開発ライフサイクルの早い段階で適用でき、やや不正確なバックファイアリング メソッドのようにコード行に依存しません。このメソッドはテクノロジに依存せず、組織間および業界間での比較分析に使用できます。

ファンクション ポイント分析の開始以来、いくつかのバリエーションが進化し、機能サイジング手法のファミリーは、COSMIC、NESMA、ユース ケース ポイント、FP Lite、早期 FP とクイック FP、そして最近ではストーリー ポイントなどのサイジング測定を含むように拡大しました。ファンクション ポイントは統計的正確性の歴史があり、多数のアプリケーション開発管理 (ADM) またはアウトソーシング契約で共通の作業測定単位として使用されており、サービスが提供され、パフォーマンスが測定される「通貨」として機能しています。

ファンクション ポイント方法論の一般的な制限の 1 つは、手動プロセスであるため、アプリケーション開発やアウトソーシング契約などの大規模な取り組みでは、労働集約的でコストがかかる可能性があることです。この方法論を適用することのマイナス面が、業界の IT リーダーが、ソフトウェア サイズの測定を自動化するための計算可能なメトリック標準の導入に焦点を当てた IT ソフトウェア品質コンソーシアムを設立する動機となった可能性があります。一方、IFPUG は、その活動のほとんどが FP カウンターの認証に依存しているため、手動アプローチを推進し続けています。

CISQは、サイジングを、コスト見積もり、進捗状況の追跡、またはその他の関連するソフトウェアプロジェクト管理活動をサポートするためにソフトウェアのサイズを見積もることと定義しています。ソフトウェアの機能サイズを測定するための自動機能ポイントと、機能コードと非機能コードの両方のサイズを1つの測定で測定するための自動拡張ポイントの2つの標準が使用されます。^[83]

重大なプログラミングエラーとは、特定のアーキテクチャやコーディングの悪い習慣であり、その結果、即時または長期的にビジネスに最大の混乱をもたらすリスクがある。^[84]

これらは多くの場合、テクノロジーに関連しており、コンテキスト、ビジネス目標、リスクに大きく依存します。命名規則の尊重を考慮する人もいれば、知識移転の基盤を準備している人など、命名規則を絶対的に重要と考える人もいます。

重大なプログラミング エラーは、CISQ 特性ごとに分類することもできます。基本的な例を以下に示します。

• 信頼性
  • 予期しない動作につながるソフトウェア パターン (初期化されていない変数、null ポインタなど)を避けてください。
  • 挿入、更新、削除、テーブルの作成、または選択を行うメソッド、プロシージャ、および関数には、エラー管理を含める必要があります。
  • マルチスレッド関数はスレッドセーフにする必要があります。たとえば、サーブレットやストラットのアクションクラスにはインスタンス/非最終静的フィールドがあってはなりません。
• 効率
  • クライアント要求（受信とデータ）の集中化を確保し、ネットワークトラフィックを削減します。
  • ループ内の大きなテーブルに対してインデックスを使用しないSQLクエリを避ける
• 安全
  • サーブレットクラス内のfinal staticでないフィールドを避ける
  • エラー管理を含まずにデータアクセスを避ける
  • 制御戻りコードを確認し、エラー処理メカニズムを実装する
  • クロスサイトスクリプティングの欠陥やSQLインジェクションの欠陥を回避するために入力検証を確実に行う
• 保守性
  • 理解しやすさを向上させるために、深い継承ツリーとネストは避けるべきである。
  • 変更の伝播を避けるために、モジュールは疎結合（ファンアウト、仲介）にする必要があります。
  • 均一な命名規則を強制する

SqualeやQuamoco ^[85]などの新しい品質モデルの提案は、品質属性の定義と測定の直接的な統合を推進しています。品質属性を細分化したり、追加のレイヤーを定義したりすることで、複雑で抽象的な品質属性（信頼性や保守性など）がより管理しやすく、測定しやすくなります。これらの品質モデルは産業界で適用されてきましたが、広く採用されていません。

• UI、セキュリティなどのチェックリストを含むAndroid OS 品質ガイドライン 2021 年 7 月
• 情報技術および通信における海事管理者協会 (AMMITEC)。海事ソフトウェア品質ガイドライン。2017 年 9 月
• Capers Jonesと Olivier Bonsignour、「ソフトウェア品質の経済学」、Addison-Wesley Professional、第 1 版、2011 年 12 月 31 日、ISBN  978-0-13-258220-9
• CAT Lab - CNES コード分析ツール ラボ (GitHub 上)
• Girish Suryanarayana「ソフトウェアプロセスと設計品質：綱引き？」^[86]
• Ho-Won Jung、Seung-Gweon Kim、Chang-Sin Chung。ソフトウェア製品の品質測定：ISO/IEC 9126の調査。IEEE Software、21(5):10–13、2004年9月/10月。
• 国際標準化機構。ソフトウェア エンジニアリング - 製品品質 - パート 1: 品質モデル。ISO、ジュネーブ、スイス、2001 年。ISO/IEC 9126-1:2001(E)。
• ソフトウェア製品品質の測定: ISO 25000 シリーズと CMMI (SEI サイト)
• MSQF - 測定に基づくソフトウェア品質フレームワークコーネル大学図書館
• Omar Alshathry、Helge Janicke、「ソフトウェア品質保証の最適化」、compsacw、pp. 87–92、2010 IEEE 第 34 回年次コンピュータ ソフトウェアおよびアプリケーション カンファレンス ワークショップ、2010 年。
• Robert L. Glass.品質の高いソフトウェアの構築. Prentice Hall、アッパーサドルリバー、ニュージャージー州、1992 年。
• Roland Petrasch、「ソフトウェア品質の定義: 実践的アプローチ」、ISSRE、1999 年
• ソフトウェア品質専門家、^[87] アメリカ品質協会（ASQ）
• ソフトウェア品質ジャーナル^[88]シュプリンガーネイチャー
• Spinellis, Diomidis (2006-04-04)。コード品質:オープンソースの視点。アッパーサドルリバー、ニュージャージー州、米国: Addison-Wesley Professional。ISBN 978-0-321-16607-4。
• Stephen H. Kan.ソフトウェア品質エンジニアリングにおけるメトリックとモデル。Addison-Wesley、ボストン、マサチューセッツ州、第 2 版、2002 年。
• Stefan Wagner. ソフトウェア製品の品質管理。Springer、2013 年。

注記

文献

ウィキメディア・コモンズには、ソフトウェア品質に関連するメディアがあります。

• コードが王様になるとき: 自動車ソフトウェアの卓越性をマスターする (McKinsey、2021)
• 組み込みシステム ソフトウェアの品質: 品質がひどい場合が多いのはなぜでしょうか? どうすれば改善できるでしょうか? (Philip Koopman 著)
• CISQ ™によるコード品質標準
• CISQ ブログ: https://blog.it-cisq.org
• ソフトウェア品質保証ガイド (ESA)
• ESA ソフトウェア エンジニアリング標準を小規模ソフトウェア プロジェクトに適用するためのガイド (ESA)
• ESA ソフトウェア製品保証サービスの概要 (NASA/ESA)
• フォルクスワーゲン ソフトウェア開発センター リスボンにおける品質への取り組み
• Google スタイルガイド
• Google における製品品質の確保 (2011)
• NASA ソフトウェア保証
• NIST ソフトウェア品質グループ
• OMG/CISQ 自動機能ポイント (ISO/IEC 19515)
• OMG 自動技術的負債標準
• 自動品質保証（IREBのHarry Sneed による記事）
• 構造化テスト: 循環的複雑度メトリックを使用したテスト方法論 (1996)
• コード分​​析ツールを使用したアプリケーション品質の分析 (Microsoft、ドキュメント、Visual Studio、2016)