Software bug - Software bug


z Wikipedie, otevřené encyklopedie

Vývoj softwaru
Hlavní činnosti
Vzory a modely
Metodiky a rámce
podpůrné disciplíny
Practices
Nástroje
Standardy a orgány znalostí
slovníky

Softwarová chyba je chyba, chyba, selhání nebo chyba v počítačovém programu nebo systému, který způsobuje, že k nesprávnému nebo neočekávaný výsledek, nebo se chovat v nezamýšleným způsobem. Proces, kterým se chyby se nazývá „ ladění “ a často se používá formální techniky nebo nástroje určit chyby, a od roku 1950, byly některé počítačové systémy byly navrženy tak, aby také odradit, detekci nebo auto-správný různé počítačové chyby v průběhu operace.

Většina chyby vyplývají z chyb a omylů učiněných buď v programu zdrojového kódu nebo jeho designu , nebo komponent a operačních systémů, které používají tyto programy. Některé jsou způsobeny překladače produkují nesprávný kód. Program, který obsahuje velké množství chyb, a / nebo chyby, které vážně narušují jeho funkčnosti, se říká, že kočárek (vadný). Chyby může vyvolat chyby, které mohou mít dominový účinky . Chyby mohou mít jemné účinky nebo způsobit, že program pád nebo zamrznutí počítače. Ostatní chyby považovat za bezpečnostní chyby a mohl by například umožnit uživateli se zlými úmysly obejít řízení přístupu za účelem získání neoprávněné výhody .

Některé softwarové chyby byly spojeny s katastrofami. Chyby v kódu, která řídila Therac-25 radiační terapie stroj byl přímo zodpovědný za úmrtí pacientů v roce 1980. V roce 1996 Evropská kosmická agentura US $ 1 miliarda ‚s prototypem Ariane 5 rakety muselo být zničeno méně než minutu po startu kvůli chybě v palubního navádění počítačový program. V červnu 1994, Royal Air Force Chinook Vrtulník narazil do Mull of Kintyre , zabíjení 29. Toto bylo původně zamítnuta jako chybě pilota, ale vyšetřování Computer Weekly přesvědčil House of Lords šetření ukázalo, že to může být způsobena softwaru chyba v letounu motoru řídicího počítače .

V roce 2002 studie zadaná US Department of Commerce ‚s Národním institutem pro normalizaci a technologie k závěru, že„softwarové chyby, nebo chyby, jsou tak rozšířené, a tak škodlivé, že stojí americká ekonomika podle odhadů 59 miliard $ ročně, nebo asi 0,6 procent hrubého domácího produktu.“

Etymologie

Pod pojmem „chyba“ popisovat vady je součástí strojírenského žargonu od roku 1870 a předchází elektronických počítačů a počítačového softwaru; to může byly původně používány v hardwarovém inženýrství popsat mechanické poruchy. Například Thomas Edison napsal tato slova v dopise přidružené společnosti v roce 1878:

Bylo to jen tak ve všech mých vynálezů. Prvním krokem je intuice a je dodáván s výbuchem, pak vznikají obtíže, tahle věc rozdává a [je] pak, že „Chyby“ -jako takových malých chyb a obtíží, se nazývají-projevují a měsících intenzivní sledování, studijní a práce jsou zcela jistě dosaženo potřebné před obchodním úspěchu či neúspěchu.

Střední anglické slovo Bugge je základem pro termíny „ strašák “ a „ bubák “ jako pojmy používané pro monstrum. Ozvučnice ples , první mechanický pinball hra, byl inzerován jako „bezchybné“ v roce 1931. Problémy s vojenským zařízením během druhé světové války byly označovány jako chyby (nebo závady ). V knize vydané v roce 1942, Louise Dickinson Rich , když už mluvíme o motorového ledařství stroji, řekl: „Ice řezání byla pozastavena, dokud se tvůrce mohl být předložen, aby se chyby z jeho miláčku.“

