4IT450 CASE - Computer Aided Systems Engineering Závěrečná práce na téma: Řízení projektů metodou PRINCE2 s vazbou na Nástroje CASE

Transkript

1 4IT450 CASE - Computer Aided Systems Engineering Závěrečná práce na téma: Řízení projektů metodou PRINCE2 s vazbou na Nástroje CASE Vypracovaly: Čapková Lenka, Hanusová Lucie, Klápová Nikola, LS 2010/2011 Kulíšková Romana, Peterková Kateřina, Šímová Marie 1

2 Obsah Obsah... 2 Seznam použitých obrázků... 5 Uvedené tabulky... 6 Úvod Nástroje CASE Historie nástrojů CASE Nástroje CASE Druhy nástrojů CASE Komponenty nástrojů CASE Příklad nástroje CASE - QPR ProcessGuide Řízení projektů Definice slova projekt Vlastnosti projektu Řízení projektů a jeho cíle Fáze projektu PMBOK PRINCE RUP Metody řízení projektů PMBOK (Project Management Body of Knowledge) PRINCE2 (Projects in controlled environment) Metodika EPMS (Equilibrium - Project Management Solutions) Jak souvisí Nástroje CASE s řízením projektů Témata k modifikaci Business Case

3 4.1.1 Průběh Business Case Definování rolí v Business Case Ukázky z programu Project in a box Organizace (Organization) Projekt Struktura projektového managementu a její odpovědnosti dle PRINCE Plány (Plans) Plánování Dělení projektu Ukázky z programu Project in a box Pokrok (Progress) Účel Co je to Progress? Co jsou to Progress kontroly? Výjimky a odchylky PRINCE 2 - koncepce Ukázky programu - část Progress Riziko (Risk) Cíl Co je riziko Co je ohroženo Co je řízení rizik Projektová rizika Rozpoznání rizika Vyhodnocení rizika Vytvoření riziko vých plánů Sledování a řízení rizika

4 Ukázky z programu PROJECT in a box Kvalita (Quality) Účel Co je to kvalita? Plánování kvality PRINCE2 a přístup ke kvalitě Změna (Change) Účel Řízení změn Správa konfigurace Issues PRINCE2 a přístup ke změnám Závěr Použité zdroje

5 Seznam použitých obrázků 1 Vzhled programu QPR 2 Vzhled programu QPR 3 Vzhled programu QPR 4 Vzhled programu QPR 5 Životní cyklus projektu metodiky PMBOK podle Widermana 6 Životní cyklus projektu metodiky PMBOK podle Morrise 7 Životní cyklus projektu metodiky PMBOK podle Morrise 8 Průběh projektu z pohledu Business Case 9 Popis dokumentace 10 Celkový pohled na procesy 11 Sedm etap projektu 12 Definování organizace 13 Tvorba plánu 14 Úvodní obrazovka 15 Microsoft Project 16 Microsoft Excel 17 Přidělení rolí 18 Rozpracovanost plánů 19 Grafy 20 Výchozí obrazovka manažerského nástroje sloužícího pro kontrolu projektů 21 Excelový výstup ukazující splnění plánu podle osob v % 22 Excelový výstup pro řízení rizik 23 Analýza a řazení rizika 24 Vyhodnocení rizika 25 Ukázka dashboards 26 Registr rizik 27 Přehled o stavu a plnění projektu 28 Ukázka spravování projektové dokumentace 5

6 Uvedené tabulky 1 Porovnání metodik Prince2 a PMBOK 2 Odchylky 6

7 Úvod Semestrální práce se zabývá tématem Řízení projektů a možnou vazbou na Nástroje CASE. Na začátku dokumentu jsou vysvětleny základní pojmy týkající se tohoto tématu, tedy co jsou to nástroje CASE, jaké je jejich členění, k čemu se používají a dále jsou vysvětleny pojmy týkající se řízení projektů co je to projekt, řízení projektů, jaké jsou vlastnosti projektu, jaké existují metody řízení projektu a na jaké fáze se rozpadají, následně jsou tyto metody na základě konkrétních kritérií porovnávány. K bližšímu představení řízení projektu byla vybrána metoda PRINCE2, která je detailně popsána v další části dokumentu, včetně doprovodné ilustrace z programu PROJECT in a box, který přímo podporuje řízení projektu touto metodou. Jako možný nástroj CASE, podporující projektové řízení byl vybrán program QPR od společnosti Software Plc a to z toho důvodu, že kromě snadného modelování procesů a hierarchických struktur umožňuje také funkce podporující sledování projektu a manažerské rozhodování. 7

