Agilní a tradiční metodiky. v projektovém řízení

Save this PDF as:
 WORD  PNG  TXT  JPG

Rozměr: px
Začít zobrazení ze stránky:

Download "Agilní a tradiční metodiky. v projektovém řízení"

Transkript

1 Masarykova univerzita Fakulta informatiky Agilní a tradiční metodiky v projektovém řízení Diplomová práce Ing. Jakub Pejchal Brno, 2015

2 Prohlášení o autorství Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně dne Ing. Jakub Pejchal Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D.

3 Poděkování Děkuji panu doktorovi Ráčkovi za vedení diplomové práce, poskytnutí odborných rad a připomínek a za vstřícný přístup při konzultacích.

4 Shrnutí Diplomová práce se zabývá problematikou projektového řízení. Představuje vybrané zástupce metodik používaných při vývoji softwaru a zástupce standardů projektového řízení. Uvádí způsoby, kterými lze zvolené standardy a metodiky kombinovat při zachování jejich výhod a na reálném projektu aplikuje jednu z možných kombinací. Klíčová slova Projekt, projektové řízení, metodika, standard, metriky.

5 Obsah 1 Úvod Principy projektového řízení Projekt Životní cyklus projektu Projektové řízení Odlišnosti ICT projektů Metodiky budování ICT projektů Srovnání tradičních a agilních metodik Výběr vhodné metodiky Scrum Role Artefakty Činnosti ve Scrumu Rational Unified Process Dynamický pohled Statický pohled Standardy projektového řízení Standard PMBOK Procesní skupiny Znalostní oblasti Standard PRINCE Principy Témata Procesy Kombinace standardu a metodik Kombinace PMBOK a Scrum Kombinace PRINCE2 a Scrum Kombinace PMBOK a RUP Kombinace PRINCE2 a RUP... 38

6 6 Pilotní projekt Předprojektová fáze Iniciační fáze Nastavení projektu Řízení přechodu mezi etapami Realizační fáze Dodání produktu Kontrola etapy Směrování projektu Fáze ukončení Návrh metrik Závěr Bibliografie... 60

7 1 Úvod Potřeba koordinovat a řídit jednotlivé činnosti se pojí se vznikem společenské dělby práce a historicky ji lze dokumentovat například na složitých stavbách typu egyptských pyramid nebo starořeckých staveb, kdy vznikala potřeba plánovat a organizovat veškeré práce, které s realizací staveb souvisely. Toto období lze považovat za základ oboru, který byl později nazván projektovým řízením a který postupem času nabýval na významu v různých odvětvích. Na konci 20. století se teoretické přístupy integrovaly a aplikovaly v praxi a proces řízení se stal široce používanou metodou, která efektivně zajistí dodání a vývoj nových produktů a služeb. Projektové řízení dnes představuje ověřené a stanovené postupy, které vychází z praktických zkušeností, definují konkrétní činnosti a v nich stanovují jednotlivé kroky. Označují se jako projektové metodiky. Ty mohou být specializované pro jeden obor nebo jsou použitelné pro vedení různých typů projektů a z některých se staly de facto standardy projektového řízení. V oblasti ICT prošly v posledních letech zásadním vývojem. Zde můžeme rozlišit tradiční metodiky, které jsou procesně orientované, formalizované, nutí používat řadu předepsaných dokumentů a agilní metodiky, které charakterizuje jednoduchost a flexibilita, která umožňuje rychle reagovat na změny v projektu. Přestože agilní metodiky vznikly jako reakce na nevýhody metodik tradičních, ne vždy je jejich zavedení vnímáno pozitivně. Výhody jednotlivých metodik lze využít při jejich kombinování, které se stále častěji v korporacích prosazuje. Na danou oblast je také zaměřena diplomová práce, jejímž cílem je prezentovat možné kombinace procesně orientovaných standardů projektového řízení a metodik vývoje softwaru a jejíž částí je také návrh na řešení projektu průmyslového partnera. Druhá kapitola Principy projektového řízení uvádí do problematiky projektového řízení, vymezuje základní pojmy jako projekt, životní cyklus projektu, projektové řízení a představuje hlavní odlišnosti ICT projektů. Rozdělení metodik budování ICT projektů, srovnání tradičních a agilních metodik a výběru vhodné metodiky se věnuje třetí kapitola Metodiky budování ICT projektů. Tato kapitola také představuje metodiky Scrum a Rational Unified Process jako typické zástupce dvou odlišných kategorií. Čtvrtá kapitola pojednává o procesních standardech projektového řízení A Guide to the Project Management Body of Knowledge (PMBOK) a PRojects IN Controlled Environments (PRINCE2). 1

8 V páté kapitole autor na základě mapování vybraných procesů vzájemně kombinuje výše zmíněné standardy a metodiky se záměrem procesy zefektivnit a optimalizovat. Šestou kapitolou je Pilotní projekt zpracovaný pro partnerskou organizaci. Na reálném projektu webového portálu aplikuje standard PRINCE2 propojený s metodikou Scrum. Závěrečný Návrh metrik je přehledem nástrojů používaných při měření vlastností projektů, ke kterým patří rozsah, čas, náklady a kvalita projektu. 2

9 2 Principy projektového řízení Projektové řízení lze obecně charakterizovat jako proces, jehož záměrem je naplánovat a realizovat řadu činností, které slouží k dosažení požadovaných cílů. Při nich je nutné dodržet stanovené termíny, kvalitu a nepřekročit plánované náklady. Význam projektového řízení jako disciplíny roste s tím, jak v podnikatelském prostředí dochází ke změnám, zvláště při zavádění nových produktů a procesů, které vyžadují také změny v manažerských strategiích. V úvodu diplomové práce je vhodné vymezit základní pojmy, které souvisí s problematikou projektového řízení obecně. Cílem první kapitoly je představit definice základních pojmů tak, jak je uvádějí významné organizace a autoři. 2.1 Projekt Základním pojmem, který se používá při řízení projektů, je termín projekt. Byla pro něho vytvořena řada definic, z nichž většina projekt charakterizuje obdobným způsobem. Project Management Institute ve standardu A Guide to the Project Management Body of Knowledge (PMBOK) definuje projekt jako dočasné úsilí vynaložené na vytvoření unikátního produktu, služby nebo určitého výsledku [1]. Standard PRojects IN Controlled Environments (PRINCE2) britské Office of Government Commerce (OGC) charakterizuje projekt jako dočasnou organizaci, která je vytvořena za účelem dodání jednoho nebo více produktů na základě odsouhlaseného obchodního případu 1 [2]. Dle Společnosti pro projektové řízení, která je členem evropské organizace International Project Management Association (IPMA), je projekt jedinečný časově, nákladově a zdrojově omezený proces realizovaný za účelem vytvoření definovaných výstupů (naplnění projektových cílů) v požadované kvalitě a v souladu s platnými standardy a odsouhlasenými požadavky [3]. Ke třem hlavním charakteristikám projektu patří čas, rozsah a náklady veličiny, které mají limity a vymezují tak prostor, ve kterém se projekt vytváří podle projektového plánu. Vztah výše uvedených a vzájemně provázaných charakteristik se označuje jako 1 Obchodní případ (Business Case) popisuje zdůvodnění projektu, oprávněnost jeho zahájení a pokračování. 3

10 projektový trojimperativ nebo trojí omezení, přičemž cílem projektového manažera je dosáhnout jejich optimální kombinace. 2.2 Životní cyklus projektu Projekt je v čase realizován v postupných a na sebe navazujících krocích, definovaných v zadání projektu, které umožní dosáhnout cíle. V průběhu realizace se dostává do různých fází, tedy z hlediska řízení projektů do skupin logicky vzájemně souvisejících činností, které tvoří životní cyklus projektu. PMBOK definuje životní cyklus projektu jako sérii fází, kterými projekt prochází od jeho zahájení po jeho ukončení [1]. Dle PRINCE2 se za životní cyklus projektu považuje období od zahájení projektu do akceptace jeho produktu [2]. Podle IPMA se jedná o skupinu sekvenčně za sebou jdoucích fází vyjadřujících průběh života daného projektu [3]. Obecně lze říci, že životní cyklus projektu určuje, jaká práce má být v určité fázi provedena, jaké výstupy a kdy je nutné dodat, které osoby se konkrétní fáze účastní a jak budou kontrolovány a schvalovány výsledky z jednotlivých fází. Projektové fáze se liší podle typu projektu, jeho velikosti, komplexnosti a dle oboru, ve kterém projekt vzniká. Obecná struktura, kterou lze aplikovat u všech projektů, rozlišuje fáze zahájení, organizace a přípravy, realizace projektových prací a dokončení projektu. Obrázek 1: Obecný životní cyklus projektu [4] 4

11 2.3 Projektové řízení Řízení projektu umožňuje prostřednictvím projektu efektivně vykonávat řadu činností: stanovit cíl, vymezit časovou náročnost, definovat materiální, lidské, finanční zdroje a všechny potřebné činnosti v projektu koordinovat. PMBOK označuje projektové řízení za uplatnění znalostí, dovedností, nástrojů a technik při realizaci projektových aktivit za účelem dosažení požadavků projektu [1]. PRINCE2 považuje za projektové řízení plánování, delegování, monitorování a kontrolu všech stránek projektu a motivování všech zúčastněných k dosažení cílů projektu v předepsaném čase, nákladech, kvalitě, rozsahu, výhodách a rizicích [2]. IPMA charakterizuje projektové řízení jako aplikaci znalostí, dovedností, nástrojů a technik na činnosti v projektu tak, aby projekt splnil požadavky na něj kladené. Zahrnuje plánování, organizování, monitorování a předávání zpráv o všech aspektech projektu a motivaci všech zúčastněných dosáhnout cílů projektu [3]. Řízení projektu je zaměřeno na řízení jednoho projektu. Lze se setkat také s pojmy řízení programů a řízení portfolia, které slouží k řízení skupiny projektů. Rozdíl mezi nimi spočívá v tom, že v portfoliu nemají projekty a programy společný cíl a jsou seskupené za účelem řízení, kontroly a koordinace cílů; naopak program je skupina věcně souvisejících projektů a organizačních činností řízených společně. 2.4 Odlišnosti ICT projektů ICT projekt je projekt v oblasti informačních a komunikačních technologií využívající k vytvoření produktu, služby či výstupu hardwaru, softwaru a/nebo sítí [5]. ICT projekty se od ostatních projektů liší především v následujících charakteristikách [6]: Jejich produkty jsou převážně nehmotné povahy, tedy obtížněji definovatelné a mentálně uchopitelné. Tato vlastnost může být i jedním z důvodů stále nepříliš velkého procenta úspěšných projektů ICT. Nemají většinou jasně definované zadání, cíle, uživatelské požadavky, obsah jednotlivých výstupů. Tyto obsahové náležitosti projektu se objasňují až v průběhu projektu. 5

