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

Save this PDF as:
 WORD  PNG  TXT  JPG

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 < [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

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

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

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

Více

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

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

Více

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

Ž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

Ří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

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

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

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

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

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

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

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

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

Více

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

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

Results of innovation of the course Application software

Results of innovation of the course Application software Zkušenosti z inovace předmětu Aplikační programové vybavení Results of innovation of the course Application software Miroslav Cepl *, Ondřej Popelka Abstrakt Článek popisuje postup a průběžný výsledek

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

Ing. Zuzana Šochová 30.4.2008. ČVUT FEL - Řízení softwarových projektů

Ing. Zuzana Šochová 30.4.2008. ČVUT FEL - Řízení softwarových projektů Ing. Zuzana Šochová 30.4.2008 1 Outsourcing jako business model Práce v týmu Procesy a řízení lidí v outsourcingu Metodologie Agile SCRUM 2 Proč firmy hledají outsourcing? Levnější (?) Nedostatek vlastních

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

Týmy SiTD. M. Studeníková E.Pařenicová. E. Hesounová E. Benková K. Hubáček L. Juráňová T. Vojkůvka P. Říha

Týmy SiTD. M. Studeníková E.Pařenicová. E. Hesounová E. Benková K. Hubáček L. Juráňová T. Vojkůvka P. Říha Týmy SiTD Četa Alfa Charlie Echo Roger Členové T. Doubrava M. Rosta R. Fačevic T. Římský P. Zlámal J. Zlámal J. Svoboda J. Werner M. Kyral M. Mackovík P. Mlčoch D. Walter M. Grohmannová náhrada za OM Zodpovědnost

Více

Vývoj IS. Vladimíra Zádová, KIN, EF TUL- ISN3

Vývoj IS. Vladimíra Zádová, KIN, EF TUL- ISN3 Vývoj IS Metodika Metoda Nástroje Technika Životní cyklus Etapy Přístupy k vývoji Základní alternativy vývoje a provozu Integrace Doporučený souhrn etap, přístupů, zásad, postupů, pravidel, metod, technik,

Více

AGILNÍ METODIKY VÝVOJE SOFTWARE

AGILNÍ METODIKY VÝVOJE SOFTWARE AGILNÍ METODIKY VÝVOJE SOFTWARE Postupy předchozích metodik, založené na důsledné analýze a propracovaném návrhu jsou obecně nejlepší. Ale Děláte web půl roku? Konkurence mezitím spustila dva Zdánlivě

Více

6INF2. RNDr. Jaroslav Žáček, Ph.D. jaroslav.zacek@osu.cz

6INF2. RNDr. Jaroslav Žáček, Ph.D. jaroslav.zacek@osu.cz 6INF2 RNDr. Jaroslav Žáček, Ph.D. jaroslav.zacek@osu.cz Vliv IT na změny ve společnosti Vznik nových produktů (platební karty, digitální kamery, ) Vznik ucelených řešení na bázi IS bez přítomnosti lidí

Více

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

KIV/SI. Přednáška č.8. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Přednáška č.8 Jan Valdman, Ph.D. jvaldman@dns.cz 19.4.2011 Outsourcing Co je to outsourcing Vyčlenění nějaké činnosti a její zajištění externím dodavatelem De-facto nákup služby Outsourcují se podpůrné

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

Hodnotocentrické metodiky

Hodnotocentrické metodiky 2 Hodnotocentrické metodiky Vyšší management Projektový manažer Jedna metodika těžko bude tou jedinou správnou,... pro každý projekt a realizační tým existuje jiný správný způsob práce. 1 Alistair Cockburn

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

D9 Realizace projektu

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

Více

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

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph. METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.D Katedra informačních technologií VŠE Praha nám. W.Churchilla 4,

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

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

Trendy v (mobilní) Business Inteligence v ČR dotazníkové šetření

Trendy v (mobilní) Business Inteligence v ČR dotazníkové šetření Trendy v (mobilní) Business Inteligence v ČR dotazníkové šetření Vytvořil: Distribuce dokumentu: Česká asociace pro finanční řízení Controller Institut elektronicky na finanční a controllingové specialisty

Více

Seminář VŠE, ČSSI a ICT UNIE 26.10.2011

Seminář VŠE, ČSSI a ICT UNIE 26.10.2011 Výsledky průzkumu nabídky a poptávky po IT profesích v ČR Seminář VŠE, ČSSI a ICT UNIE 26.10.2011 Výzkum Lidské zdroje v ICT vznikl za finanční podpory MŠMT ČR v rámci projektu Sociální síť v regionech

Více

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI Cyril Klimeš a) Jan Melzer b) a) Ostravská univerzita, katedra informatiky a počítačů, 30. dubna 22, 701 03 Ostrava, ČR E-mail: cyril.klimes@osu.cz b) DC Concept

