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é:  1125x

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

DOMOV

Minúta po minúte: Fico bude opäť kandidovať na šéfa Smeru, s Kaliňákom útočili na médiá

Vo funkcii podpredsedov skončia Čaplovič a Paška. Kandiduje aj Kaliňák.

DOMOV

Odhalila kauzu predsedníctva. Odkiaľ prišla Zuzana Hlávková?

Gymnázium, ktoré navštevovala, jej plánuje vyjadriť verejnú podporu.

KULTÚRA

Milan Lasica: Už nemôžem umrieť predčasne

Keby som mohol, správal by som sa úplne inak, tvrdí.


Už ste čítali?