Možnosti modelování požadavků na informační systém

Prezentace na téma: "Možnosti modelování požadavků na informační systém"— Transkript prezentace:

1 Možnosti modelování požadavků na informační systém

2 OBA - Object Behavior Analysis - metoda pro analýzu problému, která pomáhá zjistit o co vlastně jde.
Nepoužívá diagramy, ale formuláře a tabulky, nepoužívají se také kategorie objektového programování. Spoléhá se na iterace » postupné upřesňování (iterace nejsou v tomto případě nutné zlo, ale nástroj). Je to velice přísná metoda, má hodně pravidel. Vše se musí od něčeho odvodit - snaha řídit se pravidlem: „Co nemusím dělat teď, udělám později.“ Metoda umí odpovědět na tyto otázky: Kde se nacházejí objekty? Jak lidé organizují reálné věci? Jak se rozeznají „interface“ objekty?

3 Jde o vhodný nástroj pro porozumění problému
Jde o vhodný nástroj pro porozumění problému. Výstupy jsou nástrojem modelování bussines managementu, podklady (dokumentace) pro vytvoření informačního systému. Lze je také použít v dalších podobných projektech - jsou efektní a názorný nástroj pro komunikaci a zachycování myšlenek v týmu. Přímá analýza skutečných procesů. Možno provádět standardně (v krocích 1 až 5 za sebou) nebo zrychleně (v pořadí kroků 1, 5, 2, 3, 4), což má tu výhodu, že hrubé výsledky jsou brzo a tu zdlouhavou práci děláme až potom.

4 Kroky metody: 1) interview - rozdělit úlohy mezi více lidí; role konzultantů (musí tu být někdo, kdo rozumí metodě, kdo danému problému a někdo kdo zná lidi); i když informaci známe, měli bychom se jí dozvědět od zákazníka; nepoužívají se otázky A/N, ale také ne příliš komplexní (několik otázek najednou); provádí se sumarizace; seznam požadovaných funkcí systému - nutno vést také určitý slovník zkratek aj.; seznam scénářů v systému - počet scénářů by měl být 3 až 4 větší než počet funkcí (tedy zpravidla okolo 100 scénářů)

5 2) obsazování jednotlivých objektových rolí ve scénářích - definování objektů; tvorba modelových karet; seznam funkcí 3) klasifikace objektů - kontrolní báze metody, je třeba z několika objektů udělat jeden; odvozování dalších objektů v systému - hledáme podobné chování mezi různými objekty a podle toho vytváříme skupiny; v tomto bodě je působení lidského faktoru nejdůležitější; responsibility - visible property (zárodek atributů, vlastnosti) + activity (funkce měnící stavy, zárodek metody)

6 4) modelování vztahů mezi nalezenými objekty - tabulky vztahů mezi objekty
5) simulace scénářů - hloubková kontrola; sestavení diagramů životních cyklů objektů dokončení analýzy procesově a objektově; to, co tam být nemá, ať tam není; použití zvláštních diagramů (zachycujících vývoj v čase a aktivity, stavy, přechody)

7 Iterativní model: po analýze, designu, implementaci a testování se uvede hotový produkt. Tento produkt se může následně podrobit revizi a opět vyvíjet. Jedná se o „dodávání po částech“. Vyžaduje zkušené plánovače, výborné vedoucí projektu. Spirální model: nelze hovořit o finálním produktu, analýza a vývoj neustále pokračuje. V každém cyklu je výstupem tzv. „deliverable“, který je plně funkční pro práci. Jedná se o tzv. prototypový životní cyklus systému. Expanze – strategická analýza → počáteční analýza → pokročilá analýza Konsolidace – počáteční design (návrh) → pokročilý návrh → implementace