Tools en technieken voor kwaliteitsbepaling van productsoftware

Tools en technieken voor kwaliteitsbepaling van productsoftware Petra Heck, Alexander Serebrenik en Marko van Eekelen

Tools en technieken voor kwaliteitsbepaling van productsoftware Petra Heck, Alexander Serebrenik en Marko van Eekelen Laboratory for Quality Software (LaQuSo)1, [email protected], Technische Universiteit Eindhoven en Radboud Universiteit Nijmegen.

1

Inleiding

De laatste jaren wordt productsoftware ten opzichte van maatwerksoftware steeds belangrijker. Zo is volgens onderzoek van Marketcap het aandeel aan maatwerksoftware over alle sectoren in de Benelux heen de laatste drie jaar gedaald van 31 naar 23 procent. Deze ontwikkeling resulteert in groeiende aandacht voor kwaliteitsbepaling van softwareproducten. Productsoftware wordt ontwikkeld voor een markt, voor klanten in verschillende organisaties en met verschillende hard- en softwareomgevingen. Het belang van voortdurende productontwikkeling op basis van gedegen product-, klanten marktevaluaties neemt toe ten opzichte van onderhoud van eerder verkochte maatwerksoftware. Het is dan ook niet verwonderlijk dat, waar de prioriteit bij maatwerksoftware vaak gelegd wordt bij het beheersen van het ontwikkelproces (bij Spider, het Nederlandse Software Process Improvement netwerk is dit bijvoorbeeld het belangrijkste aandachtspunt), bij productsoftware kwaliteitsbepaling van het (deel)product steeds grotere aandacht krijgt. Ook de opkomst van outsourcing maakt het belangrijker om de kwaliteit van software (deel)producten vast te stellen. In dit artikel geven we een overzicht van diverse standaarden, tools en technieken voor kwaliteitsbepaling. Hierbij verwijzen we op diverse plaatsen naar resultaten die door LaQuSo zijn behaald bij projecten en case studies. We concentreren ons hierbij op de zogenoemde formele methoden. Hoewel deze technieken niet specifiek voor productsoftware zijn ontwikkeld, kunnen ze ook op dit terrein een toegevoegde waarde hebben ten opzichte van traditioneel testen doordat ze meer zekerheid over de kwaliteit bieden. Daarnaast zijn sommige eigenschappen simpelweg niet vast te stellen met traditioneel testen.

2

Kwaliteitsbepaling

In de vorm van kwaliteitsbepaling die we in dit artikel bespreken staat de volgende vraag centraal: Bezit het softwareproduct een bepaalde eigenschap? Voorbeelden zijn: wordt de waarde van een parameter nooit negatief, worden transacties binnen tien minuten verwerkt, kan het gebeuren dat een gebruiker twee keer in de database komt te staan, etc. Normaal gesproken wordt bepaald of een systeem een bepaalde eigenschap bezit door te testen. Het feit dat het tijdens het testen niet voorkwam dat een gebruiker twee keer in de database stond, wil echter niet zeggen dat dit nooit kan gebeuren. Het is immers onmogelijk om alle gevallen te testen. Een andere aanpak is het gebruik van wiskundige technieken en logica om te proberen te “bewijzen” dat een eigenschap geldt. Dit soort technieken wordt ook wel formele methoden genoemd en is het onderwerp van dit artikel.

1


De stappen die worden uitgevoerd tijdens de analyse van een systeem met behulp van formele methoden (ook wel verificatie genoemd) volgen vaak een algemeen proces als getekend in Figuur 1.

Figuur 1: Algemeen proces voor verificatie van een softwaresysteem

