WebML – proces vývoje webové aplikace (specifikace požadavků)

23. listopadu 2004

•

Předchozí články série o WebML se zabývaly především obsahem a provázáním jednotlivých modelů a způsobem, jak z modelu vygenerovat funkční aplikaci. Těžiště každé kvalitní metodologie představuje nejenom samotný obsah modelu, ale také návod, jak postupovat při vývoji aplikace. WebML v tomto ohledu nezůstává pozadu a definuje takzvaný WebML developmet process, který pokrývá celý životní cyklus projektu.

Fáze vývoje webové aplikace

Proces vývoje webové aplikace dle WebML do značné míry kopíruje klasické obecné schéma vývoje softwaru, na kterém už je těžko co vylepšovat a které se skládá z následujících fází:

sběr a specifikace požadavků
analýza
návrh
implementace
testování
nasazení a údržba

WebML klade důraz především na úvodní fáze celého procesu vývoje, tedy na fáze sběru požadavků, analýzy a návrhu. Implementace jako taková není přímou součástí WebML a je spíše otázkou vývojového prostředí WebRatio. Takzvaný WebML development process se skládá z následujících fází:

specifikace požadavků na webovou aplikaci
návrh datové struktury
tvorba hypertextového modelu
návrh architektury aplikace a implementace
testování
nasazení a údržba aplikace

V tomto článku se budu věnovat první fázi procesu, tedy specifikaci požadavků na aplikaci.

Význam specifikace požadavků

Každý vývojář, který má nějaké zkušenosti s tvorbou komerčního software, musí jistě uznat, jak kritický krok tato fáze při vývoji představuje. Na kvalitní specifikaci požadavků přímo závisí úspěch celého projektu. Mezi kvalitou zadání a kvalitou výsledného produktu platí nesporně přímá úměra.

Je až s podivem, jak často je tato fáze podceňována a jak často se i velké projekty rozjíždějí s velmi nepřesným zadáním s tím, že doufáme, že se vše upřesní až v průběhu vývoje. To je ale dle mých zkušeností nejrychlejší cesta do pekel. Zkušený vývojář totiž ví, jak nepříjemná může být nepatrná změna zadání, která vede například ke změně datové struktury aplikace a následnému přepisování poloviny zdrojového kódu. Nejčastějším důsledkem nedotaženého zadání je potom minimálně odkládání termínu dokončení projektu a s tím související nárůst nákladů nebo případných penále za nedodržení smlouvy.

Vraťme se ale k WebML, které specifikaci požadavků dělí na dvě fáze:

sběr požadavků
analýza požadavků

Sběr požadavků

V této fázi si musíme vytvořit základní představu o budované aplikaci. Zdrojem informací se mohou stát především rozhovory se zákazníkem. Velice užitečné pro nás mohou být již existující dokumenty nejrůznějšího typu.

Velké množství zákazníků již má alespoň částečnou představu o tom, co vlastně chce. Zkušenější společnosti připravují kvalitní specifikaci požadavků jako podklad pro výběrové řízení na dodavatele aplikace. Rozhodnutí o pořízení nové webové aplikace nebo prezentace nepřichází ve většině případů znenadále, ale předchází mu určité kroky, například proces schvalovaní, zda společnost novou prezentaci nebo aplikaci potřebuje. Součástí těchto kroků bývá vytvoření základní funkční specifikace, která nám může velice pomoci.

Nejhorším a také velmi častým případem jsou zákazníci typu „Já tomu nerozumím, nechám si od Vás poradit“. Dle mých zkušeností jsou tito zákazníci daleko horší než ti, kteří od začátku pořád něco řeší, sondují okolí a stále se (někdy velice nepříjemně) na něco vyptávají. Zákazník, který zpočátku dává najevo svou odevzdanost „nám odborníkům“, dokáže být poději velice nepříjemný a často se omezuje pouze na destruktivní kritiku všeho, co pracně a nákladně vymyslíme.

WebML rozlišuje následující typy informací a oblastí, kterými bychom se měli při sběru požadavků zabývat:

