Využití nástrojů CASE pro řízení IS/ICT firmy

Transkript

1 Využití nástrojů CASE pro řízení IS/ICT firmy Semestrální práce pro předmět 4IT450 - CASE Zadal: prof. Ing. Václav Řepa, CSc. ZS 2010/2011 Vypracovali: Marcela Fišerová Tomáš Baxa Marek Hejcman Svatopluk Ježek Lukáš Kapitán Petr Vaněk

2 Obsah 1. ÚVOD TERMINOLOGIE IS - INFORMAČNÍ SYSTÉM IT - INFORMAČNÍ TECHNOLOGIE ICT - INFORMATION AND COMMUNICATION TECHNOLOGIES CASE - COMPUTER-AIDED SOFTWARE ENGINEERING ŘÍZENÍ IS/ICT DŮVODY ŘÍZENÍ IS/ICT DŮVODY POUŽITÍ NÁSTROJŮ CASE [2] NÁSTROJE CASE PRINCIPY ŘÍZENÍ PODNIKOVÉHO IS/ICT HISTORIE NÁSTROJŮ CASE VZNIK NÁSTROJŮ CASE LÉTA LÉTA SOUČASNOST MODELOVACÍ JAZYKY UML HISTORIE UML DIAGRAMY NÁSTROJE PRACUJÍCÍ S UML MODEL DRIVEN ARCHITECTURE MODELY MDA TRANSFORMACE MEZI MODELY CIM, PIM, PSM A CODE MDA NÁSTROJE METODIKY ŘÍZENÍ IS/ICT CMMI (CAPABILITY MATURITY MODEL INTEGRATION) METODIKA RATIONAL UNIFIED PROCESS METODIKY KONTROLINGU IS/ICT ITIL COBIT - CONTROL OBJECTIVE FOR INFORMATION AND RELATED TECHNOLOGY SROVNÁNÍ ITIL A COBIT KONKRÉTNÍ PRODUKTY PRO ŘÍZENÍ IS/ICT PŘÍPADOVÁ STUDIE ZÁMĚR INVESTORA VÝCHOZÍ SITUACE IS/ICT SPOLEČNOSTI REENGINEERING IS/ICT SPOLEČNOSTI ŘÍZENÍ IS/ICT SPOLEČNOSTI [52] PŘÍNOSY ZÁVĚR ZDROJE

3 1. Úvod Tato práce se snaží přiblížit některá fakta týkající se řízení IS/ICT pomocí nástrojů CASE. Práce je koncipovaná do dvou částí. První část je koncipována jako přehledová stránka tématu. Věnuje se především definováním jednotlivých terminologických pojmů, které se v závislosti řízení IS/ICT používají. Dále se věnuje různým metodikám, které se využívají při řízení IS/ICT a také kontrolingu. Jednou z velkých kapitol je potom část věnující se jazyku UML. Zde je detailněji popsán i jeden z nejznámějších produktů CASE, který používá právě zmíněný jazyk UML, tzn. popis veškerých možných diagramů použitelných pro řízení IS/ICT. Dále se teoretická část věnuje modelu MDA, který se často využívá právě při používání nástrojů CASE a to při řízení IS/ICT. Poslední částí teoretické stránky práce se stala kapitola věnující se jednomu z nástrojů CASE pro řízení podnikové informatiky Enterprise Architect 7.0. Druhou částí naší seminární práce je případová studie. Práce zde představuje fiktivní firmu. Případová studie se zde snaží popsat a přiblížit, za pomoci jakých nástrojů, a podle jakých principů může probíhat řízení podnikového IS/ICT. 2

4 2. Terminologie 2.1. IS - informační systém je kombinace informační technologie a činnosti lidí, kteří využívají tyto systémy k podpoře provozu, řízení a rozhodování ve smyslu technologických prostředků a metod, které zabezpečují sběr, přenos, zpracování a uchování dat za účelem tvorby prezentace informací pro potřeby uživatelů. [8] 2.2. IT - Informační technologie je věda, která se zabývá způsobem, jakým fungují hmotná část počítače (hardware). Informační technologií je každý elektronický přístroj schopný provádět algoritmus, tedy přijmout vstupní data, samostatně s nimi provést nějaké operace a vydat příslušná data výstupní. [7] 2.3. ICT - Information and Communication Technologies je označení pro informační a komunikační technologie. Tato zkratka zahrnuje veškeré technologie používané pro komunikaci a práci s informacemi. Základní koncept IT byl doplněn o prvek komunikace, kdy mezi sebou začaly komunikovat jednotlivé počítače. ICT ovšem nejsou jen hardwarové prvky, ale také softwarové vybavení. V moderním světě představují informační a komunikační technologie důležitou a nepostradatelnou součást státní, podnikatelské i soukromé sféry. Z tohoto důvodu patří jejich ovládání mezi klíčové kompetence. [9] 2.4. CASE - Computer-aided software engineering je použití softwaru pří vývoji počítačových programů, údržbě softwarových produktů za účelem dosáhnutí vyšší kvality, bezchybnosti, udržovatelnosti. Nástroje CASE neslouží pouze k vývoji softwaru, ale využívají se i v jiných oblastech firmy, které dokážou využít potenciálu nástrojů CASE Některé obvyklé nástroje CASE: generování zdrojového kódu nástroj pro datové modelování UML nástroje pro refaktorování správa konfigurací [3] 2.5. Řízení IS/ICT Stále se zvětšující komplexnost IS/ICT vyvolává potřebu použití metodicky propracovaných a v praxi použitelných postupů řízení vývoje a změn IS/ICT. Řízení IS/ICT je chápáno jako sled na sebe navazujících procesů, které umožňují kvalitně zvládnut změny informatiky a její pomoci v podnikatelských aktivitách. Řízení IS/ICT rozdělíme na jednotlivé úrovně na základě pravomocí a oblasti využití. 3

5 Obrázek 1 schéma řízení IS/ICT v podniku, zdroj: [1] Strategické řízení IS/ICT Činností, které jsou realizovány především na úrovni managementu společnosti. Jedná se o dokumenty, které plánují dlouhodobější budování IS/ICT ve firmě, základní pravidla, principy a cíle. Tyto aspekty by se pak měli promítnout a realizovat v rámci jednotlivých IS/ICT projektů. Jedná se zejména o: Informační strategie Bezpečnostní strategie a politika Organizace řízení IS/ICT Taktické řízení IS/ICT Zahrnuje činnosti, které souvisí přímo s vývojem a zaváděním nových prostředků IS/ICT. Jedná se zejména o: Řízení služeb IS/ICT Plánování projektu Řízení ekonomiky IS/ICT a metrik Řízení personálních a datových zdrojů 4

