Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů 1

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

Download "Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů 1"

Transkript

1 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů 1 Jakub Balada, Alena Buchalcevová Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií nám. W. Churchilla 4, Praha 3 Abstrakt: Vývoj informačních systémů se stále potýká s nízkou úspěšností, zejména u velkých komplexních systémů. Výsledkem je nedostatečná podpora ICT pro hlavní cíle podniku, jelikož nedochází k efektivnímu propojení ICT s podnikatelskou strategií. Agilní metodiky zavádí nové principy v řízení vývoje informačních systémů, které tyto problémy eliminují. Hlavním cílem článku je prokázat přínosy agilní metodiky Scrum oproti rigorózním metodikám při vývoji velkých komplexních systémů, kde se tyto metodiky zatím příliš nevyužívají. Klíčová slova: Agilní vývoj, metodika vývoje, SCRUM, řízení projektů, splnění požadavků, komplexní systém. Abstract: Information system projects still fail in a large number. Agile methodologies reached higher level of success at specific projects developed by small teams. However most of IT companies still refuse this approach at largescale projects, which often deliver low value software to business. This paper comments mostly described conditions that must be fulfilled for agile adoption and analyze limitation of agile software process with solutions which can solve these problems. Goal of this paper is to proof a benefit of Scrum adoption at large-scale projects. For this purpose project case study of Identity and Access implementation is described. This project is characterized by limitations discussed above which should avoid Scrum adoption. Nevertheless project was marked as a successful primary due to change of methodology from plan-driven to Scrum during its development. This change helped to meet all dates at a project, accelerate bugfixing and mainly to deliver functionalities which brings higher value to business. Thanks to proposed solutions of Scrum adoption this paper proves a possibility to use this methodology at large-scale projects of system development. This can lead to common usage of Scrum which will increase success rate of all information system projects types. Goal-value oriented approach leads to more effective interconnection between ICT and business goals. 1. Úvod Význam ICT pro konkurenceschopnost podniku je stále velmi důležitý. Zejména neustálý rychlý vývoj podnikatelského prostředí nutí podniky efektivně využívat možnosti ICT a pružně reagovat na změny v tomto prostředí. Současně vývoj mnoha velkých ICT projektů končí nezdarem. Například autoři knihy [1] shrnují své názory týkající se toho, za jakých podmínek může podnik získat pomocí ICT strategickou výhodu následovně: 1 Příspěvek vznikl v rámci řešení grantu GAČR 201/08/ Inovace informačních systémů podporující konkurenceschopnost podniků SYSTÉMOVÁ INTEGRACE 4/

2 Jakub Balada, Alena Buchalcevová Strategický význam ICT nepominul, ale není možné ho naplnit stejnými cestami jako v minulosti. Strategické výhody nelze dosáhnout pouze nasazením nové technologie. Předpokladem je unikátní a efektivní propojení ICT s podnikatelským modelem, podnikovou strukturou a podnikovými procesy, které podniku umožní zvyšovat rychlost reakce na významné události, snižovat náklady, zvyšovat kvalitu anebo poskytovat nové produkty/služby zákazníkům a získávat klíčové informace dříve, než to zvládne konkurence. [1] Agilní principy vývoje informačních systémů mohou být právě touto novou cestou, přinejmenším v oblasti efektivní dodávky nových ICT služeb v rámci podniku. Základem agilního přístupu k vývoji IS je maximální snaha o splnění požadavků zadavatele, které se zpravidla v průběhu projektu 2 mění. Jinými slovy se jedná o neustálou snahu pomoci zadavateli zvýšit jeho konkurenceschopnost pomocí včasné dodávky služby, kterou potřebuje v daném čase. Agilní metodiky se již prosazují u vývoje menších projektů s krátkou dobou trvání. Nejpoužívanější z nich je podle světového průzkumu [6] Scrum. Využívá ho 50% respondentů, dalších 24% využívá hybrid Scrumu a XP. Obecně je agilní vývoj využit přibližně u poloviny všech projektů. Bohužel v České republice je situace odlišná. Podle posledního a pravděpodobně jediného průzkumu využití agilních metodik v ČR [5] využívá agilní metodiky méně než 10% respondentů. Podobně dopadl průzkum znalosti agilních metodik v ČR uvedlo pokročilou či základní znalost 43% respondentů [5] oproti 93% v celosvětovém průzkumu [6]. Cílem tohoto článku je mimo jiné větší osvěta a prokázání výhod agilního vývoje a potažmo Scrumu v České republice. Obecně jsou agilní metodiky považovány za alternativu ke standardním rigorózním metodikám, které jsou nadále doporučovány pro vývoj komplexních systémů. V článku Limitations of agile software processes [7] jsou popsány podmínky a následující omezení nasazení agilních principů: omezená podpora pro vývoj v distribuovaném prostředí omezená podpora pro využití subdodavatelů omezená podpora pro vývoj znovupoužitelných produktů omezená podpora pro vývoj ve velkých týmech omezená podpora pro vývoj kritických systémů omezená podpora pro vývoj velkých komplexních systémů V závěru [7] je shrnuto, že společnosti, které vyvíjejí dlouhotrvající velké komplexní projekty, nemusí být schopné využít agilní principy v jejich aktuální podobě. Naopak analýza neúspěchů velkých projektů (např. The replacement FAA air traffic control system, the FBI virtual case file, the Navy Marine Corps Internet) ukázala jako hlavní příčinu právě vývoj podle tradiční rigorózní metodiky [8]. Hlavním kritickým faktorem úspěchu projektu je pak označován čas vývoje. Pokud je doba dodání systému splňujícího požadavky zadavatele delší než doba, za kterou se změní prostředí, ve kterém má být systém nasazen, není projekt zpravidla 2 projektem se bude dále v této práci myslet standardní dodávka ICT služby na základě smluvního vztahu mezi zadavatelem a dodavatelem; bez újmy na obecnosti se bere v úvahu dodávka od externího poskytovatele, nejedná se tedy o vývoj v rámci interního ICT útvaru 64 SYSTÉMOVÁ INTEGRACE 4/2010

3 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů úspěšný. Tento problém dále rozvádí práce [9], která se zabývá obchodními aspekty vývoje velkých komplexních systémů. Rigorózní metodiky podle ní mají problém v docílení win-win modelu, kdy zadavatel dostane přesně to, co potřebuje (což nutně nemusí být to, co na začátku požadoval) a současně dodavatel splní veškerá kritéria projektu. Naopak jedním z hlavních cílů agilních metodik je pružně reagovat na změnu požadavků zákazníka tak, aby se vyvíjený systém stal jeho konkurenční výhodou. Hlavním cílem tohoto článku je ukázat přínosy agilní metodiky Scrum oproti rigorózním metodikám při vývoji komplexních informačních systémů. Výhody této metodiky pro jisté typy projektů jsou dostatečně známé, ale naším cílem je vyvrátit často uváděná omezení pro nasazení této metodiky popsaná v [7]. Nejprve stručně popíšeme metodiku Scrum, provedeme analýzu často uváděných nedostatků a omezení pro nasazení této metodiky a následně navrhneme možné postupy, jak tato omezení překonat. Současně se pokusíme prokázat přínos nasazení metodiky Scrum při vývoji informačního systému, který má většinu uváděných omezení. K tomuto účelu využijeme případovou studii nasazení metodiky Scrum v průběhu vývoje komplexního systému. Jedná se o projekt nasazení Identity a Access managementu pro společnost Telefónica O2 Czech Republic, který řídí přístupy pro více jak zaměstnanců společnosti do desítek různých systémů. Projekt byl rozdělen do dvou hlavních fází, přičemž první byla řízena rigorózně a druhá pomocí metodiky Scrum, což umožňuje porovnat hlavní ukazatele projektu v jednotlivých fázích a prokázat úspěšnost nasazení metodiky Scrum. 2. Metodika Scrum Za zakladatele metodiky Scrum [3] jsou považováni K. Schwaber a J. Sutherland, kteří nezávisle na sobě využili principy této metodiky již v devadesátých letech minulého století. Současně jsou jedni z autorů agilního manifestu [4], ve kterém jsou definovány 4 základní hodnoty a 12 principů agilního vývoje. Manifest zní (přeloženo dle [2]): Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji, fungujícímu softwaru před podrobnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, reakci na změnu před plněním plánu. Na základě těchto hodnot vyvinuli Scrum, který je typickou agilní metodikou. Definuje pouze pár základních artefaktů a procesů, předává kompetence samotným členům vývojového týmu a neklade takový důraz na úplnou dokumentaci. Fungující software dodávaný v pravidelných krátkých intervalech, který je připravený k nasazení u zadavatele, je hlavním cílem této metodiky, což přesně naplňuje podstatu efektivního propojení ICT se strategií podniku. Spolupráce se zadavatelem je klíčová - Scrum je založen na win-win modelu, kdy změnové požadavky nejsou problémem, ale vítanou skutečností, která pomůže zadavateli v jeho konkurenčním prostředí. SYSTÉMOVÁ INTEGRACE 4/

