Vývoj informačních systémů Životní cyklus IS. Motivace  Doposud jsme předpokládali, že IS někdo vytvořil, že perfektně funguje a nijak se v čase nevyvíjí.

Prezentace na téma: "Vývoj informačních systémů Životní cyklus IS. Motivace  Doposud jsme předpokládali, že IS někdo vytvořil, že perfektně funguje a nijak se v čase nevyvíjí."— Transkript prezentace:

1 Vývoj informačních systémů Životní cyklus IS

2 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

3 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ý.

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

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

6 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ě.

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

8 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ů.

9 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í.

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

11 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

12 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 £.

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

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

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

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

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

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

19 Ž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.

20 Životní cyklus IS Návrh a implementace ValidaceEvoluce Specifikace

21 Nezbytné činnosti  Uvedené 4 body v sobě zahrnují: –řízení projektu –analýzu –návrh –implementaci –zajištění kvality –údržbu

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

23 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

24 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,

25 …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

26 …pokračování

27 Děkuji za pozornost