Nástroj pro projektové řízení s podporou agilních metodik vývoje

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

Download "Nástroj pro projektové řízení s podporou agilních metodik vývoje"

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Nástroj pro projektové řízení s podporou agilních metodik vývoje Diplomová práce Vedoucí práce: Ing. Michael Štencl, Ph.D. Bc. Lukáš Krakovský Brno 2012

2 2

3 Děkuji Ing. Michaelu Štenclovi, Ph.D. za odborné vedení a cenné rady poskytnuté v průběhu vypracování této diplomové práce. Poděkování za nezaplatitelné poznatky a zkušenosti z praxe patří společnosti Quality Management s.r.o., především Mgr. Michalovi Severinovi, bez kterého by tato práce nemohla vzniknout. Dále děkuji svým nejbližším, kteří mi dodávali neustálou podporu a jejihc pozitivní vliv přispěl ke všem mým úspěchům.

4 Prohlašuji, že jsem tuto dilomovou práci vyřešil samostatně dle pokynů vedoucího a za použití zdrojů, které jsou uvedeny v závěru práce. V Brně dne 17. května

5 5 Abstract Krakovský, L. Tool for project management with support of agile development methodologies. Brno, 2012 This diploma thesis describes the proposal and implementation tool to support of project management with a focus on agile development methodologies, in an environment of a particular company. It analyzes the current situation in the area of agile methodologies and the development process of the company. The design will provided tool to support of project management based on the principles of agile methodologies. It will also allow the user to define her own methodology. And then it will allow the user to define actual implementation. Keywords Agile methodologies, project management, tool, software development, SharePoint, SCRUM Abstrakt Krakovský, L. Nástroj pro projekotvé řízení s podporou agilních metodik vývoje. Brno, 2012 Diplomová práce se zabývá návrhem a implementací nástroje pro podporu projektového řízení se zaměřením na agilní metodiky vývoje, v prostředí konkrétní společnosti. Analyzuje současnou situaci v oblasti agilních metodik a procesu vývoje dané společnosti. V rámci práce bude stanoven návrh nástroje pro podporu projektového řízení vycházející z principů agilních metodik. Dále bude definována vlastní metodika práce, na jejímž základě bude provedena samotná implementace nástroje. Klíčová slova Agilní metodiky, projekotvé řízení, nástroj, vývoj softwaru, SharePoint, SCRUM

6 OBSAH 6 Obsah 1 Úvod a cíl práce Úvod Cíl práce Současný stav řešené problematiky Agilní metodiky Základní charakteristika Porovnání agilních a rigorózních metodik Stručný přehled nejběžnejších agilních metodik Společnost Quality Management s.r.o Současná situace v oblasti řízení projektů Základní charakteristika metodik SCRUM a KANBAN Vývojový tým Používané artefakty Proces a fáze vývoje Srovnání nástrojů podporující agilní vývoj Důvody vedoucí k implementaci vlastního nástroje Neformální specifikace Metodika práce Formální specifikace systému Vymezení uživatelských rolí Funkční požadavky Nefunkční požadavky Metodika vlastního vývoje Implementační prostředky ASP.NET Microsoft SharePoint Designer Microsoft Visual Studio Microsoft Visio Programovací jazyk C# Microsoft Reporting Services MS Windows Server UML Selenium Vlastní práce Struktura aplikace Datová vrstva Aplikační vrstva Uživatelské rozhraní Implementace systému

7 OBSAH User Dashboard Projekty Sprinty Požadavky Úkoly Kalendář Informace a upozornění Osobní poznámky Číselníky Reporting Verzování dokumentů a položek Knihovna dokumentů Správa systému Uživatelské role Zabezpečení aplikace Testování Diskuze 64 6 Závěr 66 7 Literatura 67

8 1 ÚVOD A CÍL PRÁCE 8 1 Úvod a cíl práce 1.1 Úvod V současné době je tržní prostředí charakteristické svou dynamikou a rychlou proměnlivostí. Ekonomika je stále více orientovaná na znalosti, kratší životní cyklus produktu, inovace a rychlý technologický pokrok. Na změny kolem nás je třeba nejen reagovat, ale dokonce změny vyvolávat, a tak získat náskok před konkurencí. V oblasti informačních technologií to znamená, že do jejich vývoje a provozu je třeba stále častěji zapracovávat různé změny. Klíčovou oblastí IT je tvorba softwaru. Různé postupy a přístupy k vývoji softwaru, se rozvíjely a nadále rozvíjejí ruku v ruce s rozvojem využívaných technologií. Důležitost a význam správně zvoleného přístupu pro vývoj daného softwaru, potvrzují výsledky z průzkumu v projektu CHAOS 1 roce 2009 a výsledky z průzkumu realizovaného Scottem W. Ambrelem 2 v roce V případě prvně zmíněného průzkumu je neúspěch u projektů více jak 65% (bez návratnosti na konkrétní metodiku). Jedná se především o projekty, které nesplnily následující tři kritéria: projekt nebyl dokončen ve stanovený čas, nebyl dokončen v rámci stanoveného rozpočtu a dokonce u některých projektů nebyly splněny ani požadované vlastnosti na systém. Ve druhém případě průzkum uvádí, že za neúspěch většiny projektů mohou rigorózní metodiky a řízení projektů způsobem ad-hoc. V současných podmínkách přestávají vyhovovat tradiční rigorózní metodiky vývoje a stále více se začínají prosazovat metodiky agilní. Jedná se zejména o metodiky založené na myšlence, kdy hlavní cestou k úspěchu, je vyvinout daný systém co nejrychleji, řešení prezentovat zákazníkovi a na základě zpětné vazby jej patřičně upravit. Především u rozsáhlejších projektů se software vyvíjí převážně týmově, musí být kvalitnější, musí být k dispozici rychleji a vyžaduje údržbu i v době dávno po svém nasazení. Všechny tyto aspekty výrazně ovlivňují celý proces vývoje a požadavky na něj. Většina firem zabývající se vývojem softwarových produktů již před časem pochopila, že bez určitého řádu, vymezených pravidel a určitých firemních postupů je vývoj většinou velmi neefektivní. Společně s rostoucí popularitou agilních metodik vývoje se pro jejich podporu na trhu objevuje stále více softwarových aplikací na podporu řízení projektů, ať už distribuovaných komerčně či zdarma. Agilní vývoj nutně nevyžaduje používání podpůrných nástrojů pro řízení projektů, ale v případě správně zvoleného nástroje, který danou metodiku efektivně podporuje je tato kombinace pro většinu firem velkým přínosem a výhodou. Firmy, vyvíjející software tak stojí před nelehkým úkolem, vybrat a následně zavést metodiku vhodnou pro vlastní specifické prostředí, případně zvolit efektivní nástroje pro jejich podporu. Zavedení správné metodiky v kombinaci 1 Výsledky průzkumu dostupné z 2 Výsledky z průzkumu dostupné z

9 1.2 Cíl práce 9 s vhodně zvolenými podpůrnými nástroji, může pro danou firmu znamenat značný přínos jak z krátkodobého tak i dlouhodobého hlediska. Jednou z takových firem je i společnost Quality Management s.r.o., která se zabývá především vývojem software, zejména pak tvorbou informačních systémů a s problematikou vývoje se potýká dnes a denně. V důsledku dynamického rozvoje zakázek, časové náročnosti řešených projektů a rostoucímu počtu nových požadavků, se ve zmíněné společnosti začaly postupem času, vyskytovat v rámci řešených projektů znepokojují problémy. Problémy spočívaly především v prodlevách při dodání smluvených funkcionalit, snížení kvality implementovaných komponent, nečekaném nárůstu rozsahu práce a přetěžování zaměstnanců. Vzniklá situace přivedla vedoucí pracovníky společnosti k rozhodnutí, provést analýzu současné situace v oblasti vývoje. Následně navrhnout vhodné prostředky, které napomohou k zlepšení situace v oblasti vývoje software a celkově ve způsobu řízení projektů. Na základě provedené analýzy byly v rámci vývoje zavedeny principy agilních metodik. S ohledem na množství požadavků a situace kdy je řešeno více projektů současně, vedení společnosti rozhodlo o zavedení podpůrného nástroje, který by celý proces vývoje usnadnil. Podpůrný nástroj by měl do procesu vývoje vnést především lepší přehled a kontrolu nad současnou situací, zároveň by měl podporovat principy a pravidla agilních metodik. Vedení společnosti, nejdříve uvažovalo o nasazení nějakého již existujícího nástroje. Následovalo období, kdy společnost ve svém prostředí testovala různé nástroje vhodné pro daný účel, ovšem z různých důvodů jako např.: nedostatek vhodných funkcí, neintuitivní uživatelské rozhraní, nebo nevhodná licenční politika, došlo vedení společnosti k závěru, že nejlepším řešením bude navrhnout a implementovat nástroj vlastní. Konkrétní důvody pro implementaci vlastního nástroje a celkový rozbor vzniklé situace budou blíže specifikovaný v kapitole popisující současný stav řešené problematiky. Požadovaný nástroj by měl být především jednoduchý, přehledný, nepřetržitě dostupný a hlavně schopný podporovat vývojové procesy dané společnosti. Právě problematika související s návrhem a implementací nástroje pro podporu projektového řízení s podporou agilních metodik vývoje, bude hlavním tématem této diplomové práce, jejíž konkrétní cíle budou detailně specifikovány v následující kapitole. 1.2 Cíl práce Hlavním cílem diplomové práce, je implementovat pro společnost Quality Management s.r.o., nástroj podporující projektové řízení se zaměřením na agilní metodiky vývoje. Pro dosažení stanoveného cíle, bude řešení obsahovat analýzu současného stavu v oblasti vývoje zmíněné společnosti. Na základě identifikovaných klíčových vlastností procesu vývoje a analýze funkcionalit dostupných nástrojů v oblasti projektového řízení, budou definovány formální požadavky na vyvíjený nástroj. Dále bude stanovena vlastní metodika pro tvorbu výsledné aplikace, ze které bude vycházet

