Bc. Václav Chalupní ek

Transkript

1 Zadání Metodika vývoje internetových aplikací Navrhn te vhodnou metodiku pro vývoj b ºných internetových aplikací, která se pouºije p i komunikaci se zákazníkem. Metodiku podpo te vhodným nástrojem, pop ípad takový nástroj navrhn te. Vyuºijte standard WebML a vývojové prost edí Django jazyka Python. Prove te demonstrativní ukázku pouºití nástroje p i realizaci webového projektu.

2 ii

3 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Diplomová práce Metodika vývoje internetových aplikací Bc. Václav Chalupní ek Vedoucí práce: Ing. Juraj Kubelka Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpo etní technika leden 2009

4 iv

5 Pod kování Ing. V rce turmové a Mgr. Janu turmovi, LL.M. d kuji za korekturu stylistiky a pravopisu. Firm COEX CZ, s.r.o. d kuji za vynikající prost edí, které dalo vzniknout této práci. Ze v²ech zam stnanc bych rád jmenovit uvedl Radka Pilmaiera, Ivo²e Gajdoruse a Nikolu Schmidta, kte í svými p ísp vky do diskuzí významn p isp li k výsledku této práce. Pod kování pat í i mé rodin, která m za v²ech okolností podporovala. Nakonec bych cht l pod kovat tv rc m následujícího softwaru za vynikající práci. L A TEX, Django, Gentoo, KDE, OpenOce.org v

6 vi

7 Prohlá²ení Prohla²uji, ºe jsem svou diplomovou práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). Názvy produkt a rem mohou být ochrannými známkami nebo zapsanými ochrannými známkami p íslu²ných vlastník. V Praze dne vii

8 viii

9 Abstract The thesis creates a comprehensive methodology for the development of internet applications pursuant to XHTML 1.0 standard with the open source framework Django. The paper follows principles of agility and reects author's practical experience. The main topic discussed is eective communication between a software development team and a client during a project when the client is unable to provide xed specications for the project. Environment of a software company, leadership and management are discussed as well. The author's work is established on respected methodologies and denes procedures applicable in a practice of a functioning company. The result is primarily a Project Manual with guidelines for software developers. Abstrakt Tato práce formuluje ucelenou metodiku vytvá ení internetových aplikací dle standardu XHTML 1.0 za pomoci open source frameworku Django. Práce dodrºuje agilní principy a reektuje autorovy poznatky z praxe. St ºejním tématem je efektivní komunikace mezi vývojovým týmem a zákazníkem p i práci na projektu s nestabilním zadáním. Zabýváme se také prost edím softwarové spole nosti, ízením a managementem. Autorova práce vychází ze známých metodik a formuluje postupy uplatnitelné v praxi fungující spole nosti. Výsledkem je p edev²ím projektová p íru ka (manuál) s metodickými pokyny pro vývojá e. ix

10 x

11 Obsah Seznam obrázk xiii 1 Úvod charakterizující kontext zadání Strategický rámec Management softwarové spole nosti P edávání informací Agilní vývoj P ípadová studie Lingvistická poznámka Metoda, metodika, metodologie Vymezení e²eného problému a cíl práce Metodika B ºná internetová aplikace Zákazník Komunikace se zákazníkem WebML Django Python Struktura práce ve vztahu k vyty eným cíl m 13 4 P ehled známých metodik Agilní metodiky Adaptive Software Development Dynamic Systems Development Method Extrémní programování Feature Driven Development Scrum Agilní modelování Webové metodiky Jennifer Fleming Popis navrhnutého e²ení Zavedení manuál Obecný manuál Bezpe nost Obchodní a marketingový manuál Provozní manuál ICT manuál Projektový manuál Role a kompeten ní model Metodika Komunikace Prost edí webu Analytická dokumentace Specikace projektu Sdílení informací xi

12 5.6 Vhodný nástroj Návrh nástroje Formulá e a checklisty Udrºitelnost metodiky Zhodnocení spln ní cíl práce Záv re né shrnutí Literatura 45 A Projektový manuál 47 A.1 Popis rolí A.1.1 Production coordinator (PC) A.1.2 Project manager A.1.3 Head programmer A.1.4 Analyst A.1.5 Database specialist A.1.6 Application designer A.1.7 Programmer A.1.8 SEO, SEM specialist A.1.9 Graphic designer A.1.10 Copywriter A.1.11 Template coder A.1.12 Tester A.2 Fáze ºivotního cyklu vývoje A.2.1 Zahájení (inception) A.2.2 Rozpracování (elaboration) A.2.3 Konstrukce (construction) A.2.4 Nasazení (transition) B Vision document formulá 65 C Change request / Bug report formulá 69 D Protokol o testování formulá 71 E Ukázka pouºití metodiky 73 xii

13 Seznam obrázk 2.1 Dimenze zlep²ování spole nosti [23] P t úrovní zralosti SE-CMM [18] Struktura 80% dodávaných webových prezentací Vývojový cyklus denovaný ASD vrstvá struktura rmy kompeten ní model Formy komunikace; zdroj [3], [5] Úvodní obrazovka s p ehledem projekt Úvodní obrazovka vybraného projektu Prototyp textová forma Prototyp ukázka gracké reprezentace bloku menu Detailní zobrazení navrºeného bloku aktuality na homepage Detailní zobrazení navrºeného bloku archiv aktualit Detailní zobrazení navrºeného bloku menu Zadávání specikace funkcí a komentá návrhu Strom URL projektu Editace struktury projektu A.1 projektové role A.2 Levely skill jednotlivých worker A.3 Obsah fází ºivotního cyklu vývoje A.4 WebML unity E.1 Vypln ný dotazník vision document strana E.2 Vypln ný dotazník vision document strana E.3 Vypln ný dotazník vision document strana E.4 Vypln ný dotazník vision document strana E.5 Vypln ný dotazník vision document strana E.6 Vypln ný dotazník vision document strana E.7 Gracký návrh stránky O NÁS E.8 Gracký návrh stránky INTERPRETI E.9 Gracký návrh stránky PROJEKTY E.10 Gracký návrh stránky MP3/VIDEO E.11 Model komponent UML balí ky E.12 Datový model UML diagram t íd xiii

14 xiv

15 KAPITOLA 1. ÚVOD CHARAKTERIZUJÍCÍ KONTEXT ZADÁNÍ 1 1 Úvod charakterizující kontext zadání 1.1 Strategický rámec Inºenýrství se uplat uje tam, kde je t eba zavád t formalizmy a pravidla. Tato práce popisuje úlohu softwarového inºenýrství v komer ní sfé e, která navíc podléhá mnoºství neformálních princip, a navrhuje e²ení pro konkrétní prost edí. Jedná se tedy o p ípadovou studii implementace metodiky vývoje softwaru do konkrétního podniku (viz. kapitola 1.2). Komer ní sférou máme na mysli p edev²ím spolupráci objednatel zhotovitel Management softwarové spole nosti Poloºme si otázku: Jak ídit softwarovou rmu? Základní odpov, platná nap í podnikatelským spektrem, je nutnost rozd lení zam stnanc spole nosti na manaºery a nemanaºery ( adové zam stnance), viz. literatura [21]. Stejná literatura paradoxn tvrdí, ºe hranice mezi manaºerem a nemanaºerem není ostrá práce malých tým má charakter managementu (rozhodování, plánování), naopak manaºer m ºe provád t rutinní operace (smlouvy, ú etnictví,...). Pro identikaci jednotlivc v podniku zavádíme role, viz. kapitola 5.2. Manaºerem je dle [21] osoba zodpov dná za proces koordinace pracovních aktivit lidí tak, aby byly provedeny ú inn a efektivn. Proces reprezentují funkce: plánování, organizování, vedení a kontrolování. Máme tedy osobu ídící (globáln zodpov dnou) a osobu ízenou (lokáln zodpov dnou). Prost edí spole nosti je komplikovan j²í. Dle [7] vysv tluje management chyby v ízení, psychologie slabý výkon lov ka a sociologie negativní postoje jednotlivce. V²echny tyto sloºky tvo í prost edí spole nosti, proto kniha zavádí pojem organiza ní chování, které má být syntézou v²ech t í sloºek. Chceme-li pozitivn p sobit na organiza ní chování, musíme zavést formalizmy, které zaru í, ºe budou zú asn ní v d t, co práv d lají a pro. To se týká jak manaºer, tak nemanaºer. V této souvislosti pouºíváme pojem metodika, která je v softwarovém inºenýrství denována jako souhrn doporu ených praktik a postup pokrývajících celý ºivotní cyklus vytvá ené aplikace (viz. kapitola 2.1) P edávání informací V softwarové rm nalezneme n kolik druh informací: projektové poºadavky zákazníka, výsledky vývoje organiza ní kdo strávil kterou inností kolik asu metodické jaké metody a technologie se mají pouºívat p i e²ení problém (kdo a kdy) technické jak správn uºívat statky a prost edky rmy Projektové informace jsou prost edkem pro zji²t ní stavu v cí (projekt ). Vyplývá z nich náro nost realizace odhad budoucí zát ºe. 1 Objednatel a zhotovitel jsou právnické termíny, viz. lingvistická poznámka na konci této kapitoly (1.3)

16 2 KAPITOLA 1. ÚVOD CHARAKTERIZUJÍCÍ KONTEXT ZADÁNÍ Organiza ní informace jsou klí ové pro sledování a m ení výkonnosti organizace ([21]). Spole n s odhadem náro nosti jsou základním podkladem pro alokování zdroj (sestavování rozpo tu a tvorbu harmonogramu). Pozitivní vlastností tohoto druhu informací je, ºe jsou dob e kvantikovatelné. Metodické pokyny slouºí ke sjednocení zp sobu, jakým zam stnanci pracují. Bez této sloºky se nedá mluvit o organizaci. Informace technického rázu slouºí k efektivnímu vyuºívání prost edk, které jsou ve vlastnictví spole nosti (nap. sdílené tiskárny, vzdálený p ístup k síti pomocí VPN atd.). Pro správné fungování spole nosti jsou d leºité v²echny ty i druhy informací. Pro kaºdý typ informací musíme ur it p esnou formu a principy jejich p edávání. V textu se dále zam íme na informace projektové a metodické. S pojmem informace se váºe pojem znalost. Ta se d lí do t í skupin [13]: Tacitní (nevyslovené) znalosti jsou v hlavách lidí, jsou subjektivní, velmi t ºko formalizovatelné. Získávají se zku²eností, asem jsou povaºovány za samoz ejmost. Jedná se o sloºitý komplex dovedností, zku²enosti, intuice, pravidel, princip, mentálních model a osobních p edstav konkrétního lov ka nebo skupiny lidí. Tacitní znalost bývá n kdy nesprávn nazývána zku²enost i intuice. Zku²enost a intuice jsou v²ak pouze jednou z jejích sloºek. Vzhledem k tomu, ºe jsou mnohdy vyuºívány podv dom a neuv dom le, p edstavují také nejv t²í potenciál. P edstavují totiº rozhodující prvek mezi úsp chem a neúsp chem. Sd lování a p ená²ení t chto zku²eností vyºaduje nástroje a podmínky vyuºívané p edev²ím obory humanitního a personalistického charakteru, podporující rozvoj osobních dovedností, souhrnn management lidských zdroj a management znalostí. Implicitní znalosti p echodová skupina znalostí, které jsou vyjád itelné a popsatelné, nicmén nev dom získané, nau ené jako sou ást jiných inností a uloºené v hlavách pracovník. Explicitní znalosti výslovné znalosti, které je moºné formalizovat a které jsou systematické, p enosné a komunikovatelné. Explicitní znalost lze p evést do formy dat a skladovat ji v informa ním systému. Explicitní znalosti spolu m ºeme kombinovat a vytvá et tak na jejich základ explicitní znalost novou. Metody a nástroje pro práci a uchovávání t chto znalostí jsou p edev²ím technicko-dokumenta ního charakteru. Jedná se nap íklad o r zné záznamy, technickou dokumentaci, data v informa ních systémech atd. Práv formalizace 3. skupiny znalostí je p edm tem této práce Agilní vývoj Jednozna n nejv t²í vliv na tuto práci mají agilní metodiky (p ehled v eské literatu e nalezneme nap íklad v [3] i [12], více v kapitole 4). Nejvýrazn j²í charakteristikou agilního p ístupu jsou krátké iterace, kdy zákazník vidí vznikající produkt pr b ºn a je schopen reagovat novými podn ty. Manifest agilního vývoje softwaru [14] deklaruje ty i hodnoty, které up ednost uje p ed tradi ními p ístupy rigorózních metodik: individuality a komunikaci p ed procesy a nástroji provozuschopný software p ed obsaºnou dokumentací spolupráci se zákazníkem p ed sjednáváním kontraktu

17 KAPITOLA 1. ÚVOD CHARAKTERIZUJÍCÍ KONTEXT ZADÁNÍ 3 reakci na zm nu p ed pln ním plánu V praxi pozorujeme, ºe se programáto i necht jí o e²ení dohadovat se zákazníkem, nejrad ji dostávají p esné zadání. Je úkolem analytika, aby zajistil stabilitu zadání a rychle zpracovával zm ny (popis rolí je v kapitole A.1). Analytik se stává nárazníkem, který stojí ve st edu agilní metodiky, první bod manifestu se týká výlu n analytika (viz. role v kapitole A). 1.2 P ípadová studie Tato práce je úzce vázána na spole nost COEX CZ, s.r.o. 2, se kterou autor intenzivn spolupracuje jiº více neº 4 roky. Jedná se o malou softwarovou spole nost s p ibliºn 25 spolupracovníky (zam stnanci, studenti a externisté) s netradi ním, neformálním p ístupem. Spole nost má t i divize: webovou, desktopovou a PDA, které jsou personáln nezávislé (vyjma managementu). M eno ekonomickými ukazateli je webová divize nejd leºit j²í. Za 5 let p sobení rmy na trhu do²lo k postupnému zdokonalování pouºívaných technologií. V sou asnosti se pro tvorbu web pouºívá ve více neº 3/4 p ípad framework Django (viz. 2.5), ke kterému je zde formulovaná metodika ²itá na míru. Spole nost poskytuje komplexní sluºby v oblasti webových technologií: konzultace, tvorba, provoz (hosting), údrºba (SEO). Pro správné fungování bylo t eba vytvo it serverové zázemí (vývoj, produkce) a nasadit pat i né IS (opensource, komer ní i vlastní). Autor byl sou ástí e²itelského týmu. Zmín ná problematika v²ak není p edm tem této práce. Více detailních informací o subjektu lze nalézt na webové stránce spole nosti cz. Postupy pouºívané p ed uplatn ním princip této práce nebyly zdokumentované. Byly ustavovány konsenzem n kolika jedinc, kte í jsou velmi individuáln zdatní a sehraní (tacitní znalosti). Krom rizika, ºe tito jedinci p estanou pro rmu pracovat, je tu také r st rmy, který vyºaduje zavedení systematického p ístupu. Zejména z d vodu ²kálovatelnosti (nábor nových zam stnanc ), opakovatelnosti (²kolení zam stnanc ), trvalé urdºitelnosti (zdokonalování postup ) a kontrolovatelnosti. Metodika, kterou zde formulujeme vychází z best practices a teoretických poznatk softwarového inºenýrství. 1.3 Lingvistická poznámka V této práci budeme hojn pouºívat sociolektické prost edky (profesní mluva, slang). Nap íklad n které anglické výrazy s eskou morfologií (nap. hostingy, mock-upy atd.). Je to b ºná praxe v oboru a eské ekvivalenty neexistují nebo k porozumitelnosti nep ispívají, jejich konotace bývá nejednozna ná. Autor tento p ístup povaºuje za správný, protoºe je nejp irozen j²í. Právní termíny zhotovitel a objednatel, které se vyskytují p edev²ím ve smlouv, mají n kolik ekvivalent, které budeme pouºívat podle pot eby. Následuje seznam n kterých pouºívaných ekvivalent : web webová prezentace website webové stránky stránky internetová aplikace 2 V textu pouºíváme ozna ení podnik, spole nost, organizace i rma. Slovo rma znamená správn pouze obchodní název spole nosti, pod kterým vystupuje na trhu. My ho v²ak budeme pouºívat jako ekvivalent ostatních uvedených pojm.

18 4 KAPITOLA 1. ÚVOD CHARAKTERIZUJÍCÍ KONTEXT ZADÁNÍ templatista ten kdo sestavuje HTML a CSS ²ablony pro jednotlivé ásti webu manuál p íru ka worker pracovník, adový zam stnanec pracující na projektu zhotovitel vývojá i rma spole nost podnik objednatel zákazník zákazník zastoupený doménovým expertem V textu také pouºíváme zkratky, a to b ºné IS (informa ní systém), SW (software) atd. i námi denované TST (tester), COPY (copywriter), TPL (templatista) atd Metoda, metodika, metodologie Zvlá²t bychom se m li zmínit o rozdílu mezi metodou, metodikou a metodologií, protoºe se i v odborné literatu e setkáme se ²patným pouºíváním t chto pojm. Metodologie (anglicky methodologies) je nejobecn j²í pojem, znamená nauku o metodikách. Jedná se o v dní disciplínu. Metodika (anglicky methodology) ozna uje popis ºivotního cyklu softwarového díla, komplexní postupy a návody pro vývoj. Metoda (anglicky method) ozna uje konkrétní postup pro e²ení díl ího problému.

19 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE 5 2 Vymezení e²eného problému a cíl práce Cílem práce je zefektivnit a strukturalizovat pracovní aktivity spole nosti. V této kapitole provedeme rozbor zadání práce po jednotlivých klí ových formulacích tak, abychom sledovali její cíl. 2.1 Metodika Metodika je abstraktní pojem, který bývá konkrétn realizován ve form p íru ek, p edpis a návod. Ty popisují kdo, co, kdy, kde a pro d lá. P íru ky je nutné vytvo it, pouºívat a udrºovat. CMMI [23] denuje 3 dimenze, ve kterých se mohou spole nosti zlep²ovat. My se budeme zabývat práv oblastí procedur a metod. CMMI je sou ástí normy ISO Situaci ilustruje obrázek 2.1. Obrázek 2.1: Dimenze zlep²ování spole nosti [23] Krom vlastního metodického p ístupu je také nutné denovat zp sob, jakým se p íru ky tou, jak se ²kolí zam stnanci a jak se kontroluje, ºe je ²kolení ú inné. Jedin pak m ºeme na základ výsledk uvaºovat o zm n v metodice. SE-CMM (Software Engineering Capability Maturity Model, esky v [3]) zavádí 5 úrovní zralosti softwarových proces organizace (viz. obrázek 2.2). Nezralé procesy jsou výsledkem improvizace, nelze je opakovat a p edvídat. Organizace reaguje na vzniklé problémy a napravuje chyby. Plány a rozpo ty jsou p ekra ovány, p i snaze dodrºet as dochází ke sniºování kvality. Na druhé stran zralá organizace je dle autor CMM schopna ídit procesy p i vývoji softwaru, a to v rámci celé organizace. Jednotlivé úrovn s oblastmi klí ových proces jsou: 1. initial po áte ní úrove 2. repeatable opakovatelná úrove ízení poºadavk plánování softwarových projekt sledování softwarových projekt

