Modernı metody pro vy voj webovy ch aplikacı

Michael Žabka – Moderní metody pro vývoj webových aplikací

Úkol Předkladatel xname Cvičení

SP-K2 Michael Žabka xzabm00 Pá 9:15

Modernı́ metody pro vý voj webový ch aplikacı́ Semestrální práce pro předmět Podnikové informační systém y - 4IT314

1


1 Obsah 1

Obsah ...............................................................................................................................................2

2

Úvod.................................................................................................................................................3

3

2.1

Význam.....................................................................................................................................3

2.2

Cíl .............................................................................................................................................3

2.3

Postup zpracování práce..........................................................................................................3

2.4

Charakter projektu...................................................................................................................3

2.5

Metody zpracování ..................................................................................................................3

Popis metodik ..................................................................................................................................5 3.1

Extrémní programování ...........................................................................................................6

3.2

Vývoj řízený vlastnostmi ..........................................................................................................6

3.3

Metodika Rational Unified Process..........................................................................................8

3.4

Metoda SCRUM........................................................................................................................8

3.5

Metodika OpenUP....................................................................................................................9

4

Zhodnocení metodik ......................................................................................................................10

5

Závěr ..............................................................................................................................................11 5.1

Dosažené cíle a výsledky........................................................................................................11

5.2

Budoucí zpracování................................................................................................................11

6

Bibliografie .....................................................................................................................................12

7

Seznam obrázků .............................................................................................................................13

2


2 Úvod Moje práce se zabývá moderními metodami a modely životního cyklu vývoje projektu, jejichž využití se za posledních několik let vyskytuje ve firmách, zabývajících se vývojem webových aplikací. Označení metody uvádím z toho důvodu, že ne všechny metody, které v této práci popisuji, mají dostatečnou strukturu a náležitosti, aby se daly označovat jako metodiky1. Tyto metodiky jsou v nynější době brány jako velice důležité pro konkurenceschopný chod firmy. V oblasti tvorby webových stránek se tyto metodiky ovšem stále používají velice málo, přitom dokáží značně zefektivnit práci a vývoj projektů.

2.1 Význam Význam této práce spočívá ve zlepšení komunikace, řízení, správy, dokumentace aj. při vývoji webových aplikací. V současné době se spousty firem uchyluje k postupu, který je z hlediska teorie neefektivní nebo dokonce „nesmyslný“. Některé teorie ovšem nedokážou postihnout všechny reálné podmínky a omezení, které nám měnící se trh uděluje. Tato práce se pokusí sumarizovat metody a postupy firem, které se s tímto trhem nejlépe vypořádávají.

2.2 Cíl Cílem práce je analyzovat metody při vývoji webových aplikací, které s trendem agilních metodik, metod a postupů přicházejí do České republiky. Účelem práce by pro některé společnosti mohlo být zefektivnění jejich dosavadních přístupů k vývoji. Obsah práce bude věnovaný především firmám, které se zabývají tvorbou webových aplikací a informačních systémů.

2.3 Postup zpracování práce Abych dosáhl stanoveného cíle, budu se zaměřovat jen na některé metodiky. Budou to ty, které se v současném světě využívají, a to především v zahraničí nebo v revolučních českých firmách. Jelikož cíl neobsahuje starší resp. již nepoužívané metody, nebudu se jimi zabývat a pokud ano, tak pouze okrajově. Tyto metodiky, které spadají do cíle práce, jsou v zásadě agilní (tedy alespoň co se fakt a mého názoru týká). Proto se budu zabývat převážně jimi. Popíši principy metodik, některé přednosti a zápory. Dále pak zhodnotím ty nejsilnější z nich. Součástí analýzy bude zjištění a popsání problémů v konkrétním aplikování metodik pro jejich použití při vývoji webových aplikací a informačních systémů pro web. Závěrem pak podotknu některá vlastní doporučení a zmíním možné problémy aplikování metodik v měnícím se prostředí světa.

2.4 Charakter projektu Moje práce se zabývá analýzou, tedy shrnutím informací a vytknutím těch nejdůležitějších částí. Bohužel je rozsah práce limitován počtem slov, proto se hlouběji nedostanu k dílčím problémům, které bych rád popsal. Pro prostudování detailů problematiky doporučuji pročíst zdroje uvedené v bibliografii.

