Využití modelovacích nástrojů pro řízení IS/ICT ve firmě

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.
Vypracovali:
Marcela Fišerová
Tomáš Baxa
Marek Hejcman
Svatopluk Ježek
Lukáš Kapitán
Petr Vaněk
ZS 2010/2011
Obsah
1.
ÚVOD ....................................................................................................................................................... 2
2.
TERMINOLOGIE ........................................................................................................................................ 3
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
IS - INFORMAČNÍ SYSTÉM ............................................................................................................................. 3
IT - INFORMAČNÍ TECHNOLOGIE..................................................................................................................... 3
ICT - INFORMATION AND COMMUNICATION TECHNOLOGIES .............................................................................. 3
CASE - COMPUTER-AIDED SOFTWARE ENGINEERING ........................................................................................ 3
ŘÍZENÍ IS/ICT ............................................................................................................................................ 3
DŮVODY ŘÍZENÍ IS/ICT ................................................................................................................................ 5
DŮVODY POUŽITÍ NÁSTROJŮ CASE [2] ........................................................................................................... 5
NÁSTROJE CASE ........................................................................................................................................ 6
3.
PRINCIPY ŘÍZENÍ PODNIKOVÉHO IS/ICT ................................................................................................... 7
4.
HISTORIE NÁSTROJŮ CASE ..................................................................................................................... 11
4.1.
4.2.
4.3.
4.4.
5.
VZNIK NÁSTROJŮ CASE ............................................................................................................................. 11
80. LÉTA ................................................................................................................................................. 11
90. LÉTA ................................................................................................................................................. 11
SOUČASNOST ........................................................................................................................................... 11
MODELOVACÍ JAZYKY UML .................................................................................................................... 12
5.1.
5.2.
5.3.
6.
HISTORIE UML ........................................................................................................................................ 12
DIAGRAMY .............................................................................................................................................. 12
NÁSTROJE PRACUJÍCÍ S UML ....................................................................................................................... 22
MODEL DRIVEN ARCHITECTURE ............................................................................................................. 24
6.1.
6.2.
6.3.
7.
MODELY MDA ........................................................................................................................................ 25
TRANSFORMACE MEZI MODELY CIM, PIM, PSM A CODE ................................................................................ 25
MDA NÁSTROJE ....................................................................................................................................... 27
METODIKY ŘÍZENÍ IS/ICT ........................................................................................................................ 28
7.1.
7.2.
8.
CMMI (CAPABILITY MATURITY MODEL INTEGRATION).................................................................................... 28
METODIKA RATIONAL UNIFIED PROCESS ....................................................................................................... 30
METODIKY KONTROLINGU IS/ICT ........................................................................................................... 32
8.1.
8.2.
8.3.
9.
ITIL ....................................................................................................................................................... 32
COBIT - CONTROL OBJECTIVE FOR INFORMATION AND RELATED TECHNOLOGY .................................................... 33
SROVNÁNÍ ITIL A COBIT ........................................................................................................................... 36
KONKRÉTNÍ PRODUKTY PRO ŘÍZENÍ IS/ICT............................................................................................. 37
10.
10.1.
10.2.
10.3.
10.4.
10.5.
PŘÍPADOVÁ STUDIE ........................................................................................................................... 40
ZÁMĚR INVESTORA.................................................................................................................................... 40
VÝCHOZÍ SITUACE IS/ICT SPOLEČNOSTI ......................................................................................................... 40
REENGINEERING IS/ICT SPOLEČNOSTI........................................................................................................... 40
ŘÍZENÍ IS/ICT SPOLEČNOSTI [52] ................................................................................................................ 40
PŘÍNOSY ................................................................................................................................................. 42
11.
ZÁVĚR ................................................................................................................................................ 44
12.
ZDROJE .............................................................................................................................................. 45
1
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
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.
2.4.1. 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
Obrázek 1 – schéma řízení IS/ICT v podniku, zdroj: [1]
2.5.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
2.5.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ů
4
2.5.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.6. 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.
2.7. 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
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
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
3.1.1. 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
3.1.2. 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
Aktivity, které napomáhají naplňovat cíle druhé vrstvy, jsou následující:
•
•
•
•
Definice a optimalizace PP1
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
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.
3.1.3. 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.
3.1.4. Č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
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.
3.1.5. 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
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á.
4.2. 80. 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.
4.3. 90. 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.
4.4. 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
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.
5.1. 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 2.2.
5.2. 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
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
5.2.1. 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]
Obrázek 4 - Dagram tříd, zdroj: [36]
2) Diagram komponent
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
3) Diagram vnitřní struktury
Jedná se o diagram, který byl zařazen do verze UML 2.0. Umožňuje znázornit interní strukturu
struktu
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.
různi 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
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
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]
5.2.2. 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
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
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]
5.2.3. 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
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]
Obrázek 15 – Diagram komunikace, zdroj: [18]
13) Diagram přehledů interakcí
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
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
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.
5.3.1. 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]
5.3.2. 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]
5.3.3. 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]
5.3.4. 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
5.3.5. 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]
5.3.6. 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
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áří 2001. 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
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.
6.1. 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
6.1.1. 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é.
6.1.2. 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.
6.1.3. 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.
6.1.4. 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
Obrázek 19 - MDA workflow, zdroj: [30]
6.2.1. 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á.
6.2.2. 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.
6.2.3. 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
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.
6.3.1. 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
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 2008. 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
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
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
Ž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
8. Metodiky kontrolingu IS/ICT
8.1. ITIL
8.1.1. 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.2.
8.1.2. 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ů.
8.1.3. 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.3.
8.1.4. 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
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:
8.2.1. Základní IT procesy
Plánování a organizace
Akvizice a implementace
Poskytování a podpora
Monitorování
8.2.2. IT zdroje
Aplikace
Informace
Infrastruktura
Lidské zdroje
8.2.3. Informační kritéria
Účelnost
Hospodárnost
Důvěryhodnost
Integrita
Dostupnost
Souhlasnost/Shoda
Spolehlivost
33
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]
8.2.4. Cíle řízení
definice požadavků ze strany businessuu
strategický cíl ke každému procesu
detailní cíle jednotlivých procesů
8.2.5. 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
Obrázek 20 - vztah domén a procesů, zdroj: [13]
8.2.6. 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
8.3. Srovnání ITIL a COBIT
Základním rozdílem mezi těmito dvěma metodikami je způsob jejich podání. COBIT na rozdíl od ITILu
nepochází z praxe, ale vznikl jako potřeba auditorských společností. To, že COBIT byl vytvořen
profesionály v oboru, velmi ovlivňuje srozumitelnost formulí právě této metodiky. Tato skutečnost
má za následek, že její implementace do podniku je poněkud složitější než u ITILu, kde procesy působí
mnohem přehlednější a jasnější.
V každém případě jsou procesy obou metodik kompatibilní. Ovšem svá úskalí to má, a to především
v mapování COBITu na ITIL. Zde nemůžeme postupovat v mapování ve vztahu 1:1 ani 1:n, ale ve
vztahu m:n, tzn., že určité množině procesů COBITu odpovídá určitá množina procesů ITILu. [12]
Kritéria
Šířka záběru
Hloubka záběru
Určení (okruh
příjemců)
Dostupnost
Implementace
Pro koho je vhodný
COBIT
Všechny oblasti vedení IT
Identifikace, vymezení cílů řízení
Auditoři + top manažeři z ICT
Ke stažení na internetu
Komplikovaná (nutné procesy
vymyslet)
Velké korporace (pro velké
množství uživatelů a podniky
s milionovými rozpočty)
ITIL
POUZE vedení IT služeb a ICT
infrastruktury
Reálný rámec pro definici procesů +
př.
ICT manažeři všech úrovní
Pouze placené (OMNICOM Praha,
TSO, SMF)
Relativně přímočará (rámec
procesů je dán)
Jakýkoli podnik bez závislosti na
velikosti podniku, množství
uživatelů apod.
Tabulka 1 - srovnání metodik COBIT a ITIL
Výhody
Nevýhody
Použití
Určení
COBIT
Pokrývá všechny oblasti řízení a
auditu ICT
• Nedefinuje terminologii
• nutnost vymýšlet procesy
Nástroj strategického řízení
TOP management úseku ICT
ITIL
• Jednoznačná terminologie
• definované procesy
• přímočará implementace
Nepokrývá všechny oblasti vedení ICT
Nástroj operativního a taktického řízení
Podnikový TOP management
Tabulka 2- Výhody a nevýhody metodik COBIT a ITIL
36
9. Konkrétní produkty pro řízení IS/ICT
Podniková architektura (angl. „Enterprise Architecture“) je velmi obecný pojem, který v sobě
zahrnuje spoustu věcí a pro každého architekta má trochu jiný význam. Uvedu překlad definice,
kterou vyslovil Roger Sessions:
Podniková architektura zahrnuje popis cílů organizace, způsobů jak jsou tyto cíle dosahovány pomocí
podnikových procesů a způsobů, jak mohou tyto procesy být podpořeny technologiemi. [24]
Podniková architektura definuje vizi, zásady, normy a podrobný plán, podle kterých se řídí výběr,
zavedení, provoz a obnova technologií v organizaci.
Organizace se podnikovou architekturou zabývají proto, aby podpořily dosažení svých cílů, jako např.
úspor nákladů, provozní efektivnosti a zajištění podnikových inovací prostřednictvím informačních
technologií. Společnosti, které investují do flexibilní podnikové architektury, získávají přesný obraz o
svém IT prostředí, což jim umožňuje podporovat nové podnikové procesy, přizpůsobovat se měnícím
se tržním podmínkám a využívat nové technologie.
Pro zajištění úspěchu potřebují mít organizace přehled o své podnikové architektuře, aby viděly, jaký
dopad bude mít vznikající technologie na jejich konkrétní prostředí dříve, než se tak stane, aby mohly
řídit přechod a maximalizovat inovace. Společnost Accenture zastává názor, že strategické investice
do podnikové architektury patří mezi nejdůležitější investice na podporu produktivity a růstu na
rozdíl od neuváženého reaktivního vynakládání prostředků na udržování stávajících, značně
komplikovaných a různorodých IT systémů.
Podniková architektura není pouhým plánem uvádějícím informační technologie do souladu s
dynamickým podnikatelským prostředím, ale může také působit jako monitor pro celé IT prostředí.
Odhaluje tak rozpory mezi podnikovými strategiemi a technologiemi, které je mají podporovat, a
zároveň definuje příležitosti pro zvyšování efektivnosti a optimalizaci. Účinná podniková architektura
organizacím umožňuje určit, zda jejich IT prostředí dokáže podporovat nově se objevující
technologie, a jaký účinek budou tyto technologie mít v rámci celé organizace. [25]
9.1. Enterprise Architect 7
Nástroj CASE Enterprise Architect je vyvíjen australskou společností Sparx Systems.
Enterpise Architect je založen na podpoře UML verze 2.3 (nově ve verzi 7), ale s možností
dodefinování dalších objektů a jejich vlastností se otevírá prakticky neomezená možnost tvorby
vlastních modelů. Je to nástroj, který je schopen podpořit a velice usnadnit celou fázi vývoje
software, od definování požadavků na systém, designu až po přípravu testování a dokumentaci
systému. [26]
37
Obrázek 21 – prostředí Enterprise Architect, zdroj [26]
•
Podpora diagramů UML [27]
• Strukturní diagramy
o Diagram tříd (Class diagram)
o Objektový diagram (Object diagram)
o Diagram vnitřní struktury (Composite Structure Diagram )
o Diagram komponent (Component Diagram)
o Diagram nasazení (Deployment Diagram)
o Diagram balíčků (Package Diagram)
• Diagramy chování
o diagram případu užití (Use Case Diagram)
o diagram činností (Activity Diagram)
o stavový diagram (State Diagram)
38
o diagramy interakcí
• Sekvenční diagram (Sequence Diagram)
• Diagram komunikace (Communication Diagram)
• Přehled interakcí (Interaction Overview Diagram)
•
Modelování obchodních procesů
• Datové modelování [27]
Enterprise Architect umožňuje i tvorbu logického a fyzického datového modelu. Zajímavostí je, že
tvorba těchto modelů probíhá pomocí notace UML, tabulky jsou třídy se stereotypem „Table“. Jako
vztahy mezi tabulkami je možné použít standardní vztahy známé z objektového a datového
modelování – tedy především asociaci a generalizaci.
•
Mapování struktury modelů v Enterprise Architectu
39
10.
Případová studie
Případová studie se zabývá situací, kdy do fiktivní realitní kanceláře vstoupil nový investor, který chce
zhodnotit svou investici tím, že zvýší podíl společnosti na trhu a podpoří ekonomický růst firmy.
10.1.
Záměr investora
Svého záměru chce investor dosáhnout tím, že stanoví, popíše a zefektivní podnikové procesy,
zavede novou firemní a informační strategii. Klíčovou oblastí pro dosažení vytyčených cílů, z pohledu
investora, je zejména oblast podnikové informatiky. Z tohoto důvodu se investor rozhodl pro analýzu
a následný reengineering IS/ICT ve firmě.
10.2.
Výchozí situace IS/ICT společnosti
Naše fiktivní realitní kancelář je středně velká společnost (hodnoceno podle obratu), jejíž IT lze
charakterizovat následovně:
•
•
•
•
počítačová síť není architektury klient/server
nejsou zavedeny žádné standardy (bezpečnostní)
společnost nemá webovou presentaci
podniková informatika není řízená
Celkově situace podnikového ICT je z pohledu investora a jeho plánu do budoucna nedostatečná.
Firma využívá externího IT odborníka, který dochází jednou týdně na kontrolu stavu IT. Případné
poruchy řeší zejména pomocí vzdáleného přístupu k lokální síti.
10.3.
Reengineering IS/ICT společnosti
Pro změnu nevyhovující situace se investor rozhodl vytvořit zcela novou informační strategii
založenou na závěrečné zprávě předešlého interního auditu a analýze podnikových procesů. Investor
chce dosáhnout zpřehlednění infrastruktury IS/ICT za účelem efektivnějšího řízení, a také docílit
zvýšení efektivity využívání IT zdrojů.
Ve společnosti byly provedeny následující změny ve spojitosti s IS/ICT společnosti:
•
•
•
•
•
•
•
•
Inovace hardwarového vybavení (server, síťové prvky)
Zmapování a zavedení síťové architektury (typu klient-server)
Návrh a vytvoření vlastní webové prezentace
Zavedení jednotného podnikového informačního systému a databáze
Stanovení odpovědné osoby za řízení IS/ICT podniku
Zavedení a dodržování norem a standardů (např. ISO, ITIL)
Popsání a zefektivnění podnikových procesů
Zajištění správy IS/ICT formou outsourcingu
10.4.
Řízení IS/ICT společnosti [52]
Z důvodu potřeby efektivnějšího řízení podnikové informatiky rozhodlo vedení společnosti, po
poradě s externím odborníkem, o zavedení BTO (Business Technology Optimization).
40
Základní otázkou při řízení podnikové informatiky je totiž, jak zajistit odpovědné vyhodnocování rizik,
nákladů a přínosů uvažovaných změn v podnikovém IS/ICT. Respektive zajištění monitoringu a řízení
rizik. Za tímto účelem existuje řada softwarových nástrojů, které zmíněné oblasti podporují.
Tyto nástroje vycházejí ze základní myšlenky BTO, která je postavená na harmonizaci cílů IT a
podnikání. Účelem je efektivně pomoci manažerům odpovědným za rozhodnutí, zda se změna má
provést, či nikoliv. Největší přidaná hodnota těchto nástrojů spočívá v automatizaci a snižování rizik i
nákladů vyvolaných změnami.
Základem nástrojů pro řízení IS/ICT jsou nástroje pro mapování podnikového IS/ICT, které
automaticky rozpoznávají, z jakých objektů se dané podnikové IT skládá. Mapují nejen infrastrukturu
– tedy sítě, servery a aplikace, ale také uživatelé, databáze, otevřené porty na firewallech atd.
Zjištěné podrobné údaje jsou následně uloženy do konfigurační databáze. Nástroje poté sledují
používání a chování jednotlivých objektů.
Cílem nástrojů pro mapování aplikací je přitom zjistit, jakým způsobem spolu jednotlivé objekty
komunikují, jaké jsou prováděny transakce, jak fungují jednotlivé aplikace, a které z nich se provádění
transakcí účastní. Zjišťují také vazby mezi jednotlivými objekty při účasti na podnikových procesech.
Na nástroje mapující podnikové systémy pak těsně navazují systémy pro řízení změn podnikového
IS/ICT. Tyto nástroje pak představují soubory aplikací a postupů pro optimalizaci požadavků na změny
v IS/ICT. Určují, jak mají změny probíhat, kdo je má iniciovat, kdo schválit, provést nebo zkontrolovat.
Tyto nástroje vyžadují nepřetržitou provázanost s technickou stránkou daného systému, aby byly
schopny vyhodnocovat, zda provedené změny jsou v souladu s optimalizovanými procesy. Dále
analyzují možné dopady připravovaných změn na jednotlivé části systému. Další skupinou nástrojů
pro řízení podnikové informatiky jsou nástroje pro sledování životního cyklu výkonnosti aplikace
z hlediska jak technologického, tak i podnikatelského.
10.4.1. Mapování a řízení podnikového IS/ICT [52]
Společnost si pro oblast řízení zvolila nástroj HP Discovery and dependency Mapping (HP DDM).
Po svém nasazení „ HPDDM“ nejprve prozkoumá činnost každého infrastrukturního prostředku v
produkčním prostředí. Poté zjistí vnitřní vztahy mezi podnikovými aplikacemi a infrastrukturou, na níž
jsou provozovány. Výsledkem je dynamická topologická mapa vazeb mezi aplikacemi a
infrastrukturou, díky níž je zřejmé, jaký má určitý problém, který se objeví v ostrém provozu, dopad
na činnost podniku. V konečném důsledku to znamená výrazné zkrácení doby potřebné pro řešení
daného problému, protože nástroj přímo odhalí základní příčinu problému nebo neplánovanou
změnu.
Dalším nástrojem, který firma používá je HP Change Control Management, který pomáhá
automatizovat proces řízení změn a zmírňovat riziko negativního dopadu modifikací aplikací a
infrastruktury na podnikatelské výsledky. Poskytuje jediné zobrazení všech změn, umožňuje jim
identifikovat kolize, plánovat a řídit změny na základě jejich praktického dopadu.
Společnost používá, mimo hlavního nástroje pro řízení IS/ICT, také nástroje pro podpůrné řízení a
analýzu rizik a nástroje pro modelování procesů, těmito nástroji se rozumí například „něco pro
rizika“, „něco pro modelování podnikových procesů“, vše viz níže.
41
10.4.2. Hodnocení rizik
Součástí řízení podnikové informatiky, jak již bylo řečeno v předchozích odstavcích, je také hodnocení
možných rizik. Toto hodnocení spočívá zejména v několika krocích, z nichž nejdůležitější jsou dva –
analýza (identifikace) rizik a jejich vyhodnocení. Identifikace rizik závisí především na typu a činnosti
firmy a provádí se zpravidla při zahájení nějakého projektu nebo zavedení nějaké změny – jedná se
odhalování zdrojů rizik. Vyhodnocení rizik slouží jako nástroj pro určení závažnosti dopadů hrozeb,
které by mohly nastat v případě neřešených slabin společnosti, nebo její části (v tomto případě část,
která se zabývá informatikou).
Přístupů k hodnocení rizik je hned několik, například tzv. Kvantitativní hodnocení rizik, Metoda
bodového hodnocení nebo Metoda brainstormingu.
Jako ukázku možné podoby Hodnocení rizik jsme se v této práci rozhodli použít Metodu bodového
hodnocení rizika pro projekt modernizace podnikové sítě LAN. Nejprve bylo nutno stanovit rizikové
faktory, které mohou znamenat ohrožení, dále stanovit váhy jednotlivých rizikových faktorů. Dalším
krokem je vyhodnocení rizika a nakonec zařazení rizika podle jeho procentuelního ohodnocení do
žebříčku rizik.
Příklad hodnocení rizika můžeme vidět v tabulce 3, na níž navazuje výpočet procentuelní ohodnocení
rizika.
Projekt modernizace sítě LAN
Rizikové faktory
Velikost, organizace a zkušenosti
vývojového týmu
Rozsah (aplikačních) dat
Doba trvání projektu
Realizované kontroly (audity)
Zkušenost vedení projektu
Výše nákladů na projekt
Využívání externích zdrojů
Váha
faktoru
(v)
4
Míra rizikovosti faktoru (MRF)
nízká
střední
vysoká
Celkem
(An)
1
2
3
4
5
2
3
2
4
5
4
X
8
X
X
4
6
6
16
15
8
X
X
X
X
Tabulka 3 – příklad rizika a jeho hodnocení, zdroj: autoři
A = v1 * MRF1 +…+ v7 * MRF7 = 8 + 4 + 6 + 6 + 16 + 15 + 8 = 63
࡭
૟૜
B = ‫ = ࡭ ܠ܉ܕ‬ૡ૝ = 0,75 tj. 75%
Po tomto hodnocení by následovalo zařazení rizika do žebříčku rizik. V rámci zvládání (resp. řízení)
rizik by pak bylo postupováno od nejrizikovější oblasti.
10.5.
Přínosy
Zavedením standardizovaného řízení IS/ICT má pro společnost následují přínosy:
•
•
•
•
Zpřehlednění infrastruktury
Prevence a priorizace rizik
Normované reporty o HW a SW
Včasné zjištění vznikajících problémů
42
•
•
•
Řízení změn a predikce jejich dopadu na systém
Efektivnější využití informatiky
Rychlejší předávání dat v rámci firmy
Mimo výše zmíněných, celý proces reengineeringu přinesl společnosti celou řadu dalších přínosů
např. dobře organizovaná informatika, sdílení dat a kvalitní webovou presentaci.
43
11.
Závěr
Celý tým pracoval na seminární práci se záměrem zkompletovat informace o nástrojích CASE, které
se používají, nebo mohou být použity v řízení IS/ICT firmy. Jasná terminologie, která je na začátku
práce definovaná zcela jistě vymezuje oblast, které se práce měla věnovat. Jazyk UML patří rozhodně
mezi důležité aspekty modelování pomocí nástrojů CASE, proto mu i zde byla věnována velká část.
Nutno podotknout, že nástroji CASE pak nerozumíme jen modelovací software (jako již výše zmíněný
Power Designer 15), ale celou škálu aplikací, které mají za úkol správci, nebo jiné odpovědné osobě,
usnadnit management podnikové informatiky. Ale to, aby nástroje CASE působily ve firmě efektivně
a účinně, zajistí nejen správné nastavení procesů ve firmě, ale také schopnost vybrat odpovídající
nástroj CASE a správné jeho užívání. Tato vlastnost se projeví především u velkých firem, kde jsou
velmi složité informační struktury, k jejichž správnému řízení se nástroje CASE vyloženě nabízejí.
V takových případech se pak nástroje CASE stávají účinnou součástí informačního systému firmy, a je
třeba je mít na paměti i ve strategických rozhodnutích.
Případová studie této práce se pak snažila nastínit situaci, kdy společnost inovovala veškeré procesy a
vybavení, které spadá do oblasti IS/ICT a logicky tak u ní vyvstala potřeba nově realizovaná opatření
účinně řídit. K tomu si společnost zvolila vhodný nástroj CASE, jehož hlavní charakteristiky a hlavní
principy řízení byly ve studii popsány.
44
12.
Zdroje
[1] Itg.cz [online]. 2010 [cit. 2010-12-06]. ITG. Dostupné z WWW: <http://www.itg.cz/pdf/rizeniinformatiky.pdf>.
[2] Lbms.cz [online]. 2010 [cit. 2010-12-06]. LBMS. Dostupné z WWW:
<http://www.lbms.cz/Reseni/_pdf/0101-NC-JS-Zajimave-aspekty-pouziti-CASE.pdf>.
[3] Lbms.cz [online]. 2010 [cit. 2010-12-06]. LBMS. Dostupné z WWW:
<http://www.lbms.cz/Reseni/_pdf/0101-NC-JS-Zajimave-aspekty-pouziti-CASE.pdf>.
[4] Wikipedia [online]. 7. 11. 2010 [cit. 2010-12-06]. Wikipedia. Dostupné z WWW:
<http://cs.wikipedia.org/wiki/CASE_n%C3%A1stroje>.
[5] VOŘÍŠEK, Jiří. Řízení podnikové informatiky. Katedra informačních technologií [online]. 2001, [cit.
2010-12-02]. Dostupný z WWW: <http://nb.vse.cz/~vorisek/FILES/Clanky/2001_SPSPR.htm>.
[6] Určení odpovědnosti při řízení podnikového IS/ICT. Hospodářské noviny [online]. 4. 6. 2003, [cit.
2010-12-02]. Dostupný z WWW: <http://hn.ihned.cz/c1-12891310-urceni-odpovednosti-pri-rizenipodnikoveho-is-ict>.
[7] Wikipedia [online]. 2.12.2010 [cit. 2010-12-06]. Wikipedia. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Information_technology>.
[8] Wikipedia [online]. 15. 9. 2010 [cit. 2010-12-06]. Wikipedia. Dostupné z WWW:
http://cs.wikipedia.org/wiki/Informa%C4%8Dn%C3%AD_syst%C3%A9m>.
[9] Wikipedia [online]. 2.12.2010 [cit. 2010-12-06]. Wikipedia. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Information_and_communication_technologies>.
[10] ITIL. ITIL [online]. 2007 [cit. 2010-12-04]. Historie, vývoj a přínosy ITIL. Dostupné z WWW:
<http://www.itil.cz/index.php?id=983>.
[11] IT Governance [online]. 2007 [cit. 2010-12-04]. Co je COBIT?. Dostupné z WWW:
<http://www.itil.cz/index.php?id=929>.
[12] SKÁLA, Jiří. ITIL®, CobiT® a další standardy konfrontace a vyžití v praxi. Praha, 2004. 36 s.
Elektronická prezentace. OMNICOM Praha, spol s r. o.
[13] Enterprise Architecture [online]. 2009 [cit. 2010-12-04]. COBIT. Dostupné z WWW:
<http://iea.wikidot.com/cobit>.
[14] BERAN, Jiří . Použití CASE pro řízení IS/ICT firmy. Praha, 2006. 43 s. Seminární práce. Vysoká škola
ekonomická v Praze.
[15] Thoughtcapital.us [online]. 2010 [cit. 2010-12-06]. Thought capital. Dostupné z WWW:
<http://www.thoughtcapital.us/OperationalExcellence/CMMi.html>.
[16] BENEŠ, Michal. Přehled OO metodik a notací. Praha, 2005. Diplomová práce. Vysoká škole
ekonomická v Praze. Dostupné z WWW: <http://objekty.vse.cz/Objekty/MetodikyANotace>.
45
[17] : ::36SI:: : : Softwarové inženýrství [online]. 2005 [cit. 2010-12-01]. Semestrální práce z 36SI.
Dostupné z WWW: <http://www.sicka.frikulin.net/analyza.html>.
[18] UML a OO Metodologie [online]. 6.1.2005, 18.7.2006 [cit. 2010-12-01]. UML - úvod. Dostupné z
WWW: <http://mpavus.wz.cz/uml/uml-uvod-1.php>.
[19] VOMÁČKA, Petr, et al. CASE nástroje pro UML. Semestrální práce pro předmět 4IT450. 2008.
[20] Sybase Inc. Sybase : an SAP Company [online]. 2010 [cit. 2010-12-02]. PowerDesigner Modeling
and Metadata Management Software Tool. Dostupné z WWW:
<http://www.sybase.com/products/modelingdevelopment/powerdesigner>.
[21] No Magic Inc. MagicDraw : Architecture Made Simple [online]. 2000-2010, 26. 4. 2010 [cit. 201012-02]. MagicDraw Home. Dostupné z WWW: <http://www.magicdraw.com/home>.
[22] Astah* community [online]. 2010 [cit. 2010-12-02]. Astah* Home. Dostupné z WWW:
<http://astah.change-vision.com/en/index.html>.
[23] Thoughtcapital.us [online]. 2010 [cit. 2010-12-06]. Thought capital. Dostupné z WWW:
<http://www.thoughtcapital.us/OperationalExcellence/CMMi.html>.
[24] Wikipedia. Wikipedia [online]. 2010 [cit. 2010-12-06]. Podniková architektura. Dostupné z WWW:
<http://cs.wikipedia.org/wiki/Podnikov%C3%A1_architektura>.
[25] Accenture. Accenture [online]. 2010 [cit. 2010-12-06]. Podniková architektura. Dostupné z
WWW:<http://www.accenture.com/Countries/Czech_Republic/Services/EnterpriseArchitectureDefault.
htm>.
[26] Sparx. Enterprise Architect [online]. 2010 [cit. 2010-12-06]. Enterprise Architect - UML. Dostupné
z WWW: <http://www.sparxsystems.es/New/products/ea.html>.
[27] SVOBODA, Kamil. Modelovací nástroj Enterprise Architect. Hradec Králové, 2005. 21 s. Seminární
práce. Univerzita Hradec Králové.
[28] PATOČKA, Miroslav. Řešení IS pomocí Model Driven Architecture. Brno, 2008. 84 s. Diplomová
práce. MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY.
[29] Kožusznik, J., Dotazování, pohledy a transformace v MDA, Objekty 2003, VŠBTechnická univerzita
Ostrava, s. 120 – 128, ISBN 8024802740.
[30] LeTsch online [online]. 2009 [cit. 2010-12-06]. What is MDA?. Dostupné z WWW:
<http://www.letsch.at/>.
[31] OMG - MDA [online]. 2010 [cit. 2010-12-06]. OMG Model Driven Architecture. Dostupné z
WWW: <http://www.omg.org/mda/>.
[32] KRUŽÍK, Martin. Skriptum ke státní závěrečné zkoušce z informatiky. Praha : Skriptum ke státní
závěrečné zkoušce z informatiky, 2010. 492 s.
46
[33] BUCHALCEVOVÁ , Alena. Nb.vse.cz [online]. 2010 [cit. 2010-12-06]. Agilní a rigorózní metodiky.
Dostupné z WWW:
<http://nb.vse.cz/~vorisek/FILES/4IT215_materialy_k_predmetu/MetodikyIT_Buchalcevova.ppt>.
[34] Unified Modeling Language. In Wikipedia : the free encyclopedia [online]. St. Petersburg
(Florida) : Wikipedia Foundation, 12.11.2001, last modified on 1.12.2010 [cit. 2010-12-06]. Dostupné
z WWW: <http://en.wikipedia.org/wiki/Unified_Modeling_Language>.
[35] Class diagram. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia
Foundation, 24.4.2005, last modified on 6.12.2010 [cit. 2010-12-06]. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Class_diagram>.
[36]http://www.databaseanswers.org/data_models/uml_class_diagram_for_shopping_cart/images/
uml_class_diagram_cart.gif
[37] http://www.cs.sjsu.edu/~pearce/oom/patterns2/patterns/patterns_files/image012.jpg
[38] Component diagram. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) :
Wikipedia Foundation, 29.11.2005, last modified on 29.10.2010 [cit. 2010-12-06]. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Component_diagram>.
[39] REJNKOVÁ, Petra. Příklady použití UML 2.0 [online]. 2009 [cit. 2010-12-28]. Diagram vnitřní
struktury. Dostupné z WWW: <http://uml.czweb.org/diagram_vnits.htm>.
[40] http://upload.wikimedia.org/wikipedia/commons/b/b0/Composite_Structure_Diagram.png
[41] Deployment diagram. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) :
Wikipedia Foundation, 29.11.2005, last modified on 20.10.2010 [cit. 2010-12-06]. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Deployment_diagram>.
[42]
http://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/UML_Deployment_Diagram.svg/780p
x-UML_Deployment_Diagram.svg.png
[43] Package diagram. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) :
Wikipedia Foundation, 29.10.2005, last modified on 8.10.2010 [cit. 2010-12-06]. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Package_diagram>.
[44] http://images.visual-paradigm.com/vpuml/provides/umlmodeling/package_diagram.jpg
[45] Object diagram. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia
Foundation, 10.4.2006, last modified on 14.6.2010 [cit. 2010-12-06]. Dostupné z WWW:
<http://en.wikipedia.org/wiki/Object_diagram>.
[46] http://www.itmeyer.at/umlet/uml2/img/CL_object.jpg
[47] UML Profile Diagrams [online]. 2008 [cit. 2010-12-06]. UML. Dostupné z WWW:
<http://www.uml-diagrams.org/profile-diagrams.html>.
[48] http://www.ejb3.org/pictures/profile_creation.png
47
[49] KUČEROVÁ, Helena. Info.sks.cz [online]. 2008, 31. 3. 2010 [cit. 2010-12-28]. Use Case model.
Dostupné z WWW: <http://info.sks.cz/users/ku/PRI/usecase.htm>.
[50] KUČEROVÁ, Helena. Info.sks.cz [online]. 2007, 15. 3. 2008 [cit. 2010-12-28]. Use Case model.
Dostupné z WWW: <http://web.sks.cz/users/ku/pri/uml.htm>.
[51] HRADECKÁ, Petra. Metodika pro výběr a nasazení CASE nástrojů. Praha, 2007/2008. 163 s.
Diplomová práce. Vysoká škole ekonomická v Praze.
[52] AMBLER, Martin. Nové metody řízení podnikové informatiky. IT Systems [online]. 2006, 9/2006,
[cit. 2011-01-07]. Dostupný z WWW: <http://www.systemonline.cz/clanky/nove-metody-rizenipodnikove-informatiky.htm>. ISSN 1802-615X.
48