Nasazení IT systému v bance

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Nasazení IT systému v bance Diplomová práce Autor: Bc. Radan Novák Informační technologie a management Vedoucí práce: Ing. Martina Hábová, Ph.D. Praha Duben, 2009

Prohlášení Prohlašuji, že jsem bakalářskou resp. diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Praze dne 15.4.2009... Radan Novák

Poděkování Ing. Martině Hábové, Ph.D. za precizní odborné vedení při vypracovávání diplomové práce, především za její podnětné a hodnotné nápady a připomínky, které dozajista přispěly k významnému zkvalitnění celé diplomové práce.

Anotace práce Ve své diplomové práci popisuji obecný proces nasazení IT systému začínající předprojektovou etapou, tvořenou sběrem námětů, které se následně vyhodnocují a schválené posunují dále ke spuštění projektu. Následuje etapa zahájení, kde se specifikují cíle projektu a hrubé vymezení rozsahu projektu, jako je plán, harmonogram, rozpočet a alokace jednotlivých rolí. Etapa plánování analyzuje základní požadavky na projekt, jsou zpracovány a vyhodnoceny plány projektu. Následuje realizační etapa, ve které se provádějí činnosti, které produkují měřitelné projektové výstupy jako jsou vývoj, testování a zavedení do produkce. V dalších kapitolách se věnuji rizikům projektu, popisuji role a jejich zodpovědnosti a pravomoci. Poté se věnuji nástrojům řízení projektů, popisuji vedení projektových týmů, protože v lidské faktoru a zkušenosti členů projektu, včetně projektového manažera, spatřuji silný nástroj k úspěšné implementaci systému. V teoretické části se věnuji metodikám projektového řízení, kde standardizované postupy považuji také za klíčové. Další tematickou částí mé práce je popis procesu nasazení IT systému v reálné bance. Závěr věnuji srovnání teorie a praxe. Annotation My diploma thesis describes a general procedure of an IT system implementation. The description starts from the pre-project stage, commencing by collection of subjects to be subsequently evaluated and, after having been approved, submitted to the project initiation phase. The next stage is the launch phase, which defines project objectives and general project specifications, e.g. plan, time-schedule, budget and allocation of individual roles. The planning stage analyses basic requirements related to the project, with development and evaluation of project plans. This stage is followed by the implementation stage, which involves activities producing measurable project outputs, e.g. development, testing and implementation within production processes. Further chapters deal with project risks and describe individual roles and responsibilities and powers related thereto. Then I focus on project management tools and description of project team management, because in my opinion the human factor and expertise of the project team members constitute a powerful tool of a successful system implementation process. In the theoretical section I deal with project management methodologies, with standardized procedures assessed as key elements. This section is followed by description of an IT system implementation within a real bank. The final part is devoted to comparison of theory and practice.

Obsah Úvod... 7 1. Metodiky projektového řízení... 7 1.1 COBIT... 7 1.2 ITIL... 9 1.3 CMMI... 12 1.4 Scrum... 13 1.5 RUP... 16 1.6 MSF... 18 2. Obecný proces nasazení IT systému... 21 2.1 Definice etap... 21 2.2 Předprojektová etapa... 23 2.3 Etapa zahájení... 23 2.4 Etapa plánování... 24 2.5 Realizační etapa... 25 2.6 Etapa hodnocení... 25 2.7 Rizika projektu... 25 3. Techniky řízení projektů... 27 3.1 Metody plánování... 27 3.1.1 WBS - Work Breakdown Structure... 27 3.1.2 AND - Activity Network Diagram... 29 3.1.3 Ganttův diagram... 32 3.1.4 Afinní diagram... 33 3.1.5 PDPC diagram... 36 3.1.6 Mapa procesu... 39 3.1.7 Korelační diagram... 40 3.2 Role, zodpovědnosti a pravomoci... 41 5

