ソフトウェアの品質 – 日本語百科事典辞書

Software_quality
ソフトウェアエンジニアリングの文脈では、ソフトウェア品質とは、関連しているが異なる2つの概念を指します。
ソフトウェアの機能品質は、機能要件または仕様に基づいて、特定の設計にどの程度準拠しているか、または準拠しているかを反映します。その属性は、ソフトウェアの目的への適合性、または価値のある製品としての市場の競合他社との比較としても説明できます。それは正しいソフトウェアが作成された程度です。
ソフトウェアの構造品質とは、堅牢性や保守性などの機能要件の提供をサポートする非機能要件をどのように満たすかを指します。それは、ソフトウェアが必要に応じて機能する程度と関係が
構造品質の多くの側面は、ソフトウェアの内部構造、そのソースコード（ソフトウェアメトリクスを参照）、ユニットレベル、システムレベル（エンドツーエンドテストと呼ばれることもあります）の分析を通じてのみ静的に評価できます。 4]）、これは事実上、そのアーキテクチャが、Object Management Group（OMG）によるトピックに関する論文で概説されているソフトウェアアーキテクチャの健全な原則にどのように準拠しているかを示しています。
ただし、ユーザビリティなどの一部の構造的品質は動的にしか評価できません（ユーザーまたはユーザーに代わって行動する他のユーザーがソフトウェアと対話するか、少なくとも一部のプロトタイプまたは部分的な実装です。段ボールで作成されたモックバージョンとの対話でさえ動的に表現されますそのようなバージョンはプロトタイプと見なすことができるため、テストしてください）。信頼性などの他の側面には、ソフトウェアだけでなく基盤となるハードウェアも含まれる可能性があるため、静的および動的の両方で評価できます（ストレステスト）。
機能品質は通常動的に評価されますが、静的テスト（ソフトウェアレビューなど）を使用することもできます。
歴史的に、ソフトウェア品質管理に適用可能な属性とメトリックの構造、分類、および用語は、ISO9126およびその後のISO / IEC25000標準から派生または抽出されてきました。これらのモデル（モデルを参照）に基づいて、ITソフトウェア品質コンソーシアム（CISQ）は、ソフトウェアがビジネス価値を提供するために必要な5つの主要な望ましい構造特性を定義しました。信頼性、効率、セキュリティ、保守性、および（適切な）サイズ。
ソフトウェア品質測定は、ソフトウェアプログラムまたはシステムがこれらの5つの次元のそれぞれに沿ってどの程度評価するかを定量化します。ソフトウェア品質の集計された測定値は、定性的または定量的なスコアリングスキーム、あるいは両方の組み合わせ、そして優先順位を反映した重み付けシステムによって計算できます。線形連続体に配置されているソフトウェア品質のこの見方は、特定の状況下で、集約された測定に基づく評価に関係なく、特定のシステムを使用に適さない壊滅的な停止またはパフォーマンスの低下につながる可能性がある「重大なプログラミングエラー」の分析によって補足されます。システムレベルで見られるこのようなプログラミングエラーは、本番環境の問題の最大90％を表しますが、ユニットレベルでは、はるかに多くても、プログラミングエラーは本番環境の問題の10％未満を占めます（90対90の法則も参照）。結果として、W。エドワーズデミングが説明したように、システム全体のコンテキストがないコード品質の価値は限られています。
ソフトウェア品質測定値を表示、調査、分析、および伝達するために、情報視覚化の概念と手法は、特に複数のソフトウェア品質測定値を相互に、またはソフトウェアやシステムのコンポーネントに関連付ける必要がある場合に役立つ、視覚的でインタラクティブな手段を提供します。たとえば、ソフトウェアマップは、「ソフトウェア開発、ソフトウェア品質、およびシステムダイナミクスに関する情報を表現および組み合わせることができる」特殊なアプローチを表しています。
ソフトウェアの品質は、ソフトウェアプロジェクトのリリースフェーズでも役割を果たします。具体的には、リリースプロセス（パッチプロセスも）、構成管理の品質と確立は、ソフトウェアエンジニアリングプロセス全体の重要な部分です。

コンテンツ
1 動機
2 定義
2.1 ISO 2.2 ASQ 2.3 NIST 2.4 PMI 2.5 その他の一般的および歴史的 2.62.6 他の意味と論争
3 計測
3.1 序章 3.2 コードベースの分析 3.3 信頼性 3.43.4 効率 3.5 安全 3.6 保守性 3.7 サイズ 3.8 重要なプログラミングエラーの特定 3.9 運用可能な品質モデル
4 トリビア
5 も参照してください
6 参考文献
7 参考文献
8 外部リンク

動機
ソフトウェアの品質は、少なくとも2つの主要な観点から動機付けられています。
リスク管理：ソフトウェアの障害は、不便以上のものを引き起こしました。ソフトウェアエラーは人命にかかわる可能性があります（例：ソフトウェアバグのリストを参照）。原因は、設計が不十分なユーザインターフェースから直接の範囲であったプログラミングエラー、例えば、参照ボーイング737ケースまたは意図しない加速ケース又はセラック25ケース。これにより、一部のタイプのソフトウェア、特に重要なインフラストラクチャを規制する医療およびその他のデバイスに組み込まれたソフトウェアの開発が必要になりました。「[組み込みソフトウェアを作成するエンジニア]は、Javaプログラムが3分の1秒停止するのを見るガベージコレクションを実行し、ユーザーインターフェイスを更新するために、彼らは飛行機が空から落ちることを想定しています。」米国では、連邦航空局（FAA）内で、FAA航空機認証サービスがソフトウェアプログラム、ポリシー、ガイダンス、トレーニングを提供し、航空機搭載製品に影響を与えるソフトウェアと複雑な電子ハードウェアに焦点を当てています（a “製品」は、航空機、エンジン、またはプロペラです）。 DO-178C、ISO 26262、IEC62304などの認証規格がガイダンスを提供します。
コスト管理：他のエンジニアリング分野と同様に、優れたソフトウェア品質によって管理されるソフトウェア製品またはサービスは、維持費が少なく、理解しやすく、差し迫ったビジネスニーズに応じて費用対効果の高い方法で変更できます。業界データは、コアビジネスアプリケーション（エンタープライズリソースプランニング（ERP）、顧客関係管理（CRM）、金融サービスの大規模なトランザクション処理システムなど）のアプリケーション構造の品質が低いと、コストが発生し、スケジュールが超過し、リワークの形式（Muda（日本語）を参照）。さらに、構造品質の低さは、データの破損、アプリケーションの停止、セキュリティ違反、パフォーマンスの問題による影響の大きいビジネスの混乱と強く相関しています。
CISQは、低品質のコストについて次のような影響を見積もっています。
2020年には2.08兆ドル
2018年には2.84兆ドル
IBMのデータ漏えいレポート2020のコストは、データ漏えいの世界平均コストを次のように見積もっています。
386万ドル

