Ako sa vyhnúť problémom so softvérom

V tejto digitálnej ére ste už určite počuli o gigantoch sociálnych médií, ako sú Facebook a Twitter, a o platformách elektronického obchodu, ako sú Alibaba a Amazon. Tieto online webové stránky sa pri svojej činnosti spoliehajú na rôzne softvérové ​​balíky. Tieto programy celkom úprimne zmenili spôsob, akým pracujeme, myslíme a žijeme.

Okrem toho mnohé zariadenia, ktoré boli predtým výlučne mechanického charakteru, sú teraz ovládané softvérom. Napríklad termostaty boli kedysi elektromechanické zariadenia. Teraz sa však pri prevádzke vo veľkej miere spoliehajú na softvér.

však softvérové ​​chyby môže byť dosť problematické, najmä ak sa na ne spoliehame pri každodenných činnostiach. V skutočnosti došlo k niekoľkým prípadom, kedy softvér nesplnil svoj zamýšľaný účel, čo viedlo k nepríjemným výsledkom.

V tomto článku hovoríme o 4 príležitostiach, v ktorých sa výkon softvéru výrazne minul svojmu cieľu a ako sa takýmto problémom so softvérom vyhnúť.

1. Výpadok 911 viacerých štátov v USA

911 je kritická služba, ktorá umožňuje jednotlivcom kontaktovať pohotovostný personál kedykoľvek je to potrebné. Niekedy môže kontakt s dispečermi tiesňového volania cez 911 doslova znamenať rozdiel medzi životom a smrťou.

Preto bola poriadna katastrofa, keď 9. apríla 2014 Smerovanie hovoru na číslo 911 zlyhalo v siedmich štátoch USA vrátane Kalifornie, Floridy, Minnesoty, Severnej Karolíny, Pensylvánie, Južnej Karolíny a Washingtonu.

Tento výpadok bol spôsobený chybou kódovania, ktorej sa dalo predísť, ku ktorej došlo v centre riadenia tiesňových volaní v Colorade, ktoré vlastnila spoločnosť Intrado.

2. Uzemnenie flotily United Airlines

V júli 2015 boli United Airlines nútené uzemniť celú svoju flotilu lietadiel v dôsledku chyby softvéru. Ovplyvnilo to viac ako 4 900 letov na celom svete a mnoho cestujúcich zostalo uviaznutých na letiskách a celkom zjavne frustrovaní.

Pravdepodobne to malo aj ekonomický dopad, pretože letecká spoločnosť by musela mnohým cestujúcim kompenzovať nepríjemnosti. Pravdepodobne došlo aj k niekoľkým dôležitým obchodným stretnutiam, ktoré boli zmarené kvôli uzemneniu.

3. Porucha plynového pedálu Toyota Camry

V septembri 2007 cestovala Jean Bookout po diaľnici Interstate 69 v Oklahome s pasažierkou Barbarou Schwarz, keď sa dostala do ťažkostí. ovládanie jej Toyoty Camry.

Pokúsila sa zdvihnúť nohy z plynu, ale auto ďalej zrýchľovalo. Brzdový pedál nezastavil auto a bola nútená použiť núdzovú brzdu.

Nanešťastie to poslalo auto do nábrežia. Schwarz v dôsledku toho zomrel a Bookout bol hospitalizovaný na päť mesiacov kvôli vážnym zraneniam.

Špekulovalo sa, že k nehode došlo kvôli niekoľkým chybám v kódovaní, ktoré viedli k zlyhaniu úlohy v CPU Camry. Tento procesor by ovládal mimoriadne veľké množstvo funkcií vrátane zapaľovania, ovládania plynu a tempomatu.

Kód Toyoty sa stal zamotaným neporiadkom po niekoľkých rokoch, keď sa nové kódy hromadili na starých. Toto sa zvyčajne označuje ako „kód špagiet“.

