RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V.
Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 RAD, DE DEFINITIE... 4 3 KENMERKEN... 5 4 FASERING... 6 5 TESTEN... 8 6 LITERATUURVERWIJZINGEN... 10
Organisatie SYSQA B.V. Pagina 3 van 10 1 Inleiding 1.1 Algemeen De traditionele systeemontwikkelingsmethodes zoals SDM I, SDM II en LAD hebben, zo bleek in de praktijk, een aantal nadelen. Zo wordt de fasering als rigide ervaren, in de doorlooptijd vaak langer dan gewenst, zijn de kosten hoog en is de gebruikersparticipatie te laag. Als gevolg van deze tekortkomingen zijn er eind 20 e eeuw een aantal systeemontwikkelingsmethodes ontstaan die tegemoet komen aan deze tekortkomingen. De methodes worden gekenmerkt door een hoge gebruikersparticipatie en het incrementeel of iteratief ontwikkelen. Met dit laatste wordt bedoeld dat er meerdere ontwikkel-rondes na elkaar plaatsvinden. In plaats van te streven in één keer het systeem te bouwen worden meerdere versies gemaakt en steeds verbeterd en verfijnd. Enkele van deze methodes zijn IAD (Iterative application development) en DSDM (Dynamic system development method). Basis van deze methodes is RAD, Rapid Application Development. Deze introductie gaat in op de principes van RAD. Achtereenvolgens wordt het model en de kenmerken behandeld. Vervolgens wordt ingegaan op de fases van RAD. Als laatste wordt ingegaan op de invloed van RAD op testen. 1.2 Versiebeheer Versie Status Datum Auteur Opmerkingen 0.1 Concept 4 september 2000 SYSQA Eerste opzet 0.2 Concept 15 januari 2001 SYSQA Doorgaan waar ik gebleven was 1.1 Concept 12 april 2011 SYSQA Aanpassen aan nieuwe huisstijl
Organisatie SYSQA B.V. Pagina 4 van 10 2 RAD, de definitie Rapid application development (RAD) is een vrij jonge methode om informatiesystemen te ontwikkelen. De methode is nog in ontwikkeling, er bestaat derhalve nog geen éénduidige definitie van RAD. Daarnaast zijn er een aantal nieuwe methodes die zijn afgeleid van RAD. Voorbeelden hiervan zijn IAD (iteratief application development) en DSDM. In dit stuk wordt RAD als volgt gedefinieerd: RAD is een methodiek om informatiesystemen te ontwikkelen gebaseerd op hoge gebruikersinbreng en iteratief ontwikkelen. De doelstelling van RAD valt uiteen in meerdere zaken: hoge gebruikersparticipatie om te komen tot een systeem dat aansluit bij de wensen en eisen van de gebruiker; lage kosten; snelle ontwikkeling, korte "time to market"; goede kwaliteit.
Organisatie SYSQA B.V. Pagina 5 van 10 3 Kenmerken Er is een aantal kenmerken die vaak bij RAD-trajecten terugkomen. Het is dus niet zo dat van al deze aspecten per sé terug moeten komen. Vaak zijn RAD- of aanverwante trajecten een samenstel van deze aspecten. Gebruik krachtige ontwikkeltools. Door het gebruik van krachtige ontwikkeltools kunnen snel (deel)applicaties ontwikkeld worden op een gecontroleerde wijze. Daarnaast is de kwaliteit van de coding vaak beter en is de productiviteit hoger. Iteratief ontwikkelen. In plaats van het hele systeem met al zijn gewenste functionaliteiten te bouwen wordt eerst een beperkte versie gemaakt die op basis van de ervaringen ermee aangepast wordt. Dit proces wordt een aantal keer herhaald en op deze wijze evolueert het systeem naar zijn uiteindelijke vorm. Een variatie hierop is het incrementeel ontwikkelen; dit is het stapsgewijs uitbouwen tot een steeds grotere bruikbaarheid. De tussenproducten worden wel pilots genoemd. Hoge gebruikersparticipatie Tijdens alle fases zijn gebruikers intensief betrokken bij de ontwikkeling. In het begin vooral het management, later voornamelijk eindgebruikers van het systeem. Door middel van de gebruikersinbreng wordt getracht een systeem te maken wat beter aansluit op de eisen en wensen van de gebruiker. Toepassing prototyping. Door middel van prototyping communiceert de ontwikkelaar met de gebruiker over het te bouwen systeem. Door middel van elkaar opvolgende prototypes wordt toegewerkt naar het uiteindelijke systeem. Kleine ontwikkelteams. De gebruikersorganisatie is vertegenwoordigd in deze teams. Indien er een systeem gebouwd moet worden dat te groot is om in één klein team ontwikkeld te worden, zijn er meerdere, parallel werkende teams. De teams worden wel aangeduid als SWAT-teams. Dit staat voor Skilled With Advanced Tools. Timeboxing. Dit is een van te voren gedefinieerde periode waarin een bepaalde functionaliteit gebouwd wordt. Indien de functionaliteit niet gehaald wordt, wordt de einddatum niet verschoven. In plaats daarvan worden er minder functionaliteiten gebouwd. Op deze wijze tracht men overeniginering te voorkomen. "Juicy bits first" Het principe dat binnen een timebox eerst de belangrijkste onderdelen of functionaliteiten worden gebouwd. Indien de opdracht voor de timebox niet gehaald wordt, vallen vanzelf de minst belangrijke onderdelen vanzelf af. Herbruikbaarheid. Er moet naar gestreefd worden om kleine, herbruikbare eenheden software te bouwen. Dit verkort de ontwikkeling en verhoogd de kwaliteit, maar hierdoor kan er soms minder goed tegemoet worden gekomen aan de gebruikerswensen. 80/20 Deze werkwijze berust op de veronderstelling dat in 20% van de tijd 80% van de functionaliteit wordt ontwikkeld. Als men op 80% zit stopt men met ontwikkelen voor dat moment. De finetuning en completering volgt later, in een latere iteratie. Op deze manier beperkt met de doorlooptijd van iteraties, waardoor de snelheid erin blijft.
Organisatie SYSQA B.V. Pagina 6 van 10 4 Fasering Het ontwikkelproces conform RAD bestaat uit de volgende fases: Joint requirements planning; JAD; Prototyping; Realisatie; Implementatie; Overall planning en beheer. JRP JAD Prototype Realisatie Implementatie Overall Planning en Beheer Realisatieproces Joint requirements planning (JRP) Doel van de JRP-fase is dat opdrachtgever en project overeenstemming bereiken over de te bouwen functionaliteit, kwaliteitseisen, het ontwikkelproces en de projectorganisatie. De JRP is het beste te vergelijken met de definitiestudie uit SDM. Tijdens de JRP worden één of meerdere workshops georganiseerd. Deelnemers zijn het management van de opdrachtgever en bij voorkeur vertegenwoordigers van de gebruikers en enkele leden van het realisatieteam. De workshop staat onder leiding van een onafhankelijke workshop leider, ook wel vaak facilitator genoemd. Tijdens de JRP wordt de rechtvaardiging dat het systeem gebouwd gaat worden en de requirements vastgesteld. Vervolgens worden de functies die het systeem uit gaat voeren vastgesteld. Over het algemeen levert de JRP de rechtvaardiging, requirements en de architectuur van het systeem op. Joint application design (JAD) Doelstelling van de JAD-fase is het gezamenlijk ontwerpen van verschillende functies van het systeem. JAD gebeurt eveneens in workshopsessies onder leiding van een facilitator. Deelnemers zijn in dit geval de ontwerpers/ontwikkelaars (bij RAD zijn deze functies soms gecombineerd), de opdrachtgever en mogelijk eindgebruikers en eventueel de architect. Tijdens de sessie worden de functies tot op detail ontworpen. Hierbij wordt zoveel mogelijk gebruik gemaakt van hulpmiddelen zoals brown paper of ontwerptools. Doel is dat de ontwerpers/ontwikkelaars een goed besef krijgen van wat de eisen en wensen van de opdrachtgever en de gebruikers zijn en een ontwerp gerealiseerd wordt dat aan deze eisen voldoet. Door de actieve manier van samenwerken wordt getracht de communicatiemuur te doorbreken. Prototyping Doel van de fase prototyping is het gezamenlijk ontwerpen van een protype van het systeem.
Organisatie SYSQA B.V. Pagina 7 van 10 Prototyping is een technieken om snel een ruwe versie van het ontworpen systeem te bouwen. Prototyping is met name geschikt voor het ontwerpen van de user-interface. Op basis van het prototype kan de opdrachtgever en, indien aanwezig, de gebruiker het toekomstige systeem beoordelen en eventuele verbeteringen aanbrengen. Vooral bij systemen waarvan het succes in hoge mate afhankelijk is van de user interface, is het toepassen van prototyping dus belangrijk. Bij RAD dienen de gebruikers het prototype te beoordelen. Indien de toekomstige gebruikers uit een beperkte groep bekende personen of organisaties bestaan kan de opdrachtgever proberen een vertegenwoordiging hiervan uit te nodigen om het prototype te beoordelen. Als de groep toekomstige gebruikers niet bestaat uit een beperkte groep bekende personen of organisaties, kan getracht worden een representatieve afvaardiging (potentiële) gebruikers het prototype te laten beoordelen. Realisatie Op basis van de requirements (JRP), het ontwerp (JAD) en het prototype wordt de applicatie ontwikkeld. De realisatie vindt iteratief plaats. Delen van het systeem kunnen beoordeeld worden door de opdrachtgever, dit kan ook geïntegreerd worden in het testproces. Implementatie De implementatie kan plaatsvinden als het hele systeem af is, het kan gefaseerd gebeuren. Als vanzelfsprekend dienen de afzonderlijke delen bruikbaar te zijn en meerwaarde te hebben voor de gebruiker. Het kan zelfs voordelen hebben het systeem in systemen beschikbaar te stellen. Iedere keer als er weer een deel is geïmplementeerd, zijn de gebruikers aangenaam verrast en kan hij of zij meer. Voorwaarde is wel dat de eerste versie voldoende functionaliteit bevat zodat de gebruiker voldoende redenen heeft het systeem te gebruiken. Ook is het een eis dat nieuwe versies foutloos zijn. Één slechter ervaring kan het verlies van gebruikers veroorzaken.
Organisatie SYSQA B.V. Pagina 8 van 10 5 Testen Het ontwikkelproces is bij RAD, zoals uit bovenstaande blijkt, een dynamisch, flexibel proces met hoge betrokkenheid van de opdrachtgever en mogelijk gebruikers. Dat geldt niet voor het klassieke testproces zoals we dat kennen. Bij het testproces zoals we dat kennen is sprake van een aantal fases die elkaar opvolgen. Daarom dient het testproces aangepast te worden bij het toepassen van RAD of een daarvan afgeleide methode. Het testproces bestaat uit de volgende fases: Teststrategie Voorbereiding Specificatie Uitvoering Testafronding Inzet test tools Test Strategie Voorbereiding Specificatie Uitvoering Test Afronding Overall Planning en Beheer Testproces Teststrategie Het testproces start met het opstellen van een teststrategie. In de teststrategie wordt gesteld wat het doel is van de test en wat op welke manier getest gaat worden. Als input hiervoor worden de rechtvaardiging en de requirements van het systeem genomen, producten die tijdens de JRP worden gemaakt. Tijdens de test dient namelijk vastgesteld te worden of het uiteindelijke systeem tegemoet komt aan de rechtvaardiging en de requirements. Eén van de eindproducten van de teststrategie is een lijst eisen en acceptatiecriteria die alle stakeholders aan het systeem stellen. Tevens is in de teststrategie aangegeven op welke wijze wordt vastgesteld hoe aan de eisen en acceptatiecriteria is voldaan. Voorbereiding Nu bekend is wat getest gaat worden, wordt het testproces verder ingericht. Zaken als organisatie, infrastructuur, mijlpalen en bijbehorende producten worden gedefinieerd. Bij voorkeur worden ook sjablonen en andere hulpmiddelen gemaakt om de testspecificatie en uitvoering te ondersteunen. Een andere belangrijke activiteit is de beoordeling of testtools meerwaarde hebben bij dit project. De implementatie van testtools wordt dan tijdens deze fase voorbereid (Één, twee, drie, test, Computable 25 februari 2000). Specificatie Het hart van testen is en blijft het specificeren van testgevallen. In de klassieke testaanpak gebeurt dat nadat het ontwerp is gemaakt. Mede hierdoor kost het testtraject, mits het om een kwalitatief goed testtraject gaat, veel tijd, wat een negatief effect heeft op de doorlooptijd. Daarom dient er bij RAD gestart te worden met het specificeren van testgevallen. Het specificeren van testgevallen dient dus gelijk op te lopen met het ontwerp en de bouw. Dit pleit ervoor dat de tester ook aanwezig is bij de JAD-sessies. Op basis van de informatie uit de JAD-sessies kan de tester direct testgevallen maken. Door de testspecificaties naast de functionele specificaties te leggen kunnen lacunes en misinterpretaties in beide documenten gevonden worden.
Organisatie SYSQA B.V. Pagina 9 van 10 Als de testspecificaties toch gebaseerd worden op de functionele specificaties is er een kortere tijd voor de testvoorbereiding. Mogelijk is het natuurlijk wel, het specificeren van testgevallen is dan eenvoudiger. Het specificeren van testgevallen kan door (vertegenwoordigers van) gebruikers gebeuren. Het professioneel toepassen van testtechnieken blijft echter van groot belang. Het gebruik van testtechnieken bepaalt in hoge mate de professionaliteit van de test. Toekomstige gebruikers kunnen daarom opgeleidt worden tot tester. Gegeven het eerder genoemde afbreukrisico is het inzetten van professionele testers vaak te prefereren. Uitvoering De uitvoering van testgevallen dient zo vroeg mogelijk plaats te vinden. Het beoordelen van de user-interface is al mogelijk als het prototype klaar is. De eerste versie van het systeem kan ook direct getest worden. Bevindingen worden dan direct meegenomen. Ook in de uitvoeringsfase heeft de inzet van professionele testers een kwaliteitsverhogend effect op het testproces. Bij nieuwe versies van het systeem wordt de uitgebreide of aangepaste software getest. Het is echter minstens zo belangrijk dat de onveranderde delen van het systeem ook onveranderd werken. Regressietesten dus. Daarom is het conserveren van testscripts van groot belang. Als bij de regressietest blijkt dat delen van de testscripts niet worden bewaard, dan wel onduidelijk of onjuist zijn, kost dit direct meer tijd. Goed conserveren dus. Testafronding Een deel van de testafronding, het conserveren van testware, dient te gebeuren tijdens de specificatie en uitvoeringsfase. Bij het afsluiten van het traject dient het echter zodanig geconserveerd te worden dat ook andere partijen gebruik kunnen maken van de testware. Inzet testtools Door het grote aantal hertests bij RAD is de inzet van testtools die de testuitvoering automatiseren mogelijk zeer voordelig. Het onderzoek of testtools ingezet dienen te worden vindt plaats tijdens de voorbereiding. De inzet vindt plaats tijdens de specificatie en uitvoering. De voordelen worden vooral benut tijdens de uitvoering. Overall planning en beheer Het gehele testproject dient optimaal afgestemd te worden op de overige projectactiviteiten.
Organisatie SYSQA B.V. Pagina 10 van 10 6 Literatuurverwijzingen Rapid Application Development James Martin 0023767758 De opwaartse spiraal van systeemontwikkeling H.J.J. Cannegieter Computable 18 van 7 mei 1999. Aanvullende informatie op te vragen bij het productmanagement