De voorbereiding voor software ontwikkeling

Cliché maar heel toepasselijk, "een goede voorbereiding is het halve werk". Een goede voorbereiding doe je door vooraf goed na te denken over het eindresultaat van je applicatie. Mindmaps, wireframes en functionele plannen behoren allemaal tot een goede voorbereiding.

Een spoedige start en slechte afloop

De ontwikkeling van je nieuwe software begint voorspoedig. Via een offerte is de software kort beschreven en zijn de voorwaarden en de prijs bepaald. Je hebt het gevoel dat de ontwikkelaar van de software op één lijn zit met jou. Je voelt een positieve spanning en bent benieuwd naar het resultaat. De eerste tussentijdse oplevering van de software valt niet tegen. Ook de tweede tussentijdse oplevering ziet er veel belovend uit. De software wordt na elke oplevering steeds complexer. Je blijft geboeid en nieuwsgierig naar het verloop van de ontwikkeling van de software. Toch merk je na enkele volgende opleveringen dat de software niet helemaal meer aan jouw wensen voldoet.

Dan blijft het ineens vanuit de ontwikkelaar stil. Je wacht vijf weken en daarna nog twee weken. Je besluit een e-mail te sturen met daarin de vraag of er nog nieuwe ontwikkelingen zijn. Het duurt een week voordat je reactie krijgt. De reactie in de e-mail is niet helemaal duidelijk. De reactie komt zelfs vaag over. Je verzoekt de software ontwikkelaar om een nieuwe tussentijdse oplevering. Op verzoek stuurt de ontwikkelaar een nieuwe versie van de software met het bericht dat de software het einde van het ontwikkeltraject nadert.

Je bekijkt het resultaat en merkt op dat de software niet is geworden wat je ervan had verwacht. Je bent teleurgesteld en je neemt contact op met de ontwikkelaar om te overleggen. De software moet grondig aangepast worden. De ontwikkelaar is bereid om de software aan te passen maar dan wel tegen een nieuwe financiële investering. De ontwikkelaar heeft ook veel meer extra tijd nodig want intussen heeft de ontwikkelaar meerdere opdrachten onderhanden. Dit is niet wat je verwacht had, de ontwikkeling begon allemaal zo voorspoedig. Je zit met de handen in het haar. Wat nu? Had je dit kunnen voorkomen?

Werkwijze voor geluksvogels

Toen ik 20 jaar geleden begon met de ontwikkeling van software had ik geen benul van het belang van een goede voorbereiding. Wanneer ik een idee had voor een applicatie, dan startte ik de computer op, opende ik mijn ontwikkelomgeving en begon ik met het schrijven van de applicatie. Tijdens de ontwikkeling kreeg de applicatie vorm en evalueerde ik het resultaat. Een hele leuke manier van werken, maar niet altijd efficiënt.

Deze methode van ontwikkeling hanteerde ik destijds ook voor klanten. Met klanten voerde ik eerst een oriënterend gesprek, waarna ik, zonder grafisch overzicht, aan de slag ging met de ontwikkeling. Alles wat ik ontwikkelde was uitgedacht in mijn hoofd. Tijdens de ontwikkeling werd de klant gevraagd om feedback. De feedback werd vervolgens verwerkt in de software.

Deze manier van werken is een Agile methode, maar dan zonder gedegen voorbereiding. De klant heeft vooraf geen idee wat hij krijgt totdat er een werkend (tussentijds) resultaat is. Deze manier van werken is tijdrovend en geeft veel dubbele werkzaamheden wanneer de klant andere ideeën heeft. Tevens worden er geen doelen gesteld en is het eindresultaat niet precies duidelijk. Ik mag van geluk spreken dat mijn werkwijze en opgeleverde resultaten destijds niet tot grote discussies hebben geleid. Eigenlijk ben ik een geluksvogel geweest.

Goede voorbereiding

