IT katastrofy a ich prevencia

Autor: Ľuboš Saloky | 11.5.2011 o 16:45 | (upravené 11.5.2011 o 17:58) Karma článku: 4,73 | Prečítané:  1128x

Vývoj softvéru je náročný proces, ktorý mnohokrát sprevádza prekročenie rozpočtových limitov, zmeny cieľov, slabá komunikácia a rastúca komplexnosť. Napriek snahe potlačiť tieto riziká, nedokážeme ich zatiaľ úplne vylúčiť. To občas vedie ku katastrofálnym výsledkom.

Rádioterapeutický prístroj Therac-25 za určitých okolností ožiaril pacientov dávkou, ktorá mohla byť smrteľná. Zariadenie nemalo hardvérovú ochranu pre prípad nesprávneho nastavenia. Bol použitý softvér zo staršej verzie prístroja, v ktorom bola implementovaná hardvérová ochrana. Softvér nebol počas vývoja nikdy testovaný na hardvéri, ktorý bol použítý v nemocnici. Prehnaná dôvera k prístroju spôsobila, že prvotné sťažnosti pacientov boli zo strany nemocničného personálu ignorované.

Strata sondy Phobos 1 bola spôsobená vypnutím stabilizačného systému a následnej straty energie z dôvodu vybitia batérií. Systém bol vypnutý sekvenciou príkazov, ktoré mali byť spustené iba počas testovania na Zemi. Z dôvodu časovej úspory bola sonda vypustená so softvérom používaným počas testovania.

Sonda Mars Climate Orbiter zlyhala tiež vďaka softvérovej chybe. Motor pracoval s anglickými mierami (ťah v librách) a NASA komunikovala so sondou v metrických mierach (ťah v Newtonoch). Sonda sa dostala príliš blízko k povrchu Marsu a zhorela.

Družica CryoSat-1 bola zničená softvérovou chybou nosnej rakety. Príkaz pre vypnutie a oddelenie druhého stupňa rakety sa v programe nenachádzal. Druhý stupeň rakety sa neoddelil, horel až kým sa mu neminulo palivo a raketa nedosiahla obežnú dráhu.

Tieto a im podobné katastrofy viedli Freda Booksa k napísaniu knihy „The Mythical Man-Month" - knihy, ktorú každý cituje, niektorí ju čítajú a málokto ju nasleduje. V knihe sú načrtnuté niektoré základné zásady prevencie zlyhania IT projektov.

Kontrola časového plánu

Neustále sa hromadiace drobné zdržania vyprodukujú výrazné zdržanie projektu. Priebežná kontrola dosahovania malých míľnikov je nevyhnutná na všetkých úrovniach riadenia.

Dokumentácia

Každý projektový manažér by mal pripraviť dokumenty vysvetľujúce ciele projektu, ako ich dosiahnuť, kto a kedy ich má dosiahnuť, koľko to má stáť. Tieto dokumenty môžu pomôcť odhaliť skrytú nekonzistentnosť alebo iné riziká súvisiace s projektom.

Verzionovanie

Požiadavky sa môžu zmeniť aj počas vývoja softvéru. Niektoré vlastnosti systému sa teda priebežne menia, čo sa však môže diať len do určitej miery. Inak softvér nebude nikdy hotový. Po určitom dátume, pridávanie nových vlastností má byť zakázané a všetky požiadavky na zmenu budú vybavené až v ďalšej verzii softvéru.

Komunikácia

Tímy pracujúce na projekte by mali mať vytvorené komunikačné kanály. Namiesto domýšľania, implementátor by sa mal opýtať architektov, aký je zámer. Architekti sú zodpovední za formulovanie základných myšlienok projektu a komunikáciu týchto myšlienok ostatným členom tímu.

Pilotný systém

Pri návrhu zbrusu nového systému tím vyvinie systém na jedno použitie (bez ohľadu na to, či to tak aj naozaj zamýšľa). Takýto systém spravidla odhalí dôvody, ktoré neskôr spôsobia kompletný redizajn systému. Až tento druhý systém by mal byť dodaný zákazníkovi, pretože dodanie pôvodného systému spôsobí agóniu zákazníka a pravdepodobne zruinuje reputáciu produktu (alebo celej firmy).

Páčil sa Vám tento článok? Pridajte si blogera medzi obľúbených a my Vám pošleme email keď napíše ďalší článok
Pridaj k obľúbeným

Hlavné správy

TECH

Miliardy ľudí čoskoro zažijú nevídanú klímu

Klimatická zmena prebieha nad zemou rýchlejšie ako nad oceánmi. Takmer polovica dnes žijúcich ľudí zažije podnebie aké nepoznáme

DOMOV

Sudca Hrubala: Neviem, či bol Procházka politická objednávka. Vyzerá to tak

Združenie Za otvorenú justíciu sa zrejme zmení na think-tank.

DOMOV

Kaliňák nechal schátrať ubytovňu pre policajtov. Teraz sa jej chce zbaviť

Ministerstvo zaplatilo 175-tisíc za projekt, ktorý skončil v koši.


Už ste čítali?