Is dit nieuw?

Is de Black Box Dialog methode nu als oude wijn in nieuwe zakken of hebben we hier iets echt nieuws te pakken?

Ik denk een beetje van beide.

 

De Black Box Dialog Methode onderscheidt zich van alle andere ontwikkelmethoden doordat zij de statisch beschrijvende functionele requirements volledig geschrapt heeft.

Bij de Black Box Dialog Methode zal niet van klanten worden verwacht dat zij abstract geformuleerde requirements als “het systeem moet ‘zus of zo’ kunnen” gaan vertalen naar hun proceskennis. Want dat mag je niet van ze verwachten. Hun kracht is hun concrete proceskennis. Daar moet je bij aansluiten.

De Black Box Dialog Methode communiceert enkel in procestermen en dat maakt dat veel sneller een applicatie gebouwd kan worden waar de klant echt wat aan heeft. Op een heel natuurlijke manier wordt de klant bij het ontwikkelproces betrokken.

En dat is echt nieuw in de software-industrie.

 

Wat niet echt nieuw is zijn de Black Box Dialogs zelf. Als je kijkt naar Use Case beschrijvingen zoals deze nu worden gemaakt, dan zie je veel overeenkomstige elementen.

In de huidige Use Case beschrijvingen worden Basic Flows, Alternative Flows en Error Flows beschreven.

Dat zit heel dicht in de buurt van Black Box Dialogs.

En dat is nu juist de kracht.

Met de Black Box Dialog Methode gaan we niet alles opnieuw doen.

De Black Box Dialog Methode snijdt alleen weg wat het software ontwikkelproces onnodig gecompliceerd maakt!
We behouden het grootste deel van het ontwikkelproces dat prima functioneert.

Een mooie en transparante manier van werken blijft over.

 

In het bovenste deel van deze figuur staan de stappen beschreven die we momenteel (moeten) doen als we software bouwen. Bij het BPM (Business Process Management) denkt men in processen en bekijkt hoe een deel van het proces geautomatiseerd kan worden. Van proces flow beschrijvingen maken we dan een onlogische stap naar een statische beschrijving van wat het IT systeem moet kunnen.

Deze abstracte en academische tussenstap wordt vervolgens in de Use Case beschrijvingen weer concreet gemaakt in procesflow beschrijvingen.

Dit is momenteel de hoofdreden waarom de software industrie moeite heeft om aan te sluiten bij de business belangen. Door deze Achilleshiel kan zij niet beantwoorden aan de dringende wens snel (nieuwe) software te implementeren en te kunnen gebruiken.

Schrappen dus die statisch beschrijvende functionele requirements!