De eerste stap is om de vraag te bepalen die over het systeem beantwoord moet worden (de kwaliteitsvraag) en om deze vraag te formuleren in termen van verifieerbare eigenschappen die het softwareproduct moet bezitten. Het is daarbij ook belangrijk om een inventarisatie te maken van de beschikbare invoer voor de analyse (bijvoorbeeld broncode en documentatie). Soms moet deze invoer eerst geconverteerd worden naar een geschikt formaat. Wanneer de te verifiëren eigenschappen en de invoer bekend zijn, moeten geschikte analysetechnieken geselecteerd worden. Nadat de technieken toegepast zijn op de invoer moet het resultaat weer terugvertaald worden naar de oorspronkelijke kwaliteitsvraag. Paragraaf 4 bespreekt een aantal van de analysetechnieken. In de volgende paragraaf gaan we eerst kort in op een standaard die een startpunt kan vormen voor het definiëren van de kwaliteitsvraag en daarvan afgeleide systeemeigenschappen.

3

Kwaliteitsstandaarden

Hier geven we een kort overzicht van een aantal standaarden die relevant zijn voor productsoftware [1].

3.1

ISO/IEC 9126

De bekendste standaard voor softwareproductkwaliteit is the ISO/IEC 9126 standaard: “Software engineering – Product Quality”. Volgens deze standaard bestaat softwarekwaliteit uit 2 delen: a) interne en externe kwaliteit, en b) kwaliteit tijdens het gebruik. Het eerste deel van het model is onderverdeeld in zes eigenschappen, die weer zijn onderverdeeld in subeigenschappen (zie Figuur). Het tweede deel van het model bestaat ook uit zes eigenschappen, die samen de kwaliteit voor de gebruiker bepalen. De standaard voorziet ook in metrieken voor elk van de eigenschappen. De bijbehorende standaard ISO/IEC 14598-1 beschrijft hoe het kwaliteitsmodel in de praktijk gebruikt kan worden om productkwaliteit te bepalen. ISO/IEC 12119 “Software Package Quality Requirements and Testing” beschrijft de toepassing van ISO/IEC 9126 op productsoftware. In de standaard worden algemene eisen voor programma’s en gegevens beschreven en specifieke eisen voor de inhoud van de gebruikersdocumentatie en de productbeschrijving. Daarnaast worden richtlijnen gegeven voor het testen van het product ten opzichte van de kwaliteitseisen. 2


Figuur 2: ISO/IEC 9126 eigenschappen voor interne en externe kwaliteit

3.2

Diverse standaarden

Er zijn een aantal standaarden die het hele softwareontwikkelproces beschrijven. Veelal zijn deze geschreven vanuit het perspectief van maatwerksoftware, maar grote delen zijn zonder meer van toepassing voor productsoftware. Voorbeelden zijn ISO/IEC 12207: “Software Life Cycle Processes”, en CMMI-SE/SW (geen officiële standaard, maar wel als zodanig gebruikt om de volwassenheid van softwareleveranciers te meten). Daarnaast zijn er meerdere standaarden softwareontwikkelproces beschrijven.

die

een

bepaald

aspect

van

het

Een aantal voorbeelden daarvan zijn: ● IEEE Std 1063 “Software User Documentation”: minimale eisen aan de structuur en inhoud van papieren gebruikershandleidingen. ● ISO/IEC CD 14756 “Measurement and Rating of Performance”: richtlijnen om performance voor de gebruiker objectief te meten. ● IEEE Std 830 “Software Requirements Specification”: richtlijnen voor structuur en inhoud van het programma van eisen. In [1] is een goed overzicht te vinden van standaarden gerelateerd aan softwareontwikkeling.

4

Tools en technieken

In deze paragraaf bespreken we een aantal methoden en technieken voor de analyse van eigenschappen van softwareproducten. Dit kunnen bijvoorbeeld de eigenschappen zijn zoals genoemd in ISO/IEC 9126, maar ook functionele eigenschappen. De methoden en technieken voor de analyse van software kunnen ingedeeld worden in statische en dynamische analyses. Statische analysetechnieken hebben als doel eigenschappen van de software te ontdekken zonder het softwareproduct uit te voeren, bijvoorbeeld 3


