Pužití CASE pr řízení prjektů IS/ICT 4IT450 2009 Jakub Hlba, Radek Kllárvits, Barbra Peškvá, Mirek Řezníček, Tmáš Sukup, Jan Šafránek, Petr Šklník
1 Antace Tat práce vznikla v rámci předmětu 4IT450 CASE vyučvaném na katedře infrmačních technlgií VŠE v Praze pd vedením prf. Řepy. Práce navazuje na výstupy našich předchůdců z minulých let a dplňuje je aktuální infrmace z tét blasti. Cílem práce je v teretické úvdní části dplnit výsledky minulých prací phled na CASE jak na nástrj pr řízení živtníh cyklu IS. V praktické části je pak práce zaměřena na mžnst pužití CASE nástrjů v jedntlivých fázích prjektu a t jak z phledu metdiky MMDIS, tak z phledu metdiky ASAP. Prvnání těcht metd (nikli však jejich detailní ppis) vnímáme jak hlavní příns naší práce. 2
Obsah 2 Úvd... 5 3 Vymezení pjmů a důležitá fakta... 6 3.1 Prjekt IS/ICT... 6 3.2 Řízení prjektů IS/ICT... 6 3.3 Živtní cyklus IS, metdika vývje IS a řízení prjektu... 6 3.4 CASE... 8 4 Trendy ve vývji nástrjů řízení prjektů... 9 4.1 Nástrje pr řízení prjektů... 9 4.2 Nvé funkce a trendy, kterými se ubírají... 10 4.3 Sada nástrjů MS Prject... 10 4.3.1 Principy a kntrla plánů a financí prjektů... 10 4.3.2 Efektivní předávání a prezentace infrmací prjektech... 11 4.3.3 Rychlé zajištění prduktivity... 13 4.4 Sada nástrjů Primavera Prject Management... 16 4.4.1 Funkce řešení prjektu... 16 4.5 Prvnání nástrjů... 17 4.6 CASE nástrje v suvislsti s řízením prjektů... 17 5 Praktická část... 18 5.1 Sučasné mžnsti CASE nástrje PwerDesigner... 18 5.1.1 Klasické mžnsti PwerDesigneru (7)... 19 5.1.2 Ppis prduktu PwerDesigner(6)... 20 5.1.3 Reference... 21 5.1.4 Nvé mžnsti PwerDesigneru 15 (6)... 21 5.2 Základní principy MMDIS... 22 5.2.1 Metdika MMDIS... 22 5.2.2 Pravidla multidimenzinality: (8)... 23 5.3 Glbální pdnikvá strategie (GST) (9)... 23 5.3.1 Kritické faktry úspěchu pdnikatelské strategie... 24 5.3.2 Mžnsti pužití CASE nástrje v tét etapě... 24 5.4 Infrmační strategie (IST) (9)... 24 5.4.1 Mžnsti pužití CASE nástrje v tét etapě... 25 3
5.5 Úvdní studie (US)... 25 5.5.1 Dílčí úkly etapy (9)... 25 5.5.2 Mžnsti pužití CASE nástrje v tét etapě... 27 5.6 Glbální analýza a návrh (GAN)... 27 5.6.1 Dílčí úkly etapy (9)... 27 5.6.2 Mžnsti pužití CASE nástrje v tét etapě... 27 5.6.3 Krátký ppis splečnsti (pr snazší pchpení diagramů)... 28 5.7 Detailní analýza a návrh (DAN)... 31 5.7.1 Dílčí úkly etapy (9)... 31 5.7.2 Mžnsti pužití CASE nástrje v tét etapě... 32 5.8 Implementace (IM)... 34 5.8.1 Dílčí úkly etapy (9)... 34 5.8.2 Mžnsti pužití CASE nástrje v tét etapě... 34 5.8.3 Příklad využití CASE nástrje na skutečné implementaci IS K2 d knkrétní firmy... 34 5.9 Zavádění systému (ZA)... 36 5.9.1 Dílčí úkly etapy (9)... 36 5.10 Prvz a údržba (PU)... 37 5.10.1 Dílčí úkly etapy (11)... 37 5.10.2 Mžnsti pužití CASE nástrje v tét etapě... 37 5.11 Vyřazení systému (VY) (9)... 38 5.11.1 Mžnsti pužití CASE nástrje v tét etapě... 38 5.12 Prvnání MMDIS s kmerční metdiku ASAP... 38 5.12.1 C je t ASAP / AcceleratedSAP / ASAP Fcus?... 38 5.12.2 Samstatná úvdní studie... 39 5.12.3 Fáze 1 Příprava prjektu... 39 5.12.4 Fáze 2 Příprava cílvéh knceptu / Business Blueprint... 41 5.12.5 Fáze 3 Realizace / Realizatin... 43 5.12.6 Fáze 4 Příprava prduktivníh prvzu / Final Preparatin... 43 5.12.7 Fáze 5 Náběh a pdpra prduktivníh prvzu / G Live and Supprt... 43 5.13 Shrnutí... 44 6 Závěr... 44 7 Citvaná literatura... 46 4
2 Úvd Pprvé byl pjem CASE pužit v rce 1982 splečnstí Nastec Crpratin (Michigan, US), která jím značila svůj systém s názvem GraphiText. GraphiText byl první systém, který v sbě integrval grafický i textvý editr. Zajímavá je shda jmen jednh ze dvu půvdců akrnymu CASE (Cmputer Aided System Engineering) a zakladatelů splečnsti Nastec, Alberta F. Case, Jr. I přest, že Albert Case v jednm ze svých půvdních článků z rku 1985 píše: Plně uzpůsbený CASE systém se dlišuje d statních nástrjů, které pdprují puze jednu blast vývje sftwaru, tím, že je v sbě bsahuje všechny. (1) Následníky GraphiTextu byly dva systémy DesignAid a LifeCycle Manager. První z nich vznikl pr pdpru strukturvanéh přístupu k analýze, designu a prgramvání (Jacksn) a Yurdnvy metdlgie. Zahrnval v sbě nástrje pr analýzu a design. Druhým systémem, který vznikl paralelně, byl LifeCycle Manager. Ten bsahval mduly pr prjektvé řízení, tak jak h chápeme dnes. Již dtud je tedy patrné, že s růstem bjemu funkcinality půvdníh CASE nástrje, dšl k ddělení samtné mdelvací a řídící větvě vývje infrmačníh systému, které se pstupem času vyprfilvaly d samstatných skupin prduktů. V pslední dekádě 20. stletí zaznamenaly prgramvé nástrje na pdpru vývje infrmačníh systému CASE velku ppularitu. Tmu zajisté přispěly dva hlavní trendy, které 90. léta minuléh stletí ve vztahu k infrmačním technlgiím se všemi suvisejícími aspekty, charakterizují. Jedná se buřlivý rzvj metdik vývje infrmačních systémů (prcedurálních i bjektvých) a reengineering pdnikvých prcesů (BPR). T vyvlával stále větší pžadavky na schpnst grafickéh ztvárnění diagramů, autmatizace rutinních činnstí, ale i zvýšená ptřeba vedení a správy prjektvé dkumentace V průběhu let nástrje CASE vyspěly ve velké kmplexní a sfistikvané systémy, které pstupem času přestaly být zajímavu a marketingvě hdntnu nvinku a v sučasnsti je již jejich význam jiný. V následujícím textu se zaměříme na ppis nástrjů CASE a jejich vazby na řízení prjektů. Nejdříve však chceme bjasnit některé pjmy a shrnut becná fakta. 5
3 Vymezení pjmů a důležitá fakta 3.1 Prjekt IS/ICT V některých minulých pracích jsme se setkali s citací definice prjektů z nrmy ISO 10006 neb PMBOK. Ve vztahu k tématu naší práce nám ale jak nejlepší definice prjektu IS/ICT přišla definice Ing. Dušana Chlapka, PhD. : Prjekt IS/ICT je řízená skupina činnstí vyvlaná za účelem přízení neb adaptace (změny) IS/ICT, směřující k dsažení předem určených cílů. Prjekt knčí předáním prduktů d užívání. (2) V tét definici je pr nás stěžejní slvíčk přízení IS/ICT. Přídit IS/ICT lze pdle prf. Vříška něklika způsby. Prvním jedndušším způsbem je přízení neb ddání tzv. TASW, typickéh sftware neb také krabicvéh sftware. V tmt případě se vývjvý (živtní) cyklus infrmačníh sftware pr nás eliminuje více méně puze na implementaci a testvání, tedy na fáze, ve kterých nástrje CASE standardně nevyužíváme neb ve kterých by byl eknmicky nevýhdné CASE nástrje vzhledem k jejich ceně zakupvat. A prt není tat mžnst v další části reflektvána. (3) Druhým způsbem přízení IS/ICT je vývj vlastníh IASW, tedy sftwaru vytvřenéh přím na míru našim pžadavkům a ptřebám. Zde je již třeba reflektvat všechny fáze vývje infrmačníh systému a pužití CASE nástrjů je v dnešní dbě zvyšující se slžitsti infrmačních systémů téměř nutné. V další části práce se tedy pjmem prjekt IS/ICT bude rzumět vývj infrmačníh systému. Dále knstatujeme, že utsurcing také dále nereflektujeme. 3.2 Řízení prjektů IS/ICT Stejně jak autři předchzích prací chápeme řízení prjektů jak plánvání, rganizvání a vedení činnstí a zdrjů za účelem dsažení definvaných cílů. Nejčastěji se ptýká s časvými a finančními mezeními a s mezeními zdrjů. Mezi hlavní činnsti řízení prjektů patří zejména plánvání, rganizvání, delegvání, mtivvání, řízení času, zdrjů, financí a nákladů, kmunikace, kvality, řízení změn, rizik a rezerv a dále hdncení a kntrlvání. (13) Vše výše zmíněné však by měl být chápán v suvislsti s prjektem IS/ICT, zejména pak s přihlédnutím k vybrané metdice vývje infrmačníh systému, živtnímu cyklu infrmačníh systému a knkrétníh CASE nástrje. Přesněji tedy řízení prjektů vývje IS/ICT. 3.3 Živtní cyklus IS, metdika vývje IS a řízení prjektu V pracích z minulých let jsme se dčetli, že CASE nástrje suvisí s metdikami a živtním cyklem infrmačníh systému. Pvažujeme však za vhdné zde tut prblematiku rzvést. Pjem živtní cyklus infrmačníh systému je svázán s každu knkrétní metdiku vývje infrmačníh systému. A v každé je chápán trchu jinak. V literatuře neexistuje jedntný přístup k definvání a chápání základníh pjmu živtní cyklus vývje infrmačníh systému. Obecně se dá ale říci, že při určité míře abstrakce každá metdika bsahuje základní vývjvý cyklus fáze zadání, analýzy, návrhu, implementace, testvání a prvzu. Živtní cyklus infrmačníh systému je pak základním výchdiskem veškerých úvah v metdikách. Příkladem může být nám dbře známá metdika MMDIS. 6
Obrázek 1 Metdika MMDIS (4) Prf. Řepa píše, že v závislsti na pužití knkrétní metdiky vývje infrmačníh systému se dvíjí jedntlivé ptřebné dkumenty, cíle a specifika řízení prjektu. Jedntlivé metdy, techniky a nástrje jsu metdiku vázány vždy k jedntlivým etapám a fázím živtníh cyklu IS. Začátky a knce etap a fází vývje IS jsu tak základními klíčvými bdy pstupu (tzv. milníky), v nichž metdika určuje způsb řízení pstupu vývje IS. Dále knstatuje, že: Knkrétní metdika by měla u každé etapy stanvit krmě jinéh dpručené techniky a nástrje (techniky, které se v činnsti pužívají, jejich mžná pdpra a statní nástrje vývje IS). (4) Metdika neppisuje pstup vývje infrmačníh systému d nejmenšíh detailu. Neppisuje ani jeh veškeré mžné varianty, metdy a techniky. Ale všímá veškerých pdstatných aspektů tht prcesu a pstihuje prces vývje IS d saméh začátku až d případnéh knce. 7
Obrázek 2 Živtní etapy infrmačníh systému VS etapy pstupu prjektu (4) Je zřejmé, že becný živtní cyklus vývje infrmačníh systému, daný metdiku vývje IS a becné schéma pstupu, dané metdiku řízení prjektu jsu věci, které na jednu stranu musí platit sučasně, ale přitm jsu na druhu stranu zcela různé. Prt je vždy v prcesu rzlišvat mezi metdiku vývje IS stanvenými) věcnými činnstmi prjektu a metdiku řízení prjektů stanvenými činnstmi jejich řízení cž je vidět na brázku 2. Prblematika živtníh cyklu infrmačníh systému a metdik je v naší práci zařazena, prtže s nástrji CASE úzce suvisí. Některé nástrje CASE je ttiž lepší pužít v jiných fázích živtníh cyklu IS. Pr pdrbnější infrmace dkazujeme na specializvanu literaturu. 3.4 CASE Pdle Alberta Case byla ve svém pčátku CASE technlgie, která pmáhala sftwarvým a systémvým vývjářům dsáhnut jejich cílů, tím, že jim pskytla všechny nástrje ptřebné pr vývj v jedné integrvané pdbě. (1) Čímž také zvyšvala prduktivitu vývje systému. Ta je pdle Case daná dvěma slžkami efektivitu a kvalitu, viz br.3. 8
Obrázek 3 Zvýšení prduktivity (1) Na br. č.3 jsu patrné dvě křivky P, ty charakterizují dvě prduktivity vývje infrmačníh systému. Prduktivita vývje je na brázku dána dvěma slžkami: efektivitu a kvalitu vývje infrmačníh systému. Pkud chceme při vývji infrmačníh systému dsáhnut jeh vyské kvality (resp. minimalizvat chyby), záknitě se musí snížit efektivita jeh vývje (resp. jeh vývj bude pmalejší). Při pužití nástrjů CASE při vývji infrmačníh systému se tat křivka psuvá směrem který je patrný na br.3 a dchází k paretvu zlepšení prduktivity vývje infrmačníh systému. Prduktivita vývje infrmačníh systému se přesunula z bdu A d bdu B a dšl ke zlepšení bu jejích slžek. V sučasnsti je pužíván termín CASE spíše ve spjení přím s CASE nástrji. Na základě analýzy prací z minulých let a knkrétních nástrjů může být tent pjem definván jak: Skupina sftwarvých nástrjů zaměřených na pdpru vývje infrmačních systémů. Jedná se sadu nástrjů pdprujících určité fáze vývje, především pak analýzu a návrh. (13) Definice CASE nástrjů již ale nemusí být přesná, prtže rzdíly mezi CASE nástrji, vývjvými nástrji a třeba generátry kódů se stírají. Tudíž pdmínka, kteru stanvil Albert Case v jeh definici, resp. pdmínka, že všechny tyt nástrje by měly být integrvané d jednh, již dnes není tlik akcentvána. T je dle našeh sudu způsben příliš nárčnými pžadavky při vývji mderních prjektů IS/ICT, na t aby byly uspkjeny, v již dnes velmi kmplikvaných a sfistikvaných CASE nástrjích. A tak většina uživatelů dává přednst specializvaným prduktům před univerzálními. Obzvláště v prjektvém řízení, kde jednznačně zatím vládne MS Prject. 4 Trendy ve vývji nástrjů řízení prjektů 4.1 Nástrje pr řízení prjektů Asi nejznámějšími nástrji pr řízení prjektů jsu Micrsft Office Prject a Primavera Prject Management. Oba nástrje nabízí efektivní prstředí pr řízení prjektů s výhdným pměrem 9
využitelnsti, účinnsti a flexibility, který zajišťuje efektivnější a účinnější vedení prjektů. Zajišťují stálu infrmvanst a kntrlu nad prací na prjektu, plány a financemi. MS Prject pmáhá zachvat infrmvanst a vyšší prduktivitu prjektvých týmů díky integraci se známými aplikacemi systému Micrsft Office. Primavera zase napak plývá plně webvým rzhraním pkrývající celý živtní cyklus prjektu d jeh zahájení až p uknčení. 4.2 Nvé funkce a trendy, kterými se ubírají Stejně tak, jak každá nvá verze prgramu, i MS Prject 2007 i Primavera Prject Management přinášejí něklik nvých funkcí a vylepšení. Tyt funkce přinášejí nvé mžnsti v řízení prjektů a zárveň určují směr, kterým se budu dané nástrje z tét skupiny ubírat. V následující části jsu ppsány nvinky bu výše zmíněných nástrjů. 4.3 Sada nástrjů MS Prject (14) 4.3.1 Principy a kntrla plánů a financí prjektů Uživatel má mžnst účinně sledvat a analyzvat prjekty díky lepšímu przumění plánu a dpadu změn. Přínsem je lepší kntrla financí a mžnsti analýzy. Mezi nvé funkce tht nástrje se řadí: Sledvání zdrjů prblémů: Umžňuje uživateli rychle určit faktry vlivňující data úklů a snadn sledvat zdrj prblémů, aby se zvýšila zdpvědnst a kvalita. Ovladače úklů pmhu určit faktr (například závislst úklů, mezení kalendáře, datum plánvání neb vlný čas) určující datum zahájení úklu, takže můžete zpětně sledvat řadu faktrů a zjistit tak základní příčinu knkrétníh zpždění. Sledvání dpadů změny: Aplikace Office Prject 2007 autmaticky zvýrazní všechny plžky, které se dsuvají v důsledku napsledy prvedené změny. Zvýraznění změn umžňuje lépe przumět dpadům změn. Experimentvání se scénáři citlivstních analýz: Pmcí příkazů Zpět a Znvu může uživatel vracet zpět změny phledů, dat a mžnstí na více úrvních. Může vracet zpět akce neb skupiny akcí včetně maker a vyzkušet tak něklik scénářů citlivstních analýz. 10
Obrázek 4 Ukázka analýzy scénáře Snadná kntrla financí: Pmcí ple rzpčtu může uživatel přiřazvat rzpčty k prjektům a prgramům. Nvý typ nákladvéh zdrje vylepšuje dhady a sledvání nákladů. Mezi další vylepšení nákladů patří více předdefinvaných plí (například kód nákladů), která se mapují na finanční ple sledvaná v účetních systémech prjektu. Flexibilní sledvání a analýzy prjektů: Definváním vlastních plí zalžených na vzrcích umžňuje vypčítat a sledvat základní měřítka jedinečná pr daný prjekt. Grafické indikátry navíc mhu upzrnit na splnění knkrétních pdmínek. 4.3.2 Efektivní předávání a prezentace infrmací prjektech Uspřádání a rganizaci prjektů a lidí je mžn vylepšit díky plánvání nabízenému aplikací Office Prject Standard 2007. Lze snadn vykazvat a sdělvat infrmace v různých frmátech pdle ptřeb zúčastněných stran. Pužití grafů a diagramů: Funkce Vizuální sestavy využívá aplikace Micrsft Office Excel a Micrsft Office Visi Prfessinal k vytváření kntingenčních tabulek, grafů, diagramů a přehledů zalžených na datech aplikace Prject. Uživatel může snadn definvat vlastní šablny sestav a sdílet je s statními uživateli aplikace Prject. 11
Obrázek 5 Pužití grafů a diagramů Přidání zvýraznění: Barvu pzadí buňky neb řádku lze změnit pmcí funkce Zvýraznění pzadí buněk. Stínváním buněk, jež se prvádí pdbně jak v aplikaci Excel, lze prjektu ddat další význam. Obrázek 6 Zvýrazňvání Pužití vylepšenéh zbrazení: Díky nvým vylepšením rzhraní kalendáře a přidáním prstrvých pruhů Ganttva diagramu lze vytvřit nvé a alternativní sestavy. 12
Sdílení infrmací: Ke sdílení a správě dkumentů suvisejících s prjekty služí pracvní prstry služby Micrsft Windws SharePint Services (vyžadují Micrsft Windws Server 2003 neb nvější). 4.3.3 Rychlé zajištění prduktivity Aplikace Office Prject 2007 pmáhá lépe zrganizvat práci i tým a zajistit, aby prjekty byly ddány včas a v rámci rzpčtu. Pstup pdle Průvdce prjektem: V průvdci prjektem je k dispzici interaktivní návd, který pmáhá nastavit prjekty, řídit úkly a zdrje, sledvat stav a vykazvat prjektvé infrmace. Obrázek 7 Průvdce prjektem Získání nápvědy: Integrvaná nline nápvěda služí k získání dalších šklení, článků, šabln a zdrjů. Při práci uživatel získá včasnu a relevantní pmc díky značkám upzrňujícím na alternativy při prvádění změn plánu. Úspra času díky šablnám: Lze vytvářet vlastní šablny pužitelné některu z mnha nvých předdefinvaných šabln. 13
14
Obrázek 9 Rzpis přiřazení nákladů úklu v aplikaci MS Prject Obrázek 10 Úpravy sazby zdrje v aplikaci MS Prject Obrázek 8 Příprava rzkladu úklů prjektu v aplikaci MS Prject 15
4.4 Sada nástrjů Primavera Prject Management (15) 4.4.1 Funkce řešení prjektu Prject Initiatin: Funkce Prject Initiatin pmáhá eliminvat prdlení, které je spjen s délku prcesu schvalvání. Řešení zajišťuje, aby při zahájení prjektu nastupil knfigurvatelný prces schvalvání. Obrázek 11 Inicializace prjektu v Primavera Prject Management Laverage Best Practises: Pskytuje knihvnu předem vytvřených a katalgizvaných šabln, které umžňují rychleji a přesněji vytvářet prjektvé plány a které rganizacím umžňují úspěšně a pakvaně využívat znalsti svých dbrníků na knkrétní blasti. Interactive Web Gantt Chart: Interaktivní webvý Ganttův diagram umžňuje přidávat, mazat a měnit strukturu WBS, činnsti, vztahy, přidělení prstředků a náklady. CPM Scheduling: Umžňuje plánvat prjekt z prstředí Web Prject Management, které je sučástí řešení. Issues Management: Prtkl zaznamenávající prblémy, který umžňuje uživatelům přidávat a aktualizvat prblémy. Threaded Discussins: Prtlety pr diskusi a splupráci umžňují uživatelům nline knverzaci hledně prjektů, aktivit neb prblémů. Prject Cst Tracking: Sučást Primavery vytvřený pr sledvání půvdníh rzpčtu, aktuálníh užívání k danému datu a nevyřízených úklů. Centralized Dcument Management: Služící pr ukládání prjektvých dkumentů suvisejících s činnstmi, prblémy, nline diskusemi neb pzvánkami na zasedání prjektvéh týmu. Směrvání dkumentů pr účely kntrly, správa verzí a histrie dkumentů. 16
Baselines: Funkce Baselines zachycuje půvdní plán prjektu a umžňuje, aby si celý tým byl vědm svéh výknu. Vyhdncuje klíčvé indikátry výknu, jak jsu dchylky a dsažená hdnta. Prject Reprts: Umžňuje vybrat z více než 150 předem definvaných sestav a nemezenéh pčtu uživatelských sestav. Dashbards: Knfigurvatelné tabule typu dashbard k prjektu mhu zbrazvat až 30 různých typů prtletů, přičemž každý může bsahvat různé klíčvé indikátry výknu (KPI). 4.5 Prvnání nástrjů Na druhu stranu jsu dnes znvu patrné tendence integraci pdpůrných nástrjů zaměřených na suvisející činnsti, jakými jsu např. řízení prjektů. CASE nástrje mají jednznačně své pevné míst v prjektvých týmech, zvláště dnes při rstucí slžitsti navrhvaných prgramů a sftwarvých řešení. C se funkčnsti nástrjů týče, tak trendem v tét blasti je přinést uživateli, c mžná nejvíce funkcí pr ulehčení řízení prjektu a zárveň snaha minimalizaci chybvsti lidskéh faktru při řízení. Směr, kterým se ubírají ba výše zmíněné prdukty, jsu ve své pdstatě pdbné. Hlavním rzdílem je způsb přístupu a t lkálně v případě MS Prject a přes webvé rzhraní v případě Primavera Prject Management. 4.6 CASE nástrje v suvislsti s řízením prjektů C se týká pdpry řízení prjektů CASE nástrjem, prf. Řepa ji vidí převážně v těcht blastech: Pdpra týmvé práce (definvání různých rlí, řízení přístupu, verzvání kmpnent, sdílená repsitry apd.) CASE jak nástrj řízení živtníh cyklu infrmačníh systému (tak jak jsme h ppsali výše) CASE jak nástrj pr řízení prtflia prjektů Pdle živtníh cyklu vývje sftware lze CASE nástrje rzdělit d následujících skupin: Pre CASE pdprují tvrbu glbální strategie. Upper CASE pdprují plánvání, specifikaci pžadavků, mdelvání rganizace pdniku a glbální analýzu IS. Hlavním úklem nástrje je analýza rganizace, zachycení prcesů v rganizaci, definice klíčvých infrmačních tků a dkumentace zjištěných pžadavků. Middle CASE pdprují pdrbnu specifikaci pžadavků a vlastní návrh systému. Tat třída CASE nástrjů je nejúspěšnější. Pužívají se pr pdrbnu specifikaci pžadavků, návrh systému, dkumentaci a vizualizaci systému. Dále CASE nástrje tét kategrie bsahují systém 17
správy dkumentů a knfigurace, systém pr vyhdncvání metrik, vývj prttypů, návrh rzhraní. Mhu bsahvat také generátry brazvkvých frmulářů a tiskvých sestav a také generátry (kstry) definic dat. Tent druh CASE je jádrem kmerčně ddávaných CASE systémů. Lwer CASE bsahují nástrje pr pdpru kódvání, testvání, údržby a reverzníh inženýrství. Integrvány jsu nástrje, jak jsu generátry kódu (mhu genervat jen kstru neb až 75 prcent výslednéh kódu, kde prgramátr dplňuje většinu jen detaily). Dále pak jde prstředky pr reverse engineering (reknstrukce dkumentace a mdelů z existujícíh SW), prstředky pr sledvání a vyhdncení metrik, prstředky plánvání a zjištění kvality SW (sběr infrmací průběhu testvání, vyhdncení výsledků testů, řízení testvání), pr správu knfigurace, prstředky sledvání a vyhdncvání práce systému. Pst CASE pdpruje rganizační činnsti (zavedení, údržbu a rzvj IS). Obrázek 12 Živtní cyklus vývje SW 5 Praktická část V praktické části tét práce se pkusíme bjasnit, ve kterých fázích živtníh cyklu IS je vhdné využívat mžnstí CASE nástrjů, a pr které z nich napak jejich využití mžné není. Pr ukázky pužití CASE nástrjů v jedntlivých etapách vývje IS jsme využili nástrj PwerDesigner. 5.1 Sučasné mžnsti CASE nástrje PwerDesigner PwerDesigner je vyvíjen splečnstí Sybase a patří d skupiny prduktů, které se zaměřují na Enterprise Architecture. Úklem tht CASE nástrje je anlalýza, mdelvání a ptimalizace firemních prcesů. V sučasné dbě je aktuální verze 15, která navazuje na svéh předchůdce verzi 12 (verze 13 a 14 byly z bchdních důvdů splečnstí Sybase přeskčeny). Jaké jsu tedy mžnsti tht nástrje? (5) 18
5.1.1 Klasické mžnsti PwerDesigneru (7) Hlavní využití PwerDesigneru je při analýze infrmačníh systému. Jeh hlavní přednstí je datvé mdelvání, všem nabízí mduly zabývající se prcesní analýzu či bjektvým mdelváním. Služí k mdelvání vyvíjenéh systému nejen pdle strukturvaných metd (Data Flw diagram, datvý mdel, tvrba datvéh slvníku apd.), ale i pužitím bjektvéh přístupu. Již samzřejmstí je pdpra jazyka UML a 3 úrvňvá architektura (knceptuální, lgická a fyzická). Pr práci v týmu, která je ve většině případů naprst stěžejní, nabízí PwerDesigner úlžiště mdelů repsitry. Ta je řešena v relační databázi a umžňuji i vzdálený přístup. Nyní něklik klíčvých charakteristik: 5.1.1.1 Mdelvací techniky(6) Mdelvání business prcesů (BPM) Datvé mdelvání Mdelvání zalžené na principu tří architektur a mdelvání datvých skladů. Pdpra Javy, XML a webvých služeb v databázích XML mdelvání Pdpra XML DTD a Schema elementů Objektvé mdelvání mdely vycházející z UML 1.x a 2.0, širké mžnsti úprav pdle ptřeb uživatelů Pdprvané platfrmy Prcesy BPMN, ebxml, BPEL4WS, pdpra SOA RDBMS Obusměrný engineering pr téměř 60 relačních databází včetně nejnvějších verzí Oracle, IBM DB/2, MS SQL Server, Sybase Objektvé jazyky Obusměrný engineering pr jazyky Java, C#, C++, PwerBuilder, XML, VB.NET (viz brázek 2) Integrace při vývji Plug iny pr synchrnizaci kódu s mdelem v nástrjích Eclipse, PwerBuilder a Visual Studi 19
Obrázek 13 Výběr prcess language Obrázek 14 Výběr bject language 5.1.2 Ppis prduktu PwerDesigner(6) Nvá verze dává pdnikvým architektům, IT analytikům a bchdním manažerům mžnst vylepšit prpjení IT a firemních cílů. T vše díky nvé technlgii LINK AND SYNCH. Krmě th Sybase 20
PwerDesigner 15 vylepšuje analýzu dpadu a tím zajistí lepší infrmvanst všech účastníků prcesu bez hledu na jejich technické znalsti. 5.1.3 Reference Pr bchdní stratégy, prjektanty a analytiky má nvá verze nástrje značný příns. Pmáhá jim lépe pchpit kmplexní systém IT zdrjů a jeh pdpru bchdní činnsti, píše Greta Jamesvá, viceprezidentka Gartner* nezávislé splečnsti pr výzkum a pradenství. V dnešních slžitých IT prstředích musí splečnsti přesně přizpůsbit různé IT kmpnenty (systémy, data, aplikace a síť) bchdním cílům, prcesům a pžadavkům. Analýza každé kmpnenty se prvádí dděleně. PwerDesigner dstraňuje nevýhdu ddělené analýzy a vzájemným prpjením analyzvaných kmpnent zajistí mžnst rychle reagvat na změny. V důsledku th je splečnst mnhem perativnější a reaguje na cíle jedntlivých bchdních jedntek. Nástup Pdnikvé/Enterprise architektury je důkazem th, že pr rganizace je nevyhnutelné reagvat na změny v knkurenčním prstředí, technlgiích a legislativních nařízeních. Tyt změny je nutné prmítat d všech částí firmy. Unikátní technlgie Link and Synch bsažená v aplikaci PwerDesigner 15 dává rganizacím mžnst realizvat řešení pdnikvé architektury d začátku až d knce, takže dstraní ddělení bchdní analýzy a analýzy metadat. Tím se zvýší perativnst celéh pdniku. Operativnst je mimřádně důležitá v případě bchdních změn. Stále více firem přechází na strategii Unwired Enterprise a přesunuje infrmace blíže ke kncvým uživatelům, prt rste důležitst technlgií, které zajišťují lepší řízení IT infrastruktury. PwerDesigner 15 umžňuje snížit celkvé náklady a eliminvat nadbytečné systémvé krky, cž z něj dělá velmi výknný nástrj pr mdelvání a správu metadat. Nvá verze umžňuje snadnu analýzu a měření dpadu mezi sučasným stavem a cílvým stavem a zajišťuje přesné, předvídatelné a splehlivé plánvání IT zdrjů v suladu s bchdními cíli(5). 5.1.4 Nvé mžnsti PwerDesigneru 15 (6) C můžeme získat u pslední verze PwerDesigneru? Jaké nvé funkce přináší? Můžeme zaznamenat, že většina změn je spíše ksmetických jedná se vylepšení stávajících funkcí, žádné revluční invace v nvé verzi nenalezneme. Přest bychm zmínili následující tři vylepšení: technlgie Link and Synch zachycuje průniky mezi všemi vrstvami architektury pdniku, cž umžňuje uživatelům ze všech skupin vizualizvat a zavádět změny. webvý prhlížeč úlžiště mdelů je mžné sdílet mdely pdnikvé architektury mezi všechny zainteresvané pracvníky bez hledu na jejich sftwarvé vybavení, zbrazvat diagramy, prhledávat repsitry neb sdílet metadata 21
Editr pdnikvé architektury: PwerDesigner 15 pskytuje jak standardní metdicku šablnu mdelů (metdika FEAF) tak mžnst vytvření vlastní šablny. diagram analýzy dpadů vizualizace kaskádvéh dpadu změn, řízení času i nákladů suvisejících se změnu Nvý imprt z Visi: Dává mžnst využít bchdních metadat pr začlenění d kmpletní pdnikvé architektury. 5.2 Základní principy MMDIS 5.2.1 Metdika MMDIS MMDIS nebli Multidimensinal Management and Develpment f Infrmatin Systém je metdika vyvíjena d začátku 90. let na katedře infrmačních technlgií VŠE. Jejím hlavním prpagátrem je prfesr Vříšek. Cílem tét metdlgie je vývj a údržba kmplexníh integrvanéh IS, který ptimálně pdpruje pdnikvé cíle a prcesy. MMDIS patří d skupiny glbálních metdik se střední váhu. Využití nalezne například při vývji neb rzšíření nvých aplikací či služeb, integrace aplikací či služeb, custmizace a implementace typvéh řešení a v dalších situacích. MMDIS má něklik fází (8): Glbální pdnikvá strategie (GST) Infrmační strategie (IST) Úvdní studie (US) Glbální analýza a návrh (GAN) Detailní analýza a návrh (DAN) Implementace (IM) Zavádění systému (ZA) Prvz a údržba (PU) Vyřazení systému (VY) Hlavní myšlenku je všem právě rzdělení na něklik phledů (dimenzí), kterými můžeme na prjekt nahlížet: Sftware prgramvé vybavení systému, určuje typ, parametry a vzájemné vazby jedntlivých kmpnent 22
Hardware technické vybavení systému, určuje typy, parametry a pčty pčítačů, periferních zařízení a kmunikačních sítí Funkce a prcesy zaměřena na prcesy prbíhající v pdniku a jejich mžnu pdpru IS Organizační a legislativní zákny, nrmy a směrnice, které musí IS respektvat, rganizační strukturu pdniku platnu v dbě prvzu jedntlivých verzí IS Eknmická zahrnuje finanční náklady na tvrbu a prvz IS, časvý harmngram plateb Datvá jaké typy infrmací jsu ptřebné pr pdnikvé funkce, jaký bsah a jaku strukturu bude mít datvá základna, a jak budu dané infrmace fyzicky ulženy Pracvní, sciální a etická ptřebné znalsti zaměstnanců, partnerů i zákazníků Základem metdy MMDIS je 11 základních principů multidimenzinalita, vrstvenst, integrace, flexibilita, tevřenst, standardizace, kperace, prcesní pjetí, učení a růstu, lkalizace zdrjů a rzhdnutí a měřitelnst(12). 5.2.2 Pravidla multidimenzinality: (8) Identifikuj všechny dimenze vlivňující řešení prblému Vyřeš prblém nejdříve z phledu každé definvané dimenze Integruj separátní řešení d výslednéh řešení (kmbinace dimenzí a ptimalizace) Základem metdiky MMDIS je tedy nahlížení na řešený prblém z něklika phledů, cž nám pmůže lépe si vytvřit následně celkvý nástin prblému. Využití CASE nástrjů pr řízení prjektů je pměrně btížné a t z důvdu absence mžnsti zachycení časvé linky prjektu. Vezmeme li však v ptaz prblematiku řízení prjektu vývje IS/ICT, pak mají CASE nástrje pr řízení takvéh typu prjektu své nedmyslitelné uplatnění. 5.3 Glbální pdnikvá strategie (GST) (9) 23
Určuje hlavní zaměření pdniku Stanvuje pdnikvé cíle, kterých má být v daném bdbí dsažen a jejich priritní uspřádání Definuje zdrje, které budu k dispzici pr realizaci cílů Definuje způsb věřvání plnění stanvených cílů pdniku Určuje sby dpvědné za dsažení jedntlivých vytyčených cílů Zpracvává se pr střednědbý časvý hriznt Pdléhá změnám v závislsti na změnách vnějších a vnitřních pdmínek firmy Bývá v pravidelných peridách hdncena a aktualizvána 5.3.1 Kritické faktry úspěchu pdnikatelské strategie Faktry (měřitelné) jejichž naplnění je měřítkem úspěšnsti pdnikatelské strategie Naplnění každéh z nich je pdmínku nutnu pr pdnikatelský úspěch Naplnění všech faktrů je pdmínku pstačující 5.3.2 Mžnsti pužití CASE nástrje v tét etapě Jak z ppisu vychází, glbální strategie pdniku je rzsáhlý dkument, který vytváří sama firma (zákazník). Tat etapa předchází samtnému řízení prjektu IS/ICT a je nezbytná pr kvalitní průběh implementace. V tét etapě zpravidla nebývá žádný CASE nástrj využíván. 5.4 Infrmační strategie (IST) (9) Pskytuje základní strategický rámec pr vývj IS Stanvuje cíle a předpklady pr aplikaci IS v pdniku Stanvuje pririty a plánů prjektů, dhady času, zdrjů, přínsů v krátkdbém a střednědbém časvém hrizntu Obsahuje architekturu IS/IT : Síť kmpnent IS/IT v pdniku 24
Phled na IS/IT v pdniku jak na celek Sučasný stav Cílvý stav Plán přechdu ze sučasnéh d cílvéh stavu (9) 5.4.1 Mžnsti pužití CASE nástrje v tét etapě Infrmační strategie je stejně tak jak pdnikvá strategie tvřena zákazníkem. Pužití CASE nástrje v tét etapě není vylučen. K jeh využití však v tét fázi dchází zejména pr grafické zachycení glbálníh phledu na IS/ICT. (10) Zákazníci Aplikační server Internet Webvý server Databázvý server Zaměstnanci Obrázek 15 Glbální náhled na architekturu IS/ICT 5.5 Úvdní studie (US) 5.5.1 Dílčí úkly etapy (9) Analýza sučasnéh IS Vymezení hranic systému Ppsání prblémů sučasnéh IS Analýza pžadavků na změny 25
Výknnst, přání a pžadavky uživatelů, pririty změn, mezení, bezpečnst IS Detailní stanvení pžadavků na nvý systém Organizační pžadavky Technlgické a uživatelské rzhraní Eknmické prstředí Definvání cíle řešení Zpracvání kncepce systému Hranice systému Hlavní funkce, vstupy a výstupy Hrubý datvý mdel Návrh alternativ pr realizaci Hrubý návrh realizace Zvážení technlgických, eknmických, sciálních, rganizačních a plitických vlivů Přizpůsbení dstupným technlgiím a existujícím systémům Stanvení kriterií pr hdncení alternativ realizace Bezpečnst, splehlivst, pružnst, dby dezvy Náklady, nárky na rekvalifikaci, zdrje, jednduchst zavedení Technické nárky (základní HW studie) Vliv na změny rganizační struktury, apd. Hdncení alternativ dle stanvených kriterií Studie realizvatelnsti jedntlivých kncepcí řešení Výběr varianty řešení a následné zdůvdnění Prezentace vybranéh řešení (a zdůvdnění výběru) vedení pdniku Rzhdnutí vedení rganizace realizaci prjektu Rzhdnutí způsbu realizace (interní vývj x utsurcing) Vytvření plánu pr analýzu, implementaci a zavedení 26
5.5.2 Mžnsti pužití CASE nástrje v tét etapě Tat etapa již plně spadá d řízení prjektů IS/ICT a vypracvává ji specializvaný prjektvý tým. V tét fázi je však užití CASE nástrje zejména pr tyt 4 aspekty: 1) Zpracvání hrubých mdelů pr účely věření návrhu základních záknitstí 2) Seznámení zainteresvaných stran s pžadavky na systém a základními záknitstmi systému 3) Znázrnění využití systému a kntextu systému v prstředí externích systémů a kmpnent 4)Výchzí věření prveditelnsti implementace IS 5.6 Glbální analýza a návrh (GAN) 5.6.1 Dílčí úkly etapy (9) Zpdrbnění pžadavků na systém, zjištěných v ÚST Úplná specifikace hlavních funkcí systému Specifikace (a kvantifikace) dat Oddělení knceptuálních, technlgických a implementačních pžadavků Jde knceptuální úrveň analýzy a návrhu systému C musí aplikace vykvávat (hlavní funkce) Které datvé bjekty jsu pdstatné Jaké jsu vlastnsti bjektů a funkcí Vytvření struktury systému a subsystémů Návrhy rzhraní: systém < > jiné systémy, mezi subsystémy Knkretizace schvalvacích prcedur pr jedntlivá dílčí řešení Další rzpracvání plánů testů vyplývajících ze znalsti vstupů a výstupů, akceptační testy 5.6.2 Mžnsti pužití CASE nástrje v tét etapě V tét fázi vývje IS je využití CASE nástrje prakticky nezbytné. Bez kvalitníh namdelvání jedntlivých prcesů apd. nelze prjekt IS kvalitně implementvat. Vypracvání tht dkumentu je při řízení prjektů stěžejní. Pmcí CASE nástrje v tét fázi můžeme dkumentvat např. klíčvé a statní prcesy, zpracvat bjektvý mdel či kntextvý diagram. Při řízení prjektu je v tét fázi nezbytné dbát na t, aby byla zachycena všechna specifika funkčnsti dané firmy. Vhdné je pr snazší krdinaci prjektu využívat repsitury. 27
Pužití CASE nástrje je v tét fázi demnstrván na prjektu fiktivní firmy 1. Česká letištní. 5.6.3 Krátký ppis splečnsti (pr snazší pchpení diagramů) Splečnst 1. Česká letištní s r.. (dále jen 1ČL) se rientuje na trhu jak správce letiště v Praze. Její zaměření je jak na nákladní dpravu, kde firma patří mezi největší splečnsti v blasti, tak i na přepravu cestujících. Rční bjem materiálu, jenž letiště přijme a dbaví, se pčítá v desítkách tisíců tun, prti tmu mnžství cestujících, jež prjdu letištěm, se blíží k 1 mil. Splečnst nabízí v blasti nákladní dpravy další ddatečné služby jak krátkdbé uskladnění materiálu, servis letadel v případě vzniku pruchy letadla, dtankvání paliv apd. Dále jsu nabízeny k prnájmu celé sklady na letišti, které si rezervují jedntliví zákazníci, cž jsu letečtí přepravci, kurýři a jim pdbné splečnsti zabývající se přepravu materiálu. Cestující napak mhu využít veškerých kmfrtních služeb letiště např. taxi služby, ubytvání přím na letišti, VIP salónky, restaurace, balení zavazadel, parkvání auta apd. Hlavní business splečnsti se dělí na dvě klíčvé blasti: Přeprava sb letiště z každéh cestujícíh získává peníze ve frmě bezpečnstních a letištních pplatků, další služby se týkají samtných leteckých splečnstí, které platí pplatky za: mžnst vůbec dsednut na letiště, pzemní služby, catering a úklid (pkud je zajišťván letištěm), zaparkvání letadel, pužití autbusů k dpravě sb d letadla apd. Material handlingu letiště je tranzitní uzel, jež přijímá, uskladňuje, zabezpečuje a pět předává zbží dále. Přepravce tak platí letišti za každé uskladnění zbží či prnájem hal apd. Ukázka jedntlivých diagramů: 5.6.3.1 Class diagram Tent diagram zachycuje hlavní analyzvané entity a dále je rzšířen dplňující entity, které jsu ptřeba pr upřesnění kmpletníh datvéh mdelu. 28
Obrázek 16 Class diagram letištní splečnst (9) 5.6.3.2 Prcesní diagram 29
Diagram zachycuje mnitring dcházky zaměstnanců letiště Zaměstnanec HR Šéf ddělení Příchd zaměstnance Nvý zamestnanec <<ANO>> <<NE>> Zalžení d DB Zaznamenání příchdu d systému Zaznamenání dchdu Schválení výkazu Výkaz času práce <<NE>> Schváln <<ANO>> Knec prcesu Obr. Prcess diagram mnitring dcházky zaměstanců letiště (9) 30
5.6.3.3 Data flw diagram Diagram je glbálním phledem na jedntlivé datvé tky firmy a zachycuje jejich transfrmaci ze vstupních tků na tky výstupní. 4 3 Catering reklamace Catering bjednávka pžadavek bjednávky vyrízení reklamace 5 infrmace stavu bjednávky infrmace stavu Dcházka reklamace zamestnancu Údaje kapacitách 1 pžadavek na bjednání cateringu 4 Catering 24 Reklamace 23 Carg Catering ddávka Infrmace zaměstnancích Infrmace nákladu 8 infrmace stavu cateringu Infrmace kntrle Evidence prtklu Stav zaměstnance 18 Výdej nákladu Infrmace zaměstnancích Údaje kapacitách Kntrla zamestnancu Bezpečnstní patření Infrmace nákladu Infrmace pstupu Ddání 2 Catering kntrla hygieny 2 Zamestnanec Vyrízený pžadavek Pžadavek na nakládku Vyrízený pžadavek 13 9 Kntrla zavazadel Infrmace pstupu 26 Bezpecnstní pstup Bezpečnstní patření vkládání infrmací zamestnancích Príjem nákladu Objednání 11 Kvalifikace zamestnance Pžadavek na vykládku Infrmace pstupu stav výbervéh rízení Nábr zamestnancu Infrmace zamestnanci 23 Zákazník Predání letadla Pvlení k dletu Žádst dlet 10 Zavazadl Evidence zavazadla Plicejní zásah Pžadavek na zásah 10 Mnitrvání sb Externí firma Uchazeč Údaje šklení Šklení Pžadavek na hangárvání Vyrízený pžadavek Žádst prelžení Parametry zavazadla 14 Ptvrzení zmeny Príjem zavazadel Pžadavek na zásah Plicie Plicejní zásah 5 Šklení Evaluace Servisní pžadavek 17 Servis Letadel 19 Objednání Rezervace 6 Hangárvání Infrmace kapacitách Výdej zavazadel Vrácené zavazadl Odevzdání zavazadla Ddání vydej zavazadel cestujícím 1 Nebytvý prstr Infrmace kapacitách Servis Infrmace letadlu Cestující 20 Zásbvání letište Infrmace prstru Infrmace údržbe 9 Servis letadel Infrmace servisu Žádst pristání Žádst timeslt Pdávání infrmací Stav zásb Aktualizace stavu 22 Infrmace servisu 12 Odlet letadla Žádst infrmace 13 Zásba Údržba prstr Infrmace zdrjích Uvlnení zdrju 27 Údržba Rezervace timesltu Infrmace pcasí Infrmace timesltech Pvlení k pristání 7 Infrmvání cestujících Stav timesltu Infrmace timesltech 25 Meterlgie Infrmace pcasí Infrmace timesltech 8 Timeslt Update timesltu Infrmace pcasí 15 Stav timesltu Rezervace Infrmace timesltech Prílet letadla Infrmace timesltech 21 Zmena timesltu 16 Rezervace timesltu 5.7 Detailní analýza a návrh (DAN) 5.7.1 Dílčí úkly etapy (9) Obrázek 17 DFD letištní splečnst (9) Transfrmace knceptuální úrvně návrhu d technlgické Pdrbná funkční a datvá analýza Pdrbný funkční a datvý mdel, mdel chvání apd. Návrh uživatelskéh rzhraní 31
Pdrbné prvěření návrhu před implementací Zpracvání plánu implementace Krdinace řešitelských týmů vypracvání knečné verze schvalvacích prcedur a plánů všech testů zpracvání předpkladů a plánu pr zavádění systému 5.7.2 Mžnsti pužití CASE nástrje v tét etapě Pr tut etapu prjektu je pužití CASE nástrje taktéž naprst nezbytné. V tét fázi již na jedntlivé entity phlížíme detailněji. Pr ukázku jsme zvlili rzpad základníh DFD diagramu z glbální analýzy 1. ČL (viz předchzí kapitla) na něklik detailně rzebraných částí. I v tét části prjektvéh řízení může být repsitury vítaným pmcníkem. 5.7.2.1 Objednávka Diagram zachycuje datvý tk při realizaci bjednávky. 3.42 vyhdncení bjednávky ptvrzení navrhvanýc h bjednávek 3.42 infrmace pžadavku bjednávky 4 Catering infrmace rezervaci rezervace bjednávky Obrázek 18 DFD realizace bjednávek (9) 5.7.2.2 Reklamace Diagram zachycuje datvý tk při realizaci reklamace. 32
4.42 4 Catering zaevidvání reklamacní událsti infrmace patrení Reklamace evidence reklamace predání cateringu 4.42 prijetí patrení evidence patrení 24 Reklamace Opatření predání reklamace 4.42 predání veducímu služeb cateringu 5.7.2.3 Dcházka zaměstnanců Obrázek 19 DFD reklamace (9) Diagram zachycuje datvý tk mapující evidenci dcházky zaměstnanců. 2 Zamestnanec 5.42 Pžavek na vytvrení výkazu Vytvření výkazu 5.42 Záznamenání príchdu Pžadavek na zaznamenání 5.42 5.42 Vyhdncvání výkazu Záznamenání dchdu Sestavení výkazu Pžadavek na vyhdncení Pžadavek na schválení 5.42 5.42 5.42 Sestavení výkazu práce Zamítnutý výkaz Schválení výkazu Schválený výkaz Ulžení výkazu Obrázek 20 DFD evidence dcházky zaměstnanců (9) 33
5.8 Implementace (IM) 5.8.1 Dílčí úkly etapy (9) tvrba a ladění prgramů, úpravy nakupených aplikačních prduktů šklení uživatelů testvání prgramvých mdulů a systému jak celku vytvření prgramvé dkumentace tvrba uživatelských příruček zpracvání havarijních plánů scénářů řešení nestandardních situací příprava migrace dat 5.8.2 Mžnsti pužití CASE nástrje v tét etapě V tét fázi je pužití CASE nástrjů částečně diskutabilní. Analýza je htva, ale pkud se až v tét etapě bjeví nutnst dklnu d DAN, je zvláště nutná pečlivá analýza nezbytných dchylek v kntextu návaznsti s nezměněnými částmi systému a věření funkcinality měněných částí. Pr řízení prjektů je také vhdné mít prcesně zpracvané jedntlivé činnsti pracvníku implementačníh týmu. Pr tyt ptřeby by měla služit firemní metdika. Pkud však takvý dkument przatím neexistuje neb je nedstatečně zpracván, je vhdné některé pstupy zdkumentvat. 5.8.3 Příklad využití CASE nástrje na skutečné implementaci IS K2 d knkrétní firmy 5.8.3.1 Diagram prgramvání speciálních úprav úprav. Diagram zachycuje custmizaci IS, tedy prgramvání jedntlivých pžadvaných spceciálních 34
Nastudvání ppisu pžadvaných úprav ANO Úprava standardu? NE Upravení standardu Dhledání části kódu? ANO NE Sestavení prgramu Napsání nvéh prgramu Vlastní testvání ANO Nalezení chyby? Opravení chyby NE Tvrba dkumentace Interní testvání Obrázek 21 Prcess diagram prgramvání speciálů (10) 5.8.3.2 Diagram testvání Následující schéma ppisuje pstup při interním testvání. 35
Tvrba speciálu Přijetí speciálů a dkumentace Nastudvání dkumentace Rzepsání testvaných perací Testvací prtkl Zapsání chyb d prtklu Tvrba testvacích dat Testvání jedntlivých perací NE Funguje speciál? ANO Testvání zákazníkem 5.9 Zavádění systému (ZA) 5.9.1 Dílčí úkly etapy (9) Obrázek 22 Prcess digram interní testvání (10) Příprava rganizace a uživatelů na prvz IS změny v rganizační struktuře, přijímání nvých pracvníků resp. snižvání pčtu zaměstnanců Šklení uživatelů Instalace a knfigurace technickéh vybavení Instalace a knfigurace základníh SW např. databázvé servery 36
Instalace a knfigurace aplikačníh SW Migrace dat d nvéh IS Zpracvání prvzních řádů pr nvý IS Zkušební prvz IS Přechd na rutinní prvz 5.9.1.1 Mžnsti pužití CASE nástrje v tét etapě Tut fází největší intenzita prjektvéh řízení knčí. V tét etapě již dchází spíše k využití výstupů CASE nástrjů pr účely šklení klíčvých uživatelů a následné distribuce znalstí využití systému napříč spektrem relevantních uživatelů, případně využívání výstupů CASE nástrjů pr prvádění úklů pstupnéh náběhu IS (případně též pr účely migrace dat, viz ddíl vyřazení systému ). 5.10 Prvz a údržba (PU) 5.10.1 Dílčí úkly etapy (11) Pskytvání knzultačních a šklících služeb uživatelům Organizační a technické zajištění prvzu IS Údržba prgramvéh systému a dat Údržba dkumentace Realizace změn nvé verze prgramvých mdulů Záznamy uživatelských pžadavků 5.10.2 Mžnsti pužití CASE nástrje v tét etapě Využití CASE nástrjů již v tét fázi není tak intenzivní. Využívané jsu např. při mapvání a rzvíjení návrhů na zlepšení a změny využití systému. Následně jsu využity při designu a implementaci těcht změn zejména ve smyslu kntinuální evluce udržvanéh systému. Dalším hlediskem je pečlivá administrace prváděných změn zejména v prstředích: 1) IS ppř. klíčvá část IS je využívána větším mnžstvím externích kmpnent / systémů 2) Při pstupné evluci systému, případně při pdpře prvzu systému participuje větší mnžství bchdních subjektů neb pracvních skupin 37
5.11 Vyřazení systému (VY) (9) vyřazení systému je uknčením živtníh cyklu IS IS bývá zpravidla nahrazen nvým systémem (předchází migrace dat) 5.11.1 Mžnsti pužití CASE nástrje v tét etapě V tét fáze může být CASE nástrj využit pr pdpru designu a prvedení cutver plánu, zejména v setupech suběžnéh prvzu více generací, neb kmpnent využívanéh větším mnžstvím dalších systémů, ppř. ve velkém mnžství prcesů. S vyřazváním systému je většinu také spjen design a prvedení migrace dat (ppř. i genervání pčátečních vstupních dat) d nvě přízenéh IS. Zejména kritické aspekty migrace je nutné zachytit patřičnými diagramy. Instalace nvéh IS Určení typu subru Půvdní IS Určení struktury dat Subr Specializvaný sftware Imprt d subru Imprt d nvéh IS Testvání Nvý IS Obrázek 23 Knverze dat d nvéh IS 5.12 Prvnání MMDIS s kmerční metdiku ASAP (16) Pr zajímavst dplňujeme, že stejná lgika základních rzdělení fází, tak jak ji prvádí MMDIS, se dá vystpvat ve většině běžně využívaných metdik a strategií řízení prjektu. Jak příklad uvádíme prvnání s metdiku ASAP (Accelerated SAP), tradiční metdlgií při implementaci řešení na bázi prduktů splečnsti SAP AG. 5.12.1 C je t ASAP / AcceleratedSAP / ASAP Fcus? SAP AG (zalžen rku 1972 bývalými pracvníky IBM) je světvý ddavatel ERP řešení s hlavním sídlem v Německu (Waldrf). Minimálně v pdmínkách Evrpy je blasti velkých ERP řešení ddavatelem největším, v psledních letech je uváděn jak největší ddavatel těcht řešení becně. 38
Zaměstnává 51.447 pracvníků při bratu 16mld USD (2008). Tat firma vlastní sftware vyvíjí, v menší míře také implementuje. Nsným prduktem splečnsti SAP AG je SAP ERP (dříve SAP R/3), který je pstupně rzšiřván jak dalšími mduly tht systému (např. IS U Industry Slutin fr Utilities), případně nvými generacemi půvdních mdulů (RE Real Estate => RE FX Real Estate Flexible),,tak i dalšími samstatnými prdukty (např. CRM, datvý sklad BI Business Intelligence / BW Business Warehuse). Tt je řešen jak interním vývjem, tak i akvizicemi (BOBJ Business Objects). Většina implementací těcht prduktů prbíhá mim vlastní režii SAP AG (samstatnými implementátry, vlastním týmem, případně knzultanti SAP AG puze externě dhlížejí) a tudíž je prváděna firmami s typicky dlišnými interními metdikami. Přest pr účely pdpry implementace vlastníh systému SAP AG dpručuje specificku metdlgii ASAP (Accelerated SAP), cž je v drtivé většině případů ddržván. Tat metdlgie je nvě přejmenvána na Fcus ASAP ale vzhledem k tmu, že minimálně v českých pměrech není ještě tent termín příliš rzšířen a jeh využívání dle naší zkušensti přináší jisté zmatky, budeme dále uvádět tut metdlgii pd názvem půvdním. Tyt implementace trvají mezi 3 měsíci (agilní implementace menších řešení, přes typický 1 rk pr větší prjekty a 2 rky pr větší a nárčnější prjekty p zásadní implementace prbíhající p dbu něklika let (viz aktuálně prbíhající implementace Státní pkladny v ČR). Smyslem metdiky ASAP je pak minimalizace rizik těcht nárčných implementací a dále zvýšení ROI aplikací technik na minimalizaci a ptimalizaci implementační dby a minimalizaci veliksti a vytížení implementačníh týmu. 5.12.2 Samstatná úvdní studie Metdlgie ASAP jak takvá vlastní samstatnu část úvdní studie (tak jak MMDIS) nebsahuje. Přest je v běžné praxi pužívána ve frmě studie prveditelnsti, pkud si v pdmínkách přípravy nárčnéh prjektu není zákazník jistý vhdnstí knkrétních prduktů pr nestandardní účely (ppř. d nestandardních pdmínek). V tét studii jsu pkrývané funkcinality mapvány v kntextu pdnikvých prcesů zákazníka, dchází k identifikaci prblematických míst a je dhadnuta nárčnst nezbytných dplňujících vývjů. Následně se na základě tét studie zákazník rzhduje prvedení danéh prjektu. 5.12.3 Fáze 1 Příprava prjektu Úlhy dané v MMDIS úvdní studií se částečně překrývají s první fází metdiky ASAP Prject Preparatin, fází 1 dle metdiky ASAP. V rámci tét etapy je připraven následující: Definice cílů prjektu Příprava rámcvéh harmngramu prjektu (pzději detailizván dle ptřeby) 39
Definice technických pžadavků Definice rlí prjektvéh týmu Definice prjektvých dkumentů Základní rzdělení pkrytí business prcesů Úvdní kickff meeting prjektu seznámení prjektvéh týmu s výstupem předchzíh (zejména se základní strukturu prjektu, slžením týmu, přidělením zdpvědnstí) Nicméně, z tht rzpisu je jasné, že mnh úlh MMDIS ÚS je uskutečněn před vlastním zahájením prjektu implementace dle ASAP (tat metdika se jak takvá sustředí na phled jedntlivé implementace, nikliv na kntext zabezpečení pkrytí ICT pdpry rganizace tak jak MMDIS). Obrázek 24 ASAP Radmap (16) Základní výstupy tét fáze: Zalžení Issue Database v tmt dkumentu se evidují mimřádné prblémy (a jejich vyřešení), je zde bsažen zejména: Nečekávané úlhy (úlhy, se kterými se v předchzích fázích prjektu pr plnění aktuálních fází nepčítal) Očekávané úlhy, u kterých je prblém s jejich úspěšným vyřešením (případně včasným vyřešením) Nečekávaný vliv externích (a negativních) faktrů na průběh prjektu K jedntlivým prblémům je evidván (sledván vždy v kntextu histrie): Pririta 40
Fáze prjektu (ke které je prblém relevantní) Odpvědní pracvníci Vstupy ptřebné pr řešení prblému Termíny (etap řešení, finálníh vyřešení) Klasifikace prblému (chybějící zdrj, dkumentace, vývj...) Základní dkumenty prjektu: Pr využití v prjektu jsu ustanveny základní dkumenty prjektu a tým je seznámen s jejich využitím (některé z těcht dkumentů jsu v tét etapě zalženy, ale ještě většinu nemají faktický bsah, který je pstupně plněn a udržván v dalších etapách). Scpe prjektu Kmunikační matice, rzpis zdpvědnstí Základní supis pkrývaných prcesů Ppis systémvéh landscape Ppis technických pžadavků Šablny pracvních dkumentů Základní ppis designu řešení Dkumentace nastavení Dkumentace vývjů Dkumentace pr kncvé úživatele Využité patche (OSS Ntes) 5.12.4 Fáze 2 Příprava cílvéh knceptu / Business Blueprint V rámci ASAP není zřetelně ddělena fáze GAN a DAN tak jak v MMDIS. Přest se na úvdních schůzkách analytické fáze uživatelé seznamují se základními suvislstmi danéh systému (případně mdulu) a dchází k základnímu namapvání daných funkcinalit na business prcesy zákazníka a jejich přiřazení jedntlivým zdpvědným sbám / ddělením / rganizačním celkům. Teprve ptm dchází k detailizaci řešení d výslednéh cílvéh knceptu. Mnhdy je mžné základní rzčlenění zkrátit díky znalstem pracvníků zákazníka fungvání systému. 41
Základním smyslem tét fáze je přípava dkumentu Cílvý kncept / Business Blueprint detailníh rzpis nasazvanéh systému p jedntlivých mdulech, částech mdulů a prblematikách. Jak jsme uvedli, v tmt dkumentu splývá GAN s DAN přest lze říci, že v úvdních pdetapách je řešen GAN a v následujících pdetapách je přistupen k DAN. Tat fáze knčí akceptací dkumentu cílvéh knceptu zákazníkem a ddavatelem. Tent dkument je zcela závazný pr fázi realizace (tzn. pr dchýlení se d tht dkumentu je nutn využít řízení změnvých pžadavků / change requestů). Minimální rzpad kapitl dkumentu cílvý kncept pr jedntlivé implementvané části: Detailní ppis funkcinality nasazvané částí systému v kntextu ptřeb zákazníka Prcesní mdel Ppis nutných rzšíření / vývjů dané části Ppis návaznstí s statními částmi Ppis nárků na reprting Ppis nárků na migraci Autrizační kncept Peridické prady V tét fázi jsu zahájeny prady / kntrly pstupu prjektu. Tt je řešen na dvu úrvních: Status Meeting prjektvých týmů je kntrlván status prváděných prací p jedntlivých týmech, dále jsu prezentvány infrmace relevantní pr členy statních týmu a řešeny mezitýmvé návaznsti, případně i překrývání. Tt nejen ve smyslu navazujících funkcinalit, ale i ve smyslu navazujících prací mezi participujícími týmy. Steering Cmitee schůzky vedení prjektu prezentace statusu prjektu, případně i patření na tét úrvni (úpravy pžadvaných termínů, psilnění příp. změny kapacit atd.) Business Mdel Master List Identifikace jedntlivých prcesů (nejmenší jedntka je tzv. business prcess prcedure) Plánvání, mnitring analýzy a realizace jedntlivých prcesů Pdklad pr šklení a testvání Další aktivity Detailizace harmngramu prjektu dplnění půvdně zejména klíčvých milníků na rzpad na jedntlivé sledvané úlhy a jejich návaznsti 42