SSADM Structured System Analysis and Design Methodology 4
- Slides: 80
SSADM Structured System Analysis and Design Methodology 4. 4. 2008 1
O SSADM (1) Vyvinuto Learmonth and Burchett Management Systems (1980) Standardní metodologie pro vládní projekty UK: v 80. letech až do poloviny 90. let Metoda klade důraz na: konkrétnost, komplexnost, jednoznačnost 4. 4. 2008 slučitelnost, zřetelnost, stručnost precizní vyvažování modelů 2
O SSADM (2) • Není to pouze kolekce technik Dobře strukturovaná metoda stylem krok za krokem Začíná zkoumáním současného systému Končí detailním návrhem požadavků Používá řadu nástrojů a pohledů pro zachycení a vizualizaci de na každé úrovni, nepreferuje pouze jediný Vhodná metoda pro systémy s dobře definovaným okolím. 4. 4. 2008 3
O SSADM (3) Člení projekt na malé, dobře definované aktivity a specifikuje sekvence a interakce těchto aktivit. Používá diagramatické a jiné modelovací techniky pro vytvoření přesnější, tj. strukturované definice aplikace. Přístup vede k vývoji kvalitnějších produktů. Vychází z inženýrského přístupu, popisuje systém detailně a strukturovaně v každé etapě životního cyklu vývoje. 4. 4. 2008 4
O SSADM (4) SSADM se dělí: do tří fází a pěti etap: Analýza – stávajícího systému a specifikace požadavků Logický návrh – datový návrh a procesní návrh Fyzický návrh 4. 4. 2008 5
fáze a etapy (1) 4. 4. 2008 6
fáze a etapy (1) Fáze A Analýza Etapa 1 Analýza stávajícího systému konstrukce logického modelu stávajícího systému dokumentace problémů stávajícího systému a sepsání požadavků na nový systém Etapa 2 Specifikace požadavků konstrukce modelu požadovaného systému a detailní dokumentace 4. 4. 2008 7
fáze a etapy (2) Fáze B Logický návrh Etapa 3 Logický datový návrh Kompletní a detailní logický datový návrh Etapa 4 Logický procesní návrh Kompletní sada detailního logického procesního návrhu Fáze C Fyzický návrh Etapa 5 Fyzický návrh Překládá logický datový návrh do souboru či databáze specifikací a logický procesní návrh do programové 4. 4. 2008 specifikace 8
fáze a etapy (3) Návrh logických dat a návrh logických procesů probíhají současně za neustálého vyvažování datového a procesního modelu. Specifikace systému 4. 4. 2008 9
etapy Analýza stávajícího systému Specifikace požadavků Stávající systém je studován s cílem porozumět problémové oblasti nového systému. Logický datový návrh Logický procesní návrh Fyzický návrh 4. 4. 2008 10
etapy Analýza stávajícího systému Specifikace požadavků Logický datový návrh Pohled na stávající systém je použit pro vytvoření specifikace požadovaného systému. Logický procesní návrh Fyzický návrh 4. 4. 2008 11
etapy Analýza stávajícího systému Specifikace požadavků Logický datový návrh Logický procesní návrh Podrobný návrh je dokončen na logické úrovni před tím, než jsou řešeny implementační aspekty. Fyzický návrh 4. 4. 2008 12
etapy Analýza stávajícího systému Specifikace požadavků Logický datový návrh Logický procesní návrh Fyzický návrh 4. 4. 2008 Podrobný návrh je dokončen na logické úrovni před tím, než jsou řešeny implementační aspekty. 13
etapy Analýza stávajícího systému Specifikace požadavků Logický datový návrh Logický procesní návrh Fyzický návrh 4. 4. 2008 Logický návrh je převeden na fyzický návrh aplikací jednoduchých pravidel. 14
životní cyklus Rozsah SSADM 4. 4. 2008 15
Studie proveditelnosti (1) § Nejednotnost reprezentace § Důležité zjištění zda se má vůbec realizovat § Projekt musí projít všechny fáze, některé i několikrát (zpětné šipky) § Studie proveditelnosti je zaměřená na porovnání ceny a přínosu celého systému pro společnost, vychází především ze zkoumání systému a analýzy. § Někdy je do studie proveditelnosti třeba zahrnout i prvotní návrh. Pak je celý projekt realizován ve dvou cyklech. 4. 4. 2008 16
Studie proveditelnosti (2) 1. cyklus 4. 4. 2008 2. cyklus 17
Analýza a specifikace požadavků Analýza: § Zorganizovat shromážděné informace během zkoumání systému do smysluplné podoby § Velmi důležitý nástroj SSADM, dobře a přesně znázorní stávající systém § Detailně popsány logické modely stávajícího systému Specifikace: § Je výstupem z analýzy, tak aby bylo možné provést návrh § Zmínění možných technických variant 4. 4. 2008 18
Specifikace požadavků 4. 4. 2008 19
Návrh Logický návrh: § Vstupem je specifikace požadavků § Cílem je vybrat vhodnou implementaci § Přetváří specifikaci požadavků do specifikace jak dat, tak procesů, které jsou vyžadovány novým systémem Fyzický návrh: § Přetváří logickou specifikaci na specifikaci fyzickou, specifikaci databáze a programu § Dochází k návrhu vstupů a výstupů – to znamená podoby souborů a také obrazovek 4. 4. 2008 20
Implementace, okolí systému Implementace: Okolí systému: § Není už zahrnuta v SSADM § Metoda vhodná pro systémy s dobře definovaným okolím § Zahrnuje programování, testování, zavedení a nasazení systému včetně potřebného HW a SW vybavení, nastavení, proškolení uživatelů, testování uživateli a následné udržování § Systémy se špatně definovaným okolím musí být převedeny na systémy s dobře definovaným okolím 4. 4. 2008 Okolí systému 21
Okolí systému Parametr le Dobře strukturované reálný, jasný, pevný Problémy Požadavky Sdělení Postoj 4. 4. 2008 známé, věcné pevné, užitečné účelné, zaručené Špatně strukturované nereálný, nejasný, proměnlivý nejasné, nepoznané intuitivní nejisté, nezaručené flexibilní, spolupracující obstruktivní, zdržovací 22
Inženýrský přístup § tvoří hlavičku (do které jsou popisovány údaje o nákresu) § snadná dohledatelnost § jednoznačnost § odlišení verzí 4. 4. 2008 23
základní techniky Diagram datových toků (DFD) Logické datové struktury (LDS) Ukazuje hranice systému, jak se předává informace a vazbu s ostatním světem. Ukazuje závislosti dat a také vstup a výstup do systému. Životní cyklus entit (ELH) Normalizace Přehled procesů Popis procesů Kontrola fyzického návrhu 4. 4. 2008 24
základní techniky Diagram datových toků (DFD) Logické datové struktury (LDS) Životní cyklus entit (ELH) Ukazují, která informace je ukládána a jaké jsou vzájemné vztahy mezi jednotlivými informacemi. Také jak se data seskupují do struktur a skupin. Normalizace Přehled procesů Popis procesů Kontrola fyzického návrhu 4. 4. 2008 25
základní techniky Diagram datových toků (DFD) Logické datové struktury (LDS) Životní cyklus entit (ELH) Ukazuje, jak se informace mění během svého života. Poskytuje dynamický pohled na systém. Normalizace Přehled procesů Popis procesů Kontrola fyzického návrhu 4. 4. 2008 26
základní techniky Diagram datových toků (DFD) Logické datové struktury (LDS) Životní cyklus entit (ELH) Normalizace Přehled procesů Popis procesů Přeměňuje kompletní datovou strukturu na jednoduchý list. Využívá se pro vytváření modelů ze vstupní a výstupní datové struktury. Kontrola fyzického návrhu 4. 4. 2008 27
základní techniky Diagram datových toků (DFD) Logické datové struktury (LDS) Životní cyklus entit (ELH) Normalizace Přehled procesů Popis procesů Specifikuje operce nutné pro chod systému. Dochází k vytvoření programové specifikace. Kontrola fyzického návrhu 4. 4. 2008 28
základní techniky Diagram datových toků (DFD) Logické datové struktury (LDS) Životní cyklus entit (ELH) Normalizace Popis procesů Kontrola fyzického návrhu 4. 4. 2008 Poskytuje sadu pravidel pro transformaci logické specifikace na specifikaci fyzickou. Různá pravidla pro kombinaci HW a SW. 29
Tři vzájemně se ovlivňující pohledy OBCHOD 4. 4. 2008 30
DFD ukazuje toky informací systémem • jak informace vstupuje do systému (procesu) a opouští jej • co mění informace • kde je informace uložena Skládá se z: externí entity, procesy, paměti dat, toky dat „Diagramy datových toků jsou jednoduché grafické reprezentace datových toků, pamětí a procesů, které uživatel lehce přijme. “ (Geoff Cutts) 4. 4. 2008 31
DFD – odlišná notace (1) 4. 4. 2008 32
DFD – odlišná notace (2) Odlišná notace u DFD 0. úrovně SSADM - není zobrazen systém 4. 4. 2008 Yourdon – vše před systém 33
LDS Logical Data Structure modeluje entity a jejich vztahy v systému. Je součástí Logical Data Modeling, které zahrnuje kromě LDS ještě dokumentaci. Entita je to, o čem má význam uchovávat informace v systému. Musí být rozlišitelná od ostatních entit a existovat nezávisle na nich. Př. IS MU: Studenti, Předměty, Místnosti, Zkoušky…. Vztah je asociace mezi 2 a více entitami. 4. 4. 2008 34
LDS – kardinalita A je ve vztahu s právě jedním B 4. 4. 2008 35
LDS – příklad Vztah student se hlásí na školu (M: N) 4. 4. 2008 36
Křížový odkaz (1) § Používá se v Analýze § Poskytuje test komplexnosti a správnost DFD a LDS § Entita se skládá z jedné nebo více pamětí 4. 4. 2008 37
Křížový odkaz (2) § V praxi ale paměť postihuje dvě i více entit 4. 4. 2008 38
Entitně-funkční matice § Předchází konstrukci ELH a Popisu procesů § Řádky jsou tvořeny seznamem všech entit v entitním modelu a sloupce jsou tvořeny funkcemi v DFD I – vytvoření (insert) M – upravení (modify) R – čtení (read) D – mazání (delete) 4. 4. 2008 A – archivace (archive) 39
ELH (1) Entity Life History je diagramatická reprezentace životního cyklu jedné entity, od jejího vytvoření až po zrušení. Entita je nahoře, ostatní jsou události (event). Sekvence – diagram se čte zleva doprava. Selekce (o) – alternativy, posloupnost není důležitá Iterace (*) – cyklus, mnoho operací shodného typu následuje za sebou. Paralelní zpracování – 4. 4. 2008 40
ELH (2) Ukazatel stavu: Př. 1 -4/2 Před lomítkem – předchozí stav Za lomítkem – následující stav R – pokračovat (resume) Q – skončit (quit) 4. 4. 2008 41
Normalizace (opakování) · 1 NF (první normální forma): Tabulka je v první normální formě, jestliže lze do každého pole dosadit pouze jednoduchý datový typ (jsou dále nedělitelné) a je zbavena opakujících se položek. · 2 NF (druhá normální forma): Tabulka je ve druhé normální formě, jestliže je v 1 NF a navíc platí, že existuje klíč a všechny neklíčové atributy jsou funkcí celého klíče. · 3 NF (třetí normální forma): Tabulka je ve třetí normální formě, jestliže je v 2 NF a navíc každý neklíčový atribut je netransitivně závislý na každém kandidátním klíči. 4. 4. 2008 42
Popis procesů Technika, která shromažďuje všechny operace, které jsou nutné k tomu, aby proces proběhl Př. objednání zkoušky § entity z entitně - funkční matice § Ukazatel stavu z ELH § zahrnuje jedno nebo více funkčních okének DFD Obsahuje: jméno entity, účinek na událost, předchozí a následující stav 4. 4. 2008 43
Kontrola fyzického návrhu není jedna technika, ale několik pravidel jak přetvořit logický datový návrh a Logický popis procesů na fyzickou specifikaci. Výsledek kontroly fyzického návrhu je databáze nebo soubor specifikací a řada programových specifikací. Pravidla přeměny se budou lišit v závislosti na plánovaném hardwarovém a softwarovém vybavení. Několik popsaných procesů se spojí a vytvoří jednu programovou specifikaci. 4. 4. 2008 44
Provázanost DFD, LDS a ELH 4. 4. 2008 45
fáze a etapy - techniky(1) Fáze A Analýza Etapa 1 Analýza stávajícího systému DFD, LDS (ERD) Křížový odkaz Průchod a dokumentace Etapa 2 Specifikace požadavků DFD, LDS (ERD), ELH Křížový odkaz Průchod a dokumentace 4. 4. 2008 46
fáze a etapy - techniky(2) Fáze B Logický návrh Etapa 3 Logický datový návrh Normalizace, LDS (ERD) Průchod a dokumentace Etapa 4 Logický procesní návrh Popis procesů Průchod a dokumentace 4. 4. 2008 47
fáze a etapy - techniky(3) Fáze C Fyzický návrh Etapa 5 Fyzický návrh Kontrola fyzického návrhu DFD Průchod a dokumentace 4. 4. 2008 48
Standardní forma projektu (1) 1. DFD diagram 2. DFD 1. úrovně 3. DFD 2. úrovně 4. LDS (ERD) 5. DSE - křížový odkaz (data store entity) 6. List problémů a požadavků 7. Popis entit 8. Popis vstupů a výstupů 4. 4. 2008 49
Standardní forma projektu (2) 9. Datový slovník 10. On-line dialog specifikací 11. Logický funkční popis 12. Entitně-funkční matice 13. ELH 14. Normalizace 15. Katalog procesů 16. Popis procesu 17. Části fyzického přístupu 4. 4. 2008 50
Příklad, zadání(1) - Kuchyně § Zákazníci si objednají prostřednictvím obchodního oddělení § Objednávky jsou potvrzeny a přepsány na objednávkové formuláře § Smlouva se uzavírá na jeden typ jídla § Je dána sleva pokud se zákazník zaváže odebírat určité množství § Zákazník smí mít mnoho smluv § Objednávky obsahují smluvní cenu § Kopie všech smluv jsou uloženy u účetního a přístupné kvůli cenám § Ostatní faktury jsou ceněny podle lístku připraveného zaměstnanci § Prodejce přijímá kompletní denní list jídel na prodej § Účetní vystaví fakturu a zašle ji zákazníkovi § Při dodání jídla strhne účetní kredit z účtu § Účetní týdně kontroluje limit a zastaví dodávky pokud je vyčerpán § Účetní prověří a autorizuje nového zákazníka, § Zašle obchodníkovi informace o nových zákaznících § Účetní zaznamenává přijaté platby od zákazníka 4. 4. 2008 51
Příklad, zadání(2) § Kuchyně každý den posílá seznam dodávek a vydaných jídel § Pro jídlo vydané zákazníkovi musí zaměstnanci kuchyně vyplnit výdejový formulář pro účetního § Zaměstnanci připravují seznam ingrediencí nákupnímu oddělení. § Seznam dodaných ingrediencí posílají zaměstnanci účetnímu § To dovolí nákupčímu ověřit faktury od dodavatele § Když se zásoba nějaké ingredience ztenčuje, je připravena karta ingrediencí a poslána nákupčímu § Ten připraví objednávku pro dodavatele § Všechny nákupy se zapisují do nákupní knihy Nový systém je požadován pro práci obchodního a účetního oddělení. Na tyto dvě položky provedeme analýzu a návrh dle SSADM. 4. 4. 2008 52
Příklad, DFD 0. Level – původní stav Hranice systému 4. 4. 2008 53
Příklad, DFD 1. Level – původní stav 4. 4. 2008 54
Příklad, DFD 2. Level – obchod – původní stav 4. 4. 2008 55
Příklad, DFD 2. Level – účet – původní stav 4. 4. 2008 56
Příklad, matice entit – původní stav Pro každou entitu je zobrazeno s jakou další entitou se váže 4. 4. 2008 57
Příklad, diagram entit – původní stav Je zde zahrnut i status – v jaké fázi se objednávka nalézá: nevyřešená, čekající, odeslaná 4. 4. 2008 58
Příklad, křížový odkaz (data store entity) – původní stav Ke každé paměti v DFD jsou přiřazeny entity v LDS 4. 4. 2008 59
Příklad, diagram entit – zjednodušení Celý systém bude mít jen 4 entity. 4. 4. 2008 60
Příklad, křížový odkaz (data store entity) – nový stav DFD bude obsahovat pouze čtyři paměti. Stejně tak se dá LDS znázornit pouze se čtyřmi entitami. 4. 4. 2008 61
Příklad, diagram entit – nový stav (logický) Zjednodušení poskytuje lepší náhled na systém. Není úplně správně (vazba N: M), ale dává logický obraz o datech. 4. 4. 2008 62
Příklad, List problémů a požadavků § K uložení objednávky jsou používány tři paměti (čekající, nevyřešená, k odeslání). Je vhodné integrovat do jedné paměti. § V DFD není zahrnuto vedení. To ale chce dostávat výsledky o hospodaření. Je třeba zavést nový proces, který dokáže monitorovat výsledky obchodu i kuchyně a poskytovat údaje vedení (kolik je objednávek, jaký je průměrný čas vyřízení objednávky, kdo jsou největší zákazníci atd. ) § Faktury jsou posílány ihned po vyzvednutí jídla. Mají se posílat všechny najednou jedenkrát za týden. § Objednávky se skládají ze dvou částí (hlavičky a těla). Teď se ukládá pouze tělo objednávky. Hlavička není uložena v žádné paměti. Má se ukládat zároveň hlavička i tělo objednávky. 4. 4. 2008 63
Příklad, DFD 2. Level – obchod – nový stav 4. 4. 2008 64
Příklad, DFD 2. Level – účetní – nový stav 4. 4. 2008 65
Příklad, DFD 1. Level – nový stav 4. 4. 2008 66
Příklad, DFD 0. Level – nový stav 4. 4. 2008 67
Příklad, Popis entit Zobrazuje z jakých položek (řádků v databázi) je entita složena. 4. 4. 2008 68
Příklad, Popis vstupů a výstupů Týká se datových toků. Je jednoznačným vodítkem odkud a kam jsou data směřována. 4. 4. 2008 69
Příklad, Datový slovník Slouží k tomu, abychom popsali každou položku entity. Popisujeme nejdůležitější údaje. 4. 4. 2008 70
Příklad, On-line dialog specifikací Vychází přímo z DFD. Zjednodušuje systém a ukazuje jak by mělo vypadat menu nového systému. 4. 4. 2008 71
Příklad, Logický funkční popis Popisujeme všechny funkce obsažené v systému, vycházíme přímo z DFD. 4. 4. 2008 72
Příklad, Entitně-funkční matice 4. 4. 2008 73
Příklad, ELH 4. 4. 2008 74
Příklad, Normalizace 4. 4. 2008 75
Příklad, Katalog procesů 4. 4. 2008 76
Příklad, Popis procesu 4. 4. 2008 77
Příklad, Části fyzického přístupu Sem patří především: § Specifikace programu § Specifikace databází § Plán implementace § Uživatelský manuál § Provozní manuál 4. 4. 2008 78
Výhody a hodnocení (1) Uživatel dostane systém podle svých požadavků Metoda řízená daty Přiměřeně časově a finančně náročná Aplikace požadavků od uživatelů hned napoprvé Formát dokumentace je pochopitelný pro uživatele Neupřednostňuje jednu modelovací techniku Zahrnuje kompletní dokumentaci už v rámci metody 4. 4. 2008 79
Výhody a hodnocení (2) Používá se při vývoji systémů, ale nepokrývá celý životní cyklus systému. Používá 3 základní pohledy na informační systém: - Logické datové struktury - LDS - Diagramy datových toků - DFD - Životní cykly entit - ELH 4. 4. 2008 80
- What is ssadm methodology
- Structured system of communication
- Overview of sa/sd methodology
- Disadvantages of structured analysis
- Ssadm model
- Parallel development
- Structured development methodology
- Structured english in system analysis and design
- Structured decision in system analysis and design
- Types of interviews structured semi structured unstructured
- Basic building blocks of warnier orr diagram is/are
- Ssadm diagram
- Ssasd
- Form control in system analysis and design
- Sad vs ooad
- User interface design in system analysis and design
- Dialogue design in system analysis and design
- Fact finding techniques observation
- Candidate system in system analysis and design
- The fifth step in the iot design methodology is __________
- Process specification in iot
- Properties of a system in system analysis and design
- System security in system analysis and design
- System proposal in system analysis and design
- Problem definition in system analysis and design
- Ssadm data flow diagram
- Metodologia ssadm
- Kendall & kendall systems analysis and design
- Kendall & kendall systems analysis and design
- System analysis and design kendall
- Kendall and kendall system analysis and design
- System analysis and design kendall
- Structured design example
- The primary tool used in structured design is a
- Structured vlsi design
- Modern structured analysis
- Tools of structured analysis
- Bigtable a distributed storage system for structured data
- Bigtable: a distributed storage system for structured data
- Tradersonly review
- Bigtable: a distributed storage system for structured data
- Reg+
- Structured work system examples
- Operational view specification is
- Research methodology
- Car hoare
- Design research methodology
- Significance of research design
- Database design methodology
- Ic design methodology
- Digital design methodology
- Database design methodology
- Directed designating
- Structural design methodology
- Network design methodology steps
- Synchronous design methodology
- Fpga design methodology
- Method
- Business process assessment methodology
- Methodology of econometrics
- Diagram for traditional approach
- What is information system analysis and design
- System analysis and design chapter 2
- Gantt chart system analysis and design
- System analysis
- Systems analysis and design in a changing world
- Hardware acquisition in system analysis and design
- Sad system analysis and design
- Organizational feasibility in system analysis and design
- Dfd chapter 5
- What is interview in system analysis and design
- Requirements modeling in system analysis and design
- Project selection in system analysis and design
- Event table in system analysis and design
- Flow chart in system analysis and design
- Data dictionary notation
- Data flow diagram in system analysis and design
- System analysis and design with uml
- System analysis and design tools
- Gantt chart system analysis and design
- Context diagram in system analysis and design