Structured Systems Analysis and Design Method

SSADM is Engels voor "Structured Systems Analysis and Design Method" en betekent in het Nederlands "Gestructureerde Methode voor Analyse en Ontwerp van Systemen". Het is een verzameling methoden en technieken, die wordt gebruikt tijdens de analyseer- en ontwerpfase van systeemontwikkeling.

De SSADM-methode is een watervalmethode, het ontwerpen van een softwareapplicatie volgens deze methode geschiedt in duidelijk gescheiden fasen. SSADM gebruikt een combinatie van tekst en diagrammen door de hele levenscyclus van een systeemontwerp, van het initiële ontwerp idee tot het uiteindelijke fysieke ontwerp van de applicatie.

SSADM werd in 1980 ontwikkeld door LBMS (Learmonth & Burchett Management Systems) voor de IT-dienst van de Britse overheid, de CCTA (Central Computing and Telecommunications Agency).

John Hall was de oorspronkelijke ontwerper van SSADM, hij is samen met Keith Robinson de ontwikkelaar van versie 1. Ze verlieten LBMS in 1983 om Model Systems op te richten.

De Britse overheid had opdracht gegeven om een standaardmethode te ontwikkelen hoe programmatuur binnen de overheid ontworpen dient te worden. Voordat deze standaard gebruikt werd, waren er geen eenduidige regels hoe IT-projecten ontwikkeld moesten worden. Het gevolg daarvan was dat vaak business requirements niet volledig gehaald werden, de analyses niet goed waren en de projecten slecht onderling vergelijkbaar waren.

Tijdens de volgende 15 jaar werd de methode uitgebreid voor ondersteuning van interactieve gebruikersinterfacebenadering, vierde generatietalen, client-servertechniek, nieuwe toepassingen en objectgeoriënteerde ontwerpen. CCTA stelde de techniek algemeen ter beschikking (met behoud van het handelsmerk "SSADM" en auteursrecht voor de referentiehandboeken) en ze introduceerden formele kwalificatie voor deze techniek; een opleidingserkennings- of accreditatie- en nalevingsschema voor programma's en technieken die SSADM ondersteunden.

SSADM wordt beheerd door het DAB (Design Authority Board). Het NNC (National Computing Centre) ontwikkelt en beheert de definitieve SSADM- documentatie. Het is een open standaard en daardoor vrij te gebruiken door iedereen.

• 1980 Central Computer and Telecommunications Agency (CCTA) gaf opdracht om tot een standaard te komen.
• 1981 De door LBMS ontwikkelde methode werd gekozen uit 5 andere mogelijke methodes.
• 1983 De Britse overheid stelde de SSADM-methode verplicht voor alle nieuwe IT-projecten binnen de overheid.
• 1984 Versie 2 van SSADM vrijgegeven
• 1986 Versie 3 van SSADM vrijgegeven, Standaard wordt nu ook gebruikt door de Britse NCC (National Computing Center)
• 1988 SSADM Certificaat van bekwaamheid gelanceerd
• 1989 SSADM wordt meer volgens EUROMETHOD-richtlijnen, CASE-producten certificatieschema bij SSADM standaard bijgevoegd
• 1990 Versie 4 vrijgegeven
• 1993 SSADM V4 Standaarden- en gereedschappenschema bij SSADM standaard bijgevoegd
• 1995 SSADM V4+ bekendgemaakt, uiteindelijk is V4.2 vrijgegeven
• 1996 SSADM V4.3 uitgebracht, deze versie is vooral gericht op het ontwikkelen van applicaties met een grafische user interface.

SSADM gebruikt een watervalmethode voor het ontwerpen van een informatiesysteem. De SSADM-methode wordt gebruikt in de haalbaarheidsonderzoekfase, analysefase en de ontwerpfase bij een IT-project. De overige fasen vallen buiten de methodes die beschreven zijn in SSADM.

Elke fase binnen SSADM is opgedeeld in etappes, elke etappe is weer onderverdeeld in stappen en elke stap bevat op zijn beurt een aantal taken. Door deze onderverdeling wordt een probleem opgesplitst in kleine behapbare deelproblemen. De complexiteit wordt hierdoor sterk verminderd en hierdoor wordt de kans op fouten verminderd. Bijkomend voordeel van deze opsplitsing is dat de delen die zijn ontstaan, verdeeld kunnen worden. Hierdoor kan de werklast verlaagd worden en kan de voortgang gemakkelijk worden bijgehouden.

