ソフトウェア品質管理-はじめに

品質の高いソフトウェアとは、合理的にバグや欠陥がなく、時間内に指定された予算内で提供され、要件や期待を満たし、保守可能なソフトウェアを指します。ソフトウェアエンジニアリングのコンテキストでは、ソフトウェアの品質は、*機能品質*と*構造品質*の両方を反映しています。

ソフトウェア機能品質-機能要件または仕様に基づいて、所定の設計をどれだけ満足させるかを反映します。
ソフトウェア構造品質-堅牢性や保守性などの機能要件の配信をサポートする非機能要件の処理、およびソフトウェアが正しく作成された度合いを処理します。
ソフトウェア品質保証-ソフトウェア品質保証（SQA）は、最終的に高品質のソフトウェア製品をもたらすソフトウェアエンジニアリングプロセスの品質を確保するための一連の活動です。アクティビティは、製品を生産するプロセスを確立および評価します。それはプロセスに焦点を合わせたアクションを伴います。
ソフトウェア品質管理-ソフトウェア品質管理（SQC）は、ソフトウェア製品の品質を確保するための一連の活動です。これらの活動は、生産された実際の製品の欠陥を特定することに焦点を当てています。それは製品に焦点を合わせた行動を伴います。

ソフトウェア品質の課題

ソフトウェア業界では、他の工業製品メーカーが通常行うように、開発者はソフトウェアに欠陥がないことを決して宣言しません。この違いは、次の理由によるものです。

製品の複雑さ

製品が許可する動作モードの数です。通常、工業製品では、マシン設定のさまざまな組み合わせで数千未満の動作モードしか許可されていません。ただし、ソフトウェアパッケージを使用すると、何百万もの運用の可能性が広がります。したがって、これらすべての運用上の可能性を正しく保証することは、ソフトウェア業界にとって大きな課題です。

製品の可視性

工業製品は目に見えるため、その欠陥のほとんどは製造プロセス中に検出できます。また、工業製品に部品が存在しないことは、製品で簡単に検出できます。ただし、ディスケットまたはCDに保存されているソフトウェア製品の欠陥は目に見えません。

製品開発と生産プロセス

工業製品では、次の段階で欠陥を検出できます-

製品開発-このフェーズでは、設計者と品質保証（QA）スタッフが製品プロトタイプをチェックおよびテストして、欠陥を検出します。
製品生産計画-このフェーズでは、生産プロセスとツールが設計および準備されます。このフェーズでは、製品を検査して、開発フェーズ中に気付かなかった欠陥を検出する機会も提供します。
製造-このフェーズでは、製品自体の障害を検出するためにQA手順が適用されます。製造の最初の期間に検出された製品の欠陥は、通常、製品の設計や材料、または製造ツールの変更によって修正できます。これにより、将来製造される製品のこのような欠陥がなくなります。

ただし、ソフトウェアの場合、欠陥を検出できる唯一のフェーズは開発フェーズです。ソフトウェアの場合、ソフトウェアコピーの製造とソフトウェアマニュアルの印刷が自動的に行われるため、製品の生産計画と製造段階は必要ありません。

ソフトウェア製品と他の工業製品の欠陥の検出に影響する要因を次の表に示します。

Characteristic

Software Products

Other Industrial Products

Complexity

Millions of operational options

thousand operational options

visibility of product

Invisible Product Difficult to detect defects by sight

Visible Product Effective detection of defects by sight

Nature of development and production process

can defect defects in only one phase

can detect defects in all of the following phases

製品開発
製品生産計画
製造業

複雑さや不可視性などのソフトウェアのこれらの特性により、ソフトウェア品質保証方法の開発とその実装の成功は、非常に専門的な課題となります。

ソフトウェア品質要因

ソフトウェアに影響するさまざまな要因は、ソフトウェア要因と呼ばれます。これらは大きく2つのカテゴリに分類できます。要因の最初のカテゴリは、論理エラーの数など、直接測定できるものであり、2番目のカテゴリは、間接的にのみ測定できる要因を分類します。たとえば、保守性ですが、各要素を測定して、コンテンツと品質管理をチェックします。

ソフトウェア品質要因のいくつかのモデルとその分類が長年にわたって提案されてきました。 McCallによって提案されたソフトウェア品質要因の古典的なモデルは、11の要因で構成されています（McCall et al。、1977）。同様に、12から15の因子で構成されるモデルは、DeutschとWillis（1988）およびEvans and Marciniak（1987）によって提案されました。

これらのモデルはすべて、マッコールのモデルと実質的に異ならない。 McCall要因モデルは、ソフトウェア要件を分類するための実用的で最新の方法を提供します（Pressman、2000）。

マッコールの因子モデル

このモデルは、すべてのソフトウェア要件を11のソフトウェア品質要因に分類します。 11の要因は、製品の運用、製品の改訂、および製品の移行要因の3つのカテゴリに分類されます。

製品の運用要因-正確性、信頼性、効率性、完全性、使いやすさ。
製品改訂要因-保守性、柔軟性、テスト容易性。
製品の移行要因-移植性、再利用性、相互運用性。

製品運用ソフトウェアの品質要因

McCallのモデルによると、製品運用カテゴリには5つのソフトウェア品質要因が含まれており、ソフトウェアの日常の運用に直接影響する要件に対処しています。彼らは次のとおりです-

正しさ

これらの要件は、ソフトウェアシステムの出力の正確性を扱います。彼らが含まれます-

出力ミッション
不正確なデータまたは不正確な計算によって悪影響を受ける可能性がある、出力に必要な精度。
不完全なデータの影響を受ける可能性がある出力情報の完全性。
ソフトウェアシステムによるイベントと応答の間の時間として定義される情報の最新性。
情報の可用性。
ソフトウェアシステムのコーディングと文書化の標準。

信頼性

信頼性の要件は、サービスの失敗に対処します。ソフトウェアシステムの最大許容故障率を決定し、システム全体または1つ以上の個別の機能を参照できます。

効率

ソフトウェアシステムのさまざまな機能を実行するために必要なハードウェアリソースを扱います。処理機能（MHz単位）、ストレージ容量（MBまたはGB単位）、データ通信機能（MBPSまたはGBPS単位）が含まれます。

また、ポータブルコンピューターにある情報システムユニットや屋外に置かれた気象ユニットなど、システムのポータブルユニットの再充電間の時間も扱います。

誠実さ

この要素は、ソフトウェアシステムのセキュリティを扱います。つまり、許可されていない人へのアクセスを防ぎ、読み取り許可と書き込み許可を与える人のグループを区別します。

使いやすさ

ユーザビリティ要件は、新しい従業員のトレーニングとソフトウェアシステムの運用に必要なスタッフリソースを扱います。

製品改訂の品質要因

McCallのモデルによれば、3つのソフトウェア品質要因が製品改訂カテゴリに含まれています。これらの要因は次のとおりです-

保守性

この要因は、ソフトウェア障害の理由を特定し、障害を修正し、修正の成功を確認するために、ユーザーおよび保守要員が必要とする努力を考慮します。

柔軟性

この要素は、ソフトウェアの適応型メンテナンスアクティビティをサポートするために必要な機能と努力を扱います。これには、ソフトウェアを変更せずに、現在のソフトウェアを追加の状況および顧客に適合させることが含まれます。この要素の要件は、サービスを改善し、企業の技術的または商業的環境の変化に適応させるためのソフトウェアの変更や追加など、完全なメンテナンス活動もサポートします。

テスト容易性

テスト容易性の要件は、ソフトウェアシステムのテストとその動作を扱います。事前定義された中間結果、ログファイル、およびシステムの起動前にソフトウェアシステムによって実行される自動診断が含まれ、システムのすべてのコンポーネントが正常に機能しているかどうかを確認し、検出された障害に関するレポートを取得します。これらの要件の別のタイプは、ソフトウェア障害の原因を検出するために保守技術者によって適用される自動診断チェックを扱います。

製品移行ソフトウェアの品質係数

McCallのモデルによると、ソフトウェアのその他の環境への適応と他のソフトウェアシステムとの相互作用を扱う3つのソフトウェア品質要因が製品移行カテゴリに含まれています。これらの要因は次のとおりです-

移植性

移植性の要件は、ソフトウェアシステムを、異なるハードウェア、異なるオペレーティングシステムなどで構成される他の環境に適応させる傾向があります。ソフトウェアは、さまざまな状況で同じ基本ソフトウェアを引き続き使用できる必要があります。

再利用性

この要素は、現在開発中の新しいソフトウェアプロジェクトの1つのプロジェクト用に設計されたソフトウェアモジュールの使用を扱います。また、将来のプロジェクトで、現在開発されているソフトウェアの特定のモジュールまたはモジュールのグループを使用できるようになる場合があります。ソフトウェアの再利用は、開発リソースを節約し、開発期間を短縮し、より高品質のモジュールを提供することが期待されています。

相互運用性

相互運用性の要件は、他のソフトウェアシステムまたは他の機器ファームウェアとのインターフェイスの作成に重点を置いています。たとえば、生産機械とテスト機器のファームウェアは、生産管理ソフトウェアと連動します。

SQAコンポーネント

ソフトウェア品質保証（SQA）は、ソフトウェアエンジニアリングプロセスの品質を確保するための一連のアクティビティです。開発されたソフトウェアが、定義または標準化された品質仕様を満たし、準拠することを保証します。 SQAは、ソフトウェア開発ライフサイクル（SDLC）内で進行中のプロセスであり、開発したソフトウェアを定期的にチェックして、目的の品質基準を満たしていることを確認します。

SQAプラクティスは、使用されている基礎となるソフトウェア開発モデルに関係なく、ほとんどのタイプのソフトウェア開発に実装されています。 SQAは、ソフトウェアをテストするためのソフトウェアテスト方法論を組み込んで実装します。 SQAは、完了後に品質をチェックするのではなく、ソフトウェアが完了するまで、開発の各段階で品質テストを行います。 SQAを使用すると、ソフトウェア開発プロセスは、現在/前のフェーズが必要な品質基準に準拠した場合にのみ、次のフェーズに移行します。 SQAは通常、ソフトウェア品質のガイドラインと実装戦略の構築を支援する1つ以上の業界標準で機能します。

次のアクティビティが含まれています-

プロセスの定義と実装
監査
トレーニング

プロセスは-

ソフトウェア開発方法論
プロジェクト管理
構成管理
要件の開発/管理
推定
ソフトウェア設計
テストなど

プロセスが定義され、実装されると、品質保証には次の責任があります-

プロセスの弱点を特定する
これらの弱点を修正して、プロセスを継続的に改善する

SQAシステムのコンポーネント

SQAシステムは、常に広範囲のSQAコンポーネントを組み合わせます。これらのコンポーネントは、次の6つのクラスに分類することができます-

事前プロジェクトコンポーネント

これにより、プロジェクトのコミットメントが、必要なリソース、スケジュール、予算を考慮して明確に定義されていることが保証されます。開発および品質計画が正しく決定されました。

プロジェクトのライフサイクル活動評価のコンポーネント

プロジェクトのライフサイクルは、開発ライフサイクルと運用保守の2つの段階で構成されています。

開発ライフサイクル段階のコンポーネントは、設計およびプログラミングのエラーを検出します。そのコンポーネントは、レビュー、専門家の意見、ソフトウェアテストのサブクラスに分類されます。

運用保守フェーズで使用されるSQAコンポーネントには、特別なメンテナンスコンポーネントと開発ライフサイクルコンポーネントが含まれ、これらは主にメンテナンスタスクを改善する機能に適用されます。

インフラストラクチャエラーの防止と改善のコンポーネント

組織全体に適用されるこれらのコンポーネントの主な目的は、組織の累積SQAエクスペリエンスに基づいて、エラーの発生率を排除するか、少なくとも減らすことです。

ソフトウェア品質管理のコンポーネント

このクラスのコンポーネントは、開発およびメンテナンスアクティビティの制御、およびスケジュールと予算の失敗とその結果を主に防止または最小化する早期の管理サポートアクションの導入など、いくつかの目標を処理します。

標準化、認証、およびSQAシステム評価のコンポーネント

これらのコンポーネントは、組織内で国際的な専門的および管理上の標準を実装します。このクラスの主な目的は、国際的な専門知識の活用、組織の品質システムと他の組織との調整の改善、および共通の規模による品質システムの成果の評価です。さまざまな標準は、品質管理標準とプロジェクトプロセス標準という2つの主要なグループに分類できます。

SQAの組織化-人間の構成要素

SQAの組織基盤には、マネージャー、テスト担当者、SQAユニット、およびSQA受託者、SQA委員会メンバー、SQAフォーラムメンバーなどのソフトウェア品質に関心のある人が含まれます。彼らの主な目的は、SQAコンポーネントの実装を開始およびサポートし、SQAの手順と方法論からの逸脱を検出し、改善を提案することです。