3.2.1 Projektový řídící výbor... 42 3.2.2 Projektová kancelář... 43 3.2.3 Majitel projektu (Business vlastník)... 43 3.2.4 Projektový vedoucí (Project manager)... 44 3.2.5 Projektový tým... 45 3.3 Vedení projektových týmů... 46 3.3.1 Komunikace v týmu... 46 3.3.2 Struktura týmu... 47 3.3.3 Pozice a role v týmu... 47 3.3.4 Vedení týmu... 48 3.3.5 Problémy v týmu... 48 4. Proces nasazení IT systému v bance... 49 4.1 Fáze přípravy a schválení plánu projektů... 49 4.2 Přípravná fáze projektu... 51 4.3 Zajištění externí dodávky systému IT... 53 4.4 Funkční analýza a návrh řešení... 54 4.5 Příprava první verze testovacího plánu... 55 4.6 Testování kvality... 57 4.7 Pilotní provoz, Baby sitting... 62 5. Srovnání teorie a praxe... 64 Závěry a doporučení... 68 Seznam použité literatury... 69 Seznam obrázků... 70 Použité zkratky a terminologie... 71 Přílohy... 76 6

Úvod Podnět k iniciaci nasazení nového nebo úpravě stávajícího IT systému může být potřeba vyvolaná technologickým pokrokem, novými potřebami zákazníků, legislativní nutností, požadavky trhu, případně strategickým plánem rozvoje informačního systému. Zavádění IT systémů v bance rovná se téměř výhradně projekt. To znamená, že klíčovou vlastností pro zavedení jakéhokoli systému je úspěšné ukončení jednotlivých projektů, stejně tak jako celého programu. Klíčové je proto mít kvalitní, excelentní projektovou metodiku, jakožto jednotnou kuchařku pro projekty v organizaci, standardizovat postupy a umožnit využití přínosů z opakovaných činností. Banky jako takové také prochází povinně mnoha různými audity (ČNB, korporátní audity, bezpečnostní audity a další) a je proto nutné mít vše klíčové standardizováno a návazně zapracováno do procesů. Těmito metodikami se pak řídí nejen projekty v IT, ale i ostatní projekty mimo sféru IT. Hodnocení úspěšnosti, přínosů a auditování je pak jednoznačné a Project manager, jakožto vedoucí osoba zodpovědná za projekt jako takový a za jeho úspěšné nasazení se jako osoba stává jednoduše zástupnou. Obecně totiž platí, že Project manager nemusí být odborníkem na řešenou problematiku, ale odborníkem pro řízení projektových týmů. 1. Metodiky projektového řízení 1.1 COBIT COBIT (Control Objectives for Information and Related Technology) - byl vyvinut jako všeobecně přijímaný standard pro správný postup řízení, kontroly a auditu informačních technologií. cíle řízení pro informační a s nimi spojené technologie COBIT je zaměřený na business, je procesně orientovaný, založených na kontrolách a řízený metrikami 7

V současné době standard pro hodnocení úrovně provádění procesů informatiky a pro podporu jejího řízení COBIT pokrývá všechny aspekty řízení informatiky, zatímco ITIL je zaměřen na řízení ICT infrastruktury a jejích služeb, takže například ITIL neobsahuje oblast řízení lidských zdrojů, zatímco COBIT ano. Jeho nejčastější použití je jako nástroj auditu úseku informatiky a jeho strategického řízení oproti ITIL je COBIT zdarma COBIT umožňuje beze změny certifikovat oblast IT na normu ISO 9001:2000 1 COBIT pro jednotlivé oblasti definuje: cíle řízení procesy definuje do 4 domén zdroje přiřazené k procesům Domény: plánování a organizace akvizice a implementace dodávka a podpora monitoring a evaluace Je založený na kontrolách Procesy potřebují kontrolní mechanismy politiky, procedury, praktiky a organizační struktury, které zajišťují, že budou dosaženy business cíle, případně budou neočekávané události detekovány a vyřešeny. Hlavní důvody pro použití metodiky COBIT COBIT formalizuje IT procesy do jednoduché tříúrovňové struktury implementace základní procesní struktury je jednoduchá a logická struktura COBITu je srozumitelná managementu, uživatelům a auditorům umožňuje beze změny certifikovat oblast IT na normu managementu jakosti ISO 9001:2000 1 Cobit Stearing Committee. Cobit Framework, Second edition. Information Systems Audit and Control Foundation 8