定義

ISO
ソフトウェアの品質とは、「ソフトウェア製品が要件に準拠する能力」です。一方で、他の人にとっては、顧客または価値の創造、あるいは欠陥レベルと同義である可能性が

ASQ
ASQは、次の定義を使用します。ソフトウェア品質は、ソフトウェア製品の望ましい属性を表します。主なアプローチは2つ欠陥管理と品質属性です。

NIST
ソフトウェアアシュアランス（SA）は、プロパティとそれを実現するためのプロセスの両方をカバーします。
ソフトウェアに脆弱性がなく、ソフトウェアに意図的に設計されているか、ライフサイクル中の任意の時点で誤って挿入されていること、およびソフトウェアが意図した方法で機能していることの信頼
ソフトウェアライフサイクルプロセスと製品が要件、標準、および手順に準拠していることを保証する、計画的で体系的な一連のアクティビティ

PMI
プロジェクトマネジメント協会のPMBOKガイド『ソフトウェアの拡張』を定義していない『ソフトウェアの品質』そのものではなく、ソフトウェア品質保証（SQA）として監査他のソフトウェアプロセスは、それらのプロセスに従っていることを確実にすることを連続プロセスは、（例えば、A用含み」ソフトウェア品質管理計画）。」一方、ソフトウェア品質管理（SCQ）とは、「開発中または変更中のソフトウェアの品質要件に向けて、作業成果物の満足度を確保するための方法、ツール、技術の適用に注意を払うこと」を意味します。

その他の一般的および歴史的
品質の歴史の最初の定義は、20世紀初頭のシューハートによるものです。「品質には2つの共通の側面がそのうちの1つは、物の品質を、もう1つは、客観的な現実の結果として私たちが考え、感じ、感じることと関係が言い換えれば、品質には主観的な側面が」
キッチナムとプフリーガーは、デビッドガービンの教えをさらに報告し、品質に関する5つの異なる視点を特定しています。
超越的な視点は、品質の形而上学的側面を扱います。この品質観では、「私たちが理想として目指しているものですが、完全に実現することはできない」とのことです。それはほとんど定義できないが、連邦判事がかつて猥褻についてコメントしたものに似ている：「私はそれを見るときそれを知っている」。
ユーザーの視点は、特定の使用状況に対する製品の適切性に関係しています。超越的な見方は空気のようなものですが、ユーザーの見方はより具体的であり、ユーザーのニーズを満たす製品の特性に基づいています。
製造の観点は、品質を要件への適合として表します。品質のこの側面は、品質を「一連の固有の特性が要件を満たす程度」（ISO / IEC 9001 ）として定義するISO9001などの規格によって強調されています。
製品の視点は、製品の固有の特性を測定することによって品質を評価できることを意味します。
品質の最終的な視点は価値に基づいています。この視点は、品質のさまざまな視点がさまざまな利害関係者にとってさまざまな重要性または価値を持っている可能性があることを認識しています。
製品、ほとんどすべての製品の品質を定義する試みに固有の問題は、マスターのウォルターA.シューハートによって述べられました。品質を定義することの難しさは、ユーザーの将来のニーズを測定可能な特性に変換することです。これにより、ユーザーが支払う価格で満足できる製品を設計および作成できます。これは簡単なことではなく、努力がかなり成功したと感じるとすぐに、消費者のニーズが変化したり、競合他社が入居したりすることに気づきます。-
W.エドワーズデミング
品質は顧客の決定であり、エンジニアの決定でも、マーケティングの決定でも、一般的な管理の決定でもありません。これは、製品またはサービスに関する顧客の実際の経験に基づいており、顧客の要件（表明または非表明、意識的または単に感知済み、技術的運用または完全に主観的）に対して測定され、常に競争の激しい市場で動く目標を表しています。
品質という言葉には複数の意味がこれらの意味のうちの2つは、この単語の使用を支配します。1。品質は、顧客のニーズを満たし、それによって製品の満足度を提供する製品機能で構成されます。2.品質は、欠陥からの解放で構成されます。それにもかかわらず、このようなハンドブックでは、品質という言葉の短い定義を「使用の適性」として標準化すると便利です。
Tom DeMarcoは、「製品の品質は、世界をより良く変える程度の関数である」と提案しています。これは、ソフトウェアの品質を決定する上で、構造的な品質よりも機能的な品質とユーザーの満足度が重要であることを意味すると解釈できます。
ジェラルド・ワインバーグが品質ソフトウェア管理：システム思考で作り出した別の定義は、「品質はある人にとって価値がある」というものです。この定義は、品質は本質的に主観的なものであることを強調しています。つまり、同じソフトウェアの品質は人によって異なります。この定義の強みの1つは、「ソフトウェアを評価したい人は誰ですか」など、ソフトウェアチームに検討を促す質問です。と「彼らにとって何が価値があるのだろうか？」

他の意味と論争
品質を定義する際の課題の1つは、「誰もがそれを理解していると感じる」ことであり、ソフトウェア品質の他の定義は、ビジネスで使用される品質の概念のさまざまな説明を拡張することに基づくことができます。
また、ソフトウェアの品質は、品質保証または問題解決管理または品質管理またはDevOpsと混同されることがよく前述の領域（PMIの定義も参照）と重複しますが、テストだけでなく、プロセス、管理、改善、評価などにも焦点を当てているため、特徴的です。

