• Portretfoto van Ralph Jacobs
    Ralph Jacobs

Achter de schermen deel 3: De modelleringsfase van een software project.

Welkom bij deel 3 van deze blogreeks. In deze reeks nemen we je mee achter de schermen van Four Digits, zodat je kunt zien hoe wij een software ontwikkeltraject van oriëntatie tot oplevering en evaluatie aanpakken. Waar we bij deel 1 & deel 2 ingezoomd hebben op de oriëntatiefase, gaan we ons in dit deel specifiek richten op de modelleringsfase van een softwaretraject. Deze fase begint nadat het acceptatiedocument, met daarin het functioneel ontwerp en het afsprakendocument, goedgekeurd is.

Het belang van modelleren

Nadat het functioneel ontwerpdocument goedgekeurd is, kunnen we overgaan tot het modelleren van de software. Door een visuele representatie van de software te creëren kunnen we het makkelijker begrijpen en beheren. Dit wireframe is in feite een visuele blauwdruk die de structuur en lay-out van de uiteindelijke software laat zien.

Door eerst een wireframe op te stellen kunnen we potentiële fouten en risico’s in een vroeg stadium identificeren en elimineren. Het laat de interacties tussen verschillende onderdelen van de software zien en toont de plaatsing van elementen zoals knoppen, menu’s en andere elementen. Laten we het modelleringsproces eens aan de hand van onze voorbeeldcasus HVHL bekijken:

HVHL wilde hun oorspronkelijke website in een nieuwe jas steken. Coen vertelt:
Waar we mee begonnen zijn is goed te kijken naar wat er op dit moment staat. We zijn op gesprek gegaan en hebben op een groot bord uitgetekend welke functionaliteiten er in de huidige website zitten. Iedere pagina is opgebouwd uit een aantal blokken. Maar wij vragen vervolgens welke blokken echt belangrijk zijn voor onze klant om te kunnen uiten wat ze willen uiten. Op basis van de antwoorden beginnen we met het ontwerpen van het wireframe.”

De beste oplossing binnen een beperkt budget

Vaak werken we met een vastgesteld budget. Om hier niet overheen te gaan, is het van belang om de meeste essentiële elementen in het wireframe te verwerken. Coen vertelt over de HVHL casus:

“Mensen worden enthousiast als we iets moois laten zien en bespreken. Maar voor ons, om te voldoen aan de opdracht, moeten we keuzes maken. Dus welke blokken zijn voor fase 1 het belangrijkst? En welke blokken kunnen op een later tijdstip nog toegevoegd worden? Ik probeer de scope van de website altijd zo klein mogelijk te maken, zodat je daarna misschien nog ruimte hebt om iets extra’s op te leveren.”

Door de focus op de meest essentiële elementen te leggen voorkomen we budgetoverschrijding. En tegelijkertijd zorgen we ervoor dat de basis alle benodigde functionaliteiten bevat. Het is een proces van geven en nemen, met het uiteindelijke doel om de beste software op te leveren binnen het afgesproken budget en tijdsbestek.

Het bepalen van de software architectuur

Een belangrijk onderdeel van de modelleringsfase is het bepalen van de software architectuur. Iedere opdracht vraagt om een andere aanpak. Zowel op het gebied van planning en communicatie, als op het gebied van architectuur. De architectuur van de te ontwikkelen software is vergelijkbaar met de blauwdruk van een huis. Het omvat alle onderdelen van de software en hoe deze met elkaar communiceren. En het bevat het fundament van de software, de taal of tool waarmee het ontwikkeld wordt.

Bij Four Digits leveren we vooral software die draait in een browser. Als het gaat om webapplicaties gebruiken we vaak Django als fundament. In het geval van CMS systemen gebruiken we Wagtail. Zowel Wagtail als Django zijn ontwikkeld op basis van de programmeertaal Python, waar we bij Four Digits in gespecialiseerd zijn. Siemen vertelt:

Python is een hele flexibele taal, waardoor we veel onderdelen kunnen integreren. We kunnen hierdoor gemakkelijk standaard websites overstijgen en specifieke features maken. Puur omdat Python dat toe laat.”

Bij het bepalen van de architectuur gebruiken we het KISS (keep it simple, stupid) principe. We vragen ons altijd af met welke techniek we verschillende onderdelen kunnen creëren. Daarbij geldt dat de meest simpele oplossing vaak de beste is. Siemen vertelt:

Als je een bestelformulier hebt waarbij je een keuze maakt waarvan de volgende keuze dan weer afhankelijk is, dan wordt dat veel sneller interactief en geeft dat reden om het anders aan te pakken dan een simpel contactformulier.”

In dit geval zouden we bijvoorbeeld kunnen kiezen voor een applicatie op basis van React, omdat dit heel interactief werkt. Maar het toepassen van React voor een simpel contactformulier is niet alleen overbodig, maar ook kostbaar. Omdat je als klant meer betaalt voor hetzelfde resultaat.

“Als een klant toch onnodige technologieën wil dan gaat de development tijd omhoog. Hoe moeilijker je dingen maakt, hoe meer code je schrijft. Maar het verhoogt ook het risico op fouten. En het onderhoud wordt tegelijkertijd ook complexer en duurder.” - Siemen

De levensduur en stabiliteit van de architectuur

Bij iedere opdracht kijken we naar de levensduur en de stabiliteit van de software. Sommige klanten verwachten software dat over 10 jaar nog goed presteert. Andere klanten hebben een website nodig voor een eenmalig event en verwachten vooral hippe designs en moderne features. De wensen van de klant hebben invloed op de architectuur van de software, waarbij wij altijd kijken wat er echt nodig is om aan de wensen te voldoen. Zonder technologische overdaad toe te passen. Want dit leidt tot hogere kosten en onnodige risico’s.

Bij Four Digits kiezen we vrijwel altijd voor de lange termijn strategie, tenzij de klant anders aangeeft. Door te kiezen voor Long Term Support (LTS) versies van software onderdelen garanderen we dat de software die we opleveren actief onderhouden wordt. Maar het biedt volgens Siemen nog meer voordelen:

“Door LTS versies toe te passen kunnen we ook aangeven hoe lang het duurt voordat je webapplicatie of CMS opnieuw ontwikkeld moet worden, of een update nodig heeft. Het blijft altijd een schatting, maar een schatting is beter dan niets.”

Bij ieder project vragen we ons in de oriëntatiefase af hoe we onze software toekomstbestendig kunnen maken. Want wij vinden dat onze software over 5 tot 10 jaar nog steeds moet doen waar het voor gemaakt is.

Op naar de ontwikkelingsfase

In deze blog hebben we je kennis laten maken met de modelleringsfase van het complete traject. Deze fase is essentieel om de uiteindelijke ontwikkeling in goede banen te leiden. Met het bepalen van de architectuur en het wireframe wordt al vastgelegd hoe de software eruit komt te zien. Dit geeft ons alle informatie die we nodig hebben om te starten met de ontwikkeling, terwijl het onze klanten precies laat zien wat we gaan opleveren.

Bij Four Digits hechten we enorm veel waarde aan de oriëntatiefase en modelleringsfase. In de oriëntatiefase willen we de onderliggende problematiek van de hulpvraag precies helder krijgen. Als dit helder en goedgekeurd is, start de modelleringsfase. Hierin maken we via een wireframe overzichtelijk wat we in de oriëntatiefase hebben afgesproken. Pas als deze goedgekeurd is beginnen we met de daadwerkelijke ontwikkeling.

Wil je meer weten over de oriëntatiefase van het ontwikkeltraject? Lees onze blog hier.

We love code