Is meten ook weten? 5/6. Over het vaststellen van nuttige metrieken. Risicobeheer Functiepuntanalyse voor begroting riskant

Transcriptie

1 Het vakblad over ontwerpen, bouwen, testen en moderniseren van bedrijfsapplicaties Jaargang 2, juli/augustus /6 Risicobeheer Functiepuntanalyse voor begroting riskant Testen Angst drukt zijn stempel Techniek Methodes voor veilig inloggen Is meten ook weten? Over het vaststellen van nuttige metrieken

2 Modelleren is het nieuwe programmeren. Aquima: laagdrempelig en snel toepasbaar in de praktijk. Ontdek wat er gebeurt als programmeren modelleren wordt en u uw software direct naar eigen inzicht kunt aanpassen. ICT wordt zo wendbaar dat uw organisatie sneller inspeelt op marktontwikkelingen. Door te automatiseren aan de hand van business rules, krijgt uw werk als ICT-manager extra diepgang. U zit samen met business collega s dichter op de bedrijfsprocessen. U creëert meer ruimte voor creativiteit en innovatie binnen ICT. Maak vandaag nog kennis met Aquima op Nederland gaat aquimatiseren

3 redactioneel in dit nummer Korte berichten 4 Legal look 7 Als in confflict en delict Als u dit leest, zijn de verkiezingen voor de Tweede Kamer achter de rug. De kans dat er inmiddels al een regering is geformeerd, lijkt me uiterst gering. Dat kunnen ze in het Verenigd Koninkrijk veel sneller. Voorafgaande aan het rode potloden gekletter heb ik de partijprogramma s van een aantal politieke partijen tegen het licht gehouden. Ik heb ze doorzocht op de steekwoorden IT, ICT en automatisering. Was tenslotte toch wel benieuwd naar de standpunten van de partijen op dit vlak. Welaan, de uitkomst is bedroevend. Als industrie telt de softwaresector blijkbaar niet mee, noch zien de politici in ICT een middel om maatschappelijke uitdagingen aan te gaan. Hoezeer ze dat toch het jaar door wel roepen: slimme meters, ICT om energieverbruik terug te dringen, om wachtrijen op te lossen, om efficiëntie door te voeren, om de veiligheid te vergroten, enzovoorts; in de programma s is hierover niets, of hier en daar een splintertje terug te vinden. Wie zoekt op ICT, ziet wel heel vaak de woorden conflict, delict of dictator aan zich voorbijtrekken. Als je ICT zoekt (tussen aanhalingstekens), dan krijg je in vrijwel elk programma nul op het request. Dat geldt ook voor IT en automatisering. Bij de Partij voor de Dieren was dit te verwachten (hoewel het denkbaar is dat software kan helpen dierproeven te verminderen of overbodig te maken, toch?) en ook bij Trots op Nederland had ik niks verwacht (hoewel je toch trots kunt zijn op onze software-industrie, toch?), maar dat de oogst bij PvdA, CDA en VVD zo mager is, stemt droef. Het CDA meldt wel dat de indicatiestelling binnen de zorgverlening baat kan hebben bij automatisering, en de PvdA zegt dat de minister (welke?) verantwoordelijk is voor de automatisering bij de politie, en de VVD hamert op de bescherming van de persoonsgegevens en hoopt dat de stemcomputer weer snel het rode potlood gaat vervangen, maar dan heb je het bij deze partijen wel gehad. Groen Links laat het afweten. D66 heeft nog het meeste te melden. Zo wil de partij ver betering van ICT-projecten. Merkwaardig is wel dat dit wordt gemeld onder het hoofdstukje minder ministeries, maar alla, hiermee steekt de partij al met kop en schouders boven de andere uit. En het houdt niet op: ICT moet rijksbreed en centraal worden uitgevoerd (voorwaar een ferm standpunt, want tot nu toe was dit altijd vloeken in de departemententempel), dan wel uitbesteed. En: ICT kan helpen burgers meer invloed te geven op het bestuur. Is er dan helemaal geen partij die serieuze aandacht heeft voor ICT? Jawel, een heel kleintje: de Piratenpartij. Deze partij heeft louter ten doel de kwalijke effecten van automatisering voor de persoonsbescherming weg te nemen. Al met al een zeer karige oogst. Teus Molenaar Begroting op basis van FPA toch risicovol 8 Product Owner: vertel je verhaal 13 IT moet echt iets toevoegen 14 Emoties bij het testproces 16 Kledingrekken blijven overeind 20 Veiliger inlogmodel voor internet 23 Voordelen cloud computing komen niet aanwaaien 26 Architected Agile verbreedt ontwikkelmethode 28 Software appliance bespaart veel tijd 31 Geen Sinterklaasgesprekken meer 34 Omslagverhaal Is meten ook weten? 36 Test Driven Development 40 Coentunnel in digitaal dossier 43 Het vlindereffect 44 Boeken enzo 45 Patenttrollen 46 Hoofdredacteur teus@appworks.nl appworks juli/augustus

4 kort SaaS is ingeburgerd Het gebruik van Software as a Service is geen nieuwtje meer. Ongeveer de helft van de organisaties heeft al drie jaar een abonnement op een dergelijke dienst en 95 procent houdt hieraan vast of gaat dit zelfs uitbreiden. In het Gartner-rapport User Survey Analysis: Software as a Service, Enterprise Application Markets, Worldwide, 2010 valt te lezen dat integratie-eisen de belangrijkste redden is om over te gaan op SaaS. De wens om tot een lagere Total Cost of Ownership te komen, is ook een drijvende kracht. Gartner noemt het wel opvallend dat slechts 39 procent van de organisaties regels heeft opgesteld om het gebruik van SaaS-applicaties te evalueren. De populairste toepassingen zijn , boekhouding, verkoopautomatisering en klantendienst, en uitgavenbeheer. Zestien procent gaf aan op zijn schreden terug te keren en van een SaaS-oplossing weer terug te gaan naar software binnen de eigen systemen. Er springt niet direct een reden uit voor deze terugvering, maar er zijn aanwijzingen dat dit te maken heeft met integratieproblemen of te hoge kosten. Eerste mens met computervirus De Britse wetenschapper dr. Mark Gasson is de eerste mens die geïnfecteerd is met een computervirus. Hij wil hiermee bewijzen dat medische apparatuur kwetsbaar is voor digitale ziektes. Mark Gasson is senior onderzoeker aan de School of Systems Engineering van de University of Reading. Hij heeft een sterke RFID-chip onder de huid van zijn hand ingebracht om aan te tonen dat medische apparaten kwetsbaar zijn voor computervirussen. Hij heeft namelijk de chip met opzet geïnfecteerd. Hij gebruikt de chip om de deuren van zijn labora torium te openen en zijn mobiele telefoon actief te krijgen. Het virus wordt via het controlesysteem van de lab-toegang overgebracht op de toegangskaartjes die zijn collega s Eén van de gebouwen op de campus van Reading University. gebruiken om het gebouw binnen te komen, op dezelfde manier waarop een computervirus zich binnen een netwerk gedraagt. De bekendste implantaat bij de mens is de pacemaker, maar er zijn ook chips die bijvoorbeeld de blaas regelen. Naarmate meer mensen met dergelijke chips zijn uitgerust, neemt het risico toe dat de implantaten worden geïnfecteerd. Gasson heef zijn bevindingen kenbaar gemaakt op het IEEE International Symposium on Technology and Society in Australië dat van 7 tot 9 juni plaatsvond. Algoritme ontdekt sarcasme Wetenschappers van de Hebrew University in Jeruzalem hebben een algoritme ontwikkeld dat in staat is sarcasme in lange teksten te herkennen. De score van 77 procent is beduidend hoger dan wat mensen bereiken. Het onderzoek is gedaan door Oren Tsur en Dmitri Davidov, beiden doctoraal student aan het HU Institute of Computer Science. Zij zijn begeleid door prof. Ari Rappoport. De studie heeft negen maanden in beslag genomen. Zij hebben 5500 boekbesprekingen van Amazon. com gehaald en door vrijwilligers laten controleren op sarcasme. Met deze lijst van zinnen is het algoritme ontwikkeld dat patronen herkent in zinnen die mensen gebruiken om iets duidelijk te maken dat zij niet letterlijk menen. Het algoritme is getest op tienduizenden andere zinnen op Amazon.com die vrijwilligers als al dan niet sarcastisch hadden aangemerkt. De score kwam uit op 77 procent. Het resultaat kan helpen de interactie tussen mens en computer te verbeteren. 4 appworks juli/augustus 2010