Funkční požadavky: Tvoří základní stavební kámen specifikace. Jedná se o funkce, které musí systém realizovat. Jako velice vhodný formální nástroj k zobrazení funkčních požadavků se dají použít takzvané UseCase diagramy.
Identifikace uživatelů: Nezbytné je identifikovat jednotlivé typy uživatelů, kteří s naší aplikací budou pracovat a rozeznat skupiny uživatelů. Tento úkol bývá součástí tvorby UseCase diagramů.
Požadavky na personalizaci: Musíme si uvědomit, zda obsah a služby aplikace budou pro všechny uživatele totožné, nebo je požadována personalizace aplikace (přístupová práva a podobně).
Požadavky na data: Musíme si ujasnit, jaká data mají být aplikací zpracovávána a prezentována. Zde se jedná pouze o základní koncept. Podrobněji se datům věnujeme při vytváření datového modelu aplikace.
Ostatní požadavky: Jedná se především o klasické charakteristiky jakosti informačních systémů, které můžeme nalézt v normě ISO/IEC 9126.
- Použitelnost: Srozumitelnost, snadná obsluhovatelnost a atraktivnost aplikace (prezentace).
- Výkonnost: Většinou stanovovaná jako počet požadavků respektive přístupů do aplikace za časovou jednotku (například aplikace musí obsloužit 100 požadavků za sekundu).
- Dostupnost: Většinou stanovená v procentech jako čas, kdy aplikace funguje bez problémů (často kolem 99 %).
- Škálovatelnost: Možnost zvyšovat výkon aplikace (například využitím techniky content switch).
- Bezpečnost: Zabýváme se ochranou osobních údajů, silou ověřovacích mechanismů, ukládáním hesel, šifrováním přenosu.
- Rozšiřitelnost: Možnost přidávat další funkce aplikace, úroveň modularity. Zde záleží především na architektuře a technologii, na které je aplikace postavena.

Analýza požadavků

Pokud jsme skončili se sběrem požadavků, musíme tyto často nepřehledné a v různých formách posbírané fragmenty nějakým způsobem sjednotit a formalizovat. Specifikace požadavků musí mít samozřejmě srozumitelné a přehledné výstupy, jak pro obchodníky, tak pro vývojáře.

Výstupy analýzy požadavků kopírují do značné míry skupiny požadavků zmiňované v předchozím textu a budou popsány v následujících odstavcích.

Skupiny uživatelů

Měli bychom identifikovat potenciální uživatele a roztřídit je do skupin. Pro každou skupinu bychom měli sepsat následující údaje:

Jednoduchý slovní popis skupiny.
Informace, které chceme o uživatelích této skupiny ukládat.
Nadřízená a podřízená skupina, pokud existuje hierarchie mezi skupinami uživatelů.
Relevantní případy užití z UseCase diagramů.
Data, ke kterým bude mít uživatel přístup na čtení, a data, která bude moci uživatel dané skupiny spravovat.

UseCase diagramy

UseCase diagram je jedním z nejužitečnějších nástrojů pro úvodní analýzu softwarové aplikace. S jejich použitím se můžeme setkat především v UML, které je převzalo z metodologie OMT Jamese Rumbaugha (Rumbaugh’s Object Modeling Technique).

Tvorba UseCase diagramů a specifikace jednotlivých skupin uživatelů se navzájem doplňují. Participant z UseCase modelu představuje skupinu uživatelů a každá skupina uživatelů má své relevantní případy užití (UseCases). Pro každý případ užití musíme specifikovat především jeho účel, dále vstupní a výstupní podmínky a průběh případu užití.

Jako klasický příklad případu užití můžeme označit přihlášení administrátora do systému. Vstupní podmínkou zde je existence registrace příslušného uživatele, výstupní podmínkou úspěšné přihlášení a načtení uživatelského prostředí relevantního pro danou skupinu uživatelů. V popisu průběhu tohoto UseCase můžeme například uvést, že je nutné, aby uživatel zadal přihlašovací údaje, které jsou potom ověřovány proti databázi, a že na základě skupiny je uživatel přesměrován na výchozí stránku administračního rozhraní.

