ICT firmy

Seminární práce

Použití CASE pro řízení IS/ICT firmy

Vypracovali: Jiří Beran Jakub Erlebach Jan Kapčiar Petr Pobuda Tomáš Šafařík Petr Šťastný Jan Zubíček Předmět:

4IT450 - CASE - Computer Aided Systems Engineering

Datum:

prosinec 2006

Obsah 1 Úvod.................................................................................................................................................3 1.1 Co jsou CASE nástroje.............................................................................................................3 1.2 Řízení IS/ICT............................................................................................................................3 2 Teoretická část..................................................................................................................................4 2.1 Definice řízení IS/ICT..............................................................................................................4 2.2 Proč řídit IS/ICT.......................................................................................................................4 2.3 Proč využívat CASE nástroje při řízení IS/ICT........................................................................5 2.4 Výsledný přínos pro organizaci................................................................................................6 3 Unified Modelling Language (UML)...............................................................................................7 3.1 Historie UML............................................................................................................................7 3.2 Způsoby použití UML..............................................................................................................7 3.3 UML jako programovací jazyk.................................................................................................8 3.4 UML v řízení IS/ICT................................................................................................................9 3.5 Softwarové produkty pro modelování v UML.......................................................................13 4 Rational Unified Process (RUP).....................................................................................................14 4.1 Šest nejlepších praktik............................................................................................................14 4.2 Základní model RUP..............................................................................................................17 4.3 Vývoj softwaru.......................................................................................................................18 5 Model Driven Architecture (MDA)................................................................................................21 5.1 Princip MDA...........................................................................................................................21 5.2 Standardy MDA......................................................................................................................21 5.3 Modely dle MDA....................................................................................................................21 5.4 Nač tolik modelů?...................................................................................................................23 5.5 Transformace – aneb snadno z modelu do modelu.................................................................23 5.6 K čemu tedy MDA slouží?......................................................................................................24 5.7 Silné stránky MDA.................................................................................................................24 5.8 CASE podporující MDA........................................................................................................25 6 Další přístupy k řízení IS/ICT........................................................................................................32 6.1 ITIL.........................................................................................................................................32 6.2 COBIT....................................................................................................................................33 6.3 Srovnání ITIL a COBIT..........................................................................................................36 7 Případová studie.............................................................................................................................37 7.1 Představení firmy....................................................................................................................37 7.2 Něco z historie........................................................................................................................37 7.3 Vývoj IS/ICT..........................................................................................................................38 7.4 Provoz IS/ICT.........................................................................................................................40 7.5 Řízení služeb IS/ICT...............................................................................................................40 7.6 Plánování projektu IS/ICT......................................................................................................40 7.7 Řízení ekonomiky IS/ICT a metrik.........................................................................................41 7.8 Řízení personálních a datových zdrojů...................................................................................41 7.9 Informační strategie................................................................................................................41 7.10 Bezpečnostní strategie a politika..........................................................................................41 7.11 Organizace řízení IS/ICT......................................................................................................41 7.12 Tvorba, správa a řízení dokumentace IS/ICT.......................................................................41 8 Závěr...............................................................................................................................................42 9 Zdroje.............................................................................................................................................43

1 Úvod Tato práce se zabývá možnostmi použití nástrojů CASE pro řízení IS/ICT firmy. Snaží se předložit teoretická východiska, jednotlivé způsoby a přístupy použití CASE pro takovýto účel. Dále také ukázat konkrétní nástroje a ukázku možného použití. Tato práce vychází, rozšiřuje a navazuje na seminární práci na toto téma z letního semestru roku 2006. Z původní práce byla převzata osnova. Obsah jednotlivých kapitol byl přepracován nebo doplněn tak, aby ukazoval více konkrétních příkladů i s použitím ilustrací a aby podrobněji rozepsal jednotlivé teorie, kterých CASE využívá. Kapitola 2 o teorii je převzata z minulé práce a na ní následně navazuje kapitola o UML, která ji vhodně rozšiřuje. Kapitola o MDA obsahuje také část práce převzaté z minulého semestru (podkapitoly 1 až 6). V původní práci z minulého semestru je velmi dobře uvedena charakteristika MDA, jaký je princip MDA a co je její podstatou. Bylo by tedy zbytečné kapitoly celé přepisovat a proto byly doplněny o obrázky, které podtrhují jejich přehlednost a pochopitelnost. Nyní předložíme rychlé shrnutí oblastí, které dále budou podrobně zpracovány v jednotlivých kapitolách.

1.1 Co jsou CASE nástroje Computer-aided software engineering (CASE) se obecně označuje použití softwarových nástrojů pro vývoj a údržbu. Původně pouze vývoj software, nyní i různé jiné oblasti, ve kterých je možné využít výhod jenž CASE nástroje přinášejí. Těmi jsou zejména: ●

generování kódu

●

datové modelování

●

refaktorace kódu

●

transformace modelů

●

správa konfigurací

●

a další

1.2 Řízení IS/ICT Pod pojmem řízení IS/ICT jsou následující činnosti: ●

strategické řízení

●

taktické řízení

●

operativní řízení

●

tvorba, správa a řízení dokumentace IS/ICT

Detailnější popis je možno najít v následující kapitole zabývající se teorií. CASE nástroje usnadňují práci na jednotlivých úrovních řízení ve firmě, neboť dokáží flexibilně reflektovat změny a potřeby podniku. Samozřejmostí jsou správně zvolené postupy, nástroje a jejich provázání. Při řízení IS/ICT ve firmě je možnost využití CASE nástrojů pro modelování jednotlivých procesů firmy, tvorby individuálního software pro firmu, který přesně reflektuje procesy firmy, nebo třeba „pouze“ správu hardware, software, konfigurace atd. Nedílnou součástí je správa a údržba dokumentace jednotlivých součástí (aplikací) IS/ICT ve firmě, udržování informací o jejich konfiguraci, datových rozhraních atd. V následujících kapitolách práce budou rozebrány jednotlivé v současnosti pro tyto účely používané nástroje, metodiky a konkrétní software. A předvedeny jejich praktické ukázky a ilustrace.

2 Teoretická část 2.1 Definice řízení IS/ICT Pod řízením IS a ICT budeme v rámci této práce považovat zejména následující činnosti:

2.1.1 Strategické řízení IS/ICT Oblast činností, které jsou realizovány především na úrovni managementu společnosti. Obvykle se jedná o soubor dokumentů, příp. vizí, který definuje 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

2.1.2 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ů

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

2.1.4 Tvorba, správa a řízení dokumentace IS a ICT Jako specifickou oblast, která se prolíná všemi jednotlivými typy a úrovněmi řízení pak považujeme dokumentaci všech aspektů IS/ICT a to zejména s důrazem na její tvorbu, správu, persistenci a dostupnost. Další text dokumentu je veden zejména s ohledem na uvedené typy řízení a to v kontextu, jak daný typ je (či není) podporován dostupnými CASE nástroji event. metodikami.

2.2 Proč řídit IS/ICT V současné době je činnost podniků stále více závislá na IS/ICT podniku. Jde tedy o podporu hlavních (core) podnikových procesů procesy informatiky podniku. Důsledkem tedy je, že flexibilita organizace je přímo závislá právě na flexibilitě podnikové informatiky. S rostoucím rozsahem IT podpory pro různé oblasti činnosti organizace zároveň roste množství vazeb a závislostí mezi jednotlivými částmi IS/ICT podniku. Současně neustále rostou požadavky uživatelů podnikových systémů na rychlost implementace změn a nové funkcionality. S přibývajícími změnami v informačních systémech roste komplexita těchto systémů. Postupem času se vedle sebe kupí mnoho dílčích částí informačního systému od různých dodavatelů. Čím větší je komplexita těchto systémů, tím náročnější je IS řídit a tím vyšší a hůře odhadnutelné jsou náklady na integraci jednotlivých částí do správně jednotně pracujícího systému, na údržbu IS

a na drobné změny za provozu. V důsledku komplexity se IS/ICT může snadno stát neovladatelným a nepředvídatelným systémem s fatálními riziky pro chod podniku. Takové změny a rozvoj informačních systémů je nutné nějakým způsobem řídit. Pokud rozvoj podnikových systémů není řízen, dochází k neustálému zvyšování nákladů na IS/ICT, neboť špatně řízené promítání změn do informačních systémů je ve výsledku velmi nákladné. 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 bohužel ukáže potřeba provést ještě další změny, na které se původně zapomnělo, což ve výsledku znamená další úsilí a další náklady.

2.3 Proč využívat CASE nástroje při řízení IS/ICT Spíše než proč využívat CASE nástroje při řízení IS/ICT by na úvod byla vhodnější otázka proč modelovat podnikové IS/ICT. Odpověď je nasnadě. Modelování IS nemá své opodstatnění pouze při vytváření a implementaci těchto systémů. Modely hrají důležitou roli i v případě řízení informatiky, tedy jejím provozu a rozvoji. Jak již bylo uvedeno výše, v dnešní době se díky vývoji IT technologií nesetkáme v případě rozsáhlejších IS se systémem, který by sestával pouze z jedné aplikace od jednoho dodavatele. Současné systémy v sobě zahrnují několik dílčích aplikací od různých dodavatelů, a tak je nutné toto nějakým způsobem řídit. Významným podkladem proto jsou modely informačních systémů. Důležitým faktorem, proč modelování využívat je také další rozvoj a změny IS. Abychom mohli mluvit o řízeném promítání změn do IS, musíme mít jasno, jaké jsou dopady těchto změn. Pokud však máme podnikové systémy "namodelovány" pouze v podobě zdrojového kódu, je taková analýza dopadů velmi obtížná a nespolehlivá. Protože 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í CASE nástrojů, 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 CASE nástrojích. Modelování IS může probíhat na různých úrovních detailnosti, přičemž úplně na vrchol bychom mohli postavit modelování procesů.

2.3.1 BPM (Bussines Process Modeling) Pro celkový pohled na podnikový IS z hlediska dynamiky slouží procesní model. V tomto modelu je především zachycena vazba mezi firemními procesy a aplikacemi, které je podporují. Většina změn v systémech je totiž vyvolána změnami firemních procesů, takže model procesů je výchozím místem zkoumání při analýze dopadů změn. Na základě tohoto modelu jsme tak schopni odvozovat, které systémy budou změnou ovlivněny a v jakém rozsahu.

