ソフトウェアのバグ

ソフトウェアのバグとは、コンピュータソフトウェアの欠陥（バグ）のことです。多数のバグや深刻なバグを持つコンピュータプログラムは、バグが多いと表現されることがあります。

ソフトウェア バグの影響は、軽微なもの (ユーザー インターフェイスでの単語のスペルミスなど) から重大なもの (頻繁なクラッシュなど) まで多岐にわたります。

2002年に米国商務省国立標準技術研究所が委託した調査では、「ソフトウェアのバグやエラーは非常に蔓延しており、非常に有害であるため、米国経済に年間推定590億ドル、国内総生産の約0.6％の損失をもたらしている」と結論付けました。[ 1 ]

1950 年代以降、一部のコンピュータ システムは、操作中にさまざまなソフトウェア エラーを検出したり自動修正したりするように設計されてきました。

歴史

用語

ミス・メタモーフィズム（ギリシャ語の「メタ＝変化」と「モルフ＝形成」に由来）とは、ソフトウェア展開の最終段階における欠陥の進化を指します。ソフトウェア開発ライフサイクルの初期段階でアナリストが犯したミスが、サイクルの最終段階で欠陥へと変化することをミス・メタモーフィズムと呼びます。[ 2 ]

開発サイクルにおけるミスの様々な段階は、ミス、[ 3 ] : 31 異常、[ 3 ] : 10 障害、[ 3 ] : 31 失敗、[ 3 ] : 31 エラー、[ 3 ] : 31 例外、[ 3 ] : 31 クラッシュ、[ 3 ] : 22 グリッチ、バグ、[ 3 ] : 14 欠陥、インシデント、[ 3 ] : 39 または副作用として 説明される場合があります。

例

ソフトウェアのバグは災害につながることがある。

論争

ソフトウェアの挙動を説明する際に「バグ」という言葉を使うことは、認識の違いから議論を呼ぶことがあります。「バグ」という言葉は欠陥が自ら発生したことを意味するため、この用語の使用を中止し、人間によって引き起こされたことを明確に示す「欠陥」という言葉を使うべきだと主張する人もいます。[ 8 ]

このバグは意図的な設計上の決定を隠蔽するために利用されている可能性があると主張する人もいます。2011年、ユーザーの位置情報を暗号化されていないファイルに記録・保存していたとして、アル・フランケン上院議員から調査を受けた後、 [ 9 ] Appleはこれをバグと呼びました。しかし、民主主義と技術センターのジャスティン・ブルックマン氏は、この解釈に真っ向から異議を唱え、「彼らがバグと呼ぶものを修正しているのは喜ばしいことですが、ユーザーを追跡していることを強く否定していることには異議を唱えます」と述べています。[ 10 ]

防止

フランスのラ・クロワ・ド・ベルニー駅の2つの画面に表示されたソフトウェアのバグによるエラー

ソフトウェア開発プロセスのできるだけ早い段階でバグを防ぐことは、投資とイノベーションの目標です。[ 11 ] [ 12 ]

言語サポート

新しいプログラミング言語は、既存の言語の脆弱性に基づいて、一般的なバグを防ぐように設計される傾向があります。BASICやCなどの古い言語から得られた教訓は、 C#やRustなどの後発言語の設計に活かされています。

コンパイル言語では、インタープリタ言語よりもソフトウェア開発プロセスの早い段階で、実行前にいくつかのタイプミス (スペルミスのある識別子など) を検出できます。

言語には、静的型システム、制限された名前空間、モジュールプログラミングなどの機能が含まれる場合があります。例えば、型付けされたコンパイル言語（Cなど）の場合： 

浮動小数点数値 = "3";

構文的には正しいものの、右側の文字列をfloat型変数に代入できないため、型チェックに失敗します。コンパイルに失敗し、開発を再開する前にこの欠陥を修正する必要があります。インタプリタ型言語では、このエラーは実行時以降に発生します。