Isaac Asimov používal termín „chyba“ se vztahují k problematice s robotem ve své povídce „ chytit ten králík “, publikoval v roce 1944.

Stránka z Harvard Mark II protokolu elektromechanických počítače, představovat mrtvé můra, která byla odstraněna ze zařízení.

Pod pojmem „chyba“ byla použita v úvahu počítačový průkopník Milosti Hopper , který propagoval příčinu poruchy v časném elektromechanických počítače. Typickým verze příběhu je:

V roce 1946, kdy byl Hopper propuštěn z aktivní služby, ona se připojila k Harvard fakultu na výpočet laboratoř kde pokračovala ve své práci na Mark II a Mark III . Provozovatelé vysledovat chybu ve Mark II k můře uvězněna ve směně, razit termín chybu . Tato chyba byla opatrně odstraněna a nahrával na knihy jízd. Vyplývající z první chybu, dnes nazýváme chyby nebo závady v programu přijat chyba .

Hopper nenašel chybu, když ochotně uznal. Datum v deníku bylo 9. září 1947. Provozovatelé, kteří ho našli, včetně William „Bill“ Burke, později z Naval Weapons Laboratory , Dahlgren, Virginie , byli obeznámeni s pojmem, a pobaveně držel hmyz s poznámkou „první skutečný případ chyby byly zjištěny.“ Hopper miloval vyprávět příběh. Tato kniha jízd, spolu s připojeným můry, je součástí kolekce Smithsonian National Museum of American History .

Příbuzným výrazem „ ladění se také zobrazí“ na předcházet jeho využití v Computing: Oxford English Dictionary " je etymologie slova obsahuje osvědčení z roku 1945, v rámci leteckých motorů.

Dějiny

TA Edison byl první používat termín „chyba“ pro technické poruchy. V roce 1878, když pracoval na žárovky, zmínil termín v soukromém dopise (který byl prodán na aukci v roce 2018).

Představa, že software může obsahovat chyby sahá až Ada Lovelace má 1843 poznámky k analytické motoru , ve kterém se hovoří o možnosti programu „karet“ pro Charles Babbage ‚s analytické motoru je chybný:

... proces analyzování musí stejně byly provedeny s cílem poskytnout analytický motor s potřebným provozním datům; a že v tomto dokumentu mohou také ležet možný zdroj chyb. Dejme tomu, že skutečný mechanismus je neomylný ve svých procesech, že karty mohou dát chybné příkazy.

„Chyby v systému“ report

Open Technology Institute, řízena skupinou, New America, vydala zprávu „Chyby v systému“ v srpnu 2016 uvedl, že američtí politici by měly reformy s cílem pomoci výzkumným pracovníkům identifikovat a adresa softwarové chyby. Zpráva „zdůrazňuje potřebu reformy v oblasti software zranitelnosti objevení a zveřejnění.“ Jeden z autorů zprávy uvedl, že Kongres nedělá dost pro řešení kybernetické softwarové zranitelnosti, přestože Kongres prošel celou řadu návrhů zákonů pro boj s větší problematiku kybernetické bezpečnosti.

Vládní vědci, podniky a bezpečnostní experti kybernetické jsou lidé, kteří obvykle objevit softwarové chyby. Zpráva vyzývá k reformování zákony počítačové kriminality a autorských práv.

Počítač podvodům a zneužívání zákona, zákona Digital Millennium Copyright a zákon na ochranu soukromí elektronických komunikacích kriminalizovat a vytvoření civilní sankce za činy, které bezpečnostní výzkumníci běžně zabývají při provádění legitimní bezpečnostní výzkum, píše se ve zprávě.

Terminologie

Zatímco použití termínu „chyba“ popisovat softwarové chyby je běžné, mnozí se domnívají, že by měla být zrušena. Jedním z argumentů je, že slovo „chyba“ je rozvedená z pocitu, že člověk způsobil problém, a namísto toho vyplývá, že vada vznikla na jeho vlastní, což vede k Push to vzdát se termín „chyba“ ve prospěch pojmů jako „vada“, s omezeným úspěchem. Od roku 1970 Gary Kildall poněkud komicky navrhl používat termín „přehmat“.