4 Jakub Balada, Alena Buchalcevová 2.1 Proces vývoje podle metodiky Scrum Samotný proces vývoje je založený na iterativním modelu životního cyklu (obr. 1). Jednotlivé iterace se nazývají sprinty a mají vždy stejně dlouhou dobu trvání, typicky jeden měsíc. Výsledkem každého sprintu je otestovaný a hlavně nasaditelný přírůstek. V rámci každého sprintu se vyvíjejí požadavky (user stories), které jsou vydefinovány na začátku sprintu v tzv. sprint backlogu. Ten je podmnožinou product backlogu, což je kompletní soupis všech požadavků na vyvíjený software. Důležitá je prioritizace položek na product backlogu, podle které se vybírají úlohy do nejbližšího spritu, čímž je zajištěna včasná dodávka služeb, které zadavatel nejvíce potřebuje. Obr. 1: Scrum proces (zdroj: wikipedia.org) Každý den probíhá v přesně definovaný čas tzv. daily scrum, kdy se sejde kompletní vývojový tým a každý člen týmu zodpoví následující 3 otázky: Které úlohy jsem řešil předešlý den? Které úlohy budu řešit dnes? Jaké vidím omezení a překážky pro řešení svých úloh? Tato pravidelná schůzka, která by neměla přesáhnout 30 minut, napomáhá komunikaci v týmu a předchází možným problémům. Současně se této schůzky mohou zúčastnit lidé zodpovědní za projekt a mít tak přehled o stavu projektu na denní bázi. 2.2 Role v rámci metodiky Scrum Pro další část práce je potřeba popsat základní 3 role, které Scrum zavádí Product owner, Scrum master a tým. Product owner je nejdůležitější role během vývoje IS podle této metodiky. Paradoxně je velkou výhodou a ve většině případů nutností, aby tuto roli zastávala osoba od zadavatele. Zodpovědností product ownera je totiž správa product backlogu a především prioritizace jednotlivých user stories. Product owner tedy ovlivňuje výslednou podobu vyvíjeného IS a je za ní zodpovědný. Zde nacházíme velký rozdíl oproti vývoji podle rigorózní metodiky, kde je obsah dodávaného IS definován na začátku projektu a může být modifikován pouze na základě 66 SYSTÉMOVÁ INTEGRACE 4/2010

5 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů změnových požadavků. Ty většinou definují různě zainteresovaní lidé na straně zadavatele a nikdo je neporovnává mezi sebou a nemá za ně finální odpovědnost. Podle metodiky Scrum může product owner přijímat požadavky během celé doby vývoje, dávat jim prioritu a podle ní je zařazovat do product backlogu. Ten může, a měl by, před každým sprintem přeprioritizovat tak, aby vždy odpovídal aktuálním potřebám zadavatele. Důsledek tohoto procesu je neprázdný product backlog na konci projektu (který může teoreticky nastat na konci libovolného sprintu). Funkčnosti, které se takto neimplementují, mají nejmenší prioritu a zpravidla již nejsou v danou chvíli potřeba. Výsledný IS tedy vždy obsahuje funkčnosti, které mají pro zadavatele největší význam v daném čase, a naopak neobsahuje takové, které mu nepřinesou dostatečnou přidanou hodnotu vůči investovaným prostředkům. Scrum master je role zodpovědná za správnou adaptaci metodiky Scrum. Vede všechny důležité schůzky v rámci vývoje a především se snaží udržet ideální podmínky pro práci týmu. Neměl by se podílet na samotném vývoji ani určovat, kdo z týmu má vyvíjet jaké úlohy ze sprint backlogu. Jeho hlavním cílem je neustálá snaha o zlepšení procesu vývoje, k čemuž slouží především tzv. sprint retrospective meeting na konci každého sprintu. Na této schůzce, které se účastní všichni lidé zainteresovaní na vývoji, se probírají možné zlepšení vývojového procesu. Scrum není evoluční metodikou pouze ve smyslu životního cyklu vyvíjeného IS, ale také ve smyslu evoluce samotného procesu vývoje podle této metodiky. Což odpovídá 5. nejvyššímu stupni zralosti procesu vývoje IS podle CMMI. Tým je skupina ICT specialistů podílejících se na vývoji daného IS. Jelikož Scrum je opakem vodopádového modelu vývoje IS, musí být v týmu po celou dobu trvání projektu zastoupeny všechny potřebné role, jako jsou analytici, designéři, vývojáři, testeři a případně další. Všechny tyto činnosti je potřeba provést v každém sprintu pro všechny úlohy na aktuálním sprint backlogu. Tým vždy sám rozhoduje o tom, kolik požadavků z product backlogu převezme do nejbližšího sprintu a tím pádem sám ohodnocuje pracnost jednotlivých user stories. Současně tím přebírá odpovědnost za daný sprint a jeho dokončení v termínu, který je striktně nepřekročitelný. Pokud nastanou během sprintu problémy ohrožující jeho dokončení v termínu a kvalitě, položky s nejmenší prioritou jsou přesunuty do dalšího sprintu. Z toho plyne důležitá vlastnost vývoje podle Scrumu, totiž že ze základních čtyř kritérií řízení projektů kvalita, kvantita, termín, rozpočet může být jedině kvantita potencionálně nesplněná. Podrobnější popis metodiky Scrum, především doporučený sled a obsah jednotlivých kroků v rámci sprintu je popsán v [3]. 3. Využití metodiky Scrum pro vývoj komplexních IS Metodika Scrum popsaná výše je již celosvětově hojně využívána při vývoji menších IS v týmech do 10 vývojářů [6]. Jako její největší přínosy respondenti uvádějí větší možnost řídit změnové požadavky, lepší monitorování stavu projektu a efektivnější provázání IT s cíli podniku. Nicméně ani stále masovější využití pro projekty vyvíjené menšími týmy a prokazatelně větší úspěšnost tohoto přístupu [6] nevede k adaptaci této metodiky pro vývoj velkých komplexních IS. Zastánci SYSTÉMOVÁ INTEGRACE 4/

6 Jakub Balada, Alena Buchalcevová tradičních rigorózních metodik často uvádějí podmínky a omezení pro vývoj podle agilních principů [2] [7]. V další části této práce je snahou autora komentovat uváděné podmínky, které musí být splněny pro možný vývoj pomocí agilních metodik 3 a dále analyzovat uváděné omezení v nasazení Scrumu s návrhem řešení těchto problémů. 3.1 Nutné podmínky pro nasazení Scrumu V [7] je uvedeno celkem 11 podmínek, které musí být podle autorů splněny k tomu, aby mělo význam využít agilní přístup: 1. Zadavatel úzce spolupracuje s vývojáři a je v případě potřeby k dispozici. Současně face-to-face komunikace vyžaduje umístění vývojářů na jednom místě. Zapojení zadavatele do vývoje je opravdu velice důležité, nicméně může být redukováno na 3 schůzky během sprintu. To znamená přibližně 3 hodiny času klíčových osob zadavatele měsíčně. Nutnost umístění vývojářů na jednom místě bude diskutována dále v textu při řešení distribuovaného vývoje. 2. Dokumentace a modely nehrají při vývoji klíčovou roli. Scrum je zaměřen na pravidelné dodávání nasaditelného SW na konci každého sprintu počínaje prvním (což nemusí být pravidlem, někdy se uvádí tzv. sprint 0 bez nasaditelného výstupu). Vychází se z úvahy, že předveditelný a použitelný SW je názornější než obsáhlá dokumentace a modely, které se právě snaží popsat budoucí podobu výsledného díla. 3. Požadavky a prostředí se v průběhu vývoje mění. Toto považujeme nikoliv za podmínku, nýbrž pravidlo aktuálního stavu vývoje IS. Navíc i v případě přesně vyspecifikovaných požadavků bez změn a ve stálém prostředí je výhoda Scrumu v jejich prioritizaci pří vývoji a následném pravidelném nasazování. 4. Přizpůsobování procesu vývoje vede k vyšší kvalitě dodávaného IS. Scrum je evoluční metodika, při které nemusejí být přesně aplikovány veškeré procesy. Podle názoru autorů nemusí být jediným cílem optimalizace procesu vývoje vyšší kvalita dodávaného IS, ale také například vyšší velocity (počet user stories implementovaných během sprintu). 5. Vývojáři mají zkušenosti potřebné k přizpůsobování procesů. Pravdou je, že Scrum počítá se zkušenými členy týmu, kterým dává větší práva a odpovědnosti. Nicméně tato práva a odpovědnosti jsou vždy na týmu jako celku. Navíc se i v rámci Scrumu využívají praktiky z XP jako párové programování, které kromě automatické kontroly kódu přináší i výhodu jednoduššího začlenění nováčků. 6. Viditelnost do procesu a samotného stavu projektu je pouze při ukončení přírůstku a na základě několika metrik. Scrum disponuje několika metrikami, které ukazují stav sprintu i celého projektu v reálném čase. Navíc proces rozpadu user stories na jednotlivé úlohy, které si vývojáři 3 dále bude v práci rozebírána pouze metodika Scrum jako nejvyužívanější agilní metodika 68 SYSTÉMOVÁ INTEGRACE 4/2010