Door schade en schande werd ik wijs en leerde ik dat het ontwikkelen van software niet alleen maar schrijven van code is. Voornamelijk een goede voorbereiding zorgt voor het behalen van de gestelde doelen en het beoogde resultaat. Tegenwoordig adviseer ik klanten om een blauwdruk voor software te maken. Een blauwdruk maken is niet altijd eenvoudig maar het is de investering meer dan waard. Een blauwdruk geeft inzage in alle mogelijkheden van de software en verbanden binnen de software. Daarbij wordt de ideale situatie geschetst waaruit een aantal kerndoelen gehaald worden, zodat de software doet wat het moet doen. De ideale situatie geeft ook handvatten voor toekomstige uitbreidingen en implementaties.

Mindmaps

Eén van de meest efficiënte methodes om een goede blauwdruk van de software te maken, is een zogenoemde mindmap. Een mindmap is een diagram opgebouwd uit begrippen, teksten, relaties en/of afbeeldingen, die zijn geordend in de vorm van een boomstructuur rondom een centraal thema. Een mindmap kan statisch zijn en wordt dan gemaakt op papier. Een statische mindmap kan nadelig zijn wanneer de mindmap groter en complexer wordt. Dan bieden dynamische mindmaps een oplossing. Een dynamische mindmap maak je door middel van mindmap-software voor de computer.

Wij gebruiken mindmaps voornamelijk voor brainstormsessies en een schematische weergave van de software. Een mindmap kun je, bijvoorbeeld toepassen op brainstormsessies, ontwerpen, organiseren, samenvatten, notuleren, presenteren en leren. Je kunt er voor kiezen om één grote mindmap te maken of om verschillende kleinere mindmaps uit te werken om gefaseerd de software te ontwikkelen.

Wireframes

Om de interface van de software schematisch te ontwerpen, worden wireframes gebruikt. Het maken van wireframes passen wij voornamelijk toe op mobiele applicaties, webapplicaties en geavanceerde websites. Omdat de focus van een wireframe ligt op functionaliteit, gedrag en inhoud, bevat een wireframe normaal gesproken geen typografische stijl, kleur of afbeeldingen. Een wireframe kan statisch worden geschetst op papier of whiteboard, maar net zoals bij mindmaps biedt een dynamische aanpak meer mogelijkheden. Nadat de wireframes klaar zijn, kan een grafisch ontwerp worden gemaakt.

Functioneel plan

Nadat een mindmap is uitgedacht en uitgewerkt, kan (een deel van) de mindmap vertaald worden naar een functioneel plan. In het functioneel plan wordt omschreven wat de software precies moet doen en wat er gebeurt wanneer gebruikers de software toepassen. Een functioneel plan moet op zo'n manier geschreven worden dat zowel de (niet-technische) klant als de ontwikkelaar het plan begrijpen. Een goed functioneel plan omschrijft het technisch ontwerp en sluit aan op het grafisch ontwerp.

Meer methodes ter voorbereiding

Naast bovengenoemde methodes om goede voorbereidingen te treffen, zijn er meer methodes beschikbaar. Je kunt ook flowcharts, UML diagrammen, data flow diagrammen en dergelijke toepassen. Per project is het verstandig om na te gaan wat je eigen wensen of de wensen van de klant zijn en welke methode het beste past bij deze wensen.

Hoe realiseer je bijzonder software?

Eerder schreef ik al een artikel over hoe realiseer je bijzondere software. Daarin vertelde ik over het ontwikkelen van goede software.

Wil je hulp bij de voorbereiding van jouw software?

Heb je hulp nodig bij de voorbereiden van de ontwikkeling van jouw software? Neem dan contact met ons op voor een vrijblijvende afspraak. Ik denk graag met je mee en help je met een goede voorbereiding en het maken van de juiste keuzes. Een goede voorbereiding is immers het halve werk.

---

---

Gearchiveerd in de categorie: inspiratie

Voorzien van de labels: responsive, mobiel, tablet, smartphone, websites, ios, android