Tools en technieken voor kwaliteitsbepaling van productsoftware

Maat: px
Weergave met pagina beginnen:

Download "Tools en technieken voor kwaliteitsbepaling van productsoftware"

Transcriptie

1 Tools en technieken voor kwaliteitsbepaling van productsoftware Laboratory for Quality Software (LaQuSo) 1, 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-, klant- en 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

2 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 beschrijft hoe het kwaliteitsmodel in de praktijk gebruikt kan worden om productkwaliteit te bepalen. ISO/IEC 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

3 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 die een bepaald aspect van het softwareontwikkelproces beschrijven. Een aantal voorbeelden daarvan zijn: IEEE Std 1063 Software User Documentation : minimale eisen aan de structuur en inhoud van papieren gebruikershandleidingen. ISO/IEC CD 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

4 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

5 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

6 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

7 Om dit idee te illustreren bekijken we het volgende voorbeeld. Stel dat we willen controleren of de berekening 2134 * 567 = 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 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

8 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; // 1 // 2 public abstract class IntHeap { // 3 // 4 public model non_null int [] elements; // 5 // 6 public normal_behavior // requires elements.length >= 1; // assignable \nothing; // ensures \result // == (\max int j; // 0 <= j && j < elements.length; // elements[j]); // // 14 public abstract int largest(); // 15 // 16 ensures \result == elements.length; // 17 public abstract int size(); // 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 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

9 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

