Analýza vztahu mezi zákazníkem a dodavatelem při vývoji SW

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Analýza vztahu mezi zákazníkem a dodavatelem při vývoji SW Diplomová práce

Autor:

Bc. Jiří Jirásek Informační technologie, manaţer projektů informačních systémů

Vedoucí práce:

Ing. Alena Buchalcevová, Ph. D

Odborný konzultant:

Mgr. Pavel Veselík

Praha

březen, 2009

Poděkování: Chtěl bych touto cestou poděkovat Ing. Aleně Buchalcevové, Ph. D. za pomoc, trpělivost a rady které mi poskytla při vedení této diplomové práce. Mgr. Pavlovi Veselíkovi za poskytnuté konzultace a materiály. Mgr. Tomaši Zívrovi, Bc. Evě Matoušové za názory a korekturu potřebné pro dokončení této práce. Děkuji také rodičům, kteří pro mne byli důleţitou oporou v období studia, přípravy a tvorby práce.

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a s pouţitím uvedené literatury.

V Praze dne 10. března 2009

Bc. Jiří Jirásek

Anotace Zajištění všech potřebných úkonů pro výběr správného dodavatele ze strany zákazníka, dokončení softwaru dle představ zákazníka a splnění všech závazků ze strany dodavatele můţe být někdy velmi zdlouhavá a strastiplná cesta. Tato diplomová práce se zaměřuje na vztahy mezi zákazníky a dodavateli při vývoji softwaru tradičními a agilními metodikami a rozdíly mezi nimi. V případové studii a jejím vyhodnocení jsou jednotlivé přístupy k vývoji softwaru a vztahy mezi zákazníky a dodavateli porovnány. Jako příklad jsem uvedl projekt, kde se pokusím rozkrýt nedostatky v těchto vztazích.

Annotation The Arrangement of all the required act of choosing the right suppliers on the part of the customers, finishing software according to the customer and the fulfillment of all obligations by the supplier can sometimes be very lengthy and laborious journey. This thesis Diploma work focuses on the relationship between customers and suppliers in the process of software development with traditional and agile methods and the differences between them. There are compared and evaluated the different approaches to software development and the relationship between customers and suppliers in the case study. As an example I have drawn up a project where I try to uncover shortcomings in those relations.

Obsah Úvod ...................................................................................................................................... 6 1.

Software, zákazníci a dodavatelé................................................................................... 8

1.1

Software ................................................................................................................. 8

1.1.1 1.1.2 1.1.3 1.1.4 1.2

Dělení programového vybavení......................................................................... 8 Software ve vztahu k zákazníkovi ................................................................... 12 Softwarové licence .......................................................................................... 15 Informační systémy - IS .................................................................................. 19 Zákazníci ............................................................................................................. 22

1.3

Dodavatelé ........................................................................................................... 24

2. 2.1

Vztahy mezi zákazníkem a dodavatelem při vývoji tradičními metodikami .............. 26 Tradiční metodiky ............................................................................................... 26

2.1.1 Vodopádový model ......................................................................................... 26 2.1.2 Spirálový model............................................................................................... 28 2.1.3 RUP (Rational Unified Process) ...................................................................... 30 3. Vztahy mezi zákazníkem a dodavatelem při vývoji agilními metodikami ................. 48 3.1

Agilní metodiky ................................................................................................... 48

3.2

Manifest agilního programování ......................................................................... 52

3.3

XP Extrémní programování ................................................................................. 52

4.

Případová studie .......................................................................................................... 61

4.1

Projekt CIS .......................................................................................................... 61

4.2

Výběr dodavatele. ................................................................................................ 63

4.3

První fáze ............................................................................................................. 64

4.4

Druhá fáze ........................................................................................................... 66

4.5

Třetí fáze .............................................................................................................. 67

4.6

Čtvrtá fáze ........................................................................................................... 70

5.

Vyhodnocení a doporučení .......................................................................................... 71

5.1

Čas ....................................................................................................................... 71

5.2

Aktivita zákazníka ............................................................................................... 72

Závěr .................................................................................................................................... 75 Pouţitá literatura .................................................................................................................. 77 Seznam obrázků................................................................................................................... 80 Seznam tabulek .................................................................................................................... 81 Seznam zkratek .................................................................................................................... 81

Úvod Počítače a software se společně vyvíjejí od vzniku výpočetní techniky. Počítače by byly bez softwaru, ať uţ je to BIOS1 nebo sloţité informační systémy jako jsou např. CRM2, SAP3 atp., pouze mnoţstvím logicky uspořádaných součástek. Vývoj softwaru je procedura obsahující mnoho úkonů. Vývoj by se měl řídit doporučovanými metodikami a postupy, které se od doby, kdy vznikaly první programy, mění. Tyto postupy a činnosti při vývoji zákazník, pokud poţaduje zakázkový software, není povinen znát a většinou je skutečně nezná. Mohou proto mezi ním a dodavatelem vznikat nedorozumění a rozpory, ať uţ je to při samotném plánování softwaru, plnění projektu nebo údrţbě budoucího produktu. V diplomové práci se zaměřuji na vztahy mezi zákazníky a dodavateli při vývoji softwaru. Pro jeho vývoj se pouţívají různé přístupy, které mohou zahrnovat jak skupiny metodik, tak i přístupy, u nichţ se ţádné metodiky nepouţívají. Všechny způsoby vývoje softwaru přistupují k vývoji odlišným způsobem a tudíţ i k poţadavkům na zákazníka a dodavatele. Zvolil jsem si téma analýzy vztahu mezi zákazníkem a dodavatelem při vývoji softwaru, protoţe se pohybuji v prostředí, ve kterém je software jak vyvíjen, tak nakupován. Mám tedy zkušenosti, jak ze strany zákazníka tak dodavatele. Jako vývojář a dodavatel mám převáţně negativní zkušenosti především se zákazníky, kteří si nedokáţí představit úsilí vývojářů při neustále narůstajících a měnících se poţadavcích, jeţ jsou zákazníci schopni během vývoje softwaru poţadovat. Cílem mé diplomové práce je analyzovat a porovnat vztahy zákazníků a dodavatelů v průběhu vývoje softwaru a pomoci čtenáři vyvarovat se případných chyb jak ve výběru způsobu vývoje, tak chyb vznikajícím v různých fázích vývoje. Fakta, která v diplomové práci uvádím, mimo jiné umoţní čtenáři vytvořit si představu o softwaru, s nímţ se můţe setkat při nákupu a především softwaru, jehoţ vývoj je realizován na zakázku. Realizace softwarového projektu, který zahrnuje různé přístupy k vývoji, nabízí zákazníkovi několik

1

BIOS, Basic Input-Output System - definuje základní vstupně-výstupní funkce pro počítače IBM PC kompatibilní a představuje firmware osobních počítačů. Programový kód BIOSu je uloţen na základní desce počítače v paměti ROM, EEPROM nebo flash a je moţné jej aktualizovat. 2 CRM, Customer relationship management - řízení vztahů se zákazníky. 3 SAP, Systems Applications Products in data processing - se řadí mezi jednu z největších softwarových společností na světě a v oblasti databází.

6

moţností, jak se takového projektu účastnit. Nejsou to ze strany zákazníka jen moţnosti, ale také povinnosti, které by měl během vývoje dodrţovat, aby jeho software po skončení vývoje zcela naplnil jeho očekávání a odpovídal původním představám. Dodavatelé pro naplnění představ zákazníka postupují při vývoji různými způsoby, které porovnávám a hodnotím v případové studii. Přínosem diplomové práce je pomoc čtenáři vytvořit si na základě vyhodnocení představu, jak jednotlivé způsoby vývoje a komunikace mezi zákazníkem a dodavatelem ovlivňují tvorbu softwaru.

7

1.

Software, zákazníci a dodavatelé

V této kapitole popisuji software jako takový, jak se rozděluje a jaké má v daném rozdělení vlastnosti, co pro zákazníka a dodavatele toto rozdělení znamená. Následně se zaměřuji na software dle moţnosti pořízení a popisuji typy licencí softwaru, které jsou pro zákazníka právně zavazující a vyplývají z nich případná omezení. Jako poslední zde uvádím několik informačních systémů, které se skládají ze softwarových a někdy také hardwarových komponent.

1.1 Software Nehmotnou stránku výpočetního systému lze označit jako software. Zjednodušeně jde o sled příkazů, které počítač vykoná, aby provedl uţivatelem poţadovanou činnost. Příkazy jsou v takové formě, které počítač rozumí. Základní teorie většiny moderního softwaru byla poprvé představena Alanem Turingem4 v eseji „Computable numbers with an application to the Entscheidungsproblem― jiţ v roce 1935 (1). Součástí moderní společnosti je software více neţ 50 let. Jak se uvádí na stránkách Martina Fowlera5 (2), začal vývoj softwaru jako chaotická činnost často uváděna pod výrazem "programovat a opravovat". Software vyvíjený tímto způsobem byl napsán bez promyšleného plánu a návrh systému byl stanoven většinou na základě okamţité potřeby. Výše uvedené způsoby fungovaly pro malé systémy, ale jak časem rostla sloţitost systémů, bylo obtíţnější přidávat nové funkce a bylo těţší určit chyby. Styl vývoje uvedený Martinem Fowlerem byl pouţíván po mnoho let, neţ byla zavedena první metodika. Metodiky navozují disciplinovaný postup při vývoji softwaru s cílem dosáhnout vývoje předvídatelněji a efektivněji.

1.1.1 Dělení programového vybavení Software neboli programové vybavení se dělí do tří základních skupin (3). Programy systémové, programy pro podporu vývoje a programy aplikační.

4

Alan Mathison Turing (23. červen 1912 – 7. červen 1954) byl významný britský matematik, logik, kryptograf a zakladatel moderní informatiky. 5 Martin Fowler je programátor a autor knih o programování, ţijící v USA. Zavedl termín refaktorování, propaguje téţ UML a návrhové vzory.

8

Programy systémové Programy systémové řídí, umoţňují či usnadňují vlastní chod a správu počítače. Jsou zcela nepostradatelné pro činnost počítače a musí být na počítači nainstalovány. Patří mezi ně především: a) operační systémy – základní soubor programů, které zajišťují správnou činnost a spolupráci jednotlivých součástí počítače a jejich vyuţití pro všechny programy a pro komunikaci mezi uţivatelem a počítačem. Jednou z hlavních funkcí operačního systému je zbavit programátora potřeby znát podstatu hardwaru a nabídnout mu sadu základních funkcí v podobě aplikačního rozhraní, které můţe ve svých programech vyuţívat do jisté míry standardizovaným způsobem. (např. Microsoft Windows, Linux apod.), b) systémové utility – programy, které se zaměřují na úpravu nebo zabezpečení určité dílčí činnosti počítače jako jsou uspořádání a správa dat na disku, ovládání funkcí procesoru, grafické karty apod. (defragmentace6 disku, scan disk7), c) obsluţné programy – spravují nebo řídí některé součásti hardwaru např. ovladače8 nebo softwaru počítače jako jsou správci souborů, kteří zjišťují, co je uloţeno na disku počítače, spravují, kopírují, maţou uloţené soubory a sloţky (např. Průzkumník, Total Commander), d) komprimační programy – umoţňují komprimovat (zhustit) soubory dat. Po zkomprimování zabírají data na harddisku nebo některém z pouţívaných médií méně místa (např. WinZip, WinRAR), e) antivirové programy – před virovou nákazou chrání a zabezpečují antivirové programy, které odhalují a případně odstraňují počítačové viry 9(např. AVG, Avira).

6

Skládání rozdělených dat z velkých a objemných datových souborů, jenţ jsou na pevném disku počítače často uloţena na mnoha různých místech po malých dílčích částech. 7 Scan disk je nástroj, v MS-DOS a Microsoft Windows, který kontroluje a opravuje systém souborů a špatných clusterů na disku. 8 Ovladač nebo správněji ovladač zařízení (anglicky device driver) je software, který umoţňuje operačnímu systému pracovat s hardwarem. Některé ovladače jsou součástí operačního systému, jiné jsou distribuovány s hardwarem. 9 V oblasti počítačové bezpečnosti se jako virus označuje program, který se sám dokáţe šířit bez zásahu a vědomí uţivatele. Pro šíření sama sebe se vkládá do spustitelných souborů či dokumentů.

9

Programy pro podporu vývoje Software pro podporu vývoje poskytuje nástroje, které pomáhají programátorovi vytvořit počítačové programy a software s vyuţitím různých programovacích jazyků pohodlnější cestou. Mezi tyto nástroje patří: a) překladače programovacích jazyků – zdrojový text programu zapsaný programátorem v příslušném programovacím jazyce překládají do strojového kódu (zdrojový text převedený do posloupnosti jedniček a nul), (např. Microsoft C#, Visual Basic, Pascal apod.), b) debuggery, které se pouţívají pro nalézání chyb v jiných programech. Většinou je moţné zobrazit zdrojový kód laděného programu, takţe je ihned moţné vidět místo, kde se objevila programátorská chyba, c) CASE nástroje, jsou určeny pro návrh a vývoj programů (např. Enterprise Architect, CASE studio atd.). Pomocí těchto nástrojů dodavatelé zákazníkům mohou představit např. prototypy softwaru, najít shodu u problematického poţadavku vytvořením jednoduchých diagramů apod. d) nástroje na reportování chyb, v nichţ uţivatelé mohou dodavateli odesílat hlášení o chybách přímo při jejím odhalení. Nástroje na reportování chyb mohou také hlášení při chybě zasílat automaticky, e) nástroje pro týmovou spolupráci jako je např. Visual Studio 2008 Team Systém umoţňují visuální design servisně orientovaných řešení a jejich validaci vzhledem k aplikačnímu prostředí a infrastruktuře ve které budou nasazovány. Nabízí pokročilé vývojové nástroje pro práci v týmech. Pomáhají tvořit aplikace, testovat je a sdílet výsledky s celým týmem a koncovým uţivatelem, f) nástroje pro komunikaci zákazníků s vývojáři zlepšují moţnosti dodavatelů účinně reagovat na situace související se zákazníky a jejich potřebami pomocí integrované komunikace a rychlého přístupu k lidem a informacím. Umoţňují efektivněji a účinněji poskytovat zákazníkům lepší a rychlejší pomoc s řešením problémů. Mezi funkce nástrojů patří prohledávání informačních zdrojů, portály, sledování přítomnosti, moţnosti zasílání zpráv, plánování schůzek a sdílení virtuálních pracovních prostorů skupinami.

10

Programy aplikační Aplikační programy jsou určeny pro všeobecné vyuţití širokým okruhem uţivatelů a patří mezi ně především následující druhy programů: a) textové editory – slouţí k vytváření, úpravě a tisku textových dokumentů (např. Microsoft Word, Microsoft Works, Poznámkový blok apod.), b) grafické editory – umoţňují úpravu, vytváření a tisk obrázků nebo jiných grafických dokumentů (např. PhotoShop, Corel Draw apod.), c) databázové systémy – shromaţďují, zpracovávají, třídí, vyhledávají a vyhodnocují velké skupiny údajů (např. Microsoft Access, Microsoft SQL Server, Oracle apod.), d) tabulkové kalkulátory – vhodné pro tvorbu tabulek. Do buněk, které tvoří sloupce a řádky tabulky se zapisují textové, číselné hodnoty nebo různé vzorce. Program dokáţe zabezpečit okamţitý výpočet a automatické přepočítávání při změně obsahu některé buňky (např. Microsoft Excel, Tab602, Calc apod.), e) prezentační programy – jejich pomocí lze vytvářet dokumenty obsahují texty i obrázky, které lze potom předvádět jako sérii obrazovek na počítači (PowerPoint), f) programy pro zpracování zvuku a videa – díky těmto programům lze digitalizovat a upravovat pořízený obrazový či zvukový záznam (např. Pinnacle Studio, Microsoft Movie Maker, WinAmp apod.), g) komunikační programy – vyhledávání, výměnu čí předávání informací v počítačových sítích zajišťují programy pro online a offline komunikaci (např. Microsoft Outlook Express, Internet Explorer, ICQ, Skype apod.). Pro zvláštní účely nebo omezený okruh uţivatelů byly vytvořeny zvláštní aplikační programy. Jsou často vytvářené vysloveně na objednávku. Do této skupiny například patří: a) informační zdroje, encyklopedie, slovníky, b) ekonomické a účetní programy, c) programy pro vedení podniků, skladů, škol, d) programy pro simulace a modelování různých jevů, e) programy pro navrhování objektů pomocí počítače – pro projektanty a konstruktéry, f) počítačové hry – plošinové, sportovní, akční, strategické, g) výukové programy, h) informační systémy podniků a institucí. 11

1.1.2 Software ve vztahu k zákazníkovi Software, který si můţe zákazník pořídit, je rozdělen na: a) krabicový, coţ znamená, ţe je zakoupen jiţ jako kompletně hotov bez moţnosti dalších úprav, b) typový aplikační software (TASW), který je moţno upravit dle potřeb zákazníka, c) individuální aplikační software (IASW) vytvořený kompletně na zakázku. Při pořízení u kaţdé z těchto kategorií řeší zákazník několik klíčových otázek. Na jejich základě se musí rozhodnout, zda zakoupí software krabicový, typový aplikační nebo individuální. Při výběru mohou být uvaţovány následující parametry: a) u krabicového a TASW splňuje-li software veškeré poţadované funkce, b) je-li cenově dostupný, c) efektivita určující např. jak software nakládá s časem procesoru, pamětí, místem na disku nebo komunikačními prostředky, d) spolehlivost, která stanoví, jak bude software odolný proti selhání, e) zda bude moţné provést instalaci na stávající hardware, f) kompatibilita, která stanovuje, jak snadno dokáţe software vyměňovat data nebo sluţby s jinými systémy, g) je-li software vhodný pro právě zákazníkem pouţívaný operační systém, h) bezpečnost určuje, jak jsou ochráněna data mezi jednotlivými uţivateli navzájem tak proti odcizení apod., i) flexibilita, která umoţňuje rozšíření programů o další moduly apod. Tato kritéria musí zákazník posoudit dle svých potřeb a moţností. Můţe si například vybrat program s licencí, o kterých píši níţe, jenţ mu umoţní si program zkoušet a testovat po stanovenou dobu a ţádná další omezení se na program nevztahují. Tím je moţné vyzkoušet veškeré funkce programu a zjistit zda splňuje stanovené parametry pro dané účely. Bohuţel u některých programů není právě tato doba dostatečně dlouhá pro odzkoušení veškerých moţných variant, které zákazník potřebuje nasimulovat. Například v situaci, kdy potřebuje vyzkoušet program, ve kterém je nutné nejdříve naplnit databází číselníků a poté teprve simulovat jednotlivé případy uţití, můţe být čas na vyzkoušení nedostatečný. Výtek by se samozřejmě dalo najít větší mnoţství a osobně jsem se s těmito

12

problémy setkal. Optimálním řešením je hledat vhodný software, který je bezplatný anebo spadá do kategorie Open Source viz kapitola Softwarové licence. Krabicový software (FPP – Full Package Product), který je typicky poskytován s licencí umoţňující instalaci na jednom počítači. Zákazník si má moţnost software od některých výrobců (v dnešní době převáţná část) vyzkoušet díky některé z níţe uvedených licencí. Tento software bývá cenově nejvýhodnější, protoţe je prodáván ve větším objemu. Díky licenci neumoţňuje další modifikaci zákazníkem a jeho funkce jsou vázány pouze na ty, které jsou dodávané výrobcem. Jelikoţ se výrobce snaţí distribuovat krabicový software, mezi co nejvíce zákazníků není k jednotlivým zákazníkům přistupováno individuálně a zákazník tak nemá moţnost ovlivňovat vývoj dle svých potřeb. Pokud takový software není vhodný pro předpokládané uţívání nebo neobsahuje všechny potřebné funkcionality, je jednou z moţností pořídit TASW. Typový aplikační software (TASW) se dodává se základní funkcionalitou případně základními moduly a ty je moţné doplnit a rozšířit dle poţadavků zákazníka. Takové úpravy přináší další finanční náklady, které je nutné připočítat k ceně základních modulů či funkcionalitám. Můţe se jednat o systémy, jeţ v základní verzi nabízí správu uţivatelů a pak další základní moduly jako například tiskové sestavy apod. Na přání zákazníka je moţné doplnit tiskové sestavy o další, které tento modul neobsahuje, nebo dokoupit nadstandardní modul kde je moţné tiskové sestavy modelovat. Tento software je vhodný, pokud je natolik flexibilní, ţe dokáţe pokrýt zákazníkovy potřeby. Je cenově nákladnější neţ krabicový software, ale pouze v případě, ţe zákazník poţaduje další, dodatečné úpravy. Výhody: a) kratší doba realizace oproti IASW, b) zákazník kupuje za nejniţší náklady, software je typový a rozsah nákladů na vývoj, konzultace a vytvoření koncepce je dělen mezi mnoho zákazníků, právě díky tomu je cena niţší, c) jednotlivá funkčnost je podrobena potřebám desítkám firem a odvětvím, dosahuje tak vysoké kvality a dalším vývojem je software přizpůsobován pro stále vyšší efektivitu,