12 Podporují podnikové procesy a jsou jedním z nástrojů dosahování reálných potenciálů zlepšení podnikových procesů. Tato skutečnost ale současně významně ovlivňuje množství projektových změn, které musí být v průběhu projektu zpracovávány a integrovány do řešení. Terminologie, metodiky, metody a techniky související s řízením projektů ICT a budováním ICT nejsou jednotné. Obrázek 2: Obecný životní cyklus ICT projektu [4] ICT projekty se vyznačují jedinečností, neopakovatelností, dočasností, časovým vymezením projektu, jeho rozsahem, náklady, neurčitostí spojenou s riziky, postupným upřesňováním řešení, identifikací zadavatele a uživatele a interdisciplinárním charakterem. Odlišují se také v požadavcích na zdroje, které ve srovnání s běžnými projekty dosahují maxima přibližně ve 40 % délky životního cyklu projektu. 6

13 Obrázek 3: Odlišné nároky na zdroje ICT projektů (Autor dle [7]) 7

14 3 Metodiky budování ICT projektů Metodika obecně představuje souhrn metod a postupů určených k realizaci konkrétního úkolu. V oblasti řízení ICT projektů je terminologie nejednoznačná, protože někteří autoři do definice zařazují činnosti vázané na vývoj ICT, zatímco jiní do ní zahrnují také oblast provozování ICT. Podle Voříška [8] je metodika budování ICT tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu. Cílem metodiky je formalizovat postupy, definovat zodpovědnosti a pravidla komunikace. Bruckner a kol. [6] uvádí, že metodika budování ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. Tato definice odpovídá spíše tradičním metodikám, agilní definují jen principy a praktiky. Slovo budování vystihuje jak tvorbu informačních systémů, tak nasazení hotových řešení a rozšiřování a integrování stávajících systémů. Existuje řada metodik budování ICT. Je tomu tak proto, že odlišné technologie vyžadují odlišné metodiky, že se metodiky přizpůsobují organizacím a týmům nebo projektům. Každá metodika zdůrazňuje jiné aspekty, např. vývoj, některé fáze životního cyklu, přístup k řešení, velikost týmu apod. a metodiky je proto obtížné vzájemně srovnávat. Metodiky lze členit podle následujících kritérií [9]: Zaměření metodiky hodnotí se, zda se jedná o metodiku zaměřenou na jednotlivý projekt nebo budování ICT celé organizace (projektové a globální metodiky). Rozsah metodiky je dán počtem fází životního cyklu informačního systému pokrytých metodikou (metodiky pokrývající celý životní cyklus tvorby a metodiky dílčí). Váha metodiky váha metodiky je součin velikosti (počet kontrolních prvků v metodice) a hustoty metodiky (podrobnost a konzistence prvků). Toto kritérium vymezil A. Cockburn a dělí metodiky na lehké a těžké (rigorózní). Typ řešení rozlišuje vývoj nového řešení, integrace řešení, rozvoj a rozšíření, customizace, implementace a užití. Doména představuje oblast, pro kterou je systém vytvářen (Business Intelligence, Customer Relationship Management, obecný software, Content Management, Enterprise Application Integration, e-commerce, Enterprise Resource Planning). 8

15 Přístup k řešení rozlišuje paradigma vývoje (strukturovaný vývoj, rychlý vývoj aplikací, objektový vývoj, komponentový vývoj, vývoj orientovaný na služby). 3.1 Srovnání tradičních a agilních metodik Metodiky je možné na základě kritéria váha metodiky, které zohledňuje podrobnost a přesnost metodiky, členit na těžké tradiční (rigorózní) a lehké agilní. Tradiční metodiky jsou velmi podrobné, formální, direktivní a společně s referenčními modely procesů, různými modely životního cyklu, posuzováním zralosti a způsobilosti procesů jsou součástí tradičních přístupů budování informačních systémů [6]. Přesně stanovují procesy, všechny požadavky a produkty, předpokládají, že tvorbu IS lze přesně definovat, popsat a opakovaně realizovat. Většina těchto metodik je založena na vodopádovém modelu životního cyklu, ve kterém jednotlivé fáze vývoje softwaru následují po sobě, např. Structured Systems Analysis and Design Method (SSADM). Některé mohou vycházet z iterativního modelu životního cyklu, který rozkládá celý projekt na řadu iterací, přitom každá iterace obsahuje všechny fáze vývoje, např. Rational Unified Process. Tradiční metodiky je vhodné použít u standardních a velkých projektů. Agilní přístupy jsou opakem tradičních. Vychází z předpokladu, že proces tvorby informačního systému nelze přesně popsat, má být pružný a má nabízet rychlá řešení. Nedefinují procesy, ale popisují jen principy a praktiky a jsou tak zbaveny byrokratické zátěže. Vychází ze zkušeností získaných během vývoje, kdy je třeba projekt přizpůsobovat aktuální situaci a reagovat na změny a na požadavky zákazníka. Tyto metodiky je vhodné použít pro projekty s nejasným nebo měnícím se zadáním, pro menší týmy. Myšlenky a principy agilních metodik jsou obsaženy v Manifestu agilního vývoje software, který je jejich základním dokumentem. Principy agilních metodik tak, jak jsou uvedené v Manifestu, vychází ze čtyř základních myšlenek, které preferují [10]: Jednotlivce a interakce před procesy a nástroji. Fungující software před vyčerpávající dokumentací. Spolupráci se zákazníkem před vyjednáváním o smlouvě. Reagování na změny před dodržováním plánu. Protože tradiční a agilní metodiky vychází z odlišných předpokladů a z jiného pohledu na vývoj softwaru, jsou jinak zaměřené a vhodné pro jiný typ projektu. 9

16 Nástroje metodiky Podrobnost metodiky Kvalita Předvídatelnost Změny Participace zákazníka na projektu Specializace lidí Rigorózní metodiky Procesy se zaměřují na formálnost a dokumentovatelnost, lidé jsou sekundární faktor Podrobný popis činností a procesů Zaměření na kvalitu procesů, které povedou ke kvalitnímu výsledku Sběr požadavků a plánování předem Snaha změny minimalizovat a řízení změn Jen v počátečních a koncových fázích Vyžaduje specializaci pro týmové role Agilní metodiky Praktiky vychází ze znalostí jednotlivců, lidé jsou klíčovým faktorem úspěchu Pouze základní struktura Zaměření na priority zákazníka Přírůstkové shromažďování požadavků, plánování po iteracích Snaha změny umožnit s ohledem na nové znalosti Po celou dobu projektu Sdílení znalostí a spolupráce v týmu Dokumentace Rozsáhlá dokumentace Minimální dokumentace, podstatné je pochopení Způsob vývoje Vodopádový, iterativní s dlouhými iteracemi Přírůstkový vývoj s velmi krátkými iteracemi Forma Převážně písemná Osobní komunikace Tabulka 1: Porovnání rigorózních a agilních metodik (Autor dle [11]) Tradiční a agilní metodiky se dále liší v proměnných trojimperativu. Tradiční projektové řízení na začátku definuje množinu požadavků (rozsah), kterou považuje za neměnnou. Dle nich odhaduje čas a náklady potřebné na realizaci, které jsou proměnnými veličinami. Naopak agilní řízení projektů považuje za neměnné čas a zdroje a proměnnou veličinou je rozsah, který je přizpůsobován prioritám zákazníka. 10

17 Obrázek 4: Porovnání trojimperativu u rigorózních a agilních metodik (Autor) S ohledem na velký rozvoj agilních metodik v posledních deseti letech by se dalo usuzovat, že se jedná o univerzální metodiky, které by mohly nahradit tradiční přístupy, což byla i myšlenka jejich vzniku. Realita je však jiná. Ne vždy jsou agilní metodiky nejlepším přístupem, např. když je třeba zvažovat řadu parametrů charakteristických pro projekt. Vhodná může být kombinace obou přístupů, kdy lze odlehčit rigorózní metodiky obohacením o agilní prvky. 3.2 Výběr vhodné metodiky Volba vhodné metodiky není jednoduchou záležitostí. Návrh ovlivňuje řada faktorů, které různí autoři definovali a použili při výběru. Charvat [12] používá jednoduché měřítko pro volbu mezi agilními a tradičními metodikami. Kombinuje délku trvání projektu s jeho složitostí a pro takto získanou velikost projektu doporučuje použít příslušnou metodiku. Alistair Cockburn [13] u agilních metodik Crystal vychází z faktoru počet lidí zapojených do projektu a z důležitosti projektu. Počet lidí udává velikost pracovní skupiny, důležitost je vztažena k velikostem ztrát při selhání projektu (od diskomfortu po ohrožení života). Boehm a Turner [14] formulovali pět základních faktorů: Faktor Agilní Tradiční Velikost Malé produkty a týmy. Velké produkty a týmy. Kritičnost Nedostatečně ověřené u životně důležitých projektů, možné potíže kvůli jednoduchému návrhu a omezené dokumentaci. Přizpůsobené pro životně důležité projekty, pro malé projekty zbytečně složité. 11