V softwarovém inženýrství, omylem metamorfózy (z řeckého meta = „change“, morph = „forma“) se vztahuje k vývoji defektu v konečné fázi nasazení softwaru. Transformace „omylem“ spáchané analytik v časných fázích životního cyklu vývoje softwaru, což vede k „defekt“ v závěrečné fázi cyklu byl nazýván ‚chybou metamorfóza‘.

Různé stupně na „chyby“ v celém cyklu může být popsán jako „chyby“, „anomálie“, „spojení“, „selhání“, „chyby“, „výjimky“, „zhroucení“, „bugs“, „vady“ , „incidenty“, nebo „vedlejší účinky“.

Prevence

Softwarový průmysl dal hodně úsilí do snižování chyb počítá. Tyto zahrnují:

typografické chyby

Chyby se obvykle objeví, když programátor udělá chybu logické . Různé inovace v programovém stylu a defenzivní programování jsou navrženy tak, aby se tyto chyby méně pravděpodobné, nebo snazší místě. Některé překlepy, zejména symbolů nebo logických / matematických operátorů , povolit program správně pracovat, zatímco jiní, jako je chybějící symbol nebo chybně napsané jméno může zabránit program z provozu. Kompilovaný jazyk může odhalit některé překlepy, když je zdrojový kód kompilovat.

metodologie rozvojové

Několik schémat napomoci řídícímu programátor aktivitu, takže méně chyby jsou vyrobené. Softwarové inženýrství (který se zabývá otázkami software designu i) se vztahuje mnoho technik, aby se zabránilo poškození. Například, formální specifikace programu uvést přesné chování programů tak, aby konstrukční chyby mohou být odstraněny. Bohužel, formální specifikace jsou nepraktické pro něco jiného než nejkratší programů, z důvodu problémů kombinatorické explozi a neurčitosti .

Unit testování zahrnuje psaní testu pro každou funkci (jednotky), která je program provádět.

V programování řízené testy jsou testy jednotky psaný před kódem a kód není považován za kompletní, dokud všechny testy úspěšně dokončeny.

Agilní vývoj software vyžaduje časté verze softwaru s relativně malými změnami. Závady jsou odhaleny pomocí zpětné vazby od uživatelů.

Open source vývoj umožňuje komukoliv zkoumat zdrojový kód. Myšlenkový směr popularizoval Eric S. Raymond jako linusův zákon říká, že populární open-source software má větší šanci mít málo nebo žádné chyby, než jiný software, protože „Pokud máte dostatek očí, všechny chyby jsou mělké“. Toto tvrzení bylo sporné, nicméně: počítačové bezpečnosti specialista Elias Levy napsal, že „je to snadno skrýt zranitelnosti v komplexu málo pochopen a nezdokumentované zdrojový kód“, protože „i když jsou lidé revizi kódu, který neznamená, že ‚re kvalifikovaní k tomu.“ Příkladem může být ve skutečnosti děje náhodně, byl OpenSSL zranitelnost v Debianu 2008 .

Podpora programovací jazyk

Programovací jazyky obsahují funkce, které pomáhají zabránit chyby, jako jsou statické systémy typu , omezených jmenné prostory a modulární programování . Například, když programátor píše (pseudokód) LET REAL_VALUE PI = "THREE AND A BIT", i když to může být syntakticky správný kód selže s kontrolu typu . Kompilovaný jazyk chytit to aniž by bylo nutné spustit program. Interpretovaný jazyk chytit takové chyby při běhu. Některé jazyky úmyslné vyloučení funkce, které snadno vést k chybám, na úkor pomalejší výkon: obecná zásada je, že je téměř vždy lepší napsat jednodušší, pomalejší kódu než nevyzpytatelný kódu, který běží o něco rychleji, a to zejména za to, že náklady na údržbu je podstatná , Například, programovací jazyk Java nepodporuje ukazatel aritmetiku; implementace některých jazyků, jako je Pascal a skriptovacích jazyků často mají runtime hranice kontrola z polí, přinejmenším v ladění sestavení.

