ソフトウェアのテスト方法論は欠陥のあるデータに依存していますか？
ソフトウェアエンジニアリングではよく知られている事実ですが、バグを修正するコストは、バグが発見された後の開発で指数関数的に増加します。これは、Code Completeで公開され、他の多くの出版物で採用されているデータによってサポートされています。
ただし、 このデータは存在しなかった であることがわかります。 Code Completeによって引用されたデータは、明らかにそのようなコスト/開発時間の相関関係を示しておらず、同様の公開された表は、いくつかの特殊なケースで相関関係を示し、他のケースではフラットカーブを示しました（つまり、コストの増加なし）。
これを裏付けるまたは反駁する独立したデータはありますか？
そしてtrueの場合（つまり、最近発見されたバグのこの指数関数的に高いコストをサポートするデータがない場合）、これはソフトウェア開発方法論にどのように影響しますか？
ソフトウェアのテスト方法論は欠陥のあるデータに依存していますか？
はい、明らかに。 アジャイル変化コスト曲線の調査 は、ケントベックのXP（彼の動機の一部だったか、正当化の一部だったか）に関する作業の一部がコードコンプリートテーブルの背後にある「指数」曲線の知識に基づいて、欠陥コストの「曲線を平坦化する」ため。少なくともはい、少なくとも1つの方法論（テストファースト開発の普及に最も貢献した方法論）に取り組みます。少なくとも部分的には欠陥のあるデータに基づいています。
これを裏付けるまたは反駁するための独立したデータはありますか？
確かに、他にも調べられるデータがあります。私が知っている最大の研究は、ヒューズ航空機で CMM評価プログラム の一部として行われた欠陥の分析です。そこからのレポートは、欠陥コストがそれらのフェーズにどのように依存したかを示しています：ただし、そのレポートのデータには差異が含まれていないため、注意する必要がありますあまりにも多くの「これはそれよりもコストがかかる」という結論を導きます。また、方法論とは関係なく、1980年代から今日に至るまで、これらのデータの関連性を疑わしいとするツールや手法に変更があったことにも注意してください。
したがって、これらの数値の正当化に問題があると仮定します。
これはソフトウェア開発方法論にどのように影響しますか？
検証できない数字に依存してきたという事実は、人々が逸話や経験に基づいて進歩を遂げることを止めませんでした。多くの主弟子の取引が学んだのと同じ方法です。中世にはJournal of Evidence-Based Masonryはなかったと思いますが、大きくて印象的で長持ちする建物がたくさんありますそれにもかかわらず、ある程度の成功を収めて建設されました。それが意味することは、私たちの実践は主に「私または私が会った人々のために何がうまくいったか」に基づいているということです。悪いことではありませんが、現在の技術時代の基礎を提供する何百万もの人々の分野を改善する最も効率的な方法ではないかもしれません。
いわゆるエンジニアリングの分野では経験主義の基盤がよくないことに失望していると思います。私は（明らかに証明することはできませんが）技術と方法論の改善でより明確な進歩を遂げることができると疑っていますその基盤が整っている-臨床医学が証拠に基づく実践によって変容されたように見えるのと同じように。ただし、これはいくつかの大きな仮定に基づいています。
- ほとんどのソフトウェアエンジニアリング業務の独占的性質は、十分な有用で関連性のあるデータの収集を妨げるものではないこと。
- これらのデータから導き出された結論は、一般に適用されます（ソフトウェアエンジニアリングは熟練した職業であり、経験、能力、および好みの個人的な差異がそのような適用性に影響を与える可能性があるため）。
- 「現場」のソフトウェアエンジニアは、このようにして得られた結果を利用する能力と動機付けがあること。そして
- そもそもどんな質問をするべきかを実際に知っているということです。これが明らかにここで最大のポイントです。ソフトウェアエンジニアリングについて改善について話すとき、何を改善したいですか？測定は何ですか？その測定を改善することは実際に結果を改善しますか、それともシステムをゲームしますか？例として、実際のプロジェクトコストと予測プロジェクトコストの比率を下げることを会社の経営陣が決定したと仮定します。すべてのコスト見積もりにファッジファクターを掛け始めるだけで、その「目標」を達成できます。それから、すべての見積もりをだますのは標準的な業界慣行になるべきでしょうか？
私の場合、「これがソフトウェア開発方法にどのように影響するか」に対する答えは「それほど多くない」です。
開発者またはエンドユーザーがキャッチしたかどうか、ユーザーがキャッチした後で修正するのにより多くの費用がかかるかどうかに関係なく、システムにバグが見つかったという事実が残っています。開発者に捕まればうまくいけばこれは簡単な修正です。同じ希望は、ユーザーが見つけたバグにも当てはまります。
エンドユーザーが見つけたバグを修正するための実際の開発者時間のコストに関係なく、コーダーが何をするのかを理解するステレオタイプを維持するための無形のコストがあります。ユーザーがバグを見つけたら、それは開発者の責任です。したがって、エンドユーザーが見つけたバグごとに、システムに対するユーザーの信頼が低下します。それは、購入したい家を巡って、家の片隅の天井から水が染み出るのを見るようなものです。それ自体は簡単な修正ですが、何が原因で、他に根本的な原因が何に影響したのか疑問に思います。あなたの心の安らぎは何ですか？壁をスタッドに引き裂き、すべてを視覚的に検査して、修正された孤立したインシデントによる汚れであることを確認する必要がある場合があります。それが可能性があるかもしれないことを知っていても、あなたは家に自信が持てません。同様に、ソフトウェアを作成した開発者がこの非常に明白な（あなたにとって）表面的な欠陥を見逃した場合、何が悪いのでしょうか。
これらの無形のコストは、バグが発見されるとすぐに回避されます。これは、TDDスタイルの方法論の明記された目的です。開発者またはパートナーがペアでタイピング中に検出したバグ、コンパイル時に検出したバグ、またはユニット/統合テスト（TDDによって追加されたレイヤー）によって検出されたバグは、ユーザーが知る必要のないバグであり、プロジェクトマネージャーは謝罪する必要はありません。また、数週間残したと思っていたシステムの一部でギアを欠陥修正モードに切り替えるために、この1秒間に何をしている必要もありません。前。
私がこれで見つけたもののほとんどが1970年代から1980年代初頭にかけてのものであるという事実を前置きするつもりです。この間、逐次プロセスモデルは、反復および/または増分アプローチ（スパイラルモデルまたはアジャイルメソッド）よりもはるかに一般的でした。この作業の多くは、これらの順次モデルに基づいて構築されています。しかし、それが関係を破壊することはないと思いますが、反復/増分アプローチの利点の1つは、機能（アプリケーションの垂直スライス全体）をすばやくリリースし、依存関係が注入される前に問題を修正し、各フェーズの複雑さを修正することですは高い。
私は Software Engineering Economics のコピーを取り出し、第4章でこのグラフの背後にあるデータへの参照を見つけました。彼はME Faganによる「プログラム開発のエラーを減らすための設計とコード検査」を引用しています（- [〜＃〜] ieee [〜＃〜] 、 MDからのPDF ）、EBダリーの「ソフトウェアエンジニアリングの管理」、W.E。スティーブンソンの「Safeguardシステムソフトウェア開発で使用されるリソースの分析」（ [〜＃〜] acm [〜＃〜] ）、および「いくつかのTRWプロジェクト」。
...修正または変更が行われるフェーズの関数としての、ソフトウェアエラーの修正（または他のソフトウェアの変更）の相対コスト。計画および要件フェーズ中にソフトウェア要件エラーが検出されて修正された場合、その修正は、要件仕様の更新という比較的単純な問題です。メンテナンスフェーズまで同じエラーが修正されない場合、修正には、仕様、コード、ユーザーおよびメンテナンスマニュアル、トレーニング資料のはるかに多くの在庫が含まれます。
さらに、後の修正には、より正式な変更の承認と制御のプロセス、および修正を再検証するためのはるかに広範なアクティビティが含まれます。これらの要因が組み合わさって、エラーは通常、要件フェーズよりも大規模プロジェクトのメンテナンスフェーズで100倍費用が高くなります。
Bohemはまた、2つの小規模で正式ではないプロジェクトを調べたところ、コストの増加が見られましたが、大規模プロジェクトで特定された100倍よりもはるかに重要性は低くなっています。グラフを見ると、システムの運用後は、要件フェーズよりも要件の欠陥を修正する方が4倍の差があるように見えます。彼は、これはプロジェクトを構成するアイテムの在庫が少ないことと、簡素化された修正をより速く実装する能力につながった正式性の低下に起因すると考えています。
Software Engineering EconomicsのBoehmに基づくと、Code Completeのテーブルはかなり肥大化しています（範囲の下限が高すぎることがよくあります）。フェーズ内で変更を行うためのコストは確かに1です。ソフトウェアエンジニアリングの経済学の図4-2から推定すると、要件の変更は、アーキテクチャで1.5〜2.5倍、コーディングで2.5〜10、テストで4〜20、および4〜 100メンテナンス中。量は、プロジェクトのサイズと複雑さ、および使用されるプロセスの形式によって異なります。
バリーベームとリチャードターナーの付録Eにある バランスの取れた敏捷性と規律 には、変更のコストに関する経験的調査結果に関する小さなセクションが含まれています。
冒頭の段落では、ベックを引用して、ケントベックのエクストリームプログラミングの説明を引用しています。変更のコストが時間の経過とともにゆっくりと上昇した場合、決定はできるだけ遅く行われ、必要なものだけが実装されると述べています。これは「フラットカーブ」と呼ばれ、エクストリームプログラミングの原動力となっています。ただし、以前の文献で発見されたのは「急カーブ」であり、小さなシステム（<5 KSLOC）で5：1の変化があり、大きなシステムでは100：1の変化があります。
このセクションでは、メリーランド大学の経験ベースのソフトウェアエンジニアリングセンター（全米科学財団の後援）を引用しています。彼らは利用可能な文献の検索を実行し、結果が100：1の比率を確認する傾向があることを発見しました、いくつかの結果は70：1から125：1の範囲を示しています。残念なことに、これらは通常「前もって大きな設計」プロジェクトであり、順次管理されていました。
Extreme Programmingを使用して実行された「小規模なコマーシャルJavaプロジェクト）」のサンプルがあります。各ストーリーについて、エラーの修正、新しいデザイン、およびリファクタリングの労力が追跡されました。データは、システムが開発され（より多くのユーザーストーリーが実装されます）、平均的な労力は重要な割合で増加する傾向にあり、リファクタリングの労力は約5％増加し、労力の修正への努力は約4％増加します。
私が学んでいることは、システムの複雑さが必要な労力の量に大きな役割を果たすことです。システムに垂直スライスを構築することにより、複雑さを重ねるのではなくゆっくりと追加して、曲線の速度を遅くします。非常に複雑なアーキテクチャが続き、その後に非常に複雑な実装が続くなど、要件の複雑さの大量に対処するのではなく、非常に単純に開始してアドオンします。
これは修正コストにどのような影響がありますか？結局、それほどではないでしょう。ただし、（技術的負債の管理を通じて）複雑さをさらに制御できるという利点があります。さらに、頻繁にアジャイルに関連付けられる成果物は、プロジェクトがより早く終了する可能性があることを意味します。「システム」を提供するのではなく、ビジネスニーズが満たされるか、新しいシステム（したがって、新しいプロジェクト）が大幅に変更されるまで、断片が提供されます。必要です。
Stephen Kanの ソフトウェア品質工学における測定基準とモデル は、第6章にフェーズ欠陥の除去の費用対効果に関するセクションがあります。
彼はまず、Faganの1976年の論文（ソフトウェアエンジニアリングの経済学でも引用）を引用して、高レベルの設計（システムアーキテクチャ）、低レベルの設計（詳細な設計）、および実装を10〜100分の1程度安価にできると述べました。コンポーネントおよびシステムレベルのテスト中に行われる作業よりも。
彼はまた、大規模システムについて論じているフリードマンとウェインバーグによる1982年と1984年の2つの出版物を引用しています。 1つは「ウォークスルー、検査、およびテクニカルレビューのハンドブック」で、2つ目は「レビュー、ウォークスルー、および検査」です。開発サイクルの早い段階でレビューを適用すると、テストフェーズに到達するエラーの数を10分の1に減らすことができます。この欠陥の数を減らすと、テストコストが50〜80％削減されます。調査をもっと詳しく読む必要がありますが、コストには欠陥の発見と修正も含まれているようです。
Remusによる1983年の調査「検査/レビューの観点での統合ソフトウェア検証」では、カリフォルニアのIBMサンタテレサ研究所のデータを使用して、さまざまなフェーズ、特に設計/コードの検査、テスト、およびメンテナンスで欠陥を取り除くコストを調査しました。引用された結果は、1：20：82のコスト比を示しています。つまり、設計またはコードの検査で見つかった欠陥の変更コストは1です。同じ欠陥がテストに脱出すると、20倍のコストがかかります。それがユーザーの手に渡る場合、修正コストは最大82倍になります。Kanは、IBMのロチェスター、ミネソタの施設からのサンプルデータを使用して、AS/400プロジェクトの欠陥除去コストが同様であることを発見しました1:13:92。ただし、コストの増加は、欠陥を見つけるのが難しくなるためと指摘している。
Gilbのソフトウェア検査に関する1993（ "Software Inspection" ）および1999（ "Optimizing Software Engineering Specification and Quality Control Processes"）の出版物は、他の研究を裏付けるために言及されています。
追加情報は、Construxの Defect Cost Growth のページにあります。このページには、欠陥修復コストの増加に関する参考資料がいくつかあります。 Code Completeの作者であるSteve McConnellがConstruxを設立し、働いていることに注意してください。
私は最近 講演、Real Software Engineering を聴きました Glenn Vanderburg によってLone StarでRuby 2010年の会議。彼は同じことを与えられました Scottish Ruby Conference and Erubycon in 2011、 QCon San Francisco in 2012 および 2015年のO'Reilly Software Architecture Conference 。私はLone Starのみを聴きましたRuby Conferenceですが、彼のアイデアが洗練されるにつれて、話は時間とともに進化しました。
ベンダーバーグは、この履歴データのすべてが、プロジェクトがフェーズを通過するのではなく、時間の経過とともに欠陥を修正するためのコストを実際に示していることを示唆しています。前述の論文や書籍で検討されたプロジェクトの多くは、段階と時間が一緒に動く連続した「ウォーターフォール」プロジェクトでした。ただし、同様のパターンが反復および増分プロジェクトで出現します-欠陥が1つの反復で注入された場合、その反復で修正することは比較的安価です。ただし、反復が進むにつれて、多くのことが起こります。ソフトウェアがより複雑になり、特定のモジュールまたはコードの一部での作業に関する細かい詳細の一部を忘れ、要件が変更されます。これらはすべて、欠陥を修正するコストを増加させます。
これはおそらく現実に近いと思います。ウォーターフォールプロジェクトでは、上流の問題のために修正する必要があるアーティファクトの量が原因で、コストが増加します。反復および増分プロジェクトでは、ソフトウェアの複雑さが増すため、コストが増加します。
その単純なロジック。
仕様でエラーが検出されました。
Case : Error found while reviewing UseCase/Function spec.
Actions:
Rewrite paragraph in error.
Case : Error found during unit test.
Actions:
Fix code.
(Possibly) rewrite paragraph in spec.
rerun unit test.
Case : Error found in integration test.
Fix code.
(possibly) rewrite paragraph in spec.
rerun unit test.
build new release.
rerun integration test for whole system.
Case : Error found in UAT
Fix code.
(possibly) rewrite paragraph in spec.
rerun unit test.
build new release.
rerun integration test for whole system.
deploy release to UAT.
rerun UAT tests.
Case : Error found in production
Fix code.
(possibly) rewrite paragraph in spec.
rerun unit test.
Build release.
rerun integration test for whole system.
deploy release to UAT.
rerun UAT tests.
deploy release to production.
後でわかるように、エラーが検出されると、関与する人が増えるほど、より多くの作業をやり直す必要があり、「通常の」環境では、UATにアクセスすると、事務処理と官僚制が指数関数的に増加します。
これはすべて、生産ソフトウェアのエラー（販売の損失、注文過剰、顧客のハッキングなど）によってビジネスが被る可能性があるコストを含まずに行われます。
本番環境でバグが発生したことがないような自明ではないシステムを作成した人はいないと思いますが、バグを早期に発見するためにできることなら、長期的には時間と労力を節約できます。仕様レビュー、コードレビュー、広範な単体テスト、さまざまなコーダーを使用してテストなどを記述することはすべて、バグを早期に発見する実証済みの方法です。
これは、リスク管理と経済学に関するものであり、常にそうであったと私は信じています。欠陥の数と将来の欠陥の影響の現在の値を削減するコストはどのくらいですか。 Angry Birdsで黄色の鳥が少し離れている軌道は、トマホークの巡航ミサイルが離れている軌道と同じではありません。どちらのプロジェクトのソフトウェア開発者も、この表に基づいて決定を下すことはできません。この点で、何も変更されません。
これがうまく機能する傾向があると私が思う方法は、現場での高価なバグにより企業が品質プロセスを強化する一方で、現場からの苦情が企業にそれを緩和させることはありません。そのため、時間の経過とともに、ソフトウェア開発会社は、自分たちにとって有効なもの（+/-）を中心に収束または変動する傾向があります。 Code Completeは、いくつかの初期値に影響を与えたり、会社を少しずつ引っ張ったりする可能性があります。誰も気付かないような欠陥の除去にあまりにも多くの労力を費やしている企業は、より最適化されたアプローチをとっている競合他社にビジネスを失うでしょう。一方、バグのある製品をリリースしている会社も廃業します。
クイック検索からのいくつかの関連論文（論文全体を読み、より多くの研究を行い、そしてあなた自身の意見を形成してください）：
ソフトウェア品質コスト調査の体系的な文献レビュー（2011）
「コミュニティはこのように研究ドメインの構造について十分な理解を深めていますが、実証的な検証はしばしば欠けています。分析された記事の約3分の1だけがケーススタディまたはより広範な実証結果を提示しています。これはソフトウェア品質コスト研究には不十分であるようです。 。これは、定量的データに強く依存して新しい発見を生み出します。したがって、品質コストデータを収集するための斬新なアプローチと、そのようなデータを利用可能にするための業界と研究間のより強力な協力が必要です。」
「最後に、ソフトウェアの総コストを削減するために適合ポリシーを調整できるように、ソフトウェアの適合コストと非適合コストを監視することが重要であることがわかりました。」
要約...「現在の調査では、欠陥とその修正（または未修正のまま）の費用がソフトウェアの最終的なコストに影響する方法についての知識を更新しようとしています」...「修正されていない欠陥は指数関数的にコストが高くなります。それらが未解決の各フェーズで」
テストカバレッジと検証後の欠陥：複数のケーススタディ（2009）
「また、テスト範囲はテストカバレッジとともに指数関数的に増加しますが、フィールドの問題の減少はテストカバレッジとともに直線的に増加します。これは、ほとんどのプロジェクトでカバレッジの最適レベルが100％に十分に及ばないことを示唆しています。」
確認していませんので、質問の最初の部分にはお答えできません。しかし、私はあなたの2番目の質問に対する答えを作成し、おそらく最初の質問に対する可能な答えを示唆することができます。
言うまでもなく、バグの修正にかかるコストで最も重要な要素は、本質的に開発ツールの使用が難しいことを除けば、製品の本質的な複雑さと、ユーザーがその製品をどの程度理解できるかです。
コードに少し焦点を合わせると、コードは通常、コードの本質的な複雑さ（完全に真実ではない可能性があり、独自の議論に値する可能性がある）に対処できる開発者によって記述および保守されるという前提の下で、メンテナンスにおける、したがってバグの修正における重大な重要性は、メンテナが理解と言ったコードを実行する能力です。
コードを理解する能力は、残念ながら、ほとんどが不十分または不適切に使用されている実績のあるソフトウェアエンジニアリングツールを使用することで大幅に強化されます。適切なレベルの抽象化、モジュール性を使用し、モジュールの結合を強化し、モジュールの結合を減らすことは、適切な使用を必要とする複雑さに対処するための重要なツールです。インターフェイスへのコーディング、またはOOPでは、構成による継承の過剰な使用を回避し、機能ごとにパッケージ化することは、コーディングで十分に注意が払われていない技法の一部です。
業界での競争の現実は、ソフトウェアを開発するための品質向上方法の採用にマイナスの影響を与え、継続的な成功の尺度としてソフトウェアの本質的な品質を低く保つと考えています。
したがって、業界では、ソフトウェアが大きくなるほどバグ修正コストの影響を受ける傾向があると私は信じています。このような製品では、システムが成長するにつれてシステムが理解しにくくなるため、バグは時間の経過とともに修正することが難しくなります。各機能によってもたらされる懸念は他の懸念と過度に結びついており、理解を困難にします。または、適切なレベルの抽象化が採用されていなかったため、メンテナがシステムの適切なモデルを策定し、それについて推論することが困難になりました。ドキュメントの欠如は確かに助けにはなりません。
例外があります。 Googleは、優れた開発者によって支持されている確かな実践がなければ、そのペースで機能していないと思います。そして、他の人も同じ状況にある可能性があります。しかし、ソフトウェアの大部分では、データdidが実際にCode Completeの主張を確認しても驚かないでしょう。