10 1.2 Cíl práce 10 samotná implementace nástroje pro podporu projektového řízení. Výsledné řešení bude posléze ověřeno základní sadou automatizovaných testů. Závěrem práce budou zhodnoceny přínosy, ale i nedostatky implementovaného nástroje, jeho využití v praxi a možnosti dalšího rozvoje. Struktura diplomové práce se bude kromě úvodu a závěrečného hodnocení, skládat ze tří hlavních částí. V první části bude charakterizován současný stav v oblastech řešené problematiky. Druhá část bude věnována vlastní metodice vývoje, nástrojům využitých pro dosažení stanoveného cíle a formální specifikaci požadavků na vyvíjený nástroj. Třetí část prezentuje dosažené výsledky a tím poskytne základ pro závěrečné zhodnocení výsledného řešení.

11 2 SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY 11 2 Současný stav řešené problematiky 2.1 Agilní metodiky Název agilní metodiky vznikl z anglického slova Agile, který podle slovníku cizích slov znamená čilý, aktivní, horlivý. Agilní neboli lehké metodiky se začaly objevovat v polovině 90. let 20. století jako reakce na rigorózní neboli těžké metodiky, které bývaly často kritizovány za jejich obtížnou regulovanost a především pomalost. Začátkem roku 2001 v americkém Utahu, sepsalo 17 softwarových inženýrů dokument, nesoucí název Manifest agilního vývoje softwaru. Hlavním důvodem vzniku manifestu, bylo jasné vymezení definice a přístupy vývoje známé dnes pod názvem Agilní metodika vývoje software. Rozvojem a propagací agilních přístupů se zabývá, především nezisková organizace Agile Aliance, kterou založili někteří z autorů manifestu. Organizace Agile Ailance pořádá po celém světě konference zabývající se problematikou agilních metodik, z nichž za nejvýznamnější lze považovat konferenci Agile. V současnosti můžeme agilní metodiky vnímat jako plnohodnotný a úspěšný způsob vývoje softwaru a lze předpokládat, že do budoucna se bude tento trend dále rozvíjet Základní charakteristika V dnešní době existuje mnoho různých agilních metodik. Všechny vycházejí ze stejných principů: rychlý vývoj, kolektivní práce, spolupráce v týmu, komunikace se zákazníkem a především schopností přizpůsobit se během celého životního cyklu projektu. Agilní metodiky většinou rozdělují jednotlivé požadavky na menší části s minimálním plánováním a dlouhodobé plánování přímo nezahrnují. Harvey Maylor ve své knize uvádí: kvalitní plánování je z dlouhodobého hlediska nemožné a spolehlivé jsou pouze předpovědi na krátký časový rozsah (Maylor, 2010). Využívají zejména iterativního přístupu vývoje s velmi krátkými iteracemi, které trvají přibližně od jednoho týdne do jednoho měsíce. Každá z iterací zahrnuje tým lidí pracujících na vývoji včetně plánování, analýzy požadavků, návrhu, kódování, testování funkcionalit a přijímacích testů. Na závěr iterace je nová verze produktu demonstrována zákazníkovi, který poskytne zpětnou vazbu. Zpětná vazba od zákazníka minimalizuje riziko v případě, že prezentovaná část projektu dopadne neúspěchem. Pokud taková situace nastane je možné dané nedostatky pozměnit a rychle se přizpůsobit požadovaným změnám. Dalším úkolem zákazníka nebo jejich zástupců je spolupráce na dokumentaci a tvorbě požadavků. Jedna iterace nemusí přinést mnoho nové funkcionality, principem je aby vznikla nová verze s minimálním počtem chyb a následně po jejím odprezentování byla uznána zákazníkem. V agilních metodikách složení týmu nebere příliš velký zřetel na korporační hierarchii. Tým se vytváří většinou podle pravidel použité metodiky a její členové

12 2.1 Agilní metodiky 12 převezmou odpovědnost za úkoly, které musí být vykonány. Principem je, že komunikace v týmu by měla probíhat převážně tváří v tvář. Celý tým by měl pracovat na jednom stanovišti nedaleko od sebe, tím se komunikace výrazně zlehčuje. Každý tým by měl mít ve svém středu osobu, která reprezentuje zákazníka, aby vývojáři měli k dispozici odpovědi na své případné otázky týkající se vyvíjeného systému. Většina agilních metodik využívá rutinu a formální denní sešlosti mezi jednotlivými členy týmu. V krátkém briefingu si členové týmu navzájem oznamují, jakou činnost vykonali od poslední schůzky, co mají v plánu dál a jestli narazili na nějaké problémy. Výhodou častých briefingů je možnost řešit problémy téměř okamžitě potom, co nastanou. Dalším významným faktorem je psychologie práce ve skupině. Agilní metodiky považují motivaci lidí ve skupině za klíčový předpoklad pro úspěch celého projektu. Proto se agilní metodiky zaměřují především na pracovní prostředí, zajištění podpory pro všechny členy týmu a jejich komunikaci jak mezi sebou tak i se zákazníkem. Z pohledu agilních metodik mají lidé větší význam, než dodržené postupy, produkované dokumenty nebo používané nástroje. Václav Kadlec ve své knize Agilní programování Metodiky efektivního vývoje software uvádí, že mezi zásadní principy agilních metodik, patří (Kadlec, 2004): Iterativní a inkrementální vývoj s krátkými iteracemi: plán je sestaven tak, že nové funkce se dodávají často (i denně). Zákazník je průběžně konfrontován s novými konfiguracemi. Výhodou tohoto přístupu je skutečnost, že zákazník pořád vidí, v jakém stavu je vývoj a na jakých funkcionalitách tým zrovna pracuje. Nemůže se tak stát, že by na konci dostal něco jiného, než očekává. Kromě tohoto nedostane výrobek až na samotný konec ve formě velkého třesku. Důraz na přímou, osobní komunikaci v týmu: stejně jako v jiných sociálních skupinách, i v pracovních týmech je původcem nejzávažnějších problémů nefungující komunikace. Agilní přístupy se pokoušejí integrovat komunikaci přímo do procesu jako jeho nedílnou součást (časté schůzky, párové programování apod.). Výhodou je dřívější odhalení problémů, a to jak uvnitř týmu (analytik se s programátorem nemá rád), tak i v samotném projektu (programátor má ve svém modulu chybu, ale bál se jí přiznat kvůli strachu z ponížení před ostatními). Nepřetržité sepjetí a komunikace se zadavatelem, resp. uživatelem: zákazník by ideálně měl být členem vývojového týmu, měl by komunikovat s vývojovým týmem, spolupodílet se na návrhu a spolurozhodovat o testech. Rigorózní, opakované, průběžné automatizované testování: vzhledem k častým změnám systému je nutné průběžně ověřovat jeho správnost. Testy by měly být automatizované a měly by být napsány dokonce před implementací testovaných částí. Vzhledem ke zrychlovaným fázím analýzy a návrhu

13 2.1 Agilní metodiky 13 je testování zhola nezbytné a je jediným jistým prostředkem zachování kvality aplikace Porovnání agilních a rigorózních metodik Jak již bylo zmíněno v úvodu této práce, dle výsledku průzkumu realizovaného Scottem W. Amblerem, softwarové projekty vyvíjené tradičním způsobem selhávají častěji, než projekty vyvíjené za pomoci metodik agilních. Jednou z hlavních příčin neúspěchu může být, že většina tradičních metodik příliš spoléhala na schopnost definovat přesně své požadavky již na první schůzce a dále pak víra v to, že klient v průběhu realizace nezmění své požadavky. Vývojové týmy se následně velmi často setkávali s potížemi ve fázi předvádění produktu klientovi, kdy považují daný projekt za hotový. Konkrétně se jedná o moment, kdy ze strany klienta vyzní slova takto jsme si to rozhodně nepředstavovali. V případě že tato situace opravdu nastane, projekt se rázem může vrátit zpět na začátek vývoje, jenže s výraznou změnou tým již vyčerpal většinu přidělených finančních prostředků a zároveň také času během, kterého měl být projekt dokončen. Hlavní posun agilních metodik od rigorózních spočíval v odlišném přístupu k procesu samotného vývoje. Zatímco rigorózní metodiky kladly velký důraz na tzv. těžké procesy jako např.: definice formálních náležitostí projektu, tvorba dokumentace, detailní specifikace požadavků v začátcích vývoje. Na druhé straně agilní přístupy nabízejí spíše jednoduché techniky a nástroje, zabývající se převážně problematikou komunikace, spolupráce, flexibilní odezvou na změnu a efektivitou samotného vývoje. Obrázek 1: Srovnání agilních a tradičních přístupů