7 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů sami vybírají a implicitně informují o jejich stavu na denní bázi, vede k možnosti sledování stavu sprintu v reálném čase. 7. Hodnocení vyvíjeného IS a samotného procesu vývoje je neformální. Na konci každého sprintu probíhá prezentace aktuálně vyvinutých funkčností včetně možnosti akceptačních testů. Pokud zadavatel postupně nasazuje jednotlivé iterace do svého prostředí, hodnocení vyvíjeného IS je na všech zainteresovaných uživatelích. Hodnocení optimalizace samotného procesu vývoje je především na týmu v rámci sprint retrospective meeting na konci každého sprintu. 8. Cílem není znovupoužitelné řešení. Metodika Scrum je taktéž využívána pro vývoj produktů, dokonce i mimo ICT [12]. Díky prioritizaci požadavků se většinou nedostane na ty, které mají nejmenší využití, a tím je dosaženo vysoké přidané hodnoty výsledného produktu, který může být nasazen u více zákazníků. 9. Náklady na změny se v průběhu projektu dramaticky nezvyšují. Opět díky priorotizaci je zajištěna dodávka služeb v pořadí podle potřeb zadavatele. Pokud je potřeba změna v již implementované funkcionalitě, zjistí se to daleko dříve než v klasickém přístupu a není potřeba měnit větší část kódu. 10. Software může být vyvíjen přírůstkově. Podle autorů je možné jakýkoliv vyvíjený SW implementovat postupně v iteracích. Navíc Scrum nerozděluje SW podle architektury, nýbrž podle funkčních požadavků. Pokud není možné dodat fungující část IS na konci prvního sprintu, je snaha předat alespoň funkční prototyp. 11. Refaktoring je dostatečná metoda pro úpravy kódu. Scrum využívá pro jakoukoliv úpravu kódu, která nepřináší nové funkčnosti právě refaktoringu. Jedná se o jeden ze základních principů agilního vývoje, který napomáhá udržovat kód jednoduchý a bezchybný. Jiné způsoby úpravy většinou vedou ke složitému a nečitelnému kódu. Jak plyne z komentářů k výše uvedeným podmínkám k zavedení Scrumu, autoři nejsou přesvědčeni, že jejich splnění je potřebné pro zavedení této metodiky. Navíc některé z těchto nutných podmínek jsou v dnešním prostředí spíše pravidlem. 3.2 Základní parametry případové studie Než budou dále navržena řešení udávaných omezení v nasazení Scrumu, je potřeba uvést základní parametry projektu, na kterém bude prezentován přínos této metodiky. Jedná se o projekt implementace Identity a Access Managementu pro společnost Telefónica O2 Czech Republic vyvíjený společností Siemens IT Solutions and Services (SIS). Jeden z autorů zastával na projektu funkci solution architekta a ve druhé fázi taktéž scrum mastera zodpovědného za adaptaci metodiky Scrum. Projekt spočíval v nasazení a customizaci řady produktů DirX, které jsou vyvíjeny mateřskou společností v Německu. Cílem řešení je správa všech zaměstnanců společnosti (cca ) a jejich účtů do většiny informačních systémů ve společnosti. Hlavní výhody výsledného řešení jsou zkrácená doba zřizování přístupů pro zaměstnance, úspora práce administrátorů automatickým vytvářením SYSTÉMOVÁ INTEGRACE 4/

8 Jakub Balada, Alena Buchalcevová a rušením účtů v nejdůležitějších IS, centralizovaná správa uživatelů a jejich práv a v neposlední řadě zvýšení bezpečnosti včetně úspěšného splnění SOX auditu. Na straně dodavatele se na projektu podílely tři strany. SIS jako hlavní dodavatel, SIS Německo jako dodavatel základních produktů a Orchitech Solutions jako subdodavatel zodpovědný za uživatelskou aplikaci integrovanou do intranetu zadavatele. Sponzorem projektu na straně zadavatele bylo oddělení IT bezpečnosti. Nicméně velká část požadavků vzešla z oddělení IT provozu, které je hlavním uživatelem systému a v neposlední řadě z oddělení businessu. Jak se během projektu ukázalo, požadavky od těchto tří stran byly dosti odlišné, někdy dokonce protichůdné. Detailní specifikace požadavků, která byla přílohou smlouvy, obsahovala na 130 různých požadavků. Projekt byl rozdělen do dvou hlavních fází. První z nich začala v září 2008 a měla trvat 12 měsíců. Jejím cílem byla první verze řešení, která se měla nasadit do produkčního prostředí. Následná druhá fáze měla trvat 5 měsíců, jejím cílem bylo připojení dalších IS společnosti, jak bylo požadováno ve specifikaci. Projekt měl být tedy ukončen v únoru 2010 úspěšným nasazením druhé fáze. Od začátku projektu byla první fáze řízena standardní rigorózní metodikou, tedy během prvních 3 měsíců byly prováděny analytické schůzky s výsledným obsáhlým dokumentem popisujícím detailní design první části a stručnější design části druhé. Následovala implementace s několika kontrolními termíny pro ukázku klíčových částí řešení. Přesně podle plánu - měsíc před ukončením první fáze - bylo řešení předáno k akceptačním testům. Nicméně tyto testy odhalily velkou řadu nepochopení ve specifikaci, přestože byl předem schválen detailní design. Tyto problémy vedly k prodloužení akceptačních testů a následnému stabilizačnímu provozu. Fáze 1 byla oficiálně akceptována na konci roku 2009 se čtyřměsíčním zpožděním následována dvěmi sadami změnových požadavků. Po těchto zkušenostech zadal řídící výbor projektovému týmu úkol analyzovat příčiny nesplnění termínů a nutnosti navýšení nákladů na změnové požadavky a navrhnout taková opatření, která povedou k úspěšné realizaci druhé fáze projektu. Na základě doporučení dodavatele byla za tímto účelem schválena změna metodiky vývoje a pro druhou fázi projektu byla vybrána metodika Scrum. Tento krok vedl k úspěšné implementaci druhé části řešení ve čtyřech měsíčních sprintech, které probíhaly od června do září roku Tato fáze byla nakonec akceptována v říjnu 2010 s osmidenním zpožděním. Postup přizpůsobení metodiky Scrum a její výhody budou popsány dále. 3.3 Jak řešit deklarovaná omezení pro nasazení metodiky Scrum V této podkapitole probereme nejdůležitější omezení pro nasazení metodiky Scrum, která jsou popisována v [2] a [7], a která prozatím brání využívání Scrumu pro vývoj komplexních IS. K tomuto účelu bude taktéž využita případová studie popsaná výše Vývoj v distribuovaném prostředí Při vývoji velkých komplexních systémů se distribuovanému prostředí nelze ve většině případů vyhnout. V takovém případě již bohužel nestačí základní tabule 70 SYSTÉMOVÁ INTEGRACE 4/2010