5 Index voor webservices Onder aanvoering van CA Technologies is een index ingevoerd om de waarde van webservices te meten: de Service Management Index (SMI). Tegelijk is een website, annex community, in het leven geroepen als zwaartepunt van kennis over de cloud: Miljoenen subsidie voor SaaS-projecten NWO-Jacquard heeft vijf SaaS-projecten uitgekozen die gezamenlijk twee miljoen euro subsidie krijgen. De projecten gaan uiterlijk in september 2010 van start. Een Tijdens CA World in Las Vegas vertelde David Hodgson, senior vice president Cloud Commons bij CA, dat het bedrijf de afgelopen negen maanden heeft gezocht naar een manier om de waarde van webdiensten te meten en weer te geven. Terwijl wij hiermee bezig waren, kwamen we erachter dat er wel meer dan drieduizend webdiensten Laura Meluer legt uit hoe de index wordt opgebouwd. tegenwoordig beschikbaar zijn. Hoe vind je die? En hoe waardeer je die? De SMI en de community moeten hier een antwoord op geven. CA heeft de eerste stap gezet en samenwerking gezocht met bijvoorbeeld Gartner, Forrester en IDC. Deze analistengroepen werken mee aan de site en de index. Verder hebben we de universiteit Carnegie Mellon bereid gevonden om de index wetenschappelijk verder uit te werken. Cloud computing is een reis, Cloud Commons wil de reisgids zijn. Jeff Perdue, senior scientist bij Carnegie Mellin in Silicon Valley, gaf aan dat tevens wordt gepoogd om industriebreed gedragen definities te formuleren van wat bijvoorbeeld moet worden verstaan onder beschikbaarheid, kwaliteit of dienstverlening als het gaat om cloud services. Bij veel mensen bestaat het idee dat gebruik maken van de cloud riskant is. Wij willen een geaccepteerd framework (verder) ontwikkelen dat een houvast biedt voor mensen die gebruik willen maken van cloud services. Carnegie Mellon vormt een SMI Consortium om de index te vervolmaken. Laura Meluer, VP Cloud Community bij CA, lichtte toe dat de waardes die in de index komen, is opgebouwd uit objectieve en subjectieve beoordelingen. ITprofessionals kunnen aangeven wat zij vinden van bepaalde diensten; zij kunnen met elkaar in discussie gaan, elkaar vragen stellen. Kortom alles doen wat bij een community hoort. Om de site alvast inhoud te geven, hebben we zelf al onderzoek laten doen naar ongeveer 300 cloud dienstverleners en deze gewaardeerd. Op de site zijn blogs te vinden, meningen van analisten en tal van artikelen. Er zijn vijf onderwerpen ingedeeld: security, private cloud, public cloud, hybrid cloud, en all other topics. internationale commissie heeft de tien volledig uitgewerkte aanvragen beoordeeld. Het Joint Academic and Commercial Quality Research & Development (Jacquard) is opgezet om het onderzoeksterrein van software en service engineering in Nederland te versterken. Samenwerking tussen universiteiten en bedrijfsleven is een belangrijk onderdeel van het succes van het programma. Het project Configurable Services for Local Governments (CoSeLoG) heeft tot doel het SaaS-paradigme toe te passen in de context van gemeentelijke processen. De bedoeling is uitvoerbare referentiemodellen te ontwikkelen waardoor gemeenten niet gedwongen zijn om alles precies hetzelfde te doen als zij uit besparingsoverwegingen een SaaS oplossing willen gebruiken. Binnen het Scale.It.Up-project definiëren de onderzoekers een architectuur en een methode die het mogelijk maken om Multi-tenant softwaresystemen online te laten evalueren en ook online te testen. Het project Service Extraction from Decomposed Software Monoliths in the Financial Domain onttrekt services uit monolitische applicaties in het financiële domein. Deze services worden herkend op basis van patronen en domeinmodellen. Next Generation Auditing gaat onderzoek doen naar auditingdiensten die de financiële en administratieve processen in bedrijven continu, real-time, controleren. Het project is gebaseerd op de waardekringloop, een bewezen kernconcept uit de Nederlandse accountancytheorie. Re-engineering Service Oriented Systems (ReSOS) ten slotte is op zoek naar voldoende uitgewerkte technologieën en controlemechanismen voor het onderhoud van service oriented systemen. appworks juli/augustus

6 kort AAP krijgt software De Stichting AAP in Almere heeft AutoCAD LT gekregen voor het bijhouden van bouwkundige en installatietechnische revisietekeningen en voor het bouwen van ad-hoc verblijven. Zij wil het ook inzetten voor het vastleggen van transportkisten, vangkooien en luiken. ICT-bestedingen groeien Uit de jongste ICT-Barometer van Ernst & Young blijkt dat 39% van de ondervraagden verwacht meer te besteden aan ICT; 20% verwacht een daling. Per saldo is er een forse stijging te verwachten. AAP werkt aan de verbetering van het welzijn van uitheemse niet-gedomesticeerde dieren. Onder meer door opvang, genezing en herplaatsing, of permanente verzorging van individuele dieren. De stichting is afhankelijk van giften. Autodesk heeft via zijn distributeur Man and Machine en reseller NPQ CAD Solutions de software gratis ter beschikking gesteld. De laatste heeft Nordined LT gegeven. Hiermee zijn gebouwgebonden installaties te tekenen. De stichting kreeg ook de LT-handleiding van TEC CAD College. De software is nodig om de lay-out van de dierenverblijven aan de steeds veranderende capaciteits-, welzijns- en veiligheidseisen aan te passen. Uiteraard krijgen betrokkenen ook training aangeboden. Alle sectoren vooral overheid en dienstverlening verwachten in het komende jaar meer te investeren in ICT. De sectoren handel/distributie, overheid en dienstverlening gaan meer uitgeven aan hardware. De totale bestedingen aan hardware nemen toe: 32% (in februari was dat nog 25%) verwacht een toename, terwijl 17% (20%) denkt dat deze zullen afnemen. De investeringen in software nemen aanzienlijk toe: 41% (28%) verwacht een toename, slechts 14% (18%) een afname. Het herstel van de softwaremarkt die we in de tweede helft van 2009 zagen, zet nu met vaart door, waarbij het topniveau van de afgelopen tien jaar weer in zicht komt, luidt de toelichting van Jacob Verschuur, directeur Ernst & Young ICT Leadership. Daling in ontwikkelsoftware Wereldwijd is de omzet van applicatie ontwikkelsoftware in 2009 gedaald met 2 procent naar 7,25 miljard dollar. Voornamelijk door het bevriezen van projecten in het begin van het jaar, aldus Gartner. Hoewel projecten werden stilgelegd, is er wel veel geïnvesteerd in beveiligingstesten, aldus Laurie Wurster. Zij is onderzoekster bij Gartner. IBM blijft marktleider met 27,7 procent. Dit komt deels door de strategische overnames van Watchfire (2007) en Ounce Labs (2009) die zich vooral op beveiligingstesten richten. Tweede op de markt is Microsoft met 14,7 procent. Volgens Wurster is dat verrassend, omdat veel bedrijven de aankoop van Visual Studio hadden uitgesteld tot de lancering van de nieuwste versie: Visiual Studio Op de derde plaats staat CA Technologies (11%); op de voet gevolgd door HP (10,5%). Compuware is hekkensluiter met 5,9%. Wurster verwacht dat de verkoop van ontwikkelsoftware dit jaar met twee tot drie procent groeit. Het Java-platform en Dynamische webapplicatie tools blijven geduchte concurrentie ondervinden van open source alter natieven. Zij meent voorts dat de consolidatie in deze markt voortzet waarbij de grote spelers de pure play leveranciers van ontwikkelsoftware opkopen om hun eigen suites aan te vullen. 6 appworks juli/augustus 2010