18 Dynamika Lidé Kultura Vhodné pro často se měnící prostředí. Vyžaduje přítomnost SW expertů po celou dobu projektu. Vhodné pro stabilní prostředí. Přítomnost SW expertů při definování projektu, později specialisté nejsou vyžadováni. Pocit komfortu + podpora Pocit komfortu + jasně definované volnosti. role a procedury. Tabulka 2: Faktory v agilních a tradičních metodikách [14] Jejich kritéria doplnil Taylor [15] o faktor zapojení zákazníka do projektu, kdy rozlišuje jeho přímou účast při řešení projektu a zohledňuje důvěru zákazníka v agilní principy. Hecksel [16] patentoval systém výběru a hodnocení metodik. Ohodnotil projekt, tj. definoval Projektový kontext složený ze tří částí Lidé, Proces, Technologie. V každé části definoval vlastnosti typické pro projekt (název, popis, hodnocení, stupnice hodnot). V modelu metodik stanovil jednotlivé metodiky a zvolil pro ně hodnocení. Pomocí statistik, simulací a predikcí porovnával hodnoty atributů Projektového kontextu s hodnotami metodik obsažených v modelu a hledal mezi nimi shodu. Buchalcevová [9] v systému hodnocení metodik METES (Methodology Evaluation System) používá čtyři skupiny kritérií: Proces (skupina hodnotí rozsah, model životního cyklu, role, podrobnost popisu procesu, dokumenty, metriky, řízení kvality), Podpora (hodnotí celistvost zdrojů, dostupnost, podporu metodiky softwarovými nástroji, podporu zavedení metodiky, přizpůsobení, výuku na vysokých školách, školení a certifikace, lokalizaci), Produkt (důležitost produktu, délku projektu, stálost požadavků, znovupoužitelnost, velikost řešení), Lidé (zkušenost manažera projektu, kvalifikace a motivace členů týmu, velikost týmu, rozmístění, dostupnost uživatelů). Z uvedeného přehledu je zřejmé, že volba kritérií je individuální záležitostí. Cílem práce je vybrat vhodnou agilní a rigorózní metodiku pro kombinaci se standardem projektového řízení pro partnerskou organizaci. Tato partnerská organizace má zkušenosti s metodikami Scrum a RUP, které doposud při vývoji softwaru používala. Toho využívá také autor, který ve své práci vychází z těchto dvou metodik jako typických a propracovaných představitelů svých kategorií. Scrum je procesní rámec pro vývoj a údržbu produktů postavený na iterativním a inkrementálním vývoji. Zdůrazňuje spolupráci v týmu, komunikaci se zákazníkem a je flexibilní vůči změnám v projektu. V současné době je nejpoužívanější agilní metodikou, kterou dle průzkumu z roku 2013 používá 73 % organizací [17] a mnohými autory je také synonymem pro agile [18]. Někteří považují výběr Scrumu za nejlepší volbu pro řešení jakéhokoliv projektu [19]. RUP lze 12

19 charakterizovat jako deskriptivní, podrobně popisující procesy a činnosti během vývoje softwaru. Obsahuje nástroje, postupy a techniky, které se používají při vývoji softwaru a je téměř standardem mezi těžkými metodikami [20]. Výhodou je možnost nastavení na míru danému projektu. Nabízí také možnost využít i předem připravené varianty řešení, které lze snadno a ihned začít používat. Díky své složitosti se více hodí na projekty většího rozsahu. 3.3 Scrum První informace o Scrumu sahají do roku 1986, kdy byly popsány nové možnosti při řízení týmů. V názvu (skrumáž) se využívá metafora s ragbyovým zápasem, tedy označení pro rychlý a adaptivní proces, jehož cílem je postupovat po určitých částech až k zamýšlenému bodu, podobně jako je tomu v ragbyovém zápase. Metodika se dokáže vyrovnat s měnícími požadavky a vylepšit produktivitu procesu vývoje softwaru [21]. K tomu užívá každodenní přezkoumání realizovaných požadavků, stanovení dalších kroků a maximální spolupráci uvnitř týmu i intenzivní komunikaci se zákazníkem. Scrum je procesní rámec vhodný především pro malé týmy o několika členech, který pomáhá zvládnout složité adaptivní úkoly, do projektu však umožňuje zapojit i více týmů. Životní cyklus produktu ve Scrumu zahajuje Vlastník produktu (Product Owner), který definuje cíle projektu. Vytvoří Product backlog, tedy seznam požadavků seřazených podle priority. Celý vývoj probíhá v iteracích označovaných Sprinty. Pro každý Sprint si Vývojový tým naplánuje množství práce, kterou během Sprintu stihne dokončit. Ta je obsahem Sprint backlogu a je detailním popisem úkolů vybraných z Product backlogu pro nejbližší období. Součástí Sprintu je několik povinných schůzek [22]: Plánovací schůzka (Sprint Planning), Denní schůzka (Daily Scrum), Vyhodnocení sprintu (Sprint Review) a Retrospektiva sprintu (Sprint Retrospective), na nichž probíhá plánování činností, odhady práce, zpětná kontrola vykonané práce, přezkoumání a vyhodnocení přírůstku dokončené práce, úprava backlogu, návrhy na zlepšení. Po určitém počtu Sprintů, kdy jsou stanovené cíle splněny, je produkt dokončen. 13

20 Obrázek 5: Životní cyklus produktu v metodice Scrum (Autor dle [23]) Role Role definují funkce, ve kterých vystupují lidé zapojení do Scrumu. Metodika definuje tři základní role: Vlastník produktu, Vývojový tým a Scrum master, kteří společně tvoří Scrum tým. Scrum tým je sebeorganizující, sám si volí, jak provede práci a je zcela soběstačný. Vlastník produktu Je autoritou, která reprezentuje zájmy zákazníka a zodpovídá za návratnost jeho investice. Je odpovědný za zadání projektu, za rozhodnutí o rozsahu, rozpočtu a termínech projektu. Definuje požadavky, vybírá řešení a stanovuje prioritní vlastnosti projektu tak, aby byl Vývojový tým seznámen s dalším postupem. Je také klíčovou osobou při plánování, definuje akceptační kritéria pro každou položku backlogu a ověřuje jejich splnění, spolupracuje se všemi účastníky projektu. Scrum master Zodpovídá za dodržování pravidel Scrumu. Působí jako agilní kouč pro obě další role, kterým napomáhá ve vzájemné komunikaci a udržuje jejich činnost v mantinelech Scrumu. Pomáhá týmu dosáhnout cílů, odstraňuje problémy, motivuje tým k lepším výsledkům, chrání ho před vnějšími vlivy. Měl by usnadnit práci týmu a směrovat ho ke schopnosti samostatně se řídit. Je autoritou, snaží se zavést hodnoty, principy a zvyklosti Scrumu. 14

21 Vývojový tým Tým je multifunkční jednotka, která obsahuje všechny potřebné profese. Je složený z profesionálních členů, kteří jsou schopni během jednoho Sprintu vytvořit přírůstek produktu. Každý vývojový tým je autonomní, sám se spravuje, kolektivně rozhoduje, jeho práci (přeměnu Product backlog v přírůstek produktu) nikdo jiný neorganizuje. Vyvíjí a testuje produkt, předkládá zlepšovací návrhy, plánuje Sprinty, prezentuje výsledky své práce Vlastníkovi produktu. V rámci jednoho Sprintu se tým plně věnuje pouze zadané práci a jeho složení se nemění Artefakty Artefakty označují entity, které ve Scrumu vznikají, mění se nebo se používají a které jsou užitečné pro zajištění transparentnosti a kontroly. Patří k nim Product backlog, Sprint backlog a přírůstek. Product backlog Jedná se o seznam všech vlastností, funkcí, požadavků včetně jejich průběžné aktualizace, rozšíření, technických zlepšení, oprav a dalších prací, které budou vyžadované a vhodné pro následujícího vývoj produktu. Seznam má být dostatečně detailní, pohotový, dynamický. Položky backlogu jsou zaznamenány ve formě uživatelských příběhů (user stories) a mají stanovenou prioritu, popis a odhad. Jsou rozdělené tak, aby každá položka mohla být dokončena během jednoho Sprintu. Priorita položek v seznamu se odvíjí od přínosu, míry rizika a naléhavosti zpracování. Sprint backlog Definuje práci vývojového týmu, která je nutná pro vytvoření přírůstku a pro splnění Sprintu a která přinese uživateli očekávanou hodnotu. Je velmi detailně rozpracovaným souborem položek vybraných z Product backlogu, které mají být v průběhu Sprintu zpracovány. Změny ve Sprint backlogu provádí pouze vývojový tým, který denně položky sleduje, aktualizuje a jejich seznam upravuje podle probíhajícího vývoje. Sprint backlog pomáhá vývojovému týmu orientovat se v úkolech a aktualizovat odhad práce, kterou má během iterace vykonat. Přírůstek Je to součet všech položek z Product backlogu, které byly dokončeny v průběhu minulých Sprintů a v současném Sprintu. Po dokončení musí být použitelný pro nasazení a také musí být Scrum týmem odsouhlasený jako hotovo. Definici hotového přírůstku 15

22 si generuje každý tým individuálně, aby posoudil, zda je práce ve Sprintu dokončena a splněna v odpovídající kvalitě. Přírůstky se doplňují, testují a sleduje se jejich kompatibilita Činnosti ve Scrumu Scrum je založený na dodržování předepsaných činností. Je tím zajištěna transparentnost procesů a jejich kontrola, sledování nákladů a je umožněna adaptace na změny. Scrumem předepsané činnosti mají základ v pravidelnosti a v dodržování pro ně stanovených časových limitů. Nedochází tak k prodlevám a ztrátám času v průběhu plánování. Sprint Označuje iteraci ve Scrumu. Je to časově limitované období, jehož výstupem je přírůstek produktu. Všechny Sprinty by měly trvat stejnou dobu. Sprinty mají stanovený začátek i konec a vzájemně na sebe navazují, nový Sprint vzniká hned po dokončení předcházejícího. Každý Sprint se skládá z Plánovací schůzky, Denních schůzek, vlastních vývojových prací, Vyhodnocení sprintu a Retrospektivy. Obsahem Sprintu je návrh cílového produktu, plán k realizaci cíle, dále samotná práce a výsledný produkt. Během Sprintu nelze provádět změny ovlivňující cíl Sprintu. V situaci, kdy tým časově nezvládá práci, konzultuje Vlastníka produktu, zda a které položky Product backlogu mohou být odstraněny ze současného Sprintu. Naopak pokud je tým schopný zpracovat větší objem práce, Sprint se doplní o nové položky z backlogu. Plánovací schůzka Na plánování činností v průběhu Sprintu se podílí celý Scrum tým. Plánovací schůzka je časově limitovaná záležitost, na které se ujedná, jaký přírůstek ve Sprintu vznikne a jaká práce se vykoná pro jeho vytvoření. Denní schůzka Je pravidelná každodenní schůzka vývojového týmu, na které tým vyjedná plán na dalších 24 hodin. Kontroluje na ni práci vykonanou od poslední Denní schůzky a odhadne a naplánuje práci pro následující den. 16

