UNIVERZITA PARDUBICE FAKULTA EKONOMICKO - SPRÁVNÍ BAKALÁSKÁ PRÁCE Hana Polanská, DiS.

Transkript

1 UNIVERZITA PARDUBICE FAKULTA EKONOMICKO - SPRÁVNÍ BAKALÁSKÁ PRÁCE 2008 Hana Polanská, DiS.

2 Univerzita Pardubice Fakulta ekonomicko - správní Trendy v pístupech k životnímu cyklu vývoje informaního systému (SDLC) Bakaláská práce

3 Zadávací List 3

4 Podkování Ráda bych podkovala pedevším vedoucímu mé bakaláské práce Ing. Pavlu Jiravovi, Ph.D. za všechny pipomínky, rady a pedevším velkou podporu a trplivost pi zpracování bakaláské práce. Chtla bych podkovat všem, kteí mi pomáhali radou i pipomínkami, pípadn jinak. Pedevším mé seste Mgr. Michaele Polanské. 4

5 SOUHRN Bakaláská práce je zamena na shrnutí a zhodnocení souasných pístup k životnímu cyklu tvorby informaního systému. Jaký je trend v pístupu k životnímu cyklu informaního systému a v em se liší. Seznámíme se s konkrétními modely pro tvorbu informaního systému. Klasické modely jsou porovnávány s modely moderními. V závru práce je podrobn rozebrána problematika informaního systému veejné správy a nezbytné dokumenty pro jeho tvorbu. KLÍOVÁ SLOVA Informaní systém, životní cyklus informaního systému, SDLC = životní cyklus vývoje systému. TITLE TRENDS IN ACCESSES TO LIVE CYCLE DEVELOPMENT OF INFORMATICS SYSTÉM ABSTRACT The bachelor s work is intent on summarize and evaluate concurrent access of live cycle of making to informatics system. How is trend in access of live cycle informatics system and how are existing different. We acquaint with concrete models for making informatics system. Classical models are compared with modern models. In the end of my work is in detail described problematic of informatics system of public service and necessary documents for make. KEYWORDS Informatics system, live cycle system, system development live cycle. 5

6 OBSAH 1 Úvod Životní cyklus informaního systému Nkolik fakt o IS Oblast technického zabezpeení IS Samotný životní cyklus IS Slovníek používaných pojm bhem sestavování životního cyklu IS 11 3 Ukázky model životního cyklu Vodopádový model Prototypování Model výzkumník Iterativní model Spirálový model Jednotlivé kroky v životním cyklu IS Zahájení Vývoj Implementace Provoz a údržba Ukonení provozu Nejdležitjší etapy SDLC Etapy SDLC Identifikování problému a plánování Analýza poteb systému Návrh (Design) systému Vývoj softwaru Testování systému Implementace a údržba Závr SDLC Oblast omezení Progresivní vzestup

7 5.2.3 Peddefinování struktury Inkrementální plánování Trend pístupu k životnímu cyklu IS Vlastní analýza sestává ze 3 relativn samostatných model: Objektový model Dynamický model Funkní model Jaké diagramy metodika OMT mže obsahovat Use case Diagram datových tok Mapa událostí Metodika tvorby systému Návrh životního cyklu pro IS v oblasti veejné správy Co je ISVS Standardy ISVS pro náležitosti životního cyklu informaního systému Právní pedpisy eské Republiky se vztahem k ISVS Fáze životního cyklu ISVS Návrh životního cyklu ISVS Fáze pípravy IS Fáze vývoje, provozu a údržby IS Fáze ukonení innosti IS Grafické vyjádení životního cyklu ISVS Závr Seznam použité literatury Seznam obrázk Seznam tabulek Seznam píloh

8 1 ÚVOD Bhem mého hledání a pezkoumávání rzných podklad pro bakaláskou práci jsem zjistila, že teorie a praxe životního cyklu je velice odlišná. Životní cyklus informaního systému jako takový není z teoretického hlediska nároný. Byl pevzat z klasického životního cyklu produktu a proto urité fáze nám pipadají jednodušší a dobe aplikovatelné. Problém nastává v konkrétní situaci a konkrétním pípad. Pokaždé potebujeme vyvíjet informaní systém, který bude podle požadavk zákazníka. Tudíž neexistuje striktn dané pravidlo pro vývoj životního cyklu informaního systému. Našla jsem nekonen mnoho typ životního cyklu, ale každý byl ešen trošku jinak, existuje nkolik model, které se sousteují pokaždé na nco jiného. Životní cyklus informaního systému je dynamický, protože se neustále mní požadavky na nj a proto se jedná o jeho neustálou inovaci. Cílem mé práce bude shrnout a zhodnotit souasné pístupy k životnímu cyklu tvorby informaního systému. Popsat jednotlivé modely, které patí mezi klasické pístupy, ale i pístupy souasnosti, které jsou tzv. moderní. Snahou é práce bude tyto cykly podrobnji popsat, vysvtlit, znázornit a v neposlední ad zhodnotit, kdy a jak, který použít. V jedné z mých kapitol se podrobnji zamím na informaní systém veejné správy, kde bych ráda vyzdvihla dokumenty, kterými se ídí a samozejm vysvtlila tuto problematiku. 8

9 2 ŽIVOTNÍ CYKLUS INFORMANÍHO SYSTÉMU Životní cyklus zaíná již nejprvnjší myšlenkou o programu a koní v ten samý moment, kdy se program pestane používat. Každý IS by ml být integrovaný (= velké pokrytí ), pracovat v reálném ase, minimalizovat datové redundance, být zaveden co nejrychleji a stát co nejmén penz. Zde je známý trojúhelník penz, asu a kvality. PENÍZE AS KVALITA Obrázek 1: Trojúhelník penz, asu a kvality 2.1 Nkolik fakt o IS Mže, ale nemusí být podporován poítaem, piemž pi návrhu IS zkoumáme optimální kombinaci automatizovaných a neautomatizovaných inností. Musí disponovat prostedky sbru, kontroly a uchování dat. Jsou vyjasnné vztahy mezi informacemi a daty i v rámci jednoho zamení informaního systému. Informace jsou jen ta data, která dokážeme využít, piadit jim význam i smysl. Bhem návrhu IS je nutné, aby bylo umožnno získávání odlišných informací pro rzné zamstnance skladník, editel atd. 9

10 Informaní systém ovlivují pracovní procesy i organizaní struktura podnik. Proto jsou IS produkovány pímo tak íkajíc na míru daného podniku. Informaní systém je vždy spoleným dílem dodavatele a zákazníka, proto je velmi dležitá správná a úinná komunikace mezi tmito subjekty. Prudký rozvoj v informaních technologiích probíhá ve všech jejich komponentech, kterými je myšlen hardware a software. Výraznými rysy vývoje v jednotlivých oblastech jsou: oblast technologického zabezpeení IS a samotný životní cyklus IS. 2.2 Oblast technického zabezpeení IS. stálé snižování pomru cena/výkon (cca 20% ron), odklon od velkých sálových poíta smrem k poítaovým sítím se specializovanými servery a adou pipojených personálních poíta (pozoruhodný je zejména rst potu personálních poíta - odhaduje se, že v roce 1994 bylo na svt 208 mil. kus PC a tento poet neustále vzrstá), standardizace a z toho vyplývající možnost kombinování hardwarových produkt rzných výrobc (ovlivuje trh IT ve smyslu nezávislosti organizace na uritém dodavateli i výrobci IT), rozvoj v oblasti komunikací a Internet (nové typy stroj, multimedia, budování informaní superdálnice). [15], [10] 2.3 Samotný životní cyklus IS Životní cyklus je obdobím, které zaíná prvotní pedstavou o programu a koní okamžikem, kdy se program pestane používat. 10

