Tools en technieken voor kwaliteitsbepaling van productsoftware
|
|
- Nelly van de Velden
- 8 jaren geleden
- Aantal bezoeken:
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
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 informatieTesten 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 informatieTentamen Formele Methoden voor Software Engineering (213520)
Tentamen Formele Methoden voor Software Engineering (213520) 15 april 2010, 8:45 12:15 uur. BELANGRIJK: geef op je tentamen duidelijk aan: je studierichting of je beide huiswerkopgaven gemaakt hebt, en
Nadere informatieSoftware 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 informatieSoftware 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 informatieSoftware 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 informatieSmartTestAssistant. 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 informatieTentamen Systeemontwikkeling 1 (I00100)
Tentamen Systeemontwikkeling 1 (I00100) 26 januari 2004, 10:30 12:30 Naam: Studentnummer: Noteer op dit tentamen als eerste je naam en studentnummer Er mogen geen boeken, aantekeningen, etc. worden geraadpleegd
Nadere informatieRUM. 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 informatieSoftware 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 informatieClean 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 informatieling van die eigenschap binnen het model geldt. In het bijzonder bij het wiskundig modelleren van een programma kan een eigenschap met wiskundige zeke
De Nederlandse samenvatting van een proefschrift is bij uitstek het onderdeel van het proefschrift dat door familie en vrienden wordt gelezen. Voor hen wil ik deze samenvatting dan ook schrijven als een
Nadere informatieAFO 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 informatieMaak automatisch een geschikte configuratie van een softwaresysteem;
Joost Vennekens joost.vennekens@kuleuven.be Technologiecampus De Nayer We zijn geïnteresseerd in het oplossen van combinatorische problemen, zoals bijvoorbeeld: Bereken een lessenrooster die aan een aantal
Nadere informatieStichting 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 informatieDynamiek 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 informatieTentamen Formele Methoden voor Software Engineering (213520)
Tentamen Formele Methoden voor Software Engineering (213520) 2 juli 2009, 13:30-17:00 uur. BELANGRIJK: geef op je tentamen duidelijk aan: je studierichting of je beide huiswerkopgaven gemaakt hebt, en
Nadere informatieZelftest 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 informatieProduct 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 informatieSmartTestAssistant. 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 informatieAutomaten. Informatica, UvA. Yde Venema
Automaten Informatica, UvA Yde Venema i Inhoud Inleiding 1 1 Formele talen en reguliere expressies 2 1.1 Formele talen.................................... 2 1.2 Reguliere expressies................................
Nadere informatieKenmerken 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 informatieVAN 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 informatieEen 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 informatieSoftware Test Document
Software Test Document 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
Nadere informatieOrganisatie 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 informatieInhoud. 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 informatieBDD/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 informatieDie 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 informatieJava Les 3 Theorie Herhaal structuren
Java Les 3 Theorie Herhaal structuren Algemeen Een herhaal structuur een is programmeertechniek waarbij bepaalde Java instructies worden herhaald net zo lang tot een bepaalde voorwaarde is bereikt. Een
Nadere informatieProgrammeren (1) Examen NAAM:
Schrijf al je antwoorden op deze vragenbladen (op de plaats die daarvoor is voorzien) en geef zowel klad als net af. Bij heel wat vragen moet je zelf Java-code schrijven. Hou dit kort en bondig. Je hoeft
Nadere informatieVraag 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 informatieTentamen 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 informatieDOMjudge 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 informatieTeamhandleiding 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 informatieSoftware 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 informatieDe vereenvoudigde beslistabel
De vereenvoudigde beslistabel Auteur: Patrick Zweegman Datum: 08-12-2004 Versie: 1.0 De aanleiding Diverse testafdelingen gebruiken de beslistabellen techniek (zie TMap, paragraaf 15.5 Beslissingstabellentest,
Nadere informatieTechnisch 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 informatieSQL 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 informatieVakgroep 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 informatieFactsheet 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 informatiePlan 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 informatieSocio-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 informatieExtended 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 informatieARE 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 informatieCover 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 informatieAbstraheren 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 informatieSoftware 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 informatieAls 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 informatieEindtoets. 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 informatieHOOFDSTUK 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 informatiePracticumopgave 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 informatieCover Page. The handle holds various files of this Leiden University dissertation.
Cover Page The handle http://hdl.handle.net/1887/41339 holds various files of this Leiden University dissertation. Author: Karasneh, B.H.A. Title: An online corpus of UML Design Models : construction and
Nadere informatieEvo 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 informatieB.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 informatieCanonieke 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 informatieWijzigingen 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 informatieGids voor geautomatiseerd handelen met Proorder
Gids voor geautomatiseerd handelen met Proorder INHoud Over deze gids 01 Uw strategie creëren 02 Uw strategie testen 04 Uw strategie laten lopen 05 Uw strategie beheren 06 Over deze gids Deze korte gids
Nadere informatieTechnische architectuur Beschrijving
A gemeente Eindhoven Technische architectuur Beschrijving Specificatiecriteria Versie 1.1 A. van Loenen Technisch Beleidsadviseur B&E 21-Sep-2011 avl/fd11027578 Colofon Uitgave Gemeente Eindhoven Realisatie
Nadere informatieUML. 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 informatieBellen 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 informatieSoftware 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 informatieINSTALLATIE EXCHANGE CONNECTOR
HANDLEIDING INSTALLATIE EXCHANGE CONNECTOR INSTALLATIE EXCHANGE CONNECTOR 0 0 HANDLEIDING INSTALLATIE EXCHANGE CONNECTOR INSTALLATIE EXCHANGE CONNECTOR HANDLEIDING datum: 10-08-2018 1 Inleiding... 1 2
Nadere informatieProgrammeren: 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 informatierh276a 0 We breiden nu bovenstaand programmafragment uit door assignments toe te voegen aan een nieuwe variabele m, aldus:
rh276a 0 Een paar praktische stellinkjes 0 Standaardeindiging stelling (standaardeindiging 0) : Het volgende programmafragment eindigt, heeft als repetitie-invariant 0 n n N en als variante functie N n
Nadere informatieBijlage 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 informatieAgenda. Introductie Aan het werk Conclusie / restrospective
Agenda Introductie 13.45 14.30 Aan het werk 14.30 16.30 Conclusie / restrospective 16.30 17.00 Introductie High performance Testing Voorstellen Waar ben je echt goed in (3 minuten) Teams vormen op basis
Nadere informatieDe praktische kant van de Cloud De Cloud en modellen maken pay per use mogelijk
De praktische kant van de Cloud De Cloud en modellen maken pay per use mogelijk 04-10-2011 Thomas Veltman & Andréas Prins Agenda presentatie Trends in software ontwikkeling en testen Cloud als hulpmiddel
Nadere informatieOpdracht 1 Topics on Parsing and Formal Languages - fall 2010
Opdracht 1 Topics on Parsing and Formal Languages - fall 2010 Rick van der Zwet 8 december 2010 Samenvatting Dit schrijven zal uitwerkingen van opgaven behandelen uit het boek [JS2009]
Nadere informatieCurriculum 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 informatieMaster 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 informatieFIT TEST 4 MENDIX. Low code & kwaliteit
FIT TEST 4 MENDIX Low code & kwaliteit 2 TODAY S TOPIC: Low code & kwaliteit 1. Definitie low code wat maakt low coding platformen waardevol? 2. Kwaliteit - staat low code gelijk aan hoge kwaliteit? 3.
Nadere informatieSoftware 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 informatieChris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren
Chris de Kok 223548 TDI 3 Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Inhoud Inleiding... 3 Black box / White box... 3 XP... 3 SimpleTest... 3 Eclipse plugin... 4 GroupTest...
Nadere informatieDATAMODELLERING DATA MAPPING MODEL
DATAMODELLERING DATA MAPPING MODEL Inleiding In dit whitepaper wordt de datamodelleervorm data mapping model beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil
Nadere informatieKwaliteitsbewaking 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 informatiecase: toestandsdiagrammen
Hoofdstuk 13 case: toestandsdiagrammen In dit hoofdstuk wordt het maken van de eerste versie van de toestandsdiagrammen voor het boodschappensysteem van Hans en Jacqueline uitgewerkt. 13.1 Vind klassen
Nadere informatieOpdracht 1 Topics on Parsing and Formal Languages - fall 2010
Opdracht 1 Topics on Parsing and Formal Languages - fall 2010 Rick van der Zwet 13 november 2010 Samenvatting Dit schrijven zal uitwerkingen van opgaven behandelen uit het boek [JS2009]
Nadere informatieSoftware 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 informatieMarktscan Digikoppeling 2017
Testrapport Marktscan Digikoppeling 2017 Versie: 1.0 Datum: 18-6-2015 Auteur: egem Datum : 2 juni 2017 Versie : 1.0 Inhoudsopgave 1. Inleiding... 2 2. Managementsamenvatting... 3 3. Testopzet... 4 3.1
Nadere informatieVereiste kennis. 1 Java-editor. 2 Het compileren van een programma
3 Vereiste kennis Dit boek richt zich op het leren programmeren door het oefenen met programmeercodes. Veel theorie komt in het begin niet aan de orde. Dat is een grote uitdaging want het is niet makkelijk
Nadere informatieISACA 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 informatie1 Inleiding. 3 Handmatig... invoeren zaken basis 4 Verwerken... zaken 5 Afhandelen... van zaken. 7 Uitgebreidere... zaak opties
2 Supportdesk Pro Introductie Inhoudsopgave I Supportdesk Pro 3 1 Inleiding... 3 2 Werkwijze... 3 II Zaken 4 1 Introductie... 4 2 Zaken beheren... 4 3 Handmatig... invoeren zaken basis 4 4 Verwerken...
Nadere informatieADVANCED KNOWLEDGE SERVICES (AKS )
ADVANCED KNOWLEDGE SERVICES (AKS ) EEN KRACHTIG NIEUW BUSINESS IMPROVEMENT PARADIGMA OM COMPLEXITEIT TE BEHEERSEN DEMO AKS BUSINESS BENEFITS: VAKANTIEDAGEN SOP EEN KRACHTIG NIEUW BUSINESS IMPROVEMENT PARADIGMA
Nadere informatieWerkgroep ISO29119. TestNet thema-avond 9 oktober 2014
Werkgroep ISO29119 TestNet thema-avond 9 oktober 2014 Is dit n gezonde maaltijd? Ja toch!! Om jezelf een oordeel te kunnen vormen heb je informatie nodig!! Vandaag brengen we kennis en informatie bij elkaar
Nadere informatieFunctiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.
Functiepuntanalyse 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 2 WAT
Nadere informatieTentamen Objectgeorienteerd Programmeren TI februari Afdeling ST Faculteit EWI TU Delft
I ' Tentamen Objectgeorienteerd Programmeren TI 1200 1 februari 2012 9.00-12.00 Afdeling ST Faculteit EWI TU Delft Bij dit tentamen mag je geen gebruik maken van hulpmiddelen zoals boek of slides. Dit
Nadere informatieTentamen in2705 Software Engineering
Tentamen in2705 Software Engineering Voorbeeld (bijna tweemaal te groot) U mag meenemen naar dit tentamen: Lethbridge, afdrukken PPT slides, afdrukken handouts. 1. De TU wil een nieuw systeem ontwikkelen
Nadere informatieVoorstelling van de behoeftenanalyse-tool voor deelnemers
Voorstelling van de behoeftenanalyse-tool voor deelnemers Het succes van de opleiding hangt af van de homogeniteit van de groepen. Een analyse van de behoeften om het niveau tebepalen en zo tot homogene
Nadere informatieSoftware 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 informatieSocial Key Performance Indicators en meetbare resultaten Door: Rob van den Brink
Social Key Performance Indicators en meetbare resultaten Door: Rob van den Brink Wat is de ROI van sociale media? Dat is misschien wel de meest gestelde vraag in zakelijke media het afgelopen jaar. Er
Nadere informatieHet besturingssysteem of operating system, vaak afgekort tot OS is verantwoordelijk voor de communicatie van de software met de hardware.
Het besturingssysteem of operating system, vaak afgekort tot OS is verantwoordelijk voor de communicatie van de software met de hardware. Het vormt een schil tussen de applicatiesoftware en de hardware
Nadere informatieOntwerp van Algoritmen: opgaven weken 3 en 4
0 Ontwerp van Algoritmen: opgaven weken 3 en 4 Voor alle volgende opgaven over programmaatjes geldt de spelregel: formuleer altijd eerst alle bewijsverplichtingen. selectie 45. (tail distribution)(prima
Nadere informatieEIGENSCHAPPEN CONVERGED HARDWARE
EIGENSCHAPPEN CONVERGED HARDWARE Eigenschappen Converged Hardware 1 van 8 Document Informatie Versie Datum Omschrijving Auteur(s) 0.1 29-09-2015 Draft Remco Nijkamp 0.2 29-09-2015 Volgende Versie opgesteld
Nadere informatieSMC-web. Introduction to SMCweb Title Page. Handleiding SMC-web. 2011 Security Monitoring Centre
SMC-web Handleiding SMC-web Introduction to SMCweb Title Page CSMCweb Handleiding SMCweb Table of Contents Over dit document... 1 Organisatie... 1 Doelgroep... 1 PDF Document... 1 Introductie... 2 SMCweb
Nadere informatieNumerieke 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 informatieINTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer
INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer Van toepassing op : BRL SIKB 0100, versie 4.0-29 juni 2005 Versie en datum vaststelling : 1, 3 september 2009 Datum in werking treden : 7 september
Nadere informatieOmschrijving enquête module VervangingsManager webapplicatie
Omschrijving enquête module VervangingsManager webapplicatie OnderwijsApps B.V. Innovatieweg 26-03 7007 CD DOETINCHEM Tel. 0314-368250 Postbus 704 7000 AS DOETINCHEM KvK 51377888 www.onderwijsapps.nl info@onderwijsapps.nl
Nadere informatie