ソフトウェア工学の文脈では、ソフトウェア品質は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・エドワーズ・デミングが述べたように、システム全体の文脈を考慮に入れないコード品質の価値は限られています。[要出典]

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

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

モチベーション

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

  • リスク管理：ソフトウェアの障害は、不便以上のものをもたらします。ソフトウェアエラーは人命に関わることもあります（例えば、ソフトウェアバグ一覧を参照）。その原因は、ユーザーインターフェースの設計不良から、直接的なプログラミングエラーまで多岐にわたります（ [19] [20] [21]、例えば、ボーイング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兆8400億ドル
    • IBMの2020年データ漏洩コストレポートでは、データ漏洩の平均的な世界コストは次のように推定されています。[34] [35]
      • 386万ドル

定義

ISO

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

ASQ

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

NIST

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

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

PMI

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

その他の一般および歴史的

歴史上初めて品質の定義が示されたのは、20世紀初頭のシューハートによるものである。「品質には二つの共通の側面がある。一つは、人間の存在とは無関係な客観的現実として、物の品質を考察することである。もう一つは、客観的現実の結果として、我々が何を考え、感じ、知覚するかということである。言い換えれば、品質には主観的な側面がある。」[45]

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

  • 超越論的視点は、質の形而上学的側面を扱います。この観点から見ると、質とは「私たちが理想として目指すものでありながら、決して完全に実現できないもの」です。[48]定義することは困難ですが、かつて連邦判事が猥褻さについて述べた「見ればわかる」という言葉に似ています。[49]
  • ユーザー視点は、製品が特定の使用状況に適しているかどうかに関心を寄せます。超越論的視点が空想的であるのに対し、ユーザー視点はより具体的であり、ユーザーのニーズを満たす製品特性に根ざしています。[48]
  • 製造業の観点からは、品質は要求事項への適合性として捉えられます。品質のこの側面は、ISO 9001などの規格で強調されており、ISO/IEC 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 シリーズ標準で採用されているアプローチです。これらの属性は、アプリケーション ソース コードの静的解析の解析結果から測定できます。信頼性やパフォーマンス効率などのアプリケーションの動的な特性でさえ、その原因はアプリケーションの静的構造にあります。

構造的品質分析と測定は、ソースコード、アーキテクチャ、ソフトウェアフレームワーク、データベーススキーマを、システムの概念的および論理的アーキテクチャを定義する原則と標準に照らし合わせて分析することで行われます。これは、開発ツールによって一般的に実行される、基本的なローカルなコンポーネントレベルのコード分析とは異なります。これらの分析は主に実装上の考慮事項に重点を置き、デバッグやテスト作業において非常に重要です。

信頼性

信頼性の低さの根本的な原因は、優れたアーキテクチャとコーディングプラクティスへの非準拠の組み合わせにあります。この非準拠は、アプリケーションの静的な品質属性を測定することで検出できます。アプリケーションの信頼性の根底にある静的属性を評価することで、ビジネスリスクのレベルと、アプリケーションが運用開始時に遭遇する可能性のある障害や欠陥の発生確率を推定できます。

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

  • アプリケーションアーキテクチャの実践
  • コーディングプラクティス
  • アルゴリズムの複雑さ
  • プログラミング実践の複雑さ
  • オブジェクト指向および構造化プログラミングのベストプラクティスへの準拠（該当する場合）
  • コンポーネントまたはパターンの再利用率
  • ダーティプログラミング
  • エラーと例外の処理（GUI、ロジック、データのすべてのレイヤー）
  • 多層設計コンプライアンス
  • リソース境界管理
  • ソフトウェアは予期しない動作につながるパターンを回避する
  • ソフトウェアはデータの整合性と一貫性を管理します
  • 取引の複雑さのレベル

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

効率

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

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

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

安全

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

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

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