analýza kódu

Nástroje pro analýzu kódu vývojáře pomoci tím, že kontrolu textu programového nad schopností kompilátoru rozpoznat potenciální problémy. Ačkoliv obecně problém nalezení všech programových chyb uvedené specifikace není řešitelný (viz problém zastavení TS ), tyto nástroje využívají skutečnost, že lidské programátoři mají tendenci, aby se určité druhy jednoduchých chyb, často při psaní softwaru.

Instrumentace

Nástroje pro sledování výkonu softwaru, jako je běh, buď specificky najít problémy, jako jsou překážky nebo pro poskytnutí záruky, pokud jde o opravu v práci, mohou být zakotveny v kódu explicitně (možná tak jednoduchého jako prohlášení, které říká PRINT "I AM HERE"), nebo za předpokladu, as nástroje. To je často překvapením zjistit, kde většinu času je pořízena kus kódu, a to odstraněním předpokladů by mohlo způsobit, že kód má být přepsána.

testování

Software testery jsou lidé, jejichž hlavním úkolem je najít chyby, nebo psát kód pro podporu testování. U některých projektů, může být více prostředků vynaložených na testování než při vývoji programu.

Měření v průběhu zkoušek může poskytnout odhad počtu pravděpodobných chyb zbývajících; to se stává mnohem spolehlivější, čím déle je výrobek je testován a rozvíjet.

ladění

Typický historie bug ( GNU Classpath data projektu). Nová chyba předložené uživatelem je nepotvrzené. Jakmile byl reprodukován developera, je to potvrzeno chyba. Potvrzené chyby jsou dále pevně . Chyby, které patří do jiných kategorií (neopakovatelný, nebude pevná, atd.) Jsou obvykle v menšině

Najít a opravit chyby, nebo ladění , je hlavní část počítačového programování . Maurice Wilkes , časný computing průkopník, popsal jeho realizaci v pozdních 1940s, že hodně ze zbytku jeho života by byla vynaložena zjištění chyby ve vlastních programech.

Obvykle je nejtěžší část ladění je najít chybu. Jakmile se zjistí, oprava je obvykle poměrně snadné. Programy označované jako ladicí pomoci programátorům lokalizovat chyby spuštěním kódu řádek po řádku, sledování hodnot proměnných a další funkce pozorovat chování programu. Bez debugger, kód může být přidán tak, že zprávy nebo hodnoty mohou být zapsány do konzoly nebo do okna nebo soubor protokolu trasování spuštění programu nebo zobrazit hodnoty.

Nicméně, dokonce s pomocí debuggeru, lokalizovat chyby je něco umění. To není neobvyklé, že chyby v jedné části programu způsobit selhání v úplně jiném úseku, a proto je obzvláště obtížné sledovat (například chyba v grafickém zobrazování rutina způsobuje soubor I / O rutiny selhání) v zdánlivě nesouvisející části systému.

Někdy, chyba není izolovanou vadou, ale představuje chybu, myšlení nebo plánování na straně programátora. Takové logické chyby vyžadují část programu, který má být opraven nebo přepsat. V rámci revize kódu , krokování kódu a představy nebo přepis procesu spuštění může často najít chyby, aniž by kdy reprodukovat chybu jako takový.

Více typicky, je prvním krokem při lokalizaci chyb je reprodukovat spolehlivě. Jakmile je chyba je reprodukovatelné, programátor může používat debugger nebo jiný nástroj při reprodukci chyby najít bod, ve kterém se program zbloudili.

