Structured Systems Analysis and Design Methodology (SSADM)

Van Wikipedia

Dit artikel kan een redirect worden nadat de tekst is ingevoegd op de pagina Structured Systems Analysis and Design Method. Hier melden: Overleg.

SSADM staat voor "Structured Systems Analysis and Design Method", dit betekent: “Gestructureerde Methode voor Analyse en Ontwerp van Systemen”.

[bewerk] Geschiedenis

In 1980/1981 werd SSADM ontwikkeld door Learmonth & Burchett Management Systems voor de Britse overheid. De Britse overheid had behoefde aan een standaard, waarmee vervolgens alle software voor de overheid gebouwd moest worden.
John Hall is begonnen met het ontwerpen van SSADM en is daarmee de oorspronkelijke ontwerper. Samen met Keith Robinson bouwde hij versie 1 van SSADM. Korte tijd daarna (1983) verlieten beide personen Learmonth & Burchett Management Systems, om samen een nieuw bedrijf “Model Systems” op te starten.

Hieronder staat een lijst met jaartallen, waarin de belangrijkste ontwikkelingen op het gebied van SSADM staan vermeld.

1980 Er was behoefte om een standaard te hebben voor het ontwikkelen van software en “Central Computer and Telecommunications Agency (CCTA)” gaf opdracht om tot een standaard te komen.
1981 Er werden vijf methodes ontwikkeld. Er werd gekozen voor een methode die werd ontwikkeld door LBMS (Learmonth & Burchett Management Systems).
1983 Binnen de Britse overheid werd de SSADM-methode verplicht gesteld voor alle nieuwe IT-projecten die binnen de overheid werden gerealiseerd.
1984 De tweede versie van SSADM was ontwikkeld en werd vrijgegeven.
1986 De derde versie van SSADM was ontwikkeld en werd vrijgegeven. De “Britse National Computing Center” gebruikt deze standaard nu ook.
1989 De methode SSADM wordt meer volgens EUROMEHTOD-richtlijnen aangepast. CASE-producten certificatieschema wordt bij de SSADM standaard toegevoegd.
1990 De vierde versie van SSADM was ontwikkeld en werd vrijgegeven
1993 SSADM versie 4 werd uitgebreid met standaarden- en gereedschappenschema.
1995 SSADM versie 4+ bekend gemaakt, uiteindelijk is versie 4.2 vrijgegeven.
1996 SSADM versie 4.3 werd uitgebracht. De nadruk bij deze versie lag op het ontwikkelen van applicaties met een GUI (Grafische User Interface).

[bewerk] Filosofie

Voordat SSADM ontwikkeld was waren er geen eenduidige regels over hoe IT- projecten aangepakt dienden te worden. Het grootse probleem met projecten was dat de business requirements vaak niet volledig gehaald werden. Om deze reden gaf de Britse overheid de opdracht om een standaardmethode te ontwikkelen. De opvolgende jaren werd de methode uitgebreid en publiek gestald door de CCTA.
SSADM wordt beheerd door het DAB (Design Authority Board).
Het NNC (National Computing Centre) ontwikkelt en beheert de definitieve SSADM- documentatie.
SSADM is gebaseerd op de waterval methode.
SSADM behandeld de volgende fasen.

Haalbaarheidsonderzoekfase
Analysefase
Ontwerpfase

[bewerk] Fases

Fases waarin de methode is opgedeeld:

Fase 1 Haalbaarheid
Fase 2 Analyse van het huidige systeem
Fase 3 Schetsen van bedrijfsspecificaties
Fase 4 Requirements
Fase 5 Technische systeemopties (TSO’s)
Fase 6 Ontwerp - logisch
Fase 7 Ontwerp – fysiek

Fase 1 - Haalbaarheid

Omschrijving:
In de eerste fase wordt er kort gekeken of het systeem dat gevraagd wordt te bouwen haalbaar is binnen de gestelde business requirements.
Ook wordt er gekeken of er niet al een soortgelijk systeem ontwikkeld is, want dan kan dat systeem gebruikt worden.

Stappen van deze fase:
1. Definitie van het probleem – Als eerste moet er gekeken worden naar het bedrijf zelf en naar de informatie die het bedrijf nodig heeft. De huidige knelpunten in het bedrijf worden naar boven gehaald, zodat hierbij rekening gehouden kan worden met het te bouwen informatiesysteem.
2. Haalbaarheidsopties – Er wordt gekeken naar welke mogelijke opties er zijn voor het te ontwikkelen informatiesysteem met de bijbehorende business requirements.
3. Het resultaat van de twee bovenstaande stappen, resulteren in een haalbaarheidsverslag aan de opdrachtgever. Bij kleine projecten kan deze fase samengevoegd worden met fase 2.

Fase 2 - Analyse van het huidige systeem

Omschrijving:
In de tweede fase wordt op een hoog niveau de huidige situatie geanalyseerd. Er wordt gekeken hoe het huidige systeem werk, waar de knelpunten en problemen zitten. Dit wordt gedaan door middel van een DFD (zie verderop in artikel).

