door Marien de Gelder
12 februari 2013, 18:11
1 reactie
deel dit artikel

Marien de Gelder is business unit manager Softwareontwikkeling bij OGD ict-diensten. Met zijn achtergrond als software-ontwikkelaar werkt hij dagelijks samen met klanten om slimme oplossingen voor ict-problemen te bedenken op basis van bestaande systemen of nieuwe toepassingen. In een serie van vier blogposts vertelt hij hoe we bij OGD tegen software-ontwikkeltrajecten aankijken. Dit is de tweede post.

Wij merken bij OGD dat het belangrijk is om goede afspraken te maken binnen een software-ontwikkelingtraject. Een dergelijk traject bestaat uit een aantal stappen. Cruciale stappen, want wordt er een overgeslagen, dan valt het project als een kaartenhuis in elkaar. Of op z’n minst is het minder geslaagd. OGD is hier natuurlijk niet blij mee, want wij willen tevreden klanten. En die krijg je door van te voren goed voor te lichten over de verschillende fasen in een ontwikkeltraject.

Ontwikkeling vanuit de garage

Deze stappen gelden voor elk ontwikkeltraject. Of dat nu in een garage plaatsvindt of wordt uitgevoerd door een grote multinational. En de rolverdeling moet heel duidelijk zijn. Is dat niet het geval, dan gaan de rollen door elkaar lopen. Mensen denken van elkaar dat zij bepaalde taken wel op zich zullen nemen, waardoor rollen onverdeeld of half verdeeld worden. Wanneer bijvoorbeeld niemand de planning in de gaten houdt.  En zo loopt het project in de soep. Communicatie is ook hier weer cruciaal.

Elke stap telt

Elke stap vervult een unieke functie binnen het traject. En elke stap moet worden uitgevoerd door iemand die er ook echt verstand van heeft. Dat mag dan ook best dezelfde persoon zijn voor verschillende stappen. Bijvoorbeeld een functioneel ontwerper die ook het grafische ontwerp doet, en het testen op zich neemt. Zolang ze maar weten wat ze doen.

Iemand moet de kar trekken

Over het algemeen moet er binnen de organisatie een kartrekker voor het softwareproject zijn. De man of vrouw met visie, met het idee van wat er nodig is. Deze persoon noemen we ook wel de producteigenaar. Hij of zij stuurt niet aan, maar heeft wel een grote zakelijke verantwoordelijkheid en doet de uiteindelijke controle of het opgeleverde klopt met wat er aanvankelijk bedacht is. En of de bepaalde targets gehaald kunnen worden met het opgeleverde.

Hoe het werkt en wat het doet

De functioneel ontwerper gaat over de binnenkant van het ontwerp. Dus hoe het werkt, de functionaliteit. De grafisch ontwerper gaat vervolgens over hoe het eruit ziet. Zijn deze rollen niet goed verdeeld, dan bestaat het risico dat het eindresultaat niet doet wat het beoogd was te doen. De ontwikkelaar is vervolgens de slimmerik die dit alles in code omzet en de software ontwikkelt en daadwerkelijk laat werken.

Test… test… test…

De tester test wat de ontwikkelaar gedaan heeft. Idealiter aan de hand van een script of plan, controleert hij of zij of de software ook echt doet wat het zou moeten doen. Deze fase is erg belangrijk, het product gaat heen en weer tussen ontwikkelaar en tester. Wordt er niet goed overlegd tussen de tester en ontwikkelaar, dan heeft dat veel invloed. Of de code goed onderhoudbaar is bijvoorbeeld. En praat de ontwikkelaar weer niet goed met de klant – of de projecteigenaar – dan wordt er door die ruis ook niet het gewenste product opgeleverd.

Uit het ontwikkeltraject volgt de geproduceerde software, en dan begint de beheerfase. En dan wordt pas echt duidelijk hoe goed de software werkt omdat de eindgebruiker uiteindelijk het laatste woord heeft.

De eerste blogpost in deze reeks, over verschillende organisatietypen, vind je hier. De volgende post zal gaan over de verschillende valkuilen binnen het aansturen van een software-ontwikkeltraject. Lees deze hier.

1 reactie

voeg een reactie toe

Niet alle verplichte velden zijn ingevuld

*

*