COBIT definuje odpovědnosti procesů včetně odpovědnosti, pravomoci a obsah IT vazeb na kritické faktory a podnikové cíle COBIT obsahuje konzistentní vazby mezi podnikovou a informační strategií: - neit management pomocí COBITu dokáže lépe definovat a strukturovat požadavky na IT a hodnotit jeho celkovou úspěšnost - IT management dokáže pomocí vazby IT cíle < > Business cíle lépe komunikuje s vrcholovým vedením podniku a prosazuje své potřeby (vstupy pro plánování, zdroje, apod.) - umožňuje konzistentní propojení metodiky BSC (Balanced Scorecard) mezi celopodnikovou úrovní a IT úrovní COBIT obsahuje komplexní návrh výkonnostních i výsledkových ukazatelů/metrik 2 1.2 ITIL ITIL (Information Technology Infrastructure Library) - je sada postupů a doporučení jak řídit IT služby na základě nejlepších praktických zkušeností, přičemž ponechává velikou volnost při implementaci těchto procesů a doporučení. Z tohoto důvodu je možná lepe nehovořit o metodice ale o souhrnu doporučení (Best Practices). Šíření těchto doporučení je prováděno formou školení, kurzů, knih, CD a certifikací. Metodika ITIL je výhradně určena pro každodenní řízení IT služeb a ICT infrastruktury. Knihovna ITIL je rozdělena do 8 svazků, vždy zaměřených na specifickou oblast řízení IT služeb, které odpovídají klíčovým procesům v IT oddělení a vzájemně se prolínají. Jedná se o: podnikatelský pohled (Business Perspectives) správa aplikací IT (Aplication Management) dodávka IT služeb (IT Services Delivery) podpora IT služeb (IT Services Support) správa IT infrastruktury (IT Infrastructure Management) 2 Wikipedie, Control Objectives for Information and related Technology (COBIT), dostupný z URL: http://en.wikipedia.org/wiki/cobit 9

řízení IT projektů IT (Project Management) Charakteristické rysy ITIL procesní řízení - ITIL používá moderní procesně orientovaný přístup k řízení IT služeb. Proces je logický sled úkolů transformujících nějaký vstup na nějaký výstup, přičemž plnění jednotlivých úkolů v procesu je zajišťováno rolemi s jasně definovanými odpovědnostmi. Celý proces je řízen, monitorován, vyhodnocován měřen, a neustále vylepšován, což je odpovědností vlastníka procesu zákaznicky orientovaný přístup - všechny procesy jsou navrženy s ohledem na potřeby zákazníka - každá aktivita musí přinášet nějakou přidanou hodnotu pro zákazníka jednoznačná terminologie nezávislost na platformě Public Domain - každý si může knihy ITIL koupit a procesy ITSM (IT Service Management) podle ITIL ve svém podniku implementovat 3 3 KRŮTA, Vladimír, Procesy pro kvalitnější správu IT služeb 10

Obrázek 1 - schéma ITIL Obsah ITIL Definování procesů potřebných pro zajištění ITSM: - stanovení cílů, vstupů, výstupů a aktivit každého procesu - stanovení rolí a jejich odpovědností v daném procesu - způsob měření kvality poskytovaných IT služeb a účinnosti ITSM procesů (performance a metriky) - vzájemné vazby mezi jednotlivými procesy - postupy auditu a zásady reportingu pro každý proces Zásady pro implementaci procesů ITSM: - přínosy každého procesu - Critical Success Factors, možné problémy a vhodná protiopatření - náklady na implementaci a následný provoz - zásady pro řízení podpůrné ICT infrastruktury Zásady bezpečnosti ICT infrastruktury 11