プロジェクト前のソフトウェア品質コンポーネント

これらのコンポーネントは、プロジェクトを開始する前に実行される準備手順の改善に役立ちます。それが含まれています-

契約レビュー
開発および品質計画

契約レビュー

通常、ソフトウェアは、顧客と交渉した契約のために、またはハードウェア製品に組み込まれるファームウェアを開発するための内部注文のために開発されます。これらのすべての場合において、開発ユニットは合意された機能仕様、予算、およびスケジュールにコミットしています。したがって、契約のレビュー活動には、プロジェクト提案案と契約案の詳細な調査を含める必要があります。

具体的には、契約レビュー活動には以下が含まれます-

顧客の要件の明確化
プロジェクトのスケジュールとリソース要件の見積もりのレビュー
提案されたプロジェクトを実行する専門スタッフの能力の評価
顧客の義務を果たす能力の評価
開発リスクの評価

開発および品質計画

組織または同じ組織の内部部門とソフトウェア開発契約に署名した後、プロジェクトの開発計画と統合された品質保証活動が準備されます。これらの計画には、追加の詳細と、現在の提案および契約の基礎を提供した以前の計画に基づいた必要な修正が含まれます。

ほとんどの場合、入札の提出から契約の署名までに数か月かかります。これらの期間中、スタッフの空き状況、専門的な能力などのリソースが変更される場合があります。その後、計画は改訂され、暫定的に発生した変更が反映されます。

プロジェクト開発計画で扱われる主な問題は-

スケジュール
必要な人材とハードウェアリソース
リスク評価
組織の問題：チームメンバー、下請業者、パートナーシップ
プロジェクトの方法論、開発ツールなど
ソフトウェア再利用計画

プロジェクトの品質計画で扱われる主な問題は次のとおりです-

適切な測定可能な用語で表現された品質目標
各プロジェクトステージの開始と終了の基準
レビュー、テスト、およびその他のスケジュールされた検証および検証アクティビティのリスト

ソフトウェア品質メトリック

ソフトウェアメトリックスは、3つのカテゴリに分類することができます-

製品メトリック-サイズ、複雑さ、設計機能、パフォーマンス、品質レベルなどの製品の特性を説明します。
プロセスメトリック-これらの特性を使用して、ソフトウェアの開発およびメンテナンスアクティビティを改善できます。
プロジェクトメトリック-このメトリックは、プロジェクトの特性と実行について説明します。例には、ソフトウェア開発者の数、ソフトウェアのライフサイクル全体の人員配置パターン、コスト、スケジュール、および生産性が含まれます。

一部のメトリックは複数のカテゴリに属します。たとえば、プロジェクトのインプロセス品質メトリックは、プロセスメトリックとプロジェクトメトリックの両方です。

ソフトウェア品質指標*は、製品、プロセス、およびプロジェクトの品質面に焦点を当てたソフトウェア指標のサブセットです。これらは、プロジェクトメトリックよりもプロセスおよび製品のメトリックに密接に関連しています。

ソフトウェア品質メトリックは、さらに3つのカテゴリに分類できます-

製品品質指標
工程内品質指標
メンテナンス品質指標

製品品質指標

このメトリックには、次のものが含まれます-

故障までの平均時間
欠陥密度
顧客の問題
顧客満足

故障までの平均時間

失敗の間隔です。このメトリックは、主に航空会社の交通管制システム、航空電子工学、兵器などの安全性が重要なシステムで使用されます。

欠陥密度

コードの行や機能ポイントなどとして表されるソフトウェアのサイズに関連する欠陥を測定します。つまり、ユニットごとのコード品質を測定します。このメトリックは、多くの商用ソフトウェアシステムで使用されています。

顧客の問題

製品の使用時に顧客が遭遇する問題を測定します。これには、ソフトウェアの問題空間に対する顧客の視点が含まれています。これには、欠陥の問題とともに非欠陥指向の問題も含まれます。

問題の測定基準は、通常*ユーザー月ごとの問題（PUM）*で表されます。

PUM = Total Problems that customers reported (true defect and non-defect oriented
problems) for a time period + Total number of license months of the software during
the period

どこで、

Number of license-month of the software = Number of install license of the software ×
Number of months in the calculation period

PUMは通常、ソフトウェアが市場にリリースされた後の各月、および年ごとの月間平均に対して計算されます。

顧客満足

顧客満足度は、多くの場合、5ポイントスケールの顧客調査データによって測定されます-

非常に満足
満足
中性
不満
とても不満

製品の全体的な品質とその特定の寸法に対する満足度は、通常、顧客調査のさまざまな方法を通じて得られます。 5ポイントスケールのデータに基づいて、分析の目的に応じて、わずかに変動するいくつかのメトリックを構築して使用できます。たとえば-

完全に満足している顧客の割合
満足している顧客の割合
不満のある顧客の割合
不満足な顧客の割合

通常、このパーセント満足度が使用されます。

インプロセス品質メトリック

インプロセス品質メトリックは、一部の組織の正式なマシンテスト中に欠陥の到着を追跡します。このメトリックには以下が含まれます-

機械試験中の欠陥密度
機械試験中の欠陥到着パターン
位相ベースの欠陥除去パターン
欠陥除去の有効性

機械試験中の欠陥密度

フォーマルマシンテスト（コードがシステムライブラリに統合された後のテスト）中の欠陥率は、現場の欠陥率と相関しています。テスト中に発見されたより高い欠陥率は、ソフトウェアが開発プロセス中に高いエラー挿入を経験したことを示す指標です。ただし、テストの欠陥率が異常に高い場合は例外です。

ソフトウェアがまだテストされている間、KLOCまたは機能点ごとの欠陥のこの単純なメトリックは品質の良い指標です。同じ開発組織内の製品の後続リリースを監視することは特に役立ちます。

機械試験中の欠陥到着パターン

テスト中の全体的な欠陥密度は、欠陥の概要のみを提供します。欠陥到着のパターンは、フィールドのさまざまな品質レベルに関する詳細情報を提供します。以下が含まれます-

テストフェーズ中に時間間隔（週など）で報告された欠陥の到着または欠陥。ここではすべてが有効な欠陥ではありません。
報告された問題に対して問題判別が行われた場合の有効な欠陥到着のパターン。これが真の欠陥パターンです。
欠陥バックログ残業のパターン。開発組織は、報告されたすべての問題をすぐに調査および修正できないため、このメトリックが必要です。これは、ワークロードステートメントと品質ステートメントです。開発サイクルの終わりに欠陥のバックログが大きく、多くの修正がまだシステムに統合されていない場合、システムの安定性（その品質）が影響を受けます。目標とする製品品質レベルに確実に到達するには、再テスト（回帰テスト）が必要です。

位相ベースの欠陥除去パターン

これは、テスト中の欠陥密度メトリックの拡張です。テストに加えて、テスト前の設計レビュー、コード検査、正式な検証など、開発サイクルのすべての段階で欠陥を追跡します。

プログラミングの欠陥の大部分は設計の問題に関連しているため、フロントエンドでのプロセスの欠陥除去機能を強化するための正式なレビューまたは機能検証の実施により、ソフトウェアのエラーが減少します。フェーズベースの欠陥除去のパターンは、開発プロセスの全体的な欠陥除去能力を反映しています。

設計およびコーディング段階のメトリックに関して、多くの開発組織は、欠陥率に加えて、インプロセス品質管理のために検査カバレッジや検査労力などのメトリックを使用します。

欠陥除去の有効性

次のように定義できます-

DRE = \ frac \ {欠陥\：削除\：\：a \：開発\：フェーズ} \ {欠陥\：潜在\：in \：the \：product} \ times 100 \％

このメトリックは、開発プロセス全体、コード統合前のフロントエンド、および各フェーズについて計算できます。これは、特定のフェーズのフロントエンドおよび*フェーズの有効性*に使用される場合、*早期欠陥除去*と呼ばれます。メトリックの値が高いほど、開発プロセスの効率が上がり、次のフェーズまたはフィールドに渡される欠陥が少なくなります。このメトリックは、ソフトウェア開発の欠陥除去モデルの重要な概念です。

メンテナンス品質メトリック

この段階で製品の品質を変更することはほとんどできませんが、優れた修正品質でできるだけ早く欠陥を排除するために実行できる修正を次に示します。

バックログとバックログ管理インデックスを修正
応答時間を修正し、応答性を修正します
不良債権の割合
品質を修正

バックログとバックログ管理インデックスを修正

修正のバックログは、欠陥の到着率と、報告された問題の修正が利用可能になる率に関連しています。毎月または毎週の終わりに残る報告された問題の単純な数です。このメトリックは、トレンドチャートの形式で使用すると、メンテナンスプロセスを管理するための意味のある情報を提供できます。

バックログ管理インデックス（BMI）は、未解決および未解決の問題のバックログを管理するために使用されます。

BMI = \ frac \ {数\：of \：問題\：クローズ\：\：the \：monthの間に} \ {Number \：of \：問題\：到着\：\：the \：monthの間に} \ times 100 \％

BMIが100より大きい場合、バックログが削減されていることを意味します。 BMIが100未満の場合、バックログが増加しました。

応答時間を修正し、応答性を修正します

通常、修正応答時間メトリックは、オープンからクローズまでのすべての問題の平均時間として計算されます。修正応答時間が短いと、顧客満足度につながります。

修正対応の重要な要素は、顧客の期待、合意された修正時間、および顧客へのコミットメントを満たす能力です。

不良債権の割合

次のように計算されます-

$ Percent \：Delinquent \：Fixes = $

$ \ frac \ {数\：of \：修正\：that \：超過\：\：response \：time \：criteria \：by \：ceverity \：level} \ {Number \：of \：修正\ ：配信された\：\：a \：specified \：time} \ times 100 \％$

修正品質

修正フェーズまたは欠陥修正の数は、メンテナンスフェーズのもう1つの重要な品質指標です。報告された問題を修正しなかった場合、または元の問題を修正したが新しい欠陥を挿入した場合、修正は欠陥です。ミッションクリティカルなソフトウェアの場合、欠陥のある修正は顧客満足度に悪影響を及ぼします。不具合修正の割合のメトリックは、不具合のある時間間隔内のすべての修正の割合です。

欠陥のある修正は、2つの方法で記録できます。発見された月に記録するか、修正が配信された月に記録します。 1つ目は顧客測定です。 2番目はプロセス測定です。 2つの日付の違いは、欠陥修正の潜在期間です。

通常、遅延が長いほど、影響を受ける顧客は多くなります。欠陥の数が多い場合、パーセンテージメトリックの小さい値は楽観的な図を示します。もちろん、メンテナンスプロセスの品質目標は、延滞のない欠陥のない修正です。

測定の基礎

測定は、何かを測定するアクションです。これは、オブジェクトまたはイベントの特性への番号の割り当てであり、他のオブジェクトまたはイベントと比較できます。

正式に定義されるのは、明確に定義された規則に従ってそれらを記述する方法で、現実世界のエンティティの属性に番号または記号を割り当てるプロセスです。

日常生活での測定

測定は専門の技術者だけでなく、私たち全員が日常生活で使用するものです。ショップでは、価格はアイテムの価値の尺度として機能します。同様に、高さとサイズの測定により、布が適切にフィットするかどうかが確認されます。したがって、測定はアイテムを別のアイテムと比較するのに役立ちます。

測定では、エンティティの属性に関する情報を取得します。エンティティは、人などのオブジェクト、または実世界の旅などのイベントです。属性は、人の身長、旅の費用など、エンティティの機能またはプロパティです。現実の世界では、物事を測定することを考えているにもかかわらず、実際には物事の属性を測定しています。

属性は主に数字または記号で定義されます。たとえば、価格はルピーまたはドルの数で指定でき、服のサイズは小、中、大で指定できます。

測定の精度は、測定器と測定の定義に依存します。測定値を取得したら、それらを分析し、エンティティに関する結論を導き出す必要があります。

測定は直接的な定量化であり、計算は間接的なものであり、いくつかの式を使用して異なる測定値を組み合わせます。

ソフトウェア工学の測定

ソフトウェアエンジニアリングには、ソフトウェア製品の管理、原価計算、計画、モデリング、分析、指定、設計、実装、テスト、および保守が含まれます。したがって、測定はソフトウェアエンジニアリングで重要な役割を果たします。ソフトウェア製品の属性を測定するには、厳密なアプローチが必要です。

ほとんどの開発プロジェクトでは、

ソフトウェア製品に測定可能な目標を設定できない
ソフトウェアプロジェクトのコンポーネントコストを理解して定量化できない
生産する製品の品質を定量化または予測しません

したがって、ソフトウェア製品を制御するには、属性の測定が必要です。すべての測定アクションは、明確に定義され、簡単に理解できる特定の目標またはニーズによって動機付けられなければなりません。測定の目的は、管理者、開発者、およびユーザーが知る必要があることを試みて、具体的でなければなりません。プロジェクト、製品、プロセス、およびリソースのステータスを評価するには、測定が必要です。

