Proč je prvotní analýza jakéhokoliv projektu k programování extrémně důležitá
Analýza k programování projektu je vhodná od složitějších webů a eshopů. Například pro webovou aplikaci, která má administrovatelné stránky s novinkami a fotogalerií není nutná analýza. Ale je alespoň dobré si určit obsah a funkčnost administrovatelných stránek.
Například novinky budou obsahovat datum, název, text, obrázek a na webu se budou zobrazovat od nejnovější novinky, kde výpis novinek bude se zkráceným textem, stránkováním a možností zobrazení detailu. V detailu bude obsažena všechna data novinky.
Před programováním projektu je zapotřebí provedení analýzy. Se zákazníkem se dohodne funkčnost a chování aplikace. Vytvořený dokument si obě strany podepíší. Od tohoto dokumentu se poté odvijí finanční náročnost a pracnost projektu. Další úpravy nebo změny funkčnosti nad dohodnutý rozsah prací, pak znamená další jednání a často i další náklady.
Nyní Vás seznámím se základy analýzy, kde pro lepší představu ukážu na stručném příkladu. Tato analýza není určena pro větší projekty, kde se na projektu podílí desítky lidí.
Analýza rezervací v restauraci
- Pro projekt posbíráme co nejvíce funčních podkladů a požadavků. Čím více informací získáme, tím lepší analýzu budeme moci udělat a s výsledným projektem bude zákazník i my spokojeni.
- Pro chod aplikace se potřebujeme seznámit co nejpodrobněji s chodem a průběhem rezervací v daném zařízení. Zmapujeme si prostory, počty míst pro rezervace, všechny možné činnosti ohledně rezervací, kde zjistíme, že si hosté nebudou pouze zadávat rezervace, ale budou si je i stornovat. Co se týká popisků a textů, tak ty přizpůsobíme dle zvyklosti obsluhy a hostů, protože to oni budou ti, kdo bude program používat.
- Zpracujeme posbíraná data. V našem programu budou představovat objekty:
- host
- stůl
- židle
- rezervace
- místnost
- Budeme mít i čínnosti, které v programu představují funkce:
- host hledá místa k rezervaci
- host si rezervuje místa
- host si zruší rezervaci
- host si prohlédne rezervace
- obsluha změní nebo zruší rezervaci
- obsluha vloží rezervaci
- obsluha potvrdí rezervaci
- …
- Zpracujeme analýzu. K tomu se používá Diagram případů použití (Use Case Diagram)
V ukázce máme 2 účastníky co používají systém. U hosta je zřejmé, že vykonává podmnožinu funkcí, které vykonává obsluha, z toho nám vyplývá, že obsluha má vyšší pravomoc.
- Slovně si popíšeme funkčnost programu - rezervace.
- Host zvolí odkaz „Rezervace“
- Systém zobrazí místnosti
- Host si vybere místnost pro rezervaci
- Systém zobrazí obsazenost dané místnosti
- Host si zvolí počet míst (případně stůl, židle)
- Systém ověří volnost zvolených míst
- Host vyplní kontaktní údaje
- Host odešle rezervaci
- Systém ověří kontaktní údaje a volnost zvolených míst, pokud je vše OK, systém odešle předběžnou rezervaci k potvrzení obsluze a zobrazí úspěšné odeslání
- Alternativy: chybné kontaktní údaje, obsazené místo – systém vráti chybovou hlášku a vrátí se zpět ke kontrole nebo případné změně hostem
- Předpoklady: běží server a webové stránky fungují
- Důsledky: systém si zapíše rezervaci
Z ukázky zde vidíme několik typů informací. Datové (obsazená, volná místa), rozhraní (odkaz rezervace, výpis míst pro rezervaci, chybový dialog) a řídící (systém zobrazí, systém ověří,...)
Jen pro představu můžete podobnou funkčnost nalézt na stránkách http://www.lvidvur.cz .
Takto vypracovaný popis všech případů se prokonzultuje se zákazníkem, případně pracovníkem obsluhy v restauraci a případně provedeme úpravy, které vyplynou z konzultace. Pokusíme se zjistit, jestli se počítá s rozšířováním funkčnosti aplikace a jakým směrem se prípadně bude rozvoj ubírat. V budoucnu by nám to mohlo ušetřit spousty práce.
- Navrhneme architekturu, která bude obsahovat:
- programovací jazyk
- databáze
- zda bude aplikace vícevrstvá
- bude aplikace rozdělena na samostatné funkční celky
- možnosti lokalizace
- řízení chyb
- …
Tímto naše předběžní analýza končí a bude se přecházet ke konkrétním pracem, návrhu grafiky, vytvoření šablon, programování, …
Při vytvoření analýzy si předejdeme do budoucna ke zbytečným dohadům se špatnou nebo neúplnou funkčností systému. Složitému rozšiřování funkčnosti nebo předělání funkčnosti již vytvořeného systému. Jak již bylo řečeno, ušetříme si sami budoucí předělávání projektu a narůstající náklady na dokončení projektu do finální představy zákazníka.