1.3 CMMI CMMI (The Capability Maturity Model) - jedná se o soubor pravidel, požadavků a doporučení, které mají splňovat firemní procesy a co je třeba dodržovat, aby procesy vývoje byly efektivní, účinné a spolehlivé, přičemž důležitou charakteristikou modelu, která jej odlišuje od norem primárně zaměřených na procesy a kvalitu výroby je právě zaměření na procesy vývoje. CMMI je stavěno jako cesta, která pomáhá k neustálému zlepšování úrovně řízení a vývoje. CMMI model je složenina z několika původních modelů jako jsou např. CMMI for Services, for Software, for Acquisition. Jako integrované řešení je nazýván souhrnně CMMI od roku 2000. Složení CMMI modelu: Disciplíny modelu CMMI: CMMI/SW - softwarové inženýrství (aplikace systematických, disciplinovaných a kvalifikovaných přístupů k vývoji, provozu a údržbě SW) CMMI/SE - systémové inženýrství (pohled na vývoj celého systému, popisuje implementaci procesů projektového vývoje sytému) SS výběr dodavatelů a řízení dodávek Prvky modelu CMMI Procesní oblast skupina pravidel, doporučení a praktik, které je vhodné společně implementovat z důvodu lepšího dosažení cílů stanovených v dané oblasti projektu. Úrovně CMMI Popisují kroky zlepšování procesů od neúplného stavu do stavu vylepšení. Bývají použity pro hodnocení úspěšnosti. Úroveň vyspělosti vyjadřuje relativní zlepšení (porovnání předchozího a současného stavu) v dané oblasti. Umožňuje tak vylepšovat vybranou oblast procesů pomocí kontinuálního procesu vylepšování. Úroveň zralosti vyjadřuje pevnou úroveň, která musí být dosažena. Díky tomu je jasně vytyčena úroveň, která musí být dosažena, aby se dalo prohlásit vylepšení za úspěšné. Tato hodnota je hlavním směrníkem ve stupňovité reprezentaci CMMI. 12

Rozdíl mezi kontinuální a stupňovitou reprezentací v CMMI charakterizujte jednotlivé úrovně. Kontinuální reprezentace používá úrovně vyspělosti (Capability level) pro popis relativního zlepšení v dané oblasti. Je flexibilnější pro zlepšení procesů, nezáleží na aktuální úrovni. Stupňovitá reprezentace využívá definované, strukturované postupy pro zlepšení na základě referenčního modelu. Dosažení určité úrovně zralosti je východiskem k další úrovni. Úroveň 0 - vyspělost neúplná (proces není vykonáván vůbec, neexistují generické cíle a specifické cíle jsou vykonávány jen částečně), zralost neexistuje. Úroveň 1 vyspělost vykonávaná (proces splňuje specifické cíle procesní oblasti), zralost úvodní ( sw. procesy jsou náhodné a chaotické, reagují pouze na vzniklé problémy) Úroveň 2 vyspělost řízená (proces je vykonáván, plánován a monitorován na základě definic procesu), řízená zralost (jsou zavedeny a prováděny postupy řízení) Úroveň 3 vyspělost definovaná (proces je řízen a je upravován podle definovaných postupů), zralost je definovaná ( procesy jsou dobře definované a chápané, jsou popsány ve standardech i pro vylepšení) Úroveň 4 vyspělost kvantitativně řízená (proces je řízen a optimalizován pomocí kvantitativních technik), zralost kvantitativně řízená (definice metrik pro definované procesy pomocí kterých jsou měřeny a optimalizovány, lze předpovídat i vývoj stavu procesů) Úroveň 5 vyspělost optimalizující (je kvantitativně řízen a stáje je optimalizován), zralost optimalizující (procesy se neustále zlepšují na základě chápání příčin). 4 1.4 Scrum SCRUM z anglického slova Scrum (v ragby skrumáž, mlýn), je to agilní metodika, která vychází z objektově orientovaného přístupu. Slibuje zvýšit produktivitu a pružnost vývoje pomocí organizace práce v týmu, vhodná zejména na řízení projektů. 4 Buchalcevová, Alena, přednášky z předmětu Systémová metodologie" 13

Vývoj pomocí SCRUM: začíná se plánovací fází (Pergame) kde se určí úkoly (Backlog), následují vývojové sprinty (měsíční vývojová epizoda, jejím cílem je uvolnění nové verze systému a představení nové funkčnosti). Sprinty se dělí na fázi vývoje, zabalení, revize a přizpůsobení. Na konci každého dne Sprintu je schůzka (Scrum Meeting = 15minut), která shrnuje co se udělalo, jaké byly problémy a plány do další schůzky. Definuje vývoj SW jako empirický proces (není ho možné přesně popsat a opakovat), je postavený na třech pilířích: viditelnost do procesu, inspekce, adaptace. Osoby zainteresované do projektu pigs (vývojový tým) a chickens (ostatní - např. management, obchodníci, atd.). Role SCRUM: ProductOwner = spravuje seznam požadavků (Backlog) Team = skupina lidí, která se řídí sama a cílem je v každém Sprintu dodat fungující software ScrumMaster = zodpovídá za SCRUM proces (jeho implementaci a maximální účinnost) Sprint všechna práce se dělá uvnitř sprintu. Sprint je 30 denní iterace. na začátku sprintu se koná Sprint Planning Meeting: - trvá max. 8 hodin - cílem je definovat Sprint Backlog - první 4 hodiny - Product Owner prezentuje požadavky nejvyšší priority v Product Backlogu, tým se dotazuje na obsah, účel, význam požadavků, nakonec vybere požadavky nejvyšší priority do Sprint Backlogu - druhé 4 hodiny tým plánuje Sprint jde o plán předběžný, který se neustále sprintu v průběhu upravuje každý den se koná Scrum Meeting 15 min. na konci sprintu se koná Sprint review meeting: - trvá 4 hodiny - tým prezentuje, co bylo vyvinuto - Sprint retrospective meeting zlepšení procesu a praktik 14