23 Vyhodnocení sprintu Jedná se o neformální schůzku Scrum týmu s ostatními stakeholdery, jejímž cílem je přezkoumat přírůstek a v případě potřeby upravit Product backlog. Retrospektiva sprintu Je příležitostí ke zpětné kontrole práce Scrum týmu. Pomáhá naplánovat kroky, které pomohou zlepšit činnost týmu v následující iteraci. Všímá si použitých procesů, nástrojů, mezilidských vztahů. Další informace jsou dostupné z [21] nebo [22]. 3.4 Rational Unified Process Za počátek metodiky je možné považovat Ericssonův model z roku 1967, který rozděluje složité systémy z pohledu vzájemné komunikace do menších propojených bloků. Model byl postupně upravován a rozšiřován tím způsobem, že byl iterativní vývoj uspořádán do po sobě jdoucích fází a výsledkem těchto inovací byla metodika Rational Objectory Process, která byla v roce 1998 přejmenována na Rational Unified Process [20]. K vyjádření této metodiky byl použitý jazyk UML. Metodika je procesním rámcem pro vytvoření vhodné kombinace modelů a procesů v konkrétním projektu. Je variabilní, zobecňuje řadu procesů, lze ji přizpůsobit jakémukoliv projektu a konfigurovat na míru potřebám konkrétní organizace. Metodika vychází z praxí ověřených postupů a zkušeností, které vedou k úspěchu projektu. Opírá se o šest nejlepších praktik [24]: Iterativní vývoj softwaru (Develop software iteratively), který umožňuje předvídat rizika v každé fázi životního cyklu a reagovat na ně, usnadňuje správu změn, spolupráci se zákazníkem, testování aj. Správa požadavků (Manage requirements), která znamená udržovat kontakt se zákazníkem, získávat, organizovat a dokumentovat požadavky a dynamicky reagovat na jejich změny tak, jak k tomu dochází v průběhu vývoje. Použití komponentové architektury (Use component-based architectures), kdy komponenty jsou netriviální části systému, zajišťují určitou funkcionalitu, jsou nezávislé a nahraditelné jinými komponentami. Opakované použití hotové komponenty zvyšuje efektivitu vývoje a úsporu zdrojů. 17

24 Vizuální modelování softwaru (Visually model software), které zjednodušuje pohled na systém, umožňuje lépe systému porozumět: graficky znázornit procesy, závislosti, strukturu, chování komponent, zlepšit komunikaci. Kontrolování kvality softwaru (Continously verify software quality), které předpokládá průběžné hodnocení požadavků na kvalitu, jakými jsou např. funkcionalita, spolehlivost a výkon v rámci každé iterace Řízení změn (Control changes to software), které nabízí postup změnového řízení pro optimální vývoj. Zajišťuje, aby změny byly přijatelné, aby proběhlo jejich otestování a v případě problému byla možnost vrátit se k původní verzi softwaru Na RUP lze nahlížet ze dvou pohledů [24]: dynamického, kterým se rozumí životní cyklus projektu složený z cyklů, fází, iterací a milníků a statického, který člení metodiku na role, aktivity, artefakty a pracovní procesy Dynamický pohled Životní cyklus RUP se skládá ze čtyř na sebe navazujících fází, kdy každá fáze je zakončena milníkem, tj. byly splněny cíle, které umožnily zahájit další fázi. Ke čtyřem fázím patří [24] fáze Zahájení (Inception), Rozpracování (Elaboration), Konstrukce (Construction) a Nasazení (Transition). Součástí každé fáze jsou iterace, počet iterací závisí na velikosti projektu. Fáze vytvářejí vývojový cyklus, při jehož ukončení vznikne první verze softwaru. Pokud není vývoj produktu ukončený, může vznikat několik generací softwaru. Čtyřgenerační cyklus je zobrazený na obrázku níže. Obrázek 6: Životní cyklus produktu v metodice RUP (Autor dle [24]) Ve fázi zahájení je vytvořen obchodní případ a vymezen rozsah projektu. Musí být podchyceny všechny externí entity, se kterými systém komunikuje, identifikovány případy 18

25 užití, vyčísleny náklady, odhadnuta rizika. Výstupem této fáze je vize projektu, klíčových vlastností a rozsah požadavků, počáteční model případů užití, počáteční obchodní případ, projektový plán a odhad rizik. Ve fázi rozpracování je během jedné nebo více iterací vytvořený spustitelný prototyp. Jedná se o kritickou fázi, která je jako základ v dalších fázích rozpracována do definitivního a plnohodnotného systému. Výstupem fáze jsou: spustitelný architektonický prototyp, popis architektury softwaru, use case model, revidovaný seznam rizik a obchodní případ, plán projektu včetně iterací aj. Cílem konstrukční fáze je vyvinou konečnou verzi systému a otestovat ji. Důležité je zachovat integritu systému a rovnováhu mezi náklady, časovým harmonogramem a kvalitou systému. Výstupem fáze je produkt, který je provozně způsobilý, otestovaný a připravený k předání zákazníkovi společně s manuálem. Cílem fáze nasazení je předat produkt uživatelům. Současný produkt je pouze betaverzí, kterou je třeba ještě vyladit a dále testovat, přizpůsobit software pracovišti uživatele, školit uživatele a poskytovat podporu a údržbu produktu Statický pohled Metodika popisuje proces pomocí čtyř základních elementů, které odpovídají na následující otázky: Role Kdo?, Aktivity Jak?, Artefakty Co?, Pracovní procesy Kdy? [24]. Role určují chování a odpovědnosti jedinců nebo týmu uvnitř projektu, přitom jednotlivec může zastávat různé role. Aktivitou je jednotka práce nebo činnost, která je přidělena určité roli a která má jasný účel, výstup aktivity je označovaný jako artefakt. Ten představuje část informace, která je vytvořena, modifikována a používána v procesu vývoje. Artefakty jsou vstupem i výstupem aktivit. Pracovní procesy jsou sekvence aktivit, které vykonávají jednotlivé role, zachycují interakce mezi rolemi a vytvářejí pozorovatelný výsledek. Nejvýznamnější pracovní procesy se společnou oblastí zájmu se označují jako disciplíny, kterých je devět: Obchodní modelování (Business Modeling), Požadavky (Requirements), Analýza a návrh (Analysis and Design), Implementace (Implementation), Testování (Test), Nasazení (Deployment), Konfigurační a změnový management (Configuration and Change Management), Projektový management (Project Management), Správa prostředí (Environment). 19

26 Další informace jsou dostupné z [24] nebo [20]. Při srovnání metodik je RUP objektově orientovanou iterativní metodikou, dodávanou jako sada HTML stránek. Tato robustní, rozsáhlá a propracovaná metodika, provázaná s UML notací, vychází z potřeb praxe. Detailně instruuje celý tým, jak má postupovat v průběhu realizace projektu. Pro potřeby řízení a vývoje obsahuje množství kvalitních a podrobných návodů včetně podpůrných prostředků. Metodiku lze přizpůsobit celé řadě projektů, díky rozsáhlosti však vyhovuje spíše realizaci větších projektů. Její šíře a mohutnost se může stát nevýhodnou, protože její detailnost, kdy popisuje desítky rolí, aktivit a artefaktů, nutí tým metodiku podrobně prozkoumávat a předepsaný postup se tak stává časovou zátěží. Scrum je adaptabilní metodika využívající periodicky se opakující činnosti, často se používá v kombinaci s dalšími metodikami. Metodika je jednoduchá, schopná rychle reagovat na změny a přizpůsobovat se novým požadavkům, stejně jako rychle odstraňovat chyby a šetřit tak náklady. Vývoj projektu lze graficky monitorovat a kontrolovat a eventuálně neúspěšný projekt zavčas zastavit. Metodika vyžaduje sehraný, motivovaný a flexibilní tým, který je schopný se samostatně organizovat. Předpokládá odlišný způsob zapojení zákazníka do projektu, když očekává pravidelné vzájemné konzultace a dobrou spolupráci. Obrázek 7: Srovnání metodik z pohledu životního cyklu SW [25] Jinými používanými dokumenty, které obsahují obecná doporučení, požadavky, pokyny a návody i specifikace, které byly vytvořeny na základě best practices a slouží jako norma pro srovnávání a hodnocení, jsou standardy. Oproti metodikám budování ICT nacházejí širší uplatnění; lze je aplikovat na projekty různých odvětví, nejen při vývoji softwaru. Svou strukturou se podobají tradičním metodikám budování ICT. 20

27 4 Standardy projektového řízení Standardy v projektovém řízení jsou souhrnem nejlepších poznatků a zkušeností, které získali během svého profesního života zkušení manažeři působící v dané oblasti. Standardy však nejsou technickým návodem, jak řídit projekt, ale zohledňují řadu proměnných, které jsou součástí projektového řízení a mají být inspirací pro vedoucí pracovníky pří řízení projektů. Jejich přínos spočívá v usnadnění a zefektivnění komunikace a spolupráce projektových týmů. Standard popisuje nejlepší praktiky vztahující se k tomu, co by se mělo v rámci řízení projektu udělat. Metodika pak popisuje, jak by to mělo být uděláno [5]. K nejznámějším standardům patří A Guide to the Project Management Body of Knowledge (PMBOK), PRojects IN Controlled Environments (PRINCE2) a IPMA Competence Baseline (ICB) a normy ISO a ISO Ke dvěma základním orientacím standardů patří jejich zaměření kompetenční a procesní. 1. Cílem kompetenčně pojatého standardu je definovat kompetence manažerů a členů týmů při řízení projektů, tj. zaměřit se na jejich schopnosti a dovednosti, zda je umí uplatnit v praxi a na jejich osobní vlastnosti. Standard nepředepisuje procesy, ale doporučuje účastníkům projektu určité postupy při řešení konkrétních situacích. Neomezuje je, ale ponechává jim prostor pro jejich tvořivý přístup. Příkladem takového standardu je IPMA Competence Baseline [3], která vychází z tzv. oka kompetencí, ve kterém jsou integrované všechny složky projektového řízení důležité pro projektového manažera. 2. Procesní přístup řízení projektů umožňuje řídit projekt jako proces a aplikovat na něj veškerá pravidla obecně platná pro procesy. Norma ISO 10006:2003 definuje proces jako soubor vzájemně propojených zdrojů a činností, které přeměňují vstupy na výstupy [26]. Projekt by měla provázet prokazatelná dokumentace, všechny zainteresované strany by o něm měly mít znalosti a informace, procesy by měly být efektivně vyhodnocované, na projekt by měly být aplikované zásady systému managementu jakosti [6]. Příkladem procesního pojetí standardů projektového řízení jsou PMBOK a PRINCE2. 21