ソフトウェア工学では、測定は次の3つの基本的な活動に不可欠です-

開発および保守中に何が起こっているかを理解する
プロジェクトで何が起こっているかを制御するには
プロセスと目標を改善するには

代表的な測定理論

測定は、あらゆる種類の測定に関する開発と推論の基礎となるルールを示しています。これは、経験的世界から正式な関係世界へのマッピングです。したがって、メジャーは、エンティティを特徴付けるためにこのマッピングによってエンティティに割り当てられた番号またはシンボルです。

経験的関係

現実の世界では、番号を割り当てるのではなく、比較することで物事を理解します。

たとえば、高さを比較するために、「より高い」、「より高い」という用語を使用します。したがって、これらの「より高い」、「より高い」は、身長の経験的関係です。

同じセットに複数の経験的関係を定義できます。

たとえば、XはYよりも高いです。 X、YはZよりもはるかに高いです。

経験的関係は、単項、二項、三項などです。

Xは背が高く、Yは背が高くなく、単項関係です。

Xは、Yがバイナリ関係であるよりも高くなっています。

現実世界の経験的関係は、正式な数学的世界にマッピングできます。ほとんどの場合、これらの関係は個人的な好みを反映しています。

これらの経験的関係を数学の世界にマッピングするために使用されるマッピングまたは評価手法のいくつかは次のとおりです-

リッカートスケール

ここで、ユーザーは同意するか同意しないかの声明を受け取ります。

例-このソフトウェアのパフォーマンスは良好です。

Strongly Agree	Agree	Neither agree Nor disagree	Disagree	Strongly Disgaree

強制ランキング

指定された選択肢を1（最良）からn（最悪）の順に並べます。

例：パフォーマンスに応じて、次の5つのソフトウェアモジュールをランク付けします。

Name of Module	Rank
Module A
Module B
Module C
Module D
Module E

言語周波数スケール

例-このプログラムはどのくらいの頻度で失敗しますか？

Always	Often	Sometimes	Seldom	Never

順序スケール

ここでは、ユーザーに選択肢のリストが表示され、ユーザーはいずれかを選択する必要があります。

例-このプログラムはどのくらいの頻度で失敗しますか？

毎時
毎日
毎週
毎月
年に数回
年に1〜2回
しない

比較スケール

ここで、ユーザーはさまざまなオプションを比較して数値を指定する必要があります。

非常に優れているほぼ同じ*非常に劣っている*

*12345678910*

数値スケール

ここでは、ユーザーはその重要度に応じて番号を指定する必要があります。

重要ではない

*12345678910*

マッピングのルール

マッピングを実行するには、ドメイン、範囲、およびマッピングを実行するルールを指定する必要があります。

例-ドメイン-実世界

範囲-整数、実数などの数学世界
ルール-高さを測定するため、靴を履くかどうか

同様に、ソフトウェア測定の場合、指定するコードの行に含めるステートメントのチェックリスト。

測定の表現条件

表現条件は、測定マッピング*（M）*がエンティティを数値にマッピングし、経験的関係が数値的関係を保持し、数値的関係によって保持されるように、経験的関係を数値的関係にマップする必要があることを表明します。

例：経験的関係「より高い」は、数値関係「>」にマッピングされます。つまり、M（X）> M（Y）の場合に限り、 XはYよりも高くなります。

特定のセットには多くの関係が存在する可能性があるため、表現条件はこれらの各関係にも影響を与えます。

単項関係が「背が高い」の場合、数値関係があるかもしれません

*X> 50*

表現条件では、任意のメジャー M に対して、

M（X）> 50の場合にのみXは背が高い*

正式な測定の主要な段階

測定の主要な段階は次のように要約することができます-

正式な測定の主要な段階

測定とモデル

モデルは、実世界のエンティティの数値要素の動作を解釈し、測定するのに役立ちます。測定プロセスを支援するには、マッピングのモデルにマッピングドメインのモデルを追加する必要があります。モデルは、これらのエンティティが属性にどのように関連し、特性がどのように関連するかも指定する必要があります。

測定には2つのタイプがあります-

直接測定
間接測定

直接測定

これらは、他のエンティティまたは属性の関与なしに測定できる測定値です。

以下の直接的な対策は、ソフトウェアエンジニアリングで一般的に使用されています。

LOCによるソースコードの長さ
経過時間によるテスト目的の期間
欠陥をカウントすることにより、テストプロセス中に発見された欠陥の数
プログラマーがプログラムに費やす時間

間接測定

これらは、他のエンティティまたは属性の観点から測定できる測定値です。

ソフトウェアエンジニアリングでは、一般的に次の間接的な手段が使用されます。

\ small Programmer \：生産性= \ frac \ {LOC \：生産済み} \ {人\：months \：of \：effort}

$ \ small Module \：Defect \：Density = \ frac \ {Number \：of \：defects} \ {Module \：size} $

\ small Defect \：Detection \：Efficiency = \ frac \ {Number \：of \：defects \：detected} \ {Total \：number \：of \：defects}

$ \ small Requirement \：Stability = \ frac \ {Number \：of \：initial \：requirements} \ {Total \：number \：of \：requirements} $

$ \ small Test \：Effectiveness \：Ratio = \ frac \ {Number \：of \：items \：covered} \ {Total \：number \：of \：items} $

$ \ small System \：spoilage = \ frac \ {Effort \：spent \：for \：fixing \：faults} \ {Total \：project \：effort} $

予測のための測定

適切なリソースをプロジェクトに割り当てるには、プロジェクトを開発するための労力、時間、コストを予測する必要があります。予測の測定には、予測される属性を現在測定可能な他の属性に関連付ける数学モデルが常に必要です。したがって、予測システムは、未知のパラメーターを決定し、結果を解釈するための予測手順のセットと数学モデルで構成されます。

測定スケール

測定スケールは、経験的関係システムを表すために使用されるマッピングです。それは主に5種類です-

公称スケール
順序スケール
インターバルスケール
比率スケール
絶対スケール

公称スケール

要素を分類スキームに配置します。クラスは順序付けされません。各エンティティは、属性の値に基づいて特定のクラスまたはカテゴリに配置する必要があります。

それには2つの主要な特徴があります-

経験的関係システムは、異なるクラスのみで構成されています。クラス間に順序付けの概念はありません。
クラスの明確な番号付けまたは記号表現は受け入れられる尺度ですが、数字または記号に関連する大きさの概念はありません。

順序スケール

要素を順序付けられた分類スキームに配置します。それは次の特性を持っています-

経験的関係システムは、属性に関して順序付けられたクラスで構成されます。
順序を保持するマッピングはすべて受け入れられます。
数字はランキングのみを表します。したがって、加算、減算、およびその他の算術演算には意味がありません。

インターバルスケール

このスケールは、分類を分離する間隔のサイズに関する情報を収集します。したがって、公称スケールおよび順序スケールよりも強力です。

それは次の特性を持っています-

順序スケールのような順序を保持します。
差異は保持されますが、比率は保持されません。
加算と減算はこのスケールで実行できますが、乗算または除算はできません。

属性が間隔スケールで測定可能であり、 M および* M ’が表現条件を満たすマッピングである場合、常に2つの数値 *a および b を見つけることができます。

M = aM ’+ b

比率スケール

これは、最も有用な測定尺度です。ここでは、比率をキャプチャするための経験的な関係が存在します。それは次の特性を持っています-

これは、順序、エンティティ間の間隔のサイズ、およびエンティティ間の比率を保持する測定マッピングです。
属性がまったくないことを表すゼロ要素があります。
測定マッピングはゼロから始まり、単位として知られる等間隔で増加する必要があります。
すべての算術演算を適用できます。

ここで、マッピングは次の形式になります

M = aM ’*

ここで、「a」は正のスカラーです。

絶対スケール

このスケールでは、属性に対して考えられるメジャーは1つだけです。したがって、可能な変換はID変換のみです。

それは次の特性を持っています-

測定は、エンティティセット内の要素の数をカウントすることによって行われます。
属性は常に「エンティティ内のxの出現回数」という形式を取ります。
可能な測定マッピングは、実際のカウントのみです。
結果のカウントに対してすべての算術演算を実行できます。

実証調査

経験的調査には、あらゆるツール、手法、または方法の科学的調査が含まれます。この調査には、主に次の4つの原則が含まれています。

調査手法の選択
仮説を述べる
変数の制御を維持する
調査を意味のあるものにする

調査手法の選択

ソフトウェア工学における経験的調査の主要なコンポーネントは-

調査
ケーススタディ
正式な実験

調査

調査は、関係と結果を文書化する状況の遡及的研究です。イベントが発生した後、常に行われます。たとえば、ソフトウェアエンジニアリングでは、ユーザーが特定の方法、ツール、または技術にどのように反応して傾向や関係を判断するかを判断するために、ポーリングを実行できます。

この場合、当面の状況を制御することはできません。状況を記録し、同様の状況と比較できます。

ケーススタディ

これは、アクティビティの結果に影響を与える可能性のある重要な要因を特定し、アクティビティを文書化する調査手法です。つまり、入力、制約、リソース、出力です。

正式な実験

これは、活動の厳密に制御された調査であり、重要な要因が特定され、結果に対する影響を文書化するために操作されます。

調査

特定の調査方法は、次のガイドラインに従って選択することができます-

アクティビティが既に発生している場合は、調査またはケーススタディを実行できます。まだ発生していない場合は、ケーススタディまたは正式な実験を選択できます。
結果に影響を与える可能性のある変数を高度に制御できる場合は、実験を使用できます。変数を制御できない場合は、ケーススタディが推奨される手法になります。
より高いレベルで複製できない場合、実験はできません。
複製のコストが低い場合、実験を検討できます。

仮説を述べる

特定の調査手法の決定を後押しするには、調査の目標を、テストする仮説として表現する必要があります。仮説は、プログラマーが探求したい動作を説明すると考えている暫定的な理論または仮定です。

変数の制御を維持する

仮説を述べた後、次に、その真実に影響を与えるさまざまな変数と、それに対する制御の程度を決定する必要があります。実験とケーススタディの間の重要な識別要素は、動作に影響する変数の制御の程度であるため、これは不可欠です。

プロジェクトを特徴付けることができ、評価結果に影響を与えることもできる要因である状態変数を使用して、正式な実験の制御状況と実験状況を区別します。コントロールと実験を区別できない場合は、ケーススタディ手法が優先されます。

たとえば、プログラミング言語の変更がプロジェクトの生産性に影響を与えるかどうかを判断する場合、言語は状態変数になります。現在、Adaに置き換えたいFORTRANを使用しているとします。 FORTRANが制御言語になり、Adaが実験言語になります。

調査を意味のあるものにする

実験の結果は通常、ケーススタディや調査よりも一般化できます。ケーススタディまたは調査の結果は、通常、特定の組織にのみ適用できます。以下のポイントは、さまざまな質問に答えるこれらの手法の効率性を証明しています。

適合理論と従来の知恵

ケーススタディまたは調査を使用して、単一組織内の従来の知識と他の多くの標準、方法、またはツールの有効性と有用性を適合させることができます。ただし、正式な実験では、クレームが一般的に正しい状況を調査できます。

関係を探る

リソースとソフトウェア製品のさまざまな属性間の関係は、ケーススタディまたは調査で示唆できます。

たとえば、完了したプロジェクトの調査では、特定の言語で書かれたソフトウェアが他の言語で書かれたソフトウェアよりも障害が少ないことが明らかになります。

これらの関係を理解して検証することは、将来のプロジェクトを成功させるために不可欠です。これらの関係はそれぞれ仮説として表現でき、関係がどの程度保持されているかをテストするための正式な実験を設計できます。通常、1つの特定の属性の値は、他の属性を一定に保つか、制御することによって観察されます。

モデルの精度を評価する

モデルは通常、アクティビティの結果を予測したり、メソッドまたはツールの使用をガイドするために使用されます。実験やケーススタディを設計する際には、予測が結果に影響することが多いため、特に難しい問題を提示します。プロジェクトマネージャーは、多くの場合、予測を完了の目標に変えます。この効果は、コストモデルとスケジュールモデルを使用する場合によく見られます。

信頼性モデルなどの一部のモデルは、ソフトウェアが現場で使用できるようになるまで平均故障時間として測定される信頼性を評価できないため、結果に影響しません。

対策の検証

属性の値を取得するための多くのソフトウェア測定があります。したがって、特定の測定値がキャプチャする属性の変化を反映しているかどうかをテストするために、調査を実施する必要があります。検証は、あるメジャーを別のメジャーと相関させることにより実行されます。影響因子の直接かつ有効な尺度でもある2番目の尺度を使用して検証する必要があります。そのような測定は、常に利用可能であるとは限らないか、測定が簡単ではありません。また、使用される測定値は、測定される要因の人間の概念に準拠する必要があります。

