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

Slides:



Advertisements
Podobné prezentace
Návrh státního rozpočtu ČR na rok 2010 Ministerstvo financí září 2009.
Advertisements

Software Development Conference 2007 Vztah dodavatele a odběratele Zdeněk Borůvka.
VN zdroj pro TILECAL vila Lanna
Podprogram pro začínající včelaře Číslo podprogramu: PF
Dohled nad zadáváním veřejných zakázek v České republice
Harmonogram implementace IS v běžné praxi - informatika ZMVS.
Stručný úvod do UML.
M A N A G E M E N T 3 Akad. rok 2009/2010, Letní semestr
VYŘIZOVÁNÍ OBJEDNÁVEK
11 Udržovatelnost a servisní logistika
Projektové řízení Modul č.1.
Jan Syrovátka Jiří Hradský.  Výrobní program orientovaný na výrobu knih pro české i zahraniční nakladatele  Nabízí kompletní výrobu knihy od grafického.
poskytujeme služby v oblasti ochrany majetku a osob (EZS, EPS, CCTV …) od roku 2004 poskytujeme služby v oblasti logistiky a zabezpečení vozidel (systém.
S YTÉMOVÁ INTEGRACE Ing. Jiří Šilhán. S YSTÉMOVÁ INTEGRACE Jedná se o přístup, který přispívá k integraci nesourodých výpočetních systémů. Vyplývá ze.
SOFTWARE operační systémy
Přednáška č. 5 Proces návrhu databáze
Diagramy případů užití.
Projekt EU Dotace Informační systém sloužící k čerpání dotací ze struktur Evropské unie. FIMU PV104.
Přínosy metodik  Větší produktivita a kooperace týmů  Komunikační standard  Specializace projektových týmů  Nezávislost na konkrétních řešitelích 
MONITOROVACÍ ZPRÁVY v OP VK Seminář pro příjemce v rámci globálních grantů Olomouckého kraje Olomouc, 20. a 21. dubna 2009.
SIS - Supermarket Informační Systém 1 Komplexní řešení toků zboží v supermarketu.
Facility management ČSN EN
Definování prostředí pro provozování aplikace dosud jsme řešili projekt v obecné rovině aplikace bude ovšem provozována v konkrétním technickém a programovém.
Palatinum Excellence Software na řízení firmy. 1.Proč Software Excellence 2.Představení Software Excellence 3.Jak zavést do praxe Obsah Prezentace.
1 E - S V Ě T S E T O Č Í S T Á L E R Y C H L E J I. S T A Č Í T E M U ? Praktická realizace bezpečnostních požadavků standardů ISVS při tvorbě.
Lenka Fialová Martina Procházková Ondřej Soukup Martin Valenta Cyril Vojáček 1.
Proces řízení projektu
Aukro.cz – projektový management v e-commerce Tereza Kabrdová.
3. Životní cyklus a procesy projektu
Geo-informační systémy
Přístupnost internetové prezentace Českého statistického úřadu
Cvičná hodnotící prezentace Hodnocení vybraného projektu 1.
2 Jan Tomíšek Nová organizace služeb 3 Základní typy služeb poskytovaných společností Vema operativní hotline konzultace školení implementační implementace.
Operační systémy.
1 Informační systém autoservisu Softwarové inženýrství 2003.
Zavádění a údržba informačních systémů
Zkušenosti ze zavedení systému řízení kvality informačních služeb
Možnosti modelování požadavků na informační systém
INFORMAČNÍ SYSTÉMY Semestrální projekt 2013/2014 Podmínky udělení zápočtu Ing. Roman Danel, Ph.D. Institut ekonomiky a systémů řízení.
Rozvoj nehlasových služeb Současnost a budoucnost mobilních sítí
Strana: 1 © Vema, a. s. Ucelené řešení pro řízení lidských zdrojů, ekonomiky a logistiky.
Gymnázium, SOŠ a VOŠ Ledeč nad Sázavou I NFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE Ing. Jan Roubíček.
Dokumentace informačního systému
Ivo Novotný Jak vybrat dodavatele vzdělávání JAK SI SPRÁVNĚ VYBRAT... Dodavatele vzdělávání.
Realizační tým ICZ duben 2005
Přednáška č. 1 Proces návrhu databáze
Projekt z PA104 Richard Benkovský (139912, Jan Horák (143443, Miroslav Ligas (139542, Tomáš.
Sledování vozidel v reálném čase a využití pro informování cestujících
Přístup k řešení bezpečnosti IT Nemochovský František ISSS Hradec Králové, dubna 2005.
1 Řízení implementace IS a SS* Šablony. 2 Vzorové postupy.
SIS - Supermarket Informační Systém 1 Supermarket Informační Systém Komplexní řešení toků zboží v supermarketu.
2. Životní cyklus a procesy projektu
Specifikace požadavků na IS Vývoj informačních systémů.
Metodika řízení projektů
Helios Orange - Implementace systému
Sjednocení technologické platformy Policie ČR CZ.1.06/1.1.00/ Sjednocení technologické platformy Policie ČR CZ.1.06/1.1.00/ Projekt je.
Zabezpečení dat a komunikační infrastruktury Policie ČR CZ.1.06/1.1.00/ Zabezpečení dat a komunikační infrastruktury Policie ČR CZ.1.06/1.1.00/
Téma 13: Finanční plánování
Operační systém (OS) Základní funkce operačního systému: – Zajištění komunikace s okolím. – Řízení a zpracování programů. – Údržba informací na externích.
Digitální učební materiál Název projektu: Inovace vzdělávání na SPŠ a VOŠ PísekČíslo projektu: CZ.1.07/1.5.00/ Škola: Střední průmyslová škola a.
Digitální učební materiál Název projektu: Inovace vzdělávání na SPŠ a VOŠ PísekČíslo projektu: CZ.1.07/1.5.00/ Škola: Střední průmyslová škola a.
SOFTWARE Operační systémy.
Vysoká škola technická a ekonomická
Tradiční metodiky vývoje softwaru
Tradiční metody vývoje softwaru
Sytémová integrace Ing. Jiří Šilhán.
KPV/PIS Websol s.r.o. Jaroslav Plzák Lukáš Choulík Tomáš Kraus.
METODOLOGIE PROJEKTOVÁNÍ
Elektronizace v prostředí justice
Transkript prezentace:

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í  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 , ukončení výběrového řízení , implementace systému konec roku 1991, smlouva s dodavatelem podepsána v srpnu 1991, systém předán

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 £, 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í £.

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 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 Návrh a implementace ValidaceEvoluce Specifikace

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í

Děkuji za pozornost