6 Operativní řízení IS/ICT Do této oblasti patří jednak běžný provoz a podpora IS/ICT v každodenním běhu firmy. Za druhé se pak jedná o řízení jednotlivých projektů, jejich vzájemných závislostí, kontrola jejich průběhů a plnění cílů Důvody řízení IS/ICT Stále větší množství činností v organizaci se neobejde bez podpory IS a ICT. Jedná se o podporu hlavních podnikových procesů procesy informatiky organizace, díky tomu vzniká přímá úměra mezi flexibilitou organizace a informatikou organizace. Rostoucí trend IT podpory pro různé oblasti činnosti organizace má za následek větší provázanost a závislost mezi jednotlivými částmi IS/ICT. S růstem podpory rostou i požadavky uživatelů podnikových systému na vylepšení funkcionality a na rychlost implementace změn. S přibývajícími změnami v informačních systémech roste komplexita těchto systémů. Větší komplexita systémů má za následek náročnější řízení Informačních systémů. Náročnější řízení zvyšuje náklady na provoz IS, údržbu IS, na drobné úpravy IS a hůře se odhadují náklady na integraci jednotlivých částí do jednotného IS. Komplexita IS/ICT může vést k neovladatelnosti a nepředvídatelnosti systému s fatálními následky pro chod organizace. Proto je důležité tento rozvoj a změny řídit, aby nedocházelo k narušení organizace zevnitř. Řízení podnikových procesů hlídá náklady na provoz IS/ICT v mezích a nedochází k nesmyslnému navyšování. Jestliže rozvoj podnikových systémů není dobře řízen, dochází k zvyšování nákladů na IS/ICT, neboť špatně řízené změny, které se promítnou do informačních systémů je v konečném důsledku velmi nákladná záležitost. Prvotní promítnutí změny nebo přidání funkcionality se sice zpočátku při takovémto přístupu jako příliš nákladné nejeví, ale velmi záhy se ukáže potřeba provést další úpravy, na které se původně zapomnělo, což má za následek dodatečné úsilí a náklady Důvody použití nástrojů CASE [2] Case nástroje nám pomáhají lépe pochopit stav procesů a jejich rozvoj za pomoci modelování diagramů. Modely využíváme pro řízení a rozvoj IS/ICT, napomáhá implementaci a integraci, ale i celkovému pochopení procesů v organizaci. Díky vývoji IT se stále častěji setkáváme s rozsáhlejším IS, na kterém se podílelo více dodavatelů. Pro lepší řízení těchto IS je zapotřebí kvalitní modely informačních systémů, které nám poskytují právě CASE nástroje. Dalším prvkem, proč modelování využívat je rozvoj a změna IS. V řízeném promítání změn do IS, musíme mít zjištěny dopady těchto změn na IS organizace. Nestačí pouze zdrojový kódu pro analýza dopadů, je zapotřebí i další modely, které osvětlují strukturu IS a jeho provázanost. Modely procházejí při iterativním návrhu IS a při jeho následném řízení úpravami, je vhodné je vytvářet a upravovat pomocí nástrojů CASE, které je umožňují udržovat v aktuálním stavu. Tyto modely dokumentují stav návrhu v příslušném stádiu a po dokončení systému se stávají součástí finální dokumentace. Vidíme tedy, že řada zdrojů pro dokumentaci je uložena právě v nástrojích CASE. Použití nástrojů CASE podporuje kreativitu analytiků a návrhářů. Pro povzbuzení kreativity je klíčovou možností model problému nejen snadno vytvořit, ale především ho snadno změnit. Kreativitu nebrzdí fakt, že dotyčný zjistí, že se daná situace dá vyřešit lépe a efektivněji, ale odradí ho pracnost se změnou modelu. 5

7 Další možnost, která podporuje kreativitu, je volba úrovně abstrakce, ve které chce řešitel model vytvářet či upravovat. CASE přitom v mezích svých možností zajišťuje konzistenci mezi jednotlivými úrovněmi pohledů na model systému. Podobně zajišťuje konzistence při vertikálním členění modelu do jednotlivých problémů, jedná se o zajištění konzistence jednotlivých výřezů modelu mezi sebou. Nástroje CASE podporují práci v týmu a z hlediska přenosu informací mezi pracovníky řeší CASE dva klíčové aspekty, zajištění správné struktury a zajištění konzistentního obsahu. Z hlediska struktury komunikace definuje CASE to, pomáhá tomu, aby si řešitelé porozuměli. Jedná se především o notaci jednotlivých diagramů, jejich význam a vzájemné vazby. Pro zajištění konzistence jsou informace ukládány do speciální databáze, která se nazývá repository. Repository usnadňuje především sdílení informací v týmu Nástroje CASE se podílejí také na údržbě a rozvoji existujícího IS. Údržbu aplikace nejvíce prodražuje fakt, že se změny IS nedaří realizovat na první pokus a následně je nutné opravit vedlejší efekty a různé chyby, které byly změnou do IS zavlečeny. Příčina těchto problémů je nedostatečná analýza dopadů změny. Analýza dopadů změny na IS nástroje CASE zjednodušují, protože v modelu aplikace zaznamenávají závislosti mezi jednotlivými prvky, takže je možné snadno a rychle najít, kde všude bude potřeba provést změnu. Změna se nemusí týkat pouze kódu aplikace, ale i činností uživatele, které jsou popsány procesním modelem. Právě změny, které mají dopad na firemní procesy, je důležité důkladně analyzovat, a v tom výrazně pomáhají nástroje CASE. [35] 2.8. Nástroje CASE Nástroje CASE primárně umožňují: modelování IT systému pomocí diagramů generování zdrojového kódu z modelu zpětné vytvoření modelu podle existujícího zdrojového kódu (reverse engineering), synchronizaci modelu a zdrojového kódu, vytvoření dokumentace z modelu. Nástroje CASE jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému, zajišťují sdílení rozpracovaných fragmentů, správu vývoje, sledují konzistenci modelu systému, automatizují některé procesy, hlídají dodržování zvolené metodiky, některé umožňují řízení celého životního cyklu aplikací. Úspěch využití nástrojů CASE záleží mimo jiné na vybrané metodice. [4] 6

8 3. Principy řízení podnikového IS/ICT V současné době se řízení podnikové řízení soustředí na optimalizaci informatické podpory pro podnikové procesy. Dalším cílem tohoto řízení je poté soustředění se na návratnost investic právě do informačních systémů a komunikačních technologií. Dnešní trendy v řízení IS/ICT ve firmě charakterizuje model SPSPR. Tento modle vyvinula katedra informačních technologií na Vysoké škole ekonomické v Praze. Jeho cílem je zajistit optimální informatické podporu pro podnikové procesy a již zmíněnou návratnost investic do ICT. Chceme-li úspěšně řídit podnik s pomocí moderních ICT, musíme si uvědomit, že kritickým faktorem úspěchu je úspěšná integrace řízení podnikových procesů s řízením ICT. Zde popsaný model napomáhá k této integraci tím, že jasně vymezuje jednotlivé oblasti řízení a jejich rozhraní. [5] 3.1. Model SPSPR Tento model se skládá z celkem pěti provázaných vrstev: S Strategy P Business Processes S ICT Services P ICT Processes R ICT Resources První vrstva Strategické řízení podniku Toto řízení je plně v kompetenci vrcholového managementu. Mezi základní výstupy tohoto řízení patří: Jaké cíle a priority bude podnik sledovat Jaké produkty či služby bude nabízet zákazníkovi Jakému okruhu zákazníkům bude tyto produkty či služby poskytovat Do jakých kooperačních vztahů bude podnik vstupovat Definice finančních a materiálových vztahů Jaké zdroje (lidské, finanční apod.) bude podnik potřebovat Jak budou tyto zdroje získány Jaké metriky budou použity k měření stupně dosažení cíle Druhá vrstva hlavní a podpůrné procesy podniku Pokud chce podnik naplňovat své cíle smysluplně pomocí svého hlavního předmětu podnikání, musí umět správně spravovat své hlavní podnikové procesy. Tyto procesy jsou právě zařazeny do druhé vrstvy modelu SPSPR. Hlavním cílem druhé vrstvy je návrh a řízení podnikových procesů tak, aby organizace dosáhla svých podnikových cílů definovaných ve vrstvě první. 7