14 2.2 Společnost Quality Management s.r.o Stručný přehled nejběžnejších agilních metodik Během let bylo vyvinuto velké množství agilních metodik, řídících se na základě principů Manifestu agilního vývoje. Nové metody se neustále vyvíjí, některé jsou původní, jiné vycházejí ze starších agilních metodik. Mezi nejznámější agilní metodiky bych zařadil následující výčet: SCRUM Development Process Extrémní programování (Extreme Programming, XP) Adaptivní vývoj softwaru (Adaptive Software Development) Vlastnostmi řízený vývoj (Feature-Driven Development) Lean Development Crystal metodiky (Crystal Methodologies) Dynamic System Development Method Testy řízený vývoj (Test-Driven Development) 2.2 Společnost Quality Management s.r.o. Společnost Quality Management s.r.o., je mladá a moderní softwarová firma, která se zabývá především vývojem informačních systémů a poskytováním poradenských služeb související s řízením podniku a oblastí kvality. Společnost byla založena v roce 2010 a v současnosti působí především v České republice. Hlavní sídlo společnosti se nachází v Brně. Ve společnosti pracuje v současné době 7 zaměstnanců. Především v důsledku dynamického rozvoje zakázek a časové náročnosti řešených projektů lze v blízké budoucnosti očekávat nárůst zaměstnanců, především v oblasti vývoje. Firma se zabývá primárně implementací podnikového ERP systému DIRECTIS, který nabízí jako svůj hlavní produkt, ale svým klientům poskytuje také možnost zakázkového vývoje informačních systému šitých na míru. Všechny softwarové produkty společnosti jsou postaveny na platformě technologie Microsoft SharePoint, díky čemuž je zajištěná také plná integrace s nástroji Microsoft Office. Společnost se snaží klást velký důraz na sledování aktuálních trendů v oblasti své činnosti, pracovat na neustálém zlepšování svých produktů a vycházet jak ze zkušeností vlastních, tak svých klientů Současná situace v oblasti řízení projektů V nynější době řeší společnost Quality Management s.r.o. jeden hlavní projekt a to vývoj ERP systému DIRECTIS, jehož moduly se neustále rozrůstají a práce na projektu se odhaduje minimálně na další rok. Současně probíhají v rámci možností další zakázkové projekty s různou časovou náročností na implementaci.

15 2.2 Společnost Quality Management s.r.o. 15 Již v úvodu práce bylo nastíněno, že se společnost začala koncem roku 2011 potýkat s určitými problémy v oblasti vývoje. Problémy vznikly především na základě dynamického rozvoje zakázek, větší časové náročnosti řešených projektů a rostoucímu počtu nových požadavků. Vzniklá situace vedla ke: snížení kvality a zvýšení chybovosti implementovaných komponent, prodlevám při dodání smluvených funkcionalit, neočekávanému růstu rozsahu práce, přetěžování zaměstnanců. Zmíněné důvody přiměly společnost k rozhodnutí změnit a zmodernizovat proces vývoje. Začátkem roku 2012, byly na základě předcházející analýzy aplikovány do procesu vývoje principy metodiky SCRUM v kombinaci s prvky metodiky KANBAN. Se zavedením nové metodiky se situace v oblasti projektového řízení sice zlepšila, ovšem i nadále přetrvávaly určité problémy. Problémy spočívaly v tom, že se v některých chvílích pracovalo současně na více projektech a množství požadavků bylo stále velké, stával se proces vývoje místy nepřehledný. V tomto období využívala společnost pouze vlastní, jednoduchý webový nástroj, který umožnil evidovat požadavky a dokumenty související s vývojem. Bohužel možnosti nástroje neodpovídaly náročnosti řešených projektů a principům agilního vývoje. Například (Rosenau, 2010) uvádí: Používat počítačový software k řízení projektů není totéž jak efektivně řídit projekt. Nicméně s pomocí tohoto softwaru může vývojový tým odvést lepší práci. S ohledem na zmíněné aspekty, se vedení společnosti rozhodlo pro zavedení kvalitního nástroje, který by podporoval celý proces vývoje a zároveň principy využívaných agilních metodik SCRUM a KANBAN. Vedení společnosti nejdříve uvažovalo o nasazení již existujícího nástroje. Následovalo období, kdy společnost vybrané nástroje testovala ve svém prostředí, ale v závěru došla k názoru, že žádný z poskytovaných nástrojů přesně neodpovídá požadavkům společnosti. Výsledky z analýzy nástrojů a konkrétní důvody vedoucí k implementaci vlastního nástroje budou uvedeny v následujících kapitolách 2.3 a 2.4. Nejdříve však budou detailně představeny principy vybraných agilních metodik v návaznosti na prostředí procesu vývoje uvedené společnosti Základní charakteristika metodik SCRUM a KANBAN SCRUM Development Process SCRUM Development Process patří do rodiny agilních metodik, jejímž hlavním cílem je především zvýšení efektivity při vývoji softwaru. První nástin metodiky SCRUM byl představen Kenem Schwaberem a Mikem Beedlem v roce 1995, ovšem oficiálního představení se dočkal až v roce Samotný název SCRUM není zkratkou, jak by mohlo vyplívat z názvu často uváděného velkými písmeny, ale výraz používaný v Rugby. Vznik názvu popsal ve své knize Václav Kadlec následovně. ázev me-

16 2.2 Společnost Quality Management s.r.o. 16 todiky vznikl a anglického slova Scrum, jehož význam spadá do rugby a označuje skrumáž, mlýn, projevující se kumulací několika (typicky mnoha) hráčů na jednom místě za účelem společného dotlačení míče na požadovanou pozici. Paralela s vývojem softwaru je jednoznačná: cílem vývojového týmu není nic jiného než dotlačení míče na požadovanou pozici, tedy dokončení aplikace v podobě, jakou vyžaduje zákazník. Celý vývojový proces si v metafoře metodiky SCRUM lze představit jako rugbyový zápas a vítězstvím není nic jiného nežli spokojený zákazník (Kadlec, 2004). Scrum ve své podstatě není metodika, ale pouze rámec (framework), na jehož základě může vývojový tým použít techniky a procesy, které se mu již osvědčili (Schwaber, 2010). Může se tedy zdát, že existuje mnoho různých variant SCRUMU, v podstatě se však jedná o stále stejný SCRUM Framework, který používá pouze jiné vnitřní procesy a techniky. SCRUM můžeme považovat převážně za manažerskou metodiku, rozhodně se nejedná o žádný konkrétní návod jak programovat a nedefinuje konkrétní postupy či nástroje. Zabývá se převážně problematikou komunikace, spolupráce, flexibilní odezvou na změnu a efektivitou samotného vývoje. Stejně jako většina předchozích metodik i SCRUM vychází z principů: flexibility, iterativního vývoje, pravidelných dodávek prototypů nebo částí aplikace, následným sbíráním zpětné vazby od zákazníka a snahou adekvátně reagovat na změny během průběhu vývoje. Především komunikace a dobré vztahy se zákazníkem mají na agilní proces vývoje velmi pozitivní vliv (Aalst a kol., 2009). SCRUM v kombinaci s metodikou KANBAN Počátky metodiky KANBAN koření podobně v Japonsku. KANBAN je metodika, která předepisuje naprosté minimum technik a tím ponechává vývojovému týmu maximální volnost. Metodika KANABAN vychází podle (Kniberg, Skarin 2010) ze tří základních vlastností: Vizualizace pracovního toku tzv. Workflow - Požadavky na systém se rozepíší na jednotlivé úkoly. Úkoly se napíšou na karty a posléze přilepí na tabuli či nástěnku. Úkoly jsou na tabuli členěny do sloupců podle jednotlivých fází pracovního toku. Přiřazení limitů pro jednotlivé fáze pracovního toku. Měření průměrného času dokončení jedné položky tzv. Lead time. U metodiky KANBAN se vztahuje omezení na množství práce k dané fázi pracovního postupu, oproti tomu SCRUM jej vztahuje k aktuální iteraci. Mezi další rozdíly patří zejména absence mnohých prvků vyskytující metodiky SCRUM v metodice KANBAN, jedná se např. o: časové odhady, určení priority u úkolů, definice rolí (KANBAN nedefinuje žádné role).