9 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů s rozdělenými úlohami ve sprintu podle jejich stavu a burndown graf pro aktuální přehled o stavu vývoje. Je nutné zvolit některý z produktů umožňující efektivní komunikaci v rámci týmu. Existují specializované produkty se šablonami přímo pro vývoj podle Scrumu (Jira, IBM Rational Team Concert apod.), nicméně na našem projektu se osvědčil jednoduchý nástroj Trac, primárně využívaný jako bug tracing system. Nevyužívali jsme jej jen na evidenci a sledování stavu jednotlivých hlášených chyb, ale také jsme pomocí něj řídili jednotlivé úlohy v rámci sprintu. Současně byl využit i modul wiki jako základní zdroj informací o projektu včetně nejdůležitějších architektonických návrhů. Každý člen týmu tak měl možnost sledovat aktuálně řešené úlohy a případně přidělovat svoje části na dočasnou dobu na jiného člena právě přes tento systém, i když spolu nebyli v jedné místnosti. Další problematickou oblastí v distribuovaném prostředí jsou daily scrums. Tyto schůzky jsou velice důležité a je potřeba je provádět za jakýchkoliv okolností. Pokud není možné zajistit účast všech členů týmu na jednom místě, přicházejí na řadu moderní telekomunikační prostředky. V našem případě se osvědčil komunikační nástroj Skype, přes který byli připojeni členové týmu z jiných lokací. Důležité je dodržovat maximální dobu schůzky, což je v tomto případě složitější. Navíc je problematičtější udržet koncentraci všech členů po celou dobu schůzky. Za tímto účelem je vhodné dodržovat doporučované pravidlo, kdy všichni účastníci mají po celou dobu schůzky stát, i když jsou sami připojeni vzdáleně. Při tomto režimu je omezena jiná práce zúčastněných, kteří se koncentrují pouze na zodpovězení 3 otázek a zbytečně tak neprodlužují celou schůzku. Důležité je také vhodné sladění pravidelného času schůzky. V ideálním případě by měla začínat vždy na začátku pracovního dne, což může být z globálního hlediska problém. V tomto případě musejí členové z lokalit, které mají větší časový posun upravit denní režim tak, aby jejich denní práce v pojetí Scrumu začínala v čas daily scrums Využití subdodavatelů Subdodavatelé musí v případě využití Scrumu taktéž adaptovat tuto metodiku. Toto je nutná podmínka, která ovšem nevylučuje využití subdodavatelů obecně. V našem případě reprezentoval subdodavatel samostatný Scrum tým, který pracoval paralelně na stejných user stories v rámci sprintu jako hlavní dodavatelský tým. Subdodavatel by měl mít svého vlastního Scrum mastera dohlížejícího na jejich vlastní proces vývoje. Důležité je vhodně rozšířit povinnosti subdodavatele v back-to-back smlouvě, která se standardně uzavírá, za účelem dodržování všech procesů v rámci sprintu, aby nebyl ohrožen jeho průběh. Další důležitou oblastí je oceňování jednotlivých user stories a jejich rozpad na jednotlivé úlohy mezi subdodavatele. Každý sprint by měl mít stejnou velocity, která musí být v tomto případě rozdělena na jednotlivé dodavatele. Problém může nastat v případě, kdy se v daném sprint backlogu nacházejí úlohy, na kterých není zainteresován subdodavatel v očekávaném rozsahu. Ideálním řešením je možnost dynamicky alokovat množství zdrojů subdodavatele v jednotlivých sprintech, aby nebyl ohrožen výběr user stories do sprint backlogu podle priorit Vývoj znovupoužitelných produktů Hlavním cílem Scrumu je dodávat služby aktuálně požadované zadavatelem. Proto je jeho hlavní přínos u zakázkového vývoje IS. Nicméně Scrum se osvědčil i u SYSTÉMOVÁ INTEGRACE 4/

10 Jakub Balada, Alena Buchalcevová produktového vývoje, například samotný vývoj DirX produktů společnosti Siemens je založen na této metodice. V takovém případě je product owner hlavní osobou zodpovědnou za vývoj produktu a jeho funkčností. Velice důležitou oblastí je přijímání požadavků na nové funkcionality, které se přidávají do product backlogu a poté do sprint backlogu. Pokud je produkt již nasazen u zákazníků, většina nových požadavků přichází z jejich strany. Všechny tyto požadavky jsou přidány do product backlogu, který musí být před každým sprintem přeprioritizován. U produktového vývoje hraje velkou roli určování priorit daných požadavků, kde hlavním kritériem je počet zákazníků, kteří požadují danou funkcionalitu. Na tomto základě musí product owner rozhodnout, zda se jedná o relevantní požadavek na produkt a bude začleněn do vývoje v rámci dalšího sprintu, nebo zdali jde o tzv. project specific functionality. V tomto případě může být funkčnost vyvinuta, ale není začleněna do samotného produktu. Stinnou stránkou produktového vývoje je nemožnost vytvoření definitivní road mapy produktu v delším horizontu, jelikož se může každý měsíc měnit. To ale na druhou stranu dává produktu větší šanci uspět v konkurenčním prostředí Vývoj ve velkých týmech Maximální doporučovanou velikostí jednoho Scrum týmu je 10 členů. Pokud se na vývoji podílí více osob, musejí být rozděleni do více týmů. Jednou ze základních technik je tzv. Scrum of Scrums [3] (obr. 2). Jednotlivé týmy mají každý svého Scrum mastera a dodržují standardní Scrum proces v rámci sprintu. Po daily scrums, které provádí každý tým zvlášť, následuje daily Scrum of Scrums. Této schůzky, která má stejný formát jako základní daily scrum, se účastní zástupci jednotlivých týmů. Odpovědi na základní otázky jsou vztažené na tým, který zastupují. Vyslaní zástupci nejsou zpravidla Scrum masteři, ti se schůzky účastní, pokud počet zúčastněných nepřesáhne 10. Scrum of Scrums schůzek se většinou účastní zástupci, kteří potřebují aktuálně řešit případné závislosti mezi jednotlivými úlohami. Na začátku sprintu jsou to převážně designéři, na konci naopak testeři. Obr. 2: Scrum of Scrums (zdroj: [9]) 72 SYSTÉMOVÁ INTEGRACE 4/2010

11 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů Délka této schůzky by taktéž neměla přesáhnout 30 minut, ale narozdíl od daily scrums je potřeba vyhradit čas i na případné řešení vzniklých problémů. Současně každý Scrum of Scrums musí mít vlastního Scrum mastera, který zodpovídá za speciální backlog odpovídající issue listu na tradičně vedených projektech. Pokud je na projektu potřeba více Scrum of Scrums (vývoje se účastní více jak 100 osob), analogicky se vytvoří další stupeň, ve kterém je zástupce každého týmu nižšího stupně. To už většinou bývá samotný řídící výbor projektu Vývoj kritických systémů Vývoj systémů, na kterých může záviset lidský život, vyžaduje některé speciální praktiky. V těchto případech musí být vývoj podle Scrumu obohacen například o formální specifikaci a následnou formální verifikaci při akceptačních testech. To, v čem je Scrum přínosem u těchto typů systémů, jsou některé jeho základní agilní praktiky. Zejména test-first přístup nutí programátory nejprve napsat jednotkové testy a teprve následně začít implementovat danou funkčnost. Tento přístup odhaluje případné chyby daleko dříve a především nedává programátorům prostor nevědomky měnit přesnou specifikaci požadavku během vývoje. Programátor nejprve musí napsat test přesně odpovídající specifikaci funkčnosti a poté vyvíjet kód, dokud neprojde daným testem. Další významnou praktikou která přináší výhody při vývoji těchto typů systémů je již zmiňované párové programování, kdy druhý vývojář ve dvojici kontroluje kód, který jeho kolega zrovna vytváří Vývoj velkých komplexních systémů Možnost vývoje ve velkých případně i distribuovaných týmech byla popsána výše. Dalším často uváděným problémem pro vývoj komplexních systémů pomocí Scrumu je architektura řešení [13] [14]. Ve Scrumu, na rozdíl od rigorózních metodik, není prostor pro detailní návrh celkové architektury před zahájením implementace. Nicméně, jak je diskutováno v [13], i architektura velkých projektů může být navrhována postupně tak, jak se řeší jednotlivé požadavky. Pouze je kladen velký důraz na zkušené architekty. Pro základní návrh architektury řešení slouží sprint 0, ve kterém musí hlavní architekti definovat architektonický základ řešení. Důležité je, že nevytváří prostředí pro splnění všech požadavků na product backlogu, ale pouze těch nejzákladnějších. Cílem je zbytečně nevytvářet design a nutné prostředky pro požadavky, o kterých není jisté, že se budou v budoucnu implementovat. Architekti musí být dále součástí týmu, i když nemusí být využita veškerá jejich kapacita. Detailní analýza a design všech user stories ve sprintu jsou provedeny během prvních dvou dní daného sprintu. Při vývoji pomocí většího počtu Scrum týmů je vhodné provádět pravidelné schůzky architektů z každého týmu, kteří utvoří vlastní Scrum tým. Zejména při fázi plánování sprintu a během jeho úvodu je potřeba řešit globální architekturu nových funkčností a vazby mezi nimi. 3.4 Proces zavedení a přínosy nasazení Scrumu Případová studie popsaná výše vykazuje většinu omezení v nasazení Scrumu diskutovaných v předchozích kapitolách. Na tomto místě bude popsán proces SYSTÉMOVÁ INTEGRACE 4/

