Zařaďte činnosti týkající se návrhu programového systému do životního cyklu informačního systému. Jaké metody a techniky lze použít pro návrh programového systému? Problémy přechodu mezi konceptuální a technologickou úrovní návrhu IS včetně stavu a možností počítačové podpory (CASE). Jaká kritéria použijete při rozhodování, zda programový systém vytvářet na klíč nebo nákupem hotových programových balíků?

Předpoklady: Jste vedoucím projektu vývoje IS objektově-orientovaným způsobem a právě tvoříte plán tohoto projektu.

Zadání:

• Rozhodněte se, zda je i při objektově orientovaném vývoji systému nutné věnovat pozornost přechodu mezi konceptuální a technologickou úrovní návrhu systému?
• Naplánujete pro tento přechod specifickou činnost? Proč?

IST – definuje současnou a budoucí podobu informačního systému a způsob přechodu mezi nimi. Od toho se odvíjí jednotlivé informatické projekty.

US – úvodní studie nebo také studie řešitelnosti. Hrubý procesní a funkční model, hrubá struktura dat, vše samozřejmě na konceptuální úrovni. Role uživatelů, pro koho systém vzniká, náklady v člověkohodinách, rozpracování konceptu řešení, více variant, výběr nejlepší. Výběr SW pro realizaci. Centralizované/decentralizované zpracování.

interview

ERD diagramy.

hrubý funkční model

hrubé DFD

model procesů – základních

konzistenční matice

kritické faktory úspěchu

kontextový diagram

GST – rozpracování problému detailně, ale na konceptuální úrovni – na nejnižší ještě technologicky nezávislé úrovni, rozpracování procesů, funkcí, dat, role, use case – diagram užití, jednotlivé role, toky dat, odhady nároků na HW a SW, vytipování ZSW, ERD diagramy – normalizace dat; testování konzistence; plán školení, u TASW návrh úprav dat, plán přístupových práv; analýza všech detailních závislostí; výběr konkrétního řešení pro implementaci

DFD

ERD

use case

kontextový diagram

konzistenční matice

STD

může být strukturogram

DAN – detailní analýza – přechod od konceptuální k technologické úrovni – převod věcí vytvořených GAN do podoby závislé na technologii; definování vstupů, výstupů funkcí s ohledem na implementační prostředí, návrh databázových tabulek, návrh uživatelských obrazovek, definice konkrétních přístupových práv, u TASW příprava customizačních dat, úpravy obrazovek, definice hierarchie tříd, rozhraní modulů; detailní návrh přenosových cest, návrh menu, plán instalace, příprava testovacích dat

ERD

DFD

strukturogram

hierarchie funkcí

slovník dat

vývoják

konzistenční matice

IM – implementace už se to jen naprogramuje

ZA – už se to jen nainstaluje

PU – provoz a údržba

Pokud se v kterékoliv fázi zjistí malér, je třeba se vrátit do fáze předchozí a provést úpravy. Čím dřív se to zjistí, tím míň peněz to bude stát.

Problémy přechodu:

Může být rozpor toho, co by uživatel chtěl a co dané implementační prostředí umí. Nebo to umí, ale jak je to navrženo, je to pomalé. Kupříkladu máme nádherný návrh databáze a najednou zjistíme, že MySQL neumí referenční integritu – máme tři možnosti a) vrátit se o úroveň výše a předělat konceptuální návrh, b) jít si hodit mašli, c) vyhodit MySQL z okna a zapojit nějakou databázi. c) je správně; dalším problémem je rozhodnout, které funkce budou automatizované a které nikoliv (vývojáři mají tendenci automatizovat všechno, ale to by to nebylo nikdy hotovo). Když je potřeba – upravit vyšší vrstvy, ale návrh vždy konzistentní!

Možnost počítačové podpory je značná zejména u datového modelování, ale i u modelování procesního a funkčního. Moderní CASE nástroje jsou schopny vysledovat některé typy nekonzistencí, poskytují data dictionary, jsou schopné případně generovat dokumentaci, event. předpřipravit kusy kódu, atd. V některých vývojových prostředích naopak podpora UML.

Ano, neb implementace objektového modelu se dramaticky liší prostředí od prostředí.