Některé chyby jsou odhaleny vstupy, které mohou být obtížné pro programátor znovu vytvořit. Jednou příčinou Therac-25 úmrtí strojů záření byla chyba (specificky, spor ), ke které došlo pouze tehdy, když obsluha stroje velmi rychle vstoupil do léčebného plánu; trvalo dny praxe, aby se stal schopný to udělat, takže chyba neprojevili při testování nebo, pokud výrobce pokoušel se ho kopírovat. Jiné chyby může zmizet, když je program spuštěn s ladicí; Jedná se o tzv heisenbugs (vtipně pojmenoval podle Heisenbergův princip neurčitosti ).

Od roku 1990, zejména po Ariane 5 letu 501 havárii, zájem na automatizovaných prostředků pro ladění růži, jako je statické analýzy kódu pomocí abstraktní interpretaci .

Některé třídy chyb nemají nic společného s kódem. Vadný dokumentace nebo hardware může vést k problémům při používání systému, i přesto, že kód odpovídá dokumentaci. V některých případech, změny v kódu odstranit problém, přestože je kód pak již odpovídá dokumentaci. Vestavěné systémy často obejít hardwarových chyb, protože aby se nová verze ROM je mnohem levnější než repasování hardware, zejména pokud jsou komoditní položky .

Benchmark chyb

S cílem usnadnit reprodukovatelné výzkum na testování a ladění, výzkumníci používají kurátorem měřítka o chybách:

  • měřítkem Siemens
  • ManyBugs je měřítko 185 C chyb v devíti open-source programů.
  • Defects4J je měřítko 341 Java chyb z 5 open-source projektů. Obsahuje odpovídající náplastí, které se týká celé řady typu náplasti.

vedení chyba

Řízení chyb zahrnuje proces dokumentace, třídit, přiřazení, reprodukci, oprava a uvolnění opravený kód. Navrhované změny softwaru - chyby, stejně jako požadavky na úpravy a dokonce celé zprávy - jsou běžně sledovány a řízeny pomocí chyb sledovací systémy nebo problém sledovací systémy . Položky přidané lze nazvat vady, vstupenky, problémy, nebo po agilní vývojové paradigma, příběhů a eposů. Kategorie může být objektivní, subjektivní nebo jejich kombinace, jako je například číslo verze , oblasti softwaru, závažnosti a priority, stejně jako o jaký typ problému je to, jako například požadavek funkce nebo chybou.

Vážnost

Závažnost je dopad chyba má na provoz systému. Tento dopad může dojít ke ztrátě dat, finanční ztrátu dobré pověsti a plýtvání úsilí. Závažnosti úrovně nejsou standardizovány. Dopady se liší napříč průmyslem. Selhání ve videohře má úplně jiný dopad než havárie ve webovém prohlížeči, nebo monitorovacího systému v reálném čase. Například hladina chyba závažnosti by mohly být „selhání nebo viset“, „žádné řešení“ (což znamená, že žádný způsob, jak si zákazník může splnit zadaný úkol), „má řešení“ (což znamená, že uživatel může ještě splnit úkol), „vizuální defekt“(například chybí obraz nebo posunout tlačítko nebo tvarový prvek), nebo‚chyba dokumentace‘. Některé softwarové vydavatelé používat více kvalifikovaných náročnosti, jako „kritický“, „vysoká“, „nízké“, „blokátor“ nebo „triviální“. Závažnost chyby může být samostatnou kategorií na své priority pro upevnění a dvě mohou být kvantifikovány a řízeny odděleně.

Přednost

Priorita určuje, kde chyba padá na seznamu plánovaných změn. Priorita rozhoduje každý výrobce software. Priority jsou někdy číselné a někdy pojmenovaný, jako je „kritický“, „vysoká“, „nízká“ nebo „odložené“; Tyto mohou být podobné nebo dokonce totožné s stupních závažnosti při pohledu na různých výrobců softwaru. Například, priorita 1 chyby může vždy být stanovena pro příští verzi, zatímco „5“ chyby mohou být nikdy vyřešen. Průmysl praxe využívá invertovaný měřítko, aby nejvyšší prioritou jsou nízké počty (0 a 1), zatímco větší čísla označují nižší prioritu.