13

d) vyuţítí tzv. best practices, tedy metodik jiných uţivatelů, konkurentů, jejich standardů a osvědčených efektivních obchodních a pracovních metodik. Lze tak tedy čerpat z dlouhodobých zkušeností ostatních uţivatelů, e) změny v legislativě, zákonech apod. lze měnit parametricky. Systém dosahuje určité míry parametričnosti a je tak schopen relativně rychle reagovat na dané změny, např. změna DPH apod., f) nové moduly a budoucí funkčnosti jsou testovány řadou uţivatelů a lze tak rychleji reagovat na jejich nedostatky. Nevýhody: a) je nutné přizpůsobení podniku zákazníka moţnostem systému, b) pokud jsou jednotlivé TASW od různých dodavatelů, je zde vysoké riziko nekonzistentnosti systému a obtíţnější integrace. Celková spolehlivost integrace je závislá na politice zpětné kompatibility od různých dodavatelů, na jejich podpoře pro moţnosti integrace, c) je nutné udrţovat větší mnoţství integračních vazeb nebo stavět speciální převodové můstky či komunikační ostrovy (4). Individuální aplikační software (IASW) je poslední moţností, kdyţ nelze vybrat ze dvou předchozích. Pokud má zákazník poţadavky natolik specifické, ţe takový software ještě nebyl vytvořen anebo ţádný z podobných nesplňuje poţadované vlastnosti a není natolik flexibilní, aby jej bylo moţné přizpůsobit, musí se takový software vyvinout. Tento software je cenově nejnákladnější a jeho cena se odvíjí od pracnosti jeho vytvoření. Mezi takový software by se mohly řadit specializované informační systémy nebo programy v chemickém průmyslu apod. Výhody: a) přesně odpovídá tomu, co zákazník poţaduje. Systém je přizpůsoben konkrétním podnikovým procesům a způsobu jakým chce zadavatel se systémem pracovat, tím tedy nabízí očekávanou funkčnost, b) funkčnost a celková koncepce je ve firmě detailně známa, c) konkurence nezná silné a slabé stránky podnikání podporovaného informačními technologiemi, d) snadná reakce na okamţité potřeby uţivatelů, 14

e) obecně se dá tvrdit, ţe tento způsob nabytí softwaru je vhodný pro utajované nebo citlivé informace, kde lze zaručit určitou zvýšenou bezpečnost systému, stejně tak bezpečnostní chyby nejsou navenek známé, jak je tomu u některých open source systémů. Nevýhody: a) všechny vysoké náklady na vývoj, konzultace, vytvoření nové koncepce apod. finančně pokrývá zákazník. Rovněţ tak provizorní stavy funkčnosti, provizorní moduly a jejich náklady kryje taktéţ zadavatel v plné výši, b) absence světových a odvětvových standardů, které si firma zprvu ani nemusí uvědomovat. Absence vyzkoušených a fungujících technik ve funkčnosti systému, c) obvykle je výsledný software méně kvalitní, jeho logika není podrobena pouţíváním desítkami nebo stovkami uţivatelů. Proces připomínkování a odstraňování chyb je plně na zadavateli a není rozloţen mezi řadu uţivatelů. Interní programátoři v roli dodavatele nemusí dosahovat potřebných kvalit a mít zkušenosti s takovými projekty, d) obtíţná integrace systémů, e) delší doba nasazení a vývoje, f) budoucí údrţba je draţší, díky absenci parametričnosti, kaţdá nutná změna v zákonech, v legislativě, v obyčejích daného odvětví představuje podstatný zásah do systému, g) software je plně závislý na svých tvůrcích, často při fluktuaci zaměstnanců se systém stává nekonzistentním a ztrácí jakékoli další moţnosti vývoje, údrţby a správy (4).

1.1.3 Softwarové licence Licence určuje, jakým způsobem můţe zákazník software vyuţívat, např.: a) zda je moţné jej pouţívat ke komerčním nebo pouze soukromým účelům, b) na kolik počítačů lze program nainstalovat, c) zda je moţné jej volně šířit a nevystavuje-li se tím zákazník nebo uţivatel sankcím za porušování zákona. Podle serveru itpravo.cz (5), kde je problematika licencí podrobně popsána, je licence "oprávnění dílo uţít", tedy souhlas s uţitím software. Licence tedy není nijak hmotně vyjádřitelná (nejde o listinu atp.). Je třeba uvést, ţe licence nemusí být výhradně udělena na základě písemné licenční smlouvy, ale téţ můţe jít o smlouvu ústní nebo smlouvu 15

uzavřenou konkludentně10. Zákazník by proto neměl a nesmí povaţovat za licenci ani fakturu, ani doklad o koupi ani licenční smlouvu. Všechny tyto dokumenty mohou pouze prokázat (více či méně důvěryhodně), ţe licence byla udělena. Obrázek č. 1: Znázornění softwarových licencí

Zdroj: dostupný z http://www.gnu.org/philosophy/categories.html, [cit. 10.1.2009]

Vybral jsem jen některé ze softwarových licencí, se kterými se zákazník při koupi nebo staţení softwaru zajisté setká. Rozdělení je znázorněno viz Obrázek č. 1 a dle serveru GNU Operating System (6) je moţné licence dělit na následující: Open Source11 Programy s touto licencí jsou k dispozici včetně svého zdrojového kódu. Tento kód lze upravovat, ale nelze ho vyuţívat pro tvorbu zisku. Je však moţné vybírat poplatky odpovídající nákladům na vývoj a distribuci těchto programů. Obrázek č. 1 zobrazuje, jaké další licence spadají do této kategorie. Přesné vymezení všech pravidel je komplikované a jejich přesné znění lze nalézt na http://www.gnu.cz/. Autoři na tomto serveru význam označení Open Source povaţují za téměř totoţný s významem slova free software. Typickým příkladem Open Source softwaru jsou např. operační systém Linux, grafický program GIMP, či kancelářský balík OpenOffice org.

10

Konkludentní způsob uzavření smlouvy je takový, kdy obě strany jednají způsobem, ze kterého je zřejmý úmysl smlouvu uzavřít a kterým jsou naplněny podstatné znaky této konkrétní smlouvy. Nejde tak o výslovný (písemný nebo ústní) projev vůle. 11 V češtině se pouţívá označení svobodný software.

16

Public Domain Obrázek č. 1 zařazuje tento software mezi free software. Licence umoţňuje zákazníkovi programy volně pouţívat. Autor se u nich zcela zřekl svých autorských práv. Programy jsou většinou k dispozici včetně zdrojového kódu. Lze je tedy bez jakýchkoli poplatků pouţívat, upravovat i začleňovat do jiných programů. V českém právním systému se nikdo nemůţe vzdát svých (autorských) práv, je pouze moţné nabídnout veřejnosti bezúplatnou licenci na libovolné uţití díla, ale lze kaţdopádně předpokládat, ţe autor, který svoje dílo takto označil, se svých práv nebude domáhat (7). Copylefted software Software pod touto licencí lze volně šířit a také modifikovat. Pravidla distribuce však nedovolují uţivatelům při redistribuci přidat k programu ţádná omezení, coţ také vyplývá ze zařazení této licence, viz Obrázek č. 1. Výsledek distribuce musí být opět free software. Freeware Tento pojem bývá často zaměňován za pojem free software. Rozdíl mezi nimi činí definice, která není u freewaru pevně stanovena a tento pojem se vztahuje k volně pouţitelným programům. Díky licenci je lze bez poplatků pouţívat, ale je nutno dodrţovat autorská práva jejich tvůrců. Programy tedy nelze nijak upravovat. Autoři většinou nepublikují jejich zdrojový kód. Proprietary software Proprietární software je software, který není ani svobodný, ani částečně svobodný. Jeho svobodné uţívání, změna či šíření jsou zakázány nebo musíte ţádat o povolení, případně jsou omezení taková, ţe jej nelze svobodně vyuţívat (6). Shareware Volně šiřitelné programy, které jak znázorňuje Obrázek č. 1, spadají mezi proprietární software. Licence umoţňuje zákazníkovi si program před zakoupením vyzkoušet. Můţe jej také bez omezení šířit za účelem vyzkoušení. Po určité době je však nutné splnit podmínky licence stanovené autorem tj. většinou program zaplatit.

17

Komerční software Program si musí zákazník nejprve zakoupit a teprve poté ho můţe začít pouţívat. Software je obvykle moţné pouţívat jen dle omezení dané jeho licencí. Ta omezuje např. počet instalací software či přenositelnost licence. Komerční software většinou spadá mezi proprietální software. Příkladem komerčního software je Microsoft Windows, Microsoft Office či Adobe Photoshop. OEM12 (Original Equipment Manufacturer) Program s touto licencí je součástí PC a tiskárny, protoţe byla pořízena společně s koupí příslušného hardwaru. Výhodou pro zákazníka je niţší pořizovací cena. Tato licence softwaru je nepřenosná a zaniká s likvidací hardwaru, ke kterému náleţela. Multilicence Tento druh licence umoţňuje nainstalovat program pro větší počet počítačů. Buď pro určitý stanovený počet (např. 10), nebo pro všechny počítače v organizaci. V případě všech licencí je třeba si uvědomit, ţe nekupujeme daný program, ale jen právo program stanoveným způsobem pouţívat. Pokud to licence výslovně nepovoluje, není moţné program dále šířit nebo upravovat. Nedodrţení licence je porušením autorského práva na coţ pamatuje §152 Porušování autorského práva, trestního zákona. (1) Kdo s dílem, které je předmětem ochrany podle práva autorského, neoprávněně nakládá způsobem, který přísluší autoru nebo jinému nositeli těchto práv, anebo kdo jinak tato práva porušuje, bude potrestán odnětím svobody aţ na dvě léta nebo peněţitým trestem či propadnutím věci. (2) Odnětím svobody na šest měsíců aţ pět let nebo peněţitým trestem nebo propadnutím věci bude pachatel potrestán, a) získá-li činem uvedeným v odstavci 1 značný prospěch, nebo b) dopustí-li se takového činu ve značném rozsahu.

12

OEM (zkratka anglického Original Equipment Manufacturer) je obchodní termín, který označuje výrobek vytvořený jedním výrobcem pro jiného výrobce, který jej následně prodává pod svou vlastní obchodní značkou.

18

1.1.4 Informační systémy - IS Informační systémy jsou samostatnou kapitolou, jelikoţ nejsou pouze software, ale souhrn různých softwarových a někdy i hardwarových komponent, které tvoří ucelený systém, jenţ především plní a podporuje strategické cíle ve firmách. Jak je vidět viz Obrázek č. 2, na kterém je zobrazena globální architektura informačního systému, zajišťují tyto systémy podporu od operativního po strategické řízení. U informačních systémů a jejich rozdělení bych se chtěl pozastavit, protoţe především těchto systémů se týká vývoj na zakázku a právě při vývoji těchto systémů se nejčastěji setkává zákazník s dodavatelem. U ostatních výše zmiňovaných programů se zákazník buď vůbec anebo přímo nepodílí na vývoji. Informační systémy můţeme rozdělit, jak uvádí (8) podle různých hledisek (9) na tři kategorie. Tyto kategorie můţe určovat velikost, účel, strukturální sloţitost, obsah, počet a typy uţivatelů či územní rozsah informačního systému. Rozhodující pro volbu přístupů a metod je ale především vztah informačního systému k systému řízení, jímţ odráţí i řadu výše zmíněných aspektů. Obrázek č. 2: Globální architektura IS – úrovně řízení

Zdroj: dostupný z https://akela.mendelu.cz/~loucka/studium/9sem/SZZ/systemove%20inzenyrstvi/stz_syst_inz.doc, [cit. 12.02.2009]

19

Transakční procesní systémy – TPS (Transaction Processing Systems) Obrázek č. 2 znázorňuje tento systém jako základnu architektury. Transakční procesní systémy jsou navrţeny tak, aby provedení běţné transakce bylo efektivní a přesné. Firmy budou mít několik (někdy i mnoho) TPS, například: a) platební systém zasílání faktur zákazníkům, b) systémy pro výpočet týdenní a měsíční mzdy a platby daní, c) výrobní a nákupní systémy pro výpočet poţadovaných suroviny, d) skladový řídící systém pro zpracování všech pohybů. Informační systém pro řízení – MIS (Management Information Systems) Správa informačního systému (MIS) se soustřeďuje na interní zdroje informací. MIS bere obvykle údaje z transakčních procesních systémů a shrnuje je do řady řídících zpráv. MIS zprávy jsou převáţně pouţívány středním managementem a provozním dohledem viz Obrázek č. 2. Informační systém pro vrcholové řízení – EIS (Executive Information Systéms) Jak napovídá název, a umístění viz Obrázek č. 2, je způsob řízení informačního systému umístěn na vrcholu globální architektury. Ta má za cíl umoţnit a zlehčit podporou informací a rozhodnutí. Je vytvořena pro potřeby vrcholového vedení, jemuţ poskytuje snadný přístup k vnitřním i vnějším informacím relevantním k naplnění strategických cílů organizace. Je obecně povaţován za speciální formu (DSS). Elektronická výměna dat – EDI (Electronic Data Interchange) Na levé straně schématu globální architektury viz Obrázek č. 2, nalezneme EDI. Ta představuje aplikace, které realizují elektronickou komunikaci s okolím. Tento systém je schopen například zajistit automatické vystavení objednávky v případě poklesu stavu materiálu ve skladě pod stanovenou mez. Dále umoţňuje nahradit papírové dokumenty elektronickými a sníţit tak náklady spojené s jejich výměnou a současně zvýšit efektivitu a kvalitu prováděných procesů.

20

Kancelářské informační systémy – OIS (Office Information Systems) OIS představují aplikace orientované na podporu kancelářských prací. Jedná se především o textové editory (procesory), tabulkové procesory, systémy řízení bází dat, prezentační systémy (tvorba obrázků, prospektů), plánovací kalendář (dodává se v rámci Windows), elektronickou poštu, elektronické diskusní konference, prohlíţeče WWW stránek, podporu řízení projektů atd. Nalezneme ve schématu globální architektury, viz Obrázek č. 2 vpravo. Systémy pro podporu rozhodování – DDS (Decision Support Systems) Rozhodující podpůrné systémy (DSS) jsou navrţeny speciálně tak, aby pomohli řídit rozhodování v situacích, kde existuje nejistota ohledně moţných výsledků těchto rozhodnutí. DSS zahrnuje nástroje a techniky k získání potřebných informací a analýzy moţností a alternativ. DSS často obsahuje moţnosti pouţití sloţitých tabulkových databází a vytváření obecně nazvaných "co-kdyţ" modelů. Expertní systémy – ES (Expert Systems) Expertní systém je informační systém, který pomáhá ne příliš zkušenému pracovníkovi řešit úlohy diagnostického charakteru. Umoţňuje tak poskytnutí znalostí, které má například jen jeden člověk i ostatním pracovníkům. Výkonný systém podpory – ESS (Executive Support Systems) Výkonný systém podpory (ESS) má za cíl pomáhat vrcholovému vedení činit strategická rozhodnutí. Shromaţďuje, analyzuje a shrnuje klíčové interní a externí informace pouţívané v podnikání. Dobrým způsobem, jak přemýšlet o ESS, je představit jej vedení týmu jako kokpit letadla s přístrojovou deskou zobrazující stav všech jejich klíčových podnikatelských aktivit. ESS typicky zahrnuje spoustu údajů, analýz a nástrojů pro modelování, obecně nazvaných "co-kdyţ" analýz, které pomáhají vytvářet strategická rozhodnutí. Strategické informační systémy – SIS (Strategic Information Systems) Strategické informační systémy se snaţí o zvýšení konkurence schopnosti podniku. Jsou přímo spjaty s výrobou nebo výrobkem samotným. V průmyslové oblasti jsou to např. stroje a v obchodě třeba elektronická pošta. 21

Znalostní systémy – KWS (Knowledge Work Systems) Znalostní systémy řízení (KWS) jsou určeny na pomoc podnikům pro vytváření a sdílení informací. Obvykle se pouţívají v podnikání, kde zaměstnanci dosahují nových poznatků a odborných znalostí, které jsou pak sdíleny dalšími lidmi v organizaci a pomáhají vytvářet další obchodní příleţitosti. Dobrým příkladem jsou firmy advokátů, účetních a konzultantů managementu. KWS je postaven na bázi systémů, které umoţňují efektivní třídění a distribuci znalostí. Samotné znalosti by mohly být obsaţeny v textových dokumentech, tabulkách, prezentacích v PowerPointu, internetových stránkách či dalších médiích. Chcete-li sdílet znalosti, KWS můţe být pouţit skupinami spolupracujícími na systémech, jako je např. intranet.

1.2 Zákazníci Tato kapitola je věnována zákazníkovi, který je nedílnou součástí tvorby a obchodu se softwarem. Vysvětlím, kdo je zákazník a jaké motivy můţe mít pro pořízení softwaru. Přístupy k vývoji nebo pořízení u kaţdého z výše uvedených programů a informačních systémů, jelikoţ jsou kaţdý specifický, jsou velice různé a pokaţdé v nich figuruje zákazník, pro kterého je tento software vytvářen. Zákazníkem můţe být v podstatě kdokoliv. Fyzické či právnické osoby, které software pouţívají pro svou zábavu nebo práci, dále firmy, které software implementují do svých zařízení či výrobků. Podíl zákazníka na vývoji u jednotlivých druhů softwaru se velice liší. Zákazníky můţeme rozdělit na dvě kategorie: a) zákazníci, kteří software nebo informační systémy kupují, ale primárně je nevyuţívají. Takovým zákazníkem můţe být například majitel firmy, který má v úmyslu zlepšit komunikaci se svými zákazníky či partnery. Pro realizaci tohoto zlepšení zakoupí jiţ hotový software nebo si jej nechá na zakázku vytvořit. Pro tuto práci budu takového zákazníka označovat dále jako „zákazník―, b) zákazníci, kteří se softwarem a informačními systémy pracují, zadávají do nich data, která se zpracovávají do srozumitelných výstupů, a vyuţívá se jich pro další práci. Můţe se také jednat o zákazníky, kteří uţívají software pro zábavu apod. Důleţitý je osobní kontakt se softwarem. Takového zákazníka můţeme označit a v této práci o něm budu psát jako o „uţivateli―. 22