17 2.2 Společnost Quality Management s.r.o. 17 Metodiku KANBAN je vhodné využít především na projekty, u kterých lze dopředu předvídat velmi častou a rychlou úpravu požadavků. Metodika SCRUM neumožňuje změnu požadavků v průběhu sprintu, ale až po jeho dokončení, tím je zajištěna nerušenost a soustředěnost týmu. Obvykle je tato vlastnost velmi ceněna, ale v případě některých projektů, může být spíše na škodu. Velmi často se při spojení zmíněných metodik využívá aspekt, kdy je v rámci sprintu umožněno měnit požadavky. Velmi oblíbenou technikou KANBANU, která je v rámci metodiky SCRUM velmi populární, představuje lepení karet s úkoly na tabuli či nástěnku rozdělenou na sloupce. Rozčlenění sloupců může být kupříkladu následující: To-Do, probíhající, hotové. Tato technika velmi zvyšuje přehlednost řešených požadavků Vývojový tým Vývojový proces společnosti rozlišuje ve svém pracovním týmu celkem šest specifických rolí vycházejících z principů metodiky SCRUM. Následující popis jednotlivých rolí vychází od autorů metodiky tak, jak uvedli v (Schwaber, Beedle 2010). Scrum Master Scrum Master je odpovědný za celý proces vývoje. Dohlíží na dodržování pravidel a principů v souladu s praktikami metodiky Scrum. Má na starost komunikaci s vývojáři, zákazníkem a managementem. Hlavním úkolem Scrum Mastera je zajistit plynulý proces vývoje a popřípadě odstranit vzniklé překážky. Pokud Scrum Master není schopen vzniklé problémy odstranit sám, musí zajistit kompetentní osobu, která daný problém dokáže odstranit. Vlastník produktu (Product Owner) Vlastník produktu je role stojící na rozhraní někde mezi zákazníkem a dodavatelem. Do role je zvolen na základě společného rozhodnutí Scrum Mastera, Zákazníka a Managementu. Má hlavní slovo při rozhodování o položkách v Product Backlogu. Zodpovídá především za aktuální stav Product Backlogu a zajišťuje jeho dostupnost ostatním členům vývojového týmu. Vlastník produktu by měl striktně dodržovat zákaz přidávání položek v průběhu sprintu. Požadavky na systém se sice mohou často měnit, nebo přidávat ale pouze v rámci Product Backlogu, když nejsou zařazeny v probíhajícím sprintu. Scrum tým (Scrum Team) Scrum tým je hlavní vývojová síla, která především implementuje požadované funkcionality. Tým by se měl sám organizovat a jeho hlavním úkolem je splnit cíle daného sprintu v určeném čase. Dalšími úkoly týmu je spoluúčast na výběru požadavků z Product Backlogu daného sprintu, odhad pracnosti a času potřebného k implemen-

18 2.2 Společnost Quality Management s.r.o. 18 taci dané vlastnosti, sestavení časového plánu řešení a nacházení překážek narušující průběh vývoje. Zákazník (Customer) Zákazník nebo se podílí především na sestavování seznamu položek v Product Backlogu. Dalším jeho úkolem je poskytnout zpětnou vazbu na základě prezentace systému či některé jeho části. Management Mezi hlavní kompetence Managementu patří především obchodní jednání a uzavírání smluv. Svou roli hraje také při důležitých rozhodnutí, které mohou ovlivnit celý projekt. Podílí se na sestavování požadavků, cílů celého projektu i jednotlivých etap Používané artefakty V rámci procesu vývoje, využívá zmíněná společnost určité artefakty, které vychází z principů metodiky SCRUM a detailně jsou představeny v následujícím textu. Sprint Sprint je základní stavební jednotkou metodiky SCRUM a první typ iterace. Délka trvání jednoho sprintu se ve v procesu vývoje uvedené společnosti povětšinou pohybuje v rozmezí jednoho týdne až jednoho měsíce. Celkový počet sprintů se různí v závislosti na projektu. Každému sprintu předchází tzv. Sprint Planning Meeting, kde se definují úkoly a cíle pro daný sprint. Podle (Kniberg, 2007) by měl výstup plánovací schůzky obsahovat následující výčet prvků: cíl sprintu (slovní popis hlavního požadovaného výsledku), sprint backlog (požadavky, které se budou v rámci sprintu řešit), datum zahájení a ukončení sprintu, termín prezentace, čas a umístění pravidelných denních schůzek, složení vývojového týmu. Úkoly se určí na základě požadavků umístěných v Product Backlogu. Jednotlivé požadavky jsou vybírány podle logických celků a především priority určené zákazníkem. Požadavky vybrané do daného sprintu jsou následně přesunuty do Sprint Backlogu. Vývojový tým následně odhaduje pracnost jednotlivých úkolů a naplánuje průběh prací. Na konci sprintu se opět koná schůzka celého týmu Sprint Review, kde se proberou události vzniklé v průběhu sprintu, požadavky které se podařilo splnit popřípadě

19 2.2 Společnost Quality Management s.r.o. 19 nesplnit a důvody vedoucí k vzešlým situacím. Nejdůležitější částí závěru každého sprintu je prezentace dosažených výsledků a to jak vzájemně v rámci vývojového týmu tak především zákazníkovi. Product Backlog Product backlog v sobě soustředí požadavky na funkcionalitu systému. Zodpovědnost za Product Backlog nese především vlastník produktu (Product Owner). Product Backlog se v průběhu celého vývoje může měnit. Zákazník vždy přiřazuje definovaným požadavkům určitou prioritu. Z důvodu přehlednosti je Product Backlog roztříděn podle logických a funkčních celků. Pořadí v jakém budou požadavky v jednotlivých sprintech řešeny, určuje vývojový tým ve spolupráci se Scrum Masterem s přihlédnutím na prioritu určenou zákazníkem. Product backlog by měl podle (Cohn, 2009) dodržovat zásady DEEP: Detailed appropriately spolu s rostoucí prioritou položek, a tedy i zvyšující se pravděpodobností jejich brzkého zařazení do Sprintu, roste i podrobnost rozpracovanosti. Z počátku se jedná o rozsáhlé uživatelské příběhy tzv. eposy ty se postupně s rostoucí prioritou zpřesňují. Estimated každé položce je určen předběžný odhad pracnosti a nejen seznam pracovních činností. Emergent Product Backlog se mění během celého průběhu vývoje. Prioritized položky, které by měli přinést systému největší hodnotu, mají nejvyšší prioritu. Release Backlog Release Backlog seskupuje požadavky z Product Backlogu, potřebné pro určité vydání tzv. Release. Sprint Backlog Na začátku každého sprintu jsou vybrány požadavky, které budou v rámci tohoto sprintu řešeny a jsou přeneseny do Sprint Backlogu. Položka přiřazená do Sprint Backlogu se následně rozpracuje do větších detailů a je jí přiřazen určitý časový odhad. Výhodou Sprint Backlogu je detailnější pohled na poměr doposud odvedené či naopak neodvedené práce. Daily Scrum Daily Scrum je denní schůzka týmu tzv. Scrum Meeting. Schůzku vede Scrum Master a účastní se jí celý vývojový tým. Na každé schůzce jsou jednotlivým členům týmům pokládaný tři základní otázky.

20 2.2 Společnost Quality Management s.r.o. 20 Co jsi včera udělal? Co máš v plánu dělat dnes? Vyskytly se nějaké problémy? Díky takto krátkým iteracím je celý tým neustále informován o dosavadním průběhu vývoje a je schopen rychle reagovat na vzniklé problémy. Doba trvání jedné schůzky by neměla přesáhnout více jak hodinu času. V rámci společnosti není striktně dodržováno pravidlo každodenní schůzky, ale schůzky jsou svolávány na základě požadavku Scrum Mastera či členů Scrum týmu. User Story User story je požadavek, ve kterém zákazník jednou nebo více větami definuje určitou vlastnost, které chce v daném systému dosáhnout. Všechny User Stories jsou dále zpracovány Vlastníkem produktu s možnou konzultací ostatních členů vývojového týmu a posléze zařazeny do seznamu Product Backlog. Obrázek 2: Iterace v rámci metodiky SCRUM (Buchalcevová, 2009) Proces a fáze vývoje Samotný proces vývoje je postaven především na základě metodiky SCRUM a dle jejich principů rozděluje proces vývoje na tři hlavní fáze: předehra, hra a dohra. První a třetí fáze probíhají lineárně a prostřední fáze hra, se iterativně opakuje v rámci jednotlivých sprintů.

21 2.2 Společnost Quality Management s.r.o. 21 Předehra Fáze předehry se dělí na dva hlavní kroky: prvním je Plánování a druhým je Návrh a architektura. Plánování v sobě zahrnuje tvorbu Product Backlogu, obsahujícího všechny doposud známe požadavky na systém. Požadavky mohou být definovány zákazníkem, nebo členy vývojového týmu. Zákazník přiřadí prioritu definovaným požadavkům a vývojový tým následně odhadne úsilí potřebné k jejich implementaci. Tyto odhady jsou v počátcích většinou nepřesné, všechny hodnoty se v průběhu vývoje upravují a zpřesňují podle aktuální situace. Požadavky se následně setřídí podle logických a funkčních celků v závislosti na jejich určené prioritě. Mezi další úkoly procesu plánování patří: sestavit projektový tým, definovat vývojové nástroje, vymezit zdroje a určit postup pro schválení výsledného produktu. Návrh a architektura definuje vytvářený systém na vysokém stupni abstrakce. Jako základ systému je možné považovat již vytvořený Product Backlog. Provádí se analýza, ve které se řeší především: prostředí zadavatele, jeho obchodní procesy a studium všech relevantních dokumentů. Na závěr jsou tvořeny předběžné plány pro obsah jednotlivých verzí systému. Hra Fáze hry je hlavní částí procesu vývoje a právě zde je implementován samotný produkt. Hra je členěna do sprintů, které probíhají iterativně. Jejich počet a délka je různá v závislosti na konkrétním projektu. Délka jednoho sprintu se, zpravidla pohybuje v rozmezí jednoho týdne až jednoho měsíce. V rámci sprintu probíhají klasické fáze vývoje: sbírání požadavků, analýza, návrh, vývoj, testování, prezentace, popřípadě předání. Na začátku každého sprintu zákazník společně s vývojovým týmem vybere požadavky, které budou v rámci daného sprintu implementovány. Vývojový tým následně provede detailní analýzu vybraných požadavků, odhadne jejich časovou náročnost a určí plán pro jejich tvorbu. Na závěr každého sprintu jsou dosažené výsledky prezentovány zákazníkovi a na základě jejich zpětné vazby, jsou popřípadě zaznamenány návrhy na změnu funkcionality. Důležitou součástí každého sprintů jsou denní schůzky Daily Scrum, kde vývojový tým řeší otázky typu: co bylo od poslední schůze uděláno, co se dělat bude a jestli se nevyskytly nějaké problémy. Dohra Fáze dohry nastává v okamžiku, kdy je celý projekt kompletně zpracovaný. V této fázi se vytvoří finální verze produktu. Provede se finální integrace a závěrečné testování. V této fázi je také dokončena podstatná část dokumentace, která se v průběhu vývoje příliš neřeší, posléze je předána zákazníkovi.