7 legal look De verschillende licentiemodellen? In ieder nummer van AppWorks beantwoordt mr. Victor de Pous juridische vragen. Wie iets wil vragen aan hem kan een mail sturen naar De redactie van AppWorks zorgt dan dat u antwoord krijgt. > Waarom verschillen licentiemodellen voor computerprogramma s eigenlijk? Victor de Pous Softwareproducenten zoeken voortdurend naar de optimalisering van hun verdienmodel. Daarom worden applicaties geleverd op basis van uiteenlopende metrics of een combinatie ervan. Die bepalen uiteindelijk de hoogte van de totale gebruiksvergoeding en vaak ook de hoogte van de kosten voor support & maintenance. En deze diversiteit constateren we zelfs bij verschillende producten van een en dezelfde producent. Eenvoud en transparantie ontbreken vaak. We hebben het bijvoorbeeld over licensering op basis van rekenkracht (aantal of snelheid van de CPU, aantal cores of threaths ), aantal machines (servers), aantal eindgebruikers ( concurrent of non-concurrent users ), aantal (financiële) transacties en wat dies meer zij. Soms worden er site license agreements afgesproken, dus per bedrijfs vestiging. Een nog complexer voorbeeld betreft de licentieverlening per automated process, zoals Oracle soms doet. Het is onduidelijk wat dat is. > Welke modellen faciliteren SaaS en cloud computing het beste? Wanneer ICT meer en meer van een product in een dienst verandert, dringt de vraag zich op welke achterliggende licentiemodellen efficiënt en schaalbaar zijn. Het voor de hand liggend antwoord luidt: eenvoudige modellen. Daarbij zijn in ieder geval gebruikers geholpen; zeker wanneer we ook nog eens nieuwe manieren van werken in de informatiemaatschappij mee laten wegen. Dat betekent dat licentieverlening gebruiksrechten moet bieden aan eindgebruikers die letterlijk plaats- en tijd onafhankelijk werken. Dus in and out-of-office. Maar we mogen de redelijkheid en billijkheid niet vergeten. Wat heb je aan virtualisatie als de kosten voor softwaregebruik dusdanig stijgen, dat de Total Cost of Ownership niet wordt verlaagd? Afhankelijk van de aard van de software (ontwikkelprogrammatuur en tools, applicaties, besturing- en netwerksystemen) kunnen de preferente modellen dus verschillen. Ingewikkelde constructies, die gebruik maken van meer dan een parameter doen minder recht aan SaaS en cloud computing. Voor applicaties, zoals productiviteitssoftware, biedt licentieverlening per werkplek/gebruiker waarschijnlijk de beste oplossing. > Wat doet software asset management? Meten is weten. Zoals producenten bezig zijn met optimalisering, zo kunnen softwaregebruikers bij overheid en bedrijfsleven dat ook doen; juist gelet op de huidige economische situatie. Software asset management biedt het gereedschap voor efficiënt licentiebeheer. Uit de praktijk blijkt dat het ontbreken van accurate informatie over alle software onder meer wordt veroorzaakt door de decentrale autonomie voor softwarekeuzes, ICT-integratie na fusies en overnames, complexe softwarecontracten en lage waardering voor software-inventarisaties. Software asset management processen kunnen operationele en juridische risico s verminderen en tevens door het standaardiseren van applicaties het gebruik uniformeren en hiermee softwarekosten verlagen. Terwijl organisaties door een proactieve aanpak een betere beheersing krijgen over hun de waarde van hun software, realiseren ze ook een reductie van arbeidskosten voor ICT. In sommige gevallen zelfs tot 50%. Mr. V.A. de Pous is bedrijfsjurist en industrie-analist. Hij houdt zich sinds 1983 bezig met de juridische aspecten van digitale technologie en informatiemaatschappij en is medewerker van uitgeverij FenceWorks. appworks juli/augustus

8 risicobeheer Begroting op basis van FPA toch risicovol Veel bedrijven hanteren Functiepuntanalyse (FPA) als middel om tot een transparant begrotingsmodel te komen voor softwareontwikkeling die zij uitbesteden. Functiepunten geven alleen de omvang van een systeem weer. Voor een begroting zijn meer stappen nodig die nu niet of onvoldoende zijn gestandaardiseerd. Dit leidt tot risico s waarvan organisaties zich vaak onvoldoende bewust zijn. Eric van der Vliet, Jelle de Vries Grote verwarring ontstaat doordat de bepaling van de omvang van een systeem, zoals functiepunten, en de begroting van de kosten vaak op één hoop wordt gegooid. Dit zijn twee afzonderlijke activiteiten. Als we een vergelijking maken met de bouwsector, dan worden de m3 van een gebouw (de inhoud) gebruikt als basis voor de kostprijsberekening (de begroting). Kostprijsberekening in de bouwsector is een vak op zich (calculator of cost engineer). In de ICT is een vergelijkbare rol niet of nauwelijks bekend. Een oorzaak is onvoldoende standaardisatie van het proces om te komen tot een begroting waardoor dit vakgebied nog maar beperkt is ontwikkeld. Organisaties die functiepunten gebruiken, zijn zich vaak onvoldoende bewust van de (financiële) risico s die zij hierbij lopen. Wat vraagt de markt? Het wordt niet meer geaccepteerd dat een aanvankelijke positieve business case tijdens het project onderuit gaat omdat de kosten en de doorlooptijd niet in de hand te houden zijn. Het gebruik van een objectieve omvangeenheid, zoals functiepunten, met vaste prijsafspraken per eenheid lijkt de oplossing voor kostenbeheersing en transparantie van de begroting. Klanten die een leverancier louter selecteren op basis van een prijs per functiepunt missen de essentie: de garantie van de levering van een kwalitatief goed product binnen tijd en budget. Alleen inzicht in de prijs per functiepunt is onvoldoende om tot een goed product te komen. Een goedkope applicatie met veel fouten kan voor een onderneming uiteindelijk veel duurder uitpakken door hogere beheerkosten. Voor een transparante begroting is het belangrijk het gehele proces van functiepunten tot en met de begroting te standaardiseren en om over factoren die dit proces kunnen beïnvloeden, zoals doorlooptijd, goede afspraken te maken. Vier processtappen Om een begroting te baseren op functiepunten is een aantal stappen nodig. Slechts één van deze stappen betreft de functiepuntanalyse. De overige stappen zijn ook noodzakelijk om te komen tot een betrouwbare begroting. Omdat behalve FPA de processtappen niet zijn gestandaardiseerd, zijn begrotingen van meerdere organisaties niet vergelijkbaar. Het is tevens onmogelijk objectief vast te stellen of deze stappen correct zijn doorlopen. 8 appworks juli/augustus 2010

9 Functiepuntanalyse (FPA) Functiepuntanalyse is een methodiek die punten geeft aan gebruikersfuncties. De FPA-methode is vastgelegd in richtlijnen en in een ISO standaard [ISO/IEC 24570] en zou daarmee gesneden koek moeten zijn, maar niets is minder waar. Dat de standaard bestaat uit een document van meer dan 200 pagina s geeft al aan dat het behoorlijke kennis vergt om deze standaard eenduidig toe te kunnen passen. Een risico is dat de richtlijnen op verschillende manieren worden geïnterpreteerd met als gevolg verschillen in het aantal functiepunten. Een gedegen opleiding en begeleiding door ervaren tellers is dan ook heel belangrijk. FPA is immers een beoordelingsmethodiek en geen exacte wetenschap. Door bewuste of onbewuste aannames kunnen functiepunttellingen op onderdelen verschillen terwijl de totalen gelijk kunnen zijn. Aannames en tellingen van onderdelen dienen dan ook altijd te worden vergeleken. Ook bij ervaren tellers geldt dat de telling door een tweede persoon moet worden gereviewd of dient een onafhankelijke telling te worden uitgevoerd om voldoende nauwkeurigheid te garanderen. Inzicht in de oorzaak en mate van verschillen in tellingen geeft een goede indicatie van de risico s, die vervolgens in het project moeten worden gemanaged. en de producten die in dit proces worden opgeleverd definiëren. De standaardisatie dient ook de beinvloedingsfactoren te definieren en aan te geven wanneer FPA wel of niet toepasbaar is. Het gebruik van FPA om een begroting op te stellen, is risicovol. De kans dat de berekeningen niet kloppen, is groot. Het gevolg is een vaak onacceptabele afwijking tussen de begroting en de werkelijke kosten. Om de risico s in dit proces te begrijpen is het belangrijk om inzicht te hebben in de stappen. De eerste stap in dit proces is de applicatiebeschrijving of de input die wordt gebruikt voor de omvangbepaling. Zonder goede documentatie wordt het lastig, zo niet onmogelijk om een accurate FPA uit te voeren en te komen tot een nauwkeurige omvang van het te realiseren systeem. De tweede stap in het proces is de functiepuntanalyse, waarin middels een telling de omvang van het te realiseren product wordt bepaald. Bij het maken van een begroting is het belangrijk om de factoren te bepalen die de productiviteit en dus de prijs per functiepunt beïnvloeden (derde stap). De laatste stap is het maken van een begroting op basis van het aantal functiepunten en de vastgestelde beïnvloedingsfactoren. Het is belangrijk dat leveranciers standaarden hebben om de consistentie van begrotingen te vergroten. Deze standaarden moeten het proces Applicatiebeschrijving Om een nauwkeurige omvang te bepalen, dient een applicatiebeschrijving voldoende te zijn uitgewerkt en een functioneel ontwerp te bevatten. Om te komen tot applicatiebeschrijving worden de volgende fasen doorlopen: Projectidee Om een functiepuntenanalyse uit te kunnen voeren op basis van een projectidee, is het belangrijk dat deze is gebaseerd op basis van behoeften vanuit de business, die bij voorkeur zijn vastgelegd in een enterprise architectuur. Het proces om te komen tot een projectidee dient te zijn gestandaardiseerd, omdat het de basis vormt van een eerste versie van een business case. Onderdeel van een business case is een indicatie van de kosten. Een uitgebreide en accurate functiepuntanalyse is in deze fase echter nog niet mogelijk. Wel is het mogelijk om een indicatieve functie puntanalyse uit te voeren. Het is oppassen dat het aantal indicatieve functiepunten niet als definitief aantal wordt beschouwd, omdat de mogelijke nauwkeurigheid beperkt is tot een marge van +/- 50%. Systeemeisen Nadat het idee is goedgekeurd voor verdere uitwerking, wordt een beeld gevormd van welke eisen aan het nieuwe systeem worden gesteld. Tegenwoordig gebeurt dit vaak behulp van Use Case beschrijvingen. Deze fase maakt het al een stuk duidelijker welke functionele gebieden worden geraakt. Nu is een indicatieve functiepuntanalyse zeker appworks juli/augustus

