Home Innovatie & Strategie Software Reliability in 4 stappen

Software Reliability in 4 stappen

2
software reliability

We zijn allemaal wel eens in aanraking gekomen met onbetrouwbare software in producten. Je smartphone crasht, de autonavigatie functioneert niet naar behoren. Dit kan heel storend zijn, maar vaak volstaat het herstarten. Of nog een keer proberen. Irritatie verhogend, maar we maken ons er niet echt druk om. Stel je echter voor dat je een noodstop moet maken in de auto en de remmen reageren niet bij het intrappen van het pedaal. Dan wordt onbetrouwbare software ineens levensbedreigend. Bekende voorbeelden uit het verleden van onbetrouwbare software zijn de Ariane 5, of het bestralingssysteem Therac-25. Een recenter voorbeeld is de missie van de New Horizons Pluto Probe die na een reis van bijna 10 jaar vlak voor zijn aankomst bij Pluto serieuze problemen kreeg waardoor de software niet meer reageerde. Even herstarten is dan helaas geen optie.

Hoe meet je betrouwbaarheid van software?

We kunnen ons vrij eenvoudig iets voorstellen bij onbetrouwbare software. Maar wat is nou software-betrouwbaarheid (in het Engels software reliability)? Neem als voorbeeld een airbag. Ik heb hem zelf gelukkig nog nooit nodig gehad. Dit, terwijl ik bijna dagelijks in de auto zit en elk jaar de nodige kilometers afleg. Maakt dat de airbag betrouwbaar? Hij functioneert tot nu toe immers uitstekend? Er zijn veel verschillende definities van software reliability in omloop. De meest gangbare is:

Software Reliability is de waarschijnlijkheid dat de software storingsvrij werkt in een bepaalde omgeving voor een bepaalde tijd.

Deze definitie dien je uiteraard toe te passen in de context van het product. Voor een airbag (en de benodigde software) is de ‘bepaalde tijd’ bijvoorbeeld niet zo interessant. Het is relevanter om te kijken naar het aantal keren dat de airbag daadwerkelijk wordt gebruikt, hoewel dat uiteraard ook weer in tijd uitgedrukt kan worden. De betrouwbaarheid van automotoren (en andere onderdelen) wordt bijvoorbeeld vaak uitgedrukt in gereden kilometers.

Acties

Als duidelijk is wat software reliability in de context van het product betekent, dienen er de nodige acties worden gedefinieerd (en uitgevoerd). Denk aan het duidelijk specificeren wat de verwachte betrouwbaarheid moet zijn. Dit wordt vaak uitgedrukt in MTBF – Mean Time Between Failures. Ook is van belang welke maatregelen nodig zijn in de software architectuur. En welke testen gedefinieerd en uitgevoerd moeten worden. Wellicht worden bepaalde delen van de software niet op de traditionele manier ontwikkeld, maar gegeneerd via MDSD – Model Driven Software Development (beschreven in een eerdere blog door Michaël van de Ven). Daarnaast is het mogelijk de software betrouwbaarheid te meten gedurende de ontwikkeling en zogenaamde Reliability Growth Plots te maken om de voortgang duidelijk te maken. Zo wordt door extrapolatie geschat wat de software betrouwbaarheid van het product uiteindelijk zal zijn als het vrijgegeven wordt. Op deze manier komt dit dan niet als een verrassing.

In 4 stappen naar meer software-betrouwbaarheid

Op het gebied van software reliability is de nodige literatuur beschikbaar. Meestal is die gebaseerd op de fundamentele ideeën van John Musa. Toepassing van deze theorie in de praktijk is echter niet eenvoudig. Zeker als een organisatie voor de eerste keer structureel de software betrouwbaarheid wil aantonen, zullen er meer vragen zijn dan antwoorden. Dat moet anders kunnen…

Op basis van eigen praktijkervaringen heb ik samen met Peter Wijnhoven, Rob de Bie en René van den Eertwegh een boek geschreven met een 4-stappen aanpak naar een hogere software reliability.Boek

Met behulp van 4 stappen (en uiteraard de nodige sub-stappen) wordt het duidelijk welke acties nodig zijn om software-betrouwbaarheid van complexe producten onder controle te krijgen. Alvast een voorproefje:

  1. In de eerste stap wordt het domein van de eindgebruiker geanalyseerd. Dit leidt tot het beschrijven van de requirements op betrouwbaarheidsgebied van de verschillende functies die het systeem biedt.
  2. Hierna worden de reliability-vereisten van de software bepaald en worden zogenaamde operational profiles voor de verschillende onderdelen van de software afgeleid.
  3. In de derde stap wordt het engineering proces getuned om tot de gewenste reliability te komen. De betrouwbaarheid moet immers niet te laag zijn, maar ook niet (veel) te hoog.
  4. In de laatste stap wordt beschreven hoe software reliability gemeten en gerapporteerd kan worden. In een agile omgeving worden deze stappen continue doorlopen.

Het volledige stappenplan kun je teruglezen in het boek: Finally… Reliable Software!: A practical approach to design for reliability.

Software reliability is een keuze

Organisaties die daadwerkelijk de software reliability onder controle willen krijgen, zullen eerst moeten begrijpen wat dit in hun eigen context precies betekent. En vervolgens de benodigde acties moeten bepalen en uitvoeren. Dit kost uiteraard tijd en geld, maar net als met functionaliteit van je product… is dit een keuze! Kiest men ervoor om meer aandacht aan nieuwe functionaliteiten te besteden en minder (of geen) aan betrouwbaarheid, dan kan dat uiteindelijk voor vervelende verrassingen zorgen.

Het zou toch jammer zijn, als eindgebruikers de eersten zijn die in aanraking komen met tegenvallende software reliability. Je kunt tenslotte maar een keer een goede eerste indruk maken.

Bryan Bakker, test architect bij Sioux en veelgevraagd spreker voor (inter)nationale Test-conferenties zoals EuroSTAR en QA&Test.

Meer lezen:
Bryan Bakker (Sioux), Peter Wijnhoven (Sioux), Rob de Bie (Key Consult), en René van den Eertwegh (Altran) hebben samen een boek geschreven, waarin een 4-stappen aanpak beschreven staat: Finally… Reliable Software!: A practical approach to design for reliability. Het boek is o.a. op Amazon te bestellen.  

De theorie wordt in de eerste helft van het boek beschreven. De tweede helft bevat een zeer uitgebreide case study waarbij de stappen worden toegepast. De case study is gebaseerd op de ervaring van de auteurs.

 

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here