gebaseerd op de broncode en bijbehorende documentatie. Dynamische analysetechnieken voeren de software in kwestie wel uit. Een voorbeeld van informele statische analyse is inspectie van de broncode. Een voorbeeld van informele dynamische analyse is testen. Over deze informele technieken is elders (zie bijvoorbeeld [5], [6], [7]) voldoende informatie beschikbaar. In het vervolg van deze paragraaf zullen we beknopt uitleggen wat een aantal formele analysetechnieken inhouden en aangeven wat de voordelen van het gebruik ervan zijn. Het softwareontwikkelproces kent verschillende artefacten, zoals het programma van eisen (requirements), ontwerpen, broncode en documentatie. Elke soort artefact kent zijn eigen analysetechnieken. In deze paragraaf bespreken we technieken die uitgaan van broncode, hoewel bijvoorbeeld ontwerpen en documentatie kunnen helpen bij het interpreteren van deze broncode. Alle technieken die in deze paragraaf besproken worden hebben als invoer broncode en een eigenschap waarin we geïnteresseerd zijn nodig. Sommige tools hebben een aantal van deze eigenschappen voorgedefinieerd (b.v. “zit er geen oneindige lus in het programma?” of “wordt er nergens mogelijk door nul gedeeld?”) zodat de gebruiker ze niet zelf hoeft te specificeren.

Figuur 3: Besproken analysetechnieken

4.1

Statische analysetechnieken

Zoals hierboven reeds genoemd is het bij statische analysetechnieken niet nodig de software uit te voeren. Statische analyse heeft een aantal voordelen: ● Sommige eigenschappen kunnen alleen door middel van statische technieken geanalyseerd worden. Een oneindige lus kan bijvoorbeeld niet gedetecteerd worden door de software uit te voeren. ● Statische technieken kunnen eigenschappen vaststellen die betrekking hebben op een oneindige set van waarden, bijvoorbeeld “eindigt deze berekening voor elke mogelijke invoerwaarde?”. ● Het uitvoeren van de software kan onmogelijk of extreem duur zijn. ● Statische technieken hebben geen invloed op statistieken als executietijd en geheugengebruik. 4


Hieronder presenteren we een drietal technieken om het gedrag van softwareproducten te analyseren. Model checking Model checking is de verzamelnaam voor een aantal technieken die gebaseerd zijn op wat een model genoemd wordt. Dit model is een vereenvoudigde weergave van de software die wat betreft de te analyseren eigenschap hetzelfde gedrag vertoont als de software zelf. Een model heeft een toestandsruimte (alle mogelijke toestanden) en een set van gebeurtenissen (events) die het systeem van de ene toestand in de andere brengen. Een standaardaanpak voor model checking is het genereren van de toestandsruimte en vervolgens controleren of de gewenste eigenschap geldt voor alle toestanden (zie voorbeeld). Als het niet lukt om te bewijzen dat de eigenschap voor alle toestanden geldt, dan zal de model checker meestal met een tegenvoorbeeld komen. Er moet dan gecontroleerd worden of het gedrag dat in het tegenvoorbeeld wordt beschreven ook een probleem oplevert in het echte systeem of alleen in het model. In dit laatste geval is er ergens een verkeerde keuze gemaakt in het modelleerproces. Er bestaan veel verschillende tools voor model checking, model checkers genoemd. Een van de meest populaire tools is SPIN (open source), waarbij het model gespecificeerd moet worden in de taal PROMELA (Process Meta Language, een taal om concurrency te specificeren). PROMELA lijkt op veelgebruikte programmeertalen als C, wat de drempel om het te gebruiken verlaagt. Een ander gratis tool is SMV, dat net als SPIN met verschillende soorten specificaties kan werken. Als het softwareproduct niet in een imperatieve programmeertaal (als C) geschreven is en er een model van gemaakt moet worden, is het gemakkelijker een hoger niveau van abstractie te gebruiken met bijvoorbeeld de mCRL2 toolset. Beschouw een software systeem dat toegang geeft tot vertrouwelijke informatie. Om toegang te verkrijgen moet de gebruiker een geldige gebruikersnaam en wachtwoord opgeven en een applicatie opstarten. Inloggen en opstarten is de enige manier om toegang tot de informatie te krijgen. Als de gebruiker uitlogt, wordt de applicatie afgesloten en is de informatie niet langer toegankelijk. We willen bewijzen dat als de gebruiker probeert om de applicatie op te starten zonder ingelogd te zijn, hij geen toegang krijgt. Om dit te verifiëren construeren we een eindig model van het systeem (zie Figuur). Het model bestaat uit vier toestanden, waarbij elke toestand bestaat uit een antwoord op de twee vragen: is de gebruiker ingelogd? heeft de gebruiker toegang tot de informatie? Events die de overgang naar een andere toestand kunnen bewerkstelligen zijn “geef een geldige gebruikersnaam en wachtwoord”, “geef een ongeldige gebruikersnaam en/of wachtwoord”, “start de applicatie”, “stop de applicatie” en “log uit”. Bij de start is de gebruiker niet ingelogd en heeft dus geen toegang tot de informatie. De toestand is “nee-nee”. Als de gebruiker probeert de applicatie te starten of inlogt met een ongeldige gebruikersnaam-wachtwoord combinatie, gebeurt er niets (we blijven in dezelfde toestand). Als daarentegen de combinatie geldig is, slaagt de login en wordt de toestand “janee”. In deze toestand kan de gebruiker ofwel uitloggen en dus teruggaan naar de vorige

