Ţivotní cyklus IS Vývoj informačních systémů
Motivace Doposud jsme předpokládali, ţe IS někdo vytvořil, ţe perfektně funguje a nijak se v čase nevyvíjí To ovšem naprosto není pravda. Vůbec jsme se nezabývali otázkou, jak IS vymyslet, navrhnout a sledovat tak, aby fungoval, neobsahoval chyby a aby se modifikoval podle měnících se poţadavků To bude náplní zbývajících přednášek
Příklady některých havárií (1) Problém typu Y2K: V roce 1992 dostala paní Mary z Winona ve státě Minnesota v USA pozvánku k návštěvě mateřské školy. Pani Mary bylo v té době 104 let. Přestupný rok: Supermarket dostal dne 29. února 1988 pokutu 1000 $ za to, ţe prodával maso, které mělo o jeden den prošlou záruční lhůtou. Program, který tiskl dobu trvanlivosti na balíčky s masem nepočítal s tím, ţe rok je přestupný.
Příklady některých havárií (2) Nesprávný interface: 10 dubna 1990 opustil vlak podzemní dráhy v Londýně stanici bez řidiče. Řidič zmáčkl tlačítko, které startovalo vlak a spoléhal se na automatické zajištění, které neumoţňovalo odjezd vlaku s otevřenými dveřmi. Protoţe se dveře zpříčily a nebylo je moţné zavřít automaticky, vystoupil řidič z vlaku aby dveře uvolnil. Jakmile se tak stalo, vlak jednoduše odjel bez řidiče.
Příklady některých havárií (3) Bezpečnost: 2 listopadu 1988 byl do Internetu vypuštěn virus, který dnes označujeme jako internetový červ. Virus vyuţil zranitelnosti některých síťových sluţeb jako např. Unixové posílání pošty a začal se nekontrolované šířit. Výsledkem bylo napadení asi 10 % procent všech internetových počítačových uzlů, kde zaplnil celou paměť a způsobil výpadek počítače. Trvalo několik dnů neţ byly problémy odstraněny.
Příklady některých havárií (4) Překročení rozpočtu a pozdní dodání: V roce 1995 chyba v automatickém systému kontroly zavazadel na novém letišti v Denveru způsobila ničení zavazadel. Letiště bylo uzavřeno a znovu otevřeno aţ po 16 měsících, kdy rozpočet na dodání systému byl překročen o 3,2 miliardy dolarů a manipulace se zavazadly byly prováděny převáţně ručně.
Příklady některých havárií (5) Dodání včas: Za 18 měsíců a 200 milionů dolarů byl v roce 1984 předán systém pro zdravotní pojišťovnu ve Wisconsinu. Systém však nikdy nepracoval dobře. Bylo zjištěno přeplacení účtů o 60 milionů dolarů a trvalo další tři roky systém opravit.
Příklady některých havárií (6) Zbytečná složitost: Přepravní letoun C- 17 firmy McDonnell Douglas překročil rozpočet o 500 milionů dolarů, protoţe byly problémy v navigačním systému. Vybavení letounu mělo na palubě 19 počítačů, 80 mikroprocesorů a při jeho implementaci bylo pouţito 6 různých programovacích jazyků.
Podrobnější rozbor jedné počítačové havárie Londýnský záchranný systém byl navrţen počátkem devadesátých let a měl být plně automatický. Základní částí systému byla počítačem podporovaná pomoc, vozidla záchranné sluţby byly automaticky naváděny, řidiči měli na palubě počítačovou mapu a hlasová komunikace byla zaloţena na radiovém spojení.
Projevy havárie Dne 26. a 27. října 1992 se systém zhroutil. Řidiči nevěděli kde jsou. K jednomu případu vyjelo několik vozidel. V řídícím centru byl přeplněné kontrolní obrazovky a přetíţené telefony. Bylo přetíţené radiové spojení. Při zavolání sluţby byla odpověď aţ za 10 minut, přičemţ pouze 20% volání bylo úspěšných. Vznikla situace, která ohroţovala lidské ţivoty.
Důvody havárie (1) Nesmyslný návrh - Zadání projektu bylo 6.3.1991, ukončení výběrového řízení 15.4.1991, implementace systému konec roku 1991, smlouva s dodavatelem podepsána v srpnu 1991, systém předán 8.1.1992
Důvody havárie (2) Nezkušenost - Celkem se o projekt ucházelo 17 realizátorů. Oborníci, kteří prováděli analýzu zadání doporučovali, aby byl poţadován úplný systém za 1,5 milionů s dobou zpracování 18 měsíců. Byl akceptován neúplný systém za 937 000, který byl dodán za 5 měsíců. Firma, která získala zakázku pouţila CASE (Computer Aided Software Engineering) systém, který se teprve učila, nikdy podobný systém nerealizovala a na tvorbu systému měla v době zadání 35 000.
Důvody havárie (3) Mnoho automatizace - Lokalizace vozidel byla přímo podle hlášení případů, personál řídícího centra zasahoval aţ po 11 minutách. Nebyla ţádná písemná dokumentace. Předpokládala se stoprocentní spolupráce řidičů záchranných vozidel, přitom řidiči nebyli dostatečné ohodnoceni.
Důvody havárie (4) Uživatelské problémy - Posádky vozů nebyly při tvorbě systému konzultovány. Uţivatelé byli vyškoleni dříve, neţ byl systém realizován. Systém neakceptoval prioritu operátorů v centru. Špatná lokalizace byla mnohem častější neţ při předchozí hlasové komunikaci s operátory.
Důvody havárie (5) Softwarové chyby - Na kontrolních obrazovkách bylo mnoho informací, které však nebyly pro nedostatek paměti ukládány. V kritické dny nebyli ve sluţbě ţádní záloţní operátoři. Systém byl 26.10 uveden do provozu se dvěma váţnými a 44 malými chybami. Programátoři zapomněli odstranit část ladicích tisků, která způsobila ztrátu informací na serverech. Celý systém byl napsán ve variantě programovacího jazyku Basic.
Důvody havárie (6) Špatný uživatelský interface - Zprávy rolovaly po obrazovce a nebylo je moţné zastavit, posádka vozu mohla velmi snadno na ovládacím panelu zmáčknout špatný knoflík, tiskárny bylo moţné vypnout, aniţ se zprávy někde ukládaly.
Důvody havárie (7) Špatný management projektu -Nikdo nechtěl projekt vést, nikdo nepracoval na projektu na plný úvazek, programátoři nezvládli pouţitý CASE nástroj, softwarové změny se prováděly za pochodu, celý systém nebyl nikdy předem otestován.
Důsledky Má-li se zabránit haváriím, nezbytně se musí zlepšit řízení. Na IT je třeba pohlíţet jako na nekonečný cyklus, který se neustále vyvíjí a upravuje.
Ţivotní cyklus IS Specifikace. Definujeme především funkce a omezení systému. Návrh a implementace. Snaha o vytvoření systému, který splňuje specifikace. Validace softwaru. Software musí být testován tak, aby se prokázalo, ţe splňuje poţadavky zadavatele. Evoluce softwaru. Software se musí vyvíjet tak, aby byl schopen uspokojit potřeby zákazníka v případě změn.
Ţivotní cyklus IS Specifikace Návrh a implementace Evoluce Validace
Nezbytné činnosti Uvedené 4 body v sobě zahrnují: řízení projektu analýzu návrh implementaci zajištění kvality údrţbu
Modely ţivotního cyklu Model vodopád- Jednotlivé aktivity jsou zpracovány jako nezávislé procesy, které na sebe navazují. Evoluční model - Tento přístup prokládá jednotlivé etapy realizace kontrolou se zákazníkem a jejich paralelním zpracováním tak, aby se postupné verze realizovaného systému co nejrychleji blíţily poţadavkům zákazníka. Formální návrh -Tento přístup je zaloţen na vytvoření formálního matematického modelu specifikace systému, který je převeden do programové podoby. Verifikace systému je odvozena z matematického dokazování specifikací. Znovupoužití vývoje - Tento přístup je zaloţen na faktu, ţe existuje značné mnoţství komponent do nově vytvářeného systému.
Smůla V praxi se tak zpravidla nepostupuje. Důsledkem je, ţe: průměrně 50% velkých projektů trvá déle neţ bylo odhadnuto ¾ velkých projektů mají provozní chyby ¼ velkých projektů je zrušena
V ČR na tom nejsme nejhůř Statistiky USA z počátku 80.let ukazují, ţe: 2% programů se pouţívají tak, jak byly vytvořeny, 2-3% se pouţívají po mírném dopracování, nepřekračujícím 10-15% zdroj. textů, 20% bylo nutno přepracovat zásadním způsobem,
pokračování 20% vráceno a přepracováno (vesměs na základě nových kontraktů), 50% zákazník program nikdy nepouţil, 5% program shledán nepouţitelným
pokračování 2%používají se, jak byly vytvořeny 3%používají se po mírnémdopracování 20%bylo nutno přepracovat 20%vráceno a přepracováno 50%zákazník programnikdy nepoužil 5%programshledán nepoužitelným
Děkuji za pozornost