Jak jsem uvedl, zákazníkem můţe být kdokoliv, z toho vyplývá rozmanitost nabízeného a kupovaného software. V této práci bych se chtěl především zaměřit na individuální aplikační software, který je vytvářen tzv. na zelené louce. K tomuto kroku firmy většinou přistupují ve chvíli, kdy jejich zvláštní poţadavky není schopen splnit ţádný dodavatel softwaru jiţ hotovým produktem ani případně typově aplikačním softwarem. Jak uvádí časopis Moderní řízení (10), pokud se podnikatelé nebo malé firmy rozhodnou řešit otázku účetnictví vlastními silami, je pro ně optimálním řešením volba některého z moderních ekonomických systémů, které zahrnují oblast finančního účetnictví a často i lidských zdrojů, skladového hospodářství, oběhu zboţí apod. Takový systém je zpravidla hardwarově nenáročný a obvykle nevyţaduje dodatečné investice do technického vybavení. Některé z těchto systémů nabízejí i řadu speciálních rozšíření vhodných například pro maloobchody, kde jsou schopny zcela nahradit i dosavadní řešení v podobě pokladen. U středních podniků je jiţ informační systém naprostou nezbytností. Vedle účetnictví či ekonomiky řeší zcela samozřejmě i mnohé další oblasti. Informační systémy pro střední firmy jsou obvykle tvořeny z jednotlivých modulů, které lze sestavit podle potřeb uţivatele. Samozřejmostí je dnes i moţnost jejich rozšíření o další specializovaná řešení pro různá odvětví podnikání. Z pohledu technologického je nezbytná vícevrstvá architektura klient-server a moţnost vzdáleného přístupu s vyuţitím mobilních zařízení. Mezi důleţité funkce moderního informačního systému patří i schopnost přímé elektronické komunikace s bankovním ústavem nebo se státními úřady. Relevance a dostupnost správných informací ve chvíli, kdy jsou potřeba, je aktuálním problémem zejména manaţerů velkých firem. Zprostředkovat jim bez zbytečných časových ztrát právě ty podstatné informace je úkolem velkého informačního systému. Systém pro velké firmy řeší všechny oblasti zmíněné u systému pro střední firmy. K jeho základním vlastnostem patří však také například přizpůsobivost firemním procesům v konkrétním podniku, otevřenost a kompatibilnost pro komunikaci s jinými systémy a technologická vyspělost.

23

1.3 Dodavatelé Posledním zástupcem, který uzavírá trojúhelník, je dodavatel, který zákazníkovi software nabízí, případně vyvíjí. Dodavatele lze obdobně jako zákazníky rozdělit do kategorií (4): a) první kategorie zahrnuje dodavatele softwaru především komerčního krabicového, pokud budu brát v úvahu, ţe se za software platí, a ţe tento dodavatel nebude software dále upravovat. Jak jsem uvedl v rozdělení softwaru, jedná se především o operační systémy a aplikační software, b) v druhé kategorii nalezneme především dodavatele typového software označovaného TASW. Aplikace je vytvořena výrobcem generalizací poţadavků určité třídy uţivatelů (zákazníků). Vývoj je pro zákazníka levnější neţ u IASW (celkové náklady jsou sice vyšší, ale rozpustí se na více zákazníků), vývoj je kratší neţ při IASW (implementuje se jiţ hotový software), podporovaný business proces se musí přizpůsobit (tak lze vyuţít i „Best Practicies― zabudované v TASW), je výhodné zejména pro standardizované aplikace (účetnictví, e-pošta). c) třetí kategorie obsahuje dodavatele zaměřené na specializovaný neboli individuální software označovaný jako IASW, který se zákazníkovi vyvíjí na zakázku. Můţe jít o specializované informační systémy apod. Tito dodavatelé mají vlastní vývojové oddělení, které tento software pro zákazníky programuje, případně upravuje. Jak jsem zmínil, můţe být dodáván software, který obsahuje základní funkcionality, a další jsou programovány podle poţadavků zákazníka, U dodavatelů je obdobná situace jako u zákazníků. Hraje zde roli, jaké má dodavatel finanční moţnosti. Ty totiţ určují, jaké technologie si můţe dodavatelská firma dovolit nakoupit a pouţívat, kolik na daném projektu či projektech bude pracovat lidí, které bude platit, a tudíţ jaká bude výsledná cena a strávený čas na konkrétním projektu. Vše samozřejmě záleţí na pouţitých technologiích, kterých je v současné době velké mnoţství. Také na způsobu vývoje nebo spíše metodice, která bude určovat, jakým způsobem bude daný projekt vyvíjen. Metodik, které můţe dodavatel pouţít pro vývoj softwaru, je několik druhů např. agilní a tradiční, kterými se budu zabývat v následujících kapitolách. Nejsou to však pouze metodiky a technologie, které dodavateli softwaru zajistí úspěšnost projektu, dodrţení časového harmonogramu a nákladů. 24

Jak se uvádí v (11), je bohuţel zhruba sedmdesát aţ devadesát procent softwarových projektů neúspěšných. Příčin můţe být několik. Uvádí se nedokonalá správa poţadavků, nejasná komunikace, křehká architektura systému, podcenění sloţitosti řešené úlohy, skryté nesrovnalosti mezi poţadavky, návrhem a implementací, neadekvátní testování, subjektivní odhad stavu projektu, nepředcházení rizikům, nekontrolované změny, nedostatečná automatizace a mnoho dalších. Osobně jsem se setkal s různými firmami, které pouţívají různé techniky a nástroje pro vývoj softwaru. Ţádný z těchto nástrojů, ale nedokázal odstranit jeden z velmi váţných problémů. Tímto problémem při navrhování a vývoji určitého produktu, pokud je to produkt pro zákazníka a ještě k tomu má být vytvořen na míru, je komunikace se zákazníkem. Tu totiţ nezajišťují stroje, ale lidé. Mnoho přednášek o softwarovém vývoji, kterých jsem se účastnil, začíná obrázkem, který znázorňuje, co si zákazník přeje a jaký bývá výsledek „ten se samozřejmě s přáním zákazníka neshoduje― a bývá zdůrazňováno, ţe právě komunikace mezi zákazníky a dodavateli je klíčová pro úspěšnost softwarového projektu. Jak píše Karl E. Wiegers (12), firmy, bez ohledu na to, zda se snaţí dodrţovat stanovené metodiky či nikoli, zapomínají na komunikaci se zákazníkem. Se zákazníkem nejvíce samozřejmě komunikují v úvodní fázi projektu, kdy se specifikují poţadavky a je prováděna analýza. V dalších fázích projektu, ale tato komunikace se zákazníkem opadá a tím vzniká řada nedorozumění a nesrovnalostí v poţadovaném a v dodávaném softwarovém produktu nebo informačním systému. Komunikace odpovídá tedy spíše tradičním metodikám, od kterých se v dnešní době ustupuje, a přechází se k agilním metodikám, jeţ jsou schopné pruţně reagovat na změny a poţadavky zákazníka vznikající v průběhu celého projektu. O problematice spojené s vývojem softwaru a komunikaci mezi zákazníkem a dodavatelem spojené s dvěma odlišnými skupinami metodik budu psát v následujících kapitolách.

25

2.

Vztahy mezi zákazníkem a dodavatelem při

vývoji tradičními metodikami V této kapitole popisuji dva modely ţivotního cyklu, které měly a doposud mají vliv na vývoj metodik. Bývají označovány jako tradiční neboli rigorózní. Někdy jsou nazývány jako těţké podle A. Cockburna13, který metodiky charakterizuje podle váhy v (13). Ţivotní cyklus softwaru je časový úsek, který začíná úmyslem vytvořit software a končí, kdyţ se software přestane pouţívat (14). Samotný popis modelů ţivotního cyklu je důleţitý pro pochopení metodiky. Zaměřil jsem se, jakým způsobem zákazník a dodavatel společně komunikují při vývoji vybranou metodikou, co musí zákazník splňovat a jakým způsobem dodavatel k němu a k vývoji softwaru přistupuje.

2.1 Tradiční metodiky Vybral jsem dva zástupce ţivotního cyklu softwaru a jednu z tradičních metodik, kteří znamenali milníky v historii softwarového inţenýrství. Nyní tedy představím vodopádový model, spirálový model a metodiku RUP (Rational Unified Process).

2.1.1 Vodopádový model Tento model patří mezi základní modely ţivotního cyklu softwaru. Sekvenční vývojový proces tohoto modelu připomíná vodopád. Proto se nazývá vodopádový model. V tomto modelu se vývoj člení do navazujících kroků analýzy poţadavků, návrhu, implementace, testování

(validace), integrace

a údrţby

jako na

neustále

se svaţující tok.

Charakteristickými znaky tohoto modelu jsou za sebou jdoucí fáze, které nemají iterace jak je tomu u dalšího popisovaného modelu. Mezi jednotlivými fázemi je proces schvalování, jímţ musí projít všechny dokumenty, aby vývoj mohl pokročit do dalšího stádia vývoje. Původní "vodopádový model― postupuje od shora dolů. Jako první formální popis vodopádového modelu je často citován článek publikovaný v roce 1970 W. Roycem14 v

13

Alistair Cockburn je jedním z iniciátorů hnutí Agilního vývoje softwaru, pomáhal napsat manifest agilního programování v roce 2001 a PM Declaration of interdependence v roce 2005. 14 Winston W. Royce (1929-1995) byl americký počítačový vědec, ředitel Lockheed Software Technology Center v Austinu, Texas, a jeden z lídrů v oblasti softwarového vývoje v druhé polovině 20. století.

26

(15). Zajímavé je, ţe Royce paradoxně představil tento model jako příklad chybného, nefungujícího modelu. Základní fáze vodopádového modelu jsou následující: 1. Systémové poţadavky (Software Requirements) 2. Softwarové poţadavky (Systém Requirements) 3. Analýza a specifikace poţadavků (Analysis) 4. Návrh (Program Design) 5. Implementace (Coding) 6. Testování a integrace (Testing) 7. Provoz a údrţba (Operations)

Obrázek č. 3: Schéma ţivotního cyklu modelu vodopád

Zdroj: dostupný z http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf, [cit. 12.12.2008]

Psal jsem sice o tom, ţe tento model je striktně sekvenční, ale Obrázek č. 3 zobrazuje, ţe šipky nevedou jen jedním, ale oběma směry. V modelu se lze pohybovat vţdy o jednu fázi dopředu nebo zpět. Například, pokud zjistíme ve fázi implementace, ţe jsme v návrhu udělali chybu, můţeme se vrátit o jednu fázi zpět, návrh opravit a vrátit se opět do implementační fáze. Je důleţité, kdyţ přecházíme od fáze návrhu k implementaci, i kdyţ uţ je to po druhé, aby prošly schválením všechny dokumenty. Vývoj se můţe vrátit do jakékoli z předešlých fází teprve, pokud se nachází ve fázi údrţby. Teprve nyní umoţňuje provedení jakýchkoliv úprav. Z praxe je ověřeno, ţe změny v poţadavcích přicházejí dříve neţ ve fázi údrţby anebo často není seznam s poţadavky 27

úplný ani v době kdy probíhá jejích specifikace. Proto není pro dnešní dobu tento model ideální. V době uvedení byl tento model revoluční a bylo podle něj naprogramováno mnoho softwaru. V dnešní době je spíše uváděn jako referenční model, se kterým jsou srovnávány ostatní modely. Také se na tomto modelu zdůrazňuje, jak se nemá postupovat. Tento model má nespornou výhodu v jeho jednoduchosti a jednoznačné definici posloupnosti jednotlivých fází vývoje. Jeho jednoduchost umoţňuje snadné pochopení, řízení a práci podle něj. Snadná kontrola stádia projektu a zjišťování jaké části specifikací poţadavků jiţ byly splněny, lze dobře kontrolovat díky zakončení kaţdé fáze zpracováním předem daných dokumentů. Schvalovací řízení zajišťuje přechody mezi fázemi.

2.1.2 Spirálový model Tento několik let se vyvíjející model se stal nástupcem vodopádového modelu popsaného v předchozí kapitole. Jelikoţ nebylo moţné předchozí model dále pouţívat pro velké projekty, snaţili se softwaroví inţenýři vymyslet takový přístup, v němţ by se odstranily nedostatky vodopádu. Spirálový model ţivotního cyklu představil Barry Boehm15 v roce 1985. V obou případech se stále jedná o modely ţivotního cyklu softwarového produktu, protoţe to nejsou metodiky vývoje software. Rozdíl mezi modelem ţivotního cyklu a metodikou je, ţe ţivotní cyklus softwaru je časový úsek, který začíná úmyslem vytvořit software a končí, kdyţ se software přestane pouţívat a metodika je tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu (14). Spirálový model, přinesl dvě zcela nové a zásadní vlastnosti, a to iterativní přístup a podrobnou analýzu rizik. Tomuto modelu se někdy říká, ţe náleţí do skupiny přístupů řízených riziky. Jelikoţ u vodopádového modelu, který byl pouţit u velkých projektů, se většinou nepodařilo vţdy stanovit úplnou a přesnou specifikaci poţadavků, byla u spirálového modelu stanovena jen architektura a funkčnost celého systému. To se osvědčilo jako mnohem efektivnější. Následně se poţadavky rozpracovávaly do dalších

15

Barry W. Boehm (1935) je americký softwarový inţenýr, TRW emeritní professor softwarového inţenýrství na Ústavu informatiky na University of Southern California, a známý mnoha příspěvky o softwarovém inţenýrství.

28

detailů. V době, kdy byl spirálový model uveden, bylo cyklické opakování jednotlivých kroků vývoje přelomem v chápání ţivotního cyklu. Dalším významným pojmem se stal pojem analýza rizik. Ta se prováděla v kaţdé iteraci a určovala další vývoj projektu. Události nebo situace, které mohou ohrozit projekt, se stávají rizikem a tedy klíčovým pojmem pro projekt. Během analýzy se kaţdému riziku přiřadí jeho nebezpečnost a pravděpodobnost výskytu. Podrobné analýzy rizik by se měli provádět často a tím by se mělo podařit dopředu odhalit nevhodné návrhy nebo problémy, které mohou být skryté a mohou tak ohrozit průběh projektu. Obrázek č. 4:Schéma spirálového ţivotního cyklu

Zdroj: dostupný z http://en.wikipedia.org/wiki/File:Spiral_model_(Boehm,_1988).png, [cit. 18.12.2008]

Na základě neustálé analýzy rizik se v průběhu projektu výrazně sniţuje uplatnění nevhodného řešení projektu. Případná chyba je odhalena daleko dříve, neţ bylo moţné u předchozího vodopádového modelu. Jak je vidět, Obrázek č. 4 zobrazuje kaţdou otáčku spirály jako reprezentanta fáze softwarového

procesu.

Nejvnitřnější

neboli

tzv.

nulová

fáze

zobrazuje

studii

proveditelnosti, tedy všeobecný záměr. Dalším je definice poţadavků, návrh systému, vytvoření všech programů. Tyto fáze jsou rozděleny do čtyř různě dlouhých oddílů. V softwarovém inţenýrství je spirála důleţitým milníkem a v minulosti byla pouţita k řadě projektů. 29

2.1.3 RUP (Rational Unified Process) Metodika RUP vznikla na základě dvou předchozích představených modelů ţivotního cyklu. Metodika je tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu (14). Tvůrci a vývojáři zaměření na diagnostiku vlastností různých nepodařených softwarových projektů se snaţili rozpoznat příčiny těchto nezdarů. Rovněţ také studovali stávající softwarové inţenýrství a jeho řešení pro tyto nezdary. Projektové selhání je způsobeno kombinací několika příznaků, i kdyţ kaţdý projekt neuspěje v individuálních směrech. Výsledkem jejich studie byl definovaný a strukturovaný softwarový inţenýrský proces nejlepších praktik (Best Practices) a těmi jsou: a) iterativní vývoj software, b) správa poţadavků, c) architektura zaloţená na komponentách, d) vizuální modelování, e) ověřování kvality software, f) řízení změn software. Ty představují základní „filosofii― RUPu a definují klíčové myšlenky, na kterých byla tato metodika zaloţena. RUP je moţné rozdělit do tří rovin: a) jako proces softwarového inţenýrství, kde je povaţován za systematický návod pro přiřazování úkolů a odpovědností v týmech a organizacích zabývajících se vývojem softwaru. Cílem je zajistit úspěch takovýchto projektů dodrţením kvality, termínu a rozpočtu, b) jako softwarový produkt, původně vyvinutý Rational Software, a nyní vlastnící firmou IBM16. Celá metodika je objektově orientovaná. RUP obsahuje IBM Rational Method Composer (RMC) produkt, který umoţňuje přizpůsobení procesu,

16

International Business Machines Corporation (IBM) je přední světová společnost v oboru informačních technologií zabývající se výrobou a prodejem počítačového softwaru a hardwaru a desítkou dalších sluţeb.

30

c) jako procesní framework, obsahuje předpřipravené procesní modely a návody, které je moţné přizpůsobovat organizaci, která s ním pracuje. Pro dodavatele softwaru je tato metodika velkým pomocníkem při plánování a vývoji softwaru. Jako software totiţ obsahuje rozsáhlou znalostní databázi přístupnou hypertextovými odkazy, odkazujícími na podrobné popisy pro různé typy činností. Ty jsou dostupné jako HTML17 dokumenty a je tedy moţné s obsahem pracovat v jakémkoliv dostupném webovém prohlíţeči. Jako další z předností metodiky jsou uvnitř obsaţené šablony pro všechny procesní artefakty. Díky zmíněným vlastnostem je tato metodika vţdy v aktuální verzi dostupná všem členům vývojového týmu, jimiţ jsou: a) analytik (Analyst) zastupuje zákazníka a konečného uţivatele. Pomáhá zúčastněným stranám vzájemně pochopit a řešit problémy, zachytit a stanovit priority poţadavků, b) architekt (Architect) je odpovědný za definování softwarové architektury, která zahrnuje tvorbu klíčových technických rozhodnutí omezující celkový návrh a implementaci systému, c) vývojář (Developer) je zodpovědný za vývoj části systému, včetně návrhu tak, aby se vešel do architektury, případně návrhu prototypu uţivatelského rozhraní. Dále se účastní implementace, jednotkových testování, integraci komponent, jeţ jsou součástí řešení, d) projektový manaţer (Project Manager) vede plánování projektu, koordinuje interakce zúčastněných stran, čímţ udrţuje tým zaměřený na splnění cílů projektu, e) zákazník, uţivatel (Stakeholder) představuje zájmovou skupinu, jejíţ potřeby musí být uspokojeny v rámci projektu. Je to role, kterou můţe obsadit kdokoliv, kdo bude potenciálně nebo významně ovlivňovat výsledek projektu, f) tester (Tester) je zodpovědný za klíčové aktivity při testování. Tyto aktivity zahrnují identifikaci, definování, zavádění a provádění nezbytných zkoušek, stejně jako logování výsledků testování a analýzu výsledků. Uvedené role jsou v této metodice popsány jako základní a nemusí znamenat, ţe kaţdá role připadá na jednu osobu v týmu. Některé role je moţné zastoupit pouze jedním člověkem a jiné zase mohou představovat několik lidí. Počet osob v týmu závisí na velikosti projektu.

17

HyperText Markup Language, označovaný zkratkou HTML, je značkovací jazyk pro hypertext. Je jedním z jazyků pro vytváření stránek v systému World Wide Web.

31

Nebudu zde detailně rozebírat metodiku RUP krok za krokem, jelikoţ to není cílem této práce, ale zaměřím se na části, kde se střetávají zákazník s dodavatelem a samozřejmě popíši související aktivity. Nevím jaké přesně je povědomí a zkušenosti zákazníků, kteří vstupují do světa, kde se tvoří software na zakázku. Z mých vlastních zkušeností však mohu konstatovat, ţe zákazník bez jakýchkoliv předešlých zkušeností s vývojem softwaru na zakázku a dodavateli, kteří jej vyvíjejí, mívá představy značně zkreslené. V případě, ţe zákazník potřebuje software, který nelze běţně zakoupit, obrací se na dodavatele, který takový software vytvoří. Pokud pouţiji metodiku, která určuje stanovený postup tvorby softwaru, procesy a šablony, zjistím, ţe zákazník má jakousi představu, co by měl jeho software umět, moţná jak by měl vypadat a je pravděpodobně schopen o své představě sepsat několik bodů. V této metodice je to jeden ze základních dokumentů a je nazýván Vision (vize nebo představa) viz Příloha 1. Na začátku je třeba uvést, ţe metodika RUP prochází podobným ţivotním cyklem jako model vodopád, jak je patrné viz Obrázek č. 5, ale s tím rozdílem, ţe jednotlivé fáze jsou rozděleny do tzv. iterací. Iterativní vývoj je v této metodice jako jeden ze stěţejních procesů uvedených v tzv. „Best Practicies―. Iterace mohou trvat v závislosti na sloţitosti projektu zpravidla 6 aţ 12 týdnů. Na konci kaţdé iterace je spustitelná verze produktu. To je velice důleţité jak pro zákazníka, tak pro dodavatele. Na základě této verze je moţné odhalit rozpor mezi očekáváním zákazníka a vznikajícím produktem. Také je moţné na této verzi provádět testování z hlediska technologické způsobilosti, počtu chyb výkonu apod. Obrázek č. 5: Ţivotní cyklus metodiky RUP