2.5 Metody zpracování Informace jsem získal především z internetových zdrojů, přednášek, diplomových prací, bakalářských prací a osobních zkušeností s problematikou. Osobní zkušenosti jsou ty, které jsem získal studiem na VŠE a praxí ze zaměstnání. V průběhu jsem se potýkal s problémy získávání některých informací. 1

Metodika představuje souhrn doporučených praktik a postupů, pokrývajících celý životní cyklus vytvářené aplikace. (Wikipedia, 2011)

3

Michael Žabka – Moderní metody pro vývoj webových aplikací Například pro získání firemních způsobů, metod, postupů a know-how je velmi obtížné najít vyčerpávající a věrohodný zdroj. Důvodem je odpor firem prozradit svá „esa v rukávu“.

4


3 Popis metodik Při vývoji aplikací a softwaru se můžeme setkat se spousty metodik. Jejich vývoj procházel postupným vývojem s ohledem na aktuální požadavky trhu. Ještě před tím, než vstoupily metodiky do světa software, vyvíjelo se tzv. metodou „pokus, omyl“. Tato metoda byla dříve účinná z hlediska požadavků na tehdejší aplikace. Jakmile už tato metoda přestávala stačit požadavkům, vstoupilo na scénu softwarové inženýrství. To se snažilo připodobňovat projekty vývoje softwaru k projektu stavebního průmyslu. Vše bylo třeba předem naplánovat do posledního detailu a poté teprve začít se samotným vývojem a implementací. Vznikaly tak metodiky typu „waterflow“ neboli vodopád2. Tento typ vývoje se zdál být skvělý, ovšem nepočítal s tím, že požadavky na softwarové aplikace se mění razantně rychleji, než požadavky na stavební projekt. O odstranění nevýhod se pokoušely metodiky spirálovitého typu či metodika RUP. Ta je sice stále a funkčně využívaná, ovšem pro vývoj standardních webových aplikací je takřka nepoužitelná z důvodu její robustnosti. Po tomto prozření se začal hledat způsob, který by mohl lépe reagovat na tyto turbulentní požadavky. Na konci tohoto hledání stál tzv. agilní přístup. Tento přístup se snaží být co nejblíže zákazníkovi a reagovat na změny v jeho požadavcích. Oproti vodopádovému přístupu jsou také chyby odhaleny mnohem dříve a to se pozitivně odráží v nákladech na tyto změny. V následujících subkapitolách si popíšeme některé z těchto metodik agilního přístupu. Předtím si ještě ukážeme, jakým způsobem k vývoji agilní metodiky přistupují. Proměnné, ovlivňující vývoj si můžeme představit na trojúhelníku, viz Obrázek 1 - Proměnné agilních metodik převzatý a upravený z (HAJDIN, 2005).

Obrázek 1 - Proměnné agilních metodik

Jak je vidět proměnné, zakreslené do trojúhelníku, jsou čas, zdroje a funkcionalita. Dle standardního popisu agilních metodik se za fixní považují čas a zdroje a funkcionalita je ta, co se může v případě potřeby měnit. Zákazník se ovšem většinou snaží zafixovat všechny 3 proměnné. Takový případ v běžné praxi (především u webových aplikací) často nastává, jenže aby tu platil nějaký zákon, jedna veličina musí být volná, která se pohybuje. Můžete si všimnout třetí veličiny uprostřed trojúhelníku a to je kvalita. Pokud zafixuji tři proměnné, může se mi to podepsat právě na této kvalitě. Tomu je ovšem se třeba vyvarovat. Kvalita by vždy měla být konstanta rovna 100%. Pokud by tak nebylo, mohly by z toho plynout jiné důsledky, například bezpečnostní. Pro podrobnější pochopení metodik doporučuji přečíst zdroj (ŘEPA, 2001), či agilních metodik zdroj (HAJDIN, 2005). Nyní ovšem přejdeme k popisu konkrétních agilních metodik.

2

Vodopád je typ metodiky, která se zaměřuje především na analýzu a plánování projektu.

5