Podrobnější informace o UseCase diagramech se můžete dočíst zde na Intervalu v seriálu o UML.

Datový slovník

Při vytváření datového slovníku musíme na základě sebraných požadavků identifikovat základní objekty, respektive entity, které v systému vystupují a které budeme chtít ukládat v databázi. Pro každý z takto identifikovaných objektů musíme specifikovat:

jméno
stručný popis
základní a na první pohled zřejmé atributy
zřejmé vztahy s jinými objekty
příklady takového objektu

Mapa webu

Ve chvíli, kdy vytváříme mapu webu, musíme znát jednotlivé uživatelské skupiny, případy užití a datový slovník.

Výstupem je jedna či více map vytvářené aplikace nebo webu, dle počtu uživatelských skupin a požadavků na personalizaci aplikace. Každá personalizovaná mapa webu představuje jeden pohled na webovou prezentaci, který známe z hypertextového modelu WebML.

Pro každou mapu bychom měli uvést:

Jméno.
Stručný popis.
Cílové uživatelské skupiny, pro které je tento pohled relevantní.
Případy užití, které tato mapa implementuje.
Oblasti dané mapy, pokud je rozsáhlejší.

Viz též článek Artefakty informační architektury – navigační systémy a související.

Základní fragmenty grafického designu aplikace

Požadavky na grafický design jsou někdy stanoveny zákazníkem. Především u větších firem se musí brát ohled na corporate identity, kterou má daná společnost často již vytvořenou a jejíž součástí je provedení základních grafických prvků, barevná schémata, logo a další. Jindy naopak začínáme na zelené louce, ale ve všech případech musí být shromážděny požadavky na následující fragmenty grafického uživatelského rozhraní:

layout prezentace
logo a umístění loga na webu
menu, typ menu, umístění menu, úrovně zanoření menu
barevné schéma
fonty pro nadpisy a běžné texty
styly zobrazování seznamů, tabulek a dalších objektů

Nedílnou součástí požadavků na grafický design je kompatibilita aplikace s nejpoužívanějšími webovými prohlížeči.

Ověřovací testy a ostatní požadavky

Ověřovací testy se týkají především požadavků, které nepatří mezi takzvané funkční požadavky. Při stanovení ověřovacích testů se jedná o přesné určení hodnot, kterých musí dosáhnout naše aplikace v jednotlivých kritériích a jednotlivých kategoriích požadavků. Dále musíme určit způsob, kterým bude splnění těchto požadavků ověřeno.

Zajímají nás následující údaje:

Výkonnost: Musíme specifikovat, jakým způsobem budou probíhat výkonnostní testy a jaké hodnoty jsou od naší aplikace požadovány (například vystavení 100 stránek za sekundu ve veřejné části aplikace).
Dostupnost: Stanovíme dostupnost, kterou bude muset aplikace splňovat (například aplikace bude z 98 % plně funkční). Případně se stanoví sankce za nedodržení těchto podmínek.
Škálovatelnost: Měli bychom být schopni stanovit, jak může být zvýšen výkon aplikace v případě potřeby a zda je to vůbec možné.
Bezpečnost: Musí se naplánovat způsob, kterým budou probíhat testy bezpečnosti aplikace, a jaké výsledky jsou pro zákazníka přijatelné.
Udržovatelnost a rozšiřitelnost: Musíme specifikovat, zda bude možné nadále rozšiřovat aplikaci o další funkčnost a jak by byl celý proces časově a finančně náročný.

Platnost použitých principů

Principy specifikace požadavků na webovou aplikaci, které byly prezentovány v tomto článku, nejsou v žádném případě omezeny pouze na metodologii WebML. Naopak jsou obecně použitelné pro vývoj libovolné webové aplikace. Rozhodně se nejedná o žádný novátorský přístup k úvodní části analýzy. Autoři WebML se netají tím, že čerpají ze zaběhnutých a osvědčených postupů, které se již nějakou dobu používají a jsou součástí i mnoha jiných metodik.