ソフトウェア測定

ソフトウェア測定のフレームワークは、3つの原則に基づいています-

調査するエンティティの分類
関連する測定目標の決定
組織が到達した成熟度のレベルを特定する

検査するエンティティの分類

ソフトウェアエンジニアリングでは、主に3つのクラスのエンティティが存在します。彼らは-

プロセス
製品情報
リソース

これらのエンティティにはすべて、内部エンティティと外部エンティティがあります。

*内部属性*は、プロセス、製品、またはリソース自体に関して純粋に測定できる属性です。例：サイズ、複雑さ、モジュール間の依存関係。
*外部属性*は、環境との関係に関してのみ測定できる属性です。例：ユーザーが経験した障害の総数、データベースの検索と情報の取得にかかる時間。

各エンティティについて測定できるさまざまな属性は次のとおりです-

プロセス

プロセスは、ソフトウェア関連のアクティビティの集まりです。以下は、プロセスのために直接測定できる内部属性の一部です-

プロセスの期間またはそのアクティビティの1つ
プロセスまたはそのアクティビティの1つに関連する努力
プロセスまたはそのアクティビティのいずれかで発生した特定の種類のインシデントの数

プロセスのさまざまな外部属性は、コスト、制御性、有効性、品質、および安定性です。

製品情報

製品は、経営陣が提供することを約束しているアイテムであるだけでなく、ソフトウェアライフサイクル中に作成されたアーティファクトまたはドキュメントでもあります。

さまざまな内部製品属性は、サイズ、労力、コスト、仕様、長さ、機能性、モジュール性、再利用、冗長性、および構文の正確さです。これらのサイズの中でも、努力とコストは他のものよりも比較的簡単に測定できます。

さまざまな外部製品の属性は、使いやすさ、整合性、効率性、テスト容易性、再利用性、移植性、相互運用性です。これらの属性は、コードだけでなく、開発作業をサポートする他のドキュメントも記述します。

リソース

これらは、プロセスアクティビティに必要なエンティティです。ソフトウェア生産のための任意の入力にすることができます。これには、人員、材料、ツール、および方法が含まれます。

リソースのさまざまな内部属性は、年齢、価格、サイズ、速度、メモリサイズ、温度などです。さまざまな外部属性は、生産性、経験、品質、使いやすさ、信頼性、快適性などです。

成熟度の特定

プロセスの成熟度は、目に見えるもののみを測定することを示唆しています。したがって、プロセスの成熟度とGQMの組み合わせは、最も有用な手段を提供します。

*レベル1 *では、プロジェクトの要件が不明確になる可能性があります。このレベルでは、要求特性の測定は困難です。
*レベル2 *では、要件は明確に定義されており、各要件のタイプや各タイプへの変更数などの追加情報を収集できます。
*レベル3 *では、各アクティビティの開始基準と終了基準で中間アクティビティが定義されます

目標と質問の分析は同じですが、メトリックは成熟度によって異なります。プロセスが成熟すればするほど、測定値は豊かになります。 GQMパラダイムは、プロセスの成熟に合わせて、管理者が測定プログラムを設計するのを支援するいくつかのツールの基盤として使用されています。

GQMは、属性を測定する必要性を理解するのに役立ち、プロセスの成熟度は、意味のある方法で測定できるかどうかを示唆します。一緒になって、測定のコンテキストを提供します。

ソフトウェア測定検証

ソフトウェアシステムの測定の検証には2つのステップが含まれます-

測定システムの検証
予測システムの検証

測定システムの検証

測定または測定システムは、1つ以上の属性を数値的に特徴付けることにより、既存のエンティティを評価するために使用されます。メジャーは、メジャーと主張する属性を正確に特徴付けている場合に有効です。

ソフトウェア測定システムの検証とは、表現条件が満たされていることを示すことにより、測定値がクレームされた属性の適切な数値的特性であることを確認するプロセスです。

測定システムを検証するには、エンティティを記述する正式なモデルと、測定する属性を保持する数値マッピングの両方が必要です。たとえば、2つのプログラムP1とP2があり、それらのプログラムを連結する場合、長さの測定値 m がそれを満たすことが期待されます。

m（P1 + P2）= m（P1）+ m（P2）

プログラム P1 の長さがプログラム P2 の長さよりも長い場合、メジャー m も満たす必要があります。

m（P1）> m（P2）

プログラムの長さは、コードの行を数えることで測定できます。このカウントが上記の関係を満たしている場合、コード行は長さの有効な尺度であると言えます。

メジャーを検証するための正式な要件には、測定理論の意味で、指定された属性を特徴付けることの実証が含まれます。検証を使用して、測定者が適切に定義され、エンティティの実世界の行動と一貫していることを確認できます。

予測システムの検証

予測システムは、関連する予測手順を伴う数学モデルを含む将来のエンティティの属性を予測するために使用されます。

与えられた環境で予測システムを検証することは、経験的手段によって予測システムの精度を確立するプロセスです。特定の環境でモデルのパフォーマンスを既知のデータと比較することにより。それには、実験と仮説のテストが含まれます。

検証に受け入れられる精度の程度は、予測システムが決定論的であるか確率論的であるか、および評価を行う人によって決まります。一部の確率的予測システムは、他の確率的予測システムよりも確率的です。

確率的予測システムの例は、ソフトウェアコストの見積もり、労力の見積もり、スケジュールの見積もりなどのシステムです。したがって、予測システムを正式に検証するには、それがどの程度確率的であるかを決定し、予測システムのパフォーマンスを既知のデータと比較する必要があります。

ソフトウェア測定メトリック

ソフトウェアメトリックは、ある程度の測定を伴う多くのアクティビティを含む測定の標準です。製品メトリック、プロセスメトリック、プロジェクトメトリックの3つのカテゴリに分類できます。

*製品メトリック*は、サイズ、複雑さ、設計機能、パフォーマンス、品質レベルなどの製品の特性を説明します。
*プロセスのメトリクス*を使用して、ソフトウェアの開発とメンテナンスを改善できます。例には、開発中の欠陥除去の有効性、欠陥到着テストのパターン、および修正プロセスの応答時間が含まれます。
*プロジェクトメトリック*は、プロジェクトの特性と実行を説明します。例には、ソフトウェア開発者の数、ソフトウェアのライフサイクル全体の人員配置パターン、コスト、スケジュール、および生産性が含まれます。

一部のメトリックは複数のカテゴリに属します。たとえば、プロジェクトのインプロセス品質メトリックは、プロセスメトリックとプロジェクトメトリックの両方です。

ソフトウェアメトリックの範囲

ソフトウェアメトリックには、次のような多くのアクティビティが含まれます-

コストと労力の見積もり
生産性の尺度とモデル
データ収集
数量モデルとメジャー
信頼性モデル
性能および評価モデル
構造と複雑さのメトリック
機能-成熟度評価
指標による管理
方法とツールの評価

ソフトウェア測定は、特定の段階でのソフトウェアプロジェクトコストを予測するモデルからプログラム構造の測定に至るまで、これらのアクティビティの多様なコレクションです。

コストと工数の見積もり

努力は、プログラムのサイズ、開発者の能力、再利用のレベルなど、1つまたは複数の変数の関数として表されます。ソフトウェアライフサイクルの初期段階でプロジェクトコストを予測するために、コストと労力の推定モデルが提案されています。提案されているさまざまなモデルは-

ベームのココモモデル
パトナムのスリムモデル
アルブレヒトの機能点モデル

生産性モデルと指標

生産性は、価値とコストの関数として考えることができます。それぞれを異なる測定可能なサイズ、機能、時間、お金などに分解できます。生産性モデルのさまざまな可能なコンポーネントは、次の図で表現できます。

生産性モデル

データ収集

測定プログラムの品質は、慎重なデータ収集に明らかに依存しています。収集されたデータは、管理者が開発の進行状況と問題を理解できるように、単純なチャートとグラフに変換できます。データ収集は、関係と傾向の科学的調査にも不可欠です。

品質モデルと尺度

品質モデルは、製品の品質を測定するために開発されたもので、生産性は意味がありません。これらの品質モデルを生産性モデルと組み合わせて、正しい生産性を測定できます。これらのモデルは通常、ツリーのように構築されます。上部のブランチには、信頼性や使いやすさなどの重要な高品質の要素が含まれています。

分割統治アプローチの概念は、ソフトウェア品質を測定するための標準的なアプローチとして実装されています。

信頼性モデル

ほとんどの品質モデルは、信頼性を構成要素として含んでいますが、信頼性を予測および測定する必要があるため、信頼性のモデリングおよび予測の専門化が別途必要になりました。信頼性理論の基本的な問題は、システムがいつ故障するかを予測することです。

性能評価とモデル

これには、応答時間や完了率などの外部で観察可能なシステムパフォーマンス特性、およびアルゴリズムの効率などのシステムの内部動作が含まれます。それは品質の別の側面です。

構造と複雑さのメトリック

ここでは、ソフトウェアの表現の構造属性を測定します。これは、実行前に利用可能です。次に、品質保証、品質管理、品質予測をサポートするために、経験的に予測理論を確立しようとします。

能力成熟度評価

このモデルは、ツールの使用、標準的なプラクティスなど、開発のさまざまな属性を評価できます。それは、すべての優れた請負業者が使用すべき主要な慣行に基づいています。

メトリックスによる管理

ソフトウェアプロジェクトを管理するには、測定が重要な役割を果たします。プロジェクトが順調に進んでいるかどうかを確認するために、ユーザーと開発者は測定ベースのチャートとグラフを利用できます。顧客が通常ソフトウェア用語に精通していない製品にソフトウェアが組み込まれている場合、測定とレポート方法の標準セットは特に重要です。

方法とツールの評価

これは、実験計画、結果に影響を与える可能性のある要因の適切な特定、および要因属性の適切な測定に依存します。

データ操作

ソフトウェアメトリックは、ある程度の測定を含む多くのアクティビティを含む測定の標準です。ソフトウェア測定の成功は、収集および分析されるデータの品質にあります。

良いデータとは？

収集されたデータは、次の質問に対する答えを生成できる場合、良いデータとみなすことができます-

それらは正しいですか？-データは、メトリックの定義の正確なルールに従って収集された場合、正しいと見なすことができます。
それらは正確ですか？-精度とは、データと実際の値の差を指します。
それらは適切に正確ですか？-精度は、データの表現に必要な小数点以下の桁数を扱います。
一貫性はありますか？-測定デバイスごとに大きな違いがない場合、データは一貫していると見なすことができます。
特定のアクティビティまたは期間に関連付けられていますか？-データが特定のアクティビティまたは期間に関連付けられている場合、データで明確に指定する必要があります。
それらを複製できますか？-通常、調査、ケーススタディ、実験などの調査は、さまざまな状況下で頻繁に繰り返されます。したがって、データも簡単に複製できる必要があります。

データを定義する方法は？

測定目的のために収集されるデータは2種類あります-

生データ-生データは、プロセス、製品、またはリソースの初期測定の結果です。例：組織内の従業員の週単位のタイムシート。
洗練されたデータ-洗練されたデータは、属性の値を導出するために生データから重要なデータ要素を抽出した結果です。

データは、次の点に従って定義することができます-

ロケーション
タイミング
症状
最終結果
機構
原因
重大度
Cost

データを収集する方法は？

データの収集には、人間の観察と報告が必要です。マネージャー、システムアナリスト、プログラマー、テスター、およびユーザーは、フォームに行データを記録する必要があります。正確かつ完全なデータを収集するには、それが重要です-

手順をシンプルに保つ
不要な録音を避ける
データを記録する必要性と使用する手順について従業員を訓練する
データのキャプチャと分析の結果を元のプロバイダーに迅速に提供し、業務を支援する有用な形式で提供する
中央の収集ポイントで収集されたすべてのデータを検証します

データ収集の計画には、いくつかのステップが含まれます-

GQM分析に基づいて測定する製品を決定する
製品が構成管理下にあることを確認してください
どの属性を測定し、どのように間接的な測定値を導き出すかを正確に決定する
メトリックのセットが明確になり、測定するコンポーネントのセットが特定されたら、測定プロセスに関与する各アクティビティを特定するためのスキームを考案します
フォームの処理、データの分析、結果の報告の手順を確立します

データ収集計画は、プロジェクト計画の開始時に開始する必要があります。実際のデータ収集は、開発の多くの段階で行われます。

例-プロジェクト要員に関連する一部のデータは、プロジェクトの開始時に収集できますが、努力などの他のデータ収集は、プロジェクトの開始時に開始され、運用および保守を通じて継続されます。

データを保存および抽出する方法