3.1 Extrémní programování Extrémní programování vystupující pod zkratkou XP je metodika využívající zajímavé metody přístupu k vývoji aplikace. Hlavní a dominantní metody jsou tzv. párové programování a jednotkové testování. Slovo extrémní se zde docela hodí. Jedná se totiž o metodiku, kde se klade důraz na programový kód a jeho revizi. Programový kód je hlavním zdrojem informací pro další postup v životním cyklu projektu. Párové programování dokáže efektivně rozložit práci dvou programátorů do dvou vrstev. Jeden programátor sedí u klávesnice a píše kód. Jeho mysl se zaměřuje na konkrétní algoritmy a problémy, které má vyřešit část kódu, např. jedna metoda. Druhý programátor stojí a přemýšlí nad obecnějším problémem v aplikaci a je tak blíž business logice. Nezatěžuje se řešením toho, co řeší první programátor. Dalším velice zajímavým řešením párového programování je, že každý programátor píše vlastní část kódu pro různé dílčí funkcionality. Např. po jednom dni si vymění pozice a píší každý program toho druhého. Na první pohled se může zdát, že je to pro oba programátory zdržením, protože se musí vyznat v kódu jiného a opravovat jeho chyby, ovšem to je právě záměr. Tato metoda se využívá v případě, že chceme maximálně zamezit bezpečnostním chybám. Zároveň se tak každý programátor učí od toho druhého novým zkušenostem a znalostem. XP se, jak už bylo řečeno, zaměřuje na testování, a to nejen zmíněné jednotkové testování, ale i testování funkcionalit a akceptační testy. Tyto testy nám odstraňují problémy při častém refaktorování3 kódu, které je typické při měnících se požadavcích zákazníka. Metodika XP vytváří zajisté přehledný kód a s minimálními chybami. Pro vývoj webových aplikací má tato metodika také nevýhody. Dle analýzy metodik pomocí systému METES (BUCHALCEVOVÁ, 2009) z diplomové práce (MITTNER, 2011) je vyvozen závěr, že pro využití XP by bylo nutné získat vyšší zapojení od uživatelů (zákazníků). To je ovšem v praxi často velice omezené. Jinak spoustu metod je pro webový vývoj vhodných a stojí za to je využít. Pro podrobnější popis metodiky extrémního programování nahlédněte do zdroje (BUCHALCEVOVÁ, 2009).

3.2 Vývoj řízený vlastnostmi Tato metodika známá také pod anglickým názvem Feature-Driven Development či FDD je jedna z nejpopulárnějších agilních metodik. Tato metodika se zaměřuje na fázi návrhu a implementace. Pokrývá tedy pouze některé části životního cyklu projektu. FDD je jednoduchý, čitelný a efektivní pro spoustu typů projektů. Jednou z hlavních předností FDD je neustálé monitorování stavu projektu. Projekt je tak pod kontrolou a může se tak např. odhadovat, kdy bude projekt hotový nebo kde nastávají potíže. Postup jde tzv. po kouskách (features). To jsou části funkcionality, které mají nějaký užitek pro zákazníka. Každou z těchto funkcionalit je třeba dokončit ve stanoveném termínu (např. 2 týdny). Funkcionalita musí být dobře od zákazníka popsaná a my musíme správně odhadnout její výsledek. Pro FDD je typické, že se stále modeluje. Na začátku vzniká model celkového projektu, ale pouze obecný a u každé dílčí části se tvoří podrobnější model. Tomuto přístupu se také říká iterativní přístup a jeho podstata je vyobrazena na Obrázek 2 - Iterativní přístup životního cyklu projektu.

3

Refactoring je činnost, při které měníme kód bez změny funkčnosti za cílem zpřehlednění kódu.

6


Obrázek 2 - Iterativní přístup životního cyklu projektu (Wiki, 2010)

Ve FDD je jako vedoucí projektový manažer, a ten se stará o časové rozplánování projektu a obsazení týmu. Hlavní architekt tvoří celkový návrh systému. Dále je zde vývojový manažer, který se stará o každodenní chod vývoje. Pod vývojovým manažerem je hlavní programátor, který pomáhá při analýze, a zároveň vede a napomáhá programátorským pracím. Jednotlivým programátorům se říká vlastníci třídy. Ty mají na starost jednu danou vlastnost či funkcionalitu a starají se o její tvorbu a následné testy. Poslední z hlavních rolí je doménový expert, který ověřuje celkovou business logiku a správnost projektu. V této metodice existují ještě podpůrné role, ve kterých bych vytknul alespoň návrháře a testera, kteří bývají pro tvorbu webových aplikací velice důležití. FDD postupuje v pěti následujících procesech. Jsou to popis procesu, vstupní kritéria, úkoly, verifikace a výstupní kritéria. Ačkoli je tato metodika velice rozšířená, popisy těchto procesů nejsou striktně dané. Na rozdíl od jiných metodik, jako je např. RUP, se FDD snaží pouze nastínit, čeho by se měl vývojář držet, ale detailní definice si tvoří vývojář sám. Velice pěkný a podrobný popis této metodiky můžete najít ve zdroji (HAJDIN, 2005). Pokud bych chtěl tuto metodiku aplikovat na webový vývoj, jistě bych dospěl lepšího výsledku než při nepoužití žádné metodiky, jak se bohužel často stává. Co by bylo určitě ve webovém vývoji prospěšné, je vyvíjení po částech. Každou část si totiž můžeme od zákazníka nechat schválit nebo lépe zeptat se na požadované změny. Tento feedback nám může ušetřit spousty práce a nákladů. Rozvržení rolí v týmu je také zajímavě zpracováno, ovšem pro webový vývoj by chtělo některé role 7