De SSADM-methode maakt gebruik van een strenge documentgeleide benadering. Dit in tegenstelling tot de meer modernere Rapid Application Development- (RAD-)methoden zoals Dynamic Systems Development Method (DSDM).

Bij de SSADM-methode wordt ervan uitgegaan dat de 'requirements' (wensen) niet veranderden tijdens de ontwikkel fase van een project.

Elke stap van de SSADM-methode volgen kan veel tijd kosten en zorgen voor een aanzienlijke vertraging tussen aanvang en oplevering. Voordeel is wel dat hoe langer de ontwikkelperiode duurt des te groter de kans is dat het systeem aan de vereiste specificaties voldoet. Maar het zal niet ten goede komen aan de business requirements.

Het ontwerp van SSADM is een aantal keer gewijzigd sinds de eerste uitgave door gebruikerservaringen en nieuwere methodes. SSADM is vooral doorontwikkeld door de behoefte aan herhaalde stappen in het proces. Hierdoor is de methode steeds meer gaan grenzen of overlappen aan de RAD-methodes. Ondanks de wijzigingen is SSADM, in het bijzonder de watervalmethode, bekritiseerd omdat het veel meer tijd kost om een softwareproject te maken, zonder dat de uitkomst van de projecten verbetert.

De SSADM-methode behandelt een aantal opeenvolgende analyse-, documentatie- en ontwerptaken voor het ontwikkelen van een applicatie.

In deze fase wordt kort gekeken of het voorgestelde informatiesysteem haalbaar is binnen de gestelde business requirements en of er niet al een soortgelijk systeem ontwikkeld is.

In deze fase zitten de volgende stappen:

1. Probleemdefinitie

   In deze stap wordt gekeken naar het bedrijf en welke informatie benodigd is. Deze stap laat vooral zien welke huidige knelpunten zich binnen de organisatie bevinden.

2. Haalbaarheidsopties

   Binnen deze stap wordt een aantal mogelijke oplossingen aangedragen voor het te ontwikkelen informatiesysteem met de bijbehorende business requirements.

Aan het eind van deze fase wordt een haalbaarheidsverslag opgeleverd. Deze fase kan eventueel bij een klein project samengevoegd worden met de volgende fase.

Deze fase bestaat uit het analyseren op een hoog niveau van de huidige situatie, waarin door middel van een DFD duidelijk wordt gemaakt hoe het huidige systeem werkt en waar de problemen zitten.

In deze fase zitten de volgende stappen:

1. Bedrijfsactiveitendiagram

   Hierin wordt een diagram gemaakt van de huidige bedrijfsactiveiten waar mogelijk rekening mee gehouden moet worden. Indien er regels of andere zaken die binnen het bedrijf gelden, gevonden worden die invloed hebben op het te ontwikkelen informatiesysteem, dienen deze ook in de specificatie opgenomen te worden.

2. Requirementsonderzoek

   De requirements (eisen) voor het te ontwikkelen informatiesysteem worden hierin onderzocht op volledigheid en aangevuld waar nodig. In deze stap worden ook de gebruikers van het nieuwe informatiesysteem gevraagd naar hun mening, eisen en wensen ten opzichte van het nieuwe systeem.

3. Huidige situatieanalyse

   In deze stap wordt een DFD gemaakt waarin de huidige situatie zich begeeft waarvoor later het informatiesysteem gemaakt wordt. Deze stap gaat specifiek in op de verwerking.

4. Huidige gegevensanalyse

   In deze stap wordt een DFD gemaakt waarin de huidige situatie zich begeeft waarvoor later het informatiesysteem gemaakt wordt. Deze stap gaat specifiek in op de data.

5. Opstellen logisch model

   Deze stap heeft als doel om een schematisch model te maken van het huidige systeem. Deze stap heeft als doel om de problemen in het huidige systeem te identificeren.