9 Aktivity, které napomáhají naplňovat cíle druhé vrstvy, jsou následující: Definice a optimalizace PP 1 Operativní řízení procesů a kapacit Monitoring procesů Realizace (vykonávání) procesů Následující schéma znázorňuje rozdělení pravomocí mezi business a ICT manažery dle modelu SPSPR. Obrázek 2 - vztahy mezi jednotlivými manažery v SPSPS, zdroj: [5] Manažer odpovídající za definici a optimalizaci procesů v podniku je za navržení procesu zodpovědný tak, aby byl proces schopen v konkurenceschopném prostředí a za optimální časovou hodnotu vyrobit produkt (službu) odpovídajícího objemu a kvality s přijatými náklady. Součástí návrhu podnikového procesu je i návrh informačních prostředků, které budou daný proces v podniku podporovat. Z tohoto důvodu je takto jasně a exaktně definována zodpovědnost manažera (vlastníka)podnikového procesu za objednaný rozsah a objednanou kvalitu informačních služeb. Úkolem vlastníka podnikového procesu je také finanční kalkulace, která by měla přiblížit, jaká je přijatelná cena za požadované informační služby a prostředky. Jelikož je informační služba jednou ze součástí (nákladovou položkou) celého podnikového procesu, tak by určité překročení její ceny mělo 1 Podnikové procesy 8

10 za následek, že vzniklý produkt nebo služba by neměly šanci na konkurenceschopném trhu. Tak nám v tomto momentu vzniká jedno z klíčových míst celého modelu. Pokud není možné požadovanou informační službu pořídit za danou cenu, je nutné upravit celý hlavní proces i jeho požadavky na informační službu Třetí vrstva řízení informatických služeb Manažer procesu nabývá informační službu u manažera informatických služeb. Pokud je řízení v podniku centralizováno, manažer informatických služeb je jmenován jako ředitel informatiky, tzv. CIO (Chief Information Officer). Tato osoba poté rozhoduje o všech formách zajištění informatických služeb, a to, zda se bude jednat o zcela externí nebo zcela interní služby či zda půjde o jejich kombinaci. V případě kdy se bude jednat o decentralizované řízení, může se manažer procesu obrátit na externí organizace poskytující informatické služby a nakoupit je přímo od nich. V takovémto případě je vhodné, aby definice informatické služby měla stejnou strukturu, pokud nakupuje organizace interně nebo u externích dodavatelů. Vhodnou formou outsourcingu je tzv. SLA (Service Level Agreement). Definuje obsah, objem, kvalitu a cenu služby. V případě, že použijeme stejnou strukturu definice služeb, potom získáme množinu kritérií, které pomohou managementu v rozhodnutí, zda nakoupit službu od interního nebo externího poskytovatele. V případě, že se rozhodne pro externí zajišťování informatických služeb (ASP či outsourcing), je podmínkou, aby manažer sepsal smlouvu obsahující SLA s externím poskytovatelem a dodržel kontrolu jejího plnění. Pro organizaci to přináší i několik výhod společnost se může koncentrovat na hlavní předmět podnikání, zvýší se flexibilita informatických služeb a sníží se náklady na zajištění služeb. V případě interního pořízení informatické služby, tzn. vnitropodnikovými zdroji, je nutné, aby byly vytvořeny odpovídající podnikové informatické procesy a zajištěny informatické zdroje, které jsou informatickými procesy vyžadovány (např. hardware, software, data, lidé). Zde by mělo být úkolem manažera zajistit, aby v podniku docházelo k maximálnímu sdílení informatických zdrojů mezi všemi interně zajištěnými službami. Toho jde docílit například stanovením podnikových standardů (např. stejný typ kancelářských aplikací pro všechny uživatele apod.) nebo sdílení informatických specialistů podniku mezi službami. Mezi rozhodnutí manažera také patří, aby důsledně rozhodnul, zda služby nakupovat interně či externě nebo zda tyto typy zkombinovat. Manažeři musejí být schopní flexibilně reagovat na jakékoli změny v dodávce informatických služeb a jejich dopadů na běh podniku. Musí snadno a hlavně efektivně a pružně přizpůsobovat strategii podniku a změny být schopen prosadit a implementovat Čtvrtá vrstva Informatické procesy Informatická služba je produkována informatickými procesy, a proto tvoří čtvrtou vrstvu modelu SPSPS, kterou řídí manažeři informatických procesů. Mezi tyto procesy patří například: Level Management, Availability Management, Incident Management (viz metodika ITIL). 9

11 Význam kvalitní definice informatických procesů roste zejména s těmito parametry informatických služeb: Význam podnikového procesu, pro jehož podporu bude informatická služba pořízena o Pokud se jedná o kritické procesy, bude požadována vysoce kvalitní služba Počet uživatelů, kteří budou službu využívat o Je logické, že čím více se bude služba používat, tím preciznější musí být proces zajišťující službu Nároky na kvalitu služby o Jedná se například o dobu odezvy, bezpečnost ad. Celkový počet informatických služeb o jelikož s růstem počtu informatických služeb rostou i nároky na jejich integraci Celkový počet informatických zdrojů, které jsou informatickými procesy konzumovány Z předcházejících bodů tedy vyplývá, že řízení informatiky bude na tím vyšší úrovni, čím více služeb si podniky zajišťují interně a čím více jsou náročnější na parametry poskytovaných služeb Pátá vrstva řízení jednotlivých informačních zdrojů Tato vrstva zahrnuje technologickou infrastrukturu (hardware, software, počítačová síť ad.), data, spotřební materiál a informatický personál. Manažeři na této úrovni jsou: správce sítě, databáze apod. Jejich úkolem je spravovat systém v návaznosti na nákladech. Proto činnosti, které tito manažeři vykonávají, patří například do oblasti plánování, sledování vývojových trendů a vytížení zdrojů a řízení personálních zdrojů. [6] 10

12 4. Historie nástrojů CASE 4.1. Vznik nástrojů CASE Vznik nástrojů CASE je úzce spjat se vznikem disciplíny softwarového či také někdy systémového inženýrství. Tato disciplína zabývající se aplikací systematického, disciplinovaného, kvantifikovatelného přístupu k vývoji, provozu a údržbě softwaru vznikla na přelomu 60. a 70. let, kdy se hardwarové prostředky dostaly ve výkonu dále než požadavky softwarových nástrojů. V této době se stal vývoj softwaru nejen otázkou vědeckou, ale rovněž otázkou businessu. V businessu je však vždy potřeba optimalizovat efektivitu, v tomto případě efektivitu softwarového vývoje. Nástroje CASE vznikly právě pro podporu vývoje software a první nástroje se především zabývaly automatickým generováním programového kódu. Původní záměr těchto CASE nástrojů byl, že nebude při programování vůbec třeba programátora, jelikož veškerý kód bude vygenerován automaticky. Tato teorie se však s postupem času ukázala jako mylná léta Na počátku 80. let byly nástroje CASE spíše ještě v plenkách. Výraznější rozvoj možností CASE nástrojů proběhl především s příchodem grafického uživatelského rozhraní, které umožňovalo provádět i pokročilejší úpravy kódu jednoduše. Tyto nástroje nabízeli od formátování kódu přes tvorbu jednoduchých diagramů v analytických a návrhových fázích vývoje, verzování jednotlivých dokumentů až po ukládání údajů o jednotlivých datových typech vyvíjeného softwaru. Některé CASE v 80. letech již také podporovali automatizované testování samotné vyvíjené aplikace. Nástroje také nabízely možnost strojového generování určitých částí programového kódu a tak vznikala celá řada nástrojů, které byly vytvořeny pro různé programovací jazyky léta V 90. letech se CASE stávaly ještě více sofistikovanými nástroji pro vývoj software. CASE začaly podporovat implementační proces od počátečního návrhu, přes správu datových toků až po generování některých částí programového kódu. Nástroje CASE tak efektivně spravují jednotlivé komponenty a potřebné informace o nich. V 90. letech se také již objevily nástroje CASE, které podporují kompletní životní cyklus softwarové aplikace Současnost V současné době nabízejí nástroje CASE nejen podporu celého životního cyklu projektu, ale zároveň nabízejí možnost vývoje softwaru specializovaného pro určitou platformu jazyků (jako např..net). Nástroje CASE současnosti však slouží i pro řadu dalších věcí, především pro řízení firmy. CASE dokážou dobře modelovat procesy probíhající ve firmě a ty tak lze jednoduše mapovat a zjišťovat jejich účinnost a efektivitu a případně provádět jejich úpravy. Tyto nástroje jsou tedy již velmi komplexními a rozmanitými prostředky pro softwarové (systémové) inženýrství. 11

