Liší se vývoj pro web od vývoje neinternetových aplikací?

Hlavním posláním softwarového inženýrství, již od doby svého vzniku, je formulovat odpovědi na otázky spojené s vývojem a s údržbou softwaru. V současnosti zažívají prudký rozmach internetové projekty. Vykazuje tento druh softwarových aplikací nějaké odlišnosti od klasických (ve smyslu „neinternetových“) tříd projektů? Musíme tyto rozdíly zahrnout do přístupu k vývoji?
Před časem jsme se na Živě zabývali problémem klasických metodologií softwarového inženýrství a vyslovili jsme hypotézu, že standardní softwarově inženýrské techniky a metodologie přestávají v současnosti pomalu vyhovovat – zejména s ohledem na požadavek rychlosti. V diskusi pod článkem zazněla řada cenných názorů vycházejících přímo z praxe – od vývojářů, programátorů, členů týmů. Z příspěvků bylo patrné, že situace opravdu není jednoduchá; zákazníci obvykle požadují především rychlost, ale zároveň tlačí na vysokou kvalitu a snaží se prosadit co největší šíři zadání (co nejvíce funkcí).

Diskutující se však zároveň shodují v tom, že „odfláknutý“ návrh není řešením.

Posléze, v dalších článcích, jsme se seznámili s myšlenkami agilního přístupu k programování. Poznali jsme Manifest agilního vývoje, pochopili důvody jeho vzniku a mnohé historické souvislosti.

Slíbil jsem, že v následujících článcích se budeme zabývat některými konkrétními agilními metodologiemi. Protože ale v současné době se formuje nová, velmi početná skupina softwarových projektů – internetové aplikace, rád bych se při rozboru metodologií zabýval i otázkou, zda jsou konkrétní metodologie vhodné pro vývoj této třídy aplikací a jakým způsobem vůbec při jejich vývoji postupovat.

Dnešní článek by měl sloužit jako podklad pro budoucí úvahy o využitelnosti jednotlivých agilních (i jiných) metodologií pro webový vývoj. Rád bych se tedy pokusil shrnout základní odlišnosti a specifika internetových projektů v konfrontaci s běžnými (ve smyslu „neinternetovými“) aplikacemi.

Vývojový tým a vývoj obecně

První rozdíl spočívá již v nutném složení vývojového týmu, který u webových aplikací musí zahrnovat i netradiční profese a role, např. grafiky, Flash programátory, reklamní a propagační textaře apod. Je vyloučeno, aby jednotliví členové týmu byli izolováni: u webové aplikace ovlivní rozhodnutí přijaté jedním členem ostatní mnohem více. Prolínání činností navíc znemožňuje jednoznačné stanovení hranic odpovědnosti. U některých projektů je navíc nutné zajistit i vhodný aktivní marketing website, i na tuto činnost se vyplatí mít v týmu experta (nebo s ním přinejmenším být v kontaktu).

Liší se též požadovaná rychlost vývoje. Žádný zákazník nečeká rád dlouho na dodávku softwaru; u internetových projektů je však často rychlost dodání jedním z nejdůležitějších faktorů úspěchu či neúspěchu. U webových aplikací rozhodují často jednotlivé dny; prezentace spuštěná se zpožděním je automaticky znevýhodněna. Vzhledem k tomu doporučují některé metodologie modifikovat standardní rozhodovací proces „koupit či vyvinout“ (develop or purchase) ve prospěch nákupu; je-li možné pořídit již hotovou architekturu a znovuvyužít existující řešení, téměř vždy se to vyplatí. Někteří odborníci v souvislosti s vývojem webových aplikací zavedli pojem „web-time“. Upozorňují tak na extrémní pojetí času při vývoji internetových projektů. Dodávají však, že ani web-time nesmí vývojovému týmu zabránit vyprodukovat kvalitní aplikaci, jejíž rozšiřitelnost (na webu skoro nevyhnutelná) nebude nemožná.

Rozdíly lze též spatřovat právě v předpokládané budoucnosti aplikace. U webových projektů je téměř jisté, že se budou postupem času vyvíjet, rozšiřovat, vylepšovat a upravovat; budou přibývat funkce a měnit se vzhled. Návrh webové aplikace by měl být proveden s vědomím této skutečnosti; změnit grafický vzhled website by nemělo vyžadovat měsíc práce.

Aby webová aplikace mohla uživatelům přinést unikátní hodnotu, měl by její vývoj začínat jasným stanovením vize, cílů, účelu projektu. Neexistující jednotná vize se na kvalitě website viditelně projeví.

Zásadní rozdíly lze nalézt též v přístupu k testování. Testeři internetových aplikací si musí vštípit mnoho neotřelých postupů, např. testování layoutu stránky, grafického návrhu, barev na obrazovce, rozlišení. Jedná se o oblasti, které lze otestovat výhradně okem, automatizované testy nepřicházejí v úvahu.

Platformy, systémy, prohlížeče

Mnoho klasických projektů je dodáváno přímo pro jednu konkrétní platformu a požadavek multiplatformní podpory se řeší dodáním více verzí. Naproti tomu u webových projektů existuje fyzicky pouze jedna verze website, která musí podporovat několik prohlížečů běžících na několika operačních systémech.

Uživatelské prostředí

Vývoj webové aplikace vyžaduje kladení značného důrazu na kreativní návrh uživatelského prostředí. V prostředí internetu, kde konkurence je vzdálena pouze jedno klepnutí myší, musí aplikace rychle zaujmout svým vzhledem, v opačném případě zapadne do šedého průměru a nenajde příliš uživatelů. Stan Ward a Per Kroll uvádějí v materiálu o vývoji internetových aplikací při použití metodologie Rationa Unified Process, že nikdy předtím nebylo tak důležité uživatelské rozhraní aplikací, jako je dnes na webu.