Aan het eind van deze fase is besloten voor welke optie van de mogelijke Business System Options (BSO) wordt gekozen. Het management maakt deze keuze aan de hand van de gevonden BSO in deze fase. De opties kunnen ondersteund worden door technische documentatie bestaande uit Work Practice Modellen, Logische Data Modellen (LDM) en DFD's.

In deze fase zitten de volgende stappen:

1. Identificeer Business System Options

   In deze stap wordt uitgezocht welke opties er zijn voor het te ontwikkelen informatiesysteem.

   Deze opties voldoen (grotendeels) aan de requirements van de gebruikers.

2. Selecteer Business System Options

   Voor deze stap worden de gebruikers en het management gevraagd naar hun mening over de gepresenteerde opties.

In deze fase worden de vereisten verder uitgewerkt, zowel functionele requirements als niet-functionele requirements. Er worden technieken gebruikt om de processen en datastructuren nog specifieker uit te werken. De DFD's en LDM's verder uitgewerkt en zullen getoetst worden aan de gekozen Business System Options van de vorige fase.

In deze fase zitten de volgende stappen:

1. Definitie gevraagde systeemverwerking

   De huidige stap is bedoeld om de gebruikersrollen in het nieuwe systeem te definiëren in termen van System Data Flows.

2. Definitie gevraagd datamodel

   Het logische datamodel van fase 2 wordt in deze stap uitgebreid met alle verwerking van de gekozen BSO. Deze stap kan tegelijkertijd gedaan worden met de bovenstaande stap.

3. Afgeleide systeemfuncties

   De Service level requirements worden bepaald voor elke functie in deze stap en de extra gevonden functie die door de voorgaande 2 stappen naar boven komen, worden toegevoegd.

4. Werknemer werkomschrijving

   In deze stap wordt een Work Practice Model uitgewerkt zodat meer duidelijkheid verkregen wordt over de werkzaamheden die door werknemers moeten gebeuren.

5. Verbeter datamodel

   Normaliseer het logische datamodel om de kwaliteit te verhogen.

6. Prototypes

   Om de gebruiker weer bij het proces te betrekken, wordt er in deze stap een prototype gemaakt. Het gemaakte prototype wordt voornamelijk gebruikt om te controleren of de requirements goed zijn begrepen en of de juiste weg nog bewandeld wordt.

7. Specificeer verwerking

   In deze stap moet de opvraging en verversing van de data beschreven worden die benodigd is voor het informatiesysteem.

8. Controleer systeemdoelen

   In deze fase is voor het laatste mogelijk om de bevindingen van de requirements te veranderen. Dit is een direct gevolg van de watervalmethode.