20 6 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE Obrázek 2.2: P t úrovní zralosti SE-CMM [18] ízení subdodávek zaji²t ní kvality softwaru ízení kongurací 3. dened denovaná úrove zam ení na procesy na úrovni organizace denice proces na úrovni organizace progam ²kolení integrace softwaru softwarové inºenýrství koordinace mezi skupinami kontroly 4. managed ízená úrove kvantitativní ízení ízení kvality metriky 5. optimizing optimalizovaná úrove prevence defekt ízení technologických zm n ízení zm n proces Spole nost, pro kterou metodiku formulujeme tém zavr²ila 2. úrove vysp losti. Pouºívá interní systém pro plánování a sledování projekt dotproject (

21 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE 7 ostatní klí ové procesy jsou zaji² ovány individuálními zodpov dnostmi jednotlivc dle dohodnutého (nikoliv v²ak ádn dokumentovaného) zp sobu. Na²ím cílem bude zdokumentovat zp sob, jakým se má k projekt m p istupovat a tím upevnit pozici na 2. úrovni a také denovat standardní softwarový proces organizace a zp sob, jakým se p izp sobí podmínkám projektu, coº je sou ástí 3. úrovn vysp losti. Ve spole nosti je zavedeno pouºívání dokumentu specikace poºadavk (dále DSP), ten ale v t²inou vývoji nepomáhá, je pouze nutnou sou ástí smlouvy. V moment, kdy je smlouva podepsána, je DSP asto odloºeno, nejsou do n j reektovány zm ny v projektu a tudíº není pouºitelný ani pro vývojá e, ani pro zákazníka. Tuto situaci se pokusíme zm nit formulováním takové dokumentace, která bude reagovat na nové poºadavky. M lo by se zárove jednat o zp sob ízení poºadavk. K podpo e softwarového inºenýrství doporu íme metody a konkrétní nástroje (aplikace), které mají být v jednotlivých fázích projektu pouºity. S vývojem se váºe mnoho pojm, mezi kterými nejsou explicitn denovány vztahy a vývojá i si je vykládají po svém. Pro posun organizace dál je nutné tyto vztahy denovat (nap íklad vztah konceptuálního, logického a fyzického modelu, design UI, funk ní specikace, prototyp, aktuální TODO, testování, nasazení, testovací data, ostrá data, a mnoho dal²ích). Doporu íme také pouºití návrhových vzor [8], ov²em bez bliº²ího up esn ní. V duchu agilních metodik vydenujeme velké (obchodní) a malé (realiza ní) iterace vývojového procesu. Pokusíme se popsat zp sob, jakým se má zákazník zapojit do vývoje a jak ho motivaovat (p ístup k prototypu on-line, moºnost komentovat jednotlivé vznikající ásti atd.). 2.2 B ºná internetová aplikace B ºnou internetovou aplikaci budeme v této práci chápat jako vizuální hypertextový dokument, jehoº obsah je uloºen v S BD a je administrovatelný zákazníkem. WebML [26] takové aplikace nazývá data intensive. Dle interního pr zkumu, který byl proveden nad p ibliºn 50 dodanými internetovými prezentacemi, odpovídá 80% projekt modelu, který je znázorn n na obrázku 2.3. Toto pro nás bude ur ující vzhledem k formulaci p íkad pouºití metodiky. 2.3 Zákazník Zákazník bývá reprezentován zástupcem, který je kompetentní rozhodnout o vý²i rozpo tu projektu. Dále také doménovým expertem, tedy n kým, kdo má dokonalý p ehled o vnit ních procesech v zákaznickém prost edí a dokáºe vývojovému týmu zodpov d t kaºdou otázku. ƒasto se setkáme s tím, ºe tyto dv role zastává jedna pov ená osoba. Zákazníci jsou dvojího typu. Jedni, kte í v dí, co cht jí a pevn trvají na svých poºadavcích. Druzí, kte í nev dí nic a rádi by pouze vy e²ili sv j problém. Druhý typ zákazník je obecn hor²í (pouºívají nap. v tu Jenom takové jednoduché...), protoºe kdyº jim p edloºíme e²ení, asto naleznou n co, co by rádi vylep²ili a povaºují projekt za nedod laný. Je velmi t ºké p esv d it je, aby p inancovali nové dod lávky, protoºe dle jejich mín ní je chyba na stran vývojového týmu, který to m l p eci v d t. Takový typ zákazník je t eba v as identikovat a bu je p esv d it o nedokonalosti jejich my²lenky a nechat projekt nancovat podle reáln odpracovaných hodin (outsourcingová forma spolupráce, zodpov dnost za výsledek projektu pak z stává na zákazníkovi) nebo s nimi v bec nespolupracovat. Jak se íká v pokeru: Zku²ený

22 8 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE Obrázek 2.3: Struktura 80% dodávaných webových prezentací hrá sloºí i dobré karty. Tomuto fenoménu se budeme bránit p edev²ím d razem na metody ohodnocování projekt. N kdy se také setkáváme se s doménovými experty, kte í dostali úkol vy e²it problém remního webu (intranetu) tém za trest. Sami nev dí, co p esn pot ebují, jaké mají moºnosti. Takové zákazníky musíme postupn a srozumiteln provést v²emi moºnými variantami e²ení a nechat je se rozhodnout. Zákazník asto p ichází s problémem velké administrativní zát ºe ve svém businessu a chce sv j problém vy e²it pomocí IS. Zde je d leºité shromáºdit p edem p íklady v²ech variant dat, se kterými se pracuje. St ºejní ástí p i napl ování zákazníkových p edstav je porozum ní si analytika a doménového experta. Správa poºadavk musí být pr hledná, aby nem l zákazník pocit, ºe ho vývojá i tahají za nos, a naopak, aby vývojá i nepracovali bez právoplatného nároku na odm nu Komunikace se zákazníkem Za komunikaci se zákazníkem je zodpov dný analytik. Analytik v²ak nekomunikuje pouze se zákazníkem, se kterým by vyjednává podobu systému, sepsal ji a odevzal na dal²í zpracování, ale komunikuje s celým týmem ve v²ech fázích vývoje. M l by tvo it výpl mezi jednotlivými leny týmu. Pokud máme analytika, který dokáºe vyvolat uvnit týmu ºivou diskuzi a vnést do ní my²lenky tak, jak je p ed ním formuloval zákazník, je pravd podobnost úsp ²ného ukon ení projektu tak, aby odpovídal p edstav zákazníka, vy²²í. Dle metodiky Jennifer Fleming [12] platí pro zákazníka akronym IKIWISI, tedy I'll know it when I'll see it. Pokud nechceme, aby se vývoj jednoduchého webového systému zbyte n protahoval, musíme si rychle ujasnit, co vytvá íme, nejlépe rychlým prototypem, na kterém m ºe zákazník lépe denovat svoje poºadavky. Tvrdíme, ºe jedin zákazník ví, co pot ebuje, ale z ídkakdy je schopný to ucelen a srozumiteln p edat. Je vhodné mít vizualizovaný model, který je pln pochopitelný pro ob strany. N kdy se setkáváme s papírovými modely, tzv. mock-upy, které nemají funk nost, pouze vypadají

23 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE 9 jako skute né. Naproti tomu prototypy nevypadají jako skute né, ale mají funkce budoucího sytému. Pokusíme se formulovat p ístup, který sjednotí oba p ístupy pro lep²í porozum ní mezi zákazníkem a vývojá i. Problematika mezilidské komunikace je ²iroké téma. Základním d lením bývá verbální a neverbální komunikace, na detailn j²í rozbor v²ak není v této práci prostor. M ºeme v²ak konstatovat, ºe analytik, který má zákazníka správn pochopit, by m l být e nicky zdatný, empatický a m l by mít psychologické a sociologické vlohy. N kdy se v této souvislosti setkáváme s pojmem mentální model, který pochází z kognitivní psychologie a je reakcí na my²lení související s poznáváním softwarových systém [22] a [24]. V ideálním p ípad je mentální model iniciátora (zákazníka) shodný s mentálním modelem budoucího uºivatele. Problémem v²ak je, ºe tato p edstava o systému je vnit n uloºená v jedinci a komunikací ven se zkresluje. Dal²í zkreslení p iná²í p enos p es vývojový tým. Snahou vývojového týmu musí být co nejlépe pochopit tento mentální model a dát mu fyzickou podobu ve form aplikace, která v uºivatelích vyvolá stejný mentální model, jaký m l iniciátor. 2.4 WebML Web Modeling Language [26] je vizuální notace pro návrh komplexních, datov orientovaných webových aplikací. Byla vytvo ena na italské univerzit Politecnico di Milano. Formalizuje gra- cké specikace a zahrnuje ucelený proces návrhu, který m ºe být podpo en CASE nástroji. V sou asnosti je jediným komer n dostupným WebRatio [27]. K WebML je p idruºena metodika, která je zaloºena na principu transformace model a vyuºívá technologie XSLT. Tento p ístup bohuºel není dob e slu itelný s námi vybraným frameworkem. Metoda rozeznává p t model : structure a derivation slouºí pro návrh datové struktury. Je velice podobný klasickému entitn rela nímu modelování. Jedná se o konceptuální model, který se jednodu²e p evádí do logického modelu (rela ní databáze). composition a navigation kompozi ní model denuje sloºení prezentace z jednotlivých stránek a sloºení stránek z jednotlivých p eddenovaných atomických element (units). Units jsou vázány na entity datového modelu, ze kterých erpají sv j obsah nebo chování. Navigace zobrazuje, jak jsou mezi sebou jednotlivé stránky respektive jejich elementy provázány. presentation je chápán jako transformace p edchozích model do konkrétní podoby webové prezentace pomocí XSLT. Celý model WebML je totiº moºné prezentovat jako XML dokument. Hlavní cíl návrhu WebML p edstavuje moºnost odd lit p i modelování informa ní obsah stránek (datový model) od jejich struktury a navigace (hypertextový model) nezávisle na konkrétním designu uºivatelského rozhraní (prezenta ní model). WebML umoº uje specikovat i dynamickou stránku webové prezentace (nejr zn j²í operace a manipulace s daty), které jsou vyvolávány jako vedlej²í efekt navigace ([28]). Tato práce kopíruje strukturu WebML a p izp sobuje jí podmínkám, kdy jsou vytvá eny aplikace za pouºití frameworku Django.

24 10 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE 2.5 Django Django ( teno ['à A go:]) je open source webový aplika ní framework napsaný v Pythonu, který se voln drºí Model-view-controller architektury. P vodn byl navrºen jako systém pro ºurnalisty spole nosti Lawrence Journal-World. Pozd ji v ervnu 2005 byl vydán ve ejn pod licencí BSD. Framework byl pojmenován po jazzovém kytaristovi Django Reinhadtovi. Auto i ozna ují Django jako vysokoúrov ový webový framework, které podporuje rapidní vývoj a istý, pragmatický design. Nabízí moºnost automatické tvorby administrace projektu, která je generována dynamicky podle datového modelu. Hlavní úkol Djanga je snadné vytvo ení komplexních, databázemi ízených, webových aplikací. Zam uje se na znovupouºitelnosti a p ipojitelnosti v²ech komponent, rychlý vývoj a p edev²ím na koncept DRY (Don't Repeat Yourself) neopakovat se. Hlavním zdrojem informací je web projektu [6], kde je dokumentován jak poslední release, tak trunk Subversion repozitá e. Dokumentace je na velmi vysoké úrovni a k dispozici je i mnoho názorných návod. Komunita dala vziknout také knize The Denitive Guide to Django [10], která vývoj v Djangu detailn popisuje. Django se t ²í velké popularit a sám tv rce Pythonu Guido van Rossum se nechal sly²et, ºe co se tý e webových framework, je Django jeho volbou (viz. [9]). Pokud jde o eskou komunitu, ta se soust edí na Jan Král tam pí²e, ºe 20. srpna 2007 spustil pro spole nost Netcentrum, s.r.o. nový server který b ºí na CMS vystaveném práv na Djangu. Django se tedy dá povaºovat za stabilní vývojovou platformu. Prezentace projekt, které jsou psané v Djangu lze nalézt na Jádro Django frameworku obsahuje objektov -rela ní mapper, který je zprost edkovatelem mezi datovým modelem (denovaným jako t ídy Pythonu) a rela ní databází. MVC je napl eno p idáním systému pro zpracování poºadavk (Controller) a ²ablonovacím systémem (View). Framework navíc nabízí: Odleh ený, samostatný web server pro vývoj a testování spustitelný z p íkazové ádky OS. Serializa ní a valida ní systém pro formulá e, který automaticky p ekládá data mezi HTML formulá em a hodnotami vyhovujícími databázovým polím. Cachovací framework, který nabízí n kolik r zných metod cachování. Podporu t íd, které mohou zasáhnout v r zných stádiích vy izování poºadavku a provést vlastní funkce. Vnit ní komunika ní systém pro komunikaci mezi komponentami pomocí p edem dohodnutých signál. Moºnost p ekladu v²ech komponent do libovolného jazyka (i18n = internacionalization). Serializa ní systém, který m ºe produkovat nebo íst XML a/nebo JSON reprezentaci instancí Django modelu. Systém roz²i ujících schopností ²ablonovacího enginu. Django zárove zahrnuje mnoºství vestav ných funkcí v balíku contrib: roz²i itelný autentiza ní system (uºivatelé a práva)

25 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE 11 Dynamicky tvo ené administra ní rozhraní Nástroje pro generování RSS a Atom syndikované exporty. Flexibilní systém komentá. Nástroje pro generování Google Sitemaps. Nástroje zabra ující pad lání dotaz nap í internetovými stránkami. Template knihovny, které umoº ují pouºití odleh ených zvýraz ovacích jazyk, jako Textile a Markdown. Projekt psaný v Djangu se skládá z takzvaných aplikací, které mají denovány vlastní URL, na které reagují (formou regulárních výraz v souboru urls.py), modely (t ídy v souboru models.py), controllery (funkce v souboru view.py) a templaty (soubory.html v podadresá i templates). Sjednocujícím prvkem aplikací je soubor setting.py, který denuje nastavení projektu. Výb r frameworku Django zaru uje ist objektový p ístup k vývoji za dodrºení princip high cohesion a low coupling. 2.6 Python Python ( je dynamicky interpretovaný, objektov orientovaný programovací jazyk, který v roce 1990 navrhl Guido van Rossum. Python je vyvíjen jako open source projekt, který je dostupný pro v²echny b ºné platformy (Unix, Windows, Mac OS). Mezi nejv t²í p ednosti pat í reexivita známá nap íklad z jazyka Smalltalk. Python má vynikající vyjad ovací schopnosti. Kód programu je ve srovnání s jinými jazyky krátký a dob e itelný. Python je pouºívaný ve velkých spole nostech jako NASA i Honeywell.

26 12 KAPITOLA 2. VYMEZENÍ E ENÉHO PROBLÉMU A CÍL PRÁCE

27 KAPITOLA 3. STRUKTURA PRÁCE VE VZTAHU K VYTYƒENÝM CÍL M 13 3 Struktura práce ve vztahu k vyty eným cíl m V práci denujeme, jak má být dokumentace proces rmy len na a co se v ní má nacházet. P esn ji denujeme proces popisující realizaci webových zakázek. Po vzoru velkých spole ností budeme denovat p íru ky (manuály), které popisují jednotlivé dimenze spole nosti dle obr V první kapitole prvního manuálu bude návod, jak se mají p íru ky íst a jakou mají strukturu. První ást práce je re²er²í pouºívaných metodik, druhá popisuje prost edí spole nosti a od - vod uje záv ry (kapitola 5). T etí, hlavní ást práce je projektový manuál, který je pouºit a vyvíjen ve rm, proto je samostatn zpracován do p ílohy A. Nakonec je pouºití metodiky ilustrováno na konkrétním projektu. Ve rm budou metodické p íru ky uchovány v rámci media wiki systému ( cz), aby byla zjednodu²ena jejich aktualizace, údrºba a dostupnost. V následující kapitole jsou popsány metodiky, ze kterých vycházíme. Pouºití jedné, konkrétní, není vhodné, protoºe ºádná z metodik neposkytuje dostatek konkrétních informací, které by upevnily vývojá e p i jejich práci. Stanovení cíl a metod je p kné, ale pokud chceme vývoj zefektivnit, pot ebujeme denovat konkrétní body, po kterých se má p i realizaci postupovat. Autor se také domnívá, ºe nejefektivn j²í metodika je ta, která je maximáln p izp sobena prost edí, ve kterém se pouºívá.

28 14 KAPITOLA 3. STRUKTURA PRÁCE VE VZTAHU K VYTYƒENÝM CÍL M

29 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK 15 4 P ehled známých metodik Metodiky, ze kterých vycházíme, jsou agilního charakteru. Rigorózní metodiky nejsou vhodné, protoºe prosazují administrativn náro ný p ístup, který se u webových projekt nem ºe vyplatit. Nemáme k dispozici desítky vývojá ani m síce asu. Na²e týmy jsou sloºené z mén neº deseti vývojá a na realizaci bývá p ibliºn jeden m síc asu. Tomu odpovídá i rozpo et projektu. Existující zkoumané metodiky jsou p íli² obecné a to brání jejich efektivnímu vyuºití. V následující kapitole proto navrhneme e²ení, které bude na zde zmín ných metodikách stav t a dopl í je o d leºité (p edev²ím obchodní) reálie prost edí, ve kterém má být pouºito. Následující re²er²e erpá p edev²ím z knih Metodiky vývoje a údrºby informa ních systém [3] a Agilní programování [12] a navazující literatury. 4.1 Agilní metodiky Deset princip agilních metodik 1. Nejvy²²í prioritou je v as a kontinuáln dodávat software, který zákazík m p iná²í hodnotu Zákazníka nezajímají dokumenty, diagramy nebo integrace stávajících systém, ale zajímá jej, zda dostane fungující software v kaºdé iteraci a zda poskytovaná funkcionalita uspokojí jeho pot eby. 2. Zm nu poºadavk je moºné provést i v pozd j²ích fázích vývoje, protoºe tím m ºe zákazník získat konkuren ní výhodu Agilní p ístup se snaºí realizovat zm ny efektivn a ídit rizika negativních dopad. Je t eba realizovat krátké iterace (od dvou týdn ) a na konci dodávat fungující software. 3. Uºivatelé a vývojá i spolupracují denn na projektu Agilní p ístup radikáln m ní koncept specikace poºadavk. Východiskem je p esv d- ení, ºe není moºné dohodnout a podepsat poºadavky na za átku projektu. Proto denují na za átku jen hrubé poºadavky, které se potom na základ kaºdodenních jednání se zákazníky up es ují, a dokonce i m ní. To zd raz uje spoluú ast zákazník (uºivatel ) na denování poºadavk a p enesení odpov dnosti za projekt na n. 4. Motivovaní jedinci, kte í mají vytvo ené podmínky pro práci a mají podporu vedení, jsou klí ovým faktorem úsp chu I kdyº nasadíme v²echny moºné prost edky a nástroje, jsou to nakonec lidé, kte í rozhodují o úsp chu, i neúsp chu projektu. Lidé musí být vhodn motivováni a projekt musí být podporován v²emi zainteresovanými. 5. Nejefektivn ²ím zp sobem p enosu informací v rámci vývojového týmu je osobní komunikace Agilním metodikám bývá vytýkána nedostate ná dokumentace. Dokumentace ale není cílem projektu. Smyslem dokumentace je pochopení problému, kterého se mnohem lépe, rychleji a s men²ími náklady dosáhne pouºíváním p ímých technik komunikace. 6. Primární mírou úsp chu je fungující software

30 16 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK Ani pln ní plánu, ani existující dokumentace návrhu, nezajistí úsp ch projektu. Je t eba mít fungující systém. 7. Agilní procesy p edpokládají zdravý vývoj Vývojá i b ºn pracují p es as a o víkendech, coº zákonit sniºuje jejich produktivitu. Je t eba vymezit pracovní prostor (cca 40 hodin týdn ), v jehoº rámci z stane tým v dobré kondici, a který se za ºádných okolností nesmí p ekra ovat. 8. Perfektní technické e²ení i návrh Agilní p ístupy zd raz ují kvalitu návrhu, která je nezbytná pro realizaci zm n. Návrh není samostatnou etapou, která je pln dokon ena p ed zahájením implementace, ale je to iterativní innost provád ná v pr b hu projektu. 9. Zásadním poºadavkem je jednoduchost e²ení Existuje mnoºství cest vedoucí k e²ení, vývojá i by m li volit ty nejjednodu²²í, které vyhoví aktuálním poºadavk m. 10. Nejlep²í architektury, poºadavky a návrhy vznikají ze samoorganizujících se tým Tento princip zd raz uje kreativitu lidí, astou komunikaci a p izp sobování metodiky Adaptive Software Development Jim Highsmith, Sam Bayer ASD je projektovou metodikou zam enou na objektov orientovaný, komponentový vývoj nového e²ení. Je to lehká metodika, která se zabývá nejen oblastí softwarov inºenýrskou, ale i oblastí ízení. Zavádí tzv. Leadership Collaboration Management. Základním principem ASD je, ºe se zm nám, které nastávají, nesmíme bránit, ale musíme se na n adaptovat. Nikdo ze zú astn ných neodchází netknut, v²ichni se p i vývojovém procesu sami n co nau í a sami jsou n jakým zp sobem ovlivn ni. Klí ové je smí it se s existencí zm ny. V klasickém ºivotním cyklu je problematická fáze plánování. Plán totiº brání inovacím a produkuje výsledky, které nemusí být pot ebné. Proto ASD zavádí dynamický ºivotní cyklus Speculate-Collaborate-Learn, viz. obr Odklon od p vodního plánu je moºný v kterékoliv fázi vývoje Dynamic Systems Development Method DSDM konsorcium Tato metodika p edstavuje roz²í ení praktik rychlého vývoje aplikací (RAD). Je postavena na 9 principech aktivní zapojení uºivatele tým s rozhodovací pravomocí asté dodávky produkt klí ovým kritériem pro p ijetí dodávky je podpora business cíl

31 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK 17 Obrázek 4.1: Vývojový cyklus denovaný ASD iterativní a inkrementální vývoj, p ibliºování se k ºádoucímu e²ení zm ny v pr b hu vývoje denice poºadavk na hrubé úrovni testování v pr b hu celého ºivotního cyklu spolupráce mezi leny týmu DSDM rozd luje proces vývoje na t i ásti: Funk ní model, Návrh a Implementace. V t²ina funkcí je denována pomocí prototyp. Fáze implementace zahrnuje i ²kolení uºivatel. Metodika rozeznává dv základní projektové techniky: Timeboxing a MoSCoW. Timeboxing je zp sob rozd lení prací od zahájení projektu do jeho odevzdání do asových úsek (timebox ). Kaºdý z nich prochází t emi fázemi: zkoumání, zdokonalení, konsolidace. MoSCoW je technika se azení poºadavk podle priority, jednotlivá písmena ozna ují statusy: M (Must musí být), S (Should m lo by být), C (Could mohlo by být) a W (Won't nebude). Písmena o byla p idána pouze pro lep²í zapamatelnost názvu Extrémní programování Kent Beck, Ward Cunningham, Ron Jeries Extrémní programování (XP) vychází z princip b ºných p i vývoji softwaru, které v²ak dovádí do extrém : osv d í-li se revize zdrojového kódu, budeme kód neustále revidovat (párové programování) osv d í-li se testování, budou v²ichni vývojá i a zákazníci neustále testovat (testování white-box, black-box) osv d í-li se návrh, za adíme jej jako kaºdodenní innost osv d í-li se jednoduchost, volíme vºdy co nejjednodu²²í e²ení

32 18 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK jsme-li p esv d eni o d leºitosti architektury, budou v²ichni neustále denovat a rozpracovávat jsme-li p esv d eni o d leºitosti testování integrace, budeme integrovat a testovat n kolikrát denn osv d í-li se krátké iterace, ud láme je opravdu krátké (vte iny, minuty, hodiny) XP zd raz uje hodnotu spole ného, jednoduchost, odezvu a odvahu. D leºitými aspekty jsou nový pohled na náklady zm ny, d raz na kvalitu technického e²ení jako výsledku refaktorizace a vytvá ení test p ed kódováním. XP je lehká, ale p esto disciplinovaná metodika. Proces vývoje není podrobn popisován, ale je realizován velmi kvalikovanými a disciplinovanými vývojá i za podpory vývojových nástroj pro refaktorizaci a testování Feature Driven Development Je de Luca, Peter Coad Metodika je zaloºena na iterativním vývoji, který je ízen uºitnými vlastnostmi produktu (feature-driven). Uºitá vlastnost feature je malý výsledek uºite ný z pohledu zákazníka. Vývoj za íná vytvo ením celkového modelu a pokra uje posloupností dvoutýdenních iterací, ve kterých se provádí návrh i realizace pro jednotlivé features. FDD se skládá z p ti proces. vytvo ení celkového objektového modelu sestavení seznamu uºitných vlastností plánování pro uºitnou vlastnost návrh pro uºitnou vlastnost realizace pro uºitnou vlastnost Na rozdíl od ostatních metodik podporuje FDD procesy modelování a pouºívání CASE nástroj Scrum Ken Schwaber, Je Sutherland, Mike Beedle Tato metodika je zaloºena na p edstav, ºe vývoj softwaru je empirický proces, který vyºaduje specický zp sob ízení. Vývoj software probíhá ve 30-ti denních iteracích nazývaných Sprint, na jejichº konci je dodána mnoºina uºitných vlastností. Klí ovou praktikou metodiky Scrum je pouºívání kaºdodenních 15-ti minutových porad (Scrum meetings), které slouºí pro koordinaci a integraci prací. Scrum denuje 4 fáze ºivotního cyklu: plánovací fáze specikace funk ních poºadavk, plán dodávek, architektonická a business vize vyná²ecí fáze do souboru poºadavk (backlog) jsou p ipojeny nefunk ní poºadavky fáze vývoje dodávání funkcionality podle priority fáze dodávky p edání zákazníkovi

33 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK 19 Scrum denuje vstupy, výstupy a transforma ní procesy pro první a poslední fázi. Manipuluje se zde s explicitními znalostmi a jejich provád ní je lineární. Naproti tomu fáze vývoje je empirický proces, jehoº innosti nelze zpravidla identikovat a ídit. Scrum meetings mají informa ní charakter a konají se kaºdý den ve stejný as na stejném míst. Porady ídí tzv. Scrum Master a kaºdý ú astník musí odpov d t na t i otázky: Které poloºky dokon il od minulé porady? Které nové úkoly má e²it? Jaká vidí omezení a p ekáºky pro e²ení úkol? Agilní modelování Scott Ambler Agilní modelování (d íve nazývané Extrémní modelování, XM) aplikuje principy XP na oblast modelování. Není ucelenou metodikou, ale sadou princip a praktik v novaných modelování. Modelování je nedílnou sou ástí v²ech p ístup k vývoji software a je prosazováno na v²ech liniích softwarového inºenýrství (standardiza ní organizace OMG, IEEE atd.). Tento p ístup hlásá, ºe jakékoliv ná rtky na papí e, obrázky na tabuli i nákresy uºivatelského rozhraní p edstavují hodnotné modely. P i modelování je krom výsledného modelu d leºitý samotný proces modelování. XM také upozor uje na t i mýty spojené s modelováním: P edstava, ºe modelování je totoºné s dokumentací. Vývojá i necht jí ztrácet as s dokumentací, tak nemodelují. P ece ování významu model vytvo ených p edem. N kte í v í, ºe namodelovat v²echno p edem je správné. To je spojeno s b ºnou praxí zmrazení poºadavk na za átku ºivotního cyklu. Nutnost pouºívat CASE nástroj, který nejlépe zvládne sloºité modely. Mnohdy je ú in j²í vytvá et jednoduché modely, které zachycují jen d leºité informace místo nepodstatných detail. Principy agilního modelování shrnuje následující seznam. Nejd leºit j²ím úkolem je vytvo it fungující software cílem není vytvo it modely, ale vytvo it kvalitní software, který odpovídá pot ebám zákazníka Druhým nejd leºit j²ím úkolem je umoºnit dal²í práci na projektu vytvo ený software musí být natolik robustní, aby jej bylo moºné dále rozvíjet, sou asn je t eba mít k dispozici takovou dokumentaci, aby byl dal²í rozvoj moºný Obsah je mnohem d leºit j²í, neº reprezentace kaºdý model m ºe být reprezentován r znými zp soby. Je t eba vybrat dosta ující zp sob aby splnil ú el modelování; modely tedy nemusí být perfektní, ani nemusí být nutn vytvo ené CASE nástroji. Jednoduchost nejjednodu²²í e²ení je nejlep²í e²ení (Occamova b itva). Komunikace hlavním smyslem modelování je komunikace mezi leny týmu na vzájem i se zákazníky a zájmovými skupinami.

34 20 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK Modelovat za ur itým ú elem modely by se m ly vytvá et, jen kdyº je jasné, pro koho je model ur en a pro. Uchopit zm nu zm ny nastávají, je t eba je akceptovat. Zm ny je pot eba d lat p írustkov je lep²í m nit systém po malých ástech, neº provést jednu v²ezahrnující zm nu. Je t eba se u it od druhých nikdo nem ºe znát v²e. Je t eba se u it od druhých a rozvíjet své znalosti. Znát své modely existují r zné modely, které odráºejí r zné pohledy na systém. Je t eba znát jejich silné a slabé stránky a efektivn je vyuºívat. P izp sobení metodiky metodiku je t eba p izp sobit podle konkrétních podmínek. Maximalizovat výnosy z investic je t eba maximáln zhodnotit vynaloºené prost edky. Více model k dispozici je ²iroké spektrum model, je t eba pouºít nejvhodn j²í. Otev ená komunikace lidé se musí cítit volní, díky otev ené komunikaci mohou d lat lep²í rozhodnutí. D raz na kvalitu je t eba se zam ovat na kvalitu softwaru v celém procesu jeho vývoje, kvalitní software m ºe splnit poºadavky zákazníka, je snaz²í jej m nit. Rychlá zp tná vazba nejcenn j²í p i vývoji je rychlá zp tná vazba, prost edky pro její zaji²t ní jsou krátké iterace, prototypy, uºivatel je sou ástí týmu. Cestovat nalehko tento princip vychází z paralely mezi vývojem softwaru a slézáním hory, je t eba vytváºet jen tolik model a dokumentace, aby je lov k mohl vzít s sebou. ídit se instinkty lidí lidé se snaºí d lat v²e pro dobro v ci, je dobré vyuºít jejich tacitních znalostí. Praktiky agilního modelování shrnuje následující seznam. Aktivní ú ast investor úsp ch projektu asto závisí na aktivní ú asti investor vedení podniku, operativní pracovníci, jiné týmy Pouºívání standard p i modelování je t eba pouºívat obecné standardy modelování Vyuºívání vzor je t eba pouºívat analytické i návrhové (architektonické a implementa ní) vzory Pouºívání správných artefakt artefakt je velké mnoºství a je t eba vybrat vhodný pro daný ú el Kolektivní vlastnictví odvozeno od praktik XP umoº uje kaºdému pracovat na libovolném modelu Testování model testování je základní prost edek vytvá ení kvalitního softwaru, je t eba testovat i modely

35 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK 21 Paralelní vytvá ení r zných model modely reprezentují r zné pohledy na vytvá- ený systém, je t eba znát silné a slabé stránky jednotlivých typ model a vytvá et více model Jednoduchý obsah je t eba se snaºit o jednoduchost obsahu model Jednoduché zobrazení model je t eba se snaºit o jednoduchost zobrazení model, je vhodné pouºívat podmnoºinu notace, cílem je jednoduchý model, který zachycuje klí ové rysy Odstran ní do asných model v t²ina vytvá ených model je do asná, kdyº splní sv j ú el je t eba je zru²it Ve ejné vystavení model podporuje princip otev ené komunikace Formalizace poºadovaných model n které modely jsou poºadovány nap. vedením, ty je t eba formáln upravit P echod na jiné artefakty protoºe modely reprezentují r zné pohledy na vytvá ený systém a vzájemn se dopl ují, je t eba p echázet mezi modely Modelování v malých p ír stcích souvisí s p írustkovým modelem, není moºné vytvo it detailní model p edem, ale vytvá í se postupn Modelování pro komunikaci smyslem modelování je komunikace v týmu, se zákazníkem, s vedením Modelování pro pochopení smyslem modelování je pochopení problému Je nebezpe né modelovat sám modelování je innost, která vyºaduje abstrakci, zku- ²enosti, existuje více moºností, jak model navrhnout, proto je vhodné modelovat s jinými Testování model kódem model je abstrakce, pro zji²t ní, zda skute n bude fungovat, je t eba napsat kód Znovupouºití existujících zdroj je t eba vyuºívat hotové modely, vzory Úprava jen kdyº je to nezbytné úpravy model jsou náro né a m ly by se realizovat, jen kdyº je to nezbytn nutné Pouºívání nejjednodu²²ích nástroj v t²ína model m ºe být malována na tabuli Agilní model je takový model, který plní sv j ú el, je pochopitelný, je dostate n p esný, je dostate n konzistentní, je dostate n detailní, p iná²í kladnou hodnotu a je co moºná nejjednodu²²í. 4.2 Webové metodiky Tvorba softwarových produkt pro web má svá specika, která u jiných oblastí vývoje softwaru nenajdeme. Webové metodiky se na n snaºí reagovat a podporovat je. Mezi najvýrazn j²í rys pat í marketingový charakter, vytvá ené stránky jsou druhem reklamní prezentace. Je proto d leºité do vývojového týmu za adit také experty na tuto oblast (reklamní text, typograe, design atd.).

36 22 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK Rychlost dodání je u webových aplikací zcela zásadní. Není prostor pro omyly, protoºe rozpo et v ádu desítek tisíc korun nedovoluje zdrºení. Pouºití hotových e²ení je zcela zásadní. Vývoj musí za ít jasným stanovením cíl a ú elu, kterému má slouºit. S tím souvisí denice cílové skupiny uºivatel, kterým se musí obsah p izp sobovat (web pro seniory nebude pouºívat stejné jazykové prost edky, jako web pro mladistvé). Projekt sleduje cílovou skupinu uºivatel. Promítání vnit ních struktur objednatele nebývá p ínosem. Velký d raz je kladen na návrh uºivatelského prost edí. Na webu je konkurence vzdálena pouze jedno kliknutí my²i, proto je d leºité náv²t vníka webu zaujmout a nena²tvat. Stan Ward a Per Kroll uvád jí v materiálu o vývoji web pod RUP, ºe nikdy p edtím nebylo tak d leºité uºivatelské rozhraní aplikací, jako dnes na webu. Je t eba urdºovat konzistenci ovládacích a naviga ních prvk, musí být jasn denovaná koncepce a musí být platná nap í v²emi stránkami webu. P ístup k testování je také zcela odli²ný. Testování rozpadání layoutu, barev a rozli²ení v r zných prohlíºe ích a r zných OS je výhradn subjektivní záleºitostí, p i které hraje vliv zku²ené oko testera. Automatizované testy vy e²í pouze ást problematiky testování (pouze chyby 404, 403, 500). Tradi ní p ístup k testování p edstavuje kontrola formulá ových vstup a vícekrokových proces (nap. odbavení objednávky v e-shopu). Primárním cílem by nem lo být dosaºení co nejv t²ího po tu unikátních uºivatel, ti nejsou dlouhodob p ínosní. D leºit j²í jsou v rní uºivatelé, kte í se na web vracejí a mohou web doporu it svým známým. Dle výzkumu agentury Forrester research [12] jsou hlavními poºadavky uºivatel webu p edev²ím: kvalitní obsah snadné pouºívání astá aktualizace obsahu minimální doba nutná pro staºení Jennifer Fleming Jennifer Fleming Zakládá vývoj na iterativním p ístupu, kdy jsou dodávány fungující meziprodukty. Kaºdá iterace se skládá ze ²esti fází: Shromáºd ní informací Sb r takových informací, které jsou nezbytn nutné pro posouzení proveditelnosti projektu. Nezabýváme se podrobnostmi, na ty p ijde ada pozd ji. V této fázi se uplnatní diskuze se zákazníkem, dotazníky, vyhledání konkuren ních projekt, zji²t ní novinek v oboru a sledování budoucích uºivatel p i jejich b ºné práci. Výsledkem by m lo být získání celkového p ehledu o problematice, vymezení lidských zdroj, rozpo tu, obsahu a hrubého harmonogramu. Tyto záv ry se budou v pr m hu m nit, nejsou pevn dané. Stanovení strategie Úkolem této fáze je identikace problém, prozkoumání reálných model, shromáºd ní v²ech dostupných materiál o problematice. Rozpoutává se spontánní diskuse (brainstorming) o moºnostech e²ení, následn se denuje koncepce a rozsah. Sestaví se hlaví struktura budoucího webu a prozkoumají se alternativy designu a implementace.

37 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK 23 Vytvo ení prototypu Pro zákazníka platí IKIWISI, tedy I'll know it when I'll see it. Nejlep²ím zp sobem, jak se p iblíºit nálnímu produktu s nejmen²í námahou je vytvo ení prototypu. Vývoj prototypu zahrnuje tyto fáze: mapování pohybu po stránkách vytvo ení ukázek designu vytvo ení a otestování prototypu vytvo ení nální architektury na rtnutí specikace produktu Implementace P ed jejím zapo etím by m l zadavatel odsouhlasit strategii a konkrétní vlastnosti produktu. Je t eba: shromáºdit budoucí obsah, dokon it uºivatelské rozhraní, vytvo it výkonné jádro aplikace a vy e²it nov vyvstanuv²í problémy. Uvedení do chodu T sn p ed a po ve ejném spu²t ní je t eba zabývat se p edev²ím: testováním a zaji² ováním kvality (bugxy) a aktivním marketingem (registrace ve vyhledáva ích, dopln ní META tag, vytvo ení reklamních banner ). Údrºba, správa a roz²i ování Údrºba se skládá z n kolika sou ástí (aktualizace obsahu, roz²i ování funk nosti, zm ny designu apod.). Záleºí na kontraktu, která sou ást bude zaji² ována vývojovým týmem a kterou si obstará zákazník sám, nebo ve spolupráci se t etí stranou.

38 24 KAPITOLA 4. P EHLED ZNÁMÝCH METODIK

39 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 25 5 Popis navrhnutého e²ení Problematiku vývoje internetových aplikací uchopíme nejd íve ze ²iroka, v kontextu komer ního vývoje, a pozd ji se zam íme p ímo na vlastní produkci. D vodem k tomu je fakt, ºe má-li být metodika do rmy implementována, musí odpovídat jejímu prost edí a navíc bude fyzicky zaznamenána podobn jako jiné, pro rmu d leºité, skute nosti. Pro e²ení takto rozsáhlé problematiky pouºijeme metodu rozd l a panuj. Firmu rozd líme na samostatné správní celky (odd lení), které budou mít spole ný jmenovatel ve form managementu rmy. Ten bude ur ovat rozpo ty pro odd lení a strategii rmy jako celku. Nad v²emi odd leními (v ele s vedoucími) bude jako arbitr fungovat editel, který se v literatu e [20] ozna uje jako Executive Director (ED). Vedoucí má v odd lení rozhodující hlas a nese za výkon odd lení plnou zodpov dnost. N které díl í zodpov dnosti p edává (deleguje) ve form rolí na své pod ízené. T ívrstvou sturkturu dle [20] ukazuje následující obrázek 5.1. Vedoucí dají dohromady strategický plán, manaºe i kontrolují fungování rmy a worke i vykazují výkon a starají se o zdroje rmy. Obrázek 5.1: 3-vrstvá struktura rmy Vedoucí Reektují zasazení rmy jako celku do spole nosti. Vedení (v na²em pojetí v²ichni vedoucí odd lení) spole n formulují strategii rmy (strategický plán). Vedoucí formuluje detailní strategii postupu svého odd lení. Starají se o rozd lení zdroj v rámci svého odd lení (peníze na b h a rozvoj, lidé). Vedoucí je vstupní branou do odd lení, na kterou se mohou obracet v²ichni zam stnanci rmy. Vedoucí je povinen reagovat dát odpov d. Informují zam stance o d ní ve rm. Manaºe i Reektují sou asný stav proces, navrhují, jak je zlep²it. Manaºe i hospoda í s p id lenými zdroji (uvol ují lidi, které nepot ebují a ºádají vedoucí o lidi, pokud se jim nedostává).

40 26 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ Kaºdodenn ur ují, jaké práci se kdo a kdy bude v novat. Kontrolují díl í výsledky a ídí sestavení v celek. Starají se o to, aby byly v ci za ízeny. Sbírají podn ty z kaºdodenních inností a sestavují protokoly nebo reporty pro vedoucí (monitoring). Worke i - adoví zam stnanci Skute ný výkon rmy, provozní záleºitosti, dodaný SW, poskytnutá sluºba. Výkon, v na²em pojetí worke i, dostávají jasn zadanou práci se v²emi podklady. Nepovaºujíli zadání za dostate n jasné, mohou zpracování úkolu odmítnout. Práce není generována svévoln, ale vºdy vzhledem ke stanoveném plánu (projektovému i strategickému). Existují-li pochybnosti, m l by se zeptat worker nad ízeného. Worker p i své práci pe uje o vnit ní zdroje rmy (know-how), p ípadn nové podn ty konzultuje se správcem remní knowledgebase (wiki). Worker by m l vyuºívat spole né zdroje v co nejv t²í mí e tak, aby byla jeho práce efektivní. Worker je zodpov dný za práci, kterou d lá, a m l by dodrºet p id lenou asovou dotaci. M ºe práci odmítnout z d vod nedostatku kvalikace. Práci, kterou worker vykonává je dokumentována pomocí dotprojectu, který je napln n nejpozd ji na konci pracovního týdne. Kaºdé odd lení má své poslání, ú el, kv li kterému ve rm existuje. Vedoucí musí mít vizi, jak by m lo odd lení vypadat v budoucnu (formuluje strategii). Kaºdé odd lení si eviduje seznam poºadavk, které jsou na n j kladeny (krátkodob i dlouhodob ). Obchodní a marketingové odd lení Mezi základní cíle kaºdé komer ní rmy pat í dodávání hodnot zákazník m za p íslu²nou odm nu. S tím se váºe problematika obchodn právního vztahu. Ten je nejprve t eba identikovat, pak vybudovat a pozd ji udrºovat. Korektní p ístup k zákazníkovi s oblasti vývoje SW znamená, ºe s ním budeme komunikovat i po p edání a zaplacení díla tak, aby nedo²lo k jeho znehodnocení v d sledku ²patného pouºívání nebo zastarání (objeví se v businessu zákazníka nové skute nosti). Toto povaºujeme za klí ovou my²lenku rmy. Úkolem tohoto odd lení také je: prezentovat rmu na venek (starat se o corporate identity), vyhledávat nové zákázky a p edávat je projektovému odd lení ke zpracování, udrºovat dobré vztahy se zákazníky (nap. poslání PF na konci roku). ICT odd lení (IT odd lení) B ºnou sou ástí kaºdé rmy je odd lení zabezpe ující provoz výpo etní techniky, SW rmy nevyjímaje. Situace se zdá být jednodu²²í, protoºe je zde p evis pracovník, kte í jsou nadm rn po íta ov gramotní. Výsledek je v²ak opa ný. Kaºdý odborník povaºuje práv sv j názor za nejlep²í a obtíºn se hledají kompromisy.

41 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 27 Proto je vhodné ur it rozpo et a zodpov dnou osobu, pod kterou bude toto odd lení fungovat. Zefektivní se tím vyuºití prost edk pro vnit ní rozvoj, kdy nedochází ke generování zisku rmy. Odd lení se stará o provoz remní sít, v etn virtuálních p ipojení VPN, p ipojení pobo ky k internetu, pracovní stanice zam stanc a licence pouºívaného SW. Toto odd lení na sebe bere také úlohu správce a vývojá e interních informa ních systém, které rma vyuºívá, v etn webové prezentace rmy. Do tohoto odd lení pat í také zabezpe ení b hu produk ních server, jejich zálohování, monitoring a upgrade. Produk ní odd lení (projektové) Zabezpe uje výnosy rmy, ostatní odd lení tvo í pouze náklady. Toto odd lení p edev²ím ídí vývoj a koordinaci projekt, alokuje workery, vytvá í odhady na nové projekty a p ijímá je ke zpracování. Pod toto odd lení pat í i udrºování remního know-how o pouºívaných techhnologiích. Provozní odd lení Provozní odd lení zaji² uje ostatní innosti, které nesouvisí p ímo s produkcí, ale není t eba na n zavád t samostatná odd lení. P edev²ím jde o kaºdodenní b h rmy. Pat í sem zásobování, technická údrºba prostor rmy, vy izování administrativy a ú etnictví (komunikace s externí rmou), provoz remního automobilu, evidence majetku rmy, vyhledávání p íleºitosí pro vzd lávání zam stnanc, zam stnanecké otázky (Human resources, team building) a vyhodnocování ekonomického zdraví rmy. 5.1 Zavedení manuál Pro kaºdé odd lení navrhujeme zaloºit manuál neboli p íru ku, která bude popisovat innosti odd lení. A to v rovin kaºdodenní innosti i v rovin e²ení neobvyklých situací. Manuál by m l obsahovat popis rolí, které v odd lení p sobí a jejich interakci p i práci. Manuály budou kodikovanou formou zaznamenávat aktivity rmy tak, aby je bylo moºné sledovat a zlep²ovat (to odpovídá 3. úrovni v SE-CMM). Krom manuál jednotlivých odd lení by m lo vedení rmy vydat a udrºovat také manuál obecný, který denuje, jak je rma ízena, organizována a jaké jsou její základní principy. Z pohledu metodického p ístupu k projekt m budeme detailn formulovat projektový manuál, ale budou nás zajímat i navázané ásti ostatních manuál (potaºmo odd lení) rmy. V následující kapitole popí²eme obsah obecného manuálu. Dále okrajov zmíníme i obsah ostatních Obecný manuál Vize a mise [20] jsou krátká pojednání informa ního charakteru, která popisují, pro rma existuje a na jakých staví hodnotách. Strategický plán je popis dlouhodobé innosti rmy (v ádu let), která by m la vést k napl- ování vize a mise. Kodex (neboli zákoník), ur í fundamentální a bez vyjímky platné teze spole nosti. Jedná se

42 28 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ o desatero, jímº se v²ichni zam stnanci musí ídit. Poru²ení kodexu se bere jako obzvlá² hrubé poru²ení pracovní kázn. Obecný manuál obsahuje informace o prost edí, ve kterém spole nost funguje a povaºuje je za klí ové nap. zm na v projektu je vºdy nevyhnutelná. Vydenování povinností zam stnance a zam stnavatele je základem jejich dobrého vztahu. Právní norma obchodního zákoníku p edepisuje obecnou rovinu tohoto vztahu, která by v této kapitole obecného manuálu m la být rozpracována. P edev²ím jde o dlouhodobé udrºování vztahu: osobnostní rozvoj zam stnance (²kolení) a valorizaci mzdy Bezpe nost Bezpe nostní pravidla jsou sou ástí obecného manuálu a p edstavují jeho d leºitou ást, proto jim v nujme celou kapitolu. V duchu [17] a [16] je t eba problematiku bezpe nosti chápat nejenom systematicky a navrhovat technologicky bezpe né systémy, ale brát v ohled i skute nosti související s lidským faktorem. Nap. pokud budete po uºivateli poºadovat do kaºdého systému jiné heslo, nejspí²e si je nechá uloºené v systému (prohlíºe i), anebo h, napí²e si je na papírek a p ilepí na monitor. Uve me analogii ze silni ní dopravy. D íve bylo m ení rychlosti provád no s utajením, namátkov. idi i se navzájem upozor ovali, volali do rádií, po ídili si anti-radary, aº nakonec za ali vozit GPS navigace se zaznamenanými oblíbenými místy m ení. Postoj legislativy se zm nil, za ala místa m ení ozna ovat sama. Pro? Protoºe tak, jako jeli idi i podle p edpis, kdyº byli na m ení upozorn ni neociáln, tak stejn jedou i po upozorn ní ociálním. Náklady na výrobu zna ky s omezením rychlosti a nápisem úsek m ený radarem jsou tém stejné, jako bez n j. Ale mnohem úsp ²n ji se da í sledovat p vodní zám r, aby idi i jezdili tak, jak mají (alespo na statisticky kritických úsecích). D leºité je nenutit uºivatele (zam stnance) do v cí, které d lat nechce, ale pozorovat ho p i práci a brát jeho návyky v potaz p i formulování pravidel, kterými se má ídit. Následuje vý et bezpe nostních zásad formulovaných pro pot eby na²í spole nosti. Pravidla bezpe nosti práce v prostorách rmy i mimo ni a zp sob pro²kolování zam stnanc. Obecná pravidla bezpe nosti pouºívaných informa ních systém (IS) a hesel zam stnanc. V na²í spole nosti platí: Platí p ísný zákaz vytvá ení uºivatel s heslem: admin, test, veslo, kreslo apod. Platí kdekoliv pod pohr ºkou vyvrºení za ºiva! Pokud pot ebujete heslo slabé, pouºijte vývojá ské heslo, které v²ichni znají. Pokud vytvá íte do asné heslo pro zákazníka, pouºijte generátor hesel. Excentrická formulace výrazn pomáhá zapamatování si tohoto principu a je v duchu neformálního p ístupu, který rma vzhledem k zam stnanc m prosazuje. Principy uchovávání remního know-how a problematiku nakládání s citlivými údaji zákazník (Non-disclosure agreement). V této souvislosti doporu uje [16] zavedení ozna ení dokument podle stupn utajení. Pro pot eby na²í spole nosti sta í dv úrovn : projektové a condental (d v rné). K projektovým informacím mají na poºádání p ístup v²ichni zam stnanci, k d v rným pouze d v ryhodné osoby (majitelé a vedoucí odd lení). pravidla zálohování dat rmeních, vývojových i zákaznických (z b ºících projekt ). Firemní a vývojová data jsou uloºena v repozitá ích Subversion ( tigris.org), zákaznická data jsou p edev²ím ( y, hostingy a obsahy databázází).

43 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 29 zp sob sdíleného uchovávání hesel. Na kaºdý projekt p ipadá p ibliºn 5 hesel (DNS, SSH, FTP, DB a ové schránky). P i evidenci cca 300 projekt jiº pot ebujeme so- stikovan j²í p ístup. Pro na²e pot eby slouºí dob e multiplatformní software KeePass ( s p ístupem pod sdíleným heslem. Explicitn je v²ak t eba de- novat podmínky konkuren ního p ístupu. Krom projektových hesel existuje pot eba evidovat i hesla do systému klí ových pro spole nost (nap. superuºivatelský ú et na servery a pod.) toto je e²eno samostatným repozitá em na hesla, jehoº sdílené heslo znají jen klí ové osoby. Repozitá e se ozna ují: projektový a condental. Pro udrºení bezpe nosti v ase je t eba denovat bezpe nostní audit. Zavádíme dva druhy: velký pravidelný jednou za p l roku a malý operativn podle pot eby. 1. Velký bezpe nostní audit Operace a její harmonogram bude oznámena v p edstihu v²em zam stnanc m mailem i ve rmením IS. Doporu ené je osobní setkání v prostorách rmy, aby byl zásah do provozu co nejcitliv j²í. Termín nejbliº²ího auditu je stanoven po dokon ení p edchozího. P i auditu dojde p edev²ím ke zm n hesel a certikát, konkrétn : v²echny certikáty na OpenVPN pro p ipojení na rmení LAN, certikát na OpenVPN p ipojení mezi servery, hesla zam stnanc i externist do Subversion, remních , Active Directory a OpenVPN, administrátorská hesla do interních systém, administrátorská hesla pro konguraci hosting na v²ech serverech, FTP, SSH a DB hesla pro interní systémy (dotproject, Wiki,... ), rootovské hesla na v²echny servery a routery, zm na sdíleného p ístupového hesla v²ude, kde je pouºito (projektový KeePass, administrace vyvíjených systém,...). V rámci auditu se zkontrolují systémy na reliktní uºivatelské ú ty a v²em se doporu- uje zm nit také svá osobní, neremní, hesla. 2. Malý bezpe nostní audit Probíhá operativn, p edev²ím p i t chto situacích: odchod zam stnance, ukon ení spolupráce s klientem, odcizení citlivých dat (ukradení notebooku, vykradení bytu, hacknutí mailu nebo serveru), jiné ohroºení bezpe nosti i podez ení na n j. Rozhodnutí o malé revizi provede vedoucí IT odd lení na podn t kteréhokoliv ze zam stnanc. Vedoucí IT také stanovuje rozsah a podobu p ijatých opat ení Obchodní a marketingový manuál Kniha [11] je situovaná do prost edí v t²ích rem (obchod ) s mnoha zákazníky, ale n které záv ry jsou inspirací pro ná² manuál. Nap. fakt, ºe zákazníci odmítají automatické úst edny s nahranými odpov mi pro e²ení svých problém stejn tak, jako odmítají lhostejné a monotónní operátory. Cesta, která zákazníka pot ²í, je osobní p ístup zaloºený na d stojnosti, respektu, zdvo ilosti a vlídnosti. Tato kniha také uvádí, ºe poskytování ºádné sluºby není bez závad a jejich úplné odstran ní není moºné, proto je t eba denovat zp sob, jakým se s reklamacemi zákazník vypo ádat tak, aby

44 30 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ byli ob strany spokojené. My jsme konkrétn denovali zp sob, jak zam stnanci odpovídají na telefonní hovory zákazník (tzn. p edstavení, vyslechnutí, identikace problému a delegace na kompetentní osobu). Sluºba zákazník m nemusí být k dispozici pouze pro p ípad problém, ale m la by jednat i preventivn, nap íklad pravidelnou nezpoplatn nou náv²t vou zákazníka a pozorování ho p i práci. Z toho vyplyne nezávazná konzultace se zákazníkem, která m ºe být zasetým semínkem pro dal²í rozvoj dodaného softwaru. Velkou oblastí kompetence obchodního a marketingového odd lení je tzv. Corporate Identity neboli konzistence prezentace spole nosti na venek. Krom grackého zpracování vizitek a hlavi kových papír sem pat í také podoba a obsah remní webové prezentace, podpis v ech a dal²í. Mezi problémy accountingu v na²em oboru pat í také sledování poskytovaných hostingových sluºeb a jejich zpoplat ování. Obchodní odd lení by m lo mít dobrý p ehled o rozsahu vyuºívání hostingových sluºeb jednotlivými zákazníky tak, aby jim mohla poskytovat sluºby víc ²ité na míru Provozní manuál Denujeme zde mimo jiné spole né statky (sdílené prost edky) a za jakých podmínek je lze vyuºívat, a to jak k pracovním, tak soukromým ú el m ICT manuál Tento manuál dokumentuje zp sob, jak fungují a jak se spravují výpo etní prost edky na kterých spole nost projekty vyvíjí i provozuje. Je to popis LAN (wi, tisk, routery,...) i serverových kongurací (HW, sluºby, skripty spou²t né cronem,...). Jsou zde popsány i procesy podpory vývojového týmu, nap. p i zakládání Subversion repozitá, DNS záznam, hosting, , obnovování ze záloh atd. Na detailní popis není bohuºel v této práci místo Projektový manuál Tento manuál je st ºejní ástí této práce a pro snadn j²í uchopitelnost je umíst n do p ílohy A. Na tomto míst zmi me pozadí dokumentu. Je ur en v²em zam stnanc m rmy, kte í se podílejí na vzniku softwarových produkt, obsahuje popis ºivotního cyklu projektu a jeho vazbu na obchodní zájmy spole nosti. V kapiole 5.3 je uvedeno n kolik rovin, které budeme zohled ovat. Projektový manuál popisuje tvorbu projektu na zelené louce. Pro univerzální pouºitelnost je t eba doplnit podrobný popis postupu pro úpravu na existujících webpvých aplikacích (zm na funk nosti, SEO apod.). 5.2 Role a kompeten ní model Metodika RUP ([1] str.57) íká, ºe: role mohou mít podobu mnoha jednotlivc nebo tým, p i emº kaºdý jednotlivec nebo kaºdý tým m ºe mít podobu mnoha r zných rolí. Z toho se inspirujeme a denujeme to v kontextu malé rmy následující metaforou:

45 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 31 Role je jako klobouk, v jednu chvíli m ºeme na hlav mít i n kolik klobouk najednou, ale jen jeden je ten vrchní, který je vid t. Kaºdá role je denována takzvaným popisem role (job description), který obsahuje: popis, pro role existuje, jaký je její ú el a poslání seznam zodpov dností seznam kompetencí seznam dokument, na jejichº vzniku se podílí a p ípadn strategický plán rozvoje role Pouºíváme princip kompeten ního modelu [19], který denuje rozdíl mezi kompetencí a zodpov dností následovn. Zodpov dnost je povinnost, která je zásadní pro fungování rmy. Kompetence je v le zm nit (zlep²it) podmínky v ur ité oblasti zájmu rmy. Pro jednotlivá odd lení se dá formulovat ada rolí, ale my se v této práci zam íme pouze na role související s vlastním vývojem. Ty jsou popsány v p íslu²né ásti projektového manuálu. Uve me zde ale princip, který zaru uje, aby nez staly n které zodpov dnosti nebo kompetence v meziprostoru tak, ºe nikomu nep íslu²í. Obrázek 5.2: kompeten ní model Analogií, na které princip vysv tlíme, je soustava sít od nejhrub j²ích po nejjemn j²í. Hrubé síto p edstavuje workery, kte í odchytí nej ast j²í problémy, na který model pamatuje. Mén obvyklé situace e²í jemn j²í síto p edstavující nad ízeného pracovníka (project manager PM), dále pokra ujeme k vedoucímu odd lení (production coordinator PC), aº nakonec nejkomplikovan j²í situace kon í u svrchovaného vedoucího spole nosti (executive director ED). Obrázek 5.2 situaci ilustruje.

46 32 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 5.3 Metodika Publikace [3] denuje v 2. kapitole adu kritérií, které kategorizují metodiky, proto popi²me kritéria i té na²í, navrhované (viz. tabulka 5.1). zam ení rozsah váha typ e²ení doména p ístup PM projektová metodika (IS do ur ité oblasti) fáze: UST úvodní studie GAN globální analýza a návrh IMP implementace ZAV zavád ní dimenze: SW platforma, architektura IS, S BD, middleware apod. DATA obsah a struktura datové základny, fyzické uloºení UI uºivatelské rozhraní systému EKO zahrnuje nan ní náklady tvorby a provozu role: PC production coordinator (koordinuje práci na více projektech zárove ) PM project manager (komunika ní prvek, zakládá tasky) HP head programmer (architektura IS, sloºení systému z celk ) ANAL analyst (business analýza a zadání, odhaduje náro nost) DB SPEC database specialist (struktura DB, indexování, vyhledávání) APP DES application designer (návrh uºivatelského rozhraní) PRG programmer (implementace funkcí) SEO SEO, SEM specialist (optimalizace pro vyhledáva e) GPHX graphic designer (gracká podoba ehokoliv) COPY copywriter (formulace text ) TPL template coder (lámání HTML a CSS) TST tester (testování funk nosti, testování v prohlíºe ích) MM st ední NEW vývoj nového e²ení (na zelené louce) UPG rozvoj a roz²í ení (upgrade) CTM content management ízení obsahu ECO e-commerce elektronické obchodování WKF workow automatizace podnikových proces, ob h dokument OO objektový vývoj ve v²ech fázích Tabulka 5.1: Kritéria navrhované metodiky Stejná kniha íká, ºe metodiky je t eba customizovat (p izp sobit) nejenom dle pot eb spole nosti, která ji pouºívá, ale i dle pot eb projektu, kde ji chceme uplatnit. První p izp sobení se snaºíme zahrnout do denice metodiky, druhé bude p edm tem prvotního zkoumání zadání. V projektovém manuálu jsou ozna eny místa p izp sobení. Popisované e²ení staví na exitujících metodikách tak, aby nedocházelo k duplicitním denicím. Není t eba vymý²let vymy²lené. Základem je metodika Unied Process, která obsahuje v²echny základní pojmy softwarového inºenýrství sou asnosti. Uplatníme i principy agilních p ístup a p idáme vlastní best practices. Problém urdºitelnosti metodiky v tak labilním prost edí, jakým je vývoj webových aplikací si zaslouºí vlastní kapitolu, viz. 5.8.

47 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ Komunikace Pojem komunikace je sklo ován mnoha pády. My se budeme drºet teze, kterou formuloval A. Cockburn ve své knize [5] a sice: Nejefektivn j²í forma komunikace je osobní, kdy se uplat uje: fyzická blízkost (vizuální podn ty, timing, 3-dimenzionalita, v n ) r zné zp soby komunikace (gesta, slova, mimika) hlasové zabarvení, asování otázky a odpov di v reálném ase, otázky signalizují nedostate né vysv tlení nebo místo, kde chybí zázemí poslucha e Efektivitu r zných forem komunikace ilustruje obrázek 5.3. Obrázek 5.3: Formy komunikace; zdroj [3], [5] Prost edí webu Dle pozorování manaºer (nejen) na²í spole nosti je trh webových sluºeb výrazn ovliv ován rychlou zm nou technologií. Nap íklad r zné CMS v posledním roce u inily posun sm rem k laickým uºivatel m. Proto je d leºité p i prodeji webových sluºeb na tyto zm ny reagovat velmi rychle (v ádu m síc ). Firma proto musí svou konkuren ní výhodu zako enit více v metodickém p ístupu, neº v konkrétní technologii. Námi formulovaný postup obsahuje mnoho odkaz na pouºitý framework Django, ale principy p ístupu k jednotlivým fázím ºivotního cyklu SW jsou p enositelné. Charakteristickým rysem jsou stabilní standardy (nap. XHTML 1.0, CSS 2.0), které v²ak nejsou tak úsp ²n implementovány do nejpouºívan j²ích prohlíºe. Z toho plyne nep íjemné prodraºování vývoje a testování. Existují v²ak projekty (nap. intranetové aplikace), které jsou nasazeny v prost edí s jedním konkrétním webovým prohlíºe em. Pokud je toto smluvn podloºeno, lze toho s výhodou vyuºít ke sníºení náklad na vývoj. Tato varianta se asto uplat uje u back-endových rozhraní systém (administrací), kdy je administrátor ( asto zadavatel v jedné osob ) se situací srozumn n. Oproti jiným aplikacím jsou weby zatíºeny pot ebou dobrého grackého (resp. typograckého) zpracování. Do týmu se tedy za le ují odborníci na design a estetiku.

48 34 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ V souvislosti se správným dopadem na cílovou skupinu je do vývojového týmu také p izván odborník na formulování text. Jde nejenom o dojem náv²t vníka stránek, ale také o zp sob, jakým jsou interpretovány vyhledávacími roboty. P i vývoji nesmíme jít proti p irozeným standard m, na který jsou uºivatelé zvyklí. Obzvlá²t máme na mysli vizuální, sebevysv tlovací ovládací prvky (viz. skripta [15]). Nap. reprezentace zavírání pomocí k íºku, mazání pomocí popelnice, editace pomocí tuºky, detail poloºky pomocí lupy atd. Malé rozpo ty a rychlé dodání jsou b ºným poºadavkem zákazník. Na tuto rovinu se dá p istoupit, pokud budeme vytvá et weby zaloºené na CMS, kdy je st ºejní ástí vývoje vytvo ení vizuálního zpracování prezentace a obsah je upravován p es WYSIWYG editor samotným zadavatelem. V tomto p ípad si v²ak musíme p i vývoji vyºádat obsah prezentace p edem (texty, obrázky apod.), jinak riskujeme, ºe dodaná forma prezentace nebude vkládanému obsahu vyhovovat. Zákazník to pak bude reklamovat a dojde ke zhor²ení vzájemného vztahu Analytická dokumentace Analýza musí být vykonána, aby mohla být implementace úsp ²ná. Ov²em dokumentace nemusí mít v projektu takový význam, jako kone ná prezentace informací uºivateli. U webu, jehoº ºivotnost je mezi 1 aº 5 lety není nezbytné mít dokonalou analytickou dokumentaci, protoºe p i vytvá ení nové verze nebudou jiné jenom technologie, ale i byznys problémy. Pouºijeme proto p ístup agilního modelování, kdy se analytická dokumentace pouºívá p edev²ím ke zlep²ení porozumn ní p i vývoji. Praxe ukazuje, ºe poºadavky zákazníka mají n kdy charakter pocitu a jakoby visí ve vzduchu. Správn by m lo být v²e popsáno v dokumentaci, ale to je nákladné a pro nás neú elné. Pokud se v²ak analytik dokáºe empaticky do t chto poºadavk vcítit, sta í, kdyº bude denn kontrolovat práci zbytku týmu a m ºeme tyto poºadavky p i vývoji zohlednit. Analytik ovliv uje vývoj kaºdým svým slovem, kaºdým ná rtkem. Práv na nich zakládá práce ostatních expert. Pokud zám r zákazníka nepochopí analytik, bude ²patný výsledek práce celého týmu. Na²e funk ní analýza bude vycházet z popisu systému z vn j²ku, z pohledu uºivatelského prost edí. Tvrdíme, ºe vývojové techniky jsou tak exibilní a zákazníkovi poºadavky tak neucelené, ºe nemá smysl do systému zahrnovat ásti bez návaznosti na uºivatelské prost edí, které bychom tam zavád li pouze z d vodu v t²í obecnosti a snadn j²í roz²i itelnosti (my²lenka XP [2]). Pokud budou na²e programátorské návyky správné a tým bude um t efektivn p ijímat zm ny v projektu, je pro nás popis systému p es uºivatelské prost edí dosta ující. Dle metodiky Adaptive Software Development [12] je dne²ní sv t dynamický a rychle se m ní stejn jako poºadavky na dodaný systém a s tím i parametry vývojového procesu. Této zm n nelze zabránit. Je tedy vhodné za adit do vývojového procesu praktiky, díky nimº dokáºeme zm nu p ijmout (nebo dokonce uvítat). Pokud to srovnáme s internetovými aplikacemi a jejich rozsahem, který se po ítá na týdny práce, dojdeme k záv ru, který hlásají agilní metodiky obecn. Tým musí mít odvahu a sebev domí pustit se do e²ení bez zdlouhavých analýz. Moºná riskujeme zahození velké ásti kódu, ale toto riziko m ºeme sníºit nap íklad p i azením vy²²í priority klí ovým komponentám nebo pouºitím hotových komponent. 5.4 Specikace projektu P i specikaci poºadavk vyuºíváme jako st edobod roli analytika, který je kaºdodenn p ítomen vývoji projektu ( asto bývá zároven project managerem). Výstupy, které v pr b hu e²ení

49 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 35 projektu vzniknou mají následující skladbu: vize projektu gracký design 1:1 (screenshoty) denice dat a stromová struktura URL, detaily kaºdého uzlu change requesty nasbírané p i konstruk ní fázi protokol o testování (poºadavky na opravy) St ºejní ástí je denice dat a stromová struktura URL. Denice dat má podobu UML Class diagramu, který vyuºívá pouze konstrukty poskytnuté ORM Djanga. Stromová struktura URL je víceúrov ov íslovaná a pro kaºdý uzel obsahuje popis struktury a scéná. Struktura je vystiºena pomocí notace WebML units a bývá dopln na o ná rtek uºivatelského rozhraní. Scéná je popis toho, co v²echno se m ºe uºivateli na této stránce p ihodit. 5.5 Sdílení informací Rozeznáváme dva druhy informací: projektové a obecné. Projektové informace (mimo zdrojové kódy) ozna ujeme jako projektovou dokumentaci. Pod pojmem dokumentace chápeme jednak specikaci projektu, ale také protokoly o testování, odhady náro nosti v etn nan ních kalkulací. Tyto souvisí p ímo s projektem a existuje pot eba je aktualizovat, proto je uchováváme v Subversion repozitá i projektu. Pro lep²í p ístupnost t m, kte í nemají projektový repozitá, se vystavují odkazy na p idruºenou wiki (systém Trac Do budoucna se plánuje denice projektových metrik, které mají slouºit ke sledování efektivity. Konkrétní hodnoty se po uzav ení projektu zanesou do samostatného systému. Zp tn budou zaneseny také hodnoty z projekt star²ích. Pro sdílení obecných informací ve rm (knowledgebase) jsme zavedli dva systémy: mediawiki ( pro manuály subversion repozitá generic pro znovupouºitelné komponenty 5.6 Vhodný nástroj Webové stránky se dají reprezentovat mapou webu (site map), která formou stromu popisuje hierarchii jednotlivých stránek. Tento strom se dá sestavit ve velmi brzké fázi analýzy, proto je vhodný pro odhad náro nosti projektu. Formáln lze problematiku web popsat jako stavový automat. Jednotlivé stránky reprezentují stavy automatu, p echody jsou hypertextové odkazy na jiné stránky. Stavový automat se dá tedy reprezentovat orientovaným cyklickým grafem, jehoº uzly reprezentují stavy a hrany p echody. WebML zde je²t zavádí pojem kontextového a bezkontextového odkazu. Kontext slouºí k p edání parametr pro k zobrazení správných dat v daném stavu (stránce). Nap. stránka produktu má ve svém kontextu identikátor ozna ující, který konkrétní produkt má být zobrazen.

50 36 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ Kaºdé site view (tak jak ho denuje WebML) je reprezentováno jednou mapou webu. To znamená, ºe budeme mít samostatný stavový automat pro front-end (pro náv²t vníky), back-end (administrace) a p ípadn i pro dal²í specializované výstupy systému. WebML také zavádí tzv. personalizované mapy webu obsah se li²í podle role uºivatele, který do systému p istupuje. Formulujme hypotézu, ºe m ºeme analytický popis projektu reprezentovat interaktivním prototypem, který bude postavený nad zmín ným stavovým automatem a bude úplný vzhledem k rozsahu zadání Návrh nástroje Pro podporu metodiky byl autorem vytvo en nástroj, který slouºí k vytvo ení vizuálního prototypu a k reprezentaci stavového automatu. Práce staví na autorov bakalá ské práci [4], která byla implementována ve Squeaku (Smalltalk). Tato verze produktu má atraktivn j²í formu, p idává podporu projektového ízení a je implementována v Pythonu za pouºití frameworku Django. Následující sada komentovaných screenshot zachycuje výslednou podobu nástroje. Sestavený prototyp se dá procházet ve zvolené roli. Dají se také psát specikace funkcí a komentá e návrhu jednotlivých blok. Obrázek 5.4: Úvodní obrazovka s p ehledem projekt. Obrázek 5.5: Úvodní obrazovka vybraného projektu.

51 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 37 K navigaci v prototypu slouºí automaticky generované odkazy, které se zobrazují po najetí my²i v p íslu²ném bloku. Jsou to v²echny moºné p echody, které daný blok poskytuje, pro vybranou roli. Obrázek 5.6: Prototyp textová forma. Obrázek 5.7: Prototyp ukázka gracké reprezentace bloku menu. Re²er²e, která byla chybn provedena, aº následn ukázala, ºe podobné komer ní produkty existují (Auxure RP 5 Pro od spole nosti Axure Software Solutions, Inc. nebo eská Petra od spole nosti Cleverlance). Pro na²í spole nost je ekonomi t j²í pouºít tyto hotové produkty, protoºe vývoj vlastního nástroje je p íli² nákladný a musel by se kompenzovat podobnou distribucí t etím stranám, kterou d lají vý²e zmín né spole nosti. Usability testy ukázaly, ºe nástroj práci zpomaluje a vytvá í zbyte n silnou dokumentaci, coº je proti agilním princip m.

52 38 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ Obrázek 5.8: Detailní zobrazení navrºeného bloku aktuality na homepage. Obrázek 5.9: Detailní zobrazení navrºeného bloku archiv aktualit. Obrázek 5.10: Detailní zobrazení navrºeného bloku menu. Nástroj vytvá ený autorem byl dokon en do první funk ní podoby, ale jeho dal²í zlep²ování v pouºitelnosti a podpora udrºitelnosti by byla pro rmu neekonomická. Projekt byl proto pozastaven jako neperspektivní. Autor se v²ak vývojem aplikace zabývá na své vlastní náklady. Efektivitu pouºívání se pokusí zvý²it implementací nej ast j²ích návrhových vzor pouºívaných

53 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 39 Obrázek 5.11: Zadávání specikace funkcí a komentá návrhu. Obrázek 5.12: Strom URL projektu. Obrázek 5.13: Editace struktury projektu.

54 40 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ na webu (aktuality s archivem, galerie apod.). Zdrojové kódy popisovaného nástroje jsou sou ástí CD p iloºeného k této práci. Pozorování ve rm ukázalo, ºe nejv rn j²ím pomocníkem je tuºka a papír. Je to nástroj, který s editorem kódu pouºívají vývojá i nej ast ji. Dokonce bylo pozorováno, ºe se vzr stající zodpov dností (vedoucí, manaºe i) vzr stá také pot eba pouºívat tento nejprimitivn j²í prost edek. Proto jsme se uchýlili k pouºití nesoftwarových nástroj, které jsou popsány v následující kapitole. 5.7 Formulá e a checklisty Efektivní vývoj souvisí s p ímo arostí práce, kterou worle i d lají. Kaºdý to zná: pokud stavíte stan poprvé, trvá to dlouho, kdyº ho budete stav t podruhé, p jde vám to lépe, aº nakonec na 10. pokus to budete moci d lat tém poslepu. Podobn je to i s vývojem. Nehled na to, ºe p i prvích pokusech budete zoufalí a slab²í jedinci to moºná vzdají. Na druhou stranu, pokud budete 8 hodin denn stav t stany, také vám to nebude d lat dob e. Proto jsme v jednotlivých fázích ºivotního cyklu identikovali místa, kde je moºné uplatnit stejné postupy nap í projekty tak, aby zku²ený vývojá v d l, co p esn d lá a jak. Práce mu p jde od ruky, protoºe jí ned lá poprvé a necítí se ztracen. Prost edek, který k tomu pouºíváme jsou formulá e a checklisty. Formulá pouºíváme v p ípad, kdy pot ebujeme, aby se postupovalo p esn podle dohodnutého postupu a m ºeme podat up es ující komentá, který pom ºe daný bod zodpov d t. V p ípad vize projektu je formulá vypl ován p ímo se zákazníkem dotazníkovou formou. Mimo to se formulá e pouºívají pro sepsání change requestu, protokolu o testování a p edávacím protokolu. Checklist je pouze seznam vlastností a hodnot, které chceme v ur ité fázi zkontrolovat. Slouºí p edev²ím k tomu, aby nebyla opomenuta n která d leºitá ást úkolu. Pro uzav ení kaºdé fáze ºivotního cyklu vývoje je denován samostatný checklist (ty jsou sou ástí projektového manuálu). Empiricky se také mohou vytvá et checklisty pro sloºit j²í úkoly. Nap íklad p i odhadu náro nosti, kontrole úplnosti grackého návrhu, kontrole popisu struktury projektu, dokon ení díl í ásti projektu (komponenty) atd. 5.8 Udrºitelnost metodiky Abychom zajistili aktuálnost metodiky v ase, musíme ji pr b ºn aktualizovat. Metodika je popsána v projektovám manuálu, následující pravidla se v²ak vztahují na v²echny manuály ve rm, nejenom na projektový. Pro kaºdý manuál je ur en tzv. správce manuálu, který odpovídá vedoucí osob p íslu²ného odd lení. Pro projektový manuál je to tedy production coordinator. Námi denovaný rámec (formulá e a checklisty) je lehko roz²i itelný a upravitelný. Pat i n toho vyuºijme. S výhodou také vyuºijeme systému mediawiki, který umoºní kaºdému zam stnanci opravovat p ípadné chyby, které se v dokumentaci metodiky vyskytnou. Úpravy evolu ního charakteru jsou v kompetenci správce. V²echny provedené zm ny chodí správci em. Ten kaºdou zm nu kontroluje, zda byla provedena v souladu s jeho p edstavou o vývoji rmy. Jednou za rok probíhá celková revize manuálu, která má za úkol zajistit konzistenci a úplnost. P i této p íleºitosti je vyvolávána hromadná diskuze ízená p íslu²nným správcem. Jedná se tedy o zm ny revolu ního charakteru (hromadn, najednou, skokov ). Kaºdý manuál je opat en, tak jako kaºdý vznikající dokument ve rm, razítkem. To obsahuje ozna ení verze (rok/po adové íslo), datum poslední úpravy a jméno správce, který verzi vydal. Posledním bodem, který musíme zmínit, je ²kolení zam stnanc. Noví zam stnanci jsou nejd íve

55 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ 41 s jednotlivými ástmi seznámeni a následn jsou jejich v domosti ov eny v praxi. Kontrolní mechanizmus oponentur nám zajistí, aby se k zákazníkovi nedostávali nedokonalé produkty. Vzniká nám tu také problém s pou ením zam stnanc o provedených úpravách. Ten e²íme tak, ºe podporujeme vzájemnou komunikaci p i kaºdodenních úkolech (nikdy není moºné, aby byl úkol zpracován a odevzdán jedním workerem) a pravideln (kaºdý m síc aº dva m síce) dodáváme zam stnanc m manuál a p ináleºející formulá e a checklisty v ti²t né podob na pracovi²t tak, aby nepracovali se starými verzemi. V p ípad klí ových zm n toto provedeme ihned.

56 42 KAPITOLA 5. POPIS NAVRHNUTÉHO E ENÍ

57 KAPITOLA 6. ZHODNOCENÍ SPLN NÍ CÍL PRÁCE 43 6 Zhodnocení spln ní cíl práce My²lenky, které jsou vystiºeny v této práci, vznikaly postupn více neº jeden rok. Jsou postaveny na nejlep²ích postupech (best practices), které erpají z teorie softwarového inºenýrství a byly vyzkou²eny v praxi. V pr b hu e²ení se ukázalo, ºe problematika tvorby software stojí na pomezí dvou sv t, mezi kterými je v t²í rozdíl, neº se zdá. Na jedné stran je to sv t exaktní klasický a na stran druhé sv t humanitní romantický. Ve sv t programátor není prostor pro nejasné denice. Zato ve sv t obchodu není nic dáno pevn. To, co bylo v era konkuren ní výhodou, m ºe být dnes na obtíº a naopak. A co teprve, kdyº se snaºíme s programováním obchodovat? Dokonce uº p i vysv tlování na první pohled jednoduchých pojm, se setkáváme s velkým problémem r zného porozum ní. Kant jej ve svém díle Kritika istého rozumu nazval apriorní p edstavou kaºdého z nás. Softwarové inºenýrství spojuje r zné obory lidské innosti tím, ºe se je snaºí co nejv rn ji popisovat pomocí omezených (programových) prost edk. A práv v tom si je blízké s lozoí. Aby na²e snaºení na poli softwarového inºenýrství bylo úsp ²né, musíme zkombinovat mnoho znalostí a princip nap íklad z matematiky, logiky, sociologie, rétoriky, psychologie, ekonomie, manaºerství, personalistiky a mnoha dal²ích. Tato práce se zam ila pouze na ást softwarového inºenýrství vývoj webových aplikací a p eci se problematika zdá bezb ehá. Zformulovali jsme n kolik klí ových princip, které upev ují na²e pracovní postupy: dekompozice softwarové rmy na odd lení kodikace pravidel pomocí manuál rozd lení zodpov dností a kompetencí do rolí a vrstev Je d leºité si uv domit, ºe cesta k úsp chu nespo ívá v dokon ení konkrétní v ci (této práce), ale ºe jde o dlouhodobý proces reakce na okolní podn ty, o p izp sobování se (viz. analogie s genetickým vývojem). Námi denované prost edky umoº ují tento proces podporovat pomocí: zm n ve struktu e spole nosti zm n v denici rolí zm n ve zn ní manuál Zlep²ování proces je t eba v novat pat i nou pozornost, protoºe pravidla neodpovídající realit mohou situaci výrazn zhor²ovat. Spole nost za ne kostnat t a zam stnanci se za nou uzavírat do svých schránek. Za nejv t²í p ínos práce pro vývoj webových aplikací povaºujeme: opakovatelnost postup, jejich sledování a sbírání podn t pro zlep²ení (nap. odhady vs. realita) dodrºení agilních princip komplexní p ístup zasazený do praxe exibilitu metodiky pro pouºití na malých (týdny) aº velkých (m síce) projektech

58 44 KAPITOLA 6. ZHODNOCENÍ SPLN NÍ CÍL PRÁCE pruºnosti v p i azování rolí, moºnost za len ní r zn zdatných vývojá do e²itelského týmu rychlá reakce na zm ny ve vývojovém prost edí (snadná úprava checklist ) Podn ty pro aktuální zlep²ení jsou v následujícím seznamu. Atraktivn j²í zpracování. S existencí psaných pravidel vzniká pot eba je ²í it mezi zam stnanci (²kolení, p ezkou²ení). Sou asná forma nep ispívá k pochopení problému. Lep²í podpora metodiky pro postupy související s úpravou existujících projekt (nap. pouze zpracování SEO i roz²í ení o novou funk nost). Denování více variant p i vývoji, pouºití jiných framework apod. Zlep²ení vazby mezi models.py a jejich vizuální reprezentací Class diagramem automatické generování ob ma sm ry. Strategickým cílem je pro nás zavedení normovaných postup ISO a ºádost o certikaci z rodiny ISO Záv re né shrnutí Na²ím cílem bylo zefektivnit a strukturalizovat pracovní aktivity konkrétní spole nosti. Pokud uváºíme, ºe p ed zapo etím této práce existovalo pouze úst p edávané know-how, pak byly cíle jednozna n spln ny. Daný problém jsme e²ili za pouºití moderních prost edk a díl í metody byly zvoleny tak, aby pruºn reagovaly na zm ny v pr b hu procesu vývoje. Metodika byla vyvíjena v reálném prost edí a proto pln reektuje pot eby komer ní spole nosti.

59 KAPITOLA 7. LITERATURA 45 7 Literatura [1] Arlow, J.; Neustadt, I.: UML2 a unikovaný proces vývoje aplikací. Brno: Computer Press, první vydání, 2008, ISBN [2] Beck, K.: Extrémní programování. Praha: Grada Publishing, první vydání, 2002, ISBN [3] Buchalcevová, A.: Metodiky vývoje a údrºby informa ních systém : Kategorizace, agilní metodiky, vzory pro návrh metodiky. Praha: Grada Publishing, první vydání, 2005, ISBN [4] Chalupní ek, V.: Bakalá ská práce : Interaktivní nástroj pro tvorbu analytické dokumentace. FEL ƒvut, [5] Cockburn, A.: Methodology space. [Online], c2008, [cit ]. URL [6] Lawrence Journal-World: Django The Web framework for perfectionists with deadlines. [Online], c2008, [cit ]. URL [7] D dina, J.; Cejthamr, V.: Management a organiza ní chování. Praha: Grada Publishing, první vydání, 2005, ISBN [8] Gamma, E.; Helm, R.; Johnson, R.; aj.: Design Patterns: Elements of Reusable Object- Oriented Software. Berkeley: Addison-Wesley, první vydání, 1994, ISBN [9] Django weblog Guido likes Django. [Online], , [cit ]. URL [10] Holovaty, A.; Kaplan-Moss, J.: The Denitive Guide to Django : Web Development Done Right. Berkeley: Apress, první vydání, 2008, ISBN URL [11] Horrel, E.: Zákaznická v rnost. Brno: Computer Press, první vydání, 2007, ISBN [12] Kadlec, V.: Agilní programování : Metodiky efektivního vývoje softwaru. Brno: Computer Press, první vydání, 2004, ISBN [13] Keyes, J.: Knowledge management, business intelligence, and content management : The IT practitioner's guide. Boca Raton: Auerbach Publications, první vydání, 2006, ISBN X. [14] Manifesto for Agile Software Development. [Online], c2001, [cit ]. URL [15] Merunka, V.; Pergl, R.; Pícka, M.: Objektov orientovaná tvorba softwaru. Praha: ƒeská zem d lská univerzita v Praze, první vydání, 2004, ISBN [16] Mitnick, K.; Simon, W.: Um ní klamu. T inec: Helion, první vydání, 2003, ISBN [17] Norman, D. A.: The Design of Everyday Things. New York: Basic Books, první vydání, 2002, ISBN

60 46 KAPITOLA 7. LITERATURA [18] Paulk, M. C.; et al.: Key practices of the Capability Maturity Model. Version 1.1. [Online], c1993, [cit ]. URL [19] Plamínek, J.: ízení podle kompetencí. Praha: Grada, první vydání, 2004, ISBN [20] Plamínek, J.: Vedení lidí, tým a rem. Praha: Grada, druhé vydání, 2006, ISBN [21] Robbins, S. P.; Coulter, M.: Management : Sedmé vydání. Praha: Grada Publishing, první vydání, 2004, ISBN [22] Sedláková, M.: Mentální model. [Online], [cit ]. URL [23] SEI: CMMI R for Acquisition, Version 1.2. [Online], c2007, [cit ]. URL [24] Z. Dermí²ková: Systémové my²lení. [Online], [cit ]. URL [25] W3C: XHTML TM 1.0 The Extensible HyperText Markup Language (Second Edition) : A Reformulation of HTML 4 in XML 1.0. [Online], c2002, [cit ]. URL [26] WebML The Web Modeling Language. [Online], c2004, [cit ]. URL [27] Web Models s.r.l.: WebRatio You think You get. [Online], c2007, [cit ]. URL [28] Zelenka, P.: WebML - Web Modeling Language. [Online], c2005, [cit ]. URL

61 DODATEK A. PROJEKTOVÝ MANUÁL 47 A Projektový manuál Tento manuál popisuje pr b h realizace webového projektu ve frameworku Django. Denuje role a jejich innosti v jednotlivých fázích. Základními dv ma principy, které p i e²ení uplat ujeme, je komunikace a zm na. Princip správné, efektivní komunikace ilustruje obrázek. Up ednost ujeme osobní komunikaci, kdykoliv je to jen moºné. Ideáln tak, ºe zadavatel dochází za vývojovým týmem. Princip zm ny znamená, ºe ji budeme o ekávat v kaºdém kroku vývoje a budeme na ni p ipraveni. Budeme výsledky své práce konzultovat se zadavatelem, co moºná nej ast ji, abychom nevytvá eli n co, co budeme muset hned zahodit. A.1 Popis rolí Projektové odd lení má oproti ostatním odd lením specické krátkodobé role. Tyto role jsou p id l ny pouze pro pot eby e²ení jednoho projektu a p id lují se podle aktuálního personálního stavu ve rm. Jedinou stabiln p i azenou rolí je Production coordinator. Krátkodobé role se d lí na povinné a p id lené podle pot eby projektu. Krátkodobé role na jednom projektu povinné (mandatorní ur ení workera) PM project manager (komunika ní prvek, zakládá tasky) HP head programmer (vybíra pouºitý framework, sloºení systému z celk ) podle pot eby (fakultativní ur ení workera) ANAL analyst (zpracovává business analýzu a DSP, odhaduje náro nost) DB SPEC database specialist (navrhuje strukturu DB, indexování, vyhledávání) APP DES application designer (návrh uºivatelského rozhraní) PRG programmer (implementace funkcí, role existuje v p íchuti PHP a Python) SEO SEO, SEM specialist (optimalizace pro vyhledáva e) GPHX graphic designer (gracká podoba ehokoliv) COPY copywriter (formulace text )

62 48 DODATEK A. PROJEKTOVÝ MANUÁL TPL template coder (lámání HTML a CSS) TST tester (testování funk nosti, testování v prohlíºe ích) Námi zvolený p ístup k p id lování zodpov dností na projektu je velmi exibilní a umoº uje p id lit (v extrémním p ípad malého projektu) v²echny role jednomu lov ku. P itom se neztrácí p ehled o postupu, který se má p i vývoji dodrºet. Nej ast ji v²ak vyuºíváme dvou lidí, kte í si rozd lí povinné role, ty jim z stávají po celou dobu e²ení projektu. Worke i se dají rozd lit na dv skupiny: ty, co mají blíºe ke komunikaci se zákazníkem a formulaci zadání a ty, kte í rad ji dostávají ucelené zadání, na kterém pracují. Z první skupiny vybíráme PM, ze druhé pak HP. Podle povahy a rozsahu projektu se rozhodneme, které fakultativní role p id líme explicitn a které rozd líme mezi PM a HP. Nestane se tedy, ºe by n která z nich nebyla p id lena, m ºe v²ak být kumulována s ostatními rolemi pod jedním workerem. Fakultativní role by se m ly p id lovat tak, aby se mezi fázemi vývoje nem nily. Obrázek A.1: projektové role P i p i azování konkrétních rolí lidem vyuºijeme, krom p ehledu aktuální vytíºenosti worker, také tabulku, která je vid t na obrázku A.2. Hodnoty v tabulce vyjad ují kompetentnost jednotlivých worker pro danou roli. Hodnoty ur uje a aktualizuje PC podle zku²eností z minulých projekt. Obrázek A.2: Levely skill jednotlivých worker

63 DODATEK A. PROJEKTOVÝ MANUÁL 49 Pro citliv j²í posouzení porovnáváme hodnoty u jedné role mezi workery vzájemn. Jde p edev²ím o relativní vyjád ení, ne o absolutní hodnoty. Barevn m ºeme mít ozna ené klí ové lidi, kte í tvo í odborný cech dané role ve rm. Ti pak dohromady e²í nejzávaºn j²í problémy na projektech, mohou spole n formulovat strategická rozhodnutí a ur ují sm r vývoje dané role ve rm. Toto hodnocení je inspirováno úrovn mi (level) schopností (skill) ve hrách typu Role Playing Game. Anglické názvy level a skill se vºily do pouºívaného slangu. Hv zdi ky ozna ují role, ve kterých se chce daný lov k ze své vlastní v le zdokonalovat. A.1.1 Production coordinator (PC) Koordinuje asové, prostorové, materiální a nan ní souvislosti v²ech b ºících projekt. Zodpov dnosti: Kontroluje klí ové dokumenty. Koordinuje PM a p edev²ím personální obsazení projekt. P evádí asové odhady PM na nance hlídá protabilitu projektu. Pln ní strategického plánu odd lení. Schvaluje navrhnuté e²ení pro zákazníka. Schvaluje m sí ní odm ny worker m, p edává je asistentce. Pravidelná komunikace s PM o pr b hu realizace (min. jednou týdn ). Zaji² uje nástroje pot ebné pro realizaci. harmonogramy projekt. Komunikace se zákazníkem v otázkách zabezpe ení úsp ²ného dokon ení projektu, zm ny v rozpo tu. e²ení problém oznámených realiza ním týmem. Kompetence: Odmítnutí zakázky. Operativní pozastavení projektu. Schvaluje adepty na ²kolení. Poºaduje nové zam stnance. Inovace proces realizace projekt. P ijímání nových technologií po konzultaci s HP. Artefakty: Pravidelná hlá²ení o innosti na projektech (m sí n ). Výpo et výplat a odm n (vºdy do posledního dne m síce). Dokumentace úsp ²nosti jednotlivých projekt. Zpracovává cenové kalkulace ve spolupráci s PM.

64 50 DODATEK A. PROJEKTOVÝ MANUÁL A.1.2 Project manager Komunika ní katalyzátor týmu. Zakládá tasky pro ostatní leny a udrºuje dokumentaci vývoje projektu (reporty odpracovaných hodin). Zodpov dnosti: Zakládá projekt, monitoruje vývoj, uzavírá projekt. Komunikace se zákazníkem p i realizaci projektu, hledání nejlep²ího e²ení, vytvá ení odhad. Kaºdodenní kontrola práce vývojového týmu, konfrontace s vizí projektu a p edstavou zákazníka. ízení realizace (dotproject), TODO list. Kontrola report projektu a pr b ºného stav. Upozor uje PC na klí ové okamºiky ve vývoji (²patný asový odhad, problém s technologiemi...). Zabezpe uje podklady pro vývojá e. Kompetence: Návrh na zlep²ení ízení pracovních proces.. Odmítnutí projektu z d vod : nedostatku zadání, kvalikace, ned slednosti. Odmítnutí projektu z d vod nedostatku prost edk ( as, nance, pracovní síly...). Návrh na pozastavení projektu. Zaji²t ní kapacit a pot ebných nástroj pro realizaci projektu od PC. Artefakty: Návrh realizace projektu na základ podklad od zákazníka a ANAL povinná konzultace s PC, specikace poºadavk. Odhad náro nosti projektu a spojené náklady, harmonogram. Dokumentace pr b hu vývoje (dotproject). Týdenní hlá²ení o pr b hu realizace sch zka s PC. Bilancování projektu na konci realizace. A.1.3 Head programmer Vybírá konkrétní pouºité technologie a znovupouºitelné komponenty. Integruje e²ení. Vytvá í architekturu, d lí systém do samostatných celk komponent. Zodpov dnosti: Návrh e²ení aplikace na modelové úrovni (arhcitektura). Integrita práce na úrovni kódu. Podpora ostatních programátor. Upozr uje na problémy ( asové prodlevy, technologické nedostatky) vzniknuv²í p i realizaci. Návrh technologie e²ení (výb r frameworku, modx/django/...).

65 DODATEK A. PROJEKTOVÝ MANUÁL 51 Koncepce modelového e²ení. Správné rozd lení zdrojového kódu (JS extern,...). Kompetence: Zm ny v konvencích psaní kódu. Odmítnout projekt pro ned slednost i nesrozumitelnost zadání, resp. nesplnitelnost. Návrh na inovace technologií a postup. Návrhy na zlep²ení architektury i databáze projektu. Artefakty: Návrh architektury systému sitemap, Django aplikace. Spustitelné jádro systému. Nasazení systému do produk ního prost edí. A.1.4 Analyst D lá business analýzu, pí²e specikace úkol pro ostatní leny týmu. Dává do souvztaºnosti skute nosti z reálného sv ta a vytvá ený systém. Zodpov dnosti: Podrobná analýza poºadavk klienta ve v²ech fázích. D sledné provedení klienta moºnostmi e²ení zadání. Kompetence: Návrh volby technologie. Návrh e²ení UI. Doporu uje optimalizaci e²ení v i nan ním moºnostem klienta. Artefakty: Vision document. Doménový model ilustrující procesy a p edstavu klienta. Specikace jednotlivých stránek a jejich funkcí. A.1.5 Database specialist Navrhuje strukturu DB tak, aby spl ovala výkonostní poºadavky. Zodpov dnosti: Návrh databáze a volba SQL serveru. Dopl ující technologie (fulltext engine,...). Optimalizace databáze (cache tables, indexing,...). Kompetence:

66 52 DODATEK A. PROJEKTOVÝ MANUÁL Návrh na modikaci architektury. Návrhy na inovace technologických postup. Artefakty: Datový model. A.1.6 Application designer Návrhuje uºivatelské rozhraní, tak aby bylo ergonomické a konzistentní. Zohled uje zku²enosti budoucího uºivatele a zvyklosti prost edí, kde bude systém pouºíván. Zodpov dnosti: Návrh aplikace z hlediska p ístupnosti a pouºitelnosti UI (ISO ). Kontrola konzistence projektu z u6ivatelsk0ho pohledu. Komplexní podání rozhraní aplikace s ohledem na poºadavky klienta. Kompetence: Inovace technologie navrhování UI (po konzultaci s Project Managerem). Návrh optimalizací e²ení. Artefakty: Vizualizace aplikace (alespo na úrovni wireframes). Úpravy v templatech tak, aby byly napln ny zodpov dnosti. A.1.7 Programmer Tato role implementuje specikované funkce podle zadání. Drºí se stanoveného harmonogramu a asových odhad. V²echny komplikace ihned hlási PM. Zodpov dnosti: Dodrºování konvencí a istoty zdrojového kódu. Znalost jazyka dané platformy. O²et ení chyb a vstup. Znalost architektury aplikace a struktury databáze. Dodrºování standardu kódování PEP-8 (Python) a com/documentation/contributing/#coding-style (Django) Dodrºení konvence pro zdrojové kódy (do záhlaví # -*- coding: utf-8 -*- a # kate: space-indent on; indent-width 4; mixedindent off; indent-mode python;. Kompetence: Odmítnutí zadání z d vod : ned slednosti i nesrozumitelnosti zadání, nereálnosti realizace. Odmítnutí zadání z d vod nedostatku kvalikace.

67 DODATEK A. PROJEKTOVÝ MANUÁL 53 Inovace technologií konzultací s týmem. Návrhy na zlep²ení architektury i díl ích e²ení aplikace. Artefakty: Funk ní ásti projektu, obsah komponent. A.1.8 SEO, SEM specialist Tato role se specializuje na optimalizaci pro vyhledáva e po technick stránce, neformuluje konkrétní klí ová slova. To je kompetencí copywritera. Zodpov dnosti: Kontrola komplexnosti zpracování SEO na projektu (titulek, nadpisy, metatagy ve v²ech stránkách). Kontrola validity v²ech stránek projektu (XHTML i CSS). Sledování pozice ve vyhledáva ích. Kompetence: Návrh na zjednodu²ení SEO z d vodu p eoptimalizace. Sledování konverzního pom ru a upozorn ní na extrémy. Sledování aktuálního d ní na poli SEO (google dance). Artefakty: Práce s dodanými klí ovými slovy. Registrace ve vyhledáva ích. Link exchange. A.1.9 Graphic designer Navrhuje grackou podoba projektu p i zohledn ní jeho charakteru. Graku navrhuje tak, aby byla vhodná pro pouºití na webu (barevnost, sloºitost). Zodpov dnosti: P i tvorb grackého designu zohledn ní zásad CSS a HTML (a následného ezaní). Zohledn ní p ístupnosti a pouºitelnosti UI (drobky, menu, psychologie navigace). Navrºení grackého zpracování v²ech druh informací v projektu (formulá e, tabulky, texty). Konzistence grackého návrhu, psychologie barev. Kompetence: Inovace v p ístupu k UI. Návrh na vyuºití speciálních technologií (AJAX, Flash...). P ipomínky ke zp sobu zobrazování projektu (rozli²ení, PDA, wap). Artefakty: Gracký design ve vrstvách srozumiteln pojmenovaných a strukturovaných. Dodate né gracké práce v pr b hu projektu (ikonky,...).

68 54 DODATEK A. PROJEKTOVÝ MANUÁL A.1.10 Copywriter Specialista na jazyk projektu (lingvista). Zohled uje v²echny obchodní a marketingové souvislosti. Zodpov dnosti: Citlivá formulace pravopisn správných text. Konzistence v pouºívaných termínech a p izp sobení sílové skupin. Ur ení správné struktury projektu tak, aby sledovala jeho cíle. Nalezení klí ových slov pro kaºdou ást projektu. Ozna ení landing pages. Kompetence: Doporu ení pro marketingovou strategii zákazníka. Doporu ení k názvosloví pouºitému v URL. Sledování aktuálních marketingových trend na internetu. Sledování vyhledávacích schopností (trend ) r zných v kových a cílových skupin. Návrh konkrétních reklamních kampaní (PPC, bannery atd.). Artefakty: Úprava templat po textové stránce. Návrh vhodných názv pro strom URL A.1.11 Template coder Tato role obhospoda uje prezenta ní vrstvu projektu, gracké návrhy p etvá í do konkrétních stránek. Zodpov dnosti: ezání a za i² ování grackých podklad. Kódování XHTML a CSS do templat. Validita kódu dle standard W3C. Cross-browser funkcionalita. Úplné zprovozn ní stromu URL ve statické form. Kompetence: Kladení poºadavk na gracké dod lávky. Inovace p ístupu k HTML a CSS kódování. Poºadování kvalitn j²ích grackých podklad (po strukturální stránce). Artefakty: Templaty projektu.

69 DODATEK A. PROJEKTOVÝ MANUÁL 55 A.1.12 Tester Testuje funk nost (formulá e, vícekrokové operace) a správné zobrazování v r zných prohlíºe- ích. Kontrola úplnosti projektu. Zodpov dnosti: Hledá chyby ve výsledné aplikaci a upozor uje na n PM. Hodnotí pouºitelnost a uºivatelskou p ív tivost aplikace. Upozor uje na stylistické, gracké a jiné nedostatky aplikace. Prozkoumává celou aplikaci na chyb jící ásti (porovnává se stomem URL). Cross-browser testing. Kompetence: Navrhuje zlep²ení UI aplikace. Vrací ást projektu k dolad ní. Artefakty: Protokol o testování. Hlá²ení bug. A.2 Fáze ºivotního cyklu vývoje Fáze ºivotního cyklu kopírují metodiku Unied Process a popisují kroky k tvorb projektu na zelené louce. Jednotlivé úkony lze vynechávat podle pot eb projektu (customizace metodiky), ale musí se denovat p edem, které to budou (nap. zákazník nechce provád t SEO). Jednotlivé fáze iterují, dokud nejsou schváleny dohlíºejícím Production coordinatorem (PC). Ten schvaluje p echod projektu do dal²í fáze. Na obrázku A.3 jsou názorn zobrazeny obsahy jednotlivých ástí. Pro kaºdou fázi jsou v n m vypsány zú astn né role, procesy a vznikající artefakty (dokumenty). A.2.1 Zahájení (inception) Role PC, PM, ANAL, COPY Artefakty vision document, konceptuální doménový model, odhad náro nosti, nabídka softwarového e²ení Shrnutí Tato fáze se zabývá p edev²ím odhadnutím náro nosti projeku. Zda je realizovatelný a za jakých, p edev²ím nan ních, podmínek. Pro pot eby této fáze byl sestaven formulá vision document nezávazná objednávka, který strukturovanou formou prochází v²echny d leºité aspekty webového projektu.

70 56 DODATEK A. PROJEKTOVÝ MANUÁL Obrázek A.3: Obsah fází ºivotního cyklu vývoje Postup PC zvolí pro projekt roli ANAL a p ípadn i PM. Ti zpracovávají celou fázi zahájení aº do bodu oponování. ANAL na první sch zce se zákazníkem vyplní formulá vision document. Identikuje p i tom jednotlivé role uºivatel, kte í budou k systému p istupovat. Zkoumá, jaké budou jejich nej ast j²í operace a v jakých ástech systému (komponentách). Po vypln ní dotazníku sestaví ANAL konceptuální doménový model, který reprezentujeme UML Class diagramem. Názvy t íd jsou vybírány tak, aby byly co nejlépe srozumitelné pro zákazníka. To proto, abychom mohli nad modelem diskutovat. Tato diskuze je nezbytná pro sjednocení projektového slovníku, tedy pouºívaných výraz p i komunikaci zákazníka a vývojového týmu (zastupovaného p eváºn ANAL). Atribut m nep i azujeme datové typy. Cílem je identikovat v²echny vazby, které se v modelu mohou vyskytnout. Dále ANAL po konzultaci s COPY sestaví seznam komponent, ze kterých by se m l systém skládat. Komponenty tvo íme ze skupin poºadovaných funkcí, které pracují se stejnou podmnoºinou entit doménového modelu. Rozvrºení komponent m ºe být ilustrováno pomocí UML balí k nebo diagramu komponent.

71 DODATEK A. PROJEKTOVÝ MANUÁL 57 Ze seznamu komponent utvo í PM odhad náro nosti projektu tak, ºe kaºdou ohodnotí po tem lov kohodin p i ideálním pr b hu zpracování (kaºdá komponenta projde fází analýzy, návrhu, realizace a testování). P i realizaci pamatujeme na lámání stránek a implementaci funkcí. Nesmíme také zapomenout na r zné jazykové verze. Snaºíme se odhad minimalizovat, nikoliv v²ak podhodnocováním, ale pouºitím znovupouºitelných e²ení. Do odhadu dále p idáme odhad náro nosti: grackého návrhu, není-li zpracováván extern komunika ních a organiza ních prvk realizace zohled ující po et subdodavatel (nap. dodání grackého designu) testování a lad ní systému, s ohledem na poºadavky na kompatibilitu v prohlíºe ích s p ihlédnutím ke komplikovanosti pouºitých technologií (Java, Flash, JavaScript atd.) nasazení na produk ní server, kdy zohled ujeme po et a vztah domén, na kterých má b ºet za²kolení do ovládání aplikace, p ípadné zpracování uºivatelského manuálu migraci nebo napln ní dat, pokud to projekt vyºaduje Celý odhad násobíme rizikem, které je dáno zku²eností worker vybraných do týmu (reps. t ch kte í p ipadají v úvahu), tlakem ostatních projekt, poºadavkem na pevný termín dokon ení a po tem jazykových variant v p ípad internacionalizovaných projekt. Riziko se b ºn pohybuje v rozmezí 1,2 aº 1,8. Následuje fáze oponování odhadu. Zku²en j²í, nezainteresovaný vývojá ( asto sám PC) se seznámí s projektem a snaºí se napadnout jeho odhad (hledá zapomenutá rizika). V p ípad zji²t ných nedostatk se fáze zahájení opakuje od za átku (bez vision documentu). PC dává projekt do sovislosti se zdroji (p edev²ím presonálními), které má k dispozici, aby mohl zaru it realizaci projektu ze strany dodavatele. Také m ºe na ídit prototypové nebo re²er²ní zpracování n kterých klí ových ástí, aby ov ril technologickou proveditelnost. Výsledná hodnota odhadu v lov kohodinách je postoupena k diskuzi obchodnímu odd lení, které ur í hodinovou sazbu, p ípadn dal²í obchodní sloºky vztahu. Nakonec PM zpracuje odhad do závazné nabídky softwarového e²ení s konkrétní výslednou sumou a p edá ji zákazníkovi ke schválení. Zákazník je zárove upozorn n na rizika spojená s neodhalenými poºadavky a jejich vlivem na výslednou cenu. Praxe ukázala, ºe se p vodní odhadnutá cena li²í od výsledné aº o 20%. U v t²ích projekt m ºe být smluvn dohodnuto samostatné zpracování detailní analýzy a návrhu. V takovém p ípad ANAL zpracuje odhad bez zapo ítání konstruk ní a nasazovací fáze (p edev²ím realizace a testování). Po schválení projektu zákazníkem je sepsána p íslu²ná smouva (viz. manuál obchodnícho odd lení), je zaloºen Subversion repozitá projektu (viz. manuál IT odd lení) a je na vývojovém serveru zprovozn no spou²t cí prost edí (DB, hosting, maily, Django enviroment, viz. taktéº manuál IT odd lení). Checklist Byly p i odhadu zohledn ny v²echna rizika (funkce a technologie, se kterými nejsou zku- ²enosti)?

72 58 DODATEK A. PROJEKTOVÝ MANUÁL Byla p i odhadu zohledn na minulá zku²enost se zákazníkem? Byly p i odhadu zohledn ny prvky, které jsme nikdy neimplementovali? Byly informace podané zákazníkem dosta ující (byl doménový expert dostate n kompetentní)? Byla p i rozvrºení komponent zohledn na marketingová rovina? Sledují v²echny poºadované funkce stanovené cíle? Byly p i azeny role pro fázi rozpracování? A.2.2 Rozpracování (elaboration) Role ANAL, PM, HP, GPHX, COPY, TPL, DB SPEC, APP DES Artefakty Graka screenshoty, datový model, struktura a scéná e, spustitelný základ systému, harmonogram realizace v dp Shrnutí V této fázi provádíme detailní analýzu a návrh systému po komponentách (Django aplikacích), postupujeme metodou zhora dol. Je vytvo en gracký návrh aplikace. Shromaº ujeme v²echny relevantní materiály (texty, obrázky, forograe, letáky, ceníky,...), které budou mít vliv na výsledný obsah prezentace. Postup ANAL za ne sestavením stromu URL (site map). Pro kaºdou komponentu zvolí název Django applikace (dle COPY a HP). To bude první ást URL. Pak odd lujeme jednotlivé funkce klí ovými slovy, prom nné uzavíráme do ²pi atých závorek, nap. /knihovna/fotogalerie/<gallery_slug>/. P ípadn m ºe být pouºit zápis pomocí regulárních výraz, který usnadní realizaci v Djangu, nap. ^/knihovna/fotogalerie/(?p<gallery_slug>[\w\d-]+)/$. U vícejazy ných projektu p ed adíme ISO zkratku jazyka, pokud se z d vodu SEO uvaºuje o jazykov závislých URL, nap. /cs/knihovna/clanky/<article_slug>/.

73 DODATEK A. PROJEKTOVÝ MANUÁL 59 V p ípad, ºe se struktura stránek v jednotlivých jazycích li²í, vytvo íme pro kaºdý jazyk samostatný strom. Je-li to vhodné, m ºeme pouºít pro popis rozdíl ve struktu e binární matici. Poloºky stromu o íslujeme te kovou notací (nap ). Pokud budeme pozd ji do stromu zasahovat, nebudeme ísla restrukturalizovat, ale pouºijeme nová. Strom uchováváme v textovém souboru v repozitá i projektu. Kaºdé roli v systému p i adíme písmeno. Pro lep²í zapamatování pouºijeme první písmeno z názvu role (nap. A pro administrátora, G pro hosta guest = anonymní náv²t vník). Do stromu p ipí²eme písmena tam, kde se bude obsah stránek li²it podle role (nap. B 4.7 a C 4.7). Jestliºe bude na dané URL povolen p ístup jen n kterým rolím, ale obsah stránky bude stejný, napí²eme do íselného kódu více písmen za sebou (nap. ACDE 2.5.3). Toto kodové ozna ení budeme pouºívat p i komunikaci uvnit týmu. Datový model reprezentuje ANAL jako UML Class diagram v oblíbeném CASE nástroji. Sloºit j²í modely e²í ANAL a DB SPEC spole n. Prvotní návrh kon í, kdyº jsou popsány v²echny principiální entity a jejich atributy v etn datových typ. Detailní specikaci systému vytvo í APP DES a ANAL v textovém procesoru. Bude ji tvo it popis jednotlivých ástí systému po jednotlivých stránkách (kódech). Kaºdé stránce (kódu) p i adíme pracovní název, nap. detail knihy. Popis stránky je koncipován jako povídání o tom, co je moºné na stránce vid t, jak je to strukturované, na co se dá kliknout, jaké se dají odeslat formulá e a do kterých stránek vedou odkazy. Nepovinn m ºe být p ipojen ná rtek UI, nebo WebML composition model. V rámci WebML composition modelu jsou denovány unity zobrazené na obr. A.4. Tzv. lízátko u n kterých element znázor uje vazbu na databázovou vrstvu. V²echny vlastnosti se pí²ou v textové form pod p íslu²né elementy. Nezávisle na analýze a návrhu probíhá návrh grackého designu. GPHX prostuduje vision document a sejde se se zákazníkem, aby se lépe ztotoºnil se zám rem projektu. Konzultuje s ním výb r barevnosti (v souladu s Corporate Identity zákazníka), nashromáºdí dostupné marketingové materiály, loga a typogracké podklady. Zákazník si z návrh GPHX vybere ten, který se bude realizovat. GPHX vytvo í screenshoty (layout stránky nej ast ji se vyskytující ve stromu URL). APP DES vytvo í wireframe návrhy pro jednotlivé typy stránek a konzultuje je s ANAL a zákazníkem. Po schválení wirefram GPHX nakreslí typové screenshoty. Nakonec se e²í vizuální podoba homepage, protoºe nemusí dodrºovat stabilitu ovládacích prvk tak, jako ostatní stránky. Do prázdného vývojového prost edí vytvo í HP v²echny komponenty a vloºí strukturu URL podle stromu. Pro kaºdou stránku vytvo í TPL statické templaty obsahující identika ní kód stránky. P ípadn m ºe být do templatu zkopírována celá specikace dané URL. TPL pracuje na lámání graky. P i tom restrukturalizuje statické templaty tak, aby se kód neopakoval (pouºívá d di nost a include). Kódují se pouze ásti spole né pro více stránek (záhlaví, menu apod.), nikoliv konkrétní obsahy. Kaºdou komponentu dopl í HP o DB strukturu (models.py) podle datového modelu navrºeného DB SPEC. Vypl í p i tom i hodnoty verbose_name, verbose_name_plural a help_text, aby bylo p ístupn j²í vygenerované administra ní rozhraní. Konkrétní názvy vybírá s ANAL, aby reektovaly názvosloví pouºívané zákazníkem. ANAL denuje mnoºinu testovacích dat nejlépe tak, aby obsahovala v²echny extrémní hodnoty. Testovací data se vºdy snaºíme vytvá et tak, aby se co nejvíce podobala skute ným, ºádné asdfasdf! Pro dluhé texty je vhodné pouºít lorem ipsum generátory. Testovací data jsou se-

74 60 DODATEK A. PROJEKTOVÝ MANUÁL rializována ve formátu JSON a jsou uloºena v initial_data.json u kaºdé komponenty. P i zm nách datového modelu m níme sou asn i testovací data tak, abychom mohli bezpe n synchronizovat models.py s databází. Tato fáze kon í spustitelným základem systému, který je ve nálních barvách a který je schválen zákazníkem. Má-li zákazník poºadavky, které znamenají zm nu ve stromu URL, musí být zapracovány d ív, neº se p ejde do dal²í fáze. Tento základ systému budeme nazývat prototyp. U v t²ích projekt vytvo í PM a ANAL odhad pro konstruk ní fázi. Ty musí následn schválit PC (analogicky k odhadu ve fázi zahájení). Jako základní seznam pro odhad pouºijeme vzniklý strom URL. Po schválení je sepsána p íslu²ná smouva (viz. manuál obchodnícho odd lení). Checklist Spl uje gracký návrh v²echny náleºitosti (typograe, zarovnání na m íºku, vertikální rytmus,...)? Obsahuje gracký návrh v²echny pouºívané elementy (formulá e, tla ítka, aktivní poloºku menu, odkazy link, hover, visited atd.)? Bylo provedeno teoretické testování datového modelu na extrémní hodnoty v datech? Byly ve specikaci zmín ny obecn platné principy (podoba datumu,...)? Jsou ve specikaci uvedeny stránky s automatickým p esm rováním (nastavení jazyka apod.)? Jsou ve specikaci uvedeny hlá²ení uºivateli, nap. úsp ch/neúsp ch p i odesílání formulá e? Jsou ve specikaci stránek uvedeny stránkování, azení, ltrování a hromadné manipulace s daty? Jsou ve specikaci stránek zmín ny znovupouºitelné komponenty (LightBox, Google Maps, JQuery apod.)? Byl prototyp d kladn p edstaven zákazníkovi? M ºe zákazník dodat je²t n jaké materiály popisující budoucí data v systému? Byly p i azeny role pro fázi konstrukce? A.2.3 Konstrukce (construction) Role PM, HP, ANAL, PRG, TPL, TST, GPHX, APP DES Artefakty dokon ené komponenty, change requesty

75 DODATEK A. PROJEKTOVÝ MANUÁL 61 Shrnutí Cílem této fáze je postupná realizace jednotlivých komponent metodou ²í ení olejové skvrny. Jde o asov nejnáro n j²í fázi protoºe se objevují neodhalené závislosti a poºadavky. Kaºdou vytvo enou ást je také t eba testovat. Popsaný postup zahrnuje vytvo ení jedné komponenty, je tedy t eba iterovat pro kaºdou komponentu zvlá². Postup HP ídí implementaci komponent od nejd leºit j²ích po nejmn významné. K dispozici má PRG, TPL a p ípadn GPHX. Konkrétní podoba UI je konzultována s APP DES. HP vyv sí na viditelné místo datový model tak, aby se dalo lépe diskutovat a p emý²let nad problémy. Zadání implementace kaºdé komponenty potvrdí ANAL a APP DES. Ozna í ásti stromu URL, které se budou v dané iteraci implementovat a zkontrolují, ºe jsou ve specikaci zahrnuty v²echny dosud známé poºadavky. Po implementaci souvislé sady funkcí systému (celé komponenty) je výsledek zkontrolován a otestován HP (white-box, alfa testing) a následn p edstaven zákazníkovi. Ten m ºe vznést up es ující poºadavky. Je na PM, aby zhodnotil, zda bude vydán Change request, tedy zm na v zadání i rozpo tu, nebo zda bude zm na povaºována pouze za konguraci e²ení. P i objevení nedostatk (bug ) jsou podle závaºnosti e²eny hned (slovním zadáním), nebo jsou sepsány do Bug reportu a st ádány. Nast ádané bugy se e²í najednou, aby se u²et ila práce s testováním. Po implementaci a schválení v²ech komponent zákazníkem konsoliduje PM a PC nashromáºd né Change requesty. Po dohod se zákazníkem se bu zm ní rozpo et projektu a jsou zm ny provedeny ihned, nebo se ádn zdokumentují (formulá ) a odloºí na pozd j²í dobu (nový obchodní kontrakt). Checklist Byly dodrºeny zásady správného psaní zdrojového kódu (struktura, komentá e,...)? Byly dodrºeny zásady správného psaní webových stránek (zobrazení bez styl, bez obrázk,...)? Bylo spln no zadání dané specikací? Byly dodány v²echny pot ebné jazykové p eklady? Bylo provedeno základní testování v r zných prohlíºe ích? Byly testovány v²echny formulá e na extrémní hodnoty vstup? Byl zákazník d kladn seznámen se v²emi ástmi systému? Byly p i azeny role pro fázi nasazení? A.2.4 Nasazení (transition) Role PM, HP, COPY, TPL, SEO, TST

76 62 DODATEK A. PROJEKTOVÝ MANUÁL Artefakty protokol o testování, p edávací protokol Shrnutí Cílem nasazení je zprovozn ní systému na produk ním serveru a jeho otestování skute nými uºivateli. Systém se plní skute nými daty a provádí se integrace s b ºícími systémy v etn SEO a dal²ích marketingových operací. Postup PM poºádá IT odd lení o vytvo ení produk ního spou²t cího prost edí. HP m ºe dodat up es- ující poºadavky (DB, hosting, kvóty, Django verze atd., viz. manuál IT odd lení). PM zajistí pot ebné údaje k editaci DNS a p edá je spole n s poºadavky na ové ú ty IT odd lení. HP na produk ním serveru zajistí p enesení zdrojových kód, nastavení lokální kongurace (settings_local.py, hesla do administrace,...), migraci ostrých dat a kontrolu funkce znovupouºitých komponent v produk ním prost edí. PM zkontrokuje, ºe byla v²echna pouºitá hesla zanesena do KeePassu a ºe je správn zaevidován hosting v etn faktura ních údaj. SEO a COPY zajistí podle pot eby provedení marketingových úprav v projektu. Následující popis je postup úplné optimalizace. Zákazník dodá klí ových slov (deset nejd leºit j²ích a 50 zbylých). Ty jsou revidovány COPY a SEO zhodnotí jejich konkurenceschopnost (keyword analysis, keyword rank tracking). SEO komplexn zkontroluje validitu stránek. COPY ur í landing pages a denuje konkrétní keywords, description a titulky pro klí ové stránky. SEO vyhodnotí pagerank jednotlivých stránek (onpage, opage faktory). COPY zajistí registraci do vyhledáva a p ípadný link exchange. V pr b hu lad ní optimalizací pro vyhledáva e probíhá beta testování (blackbox zp sobem). Toto testování provádí TST (zku²ený vývojá ), který se nepodílel na vývoji projektu (m ºe být PC v rámci QA). Testují se extrémní hodnoty vstup, úplnost a konzistence projektu. Na míst je také testování skute nými uºivateli. Zji²t né nedostatky se zaznamenávají do Change request /Bug report. Jednodu²²í bugy opravuje HP na míst. TST vypl uje protokol o testování. Po dokon ení testování je provedena nální prezentace zákazníkovi, kdy je pou en o bezpe nostních rizicích, moºných formách zneuºití, ovládání administrace systému, zásadách pro udrºení produktu a moºnostech budoucího roz²í ení funk nosti. Také je seznámen s rozsahem poskytovaných hostingových sluºeb (kvóta, zálohování,...). Následn je sepsán p edávací protokol. Nakonec HP zajistí vypnutí debug módu a nastavení administrátorských (pro automatický p íjem chyb). PC po dohod s PM dá pokyn obchodnímu odd lení pro vystavení fakturace. Checklist Byla komplexn zkontrolována validita XHTML a CSS? Byl v poºadovaném rozsahu vypln n protokol o testování? Jsou ádn zdokumentovány poºadavky, kterým nebylo vyhov no?

77 DODATEK A. PROJEKTOVÝ MANUÁL 63 Je správn zaloºený a zaevidovaný hosting (kvóty, y, faktura ní údaje)? Byly ádn zdokumentovány hesla pouºitá v projektu (FTP, SSH, DB, maily, administrace,...)? Byl vypnut debug reºim a nastaveny y pro automatické odesílání chyb? Byly provedeny v²echny úkony související se SEO (statistiky, vyhledáva e, keywords apod.)? Bylo provedeno pozorování systému ve skute ném provozu? Podepsal zákazník p edávací protokol? Byla zákazníkovi odeslána faktura? Ví zákazník, na koho se má obrátit v p ípad pot eby?

78 64 DODATEK A. PROJEKTOVÝ MANUÁL Obrázek A.4: WebML unity

79 DODATEK B. VISION DOCUMENT FORMULÁ 65 B Vision document formulá Datum Zpracoval Název projektu Zadavatel Kontakt Ú el projektu Za jakým ú elem projekt vzniká? Komu (cílová skupina) a jak bude slouºit (pouze základní guideline)? Charakter projektu Co budou hlavní ásti? Co bude v hlavním menu? Jaké dal²í nabídky (menu) lze rozli- ²it. Mapa webu. Jaké ásti bude projekt mít (front-end, back-end,...) Co má být administrovatelné p es back-end? statické texty poloºky (hlavní atributy) galerie interaktivní obsah bannerový systém p ihá²ení role v systému Návrh homepage a klí ových obrazovek je na konci tohoto dokumentu, p íslu²né odpovídající ásti ozna te íslem v krouºku. Pouºité domény Na jakých doménách projekt pob ºí (modikace)? Jsou domény registrované? Kdo administruje DNS (login)? Alternativy Jaká e²ení p ipadají v úvahu?

80 66 DODATEK B. VISION DOCUMENT FORMULÁ Obsah webové prezentace Design stránek Jaké jsou poºadavky na design webu (barevnost, téma, nálada)? Jaké jsou existující prezenta ní materiály, ze kterých se dá vycházet (letáky, vizitky, stávající web)? P ípadé ID designu na Template Monster? Jaké jsou poºadavky na lámání stránek (externisté)? Jaké mají být moºnosti úprav (zm na barevnosti, layoutu, Váno ní/velikono ní tématika)? Jazykové varianty Kolik a jakých? Jaká je pravd podobnost, ºe p ibudou? Kdo dodá p eklady (kontakty, termíny)? Marketingové informace Logo, záhlaví corporate identity, cké manuály logo, gra- Textový obsah Kdo ho kdy p ipraví, jakou bude mít podobu? Kolik se dá o ekávat zm n? Obrazový materiál Fotograe a ilustrace, které se neadministrují a jsou sou ástí grackého designu. Kdo je kdy dodá? SEO registrace ve vyhledáva ích

81 DODATEK B. VISION DOCUMENT FORMULÁ 67 Administrativní informace Zodpov dné osoby hesla do mail, heslo k FTP, heslo k DNS, zp sob p edání hesel Hosting Existuje nebo se musí zaloºit? Kolik mailových schránek se bude vytvá et? (p esm rování, doménový ko², aliasy, nastavení SPAM ltru) Vyºaduje zákazník p ístup p es SSH/FTP? Statistiky? Osobní údaje Ochrana osobních údaj : které informace je t eba chránit. Kdo a kdy zajistí p ístup k dat m pro testovací ú ely. NDA Cena cht ná cenová hladina p edpokládaná cenová relace Ostatní poznámky + návrhy obrazovek

82 68 DODATEK B. VISION DOCUMENT FORMULÁ

83 DODATEK C. CHANGE REQUEST / BUG REPORT FORMULÁ 69 C Change request / Bug report formulá Hlá²ení: Projektu Datum Charakter: Bug* / Change request* URL související ásti stromu URL Autor Replikovatelný: ANO* / NE* Prohlíºe all, IE, FF apod. Jazyková vatianta all, cs, en apod. Ostatní jiné, globáln nastavené hodnoty Popis Podrobný popis, kód chyby (404, 403, 500), název Exception, copy & paste chybového hlá²ení, hodnoty ve vypl- ovaném formulá i, akce vyvolávající request apod. Navrhované zm ny, wireframe, p ípadn screenshot. Potvrzení: Datum Potvrdil Ovlivn né komponenty Bug* / Change request* Odhadovaná náro nost lov kohodiny * nehodící se ²krtn te

84 70 DODATEK C. CHANGE REQUEST / BUG REPORT FORMULÁ

85 DODATEK D. PROTOKOL O TESTOVÁNÍ FORMULÁ 71 D Protokol o testování formulá Do jednotlivých polí se vpisuje íslo verze (revize ze Subversion), jméno testera a datum. PM m ºe ur í p esný harmonogram testování (kdy, který prohlíºe ). název komponenty (Django app) FireFox 2 FireFox 3 IE 6 IE 7 IE 8 Safari Opera

86 72 DODATEK D. PROTOKOL O TESTOVÁNÍ FORMULÁ

87 DODATEK E. UKÁZKA POUšITÍ METODIKY 73 E Ukázka pouºití metodiky V této kapitole ukáºeme pouºití popsané metodiky p i e²ení malého, reálného projektu. Oslovil nás zákazník, který si p ál zpracovat web pro své hudební vydavatelství (dále jen zákazník). Role Na projektu ve výsledku pracovali t i lidé, ozna me je A, B a C. Role jim byly rozd leny následujícím zp sobem: A~- ANAL, PM, HP, PRG, TPL, DB SPEC, TST B - TPL, TST C - GPHX, COPY, SEO, APP DES Postup vývoje Zahájení Projektové odd lení bylo obchodním odd lením pov eno zpracováním nabídky softwarového e- ²ení. PC ur il role PM, ANAL a COPY pro tento projekt. ANAL na první sch zce se zákazníkem sestavil vision document. Z vision documentu vyplynulo, ºe se jedná o men²í projekt. PC ur il role PM, HP a COPY. Z p id lení rolí vidíme, ºe byl za celou realizaci zodpov dný jeden lov k A. A provedl dekompozici projektu a strukturu konzultoval s C. A provedl odhad náro nosti a dal ho k posouzení PM. Ten ho po malé korekci schválil a nechal A vypracovat nabídku softwarového e²ení s konkrétní sumou (konzultováno s obchodním odd lením). Rozpracování PC ur il role HP, GPHX, TPL, DB SPEC a APP DES. Vyuºil v co nejv t²í mí e A a C. P edcházel tím sniºování efektivity v d sledku zvý²ení komunikace mezi leny týmu. C vypracoval po sch zce se zákazníkem gracký návrh. Zákazník po zapracování p ipomínek návrh schválil. A vytvá il spustitelný architektonický základ. C soub ºn vytvá el statickou podobu stránek dle grackého návrhu. Specikace jednotlivých stránek byla s ohledem na velikost projektu omezena na krátký textový popis. Spustitelný architektonický základ nebyl zaznamenán, na p iloºeném CD jsou v²ak k dispozici stránky ve statické form (tzn. ist HTML a CSS, bez skript ). A sjednotil spustitelný architektonický základ se statickou podobou stránek a vytvo il tak prototyp. Ten obsahoval i automaticky generovanou administraci dat (vlastnost frameworku Django). Nad prototypem doladil A výslednou podobu jednotlivých komponent se zákazníkem. Konstrukce PC p i adil roli TST jiº vyuºitým pracovník m ze stejného d vodu, který je uveden vý²e.

88 74 DODATEK E. UKÁZKA POUšITÍ METODIKY A postupn implementoval a testoval v²echny komponenty. B provedl kontrolu a opravy validity kódu. Projekt byl pr b ºn nahráván na produk ní server, aby k n mu m l zákazník pohodln j²í p ístup. To bylo moºné uskute nit, protoºe projekt nepouºíval experimentální technologie, které by mohly server shodit a protoºe doména ur ená pro projekt byla v provozu, ale nebyla vyuºívána. Formulá pro bugxy a change requesty nebyl pouºit, protoºe se tyto zm ny e²ily se zákazníkem operativn. Ve výsledku se jednalo o úpravy v rozsahu 4 lov kohodin). Výsledné zdrojové kódy jsou p iloºeny na CD. Nasazení Zákazníkem byly migrovány star²í data pomocí p ipravené administrace (back-endu). Její pou- ºívání odhalilo n které skryté chyby. Ty byly zákazníkem hlá²eny formou u p ímo A. Po opravení chyb byl zákazníkem podepsán p edávací protokol. Servisní smlouva byla uzav ena pouze v rozsahu poskytování hostingových sluºeb. Projekt je moºné nav²tívit na webových stránkách Vyhodnocení Cena projektu, navrºená obchodním odd lením zaloºená na odhadu náro nosti, nebyla zákazníkem akceptovatelná. Nakonec bylo, s ohledem na charakter projektu, zvoleno kompromisní e²ení se sníºenou sazbou. T i m síce po podpisu p edávacího protokolu m ºeme bilancovat reálnou zát º rmy. Kone ná náro nost byla vypo tena na 46 lov kohodin. Vidíme, ºe provedený odhad byl vy²²í a ohrozil tím p ijetí nabídky. Od vodnujeme to p edev²ím velkou ochotou zákazníka intenzivn spolupracovat. 17% odchylka je v²ak s ohledem na velikost projektu uspokojivá. K seznamu uvedených artefakt dodejme, ºe: Logo, graka a dal²í níºe uvedené informace mohou být pod ochrannou známkou Amplión records, s.r.o. nebo jiných subjekt. Konceptuální datový model je sou ástí vision documentu. Nabídka softwarového e²ení a ostatní ásti zmi ující nance nejsou p iloºeny z d vodu uchování obchodního tajemství. Stejn tak p edávací protokol. Rozmazané údaje ve vision documentu podléhají ochran osobních údaj dle zákona. 101/2000 Sb., o ochran osobních údaj, v platném zn ní. ƒásti stránek jsou zám rn vynechávány tak, aby byly podkapitoly soudrºn j²í. Musíme zde je²t zd raznit, ºe neformální podoba, kterou má p edev²ím vision document, je reálným projevem agilního p ístupu v praxi. Konkrétn máme na mysli pasẠo podob a ú elu dokumentace (viz. kapitola 4.1.6).

89 DODATEK E. UKÁZKA POU ITÍ METODIKY Obrázek E.1: Vypln ný dotazník vision document strana 1. 75