一部の言語では、パフォーマンスの低下を犠牲にして、バグが発生しやすい機能を除外しています。これは、複雑でバグの多いコードよりも、シンプルで遅くても正しいコードを書く方が一般的に優れているという原則に基づいています。例えば、Javaはポインタ演算をサポートしていません。ポインタ演算は非常に高速ですが、十分に注意して使用しないとメモリ破損やセグメンテーション違反を引き起こす可能性があります。

一部の言語には、一般的なバグを防ぐために実行時にオーバーヘッドを追加する機能が含まれています。例えば、多くの言語には実行時の境界チェック機能や、境界外エラーが発生した場合にクラッシュせずに回復する機能が含まれています。

テクニック

スタイル ガイドラインと防御的プログラミングにより、見逃しやすい誤植 (タイプミス) を防ぐことができます。

例えば、ほとんどのC言語系プログラミング言語では、命令が1つしかない場合、命令ブロックを囲む中括弧を省略できます。次のコードは、が真のfoo場合にのみ関数を実行しますcondition。 

if (条件) foo();

しかし、このコードは常に実行されますfoo: 

if (条件); foo();

厳密に必要ではない場合でも中括弧を使用すると、このエラーを確実に防ぐことができます。 

if (条件) { foo(); }

規則の強制は、手動で行う場合（コードレビューなど）、またはリンターなどの自動化ツールを介して行う場合があります。

仕様

プログラムの意図された動作を記述するプログラム仕様を記述することでバグを防止できると主張する人もいます。しかし、組み合わせ爆発や不確定性の問題があるため、形式仕様は最短のプログラム以外では実用的ではないと主張する人もいます。

ソフトウェアテスト

ソフトウェアテストの目標の一つはバグを見つけることです。テスト中の測定によって、残存する可能性のあるバグの数を推定できます。製品のテストと開発期間が長くなるほど、この推定値の信頼性は高まります。

アジャイルプラクティス

アジャイルソフトウェア開発では、比較的小さな変更を伴うソフトウェアリリースが頻繁に行われることがあります。欠陥はユーザーからのフィードバックによって発見されます。

テスト駆動開発(TDD)では、製品コードの作成中にユニット テストが作成され、すべてのテストが記述されて正常に完了するまで、製品コードは完了したとは見なされません。

静的解析

静的コード解析ツールは、コンパイラの能力を超えてプログラムテキストを検査し、潜在的な問題を発見することで開発者を支援します。仕様が与えられた場合、すべてのプログラミングエラーを見つけるという問題は一般的に解決不可能ですが（停止問題を参照）、これらのツールは、人間のプログラマーがソフトウェアを作成する際に特定の種類の単純なミスを犯しやすいという事実を利用しています。

計装

ソフトウェアの実行中のパフォーマンスを監視するツールは、ボトルネックなどの問題を発見するため、あるいは正しく動作していることを保証するために、コードに明示的に埋め込まれる場合（おそらく「」という単純な文のようにPRINT "I AM HERE"）、あるいはツールとして提供される場合があります。時間の大半がコードの一部に費やされていることに気づくのは意外な場合が多く、こうした前提の排除によってコードの書き直しが必要になることもあります。

オープンソース

オープンソース開発では、誰でもソースコードを検査することができます。エリック・S・レイモンドがリーナスの法則として普及させた考え方では、人気のあるオープンソースソフトウェアは、他のソフトウェアよりもバグがほとんどないか全くない可能性が高いとされています。これは、「十分な数の目があれば、すべてのバグは浅い」ためです。[ 13 ]しかし、この主張には異論があります。コンピュータセキュリティの専門家であるエリアス・レヴィは、「複雑で、ほとんど理解されておらず、文書化されていないソースコードでは、脆弱性を隠すのは簡単です」と述べています。なぜなら、「たとえ人々がコードをレビューしていたとしても、それがその資格があるという意味ではないからです。」[ 14 ]オープンソースソフトウェアのバグの例として、2008年にDebianで発見されたOpenSSLの脆弱性が挙げられます。