計測
このセクションで紹介する概念は、構造的および機能的なソフトウェア品質の両方に適用できますが、後者の測定は、基本的にテストを通じて実行されます[主要な記事：ソフトウェアテストを参照]。しかし、テストだけでは不十分です。ある調査によると、個々のプログラマーは、自分のソフトウェアのバグを見つけるのに50％未満の効率しかありません。そして、ほとんどの形式のテストは35％しか効率的ではありません。これにより、の品質を判断することが困難になります。

序章

ソフトウェアの望ましい特性（右）と測定可能な属性（左）の関係。
ソフトウェア品質の測定とは、システムまたはソフトウェアが望ましい特性をどの程度備えているかを定量化することです。これは、定性的または定量的手段、あるいは両方の組み合わせによって実行できます。どちらの場合も、望ましい特性ごとに、ソフトウェアまたはシステムの一部に存在する測定可能な属性のセットが相関し、この特性に関連付けられる傾向がたとえば、移植性に関連する属性は、プログラム内のターゲットに依存するステートメントの数です。より正確には、品質機能展開アプローチを使用すると、これらの測定可能な属性は、上記のソフトウェア品質定義の「whats」を有効にするために適用する必要のある「hows」です。
ソフトウェア品質管理に適用可能な属性とメトリックの構造、分類、および用語は、ISO9126-3およびその後のISO / IEC 25000：2005品質モデルから導出または抽出されています。主な焦点は、内部構造の品質です。サブカテゴリは、ビジネスアプリケーションアーキテクチャや、データアクセスや操作、トランザクションの概念などの技術的特性などの特定の領域を処理するために作成されています。
ソフトウェア品質特性とそれらの測定可能な属性の間の依存関係ツリーは、右の図に示されています。ここで、ビジネスシステムのユーザー（右）または所有者にとって重要な5つの特性のそれぞれは、測定可能な属性（左）に依存します。
アプリケーションアーキテクチャの実践
コーディング慣行
アプリケーションの複雑さ
ドキュメンテーション
移植性
技術的および機能的ボリューム
プログラミングエラーと本番環境の欠陥との相関関係から、基本的なコードエラーがソースコードのエラー全体の92％を占めていることがわかります。これらの多数のコードレベルの問題は、最終的には本番環境の欠陥の10％にすぎません。アーキテクチャレベルでの不適切なソフトウェアエンジニアリングプラクティスは、欠陥全体の8％しか占めていませんが、問題の修正に費やされた労力の半分以上を消費し、本番環境における深刻な信頼性、セキュリティ、および効率の問題の90％につながります。

コードベースの分析
既存のソフトウェアメジャーの多くは、そのような個々の命令トークン制御構造（複雑さ）およびオブジェクトのソースコードを解析した結果として生じるアプリケーションの構造要素をカウントします。
ソフトウェア品質の測定とは、システムまたはソフトウェアがこれらの側面に沿ってどの程度評価するかを定量化することです。分析は、定性的または定量的アプローチ、あるいは両方の組み合わせを使用して実行し、[たとえば、測定される要因間の相対的な重要性を反映する加重平均を使用して]集計ビューを提供できます。
線形連続体でのソフトウェア品質のこの見方は、離散的なクリティカルプログラミングエラーの識別によって補足する必要がこれらの脆弱性はテストケースに失敗しない可能性がありますが、特定の状況下で壊滅的な停止、パフォーマンスの低下、セキュリティ違反、データの破損、および特定のシステムを事実上作成するその他の無数の問題につながる可能性がある悪い慣行の結果です。集計された測定値に基づく評価に関係なく、使用には適し脆弱性のよく知られた例は、共通脆弱列挙、メイクアプリケーションがセキュリティ侵害にさらされることは、ソースコードの脆弱性のリポジトリ。
重要なアプリケーション特性の測定には、上の図に示すように、アプリケーションのアーキテクチャ、コーディング、およびインラインドキュメントの構造属性の測定が含まれます。したがって、各特性は、アプリケーションのさまざまな抽象化レベルの属性の影響を受けます。ビジネスに影響を与える品質結果の貴重な予測子となるには、特性の測定値の計算にすべてを含める必要が上の図に表示されている特性測定値を計算するための階層型アプローチは、TRWのBoehmと彼の同僚によって最初に提案され（Boehm、1978）、ISO9126および25000シリーズ規格で採用されたアプローチです。これらの属性は、アプリケーションのソースコードの静的分析の解析結果から測定できます。信頼性やパフォーマンス効率などのアプリケーションの動的特性でさえ、アプリケーションの静的構造に因果関係が
構造品質の分析と測定は、システムの概念的および論理的アーキテクチャを一緒に定義する原則と標準に関連して、ソースコード、アーキテクチャ、ソフトウェアフレームワーク、データベーススキーマの分析を通じて実行されます。これは、開発ツールによって通常実行される基本的なローカルのコンポーネントレベルのコード分析とは異なります。これらのツールは、主に実装の考慮事項に関係し、デバッグおよびテストアクティビティ中に重要です。

信頼性
信頼性の低下の根本的な原因は、コンプライアンス違反と優れたアーキテクチャおよびコーディング手法の組み合わせにこの不適合は、アプリケーションの静的品質属性を測定することで検出できます。アプリケーションの信頼性の根底にある静的属性を評価することで、ビジネスリスクのレベルと、アプリケーションを運用したときに発生する可能性のあるアプリケーションの障害や欠陥の可能性を見積もることができます。
信頼性を評価するには、少なくとも次のソフトウェアエンジニアリングのベストプラクティスと技術属性をチェックする必要が
アプリケーションアーキテクチャの実践
コーディング慣行
アルゴリズムの複雑さ
プログラミング手法の複雑さ
オブジェクト指向および構造化プログラミングのベストプラクティスへの準拠（該当する場合）
コンポーネントまたはパターンの再利用率
汚いプログラミング
エラーと例外の処理（すべてのレイヤー-GUI、ロジック、データ）
多層設計コンプライアンス
リソース境界管理
ソフトウェアは、予期しない動作につながるパターンを回避します
ソフトウェアはデータの整合性と一貫性を管理します
トランザクションの複雑さのレベル
アプリケーションアーキテクチャと使用するサードパーティコンポーネント（外部ライブラリやフレームワークなど）に応じて、提供されたソフトウェアの信頼性をより適切に評価するために、上記のベストプラクティスのリストに沿ってカスタムチェックを定義する必要が