12 Jakub Balada, Alena Buchalcevová přechodu z rigorózního způsobu řízení první fáze projektu na metodiku Scrum využitou v druhé fázi a důsledky tohoto kroku. Mezi hlavní argumenty dodavatele, díky kterým řídící výbor schválil nasazení metodiky Scrum pro vývoj druhé fáze projektu, patřilo velké množství změnových požadavků během vývoje, neplnění termínů v první fázi, lepší viditelnost do stavu projektu, možnost nasazovat nové funkčnosti po jednotlivých měsících a především prokazatelné nevyužívání některých funkčností, které byly implementované v první fázi. Tento poslední bod je obecný problém, který Scrum pomáhá eliminovat. Podle Chaos Reportu 2009, který vydává The Standish Group, 50% implementovaných funkčností není nikdy použito. Je to dáno tradičním přístupem, kdy zadavatel musí na začátku projektu vyspecifikovat veškeré požadavky včetně tzv. nice to have. První fáze projektu byla definitivně ukončena v dubnu roku 2010 akceptací dvou sad změnových požadavků, nasazením řešení do produkčního prostředí zadavatele a zkušebním provozem. Tedy celých 7 měsíců po plánovaném termínu. Následovat měla druhá fáze projektu, jejíž požadavky byly podmnožinou původní detailní specifikace projektu. Jelikož projekt byl do této doby vyvíjen pomocí rigorózní metodiky, byl již vypracován hrubý design řešení, které se mělo implementovat ve druhé etapě projektu. Projekt byl od začátku smluvně dojednán jako tzv. fix-time, fix-prize, tudíž veškeré úlohy pro druhou fázi již byly v rámci nabídky a pozdější analýzy a designu ohodnoceny v člověkodnech. Řídící výbor souhlasil s dohodou, díky které se mohl obsah řešení druhé fáze projektu měnit podle aktuální potřeby zadavatele. Termín a cena zůstaly zachovány. Prvním krokem přechodu z rigorózní metodiky na Scrum je úvodní naplnění product backlogu. V našem případě se jednalo o sadu požadavků z původní specifikace druhé fáze, které byly upraveny do formy user stories. Současně již měly uvedenu časovou náročnost v člověkodnech, která ovšem byla definována na začátku projektu a v některých případech již neodpovídala získaným zkušenostem během první fáze. Nicméně vydělením pracnosti celé fáze projektu čtyřmi měsíčními sprinty nám vyšla úvodní velocity jednoho sprintu. Dále bylo nutné prioritizovat úvodní backlog pro výběr úloh pro první sprint. Tento krok byl velmi komplikovaný, jelikož byl problém definovat product ownera na straně zadavatele. Jeden z autorů, který zastával roli Scrum mastera, striktně požadoval nominování jedné osoby ze strany dodavatele. Nakonec se tuto pozici podařilo obsadit externím zaměstnancem zadavatele, který do této doby zastával funkci projektového vedoucího se zkušenostmi s vývojem tohoto typu IS. Product owner sestavil funkci vypočítávající prioritu jednotlivých user stories na základě jejich přínosu pro podnikové cíle podle jednotlivých zainteresovaných oddělení (business, bezpečnost, provoz). Pomocí této funkce prioritizoval všechny nově přicházející požadavky během celé fáze vývoje. Jednotlivé sprinty trvaly kalendářní měsíc s tím, že v posledním týdnu probíhaly akceptační testy zadavatele. Tudíž pro samotný vývoj zbývalo průměrně 16 dní. Během akceptačních testů již tým připravoval další sprint. Zejména se jednalo o kvotaci nových požadavků a analytické schůzky za účelem přípravy designu řešení nových úloh. První dva dny sprintu probíhaly verifikační schůzky nad úlohami pro daný sprint, po kterých již byl uzavřen design celého sprintu. Po této verifikaci již zadavatel striktně nesměl měnit zadání úloh v daném sprintu. Pokud takováto situace nastala, přidala se požadovaná změna na product backlog a pokud měla dostatečnou prioritu, byla zahrnuta do následujícího sprintu. První den týdne akceptačních testů byla provedena prezentace nových funkčností (sprint review) a 74 SYSTÉMOVÁ INTEGRACE 4/2010

13 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů oficiálně zahájeny testy podle testovacích scénářů definovaných na začátku sprintu po verifikačních schůzkách. Pouze jednou za všechny 4 sprinty nedošlo k nasazení přírůstku v první pravidelné odstávce systému po týdnu akceptačních testů. Důvodem byl nadměrný počet reportovaných chyb, který vedl k týdennímu zpoždění nasazení nové verze. Nicméně další sprint probíhal paralelně v definovaných termínech. Jelikož současně s vývojem druhé fáze již byl systém využíván v produkčním prostředí, případné malé množství drobných chyb z testů bylo řešeno standardním problem managementem na projektu a nebránilo nasazení nové verze do produkčního prostředí. Poslední čtvrtý sprint byl akceptován v říjnu roku 2010 s osmidenním zpožděním a po zkušebním a ověřovacím provozu kompletní druhé fáze byl projekt oficiálně akceptován a ukončen v listopadu téhož roku. Projekt byl i přes neplnění termínů v jeho první fázi označen jako úspěšný a nyní probíhá jeho další rozvoj. Největším přínosem nasazení Scrumu na tomto projektu byla jednoznačně možnost definovat obsah měsíčních sprintů před jejich zahájením. Z původní specifikace druhé fáze bylo po čtyřech sprintech implementováno méně než 40% požadavků. Zbývajících 60% nahradily nově vzniklé požadavky během vývoje. Na začátku druhé fáze byl domluven postup výměny úloh na product backlogu v případě nového požadavku, kdy byl vypuštěn jiný požadavek stejné pracnosti s nejnižší prioritou. Postupem času již zadavatel uznal možnost neprázdného product backlogu na konci posledního sprintu a již pouze přidával nově požadované funkčnosti. Základem byla domluvená velocity jednotlivých sprintů vypočítaná podle původní smlouvy. Neoficiálně tedy došlo ke změně smluvního vztahu z fix-time, fix-prize smlouvy o dílo na smlouvu o dodávce jednotlivých přírůstků za fixní cenu s obsahem definovaným na jejich začátku. Nezanedbatelný je na tomto principu i přínos pro dodavatele ve smyslu fakturací po jednotlivých měsících, což má kladný vliv na cashflow. Nutnou podmínkou tohoto režimu je vzájemná důvěra mezi zadavatelem a dodavatelem přinejmenším kvůli akceptaci odhadnutých kvotací nových úloh. Dalším již zmiňovaným přínosem je splnění termínu druhé fáze projektu, čemuž nejvíce napomohlo průběžné akceptování a nasazování jednotlivých sprintů do produkčního prostředí ihned po jejich implementaci. Nikdy nebyl posunut termín prezentace nových funkčností v rámci sprintu, pouze jednou se nestihly implementovat veškeré úlohy na sprint backlogu a 2 s nejmenší prioritou byly přesunuty do dalšího sprintu, kde byly implementovány bez fakturace. Kvalita dodaného IS je těžko porovnatelná mezi oběmi fázemi, množství reportovaných chyb z akceptačních testů je srovnatelné. Nicméně Scrum napomohl k jejich identifikaci daleko dříve než při klasickém vývoji a oprava chyby tak nebyla natolik náročná vzhledem k integraci s dalšími částmi řešení. Ke stejnému závěru dospěla i studie [11] zaměřující se na porovnání kvality vyvíjeného SW mezi rigorózním přístupem a využitím Scrumu. 4. Závěr Projekty vývoje informačních systémů stále vykazují nízkou úspěšnost. Agilní metodiky se s úspěchem používají při vývoji menších systémů v malých týmech, nicméně převážná část IT společností nadále odmítá jejich zavedení u velkých SYSTÉMOVÁ INTEGRACE 4/

14 Jakub Balada, Alena Buchalcevová komplexních projektů. Tento článek komentuje omezení pro nasazení agilních metodik, které nalezneme v literatuře, analyzuje je a navrhuje postupy, jak je překonat. Současně ukazuje přínosy nasazení metodiky Scrum na reálném komplexním projektu systémové integrace, což je v rozporu s dosud uváděnými omezeními této metodiky. Projekt byl vyhodnocen jako úspěšný právě díky nasazení Scrumu během jeho vývoje. Tento krok přispěl k plnění jednotlivých termínů projektu, rychlejším opravám reportovaných chyb a zejména k implementaci funkčností, které zadavateli přinesly větší přidanou hodnotu. Díky navrženým postupům adaptace Scrumu při vývoji velkých projektů ukazuje článek širší možnosti využití této metodiky, což může do budoucna napomoci k jejímu masovějšímu využití a na základě toho dosažení vyšší úspěšnosti projektů vývoje informačních systémů. Tento stav by vedl k efektivnějšímu propojení ICT s podnikovou strategií, zejména díky flexibilní dodávce aktuálně potřebných ICT služeb. Literatura [1] Voříšek Jiří. Principy a modely řízení podnikové informatiky. Praha : Oeconomica, s. ISBN [2] Buchalcevová Alena. Metodiky budování informačních systémů. 1. vyd. Praha : Oeconomica, s. ISBN [3] Schwaber, K., Beedle, M. Agile Software Development with SCRUM. Prentice Hall, ISBN [4] Beck K. et al. Manifesto for Agile Software Development [cit ]. Dostupný z WWW <http://agilemanifesto.org/>. [5] Buchalcevová A., Leitl M.: Průzkum používání agilních metodik v ČR. In Objekty Praha : PEF ČZU, 2006, s ISBN [6] The State of Agile Development Survey. VersionOne [cit ]. Dostupný z WWW development_survey_results.pdf>. [7] Dan Turk, Robert France, Bernhard Rumpe. Limitations of agile software processes. In Proc. of the 3th International Conference on extreme Programming and Agile Processes in Software Engineering Pages [8] Peter J. Denning, Chris Gunderson, Rick Hayes-Roth. The profession of IT: Evolutionary System Development. Communications of the ACM, December Volume 51, Issue 12, Pages: [9] Oualid Ktata, Ghislain Lévesque. Agile development: issues and avenues requiring a substantial enhancement of the business perspective in large projects. Proceedings of the 2nd Canadian Conference on Computer Science and Software Engineering Pages ISBN [10] Michael Budwig, Soojin Jeong, Kuldeep Kelkar. When user experience met agile: a case study. Proceedings of the 27th international conference 76 SYSTÉMOVÁ INTEGRACE 4/2010