22 2.3 Srovnání nástrojů podporující agilní vývoj 22 Obrázek 3: Fáze vývoje metodiky SCRUM 2.3 Srovnání nástrojů podporující agilní vývoj Agilní vývoj výslovně nevyžaduje používání speciálních podpůrných nástrojů. Metodiky agilního vývoje lze využívat i s použitím běžného textového editoru, systému indexních karet pro zaznamenání požadavků, nebo jen obyčejný papír a tužku. Nicméně v případě kdy členové týmu nejsou úplně v pravidelném denním styku, řeší se více projektů současně, nebo množství požadavků roste a neustále se mění, může se vývojový tým ocitnout v situaci, kdy přestane mít přehled nad průběhem své práce a nastane chaos. Takovým situacím je možné předejít, použitím vhodného nástroje pro podporu agilního vývoje, který bude evidovat všechny potřebné informace o řešených projektech v aktuálním stavu. V současnosti je na softwarovém trhu k dispozici mnoho takových nástrojů. Ovšem s jejich rostoucím počtem, roste také problém volby vhodného nástroje, který by nejlépe vyhovoval prostředí dané společnosti. Cílem této kapitoly bude stručné seznámení s výsledky analýzy nástrojů pro podporu agilního vývoje. Než budou prezentovány výsledky samotné analýzy, je důležité zmínit skutečnost, že hlavním kritériem společnosti při výběru nástroje byla nejnižší možná cena. Proto byly porovnávány především tzv. komunitní verze nástrojů (Community Tools). Komunitní verze, značí většinou produkt stejného typu, ale s určitými omezeními. Jejich výhodou oproti standardním verzím těchto nástrojů je fakt, že jsou většinou distribuovány zdarma nebo za nízký poplatek. Výsledky analýzy budou prezentovány formou přehledné tabulky, kde budou srovnány zvolená kritéria nad vybranými produkty. Zvolená kritéria uvedená v porovnávací tabulce byla vybrána na základě specifických požadavků společnosti a bu-

23 2.4 Důvody vedoucí k implementaci vlastního nástroje 23 dou rozdělena do tří hlavních sekcí. Obecné obecná kritéria produktu. Funkcionalita přehled poskytovaných funkcí. Vlastní dojem zde bude uvedeno číselné hodnocení vybraných kritérií, které bude reprezentovat vlastní názor na kvalitu nástroje. Hodnotící stupnice bude mít rozmezí od 0 do 5 bodů. Větší počet bodů představuje lepší kvalitu daného kritéria. Analyzovány byly nástroje od společností Rally Software, VesrionOne, Target- Process a Jira. Obrázek 4: Srovnání nástrojů s podporou agilního vývoje 2.4 Důvody vedoucí k implementaci vlastního nástroje Z tabulky uvedené v předcházející kapitole, která porovnává jednotlivé nástroje sice vyplývá že většina produktů poskytuje požadovanou funkcionalitu, ovšem uživatelská přívětivost, přehlednost, a konkrétní řešení dané funkcionality neodpovídalo představám vedení společnosti. Spokojenost se zmíněnými aspekty je v tabulce jasně prezentována v části vlastní hodnocení, kde jsou většinou uvedeny průměrné až podprůměrné hodnoty. Výjimku představoval pouze produkt od společnosti Jira, který byl mimochodem částečnou inspirací při tvorbě vlastní aplikace, ovšem ani on nebyl nakonec vybrán. Mezi hlavní důvody, které vedly společnost k rozhodnutí, implementovat vlastní nástroj můžeme zařadit následující aspekty.

24 2.5 Neformální specifikace 24 Vysoká cena licenční politika u plných tzv. Enterprie verzí uvedených produktů byla příliš nákladná. Počet uživatelů u všech produktů není možné, aby s nástrojem pracovalo více než 10 uživatelů. Jelikož, má společnost Quality Management s.r.o. v plánu rozšířit počet zaměstnanců podílejících se na vývoji produktů, není počet uživatelů z dlouhodobého hlediska dostačující. Počet projektů většina zmíněných nástrojů neumožňuje pracovat s více jak jedním projektem současně. Nemožnost dalšího rozšíření nástroje není možné v případě nutnosti rozšířit či upravit dle specifických požadavků procesu vývoje uvedené společnosti. 2.5 Neformální specifikace Jak již bylo zmíněno v úvodu práce, hlavní cíl spočívá v implementaci nástroje, který bude ve společnosti Quality Management s.r.o. podporovat řízení projektů a to především proces vývoje. V následujících odstavcích budou nastíněny základní požadavky na systém, které vznikly po konzultaci s vedením společnosti. Zadavatel požaduje nástroj, který bude jednoduchý, intuitivní, vnese větší přehled do aktuální situace vývoje a především zefektivní projektové řízení. Nástroj bude realizován jako webová aplikace, která bude funkční a dostupná z kteréhokoliv počítače s přístupem k internetu, nebo firemního intranetu. Nástroj bude v maximální možné míře podporovat definovaný proces vývoje, jehož principy vycházejí z agilních metodik SCRUM a KANBAN. Kritéria, zohledněná při návrhu nástroje, zahrnují: definovanou strukturu vývojového týmu a využívané artefakty uvedené v kapitolách a Nástroj bude sloužit především pro evidenci projektů, a sledování jejich průběhu vývoje. Ke každému projektu bude možné přiřadit libovolné množství požadavků na vyvíjený systém. V rámci projektu budou iterativně zadávány sprinty, do kterých se přenesou aktuálně vybrané požadavky pro implementaci. Požadavek představuje funkcionalitu vyvíjeného systému zapsanou v jazyce srozumitelném zákazníkovi. Z důvodů přehlednosti a usnadnění vývoje, bude možné požadavek detailně rozvrhnout a rozdělit na drobnější úkoly. Nástroj umožní k evidovaným požadavkům a jejich úkolům určit odpovědné osoby. Sprint je první typ iterace, který se pravidelně opakuje a lze do něj přiřadit libovolné množství požadavků. V rámci každého sprintu bude možné uchovat informace o první plánovací schůzce a závěrečném vyhodnocení sprintu. Velimi důležitou součástí systému bude tzv. User Dashboard, který bude představovat pohled aktuálně přihlášeného uživatele. V tomto zobrazení uvidí uživatel pohromadě všechny projekty, sprinty, úkoly, upozornění a další užitečné informace, související právě s jeho osobou. Mezi další požadavky na implementaci vyvíjeného nástroje patří především:

25 2.5 Neformální specifikace 25 Knihovna dokumentů umožňující v systému evidovat dokumenty související s vývojem. Kalendář, který bude představovat komplexní řešení pro správu času a informací. Osobní poznámky, kam může uživatel zapsat libovolný postřeh, určený pouze jemu. Informace nebo upozornění, které může vytvořit uživatel pro ostatní členy týmu. Vyhledávání libovolného datového obsahu v aplikaci. Filtrování dat nad evidovanými seznamy (Projekty, Požadavky, Úkoly, Sprinty atd.). Možnost tvorby různých pohledů nad zobrazenými daty. Integrace s produkty MS Office. Grafické znázornění, průběhu vývoje v rámci jednotlivých sprintů. Reporty, reprezentující statické informace a přehledy z evidovaných položek systému. Neformální specifikace představuje pouze základní popis požadovaných vlastností systému, detailně jsou všechny požadavky na systém popsány v následující kapitole s názvem Formální specifikace systému.