Principy Scrum Komunikace - sdílení informací umožňuje viditelnost, lepší rozhodování a pochopení cílů - denní informování o (daily meeting) pokroku - je třeba vědět, jak na tom tým je a podle toho dělat rozhodnutí (Sprint backlog) - pracujte společně ( Stay in sync.) Pravomoc týmu - není nic mocnějšího než tým, který je omezován jen tím, jak kreativní je a jak tvrdě bude pracovat Učit se a zlepšovat - zkusit, prohlédnout výsledky, zlepšit sprint - krátké sprinty jsou efektivní - předvedení výsledků na konci sprintu (Sprint review) - zlepšení po každé iteraci (Sprint retrospective). Dodat hodnotu včas - priority požadavků (product backlog, Product Owner), dohoda o produktech, jejich dodání to buduje důvěru mezi spolupracovníky, dalšími týmy a zákazníky - plánování sprint (Sprint planning meeting) SCRUM meetings umožňují monitorovat stav projektu, konají se vždy ve stejný čas na stejném místě trvají méně než 30 minut (cílem je 15 minut) vede je Scrum master účastní se jich všichni členové týmu (vývojáři, uživatelé, testeři,...) navštěvují je manažeři, aby věděli o stavu, ale aktivně se neúčastní slouží ke zjištění problémů, ale ne k jejich řešení každý účastník musí zodpovědět 3 otázky: - co udělal od poslední Scrum porady - co bude dělat do příští Scrum porady - jaké překážky mu stojí v cestě 15

Scrum - zhodnocení: projektová metodika zaměřená především na řízení projektu chápe procesy při vývoji software jako empirické procesy, které není možné předvídat, ale je nutné je monitorovat. K tomu poskytuje praktiky jako denní porady, monitorování Sprintu (30 denní iterace) pomocí Backlog graph a dalšího. explicitně tím že stabilizuje snižuje chaos při vývoji, úkoly pro 30 denní Sprint je popsána jako jazyk vzorů (pattern language). 5 1.5 RUP Metodika Rational Unified Process je založena na tzv. nejlepších praktikách softwarového vývoje: iterativní vývoj, řízení požadavků, použití komponentové architektury, vizuální modelování, kontrola kvality software, řízení změn. Je založena na třech základních zásadách: řízení případů užití a rizik (snaha o co největší užitečnost pro zákazníka, pro to je důležité porozumění mezi zákazníkem a vývojovým týmem už od raných fázi, snaha o řízení projektu tak, aby byla minimalizována rizika) základem je architektura (rozklad systému na části komponenty, důležité jsou jejich vztahy a nasazení na HW) - řízení pomocí případů užití iterativní a inkrementální vývoj Je to instance metodiky Unified Process. Důraz je kladen na tzv. best practises (iterativní a inkrementální vývoj, použití komponentové architektury, řízení změn, kontrola a ověřování kvality, vizuální modelování (UML), správa požadavků, použití CASE nástrojů). Je třeba vytvářet jen to, co je nezbytné, minimalizovat papírovou dokumentaci, snažit se o flexibilitu, učit se z chyb, prověřovat rizika, definovat cíle a metriky (aby se mohl hlídat pokrok), používat nástroje na vývoj SW. Hlavní myšlenky metodiky RUP shrnutí: řešit hlavní rizika včas a kontinuálně 5 Buchalcevová, Alena, přednášky z předmětu Systémová metodologie" 16