5


toestand, ofwel de applicatie starten. Als de applicatie gestart is heeft de gebruiker toegang tot de informatie en wordt de toestand “ja- ja”. Als de gebruiker nu besluit om de applicatie te stoppen gaat het systeem van “ja-ja” naar ”ja-nee”. Tenslotte, als de gebruiker uitlogt, wordt de applicatie afgesloten en is het systeem terug in de oorspronkelijke “nee-nee” toestand. Dit zijn de enige mogelijke scenario’s. In het bijzonder betekent dit dat er geen enkele manier is om de informatie te krijgen zonder ingelogd te zijn (de toestand “nee-ja” kan nooit bereikt worden).

Figuur 4: Toestandsdiagram van het softwaresysteem

Tijdens een van de LaQuSo-projecten is de beveiligingslaag van een geautomatiseerde parkeergarage gemodelleerd in de taal mCRL2 [3]. In deze garage laat de bestuurder zijn auto achter die door robots en lopende banden op de juiste plek wordt geparkeerd. De beveiligingslaag moet er voor zorgen dat hij zijn auto ook weer heel terug krijgt. Het model is geverifieerd en daarmee is aangetoond dat het model geen “fouten” vertoont. Dit model kan dus goed gebruikt worden voor het implementeren van de uiteindelijke broncode. LaQuSo is momenteel bezig eenzelfde techniek toe te passen bij een bedrijf dat als software product een platform levert voor de generatie van geavanceerde documenten. Hierbij worden alle parallelle processen in kaart gebracht en wordt gekeken of gegarandeerd kan worden dat er zich geen deadlocks (processen die oneindig lang op elkaar wachten) voor kunnen doen. Abstractietechnieken In veel gevallen heeft het gedrag van software oneindig veel mogelijkheden. Zelfs bij een eindig, maar groot, aantal mogelijkheden is het ondoenlijk om ze allemaal uit te proberen. Een mogelijke oplossing voor dit probleem is een abstractietechniek te gebruiken die de oneindige verzameling mogelijkheden benadert door een kleinere (eindige) verzameling. Hiervoor moeten bepaalde irrelevante delen van de informatie genegeerd worden en elementen uit de verzameling die identieke relevante delen hebben als identiek beschouwd worden. Welk deel van de informatie relevant is hangt af van de eigenschap die geanalyseerd moet worden. 6


