ソフトウェアのバグ

ソフトウェアのバグとは、コンピューター ソフトウェアの設計、開発、または操作におけるエラー、欠陥、障害のことで、ソフトウェアが誤った結果や予期せぬ結果を生み出したり、意図しない動作を引き起こしたりするものです。バグを見つけて修正するプロセスは「デバッグ」と呼ばれ、多くの場合、バグを正確に特定するために正式な技術やツールが使用されます。 1950 年代以来、一部のコンピュータ システムは、動作中にさまざまなソフトウェア エラーを検出または自動修正するように設計されてきました。

ソフトウェアのバグは、ユーザーの要件の解釈と抽出、プログラム設計の計画、ソース コードの記述、および人間、ハードウェア、およびオペレーティング システムライブラリなどのプログラムとの相互作用で発生する間違いやエラーから発生する可能性があります。多くのバグ、または重大なバグがあるプログラムは、多くの場合、「バグがある」と表現されます。バグは、波及効果をもたらす可能性のあるエラーを引き起こす可能性があります。バグの影響は、意図しないテキストの書式設定などの微妙なものから、プログラムのクラッシュ、コンピュータのフリーズ、ハードウェアの損傷などのより明らかな影響まであります。その他のバグはセキュリティ バグとみなされ、たとえば、悪意のあるユーザーがアクセス制御をバイパスし不正な権限を取得できる可能性があります。[1]

一部のソフトウェアのバグは災害に関連しています。Therac-25 放射線治療装置を制御するコードのバグが、1980 年代の患者死亡の直接の原因でした。 1996 年、欧州宇宙機関の 10 億米ドルの試作型アリアン 5 ロケットは、搭載された誘導コンピュータ プログラムのバグにより、打ち上げ後 1 分も経たないうちに破壊されました。 [2] 1994 年に英国空軍チヌーク ヘリコプターが墜落し、29 名が死亡した。これは当初パイロットのミスによるものと考えられていましたが、後にエンジン制御コンピュータのソフトウェアのバグが原因であると考えられました[3]バグのあるソフトウェアは、21 世紀初頭の英国郵便局スキャンダルを引き起こしました。これは、英国法史上最も広範な誤判です。[4]

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

歴史

中英語のバゲという単語は、モンスターを表す用語として「バグベア」や「バガブー」という用語の基礎となっています。[6]

欠陥を表す「バグ」という用語は、1870 年代から工学用語の一部として使用され[7]、エレクトロニクスやコンピューターよりも前から使われてきました。元々はハードウェア工学で機械の故障を説明するために使用されていたものと考えられます。たとえば、トーマス・エジソンは1878 年に同僚に宛てた手紙の中で次のように書いています[8]

... 困難が生じます—これが解決し、[それが]そのとき、「バグ」—そのような小さな欠点や困難をそう呼ぶ—が現れます[9]

最初の機械式ピンボールゲームであるバッフル ボールは1931 年に「バグがない」と宣伝されました。[10]第二次世界大戦中の軍用装備の問題はバグ (またはグリッチ)と呼ばれていました[11] 1942年に出版された本の中で、ルイーズ・ディキンソン・リッチは動力式氷切断機について、「最愛の人から虫を取り出すために製作者が連れてこられるまで、氷の切断は中断された」と述べた。[12]

アイザック・アシモフは、1944 年に出版された短編小説「 Catch That Rabbit 」の中で、ロボットの問題に関連して「バグ」という用語を使用しました

ハーバード大学 Mark II電気機械コンピューターのログのページ。デバイスから取り出された死んだ蛾が描かれています。

「バグ」という用語は、初期の電気機械式コンピューターの誤動作の原因を公表したコンピューターの先駆者グレース ホッパーの説明で使用されました。 [13]物語の典型的なバージョンは次のとおりです。

1946 年にホッパーが現役から解放されると、彼女はハーバード大学の計算研究所に加わり、そこでMark IIMark IIIの研究を続けました。オペレーターは、Mark II のエラーの原因をリレーに閉じ込められた蛾であると突き止め、「バグ」という用語を作りました。このバグは慎重に削除され、ログブックにテープで記録されました。最初のバグに由来し、今日ではプログラム内のエラーや不具合を バグ と呼びます[14]

バグが発見されたとき、ホッパーさんはその場にいませんでしたが、それは彼女のお気に入りの話の 1 つになりました。[15]航海日誌の日付は 1947 年 9 月 9 日でした。[16] [17] [18]それを発見したオペレーターには、後にバージニア州ダールグレンの海軍兵器研究所に所属するウィリアム "ビル" バークが含まれていました[19 ] という工学用語に精通しており、「実際に虫が見つかった初の事例」という表記をして面白がって昆虫を飼っていた。蛾が添付されたこのログブックは、スミソニアン国立アメリカ歴史博物館のコレクションの一部です[17]

関連用語「デバッグ」も、コンピューティングでの使用よりも前からあるようです。オックスフォード英語辞典語源には、航空機エンジンの文脈で 1945 年の証明が含まれています。[20]

