Functionele eisen: maak ze executeerbaar

Bij uitbesteden van softwareontwikkeling dienen eisen en wensen eenduidig te zijn. Dit kan bereikt worden door ze executeerbaar te maken. 'Exploratory modelling' (xM) is een techniek die daarbij kan helpen. Onze experts uit het topic Development aan het woord.

Edwin van Dillen, cto, Sogyo

Ik kom vaak in aanraking met klanten die graag software extern ontwikkeld willen hebben. Natuurlijk zijn er vanuit de agile-benaderingen meerdere technieken beschikbaar die hierin te helpen, maar je wilt wel graag weten wat het gaat kosten en wanneer het opgeleverd wordt. Wanneer tijd en budget vaststaan, volgt logischerwijs dat de functionaliteit de variabele wordt. De opdrachtgever heeft zijn specificaties gedefinieerd. Deze zijn vastgelegd in een of meerdere documenten. Hier gaat het eigenlijk fout. De vraag is of de opdrachtgever ook 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 en overbrengen van eisen en wensen in documentvorm complex maken.

De mogelijkheid is om eisen en wensen anders te specificeren. Deze techniek heet 'exploratory modelling'. In deze stijl van requirements modelling wordt de businessfunctionaliteit gemodelleerd in een domeinmodel. Echter wordt het model ook in een 'simulatie'-platform of -framework geïmplementeerd. In dit framework kunnen we een domeinmodel plaatsen. Vervolgens genereert het framework schermen, zodat de gebruiker kan zien wat het systeem doet. We kunnen toetsen of de begrippen die in het domein bestaan op een juiste manier gedefinieerd zijn. 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.

Sander Hoogendoorn, principal technology officer, Capgemini

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 gestandaardiseerd modelleert en tijdens de workshop niet steeds de vraag stelt wat je deze keer kan betekenen, maar de gebruiker meeneemt langs meer gestandaardiseerde voorbeelden. Zelf gebruik ik hiervoor graag 'smart use cases' en genereer nog dezelfde dag zo'n 95 procent 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.

Gerlof Hoekstra, sr. testconsultant, Atos Origin

Vanuit het 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 hen 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.

Christiaan Heidema, softwarearchitect, Sogeti Nederland

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 is genomen, 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.

Sebastiaan Koreman, sr. consultant, ps_testware

Zijn verkeerde requirements juist gespecificeerd of juiste requirements verkeerd gespecificeerd? Soms wijzigen de specs van veranderende requirements bij aanvang in niet eenduidig gedefinieerde specs. Als requirements niet 'smart' zijn, werken klant en leverancier vanaf aanvang langs elkaar heen. Een probleem los je het eenvoudigst op waar dit ontstaat en dat zie je deels bij deze methode terug. Het is ongeveer acht 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 efficiënt automatiseringstraject op zijn beurt valideert requirements op papier, door review, vóór hij verder gaat.

Alexander Vermeulen, information & system analist, Garansys

xM zie ik als een variant van RAD. RAD-hulpmiddelen bestaan al meer dan twintig jaar. De lastigheid zit hem in de wisselwerking tussen genereerbaarheid en aanpasbaarheid en daarnaast tussen beheerbaarheid en her-genereerbaarheid. Eenvoudige systemen zal dat prima lukken, maar het gaat mis bij de business rules. Mijn ervaring is dat gebruikers het niet snappen dat de applicatie het lijkt te doen, maar de business rules nog ontbreken.

Wel sta ik volledig achter het idee van xM om de gebruikers snel te laten zien wat ze krijgen. Ik kies ervoor om, in de sessie 'what you see is what you get' met de gebruikers, de schermen samen te tekenen met behulp van Microsoft Visio. Door een gestandaardiseerd ontwikkeltraject weten we dat deze mock-ups voor 99 procent 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 maak ik gebruik van een standaard user interface mock-up die zorgt dat alle meest voorkomende schermen al aanwezig zijn.

Ruud Hochstenbach, technical partner manager, OutSystems Benelux

Vanuit de agile-benadering bestaan er 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. Ik ben, in veel gevallen nog voor er een aanbieding is, al met de (potentiële) opdrachtgever(s) in gesprek om te toetsten of mijn beschrijving aansluit bij de beleving van de uiteindelijke (key-)users. Op die manier voorkom ik het verschil van inzicht al bij de bron. Met behulp van een projectmanagementoplossing kan ik 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 ik aan de voorkant van het traject al behandel. Verder wordt er volgens agile ontwikkeld waardoor ik tijdens de bouw korte iteraties ken. Zo heb ik steeds een vinger aan de pols en blijft de deviatie ten opzichte van de 'ideale (denkbeeldige) lijn' zeer beperkt en goed controleerbaar.

André Weber, manager teststraat, Capgemini BAS

Bij het ontwikkelen van lichte toepassingen is dit een veelbelovende techniek. Ook voor het vaststellen van globale eisen en wensen van complexe toepassingen. Bij zwaardere toepassingen met complexe berekeningen zoals actuariële 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 afbreuk doet aan deze aanpak. Mooie techniek, maar niet voor alle toepassingen.

Ewald Roodenrijs, sr. testmanager, Sogeti Nederland

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 testgevallengeneratie mogelijk is, kunnen onjuist zijn geformuleerd. Modellen bieden de mogelijkheid om zowel te bouwen als te testen!