11 2.3.1 Slovníek používaných pojm bhem sestavování životního cyklu IS Následující text vychází ze studia celé ady odborných publikací a text, pedevším pak. [3], [5], [6], [15], [16] [21] Trend: základní smr vývoje uritého jevu, jedná se o dlouhodobou tendenci i sklon, který je ovšem uritý. Též mžeme trend definovat jako po delší dobu se projevující proces, který se jako prmr prosazuje mezi individuálními odchylkami od tohoto prmru. Vývoj: je oznaení pro soustavný proces, bhem kterého dochází ke zmn aktuálního stavu do stavu nového. Cílem vývoje je na základ zkušenosti, plánu, i náhodné chyby vyvíjet stále lepší verze. Vývoj mže být pirozený nebo umlý. Mezi umlé zmny patí takové, které jsou pímo ovlivovány bytostí za úelem zlepšení stávající vci zájmu. Mezi umlé vývoje se mže zaadit napíklad vývoj softwaru, kdy na základ objevovaných chyb a nových nápad dochází k opravám a zlepšováním starší verze. Informaní systém IS: funkní propojení lidí, dat, procesu rozhodování, sítí a technologií, které spolupracují, aby podporovali a zlepšovali každodenní operace ( data processing ) v organizaci a zárove, aby podporovali ešení problém a proces rozhodování v rámci managementu ( information services ). Každý informaní systém má sloužit vlastníkovi nebo uživateli (ne naopak, jak tomu asto bývá). Informace: Skupina nebo množina informaních jednotek i signál, která je píjemcem interpretovatelná jako smysluplná. Míníme sdlení, které odstrauje nejistotu nebo nevdomost. Data: zobrazují stavy objekt i probíhající procesy v realit kolem nás (to, s ím pichází píjemce do styku). V závislosti na zpsobu a okolnostech prezentace dat bu pedstavují tato data pro píjemce informaci nebo nikoli. 11

12 Znalosti: pedstavují zobecnné poznání urité ásti reality. Znalosti souvisejí s vymezováním pojm, s kategorizací, s definováním, s odvozováním závr z dostupných fakt na základ abstraktních schémat (hypotéz) a s vymezováním mechanism (postup), odvozováním závr. Implementace: znamená uskutenní, naplnní a doplnní. Odtud sloveso implementovat - uskutenit i naplnit. Databázové schéma: pedstavuje seznam implementovaných tabulek a pohled = definice rozvržení systému. Vzniká z myšlenkového modelu a to pevedením do fyzické reprezentace, kterou je již možné implementovat ve zvoleném systému pro správu databází. Databázové schéma je databázový model vyjádený v pojmech, pomocí kterých jej popisujeme databázovými stroji. Zde se nezabýváme fyzickou implementací. Databázový model: mžeme rozumt myšlenkový (konceptuální) popis prostoru problému. Nemá však žádnou souvislost s fyzickým rozložením výsledného systému. 12

13 3 UKÁZKY MODEL ŽIVOTNÍHO CYKLU Životní cyklus IS se ídí nkolika základními modely, samozejm tyto modely jsou všelijak obmovány a doplovány o další kroky. Ukázky model slouží jako úinný návod životního cyklu IS, protože modely doplujeme o jednotlivé kroky dle poteby, situace a požadavk na systém. [15], [17] vodopádový model prototypování model výzkumník iterativní model spirálový model 3.1 Vodopádový model Tento model je jedním z nejstarších model, zaíná se datovat od roku Existuje v nkolika rzných verzích, my se zamíme na jednu z nich. Celý proces zaíná definicí požadavk, v rámci kterého je nutné se zamit na to, co zákaznická organizace a její uživatelé od systému požadují. Po dokonení analýzy se vytvoí podrobný návrh celého systému. Následuje fáze zavádní a testování jednotlivých jednotek systému, po jejich odladní testováním systému jako celku. Poslední fází projektu je samotný provoz a údržba systému. Vodopádový model je složen z posloupnosti jednoznan vymezených etap, které na sebe navazují a vzájemn se prolínají. Naprosto naivní pedstava pak dokonce poítá s jednoznaným dokonením každé ásti ped spuštním následující. Pokud by tomu tak bylo, tak by model provádl rozumnou kontrolu nad rozpotem, nasazením pracovník a asem. 13

14 Pi použití tohoto modelu, je kladen velký draz na zadavatele, musí být jasn a pesn definované požadavky, nebo vrátit se zpt nebo peskakovat z jedné etapy do druhé, není možné (z toho paralela s tekoucí vodou, tekoucí z vodopádu). V prbhu realizace nelze mnit požadavky a technologické postupy, proto je v praxi tento model použitelný jen výjimen. Pozitiva: Model je nedokonalý, ale je lepší než náhodný, nelogický neízený pístup k ešení projektu. Velký teoretický význam- definuje jednotlivé etapy podle logického sledu. Obrázek 2: Vodopádový model [15], Negativa: Reálné projekty zídkakdy sledují jednotlivé etapy modelu v pedepsaném poadí. Uživatel asto nedokáže pedem stanovit své požadavky zeteln a jednoznan. 14

15 Provozuschopnost verze vidí zákazník až v závrených fázích ešení, pípadn jsou závažné nedostatky odhaleny velmi pozd. Proto mže mít nepíznivý vliv na finanní stránku projektu a jeho celkový neúspch. 3.2 Prototypování Prototyp je ásten zavedeným produktem, mže být v logické nebo fyzické podob a má všechna vnjší rozhraní. Negativa: Nároný na vedení v okamžiku, kdy existuje teba i nkolik nezávislých vývojových skupin. Poet pracovník a zpsob vývoje se pak samozejm nepízniv projeví i na nákladech projektu. Pozitiva: Budoucí uživatelé testují a ovují prototyp a je upesována specifikace požadavk. Zákazníci spolu s ešitelským týmem si prbžn sdlují a vyjasují požadavky i jejich interpretaci. Nkteré prototypy jsou tvoeny s vdomím, že budou "vyhozeny", jiné budou použity a dále rozšíeny. 3.3 Model výzkumník Bhem vývoje systému se ešitelé pí získávání poznatk asto vracejí k pedchozím etapám. Tento model s tím pímo poítá jako se základní charakteristikou vývoje. Ale zpsob vývoje s sebou nese pedevším problémy asové a finanní. Využívá se v pípad, kdy je nutné se vrátit k pedešlým etapám projektu, z dvodu chyby. 15