ソフトウェアにエラーが含まれている可能性があるという概念は、分析エンジンに関するエイダ ラブレスの 1843 年のメモに遡ります。その中で彼女は、チャールズ バベッジ分析エンジンのプログラム「カード」に誤りがある可能性について語っています。

...分析エンジンに必要な運用データを提供するために、分析プロセスも同様に実行されている必要があります。そして、これもエラーの原因となる可能性があります。実際のメカニズムのプロセスに間違いがないとしても、カードが間違った命令を与える可能性があります。

用語

ソフトウェアのエラーを説明するために「バグ」という用語が使用されるのは一般的ですが、多くの人がその用語を放棄すべきだと主張しています。議論の 1 つは、「バグ」という言葉は人間が問題を引き起こしたという意味から離れており、代わりに欠陥が自然に生じたという意味を含んでいるため、次のような用語を支持して「バグ」という言葉を放棄するよう促すというものです。 「欠陥」があり、成功は限られています。[21]

「バグ」という用語は、意図的な設計上の決定を隠すために使用されることもあります。 2011 年、ユーザーの位置情報を暗号化されていないファイルに記録して保存したとして米国上院議員アル フランケンから厳しい追及を受けた後、 [22] Apple はその動作をバグだと呼びました。しかし、民主主義とテクノロジーセンターのジャスティン・ブルックマン氏は、その描写に真っ向から異議を唱え、「彼らがバグと呼ぶものを修正しているのはうれしいが、ユーザーを追跡しているという彼らの強い否定は例外とする」と述べた。[23]

ソフトウェア エンジニアリングではミス メタモーフィズム(ギリシャ語のメタ= 「変化」、モーフ= 「形」に由来) は、ソフトウェア展開の最終段階における欠陥の進化を指します。ソフトウェア開発ライフサイクルの初期段階でアナリストが犯した「間違い」が変化し、サイクルの最終段階で「欠陥」が生じることは、「間違いの変態」と呼ばれています。[24]

サイクル全体における「間違い」のさまざまな段階は、「間違い」、「異常」、「障害」、「失敗」、「エラー」、「例外」、「クラッシュ」、「グリッチ」、「バグ」として説明される場合があります。 、「欠陥」、「事件」、または「副作用」。[24]

防止

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

ソフトウェア業界はバグ数を減らすことに多大な努力を払ってきました。[25] [26]これらには次のものが含まれます。

誤字脱字

バグは通常、プログラマが論理エラーを犯したときに発生します。プログラミング スタイル防御的プログラミングにおけるさまざまな革新は、これらのバグの可能性を低くしたり、発見しやすくしたりするように設計されています。一部のタイプミス、特に記号演算子のタイプミスによってプログラムが誤って動作する可能性がある一方で、記号の欠落や名前のスペルミスなどによってプログラムの動作が妨げられる場合があります。コンパイルされた言語では、ソース コードをコンパイルするときにいくつかのタイプミスが明らかになる場合があります。

開発方法論

いくつかのスキームは、生成されるバグを少なくするためにプログラマのアクティビティの管理を支援します。ソフトウェア エンジニアリング(ソフトウェア設計の問題にも対処します) は、欠陥を防ぐために多くの技術を適用します。たとえば、正式なプログラム仕様には、設計のバグを排除できるようにプログラムの正確な動作が記載されています。正式な仕様は、組み合わせ爆発不確定性の問題があるため、最も短いプログラム以外には実用的ではありません

単体テストでは、プログラムが実行するすべての機能 (ユニット) のテストを作成します。

テスト駆動開発では、単体テストはコードの前に記述され、すべてのテストが正常に完了するまでコードは完了したとは見なされません。

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

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

プログラミング言語のサポート

プログラミング言語には、静的型システム、制限された名前空間モジュール型プログラミングなど、バグの防止に役立つ機能が含まれています。たとえば、プログラマが (擬似コード)を記述するとLET REAL_VALUE PI = "THREE AND A BIT"、これは構文的には正しいかもしれませんが、コードは型チェックに失敗します。コンパイルされた言語は、プログラムを実行することなくこれを検出します。インタープリタ型言語は、実行時にそのようなエラーを検出します。一部の言語では、パフォーマンスの低下を犠牲にして、バグにつながりやすい機能を意図的に除外しています。一般原則として、特にメンテナンス コストが多額であることを考慮すると、わずかに高速に実行される不可解なコードよりも、単純で低速のコードを作成する方がほとんどの場合優れています。 。たとえば、Java プログラミング言語はポインター演算をサポートしていませんPascalスクリプト言語などの一部の言語の実装では、少なくともデバッグ ビルドでは、配列の 実行時境界チェックが行われることがよくあります。

コード分​​析

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

計装

ソフトウェアの実行中にそのパフォーマンスを監視するためのツールは、特にボトルネックなどの問題を見つけたり、正常に動作していることを保証したりするために、明示的にコードに埋め込むか (おそらく というステートメントと同じくらい単純PRINT "I AM HERE")、次のように提供することができます。ツール。コードの一部にほとんどの時間が費やされている場所を見つけると、驚くことがよくあります。この仮定の削除により、コードが書き直される可能性があります。