8 1. Nástroje CASE V první kapitole se zabýváme vysvětlením toho, co jsou nástroje CASE jejich historií, druhy i jejich komponentami. Pojem nástroje CASE označuje takovou skupinu nástrojů, která se zaměřuje na podporu vývoje informačních aplikací. CASE je zkratkové slovo složené ze čtyř anglických slov - Computer Aided Software Engineering. 1.1 Historie nástrojů CASE Historie těchto nástrojů není jen otázkou nového tisíciletí, ale začala již se vznikem odvětví zvané softwarové inženýrství (kolem roku 1960). Softwarové inženýrství odstartovalo éru systému pro podporu vývoje zejména softwarů pro analýzu. Mezi první nástroje CASE patřily nástroje, které můžeme nazývat Lower Case. Tyto nástroje jsou dodnes určeny pro fázi implementace např. generování kódu. Původní myšlenka nástrojů CASE byla taková, že už nebude zapotřebí programátorů, čímž bylo míněno to, že CASE nástroj vygeneruje již samotný kód, který nebude potřeba upravovat a rovnou použít. Takováto myšlenka ovšem nenašla své místo ve světě a nástroje CASE se dále vyvíjely. Rozmach zapříčinilo až vytvoření uživatelského rozhraní pro Nástroje CASE kolem roku Do té doby byly dostupné pouze samostatně malé nástroje, poté bylo možné vše integrovat na univerzální pracovní ploše (History of CASE, 15). 1.2 Nástroje CASE Těchto nástrojů existuje celá řada. Jedná se buď o strukturované anebo objektově orientované metody vývoje podporující určité fáze vývoje, především analýzu a návrh. Jednotlivé nástroje CASE vycházejí z konkrétní metodologie, díky které umožňují materializovat představu o zpracovávaném problému formou diagramů. Nejčastěji jsou nástroje CASE používány pro datové a funkční modelování. Některé nástroje CASE jsou integrovány do moderních prostředí pro vývoj software (Borland, Oracle). Nástroje CASE jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému, zajišťují sdílení rozpracovaných fragmentů, správu vývoje, sledují konzistenci modelu systému, automatizují některé procesy, hlídají dodržování zvolené metodiky, některé umožňují řízení celého životního cyklu aplikací. 8

9 Nástroje CASE by měly podporovat komponentové a distribuované aplikace či aplikace založená na webových službách. Podmínkou každého nástroje CASE je splnění obecné podmínky otevřenosti a nezávislosti na hardwaru. Každý nástroj CASE by měl umožňovat podporu požadavků na modelování v reálném čase. Přestože vypadá, že tvorba diagramů v těchto nástrojích je jednoduchá, opak je pravdou. Vyžaduje vysokou znalost a profesionálnost tvůrce modelů i těch, kdo nástroj používají. Druhým předpokladem úspěchu je vhodnost použitých metod, na kterých je CASE založen (Procházka, 14), (Řezníček, Kollárovitz, Holba, Pešková, Soukup, Šafránek, Školník,16).. Je dobré mít na paměti, že nástroje CASE nejsou metodologií, ale používají již zavedené metodologie. Nástroje CASE také nejsou náhradou programovacích jazyků (může generovat části kódu, ale programovací jazyky nenahrazuje) a používání nástrojů CASE automaticky nezlepší práci vedoucích pracovníků podniku nebo specialistů pro IT (pouze zlepšuje produktivitu práce). Nástroje CASE odstraňují potřebu disciplíny a přísného vývoje aplikací IT, ale CASE systémy často selhávají právě díky nedisciplinovanosti uživatelů. Od nástrojů CASE se často očekává jako výstup tvorba aplikačního programového vybavení. Hlavní přínos přitom je v úplném poznání fungování podniku a vytváření úplných podkladů právě pro programování aplikací (Procházka, 14) Druhy nástrojů CASE Jak bylo uvedeno výše, existuje několik druhů nástrojů CASE. Je to dáno nejen podporovanou metodikou, ale také tím, v jaké fázi vývoje je nástroj používán. Nástroje CASE se využívají ve fázích specifikace požadavků, analýzy, návrhu, kódování a údržby. Nástroje použité v různých etapách se liší, a proto je obvyklé, že pokrývají jen určité činnosti. Stírají se také hranice mezi nástroji CASE a integrovanými vývojovými nástroji, například CASE a současně také integrovaný vývojový nástroj QI Builder, který je součástí informačního systému QI od společnosti DC Concept a celý informační systém je v něm vytvořen (Procházka, 14). Podle životního cyklu vývoje software lze nástroje CASE 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ástrojů je analýza organizace, 9

10 zachycení procesů v organizaci, definice klíčových informačních toků a dokumentace zjištěných požadavků. Z těchto údajů je jasné použití při specifikaci cílů, počáteční specifikaci požadavků a řízení projektů. Použité nástroje mohou být DFD (Data Flow Diagram) a ERD (Entity Relationship Diagram) bez podrobných atributů, prostředky pro řízení projektů a sledování ekonomických ukazatelů, popis základních vlastností systému prostředky objektově orientovaného modelování. Middle CASE podporují podrobnou specifikaci požadavků a vlastní návrh systému. Tato třída nástrojů CASE je nejúspěšnější. Používají se pro podrobnou specifikaci požadavků, návrh systému, dokumentaci a vizualizaci systému. Použité metody a nástroje jsou DFD včetně podrobného popisu procesů, datových úložišť, podrobné ERD, ale také diagramy tříd, instancí, přechodové diagramy apod. Nástroje CASE této skupiny obsahují systém 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 nástrojů 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 takové 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. Funkce nástrojů CASE této kategorie se často překrývají s funkcemi obecných vývojových prostředí (Procházka, 14). Je ovšem nutné podotknout, že třídění podle životního cyklu je možné brát i z jiného pohledu i podle toho, zda jsou využívány nástroje CASE během celého životního cyklu softwarové aplikace: vertikální nástroje CASE - nástroje podporující jen dílčí krok životního cyklu software či dílčí oblast např. zjišťování uživatelských požadavku nebo kódování 10

11 horizontální nástroje CASE - nástroje podporující několik kroku životního cyklu software či více oblastí např. nástroje pro tvorbu dokumentace či řízení konfigurace (Procházka, 14). Životnímu cyklu je velice podobná kategorizace nástrojů CASE podle fáze projektu vývoje softwarové aplikace, v níž jsou využívány: Front-end nástroje CASE - využívány v dřívějších fázích projektu např. nástroje na podporu návrhu Back-end nástroje CASE - využívány v pozdějších fázích projektu např. kompilery a nástroje podporující testování (Procházka, 14). Předešlé kategorizace jsou si velice podobná, avšak v jistých ohledech se neshodují. Ale rozdělení nástrojů CASE může být provedeno i podle jiných hledisek, kterými jsou interaktivita a integrace. Rozdělení nástrojů CASE podle interaktivity se míní: ástroje CASE, které jsou interaktivní ze své podstaty - např. nástroje podporující metodu návrhu ástroje CASE, které nejsou interaktivní - tzv. vývojové nástroje, např. překladače Podle stupně integrace se Nástroje CASE dělí na: CASE tools - nástroje zabezpečující automatizovanou podporu libovolné úlohy životního cyklu software CASE toolkits - soubor integrovaných softwarových nástrojů, který poskytuje částečnou či komplexní podporu jen v rámci jedné fáze životního cyklu software CASE workbenches - množina integrovaných CASE tools nebo CASE toolkits, která poskytuje částečnou či komplexní podporu v minimálně dvou fázích životního cyklu software I CASE - představuje nejvyšší stupeň integrace; představuje propojení několika CASE tools, CASE toolkits a CASE workbenches (Procházka, 14) Komponenty nástrojů CASE Z obecných funkcí čili vlastností nástrojů CASE a požadavků, které jsou na ně kladeny, vyplývá také, z jakých komponent se nástroje CASE skládají. Mezi důležité funkce a vlastnosti CASE patří: 11

12 soudržné grafické ovládací prostředí (podle zásad tvorby GUI) jednotný vzhled obrazovek, popisků, tlačítek, jednotné ovládání, použití symbolických ikon atd. centrální databáze (repository) pro uchování informací o všech objektech IS (tímto způsobem se zaručí, že informace je použitelná i pro libovolné další kroky a fáze projektování) prostředky verifikace konzistentnosti dat a podpora normalizace dat textový editor pro popis jednotlivých objektů pro účely technické a uživatelské dokumentace systému, možnost jejího přímého generování ze systému možnost rychlého návrhu uživatelských obrazovek včetně simulace vstupů a výstupů (je vyžadováno pro prototyping) generátor zdrojových programů (pro případy častého znovupoužití daného kódu) export / import dat pro práci s modely a dokumentací, které byly vytvořeny v jiných programech nebo jsou v jiných programech dále využívány a zpracovávány. Slovník - je důležitou částí každého nástroje CASE. Je v něm obsažena definice datových struktur - použitých datových entit, definice vztahů v hierarchii procesů typu rodič / potomek a v neposlední řadě také relace mezi daty a procesy (Procházka, 14). V některých nástrojích je slovník automatický - jakmile vytvoří uživatel objekt diagramu, je ve slovníku automaticky o tomto objektu vytvořen záznam. Velikost slovníku definuje maximální počet procesů, toků, datových objektů. Existují různé metody navigace - přístup k položkám databáze - ve slovníku, přístup pomocí diagramu, přímý přístup do slovníku apod. Slovník funguje většinou také jako textový procesor pro účely dokumentace (Procházka, 14) Příklad nástroje CASE - QPR ProcessGuide Následující nástroj CASE jsme vybraly jako velice vhodný nástroj pro procesní modelování, jelikož jeho uživatelské prostředí je graficky přívětivé a uživatel se v něm rychle zorientuje. QPR ProcessGuide je manažerský nástroj, který slouží pro práci související s procesním řízením. Nabízí procesní modelování, dokumentaci, publikaci, měření a analýzu procesů. Jeho jednoduché ovládání, přizpůsobitelnost a přehlednost patří k hlavním vlastnostem, díky kterým si získal oblíbenost uživatelů. Dále lze ProcessGuide charakterizovat jako interaktivní nástroj pro plánování, komunikaci a zapojování lidí do zlepšování procesů. Nástroj umožňuje také určení zodpovědností, kompetencí a cílů (QPR, 18). 12

13 Další charakteristiky nástroje ProcessGuide: Dynamická publikace procesů prostřednictvím Internetu Široká škálovatelnost Provázanost na strategické řízení Cenově dostupný Optimalizace a zvyšování kvality procesů (QPR, 18) ProcessGuide má i široké využití jako nástroj pro elektronickou dokumentaci systému řízení jakosti podle ISO 9001:2008. Poskytuje měření a hodnocení výkonnosti a efektivnosti procesů. Měření lze měnit a analyzovat s výstupem do grafů a tabulek. Zajímavá je tvorba simulace procesů, která přináší konkrétní pohled na chod podniku. Simulace je využívána pro analýzu budoucích alternativ, napomáhá tak strategickým a taktickým změnám. Práce s QPR ProcessGuide je na straně uživatele snadno zvládnutelná pro manažery a nevyžaduje žádné speciální IT schopnosti (QPR, 18). Na následujícím obrázku je výchozí obrazovka programu QPR. Uživatelské prostředí je navrženo tak, aby bylo co nejvíce intuitivní, i z toho důvodu je celkový vzhled a ovládání navrženo tak, aby připomínalo MS Office, se kterým mají zkušenosti téměř všichni. Vlevo se nachází adresář jak uložených modelů, tak i souvisejících materiálů, které je možno v programu přiřadit jednotlivým objektům. Vpravo je umístěna paleta nástrojů, avšak program je natolik intuitivní, že při najetí myší na objekt sám nabídne vhodné nástroje k použití v souvislosti s daným objektem. 13

