Co očekává business od analýzy?

V tomto dokumentu je uveden seznam toho, co zadavatel (BUS) očekává od analýzy. Pro všechny součásti analýzy je uvedeno, jak se vztahují k zadání. Pokud je v analýze uveden nějaký prvek či část, který není uveden v zadání, je to v analýze zdůvodněno (příklad pověřovací plán).

Analýza slouží k tomu, aby se v rámci projektu začalo pracovat na řešení problému, který byl popsán v zadání. Použití analytických výstupů je následující:

• IT definuje základní charakteristiky řešení v oblasti dat, funkcí, ovládání aplikace a způsob komunikace s již existujícími komponentami IS. Jedná se o obdobu plánu domu.
• Jednotlivé části analytických výstupů budou sloužit k provedení odhadů pracnosti jejich implementace. Takto je pak možné upřesnit plán projektu, nacenění projektu, případně zpřesnit úvahy o prioritách v rámci projektu.
• Určené části projektu budou sloužit jako podklad pro vypracování uživatelské dokumentace
• Popis funkcí a obrazovek slouží pro zadání testovacích případů

S ohledem na fakt, že analytické dokumenty musí být odsouhlaseny zadavatelem (někdy i vedoucími pracovníky businessu) je vhodné členit analýzu do těchto úrovní:

• Konceptuální: na této úrovni vznikají modely, které jsou srozumitelné zadavateli, neřeší se technické problémy.
• Logické a fyzické: postupné přenesení řešení do prostředí výpočetních systémů, tzn. do databáze a do kódů aplikace. Tato úroveň již není se zadavatelem konzultována. Je jen prověřována pomocí testovacích případů, připravených na konceptuální úrovni.

Sumárně řečeno: výsledkem analýzy je analytický dokument, který je něco jako smlouva mezi IT a BUS. Tato smlouva určuje, co se bude v dalších fázích projektu dělat, jak dlouho to bude trvat a jak se budou ověřovat dodané moduly. Při nedodržení závazků daných smlouvou je možné jasně určit, kdo smlouvu porušil a jakým způsobem bude sjednána náprava a jaký dopad to bude mít na další práce a průběh projektu.

Poznámka 1. V dokumentu nejsou záměrně uvedeny žádné prostředky a metody, jakými jsou jednotlivé části analýzy (modely) vyjádřeny.

Poznámka2. V konkrétní analýze budou uvedeny jen ty části z dále uvedeného seznamu, které jsou pro popis konkrétní aplikace relevantní. Tento výběr však je v preambuli analýzy uveden a vysvětlen.

Poznámka 3. V dokumentu není uvažována situace, že v dané organizaci je forma některých výstupů analýzy stanovena či usměrněna směrnicemi. Časté je to např. pro definování zásad uživatelského ovládání.

Aby analytický dokument (výstup analýzy) splnil očekávání uvedená nahoře musí obsahovat tyto části:

• Prembule/úvod: obecné vysvětlení vztahu analýzy k zadání, omezení a rozšíření, která byla zvolena, verze, návrh postupu projednání analýzy s BUS.
• Uživatelské role: základní popis potřebných uživatelských rolí
• Rozdělení aplikace do modulů, popis jejich účelu a popis jejich vzájemné komunikace. Dále je uvedeno přiřazení rolí k jednotlivým modulům
• Datový model: model datových struktur. Datový model se dodává v několika úrovních:
• Konceptuální, kde jsou uvedeny základní entity podstatné pro řešení, jejich atributy a vztahy. Dále jsou popsána základní pravidla vztahů v rámci datových struktur, tzv. business pravidla. Všechny ostatní úrovně vycházejí z konceptuálního datového modulu
• Logický, kde jsou uvedeny relační tabulky, jejich sloupce a vztahy k jiným tabulkám ve formě cizích klíčů. Dále pak constrainty, které reprezentují business pravidla z konceptuální úrovně.
• Fyzický, kde jsou uvedeny konkrétní databázové skripty pro založení datových struktur v rámci konkrétního databázového systému (např. Oracle)
• Základní koncepce uživatelského ovládání, zejména ve vztahu k jednotlivým modulům. Tzn.:
• způsob přihlašování do aplikace
• základní obrazovka aplikace, způsob zpřístupnění funkcí modulů,
• standard rozvržení formulářů a seznamů,
• pravidla aktivace/deaktivace datových a funkčních prvků,
• způsob ohlašování chyb a varování apod.
• Pokud jsou tyto záležitosti již definovány, odkaz na příslušné dokumenty a uvedení jen odlišností.
• U každého modulu jsou uvedeny (pokud některá část nemá pro daný modul smysl, není uvedena. V analýze je to však explicitně zmíněno):
• Seznam funkcí, které poskytuje a role, které jí mohou spustit
• Seznam obrazovek
• Seznam chybových zpráv
• U každé funkce modulu je uvedeno:
• Základní popis účelu funkce a taky rozlišení, zda jde o:
• interaktivní funkci, používající obrazovky a očekávající interakci uživatele, tzn. funkci, která pracuje nad jedním záznamem
• dávkovou funkci, která pracuje nad více záznamy v db (př. report)
• Podmínka pro spuštění funkce, tzv. pre condition.
• Role, které mohou funkci spustit
• Postup, jakým se funkce používá, někdy nazývaný scénář
• Obrazovky, které jsou v rámci tohoto postupu použity
• Výsledek úspěšného a neúspěšného provedení funkce
• U každé obrazovky je uvedeno/předvedeno:
• Základní rozvržení prvků obrazovky ve formě prototypu
• Popis datových prvků obrazovky: účel, forma (text, check box, radio button, popup, ..), formát (text, číslo, datum, …), kontroly
• Popis aktivních prvků obrazovky (tlačítko, odkaz, …)
• Popis kontrol mezi prvky
• Popis kontrol nad celou obrazovkou: při vstupu do obrazovky a výstupu z obrazovky

Další (možná) očekávání

Dobře provedená analýza by dále měla "pohlédnout" i za hranice problému, který vyjádřil zadavatel. Může to být v těchto aspektech:

• Zvážení toho, jak má být aplikace obecná, jinak řečena, jak má být připravena na případné změny a rozšíření. Příkladem může být v rámci aplikace pro Finanční kontrolu (přirozený) požadavek na doplňování dalších typů dokumentů a tím i dalších schvalovacích postupů
• Nabídka dalších funkcí, které aplikace/systém bude/může poskytovat a zadavatel je ani nepožadoval. Příkladem může být v systému pro správu studijních programů nebo v transferu technologií funkce systému, která bude upozorňovat na blížící se termíny kontrolních zpráv, prodloužení patentů, plateb apod.