テスト

ソフトウェア テスターは、バグを見つけたり、テストをサポートするコードを作成したりすることを主な任務とする人々です。取り組みによっては、プログラムの開発よりもテストに多くのリソースが費やされる場合があります。

テスト中の測定により、残っている可能性のあるバグの数を推定できます。これは、製品のテストと開発に時間がかかるほど信頼性が高くなります。[要出典]

デバッグ

典型的なバグ履歴 ( GNU クラスパスプロジェクト データ)。ユーザーによって提出された新しいバグは未確認です。開発者によって再現されると、それは確認されたバグとなります。確認されたバグは後で修正されます。他のカテゴリに属する​​バグ (再現不可能、修正されないなど) は、通常、少数派です。

バグの発見と修正、つまりデバッグは、コンピューター プログラミングの主要な部分です。初期のコンピューティングのパイオニアであるモーリス ウィルクスは、1940 年代後半に、残りの人生の多くはプログラムの間違いを見つけることに費やされるだろうと悟ったと述べています。[29]

通常、デバッグで最も難しい部分はバグを見つけることです。一旦発見されれば、通常は修正するのは比較的簡単です。デバッガとして知られるプログラムは、コードを 1 行ずつ実行し、変数値を監視し、プログラムの動作を観察するその他の機能により、プログラマがバグを特定するのに役立ちます。デバッガを使用しない場合、プログラムの実行をトレースしたり、値を表示したりするために、メッセージや値をコンソール、ウィンドウ、ログ ファイルに書き込むコードを追加することができます。

ただし、デバッガーを使用したとしても、バグを見つけるのは一種の技術です。プログラムのあるセクションのバグがまったく別のセクションで障害を引き起こすことは珍しいことではなく、[要出典]そのため、追跡が特に困難になります (たとえば、グラフィックスレンダリングルーチンのエラーによりファイルI/Oが発生するなど)ルーチンが失敗する)、システムの一見無関係な部分にあります。

場合によっては、バグは単独の欠陥ではなく、プログラマー側の思考や計画のエラーを表している場合があります。このような論理エラーが発生した場合は、プログラムの一部を徹底的に見直すか書き直す必要があります。コード レビューの一環として、コードをステップ実行し、実行プロセスを想像したり転写したりすると、バグそのものを再現することなくエラーが見つかることがよくあります。

より一般的には、バグを特定するための最初のステップは、それを確実に再現することです。バグが再現可能になると、プログラマはエラーの再現中にデバッガまたは他のツールを使用して、プログラムが誤った箇所を見つけることができます。

一部のバグは、プログラマが再作成するのが難しい入力によって明らかになります。Therac-25放射線治療装置の死亡原因の 1 つは、装置のオペレーターが非常に迅速に治療計画を入力した場合にのみ発生するバグ (具体的には競合状態) でした。これができるようになるまでには何日も練習が必要だったので、テスト中やメーカーが再現しようとしたときにバグは現れませんでした。他のバグは、デバッガーでプログラムを実行するなど、バグを見つけやすくするためにセットアップが強化されるたびに発生しなくなる可能性があります。これらはハイゼンバグと呼ばれます(ハイゼンベルクの不確定性原理にちなんでユーモラスに名付けられました)。

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

バグの一部のクラスは、コードとは何の関係もありません。コードがドキュメントと一致していても、ドキュメントやハードウェアに欠陥があると、システムの使用に問題が発生する可能性があります。場合によっては、コードがドキュメントと一致しなくなっても、コードを変更すると問題が解消されることがあります。組み込みシステムでは、特に汎用品の場合、ハードウェアを再製造するよりも新しいバージョンのROMを作成する方がはるかに安価であるため、ハードウェアのバグを頻繁に回避します

バグのベンチマーク

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

  • シーメンスのベンチマーク
  • ManyBugs [31] は、 9 つ​​のオープンソース プログラムの 185 C バグのベンチマークです。
  • Defects4J [32] は、 5 つのオープンソース プロジェクトからの 341 個の Java バグのベンチマークです。さまざまなパッチ タイプをカバーする、対応するパッチが含まれています。

バグ管理

バグ管理には、文書化、分類、割り当て、再現、修正、修正されたコードのリリースのプロセスが含まれます。ソフトウェアに対する提案された変更 (バグ、機能拡張リクエスト、さらにはリリース全体) は、通常、バグ追跡システムまたは問題追跡システムを使用して追跡および管理されます。[33]追加された項目は、欠陥、チケット、問題、またはアジャイル開発パラダイムに従ってストーリーやエピックと呼ばれることがあります。カテゴリは、バージョン番号、ソフトウェアの領域、重大度、優先度、機能リクエストやバグなどの問題の種類など、 客観的、主観的、または組み合わせの場合があります。