28 4.1 Standard PMBOK Vznikl v roce 1987 podle standardů US Army. Standard je využitelný nejen v projektech z oblasti IT a softwaru, ale i v průmyslu, stavebnictví a jiných sférách. Vytvořilo ho největší profesní sdružení projektových manažerů na světě Project Management Institute [27]. Představuje procesní rámec, který definuje projektové řízení z různých hledisek, přitom vychází z osvědčených postupů dlouhodobě používaných při úspěšném řízení projektu. Těžiště standardu spočívá v definování procesu jako souboru vzájemně souvisejících činností, jejichž cílem je vykonat stanovenou práci, vytvořit specifikovaný produkt, službu nebo výsledek [1]. Každý proces je definován vstupy, nástroji a technikami a výstupy. Do standardu je zahrnuto 47 procesů rozdělených do 5 procesních skupin a 10 znalostních oblastí. Každý proces spadá jak do procesní skupiny, tak do určité znalostní oblasti. V úvodu standardu [1] je definován projekt, vymezeno projektové řízení, stanovena role projektového manažera, vysvětleny vztahy mezi projektem, programem a portfoliem. Druhá kapitola popisuje životní cyklus projektu a vliv organizace na projekt. Zabývá se kulturou, organizační strukturou, způsobem komunikace, vztahy se zainteresovanými osobami, popisuje složení projektového týmu a fáze projektů. Třetí kapitola se zabývá procesními skupinami, ke kterým patří: Zahájení (Initiating Process Group), Plánování (Planning Process Group), Realizace (Executing Process Group), Monitorování a kontroly (Monitoring and Controlling Process Group) a Uzavření (Closing Process Group). Zbývající kapitoly se věnují znalostním oblastem: Integrovanému řízení projektu (Project Integration Management), Řízení rozsahu projektu (Project Scope Management), Řízení času projektu (Project Time Management), Řízení nákladů projektu (Project Cost Management), Řízení kvality projektu (Project Quality Management), Řízení lidských zdrojů projektu (Project Human Resource Management), Řízení komunikace projektu (Project Communications Management), Řízení rizik projektu (Project Risk Management), Řízení dodávek projektu (Project Procurement Management), Řízení zainteresovaných stran v projektu (Project Stakeholder Management) Procesní skupiny V průběhu životního cyklu projektu současně probíhá, spolupracuje a na sebe navazuje celá řada vzájemně propojených a souvisejících procesů, které se mohou opakovat. Tyto aktivity jsou logicky seskupené do procesních skupin podle jejich povahy, vývojového stupně projektu a způsobu ovlivňování celkového procesního toku. Jednotlivé procesní 22

29 skupiny se vzájemně ovlivňují, překrývají se, mohou probíhat opakovaně nebo souběžně, nemusí na sebe navazovat a všechny se mohou odehrát během jedné fáze životního cyklu projektu. Procesní skupiny se tak neshodují s fázemi projektu [28]. Procesy obsažené v Zahajovací procesní skupině iniciují nový projekt nebo novou fázi stávajícího projektu. Jsou určeny ke schválení a povolení projektu. Procesy v Plánovací procesní skupině navazují na výstupy předchozí fáze a detailně plánují činnosti zasahující do všech znalostních oblastí. Stanovují rozsah a cíle projektu, definují činnosti potřebné k dosažení cíle včetně vypracování projektových plánů. Do Realizační procesní skupiny patří procesy, které je nutné vykonat; patří k nim práce s lidskými zdroji, koordinace zdrojů, plnění očekávání zainteresovaných stran a realizace činností v souladu s projektovým plánem. Činnosti cílené na ověřování reálného postupu projektu ve srovnání s jeho plánem jsou obsažené v procesní skupině Monitorování a kontroly. Používané procesy jsou potřebné ke sledování probíhajících činností a k vyhodnocování pokroku projektu a jeho dalšího směrování. Uzavření je poslední procesní skupinou, kam jsou zařazeny procesy nutné pro dokončení všech běžících procesů v projektu nebo jeho fází. Jejich účelem je zhodnotit projekt nebo fázi, zaznamenat dopady změn, zpracovat výsledky a získané zkušenosti, získat akceptaci projektu zákazníkem, archivovat dokumentaci projektu. Obrázek 8: Procesní skupiny PMBOK s hlavními procesy (Autor dle [1]) 23

30 4.1.2 Znalostní oblasti Znalostní oblast představuje soubor konceptů, pojmů a aktivit, které náleží určité oblasti, oboru nebo specializaci [1]. V každé znalostní oblasti se používají nástroje a techniky projektového řízení, specifické pro danou kategorii. Znalostní oblasti obsahují klíčové kompetence projektového manažera, které rozhodují o úspěchu projektu. Integrované řízení projektu spočívá v koordinaci ostatních znalostních oblastí v životním cyklu projektu a zajišťuje, že se všechny elementy projektu ve vhodnou dobu propojí a projekt bude úspěšně dokončený. Řízení rozsahu projektu zahrnuje procesy, které definují a kontrolují, jaké práce budou obsaženy v projektu, tj. které jsou potřebné k jeho úspěšnému dokončení. Řízení času projektu obsahuje procesy nutné k tomu, aby byl projekt včas dokončený. Řízení nákladů projektu zajišťuje, aby byl projekt dokončený v mezích schváleného rozpočtu. Řízení kvality projektu sleduje, zda projekt splňuje požadavky v definované kvalitě. Řízení lidských zdrojů projektu umožňuje co nejefektivněji využívat lidský kapitál zainteresovaný na projektu. Řízení komunikace projektu má zajistit včasné plánování, sběr, distribuci, dokumentování, archivování, řízení, kontrolu a monitorování informací v projektu. Řízení rizik projektu je cílené na snížení dopadu nežádoucích vlivů a naopak na využití působení pozitivních vlivů. Řízení dodávek projektu znamená pořizování zboží, služeb nebo výsledků od externích zdrojů. Řízení zainteresovaných stran v projektu identifikuje osoby, skupiny nebo organizace, které mohou projekt ovlivnit nebo mohou být ovlivněny projektem, analyzuje jejich požadavky a vytváří pro ně strategii řízení. Další informace jsou dostupné z [1]. 24

31 4.2 Standard PRINCE2 PRINCE2 je považován za univerzální standard založený na procesním pojetí projektového řízení, který může být použitý při řízení projektu jakéhokoliv typu a velikosti [2]. Původní metodika britské společnosti Simpact Systems Ltd. byla postupně upravována a od roku 1989 se používá jako doporučený standard pro realizaci vládních projektů v oblasti IT. Jeho poslední revize proběhla v roce Standard se člení do 4 elementů, k nimž patří: Sedm principů, Sedm témat, Sedm procesů a Přizpůsobení PRINCE2 prostředí projektu Principy Všechny principy mají společnou charakteristiku: Jsou univerzální, lze je aplikovat při každém projektu, jsou samovalidovatelné, byly ověřeny opakovaným používáním na projektech. Pokud není aplikováno všech sedm principů, nejedná se o PRINCE2 projekt [2]. Neustálé zdůvodňování opodstatněnosti projektu dokládá jeho odůvodnění a podložení Obchodním případem (Business Case). Ten musí být zdokumentovaný a schválený, řídí se podle něj rozhodování a zajišťuje, že je projekt přínosný. Učení se ze zkušeností předpokládá, že všichni zapojení do projektu budou čerpat ze zkušeností a znalostí jak na počátku projektu, tak v jeho průběhu a při ukončení projektu. Definované role a odpovědnosti je nutné stanovit pro úspěšný průběh projektu. Každý člen týmu musí znát své odpovědnosti a musí být seznámen také s odpovědnostmi ostatních. Mezi členy týmu musí probíhat efektivní komunikace. Řízení po etapách rozděluje projekt na etapy, jejichž počet závisí na velikosti a komplexnosti projektu a na souvisejících rizicích. Podrobně je naplánovaná pouze nejbližší etapa, která se po dokončení spolu s dalšími aktualizovanými dokumenty schvaluje. Řízení na základě výjimky definuje několik úrovní rozhodování v projektu, přitom je důležité, aby rozhodnutí byla činěna na odpovídajícím stupni řízení. 25

32 Zaměření standardu na produkty a jejich identifikaci vychází z toho, že úspěšné projekty jsou zaměřené na výsledek, nikoli na průběh projektu. Takto standardem definované produkty potom určují rozsah projektu a vychází z nich plánování a kontrola průběhu projektu. Přizpůsobení PRINCE2 prostředí a okolí projektu umožňuje flexibilita standardu. Podmínkou je, aby úprava vyhovovala v oblasti prostředí, velikosti, komplexity a rizika a cílem je zajistit, aby byl projekt vedený vzhledem k jeho rozsahu, složitosti a významu Témata Témata popisují projekt z různých hledisek, vzájemně spolu souvisí a jsou integrována do projektu. Mají společnou strukturu, a to cíl, definici, přístup a odpovědnosti. Téma Popis Odpověď na otázku Obchodní případ (Business Case) Organizace (Organization) Kvalita (Quality) Plány (Plans) Rizika (Risk) Změna (Change) Projekt je založený na nápadu, který by měl být pro organizaci přínosný. Téma rozpracovává, jakým způsobem je tento nápad realizován a prověřuje, zda je projekt i nadále žádoucí, životaschopný a jeho cíl dosažitelný. Po dobu trvání projektu jsou definovány role, odpovědnosti a vztahy mezi zapojenými pracovníky. Role mohou být podle velikosti projektu kombinovatelné, sdílené nebo přiděleny jednotlivci. Představuje způsob vzniku produktu a hlediska pro kontrolu jeho kvality. Stanovuje normy a metody kontroly kvality, které mají být použitelné a způsob jejich dodržování. Plánování projektu je prováděno pro nastavení kontroly komunikace a prováděných prací se zaměřením na produkty. Definuje kdo, kdy, kde a jak dodá produkty. Probíhá na třech úrovních: Plán projektu, Plán etapy a Plán týmu. Účelem je identifikovat, vyhodnotit a kontrolovat nejistotu. Na začátku projektu identifikovat rizika, provést jejich hodnocení, stanovit vlastníky rizik, způsob ošetření a monitorování rizik. Uvádí postupy jak posuzovat a reagovat na události s možným dopadem na plány projektu a produkty. Řízení změny: postupy, jak změny identifikovat a řešit. Řízení konfigurací: identifikovat, sledovat a ochraňovat produkty projektu. Proč? Kdo? Co? Jak? Kolik? Kdy? Co když? Jaký je dopad? 26