13 5. Modelovací jazyky UML Jelikož se v dalších částech práce věnujeme metodikám řízení a kontrole informačních systémů, rozhodně není od věci si alespoň základně popsat Unified Modeling Language, jelikož např. metodika RUP jej přímo využívá a modely zachycené tímto modelovacím jazykem jsou důležitým podkladem při další práci se systémem, ať už se jedná o jeho řízení, nebo jako technologická dokumentace. Modely se z pohledu řízení IS samozřejmě nedají využít všechny, ale některé z nich jsou v tomto procesu užitečné. Především za účelem porozumění sytému, jeho organizaci, stavu a rozdělením do různých logických celků. Unified Modeling Language (dále jako UML) je standardizovaný grafický jazyk, který se používá v oblasti softwarového inženýrství za účelem vizualizace, návrhu, upřesnění a dokumentaci programovaných informačních systémů. UML umožňuje modelovaný systém zachytit z mnoha úhlů pohledu. A to jak z čistě konceptuálního hlediska, jako je fungování budoucího systému jako celku a jeho návaznost na podnikové procesy a podnik samotný, tak i popisu zcela konkrétních věcí jako struktura daného systému, která pak slouží programátorům jako podklad pro práci. UML však není metodikou a neobsahuje žádné návody, jak jej použít či jak provádět analýzu systému. Je pouze nástrojem, který má pomoci fáze tohoto procesu vývoje vhodně a srozumitelně zachytit Historie UML Historie UML sahá do roku 1994, kdy Grady Booch a Jim Rumbaugh začali ve firmě Rational Software spojovat své metodiky Booch a OMT (Object Modeling Technique). Na konci roku 1995 koupila firma Rational Software společnost Objectory AB, ze které přišel Ivar Jacobson se svojí metodologií OOSE (Object-Oriented Software Engineering). [34] V roce 1996 však ve firmě Rational Software došli k závěru, že mnoho druhů modelovacích metod zpomaluje práci a vytváří nekonzistence, a tak začali výše zmínění pánové vytvářet jednotný modelovací jazyk. Výsledkem byl Unified Modeling Language (UML), který byl následně ve verzi 1.1 v roce 1997 přijat OMG (Object Management Group). Vývoj modelovacího jazyku stalé neustal a v jednotlivých dalších verzích docházelo a dochází k drobným i větším změnám. Poslední verzí je UML Diagramy Diagramy UML představují dva základní pohledy na programovaný systém. Statický pohled (nebo strukturální), který klade důraz na statické struktury systému pomocí systémových entit a vztahů mezi nimi, které musí být přítomny v modelovaném systému. Dynamický pohled, který zdůrazňuje chování systému tím, že zobrazuje spolupráce mezi entitami a změny jejich vnitřních stavů. Poslední verze UML 2.2 obsahuje 14 typů diagramů, rozdělených do dvou výše zmíněných skupin. Sedm typů diagramů představují strukturální (statické) informace, a dalších sedm představují obecné typy chování (dynamické), včetně čtyř, které reprezentují různé aspekty interakce v systému. Diagramy lze hierarchicky rozdělit, jak je uvedeno na Obrázku 1. [34] 12

14 Obrázek 3 - Hierarchie UML diagramů, zdroj: [34] Strukturální diagramy: 1) Diagram tříd 2) Diagram komponent 3) Diagram vnitřní struktury 4) Diagram nasazení 5) Diagram balíčků 6) Diagram objektů 7) Profile diagram Diagramy chování: 8) Diagram aktivit 9) Diagram užití 10) Stavový diagram Diagramy interakce: 11) Diagram událostí 12) Diagram komunikace 13) Diagram přehledů interakcí 14) Diagram časování 13

15 Strukturální diagramy 1) Diagram tříd Diagram tříd je hlavním stavebním kamenem v objektově orientovaného modelování. Je požíván jak pro obecné koncepční modelování systému, tak i pro tvorbu detailních modelů, na jejichž základě je pak generován programový kód. V diagramu tříd jsou tedy uvedeny třídy, skupiny tříd a jsou zde zobrazeny i vztahy mezi těmito objekty v rámci systému. [35] 2) Diagram komponent Obrázek 4 - Dagram tříd, zdroj: [36] Diagram komponentů zobrazuje, jak jsou jednotlivé komponenty systému propojeny navzájem a tvoří větší komponenty resp. celé systémy. Lze jej použít k popsání struktury libovolně složitého systému. Diagram je tedy tvořen komponentami, které jsou navzájem propojeny pomocí vazeb a vzájemná komunikace je pak realizována pomocí přesně definovaných rozhraní obou komponent. [38] Obrázek 5 - Diagram komponent, zdroj: [37] 14

16 3) Diagram vnitřní struktury Jedná se o diagram, který byl zařazen do verze UML 2.0. Umožňuje znázornit interní strukturu komplexního prvku (např. případ užití či komponenta). Pomocí tohoto diagramu může autor zobrazit spolupráci právě zmíněného prvku (tzv. klasifikátor)s ostatními prvky v systému. Tento diagram je ale velmi problematický, neboť jeho vyložení se může různit. V některých případech pomocí tohoto diagramu můžeme znázornit kolaboraci mezi klasifikátory anebo ho můžeme pojmout jako model, který zachycuje interní strukturu klasifikátoru.[39] Obrázek 6 - Diagram vnitřní struktury, zdroj: [40] 4) Diagram nasazení Diagram nasazení slouží k zachycení systémové implementace. Zobrazuje uzly, které představují hardware, na kterém systém běží. A dále artefakty uvnitř uzlu, které reprezentují softwarové komponenty na něm běžící a neposlední řadě ukazuje i vztahy mezi těmito prvky. [41] Obrázek 7 - Diagram nasazení, zdroj: [42] 15

17 5) Diagram balíčků Diagram balíčků slouží k zobrazení rozdělení a organizace systému do balíčků vzájemně souvisejících komponent a k zachycení vztahů mezi nimi. Diagram balíčků lze také použít pro ilustraci funkčnosti celého systému. [43] Obrázek 8 - Digram balíčků, zdroj: [44] 6) Diagram objektů Jinak můžeme diagram objektů také nazvat diagramem instancí. Diagram objektů zobrazuje úplný nebo částečný pohled na strukturu modelovaného systému v určitý okamžik. Diagram zachycuje určitou skupinu instancí, jejich atributů a vazeb mezi nimi, tak jak by se měli v průběhu času měnit. Diagram objektů je podobný diagramu tříd a vychází z něj, je však konkrétnější. [45] Obrázek 9 - Diagram objektů, zdroj: [46] 16