Zdroj: vlastní úprava

Nyní se vrátím k zákazníkovi, který má svou představu o softwaru. V tomto bodě, pokud zákazník osloví dodavatele, vstupuje projekt do první fáze, která je označována jako počáteční fáze (Inception). V této fázi je nutné určit rozsah systému, který bude tvořit základ pro rozpočet a počáteční náklady. Odhady stanovené v počáteční fázi projektu 32

nejsou povaţovány za konečné. Jedná se pouze o orientační odhady, které se zpřesňují v dalších iteracích. V této fázi je stanoven obchodní cíl, v němţ jsou zahrnuty obchodní souvislosti. Zároveň je nutné v této fázi také ohodnotit rizika, odhadnout potřebné zdroje a naplánovat hlavní milníky, jejichţ dosaţením je vţdy fáze ukončena. V počáteční fázi je důleţité pro dodavatele identifikovat všechny zainteresované strany: řídící subjekty, zákazníky, potenciální uţivatele, partnery a dalších zúčastněné strany. Stručně popsat, co zainteresované strany dělají a jaké jsou jejich povinnosti s ohledem na vyvíjený systém. Práce s účastníky by měla zachytit seznam vlastností, které zúčastněné strany v systému poţadují, stručně popsat atributy a jejich pomocí definovat obecný stav a priority v rámci projektu. Tato činnost se v RUPu nazývá správa poţadavků (Requirements Management) a je jednou z dalších Best Practices. U správy poţadavků se musím pozastavit, neboť se jedná o jednu z nejdůleţitějších činností během vývoje projektu. Správa poţadavků je systematický přístup ke zjišťování, organizování a řízení měnících se poţadavků na systém a poţadavky jsou schopnosti nebo podmínky, které musí systém splňovat. Ve správě poţadavků je: a) jednotlivým poţadavkům přidělena priorita dle jejich povahy a vlastností, b) moţné objektivně odhadnout přínosy a náklady na jednotlivé poţadavky, c) mnohem snazší odhadnout nekonzistenci mezi poţadavky, d) snadné efektivně sledovat dopady jednotlivých poţadavků na proces vývoje, e) nutné věnovat pozornost všem poţadavkům během celého vývoje. Poţadavky se klasifikují metodou FURPS+ (16) a jsou rozděleny takto: a) funkčnost (Funkcionality) čili poţadavky na funkce systému (co bude systém dělat), b) pouţitelnost (Usability) obsahuje vlastnosti, jako je estetika a důslednost v uţivatelském rozhraní, c) spolehlivost (Reliability) se týká vlastností, jako je dostupnost (doba odezvy), správnost výpočtů, schopnost zotavit se z neúspěchu, d) výkon (Performance) jsou poţadavky na vlastnosti, jako je propustnost, doba odezvy, vyuţití času, času startu a času vypnutí, 33

e) podpora (Supportability) se zabývá vlastnostmi, jako jsou testovatelnost, adaptabilita, udrţovatelnost, kompatibilita, konfigurovatelnost, škálovatelnost a lokalizace, f) + , zkratka se pouţívá k identifikaci další kategorie, které obecně představují omezení, •

konstrukční poţadavek se často nazývá konstrukční omezení. Určuje nebo omezuje moţnosti vytvoření systému. Například pokud zadáte, ţe je nutná relační databáze, jedná se o konstrukční omezení,

•

implementace poţadavků určuje nebo omezuje kódování nebo výstavbu systému. Příkladem by mohly být poţadované standardy, implementace jazyků a omezení zdrojů,

•

poţadavky rozhraní specifikují externí poloţky, se kterými musí systém spolupracovat, nebo omezení na formáty či jiné faktory pouţité v takové interakci,

•

fyzický poţadavek specifikuje fyzikální omezení pouţité na pouţívaný hardware např. tvar, velikost nebo hmotnost (16).

Poměrně častý omyl, který souvisí s iterativním vývojem (do něhoţ spadá i metodika RUP) a správou poţadavků je, ţe na základě těchto dvou praktik by se mohl zákazník domnívat, ţe se v kaţdé iteraci mohou objevovat nové poţadavky. V tom případě by ovšem nebylo moţné, aţ do počátku poslední iterace přesně stanovit, co všechno má systém dělat. Tím by nebylo moţné řídit rizika a byla by tím potlačena hlavní myšlenka iterativního vývoje. V RUPu je doporučeno, v rámci počáteční fáze, definovat přibliţně dvacet procent poţadavků. V další elaborační fázi (Elaboration), která navazuje na počáteční, musíme specifikovat nejpřesněji co nejvíce poţadavků, přibliţně osmdesát procent. V konstrukční fázi (Construction) je moţné poţadavky revidovat nebo opravit. Také lze poţadavky změnit např. na základě změny vnějších okolností. V ţádném případě ale není přípustné, aby nastala situace, kdy ve fázi konstrukce přijde zákazník s dalšími novými klíčovými poţadavky. V takovém případě nastává důvod k pozastavení projektu a revidování jeho rozsahu. Ve fázi zavedení (Transition) se jiţ s poţadavky neoperuje. Nejlepší metodou pro získání těchto, pro projekt zásadních poţadavků, je osobní jednání se zúčastněnými stranami. Pak je moţné provést pohovor či brainstorming. Spolupráce tváří v tvář je nesmírně cenná a sniţuje šance projektového týmu na neporozumění potřebám zainteresovaných stran.

34

Kaţdý projekt má svou vlastní specializovanou terminologii a kaţdý z týmu musí rozumět a účinně komunikovat se zainteresovanými stranami. Během kontaktu účastníků se vytváří slovník, který definuje akronymy, zkratky a příslušné obchodní a technické termíny. Slovník se musí neustále rozšiřovat a zjemnit glosáři v celém ţivotním cyklu projektu. Na základě sezení zúčastněných stran a na základě poţadavků, se vytvářejí modely případů uţití, viz uţití, viz

Obrázek č. 6. Poţadavky nemusí být reprezentovány pouze graficky znázorněnými modely uţití, ale mohou být také zaznamenány v textové podobě. Nejlepším řešením je tyto modely popsat jak graficky, tak textově. Také je důleţité jiţ zahrnout omezení, která přináší dané prostředí. Těmi mohou být různé platformy nebo rozhraní stávajících systémů. Na závěr je prováděno přezkoumání efektivity poţadavků zúčastněnými stranami a vývojovým týmem s cílem zajistit dohodu o projektu, vizi, posouzení kvality a identifikovat potřebné změny.

Obrázek č. 6: Use Case (případ uţití)

Zdroj: dostupný z http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/resources/atm_uc_model_ inception.doc, [cit. 2.1.2009]

35

Na konci počáteční fáze je jeden z projektových milníků, který určuje rozsah systému (LCO – Lifecycle Objectives Milestone). Na tomto místě se prověří celoţivotní cíle projektu a rozhodne se, zda pokračovat v projektu, nebo jej zrušit. V tomto milníku musí být splněna kritéria: a) zákazník a dodavatel musí souhlasit s definicí rozsahu projektu, časovým a cenovým odhadem, b) dohoda o porozumění poţadavkům oběma zúčastněnými stranami (doloţeno přesností primárního případu uţití), c) dohoda, ţe odhady nákladů, priority, rizika, a harmonogram vývoje procesu jsou vhodné, d) všechna rizika byla identifikována a pro kaţdé existuje strategie jeho potlačení nebo zmírnění. Všechna tato kritéria musí být odsouhlasena společně zákazníkem i dodavatelem. Dalším krokem pro zákazníka a dodavatele je druhá fáze, do které projekt vstupuje odsouhlasením výše uvedených kritérií. Druhá fáze se nazývá přípravná (Elaboration). Dodavatel má v této fázi úkol navrhnout stabilní model architektury systému a to na základě pochopení celého systému, tj. rozsahu, funkčnosti a dalších poţadavků FURPS+. Dále se upřesní plán projektu a eliminují nejrizikovější části projektu. Při splnění těchto podmínek se upřesní čas potřebný pro dokončení a cena. Na konci této fáze je vytvořen jeden nebo několik prototypů. Tato část je nejrizikovější ze všech čtyřech fází a určuje, zda se bude pokračovat v projektu či nikoli. Architekturou systému můţe být např. v současné době hodně pouţívaná architektura intranet/internet, která je velice výhodná z důvodů: a) tenký klient, není třeba instalovat ţádné programy. Pro práci je pouţíván webový prohlíţeč a díky tomu má uţivatel k dispozici vţdy aktuální verzi, b) webová, aplikační a databázová vrstva soustředěná v jednom data-centru, která dokáţe obslouţit potencionálně neomezené mnoţství klientů, kteří k systému přistupují. Nevýhodou takového systému je, ţe musí být odolný vůči chybám a výpadkům. Být připravený na nepřetrţitý provoz bez servisních odstávek. Výpadek systému nebo jednoho

36

procesu snadno způsobí nedostupnost pro všechny uţivatele. Architekturu systému navrţenou dodavatelem musí zákazník odsouhlasit. V této fázi se dále upřesňují poţadavky na systém. Jak znázorňuje Obrázek č. 7, je zde zřejmé, jak probíhá v této fázi upřesnění modelů uţití. Při srovnání vyobrazení viz

Obrázek č. 6 a Obrázek č. 7 je patrné rozšíření modelu o další aktéry a prvky systému, které je nutno do modelu zahrnout. Toto rozšíření je také zaznamenáno do textové podoby modelu uţití. Tato upřesnění vznikají na základě dalších pohovorů se zúčastněnými stranami. V přípravné fázi by mělo být popsáno a definováno minimálně osmdesát procent případů uţití a model návrhu by měl pokrývat jiţ deset procent modelů uţití. Součástí upřesňování poţadavků je také, jak jsem jiţ zmínil, neustálé rozšiřování slovníku. Obrázek č. 7:Upřesnění Use Case modelu

Zdroj: dostupný z http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/resources/atm_uc_model_ elaboration.doc, [cit. 10.1.2009]

Dalším úkolem této fáze je upřesnění stanovení způsobu testování. Testy předchází ztrátám způsobeným chybami v programovém kódu. V předchozí fázi se identifikují testovací případy, coţ v praxi znamená, ţe je nutno ke kaţdému případu uţití připravit testovací scénář. Takové scénáře mohou být samotná testování, kde je software spuštěn a jsou v něm hledány chyby nebo inspekce, v níţ se prohlíţí programovací kód. Dalšími moţnými scénáři jsou ukázky, kde se představí systém a je testován, zda splňuje očekávání zákazníka nebo uţivatele. Analýza poţadovaného logického chování systému v různých 37

podmínkách je další moţností prověření softwaru. Tyto scénáře jsou prodiskutovány se zúčastněnými stranami a je dosaţeno dohody, za jakých podmínek bude test uspokojivý. Tato jednání by měl uzavírat dokument, který bude obsahovat seznam testovaných případů s jedinečným názvem a jejich identifikaci hodnocení nebo očekávaný výsledek viz Příloha č. 2. Testovací scénáře se připravují jiţ se sběrem poţadavků právě v počáteční fázi a ve fázi přípravné se dále zpřesňují. Můţe se zdát, ţe testování bude zatěţovat projekt svou časovou náročností, ale právě kvalitní testování zajistí v průběhu projektu, aby nebyl čas na vývoj zbytečně vynakládán na opravy jiţ hotových částí projektu. Proto by nemělo být testování postaveno do pozadí ani zákazníkem ani dodavatelem. Testy lze odvodit z mnoha zdrojů a obvykle zahrnují podmnoţinu poţadavků (jako jsou případy uţití, funkční vlastnosti a spolehlivost) a další druhy kvalitativních atributů viz testy podle FURPS níţe. Testovací úsilí je běţně rozděleno mezi vývojový tým a tým testerů, případně mezi další role. Pro roli testera je velice důleţité provést správný výběr osob, které se této role zhostí a budou se na testování podílet. Do této role jsou přiřazeni jak členové týmu ze strany dodavatele, tak ze strany zákazníka. Především v další konstrukční fázi projektu je důleţité, aby se testování účastnili koncoví uţivatelé ze strany zákazníka. Ti budou se systémem nejvíce pracovat. Tyto osoby by měly splňovat minimálně následující dovednosti a schopnosti (17): a) znalost testovacích postupů a technik, b) dovednost diagnostikovat a řešit problémy, c) znalost systému nebo aplikace, která se zkouší (vyţadováno), d) znalost sítí a systémové architektury (vyţadováno). Pokud je pouţíváno automatizované testování, je ještě vhodné zváţit tyto dodatečné schopnosti: a) znalost pouţívání automatizovaného testovacího nástroje, b) zkušenosti s pouţíváním automatizovaného testovacího nástroje, c) programovací dovednosti, d) dovednosti v ladění a diagnostice. Specifika kvalifikačních poţadavků se samozřejmě liší v závislosti na typu testování. Např. dovednosti potřebné pro správné pouţívání nástrojů zátěţového testování jsou odlišné od těch automatizovaných funkčních testování. 38

Do role testera je moţné přiřadit osoby následujícími způsoby: a) zaměstnanec je přiřazen k jednomu nebo více testům. Jedná se o poměrně standardní přístup a je zvlášť vhodný pro malé týmy stejně jako pro týmy o libovolné velikosti, kde tým tvoří zkušená skupina testerů relativně stejné úrovně dovedností, b) zaměstnanec je přiřazen k jednomu nebo více testům, ale vykonává pouze tuto roli. Tento způsob je vhodný a velmi dobře funguje ve velkých týmech. V tomto případě je také vhodné oddělit ostatní povinnosti zaměstnance od testování, pokud má více zkušeností s testováním a automatizací testů neţ ostatní členové týmu, c) přiřazení jednoho (nebo více) člena týmu, který jiţ má jinou roli v projektu. Bude odpovědný za testování schopností některých části systému. Tento člen týmu musí mít příslušné zkušenosti a dovednosti. Chování softwaru je jen těţko představitelné na základě analytických modelů anebo textových poţadavků, kterých můţe být u rozsáhlých systémů mnoho. Dalším velmi důleţitým bodem pro zákazníka a dodavatele je v této fázi projektu vytvořený prototyp. Na základě předchozích a současných poţadavků, jednotlivých modelů uţití a ošetření rizik dodavatel sestaví prototyp a představí jej zákazníkovi. Jak se uvádí v (12) jsou tyto prototypy velice důleţité pro získání dalších informací a doplnění mezer v chápání poţadavků zákazníka. Při představení prototypu je před zákazníka postavena maketa nebo první část nového systému, jenţ by měl v zákazníkovi probudit větší představivost a otevřít další diskuzi a především vyvolat zpětnou vazbu. To by v budoucnu mělo eliminovat riziko zákazníkovy nespokojenosti. Softwarovým prototypem můţe být například funkční model nebo statické návrhy, podrobné obrazovky i rychlé skici, videa apod. Prototypy jsou rozděleny na papírové a elektronické, a ty se ještě dělí na: a) horizontální se nesnaţí popsat celou architekturu systému, ale soustředí se především na uţivatelské rozhraní. Uţivatelům pomáhá odhadnout, zda by tento prototyp splnil jejich potřeby. V podstatě se jedná o představení několika uţivatelských obrazovek, které nemají ţádnou funkcionalitu, b) vertikální jsou průřezem aplikační funkcionalitou počínaje uţivatelským rozhraním a všemi technickými vrstvami systému konče. Tento prototyp je vhodný pro posouzení smysluplnosti a proveditelnosti zvolené architektury.

39

Výše uvedené prototypy mohou být jednorázové nebo evoluční. To v praxi znamená, ţe jednorázový prototyp bude vytvořen především v situacích, kdy je třeba se vypořádat s nejasnými nebo neúplnými poţadavky. Na základě jednorázového prototypu se sníţí riziko pozdější implementace. Nástroje pro navrhování jednorázových prototypů mohou být např. Microsoft Visio nebo Microsoft PowerPoint. Evoluční prototyp není oproti jednorázovému po jeho představení zahozen, ale stává se součástí vývoje systému a prochází společně s projektem inkrementálním vývojem, jak je zobrazeno viz Obrázek č. 8. Tento prototyp jiţ od začátku obsahuje kvalitní produkční kód a jeho vytvoření trvá mnohem déle neţ prototypu jednorázového. Obrázek č. 8: Začlenění prototypování do vývoje softwaru

Zdroj: převzato z (12) str. 218, [cit. 28.2.2009], vlastní úprava

Prototypy jsou, jak jsem jiţ uvedl, určeny především zákazníkovi a ten musí být schopen takový prototyp ohodnotit, aby tato část fáze byla přínosná. Je vhodné při takovém hodnocení pokládat uţivateli otázky typu:

40

a) nechybí v prototypu nějaká funkcionalita?, b) je navigace v prototypu logická a úplná?, c) jsou některé postupy zbytečně sloţité?, a další otázky, které pomohou správně prototyp ohodnotit a získat tím potřebné informace pro odhalení nesrovnalostí a sníţení rizik. Také je velice důleţité pro hodnocení prototypů vybrat správné lidi. Na základě vlastních zkušeností doporučuji vybrat z řady uţivatelů jak zkušené, tak nezkušené zástupce. Zkušení uţivatelé provádějí činnosti v posloupnostech, které od systému očekávají, ale nezkušení mohou mnohdy zvolit natolik nestandardní postup, kterým je moţné dosáhnout chyby v systému. Na konci této fáze je zpracován druhý významný mezník (LCA – Lifecycle Architecture Milestone). V tento moment je podrobně vymezen rozsah a cíle systému, výběr architektury a vyřešené rizikové faktory. Kritéria hodnocení tohoto milníku jsou: a) vize produktu a poţadavky stabilní a neměnné, b) stabilní architektura a nebude jiţ docházet k zásadním změnám, c) klíčové přístupy, které mají být pouţity při zkoušce a hodnocení prokázané, d) test a vyhodnocení spustitelného prototypu prokázaly, ţe hlavní rizikové faktory byly řešeny a spolehlivě vyřešeny, e) iterační plán pro fázi výstavby dostatečně podrobný a přesný, aby umoţnil postupovat v práci, f) v iteračním plánu pro fázi výstavby podporovány věrohodné odhady, g) všechny zainteresované strany se dohodly, ţe současná vize můţe být splněna v případě, ţe současný plán bude realizován na rozvoj celého systému, s navrţenou architekturou, h) skutečné zdroje výdajů jsou oproti plánovaným výdajům přijatelné. Tento milník musí opět odsouhlasit zákazník. Pokud není dosaţeno tohoto milníku, mělo by dojít k přerušení nebo přehodnocení projektu. Z obchodního hlediska je ideální jak pro zákazníka, tak pro dodavatele řešit elaborační fázi separátní smlouvou. V této části bych rád uvedl nástroj, který umoţňuje řídit a realizovat změny. Jedná se o změnové řízení. Jak je uvedeno v (18) změnové řízení můţe procházet všechny fáze projektu, ale především je spjato se správou poţadavků. Řízení změn v metodice RUP je jednou z dalších „Best Practices―. 41

Změnové řízení v praxi probíhá takto: a) identifikace - podněty ke změnovému řízení nejčastěji podává zákazník. Takové změny mohou být například zlepšení funkce systému. Návrhy na změny samozřejmě mohou přicházet i od analytiků a dalších zúčastněných stran na projektu. Některé poţadavky na změny mohou být hlášeny zákazníkem jako chyby a tak je nejlepší formou pro zařazení poţadavku do změnového řízení validace takového poţadavku. Tu provádí komise, která je oprávněna hlásit nové změnové poţadavky, b) ohodnocení, naplánování – tato aktivita je v kompetenci ředitele projektu na straně dodavatele systému. Plánování většinou stačí provést vzhledem k významným milníkům projektu, c) rozhodnutí o realizaci - podle metodiky RUP o realizaci daného změnového poţadavku rozhoduje orgán nazvaný Change Control Board. Podle velikosti projektu můţe tuto roli tvořit jediný člověk nebo několik zástupců obou stran projektu. Prostřednictvím změnových poţadavků je moţné rozsah projektu buď měnit (tj. nějaká funkčnost je přidána a jiná je odebrána), nebo rozšiřovat. V kaţdém případě zůstává finální rozhodnutí na zákazníkovi, d) realizace – v této fázi je poţadavek přidán do projektového plánu a neodlišuje se od ostatních realizovaných poţadavků, e) akceptace – stejně jako u ostatních částí díla musí zákazník akceptovat realizovanou úpravu systému. Jak je zobrazeno, viz Obrázek č. 9, projde ţádost na změnu během svého ţivota několika stavy. Uvedená kritéria by měla tvořit základní koncepci těchto stavů.