ujistit se, že je dodávána zákazníkovi hodnota zaměřit se hlavně na fungující SW umožnit změny v projektu definovat včas architekturu sestavit systém z komponent pracovat společně jako jeden tým chápat kvalitu jako základ vývoje (ne až zpětně) Fáze a disciplíny v metodice RUP, Fáze iterativního vývoje - hlavní milníky: Počáteční fáze (Inception): je třeba pochopit co se bude vytvářet (vize, high-level požadavky, business case, ne detaily) definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. Počáteční fáze končí rozhodnutím, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu, možné realizovat. Elaborační fáze (Elaboration): je třeba vědět jak vytvářet (architektura, detailizace většiny požadavků, ne detailní design), definovat architekturu systému a komponenty, je vytvořen prototyp, který ověří všechny architektonické principy a umožní zpřesnění plánu realizace systému. Konstrukční fáze (Construction): vytváření produktu (výsledkem je fungující produkt, možnost provedení kompletních systémových testů), návrh a realizace systému včetně testování. Prosazuje se pokud možno paralelní vývoj. Fáze nasazení (Transition): prověření řešení (splňuje očekávání, akceptace) - zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření HelpDesku atd. Každá fáze je uzavřena milníkem časovým okamžikem, ve kterém musí být splněny cíle fáze a dochází k rozhodování. Metodika Rational Unified Process patří mezi rigorózní metodiky, neboť podrobně definuje procesy a činnosti při vývoji software. Zaměřuje se pouze na vývoj nového řešení 17

realizovaný objektově orientovaným způsobem. Podstatným nedostatkem metodiky RUP je její zaměření pouze na úroveň projektu. Metodika má poměrně malý rozsah, neboť se zaměřuje pouze na vývoj řešení (nezahrnuje provoz a údržbu) a pouze na softwarově inženýrské role a dimenze. Silnou stránkou metodiky RUP je její integrace s CASE nástroji firmy Rational, které podporují především oblast analýzy a návrhu, testování, řízení konfigurací a správu požadavků. K výhodám patří, že je dodávána jako produkt, který zahrnuje znalostní bázi s webovým rozhraním a sadu nástrojů na přizpůsobení procesu a šablon do nástrojů firmy Rational. 6 1.6 MSF MSF (Microsoft Solutions Framework) zavádí proces do vývoje softwaru, ale neomezuje příliš kreativitu lidí. Snaží se odhalovat chyby a rizika včas. Tato metodika je vhodná pro menší týmy (velké týmy mohou fungovat jako tým týmů ). Postup projektu je definován úspěšností testů a dalšími objektivními metrikami (počet chyb, pokrytí kódu, apod.). iterativní postup založený na scénářích pracuje s požadavky na kvalitu a riziky využívá testování v kontextu projektu Vývoj v iteracích jednotlivé úlohy, chyby, scénáře apod. jsou přiřazovány verzím (iteracím) např. Beta1, RC, RTM každá iterace je vždy jasně uzavřena podporuje postupný vývoj řešení umožňuje dobré měření postupu nabízí odhad rychlosti dalšího postupu Týmový model MSF role Product Management zastupuje zákazníka vůči týmu - Zastupuje tým vůči zákazníkovi 6 CHARVAT, Jason. Project Management Methodologies 18

Oblasti činnosti: marketing, přínosy produktu, zastupování zájmů zákazníka, plánování produktu. Program Management řídí celkový proces (termíny, náklady, rozsah, specifikaci) Oblasti činnosti: řízení projektu, celková architektura řešení, dohlížení na dodržení procesu, administrativa. Development vytváří řešení, které naplňuje očekávání zákazníků a je v souladu se specifikací produktu Oblasti činnosti: technologické konzultace, implementace architektury a designu, vývoj infrastruktury, vývoj aplikace. Testing vytváří strategii a plány testování spravuje automatický build provádí testy účastní se na řízení kvality produktu Oblasti činnosti: plánování testů, vytváření testů, vyhodnocování výsledků. User Experience zastupuje koncového uživatele vůči týmu zastupuje tým vůči koncovému uživateli účast na definování: o požadavků uživatele o funkcí produktu zodpovědný za ergonomii a použitelnost Oblasti činnosti: grafický design, ergonomie a použitelnost, speciální požadavky, pro postižené, internacionalizace. dokumentace a komunikace školení uživatelů 19