18 7) Profile diagram Profile diagram je jeden z novějších diagramů struktury, který rozšiřuje mechanismy UML o definování vlastních stereotypů, značených hodnot a omezení. Diagram funguje především na úrovni metamodelu UML a umožňuje jeho úpravy či přizpůsobení pro využití na specifické doméně, nebo platformě. [47] Obrázek 10 - Profile diagram, zdroj: [48] Diagramy chování 8) Diagram aktivit Diagram aktivit se používá pro znázornění dynamických aspektů popisovaného systému. Znázorňuje to řízení z aktivity do aktivity, popřípadě může vyjádřit model obchodních procesů nebo workflow. V podstatě je podobný stavovému diagramu (viz níže), nicméně rozdíl se nachází v tom, že diagram aktivit se soustřeďuje spíše na popis výpočtu stavu, nikoliv stavy samotné. Příklad diagramu aktivit můžeme vidět na obrázku 9. [17] 17

19 Obrázek 11 Diagram aktivit, zdroj: [18] 9) Diagram užití Někdy se také nazývá diagram případů užití z anglického use case diagram. Jedná se o diagram, který zobrazuje dynamické (funkční) struktury systému z pohledu uživatele. Primárně je určen k definici chování systému bez nutnosti odhalit jeho vnitřní struktury. Můžeme ho také označit za soubor scénářů pro používání systému, přičemž každý tento scénář obsahuje sekvenci (posloupnost) událostí, které v jeho rámci probíhají, a popis interakce (komunikace) mezi uživatelem (aktorem) a systémem. Na závěr k tomuto diagramu můžeme říci, že se jedná o grafické znázornění části dokumentu nazývaného Specifikace požadavků, který už ale není otázkou této práce. [49] Obrázek 12 Diagram případů užití, zdroj: [18] 18

20 10) Stavový diagram Stavové diagramy zachycují jednotlivé stavy objektů, kterými tyto objekty procházejí nebo mohou procházet a to v rámci jejich životního cyklu v daném systému. Jednotlivé objekty jsou v diagramu znázorněny jako obdélníky se zaoblenými. Každý z objektů má obvykle svůj počáteční stav a konečný stav, přičemž ke změnám (přechodům) mezi jednotlivými stavy může dojít buďto jako následek nějaké akce (události) nebo pouhým plynutím času. Přechody mezi jednotlivými stavy jsou symbolizovány šipkami. Samostatnou kapitolou stavových diagramů jsou tzv. podstavy, neboli změny stavu v rámci jednoho stavu. [16] Obrázek 13 Jednoduchý stavový diagram, zdroj: [17] Diagramy interakce 11) Diagram událostí Pro tento diagram se také užívají názvy Sekvenční diagram. Tento diagram, obdobně, jako diagram komunikace (viz níže), jsou navzájem natolik provázané, že je lze převádět z jedné formy na druhou (ovšem, nejsou-li příliš složitě strukturované). Sekvenční diagram je vhodné použít v případech, kdy chceme znázornit časové souvislosti interakcí. [18] Jedná se o model časové dynamiky uvnitř Use Case (časová posloupnost zasílání zpráv mezi objekty). [50] 19

21 Obrázek 14 Sekvenční diagram, zdroj [18] 12) Diagram komunikace V UML 2.0 se vyskytuje tento diagram právě pod názvem diagram komunikací, nicméně z dřívějších verzí UML 1.X je znám jako collaboration diagram. Jak již bylo uvedeno výše, diagram komunikace je izomorfní (převoditelný tam i zpět) se sekvenčním diagramem. Stejně jako úkol sekvenčního diagramu, je i úkolem diagramu komunikace znázornit interakce v systému. Umí vyjádřit skutečnost, že objekty si mezi sebou posílají zprávy. [18] 13) Diagram přehledů interakcí Obrázek 15 Diagram komunikace, zdroj: [18] Jedná se o obměnu diagramu aktivit, přičemž jeho podstata tkví v tom, že se snaží popsat interakce v systému pomocí varianty diagramu aktivit, do kterého jsou vkládány fragmenty sekvenčních diagramů. [18] 20

22 Obrázek 16 Diagram přehledů interakcí, zdroj: [18] 14) Diagram časování Jedná se o obměnu diagramu načasování. Hlavní snahou je zobrazit interakce z hlediska posloupnosti v čase. Vyjádření diagramem časování je explicitní a zobrazuje změny stavu v čase (v předem definovaných časových jednotkách). Jeho využití můžeme nalézt například při modelování real-time aplikací. [18] Obrázek 17 Diagram časování, zdroj: [18] 21

23 5.3. Nástroje pracující s UML Jak již ze specifikace nástrojů CASE obecně vyplývá, jedná se o software, který umožňuje modelování reality, respektive modelování systémů a následně, v některých případech i generování zdrojového kódu z těchto modelů. V tomto případě se bude hovořit konkrétně o těch nástrojích, které k modelování reality využívají Unified Modeling Language, jinak také UML. Škála produktů, které se problematikou modelování v UML zabývají, je velice široká, ať už se jedná o produkty komerční, či volně stažitelné a použitelné, napříč celým spektrem platforem operačních systémů. Analýza všech produktů by byla samostatným tématem jiné práce, proto zmíníme pouze některé nejznámější nástroje Umbrello UML Modeller Umbrello UML Modeller je nástroj vyvíjený primárně pro operační systémy na bázi UNIXu, nicméně je k dostání i verze pro OS Windows. Většina ostatních aplikací nástrojů pro podporu modelování UML je psaná v programovacím jazyce Java, ne tak Umbrello. Jeho zdrojový kód je sepsán v jazyce C++, což, společně s jednoduchostí řešení, které je zajištěno díky tomu, že aplikace je vyvíjena v rámci komunity odborníků-nadšenců, vede k vyšší rychlosti odezvy aplikace a širší podpoře dalších programovacích jazyků (PHP, Perl). Nevýhodou tohoto nástroje je špatná přenositelnost na jednotlivé platformy OS oproti aplikacím v Javě, které fungují pod JRE (Java Runtime Environment). [19] Powerdesigner Výkonný a časem prověřený nástroj společnosti Sybase se v současné verzi 15.2 umožňující efektivní modelování a správu metadat. Jistou nevýhodou tohoto nástroje je fakt, že nepodporuje více platforem OS, v podstatě podporuje pouze OS Windows. Nedá se s určitostí tvrdit, že se jedná vyloženě o radikální negativum, jelikož například komunita UNIXových systémů si stejně vyvíjí vlastní produkty. Jako velice vyspělý nástroj umožňuje PD jak modelování všech diagramů UML, tak i generování kódu v jazycích Java, VB,.NET, C# a dalších. Praktickou součástí je také možnost generování reportů, podpora XML a umisťování souborů do tzv. respozitoře, což zvyšuje efektivitu práce týmu vývojářů, kteří tento nástroj vuyžívají. [20] MagicDraw UML Nástroj CASE vyvinutý společností No Magic Inc. zahrnuje komplexní řešení pro modelování nejen diagramů UML. Jako většina ostatních komerčních produktů s dobrým zázemím mateřské společnosti je s ním možno modelovat i business procesy, datové modely a další. Nástroj umožňuje i generování kódu v jazycích Java, C++, C# a jiných. Mimo těchto funkcí podporuje také týmovou práci a je schopen integrace s následujícími vývojovými prostředími: Sun Java Studio, Oracle Workshop, NetBeans, Eclipse a mnoha dalšími. [21] Astah* Astah je rodina nástrojů pro modelování diagramů UML, myšlenkových map s doplňky pro ERD (Evolutionary Rapdi Development proces vývoje SW), DFD (Data Flow Diagram) a CRUD (Create Read Update Delete). Přínosem tohoto nástroje je usnadnění komunikace vývojářského týmu, jelikož veškeré diagramy pro daný projekt jsou přehledně uloženy jako jeden model. Astah* jako jeden z mála komerčních produktů podporuje různé Operační Systémy, jak Windows 32 i 64 bitovou verzi, Mac OS, tak i Linux. To vše díky tomu, že je napsán v Javě a běží pod JRE. Nástroj umožňuje modelovat všechny diagramy UML ve verzi UML 2.X a má velice dobře zpracované uživatelské rozhraní. [22] 22