42

Obrázek č. 9: Ţivotní cyklus poţadavku na změnu

Zdroj: převzato z (12), [cit. 1.3.2009], vlastní úprava

Další fází projektu je konstrukční fáze (Construction), která je zaměřena především na implementaci. V této fázi se jiţ všechny komponenty a vlastnosti softwaru programují, testují a integrují do produktu. Úkolem dodavatele je především správně a efektivně řídit zdroje, kontrolovat a optimalizovat operace tak, aby byl dodrţen rozpočet, časový harmonogram a kvalita produktu. Na konci této fáze je samotné předání softwarového produktu nebo alespoň některé části, které můţe zákazník vyuţívat a jeţ je integrovaný na adekvátní platformě. Společně s tím jsou předány uţivatelské manuály a popis tohoto release. Zákazník se v této fázi podílí v roli poskytování lidských zdrojů pro testování a přebírání hotové části softwaru.

43

Testování můţe probíhat dle dělení typů testů, které odpovídají základním rozměrům kvality FURPS (19): a) funkčnost (Funkcionality), do této kategorie spadají testy zaměřené na testování funkčních poţadavků jako: •

Function test - test, zda jsou poskytovány funkčnosti uvedené v návrhu systému,

•

Security test - ověření přístupových práv k funkčnostem, popř. datům.

•

Volume test - testy stability a zachování všech funkčností při vysokém naplnění databáze,

b) pouţitelnost (Usability), kde jsou zahrnuty testy pouţitelnosti systému: •

Test uţivatelského rozhraní (GUI),

•

Testy on-line nápovědy,

•

Testy školících materiálů,

•

Testy uţivatelské dokumentace,

c) spolehlivost (Reliability), •

Integrity test - testy robustnosti systému (odolnosti proti selhání) po datové i funkční stránce,

•

Structure test - typicky testy webových rozhranní (chybné odkazy, chybějící stránky, osamocené stránky apod.),

•

Stress test - ověření stability a funkčnosti systému při nestandardních podmínkách (sníţení operační paměti aplikačního serveru, omezené sdílení hardwarových i softwarových prostředků apod.),

d) výkon (Performance), měření výkonu systému: •

Performance profile - klasické výkonnostní testy systému (měření odezev), nalézání výkonnostně slabých míst systému (tzv. "úzká hrdla"),

•

Contention test - test toho, zda přístup více uţivatelů (popř. jiných systémů) umoţňuje současně přistupovat k sdíleným prostředkům (HW i SW) při zachování funkčnosti systému,

•

Load test - test chování a výkonu systému pod vysokou zátěţí (vysoký počet současně pracujících uţivatelů),

•

Benchmark test - porovnání výkonnosti systému v referenčním prostředí,

44

e) podpora (Supportability), •

Configuration test - ověřujeme, zda systém bude fungovat i na jiných přípustných HW / SW konfiguracích, neţ jaké jsou nastaveny v současném testovacím (popř. produkčním) prostředí,

•

Instalation test - test korektní instalace na různé HW / SW konfigurace, testy kompletní instalace, updatu apod.

Testy lze dále dělit z hlediska časového pohledu: Unit test Unit test je první a velmi důleţitá fáze. Probíhá na straně vývojového týmu a v praxi představuje fakt, ţe vývojář po dokončení unity (use casu, komponenty apod.) svou práci otestuje. Je zřejmé, ţe tento typ testu probíhá většinou úplně samozřejmě a intuitivně. Integrační test Integrační test je ověřením skutečnosti, ţe unity dodané vývojovým týmem lze integrovat, tj. vytvořit funkční build. Jinými slovy, pokud se podaří integrátorovi (členovi vývojového, resp. integračního týmu) sestavit build, je integrační test proveden. Smoke test Tento typ testu ověřuje stabilitu buildu. To je nutné především pro zajištění proveditelnosti následného hloubkového systémového testu. Eliminujeme tím situaci, kdy po zapojení většího počtu testerů systém selţe a není moţné v testech pokračovat. Systémový test Systémový test představuje hloubkový test systému, při kterém se zpravidla provádějí téměř všechny typy testů (FURPS – viz výše). Velmi důleţitou vlastností systémového testu je regresnost. Regresním testem nazýváme takový test systému, při kterém jsou kromě nově přidaných funkčností testovány i všechny funkčnosti přidané v dřívějších buildech.

45

Akceptační test Uţivatelské akceptační testy jsou zaměřeny na testování standardních i méně standardních situací v systému. Testy provádí koncový uţivatel na vlastním testovacím prostředí. Tím je do vysoké míry zaručena reálnost testovaných situací. Podle metodiky RUP je kaţdý provedený test zaznamenán do tzv. test logu. Záznamy v něm jsou uchovány z důvodu pozdějšího dohledání, který test jiţ byl proveden a jak byl vyhodnocen. V test logu se uchovávají výsledky jak z manuálních testů, tak z testů automatizovaných. Další iterace v této fázi projektu slouţí převáţně k návrhu a implementaci další funkcionality systému. Výstupy na základě této fáze jsou: a) vytvoření první funkční verze vyvíjeného softwaru, b) existuje plán nasazení první verze, c) je vytvořena první uţivatelská dokumentace, d) je stanoven plán iterací pro poslední fázi předávání, e) existuje celková specifikace datového modelu. Třetím milníkem této fáze je (IOC - Initial Operation Capability milestones) nebo „Beta milestone―. Podmínkami jsou: a) produkt je dostatečně stabilní, aby je bylo moţné poskytnout uţivatelům, b) zákazník je připraven k nasazení systému. Pokud produkt některé tyto podmínky tohoto milníku nesplní, je vhodné odloţit předání produktu o jednu verzi. Poslední čtvrtou fází metodiky RUP je fáze nasazení (Transition). V této fázi je software nebo informační systém předáván zákazníkovi. Činnosti nejvíce spojené s předáním jsou následující: a) uţivatelské akceptační testy nebo beta testy slouţící k validaci produktu uţivatelem, b) hladké provedení přechodu z dosavadního softwaru s případnou konverzí pouţívané databáze, c) zaškolení uţivatelů a správců nového softwaru. 46

Po předání obvykle následují operativní řešení nalezených problémů a reakce na připomínky uţivatelů, případně dokončení funkčností, které byly doposud odkládány. Reakce zákazníka a uţivatelů by však měla směřovat k doladění produktu nikoli novým poţadavkům a změnám funkcionality. Poţadavky zákazníka se musí týkat pouze instalace, konfigurace a odstranění drobných chyb zjištěných při testovacím provozu. V případě, ţe vyvíjený produkt zatím nemá konkrétního zákazníka, je namísto zadavatele prováděno předání produktu marketingovým a distribučním týmům. U softwarových projektů je vhodné smluvně upravit přejímací testy, při nichţ se testuje předávaná verze systému pomocí určené série testů. Tyto testy mohou vycházet z jiţ stanovených testovacích scénářů, které vznikly v předchozích fázích. Před ukončením fáze je nezbytné splnit podmínky milníku (GA - Product Release milestone). Tyto podmínky jsou: a) ujistit se, ţe uţivatel je s produktem spokojen, b) zda uskutečněné výdaje nepřekračují naplánované výdaje. Pro dodavatele softwaru v tomto období začíná poinstalační podpora, která je stanovena na základě řady návrhů pro zlepšení softwaru předkládaných uţivateli a zákazníky. Tyto návrhy vznikají po nasazení do rutinního provozu a podrobném seznámení. V závislosti na závaţnosti připomínek je dále rozhodnuto, zda bude zahájen nový projekt a vytvoří se další verze celého software či bude stačit provést úpravy některých komponent.

47

3.

Vztahy mezi zákazníkem a dodavatelem při

vývoji agilními metodikami Většina technik byla svými autory pouţívána jiţ dříve, samotný název a vznik agilního přístupu je datována k únoru 2001, kdy se setkalo sedmnáct odborníků z oblasti vývoje software a softwarového inţenýrství, např. Jeff Sutherland, Jim Highsmith, Kent Beck, Mike Beedle, Ward Cunningham, Alistair Cockburn, Martin Fowler, Ken Schwaber a projednávali budoucí trendy v oblasti softwarového vývoje. Všimli si, ţe jejich různé metody měly mnoho společných vlastností. Důsledkem tohoto jednání byl vznik Agile Alliance a její manifest pro agilní vývoj softwaru. Agilní metodiky obecně prosazují projektové řízení procesu, který podporuje častou kontrolu a úpravy. Hlavní filozofie je podpora týmové práce, přizpůsobivost a zodpovědnost, coţ je sada osvědčených postupů, které umoţňují rychlé dodání vysoce kvalitního softwaru. Dále také obchodní přístup, který harmonizuje vývoj s potřebami zákazníků a firemních cílů.

3.1 Agilní metodiky Změna softwarového trhu od jeho počátku dosáhla takových změn, ţe například vývoj webových aplikací je natolik jednoduchý, ţe vytvořit průměrnou internetovou prezentaci dokáţe kaţdý, kdo trochu lépe ovládá práci s aplikacemi jako je např. Microsoft Word. Dnes jiţ existují specializované nástroje pro vytváření webových stránek, s jejichţ pomocí se vytváří tyto prezentace především vizuálně a nikoliv psaním kódu jako dříve. Tím odpadá znalost tohoto kódu a nároky na ty, kteří tyto webové prezentace vytváří. Samozřejmě sloţité aplikace a především dynamické aplikace nebo online aplikace vyţadují daleko hlubší znalosti této problematiky. Podstatou je, ţe na trhu s vývojem softwaru vznikla během posledních let taková konkurence, ţe vývoj softwaru začal klást větší důraz na rychlý vývoj a nízkou cenu. Firmy, které v současnosti poţadují od dodavatelů vývoj softwaru za těchto podmínek, nezajímají detailně zpracované analýzy, obsáhlé dokumentace apod. Jediné, co tyto firmy a potencionální zákazníky zajímá, jsou jejich obchodní cíle, jimiţ mohou rozšířit skupiny svých zákazníků, zvýšit prodej nebo zjednodušit obchodní procesy. Tento software musí být pro zákazníka vytvořený rychle, aby firma získala konkurenční výhodu a tím částečně naplnila své závazky.

48

Díky zrychlení trhu se softwarem a potřebě jeho rychlejšího vývoje, začaly být po roce 2000 vytvářeny metodiky a nástroje, které umoţnily rychlejší a snadnější vývoj softwaru. Přitom dokázaly pruţně reagovat na změny. Začalo se jim říkat agilní. Název vznikl z anglického překladu agile, coţ znamená hbitý, čilý, bystrý nebo sviţný. Obrázek č. 10 zobrazuje, jak se liší agilní pojetí vývoje softwaru od tradičního pojetí. Obrázek č. 10: Rozdíl tradičního a agilního pojetí vývoje software

Zdroj: dostupný z http://leadinganswers.typepad.com/.shared/image.html?/photos/uncategorized/2007/05/05/flip_triangle.jpg, [cit. 10.3.2009], vlastní úprava

Tradiční metodiky mají jako fixní veličinu funkcionalitu, kterou stanovují pevné specifikace poţadavků, jenţ se musí dodrţet. Čas a zdroje jsou hodnoty proměnné a mění se podle vývoje produktu. Agilní metodiky mají jako fixní proměnné čas a zdroje, coţ jsou finance, lidi, prostředí, ve kterém se software vyvíjí a další. Funkcionalita je u agilních metodik nastavena jako proměnná hodnota. Z důvodu nastavení těchto proměnných je u tradičních metodik běţné překročení termínů dodání a navýšení finančních nákladů. Agilní metodiky mohou naopak právě díky tomuto nastavení implementovat jen části funkcionalit a další funkcionality upravovat a vylepšovat za provozu. Z tohoto hlediska jsou pro zákazníka agilní metodiky přínosem. Zákazník můţe pracovat, sice na neukončené aplikaci, která se bude neustále vyvíjet během provozu, ale nemusí čekat na ukončení vývoje a na úplné doladění softwaru, jak tomu je u tradičních metodik. Nedokončená aplikace znamená pouze to, ţe nebyly implementovány některé funkce. U těchto funkcí byla stanovena priorita jako nejniţší. Ty byly takto ohodnoceny zákazníkem ve spolupráci s vývojovým týmem. Zákazník tím tedy akceptuje nastavení těchto priorit. Jedna z nejdůleţitějších pouček týkající se agilního programování, vznikla z poznatků, ţe jedinou cestou, jak prověřit správnost navrţeného systému, je co nejrychleji jej vyvinout, předloţit zákazníkovi a podle zpětné vazby upravit. 49

Principy agilního programování společné pro všechny metodiky jsou: a) iterativní a inkrementální vývoj s krátkými iteracemi. Iterace jsou krátké časové rámce (známé jako „timeboxes―), které obvykle trvají od jednoho do čtyř týdnů, b) vývoj probíhá v krátkých fázích, takţe celková funkcionalita je dodávána po částech. Zákazník tak má moţnost průběţně sledovat vývoj, můţe se k němu vyjádřit a oponovat změny. Na konci má jistotu, ţe nedostane něco, co neočekával, c) komunikace mezi zákazníkem a vývojovým týmem, d) v ideálním případě je zákazník přímo součástí vývojového týmu, má moţnost okamţitě vidět průběţné výsledky a reagovat na ně. Účastní se sestavování návrhu, spolurozhoduje o testech a poskytuje zpětnou vazbu pro vývojáře, e) průběţné automatizované testování, f) díky krátkým iteracím se aplikace mění velice rychle, proto je nutné pro zajištění co nejvyšší kvality ověřovat její funkčnost průběţně. Testy by měly být automatizované, předem sestavené a měly by být napsány ještě před samotnou implementací testované části. Při kaţdé změně musí být aplikována kompletní sada testů, aby nebyla porušena integrace jednotlivých částí. Výše uvedené principy jsou součástí Manifestu agilního programování, který popisuji v následující kapitole. Obrázek č. 11: Spektrum plánovacích metod

Zdroj: dostupný z http://www.agilealliance.org/system/article/file/923/file.pdf, [cit. 1.12.2008], vlastní úprava

Na obrázku, viz Obrázek č. 11, který byl publikován Barry Boehmem v (20), jsou agilní metodiky v tomto rozsahu na levé straně směrem od středu, to znamená, jak jiţ bylo zmíněno, větší adaptibilitu, flexibilnost, řízení změnami a nikoli předem daným plánem. 50

V (21) se pokusil Juhani Warsta and Pekka Abrahamsson porovnat open source, agilní a plánem řízené metodiky. Porovnání těchto tří způsobů vývoje softwaru v jednotlivých oblastech je uvedeno viz Tabulka 1. Tabulka 1: Srovnání agilních a plánem řízených metodik Oblast

Agilní metodiky

Open source software

Metodiky řízené plánem

Vývojáři

Agilní, zkušení, spolupracující a soustředění na jednom místě Nadšení, zkušení, soustředění, spolupracující, reprezentativní a zmocnění Převáţně neurčité, rychle se měnící

Geograficky oddělené, zkušené, spolupracující, agilní týmy

Orientovaní na plán, potřebné schopnosti, přístup k externím znalostem Přístup ke schopným, spolupracujícím, reprezentativním a zmocněným zákazníkům

Zákazníci

Poţadavky

Architektura

Navrţená pro aktuální poţadavky

Refaktoring Velikost

Levný Menší týmy a produkty

Primární cíl

Rychlý výsledek

Nadšení, schopní, spolupracující a zmocnění Převáţně neurčité, rychle se měnící, vlastněné společně, průběţně se vyvíjející, nikdy úplné Otevřená a navrţená pro aktuální poţadavky Levný Větší rozptýlené týmy a menší produkty Řešení problému

Známé brzy, většinou dlouhodobě stálé

Navrţená pro současné i předpokládané poţadavky Drahý Větší týmy a produkty Vysoká spolehlivost

Zdroj: dostupný z http://agile.vtt.fi/docs/publications/2003/2003_oss.pdf, [cit. 3.12.2008], vlastní úprava

Jak vyplývá z uvedené tabulky, nejvíce se metodiky odlišují v přístupu k poţadavkům, kde agilní metodiky reflektují neurčité a rychle se měnící poţadavky oproti tradičním. U tradičních metodik musí být poţadavky známé jiţ v počátku projektu a pokud moţno během projektu neměnné. Agilní metodiky se soustředí především na týmovou spolupráci a zákazníka, který by měl být v ideálním případě plnohodnotnou součástí týmu a sdílet s vývojáři stejné prostory, aby byla komunikace pruţnější a efektivnější. V agilních metodikách je vyvíjena pouze funkcionalita, kterou zákazník označí jako potřebnou v daném okamţiku. Po rychlém vývoji je předána zákazníkovi, který poskytne zpětnou vazbu, na jejímţ základě se aplikace modifikuje. Agilní je tedy označen především takový vývoj softwaru, který je inkrementální (přírůstkový, dodávaný po menších částech), kooperativní (spolupráce a komunikace mezi vývojáři a zákazníkem je velice aktivní) a adaptivní (dokázat aktivně reagovat na poţadované změny v průběhu projektu).

51

3.2 Manifest agilního programování Manifest agilního programování je zaloţen na několika principech: a) jednotlivci a komunikace místo procesů a nástrojů, b) fungující software místo komplexní dokumentace, c) spolupráce se zákazníkem místo sjednávání smluv, d) reakce na změny místo dodrţování plánu. Prakticky ţádná agilní metodika, stejně jako tradiční, není striktně daná kuchařka zaručených a ověřených postupů. Vţdy je nechán prostor pro přizpůsobení metodiky konkrétnímu projektu. Jinak by daná metodika ani nemohla být povaţována za agilní, protoţe slovo „agilní" má velice blízko k „flexibilní", tedy přizpůsobivý. To je přesná aplikace jednoho z doporučení agilního vývoje. Raději neţ abychom se snaţili vytvořit vše objemnou univerzální metodiku, která bude vyhovovat kaţdému projektu, zákazníkovi i vývojáři, vytvořme metodiku jednoduchou, lehkou a flexibilní, kterou pak budeme moci přizpůsobit danému konkrétnímu problému. To nás opět vede k jednomu ze základních tvrzení agilního programování, které říká „programujme jen to, co je v této chvíli nezbytně nutné, nic navíc, do řešení by se mělo zahrnout jen to, co prokazatelně potřebuje kaţdý, nikoli to, co moţná bude někdy někdo potřebovat" (22).

3.3 XP Extrémní programování Tato metodika byla představena zveřejněním knihy se stejným názvem Extreme Programming Explained (23). Představil jí Kent Beck 18v roce 2000. Kent Beck zde uvedl, jak si myslí, ţe by se měl správně vyvíjet software. Tyto názory byly podloţeny jeho mnohaletými zkušenostmi a účastí v řadě projektů. Kniha vzbudila mezi softwarovými profesionály (především ve Spojených státech) velký rozruch. Mnoho lidí se přihlásilo k myšlenkám XP, coţ vedlo ke vzniku pojmu "agilní metodiky" a také k Manifestu agilního softwarového vývoje. Vzniklo tak celé hnutí softwarových profesionálů, kteří se snaţili ovlivnit vnímání a praktiky softwarového

18

Kent Beck je programátor a jeden ze tří autorů agilního procesu zvaného extrémní programování.

52