15 Přínosy nasazení metodiky Scrum pro vývoj komplexních informačních systémů tended abstracts on Human factors in computing systems Pages ISBN: [11] Jingyue Li, Nils B. Moe, Tore Dybå. Transition from a Plan-Driven Process to Scrum A Longitudinal Case Study on Software Quality. Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement Article No. 13. ISBN [12] Martin Glas, Sven Ziemer. Challenges for agile development of large systems in the aviation industry. Proceeding of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and pplications Pages ISBN: [13] Dennis Mancl, Steven Fraser, Bill Opdyke, Ethan Hadar, Irit Hadar. Architecture in an agile world. Proceeding of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications Pages ISBN: [14] Philippe Kruchten. Software architecture and agile software development: a clash of two cultures? Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume Pages ISBN: SYSTÉMOVÁ INTEGRACE 4/

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

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

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

Agile Software Development

Agile Software Development Agile Software Development Agile Software Development Jiri Fabian www.jirifabian.net O čem to bude O metodologiích RUP Agile XP Scrum Co je softwarový vývoj Umění? Manufaktura? Modelování? Co je softwarový

Více

Jak vytvořit správné Zadání IS

Jak vytvořit správné Zadání IS Jak vytvořit správné Zadání IS 26. dubna 2013 Jiří Svačina Jiří Svačina Unicorn Systems, Senior Consultant Unicorn, 1993 Vývoj Softwarová architektura Projektové řízení Business analýza Univerzita Hradec

Více

Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás

Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás Motivace Vybrali jsme nový webový framework a potřebovali ho ověřit na reálné aplikaci

Více

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc Seminární práce Vývoj informačního systému Manažerská informatika 2 Ing. Miroslav Lorenc Vypracoval: Jan Vít (xvitj17) LS 2007/2008 1. ÚVOD...3 1.1. POPIS PROJEKTU...3 2. OBSAH PROJEKTU...3 2.1. SEZNAM

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

Manažerská informatika - projektové řízení

Manažerská informatika - projektové řízení VŠE, fakulta Podnikohospodářská Manažerská informatika - projektové řízení Projekt implementace informačního systému Jiří Mikloš 2009 Obsah Obsah Obsah... 2 Úvod... 3 Zadání... 4 Projektový postup... 5

Více

Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of

Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of Association for the advancement of Cost Engineering International (AACE) Australian Institute of Project Management (AIPM) English Association of Project Managers (APM) Association for Project Management

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

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

BI-TIS Případová studie

BI-TIS Případová studie Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti BI-TIS Případová Cvičení č. 2 Ing. Pavel Náplava naplava@fel.cvut.cz Katedra softwarového inženýrství, ČVUT FIT, 18102 Centrum znalostního

Více

Životní cyklus produktu (IS / IT služby) Životní cyklus projektu Životní cyklus řízení projektu. Vývoje produktu Implementace produktu

Životní cyklus produktu (IS / IT služby) Životní cyklus projektu Životní cyklus řízení projektu. Vývoje produktu Implementace produktu Životní cykly Životní cyklus produktu (IS / IT služby) Životní cyklus projektu Životní cyklus řízení projektu Vývoje produktu Implementace produktu 1. Identifikace problému potřeba nového systému/služby

Více

Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci

Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci Charta projektu úplné znění pro MŠMT a jeho příspěvkové organizace a Českou školní inspekci 1 Obsah Manažerské Shrnutí... 3 Definice projektu rámcová část... 3 Stručný kontext realizace projektu... 3 Cíle

Více

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2010 Tieto Corporation Agile nejžádanější způsob vývoje software Tomáš Tureček Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2012 Tieto Corporation Tieto Aktivity ve více než 20

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

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

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

Ing. Pavel Rosenlacher

Ing. Pavel Rosenlacher Marketing v sociálních sítích Webová analytika Ing. Pavel Rosenlacher pavel.rosenlacher@vsfs.cz Krátké shrnutí SEO spočívá v lepším zobrazování stránek ve výsledcích vyhledávání na vyhledávačích Souhrnně

Více

Testing as a Service. Přístupné, flexibilní a cenově výhodné řešení pro ověření kvality softwaru. Kompletní portfolio služeb testování softwaru

Testing as a Service. Přístupné, flexibilní a cenově výhodné řešení pro ověření kvality softwaru. Kompletní portfolio služeb testování softwaru Testing as a Service Přístupné, flexibilní a cenově výhodné řešení pro ověření kvality softwaru Kompletní portfolio služeb testování softwaru Předem známé náklady na testování, umožňující efektivní tvorbu

Více

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme Smysl metodiky IS/IT Koncentrovaná zkušenost Checklist na nic nezapomeneme Přínosy metodik Větší produktivita a kooperace týmů Komunikační standard Specializace projektových týmů Nezávislost na konkrétních

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

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS Roman Danel VŠB TU Ostrava HGF Institut ekonomiky a systémů řízení Literatura Staníček, Z, - Hajkr, J.: Řízení projektů zavádění IS do organizací.

Více

EXIN Agile Scrum Foundation Příručka ke zkoušce. Vydání

EXIN Agile Scrum Foundation Příručka ke zkoušce. Vydání EXIN Agile Scrum Foundation Příručka ke zkoušce Vydání 201608 Copyright 2016 EXIN Všechna práva vyhrazena. Žádná část této publikace nesmí být zveřejněna, reprodukována, kopírována nebo uložena v systému

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Slovenská spořitelna:

Slovenská spořitelna: Případová studie Slovenská spořitelna: Microsoft Dynamics CRM pro správu klientů ze segmentu malých a středních podniků Jak jsme Slovenské spořitelně usnadnily a zefektivnily práci s klienty ze segmentu

Více

Metodologie řízení projektů

Metodologie řízení projektů Metodologie řízení projektů Petr Smetana Vedoucí práce PhDr. Milan Novák, Ph.D. Školní rok: 2008-09 Abstrakt Metodologie řízení projektů se zabývá studiem způsobů řešení problémů a hledání odpovědí v rámci

Více

Operační program Lidské zdroje a zaměstnanost

Operační program Lidské zdroje a zaměstnanost Operační program Lidské zdroje a zaměstnanost EDUCA Profesní vzdělávání zaměstnanců společnosti T-MAPY spol. s r.o. 2010-2012 únor 2010 - leden 2012 Charakteristika projektu Projekt je zaměřen na prohloubení

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

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

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha,

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, Řízení projektů Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, 6. 12. 2012 Představení Zpracovatel: SOFO Group a.s. Ovocný trh 572/11 Praha 1 Projektový tým zpracovatele:

Více

Případová studie. SAM Assessment ušetřil AAA Auto 30 % nákladů na nákup licencí a zkrátil proces implementace nových aplikací a SW na desetinu

Případová studie. SAM Assessment ušetřil AAA Auto 30 % nákladů na nákup licencí a zkrátil proces implementace nových aplikací a SW na desetinu Případová studie SAM Assessment ušetřil AAA Auto 30 % nákladů na nákup licencí a zkrátil proces implementace nových aplikací a SW na desetinu www.microsoft.cz/pripadovestudie Přehled Země: Česká republika

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

Jan Hřídel Regional Sales Manager - Public Administration

Jan Hřídel Regional Sales Manager - Public Administration Podpora kvality ICT ve veřejné správě pohledem Telefónica O2 4. Národní konference kvality Karlovy Vary Jan Hřídel Regional Sales Manager - Public Administration Obsah 1. Strategie v ICT využití metody

Více

Případová studie.

Případová studie. Případová studie Centrum podpory projektů VUT v Brně vsadilo na řešení na platformě Microsoft, to nabídlo řešitelům projektů i univerzitě zcela nové možnosti www.microsoft.cz/pripadovestudie Přehled Země:

Více

Proces je definovaný soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má pro zákazníka hodnotu

