#2 System Development H3 Flashcards
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.
