Van concept naar x

Hoewel bedrijven al een tijdje naar model-driven development (MDD) kijken, heeft de aanpak nog niet echt erkenning gekregen als meest effectieve manier om een ontwerpproces te sturen. Bill Chown van Mentor Graphics beschrijft de stappen die hij onderscheidt in een succesvolle toepassing van MDD.

Bill Chown is productmarketingdirecteur bij Mentor Graphics. Tijdens de Model-Driven Development Day op 29 april gaat hij uitgebreider in op zijn tien stappen naar modelgebaseerde ontwikkeling.

5 april 2011

Stap 1: het concept opzetten

Het ontwerpproces begint met een briljante inval. Meestal is het idee echter onvolledig en moet het nog uitkristalliseren, waardoor we er niet onmiddellijk mee aan de slag kunnen. Hoe kunnen we dat idee verfijnen, de scherpe kantjes eraf slijpen en komen tot iets dat anderen waarderen en graag willen kopen?

Eerst moeten we duidelijkheid scheppen en de requirements definiëren, maar niet voordat we hebben gedefinieerd wat een ’requirement‘ precies is. Als we de requirements eenmaal kunnen beschrijven, kunnen we ze doorgeven aan het alsmaar groeiende team dat nodig is om de producten van vandaag te implementeren. Het is hun interpretatie van de requirements die de uiteindelijke vorm van het eindproduct bepaalt.

Stap 2: de requirements inzichtelijk maken

Wat moeten we nu verstaan onder de interpretatie van requirements? Hoe kunnen we er zeker van zijn dat een softwareteam ze op dezelfde manier opvat als de hardwarejongens, de architecten en zelfs de oorspronkelijke bedenker van het idee? Door ze inzichtelijk te maken.

We moeten laten zien wat we werkelijk bedoelen met de requirements en wat we ermee willen bereiken. We moeten hun werking tonen. Een goede manier om dat te doen, is door ze direct aan het begin van het ontwerpproces te gieten in een actieve vorm die we kunnen beoordelen en aanpassen.

De mogelijkheid om requirements aanschouwelijk te kunnen maken, is een onmisbaar onderdeel van elke succesvolle MDD-flow. Een dergelijk hulpmiddel moet van meet af aan beschikbaar zijn en de betrokkenen bij het ontwerp moeten er de vragen mee kunnen stellen die ze moeten stellen. Vervolgens moet het betekenisvolle antwoorden opleveren, met eenzelfde hoge niveau van detail als de ontwerpfase waarin we op dat moment zitten.

Stap 3: een uitvoerbare specificatie maken

We hebben het vaak over een uitvoerbare specificatie als middel om de kloof te overbruggen tussen tekstuele, gebruikergeoriënteerde behoeftes en een concrete en opleverbare designspecificatie waar we ook in de praktijk wat aan hebben. Een uitvoerbare specificatie die bruikbaar is om onze doelen te bereiken, is echter niet zomaar gemaakt. Daar zijn doorgaans meerdere stappen voor nodig.

Een uitvoerbare specificatie moet voldoen aan twee belangrijke eisen: we moeten ermee kunnen laten zien waar we aan werken en we moeten er onze initiële vragen mee kunnen beantwoorden. Een goede uitvoerbare specificatie laat ook toe om veranderingen aan te brengen in het concept, het vroege ontwerp of de significante features van het uiteindelijke product. Om te komen tot een succesvol design en een effectief ontwerpproces dat we elke keer weer kunnen gebruiken op weg naar de implementatie, is het belangrijk dat we de specificatie goed begrijpen.

Stap 4: het systeem partitioneren

Functionaliteit toekennen aan een implementatiepad doen we vaak heel vroeg in het ontwerpproces, op een moment dat we nog onvoldoende informatie hebben om geïnformeerde beslissingen te kunnen nemen. En als we eenmaal keuzes hebben gemaakt, hebben we de neiging om daaraan vast te houden en niet meer naar alternatieven te kijken. Inzichten die we in een later stadium opdoen, zijn vrijwel onmogelijk nog mee te nemen, zodat het architectuurontwerp veel te vroeg vastligt.