デバッグ

デバッグはソフトウェア開発ライフサイクルの重要な部分を占めることがあります。初期のコンピュータ技術のパイオニアであるモーリス・ウィルクスは、1940年代後半に「残りの人生の大部分は、自分のプログラムのエラーを見つけることに費やされるだろう」と悟ったと述べています。[ 15 ]

通常、バグを見つけるための最初のステップは、確実に再現することです。問題を再現できない場合、プログラマーはバグの原因を特定できず、修正できません。

再現が困難な入力によってバグが明らかになることもあります。Therac -25放射線治療装置の故障原因の一つは、治療計画を非常に速く入力した際にのみ発生するバグ（具体的には競合状態）でした。この操作を習得するには数日間の練習が必要だったため、テストやメーカーによる再現試行ではバグは現れませんでした。また、プログラムをデバッガーで実行するなど、バグの発見を容易にするために設定を拡張すると、バグが発生しなくなる場合もあります。これらはハイゼンバグ（ハイゼンベルクの不確定性原理にちなんでユーモラスに名付けられました）と呼ばれます。

バグは、単独の欠陥ではなく、プログラマーの思考や計画の誤りを表す場合もあります。多くの場合、このような論理エラーは、プログラムの一部を徹底的に見直したり書き直したりすることを必要とします。このプロセスは、コードリファクタリングと呼ばれます。

コードレビューでは、コードをステップ実行して実行プロセスを想像または書き写しますが、バグそのものを再現しなくてもエラーが見つかることがよくあります。

デバッガーと呼ばれるプログラムは、コードを 1 行ずつ実行したり変数の値を表示したりしてプログラムの内部動作を調べることにより、プログラマーが問題のあるコードを見つけるのに役立ちます。

デバッガを使用する代わりに、デバッグ情報を出力するロジックをコードに組み込むことで、プログラム実行をトレースし、値を確認することができます。出力は通常、コンソール、ウィンドウ、ログファイル、またはハードウェア出力（インジケータLEDを駆動する場合もあります）に行われます。

1990年代以降、特にアリアン5便501便の事故以降、抽象解釈による静的コード解析など、デバッグの自動化支援への関心が高まりました。[ 16 ]

組み込みシステムでは、ハードウェアを変更するよりもソフトウェアを変更する方が安価で混乱も少ないため、ハードウェアのバグを 回避するためにソフトウェアが変更されることがよくあります。

管理

バグ履歴の例（GNU Classpathプロジェクトデータ）。新しいバグは最初は「未確認」です。再現されると、 「確認済み」に変更されます。問題が解決されると、 「修正済み」に変更されます。

バグは、文書化、分類、割り当て、再現、修正、修正されたコードのリリースなどのアクティビティを通じて管理されます。

ツールは、ソフトウェアのバグやその他の問題を追跡するためによく使用されます。通常、ソフトウェア開発チームがワークロードを追跡するツールと、カスタマーサービスがユーザーからのフィードバックを追跡するツールでは、異なるツールが使用されます。[ 17 ]

追跡対象項目は、バグ、欠陥、チケット、問題、機能、あるいはアジャイルソフトウェア開発ではストーリーやエピックと呼ばれることがよくあります。項目は、重大度、優先度、影響を受けるバージョン番号などの側面によって分類されることがよくあります。

トリアージと呼ばれるプロセスでは、バグの重大度や優先度、開発スケジュールなどの外部要因に基づいて、各バグについて修正の有無と時期を決定します。トリアージには通常、原因の調査は含まれません。トリアージは定期的に実施され、少なくとも前回のトリアージ以降に発生した新しいバグの確認から構成され、場合によってはすべての未解決のバグにまで及ぶこともあります。参加者には、プロジェクトマネージャー、開発マネージャー、テストマネージャー、ビルドマネージャー、技術専門家などが含まれます。[ 18 ] [ 19 ]

重大度