Release Management zastupuje provozní oddělení vůči vývojovému týmu zastupuje vývojový tým vůči provoznímu oddělení podpora Beta testování produktu příprava provozního oddělení na provoz aplikace definuje požadavky na provoz aplikace a její důsledky Oblasti činnosti: infrastruktura a provoz, podpora. Procesní model MSF Envisioning Phase - Vision/Scope Approved (odpovídá Produkt management) Planning Phase Project Plan Approved (odpovídá Program management) Development Phase Scope komplete (odpovídá Development, user experience) Stabilising Phase Release Readiness Approved (odpovídá Testing, Release management) Deploing Phase Deployment komplete(odpovídá Release Management) Persony (personas) v kontextu vývoje zastupuje uživatele anebo jejich skupinu (podobné actor ) persona není abstraktní a neosobní actor, je to fiktivní osoba popisuje se její chování, návyky, motivace apod., je možné ji ztotožnit s konkrétním člověkem používá se ke stanovení cílů (a z nich pak scénářů) Seznam scénářů pro každou personu se stanoví její cíle, pro každý cíl scénáře nutné k jeho dosažení scénář je cesta uživatelským rozhraním od počátku až do dokončení úlohy při psaní scénářů je vhodné být specifický, ale nezacházet do příliš hlubokých detailů příliš málo scénářů znamená malou flexibilitu plánů příliš mnoho scénářů vede k zahlcení stanovení důležitosti scénáře - priority volitelně - stanovení pracnosti implementace 20

Řízení projektu v MSF disciplína, nikoliv role v MSF má každá určité povinnosti s řízením projektu Manažer projektu v klasickém smyslu neexistuje, nejblíže k němu má role Program Management Týmový model není příliš hierarchický manažer lidí zpravidla není přímým členem týmu, rozhoduje případné spory apod. Vytvoření týmového projektu Na základě šablony procesu: - MSF for Agile Software Development - MSF for Process CMMI Improvement - vlastní anebo upravená jiná šablona Šablona obsahuje: - typy udržovaných seznamů (work items) - položky v těchto seznamech - skupiny a jejich oprávnění - reporty - úvodní obsah projektového portálu (šablony dokumentů apod.) - politiku pro check-in - integrovanou nápověda metodologie - iterace projektu 2. Obecný proces nasazení IT systému 2.1 Definice etap 21

Obrázek 2 - obecný vývojový diagram etap Předprojektová etapa Námět (příloha A) Projektová kancelář komunikace s autorem check list (příloha B) Majitel projektu Info autora Informování autora Podmíněné zastavení NE (info autora) ANO (info o zamítnutých námětech) Projektový výbor Vedoucí projektového týmu ANO (prirorita, majitel) NE Etapa zahájení Vedoucí projektového týmu sestaví projektový tým (příloha C, příloha D) Zadání projektu (příloha E) Podmíněné zastavení Feasibility study (příloha F) Business case (příloha G) Uživatel Majitel projektu NE ANO Work Breakdown Structure (Stromový diagram) Matice zodpovědností Etapa plánování Activity Network Diagram (Síťový diagram) Analýza rizik Podmíněné zastavení Gantt diagram - Plán operativního řízení projektu, diagram nákladů (příloha H), diagram zdrojů Uživatel Majitel projektu NE "Výroba" projektového výstupu ANO Etapa realizace Operativní řízení (příloha I) Testování projektového výstupu Školení uživatelů Podmíněné zastavení Odevzdání projektového výstupu (příloha J) Uživatel Majitel projektu NE ANO Etapa hodnocení Hodnotící matice (příloha K) Hodnocení skupinové dynamiky (příloha L) Archivace, standardizace 22