2.3.2 Model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní Vzhledem k tomu, že většina podnikových systémů je složena z jednotlivých vzájemně provázaných aplikací od různých dodavatelů, jsou pro údržbu celého systému klíčovými informace o rozhraních aplikací. Základním modelem systému z hlediska jeho struktury je tedy model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní. Model rozhraní umožňuje provádět analýzu dopadů toho, jak změna jednoho systému ovlivní další systémy. Závislosti mezi aplikacemi podnikového IS jsou na tomto modelu zobecněním komunikace, která probíhá na úrovni rozhraní systémů.

2.3.3 Detailní modely aplikací Jednotlivé systémy je pak možné detailněji modelovat pomocí tradičních UML modelů, jako je

model tříd nebo model interakcí. Vytvoření a údržba těchto detailních modelů je samozřejmě podstatně nákladnější a vyplatí se u systémů, které jsou buď intenzivně rozvíjeny nebo při novém vývoji.

2.3.4 Dokumentace Dokumentace hraje důležitou roli již v procesu vývoje programového systému. Jednotlivé fáze vývoje je třeba dokumentovat a každá fáze má většinou definovány určité výstupní dokumenty (záleží na zvolené metodice vývoje IS). Díky dokumentaci tak máme dokonalý přehled o tom, kde, co a jak je implementováno. Právě zde se naskytuje možnost využití dokumentačních nástrojů zvoleného CASE nástroje. Jednou z hlavních předností modelování IS/ICT pomocí CASE nástrojů a jejich následného využití při řízení informatiky, je schopnost těchto nástrojů generovat a udržovat aktuální dokumentace systému, které jsou vždy (nebo by tomu tak alespoň mělo být) nedílnou součástí aplikací. Nejen že tyto systémy jsou schopné dokumentaci jednorázově vygenerovat, ale jsou ji rovněž schopny udržovat v aktuálním stavu dle provedených změn v modelech systému. Většina současných strukturovaných i objektově orientovaných CASE prostředků má v sobě totiž integrované prostředky pro tvorbu všech typů dokumentace vznikající v různých fázích životního cyklu. Nejedná se zpravidla jen o pouhý tisk diagramů vyskytujících se na obrazovce, nýbrž o dokonale hierarchicky zpracovanou dokumentaci ve formě přehledových sestav, detailních popisů entit, atributů, relačních a dědičných vztahů a toto vše teprve doplněno jednotlivými diagramy.

2.3.5 Model jako komunikační nástroj Protože na vývoji i na následném řízení IS pracuje několik lidí, jsou modely nezbytné i jako komunikační prostředek mezi nimi. Jednak jsou součástí finální dokumentace systému a jednak jsou přístupné pomocí CASE nástrojů. Celkový model podnikového IS je také velmi užitečným podkladem pro komunikaci s dodavateli jednotlivých aplikací při zadávání požadavků na funkcionalitu dodávaných aplikací.

2.3.6 Audit IS/IT CASE nástroje, potažmo dokumentace a vytvořené modely jsou také důležitým podkladem pro audit informačních systémů.

2.4 Výsledný přínos pro organizaci Nasazení systematičtějšího přístupu nastíněného výše, který je navíc podpořen nástrojem CASE usnadňujícím vytváření a údržbu příslušných modelů, vede zpravidla ke znatelným úsporám nákladů na rozvoj a údržbu podnikového IS/ICT. Tyto úspory jsou však nejen finančního charakteru, který vyplývá z toho, že změny se daří úspěšně realizovat na první pokus, ale i charakteru praktického, neboť používání CASE nástrojů a modelování všeobecně vede k přehlednosti a transparentnosti informačního systému.

3 Unified Modelling Language (UML) V této části bychom se rádi zabývali modelovacím jazykem UML. Tento grafický modelovací jazyk tvoří standardní nástroj pro specifikaci, vizualizaci, výstavbu a dokumentování částí softwarových systémů. Rozšíření jeho využití a také jeho zahrnutí do dalších metodik nás vede k tomu, věnovat mu alespoň základní popis jeho využití při řízení IS/ICT. Unified Modeling Language je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy.

3.1 Historie UML Vývoj UML začal v roce 1994, kdy Grady Booch a Jim Rumbaugh začali ve firmě Rational Software (nyní součást firmy IBM) spojovat své metodiky – Booch a OMT (Object Modeling Technique). Na konci roku 1995 do firmy Rational Software vstoupil Ivar Jacobson se svojí metodologii OOSE (Object-Oriented Software Engineering). Výsledkem jejich práce byl návrh UML (verze 0.9) a metodika RUP (Rational Unified Process – viz dále v textu). Standardizační organizace OMG v roce 1997 přijala jako standard UML verze 1.1 ve které byly začleněny prvky z dalších metodik (označení UML 1.0 se používá pro návrh, který poslala firma Rational Rose standardizační komisi). Postupně se upřesňovala specifikace a vznikaly další verze 1.2 (1998), 1.3 (1999), 1.4 (2001) a 1.5 (2002). Větší změny byly začleněny do verze 1.3. Od roku 2001 OMG připravuje verzi 2.0, která přináší podstatná rozšíření. Text první části (SuperStructure) byl schválen na podzim 2004, ale ještě není dokončena formální úprava dokumentu. Další části specifikace UML jsou připraveny k závěrečnému hlasování.

3.2 Způsoby použití UML 3.2.1 Kreslení konceptu Při tomto použití je UML podpůrným nástrojem pro komunikaci mezi vývojáři a pro zaznamenání myšlenek a návrhů. Do diagramů se kreslí pouze věci podstatné pro grafické vyjádření návrhu, části návrhu před tím, než se začne programovat. Důležitá je srozumitelnost, rychlost nakreslení a snadnost změny či navržení alternativ řešení.

3.2.2 Kreslení detailních návrhů Cílem je zaznamenat kompletní návrh či kompletní realizaci. Při kreslení návrhu by měl analytik obsáhnout všechny prvky tak, aby programátor byl schopen vytvořit program bez velkého přemýšlení nad věcnou oblastí (pro programátora by neměla vzniknout potřeba konzultace s uživatelem). Při kreslení detailních návrhů se obvykle používají specializované programy (CASE), které jsou schopny sdílet informace mezi jednotlivými modely a kontrolovat konzistenci návrhu. Při dokumentaci programu se často používání nástroje pro generování diagramů z vlastního kódu aplikace.

3.3 UML jako programovací jazyk Při tomto použití vývojář nakreslí UML diagramy, ze kterých se vygeneruje přímo spustitelný kód. Toto vyžaduje specializované nástroje a velmi přesné vyjadřování v UML diagramech. V této souvislosti se velmi často používá pojem Model Driven Architecture (MDA), což je další standard skupiny OMG, který se snaží standardizovat použití UML jako programovacího jazyka.

3.3.1 Metamodel Tento pohled používají autoři UML a autoři CASE nástrojů - nedívají se na UML jako na diagramy, pro ně je základem UML metamodel (diagramy jsou pouze grafickou reprezentací metamodelu). Při tomto přístupu se často používá pojem model místo pojmu diagram, např. místo diagramu tříd se používá pojem model tříd. Metamodel se popisuje pomocí Meta-Object-Facility (MOF) abstraktního jazyka pro specifikaci, vytváření a správu metamodelů (další standard OMG). Pro výměnu metamodelů se používá XMI - na XML založený standard (součást standardu UML).

3.3.2 Diagramy

Diagramy jsou nejznámější a nejpoužívanější částí standardu. Následuje přehled diagramů v UML 2.0 včetně jejich rozčlenění do skupin: Strukturní diagramy: ● diagram tříd (class diagram) ● diagram komponent (component diagram) ● composite structure diagram ● diagram nasazení (deployment diagram) ● diagram balíčků (package diagram) ● diagram objektů (object diagram), též se nazývá diagram instancí Diagramy chování: ● diagram aktivit (activity diagram) ● diagram užití (use case diagram) ● stavový diagram (state machine diagram) ● diagramy interakce:

● ● ● ●

sekvenční diagram (sequence diagram) diagram komunikace (communication diagram, dříve collaboration diagram) interaction overview diagram diagram časování (timing diagram)

Standard UML ve verzi 2.0 se skládá ze čtyř částí: UML 2.0 SuperStructure – popis UML z hlediska uživatele (analytik/programátor). Tato část popisuje jednotlivé diagramy. UML 2.0 Infrastructure – metamodel stojící v pozadí za UML, specifikovaný pomocí Meta-Object Facility (MOF). UML 2.0 Object Constraint Language (OCL) – jazyk pro specifikaci vstupních a výstupních podmínek, invariantů v jednotlivých diagramech. UML 2.0 Diagram Interchange – popis XML struktur pro výměnu konkrétních modelů mezi jednotlivými modelovacími nástroji.

3.4 UML v řízení IS/ICT V následující sekci se zaměříme na popis využití jazyka UML při řízení IS/ICT v podniku, především pak na představení jednotlivých diagramů. Přestože by tato sekce mohla popisovat všechny aspekty jazyka UML, včetně jeho využití při vývoji nových aplikací, zaměříme se spíše na ty aspekty tohoto modelovacího jazyka, které je možné využít při řízení IS/ICT ve své celistvosti, na určité globálnější úrovni. Zájemce o využití jazyka pro samostatný vývoj software odkážeme na práce zabývající se právě touto činností. Během popisu se zaměříme na aktuální verze (2.x) jazyka s vyznačením důležitých rozdílů oproti starším verzím (řady 1.x).

3.4.1 Strukturální diagramy Strukturální diagramy se logicky zabývají strukturou modelovaného objektu. Zaměřují se tedy na statické vztahy mezi jednotlivými entitami v modelovaném objektu. Z výčtu obsaženého v předchozí části se zaměříme především na tyto diagramy: ● ● ●

diagram komponent (component diagram) diagram nasazení (deployment diagram) diagram balíků (package diagram)

Diagram komponent Zatímco v UML 1.x byl komponentový diagram využíván především ve fázi implementace je v UML verze 2.0 a výše kladen důraz především na využití komponentového diagramu ve fázi modelování. Tento diagram slouží pro zachycení komponent v systému, tedy autonomních prvků, které spolu komunikují pouze pomocí svých pevně definovaných rozhraní. Tato autonomita dělá z diagramu komponent vhodný prvek pro spolupráci mezi různými týmy. Přestože hlavní význam má diagram stále pro implementátory systému, kterým usnadňuje koordinaci práce, zůstává jeho důležitost pro všechny zainteresované skupiny v celistvém pochopení kompletního systému IS/ICT a jeho organizace.