inţenýrství. Samozřejmě následovala řada dalších knih (např. (23) nebo (24)), webových stránek (25), konferencí apod. Podobně jako metodika RUP má i metodika XP své doporučené praktiky. Ty jsou souborem myšlenek a postupů, na jejichţ základě lze realizovat tvorbu softwarového produktu agilním přístupem viz Obrázek č. 12. Původní praktiky uvedené v (23) byly později rozšířeny v (26) a jsou jimi: a) soustředění na tým (Whole Team), b) plánovací hra (Planing Game), c) testování zákazníky (Customer Tests), d) malé distribuce (Small Releases), e) jednoduchý design (Simple Design), f) programování ve dvojicích (Pair Programming), g) návrh řízený testy (Test-Driven Development), h) kvalita kódu (Refactoring), i) průběţná integrace (Continuous integration), j) společné vlastnictví kódu (Collective Ownership), k) programátorské standardy (Coding Standards), l) metafora (Metaphor), m) čtyřicet hodin týdně (fourty hour week), n) práva manaţerů a zákazníků, o) práva vývojářů. Tyto doporučené praktiky představují stěţejní body XP a byla na nich tato metodika zaloţena.

53

Obrázek č. 12: Doporučené praktiky XP

Zdroj: dostupný z http://www.xprogramming.com/images/circlesthumb.jpg, [cit. 20.3.2009]

Metodiku je moţné rozdělit do dvou základních rovin jako: a) proces softwarového inţenýrství, z jehoţ pohledu nabízí tato metodika návod k přiřazování úkolů a odpovědností v týmech a organizacích, jeţ se zabývají vývojem softwaru. Tento návod by měl zajistit očekávanou kvalitu softwaru, splnění termínů a dodrţení rozpočtu. V tomto procesu je pohled na vývoj softwaru ještě dále rozdělen do tří úrovní: •

sociální, která odlišuje tuto konkrétní metodiku od ostatních agilních metodik a to tím jak klade obrovský důraz na mezilidské vztahy a komunikaci. Na tomto základě pak hodnotí moţnosti úspěchu či neúspěchu projektu,

•

statickou, která jako v metodice RUP podporuje artefakty, které jsou pro vývoj důleţité,

•

dynamickou, která určuje ţivotní cyklus celého projektu,

b) procesní framework, který je spíše myšlenkovým proudem neţ produktem, na němţ by bylo moţné systematicky stavět. Obdobně jak tomu bylo u metodiky RUP, je i tato metodika zpracována jako software, jenţ obsahuje rozsáhlou znalostní databázi přístupnou hypertextovými odkazy odkazujícími na podrobné popisy pro různé typy činností. Ty jsou dostupné jako HTML dokumenty a je tedy moţné s obsahem pracovat v jakémkoliv dostupném webovém prohlíţeči. Další předností této metodiky jsou uvnitř obsaţené šablony pro všechny procesní artefakty. 54

Díky těmto vlastnostem je tato metodika vţdy v aktuální verzi dostupná všem členům vývojového týmu. Těmito členy týmu jsou: a) kouč (Coach) je podpůrnou rolí, která pomáhá týmu zůstat v procesu z metodického hlediska a pomáhá týmu se učit. Kouč musí mít dovednosti s jednáním s lidmi a být efektivní v ovlivňování činnosti týmů, b) zákazník (Customer) má úlohu odpovědně definovat, co je tím pravým produktem pro sestavení. Určuje pořadí, ve kterém se funkce budou programovat, zjišťuje, zda produkt skutečně funguje, c) programátor (Programmer) je zodpovědný za implementaci kódu na základě uţivatelských poţadavků, d) programátor administrátor (Programmer Administrator) je zodpovědný za řízení programátorských prací, e) dozor (Tracker), tato role má na starosti tři základní věci a těmi jsou plány nasazení uţivatelských poţadavků, iterační plán a akceptační testy. Můţe také sledovat další ukazatele, které mohou pomoci při týmových řešeních. Dobrý Tracker musí mít schopnost shromaţďovat informace bez významného narušení procesu, f) tester (Tester), jeho primární odpovědností je pomáhat zákazníkům definovat a provádět zkoušky pro přijetí uţivatelských poţadavků. Tester je zodpovědný za chod zkoušek a informování celého týmu o výsledcích zkoušek. Výše uvedené role jsou v metodice XP popsány jako základní. Tyto role mají mnohem širší záběr neţ v metodice RUP, kde pouze jedna osoba určená do některé z rolí má znalosti o specifických a kritických částech systému nebo technologie. Úlohy, které jsou určeny, obvykle realizuje jednotlivec nebo skupina jednotlivců, kteří pracují společně jako tým. V tomto týmu obvykle jeden člen plní několik různých úloh. Soustředění na tým je v metodice XP vůbec jednou z nejstěţejnějších doporučených praktik. Vytvoření správného sloţení týmu je zde povaţováno za klíčovou vlastnost pro úspěšné dokončení projektu. Nejpodstatnější změnou v týmovém sloţení je účast zákazníka v projektovém týmu. Ta by měla být nejlépe takovou formou, kde zákazník bude přímo sdílet prostory s vývojovým týmem dodavatele. Tím by měla být zajištěna rychlá a levná komunikace, včasné odhalení problémů a chyb. Pokud toto není moţné, měl by zákazník počítat s velmi

55

častým kontaktem dodavatele. Nahrazení zákazníka analytikem nebo ředitelem projektu se proces vývoje zpomalí, protoţe není moţno pruţně reagovat. Podobně jako jsem popisoval u metodiky RUP, i zde začíná projekt a jeho fáze tím, ţe zákazník osloví některého z dodavatelů softwaru. Nyní nastává fáze, která se v XP nazývá průzkum (Exploration) viz Obrázek č. 13. V této fázi projektu, která je zaměřena především na vytvoření základních artefaktů se definuje rozsah projektu. Zákazníci by měli také v této metodice vytvořit vizi svého softwaru. XP Vision je jedním ze základních artefaktů této metodiky a slouţí jako vodítko pro tým v průběhu vývojového cyklu. V této vizi zákazník stanoví poţadavky na velmi vysoké úrovni. Poţadavky musí být jednoznačně a stručně formulované. Podrobnost uţivatelských poţadavků je jen do té míry, aby bylo moţné bez většího rizika rozhodnout, jak dlouho bude trvat implementace. Ke kaţdému poţadavku se zároveň stanoví testovací scénář. Ty jsou společně projednány s týmem tak, aby se obě strany dohodly na shodě o produktu. Obrázek č. 13: Ţivotní cyklus XP projektu

Zdroj: dostupný na http://www.extremeprogramming.org/rules/commit.html&prev=_t&usg=ALkJrhjB1orq9u5WH lghNGYpJhZphPfDFg, [cit. 7.3.2009], vlastní úprava

Vize bude vodítkem pro tým v průběhu celého vývojového cyklu. Programátoři dodavatele v této fázi zkoumají technologie. Tato fáze by měla být velmi krátká. V praxi tato fáze vypadá tak, ţe zákazník popisuje poţadavky v tzv. „User Stories― společně s týmem dodavatele a vysvětluje podmínky, za kterých budou poţadavky 56

povaţovány za úplné. Vývojáři tyto poţadavky ohodnotí na základě svých zkušeností a snaţí se navrhnout nejjednodušší řešení. Pokud nebudou vývojáři schopni udělat rozumný odhad, měli by poţadovat od zákazníka více informací. Pokud budou poţadavky od zákazníka příliš rozsáhlé, musí se rozdělit na menší celky. Jestliţe nebudou schopni určit správnou cestu vývoje, musí provést šetření. Při setkáních zákazníka s vývojáři se nekomunikuje specifickými vyjadřovacími prostředky pro obor vývojářů nebo spadajícím do obchodního rámce zákazníka. Pouţívá se tzv. „metafora― jíţ se snaţí tým popsat technické uspořádání systému. Mělo by jít o neformální a kaţdému snadno pochopitelný popis. Metafora pomáhá při identifikaci částí, které by byly jinak špatně pojmenovány, a tím hraje významnou roli v komunikaci mezi zákazníkem a dodavatelem. Další fází projektu je plánování (Planning). Poté, co mají všechny poţadavky určeny odhadované náklady, můţe zákazník priorizovat poţadavky pro plán vydávání distribucí (release plan). K tomuto účelu jsou pořádány mítinky, kde zákazník stanoví, který z poţadavků má pro něj nejvyšší prioritu. Vývojáři odhadnou, jak dlouho bude trvat implementace. Poţadavky zákazníka jsou tištěné nebo napsané na kartičkách, které jsou společně s vývojáři přemísťovány tak, aby vytvořily sady poţadavků, které mají být implementovány dříve či později. Vybraný systém musí být pouţitelný, testovatelný a zároveň mít smysl z obchodního hlediska. Plán vydávání distribucí je podkladem pro tvorbu plánu iterací pro kaţdou iteraci. Další distribuce jsou plánovány s předstihem v souladu s pravidly iterativního vývoje. Základní filozofií plánu distribucí je kvalifikace projektu do čtyř proměnných: a) rozsah – co je třeba udělat, jaké funkce mají být implementovány, b) zdroje - kolik lidí bude k dispozici, c) čas - kdy bude projekt nebo distribuce hotová, d) kvalita - jak dobrý bude software a jak dobře bude testován. Při plánování je důleţité, aby technici rozhodovali o technických problémech a zákazníci o business problémech. Součástí této fáze jsou také jiţ v RUPu zmíněné prototypy, které zajišťují okamţitou zpětnou vazbu od zákazníka a tím včasnému předcházení chyb a nedorozumění při implementaci. Prototypování s sebou také přináší svá rizika a nevýhody. V (12) je jich několik uvedeno. Jednou z nich můţe být, ţe se zákazník příliš upne k prototypu a bude ho 57

především zajímat, jak systém vypadá, neţ aby se soustředil na otázku co má systém řešit. Z praxe vím, jak ukázka prototypu podněcuje zákazníka k neustálé snaze o vylepšování a doplňování systému o další funkcionality, které jej bez náhledu na prototyp nenapadli. To je samozřejmě nutné omezit v rámci změnového řízení, které prochází schvalováním poţadavků nebo upozornit zákazníka, ţe tyto poţadavky jiţ nespadají do rozsahu projektu a můţou být zařazeny třeba do fáze údrţby, kde budou doimplementovány. Dalším rizikem prototypování můţe být, ţe zákazník bude podle rychlosti prototypu usuzovat rychlost výsledného modelu. Horizontální prototypy nejsou zkoušeny v provozním prostředí a mohou být napsané pomocí nástrojů, jejichţ efektivita se liší od produkčních nástrojů (např. namísto překládaného kódu jsou pouţity interpretované skripty). Vertikální prototypy zase nemusí obsahovat odladěné algoritmy nebo bezpečnostní vrstvy, které budou sniţovat výsledný výkon. Posledním zmíněným rizikem je vkládání přílišného úsilí do vytvoření prototypu a tím sníţení času na implementaci. Na základě těchto rizik je nutné si uvědomit, ţe je vhodné prototypovat jen do té míry, aby byly ověřeny hypotézy a zodpovězeny otázky, které je nutné pro upřesnění poţadavků zákazníka. Následuje fáze iterace vedoucí k distribuci (Iterations to Release). V této části je čas projektu rozdělen do krátkých iterací v rozmezí jeden aţ tři týdny. Délka iterací by měla být po celou dobu projektu stejná. To umoţní snazší odhad měření pokroku v projektu a také jednodušší a spolehlivější plánování. Pro kaţdou iteraci se vybírají poţadavky, které byly zahrnuty v plánu distribucí. Tato fáze zahrnuje i testování. To je reprezentováno akceptačními testy, které provádí zákazník. V extrémním programování byly nahrazeny funkční testy právě testy akceptačními, protoţe to lépe odráţí záměr, který má zaručit, ţe byly splněny zákaznické poţadavky a systém je přijatelný. Akceptační testování jsou Black box systémové testy. Realizuje se bez znalosti vnitřní datové a programové struktury, coţ znamená, ţe tester nemá k dispozici ţádnou dokumentaci, binární ani zdrojové kódy. Tento způsob testování vyţaduje testovací scénáře, které jsou buď poskytnuty testerovi, nebo si je tester u některých typů testů sám vytváří. Vzhledem k tomu, ţe jsou obvykle definovány typy a rozsahy hodnot přípustných a nepřípustných pro danou aplikaci a tester ví, jaký zadal vstup, tak i ví jaký výstup nebo chování můţe od aplikace očekávat, viz (27). Black box testy mohou probíhat ručně nebo automatizovaně za pouţití nejrůznějších nástrojů. Obrázek č. 14 ukazuje schéma automatického testu, kde se testují scénáře přidání, odebrání a zadání nesprávné hodnoty pro atribut „name―. Test provede automatický záznam výsledků do logu. 58

Obrázek č. 14: Schéma automatického testu

Zdroj: dostupný z http://www.xprogramming.com/images/Image1.gif, [cit. 30.3.2009]

Kaţdá iterace produkuje řešení pro sadu uţivatelských poţadavků. Během iterace se musí dodavatel soustředit na splnění poţadavků, které vybral zákazník místo nedokončených poţadavků vybraných vývojáři. V rámci iterací jsou řešeny konflikty a odchylky od původního plánu. Zavedení (Productionizing) je fáze, kde se dodavatel společně se zákazníkem soustředí na ověření spolehlivosti, výkonnosti a správnosti vytvořeného řešení. Cílem této fáze je nasadit produkt do ostrého provozu. Produkt by měl být uvolňován v malých částech (Small Releases) pokaţdé, jak je to moţné. To zajistí okamţitou zpětnou vazbu od zákazníků, kteří vidí, ţe se něco děje a to je vede k důvěře. Small Releases jsou jednou z doporučených praktik. XP obsahuje další doporučené praktiky, které se vztahují k celému vývoji a tím ho znatelně odlišují od tradičních metodik. Jsou také velice důleţité k pochopení fungování celé metodiky, proto bych ještě některé popsal: a) párové programování (Pair Programming). Tato doporučení vychází ze skutečnosti, ţe dva programátoři uvaţují rychleji neţ jeden. Zakládá se na programování dvěma programátory, přičemţ jeden programuje a druhý kontroluje, zda se kód neodchyluje od stanoveného cíle, chyby v návrhu, dohodnuté standardy, b) jednoduchý návrh (Simple Design). V XP je důleţité udrţovat návrh architektury co nejjednodušší a vyvarovat se budoucím vlastnostem, které nebudou nikdy pouţity, 59

c) refactoring (kvalita kódu) nahrazuje absenci formální analýzy a návrhu. Doporučení XP nabádá programátory k povinnosti trvale dbát o kvalitu kódu. V praxi při nalezení části kódu, který obsahuje chyby nebo nedostatky, musí programátor najít čas na opravu takového kódu. Také čištění a udrţování přehlednějšího kódu zajistí v pozdějším stádiu jednodušší údrţbu. Úprava kódu však nesmí způsobit změnu jeho chování, d) programátorské standardy (Coding Standards). Tím, ţe XP tým dodrţuje společný standard kódování, celý kód v systému vypadá, jako kdyby byl napsán jedním programátorem. Je snadnější jej upravovat a opravovat bez nutnosti rozsáhlé dokumentace. Takto vytvořený kód je vhodný pro podporu společného vlastnictví, e) společné vlastnictví kódu (Collective Ownership). Kód je společně vlastněn a upravován všemi členy týmu, proto je nutné dodrţovat výše uvedené standardy v psaní kódu. Nezbytnou nutností pro společné vlastnictví kódu jsou nástroje pro řízení konfigurací a správu verzí, f) návrh řízený testy (Test-Driven Development). Extrémní programování je závislé na zpětné vazbě a k té patří i testování. Pokud se netestuje nebo není k některému poţadavku napsaný test, jako by poţadavek nefungoval. V podstatě by měl být napsaný test ještě před začátkem psaní kódu (pokud to programovací jazyk umoţňuje). Kaţdý test musí dosáhnout stoprocentní úspěšnosti. Test části kódu, pro který byl napsán, je spouštěn i po implementaci části testovaného kódu do většího celku. I poté musí být test stoprocentně úspěšný. Kromě toho tyto testy poskytují neocenitelnou podporu pro zlepšování softwarového návrhu.

60

4.

Případová studie

Pro případovou studii jsem si vybral projekt CIS, kterého jsem se účastnil v roce 2003 – 2004 jako člen týmu zákazníka. Realizace projektu byla započata v roce 2002. Do tohoto projektu jsem vstoupil ve fázi analýzy a návrhu. Tento projekt se stal neúspěšným. S odstupem času a získáváním dalších zkušeností v oblasti vývoje softwaru bych v dnešní době řekl, ţe pokud by se takový projekt měl znovu realizovat za stejných podmínek, bude zajisté opět neúspěšný. Za neúspěch realizace tohoto projektu jsou z dnešního hlediska zodpovědné obě strany, a to jak dodavatel, tak zákazník. Na obou stranách se v průběhu projektu vyskytla spousta pochybení, která vedla k neúspěchu. Dodavatel, který nakonec zvítězil ve výběrovém řízení a projekt realizoval, nepouţíval pro vývoj softwaru ţádnou metodiku. Vývoj softwaru prováděl na základě vnitropodnikových standardů a pouţíváním některých nástrojů jako jsou CASE nástroje, software pro správu verzí kódu a datových modelů atd. Průzkum pouţívání agilních metodik v ČR (28) uvádí aţ 57 procent firem, které se podílejí na vývoji softwaru a nepouţívají ţádnou metodiku. Důvody, které vedly k výslednému neúspěchu tohoto projektu, uvedu na konci této studie. Rozsah tohoto projektu je v celku obsáhlý, proto se omezím převáţně na teoretickou problematiku, jeţ se vztahuje k metodikám a vztahům mezi zákazníkem a dodavatelem.

4.1 Projekt CIS Projektem byla realizace informačního systému pro správu klientů a sledování některých jejich aktivit. Tento informační systém měl nahradit současný nevyhovující systém sběru a vyhodnocování informací o klientech. Původní řešení spočívalo ve sběru informací v různých lokalitách v ČR programy, které neměly zcela shodné atributy. Tyto programy byly spravovány různými pobočkami samostatně, a tudíţ se od sebe v některých částech odchylovaly. Úmyslem bylo vytvoření jednotného informačního systému propojujícího všechny pobočky a zajištění jednotnosti při sběru a zpracování informací, rychlejší výměnu dat mezi pobočkami a centrální dohled nad informacemi s moţností jejich centrálního zpracování. Jelikoţ tento systém měl provádět zpracování osobních údajů podle § 5 odst. 2 písm. a) zákona č.101/2000 Sb., o ochraně osobních údajů, v platném znění má zákazník registraci u Úřadu pro ochranu osobních údajů. 61

Zde uvedu některé poţadavky na informační systém: a) Informační systém měl být řešen modulárně podle oblastí problematiky, kterou měl systém řešit a to takovým způsobem, aby bylo moţné program postupně zavádět, doplňovat, popř. upravit při změně zákona, usnesení vlády apod. Tento bod dodavatel splnil tak, že rozdělil projekt na dílčí části a každá z nich byla řešena samostatnou smlouvou, b) moţnost přidávat další atributy bez zásahu dodavatele. Tento bod byl dodavatelem dodržen pouze částečně. Dodavatel totiž v analýze rozdělil informace na statické a dynamické. Zákazník s tím souhlasil, a tudíž v podstatě popřel tuto myšlenku. V době provozu a údržby zjistil, že je potřeba měnit (rozšiřovat či zužovat počet) i statické informace, c) jednotný systém propojený do centrální databáze. Bylo dodavatelem dodrženo, d) moţnost zpracovávat informace při přerušení spojení s centrální databází. Tento bod byl dodavatelem dodržen po obtížích, viz níže, e) moţnost rozšíření o další moduly. Bylo dodavatelem dodrženo zpřístupněním otevřeného databázového modelu, f) moţnost reagovat na změny legislativy. Tento bod byl po fázi analýzy vypuštěn z důvodu náročnosti jak časové, tak finanční. Bylo dohodnuto, že bude řešeno v rámci servisní smlouvy, což způsobilo závislost na dodavateli, g) kaţdý záznam musel mít svou historii (aby v případě změny bylo moţné dohledat původní stav, kdo jej opravil a z jakého důvodu). Požadavek byl dodržen, h) cena za vytvoření informačního systému byla pevně stanovena. Cenu za vytvoření díla nebylo možné překročit z důvodu rozpočtových omezení zákazníka, i) čas pro dokončení vývoje a nasazení byl pevně stanoven. Čas byl dodavatelem překročen již ve fázi testování, z důvodu špatného návrhu datové a technologické architektury. Tento projekt vykazuje zřejmé vlastnosti IASW a to včetně všech svých výhod a nevýhod zmíněných v kapitole 1.1.2. Je zapotřebí, aby si čtenář uvědomil, jaká rizika tvorba informačního systému na zakázku přináší a na co je třeba se soustředit při jejich eliminaci.

