Loading article…
ソフトウェアエンジニアリングの文脈では、ソフトウェア品質は、関連しているが異なる2つの概念を指します。[ 1 ]
構造的品質の多くの側面は、ソフトウェアの内部構造、ソースコード（ソフトウェアメトリクスを参照）[ 4 ]をユニットレベルおよびシステムレベル（エンドツーエンドテスト[ 5 ]と呼ばれることもある）で分析することによってのみ静的に評価できます。これは、そのアーキテクチャが、オブジェクト管理グループ（OMG）によるこのトピックに関する論文で概説されているソフトウェアアーキテクチャの健全な原則にどれだけ準拠しているかを実質的に示すものです。[ 6 ]
ユーザビリティなどの構造的特性は、動的にのみ評価できます（ユーザーまたはユーザーに代わって操作する人がソフトウェア、あるいは少なくともプロトタイプや部分的な実装とやり取りします。段ボールで作った模擬版とのやり取りでさえ、プロトタイプとみなせるため、動的テストとなります）。信頼性などの他の側面は、ソフトウェアだけでなく基盤となるハードウェアも関係するため、静的にも動的にも評価できます（ストレステスト）。
自動テストと適合性関数を使用することで、品質に関連する属性の一部を維持するのに役立つ。[ 7 ]
機能品質は通常、動的に評価されますが、静的テスト（ソフトウェアレビューなど）を使用することも可能です。
歴史的に、ソフトウェア品質管理に適用される属性とメトリクスの構造、分類、用語は、ISO 9126およびその後のISO/IEC 25000規格から派生または抽出されています。[ 8 ]これらのモデル (モデルを参照) に基づいて、IT ソフトウェア品質コンソーシアム(CISQ) は、ソフトウェアがビジネス価値を提供するために必要な 5 つの主要な望ましい構造特性を定義しました。[ 9 ]信頼性、効率性、セキュリティ、保守性、および (適切な) サイズ。[ 10 ] [ 11 ] [ 12 ]
ソフトウェア品質測定は、ソフトウェアプログラムまたはシステムがこれら5つの次元のそれぞれにおいてどの程度優れているかを定量化します。ソフトウェア品質の総合的な尺度は、定性的または定量的なスコアリングスキーム、あるいはその両方を組み合わせたもの、そして優先順位を反映した重み付けシステムによって算出できます。ソフトウェア品質を線形連続体上に位置づけるこの見方は、「重大なプログラミングエラー」の分析によって補完されます。これらのエラーは、特定の状況下では壊滅的な停止やパフォーマンスの低下を引き起こし、総合的な測定に基づく評価に関係なく、特定のシステムを使用不可能にする可能性があります。システムレベルで発見されるこのようなプログラミングエラーは、本番環境の問題の最大90%を占めますが、ユニットレベルでは、はるかに数が多いにもかかわらず、プログラミングエラーは本番環境の問題の10%未満を占めるにすぎません（90-90ルールも参照）。したがって、W.エドワーズ・デミングが述べたように、システム全体のコンテキストを伴わないコード品質は、限られた価値しか持ちません。
ソフトウェア品質の測定値を表示、探索、分析、伝達するために、情報視覚化の概念と技術は、特に複数のソフトウェア品質の測定値を相互に、またはソフトウェアやシステムのコンポーネントに関連付ける必要がある場合に有用な視覚的かつインタラクティブな手段を提供する。たとえば、ソフトウェアマップは、「ソフトウェア開発、ソフトウェア品質、およびシステムダイナミクスに関する情報を表現し、組み合わせることができる」特殊なアプローチである。[ 13 ]
ソフトウェアの品質は、ソフトウェアプロジェクトのリリースフェーズでも重要な役割を果たします。具体的には、リリースプロセス（パッチプロセスも含む）[ 14 ] [ 15 ] 、構成管理[ 16 ]の品質と確立は、ソフトウェアエンジニアリングプロセス全体の重要な部分です。[ 17 ] [ 18 ] [ 19 ]
ソフトウェアの品質は、少なくとも2つの主要な観点に基づいている。
ソフトウェア品質とは、「ソフトウェア製品が要求事項に適合する能力」である[ 36 ] [ 37 ]。一方、顧客価値創造[ 38 ] [ 39 ]や欠陥レベル[ 40 ]と同義とされる場合もある。ソフトウェア品質の測定は、プロセス品質、内部特性と外部特性を含む製品品質、そして最後にソフトウェアの効果である使用品質の3つの部分に分けられる[ 41 ] 。
ASQでは、ソフトウェア品質とは、ソフトウェア製品の望ましい特性を記述するものである。主なアプローチは、欠陥管理と品質特性の2つである。[ 42 ]
ソフトウェア保証（SA）は、特性とそれを実現するためのプロセスの両方をカバーします。[ 43 ]
プロジェクトマネジメント協会のPMBOKガイド「ソフトウェア拡張」では、「ソフトウェア品質」そのものではなく、ソフトウェア品質保証 (SQA) を「他のソフトウェアプロセスを監査して、それらのプロセスが遵守されていることを確認する継続的なプロセス (例えば、ソフトウェア品質管理計画を含む)」と定義しています。一方、ソフトウェア品質管理 (SCQ) は「開発中または変更中のソフトウェアの品質要件に対する成果物の満足度を確保するために、方法、ツール、技術を適用することに気を配ること」を意味します。[ 44 ]
記録に残る歴史の中で品質を最初に定義したのは、20世紀初頭のシューハートです。「品質には2つの共通する側面があります。1つは、人間の存在とは無関係な客観的現実として物の品質を考慮することです。もう1つは、客観的現実の結果として私たちが考えたり、感じたり、知覚したりすることです。言い換えれば、品質には主観的な側面があるのです。」[ 45 ]
キッチンハムとプフリーガーは、デビッド・ガービンの教えをさらに報告し、品質に関する5つの異なる視点を特定しています。[ 46 ] [ 47 ]
製品の品質を定義しようとする試みに内在する問題は、ほぼすべての製品において、巨匠ウォルター・A・シューハートによって述べられています。品質を定義することの難しさは、ユーザーの将来のニーズを測定可能な特性に変換し、ユーザーが支払う価格で満足を与える製品を設計および製造できるようにすることです。これは容易ではなく、その試みがかなり成功したと感じた途端、消費者のニーズが変化したり、競合他社が参入したりすることに気づきます。[ 51 ]
品質は顧客の判断であり、エンジニアの判断でも、マーケティングの判断でも、一般的な経営判断でもありません。それは、製品やサービスに対する顧客の実際の経験に基づいており、明示的か暗示的か、意識的か単に感じ取られたものか、技術的に運用可能か完全に主観的かを問わず、顧客の要求に照らし合わせて測定され、競争の激しい市場においては常に変化する目標を表しています。[ 52 ]
「品質」という言葉には複数の意味があります。この言葉の使用において支配的な意味を持つのは、次の2つの意味です。1. 品質とは、顧客のニーズを満たし、それによって製品満足度を提供する製品の特徴のことです。2. 品質とは、欠陥がないことです。しかしながら、このようなハンドブックでは、「使用に適していること」という短い定義に品質を標準化するのが便利です。[ 53 ]
トム・デマルコは、「製品の品質は、それが世界をどれだけ良い方向に変えるかによって決まる」と提唱している。デマルコ、トム（1999）。「マネジメントは品質を（不可能に）作り出すことができる」。カッターITサミット。{{cite web}}:欠落または空|url=(ヘルプ)これは、ソフトウェアの品質を決定する上で、構造的な品質よりも機能的な品質とユーザーの満足度の方が重要であるという意味に解釈できます。
ジェラルド・ワインバーグが『品質ソフトウェア管理：システム思考』で提唱した別の定義は、「品質とは、ある人にとっての価値である」である。[ 54 ] [ 55 ]
品質を定義する上での課題の一つは、「誰もがそれを理解していると思っている」[ 56 ]ことであり、ソフトウェア品質の他の定義は、ビジネスで使用される品質の概念のさまざまな説明を拡張することに基づいている可能性がある。
ソフトウェア品質は、品質保証 や問題解決管理[ 57 ] 、品質管理[ 58 ] 、DevOpsと混同されることもよくあります。これらの分野と重複する部分もありますが（PMIの定義も参照）、テストだけでなくプロセス、管理、改善、評価などにも焦点を当てている点で独特です[ 58 ]。
ソフトウェアの品質を、開発者の意思決定に実際に適用できる方法で測定することは困難です。この困難さは、複雑性や保守性などの多くの品質属性が多次元的であり、単一の指標で完全に捉えることができないという点に一部起因しています。[ 59 ]
このセクションで提示された概念は、構造的および機能的なソフトウェア品質の両方に適用できますが、後者の測定は基本的にソフトウェアテストを通じて行われます。[ 60 ]テストだけでは不十分です。ある研究によると、「個々のプログラマーは、自分のソフトウェアのバグを見つける効率が50%未満です。また、ほとんどのテスト形式は効率が35%しかありません。そのため、[ソフトウェア]品質を判断することが困難になります。」[ 61 ]
ソフトウェア品質測定とは、システムやソフトウェアが望ましい特性をどの程度備えているかを定量化することです。これは、定性的、定量的、あるいはその両方を組み合わせた方法で行うことができます。いずれの場合も、望ましい特性ごとに、ソフトウェアやシステムに存在することがその特性と相関し、関連付けられる一連の測定可能な属性が存在します。例えば、移植性に関連する属性の一つに、プログラム内のターゲット依存ステートメントの数があります。より正確には、品質機能展開（ QFD）アプローチを用いる場合、これらの測定可能な属性は、上記のソフトウェア品質の定義における「何」を実現するために強制する必要のある「方法」に相当します。
ソフトウェア品質管理に適用される属性と指標の構造、分類、用語は、ISO 9126-3およびそれに続くISO/IEC 25000:2005品質モデルから派生または抽出されています。主な焦点は内部構造品質にあります。ビジネスアプリケーションアーキテクチャなどの特定の領域や、データアクセスと操作、トランザクションの概念などの技術的特性を扱うために、サブカテゴリが作成されています。
ソフトウェア品質特性とその測定可能な属性間の依存関係ツリーは、右の図に示されています。この図では、ユーザー（右）またはビジネスシステムの所有者にとって重要な5つの特性のそれぞれが、測定可能な属性（左）に依存しています。
プログラミングエラーと本番環境の欠陥の相関関係から、基本的なコードエラーがソースコード全体のエラーの 92 パーセントを占めていることが明らかになりました。これらの多数のコードレベルの問題は、最終的に本番環境の欠陥の 10 パーセントにしか影響しません。アーキテクチャ レベルでの不適切なソフトウェア エンジニアリングの実践は、欠陥全体の 8 パーセントを占めるにすぎませんが、問題修正に費やされる労力の半分以上を消費し、本番環境における深刻な信頼性、セキュリティ、および効率の問題の 90 パーセントにつながります。[ 62 ] [ 63 ]
既存のソフトウェア測定の多くは、ソースコードを解析して個々の命令[ 64 ]トークン[ 65 ]制御構造（複雑性）、およびオブジェクト[ 66 ]を取得することによって得られるアプリケーションの構造要素をカウントします。
ソフトウェア品質測定とは、システムまたはソフトウェアがこれらの側面においてどの程度優れているかを定量化することです。分析は、定性的アプローチ、定量的アプローチ、または両方を組み合わせたアプローチを用いて実施でき、例えば、測定対象となる要素間の相対的な重要度を反映する加重平均などを用いて、総合的な見解を得ることができます。
ソフトウェアの品質を線形連続体として捉えるこの見方は、個別の重大なプログラミングエラーの特定によって補完されなければなりません。これらの脆弱性はテストケースで失敗しないかもしれませんが、特定の状況下では壊滅的な停止、パフォーマンスの低下、セキュリティ侵害、データの破損、その他無数の問題[ 67 ]につながる可能性のある不適切な慣行の結果であり、集計された測定に基づく評価に関係なく、特定のシステムを事実上使用に適さないものにします。脆弱性のよく知られた例として、共通脆弱性列挙[ 68 ]があります。これは、アプリケーションをセキュリティ侵害にさらすソースコードの脆弱性のリポジトリです。
重要なアプリケーション特性の測定には、上の図に示すように、アプリケーションのアーキテクチャ、コーディング、およびインラインドキュメントの構造属性の測定が含まれます。したがって、各特性は、アプリケーションのさまざまな抽象レベルの属性の影響を受け、ビジネスに影響を与える品質結果の貴重な予測因子となるためには、特性の測定値の計算にそれらすべてを含める必要があります。上の図に示す特性測定値の計算に対する階層的アプローチは、TRWのBoehmとその同僚によって最初に提案され（Boehm、1978）[ 69 ]、ISO 9126および25000シリーズ規格で採用されているアプローチです。これらの属性は、アプリケーションのソースコードの静的解析の解析結果から測定できます。信頼性やパフォーマンス効率などのアプリケーションの動的特性でさえ、その原因はアプリケーションの静的構造にあります。
構造品質の分析と測定は、ソースコード、アーキテクチャ、ソフトウェアフレームワーク、データベーススキーマを、システムの概念的および論理的アーキテクチャを定義する原則と標準に照らし合わせて分析することによって行われます。これは、開発ツールが通常行う基本的なローカルなコンポーネントレベルのコード分析とは異なります。後者は主に実装上の考慮事項に関心があり、デバッグやテスト活動において非常に重要です。
信頼性の低さの根本原因は、適切なアーキテクチャ設計とコーディング手法への不遵守が複合的に作用することにあります。この不遵守は、アプリケーションの静的品質属性を測定することで検出できます。アプリケーションの信頼性を支える静的属性を評価することで、ビジネスリスクのレベル、およびアプリケーションが運用開始時に発生する可能性のある障害や不具合の発生確率を推定できます。
信頼性を評価するには、少なくとも以下のソフトウェアエンジニアリングのベストプラクティスと技術的特性をチェックする必要があります。
アプリケーションのアーキテクチャや使用されるサードパーティ製コンポーネント（外部ライブラリやフレームワークなど）に応じて、提供されるソフトウェアの信頼性をより適切に評価するために、上記のベストプラクティスのリストに沿ってカスタムチェックを定義する必要があります。
信頼性と同様に、パフォーマンスの非効率性の原因は、多くの場合、優れたアーキテクチャとコーディングの実践に違反していることにあり、これはアプリケーションの静的品質属性を測定することで検出できます。これらの静的属性は、特に複雑なアルゴリズムや膨大な量のデータを処理するために高い実行速度を必要とするアプリケーションにおいて、潜在的な運用パフォーマンスのボトルネックや将来のスケーラビリティの問題を予測します。
パフォーマンス効率を評価するには、少なくとも以下のソフトウェアエンジニアリングのベストプラクティスと技術的特性を確認する必要があります。
ソフトウェアの品質にはソフトウェアのセキュリティが含まれます。[ 71 ]多くのセキュリティ脆弱性は、SQLインジェクションやクロスサイトスクリプティングなどの不適切なコーディングやアーキテクチャの慣行に起因します。[ 72 ] [ 73 ]これらは、CWE [ 74 ]やカーネギーメロン大学のSEI/コンピュータ緊急センター（CERT）[ 70 ]が管理するリストに詳しく記載されています。
セキュリティを評価するには、少なくとも以下のソフトウェアエンジニアリングのベストプラクティスと技術的特性を確認する必要があります。
保守性には、モジュール性、理解しやすさ、変更しやすさ、テストしやすさ、再利用性、開発チーム間での転送性といった概念が含まれます。これらはコードレベルで重大な問題として現れるものではありません。むしろ、保守性が低いのは、通常、ドキュメント作成、複雑性回避戦略、基本的なプログラミング手法におけるベストプラクティスに対する何千もの小さな違反の結果であり、それがクリーンで読みやすいコードと、整理されておらず読みにくいコードの違いを生み出します。[ 80 ]
保守性を評価するには、以下のソフトウェアエンジニアリングのベストプラクティスと技術的特性を確認する必要があります。
保守性は、保守性の欠如によって生じるコストを表すワード・カニンガムの技術的負債の概念と密接に関連しています。保守性が低い理由は、無謀か慎重か、意図的か不注意かに分類でき、 [ 81 ] [ 82 ]多くの場合、開発者の能力不足、時間と目標の欠如、不注意、ドキュメント、特に保守可能なソースコードの作成コストとメリットの不一致に起因します。[ 83 ]
ソフトウェアのサイズを測定するには、データベース構造スクリプト、データ操作ソースコード、コンポーネントヘッダー、設定ファイルなどを含むソースコード全体を正しく収集する必要があります。測定対象となるソフトウェアのサイズは、基本的に技術的なサイズ（フットプリント）と機能的なサイズの2種類があります。
ファンクションポイント分析のサイジング標準は、国際ファンクションポイントユーザーグループ（IFPUG）によって支持されています。この標準はソフトウェア開発ライフサイクルの初期段階で適用でき、やや不正確なバックファイアリング法のようにコード行数に依存しません。この方法は技術に依存せず、組織間や業界間の比較分析に使用できます。
ファンクションポイント分析が始まって以来、いくつかのバリエーションが開発され、機能規模測定手法のファミリーは、COSMIC、NESMA、ユースケースポイント、FP Lite、早期FP、クイックFP、そして最近ではストーリーポイントといった規模測定指標を含むまでに拡大しました。ファンクションポイントは統計的に正確であるという実績があり、数多くのアプリケーション開発管理（ADM）やアウトソーシング案件において、共通の作業測定単位として使用され、サービスの提供やパフォーマンスの測定における「基準」として機能してきました。
ファンクションポイント手法の一般的な制約の一つは、手作業によるプロセスであるため、アプリケーション開発やアウトソーシングといった大規模な取り組みでは、労力とコストがかさむ可能性があるという点です。この手法のマイナス面が、業界のITリーダーたちが、ソフトウェア規模の測定を自動化するための計算可能なメトリクス標準の導入に焦点を当てたITソフトウェア品質コンソーシアムを設立する動機となったのかもしれません。一方、IFPUGは、その活動のほとんどがFPカウンター認証に依存しているため、手作業によるアプローチを推進し続けています。
CISQは、サイジングを、コスト見積もり、進捗状況の追跡、またはその他の関連するソフトウェアプロジェクト管理活動をサポートするためにソフトウェアのサイズを見積もることと定義しています。2つの標準が使用されます。ソフトウェアの機能サイズを測定するための自動機能ポイントと、機能コードと非機能コードの両方のサイズを1つの尺度で測定するための自動拡張ポイントです。 [ 84 ]
重大なプログラミングエラーとは、最も高い、即時的または長期的な業務中断リスクをもたらす、特定のアーキテクチャおよび/またはコーディングの不適切な慣行のことです。[ 85 ]
これらは多くの場合、技術に関連するものであり、状況、ビジネス目標、リスクに大きく左右されます。命名規則の遵守を重視する人もいれば、例えば知識移転の準備をしているような人は、それを絶対的に重要視するでしょう。
重大なプログラミングエラーは、CISQ特性に基づいて分類することもできます。基本的な例を以下に示します。
SqualeやQuamoco [ 86 ]などの新しい品質モデル提案では、品質属性の定義と測定の直接的な統合が提唱されています。品質属性を細分化したり、さらにレイヤーを追加したりすることで、複雑で抽象的な品質属性（信頼性や保守性など）がより管理しやすく、測定しやすくなります。これらの品質モデルは産業界で適用されていますが、広く普及しているとは言えません。
注記
{{cite book}}: CS1メンテナンス: 場所の発行元が見つかりません (リンク) CS1メンテナンス: その他 (リンク)参考文献