保守性

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

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

  • アプリケーションアーキテクチャの実践
  • ソースコードに埋め込まれたアーキテクチャ、プログラム、およびコードのドキュメント
  • コードの読みやすさ
  • コードの臭い
  • 取引の複雑さのレベル
  • アルゴリズムの複雑さ
  • プログラミング実践の複雑さ
  • オブジェクト指向および構造化プログラミングのベストプラクティスへの準拠（該当する場合）
  • コンポーネントまたはパターンの再利用率
  • 制御されたレベルの動的コーディング
  • カップリング比
  • ダーティプログラミング
  • ドキュメント
  • ハードウェア、OS、ミドルウェア、ソフトウェアコンポーネント、データベースの独立性
  • 多層設計コンプライアンス
  • 携帯性
  • プログラミングプラクティス（コードレベル）
  • 重複するコードと関数の削減
  • ソースコードファイルの整理整頓

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

サイズ

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

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

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

ファンクションポイント分析の開始以来、様々なバリエーションが進化を遂げ、機能サイジング手法のファミリーはCOSMIC、NESMA、ユースケースポイント、FP Lite、アーリーFPとクイックFP、そして最近ではストーリーポイントといったサイジング指標を含むように拡大しました。ファンクションポイントは統計的な正確性において高い実績があり、数多くのアプリケーション開発管理（ADM）やアウトソーシング業務において共通の作業測定単位として使用され、サービス提供とパフォーマンス測定の「通貨」として機能しています。

ファンクションポイント手法の一般的な制約の一つは、手作業によるプロセスであるため、アプリケーション開発やアウトソーシング契約といった大規模なプロジェクトでは労働集約的でコストがかさむ可能性があることです。この手法の適用におけるマイナス面こそが、業界のITリーダーたちがソフトウェア規模の測定を自動化するための計算可能なメトリクス標準の導入に注力するITソフトウェア品質コンソーシアムを設立した動機と言えるでしょう。一方、IFPUGは活動の大部分がファンクションポイント（FP）カウンターの認証に依存しているため、手作業によるアプローチを推奨し続けています。

