Met een Programma van Eisen geef je als opdrachtgever aan, aan welke eisen en randvoorwaarden het te ontwikkelen systeem moet voldoen. Je wilt voorkomen dat de bekende schommelkarikatuur ook van toepassing wordt op je project. Dat bereik je door te zorgen dat je zelf goed weet wat je wilt, door je eisen helder te communiceren en tevens door op tijd te controleren of alles aan je eisen voldoet.
Om de schommelkarikatuur te verslaan moet een Programma van Eisen drie basisingrediënten bevatten. Deze drie basis ingrediënten versterken elkaar en vormen gezamenlijk een ijzersterk recept.
-
Om te zorgen dat je zelf goed weet wat je wilt heb je een concreet beeld van de gewenste situatie nodig. Dat beeld moet je geleidelijk opbouwen. Het lukt je niet om dat vooraf (voordat de bouw van het systeem is gestart) in de volle breedte en met alle details te overzien.
Voor het Programma van Eisen betekent dit dat je het in delen oplevert of beter gezegd dat je het project opdeelt in kleine deelprojecten. Voor ieder deelproject stel je een mini-PvE op tijdens het voorgaande deelproject. Je begint met de kern van het systeem en bouwt dat met iedere mini-PvE verder uit. Op deze manier hoef je niet alles vooraf te bedenken, maar borduur je voort op de software die in eerdere deelprojecten is opgeleverd.
-
Om je eisen helder te communiceren aan het ontwikkelteam is tweerichtingsverkeer noodzakelijk. Dat is namelijk de enige manier om erachter te komen of je eisen duidelijk zijn en goed geïnterpreteerd worden door de ontvanger.
Voor het Programma van Eisen betekent dit dat je een groot deel mondeling overbrengt en daardoor niet alle details schriftelijk hoeft vast te leggen. Alleen informatie waarop je later terug wilt kunnen grijpen moet expliciet vastgelegd worden. Hoe vaker je mondeling contact hebt met het ontwikkelteam, hoe minder details je hoeft vast te leggen. Bovendien is het veel eenvoudiger om mondeling uit te leggen wat je wilt en hoor je meteen of je boodschap correct overkomt.
-
Om zinvol te controleren of de software aan je eisen voldoet moet je zorgen dat je ruimte hebt om bij te sturen. Het gaat er namelijk om dat je (uiteindelijk) een systeem opgeleverd krijgt dat volledig aan je wensen voldoet. Daarop controleren is belangrijk, maar alleen als er daarna ook ruimte is voor herstelacties komt het perfecte systeem dichterbij.
Voor het Programma van Eisen betekent dit dat de bijbehorende acceptatietesten vroegtijdig moeten worden uitgevoerd. Hoe eerder en hoe vaker je test, hoe eenvoudiger en minder kostbaar het is om de software aan te passen. Voer daarom niet alleen acceptatietesten aan het eind van ieder deelproject uit, maar geef ook tussentijds feedback op schermprototypen en nog in bewerking zijnde onderdelen van het systeem.
Kortom, participeren tijdens de ontwikkeling van de software is effectiever dan vooraf een omvangrijk en gedetailleerd Programma van Eisen opstellen.
Reacties
"Voor het Programma van Eisen betekent dit dat je een groot deel mondeling overbrengt en daardoor niet alle details schriftelijk hoeft vast te leggen. Alleen informatie waarop je later terug wilt kunnen grijpen moet expliciet vastgelegd worden. Hoe vaker je mondeling contact hebt met het ontwikkelteam, hoe minder details je hoeft vast te leggen. Bovendien is het veel eenvoudiger om mondeling uit te leggen wat je wilt en hoor je meteen of je boodschap correct overkomt."
Tja, ik ben persoonlijk wel een voorstander van het schriftelijk vastleggen van details. Ook kleine details die misschien niet meteen een grote impact lijken te hebben. Bij het mondeling overbrengen, schrijft de ontvangende partij (de ontwikkelaar in dit verhaal) het toch vaak vluchtig op (vaak kan hij/zij er immers niet meteen mee aan de slag) en daarmee is het risico op interpretatieverschillen groter dan dat je het eerst goed schriftelijk vastlegt en het daarna samen goed bespreekt. Regelmatig mondeling communiceren juich ik alleen maar toe en je sluit interpretatieverschillen nooit helemaal uit, maar een zo gedetailleerd mogelijke vastlegging heeft wel mijn voorkeur. Opdrachtgever en ontwikkelaar spreken veelal alles behalve dezelfde taal.
Wet u wat ik hier mis? Ik mis hier de allereerste stap. Namelijk de opdrachtgever uit te leggen Wat IT is als materie en Hoe met die materie om te gaan. Dat er nogal wat Do's en Dont's zijn en wetmatigheden waar je onderweg mee te maken zult krijgen.
Telkens zie ik hele mooie modellen worden bedacht en geimplenteerd. Zie het niet verkeerd, ik juich elk initiatief toe die fouten voorkomt in automatiseren. Maar telkens word die allereerste cruciale stap weer niet gemaakt.
Leg non IT uit hoe je tegen IT aan moet kijken, leg ze de wetmatigheden uit en geef ze voorbeelden waarom IT nu eenmaal werkt zoals het werkt als materie. Dat voorkomt veel vertraging, frustratie en bovenal, kosten.
Software ontwikkelen is erg moeilijk. De vraag is ook of iemand van te voren kan bepalen wat er gemaakt moet worden. Software ontwikkeling is een creatief proces waarbij juist de invulling nog niet vast moet staan. Onze economie gaat steeds meer uit van samenwerkingsmodellen waarbij ieder zijn specialisme kiest. Laat de IT bepalen wat er gemaakt wordt en welke technieken er gebruikt worden. Laat de business bepalen welke doelen er bereikt moeten worden. Vaak gaat er heel veel tijd verloren aan de wijze waarop de software moet werken. Maar dat is eigenlijk niet zo relevant.
Wat wel mogelijk is, en belangrijk is, is om aan te geven wat er bereikt moet worden. Software is uiteindelijk het middel. Hoe dat de doelen gerealiseerd gaan worden is vooraf niet belangrijk, wel dat ze bereikt worden.
Software is zeker geen doel op zich, maar de manier waarop de gewenste doelen bereikt worden is juist enorm belangrijk. Er kan nl. flink bespaard worden door effectieve en efficiënte processen (met de juiste vertaalslag naar software!) om die doelen te bereiken en dat maakt het belang van goede requirements engineering erg groot.
Ik krijg van de term "programma van eisen" pukkels.
Dat model gaat uit van het hardnekkige misverstand dat systeemontwikkeling een project kan zijn, deterministisch, met de eisen van tevoren vastgelegd. Het magische "eindresultaat" en de "oplevering" en "acceptatie", zijn illusies. Zowel bij maatwerk als bij commerciele pakketten. Het tegen beter weten in blijven vasthouden aan waterval- en prince2 modellen voor systeemontwikkeling zorgen al decennialang voor schade, ruzie, teleurgestelde gebruikers en enorme verspilling van belastinggeld.
Laten we nu voor eens en voor altijd eens gaan accepteren dat systeemontwikkeling een researchtraject is. Dat alleen op hoofdlijnen het einddoel kan worden vastgesteld bij aanvang. In business termen, en in architectuur. Resultaat komt alleen met incrementeel werken, steeds 2 stappen vooruit en vaak 1 achteruit, met kleine stappen op basis van voortschrijdend inzicht, en met een continue wisselwerking tussen gebruikers en ontwikkelaars.
Kortom: richt je energie op de inrichting van het proces, in plaats van proberen vast te leggen wat niet vastgelegd kan worden.
Bewijs te over, lees de boeken over bijv. agile ontwikkelen er maar op na.
(Op persoonlijke titel)
Ik krijg last van flink kromtrekkende tenen als ik sommige reacties belees. Het is mij duidelijk dat er mensen zijn die compleet de plank mis slaan waar het het gebruik en de toepassing van IT betreft.
@ Remko Heethuis
'Software ontwikkeling is een creatief proces waarbij juist de invulling nog niet vast moet staan'?
Are you kidding me? Elk proces in IT, elke stap van de materie IT, om tot een volgende stap of doel te komen, is volkomen afhankelijk van een toegekende waarde. Zonder een duidelijk doel te omschrijven, die voldoet aan gegeven waarde, welke dat ook mogen zijn, is er geen ontwikkeling mogelijk.
Sec gesteld, je zult van tevoren helder moeten krijgen wat de klant verwacht, en de vertaalslag moeten maken naar de processen waarmee je de klant gaat ondersteunen. WELK dat proces dan ook moge zijn. IT bepaalt niets. IT is een dode materie. IT kan alleen maar worden aangewend de mens met geautomatiseerde processen ten dienste te staan en een duidelijk 'NUT' te bereiken. Anders heeft het aanwenden van IT geen zin.
@ Ralf Thissen
U stelt het in enkele regels volkomen juist. Software is een middel maar geen doel op zich in het geheel. Dat is voor de software ontwikkelaar, vanuit diens perceptie ietwat anders. Die moet namelijk, gebaseerd op requirements aangegeven door de klant, dat zien te realiseren.
@ Michel Steltman.
Horror. U stelt, tenminste, klaarblijkelijk Agile ...., dat het een misverstand dat systeemontwikkeling een project zou zijn. U heeft het over termen als 'magisch eindresultaat', dat oplevering en acceptatie een illusie zouden zijn.
Eens even zien hoor. De klant heeft een aantal requirements. Er word gekeken of dat in software te vervatten is en of dat 'NUT' heeft. Dan vervolgens bekijkt een systeem ontewikkelaar het FO en TO en maakt er een plan voor. (Tenminste een goed professional wel...) Die doet een voorstel aan de klant en dan word er een beslissing genomen.
Lees hier even, de software ontwikkelaar geeft aan hoe lang die nodig denkt te hebben tegen welk budget. (Zou dat anders zijn, zou ik de eerste zijn die dat project af schiet...) Dan gaat de software ontwikkelaar aan de slag. Daar komt vervolgens een teste een keer aan te pas. Los even of de ontwikkelaar dit zelf doet of niet. Dan als laatste komt de klant testen.(Oplevering)(End user test). Dan is het aan de klant dit product te 'Accepteren'.
Even kijken of ik begrijp hoe IT als materie werkt hoor. FO/TO, ontwikkelen, testen, opleveren, accepteren. Ja, ik geloof dat ik alles heb. Oh nee, een 'handig element'ontbreekt. De Civile Matrix.
Elke systeem ontwikkelaar die mij probeert te verkopen dat zij/hij niet binnen een project kan werken, via vastgestelde projectkaders, mag van mij naar huis. Die mag andere dingen gaan doen.
Als u nieuwe dingen wil ontwikkelen dan gaat u maar op zoek naar budgetten of investeerders, lees durfkapitalisten. Want als u denkt dat ik zakelijke budgetten ter beschikking stel voor een traject met een open eind, dan wens ik u in elk geval zeer veel succes.
Voordat je tot een programma van eisen kan komen, ligt er een heel traject voor. Alleen dan kan je tot een stabiel programma van eisen komen. Te vaak wordt aangegeven dat het pve zalig makend is, dat is net niet helaas. Het is wel een efficiënte methode om achteraf een "schuldige" aan te wijzen. Dat draagt echter nooit bij aan een oplossing, want diezelfde mensen zullen daar weer juist aan moeten bijdragen.
Blijft de vraag tot op welk abstractie niveau je in een pve iets moet specificeren.
pve, architectuur, creatief ontwerpen, research trajecten ... zullen we eens beginnen met een portie GBV, ofwel Gezond Boeren Verstand?
Zelfs aan de kleinste software ligt een ontwerp ten grondslag. Misschien niet altijd uitgeschreven, maar normaliter wel in de hoofden van de makers.
Hoe groter en complexer het software-pakket wordt (noem het voor mijn part een "systeem"), hoe meer je hierover na zult moeten denken. En zeker wanneer je gaat samenwerken met meerdere partijen moet je ook iets vast gaan leggen en communiceren.
En of je dat nu incrementeel doet of stapsgewijs hangt helemaal af van hetgeen je maakt.
Vergelijk het een beetje met bouwen: voor het bouwen van een plantenbak van wat oude stenen en cement heb je waarschijnlijk genoeg aan je creatieve geest.
Maar ga je een huis bouwen, is het toch wel handig te bedenken hoeveel verdiepingen je wil, voordat je je fundering gaat storten en de dragende muren gaan definiëren.
Binnen de muren heb je meer creatieve ruimte om te ontwerpen, zolang je maar afstemt waar bijvoorbeeld leidingen en afvoeren komen. Het is niet zo handig als je de wc aan de voorkant maakt, en de loodgieter de afvoer aan de achterkant heeft, toch? Echter, doe je alles zelf, dan zal er minder afstemming nodig zijn.
Je "eisen" zullen specifieker worden naarmate het bouwen volgt, maar er komt op een gegeven moment een "point of no return", waar het schier onmogelijk wordt nog dingen te veranderen (of tegen een gigantiesche meerprijs). Bij het verven van de plinten bij wijze van spreken bedenken dat je toch liever 3 verdiepingen had in plaats van een bungalow wordt toch heel lastig om nog te realiseren
GBV, gecombineerd met "bezint eer ge begint" klinkt misschien niet zo formalistisch maar voorkomt minstens zoveel problemen
Allereerst is dit gewoon een gedegen opinie waar ik me in kan vinden. De reacties vind ik echter het leukst om op te reageren.
30 jaar geleden schreef ik mijn eerste software (ben nu 41), en het ontwikkelen van software doe ik nog steeds al worden de teams steeds groter en de oplossingen internationaler. Dit om aan te geven dat ik veel heb meegemaakt in software ontwikkeling.
Veel reacties zijn sterk in hun eigen context en worden buiten hun context slecht begrepen waardoor de reacties zo fel zijn (maar wel op de bal, ofwel on topic en dus prima).
Overigens raakt PaVaKe wel de kern. Iedere ontwikkeling van software is anders. Soms wordt software ontwikkeld (ook voor bedrijven) maar staat daar alleen een basisgedachte aan ten grondslag. Hier komt dan het SaaS adagium uit voort waar Michiel het volgens mij over heeft.
1) Software is niet af bij oplevering
2) Breng iets snel live en verbeter het nagelang feedback en gebruik
Voor het automatiseren van een bedrijfsproces vlieg je dit echter heel anders aan en heb je inderdaad te maken met eisen en wensen van opdrachtgevers, of dit nu intern of extern is.
Wat je tegenwoordig veel ziet is dat er in het begin van het proces al een interactief ontwerpen of UX specialist bij wordt gehaald waarna er visuals gemaakt worden.
Dat er nog steeds zoveel mis gaat bij software ontwikkeling is de totale desinteresse van project managers / business managers voor alles wat ruikt naar techniek. Zelfs het doorgronden van de architectuur of de modellen gaat ze al te ver en dat is dus punt 2 en 3 uit dit artikel.
Wat ik ook zie is dat er een heel functioneel ontwerp gemaakt wordt welke naar de ontwikkelaars gaat. Specs lezen, begrijpen, opdelen in stukjes en hieruit een logische volgorde creeren is gewoon erg pittig en is niet iedere ontwikkelaar gegeven om dit te kunnen.
Software ontwikkelen is net als koken. Je kan de instructie en de ingredienten hebben, maar er moet vooral liefde in gestoken worden voordat het echt lekker smaakt.
Mijn aanpak en visie is dat je verhaaltjes beschrijft en daaruit maak je model van het domein in taal die iedereen snapt. Geen UML of alleen grafische modellen, maar gewoon een beschrijving geven met visuele ondersteuning. Van daaruit bouw je een datamodel (relationele tabellen) en hier kun je nog lekker over filosoferen en testen of dit je scenario’s kan bevatten.
Als je datamodel goed is heb je gewoon duurzame basis voor software waar je jarenlang tegenaan kan plakken voordat het legacy wordt. Denk daarnaast in webservices, ook intern. Voordeel is dat je browser, desktop software en apps kunt bouwen in allerlei talen en integratie vergemakkelijkt. En de logica en validatie kun je centraal houden.
@schrijver e.a.
Dat mondelingen uitwisseling van requirements het beschrijven (deels) overbodig maakt is iets waar ik als ontwerper/beheerder ernstig tegen moet ageren.
Als software eenmaal in bedrijf is genomen, verandert de wereld om ons heen. En mogelijk is dat tijdens ontwikkeling al een beetje gebeurd. Als beheerder wil ik graag kunnen beschikken over een compleet overzicht van requirements. Hoe kan ik anders bepalen of iets een fout of een wens is? Vergeet niet dat de ontwikkelaars een keer weggaan, de kerngebruikers een keer weggaan en ons aller geheugen ons een keer in de steek laat.
Hoewel we ons van Numoquest overbodig moeten maken als IT-er worden we het nooit. Problemen moeten opgelost: daarvoor heb je requirements nodig. Veranderingen moeten geassimileerd worden: voortborduren op vastgelegde requirements en basisideeën houdt het systeem over het algemeen beheer(s)baarder.
Het alternatief is bij elke vraag van de gebruiker re-engineeren wat ooit de bedoeling geweest kan zijn ten koste van veel tijd.
Kortom, leg zoveel mogelijk vast voor diegenen die na ons komen!
Nee brombeer,
Documenteren en vastleggen heeft een zeer slechte business case en is gewoon verspilde moeite. Ik documenteer veel omdat het een vereiste vaak is. Maar ik stop in *al* mijn documentatie woord grapjes en de belofte van gebak als je mij een e-mail stuurt. Ik heb nog *NOOIT* gebak hoeven brengen.
Documentatie moet vanzelf ontstaan en terugvindbaar zijn. Een soort logisch gevolg van communicatie. Maar het vastleggen om het vastleggen is redelijk zinloos.
Belangrijke mensen in het proces/software wat je beheerd hebben vaak wel de kennis of kunnen je in de juiste richting wijzen.
Brombeer zeg nu eens eerlijk: Zo te horen heb je vaak bij gebruikers moeten re-engineeren wat ooit de bedoeling was. Heb jij dat toen netjes gedocumenteerd? En heeft ooit iemand dat gebruikt? Wel eerlijk zijn heh!
De praktijk is dat het re-engineeren af en toe minder kost dan alles achteraf te documenteren met de grote kans dat het toch weer achterhaald is. Kennis moet organisch ontstaan (gecodificeerd of personaliseerd), kunstmatig pielen omdat het moet... ik geloof er niet in.