verze softwaru

Je běžnou praxí, uvolnit software se známými, s nízkou prioritou chyb. Většina velkých softwarových projektů udržovat dva seznamy „známých chyb“ - těch známých softwaru týmu, a ty, které mají být řečeno, aby uživatelům. Druhý seznam informuje uživatele o chyby, které nejsou opraveny v určitém uvolnění a řešení mohou být nabízeny. Zprávy jsou různého druhu. Chyby s dostatečně vysokou prioritou může vyžadovat zvláštní vydání části kódu, který obsahuje pouze moduly s těmito opravami. Tito jsou známí jako záplaty . Většina zprávy zahrnují směs změny chování a několik oprav chyb. Zpráv, které zdůrazňují chyb jsou známy jako údržby verzích. Zpráv, které zdůrazňují funkcí doplnění / změny jsou známy jako hlavní verze a často mají jména rozlišují nové funkce ze starého.

Důvody, že software vydavatel rozhodne ne na opravu či dokonce stanovit konkrétní chyby patří:

  • Lhůta musí být splněny a zdroje jsou nedostatečné opravit všechny chyby ve stanovené lhůtě.
  • Chyba je již opravena v příští verzi, a to není vysokou prioritu.
  • Požadované změny opravit chyby jsou příliš nákladné nebo ovlivnit příliš mnoho dalších komponent, které vyžadují velkou testovací aktivity.
  • To může být podezřelá, nebo známé, že někteří uživatelé se spoléhají na stávající chování kočárek; navrhovaná oprava může zavést lomu změnu .
  • Problém je v oblasti, která bude zastaralé s nadcházejícím propuštění; kterým se to zbytečné.
  • Je to „není chyba.“ Nedorozumění vzniklo mezi očekávanou a vnímanou chování, pokud takové nedorozumění není kvůli zmatku v důsledku konstrukční vady nebo chybná dokumentace.

druhy

V projektech vývoje softwaru, „chyba“ nebo „poruchy“ mohou být zavedeny v jakékoliv fázi. Chyby vznikají přehlédnutím nebo nedorozumění ze strany softwaru týmem při specifikaci, návrhu, kódování, zadávání dat nebo dokumentaci. Například poměrně jednoduchý program, podle abecedy seznam slov, návrh by mohl selhat, aby zvážila, co by se stalo, když slovo obsahuje pomlčku . Nebo při převodu abstraktní konstrukce do kódu, kodér mohl nechtěně vytvořit chyby off-by-one a nedaří vyřešit poslední slovo v seznamu. Chyby mohou být stejně jednoduché jako chyby při psaní: a „<“, kde „>“ byla určena.

Další kategorie chyba se nazývá spor, který může nastat, když programy mají více komponent vykonávající současně. V případě, že komponenty komunikovat v jiném pořadí, než je developer určené, mohly by překážet spolu navzájem a zastavení programu v dokončení svých úkolů. Tyto chyby může být obtížné zjistit ani předvídat, protože nemusí dojít při každém provedení programu.

Koncepční chyby jsou nedorozumění vývojářský toho, co software musí udělat. Výsledný software může provádět v souladu s porozuměním developera, ale ne to, co je opravdu potřeba. Ostatní typy:

Aritmetický

Logika

Syntax

  • Použití nesprávného operátora, jako je provádění úkolu namísto testu rovnosti . Například, v některých jazycích x = 5 nastaví hodnotu x až 5, zatímco x == 5 zkontroluje, zda x je v současné době 5 nebo jiné číslo. Interpretovaný jazyk, aby takový kód k nezdaru. Kompilovaný jazyk může zachytit takové chyby před začátkem testování.

prostředky

Multi-threading