33 Progres (Progress) Soubor řídících prvků, které umožní kvalifikovaně posoudit vývoj projektu a určí jeho další směr, systém pro schvalování plánů a pro řešení odchylek od plánu. Tabulka 3: PRINCE2 témata (Autor dle [29]) Kde jsme? Kam směřujeme? Máme pokračovat? Procesy Procesy chronologicky popisují průběh projektu. Obsahují jednotlivé kroky řízení projektu, tedy řízený začátek, realizaci a ukončení [2]. Procesy jsou složeny z aktivit, které mohou probíhat paralelně nebo na sebe navazovat. Obsahem aktivit jsou doporučené činnosti, jejichž pomocí lze dosáhnout kýžených výsledků. Projekt PRINCE2 probíhá v několika na sebe navazujících etapách. V předprojektové etapě se zpracovává myšlenka či potřeba a ověřuje a dokumentuje se užitečnost a proveditelnost projektu. V navazující iniciační etapě se projekt detailně plánuje, získávají se zdroje k jeho financování a definují se kontrolní mechanismy. V realizační etapě probíhají vlastní práce na produktu. Ve fázi ukončení jsou produkty dodány, zhodnoceny výsledky, proběhlé události a dosažené cíle a jsou posouzené skutečné termíny a náklady vůči plánovaným. Obrázek 9: PRINCE2 procesy (Autor dle [2]) Zahájení projektu předchází projektu, má stanovit cíle, popsat projekt a rozhodnout o přístupu, který se použije při realizaci, odsouhlasit kvalitu připraveného plánu, definovat role a odpovědnosti. 27

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

Metodiky a normy. Matěj Vala. Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Matěj Vala, 2011

Metodiky a normy. Matěj Vala. Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Matěj Vala, 2011 Metodiky a normy Matěj Vala Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Matěj Vala, 2011 Projektové řízení LS 2010/11, Předn. 2 Evropský sociální

Více

kapitola 2 předprojektová fáze 31

kapitola 2 předprojektová fáze 31 OBSAH 6 projektové řízení Předmluva 3 Kapitola 1 Základní pojmy a východiska 13 1.1 Úvod do řízení projektů 14 1.1.1 Co je to projektové řízení 14 1.2 Základní pojmy projektového řízení 17 1.2.1 Projekt

Více

Manažer programů a komplexních projektů (kód: 63-008-T) Manažer programů a komplexních projektů

Manažer programů a komplexních projektů (kód: 63-008-T) Manažer programů a komplexních projektů Manažer programů a komplexních projektů (kód: 63-008-T) Autorizující orgán: Ministerstvo pro místní rozvoj Skupina oborů: Ekonomika a administrativa (kód: 63) Povolání: Manažer programů a komplexních projektů

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Novinky v projektovém řízení

Novinky v projektovém řízení Novinky v projektovém řízení Jiří Krátký Struktura prezentace - O Společnosti pro projektové řízení - Trendy v projektovém řízení - Nejčastější chyby v projektech - Certifikace projektových manažerů -

Více

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Přednáška č.2 Jan Valdman, Ph.D. jvaldman@dns.cz 8.3.2011 ITIL Information Technology Infrastructure Library ITIL v současnosti zahrnuje: Samotnou knihovnu Oblast vzdělávání a certifikace odborné

Více

1. Stavební management

1. Stavební management 1. Stavební management Klíčová slova: Management, podstata managementu, organizační uspořádání podniku, organizační struktura, rozhodování, osobnost manažera, projektové a procesní řízení. Anotace textu:

Více

Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model

Projekt: Koordinační centrum pro zavádění e-gov v územní veřejné správě. Koncepční dokument pro oblast řízení. Procesní model Koncepční dokument pro oblast řízení a koordinaci e-gov: Procesní model 18. 09. 2013 OBSAH Obsah... 2 Seznam zkratek... 3 Použité pojmy... 4 1 Úvodní informace... 6 2 Procesní model: životní cyklus e-gov...

Více

Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT)

Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT) Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta

Více

PŘEDSTAVENÍ STANDARDŮ PM. Ing. Jan Doležal, Ph.D., PMP, IPMA B

PŘEDSTAVENÍ STANDARDŮ PM. Ing. Jan Doležal, Ph.D., PMP, IPMA B PŘEDSTAVENÍ STANDARDŮ PM Ing. Jan Doležal, Ph.D., PMP, IPMA B Ing. Jan Doležal, Ph.D. 2 Ředitel a jednatel PM Consulting s.r.o. IPMA level B (senior projektový manažer) PMI Project Management Professional

Více

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů Zuzana Šochová 30.10.2008 1 Metody řízení projektů Týmová spolupráce Agilní metody Scrum proces Backlog úloh a odhady Jak plánovat Tým a zákazník 2 Executive support User involvement Experienced project

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 21. Otázka : Softwarový process. Jeho definice, modely a vyspělostní úrovně. Standardizovaný přístup pomocí RUP (Rational Unified Process). Obsah :

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

InternetovéTechnologie

InternetovéTechnologie 8 InternetovéTechnologie webdesign, mobile first Ing. Michal Radecký, Ph.D. www.cs.vsb.cz/radecky Webové stránky a aplikace - Webové stránky - množina vzájemně propojených stránek, které obsahují informace

Více

Řízení projektového cyklu. představení oboru

Řízení projektového cyklu. představení oboru ODBORNÉ VZDĚLÁVÁNÍ ÚŘEDNÍKŮ PRO VÝKON STÁTNÍ SPRÁVY OCHRANY OVZDUŠÍ V ČESKÉ REPUBLICE Řízení projektového cyklu (PCM - project cycle management) představení oboru Co je projekt? 2 Projekt Co je možno vlastně

Více

Úvod do projektového řízení

Úvod do projektového řízení Projektové řízení (BI-PRR) Úvod do projektového řízení Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Ing. Martin Půlpitel, 2011 Projektové řízení

Více

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt Projektový management Lekce: 8 Projektový management Doc. Ing. Alois Kutscherauer, CSc. Projektový management je typ managementu uplatňovaného k zabezpečení realizace jedinečných, neopakovatelných, časově

Více

D5 Životní cyklus projektu

D5 Životní cyklus projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D5 Životní cyklus projektu Toto téma obsahuje informace o vhodné posloupnosti kroků přípravy a realizace

Více

D1 Trvalá organizace

D1 Trvalá organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D1 Trvalá organizace Toto téma obsahuje informace o trvalé organizaci, jejích základních principech a prostředí.

Více

D9 Realizace projektu

D9 Realizace projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D9 Realizace projektu Toto téma obsahuje informace o správném postupu realizace projektu tak, aby byl respektován

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist)

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist) SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist) Oblast 1. STRATEGICKÉ PLÁNOVÁNÍ Jsou identifikovány procesy v takovém rozsahu, aby byly dostačující pro zajištění systému managementu jakosti v oblasti vzdělávání?

Více

Manažerská ekonomika

Manažerská ekonomika PODNIKOVÝ MANAGEMENT (zkouška č. 12) Cíl předmětu Získat znalosti zákonitostí úspěšného řízení organizace a přehled o současné teorii a praxi managementu. Seznámit se s moderními manažerskými metodami

Více

SYLABUS MODUL BUSINESS MODELOVÁNÍ. Doc. RNDr. Vladimír Krajčík, Ph.D.

SYLABUS MODUL BUSINESS MODELOVÁNÍ. Doc. RNDr. Vladimír Krajčík, Ph.D. SYLABUS MODUL BUSINESS MODELOVÁNÍ Doc. RNDr. Vladimír Krajčík, Ph.D. Ostrava 20 : Business modelování Autoři: Doc. RNDr. Vladimír Krajčík, Ph.D. Vydání: první, 20 Počet stran: Tisk: Vysoká škola podnikání,

Více

Popis obsahu a struktury programu

Popis obsahu a struktury programu Popis obsahu a struktury programu (Příloha k Žádosti o akreditaci vzdělávacího programu u Společnosti pro projektové řízení, o. s.) 1 Vzdělávací subjekt: HM PARTNERS s.r.o. Název programu: Projektové řízení

Více

PMBOK Guide Fifth edition novinky, posuny

PMBOK Guide Fifth edition novinky, posuny PMBOK Guide Fifth edition novinky, posuny Tomáš Klein, PMP Shine Consulting, s.r.o. Obsah Změny v PMBOK Guide 5ed. od 4ed. a jejich interpretace s ISO 21500 Dopady do PMI certifikací Změny v PMBOK Guide

Více

Abychom definovali dimenze kompetencí, položili jsme si otázku: S kým/čím vstupujete do vzájemné interakce?

Abychom definovali dimenze kompetencí, položili jsme si otázku: S kým/čím vstupujete do vzájemné interakce? Profily kompetencí Úvodní situace před testováním E-learningový modul obsahuje šest interaktivních situací orientovaných na kompetence, které mají svou roli v maloobchodní společnosti. Všechny maloobchodní

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily?

Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? Úvod do SCRUM!! Co je to SCRUM! FRAMEWORK vs METODIKA Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? agilemanifesto.org www.mountaingoatsoftware.com/scrum Z čeho to je...! Vychází

Více

Projektové řízení. 1. část. http://knihy.abz.cz/obchod/projektovy-management http://www.method123.com/free-projectmanagement-book.

Projektové řízení. 1. část. http://knihy.abz.cz/obchod/projektovy-management http://www.method123.com/free-projectmanagement-book. Projektové řízení 1. část http://knihy.abz.cz/obchod/projektovy-management http://www.method123.com/free-projectmanagement-book.php http://www.amazon.com/project-management- Books/lm/R2JSEO2N6WOUEJ Definice

Více

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz

Informační systémy. Jaroslav Žáček jaroslav.zacek@osu.cz Informační systémy Jaroslav Žáček jaroslav.zacek@osu.cz Úvod - co možná umíte z předmětu SWENG Rozdělení IT Architektura IS Klíčový prvek řízení IS z něj vycházejí detailní analytické i plánovací charakteristiky

Více

Kvalita procesu vývoje (SW) Jaroslav Žáček jaroslav.zacek@osu.cz

Kvalita procesu vývoje (SW) Jaroslav Žáček jaroslav.zacek@osu.cz Kvalita procesu vývoje (SW) Jaroslav Žáček jaroslav.zacek@osu.cz Vývoj software a jeho kvalita Samotný vývoj je rozsáhlá a složitá disciplína. Většina SW projektů (v průměru 60 %) je podhodnocena či zpožděna.

Více

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D. Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační

Více

Národní soustava povolání

Národní soustava povolání OP RLZ, Opatření 3.3 Rozvoj dalšího profesního vzdělávání Systémový projekt Národní soustava povolání Ing. Michaela NAVRÁTILOVÁ Ministerstvo práce a sociálních věcíčr, Odbor 35, Odbor implementace programů

Více

Standard ISVS 005/02.01 pro náležitosti životního cyklu informačního systému