10 Applicatie beschrijving Functiepunt analyse Beïnvloedings factoren Begroting mogelijk, met de nadruk op indicatief en dus niet bruikbaar voor een definitieve omvangschatting. Door de wet van de grote aantallen wordt de kans op een omvangsschatting die uitkomt nabij de uiteindelijke omvang groter. Dus hoe groter een project des te kleiner de kans op een grote percentuele afwijking tussen inschatting en de werkelijke omvang. Globaal ontwerp Een globaal ontwerp of een Solution Architectuur is nodig om de eisen te vertalen in een oplossing. Idealiter wordt deze fase iteratief uitgevoerd waarbij oplossingen en eisen voordurend worden bijgesteld aan elkaar. Als deze fase is afgerond, is een globale functiepuntenanalyse mogelijk en kan worden bepaald welke beïnvloedingsfactoren relevant zijn. Omdat nog geen gedetailleerde documentatie beschikbaar is, moet in deze fase rekening worden gehouden met een mogelijke variatie van het aantal functiepunten van +/- 35%. In de praktijk wordt deze fase van een project veelal niet of nauwelijks uitgevoerd en worden direct functionele of technische ontwerpen gemaakt. Als gevolg hiervan is het globaal ontwerp vaak nog zo rudimentair dat de functiepuntanalyse op onvolledige invoer is gebaseerd en nauwelijks waarde heeft. Het is dan ook van belang dat de partij die de eisen Een gebrek aan standaarden (zoals de meter) maakt het lastig een FPA te gebruiken als basis voor het opstellen van een begroting voor softwareontwikkeling. Deze stappen zijn nodig om tot een transparante begroting voor een softwareontwikkelproject te komen. aanlevert en de partij die de realisatie uitvoert in een zo vroeg mogelijk stadium afstemmen en tot overeenstemming komen. Functioneel ontwerp Het functioneel ontwerp of de functionele architectuur wordt opgesteld op basis van van het globaal ontwerp of de Solution Architectuur. Op basis van dit functioneel ontwerp is het mogelijk een gedetailleerde functiepuntanalyse uit te voeren. De nauwkeurigheid van deze telling hangt af van de kwaliteit van het functioneel ontwerp. Als deze kwaliteit onvoldoende is zal, ondanks de uitvoering van een gedetailleerde functiepuntanalyse, de nauwkeurigheid nog steeds beperkt zijn en meer dan gemiddeld afwijken van de realiteit. Het is belangrijk dat de functiepunttellers deze afwijking signaleert en ook rapporteert aan zijn opdrachtgever. Toepasbaarheid van FPA Functiepunten analyse is bedoeld voor transactiegebaseerde systemen waarbij het aantal transacties representatief is voor de omvang van het systeem. Meestal zijn dit administratieve systemen met een duidelijke gebruikersinteractie. Soms bevatten transactiegebaseerde systemen complexe berekeningen. Deze complexiteit wordt niet vertaald in de functionele omvang; de kans is groot dat de begroting niet klopt met de realiteit. Complexiteit is dan ook een belangrijke beïnvloedingsfactor. Technische systemen die weinig gebruikersinteractie hebben zijn niet geschikt voor functiepuntanalyse doordat er geen of een beperkt aantal transacties is dat geteld kan worden en daarmee niet representatief voor de begroting. Er zijn nieuwe ontwikkelingen op het gebied van functiepunten (bijvoorbeeld Cosmic Full Function Points) die meer geschikt zijn voor technische systemen, maar in dit artikel buiten beschouwing worden gelaten. Een nieuwe ontwikkeling is het gebruik van functiepuntanalyse voor het begroten van pakket implementaties. Dit vereist wel dat voldoende documentatie van de te implementeren functionaliteit beschikbaar is. Doordat het meestel gaat om standaard functionaliteiten is deze functionaliteit vaak niet of beperkt gedocumenteerd. Dit maakt het tellen van functiepunten lastig. Over de toepasbaarheid van functiepunten voor pakketimplementaties bestaat nog twijfel. 10 appworks juli/augustus 2010

11 Kwaliteit van gebruikte documentatie Als documentatie beschikbaar is met voldoende diepgang, dan nog is het voor een goede FPA-telling belangrijk dat de documentatie van voldoende kwaliteit is. Als de documentatie niet of onvoldoende is gereviewd, kan deze nog allerlei onjuistheden en onduidelijkheden bevatten die later leiden tot discussie en in dit stadium tot een verkeerd aantal functiepunten. De functiepuntanalist dient dan ook voor de start van de telling de kwaliteit van het document te toetsen. Beïnvloedingsfactoren Om een prijs per functiepunt te bepalen, is het belangrijk om na te gaan welke factoren de prijs beïnvloeden. Voorbeelden van beïnvloedingsfactoren zijn de volwassenheid van de ontwikkelorganisatie; samenstelling, kennis en ervaring van het team; bekendheid van projectleden met de materie; de gekozen ontwikkelmethodiek; activiteiten / producten die deel uitmaken van de begroting; doorlooptijd van het project; volledigheid en concreetheid van de eisen. Andere factoren zijn beschikbaarheid van de vereiste documentatie; kwaliteit van de producten; omvang van het te leveren systeem; complexiteit van het te leveren systeem; en architectuureisen voor het te leveren systeem (non functionals). Als deze factoren niet of onvoldoende inzichtelijk zijn, dan kan dit grote gevolgen hebben voor de begroting van het project. Begroting In de bouwsector is kostprijsberekening een vak op zich. Begroting is uiteindelijk de stap om te komen tot een prijs per functiepunt. Hierin zitten twee belangrijke factoren: het aantal functiepunten zoals die tijdens de telling is vastgesteld; de prijs zoals vastgesteld op basis van de beïnvloedingsfactoren en de productiviteit. Om het nog complexer te maken: ook het aantal functiepunten heeft invloed op de uiteindelijke productiviteit en daarmee de prijs per functiepunt. Omvang is namelijk één van de beïnvloedingsfactoren met een totaal niet lineair beïnvloedingspatroon. Dit wordt vaak niet onderkend, waardoor de foute aanname wordt gedaan dat als een project 2x zo groot wordt de kosten ook 2x zo hoog zijn. In de praktijk nemen de kosten in veel grotere mate toe. Voor het bepalen van de productiviteit en de kosten is het essentieel ervaringscijfers te hebben. Er zijn allerlei benchmarkgegevens en benchmark-tools met ervaringscijfers op de markt beschikbaar. De cijfers zijn echter primair bedoeld om een organisatie te benchmarken. Een klant kan bepalen in hoeverre een aanbieding afwijkt van het marktgemiddelde. Een leverancier kan de benchmarkgegevens gebruiken om te bepalen of zijn productiviteit in de buurt ligt van die van andere organisaties. appworks juli/augustus