24 ArgoUML Je open-source nástroj, který je vydáván pod licencí BSD. Tento nástroj umožňuje mimo tvorby řady diagramů UML také tvorbu návrhů databází. Tento nástroj umožňuje generovat z uložených diagramů tříd zdrojový kód aplikace a to primárně v jazyce Java. Jelikož je ale tento nástroj vyvíjen daleko rychleji a s větším zájmem jeho vývojářů, je možné po přidání dalších modulů generovat také kód C++, PHP, a dalších. Předností nástroje je nepochybně možnost on-line spuštění. [19] Visual Paradigm fo UML Další komerční nástroj pro modelování UML a nejen pro něj. Jedná se o komplexní sadu nástrojů pro modelování, mimo UML, také business procesů a databázových struktur. Nástroj má plnou podporu jazyka UML a podporuje tak všechny diagramy UML. Jako profesionální nástroj za odpovídající cenu umožňuje i další funkce mimo modelování. Účinně podporuje týmovou komunikaci a spolupráci, intuitivní uživatelské rozhraní a praktická integrace nástroje do ostatních vývojových aplikací například Microsoft Visio. [19] 23

25 6. Model Driven Architecture Model Driven Architecture byl založen jako standard organizací OMG (Object Management Group). Toto koncorcium se už několik let realizuje na trhu s objektovými informačními technologiemi, které se soustředí především na vytváření standardů zaručující interoperabilitu a portabilitu distribuovaných objektově-orientovaných aplikací. MDA bylo schváleno touto organizací jako standard v září V roce 2003 pak došlo k dalšímu upřesnění této architektury. MDA v dnešní době využívá, rozšiřuje a integruje většinu stávajících specifikací skupiny OMG. Jde zejména o UML (Unified Modeling Language),MOF (Meta-Object Facility), CWM(Common Warehouse Metamodel), XML (Extensible Markup Language), XMI (XML Metadata Interchange) a IDL (Interface Definition Language). [28] MDA se významně odlišuje od předchozích přístupů ve využití modelovacích jazyků jako je UML. Původně se využívaly hlavně pro jednodušší porozumění a komunikaci. Naproti tomu v MDA je modelovací jazyk klíčovou částí pro definici softwarového systému. Většina - v ideálním případě všechny - specifikací struktury a chování budoucího systému, která je uložena právě v modelu, je automaticky transformována do zdrojových kódů. Znalost platformy je zakódována do transformací, které mohou být takto použity pro více systémů. [29] Princip MDA je jednoduchý. Jak název napovídá, jedná se o Modelem řízenou architekturou, a proto se jedná o koncept standardizující modely, které jsou v průběhu vývoje aplikace vytvářeny a definují způsoby mapování mezi nimi. Základním principem MDA spočívá v oddělení business logiky od technologie platformy (subsystémy a technologie, které zajišťuje logickou sadu rozhraní a vzorů, které může aplikace využívat bez znalosti toho, na jaké platformě a jak je implementována.). Obrázek 18 - Grafické znázornění modelu MDA, zdroj: [31] 24

26 Tato schopnost, kterou MDA nabízí, se dá použít velmi výhodným způsobem, neboť aplikace vytvořené na základě MDA se mohou realizovat v mnoha webových platformách jako např. CORBA, J2EE nebo.net ad Modely MDA MDA definuje celkem 4 úrovně modelu: CIM (Computation Independent Model) model nezávislý na počítačovém zpracování PIM (Platform Independent Model) platformově nezávislý model PSM (Platform Specific Model) platformově specifický model Code Kód aplikace CIM Computation Independent Model Tento model definuje a modeluje firemní procesy a slovník pojmů dané oblasti. Notace modelu procesů není v UML nijak standardizována, přesto se doporučuje použít diagram aktivit. Pro slovník pojmů je vhodné použít konceptuální model tříd. Tento model se používá na začátku projektu podporovaného MDA a vytváří ho business analytici nebo doménoví experti či uživatelé PIM Platform Independen Model Tento model se soustředí na řešení problému dané oblasti na základě konkrétních požadavků. Model řeší koncepční otázky, ale již se nezabývá tím, jak bude řešení technologicky implementováno. Podstatou modelu je zařadit do něj co největší množství technologických faktorů architektonicky podstatných pro návrh systému, ale jsou platformově nezávislé. Pro tento model se nejčastěji používá diagram tříd, ale mohou se použít i ostatní diagramy UML, ovšem nesmí obsahovat platformově závislé prvky (např. diagram nasazení). Tento model vytváří IT analytici PSM Platform Specific Model Tento model se soustřeďuje na danou platformu. Je vytvářen na základě PIM, ale existuje zde možnost vytvořit ho i na základě PSM. Zároveň zde existuje situace, že pro jeden PIM existuje hned několik PSM. Nakonec je PSM model podkladem pro vlastní implementaci a má stejnou strukturu jako kód vyvíjené aplikace. Model PSM je nejčastěji spojován s diagramem tříd, ale stejně jako PIM může být prezentován dalšími diagramy jako např. diagram nasazení ad Code Také zdrojový kód aplikace je z pohledu MDA chápán jako model. Jde o model konkrétní realizace na dané platformě. [28] 6.2. Transformace mezi modely CIM, PIM, PSM a Code Výhodou právě modelu MDA je možnost transformace mezi jednotlivými druhy modelů (jejich způsob a postup). V těchto případech se postupuje dle standardizovaných postupů, tzv. použití návrhových vzorů (Design Patterns). [28] 25

27 Obrázek 19 - MDA workflow, zdroj: [30] CIM -> PIM transformace Jde o zcela manuální transformaci. Obvykle se v případech procesů a akcí uživatelů používá diagram Use Case (diagram případů užití), ale MDA se touto transformací nezabývá PSM -> Code transformace Pro tuto transformaci existuje několik možných nástrojů. Jelikož oba modely mají stejnou strukturu, umožňuje snadné automatizované generování. Problémem by se nemělo stát ani reverzivní transformace, která probíhá pomocí reverzního inženýrství a vizualizuje kód v modelech PIM -> PSM transformace Hlavní přínosem MDA je právě automatizovaná transformace mezi modely PIM a PSM. Specifikace MDA poté rozděluje tuto transformaci do následujících 4 kategorií: Návrhář může na základě prostudování PIM vytvořit manuálně platformově specifický model. Návrhář může po prostudování PIM použít ke zjednodušení práce s tvorbou PSM již vytvořené šablony. Pro PIM se použije určitý algoritmus, který vytvoří kostru PSM. Tuto kostru následně návrhář manuálně doplní. K doplnění tohoto modelu může použít šablony z předcházející kategorie. Použití algoritmu na kompletní PIM vytvoří kompletní PSM. Tento poslední postup je pro naplnění MDA vizí nejpřínosnější. 26

