Dit is het vijfde artikel in een reeks over het tot stand komen van een maatwerk-website. Een introductie, de analysefase en ontwerpfase , en het functioneel ontwerp werden reeds eerder besproken. In dit artikel wordt ingegaan op wat er zoal in een technisch ontwerp vastgelegd wordt.

Het proces zoals we dit behandelen in deze reeks is als volgt gefaseerd:

• Analysefase
• Ontwerpfase
  • Functioneel Ontwerp
  • Technisch Ontwerp
  • Grafisch Ontwerp
• Bouwfase
• Kwaliteitfase
• Acceptatiefase
• Lanceerfase

Zoals eerder in de reeks besproken staat in het functioneel ontwerp wat de te bouwen applicatie of website aan functionaliteit moet bieden zodanig omschreven dat een klant het document ook goed kan begrijpen. Voor het uitwerken van enkele onderdelen kan het nodig  zijn dat een architect of developer aanvullend onderzoek moet doen. Dit is vaak nodig bij complexe onderdelen binnen een site die zeer specialistische kennis behoeven. Deze uitgewerkte onderzoeken worden vastgelegd in een technisch ontwerp. Hierin staat HOE bepaalde onderdelen technisch gerealiseerd gaan worden. Een technisch ontwerp wordt geschreven door een zeer ervaren developer of architect en is een document dat voor en door developers (en eventueel techneuten bij de opdrachtgever/klant) wordt gemaakt.  Nadeel: het is helaas vaak onbegrijpelijk voor de klant, dus is er minder begrip voor de kosten die hiermee gemoeid zijn., echter…:

Ontwerp is essentieel

Toch worden hier juist de belangrijke beslissingen genomen als het gaat over de essentiële onderdelen van een website of webapplicatie.  Je beslist hier immers over de fundering van de site , en zoals bekend, deze kan maar beter goed in orde zijn. (Hier falen veel ict-projecten jammergenoeg).  Afhankelijk van het project zal de behoefte aan technisch ontwerp voor de te bouwen onderdelen erg verschillen. Vaak moet een website worden gebouwd en gekoppeld in zijn eigen unieke omgeving, en het is daarom lastig om eenduidig te omschrijven welke onderdelen er in een technisch ontwerp moeten komen. Onderstaande geef ik een aantal voorbeelden waar gedacht kan worden: 

Inhoud technisch ontwerp

De volgende zaken kunnen worden uitgewerkt in een technisch ontwerp (en is zeker niet uitputtend) 

• Architectuur van de site (Hoe richt je de code van de applicatie in?)
• Performance (hoe garandeer je de performance van de site bij grote bezoekersaantallen)
• Caching (hoe is de caching van pagina’s of onderdelen in de site geregeld)
• Databaseontwerp  (welke data moet er opgeslagen en hoe is deze aan elkaar gerelateerd)
• Datamodellen van entiteiten binnen de site (Welke velden heeft een user in de site of een bestelling)
• Imports  (mapping van velden vanuit de de te importeren content naar de database)
• Beveiligingsmodel (welke rollen en rechten, wie mag waarbij)
• Koppeling met een andere applicatie ( bv een CRM of SAP )
• Zoekfunctionaliteit (welke zoekmachine wordt er gebruikt, hoe wordt er geïndexeerd)

Ook voor deze voorbeeldlijst geld: het kan zijn dat niet elk onderdeel benodigd is binnen je eigen project of website.

Investeer en bespaar geld

Gebruik bovenstaande dan wederom als een checklist om jezelf ervan te vergewissen dat je in de loop van het project niet met deze zaken te maken krijgt.  Zijn ze echter wel nodig, investeer dan in deze documentatie. Je moet deze zaken vooraf tackelen om grote kostenposten in het project later te voorkomen. Onthoud, deze zaken staan aan de basis van de site, dus als je hier iets in moet gaan veranderen tijdens of na het project, houd dan rekening met een grotere kostenpost!

Lange termijn

Daarnaast, denk je eens in dat de applicatie nog een keer gebouwd moet worden in een andere techniek. Dan is het wel zo prettig als je bouwdocumentatie hebt van de huidige applicatie (waar je in al die jaren tijd dat de site live heeft gestaan ongetwijfeld veel tegenaan hebt gebouwd).Vooraf nadenken levert net zoals bij het functioneel ontwerp ook hier wederom vele voordelen: onderhoudbaarheid van de applicatie, kwaliteit van de code,  kosten van wijzigingen vallen lager uit, je voorkomt performance problemen en tal van andere issues waar je anders mee te maken kan krijgen. Doe er dus je voordeel mee. Samengevat:  in het FO staat WAT je bouwt, in het TO voor de lastige onderdelen HOE je het bouwt. Volgende week: hoe komt het eruit te zien: het grafisch ontwerp.

Stay tuned!

Wellicht ook interessant!

• Websites op maat in het watervalmodel: Analysefase
• Websites op maat in het watervalmodel
• Watervalmodel: Ontwerpfase
• Watervalmodel: Grafisch Ontwerp
• Watervalmodel: Functioneel ontwerp

Bart Lelieveld is werkzaam als Manager Bouw bij Liones, internetbureau voor uitgevers. Als programmamanager overziet hij alle projecten binnen Liones, en is hij verantwoordelijk voor de dagelijkse operatie en het procesmanagement. Daarnaast is hij werkzaam als Senior projectleider en Business Analist.
Bekijk meer berichten van Bart Lelieveld