Stappen van deze fase:
1. Bedrijfsactiviteitendiagram
Er wordt een diagram gemaakt van de huidige bedrijfsactiviteiten waar misschien rekening mee gehouden moet worden. Alle regels of andere zaken die in het bedrijf gelden en die mogelijk invloed kunnen hebben op het te bouwen informatiesysteem, worden ook in de specificatie opgenomen.
2. Requirements onderzoek
De eisen voor het te ontwikkelen informatiesysteem worden in kaart gebracht. Als er dingen niet volledig zijn of missen, worden deze aangevuld in het nieuwe systeem. Gebruikers van het systeem worden ingeschakeld om hun mening te geven welke eisen en wensen ze hebben voor het nieuwe systeem.
3. Huidige situatieanalyse
Er wordt een DFD gemaakt waarin de huidige situatie in kaart wordt gebracht, met betrekking tot het nieuw te bouwen informatiesysteem. Deze stap gaat specifiek in op de verwerking.
4. Huidige gegevensanalyse
Deze stap is hetzelfde als de vorige stap, alleen wordt nu specifiek ingegaan op de data.
5. Opstellen van een logisch model
In deze stap wordt een schematisch model gemaakt van het huidige systeem. Doel is om de problemen in het huidige systeem te vinden.

Fase 3 - Schetsen van bedrijfsspecificaties

Omschrijving:
In deze fase wordt gekozen welke optie van de Business System Options (BSO) wordt gekozen. De BSO wordt in deze fase opgesteld, en aan de hand hiervan kan het management een keuze maken uit de beschikbare opties.

Stappen van deze fase:
1. Identificeren van Business System Options
Er wordt in deze stap uitgezocht welke opties er zijn voor het te ontwikkelen informatiesysteem. Deze opties moeten grotendeels voldoen aan de requirements van de gebruikers.
2. Selecteren van Business System Options
In deze stap bekijkt het management de Business System Options en zal hun mening over de opties geven die gepresenteerd worden.

Fase 4 - Requirements

Omschrijving:
In deze fase worden alle requirements verder uitgewerkt. De DFD's en LDM's worden verder uitgewerkt. Aan de hand van de in de vorige fase gekozen Business System Options, zullen de DFD's en LDM's gekeurd worden.

Stappen van deze fase:
1. Definitie gevraagde systeemverwerking
In deze stap worden worden de gebruikersrollen gedefinieerd in termen van System Data Flows.
2. Definitie gevraagde datamodel
Het in de vorige fase gemaakte logische datamodel wordt in deze stap verder uitgewerkt aan de hand van de gekozen Business System Options.
3. Werknemer werkomschrijving
Om duidelijk te krijgen welke activiteiten worden uitgevoerd door de werknemers, wordt er een “Work Practice Model” uitgewerkt.
4. Vebeteren van datamodel
Het datamodel wordt in deze stap verbeterd, door te normaliseren, zodat de kwaliteit wordt verbeterd.
5. Prototype bouwen
Voordat het gehele systeem wordt gebouwd, wordt eerst een prototype gebouwd om te kijken of het aan de eisen van de gebruiker voldoet. De gebruiker wordt op deze manier weer bij het proces betrokken.
6. Specificeren van de verwerking
In deze stap wordt het opvragen en vernieuwen van data bescheven.
7. Controleren van de doelen van het systeem
Dit is het laatste moment waarop het nog mogeiljk is om de requirements te veranderen.

Fase 5 - Technische systeemopties (TSO's)

Omschrijving:
Deze fase wordt gebruikt om meerdere TSO's te maken. Belangrijk in deze fase is dat er bepaald moet worden hoeveel TSO's er worden gemaakt. Er moet worden gelet op de kosten om elke TSO tot eenbepaald niveau uit te werken, de behoefte om noodzaak aan te tonen en onderzoek naar andere oplossingen.

Stappen van deze fase:
1.Definieer TSO
De mogelijke aanpakken van de functionele eisen worden bekeken en een aantal opties worden vastgelegd.
2. Selecteer TSO
De TSO's worden aan de gebruikers gepresenteerd, waarna een keuze gemaakt kan worden.

Fase 6 - Ontwerp - logisch

Omschrijving:
In deze fase worden twee producten gerealiseerd. Ten eerste een fysiek databaseontwerp. En ten tweede een set van programmaspecificaties. Deze twee producten worden gerealiseerd op basis van de logische ontwerpen.

Stappen van deze fase:
1. Definiëren van gebruikersdialogen
De structuren en navigatie van en tussen de dialogen wordt bepaald.
2. Definiëren van verversprocessen
Hierbij worden de error- en updategebeurtenissen uitgewerkt.
3. Definiëren van opvraagprocessen
Hierbij worden de error- en opvraaggebeurtenissen uitgewerkt.

Fase 7 - Ontwerp - fysiek

Omschrijving:
We zijn nu bij de laatste fase van deze methode aangekomen. In deze fase worden de fysieke data en processen vastgesteld. Rekening houdend met de gekozen fysieke omgeving waar het systeem in komt te draaien.

Stappen van deze fase:
1. Voorbereiden op het fysieke ontwerp
De regels van het implementatie systeem worden geleerd.
De requirements voor de logische en fysiek mapping worden bekeken.
De aanpak wordt gepland.
2. De functies worden gespecificeerd.
3. De dataontwerpen en procesontwerpen worden opvolgende gemaakt.

[bewerk] Technieken

SSADM gebruikt 3 basis technieken deze zijn:

Logische gegevens modelering: bij deze techniek word vastgesteld wat de bedrijfs data behoeften zijn en worden hier gemodeleerd door middel van Logical Data Structure.
Data Flow modellering: bij deze techniek worden de gegevensstromen gemodeleerd van het betreffende bedrijfsprocess. dit word gedaan door middel van een aantal Data Flow Diagramms (DFD's).
Entiteit/Gebeurtenis modellering: bij deze techniek worden de bedrijfs processen vastgestelt en gemodeleerd. hierbij word elke gebeurtenis gedocumenteerd als een model met een aantal entiteiten.