Úvodní analýza projektu

Před tím, než se pustíte do projektu, je třeba provést analýzu. Pokud jde o velmi jednoduchý projekt, je zkušený vývojář schopný provést analýzu jen v hlavě a pustit se do programování. Metoda programování na zelené louce bez analýzy je vhodná pouze pro velmi jednoduché projekty a rozhodně není vhodný v případě, kdy se jedná o projekt zadaný zákazníkem.

Se zákazníkem je před zahájením programových prací nutné dohodnout platformu, rozsah funkčnosti a specifikovat přesně chování programu. Takto sepsaný dokument si pak nechat zadavatelem podepsat, protože od něj se odvíjí odhad pracnosti a finanční náročnost projektu. Jakékoliv další úpravy nebo změny funkčnosti nad dohodnutý rozsah prací pak znamenají další jednání, rozšíření návrhu projektu a obvykle další náklady. V případě, kdy nebudete mít v ruce podepsaný návrh projektu, budou další jednání velmi obtížná a z projektu, který z počátku vypadá jako velmi snadný výdělek se stává "noční můra".

Jako příklad projektu v našem článku si vezmeme Rezervační systém pokojů v hotelu

Zahájení projektu

Projekt začíná sběrem požadavků. Cílem je co nejpodrobnější zjištění způsobu práce, informací o prostředí a požadavků na budoucí projekt. Čím víc informací získáme, tím lepší analýzu budeme schopni udělat a výsledkem bude projekt, se kterým bude spokojen vývojář i zákazník.

Krok 1. Rozhovor se zadavatelem

Vydáme se za zadavatelem, obvykle je to nějaký manažer, vedoucí nebo ředitel hotelu a vyslechneme požadavky na rezervační systém.

Dozvíme se zřejmě něco takového:
Potřebujeme rezervační systém. Naše představy jsou takové, že host si na našich webových stránkách zjistí volné pokoje v určitém termínu a případně provede předběžnou rezervaci. Od vedoucího se obvykle více informací nedozvíte, kromě otázek kdy to bude hotové a kolik to bude stát.
V této chvíli si dohodneme možnost návštěvy recepce, zjistíme si jméno nějakého šikovného člověka, se kterým bychom se mohli pobavit o reálném provozu a zajistíme, aby byl člověk vyrozuměn o tom, že jej navštívíte a budete se jej ptát. Mnohem vhodnější je v tomto případě recepční, který na recepci pracuje několik let a má zkušenosti i z jiných hotelů než sličná studentka, která je tam na 14-ti denní brigádě.

Krok 2. Návštěva provozu

Promluvíme si s recepcí o tom, jak to ve skutečnosti v hotelu funguje. Zjistíme, že existují určité kategorie pokojů podle výbavy, podle počtu lůžek. Zmapujeme varianty pokojů, vybavení, cenové relace.
Zjistíme, že hosté si pokoje nejen rezervují, ale také ruší rezervace ruší nebo mění termíny. A to mohou udělat buď opět přes internet nebo telefonicky.
Zjistíme si způsob potvrzení předběžné rezervace, jak dlouho bývá pokoj rezervován bez potvrzení, jaké informace chtějí hosté o pokoji znát.
Vhodné je používat v programu termíny, které se používají v reálném provozu. Nebudeme "hotelového hosta" v programu označovat jako "osobu", "pokoj" jako "místnost" apod. S programem nebudete pracovat vy, ale obsluha.

Krok 3. Zpracování sběru požadavků

Z našich poznámek nám vyplynou určité termíny, které budou později v programu představovat objekty:

- host
- pokoj
- recepce
- rezervace
- vybavení pokoje

Objeví se také činnosti, které budou představovat funkce programu:

- host hledá volné pokoje pro zadaný termín
- host se zaregistruje
- host provede rezervaci
- host změní nebo zruší rezervaci
- recepce potvrdí rezervaci
- recepce změní nebo zruší rezervaci
- ...

Zpracování analýzy

Pro zachycení této fáze analýzy se používá Diagram případů použití (Use case diagram).

Máme zde 2 účastníky (actor), kteří budou systém používat určitými způsoby (use case). Z předchozího diagramu je velmi dobře vidět, že host vykonává podmnožinu funkcí, kterou vykonává recepce. Takže recepční bude v našem programu jen osobou, která bude mít vyšší pravomoci než host - bude mít dostupných více funkcí programu. Určitě by bylo zbytečné programovat stejné věci 2x a dělat zvlášť tabulku pro hosty a další tabulku pro pracovníky recepce.

Následuje slovní popis funkce programu

Příklad 1 - přihlášení uživatele

- Host si zvolí odkaz "přihlášení"
- Systém zobrazí přihlašovací dialog
- Host vyplní uživatelské jméno a heslo
- Systém ověří zadané údaje v seznamu hostů
- Pokud je vše OK, systém zpřístupní další funkce programu
- Alternativy: chybné jméno - systém zobrazí chybový dialog a vrátí se do přihlašovacího dialogu
- Předpoklady: běží internetový server a webové stránky jsou funkční
- Důsledky: systém si zapamatuje přihlášeného uživatele

Příklad 2 - provedení rezervace

- Host zvolí odkaz "nová rezervace"
- Systém zobrazí dialog pro zadání rezervace (termín, parametry pokoje)
- Host vyplní požadavek na rezervaci
- Systém vyhledá volné pokoje a zobrazí seznam pokojů
- Host zvolí pokoj a provede předběžnou rezervaci
- Systém zapíše předběžnou rezervaci do seznamu rezervací
- Důsledky: pokoj bude pro daný termín rezervován

Všimněte si, že zde máme několik typů informací. Datové (seznam hostů), rozhraní - interface (odkaz přihlášení, přihlašovací dialog, chybový dialog) a řídící (systém zobrazí, systém ověří, sytém zpřístupní). Je vhodné tyto informace rozlišovat v popisu barevně, pomůže nám to později při programování.

Takto zpracovaný popis všech případů (use case) pak budeme konzultovat se zadavatelem, popř. s pracovníky recepce, provedeme úpravy, které z konzultace vyplynou. Zkusíme zjistit, zda se počítá s rozvojem (rozšiřováním funkčnosti) aplikace a kterým směrem by se rozšiřování mělo ubírat. Může nám to v budoucnu ušetřit spoustu práce.

Návrh architektury

Návrh architektury probíhá současně s analýzou a popisem aplikace. Cílem návrhu architektury je:

- návrh platformy (programovací jazyk, databáze)
- rozhodnutí o tom, zda bude aplikace vícevrstvá
- rozdělení aplikace na samostatné funkční celky
- možnost lokalizace
- řízení chyb

V této chvíli naše předběžná obecná analýza končí a začínají už konkrétní práce jako návrh tabulek, frameworku, vytvoření společných systémových funkcí, návrh grafiky...