12 Het gebruiken van de benchmark gegevens voor het bepalen van de productiviteit is een risico omdat dat deze cijfers niet in iedere organisatie zonder meer toepasbaar zijn. Het hebben van eigen ervaringscijfers heeft dan ook de voorkeur. Change management Als een prijs per functiepunt is afgegeven zonder duidelijke aannames, uitgangspunten en afspraken dan levert dit voor zowel klant als leveranciers risico s op. Bijvoorbeeld bij change requests, geldt dan dezelfde prijs? Begroting is uiteindelijk de stap om te komen tot een prijs per functiepunt. Nieuw is het gebruik van functiepuntanalyse voor het begroten van een pakket implementatie. Dit vereist wel dat voldoende documentatie van de te implementeren functionaliteit beschikbaar is. Wat als het aantal functiepunten toch meer blijkt te zijn? Is dit voor kosten van de leverancier of toch de klant? Wat zijn de afspraken met betrekking tot kwaliteit? Een product kan dan misschien wel worden opgeleverd, maar als de kwaliteit onvoldoende is, dan nemen de kosten tijdens de garantieperiode en in beheer navenant toe. Bij wie ligt dit risico? Wat als de klant ineens vraagt om een kortere doorlooptijd? Ervaring en benchmarks tonen aan dat de prijs daarmee toeneemt. Zijn hier duidelijke afspraken over gemaakt? Change requests zijn onderdeel van elk project. De invloed van het toevoegen van nieuwe functionaliteit is groot als daarmee een project substantieel in omvang toeneemt. Zolang de totale groei of krimp van een projectomvang niet meer dan 1% bedraagt, kan nog worden volstaan met een impactbepaling voor de change zelf. Als de groei, of de wijzigingsgraad, van een project meer wordt, dan is het risico zo groot dat dit impact heeft op de originele begroting dat het verstandig is de impact opnieuw te berekenen. Dit is evenwel arbeidsintensief; wie gaat dat betalen?. Change requests die betrekking hebben op de opleverdatum van projecten en vooral waarin deze wordt vervroegd zijn een bron van problemen. Er is geen lineair verband tussen omvang en kosten, zo is er ook geen lineair verband tussen inzet van mensen en doorlooptijd. Als er een begroting is gemaakt voor een project is die begroting alleen geldig voor die berekende omvang en doorlooptijd. Door projectfactoren zoals doorlooptijd en bemensing te veranderen, moet een begroting opnieuw worden gemaakt. Hierbij geldt dat de kans op het mislukken van een project toeneemt met het krimpen van de beschikbare tijd. Referenties Alain Abran, Jean-Marc Desharnais, Serge Oligny, Charles Symons, Cosmic Functional Size Measurement Method, version Ars Conjectandi (De kunst van het opstellen van vermoedens); Software Engineering Economics. Prentice Hall, 1981 Jan Jaap Cannegieter, Erik van Veenendaal, Eric van der Vliet, Mark van der Zwan. Reviews in de praktijk. Academic Service Clinger Cohen Act; wet in de Verenigde Staten uit 1996 ter bevordering van efficiënte IT-investeringen bij de overheid door een verplichte Enterprise Architectuur Cockburn 2002; Use cases, ten years later. Oorspronkelijk gepubliceerd in STQE Magazine, Mar/Apr Gilb, T & Graham, D. Software Inspections. Addison Wesley, 1993 ISO/IEC Functional size measurement method, 2005 Jacobson; Object-Oriented Software Engineering. Addison Wesley Professional, 1992 Jones, C. Software Assessments, Benchmarks, and Best Practices. Addison Wesley, 2000 Jones, C Applied Software Measurement. McGraw Hill, 1997 Nesma; Definities en Telrichtlijnen voor de toepasing van functiepunten analyse v2.2. Nesma, 2004Fred J. Heemstra en Rob J. Kusters. Wat bepaalt de kosten van ERP-implementatie? Management accounting 2005 SEI. CMMI for Development v1.2. CMU/SEI-2006-TR Verhoef; Quantifying the Value of IT-Investments, Free University of Amsterdam, Department of Mathematics and Computer Science Yang, Y., Chen, Z., Valerdi, R., Boehm, B., Effect of Schedule Compression on Project Effort, 27th Conference of the International Society of Parametric Analysts, June 2005, Denver, CO. Eric van der Vliet is Lead Expert Estimating bij Logica Nederland Jelle de Vries is Solution Architect en productmanager metrieken bij Ordina 12 appworks juli/augustus 2010

13 requirements Product Owner: vertel je verhaal! Geen stapels met papieren waarop requirements staan geschreven, maar een gloedvol betoog. Als Product Owners gewoonweg vertellen wat hun bevindingen zijn, en daarmee het team enthousiasmeren, dan lopen softwareprojecten een stuk beter. Geert Bossuyt duidelijke manier te vertellen, de rest van het team enthousiasmeren. Hij kan ervoor zorgen dat het team zijn visie begrijpt, daarmee focus krijgt en zijn wensen snapt! Dus niet meer de nadruk op requirements schrijven, backlog vullen en gereed hebben voor een volgende Sprint, maar vragen van teamleden beantwoorden en bevestigen dat het team inderdaad het juiste gebouwd heeft. Niet meer proberen voor het team uit te rennen maar samen met het team een oplossing realiseren! Door telkens weer zijn verhaal te vertellen, details te geven en te luisteren naar de feedback ontstaat een steeds grotere interactie. Deze interactie tussen mensen om werkende software opgeleverd te krijgen is noodzakelijk. Interactie binnen het team maar ook met de klant! Een Product Owner die goed onder woorden kan brengen wat hij wil, vertelt bijvoorbeeld niet alleen dat hij een fiets wil, maar ook dat hij daarmee door de Ardennen wil fietsen. Dat detail zorgt ervoor dat de teamleden begrijpen dat er een aantal randvoorwaarden zijn waaraan die fiets moet voldoen. Doet hij dit goed, dan raakt zijn team enthousiast. Enthousiaste teamleden stellen vragen waarop ingespeeld kan worden en voelen zich ook meer verantwoordelijk voor de resultaten. Mijn zoon zat dit weekend bij zijn grootmoeder op schoot. Zij vertelde hem een verhaal waar hij helemaal in opging. Hij stelde allerlei vragen, vulde aan en had alleen nog maar oor voor haar. Ik was vertederd door zijn jeugdig enthousiasme. Tegelijkertijd vroeg ik me af waarom volwassenen maar zelden een zelfde soort enthousiasme tonen. Volwassenen lachen, knikken en soms stellen ze vragen. Zelden tref ik een volwassene met rode wangen, over lopend van enthousiasme, over iets waarbij hij is betrokken of dat zijn aandacht heeft getrokken. Als Agile Coach ben ik bij diverse, zeer uiteenlopende, projecten betrokken waar vaak scrum wordt gebruikt. Een belangrijke rol binnen scrum is weggelegd voor de Product Owner, die de stem van de business ver tegenwoordigd. Om deze rol goed te kunnen vervullen, moet een Product Owner onder andere een duidelijke visie hebben op wat hij wil realiseren en dit helder kunnen vertalen naar de noodzakelijke functionaliteit. Hiermee zorgt hij voor focus. Daarnaast moet hij goed kunnen uitleggen waarom deze functionaliteit noodzakelijk is en met welke prioriteit deze moet worden geïmplementeerd. Verder wordt van hem ook nog feedback verwacht op de reeds ontwikkelde functionaliteit. Dit zijn een hoop taken en verantwoordelijkheden waardoor menig Product Owner zijn rol als een zware taak ziet. Als vertegenwoordiger van de visie zou zijn rol, denk ik, een stuk eenvoudig kunnen zijn. Het toverwoord is enthousiasmeren! Details geven In plaats van het uitschrijven van alle mogelijke requirements kan hij, door zijn verhaal op een Enthousiasme Een goed project staat of valt met de rol die de teamleden invullen en de mate waarin deze leden hun verantwoordelijkheid nemen voor de uit te voeren activiteiten. De rol van Product Owner kan een stuk efficiënter worden ingevuld door in plaats van veel papier met requirements te produceren de interactie te zoeken. Ik roep Product Owners op om hun verhaal te gaan vertellen, hun visie te geven en er te zijn voor het team. Volgens mij verbetert dat de productiviteit, kwaliteit en doorlooptijd enorm en brengt het bovendien het enthousiasme terug! Geert Bossuyt is consultant bij Xebia appworks juli/augustus