CISQは、サイジングを、コスト見積り、進捗状況の追跡、その他関連するソフトウェアプロジェクト管理活動を支援するためにソフトウェアのサイズを見積もることと定義しています。2つの基準が用いられています。ソフトウェアの機能的サイズを測定する自動機能ポイントと、機能コードと非機能コードの両方のサイズを1つの基準で測定する自動拡張ポイントです。 [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 上)
  • ギリッシュ・スリヤナラヤナ「ソフトウェアプロセスと設計品質：綱引き？」[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 34th Annual Computer Software and Applications Conference Workshops、2010。
  • ロバート・L・グラス著『高品質なソフトウェアの構築』プレンティス・ホール、アッパーサドルリバー、ニュージャージー州、1992年。
  • Roland Petrasch、「ソフトウェア品質の定義：実践的アプローチ」、ISSRE、1999年
  • ソフトウェア品質専門家、[87] アメリカ品質協会（ASQ）
  • シュプリンガー・ネイチャーのソフトウェア品質ジャーナル[88]
  • スピネリス、ディオミディス（2006年4月4日）『コード品質：オープンソースの視点』アッパーサドルリバー、ニュージャージー州、米国：アディソン・ウェスリー・プロフェッショナル、ISBN 978-0-321-16607-4。
  • Stephen H. Kan.ソフトウェア品質工学におけるメトリクスとモデル. Addison-Wesley, Boston, MA, 第2版, 2002年.
  • ステファン・ワグナー著『ソフトウェア製品の品質管理』Springer、2013年。

参考文献

注記

  1. ^ 「歴史から学ぶ：ソフトウェア要件エンジニアリングの事例 – Requirements Engineering Magazine」。歴史から学ぶ：ソフトウェア要件エンジニアリングの事例 – Requirements Engineering Magazine 。2021年2月25日閲覧。
  2. ^ プレスマン、ロジャー・S. (2005).ソフトウェアエンジニアリング：実践者のアプローチ（第6回インターナショナル版）. マグロウヒル・エデュケーション. p. 388. ISBN 0071267824。
  3. ^ 「自動ソースコード品質測定仕様バージョン1.0について」www.omg.org . 2021年2月25日閲覧。
  4. ^ 「エンドツーエンドテストの実行方法」。smartbear.com 。 2021年2月25日閲覧。
  5. ^ 「CISQ勧告に沿って、回復力があり、安全で、効率的で、変更が容易なITシステムを提供する方法」（PDF）。2013年12月28日時点のオリジナルからアーカイブ（PDF） 。 2013年10月18日閲覧。
  6. ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ. O'Reilly Media. 2020. ISBN 978-1492043454。
  7. ^ 「ISO/IEC 25010:2011」。ISO 。 2021年2月23日閲覧。
  8. ^ Armour, Phillip G. (2012-06-01). 「制御の尺度」 . Communications of the ACM . 55 (6): 26– 28. doi :10.1145/2184319.2184329. ISSN  0001-0782. S2CID  6059054.
  9. ^ Voas, J. (2011年11月). 「ソフトウェアの秘密のソース："-ilities" [ソフトウェアの品質]」. IEEE Software . 21 (6): 14– 15. doi :10.1109/MS.2004.54. ISSN  1937-4194.
  10. ^ 「コード品質標準 | CISQ - 情報およびソフトウェア品質コンソーシアム」www.it-cisq.org . 2021年2月25日閲覧。
  11. ^ 「ソフトウェアサイジング標準 | CISQ - 情報およびソフトウェア品質コンソーシアム」www.it-cisq.org . 2021年2月25日閲覧。
  12. ^ J. Bohnet, J. Döllner Archived 2014-04-27 at the Wayback Machine , "Monitoring Code Quality and Development Activity by Software Maps". Proceedings of the IEEE ACM ICSE Workshop on Managing Technical Debt, pp. 9-16, 2011.
  13. ^ 「IIA - グローバルテクノロジー監査ガイド：IT変更管理：組織の成功に不可欠」na.theiia.org . 2021年2月26日閲覧。
  14. ^ Boursier, Jérôme (2018年1月11日). 「メルトダウンとスペクターの余波：パッチ適用の問題は依然として残る」Malwarebytes Labs . 2021年2月26日閲覧。
  15. ^ 「ソフトウェア更新のベストプラクティス - Configuration Manager」。docs.microsoft.com 。2021年2月26日閲覧。
  16. ^ Wright, Hyrum K. (2009-08-25). 「リリースエンジニアリングのプロセス、モデル、メトリクス」. ESEC/FSE 博士課程シンポジウム議事録. ESEC/FSE 博士課程シンポジウム '09. アムステルダム、オランダ：Association for Computing Machinery. pp.  27– 28. doi :10.1145/1595782.1595793. ISBN 978-1-60558-731-8. S2CID  10483918。
  17. ^ ファン・デル・フック、アンドレ;ホール、リチャード S.ハイムビグナー、デニス。ウルフ、アレクサンダー L. (1997 年 11 月)。 「ソフトウェアリリース管理」。ACM SIGSOFT ソフトウェア エンジニアリング ノート。22 (6): 159–175 .土井: 10.1145/267896.267909。ISSN  0163-5948。
  18. ^ Sutton, Mike; Moore, Tym (2008年7月30日). 「ソフトウェアリリース管理を改善する7つの方法」. CIO . 2021年2月26日閲覧。
  19. ^ Clark, Mitchell (2021年2月24日). 「iRobotは、ルンバの最新ソフトウェアアップデートの混乱を解消できるまで数週間かかると述べている」The Verge . 2021年2月25日閲覧。
  20. ^ 「ソフトウェアエラートップ25」www.sans.org . 2021年2月25日閲覧。
  21. ^ 「『149時間ごとに電源をオフにしてオンにする』は、3億ドルのエアバス機のソフトウェアバグに対する懸念すべき解決策」Gizmodo 2019年7月30日. 2021年2月25日閲覧。
  22. ^ 「MISRA C、トヨタ、そしてタスクXの終焉」 。 2021年2月25日閲覧。
  23. ^ 「トヨタと意図しない加速に関する最新情報 « Barr Code」embeddedgurus.com . 2021年2月25日閲覧。
  24. ^ 医療機器：Therac-25* 2008年2月16日アーカイブ、Wayback Machine、ナンシー・レベソン、ワシントン大学
  25. ^ Embedded Software Archived 2010-07-05 at the Wayback Machine、Edward A. Lee、「Advances in Computers」（Marvin Victor Zelkowitz編）、第56巻、Academic Press、ロンドン、2002年に掲載予定、UCB ERL Memorandum M01/26から改訂、University of California、Berkeley、CA 94720、USA、2001年11月1日
  26. ^ 「航空機認証ソフトウェアおよび航空機搭載用電子ハードウェア」。2014年10月4日時点のオリジナルよりアーカイブ。2014年9月28日閲覧。
  27. ^ 「米国におけるソフトウェア品質の低さがもたらすコスト：2020年報告書 | CISQ - 情報・ソフトウェア品質コンソーシアム」www.it-cisq.org . 2021年2月25日閲覧。
  28. ^ 「What is Waste? | Agile Alliance」. Agile Alliance | 2016年4月20日. 2021年2月25日閲覧。
  29. ^ Matteson, Scott (2018年1月26日). 「報告書：ソフトウェア障害による2017年の財務損失は1兆7000億ドル」. TechRepublic . 2021年2月25日閲覧。
  30. ^ Cohane, Ryan (2017年11月16日). 「ソフトウェアバグの経済的コスト」. Medium . 2021年2月25日閲覧。
  31. ^ Eloff, Jan; Bella, Madeleine Bihina (2018)、「ソフトウェア障害：概要」、ソフトウェア障害調査、Cham: Springer International Publishing、pp.  7– 24、doi :10.1007/978-3-319-61334-5_2、ISBN 978-3-319-61333-8、2021年2月25日取得
  32. ^ 「ソフトウェアの品質低下により、昨年企業は2兆ドルの損失を被り、セキュリティが危険にさらされた」CIO Dive . 2021年2月26日閲覧。
  33. ^ 「シノプシスがスポンサーとなったCISQの調査で、2020年のソフトウェア品質の低さによるコストは2.08兆ドルと推定」。finance.yahoo.com 。2021年2月26日閲覧。
  34. ^ 「2020年のデータ侵害のコストはいくらか？」Digital Guardian、2020年8月6日。 2021年3月8日閲覧。
  35. ^ 「データ漏洩のコストに関するレポート2020 | IBM」www.ibm.com . 2020年. 2021年3月8日閲覧。
  36. ^ 「ISO - ISO 9000ファミリー - 品質マネジメント」ISO . 2021年2月24日閲覧。
  37. ^ “ISO/IEC/IEEE 24765:2017”. ISO . 2021年2月24日閲覧。
  38. ^ ab 「自動車ソフトウェアの習得」www.mckinsey.com . 2021年2月25日閲覧。
  39. ^ 「ISO/IEC 25010:2011」。ISO 。 2021年2月24日閲覧。
  40. ^ Wallace, DR (2002). 「実践的なソフトウェア信頼性モデリング」.第26回NASAゴダードソフトウェアエンジニアリングワークショップ議事録. 米国メリーランド州グリーンベルト: IEEE Comput. Soc. pp.  147– 155. doi :10.1109/SEW.2001.992668. ISBN 978-0-7695-1456-7. S2CID  57382117。
  41. ^ 「ISO/IEC 25023:2016」。ISO 。 2023年11月6日閲覧。
  42. ^ 「ソフトウェア品質とは？ | ASQ」。asq.org . 2021年2月24日閲覧。
  43. ^ 「SAMATE - ソフトウェア保証メトリクスおよびツール評価プロジェクトのメインページ」NIST 2021年2月3日. 2021年2月26日閲覧。
  44. ^ PMBOKガイドのソフトウェア拡張。プロジェクトマネジメント協会（第5版）。ペンシルベニア州ニュータウンスクエア。2013年。ISBN 978-1-62825-041-1. OCLC  959513383.{{cite book}}: CS1 maint: location missing publisher (link) CS1 maint: others (link)
  45. ^ Shewart, Walter A. (2015).製造製品の品質の経済的管理. [出版地不明]: Martino Fine Books. ISBN 978-1-61427-811-5. OCLC  1108913766.
  46. ^ Kitchenham, B. ; Pfleeger, SL (1996年1月). 「ソフトウェア品質：捉えどころのない目標 [特集号]」. IEEE Software . 13 (1): 12– 21. doi :10.1109/52.476281. ISSN  1937-4194.
  47. ^ ガービン、デイビッド・A.（1988年）『品質管理：戦略的競争力』ニューヨーク：フリープレス、ISBN 0-02-911380-6. OCLC  16005388。
  48. ^ ab B. Kitchenhamと S. Pfleeger、「ソフトウェア品質：つかみどころのない目標」、IEEE Software、vol. 13、no. 1、pp. 12–21、1996 年。
  49. ^ Kan, Stephen H. (2003).ソフトウェア品質工学におけるメトリクスとモデル（第2版）. ボストン: Addison-Wesley. ISBN 0-201-72915-6. OCLC  50149641。
  50. ^ 国際標準化機構、「ISO/IEC 9001: 品質マネジメントシステム - 要求事項」、1999 年。
  51. ^ WEデミング、「危機からの脱却：品質、生産性、競争力」ケンブリッジ大学出版局、1988年。
  52. ^ AVファイゲンバウム、「Total Quality Control」、McGraw-Hill、1983年。
  53. ^ JM Juran、「Juran の品質管理ハンドブック」、McGraw-Hill、1988 年。
  54. ^ Weinberg, Gerald M. (1991).品質ソフトウェア管理：第1巻、システム思考. ニューヨーク、NY: Dorset House. ISBN 0-932633-22-6. OCLC  23870230。
  55. ^ Weinberg, Gerald M. (1993).品質ソフトウェア管理：第2巻、第一段階の測定. ニューヨーク、NY: Dorset House. ISBN 0-932633-22-6. OCLC  23870230。
  56. ^ クロスビー、P.、「クオリティ・イズ・フリー」、マグロウヒル、1979年
  57. ^ 「SUP.9 – 問題解決管理 - Kugler Maag Cie」. www.kuglermaag.com . 2021年2月25日閲覧。
  58. ^ ab Hoipt (2019年11月29日). 「組織はしばしば『品質保証』（QA）と『品質管理』（QC）という用語を使用します…」Medium . 2021年2月25日閲覧。
  59. ^ Wallace, D.; Watson, AH; Mccabe, TJ (1996-08-01). 「構造化テスト：循環的複雑度メトリックを用いたテスト手法」NIST .
  60. ^ Bellairs, Richard. 「コード品質とは何か？そしてコード品質を向上させる方法」Perforceソフトウェア. 2021年2月28日閲覧。
  61. ^ 「OMGホワイトペーパー | CISQ - 情報およびソフトウェア品質コンソーシアム」www.it-cisq.org . 2021年2月26日閲覧。
  62. ^ 「CISQ勧告に沿った、回復力、安全性、効率性、俊敏性を備えたITシステムを提供する方法 - ホワイトペーパー | Object Management Group」(PDF) 。 2013年12月28日時点のオリジナルよりアーカイブ(PDF) 。 2013年10月18日閲覧。
  63. ^ 「ソフトウェアサイズ測定：ソースステートメントをカウントするためのフレームワーク」. resources.sei.cmu.edu . 1992年8月31日. 2021年2月24日閲覧。
  64. ^ ハルステッド、モーリス・H. (1977). 『ソフトウェア科学の要素（オペレーティングシステムとプログラミングシステムシリーズ）』米国：エルゼビア・サイエンス社ISBN 978-0-444-00205-1。
  65. ^ Chidamber, SR; Kemerer, CF (1994年6月). 「オブジェクト指向設計のためのメトリクススイート」. IEEE Transactions on Software Engineering . 20 (6): 476– 493. doi :10.1109/32.295895. hdl : 1721.1/48424 . ISSN  1939-3520. S2CID  9493847.
  66. ^ ナイガード、マイケル (2007). Release It! . オライリー・メディア・カンパニー Safari (第1版). Pragmatic Bookshelf. ISBN 978-0978739218. OCLC  1102387436。
  67. ^ 「CWE - Common Weakness Enumeration」cwe.mitre.org . 2016年5月10日時点のオリジナルよりアーカイブ。2016年5月20日閲覧。
  68. ^ Boehm, B., Brown, JR, Kaspar, H., Lipow, M., MacLeod, GJ, & Merritt, MJ (1978). ソフトウェア品質の特性. North-Holland.
  69. ^ abc 「SEI CERTコーディング標準 - CERTセキュアコーディング - Confluence」. wiki.sei.cmu.edu . 2021年2月24日閲覧。
  70. ^ 「コード品質とコードセキュリティ：どのような関連性があるか？ | Synopsys」。ソフトウェアインテグリティブログ。2019年5月24日。 2021年3月9日閲覧。
  71. ^ 「データ漏洩のコストに関するレポート2020 | IBM」www.ibm.com . 2020年. 2021年3月9日閲覧。
  72. ^ 「2020年データ漏洩コストレポートの重要なポイント」Bluefin 2020年8月27日2021年3月9日閲覧。
  73. ^ 「CWE - Common Weakness Enumeration」. Cwe.mitre.org. 2013年10月14日時点のオリジナルよりアーカイブ。 2013年10月18日閲覧。
  74. ^ 開発におけるセキュリティ: IBM セキュア エンジニアリング フレームワーク | IBM Redbooks。2016 年 9 月 30 日。
  75. ^ IBM Tivoli セキュリティ ソリューションを使用したエンタープライズ セキュリティ アーキテクチャー | IBM Redbooks。2016 年 9 月 30 日。
  76. ^ 「セキュアアーキテクチャ設計定義 | CISA」us-cert.cisa.gov . 2021年3月9日閲覧。
  77. ^ 「OWASP Foundation | Open Source Foundation for Application Security」. owasp.org . 2021年2月24日閲覧。
  78. ^ 「CWEのトップ25」Sans.org . 2013年10月18日閲覧。
  79. ^ IfSQ レベル 2 コンピュータ プログラム ソース コードの基礎レベル標準、Wayback Machineに 2011 年 10 月 27 日にアーカイブ、第 2 版 2008 年 8 月、Graham Bolton、Stuart Johnston、IfSQ、Institute for Software Quality。
  80. ^ Fowler, Martin (2009年10月14日). 「TechnicalDebtQuadrant」. 2013年2月2日時点のオリジナルよりアーカイブ。2013年2月4日閲覧。
  81. ^ 「コード品質：企業、収益、そして共感的なプログラマーにとっての懸念事項」Stack Overflow . 2021年10月18日. 2023年12月5日閲覧。
  82. ^ Prause, Christian; Durdik, Zoya (2012年6月3日). 「アーキテクチャ設計とドキュメンテーション：アジャイル開発における無駄？」. 2012 International Conference on Software and System Process (ICSSP). IEEE Computer Society. pp.  130– 134. doi :10.1109/ICSSP.2012.6225956. ISBN 978-1-4673-2352-9. S2CID  15216552。
  83. ^ 「ソフトウェアサイジング標準 | CISQ - 情報およびソフトウェア品質コンソーシアム」www.it-cisq.org . 2021年1月28日閲覧。
  84. ^ 「ソフトウェアが失敗する理由」IEEE Spectrum: テクノロジー、エンジニアリング、科学ニュース. 2005年9月2日. 2021年3月20日閲覧。
  85. ^ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas (2015). 「運用化された製品品質モデルと評価：Quamocoアプローチ」（PDF） . Information and Software Technology . 62 : 101– 123. arXiv : 1611.09230 . doi :10.1016/j.infsof.2015.02.009. S2CID  10992384.
  86. ^ Suryanarayana, Girish (2015). 「ソフトウェアプロセスと設計品質：綱引き？」IEEEソフトウェア. 32 (4): 7– 11. doi : 10.1109/MS.2015.87 . S2CID  9226051.
  87. ^ 「ソフトウェア品質プロフェッショナル | ASQ」. asq.org . 2021年1月28日閲覧。
  88. ^ 「Software Quality Journal」. Springer . 2021年1月28日閲覧。

参考文献

  • Albrecht, AJ (1979)、「アプリケーション開発の生産性の測定」。Share/Guide IBMアプリケーション開発シンポジウムの議事録。IBM
  • Ben-Menachem, M.; Marliss, GS (1997)、『ソフトウェア品質、実用的かつ一貫性のあるソフトウェアの制作』、Thomson Computer Press
  • Boehm, B.; Brown, JR; Kaspar, H.; Lipow, M.; MacLeod, GJ; Merritt, MJ (1978)、「ソフトウェア品質の特性」、North-Holland。
  • Chidamber, S.; Kemerer, C. (1994),オブジェクト指向設計のためのメトリクススイート. IEEE Transactions on Software Engineering, 20 (6) , pp.  476– 493
  • エバート、クリストフ、ドゥムケ、ライナー、『ソフトウェア測定：確立 - 抽出 - 評価 - 実行』、Kindle版、p. 91
  • ガーマス、D.; ヘロン、D. (2001)、『ファンクションポイント分析』、アディソン・ウェスリー
  • Halstead, ME (1977)、「Elements of Software Science」、Elsevier North-Holland
  • Hamill, M.; Goseva-Popstojanova, K. (2009),ソフトウェアの障害および故障データにおける一般的な障害. IEEE Transactions of Software Engineering, 35 (4) , pp.  484– 496
  • Jackson, DJ (2009), 「信頼できるソフトウェアへの直接的な道」Communications of the ACM, 52 (4).
  • Martin, R. (2001)、「ネットワーク システムの脆弱性の管理」、IEEE Computer。
  • McCabe, T. (1976年12月) 「複雑性の尺度」IEEE Transactions on Software Engineering
  • マコーネル、スティーブ（1993年）、コードコンプリート（初版）、マイクロソフトプレス
  • Nygard, MT (2007)、「リリース! 本番環境対応ソフトウェアの設計と導入」、The Pragmatic Programmers。
  • Park, RE (1992),ソフトウェアサイズ測定：ソースステートメントのカウントのためのフレームワーク。(CMU/SEI-92-TR-020).カーネギーメロン大学ソフトウェア工学研究所
  • プレスマン、ロジャー・S. (2005). 『ソフトウェアエンジニアリング：実践者のアプローチ』（第六インターナショナル版）. マグロウヒル・エデュケーション. ISBN 0071267824。
  • Spinellis, D. (2006)、コード品質、Addison Wesley
ウィキメディア コモンズには、ソフトウェア品質に関連するメディアがあります。
  • コードが王様になるとき: 自動車ソフトウェアの卓越性をマスターする (マッキンゼー、2021 年)
  • 組み込みシステムソフトウェアの品質：なぜこれほどまでにひどい結果になるのか？どうすれば改善できるのか？（フィリップ・クープマン著）
  • 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誌ハリー・スニードの記事）
  • 構造化テスト：循環的複雑度メトリックを用いたテスト方法論（1996）
  • コード分​​析ツールを使用したアプリケーション品質の分析 (Microsoft、ドキュメント、Visual Studio、2016)