16 Obrázek 3: Model výzkumník [15] Negativa: Manažersky velmi nároné etapy lze stží plánovat asov, finann i personáln. Odklon od pvodního zámru, z dvodu neustálých úprav (astý výskyt spor s realizaním týmem a zadavatelem) Dokumentace pokud nevzniká prbžn, je odrazem hotového díla. Pi údržb není jasné, které požadavky byly stanoveny pi zadání, a které jsou nyní nové. Pozitiva: Systém je velice dobe pizpsobitelný i dodateným požadavkm zákazníka. Není nutné v pípad pipomínek vracet se k analýze 3.4 Iterativní model Tento model je vhodný pro ešitele, protože zde hraje velkou roli zadavatel a je spoluodpovdným za další vývoj projektu. Pilíem modelu je zpracování úvodní studie, kde jsou zjištny pvodní požadavky a poteby zadavatele. Následuje analýza, návrh a implementace. Pokud se zjistí nové požadavky i provádí zmna, vracíme se zpt do fáze analýzy. Proces je ukonen v moment splnní všech požadavk a neexistují li další pipomínky. 16

17 Použití modelu je v pípad upesování požadavk bhem vývoje nebo pokud bhem testování uvedu nové požadavky. Pozitiva Zadavatel vidí postup v realizaci jednotlivých ástí návrhu. Negativa asová a finanní náronost Vracení se stále na poátení fáze v pípad pipomínek Analýza Návrh Implementace Testování Zavádní Obrázek 4: Iterativní model [17] 3.5 Spirálový model Model je založen na kombinaci prototypování a analýzy rizik. Jednotlivé kroky pi vývoji systému se ve spirále opakují, ale pokud možno na vyšším stupni zvládnuté problematiky. 17

18 Negativa: Výhodné jen pro zkušené ešitelské týmy, zvlášt pi velkých projektech. Pokud se budete také pesn ídit schématem tohoto modelu, tak celkový zámr projektu mžete vzít do úvahy až velmi pozd a pedchozí výsledky mohou být ztraceny. Pozitiva: Již v asných fázích modelu je pozornost zamena na použití SW. Chyby a nevyhovující alternativy jsou vyloueny co nejdíve (díky "vyhazování" nkterých prototyp a analyzování rizik). Obrázek 5: Spirálový model [15] Pro životaschopný IS, je poteba vnovat pípravnému procesu nejmén stejné úsilí jako samotnému fyzickému vývoji. Shrme tedy alespo základní kroky, které by mly vést po správné cest. 18

19 Pi tvorb nového projektu, je teba shromáždit velké množství pípravných údaj a zapsat je ve form, která bude srozumitelná, pokud možno všem zúastnným. Mnohé údaje, které zdají v poátcích zbytené, jsou po ase "objeveny" jako zásadní, mnohé údaje opravdu zbytenými mohou být. 19

20 4 JEDNOTLIVÉ KROKY V ŽIVOTNÍM CYKLU IS Zahájení Vývoj Implementace Provoz, podpora, údržba, rozvoj (ukonení provozu) 4.1 Zahájení Na tvorbu nového i dalšího vývoje stávajícího IS zadá podnt zákazník, když má dost síly na prosazení myšlenky a dostatek zdroj na financování návrhu, vývoje a provozu IS. Prvotním krokem je definování požadavk, které obsahuje: co je požadavkem, co je poteba ešit ( v em problém spoívá, a do které oblasti spadá), kdo jsou úastníci procesu, pro je poteba problém ešit (jaké jsou cíle úastník), kdy je teba problém vyešit (asový horizont a limity), jak pomže software problém vyešit. [10], [7] Požadavky se musí specifikovat, nap. všechny funkce a výkonnost systému. Toto rozdlit mezi hardware a software, požadavky na bezpenost a stanovit uživatelské rozhraní. Požadavky by mly být stanoveny: Správn Jednoznan Úpln Konzistentn bez rozpor Oviteln Ohodnocen dle dležitosti Modifikovateln ( strukturovan) Vysledovateln Pro získání informací existuje nkolik zpsob a zdroj. Záleží jen na vyhodnocení toho nejefektivnjšího. Informace mžeme získat nap. vzorkováním existující dokumentace, 20

21 formulá a databází, przkumem na míst, osobní návštvou, pozorováním pracovního prostedí, rznými dotazníky a rozhovory, brainstormingem, 4.2 Vývoj V této druhé fázi je pozornost zamena na získání nebo vytváení všech potebných prostedk (HW, SW, ), testování, dokumentace, jak by ml IS a produkní systém pracovat. Mlo by být oveno, zda systém práce a IS opravdu eší problémy i obtíže uživatele, které jsou známé z první fáze. Výsledkem této fáze je fungující informaní technologie. V tomto okamžiku velice asto dochází k selhání a z pohledu zpoždní nebo pekroení daného rozpotu. 4.3 Implementace Tetí fáze systému zahrnuje uvedení nového systému do provozu. Naplánování pechodu ze starého IS na nový. To obsahuje školení uživatel a ovit zda systém je efektivní. Mže nastat zmatek, ale i selhání (není ovšem tak asté jako v pedešlé fázi). 4.4 Provoz a údržba V pedposlední fázi je nutné neustálé sledování a kontrolování funknosti systému, provádní údržby. asto zde dochází k omylu, že tato fáze je nejjednodušší, tudíž se jí nemusí vnovat pozornost. Opak je pravdou. Tato fáze má dležitý vliv na využívání systému uživateli. Je vhodné drobné zmny provést co nejdíve, protože po delším ase je obtížnjší provádt údržbu a zmny. 4.5 Ukonení provozu Poslední fází IS je ukonení provozu. IS je zastaralý a nestaí uspokojit požadavky uživatele (nároností, rychlostí, ). 21

22 5 NEJDLEŽITJŠÍ ETAPY SDLC Systems Development Life Cycle (SDLC = systémový vývoj životního cyklu) je stanovený u United States Department of Justice jako vývoj softwarového procesu, akoliv je zejmé, že se jedná o proces nezávislý na softwaru nebo na jiné informaní technologii. [21] Je používán u systémových analýz vývoje informaního systému, zahrnující požadavky, validaci (ovení), proškolení a používání vlastnických práv pes przkum, analýzu, design (návrh), implementaci a údržbu. SDLC je také znám jako vývojový, informaní a systémový vývoj nebo jako vývoj na požádání. SDLC mže být výsledkem vysoké kvality, který se setkává nebo pekonává zákazníkovo oekávání v ase, nákladech, pracovní efektivity a je levný na údržbu. SDLC je systematický pístup k problému ešení a je sestaven z nkolika fází. Piemž každá fáze obsahuje nkolik krok. 5.1 Etapy SDLC Prvotní je vždy definování problému a odpov na otázku, co chci, aby systém uml. Systém analýzy a návrhu je systematickým pístupem identifikováním problém, píležitostí a objektivní analýza informaního toku v organizaci a navrhování IS, který bude ešit problémy. Konstrukce pro systematický pístup je nazýván system development live cycle (SDLC). Cyklus mže být rozdlen do 3 až 20 ástí. Ing. Pavel Jirava, PhD. Rozdlil SDLC do 6 sekvenních ástí, viz obrázek. 22