Standard ISVS 005/02.01 pro náležitosti životního cyklu informačního systému Úřad pro veřejné informační systémy Havelkova 22 130 00 Praha 3 Standard ISVS 005/02.01 pro náležitosti životního cyklu informačního systému Verze. modifikace standardu ISVS Datum schválení verze / modifikace

Více

D8 Plánování projektu

D8 Plánování projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D8 Plánování projektu Toto téma obsahuje informace o správném postupu plánování projektu tak, aby byl respektován

Více

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací Monitorovací indikátor: 06.43.10 Počet nově vytvořených/inovovaných produktů Akce: Přednáška, KA 5 Číslo přednášky: 30 Téma: INFORMAČNÍ SYSTÉMY A ARCHITEKTURA IT V PODNIKU Lektor: Ing. Michal Beránek Třída/y:

Více

PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST

PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST Ing. Jan Doležal Agenda 2 Projektové řízení a projektová výuka Jaké jsou požadavky praxe? Význam a možnosti certifikace

Více

PROJEKTOVÝ MANAGEMENT V CESTOVNÍM RUCHU

PROJEKTOVÝ MANAGEMENT V CESTOVNÍM RUCHU Udržitelný rozvoj venkova a cestovní ruch PROJEKTOVÝ MANAGEMENT V CESTOVNÍM RUCHU Jiří Vaníček Vysoká škola polytechnická Jihlava Strategie pro CR v EU a v ČR Priority rozvoje CR v ČR: rozvoj regionální

Více

Projektové řízení (Projektový cyklus)

Projektové řízení (Projektový cyklus) Projektové řízení (Projektový cyklus) Vzdělávací program v rámci projektu Rekonstrukce učitelů - posílení profesní a kompetenční připravenosti učitelů (CZ.1.07/1.3.10/02.0052) 1 Projektový cyklus Metodické

Více

Profil Škola 21 : difuzní model pro integraci moderních technologií

Profil Škola 21 : difuzní model pro integraci moderních technologií Profil Škola 21 : difuzní model pro integraci moderních technologií 1. začínáme 2. máme první zkušenosti 3. nabýváme sebejistoty 4. jsme příkladem ostatním řízení a plánování vize školy ICT plán Vize pouze

Více

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko Obsah Kvalita SW, jak zajistit kvalitu SW a jak ji ověřit Zabezpečení kvality, techniky řízení kvality SW. Potřeba kultivovat kvalitu, Cena za jakost Procesy pro řízení kvality, harmonogram řízení kvality

Více

Vstupní a výstupní hodnocení v rámci projektu EU peníze středním školám

Vstupní a výstupní hodnocení v rámci projektu EU peníze středním školám Vstupní a výstupní hodnocení v rámci projektu EU peníze středním školám Škola: Gymnázium, Krnov, p.o. Indikátor Počáteční stav k 1.5.2012 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen

Více

Analýza a vytváření pracovních míst

Analýza a vytváření pracovních míst Analýza a vytváření pracovních míst Definice pracovního místa a role Pracovní místo Analýza role Roli lze tedy charakterizovat výrazy vztahujícími se k chování existují-li očekávání, pak roli představuje

Více

Přehled technických norem z oblasti spolehlivosti

Přehled technických norem z oblasti spolehlivosti Příloha č. 1: Přehled technických norem z oblasti spolehlivosti NÁZVOSLOVNÉ NORMY SPOLEHLIVOSTI IDENTIFIKACE NÁZEV Stručná charakteristika ČSN IEC 50(191): 1993 ČSN IEC 60050-191/ Změna A1:2003 ČSN IEC

Více