バグトリアージはバグをレビューし、それらを修正するかどうか、いつ修正するかを決定します。決定はバグの優先度や開発スケジュールなどの要素に基づいて行われます。トリアージはバグの原因を調査することを目的としたものではなく、バグを修正するためのコストを調査することを目的としています。トリアージは定期的に行われ、前回の会議以降にオープンまたは再オープンされたバグが調査されます。トリアージ プロセスの参加者は通常、プロジェクト マネージャー、開発マネージャー、テスト マネージャー、ビルド マネージャー、および技術専門家です。[34] [35]

重大度

重大度は、バグがシステム動作に及ぼす影響の強さです。[36]この影響は、データ損失、財務的損失、信用の損失、無駄な労力などに及ぶ可能性があります。重大度レベルは標準化されていません。影響は業界によって異なります。ビデオ ゲームのクラッシュは、Web ブラウザやリアルタイム監視システムのクラッシュとはまったく異なる影響を及ぼします。たとえば、バグの重大度レベルは、「クラッシュまたはハング」、「回避策なし」 (顧客が特定のタスクを達成できる方法がないことを意味します)、「回避策あり」 (ユーザーはまだタスクを達成できることを意味します)、「視覚的」などです。欠陥」(画像の欠落、ボタンやフォーム要素の位置のずれなど)、または「ドキュメントのエラー」。ソフトウェア発行元によっては、「クリティカル」、「高」、「低」、「ブロッカー」、または「軽度」など、より適切な重大度を使用している場合があります。[37]バグの重大度は、修正の優先順位とは別のカテゴリである場合があり、この 2 つは個別に定量化および管理される場合があります。

優先度

優先順位は、計画された変更リストのどのバグに該当するかを制御します。優先順位は各ソフトウェア制作者によって決定されます。優先順位は、1 ~ 5 などの数値で指定することも、「クリティカル」、「高」、「低」、「延期」などの名前で指定することもできます。これらの評価スケールは、重大度の評価と類似または同一である場合もありますが、バグの重大度と推定修正作業量の組み合わせとして評価されます。重大度は低いが修正が簡単なバグは、修正に多大な労力を必要とする中程度の重大度のバグよりも優先順位が高くなります。優先度の評価は、次のソフトウェア リリースまでに修正する必要があるすべてのバグを示す「クリティカル」優先度など、製品リリースと一致する場合があります。

製品のリリースを遅らせたり中止したりするほど深刻なバグは、「ショーストッパー」[38]または「ショーストッパーバグ」と呼ばれます。[39]「ショーを停止する」つまり許容できない製品障害を引き起こすため、このように名付けられました。[39]

ソフトウェアのリリース

既知の優先度の低いバグを含むソフトウェアをリリースするのが一般的です。優先度が十分に高いバグの場合は、それらの修正が適用されたモジュールのみを含むコードの一部を特別にリリースする必要がある場合があります。これらはパッチと呼ばれます。ほとんどのリリースには、動作の変更と複数のバグ修正が混在しています。バグ修正に重点を置いたリリースは、機能の追加や変更に重点を置いたメジャー リリースと区別するために、 メンテナンスリリースとして知られています。

ソフトウェア発行者が特定のバグにパッチを適用しない、あるいは修正しないことを選択する理由には次のようなものがあります。

  • 期限を守る必要がありますが、期限までにすべてのバグを修正するにはリソースが不十分です。[40]
  • このバグは次のリリースですでに修正されており、優先度は高くありません。
  • バグを修正するために必要な変更にはコストがかかりすぎるか、他の多くのコンポーネントに影響を与えるため、大規模なテスト作業が必要になります。
  • 一部のユーザーが既存のバグのある動作に依存していることが疑われるか、知られている可能性があります。提案された修正により、重大な変更が導入される可能性があります。
  • 問題は、今後のリリースでは廃止される領域にあります。直す必要はありません。
  • 「それはバグではありません。機能です。」[41]期待される動作と認識される動作または文書化されていない機能の間に誤解が生じています

種類

ソフトウェア開発では、どの段階でも間違いやエラーが発生する可能性があります。バグは、仕様、設計、コーディング、構成、データ入力、文書化の際のソフトウェア チームによる見落としや誤解から発生します。たとえば、単語のリストをアルファベット順に並べる比較的単純なプログラムでは、単語にハイフンが含まれている場合に何が起こるかを考慮していない可能性があります。あるいは、抽象的なデザインをコードに変換するときに、コーダーが誤って「<=」が意図されていた場所に「<」になる可能性があるオフバイワンエラーを作成し、リスト内の最後の単語のソートに失敗する可能性があります。

バグの別のカテゴリは競合状態と呼ばれ、プログラムで複数のコンポーネントが同時に実行されている場合に発生する可能性があります。コンポーネントが開発者が意図した順序とは異なる順序で対話すると、コンポーネントが相互に干渉し、プログラムがタスクを完了できなくなる可能性があります。これらのバグは、プログラムの実行ごとに発生するわけではないため、検出または予測することが困難な場合があります。

概念的なエラーは、ソフトウェアが何をしなければならないかについての開発者の誤解です。結果として得られるソフトウェアは、開発者の理解に従って動作する可能性がありますが、実際に必要なものとは異なる場合があります。他のタイプ:

算術