23 Identifikování problému a plánování Analýza poteb systému Návrh (design) systému Vývoj SW Integrace a testování systému Implementace a údržba Obrázek 6: Etapy SDLC Identifikování problému a plánování (Prvotní studie - Feasibility Study) Jedná se o definování a pojmenování problému a plánování. Fáze první je velice dležitou pro budoucí vývoj systému ŽC. Zda dojde v této fázi projektu k jakékoli chyb, ale i v pozdjších fázích se vyskytují problémy, které musí být napravené. Proto je tato fáze asto oznaována za kritickou z pohledu projektu. Tato studie by mla odpovdt na otázky managementu ohledn IS. Jedná se o otázky typu: Co oekáváme od systému. Jaký je cíl systému. Stanovení podmínek financováni. 23

24 Stanovení podmínek z hlediska asu. Stanovení podmínek z hlediska koneného výsledku. Jaká bude originalita systému a jeho rozdílnost. Jak asto mže být existující systém obnovován (update) a inovován. Na všechny tyto otázky by mla odpovdt prvotní studie. Specialisté zde identifikují požadavky na nový nebo rozšiující systém. Tyto požadavky jsou uvedeny do projektu. Velmi asto poteby IS vyplývají z požadavk. Tato fáze obsahuje plán rozvrhu vývoje nového systému. V menších organizacích je ureno, který systém se bude vyvíjet. Zahrnuje základní strukturu modelu životního cyklu, cíle, jaké jsou píležitosti a riziky spojené s projektem a pípadn popisuje management a technické pístupy. Výstupem této fáze je uspoádaný plán ízení, Cíle Identifikování problému a plánování Model životního cyklu SW a plán ízení Kvalita SW a pojistný plán Plán projektu a seznam Obrázek 7: Plánovací fáze SDLC [18] 24

25 5.1.2 Analýza poteb systému Pi analýze systému jsou použité znalosti z pedcházející fáze jako je informace o prostedí, ve kterém se bude nacházet nový nebo rozšíený IS, dále informace o struktue systému a jeho elementárních ástech. Dochází k systematizaci požadavk získaných z identifikace problému. Je vytvoen seznam vstup (= funkních požadavk), dále seznam událostí a rzné varianty reakcí na n a samozejm seznam výstup. Na základ tchto seznam se analyzují náklady na systém, to, zda se projekt vyplatí i vrátí. RTM (requirements treasibility matrix)je tzv. matice požadavk, tyto požadavky jsou podrobn rozebrány a roztídni. Každý cíl je uveden zvláš a vnuje se mu zvláštní pozornost. Jeden z nástroj pro získání znalostí budoucího použití systému slouží tzv. datových tok (DFD data flow diagram viz. píloha ). Diagram Vysoká úrove požadavk Analýza poteby systému Požadavky na dokumentaci Aktualizování plánu projektu a seznamu RTM Obrázek 8: Analýza poteby systému [18] 25

26 5.1.3 Návrh (Design) systému Zatímco se analýza pedevším zabývá tím, co je teba udlat, design se snaží na základ analýzy urit nejvhodnjší zpsob, jak to udlat. Nkteré zdroje dlí design systému na dv základní ásti, a to systémový a objektový návrh. Hlavním cílem systémového designu je rozdlit systém na subsystémy, alokovat (rozmístit) subsystémy na HW a SW prvky a vytvoit koncepci detailního návrhu. [7] V systémovém designu se uvažují mimo model systému také možná výpoetní prostedí a možná vývojová prostedí. V tomto návrhu jsou ureny typy architekt, kterými je objektov ízený systém, systém v reálném ase atd. Systém se lení na podsystémy (vrstvy subsystému), definují se paralelní prvky a innosti. V systému je nutné definovat chování pi mezních stavech. Mezní stav mže nastat pi uvedení systému do provozu, pádu systému a ukonení bhu systému. Bhem tetí fáze SDLC je také vyvíjena efektivní dokumentace softwaru, která musí zahrnovat procesní manuál, on-line pomoc, asto kladené otázky, ti mj soubor. Dokumentace íká uživatelm, jak používat systém a pípadn, co dlat, když se vyskytnou njaké komplikace Požadavky na dokumentaci Fáze návrhu (design) Návrh dokumentu Aktualizování plánu projektu a seznamu aktualizace RTM Obrázek 9: Fáze návrhu [18] 26

27 Vstupem fáze jsou definované požadavky v dokumentaci. Pro každý požadavek je navrženo jeden nebo více element, z kterých se vybere výsledný, pomocí interview, workshopy,. Návrh element obvykle zahrnuje SW vzhled (detailn), diagramy, tabulky obchodních pravidel, procesní diagram, pseudokód, celkové vztahy diagram s ucelenými daty. Když návrh dokumentu je ukonen a akceptován provede se aktualizace RTM a každý návrh prvku je porovnán s požadavky. Výstupem návrhu SW je navržená dokumentace, aktualizovaný plán projektu a RTM Vývoj softwaru V této fázi SDLC je analyzována práce s programátory vývoje softwaru. Software by ml být originální a splovat poteby. Velmi dležitou úlohu mají programátoi, oni navrhují, kódují a odstraují syntaktické chyby z poítaového programu. Návrh dokumentace Fáze vývoje Software On-line pomoc Aktualizování plánu projektu a seznamu Implementace map Plán testování aktualizace RTM 27

28 Obrázek 10: Fáze vývoje SDLC [18] Primárním vstupem fáze vývoje je návrh dokumentace, která je schválená. Výstupem je plný funkní set softwaru, který spluje požadavky a shoduje se s návrhem, možná on-line pomoc (popsání jednotlivých operací softwaru), implementaní mapy (identifikace primárního kódu pro vstup k funknímu systému), plán testování, kde jsou popsány jednotlivé testovací pípady, update RTM a plánu projektu Testování systému Po sestavení systému je nutné zjištní, zda opravdu funguje a spluje dané požadavky. Tuto fázi nazýváme Testovací. Testování se provádí ped implementací z mnoha dvod nap. rychlejší reakce na chybu a tím i na její nápravu. Pokud je odhalena chyba, program se vrátí zpt do rukou programátor. Ovení kompletnosti a korektnosti systému. Software On-line pomoc Implementace map Plán testování Testování a integrace Integrovaný software Implementace map On-line pomoc Uskutenní plánu Pijetí plánu Aktualizování plánu projektu a seznamu Obrázek 11: Testování a integrace SDLC [18] 28