Životní cyklus vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Životní cyklus vývoje SW. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Životní cyklus vývoje SW Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Proč potřebujeme definovat proces vývoje Při vývoji SW nemáme tvrdá fakta, jako v jiných vědách (fyzika, chemie,

Více

Management IS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1

Management IS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1 Management IS Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1 Učitelé Přednášející: Cvičící: Doc.Ing.Miloš Koch,CSc. Ing.Aleš Klusák Kontakt: koch@fbm.vutbr.cz 22/ 2 Literatura Skripta: Koch,M. Dovrtěl,J.:

Více

Role lidí při realizaci strategie Cíl kapitoly. Základní pojmy. Proces integrace služeb ICT

Role lidí při realizaci strategie Cíl kapitoly. Základní pojmy. Proces integrace služeb ICT Role lidí při realizaci strategie Cíl kapitoly Poskytnout informace o rolích jednotlivých osob ve škole při procesu integrace ICT do života školy. Kromě základního rozdělení rolí budou uvedeny konkrétní

Více

BUMP: integrovaný přístup k plánování městské mobility

BUMP: integrovaný přístup k plánování městské mobility BUMP: integrovaný přístup k plánování městské mobility Kurz BUMP: integrovaný přístup k plánování městské mobility je pořádaný v rámci projektu BUMP - Boosting Urban Mobility Plans financovaného prostřednictvím

Více

ICT plán. Škola: gyricany - Hodnocení: Vstupní hodnocení. Indikátor Aktuální stav k 22.3.2012 Plánovaný stav k 30.6.2014. 1. řízení a plánování

ICT plán. Škola: gyricany - Hodnocení: Vstupní hodnocení. Indikátor Aktuální stav k 22.3.2012 Plánovaný stav k 30.6.2014. 1. řízení a plánování ICT plán Škola: gyricany - Hodnocení: Vstupní hodnocení Indikátor Aktuální stav k 22.3.2012 Plánovaný stav k 30.6.2014 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen omezená skupina učitelů.

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Řízení projektů v praxi

Řízení projektů v praxi Řízení projektů v praxi Ing.Josef Hajkr, Ph.D.,MBA (IPMA CPM) haj@shine.cz 25.3.2008 (c) SHINE Consulting s.r.o. www.shine.cz 1 Bylo nebylo... Byl jednou jeden podnik a v něm čtyři zaměstnanci, kteří se

Více

Město Vsetín, Městský úřad Vsetín, Svárov 1080, 755 01 Vsetín, IČ0: 00304450. SMĚRNICE číslo QS 85-03 PROJEKTOVÉ ŘÍZENÍ

Město Vsetín, Městský úřad Vsetín, Svárov 1080, 755 01 Vsetín, IČ0: 00304450. SMĚRNICE číslo QS 85-03 PROJEKTOVÉ ŘÍZENÍ Město Vsetín, Městský úřad Vsetín, Svárov 1080, 755 01 Vsetín, IČ0: 00304450 Výtisk č.: 0 Město Vsetín Městský úřad Vsetín SMĚRNICE číslo QS 85-03 Vydání: 1 Účinnost od: 1. 7. 2005 Přepis: Počet stran:

Více

Agilní metodiky vývoje softwaru

Agilní metodiky vývoje softwaru vývoje softwaru : důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka týmovou spolupráci a samoorganizaci

Více

Bakalářský studijní obor hospodářská informatika

Bakalářský studijní obor hospodářská informatika Bakalářský studijní obor hospodářská informatika Předpoklady Struktura studia Přihlášky Poradenství Bakalářský studijní obor hospodářská informatika nabízí fundované vědecké a praktické vzdělání v oblasti

Více

Příloha č.3 Otázka pro hodnocení manažera

Příloha č.3 Otázka pro hodnocení manažera Příloha č.3 Otázka pro hodnocení manažera 1. Sleduje profesní a technický vývoj? 2. Připravuje a dodržuje realistický rozpočet? 3. Zaměřuje se na podstatné informace a neztrácí se v nedůležitých detailech?

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

Projekt Systematickým vzděláváním k rozvoji zaměstnanců a kvalitě řízení Městského úřadu Luhačovice"

Projekt Systematickým vzděláváním k rozvoji zaměstnanců a kvalitě řízení Městského úřadu Luhačovice Projekt Systematickým vzděláváním k rozvoji zaměstnanců a kvalitě řízení Městského úřadu Luhačovice" Registrační číslo: CZ.1.04/4.1.01/69.00060 Zkrácený název projektu: Vzdělávání v MěÚ Luhačovice Datum

Více

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track PROCESY CO ZÍSKÁTE: Jasná pravidla pro provádění činností, uložení know-how Jasně definované zodpovědnosti za celý proces i jednotlivé kroky Zprůhlednění organizace plynoucí z jasně definovaných vstupů,

Více

Příklad I.vrstvy integrované dokumentace

Příklad I.vrstvy integrované dokumentace Příklad I.vrstvy integrované dokumentace...víte co. Víme jak! Jak lze charakterizovat integrovaný systém managementu (ISM)? Integrovaný systém managementu (nebo systém integrovaného managementu) je pojem,

Více

Projektové řízení základní pojmy. Michal Beránek 17.1.2015

Projektové řízení základní pojmy. Michal Beránek 17.1.2015 Projektové řízení základní pojmy Michal Beránek 17.1.2015 Obsah Základní pojmy, definice Řízení projektu Souvislost strategie a projektu Životní cykly projektu Procesy řízení projektu Důležité techniky

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

Současný stav a rozvoj elektronického zdravotnictví - pohled Ministerstva zdravotnictví

Současný stav a rozvoj elektronického zdravotnictví - pohled Ministerstva zdravotnictví Současný stav a rozvoj elektronického zdravotnictví - pohled první ročník semináře ehealth 2012 kongresový sál IKEM 1.11.2012 Elektronizace zdravotnictví: 1. jedná se o dlouhodobé téma 2. povede ke zvýšení

Více

Štěpánka Chaloupková

Štěpánka Chaloupková Štěpánka Chaloupková Akvizice a fúze: definice základních pojmů Akvizice je proces získávání či nabytí nějakého aktiva (předmětu, věci, osoby) nebo cíl tohoto procesu Označuje převzetí firmy nebo její

Více

Úvod. Projektový záměr

Úvod. Projektový záměr Vzdělávací program Řízení jakosti a management kvality Realizátor projektu: Okresní hospodářská komora Karviná Kontakt: Svatováclavská 97/6 733 01 KARVINÁ +420 596 311 707 hkok@hkok.cz www.akademieok.cz

Více

Standardy/praktiky pro řízení služeb informační bezpečnosti. Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha

Standardy/praktiky pro řízení služeb informační bezpečnosti. Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha Standardy/praktiky pro řízení služeb informační bezpečnosti Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha Služby informační bezpečnosti Nemožnost oddělit informační bezpečnost od IT služeb

Více

Česká letecká servisní a. s.

Česká letecká servisní a. s. Česká letecká servisní a. s. 1/20 Česká letecká servisní a. s. Your integrator of the avionics Česká letecká servisní a. s. Úvod do RTCA-DO178B Česká letecká servisní a. s. 2/20 Co je RTCA-DO178B RTCA-DO178B,

Více

Systém environmentálního řízení

Systém environmentálního řízení EMS Systém environmentálního řízení Pavel Růžička, MŽP Seminář k environmentální politice pro MSP Brno, 14.12.2007 Systémy environmentálního řízení Systematický přístup k ochraně ŽP ve všech směrech podnikatelské

Více

Zdravotnické laboratoře. MUDr. Marcela Šimečková

Zdravotnické laboratoře. MUDr. Marcela Šimečková Zdravotnické laboratoře MUDr. Marcela Šimečková Český institut pro akreditaci o.p.s. 14.2.2006 Obsah sdělení Zásady uvedené v ISO/TR 22869- připravené technickou komisí ISO/TC 212 Procesní uspořádání normy

Více

PPM umožňuje: PPM napomáhá: Systém je postaven na čtyřech základních pilířích, vedoucích k efektivnímu vývoji a optimalizaci portfolia:

PPM umožňuje: PPM napomáhá: Systém je postaven na čtyřech základních pilířích, vedoucích k efektivnímu vývoji a optimalizaci portfolia: Solutions s.r.o. PPM umožňuje: Komplexní analýzu vývoje portfolia Strategické řízení Evidenci projektů Evidenci projektových a souvisejících dat Závislost procesů, podpora workflow definovaná událost

Více

Požadavky na data a informace k hodnocení klastrové excelence. (Bronze Label of Management Excellence minimum requirments)

Požadavky na data a informace k hodnocení klastrové excelence. (Bronze Label of Management Excellence minimum requirments) Požadavky na data a informace k hodnocení klastrové excelence (Bronze Label of Management Excellence minimum requirments) Pro zapojení se do daného projektu resp. do benchmarkingové databáze je nutné provést

Více

Ing. Jana Košťálová Uplatnění nástrojů projektového řízení v ESF projektech

Ing. Jana Košťálová Uplatnění nástrojů projektového řízení v ESF projektech Ing. Jana Košťálová Uplatnění nástrojů projektového řízení v ESF projektech Univerzita Pardubice Uplatnění nástrojů projektového řízení v ESF projektech ESF fondy a aktuální rozšíření realizace projektů

Více

10 Otázky obecné povahy OBSAH

10 Otázky obecné povahy OBSAH 10 Otázky obecné povahy OBSAH Označení postupu DP 10/01 DP 10/02 DP 10/03 DP 10/04 R 1 DP 10/05 Otázka k přijatému doporučenému postupu Je možné použít určité tlakové části již dříve provozovaného tlakového

Více

Virtualizace serverů v ČSOB

Virtualizace serverů v ČSOB 5 Shared Experience Technická řešení Virtualizace serverů v ČSOB ČSOB jsme pomohli vybudovat globální evropské data-centrum, ušetřit náklady a zkrátit dobu dodání serverů pro nové aplikace a to díky virtualizaci

Více

Projektové řízení I. doc. Ing. Jaroslav Jánský, CSc.

Projektové řízení I. doc. Ing. Jaroslav Jánský, CSc. Projektové řízení I. doc. Ing. Jaroslav Jánský, CSc. Doporučená literatura SVOZILOVÁ, A. Projektový management. 1. vyd. Praha: Grada, 2006. 353 s. ISBN 80-247-1501-5, ROSENAU, M. D. Řízení projektů. 3.

Více

Standardy projektového řízení a certifikace

Standardy projektového řízení a certifikace Projektové řízení (BI-PRR) Standardy projektového řízení a certifikace Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Ing. Martin Půlpitel, 2011

Více

Jan Horák. Pilíře řešení

Jan Horák. Pilíře řešení Jan Horák Pilíře řešení Nová generace systémů Důsledek rozvoje a změn informatiky ve zdravotnictví: Nové technologie Výkonnost, mobilita, velikost monitorů, dotykové ovládání, vzdálené přístupy Nové možnosti

Více

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY 29 HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY POKORNÝ Karel Abstrakt: Metoda Balanced Scorecard (BSC) její podstata, obsah a principy. Vztah BSC ke strategickému a operativnímu řízení

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

Více

Management IS1. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Management IS1. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Management IS1 Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 23 1 Proč a jaký IS/IT? Informační systém je pro podnik totéž, co šaty pro člověka. Může mít vlastní, může mít vypůjčené (outsourcing), ale musí

Více

Workflow, definice, charakteristika, trendy

Workflow, definice, charakteristika, trendy Workflow, definice, charakteristika, trendy Workflow management je efektivní správa toku informací a řízení v podnikových procesech. Workflow automatizuje procesy. Workflow podporuje tok dokumentů, informací

Více

Simulace procesů pomocí Witness Visio Simulation Solution ve výuce

Simulace procesů pomocí Witness Visio Simulation Solution ve výuce Simulace procesů pomocí Witness Visio Simulation Solution ve výuce Zdeňka Videcká 1, Vladimír Bartošek 2 Anotace Jednou ze základních znalostí studentů je schopnost analyzovat, modelovat a efektivně řídit

Více

Standardní dokumenty

Standardní dokumenty Standardní dokumenty Zadávací dokumentace pro projekty EPC Principy European Energy Service Initiative EESI IEE/08/581/SI2.528408 Duben 2011 Výhradní odpovědnost za obsah tohoto materiálu nesou autoři.

Více

Podklady pro ICT plán

Podklady pro ICT plán Podklady pro ICT plán Škola: ICT - Hodnocení: Vstupní hodnocení Indikátor Aktuální stav k 1.3.2012 Plánovaný stav k 28.2.2014 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen omezená skupina

Více

Přístupy malých a středních podniků k marketingovým aktivitám

Přístupy malých a středních podniků k marketingovým aktivitám Přístupy malých a středních podniků k marketingovým aktivitám Petra Koudelková VUT Brno, Fakulta Podnikatelská Tel.: 793 649 578 Email: koudelkova@fbm.vutbr.cz Abstrakt V závislosti na finanční krizi je

Více

Kvalita systému řízení v institucích terciárního vzdělávání

Kvalita systému řízení v institucích terciárního vzdělávání Vysoké učení technické v Brně Kvalita systému řízení v institucích terciárního vzdělávání Národný seminár Vnútorné systémy zabezpečenia kvality Bratislava, 25.4.2013 Aleš Nosek Kvalita kvalita služby/výrobku

Více

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o. Bezpečnostní politika společnosti synlab czech s.r.o. Platnost dokumentu: 14. ledna 2015 Datum vypracování: 8. ledna 2015 Datum schválení: 13. ledna 2015 Vypracoval: Schválil: Bc. Adéla Wosková, Ing. Jaroslav

Více

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jiří Sedláček AIT s.r.o, Sinkulova 83, 140 00 Praha 4 tel. 261 225 072 www.ait.cz AIT, 2004 1 Program Současné postavení IT v podniku

Více

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! F11. Zásady personálního řízení projektu

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! F11. Zásady personálního řízení projektu Projektový manažer 250+ Kariéra projektového manažera začíná u nás! F Řízení lidských zdrojů F11 Zásady personálního řízení projektu V tomto tématu bude pozornost věnována zvláště těmto bodům: Úkoly managementu

Více

ZVÝŠENÍ KVALITY ŘÍZENÍ NA MĚSTSKÉM ÚŘADU LANŠKROUN V RÁMCI OP LIDSKÉ ZDROJE A ZAMĚSTNANOST. Reg. č. CZ.1.04/4.1.01/89.00080 KOMPETENČNÍ MODEL

ZVÝŠENÍ KVALITY ŘÍZENÍ NA MĚSTSKÉM ÚŘADU LANŠKROUN V RÁMCI OP LIDSKÉ ZDROJE A ZAMĚSTNANOST. Reg. č. CZ.1.04/4.1.01/89.00080 KOMPETENČNÍ MODEL ZVÝŠENÍ KVALITY ŘÍZENÍ NA MĚSTSKÉM ÚŘADU LANŠKROUN V RÁMCI OP LIDSKÉ ZDROJE A ZAMĚSTNANOST Reg. č. CZ.1.04/4.1.01/89.00080 PRAHA, 2013 Kompetenční model je nástroj práce se zaměstnanci MěÚ Lanškroun. Slouží

Více

Cobit 5: Struktura dokumentů

Cobit 5: Struktura dokumentů Cobit 5: Struktura dokumentů Cobit 5 Framework; popisuje základní rámec (principy, předpoklady, vazby na jiné rámce), Cobit 5 Enabler Guides; jde o dokumenty, které jsou obecným návodem na vytváření předpokladů

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Realizace kurzu ISO 9001 Manažer procesu

Realizace kurzu ISO 9001 Manažer procesu Př íloha č. 6 Výzvy Realizace kurzu ISO 9001 Manažer procesu Tento akreditovaný vzdělávací program navazuje na projekt implementace procesního systému řízení ISO 9001 dle real. projektu z výzvy č. 53.

Více

Výhody a rizika outsourcingu formou cloud computingu

Výhody a rizika outsourcingu formou cloud computingu Výhody a rizika outsourcingu formou cloud computingu Jiří Voříšek katedra informačních technologií Vysoká škola ekonomická v Praze vorisek@vse.cz 1 Výchozí model MMDIS pro identifikaci možností outsourcingu

Více

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY v souladu s 156 Zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen zákon Identifikace zadavatele: Česká republika Ministerstvo financí Letenská

Více

BEZPEČNOSTNÍ POLITIKA INFORMACÍ

BEZPEČNOSTNÍ POLITIKA INFORMACÍ BEZPEČNOSTNÍ POLITIKA INFORMACÍ společnosti ČEZ Energetické služby, s.r.o. Stránka 1 z 8 Obsah: 1. Úvodní ustanovení... 3 2. Cíle a zásady bezpečnosti informací... 3 3. Organizace bezpečnosti... 4 4. Klasifikace

Více

Zadavatel: Česká republika Ministerstvo práce a sociálních věcí se sídlem Na Poříčním právu 1/376, Praha 2, PSČ 128 02, IČO: 00551023

Zadavatel: Česká republika Ministerstvo práce a sociálních věcí se sídlem Na Poříčním právu 1/376, Praha 2, PSČ 128 02, IČO: 00551023 Zadavatel: Česká republika Ministerstvo práce a sociálních věcí se sídlem Na Poříčním právu 1/376, Praha 2, PSČ 128 02, IČO: 00551023 Veřejná zakázka: Informační systém o průměrném výdělku za roky 2015-2017

Více