Ilustrace 1: Diagram komponent (zdroj: http://www.agilemodeling.com/artifacts/componentDiagram.htm)

Diagram nasazení Diagram nasazení slouží k zachycení statického zobrazení systémové implementace – zobrazuje hardware, vyskytující se v systému, jaké softwarové komponenty na něm běží a v neposlední řadě vztahy mezi těmito prvky. Jak v UML1, tak v UML2 jsou hlavními prvky uzly, představující hardware. Avšak zatímco v UML1 jsou softwarové komponenty zakreslovány přímo do uzlů, používá UML2 navíc podřazené uzly a artefakty, které sdružují jednotlivé komponenty a představují běhové prostředí, ve kterém tyto komponenty běží (J2EE server atp.). Jak vidno, poskytují diagramy nasazení vhodný prostředek pro zachycení celkového stavu IS/ICT, jeho řízení a také řízení změn a vývoje.

Ilustrace 2: Diagram nasazení (zdroj: http://en.wikipedia.org/wiki/Image:UML_Deployment_Diag ram.gif)

Diagram balíků Diagramy balíků slouží k popisu toho, jakým způsobem jsou systémy rozděleny a organizovány do balíků vzájemně souvisejících komponent a k zachycení vztahů mezi těmito skupinami. Nejběžnější použití slouží k organizaci jednotlivých diagramů tříd či diagramů užití, z našeho pohledu je však důležitější možnost tento druh diagramu použít k abstraktnímu rozdělení systému na vzájemně co nejméně závislé, ale vnitřně co nejvíce soudržné balíky, a na základě tohoto usnadnit řízení a rozdělení zodpovědnosti za jednotlivé balíky.

Ilustrace 3: Diagram balíků (zdroj: http://en.wikipedia.org/wiki/Image:Package_diagram.jpg)

3.4.2 Diagramy chování Zatímco první popisovaná skupina diagramů se zaměřovala na statický popis systému, zaměřují se diagramy chování dynamiku systému – na to, co se v systému děje. Tato skupina obsahuje tři druhy diagramů, ze kterých se budeme věnovat těmto:: ● ● ●

diagram aktivit (activity diagram) diagram užití (use case diagram) diagramy interakcí

Diagram aktivit Diagram aktivit umožňuje zachytit pracovní postupy jako sled kroků vyvolaných určitou podmínkou a vedoucích k určitému cíli (cílům, případně žádnému cíli). Jde jim tedy o zobrazení business procesu případně pracovního postupu. Verze UML2 přinesla diagramům aktivit několik novinek: Především jde o větší možnosti v oddělení, popisu a hierarchického řazení jednotlivých oddílů diagramu.

Ilustrace 4: Diagram aktivit (zdroj: http://zubicek.eu/skola/novinky-ve-specifikaci-uml2/)

Diagram užití Diagramy užití identifikuje systém jako souhrn elementů – aktorů a procesů. Procesy jsou zde nazývány užití (use case). Zatímco tedy předchozí model popisoval samotné business procesy, tento diagram zachycuje systém těchto procesů a zároveň role, které v systému vystupují. Diagramy užití jsou vhodným prostředkem pro modelování systému během setkání s uživateli. Kromě toho také umožňují vytváření testů modelu. V každém případě jsou dobrým způsobem, jak zachytit procesy ve firmě jako východisko pro modelování IS/ICT. Ilustrace 5: Diagram užití (zdroj:

http://en.wikipedia.org/wiki/Image:Restaurant-UML-UC.png)

Diagramy interakcí Diagramy interakcí jsou podskupinou diagramů chování, zaměřují se na komunikaci mezi prvky systému a také na to, jakým způsobem je předáváno řízení systému. Z našeho pohledu asi nejdůležitějším diagramem z této skupiny je sekvenční diagram. Tento diagram umožňuje zachycení procesů (přičemž souběžné procesy jsou zakresleny na vertikále) a výměnu informací mezi nimi (jako horizontální čáry). Jejich použití se týká modelování, analýzy a dokumentování následujících aspektů našeho systému: ● ● ●

scénáře užití – jakými způsoby může být náš systém užíván funkční logika systému popis služeb systému

Obohacením sekvenčního diagramu, které přineslo UML2, je možnost zaznamenat varianty procesu.

Ilustrace 6: Variace v sekvenčním diagramu (zdroj: http://zubicek.eu/skola/novinky-ve-specifikaci-uml2/)

3.5 Softwarové produkty pro modelování v UML Vzhledem k tomu, že UML je standardizovaný jazyk, nejsou tvůrci modelovacích nástrojů nijak omezováni v jeho implementaci. Proto je na trhu k dispozici velké množství produktů. Mnohé jsou dokonce zdarma či spadají do oblasti open-source software. U software pro modelování v UML je možné v poslední době zaznamenat příklon k využití programovacího IDE frameworku nadace Eclipse (jejími členy jsou např. IBM, Borland, Google...). Framework Eclipse využívají například nástroje Apollo for Eclipse, Borland Together nebo Rational Software Architect. Z open-source projektů můžeme jmenovat například nástroje Dia a Umbrello UML Modeller. Další komerční produkty zahrnují mimo jiné Poseidon for UML, Microsoft Visio či Sparx Enterprise Architect.

4 Rational Unified Process (RUP) Rational Unified Process je metodika pro vývoj softwarových řešení a projektů vytvořená společností Rational Software Inc. Podnětem pro vznik této metodiky byla neuspokojivá bilance úspěšností softwarových projektů. Metodika je založena na rozsáhlých praktických poznatcích – byly prozkoumány a zevrubně zanalyzovány tisíce projektů renomovaných firem. Na základě výsledků analýz, zaměřených zejména na nalezení příčin neúspěšnosti zkoumaných projektů. Byly identifikovány postupy a opatření umožňující efektivně tyto příčiny eliminovat nebo alespoň omezit jejich dopad. Tato opatření byla shrnuta do šesti ucelených souborů doporučení, které se nazývají „Nejlepší praktiky softwarového vývoje“. RUP zahrnuje zapracování šesti nejlepších praktik do konkrétních návodů a postupů. Metodika jako taková pokrývá globálně proces softwarového vývoje a současně poskytuje návody a doporučení na detailní úrovni. Při zpracování a pro implementaci metodických postupů uživateli poskytuje i odpovídající konstrukce vycházející ze standardního jazyka pro modelování Unified Modelling Language (UML). RUP je ve své obecnosti a úplnosti ideální pro malé i velké organizace, především pro ty, které nemají zavedeny standardní mechanismy procesu vývoje. Čtyři základní role RUPu: ● Poskytuje návod k činnosti pracovního týmu ● Určuje, které artefakty a kdy mají být vytvořeny ● Slouží k řízení úkolů jednotlivců i týmu jako celku ● Nabízí kritéria pro monitorování a hodnocení činností a výsledků projektu

4.1 Šest nejlepších praktik Selhání při nasazení informačních technologií má mnoho příčin. Může to být špatné pochopení potřeb uživatelů, neschopnost vypořádat se s měnícími se požadavky, nekompatibilita modulů nebo náročná podpora a rozšiřování informačního systému. Mezi další příčiny patří pozdní rozpoznání chyb projektu, nízká kvalita a nepřijatelný výkon, nedostatečné řízení změn (informace nejsou zpětně dohledatelné) nebo nespolehlivý proces zavedení systému do provozu. Časté příčiny problémů: ● Nedokonalá správa požadavků a nejasná komunikace ● Křehkost a složitost architektury ● Neadekvátní testování ● Nepředcházení rizikům ● Nekontrolovatelné provádění změn ● Nedostatečná automatizace Většina softwarových projektů, vyvíjených na celém světě, nekončí úspěšně. Projekty jsou buď předčasně zastaveny, je přečerpán stanovený rozpočet, nejsou dodrženy termíny nasazení nebo výsledný informační systém nesplňuje požadavky zadavatele. Proto byl definován soubor principů, metod a procesů, které zvyšují kvalitu a produktivitu softwarového vývoje a zásadním způsobem ovlivňují úspěšnost projektu. Jsou to následující praktiky : ● ● ● ● ● ●

Iterativní vývoj Správa požadavků Komponentová architektura Vizuální modelování Ověřování kvality Řízení změn

4.1.1 Iterativní vývoj Při vývoji velkých informačních systémů často narážíme na problémy způsobené neadekvátní délkou projektu. Značná část chyb je odhalena až v poslední fázi projektu (při nasazování systému), kdy je už většina finančních prostředků vyčerpána. Naproti tomu iterativní vývoj pomáhá identifikovat rizika v každém stádiu životního cyklu, a tím značně snižuje náklady na jejich odstranění. Celý proces je rozdělen do několika iterací, kdy každá z nich končí spustitelnou verzí. Výhody iterativního vývoje: ● Koncentrace na klíčové problémy ● Průběžné odstraňování chyb ● Možnost objektivního posouzení aktuálního stavu projektu ● Včasné odhalení nesrovnalostí mezi požadavky, návrhem a implementací ● Pracovní zatížení je rovnoměrné ● Možnost testování meziverzí, zpětná vazba od uživatelů

Obrázek 1 - Vodopádový životní cyklus projektu

Iterativní vývoj je následně detailně rozebrán v kapitole „Vývoj Softwaru“.

4.1.2 Správa požadavků Požadavek je podmínka nebo schopnost, kterou musí systém splňovat. Standardně se předpokládá, že na začátku vývoje jsou posbírány všechny požadavky, které jsou poté vyhodnoceny a zapracovány do projektové dokumentace. Další změna požadavků se zpravidla nepřipouští. Takový přístup neodráží chování reálného světa a bývá příčinou špatného hodnocení celého projektu. Proto je nutné hledat postupy, které umožní řídit změny požadavků v průběhu vývoje softwaru. Správa požadavků zahrnuje: ● Zjištění požadované funkčnosti a omezení systému ● Zpracování detailní dokumentace ● Vyhodnocování změn požadavků a jejich důsledků

●

Dokumentace jednotlivých rozhodnutí

4.1.3 Komponentová architektura Vytvoření pružné architektury je důležité především z hlediska jasného rozdělení úkolů mezi jednotlivé týmy. Spolu s iterativním vývojem softwaru přispívá komponentová architektura k postupné tvorbě systémové architektury. Tento přístup pak usnadňuje identifikaci rizik a jejich odstranění již v samotném procesu vývoje. Přínosy: ● Podpora vývoje založeného na komponentách ● Systematický přístup k definování architektury ● Podpora standardních komponentových infrastruktur (CORBA, COM)

4.1.4 Vizuální modelování Model je kompletní popis systému z určitého pohledu. Modelování pomáhá zpřehlednit, specifikovat, zkonstruovat a z dokumentovat strukturu a chování systémové architektury. K jednomu systému vytváříme zpravidla více modelů. Díky standardnímu modelovacímu jazyku, jako je například UML, mohou jednotliví členové týmů mezi sebou srozumitelně komunikovat a předávat si informace bez ohledu na fázi vývoje. Výhody: ● Zachovává strukturu a chování architektury a komponent ● Ukazuje, zda jsou jednotlivé prvky kompatibilní ● Skrývá nebo odkrývá detaily podle potřeby ● Podporuje konzistenci mezi návrhem a implementací

4.1.5 Ověřování kvality Po dodání softwaru je velmi obtížné a nákladné opravit dodatečně nalezenou chybu. Proto je důležité nepřetržitě hlídat kvalitu produktu, a to s ohledem na jeho funkčnost, spolehlivost, výkon aplikace a celého systému. Při kontrole kvality jsou odhaleny nesoulady mezi požadavky, návrhem a implementací. Testování a kontrola se zaměřují na oblasti s nejvyšším rizikem, což zvyšuje jejich kvalitu a efektivitu. Chyby jsou odhalovány dříve, což snižuje náklady na jejich odstranění.

Obrázek 2 - Náklady na odstranění chyb v čase

Přínosy: ● Hodnocení kvality je zabudováno do procesu, do každé činnosti ● Používá objektivní míry a kritéria ● Objektivně hodnotí stav pomocí výsledků testování

4.1.6 Řízení změn Klíčovým úkolem při vývoji softwaru je dosáhnout efektivní koordinace všech aktivit a artefaktů tak, aby bylo možné opakovaně využívat standardní pracovní metody a reagovat na změny. Tím dosáhnout lepší alokace zdrojů. Práce je řízena dle priorit a rizik. RUP popisuje jak kontrolovat, sledovat a monitorovat změny a umožnit úspěšný iterativní vývoj. Řeší také paralelní vývoj různých verzí softwaru a správu buildů. Výhody: ● Postup řešení požadavků na změny je definovaný a opakovatelný ● Požadavky na změny zajišťují bezproblémovou komunikaci ● Vhodná metrika pro objektivní posouzení stavu projektu ● Změny jsou prováděny kontrolovatelně

4.2 Základní model RUP RUP definuje kdo, jak, kdy a co dělá. K tomu používá čtyři základní prvky: ● Osoby ● Aktivity ● Artefakty ● Pracovní postupy Mezi prvky existují tyto základní vztahy ● Osoba definuje chování a odpovědnost jednotlivce nebo týmu ● Chování je vyjádřeno aktivitou, kterou osoba vykonává. Každá osoba je spojena se souborem aktivit. ● Odpovědnost každé osoby je vyjádřena ve spojení s artefaktem, který osoba vytváří, upravuje nebo kontroluje.

4.2.1 Osoba Osobu si můžeme představit jako roli v divadelní hře. Jeden člověk může hrát ve více rolích a naopak do jedné role může být obsazeno více lidí. Tato odlišnost je důležitá, protože je přirozené myslet osobou jednotlivce nebo tým. V RUPu osoba definuje, jak má jednotlivec (který je do ní obsazen) dělat svojí práci a jakých artefaktů je vlastníkem. Toto rozdělení má na starosti projektový manažer, který plánuje projekty a jejich personální obsazení. Příklad: Systémový analytik (řídí a koordinuje proces zpracování požadavků), Návrhář (vytváří model tříd a určuje, jak mají být zakomponovány do implementačního prostředí)

4.2.2 Aktivita Aktivita je jednotka práce, která může být osobě přidělena. Aktivita má jasný cíl, většinou se jedná o tvorbu nebo správu artefaktů. Každá aktivita je přidělena specifické osobě. Aktivita musí být použitelná jako prvek plánování. Pokud je příliš malá, může být opomenuta a pokud je naopak příliš velká, lze pokrok vyjádřit po částech aktivity. V objektově orientované terminologii je osoba aktivní objekt. Aktivity, které osoba vykonává, jsou pak operace vykonávané tímto objektem. Příklad: Plánování vývojové iterace (provádí projektový manažer), nalezení případů užití (systémový analytik)

4.2.3 Artefakt Artefakt představuje informaci, která je vytvořena, modifikována a používána v procesu vývoje. Je hmatatelným výsledkem projektu. Artefakty jsou používány jako vstup pro vykonávání aktivity určitou osobou a jsou cílem nebo výstupem takovéto aktivity. Artefakty nemusí být vždy dokumenty. Efektivnější je tvorba artefaktů vhodnými nástroji. Pokud je to nutné, lze dokumenty generovat pomocí těchto nástrojů. Takovéto dokumenty jsou pak založeny na aktuální verzi artefaktů.

Příklad: model případu užití, plán projektu, zdrojový kód. Spustitelný program, databáze požadavků

4.2.4 Pracovní postupy Pouhý výčet všech osob, aktivit a artefaktů ještě nevytváří proces. Je třeba najít způsob, jak popsat posloupnost aktivit, které produkují hodnotné výsledky a ukazují interakce mezi osobami. Pracovní postup je posloupnost aktivit, které přinášejí předem definované výstupy. Často není možné znázornit všechny závislosti mezi aktivitami, zvláště jsou-li velmi úzce propojeny a týkají-li se stejné osoby či jednotlivce. Postupy týkající se následného odvozování jednotlivých artefaktů můžeme pak popsat v detailu pracovního postupu. Příklad : Analýza architektury (Architekt) -> Analýza případu užití (Business Analytik) -> Analýza objektů (Návrhář) -> Revize analýzy (Revizor návrhů)

Obrázek 3 - Příklad pracovního postupu

4.3 Vývoj softwaru Iterativní vývoj softwaru vychází z dnes běžně používaného sekvenčního procesu vývoje (tzv. vodopád). Ten funguje u malých projektů, ale způsobuje problémy u rozsáhlých řešení. Proto úlohu poněkud upravíme. Velký projekt rozdělíme na řadu malých částí (vodopádů). V každé fázi nejdříve získáme požadavky, vytipujeme rizika, navrhneme řešení, adekvátní část implementujeme a ověříme. Poté zapracujeme další požadavky, navrhneme rozšíření, zapracujeme jej a opět ověříme. To je podstata iterativního vývoje. RUP předpokládá 4 základní fáze, každá z nich je ukončena milníkem, tj. okamžikem, kdy rozhodujeme, zda ve vývoji pokračovat, změnit postup nebo jej ukončit. Fáze a jejich milníky: ● Počáteční fáze (milník: rozsah systému) ● Elaborace (milník: architektura systému) ● Konstrukce (milník: beta verze systému) ● Zavedení (milník: nasazení produktu)

4.3.1 Počáteční fáze V této fázi je založen obchodní případ a určen rozsah projektu. Je nutno identifikovat prvky, s nimiž bude systém komunikovat a definovat povahu těchto prvků, což znamená identifikovat všechny

případy užití a popsat několik nejvýznamnějších z nich. To vše se děje na základě vyhodnocování požadavků a omezení systému, stanovení kritérií, která systém musí splňovat, zvážení možných alternativ v poměru cena/termín/výkon, definování použitelných architektur a komponent a rozhodnutí, co se vyrobí/koupí/znovu použije. Výstupem této fáze je: ● Vize, tj. dokument obsahující vizi klíčových požadavků projektu, jeho hlavní rysy a omezení ● Model případů užití ● Počáteční obchodní případ (finanční rozpočet, kritéria úspěchu…) ● Počáteční ohodnocení rizik ● Plán projektu Na konci počáteční fáze se objevuje první milník projektu: Rozsah systému. Jeho smyslem je navodit konsenzus mezi osobami zodpovědnými za realizaci projektu a objektivně prokázat, že projekt je realizovatelný v navržené kvalitě, kvantitě, termínu a rozpočtu.

4.3.2 Elaborační fáze Cílem této fáze je analyzovat klíčové problémy, vyvinout základy architektury, vytvořit plán projektu a odhadnout nejrizikovější prvky projektu. Součástí elaborace je navržení funkčního prototypu architektury. Toto úsilí by se mělo zaměřit především na kritické případy užití, identifikované v počáteční fázi, které typicky zahrnují hlavní technická rizika projektu. Dá se říci, že tato fáze je nejrizikovější ze všech čtyř fází. Na jejím konci nastává důležitý okamžik, kdy se rozhodne o pokračování projektu. Výstupem této fáze je: ● Model případu užití ● Dodatečné požadavky ● Popis softwarové architektury ● Spustitelný prototyp architektury ● Revidovaný seznam rizik a revidovaný obchodní plán ● Vývojový plán pro celý projekt (včetně hrubého plánu s iteracemi a hodnotícími kritérii pro každou iteraci) ● Aktualizovaný vývojový případ s popisem procesu, který se má použít ● Předběžný uživatelský manuál V tomto dalším důležitém okamžiku se prověřují detailní vlastnosti systému a jeho rozsah. Klíčovými úkoly jsou výběr architektury a odstranění hlavních rizik vyřešením technologických problémů nebo zvolením alternativních postupů.

4.3.3 Konstrukční fáze Během této fáze jsou navrženy všechny zbývající komponenty a vlastnosti aplikace, jsou vyvinuty a integrovány do produktu. Všechny vlastnosti systému jsou důkladně otestovány. Konstrukční fáze je výrobním procesem, v němž se klade důraz na řízení zdrojů a kontrolu kvality, kvantity, termínu a rozpočtu. Jednou z nejdůležitějších kvalit architektury je jednoduchost její konstrukce, proto je vyzdvihován vyvážený vývoj architektury a plánu během elaborační fáze. Výstup z konstrukční fáze je připraven k předání koncovým uživatelům. Výstupem této fáze je: ● Softwarový produkt integrovaný na odpovídajících platformách ● Uživatelský manuál ● Popis současné verze Na konci konstrukční fáze je třetí milník projektu: Beta verze. V tomto okamžiku prověřujeme, zda software, provozní prostředí a uživatelé jsou připraveni k nasazení systému do provozu, aniž bychom zúčastněné strany vystavovali velkým rizikům. V případě, že se nepodaří dosáhnout tohoto

milníku, musí být zavedení odloženo a je naplánována náhradní verze, která odstraní rizika nasazení systému do provozu, případně musí být upraven plán nasazení.

4.3.4 Nasazení Tato fáze se zaměřuje na činnosti potřebné k předávání softwaru do provozního prostředí. Zpravidla zahrnuje několik iterací (třeba akceptační testy, pilotní provoz atp.) včetně servisních buildů, patchů či hotfixů řešících nalezené chyby. Velké úsilí je vynaloženo na přípravu uživatelské a servisní dokumentace, školení uživatelů a podporu uživatelů. Tato fáze zahrnuje: ● Beta testování a pilotní provoz ● Paralelní nasazení společně s nahrazovaným systémem ● Konverzi operačních databází ● Školení administrátorů a správců, případně též uživatelů ● Předání systému do rutinního provozu V tomto okamžiku se rozhodne, zda byly dosaženy stanovené cíle a zda je možno začít práci na jiném vývojovém cyklu. V některých případech se tento milník kryje s ukončením počáteční fáze dalšího cyklu. Důležitá je správná funkčnost komunikačního kanálu mezi servisním týmem a koncovými uživateli. Do servisního týmu je vhodné zařadit několik lidí z vývoje. Ti zaškolí ostatní a poté se mohou vrátit zpět do realizace.

5 Model Driven Architecture (MDA) Model Driven Architecture byla zveřejněna v roce 2001 a již nyní získala velký vliv na metody vývoje aplikací. V současné době existuje přinejmenším 40 nástrojů, které podporují alespoň jeden z hlavních aspektů MDA. Jedná se o koncept standardizující modely, které jsou v průběhu vývoje aplikace vytvářeny a definující způsoby mapování mezi nimi. Proto také název, který by se dal přeložit jako „Modelem řízená architektura“, zkráceně MDA. MDA není ve své podstatě převratnou novinkou, nakonec otázkou členění modelů se zabývá každý rozumná metodika softwarového vývoje, nicméně podstatné je to, že toto členění standardizuje a dále definuje způsob transformace jednoho modelu v druhý. Koncept MDA sice úzce souvisí s UML, avšak není na tento modelovací standard bezprostředně vázaný, neboť se dá aplikovat i jiným způsobem modelování než je UML.

5.1 Princip MDA Princip MDA je velmi jednoduchý, spočívá v oddělení business logiky od technologie platformy. Platformou se rozumí sada subsystémů nebo technologií, které zajišťují logickou sadu rozhraní a vzorů, které může jakákoliv aplikace využívat bez potřeby vědět, jak je která funkce, poskytována platformou, implementována. Toto umožňuje realizovat aplikace vytvořené pomocí MDA v celé řadě otevřených platforem jako např. CORBA, J2EE, .NET a jiných webových platformách. Nezávislost na platformě nabývá významu tím více, čím rychleji jsou vytvářena nové a nové technologie.

5.2 Standardy MDA Technologický základ MDA zahrnuje souhrn metodik, které umožnily modely řízený přístup. Mezi tyto metodiky patří UML, MOF, specifické modely a UML profily (např. EDOC) Všechny UML specifikace jsou dostupné na http://www.omg.org/technology/documents/index.htm. UML (Unified Modeling Language) je standardním modelovacím jazykem pro vizualizaci, specifikaci a dokumentaci softwarových systémů. UML 2 integruje sadu komponent pro kompletní specifikaci chování objektů (http://doc.omg.org/formal/03-03-0). MOF (Meta-Object Facility) technologie nabízí repozitory modelů, které mohou být využity pro specifikaci a tvorbě modelů, též k zajištění konzistence ve všech fázích MDA využití (http://doc.omg.org/formal/02-04-03). Profily UML jsou rozšířeními UML nitifikace. Vznikají přidáním nových druhů elementů jazyka za účelem určité restrikce či specifikace. Jakýkoliv model vytvořený v UML profilu je stále UML modelem. Přitom jej lze transformovat do UML.

5.3 Modely dle MDA MDA vidí modely aplikací ve čtyřech úrovních: ● CIM – model nezávislý na počítačovém zpracování ● PIM – platformově nezávislý model řešení ● PSM – platformově specifický model řešení ● Code – kód aplikace, tj. výsledná realizace řešení

5.3.1 CIM – Computation Independent Model Model nezávislý na počítačovém zpracování je de facto modelem vlastního „businessu“, čili činností, které musí vykonávat pracovníci firmy aby tato mohla fungovat. Model CIM tedy znázorňuje tyto činnosti a obvykle se také nazývá model firemních procesů. Celkem pikantní je, že notace modelu CIM není v UML plně standardizována (a to ani v chystané verzi UML 2.0). Tento model vytvářejí buď sami uživatelé nebo business analytici. Model CIM je při vývoji a údržbě důležitý především pro to, aby vývojáři pochopili činnosti uživatele a chápali příslušné souvislosti. Navíc je to jediný model, který lze bez obav předložit

běžnému uživateli a ten je schopen ho po krátkém vysvětlení pochopit a především se k němu vyjadřovat. Další modely totiž nejsou pro uživatele snadno pochopitelné a jsou určeny především vývojářům.

5.3.2 PIM – Platform Independent Model Platformově nezávislý model reprezentuje koncepci řešení dané problémové oblasti na základě konkrétních požadavků. Jeho hodnota je především ve vyřešení koncepčních otázek, jako jsou třeba algoritmy zaskladňování a vyskladňování v případě skladů, nebo způsob párování saldokontních položek v účetnictví. Tento model však neobsahuje informace spojené s konkrétní technologií realizace a vytvářejí ho IT analytici. Platformově nezávislý model umožňuje vyřešit určitou oblast na obecné úrovni a teprve pak zvažovat konkrétní technologii pro vlastní realizaci. Dalším důležitým aspektem pro vytváření PIM modelu je to, že je cca 3x jednodušší než model, který již specifické technologické informace obsahuje a tudíž se v tomto modelu snadno zorientuje analytik, který obvykle nemá (ani to není žádoucí) detailní technologické znalosti.

5.3.3 PSM – Platform Specific Model Model řešení na dané platformě (např. J2EE nebo C# a ASP.NET) je podkladem pro vlastní implementaci. Z hlediska vztahu ke kódu je důležité to, že PSM má stejnou strukturu jako kód aplikace. Tento model vytvářejí návrháři. Na následujícím obrázku je zachycena hierarchie jednotlivých modelů. Samozřejmě je možné zpětné generování na úrovňově jednodušší model. Viz dále. Obrázek 4: Hierarchie modelů

5.3.4 Code Z hlediska MDA je zdrojový kód chápán také jako model konkrétní realizace na dané platformě. Konec konců určitě znáte ze svého okolí aplikace, kde jedině tento model skutečně odpovídá realitě toho, co aplikace dělá.

5.4 Nač tolik modelů? MDA tedy doporučuje při tvorbě a údržbě aplikací vytvořit a udržovat tyto čtyři modely, neboť se tím výrazně zjednoduší údržba a rozvoj aplikace. Podívejme se nyní proč. Udržování CIM modelu umožní vývojářům analyzovat dopady změn v činnostech uživatele na příslušnou aplikaci. Vezměme si jako příklad jarní změnu zákona o DPH. V tomto zákoně je například příchod platby považován za zdanitelné plnění a je nutné k ní vystavit daňový doklad. Implementovat do stávající ekonomické aplikace automatické vystavování daňového dokladu při příchodu platby se může zdát triviální záležitostí. Pokud však není jasné, kdo bude tento doklad odesílat zákazníkovi, zda ho bude odesílat vždy nebo jenom na vyžádání, může velmi snadno dojít k tomu, že změna je sice implementována zdánlivě správně, ale není možné jí použít. Proto je potřeba nejprve na modelu CIM analyzovat jak se změní, či rozšíří činnosti uživatele a pak teprve můžeme uvažovat, jak tyto změny ovlivní naší ekonomickou aplikaci. Udržování aktuálního modelu PIM je pak klíčové pro analytiky, kteří musí definovat příslušnou změnu na koncepční úrovni. Velice častým problém je, že aplikace je dokumentována pouze platformově specifickým modelem, který obsahuje množství informací souvisejících s technologickým řešením. Tyto informace však vlastní koncepční řešení značně zatemňují a výrazně ztěžují analytikovi práci. Důsledkem jsou pak časté chyby způsobené opomenutím nebo tím, že analytik zasahuje do technologických záležitostí, kterým až tak dobře nerozumí. V našem příkladu s daňovým dokladem k platbě musí analytik vyřešit především způsob jeho číslování, vazby na platby a další související doklady a v neposlední řadě například způsob archivace. Pokud se však musí probírat modely plnými session kontrolérů, object brokerů a podobných technologických objektů, jeho produktivita a kvalita práce samozřejmě značně klesá. Modely CIM a PIM tedy potřebujeme, ale na co nám je platformově specifický model – PSM? Jak již bylo řečeno, PSM model znázorňuje technologický způsob řešení a má stejnou strukturu jako zdrojový kód aplikace. Právě posledně uvedené je velmi důležité – PSM je totiž v podstatě vizualizací kódu. Pokud jste měli možnost programovat rozsáhlejší aplikaci, jistě jste narazili na problém jak se vyznat ve spoustě programových tříd a množství kódu. A právě k tomu slouží PSM model – abychom se vyznali v kódu a to zpětně, jako forma dokumentace, ale i dopředně, jako zadání pro vytvoření kódu. Některá vývojová prostředí (Integrated Development Environment – IDE) dnes již obsahují takovéto „vizualizéry“ kódu ve formě UML modelu, obvykle však jen ve svých Enterprise verzích.

5.5 Transformace – aneb snadno z modelu do modelu V čem spočívá nejdůležitější přínos MDA je to, že definuje kromě shora uvedených modelů také způsob a postup jejich transformace. Opět se však nejedná o zcela nový přístup, ale spíše o standardizovanou aplikaci osvědčených praktik, především zkušeností z použití návrhových vzorů (Design Patterns). Z praktického hlediska jsou zajímavé transformace CIM do PIM a PIM do PSM.

5.5.1 Transformace CIM <-> PSM Tato transformace vyjadřuje vztah mezi činnostmi uživatele a funkcionalitou aplikace. MDA se sice touto transformací příliš nezabývá, ale obvyklý postup je transformace firemních procesů do akcí uživatele v aplikaci (v UML tzv. Use Cases).

5.5.2 Transformace PIM <-> PSM Z hlediska MDA je nejzajímavější transformace platformově nezávislého modelu (PIM) do platformově specifického modelu (PSM). Postup transformace dle MDA je zhruba následující: 1. Návrhář doplní PIM model tzv. mapovacími značkami, které definují, jaká obecná transformační pravidla budou použita.

2. Pro PIM model (resp. jeho části) je zvolena implementační platforma. 3. Na základě mapovacích značek jsou provedeny odpovídající transformace již s ohledem na zvolenou platformu. Následující obrázek zachycuje úrovně abstrakce přechodů mezi jednotlivými modely. Obrázek 5: Úrovně abstrakce [Ele_04]

5.6 K čemu tedy MDA slouží? Přínos koncepce Model Driven Architecture je tedy především v tom, že jasně definuje, co je analytický model, co je návrhový model a jak provádět jejich transformaci. Cílem je, aby aplikace byla popsána na různých úrovních abstrakce a tím pádem je značně usnadněno konzistentní promítání změn v aplikaci. Další pozitivní důsledek je standardizace návrhu, která umožňuje zvýšit kvalitu aplikací. Důsledkem toho všeho je především snížení nákladů na údržbu aplikací, tedy peníze, o které jde jako obvykle až v první řadě. Jak již bylo zmíněno na začátku, MDA je především o zjednodušení a tím i zlevnění údržby a rozvoje aplikací. Vzhledem k tomu, že právě sem směřuje větší část investic související s vývojem softwaru (Gartner Group uvádí že až 70%), je tato koncepce nakonec zajímavá i po finanční stránce. MDA se bude zcela jistě dále rozvíjet. Budou vytvořeny mocnější nástroje, které budou tuto technologii využívat. S těmito nástroji bude zřejmě ubývat nutnost upravovat PSM a vše se již bude definovat v PIM, který bude spustitelný a testovatelný (bude tedy převládat přístup translationist). Potom budou tyto aplikace opravdu Model Driven.

5.7 Silné stránky MDA Největším přínosem MDA je, že kromě modelů definuje i způsob a postup jejich transformace. Vychází přitom ze zkušeností s použitím návrhových vzorů (Design Patterns). Transformace CIM – PSM obvykle přetváří podnikové procesy do akcí uživatele v aplikaci (v UML tzv. Use Cases). Transformace PIM – PSM využívá mapovacích značek, které definují použitá obecná transformační pravidla. Po zvolení platformy se na základě těchto značek provedou odpovídající transformace s ohledem na danou platformu. Ty mohou probíhat oběma směry, takže i změny na nižších úrovních se snadno promítnou do modelů vyšší úrovně. Standard MDA sestává z jazyka UML pro tvorbu vizuálních reprezentací návrhových artefaktů, standardu MOF (Meta Object Facility), popisujícího abstraktní jazyk a rámec pro správu a uchování objektů a modelů vytvořených pomocí UML v datovém skladu a konverzního prostředku XMI (XML Metadata Interchange) pro výměnu modelů mezi jednotlivými MDA nástroji.

5.8 CASE podporující MDA Jednotlivé modely lze vytvářet v různých prostředích od „kreslítek“ typu MS Power- Point až po robustní CASE nástroje. Při volbě nástroje je nutné zvážit především rozsah modelů a míru potřebné týmové spolupráce při tvorbě a úpravě modelů. Klíčovou výhodou robustních nástrojů CASE je schopnost zabezpečit vzájemnou konzistenci jednotlivých modelů mezi sebou. Informace vytvořené pomocí editorů diagramů jsou totiž ukládány v databázi informací (repository), a tak se nemůže stát, že na jednom diagramu je například rozhraní subsystému změněno, kdežto na jiném diagramu zůstane toto rozhraní beze změny. Robustním nástrojům nečiní také potíže pracovat i s velmi rozsáhlými modely, které v průběhu modelování podnikových IS vznikají. Poněkud vyšší pořizovací náklady standardního nástroje CASE oproti „kreslítkům“ nebo prosté textové dokumentaci se rychle vrátí v úsporách práce informatiků, kteří se nemusí zabývat pracným sehráváním modelů a manuálním udržováním jejich konzistence. V následující tabulce je uveden přehled nejběžnějších CASE nástrojů (včetně jejich výrobce), které podporují standardy metodiky MDA. Tabulka 1: Přehled Case nástrojů [Léb_01]

Firma

Produkt

ARTiSAN Borland Compuware I-Logix IBM MetaMatrix Select Business Solutions Telelogic

Real-time Studio TogetherJ OptimalJ Rhapsody Rational Software Architect and Modeler Commitment Select Component Architect TAU Generation2

V následujícím textu je popsán vybraný nástroj podporující MDA, který bývá v praxi často využíván. Jedná se o Select Component Architect.

5.8.1 Select Component Architekt (SCA) Pro modelování podnikových systémů je samozřejmě možné zvolit mnoho přístupů. Jedním z pragmatických přístupem, který umožňuje vytvořit potřebný model systémů a jejich vazeb v krátkém čase a s rozumnými náklady je postup modelování, který vychází z metodiky Select Perspective určené pro vývoj a údržbu středních a rozsáhlých systémů. Z hlediska modelování využívá Select Perspective standard UML doplněný o modelování firemních procesů a modelování datových struktur.

Procesy Pro celkový pohled na podnikový IS z hlediska dynamiky slouží procesní model. V tomto modelu je především zachycena vazba mezi firemními procesy a aplikacemi, které je podporují. Většina změn v systémech je totiž vyvolána změnami firemních procesů, takže model procesů je výchozím místem zkoumání při analýze dopadů změn. Na základě tohoto modelu je možné odvozovat, které systémy budou změnou ovlivněny a v jakém rozsahu. Následující obrázek zachycuje model jednoduchého procesu v prostředí SCA.

Obrázek 6: Příklad modelu vybraného procesu [ŠVE_01]

Rozhraní a závislosti Vzhledem k tomu, že většina podnikových systémů je složena z jednotlivých vzájemně provázaných aplikací od různých dodavatelů, jsou pro údržbu celého systému klíčovými informace o rozhraních aplikací (interfaces). Základním modelem systému z hlediska jeho struktury je tedy model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní. Příklad takovéhoto modelu je znázorněn v následujícím obrázku.

Obrázek 7: Model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní [ŠVE_01]

Model rozhraní umožňuje provádět analýzu dopadů toho, jak změna jednoho systému ovlivní další systémy. Závislosti mezi aplikacemi podnikového IS jsou na tomto modelu zobecněním komunikace, která probíhá na úrovni rozhraní systémů. Detailnější model komunikace mezi aplikacemi se v Select Perspective vytváří pomocí diagramu interakcí rozhraní, pro který je použit diagram sekvencí zpráv s doplněnými komentáři. Tento detailnější model slouží pro přesnější pochopení a sledování dopadů změn rozhraní jednotlivých aplikací na ostatní aplikace. Na této úrovni jsou totiž detailně zachyceny služby a informační položky rozhraní aplikace a kontext jejich využití v návazných aplikacích. [ŠVE_01]

Detailní modely aplikací Jednotlivé systémy je dále možné detailněji modelovat pomocí tradičních UML modelů, jako je model tříd nebo model interakcí. Vytvoření a údržba těchto detailních modelů je samozřejmě podstatně nákladnější a vyplatí se u systémů, které jsou buď intenzivně rozvíjeny nebo při novém vývoji.

Zpětné inženýrství Detailní model jednotlivých aplikací je možné odvodit i pomocí nástrojů pro zpětné inženýrství kódu a datových struktur. Tento přístup je obvykle používán jako prvotní fáze dokumentace existujícího systému nebo v případech, kdy neexistuje dokumentace k některým částem podnikového IS. V nástroji Select Component Architekt lze kromě zpětného inženýrství (reverzace) kódu a datových struktur provádět i zpětné inženýrství binárních komponent, které jsou stále více používány při tvorbě soudobých aplikací.

Model jako komunikační nástroj Celkový model podnikového IS je také velmi užitečným podkladem pro komunikaci s dodavateli jednotlivých aplikací při zadávání požadavků na funkcionalitu dodávaných aplikací. V prostředí Select Component Architect je možné velmi rychle vytvořit dílčí model rozhraní s příslušnou specifikací, kterou lze předat dodavateli jako zadání pro vytvářenou aplikaci. A naopak lze při dodávce aplikace provést zpětné inženýrství jejich rozhraní, pokud jsou realizována v nějaké standardní technologii, jako je Corba/IIOP, COM+ nebo webové služby (WSDL). To opět snižuje náklady na logické začlenění nové aplikace do celkového IS. [ŠVE_01]

Přínos pro organizaci Nasazení systematického přístupu, který je podpořen nástrojem CASE usnadňujícím vytváření a údržbu příslušných modelů, vede v krátkém horizontu (cca 3–6 měsíců) ke znatelným úsporám nákladů na rozvoj podnikového IT. Tyto úspory jsou však nejen finančního charakteru, který vyplývá z toho, že se změny daří úspěšně realizovat na první pokus, ale i charakteru psychologického, protože ve výsledku snižují stres pracovníků IT.

Příklad transformace modelů v SCA 1. Přiřazení transformačních pravidel k objektům analytického modelu (Tagged PIM) V této fázi definuje architekt obecný způsob implementace pro jednotlivé objekty analytického modelu, který je zatím ještě nezávislý na implementační platformě. Jedná se v zásadě o přiřazení obecných transformačních pravidel k analytickým objektům tak, jak je patrné z následujícího obrázku, kde jsou takto označené objekty indikovány symbolem γ. Obrázek 8: Tagged PIM

2. Vytvoření platformově specifického modelu (PSM) V úvodu transformace do platformově specifického modelu je nutné vybrat implementační prostředí. To je možné nastavit buď stejné pro celý model, nebo různé pro jednotlivá seskupení (Packages).

Obrázek 9: PSM Packages

V této fázi je pomocí MDA Solution vytvořen úvodní platformově specifický model, kde jsou nově vzniklé objekty modelu označeny symbolem π, čímž je indikováno, že se jedná o "modelově specifické prvky", které nemají být zpětně promítány do analytického modelu (PIM). Obrázek 10: Výsledný PSM

Návrhový model je dále rozpracován návrhářem a slouží jako podklad pro generování kódu. 3. Synchronizace modelů PIM a PSM Ve fázi detailního návrhu ale i dalšího postupu analýzy dochází samozřejmě ke změnám v modelu. MDA Solution umožňuje tyto změny porovnat a promítat je do druhého modelu. Při synchronizaci je nejprve nutné vybrat, jaký typ porovnávání se má použít (viz následující obrázek).

Obrázek 11: Synchronizace PIM a PSM

Při porovnání modelů jsou samozřejmě ignorovány modelově specifické prvky. Na následujícím obrázku je znázorněn případ, kdy v analytickém modelu přibyla operace A ("zruš pracovníka") a v návrhovém modelu zase operace B ("remOpa"). Záleží nyní na architektovi, který synchronizaci provádí je nyní posouzení, zda mají být tyto změny synchronizovány, nebo mají být příslušné prvky označeny jako "modelově specifické". Obrázek 12: Případ modelově specifické odlišnosti

4. Přizpůsobení transformačních pravidel Transformační pravidla, která jsou v MDA Solution připravena pro jazyky Java, C#, VB.Net a C++ je možné uživatelsky konfigurovat a doplňovat. Na následujícím obrázku je vidět nastavení transformačního pravidla "Create data tier class" pro C#, které doplňuje do komponenty přístup k datům na základě mapování mezi třídami a tabulkami na fyzickém datovém modelu.

Zdroj obrázků: http://www.lbms.cz/Nastroje/Select/_images

6 Další přístupy k řízení IS/ICT 6.1 ITIL ITIL je zkratkou pro "Information Technology Infrastructure Library", což přeloženo do češtiny znamená "knihovna infrastruktury informačních technologií".Od svého vzniku v 80. letech prošel velkým vývojem a stal se mezinárodně uznávaným standardem pro řízení IT služeb. Ačkoli původně vznikl jako knihovna osvědčených praktik (best practises) a standardních metodologií pro řízení klíčových procesů IT, v současné době je již ITIL zcela samostatným oborem činnosti a podnikání, jenž zahrnuje: ● ● ● ● ●

Samotnou knihovnu čítající v současné době 8 svazků Oblast vzdělávání a certifikace odborné způsobilosti Oblast poskytování konzultačních služeb Oblast vývoje a implementace softwarových nástrojů pro podporu procesů ITSM Mezinárodní platformu profesionálů a odborné veřejnosti

Pro účely naší práce se však při popisování koncepce ITIL omezíme na původní funkci a budeme jej chápat pouze jako knihovnu osvědčených praktik a metodologií pro řízeni IS.

6.1.1 Charakteristika ITIL ● ●

●

ITIL je rozsáhlý, konzistentní a procesně orientovaný rámec pro designování procesů podpory a řízení služeb ICT Tento rámec je popsán v 8 publikacích, které obsahují: Definici procesů pro zajištění dodávky a podpory IT služeb (ITSM): Stanovení cílů, vstupů, výstupů a aktivit každého procesu Stanovení rolí a jejich odpovědností v daném procesu Způsob měření kvality poskytovaných IT služeb a účinnosti procesů Vzájemné vazby mezi procesy Zásady pro implementaci procesů ITSM: Přínosy, Critical Success Factors, problémy a vhodná protiopatření, Náklady na implementaci a následný provoz Zásady pro řízení ICT infrastruktury Zásady bezpečnosti ICT infrastruktury ITIL je založený na nejlepších zkušenostech z praxe ITSM, tzn. jako souhrn "Best Practices" z oblasti ITSM, což mimo jiné znamená, že: Hodně oblastí, které ITIL popisuje, nepředstavuje pro lidi z praxe něco zásadně nového nebo něco naprosto neznámého Některé aktivity a principy, které jsou v současnosti již v řadě podniků implementovány, mohou být zásadám a principům ITIL dosti podobné

Následující schéma ukazuje vzájemné vztahy publikací ITIL a znázorňuje vztah jednotlivých publikací k obchodním procesům na jedné straně a ICT infrastruktuře na straně druhé:

Obr. 1

zdroj: www.itil.cz

6.1.2 Přínos existence knihovny ITIL ● ● ●

Všechny zkušenosti z praxe shrnuje do jednoho uceleného a konzistentního rámce Dává všechny ITSM procesy do vzájemných souvislostí Zavádí jednotnou a mezinárodně používanou terminologii

6.1.3 Shrnutí ITIL není metodika, a to ani metodika IT Service Managementu, ani metodika implementace ITSM v organizaci, ale rámec pro designování procesů ITSM založený na nejlepších zkušenostech z praxe (ITIL ponechává velikou volnost při implementaci procesů). Protože ITIL je nezávislý na platformě a protože je to "rámec", jsou výstupy všech dodavatelů kompatibilní a univerzálně použitelné ve všech odvětví (SW nástroje, školení, konzultační služby).

6.2 COBIT COBIT (Control Objectives for Information and related Technology) je sada best practices pro informační management vytvořena ISACA (Information Systems Audit and Control Association) a ITGI (IT Governance Institute) v roce 1996. byl vyvinut jako všeobecně použitelný a přijímaný standard pro správné postupy řízení informačních technologií. Je založen na cílech řízení a rozšířeny o existující a vznikající mezinárodní technické, profesní, zákonné a specifické standardy jednotlivých odvětví. Výsledné cíle řízení byly vyvinuty pro aplikaci v celopodnikových informačních systémech. Jedná se tedy o self-assessment nástroj pro konstruktivní a strukturované řízení informačních technologií založený na bázi systémových procesů.

6.2.1 Charakteristika COBITu ●

● ●

Cílem COBITu je zkoumat, vyvíjet, publikovat a rozšiřovat směrodatný, aktuální a mezinárodně přijímaný komplex cílů řízení informačních technologií pro každodenní používání obchodními manažery a auditory je tvořen soupisem určitých stavů, ve kterých by se firemní IS/ICT měla nacházet Páteří COBITu jsou vzájemné vztahy mezi zdroji IT, procesy IT a informačními kritérii. Tyto tři vzájemně prolínající se složky pokrývají celou metodiku COBIT, viz obr.2

Obr.2

Zdroj: www.isaca.org

6.2.2 Procesy Ačkoli ne jedinou, procesy tvoří hlavní složku COBITu. Standard definuje celkem 34 hlavních procesů, pro které uvádí obecný přístup ke kontrole a postupy pro audit. Všechny procesy jsou rozděleny do 4 základních domén: ● ● ● ●

Plánování a organizace Akvizice a implementace Dodávka a podpora Měření a hodnocení

Jednotlivé vztahy domén a procesů spolu se začlenění do celkového systému řízení IT je znázorněno na následujícím schématu.

Obr.3

Zdroj: www.isaca.org

6.3 Srovnání ITIL a COBIT Nejdůležitějším rozdílem je samotný původ COBITu. Ten, na rozdíl od ITILu, nevzešel z praxe, ale je produktem několika profesionálních auditorských společností, což je na jazyku a srozumitelnosti COBIT podstatně znát. Tudíž implementace procesů COBIT je oproti ITIL mnohem složitější a procesy COBIT jsou pro obyčejné lidi z praxe podstatně méně "čitelné" než jasné a přehledné procesy ITIL. ITIL je s procesy podle COBIT plně kompatibilní - jednotlivé procesy i dílčí kontrolní cíle COBIT je možné přehledně namapovat na jednotlivé procesy, resp. aktivity ITIL. Na úrovni procesů však toto mapování není ve vztahu 1:1, ani 1:n, ale m:n, tzn. že určité množině procesů COBiT odpovídá určitá množina procesů podle ITIL. V následující tabulce je uveden přehled rozdílů COBIT a ITIL podle vybraných kritérií:

COBIT

ITIL

Šířka záběru

všechny aspekty managementu informatiky

pouze management IT služeb a ICT infrastruktura

Hloubka záběru

pouze identifikace procesů a vymezení cílů jejich řízení

obsahuje reálný rámec pro definici procesů a mnoho příkladů

Určení

auditoři a top manažeři z vně úseku ICT

ICT manažeři všech úrovní

Implementace

komplikovaná, nutno vymyslet konkrétní procesy

relativně přímočará, rámec procesů je dán

Dostupnost

6 ze 7 publikací volně ke stažení na internetu

pouze placené, knihy nebo HTML verze na CD

7 Případová studie 7.1 Představení firmy Firma působí v oblasti výuky jazyků. Nabízí širokou paletu služeb od klasické prezenční výuky, ať už individuální nebo skupinové, přes překlady, tlumočení a výuku v zahraničí. Ve firmě pracuje na plný úvazek cca 20 zaměstnanců a dále pak množství externích lektorů, překladatelů a tlumočníků.

7.2 Něco z historie Firma začínala s podnikáním před cca 10 lety, kdy byla výuka jazyků ještě v počátcích. Konkurence nebyla v té době tak velká, stejně jako v podstatě neexistovaly zkušenosti s podnikáním v této oblasti. V počátcích se tedy firma zaměřovala jen na výuku pro veřejnost a vystačila si s pár lektory a zaměstnanci, kteří zajišťovali nutnou agendu. Komunikace ve firmě probíhala formou pravidelných schůzek a informace byly uskladňovány v tabulkových procesorech. Jak šel čas, tak se také zvětšoval záběr firmy. Nejprve se začala zaměřovat na firemní výuku, následně rozšířila své služby i o překlady a tlumočení. V té době již nestačily prostory pro výuku a tak byla firma nucena založit ještě jednu pobočku. Tímto vyvstaly problémy v následujících oblastech: ●

koordinace lektorů Každá z poboček pořádala vlastní kurzy, přičemž lektoři byli společní pro celou firmu. To kladlo velké nároky na komunikaci mezi pobočkami, aby nedocházelo ke kolizím ve výuce a tvorba rozvrhů tak zabírala neúměrně velké množství času.

●

evidence zákazníků Ve firmě existovaly jisté věrnostní programy pro stálé klienty. Teď ale mohla nastat situace, kdy klient mohl navštěvovat kurzy v jedné z poboček a využívat tam slev, ale pokud by přišel do pobočky druhé, nedostal by žádné slevy, jelikož tam není v evidenci.

●

marketing Každá pobočka si marketingové akce pořádá sama. Ale jak již bylo zmíněno výše, někteří zákazníci mohli být pro pobočky společní, stejně tak mohli být společní i zákazníci, na které se chtěli teprve zaměřit. To opět kladlo velké nároky na koordinaci, aby nebyli oslovováni stejní zákazníci dvakrát a nedocházelo tak k plýtvání prostředky.

●

evidence nákladů a výnosů Každá pobočka si vede své vlastní přehledy, přičemž některé náklady a výnosy jsou spojené s celou firmou. Vzhledem k faktu, že rozpočty poboček jsou oddělené, mohlo by docházet k situaci, kdy pobočka bude generovat výnosy, které se započítají i pobočce druhé, přičemž náklady bude hradit zcela samostatně.

Dále s růstem firmy vznikly požadavky řešit následující oblasti: ●

skladové hospodářství S postupem času se firma rozhodla nabízet svým zákazníkům materiály pro výuku a dále pak také různé cizojazyčné publikace. Tyto si mohli klienti také půjčovat. V počátcích, kdy byl sklad poměrně malý, nebyl takový problém zajistit evidenci skladu a výpůjček, ovšem později již v této oblasti vznikl nepořádek a evidence byla obtížná.

●

fakturace S rostoucím počtem zákazníků se začaly zvyšovat nároky na personál v oblasti vystavování

faktur a jejich zápisu. U každé objednávky totiž museli znovu zapsat zákazníka do připraveného formuláře, vyplnit názvy objednaných položek, počítat ceny a následně vše ještě uložit do tabulkového procesoru. To zabíralo zaměstnancům značnou část pracovní doby a nemohli se tak věnovat dalším, pro firmu prospěšným činnostem. Firma se proto rozhodla pro nákup informačního systému, který by tyto oblasti zautomatizoval a tím ušetřil čas a náklady. Vzhledem k faktu, že se jedná spíše o menší firmu, bylo poptáváno řešení založené na třívrstvé architektuře a webových technologiích. Po konzultaci s dodavatelem bylo rozhodnuto, že se daný informační systém bude skládat z více víceméně samostatných modulů, které budou vyvíjeny separátně a budou přímo suplovat firemní procesy. Vývoj softwaru trval 18 měsíců, byl realizován externě a podílelo se na něm několik programátorů a analytiků, což kladlo velký důraz na vzájemnou komunikaci, jak mezi firmou a dodavatelem, tak i mezi programátory a analytiky. V následujících jednotlivých podkapitolách bude řečeno jestli a jakým způsobem jsou realizovány jednotlivé činnosti řízení IS/ICT v popisované firmě a zda je využíváno CASE nástroje.

7.3 Vývoj IS/ICT V první řadě bylo nutné popsat firemní procesy. Zaměstnancům firmy bylo uloženo slovně vyjádřit a alespoň částečně zformalizovat jejich každodenní úkoly. Proces objednávek byl popsán následovně: telefonický nebo osobní kontakt zákazníka -> zjištění požadavků zákazníka pracovníkem firmy -> zařazení do kurzu -> vystavení dokladu. Po této fázi přišla fáze detailního rozpracování těchto procesů. To se dělo na schůzkách analytika a daného odpovědného pracovníka firmy, kdy byly konzultovány všechny potřebné aspekty. Své poznatky pak analytik s využitím CASE nástroje Power Designer zformalizoval v Business Process modelu. Výše zmíněný proces objednávek pak dostal následující podobu:

Obr. 1 – Procesní model

Jak je již na první pohled zřejmé, popis procesu s využitím CASE nástroje je mnohem názornější. Také v něm jsou již naznačeny datové zdroje, které budou využity při další analýze a návrhu. Po zmapování procesů firmy přišli na řadu programátoři. Jejich úkolem bylo zkonzultovat se zaměstnanci nakládání s informacemi, jejich strukturu a vzájemné vazby. Dále byl také konzultován návrh obrazovek budoucího systému a popis scénářů jeho chování. Výstupem této fáze pak byl diagram tříd a datový model. Ty byly opět realizovány za pomocí CASE nástroje. Obr. 2 – Diagram tříd

Obr. 3 – Fyzický datový model

Tyto diagramy navazují na procesní model objednávek a poskytují programátorům dostatečné informace pro implementaci samotného informačního systému, v tomto případě jednoho modulu, konkrétně modulu objednávek.

7.4 Provoz IS/ICT Při provozu informačního systému se v této firmě CASE nástroj příliš nevyužívá. Výjimkou jsou výstupy procesních a databázových modelů, které slouží jako dokumentace a jsou zaměstnancům jistým vodítkem, jak s daným informačním systémem pracovat. Na straně dodavatele se CASE nástroj využívá hlavně v případě, kdy je zapotřebí upravit datový model. Vzhledem ke schopnosti CASE nástroje vygenerovat změněnou strukturu databáze i se samotnými daty, je tato úloha značně usnadněna.

7.5 Řízení služeb IS/ICT Vzhledem k úzkému zaměření firmy není řízení služeb ve firmě nikterak komplexní a žádný CASE nástroj využíván není.

7.6 Plánování projektu IS/ICT V této oblasti firma CASE nástroj nevyužívá a to zejména z toho důvodu, že žádný z dostupných nástrojů plně nevyhovuje jejím požadavkům. K plánování složitějších projektů se ve firmě využívá MS Project, u jednodušších projektů si většinou odpovědní zaměstnanci vystačí s tabulkovými procesory.

7.7 Řízení ekonomiky IS/ICT a metrik Tato oblast je částečně implementována v dodaném informačním systému, to se týká hlavně plánovaných nákladů a příjmů. Výstupy jsou tedy generovány přímo z těchto dat a CASE nástroj využíván není.

7.8 Řízení personálních a datových zdrojů K řízení personálních zdrojů firma nevyužívá žádný CASE nástroj. Tuto oblast zajišťuje HR oddělení na základě vytvořených metodik. Jejich část je ale implementována v informačním systému. Co se datových zdrojů týče, tak zde, jak již bylo řečeno, se CASE nástroj využívá v poměrně velké míře.

7.9 Informační strategie Dokument informační strategie obsahuje plán rozvoje oblasti firemních informačních technologií a předpokládané finanční výdaje. Při jeho tvorbě nebyl využit žádný CASE nástroj a to zejména z toho důvodu, že se jedná pouze o strukturovaný text, který lze jednoduše vytvořit v jakémkoli textovém editoru. V budoucnu ale není vyloučeno, že firma bude zařazovat do tohoto dokumentu i určitý náčrt nově plánovaných procesů. Pak by CASE nástroj jistě využit byl.

7.10 Bezpečnostní strategie a politika Dokument bezpečnostní strategie opět není vytvářen s pomocí CASE nástroje. Samotná implementace bezpečnostní strategie je ale obsažena v datovém modelu, k jehož tvorbě CASE nástroj využit byl.

7.11 Organizace řízení IS/ICT Tato oblast je čistě v rukou majitele firmy. Vzhledem k faktu, že informační systém firmy je poměrně jednoduchý, není třeba vytvářet nějaké specializované postupy, tudíž i využití CASE nástroje je zde zbytečné.

7.12 Tvorba, správa a řízení dokumentace IS/ICT Jako dokumentace slouží ve firmě výstupy z CASE nástroje. Z toho důvodu bylo zapotřebí vyškolit určité zaměstnance, aby částečně porozuměli jazyku UML. To s sebou přineslo značné zefektivnění komunikace mezi firmou a dodavatelem informačního systému, jelikož zaměstnanci mohou lépe definovat a popsat vzniklý problém. Tím pádem pak může i dodavatel rychleji zareagovat a firma šetří čas. Takto vytvořená dokumentace je také zárukou toho, že pokud by nastaly problémy s dodavatelem a bylo by nutné jej změnit, netrvalo by novému dodavateli příliš dlouho, aby do problematiky informačního systému pronikl.

8 Závěr Věříme, že se našemu týmu naší prací podařilo dobře navázat na práci našich předchůdců. Že je dokument nyní aktuálnější, kompletnější a přehlednější. A že díky příkladům a obrázkům bude pochopení jednotlivých uvedených metod, postupů a nástrojů snadnější a čtenář si snadno udělá komplexnější přehled o probírané problematice. Bohužel se nám nepodařilo zpracovat případovou studii z vlastních zdrojů. I tak jsme ale přesvědčení, že rozšíření stávající studie bude přínosné. Od uvedení konkrétních postupů si slibujeme jasnější nastínění toho, jak by může vypadat využití CASE nástrojů v konkrétním případě, jaké jsou přínosy a další související faktory. Jak bylo naznačeno již v úvodu, efektivita a přínos použití CASE nástrojů pro řízení IS/ICT firmy je velmi závislá na správně zvolených postupech a jednotlivých nástrojích. Zvláště u velkých firem nebo rozsáhlých a složitých informačních systémů, tyto dvě věci se často kryjí, je řízení návrhu, implementace, správy nějakým neautomatizovaným způsobem neudržitelné a nemožné. A právě to je prostorem pro použití CASE nástrojů. Samozřejmě nasazení a implementace takového software samo o sobě zabírá zdroje podniku. Použité CASE nástroje podniku se tak stávají nedílnou součástí jeho informačního systému a je třeba i na ně pamatovat ve strategických dokumentech a rozhodnutích.

9 Zdroje Wikipedia, http://www.wikipedia.org/ Agile Model Driven Development with UML 2, http://www.ambysoft.com/books/theObjectPrimer.html Unified Modeling Language (UML), version 2.0, http://www.omg.org/technology/documents/formal/uml.htm UML basics: The component diagram, http://www-128.ibm.com/developerworks/rational/library/dec04/bell/ Novinky ve specifikaci UML2, http://zubicek.eu/skola/novinky-ve-specifikaci-uml2/ [ŠVE_01] Jaromír Šveřepa – Praktický způsob Modelování podnikových IS – Informační systémy (7-8/2003) [ŠVE_02] Jaromír Šveřepa – Zajímavé aspekty použití nástrojů CASE – Network computing (01/2004) [Léb_01] Jan Lébl – Modelování aplikací nanovo: UML 2.0, MDA nebo někdo další? - Connect! (02/2005) [EL_01] MDA Guide Version 1.0.1 [EL_02] www.SystemOnLine.cz [EL_03] ISO, RM-ODP [X.900], http://www.joaquin.net/RM-ODP/ [EL_04] Select Business Solutions Supporting the OMG™ Model Driven Architecture®, http://www.selectbs.com/ [www1] www.itil.cz [www2] www.isaca.org [NEM05] SW pro řízení provozu IS, D.Němeček, dipl.práce, 2005 [IST04] COBIT a jeho využití v praxi, E. Ištvánfy, bak. práce, 2004