Vypisky

#AUTHOR: Roman Plášil
#TITLE: Analýza a návrh systémů - výpisky


* Různé vývojové cykly
** Model životního cyklu __vodopád__
Analýza -> Návrh -> Implementace -> Testování -> Správa

*** Problémy
* Těžko se to celé odhaduje dopředu, jak ze strany zákazníka tak ze strany vývojáře.
* Celkový výsledek je vidět až na konci a to zákazníkovi vadí.

** Cyklus beze jména 1
Uživatelovy potřeby -> Požadavky na sw -> Návrh -> Kód -> Operační použití

** Základní aktivity
* Specifikace
* Vývoj
* Validace
* Evoluce

** Inkrementální cykly
Prototypování :: Prototyp se použije pro tvorbu specifikace, pak se
zahodí.
Inkrementální vývoj ::
Výzkumník :: Experimentování, těžko říditelné.



{endslide}




* Řízení týmu
* Přidání člověka do zpožděného projektu může ještě zvětšit
jeho zpoždění, kvůli potřebnému úsilí na komunikaci.



{endslide}


* Specifikace požadavků
* Popisuje __cílový stav__ projektu. Podle specifikace se bude
hodnotit úspěšnost produktu.
* Obsahuje
* cenu
* funkce
* plán práce (termíny)
* výkonnost sw

** Osnova dle Pressmana
Úvod :: Kde je to zasazeno, jaká jsou vnější omezení (legislativa, ...)
* Odkaz na systém
* Celkový popis
* Omezení
Popis informací :: V podstatě DFD, včetně vysvětlení symbologie.
* Popis informačních toků (datových/řídících)
* Popis informačního obsahu
* Rozhraní systému
Popis funkcí :: Rozepsaná funkcionalita systému.
* Stručný popis
* Omezení - používáme takový a takový OS, musí to na něm běžet.
Nebo používáme takový systém, musí to s ním komunikovat.
* Výkon
* Obrázky
Popis řízení :: Nevim co to má být.
Popis chování :: Stavy systému, co je v kterém stavu povoleno.
Validační kritéria :: Závazné vlastnosti systému.
Literatura :: Ať to vypadá, že jsme zběhlí.

** Osnova podle IEEE
Úvod :: Účel, definice, odkazy, přehled.
Celkový popis :: Funkce, uživatelské rozhraní, omezení, předpoklady.
Funkce :: Úvod, vstup, výstup, zpracování
Požadavky na rozhraní :: HW rozhraní, SW rozhraní
Požadavky na výkon :: ...
Návrhová omezení :: Dodržení standardů, bezpečnost, udržovatelnost
Další požadavky :: Databáze, lokalizace, ...

** Zásady
* Každá cílová skupina vyžaduje trochu jinou formu (programátor vs. manažer)
* Abstrahovat od implementačních detailů.
* Popisovat i okolí, ve kterém bude systém zasazen.
* Specifikace musí být dostatečně formální a úplná, aby byla použitelná
pro validaci systému.
* Specifikace musí být rozšiřitelná.




{endslide}


* Analýza jako taková
Fyzický systém :: skutečně existující systém, který v sobě zahrnuje
vše potřebné pro funkci (tedy především implementační detaily) a
tudíž se obtížně pracuje na takto nízké úrovni.
Logický systém :: abstrakce od fyzického systému, podstatné jsou funkce,
ne implementace.


** Postup analýzy
Informace můžeme získat z
* Dotazování
* Odvození z existujícího systému
* fungujícího v dané firmě doposud
* fungujícího někde jinde
* v literatuře
* Analýza okolí - postupy používané ve firmě
ne nutně související s vytvářeným systémem
* Prototypování
** SASS
Klasický postup od Yourdona a \DeMarca, také nazývaný
__metodika 4 modelů__.
#. Studie stávajícího fyzického systému
#. Odvození logického ekvivalentu stávajícího systému
#. Odvození nového logického systému
#. Vypracování možností
#. Volba a tvorba fyzického modelu

Poměrně kritizované, zákazníkovi se to často nelíbí,
tvorba 4 modelů je zdlouhavá a možná ani ne nutná.
Navíc logický model stávajícího systému bude stejně
zahozen.

** Logické mo