Softwarespecificaties zijn vaak vaag, inconsistent en ze bevatten fouten. Hierdoor ontstaat een cultuur waarin programmeurs systemen bouwen naar eigen inzicht en steeds minder acht slaan op softwarespecificaties. Dat leidt tot een enorme verspilling van programmeerinspanningen en een slechte software-architectuur. Dat zegt hoogleraar Jan Friso Groote van Technische Universiteit Eindhoven.
Hij leidt daar de faculteit Systeemontwerp en is gespecialiseerd in de softwareveiligheid van ingebedde systemen.
'Een voorbeeld van een vage omschrijving is: de software moet gebruiksvriendelijk zijn', vertelt Groote in een vraaggesprek met Computable. 'Daaruit kan een programmeur niet opmaken of hij een bepaald edit-veldje wel of niet moet aanmaken, hoe competent hij ook is.'
Hak- en breekwerk
Hierdoor ontstaat volgens Groote 'een cultuur waarin programmeurs systemen bouwen naar eigen inzicht en steeds minder acht slaan op softwarespecificaties. Dat leidt tot een enorme verspilling van programmeerinspanningen en een slechte software-architectuur.'
Hoe inefficiënt die werkwijze is, illustreert Groote aan de hand van een metafoor: 'Stel je de bouw van een huis voor aan de hand van een onduidelijke schets. Stel je voor dat de aannemer desondanks begint met de bouw van het huis. Het gevolg: hak- en breekwerk, omleggen van leidingen, de constructie van extra steunpilaren. Kortom: enorme vertragingen en een gebrekkige architectuur.'
Software verificatie
Goede softwarespecificaties zijn volgens Groote essentieel bij het voorkomen van programmeerfouten: 'Wat wil je dat de software wel doet, en wat juist niet?' Andere hulpmiddelen zijn het testen van software door het geautomatiseerd analyseren van een vereenvoudigde model van de software. Ook softwareverificatiesystemen zouden volgens de hoogleraar vaker moeten worden gebruikt.
Interview Jan Friso Groote
Lees het interview met hoogleraar Jan Friso Groote: 'Softwaretests zijn niet afdoende'
Grappig artikel, geen idee waarom dit “Nieuws” is en of deze uitspraak op basis van een onderzoek gedaan wordt/is. Sterker nog, het ontbreekt aan enige vorm van inhoud.
Verder zou ik graag eens met deze hoogleraar willen discussiëren waarom Agile een prima methode is om verspillingen te reduceren én waarom Agile wel degelijk geschikt is om onder architectuur te werken.
@ Jan Friso
Ik vermoed dat U iets tegen “Agile” heeft.. Laten we gewoon 20 jaar terug gaan en het woord “Agile” bestond nog niet. Ik zou dan het “effectief werken” noemen (of zoiets als EW om t catchy te maken) als ik er een naam aan mocht geven.
Mijn vraag dan aan U: Wat zijn argumenten tegen effectief werken?
Specificaties worden vaak in tekstuele zin uitgewerkt. Dit leidt tot dikke boekwerken waarvan menigeen begint te gapen, maar ook tot tekstuele specs die mijlenver van de uiteindelijke software af staan. Tekstuele specs leiden tot de illusie van overeenstemming tussen opdrachtgever en opdrachtnemer: men denkt overeenstemming te hebben over wat er ontwikkeld gaat worden, maar men heeft slechts overeenstemming op een zeer hoog abstractieniveau. Gevolg? De uiteindelijke software voldoet in geen velden of wegen aan de verwachtingen van de opdrachtgever.
Wij hebben het uitschrijven van specs helemaal het raam uitgegooid en maken nu in plaats daarvan gedetailleerde schermontwerpen. De opdrachtgever (en eindgebruikers binnen de klantorganisatie!) kunnen dan in de startfase van projecten al zien wat ze aan het eind van de rit kunnen verwachten. Overleg en finetuning van de software vindt plaats in de ontwerpfase. Hierdoor wordt de hoeveelheid hak- en breekwerk tot vrijwel nihil teruggebracht. Ook leidt het tot simpeler en betaalbaarder software. En daar houden wij en onze eindgebruikers van!
@Gerwin
Ik ben als projectmanager niet anders gewend.
Sterker nog: in de 90-er jaren deden wij dit al (toen met een flipover), nu met beamer en screenshots van de beoogde nieuwe applicatie.
Liever in het begin goed overleg met de eindgebruikers en de opdrachtgever, dan achteraf bakkeleien over extra werk (en dus kosten). Kunst is natuurlijk wel om de juiste groep op de tafel te krijgen, het management kan namelijk heel andere ideëen hebben dan de daadwerkelijke gebruikers.
Verder is het natuurlijk nodig de programmeurs de vrijheid te geven om bij vragen en onduidelijkheden te laten praten met de opdrachtgever/eindgebruiker en deze kennis binnen de groep te laten delen. In mijn geval is het dan de lead-architect die op dit niveau contacten onderhoudt met de klant en de uitkomsten van het gesprek aan mij als projectmanager terugkoppelt. Ik beslis dan of e.e.a. binnen de scope van het project valt of dat ik op (hogere niveau) in overleg met de opdrachtgever een beslissing ga nemen.
Een grotere open deur om in te trappen kan ik mij als tester nauwelijks of niet voorstellen. Ik sluit mij daarom geheel en van harte aan bij de eerste vier reacties.
Ik ben voorstander van Agile, met name SCRUM en XP, deze zijn niet perfect. En net als democratie is het op dit moment de beste oplossing.
Bij Volmac mochten we (eind jaren 70) pas gaan programmeren wanneer we de specificatie hadden begrepen. Dan bouwden we tenminste het goede programma. Een gedegen programmeer-opleiding bevorderde dat de programma’s ook nog goed gebouwd werden.
Niet alleen de programmeur moet de specificatie begrijpen; de tester(s) en de applicatiebeheerder(s) en soms nog de helpdesk, moeten hem ook begrijpen. Reviewen deze partijen systematisch samen de specificaties dan zijn we al een eind op weg naar goede programmatuur.
Alle waar is naar zijn geld: hoeveel tijd en moeite (geld, dus) wil een opdrachtgever steken in softwarekwaliteit?
In het artikel is sprake van prototype-verificatiesystemen (PVS) die maar niet van de grond komen omdat het zo duur is om die te ontwikkelen. Wees gerust: als het een goed idee is ontstaan ze wel in het open source-circuit – gratis, als hobbywerk.
Het hele artikel gaat over de vraag waarom ICT de business niet begrijpt. Desondanks heb ik niet 1 keer ‘functioneel ontwerper’, ‘informatie analist’ of ‘business analist’ horen vallen, terwijl deze functies toch in het leven geroepen zijn om te dienen als schakel tussen business en ICT.
Veel bedrijven en mensen lopen duidelijk mijlenver achter als ze daadwerkelijk denken dat een projectmanager of een architect deze rol wel ‘even’ vervult. Het is een specialisme en gelukkig zijn er steeds meer bedrijven die dit ook beseffen.
Ik snap de relatie met agile in bovenstaande reacties niet. Ook met Agile programmeren (in Scrum en XP) moeten er specificaties worden opgesteld door een business analist. Alleen gebeurt dat dan in hetzelfde agile proces.
@Schakel tussen business en ICT: Ook business analisten kunnen vage, inconsistente specs opstellen. Ik werk nu al bijna vijf jaar op een project waar niet anders gebeurt. 🙁 (en dit ligt niet alleen aan de analisten, maar aan de hele organisatie die niet weet wat ze wil en geen verantwoordelijkheid durft te nemen).
Softwarespecs zijn vaak net zo vaag als dit artikel. Ik zie namelijk niet wat de nieuwswaarde is van iets dat ik al vanaf 1997 in de ICT branche ervaar. Ik had liever ook iets over de oorzaken van het vaag en inconsistent zijn van softwarespecs willen lezen. Wat is de rol van de verschillende partijen, dus ook de gebruiker, hier in? Hoe voorkom je dat er te weinig of te veel beschreven wordt? Dit zijn belangrijke vragen waar geen antwoord op gegeven wordt. Maar ja, dan moet je wel de praktijk gaan beschrijven. Universiteiten zijn nu eenmaal onderzoeksinstellingen waar vaak van een theorie uit wordt gegaan, waardoor ook dit soort artikelen weer vaag blijven.