14 persoonlijk IT moet echt iets toevoegen Het is toch wel raar dat IT-architecten helemaal niets ontwerpen, terwijl architecten van de gebouwde omgeving niets anders doen, concludeert Douwe Pieter van den Bos na een gesprek met een bouw - architect. Van den Bos ten voeten uit: inspiratie opdoen bij andere branches en prikkelende stellingen innemen. Zijn grondhouding: IT moet waarde toevoegen aan een organisatie. Teus Molenaar Met een achtergond van Technische Bestuurskunde (TU Delft) heeft Van den Bos bewust gekozen voor de IT als branche om in te werken. Ik zocht een sector die op zichzelf volwassen genoeg is, maar vervolgens ontvankelijk voor verbetering. Je kunt in bijvoorbeeld de petrochemie gaan werken, maar die processen zijn in de afgelopen honderd jaar al min of meer uitgekristalliseerd. Daar kun je niet veel meer aan verbeteren. Als het om automatisering gaat, dan doe je eigenlijk niets anders dan bedenken hoe je met technologie in staat bent de bedrijfsprocessen beter te laten verlopen. Daar kun je nog wat betekenen. Dus werd het de IT. Bovendien deed hij al iets met Linux. Ik vind het fascinerend hoe al die vrijwilligers wereldwijd met elkaar samenwerken. Van den Bos kon in 2006 meteen aan de slag bij detacheringsbedrijf Caesar Groep. Hij had er gesolliciteerd als Oracle-deskundige. Had immers cursussen Oracle Forms, Oracle Designer, enzovoorts gedaan. Centraal Boekhuis zag meer in de jonge (Van den Bos is nu 30 jaar) automatiseerder dan een softwareontwikkelaar en vroeg hem requiremens te verzamelen voor enkele losse projecten. Daar leerde hij dat IT iets moet opleveren waaraan de gebruikersgroep behoefte heeft en waarmee de organisatie als geheel vooruit komt. Waarom doen we dit? Elk IT-project moet volgens hem resultaat gericht zijn. En dat is wat hem betreft niet alleen een kwestie van de IT-afdeling, maar evenzeer van de gebruikersgemeenschap. Het is hem een doorn in het oog dat bij de meeste bedrijven de IT-groep en aparte afdeling is, en los lijkt te staan van de rest van het bedrijf. Eigenlijk zou een business analist aan elk IT-project moeten worden toegevoegd. De hele discussie over Business-IT Alignment, of IT Fusion, moet uitmonden in het gezamenlijk bepalen hoe automatisering ten voordele is in te zetten. Wat dat betreft, wordt er aldus Van den Bos al te vaak te veel het IT-domein in geduwd. Als er een probleem is, dan mag de IT-afdeling dat oplossen. Terwijl de oplossing ook vaak is 14 appworks juli/augustus 2010

15 te vinden in het anders organiseren van een bedrijfsproces; zonder automatisering. Hij zegt te vaak IT-projecten tegen te komen die al anderhalf jaar lopen en nog niets hebben opgeleverd; niemand voelt zich er blijkbaar verantwoordelijk voor. En in die anderhalf jaar heeft niemand zich afgevraagd: Waarom doen we dit eigenlijk? Mijn doel is inzichtelijk te maken welke kennis er leeft binnen een organisatie, en ervoor te zorgen dat mensen hun oogkleppen kwijt raken. Iedereen: op de IT-afdeling, maar ook bij de gebruikers, bij de projectleiders. Je.hoort vaak dat iets goed is, omdat ze het al tien jaar op die manier doen. Toch hoeft dat niet per se de beste oplossing te zijn. Daar moeten mensen voor open staan. Hij benadrukt dat softwareontwikkeling ook maar een bedrijfsprocesje is. Wij houden zogenoemde metaplan-sessies met de betrokkenen ook van de business om met een frisse blik naar uitdagingen en mogelijke oplossingen te kijken. Om tunnelvisies te herkennen en kwijt te raken. Drie elementen Van den Bos onderscheidt drie elementen die een rol spelen bij het succesvol tot een goed eind brengen van automatiseringsprojecten. Dat begint met analyse en ontwerp. Ga grondig na wat de uitdaging is en of dit met IT is op te lossen. Maak vervolgens een ontwerp van die oplossing. Een goed beleid van een IT-project is het tweede element. Daarbij moet je niet met een budget werken, maar waarde toekennen aan de problemen en mogelijke oplossingen. Als iets goed meetbaar is, dan is het wel automatisering. We pakken het alleen te vaak verkeerd aan. Ten slotte het derde element: technologie. Uiteindelijk heb je, bij wijze van spreken, toch een hamer of een beitel nodig om iets te maken. Het gaat erom een bewuste keuze te maken. Daarnaast is technologie tegenwoordig een essentieel onderdeel van bedrijfsstrategie; zij kan daadwerkelijk helpen nieuwe markten aan te boren of vooruitstrevend te werken. Dit is een grote overgang van u vraagt, wij draaien naar meedenken en innoveren. Dit is een van de doelen van IT-Business alignment. Als deze drie elementen kloppen, dan kan er niks misgaan met een project, is zijn overtuiging. Overigens ziet hij wel dat de praktijk ten goede aan het veranderen is. Er is meer interesse voor de waardebepaling van software-oplossingen. En technisch is er ook meer mogelijk. Er verschijnt nu software die op de achtergrond precies dezelfde is, maar de secretaresse een heel andere interface voorspiegelt dan de manager. Dat heeft niet alleen met de rechten te maken, maar met het besef dat mensen niet allemaal op dezelfde manier willen werken. Deze ontwikkeling is volgens mij ingezet onder druk van de consumentensoftware. Op dat vlak is nu nog veel meer mogelijk dan bij bedrijfssoftware. Mensen willen op hun werk hetzelfde kunnen doen wat zij thuis doen. Oracle ACE Inmiddels werkt Van den Bos een klein jaartje bij Whitehorses (Oracle- en Java-specialisten). De visie en mentaliteit van dit bedrijf past precies bij mijn opvattingen. Er heerst bij de ongeveer 35 medewerkers een ondernemersgeest, zegt hij hierover. Onlangs is Van den Bos opgenomen in het gelauwerde gezelschap van Oracle ACE s. Er zijn zo n vijftien van dergelijke deskundigen in Nederland. De benoeming kwam voor hem trouwens als een verrassing. Ik heb vorig jaar een boek geschreven over Oracle Applications Express; en dan vooral over hoe je van Oracle Forms naar APEX overgaat. Iemand die onder de indruk was van dit drukwerk heeft mij voorgedragen en vervolgens heeft het Oracle behaagt mij tot ACE te slaan. Nee, hij wordt sindsdien niet herkend in de supermarkt, lacht hij. Maar zijn ACE-status heeft wel voordelen. Ik werk binnen projecten meestal als analist of ontwerper. Sinds ik Ace ben, merk ik dat softwareontwikkelaars en databasebeheerders mij nu meer als een gelijke beschouwen. Mijn taak is het de techniek te vertalen naar een bedrijfsstrategie (en andersom); het vertrouwen van technici is daarbij onontbeerlijk. Inspiratie zoek Van den Bos overal. Hij wil over muurtjes heen kijken. Daarom had ik onlangs een gesprek met een architect. Die ontwerpt een gebouw waarbij hij rekening houdt met de wensen van de toekomstige gebruikers en de technische mogelijkheden. Er zijn veel parallellen. Wat dat betreft is het raar dat ITarchitecten niets ontwerpen, zich eigenlijk alleen met de infrastructuur bezig houden. Teus Molenaar is hoofdredacteur van AppWorks appworks juli/augustus