効率
信頼性と同様に、パフォーマンスの非効率性の原因は、アプリケーションの静的品質属性を測定することで検出できる、優れたアーキテクチャおよびコーディングの慣行に違反している場合によく見られます。これらの静的属性は、特に複雑なアルゴリズムや大量のデータを処理するために高い実行速度を必要とするアプリケーションの場合、潜在的な運用パフォーマンスのボトルネックと将来のスケーラビリティの問題を予測します。
パフォーマンス効率を評価するには、少なくとも次のソフトウェアエンジニアリングのベストプラクティスと技術属性を確認する必要が
アプリケーションアーキテクチャの実践
高価なリソースやリモートリソースとの適切なやり取り
データアクセスのパフォーマンスとデータ管理
メモリ、ネットワーク、およびディスクスペースの管理
コーディング慣行の遵守（ベストコーディング慣行）

安全
ソフトウェアの品質には、ソフトウェアのセキュリティが含まれます。多くのセキュリティの脆弱性は、SQLインジェクションやクロスサイトスクリプティングなどの不十分なコーディングとアーキテクチャの慣行に起因します。これらは、CWE およびカーネギーメロン大学のSEI /コンピューター緊急センター（CERT）によって維持されているリストに十分に文書化されています。
セキュリティを評価するには、少なくとも次のソフトウェアエンジニアリングのベストプラクティスと技術属性を確認する必要が
セキュリティを意識した強化された開発プロセスの実装、管理。たとえば、セキュリティ開発ライフサイクル（Microsoft）やIBMのセキュアエンジニアリングフレームワーク。
安全なアプリケーションアーキテクチャの実践
多層設計コンプライアンス
セキュリティのベストプラクティス（入力検証、SQLインジェクション、クロスサイトスクリプティング、アクセス制御など）
安全で優れたプログラミング手法
エラーと例外の処理

保守性
保守性には、モジュール性、理解可能性、変更可能性、テスト可能性、再利用性、およびある開発チームから別の開発チームへの転送可能性の概念が含まれます。これらは、コードレベルでの重大な問題の形をとることはありません。むしろ、保守性の低さは、通常、ドキュメントのベストプラクティス、複雑さの回避戦略、およびクリーンで読みやすいコードと整理されていない読みにくいコードを区別する基本的なプログラミングプラクティスに関する数千の軽微な違反の結果です。。
保守性を評価するには、次のソフトウェアエンジニアリングのベストプラクティスと技術属性を確認する必要が
アプリケーションアーキテクチャの実践
ソースコードに埋め込まれたアーキテクチャ、プログラム、およびコードのドキュメント
コードの読みやすさ
コードの臭い
トランザクションの複雑さのレベル
アルゴリズムの複雑さ
プログラミング手法の複雑さ
オブジェクト指向および構造化プログラミングのベストプラクティスへの準拠（該当する場合）
コンポーネントまたはパターンの再利用率
動的コーディングの制御されたレベル
カップリング比
汚いプログラミング
ドキュメンテーション
ハードウェア、OS、ミドルウェア、ソフトウェアコンポーネント、およびデータベースの独立性
多層設計コンプライアンス
移植性
プログラミングの実践（コードレベル）
重複するコードと関数の削減
ソースコードファイルの整理の清潔さ
保守性は、ウォード・カニンガムの技術的負債の概念と密接に関連しています。これは、保守性の欠如から生じるコストの表現です。保守性が低い理由は、無謀と慎重、意図的と不注意に分類でき、多くの場合、開発者の無能さ、時間と目標の欠如、不注意と作成コストと利益の不一致に起因します。ドキュメント、特に保守可能なソースコードから。

サイズ
ソフトウェアサイズを測定するには、データベース構造スクリプト、データ操作ソースコード、コンポーネントヘッダー、構成ファイルなど、ソースコード全体を正しく収集する必要が測定するソフトウェアサイズには、基本的に技術サイズ（フットプリント）と機能サイズ：
広く説明されているいくつかのソフトウェア技術的なサイジング方法が最も一般的な技術的なサイジング方法は、テクノロジーごとのコード行数（#LOC）、ファイル、関数、クラス、テーブルなどの数であり、そこからバックファイアファンクションポイントを計算できます。
機能サイズの測定で最も一般的なのは、ファンクションポイント分析です。ファンクションポイント分析は、ユーザーの観点から成果物のソフトウェアのサイズを測定します。ファンクションポイントのサイジングは、ユーザーの要件に基づいて行われ、開発者/見積もり担当者のサイズと価値（提供される機能）の両方を正確に表現し、顧客に提供されるビジネス機能を反映します。この方法には、ユーザーが認識できる入力、出力、およびデータストアの識別と重み付けが含まれます。サイズ値は、ソフトウェアの提供とパフォーマンスを定量化および評価するための多数の測定値と組み合わせて使用できます（機能ポイントごとの開発コスト、機能ポイントごとの提供された欠陥、スタッフ月ごとの機能ポイント）。
ファンクションポイント分析のサイジング標準は、International Function Point Users Group（IFPUG）によってサポートされています。これは、ソフトウェア開発ライフサイクルの早い段階で適用でき、やや不正確なバックファイア方式のようにコード行に依存しません。この方法はテクノロジーにとらわれず、組織間および業界間での比較分析に使用できます。
ファンクションポイント分析の開始以来、いくつかのバリエーションが進化し、機能サイジング手法のファミリーは、COSMIC、NESMA、ユースケースポイント、FP Lite、アーリーおよびクイックFP、そして最近ではストーリーポイントなどのサイジング手段を含むように拡大しました。ただし、ファンクションポイントには統計的精度の歴史があり、多くのアプリケーション開発管理（ADM）またはアウトソーシング契約で共通の作業単位として使用され、サービスの提供とパフォーマンスの測定の「通貨」として機能します。
ファンクションポイント方法論の一般的な制限の1つは、手動プロセスであるため、アプリケーション開発やアウトソーシング契約などの大規模なイニシアチブでは、労働集約的でコストがかかる可能性があることです。方法論を適用することのこの否定的な側面は、IFPUGがその活動のほとんどが依存しているため、手動アプローチを推進し続けている間、ソフトウェアサイズの測定を自動化するための計算可能なメトリック標準の導入に焦点を当てたITソフトウェア品質コンソーシアムを形成する動機となった業界ITリーダーである可能性がありますFPカウンター認証について。
CISQは、コスト見積もり、進捗状況の追跡、またはその他の関連するソフトウェアプロジェクト管理アクティビティをサポートするために、ソフトウェアのサイズを見積もることとしてサイジングを定義しています。2つの標準が使用されます。ソフトウェアの機能サイズを測定する自動ファンクションポイントと、機能コードと非機能コードの両方のサイズを1つのメジャーで測定する自動拡張ポイントです。