26 3 METODIKA PRÁCE 26 3 Metodika práce 3.1 Formální specifikace systému Vymezení uživatelských rolí Definice uživatelských rolí systémů vyplývá především z rolí používaných v samotném procesu vývoje společnosti, jejichž význam byl podrobně definován v kapitole Konkrétně budou v systému figurovat následující uživatelské role: Administrátor, Management, Scrum Master, Vývojář, Vlastník produktu, Zákazník. Přesné definice oprávnění pro jednotlivé uživatelské role budou uvedeny v kapitole Vlastní práce, kde jsou prezentovány dosažené výsledky Funkční požadavky Projekty Základním prvkem systému je položka projekt, se kterou budou přímo či nepřímo souviset všechny další komponenty aplikace. Systém umožní správu jednotlivých projektů, což zahrnuje možnost jejich vytváření editaci, změnu příslušného stavu, ukončení nebo popřípadě definitivní odstranění. Jednotlivé projekty o sobě budou evidovat patřičné informace jako např.: název, stručný popis, kódové označení, důležité časové termíny, seznam členů vývojového týmu nebo informace o zákazníkovi. Uživatelé si mohou prohlížet přehled všech projektů a jejich detail, díky čemuž mají přístup k potřebným informacím a přehled o aktuální situaci. K projektu bude možné přiřadit libovolný počet sprintů a požadavků. Dalším důležitým aspektem bude vlastní knihovna dokumentů každého projektu. V knihovně budou evidovány všechny dokumenty a grafické návrhy související s daným projektem. Požadavky (Backlog) V seznamu požadavky neboli tzv. Baclogu budou evidovány všechny funkční požadavky vyvíjených produktů. Každý projekt bude mít svůj samostatný seznam požadavků. Po vytvoření požadavku se vyplní základní údaje, které se v průběhu vývoje aktualizují. Po vytvoření požadavku se nejdříve definuje stručný význam požadavku, priorita, řešitelé, předběžný odhad, termín splnění a agenda zastupující

27 3.1 Formální specifikace systému 27 logický celek, pod který daný požadavek spadá. Požadavky budou rozděleny na tři hlavní kategorie, podle situace ve které se momentálně nachází. Ihned po vytvoření bude požadavek umístěn v kategorii Product Backlog, po zařazení do sprintu v kategorii Sprint Backlog a v momentě kdy je připraven pro nasazení v kategorii Release Backlog. Požadavek může být pro větší přehlednost rozdělen na více úkolů. Požadavek bude obsahovat několik specifických atributů, které budou v průběhu vývoje aktualizovány buď uživatelem, nebo automaticky. Konkrétně se jedná o atributy: Zbývající odhad, Počet odpracovaných hodin, Hotovo (bude určeno procentuálně) a Stav, ve kterém se požadavek aktuálně nachází. Následující výčet prezentuje další funkcionality týkající se artefaktu požadavky. Možnost připojit dokumentové přílohy. Uživatelé systému mohou přidat libovolný počet svých komentářů. Verzování jednotlivých požadavků, při změně či aktualizaci dat. Úkoly Jednotlivé úkoly jsou vázány k požadavku řešeného projektu. Jejich hlavním smyslem je logické rozdělení požadavku na menší části, a tak jeho implementaci usnadnit a zpřehlednit. Za každý úkol je odpovědná pouze jedna osoba, která jej patřičným způsobem řeší. Po vytvoření úkolu se nejdříve definuje stručný popis požadavku, stav či odpovědný pracovník. Uživatel řešící úkol, postupně v průběhu implementace aktualizuje hodnoty atributů: Zbývající odhad, Počet odpracovaných hodin, Hotovo (bude určeno procentuálně). Na základě zmíněných atributů se budou automaticky aktualizovat stejné atributy evidované u nadřazeného požadavku. Následující výčet prezentuje další funkcionality týkající se artefaktu úkoly. Možnost připojit dokumentové přílohy. Uživatelé systému mohou přidat libovolný počet svých komentářů. Verzování jednotlivých úkolů, při změně či aktualizaci dat. Sprinty Sprint je základním stavebním kamenem metodiky SCRUM a jedná se o první typ iterace, který se pravidelně opakuje. V rámci každého projektu bude možné zadat libovolný počet sprintů. Na začátku každého sprintu se určí cíl sprintu, definují se informace o termínu zahájení, ukončení a předpokládané prezentaci výsledků. Dále se stanoví členové vývojového týmu, kteří se sprintu zúčastní a vyberou se požadavky, které budou v rámci sprintu řešeny. Ke každému sprintu bude možné přidat a uchovat informace o první plánovací schůzce sprintu (Sprint Planning Meeting) a o závěrečném vyhodnocení sprintu (Sprint Review Meeting). V rámci sprintu budou evidovány údaje o jeho průběhu, konkrétně o zbývajícím časovém odhadu, odpracovaném čase a množstvím dokončené práce odhadované v procentech.

28 3.1 Formální specifikace systému 28 Důležitou komponentu bude představovat pracovní prostředí, které uživatelům usnadní aktualizaci požadavků v průběhu sprintu. Uživatelské rozhraní bude vycházet z principů metodiky KANBAN, konkrétně z vizualizace pracovního toku (Workflow), kdy jsou jednotlivé požadavky rozděleny do sloupců podle jejich stavu. Sloupce budou rozděleny následovně: nezahájeno, probíhá, dokončeno. Ke každému sprintu bude možné připojit libovolný počet dokumentových příloh. BurnDown Chart BurnDown Chart je zobrazovací prvek, který navazuje na sprint projektu. Jeho hlavním úkolem je znázornit průběh práce daného sprintu v závislosti na čase. Hodnoty zobrazované v grafu budou denně aktualizovány automaticky nebo na pokyn uživatele. UserDasboard Specifické zobrazení aktuálně přihlášeného uživatele na titulní straně aplikace. V tomto zobrazení uvidí uživatel pohromadě v přehledném rozložení všechny projekty, sprinty, požadavky, úkoly, osobní poznámky, plánované akce, upozornění a další užitečné informace související právě s jeho osobou. Zobrazení umožní rychlý přístup ke všem potřebným položkám a jejich případné editaci. Hlavním cílem ovládacího prvku je poskytnout uživateli rychlý přehled o stavu právě probíhajících činnostech. Kalendář Kalendář, který bude představovat komplexní řešení pro správu času a informací. Cílem kalendáře bude zachytit všechny plánované aktivity jako např.: schůzky, dovolenou, důležité termíny a další různé činnosti. Knihovna dokumentů Knihovna dokumentů umožní v systému evidovat dokumenty různých formátů jak v textové tak grafické podobě. Po vytvoření projektu se automaticky vygeneruje do knihovny dokumentů jeho samostatná složka. Ve složce projektu bude možné soubory ukládat do libovolné struktury. Mezi další funkce knihovny dokumentů patří možnosti. Uzavření dokumentu v případě jeho probíhající úpravy. Evidence metadat souvisejících s dokumentem. Verzování dokumentu.

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

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

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

4IT445 - AGILNÍ VÝVOJ WEBOVÝCH APLIKACÍ AGILNÍ METODIKY VÝVOJE SW ING. JAN ČERNÝ

4IT445 - AGILNÍ VÝVOJ WEBOVÝCH APLIKACÍ AGILNÍ METODIKY VÝVOJE SW ING. JAN ČERNÝ 4IT445 - AGILNÍ VÝVOJ WEBOVÝCH APLIKACÍ AGILNÍ METODIKY VÝVOJE SW ING. JAN ČERNÝ 1 METODIKY K ČEMU JSOU DOBRÉ? BUĎ NEMÁTE ŽÁDNOU NEBO STRIKTNÍ / RIGORÓZNÍ POSTUPY NĚCO MEZI TÍM: AGILNÍ PŘÍSTUP K ČEMU

Více

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ Předmětem softwarového inženýrství jsou metodiky pro řízení vývoje softwaru. Proč potřebujeme tyto metodiky? Čím je vývoje softwaru specifický oproti jiným odvětvím? SOFTWAROVÉ

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

Více

Návrh softwarových systémů - úvod, motivace

Návrh softwarových systémů - úvod, motivace Návrh softwarových systémů - úvod, motivace Jiří Šebek, Martin Tomášek Návrh softwarových systémů (B6B36NSS) Obsah Motivace Integrace s ostatními obory SI Kdo / co ovlivňuje cílový SW Modely, metodiky

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

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 Znalosti Schopnosti Cvičení

Více

Metodika analýzy. Příloha č. 1

Metodika analýzy. Příloha č. 1 Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,

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

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

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

Více

Komunikační strategie a plán rozvoje portálu portal.gov.cz

Komunikační strategie a plán rozvoje portálu portal.gov.cz Příloha č. 2 Výzvy - Detailní popis předmětu VZ Komunikační strategie a plán rozvoje portálu portal.gov.cz V rámci dodávky vznikne dokument s analýzou současného stavu Portálu veřejné správy (PVS), určením

Více

Tieto Future Office. Přehled. Země: Česká republika. Odvětví: Samospráva

Tieto Future Office. Přehled. Země: Česká republika. Odvětví: Samospráva Tieto Future Office Přehled Země: Česká republika Odvětví: Samospráva Profil zákazníka: Magistrát města Plzeň je orgánem města Plzně, který plní jeho úkoly v oblasti územní samosprávy i státní správy na

Více

PŘÍLOHA Č. 4 K ZADÁVACÍ DOKUMENTACI VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU. Tvorba software pro reportování stavu projektů (dále jen IS)

PŘÍLOHA Č. 4 K ZADÁVACÍ DOKUMENTACI VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU. Tvorba software pro reportování stavu projektů (dále jen IS) PŘÍLOHA Č. 4 K ZADÁVACÍ DOKUMENTACI VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU Tvorba software pro reportování stavu projektů (dále jen IS) VERZE: finální DATUM: 6.9. 2013 1 ÚVOD Popis reportů potřebných pro sledování

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

Seznam.cz. Tomáš Pergler. najdu tam, co neznám!

