De mate van zekerheid over de verwachte functionaliteit van software is bepalend voor de te hanteren systeemontwikkelmethode. Hoe kunnen organisaties hiervan slimmer gebruik maken?
In mijn praktijk als BI-consultant speelt ontwikkeling van oplossingen een grote rol. De ontwikkeling van een datawarehouse voor bedrijfsrapportage is een aparte bezigheid. Na een analyse van de informatiebehoefte is duidelijk welke databases naar het datawarehouse ontsloten moeten worden, dit is zeker. De meest moderne BI-architecten zullen kiezen voor eenzelfde soort datamodel, en dezelfde aanpak voor het correct vullen van het datawarehouse, ook dit is zeker. Vervolgens kan het datawarehouse voor een groot deel worden geconfigureerd of zelfs gegenereerd, zoveel zekerheid is er over dit deel van een project.
Maar daarna houdt de grote zekerheid op. Hoe zijn gegevens uit verschillende bronnen te combineren? Welke gegevens op welk rapport? Hoe zullen de rapporten eruit zien? Daarmee zit het venijn in de staart van deze projecten. Eerst een dure database bouwen en dan onzeker zijn over het eindresultaat, hoe gaan we daarmee om?
In de jaren tachtig gebruikten we al prototyping als mogelijke aanpak om meer zekerheid over de specificaties van software te krijgen. In korte tijd en met veel gebruikersinteractie worden de eerste versies van de software ontwikkeld of geëvolueerd. De gebruiker is betrokken, ziet resultaat, kan zijn mening bijstellen en kan resultaten misschien zelfs al gebruiken. Ontwikkelaars krijgen sneller zekerheid over de specs, dragen bij aan succes en besparen onnodige kosten voor rework en hertesten. Er zijn solide methoden voor prototyping voorhanden, bijvoorbeeld Scrum. Allemaal prima!
Dus, waarom wordt prototyping niet vaker toegepast? De belangrijkste reden heeft te maken met de huidige conventionele manier van software-ontwikkeling binnen grote organisaties. Men is door alle vastgelegde checkpoints en procedures niet in staat om iets op te leveren dat als nog niet-af beschouwd moet worden of als niet betrouwbaar kan worden gezien. Analisten durven geen conceptspecs op te leveren, ontwikkelaars moeten hun software laten testen vóór gebruikersevaluatie. Rigide organisaties voor systeemontwikkeling staan geen onzekere tussenresultaten toe, waardoor snelle prototyping geen kans krijgt. Daarmee missen deze organisaties een kans om sneller, goedkoper en betere software op te leveren.
Ik kijk uit naar reacties, met name voorbeelden van grotere ict-organisaties die wél in staat zijn om structureel aan prototyping te doen.
Deze bijdrage kwam tot stand in samenwerking met de collega's Niek Verdoes en Frans Burger.
Robert Mansour
Simpel Robert:
Alles moet gisteren af, werken in een keer, zonder fouten.
Er is gewoon geen tijd en geen geld voor dit soort structurele zaken te implementeren binnen een – alleen maar op maximale winst beluste – onderneming, is mijn vermoeden.
Ik ben het helemaal met je eens Robert. Maar ‘men’ wil graag in control zijn en daar hoort prototyping niet bij. Er mag wel prototyping gedaan worden in de ontwikkel omgeving maar daar mag dan weer alleen een ontwikkelaar bij. Een oplossing is ook om het door het projectteam in productie te laten nemen en de acceptatie proces daar te laten verlopen met een snelle oplever/change cyclus. Na een bepaalde periode kan het overgedragen worden naar beheer.
Veel volwassen klanten plannen zelf een Proof of Concept in, om er ook zelf zeker van te zijn dat er geen kapitaalvernietiging gaat worden gepleegd.