Om dit idee te illustreren bekijken we het volgende voorbeeld. Stel dat we willen controleren of de berekening 2134 * 567 = 1208976 correct is uitgevoerd. Om te constateren dat dit niet het geval is, is het voldoende ons te realiseren dat 4 * 7 = 28 en dus het product van een getal eindigend op een 4 en een getal eindigend op een 7, moet eindigen op een 8. In dit voorbeeld hebben we alle cijfers van de getallen genegeerd, behalve de laatste. Zo hebben we oneindig veel nummers die eindigen op een bepaald cijfer benaderd door dat cijfer zelf. Abstracte interpretatie is een raamwerk dat een groot aantal abstractietechnieken omschrijft. Een voordeel van abstracte interpretatie is dat de beslissing welk deel van de informatie genegeerd moet worden automatisch genomen kan worden en ingebouwd is in tools gebaseerd op abstracte interpretatie. Voorbeelden van commerciële tools zijn PolySpace Verifier (PolySpace Technologies) en PAG (AbsInt Angewandte Informatik). Bij een LaQuSo-project is de besturingsoftware van een proefdrukprinter geanalyseerd met behulp van abstractietechnieken. De software bestond uit ongeveer 60.000 regels C-code. Omdat de software niet onafhankelijk van de hardware (de printer) gedraaid kon worden, was statische analyse hier de enige mogelijkheid. Met behulp van tools zijn een aantal fouten ontdekt die tot storingen in de uitvoering van de software kunnen leiden. Assertionele technieken Soms is het bekend dat op een bepaald punt in de broncode, bepaalde eigenschappen moeten gelden. Bijvoorbeeld nadat een sorteerfunctie is aangeroepen is het resultaat een geordende lijst van getallen. Daarnaast zijn er ook eigenschappen die gedurende de gehele executie moeten gelden: bijvoorbeeld “dit getal is altijd groter dan nul”. Het startpunt van assertionele technieken is het toevoegen van dergelijke eigenschappen, asserties geheten, aan de broncode. Vervolgens moet bewezen worden dat de asserties nooit geschonden kunnen worden (bijvoorbeeld dat een bepaald getal inderdaad nooit kleiner dan nul wordt). Er bestaan verschillende soorten asserties, onder andere: ● Precondities specificeren condities die moeten gelden voordat een functie wordt aangeroepen. ● Postcondities specificeren condities die gelden nadat de functie beëindigd is. ● Invarianten specificeren condities die tijdens de gehele uitvoering gelden. Tools die assertionele technieken ondersteunen (assertion checkers) vertalen de broncode inclusief de asserties naar logische formules en proberen deze vervolgens te bewijzen. Sommige tools zoals ESC/Java 2 (University College Dublin) proberen de formules automatisch te bewijzen, andere tools zoals Krakatoa (INRIA Futurs) roepen ook de hulp van de gebruiker in om de formules te bewijzen. Omdat assertionele technieken met broncode werken hangt de keuze voor een bepaalde tool ook af van de programmeertaal die is gebruikt om het softwareproduct te implementeren. Dit is een voorbeeld van Java code waarin met de assertietaal JML asserties zijn geplaatst [2]. Het is de code voor een Heap klasse. Een preconditie staat in regel 8 (de heap moet minstens 1 element bevatten voordat de functie largest kan worden aangeroepen), een

7


