Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Fouten in de requirements kost kapitalen

18 juli 2012 - 12:274 minuten leestijdOpinieSoftware & Development

Slechte requirements kosten ‘zakken met geld’. Denk alleen maar eens aan herstelkosten, extra inhuur van medewerkers, uitloop of stopzetten van projecten en juridische procedures.

En hoe later in de ontwikkeling van een product een fout wordt ontdekt, des te duurder is het om deze te herstellen. Tot wel duizend maal meer wanneer een fout pas wordt gevonden in productie. Deze wetmatigheid werd al in 1978 aangetoond door Barry W. Boehm.

Maar zonder harde cijfers zijn managers vaak moeilijk te overtuigen om meer aandacht en prioriteit te geven aan het opstellen en toetsen van requirements. Zeker in tijden van crisis. Probleem is echter dat er vaak geen harde cijfers bijgehouden worden voor projecten in de eigen organisatie.

Om de kosten van slechte requirements toch snel inzichtelijk te maken hebben Tom King en Joe Marasco, op basis van heel veel data en statistieken uit de praktijk, een formule ontwikkeld voor software projecten (in een traditionele ontwikkelomgeving). Deze formule berekent wat het gemiddeld kost om één fout in de requirements te herstellen, die pas wordt ontdekt tijdens de systeemtest en/of acceptatietest.

Deze formule bestaat uit de volgende 6 stappen:

A.
Schat de hoeveelheid zuivere ontwikkeltijd- en kosten in, dus zonder herstelwerkzaamheden, projectmanagement en/of analyse tijd. Een vuistregel die je hiervoor kunt gebruiken is: Vermenigvuldig het totaal aantal verwachte schermen en rapportages in het eindproduct met vier werkweken (= ontwikkeltijd in weken) en vermenigvuldig dit met de gemiddelde weekkosten van één lid van het ontwikkelteam (= ontwikkelkosten).

B.
Schat het aantal verwachte gebreken in tijdens de testfase. Uit onderzoeken blijkt dat je gemiddeld voor elke week ontwikkeltijd één gebrek kunt verwachten. Kortom, het aantal te verwachten gebreken is gelijk aan de ontwikkeltijd in weken (= A).

C.
Schat het aantal gebreken in dat zijn oorsprong heeft in de requirements. Ga daarbij uit van tenminste de helft van al je verwachte gebreken (= 0,5 x B), want uit onderzoek van James Martin blijkt dat 56 procent van alle gebreken in software zijn oorsprong heeft in de requirements.

D.
Schat de kosten in voor herstelwerkzaamheden. Een vuistregel is dat projecten 30 procent van hun zuivere ontwikkelkosten (=A) nodig hebben voor herstelwerkzaamheden, ongeacht de oorsprong van de gebreken.

E.
Schat de herstelkosten in voor fouten in de requirements. Het herstellen van gebreken die hun oorsprong hebben in de requirements kost vaak meer dan andere gebreken. Uit onderzoek van o.a. het Chaos Report blijkt namelijk dat zij ergens tussen de 70 en 85 procent van de totale herstelkosten (=D) voor hun rekening nemen. Reken dus tenminste met 75 procent..

F.
Bereken nu de kosten voor één foutieve requirement, door de herstelkosten voor foutieve requirements (= E) te delen door het aantal foutieve requirements (=C ).

Een rekenvoorbeeld: Voor een project dat een applicatie ontwikkelt dat bestaat uit 25 schermen en rapportages en waarvan de gemiddelde weekkosten van een ontwikkelaar 2500 euro bedragen, zullen de totale herstelkosten voor vijftig fouten in de requirements zo’n 56.250 euro bedragen (op een bedrag van circa 250.000 euro aan zuivere ontwikkelkosten). Oftewel, in dit rekenvoorbeeld zal elke fout in de requirements die je pas ontdekt tijdens de testfase 1125 euro kosten (en later zelfs nog meer!).

Met deze formule kun je voor managers per project uiteindelijk heel concreet maken wat bij benadering de kosten zullen zijn van fouten in de requirements die je pas tijdens de testfase ontdekt. En dat dit dertig tot zeventig keer meer is dan wanneer je ze ontdekt voordat je begint met het bouwen van de applicatie.

Investeren in goede trainingen, processen en extra tijd voor het opstellen en vroegtijdig toetsen van requirements kost geld. Maar deze kosten zijn een fractie van de kosten voor het herstellen van slechte requirements die pas laat ontdekt worden.

Of met andere woorden,
“If you think good requirements are expensive, try bad requirements!”
(Analoog aan Joseph Yoder over architectuur)