14 Obrázek 1 Vzhled programu QPR (Řízení projektů QPR Software, 17) Program umožňuje vytvářet subprocesy jako dílčí části modelu, stačí jen danou část označit a pojmenovat ji jako novou entitu, která nově v modelu zastoupí celý subproces. Tento subproces se pro budoucí použití objeví v adresáři ve stejné větvi jako hlavní proces. 14

15 Obrázek 2 Vzhled programu QPR (Řízení projektů QPR Software, 17) K jednotlivým entitám program umožňuje připojovat dokumenty, které se zobrazí při kliknutí myší na malé i v pravém dolním rohu příslušné entity. Podporovány jsou formáty doc, xls. ppt, pdf a html. Přiřazení dokumentu se provádí pouhým přetáhnutím ikony do prostoru výskytu entity. Obrázek 3 Vzhled programu QPR (Řízení projektů QPR Software, 17) 15

16 Veškerý vytvořený obsah je možné sdílet na webu a včetně připojených dokumentů. Každý uživatel má svůj vlastní profil, na který může ukládat soubory a komunikovat s dalšími členy týmu. Obrázek 4 Vzhled programu QPR (Řízení projektů QPR Software, 17) 16

17 2. Řízení projektů V druhé kapitole se věnujeme pojmům souvisejícím s řízením projektu. Tato část tedy obsahuje volnou definici slova projekt, uvádí jeho hlavní vlastnosti, cíle a fáze pro vybrané tři metodiky (PMBOK, PRINCE2, RUP). 2.1 Definice slova projekt Projekt může být definován jako časově ohraničené úsilí, směřující k vytvoření unikátního produktu nebo služby. Od procesů se liší právě díky časovému omezení a jedinečnosti výstupů. Projektem lze nazvat činnost, která má jasně definovaný konec z pohledu času a výstupu. Projektem však již není činnost, která se opakuje a je prováděna ověřeným postupem (Wikipedie, otevřená encyklopedie, 18). 2.2 Vlastnosti projektu Cíl a kvalita cíl a kvalita produktu by měly být jasně stanoveny před zahájením projektu např. ve smlouvě. Po započetí projektu, se dají provádět menší úpravy, cíl již lze měnit jen obtížně resp. vůbec. V souvislosti s dodržením cíle a kvality by měl a být vedena kvalitní dokumentace. Čas a náklady Dodržet stanovený čas a náklady není povinné, pokud tak není uvedeno ve smlouvě. Úzce souvisí s riziky a větším čerpáním zdrojů. Omezení a rizika Měly by být definovány již ve fázi plánování, tzn. vyhodnotit okolnosti, které mohou projekt ovlivnit, omezit je a zabránit tak ohrožení projektu. Měla by být provedena analýza rizik, vyhodnocující míru pravděpodobnosti a velikosti dopadu na projekt, pro případ že nastane nežádaná situace, kde by pro vyřešení této situace měl být definován další postup (Řízení projektů Project management, 16). 2.3 Řízení projektů a jeho cíle Při řízení projektů dochází k rozplánování a následné realizaci složitých a zpravidla jednorázových akcí, které je třeba uskutečnit v požadovaném termínu s plánovanými náklady tak, aby došlo ke splnění stanovených cílů. 17

