Softwarerot ± feit of fictie?

Aan het einde van het jaar is het tijd om een ludiek verschijnsel op de korrel te nemen: SoftwareRot. Wat zullen we nu krijgen! zie ik jullie denken. Software is geen fruit dat zomaar kan gaan rotten. Dat is ook zo, maar SoftwareRot bestaat echt! Het is aan het einde van het jaar een goede gelegenheid om hierover te bloggen, temeer omdat het verschijnsel wel steeds zeldzamer wordt, maar nog steeds niet geheel is uitgestorven.. Hoe kun je SoftwareRot zien? We hebben hier te maken met een subtiel verschijnsel, dat slechts door nauwkeurige en langdurige observatie is op te merken. We kunnen er van uit gaan dat software na de oplevering nog enkele software fouten bevat. En om die gaat het nu juist. Wat hebben wij daarvoor nodig: 1. Software, die na in productie name niet meer ingrijpend wijzigt en waar gebruikers mee werken; 2. Een centrale registratie van software fouten, die na de in productie name aan het licht komen. Elke organisatie, die ITIL gebruikt en organisaties, die goed beheer hebben ingericht houdt dit soort fouten bij. En daarmee kun je een grafiek maken om SoftwareRot te detecteren. Wat moet je in de grafiek opnemen: het aantal fouten dat per tijdseenheid worden gevonden. En dat over de eerste 3 jaar na de in productie name. Het opmerkelijke is dat de gebruikte programmeertaal geen enkele invloed blijkt te hebben op het verschijnsel SoftwareRot. De grafiek

De zo ontstane grafiek toont het merkwaardige verschijnsel: de grafiek toont het aantal fouten, dat de gebruikers rapporteren over 3 jaar. In het eerste jaar worden nog wat fouten gevonden en gefixed. Dit neemt af en we zeggen dan: de software stabiliseert. Dat klopt ook. Zo rond het derde en vierde jaar treedt echter het verschijnsel van SoftwareRot op: de grafiek gaat ineens en geheel onverwacht weer stijgen!

Dat is een zeer opmerkelijk verschijnsel en het wordt vaak geeneens opgemerkt omdat bedrijven hun statistieken maar in weinig gevallen over enkele jaren heen bekijken. En ook moet de software, die wij monitoren tussentijds niet ingrijpend zijn gewijzigd.

Wat is er nu echt aan de hand? Software is immers geen fruit en kan ook niet echt rotten.. We moeten dus verder kijken dan naar de software alleen.

Nu de meest interessante vraag: hoe ontstaat het verschijnsel? In de eerste periode dat gebruikers met het systeem werken houden gebruikers zich vooral aan de voorgeschreven werkwijzen en zullen daarom ook dicht bij de Use Case van het ontwerp blijven. Na een tijd op deze manier gewerkt te hebben, zullen gebruikers eerder geneigd zijn om te gaan experimenteren met de software. Hierdoor gaat de software op andere manieren gebruikt worden dan zij initieel voor is ontworpen en zullen nog niet eerder ontdekte fouten worden ontdekt. Verder blijkt uit de praktijk dat mensen van tijd tot tijd van functie of baan veranderen. Vroeger duurde het langer voordat er weer andere mensen met de zelfde software ging werken, nu is dat wat korter. Ik schat dat nu in ongeveer 3 jaar de groep mensen, die met de software werken grotendeels is µvernieuwd'. Wat gebeurt er dan? De µeerste generatie', die model hebben gestaan voor µde gebruiker' zijn vervangen door nieuwe medewerkers met nieuwe verwachtingen en inzichten. De requirements, die op de eerste generatie was toegespitst komen niet langer overeen met de verwachtingen van de volgende generatie. Die zullen de software ook op een andere manier gaan gebruiken en zullen dan ook nog niet eerder ontdekte fouten gaan vinden. Wat ook effect heeft op SoftwareRot zijn de gewijzigde behoeften van een organisatie, die nu

door licht verouderde software wordt ondersteund. Zo wordt soms een veld in de database gebruikt voor iets waar het nooit voor bedoeld is. En dat kan in sommige gevallen leiden tot nieuwe fouten, zonder dat de software is veranderd. Gewoonweg omdat er een potentiële fout in heeft gezeten, die bij normaal gebruik nooit aan het licht gekomen zou zijn.

Wat kunnen wij tegen SoftwareRot doen? Requirements: hoewel het niet gemakkelijk is kan een goede Requirements Engineer anticiperen op toekomstig gebruik. Zoals bij voorbeeld de mogelijkheid om bepaalde beslissingen te laten uitvoeren door een Rules Engine. Bij voorbeeld voor het bepalen of een hypotheek verstrekt zou mogen worden. Dit kan een deel van het oneigenlijk gebruik van de software voorkomen. Programmeren: het is belangrijk dat de Software Engineer defensief programmeert. Dit voorkomt potentiële fouten, die pas laat aan het licht komen. Testen: belangrijk is ook hier het gedrag van de gebruiker op lange termijn te voorspellen en uitgaande van dit potentieel onbedoelde gedrag te testen. Bij voorbeeld door testtechnieken zoals Exploratory Testen en UseCase Based Exploratory Testen structureel toe te passen als aanvulling op de meer formele en klassieke testtechnieken.

Wat betekent SoftwareRot voor organisaties? Wordt SoftwareRot niet opgemerkt, dan wel genegeerd, dan kan dit vervelende gevolgen hebben. Worden bij voorbeeld bepaalde database velden oneigenlijk gebruikt, dan heeft dat zeker invloed op een latere migratie van de software. De migratie zal moeilijker zijn en meer gaan kosten. Organisaties kunnen het fenomeen SoftwareRot nuttig gebruiken als µearly warning system'.

Conclusie
y y y

SoftwareRot is een ludiek gekozen naam voor een interessant fenomeen. SoftwareRot bestaat echt, maar is wat anders dan je op het eerste gezicht zou vermoeden. SoftwareRot is een interessante indicator om eens goed naar het gebruik van de software te kijken.

Meer over SoftwareRot en BitRot:
y

y y y y y

http://books.google.nl/books?id=pjGzTOYocikC&pg=PA186&lpg=PA186&dq=soft warerot&source=bl&ots=N710EoOQ9&sig=rRw7UpPktTLaDnTSmWv4SXswJiM&hl=nl&sa=X&oi=book_result&r esnum=9&ct=result http://en.wikipedia.org/wiki/Software_rot http://www.scottpreston.com/articles/638.php http://www.javvin.biz/softwareglossary/SoftwareRot.html http://encyclopedia2.thefreedictionary.com/software+rot http://www.wordyard.com/2004/07/27/software-rot/

y y

http://askleo.com/what_kind_of_maintenance_should_i_do_to_avoid_software_rot.html http://blogs.salon.com/0000014/2004/07/27.html

Sign up to vote on this title
UsefulNot useful