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.
Inleiding 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.
Historie 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.
Methode 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.
Fasering De SSADM-methode behandelt een aantal opeenvolgende analyse-, documentatie- en ontwerptaken voor het ontwikkelen van een applicatie.
Fase 0: Haalbaarheid (Feasibility Study) 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: 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. 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.
Fase 1: Analyse van het huidige systeem (Requirements Analysis) 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: 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. 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. 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. 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. 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.
Fase 2: Het schetsen van de bedrijfsspecificaties 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: 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. Selecteer Business System Options Voor deze stap worden de gebruikers en het management gevraagd naar hun mening over de gepresenteerde opties.
Fase 3: Requirementdefinities (Requirements Specification) 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: Definitie gevraagde systeemverwerking De huidige stap is bedoeld om de gebruikersrollen in het nieuwe systeem te definiëren in termen van System Data Flows. 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. 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. Werknemer werkomschrijving In deze stap wordt een Work Practice Model uitgewerkt zodat meer duidelijkheid verkregen wordt over de werkzaamheden die door werknemers moeten gebeuren. Verbeter datamodel Normaliseer het logische datamodel om de kwaliteit te verhogen. 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. Specificeer verwerking In deze stap moet de opvraging en verversing van de data beschreven worden die benodigd is voor het informatiesysteem. 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.
Fase 4: Technische systeemopties 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: Definieer TSO Hierbij wordt gekeken naar de mogelijke aanpakken en de functionele eisen, hieruit wordt een aantal opties gehaald. Selecteer TSO Presenteer de TSO's aan de gebruikers
Fase 5: Logisch ontwerp (Logical System Specification) 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: Definieer gebruikersdialogen Hierin worden de navigatie en de structuren van de dialogen bepaald. Definieer verversprocessen Hierin worden de error- en updategebeurtenissen uitgewerkt. Definieer opvraagprocessen Hierin worden de error- en opvraaggebeurtenissen uitgewerkt.
Fase 6: Fysiek ontwerp (Physical Design) 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: 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 Maak de specificatie af van de functies. Maak opvolgend de data- en procesontwerpen.
Technieken SSADM draait rond het gebruik van drie basistechnieken, namelijk Logische Gegevens Modellering, de Data Flow modellering en Entiteit/ Gebeurtenis modellering.