数値の操作では、予期しない出力、プロセスの遅延、またはクラッシュを引き起こす問題が発生する可能性があります。[42]これらは、丸めによる精度の低下数値的に不安定なアルゴリズム、算術オーバーフローアンダーフローなどのデータ ストレージの品質の認識の欠如、またはさまざまなソフトウェアによる計算の処理方法の認識の欠如から発生する可能性があります。ゼロ除算などのコーディング言語では、一部の言語では例外がスローされ、他の言語ではNaNinfinityなどの特別な値が返される場合があります。

制御フロー

制御フローのバグとは、有効なロジックを備えたプロセスで見つかるものの、無限ループや無限再帰、間違った比較演算子の使用などの条件付きステートメントの誤った比較オフバイワン エラー(1 つを数える)などの意図しない結果を引き起こすバグです。ループ時の反復が多すぎるか 1 回が少なすぎます)。

インターフェース

  • API の使用法が間違っています。
  • プロトコルの実装が正しくありません。
  • ハードウェアの取り扱いが間違っている。
  • 特定のプラットフォームの誤った仮定。
  • 互換性のないシステム。 2 つのシステムが異なるバージョンを使用している場合、新しいAPIまたは通信プロトコルは機能するように見えますが、あるバージョンに実装されている機能が別のバージョンで変更されたり欠落したりすると、エラーが発生する可能性があります。電気通信業界[43]やインターネットなど、継続的に実行する必要がある運用システムでは、メジャー アップデートのためにシステム全体をシャットダウンすることができない場合があります。[44] [45] [46]この場合、大規模ネットワークへの中断を最小限に抑えるために、大規模システムの小さなセグメントが個別にアップグレードされます。ただし、一部のセクションは見落とされてアップグレードされない可能性があり、検出して修復することが困難な互換性エラーが発生する可能性があります。
  • 不正なコードの注釈。

同時実行性

リソースの調達

構文

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

チームワーク

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

意味するところ

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

バグによる損害以外に、そのコストの一部はバグを修正するために費やされた労力によるものです。 1978 年に、リエンツら。プロジェクトの中央値は、開発労力の 17% をバグ修正に投資していることがわかりました。[47] 2020 年のGitHubリポジトリに関する調査では、中央値が 20% であることが示されました。[48]

納品された製品にバグが残っている

1994 年、NASA のゴダード宇宙飛行センターは、コード ( SLOC ) 1000 行あたりの平均エラー数を 4.5 から1000 SLOC あたり 1 まで減らすことに成功しました。[49]

1990 年の別の研究では、非常に優れたソフトウェア開発プロセスでは、1000 SLOC あたり 0.1 という低い導入失敗率を達成できることが報告されています。[50]この図は、Steve McConnellによるCode Complete [51]飛行ソフトウェアの複雑さに関する NASA の研究などの文献で繰り返されています[52]いくつかのプロジェクトでは欠陥ゼロを達成しました。IBM Wheelwriterタイプライターのファームウェアは63,000 SLOC で構成され、Space Shuttleソフトウェアは 500,000 SLOC で構成されています。[50]

よく知られているバグ

多くのソフトウェアのバグは、通常その深刻さによってよく知られるようになりました。例としては、さまざまな宇宙航空機や軍用機の墜落などが挙げられます。おそらく最も有名なバグは2000 年問題または Y2K バグです。これは、19xx 年から 20xx 年に移行するずっと前に作成された多くのプログラムの誤動作を引き起こしました。たとえば、2004 年を表す日付「2004 年 12 月 25 日」が誤って 1904 年として扱われたり、年「2000」が誤って「19100」と表示されたりする可能性があります。 20 世紀の終わり近くにプログラマーが大規模な努力を行った結果、このバグによる最も深刻な結果は回避されました。[要出典]

2012 年の株式取引の混乱には、古いAPI と新しい API の間の非互換性の 1 つが関係していました。

政治において

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

New Americaというグループが運営する Open Technology Institute [53]は、2016 年 8 月に「システムのバグ」という報告書を発表し、米国の政策立案者は研究者がソフトウェアのバグを特定して対処できるように改革を行うべきであると述べています。この報告書は「ソフトウェアの脆弱性の発見と開示の分野における改革の必要性を強調している」。[54]報告書の執筆者の一人は、議会はサイバーセキュリティというより大きな問題に対処するために数多くの法案を可決したにもかかわらず、議会はサイバーソフトウェアの脆弱性への対処に十分な措置を講じていない、と述べた。[54]

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

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