28 6.3. MDA nástroje Vývojové prostředí s podporou MDA by mělo umět rozlišovat 4 základní modely (CIM, PIM, PSM, Code). A dále by měl umět transformaci mezi těmito modely (alespoň mezi některými z nich). Můžeme je dělit dle několika způsobů [28]: Dělení 1: Dílčí o Jedná se o nástroje používající výstupy z modelovacích nástrojů UML ke generování kódu. Kompletní o Tyto nástroje se starají o vše od sběru požadavků až po vygenerování kódu. Dělení 2: Model-and-generate o Jedná se o nástroje, které z modelu generují zdrojové kódy. Ovšem většina z nástrojů, které nabízí dnešní trh, neumí generovat kompletní kód, který by šel bez modifikace kompilovat. Kód musí posléze doplnit vývojáři. Model-and-execute o Tyto nástroje používá Executable UML (xuml, xtuml). Tento nástroj umožní návrhářům spuštění a kontrolu modelu celého systému již v procesu návrhu Výčet MDA nástrojů Samozřejmě následující seznam neobsahuje plný výčet nástrojů podporující MDA, jedná se jen o náhodný výběr opensourcových, komerčních či českých nástrojů. OptimalJ Zástupce komerčního produktu. Zavádí model procesů založený na diagramu aktivit v jazyce UML 2.0. Podporuje vývojovou platformu Eclipse. AndroMDA Zástupce open-source produktů. Používá se v kombinaci s jinýminástroji (ArgoUML, MagicDraw, Maven). Umožňuje psát vlastní transformační MDA nástroje skripty i v Javě (včetně dalších jazyků používaných pro psaní transformací, např. QVT, ALT). Select Architect Produkt českého výrobce (firma LBMS s.r.o.). Vývojové prostředí Select je dodáváno s metodikou LBMS Development Method, která poskytuje konkrétní návod na postup vývoje a údržby vícevrstevných aplikací s využitím principů MDA. Podporu pro MDA zajišťuje modul Select Solution for MDA. Middlegen Zástupce open-source produktů. Používá databázově řízené generování kódu založené na JDBC, Antu, Velocity a XDocletu. Vývoj začíná vytvořením databáze a připojením Middlegenu k této databázi. Následuje přejmenování tabulek a sloupců, vyladění asociací a mapování. Pak je pomocí Middlegenu a XDocletu generován zdrojový kód a dodatečné soubory. 27

29 7. Metodiky řízení IS/ICT 7.1. CMMI (Capability Maturity Model Integration) Tato podkapitola čerpala ze zdroje [32] a [33]. CMMI je přístup k zlepšování procesů, který chce poskytnout společnostem základní prvky pro efektivní zlepšování procesů. Klade si za cíl zlepšit použitelnost modelů zralosti (maturity models) integrováním různých modelů do jednoho rámce (frameworku). CMMI je majetkem SEI (Software Engineering Institute) při Carnegie Mellon University v Pitsbourgu a hlavním sponzorem je americké ministerstvo obrany. Ačkoli bylo CMMI primárně určeno pro vývoj software, dá se použít i pro jiná odvětví, jako např. výroba elektroniky. Model CMM definuje pět úrovní zralosti procesů a na základě jejich definice identifikuje nejdůležitější oblasti pro zlepšení procesu, na které by se měla organizace zaměřit. Definuje oblasti procesu a cíle, které by měly být dosaženy tím, že říká, co by organizace měly dělat, neradí však již, jak by to měly dělat. CMM se řadí mezi globální metodiky a zaměřuje se na veškeré procesy v rámci celé organizace. [51] Nahrazuje i starší model CMM (Capability Maturity Model), který byl přejmenován na Software Engineering-CMM a používal se ještě do roku CMMI podobně jako CMM definuje několik úrovní zralostí: Počáteční (Initial): Týmy na této úrovni definované procesy nevykonávají nebo pouze částečně. Řízená (Managed): Je stanoveno řízení projektů a činnosti jsou plánovány Definovaná (Defined): Postupy jsou definovány, dokumentovány a řízeny Kvantitativně řízená (Quantitatively Managed): Produkty i procesy jsou řízené kvantitativně Optimalizující (Optimizing): Tým soustavně optimalizuje své činnosti 28

30 Obrázek 20 CMMI, zdroj: [23] CMMI vymezuje takzvané klíčové procesní oblasti (KPA), přiřazuje jim úroveň zralosti a rozděluje je do několika oblastí: Řízení procesů (Organizational Process Definition: 3, Organizational Process Focus: 3, Organizational Training: 3, Organizational Process Performance: 4, Organizational Innovation and Deployment: 5) Řízení projektů (Project Monitoring and Control: 2, Project Planning: 2, Supplier Agreement Management: 2, Integrated Project Management: 3, Risk Management: 3, Quantitative Project Management: 4) Engineering (Requirements Management: 2, Product Integration: 3, Requirements Development: 3, Technical Solution: 3, Validation: 3, Verification: 3) Podpora (Configuration Management: 2, Measurement and Analysis: 2, Process and Product Quality Assurance: 2, Decision Analysis and Resolution: 3, Causal Analysis and Resolution: 5) Nejlepší praktiky (best practices) CMMI se dělí do tří modelů: CMMI pro vývoj (CMMI-DEV) zabývá se procesy vývoje produktů a služeb. CMMI pro pořizování IT (CMMI-ACQ) zabývá se SCM (Supply Chain Management = řízení dodavatelských řetězců), pořizováním produktů a služeb nebo outsourcingem vývoje a podpory. CMMI pro služby (CMMI-SVC) zabývá se řízením dodávek služeb uvnitř organizace a externím zákazníkům. 29

31 7.2. Metodika Rational Unified Process Tato podkapitola čerpala ze zdroje [32] a [33]. Metodika Rational Unified Process (RUP) je softwarový inženýrský proces, který představuje disciplinovaný přístup přiřazující úkoly a odpovědnosti v organizaci zabývající se vývojem softwaru. Metodika Rational Unified Process vznikla spojením přístupu Rational a metodiky Objectory Process Ivara Jacobsona. Nejprve byla nazvána Rational Objectory Process a v roce 1998 pak byla doplněna a přejmenována na Rational Unified Process. Rational Unified Process je specializací obecnějšího procesu. [14] Charakteristika metodiky: Metodika Rational Unified Process je založena na tzv. nejlepších praktikách softwarového vývoje: iterativní vývoj, řízení požadavků použití komponentové architektury, vizuální modelování, kontrola kvality software, řízení změn. 30

32 Životní cyklus software je rozdělen na cykly. Předmětem každého cyklu je nová verze produktu. Jeden vývojový cyklus je v RUP rozdělen do 4 po sobě jdoucích fází: Počáteční fáze (Inception), Elaborační fáze (Elaboration), Konstrukční fáze (Construction), fáze Nasazení (Transition). Počáteční fáze je definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. Součástí této fáze může být vytvoření modelu nebo jednoduchého prototypu, na kterém se ověří, zda je možné se zvolenou technologií a pomocí zvolených nástrojů klíčové požadavky splnit. Počáteční fáze končí rozhodnutím, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu možné realizovat. Elaborační fáze má za cíl definovat architekturu systému. V této fázi by měl být vytvořen prototyp, který ověří všechny architektonické principy a umožní zpřesnění plánu realizace systému. Měly by být definovány komponenty, které je třeba vyvinout pro opakované použití. Konstrukční fáze je návrh a realizace systému včetně testování. Prosazuje se pokud možno paralelní vývoj. Fáze Nasazení zajišťuje, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help-desk atd. Každá fáze je uzavřena milníkem časovým okamžikem, ve kterém musí být splněny cíle fáze a dochází k rozhodování. Podstatným nedostatkem metodiky RUP je její zaměření pouze na úroveň projektu, nepostihuje tedy procesy a činnosti, které jdou za hranice jednoho projektu jako řízení portfolia projektů, vytváření globální architektury, znuvupoužitelnost na úrovni organizace a další. Metodika má poměrně malý rozsah, neboť se zaměřuje pouze na vývoj řešení, ne na jeho provoz a údržbu, a pouze na softwarově inženýrské role a dimenze. Silnou stránkou metodiky Rational Unified Process je její integrace s nástroji CASE firmy Rational, které podporují především oblast analýzy a návrhu, testování, konfigurační management a správu požadavků. Tato výhoda ale může být z hlediska otevřenosti a obecnosti povaţována na druhé straně za nevýhodu, neboť činí metodiku RUP závislou na vývojových nástrojích. V České republice je metodika RUP distribuována firmou Unicorn, která zajišťuje i školení a podporu. K nevýhodám metodiky RUP patří, že není lokalizována do češtiny, je velmi rozsáhlá a je poměrně drahá. Metodika Rational Unified Process je dodávána jako produkt. Jde o znalostní bázi s webovým rozhraním a sadu nástrojů na přizpůsobení procesu a šablon do nástrojů firmy Rational. V současné době se tvůrci metodiky RUP snaží o promítnutí některých myšlenek agilních metodik a odlehčeni metodiky RUP, ale stále je to těžká metodika. 31