propojení

  • Nesprávné použití API.
  • Implementace nesprávné protokol.
  • Nesprávná manipulace hardware.
  • Nesprávné předpoklady určitou platformu.
  • Nekompatibilní systémy. Nová API nebo komunikační protokol zdánlivě fungovat, když se dva systémy používají různé verze, ale může dojít k chybám při funkce nebo funkce implementována v jedné verzi se změní, nebo chybí v jiném. V produkčních systémech, které musí běžet nepřetržitě, vypnutí celého systému pro velkou aktualizaci nemusí být možné, například v telekomunikačním průmyslu nebo na internetu. V tomto případě menší segmenty velkého systému jsou inovovány individuálně, aby se minimalizovalo narušení velké sítě. Nicméně, některé úseky by mohly být přehlédnuty a neaktualizováno a chyby příčina s kompatibilitou, které mohou být obtížné najít a opravit.

Týmová práce

  • Unpropagated aktualizace; například změny programátor „myAdd“, ale zapomene změnit „mySubtract“, který používá stejný algoritmus. Tyto chyby jsou zmírněny udělej Neopakujte filozofie.
  • Komentáře zastaralé nebo nesprávné: mnoho programátorů předpokládat připomínky přesně popsat kód.
  • Rozdíly mezi dokumentací a produktu.

Dopady

Množství a typ poškození softwarová chyba může způsobit přirozeně ovlivňuje rozhodování, procesy a politiku týkající se kvality softwaru. V aplikacích, jako je pilotovaných kosmických letů či bezpečnosti automobilů , protože softwarové chyby mají potenciál způsobit zranění osob nebo dokonce smrt, takový software bude mít mnohem větší kontrolu a kontrolu kvality, než například, online nakupování internetové stránky. V aplikacích, jako je například bankovnictví, kde softwarové chyby mají potenciál způsobit vážné finanční škody na banky nebo jejích zákazníků, kontrola kvality je také mnohem důležitější, než, řekněme, aplikace pro úpravu fotografií. NASA Software Assurance Technology Center se podařilo snížit počet chyb na méně než 0,1 na 1000 řádků kódu ( Smístní ), ale toto nebylo pociťováno jako možné pro projekty v obchodním světě.


Známé chyby

Řada softwarových chyb se staly dobře známé, většinou z důvodu jejich závažnosti: příklady zahrnují různá místa a vojenské pády letadel. Možná nejslavnější chyba je problém Year 2000 , také známý jako Y2K bug, ve kterém to bylo se obával, že celosvětový ekonomický kolaps by se stalo na začátku roku 2000 jako důsledek počítačů myšlení to bylo 1900. (Na konci , došlo k žádné závažné problémy.)

Rozvrat 2012 obchodování s akciemi podílejí jednu takovou neslučitelnost mezi starým a novým API API.

V populární kultuře

  • V roce 1968 román 2001: Vesmírná odysea (a jeho odpovídající 1968 filmové adaptace ), palubní počítač kosmické lodi se, HAL 9000 , pokusí se zabít všechny své členy posádky. V návaznosti 1982 románu, 2010: Odyssea dva a doprovodná 1984 filmu, 2010 , to je ukázal, že tato akce byla způsobena počítače, které byly naprogramovány s dvěma protichůdnými cíli: plně zveřejnit veškeré své informace a udržet skutečný účel letu tajemství z posádky; tento konflikt způsobil HAL, aby se stal paranoidní a nakonec vraždící.
  • V 1999 americká komedie kancelářské prostory , tři pracovníci zneužít zaujetí své společnosti s kterým se Y2K počítačovou chybu tím, že nakazí počítačového systému společnosti s virem, který posílá zaoblenou haléře na zvláštním bankovním účtu. Tento plán selže, protože virus sám o sobě má vlastní chyba, která odesílá velké množství peněz na účet předčasně.
  • V roce 2004 román Bug , od Ellen Ullman , je o pokus programátora, aby nalezly nepolapitelný chyba v databázové aplikace.
  • V roce 2008 kanadský filmový Control Alt Delete je o programátor na konci roku 1999 bojuje opravit chyby v jeho společnosti vztahující se k roku 2000 problému.

viz též

Reference

externí odkazy