Použití CASE pro řízení projektů IS/ICT 4IT450 2009 ‐ Jakub Holba, Radek Kollárovits, Barbora Pešková, Mirek Řezníček, Tomáš Soukup, Jan Šafránek, Petr Školník
‐2009‐
4IT 450 CASE
1 Anotace Tato práce vznikla v rámci předmětu 4IT450 CASE vyučovaném na katedře informačních technologií VŠE v Praze pod vedením prof. Řepy. Práce navazuje na výstupy našich předchůdců z minulých let a doplňuje je o aktuální informace z této oblasti. Cílem práce je v teoretické úvodní části doplnit výsledky minulých prací o pohled na CASE jako na nástroj pro řízení životního cyklu IS. V praktické části je pak práce zaměřena na možnost použití CASE nástrojů v jednotlivých fázích projektu a to jak z pohledu metodiky MMDIS, tak z pohledu metodiky ASAP. Porovnání těchto metod (nikoli však jejich detailní popis) vnímáme jako hlavní přínos naší práce.
2
‐2009‐
4IT 450 CASE
Obsah 2 Úvod .......................................................................................................................................... 5 3 Vymezení pojmů a důležitá fakta .............................................................................................. 6 3.1
Projekt IS/ICT ..................................................................................................................... 6
3.2
Řízení projektů IS/ICT ........................................................................................................ 6
3.3
Životní cyklus IS, metodika vývoje IS a řízení projektu ...................................................... 6
3.4
CASE ................................................................................................................................... 8
4 Trendy ve vývoji nástrojů řízení projektů .................................................................................. 9 4.1
Nástroje pro řízení projektů .............................................................................................. 9
4.2
Nové funkce a trendy, kterými se ubírají ........................................................................ 10
4.3
Sada nástrojů MS Project ................................................................................................ 10
4.3.1 Principy a kontrola plánů a financí projektů .............................................................. 10 4.3.2 Efektivní předávání a prezentace informací o projektech ......................................... 11 4.3.3 Rychlé zajištění produktivity ...................................................................................... 13 4.4
Sada nástrojů Primavera Project Management .............................................................. 16
4.4.1 Funkce řešení projektu ............................................................................................... 16 4.5
Porovnání nástrojů .......................................................................................................... 17
4.6
CASE nástroje v souvislosti s řízením projektů ................................................................ 17
5 Praktická část ........................................................................................................................... 18 5.1
Současné možnosti CASE nástroje PowerDesigner ......................................................... 18
5.1.1 Klasické možnosti PowerDesigneru (7) ...................................................................... 19 5.1.2 Popis produktu PowerDesigner(6) ............................................................................. 20 5.1.3 Reference ................................................................................................................... 21 5.1.4 Nové možnosti PowerDesigneru 15 (6) ...................................................................... 21 5.2
Základní principy MMDIS ................................................................................................. 22
5.2.1 Metodika MMDIS ....................................................................................................... 22 5.2.2 Pravidla multidimenzionality: (8) ............................................................................... 23 5.3
Globální podniková strategie (GST) (9) ............................................................................ 23
5.3.1 Kritické faktory úspěchu podnikatelské strategie ...................................................... 24 5.3.2 Možnosti použití CASE nástroje v této etapě ............................................................. 24 5.4
Informační strategie (IST) (9) ........................................................................................... 24
5.4.1 Možnosti použití CASE nástroje v této etapě ............................................................. 25 3
‐2009‐
5.5
4IT 450 CASE
Úvodní studie (US) ........................................................................................................... 25
5.5.1 Dílčí úkoly etapy (9) .................................................................................................... 25 5.5.2 Možnosti použití CASE nástroje v této etapě ............................................................. 27 5.6
Globální analýza a návrh (GAN) ....................................................................................... 27
5.6.1 Dílčí úkoly etapy (9) .................................................................................................... 27 5.6.2 Možnosti použití CASE nástroje v této etapě ............................................................. 27 5.6.3 Krátký popis společnosti (pro snazší pochopení diagramů) ....................................... 28 5.7
Detailní analýza a návrh (DAN) ........................................................................................ 31
5.7.1 Dílčí úkoly etapy (9) .................................................................................................... 31 5.7.2 Možnosti použití CASE nástroje v této etapě ............................................................. 32 5.8
Implementace (IM) .......................................................................................................... 34
5.8.1 Dílčí úkoly etapy (9) .................................................................................................... 34 5.8.2 Možnosti použití CASE nástroje v této etapě ............................................................. 34 5.8.3 Příklad využití CASE nástroje na skutečné implementaci IS K2 do konkrétní firmy ... 34 5.9
Zavádění systému (ZA) .................................................................................................... 36
5.9.1 Dílčí úkoly etapy (9) .................................................................................................... 36 5.10
Provoz a údržba (PU) ................................................................................................... 37
5.10.1 Dílčí úkoly etapy (11) ................................................................................................ 37 5.10.2 Možnosti použití CASE nástroje v této etapě ........................................................... 37 5.11
Vyřazení systému (VY) (9) ............................................................................................ 38
5.11.1 Možnosti použití CASE nástroje v této etapě ........................................................... 38 5.12
Porovnání MMDIS s komerční metodikou ASAP ......................................................... 38
5.12.1 Co je to ASAP / AcceleratedSAP / ASAP Focus? ....................................................... 38 5.12.2 Samostatná úvodní studie ........................................................................................ 39 5.12.3 Fáze 1 ‐ Příprava projektu ........................................................................................ 39 5.12.4 Fáze 2 ‐ Příprava cílového konceptu / Business Blueprint ....................................... 41 5.12.5 Fáze 3 – Realizace / Realization ................................................................................ 43 5.12.6 Fáze 4 – Příprava produktivního provozu / Final Preparation ................................. 43 5.12.7 Fáze 5 – Náběh a podpora produktivního provozu / Go Live and Support .............. 43 5.13
Shrnutí ......................................................................................................................... 44
6 Závěr ........................................................................................................................................ 44 7 Citovaná literatura ................................................................................................................... 46 4
‐2009‐
4IT 450 CASE
2 Úvod Poprvé byl pojem CASE použit v roce 1982 společností Nastec Corporation (Michigan, US), která jím označila svůj systém s názvem GraphiText. GraphiText byl první systém, který v sobě integroval grafický i textový editor. Zajímavá je shoda jmen jednoho ze dvou původců akronymu CASE (Computer‐ Aided System Engineering) a zakladatelů společnosti Nastec, Alberta F. Case, Jr. I přesto, že Albert Case v jednom ze svých původních článků z roku 1985 píše: „Plně uzpůsobený CASE systém se odlišuje od ostatních nástrojů, které podporují pouze jednu oblast vývoje softwaru, tím, že je v sobě obsahuje všechny.“ (1) Následníky GraphiTextu byly dva systémy DesignAid a LifeCycle Manager. První z nich vznikl pro podporu strukturovaného přístupu k analýze, designu a programování (Jackson) a Yourdonovy metodologie. Zahrnoval v sobě nástroje pro analýzu a design. Druhým systémem, který vznikl paralelně, byl LifeCycle Manager. Ten obsahoval moduly pro projektové řízení, tak jak ho chápeme dnes. Již odtud je tedy patrné, že s růstem objemu funkcionality původního CASE nástroje, došlo k oddělení samotné modelovací a řídící větvě vývoje informačního systému, které se postupem času vyprofilovaly do samostatných skupin produktů. V poslední dekádě 20. století zaznamenaly programové nástroje na podporu vývoje informačního systému ‐ CASE velkou popularitu. Tomu zajisté přispěly dva hlavní trendy, které 90. léta minulého století ve vztahu k informačním technologiím se všemi souvisejícími aspekty, charakterizují. Jedná se o bouřlivý rozvoj metodik vývoje informačních systémů (procedurálních i objektových) a reengineering podnikových procesů (BPR). To vyvolávalo stále větší požadavky na schopnost grafického ztvárnění diagramů, automatizace rutinních činností, ale i zvýšená potřeba vedení a správy projektové dokumentace V průběhu let nástroje CASE vyspěly ve velké komplexní a sofistikované systémy, které postupem času přestaly být zajímavou a marketingově hodnotnou novinkou a v současnosti je již jejich význam jiný. V následujícím textu se zaměříme na popis nástrojů CASE a jejich vazby na řízení projektů. Nejdříve však chceme objasnit některé pojmy a shrnout obecná fakta.
5
‐2009‐
4IT 450 CASE
3 Vymezení pojmů a důležitá fakta 3.1 Projekt IS/ICT V některých minulých pracích jsme se setkali s citací definice projektů z normy ISO 10006 nebo PMBOK. Ve vztahu k tématu naší práce nám ale jako nejlepší definice projektu IS/ICT přišla definice Ing. Dušana Chlapka, PhD. : „Projekt IS/ICT je řízená skupina činností vyvolaná za účelem pořízení nebo adaptace (změny) IS/ICT, směřující k dosažení předem určených cílů. Projekt končí předáním produktů do užívání“. (2) V této definici je pro nás stěžejní slovíčko „pořízení IS/ICT“. Pořídit IS/ICT lze podle prof. Voříška několika způsoby. Prvním jednodušším způsobem je pořízení nebo dodání tzv. TASW, typického software nebo také krabicového software. V tomto případě se vývojový (životní) cyklus informačního software pro nás eliminuje více méně pouze na implementaci a testování, tedy na fáze, ve kterých nástroje CASE standardně nevyužíváme nebo ve kterých by bylo ekonomicky nevýhodné CASE nástroje vzhledem k jejich ceně zakupovat. A proto není tato možnost v další části reflektována. (3) Druhým způsobem pořízení IS/ICT je vývoj vlastního IASW, tedy softwaru vytvořeného přímo na míru našim požadavkům a potřebám. Zde je již třeba reflektovat všechny fáze vývoje informačního systému a použití CASE nástrojů je v dnešní době zvyšující se složitosti informačních systémů téměř nutné. V další části práce se tedy pojmem projekt IS/ICT bude rozumět vývoj informačního systému. Dále konstatujeme, že outsourcing také dále nereflektujeme.
3.2 Řízení projektů IS/ICT Stejně jako autoři předchozích prací chápeme řízení projektů jako „plánování, organizování a vedení činností a zdrojů za účelem dosažení definovaných cílů. Nejčastěji se potýká s časovými a finančními omezeními a s omezeními zdrojů. Mezi hlavní činnosti řízení projektů patří zejména plánování, organizování, delegování, motivování, řízení času, zdrojů, financí a nákladů, komunikace, kvality, řízení změn, rizik a rezerv a dále hodnocení a kontrolování.“ (13) Vše výše zmíněné však by mělo být chápáno v souvislosti s projektem IS/ICT, zejména pak s přihlédnutím k vybrané metodice vývoje informačního systému, životnímu cyklu informačního systému a konkrétního CASE nástroje. Přesněji tedy řízení projektů vývoje IS/ICT.
3.3 Životní cyklus IS, metodika vývoje IS a řízení projektu V pracích z minulých let jsme se dočetli, že CASE nástroje souvisí s metodikami a životním cyklem informačního systému. Považujeme však za vhodné zde tuto problematiku rozvést. Pojem „životní cyklus informačního systému“ je svázán s každou konkrétní metodikou vývoje informačního systému. A v každé je chápán trochu jinak. V literatuře neexistuje jednotný přístup k definování a chápání základního pojmu životní cyklus vývoje informačního systému. Obecně se dá ale říci, že při určité míře abstrakce každá metodika obsahuje základní vývojový cyklus fáze zadání, analýzy, návrhu, implementace, testování a provozu. Životní cyklus informačního systému je pak základním východiskem veškerých úvah v metodikách. Příkladem může být nám dobře známá metodika MMDIS.
6
‐2009‐
4IT 450 CASE
Obrázek 1 ‐ Metodika MMDIS (4)
Prof. Řepa píše, že v závislosti na použití konkrétní metodiky vývoje informačního systému se odvíjí jednotlivé potřebné dokumenty, cíle a specifika řízení projektu. Jednotlivé metody, techniky a nástroje jsou metodikou vázány vždy k jednotlivým etapám a fázím životního cyklu IS. Začátky a konce etap a fází vývoje IS jsou tak základními klíčovými body postupu (tzv. milníky), v nichž metodika určuje způsob řízení postupu vývoje IS. Dále konstatuje, že: „Konkrétní metodika by měla u každé etapy stanovit kromě jiného doporučené techniky a nástroje (techniky, které se v činnosti používají, jejich možná podpora a ostatní nástroje vývoje IS).“ (4) Metodika nepopisuje postup vývoje informačního systému do nejmenšího detailu. Nepopisuje ani jeho veškeré možné varianty, metody a techniky. Ale všímá veškerých podstatných aspektů tohoto procesu a postihuje proces vývoje IS od samého začátku až do případného konce.
7
‐2009‐
4IT 450 CASE
Obrázek 2 ‐ Životní etapy informačního systému VS etapy postupu projektu (4)
Je zřejmé, že obecný životní cyklus vývoje informačního systému, daný metodikou vývoje IS a obecné schéma postupu, dané metodikou řízení projektu jsou věci, které na jednu stranu musí platit současně, ale přitom jsou na druhou stranu zcela různé. Proto je vždy v procesu rozlišovat mezi metodikou vývoje IS stanovenými) věcnými činnostmi projektu a metodikou řízení projektů stanovenými činnostmi jejich řízení což je vidět na obrázku 2. Problematika životního cyklu informačního systému a metodik je v naší práci zařazena, protože s nástroji CASE úzce souvisí. Některé nástroje CASE je totiž lepší použít v jiných fázích životního cyklu IS. Pro podrobnější informace odkazujeme na specializovanou literaturu.
3.4 CASE Podle Alberta Case byla ve svém počátku CASE „technologie, která pomáhala softwarovým a systémovým vývojářům dosáhnout jejich cílů, tím, že jim poskytla všechny nástroje potřebné pro vývoj v jedné integrované podobě.“ (1) Čímž také zvyšovala produktivitu vývoje systému. Ta je podle Case daná dvěma složkami ‐ efektivitou a kvalitou, viz obr.3.
8
‐2009‐
4IT 450 CASE
Obrázek 3 ‐ Zvýšení produktivity (1)
Na obr. č.3 jsou patrné dvě křivky P, ty charakterizují dvě produktivity vývoje informačního systému. Produktivita vývoje je na obrázku dána dvěma složkami: efektivitou a kvalitou vývoje informačního systému. Pokud chceme při vývoji informačního systému dosáhnout jeho vysoké kvality (resp. minimalizovat chyby), zákonitě se musí snížit efektivita jeho vývoje (resp. jeho vývoj bude pomalejší). Při použití nástrojů CASE při vývoji informačního systému se tato křivka posouvá směrem který je patrný na obr.3 a dochází k paretovu zlepšení produktivity vývoje informačního systému. Produktivita vývoje informačního systému se přesunula z bodu A do bodu B a došlo ke zlepšení obou jejích složek. V současnosti je používán termín CASE spíše ve spojení přímo s CASE nástroji. Na základě analýzy prací z minulých let a konkrétních nástrojů může být tento pojem definován jako: „Skupina softwarových nástrojů zaměřených na podporu vývoje informačních systémů. Jedná se o sadu nástrojů podporujících určité fáze vývoje, především pak analýzu a návrh“. (13) Definice CASE nástrojů již ale nemusí být přesná, protože rozdíly mezi CASE nástroji, vývojovými nástroji a třeba generátory kódů se stírají. Tudíž podmínka, kterou stanovil Albert Case v jeho definici, resp. podmínka, že všechny tyto nástroje by měly být integrované do jednoho, již dnes není tolik akcentována. To je dle našeho soudu způsobeno příliš náročnými požadavky při vývoji moderních projektů IS/ICT, na to aby byly uspokojeny, v již dnes velmi komplikovaných a sofistikovaných CASE nástrojích. A tak většina uživatelů dává přednost specializovaným produktům před univerzálními. Obzvláště v projektovém řízení, kde jednoznačně zatím vládne MS Project.
4 Trendy ve vývoji nástrojů řízení projektů 4.1 Nástroje pro řízení projektů Asi nejznámějšími nástroji pro řízení projektů jsou Microsoft Office Project a Primavera Project Management. Oba nástroje nabízí efektivní prostředí pro řízení projektů s výhodným poměrem 9
‐2009‐
4IT 450 CASE
využitelnosti, účinnosti a flexibility, který zajišťuje efektivnější a účinnější vedení projektů. Zajišťují stálou informovanost a kontrolu nad prací na projektu, plány a financemi. MS Project pomáhá zachovat informovanost a vyšší produktivitu projektových týmů díky integraci se známými aplikacemi systému Microsoft Office. Primavera zase naopak oplývá plně webovým rozhraním pokrývající celý životní cyklus projektu od jeho zahájení až po ukončení.
4.2 Nové funkce a trendy, kterými se ubírají Stejně tak, jako každá nová verze programu, i MS Project 2007 i Primavera Project Management přinášejí několik nových funkcí a vylepšení. Tyto funkce přinášejí nové možnosti v řízení projektů a zároveň určují směr, kterým se budou dané nástroje z této skupiny ubírat. V následující části jsou popsány novinky obou výše zmíněných nástrojů.
4.3 Sada nástrojů MS Project (14) 4.3.1
Principy a kontrola plánů a financí projektů Uživatel má možnost účinně sledovat a analyzovat projekty díky lepšímu porozumění plánu a dopadu změn. Přínosem je lepší kontrola financí a možnosti analýzy. Mezi nové funkce tohoto nástroje se řadí: Sledování zdrojů problémů: Umožňuje uživateli rychle určit faktory ovlivňující data úkolů a snadno sledovat zdroj problémů, aby se zvýšila zodpovědnost a kvalita. Ovladače úkolů pomohou určit faktor (například závislost úkolů, omezení kalendáře, datum plánování nebo volný čas) určující datum zahájení úkolu, takže můžete zpětně sledovat řadu faktorů a zjistit tak základní příčinu konkrétního zpoždění. Sledování dopadů změny: Aplikace Office Project 2007 automaticky zvýrazní všechny položky, které se odsouvají v důsledku naposledy provedené změny. Zvýraznění změn umožňuje lépe porozumět dopadům změn. Experimentování se scénáři citlivostních analýz: Pomocí příkazů Zpět a Znovu může uživatel vracet zpět změny pohledů, dat a možností na více úrovních. Může vracet zpět akce nebo skupiny akcí včetně maker a vyzkoušet tak několik scénářů citlivostních analýz.
10
‐2009‐
4IT 450 CASE
Obrázek 4 ‐ Ukázka analýzy scénáře
Snadná kontrola financí: Pomocí pole rozpočtu může uživatel přiřazovat rozpočty k projektům a programům. Nový typ nákladového zdroje vylepšuje odhady a sledování nákladů. Mezi další vylepšení nákladů patří více předdefinovaných polí (například kód nákladů), která se mapují na finanční pole sledovaná v účetních systémech projektu. Flexibilní sledování a analýzy projektů: Definováním vlastních polí založených na vzorcích umožňuje vypočítat a sledovat základní měřítka jedinečná pro daný projekt. Grafické indikátory navíc mohou upozornit na splnění konkrétních podmínek. 4.3.2
Efektivní předávání a prezentace informací o projektech Uspořádání a organizaci projektů a lidí je možno vylepšit díky plánování nabízenému aplikací Office Project Standard 2007. Lze snadno vykazovat a sdělovat informace v různých formátech podle potřeb zúčastněných stran. Použití grafů a diagramů: Funkce Vizuální sestavy využívá aplikace Microsoft Office Excel a Microsoft Office Visio Professional k vytváření kontingenčních tabulek, grafů, diagramů a přehledů založených na datech aplikace Project. Uživatel může snadno definovat vlastní šablony sestav a sdílet je s ostatními uživateli aplikace Project.
11
‐2009‐
4IT 450 CASE
Obrázek 5 ‐ Použití grafů a diagramů
Přidání zvýraznění: Barvu pozadí buňky nebo řádku lze změnit pomocí funkce Zvýraznění pozadí buněk. Stínováním buněk, jež se provádí podobně jako v aplikaci Excel, lze projektu dodat další význam.
Obrázek 6 ‐ Zvýrazňování
Použití vylepšeného zobrazení: Díky novým vylepšením rozhraní kalendáře a přidáním prostorových pruhů Ganttova diagramu lze vytvořit nové a alternativní sestavy. 12
‐2009‐
4IT 450 CASE
Sdílení informací: Ke sdílení a správě dokumentů souvisejících s projekty slouží pracovní prostory služby Microsoft Windows SharePoint Services (vyžadují Microsoft Windows Server 2003 nebo novější). 4.3.3
Rychlé zajištění produktivity
Aplikace Office Project 2007 pomáhá lépe zorganizovat práci i tým a zajistit, aby projekty byly dodány včas a v rámci rozpočtu. Postup podle Průvodce projektem: V průvodci projektem je k dispozici interaktivní návod, který pomáhá nastavit projekty, řídit úkoly a zdroje, sledovat stav a vykazovat projektové informace.
Obrázek 7 ‐ Průvodce projektem
Získání nápovědy: Integrovaná online nápověda slouží k získání dalších školení, článků, šablon a zdrojů. Při práci uživatel získá včasnou a relevantní pomoc díky značkám upozorňujícím na alternativy při provádění změn plánu. Úspora času díky šablonám: Lze vytvářet vlastní šablony použitelné některou z mnoha nových předdefinovaných šablon. 13
‐2009‐
4IT 450 CASE
14
‐2009‐
4IT 450 CASE
Obrázek 9 ‐ Rozpis přiřazení nákladů úkolu v aplikaci MS Project
Obrázek 10 ‐ Úpravy sazby zdroje v aplikaci MS Project Obrázek 8 ‐ Příprava rozkladu úkolů projektu v aplikaci MS Project
15
‐2009‐
4IT 450 CASE
4.4 Sada nástrojů Primavera Project Management (15) 4.4.1
Funkce řešení projektu
Project Initiation: Funkce Project Initiation pomáhá eliminovat prodlení, které je spojeno s délkou procesu schvalování. Řešení zajišťuje, aby při zahájení projektu nastoupil konfigurovatelný proces schvalování.
Obrázek 11 ‐ Inicializace projektu v Primavera Project Management
Laverage Best Practises: Poskytuje knihovnu předem vytvořených a katalogizovaných šablon, které umožňují rychleji a přesněji vytvářet projektové plány a které organizacím umožňují úspěšně a opakovaně využívat znalosti svých odborníků na konkrétní oblasti. Interactive Web Gantt Chart: Interaktivní webový Ganttův diagram umožňuje přidávat, mazat a měnit strukturu WBS, činnosti, vztahy, přidělení prostředků a náklady. CPM Scheduling: Umožňuje plánovat projekt z prostředí Web Project Management, které je součástí řešení. Issues Management: Protokol zaznamenávající problémy, který umožňuje uživatelům přidávat a aktualizovat problémy. Threaded Discussions: Portlety pro diskusi a spolupráci umožňují uživatelům online konverzaci ohledně projektů, aktivit nebo problémů. Project Cost Tracking: Součást Primavery vytvořený pro sledování původního rozpočtu, aktuálního užívání k danému datu a nevyřízených úkolů. Centralized Document Management: Sloužící pro ukládání projektových dokumentů souvisejících s činnostmi, problémy, online diskusemi nebo pozvánkami na zasedání projektového týmu. Směrování dokumentů pro účely kontroly, správa verzí a historie dokumentů. 16
‐2009‐
4IT 450 CASE
Baselines: Funkce Baselines zachycuje původní plán projektu a umožňuje, aby si celý tým byl vědom svého výkonu. Vyhodnocuje klíčové indikátory výkonu, jako jsou odchylky a dosažená hodnota. Project Reports: Umožňuje vybrat z více než 150 předem definovaných sestav a neomezeného počtu uživatelských sestav. Dashboards: Konfigurovatelné tabule typu „dashboard“ k projektu mohou zobrazovat až 30 různých typů portletů, přičemž každý může obsahovat různé klíčové indikátory výkonu (KPI).
4.5 Porovnání nástrojů Na druhou stranu jsou dnes znovu patrné tendence o integraci podpůrných nástrojů zaměřených na související činnosti, jakými jsou např. řízení projektů. CASE nástroje mají jednoznačně své pevné místo v projektových týmech, zvláště dnes při rostoucí složitosti navrhovaných programů a softwarových řešení. Co se funkčnosti nástrojů týče, tak trendem v této oblasti je přinést uživateli, co možná nejvíce funkcí pro ulehčení řízení projektu a zároveň snaha o minimalizaci chybovosti lidského faktoru při řízení. Směr, kterým se ubírají oba výše zmíněné produkty, jsou ve své podstatě podobné. Hlavním rozdílem je způsob přístupu a to lokálně v případě MS Project a přes webové rozhraní v případě Primavera Project Management.
4.6 CASE nástroje v souvislosti s řízením projektů Co se týká podpory řízení projektů CASE nástrojem, prof. Řepa ji vidí převážně v těchto oblastech: Podpora týmové práce (definování různých rolí, řízení přístupu, verzování komponent, sdílená repository apod.) CASE jako nástroj řízení životního cyklu informačního systému (tak jak jsme ho popsali výše) CASE jako nástroj pro řízení portfolia projektů Podle životního cyklu vývoje software lze CASE nástroje rozdělit do následujících skupin: Pre CASE – podporují tvorbu globální strategie. Upper CASE – podporují plánování, specifikaci požadavků, modelování organizace podniku a globální analýzu IS. Hlavním úkolem nástroje je analýza organizace, zachycení procesů v organizaci, definice klíčových informačních toků a dokumentace zjištěných požadavků. Middle CASE – podporují podrobnou specifikaci požadavků a vlastní návrh systému. Tato třída CASE nástrojů je nejúspěšnější. Používají se pro podrobnou specifikaci požadavků, návrh systému, dokumentaci a vizualizaci systému. Dále CASE nástroje této kategorie obsahují systém 17
‐2009‐
4IT 450 CASE
správy dokumentů a konfigurace, systém pro vyhodnocování metrik, vývoj prototypů, návrh rozhraní. Mohou obsahovat také generátory obrazovkových formulářů a tiskových sestav a také generátory (kostry) definic dat. Tento druh CASE je jádrem komerčně dodávaných CASE systémů. Lower CASE – obsahují nástroje pro podporu kódování, testování, údržby a reverzního inženýrství. Integrovány jsou nástroje, jako jsou generátory kódu (mohou generovat jen kostru nebo až 75 procent výsledného kódu, kde programátor doplňuje většinou jen detaily). Dále pak jde o prostředky pro reverse engineering (rekonstrukce dokumentace a modelů z existujícího SW), prostředky pro sledování a vyhodnocení metrik, prostředky plánování a zjištění kvality SW (sběr informací o průběhu testování, vyhodnocení výsledků testů, řízení testování), pro správu konfigurace, prostředky sledování a vyhodnocování práce systému. Post CASE – podporuje organizační činnosti (zavedení, údržbu a rozvoj IS).
Obrázek 12 ‐ Životní cyklus vývoje SW
5 Praktická část V praktické části této práce se pokusíme objasnit, ve kterých fázích životního cyklu IS je vhodné využívat možností CASE nástrojů, a pro které z nich naopak jejich využití možné není. Pro ukázky použití CASE nástrojů v jednotlivých etapách vývoje IS jsme využili nástroj PowerDesigner.
5.1 Současné možnosti CASE nástroje PowerDesigner PowerDesigner je vyvíjen společností Sybase a patří do skupiny produktů, které se zaměřují na Enterprise Architecture. Úkolem tohoto CASE nástroje je anlalýza, modelování a optimalizace firemních procesů. V současné době je aktuální verze 15, která navazuje na svého předchůdce verzi 12 (verze 13 a 14 byly z obchodních důvodů společností Sybase přeskočeny). Jaké jsou tedy možnosti tohoto nástroje? (5)
18
‐2009‐
4IT 450 CASE
5.1.1
Klasické možnosti PowerDesigneru (7) Hlavní využití PowerDesigneru je při analýze informačního systému. Jeho hlavní předností je datové modelování, ovšem nabízí moduly zabývající se procesní analýzou či objektovým modelováním. Slouží k modelování vyvíjeného systému nejen podle strukturovaných metod (Data Flow diagram, datový model, tvorba datového slovníku apod.), ale i použitím objektového přístupu. Již samozřejmostí je podpora jazyka UML a 3‐úrovňová architektura (konceptuální, logická a fyzická). Pro práci v týmu, která je ve většině případů naprosto stěžejní, nabízí PowerDesigner úložiště modelů – repository. Ta je řešena v relační databázi a umožňuji i vzdálený přístup. Nyní několik klíčových charakteristik: 5.1.1.1 Modelovací techniky(6) ‐
Modelování business procesů (BPM)
‐
Datové modelování o
‐
XML modelování o
‐
Modelování založené na principu tří architektur a modelování datových skladů. Podpora Javy, XML a webových služeb v databázích
Podpora XML DTD a Schema elementů
Objektové modelování ‐ modely vycházející z UML 1.x a 2.0, široké možnosti úprav podle potřeb uživatelů
Podporované platformy ‐
Procesy o
‐
RDBMS o
‐
Obousměrný engineering pro téměř 60 relačních databází včetně nejnovějších verzí Oracle, IBM DB/2, MS SQL Server, Sybase
Objektové jazyky o
‐
BPMN, ebXML, BPEL4WS, podpora SOA
Obousměrný engineering pro jazyky Java, C#, C++, PowerBuilder, XML, VB.NET (viz obrázek 2)
Integrace při vývoji o
Plug‐iny pro synchronizaci kódu s modelem v nástrojích Eclipse, PowerBuilder a Visual Studio 19
‐2009‐
4IT 450 CASE
Obrázek 13 ‐ Výběr process language
Obrázek 14 ‐ Výběr object language
5.1.2
Popis produktu PowerDesigner(6) Nová verze dává podnikovým architektům, IT analytikům a obchodním manažerům možnost vylepšit propojení IT a firemních cílů. To vše díky nové technologii LINK AND SYNCH. Kromě toho Sybase 20
‐2009‐
4IT 450 CASE
PowerDesigner 15 vylepšuje analýzu dopadu a tím zajistí lepší informovanost všech účastníků procesu bez ohledu na jejich technické znalosti. 5.1.3
Reference „Pro obchodní stratégy, projektanty a analytiky má nová verze nástroje značný přínos. Pomáhá jim lépe pochopit komplexní systém IT zdrojů a jeho podporu obchodní činnosti,“ píše Greta Jamesová, viceprezidentka Gartner* nezávislé společnosti pro výzkum a poradenství. V dnešních složitých IT prostředích musí společnosti přesně přizpůsobit různé IT komponenty (systémy, data, aplikace a síť) obchodním cílům, procesům a požadavkům. Analýza každé komponenty se provádí odděleně. PowerDesigner odstraňuje nevýhodu oddělené analýzy a vzájemným propojením analyzovaných komponent zajistí možnost rychle reagovat na změny. V důsledku toho je společnost mnohem operativnější a reaguje na cíle jednotlivých obchodních jednotek. Nástup Podnikové/Enterprise architektury je důkazem toho, že pro organizace je nevyhnutelné reagovat na změny v konkurenčním prostředí, technologiích a legislativních nařízeních. Tyto změny je nutné promítat do všech částí firmy. Unikátní technologie Link and Synch obsažená v aplikaci PowerDesigner 15 dává organizacím možnost realizovat řešení podnikové architektury od začátku až do konce, takže odstraní oddělení obchodní analýzy a analýzy metadat. Tím se zvýší operativnost celého podniku. Operativnost je mimořádně důležitá v případě obchodních změn. Stále více firem přechází na strategii Unwired Enterprise a přesunuje informace blíže ke koncovým uživatelům, proto roste důležitost technologií, které zajišťují lepší řízení IT infrastruktury. PowerDesigner 15 umožňuje snížit celkové náklady a eliminovat nadbytečné systémové kroky, což z něj dělá velmi výkonný nástroj pro modelování a správu metadat. Nová verze umožňuje snadnou analýzu a měření dopadu mezi současným stavem a cílovým stavem a zajišťuje přesné, předvídatelné a spolehlivé plánování IT zdrojů v souladu s obchodními cíli(5). 5.1.4
Nové možnosti PowerDesigneru 15 (6) Co můžeme získat u poslední verze PowerDesigneru? Jaké nové funkce přináší? Můžeme zaznamenat, že většina změn je spíše kosmetických – jedná se o vylepšení stávajících funkcí, žádné revoluční inovace v nové verzi nenalezneme. Přesto bychom zmínili následující tři vylepšení: ‐
technologie Link and Synch ‐ zachycuje průniky mezi všemi vrstvami architektury podniku, což umožňuje uživatelům ze všech skupin vizualizovat a zavádět změny.
‐
webový prohlížeč úložiště modelů ‐ je možné sdílet modely podnikové architektury mezi všechny zainteresované pracovníky bez ohledu na jejich softwarové vybavení, zobrazovat diagramy, prohledávat repository nebo sdílet metadata
21
‐2009‐
4IT 450 CASE
‐
Editor podnikové architektury: PowerDesigner 15 poskytuje jak standardní metodickou šablonu modelů (metodika FEAF) tak možnost vytvoření vlastní šablony.
‐
diagram analýzy dopadů – vizualizace kaskádového dopadu změn, řízení času i nákladů souvisejících se změnou
‐
Nový import z Visio: Dává možnost využít obchodních metadat pro začlenění do kompletní podnikové architektury.
5.2 Základní principy MMDIS 5.2.1
Metodika MMDIS MMDIS neboli Multidimensional Management and Development of Information Systém je metodika vyvíjena od začátku 90. let na katedře informačních technologií VŠE. Jejím hlavním propagátorem je profesor Voříšek. Cílem této metodologie je vývoj a údržba komplexního integrovaného IS, který optimálně podporuje podnikové cíle a procesy. MMDIS patří do skupiny globálních metodik se střední váhou. Využití nalezne například při vývoji nebo rozšíření nových aplikací či služeb, integrace aplikací či služeb, customizace a implementace typového řešení a v dalších situacích. MMDIS má několik fází (8): ‐
Globální podniková strategie (GST)
‐
Informační strategie (IST)
‐
Úvodní studie (US)
‐
Globální analýza a návrh (GAN)
‐
Detailní analýza a návrh (DAN)
‐
Implementace (IM)
‐
Zavádění systému (ZA)
‐
Provoz a údržba (PU)
‐
Vyřazení systému (VY)
Hlavní myšlenkou je ovšem právě rozdělení na několik pohledů (dimenzí), kterými můžeme na projekt nahlížet: ‐
Software ‐ programové vybavení systému, určuje typ, parametry a vzájemné vazby jednotlivých komponent
22
‐2009‐
4IT 450 CASE
‐
Hardware ‐ technické vybavení systému, určuje typy, parametry a počty počítačů, periferních zařízení a komunikačních sítí
‐
Funkce a procesy ‐ zaměřena na procesy probíhající v podniku a jejich možnou podporu IS
‐
Organizační a legislativní ‐ zákony, normy a směrnice, které musí IS respektovat, organizační strukturu podniku platnou v době provozu jednotlivých verzí IS
‐
Ekonomická ‐ zahrnuje finanční náklady na tvorbu a provoz IS, časový harmonogram plateb
‐
Datová ‐ jaké typy informací jsou potřebné pro podnikové funkce, jaký obsah a jakou strukturu bude mít datová základna, a jak budou dané informace fyzicky uloženy
‐
Pracovní, sociální a etická ‐ potřebné znalosti zaměstnanců, partnerů i zákazníků
Základem metody MMDIS je 11 základních principů – multidimenzionalita, vrstvenost, integrace, flexibilita, otevřenost, standardizace, kooperace, procesní pojetí, učení a růstu, lokalizace zdrojů a rozhodnutí a měřitelnost(12). 5.2.2
Pravidla multidimenzionality: (8) ‐
Identifikuj všechny dimenze ovlivňující řešení problému
‐
Vyřeš problém nejdříve z pohledu každé definované dimenze
‐
Integruj separátní řešení do výsledného řešení (kombinace dimenzí a optimalizace)
Základem metodiky MMDIS je tedy nahlížení na řešený problém z několika pohledů, což nám pomůže lépe si vytvořit následně celkový nástin problému. Využití CASE nástrojů pro řízení projektů je poměrně obtížné a to z důvodu absence možnosti zachycení časové linky projektu. Vezmeme‐li však v potaz problematiku řízení projektu vývoje IS/ICT, pak mají CASE nástroje pro řízení takového typu projektu své neodmyslitelné uplatnění.
5.3 Globální podniková strategie (GST) (9) 23
‐2009‐
4IT 450 CASE
‐
Určuje hlavní zaměření podniku
‐
Stanovuje podnikové cíle, kterých má být v daném období dosaženo a jejich prioritní uspořádání
‐
Definuje zdroje, které budou k dispozici pro realizaci cílů
‐
Definuje způsob ověřování plnění stanovených cílů podniku
‐
Určuje osoby odpovědné za dosažení jednotlivých vytyčených cílů
‐
Zpracovává se pro střednědobý časový horizont
‐
Podléhá změnám v závislosti na změnách vnějších a vnitřních podmínek firmy
‐
Bývá v pravidelných periodách hodnocena a aktualizována
5.3.1
5.3.2
Kritické faktory úspěchu podnikatelské strategie ‐
Faktory (měřitelné) jejichž naplnění je měřítkem úspěšnosti podnikatelské strategie
‐
Naplnění každého z nich je podmínkou nutnou pro podnikatelský úspěch
‐
Naplnění všech faktorů je podmínkou postačující
Možnosti použití CASE nástroje v této etapě
Jak z popisu vychází, globální strategie podniku je rozsáhlý dokument, který vytváří sama firma (zákazník). Tato etapa předchází samotnému řízení projektu IS/ICT a je nezbytná pro kvalitní průběh implementace. V této etapě zpravidla nebývá žádný CASE nástroj využíván.
5.4 Informační strategie (IST) (9) ‐
Poskytuje základní strategický rámec pro vývoj IS
‐
Stanovuje cíle a předpoklady pro aplikaci IS v podniku
‐
Stanovuje priority a plánů projektů, odhady času, zdrojů, přínosů v krátkodobém a střednědobém časovém horizontu
‐
Obsahuje architekturu IS/IT : o
Síť komponent IS/IT v podniku
24
‐2009‐
4IT 450 CASE
o
Pohled na IS/IT v podniku jako na celek
o
Současný stav
o
Cílový stav
o
Plán přechodu ze současného do cílového stavu (9)
5.4.1
Možnosti použití CASE nástroje v této etapě Informační strategie je stejně tak jako podniková strategie tvořena zákazníkem. Použití CASE nástroje v této etapě není vyloučeno. K jeho využití však v této fázi dochází zejména pro grafické zachycení globálního pohledu na IS/ICT. (10)
Zákazníci
Aplikační server
Webový server
Internet
Databázový server
Zaměstnanci
Obrázek 15 ‐ Globální náhled na architekturu IS/ICT
5.5 Úvodní studie (US) 5.5.1
Dílčí úkoly etapy (9)
•
Analýza současného IS o
Vymezení hranic systému
o
Popsání problémů současného IS
o
Analýza požadavků na změny 25
‐2009‐
o
•
Výkonnost, přání a požadavky uživatelů, priority změn, omezení, bezpečnost IS
Detailní stanovení požadavků na nový systém o
Organizační požadavky
o
Technologické a uživatelské rozhraní
o
Ekonomické prostředí
•
Definování cíle řešení
•
Zpracování koncepce systému
•
4IT 450 CASE
o
Hranice systému
o
Hlavní funkce, vstupy a výstupy
o
Hrubý datový model
Návrh alternativ pro realizaci o
Hrubý návrh realizace
o
Zvážení technologických, ekonomických, sociálních, organizačních a politických vlivů
o
Přizpůsobení dostupným technologiím a existujícím systémům
•
Stanovení kriterií pro hodnocení alternativ realizace
•
Bezpečnost, spolehlivost, pružnost, doby odezvy
•
o
Náklady, nároky na rekvalifikaci, zdroje, jednoduchost zavedení
o
Technické nároky (základní HW studie)
o
Vliv na změny organizační struktury, apod.
Hodnocení alternativ dle stanovených kriterií o
Studie realizovatelnosti jednotlivých koncepcí řešení
•
Výběr varianty řešení a následné zdůvodnění
•
Prezentace vybraného řešení (a zdůvodnění výběru) vedení podniku
•
Rozhodnutí vedení organizace o realizaci projektu
•
Rozhodnutí o způsobu realizace (interní vývoj x outsourcing)
•
Vytvoření plánu pro analýzu, implementaci a zavedení 26
‐2009‐ 5.5.2
4IT 450 CASE
Možnosti použití CASE nástroje v této etapě
Tato etapa již plně spadá do řízení projektů IS/ICT a vypracovává ji specializovaný projektový tým. V této fázi je však užití CASE nástroje zejména pro tyto 4 aspekty: 1) Zpracování hrubých modelů pro účely ověření návrhu základních zákonitostí 2) Seznámení zainteresovaných stran s požadavky na systém a základními zákonitostmi systému 3) Znázornění využití systému a kontextu systému v prostředí externích systémů a komponent 4)Výchozí ověření proveditelnosti implementace IS
5.6 Globální analýza a návrh (GAN) 5.6.1 •
Dílčí úkoly etapy (9) Zpodrobnění požadavků na systém, zjištěných v ÚST
•
Úplná specifikace hlavních funkcí systému
•
Specifikace (a kvantifikace) dat
•
Oddělení konceptuálních, technologických a implementačních požadavků
•
Jde o konceptuální úroveň analýzy a návrhu systému o
Co musí aplikace vykovávat (hlavní funkce)
o
Které datové objekty jsou podstatné
o
Jaké jsou vlastnosti objektů a funkcí
•
Vytvoření struktury systému a subsystémů
•
Návrhy rozhraní: systém <‐> jiné systémy, mezi subsystémy
•
Konkretizace schvalovacích procedur pro jednotlivá dílčí řešení
•
Další rozpracování plánů testů vyplývajících ze znalosti vstupů a výstupů, akceptační testy
5.6.2
Možnosti použití CASE nástroje v této etapě V této fázi vývoje IS je využití CASE nástroje prakticky nezbytné. Bez kvalitního namodelování jednotlivých procesů apod. nelze projekt IS kvalitně implementovat. Vypracování tohoto dokumentu je při řízení projektů stěžejní. Pomocí CASE nástroje v této fázi můžeme dokumentovat např. klíčové a ostatní procesy, zpracovat objektový model či kontextový diagram. Při řízení projektu je v této fázi nezbytné dbát na to, aby byla zachycena všechna specifika funkčnosti dané firmy. Vhodné je pro snazší koordinaci projektu využívat repositury. 27
‐2009‐
4IT 450 CASE
Použití CASE nástroje je v této fázi demonstrováno na projektu fiktivní firmy 1. Česká letištní. 5.6.3
Krátký popis společnosti (pro snazší pochopení diagramů) Společnost 1. Česká letištní s r.o. (dále jen 1ČL) se orientuje na trhu jako správce letiště v Praze. Její zaměření je jak na nákladní dopravu, kde firma patří mezi největší společnosti v oblasti, tak i na přepravu cestujících. Roční objem materiálu, jenž letiště přijme a odbaví, se počítá v desítkách tisíců tun, oproti tomu množství cestujících, jež projdou letištěm, se blíží k 1 mil. Společnost nabízí v oblasti nákladní dopravy další dodatečné služby jako krátkodobé uskladnění materiálu, servis letadel v případě vzniku poruchy letadla, dotankování paliv apod. Dále jsou nabízeny k pronájmu celé sklady na letišti, které si rezervují jednotliví zákazníci, což jsou letečtí přepravci, kurýři a jim podobné společnosti zabývající se přepravou materiálu. Cestující naopak mohou využít veškerých komfortních služeb letiště např. taxi služby, ubytování přímo na letišti, VIP salónky, restaurace, balení zavazadel, parkování auta apod. Hlavní business společnosti se dělí na dvě klíčové oblasti: Přeprava osob – letiště z každého cestujícího získává peníze ve formě bezpečnostních a letištních poplatků, další služby se týkají samotných leteckých společností, které platí poplatky za: možnost vůbec dosednout na letiště, pozemní služby, catering a úklid (pokud je zajišťován letištěm), zaparkování letadel, použití autobusů k dopravě osob do letadla apod. Material handlingu ‐ letiště je tranzitní uzel, jež přijímá, uskladňuje, zabezpečuje a opět předává zboží dále. Přepravce tak platí letišti za každé uskladnění zboží či pronájem hal apod. Ukázka jednotlivých diagramů: 5.6.3.1 Class diagram Tento diagram zachycuje hlavní analyzované entity a dále je rozšířen o doplňující entity, které jsou potřeba pro upřesnění kompletního datového modelu.
28
‐2009‐
4IT 450 CASE
Obrázek 16 ‐ Class diagram ‐ letištní společnost (9)
5.6.3.2 Procesní diagram 29
‐2009‐
4IT 450 CASE
‐ Diagram zachycuje monitoring docházky zaměstnanců letiště Zaměstnanec
HR
Šéf oddělení
Příchod zaměstnance
Nový zamestnanec
<
> <>
Založení do DB
Zaznamenání příchodu do systému
Zaznamenání odchodu Schválení výkazu
Výkaz č asu práce
<>
Schválno <>
Konec procesu
Obr. ‐ Process diagram ‐ monitoring docházky zaměstanců letiště (9)
30
‐2009‐
4IT 450 CASE
5.6.3.3 Data flow diagram ‐ Diagram je globálním pohledem na jednotlivé datové toky firmy a zachycuje jejich transformaci ze vstupních toků na toky výstupní. 4 3
Catering reklamace
Catering objednávka
požadavek objednávky vyrízení reklamace
informace o stavu objednávky
5
Docházka zamestnancu informace o stavu reklamace Údaje o kapacitách
požadavek na objednání cateringu
1
4
24
Catering
Reklamace
23
Catering dodávka
Cargo
Informace o nákladu
Informace o zaměstnancích
8
Informace o zaměstnancích informace o stavu cateringu
Kontrola zamestnancu
18
Evidence protokolu Stav zaměstnance
Bezpečnostní opatření
Údaje o kapacitách
Výdej nákladu
Informace o kontrole
Informace o nákladu
Informace o postupu
2
Dodání
Požadavek na nakládku
Catering kontrola hygieny
9
Vyrízený požadavek 2
Zamestnanec
Informace o postupu
Požadavek na vykládku
Informace o zamestnanci
Povolení k odletu
10
Zákazník stav výberového rízení
Požadavek na zásah
Zavazadlo
Monitorování osob Evidence zavazadla
Predání letadla
Školení Vyrízený požadavek
Uchazeč
10
Policejní zásah
Žádost o odlet 23
Žádost o preložení
Parametry zavazadla
Údaje o školení
Požadavek na zásah
14 Požadavek na hangárování
Externí firma
Servis Letadel
Školení
Policejní zásah
19 Výdej zavazadel
Informace o kapacitách
6
Policie
17
Servisní požadavek
Objednání
Potvrzení zmeny
Príjem zavazadel
Evaluace 5
Bezpečnostní opatření
Príjem nákladu Kvalifikace zamestnance
11 Nábor zamestnancu
Bezpecnostní postup
13
vkládání informací o zamestnancích Objednání
26 Informace o postupu
Kontrola zavazadel
Vyrízený požadavek
Odevzdání zavazadla
Vrácené zavazadlo
Hangárování
Rezervace
vydej zavazadel cestujícím
Dodání Informace o kapacitách 1
20
Informace o letadlu
Servis
Nebytový prostor
Cestující
Informace o údržbe
Informace o servisu
Zásobování letište
Podávání informací
Žádost o pristání
Informace o prostoru
9
Servis letadel
Žádost o timeslot
Stav zásob
12 Informace o servisu
22
Aktualizace stavu
Údržba prostor
Žádost o informace
Odlet letadla
Rezervace timeslotu Informace o pocasí
Informace o zdrojích
7 Informování cestujících
13
Zásoba
Informace o timeslotech
Uvolnení zdroju 27
Údržba
Povolení k pristání
Informace o timeslotech Stav timeslotu
25
Meteorologie
Informace o pocasí
8
Informace o timeslotech
Timeslot
Update timeslotu
Informace o pocasí 15 Prílet letadla
Rezervace Informace o timeslotech
Stav timeslotu
Informace o timeslotech
21 Zmena timeslotu
16 Rezervace timeslotu
Obrázek 17 ‐ DFD ‐ letištní společnost (9)
5.7 Detailní analýza a návrh (DAN) 5.7.1
Dílčí úkoly etapy (9) ‐
Transformace konceptuální úrovně návrhu do technologické
‐
Podrobná funkční a datová analýza
‐
Podrobný funkční a datový model, model chování apod.
‐
Návrh uživatelského rozhraní 31
‐2009‐
4IT 450 CASE
‐
Podrobné prověření návrhu před implementací
‐
Zpracování plánu implementace
‐
Koordinace řešitelských týmů
‐
vypracování konečné verze schvalovacích procedur a plánů všech testů
‐
zpracování předpokladů a plánu pro zavádění systému
5.7.2
Možnosti použití CASE nástroje v této etapě
Pro tuto etapu projektu je použití CASE nástroje taktéž naprosto nezbytné. V této fázi již na jednotlivé entity pohlížíme detailněji. Pro ukázku jsme zvolili rozpad základního DFD diagramu z globální analýzy 1. ČL (viz předchozí kapitola) na několik detailně rozebraných částí. I v této části projektového řízení může být repositury vítaným pomocníkem. 5.7.2.1 Objednávka ‐ Diagram zachycuje datový tok při realizaci objednávky. informace o požadavku objednávky
3.42 vyhodnocení objednávky
4 potvrzení navrhovanýc h objednávek
informace o rezervaci
3.42 rezervace objednávky
Obrázek 18 ‐ DFD ‐ realizace objednávek (9)
5.7.2.2 Reklamace ‐ Diagram zachycuje datový tok při realizaci reklamace.
32
Catering
‐2009‐
4IT 450 CASE 4.42
4
Catering
zaevidování reklamacní události
informace o opatrení
4.42
predání cateringu
evidence reklamace
Reklamace
evidence opatrení
24
Reklamace
prijetí opatrení
predání reklamace Opatření
4.42 predání vedoucímu služeb cateringu
Obrázek 19 ‐ DFD – reklamace (9)
5.7.2.3 Docházka zaměstnanců ‐ Diagram zachycuje datový tok mapující evidenci docházky zaměstnanců. 2
Zamestnanec
5.42 Požavek na vytvorení výkazu Vytvoření výkazu
5.42 Záznamenání príchodu Požadavek na zaznamenání
5.42 Vyhodnocování výkazu
5.42 Záznamenání odchodu
Požadavek na vyhodnocení
Sestavení výkazu
Požadavek na schválení
5.42
5.42
5.42
Sestavení výkazu práce
Schválení výkazu
Uložení výkazu Schválený výkaz
Zamítnutý výkaz
Obrázek 20 ‐ DFD ‐ evidence docházky zaměstnanců (9)
33
‐2009‐
4IT 450 CASE
5.8 Implementace (IM) 5.8.1
5.8.2
Dílčí úkoly etapy (9) ‐
tvorba a ladění programů, úpravy nakoupených aplikačních produktů
‐
školení uživatelů
‐
testování programových modulů a systému jako celku
‐
vytvoření programové dokumentace
‐
tvorba uživatelských příruček
‐
zpracování havarijních plánů ‐ scénářů řešení nestandardních situací
‐
příprava migrace dat
Možnosti použití CASE nástroje v této etapě
V této fázi je použití CASE nástrojů částečně diskutabilní. Analýza je hotova, ale pokud se až v této etapě objeví nutnost odklonu od DAN, je zvláště nutná pečlivá analýza nezbytných odchylek v kontextu návaznosti s nezměněnými částmi systému a ověření funkcionality měněných částí. Pro řízení projektů je také vhodné mít procesně zpracované jednotlivé činnosti pracovníku implementačního týmu. Pro tyto potřeby by měla sloužit firemní metodika. Pokud však takový dokument prozatím neexistuje nebo je nedostatečně zpracován, je vhodné některé postupy zdokumentovat. 5.8.3
Příklad využití CASE nástroje na skutečné implementaci IS K2 do konkrétní firmy
5.8.3.1 Diagram programování speciálních úprav ‐ Diagram zachycuje customizaci IS, tedy programování jednotlivých požadovaných spceciálních úprav.
34
‐2009‐
4IT 450 CASE
Nastudování popisu požadovaných úprav ANO
NE
Úprava standardu?
Upravení standardu
Dohledání části kódu?
NE
ANO
Sestavení programu
Napsání nového programu
Vlastní otestování
ANO Nalezení chyby?
Opravení chyby
NE Tvorba dokumentace
Interní testování
Obrázek 21 ‐ Process diagram ‐ programování speciálů (10)
5.8.3.2 Diagram testování ‐ Následující schéma popisuje postup při interním testování.
35
‐2009‐
4IT 450 CASE
Tvorba speciálu
Přijetí speciálů a dokumentace
Nastudování dokumentace
Rozepsání testovaných operací
Testovací protokol
Zapsání chyb do protokolu
Tvorba testovacích dat
Testování jednotlivých operací
NE Funguje speciál?
ANO
Testování zákazníkem
Obrázek 22 ‐ Process digram ‐ interní testování (10)
5.9 Zavádění systému (ZA) 5.9.1
Dílčí úkoly etapy (9) ‐
Příprava organizace a uživatelů na provoz IS ‐ změny v organizační struktuře, přijímání nových pracovníků resp. snižování počtu zaměstnanců
‐
Školení uživatelů
‐
Instalace a konfigurace technického vybavení
‐
Instalace a konfigurace základního SW ‐ např. databázové servery
36
‐2009‐
4IT 450 CASE
‐
Instalace a konfigurace aplikačního SW
‐
Migrace dat do nového IS
‐
Zpracování provozních řádů pro nový IS
‐
Zkušební provoz IS
‐
Přechod na rutinní provoz
5.9.1.1 Možnosti použití CASE nástroje v této etapě Touto fází největší intenzita projektového řízení končí. V této etapě již dochází spíše k využití výstupů CASE nástrojů pro účely školení klíčových uživatelů a následné distribuce znalostí využití systému napříč spektrem relevantních uživatelů, případně využívání výstupů CASE nástrojů pro provádění úkolů postupného náběhu IS (případně též pro účely migrace dat, viz oddíl „vyřazení systému“).
5.10 Provoz a údržba (PU) 5.10.1 Dílčí úkoly etapy (11) ‐
Poskytování konzultačních a školících služeb uživatelům
‐
Organizační a technické zajištění provozu IS
‐
Údržba programového systému a dat
‐
Údržba dokumentace
‐
Realizace změn ‐ nové verze programových modulů
‐
Záznamy uživatelských požadavků
5.10.2 Možnosti použití CASE nástroje v této etapě Využití CASE nástrojů již v této fázi není tak intenzivní. Využívané jsou např. při mapování a rozvíjení návrhů na zlepšení a změny využití systému. Následně jsou využity při designu a implementaci těchto změn zejména ve smyslu kontinuální evoluce udržovaného systému. Dalším hlediskem je pečlivá administrace prováděných změn zejména v prostředích: 1) IS popř. klíčová část IS je využívána větším množstvím externích komponent / systémů 2) Při postupné evoluci systému, případně při podpoře provozu systému participuje větší množství obchodních subjektů nebo pracovních skupin
37
‐2009‐
4IT 450 CASE
5.11 Vyřazení systému (VY) (9) ‐
vyřazení systému je ukončením životního cyklu IS
‐
IS bývá zpravidla nahrazen novým systémem (předchází migrace dat)
5.11.1 Možnosti použití CASE nástroje v této etapě V této fáze může být CASE nástroj využit pro podporu designu a provedení „cutover“ plánu, zejména v „setupech“ souběžného provozu více generací, nebo komponent využívaného větším množstvím dalších systémů, popř. ve velkém množství procesů. S vyřazováním systému je většinou také spojen design a provedení migrace dat (popř. i generování počátečních vstupních dat) do nově pořízeného IS. Zejména kritické aspekty migrace je nutné zachytit patřičnými diagramy. Instalace nového IS
Určení typu souboru
Původní IS
Soubor
Určení struktury dat
Specializovaný software Import do souboru
Import do nového IS
Testování
Nový IS
Obrázek 23 ‐ Konverze dat do nového IS
5.12 Porovnání MMDIS s komerční metodikou ASAP (16) Pro zajímavost doplňujeme, že stejná logika základních rozdělení fází, tak jako ji provádí MMDIS, se dá vystopovat ve většině běžně využívaných metodik a strategií řízení projektu. Jako příklad uvádíme porovnání s metodikou ASAP (Accelerated SAP), tradiční metodologií při implementaci řešení na bázi produktů společnosti SAP AG. 5.12.1 Co je to ASAP / AcceleratedSAP / ASAP Focus? SAP AG (založen roku 1972 bývalými pracovníky IBM) je světový dodavatel ERP řešení s hlavním sídlem v Německu (Waldorf). Minimálně v podmínkách Evropy je oblasti „velkých ERP řešení“ dodavatelem největším, v posledních letech je uváděn jako největší dodavatel těchto řešení obecně. 38
‐2009‐
4IT 450 CASE
Zaměstnává 51.447 pracovníků při obratu 16mld USD (2008). Tato firma vlastní software vyvíjí, v menší míře také implementuje. Nosným produktem společnosti SAP AG je SAP ERP (dříve SAP R/3), který je postupně rozšiřován jak dalšími moduly tohoto systému (např. IS‐U Industry Solution for Utilities), případně novými generacemi původních modulů (RE Real Estate => RE‐FX Real Estate Flexible),,tak i dalšími samostatnými produkty (např. CRM, datový sklad – BI Business Intelligence / BW Business Warehouse). Toto je řešeno jak interním vývojem, tak i akvizicemi (BOBJ – Business Objects). Většina implementací těchto produktů probíhá mimo vlastní režii SAP AG (samostatnými implementátory, vlastním týmem, případně konzultanti SAP AG pouze externě dohlížejí) a tudíž je prováděna firmami s typicky odlišnými interními metodikami. Přesto pro účely podpory implementace vlastního systému SAP AG doporučuje specifickou metodologii ASAP (Accelerated SAP), což je v drtivé většině případů dodržováno. Tato metodologie je nově přejmenována na Focus ASAP – ale vzhledem k tomu, že minimálně v českých poměrech není ještě tento termín příliš rozšířen a jeho využívání dle naší zkušenosti přináší jisté zmatky, budeme dále uvádět tuto metodologii pod názvem původním. Tyto implementace trvají mezi 3 měsíci (agilní implementace menších řešení, přes typický 1 rok pro větší projekty a 2 roky pro větší a náročnější projekty po zásadní implementace probíhající po dobu několika let (viz aktuálně probíhající implementace Státní pokladny v ČR). Smyslem metodiky ASAP je pak minimalizace rizik těchto náročných implementací a dále zvýšení ROI aplikací technik na minimalizaci a optimalizaci implementační doby a minimalizaci velikosti a vytížení implementačního týmu. 5.12.2 Samostatná úvodní studie Metodologie ASAP jako taková vlastní samostatnou část úvodní studie (tak jako MMDIS) neobsahuje. Přesto je v běžné praxi používána ve formě studie proveditelnosti, pokud si v podmínkách přípravy náročného projektu není zákazník jistý vhodností konkrétních produktů pro nestandardní účely (popř. do nestandardních podmínek). V této studii jsou pokrývané funkcionality mapovány v kontextu podnikových procesů zákazníka, dochází k identifikaci problematických míst a je odhadnuta náročnost nezbytných doplňujících vývojů. Následně se na základě této studie zákazník rozhoduje o provedení daného projektu. 5.12.3 Fáze 1 ‐ Příprava projektu Úlohy dané v MMDIS úvodní studií se částečně překrývají s první fází metodiky ASAP ‐ „Project Preparation“, fází 1 dle metodiky ASAP. V rámci této etapy je připraveno následující:
Definice cílů projektu
Příprava rámcového harmonogramu projektu (později detailizován dle potřeby) 39
‐2009‐
4IT 450 CASE
Definice technických požadavků
Definice rolí projektového týmu
Definice projektových dokumentů
Základní rozdělení pokrytí business procesů
Úvodní „kickoff meeting“ projektu – seznámení projektového týmu s výstupem předchozího (zejména se základní strukturou projektu, složením týmu, přidělením zodpovědností)
Nicméně, z tohoto rozpisu je jasné, že mnoho úloh MMDIS ÚS je uskutečněno před vlastním zahájením projektu implementace dle ASAP (tato metodika se jako taková soustředí na pohled jednotlivé implementace, nikoliv na kontext zabezpečení pokrytí ICT podpory organizace tak jako MMDIS).
Obrázek 24 ‐ ASAP Roadmap (16)
Základní výstupy této fáze: Založení Issue Database – v tomto dokumentu se evidují mimořádné problémy (a jejich vyřešení), je zde obsaženo zejména:
Neočekávané úlohy (úlohy, se kterými se v předchozích fázích projektu pro plnění aktuálních fází nepočítalo)
Očekávané úlohy, u kterých je problém s jejich úspěšným vyřešením (případně včasným vyřešením)
Neočekávaný vliv externích (a negativních) faktorů na průběh projektu´
K jednotlivým problémům je evidováno (sledováno vždy v kontextu historie):
Priorita 40
‐2009‐
4IT 450 CASE
Fáze projektu (ke které je problém relevantní)
Odpovědní pracovníci
Vstupy potřebné pro řešení problému
Termíny (etap řešení, finálního vyřešení)
Klasifikace problému (chybějící zdroj, dokumentace, vývoj...)
Základní dokumenty projektu: Pro využití v projektu jsou ustanoveny základní dokumenty projektu a tým je seznámen s jejich využitím (některé z těchto dokumentů jsou v této etapě založeny, ale ještě většinou nemají faktický obsah, který je postupně plněn a udržován v dalších etapách).
Scope projektu
Komunikační matice, rozpis zodpovědností
Základní soupis pokrývaných procesů
Popis systémového landscape
Popis technických požadavků
Šablony pracovních dokumentů
Základní popis designu řešení
Dokumentace nastavení
Dokumentace vývojů
Dokumentace pro koncové úživatele
Využité patche (OSS Notes)
5.12.4 Fáze 2 ‐ Příprava cílového konceptu / Business Blueprint V rámci ASAP není zřetelně oddělena fáze GAN a DAN tak jako v MMDIS. Přesto se na úvodních schůzkách analytické fáze uživatelé seznamují se základními souvislostmi daného systému (případně modulu) a dochází k základnímu namapování daných funkcionalit na business procesy zákazníka a jejich přiřazení jednotlivým zodpovědným osobám / oddělením / organizačním celkům. Teprve potom dochází k detailizaci řešení do výsledného cílového konceptu. Mnohdy je možné základní rozčlenění zkrátit díky znalostem pracovníků zákazníka o fungování systému.
41
‐2009‐
4IT 450 CASE
Základním smyslem této fáze je přípava dokumentu Cílový koncept / Business Blueprint ‐ detailního rozpis nasazovaného systému po jednotlivých modulech, částech modulů a problematikách. Jak jsme uvedli, v tomto dokumentu splývá GAN s DAN ‐ přesto lze říci, že v úvodních podetapách je řešeno GAN a v následujících podetapách je přistoupeno k DAN. Tato fáze končí akceptací dokumentu cílového konceptu zákazníkem a dodavatelem. Tento dokument je zcela závazný pro fázi realizace (tzn. pro odchýlení se od tohoto dokumentu je nutno využít řízení změnových požadavků / change requestů). Minimální rozpad kapitol dokumentu cílový koncept pro jednotlivé implementované části:
Detailní popis funkcionality nasazované částí systému v kontextu potřeb zákazníka
Procesní model
Popis nutných rozšíření / vývojů dané části
Popis návazností s ostatními částmi
Popis nároků na reporting
Popis nároků na migraci
Autorizační koncept
Periodické porady V této fázi jsou zahájeny porady / kontroly postupu projektu. Toto je řešeno na dvou úrovních:
Status Meeting projektových týmů – je kontrolován status prováděných prací po jednotlivých týmech, dále jsou prezentovány informace relevantní pro členy ostatních týmu a řešeny mezitýmové návaznosti, případně i překrývání. Toto nejen ve smyslu navazujících funkcionalit, ale i ve smyslu navazujících prací mezi participujícími týmy.
Steering Comitee – schůzky vedení projektu – prezentace statusu projektu, případně i opatření na této úrovni (úpravy požadovaných termínů, posilnění příp. změny kapacit atd.)
Business Model Master List
Identifikace jednotlivých procesů (nejmenší jednotka je tzv. business process procedure)
Plánování, monitoring analýzy a realizace jednotlivých procesů
Podklad pro školení a testování
Další aktivity
Detailizace harmonogramu projektu – doplnění původně zejména klíčových milníků na rozpad na jednotlivé sledované úlohy a jejich návaznosti
42
‐2009‐
4IT 450 CASE
Úvodní školení – školení potřebných funkcionalit relevantních pro tuto etapu (např. úvodní školení systému SAP pro pracovníky zákazníka, kteří zatím tento systém při své práci nevyužívali)
Příprava systémového prostředí – příprava potřebných systémů a dalšího technického zázemí etapy Realizace a vlastního produktivního provozu
Příprava podkladů na straně zákazníka – příprava potřebných podkladů pro implementaci, o které byly požádáni pracovníci na straně zákazníka
5.12.5 Fáze 3 – Realizace / Realization Po fázi přípravy Business Blueprint / Cílového konceptu končící jeho akceptací je přistoupeno k fázi realizace. V této fázi jsou provedeny veškerá nastavení systému a připraveny všechny vývoje přesně dle rozpisu cílového konceptu. Pokud je v této fázi identifikována nutnost odchýlení se od cílového konceptu, je toto řešeno řízením změnového požadavku. Realizace je rozdělena do dvou částí:
Základní konfigurace / Baseline configuration – základní nastavení systému (pokrývá cca 80% potřeb) – na jeho základě je možné testovat systém a návaznosti jednotlivých částí, také je možno začít s úvodním školením uživatelů
Finální konfigurace / Final configuration – provedení zbývajících nastavení (v praxi většinou navázáno na dokončení rozšíření systému / vývojů)
5.12.6 Fáze 4 – Příprava produktivního provozu / Final Preparation Smyslem této fáze je zajistit hladký náběh systému – ve smyslu provedení testování, školení klíčových a koncových uživatelů, realizace cutover plánu, provedení migrací a případně též vyřešení všech zásadních bodů z issue logu. Po dokončení této fáze je systém připraven k náběhu. V praxi je v mnoha případech tento náběh ohraničen koncem kalendářního roku, kvartálu, účetního roku atp. V případě problémů dochází k posunu klíčových milníků – někdy je využito posunu z „optických termínů“ (např. konec roku) na termíny „nouzové“ ‐ např. těsně před posláním prvních lednových faktur. Tato fáze odpovídá v MMDIS fázi ZA Zavádění systému. 5.12.7 Fáze 5 – Náběh a podpora produktivního provozu / Go Live and Support Fáze PU metodiky MMDIS je zastoupena ve fázi „Go Live and Support“ / Náběh a podpora produktivního provozu. Tato fáze je využita nejprve k vyřešení případných problémů, které šlo odložit po náběhu systému, případně realizace celých částí projektu, které mají posunuté fáze proti klíčovým aktivitám (např. podpůrný reporting, podpůrné vývoje pro zlepšení uživatelského komfortu atp.). V této fázi (většinou např. 2 měsíce po náběhu systému) je také poskytována zvýšená podpora koncovým uživatelům, pro které ještě není práce v novém systému rutinním plněním úloh. Také dochází k počátku
43
‐2009‐
4IT 450 CASE
postupného sběru podnětů na další zlepšení systému, které může být provedeno buď v samostatných zakázkách malého rozsahu, případně i v samostatných navazujících projektech.
5.13 Shrnutí Z výše uvedených novinek je zřejmé, že MS Project 2007 se řadí do skupiny tzv. „Schedulerů“ a čím dál více se odcizuje skupině CASE nástrojů. Naopak Sybase PowerDesigner 15 se zase řadí do CASE nástrojů podporující Enterprise architekturu. Vzhledem k vývoji, který je zaměřen na podporu uživatelsko‐podnikového prostředí, bude trendem jednoznačné a striktnější oddělení těchto dvou skupin nástrojů. Jejich další evoluce bude podřízena aktuální poptávce po nových funkcích v dané oblasti jejich využívání.
6 Závěr Cílem této práce bylo zjistit možné použití CASE nástrojů pro řízení projektů IS/ICT. V pracích našich kolegů jsme se mohli dozvědět o mnohých metodikách řízení projektů, různých CASE nástrojů a ve většině případů se došlo k závěru, že jejich využití k řízení projektů je poměrně složité. Což ostatně potvrzujeme i my. Jak jsme se ale zmínili v úvodu, zaměřili jsme se na projekt IS/ICT jako na projekt vývoje informačního systému a s tím související metodiky životního cyklu IS. Ačkoliv neexistuje jednotný přístup k definici životního cyklu vývoje informačního systému, můžeme říci, že každá metodika obsahuje základní vývojový cyklus fáze zadání, analýzy, návrhu, implementace, testování a provozu. My jsme se zaměřili na metodiku vyvíjenou na katedře informačních technologií VŠE: MMDIS. Z té mimo jiné vyplývá, že by měla metodika stanovit i jaký CASE nástroj je vhodné použít v jednotlivých fázích životního cyklu IS. V praktické části ukazujeme uplatnění CASE nástroje Powerdesigner v jednotlivých fázích metodiky MMDIS. Ta ukazuje, že CASE nástroj využijeme hlavně v etapě globální analýzy a návrhu (GAN), v detailní analýze a návrhu (DAN) a lze i ve fázi implementace. V případě GAN je využití CASE nástroje v podstatě nutností. Konkrétně používáme např. Class diagramy, procesní diagramy či Data flow diagramy. V nové verzi Powerdesigneru jsou nově čtyři vybrané metodiky, které doporučují postup při modelování jednotlivých diagramů a jejich návaznost dle jednotlivých metodik. Což vidíme jako velké plus a naznačení možného trendu, kterým se CASE nástroje můžou ubírat (ulehčení práce analytikům a vedoucím projektů). Dalším trendem je rozdělení (nejen) CASE nástrojů na více částí (modulů), které umožňují společnostem minimalizovat náklady nákupem pouze potřebných modulů pro danou fázi projektu. Nemalým plusem je též sdílený repositář v relační databázi, která umožňuje ukládat a verzovat modely, což je velmi důležité pro práci v týmu a tím i pro samotný projekt, jež stojí na týmové práci. Z naší práce také vyplývá, a i potvrzuje výsledky kolegů, že trendem (jdoucím proti původní definici pojmu CASE) je rozdělení se na dvě specializované samostatné skupiny produktů podporující buď procesní řízení (např. námi zmíněný Powerdesigner či Enterprise Architect) a na produkty podporující projektové řízení (např. nejvyužívanější MS Project či Primavera). 44
‐2009‐
4IT 450 CASE
Přínosem této práce je též strukturované srovnání metodiky MMDIS s metodikou ASAP (Accerelated SAP), které dokazuje překrývání určitých fází obou metodik. Rozdíl je ale především v komplexnosti MMDISu na rozdíl od ASAPu, která se soustředí jen na jednotlivé implementace. Využití Case nástrojů, v odpovídajících si fázích, shodné. Na závěr tedy můžeme konstatovat, že z naší práce a prací našich kolegů vyplývá, že CASE nástroje k podpoře řízení projektů využijeme především jako podporu týmové práce, jako nástroj řízení životního cyklu informačního systému a jako nástroj pro řízení portfolia projektů.
45
‐2009‐
4IT 450 CASE
7 Citovaná literatura 1. CASE, Albert F. Computer‐aided software engineering (CASE): technology for improving software development productivity. New York, USA : ACM, 1985. ISSN:0095‐0033. 2. Chlapek, Dušan. 4IT414 Řízení projektů IS/ICT. Praha, 2008. 3. J. Voříšek, a kol. Principy a modely řízení podnikové informatiky. Praha : Oeconomica, 2008. ISBN: 978‐80‐245‐1440‐6. 4. Václav Řepa, a kol. Metodika vývoje informacního systému. [Online] 6 2006. http://opensoul.iquest.cz/forum/docs/publications/Metodika_vyvoje_IS_06_2006.pdf. 5. Sybase Software, s. r. o. Sybase POWERDESIGNER 15. [Online] 10 2008. http://www.lupa.cz/tiskove‐zpravy/sybase‐powerdesigner‐15/. 6. Sybase Software, s.r.o. PowerDesigner. [Online] http://www.sybase.cz/index.php?option=com_content&view=article&id=3&mid=24.
4
2009.
7. Kotek, Jan. Vývojové nástroje SYBASE. soft‐tronic. [Online] 2000. http://www.soft‐ tronik.cz/web/read_me.nsf/0580dad5432d70444125686a00472c05/52c7890f3dbb7a23c12568d300485 9f6?OpenDocument. 8. Voříšek, Jiří. MMDIS princip multicimenzionality a dimenze řešení. [Online] 2003. http://nb.vse.cz/~vorisek/FILES/4IT215_materialy_k_predmetu/05MMDIS‐ Princip_multidimezionality_a_dimenze_reseni_IS.zip. 9. Kajzar, RNDr Dušan. Projektování http://zdenek2.euweb.cz/doc3/prois5.doc.
informačních
systémů.
[Online]
2003.
10. Ondřej Čuka, Martin Navrkal, Jakub Albrecht. Použití CASE/CABE pro rízení workflow ve firmě IT 572. 2005. 11. Mikhail Šubachev, Radek Kollárovits a kol. Globální analýza podniku 1. Česká letištní s.r.o. práce pro předmět Informační modelování organizací. [Online] 2008. 12. Pešková, Barbora. Implementace informačního systému K2 do konkrétní firmy, bakalářská práce. 2008. 13. Grégr , Jiří. Použití CASE pro řízení projektů IS/ICT : (Vazba na nástroje řízení projektů, trendy a možnosti). [s.l.], 2007. 23 s. Seminární práce. 14. MICROSOFT, Microsoft Office Project. [online]. 2007. http://office.microsoft.com/cscz/project/HA101656381029.aspx 15. PRIMAVERA Project Manager. [online]. http://www.iprimavera.cz/primavera-6-0/projectmanagement/
46
‐2009‐
4IT 450 CASE
16. Hansen, Kathryn, SAP AG, ASAP Implementation Roadmap. 12 2006.
47