Internetová aplikace, která chce působit profesionálně, by měla dodržovat konzistenci ovládacích a navigačních prvků; měla by mít jasně definovanou koncepci a řídit se jí napříč všemi stránkami. U běžných aplikací je konzistence zajištěna implicitně např. použitím standardních systémových ovládacích prvků; požadavek kreativního grafického návrhu nutí vývojáře zvolit u webových aplikací vlastní ovládací prvky, takže konzistence musí být vědomě a cíleně budována.

Odlišná je také prezentace informací. Zatímco při vývoji běžných aplikací není obvykle nutné klást zvláštní důraz na formu textů a způsob předávání informace, web vyžaduje opak. Na internet je nutné pohlížet nejen jako na provozní platformu aplikace, ale též jako na specifické médium pro prezentaci informací. U webu je nesmírně důležité vhodné strukturování textu, komunikace se čtenáři/uživateli, personalizace a předávání informací se souvisejícími referencemi (včetně těch, které vedou na jiný server). Důsledkem pro vývojový tým je nutnost mít ve svém středu alespoň jednoho tvůrce webových textů, „neprogramátora“; pouhé přelití firemních materiálů na web nezajistí úspěch projektu.

Zákazník

Na webu je praxe taková, že uživatel se s aplikací nejprve důkladně seznámí, a pak se rozhodne, stane-li se zákazníkem (zaregistruje-li se, nakoupí-li apod.). U běžných aplikací někdy tuto možnost nemá; stane se zákazníkem (zaplatí za produkt) a teprve se zpožděním se dozví všechny podrobnosti o vlastnostech produktu, jeho ovládání, chybách apod. V poslední době ovšem konkurence nutí všechny výrobce softwaru poskytovat natolik sofistikované demoverze, že se tento rozdíl prakticky stírá. Stále však platí, že uživatel webu není nucen pořídit a instalovat aplikaci; namísto toho si důkladně prohlédne website a na místě se rozhodne, jestli klepne dál nebo nikoliv.

Při vývoji klasické aplikace, typicky na zakázku pro konkrétní společnost, je důležité vysledovat pracovní procesy probíhající v dané společnosti a vytvořit aplikaci v souladu s nimi, jinak si koncoví uživatelé (z řad zaměstnanců společnosti) na používání aplikace nezvyknout. U internetové aplikace je naopak důležité rozbít představu, že aplikace musí sledovat firemní procesy. Aplikace musí především vycházet z potřeb uživatelů, které např. nezajímá, jak je společnost interně rozdělena na oddělení. Není-li toto dělení intuitivní a logické i pro okolní svět, neměl by web být podle něj členěn.

Cíle webových prezentací

Primárním cílem webu by neměla být honba za počtem unikátních uživatelů; ti nejsou dlouhodobě přínosní. Důležitější jsou věrní uživatelé, kteří se na web vracejí. Agentura Forrester Research provedla výzkum, v němž se zeptala 8900 uživatelů internetu na důvody, proč se vracet na některé weby. Výsledkem studie bylo zjištění, že lidé po webu požadují především 4 věci:

  • kvalitní obsah
  • snadné používání
  • častá aktualizace obsahu
  • minimální doba nutná ke stažení

Jacob Nielsen, světově uznávaný odborník v oblasti návrhu webu, ve své knize Web.Design přidává k uvedeným čtyřem bodům další tři kritéria:

  • uspokojení potřeb zákazníka (nestačí poskytovat kvalitní obsah; obsah musí mít vůči zákazníkovi určitou relevanci a musí mu poskytnout to, co hledá)
  • unikátnost online média (způsob prezentace musí odpovídat charakteru online média)
  • firemní kultura v souladu s obsahem webu (celá firma musí web přijmout a stát za ním)

Podrobnosti o splnění těchto kritérií, stejně jako doporučené konkrétní postupy návrhu website spadají do oblasti webdesignu a navigace. Některé metodologie, jimiž se budeme zabývat v příštích článcích, definují vlastní kroky k dosažení uvedených kritérií. Snaha o uspokojení potřeb zákazníka (přesněji různých potřeb různých zákazníků) může být realizována např. pomocí několika skupin případů použití, které jsou vytvářeny zvláště pro různé skupiny uživatelů. (Poznámka: případ použití je textový popis definující posloupnost akcí prováděných uvnitř systému či systémem, která poskytuje určitou hodnotu uživateli systému. Tento koncept používá např. Rational Unified Process).

Na závěr

Internetové aplikace samozřejmě spadají do kategorie softwaru a mají s ním mnoho společných rysů, na druhé straně však vykazují některé klíčové odlišnosti. Z toho důvodu je nutné při jejich vývoji mírně modifikovat tradiční softwarově-inženýrské postupy, aby zvláštní charakter webu zůstal zachován a website byla úspěšná.

Diskuze (13) Další článek: Pozor na falešné procesory AMD Athlon XP

Témata článku: Software, Programování, Stan, Vývoj, Různé důvody, Webová prezentace, Ovládací aplikace, Purchase, Jednotlivý člen, Běžná aplikace, Běžný zákazník, Různé požadavky, Aplikace, Častá aktualizace, Primární projekt, Relevance, Existující řešení, Běžný uživatel, Vhodný uživatel, Rational, Jednotlivé prvky, Vhodná rychlost, Různé materiály, Odlišné zjištění, Nielsen

Určitě si přečtěte


Aktuální číslo časopisu Computer

Zachraňte nefunkční Windows

Jak nakupovat a prodávat kryptoměny

Otestovali jsme konvertibilní notebooky

Velký test 14 herních myší