62

4.2 Výběr dodavatele. Výběr dodavatele je jednou z velice důleţitých fází projektu. Pokud zákazník včas nedokáţe odhalit nedostatky dodavatele, coţ můţe být někdy velice obtíţné, můţe v pozdějších fázích projektu dojít k problémům s realizací celého projektu. Výběr dodavatele probíhal oslovením dodavatelů zákazníkem. Zákazník by si měl stanovit, jaká kritéria budou po dodavateli poţadována. Těmi by především měly být reference a zkušenosti s realizací projektu odpovídající velikosti projektu, který má v úmyslu zákazník realizovat. Pokud dodavatel projde do uţšího výběru, doporučoval bych kontaktovat některého dřívějšího odběratele informačního systému pro získání dalších informací o dodavateli. Ten totiţ můţe za účelem získání zakázky neposkytnout relevantní informace o svých předchozích projektech. Dodavatelé do referencí uvádí i projekty, které nebyly úspěšné např. z hlediska akceptace zákazníkem nebo dodrţení časového harmonogramu. V případě tohoto projektu bylo nutné vyhlásit veřejnou soutěţ a jako kritérium pro výběr dodavatele informačního systému byla nejniţší cena. Ta nakonec eliminovala ze soutěţe dodavatele, kteří patrně měli výrazně větší zkušenosti s vývojem informačního systému. Po výběru dodavatele se rozbíhá softwarový projekt po fázích stanovených jednotlivými přístupy s vývoji softwaru. Tabulka 2: Porovnání fází metodik metodika

ţádná

tradiční (RUP)

agilní (XP)

1 fáze

sběr informací, plánování

počáteční

průzkumná

2 fáze

implementace

přípravná

plánování

3 fáze

implementace

konstrukční

iterace vedoucí k distribuci

4 fáze

zavádění

nasazení

zavedení

Zdroj: vlastní úprava

63

4.3 První fáze Zákazník v případě projektu CIS řešil první fázi projektu samostatnou smlouvou, která se týkala vytvoření detailní analýzy s informacemi o rozpočtu třech zbývajících fází a jejich časovém harmonogramu. Jednou z nejdůleţitějších záleţitostí při plánování budoucího projektu je počáteční stanovení odhadu. Na tom bude totiţ záleţet, jak se zákazník rozhodne při dalším postupu vývoje softwaru nebo informačního systému. Pokud vezmu v úvahu vlastní zkušenosti, tak zákazník převáţně nezkoumá a nezajímá jej, jakým způsobem bude dodavatel software vyvíjet. Tato otázka zůstává leţet na bedrech dodavatele, jaký z přístupů zvolí. Zda tradiční, agilní nebo jiný. U obou kategorií metodik jsem uvedl, ţe výchozím bodem je vţdy vize, kterou zákazník předkládá při poptávce na poţadovaný software. Vize, které jsem viděl během svého působení v oblasti IT, byly některé velice obsáhlé, řekl bych, ţe mnohdy aţ zbytečně. Z této obsáhlosti nakonec vyplývá spoustu nadbytečných omezení pro dodavatele. Jiné vize zase natolik stručné, ţe nebylo moţné přesně stanovit, co si vlastně zákazník přeje. V prvé řadě je potřeba říci, ţe odhad softwarových projektů bude vţdy problematický. Nezáleţí na tom, jestli bude projekt tradiční nebo agilní. Kaţdý softwarový projekt, zabývající se vývojem softwaru, je jedinečný. Nikdy nejsou poţadavky zákazníka zcela shodné a hodnocení obtíţnosti a rozsahu při shromaţďování vstupních poţadavkům je choulostivé. Tradiční a agilní metodiky jsou v této problematice velmi podobné. Kaţdý počáteční odhad bude stejně nepřesný jak v agilních tak tradičních metodikách (29). Tradiční metodiky spoléhají především na znalost větší části systému v počáteční fázi projektu. To se odráţí ve snadnějším odhadu nákladů na projekt. U agilních metodik je schopnost odhadnout projekt po ukončení několika iterací, kdy se stává projekt, jeho rozsah a tím i náklady a čas, snadno měřitelný. Samozřejmě rychlost metriky, která vzejde z první iterace, nebude přesným zástupcem měření rychlosti. Ta se, jak jsem zmínil v metodice XP, s kaţdou další iterací zpřesňuje a zkracuje.

64

Přístup obou metodik zobrazuje Obrázek č. 15. Obrázek č. 15: Odhad ukončení projektu

Zdroj: dostupný z http://leadinganswers.typepad.com/leading_answers/images/2007/11/03/estimation_approach_slider.jpg, [cit. 29.3.2009]

Nejlepším způsobem, jak co nejpřesněji odhadnout výsledek budoucího projektu, je zvolit více technik pro odhad. Jednou z nich je analogický odhad na základě porovnání s jinými projekty, parametrický odhad na základě některých proměnných např. počtu řádků programu apod. V této první fázi dodavatel poţádal zákazníka o vyplnění dotazníků, které se skládaly z několika částí. Dotazník byl rozdělen na sekce hardware, software a komunikace. Tabulka 3: Rozdělní přístupů k vývoji v první fázi metodika

ţádná

tradiční

agilní

1 fáze

sběr informací, plánování

počáteční

průzkumná

zákazník

Poskytuje informace.

Poskytuje informace. Odpovídá

Poskytuje informace.

Odpovídá na dotazy

na dotazy dodavatele, vyplňuje

Odpovídá na dotazy

dodavatele, vyplňuje

dotazníky.

dodavatele, vyplňuje

dotazníky.

dotazníky.

aktivita %

100

100

100

dodavatel

Provádí sběr informací

Ujasnění rozsahu projektu:

Ujasnění rozsahu projektu:

vedený za účelem určení

vytvoření základního modelu

definice základních

detailního rozsahu projektu

případu uţití a základního

uţivatelských poţadavků,

a naplánování časového

architektonického prototypu.

vytvoření architektonického

harmonogramu. čas v %

30

modelu. 10

10

Zdroj: vlastní úprava

65

Zákazník poskytl dodavateli stávající programy, které byly provozovány na jednotlivých pobočkách. Z pozdějších informací vyplynulo, ţe je dodavatel nikdy neotevřel. Výše, viz Tabulka 2, uvádím rozdíl mezi jednotlivými přístupy k vývoji softwaru. Jak je vidět, všechny tři způsoby poţadují maximální zapojení zákazníka pro stanovení základního rozsahu projektu. V této fázi se jednotlivé přístupy téměř shodují. Vycházejí z vize zákazníka, na jejímţ základě je moţné definovat základní model případu uţití v metodice RUP, user stories pro metodiku XP a entit, vazeb a závislostí bez pouţití metodiky. V této fázi však u projektu CIS bylo zákazníkem navíc poţadováno dodání přesného časového harmonogramu. Tento poţadavek vznikl na základě obavy z nedodrţení termínu dodání poţadovaného systému. Z tohoto důvodu bylo nutné, aby dodavatel udělal podrobnější analýzu, sestavil téměř kompletní poţadavky na systém, provedl návrh architektury a sestavil obsáhlou dokumentaci. Tím byl čas strávený dodavatelem bez metodiky v této fázi projektu znatelně delší, viz Obrázek č. 17. Podrobný plán projektu metodiky plánují aţ ve fázi druhé.

4.4 Druhá fáze V druhé fázi se jednotlivé přístupy značně odlišují, viz Tabulka 4. Prvním důvodem je zahájení prací dodavatelem, který neměl ţádnou metodiku na implementaci informačního systému. Rozdíl je dán především tím, ţe podrobný plán jiţ byl schválen v předchozí fázi projektu a dodavatel se jiţ v této fázi soustředil na vývoj. Zákazník v této chvíli prováděl svou běţnou pracovní činnost. Komunikace s dodavatelem nebyla ţádná, protoţe dodavatel předpokládal navrţený a schválený harmonogram, včetně všech poţadavků za fixní. S pouţitím metodiky RUP v této fázi komunikuje dodavatel se zákazníkem na upřesnění poţadavků se stanovením priorit a rizik jednotlivých modelů případů uţití a vytváří plán realizace a soustředí se na zavedení stabilní architektury. Komunikace zákazníka s dodavatelem není jiţ natolik intenzivní, protoţe jiţ v první fázi byla vytvořena hrubá koncepce. Přípravná fáze v metodice RUP je z tohoto důvodu znatelně delší neţ např. u XP. V metodice XP dodavatel společně se zákazníkem pouze plánuje distribuce na základě zákazníkem stanovených priorit. 66

Tabulka 4: Rozdělní přístupů k vývoji v druhé fázi metodika

ţádná

tradiční

agilní

2 fáze

implementace

přípravná

plánování

zákazník

Zákazník v této fázi

Upřesnění poţadavků, schválení

Schválení plánu distribucí na

nevyvíjel ţádnou činnost.

plánu realizace a způsobu

základě stanovení priorit

testování.

jednotlivých user stories. Součástí distribuce jsou akceptační kritéria.

aktivita %

0

50

100

dodavatel

Prováděl implementaci.

Upřesňuje poţadavky zákazníka

Vytváří ve spolupráci se

a vytváří plán realizace a

zákazníkem plán distribucí.

soustředí se na zavedení stabilní architektury, vytváří plán testování. čas v %

30

30

10

Zdroj: vlastní úprava

Jak je patrné, obě metodiky se v této fázi shodnou na stanovení priorit stanovených zákazníkem. V případě projektu CIS dodavatel nestanovil ţádné priority a jedinými prioritami byly celková funkcionalita systému a dodrţení časového harmonogramu. Tím byl stanoven počátek následných potíţí tohoto projektu. Jako další velmi zásadní pochybení dodavatele povaţuji nedostatečné prověření poţadavků zákazníka. Tím se do projektu zavleklo mnoho poţadavků, které nebyly pro funkčnost systému důleţité.

4.5 Třetí fáze Ve třetí fázi projektu se přístupy k tvorbě softwaru shodují. Všechny tři způsoby, viz Tabulka 5, se zabývají implementací jednotlivých poţadavků. Bohuţel, dodavatel bez metodiky nezvolil iterativní přístup a volil přístup dodání kompletního softwaru, který byl uvolněn pro testování. Metodiky, jak jsem u obou uvedl, tuto fázi konstrukční a vedoucí k distribuci, zpracovávají iteračně. To znamená, v obou případech vytvoření funkční části 67

systému, kterou dodavatel postupně dodává zákazníkovi a ten ji testuje technikami, které byly výše u jednotlivých metodik uvedeny. Tabulka 5: Rozdělní přístupů k vývoji ve třetí fázi metodika

ţádná

tradiční

agilní

3 fáze

implementace

konstrukční

iterace vedoucí k distribuci

zákazník

Zákazník v této fázi

Zákazník postupně testuje

Zákazník postupně testuje

nevyvíjel ţádnou činnost.

dodávané funkční části

dodávané funkční části

softwaru.

softwaru a podílí se na sestavování další iterace vedoucí k distribuci.

aktivita %

0

50

100

dodavatel

Prováděl implementaci a

Dodavatel provádí

Dodavatel provádí

po dokončení kompletní

implementaci v jednotlivých

implementaci v jednotlivých

implementace předal

iteracích. Na konci kaţdé

iteracích. Na konci kaţdé

zákazníkovy software k

iterace je spustitelný kód, který

iterace je spustitelný kód,

testování.

zákazník testuje.

který zákazník testuje.

20

40

60

čas v %

Zdroj: vlastní úprava

U metodiky XP jsou distribuce zákazníkovi častější neţ u metodiky RUP. Navíc po ukončení kaţdé iterace zákazník znovu plánuje další iteraci vedoucí k distribuci. Metodika RUP jiţ v této fázi zákazníka nezatěţuje a soustředí se na plnění plánu schváleného v druhé přípravné fázi. U všech těchto přístupů je v této fázi prováděno testování, proto jsem jej neodděloval jako samostatnou fázi. Testování navíc, jak jsem uvedl, probíhá u metodik průběţně s ukončením kaţdé iterace. Tím by byla aktivita zákazníka u ostatních způsobů vývoje uměle sníţena. Dodavatel projektu CIS, který zde popisuji, zvolil při analýze dva způsoby testování. Prvním byly unit testy prováděné v rámci vývoje jednotlivých komponent, a které jsou povaţovány při vývoji za samozřejmé. Další testování proběhlo jako akceptační testy zákazníkem. Zcela jsem postrádal například integrační testování, validační testy rozdělené 68

na alfa a beta testy a systémový test (při tak rozsáhlém projektu by tyto testy měly být povinné). Ten byl prováděn pouze ve vývojovém a simulovaném prostředí u dodavatele. Toto pochybení se projevilo při nasazení kompletního systému do reálného provozního testování. Náhle byly odhaleny závaţné nedostatky především v navrţené datové a technologické architektuře. Ty se týkaly neschopnosti databázových systémů, které mezi sebou zajišťovaly výměnu dat, dopravit všechna data do centrální databáze, která zajišťovala výměnu s ostatními datovými úloţišti, viz Obrázek č. 16. Obrázek č. 16: Rozloţení a toky dat mezi DB

Zdroj: vlastní úprava

Problém spočíval ve špatně provedeném měření datové sítě na počátku celého projektu. Pro výměnu dat zvolil dodavatel řešení jiného dodavatele, které nebylo schopno na nízké propustnosti datových linek tuto výměnu zajistit. Pochybení ale bylo i na straně zákazníka, protoţe dodavatele neupozornil, ţe datové linky jsou pouţívány také jinými organizacemi a neslouţí výhradně tomuto zákazníkovi. To by ovšem bylo odhaleno v rámci kvalitního měření dodavatelem. Jelikoţ nebyly provedeny další chybějící testy, nedošlo k eliminaci chyb, které způsobovaly problémy v průběhu celého nasazení informačního systému.

69

4.6 Čtvrtá fáze V poslední závěrečné fázi projektu na vytvoření informačního systému je komunikace a zapojení zákazníka do projektu v maximální míře. V tomto případě reagují všechny přístupy stejně a jejich záměr je z metodického pohledu totoţný. Tabulka 6: Rozdělní přístupů k vývoji ve čtvrté fázi metodika

ţádná

tradiční

agilní

4 fáze

zavádění

nasazení

zavedení

zákazník

Přebírání a testování

Přebírání a testování systému,

Přebírání a testování systému,

systému, dokumentace a

dokumentace a školení

dokumentace a školení

školení uţivatelů. Reakce

uţivatelů. Reakce zákazníka a

uţivatelů. Reakce zákazníka a

zákazníka a uţivatelů na

uţivatelů na problémy s

uţivatelů na problémy s

problémy s instalací,

instalací, konfigurací a

instalací, konfigurací a

konfigurací a

odlaďováním drobných chyb

odlaďováním drobných chyb

odlaďováním drobných

zjištěných při testovacím

zjištěných při testovacím

chyb zjištěných při

provozu.

provozu.

testovacím provozu. aktivita %

100

100

100

dodavatel

Předávání systému,

Předávání systému,

Předávání systému,

dokumentace, školení

dokumentace, školení uţivatelů.

dokumentace, školení

uţivatelů. Operativní

Operativní řešení nalezených

uţivatelů. Dodavatel se

řešení nalezených

problémů a reakce na

soustředí na ověření

problémů a reakce na

připomínky uţivatelů, případně

spolehlivosti, výkonnosti a

připomínky uţivatelů.

dokončení funkčností, které

správnosti vytvořeného řešení.

byly doposud odkládány čas v %

40

20

20

Zdroj: vlastní úprava

Zapojení zákazníka se týká především problémů s instalací, konfigurací a odstraňováním drobných chyb zjištěných při testovacím provozu. Dodavatel nesmí připustit, aby zákazník kladl nové poţadavky či návrhy na změny funkcionality informačního systému místo soustředění se na doladění produktu.

70

5.

Vyhodnocení a doporučení

Do vyhodnocení jsem zahrnul výše uvedené informace a hodnoty z tabulek.

5.1 Čas Z tabulek vyplývá čas strávený jednotlivými přístupy na vývoji softwaru, viz Obrázek č. 17. To ukazuje poměrně důleţité informace: a) čas věnovaný metodikou XP vývoji by měl zajistit dodání kvalitního a spolehlivého informačního systému. Spolehlivého především, protoţe metodika XP klade na testování velmi vysoký důraz a testy jsou většinou napsány ještě před zahájením programování. Další výhodou agilní metodiky je rychlé zahájení vývoje, zatímco tradiční metodiky ještě plánují, b) metodika RUP věnuje poměrně velkou část na přípravu a plánování, ale věnuje i velkou část programování a testování. Tato metodika se doporučuje pro rozsáhlejší projekty, u nichţ se nepředpokládají zásadní změny v poţadavcích, c) dodavatel bez metodiky a jeho absence samostatné fáze plánování a kvalitního zjišťování relevantních informací k celému projektu na základě nátlaku zákazníka nakonec způsobilo řadu pochybení během celého vývoje a tím v závěrečné fázi prodlouţení doby nasazení k zákazníkovi do ostrého provozu. Obrázek č. 17: Graf času stráveného v jednotlivých fázích projektu

metodika RUP

metodika XP

bez metodiky

0

20

40

60

80

fáze 1

fáze 2

fáze 3

fáze 4

Zdroj: vlastní úprava

71

100

120

5.2 Aktivita zákazníka Další sledovanou hodnotou je aktivita zákazníka během jednotlivých fází projektu. Ta se u jednotlivých přístupů liší, viz Obrázek č. 18. Z tabulek a grafu se dá vyčíst ţe: a) agilní metodika vyţaduje neustálou interakci dodavatele se zákazníkem. V metodice XP je přímo doporučeno, aby zákazník byl součástí vývojového týmu a sdílel s ním pokud moţno stejnou místnost. Tím by měla být zajištěna okamţitá reakce zákazníka na vývoj a dodavatele na zpětnou vazbu od zákazníka, b) tradiční metodika zatěţuje zákazníka především v počáteční fázi, kdy jsou od zákazníka získávány informace pro projekt a v konečné fázi při nasazování a předávání projektu. V druhé a třetí fázi projektu dodavatel společně se zákazníkem provádí pouze menší korekce, které zajistí včasné dodání kvalitního produktu. Způsob komunikace dodavatele se zákazníkem není u tradičních metodik podmiňován přítomností zákazníka na pracovišti dodavatele. Navíc můţe být zákazník zcela nahrazen analytikem, se kterým zákazník komunikuje, c) dodavatel bez metodiky věnoval maximální úsilí v počáteční fázi projektu, kde se snaţil analyzovat sto procent celého projektu a vytvořit plán implementace a nasazení. V této části byla komunikace se zákazníkem velmi intenzivní. V druhé a třetí fázi nepředpokládal jakékoliv změny ve schváleném projektu a tak se zákazníkem téměř nekomunikoval. Ve fázi zavádění byla komunikace se zákazníkem opět intenzivní. Tento přístup zpětně hodnotím jako velmi nezodpovědný. Určité, alespoň drobné korekce jak poţadavků, tak plánu jsou v kaţdém projektu vţdy potřeba a to ne pouze v softwarovém. Obrázek č. 18: Graf aktivity zákazníka v jednotlivých fázích projektu 120 100 80 60 40 20 0 fáze 1

fáze 2

fáze 3

bez metodiky

tradiční

Zdroj: vlastní úprava

72

fáze 4 agilní