Bookoutova nehoda však tento problém odhalila a poukázala na chyby Toyoty v ich softvérovom procese. Dokonca sa zistilo, že existuje viac ako 10 miliónov spôsobov môže dôjsť k nežiaducemu zrýchleniu, na základe spôsobu, akým bol štruktúrovaný kód Toyoty.

Porucha termostatu Nest

Nest je spoločnosť, ktorú vlastní Alphabet, to robí inteligentné termostaty. Tieto termostaty sú celkom šikovné a umožňujú používateľom ovládať teplotu vo svojich domovoch zo svojich smartfónov.

Minulú zimu termostaty Nest zažil poruchu vo forme chybnej aktualizácie softvéru, ktorá spôsobila vybitie ich batérií. Bohužiaľ, táto chyba sa stala uprostred zimy a niekoľko používateľov zostalo dočasne bez tepla. To je určite niečo, čo nechcete, aby sa stalo v tomto ročnom období.

Stručná analýza softvérových problémov

Prístupy ako dizajn založený na modeli a TLA+ umožňujú vývojárom získať väčší prehľad o tom, ako ich softvér funguje.

Brett Victor, prominentný počítačový výskumník, sa domnieva, že existuje odpojenie medzi programátormi a problémami, ktoré sa snažia vyriešiť pomocou kódov.

Kvôli tomuto odpojeniu je pre programátorov ťažké predstaviť si, čo sa pokúšajú vložiť do kódov. Victor si myslí, že toto je jeden z faktorov, ktoré prispievajú k tomu, že softvér je plný chýb.

Je tu však nádej. Prístupy ako napr dizajn založený na modeli a TLA+ umožňujú vývojárom získať väčší prehľad o tom, ako ich softvér funguje.

Dizajn založený na modeli, ako už názov napovedá, umožňuje vývoj softvéru prostredníctvom vizuálnych modelov. TLA+, čo je skratka pre Temporal Logic of Actions, je jazyk určený na písanie špecifikácií počítačového programu. Na TLA+ je skvelé to, že umožňuje dôkladné testovanie a overovanie softvéru pred jeho zverejnením.

Dizajn založený na modeli aj TLA+ sa už osvedčili. Esterel technológie, spoločnosť zaoberajúca sa vývojom softvéru, používa modelový dizajn na vytváranie softvéru kritického z hľadiska bezpečnosti, zatiaľ čo TLA+ používajú napr. Microsoft opraví možnú katastrofickú chybu Xboxu a Európska vesmírna agentúra prepíše kódy pre sondu, ktorá pristála na kométa.

Proces písania kódu si programátori veľmi vážia. Mnohí z nich sú jednoducho zaujatí procesom písania kódov. Je preto výzvou primäť niektorých programátorov, aby akceptovali prístupy, ako je dizajn založený na modeli a TLA+. Tieto prístupy sú často vnímané ako striktne akademické bez životaschopnosti v reálnom svete. Zmena pohľadu však musí prísť čo najskôr.

Záverečné myšlienky

Softvér sa čoraz viac používa v aplikáciách, ktoré si vyžadujú zabudované bezpečnostné opatrenia. Lepšie metódy navrhovania softvéru musia byť zavedené plošne, pretože takéto aplikácie sú v našich životoch životne dôležité.

Procesy ako automatizácia sa v dnešnej dobe do veľkej miery spoliehajú na softvér, ale jedna chyba v riadku kódu nás môže viesť k veľkým neúspechom, ako ukazujú vyššie uvedené prípady.

Teraz si predstavte niečo ako umelú inteligenciu (AI), ktorá je začlenená do týchto aplikácií. AI je sám o sebe dosť desivý bez softvérových chýb. Pridajte chyby do mixu a nedá sa povedať, čo sa môže stať.

Je tu však strieborná hranica. S trochou práce a niektorými novými nástrojmi môžeme vytvoriť lepší softvér a AI tak, že ich navrhneme spoľahlivejšie a otestujeme ich.

Dúfajme, že tento kritický problém budú príslušné orgány brať vážne, aby sme mohli softvér naplno využiť, ale len na vybudovanie bezpečnejšej a inteligentnejšej budúcnosti.