18 Předmětem řízení je projekt, který byl již definován v podkapitole Definice slova projekt. Cílem řízení projektů je zajištění naplánování a realizace úspěšného projektu, tj. projekt dokončený v plánovaném čase a s plánovanými náklady, který naplňuje stanovené cíle a nevyvolává negativní reakce. Řízení projektů je prováděno v projektovém týmu, který bývá veden projektovým manažerem. Při řízení projektů se využívá celá řada metod pro zvýšení pravděpodobnosti úspěchu projektu. Tyto metody představují ověřené a popsané postupy, řešící problémy vzniklé při návrhu a implementaci projektu (Wikipedie, otevřená encyklopedie, 18). 2.4 Fáze projektu Fáze projektu jsou souhrnně označovány pojmem životní cyklus projektu (project life cycle). Tyto fáze se jednotlivě liší podle použité metodiky (Řízení projektů Project management) PMBOK Známý a rozšířený obecný životní cyklus navržený v roce 1991 Warrenem Allenem, který bohužel nebyl v PMBOK publikován. Zahájení (Initiation) Definice (Definition) Implementace (Implementation) Uzavření (Completion)(Řízení projektů Project management). 18

19 Obrázek 5 - Životní cyklus projektu metodiky PMBOK podle Widermana (Řízení projektů Project management, 16) V obecné rovině se rozlišují pouze tři hlavní fáze: Počáteční (Initial) Střední (Intermediate) může být jedna i více Závěrečná (Final)(Řízení projektů Project management). Další fáze, dělení dle Morrise: Proveditelnost, Plánování a návrh, Zavedení a spuštění, uzavření (Řízení projektů Project management). 19

20 Obrázek 6 - Životní cyklus projektu metodiky PMBOK podle Morrise (Řízení projektů Project management, 16) Jednotlivé další metodiky pak používají různé obměny výše uvedených fází, nebo je detailněji rozpracovávají PRINCE2 Metodika PRINCE2 rozděluje projekt na dílčí fáze (stages), pojmenování těchto fází se však vyhýbá. Zaměřuje se především na procesy uvnitř podniku. Dělení na fáze je ponecháno manažerovi s ohledem ke konkrétnímu projekt tak, aby byl rozdělen do logických celků (Řízení projektů Project management, 16) RUP RUP (Rational Unified Process) byl vyvinut společností IBM a dělí se do čtyř hlavních fází: Založení, Rozpracování Budování 20

21 Zavedení (Řízení projektů Project management). Obrázek 7 - Životní cyklus projektu metodiky PMBOK podle Morrise (Řízení projektů Project management, 16) 2.5 Metody řízení projektů V této podkapitole popisujeme dvě nejčastěji používané metody řízení projektů Project Management Body of Knowledge a Projects IN Controlled Environments. Pro podrobnější seznámení s těmito metodami uvádíme oblasti, kterými se zabývají a také, pro které společnosti jsou obecně vhodné. Dále jsme k vybraným metodám uvedly další metodiku pro řízení projektů s názvem Equilibrium - Project Management Solutions, která vychází z dvou hlavních a nejčastěji používaných PMBOK a PRINCE2. Metody řízení projektů, někdy se také můžeme setkat s názvem metody projektového řízení, tyto metody představují ověřené a popsané postupy, které slouží k realizaci činností s cílem zavést nějakou změnu. Dnes existuje řada oborových a dílčích metodik pro řízení projektů. Obecně nejznámější a světově nejrozšířenější metodiky a standardy pro řízení projektů jsou: PMBOK (Project Management Body of Knowledge) PRINCE2 (Projects IN Controlled Environments) 21