Met name weten we niet genoeg om de optimale opdeling in componenten te kunnen maken. Om ons hierbij te helpen en een meer effectieve en flexibele flow te bewerkstelligen, is het essentieel dat we meer informatie hebben. Daarbij is het cruciaal dat we een proces hanteren dat veranderingen toelaat.

Het gebruik van modellen, de essentie van MDD en eigenlijk ook van de meeste van onze huidige processen, kan hier het verschil maken. Modellen stellen ons in staat de voorgestelde opdeling uit te proberen en vervolgvragen te stellen.

Stap 5: een functioneel virtueel platform maken

Die vervolgvragen hebben betrekking op de algehele functionaliteit en het algehele gedrag van het systeem, op een hoog abstractieniveau. Om te bepalen of we de volledige verzameling van vereiste ontwerpelementen bij elkaar hebben en om te zien of deze met elkaar samenwerken zoals verwacht, is het verstandig om een virtueel platform te gebruiken. In deze fase van het proces hoeft dit platform nog geen timingconstraints of andere details te bevatten. Wel moeten we het snel kunnen uitvoeren om alle functionaliteit in de praktijk te kunnen uitproberen. Een dergelijk virtueel platform is van groot belang om op de mijlpalen in het ontwerpproces de consistentie tussen de systeemdelen in de gaten te kunnen houden.

Een effectieve uitvoerbare specificatie ondersteunt de hele ontwikkelflow. Het virtuele platform maakt controlepunten en iteraties mogelijk terwijl het ontwerp evolueert, waarna we er in het virtuele systeemprototype interacties met de echte wereld en bijbehorende implementaties aan koppelen. Tests kunnen we door het hele proces hergebruiken, met extra detail wanneer dat nodig is, om de consistentie te waarborgen met de oorspronkelijke behoeftes.

Stap 6: een virtueel systeemprototype maken

Functioneel gedrag is slechts een deel van de ontwerpdoelen. Ook de performance, het energieverbruik, de interacties met de echte wereld en de algehele mogelijkheden van het systeem moeten we beoordelen. Dat kan vaak pas als het eerste fysieke prototype klaar is, maar dat is verre van ideaal. Met een virtueel systeemprototype kunnen we het hardwareplatform, de software die daarop draait om het systeemgedrag te realiseren en de externe actuatoren, sensoren en overige interfaces met de echte wereld samen in actie zien. Op dit moment in het proces kunnen we voldoende detail toevoegen om bijvoorbeeld knelpunten in de performance te kunnen vinden, het energieverbruik onder verschillende omstandigheden te kunnen bepalen of om de testgrenzen vast te stellen van constraints waarvan we weten dat ze een beperking zullen vormen in het echte systeem.

Stap 7: itereren

De eerste architectuur zal zeker niet de beste zijn. Inzichten opgedaan in een later stadium, nieuwe afgeleide requirements en een steeds veranderende marktvraag vereisen allemaal een flexibel proces. Om goed te kunnen itereren, moet het MDD-proces voor een echte verbetering zorgen in de hoeveelheid informatie die op ieder moment beschikbaar is en significant meer inzicht bieden in de gevolgen van een verandering. Cruciaal voor de flexibiliteit in het proces is dat we de specificatie van het verwachte ontwerpgedrag kunnen uitvoeren of simuleren.

Stap 8: implementeren

Er bestaan een heleboel mogelijke implementatietechnologieën en gedetailleerde flows. Het gaat te ver om deze in dit artikel te behandelen. Ook daar vinden modellen echter volop toepassing – in ontwerp, simulatie en verificatie – en allemaal kunnen ze bijdragen aan de algehele MDD-flow, mits op de juiste manier toegepast.

Stap 9: testen