29 Vstupem je software, on-line pomoc, implementace map a plán testování.. Výstupem pedposlední fáze SDLC je integrovaný set SW, on-line pomoc, plány uskutenní a aktualizace plánu projektu Implementace a údržba Implementace a údržba je poslední fází systému vývoje. Pedešlé analýzy pomáhají uvádt do chodu IS. Implementaní fáze zahrnuje školení pímých uživatel. Nkterá školení jsou provádna u prodávajících, ale veškerá odpovdnost školení spadá pod fázi analýzy systému. Tato fáze udává, jak pevést starý systém na nový co nejefektivnji a pi co nejmenší možné ztrát asu. Existuje nkolik zpsob implementace, nap. pímé pepnutí na nový systém (spolenost chce rychle vymnit starý systém za nový, velmi asto se implementace provede bhem víkendu, kdy zamstnanci jsou mimo kancelá. Tento pístup ale mže být velmi riskantní. Po všech testech nemusí být systém funkní, jak pedpokládáme), paralelní konverzace (soubžná, spolenost instaluje nový systém souasn, když starý systém stále funguje. Organizace postupn pesouvá své zamstnance na nový systém. Možné riziko ze strany zamstnanc, neochota pejít na systém nový starý systém znají.), pilotní testování (bhem poáteního testování spolenost instaluje nový systém jen na uritou ást organizace nebo na jedno oddlení, pokud se systém osvdí je instalován všude). Po implementaci je nutná údržba. 80% celkových náklad IS jde na údržbu. Údržba zahrnuje opravy chyb, zálohování dat, pomoc uživatelm. Nkteré z chyb nelze detekovat v testovací fázi, nap. když zamstnanci zaínají používat nový systém, tak picházejí chyby. Oprava tchto chyb je jednou z nejdležitjších ástí údržby. [11], [12] 29

30 Uskutenní Pijetí plánu Integrovaný On-line pomoc plánu software Implementace map Implementace a údržba Výroba softwaru Kompletní akceptovatelný test Záznam akceptovatelný pro zákazníka Archivace SW artefakt Archivace plánu projektu a seznamu Obrázek 12: Implementace a údržba [18] 5.2 Závr SDLC Pedepsaná struktura u SDLC, je specifikovaná návrhem maximální pravdpodobnosti úspchu vyvíjeného SW. Pro dosažení úspchu a vložení co nejvtšího úsilí do SDLC existují tyi základní koncepty. Oblast omezení (Scope restrict) Progresivní vzestup (Progresive enhancement) Ped- definovatelná struktura (pre-defined structure) Inkrementální (pírstkové) plánování (Incremental Planning) 30

31 Tyto tyi koncepty pomáhají k pedcházení rizik bhem vývoje softwaru Oblast omezení Projektová oblast je založena na základ požadavk zákazníka, na známosti cíl a jejich zalenní do projektového plánu. Cíle jsou postupn vytíbeny do požadavk, dále do návrhu element a nakonec do artefakt softwaru. Tato hierarchie cíl. Požadavk, element a artefakt jsou zdokumentovány v RTM, který slouží jako kontrola element, které omezují projekt pvodní definované oblasti. Úastníci projektu jsou omezeni adresností tchto požadavk, element a artefakt, které jsou pímo patrné z cíl produktu. Tato prevence znan sníží poruchovost projektu Progresivní vzestup Každá fáze SDLC bere výstup vezme výstupy z pedešlé fáze a ty jsou vstupy pro další fáze. Dodatkové informace jsou tímto seskupeny, využití specifických metod v každé fázi. Pak výsledkem jsou výstupy z pedešlých fází, u kterých progresivn stoupají dodatené informace. Tato fáze nám podrobn rozebere každý element. Zakládá se na vzrstající práci a dodatené informace mžeme použít i v pozdjších fázích. Nové požadavky jsou formáln mimo vývojový tým pro pozdjší srovnání. Výsledkem této fáze je zamení úastník projektu na udržení a pesného dodržení pvodních cíl projektu. Tím se minimalizuje výskyt chyby Peddefinování struktury Každá fáze má peddefinovanou sadu standardních proces jako je iteraní, informální a jiné modely. Úastníci projektu rychle ustálí proces do jednotlivých fází pedem ureného modelu,model se vybere podle vývoje, požadavk nebo kultury projektu. Peddefinovaná struktura se utváí podle znalostí z minulosti, souasnosti a z toho, co oekáváme od blízké budoucnosti. Toto umožuje vyšší úrove komfortu a zpsobí lepší spolupráci mezi úastníky. Úastníci poskytují potebné informace nebo zptnou vazbu opakovan. Tím nechybí komunikace mezi jednotlivými lánky. Toto Vynaložené úsilí se navrátí v píštích fázích. 31

32 5.2.4 Inkrementální plánování V pírstkovém plánování je minimalizované pekvapení Zvyšuje pesnost, poskytuje informace, Poskytuje informace o odchylkách od plánu tak brzy, jak je v SDLC možné. V SDLC se navrhuje každá fáze detailn a omezuje pozdní plánování fází. \Pedem zná výstup fází, což zvýší celkovou úrove. Návrh plánu je kompletn aktualizován v každé fázi, prbžn se aktualizují i náklady a dležitá data v kombinaci s odhady dalších aktivit v píštích fázích. Otázky a aktivity dalších fází jsou definovány pouze po skonení probíhající fáze. Výstup každé fáze musí být mitelný. Toto dovoluje plánování výroby s vysokou pesností v každé fázi. Pímé zkušenosti ukazují, že se jedná o velmi složitý vývoj, více než ukazují odhady pedvídatelných struktur a úrovn úsilí pro výstup fází. Odhady pro výstup z fází zahrnují závrené odhady náklad a seznam dat. Výsledkem tohoto konceptu je celkový návrh odhadu, který je naprosto pesný. Toto dá zákazníkovi píležitost k porovnání shody projektu a požadavk popípad opravy. Zákazník se aktivn úastní projektu. 32

33 6 TREND PÍSTUPU K ŽIVOTNÍMU CYKLU IS Objektov orientované metodiky a technologie jsou dle mého názoru trendem pístupu k životnímu cyklu. Dá se íci, že OMT (model orientovaný na pedmt) je jednou z nejoblíbenjších metodik analýzy a návrhu. Proto Metodiku OMT pokládám za trendovou, dkazem toho jsou nové metodiky, které vznikly na základ OMT. OMT zahrnuje notaci (jednotlivé použitelné diagramy) i popis objektov orientovaného vývoje IS. 6.1 Vlastní analýza sestává ze 3 relativn samostatných model: Každý model popisuje pouze nkteré aspekty systému. Obsahuje však odkazy a vztahy s ostatními modely. Vztahy model jsou velice dležité, protože díky tomu mže být metodika zcela kompaktní. [2], [13] objektový model (OM - Object Model), dynamický model (DM - Dynamic Model), funkní model (FM - Functional Model) Objektový model Objektový model znázoruje objektovou strukturu, na které jsou provádny operace znázornné v dynamickém a funkním modelu. Model obsahuje definice tíd a jejich vztah spolen s atributy a metodami. Zachycuje statickou strukturu systému Dynamický model Dynamický model ukazuje akce, které závisí na hodnotách objekt (lépe eeno jejich atributech). Ty pak zpsobují zmny hodnot objekt a vyvolávají funkce. Druhý model zachycuje dynamiku objekt a zmny jejich stav. Zabývá se chováním objekt v ase a 33