33 8. Metodiky kontrolingu IS/ICT 8.1. ITIL Historie ITIL Tato podkapitola čerpala z [10] ITIL, neboli Information Technology Infrastructure Library je sadou dokumentů popisujících a udávajících směr infrastruktuře informačních technologií. Historie ITILu sahá do roku 1989 až 1995, kdy byl publikován pro HMSO (Her Majresty s Stationery Office) ve Velké Británii a to ve verzi 1. Původně ITIL ve verzi 1 tvořilo 31 publikací, které pokrývaly tehdejší otázku poskytování IT služeb, verze 2 pak, v letech 2000 až 2004, shrnula a revidovala tyto publikace do 7 knih obsahujících inovované poznatky verze 1. ITIL ve verzi 2 pak byl hojně akceptován a aplikován v mnoha zemích Evropy i světa. Následně byl ITIL v.2 vystřídán 5 svazky ITILu ve verzi 3, které pokrývají celý životní cyklus IT služeb. ITIL v.3 však nemění některé zásadní informace a postupy obsažené ve v ITIL obecně Jak již bylo výše nastíněno, ITIL představuje rámec, jenž popisuje tzv. best practices ve správě IS/ICT podniku. Hlavním přínosem knihovny ITIL je, že obsahuje výběr nejlepších osvědčených postupů, zásad, funkcí, procesů, rolí a aktivit, nezávisle na velikosti a typu podniku, pro který má být ITIL nasazen. Jeho principy je možné aplikovat pro všechny velikosti podniků ve všech odvětvích. Systém řízení IS/ICT společnosti založený na metodice ITIL zahrnuje řízení operativních, taktických i strategických aspektů ITSM (Inforomation Technology Services Management) procesů a klade důraz zejména na automatizaci a nástrojovou podporu těchto procesů Novinky v ITIL v.3 Současná verze ITIL přináší do systému řízením podnikového IS/ICT některé nové prvky. Těmito prvky můžeme vidět zejména: Řízení životního cyklu IT služby Řízení IT služeb z pohledu hodnoty pro zákazníka Odklon o striktně procesního řízení podnikového IS/ICT Hlavní myšlenkou těchto bodů je přesně identifikovat životní cyklus dané služby a také zjistit, co má služba zákazníkovi přinášet a podle toho uspokojovat i jeho potřeby a tím zajistit jeho příslušné výstupy. Toto je současně hlavní rozdíl mezi ITIL v.2 a v Obecné shrnutí ITIL v.3: Kompletně převzato z [10]: ITIL V3 nepopírá jediný aspekt systému řízení IT služeb vymezený předchozí verzí knihovny, ale přináší do celého systému principiálně nový prvek, jenž je založen na řízení hodnoty služby pro zákazníka, a to v jednotlivých fázích celého životního cyklu služby. Mnoho principů a zásad, které jsou popsány v ITIL V3, bylo přítomno i v ITIL V2, nicméně kontext, do kterého jsou tyto prvky zasazeny, je principiálně odlišný. Praxe ukazuje, že jakkoli důsledné soustředění na implementaci sofistikovaného procesně svázaného ICT prostředí, nad nímž jsou služby poskytovány (což je ústřední princip ITIL V2), nemusí přinést potřebnou hodnotu pro zákazníka, pokud se ztratí ze zřetele hlavní cíl, jímž je dodat zákazníkovi hodnotu, která mu umožní dosáhnout jím požadovaných výsledků bez toho, aby musel nést specifická rizika a náklady s tím spojené. 32

34 8.2. COBIT - Control Objective for Information and Related Technology Metodika COBIT byla vyvinuta jako celosvětově příjímaný standardní postup řízení, kontroly a auditu ICT. Jedná se o sadu best practices, které byly roku 1996 vytvořeny pro informační management organizacemi ISACA (Information Systems Audit and Control ASsociation) a ITGI (IT Governance Institute). COBIT představuje standard pro řízení informatiky a kontrolní nástroj pro auditory. Právě na cílech řízení tato metodika stojí, ale je dále rozšířena o mezinárodní technické, profesní, zákonné a specifické standardy jednotlivých odvětví. Jedná se o self-assesment nástroj, tzn., že výsledné cíle řízení ICT byly vyvinuty pro aplikaci v celopodnikových IS, jelikož je založen na bázi systémových procesů. Řízení ICT je tedy potom bráno jako konstruktivní a strukturované. Další metodikou, která se zabývá řízením ICT v podnicích je také ITIL (viz kapitola ITIL). Ten se od COBITu ale liší, jelikož je soupisem určitých stavů, ve kterých by se podnik a jejich IS/ICT měly nacházet. Dle COBITu jsou řízení a správa podniku, jako systém, kterým je organizace vedena a kontrolována (Enterprise Governance) a řízení a správa podnikové informatiky, jako systém, kterým je IT v organizaci vedeno a kontrolováno (IT Governance) vzájemně podmíněné systémy. [11] Páteř COBITu tvoří vzájemný vztah mezi následujícími složkami, které pokrývají celý princip metodiky: Základní IT procesy Plánování a organizace Akvizice a implementace Poskytování a podpora Monitorování IT zdroje Aplikace Informace Infrastruktura Lidské zdroje Informační kritéria Účelnost Hospodárnost Důvěryhodnost Integrita Dostupnost Souhlasnost/Shoda Spolehlivost 33

35 Obrázek 19 - Multidimenzionální kostka COBITu, zdroj: [15] COBIT pro jednotlivé oblasti definuje cíle řízení a procesy a zdroje přiřazené k procesům: [11] Cíle řízení definice požadavků ze strany businessuu strategický cíl ke každému procesu detailní cíle jednotlivých procesů Procesy Procesy tvoří velmi důležitou složku metodiky. Standard definuje 34 procesů seskupených do 4 následujících domén: Plánování a organizace Akvizice a implementace Poskytování a podpora Monitorování Pro každý z procesů jsou definovány: Obsah a cíl Dílčí kontrolní cíle Typické aktivity a role Vstupy a výstupy Kritéria pro model vyspělosti Způsob měření Způsob auditu 34

36 Obrázek 20 - vztah domén a procesů, zdroj: [13] Zdroje přiřazené k procesům Informace (datové objekty interní, externí atp.) Aplikační systémy (souhrn manuálních i automatizovaných procedur) Infrastruktura (HW, operační systémy, sítě, lokalizace a podpora informačních systémů) Lidé (znalosti, organizace, získávání, poskytování, podpora, monitoring a ohodnocení informačních systémů a služeb) 35