Proces je definovaný soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má pro zákazníka hodnotu Proces je definovaný soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má pro zákazníka hodnotu EPC(Event driven Process Chains) s funkcemi, událostmi, organizačními jednotkami

Více

CASE. Jaroslav Žáček

CASE. Jaroslav Žáček CASE Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? Definice dle SEI A CASE tool is a computer-based product aimed at supporting one or more software engineering activities

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

Co je to COBIT? metodika

Co je to COBIT? metodika COBIT Houška, Kunc Co je to COBIT? COBIT (Control OBjectives for Information and related Technology) soubor těch nejlepších praktik pro řízení informatiky (IT Governance) metodika určena především pro

Více

Elektronizace projektového řízení a nástroje komunikace

Elektronizace projektového řízení a nástroje komunikace Odůvodnění účelnosti nadlimitní veřejné zakázky Elektronizace projektového řízení a nástroje komunikace podle 156 odst. 1 zákona č. 137/2006 Sb., o veřejných zakázkách, v platném znění a v souladu s prováděcí

Více

Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů

Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Alena Buchalcevová Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, katedra informačních technologií

Více

Michal Oškera (50854)

Michal Oškera (50854) PV098 - Řízení SW projektů semestrální práce Michal Oškera (50854) 19. listopadu 2003 Obsah 1 Úvod 2 2 Plán projektu 3 2.1 Plán CO.............................. 3 2.2 Plán JAK.............................

Více

ADAPTIVITA INFORMAČNÍCH SYSTÉMŮ INFORMATION SYSTEM ADAPTIVITY

ADAPTIVITA INFORMAČNÍCH SYSTÉMŮ INFORMATION SYSTEM ADAPTIVITY ADAPTIVITA INFORMAČNÍCH SYSTÉMŮ INFORMATION SYSTEM ADAPTIVITY Roman Malo Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta, Ústav informatiky, malo@pef.mendelu.cz Abstrakt Problematika

Více

Nebojte se přiznat, že potřebujete SQA

Nebojte se přiznat, že potřebujete SQA Nebojte se přiznat, že potřebujete SQA Internet a technologie 16 Václav Klimeš vaclav.klimes@nic.cz 1. 6. 2016 Osnova Kvalita Koncept kvality Co je a není SQA (Software Quality Assurance) Proč se zajímat

Více

Závěrečná zpráva o výsledcích řešení projektu v rámci rozvojových program MŠMT na rok 2006

Závěrečná zpráva o výsledcích řešení projektu v rámci rozvojových program MŠMT na rok 2006 Závěrečná zpráva o výsledcích řešení projektu v rámci rozvojových program MŠMT na rok 2006 Fakulta/Ústav: Název projektu: Aplikace novely zákona o veřejných zakázkách do informačního systému VVŠ Číslo

Více

Buďte Společně vždy vpřed na stopě vozidlům a pohonným hmotám. pilotní řešení O 2 Car Control pro TNT Post ČR

Buďte Společně vždy vpřed na stopě vozidlům a pohonným hmotám. pilotní řešení O 2 Car Control pro TNT Post ČR Buďte Společně vždy vpřed na stopě vozidlům a pohonným hmotám pilotní řešení O 2 Car Control pro TNT Post ČR Proč společný projekt 1. Výchozí podmínky: 2. Cíl: Telefónica O2 se stala poskytovatelem ucelených

Více

Operační program Lidské zdroje a zaměstnanost

Operační program Lidské zdroje a zaměstnanost Operační program Lidské zdroje a zaměstnanost EDUCA III Další profesní vzdělávání zaměstnanců společnosti T-MAPY spol. s r.o. 2013-2015 září 2013 - únor 2015 Charakteristika projektu Projekt je zaměřen

Více

Cíle a metodika průzkumu

Cíle a metodika průzkumu Cíle a metodika průzkumu Prof. Ing. Jiří Voříšek, CSc. Ing. Ota Novotný, Ph.D. Seminář ČSSI SPIS CACIO 15.5.2007 Konkurenceschopnost absolventů IT oborů VŠ a VOŠ na trhu práce v ČR Společný projekt ČSSI,

Více

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE PROJEKTOVÉ ŘÍZENÍ STAVEB ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE Vysoká škola technická a ekonomická v Českých PROJEKTŮ Budějovicích Institute of Technology And Business In České Budějovice Tento učební

Více

Metodika věcného auditu projektu Příloha č. 06. Kariéra projektového manažera začíná u nás! CHECK-LIST. Celkové zhodnocení projektu

Metodika věcného auditu projektu Příloha č. 06. Kariéra projektového manažera začíná u nás! CHECK-LIST. Celkové zhodnocení projektu CHECK-LIST Auditovaná fáze projektu: Auditor: Název projektu: Zpracoval: Datum: Celkové zhodnocení projektu Návod na vyplnění: Při vyplňování Check-listu posuzujte skutečný obsah auditované dokumentace,

Více

4.4.1 Ustavení vztahu, zpracování Projektu

4.4.1 Ustavení vztahu, zpracování Projektu Dodatečné informace č. 2 k zadávacím podmínkám k výběrovému řízení s názvem Zajištění bezproblémového provozu, dostupnosti, rozvoje a optimalizace portálu ČPZP Vážená paní / Vážený pane, na základě zmocnění

Více

Nadpis presentace. Řízení IT v malých. útvarech aneb Light verze IT governance

Nadpis presentace. Řízení IT v malých. útvarech aneb Light verze IT governance Řízení IT v malých Nadpis presentace útvarech aneb Light verze IT governance Iva Steinerová Mobil: +420 605 225 016 iva.steinerova@perpartes.cz www.perpartes.cz Název a datum presentace (Zobrazit Předloha

Více

Projektová dokumentace pro tvorbu internetových aplikací

Projektová dokumentace pro tvorbu internetových aplikací Projektová dokumentace pro tvorbu internetových aplikací Tomáš Kuthan PhDr. Milan Novák, Ph.D. Školní rok: 2008-09 Abstrakt Bakalářská práce stanovuje vzor pro vytváření projektové dokumentace internetových

Více

3. Očekávání a efektivnost aplikací

3. Očekávání a efektivnost aplikací VYUŽÍVANÍ INFORMAČNÍCH SYSTÉMŮ V ŘÍZENÍ FIREM Ota Formánek 1 1. Úvod Informační systémy (IS) jsou v současnosti naprosto nezbytné pro úspěšné řízení firem. Informačním ním systémem rozumíme ucelené softwarové

Více

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci.

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci. Mgr. Monika Johaníková Ochrana & Bezpečnost 2013, ročník II., č. 3 (podzim), ISSN 1805-5656 Stanovení strategie řízení kontinuity činností Anotace Příspěvek je věnován základním informacím o způsobu volby

Více

Projektové řízení. Lenka Švecová, Tomáš Říčka. University of Economics, Prague. Project management for SMEs/NGOs - exchange of experience for trainers

Projektové řízení. Lenka Švecová, Tomáš Říčka. University of Economics, Prague. Project management for SMEs/NGOs - exchange of experience for trainers Project management for SMEs/NGOs - exchange of experience for trainers LLP Grundtvig Learning Partnership Projektové řízení Lenka Švecová, Tomáš Říčka University of Economics, Prague This project has been

Více

MANUÁL PROJEKTOVÉHO MANAŽERA MĚSTSKÉHO ÚŘADU

MANUÁL PROJEKTOVÉHO MANAŽERA MĚSTSKÉHO ÚŘADU PŘÍLOHA Č. 4 VNITŘNÍHO PŘEDPISU Č. 0003/2015 MANUÁL PROJEKTOVÉHO MANAŽERA MĚSTSKÉHO ÚŘADU - POSTUP ŘÍZENÍ KOMPLEXNÍHO PROJEKTU - Městský úřad Moravská Třebová 1 OBSAH A. ÚVOD 3 A.1.1. Účel manuálu 3 A.1.2.

Více

Standardní dokumenty

Standardní dokumenty Standardní dokumenty Definice European Energy Service Initiative EESI IEE/08/581/SI2.528408 Prosinec 2010 Berliner Energieagentur GmbH Disclaimer: The sole responsibility for the content of this paper

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

Informační systémy ve strojírenství

Informační systémy ve strojírenství 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení Informační systémy ve strojírenství Radim Farana 1 Obsah Životní cyklus vývoje SW. Informační

Více

Hlavní otázka zní Co dál? Mapování cesty zákazníků službou

Hlavní otázka zní Co dál? Mapování cesty zákazníků službou Hlavní otázka zní Co dál? Mapování cesty zákazníků službou Adam Hazdra Jihomoravské inovační centrum Klubový večer WebTop100 4.4.2013 Adam Hazdra 6+ years of Market Research and Innovation Startup Consultant,

Více

Případová studie. Intranet 2.0 pre. HB Reavis Group. Jak jsme zaměstnancům společnosti HB Reavis Group pomohli zefektivnit práci.

Případová studie. Intranet 2.0 pre. HB Reavis Group. Jak jsme zaměstnancům společnosti HB Reavis Group pomohli zefektivnit práci. Případová studie Intranet 2.0 pre HB Reavis Group Jak jsme zaměstnancům společnosti HB Reavis Group pomohli zefektivnit práci. Intranet 2.0 pre HB Reavis Group Se společností Millennium jsme poprvé vyzkoušeli

Více

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007 Základy analýzy autor Jan Novotný http://blog.novoj.net/ 15. února 2007 V prezentaci jsou použity diagramy z: Wikipedia, Sparx UML Tutorial, Argo UML Metodiky vývoje Různé metodiky vývoje vazba na fáze

Více

People Manager Komplexní řízení zdrojů a projektů jednoduše

People Manager Komplexní řízení zdrojů a projektů jednoduše People Manager Komplexní řízení zdrojů a projektů jednoduše Hlavní funkce Řízení portfolia projektů Podpora pro Demand Management a prioritizaci Podpora pro rozhodování při plánování releasů aplikací Přehled

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

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

Více

Případová studie. SAM Assessment ušetřil AAA Auto 30 % nákladů na licence a zkrátil proces implementace nových aplikací a software na desetinu

Případová studie. SAM Assessment ušetřil AAA Auto 30 % nákladů na licence a zkrátil proces implementace nových aplikací a software na desetinu Případová studie SAM Assessment ušetřil AAA Auto 30 % nákladů na licence a zkrátil proces implementace nových aplikací a software na desetinu www.microsoft.cz/pripadovestudie Přehled Země: Česká republika

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

AGILNÍ METODIKY A SPRÁVA POŽADAVKŮ

AGILNÍ METODIKY A SPRÁVA POŽADAVKŮ Citace: BUCHALCEVOVÁ, Alena. Agilní metodiky a správa požadavků. Ostrava 04.06.2007 06.06.2007. In: Tvorba softwaru 2007. Ostrava : Ekonomická fakulta VŠB TU, 2007, s. 16 23. ISBN 978-80-248-1427-8. AGILNÍ

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

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

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 AGENDA definice IS, zavedení pojmů možnosti a rozdělení typická struktura technologie nasazení praktická ukázka

Více

Řízení projektového cyklu. Fáze projektového cyklu

Řízení projektového cyklu. Fáze projektového cyklu 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) Fáze projektového cyklu Řízení projektového cyklu Projektový