34 tokem zpráv a kontroly mezi objekty. Dynamický model zahrnuje stavové diagramy (STD - State Transition Diagram) pro každou tídu nebo pro dležité ásti návrhu. Dále pak diagramy interakcí. Souástí DM je také celková mapa událostí (Event Trace Diagram) a diagram událostí (model událostí, v anglitin se nazyvá Event Schema nebo i Event-flow Diagram) Funkní model Funkní model popisuje funkce vyvolané operacemi (metodami) v objektovém modelu a akcemi v dynamickém modelu. Funkce zpracovávají hodnoty dat definovaných v objektovém modelu. Poslední ze tí model popisuje funkní závislosti systému, je podobný diagramu datových tok. Popisuje, co systém dlá (ale nezabývá se tím, jak to dlá). 6.2 Jaké diagramy metodika OMT mže obsahovat Dalšími diagramy metodiky OMT jsou nap use CASE tzv. model jednání a slovní scénáe, Diagram datových tok tzv. Data Flow Diagram nebo nap. mapa událostí Use case Model jednání je využíván pi definování požadavk, specifikace chování a urení hranic systému. Use case se skládá i ze slovního popisu, který se sestavuje následujícím zpsobem. Na poátku sepíšeme seznam událostí probíhajících v dané funkci/use case, které se íslují. Následn je seadíme dle poadí, ve kterém nastávají. Paralelní události a podudálosti se íslují víceúrovov. Mohou se sepsat do tabulky, kde se lépe piadí jednotlivým událostem i podudálostem vstupy a výstupy. Dále je celý proces popsán slovy, na závr napsán dsledek plus možná rizika, která mohou nastat Diagram datových tok Diagram datových tok (Data Flow Diagram) se skládá z proces, datových tok, aktér a data stores. Proces transformuje vstupní data na výstupní. Proces se znázoruje elipsou. Datový tok zachycuje tok dat mezi procesy. Znázoruje se šipkou. Pro prvky okolí se pvodn v diagramech datových tok používalo pojmenování terminátor, v objektové 34

35 terminologii OMT jsou aktéi. Znázoruje se obdélníkem. Data stores pak slouží pro doasné uložení dat. Znázoruje se pomocí dvou rovnobžných ar, mezi kterými je napsán název skladu. Aktoi jsou objekty, data stores mohou být také objekty. (Aktor - oznaení uživatele v diagramech use case. Mže to být osoba, jiný systém, hardware, plynutí asu.) [8] Diagram datových tok je modelem hierarchickým. Nejvyšší diagram se nazývá kontextový. V nm jsou uvedeni pouze aktéi, systém jako celek jakožto jediný proces a datové toky mezi aktéry a systémem. Pod kontextovým diagramem se nachází diagram nulté úrovn. Vzniká rozpadem funkce systému jako celku na nkolik základních proces (jejich poet se odvíjí od nároku na pehlednost diagramu). Každý proces v nulté úrovni nese ped svým jménem íslo. Každý z tchto proces se pak rozpadá do nkolika podproces v diagramech první úrovn. Podprocesy pak nesou íslo svého nadprocesu a za teku pidávají své vlastní íslo v rámci své úrovn (nap. proces ve druhé úrovni hierarchie) Mapa událostí Dalším modelem je mapa událostí. Jejím cílem je zobrazit všechny události, které tídy zpracovávají nebo vysílají. Mapa událostí se podobá objektovému modelu, jsou v ní však pouze tídy, které se vyskytují v diagramech interakcí. Tídy se znázorují klasicky obdélníky, události šipkami (udávají smr události). Diagram událostí popisuje všechny innosti systému jako reakce na njaké vstupy. Cílem je identifikovat všechny aktivity. Jedná se o sí událostí a aktivit. Aktivity jakožto uzly diagramu se znázorují obdélníky se zaoblenými rohy, události se znázorují jako šipky. Celý diagram má jeden vstup a jeden výstup. Mezi základní vlastnosti modelu patí fakt, že popisuje systém bez ohledu na jeho objektovou strukturu. Dále nerespektuje hranice systému (popisuje aktivity systému i okolí, nap. uživatele). Události se v diagramu mohou vtvit. Vtvení událostí se oznauje písmenem S v kroužku (z anglického split ), slévání událostí se oznauje M v kroužku (z anglického merge ). Vtvení a slévání událostí je projevem njaké innosti, která se ale v diagramech uvádt nemusí, protože má výhradn technický charakter. Vtvením pak vznikají paralelní události (vtve), nebo mají události ve vtvích k sob vztah exclusive or (tj. dojde pouze k jedné z nich). Závrem k 35

36 diagramu událostí je nutné zmínit, že je možné je vytváet a uspoádávat hierarchicky (obdobn jako DFD). Toho lze využít u složitých aktivit Metodika tvorby systému Tvorba informaního systému s použitím objektového pístupu (ale i bez nj) stojí pedevším na vytváení nejrznjších model. Modelujeme tak napíklad interakci systému s okolím, komunikaci objekt jako nosný prostedek realizace dynamiky aplikace a jako podrobný model mžeme chápat i zdrojový kód. Samotné modely mžeme ze zejmých dvod prezentovat a vytváet ve form grafických diagram, jejichž sémantika (význam) a syntaxe (zápis) je zpravidla jasn vymezena. Souhrnn mluvíme o tzv. notaci. V pípad použití objektového pístupu nemusí být, vhledem k povaze používaných nástroj, jasná hranice mezi jednotlivými etapami. Obecné schéma posloupnosti analýza/design/implementace/validace však zstává zachováno. Práv v souvislosti s používáním objektových technologií se nejvíce osvdil iterativní pírstkový životní cyklus, jehož filosofie staví na práci s relativn malými ástmi systému, které jsou vždy ešeny a zpracovávány pes všechny etapy zkráceného životního cyklu. Celý vývoj IS je tak vlastn neustálým kolobhem klíových etap pi uvažování stále vtšího množství dílích celk. Samozejm tento model iterativního životního cyklu vícemén padá v pípad, kdy není uvažována tvorba kompletního IS, tj. napíklad v již diskutovaném pípad analýzy provádné samostatn. Zatímco pi klasickém tzv. vodopádovém modelu byla snaha uzavírat definitivn jednotlivé etapy, pi iterativní metod jsou jednotlivé etapy prchodné obma smry. [13], [4] 36

37 Obrázek 13- Vybrané pedmty zájmu metodik pro tvorbu IS [14] OMT také popisuje fáze objektov orientovaného vývoje informaního systému. Mezi n patí: Analýza Zde je nutné porozumt a namodelovat ást reality, kterou bude systém obsahovat. 37

38 Systémový design uruje celkovou architekturu systému (plus podsystémy, paralelní tásky, uložení dat, ). Objektový design optimalizuje modely analýzy z hlediska konceptu implementace. Implementace obsahuje programování vlastního poítaového systému. Testování probíhá prbžn ve fázích inkrementálního vývoje OMT dále detailnji popisuje kroky, které by mly být provedeny v jednotlivých fázích objektov orientovaného vývoje IS. Ve fázi analýzy je teba vytvoit objektový, dynamický a funkní model. Tvorba objektového modelu by mla obsahovat následující kroky: Vytvoit slovní popisy modelovaného problému. Urit tídy objekt. Zrušit nepotebné a chybné tídy. Pipravit knihovnu znalostí (data dictionary) Urit asociace mezi tídami. Zrušit nepotebné a chybné asociace. Urit atributy tíd. Zrušit nepotebné a chybné atributy. Urit vazby ddinosti. Projít vše znova a urit nedostatky. 38