ソフトウェアエンジニアリングでは、データをデータベースに保存し、データベース管理システム（DBMS）を使用してセットアップする必要があります。データベース構造の例を次の図に示します。このデータベースには、組織のさまざまな部門で働いているさまざまな従業員の詳細が格納されます。

データベース管理システム

上記の図では、各ボックスはデータベース内のテーブルであり、矢印はあるテーブルから別のテーブルへの多対1マッピングを示しています。マッピングは、データの論理的な一貫性を保持する制約を定義します。

データベースが設計され、データが入力されると、データ操作言語を使用して分析用のデータを抽出できます。

ソフトウェア測定データの分析

関連データを収集した後、適切な方法で分析する必要があります。分析手法を選択する際に考慮すべき3つの主要な項目があります。

データの性質
実験の目的
設計上の考慮事項

データの性質

データを分析するには、データによって表されるより大きな母集団とそのデータの分布も調べる必要があります。

サンプリング、母集団、およびデータ分布

サンプリングは、大規模な母集団からデータのセットを選択するプロセスです。サンプル統計は、実験被験者のグループから得られた測定値を説明し、要約します。

母集団パラメーターは、可能なすべての被験者を測定した場合に得られる値を表します。

母集団または標本は、平均、中央値、最頻値などの中心傾向の尺度と、分散や標準偏差などの分散の尺度で説明できます。次のグラフに示すように、多くのデータセットが正規分布しています。

人口

上に示したように、データは平均について均等に分散されます。これは正規分布の重要な特性です。

データが歪んでいる他の分布も存在するため、平均の片側に他より多くのデータポイントがあります。たとえば、データのほとんどが平均の左側にある場合、分布は左に傾いていると言えます。

実験の目的

通常、実験が行われます-

理論を確認するには
関係を探索するには

これらのそれぞれを達成するために、目的は仮説に関して形式的に表現されるべきであり、分析は仮説に直接対処しなければなりません。

理論を確認するには

調査は、理論の真実を探求するように設計されなければなりません。理論は通常、特定の方法、ツール、またはテクニックの使用が被験者に特定の影響を与え、他の方法よりも何らかの形でそれを改善すると述べています。

考慮すべきデータには、*通常のデータ*と*非通常のデータ*の2つのケースがあります。

データが正規分布からのもので、比較するグループが2つある場合、スチューデントのt検定を分析に使用できます。比較するグループが3つ以上ある場合は、F統計と呼ばれる分散分析の一般的な分析を使用できます。

データが非正規である場合、データをランク付けすることによりクラスカル・ワリス検定を使用して分析できます。

関係を探索するには

調査は、1つの変数または複数の変数を記述するデータポイント間の関係を決定するように設計されています。

関係に関する質問に答えるには、箱ひげ図、散布図、相関分析の3つの手法があります。

*箱ひげ図*は、一連のデータの範囲の概要を表すことができます。
*散布図*は、2つの変数間の関係を表します。
*相関分析*では、統計的手法を使用して、2つの属性間に真の関係があるかどうかを確認します。
正規分布値の場合、 Pearson Correlation Coefficient を使用して、2つの変数が高度に相関しているかどうかを確認します。
非正規データの場合、データをランク付けし、スピアマンランク相関係数*を関連性の尺度として使用します。非正規データの別の尺度は Kendallのロバストな相関係数*で、データポイントのペア間の関係を調査し、偏相関を特定できます。

ランキングに多数のタイ値が含まれている場合、分割表の*カイ2乗検定*を使用して、変数間の関連性をテストできます。同様に、*線形回帰*を使用して、変数間の関係を記述する方程式を生成できます。

3つ以上の変数の場合、*多変量回帰*を使用できます。

設計上の考慮事項

分析手法を選択する際には、調査の設計を考慮する必要があります。同時に、分析の複雑さが選択した設計に影響を与える可能性があります。複数のグループは、2つのグループでの学生のT検定ではなくF統計を使用します。

3つ以上の要因を持つ複雑な要因計画では、関連性と有意性のより洗練されたテストが必要です。

統計的手法を使用して、ある変数セットが他の変数セットに与える影響を説明したり、タイミングや学習効果を補正したりできます。

内部製品の属性

内部製品属性は、製品自体にのみ依存する方法でソフトウェア製品を記述します。内部製品属性を測定する主な理由は、開発中に製品を監視および制御するのに役立つからです。

内部製品属性の測定

主な内部製品属性には、*サイズ*および*構造*が含まれます。サイズは、実行することなく静的に測定できます。製品のサイズは、それを作成するために必要な労力について教えてくれます。同様に、製品の構造は、製品のメンテナンスを設計する上で重要な役割を果たします。

サイズを測定する

ソフトウェアのサイズは、3つの属性で説明することができます-

長さ-製品の物理的なサイズです。
機能-製品によってユーザーに提供される機能を説明します。
複雑さ-複雑さは次のような異なるタイプのものです。
問題の複雑さ-根本的な問題の複雑さを測定します。
アルゴリズムの複雑さ-問題を解決するために実装されたアルゴリズムの複雑さを測定します
構造の複雑さ-アルゴリズムを実装するために使用されるソフトウェアの構造を測定します。
認知の複雑さ-ソフトウェアを理解するために必要な労力を測定します。

これらの3つの属性の測定は、次のように説明することができます-

長さ

サイズ測定が予測に必要な労力の予測に役立つ3つの開発製品があります。それらは仕様、設計、コードです。

仕様と設計

これらのドキュメントは通常、テキスト、グラフ、および特別な数学的図と記号を組み合わせています。仕様測定は、設計の長さを予測するために使用できます。これは、コード長の予測子です。

ドキュメント内の図には、ラベル付きダイグラフ、データフロー図、Zスキーマなどの統一された構文があります。仕様および設計ドキュメントはテキストと図で構成されているため、その長さは、テキストの長さと図の長さを表す数値のペアで測定できます。

これらの測定では、さまざまなタイプのダイアグラムおよびシンボルに対してアトミックオブジェクトを定義します。

データフロー図のアトミックオブジェクトは、プロセス、外部エンティティ、データストア、およびデータフローです。代数的仕様のアトミックエンティティは、ソート、関数、操作、および公理です。 Zスキーマのアトミックエンティティは、仕様に表示されるさまざまな行です。

Code

コードは、手続き型言語、オブジェクト指向、ビジュアルプログラミングなど、さまざまな方法で生成できます。ソースコードプログラムの長さの最も一般的に使用される従来の測定は、コード行（LOC）です。

全長、

*LOC = NCLOC + CLOC*

すなわち

*LOC =コメントなしのLOC +コメント付きのLOC*

コードの行とは別に、Maurice Halstedによって提案されたサイズや複雑さなどの他の代替手段も長さの測定に使用できます。

Halsteadのソフトウェアサイエンスは、プログラムのさまざまな属性をキャプチャしようとしました。彼は、長さ、語彙、ボリュームなど、サイズのさまざまな見方を反映する3つの内部プログラム属性を提案しました。

彼は、プログラム P を、演算子またはオペランドで分類されたトークンのコレクションとして定義することから始めました。これらのトークンの基本的な指標は、

μ〜1〜 =一意の演算子の数
μ〜2〜 =一意のオペランドの数
* N〜1〜* =オペレーターの合計オカレンス
* N〜2〜* =一意の演算子の数

長さ P は次のように定義できます。

N = N _ \ {1} + N _ \ {2}

*P* の語彙は

\ mu = \ mu _ \ {1} + \ mu _ \ {2}

プログラムのボリューム=いいえ。長さ N のプログラムを書くために必要な精神的比較の

V = N \ times \ {log _ \ {2}} \ mu

ボリューム V のプログラム P のプログラムレベルは、

L = \ frac \ {V ^ \ ast} \ {V}

ここで、$ V ^ \ ast $は潜在的なボリューム、つまり P の最小サイズ実装のボリュームです。

レベルの逆は難易度です-

D = 1 \ diagup L

Halstead理論によれば、推定値 L は次のように計算できます。

$$ \ {L} '= 1 \ diagup D = \ frac \ {2} \ {\ mu _ \ {1}} \ times \ frac \ {\ mu _ \ {2}} \ {N _ \ {2}} $ $

同様に、推定プログラム長は、$ \ mu _ \ {1} \ times log _ \ {2} \ mu _ \ {1} + \ mu _ \ {2} \ times log _ \ {2} \ mu _ \ {2} $です。

Pを生成するのに必要な努力は、

E = V \ diagup L = \ frac \ {\ mu _ \ {1} N _ \ {2} Nlog _ \ {2} \ mu} \ {2 \ mu _ \ {2}}

測定単位 E は、 P を理解するために必要な基本的な精神的差別です。

長さを測定するための他の選択肢は-

プログラムテキストに必要なコンピューターストレージのバイト数に関して
プログラムテキストの文字数に関して

オブジェクト指向開発では、長さを測定する新しい方法が提案されています。プリーガー等。オブジェクトとメソッドの数がコード行を使用するものよりも正確な生産性の見積もりにつながることがわかりました。

機能性

製品に固有の機能の量により、製品のサイズが測定されます。ソフトウェア製品の機能を測定するには、非常に多くの異なる方法があります。次の章では、そのような方法の1つであるアルブレヒトの関数点法について説明します。

アルブレヒトの関数点法

ファンクションポイントメトリックは、ソフトウェアアプリケーションのさまざまな機能を測定するための標準化された方法を提供します。これは、ユーザーの観点から機能を測定します。つまり、ユーザーがリクエストして受け取ったものに基づいて機能を測定します。ファンクションポイント分析は、ユーザーの観点からソフトウェア開発を測定するための標準的な方法です。

当初Albrechtによって考案されたFunction Pointメジャーは、1986年にInternational Function Point Users Group（IFPUG）が発足して人気が高まりました。 2002年、IFPUG機能ポイントは、ISO/IEC 20926の国際ISO標準になりました。

ファンクションポイントとは何ですか？

FP（ファンクションポイント）*は、ソフトウェアアプリケーションの定量化に適した最も一般的な機能タイプメトリックです。これは、2つのデータ関数タイプと3つのトランザクション関数タイプに分けられる、5人のユーザーが識別可能な論理的な「関数」に基づいています。特定のソフトウェアアプリケーションについて、これらの各要素は定量化および重み付けされ、ファイル参照や論理フィールドなどの特徴的な要素がカウントされます。

結果の数値（未調整FP）は、追加、変更、または削除された関数セットにグループ化され、値調整係数（VAF）と組み合わされて、FPの最終的な数が取得されます。カウントタイプごとに、アプリケーション、開発プロジェクト、または拡張プロジェクトの個別の最終式が使用されます。

アルブレヒトの関数点法の適用

アルブレヒトの関数点法を適用する方法を理解しましょう。その手順は次のとおりです-

コンポーネント（EI、EO、EQ、ILF、およびELF）の数を決定する

EI -外部入力の数。これらは、派生データが外部から内部に境界を通過する基本プロセスです。ライブラリデータベースシステムの例では、既存の利用者のライブラリカード番号を入力します。
EO -外部出力の数。これらは、派生データが境界を内側から外側へ通過する基本プロセスです。ライブラリデータベースシステムの例では、利用者にチェックアウトされた書籍のリストを表示します。
EQ -外部クエリの数。これらは、1つ以上の内部論理ファイルと外部インターフェイスファイルからデータを取得する入力コンポーネントと出力コンポーネントの両方を備えた基本プロセスです。ライブラリデータベースシステムの例では、現在どの本が利用者にチェックアウトされているかを判断します。
ILF -内部ログファイルの数。これらは、外部入力によって維持されるアプリケーション境界内に完全に存在する、論理的に関連するデータのユーザー識別可能なグループです。ライブラリデータベースシステムの例では、ライブラリ内の書籍のファイル。
ELF -外部ログファイルの数。これらは、参照目的でのみ使用され、完全にシステムの外部に存在する、論理的に関連するデータのユーザー識別可能なグループです。ライブラリデータベースシステムの例で、ライブラリの請求システムのトランザクションを含むファイル。

未調整の関数ポイントカウント（UFC）を計算する

各コンポーネントを* low、average、または *high として評価します。
トランザクション*（EI、EO、およびEQ）の場合、評価は *FTR および DET に基づきます。
FTR -更新または参照されたファイルの数。
DET -ユーザーが認識可能なフィールドの数。
次の表に基づいて、2つのファイルと10個のデータ要素を参照する EI は、*平均*としてランク付けされます。

FTRs

DETs

*1-5*

*6-15*

> 15 *

*0-1*

Low

平均

*2-3*

Low

平均

High

>3

平均

High

ファイル*（ILFおよびELF）の場合、評価は *RET および DET に基づきます。
RET - ILF または ELF 内のユーザーが認識可能なデータ要素の数。
DET -ユーザーが認識可能なフィールドの数。
次の表に基づいて、10個のデータ要素と5個のフィールドを含む ILF は、 high としてランク付けされます。