16 testen Emoties bij het testproces Waarom doen testers de dingen die ze doen? Met deze vraag heb ik me al tijden bezig gehouden. Je zou namelijk verwachten dat IT ers bij uitstek rationele mensen zijn die de dingen die ze doen, uitvoeren volgens een weldoordachte aanpak. We maken een fraai proces en instrueren de mensen hierover. Toch vallen de IT-producten vaak anders uit dan de opdrachtgever tevoren had gedacht. Hoe langer ik in het testen (en het IT-vak in het algemeen) werk, hoe meer ik merk dat emoties een belangrijke rol spelen. Het testproces heeft soms veel weg van een spokenhuis. Bij het testen van software spelen veel gevoelens, waaronder angst (om fouten te maken, om als dom te worden bestempeld), een rol. Niet alleen bij de tester, maar ook bij de opdrachtgever, de projectleider, de ontwikkelaar en eindgebruiker. Een verhandeling over de psychologie van het testen. Rik Marselis Angst In de jaren 80 was er een ongegronde angst voor computers. Voor veel mensen was een computer namelijk een onbekend ding dat magische krachten leek te bezitten. Het klein orkest zong er zelfs over in Koos Werkeloos ; refrein: Kijk he, je hoort vaak zeggen waar moet dat heen; Straks doen computers al het werk alleen. Maar mensen, het gaat toch prima zo. Gratis vrije tijd kado en dat is voor Koos geen probleem. Inmiddels weten we dat hun vrees Straks doen computers al het werk alleen niet bewaarheid is. Computers (en robots) hebben wel veel mensenwerk overgenomen, maar daar zijn andere activiteiten voor in de plaats gekomen. Neem nou . Je denkt toch niet dat we in de jaren 80 een kwart van onze tijd besteedden met memootjes naar elkaar typen! Tegenwoordig is de angst voor computers verdwenen. Het tegendeel lijkt eerder opgeld te doen: men is te goed van vertrouwen en zet z n hele hebben en houden op internet. Maar emoties spelen zeker nog een rol in het werk. Nog meer angst Zo kom ik bijvoorbeeld luie testers tegen die geen testontwerptechnieken gebruiken of het een beetje uit de losse pols doen met als argument dat het anders te veel tijd kost. Maar de echt luie testers hebben al lang ontdekt dat juist door toepasing van testontwerptechnieken het testen minder inspanning kost. (zie ook het artikel in de AppWorks van maart 2010 en het TMap NEXT boek [1]) 16 appworks juli/augustus 2010

17 Of testers besluiten toch maar geen exploratory testing als testontwerptechniek te kiezen voor een systeemonderdeel met laag productrisico, omdat ze bang zijn dat ze dan toch een belangrijke fout over het hoofd zien. Onzekerheid speelt hen parten, want als de belanghebbenden het productrisico als laag hebben ingeschat, dan kun je toch per definitie geen belangrijke fouten in dat onderdeel hebben? Anders was de inschatting fout, maar dat kan de tester niet kwalijk genomen worden. Angst om voor dom te worden uitgemaakt, speelt een rol bij testers die geen ervaring hebben met testtools. Ze gebruiken geen tools, omdat ze bang zijn dat ze in het begin fouten zullen maken. Maar ja, dat hoort nu juist bij leren. De algemene emotie van projectleiders is ongeduldigheid. Nadat er al twee keer een regressietest is gedaan om vast te stellen of bugfixes geen nieuwe fouten hebben geïntroduceerd, dringen ze bij de testers aan om de regressietest voortaan maar over te slaan, omdat er de vorige keren ook geen bevindingen uit zijn gekomen. Maar ja, een regressietest is nu juist het vangnet voor het geval het wel een keer mis gaat. Voor gebruikers is het moeilijk om door hun emoties heen te kijken als de testomgeving faalt. Dan denken ze al heel snel dat het nieuwe informatiesysteem nooit meer wat zal worden. Terwijl ze - goed beschouwd - nog helemaal niets van het nieuwe systeem hebben gezien. Bij al deze emoties speelt een gemeenschappelijk fenomeen dat bekend staat als F.E.A.R. F.E.A.R. Vorig jaar las ik het boek Perfect Software and other illusions about software testing van Gerald Marvin (Jerry) Weinberg [2]. Dit boek was voor mij een feest van herkenning. En ook van nieuwe inspiratie. Zo beschrijft Jerry de theorie over F.E.A.R. van Thomas Crum. Het acroniem staat voor Fantasy Experienced As Reality. Bij de emoties die ik in de vorige paragraaf beschreef, speelt precies dit fenomeen een rol. In alle gevallen handelen mensen vanuit een onvolledig of onjuist beeld van de werkelijkheid. Thomas Crum beschrijft dat als: Wij worden bezeten door bange gedachten over een toekomstige mogelijkheid gebaseerd op onze ervaringen uit het verleden (werkelijk of ingebeeld). En juist waar iemand een fantasie heeft waarvan hij denkt dat het echt is, daar gaat het mis. Door het onjuiste beeld gaan emoties een belangrijke rol spelen. Bij emoties val je terug Vroeger waren mensen bang voor computers. op je primaire verdedigingsmechanismen die niet door je verstand gestuurd worden. In onze huidige, geïndustrialiseerde wereld zijn die verdedigingsmechanismen (die nog stammen uit de tijd dat onze voorouders holbewoners waren) niet erg effectief. Onze overlevingsdriften nemen het over. Dat is wat FEAR zo vervelend maakt. Samenwerking Hoe ga je met de verschillende emoties om? Neem nu angst. Sommige testers leggen niet alle bevindingen vast, omdat ze bang zijn voor de reacties van de ontwerpers en ontwikkelaars. Maar die (vervelende) reacties zijn vaak ook weer gebaseerd op FEAR, een onvolledig beeld (wat is de omgeving van het systeem) of een onjuist beeld (de testers zijn er alleen maar op uit om ontwikkelaars te pesten). Een bekende misvatting is dat een informatiesysteem beter wordt door te testen. Helaas, Fouten opsporen en oplossen is veel minder leuk dan nieuwe dingen maken. testers veranderen niets aan de kwaliteit. Ze meten alleen de kwaliteit en rapporteren daarover. Ontwikkelaars verbeteren de kwaliteit. Met gebruikmaking van de informatie die zij van de testers krijgen. De juiste kwaliteit van een informatiesysteem is dus alleen maar appworks juli/augustus

18 te bereiken als de ontwikkelaars en testers samenwerken. Dan blijkt al gauw dat beide beroepsgroepen uit gewone mensen bestaan en dat je er samen best uitkomt. De angst was onnodig en de realiteit een verademing. Het kan zelfs nog gezellig worden ook! Niet uitstellen Ongeduldigheid Ik was bezig met een testprocesverbetering (gebaseerd op TPI NEXT) toen de opdrachtgever belde. Hij bleek duidelijk geëmotioneerd; hij was boos. Dat werd veroorzaakt door een andere emotie. Ongeduldigheid. Bij de start van de testprocesverbetering hadden we aangekondigd dat het testen beter en goedkoper zou worden. Helaas moet je daar eerst wat voor doen. Dus in het begin wordt het even duurder (de kost gaat voor de baat uit). De verwachting van de ongeduldige opdrachtgever was echter dat die verlaging van kosten al op korte termijn zou gebeuren. Dus bereikte hij al snel het punt van desillusie. Wij hebben de opdrachtgever toen uitgelegd wanneer wij de geplande besparingen zouden gaan bereiken. En hoeveel de besparingen daarna zouden worden. Door deze verwachtingen te managen verdween de desillusie gelukkig. Ook bleek de opdrachtgever te begrijpen dat we weliswaar sneller besparingen zouden kunnen bereiken door de ambities te verminderen, maar dat dan de totale besparingen lager zouden zijn. Door betere communicatie van onze kant is de fantasie van de opdrachtgever (het wordt niet goedkoper) omgezet in de realiteit dat we op de goede weg waren. Zoals TPI NEXT [3] het zegt: communicatie is een manier van team building. Lessen van Covey In 1989 publiceerde Stephen Covey het boek The 7 habits of highly effective people [4] en De juiste kwaliteit van een informatiesysteem is dus alleen maar te bereiken als de ontwikkelaars en testers samenwerken. Waarom zou je iets nu doen als je het ook later kan doen? Dat lijkt wel de belangrijkste reden voor Barry Böhm (emeritus professor software engineering aan de Universiteit van Zuid-Californië) om zijn Böhm-curve wereldkundig te maken. Hij beschreef namelijk al in 1979 dat als je een fout vroegtijdig vindt en oplost dat veel goedkoper is dan wanneer je dat later doet. Toch wordt er - om maar wat te noemen - nog veel te weinig tijd besteed aan vroegtijdige reviews van requirements- en ontwerpdocumenten. Dat is niet meer met goed fatsoen te verklaren door een gebrek aan kennis (iedereen kent deze theorie toch wel?). Dan moet er iets anders aan de hand zijn. Uitstelgedrag. Nu even knallen en later de brokstukken opvegen. De echt luie IT ers hebben echter al lang geleerd dat vroegtijdig reviewen op termijn heel veel (vervelend!) werk scheelt. Want fouten opsporen en oplossen is veel minder leuk dan nieuwe dingen maken. Dus vervang je uitstelgedrag door echte luiheid! En weer is een stukje fantasie (later kan het ook nog wel) vervangen door realiteit (nu even zorgen voor kwaliteit en later geen gedoe). Niet voor niets luidt een gewaardeerd Nederlands gezegde: Stel niet uit tot morgen, wat je vandaag kunt doen. De angst (voor een atoomoorlog) verbeeld naar het beroemde schilderij van Edvard Munch. 18 appworks juli/augustus 2010