39 Tvorba dynamického modelu by mla obsahovat tyto kroky: Urit use cases a pipravit scénáe typických interakních sekvencí. Urit události mezi objekty a pipravit mapu událostí pro každý scéná. Vytvoit diagram událostí systému. Vytvoit stavové diagramy pro tídy s významným dynamickým chováním. Zkontrolovat konzistenci a úplnost událostí sdílených mezi stavovými diagramy. Tvorba funkního modelu zahrnuje následující kroky: Urit vstupní a výstupní hodnoty. Vytvoit diagramy datových tok pro vyjádení funkních závislostí. Popsat každou funkci, co dlá. Urit omezení. Specifikovat optimalizaní kriteria. 39

40 7 NÁVRH ŽIVOTNÍHO CYKLU PRO IS V OBLASTI VEEJNÉ SPRÁVY 7.1 Co je ISVS Informaní systémy veejné správy (dále jen ISVS ) pedstavují významný nástroj výkonu veejné správy na všech úrovních. S ohledem na potebu zajistit transparentnost, vzájemnou kompatibilitu, komunikaci a uritý stupe jednotnosti všech ISVS, je kladen velký draz na ízení této oblasti. Informaní systém veejné správy (dále jen ISVS ) má životní cyklus podobný jako klasický IS nap. pro podnik. Pesto se, ale liší v jednotlivých fázích a zpracováním, je zde kladen vtší draz na dokumentaci a vše, co s ní souvisí nap. aktualizace. 7.2 Standardy ISVS pro náležitosti životního cyklu informaního systému Pi vývoji životního cyklu se používají standardy a metodiky ISVS. Jedná se o soubory pravidel pro výkon odborných inností spojených s vytváením, rozvojem a využíváním informaních systém veejné správy. Jedním z nejvýznamnjších je "Standard ISVS pro náležitosti životního cyklu informaního systému". Jeho cílem je: Zajistit ízení a zejména kvalitní organizaci a kontrolu projekt rozvoje IS v rámci organizace správce ISVS. Zajistit kvalitní ízení vývoje, provozu a údržby IS jako celku. Pipravit vcný podklad pro atestace IS nebo projekt jejich rozvoje. Poskytnout správcm IS veejné správy možnost efektivnji kontrolovat dodavatele komplexních ešení (zejména externí subjekty) rozšíením potu a pesnou definicí kontrolních bod, ve kterých lze zpracovávaný projekt ovlivnit nebo v krajním pípad zastavit tak, aby nedocházelo k dalším zbyteným finanním a asovým ztrátám. 40

41 Standard pedepisuje základní kroky, které musí být provedeny v prbhu životního cyklu informaního systému a zejména základní strukturu dokument, které musí být v prbhu životního cyklu informaního systému vypracovány a pravideln aktualizovány Právní pedpisy eské Republiky se vztahem k ISVS Právní pedpisy platné pro oblast ízení ISVS jsou uvedeny v tabulce. 1. Základním právním pedpisem je zák.. 365/2000 Sb., o informaních systémech veejné správy, ve znní pozdjších pedpis (dále též jen "zákon"), od nhož se odvíjejí všechny právní pedpisy nižší právní síly a další nástroje používané Ministerstvem vnitra. [19] Pedpis (poslední novela) Zkrácený název zák.. 365/2000 Sb. (81/2006) 1 o informaních systémech veejné správy Název O informaních systémech veejné správy a o zmn nkterých dalších zákon vyhl.. 529/2006 Sb. (529/2006) O dlouhodobém ízení ISVS o požadavcích na strukturu a obsah informaní koncepce a provozní dokumentace a o požadavcích na ízení bezpenosti a kvality informaních systém veejné správy (vyhláška o dlouhodobém ízení informaních systém veejné správy) 41

42 Pedpis (poslední novela) vyhl.. 530/2006 Sb. (530/2006) vyhl.. 528/2006 Sb. (528/200 6) vyhl.. 528/2006 Sb. (528/2006) vyhl.. 469/2006 Sb. (469/2006) Zkrácený název o dlouhodobém ízení ISVS o postupech atestaních stedisek pi posuzování dlouhodobého ízení ISVS o informaním systému o informaních systémech veejné správy o informaním systému o datových prvcích Název O požadavcích na strukturu a obsah informaní koncepce a provozní dokumentace a o požadavcích na ízení bezpenosti a kvality informaních systém veejné správy (vyhláška o dlouhodobém ízení informaních systém veejné správy) o postupech atestaních stedisek pi posuzování dlouhodobého ízení informaních systém veejné správy o form a technických náležitostech pedávání údaj do informaního systému, který obsahuje základní informace o dostupnosti a obsahu zpístupnných informaních systém veejné správy o form a technických náležitostech pedávání údaj do informaního systému o datových prvcích a o postupech Ministerstva vnitra a jiných orgán veejné správy pi vedení, zápisu a vyhlašování datových prvk v informaním systému o datových prvcích 42

43 Pedpis (poslední novela) Vyhl.. 52/2007 Sb. (52/2007) Vyhl.. 53/2007 SB. (53/2007) zák.. 137/2006 Sb. (137/2006) zák.. 81/2006 Sb. (81/2006) zák.. 110/2007 Sb. (110/2007) Zkrácený název o postupech atestaních stedisek pi posuzování vazeb ISVS o referenním rozhraní o veejných zakázkách Kterým se mní zákon. 365/2000 Sb., o ISVS o zrušení Ministerstva informatiky Název o postupech atestaních stedisek pi posuzování zpsobilosti k realizaci vazeb informaních systém veejné správy prostednictvím referenního rozhraní o technických a funkních náležitostech uskuteování vazeb mezi informaními systémy veejné správy prostednictvím referenního rozhraní o veejných zakázkách kterým se mní zákon. 365/2000 Sb., o informaních systémech veejné správy a o zmn nkterých dalších zákon, ve znní pozdjších pedpis, a další související zákony zákon o nkterých opateních v soustav ústedních orgán státní správy, souvisejících se zrušením Ministerstva informatiky a o zmn nkterých zákon Tabulka 1 pehled pedpis souvisejících s ISVS [20] Poslední významnjší novela zák.. 365/2000 Sb., která byla pijata jako zák.. 81/2006 Sb., pináší v oblasti ízení ISVS významné zmny, které spoívají pedevším v penesení drazu z jednotlivých ISVS na dlouhodobé ízení celé oblasti 43