重大度は、バグが与える影響の尺度です。[ 20 ]この影響には、データ損失、財務、信用の失墜、無駄な労力などがあります。重大度レベルは標準化されておらず、業種や追跡ツールなどのコンテキストによって異なります。たとえば、ビデオゲームのクラッシュと銀行のサーバーのクラッシュでは影響が異なります。重大度レベルの説明の例には、クラッシュまたはハング、回避策なし（ユーザーはタスクを達成できない）、回避策あり（ユーザーはまだタスクを達成できる）、視覚的な欠陥（スペルミスなど）、ドキュメントエラーなどがあります。重大度の別の例には、クリティカル、高、低、ブロッカー、トリビアルなどがあります。[ 21 ]バグの重大度は、修正の優先度と同じカテゴリになることもあれば、2 つが定量化されて別々に管理されることもあります。

製品のリリースを遅らせるほど重大なバグはショーストッパーと呼ばれます。[ 22 ] [ 23 ]

優先度

優先度は、他のバグと比較して、そのバグを解決する重要性を表します。優先度は、1から5などの数値、または「critical（重大）、high（高）、low（低）、deferred（延期）」などの名前で表されます。優先度は重大度評価と異なる側面を持つものの、値は重大度評価と類似または同一になる場合があります。

優先度は、バグの重大度と修正にかかる労力レベルの組み合わせで決定されます。重大度は低いものの修正が容易なバグは、重大度が中程度で修正に多大な労力を要するバグよりも高い優先度が付けられる場合があります。

パッチ

優先度の高いバグについては、それを修正するための特別なリリースが必要になる場合があります。このようなリリースはパッチと呼ばれることもあります。

メンテナンスリリース

バグ修正を重視したソフトウェア リリースは、新機能やその他の変更を重視したリリースと区別するために、 メンテナンスリリースと呼ばれることがあります。

既知の問題

既知の低優先度のバグやその他の問題を抱えたままソフトウェアをリリースすることはよくあることです。考えられる理由としては、以下のようなものが挙げられますが、これらに限定されるわけではありません。

  • 期限を守らなければならないが、期限までにすべてのバグを修正するにはリソースが不足している[ 24 ]
  • このバグは今後のリリースですでに修正されており、優先度は高くありません。
  • バグを修正するために必要な変更はコストがかかりすぎたり、他の多くのコンポーネントに影響を与えたりして、大規模なテスト活動が必要になる
  • 問題は、今後のリリースで廃止される領域にあるため、修正する必要はありません。

意味合い

ソフトウェアのバグが引き起こす損害の規模と種類は、ソフトウェアの品質に関する意思決定、プロセス、ポリシーに影響を与えます。有人宇宙飛行、航空、原子力、医療、公共交通機関、自動車の安全性といった分野では、ソフトウェアの欠陥が人身事故や死亡につながる可能性があるため、オンラインショッピングサイトなどよりもはるかに厳格な監視と品質管理が行われます。銀行業務などの分野では、ソフトウェアの欠陥が銀行やその顧客に深刻な経済的損害をもたらす可能性があるため、写真編集アプリケーションなどよりも品質管理が重要です。

バグによって引き起こされる損害以外にも、バグ修正に費やされた労力もコストの一部を占めます。1978年、Lientzらは、プロジェクトの中央値が開発労力の17%をバグ修正に費やしていることを示しました。[ 26 ] 2020年のGitHubリポジトリに関する調査では、中央値は20%であることが示されました。[ 27 ]

料金

1994年、NASAゴダード宇宙飛行センターは、平均エラー数を1,000行コード（SLOC）あたり4.5個から1,000行コードあたり1個に削減することに成功しました。[ 28 ]

1990年の別の研究では、非常に優れたソフトウェア開発プロセスでは、1000 SLOCあたり0.1という低いデプロイメント障害率を達成できることが報告されています。[ 29 ]この数字は、スティーブ・マッコーネルのCode Complete、[ 30 ]やNASAのFlight Software Complexityに関する研究などの文献でも繰り返されています。[ 31 ]一部のプロジェクトでは、欠陥ゼロを達成しました。63,000 SLOCのIBM Wheelwriterタイプライターのファームウェアや、500,000 SLOCのスペースシャトルソフトウェアなどです。 [ 29 ]