RETs

DETs

*1-5*

*6-15*

> 15 *

1

Low

平均

*2-5*

Low

平均

High

>5

平均

High

評価を UFC に変換します。

評価

値

EO

EQ

EI

*ILF*

エルフ

低

4

3

7

5

平均

5

4

10

7

高い

6

5

6

15

10

最終関数ポイントカウント（FPC）を計算する

14の一般的なシステム特性*（GSC）に基づいて、値調整係数（VAF）*を計算します。

一般的なシステム特性

簡単な説明

GSC 1

データ通信

アプリケーションまたはシステムとの情報の転送または交換を支援するために、いくつの通信施設がありますか？

GSC 2

分散データ処理

分散データと処理機能はどのように処理されますか？

GSC 3

パフォーマンス

ユーザーは応答時間またはスループットを必要としましたか？

GSC 4

頻繁に使用される構成

アプリケーションが実行される現在のハードウェアプラットフォームはどの程度使用されていますか？

GSC 5

取引レート

トランザクションは毎日、毎週、毎月などの頻度で実行されますか？

GSC 6

オンラインデータ入力

オンラインで入力される情報の割合は？

GSC 7

エンドユーザーの効率

アプリケーションはエンドユーザーの効率のために設計されましたか？

GSC 8

オンライン更新

オンライントランザクションによっていくつのILFが更新されますか？

GSC 9

複雑な処理

アプリケーションには、広範な論理的または数学的な処理がありますか？

GSC 10

再利用性

アプリケーションは、1つまたは複数のユーザーのニーズを満たすように開発されましたか？

GSC 11

インストールが簡単

変換とインストールはどのくらい難しいですか？

GSC 12

操作性

起動、バックアップ、および回復の手順は、どの程度効果的および/または自動化されていますか？

GSC 13

複数のサイト

アプリケーションは、複数の組織の複数のサイトにインストールされるように特別に設計、開発、およびサポートされていましたか？

GSC 14

変更を促進する

アプリケーションは、変更を容易にするために特別に設計、開発、およびサポートされていましたか？

強い影響に影響がないかどうかに基づいて、0〜5のスケールで各 GSC を計量します。
次のように FPC を計算します- + FPC = UFC＆ast; （0.65+（sum（ GSC ）＆ast; .01））

複雑

複雑さは、サイズの独立したコンポーネントです。それは2つのタイプです-

問題の複雑さ-問題の最適な解決に必要なリソースの量です。
ソリューションの複雑さ-特定のソリューションを実装するために必要なリソースです。これには2つの側面があります。彼らは次のとおりです-
時間の複雑さ-リソースはコンピューター時間です。
スペースの複雑さ-リソースはコンピューターのメモリです。

複雑さの測定

複雑さの1つの側面は効率です。アルゴリズムとしてモデル化できるソフトウェア製品を測定します。

例：特定の問題のすべてのインスタンスを解決するアルゴリズムが* f（n）の計算を必要とする場合、問題を解決する複雑さgを持つ他のすべてのアルゴリズムが *f である場合、* f（n）は漸近的に最適です。 * O（g）。その場合、与えられた問題の複雑さは大きくなります-問題の解決のための漸近的に最適なアルゴリズムの O 。

構造の測定

ソフトウェアの構造特性の測定は、製品のメンテナンスだけでなく、開発作業の見積もりにも重要です。要件、設計、およびコードの構造は、ある製品から別の製品への変換、製品のテスト、または初期の内部製品測定から外部ソフトウェア属性を予測する際に生じる困難を理解するのに役立ちます。

構造物対策の種類

ソフトウェアの構造には3つの部分があります。彼らは-

制御フロー構造-プログラム内で命令が実行されるシーケンスです。
データフロー構造-それはプログラムと対話するときのデータの動作です。
データ構造-リスト、キュー、スタック、またはその他の明確に定義された構造の形式のデータ要素と、それらを作成、変更、または削除するためのアルゴリズムの編成です。

制御フロー構造の測定

制御フロー測定は通常、各ノードまたはポイントがプログラムステートメントに対応し、各アークまたは有向エッジがステートメント間の制御フローを示す有向グラフでモデル化されます。これらのグラフは、制御フローグラフまたは有向グラフと呼ばれます。

*'m'* がフローグラフモデルに関して定義された構造メジャーであり、プログラム *A* がプログラム *B* より構造的に複雑な場合、メジャー* m（A）*は* mより大きくなければなりません。 （B）*。

データフロー構造の測定

データフローまたは情報フローは、モジュール間（モジュール内の情報の流れ）またはモジュール内（個々のモジュールとシステムの他の部分との間の情報の流れ）になります。

データがシステムを移動する方法に応じて、次のように分類することができます-

ローカルダイレクトフロー-モジュールが2番目のモジュールを呼び出して情報を渡すか、呼び出されたモジュールが呼び出し元に結果を返す場合。
ローカル間接フロー-呼び出されたモジュールが情報を返し、その情報が次に2番目に呼び出されたモジュールに渡される場合。
グローバルフロー-グローバルデータ構造を介して情報が1つのモジュールから別のモジュールに流れる場合。

情報フローの複雑さは、ヘンリーとカフラによると、

情報フローの複雑さ（M）=長さ（M）×ファンイン（M）×（ファンアウト（M））^ 2 ^ *

どこで、

ファンイン（M）-Mで終了するローカルフローの数+ Mが情報を取得するデータ構造の数
ファンアウト（M）-Mから発生するローカルフローの数+ Mによって更新されるデータ構造の数

データ構造の測定

データ構造は local と global の両方にすることができます。

ローカル、各データ項目の構造の量が測定されます。グラフ理論的アプローチを使用して、個々のデータ構造のプロパティを分析および測定できます。その中で、整数、文字、ブールなどの単純なデータ型は素数と見なされ、より複雑なデータ構造を構築できるさまざまな操作が考慮されます。データ構造のメジャーは、さまざまな操作に関連付けられた素数と値の値に関して階層的に定義できます。

グローバル*では、ユーザー定義変数の総数が測定されます。

規格と証明書

SQA標準の開発には、いくつかの国内および国際標準化機関、専門家および業界志向の組織が関与しています。

次の機関および組織は、SQAおよびソフトウェアエンジニアリング標準の主な開発者です-

IEEE（電気電子技術者協会）コンピューター協会
ISO（国際標準化機構）
DOD（米国国防総省）
ANSI（米国規格協会）
IEC（国際電気技術委員会）
EIA（電子工業会）

これらの組織は、ソフトウェア開発および保守組織で実行される専門的および管理的活動の品質に関する最新の国際基準を提供します。

また、独立した専門的な品質監査を通じてSQA認証を提供します。これらの外部監査は、SQAシステムの開発とその実装における成果を評価します。定期監査後に付与される認証は、次の監査までのみ有効であるため、更新する必要があります。現在、ISO 9000認証サービスは、ヨーロッパおよびその他の国で最も著名なSQA認証プロバイダーです。

また、組織のSQAシステムとその運用を自己評価するためのツールも提供します。 Software Engineering Institute（SEI）、Carnegie Mellon University、およびISO/IEC Std 15504によって開発されたCapacity Maturity Model（CMM）は、このアプローチの例です。

SQA規格

ソフトウェア品質保証基準は、2つの主要なクラスに分類することができます-

認証および評価方法論を含むソフトウェア品質保証管理基準（品質管理基準）
ソフトウェアプロジェクト開発プロセス標準（プロジェクトプロセス標準）

品質管理基準

これらは組織のSQAシステム、インフラストラクチャ、および要件に焦点を合わせながら、方法とツールの選択は組織に任せます。品質管理標準を使用すると、組織はソフトウェア製品が許容可能な品質レベルを達成することを着実に保証できます。

例-ISO 9000-3およびCapability Maturity Model（CMM）

プロジェクトプロセス標準

これらは、ソフトウェア開発および保守プロジェクトを実装するための方法論に焦点を当てています。これらの標準には次のものが含まれます-

取るべきステップ
設計ドキュメントの要件
設計文書の内容
設計レビューとレビューの問題
実行するソフトウェアテスト
テストトピック

当然のことながら、このクラスの多くのSQA標準は、その特性により、ソフトウェアエンジニアリング標準として機能し、その逆も同様です。

これら2つのクラスの標準の特性を次の表にまとめます。

Characteristics	Quality Management Standards	Project Process Standards
The target unit	Management of software development, maintenance and the specific SQA units	A software development and maintenance project team
The main focus	Organization of SQA systems, infrastructure and requirements	Methodologies for carrying out software development and maintenance projects
The standard’s objective	“What” to achieve	“How” to perform
The standard’s goal	Assuring the supplier’s software quality and assessing its software process capability	Assuring the supplier’s software quality and assessing its software process capability Assuring the quality of a specific software project.
Examples	ISO 9000-3 SEI’s CMM	ISO/IEC 12207 IEEEStd 1012-1998

ISO 9001認証

ISO（国際標準化機構）は、国家標準化団体の世界的な連合です。 ISO技術委員会は国際規格を準備します。 ISOは、電気技術標準化のすべての問題に関して、国際電気標準会議（IEC）と密接に協力しています。

国際規格は、ISO/IEC指令、パート2に記載されている規則に従って作成されます。技術委員会によって採択された国際規格の草案は、投票のために会員団体に回覧されます。 ISO 9001は、技術委員会ISO/TC 176、品質管理と品質保証、小委員会SC 2、品質システムによって作成されました。

プロセスアプローチ

この国際規格は、顧客の要件を満たすことで顧客満足度を高めるために、品質管理システムの有効性を開発、実装、改善する際のプロセスアプローチの採用を促進しています。組織が効果的に機能するには、多数のリンクされたアクティビティを決定および管理する必要があります。リソースを使用し、入力から出力への変換を可能にするために管理されるアクティビティまたは一連のアクティビティは、プロセスと見なすことができます。

多くの場合、1つのプロセスからの出力が次のプロセスへの入力を直接形成します。組織内のプロセスシステムの適用と、これらのプロセスの識別と相互作用、および望ましい結果を生み出すための管理は、*「プロセスアプローチ」*と呼ばれます。

プロセスアプローチの利点は、プロセスのシステム内の個々のプロセス間のリンクだけでなく、それらの組み合わせや相互作用に対しても継続的に制御できることです。品質管理システム内で使用される場合、そのようなアプローチは次の重要性を強調します-

要件を理解して満たす
付加価値の観点からプロセスを検討する必要がある
プロセスのパフォーマンスと有効性の結果を取得する
客観的な測定に基づくプロセスの継続的な改善

ISO 9001-ソフトウェアへの適用：TickITイニシアチブ

TickITは、TickITイニシアチブとして知られるソフトウェア産業の特性にISO 9001を適合させるための方法論の開発を促進するために、英国貿易産業省と協力して1980年代後半に英国のソフトウェア産業によって開始されました。

さらに、TickITは情報技術（IT）に特化しています。商用ソフトウェア開発および保守サービスの全範囲をカバーしています。 TickITは、現在BSIのDISC部門（英国規格協会）によって管理および保守されており、英国およびスウェーデンのIT組織の認証を取得しています。

その活動が含まれます-

ISO 9001認証を広めるためのソフトウェア業界の取り組みをサポートするTickITガイドの発行。 ISO/IEC 12207およびISO/IEC 15504への参照を含む現在のガイド（エディション5.0、TickIT、2001）は、すべてのTickITのお客様に配布されています。
ソフトウェア品質システムの監査ベースの評価の実行、および管理に加えてソフトウェア開発および保守プロセスの改善に関する組織への相談。
ISO 9000認証監査を実施します。

監査ベースの評価と認証監査を実施するTickIT審査員は、国際認証審査登録者（IRCA）によって登録されています。 IRCAの登録審査員には、とりわけ、管理およびソフトウェア開発の経験が必要です。また、審査員コースを正常に完了する必要があります。

登録された主任審査員は、TickIT審査の実施と指揮に関する実証済みの経験を持っている必要があります。

ソフトウェアプロセス評価

ソフトウェアプロセス評価は、プロセスモデルに基づいて、組織が使用するソフトウェアプロセスの統制された検査です。評価には、現在の慣行の特定と特徴付け、長所と短所の特定、および現在の慣行が不十分な（ソフトウェア）品質、コスト、およびスケジュールの重大な原因を制御または回避する能力が含まれます。

ソフトウェア評価（または監査）には3つのタイプがあります。

*自己評価（第一者評価）*は、組織の担当者によって内部的に実行されます。
*二次評価*は外部の評価チームによって実行されるか、組織は顧客によって評価されます。
*第三者評価*は、外部の当事者または（たとえば、顧客との契約を入力する能力を検証するために第三者によって評価されているサプライヤー）によって実行されます。