19 inspireerde daarmee miljoenen mensen over de hele wereld. Ook voor testers zijn er vele wijze lessen uit te leren. Bijvoorbeeld: Begin with the end in mind. Bijna alle testmanagers die ik ken, beginnen een project met het maken van hun testplan. Ik zeg dan: FOUT. Wat is het (enige!) resultaat van testen waar de opdrachtgever echt op zit te wachten? Het testrapport. Dus als testmanager begin je met het maken van de inhoudsopgave van het testrapport. Die stem je af met de opdrachtgever. Dan sluit je precies aan bij zijn informatiebehoefte. En die informatiebehoefte is de basis voor alle volgende activiteiten. Door dus te beginnen met het testrapport kun je ook een effectiever en efficiënter testplan maken. Bovendien kun je makkelijk tussentijds rapporteren volgens dezelfde structuur. Waardoor de opdrachtgever het rapport als het ware ziet groeien en dus veel meer gerust is op het goede verloop van het testproject. Bovendien kan hij bijsturen als dat nodig is (tenslotte testen we tegenwoordig business driven ) of actie nemen naar de ontwerpers of ontwikkelaars als de testrapportage de indruk geeft dat de kwaliteit achterblijft bij de verwachtingen. Door gebruik te maken van de theorie van Stephen Covey krijgt de opdrachtgever snel de realiteit onder ogen en hoeft dus niet de angst te hebben dat hij op een laat moment verrassingen krijgt. Ook hier is de FEAR bestreden. Testersgeluk Tot slot laat ik graag geïnspireerd door Erik van Veenendaal de bij dit artikel afgebeelde grafiek van testersgeluk zien. Als een tester geen fouten vindt, dan is hij wel lekker aan het testen, maar toch niet helemaal gelukkig. Als die tester een redelijk aantal fouten vindt, voelt hij zich als een vis in het water. Wanneer het aantal fouten echter oploopt tot onverwachte hoeveelheden, dan is er voor de tester geen lol meer aan. Het testen gaat niet vlot; hij blijft bevindingen schrijven en het vooruitzicht van ontelbare hertests is ook niet prettig. Maar: als tester ben je eigenlijk wel dom bezig als je jouw geluk laat afhangen van de Source: Erik van Veenendaal Grafiek van het testersgeluk. Op de x-as het aantal gevonden fouten of dekkingsgraad, en op de y-as het geluksgevoel van de tester. kwaliteit van het systeem. Die kwaliteit heb je zelf namelijk niet in de hand. Hoe kun je als tester wel je geluk in eigen hand houden? Bijvoorbeeld door dekkingsgraad. Als tester doe je een productrisico-analyse. Op basis daarvan bepaal je (uiteraard in overleg met de opdrachtgever) welke testzwaarte nodig is om de opdrachtgever voldoende zekerheid over de kwaliteit van het systeem te geven. En vervolgens doe je als tester je best om die testzwaarte zo goed mogelijk te bereiken, door het toepassen van de juiste testontwerptechniek. Als je een techniek met te lage dekkingsgraad gebruikt, ben je wel lekker snel klaar, maar heb je toch geen goed gevoel. Als je de adequate techniek gebruikt, voel je je helemaal top en kun je bewijzen dat je effectief en efficiënt bezig bent. En als je toevallig toch een te zware techniek zou gebruiken, dan merk je aan je eigen gevoel al dat je niet optimaal bezig bent. Het gebruik van dekkingsgraad als maatstaf voor jouw geluk is dus weer een manier om FEAR te lijf te gaan. Met juiste en volledige kennis van de werkelijke omstandigheden zit je lekkerder in je vel! Aanbevolen literatuur [1] TMap NEXT voor resultaatgericht testen, 2006, Tim Koomen, Leo van der Aalst, Bart Broekman en Michiel Vroon, Uitgeverij Tutein Nolthenius, ISBN [2] Perfect Software and other illusions about software testing, 2008, Gerald M. Weinberg, Dorset House Publishing, ISBN [3] TPI NEXT Business Driven Test Process Improvement, 2009, Sogeti, Uitgeverij Tutein Nolthenius, ISBN [4] The 7 habits of highly effective people, Stephen R. Covey, Simon & Schuster, ISBN Rik Marselis is Test Strateeg bij Sogeti appworks juli/augustus

20 agile Kledingrekken blijven overeind De uitvoering van een Agile-project, om efficiënter tot werkende applicaties te komen, vereist de betrokkenheid van de business. Zoveel is wel duidelijk geworden uit presentaties van IT-dienstverleners tijdens Nextstep 2010, de gebruikersconferentie van Outsystems in Lissabon. Het Nederlandse Coolprofs, maar ook het Portugese Pessoas & Processos, hameren op de noodzaak dat de uitvoerders van bedrijfsprocessen actief meewerken aan de totstandkoming van de gewenste software. Teus Molenaar Het leek aanvankelijk een raadsel: steeds als een vrachtwagen met kleding aankwam bij de Bijenkorf in Amsterdam lag alle kleding op de vloer van het voertuig; afgegleden van de kledingrekken. TNT Express had die ervaring bij geen enkele andere klant. Tot een chauffeur bedacht dat het euvel wel eens veroorzaakt kon worden door de tamelijk hoge verkeersdrempels op het Damrak. Hij volgde een andere route en het euvel bleek verholpen. Maar de volgende dag was het weer mis: een andere chauffeur die de kortste route nam; inderdaad: over het Damrak. Een (web) applicatie waarin de chauffeurs hun ervaringen kunnen opgeven en aldus beschikbaar stellen aan collega s leek een simpele oplossing. Toch lukte het de IT-afdeling van TNT Express niet om die toepassing te bouwen. Op Nextstep 2010 vertelden Ton Koot en Joop Stringer van Coolprofs hoe zij het wel voor elkaar kregen. Met het Agile platform van Outsystems (dat Portugal als thuisbasis heeft) zijn ze aan de slag gegaan. Het betrof een stand alone systeem met ongeveer SU s (software units), gebruik makend van een MS SQL database. We hebben het precies volgens het Agile-boekje gedaan. Compleet met een workshop, sprints, demo s, aanpassingen en dergelijke. Elke dag overleg met alle betrokkenen. De business was daar vanaf het begin bij, want die had zelf om deze applicatie gevraagd. We hadden gerekend op drie sprints, en dat is ook zo verlopen, zei Springer. TNT Express gniffelde in het begin dat het ons nooit zou lukken in zeven weken, maar halverwege kwamen ze erachter dat het toch precies volgens plan zou verlopen. De applicatie met de naam GARD (Global Account Retention & Development) - is opgeleverd binnen de afgesproken tijd en budget. Het was het eerste project dat Coolprofs volgens de Agile-methode uitvoerde en de tevredenheid was alomtegenwoordig. Ton Koot en Joop Stringer geven in Lissabon hun presentatie tijdens Nextstep 2010 van Outsystems. Met de haren erbij Dat het ook heel anders kan lopen, bleek bij het volgende project dat Coolprofs onder handen nam: een applicatie voor een retail-winkelketen in Nederland. We hadden al een keer met het bijltje gehakt en dachten dat het hier ook wel zou loslopen, maakte Koot de zaal warm. Tenslotte had die gewenste applicatie slechts ongeveer SU s en moest er een koppeling komen met de CA-Gen backend, een platform dat de jongens van Coolprofs als hun broekzak kennen. Ook deze uitdaging was gepland als een drie sprints-gebeurtenis. Inmiddels is de vijfde sprint al bezig en zijn sprint 1 en 2 in de herhaling gegaan. Onze klant was de IT-afdeling. En daar blijkt de fout te zitten; je 20 appworks juli/augustus 2010