重要なプログラミングエラーの特定
重大なプログラミングエラーは、特定のアーキテクチャおよび/またはコーディングの悪い慣行であり、ビジネスの混乱のリスクが最も高く、即時または長期になります。
これらはテクノロジーに関連していることが多く、コンテキスト、ビジネス目標、およびリスクに大きく依存します。命名規則の尊重を検討する人もいれば、知識移転の基盤を準備している人など、それを絶対的に重要だと考える人もいます。
重大なプログラミングエラーは、CISQ特性ごとに分類することもできます。以下の基本的な例：
信頼性
予期しない動作につながるソフトウェアパターン（初期化されていない変数、nullポインターなど）は避けて
挿入、更新、削除、テーブルの作成、または選択を行うメソッド、プロシージャ、および関数には、エラー管理が含まれている必要があります
マルチスレッド関数はスレッドセーフにする必要がたとえば、サーブレットまたはストラットアクションクラスには、インスタンス/非最終静的フィールドを含めることはできません。
効率
ネットワークトラフィックを削減するために、クライアント要求（受信およびデータ）の集中化を確実にします
ループ内の大きなテーブルに対してインデックスを使用しないSQLクエリは避けてください
安全
最終的な静的ではないサーブレットクラスのフィールドは避けてください
エラー管理を含めずにデータアクセスを回避する
制御戻りコードを確認し、エラー処理メカニズムを実装します
クロスサイトスクリプティングの欠陥やSQLインジェクションの欠陥を回避するために、入力の検証を
保守性
理解しやすさを向上させるために、深い継承ツリーとネストは避ける必要があります
モジュールは、変更の伝播を避けるために緩く結合する必要があります（ファンアウト、仲介者）
同種の命名規則を適用する

運用可能な品質モデル
SqualeやQuamoco などの品質モデルに関する新しい提案は、品質属性と測定の定義の直接統合を広めています。品質属性を分解したり、追加のレイヤーを定義したりすることで、複雑で抽象的な品質属性（信頼性や保守性など）がより管理しやすくなり、測定可能になります。これらの品質モデルは産業の文脈で適用されていますが、広く採用され

トリビア
「科学はその測定ツールと同じくらい成熟しています。」
「私はそれを見るとそれを知っています。」
「測定できないものを制御することはできません。」（トム・デマルコ）
「製品の品質を検査することはできません。」（W.エドワーズデミング）
「スケジュールを守る甘さが忘れられた後も、質の悪い苦味は長く残っています。」（匿名）
「スペックから始めなければ、書くコードはすべてパッチです。」（レスリー・ランポート）

も参照してください
ソフトウェアの異常
アクセシビリティ
可用性
ベストコーディングプラクティス
結束とカップリング
循環的複雑度
コーディング規約
コンピューターのバグ
信頼性 GQM ISO / IEC 9126
ソフトウェアプロセスの改善と機能の決定-ISO / IEC 15504
プログラミングスタイル
品質：品質管理、総合品質管理。
要件管理
スコープ（プロジェクト管理）
安全
セキュリティエンジニアリング
ソフトウェア品質保証
ソフトウェアアーキテクチャ
ソフトウェア品質管理
ソフトウェアメトリクス
ソフトウェアの再利用性
ソフトウェア標準
ソフトウェアテスト
妥当性
静的プログラム分析

参考文献
アンドロイドOS品質ガイドラインなど2021年7月UI、セキュリティのためのチェックリストを含みます
情報技術と通信の海事管理者協会（AMMITEC）。海事ソフトウェア品質ガイドライン。2017年9月
Capers Jones and Olivier Bonsignour、「The Economics of Software Quality」、Addison-Wesley Professional、第1版、2011年12月31日、ISBN 978-0-13-258220-9
CATラボ-CNESコード分析ツールラボ（GitHub上）
Girish Suryanarayana、ソフトウェアプロセスと設計品質：綱引き？
Ho-Won Jung、Seung-Gweon Kim、Chang-SinChung。ソフトウェア製品の品質の測定：ISO / IEC9126の調査。IEEEソフトウェア、21（5）：10–13、2004年9月/ 10月。
国際標準化機構。ソフトウェアエンジニアリング—製品品質—パート1：品質モデル。ISO、スイス、ジュネーブ、2001年。ISO/ IEC 9126-1：2001（E）。
ソフトウェア製品品質の測定：ISO 25000シリーズおよびCMMI（SEIサイト）
MSQF-測定ベースのソフトウェア品質フレームワークCornellUniversity Library
Omar Alshathry、Helge Janicke、「Optimizing Software Quality Assurance」、compsacw、pp。87–92、2010 IEEE 34th Annual Computer Software and Applications Conference Workshops、2010。
ロバートL.グラス。品質ソフトウェアの構築。プレンティスホール、ニュージャージー州アッパーサドルリバー、1992年。
Roland Petrasch、「「ソフトウェア品質」の定義：実用的なアプローチ」、ISSRE、1999年
Software Quality Professional、 American Society for Quality（ASQ）
SpringerNatureによるSoftwareQuality Journal
スピネリス、ディオミディス（2006-04-04）。コード品質：オープンソースの観点。米国ニュージャージー州アッパーサドルリバー：アディソン-ウェスリープロフェッショナル。ISBN 978-0-321-16607-4。
Stephen H.Kan。ソフトウェア品質エンジニアリングのメトリクスとモデル。アディソン-ウェスリー、マサチューセッツ州ボストン、第2版、2002年。
ステファン・ワーグナー。ソフトウェア製品の品質管理。Springer、2013年。