Více

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

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

Více

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

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

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

Architektura řízení v návaznosti na IT systémy

Architektura řízení v návaznosti na IT systémy Koncepční dokument pro oblast řízení a koordinaci e-gov: Architektura řízení v návaznosti na IT systémy 11. 09. 2013 OBSAH Obsah... 2 Seznam zkratek... 3 Použité pojmy... 4 1 Úvodní informace... 7 1.1

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

Vysoká škola ekonomická v Praze Fakulta podnikohospodářská

Vysoká škola ekonomická v Praze Fakulta podnikohospodářská Projekt implementace SAP Business Objects Předmět: 3MA382 Manažerská informatika projektové řízení, distanční Období: ZS 2009/2010 Vypracoval/a: Petr Kuchyňka (xkucp27), Klára Jalůvková (xjalk00, FPH N

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

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

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

Více

Zavedení UX do organizace

Zavedení UX do organizace Zavedení UX do organizace Jiří Mžourek jiri@mzourek.org Cíl prezentace Zavedení UX do organizace z pohledu managementu Zdroje dat Primární: Sun Microsystems a ostatní enterprise firmy Uživatelská rozhraní

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

HUMAN CAPITAL IN ICT. Petr Doucek, Lea Nedomová Informační technologie pro praxi 1. září 2009, Ostrava

HUMAN CAPITAL IN ICT. Petr Doucek, Lea Nedomová Informační technologie pro praxi 1. září 2009, Ostrava HUMAN CAPITAL IN ICT Petr Doucek, Lea Nedomová Informační technologie pro praxi 1. září 2009, Ostrava Obsah LIDSKÉ ZDROJE V ICT BUDOUCNOST ICT V ČESKÉ REPUBLICE Cíle projektu 3 Budu hovořit o business

Více

Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali

Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali K.O.D.A. s.r.o Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali dost zkušeností v našem oboru. Zabýváme se vývojem informačního systému pro výrobní podniky a dále konzultačními

Více

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

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

ABSOLVENTI FILOLOGICKÝCH OBORŮ DNES A ZITRA

ABSOLVENTI FILOLOGICKÝCH OBORŮ DNES A ZITRA CZ.1.07/2.2.00/15.0291 ABSOLVENTI FILOLOGICKÝCH OBORŮ DNES A ZITRA 22. září 2011 Filozofická fakulta Univerzity Palackého v Olomouci PhDr. Hana Katrňáková, Ph.D. Kurzy měkkých manažerských dovedností (soft

Více

Vytvoření dokumentu informační strategie

Vytvoření dokumentu informační strategie Vytvoření dokumentu informační strategie M ě s t o Uh e r s ké H r adi š t ě M ě s t s ký ú ř a d M as ar y ko v o n ám. 1 9 68 6 70 Uh. H r adi š t ě I Č 00 2 9 14 7 1 Smysl informační strategie Důraz

Více

ANALÝZA A OPTIMALIZACE VÝROBNÍCH PROCESŮ MALOSÉRIOVÉ SLOŽITÉ VÝROBY V NOVÝCH VÝROBNÍCH PROSTORECH NA ZÁKLADĚ DISKRÉTNÍ SIMULACE

ANALÝZA A OPTIMALIZACE VÝROBNÍCH PROCESŮ MALOSÉRIOVÉ SLOŽITÉ VÝROBY V NOVÝCH VÝROBNÍCH PROSTORECH NA ZÁKLADĚ DISKRÉTNÍ SIMULACE ANALÝZA A OPTIMALIZACE VÝROBNÍCH PROCESŮ MALOSÉRIOVÉ SLOŽITÉ VÝROBY V NOVÝCH VÝROBNÍCH PROSTORECH NA ZÁKLADĚ DISKRÉTNÍ SIMULACE Doc. Václav Votava, CSc. (a), Ing. Zdeněk Ulrych, Ph.D. (b), Ing. Milan Edl,

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

Web Design Factory Projektové řízení pro progresivní společnost

Web Design Factory Projektové řízení pro progresivní společnost Web Design Factory Projektové řízení pro progresivní společnost Případová studie Name Description Projektové řízení pro progresivní společnost Implementace systému Atollon Workshop ve společnosti WDF Version

Více

Trendy outsourcingu pro veřejnou správu

Trendy outsourcingu pro veřejnou správu Trendy outsourcingu pro veřejnou správu Jindra Tumová ISSS 2009 Obsah Stav Řešení Přínosy Reference Page 2 Klíčové trendy ve státní správě vysílají signál: více činností za méně peněz Ekonomická situace,

Více

CMMI-DEV v.1.3 PA Configuration management

CMMI-DEV v.1.3 PA Configuration management VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE CMMI-DEV v.1.3 PA Configuration management 4IT421 - Zlepšování procesů budování IS Pavel Neuman ZS 2012/2013 Obsah 1. Úvod... 2 2. Configuration Management... 2 2.1. Úvodní

Více

Architektura ArchestrA Všechny systémy ve Vašem podniku pracují v souladu

Architektura ArchestrA Všechny systémy ve Vašem podniku pracují v souladu Architektura ArchestrA Všechny systémy ve Vašem podniku pracují v souladu Wonderware, Pantek (CS) s.r.o. Strana 2 Moderní průmyslová aplikační infrastruktura ArchestrA pro efektivní řešení v průmyslové

Více

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

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

Více

Č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

Jak získat do firmy kvalitní lidi. Ing. Olga Girstlová, Ph.D.

Jak získat do firmy kvalitní lidi. Ing. Olga Girstlová, Ph.D. Jak získat do firmy kvalitní lidi Ing. Olga Girstlová, Ph.D. PODNIKATEL Vytváří podnikatelský model v daném oboru podnikání Definuje svého zákazníka a jeho potřeby na daném trhu Využívá k naplnění svého

Více

Agenda. Docházka Návrat k minulému praktickému cvičení Zápočtové práce. Dokumentace. Dotazy, přání, stížnosti. Co, jak a proč dokumentovat

Agenda. Docházka Návrat k minulému praktickému cvičení Zápočtové práce. Dokumentace. Dotazy, přání, stížnosti. Co, jak a proč dokumentovat QA & Dokumentace Agenda Docházka Návrat k minulému praktickému cvičení Zápočtové práce QA opakování Dokumentace Co, jak a proč dokumentovat Dotazy, přání, stížnosti Kde je chyba? public static StringBuilder

Více

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

ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY ODŮVODNĚNÍ VEŘEJNÉ ZAKÁZKY v souladu s ust. 156 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen ZVZ ) Identifikace zadavatele: Statutární město Ostrava sídlem: Prokešovo

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

Agilní metodiky Agilní Jan Smolík

Agilní metodiky Agilní Jan Smolík Agilní metodiky Jan Smolík Kritéria pro členění metodik Zaměření metodiky Rozsah metodiky Váha metodiky Typ řešení Doména Zaměření metodiky Globální metodiky (Enterprise Methodologies) Zaměřené na komplexní

Více

ODBORNÉ PORADENSTVÍ PRO STRATEGICKÉ ŘÍZENÍ KATALOG 2013. Motto: Víte, kde jsou Vaše zdroje?

ODBORNÉ PORADENSTVÍ PRO STRATEGICKÉ ŘÍZENÍ KATALOG 2013. Motto: Víte, kde jsou Vaše zdroje? ODBORNÉ PORADENSTVÍ PRO STRATEGICKÉ ŘÍZENÍ KATALOG 2013 Motto: Víte, kde jsou Vaše zdroje? ODBORNÉ PORADENSTVÍ PRO STRATEGICKÉ ŘÍZENÍ AL-Consulting s.r.o. Metody strategického poradenství v dnešní době

Více

Projektové řízení. Ing. Miroslav Žilka, Ph.D.

Projektové řízení. Ing. Miroslav Žilka, Ph.D. Projektové řízení Ing. Miroslav Žilka, Ph.D. Týmová spolupráce Prezentační dovednosti Kreativita Projekt REHP Kalkulace nákladů Přesvědčivost Rozpočet TE hodnocení projektů Diplomacie Zásady projektového

Více

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

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

Více

Přehled rolí v jednotlivých metodikách

Přehled rolí v jednotlivých metodikách 4IT421 Zlepšování procesů budování informačních systémů Přehled rolí v jednotlivých metodikách RUP pro velké projekty, RUP pro malé projekty, OpenUP, MMSP, Scrum, XP Bc. Kamila Langrová (xlank10) ZS 2013/2014

Více

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

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

Více

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

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

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

Více

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

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

Více

Project management. Příprava projektu Zahájení High level plánování. Vykonávání Detailní plánování Vykonávání Řízení a monitorování

Project management. Příprava projektu Zahájení High level plánování. Vykonávání Detailní plánování Vykonávání Řízení a monitorování Project management Project management Příprava projektu Zahájení High level plánování Vykonávání Detailní plánování Vykonávání Řízení a monitorování Uzavření a zhodnocení (iterace, projektu) Projekt Projekt

Více

Podnik jako živý organismus - konkurenční výhoda. Ing. Olga Girstlová Víceprezidentka a generální ředitelka skupiny GiTy

Podnik jako živý organismus - konkurenční výhoda. Ing. Olga Girstlová Víceprezidentka a generální ředitelka skupiny GiTy Podnik jako živý organismus - konkurenční výhoda Ing. Olga Girstlová Víceprezidentka a generální ředitelka skupiny GiTy PODNIKATEL Vytváří podnikatelský model v daném oboru podnikání Definuje svého zákazníka

Více

Agenda. Docházka Odhadování Neohlášený test Vedení projektů Historie projektů

Agenda. Docházka Odhadování Neohlášený test Vedení projektů Historie projektů Odhadování pracnosti a PM Agenda Docházka Odhadování Neohlášený test Vedení projektů Historie projektů PM, odhadování, historie Odhadování Snaha určit rozsah. Důležité pro stanovení ceny a termínu Do nabídek.

Více

Efektivita (nejen) veřejné správy

Efektivita (nejen) veřejné správy Efektivita (nejen) veřejné správy 09/04/2014 Jan Růžička Managed services Výchozí stav Neefektivní využívání pracovní doby Důvody: Nejednotnost příchozích kanálů pro práci (email, interní systémy, mobil,

Více

Řízení rizik s nástroji SAP BusinessObjects GRC AC Josef Piňos, CONSIT s.r.o.

Řízení rizik s nástroji SAP BusinessObjects GRC AC Josef Piňos, CONSIT s.r.o. Řízení rizik s nástroji SAP BusinessObjects GRC AC Josef Piňos, CONSIT s.r.o. Bezpečnost informačních systémů Využívání informačních technologií, zejména sofistikovaných ERP systémů jako je SAP, znamená

Více

PRŮZKUM AGILNÍHO ŘÍZENÍ V ČR 2013

PRŮZKUM AGILNÍHO ŘÍZENÍ V ČR 2013 PRŮZKUM 2013... aneb jak jsme na tom s agilem PRŮZKUM 2013 ETNETERA & AGILE V KOSTCE V dnešní době již téměř každý volnonožec, každá firmička, firma či korporace slyšeli aspoň něco málo o Agilu. O tak

Více

Řízení projektu a rizik vývoje softwaru

Řízení projektu a rizik vývoje softwaru Řízení projektu a rizik vývoje softwaru 3. dubna 2013 Zbyněk Šlosar Lektor Zbyněk Šlosar Project Manager @ Unicorn Systems Energetika, Telco, Bankovnictví, Odpadové hospodářství Zakázkový vývoj software,

Více

System Center Operations Manager

System Center Operations Manager System Center Operations Manager Jan Vávra Solution Sales Professional Microsoft System Center Operations Manager End-to-End Service Management Proaktivní správa IT služeb Integrované monitorování distribuovaných

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

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

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

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

Více

Výhody a rizika outsourcingu formou cloud computingu

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

Více

Business Suite for Notes

Business Suite for Notes Business Suite for Notes Systém BSFN byl vytvořen na základě zkušeností s podporou a řízením procesů v obchodní firmě. Během několika let existence na trhu se osvědčil u mnoha zákazníků. Z nejvýznamnějších

Více

Helios Easy. integrované řešení pro řízení

Helios Easy. integrované řešení pro řízení integrované řešení pro řízení Skupina ASSECO je jedním z nejvýznamnějších softwarových domů ve střední Evropě. Chcete držet své náklady více pod kontrolou? Potřebujete, aby vaše investice měly rychlou

Více

Není nic staršího než včerejší web

Není nic staršího než včerejší web Není nic staršího než včerejší web Jan Ondrák Technická správa komunikací Praha René Zahradník IBM Lotus Software 2007 IBM Corporation Technická správa komunikací Praha Tradice od roku 1963, od roku 1996

Více

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

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

Více

One Life, live it well

One Life, live it well One Life, live it well DATASYS UMS - UNIFIED MESSAGING SYSTEM with integrated it s possible! 1 Společnost DATASYS poskytuje specializované služby v oblasti implementace, vývoje a dodávek komunikačních

Více

Zadavatel: Česká republika Český statistický úřad se sídlem Na padesátém 81/3268, 100 82 Praha 10 Strašnice, IČO: 00025593

Zadavatel: Česká republika Český statistický úřad se sídlem Na padesátém 81/3268, 100 82 Praha 10 Strašnice, IČO: 00025593 Zadavatel: Česká republika Český statistický úřad se sídlem Na padesátém 81/3268, 100 82 Praha 10 Strašnice, IČO: 00025593 Dílčí veřejná zakázka: Evidenční systém etapy IV VI zadávaná podle ustanovení

Více

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

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

Více

Konkurenceschopnost absolventů IT oborů VŠ a VOŠ na trhu práce v ČR

Konkurenceschopnost absolventů IT oborů VŠ a VOŠ na trhu práce v ČR za podpory MŠMT ČR Konkurenceschopnost absolventů IT oborů VŠ a VOŠ na trhu práce v ČR Detailní zpráva pro obor: VŠE v Praze FIS Kognitivní informatika navazující magisterský studijní program verze 1.0

Více

software pro embedded systémy a mobilní zařízení

software pro embedded systémy a mobilní zařízení software pro embedded systémy a mobilní zařízení profil společnosti Eccam je česká softwarová společnost se sídlem v Praze. Zabýváme se návrhem a vývojem software pro embedded a mobilní systémy z různých

Více

DYNAMICKÝ WEB SITE PRO SME THE DYNAMIC WEB SITE FOR SME

DYNAMICKÝ WEB SITE PRO SME THE DYNAMIC WEB SITE FOR SME DYNAMICKÝ WEB SITE PRO SME THE DYNAMIC WEB SITE FOR SME Zdeněk Havlíček, Pavel Jeřábek Anotace Celkový vývoj informačních technologií má dopad na činnost malých a středních podniků (SME). V příspěvku jsou

Více

Ochranný svaz autorský zefektivnil svou činnost s produktem Webtica HelpDesk na platformě Microsoft

Ochranný svaz autorský zefektivnil svou činnost s produktem Webtica HelpDesk na platformě Microsoft Microsoft Windows Server System Ochranný svaz autorský zefektivnil svou činnost s produktem Webtica HelpDesk na platformě Microsoft Přehled Země: Česká republika Odvětví: Služby, zábavní průmysl Vedení

Více

Strategické řízení návrh

Strategické řízení návrh Strategické řízení návrh Víme jakým způsobem Vaše: Cíl naší spolupráce v čase náklady problémy rezervy nedostatky snížit řešit využít odstranit Naším cílem je trvalý růst vaší společnosti Předpokládaný

Více

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

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

Více