reklama

IT katastrofy a ich prevencia

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.

Písmo: A- | A+
Diskusia  (2)

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.

SkryťVypnúť reklamu
Článok pokračuje pod video reklamou

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.

SkryťVypnúť reklamu
reklama

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.

SkryťVypnúť reklamu
reklama

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).

Ľuboš Saloky

Ľuboš Saloky

Bloger 
  • Počet článkov:  11
  •  | 
  • Páči sa:  0x

Pracujem v sektore informačných technológií. Zaujímam sa o to, ako svet funguje. Zoznam autorových rubrík:  ITNezaradené

Prémioví blogeri

Adam Valček

Adam Valček

14 článkov
Jiří Ščobák

Jiří Ščobák

752 článkov
Pavol Koprda

Pavol Koprda

10 článkov
Juraj Karpiš

Juraj Karpiš

1 článok
Monika Nagyova

Monika Nagyova

295 článkov
reklama
reklama
SkryťZatvoriť reklamu