ベンチマーク

テストとデバッグに関する再現可能な研究を促進するために、研究者はバグの厳選されたベンチマークを使用します。

  • シーメンスのベンチマーク
  • ManyBugs [ 32 ]は9つのオープンソースプログラムの185個のCバグのベンチマークである。
  • Defects4J [ 33 ]は、5つのオープンソースプロジェクトの341個のJavaバグをベンチマークしたツールです。対応するパッチが含まれており、様々な種類のパッチをカバーしています。

種類

注目すべきバグの種類:

設計ミス

バグは、仕様に基づいた設計が不十分であったり、不適切であったりすることで発生する可能性があります。例えば、仕様が単語のリストをアルファベット順に並べることである場合、記号を考慮していない設計によって記号を含む単語が誤ってアルファベット順に並べられてしまうと、設計上のバグが発生する可能性があります。

算術

数値演算は予期しない出力、処理の遅延、クラッシュを引き起こす可能性があります。[ 34 ] このようなバグは、丸めによる精度の低下、数値的に不安定なアルゴリズム、算術オーバーフローとアンダーフローなど、データストレージの品質に関する認識不足から発生する可能性があります。また、ゼロ除算など、一部の言語では例外がスローされ、他の言語ではNaNや無限大などの特殊な値が返されるなど、さまざまなソフトウェアコーディング言語で計算がどのように処理されるかについての認識不足から発生する可能性があります。

制御フロー

制御フローバグ、または論理エラーは、無限ループ、無限再帰、誤った比較演算子の使用などの条件での誤った比較、オフバイワン エラーなど、エラーで失敗しないものの、期待どおりの動作をしないコードによって特徴付けられます。

インターフェース

同時実行性

リソースの確保

構文

  • 等価性テストの代わりに代入を実行するなど、誤ったトークンの使用。例えば、一部の言語では x=5 は x の値を 5 に設定しますが、 x==5 は x が現在 5 か他の数値かを確認します。インタープリタ型言語ではこのようなコードは失敗します。コンパイル型言語では、テスト開始前にこのようなエラーを検出できます。

チームワーク

  • 伝播されない更新：例えば、プログラマーが「myAdd」を変更したが、同じアルゴリズムを使用する「mySubtract」の変更を忘れた場合などです。こうしたエラーは、「Don't Repeat Yourself（同じことを繰り返さない）」という理念によって軽減されます。
  • コメントが古くなっているか不正確: 多くのプログラマーは、コメントがコードを正確に説明していると想定しています。
  • ドキュメントと製品の違い。

政治の世界では

「システムのバグ」レポート

ニュー・アメリカという団体が運営するオープン・テクノロジー・インスティテュート[39]は、2016年8月に報告書「システムのバグ」を発表し、米国の政策立案者は研究者がソフトウェアのバグを特定し、対処できるよう支援するための改革を行うべきだと述べた。この報告書は、「ソフトウェアの脆弱性の発見と開示の分野における改革の必要性を強調している」[ 40 ] 。報告書の著者の一人は、議会がサイバーセキュリティというより大きな問題に対処するための法案を多数可決しているにもかかわらず、サイバーソフトウェアの脆弱性に対処するための十分な対策を講じていないと述べた[ 40 ] 。

ソフトウェアの欠陥を発見するのは、通常、政府の研究者、企業、サイバーセキュリティの専門家です。報告書は、コンピュータ犯罪法と著作権法の改革を求めています。[ 40 ]