Na začátku případové studie jsem uvedl, ţe popíši, z jakých důvodů byl projekt CIS neúspěšný. V podstatě jsem to jiţ naznačil v průběhu celé případové studie. Pokud vezmu projekt od úplného počátku, tak to byla především nezkušenost a neznalost zákazníka, která způsobila chyby v zadání a nestandardní poţadavky na dodavatele. Neznalost přístupů a metodik vývoje a absence zkušeností z předchozích podobných projektů nedávala moţnost zákazníkovi utvořit si představu o tom, jak správně softwarový projekt probíhá a tím se nemohl vyvarovat uvedených chyb. Dodavatel, jenţ měl snahu k vývoji přistupovat zodpovědně, udělal v průběhu realizace projektu spoustu chyb. Objevily se jiţ v analýze projektu, kde došlo k nekvalitnímu zpracování poţadavků. Během implementace nekorigoval poţadavky a neupravoval plán. Neúplné testování probíhalo jak v průběhu implementace, tak v průběhu zavádění. Zde se projevily chyby právě těch částí, které nebyly dostatečně kvalitně provedeny. Dalším problémem celého projektu byli uţivatelé, kteří byli zvyklí na předešlý software, který pouţívali několik let a nechtěli si zvykat na jiný, který byl především vizuálně jiný a podle uţivatelů horší neţ ten původní. Zde je několik důvodů, o kterých jsem s uţivateli hovořil: a) lokální správci tyto programy neustále vylepšovali podle poţadavků uţivatelů téměř okamţitě a s příchodem nového informačního systému musely návrhy na změny a úpravy procházet schvalováním, které bylo zdlouhavé, b) uţivatelům nikdo nevysvětlil přínosy nového informačního systému, c) vlivem neustálých chyb při nasazování a testování jej uţivatelé předem zamítli, d) celý informační systém neměl v průběhu realizace kvalitní podporu vedení. Z pohledu metodik by zajisté bylo přínosem, pokud by dodavatel některou z agilních nebo tradičních pouţil. Metodiky jsou upravovány a sestavovány odborníky z oblasti vývoje softwaru na základě jejich zkušeností a zkušeností vývojářů, kteří tyto metodiky pouţívají. Jsou souborem rad a doporučení získaných právě na základě takto nezdařených projektů. Projekt CIS je v současné době stále provozován po mnoha úpravách, které bylo nutné ještě realizovat, aby byla zajištěna funkčnost, jakou zákazník poţadoval. Tyto úpravy stály ještě další investice, které nebyly plánovány a tak byl projekt neúspěšný nejen v nesplnění časového harmonogramu, ale i v rozpočtu a rovněţ nesplnil očekávání zákazníka.

73

Pro mě osobně jako pracovníka v oboru informačních technologií a také vývojáře jsou nejzajímavější a pravděpodobně nejdůleţitější především poţadavky a sběr informací. Zde je moţné zavést do budoucího projektu nejvíce chyb, ale také je moţné je nejlevněji a nejsnadněji eliminovat. Poţadavky by měly být vţdy: a) úplné - kaţdý poţadavek musí plně popisovat funkčnost, která má být vytvořena. Popis poţadavku musí obsahovat všechny informace, které můţe vývojář potřebovat pro návrh a implementaci takové funkčnosti, b) správné - posuzování uţivatelských poţadavků z hlediska funkčnosti těmi, jichţ se tato funkčnost týká, c) proveditelné - vţdy je třeba dbát na to, aby byl kaţdý poţadavek hodnocen i z hlediska technické proveditelnosti. Některé technicky proveditelné poţadavky mohou být například také velice nákladné, a) nutné - kaţdý poţadavek by měl být doloţen opravdovou potřebou zákazníka. Seznam veškerých poţadavků je třeba na konci znovu projít a odstranit poţadavky, které zcela zřejmě zákazník nepotřebuje, b) důleţité - ohodnocení jednotlivých poţadavků prioritami, které určí, jak důleţitý je kaţdý jednotlivý poţadavek v celém produktu, c) jednoznačné – popis příslušného poţadavku musí být jednoznačný tak, aby kaţdý dospěl ke stejnému pochopení významu. Jelikoţ má přirozený jazyk tendenci k nejednoznačnosti, je vhodné pouţívat jednoduchá a přímočará vyjádření. Jelikoţ zákazník nemusí být znalý technických a odborných termínů z oblasti informatiky, není vhodné je pouţívat. Ideálním prostředkem pro pochopení problémů je pouţití jednoduchých praktických příkladů, d) ověřitelné - kaţdý poţadavek je nutné pečlivě sledovat a ujistit se, ţe existují testy nebo jiné metody, podle kterých bude moţné stanovit, zda byl poţadavek implementován a splňuje poţadovaná kritéria (30). Testování je dalším důleţitým bodem v průběhu vývoje. Pokud není kvalitní se stoprocentními výsledky po celou dobu projektu, hrozí neodhalení chyb, které mohou v závěru projektu nepříjemně překvapit jak zákazníka, tak dodavatele. Metodiky však na tuto problematiku myslí.

74

Závěr Vývoj softwaru můţe a nemusí být řízen metodikami. Tato volba spočívá především na dodavatelích softwaru a na zákaznících, kteří se na vývoji podílejí. Pouţitím metodik by však měl být zaručen kvalitní přístup k vývoji a dokončení kvalitního softwaru včas a za stanovenou cenu. To, kterou metodiku dodavatel zvolí nebo pouţívá, je závislé na několika aspektech. Je to především ochota zákazníka se podílet na vývoji. Není moţné aplikovat metodiku XP, kdyţ nemá zákazník zájem být členem vývojového týmu anebo se nechce intenzivně podílet na vývoji aţ do dokončení projektu. Také velikost projektu můţe ovlivnit to, jaká metodika je vhodnější. Všeobecně se tvrdí, ţe metodika RUP je pro větší projekty vhodnější. V dnešní době nelze zapomenout ani na geografické rozloţení vývojového týmu, na jehoţ základě není moţné některé metodiky pouţít. Všechny tyto nedostatky, na které vývojáři naráţí, se snaţí autoři metodik postupně odstranit. Ve své diplomové práci jsem čtenáři popsal, co je software a s jakými jeho druhy se můţe zákazník setkat nejen při vývoji, ale i při koupi v obchodech. Jaká licenční ujednání se k takovému softwaru vztahují a jaká tím zákazníkovi vznikají práva a omezení. Dále s jakými informačními systémy se uţivatelé mohou setkat v praxi a k jakému účelu jsou určeny. Představil jsem část souboru metodik, jejichţ pomocí je vývoj softwaru a informačních systémů realizován. Kromě představení historie jsem na jednotlivých fázích vývoje různými metodikami uvedl, jak se na vývoji zákazník podílí a jak probíhají vztahy mezi zákazníky a dodavateli. V případové studii jsem porovnal tradiční a agilní metodiky a také přístup k vývoji neřízený metodikou. Vyhodnotil jsem jednotlivé přístupy k vývoji a jejich vliv na vztahy mezi zákazníkem a dodavatelem. Zároveň vyhodnocením úspěšnosti realizace softwarového projektu ovlivněného některým z výše popsaných způsobů, jsem splnil cíl této práce. Uvedené informace a doporučení by měly čtenáři pomoci zaměřit se na oblasti, ve kterých jsem se setkal s nedostatky a tím předejít chybám, které mnohdy z těchto nedostatků vznikají. Dalšími moţnostmi zkoumání vztahů mezi zákazníky a dodavateli při vývoji softwaru by mohlo být porovnání více druhů agilních metodik. Kaţdá metodika je svým způsobem specifická a v jednotlivých fázích vývoje přistupuje k zákazníkovi odlišným způsobem. Zajímavá by byla např. studie, ve které by se porovnávaly agilní metodiky mezi sebou. Na základě průzkumu dodavatelů zabývajících se vývojem softwaru agilními metodikami by 75

bylo určeno, která z metodik je při komunikaci a vztazích zákazníka s dodavatelem úspěšnější. Ne vţdy se podaří zákazníka plně integrovat do vývojového týmu dodavatele a tím zajistit naplnění některých podmínek manifestu agilního programování. Další agilní metodiky, které by mohly být pouţity pro srovnání, a je moţné se jimi nechat inspirovat, jsou: Feature-Driven Development (FDD), SCRUM Development Process, Adaptive Software Development (ASD), Lean Software Development, Test-Driven Development (TDD), Crystal family of methodologies.

76

Pouţitá literatura 1. Computer software. en.wikipedia.org. [Online] wikipedia.org, 4. 4 2009. [Citace: 7. 4 2009.] http://en.wikipedia.org/wiki/Computer_software. 2. Fowler, Martin. The New Methodology. www.martinfowler.com. [Online] [Citace: 20. 02 2009.] http://martinfowler.com/articles/newMethodology.html. 3. Šimek, Milan. Školský vzdělávací informační portál. www.edu.cz. [Online] MŠ MT ČR. [Citace: 10. 1 2009.] http://app.edu.cz/kvo/stahnout/542/;jsessionid=791562E2ECC522BA05E2D1110A225DD 5.t1. 4. Matěna, Roman. Stavět eshop na míru nebo koupit hotový systém? IASW nebo TASW? www.solisshop.cz. [Online] 25. 6 2008. [Citace: 25. 3 2009.] http://www.solisshop.cz/clanek/Stavet-eshop-na-miru-nebo-koupit-hotovy-system-IASWnebo-TASW. 5. Čermák, Jiří. Licence a licenční smlouvy k software - otázky a odpovědi. www.ipravo.cz. [Online] IT právo, 24. 6 2003. [Citace: 18. 2 2009.] http://www.itpravo.cz/index.shtml?x=138962. 6. Free Software Foundation, Inc. Categories of Free and Non-Free Software. www.gnu.org. [Online] GNU Operating System, 7. 1 2009. [Citace: 10. 1 2009.] http://www.gnu.org/philosophy/categories.html. 7. Druhy software. www.gvp.cz. [Online] Gymnázium Na Vítězné pláni. [Citace: 27. 01 2009.] http://www.gvp.cz/local/new/ucebnice/Vyptech/software/software.htm. 8. Lindsay, John. Information Systems: Fundamentals and Issues. www.oturn.net. [Online] 2000. [Citace: 12. 02 2009.] http://www.oturn.net/isfi/index.html. 9. Loučka, Zdeňek. Systémové inžrnýrství. [Dokument] Praha : akela.mendelu.cz, 2008. 10. Sýkora, Stanislav. Moderní řízení. modernirizeni.ihned.cz. [Online] 12. 10 2007. [Citace: 12. 01 2009.] http://modernirizeni.ihned.cz/c1-22200550-nastroje-ke-zkroceniinformaci. 11. Unicorn. Metodiky řízení softwarových projektů. www.unicorn.cz. [Online] Unicorn, 25. 06 2007. [Citace: 28. 02 2009.] http://www.unicorn.eu/cz/press/clanek.php?id=15584. 12. Wiegers, Karl E. Software Requirements, 2nd Edition. : Microsoft Press, 2003. ISBN 0-7356-1879-8. 13. Cockburn, A. Methodology Per Project. Alistair Cockburn. [Online] 01. 07 1999. [Citace: 27. 02 2009.] http://alistair.cockburn.us/Methodology+per+project. 14. Buchalcevová, Alena. Systémová metodologie. [Dokument] Praha : VŠE, 2008. 1. blok.

77

15. RERYCH, Markus. Wasserfallmodell > Entstehungskontext [online]. cartoon.iguw.tuwien.ac.at. [Online] [Citace: 20. 11 2008.] http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html. 16. Eeles, Peter. Capturing Architectural Requirements. www.ibm.com. [Online] IBM, 15. 11 2005. [Citace: 02. 03 2009.] http://www.ibm.com/developerworks/rational/library/4706.html. 17. Eclipse. Introduction to OpenUP. epf.eclipse.org. [Online] Eclipse contributors and others, 27. 10 2008. [Citace: 5. 1 2009.] http://epf.eclipse.org/wikis/openup/. 18. Unicorn. Změnové řízení – "Jak řídit změny a nebýt jimi řízen". www.unicorn.cz. [Online] Unicorn, 6. 8 2007. [Citace: 1. 12 2008.] http://www.unicorn.eu/cz/press/clanek.php?id=15940. 19. —. Testy software. www.unicorn.cz. [Online] Unicorn, 22. 5 2003. [Citace: 3. 12 2008.] http://www.unicorn.eu/cz/press/clanek.php?id=2612. 20. Boehm, Barry. Agile and Plan-Driven Methods Oil and Water? www.agilealliance.org. [Online] 5. 5 2002. [Citace: 12. 12 2008.] www.agilealliance.org/system/article/file/923/file.pdf. 21. Warsta, J. a Abrahamsson, P. Is open source software development essentially and agile method? [Dokument] Oregon : In 3rd Workshop on Open Source Software Engineering, 2003. 22. Hajdin, Tomáš. Agilní metodiky vývoje software. [Dokument] Brno : Masarykova univerzita, 1. 5 2005. 23. Beck, Kent. Extreme Programming Explained. Embrance Change : Addison-Wesley, 1999. ISBN 0201616416. 24. Cockburn, Alistair. Agile Software Development. Ontario : Addison-Wesley Professional, 2001. ISBN 0-201-69969-9. 25. Don, Wells. Extreme Programming. www.extremeprogramming.org. [Online] 2001. [Citace: 2. 03 2009.] www.extremeprogramming.org. 26. Jeffries, Ronald. XProgramming.com an Agile Software Developement Resource. www.xprogramming.com. [Online] 2002. [Citace: 20. 1 2009.] http://www.xprogramming.com/. 27. Čermák, Miroslav. Black Box Test. www.cleverandsmart.cz. [Online] 25. 12 2008. [Citace: 17. 3 2009.] http://www.cleverandsmart.cz/black-box-test/. 28. Buchalcevová, Alena a Leitl, Marek. Průzkum používání agilních metodik v ČR. [Dokument] Praha : PEF ČZU, 2006. ISBN 80-213-1568-7. 29. Capers, Jones. Estimating Software Costs. New York : McGraw Hill Companies, 2007. ISBN: 0071483004.

78

30. Sloup, Petr. Vytvoření aplikačního software pro podporu marketingu prodeje automobilů. [Dokument] Plzeň : pslsoftware, 2002. 31. WEISERT, Conrad. There's no such thing as the Waterfall Approach!(and there never was) [online]. www.idinews.com. [Online] 8. February 2003. http://www.idinews.com/waterfall.html. 32. ROYCE, Winston. Managing the Development of Large Software Systems. www.cs.umd.edu. [Online] srpen 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf. 33. MCCONNELL, Steve. Rapid Development. Taming Wild Software Schedules. [s.l.] : Microsoft Press, 1996. str. 72. ISBN 1-55615-900-5. 34. PARNAS, David. A Rational Design Process: How and Why to Fake It. www.idemployee.id.tue.nl. [Online] 2. FEBRUARY 1986. http://www.idemployee.id.tue.nl/g.w.m.rauterberg/presentations/parnas-clements1986.pdf. 35. MCCONNELL, Steve. Dokonalý kód : umění programování a techniky tvorby software. Brno : Computer Press, 2005. ISBN 80-251-0849-X. 36. Adolf, Filip. Metodika RUP. objekty.vse.cz. [Online] 3. 2 2008. [Citace: 15. 12 2008.] http://objekty.vse.cz/Objekty/RUP. 37. Kadlec, Václav. Agilní programování. Brno : Computer Press, 2004. ISBN 80-2510342-0. 38. Get Ready for Agile Methods, with Care. Boehm, Barry. Computer, Los Alamitos : IEEE Computer Society Press, leden 2002, Sv. 35. ISSN: 0018-9162 . 39. Agile Contracts. leadinganswers.typepad.com. [Online] 5. 5 2007. [Citace: 10. 3 2009.] http://leadinganswers.typepad.com/.shared/image.html?/photos/uncategorized/2007/05/05/f lip_triangle.jpg. 40. Example Use-Case Model Inception Phase. epf.eclipse.org. [Online] 2009. [Citace: 2. 1 2009.] http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/re sources/atm_uc_model_inception.doc. 41. Example Use-Case Model Elaboration Phase. epf.eclipse.org. [Online] 2009. [Citace: 10. 1 2009.] http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/re sources/atm_uc_model_. 42. Conrad, Nutschan. http://en.wikipedia.org/wiki/Spiral_model. en.wikipedia.org. [Online] 8. 4 2008. [Citace: 18. 12 2008.] http://en.wikipedia.org/wiki/Spiral_model. 43. Jeffries, Ronald. What is Extreme Programming? www.xprogramming.com. [Online] 11. 8 2001. [Citace: 20. 3 2009.] http://www.xprogramming.com/xpmag/whatisxp.htm.

79

44. Wells, Don. Extreme Programming: A gentle introduction. www.extremeprogramming.org. [Online] 17. 2 2006. [Citace: 7. 3 2009.] http://www.extremeprogramming.org/map/images/project.gif. 45. Beck, Kent. Simple Smalltalk Testing: With Patterns. www.xprogramming.com. [Online] First Class Software, Inc. [Citace: 30. 3 2009.] http://www.xprogramming.com/images/Image1.gif. 46. Griffiths, Mike. Agile Estimation – Upfront Estimates. leadinganswers.typepad.com. [Online] 3. 11 2007. [Citace: 29. 3 2009.] http://leadinganswers.typepad.com/leading_answers/images/2007/11/03/estimation_approa ch_slider.jpg.

Seznam obrázků Obrázek č. 1: Znázornění softwarových licencí .................................................................. 16 Obrázek č. 2: Globální architektura IS – úrovně řízení ....................................................... 19 Obrázek č. 3: Schéma ţivotního cyklu modelu vodopád .................................................... 27 Obrázek č. 4:Schéma spirálového ţivotního cyklu ............................................................. 29 Obrázek č. 5: Ţivotní cyklus metodiky RUP ....................................................................... 32 Obrázek č. 6: Use Case (případ uţití) .................................................................................. 35 Obrázek č. 7:Upřesnění Use Case modelu .......................................................................... 37 Obrázek č. 8: Začlenění prototypování do vývoje softwaru ................................................ 40 Obrázek č. 9: Ţivotní cyklus poţadavku na změnu ............................................................. 43 Obrázek č. 10: Rozdíl tradičního a agilního pojetí vývoje software ................................... 49 Obrázek č. 11: Spektrum plánovacích metod ...................................................................... 50 Obrázek č. 12: Doporučené praktiky XP ............................................................................. 54 Obrázek č. 13: Ţivotní cyklus XP projektu ......................................................................... 56 Obrázek č. 14: Schéma automatického testu ....................................................................... 59 Obrázek č. 15: Odhad ukončení projektu ............................................................................ 65 Obrázek č. 16: Rozloţení a toky dat mezi DB .................................................................... 69 Obrázek č. 17: Graf času stráveného v jednotlivých fázích projektu .................................. 71 Obrázek č. 18: Graf aktivity zákazníka v jednotlivých fázích projektu .............................. 72 80

Seznam tabulek Tabulka 1: Srovnání agilních a plánem řízených metodik .................................................. 51 Tabulka 2: Porovnání fází metodik ..................................................................................... 63 Tabulka 3: Rozdělní přístupů k vývoji v první fázi ............................................................ 65 Tabulka 4: Rozdělní přístupů k vývoji v druhé fázi ............................................................ 67 Tabulka 5: Rozdělní přístupů k vývoji ve třetí fázi ............................................................. 68 Tabulka 6: Rozdělní přístupů k vývoji ve čtvrté fázi .......................................................... 70

Seznam zkratek ASD

Adaptive Software Development

BIOS

Basic Input-Output System

CASE

Computer-aided software engineering

CRM

Customer relationship management

DB

Database

DDS

Decision Support Systems

EDI

Electronic Data Interchange

EIS

Executive Information Systéms

ES

Expert Systems

ESS

Executive Support Systems

FDD

Feature-Driven Development

FPP

Full Package Product

GA

Product Release milestone

GUI

Graphical user interface

HTML

HyperText Markup Language

HW

Hardware

IASW

Individuální aplikační software

IBM

International Business Machines Corporation

IOC

Initial Operation Capability milestones 81

IS

Informační systémy

KWS

Knowledge Work Systems

LCA

Lifecycle Architecture Milestone

LCO

Lifecycle Objectives Milestone

MIS

Management Information Systems

OEM

Original Equipment Manufacturer

OIS

Office Information Systems

RMC

Rational Method Composer

RUP

Rational Unified Process

SAP

Systems Applications Products in data processing

SIS

Strategic Information Systems

SW

Software

TASW

Typový aplikační software

TDD

Test-Driven Development

TPS

Transaction Processing Systems

WWW

World Wide Web

XP

Extreme Programming

82