参考文献
ノート
^ ボード（IREB）、国際要求工学。「歴史から学ぶ：ソフトウェア要件エンジニアリングの事例–要件エンジニアリングマガジン」。歴史から学ぶ：ソフトウェア要件エンジニアリングの事例–要件エンジニアリングマガジン。2021-02-25を取得。
^ Pressman、Roger S.（2005）。ソフトウェアエンジニアリング：実践者のアプローチ（第6回国際版）。マグロウヒルエデュケーション。NS。388. ISBN
0071267824。
^ 「自動ソースコード品質測定仕様バージョン1.0について」。www.omg.org 。2021-02-25を取得。
^ 「エンドツーエンドのテストを実行する方法」。smartbear.com 。2021-02-25を取得。
^ 「CISQの推奨事項に沿って、復元力があり、安全で、効率的で、簡単に変更できるITシステムを提供する方法」（PDF）。2013年12月28日のオリジナルからアーカイブ（PDF）。
^ 14：00-17：00。「ISO / IEC25010：2011」。ISO 。2021-02-23を取得。
> ^ アーマー、フィリップG.（2012-06-01）。「コントロールの尺度」。ACMの通信。55（6）：26–28。土井：10.1145 /2184319.2184329。ISSN 0001から0782まで。S2CID 6059054。