報告書によると、コンピュータ詐欺および濫用防止法、デジタルミレニアム著作権法、電子通信プライバシー法は、セキュリティ研究者が合法的なセキュリティ研究を行う際に日常的に行う行為を犯罪とし、民事罰を規定している。[ 40 ]

  • ビデオゲームでは、「グリッチ」という言葉はソフトウェアのバグを指すために使用されることがあります。例としては、グリッチと非公式ポケモンの種族であるMissingNoが挙げられます。
  • 1968年の小説『2001年宇宙の旅』と、それを原作とした同名の映画の両方において、宇宙船の搭載コンピュータHAL9000は乗組員全員の殺害を試みる。1982年の続編小説『2010年宇宙の旅』と、それを原作とした1984年の映画『2010年宇宙の旅』では、この行動はコンピュータが2つの相反する目的、すなわち全ての情報を完全に開示することと、飛行の真の目的を乗組員に秘密にしておくこと、という2つの相反する目的をプログラムされていたために引き起こされたことが明らかにされる。この相反する目的により、HALは妄想症を発症し、最終的には殺人鬼へと変貌を遂げた。
  • ネーナの1983年の曲「99 Luftballons (99 Red Balloons)」の英語版では、「ソフトウェアのバグ」の結果として、99個の赤い風船のグループの放出が敵の核ミサイル発射と誤解され、同等の発射対応が必要となり、大惨事につながるという。
  • 1999 年のアメリカのコメディ映画「オフィス・スペース」では、3 人の社員が、会社の Y2K コンピュータ バグへのこだわりを利用しようとしますが、その際にコンピュータ ウイルスを使って、端数を切り捨てて 1 セント硬貨を銀行口座に送金します。これはサラミ スライスと呼ばれる昔から知られている手法です。
  • 2004年にエレン・ウルマンが書いた小説『ザ・バグ』は、データベースアプリケーションの見つけにくいバグを見つけようとするプログラマーの試みを描いたものです。[ 41 ]
  • 2008 年のカナダ映画「Control Alt Delete」は、1999 年末に会社で 2000 年問題に関連したバグを修正しようと奮闘するコンピュータ プログラマーを描いた物語です。

参照

