methode
Een methode kan worden gezien als het geheel van afspraken om te komen tot het gewenst eindresultaat. Ontwikkelmethoden zijn raamwerken die aangeven hoe ontwikkeltrajecten kunnen worden ingericht en uitgevoerd.
Ze omschrijven welke fasen, activiteiten en producten er bestaan, welke personen of rollen hieraan invulling dienen te geven en welke technieken en tools daarbij gebruikt kunnen worden.
traditionele systeemontwikkeling
Traditionele ontwikkelmethoden gaan ervanuit dat requirements op zeker moment stabiel en gefixeerd zijn en dat vervolgens het verloop van een ontwikkeltraject precies te voorspellen is. Dat ontwikkeltraject wordt vervolgens eenmaal doorlopen [lineaire of watervalmethoden]
kenmerken traditionele systeemontwikkeling
- vast stappenplan
- gescheiden rollen
- interpretatieproblemen
- stand-alone
vast stappenplan
Een vast stappenplan heeft de mogelijkheid tot controle op iedere stap in de diverse fases: analyse, ontwerp, bouw, test en de ingebruikname. Iedere stap wordt zorgvuldig geëvalueerd voordat de volgende stap gezet wordt.
Door deze vaste gecontroleerde fasering is dit een gedegen, eenduidige methode die moet leiden tot een voorspelbare en hoge kwaliteit van het eindproduct.
- bij elke fase gelden strikte documentatie-eisen
nadelen vast stappenplan
- De gebruikerseisen gericht op effectiviteit en kwaliteit, worden daarbij snel ondergeschikt gemaakt aan projectuitgangspunten met betrekking tot tijd en geld.
- het eenmalig opleveren van een ‘perfect’ systeem krijgt de volle aandacht en wordt maar weinig aandacht besteed aan toekomstige veranderingen.
gescheiden rollen
[ontwikkelaars, waaronder diverse typen analisten, ontwerpers, bouwers en andere specialisten]
Gebruikers worden regelmatig benaderd voor interviews, andere partijen mogen hun zegje doen bij het opleveren van de geplande mijlpalen. Elke verdere detaillering in een procesmodel binnen de traditionele methode moet uiteindelijk ook weer door het analyseteam volledig worden gedocumenteerd in het ontwerp, zonder dat er ook nog maar iets gebouwd is.
gescheiden rollen nadelen
- Als de bouwactiviteiten uiteindelijk kunnen plaatsvinden, wordt veel plaats ingeruimd voor aparte technische testfases. Deze kennen elk hun eigen specialisten, waardoor doorlooptijd en kosten weer navenant stijgen.
- Het probleem is dat de gebruiker pas aan het eind weer in beeld komt bij Gebruikers- of Acceptatietesten. Dan blijkt dat de wereld van de gebruiker ondertussen is veranderd of dat de requirements verkeerd zijn geinterpreteerd. Maar tijd voor grote veranderingen is er niet meer. Vaak is het slikken of stikken.
hoe ontstaan interpretatieproblemen
- door de schriftelijke en bureaucratische wijze van communiceren
- door de uiteindelijke interpretatie van de requirements zelf of de veranderende wensen en inzichten in de loop van de tijd
stand-alone
stand-alone systemen:
greenfield-situatie:
stand-alone systemen: er is geen uitwisseling met andere systemen.
greenfield- situatie: er is nog geen systeem om op aan te sluiten, of een oud systeem moet in zijn geheel worden vervangen.
er is meestal sprake van een stabiele, eenduidige infrastructuur: een platform, dus gemakkelijk te beveiligen en ook relatief makkelijk te beheren.
wat is er nodig bij een watervalaanpak
- De gebruiker weet precies wat hij nodig heeft.
- De gebruiker kan dat eenduidig uitdrukken.
- De ontwikkelaar kan dat foutloos interpreteren.
- De ontwikkelaar kan dit probleemloos realiseren.
- Als je klaar bent zijn de behoeften van de gebruiker niet veranderd.
traditionele methode conclusie
de traditionele methode sluit vaak niet aan bij informatiseringvraagstukken waarbij eindgebruikers een belangrijke rol spelen en waar verandering aan de orde van de dag is.
De methode voldoet zeker voor statische systemen in een relatief stabiele omgeving, maar toegepast binnen een dynamische, steeds veranderende omgeving is het een moeilijk hanteerbaar en onvolledig gereedschap.
beperkingen traditionele methoden
• Requirements zijn niet stabiel.
• Een doorlooptijd van enkele jaren past niet meer in een dynamische wereld waar korte time-to-
market essentieel is.
• Risico’s worden te laat ontdekt, vaak pas wanneer al veel in het project is geïnvesteerd.
• Omvangrijke tekstuele documentatie is moeilijk communiceerbaar en te onderhouden.
• Systemen zijn tegenwoordig vaak deel van een brede architectuur.
• Testen worden aan het eind van het traject gedaan, de kwaliteit van het systeem is niet van begin tot
eind zichtbaar.
kenmerken moderne systeemontwikkeling
- requirements
- iteratief en incrementeel
- gebruikersparticipatie
- organiseren van samenwerking • prototyping
- testen
reqs
Een systeem hoeft niet altijd in een keer met alle functionaliteit te worden opgeleverd.
wat moet nu en wat kan later, in een volgende versie of release? Prioritering van requirements, is een standaardonderdeel.
gebruikersparticipatie voordeel
- bredere acceptatie
- het faciliteert tevens de aanpassing van de eisen aan de hand van nieuwe inzichten
- het vergroot de kans dat het uiteindelijke product ook daadwerkelijk het juiste probleem oplost
Voorwaarde is wel dat gebruikers worden betrokken die genoeg inzicht hebben in het doel van het systeem en die tevens detailkennis hebben van de bedrijfsprocessen en de daarvoor benodigde informatie. Daarnaast is voor een snel en goed verloop de beslissingsbevoegdheid van de betrokken gebruikers belangrijk. Het management moet de participerende gebruikers hierbij voldoende ruimte voor onderhandeling bieden.
organiseren van samenwerking (workshop)
voordeel
- Workshops zijn een goed middel om binnen zeer korte tijd overeenstemming te bereiken tussen gebruikers en ontwikkelaars.
- Workshops verminderen in sterke mate de hoeveelheid geproduceerd papier, zorgen voor een betere, realistische afstemming en vergroten het draagvlak en de betrokkenheid.
voordeel prototyping
Prototyping versnelt de communicatie tussen gebruikers en ontwikkelaars doordat er wordt gecommuniceerd in een taal die gebruikers begrijpen
testen voordeel
[continue activiteit]
- problemen worden snel gesignaleerd en er wordt voorkomen dat het testen door tijdgebrek wordt ingekort.
eigenschappen traditionele SD
- linear, eenmalige doorloop analyse-ontwerp-bouw-gebruik
- gescheiden rollen
- interpretatieproblemen vanwege communicatiewijze
- stabiele, eenduidige infrastructuur, eenvoudig in onderhoud en beveiliging
- statische systemen in een relatief stabiele omgeving
- gebruiker weet wat hij nodig heeft en kan dat eenduidig uitdrukken
- de behoefte uit de business verandert niet tijdens het project
- de ontwikkelaar kan requirements foutloos interpreteren en probleemloos realiseren
- efficient proces, alleen effectief als het project zich er voor leent
- aanpassingen vrijwel onmogelijk
eigenschappen moderne SD
- gebruikersparticipatie
- reqs zijn onbekend en niet stabiel -> prioritering
- risico’s worden tijdens het project ontdekt
- prototyping en proof of concepts
- korte time to market
- handige communcatie ipv veel documentatie
- systemen zijn vaak deel van brede architectuur
- continu testen en incrementele oplevering
- dynamische, steeds veranderende functionele en technische omgeving
- effectief
- risicovermindering en draagvlak bij gebruikers
-
#1 RCA SYLLABUS50
-
#1 Swart H137
-
#1 System Development H1 + 228
-
#2 Stakeholder analysis C41
-
#2 Swart H215
-
#2 Swart H39
-
#2 Swart H731
-
#2 Swart H1534
-
#2 Swart H167
-
#2 Swart H187
-
#2 System Development H320
-
#3 Swart H416
-
#3 Swart H517
-
#3 Swart H1718
-
#3 System Development H416
-
#4 Swart H1212
-
#4 Swart H135
-
#4 System Development H511
-
#5 Swart H192