Seznam.cz. Tomáš Pergler. najdu tam, co neznám! Scrum @ Seznam.cz Tomáš Pergler Obsah přednášky Jak funguje Scrum role fáze (meetingy) vstupy / artefakty Jak děláme Scrum v Seznam.cz Praha Brno na dálku Jak reportujeme dál Projekty i maintenance Co

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

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

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Návrh softwarových systém. Návrh softwarových systémů

Návrh softwarových systém. Návrh softwarových systémů Návrh softwarových systém ů - úvod, motivace Jiří Šebek Návrh softwarových systémů (B6B36NSS) Obsah Motivace Integrace s ostatními obory SI Modely, metodiky SI Verzování SW 2 Úvod Motivace SI Velké projekty

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

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů Ing. Ondřej Macek 2013/14 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Historie 2 Jak vypadal vývoj SW? - Bylo třeba specifikovat zadání, to se naprogramovalo a pak se

Více

Umí HR držet krok s byznysem (zkušenosti z agilního řízení)

Umí HR držet krok s byznysem (zkušenosti z agilního řízení) Umí HR držet krok s byznysem (zkušenosti z agilního řízení) Jana Gutierrez Chvalkovska Konference HR v pohybu 23.května 2018 Co nás čeká? Co je to agile? Jak lze využít prvky agilního řízení v HR Příklady

Více

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů Ing. Ondřej Macek 2013/14 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Historie 2 Jak vypadal vývoj SW? - Bylo třeba specifikovat zadání, to se naprogramovalo a pak se

Více

ČSOB: Upgrade systému Microsoft Dynamics CRM

ČSOB: Upgrade systému Microsoft Dynamics CRM Případová studie ČSOB: Upgrade systému Microsoft Dynamics CRM Jak jsme společnosti ČSOB zefektivnili práci s firemními klienty ČSOB: Upgrade systému Microsoft Dynamics CRM Celý projekt začal v srpnu, přičemž

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

Vzdálená správa v cloudu až pro 250 počítačů

Vzdálená správa v cloudu až pro 250 počítačů Vzdálená správa v cloudu až pro 250 počítačů S pomocí ESET Cloud Administratoru můžete řídit zabezpečení vaší podnikové sítě bez nutnosti nákupu, instalace nebo údržby dalšího hardwaru. Řešení je poskytováno

Více

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT RosaData TM DEVELOPERSKÝ PROJEKT OBSAH Úvod... 4 Developerský projekt... 5 Seznam developerských projektů... 5 Základní údaje... 6 Popis... 7 Technické detaily... 8 Reality... 11 Foto... 13 Obchodní případ...

Více

IS pro podporu BOZP na FIT ČVUT

IS pro podporu BOZP na FIT ČVUT IS pro podporu BOZP na FIT ČVUT Závěrečná zpráva pro 2. iteraci 21. dubna 2011 Zadavatel: Ing. Jiří Chludil Řešitelský tým: Jiří Kopecký Jan Kratochvíl Milan Matějček Štefan Pinďák Kristýna Streitová Úvod

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

CASE nástroje. Jaroslav Žáček

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

Více

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Strana 1 z 12 Obsah 1. Leady... 3 a. Shrnutí... 3 b. Popis modulu... 3 c. Technické podrobnosti o modulu... 5 2. MERK... 6 a. Shrnutí... 6 b.

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

Struktura Pre-auditní zprávy

Struktura Pre-auditní zprávy Příloha č. 1 k Smlouvě o Pre-auditu: Struktura Pre-auditní zprávy 1. Manažerské shrnutí Manažerské shrnutí poskytuje nejdůležitější informace vyplývající z Pre-auditní zprávy. 2. Prohlášení o účelu a cílů

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

Agilní metodiky a techniky. analýza a vývoj IS

Agilní metodiky a techniky. analýza a vývoj IS Agilní metodiky a techniky analýza a vývoj IS Využití UML UML jako náčrt systému UML jako plán vývoje UML jako programovací jazyk Příklad: Analýza - chyby v zákoně viz http://blog.geospy.org/tagged/anal%c3%bdza

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

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

egovernment ready úřad

egovernment ready úřad egovernment ready úřad Ing. Václav Koudele Strategy architect Tel.: +420 602 191 122 Vaclav.koudele@microsoft.com Ing. Zdeněk Dutý Ředitel pro egovernment Tel.: +420 910 972 131 zdenek.duty@autocont.cz

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

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Prezentace CRMplus Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Obsah prezentace Představení společnosti Technodat Develop, s.r.o. CRMplus základní charakteristika

Více

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ SPOLEČNOST DECADIC PROJEKT FRAMETRIX

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ SPOLEČNOST DECADIC PROJEKT FRAMETRIX FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ MANAGEMENT PROJEKTŮ SPOLEČNOST DECADIC PROJEKT FRAMETRIX SPECIFIKACE POŽADAVKŮ AUTOR DOKUMENTU JIŘÍ JANDA BRNO 15. března 2012 Obsah 1 Úvod........................................

Více

Specifikace softwarového projektu

Specifikace softwarového projektu Specifikace softwarového projektu Objednávkový systém pro lékařská zařízení Jméno projektu: KaNIS (Kliniky a Nemocnice Informační Systém) Předpokládaný vedoucí: RNDr. Michal Kopecký, Ph.D. Předpokládaný

Více

Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ,

Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, 2015 1 5/ Řízení rizika na úrovni projektu, podniku a v rámci corporate governance. BIVŠ, 2015 2 Definice projektu říká, že se jedná o činnost, která

Více

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy Bc. Petr Pokorný Letní semestr 2009/2010 1 Obsah 1 Úvod... 3 2 Workflow... 3 3 Workflow

Více

Allegro obchodní doklady

Allegro obchodní doklady Allegro obchodní doklady Modul obchodních dokladů nabízí vše, co je zapotřebí pro obchodování menších a středních firem. K dispozici je evidence nákupu a objednávek materiálu, systém pokrývá celý prodejní

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 : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Obsah. Poděkování... 7

Obsah. Poděkování... 7 Obsah Poděkování.............................................................................. 7 Kapitola 1 Navigace v soustavě Projektového řízení.......................... 9 Dvojí rozměr projektového

Více

1 Úvod 1.1 Vlastnosti programového vybavení (SW)

1 Úvod 1.1 Vlastnosti programového vybavení (SW) 1 Úvod 1.1 Vlastnosti programového vybavení (SW) - dávkové zpracování - omezená distribuce - zakázkový SW - distribuované systémy - vestavěná inteligence - laciný HW - vliv zákazníka 1950 1960 1970 1980

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

ČMSS: CRM systém pro efektivní práci s klienty

ČMSS: CRM systém pro efektivní práci s klienty Případová studie ČMSS: CRM systém pro efektivní práci s klienty Jak jsme společnosti ČMSS dodali moderní řešení pro řízení vztahů s klienty ČMSS: CRM systém pro efektivní práci s klienty Kvalitní poskytování

Více

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK Systém WorkWatch je určen pro malé a střední firmy, které se zabývají službami nebo zakázkovou výrobou. Zajistí dokonalý přehled o všech zakázkách a jejich rozpracovanosti.

Více

ELO Analytics Vaše obchodní metriky na jednom místě. Vaše obchodní metriky na jednom místě. Enterprise Content Management

ELO Analytics Vaše obchodní metriky na jednom místě. Vaše obchodní metriky na jednom místě. Enterprise Content Management ELO Analytics ELO Analytics Enterprise Content Management www.elo.com ELO ECM Suite 10 ELO Analytics pro správu informací ELO Analytics vám umožňují zhodnotit a pochopit veškerá data vaší společnosti na

Více

Indexace pro souborová uložiště a Vyhledávací centrum

Indexace pro souborová uložiště a Vyhledávací centrum Indexace pro souborová uložiště a Vyhledávací centrum Obsah I. Úvod... 2 II. Cíl dokumentu... 2 III. Fáze projektu... 2 IV. Popis jednotlivých fází projektu... 2 1. Fáze 1. - Analýza... 2 2. Fáze 2. -

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

AGILNÍ METODIKY, JAK DÁL?

AGILNÍ METODIKY, JAK DÁL? AGILNÍ METODIKY, JAK DÁL? Alena Buchalcevová Katedra informačních technologií VŠE Praha, buchalc@vse.cz ABSTRAKT: Agilní metodiky mají za sebou již sedm let své existence, vyzrávají a začínají být skutečně

Více

ADVANTA 2.0. www.advanta- group.cz Strana 1 ze 40. Popis řešení Řízení IT projektů. www.advanta- group.cz

ADVANTA 2.0. www.advanta- group.cz Strana 1 ze 40. Popis řešení Řízení IT projektů. www.advanta- group.cz www.advanta- group.cz ADVANTA 2.0 Popis řešení Řízení IT projektů Advanta pomáhá firmám s realizací krátkodobých i dlouhodobých projektů. Díky kombinaci tradičních metod a inovativních přístupů v projektovém

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 : 22. Otázka : Úvodní fáze rozpracování softwarového projektu. Postupy při specifikaci byznys modelů. Specifikace požadavků a jejich rozpracování pomocí

Více

PROCE55 Maintenance. Přehled

PROCE55 Maintenance. Přehled Přehled Obsah Představení PROCE55 Maintenance... 3 Přínosy řešení... 3 Integrace PROCE55... 4 PROCE55 Scheduling... 4 PROCE55 Warehouse... 4 Klíčové vlastnosti PROCE55 Maintenance... 5 Karty strojů a zařízení...

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