10 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, [2] JML Reference Manual, [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, [4] Cornelis Huizing, Ruurd Kuiper, Teade Punter and Alexander Serebrenik. Looking for Stability. In Development and Deployment of Product Software S.Brinkkemper, L. Xu (Eds.), San Diego, U.S.A., [5] B. Beizer. Software Testing Techniques. Van Nostrand Reinhold, [6] G.J. Myers, T. Badgett, T.M. Thomas and C. Sandler. The Art of Software Testing. Wiley, [7] Martin Pol, Ruud Teunissen, Erik van Veenendaal. Software Testing. A Guide to the TMAP Approach. Addison-Wesley, 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

Werkgroep Software Kwaliteit

Werkgroep Software Kwaliteit Nationaal Productsoftware Congres 2006 Software Kwaliteit 11 April 2006 is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen PPSW Software Kwaliteit overzicht Introductie

Nadere informatie

Testen van Java code met JML

Testen van Java code met JML Testen van Java code met JML Engelbert Hubbers Martijn Oostdijk Erik Poll University of Nijmegen Testen met JML p.1/23 Overzicht De specificatietaal JML voor Java Wat voorbeelden van JML specificaties

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Kenmerken van DLArchitect

Kenmerken van DLArchitect Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

Vraag 1... Vraag 2... Vraag 3...

Vraag 1... Vraag 2... Vraag 3... Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat ofwel op 1.5 ofwel op 2 punten, en elke oefening op 10 punten. Het geheel staat op 60. Vraag 1...[.../3]

Nadere informatie

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

Plan van Aanpak Afstuderen

Plan van Aanpak Afstuderen Plan van Aanpak Afstuderen Michiel Graat 27-09-2005 Inhoudsopgave 1 Inleiding 3 1.1 Terminologie............................. 3 1.2 Opdracht............................... 4 1.3 JavaCard...............................

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

Nadere informatie

HOOFDSTUK 3. Imperatief programmeren. 3.1 Stapsgewijs programmeren. 3.2 If Then Else. Module 4 Programmeren

HOOFDSTUK 3. Imperatief programmeren. 3.1 Stapsgewijs programmeren. 3.2 If Then Else. Module 4 Programmeren HOOFDSTUK 3 3.1 Stapsgewijs programmeren De programmeertalen die tot nu toe genoemd zijn, zijn imperatieve of procedurele programmeertalen. is het stapsgewijs in code omschrijven wat een programma moet

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

Product Quality Management, onze toekomst René Tuinhout

Product Quality Management, onze toekomst René Tuinhout Product Quality Management, onze toekomst René Tuinhout Agenda No. 2 1 Tijdsindeling Binnen TestNet is gesproken over Product Kwaliteit (in 2011 en tijdens de Summerschool 2012). Een TestNet-werkgroep

Nadere informatie

Cover Page. The handle http://hdl.handle.net/1887/20225 holds various files of this Leiden University dissertation.

Cover Page. The handle http://hdl.handle.net/1887/20225 holds various files of this Leiden University dissertation. Cover Page The handle http://hdl.handle.net/1887/20225 holds various files of this Leiden University dissertation. Author: Heijstek, Werner Title: Architecture design in global and model-centric software

Nadere informatie

Clean code improves test quality

Clean code improves test quality Clean code improves test quality Michel Kroon, Senior Consultant, SIG TestNet Voorjaarsevenement 30 juni 2008 Arent Janszoon Ernststraat 595-H NL-1082 LD Amsterdam info@sig.nl www.sig.nl De Software Improvement

Nadere informatie

SQL Plan Management in Oracle11g Harald van Breederode

SQL Plan Management in Oracle11g Harald van Breederode SQL Plan Management in Oracle11g Harald van Breederode Sinds de introductie van de Cost Based Optimizer (CBO) in Oracle7 hebben zowel database beheerders als database ontwikkelaars de wens om deze optimizer

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

Teamhandleiding DOMjudge (versie 2.2.0muKP) 31 mei 2008

Teamhandleiding DOMjudge (versie 2.2.0muKP) 31 mei 2008 judge Teamhandleiding DOMjudge (versie..0mukp) 31 mei 008 /\ DOM DOM judge Inhoudsopgave 1 Inleiding Samenvatting.1 Inlezen en wegschrijven............................... Insturen van oplossingen...............................3

Nadere informatie

Dynamiek met VO-Script

Dynamiek met VO-Script Dynamiek met VO-Script Door Bert Dingemans DLA Ontwerp & Software bert@dla-architect.nl Inleiding Op de SDGN nieuwsgroep voor Visual Objects ontstond laatst een draad van berichten over de nieuwe libraries

Nadere informatie

Als een PSD selecties bevat, deelt de lijn van het programma zich op met de verschillende antwoorden op het vraagstuk.

Als een PSD selecties bevat, deelt de lijn van het programma zich op met de verschillende antwoorden op het vraagstuk. HOOFDSTUK 3 3.1 Stapsgewijs programmeren In de vorige hoofdstukken zijn programmeertalen beschreven die imperatief zijn. is het stapsgewijs in code omschrijven wat een programma moet doen, net als een

Nadere informatie

DOMjudge teamhandleiding

DOMjudge teamhandleiding judge DOMjudge teamhandleiding Samenvatting /\ DOM DOM judge Hieronder staat de belangrijkste informatie kort samengevat. Dit is bedoeld om snel aan de slag te kunnen. We raden echter ten zeerste aan dat

Nadere informatie

Vakgroep CW KAHO Sint-Lieven

Vakgroep CW KAHO Sint-Lieven Vakgroep CW KAHO Sint-Lieven Objecten Programmeren voor de Sport: Een inleiding tot JAVA objecten Wetenschapsweek 20 November 2012 Tony Wauters en Tim Vermeulen tony.wauters@kahosl.be en tim.vermeulen@kahosl.be

Nadere informatie

Curriculum 2015-2016 Afkortingen Bachelor Informatica Propedeuse Postpropedeuse Start Vervolg Afsluiting 60,0 Gebonden keuze (8,6 EC) Afsluiting

Curriculum 2015-2016 Afkortingen Bachelor Informatica Propedeuse Postpropedeuse Start Vervolg Afsluiting 60,0 Gebonden keuze (8,6 EC) Afsluiting Curriculum 2015-2016 Opleidingen Open Universiteit, faculteit Management, Science & Technology, wetenschapsgebied Informatica en informatiekunde, geldig vanaf 1-9-2015 Afkortingen European Credits (studiepunten)

Nadere informatie

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996 Organisatie SYSQA B.V. Pagina 1 van 6 Black-Box Test Technieken Er zijn een aantal test specificatie technieken, verder testtechnieken genoemd, die bruikbaar zijn binnen het black-box acceptatietesten.

Nadere informatie

Inhoud. Introductie tot de cursus

Inhoud. Introductie tot de cursus Inhoud Introductie tot de cursus 1 De functie van de cursus 7 2 De inhoud van de cursus 7 2.1 Voorkennis 7 2.2 Leerdoelen van de cursus 8 2.3 Opbouw van de cursus 8 3 Leermiddelen en wijze van studeren

Nadere informatie

Master Software Engineering. Inhoud, begeleiding, tentamen dr. Anda Counotte Docent en mentor

Master Software Engineering. Inhoud, begeleiding, tentamen dr. Anda Counotte Docent en mentor Master Software Engineering Inhoud, begeleiding, tentamen dr. Anda Counotte Docent en mentor Thema Software Architectuur Design Patterns (DP) ir. Sylvia Stuurman, dr.ir. Harrie Passier en dr. Bastiaan

Nadere informatie

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

1 Inleiding in Functioneel Programmeren

1 Inleiding in Functioneel Programmeren 1 Inleiding in Functioneel Programmeren door Elroy Jumpertz 1.1 Inleiding Aangezien Informatica een populaire minor is voor wiskundestudenten, leek het mij nuttig om een stukje te schrijven over een onderwerp

Nadere informatie

Software Engineering (I00094) College 3:

Software Engineering (I00094) College 3: Software Engineering (I00094) College 3: Kwaliteit, organisatie en documentatie Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Huidige planning 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse

Nadere informatie

SmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker

SmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker SmartTestAssistant Het slimme testhulpmiddel door Frank Stolker Inhoud Waarom wéér een ander tool? Omdat dit is wat we willen Wat is SmartTestAssistant dan? Hoe zit het in elkaar? Hoe werkt het? Schematische

Nadere informatie

Een Inleiding tot Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

Een Inleiding tot Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Een Inleiding tot Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Software engineering De economie is compleet afhankelijk van software. Meer en meer systemen

Nadere informatie

Onderzoeksvaardigheden 2

Onderzoeksvaardigheden 2 Performance van Phonegap Naam: Datum: april 2012 Studentnummer: 0235938 Opleiding: CMD Docenten: Pauline Krebbers Modulecode: MEDMO101DT Modulenaam: Onderzoeksvaardigheden 2 / Media & Onderzoek Inhoudsopgave

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Curriculum 2014-2015 Afkortingen Bachelor Informatica Propedeuse Postpropedeuse Start Vervolg Afsluiting 60,0 Gebonden keuze (8,6 EC) Afsluiting

Curriculum 2014-2015 Afkortingen Bachelor Informatica Propedeuse Postpropedeuse Start Vervolg Afsluiting 60,0 Gebonden keuze (8,6 EC) Afsluiting Curriculum 2014-2015 Opleidingen Open Universiteit, faculteit Management, Science & Technology, wetenschapsgebied Informatica en informatiekunde, geldig vanaf 1-9-2014 Afkortingen European Credits (studiepunten)

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan.

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan. Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. De puntenverdeling is 2 punten per theorie-vraag en 8 punten per oefening. Het totaal is 40. Vraag 1. Er bestaan verschillende

Nadere informatie

Inleiding Software Engineering! Unit Testing, Contracten, Debugger! 13 Februari 2014!

Inleiding Software Engineering! Unit Testing, Contracten, Debugger! 13 Februari 2014! Inleiding Software Engineering Unit Testing, Contracten, Debugger 13 Februari 2014 Beknopte info over Unit Testing en Contracten kan je vinden op het einde van dit document. Eclipse beschikt over een handige

Nadere informatie

Abstraheren van modellen

Abstraheren van modellen Abstraheren van modellen Geert Delanote 7 maart 2005 Geert.Delanote@cs.kuleuven.ac.be Software Development Methodology 1 Inhoudstafel Motivatie Denkpistes Software Development Methodology 2 Motivatie Verslag

Nadere informatie

Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft

Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft Tentamen Object Georiënteerd Programmeren TI1200 30 januari 2013, 9.00-12.00 Afdeling SCT, Faculteit EWI, TU Delft Bij dit tentamen mag je geen gebruik maken van hulpmiddelen zoals boek of slides. Dit

Nadere informatie

Technische Specificaties nieuwe Unix Applikaties

Technische Specificaties nieuwe Unix Applikaties Technische Specificaties nieuwe Unix Applikaties In 2010 werden 7 Unix servers geconsolideerd naar een nieuwe Unix omgeving, waar gebruik gemaakt wordt van srp s (vergelijkbaar met zone, of container).

Nadere informatie

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.

Nadere informatie

Grenzeloos vertrouwen in een tool!?

Grenzeloos vertrouwen in een tool!? Grenzeloos vertrouwen in een tool!? TestNet voorjaarsevenement Maandag 30 juni 2008 Rick de Jong Agenda Korte introductie Kritische kijk op het gebruik van tools Intake en selectie van tools Het omarmen

Nadere informatie

AFO 142 Titel Aanwinsten Geschiedenis

AFO 142 Titel Aanwinsten Geschiedenis AFO 142 Titel Aanwinsten Geschiedenis 142.1 Inleiding Titel Aanwinsten Geschiedenis wordt gebruikt om toevoegingen en verwijderingen van bepaalde locaties door te geven aan een centrale catalogus instantie.

Nadere informatie

Bellen Zonder Zorgen

Bellen Zonder Zorgen Bellen Zonder Zorgen Je hebt het vast wel eens gehad. Ben je lekker aan het werk op je computer loopt hij ineens vast! En natuurlijk heb je het werk niet opgeslagen. Je probeert nog van alles om te redden

Nadere informatie

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Extended ISO 9126: 2001 Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

Nadere informatie

Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0

Technisch ontwerp. Projectteam 6. Project Web Essentials 02 april 2009. Versie 2.1.0 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Programmeren: Visual Basic

Programmeren: Visual Basic PETERSTUYVESANT COLLEGE INFORMATICA 2009-2010 Programmeren: Visual Basic Algemene Kennis: 01. Programmeren Programmeren is het schrijven van een computerprogramma, een concrete verzameling instructies

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

Referentieniveaus uitgelegd. 1S - rekenen Vaardigheden referentieniveau 1S rekenen. 1F - rekenen Vaardigheden referentieniveau 1F rekenen

Referentieniveaus uitgelegd. 1S - rekenen Vaardigheden referentieniveau 1S rekenen. 1F - rekenen Vaardigheden referentieniveau 1F rekenen Referentieniveaus uitgelegd De beschrijvingen zijn gebaseerd op het Referentiekader taal en rekenen'. In 'Referentieniveaus uitgelegd' zijn de niveaus voor de verschillende sectoren goed zichtbaar. Door

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

NHibernate als ORM oplossing

NHibernate als ORM oplossing NHibernate als ORM oplossing Weg met de SQL Queries Wat is ORM? ORM staat in dit geval voor Object Relational Mapping, niet te verwarren met Object Role Modeling. ORM vertaalt een objectmodel naar een

Nadere informatie

Inhoudstafel. UML (Unified Modeling Language)

Inhoudstafel. UML (Unified Modeling Language) UML (Unified Modeling Language) Inhoudstafel Inleiding...2 Waarvoor dient UML...2 Wat is UML... 2 Use-cases... 2 Inleiding...2 Voorbeeld...3 Eigenschappen van een goede use-case...3 Wat is een actor...4

Nadere informatie

Een eenvoudig algoritme om permutaties te genereren

Een eenvoudig algoritme om permutaties te genereren Een eenvoudig algoritme om permutaties te genereren Daniel von Asmuth Inleiding Er zijn in de vakliteratuur verschillende manieren beschreven om alle permutaties van een verzameling te generen. De methoden

Nadere informatie

13/07/2012. Op naar Product Quality Monitoring René Tuinhout. Agenda. Tijdsindeling. K o f f i e p a u z e. TestNet Summerschool, juni 2012

13/07/2012. Op naar Product Quality Monitoring René Tuinhout. Agenda. Tijdsindeling. K o f f i e p a u z e. TestNet Summerschool, juni 2012 Op naar Product Quality Monitoring René Tuinhout Agenda No. 2 Tijdsindeling K o f f i e p a u z e No. 3 1 Introductie Zaterdag 9 juni 2012 Vrijdag 15 juni 2012 Zaterdag 16 juni 2012 Zaterdag 9 juni 2012

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Vraag 1. Vraag 2. Vraag 3. Vraag 4.

Vraag 1. Vraag 2. Vraag 3. Vraag 4. Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat op 2 en elke oefening op 8 punten. Het geheel staat op 40. Vraag 1. Schets kort de fasen in Boehm s Lifecycle

Nadere informatie

Eindtoets. Opgaven. 1 Gegeven is het domeinmodel van figuur 1. Domeinmodel voor betalingen. Eindtoets I N T R O D U C T I E.

Eindtoets. Opgaven. 1 Gegeven is het domeinmodel van figuur 1. Domeinmodel voor betalingen. Eindtoets I N T R O D U C T I E. Eindtoets I N T R O D U C T I E Deze eindtoets is bedoeld als voorbereiding op het tentamen. Het is belangrijk dat u de eindtoets pas probeert te maken op het moment dat u denkt klaar te zijn met de tentamenvoorbereiding.

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Afstudeeronderwerpen Lex Wedemeijer

Afstudeeronderwerpen Lex Wedemeijer Afstudeeronderwerpen Lex Wedemeijer Hierbij een aantal onderwerpen die wellicht geschikt zijn als afstudeeronderwerp. Het accent van mijn onderzoek ligt op het (steeds beter) ondersteunen van bedrijfsprocessen,

Nadere informatie

Het SEESCOA project; jouw user interface, altijd en overal

Het SEESCOA project; jouw user interface, altijd en overal Het SEESCOA project; jouw user interface, altijd en overal Kris Luyten Karin coninx 17 januari 2002 Samenvatting De informatica kende een ware revolutie voordat men tot de desktop PC gekomen is. 20 jaar

Nadere informatie

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

Kleine cursus PHP5. Auteur: Raymond Moesker

Kleine cursus PHP5. Auteur: Raymond Moesker Kleine cursus PHP5 Auteur: Raymond Moesker Kleine cursus PHP PHP is platform en CPU onafhankelijk, open source, snel, heeft een grote userbase, het is object georiënteerd, het wordt omarmd door grote bedrijven

Nadere informatie

Numerieke aspecten van de vergelijking van Cantor. Opgedragen aan Th. J. Dekker. H. W. Lenstra, Jr.

Numerieke aspecten van de vergelijking van Cantor. Opgedragen aan Th. J. Dekker. H. W. Lenstra, Jr. Numerieke aspecten van de vergelijking van Cantor Opgedragen aan Th. J. Dekker H. W. Lenstra, Jr. Uit de lineaire algebra is bekend dat het aantal oplossingen van een systeem lineaire vergelijkingen gelijk

Nadere informatie

Installatie Today s Pro

Installatie Today s Pro Installatie Today s Pro Ga je voor de eerste keer met Today s Pro aan de slag, heb je een nieuwe computer aangeschaft, of wil je Today s Pro gewoon opnieuw installeren? In deze instructie lees je hoe je

Nadere informatie

Wijzigingen volledig onder controle en geborgd

Wijzigingen volledig onder controle en geborgd Installation Management Platform IMProve 2014 is het ultieme hulpmiddel om het beheer van uw (terminal) serverfarm continu, stap voor stap, op een hoger niveau te brengen. Gedocumenteerd, geborgd en reproduceerbaar

Nadere informatie

Microsoft Excel. It s all about Excel - VBA

Microsoft Excel. It s all about Excel - VBA X Microsoft Excel Stap in de wereld van Visual Basic for Applications (VBA) binnen het Microsoft Office programma Excel. Leer hoe deze programmeertaal precies in elkaar zit en hoe u deze in de dagelijkse

Nadere informatie

Test rapportage Waarom eigenlijk?

Test rapportage Waarom eigenlijk? Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

VERZAMELINGEN EN AFBEELDINGEN

VERZAMELINGEN EN AFBEELDINGEN I VERZAMELINGEN EN AFBEELDINGEN Het begrip verzameling kennen we uit het dagelijks leven: een bibliotheek bevat een verzameling van boeken, een museum een verzameling van kunstvoorwerpen. We kennen verzamelingen

Nadere informatie

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Mislukken Slagen gegarandeerd 2 Mislukken Slagen gegarandeerd Management verwacht onmiddellijk R.O.I. Doel:

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

Nadere informatie

Practicumopgave Mehmet Oktener

Practicumopgave Mehmet Oktener Practicumopgave Mehmet Oktener Alban Ponse Kruislaan 403, kr. 2.45 tel. 5257592 e-mail: alban@science.uva.nl Algemeen. In deze serie opgaven komt de specificatie van data typen aan de orde. Je wordt geacht

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

Nadere informatie

CONFIDENTIEEL. EIB-RPT-880076 3 van 12. Samenvatting

CONFIDENTIEEL. EIB-RPT-880076 3 van 12. Samenvatting EIB-RPT-880076 3 van 12 Samenvatting Inleiding Dit rapport beschrijft de prototypekeuring van de SDUMJGA stemmachine RS- Vote. De RS-Vote stemmachine is bedoeld voor elektronisch gefaseerd stemmen en is

Nadere informatie

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

Sjabloon testspecificatie. <>

Sjabloon testspecificatie. <<Organisatie>> Sjabloon testspecificatie SYSQA B.V. Almere : Status : Opgesteld door : Organisatie Pagina 2 van 5 Inhoudsopgave Inleiding...3 1 Analyse functiebeschrijving...4

Nadere informatie

Modulewijzer tirprog02/infprg01, programmeren in Java 2

Modulewijzer tirprog02/infprg01, programmeren in Java 2 Modulewijzer tirprog02/infprg01, programmeren in Java 2 W. Oele 17 november 2009 1 Inhoudsopgave 1 Inleiding 3 2 Studiehouding 3 3 Voorkennis 4 4 Inhoud van deze module 5 5 Leermiddelen 5 6 Theorie en

Nadere informatie

Tools voor canonieke datamodellering Bert Dingemans

Tools voor canonieke datamodellering Bert Dingemans Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze

Nadere informatie

Inhoudsopgave. Hoofdstuk 1.RMI...2

Inhoudsopgave. Hoofdstuk 1.RMI...2 - CORBA Inhoudsopgave Hoofdstuk 1.RMI...2 1.1.Inleiding...2 1.2.De remote...4 1.3.Het remote...5 1.4.De server...6 1.5.De server opstarten...8 1.6.De client applicatie...8 1.7.De stub en skeleton en...10

Nadere informatie

De Vergeten Abstracties

De Vergeten Abstracties De Vergeten Abstracties Cesario Ramos Senior Consultant bij Xebia B.V. 2009 Inleiding Rollen zijn een belangrijk concept in object georiënteerde software ontwikkeling dat vaak vergeten wordt. Het gebruik

Nadere informatie

Nederlandse samenvatting (Dutch summary)

Nederlandse samenvatting (Dutch summary) Nederlandse samenvatting (Dutch summary) Ditproefschriftpresenteerteen raamwerk voorhetontwikkelenvanparallellestreaming applicaties voor heterogene architecturen met meerdere rekeneenheden op een chip.

Nadere informatie

Dynamische webapplicaties in Java

Dynamische webapplicaties in Java Dynamische webapplicaties in Java October 7, 2006 In java is het mogelijk dynamische webpagina s te implementeren. De code om de dynamische gegevens te genereren staat in servlets of Java Server Pages

Nadere informatie

Software Engineering Groep 4

Software Engineering Groep 4 Software Engineering Groep 4 Software Design Description Jeroen Nyckees (Design Manager) Jan-Pieter Hubrecht (Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 11 december 2011

Nadere informatie

Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden.

Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden. Herhaling Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden. De basisbouwsteen is het object; een geïntegreerde eenheid van data en operaties werkend op deze

Nadere informatie