^ Voas、J。。「ソフトウェアの秘密のソース：「-ilities」」。IEEEソフトウェア。21（6）：14–15。土井：10.1109 /MS.2004.54。ISSN 1937から4194まで。
^ 「コード品質基準| CISQ-情報およびソフトウェア品質のためのコンソーシアム」。www.it-cisq.org 。2021-02-25を取得。
^ 「ソフトウェアサイジング標準| CISQ-情報とソフトウェア品質のためのコンソーシアム」。www.it-cisq.org 。2021-02-25を取得。
^ J. Bohnet、J.Döllnerは 2014年4月27日にウェイバックマシンでアーカイブされました。「ソフトウェアマップによるコード品質と開発活動の監視」。技術的負債の管理に関するIEEEACM ICSEワークショップの議事録、pp。9-16、2011年。
^ 「IIA-グローバルテクノロジー監査ガイド：IT変更管理：組織の成功に不可欠」。na.theiia.org 。2021-02-26を取得。
^ Boursier、Jérôme（2018-01-11）。「メルトダウンとスペクターのフォールアウト：パッチの問題が続く」。MalwarebytesLabs 。2021-02-26を取得。
^ メステウ。「ソフトウェアアップデートのベストプラクティス-構成マネージャー」。docs.microsoft.com 。2021-02-26を取得。
^ ライト、ハイラムK.（2009-08-25）。「リリースエンジニアリングプロセス、モデル、およびメトリック」。博士号シンポジウムに関するESEC / FSEの博士号シンポジウムの議事録。ESEC / FSE博士シンポジウム’09。オランダ、アムステルダム：Association for Computing Machinery：27–28。土井：10.1145 /1595782.1595793。ISBN
978-1-60558-731-8。S2CID 10483918。
^ van der Hoek、André; ホール、リチャードS。; ハイムビグナー、デニス; ウルフ、アレクサンダーL.（1997年11月）。「ソフトウェアリリース管理」。ACMSIGSOFTソフトウェアエンジニアリングノート。22（6）：159–175。土井：10.1145 /267896.267909。ISSN 0163から5948まで。
^ Moore、Mike Sutton、Tym（2008-07-30）。「ソフトウェアリリース管理を改善する7つの方法」。CIO 。2021-02-26を取得。
^ クラーク、ミッチェル（2021-02-24）。「iRobotは、最新のルンバソフトウェアアップデートの混乱を一掃できるようになるまでに数週間かかると言っています」。ザ・ヴァージ。2021-02-25を取得。
^ 「トップ25ソフトウェアエラー| SANSインスティテュート」。www.sans.org 。2021-02-25を取得。
^ “” ‘ 149時間ごとにオフにしてから再度オンにする’は、3億ドルのエアバス飛行機のソフトウェアバグに対する救済策です””。ギズモード。2021-02-25を取得。
^ ソフトウェア、Gimpel。「MISRAC、トヨタとタスクXの死」。2021-02-25を取得。
^ 「トヨタと意図しない加速に関する最新情報«バーコード」。Embeddedgurus.com 。2021-02-25を取得。
^ 医療機器：Therac-25 * ワシントン大学ナンシーレベソンのウェイバックマシンで2008年2月16日にアーカイブ
^ Wayback Machineで2010年7月5日にアーカイブされた組み込みソフトウェア、Edward A. Lee、Advances in Computers（M。Zelkowitz、編集者）、Vol。56、Academic Press、ロンドン、2002年、UCBERLメモランダムM01 / 26カリフォルニア大学、バークレー、CA 94720、米国、2001年11月1日から改訂
^ 「航空機認証ソフトウェアおよび航空機搭載電子ハードウェア」。2014年10月4日にオリジナルからアーカイブされました。取得した28年9月2014。
^ 「米国の貧弱なソフトウェア品質のコスト：2020年のレポート| CISQ-情報およびソフトウェア品質のためのコンソーシアム」。www.it-cisq.org 。2021-02-25を取得。
^ 「廃棄物とは何ですか？|アジャイルアライアンス」。アジャイルアライアンス| 。2021-02-25を取得。
^ 1月26日、ソフトウェアのスコット・マットソン。2018; Pst、午前7時54分。「レポート：ソフトウェアの障害により、2017年に1.7兆ドルの経済的損失が発生しました」。TechRepublic 。2021-02-25を取得。
> ^ Cohane、Ryan（2017-11-16）。「ソフトウェアバグの経済的コスト」。ミディアム。2021-02-25を取得。
^ Eloff、1月; 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-02-25を取得
^ 「ソフトウェアの品質が悪いと、昨年は2兆ドルのコストがかかり、セキュリティが危険にさらされました」。CIOダイブ。2021-02-26を取得。
^ 「Synopsysが後援するCISQの調査では、2020年に2.08兆米ドルのソフトウェア品質の低下によるコストが見積もられています」。Finance.yahoo.com 。2021-02-26を取得。
^ 「2020年のデータ侵害のコストは？」。デジタルガーディアン。2020-08-06 。2021-03-08を取得。
^ 「データ侵害レポート2020のコスト| IBM」。www.ibm.com。2020 。2021-03-08を取得。
^ 「ISO-ISO9000ファミリー-品質管理」。ISO 。2021-02-24を取得。
^ 14：00-17：00。「ISO / IEC / IEEE24765：2017」。ISO 。2021-02-24を取得。
> ^ “”自動車ソフトウェアの習得|マッキンゼー””。www.mckinsey.com 。2021-02-25を取得。
^ 14：00-17：00。「ISO / IEC25010：2011」。ISO 。2021-02-24を取得。
> ^ ウォレス、DR（2002）。「実用的なソフトウェア信頼性モデリング」。議事録第26回NASAゴダードソフトウェアエンジニアリングワークショップ。米国メリーランド州グリーンベルト：IEEEComput。Soc：147–155。土井：10.1109 /SEW.2001.992668。ISBN
978-0-7695-1456-7。S2CID 57382117。
^ 「ソフトウェア品質とは何ですか？| ASQ」。asq.org 。2021-02-24を取得。
^ 「SAMATE-ソフトウェアアシュアランスメトリクスとツール評価プロジェクトのメインページ」。samate.nist.gov。2021年2月3日。2021-02-26を取得。
^ PMBOKガイドのソフトウェア拡張。プロジェクトマネジメント協会（第5版）。ペンシルベニア州ニュータウンスクエア。2013年。ISBN
978-1-62825-041-1。OCLC 959513383。
^ SHEWHART、WALTER A.（2015）。製造された製品の品質の経済的管理。[出版場所は特定されていません]：MARTINO FINEBooks。ISBN
978-1-61427-811-5。OCLC 1108913766。
^ キッチナム、B。; Pfleeger、SL（1996年1月）。「ソフトウェア品質：とらえどころのないターゲット」。IEEEソフトウェア。13（1）：12–21。土井：10.1109 /52.476281。ISSN 1937から4194まで。
^ Garvin、David A.（1988）。品質の管理：戦略的かつ競争力のある優位性。ニューヨーク：フリープレス。ISBN
0-02-911380-6。OCLC 16005388。
^ B.KitchenhamおよびS.Pfleeger、「ソフトウェア品質：とらえどころのないターゲット」、IEEE Software、vol。13、いいえ。1、pp。12–21、1996。
^ Kan、Stephen H.（2003）。ソフトウェア品質工学の測定基準とモデル（第2版）。ボストン：アディソン-ウェスリー。ISBN
0-201-72915-6。OCLC 50149641。
^ 国際標準化機構、「ISO / IEC 9001：品質管理システム-要件」、1999年。
^ WEデミング、「危機から抜け出す：品質、生産性、競争力」。ケンブリッジ大学出版局、1988年。
^ AV Feigenbaum、「Total Quality Control」、McGraw-Hill、1983年。
^ JMジュラン、「ジュランの品質管理ハンドブック」、McGraw-Hill、1988年。
^ Weinberg、G。（1991）。「品質ソフトウェア管理第1巻：システム思考」。未定義。S2CID 62542541 。2021-02-24を取得。
^ 「品質ソフトウェア管理（品質ソフトウェアシリーズ）第2巻：一次測定」。GeraldMWeinberg.com。2019-12-05 。2021-02-24を取得。
^ クロスビー、P。、品質は無料、マグロウヒル、1979年
^ 「SUP.9–問題解決管理-Kugler MaagCie」。www.kuglermaag.com 。2021-02-25を取得。
^ Hoipt（2019-11-29）。「組織はしばしば「品質保証」（QA）と「品質管理」（QC）という用語を使用します…」。ミディアム。2021-02-25を取得。
^ ウォレス、D。; ワトソン、AH; Mccabe、TJ（1996-08-01）。「構造化テスト：循環的複雑度メトリックを使用したテスト方法」。
^ Bellairs、リチャード。「コード品質とは何ですか？そしてコード品質を改善する方法」。PERFORCEソフトウェア。2021-02-28を取得。
^ 「OMGホワイトペーパー| CISQ-情報およびソフトウェア品質のためのコンソーシアム」。www.it-cisq.org 。2021-02-26を取得。
^ 「CISQの推奨事項に沿った復元力、安全性、効率性、アジャイルなITシステムを提供する方法-ホワイトペーパー| Object Management Group」（PDF）。2013年12月28日のオリジナルからアーカイブ（PDF）。
^ 「ソフトウェアサイズ測定：ソースステートメントを数えるためのフレームワーク」。resources.sei.cmu.edu 。2021-02-24を取得。
^ Halstead、Maurice H.（1977）。ソフトウェアサイエンスの要素（オペレーティングおよびプログラミングシステムシリーズ）。米国：Elsevier Science Inc. ISBN
978-0-444-00205-1。
^ Chidamber、SR; ケメラー、CF（1994年6月）。「オブジェクト指向設計のためのメトリクススイート」。ソフトウェアエンジニアリングに関するIEEEトランザクション。20（6）：476–493。土井：10.1109 /32.295895。hdl：1721.1 / 48424。ISSN 1939から3520まで。
^ ナイガード、マイケル（2007）。それを解放しなさい！。オライリーメディアカンパニーサファリ（第1版）。ISBN
978-0978739218。OCLC 1102387436。
^ 「CWE-一般的な弱点の列挙」。cwe.mitre.org。2016年5月10日にオリジナルからアーカイブされました。
^ Boehm、B.、Brown、JR、Kaspar、H.、Lipow、M.、MacLeod、GJ、およびMerritt、MJ（1978）。ソフトウェア品質の特徴。北ホラント。
^ “”SEICERTコーディング標準-CERTセキュアコーディング-Confluence”。wiki.sei.cmu.edu 。2021-02-24を取得。
^ 「コード品質とコードセキュリティ：それらはどのように関連していますか？| Synopsys」。ソフトウェア整合性ブログ。2019-05-24 。2021-03-09を取得。
^ 「データ侵害レポート2020のコスト| IBM」。www.ibm.com。2020 。2021-03-09を取得。
^ 「データ侵害レポートの2020年のコストからの重要なポイント」。ブルーフィン。2020-08-27 。2021-03-09を取得。
^ 「CWE-一般的な弱点の列挙」。Cwe.mitre.org。2013-10-14にオリジナルからアーカイブされました。
^ 開発中のセキュリティー：IBM Secure Engineering Framework | IBMRedbooks。2016-09-30。
^ IBM Tivoli SecuritySolutionsを使用したエンタープライズ・セキュリティー・アーキテクチャー| IBMRedbooks。2016-09-30。
^ 「安全なアーキテクチャ設計の定義| CISA」。us-cert.cisa.gov 。2021-03-09を取得。
^ 「OWASPFoundation |アプリケーションセキュリティのためのオープンソースFoundation」。owasp.org 。2021-02-24を取得。
^ 「CWEのトップ25」。Sans.org 。
^ IfSQレベル-2 ウェイバックマシンで2011年10月27日にアーカイブされたコンピュータプログラムソースコードの基礎レベルの標準、第2版、2008年8月、Graham Bolton、Stuart Johnston、IfSQ、Institute for SoftwareQuality。
^ ファウラー、マーティン（2009年10月14日）。「TechnicalDebtQuadrant」。2013年2月2日にオリジナルからアーカイブされました。
^ プラウス、クリスチャン; Durdik、Zoya（2012年6月3日）。「アーキテクチャ設計とドキュメンテーション：アジャイル開発の無駄？」2012ソフトウェアおよびシステムプロセスに関する国際会議（ICSSP）。IEEEコンピュータソサエティ。pp。130–134。土井：10.1109 /ICSSP.2012.6225956。ISBN
978-1-4673-2352-9。S2CID 15216552。
^ 「ソフトウェアサイジング標準| CISQ-情報とソフトウェア品質のためのコンソーシアム」。www.it-cisq.org 。2021-01-28を取得。
^ 「ソフトウェアが失敗する理由」。IEEEスペクトラム：テクノロジー、エンジニアリング、サイエンスニュース。2005年9月2日。2021-03-20を取得。
^ ワーグナー、ステファン; ゲーブ、アンドレアス; ハイネマン、ラース; Kläs、Michael; ランパソナ、コンスタンザ; Lochmann、Klaus; マイヤー、アロイス; Plösch、Reinhold; ザイドル、アンドレアス（2015）。「運用可能な製品品質モデルと評価：Quamocoアプローチ」（PDF）。情報およびソフトウェア技術。62：101〜123。arXiv：1611.09230。土井：10.1016 /j.infsof.2015.02.009。S2CID 10992384。
^ Ebert、Christof（2010）。ソフトウェア測定：確立-抽出-評価-実行。ISBN
9783642090806。OCLC 941931829。
^ 「管理不能な管理：より多くの経験則」。www.managingtheunmanageable.net 。2021-02-26を取得。
^ Suryanarayana、Girish（2015）。「ソフトウェアプロセスと設計品質：綱引き？」。IEEEソフトウェア。32（4）：7–11。土井：10.1109 /MS.2015.87。S2CID 9226051。
^ 「ソフトウェア品質の専門家| ASQ」。asq.org 。2021-01-28を取得。
^ 「ソフトウェア品質ジャーナル」。スプリンガー。2021-01-28を取得。