In deze fase maakt men meerdere technische systeemopties (TSO's). Het is belangrijk te bepalen hoeveel TSO's er worden gemaakt. Door te letten op de kosten om elke TSO tot een bepaald niveau uit te werken, de behoefte om noodzaak aan te tonen en mate van onderzoek naar alternatieve oplossingen.

In deze fase zitten de volgende stappen:

1. Definieer TSO

   Hierbij wordt gekeken naar de mogelijke aanpakken en de functionele eisen, hieruit wordt een aantal opties gehaald.

2. Selecteer TSO

   Presenteer de TSO's aan de gebruikers

In deze fase worden de logische ontwerpen gebruikt om een fysiek databaseontwerp te maken en om een set van programmaspecificaties te maken.

In deze fase zitten de volgende stappen:

1. Definieer gebruikersdialogen

   Hierin worden de navigatie en de structuren van de dialogen bepaald.

2. Definieer verversprocessen

   Hierin worden de error- en updategebeurtenissen uitgewerkt.

3. Definieer opvraagprocessen

   Hierin worden de error- en opvraaggebeurtenissen uitgewerkt.

De laatste fase van de SSADM-methode; hierin worden de fysieke data en processen vastgesteld, gebruikmakend van de taal en opties van de gekozen fysieke omgeving waarop het systeem komt te draaien.

De volgende stappen horen hierbij:

1. Voorbereiden op fysiek ontwerp.

   Deze stap bestaat uit de volgende punten:

   • Leer de regels van het implementatiesysteem.
   • Bekijk de requirements voor de logische en fysieke mapping.
   • Plan de aanpak

2. Maak de specificatie af van de functies.
3. Maak opvolgend de data- en procesontwerpen.

SSADM draait rond het gebruik van drie basistechnieken, namelijk Logische Gegevens Modellering, de Data Flow modellering en Entiteit/ Gebeurtenis modellering.

• Logische gegevens modellering (Logical Data Modeling): Dit is het proces om de behoeften aan gegevens van een bedrijfsinformatiesysteem te identificeren te modelleren en te documenteren. Deze modellering bevat Logical Data Structure (LDS: de terminologie voor een Entiteit-Relatie Model) en de bijbehorende documentatie.
• Gegevensstroommodellering (Data Flow Modeling): Dit is het proces om te identificeren, te modelleren en te documenteren hoe gegevensstromen rond een bedrijfsinformatiesysteem verlopen. Een Data Flow model bestaat uit een set van Data Flow diagrammen (DFD’s) met de bijbehorende documentatie. Deze DFD’s laten de processen, de dataopslag, externe entiteiten (dingen die data in een systeem inbrengen of verzenden) en ten slotte de dataflows (de routes die data volgen) zien.
• Entiteit/Gebeurtenis modellering (Entity Behavior Modeling): Dit is het proces om de bedrijfsgebeurtenissen te identificeren, te modelleren en te documenteren die elke entiteit en opeenvolging beïnvloeden waarin deze gebeurtenissen voorkomen. Dit model bestaat uit een set entiteiten (records) met onderbouwing en documentatie (één voor elke entiteit).

Een DFD (Data Flow Diagram) geeft op een duidelijke manier weer hoe een business proces verloopt. Het diagram begint met een zeer globale weergave van het te onderzoeken bedrijf en gaat verder met het analyseren van de toepasbare omgevingen en interesses. Deze techniek gebruikt een methode welke de top-down methode wordt genoemd.

Als de analyses zijn voltooid, is het product hiervan een groep diagrammen die gedetailleerd en overzichtelijk alle bedrijfsprocessen binnen een bedrijf in kaart brengen. Het diagram legt de definities van een proces vast en daardoor is het makkelijker om erover te communiceren.

Het begin van een DFD begint bij het aanvangtniveau. Op dit niveau wordt een context diagram getekend, dit is een heel simpele weergave van het onderzochte proces.

Daarna volgt niveau 1. Op dit niveau identificeert het diagram de belangrijkste bedrijfsprocessen welke later weer verder geanalyseerd kunnen worden. Als een bedrijfsproces nog tè complex is op niveau 1 kan gekozen worden om het nog gedetailleerder te beschrijven op niveau 2. In principe zit er geen limiet aan het aantal niveaus, maar meestal houden de onderzoeken op bij niveau 2 en het is zeer ongebruikelijk om verder te gaan dan niveau 3.

SSADM houdt weinig rekening met de mate van belang van collectief informatie- en databeheer. SSADM volgt een gestructureerde, strenge en project geleide aanpak voor de ontwikkeling van gegevensstructuren en processen. SSADM kan de kansen van aanvankelijke vereisten die verkeerd worden begrepen verminderen. Maar daarbij veronderstelt SSADM dat de vereisten (in de vorm van een goedgekeurde vereistenspecificatie) niet tijdens de ontwikkeling van een project zullen veranderen.

Wanneer elke stap van SSADM wordt gevolgd dan neemt dit zeer veel tijd in beslag en kan er een groot tijdsverschil ontstaan tussen aanvang en levering (wat eigenlijk de eerste keer is dat de gebruikers een werkend systeem zien). Hoe langer de ontwikkelingstijd in beslag neemt, hoe groter de kans dat het systeem wel aan de vereiste specificaties voldoet, maar niet aan de bedrijfsvereisten op het tijdstip van levering. Deze veranderen namelijk en kunnen niet lang onveranderd blijven.

Het ontwerp van SSADM is een aantal keren veranderd sinds de eerste versie, door de ervaringen van gebruikers en van andere methodes. Ondanks de veranderingen, in SSADM in het bijzonder en in de watervalaanpak in het algemeen, is er veel kritiek. Dit komt doordat er tijd en geld in het softwareproject wordt gestopt, zonder dat het resultaat/output van het project wordt verbeterd.

• System Development Methodology (SDM)
• Dynamic Systems Development Method (DSDM)