22 Tyto metodiky jsou pro řízení projektů využívány nejčastěji, jelikož obsahují standardy pro projekty různého charakteru. Každá organizace by měla uvažovat několik základních faktorů, které napomáhají při rozhodnutí, jakou zvolit metodu řízení projektu: Druh organizace a její kultura Vyspělost a velikost organizace Způsob řízení organizace Volba projektového manažera (jeho zkušenosti s metodikou) Cíle projektu Rozpočet a rizika Harmonogram projektu (Management mania, 7) K řízení projektu se také vztahují některé normy ISO: ISO (norma ISO pro řízení projektů) ISO (připravovaná norma ISO pro řízení projektů) PMBOK (Project Management Body of Knowledge) Tento mezinárodně uznávaný standard pro řízení projektů vydává institut PMI. PMI (Project Management Institute) je světové sdružením profesí projektového řízení, které čítá více jak půl milionu členů po celém světě. PMI definuje odborné standardy, provádí průzkumy a poskytuje přístup k množství informací a zdrojů (Management mania, 7). PMBOK je mezi ostatními standardy a metodikami nejstarší a nejobecnější. Tento standard je nejvíce rozšířen v USA. PMBOK popisuje všechny aspekty projektového řízení a zaměřuje na výrobní firmy, které své výrobky a služby dodávají prostřednictvím projektů. Standard PMBOK je založen na pěti procesních skupinách (Planning, Executing, Monitoring, Controlling a Closing) a devíti znalostních oblastech (Klusoň Martin, 6). Mezi znalostní oblasti PMBOK patří: Project Integration Management (spojuje a integruje všechny ostatní oblasti) 22

23 Project Scope Management (definuje kroky vedoucí k vytvoření rozsahu projektu a k jeho udržení. Zahrnuje i řízení změn. Prvním krokem je sběr požadavků) Project Time Management (vytváření harmonogramu na základě činností) Project Cost Management (vytvoření rozpočtu, kalkulace postupu a odhadování výsledku projektu v čase a penězích) Project Quality Management Project Human Resources Management Project Communications Management (detailní řízení komunikace) Project Risk Management Project Procurement Management (stručné pojednání o řízení smluv) PMBOK je vhodná pro: americkou společnost zlepšení vlastní kvalifikace zlepšení vědomostí o nejlepších praxích řízení projektů a zlepšení jednotlivých oblastí 2.6 PRINCE2 (Projects in controlled environment) PRINCE2 je v současnosti nejvíce rozšířenou metodikou pro řízení projektů v Evropě. Tato metodika je vydávána OGC. OGC (Office of Government Commerce) je nezávislý úřad britského Ministerstva financí (Management mania, 7). PRINCE2 se opírá o sedm principů, tvoří ji sedm procesů a popisuje sedm témat. Metodiku je nutné v závislosti na konkrétním projektu přizpůsobovat. Znamená to ale, že principy zůstávají zachovány, mění se pouze jednotlivé procesy. Toto přizpůsobování se je jednou z předností metodiky PRINCE2 (Prince Official Site, 9). Principy PRINCE2: Průběžné zdůvodnění projektu Poučení se ze zkušeností Definované role a zodpovědnosti Řízení pomocí etap 23

24 Dohled nad projektem na základě výjimek Důraz na produkty Nutnost upravit metodiku podle aktuálního prostředí (Prince Official Site, 9) Procesy: Starting Up a Project Initiating a Project Directing a Project Controlling a Stage Managing Product Delivery Managing a Stage Boundary Closing a Project (Prince Official Site, 9) Témata pro modifikaci: Business Case (popis významu projektu) Organization (stanovení rolí a vazeb) Plans (způsoby sestavení plánu) Progress (autority mezi řídícím výborem a projektovým manažerem) Risk (definování hrozby nebo příležitostí) Quality (upřednostnění kvalit zákazníkem) Change (řízení změn v projektu) (Prince Official Site, 9) PRINCE2 je vhodná pro: evropské společnosti či společnosti s evropskou centrálou společnosti účastnící se veřejných tendrů v ČR nebo SR společnosti bez firemní metodiky Nevýhody: Nepokrývá např. oblasti vedení lidí, manažerské dovednosti, podrobné pokrytí nástrojů pro řízení projektů, které jsou podrobně popsány již existujícími a osvědčenými metodami. Stručné souhrnné porovnání obou metodik nabízí následující tabulka: 24