Více

Jakou metodiku použít pro

Jakou metodiku použít pro Jakou metodiku použít pro konkrétní projekt? Hodnocení a výběr vhodné metodiky pro budování IS Alena Buchalcevová Katedra informačních č technologií, VŠE Praha Agenda metodika jako nástroj zvýšení úspěšnosti

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

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

Procesní řízení. Hlavní zásady a praxe dodavatele Komix

Procesní řízení. Hlavní zásady a praxe dodavatele Komix Procesní řízení Hlavní zásady a praxe dodavatele Komix 1 Obsah prezentace Teoretická část (menšího objemu) orientace na zákazníka hodnocení procesu podmínky procesního řízení cyklus zlepšování procesu

Více

Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D.

Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Přípravné činnosti projektu Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Obsah prezentace Seznámení s problematikou Procesy a roviny před implementací projektu Obchodní rovina Implementační rovina Řešení

Více

Model vlakového uzlu Model of a Railway Junction

Model vlakového uzlu Model of a Railway Junction Model vlakového uzlu Model of a Railway Junction Michal Bílek 1 Abstrakt Vysoká škola polytechnická v Jihlavě využívá pro výuku odborných předmětů mnoho modelů. Jedním z modelů používaných ve výuce je

Více

Současný stav používání agilních metodik ve světě a v ČR

Současný stav používání agilních metodik ve světě a v ČR Acta Informatica Pragensia, 2015, 4(1): 4 17 DOI: 10.18267/j.aip.48 Peer-reviewed paper Současný stav používání agilních metodik ve světě a v ČR Current State of Agile Methodologies Worldwide and in the

Více

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí:

Výčet strategií a cílů, na jejichž plnění se projektový okruh podílí: Karta projektového okruhu Číslo a název projektového okruhu: Garant karty projektového okruhu: Spolupracující subjekty: 9. Elektronizace podpůrných procesů Ministerstvo vnitra, Ministerstvo financí Správa

Více

Vyhodnocení systému outsourcingu IT na ÚMČ Praha 10

Vyhodnocení systému outsourcingu IT na ÚMČ Praha 10 Vyhodnocení systému outsourcingu IT na ÚMČ Praha 10 Vyjádření k oponentnímu posudku zpracovanému společností Deloitte Advisory, s.r.o. Předkládá Ing. Luděk Kryšpín Datum vydání: 11. 3. 2014 (verze 1.00)

Více

TOGETHER WE CAN projekt interních koučů v UniCredit Bank

TOGETHER WE CAN projekt interních koučů v UniCredit Bank TOGETHER WE CAN projekt interních koučů v UniCredit Bank Firma: UniCredit Bank Czech Republic, a.s. Na Příkopě 858/20 111 21 Praha 1 www.unicreditbank.cz Kontaktní osoba: Lenka Štěpánová Learning & Development

Více

Česká zemědělská univerzita v Praze

Česká zemědělská univerzita v Praze Česká zemědělská univerzita v Praze Provozně ekonomická fakulta Katedra informačních technologií Teze diplomové práce Operační systém Google Android Petr Koula 2011 ČZU v Praze Souhrn Diplomová práce zahrnuje

Více

Informační systémy ve výuce na PEF Information Systems in teaching at the FEM

Informační systémy ve výuce na PEF Information Systems in teaching at the FEM Informační systémy ve výuce na PEF Information Systems in teaching at the FEM Edita Šilerová, Čestmír Halbich, Jana Hřebejková Cíle Předmět Informační systémy je postupně od roku 1994 zařazován na všechny

Více

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 Obsah Předmluva 11 Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 KAPITOLA 1 Úvod do architektury softwaru 15 Použití procesu 16 Stručný popis

Více

Představení projektu Metodika

Představení projektu Metodika Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah

Více

B3 Vazba strategie byznys

B3 Vazba strategie byznys Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B3 Vazba strategie byznys Toto téma vysvětluje vzájemný vztah mezi tzv. byznysem organizace (hlavním

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

Infor APS (Scheduling) Tomáš Hanáček

Infor APS (Scheduling) Tomáš Hanáček Infor APS (Scheduling) Tomáš Hanáček Klasické plánovací metody a jejich omezení MRP, MRPII, CRP Rychlost Delší plánovací cyklus Omezená reakce na změny Omezené možnosti simulace Funkčnost Nedokonalé zohlednění

Více

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz INFORMAČNÍ SYSTÉMY 03. 01. 2006, Ing. Jiří Mráz PŘEDNÁŠEJÍCÍ Jiří Mráz Production Coordinator UNICORN jiri.mraz@unicorn.cz AGENDA Informační a komunikační technologie (ICT) podniku Informační systémy Zakázkový

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 Zadavatel: Česká republika Ministerstvo životního prostředí Sídlo: Vršovická 1442/65, 100 10 Praha 10 IČO: 00164801 Jednající: Název veřejné zakázky: Ing.

Více

Metodický rámec budování IS/ICT

Metodický rámec budování IS/ICT Metodický rámec budování IS/ICT Alena Buchalcevová Katedra informačních technologií VŠE Praha nám. W. Churchilla 4, 30 00 Praha 3 email: buchalc@vse.cz Abstrakt Článek popisuje metodický rámec pro budování

Více

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

Více

Studie webů automobilek

Studie webů automobilek Studie webů automobilek červen 2006 [manažerské shrnutí] Obsah Obsah... 1 Manažerské shrnutí... 2 Kvalita obsahu a použitelnost webu... 3 Základní nedostatky negativně ovlivňují použitelnost většiny webů...

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

PROVÁDĚCÍ SMLOUVA Č. 2. (č. ev. ČSÚ: 180 2013 S)

PROVÁDĚCÍ SMLOUVA Č. 2. (č. ev. ČSÚ: 180 2013 S) PROVÁDĚCÍ SMLOUVA Č. 2 (č. ev. ČSÚ: 180 2013 S) k Rámcové smlouvě na služby odborné podpory IT v rámci projektu Redesign statistického informačního systému v návaznosti na zavádění egovernmentu v ČR uzavřené

Více

Vnitřní kontrolní systém a jeho audit

Vnitřní kontrolní systém a jeho audit Vnitřní kontrolní systém a jeho audit 7. SETKÁNÍ AUDITORŮ PRŮMYSLU 11. 5. 2012 Vlastimil Červený, CIA, CISA Agenda Požadavky na VŘKS dle metodik a standardů Definice VŘKS dle rámce COSO Role interního

Více