Michael Žabka – Moderní metody pro vývoj webových aplikací přidat a některé jsou zase spíše zbytečné. Jedná se např. o přidání role, která vytváří tzv. wareframe4, o kterých půjde řeč ještě později. Co bych chtěl FDD vytknout pro využití při webovém vývoji je neustálé modelování. To, jak sám vím z praxe, je pro toto odvětví velice zdržující činnost a je třeba se jí vyvarovat.

3.3 Metodika Rational Unified Process Již v úvodu byla zmíněna tato metodika. Ačkoli jsem její využití pro webový vývoj prakticky zavrhl, má tato metodika spousty prvků, podložených „best practices“. RUP je opravdu robustní metodika, popsaná obrovskou dokumentací. Tato metodika nyní spadá pod firmu IBM, což taky napovídá, pro koho je určena. Jedná se spíše o větší podniky s většími zdroji a rozsáhlou organizační strukturou. Stejně jako FDD využívá iterativního vývoje, dále pak aktivní správu požadavků, komponentovou architekturu, ověřování kvality a řízení změn viz zdroj (IBM, 2010). Tato metodika bývá často označována jako tzv. „agilní těžká“ metodika. Postupem času ovšem tato metodika zavedla některá rozšíření, díky kterým se dá RUP využít i ve středních a menších podnicích a na menších projektech. Hlavní charakteristikou RUP je rozdělení životního cyklu do čtyř částí, mezi kterými se přechází iterativně. Jako první je zahájení (inception), ve kterém se připravuje dokumentace, tvoří use-case diagramy nebo například časově plánuje projekt. Následuje příprava (elaboration), která je nejzásadnější. V této fázi se dokončují use-case diagramy a dělá se kompletní engeineering. Po přípravě je konstrukce, kde se vytváří, jak už název napovídá, samotný software na danou platformu. A na závěr je tzv. předávání, při kterém se zaměřuje na požadavky zákazníka a dosahuje se jeho přání. Po každé fázi je dokončen milník ve vývoji. Podrobný přehled o metodice (v angličtině) najdete v následujícím zdroji (IBM, 2011). Metodika RUP těží na své přesně definované podobě a zkušenostech velké firmy IBM, která se vývojem software zabývá již řadu let. Velkým problémem této metodiky, a to ne jen pro webový vývoj, je její robustnost a sáhodlouhá dokumentace. Díky tomu ji řada vývojářů a programátorů nezná a nejsou většinou ani ochotni se ji učit. Musíme hledět na to, že programátoři webových stránek, hlavně PHP5, mají často velice slabou praxi a nedostatečné znalosti. Proto bych tuto metodiku spíše nedoporučoval pro vývoj webových aplikací, nicméně pro vývoj software obecně má silné uplatnění.

3.4 Metoda SCRUM Metodika SCRUM je velice inovativním způsobem řízení projektu. Značná změna oproti ostatním metodikám zde spočívá v aktivnějším zapojení zákazníka do projektu. Vůbec role zde hrají velkou roli. Zákazník vystupuje jako Product Owner, dále je pak Scrum Master, který se stará o správné fungování Teamu, který je zároveň třetí rolí. Ačkoli by se zdál být Scrum Master vedoucí rolí, tak tomu tak není. SCRUM nemá vlastní vedení, čili jsou všichni na stejné úrovni. Zde se musí předpokládat s důvěrou mezi členy teamu a dobrou pracovní morálkou. SCRUM je oproti RUP velice málo dokumentovaná a dává vývojářům velkou volnost. Resp. SCRUM není metodikou, ale pouze sadou doporučení, jak by se k vývoji mělo přistupovat. Při využívání ve 4