25 PRINCE2 Metoda řízení projektů Normativní Ucelený souhrn procesů a témat Pokrývá všechny role řízení projektů Nezahrnuje mezilidské vztahy Odvolává se na techniky PMBOK Souhrn nejlepších praxí pro řízení projektů Není normativní Z každého tématu čerpá nezávisle Je zaměřen na projektové manažery Popisuje soft skills Popisuje techniky řízení projektů Tabulka 1 Porovnání metodik Prince2 a PMBOK (Klusoň Martin, 6) Metodika EPMS (Equilibrium - Project Management Solutions) Tato metodika, kterou vyvinula společnost Equica, a.s., je postavena nad obecnými principy normy systému řízení kvality ISO 9001 a její aplikace na projektové řízení ve smyslu normy ISO (Equica,1). EPMS vychází principů metodik již zmíněných metodik PRINCE2 A PMBOK. Na rozdíl od těchto metod EPMS odráží specifický stav českého prostředí. EPMS si klade za cíl vnitřní i vnější rovnováhu projektu s využitím objektivního pohledu projektových manažerů. Životní cyklus projektu se skládá z šesti fází (Identifikační, Ověřovací, Přípravné, Realizační, Provozní a Likvidační), při čemž celým projektem prochází proces stabilizace. Stabilizace je zajištěna zpětnou vazbou od zadavatelů. Další kontrolu a dohled zajišťuje proces Audit a dohled projektu (Equica,1). EPMS je metodika jednoznačně a pragmaticky zaměřená do české praxe, vystavěná za využití letitých koncentrovaných zkušeností s maximální srozumitelností a tahem na branku. (Equica,1) 25

26 3. Jak souvisí Nástroje CASE s řízením projektů Spojení mezi CASE nástroji a řízením projektů je velice nepatrné. Obě linie jsou od sebe poměrně vzdáleny a najít cestu k jejich propojení je těžký úkol. Předešlé práce se marně snažily o určité výrazné propojení těchto dvou paradigmat, což jsme my shledaly špatným pokusem. My jsme toho názoru, že zde jisté propojení existuje. Je bohužel v praktickém využití nevýrazné. Vazbu shledáváme pouze tak, že manažer řídí pomocí svého programu celý projekt, přičemž má přehled o dílčích aktivitách (času, pracovnících, procesech, atd.) v rámci projektu IS/ICT. Vhledem k faktu, Nástroje CASE jsou používány v prvotní fázi projektu (čili v datovém a funkčním modelování IS/ICT), což je samozřejmě dílčí činnost projektu, může tedy manažer sledovat i práci zaměstnanců pracujících s CASE nástroji. Tudíž může ovlivňovat jejich práci s CASE nástroji (například z časového hlediska nebo počtu zaměstnanců pracujících s CASE nástroji), čímž dochází k určitému propojení mezi řízením projektu a CASE nástroji. Jak už je napsáno výše, nejčastěji jsou Nástroje CASE používány pro datové a funkční modelování. A Nástroje CASE jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému. Ano při vývoji systému nikoli řízení projektu. Také vyžaduje vysokou znalost a profesionálnost tvůrce modelů i těch, kdo nástroj používají. Takže bychom po manažerovi, který řídí nějaký IS/ICT projekt mohli asi jen těžko chtít, aby se naučil s těmito nástroji zacházet, když má pod sebou zaměstnance a kolegy a někteří z nich s těmito nástroji pracují, protože to patří k náplni jejich práce. A manažerovi jsou posléze předávány výsledky této práce. Jinak by si vlastně mohl dělat všechnu zadanou práci sám. Proto jsme si zvolili na popsání metodu PRINCE2, která je určena pro řízení projektů a program Project in a box, který umí zpracovávat výstupy do aplikace MS Excel, ve kterém si můžeme data uspořádat do různých grafů a diagramů, na kterých je vidět, jak si projekt stojí. Nejedná se tedy vůbec o CASE nástroj, který generuje kód, ale z našeho hlediska nic nevyvíjíme, ale řídíme. Pro řízení projektu je tedy tato možnost dostačující. Protože právě grafy a diagramy popisující daný stav budou manažera zajímat. Ve většině již zpracovaných prací, většina autorů tak nějak přešla v názvu řízení projektů a rozepsala se o některém z Nástrojů CASE či je porovnávala. Ať již komerční či open source. My jsme se na toto téma podívali zase z trochu jiného úhlu pohledu a zaměřili se právě na