Structured Systems Analysis and Design Methodology

SSADM is Engels voor "Structured Systems Analysis and Design Methodology" en betekent in het Nederlands "Gestructureerde Methode voor Analyse en Ontwerp van Systemen".

Inleiding

SSADM werd ontwikkeld door LBMS in 1980/81 voor de IT-dienst van de Britse overheid, de CCTA (Central Computing and Telecommunications Agency).

De Britsenoverheid heeft opdracht gegeven om een standaard methode te ontwikkelen hoe programmatuur binnen de overheid ontworpen dient te worden. Voor dat deze standaard gebruikt werd waren er geen eenduidige regels hoe de IT projecten dienen te worden ontwikkeld. Resultaat hierdoor 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-server techniek, 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 nalevingschema voor programma`s en technieken die SSADM ondersteunden.

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 of 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 certificatie schema bij SSADM standaard bijgevoegd
1990 Versie 4 vrijgegeven
1993 SSADM V4 Standaarden en gereedschappen schema bij SSADM standaard bijgevoegd
1995 SSADM V4+ bekend gemaakt , uiteindelijk is V4.2 vrijgegeven

Methode

SSADM gebruikt een watervalmethode voor het ontwerpen van een informatiesysteem. De SSADM methode wordt gebruikt in voor de haalbaarheids onderzoekfase, analyse fase en de ontwerp fase bij een IT project. De overige fase 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 verlaagt worden en kan de voorgang 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 bijvoorbeeld Dynamic Systems Development Method (DSDM).

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 wijzingen is, SSADM in het bijzonder, de watervalmethode bekritiseerd omdat het veel meer tijd kost om een software project te maken zonder dat de uitkomst van de projecten verbeterd.

Fasering

De SSADM methode behandeld de opeenvolgende analyse-, documentatie- en ontwerptaken voor het ontwikkelen van een applicatie:

Fase 0 Haalbaarheid

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

In deze fase zitten de volgende stappen:

Probleem definitie

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.

Haalbaarheids opties

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

Aan het eind van deze fase wordt een Haalbaarheids verslag opgeleverd. Deze fase kan eventueel bij een klein project samen gevoegd worden met de volgende fase.

Fase 1 Analysering van het huidige systeem

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:

Bedrijfsactiveiten diagram

Hierin wordt een diagram gemaakt van de huidige bedrijfsactiveiten waar mogelijk rekening meer 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.

Requirements onderzoek

De requirements (eisen) voor het te ontwikkelen informatiesysteem worden hierin onderzocht op volledigheid en aangevuld waarnodig. 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 situatie analyse

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 gegevens analyse

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 waarbij 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 Sytem Options 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, en Data Flow Diagrammen. In deze fase zitten de volgende stappen:

Identificeer Business Sytem Options

In deze stap wordt uigezocht welke opties er zijn voor het te ontwikkelen informatie systeem.

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

Selecteer Business Sytem Options

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

Fase 3 Requirement definities

In deze fase worden de vereisten verder uitgewerkt zowel functionele requirements als niet functionele requirements. Er deze fase worden technieken gebruikt om de processen en datastructuren nog specifieker uit te werken. De DFD’s en LDS verder uitgewerkt en zullen getoetst worden aan de gekozen business system option van de vorige fase.

In deze fase zitten de volgende stappen:

Definitie gevraagde systeem verwerking

De huidige stap is bedoel om de gebruikers rollen in het nieuwe systeem te definiëren in termen van system data flows.

Definitie gevraagd data model

Het Logische data model 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 uitwerkt zodat meer duidelijkheid verkregen wordt over de werkzaamheden die door werknemers moeten gebeuren.

Verbeter data model

Normaliseer het Logische data model 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 word.

Specificeer Verwerking

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

Controleer systeem doelen

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

Fase 4 Technische systeem opties (TSOs)

In deze fase maakt men meedere TSOs. Het is belangrijk te bepalen hoeveel TSOs 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, hier uit worden een aantal opties gehaald.

Selecteer TSO

Presenteer de TSOs aan de gebruikers

Fase 5 Logisch ontwerp

In deze fase worden de logisch ontwerpen gebruikt om een fysiek database ontwerp te maken en om een set van programma specificaties te maken.

In deze fase zitten de volgende stappen:

Definieer Gebruikers dialogen

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

Definieer ververs processen

Hierin wordt de error en update gebeurtenissen uitgewerkt.

Definieer opvraag processen

Hierin wordt de error en opvraag gebeurtenissen uitgewerkt.

Fase 6 Fysiek ontwerp

De laatste fase van de SSADM methode hierin wordt de fysieke data en processen vastgesteld, gebruik makend 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 implementatie systeem.
Bekijk de requirements voor de logische en fysieke mapping.
Plan de aanpak

Maak de specificatie af van de functies.
Maak opvolgend de data en proces ontwerpen.

Technieken

De twee belangrijkste technieken gebruikt in SSADM zijn:

Datamodellering (Data modelling)

Identificeert en documenteert de data behoefte van een bedrijfsinformatiesysteem. Een logisch datamodel bestaat uit een Entity-Relationship model (ERD) en de bijbehorende documentatie

Datastroomdiagrammen (Data Flow Diagrams, DFD)

Identificeert en documenteert hoe data gebruikt wordt en zich verplaats in een bedrijfsinformatiesysteem. Een DFD bevat de processen, data-opslag plaatsen, eenheden buiten het systeem en dataverplaatsing in een informatiesysteem.

Entity Event Modelling

Hier in worden de toestanden beschreven waarin een entiteit zich kan bevinden. Deze beschrijving bestaat uit gebeurtenissen die effect hebben op de entiteit toestand en welke effecten dit geeft op de entiteit.

Bronnen