Wareframe je grafický návrh rozložení funkcionalit v aplikaci. Slouží jako podklad pro grafika, který by se jeho struktury měl držet. 5 PHP – Je skriptovací programovací jazyk pro vývoj webových stránek. V nynější době je nejrozšířenějším jazykem využívaným na WEBu.

8

Michael Žabka – Moderní metody pro vývoj webových aplikací firmě je třeba spoustu dalších náležitostí doplnit a vytvořit tak vlastní metodiku, která je postavena na základu SCRUM. Metodika se pyšní třemi pilíři, a to jsou průhlednost, revize a adaptace. Tyto pilíře přibližují zákazníka k vývoji a tak se očekávají přívětivější výsledky. Zákazník tyto dílčí výsledky vývoje kontroluje v pravidelných intervalech, tzv. sprintech. Za dobu tohoto sprintu, nastaveného např. na jeden týden, se vyvine malá část programu. Je zde hodně kladen důraz na porady. Nejen po každém sprintu, ale dokonce po každém dni se team schází a řeší průběh sprintu a pokouší se odstraňovat problémy při vývoji. Na těchto denních meetinzích by měl být přítomen i zákazník, ovšem neměl by do vývoje zasahovat, pouze sledovat a připravovat se na meeting po sprintu, kde má hlavní slovo. Podle jeho připomínek se může poupravit přístup v dalším sprintu. Detailní popis této metodiky můžete nalézt v tomto zdroji (KOŠATA, 2010). Tato metodika má dle mého názoru veliký potenciál a slibnou budoucnost. Pro webový vývoj má pár much. Jednou z nich je nutnost zapojení zákazníka do vývoje. Na tomto způsobu je tato metodika postavená a právě při vývoji webových aplikací je tento požadavek často těžko realizovatelný. Pokud by ovšem byl zákazník přesvědčen a ochoten se zapojit, bude vidět jistě kvalitní výsledek. Tuto metodiku bych tedy doporučil pro některé projekty, ale pro jiné, především menší projekty, bych ji nedoporučoval využívat.

3.5 Metodika OpenUP Tato metodika má v názvu stejná slova jako RUP tedy Unified Process. To není náhoda. OpenUP je totiž zredukovaná a volně šiřitelná verze metodiky RUP. Nebudu je tedy detailně popisovat, pouze vytknu nejdůležitější části této metodiky. Stejně jako RUP se k vývoji přistupuje iterativně a má inkrementální model životního cyklu. Veliký důraz je kladen na řízení rizik a architekturu. OpenUP se zaměřuje na 4 základní hodnoty agilních principů (BUCHALCEVOVÁ, 2009) (MITTNER, 2011).    

spolupráce pro sladění zájmů a porozumění cílům projektu, hodnocení priorit s cílem maximalizace hodnoty pro zákazníka, včasné zaměření na architekturu s cílem minimalizace rizik, kontinuální zpětná vazba a zlepšování.

Při vývoji se využívá kontinuální integrace6 a vývoje řízeného testy a případy užití. Metodika definuje tyto role: Analytik, Architekt, Vývojář, Projektový manažer, Tester, Zainteresované osoby. Životní cyklus aplikace je pokryt 19 činnostmi a 17 produkty. Tato metodika odfiltrovala hlavní nevýhodu RUP, a to je složitost celé metodiky. Další výhodou oproti RUP jsou lépe zpracované produkty a činnosti resp. jsou takto blíž webovému vývoji. Na základě těchto výhod bych tuto metodiku řadil mezi nejefektivnější při vývoji webových stránek a aplikací.

6

Kontinuální integrace je průběžné kontrolování funkčnosti, např. testy apod. (Wikipedia, 2011)

9


