Fakulta informatiky a statistiky
Katedra informačních technologií
POROVNÁNÍ VYBRANÝCH METODIK PROJEKT MANAGEMENTU V OBLASTI ICT
BAKALÁŘSKÁ PRÁCE
Student : Jiří Grégr
Vedoucí bakalářské práce : Ing. Jakub Řídel
Recenzent bakalářské práce: Mgr. Rudolf Stolař Praha 2007
Poděkování
Rád bych na tomto místě poděkoval vedoucímu mé bakalářské práce Ing. Jakubovi Řídelovi za odborné vedení, konzultace a rady, které mi v průběhu tvorby práce věnoval.
Prohlašuji, že jsem předkládanou bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.
V Praze dne 8. srpna 2007 ………
Podpis
Abstrakt
Tato práce je zaměřena na porovnání dvou metodik užívaných v projekt managementu. První z těchto metodik je PMBOK, která byla zpracována v Project Management Institute a je podrobně popsána v publikaci PMBOK (Project Management Body of Knowledge) a druhou metodikou je V-Modell (VM), jejímiž autory jsou C. Johannson a Ch. Bucanac. Tato metodika se využívá zejména pro řízení projektů ICT.
Při porovnávání analyzovaných metodik jsem se soustředil zejména na oblast zajištění kvality, která je nezbytná k úspěšnému zavedení projektu. V závěru práce je uvedeno stručné zhodnocení obou srovnávaných metodik, které přispívá k orientaci při jejich použití.
This study is focused on the comparison of two methodologies being used in Project Management. The first one of these two methodologies is Project Management Body of Knowledge (PMBOK), which has been developed by Project Management Institute and is described in detail in PMBOK (Project Management Body of Knowledge) publication and the second one is V-Modell (VM) the authors of which are C. Johannson a Ch. Bucanac 1.
This methodology is being used namely for the assessment of project management for ICT.
When comparing mentioned methodologies I have focused on the branch of quality assurance, which is necessary for successful implementation of a project. A brief assessment of both used methodologies is mentioned in the study’s conclusions as an outcome for better orientation when using them.
1 [lit8]
Obsah
1. ÚVOD... 7
2. PŘEHLED PROBLEMATIKY ... 9
2.1. Projekt management (PM) ... 9
2.1.1. Projekt... 9
2.1.2. Projekt management... 9
2.2. Historie projekt managementu ... 10
2.3. Cíl a využití PM ... 11
2.4. Úloha a využití metodik ... 11
3. CHARAKTERISTIKA VYBRANÝCH METODIK ... 13
3.1. Metodika PMBOK... 13
3.1.1. Struktura PMBOK ... 13
3.1.2. Project Management Office (PMO) ... 13
3.1.3. Životní cyklus projektu a jeho organizace ... 14
3.1.4. Vybrané vědní oblasti PMBOK - Project Quality Management ... 15
3.1.4.1. Plánování kvality... 15
3.1.4.2. Zajištění kvality ... 17
3.1.4.3. Kontrola kvality ... 18
3.2. Metodika V-Modell (VM)... 18
3.2.1. Alokace metod (AM) a požadavků na funkční nástroje (FTR)... 20
3.2.2. LPM – základní prvky... 22
3.2.2.1. Podmodel Projekt management (PM)... 25
3.2.2.2. Vývoj systému (SD) ... 26
3.2.2.3. Zajištění kvality (QA)... 26
3.2.2.4. Management konfigurace (CM) ... 27
4. POROVNÁNÍ VYBRANÝCH METODIK ... 28
4.1. Cíl a zaměření porovnání... 28
4.2. Výhody a nevýhody srovnávaných metodik ... 28
4.3. Porovnání modelů z hlediska zajištění kvality ... 30
4.4. Tabulka srovnání metodik ... 31
5. ZÁVĚR ... 33
6. SLOVNÍK POUŽITÝCH POJMŮ ... 34
7. SEZNAM POUŽITÉ LITERATURY ... 35
1. ÚVOD
Jednou ze základních funkcí vedení organizace je zajištění jejího růstu a zvyšování celkové hodnoty podniku. Projekt management je jedinečným nástrojem pro následnou implementaci změn, které jsou v souladu se strategií organizace. Rozličné používané metodiky jsou jakýmsi standardem hodnocení a následného určení činnosti pro většinu podniků. Tyto metodiky obsahují základní praktiky a směry, které řídí výsledky podniků na místní, regionální i globální úrovni.
V poslední době je možné zaregistrovat pohyb ve vnímání od „obecně akceptovaného ve většině projektů a většině času“ k „obecně uznávanému, jako ověřených postupů, většiny projektů a většině času“.
Project management může být zaměřen na podporu managementu při vedení a realizaci ICT projektů a zároveň jej může vybavit nezbytnými dovednostmi s cílem efektivně řídit různé ICT iniciativy v jimi řízených jednotkách. Jedná se zejména o:
• Jasné porozumění úloh a odpovědnosti managementu
• Systematický přístup k definování projektů a k vytváření uskutečnitelných plánů směřujících k dosažení požadovaného
• Ověřené techniky používané k vyhledávání, vyhodnocování a sdílení stavu projektu
• Ověřené techniky používané pro vyhodnocování rizik, odhadů zdrojů a časovou optimalizaci postupů
Výhodou aplikace PM je dosažení konzistentní metodologie za využití PM terminologie, zisk nových metodologií vhodných k definování a řešení současných a budoucích problémů projektů, systematický management rizik a implementace změn založených na ověřených metodologiích. V neposlední řadě pak zlepšování produktivity projektových týmů v návaznosti na ověřených postupech a nástrojích2.
V této práci jsem se věnoval popisu dvou významných metodik pro řízení projektů, jimiž jsou:
PMBOK a V-Modell
2 [lit4]
Vzhledem k tomu, že se jedná o obsáhlé metodiky, položil jsem důraz především na srovnání charakteristik, které jsou pro projekty společné.
2. PŘEHLED PROBLEMATIKY
2.1. Projekt management (PM)
Studium celého komplexu problematiky PM je třeba začít definicí projektu a projektového managementu tak, jak ji uvádí nejnovější zdroje.
2.1.1. Projekt
Projekt je dočasné úsilí vynaložené za účelem vytvoření unikátního výrobku, služby nebo dosažení výsledku3.
2.1.2. Projekt management
Projekt management je aplikace znalostí, dovedností, nástrojů a postupů pro návrh činností s cílem dosáhnout požadavků projektu. Projekt management je realizován prostřednictvím aplikace a integrace projektového procesu zahájením, plánováním, realizací, monitorováním, kontrolou a ukončením projektu. Projektový manager je osobou odpovědnou za dosažení projektových cílů.4
K úspěšné aplikaci PM je nutné zejména:
• identifikovat požadavky,
• stanovit jasné a dosažitelné cíle,
• vybalancovat požadavky na kvalitu, rozsah, čas a náklady,
• a dále přizpůsobit plány a přístupy různým zájmům a představám účastníků projektu.
Za řízení každého projektu je odpovědný jeho projektový manager. Jedná se o osobu, která se přímo účastní aktivit vedoucích k cíli projektu, ale více usiluje také o vzájemnou interakci mezi účastníky daného projektu tak, aby bylo minimalizováno riziko neúspěchu.5
Otázkami metodik PM a jejich využitím při řízení procesů ICT se zabývalo mnoho autorů. K základním pramenům patří A Guide to the Project Management Body of Knowledge (PMBOK), zmiňovaný např. v bakalářské práci (Prochásková J.).6
3 [lit1]
4 [lit1]
5 [lit3]
6 [lit2]
2.2. Historie projekt managementu
Projekt management jako disciplína vznikl s rozvojem různých oblastí průmyslu jako strojírenství, stavitelství a především obrana v USA. Za předchůdce projektového managementu můžeme považovat Henryho Gantta, který přinesl do oblasti řízení techniky pro kontrolu a plánování PM a začal využívat nový nástroj – sloupcový graf (bar chart).
Druhou významnou osobou, která přispěla k PM je Frederick Wislow Taylor. Jeho přínos spočívá ve studii řízení projektů při stavbě válečných lodí pomocí nástroje Work Breakdown Structure (WBS). Jedná se o základní techniku PM pro definování a organizování projektu jako celku pomocí stromové struktury.
V padesátých letech dvacátého století začala éra moderního projektového řízení využívající metody Ganttových grafů a dalších neoficiálních technik. V té době byly vyvinuty dva stěžejní modely Program Evaluation and Review Technique (PERT) a Critical Path Method (CPM), jež vznikly v joint venture mezi DuPont Corporation a Remington Rand Corporation. Cílem matematického modelu PERT je analýza projektu, stanovení času potřebného k dokončení dílčích úkolů a určení minimálního času potřebného k dokončení celého projektu. CPM je matematický algoritmus zaměřený na plánování aktivit v jednotlivých fázích projektu a projekty vedení údržby.
V roce 1969 byl založen Project Management Institute (PMI), aby sjednotil do té doby používané techniky projektového řízení a umožnil jejich aplikaci pro širokou škálu projektů od softwarového až po stavební průmysl. Roku 1981 schválila správní rada PMI tzv. „A Guide to the Project Management Body of Knowledge“ (PMBOK). Tento dokument obsahuje standardy a směrnice, které se staly stěžejními pro PM.
Roku 1967 byla v Evropě založena obdobná organizace s názvem „International Project Management Association“ (IPMA). V dnešní době se PMI a IPMA spolupodílejí na vývoji standardů PM.7
7 [lit3]
2.3. Cíl a využití PM
Cílem projekt managementu je zajistit, aby byl projekt vyhotoven v rámci předem definovaných požadavků a omezení. Dále si PM klade za cíl optimálně alokovat zdroje a dosahovat jejich integrace v průběhu projektu tak, aby byl výsledek dosažen co nejefektivněji.
Při definování cílů projektu je třeba brát na vědomí i kvalitativní stránku vymezení.
Cíle by měly být definovány podle pravidel, která se zkráceně označují S.M.A.R.T.
Význam zkratky lze vyjádřit následovně:
• S – specific: navrhované řešení by mělo být popsáno co nejpřesněji. Musí být zcela jasné, jaký je problém a jak ho hodláme řešit
• M – measurable: řešení by mělo být měřitelné. Součástí plánu by měla být kontrola úspěšnosti
• A – achiavable, attainable: řešení musí být dosažitelné z hlediska zdrojů a času
• R – relevant, realistic: řešení musí mít smysl
• T – timed: jsou jasně definovány termíny dokončení úkolů
Pravidla S.M.A.R.T. bohužel nejsou jednoznačně definována, a tak se v literatuře můžeme setkat s více interpretacemi písmen, vyjadřující tuto zkratku.8
2.4. Úloha a využití metodik
PM metodik se využívá k řízení projektů, kde nelze díky jejich rozsahu spoléhat na intuici a je třeba využívat ověřené postupy vedoucí ke stanoveným cílům.
Původně se metodiky využívaly pro řízení ve stavebním průmyslu a pro armádní projekty, později byly rozšířeny i na další oblasti včetně softwarového průmyslu, na nějž je tato práce zaměřena.
Význam ještě podtrhuje, že se těchto metodik využívá k praktickému řízení procesů v mnoha společnostech a mezinárodních organizacích. Příkladem může být využití při kontrole procesů ICT jedné z důležitých evropských institucích – Evropského policejního úřadu – EUROPOL.
8 [lit5], [lit6]
Základním úkolem metodiky zavedené v Europolu v souvislosti s jeho postavením, jako jedinečné evropské organizace poskytující analytickou podporu orgánům činným v trestním řízení v boji proti organizovanému zločinu a terorismu poskytováním informačního managementu v oblasti softwarového inženýrství je efektivní zavádění a využití nových softwarových aplikací včetně systémového designu a údržby systému.
• Testování: implementací automatizovaných nástrojů softwaru (Mercury Quick Test Professional and Quality Center)
• Lifecycle: vývoj softwaru aplikací Microsoft Visual Studio 2005 and .NET zaměřené na vyhledávání a kódové pokrytí
• Mechanizmy výměny dat: pilotním použitím Microsoft Biztalk 2006 s cílem rozvoje automatického zadávání dat do informačních systémů
• Portálové služby: pilotním využitím Microsfot Sharepoint Portal Services s cílem zlepšování údržby webových služeb
• Monitorování systémů: aplikací Microsoft Operations Manager (MOM) v platformě Informačního Systému s ohledem na dosažení rychlejší odezvy 9
9 [lit10]
3. CHARAKTERISTIKA VYBRANÝCH METODIK
3.1. Metodika PMBOK
Jak již bylo nastíněno v úvodu, metodika PMBOK byla vyvinuta v institutu PMI a sjednocuje postupy, praktiky a zkušenosti z oblasti projektového řízení do jednoho celku.
Tato metodika se, vzhledem k neustálému vývoji informačních technologií, ale i všech ostatních směrů, kde je třeba řízení projektů, rozvíjí a nelze její vývoj považovat za ukončený. Ač PMBOK umožňuje řídit projekty podle ověřených a vyzkoušených praktik, odpovědnost za výběr vhodných postupů pro daný projekt stále nesou členové týmu projekt managementu. PMBOK navíc nezahrnuje veškerou problematiku projekt managementu a existují k ní další přílohy. Nelze spoléhat na vyzkoušené postupy uvedené v této metodice, pokud nejsou správně přizpůsobeny specifickým podmínkám projektu.
3.1.1. Struktura PMBOK
PMBOK lze rozdělit do třech základních oddílů. Prvním z nich je The Project Management Framework, jehož cílem je seznámit uživatele se základními termíny a strukturou projekt managementu.
Druhý oddíl The Standard for Project Management of a Project popisuje procesy projektového řízení, které využívá projektový tým ke zvládnutí projektu.
Třetí oddíl The Project Management Knowledge Areas podrobněji specifikuje 44 procesů projekt managementu, které jsou rozděleny do 9 vědních oblastí.
V této práci se podrobněji zaměřím na některé z těchto oblastí a porovnám je s přístupem druhé metodiky – VM.
3.1.2. Project Management Office (PMO)
Při řešení projektů je velice často zapotřebí velké projekty dekomponovat na skupinu menších podprojektů. Aby mohly být podprojekty propojeny, byla utvořena organizační jednotka PMO, která koordinuje a sjednocuje dílčí projekty do jednoho celku.
Mezi další funkce PMO patří:
♦ sdílení, koordinace a administrace zdrojů
♦ identifikace a vývoj metod projekt managementu a standardů
♦ centralizované řízení konfigurace všech projektů, které jsou spravovány PMO
♦ centrální služba pro provoz a management projektových nástrojů jakým může být např. celopodnikový software na podporu projekt managementu
♦ centrální řízení komunikace mezi projekty
♦ centrální monitorování všech PMO projektů z časového hlediska, aby byly dodržovány termíny dílčích projektů
♦ koordinace celkové kvality modelu
3.1.3. Životní cyklus projektu a jeho organizace
Každý projekt je časově omezen a projektový tým si musí uvědomovat toto omezení, rozdělit jej do fází a procesů a přiřadit projektu odpovídající nástroje a určit vhodné techniky. Fáze projektu se mohou do určité míry překrývat.
Nejistota a riziko selhání projektu je nejvyšší na počátku a jistota se postupně zvyšuje.
Investoři mohou projekt nejvíce ovlivnit na jeho počátku. Z toho zároveň vyplývá, že náklady na opravení chyb, které vznikly např. špatnou specifikací požadavků investora na začátku projektu, neustále rostou. Mnoho projektů selhává právě v tom bodě, kdy špatně definované požadavky na počátku vedou k řešení, které neodpovídá investorovým představám a projekt je ve výsledku pro investora nepoužitelný.
Obr. 1 – Vliv investorů v průběhu času 10
10 [lit1]
(PQM)
Procesy PQM zahrnují veškeré aktivity společnosti spojené se zajištěním kvality, její definicí, určením cílů a odpovědností za kvalitu tak, aby projekt uspokojil potřeby, pro které byl vytvořen. Jedná se o procesy plánování kvality, jejího zajištění, kontrolu kvality a v neposlední řadě i zlepšování v průběhu vývoje.
♦ Plánování kvality (QP) – identifikace standardů, které přísluší danému projektu a určení postupu, jak tyto standardy naplnit
♦ Zajištění kvality – systematické provádění naplánovaných aktivit, aby bylo dosaženo požadavků v odpovídající kvalitě
♦ Kontrola kvality – sledování průběžných výsledků projektu za účelem ověření, že kvalita odpovídá standardům a určení způsobů, jak eliminovat případy, které v minulosti dopadly neúspěchem
Přístup k řízení kvality popsaný metodikou PMBOK je slučitelný s ISO standardy.
PQM se zabývá managementem projektu i produktem samotným. Jako příklad lze uvést následující: management softwarových produktů si vyžaduje jiný přístup a jiný způsob měření kvality než management jaderné elektrárny, zatímco PQM je aplikovatelný na oboje.
Moderní management kvality je doplňkem projekt managementu, neboť pro obojí je důležité:
• uspokojení zákazníka – porozumění, vyhodnocení a naplnění požadavků zákazníka
• prevence – cena prevence je ve většině případů mnohem nižší, než náklady na opravu chyb, proto je prevence základní předpokladem managementu kvality
• odpovědnost managementu – k dosažení úspěchu je zapotřebí účasti všech členů týmu, avšak odpovědnost za poskytnutí zdrojů, které potřebuje tým ke splnění úkolů, zůstává na managementu projektového týmu
• neustálé zlepšování kvality 3.1.4.1. Plánování kvality
QP, jak bylo uvedeno výše, zahrnuje výběr standardů kvality, které budou pro projekt použity. Tento proces probíhá paralelně s ostatními procesy plánování a jsou vzájemně propojeny. Při změně standardu kvality pak může být zapotřebí přizpůsobit i celkový plán.
Vstupy QP
Vstupy QP jsou ovlivněny čtyřmi hlavními faktory:
1. Podnikové faktory – nařízení orgánů státní zprávy, standardy a směrnice, které jsou specifické pro danou oblast QP.
2. Firemní politika - řízení kvality, pracovní postupy a směrnice, historické databáze a zkušenosti z předešlých projekt.
3. Rámec působnosti projektu 4. Plán projekt managementu
Nástroje a techniky QP
1. Analýza nákladů a výnosů – při plánování kvality musí být dosaženo efektivního kompromisu mezi náklady a výnosy. Primárním výnosem při dodržení požadavků kvality je co nejméně chyb, které znamenají větší produktivitu, nižší náklady a větší uspokojení investora. Primární náklad je představován výdaji na aktivity PQM.
2. Posuzování výkonnosti – znamená zjištění aktuálního nebo plánovaného stavu projektu a jeho porovnání s obdobnými projekty, za účelem vylepšení slabých míst projektu. Porovnáním se získá měřítko výkonnosti, které zle brát za základ měření. Projekty, se kterými se porovnává projekt, mohou být jak ze stejné firmy, tak z jiné.
3. Návrh experimentů (DOE) – je statistická metoda, která pomáhá odhalit faktory ovlivňující kvalitativní charakteristiky produktu při jeho vývoji. DOE hraje také významnou roli při optimalizaci procesů výroby.
4. Náklady kvality – jsou celkovým součtem nákladů, které je třeba vynaložit na prevenci, aby nedocházelo k chybám.
5. Dodatečné nástroje QP – tyto nástroje se používají za účelem lepšího pochopení situace a efektivnějšímu plánování aktivit v rámci managementu kvality. Mezi ně patří např. brainstorming.
Výstupy QP
1. Plán managementu kvality – popisuje, jak bude tým PM aplikovat politiku kvality.
Tento plán je jednou z částí komplexního plánu projekt managementu.
2. Míry kvality – jedná se o vymezení kvalitativních znaků a určení, jak budou tyto znaky měřeny.
Seznam úkolů je většinou psán v imperativu („udělej tohle“) nebo formou otázky („udělal jsi tohle?“) a lze tak přehlednou formou ověřit splnění všech kroků.
4. Plán zlepšování procesů – je druhotný plán, který detailněji analyzuje procesy, které usnadní identifikaci zbytečných aktivit, nebo aktivit, které nepřidávají produktu žádnou přidanou hodnotu.
5. Cíle kvality projektu
6. Aktualizace plánu projekt managementu 11 3.1.4.2. Zajištění kvality
obr. 2 – Zajištění kvality – Vstupy, Nástroje a techniky, Výstupy 12
11 [lit1]
12 [lit1]
3.1.4.3. Kontrola kvality
obr. 3 – Kontrola kvality – Vstupy, Nástroje a techniky, Výstupy 13
3.2. Metodika V-Modell (VM)
VM je metodika určená pro plánování a realizaci IT projektů, zaměřená především na vývoj softwarových produktů. Cílem metodiky je zvýšení pravděpodobnosti úspěchu projektů přesným specifikováním cílů a záměrů projektu. VM definuje role a odpovědnosti účastníků projektu jak na straně zadavatele, tak na straně dodavatele a tím dává jednoznačný základ pro smlouvy mezi oběma stranami. Popisuje, „kdy má kdo co dělat“
v rámci projektu.
V porovnání s ISO standardy je VM konkrétnější, neboť jeho součástí jsou i vzory ověřených postupů, kterými se manažer řídí. VM umožňuje řídit nejen samostatné projekty, ale i celý komplex projektů. VM je srovnatelný s metodikou PRINCE2 a popisuje metody PM stejně tak jako metody systémového rozvoje.
Tento V-Modell byl vyvinut pro usměrňování procesu vývoje softwaru v německé administrativě. Popisuje činnosti a výsledky, které musí být formulovány během vývoje softwaru. Dnes je standardem pro německou federální administrativu a obranné projekty a vzhledem k tomu, že je veřejně přístupný, je využíván mnoha institucemi a společnostmi.14
13 [lit1]
14 [lit7]
upravena na základě starší verze metodiky V-Modell 97 (VM97) 16, která již neodpovídá stavu informačních technologií současnosti a musela být přepracována např. o komponentový způsob vývoje. Z toho důvodu se VM97 již příliš nepoužívá. Na základě zkušeností s tímto modelem byly formulovány návrhy na změny a vylepšení, což vedlo k vytvoření nové verze již zmiňovaného V-Modell XT Version 1.2.017
Základem VM je Lifecycle Process Model (LPM), který popisuje aktivity a produkty v rámci VM. Další úrovně pak doplňují Lifecycle Process Model o metody a nástroje, nicméně jaké metody a nástroje vytvářejí produkty je méně důležité. Liší se projekt od projektu, přičemž Lifecycle Process Model zůstává stále stejný.
V-Modell je charakterizován následujícími úrovněmi:
1. Lifecycle Process Model odpovídá na otázku „Co musí být uděláno?“, tedy jaké aktivity budou prováděny, v jaké výsledky by měly vyústit a jaký obsah musí tyto výsledky mít.
2. Použití metod odpovídá na otázku „Jak je to prováděné?“. Na této úrovni je stanoveno jaké metody budou použity, aby zajistily činnosti na úrovni procesu.
3. Požadavky na funkční nástroje odpovídají na otázku „Co je použito, aby se to udělalo?“ Na této úrovni je stanoveno jaké funkční charakteristiky musí nástroj mít pro to, aby zajišťoval požadované činnosti.
Na všech úrovních jsou standardy strukturovány podle oblastí a tyto oblasti jsou nazývány podmodely. Existují 4 podmodely:
1. Projekt management – pomocí tohoto podmodelu je plánován, monitorován a kontrolován projekt. Informace z něj jsou dále postoupeny ostatním podmodelům.
2. Vývoj systému (SD) – tímto podmodelem je vyvíjen systém nebo software.
3. Zajištění kvality (QA) – podmodel ve kterém jsou specifikovány požadavky na kvalitu a který disponuje těmito informacemi pro ostatní podmodely. Specifikuje např. testová kritéria, aby bylo zajištěno, že procesy vyhovují standardům.
4. Management konfigurace (CM) – správa vygenerovaných produktů
15 [lit12]
16 [lit9]
17 [lit12]
obr.4 – Architektura V-Modell18
3.2.1. Alokace metod (AM) a požadavků na funkční nástroje (FTR)
Alokace metod (AM) řídí výběr a aplikaci metod pro všechny podmodely a doplňuje LPM. Specifikuje „jak“ má být něco uděláno, zatímco LPM specifikuje, „co“ má být uděláno.
Existují dvě skupiny metod, základní a komplexní. Základní metody odkazují na procedury, které popisují a specifikují omezený úhel pohledu na systém (např. funkční pohled, nebo pohled orientovaný na data) nebo určitou výseč vývoje systému (např.
analýzu nebo návrh). Tyto základní metody jsou kategorizovány. Komplexní metody odkazují na procedury, které jsou přizpůsobeny různým metodickým součástem a sjednocují je v ucelenou metodu.
Pro každou aktivitu je vybrána metoda. Takový výběr je zadokumentován v manuálu projektu. K usnadnění výběru existuje na úrovni alokace metod omezený výčet metod, které jsou dále popsány podle následující struktury:
18 [lit8]
• Stručný popis metody
• Omezení metody
• Specifikace AM – popisuje, jak by měla být metoda použita při daných aktivitách
• Rozhraní – popis napojení na ostatní metody, které se vzájemně doplňují
• Dodatečná literatura o metodě
Stejně jako je AM zapotřebí k výběru vhodné metody, FTR určují výběr a použití vhodných nástrojů pro všechny podmodely. Jsou také doplňkem k LPM.
Definice nástroje:
„Nástroj je softwarový produkt podporující vývoj, údržbu nebo modifikaci IT systému“19 Nástroje jsou seskupovány do tzv. obslužných jednotek, které mohou být použity na úrovni LPM nebo FTR, ale mohou být použity na obou zároveň. Obslužné jednotky jsou dále seskupovány do obslužných celků. Tím může být jeden z podmodelů. Obslužné celky pak vytváří „Reference Model of a Software Development Environment (SDE). Zkratka SDE vyjadřuje kompletní soustavu služeb podporující většinu fází vývoje systému a jeho údržby.
Výběr nástrojů se provádí ve 4 krocích
1. V prvním kroku jsou specifikovány funkční požadavky na nástroje na základě funkčních požadavků projektu. Tento krok vede k výběru některé z obslužných jednotek, které naplňují požadovanou funkcionalitu.
2. Ve druhém kroku se prování dvě aktivity:
a) první je výběr obslužné jednotky a určení podmínek, za kterých budou použity nástroje a vstupy. V ní se rozhoduje o prioritách požadavků. Výstupem jsou funkční požadavky nástrojů.
b) při druhé jsou podmínky použití nástrojů vstupem. Aktivita specifikuje technické a organizační požadavky. Výstupem jsou technické požadavky.
3. Ve třetím kroku se shrnou funkční a technické požadavky do katalogu provozních požadavků.20
4. Ve čtvrtém kroku se porovnávají různé nástroje s kritérii pro jejich použití.
19 [lit8]
20 [lit8]
3.2.2. LPM – základní prvky
LPM popisuje procesy ve dvou základních koncepcích – jako aktivity a produkty.
Také popisuje stavy produktů a vzájemné závislosti mezi aktivitami a produkty pomocí schématu toku produktů.
Aktivity jsou jedním z kroků v procesu vývoje, jejich provádění a výsledky jsou přesně popsány. Mohou se skládat z podaktivit, přičemž aktivita na nejvyšším stupni se nazývá hlavní aktivita. Aktivita vytváří nebo mění produkt, který je zároveň jejím výsledkem. Pro každou aktivitu existuje vzor nazývaný schéma aktivity.
Produktem může být dokument, část softwaru nebo hardwaru. Stejně jako aktivity je možno i produkty dekomponovat na menší části - podprodukty.
Schéma aktivity
Aktivita se skládá z následujících částí:
• Název aktivity – popis jména a čísla aktivity. Podaktivity jsou značeny desetinným číslováním.
• Tok produktů – popis a porovnání vstupního a výstupního stavu produktu.
Produktový tok je graficky znázorněn na obr. 5.
• Zacházení s aktivitou – popisuje, co bude s aktivitou prováděno v průběhu realizace.
• Doporučení a vysvětlivky k aktivitám.
obr.5 – příklad produktového toku 21 Vysvětlivky k ukázkovému příkladu obr.5:
Pořadí projektů je externí aktivita, která nemá žádný stav. Nepokračuje do dalšího stavu a nemění stav. Projektový manuál nepochází z žádné aktivity ani stavu. Jde o nově vytvořenou aktivitu, která pokračuje dál do aktivity PM 1.3 (Generation of Project-Specific V- Model) ve stavu provádění. Tento stav je dále popsán v následující kapitole Stavy produktů.
Projektový manuál je jednou ze vstupních produktů pro aktivitu PM 1.3.
21 [lit7]
Každý produkt nabývá různých stavů v průběhu své existence, přičemž změna stavu může být spuštěna pouze aktivitou. Ve schématu aktivity je popsáno, v jakém stavu se produkt nachází, když vstupuje a když opouští aktivitu.
Produkt nabývá těchto stavů:
• Plánovaný – produkt je plánovaný, ještě neexistuje, jde o počáteční stav společný všem produktům.
• Ve stavu provádění – produkt je pod kontrolou vývojáře. Je buď přihlášen nebo odhlášen z knihovny produktů.
• Předložený - produkt je z pohledu vývojáře dokončený. V případě, že produkt projde přes QA, je označen jako přijatý, jinak je vrácen do stavu provádění k přepracování.
• Přijatý – produkt je hotov a vydán. Může být změněn a vydán pouze pod novým číslem verze.
Stavy produktu znázorňuje obrázek č.6
obr.6 – stavy přechody produktu 22
Organizace a role
Přidělení úkolů k jednotlivým členům projektového týmu je dáno rozdělením rolí v rámci projektu. Pro každý podmodel je specifikována množina rolí a každá role má přidělené aktivity, odpovědnosti za jejich splnění, potřebné dovednosti, potřebné know-how a závislosti na jiné role.
22 [lit8]
Organizace projektového týmu je založena na výběru členů pro každý podmodel a přidělení rolí každému z týmu. Role může být přidělena jednomu nebo více členům projektového týmu a jeden člen může mít zároveň více rolí.
Podmodely
Jak bylo podotknuto dříve, VM lze dekomponovat na čtyři podmodely. V této kapitole budou popsány tyto podmodely z pohledu LPM.
Všechny podmodely se skládají z aktivit a těmi jsou vytvářeny produkty. Jejich vzájemná kooperace vede k cíli projektu. To ukazuje následující schéma (obr.7)
obr.7 – kooperace podmodelů 23
23 [lit8]
3.2.2.1. Podmodel Projekt management (PM)
Podmodelem PM se řídí aktivity zahájení, plánování a monitorování projektu. Je složen z 14 hlavních aktivit:
1. Zahájení projektu – je definován organizační rámec v projektovém manuálu.
Provádí se přizpůsobování VM podle konkrétních podmínek a kritérií projektu a dále plánování podle projektového manuálu a dokumentace v projektovém plánu.
2. Dodávky – cílem je zasílání požadavků na návrhy možným subdodavatelům a vyhodnocování odpovědí a z toho plynoucí nabídky, ze kterých by měly být vybrány ty nejefektivnější.
3. Smluvní management – cílem této aktivity je dohlížet na splňování termínů smluv.
4. Detailní plánování – cílem je vytvoření detailního plánu projektu. Toho je docíleno na základě existujícího předběžného plánu a specifikací v projektovém manuálu.
5. Analýza nákladů a přínosů – cílem je odvodit, do jaké míry jsou výnosná plánovaná řešení
6. Zhodnocení stádia – po dokončení každého stádia projektu následuje jeho zhodnocení, zda je výsledek v souladu s plánovaným stavem či nikoliv.
7. Management rizika – cílem aktivity je co nejdříve odhalit rizika projektu.
Management provádí preventivní měření těchto rizik a následné sledování efektivity preventivních opatření.
8. Kontrola projektu – cílem je kontrolovat vývoj projektu. Pokud jsou zjištěny výchylky od plánu, měly by být managementem zajištěny nápravy problémů, které výchylky způsobily.
9. Informační služba – cílem je zpřístupnit dostupné informace o projektu jeho zákazníkům, subdodavatelům a členům projektového týmu.
10. Školení – cílem této aktivity je školit členy projektového týmu, aby si osvojili vědomosti potřebné k plnění přidělených rolí.
11. Dodavatelské zdroje – cílem je dodávat zdroje potřebné k realizaci projektového cíle.
12. Přidělení objednávek – alokace objednávek k jednotlivým rolím.
13. Školení zaměstnanců
14. Dokončení projektu – cílem je kromě dokončení všech aktivit i sepsání závěrečné zprávy včetně nabytých zkušeností z průběhu projektu.
3.2.2.2. Vývoj systému (SD)
Dalším významným podmodelem VM je vývoj systému (SD), který spravuje aktivity v rámci vývoje systému. Lze jej rozdělit na devět základních aktivit:
1. Analýza systémových požadavků – aktivita zahrnuje sestavení požadavků na systém z pohledu uživatelů.
2. Systémový návrh – cílem této aktivity je vytvoření architektury systému a plán integrace pro tuto architekturu.
3. Analýza softwarových a hardwarových požadavků – aktivita zahrnuje aktualizaci technických požadavků a provozních informací vzhledem k softwarovým a hardwarovým požadavkům. Vychází se z požadavků uživatelů, systémové architektury a dříve odvozených technických požadavků.
4. Předběžný softwarový návrh – aktivita zahrnuje návrh architektury softwaru, popis rozhraní a aktualizaci plánu integrace.
5. Detailní softwarový návrh – předběžný návrh je detailně rozpracován, jsou vytvořeny specifikace pro každý softwarový modul, komponent a jsou vytvořeny databáze.
6. Implementace softwaru – jsou vytvořeny softwarové moduly, komponenty a databáze, jejichž kódy jsou zkompilovány.
7. Integrace softwaru – jsou integrovány moduly, komponenty a je vytvořena databáze. Integrace softwaru probíhá v několika krocích.
8. Integrace systému – jsou integrovány jak softwarové, tak hardwarové komponenty podle systémové architektury.
9. Přechod do provozního stavu – tato aktivita zahrnuje úkoly potřebné ke spuštění systému v prostředí, pro které byl systém navrhován.
3.2.2.3. Zajištění kvality (QA)
V pořadí třetím podmodelem VM je QA, což je model regulující aktivity a produkty ostatních podmodelů jejich zhodnocením před tím, než jsou přijaty. Skládá se z pěti hlavních aktivit:
1. Zahájení QA – tato aktivita zahrnuje specifikaci aktivit, které se zabývají hodnocením kvality ostatních aktivit. Tyto aktivity jsou dokumentovány v plánu QA.
2. Příprava hodnocení – aktivita spočívá ve vytvoření plánu hodnocení, obsahuje definici hodnotících metod, kritérií a zkušební případy.
všechny aktivity v normě vzhledem k plánu.
4. Hodnocení produktu – je testována kvalita produktu. V případě, že produkt splňuje kritéria hodnocení, je přijat, v opačném případě je vrácen do stavu provádění.
5. Zpráva QA – aktivita při které jsou zhodnoceny zprávy o hodnocení jednotlivých aktivit. Jsou spočteny a roztříděny problémy, které nastaly, aby mohly být provedeny nápravné kroky.
3.2.2.4. Management konfigurace (CM)
Posledním podmodelem VM je management konfigurace zajišťující jednoznačnou identifikaci produktu v jakékoliv fázi. Každá modifikace produktu je zaznamenána, což přispívá k celkové integritě.
CM se skládá z 4 stěžejních aktivit:
1. Plánování CM – aktivita při které je definován organizační rámec CM a je vytvořen plán CM.
2. Management produktu – aktivita spočívá ve vytvoření katalogu produktů.
3. Řízení změn - aktivita se dělí na tři kroky. Prvním krokem je požadavek CM na změnu, ve druhém kroku je změna zhodnocena a buď je přijata nebo zamítnuta. V případě přijetí je ve třetím kroku změna implementována a všichni, kterých se tato změna týká, jsou o ní informováni.
4. Služby CM – jedná se o souhrn služeb na podporu CM. Příkladem může být zavádění softwarových produktů do katalogu, zálohování nebo zaznamenávání historie produktů.24
24 [lit12], [lit8]
4. POROVNÁNÍ VYBRANÝCH METODIK
4.1. Cíl a zaměření porovnání
V této kapitole bych rád vyzdvihl hlavní rozdíly mezi metodikou PMBOK a VM nejprve z obecného pohledu a poté i z pohledu zajištění kvality. Oblast QA považuji za jednu z důležitějších oblastí projektového řízení ICT projektů, neboť velké procento ICT projektů končí neúspěchem a zajištění kvality stejně jako kontrola kvality jsou významné faktory, které mohou ovlivnit výsledek projektu. QA nezajišťuje pouze testování aktivit a produktů v jednotlivých fázích projektu, ale umožňuje i zavádění preventivních opatření, které jsou často mnohem levnější než náprava chyb. Toto tvrzení platí obecně nejen pro ICT projekty.
V první části se tedy zaměřím na výhody a nevýhody metodiky VM a PMBOK, v druhé části detailněji analyzuji rozdíly porovnávaných metodik z pohledu PQM a položím si otázku, zda je vhodnější řídit projekt ICT podle metodiky PMBOK nebo VM. Vzhledem k rozsahu obou metodik se zaměřím pouze na úhel pohledu zajištění kvality projektů.
4.2. Výhody a nevýhody srovnávaných metodik
Aby byla metodika využívána a přinášela výsledky v odpovídající kvalitě, je zapotřebí kromě dobrého managementu i aktualizace neboli přizpůsobování metodiky novým podmínkám. Mezi hlavní výhody VM patří možnost jeho uživatelů podílet se na jeho vývoji a údržbě. Jednou za rok jsou shrnuty veškeré návrhy na změny, které jsou zpracovány a případně zavedeny do VM. Podstatnou vlastností VM je tzv. tailoring, tedy možnost přizpůsobovat VM na počátku projektu specifickým podmínkám projektu a to díky tomu, že VM je nezávislý na organizaci a projektu. Dále VM poskytuje asistenci ve formě návodu jak implementovat jednotlivé aktivity projektu. Každé schéma aktivity obsahuje pokyny, doporučení a vysvětlení aktivit, i s praktickými příklady vysvětlujícími tyto aktivity.
Kromě výhod samotného modelu poukáži i výhody vztahující se pouze k metodám VM. Počet metod VM je omezený, což ve výsledku ulehčuje výběr té nejvhodnější, bez nutnosti utápět se v jejich množství. Přehled a definice metod usnadňuje jejich výběr i aplikaci. V neposlední řadě VM podporuje škálu vývojových metodologií. Existují metody, které podporují jak strukturní tak objektový přístup k vývoji systému. Výhodou VM je bezesporu i jeho velká flexibilita, která umožňuje velice snadno do modelu přidávat nové nástroje a metody a stejně tak odebírat z modelu ty zastaralé.
v obslužných jednotkách. Tak je zajištěn jednoznačný objektivní výběr podle toho, které požadavky jsou naplněny. Známé a ověřené nástroje zajišťují, že jejich použití vede k předvídatelným a dobře odhadnutelným výsledkům.
VM není zcela dokonalá a univerzální metodika a má i své nevýhody, které shrnu v následujících odstavcích. Předně bych podotkl, že v metodice VM nejsou zcela objektivně podány informace o jeho nasazení, neboť v [lit7] a [lit12] jsou vypsány pouze jeho kladné stránky a žádné nedostatky. Výhody jsou pouze zmíněny, ale už nejsou vysvětleny. Tento přístup lze považovat za neprofesionální a metodiku tak oslabuje v konkurenci s PMBOK.
Narozdíl od PMBOK je metodika VM zaměřena na vývoj systému v rámci projektu spíše než v rámci organizace. Jedná se o LPM, který je použit jednou v průběhu projektu, zatímco PMBOK je více přizpůsoben celé organizaci. Ve VM jsou aktivity velice abstraktně popsány a je někdy složité stanovit, jaké aktivity jsou podstatné a jaké méně. Některé z aktivit jsou pak pouze vyjmenovány, bez dalšího vysvětlení.
Nyní se zaměřím na příčinu selhávání projektů, kterou bývá velice často neuspokojení požadavků zákazníka. Z logického hlediska jsou pro každý projekt stěžejní právě analýza a management požadavků. Selhání projektů bývá způsobeno více managementem a špatným tréninkem, než technickými problémy. Někteří manažeři tvrdí, že ICT projekt mohou řídit i manažeři, kteří nejsou přímo informatici, stejně jako auto může řídit řidič, jež není automechanik. Tento názor není obecně platný a zmiňuji ho zde především v souvislosti s další vlastností metodiky VM. Obsahuje totiž podrobnější charakteristiky manažera kvality pro ICT projekty, včetně požadavků na jeho schopnosti. Tato role bude více přiblížena v další kapitole při srovnání metodik podle QA.25
Zajímavostí VM je fakt, že VM není určen pouze pro vývoj softwaru, ale je navržen pro vývoj systému zahrnující jak software, tak hardware. Software je bezesporu závislý na hardwaru a tato skutečnost není zakomponována v PMBOK. Důvodem může být i vlastnost PMBOK, že tato metodika není zaměřena pouze na projekty ICT.
V závěru podkapitoly připomenu vlastnost tailoring v metodice VM. Na začátku každého projektu metodiky VM probíhá přizpůsobení podmínkám a dochází ke vzniku vždy specifického projektu. Po skončení projektu jsou zkušenosti z projektu zavedeny do
25 [lit11]
databáze k tomu určené. Dle [lit8] je vedení takové databáze pouze mrhání prostředků, neboť projekty jsou svou unikátností ne příliš srovnatelné. Dle mého názoru i v unikátních projektech se vyskytují fáze a aktivity, které se členové týmu z důvodu úspory času snaží provádět obdobným způsobem jako v předchozích projektech. Pak i přes unikátnost projektů nalezneme shodné aktivity a zaznamenávání průběhu aktivit má význam.
4.3. Porovnání modelů z hlediska zajištění kvality
Jak bylo uvedeno na začátku čtvrté kapitoly, zajištění kvality má nejen u ICT projektů velký význam, proto budou v této podkapitole metodiky VM a PMBOK srovnány z pohledu kvality.
Podmodel QA v metodice VM je zaměřen na hodnocení produktů a aktivit v rámci projektu. Cílem QA je zhodnocení aktivit a produktů vzhledem k plánu, standardům a definicím. Produkty a aktivity mohou být buď přijaty nebo zamítnuty, ale VM je v této fázi příliš abstraktní na to, aby bylo možné navrhnout změny v případě, že má dojít k zamítnutí.
V metodice PMBOK je zajištění kvality popsáno způsobem, který je kompatibilní s ISO standardy a je možné jej srovnávat i s přístupy jakými jsou např. Total Quality Management (TQM) nebo Cost of Quality (COQ). V metodice VM také existuje napojení na standardy ISO, ale nenajdeme v něm zmínku o přístupech TQM, což není z hlediska zajištění kvality pro ICT zcela nezbytné.
Porovnám-li celkovou strukturu zajištění kvality v metodice PMBOK a VM, lze říci, že v PMBOK je PQM rozdělen do tří částí: plánování kvality, aplikace toho, co bylo naplánováno v první fázi, a v poslední části se provádí testování a porovnávání výsledků s plánovaným. Každá z těchto částí je dále rozdělena na vstupy, techniky a nástroje a výstupy. Naproti tomu metodika VM lépe popisuje kromě aktivit spojených s testováním kvality i dokumenty, protokoly a další systémové prvky, které je třeba vytvořit pro zajištění kvality produktů. Právě na takové prvky klade VM velký důraz a jejich hodnocení má velký význam pro manažera kvality. Tato role je ve VM rozpracována podrobněji než v PMBOK a bude blíže analyzována v následujícím odstavci.
Tím, že je VM zaměřen více na užší spektrum projektů, konkrétně na ICT projekty, je v něm specifikována i role manažera kvality. Té jsou vymezeny pravomoci a stanoveny úkoly, kterých má dosáhnout, jsou definovány i požadované schopnosti manažera. Takto detailní rozpracování v metodice PMBOK nenalezneme, neboť ta není zaměřena na vývoj
jiné. Lze tedy i to vymezení role považovat za velkou výhodu metodiky VM.
Ve VM v sekci „aktivity“ (pro činnosti vztahující se k zajištění kvality) jsou k nalezení nástroje a techniky pro řízení kvality, tudíž tato sekce odpovídá části „Nástroje a techniky“
v PMBOK. VM požaduje zavedení tzv. QS – příručky, což je dokument vytvářený pro daný projekt, soužící jako příručka řízení kvality, přizpůsobena konkrétnímu projektu. V metodice PMBOK neexistuje taková příručka v ucelené formě, ale jako několik samostatných dokumentů.
Co se týče nástrojů kontroly kvality v jednotlivých metodikách, PMBOK odkazuje např.
na techniky „fishbone diagram“, paretům diagram, bodový graf a další. Tyto metody, podle mého názoru, nejsou zcela vhodné pro kontrolu kvality v oblasti ICT. VM v této sekci nabízí metody, kterými jsou např. funkční test, test výkonu, test zdrojů, obnovy, test užití, systémový test a další. Právě z tohoto pohledu je zřejmé, že VM má jasné přednosti v kontrole kvality ICT projektů, než metodika PMBOK, která nemá tak jasně vymezení použití.26
4.4. Tabulka srovnání metodik
Tabulka obsahuje jednak obecná kritéria pro srovnání metodik a dále výběr zajímavějších odlišností vztahující se k QA.
Metodika
V-Modell PMBOK
Obecné hledisko
Obecné povědomí o metodice malé velké
Možnost uživatelů podílet se na vývoji metodiky
každoroční implementace schválených změn, které
byly navrženy uživateli
menší možnost uživatelů podílet se na vývoji
Zaměření modelu převážně ICT velká škála oblastí PM včetně ICT
Tailoring podporuje podporuje
Závislost metodiky na organizaci /
projektu nezávislá / nezávislá střední závislost / střední závislost
26 [lit8], [lit12]
Existence praktických příkladů ano (často příliš obecné) ne Existence objektivních informace pro
nasazení metodiky neobsahuje záporné
vlastnosti metodiky obsahuje objektivní informace Existence vývojových metodologií pro
strukturní / objektový přístup ano / ano ano / ano Flexibilita přidávání / odebírání nástrojů a
metod z modelu velká střední
Počet metod na výběr menší množství, snazší
orientace větší množství Zaměření metodiky na vývoj SW v
závislosti na HW ano ne
Hledisko QA
Rozsah zpracování QA srovnatelný s PMBOK srovnatelný s VM
Kompatibilita s ISO standardy ano ano
Struktura popisu PQM
rozdělení PQM do kapitol (aktivity, produkty, role...)
shrnutí PQM do jedné kapitoly Techniky vhodné pro kontrolu kvality v
oblasti ICT vhodné techniky techniky nejsou
zaměřené na ICT
Popis návrhu změn, pokud je produkt
nebo aktivita zamítnuta z hlediska kvality příliš abstraktní dobrý
Specifikace role manažera kvality ano ne
5. ZÁVĚR
V této práci jsem se zaměřil na porovnání dvou metodik projektového řízení, které jsou k dispozici k řízení ICT projektů. Metodikami jsou PMBOK a V-Modell (VM), přičemž první z nich je obecně rozšířenější, naproti tomu VM je více zaměřena na ICT projekty.
Porovnání jsem provedl nejprve na obecné úrovni a následně i se zaměřením na zajištění kvality, což je nezbytný faktor ovlivňující úspěšnost finálního produktu projektu.
Výsledkem porovnání je vyzdvižení silných a slabých stránek obou metodik, které napomáhá při rozhodování při výběru vhodné metodiky k řízení ICT projektu. Bylo bráno v úvahu zaměření metodik na oblast ICT, možnost aktualizace metodik v souvislosti s rychlým vývojem oblasti ICT, dále byla porovnána vhodnost metod pro kontrolu kvality a kompatibilitu s ISO standardy.
Metodika PMBOK je z obecného hlediska častěji používána a její metody jsou postaveny na ověřených postupech. VM byla nasazena především v Německu, není tolik rozšířena, ale přesto je konkurenceschopná díky neustálému vývoji a svému zaměření na ICT. Nespornou výhodou VM naproti PMBOK je tailoring, tedy možnost přizpůsobovat metodiku projektu, flexibilněji přidávat a odebírat metody v závislosti na podmínkách projektu. VM naopak neobsahuje objektivní hodnocení, konkrétně slabé stránky VM.
Metodiku VM považuji za vhodnější pro menší ICT projekty, neboť VM není přizpůsobena projektům, které jsou odrazem celé organizace. VM dává spíš návod, jak řídit samostatné projekty, nikoliv jejich komplex. V případě, že by byl doplněn VM o procesní model na celoorganizační úrovni, navrhl bych VM jako vhodnější metodiku pro ICT projekty.
Z hlediska zajištění kvality je VM abstraktnější než PMBOK a v některých případech není jasné, jaké metody jsou důležitější. Výhodou pak jsou vhodnější metody pro kontrolu kvality.
6. SLOVNÍK POUŽITÝCH POJMŮ
AM - alokace metod
CM – management konfigurace CPM - Critical Path Method DOE - Návrh experimentů
FTR - požadavky na funkční nástroje (Functional Tool Requirements) IPMA - International Project Management Association
LPM - Lifecycle Process Model PM – projekt management
PMBOK - A Guide to the Project Management Body of Knowledge PMI - Project Management Institute (PMI)
PERT - Program Evaluation and Review Technique PQM - Project Quality Management
QA – zajištění kvality SD – vývoj systému
SDE - Software Development Environment TQM – Total Quality Management
VM – V-Modell XT VM97 – V-Modell 97
WBS - Work Breakdown Structure
7. SEZNAM POUŽITÉ LITERATURY
[lit1] PMBOK Guide – 3rd Edition, 2004, PMI, Four Campus Boulevard, Newton Sq., USA [lit2] PROCHÁSKOVÁ J., 2004, ‘Analýza metodik projekt managementu pro malé a střední
ICT firmy‘. Bakalářská práce, VŠE Praha
[lit3] Wikipedia – otevřená encyklopedie, ‚Project Management‘, staženo 2.6.2007 z http://en.wikipedia.org/wiki/Project_management
[lit4] ICT Project Management, ‘Infocomm Education Programme‘, IPS Associates Asia Pte Ltd, Singapure
[lit5] Finance-Management, webový portál, ‘definice cíle SMART‘, staženo 15.7.2007 z http://www.finance-
management.cz/080vypisPojmu.php?X=Definice+cile+SMART+Project+Management&IdPoj Pass=39
[lit6] Wikipedia – otevřená encyklopedie, ’SMART (project management)‘, staženo 2.6.2007 z, http://en.wikipedia.org/wiki/SMART_%28project_management%29
[lit7] V-Modell XT v.1.1.0 part 1, IABG Industrieanlagen-Betriebsgesellschaft mbH, medotika, staženo 20.6.2007 z
http://v-modell.iabg.de/index.php?option=com_docman&task=doc_download&gid=32
[lit8] JOHANSSONC., BUCANAC Ch, 1999, ‘The V-Modell. Federal Armed Forces‘, University of Karlskrona, Ronneby
[lit9] ‚V-Modell 97‘, IABG Industrieanlagen-Betriebsgesellschaft mbH, medotika, staženo 20.6.2007 z http://v-
modell.iabg.de/index.php?option=com_docman&task=doc_download&gid=31&Itemid=30 [lit10] EUROPOL, 2007, ‘IMT System Life Cycle Management‘, European Police Office [lit11] Coley Consulting, ‘Why Projects Fail’, staženo 17.7.2007 z
http://www.coleyconsulting.co.uk/failure.htm
[lit12] ‘V-Modell XT v.1.2.0 teil 1-9‘, IABG Industrieanlagen-Betriebsgesellschaft mbH, metodika, staženo 8.7.2007 z http://v-
modell.iabg.de/index.php?option=com_docman&task=cat_view&gid=15&Itemid=30