Reacties zijn welkom!

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Staat van Digitale Connectiviteit binnen de Bouw- en Installatiebranche 2025

    Digitale connectiviteit is de kern van veel processen in de bouw en volgens insiders van strategisch belang voor de toekomst van de sector. Waar sta jij?

    Computable.nl

    Design Sprints: 4 dagen van idee naar prototype

    Hoe zet je in vier dagen tijd een gevalideerd prototype neer met Design Sprints?

    Computable.nl

    Resultaatgericht Samenwerken (RGS).

    RGS is een gestructureerde methode die vastgoedprofessionals direct ondersteunt bij kwaliteitsverbetering, kostenefficiëntie en verduurzaming.

    Meer lezen

    ActueelData & AI

    Europese beurzen voor grensverleggend UvA-onderzoek in it

    AchtergrondSoftware & Development

    License to bill

    AchtergrondData & AI

    Ai-bedrijf Braincreators stelt de mens weer centraal in nieuwe koers

    ActueelSoftware & Development

    Europese tech hongert naar Navo-orders

    ActueelOverheid

    Gemeente Breda verruilt Centric voor Unit4

    ActueelSoftware & Development

    Kort: Elastique op Sri Lankaans avontuur, Panasonic helpt The AA, Main koopt Carwise-duo (en meer)

    13 reacties op “Fouten in de requirements kost kapitalen”

    « Oudere reacties
    1. willem oorschot schreef:
      23 juli 2012 om 11:01

      @PaVaKe

      http://nl.wikipedia.org/wiki/Agile-software-ontwikkeling

      Agile is al een aantal jaren bekend als ontwikkel methode. Je spreekt dan van een iteratie die een bepaalde tijd doorloopt, na die tijd stop je en weet je wat je hebt verbruikt in termen van budget. Je hebt dan binnen een bepaalde tijd bijvoorbeeld een interface gebouwd of een front end of een bedieningsinterface en zo rijg je de applicatie aan elkaar. Je kunt bij iedere iteratie andere mensen inzetten om de kennis optimaal in te zetten en weinig tijd te verspillen aan training, je zet mensen in die iets kunnen op dat gebied, ipv het inzetten van generalisten die iedere stap in het proces moeten onderzoeken.

      Agile wordt heel veel toegepast, je ziet dat ook bij professionele organisaties, ik denk dan aan de Apple IOS software. Voor elke versie worden de requirements opgesteld en ontwikkeld en soms wordt er al een beetje vooruit ontwikkeld. Een iOS release duurt ongeveer een jaar en in dat jaar wordt er agile ontwikkeld. De projectleiding neemt het besluit of iets er wel of niet inkomt. Zo zie je dat je start met Siri, in de volgende release komen er meer talen bij en de nieuwe release nieuwe functionaliteit.
      Als je start met de waterval methode en de uitgebreide requirements analyses en fouten en dergelijk dan zou je pas na 2-3 jaar een nieuw product hebben, als je geluk hebt. Dit is de Microsoft aanpak, die nu aan het coderen zijn voor Offic 2013 op basis van requirements van 2009, als de versie uitkomt mis je altijd functies die dan al heel gewoon zijn en door andere applicaties worden gebruikt.

      Ik ben ook principieel tegen het managen van foute code. Waarom ga je niet uit van in een keer goed programmeren? Dus een goed(e) programmeurs, een goed Framework kiezen, denk hierbij aan Spring software of Ruby on Wheels en niet aan .Net en start met je agile development op basis van enkele goed gespecificeerde requirements en een principe kader. Het principe kader beschrijft de generieke uitgangspunten en ontwerp criteria. Je kunt natuurlijk ook kiezen voor een applicatie die je kunt configureren, zoals Siebel of Sharepoint en deze verrijken met plugin’s of add-on applicaties. Nog moderner is het om app based te gaan programmeren, dus je gaat ervan uit dat de applicatie bestaat uit een aantal app’s, hiervoor gebruikt je dan Android en IOS als framework en daarbij hoef je nog maar een klein beetje te programmeren. (in verhouding)

      Beginnen met “Plain Vanilla” coding en hele lijsten met requirements die vaak open deuren zijn en dan ook nog eens uitgaan van fouten, dat lijkt mij niet meer van deze tijd.

      Login om te reageren
    2. PaVaKe schreef:
      23 juli 2012 om 19:26

      @Willem

      Dat is helaas geen antwoord op mijn vraag …
      Om een misverstand te voorkomen: mijn doel is niet om agile te verdedigen noch aan te vallen.

      Wat ik me afvraag is wie de verstookte uren uiteindelijk bekostigt als requirements na 4 weken werk toch afgewezen worden.

      Login om te reageren
    3. Mirjam van den Berg schreef:
      6 augustus 2012 om 13:15

      Allereerst iedereen hartelijk dank voor voor het lezen van en reageren op dit artikel.
      Mij vallen 2 zaken op in de reacties:

      1) Een aantal mensen zet vraagtekens bij de vuistregel(s)zelf. Uiteraard zijn er altijd uitzonderingen te bedenken voor de eigen specifieke omgeving. Zijn bepaalde parameters in de formule te veel/te weinig? Geen probleem. Pas de formule gerust aan obv je eigen statistieken (en of inschatting) en het kostenplaatje wordt alleen maar realistischer. Daarvoor is het immers een vuistregel. Belangrijkste is om aan te tonen dat fouten in de requirements veel geld kosten.

      2) En dat brengt me gelijk bij het tweede punt. Wanneer is iets nu een fout in de requirements? Daarover kun je soms idd discussieren. Maar requirements die ruimte laten voor (foutieve) aannames en interpretieverschillen vallen daar wel onder. En hierbij geldt voorkomen is beter dan genezen. Requirements laten toetsen door collega’s (peer review) is niet voldoende. Een multidisciplinaire toetsing, liefst via een zgn. Fagan-inspectie, waarbij de requirements hardop voorgelezen worden, is het meest effectief om interpretatieverschillen tussen stakeholder, analist, ontwerper, bouwer, tester, etc…, te ontdekken.

      Tot slot, @Maarten: een soortgelijke formule voor infrastructuur is mij helaas niet bekend.

      Login om te reageren
    « Oudere reacties

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Uitgelicht

    Partnerartikel
    AdvertorialInnovatie & Transformatie

    Computable Insights

    Een ai-agent die klantvragen afhandelt. Dat is een van de nieuwste troeven van softwareproducent Salesforce, dat daarmee meesurft op de...

    Meer persberichten

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs