Bij uitbesteden van softwareontwikkeling dienen eisen en wensen eenduidig te zijn. Dit kan bereikt worden door ze executeerbaar te maken. 'Exploratory modelling' is een techniek die ons daarbij kan helpen.
Uit onderzoek blijkt dat tijdens software ontwikkelprojecten meer dan 50 procent van de eisen die aan het begin van het project gesteld worden, tijdens de uitvoering van het project veranderen (zie onder andere het werk van Larman, C. Applying UML and Patterns). Dat is dus meer dan de helft! Of het nu gaat om maatwerk- of standaardproductontwikkeling, verandering moet daarom in alle onderdelen van de software mogelijk zijn.
In onze praktijk komen we vaak in aanraking met klanten die graag software extern ontwikkeld willen hebben. Wanneer we dan de stelling in ogenschouw nemen dat 50 procent van de eisen die gesteld worden zullen gaan veranderen, dan heb je een aanpak nodig waarin omgegaan kan worden met deze verandering. Natuurlijk zijn er vanuit de agile-benaderingen meerdere technieken beschikbaar om ons, opdrachtgever en opdrachtnemer, hierin te helpen.
Echter, in een situatie waarin de opdrachtgever software extern laat ontwikkelen, wil deze wel graag weten wat het gaat kosten en wanneer het opgeleverd wordt. Wat op zichzelf natuurlijk niet meer dan terecht is. Wanneer de tijd en budget vast staan volgt logischerwijs dat de functionaliteit de variabele wordt. Ook dit is niet bijzonder.
Het interessante komt nu: de opdrachtgever heeft zijn specificaties gedefinieerd. Deze zijn vastgelegd in een of meerdere documenten. Hier gaat het eigenlijk al fout. De opdrachtgever heeft de documenten naar beste weten samengesteld. Ze zijn misschien zelfs al door meerdere mensen doorgenomen en goed bevonden. Wanneer de opdrachtnemer deze documenten doorneemt, zal gelezen worden wat er staat. De grote vraag is of deze ook daadwerkelijk gaat begrijpen waar het betreffende domein over gaat. Zijn alle begrippen eenduidig gedefinieerd? Is duidelijk welke gedragingen verwacht worden van de software in verschillende situaties? Dit zijn punten die het vastleggen, belangrijker nog het overbrengen, van eisen en wensen in documentvorm complex maken. Bij een beetje systeem zien we al gauw dat inconsistenties ontstaan in de eisen en wensen.
Inmiddels hebben we in meerdere van dit soort trajecten met de opdrachtgever om tafel gezeten en besloten de eisen en wensen anders te specificeren. In dit geval zijn we aan de slag gegaan met een techniek die Exploratory Modelling heet. In deze stijl van requirements modelling wordt de businessfunctionaliteit gemodelleerd in een domeinmodel. Dit model kan gewoon traditioneel in UML-diagrammen gepresenteerd worden. Echter wordt het model ook in een 'simulatie'-platform of -framework geïmplementeerd. Een voorbeeld van zo’n framework is Naked Objects.
In dit framework kunnen we een domeinmodel plaatsen. Vervolgens genereert het framework schermen, zodat de gebruiker kan zien wat het systeem doet. Ja, deze schermen zien er vaak niet uit. Ze representeren niet de uiteindelijke visuele weergave van het systeem. Wel kunnen we toetsen of de begrippen die in het domein bestaan op een juiste manier gedefinieerd zijn. In een hypotheekdomein kunnen we bijvoorbeeld vaststellen of we op de juiste manier de berekening uitvoeren. De gebruikers kunnen al gaan 'interacteren' met het systeem.
Het unieke is dat dit proces in enkele dagen doorlopen kan worden. Er vindt dus continue afwisseling plaats tussen het definiëren van eisen en wensen en het toetsen hiervan in de 'simulatie'-omgeving. Hiermee worden in een zeer vroeg stadium inconsistenties in de eisen en wensen aan het licht gebracht.
Nu zou je kunnen denken: leuk, maar wat is dan het verschil met prototyping? Een terechte vraag. Het grote verschil is dat het resultaat niet weggegooid wordt. Het resultaat is een executeerbaar domeinmodel. Daarmee liggen de functionele eisen vast in een executeerbare implementatie. Natuurlijk zullen de niet-functionele eisen nog vastgelegd moeten worden. De kracht is dat de eisen en wensen van de opdrachtgever nu getoetst worden. De opdrachtnemer weet daarmee welke functionaliteiten gerealiseerd moeten worden in het komende incerement of project. Risico’s ten aanzien van veranderende functionaliteit worden vroegtijdiger in het project afgedekt en daarmee wordt de impact verkleind.
Ik had nog niet eerder van deze exploratory aanpak gehoord. Dat klinkt me interessant in de oren. Echter, zoals je zelf al beschrijft aan het eind van je bijdrage, wat is nu het verschil met prototyping. Ja inderdaad, prototyping volgens het boekje, gooit het resultaat weg. Maar in de praktijk wordt heel vaak dat prototype niet weggegooid.
Wat me echter nog niet duidelijk is dat je aan het begin aangeeft dat met name bij een groter project problemen ontstaan met de papieren documentatie en kennisoverdracht. Vervolgens geef je aan het eind aan dat in enkele dagen de domein specificaties worden verkregen. Dat laatste lijkt mij ook een klein project. Bij een serieus project is dat ook een kwestie van vele sessies en langere doorlooptijd. Hoe gaat deze aanpak daar dan mee om? Wat zijn daar je ervaringen?
In principe is het mogelijk nog veel verder te gaan met Exploratory Modeling. De volgende stap is namelijk om zo snel mogelijk de daadwerkelijke software te genereren. Eventueel al tijdens de workshop, of in elk geval zo spoedig mogelijk daarna (dezelfde dag). Dit kan wanneer je de requirements zeer gestandardiseerd modeleert en tijdens de workshop niet steeds de vraag stelt: beste gebruiker, wat kunnen we deze keer voor je betekenen, maar de gebruiker meeneemt langs meer gestandiseerde voorbeelden.
Zelf gebruiken we hiervoor graag smart use cases en genereren nog dezelfde dag tot zo’n 95% van de daadwerkelijke applicatie. Dit levert een hoge productiviteit op, tegen lage kosten. Bovendien kan de gebruiker vrijwel direct feedback geven op de applicatie. Hierdoor schiet de kwaliteit van de software met sprongen vooruit.
Vanuit oogpunt van testen ben ik heel blij hiermee. Executeerbaar maken van eisen is een uitstekend middel om te toetsen of men elkaar goed begrijpt. Eindgebruikers begrijpen veel beter wat er op hun afkomt als ze iets werkends zien.
Al langer pas ik dit toe in mijn eigen omgeving, maar dan handmatig: op basis van eisen voeren we dan ?testen? uit via rollenspelen en simulaties. Dat het nu mogelijk is om dit te ondersteunen met tools is goed nieuws.
Een waarschuwing: hoe meer het model gericht wordt op het realiseren van software die daadwerkelijk in productie kan, hoe ontoegankelijker het vaak wordt voor eindgebruikers. Een goede balans tussen ontwikkelfeatures en begrijpelijkheid is dus wel gewenst.
Ik zou ook graag testgevallen genereren vanuit dit proces.
De modellen kunnen voor het testen gebruikt worden. Model-Based Testing (MBT) biedt de mogelijkheid om vanuit (UML) modellen testgevallen te generen. Geautomatiseerd specificeren van testgevallen op basis van de gestelde modellen. Aan de hand van deze testgevallen is het daarna weer makkelijker de testgevallen geautomatiseerd uit te voeren. Hiervoor is enkel de benodigde fysieke data nodig.
Aan de hand van MBT kunnen ook de requirements (automatisch) worden getoetst. Niet toegankelijke modellen, waaruit geen testgevallen generatie mogelijk is, kunnen onjuist zijn geformuleerd. Modellen bieden de mogelijkheid om zowel te bouwen als te testen!
Exploratory Modeling is goed toepasbaar voor nieuwbouwtrajecten. De time-to-market versnelt hiermee en de ontwikkelkosten zullen sterk reduceren. Ten aanzien van beheer heeft xM nog wel een paar issues. Nadat de applicatie in productie genomen is, is het model niet meer bruikbaar voor onderhoud. Deze is immers overgeheveld naar een ontwikkelplatform waarin de noodzakelijke aanpassingen zijn aangebracht.
Toch verwacht ik dat xM een belangrijke eerst stap is naar het geautomatiseerd software ontwikkelen. Voorwaarde is wel dat de non-functional requirements in het model worden opgenomen en dat de volledige source code van de applicatie vanuit het model wordt gegenereerd.
Bij het ontwikkelen van lichte toepassingen is dit een veelbelovende techniek. Ook voor vaststellen van globale eisen en wensen van complexe toepassingen. Het door Edwin genoemde voorbeeld over het toetsen van hypotheekberekeningen vind ik op het randje. Bij zwaardere toepassingen met complexe berekeningen zoals actuariele berekeningen of uitkeringssystemen met complexe terugwerkende kracht berekeningen past deze aanpak niet. In dat geval kan niet op basis van een nog niet uitontwikkeld model ‘even’ getoetst worden of de berekeningen kloppen. Hier is meer tijd voor nodig en dat doet afbreuk aan deze aanpak. Mooie techniek, maar niet voor alle toepassingen?
Zijn verkeerde requirements juist gespecificeerd of juiste requirements verkeerd gespecificeerd? Zelfs in dit artikel wijzigen de specs van veranderende requirements in bij aanvang niet eenduidig gedefinieerde. Als requirements niet SMART zijn werken klant en leverancier vanaf aanvang langs elkaar heen; een juiste constatering.
Een probleem los je het eenvoudigst op waar dit ontstaat; deels wat je bij deze methode terugziet. Het is ongeveer 8 maal goedkoper om fouten in documenten op te sporen en te verhelpen dan dit in software te moeten doen. Dan zijn namelijk al ontwikkelkosten gemaakt, deels verspild, ook bij deze methode. Efficiency vereist automatisering. Een efficient automatiseringstraject op haar beurt valideert requirements op papier, door review, v??r ze verder gaat.
xM zie ik als een variant van RAD. RAD hulpmiddelen bestaan al meer dan 20 jaar. De lastigheid zit hem in de wisselwerking tussen genereerbaarheid en aanpasbaarheid en daarnaast tussen beheerbaarheid en her-genereerbaarheid. Ik sluit me volledig aan bij Andre dat eenvoudige systemen prima zal lukken, maar het mis gaat bij de business rules. Mijn ervaring is dat gebruiker het niet snappen dat de applicatie het lijkt te doen, maar de business rules nog ontbreken.
Wel staan wij volledig achter het idee van xM om de gebruikers snel te laten zien wat ze krijgen. Wij kiezen ervoor om – in de sessie met de gebruikers – What You See Is What You Get – de schermen samen te tekenen m.b.v. MS Visio. Door een gestandaardiseerd ontwikkeltraject weten we dat deze mockups voor 99% betrouwbaar zijn (high fidelity). Doordat de gebruiker ziet dat het getekend wordt ontstaat er geen enkele verwarring met het idee dat de applicatie al af zou zijn. Voor deze aanpak maken we gebruik van een standaard user interface mockup die zorgt dat alle meest voorkomende schermen al aanwezig zijn.
Vanuit de agile benadering bestaan er ook manieren om ervoor te zorgen dat zowel de opdrachtgever als de gebruiker een oplossing krijgen die zo goed mogelijk aansluit bij hun eisen en wensen. Bij OutSystems zijn we – in veel gevallen nog voor er een aanbieding is – al met de (potenti?le) opdrachtgever(s) in gesprek om te toetsten of onze beschrijving aansluit bij de beleving van de uiteindelijke (key-) users. Op die manier voorkomen we het verschil van inzicht al bij de bron. Met behulp van OutSystems AgileNetwork Projects, onze project management oplossing, kunnen we een project sizen. Deze sizing verwoordt welke functionaliteit er uiteindelijk gewenst is. Het probleem dat geschetst wordt, het vertalen naar de techniek, is er een die wij aan de voorkant van het traject al behandelen. Verder wordt er volgens Agile ontwikkeld waardoor we tijdens de bouw korte iteraties kennen. Zo hebben we steeds een vinger aan de pols en blijft de deviatie t.o.v. de ?ideale (denkbeeldige) lijn? zeer beperkt en goed controleerbaar.