44 ISVS jako komplexní dlouhodobý proces probíhající v rámci každého orgánu veejné správy. U samotných informaních systém je pak kladen draz pedevším na kvalitu jejich komunikaního rozhraní, což platí též o provozních informaních systémech, které si s ISVS vymují data. Zákon zmocuje MV k vydávání provádcích pedpis v nkolika oblastech. Z pohledu informaní koncepce je nejdležitjší vyhl.. 529/2006 Sb., vyhláška o dlouhodobém ízení ISVS a vyhl.. 530/2006 Sb., o postupech atestaních stedisek pi posuzování dlouhodobého ízení ISVS. Úinnost vyhlášek je stanovena od Zejména první vyhláška je stžejním podkladem a pomrn pesným návodem pro pípravu informaní koncepce. Další zmnu pravidel v této oblasti pinesl zák.. 110/2007 Sb., zákon o zrušení Ministerstva informatiky, kterým byly kompetence v oblasti dlouhodobého ízení ISVS, pvodn svené Ministerstvu informatiky, kompletn pevedeny na Ministerstvo vnitra, a to ke dni 1. ervna [20] 7.3 Fáze životního cyklu ISVS Životní cyklus ISVS se skládá ze tí ásti. Vztah fází životního cyklu informaního systému, strategických proces a realizaních projekt IS nebo jeho vztah fází životního cyklu IS, strategických proces a realizaních projekt IS je uveden v Tabulce 2. FÁZE ŽIVOTNÍHO CYKLU IS STRATEGICKÉ PROCESY IS REALIZANÍ PROJEKTY IS Píprava IS Definice poteby IS Píprava na zpracování nebo aktualizaci informaní strategie IS Píprava nebo aktualizace nástroj strategického ízení IS Vývoj, provoz a údržba IS Tvorba a údržba informaní strategie ízení bezpenosti Plánování a koordinace Projekty akvizice Projekty základního postupu vývoje Projekty provozu a 44

45 projekt Plánování a ízení jakosti ízení požadavk a jejich monitorování Ukonení innosti IS Vyazení IS údržby Kombinované projekty Tabulka 2 fáze životního cyklu ISVS [23] 7.4 Návrh životního cyklu ISVS Celý návrh životního cyklu IS se musí ídit standardem ISVS, tudíž i jednotlivé kroky, které zde popisuji budou rozdleny do tí hlavních skupin viz. tabulka. V této kapitole se pokusím jednotlivé fáze pesnji specifikovat a vysvtlit Fáze pípravy IS Ped zahájením jakékoli innosti musíme urit tzv. správce ISVS, osobu, která uruje úel a prostedky zpracování informací a za informaní systém odpovídá. Fáze pípravy informaního systému obsahuje innosti a úlohy správce. Definujeme poteby vytvoení informaního systému a dále pokraujeme pípravou a zpracováním zámru rozvoje a informaní strategie. Pokud v organizaci je provozováno více IS musí tato fáze zahrnovat kroky spojené s aktualizací informaní strategie a nástroj strategického ízení. Z dvodu shody požadavk s nov pipravovaným systémem Strategické procesy Strategické procesy obsahují minimální požadavky na dokumentaci, v pípad, že organizace nemá vnitním pedpisem definovanou metodiku pro vývoj, provoz a údržbu IS, vést IS v souladu s pravidly, postupy a innostmi uvedenými ve standardu ISVS a zpracovávat dokumenty, které tento standard požaduje. Pokud mají vnitním pedpisem definovanou metodiku pro vývoj, provoz a údržbu IS, musí ji upravit tak, aby zahrnovala i pravidla, postupy, innosti a dokumenty uvedené ve standardu ISVS a ídit IS v souladu s takto upraveným vnitním pedpisem. 45

46 Definice poteby IS V této fázi je nutno, aby správce popsal koncepci a zdvodnil potebu IS. Koncepce musí být v souladu s principy uvedenými v aktuální verzi dokumentu Státní informaní politika a Informaní politika resortu (resortu správce) v organizacích. Tento požadavek platí pouze pro organizace správc, kteí jsou povinni se tmito dokumenty ídit. Píprava na zpracování nebo aktualizaci informaní strategie IS Správce definuje a analyzuje systémové požadavky IS, do kterých patí definování a analýza zdroje a východiska IS, definování a analyzování výchozího stavu pro rozvoj IS, definování cílového stavu IS, definování prvotního návrhu transformace ze souastného stavu IS do cílového. Píprava nebo aktualizace nástroj strategického ízení IS Správce pipraví základní nástroje strategického ízení IS, bude definovat jejich základní principy a pipraví úvodní verze dokument, kde bude uvedeno: definování základní procedury ízen, bezpenosti ICT, definování principu plánování a ízení projektu, definování principu ízení jakosti IS, definování principu monitorování a aktualizace požadavky na IS Fáze vývoje, provozu a údržby IS Tato fáze obsahuje innosti a úlohy správce a provozovatele v rzných rolích. V této fázi budou probíhat strategické procesy IS periodicky a realizaní projekty IS probíhají jednorázov Strategické procesy obsahují tvorbu a údržbu informaní strategie, kterou správce musí aktualizovat pravideln (nejmén jednou za dva roky) a nap. pokud dojde ke zmn legislativy. ízení bezpenosti Správce ídí bezpenost IS podle postup bezpenostní politiky IS. Opt ji musí aktualizovat po 2 letech. 46

47 Plánování a koordinace projekt Tuto fázi opt spravuje správce e vede o ní požadovanou evidenci. Dále správce vede plánování a ízení jakosti, ízení požadavk a jejich monitorování. Správce musí evidovat požadavky na IS v dokumentu Systémové požadavky Realizaní projekty Standardem ISVS se nepedepisuje použití specifické metody vedení realizaních projekt. Je nutné definovat specifickou metodiku k vedení realizaních projekt IS. Standard ISVS definuje pt druh projekt: Projekty akvizice (získání IS od externího dodavatele), Projekty vývoje (vývoj IS nap. jeho ást, softwarový produkt nebo služba. Mže se zde i IS modifikovat nad rámec bžné údržby), Projekty základního postupu vývoje, (vypracovává se, pokud nejsou splnny podmínky pro použití postupu redukovaného projektu), Projekty redukovaného postupu vývoje (jde o projekty, ve kterých se vyvíjí IS, jeho ást, softwarový produkt nebo služba. Jedná se o projekty, u kterých výsledek nevyžaduje zmnu právního pedpisu nebo výsledek projektu má jednoduchou strukturu a omezené vazby na jiné IS pop. je zcela izolovaný), Projekty provozu a údržby (v tomto projektu se provozuje IS nebo jeho ást nebo se poskytuje provozní podpora uživatelm, mžeme sem zahrnout také drobné opravy systému, které zásadn nemní jeho funknost nebo datové rozhraní. Dále tento projekt zahrnuje innosti spojené s migrací systému nebo jeho ásti na novou verzi, které zásadn nemní jeho funknost nebo datové rozhraní a které jsou ešeny v rámci provozních inností IS) a Kombinovaný projekt (jedná se o kombinaci dvou i více z výše uvedených projekt, do této kategorie patí nap. projekty, ve kterých je proces akvizice kombinován nap. se soubžn probíhajícím procesem vývoje realizovaným vlastními silami správce) Fáze ukonení innosti IS Strategické procesy obsahují pouze jednu fázi a to vyazení IS. Vyazení mže být z dvodu uplynutí ureného období nebo IS je nahrazován novou verzí (migrace), což je souástí procesu provozu. O ukonení innosti IS musí být zpracován plán. Do plánovacích inností se musí zapojit všichni uživatelé. 47