参考文献
Albrecht、AJ（1979）、アプリケーション開発の生産性の測定。共同SHARE / GUIDEIBMアプリケーション開発シンポジウムの議事録。、IBM
ベンメナケム、M。; Marliss、GS（1997）、ソフトウェア品質、実用的で一貫性のあるソフトウェアの作成、Thomson Computer Press
ベーム、B。; ブラウン、JR; Kaspar、H。; Lipow、M。; マクラウド、GJ; メリット、MJ（1978）、ソフトウェア品質の特性、北ホラント。
Chidamber、S。; Kemerer、C。（1994）、オブジェクト指向設計のためのメトリクススイート。ソフトウェアエンジニアリングに関するIEEEトランザクション、20（6）、pp。476–493
エバート、クリストフ; Dumke、Reiner、ソフトウェア測定：確立-抽出-評価-実行、Kindle版、p。91
ガルムス、D。; Herron、D。（2001）、ファンクションポイント分析、Addison Wesley
Halstead、ME（1977）、Elements of Software Science、Elsevier North-Holland
ハミル、M。; Goseva-Popstojanova、K。（2009）、ソフトウェアフォールトおよび障害データの一般的なフォールト。ソフトウェアエンジニアリングのIEEEトランザクション、35（4）、pp。484–496
ジャクソン、DJ（2009）、信頼できるソフトウェアへの直接の道。ACMの通信、52（4）。
Martin、R。（2001）、ネットワークシステムの脆弱性の管理、IEEEComputer。
McCabe、T。（1976年12月）、複雑さの尺度。ソフトウェアエンジニアリングに関するIEEEトランザクション
McConnell、Steve（1993）、Code Complete（First ed。）、Microsoft Press
ナイガード、MT（2007）、リリースイット！Production Ready Software、ThePragmaticProgrammersの設計と展開。
Park、RE（1992）、ソフトウェアサイズ測定：ソースステートメントをカウントするためのフレームワーク。（CMU / SEI-92-TR-020）。、カーネギーメロン大学ソフトウェア工学研究所
プレスマン、ロジャーS.（2005）。ソフトウェアエンジニアリング：実践者のアプローチ（第6回国際版）。マグロウヒルエデュケーション。ISBN 0071267824。
Spinellis、D。（2006）、Code Quality、Addison Wesley

外部リンク
コモンズには、ソフトウェア品質に関連するメディアが
コードが王様の場合：自動車ソフトウェアの卓越性をマスターする（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自動技術的負債基準
自動化された品質保証（中articled IREBハリーSneedで）
構造化テスト：循環的複雑度メトリックを使用したテスト方法（1996）
コード分析ツールを使用したアプリケーション品質の分析（Microsoft、ドキュメント、Visual Studio、2016年）”