Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Lucie Fryaufová
Metodiky zjišťování požadavků uživatelů na webové prezentace
Bakalářská práce
2010
Prohlášení
Prohlašuji, že jsem bakalářskou práci na téma Metodiky zjišťování požadavků uživatelů na webové prezentace zpracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury.
V Praze dne:
................................ podpis
Poděkování
Na tomto místě bych chtěla velice poděkovat vedoucí mé bakalářské práce PhDr. Heleně Kučerové za poskytnuté konzultace, rady a připomínky během zpracování mé bakalářské práce. Dále bych ráda poděkovala své rodině a blízkým, kteří mi byli oporou při mém studiu.
Abstrakt Cílem bakalářské práce je analýza metodik z oblasti softwarového inženýrství. Práce se nejprve zabývá definováním pojmů metodiky a stručným popisem Webu, jeho vývojem a přínosem webových prezentací v dnešní době. Závěrečné kapitoly jsou zaměřeny na zjišťování požadavků na webové prezentace ve vybraných metodikách.
Abstract The aim of bachelor thesis is the analysis methodologies in the part of software engineering. First this work discusses the definition of methodology and brief description of the Web, its evolution and the benefits of the website today. The final chapters are devoted to identifying the requirements for the website in the selected methodologies.
Obsah 1.!
Úvod ...................................................................................................................... 7!
2.!
Význam a vývoj metodik při vývoji softwaru ................................................... 8! 2.1!
Definice a obsah pojmů metodika, metodologie a metoda ............................. 8!
2.2!
Vývoj a vznik metodik a životních cyklů ..................................................... 10!
2.2.1!
Model napiš a oprav (Code and Fix Model) .......................................... 10!
2.2.2!
Stagewise model .................................................................................... 10!
2.2.3!
Vodopádový model ................................................................................ 10!
2.2.4!
Spirálový model ..................................................................................... 13!
2.3!
Kategorizace metodik.................................................................................... 14!
2.3.1! 3.!
Web a webové prezentace ................................................................................. 18! 3.1!
Vývoj WWW ................................................................................................ 18!
3.1.1! 3.2!
Typy webových aplikací ........................................................................ 25!
Specifikace požadavků na webové prezentace ................................................ 28! 4.1!
Rozdíly ve vývoji softwaru a internetové aplikace ....................................... 28!
4.1.1!
Webové inženýrství ............................................................................... 28!
4.1.2!
Vývojový tým ........................................................................................ 29!
4.1.3!
Vývoj aplikace ....................................................................................... 29!
4.1.4!
Cíl, vize a uživatelé ................................................................................ 31!
4.2!
5.!
Statické a dynamické webové stránky ................................................... 24!
Webové prezentace ....................................................................................... 25!
3.2.1! 4.!
Agilní vs. rigorózní metodiky ................................................................ 17!
Požadavky na webové aplikace ..................................................................... 33!
4.2.1!
Definice pojmů ...................................................................................... 33!
4.2.2!
Typy požadavků ..................................................................................... 34!
4.2.3!
Vývoj požadavků ................................................................................... 37!
Vybrané metodiky zjišťování požadavků uživatelů na webové prezentace . 42! 5.1.1!
Metodika RUP ....................................................................................... 42!
5.1.2!
Metodika Jennifer Fleming .................................................................... 48!
5.1.3!
Metodika Web Modeling Language (WebML) ..................................... 50!
5.1.4!
Metodika UML-Based Web Engineering (UWE) ................................. 54!
6.!
Závěr .................................................................................................................... 56!
7.!
Seznam zdrojů .................................................................................................... 58!
6
1. Úvod V dnešní době si málokdo dokáže svůj život představit bez Internetu. Tato stále se vyvíjející technologie nás provází každým dnem. Její rozmach byl hlavně díky službě World-Wide-Web. Hlavní přínos Webu spočívá ve využití jeho služeb. Uživatel může jednak z webových prezentací získávat velké množství informací, ale také může využívat aplikace, které zjednoduší jeho každodenní činnosti. Prezentace má také velký přínos pro firmy, a to z možnosti celosvětového zveřejnění. Pro vývoj webové prezentace je k dispozici celá řada metodik, které představují souhrn činností procesu. Cílem práce je analyzovat metodiky zjišťování uživatelských požadavků a zhodnotit jejich specifikaci požadavků uživatelů. Práce je rozdělena do čtyř kapitol. První kapitola se věnuje vývoji metodik a životních cyklů. Zaměřuje se na definici a porovnání s příbuznými pojmy metodologie a metoda. Popisuje také jednotlivé modely, které stály při počátku vzniku metodik. Druhá kapitola se týká webových prezentací a stručnou historií webu. Vysvětlím na jakých principech je postaven World-Wide-Web a objasním hlavní rozdíl mezi webovou prezentací a aplikací. Vývoj webové prezentace je dlouhý proces, který je rozdělen do několika fází. Zaměřím se hlavně na fázi specifikace a sběr požadavků. Vyberu nejčastější prostředky zjišťování požadavků. Na základě vybraných metodik, kterými jsou RUP (Rational Unified Process), metodika Jennifer Fleming, Web Modeling Language (WebML) a UML-Base Web Engineering (UWE), se zaměřím na fázi zjišťování požadavků a stručně popíšu jednotlivé fáze vývoje webové prezentace.
7
2. Význam a vývoj metodik při vývoji softwaru Na úvod své bakalářské práce, která je zaměřena popisem metod v oblasti vývoje webových prezentací, bych ráda stručně objasnila pojem metodika a s ním spojené pojmy jako životní cyklus a proces vývoje softwaru. V této kapitole se zaměřím na vysvětlení pojmu metodika, její vývoj a kategorizaci metodik.
2.1 Definice a obsah pojmů metodika, metodologie a metoda Pojem
metodika
bývá
dost
často
zaměňován
s dalšími
pojmy,
kterými
jsou - metodologie a metoda. Ve skutečnosti není až takový rozdíl, používá-li se slova „metodika“ či „metodologie, avšak pro upřesnění bych uvedla hned několik definic. Obecné vysvětlení pojmu metodika definuje tento pojem jako pracovní postup nebo nauku. „Metodika ve vývoji software představuje souhrn doporučených praktik a postupů, pokrývajících celý životní cyklus vytvářené aplikace. Pro řešení dílčích problémů mohou být v rámci nasazení metodiky uplatněny specifické postupy – metody.“ [1] „Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení.“ [2] „Metodika“ se používá k označení komplexních postupů a návodů na vývoj softwarové aplikace. Skrývají se pod ní všechny etapy řešení (u vývoje softwarové aplikace tedy jde o všechny fáze životního cyklu).“ [3]
8
„Metodologie je nejobecnější pojem a znamená ve své podstatě „nauku o metodikách“. Jinými slovy, pod pojmem metodologie se skrývá vědní disciplína, která nějakým způsobem rozebírá metodiky, definuje je apod.“ [3] „Metoda je postup nebo návod, jak získávat správné poznatky, prostředek poznání.“ [4] Shrneme-li všechny tyto pojmy, které jsme si definovali, dospějeme k závěru, že metodika je proces, který se zabývá především popisem postupů a procesů činností spějících k dosažení určitého cíle. Metodika na všechny procesy nahlíží z výšky. Nezabývá se způsobem jak danou operaci provést, ale pomocí čeho ji provést. Metodika je tedy souhrn postupů a návodů, které popisují činnosti při návrhu, vývoji, analýze a nasazování software. Ke všem činnostem je potřeba prostředky, které umožní efektivně dosáhnout stanoveného cíle. Jsou jimi specifické nástroje, techniky, metody, souhrny etap, postupů či pravidel, dokumenty, role a další prostředky závisející na konkrétní metodice. V metodikách z oblasti softwarového inženýrství by měly být zahrnuty i prvky informačního systému – pracovníci, software, hardware, data a organizační procedury. Metodologie je vědní disciplína, která se zabývá tvorbou a aplikací metod. Samotná metoda je označení konkrétního postupu, který vede k vyřešení jednotlivých problémů. V mé práci budu popisovat metodiky, které se zaměřují zejména na vývoj webových prezentací.
9
2.2 Vývoj a vznik metodik a životních cyklů Podle [3] patří metodiky vývoje aplikací k nejdůležitějším produktům softwarového inženýrství. Během vývoje se metodiky pokoušely přizpůsobit aktuální situaci, to znamená, že se přizpůsobovaly konkrétním požadavkům kladeným na software. Cílem metodik tedy bylo odstranit nedostatky vývoje aplikací. Dříve se metodiky specializovaly spíše na fáze analýz, specifikace testů atd. V dnešní době je důležité hlavně (agilní metodiky) dodání výsledného produktu co nejdříve.
2.2.1 Model napiš a oprav (Code and Fix Model) Tento model se používal v 50. letech minulého století. Jeho vznik byl zcela spontánní, dnes by se ale neprezentoval jako metodika. Činnost modelu se dala popsat následovně: Sepsání aplikace – spuštění (zařazení do provozu) - opravování chyb.
2.2.2 Stagewise model Model životního cyklu založený na striktní posloupnosti fází byl uveden v roce 1957. Hlavní novinkou v tomto modelu bylo rozdělení vývoje softwaru na několik fází – definice problému, specifikace požadavků, architektura a návrh, implementace, integrace, provoz. Nevýhoda tohoto modelu byla absence zpětné vazby. Znamenalo to tedy, že model nebyl schopen ověřit výsledky jednotlivých fází. Po skončení jedné fáze se hned pokračovalo v další. Chyběla možnost revize, hodnocení výsledků a hledání rizik. Jediná možnost návratu byla v samotném závěru, kdy po dodání aplikace následovala fáze revalidace. Zde bylo možné rozhodnout se, zda se vrátit zpět, nebo opětovně vstoupit do procesu.
2.2.3 Vodopádový model K charakteristice tohoto modelu bych na úvod citovala definici, kterou vyslovil roku 1970 Dr. Winston Royce: „Máme-li být úplně korektní, musíme dodat, že model životního cyklu nerovná se metodice. Mezi metodikou a modelem životního cyklu není úplná shoda – zatímco model životního cyklu popisuje pouze „život“ aplikace a kroky prováděné při vývoji, metodika obvykle obsahuje i řadu dalších informací a podrobněji předepisuje, co se má v kterém okamžiku udělat. V současnosti je 10
k dispozici řada metodik, a tak se při vývoji více používají metodiky než „holé“ modely životního cyklu; v minulosti však byla situace právě opačná, a proto při úvahách o metodikách nesmíme zapomenout ani na modely životních cyklů.“ [3] Jak už bylo zmíněno v definici, vodopádový model ztvárňuje životní cyklus. Tento cyklus má pevně daný postup vývoje. Důležitá je analýza a z ní vyplývající návrh systému. Oproti svému předchůdci (model stagewise) se vodopádový model liší přítomnou zpětnou vazbou. Model je tvořen z několika fází a na konci fáze dochází k jejímu vyhodnocení a následné opravě či přepracování. Pokud by po dokončení jednotlivých fází došlo k nějakému problému, je možné se vrátit k jádru problému (např. úprava specifikace problému, změna návrhu či zvolení jiných podmínek testů, atd.). Důležitým znakem, který charakterizuje tento model je rozdělení do postupně uspořádaných fází, které odpovídají jednotlivým vývojovým aktivitám (definice, analýza, atd.). To znamená, že po ukončení jedné fáze může být zahájena další fáze. Neexistuje možnost, aby bylo prováděno více fází najednou. Dalším charakteristickým znakem modelu je přesně definovaná posloupnost kroků a fází: [3] 1. definice problému a seznámení s cílovou oblastí 2. analýza a specifikace požadavků 3. návrh 4. implementace 5. integrace a testování 6. provoz a údržba
11
!"#$%&'()*(+,-,.$-,/0(1,-&23(.4&/%56,(%(789(
Vodopádový model byl vůbec prvním modelem, který použil posloupnost fází při vývoji softwaru. Na jednu stranu je výhodou, že model vyniká svojí jednoduchostí. Má přesně dané postupy, určující co se má v daném okamžiku udělat. Na druhou stranu má výhoda v jednoduchosti i svoji slabou stránku. Model je užitečný pouze pro malé projekty. Na rozsáhlejší a komplexnější projekty je tento model příliš jednoduchý. Ideálně se model hodí pro vedení firmy, neboť lze stanovit tzv. rámcový harmonogram. Uživatelé tak mohou kontrolovat, zda všechny etapy vývoje odpovídají časovému harmonogramu projektu, zda je plněna specifikace požadavků či není překročen rozpočet projektu. Nevýhodou modelu je jeho nepružnost na změny, kdy při jakékoliv změně v zadání dochází ke zdlouhavému procházení fází analýzy a návrhu, tvorba příslušné dokumentace a opětovnému schválení procesu. Také dodání produktu zákazníkovi nepatří mezi silné stránky. Dodání probíhá formou „velkého třesku“1. Tím hrozí riziko odhalení chyb v návrhu, a proto je potřeba vrátit se zpět na začátek a opravit chyby. Vzniká tak zbytečné prodlužování a prodražování projektu.
1
Forma velkého třesku: Dodavatel zákazníka potřebuje pouze v úvodu projektu (specifikace požadavků) a poté na konci, kdy mu předává hotovou aplikaci. [3]
12
2.2.4 Spirálový model Spirálový model byl uveden v roce 1985. Za jeho vznikem stojí Barry Boehmen. Řadí se stejně jako vodopádový model k životnímu cyklu vývoje softwaru. Vývoj aplikace probíhá v opakovaných krocích - iteracích, které byly hlavním přínosem ve vývoji tohoto modelu. Na úvod projektu jsou stanoveny pouze obecné požadavky, vnější funkčnost a architektura. Poté se vyvine část aplikace a následuje konzultace se zákazníkem, kde je možné podrobněji specifikovat konkrétní situaci a následně pokračovat dalším krokem. Na začátku každé iterace je prováděna analýza rizik2. Jejím cílem je zjištění možných rizik v průběhu vývoje projektu. Hlavní výhodou tohoto modelu je jeho nezávislost. Model není závislý na speciálních metodikách či strategiích a proto je možné ho využít pro konkrétní postupy v závislosti na povahách projektů a zvláštnostech firmy. Model je možné využít i pro rozsáhlé projekty díky tomu, že klade velký důraz na plánování, ověřování a analýzu rizik. Pro vývoj webových aplikací se však tento model nehodí. Hlavní důvod je jeho zdlouhavý vývoj závislý na množství prováděných analýz a tvorby obsáhlé dokumentace. [3]
!"#$%&'(:(;(<.=#$2,/0(1,-&23(.4&/%56,(%(789( 2
Analýza rizik: myslitelné situace nebo události, které mohou způsobit nesplnění cílů projektu [3] např. dodání aplikace ve stanovený termín, implementace všech požadovaných funkcí, vztahy k nákladům, legislativě, konkurenci, apod.
13
2.3 Kategorizace metodik V předchozí části jsem se věnovala obsahu pojmu metodika a životním procesům, které daly prvopočátky pro vznik a rozvoj dalších metodik a procesů při budování IS/ICT3 či vývoji právě webových prezentací. Při budování jakékoliv webové prezentace nebo informačního systému je důležité použít tu správnou metodiku. Metodik existuje celá řada, nastává však otázka, jakou metodiku zvolit, aby měla právě takové vlastnosti, které charakterizují náš projekt. Proto jsem do kapitoly, která se zabývá metodikami, zahrnula i část, kde se budu věnovat rozdělování metodik do kategorií podle určitých kritérií. Vybrala bych pouze nejdůležitější kritéria a podle nich popsala základní členění. Jako hlavní zdroje pro tuto pasáž jsem použila publikaci [2], kterou můžu zároveň doporučit zájemcům, kteří se chtějí zabývat detailnějším popisem kategorizací metodik. Aby bylo možno metodiky dobře kategorizovat, je potřeba si nejprve stanovit důvody jejich existence. V díle uvádí autorka tzv. objektivní příčiny existence různých metodik. Musíme brát v potaz následující skutečnosti: •
Rozlišení technologií – různé technologie vyžadují různé techniky a metody (datově orientované metodiky vyhovují pro vývoj datově orientovaných aplikací, objektově orientované metodiky se více hodí pro projekty využívající objektově orientované technologie).
•
Analýza firemní kultury – možnou příčinou selhávání metodik je právě to, že nepočítají s firemní kulturou. Jiná firemní kultura může mít kladný ale i záporný vliv na implementaci metodiky.
•
Individualita jedinců a týmů – důležitým faktorem při vývoji informačního systému
jsou
lidé.
Každý
jedinec
má
jiné
charakteristické
vlastnosti - schopnosti, dovednosti, znalosti a způsoby dosažení cílů, proto nelze vytvořit jedinou metodiku, která by vyhovovala všem, ale je potřeba přizpůsobit ji konkrétním lidem či týmu lidí. •
Různé vlastnosti projektů – projekty můžeme rozlišovat podle velikosti týmu, důležitosti, postavení produktů na trhu či upřesnění vnějšího prostředí (např. projekty pro státní zakázky).
3
IS – informační systém, ICT – informační a komunikační technologie
14
Díky objektivním příčinám, je zřejmé, že existuje celá řada metodik. Aby bylo možné metodiky klasifikovat, je potřeba stanovit si kritéria. V publikaci [2] jsou vedena následující kritéria: •
zaměření
•
rozsah
•
váha
•
typ řešení
•
doména
•
přístup k řešení
Pro upřesnění bych uvedla stručnou charakteristiku každého kritéria. Zaměření metodiky Toto kritérium definuje dvě kategorie metodik – globální a projektové. Hlavní odlišnost těchto metodik je v jejich zaměření. Metodiky globální jsou zaměřené na vývoj, provoz a zavedení softwaru pro určitý subsystém, ale v rámci jednoho podniku. Kdežto metodiky projektové spadají do určité oblasti, ve které je implementován informační systém. Hlavním kritériem je určit, zda je metodika zaměřena na vývoj informačního systému celé organizace nebo jen na určitý projekt. Projektové metodiky jsou více publikované. Ke globálním metodikám patří např. MMDIS, CMM či MDA.4 Rozsah metodiky Rozsah metodiky stanoví tři hlediska, která podrobněji specifikují budování systému. Při vývoji systému je potřeba vymezit, kde metodika začíná a kde končí. Prvním hlediskem jsou fáze životního cyklu, ke kterým patří strategie (globální, informační), úvodní studie, analýza a návrh, implementace, zavádění a v neposlední řadě provoz a údržba. Dalším hlediskem je spolupráce specialistů, a proto se na budování informačního systému podílí typové skupiny spolupracovníků. Třetím posledním bodem jsou dimenze, které zahrnují detailnější specifikaci vyvíjeného softwaru. Patří k nim dimenze pokrývající požadavky na hardware, software, datovou základnu, uživatelské rozhraní, atd. 4
MMDIS – Multidimensional Management and Development of Information Systém; CMM – Capability Maturity Model; MDA – Model Driven Architecture [2]
15
Váha metodiky Podle váhy rozdělujeme metodiky na „lehké“ a „těžké“. Těžké metodiky jsou označovány jako rigorózní a vyznačují se tím, že mají přesně definované činnosti, procesy či artefakty5. Opakem jsou lehké metodiky neboli metodiky agilní. Jejich hlavní charakteristikou je rychlost a flexibilita vývoje aplikací. Vlastnosti metodik jsou definovány v pojmech - velikost, hustota a váha. Váha metodiky je potom shrnutí těchto pojmů. Typ řešení Typ řešení je kritérium, které podává informace o způsobu realizace řešení. Ve většině případů se nevyvíjí nový software, ale bývá implementován typový aplikační software. To může vést k rozdílnosti v metodice zavádění typového aplikačního softwaru a metodice vývoje softwaru. V současnosti jsou některé části informačních systémů zajišťovány externími specializovanými firmami, které se zabývají poskytováním aplikačních služeb. Doména Každý informační systém je vytvářen za podpory podnikových procesů. K podnikovým procesům se připojuje i řízení externích vztahů se zákazníky, dodavateli a ostatními partnery. Autorka publikace [2] uvádí, že specifikace domén pro účely kategorizace metodik vychází z aplikační architektury informačních systémů. Obecné schéma aplikační architektury zobrazuje jednotlivé části informačního systému. Jako příklady aplikační architektury bych uvedla např. Business Intelligence, SCM (Supply Chain Management), ERP (Enterprise Resource Planning), CRM (Customer Relationschip Management) atd.6 Přístup k řešení Hlavním cílem kritéria je poukázat na základní paradigma metodiky. Vývoj softwaru je tedy charakterizován přístupy, jež definují hlavní vývojové etapy - analýza, návrh a implementace. Přístupy můžou být orientované na strukturovaný vývoj, rychlý vývoj či objektově orientovaný vývoj.
5
Artefakt je specifikace reálných objektů [10] SCM – řízení dodavatelských řetězců, ERP – integrace podnikových aplikací, CRM – řízení vztahů se zákazníky [2]
6
16
2.3.1 Agilní vs. rigorózní metodiky Dnešní doba je charakterizována neustálým vývojem prakticky na každém našem kroku. Je tomu tak i při vývoji softwaru. Tato část vývoje informačních technologií je brána jako jedna z nejvíce proměnlivých oblastí. Změny jsou nejen v technických možnostech, technologiích, vývojových nástrojích, ale také v dostupnosti výpočetní techniky z hlediska kvality. Tady jsou počátky sílící konkurence, která se objevuje na poli výrobců softwaru. Rozdělení metodik na rigorózní a agilní souvisí do jisté míry s kritériem Váha metodiky. Jak je uvedeno výše, rozděluje toto kritérium metodiky na „lehké“, k těm patří spíše metodiky agilní a k „těžkým“ naopak rigorózní. [2] Rigorózní metodiky vycházejí z předpokladu získání všech potřebných požadavků na budování systému od zákazníků. Budování informačního systému tak vychází z původního vodopádového modelu, kde se dá přesně popsat a stanovit podrobná pravidla pro jeho plánování, řízení a měření. Probíhají zde jednotlivé fáze vývoje - plánování, analýza, návrh, implementace, zavedení. Metodika je tedy podrobně zaměřena na probíhající procesy ve vývoji softwaru. Předpokladem těchto podrobných procesů je dosažení kvalitního výsledku. S vývojem nových technologií, změnou požadavků na software a hlavně k urychlení vývoje systému, přestávaly rigorózní metodiky v těchto podmínkách vyhovovat. Bylo potřeba vytvořit metodiky, které umožnily řešit projekty pružně, rychle a dokázaly se okamžitě přizpůsobit měnícím se požadavkům. Tyto metodiky se nazývají agilní. Z hlediska významu slova agilní – „aktivní“, jsou tyto metodiky určeny pro širokou škálu softwarových projektů, převážně však pro internetové aplikace. Agilní metodiky se zaměřují na zákazníky a na kvalitu vyvíjeného softwaru. Při vývoji webové aplikace hraje hlavní roli čas, resp. rychlost. Vyvíjíme-li web déle než půl roku, hrozí zde riziko, že konkurence už dávno spustila dva jiné. Cílem agilních metodik je vyvinout aplikaci co nejrychleji, předložit zákazníkovi a na základně jeho zpětné vazby ji upravovat. U internetových aplikací také platí, že funkčnost lze vytvářet za „chodu“ aplikace. [2], [3]
17
3. Web a webové prezentace World-Wide-Web World-Wide-Web, často označován zkratkou WWW, Web či W3. Systém, který umožňuje uživateli přístup k různým typům informací v prostředí sítě Internet. V dnešní době si bez internetu většina lidí nedokáže svůj život ani představit. Internet se stává každodenní součástí našeho života. Kdo odejde ráno z domova, aniž by se předtím nepodíval, v kolik hodin mu jede tramvaj a do kolika mají otevřeno v jeho oblíbené restauraci? Člověk se s touto fenomenální službou sblížil tak rychle, že si ani nestačil uvědomit, jak ovlivňuje jeho sociální chování. Podle autorů publikace [6] stojí současný web na křižovatce vývoje – „na jedné straně narůstá množství informací na webu, na straně druhé narůstá i množství běžných uživatelů a tak současné technologie reprezentace a vyhledávání informací naráží na své limity.“ Aby tento problém mohl být vyřešen, je potřeba přenechat vyhledávání informací strojům a zajistit, aby komunikace s webem odpovídala přirozenému myšlení člověka. Uživatel WWW je tedy odkázán na práci s hypertextovými dokumenty. Hypertext je vlastně způsob pohledu na informace. Hypertextový dokument se skládá ze sítě uzlů, které představují části textových dokumentů, grafiku a tabulky a jsou mezi sebou propojeny vazbami. Z této definice můžeme pochopit význam slova web. Je to pavučina, která pomocí tenkých nitek přenosových cest umožní spojovat dokumenty po celém světě do jednoho celku. [7]
3.1 Vývoj WWW Původní myšlenka pro vznik WWW byla vytvoření jednotného globálního informačního prostoru. Znamenalo to vytvořit nějaké spojení, které by umožnilo počítačům sdílet informace. Tato myšlenka se zrodila v roce 1980 v Ženevě. Postupný vývoj tohoto propojení dal vzniku jedné z největších virtuálních sítí – World Wide
18
Web. Původně byl tento systém zamýšlen jako nástroj pro sdílení informací a dokumentů mezi vědci a vědeckými institucemi. [11] Jak už jsem se zmínila v předchozí kapitole, systém WWW je univerzální metoda, založena na principu hypertextu, který je charakterizován jako celek informací propojený systémem odkazů. Díky odkazům se pouhým „klikem“ dostaneme z jedné stránky k další. Uživatel pomocí internetu má možnost získávat spoustu nových informací. Velká výhoda webu je jeho nezávislost na platformě. Stránku si můžeme prohlížet na počítači s jakýmkoliv operačním systémem. Celá tato nezávislost je postavena na standardech (normách). Tyto standardy jsou v oblasti Internetu popsány v tzv. RFC dokumentech. Představují dokumenty, které definují oficiální fungování Internetu. Zabývají se tedy nejrůznějšími aspekty fungování Internetu, jako např. komunikace v rámci Internetu, formáty používaných datových struktur a také protokolů TCP/IP7. Standardy jsou volně šiřitelné a bezplatné, nevážou se na specifické vlastnosti daného operačního systému, takže se dají bez problému implementovat na všechny používaného platformy. [12], [15] Co bylo dále potřeba k tomu, aby Web mohl fungovat a čtenáři si tak mohli pročítat informace na internetu? Hypertext Markup Language (HTML), z anglického překladu se jedná o tzv. značkovací jazyk, který popisuje obsah webové stránky. Původní verze tohoto jazyka umožňovala rozčlenění textu do několika logických úrovní, použití prostředků pro zvýraznění textu a také možnost zařadit do textu odkazy a obrázky. Postupem času pronikala do internetu čím dál víc komerční sféra a tak bylo potřeba obohacovat tento jazyk o nové a lepší formátovací prvky (např. skriptovací jazyk (JavaScript), kaskádové styly8, apod.). [12] Pro dokonalé vysvětlení HTML jazyka nám ještě zbývá stručně objasnit pojmy SGML (Standard Generalized Markup Language) a DTD (Document Type Definition). SGML je metajazyk potřebný k definici různých značkovacích jazyků. Tento typ 7 8
TCP/IP – protokoly zabezpečující základní komunikaci v systému [13] CSS – Cascading Style Sheet – kolekce metod pro grafickou úpravu stránek [14]
19
dokumentu, ve kterém je definice, se nazývá DTD (Document Type Definition). Definice DTD nás informuje, které elementy a atributy (syntaxe) můžeme v dokumentu použít. Jednodušeji řečeno, SGML je programovací jazyk, který je v DTD zapsaný. S těmito pojmy souvisí i tzv. parsování. Programy „parsery“ jsou vytvořeny k tomu, aby kontrolovaly, zda dokument SGML vyhovuje DTD. Vyhověno je pouze v tom případě, že elementy, atributy a přípustné vztahy mezi elementy jsou nadefinovány v dokumentu DTD. Dokument je zkontrolován právě tehdy, pokud je „parser“ správně nakonfigurován a nalezne k němu odpovídající HTML. Postupem času, kdy se technologie webu zdokonaluje, bylo potřeba použít efektivnějších metod jazyka HTML. Tím mám na mysli vytvoření části textu s dynamickým významem (zvýraznění nadpisů, označení jednotlivých úseků, tabulek, atd.). Pomocí jazyka SGML si můžeme sice definovat vlastní sadu značek a docílit tak výstižnějšího označení jednotlivých částí textu. Avšak implementace SGML v programech bývá časově i finančně náročná. Proto bylo opět potřeba vytvořit jazyk, dostupný nejen velkým a finančně zajištěným firmám, ale i běžným uživatelům Webu. Členové konsorcia W3C9 tak vytvořili nový jazyk XML (eXtensible Markup Language), který je zjednodušenou verzí SGML. XML, stejně tak jako jeho předchůdci, patří mezi značkovací jazyky. Jelikož jazyk XML řadíme mezi standardy, můžeme pomocí něj generovat jazyky definované jednotnou cestou. [12] Spolu s jazykem bylo potřeba vytvořit program, který zformátuje daný text a zobrazí ho jako webovou stránku. Tímto pomocníkem mám na mysli webový prohlížeč (browser). Tento program komunikuje s HTTP serverem a zpracovává přijatý kód v daném jazyce. Vůbec prvním prohlížečem v historii byl WorldWideWeb, později přejmenován na Nexus. [16] V dnešní době se nám nabízí dostatek prohlížečů, které můžeme používat. Stačí si jen vybrat podle referencí či podle našich požadavků. Já osobně dávám přednost rychlým a bezpečným prohlížečům.
9
W3C – mezinárodní webové konsorcium vyvíjející webové standardy pro World Wide Web, přeloženo z [17]
20
Nejvíce používaný webový prohlížeč Internet Explorer, vyvíjený firmou Microsoft, se dostal na trh až v roce 1995 spolu s novým operačním systémem Windows 95. V současnosti je na trhu dostupná nejnovější verze Internet Explorer 8. [19] Pro zajímavost bych uvedla dva grafy nejpoužívanějších prohlížečů. K vybraným prohlížečům jsem zařadila Internet Explorer, Firefox, Safari a Google Chrome. Pro porovnání jsem vybrala grafy z let 2008 a 2010. Je možné zaznamenat rozdíly v procentuálním zastoupení používání webových prohlížečů v období těchto dvou let. Tyto data jsem čerpala ze serveru NetMarketShare.
Název prohlížeče
Používání % prosinec 2008
březen 2010
MS Internet Explorer
74,65
55,27
Firefox
18,15
20,53
Safari
1,39
3,77
Chrome
0,40
5,93
>5"?2'5()*(/25@6AB(%.#5C,/$AB(A5(%$'25-D(-56(%(7)E9(
21
(%*'& )! (! '! 56789:2,92:7;<=/-,2, &! >?,2@-< %! 6A@A,? ")*"&
$!
B.,-C2
#! "*$4 !*% "! ! +,-./0123
F#5G()(;(H&I.,?JB/5ADIKB(.#,L2BJ&M&(/ H&I.,?JB/5ADIKB(.#,L2BJ&M&(/(#,C&(:NNE3(%.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(%( %.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(%((7)E9(
'!
&&*#(
&!
%! 56789:2,92:7;<=/-,2, $! >?,2@-< #!*&$ B.,-Ce
#!
6A@A,? "!
&*4$
$*((
!
+,-./0123
F#5G(:(*((H&I.,?JB/5ADIKB(.#,L2BJ&M&(/ B/5ADIKB(.#,L2BJ&M&(/(#,C&(:N)N3(%.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(% #,C&(:N)N3(%.#5C,/$A,(A5(%$'25-D(.,@'O6A?60CL(-56(%(7)E9(
22
Ale vraťme se zpátky k webu. Principy systému WWW jsou založeny na architektuře klient/server10. Ve vztahu k webovým aplikacím je klientem myšlen právě webový prohlížeč. Základem tohoto modelu je vzájemná komunikace mezi uživatelem, klientem a serverem, zpracování dat a prezentace výsledků uživateli. Data jsou uložená na webovém serveru, kde také probíhá zpracování určitého požadavku od uživatele. Server poté odešle výsledky klientovi, který zobrazí stánku s požadovanými výsledky. Aby tato komunikace mohla probíhat, je potřeba si ještě definovat prostředky, na kterých je systém WWW postaven. V systému WWW se jedná o URL, HTTP, HTML a CGI. [7] V následujícím odstavci se zaměřím na charakteristiku pouze prvků URL, HTTP a CGI. Popis jazyka HTML byl popsán již v předchozí kapitole. URL (Uniform Resource Locator) je „lokátor“, který specifikuje zdroje na Internetu. Můžeme
ho
blíže
charakterizovat
jako
synonymum
internetové
adresy,
např. http: //www.seznam.cz – URL, které odkazuje na stránku Seznamu. [14] HTTP (HyperText Transfer Protocol) je protokol, díky kterému probíhá komunikace mezi klientem a serverem. Klient je internetový prohlížeč (Mozilla, Explorer) a HTTP server je program, který běží na jiném počítači (server), programem může být např. Apache. Celý proces se skládá ze dvou činností – klient zašle požadavek a tím navazuje vztah se serverem a server posílá odpověď klientovi na jeho požadavek. [7], [12] CGI (Common Gateway Interface) – technologie umožňující komunikaci s jakýmkoli programem. Definuje rozhraní, které umožní spuštění programů. V současnosti se ale používají dokonalejší technologie např. PHP11, J2EE12 nebo nejnovější technologie tvorby webových aplikací Ajax13. [6], [12]
10
model klient/server je určitá forma distribuovaného zpracování, kdy klient komunikuje se serverem s cílem vyměnit si informace mezi sebou. V našem případě chápeme tuto formu komunikace ve smyslu výpočetního modelu (softwarového). [7]
11
PHP – Personal Home Page – programovací jazyk pro tvorbu webové aplikace. [6]
23
Když všechny tyto poznatky shrneme, dojdeme k závěru, že princip WWW pracuje, laicky řečeno, formou dotazu a následné odpovědi. Tato komunikace probíhá pomocí protokolu HTTP. Pro tvorbu dokumentů potřebujeme znát HTML jazyk, abychom tyto „webové zdroje“ mohli umístit pomocí identifikátoru URL, který navíc zajistí vzájemné propojení pomocí odkazů. Díky všem těmto předpokladům může kdokoliv rychle zveřejnit jakékoliv informace. Na druhou stranu uživatelé pomocí webového prohlížeče mohou kdykoliv k těmto datům přistupovat, za podmínky počítače připojeného k internetu.
3.1.1 Statické a dynamické webové stránky Jelikož webové stránky jsou závislé na technologiích, které jsem stručně popsala v předchozí kapitole, závisí na nich i vývoj webových prezentací. Webové stránky se rozlišují podle statického a dynamického generování. V raných fázích internetu se využívaly statické webové stránky. Tento typ stránek je pouhou elektronickou kopií textu. Každá stránka je tvořena jedním HTML dokumentem a uživatel nemůže obsah stránky sám měnit. Je-li potřeba změnit nějaká data, upraví se určitý soubor. Statické stránky mají minimální nároky na HTTP server. Můžeme tedy říci, že stránky mají naprogramovanou pevnou podobu a k jakékoliv změně je potřeba odborníka. Statické stránky nejčastěji obsahují kontaktní informace (údaje o firmě, služby a produkty, atd.) a dokumentaci. [20] V minulosti statická povaha webových stránek nepředstavovala až takový problém, protože internet byl využíván hlavně jako výměna dat ve vědeckých sférách. V dnešní době se tento typ aplikace hodí spíše pro malé webové prezentace, které nepotřebují tak častou aktualizaci. Dynamické stránky jsou sestaveny ze statických textů a odkazů doplňovaných proměnlivými údaji. Tyto data jsou uložena v databázi (např. SQL) a aby mohla být data zpracována je potřeba programovací technologie a softwarový program. Tento program je umístěn na internetovém serveru a na základě požadavku vytvoří konkrétní 12
J2EE – Java 2 Enterprise Edition – základem této technologie je programovací jazyk Java, technologie vysoké úrovně z hlediska použití a výkonnosti. [6] 13
Ajax – technologie pro vývoj interaktivních webových aplikací [16]
24
webovou stránku, kterou odesílá do prohlížeče uživatele. Obsah stránky není předem uložen na HTTP serveru, ale požadovaná stránka, ve formátu HTML, se vytváří až podle dotazu uživatele. Dynamicky generované stránky kladou vysoké nároky na výkon serveru z důvodu objemného množství ukládaných informací. Příkladem dynamicky generovaných stránek jsou e-shopy, internetové bankovnictví, atd. Dynamické stránky se nejvíce rozrůstaly se vstupem komerčních oblastí, protože hlavním cílem tvorby webových stránek bylo poskytnout rychle a efektivně informace požadované uživatelem. Při vývoji dynamicky generovaných stránek sehrála velkou roli technologie. Stránky byly vytvářeny pomocí skriptovacích jazyků a databází. Jako příklad bych uvedla technologie CGI, skriptovací jazyk JavaScript, PHP a MySQL. [21], [22]
3.2 Webové prezentace V dnešní době je webových prezentací celá škála. Většina obchodníků si už nedokáže představit, že by nabídku produktů zapomněla zveřejnit na Internetu. Díky prezentaci na Internetu je zaručena celosvětová dostupnost. Kdokoliv po celém světě má k dispozici profil firem. Může publikovat všeobecné informace o firmě, její historii, tiskové či výroční zprávy. Zákazník se tímto způsobem dozví, jaké jsou možnosti pracovních příležitostí nebo také aktuální ceny produktů. Hlavním přínosem webové prezentace ze strany firem je zvýšení počtu zákazníků, které webová prezentace firmy zaujala a díky ní nakupují výrobky nebo mají zájem o aktuální volné pozice ve firmě.
3.2.1 Typy webových aplikací Podle autorů publikace [6] můžeme webové prezentace rozdělit do dvou skupin - informační aplikace a webové aplikace. Informační aplikace se týkají vyhledávání a prezentace informací, kdežto klasickými aplikacemi jsou myšleny ty, které se zaměřují na zpracování textů, grafů, grafiky, videa apod. Dříve se nekladl až takový důraz na použití webových technologií, hlavně z důvodu omezení pomalých sítí. Postupem času se technologie staly žádanější nejen z důvodu jejich zdokonalování, které bylo zabezpečeno rychlejším a bezpečnějším přenosem po síti, 25
ale také díky tlaku uživatelů z komerčních oblastí. Webové aplikace se začaly rozšiřovat a nabíraly stále více na komplexnosti. Z jednoduchých aplikací se stávají rozsáhlé informační a databázové projekty umístěné na podnikových portálech na internetu. Webové aplikace se dělí na kategorie: •
informační – pro čtenáře zajistí přísun informací - časopisy, knihy, noviny
•
interaktivní – online hry
•
transakční – uživatel může provádět různé bankovní operace (online bankovnictví), využít elektronického obchodování či odeslání objednávky zboží na internetu
•
workflow – týká se firemních procesů – online plánování, skladové hospodářství, sledování stavu firmy, atd.
•
online společenství – sociální sítě – chat skupiny, online aukce, atd.
•
prostředí pro spolupráci – např. e-learnigové kurzy s využitím multimediálních prostředků (video, audio, animace)
•
webové portály – podpora online služeb zákazníkům (např. elektronická nákupní střediska).
V této kapitole jsme se setkali se dvěma pojmy – aplikace a prezentace. Jaký je mezi nimi rozdíl? Obsahem webové prezentace jsou data, multimediální prvky – video, zvuk, obrázky. Cílem je pasivní předávání informací uživateli. Webové prezentace se nejčastěji využívají např. ve firmách, které chtějí zveřejnit seznam svých výrobků uživateli. Webová aplikace umožňuje uživateli, aby na základně zadaných dat obdržel z webového serveru výsledek. Online bankovnictví nebo e-shopy jsou typickým příkladem webové aplikace. Uživatel zadá data (požadavek na převod peněz, platba, objednání výrobku, atd.) a aplikace mu zpracuje jeho požadavek. Na závěr této kapitoly bych shrnula využití webových aplikací v dnešní době. Jak už jsem se zmínila v předchozích textech, nebýt těchto aplikací, neměl by Internet takové využití jaké má. Už jenom z důvodu možnosti provést určitou operaci na bankovním účtu – platby, převody peněz, může člověk využít internetové
26
bankovnictví, aniž by opustil svůj domov. Využití mají také rezervace letenek či hotelových pokojů. Co v dnešní době považuji za opravdový boom webu, jsou e-shopy. Člověk už nestráví zdlouhavé „chození po obchodech“, vybíráním určitého výrobku, hledáním nejnižší ceny. Stačí si vybrat několik „obchodních domů“ na internetu, porovnat parametry a ceny výrobku a jedním kliknutím si výrobek objednat. Je už na každém z nás, které typy výrobků jsme ochotni nakupovat pomocí e-shopů.
27
4. Specifikace požadavků na webové prezentace V úvodu této kapitoly bych podotkla hlavní prvky, které se odlišují ve vývoji webové aplikace a softwaru. Následovat bude část věnovaná specifikaci požadavků. Požadavek je „základní kámen“ vyvíjené aplikace. Cílem vývojářů je zjistit přání zákazníků na webovou aplikaci. Proces vývoje aplikace se neskládá jen ze sběru požadavků, ale obsahuje procesy jako je analýza, specifikace a kontrola.
4.1 Rozdíly ve vývoji softwaru a internetové aplikace Pro obecné vyjádření pojmů webová aplikace a prezentace budu používat pojem internetová aplikace, kterou myslím veškeré dostupné aplikace na internetu. Rozdíly ve vývoji internetových aplikací se týkají složení vývojového týmu a rozdílných klíčových prvků při vývoji celkové aplikace. Webové prezentace jsou oproti softwarům závislé i na typu webových prohlížečů. Z toho důvodu je potřeba, aby aplikace byla podporována nejpoužívanějšími prohlížeči. Důležitý rozdíl oproti softwaru je vize a cíl aplikace. Další popsané rozdíly jsou např. uživatelské prostředí a charakteristika zákazníků.
4.1.1 Webové inženýrství Vývoj softwaru a vývoj webových aplikací spadají každý do jiného odvětví. Vývoj softwaru zařadím spíše do oboru softwarového inženýrství, kdežto webové aplikace patří oboru webové inženýrství. Tento obor výpočetní techniky si dává za cíl prozkoumat určitá hlediska vývoje webových aplikací. Ke zdrojům, ze kterých webové inženýrství vychází, patří počítačové sítě, informační systémy, softwarové inženýrství, věda o počítačích, atd. Jelikož se objevují neustále novinky v oboru výpočetní techniky (vznik nových informačních technologií, atd.) je potřeba aby web tyto změny přijal. Díky tomu se webové inženýrství může neustále rozvíjet. [6]
28
4.1.2 Vývojový tým Dalším rozdílem je složení vývojového týmu. Podle mého názoru patří k důležitým osobám v týmu grafici a designeři. Jejich cílem je vytvořit prezentaci, která zaujme čtenáře. Dalšími osobami jsou: •
flash14programátoři
•
reklamní a propagační textaři
•
expert na kvalitní marketing website
Pokud se tvoří webová prezentace pro určitou organizaci, je zapotřebí, aby vývojový tým pracoval společně. [3]
4.1.3 Vývoj aplikace Rychlost O vývoji webové prezentace rozhodují jednotlivé dny. Webové prezentace si v poslední době nechávají vytvořit nejen firmy nebo lidé, kteří v něčem podnikají, ale také státní instituce, jako např. školy, organizace nabízející volnočasové aktivity, atd. Hlavní důvodem je zviditelnit se, přilákat nové zákazníky. Proto je důležité vyvinout prezentaci v co nejkratším čase, aby byla předběhnuta konkurence. Faktor rychlosti vývoje je tedy nejdůležitějším prvkem a hraje hlavní roli v úspěchu a neúspěchu prezentace. Někteří odborníci zavedli pojem „web-time“ – extrémní pojetí času při vývoji internetových aplikací. Web-time by však neměl zabránit vývojovému týmu vytvořit kvalitní aplikaci. [3]
14
Flash - animace napsané v programovacím jazyku Java. Tvorba multimediálních webů a dynamických aplikací. [16]
29
Budoucnost Rozdíl mezi internetovými a neinternetovými aplikacemi spočívá též v budoucnosti aplikace. Je potřeba brát na vědomí skutečnost, že postupem času se webová aplikace bude dále vyvíjet, vylepšovat a rozšiřovat o nové funkce. Bude se také měnit po stránce grafické a obsahové. Testování Testování internetových aplikací patří k důležité části vývoje. Testeři aplikací se specializují na dvě hlavní kritéria při testování: [8]
• Funkčnost: Testuje se funkčnost odkazů, správné zobrazení obrázků, požadovaný vzhled stránky, pravopis, obsah stránky, atd. • Použitelnost: Týká se vizuální a grafické stránky či rychlosti načítání stránek. Obsah stránky by měl být logicky uspořádaný tak, aby se uživatel dostal co nejmenším počtem kliknutí na požadované odkazy. Bohužel tuto část vývoje aplikace nelze provádět pomocí automatizovaných testů, ale testuje se tzv. „okem“. [3]
Prohlížeče Aby webová stránka byla dostupná celému světu, musí podporovat několik prohlížečů běžících na několika operačních systémech. U webových projektů existuje pouze jedna verze, kdežto software nebo ostatní informační systémy jsou dodávány pro konkrétní operační systém. [3] Výběr prohlížeče závisí na jeho použitelnosti uživatelů webových prezentací. Pokud by se stalo, že u konkrétního prohlížeče, který patří mezi často využívané, jsme znemožnili správně zobrazit webovou prezentaci (např. špatné zarovnání obrázků, nefunkční odkazy, špatně se zobrazující texty, atd.), můžeme snížit počet jednak budoucích čtenářů, návštěvníků, ale také přijít o nové klienty či zákazníky.
30
Uživatelské prostředí Webová aplikace má za cíl přilákat dostatek návštěvníků. Aby svým vzhledem zaujala, je potřeba vytvořit kreativní uživatelské prostředí. To spočívá v dodržování spojitosti ovládacích a navigačních prvků. [3] Další odlišností je prezentace informací. Vývoj webové aplikace vyžaduje dostatek pozornosti právě na prezentaci a formu textů. Nezbytnou osobou vývojového týmu je člověk, který se o tvorbu těchto textů postará. Internet je nejen provozní aplikace, ale též specifické médium prezentující informace.
4.1.4 Cíl, vize a uživatelé Dalšími důležitými prvky při vývoji internetové aplikace jsou jasné vize, cíl a účel prezentace. Cílem webu jsou věrní uživatelé. Je potřeba, aby webová prezentace měla dostatek zákazníků, kteří se na web často vracejí. Podle průzkumu agentury Forrest Research považují uživatelé za nejdůležitější kvalitní obsah stránky. Dalšími důvody, proč se čtenáři vracejí na jejich oblíbený web, jsou např. jednoduchost používání aplikace, rychlé stahování a pravidelná aktualizace. [3]
Cíle webové prezentace závisí samozřejmě na typu organizace, pro kterou je prezentace vyvíjena. Jedná-li se například o agenturu zprostředkovávající vzdělávací programy, bude hlavním cílem prezentace přehlednost a aktuálnost informací o jednotlivých vzdělávacích programech, seminářích či termínech. Dle mého názoru by firemní prezentace měla poskytnout zákazníkovy informace, které hledá. Není to pouze o kvalitě obsahu, ale o uspokojení zákazníkova hledání. Návštěvník webu by se měl dozvědět stručné informace o firmě a o její struktuře. Poté je důležitá nabídka produktů a popřípadě jejich snadné objednání pomocí například e-shopů. Zmíněná aktuálnost informací je pro firemní weby samozřejmostí. Představme si web, na kterém nebyla půl roku žádná změna. Taková webová prezentace svou aktuálností spíše zákazníky odradí, než přiláká. Tyto cíle je však
31
důležité si stanovit na počátku vývoje webové prezentace. Naplnění těchto cílů může být jedním z měřítek úspěšnosti prezentace. Další rozdíl mezi softwarem a internetovou aplikací jsou uživatelé. Na webu se uživatel nejdříve seznámí s aplikací a poté se teprve rozhodne, zda se stane zákazníkem (nákup produktů, registrace uživatele, atd.). Uživatel webové prezentace si tedy nemusí nic extra instalovat, rozhodnutí zda bude dále pokračovat „kliknutím“ na příslušný odkaz je pouze na něm. Kdežto u neinternetových aplikací si produkt nejprve zakoupí, nainstaluje a poté se dozvídá ostatní podrobnosti o produktu. [3]
Vývojáři webové aplikace by se měli soustředit na publikum, které bude aplikaci používat. Je důležité přesně charakterizovat typy uživatelů a důvody jejich návštěvnosti webu. Není však cílem stanovit jednoho obecného uživatele, ale zamyslet se nad typem lidí, kteří budou pravděpodobně koncovými uživateli. Uvedu několik základních bodů, které se vztahují k budoucím uživatelům webu: [8] •
věk
•
pohlaví
•
odborný jazyk
•
vzdělanost uživatelů a jejich znalost webu
•
technologické parametry – typ připojení, typ počítače
•
typ webového prohlížeče.
U většiny softwarů či informačních systémů (ERP, CRM, atd.) implementovaných pro konkrétní firmu je potřeba vycházet z procesů probíhajících ve firmě. [3]
Internetové aplikace jsou součástí vývoje softwaru, protože mají hodně společných vlastností. Při vývoji webových prezentací je ovšem nezbytně nutné zahrnout specifické rysy, které jsem popisovala.
32
4.2 Požadavky na webové aplikace Ještě než se dostaneme k vybraným metodikám vývoje, je důležité obecně definovat požadavky na webovou prezentaci. Jak už jsem se v předchozí kapitole zmínila, webové aplikace jsou součástí vývoje softwaru, proto budu vycházet z publikace [9], která se specializuje na detailní popis požadavků na software. Disciplína zabývající se zjišťováním požadavků na software pochází z anglického slova „requirements engineering“ a v překladu znamená „inženýrství požadavků“. [10] Specifikace požadavků je hlavním prvkem při vývoji softwaru, neboť se od ní odvíjí úspěch celého projektu. Pokud se nezapojí všichni uživatelé, kteří budou systém používat, či se podcení fáze tvorby požadavků, může to v budoucnosti vést k možným problémům.
4.2.1 Definice pojmů Specifikace požadavků Specifikace požadavků je dokument, tabulka, databáze nebo program pro správu požadavků. V tomto dokumentu jsou popsané všechny funkční požadavky. Tato dokumentace také popisuje chování výsledného systému. Obsahuje manuální a automatické požadavky na software, parametry systému, mezi které patří požadavky na výkonnost systému a kvalitativní parametry (popisující použitelnost, přenositelnost, integritu, rychlost nebo odolnost systému). Všechny tyto požadavky jsou srozumitelně popsány v jazyce uživatele. Mezi specifikace požadavků nepatří jak informace o plánování projektu a testování, tak podrobnosti návrhu či implementace. [9], [10]
33
Požadavek „Požadavek je cokoliv, co, ovlivňuje rozhodování při návrhu.“ Brian Lawrence [9] „Specifikace toho, co by mělo být implementováno”. [10] Požadavek může být charakterizován jako „stav či schopnost“, který docílí k vyřešení nějakého problému. Nebo jak vyplývá z druhé konkrétnější definice, je požadavek specifikace vyvíjeného systému. Co mají však charakteristiky společného je to, že požadavek je nějaký základ toho, co by měl vyvíjený systém dělat.
4.2.2 Typy požadavků Rozlišujeme 3 typy požadavků: [9] •
podnikatelské
•
uživatelské
•
funkční
A. podnikatelské požadavky Definují jasné cíle organizace nebo zákazníka, který požaduje systém. Většinou tyto požadavky popisují ekonomické, tržní, podnikatelské výhody, které zákazníci či vývojáři očekávají od projektu. Hlavními zástupci, kteří popisují požadavky, jsou budoucí zákazníci, vedoucí marketingového oddělení, produktový vizionář a hlavní investor. Tyto požadavky také definují případy užití, což je vyjádření podnikatelských cílů a úkolů v podobě diagramu.
34
B. uživatelské požadavky Popisují, co všechno je uživatel schopen se systémem dělat. Tyto cíle a úkoly uživatelů jsou zapisovány pomocí případů užití, scénářů či tabulek popisující reakce na různé události. Případy užití se od tradičního přístupu liší z hlediska sbírání požadavků. Místo toho, aby zjišťovaly od uživatelů, jak by měl systém pracovat, zjišťují, čeho potřebují uživatelé dosáhnout. Např. rezervace hotelu na webové prezentaci. Hlavní komponenty případu užití jsou: [10] •
hranice systému (system boundary) – stanovení hranic softwarového systému, respektive co je a co není součástí systému
•
aktéři (actors) – role, přidělené osobám či předmětům, které pracují se systémem. Například: žadatel, zákazník, správce systému, čas15, atd.
•
případy užití (use cases) – činnosti, které jsou iniciovány aktérem – např. zadat objednávku, poslat objednávku, atd.
•
relace (relationships) – vyjadřují vztahy mezi aktéry a případy užití.
Jako příklad bych uvedla jednoduché znázornění diagramu případu užití – objednávka produktu. Rámeček vyjadřuje subjekt a hranice systému, vztahy mezi aktéry a případy užití jsou vyjádřeny relacemi (zákazník – objednávka produktu, atd.). Rámeček nám též značí, které subjekty jsou umístěny uvnitř systému a které jsou mimo systém. Vnitřní část systému tvoří případy užití a vnější část je tvořena aktéry.
15
čas ve smyslu modelace něčeho, co se stane v určitý čas v systému, např. zálohování systému, které se automaticky spouští každý večer [10]
35
!"#$%&'(PQ(R=5S#51(.4B.5-T(?J=6B3(/25@6AB(%.#5C,/$AB3(%-#,I(7U93(7)N9(
Popis diagramu případů užití: Název subjektu: Systém objednání produktu Aktéři: •
zákazník
•
prodejce
•
skladník
Případy užití: •
objednávka produktu
•
platba produktu
•
převzetí produktu
•
kontrola platby
•
předání produktu
•
potvrzení objednávky
•
příjem objednávky
36
C. funkční požadavky (= behaviorální požadavky) Funkční požadavky popisují chování částí systému a funkcionalitu softwaru. Vývojáři musí tuto funkcionalitu softwaru dostat do systému, aby uživatelé mohli plnit své úkoly a s nimi také podnikatelské požadavky. Díky funkčním požadavkům jsou vývojáři schopni splnit cíle uživatelů a vytvořit požadované případy užití. Mezi typické věty těchto požadavků patří: „Potvrzení o přijetí transakce by systém měl zaslat uživateli.“ K dalšímu typu požadavků, patří systémové požadavky. Tyto požadavky představují celkové požadavky na produkt, který se skládá z většího počtu podsystémů. Systém se může skládat kompletně ze softwaru, nebo může kombinovat softwarové podsystémy s hardwarovými. Součástí systému jsou také lidé, kteří můžou obstarávat nějakou funkci. [9]
4.2.3 Vývoj požadavků V této fázi vývoje softwaru, v našem případě webové aplikace, se dostaneme k procesu získávání požadavků. Tento vývoj bude podán z pohledu vývojářů a analytiků. Opět mi při psaní této kapitoly posloužila publikace [9]. Požadavky na web nám podávají všechny potřebné informace k obsahu webu a kroky, dle kterých budeme web vyvíjet. Hlavním cílem společnosti či osoby vyvíjející web je vytvořit takový dokument, který co nejpřesněji popíše vznik webu, jeho dokončení a budoucí podobu aplikace. Vývoj požadavků rozdělím do 4 fází: sběr požadavků, analýza požadavků, specifikace požadavků, kontrola a správa požadavků. A. Sběr požadavků V této počáteční fází si nejprve analytik stanoví proces pro vývoj požadavků. Je to užitečné z hlediska odvedení dobré práce. Analytik si vytvoří postup, podle kterého
37
daná organizace sbírá, dokumentuje a kontroluje požadavky. V této fázi je důležité vytvořit plán a stanovit termíny a jednotlivé úkoly. V plánu je potřeba si stanovit důležité body: • cíl sbírání požadavků – ověření dat o trhu, vývoj požadavků z hlediska funkcionality systému • strategie a procesy získávání požadavků – např. průzkumy, workshopy, individuální konzultace se zákazníkem, apod. • typy výstupů – diagramy případů užití, specifikace požadavků (analýza výsledků průzkumu) a kvalitativních parametrů • časový harmonogram a potřebné zdroje – zástupci vývojářů a zákazníka jednotlivých aktivit, odhad potřebného času a úsilí • rizika – faktory, které můžou ohrozit dokončení těchto aktivit, najít způsob, jak předejít či zmírnit jejich dopad. Dalšími důležitými úkoly ve fázi sbírání požadavků, je zpracování vize a rozsahu projektu. Vize by všem účastníkům projektu měla podat společnou představu o cílech projektu. Analytik by měl poté vybrat skupinu uživatelů, kteří budou s aplikací nejvíce pracovat. Je potřeba si od těchto skupin uživatelů zjistit informace o požadovaných funkcích a kvalitě aplikace. Při vývoji webové aplikace nesmí vývojáři zapomenout na informace ohledně požadavků na design, funkce, obsah a název webu. Nejčastější prostředky k získávání požadavků: Konzultace Nejlepší způsob shromažďování požadavků. Abychom docílili opravdu kvalitních požadavků, je dobré rozhovor vést v příjemném prostředí, kde je uvolněná atmosféra než například v kanceláři. Autor publikace [10] doporučuje využít během pohovoru pro zachycení informací nejlépe obyčejný papír a tužku. Psaní na klávesnici notebooku vyrušuje a odvádí pozornost. Jako rychlý a graficky bohatý způsob shromažďování informací je dobré využít pojmové mapy. Pomocí pojmové mapy si rychle utřídíme získané informace a máme lepší přehled o vyvíjené aplikaci. 38
Během konzultací je dobré podávat takové otázky, na které není hned jasná odpověď ano/ne, ale odpověď, při které se zákazník více rozpovídá. Analytik tak může získat více informací a požadavků zákazníka na vyvíjenou aplikaci. Zákazník musí mít prostor, aby mohl dostatečně definovat své představy a potřeby na požadovanou aplikaci. Dotazníky Dotazníky nejsou tak vyčerpávající prostředky k zisku požadavků jako osobní rozhovory. Analytik se tak může ocitnout v situaci, kdy bude potřebovat více specifikovat zákazníkovy požadavky a bude muset dodělávat další dotazníky s velmi podrobnými otázkami. Dotazník je užitečný doplněk při konzultacích, kdy můžeme získat odpověď na konkrétní dotazy. Dílna požadavků Dílna požadavků patří k nejefektivnějšímu způsobu získávání požadavků. Dílna se převážně zaměřuje na hledání nových nápadů při diskuzi. K aktérům dílny patří sparingpartner, inženýr požadavků, nejdůležitější zainteresované osoby a experti v oboru. Inženýrství požadavků je iterativní proces založený na hledání požadavků. Trvá tak dlouho, dokud nemáme k dispozici všechny znalosti. Postup získávání požadavků je založen na spontánní diskuzi o hledání nových nápadů. Všechny definované nápady jsou přijaty a zaznamenány. Dále se zjistí nejdůležitější požadavky na aplikaci a každý požadavek se napíše na samostatný lísteček a nalepí na nástěnku. V konečné fázi sběru požadavků se připojí k požadavkům atributy. Po skončení schůzky bude vytvořena analýza výsledků. [10] B. Analýza požadavků Analýza požadavků je rozbor požadavků s cílem porozumění vyvíjené aplikaci a hledání chyb či nedostatků. Součástí analýzy je tvorba kontextového diagramu, který slouží ke grafickému vyjádření datových toků mezi koncovými prvky a systémem.
Koncové prvky
v diagramu představují třídu uživatelů, organizace či ostatní systémy a hardwarové zařízení. „Jádro“ tohoto diagramu představuje systém, který je tvořen kombinací softwaru, hardwaru a lidí. Činnosti probíhající mezi uživateli a systémem znázorňují datové toky. Tento diagram je samozřejmě spíše součástí analýzy požadavků při 39
vývoji softwaru. Při vývoji webové aplikace, dle mého názoru, přichází v úvahu tento diagram pro prezentace, v kterých probíhají nějaké procesy (datové toky), např. když může zákazník vyplnit a odeslat objednávku přímo z prostředí webové aplikace, nebo při zasílání dotazu a požadavků k určitému produktu. Při tvorbě kontextového diagramu je důležité dodržet jeho strukturu – kružnice. Cílem diagramu je znázornit jasnou a přesnou komunikaci mezi účastníky. Dalšími analytickými modely při analýze požadavků jsou např. ER diagramy, stavové diagramy, diagramy datových toků, mapy diagramů, diagramy tříd, atd. Tyto diagramy popisují abstraktní požadavky, neobsahují podrobnější specifikace. Pokud si vývojáři nejsou jisti přesnou podobou požadavků nebo chtějí detailnější zobrazení požadavků, vytvoří tzv. prototyp – technický a uživatelský. Jedná se zkušební implementaci, která pomůže k lepší představivosti řešeného problému. Aby nedošlo k chybám při definování datových typů či různých typů zápisů požadavků, je potřeba vytvořit si datový slovník. Datový slovník slouží všem uživatelům, kteří se na vývoji aplikace podílejí, používat jednotné definice dat (jména proměnných, jejich délka, kritéria,…). Příklad definice datových polí: definovaný výraz = definice (Objednávka = Číslo objednávky). [9] K účastníkům v této fázi analýzy patří: • zákazník (organizace, jednotlivec) - požaduje webovou aplikaci • uživatel – využívá aplikaci (zisk informací, nákup zboží, atd.) • analytik požadavků – sepisuje požadavky, předává je vývojářům • vývojář – návrh, implementace a údržba systému • tester – testování systému • grafici, designeři, programátoři – starají se o funkčnost a design aplikace • lidé z marketingového oddělení, technické podpory – správa obsahu webové aplikace. C. Specifikace požadavků Třetím hlavním bodem ve vývoji softwaru je specifikace požadavků, která přesně definuje funkce a omezení systému. Měla by detailně popsat chování systému za různých podmínek. Specifikace je zdrojem pro plánování, návrh, implementaci 40
a testování systému. Tyto požadavky je potřeba zpracovat do přehledné a čitelné podoby, aby je mohli zkontrolovat klíčový účastníci projektu. Častým způsobem je tvorba dokumentace v přirozeném jazyce, která je dostupná všem účastníkům projektu. Z praktického hlediska je nejpoužívanějším nástrojem pro dokumentaci grafický model, kde můžou uživatelé vidět různé transformace, stavy systému či vztahy
mezi
daty.
Formální
specifikace
patří
k nejpřesnější,
ale
i k nejpřísnější. Bohužel tato specifikace je špatně kontrolovatelná, protože se v ní nedokáže orientovat moc vývojářů, o zákaznících nemluvě. Nejefektivnější způsobem specifikace požadavků je však osobní komunikace v průběhu celého projektu. V této fázi vývoje nesmíme opomenout na cílové skupiny, které se na vývoji aplikace podílí. Hlavní cílovou skupinou jsou zákazníci, tedy ti kteří si webovou aplikaci objednali. Velkou roli zde hraje také oddělení marketingu a prodeje, protože webová stránka má za cíl představit produkty, které firma nabízí. Proto by lidé z těchto oddělení měli vědět, jakou aplikaci mají očekávat. Další skupinou je vývojářský tým, protože podle specifikace budou aplikaci implementovat. To samé platí u testovacího týmu, který specifikaci využívá při vývoji testovacích plánů či scénářů. D. Kontrola požadavků Abychom zabránili případným chybám při vývoji, je potřeba, aby požadavky prošly kontrolou, zda jsou správně napsané a splňují požadovaná kritéria. Je nezbytně nutné provést tzv. revizi dokumentace požadavků. Tato revize spočívá ve vytvoření týmu, skládajícího se z lidí různých pohledů – zákazník, analytik, vývojář a tester. Jejich cílem je najít chyby ve specifikaci, analytických modelech a ostatních informacích. Poté přicházejí na řadu specialisté z testovacích týmů, aby podle testovacích scénářů ověřili chování systému. Testování je potřeba si naplánovat předem a testovací scénáře začít psát už během odpovídající vývojové fáze. Kontrola požadavků zajistí, aby specifikace požadavků byla kvalitní a měla odpovídající vlastnosti (úplnost, správnost, ověřitelnost, atd.), správně popsala požadované vlastnosti systému a posloužila jako základna pro návrh a implementaci. Úvodní verze požadavků není finální verze. V průběhu vývoje aplikace se musíme smířit i s dalšími nevyhnutelnými změnami, které zákazníci, manažeři, vývojáři a marketing vyžadují. 41
5. Vybrané metodiky zjišťování požadavků uživatelů na webové prezentace V poslední kapitole jsem si vybrala čtyři metodiky, které jsou určeny pro vývoj webových prezentací. Dále jsem se rozhodla zařadit mezi ně i metodiku RUP (Rational Unified Process), která je, dle mého názoru, průkopníkem ve světě vývoje systémů. Metodiky stručně popíšu a poté se zaměřím na část zjišťování požadavků. Jako první metodiku budu popisovat metodiku RUP (Rational Unified Process). Tato medika patří k tzv. vývojovým procesům softwaru, je vytvořena a používána komerční společností Rational Software Corporation. [uml, agilni pgm] Dalšími metodikami, u kterých jsem se zaměřila na fázi zjišťování požadavků, jsou Web Modeling Language (WebML), metodika Jennifer Fleming a UML-Based Web Engneerign (UWE).
5.1.1 Metodika RUP Metodiku Rational Unified Process (RUP) považuji za důležitou z hlediska vývoje softwaru, protože patří k prvotním zástupcům objektově orientovaných metodik. Mimo jiné je to rozsáhlá a iterativní metodika vývoje softwaru. RUP má mnoho společného s metodikou UP (Unified Process), avšak hlavní rozdíl mezi těmito dvěma metodikami je v jejich dostupnosti uživatelům. UP je otevřený standard dostupný všem, kdežto RUP patří mezi produkt společnosti Rational. Jednoduše řečeno, RUP zařídíme ke komerční verzi metodiky Unified Process (UP), která je dodávaná společností IBM. [10] RUP patří do skupiny tzv. přístupů řízených případy použití (use-case-driven approach). Jako základní prvek metodiky RUP je považován případ použití, který znázorňuje posloupnost akcí prováděných systémem nebo uvnitř systému. [3] Metodika je založena na efektivním používání jazyka UML (Unified Modeling Language). UML je unifikovaný modelovací jazyk pro vizuální modelování systémů. UML se dá vcelku použít se všemi existujícími metodikami, avšak metodika UP (Unified Process) či RUP jsou považovány za přednostní. Pomocí jazyka UML 42
můžeme jasně pracovat s požadavky, architekturou a designem. Iterativní přístup umožňuje lepší porozumění problému prostřednictvím po sobě jdoucích činností. Iterativní vývoj tedy vychází ze spirálového modelu, který je založen na návaznosti jednotlivých fází a zjištění možných rizik. Každá z činností je prováděna jednorázově po skončení činnosti předcházející. RUP definuje čtyři základní prvky modelování. Díky těmto prvkům se modelují základní přístupy použití a pracovní postupy, z nichž se celý RUP skládá. Tyto prvky, odpovídají na otázky typu – kdo, co, jak a kdy. [23] Pracovníci a role Jako lidské zdroje zapojené do projektu označujeme „pracovníky“ (workers). Každý z pracovníků může zastávat jednu nebo více rolí (roles). Pracovníka si můžeme představit ne jako fyzickou osobu, ale spíše jako jakýsi „klobouk“, který si mohou pracovníci během projektu nasazovat a odkládat dle potřeby. Pracovníci dávají odpověď na otázku „kdo vytváří“ a jsou charakterizováni z hlediska odpovědnosti a chování. Chování je spojeno ve vztahu k činnostem a odpovědnost se týká „artefaktů“. Každý pracovník může tvořit, upravovat a kontrolovat určitou množinu artefaktů. Pro příklad uvádím přehlednou tabulku s pracovníky a jejich činnostmi.
Jméno
Pracovník
Činnost
Pavel
Designer
design objektů
Marie
Use-Case-Author
podrobná tvorba Use-Case
Jiří
Test designer
zodpovědnost za celkový úspěch testování, dohled nad testováním a stanovení strategií testování
Simona Architect
analýza a design architektury
Tabulka 1 – Lidé a pracovníci, převzato a upraveno z [3], [23]
43
Činnosti Činnost (activities) je souhrn akcí, které vykonává určitý pracovník, aby naplnil přesně definovaný účel činnosti. Díky činnosti mohou pracovníci vytvářet či modifikovat artefakty (meziprodukty). Činnosti odpovídají na otázku „jak vytváří“. Rozsah činnosti se může pohybovat od několika hodin až po několik dní, ale týká se pouze jednoho pracovníka a ovlivňuje malé množství artefaktů. [23] Činnosti dělíme do tří fází – úvahy (Thinking Steps), provádění (Perfoming Steps) a přezkoumání (Reviewing Steps). [3] Artefakty Artefakty neboli meziprodukty jsou hmotné výsledky projektu. Definují část informace, která je produkována, modifikována či použita v rámci procesu. Artefakty řeší otázku „co vytváří“. Mohou mít různé podoby, jako např. model, element modelu, dokument či zdrojový kód. Workflow Kompletní proces se neskládá jen z pracovníků, činností a artefaktů. Je potřeba ještě definovat smysluplnou posloupnost činností a spolupráci mezi pracovníky, což vede k požadovanému výsledku. Pracovní proces je nejčastěji modelovaný v UML jako sekvenční diagram, diagram činností nebo diagram spolupráce. Workflow odpovídá na otázku „kdy vytváří“. [3], [23]
Životní cyklus Vývojová část RUP se dělí na čtyři základní fáze, z nichž každá část je uspořádána do několika iterací. Fáze RUP: [3] 1. zahájení (Inception) - vývojáři zde definují účel a rozsah projektu 2. projektování
(Elaboration)
-
vývojáři
analyzují
potřeby projektu
a zákazníka a definují základy architektury 3. realizace (Construction) - v této fázi probíhá design aplikace a tvorba zdrojových kódů 44
4. předání (Transition) - předání projektu zákazníkovi či dalšímu vývojovému cyklu. Každá iterace je podrobně rozpracována a její počet závisí na určitých potřebách týmu a rozsahu projektu. Pro lepší znázornění výše popsaných fází, uvádím obrázek, v kterém je popsaný vývojový cyklus. Posloupnost cyklů, fází, iterací a kroků je popsána ve dvou úrovních.
!"#$%&'(V(;(+0/,I,/0(CO'2?@(/(1&6,-=C&(WXY3(.4&/%56,(%(7:P9(
Životní cyklus RUP rozlišuje celkem devět základních pracovních postupů (workflows), které zabezpečují, co je vše potřeba udělat, aby byly naplněny cíle projektu. Tyto klíčové postupy se dále dělí na dvě skupiny - „hlavní“ a „podpůrné“. [23] Zaměřím se pouze na skupiny „hlavní“, protože mezi ně spadají právě specifikace požadavků. Prvních šest pracovních postupů: •
tvorba podnikového modelu
•
správa požadavků
•
analýza a návrh
•
implementace 45
•
testování
•
nasazení
Ke zbylým třem „podpůrným“ procesům patří: •
řízení projektu
•
řízení změn a konfigurace projektu
•
správa prostředí
Správa požadavků Tato část by měla popsat specifikaci požadavků, která vede k úspěšnému vývoji systému. Jak už bylo v předchozích kapitolách řečeno, specifikace požadavků patří k důležitým prvkům ve vývoji systémů, v našem případě hlavně webových aplikací. Autoři publikace [25] charakterizují správu požadavků následující definicí:
•
systematický přístup ke zjišťování, organizování a dokumentaci požadavků na vyvíjený systém
•
proces zajišťující dohodu mezi zákazníkem a vývojovým týmem v případě změny požadavků na systém.
To znamená, že požadavky jsou kritéria vedoucí k úspěchu projektu. V přehledné dokumentaci je potřeba systematicky zaznamenávat a zapracovávat jejich případné změny. K osobám podílejících se na vývoji projektu v této činnost (správa požadavků) patří systémový analytik, SW architekt, osoba odpovědná za specifikaci případů užití a návrhář uživatelského rozhraní. Hlavním úkolem systémového analytika je zjišťování požadavků zadavatele na systém a jejich následná systematizace pomocí modelů případů užití. Pro sjednocení terminologie sepisuje společný slovník. Návrhář uživatelského rozhraní vytváří prototypy uživatelského rozhraní. Jeho dalšími úkoly jsou např. vyhodnocení a organizace uživatelských testů a aplikací či tvorba uživatelského rozhraní systému. Analytik případů užití a SW architekt se zabývá detailním zpracováním diagramů případů užití.
46
Správa požadavků se skládá z několika postupů, které blíže specifikují tvorbu požadavků na systém.
Postupy v rámci správy požadavků: a) Analýza problémové oblasti Klíčovou osobou v této fázi je systémový analytik a zadavatel (stakeholder). Systémový
analytik
na
základě
konzultací
se
zadavatelem
sepisuje
tzv. vizi, ve které přesně identifikuje a popisuje příslušný problém. Dále určí další osoby, kterých se daný problém týká a stanoví úspěšné řešení. Během analýzy problémové oblasti se také vytvoří společný slovník, který systematizuje používanou terminologii a odstraní případné duplicity ve formulaci problémů. Na závěr této části se identifikují aktéři systémů a možné závislosti mezi jednotlivými požadavky. b) Identifikace požadavků zadavatele Na základě předchozí analýzy problémové oblasti se stanoví, zda je reálné pokračovat v projektu. Poté se začíná se sběrem požadavků zadavatelů. Analytici mohou čerpat z mnoha zdrojů. Patří k nim všechny osoby se zájmem o vyvíjenou aplikaci. Od zákazníků přes koncové uživatele, partnery až po členy projektového týmu a samotný management. Nejčastějšími technikami zjišťování požadavků jsou rozhovory, dotazníky, brainstorming či pojmové prototypování. Výsledek sbírání požadavků je textové a grafická dokumentace. c) Definice systému Součástí třetí fáze je kompletní specifikace systému za použití prototypů nebo modelů případů užití. V definici jsou přesně popsané prvky, požadavky, jazyk vyvíjené aplikace, technická a obchodní rizika. d) Správa rozsahu systému Rozsah projektu je definován přiděleným souborem požadavků. Klíčem k úspěchu projektu je zabezpečit jeho rozsah tak, aby byl v souladu s dostupnými zdroji (čas, lidé a penize). Klíčové role v této fázi hrají atributy požadavků, kterými jsou priority, úsilí
47
a rizika. Tyto atributy patří k základním pravidlům vyjednávání určitých technik pro rozsah systému. e) Zpřesnění definice systému V tomto kroku se předpokládá, že jsou identifikováni všichni aktéři a případy užití a existuje k nim alespoň stručný popis. Cílem analytika případů užití je popsat do detailů jednotlivé případy užití (vstupní, výstupní podmínky, popisu skupin uživatelů, atd.) f) Řízení změn požadavků Počátečním zjišťováním požadavků, správa požadavků nekončí. Celá tato fáze musí brát v potaz případné změny. Systémový analytik rozhodne, čeho se změny týkají, zda softwaru nebo stávajícího požadavku či funkcionality. Následují stejné postupy, jako jsem popsala. Poté se požadavky předají ke zhodnocení pracovníkům zodpovídajících za část systému, kterého se změna dotkne. Závěrem bych podotkla, že změna požadavků není nepřítelem, ba naopak, přispívá k úspěšnému dokončení vyvíjené aplikace.
5.1.2 Metodika Jennifer Fleming Metodika, obdobně jako RUP patří mezi metodiky s iterativním charakterem. Tvůrkyní této metodiky je Jennifer Fleming16. Většina zdrojů k této metodice není dostupná v českém jazyce, ale spíše v angličtině. Pro zpracování jsem použila publikaci [3]. Podle autorky je v celém procesu důležité přesné sledování posloupnosti kroků a postupů. Z celkové úspěšnosti webové aplikace je podstatné získat spíše tzv. „nadhled“ nad systémem než dostatečný přehled o celkovém systému. Díky takovému způsobu uvažování by mělo být snadnější rozhodování o konkrétních činnostech. Cílem této metodiky je tedy mít dostatek informací, pomocí nichž můžeme stanovit globální strategie a určit dílčí cíle. 16
Jennifer Fleming – webová návrhářka a vývojářka, autorka knihy Web Navigation: Designing the User Experience [3]
48
Vývojový tým by měl pochopit vize aplikace a její přinos pro uživatele. Vývoj aplikace musí probíhat efektivním způsobem. Metodika se skládá ze šesti fází: Shromažďování informací •
podrobněji popsána níže
Stanovení strategie •
definuje obsah projektu a navrhuje možná řešení
•
cílem fáze je realizovat cíl webu a naplnit tak očekávání uživatelů
Vytvoření prototypu •
vývojové diagramy znázorňují typické „cesty“ pohybu uživatelů na webu
•
tvorba ukázek designu a testování funkčnosti webové stránky
•
vytvoření finální podoby architektury aplikace
Implementace •
potřeba souhlasu zadavatele k vytvoření kompletní stránky
•
příprava a editace obsahu pro použití na webu
•
dokončení grafického návrhu stránek a uživatelského rozhraní webu
•
naprogramování skriptů a spolupráce s databází
•
je nutné počítat s výskytem nových problémů
Uvedení do chodu •
před konečným spuštěním aplikace veřejnosti je potřeba provést testování (např. funkčnost odkazů, použitelnost, atd.)
•
obvykle je součástí vývojového týmu i aktivní marketing, který má na starost tvorbu reklamních bannerů
Údržba, správa a rozšiřování •
aktualizace obsahu, rozšiřování funkčnosti systému či změna designu
•
údržbu zajišťuje vývojový tým, zákazník nebo externí osoba. 49
Z hlediska zjišťování požadavků se více zaměříme na první fázi – Shromažďování informací. Fáze 1: Shromažďování informací Cílem fáze je zjištění dostatečného množství informací podporující úspěšné dokončení projektu. V této fázi se nezabýváme podrobnými a konkrétními stanovisky projektu, ale zjišťujeme takové informace, které vedou k pochopení projektu a podle nich usoudíme, zda je možné projekt vůbec realizovat. Detailnější popisy probíhají v ostatních fázích. Náplní fáze je: •
pochopení poslání projektu, jeho cíl a případná historie
•
definice cílové skupiny uživatelů
•
zajištění existence zdrojů – lidé, finance, technologie.
Zjišťování požadavků na webovou aplikaci je zajišťováno nejčastěji formou konverzace se zadavateli (budoucími uživateli) nebo využitím speciálních druhů dotazníků. Analytik požadavků by se měl také zaměřit na průzkum konkurenčních projektů a vyhledávat novinky v oboru projektu formou pročítání časopisů, novinových článků či knih. Posledním postupem ve fázi shromažďování informací je sledování budoucích uživatelů při jejich běžné práci, čímž docílíme lepšího vývoje aplikace a splníme tak jejich očekávání. Výsledkem této fáze je získání celkového přehledu o potřebách projektu. Vzniká také tzv. hrubý plán projektu obsahující základní informace o lidských zdrojích, rozpočtu projektu nebo obsahu a harmonogramu projektu. Tento dokument není finální verzí projektu, ale podléhá v průběhu vývoje změnám.
5.1.3 Metodika Web Modeling Language (WebML) Převážná většina dostupných zdrojů je v cizím jazyce. Čerpala jsem především z online zdrojů [26], [27].
50
WebML je poměrně mladá metodika, která vznikla v Itálii. Je to velmi propracovaná metodika s komerčním zázemím firmy WebRatio. Pomocí modelovacího jazyka jsou vývojáři schopni navrhnout hlavní rysy webové stránky na vysoké úrovni. Koncepty jazyka WebML jsou spojovány s grafickým ztvárněním, které lze snadno podporovat CASE nástroji17. Členové vývojového týmu (od grafiků až po producenty obsahu) je pak mohou efektivně zpracovávat. Základem metodiky WebML jsou čtyři modely: •
strukturální model – zabývá se daty, se kterými webová aplikace pracuje
•
hypertextový model – popisuje jeden či více hypertextů, které mohou být zveřejněny na webu; skládá se z dalších dvou rozdílných modelů – kompoziční a navigační model
•
prezentační model – prezentuje rozvržení a grafický vzhled stránek pomocí abstraktní XML syntaxe
•
uživatelský model - modeluje jednotlivé uživatele a skupiny uživatelů dle uživatelského kontextu v jednotlivých stránkách webové stránky, snaží se přizpůsobit stránky podle návštěvníka – např. stránky s možností nákupního košíku.
Fáze vývoje webové aplikace jsou shodné s klasickými fázemi vývoje softwaru. Patří mezi ně – sběr a specifikace požadavků, analýza, návrh, implementace, testování, nasazení a údržba. Metodika WebML definuje tzv. WebML Development Process, který obsahuje celý životní cyklus aplikace. Tento vývojový proces se skládá: •
specifikace požadavků na webovou aplikaci
•
návrh datové struktury
•
tvorba hypertextového modelu
17
CASE nástroje – počítačové programy použité při vývoji softwaru (např. UML, nástroj pro datové modelování, atd.)
51
•
návrh architektury aplikace a implementace
•
testování
•
nasazení a údržba aplikace
Pro zpracování požadavků na webové prezentace jsem se zaměřila opět na fázi specifikace požadavků. Tato fáze se dále dělí na dvě části – sběr požadavků a analýza požadavků. Sběr požadavků V této části vývoje se vytváří základní představa o vyvíjené aplikaci. Nejčastějším zdrojem zjišťování požadavků je rozhovor se zákazníkem. Je potřeba, aby zákazník věděl, co všechno má aplikace splňovat. Pro zkušenější společnosti slouží kvalitní specifikace požadavků jako podklad pro výběrové řízení dodavatele aplikace. Než je však přijato rozhodnutí o pořízení nové webové aplikace, je nutné projít určité kroky - např. proces schvalování nebo tvorba základní funkční specifikace. Při sběru požadavků je důležité rozlišovat zjištěné informace na funkční požadavky, které tvoří základní prvek specifikace. Pro zobrazení funkčních požadavků se používají Use Case diagramy. Dále je potřeba identifikovat jednotlivé typy uživatelů, kteří budou s aplikací pracovat. Tato část zjišťování je také součástí tvorby Use Case diagramů. S identifikací typů uživatelů souvisí další typ požadavku, a to požadavek na personalizaci. Webová aplikace nemusí mít zpřístupněn kompletní obsah a služby pro všechny uživatele. Mohou být stanovena přístupová práva (požadavek na personalizaci). Důležité je stanovit si požadavky na data, to znamená konkretizovat, jaká data mají aplikací být zpracována a prezentována. K dalším požadavkům patří např. informace o výkonnosti, bezpečnosti nebo rozšiřitelnosti aplikace.
Analýza požadavků Analýza požadavků nesouvisí přímo se sběrem požadavků, nicméně je součástí specifikace požadavků. Hlavním cílem analýzy je sjednotit a formalizovat posbírané požadavky uživatelů. Výsledkem specifikace požadavků jsou smysluplné a přehledné výstupy nejen pro uživatele (obchodníky), ale hlavně pro vývojáře. 52
Obsahem analýzy je roztřídit budoucí uživatele do skupin s využitím nástrojů Use Case diagramů. Je potřeba vytvořit datový slovník, aby byla zajištěna jednotná definice objektů (entit). K dalším prvkům analýzy požadavků patří tvorba mapy webu a shromáždění požadavků na grafický design aplikace. Posledním bodem analýzy jsou ověřovací testy hodnot podle jednotlivých kritérií.
53
5.1.4 Metodika UML-Based Web Engineering (UWE) UWE vznikla na konci 90. let. Patří opět k mladým metodikám ve vývoji webových aplikací. Tuto metodiku jsem vybrala z toho důvodu, že se její vývoj požadavků na webovou aplikaci odvíjí od metodiky UP18, která je velice podobná s metodikou RUP 19, popsanou na začátku této kapitoly. Při zpracování této metodiky jsem vycházela z publikace [24]. K hlavním znakům UWE patří standardní notace jazyka UML ve všech modelech, podrobný popis všech vytvářených modelů a specifikace omezení zvyšující přesnost jednotlivých modelů. Metodika UWE se skládá ze čtyř fází: •
analýza požadavků
•
konceptuální návrh
•
návrh navigace
•
návrh prezentace
Konceptuální návrh je model vyjadřující vzájemnou komunikaci mezi účastníky a systémem. Konceptuální analýza je závislá na analýze požadavků, a proto je komunikace vyjádřena pomocí diagramů případů užití. Návrh navigace Součástí návrhu navigace jsou další dva související modely. Model navigačního prostoru specifikuje objekty ve webové aplikaci, které mohou být navštívené při dané navigaci. Zatímco Model navigační struktury specifikuje způsob dosažení uvedených objektů při navigaci. Návrh prezentace Metodika nabízí tři hlavní metody pro prezentační návrh, které umožní co nejpřesněji popsat činnosti návrháře a dosáhnout tak stanoveného cíle. K základním metodám patří - náčrtky, prezentační tabule a model prezentačního toku. Dále se prezentační model skládá z množiny pohledů (views) zobrazující obsah, strukturu a způsob komunikace mezi uživatelem a webovou stránkou. 18 19
Unified Process Rational Unifed Process
54
Analýza požadavků Fázi analýza požadavků jsem si nechala na konec, protože je v této části nejdůležitější. Tato část vývoje aplikace je částečně shodná s metodikou UP. Hlavními účastníky analýzy jsou tzv. „pracovníci“ (Workers) a jejich vztah k případům užití (Use Case). Cíl analýzy požadavků nám odpovídá na to „kdo systém používá“ a „jaké od něj vyžaduje funkce“. To znamená, že analytici v této časti musí specifikovat skupinu uživatelů (Workers), kteří budou s aplikací pracovat. Poté zjišťují, jaké činnosti (activities) budou uživatelé vykonávat a potom je všechny seskupí do diagramů případů užití (Use Case). Dalšími kroky tvorby modelu aplikace je vyjádření vztahů mezi uživateli a případy užití a stanovení vztahů rozšíření mezi jednotlivými případy užití. V posledním kroku je možné použít prvek objektově orientovaného programování, kterým je dědičnost. Jelikož se metodika odvíjí od metodiky UP, nejčastější formou zjišťování požadavků budou osobní rozhovory či dotazníky.
55
6. Závěr Cílem mé bakalářské práce bylo porovnat metodiky zjišťování požadavků uživatelů. Tyto metodiky jsou z oblastí vývoje softwaru a webových prezentací. V druhé kapitole jsem obecně vysvětlila pojem metodika. Z historického hlediska jsem stručně popsala životní cykly vývoje aplikací. Posledním bodem této kapitoly je kategorizace metodik. Rozumí se tím výběr vhodné metodiky podle určitých kritérií charakterizujících software či webovou prezentaci. Protože vývoj webových prezentací je závislý na rychlosti, jsou pro tuto kategorii softwarů vhodné agilní metodiky. Jejich cílem je orientace na zákazníka a kvalita vyvíjené aplikace. Třetí kapitola je zaměřena na prostředí webových prezentací. Zabývala jsem se principy systému World-Wide-Web. Uživatel získává informace v podobě textu a multimédií, pomocí hypertextových dokumentů. S vývojem technologií už Web není pouhý prostředek pro získávání informací. Také velmi záleží na grafické úpravě. A díky databázím a skriptovacím jazykům je Web čím dál více podobný softwarové aplikaci. To má za následek zánik statických webových prezentací a vznik dynamických stránek. Ve čtvrté kapitole jsem se věnovala specifikaci požadavků. Při vývoji webových prezentací je to jedna z nejdůležitějších fází procesu. Cílem požadavků je stanovit hlavní parametry a vize vyvíjené prezentace. Dokument, ve kterém jsou všechny nároky sepsány, je tzv. specifikace požadavků. Analytici efektivně zjišťují, co zákazníci od prezentace očekávají. První konkrétní metodikou, kterou jsem se zabývala, je metodika RUP. Patří k objektově orientovaným metodikám. Správa požadavků je proces, ve kterém probíhá již zmíněné zjišťování požadavků a vede k úspěšnému vývoji systému. V první fází sepisuje zadavatelem tzv. vizi, ve které je popsán příslušný problém. Na základě vize, stanoví analytici, zda je možné přejít na další krok vývoje. V následujících fázích se přesně specifikuje požadovaný systém, určí se jeho rozsah a přidělí se role všem účastníkům projektu. V konečné fázi je důležité neopomínat možné změny systému 56
přispívající k úspěchu vyvíjené aplikace. Technikami zjišťování požadavků jsou rozhovory se zákazníkem. Metodika je určena především pro tvorbu softwaru. Ale z hlediska propracovanosti ji lze využít i pro vývoj webových prezentací. Metodika Jennifer Fleming není oproti metodice RUP tak rozsáhlá a propracovaná, ale jedná se spíše o specifikaci procesu vývoje webové aplikace. Fáze zjišťování požadavků je zaměřena na obecném pochopení vyvíjené aplikace. Nezajímá se o detaily, ale o účel tvorby prezentace. Zjišťování požadavků se provádí nejčastěji formou konverzace. Analytik by se měl o vyvíjenou prezentaci zajímat také z externích zdrojů např. zjišťováním novinek v oboru nebo průzkumem konkurence. Metodika je vhodná pro vývoj webové prezentace. Podpora metodiky WebML je založena na osvědčených principech metodiky RUP. Její vývojový proces začíná sběrem požadavků a končí údržbou aplikace. Sběr požadavků je téměř shodný s metodikou RUP. Specifikace obsahuje všechny zjištěné informace na webovou prezentaci. Identifikuje jednotlivé typy uživatelů, kteří budou s prezentací pracovat. Rozdíl oproti metodice RUP spočívá v požadavcích na personalizaci. Je potřeba stanovit různá přístupová práva uživatelům. Znamená to, že mají omezené funkce systému. Nejčastější technikou zjišťování jsou osobní rozhovory. Poslední porovnávanou metodikou je UWE. Stejně jako WebML patří k mladým metodikám ve vývoji webových aplikací. Opět je metodika postavena na principech RUP. Fáze analýza požadavků se zabývá zjišťováním funkcí systému. Jako RUP jsou v UWE začleněni „pracovníci“ a k nim přiřazené jejich „činnosti“. V metodice se používají prvky objektově orientovaného programování. Společnou vlastností metodik je jejich návaznost na metodiku RUP. Metodiku RUP bych označila jako výchozí metodiku, která je základem ostatních nově vyvíjených metodik.
57
7. Seznam zdrojů [1] Metodika In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 31. 8. 2009, [cit. 2010-03-31]. Dostupné z WWW:
.
[2]((BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. Praha : Grada, 2005. 163 s.
[3]((KADLEC, Václav. Agilní programování : Metodiky efektivního vývoje softwaru. Brno : Computer Press, 2004. 278 s. ISBN 80-251-0342-0.
[4] Metoda In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, [cit. 2010-03-31]. Dostupné z WWW: . [5] NEŠETŘIL, Vlastimil. Fázová organizace projektu a průběhové modely [online]. 2001 [cit. 2010-05-28]. Průběhové modely. Dostupné z WWW: . [6] BUREŠ, Miroslav; MORÁVEK, Adam; JELÍNEK, Ivan. Nová generace webových technologií : Informace v 21. století. Praha : VOX, 2005. 264 s. ISBN 8086324-46-X. [7] HENDL, Jan; SKLENÁK, Vilém. Metody zpracování informací III : Hypertextové systémy . Praha : Vysoká škola ekonomická v Praze, 1997. 293 s. ISBN 80-7079-896-3. [8] ECCHER, Clint. Profesionální Web design : techniky a vzorová řešení. Brno : CP Books , 2005. 421 s. ISBN 80-251-0547-4. [9] WIEGERS, Karl E. Požadavky na software. Brno : Computer Press, 2008. 448 s. ISBN 978-80-251-1877-1. 58
[10] ARLOW, Jim; NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací. Brno : Computer Press, 2007. 567 s. ISBN 978-80-251-1503-9. [11] BARABÁSI, Albert-László. V pavučině sítí. Praha : Paseka, 2005. 274 s. ISBN 80-7185-751-3. [12] KOSEK, Jiří. HTML:Tvorba dokonalých WWW stránek. Praha : Grada, 1998. Historie a vývoj HTML, s. 15-23. ISBN 80-7169-608-0.
[13] KREJČÍ, Aleš. Informatika:Technologie Internetu. Brno:Vysoké učení technické, Fakulta stavební, 2004. 69 s. [14] JANOVSKÝ, Dušan. Jak psát web [online]. 2010 [cit. 2010-05-26]. CSS kaskádové styly. Dostupné z WWW: . [15] MUSIL, Marek. Historie sítě Internet [online]. 2003 [cit. 2010-05-26]. RFC dokument. Dostupné z WWW: . [16] ASLESON, Ryan; SCHUTTA, Nathaniel T. Ajax: Vytváříme vysoce interaktivní webové aplikace. Brno : Computer Press, 2006. Stručná historie webových aplikací, Historie prohlížeců, Evoluce webových aplikací, s. 269. ISBN 80-251-1285-3. [17] World Wide Web Consorcium [online]. c2010 [cit. 2010-05-26]. Dostupné z WWW: . [18] NetMarketShare [online]. c2010 [cit. 2010-05-26]. Browser version market share. Dostupné z WWW: . [19] Microsoft:Internet Explorer [online]. c2010 [cit. 2010-05-26]. Dostupné z WWW: .
[20] Tvorba web stránek [online]. 2010 [cit. 2010-05-27]. Výroba web stránek. Dostupné z WWW: .
59
[21] Svět hardware [online]. c2010 [cit. 2010-05-27]. Dynamický web. Dostupné z WWW: .
[22] MediaCentrik [online]. 2010 [cit. 2010-05-27]. Dynamické webové stránky. Dostupné z WWW: . (
[23] Rational Unified Process : Best Practise for Software Development Teams [online]. c1998 [cit. 2010-05-28]. Dostupné z WWW: . [24] MOLHANEC, Martin. Metodika UWE [online]. Praha : České vysoké učení technické, 2005 [cit. 2010-05-28]. Dostupné z WWW: . (
[25] Applying Requirements Management with Use Cases [online]. c2000 [cit. 2010-05-28]. Dostupné z WWW: <www.ibm.com>. [26] ZELENKA, Petr WebML - proces vývoje webové aplikace (specifikace požadavků). In Interval.cz. 2004 [cit. 2010-03-27]. Dostupné z WWW: . (
[27] MOLHANEC, Martin. Novinky ve webových metodikách [online]. Praha : Vysoké učení technické, 2010 [cit. 2010-05-28]. Dostupné z WWW: .
60