2.2 Předprojektová etapa V této etapě probíhá sběr námětů. Náměty jsou elektronickou poštou zasílány do Projektové kanceláře, která vyplní po upřesnění s autorem Checklist. Na jeho základě se rozhoduje, zda je námět vhodný jako téma pro projekt a navrhne se projektovému řídícímu výboru vybraná témata pro spuštění projektu. V případě, že téma není vhodné na projekt, informuje projektová kancelář autora námětu o důvodech a archivuje kompletní dokumentaci k námětu. Pokud projektový řídící výbor povolí pustit projekt do etapy zahájení, stanoví prioritu a rozhodne o majiteli projektu. Majitel projektu jmenuje vedoucího projektu. Výstupem předprojektové etapy je vyplněný Checklist, definovaný majitel projektu, priorita a jmenovaný vedoucí projektu. 2.3 Etapa zahájení Cílem etapy Zahájení projektu je právě stanovit rámec řízení projektu. Etapa obsahuje pouze řídicí činnosti s výjimkou specifikace rozsahu projektu, protože dekompozice tohoto kroku zpravidla obsahuje i výkonné činnosti závislé na typu projektu (např. o projektu vývoje systému zahrnuje i úvodní analytické modely). Specifikace cílů a rozsahu projektu je podmínkou pro návazné kroky, protože bez prvního hrubého vymezení rozsahu projektu nelze uvažovat o jeho plánu, harmonogramu, rozpočtu i potřebných rolích pro splnění cílu projektu. Celý postup etapy Zahájení projektu může být v praxi iterativní, neboť důsledkem specifikace projektu mohou být termíny a náklady, které nejsou pro sponzora projektu přijatelné, což muže vést v další iteraci ke snížení rozsahu projektu. Podobně jako provedení analýzy rizik může vést k doplnění činností, které mají tato rizika snížit, do plánu projektu. Výstupem etapy Zahájení projektu je Základní dokument projektu (Project Charter) nazývaný také Zpráva o zahájené projektu. Tento dokument je vždy na závěr každé další etapy (kromě poslední) opětovně posuzován a podle potřeby revidován. V etapě Zahájení projektu je třeba definovat hranice projektu, tj. jeho rozsah (co projekt bude a co nebude pokrývat). Rozsah projektu lze uvažovat z dvou hledisek: z hlediska rozsahu zkoumání a z hlediska rozsahu řešení. Nejdříve identifikujeme hlavní cíle a kritické požadavky projektu. Rozsah projektu zpravidla znázorníme pomocí diagramů. 23

Rozsah projektu bývá definován pomocí seznamu požadavků vyšší úrovně. Oprávněnost těchto požadavků může být prověřena pomocí techniky analýzy kritických požadavků. Pro projekt definujeme jeho organizaci, tj. role, které se budou podílet na realizaci projektu. Pro každou roli stanovíme její odpovědnost. Projektová organizace zahrnuje vzájemné vztahy mezi jednotlivými rolemi. Plán celého projektu vychází obvykle z některého procesu, který je k dispozici pro projekty obdobných charakteristik. Definujeme kroky a etapy projektu a závislosti mezi nimi. Dále odhadneme jejich pracnost, určíme potřebu zdrojů (počty pro jednotlivé role) pro jednotlivé kroky, vypracujeme harmonogram projektu a připravíme rozpočet projektu. Podobně, ale na podrobnější úrovni, zpracujeme plán následující etapy projektu. Plán projektu je vytvářen na začátku projektu a pak je vždy aktualizován na konci jeho etap případně pokud dojde k významným změnám. Jedná se o hrubý plán na úrovni etap a kroků často vytvářený bez znalosti konkrétních osob, které se budou na projektu podílet. Naproti tomu plán etapy je podrobný a vytváří se vždy na konci předchozí etapy. Výjimku tvoří plán etapy zahájení projektu, který se tvoří v rámci iniciace projektu. Důležité je zaznamenat jako součást každého plánu předpoklady jeho platnosti. Na úrovni projektu neplánujeme podrobně. Podrobný plán vypracováváme vždy jen pro následující etapu. 7 2.4 Etapa plánování Jsou analyzovány základní požadavky na projekt. Jsou navrhována a hodnocena možná řešení. Jsou zpracovány a vyhodnoceny plány projektu. Po schválení postupu projektu do etapy plánování vytvoří projektový tým metodou brainstormingu stromový diagram (WBS - Work Breakdown Structure), matici zodpovědnosti a síťový diagram. Dále provede analýzu rizik a vytvoří Ganttův diagram s plánem operativního řízení. Do elektronické podoby (MS Project) se práce převádí po vytvoření síťového diagramu. Výstupem plánovací fáze jsou Ganttův diagram s plánem operativního řízení, diagram nákladů a diagram zdrojů. 7 Metodika pro implementaci systémů, Cleverlance 24