Hoofdstuk 15 Systeemontwikkeling en UML15.3 Ontwikkelmethoden
Er zijn in de afgelopen jaren een aantal methoden bedacht om geautomatiseerde systemen te ontwikkelen. |
| Nummer | Naam fase |
| 0 | Vooronderzoek |
| 1 | Definitiestudie |
| 2 | Functioneel ontwerp |
| 3 | Technisch ontwerp |
| 4 | Programmeren en toekennen van taken |
| 5 | Testen |
| 6 | Conversie en invoering |
| 7 | Gebruik en beheer van het systeem |
-
Vooronderzoek.
Tegenwoordig wordt er bijna nooit met een nieuw informatiesysteem begonnen terwijl er helemaal nog niets is. Je begint meestal niet from scratch (zo wordt dat in goed nederlands gezegd), meestal is er al wel een systeem, maar dat voldoet niet meer aan de eisen.
Er wordt daarom eerst onderzocht welke problemen het oude informatiesysteem heeft veroorzaakt. Uiteindelijk ontstaat er een plan om het informatiesysteem te verbeteren of te vernieuwen.
Het vooronderzoek wordt afgesloten met een rapport, en als het plan wordt goedgekeurd begint men aan fase 1.
- Definitiestudie
De definitiestudie is erop gericht inzicht te verkrijgen in het probleemgebied.
De bestaande processen worden onderzocht en de problemen worden tot op detailniveau uitgeplozen.
Daarna worden doelstellingen geformuleerd en mogelijke oplossingen uitgedacht. Van elke oplossing wordt bekeken wat voor soort systeem er nodig is en wordt ook bekeken hoeveel dat globaal kost.
Er worden ook functionele eisen aan een mogelijke oplossing gesteld.
Functionele eisen zijn de eigenschappen die een systeem moet hebben om te doen wat het moet doen.
Alle informatie van deze fase komt in een rapport met daarin aangegeven welke oplossing de voorkeur geniet.
Dit rapport is een mijlpaal. Dat wil dus zeggen dat pas na goedkeuring van het rapport verdergegaan wordt.
- Functioneel ontwerp
Nadat een bepaalde oplossing gekozen is, wordt onderzocht wat het systeem, dat gebouwd gaat worden, allemaal moet kunnen (dus welke functies moeten moeten kunnen worden verricht) en welke gegevens daarbij gebruikt moeten worden.
Dit heet het functioneel ontwerp.
- Technisch ontwerp
Aan de hand van het functioneel ontwerp kan er een werkelijk programma uitgedacht worden. In deze fase wordt vastgelegd hoe de in het functioneel ontwerp vastgelegde functionaliteit gerealiseerd gaat worden. Er vindt ook een onderverdeling plaats in technische eenheden zoals programma's, modules en functies.
Dit gebeurt zo gedetailleerd dat de ontwikkelaar in de volgende fase precies weet wet er gebouwd moet worden.
Alle schermen met hun invoervelden, berekeningen, controles en ondersteunende schermen worden beschreven.
De interface moet aan een aantal eisen voldoen. Het moet duidelijk zijn waar elk onderdeel voor dient, dat heet ook wel de transparantie van de bediening.
Het technisch ontwerp wordt afgesloten met een test op papier waarbij wordt nagegaan of de detaillering voldoende is om verder te gaan en of alle functionele eisen erin verwerkt zijn. Dit is weer een mijlpaalproduct.
- Programmeren en toekennen van taken
In deze fase worden de programma's van het systeem geschreven volgens de technische specificaties die in de vorige fase vastgelegd zijn.
Elk apart programma wordt geschreven met de bestanden die erbij horen en afzonderlijk getest. De test houdt in dat er bekeken wordt of de specificaties gehaald worden.
- Testen
Alle deelprogramma's worden nu in samenhang getest. Hierbij worden ook de procedures meegenomen en de gebruikershandelingen bekeken.
De klant doet in deze fase een formele acceptatietest. Dit wil zeggen dat de klant controleert of alle functionaliteiten volgens de specificaties gebouwd zijn. Zo niet, dan zal het programma door de programmeur bijgesteld moeten worden en wordt dat onderdeel opnieuw getest.
De mijlpaal van deze fase is een door de klant ondertekend acceptatierapport.
- Conversie en invoering
Bij de invoering van het nieuwe systeem is het in veel gevallen zo dat er een oud systeem bestond.
De gegevens van dat oude systeem zullen omgezet moeten worden zodat ze geschikt zijn voor het nieuwe systeem.
Dit heet conversie.
Bij de invoering wordt de gebruiker geschoold in het gebruik van het nieuwe systeem.
Na de scholing is het informatiesysteem klaar. Maar deze fase wordt pas afgerond als de systeemdocumentatie compleet is.
De systeemdocumentatie is de beschrijving van het systeem met daarin de programma's, de bestanden, de procedures en een beschrijving van de handmatige handelingen die nodig zijn.
- Gebruik en beheer van het systeem
Zodra het systeem af is, wordt het in gebruik genomen. Tijdens het gebruik vindt er regelmatig een evaluatie van het systeem plaats, waarbij gekeken wordt of het systeem nog wel voldoet.
Dit levert ideeën op voor de volgende systeemontwikkeling die op termijn weer gaat plaatsvinden.
Voor het beheer is het bijvoorbeeld belangrijk dat men back-ups van de bestanden maakt.
Het beheer betekent hoofdzakelijk het operationeel houden van het informatiesysteem, en het eventuele herstel ervan.
Voor het ontwikkelen van een geautomatiseerd informatiesysteem, fase 0-6, werd in de jaren 1970-1980 ongeveer 1 tot 2 jaar uitgetrokken. De fase Gebruik en beheer duurde vijf jaar of langer. Daarna vonden de meeste bedrijven het noodzakelijk een nieuwe ontwikkeling te starten, dus een systeem ging circa zeven jaar mee.
15.3.3 DSDM: Dynamic System Development Method
In de beginjaren negentig van de vorige eeuw werden er zogenaamde RAD-methoden ontwikkeld.
RAD staat voor Rapid Application Development. Een bekende RAD-methode is DSDM.
Dynamic System Development Method is een methode die vanaf 1995 is ontwikkeld.DSDM is gebaseerd op negen principes:
- Actieve betrokkenheid van gebruikers is noodzakelijk.
- DSDM-teams zijn gemachtigd besluiten te nemen.
- Het team levert regelmatig producten.
- De producten moeten onmiddelijk bruikbaar zijn voor het doel waarvoor ze ontwikkeld zijn.
- Herhalende en cyclische ontwikkeling zijn nodig om te komen tot een juiste oplossing.
- Wijzigingen tijdens de ontwikkeling zijn terug te draaien.
- Er wordt uitgegaan van een hoog niveau van benodigheden.
- Er wordt gedurende de gehele levencyclus van een product getest.
- Alle betrokkenen moeten samenwerken en meewerken.
- Actieve betrokkenheid van gebruikers is noodzakelijk.
In DSDM staat de gebruiker centraal.
Beslissingen die genomen zijn zonder de gebruiker daarbij te betrekken roepen vaak weerstand op, de gebruiker is dan meestal niet tevreden met het product.
Bij SDM staan gebruikers buiten het ontwikkelproces en geven alleen informatie, maar bij DSDM zijn de gebruikers actief betrokken bij het ontwikkelproces.
- DSDM-teams zijn gemachtigd besluiten te nemen.
De teams bestaan uit gebruikers en ontwikkelaars. Zij moeten beslissingen kunnen nemen wanneer uit overleg en voortschrijdend inzicht blijkt dat specificaties anders zijn dan eerder afgesproken.
Wanneer teamleden steeds terug moeten naar hun management vertraagt dat.
- Het team levert regelmatig producten.
Het werk van DSDM-teams richt zich op producten die op te leveren zijn in een afgesproken tijd.
De tijd is kort, daarom zal het team alleen die activiteiten ontplooien die nodig zijn om het doel (een product opleveren) te bereiken.
- De producten moeten onmiddelijk bruikbaar zijn voor het doel waarvoor ze ontwikkeld zijn.
De nadruk van DSDM ligt op het leveren van producten met een bepaalde functionaliteit in een vooraf vastgestelde tijd.
De producten moeten bij oplevering werken en dus meteen van nut zijn.
Bij de vroegere ontwikkelingsmethoden (gebaseerd op de watervalmethode) was de ontwikkelperiode lang en daardoor was de kans groot dat de behoefte van het bedrijf veranderd was en dus het product niet meer bruikbaar. Dat probeert men bij de DSDM-methode te voorkomen.
- Herhalende en cyclische ontwikkeling zijn nodig om te komen tot een juiste oplossing.
Bij de DSDM-methode sturen de ontwikkelaars steeds bij wanneer de gebruikers met kritiek komen op het product.
Daardoor maakt DSDM het mogelijk dat systemen steeds blijven groeien.
Dit is een goed voorbeeld van het toepassen van de Deming-cirkel (zie hoofdstuk 13): plan, do, check, act.
- Wijzigingen tijdens de ontwikkeling zijn terug te draaien.
Als gebruikers met een verandering van het programma niet tevreden zijn, kan deze verandering simpel teruggedraaid worden door aan de voorlaatste versie verder te bouwen.
Omdat er vaak verschillende ontwikkelingen tegelijkertijd plaatsvinden is het verschrikkelijk belangrijk een goed versiebeheer te hebben.
- Er wordt uitgegaan van een hoog niveau van benodigdheden.
De specificaties van het programma, het doel en de reikwijdte zijn net zoals bij andere methoden van groot belang.
Door de cyclische en zich herhalende ontwikkeling zullen bepaalde specificaties in een later stadium pas gedetailleerd beschreven worden. Zo zal men altijd uitgaan van het hoogst bereikbare niveau in functionaliteiten van een programma of een systeem, maar het zal niet allemaal op hetzelfde moment bereikt worden.
- Er wordt gedurende de gehele levenscyclus van een product getest.
Testen wordt niet gezien als een apart proces maar is onderdeel van de systeemontwikkeling.
Elk programma en elk deelsysteem wordt getest bij oplevering en zodoende zorgt de gebruiker er voor dat het gemaakte onderdeel ook aan de wensen voldoet.
In het begin van de ontwikkeling wordt er getest op functionaliteit van het ontwikkelde deel.
Aan het eind van het ontwikkelingsproces is de test van het grotere geheel belangrijk.
- Alle betrokkenen moeten samenwerken en meewerken.
Omdat snelheid een van de aspecten is van deze vorm van systeemontwikkeling kan de ontwikkeling alleen goed gaan wanneer alle betrokkenen meewerken.
Als de gebruikers onvoldoende meewerken dan is dat de doodsteek voor het proces. Er zal dan onvoldoende feedback zijn om de verschillende onderdelen volgens specificaties to bouwen en het systeem kan gemakkelijk een flop worden.
Beschrijving van DSDM
DSDM is een methode die de ontwikkeling van IT-systemen vastlegt in een raamwerk van een tijdsplanning (timeboxes), en die
tijdsplanning is vrij kort.De duur van het project en de te gebruiken hulpbronnen worden vastgelegd, maar de specificaties die gerealiseerd zullen gaan worden in het verloop van het project kunnen variëren.
Dus in DSDM is de tijd vooraf vastgelegd en het gewenste product maar ten dele.
Een kenmerk van DSDM is dat het volledig onafhankelijk is van leveranciers, ontwerpmethodes en van ontwikkelomgevingen.
Verder is het kenmerkend dat de eindgebruiker zeer actief deelneemt aan het ontwikkelingsproces.
In het begin van het project worden de specificaties op globaal niveau ingedeeld op prioriteiten, volgens het zogenaamde MoSCoW-principe.
De afkorting MoSCoW staat voor de gewenstheid van de diverse onderdelen van het gewenste systeem:
- Must have - die onderdelen moeten in ieder geval worden gerealiseerd;
- Should have - zouden eigenlijk moeten worden gerealiseerd, maar zijn niet onmisbaar;
- Could have - onderdelen die handig zijn om op te nemen, maar zonder problemen achterwege kunnen blijven;
- Would not have - onderdelen die waarschijnlijk niet aan bod komen, maar die in de toekomst interessant zijn
Het proces bestaat uit vijf fasen:
- Haalbaarheidsonderzoek
- Bedrijfsonderzoek
- De functiebepalende cyclus
- De cyclus ontwerpen en bouwen
- De implementatie cyclus
- Haalbaarheidsonderzoek.
In het haalbaarheidsonderzoek wordt onderzocht of de applicatie ontwikkeld kan worden met DSDM.
Er wordt vooral gekeken of aan de voorwaarden, technisch en organisatorisch, kan worden voldaan.
Dit onderzoek duurt ongeveer twee weken.
- Het bedrijfsonderzoek.
In het bedrijfsonderzoek wordt de totale activiteit van het project bekeken in het licht van het functioneren van het bedrijf.
In grote lijnen wordt beschreven waaraan de applicatie moet voldoen en hoe het systeem opgezet gaat worden. Ook wordt de onderhoudbaarheid van het systeem beschreven.
Dit onderzoek duurt niet langer dan een maand.
-
De functiebepalende cyclus.
Deze fase is één van de twee fasen waarin prototypes gebouwd worden.
In deze fase gaat het vooral om de functionaliteiten.
Het prototype in deze fase is een programma dat vooral bedoeld is om er achter te komen wat het programma moet doen. Dit gebeurt door analyse door gebruiker en ontwikkelaar.
Voor de analyse worden allerlei technieken gebruikt die ook in de traditionelere methoden gebruikt worden.
- De cyclus ontwerpen en bouwen.
Gedurende deze fase is het belangrijkste dat de prototypes zodanig gebouwd zijn dat ze echt gebruikt kunnen worden.
De overgang van de vorige fase naar deze fase is gebaseerd op overeenstemming tussen gebruikers en ontwikkelaars van een deel van het functionele model. Dit kan stap voor stap gebeuren.
Er is daarom geen harde scheidslijn tussen de vorige fase en deze fase. Sommige onderdelen zijn nog in fase 3 (functiebepaling), terwijl andere al in fase 4 (bouwen) zijn.
- De implementatiecyclus.
In de implementatiefase wordt het nieuwe (deel)systeem ingevoerd in het bedrijf, en de gebruikers worden getraind. Verder wordt de bedrijfsvoering herzien ten aanzien van die zaken die geautomatiseerd zijn.
Uit die herziening volgen vier mogelijkheden, kijk maar naar de pijlen die daaruit voortkomen in bovenstaande figuur.- Alles werd opgeleverd en juist geïmplementeerd en er is geen behoefte aan verdere ontwikkeling (dus geen pijl).
- Een nieuwe functionele omgeving is ontdekt gedurende de ontwikkeling en implementatie. De ontwikkeling start dan weer bij het bedrijfsonderzoek (Pijl 1).
- Een minder essentieel deel van de functionele omgeving ontbreekt, bijvoorbeeld door tijdgebrek.
Er wordt weer gestart met het bepalen van de functionaliteiten (Pijl 2). - Een niet nieuw functioneel onderdeel was onvoldoende ontwikkeld en er moet nog een extra inspanning geleverd worden in ontwerp en bouw (Pijl 3).
Tijdframes (timeboxes)
DSDM gebruikt tijdframes.Aan het einde van het tijdframe moeten er één of meerdere werkende producten worden opgeleverd.
Er worden verschillende tijdframes achter elkaar gepland als er veel producten opgeleverd moeten worden.
Een tijdframe heeft gemiddeld een lengte van zes weken.
Elk tijdframe bestaat uit drie delen: deel 1 bestaat uit onderzoek of het team nog in de juiste richting gaat, dan volgt de verfijning (deel 2) en als laatste (deel 3) de controle waarbij alle onderdelen die nog openstaan afgerond worden en gekeken wordt naar vervolgacties.
Doordat de tijd krap is, is een directe communicatie in het team (gebruikers en ontwikkelaars) noodzakelijk.
In een vastgestelde korte tijd moet altijd een resultaat kunnen worden opgeleverd, want volgens de Paretoregel of de 80/20-regel kun je met 20 procent van de inspanning 80 procent van het werk gedaan krijgen.
Hiermee bedoelt men eigenlijk gewoon dat je je op de juiste zaken moet concentreren.
Het patroon van het 80/20 principe werd voor het eerst in 1897 ontdekt door de Italiaanse
econoom Vilfredo Pareto (1848 - 1923).
Sindsdien is het vele malen herontdekt in uiteenlopende situaties.
Het staat bekend onder verschillende namen, bijvoorbeeld de 80/20 regel, de Wet van Pareto, het principe van de minste inspanning.
Vilfredo Pareto was een Italiaanse econoom die had opgemerkt dat 20% van de Italianen 80% van de totale rijkdom van het land bezaten.
Dit geldt ook voor de gehele aardbol: 80% van de rijkdommen op onze planeet is in handen van 20% van de bewoners.
Deze wet kan worden toegepast op een heleboel gebieden, bijvoorbeeld op de verkeersveiligheid: 20% van de automobilisten veroorzaken 80% van de ongevallen.
Het kan ook worden toegepast op de sociale zekerheid: 20% van de mensen nemen 80% van de onkosten voor hun rekening.
Bij een bedrijf bepalen meestal slechts 20% van de klanten samen zo'n 80% van de omzet.
Zelfs blijkt het meestal zo te zijn dat 20% van je kleren 80% van de tijd door je gedragen worden.
Het Pareto Principe geeft aan dat een gering aantal oorzaken (beperkte input of moeite) verantwoordelijk is voor het merendeel van de resultaten (output of beloning).
Sindsdien is het vele malen herontdekt in uiteenlopende situaties.
Het staat bekend onder verschillende namen, bijvoorbeeld de 80/20 regel, de Wet van Pareto, het principe van de minste inspanning.
Vilfredo Pareto was een Italiaanse econoom die had opgemerkt dat 20% van de Italianen 80% van de totale rijkdom van het land bezaten.
Dit geldt ook voor de gehele aardbol: 80% van de rijkdommen op onze planeet is in handen van 20% van de bewoners.
Deze wet kan worden toegepast op een heleboel gebieden, bijvoorbeeld op de verkeersveiligheid: 20% van de automobilisten veroorzaken 80% van de ongevallen.
Het kan ook worden toegepast op de sociale zekerheid: 20% van de mensen nemen 80% van de onkosten voor hun rekening.
Bij een bedrijf bepalen meestal slechts 20% van de klanten samen zo'n 80% van de omzet.
Zelfs blijkt het meestal zo te zijn dat 20% van je kleren 80% van de tijd door je gedragen worden.
Het Pareto Principe geeft aan dat een gering aantal oorzaken (beperkte input of moeite) verantwoordelijk is voor het merendeel van de resultaten (output of beloning).