4 Zhodnocení metodik Představené metodiky obsahují řadu výhod a řadu nevýhod. Ať už se jedná o výhody a nevýhody celkově nebo konkrétně pro webový vývoj, je vidět, že nelze využít ideálně některou z těchto metodik. Metodika Extrémní programování je velice prospěšná pro kód, ale vyžaduje častou interakci se zákazníkem. Komunikaci se zákazníkem vyžaduje i metodika SCRUM, která se v současné době začíná razantně využívat při vývojích software i webových aplikací. Vývoj řízený vlastnostmi je také velice účinný a využívaný, ovšem opomíná na některá důležitá odvětví webového vývoje. RUP je velice precizně zpracovaná metodika a obsahuje spousty zkušeností, ale její robustnost jí především ve webovém vývoji dostává spíše do pozadí. V OpenUP se sice tyto nevýhody řeší, ovšem ještě nám něco k dokonalosti vývoje chybí. Naštěstí vývin samotných metodik neustává. Ing. Jan Mittner se ve své diplomové práci snaží najít metodiku právě pro webový vývoj. Na základě jeho teoretických znalostí a několikaleté praxe se pokusil takovou konkrétní metodiku vytvořit a také s úspěchem vytvořil. Tato metodika je postavena se základem v OpenUP. Dále na ní jsou aplikovány některé užitečné praktiky např. z XP či FDD. Výrazný přínos má přidání rolí a konkretizování jejich povinností a činností. Dále jsou zde zmíněny i technologické postupy a zásady, které byste v abstraktních metodikách jen těžko hledali. Mezi tyto zásady patří například výroba wareframe, které částečně nahrazují zadavatelskou dokumentaci a rychle reagují na zpětnou vazbu od zákazníka. Přesný popis této metodiky můžete nalézt ve zdroji (MITTNER, 2011). Osobně bych chtěl podotknout, že ať se rozhodnete využívat jakoukoli metodiku, není v zájmu si jí nechat svázat ruce. Naopak je třeba si metodiku upravovat podle vaší potřeby a tu vámi stvořenou metodiku teprve striktně dodržovat v prostředí fungování firmy.

10


5 Závěr 5.1 Dosažené cíle a výsledky Tato práce analyzuje některé agilní metodiky a pokouší se je spojit s webovým vývojem. V závěru každé metodiky je popsána praktická možnost využití při webovém vývoji. Cíl pomoci firmám se lépe zorientovat v metodikách a třeba i některou z metodik aplikovat myslím byl dosáhnut. Jelikož je rozsah práce limitován, bylo těžké postihnout všechny myšlenky. Tato práce spíše ukazuje možnosti a dále jakým směrem se zaobírat. Manažera či vedení vývoje by tato práce měla podnítit k tomu, aby se problematikou metodik více zabývali.

5.2 Budoucí zpracování V poslední kapitole byla zmíněna metodika, vytvořená přímo pro vývoj webových aplikací. Tato metodika ovšem není řádně odzkoušená. Proto by její analýza a test mohly být velice prospěšné. Následně by bylo možné tuto metodiku doladit a lépe zformalizovat.

11


6 Bibliografie BUCHALCEVOVÁ, Alena. 2009. Metodiky budování informačních systémů. Praha : Oeconomia, 2009. ISBN 978-80-245-1540-3. HAJDIN, Tomáš, Bc. 2005. Agilní metodiky vývoje software. Brno : Masarykova Univerzita v Brně, Fakulta Informatiky, 2005. IBM. 2011. Best Practices for Software Development Teams. Rational Unified Process. [Online] 2011. [Cited: 12 16, 2011.] http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractic es_TP026B.pdf. —. 2010. IBM software. Rational Team Concert. [Online] 2010. [Cited: 12 11, 2011.] http://www01.ibm.com/software/awdtools/rtc/. KOŠATA, Václav. 2010. Metodika SCRUM, Bakalářská práce. Praha : VŠE, 2010. MITTNER, Jan. 2011. Metodika pro vývoj webových aplikací. Praha : VŠE FIS, 2011. ŘEPA, Václav. 2001. Vývojové trendy metodyk - Výzva BPR. Praha : VŠE, 2001. Wiki, Eclipse Process Framework. 2010. Open Unified Process. [Online] 2010. [Cited: 12 11, 2011.] http://epf.eclipse.org/wikis/openup/. Wikipedia. 2011. Continuous intergration. Wikipedia. [Online] 2011. [Cited: 12 17, 2011.] http://en.wikipedia.org/wiki/Continuous_integration. —. 2011. Metodika. Wikipedia. [Online] 2011. [Citace: 10. 12 2011.] http://cs.wikipedia.org/wiki/Metodika.

12


7 Seznam obrázků Obrázek 1 - Proměnné agilních metodik..................................................................................................5 Obrázek 3 - Iterativní přístup životního cyklu projektu (Wiki, 2010).......................................................7

13

Modernı metody pro vy voj webovy ch aplikacı

Recommend Documents