大衆文化において

  • ビデオ ゲームでは、「グリッチ」という用語がソフトウェアのバグを指すために使用されることがあります。例としては、グリッチと非公式のポケモン種 MissingNo があります。
  • 1968 年の小説『2001 年宇宙の旅』と、それに対応する 1968 年の映画『2001 年宇宙の旅』では、宇宙船の搭載コンピューターであるHAL 9000が乗組員全員を殺害しようとします。続編となる 1982 年の小説『2010: Odyssey Two』と、それに付随する 1984 年の映画『2010』では、この行為はコンピュータが 2 つの相反する目的を持ってプログラムされたことによって引き起こされたことが明らかになりました。それは、すべての情報を完全に開示することと、情報を保持することです。乗組員には秘密にされていた飛行の真の目的。この対立により、HAL は偏執的になり、最終的には殺人行為に走るようになりました。
  • ネーナの 1983 年の歌99 Luftballons (99 Red Balloons)の英語版では、「ソフトウェアのバグ」の結果、99 個の赤い風船のグループの放出が敵の核ミサイル発射と誤認され、同等の発射対応が必要となります。 、大惨事につながります。
  • 1999 年のアメリカのコメディ映画『オフィス スペース』では、3 人の従業員が、銀行口座に 1 ペニーの端数を四捨五入した金額を銀行口座に送金するコンピューター ウイルスを使用して、会社が Y2K コンピューターのバグに夢中になっているのを悪用しようと (失敗しました)、サラミと呼ばれる古くから知られている手法です。スライス
  • エレン・ウルマンによる2004 年の小説『The Bug』は、データベース アプリケーション内のとらえどころのないバグを見つけようとするプログラマーの試みについての物語です。[55]
  • 2008 年のカナダ映画「Control Alt Delete」は、1999 年末に 2000 年問題に関連した会社のバグ修正に奮闘するコンピューター プログラマーの物語です。

こちらも参照