ソフトウェアプロセスの評価は、オープンで協調的な環境で実行されます。ソフトウェアプロセスを改善するために組織を使用するためのものであり、結果は組織にとって機密です。評価対象の組織には、評価チームのメンバーが必要です。

ソフトウェアプロセスの成熟度評価

ソフトウェアプロセス評価の範囲は、組織内のすべてのプロセス、ソフトウェアプロセスの選択されたサブセット、または特定のプロジェクトをカバーできます。標準ベースのプロセス評価アプローチのほとんどは、常にプロセス成熟度の概念に基づいています。

評価対象が組織である場合、同じ方法を連続して適用しても、プロセス評価の結果は異なる場合があります。異なる結果には2つの理由があります。彼らです、

調査対象の組織を決定する必要があります。大企業の場合、組織のいくつかの定義が可能であるため、実際の評価範囲は連続した評価で異なる場合があります。
同じ組織のように見える場合でも、組織を表すために選択されたプロジェクトのサンプルは、範囲と結果に影響を与える可能性があります。

評価の対象ユニットがプロジェクトレベルにある場合、評価にはプロジェクトの成功または失敗に寄与するすべての意味のある要因を含める必要があります。特定のプロセス成熟度モデルの確立された次元によって制限されるべきではありません。ここでは、プロジェクトデータによって実証される実装の程度とその有効性が評価されます。

組織が全体的な長期改善戦略に着手しようとする場合、プロセスの成熟度が重要になります。ソフトウェアプロジェクトの評価は、客観的であるために独立した評価でなければなりません。

ソフトウェアプロセス評価サイクル

Paulkと同僚（1995）によると、CMMベースの評価アプローチでは6段階のサイクルが使用されます。彼らは-

チームを選択する-チームのメンバーは、ソフトウェアエンジニアリングと管理に精通した専門家でなければなりません。
評価対象のサイトの代表者は、標準的なプロセス成熟度アンケートに記入します。
評価チームは、アンケートの回答の分析を実行し、CMMの主要なプロセス領域に従って、さらなる調査が必要な領域を特定します。
評価チームは、サイトにアクセスして、ソフトウェアプロセスとサイトの理解を深めます。
評価チームは、組織のソフトウェアプロセスの長所と短所を特定する調査結果のリストを作成します。
評価チームは、キープロセスエリア（KPA）プロファイル分析を準備し、結果を適切な対象者に提示します。

たとえば、評価チームは、認定されたSEIリード評価者が主導する必要があります。チームは4〜10人のチームメンバーで構成する必要があります。少なくとも、1人のチームメンバーが評価対象の組織のメンバーであり、すべてのチームメンバーがSEIのCMM入門（またはその同等）コースとSEIのCBA IPIチームトレーニングコースを完了する必要があります。チームメンバーは、いくつかの選択ガイドラインも満たしている必要があります。

データ収集に関して、CBA IPIは4つの方法に依存しています-

標準的な成熟度アンケート
個人およびグループインタビュー
文書レビュー
評価参加者との調査結果案のレビューからのフィードバック

SCAMPI

プロセス改善のための標準CMMI評価方法（SCAMPI）は、CMMIモデルの要件を満たすために開発されました（Software Engineering Institute、2000）。 CBA IPIにも基づいています。 CBA IPIとSCAMPIの両方が3つのフェーズで構成されています-

計画と準備
オンサイトで評価を実施
結果を報告する

計画と準備段階の活動には以下が含まれます-

評価範囲を特定する
評価計画を作成する
評価チームの準備とトレーニング
参加者の簡単な評価を行う
CMMI評価アンケートの管理
アンケートの回答を調べる
最初の文書レビューを実施する

オンサイト評価フェーズの活動には、以下が含まれます-

オープニングミーティングを実施する
インタビューを実施する
情報を統合する
調査結果草案のプレゼンテーションを準備する
調査結果の草案を提示する
最終的な調査結果を統合、評価、準備する

レポート結果フェーズのアクティビティには次が含まれます-

最終結果を発表する
エグゼクティブセッションを実施する
評価のまとめ

品質保証

ソフトウェアの品質保証のためのIEEEの定義は次のとおりです-

'_「アイテムまたは製品が確立された技術要件に適合しているという十分な信頼を提供するために必要なすべてのアクションの計画的かつ体系的なパターン。製品が開発または製造されるプロセスを評価するために設計された一連のアクティビティ。」_

SQAアクティビティの目的

SQA活動の目的は次のとおりです-

ソフトウェア開発（プロセス指向）

ソフトウェアが機能的な技術要件に準拠するという信頼できる許容レベルを保証します。
ソフトウェアが管理スケジューリングおよび予算要件に準拠するという許容できるレベルの信頼性を保証します。
ソフトウェア開発とSQAアクティビティの改善と効率向上のためのアクティビティの開始と管理。

ソフトウェア保守（製品指向）

ソフトウェアメンテナンスアクティビティが機能的な技術要件に適合することを、許容できるレベルの信頼性で保証します。
ソフトウェアメンテナンスアクティビティが管理スケジューリングおよび予算要件に適合することを、許容できるレベルの信頼度で保証します。
ソフトウェアメンテナンスおよびSQAアクティビティの効率を改善および向上させるためのアクティビティの開始と管理。これには、コストを削減しながら、機能および管理要件を達成する見通しを改善することが含まれます。

品質保証のための組織化

組織構造内で動作する品質保証組織のフレームワークには、次の参加者が含まれます-

マネージャー

トップマネジメントの幹部、特にソフトウェアの品質保証を直接担当する幹部
ソフトウェア開発および保守部門のマネージャー
ソフトウェアテスト部門のマネージャー
開発および保守プロジェクトのプロジェクトマネージャーおよびチームリーダー
ソフトウェアテストチームのリーダー

テスター

ソフトウェアテストチームのメンバー

SQAの専門家と関心のある実務家-

SQA受託者
SQA委員
SQAフォーラムメンバー
SQAユニットチームメンバー

ソフトウェアテスト部門のマネージャーと従業員のみが、SQAタスクのパフォーマンスにフルタイムで従事しています。他の人は、管理機能や専門職務の遂行中、または他の人のボランティアとして、ほとんどの場合、SQA委員会、SQAフォーラム、またはSQA受託者として、時間の一部を品質問題に充てています。

QAにおける管理の役割

基本的に、ソフトウェア開発組織には3レベルの管理構造が存在します-

トップマネジメント
部門管理
プロジェクト管理

ソフトウェア品質におけるトップマネジメントの責任

以下は、ソフトウェア品質を確保する上での経営陣の責任です-

会社のソフトウェア製品とソフトウェア保守サービスの品質を保証する
あらゆるレベルの従業員に顧客満足度に加えて、製品とサービスの品質の重要性を伝えます
満足のいく機能と顧客の要件への完全なコンプライアンスを保証する
組織のSQAシステムの品質目標が確立され、その目標が達成されていることを確認する
計画を開始し、SQAシステムを組織の顧客、競争、技術に関連する主要な内部および外部の変更に適合させるために必要な変更の実装を監督します
直接介入して危機的状況の解決を支援し、損害を最小限に抑える
SQAシステムに必要なリソースの可用性を確保する

次の手順は、その責任を果たすために経営陣が取ることができます-

組織のソフトウェア品質ポリシーの確立と更新。
SQAの副社長などの幹部の1人をソフトウェア品質の問題を担当するように割り当てる
ソフトウェア品質の問題に関するパフォーマンスの定期的な管理レビューの実施

ソフトウェア品質ポリシー

組織のソフトウェア品質ポリシーは、次の要件を伝える必要があります-

組織の目的と目標への適合
一般的なソフトウェア品質保証の概念へのコミットメント
組織が採用した品質基準へのコミットメント
ソフトウェアの品質保証のために適切なリソースを割り当てるというコミットメント
組織の品質と生産性の継続的な改善への取り組み

ソフトウェア品質の管理責任者

ソフトウェア品質の問題を担当する幹部の責任は次のように分類されます-

年間のSQA活動プログラムと予算の準備の責任
SQAシステム開発計画の準備に対する責任
年間SQA定期活動プログラムおよび計画されたSQA開発プロジェクトの実施の全体的な管理
経営陣へのSQA問題のプレゼンテーションと擁護

年次SQA活動プログラムの準備の責任

これには、エグゼクティブが必要です-

来年のシステムのSQA目標を確立する
SQAユニットが年次活動プログラムのために準備した提案をレビューし、SQAシステムに設定された目標を達成する提案の可能性を検証します。
活動プログラムが、来年に計画されている下請業者サービスとソフトウェア購入の特性と範囲に適切かどうかを判断する
SQAプログラムの実施のために計画されている人材およびその他のリソースの妥当性を判断する
年間SQA活動プログラムと予算の最終バージョンを承認する

SQAシステム開発計画の準備に対する責任

これらの計画は、技術の変化だけでなく、顧客の要求や競争にも適応できなければなりません。責任が含まれます-

近い将来に組織のソフトウェアの品質に影響を及ぼすと予想される傾向のレビュー
新しいツールやSQA規格に適した新しい手順の準備など、SQAの適応に関する提案を確認する
ベテランのソフトウェア開発チームおよび新しく採用されたチームメンバー向けのトレーニングプログラムの準備
新しいツールと標準、およびトレーニングプログラムの成功を評価するのに適したソフトウェア品質メトリックの開発
スケジュールと予算を含む、計画されたSQA開発プロジェクトの最終バージョンの承認

年間SQAプログラムの実施の全体的な管理

エグゼクティブの責任者は次のことを担当します-

年次活動プログラムの一般的な監督
SQA適応プロジェクトの進捗状況のレビュー
チームの目標によって定められた品質の達成を実現するために取られた行動の一般的な監督（定期的な報告に基づく）
内部品質監査に基づいたSQA手順および標準への準拠のレビュー
ソフトウェア開発プロジェクトのスケジュールと予算へのコンプライアンスの一般的なフォローアップ
外部および内部顧客への品質維持サービスの提供の一般的なフォローアップ

経営陣へのSQA問題の提示と擁護

品質を促進し、SQAシステムの問題を解決するために必要なもの-

提案された年間活動プログラムと予算の最終承認のためのプレゼンテーション
計画されたSQA適応プロジェクトの最終承認のためのプレゼンテーションと対応する予算
組織のソフトウェア品質に特化した定期的な管理レビュー会議の開始とリーダーシップ
深刻な品質障害、深刻な専門スタッフ不足によるプロジェクトの成功への脅威、SQAユニットの経営危機など、特別なソフトウェア品質イベントに特化した管理レベルの議論の開始

SQAの部門管理責任

中間管理職の品質保証責任には以下が含まれます-

ソフトウェア品質管理システムの管理（品質システム関連タスク）
特定のマネージャーの権限の下でユニットまたはチームによって実行されるプロジェクトおよびサービスに関連するタスクの管理（プロジェクト関連タスク）

品質システム関連の責任

これらには、部門レベルで実行されるSQAアクティビティが含まれます-

SQAユニットが作成した推奨プログラムに基づく、部門の年間SQA活動プログラムと予算の準備
SQAユニットが作成した推奨計画に基づいた、部門のSQAシステム開発計画の準備
部門の年間SQA活動プログラムと開発プロジェクトのパフォーマンスの管理
経営陣への部門のSQA問題のプレゼンテーション

プロジェクト関連の責任

これらは、組織の手順と権限の配分によって異なります。彼らは通常、関与します-

CAB、SCM、SCCAの各機関を含む、部門のユニットにおける品質保証手順へのコンプライアンスの管理
契約レビュー結果と提案承認の詳細なフォローアップ
計画されたレビュー活動のユニットパフォーマンスのレビュー。プロジェクト文書の承認とプロジェクト段階の完了
ソフトウェアテストとテスト結果のフォローアップ。プロジェクトのソフトウェア製品の承認
ソフトウェア開発プロジェクトのスケジュールと予算の逸脱の進捗状況のフォローアップ
スケジュール、予算、顧客関係の問題を解決するプロジェクトマネージャーへのアドバイスとサポート
保守サービス提供の質のフォローアップ
プロジェクトのリスクとその解決策の詳細なフォローアップ
顧客の要件と顧客の満足度に対するプロジェクトのコンプライアンスのフォローアップ
大規模なソフトウェア変更命令の承認とプロジェクト仕様からの大幅な逸脱

ソフトウェア品質に関するプロジェクト管理の責任

ほとんどのプロジェクト管理の責任は、手順と作業指示書で定義されています。プロジェクトマネージャーは、すべてのチームメンバーが上記の手順と指示を確実に順守する責任者です。

彼の仕事には、特に次のような専門的な実践的および管理的な仕事が含まれます-

