一貫性のある組織プロセスフレームワークしかない場合、欠陥封じ込め指標を組織レベルですぐに適用できますか？
総欠陥封じ込め有効性（TDCE）やフェーズ封じ込め有効性（PCE）などの欠陥封じ込めメトリックを使用して、プロセスの品質を適切に示すことができます。 TDCEは、要件と製品のフィールドへのリリースとの間のある時点で捕捉された欠陥を捕捉し、欠陥を見つけて除去するプロセス全体の全体的な有効性を示します。 PCEは、ソフトウェア開発ライフサイクルの各フェーズの詳細と、欠陥の検出と削除の技術のしくみを提供します。
これらの指標を適用することは、製品開発（多くの場合はプロジェクト）のプロセスと方法が明確に定義されているレベルで理にかなっています。ただし、一部の組織では、プロジェクトレベルで調整されたプロセスフレームワークを提供しています。このプロセスフレームワークには、認定を満たすために必要なガイダンス（ISO9001、CMMI）、既知の優れた手法（アジャイルメソッド、リーン、シックスシグマ）を組み込むためのプラクティス、および法的または規制上の理由の要件が含まれます。ただし、要件の収集、システムの設計、ソフトウェアの作成、テストの実施、およびリリースの具体的な詳細は、製品開発チームに任されています。
組織レベルでプロセスフレームワークのみが存在する場合に、欠陥封じ込めメトリックを組織レベルで適用する効果的な方法はありますか？そうでない場合、各プロジェクトから抽出できるメトリック（組織プロセスのフレームワークに適合する調整されたプロセスを使用する）のアイデアにはどのようなものがありますか？
このような指標の最終目標は、多数の進行中のプロジェクトの欠陥封じ込めプラクティスを統合し、経営陣に報告することです。対象読者は、組織の（すべてのエンジニアリング分野の）チーフソフトウェアエンジニアやチーフエンジニアなどの役割を持つ人々です。プロジェクト固有のデータは利用可能ですが、アイデアは、進行中のすべてのプロジェクトにわたるすべての調整されたプロセスの一般的な効果を定量化するものを作成することです。このデータは、プロセスの品質を実証するために、CMMI、ISO、または同様の監査の一部としても表示されると思います。
欠陥管理の統合は、個別の欠陥管理システムを必要とするほどプロジェクトが直交していない限り、良い考えのように思えます。たとえば、独自のテストを行う一人の開発者は箇条書きリストで問題を解決できますが、顧客がサポートチームにバグを報告する分散型組織では、はるかに重いプロセスが必要になります。これは明白ですが、統合が関係するすべての開発者にどのように影響するか、そして開発者がそれに参加する意欲があるかどうかを検討することが重要です。
バグメトリックの問題は、開発者がバグカウントがパフォーマンスを測定する方法であると感じた場合、ファッジ数（複数のバグを1つにグループ化） 、バグの影響を過小評価し、バグを上流で捕まえたと述べた）。レポートを経営陣に提示する場合、これは特にリスクです。すべての開発者からサポートを得ても、彼らが個々にバグを報告する方法には大きな違いがあります。
欠陥封じ込め処理は、特に、下流で指数関数的に増加するコスト曲線の仮定を保持しているようです。これは事実かもしれないが、できるだけ早く欠陥を止めるのではなく、アジリスト コスト曲線を変更するための説得力のある議論を行う です。それぞれのプロジェクトとバグのタイプは劇的に異なるコスト曲線を持っているかもしれないので、固定コスト曲線を仮定するどのメトリックにも懐疑的です。
ダウンストリームでバグを検出するのが劇的に高額な場合は、より優れたツールを採用し、継続的インテグレーション、自動テスト、またはその他のアジャイルプラクティスを採用することにより、コスト曲線を下げることをお勧めします。もちろん、一部のプロジェクトでは、避けられない大きなダウンストリームコスト（スペースシャトルコードなど）が発生する可能性があり、その場合は、欠陥封じ込めメトリックスの方が理にかなっています。
それ以外の場合、私の意見では、有用な「メトリック」は、システムの欠陥の分析に役立つようにタイプ別にバグを分類しています。バグが発見された場所（開発、統合、または現場で）を追跡することも分析にとって重要ですが、前に述べたように、固定コストカーブにバグを挿入して1つの数値を取得するのにはためらいがあります。代わりに、Mylynなどのツールを使用して開発者がバグに費やす時間を追跡することで、バグを修正するためのコストを見積もることができますが、これには開発者の側でいくつかの規律が必要です。
私見の意見（同意しない場合は反対投票）これは四角い止め釘、丸い穴です。
特にアジャイルのようなプロセスフレームワークが存在するのは、プロセスが人ほど重要ではないからです（ アジャイル宣言 を参照）。指標がそれほど重要ではないということではありません。たとえばVelocityのような重要なものは、ユーザーストーリーの完了率と関係があります。欠陥はユーザーストーリーに関連付けられ、短命である必要があります。そうでない場合、欠陥は単に別のユーザーストーリーになるはずです。しかし、私は余談です。
TDCEやPCEなどのメトリクスは、アジャイルなどのプロセスフレームワークでは意味がありません。これは、アジャイルがマクロプロジェクトレベルでのソフトウェアの表示に特に反対して実行されるためです。特にバグの解決固有の意味開発前の厳格な要件セット段階。
それはベーコンのほこりを測定しようとするようなものです。確かにできました試してみればおそらく測定できますが、なぜそうしたいのでしょうか？
そうは言っても、プロセスフレームワークは、プロジェクトまたは組織のニーズを具体的に満たすカスタムフレームワークの開発を促進します。組織、製品、および顧客に関連性があり有益であると考える限り、なぜミニPCEメトリックを考案できなかったのかわかりません。
クロストーク誌の記事 欠陥封じ込めを定量的欠陥管理に進める と題された記事をレイセオンの2人のエンジニアが書きました。この記事では、私がやりたいことを正確に行うための手法について説明します。ソフトウェアの欠陥封じ込めメトリックを用意し、組織レベルでそれらを意味のあるものにしようとします。彼らはこの手法を定量的欠陥管理（QDM）と呼んでいます。
過去の欠陥データを中心に、現在のプロジェクトデータと履歴データを比較します。同様の過去のプロジェクトの特定のフェーズで生成された欠陥の数を決定することにより、同じフェーズの現在のプロジェクトで生成されると予想される欠陥の数を推定することが可能です。もちろん、継続的な改善を受け入れる環境では、時間の経過とともに欠陥の減少傾向が見られると予想されますが、これは説明できます。
履歴データがわかれば、見つかった同相欠陥をその予測数と比較できます。これにより、開発の各フェーズのさまざまな欠陥検出戦略に時間とリソースを割り当て、欠陥の除去と封じ込めのデータを確認して、将来のプロジェクトで欠陥を防ぐためのプロセスを改善できます。各フェーズに適切な時間を割り当て、欠陥を検出するために使用される技術を継続的に監視および改善することにより、プロセスと製品の両方の品質の改善が期待できます。
著者はまた、シックスシグマおよびCMMI（特にレベル4およびレベル5）との関係でこのメトリックについて話します。
これは欠陥の封じ込めに正確に対応しているわけではありませんが、管理には適切だと思います。現在のプロセス品質を以前のプロジェクトと比較するためにプロジェクト全体で使用できるデータを提供し、製品品質を監視するための追加データを提供し、（時間とともに）プロセス改善努力の有効性を実証します。