Managed hosting door True

'Softwarespecs zijn vaak vaag en inconsistent'

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'

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

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.

Communicatie is the name of the game. Helaas worden de specificaties meestal overgelaten aan ICT-specialisten en niet aan de materiedeskundigen. Dat was al zo in de 60'er jaren, en als we niet veranderen zal dat in de 60'er jaren van deze eeuw nog steeds zo zijn!

Hoewel al oud nieuws is www.computable.nl/artikel/ict_topics/overheid/2998823/1277202/architecten-terug-naar-de-blokkendoos.html - 69k - 2009-07-21 nog steeds actueel . . . communicatie nietwaar . . .

Een beetje een open deur die de schrijver van dit artikel intrapt.
Mijn ervaring is dat een een iteratieve aanpak - een gulden middenweg tussen gewoon maar beginnen te bouwen en alle specificaties uitgekauwd hebben voordat je dat doet - heel goed kan werken.
Ik werk momenteel als senior ontwikkelaar in een team en wij volgen de OpenUp methodiek. Hoewel niet zaligmakend, werkt dit voor ons heel goed: business analisten schakelen met de business, wij ontwikkelen iets dat na enkele weken gereed is voor "user preview". Door de dagelijkse standup vergadering, iteraties van drie weken en een duidelijk focus op de te implementeren functionaliteit per iteratie, leidt dit tot goed werkende software, die goed aan de verwachtingen voldoet.

Begrijpend lezen (zoals je specs zou kunnen lezen) lijkt moeilijk:

- ik zie in het hele artikel geen woord over agile, noch over watervalmodel, dus een deel van de reacties kan ik niet plaatsen
- de heer Groote is gespecialiseerd in embedded systems. De toegevoegde waarde van "gedetailleerde schermontwerpen" is ver te zoeken als je op basis van een positiebepaling moet kijken of je een motor harder of zachter moet laten draaien bijv.

Wat overigens niet wegneemt dat een gedetailleerd schermontwerp vele malen duidelijker kan zijn dan 3 pagina's tekst die beschrijven welke knop waar moet zitten. Voor de gebruikersinterface van een embedded systeem kan dit zeer bruikbaar zijn.

En of agile de heilige graal is... zoals iedere sector heeft ook de embedded sector zijn kenmerken, waardoor je je af kunt vragen of agile in pure vorm toepasbaar is:
- korte sprints is leuk, maar wat nu als je afhankelijk bent van hardware \ embedded borden etc met ontwikkel- en levertijden van enkele maanden?
- snel iets aan de klant laten zien lukt wellicht nog net, maar als je aan allerlei ISO- en andere normen moet voldoen voor bijv. Automotive, luchtvaart of medische sector dan kun (en wil) je echt niet iedere maand nieuwe functionaliteit leveren

Moraal van het verhaal: doe wat je moet doen, maar zorg ervoor dat je al vanaf punt 0 met een zo tastbare mogelijke versie van het eindproduct aan de slag bent!

iets te snel op "plaatsen" gedrukt:

- afhankelijk van de sector zul je toch de nodige documentatie op moeten leveren, of je dat nu overhead vind of niet. Om medische apparaten te mogen leveren in bepaalde landen, zul je aardig wat papieren moeten overleggen. Daar gaat Agile geen verandering in brengen

Wat overigens niet wegneemt dat Agile geen bruikbare elementen kent voor de embedded sector. User stories, de planningstechnieken, standup meetings etc. zijn goede gebruiken, die algemeen toepasbaar zijn

Al met al blijft het dus aan rommelen, of het nu Agile is of spelen met schermpjes, er is de laatste jaren niets veranderd, erger nog het lijkt alleen nog minder te worden. Over functionals of non-functionals wordt niet gesproken, laat staan over SW architectuur en al de daarbij behorende kwaliteitseisen. Het duurt nog even voordat we het stadium van volwassenheid hebben bereikt in SW Engineering.

@Emiel van der Linden
Zeker niet naar de auteur van dit artikel gekeken.
Dan had je vooraf geweten dat dit weinig aan inhoud zou bevatten.
De paar opmerkingen van ir. K.E. van Zanten hadden van het artikel nog enige kwaliteit kunnen geven.

@PaVaKe
Onder aan het artikel staat een link naar http://www.computable.nl/artikel/ict_topics/development/3815004/1277180/softwaretests-zijn-niet-afdoende.html. Hierin wordt gesproken over waterval en Agile.

Dit artikel bespreekt de problematiek van informatie overdracht tussen verschillende afdelingen. Mijn opmerking is daarom "overkoepelend" bedoeld.

@Pascal
Ik vind het ontzettend jammer dat dit soort non-artikelen gepubliceerd worden...

@MG
'er is de laatste jaren niets veranderd, erger nog het lijkt alleen nog minder te worden.'
Ik zou je graag willen uitnodigen om eens te laten zien wat de mogelijkheden zijn en hoe wij (ik noem het bedrijf waar ik werk bewust niet) daar mee om gaan.

Algemeen
Een non-functional requirement als 'de software moet gebruiksvriendelijk zijn' inderdaad redelijk vaag, je wil juist dat requirements SMART zijn. Daarover leg je je afspraken vast in binnen de architectuur.

@PaVaKe

"Om medische apparaten te mogen leveren in bepaalde landen, zul je aardig wat papieren moeten overleggen. Daar gaat Agile geen verandering in brengen"

Doel je op verplicht CMMi niveau 3 in de US als het om de medische sector gaat? (kort door de bocht)

Misschien dan een leuke info: CMMi & Agile wordt al gecombineerd. Ook ISO- en andere normen kunnen meegenomen worden als de opdracht daarvoor wordt gegeven. Ik heb (nog) niet ingezoomd op voorbeelden van successen en failures. Ik verwacht het gene van jij zegt betreft Agile & de embedded sector "User stories, de planningstechnieken, standup meetings etc. zijn goede gebruiken, die algemeen toepasbaar zijn."

@Tester:

zover ik weet is CMMi Level 3 geen verplichting.

Ik doel meer op documentatie veresiten vanuit instanties als FDA en KEMA, ISO certificeringen en IEC normen (bijv. IEC62304).

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.