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'
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 http://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 https://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).