参考文献

  1. ^ 「ソフトウェアのバグが米国経済に多大な損失をもたらす」 2009年6月10日. 2009年6月10日時点のオリジナルよりアーカイブ。2012年9月24日閲覧。
  2. ^「Testing experience : te : プロフェッショナルテスターのための雑誌」. Testing Experience . ドイツ: testingexperience: 42. 2012年3月. ISSN 1866-5705 . （サブスクリプションが必要です）
  3. ^ a b c d e f g h i 610.12-1990: IEEE標準ソフトウェア工学用語集. IEEE . 1990年12月31日. doi : 10.1109/IEEESTD.1990.101064 . ISBN 978-0-7381-0391-4。
  4. ^ Leveson, Nancy G. ; Turner, Clark S. (1993年7月1日). 「Therac-25事故の調査」 . Computer . 26 ( 7 ). IEEE Computer Society : 18–41 . Bibcode : 1993Compr..26g..18L . doi : 10.1109/MC.1993.274940 . eISSN 1558-0814 . ISSN 0018-9162 . LCCN 74648480. OCLC 2240099. S2CID 9691171 .     
  5. ^ 「アリアン5号501便失敗に関する調査委員会報告書」欧州宇宙機関（ESA）アリアン501調査委員会報告書（33- 1996年）。1996年7月23日。
  6. ^サイモン・ロジャーソン(2002年4月). 「チヌーク・ヘリコプター事故」 . IMISジャーナル. 12 (2) . 2024年5月27日閲覧。{{cite journal}}:|archive-url=形式が正しくありません: タイムスタンプ (ヘルプ) Alt URLCS1 メンテナンス: url-status (リンク)
  7. ^ 「郵便局のスキャンダルで人生が台無しになった、と調査で判明」 BBCニュース、2022年2月14日。
  8. ^ Humphrey, Watts S. (1999年4月1日). 「SEIのニュース – バグか欠陥か？」(PDF) . SEIのニュース. Software Engineering Institute . PDFファイル（154ページ中73ページ）. 2023年10月15日時点のオリジナルよりアーカイブ（PDF） . 2025年2月2日閲覧。（ SEI 1999 アーカイブのニュースからリンク）
  9. ^ Gregg Keizer (2011年4月21日). 「Apple、iPhoneの追跡について議会から質問を受ける」 . Computerworld .
  10. ^ Gregg Keizer (2011年4月27日). 「AppleはiPhoneユーザーの追跡を否定するが、変更を約束」Computerworld .
  11. ^ Dorota Huizinga、Adam Kolawa（2007年9月）。『自動欠陥予防：ソフトウェア管理におけるベストプラクティス』Wiley-IEEE Computer Society Press、ISBN 978-0-470-04212-0。
  12. ^マクドナルド、マーク、ムッソン、ロバート、スミス、ロス (2007). 『欠陥予防の実践ガイド』 マイクロソフトプレス. p.  480. ISBN 978-0-7356-2253-1。
  13. ^「リリースは早く、リリースは頻繁に」 2011年5月14日アーカイブ、Wayback Machine、 Eric S. Raymond、 The Cathedral and the Bazaar
  14. ^「Wide Open Source」 2007年9月29日アーカイブ、 Wayback Machine、 Elias Levy、 SecurityFocus、2000年4月17日
  15. ^ 「モーリス・ウィルクスの名言」 QuoteFancy . 2024年4月28日閲覧。
  16. ^ 「PolySpace Technologiesの歴史」christele.faure.pagesperso-orange.fr . 2019年8月1日閲覧。
  17. ^ Allen, Mitch (2002年5～6月). 「バグトラッキングの基礎：欠陥の報告と追跡に関する初心者向けガイド」 . Software Testing & Quality Engineering Magazine . 第4巻第3号. pp.  20～ 24 . 2017年12月19日閲覧。
  18. ^レックス・ブラック (2002). 『テストプロセスの管理』（第2版）. Wiley India Pvt. Limited. p. 139. ISBN 978-8126503131. 2021年6月19日閲覧。
  19. ^クリス・ヴァンダー・メイ (2012). 『Shipping Greatness: Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon . O'Reilly Media . pp.  79– 81. ISBN 978-1449336608。
  20. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (2020年10月1日). 「ソフトウェアバグトリアージシステムにおける重複バグレポート検出の検証性能向上のための効率的な特徴抽出モデル」 .情報ソフトウェア技術. 126 106344. doi : 10.1016/j.infsof.2020.106344 . S2CID 219733047 . 
  21. ^ 「5.3. バグの解剖学」 . bugzilla.org . 2013年5月23日時点のオリジナルよりアーカイブ。
  22. ^ジョーンズ、ウィルバー・D・ジュニア編 (1989). 「ショーストッパー」用語集：防衛調達の頭字語と用語（第4版）. バージニア州フォートベルボア：国防総省、防衛システム管理大学. p. 123. hdl : 2027/mdp.39015061290758 – Hathitrust経由.
  23. ^ザカリー・G・パスカル (1994). 『ショーストッパー!: マイクロソフトにおけるWindows NTと次世代開発への猛烈な競争』ニューヨーク:ザ・フリー・プレス158ページ. ISBN 0029356717– archive.orgより。
  24. ^「The Next Generation 1996 Lexicon A to Z: Slipstream Release」. Next Generation . 第15号. 1996年3月. 41ページ.
  25. ^カー、ニコラス（2018年）。「これはバグではなく、機能です。」陳腐な表現か、それともちょうど良い表現か？」wired.com
  26. ^ Lientz, BP; Swanson, EB; Tompkins, GE (1978). 「アプリケーションソフトウェア保守の特徴」 . Communications of the ACM . 21 (6): 466– 471. doi : 10.1145/359511.359522 . S2CID 14950091 . 
  27. ^ Amit, Idan; Feitelson, Dror G. (2020). 「修正コミット確率コード品質メトリック」. arXiv : 2007.10912 [ cs.SE ].
  28. ^ 「ソフトウェアエンジニアリングラボの概要」（PDF） .ソフトウェアエンジニアリングラボシリーズ（SEL-94-005）：22293. 1994年12月. Bibcode：1994ntrs.rept22293.
  29. ^ a b Cobb, Richard H.; Mills, Harlan D. (1990). 「統計的品質管理に基づくエンジニアリングソフトウェア」 . IEEE Software . 7 (6): 46. Bibcode : 1990ISoft...7f..45C . doi : 10.1109/52.60601 . ISSN 1937-4194 . S2CID 538311 – テネシー大学 – Harlan D. Mills コレクションより.  
  30. ^ McConnell, Steven C. (1993). Code Complete . Redmond, Washington: Microsoft Press. p. 611. ISBN 978-1556154843– archive.orgより。（コブとミルズ 1990）
  31. ^ Gerard Holzmann (2009年3月5日). 「付録D – ソフトウェアの複雑性」(PDF) .最終報告書: NASAによる飛行ソフトウェアの複雑性に関する調査 (Daniel L. Dvorak (編)) . NASA主任技師局技術優秀プログラム.
  32. ^ Le Goues, Claire ; Holtschulte, Neal ; Smith, Edward K. ; Brun, Yuriy ; Devanbu, Premkumar ; Forrest, Stephanie ; Weimer, Westley (2015). 「Cプログラムの自動修復のためのManyBugsとIntroClassベンチマーク」 IEEE Transactions on Software Engineering . 41 (12): 1236– 1256. Bibcode : 2015ITSEn..41.1236L . doi : 10.1109/TSE.2015.2454513 . ISSN 0098-5589 . 
  33. ^ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). 「Defects4J: Javaプログラムの制御されたテスト研究を可能にする既存障害データベース」. 2014年国際ソフトウェアテスト・分析シンポジウム (ISSTA 2014) の議事録. pp.  437– 440. CiteSeerX 10.1.1.646.3086 . doi : 10.1145/2610384.2628055 . ISBN  9781450326452. S2CID  12796895 .
  34. ^ Anthony Di Franco、Hui Guo、Cindy Rubio-González (2017年11月23日).実世界の数値バグ特性に関する包括的な研究. 2017年第32回IEEE / ACM国際自動ソフトウェアエンジニアリング会議 (ASE). IEEE . doi : 10.1109/ASE.2017.8115662 .
  35. ^キンブラー、K. (1998).電気通信とソフトウェアシステムにおける機能の相互作用 V. IOS Press. p. 8. ISBN 978-90-5199-431-5。
  36. ^ Syed, Mahbubur Ra​​hman (2001).マルチメディアネットワーキング：技術、管理、アプリケーション. Idea Group Inc (IGI). p. 398. ISBN 978-1-59140-005-9。
  37. ^ Wu, Chwan-Hwa (John); Irwin, J. David (2016).コンピュータネットワークとサイバーセキュリティ入門. CRC Press. p. 500. ISBN 978-1-4665-7214-0。
  38. ^ RFC 1263 : 「TCP 拡張機能は有害であると考えられる」からの引用: 「新しいバージョンのプロトコルをすべてのホストに配布するには、かなり長い時間がかかる可能性があります (実際には永遠にかかることもあります)。... 古いバージョンと新しいバージョンの間に少しでも互換性がないと、混乱が生じる可能性があります。」
  39. ^ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. 「システムのバグ」（PDF） . Open Policy Institute . 2016年9月21日時点のオリジナルよりアーカイブ（PDF） . 2016年8月22日閲覧。
  40. ^ a b c d Rozens, Tracy (2016年8月12日). 「ソフトウェアのバグ発見と開示を強化するにはサイバー改革が必要：New Americaレポート - Homeland Preparedness News」 . 2016年8月23日閲覧。
  41. ^ウルマン、エレン (2004)。バグ。ピカドール。ISBN 978-1-250-00249-5。
MediaWikiにはバグ管理に関するドキュメントがあります
「 https://en.wikipedia.org/w/index.php?title=ソフトウェアバグ&oldid= 1335551924」より取得