01 Obecné tipy pro analýzu

Postup

1. Zjistit termíny, omezení a závislosti.
2. Určit cíle a očekávání - proč se systém vyvíjí?
3. Zainteresované osoby - kdo je za co odpovědný, kdo může dělat rozhodnutí.
4. Rozdělit na části, komponenty, funkcionality.
5. Nastavit priority (nejprve jádro obchodu, pak výjimky).

Checklist analýzy

Pole

• Viditelnost
• Editovatelnost
• Výchozí hodnota
• Validace (povinnost)

Zpětná kompatibilita

• Změna dat (číselníky)
• Platnost od - do, od kdy začne platit nový stav, jak se budou chovat rozpracované případy

Oprávnění

Tipy

Oprávnění

Pokud je např. nějaká funkcionalita na speciální oprávnění, často je lepší zobrazit možnost té funkcionality (např. tlačítko), aby uživatel viděl, že tam něco takového vůbec je. Na stisk tlačítka se pak naváže teprve to oprávnění a informuje to uživatele o tom, že nemá dostatečná oprávnění. To samozřejmě neplatí v případě, že uživatel nemá o funkcionalitě vůbec vědět (např. funkcionalita úplně pro jinou roli). Pokud ale může něco udělat jen v případě, že předtím musí udělat ještě něco jiného, tak je to lepší řešit takto, protože uživatelé se pak diví, proč tam tlačítko není a zahlcuje to support, takhle jim to systém řekne sám.

Parametrizovatelnost systému

Zadavatelé často chtějí, aby byl systém co nejvíce parametrizovatelný. Je to proto, aby nemuseli dělat dovývoje, když se něco změní. Parametrizovatelnost systému ale výrazně zesložiťuje jeho nastavování, užívání, zvyšuje pravděpodobnost chyb a má dopady na výkon. Čím složitější systém, tím více se tyto problémy projevují. Navíc budoucí rozvoje jsou komplikovanější, udržování dokumentace nebo předávání informací atd.

Proto je potřeba při se držet určitých mez. Osobně bych řekl, že platí následující:

Četnost změn	Řešení
V řádů dnů až měsíců	Vyplatí se parametrizovatelnost na straně obchodu.
Po kvartálech, až třeba jednou do roka	Je na zvážení, jestli nenechat parametrizovatelnost pouze na úrovni DB prováděnou IT.
Jednou za několik let, nebo není vysoká pravděpodobnost její změny	Může být nastaveno "natvrdo" v kódu. Budoucí dovývoj bude zřejmě levnější než problémy, které parametrizovatelnost v budoucnu přinese.