POČÍTAČE A PROGRAMOVÁNÍ

POČÍTAČE A PROGRAMOVÁNÍ POČÍTAČE A PROGRAMOVÁNÍ Moderní metody vývoje softwaru, Demontrační příklad piškvorky Miroslav Vavroušek PPI 09 V1.0 Opakovaní z minulé přednášky Vícerozměrná statická a dynamická pole Pole polí Datový

Více

Dynamické ověřování nákupních podmínek v systému PROe.biz

Dynamické ověřování nákupních podmínek v systému PROe.biz Dynamické ověřování nákupních podmínek v systému PROe.biz Ing. Zbyněk Dohnal DONASY s.r.o. Sídlo: 787 01 Šumperk, Nezvalova20 Poštovní adresa: 623 00 Brno, Chopinova 13 GSM: +420 602 730 976 email: dohnal@donasy.cz

Více

Jak správně psát scénáře k případům užití?

Jak správně psát scénáře k případům užití? Jak správně psát scénáře k případům užití? Autor RNDr. Ilja Kraval 2007 http://www.objects.cz K napsání tohoto článku mne inspiroval tento mail: Dobrý den pane Kravale, chci Vás poprosit o radu, která

Více

1 Popis předmětu plnění projektu implementace MIS

1 Popis předmětu plnění projektu implementace MIS 1 Popis předmětu plnění projektu implementace MIS Vytvořit Manažerský rozpočet Tzn. vytvoření metodiky pro zajištění Manažerského účetnictví, přičemž metodikou se rozumí soubor postupů a pravidel popisujících

Více

Popis modulu Základní popisy odpadu v programu SKLAD Odpadů 8

Popis modulu Základní popisy odpadu v programu SKLAD Odpadů 8 Popis modulu Základní popisy odpadu v programu SKLAD Odpadů 8 Co je to Základní popis odpadu Úvodem stručná rekapitulace, co je to Základní popis odpadu (ZPO). Je to dokument popisující vlastnosti a kvalitu

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

Softwarový proces Martin Hlavatý 4. říjen 2018

Softwarový proces Martin Hlavatý 4. říjen 2018 Softwarový proces Martin Hlavatý 4. říjen 2018 Úvod Základní pojmy Softwarový proces / Model životního cyklu vývoje software (SDLC, Software Development Lifecycle) Množina aktivit nutných k tomu, aby software

Více

Vývoj informačních systémů. Jak vyvíjet v týmu

Vývoj informačních systémů. Jak vyvíjet v týmu Vývoj informačních systémů Jak vyvíjet v týmu Co je potřeba a co je podstatné? Lidé a jejich spolupráce Plány, pravidla, procesy, řízení Dokumentace Techniky a technologie Dlouhý čas Cílem je produkt (software)

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

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

1 Úvod. 2 Registrace a přihlášení. Registrace). Zobrazí se stránka, kde budete mít na výběr ze dvou možností. Můžete vytvořit nové či.

1 Úvod. 2 Registrace a přihlášení. Registrace). Zobrazí se stránka, kde budete mít na výběr ze dvou možností. Můžete vytvořit nové či. 1 Úvod Aplikace XPERA Projects, která je určena pro sběr a řešení požadavků, přináší nový rozměr a efektivity mobilního klienta. Aplikace Xpera Projects pro ios znamená mít řešené případy stále s sebou.

Více

MST - sběr dat pomocí mobilních terminálů on-line/off-line

MST - sběr dat pomocí mobilních terminálů on-line/off-line MST - sběr dat pomocí mobilních terminálů on-line/off-line Stručný přehled název: MST, software pro sběr dat mobilními terminály ve skladu (příjem, výdej, inventura) autor aplikace: FASK, spol. s r.o.,

Více

Manuál k programu RIZIKA

Manuál k programu RIZIKA Manuál k programu RIZIKA nástroj k efektivnímu vyhledávání a řízení pracovních rizik Program RIZIKA Program RIZIKA jsou víceuživatelskou aplikací s možností nastavení uživatelských práv pro jednotlivé

Více

Řízení prací na vodovodních sítích

Řízení prací na vodovodních sítích Řízení prací na vodovodních sítích Ing. Josef Fojtů 1) Ing. Jiří Tajdus 1), Ing. Milan Koníř 2) 1) QLine a.s., 2) Severomoravské vodovody a kanalizace Ostrava a.s. Cílem příspěvku je představení základních

Více

UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0

UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0 UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0 OBSAH 1 ÚVOD... 3 1.1 HOME STRÁNKA... 3 1.2 INFORMACE O GENEROVANÉ STRÁNCE... 4 2 VYHLEDÁVÁNÍ V ÚZEMÍ...

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

Výběrové řízení. Informační systém Autoklubu ČR. Autoklub České republiky. Strana 1 z 8

Výběrové řízení. Informační systém Autoklubu ČR. Autoklub České republiky. Strana 1 z 8 Autoklub České republiky Výběrové řízení Informační systém Autoklubu ČR Strana 1 z 8 AUTOKLUB České republiky, Opletalova 29, 110 00, Praha 1 // www. Autoklub.cz Obsah Identifikační údaje zadavatele...

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

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

Nemocnice. Prvotní analýza a plán projektu

Nemocnice. Prvotní analýza a plán projektu Nemocnice Projekt do předmětu AIS Prvotní analýza a plán projektu Lukáš Pohl, xpohll00, xkosti03 Jan Novák, xnovak79 2009/2010 1 Neformální specifikace FN potřebuje informační systém, který bude obsahovat

Více

SW podpora projektového řízení

SW podpora projektového řízení Browser MS-Project SW podpora projektového řízení Společnost appcore s.r.o. nabízí služby v oblastech systémové integrace, softwarové integrace a řízení organizace. Veškeré služby naší společnosti jsou

Více

E-ŘEŠENÍ INTERNETOVÉ APLIKACE NAD SOFT-4-SALE

E-ŘEŠENÍ INTERNETOVÉ APLIKACE NAD SOFT-4-SALE E-ŘEŠENÍ E-řešení je společným názvem pro skupinu internetových nadstaveb. V systému Soft-4-Sale poskytují podporu e-řešením, která Vám pomohou s prodejem a propagací zboží a služeb na internetu. Systém

Více

Aplikace Elektronická podání Transakční část portálu veřejné správy

Aplikace Elektronická podání Transakční část portálu veřejné správy Aplikace Elektronická podání Transakční část portálu veřejné správy Vysvětlení pojmů Obsah Občan 3 Organizace 3 Zástupce 3 Uživatel 3 4 Zastupování 5 Služba 6 Transakce 6 Vlastník služby 6 Registrace 6

Více

Při prvním přihlášení Vás program vyzve ke změně úvodního hesla.

Při prvním přihlášení Vás program vyzve ke změně úvodního hesla. Návod na používání helpdeskového systému HELP.i. Požadavky směrované na podporu produktů firmy DATACENTRUM systems & consulting, a.s., jsou evidovány v aplikaci HELP.i. V systému jsou evidovány požadavky,

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

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

45 Plánovací kalendář

45 Plánovací kalendář 45 Plánovací kalendář Modul Správa majetku slouží ke tvorbě obecných ročních plánů činností organizace. V rámci plánu je třeba definovat oblasti činností, tj. oblasti, ve kterých je možné plánovat. Každá

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

QAD CRM. Vladimír Bartoš. konzultant

QAD CRM. Vladimír Bartoš. konzultant QAD CRM Vladimír Bartoš konzultant Integrace QAD CRM QAD EA Artikly Adresy Nabídky Prodejní objednávky Instalovaná báze Servisní volání Servisní kontrakty Servisní nabídky Nabídky volání Měny Uživatelé

Více

2. Začlenění HCI do životního cyklu software

2. Začlenění HCI do životního cyklu software Jan Schmidt 2011 Katedra číslicového návrhu Fakulta informačních technologií České vysoké učení technické v Praze Zimní semestr 2011/12 EVROPSKÝ SOCIÁLNÍ FOND PRAHA & EU: INVESTUJENE DO VAŠÍ BUDOUCNOSTI

Více

Modul Zakázky MANUÁL

Modul Zakázky MANUÁL MANUÁL www.aktion.cz POPIS Modul Aktion Zakázky zajišťuje evidenci času, který zaměstnanci, externisté či brigádníci stráví na jednotlivých zakázkách/projektech a jejich částech. Projekty lze naplánovat

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

Průvodce aplikací FS Karta

Průvodce aplikací FS Karta Průvodce aplikací FS Karta Základní informace k Aplikaci Online aplikace FS Karta slouží k bezpečnému ukládání osobních údajů fyzických osob a k jejich zpracování. Osobní údaje jsou uloženy ve formě karty.

Více

Telelogic Focal Point využití pro řízení a optimalizaci projektového portfolia Verze 1.0

Telelogic Focal Point využití pro řízení a optimalizaci projektového portfolia Verze 1.0 DISTRIBUTOR White Paper Verze 1.0 Ing. Jiří Gryc 26.4.2007 Tento dokument ve stručnosti představuje možnost využití špičkového Telelogic Focal Point pro řízení a optimalizaci projektového portfolia. Další

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

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

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

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