Testen is maar al te vaak het stiefkindje in het ontwerpproces. Zodra het eerste product klaar is, gaat de druk op de ketel bij de testafdeling: hoe doet het systeem het? Werkt het überhaupt? Wat is de performance? Hoe testers dat kunnen weten als het de eerste keer is dat ze het ding zien? Het antwoord luidt weer: modellen.

Modellen, zelfs als ze beperkt zijn tot de belangrijke punten van de eerste requirements, kunnen het testteam aanzienlijk helpen om vroeg aan de slag te gaan en voorbereid te zijn op de komst van het product. Modellen bieden inzicht in wat testers moeten kunnen meten, zodat ze de bijbehorende tests al klaar kunnen hebben. De praktijk heeft uitgewezen dat alleen deze stap het productieschema al met enkele maanden kan inkorten.

Dit is ook het moment dat we controleren of de eerder gestelde grenzen nog steeds kloppen, dat we in meer detail kijken naar de timing en de performance en dat we het resultaat finetunen, indien mogelijk. Het is niet het moment om functionele problemen te gaan zoeken. We zitten al veel te ver in het proces om ons de benodigde wijzigingen te kunnen veroorloven.

Stap 10: volgen

De requirements die vroeger op de plank bleven liggen en slechts een ondergeschikte rol speelden in de ontwikkeling van het eindproduct zijn nu de hele rit bij ons en nemen actief deel aan ons hele MDD-proces. Door ze bij elke stap op te nemen als dynamische onderdelen van het ontwerp kunnen we de oorspronkelijke doelstellingen, veranderende behoeftes en onze reactie daarop bijhouden in designfeatures en de manier waarop we de mogelijkheden van het systeem verifiëren en testen.

Extra stap: documenteren

Nu zijn we klaar om het product in de markt te zetten. Of toch niet? Hebben we gemaakt wat we wilden maken en kunnen we dat ook laten zien aan alle afnemers/consumenten? En belangrijker nog voor een ontwikkelproces: is het herhaalbaar? Op een betere manier misschien? Weten wat er vooraf is gegaan, is een belangrijke voorwaarde om iets nog een keer te kunnen doen, om iets beter te kunnen doen en om verder te kunnen bouwen aan marktleidende functionaliteit. Alle activiteiten in het gevolgde MDD-proces documenteren is daarom een essentieel onderdeel van dat proces en leidt tot het vermogen om voortdurend te verbeteren en te innoveren.

MDD is niet alleen een goed idee, het helpt ook echt om de productiviteit in het ontwerpproces op te krikken. Het maakt het mogelijk om modellen over de hele flow te gebruiken en daarbij automatisch delen van het design te genereren en zo de kwaliteit van het ontwerp te verhogen door herhaalbaarheid en conformiteit met standaarden te introduceren. Met MDD hoeven we geen fysieke prototypes meer te maken. In plaats daarvan simuleren we hoe de analoge en digitale elementen samenwerken met elkaar en met de besturingssoftware van het systeem. MDD kan ook de papierstroom elimineren of in ieder geval danig verminderen. Bovendien omvat een productief modelgebaseerd proces de middelen en mogelijkheden die het makkelijker maken om kritieke problemen vroeg in de ontwikkelcyclus aan het licht te brengen, ruim vóór de systeemintegratie.

MDD zorgt voor een structuur om complexiteit beheersbaar te houden. Tegelijkertijd biedt het de mogelijkheid om de functionaliteit van het ontwerp in iedere fase direct terug te koppelen naar de oorspronkelijke requirements en functionele specificaties. Met een virtuele infrastructuur voor prototyping, waarin modellen uit verschillende domeinen zijn te integreren in ieder stadium van de designcyclus, kunnen we systeemintegratie-issues vroegtijdig identificeren en aanpakken. Bovendien kunnen we verificatiestappen naar voren halen door tools toe te passen die requirements modelleren en door functionaliteit op te nemen in het design.