参考文献

  1. ^ ミッタル、ヴァルン;アディティヤ、シヴァム(2015 年 1 月 1 日)。 「バグ修正分野の最近の動向」。プロセディアコンピュータサイエンス。コンピューター、コミュニケーション、コンバージェンスに関する国際会議 (ICCC 2015)。48 : 288–297。土井: 10.1016/j.procs.2015.04.184ISSN  1877-0509。
  2. ^ “アリアン 501 – 調査委員会報告書の提示”. www.esa.int 2022 年1 月 29 日に取得
  3. ^ サイモン・ロジャーソン教授。 「チヌークヘリコプターの惨事」。 Ccsr.cse.dmu.ac.uk。 2012 年 7 月 17 日のオリジナルからアーカイブ2012 年9 月 24 日に取得
  4. ^ “郵便局のスキャンダルで生活が台無し、捜査が続く”. BBCのニュース。 2022 年 2 月 14 日。
  5. ^ “ソフトウェアのバグは米国経済に多大な損害を与える”. 2009 年 6 月 10 日。2009 年 6 月 10 日のオリジナルからアーカイブ2012 年9 月 24 日に取得{{cite web}}: CS1 maint: unfit URL (link)
  6. ^ Computerworld スタッフ (2011 年 9 月 3 日)。 「マシンの中の蛾: 「バグ」の起源をデバッグする」。コンピューターワールド。 2015年8月25日のオリジナルからアーカイブ。
  7. ^ "バグ" .オックスフォード英語辞典(オンライン版)。オックスフォード大学出版局 (購読または参加機関のメンバーシップが必要です。) 5a
  8. ^ “知っていましたか? エジソンが「バグ」という用語を作った”. 2013 年 8 月 1 日2019 年7 月 19 日に取得
  9. ^ エジソンからプスカシュへ、1878 年 11 月 13 日、エジソン論文、エジソン国立研究所、米国国立公園局、ニュージャージー州ウェストオレンジ、 ヒューズ、トーマス・パーク (1989) で引用。アメリカの創世記: 発明と技術的熱意の世紀、1870 ~ 1970 年。ペンギンブックス。 p. 75.ISBN 978-0-14-009741-2
  10. ^ 「バッフルボール」。インターネットピンボールデータベース。(参考エントリーの広告画像を参照)
  11. ^ “現代の航空母艦は、20 年間にわたる賢明な実験の結果である”.人生。 1942 年 6 月 29 日。p. 25. 2013年6月4日時点のオリジナルからアーカイブ2011 年11 月 17 日に取得
  12. ^ ディキンソン・リッチ、ルイーズ (1942)、「We Took to the Woods」、JB Lippincott Co、p. 93、LCCN  42024308、OCLC  405243、2017 年 3 月 16 日のオリジナルからアーカイブ。
  13. ^ FCAT NRT テスト、ハーコート、2008 年 3 月 18 日
  14. ^ “ダニス、シャロン・アン:「グレース・マレー・ホッパー少将」”. ei.cs.vt.edu。 1997 年 2 月 16 日2010 年1 月 31 日に取得
  15. ^ ジェームス・S・ハギンズ。 「最初のコンピューターのバグ」。ジェームスシャギンス.com。 2000 年 8 月 16 日のオリジナルからアーカイブ2012 年9 月 24 日に取得
  16. ^ "バグは 2017 年 3 月 23 日にウェイバック マシンにアーカイブされました"、専門用語ファイル、ver. 4.4.7. 2010 年 6 月 3 日に取得。
  17. ^ ab 「コンピューターのバグを含むログブック、2017 年 3 月 23 日にウェイバック マシンでアーカイブ」、国立アメリカ歴史博物館、スミソニアン博物館。
  18. ^ “The First "Computer Bug", Naval Historical Center. ただし、ハーバード大学 Mark IIコンピュータは 1947 年の夏まで完成しなかったことに注意してください。
  19. ^ IEEE コンピューティングの歴史年報、第 22 巻第 1 号、2000 年
  20. ^ 英国王立航空協会の雑誌。 49、183/2、1945 「それは…型式試験、飛行試験、そして『デバッグ』の段階に及びました…」
  21. ^ “SEI 1999 アーカイブのニュース”. cmu.edu。 2013 年 5 月 26 日のオリジナルからアーカイブ。
  22. ^ “Apple は iPhone の追跡に関して議会からの質問に直面している”。コンピューターワールド。 2011年4月21日。オリジナルの2019年7月20日からアーカイブ。
  23. ^ "Apple、iPhone ユーザーの追跡を否定、しかし変更を約束".コンピューターワールド。 2011年4月27日。2023年3月29日のオリジナルからアーカイブ。
  24. ^ ab "テスト体験: te: プロのテスターのための雑誌".テスト経験。ドイツ: テスト経験: 42。2012 年 3 月。ISSN 1866-5705  。 (購読が必要です)
  25. ^ ホイジンガ、ドロタ;コラワ、アダム (2007)。自動欠陥防止: ソフトウェア管理のベスト プラクティス。 Wiley-IEEE Computer Society Press。 p. 426.ISBN 978-0-470-04212-0。 2012 年 4 月 25 日のオリジナルからアーカイブ。
  26. ^ マーク・マクドナルド;ロバート・マッソン。スミス、ロス (2007)。欠陥防止の実践ガイド。マイクロソフトプレス。 p. 480.ISBN 978-0-7356-2253-1
  27. ^ “Release Early, Release Often” 2011 年 5 月 14 日アーカイブ、Wayback MachineEric S. RaymondThe Cathedral and the Bazaar
  28. ^ 「ワイド オープン ソース」アーカイブ、2007 年 9 月 29 日、Wayback MachineElias LevySecurityFocus、2000 年 4 月 17 日
  29. ^ モーリス・ウィルクスの名言
  30. ^ “PolySpace Technologies の歴史”. christele.faure.pagesperso-orange.fr 2019 年8 月 1 日に取得
  31. ^ ル・グー、クレア;ニール・ホルトシュルテ。スミス、エドワード K.ブラン、ユーリー。デヴァンブ、プレムクマール。フォレスト、ステファニー。ワイマー、ウェストリー (2015)。 「C プログラムの自動修復のための ManyBugs と IntroClass ベンチマーク」。ソフトウェアエンジニアリングに関するIEEEトランザクション41 (12): 1236–1256。土井: 10.1109/TSE.2015.2454513ISSN  0098-5589。
  32. ^ ただ、ルネ。ジャラリ、ダリオシュ。エルンスト、マイケル D. (2014)。 「Defects4J: Java プログラムの制御されたテスト研究を可能にする既存の障害のデータベース」。ソフトウェアのテストと分析に関する 2014 年の国際シンポジウムの議事録 – ISSTA 2014。 437–440ページ。CiteSeerX 10.1.1.646.3086土井:10.1145/2610384.2628055。ISBN  9781450326452S2CID  12796895。
  33. ^ アレン、ミッチ (2002 年 5 月 - 6 月)。 「バグ追跡の基本: 欠陥の報告と追跡に関する初心者向けガイド」。ソフトウェア テストおよび品質エンジニアリング マガジン。 Vol. 4、いいえ。 3. 20 ~ 24 ページ2017 年12 月 19 日に取得
  34. ^ レックス・ブラック (2002).テストプロセスの管理 (第 2 版)。ワイリー・インディア社限定。 p. 139.ISBN 978-81265031312021 年6 月 19 日に取得
  35. ^ クリス・ヴァンダー・メイ (2012). Shipping Greatness - Google と Amazon での現場で学んだ、優れたソフトウェアの構築と立ち上げに関する実践的なレッスン。オライリーメディア。 79–81ページ。ISBN 978-1449336608
  36. ^ ソレイマニ・ネイシアーニ、ベフザド;ババミル、シード・モルテザ。有次、正義(2020年10月1日)。 「ソフトウェアバグトリアージシステムにおける重複バグレポート検出の検証パフォーマンスを向上させるための効率的な特徴抽出モデル」。情報およびソフトウェア技術126 : 106344.土井:10.1016/j.infsof.2020.106344. S2CID  219733047。
  37. ^ 「5.3. バグの構造」. bugzilla.org。 2013 年 5 月 23 日のオリジナルからアーカイブ。
  38. ^ ジョーンズ、ウィルバー D. ジュニア編。 (1989年)。 "ショーストッパー"。用語集: 防衛獲得の頭字語と用語(第 4 版)。バージニア州フォートベルボア: 国防総省、防衛システム管理大学。 p. 123. hdl :2027/mdp.39015061290758 – Hathitrust経由。
  39. ^ ab ザカリー、G. パスカル (1994)。ショーストッパー!: Microsoft における Windows NT と次世代を作成するための熾烈な競争。ニューヨーク:フリープレス。 p. 158.ISBN 0029356717– archive.org経由。
  40. ^ “The Next Generation 1996 Lexicon A to Z: Slipstream Release”.次世代。 No. 15、1996 年 3 月、p. 41.
  41. ^ カー、ニコラス (2018). 「『それはバグではありません、機能です。』ありきたり – それともちょうどいい?」有線.com
  42. ^ ディ・フランコ、アンソニー;郭、慧。シンディ、ルビオ=ゴンザレス。 「現実世界の数値バグ特性の包括的研究」(PDF)2022 年 10 月 9 日のオリジナルからアーカイブ(PDF) 。
  43. ^ キンブラー、K. (1998)。通信およびソフトウェア システムにおける機能の相互作用 V. IOS Press。 p. 8.ISBN 978-90-5199-431-5
  44. ^ サイード、マフブブル・ラーマン (2001).マルチメディア ネットワーキング: テクノロジー、管理、およびアプリケーション: テクノロジー、管理、およびアプリケーション。イデアグループ株式会社(IGI)。 p. 398.ISBN 978-1-59140-005-9
  45. ^ ウー・チュワンファ (ジョン);アーウィン、J. デビッド (2016)。コンピュータ ネットワークとサイバーセキュリティの概要。 CRCプレス。 p. 500.ISBN 978-1-4665-7214-0
  46. ^ RFC 1263: 「TCP 拡張機能は有害であると考えられる」の引用: 「プロトコルの新しいバージョンをすべてのホストに配布するのに非常に長い時間がかかる可能性があります (実際には永久に)。 ... 古いバージョンと新しいバージョンの間に少しでも互換性がない場合、混乱が生じる可能性があります。」
  47. ^ リエンツ、BP; EB、スワンソン。ジョージア州トンプキンス (1978)。 「アプリケーションソフトウェアメンテナンスの特徴」。ACM の通信21 (6): 466–471。土井10.1145/359511.359522S2CID  14950091。
  48. ^ アミット、イダン;フェイテルソン、ドロール G. (2020)。 「修正コミット確率コード品質メトリック」。arXiv : 2007.10912 [cs.SE]。
  49. ^ ソフトウェア工学研究室の概要(PDF)(レポート)。メリーランド州:ゴダード宇宙飛行センター、NASA。 1994 年 12 月 1 日。41 ~ 42 ページの図 18。 pp 43–44 図 21. CR-189410; SEL-94-005。2022 年 11 月 22 日のオリジナルからアーカイブ(PDF) 2022 年11 月 22 日に取得(参考文献:ソフトウェア工学研究室の概要)
  50. ^ ab コブ、リチャード H.ミルズ、ハーラン D. (1990)。 「統計的品質管理の下でのエンジニアリングソフトウェア」。IEEE ソフトウェア7 (6): 46.土井:10.1109/52.60601。ISSN  1937-4194。S2CID  538311 – テネシー大学 – ハーラン D. ミルズ コレクション経由。
  51. ^ マコーネル、スティーブン C. (1993)。コードが完成しました。ワシントン州レドモンド: Microsoft Press。 p. 611.ISBN 978-1556154843– archive.org経由。(コブとミルズ、1990)
  52. ^ ジェラルド、ホルツマン(2009 年 3 月 6 日)。 「付録 D – ソフトウェアの複雑さ」(PDF)。ドヴォルザークでは、ダニエル L. (編)。飛行ソフトウェアの複雑さに関する NASA の調査 (レポート)。NASA。 pdf フレーム 109/264。付録 D p.2。2022 年 3 月 8 日のオリジナルからアーカイブ(PDF) 2022 年11 月 22 日に取得(NASA チーフエンジニアオフィステクニカルエクセレンスイニシアチブ、2022 年 11 月 23 日、ウェイバックマシンにアーカイブ)
  53. ^ アンディ・ウィルソン;シュルマン、ロス。バンクストン、ケビン。ああ、トレイ。 「システムのバグ」(PDF)オープンポリシー研究所2016 年 9 月 21 日のオリジナルからアーカイブ(PDF) 2016 年8 月 22 日に取得
  54. ^ abcd ローゼンズ、トレイシー (2016 年 8 月 12 日)。 「ソフトウェアのバグ発見と開示を強化するにはサイバー改革が必要:新しいアメリカの報告書 – Homeland Preparedness News」2016 年8 月 23 日に取得
  55. ^ ウルマン、エレン (2004)。不具合ピカドールISBN 978-1-250-00249-5

外部リンク

  • 「Common Weakness Enumeration」 – バグに焦点を当てた専門家の Web ページ (NIST.gov)
  • ジム・グレイのバグタイプ - 別のバグタイプ
  • Wayback Machineの「最初のコンピューターのバグ」の画像(2015 年 1 月 12 日アーカイブ)
  • 「初めてのコンピューターバグ!」 – ホッパー提督のバグについての 1981 年のメール
  • 「GCC および LLVM のコンパイラのバグを理解するために」。コンパイラのバグに関する 2016 年の調査
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_bug&oldid=1219083356"