postconditie in regel 17 (het resultaat van de functie size is het aantal elementen in de heap) en een invariant staat in regel 5 (het attribuut elements is nooit null). package org.jmlspecs.samples.jmlrefman; public abstract class IntHeap { //@ public model non_null int [] elements; /*@ public normal_behavior @ requires elements.length >= 1; @ assignable \nothing; @ ensures \result @ == (\max int j; @ 0 <= j && j < elements.length; @ elements[j]); @*/ public abstract /*@ pure @*/ int largest(); //@ ensures \result == elements.length; public abstract /*@ pure @*/ int size(); };

// // // // // // // // // // // // // // // // // // //

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

LaQuSo heeft een case studie uitgevoerd waarbij de stabiliteit van een besturingssysteem voor een modelspoorbaan is geanalyseerd [4]. De broncode bestond uit bijna 18.000 regels Javacode. Deze code is geannoteerd met asserties in JML [2]. Hiermee zijn een aantal fouten gevonden die in principe niet leiden tot storing in de uitvoering, maar problemen kunnen opleveren als de software uitgebreid wordt. Zo is er bijvoorbeeld een functie die alleen correct werkt als een van de parameters “0” is. In de huidige code wordt hij ook alleen als zodanig aangeroepen, maar bij uitbreiding en hergebruik is dat niet gegarandeerd.

4.2

Dynamische analysetechnieken

Dynamische technieken analyseren de eigenschappen van een softwaresysteem over één of meerdere executies. Het grote voordeel van dynamische analyse is dat tijdens de executie alle benodigde informatie beschikbaar is. Eigenschappen die moeilijk of zelfs niet te analyseren zijn met statische technieken, kunnen vaak eenvoudig worden opgelost met dynamische technieken (bijvoorbeeld, bepalen of twee pointers naar eenzelfde object wijzen). Een inherent nadeel van dynamische technieken is dat ze nooit compleet kunnen zijn: eigenschappen worden slechts gecontroleerd voor een beperkt aantal testgevallen. Hieronder presenteren we een viertal technieken gerelateerd aan dynamische analyse. Instrumentatie Een veelgebruikte techniek bij dynamische analyse is instrumentatie: er wordt code toegevoegd aan het originele programma. Deze extra code heeft als doel om informatie te verzamelen tijdens executie en zou de semantiek van het programma idealiter niet aan moeten tasten. Een typisch voorbeeld is een debugger. Helaas beïnvloeden dergelijke applicaties doorgaans wel degelijk de executietijd en het resourcegebruik. Instrumentatie kan toegepast worden op twee niveaus: ● Broncode ● Gecompileerde code (bytecode) 8


Een duidelijk voordeel van het instrumenteren van broncode is dat de broncode gemakkelijk toegankelijk is. Voordelen van instrumentatie van gecompileerde code is dat parsers en editors voor dergelijke code gemakkelijker te maken zijn en er dus meer beschikbaar zijn. Daarnaast is de bytecode van een programmeertaal stabieler dan de taal zelf. Bovendien zijn er in bijvoorbeeld de .NET omgeving veel verschillende programmeertalen die allemaal naar dezelfde bytecode compileren. Off-line technieken Off-line technieken zijn gebaseerd op het gedrag dat een systeem in het verleden vertoond heeft. Dit gedrag kan bijvoorbeeld geanalyseerd worden in executielogs van het systeem en gebruikt worden om toekomstig gedrag te voorspellen. Een voorbeeld van dergelijke tools zijn de process miners. Een nadeel van dergelijke technieken is dat om ze uit te voeren een uitvoerige (set) logfile(s) nodig is. Het constant wegschrijven van grote hoeveelheden data in de logs van een systeem, kan drastische invloeden hebben op de performance van het systeem. On-line technieken On-line technieken worden gebruikt tijdens de executie van een programma. Het grote voordeel van on-line technieken is hun precisie: als er een fout wordt gerapporteerd, weten we zeker dat deze is opgetreden en de fout wordt ook direct gerapporteerd nadat hij is opgetreden. In deze context (formele methoden) zijn ze gebaseerd op toevoegingen aan de code (asserties of instrumentatie), wat ze onderscheidt van traditioneel testen. Run-time assertion checking is een voorbeeld van zo een on-line techniek. Hierbij is het niet het doel van de tool om te bewijzen dat de asserties niet geschonden kunnen worden. In plaats daarvan wordt de code gewoon uitgevoerd en geeft de tool een melding als tijdens de executie een assertie geschonden wordt. Metrieken Omdat dynamische technieken niet compleet zijn, kan nooit gegarandeerd worden dat alle mogelijke executiepaden getest zijn. Een veelgebruikt hulpmiddel (ook bij traditioneel testen) om een inschatting te maken van de betrouwbaarheid van de analyse zijn coverage (dekkings-) metrieken: ● Statement coverage geeft aan welk percentage van de regels code is uitgevoerd tijdens de analyse. Idealiter is elke regels minstens één keer uitgevoerd. ● Decision coverage geeft aan welke takken (case, selecties, lussen, etc.) in de code zijn uitgevoerd tijdens de executie. Idealiter is elke tak minstens één keer uitgevoerd. ● Predicate coverage verwijst naar conditionele en iteratieve constructies waarin booleaanse expressies voorkomen. Bijvoorbeeld het C fragment if ((a>0)||(b<10))bevat twee booleeaanse expressies, a>0 en b<10. Idealiter is elke expressie minstens 1 keer waar. ● Call coverage meet het percentage aangeroepen modules of functies. Idealiter worden alle modules (of functies) minstens één keer aangeroepen.

9


In een LaQuSo-project is een analyse gemaakt van de performance van een groot systeem waarmee pensioenoverzichten worden gegenereerd. Dit systeem bestaat uit een Oracle database en een COBOL applicatie. Uit metingen bleek dat de databasequeries de grootste invloed hadden op de totale rekentijd. Uiteindelijk zijn de Oracle traces (logs) met behulp van een speciaal ontwikkelde visualisatietechniek geanalyseerd (off-line techniek). Hierdoor is een aantal verbetering gevonden waarbij de benodigde rekentijd aanzienlijk korter werd.

5

Conclusie

We hebben door het inzoomen op een aantal technieken en bijbehorende case-studies een overzicht gegeven van een aantal van de tools en technieken die ter beschikking staan voor kwaliteitsbepaling van productsoftware. Een volledig overzicht is dit echter zeker niet. We hebben een selectie moeten maken gezien de beschikbare ruimte. Zo zijn eigenschappen als security, usability en een veelheid aan testtechnieken hier helaas niet besproken. Binnen LaQuSo wordt de beschikbare kennis gebundeld en toegankelijk gemaakt door het opzetten van een geïntegreerde omgeving van tools en technieken (Software Quality Analysis & Design Toolset, SQuADT) waar bovendien mogelijkheden aan zijn toegevoegd om voor de ene techniek gebruikte specificaties en modellen om te zetten naar een voor een andere techniek bruikbare vorm. Zoals in de inleiding reeds genoemd zijn de hier besproken tools en technieken niet specifiek voor productsoftware. De in dit artikel besproken case studies en projecten zijn daar ook niet op gericht. We hopen dat we de lezer toch hebben kunnen laten inzien dat de technieken wel degelijk ook van toepassing zijn op productsoftware. Tijdens lopende en nieuwe case studies op dit terrein wil LaQuSo dit aantonen en waar nodig de technieken aanpassen of nieuwe tools ontwikkelen, specifiek voor productsoftware. Met gebruik van dergelijke tools en technieken zal het in de toekomst wellicht mogelijk worden om te komen tot een vorm van kwaliteitscertificatie van softwareproducten.

6

Referenties

[1] James W. Moore. Software Engineering Standards. A User’s Road Map. IEEE, 2000. [2] JML Reference Manual, http://www.cs.iastate.edu/~leavens/JML/jmlrefman/ [3] Aad Mathijssen, A. Johannes Pretorius. Specification, Analysis and Verification of an Automated Parking Garage. Technische Universiteit Eindhoven, Department of Mathematics and Computer Science, CS-Report 05-25, 2005. [4] Cornelis Huizing, Ruurd Kuiper, Teade Punter and Alexander Serebrenik. Looking for Stability. In Development and Deployment of Product Software 2005. S.Brinkkemper, L. Xu (Eds.), San Diego, U.S.A., 2005. [5] B. Beizer. Software Testing Techniques. Van Nostrand Reinhold, 1990. [6] G.J. Myers, T. Badgett, T.M. Thomas and C. Sandler. The Art of Software Testing. Wiley, 2004. [7] Martin Pol, Ruud Teunissen, Erik van Veenendaal. Software Testing. A Guide to the TMAP® Approach. Addison-Wesley, 2002. 1. Het Platform voor Productsoftware kent een werkgroep softwarekwaliteit waar de leden onderling hun ervaringen op het gebied van kwaliteitsbepaling en kwaliteitsborging uitwisselen. LaQuSo, het Laboratory for Quality Software (een gezamenlijke activiteit van Technische Universiteit Eindhoven en Radboud Universiteit Nijmegen), verricht in projecten voor en met het bedrijfsleven onderzoek naar kwaliteitsbepaling van softwareproducten. Vanuit LaQuSo wordt door middel van het voorzitterschap van Marko van Eekelen een bijdrage geleverd aan deze werkgroep.

10

Tools en technieken voor kwaliteitsbepaling van productsoftware

Recommend Documents