プロのハンズオンタスク
プロジェクトおよび品質計画とその更新の準備
顧客とサプライヤーの共同委員会への参加
募集、トレーニング、指導への参加を含む、プロジェクトチームのスタッフの詳細なフォローアップ
管理タスク +プロジェクトマネージャーは、次のようなフォローアップの問題に対処します-
レビュー活動の実施とその結果の修正
ソフトウェア開発およびメンテナンスユニットのパフォーマンス、統合およびシステムテストアクティビティ、修正および回帰テスト
受け入れテストのパフォーマンス
リモート顧客サイトでのソフトウェアのインストールと顧客によるソフトウェアシステムの実行
プロジェクトチームメンバーのSQAトレーニングと指導
プロジェクト活動に割り当てられたスケジュールとリソース
顧客の要望と満足
進化するプロジェクト開発リスク、ソリューションの適用、結果の管理

SQAユニット

SQAユニットの構造は、組織の種類と規模によって異なります。次の図は、SQAユニットの下の標準構造とすべてのコンポーネントの例を示しています。この章では、各サブユニットの役割と責任について説明します。

SQAユニット

SQAユニット長が実行するタスク

SQAユニットのヘッドは、SQAユニットとそのサブユニットによって実行されるすべての品質保証タスクを担当します。これらのタスクは、次のカテゴリに分類することができます-

計画タスク
ユニットの管理
SQAの専門的な活動

計画タスク

ユニットの提案された年間活動プログラムと予算の準備
組織のソフトウェア品質管理システムの計画と更新
ソフトウェア開発および保守部門向けに推奨される年間SQA活動プログラムとSQAシステム開発計画の準備

管理タスク

SQAチームの活動の管理
SQAアクティビティプログラムの実装の監視
チームメンバー、SQA委員、SQA受託者の指名
組織内のソフトウェア品質問題のステータスや月次パフォーマンスレポートなど、特別な定期的なレポートの準備

SQAプロフェッショナル活動

プロジェクト合同委員会への参加
正式な設計レビューへの参加
仕様からの逸脱のレビューと承認
プロジェクトマネージャーおよびチームリーダーとの相談
SQA委員会およびフォーラムへの参加

プロジェクトライフサイクルSQA

プロジェクトライフサイクルサブユニットに関連するSQAタスクは、2つのグループに分類できます-

「純粋な」管理フォローアップおよび承認タスク（プロジェクトライフサイクル制御タスク）
「実践」またはプロジェクトチームのSQA活動への積極的な参加。専門的な貢献が必要な場合（参加タスク）

プロジェクトライフサイクル制御タスク

開発および保守チームのSQA手順および作業指示へのコンプライアンスのフォローアップ
関連する手順に従ったソフトウェア製品の承認または推奨
内部および外部の顧客へのソフトウェアメンテナンスサービスの配信の監視
顧客満足度を監視し、顧客の品質保証担当者との連絡を維持する

参加タスク

これらのタスクには、参加が含まれます-

契約レビュー
プロジェクト開発と品質計画の準備と更新
正式な設計レビュー
下請業者の正式な設計レビュー
顧客受け入れテストを含むソフトウェアテスト
下請業者のソフトウェア製品のソフトウェア受け入れテスト
新しいソフトウェア製品のインストール

SQAインフラストラクチャ運用タスク

SQAシステムは、スムーズに動作するためにさまざまなインフラストラクチャコンポーネントを採用しています。

手順と作業指示
高品質のデバイス（テンプレート、チェックリスト）のサポート
スタッフのトレーニング、指導、認定
予防および是正措置
構成管理
ドキュメント管理

より具体的には、これらのコンポーネントに関するSQAサブユニットのタスクには以下が含まれます-

手順、作業指示、テンプレート、チェックリストなどの更新版の発行、およびハードコピーおよび/または電子的手段による流通
SQA手順、作業指示書、および同様の項目の順守および適用に関するトレーニングおよび指導の、新規および現在のスタッフへの伝達
他のコンポーネントの中でも特に、新規および改訂された手順、開発ツールおよび方法に関するSQA受託者への指示
新規および改訂されたSQA手順の実装の監視とサポート
スタッフ認定活動のフォローアップ
CAB委員会への参加を含む予防および是正措置を必要とする主題の提案
CCA委員会への参加を含む、構成管理活動のフォローアップ
文書化手順と作業指示の遵守のフォローアップ

SQA内部監査および認証タスク

ソフトウェア組織内またはソフトウェア組織によって実行されるSQA監査の種類は、次のように分類することができます-

内部監査
下請業者とサプライヤーのSQAシステムを評価するための監査
認証機関が実施する外部監査
サプライヤとして組織を受け入れる前にSQAシステムを評価することを希望する顧客によって実行される外部監査

監査の最初の2つのクラスはSQAサブユニットによって開始および実行され、最後の2つのクラスは外部機関によって実行されます。

SQAユニットは、内部SQA監査のために次のタスクを実行します

内部SQA監査のための年次プログラムの準備
内部SQA監査のパフォーマンス
監査されたチームおよび他のユニットによって実行される修正および改善のフォローアップ
改善の推奨事項を含む、監査結果のステータスに関する定期的な要約レポートの準備

SQAユニットは、下請業者とサプライヤーの監査のために以下のタスクを実行します-

下請業者とサプライヤーのSQA監査のための年次プログラムの準備
下請業者およびサプライヤーのSQA監査のパフォーマンス
監査された下請業者およびサプライヤによって実行される修正および改善のフォローアップ
内部および外部ソースからの下請業者およびサプライヤーのパフォーマンスに関するデータの収集
監査レポートおよび他の内部および外部ソースから収集された情報に基づいた、組織の認定下請業者およびサプライヤーのSQAシステムの定期的な評価。評価レポートには含まれています-
下請業者およびサプライヤーの認証に関する推奨事項
認証機関によって実行される外部監査には、次のタスクが含まれます-
認証審査の内容とスケジュールの調整
認証機関が指定した文書の準備
監査チームへの指示と認証監査に必要な準備の実施
認証審査への参加
必要な修正と改善が実行されていることを確認する

組織の顧客によって実行されるSQA監査には、これらのタスクが伴います-

監査の内容とスケジュールの調整
顧客の監査人が指定した書類の準備
監査対象チームの指示と、組織の顧客によるSQA監査に必要な準備の実行
監査への参加
必要な修正と改善が実行されていることを確認してください

SQAサポートタスク

SQAサポートサービスのほとんどの消費者は組織内にいます。プロジェクトマネージャー、チームリーダー、およびSQA受託者が含まれます。彼らのタスクは次のとおりです-

プロジェクト計画とプロジェクト品質計画の準備
スタッフ配置レビューチーム
特定されたソフトウェア開発リスクを解決するための手段の選択
スケジュールの遅延と予算超過を解決するための手段の選択
SQAメトリックとソフトウェアコストコンポーネントの選択
SQA情報システムの使用
SQAユニットによって蓄積された障害経験データを反映する開発方法論とツールの選択

SQA標準および手順タスク

SQAサブユニットは、どのSQA標準を採用するかを決定し、組織の手順を開発および維持することに密接に関与しています。付随する義務を果たすために、SQAユニットは以下を行う必要があります-

新しい手順と手順の更新の開発のための年次プログラムを準備する
適切な委員会とフォーラムに参加して、新しい手順と手順の更新の開発を担当する
SQAおよびソフトウェアエンジニアリング標準の開発および変更のフォローアップ。組織に関連する追加の手順と変更の導入
組織によって適用される標準の採用または削除を含む、専門的な標準の変更に応じて、手順の更新と適応を開始する

SQAエンジニアリングタスク

このSQAサブユニットの目下の目標は、専門的な進歩のフォローアップ、運用上の問題の解決、および障害の専門家による分析です。

したがって、主なエンジニアリングタスクには次のものが含まれます-

新しい開発ツールおよび現在使用されている開発ツールの新しいバージョンに関する品質と生産性のテスト
新しい開発および保守方法と方法改善の品質と生産性の評価
現在使用されているソフトウェア開発ツールおよび方法の適用で直面する問題の解決策の開発
ソフトウェアの品質とチームの生産性を測定する方法の開発
ソフトウェア開発の失敗の分析および提案されたソリューションの定式化中のCAB委員会への技術サポートの提供

SQA情報システムのタスク

SQA情報システムは、SQAシステムの機能を促進および改善することを目的としています。関係するタスクは次のとおりです-

ソフトウェア開発および保守ユニット用のSQA情報システムの開発
活動データの収集
たとえば、定期的なレポート、リスト、例外レポート、クエリの処理
たとえば、定期的なレポート、リスト、例外レポート、クエリの処理
ソフトウェアの品質指標とソフトウェアの品質コストの推定を含む、ソフトウェア開発およびメンテナンスユニットによって提供される情報のSQAユニットの処理を促進するSQA情報システムの開発
SQA情報システムの更新
組織のSQAインターネット/イントラネットサイトの開発と保守

SQA受託者とそのタスク

SQA受託者は、主にソフトウェア品質の促進に関与しているメンバーです。これらのメンバーは、SQAコンポーネントを正常に実装するために必要な内部サポートを提供します。

そのタスクは組織によって異なる場合があります。したがって、それはユニット関連および/または組織関連のタスクである可能性があります。

ユニット関連のタスク

ソフトウェア品質手順および作業指示の実装中の困難を解決するために同僚をサポートします
関連するSQAタスクを実行する際にユニットマネージャーを支援する
コンプライアンスを促進し、同僚によるSQA手順と作業指示の実装を監視する
SQAユニットに実質的かつ体系的な非コンプライアンスイベントを報告する
重大なソフトウェア品質障害をSQAユニットに報告する

組織関連のタスク

組織全体のSQA手順と作業指示の変更と更新をトリガーする
組織の開発および保守プロセスの改善をトリガーします
各ユニットで観察された再発障害の解決策に関するCABへの申請を開始する
組織全体のSQAトレーニングのニーズを特定し、SQAユニットが実施する適切なトレーニングまたは指導プログラムを提案する

SQA委員会とそのタスク

SQA委員会は恒久的またはアドホックのいずれかです。タスクは組織によって大きく異なる場合があります。

*常設委員会*は、一般にSCC（ソフトウェア変更管理）、CA（修正措置）、手順、メソッド開発ツール、品質指標を扱います。
*アドホック委員会*は一般的に、特定の手順の更新、ソフトウェア障害の分析と解決、ターゲットプロセスまたは製品のソフトウェアメトリックの作成、特定の問題のソフトウェア品質コストとデータ収集方法の更新など、一般的な関心のある特定のケースを扱います。

恒久的なSQA委員会は、SQA組織フレームワークの不可欠な部分です。そのタスクと操作は通常、組織のSQA手順で定義されています。

アドホック委員会は、問題ごとに短期間で設立され、メンバーはソフトウェア品質問題の責任者、SQAユニットの長、SQAサブユニット、恒久的なSQA委員会、またはその他の開始機関によって指名されます。その形成と仕事に興味を持っています。この機関は、アドホック委員会のタスクも定義しています。

Software-quality-management-quick-guide

ソフトウェア品質管理-はじめに

ソフトウェア品質の課題

製品の複雑さ

製品の可視性

製品開発と生産プロセス

ソフトウェア品質要因

マッコールの因子モデル

製品運用ソフトウェアの品質要因

正しさ

信頼性

効率

誠実さ

使いやすさ

製品改訂の品質要因

保守性

柔軟性

テスト容易性

製品移行ソフトウェアの品質係数

移植性

再利用性

相互運用性

SQAコンポーネント

SQAシステムのコンポーネント

事前プロジェクトコンポーネント

プロジェクトのライフサイクル活動評価のコンポーネント

インフラストラクチャエラーの防止と改善のコンポーネント

ソフトウェア品質管理のコンポーネント

標準化、認証、およびSQAシステム評価のコンポーネント

SQAの組織化-人間の構成要素

プロジェクト前のソフトウェア品質コンポーネント

契約レビュー

開発および品質計画

ソフトウェア品質メトリック

製品品質指標

故障までの平均時間

欠陥密度

顧客の問題

顧客満足

インプロセス品質メトリック

機械試験中の欠陥密度

機械試験中の欠陥到着パターン

位相ベースの欠陥除去パターン

欠陥除去の有効性

メンテナンス品質メトリック

バックログとバックログ管理インデックスを修正

応答時間を修正し、応答性を修正します

不良債権の割合

修正品質

測定の基礎

日常生活での測定

ソフトウェア工学の測定

代表的な測定理論

経験的関係

リッカートスケール

強制ランキング

言語周波数スケール

順序スケール

比較スケール

数値スケール

マッピングのルール

測定の表現条件

正式な測定の主要な段階

測定とモデル

直接測定

間接測定

予測のための測定

測定スケール

公称スケール

順序スケール

インターバルスケール

比率スケール

絶対スケール

実証調査

調査手法の選択

調査

ケーススタディ

正式な実験

仮説を述べる

変数の制御を維持する