Meten aan software(kwaliteit) Dr. Ir. Jacob Brunekreef Lector Softwarekwaliteit Instituut voor Informatica

Maat: px
Weergave met pagina beginnen:

Download "Meten aan software(kwaliteit) Dr. Ir. Jacob Brunekreef Lector Softwarekwaliteit Instituut voor Informatica"

Transcriptie

1 Een grijs gat Meten aan software(kwaliteit) Dr Ir Jacob Brunekreef Lector Softwarekwaliteit Instituut voor Informatica Openbare Les Uitgesproken op 1 november 2007 Hogeschool van Amsterdam

2 In many ways, the software engineering process is an informational black hole it draws in money and resources like a magnet but little data emerges (HA Rubin) Measurement has been the basis of all science and engineering progress except for software (Capers Jones)

3 Geloven, weten en meten Software engineering is het vakgebied dat zich bezighoudt met het ontwerpen, bouwen, testen en beheren van software Het vakgebied is nog jong Het idee om methoden en technieken uit bestaande engineering disciplines in te zetten voor het ontwikkelen van software stamt uit het eind van de jaren zestig van de vorige eeuw Het was een antwoord op wat toen de software crisis werd genoemd: een overvloed aan problemen met slecht functionerende software, ontwikkeld in softwareprojecten die te laat opleverden en te veel kostten Aan de basis van gevestigde engineering disciplines als elektrotechniek, werktuigbouwkunde en chemische technologie staat de natuurwetenschappelijke benadering Het ontstaan van die benadering wordt uitgebreid beschreven in De mechanisering van het wereldbeeld van de hand van de Utrechtse hoogleraar EJ Dijksterhuis (Dijksterhuis, 1950) In dit monumentale boek beschrijft hij de geboorte van de klassieke natuurkunde, waarbij experimenten en wiskundige afleiding een prominente rol spelen De voorganger daarvan, de antieke natuurkunde, was primair gebaseerd op principes die wij nu samenvatten onder de noemer metafysica : religieuze en filosofische invloeden op de theorievorming, het primaat van de theorie boven het experiment Pas nadat de natuurkunde zich ontworsteld had aan haar metafysische ketenen ontstond een wetenschap die nu nog steeds model staat voor de (natuur)wetenschappelijke praktijk Een wetenschap die aan de basis heeft gestaan van grote maatschappelijke veranderingen, zoals de industriële revolutie De geboorte van de klassieke natuurkunde is niet vast te pinnen op één enkele gebeurtenis of één enkel tijdstip Er is sprake van een periode waarin oude inzichten langzaam afsterven, nieuwe inzichten langzaam rijpen Opvallend is de rol van de techniek: de sterk toegenomen kwaliteit van instrumenten in de zestiende en zeventiende eeuw gaf een enorme impuls aan het aantal en het niveau van experimenten Daarmee werd het mogelijk een wetenschap te ontwikkelen die gebaseerd was op nauwkeurige waarnemingen Enigszins generaliserend kunnen we zeggen dat de belangrijke rol die het meten (waarnemen, het uitvoeren van experimenten) toegewezen krijgt in het wetenschappelijk bedrijf de overgang markeert van het geloven naar het weten We zouden dan ook mogen verwachten dat meten een prominente plaats inneemt in de ontwikkeling van de software engineering als toegepaste wetenschap, maar zoals de citaten aan het begin van deze openbare les aangeven dit is ogenschijnlijk niet echt het geval Die citaten stammen uit het begin van 3 een grijs gat

4 de jaren negentig van de vorige eeuw (Rubin, 1993; Jones, 1991) Sindsdien is er in mijn ogen wel het één en ander ten goede veranderd, zonder dat er nu sprake is van een optimale situatie Zodat we wellicht niet meer moeten spreken van een black hole, een zwart gat, maar eerder van een grijs gat : nog steeds wordt er binnen de software engineering te weinig aandacht besteed aan het meten en aan het analyseren van meetgegevens Wat kunnen we eigenlijk meten aan software? Hoe moeten we meten? Wat kunnen we doen met meetresultaten? In deze openbare les wil ik op deze vragen ingaan vanuit de overtuiging dat het vakgebied van software engineering alleen werkelijk voortgang kan boeken als het meten een meer centrale plaats zal gaan innemen 4 Dr Ir Jacob Brunekreef

5 ICT is overal De producten van de digitale techniek, in het bijzonder de computer, hebben zich een essentiële plaats in de maatschappij veroverd: een ontwikkeling zonder weerga in de geschiedenis der techniek Dit is geen zinsnede uit een recente populairwetenschappelijke beschouwing over ICT, maar een citaat uit de inaugurele rede van mijn leermeester Gerrit Blaauw, uitgesproken in 1966 op de toenmalige TH Twente in Enschede (Blaauw, 1966) De onderkenning van het grote maatschappelijke belang van ICT is dus al zeker 40 jaar oud Tegenwoordig is ICT alom aanwezig in onze samenleving Vrijwel ieder mens in de westerse wereld komt een aantal keren per dag in aanraking met toepassingen van ICT Zo maken een treinkaartje uit een automaat, een sms-berichtje op een mobiele telefoon en route-instructies uit een routeplanner stuk voor stuk gebruik van ICT ICT verandert de maatschappij Reisbureaus zijn grotendeels uit het straatbeeld verdwenen; een reis boek je s avonds achter je pc, op het internet, niet meer aan een balie Artikelen worden via een virtuele marktplaats of veiling verkocht en gekocht, niet meer in een winkel Kennis haal je niet uit een boek maar van het internet Je bent overal bereikbaar, per telefoon, sms of De ICT-sector is ook van groot economisch belang Met een aandeel in de nationale productiewaarde van ruim 5% en een aandeel van ruim 4% als het gaat om werkverschaffing is de ICT-sector van substantiële waarde voor de BV Nederland (CBS, 2006) De ontwikkelingen in de ICT zijn voor een belangrijk deel mogelijk gemaakt door de stormachtige vooruitgang op het terrein van de hardware In ruim 60 jaar tijd is de ruimte die nodig is voor een elementaire digitale schakeling gekrompen van enkele kubieke centimeters (een elektronenbuis) tot enkele kubieke micrometers of zelfs nanometers (een halfgeleiderschakeling), en de tijd die nodig is om die elementaire schakelaar om te zetten, is teruggebracht van tienden van seconden tot nanoseconden De snelheid van de ontwikkeling van hardware werd al in 1965 vastgelegd in de Wet van Moore: iedere twee jaar verdubbelt het aantal transistors op een chip Figuur 1 toont de schets die ten grondslag lag aan deze wet De lijn voor 1970 was een voorspelling 5 een grijs gat

6 Figuur 1 Gordon Moores oorspronkelijke grafiek uit 1965 Al die krachtige hardware functioneert bij de gratie van software Die levert de instructies op basis waarvan computers, mobiele telefoons en pinautomaten functioneren Ook het produceren van software heeft in de afgelopen jaren een enorme ontwikkeling doorgemaakt De eerste computers werden geprogrammeerd met behulp van stekkers en snoeren Al snel werden computerprogramma s opgeslagen in het geheugen van de computer Aanvankelijk werden deze programma s opgesteld in machinetaal: een lijst met instructies die direct uitvoerbaar is door de computer Omdat deze taal voor de mens vrijwel onbegrijpelijk was (en is), werden al in de jaren vijftig van de vorige eeuw kunstmatige talen ontwikkeld die voor mensen begrijpelijker waren, maar verder van de machine afstonden Deze talen dienden vaak specifieke doeleinden, zoals de taal Cobol voor het ontwikkelen van administratieve software en de taal Fortran voor wetenschappelijke rekenintensieve software Deze talen waren de voorlopers van een generatie van imperatieve of procedurele talen, met groepen opdrachten (statements) die nog vrij direct om te zetten waren in instructies voor een machine Sinds de jaren tachtig van de vorige eeuw wordt er in sterk toenemende mate geprogrammeerd in zogenaamde object-georiënteerde talen Daarbij dienen klassen van objecten, met welgedefinieerde operaties op die objecten, als basis voor een programma Hedendaagse voorbeelden van talen uit deze categorie zijn Java, C# en C++ 6 Dr Ir Jacob Brunekreef

7 Gezien de succesvolle aanwezigheid alom van ICT zouden we mogen veronderstellen dat het wel goed zit met de kwaliteit van de software die al die toepassingen aanstuurt Helaas, niet alleen het succesverhaal maar ook het falen van software is legendarisch Lijsten met softwarefouten zijn te vinden op het internet; zie bijvoorbeeld en Soms is een fout hilarisch: in het najaar van 2006 ontvingen vrijwel alle werknemers van de Universiteit van Groningen een bericht waarin hun ontslag werd aangekondigd Foutje van de computer(software) En, in februari 2007 lag het treinverkeer van en naar Amsterdam een aantal uren plat door een hardwarestoring Wie tijdens die uren probeerde op de website van de NS meer informatie over deze storing te verkrijgen, kreeg een wel heel originele storingsmelding (zie figuur 2) Figuur 2 Storingsmelding NS, februari 2007 Er zijn ook dramatischer voorbeelden te geven van het falen van software, ongelukken met ruimtevaartuigen, vliegtuigen of medische software, waarbij mensenlevens verloren zijn gegaan Niet alleen het product software, ook projecten waarin software wordt geproduceerd hebben een bedenkelijke reputatie Ze worden beëindigd zonder dat ze enig resultaat hebben opgeleverd en kosten veel meer tijd en/of geld dan 7 een grijs gat

8 oorspronkelijk was begroot Beroemd is het Chaos Report van de Standish Group uit 1994 Dit rapport bevat onthutsende cijfers over het percentage softwareprojecten dat voortijdig gestrand is tegenover het percentage projecten dat op tijd voltooid is (zie tabel 1) Grote bedrijven Middelgrote bedrijven Kleine bedrijven Op tijd gereed 9% 16% 28% Over tijd/over budget 62% 47% 50% Voortijdig beëindigd 29% 37% 21% Tabel 1 Slagingspercentage softwareprojecten in de Verenigde Staten, 1994 De cijfers hebben betrekking op de situatie in de Verenigde Staten, maar er is weinig reden om aan te nemen dat de situatie in Europa in 1994 anders lag Onderzoek van recenter datum van dezelfde partij laat overigens betere cijfers zien In 2006 was 35% van de projecten succesvol afgerond, was 46% van de projecten over tijd/over budget en stopte 19% van de projecten voortijdig Maar, dit zijn nog steeds niet cijfers om trots op te zijn! De Standish Group heeft in haar onderzoek naar het slagen en falen van softwareprojecten een top-10 lijst van oorzaken opgesteld (zie tabel 2) Top-10 factoren slagen projecten Top-10 factoren falen projecten 1 Betrokkenheid gebruikers 1 Gebrekkige specificaties 2 Support uitvoerend management 2 Onvoldoende betrokkenheid gebruikers 3 Duidelijke specificaties 3 Gebrek aan personeel, tools 4 Heldere planning 4 Onrealistische verwachtingen 5 Realistische verwachtingen 5 Gebrek aan management support 6 Kleine project milestones 6 Tussentijds wijzigen specificaties 7 Competent personeel 7 Gebrek aan planning 8 Eigenaarschap 8 Niet meer nodig 9 Heldere visie en doelen 9 Gebrek aan IT-management 10 Hardwerkend en betrokken personeel 10 Gebrek aan technische kennis, vaardigheden Tabel 2 Top-10 factoren voor het slagen en falen van softwareprojecten 8 Dr Ir Jacob Brunekreef

9 Opvallend is in de eerste plaats de betrokkenheid van de gebruikers De aanwezigheid van die betrokkenheid is een belangrijke slaagfactor voor projecten, de afwezigheid een belangrijke faalfactor Moderne ontwikkelmethoden als DSDM en XP propageren dan ook terecht een sterke betrokkenheid van de gebruiker van begin tot eind Helaas moet ik vanuit mijn eigen softwarepraktijk constateren dat er vaak onvoldoende invulling aan dit punt wordt gegeven Soms uit onvermogen, soms uit onwil, worden gebruikers pas in een zeer laat stadium, bij het acceptatietesten, betrokken bij een ontwikkelproject, met alle gevolgen van dien In de tweede plaats valt het belang van goede specificaties op Specificaties worden opgesteld door vertegenwoordigers van toekomstige gebruikers Ze dienen als opdrachtomschrijving voor softwareontwerpers Volgens sommigen is hier sprake van een fundamenteel communicatieprobleem In zijn boek The Inmates Are Running The Asylum introduceert Alan Cooper het begrip cognitive friction Hieronder verstaat hij de mentale kloof tussen de opdrachtgever/gebruiker aan de ene kant en de ontwerper aan de andere kant: de één leeft in een wereld van gewenste functionaliteiten, de ander in een wereld van mogelijke features (Cooper, 2004) Het tussentijds wijzigen van specificaties geldt als een belangrijke reden voor het falen van projecten Dit is voorstelbaar Maar, zeker bij langer lopende projecten is het een gegeven dat de specificaties tijdens het project wijzigen De buitenwereld staat immers niet stil De huidige generatie ontwikkelmethoden is daar dan ook tot op zekere hoogte op ingesteld Als lector aan een onderwijsinstelling doet het me goed te zien dat ook de kennis en vaardigheden van personeel ertoe doen, zowel in positieve zin (competent, hardwerkend en betrokken personeel is belangrijk voor het slagen van een project), als in negatieve zin (gebrek aan technische kennis en vaardigheden is een faalfactor) En dan is er natuurlijk de planning en aansturing van een project Een heldere planning, realistische verwachtingen en kleine project milestones zijn succesfactoren voor een softwareproject Daartegenover staan een gebrekkige planning, onrealistische verwachtingen en gebrek aan IT-management als faalfactoren Vooral het plannen, begroten en aansturen van grote projecten is een moeizame zaak Dit geldt overigens niet alleen voor softwareprojecten Ook grote infrastructuurprojecten in Nederland, zoals de Betuwelijn en de HSL, kampen met forse vertragingen en budgetoverschrijdingen En ook hier zien we wat doorgaans als een van de grootste bedreigingen van de voortgang in software- 9 een grijs gat

10 projecten wordt gezien: het tijdens de rit wijzigen van het programma van eisen en wensen De beveiligingssystemen die nu worden voorgeschreven voor de HSL zijn gebaseerd op eisen die nog niet bestonden bij de start van het project! 10 Dr Ir Jacob Brunekreef

11 De virtuele wereld van software Zowel het succes als het falen van ICT, van softwareproducten en -projecten, is zeer zichtbaar in onze maatschappij Voor het vakgebied van de software engineering ligt er de uitdaging om het succespercentage te verhogen door permanente aandacht voor kwaliteitsverbetering Het aanpakken van een probleem begint met het in kaart brengen van wat er nu feitelijk aan de hand is Daarbij speelt meten een belangrijke, zo niet centrale rol In de fysieke wereld zijn we zeer vertrouwd met meten Tal van eigenschappen van objecten worden uitgedrukt in een meeteenheid: de lengte van een persoon in meters, de massa van een auto in kilogrammen, de elektrische spanning van een batterij in volt en ga zo maar door Software functioneert in een virtuele wereld Dat is een andere wereld dan de fysieke wereld, wat betekent: andere eigenschappen, andere meeteenheden en andere meetprocessen Voordat ik daar nader op inga, wil ik eerst enkele kenmerken van die virtuele wereld aanstippen die een rol spelen bij de mogelijkheden en onmogelijkheden van het meten aan software 1 De relatie tussen statische en dynamische eigenschappen is indirect Gloeilampen worden gemaakt om licht te geven Auto s worden gemaakt om in te rijden In de fysieke wereld kunnen direct waarneembare statische eigenschappen al duidelijk maken dat een product niet naar wens zal functioneren Een gloeilamp zonder fitting, een auto met vierkante wielen Al tijdens het ontwerpen en bouwen wordt duidelijk dat de gevraagde functie (licht geven, verplaatsen van personen) niet geleverd kan worden Software wordt gemaakt om gewenst gedrag te vertonen als het programma gedraaid wordt Software bestaat uit een aantal regels met programmacode Aan die programmacode zelf is niet in één oogopslag te zien of er problemen zullen zijn bij dit dynamische gedrag Daarin onderscheidt software zich van engineering-producten in de fysieke wereld Bij software die functioneert in een virtuele wereld is de directe relatie tussen statische en dynamische eigenschappen niet aanwezig 2 De grenzen van de virtuele wereld zijn niet helder In de fysieke wereld zorgen materiaaleigenschappen en natuurwetten voor een soort natuurlijke bovengrens voor wat betreft de mogelijkheden Een brug met een overspanning van 10 kilometer, een auto met een topsnelheid hoger dan 11 een grijs gat

12 het geluid, een kerncentrale die heel Nederland van stroom voorziet: het zijn toekomstdromen van futuristen De huidige generatie ingenieurs en constructeurs houdt zich er niet serieus mee bezig Zowel informatici als niet-informatici zijn bijzonder goed in het bedenken van complexe uitdagingen op softwaregebied, zonder dat ze een helder zicht hebben op de mogelijkheden om ze te realiseren Door het ontbreken van natuurlijke beperkingen is het niet altijd direct inzichtelijk dat de doelstellingen soms ver voorbij het haalbare liggen Zo zijn in het verleden tal van grote automatiseringstrajecten gestart die voortijdig gestopt zijn, zonder dat ze enig resultaat hebben opgeleverd Een berucht voorbeeld uit een wat verder verleden is het Strategic Defense Initiative (SDI) uit de jaren tachtig van de vorige eeuw, ook wel Star Wars genaamd: een computergestuurd raketschild in de ruimte dat de Verenigde Staten moest beschermen tegen raketaanvallen van buiten de VS In 1985 trok de bekende informaticus David Parnas zich terug uit dit project omdat hij de realisatie van de benodigde software op vakinhoudelijke gronden voor onmogelijk hield Zijn belangrijkste argumenten waren: inherent onvolledige specificaties (de kenmerken van een vijandige raket zijn pas met zekerheid bekend ten tijde van de aanval), het feit dat men het systeem niet kan testen in een realistische omgeving en het gegeven dat door de korte tijd waarin een aanval zich afspeelt een handmatige correctie van een foutieve beslissing niet mogelijk zal zijn (Parnas, 1985) Ook nu nog is voor grotere softwareprojecten de volledigheid van specificaties niet te garanderen en is een realistische testomgeving moeilijk of niet te realiseren Mede hierom hebben kleinere projecten nog steeds een grotere kans van slagen dan grote projecten 3 De virtuele wereld is discreet van karakter De fysieke wereld is voor het overgrote deel continue van karakter In een continue wereld leidt een kleine verandering of afwijking tot kleine gevolgen Eén wat zwakkere spaak in een wiel leidt niet direct tot het sneuvelen van een fiets Software in de virtuele wereld gedraagt zich anders Eén enkele foutieve actie in een programma kan leiden tot een 100% fout resultaat Dit discrete gedrag van programmatuur (overigens ook al gememoreerd door David Parnas in zijn eerdergenoemde artikel) maakt het bijzonder moeilijk om ongewenste resultaten te allen tijde te voorkomen In de fysieke (continue) wereld is overdimensionering een veelgebruikte techniek om potentiële problemen te voorkomen Maak de spaken in een wiel extra dik, zodat ze bij normale belasting nooit 12 Dr Ir Jacob Brunekreef

13 zullen buigen Een dergelijke aanpak is in een discrete wereld onzinnig, want het toevoegen van een paar extra statements verhoogt op geen enkele manier de betrouwbaarheid van een programma! 4 De virtuele wereld kent zeer veel verschillende toestanden We kunnen een computerprogramma beschouwen als een automaat met een aantal toestanden Door een externe prikkel (muisklik, menucommando, invoer van een getal) gaat de automaat over van de ene toestand naar een andere toestand Enig rekenwerk laat zien dat zelfs bij eenvoudige programma s het aantal mogelijke toestanden al snel in de miljoenen loopt Dat wil zeggen dat niet iedere toestand waarin het programma kan verkeren, getest kan worden voordat het programma in gebruik wordt genomen, en dat houdt op zijn beurt weer een fundamenteel risico in: een programma kan in een niet geteste toestand ongewenst gedrag vertonen 5 (Re)productie kost geen materiaal Aan het produceren van software zijn nagenoeg geen materiaalkosten verbonden Zeker als de productieomgeving (de hardware) al aanwezig is, zijn de kosten van het produceren van software volledig toe te schrijven aan de inzet van de benodigde menskracht Dit betekent dat een bestaand softwareproduct zonder verlies van materiaalkosten gewijzigd of zelfs weggegooid kan worden Moderne ontwikkelmethoden voor software maken gebruik van deze eigenschap: tussenproducten worden aan toekomstige gebruikers getoond, en als deze niet bevallen, worden er wijzigingen in doorgevoerd Dit is een belangrijk verschil met de fysieke wereld Als een productiestraat voor een auto er eenmaal staat, dan is het zeer kostbaar om daar veranderingen in aan te brengen In de klassieke engineering disciplines is alles er dan ook op gericht om éérst goed te ontwerpen en daarna pas te gaan bouwen, met als doel het aantal corrective actions tot een absoluut minimum te beperken Binnen de virtuele wereld is een bestand (programma, maar ook documenten, muziek, foto s, films) zeer eenvoudig en kosteloos te kopiëren Ook dit is een belangrijk verschil met de fysieke wereld Het ontwerpen en implementeren van een reproductieproces is een belangrijk aandachtsgebied binnen de klassieke engineering disciplines: hoe maak ik zo goed en goedkoop mogelijk grote aantallen gloeilampen, auto s, etc Binnen de virtuele wereld is het reproductieproces zeer eenvoudig en daarmee geen punt van aandacht/zorg (afgezien van auteursrechten of patenten, maar dat is een ander verhaal) 13 een grijs gat

14 Figuur 3 Onbeperkt kopiëren in de virtuele wereld Op basis van de genoemde punten is te verwachten dat werken in een virtuele wereld gebaseerd zal moeten zijn op andere inzichten dan werken in de fysieke wereld De klassieke engineering-aanpak, met ontwerpen op basis van materiaalkennis en natuurwetenschappelijke inzichten en bouwen en reproduceren op basis van beproefde constructiemethoden, is niet zonder meer overdraagbaar naar het terrein van de softwareontwikkeling Het vakgebied van software engineering is nu zo n zestig jaar onderweg met het verkennen van de mogelijkheden en onmogelijkheden van de virtuele wereld Gezien de tijd die de natuurwetenschappen nodig hebben gehad om zich te ontwikkelen tot hun huidige niveau mogen we nauwelijks verwachten dat de software engineering al tot volledige wasdom is gekomen In mijn ogen bevindt de ontwikkeling van software engineering als wetenschap zich in een fase die vergelijkbaar is met die van de natuurkunde in de zestiende, zeventiende eeuw Alleen is nu niet een mechanisering maar een virtualisering van het wereldbeeld aan de orde Oude inzichten die hun oorsprong hebben in de fysieke wereld gaan overboord Nieuwe inzichten zijn al volop aanwezig, maar moeten nog tot volle wasdom komen De geschiedenis heeft geleerd dat dit tijd kost Ook al gaan wetenschappelijke ontwikkelingen vandaag de dag razend snel, dan nog is niet te verwachten dat een totaal nieuwe wetenschap als software engineering zich in ruim een halve eeuw volledig kan ontwikkelen 14 Dr Ir Jacob Brunekreef

15 Bij het ontwikkelen van een eigen wetenschappelijke aanpak op het terrein van de software engineering speelt een bezinning op het meten aan software een belangrijke rol Hoe is de in andere wetenschappelijke disciplines zo succesvol gebleken empirische benadering te vertalen naar het specifieke domein van software engineering? 15 een grijs gat

16 Meten aan software Meten speelt in de natuurwetenschappen een cruciale rol Op basis van meetresultaten worden theorieën geverifieerd of gefalsifieerd en worden onvolkomenheden in theorieën aan het licht gebracht De natuurwetenschappen kennen een uitgebreide theorie en praktijk als het gaat om meten Begrippen als meetschaal, meeteenheid en meetfout zijn uitgebreid beschreven, nauwkeurig gedefinieerd Meten kan gezien worden als het (zo mogelijk kwantitatief) bepalen van een eigenschap (attribuut) van een object Met het vaststellen van een aantal verschillen tussen de virtuele wereld en fysieke wereld dient zich direct de vraag aan wat we kunnen meten in de virtuele wereld en hoe we dit moeten meten In deze paragraaf wordt een aantal direct meetbare eigenschappen (basismetrieken) benoemd voor zowel het product software als het proces van softwareontwikkeling (en -gebruik) Bij iedere eigenschap wordt een meeteenheid gegeven Ook wordt aandacht besteed aan de meetmethode Daarbij speelt het onderscheid tussen handmatig en geautomatiseerd een rol Sommige eigenschappen zijn alleen via persoonlijke waarneming/inspectie te meten, andere kunnen via de inzet van tools (meetinstrumenten) zonder menselijke tussenkomst gemeten worden Meten aan het product Een product kent dynamische en statische eigenschappen Dynamische eigenschappen, zoals de snelheid van een auto, de remweg, de CO2-uitstoot, hangen samen met het gebruik Statische eigenschappen zeggen iets over het product op zich: het gewicht, de lengte, de kleur van een auto De oudste vorm van meten van de dynamische eigenschappen van software is testen Door het programma te draaien op een computer kan een gebruiker, programmeur of beheerder waarnemen of het gedrag van het programma overeenkomt met de verwachtingen Daarbij wordt vooral gekeken naar de functionaliteit: is de gewenste functionaliteit beschikbaar, leidt het activeren van een functie met specifieke parameters tot het beoogde resultaat? Functionaliteit wordt doorgaans niet gemeten tijdens het reguliere gebruik, maar in een aparte testsituatie in een aparte testomgeving Een programmeur test vanuit een technische invalshoek of een module of functie correct werkt Een gebruiker test meestal het hele programma Hij controleert of het programma op de gewenste manier het bedrijfsproces van de gebruiker ondersteunt Functionaliteit wordt gemeten door een groot aantal nauwkeurig beschreven 16 Dr Ir Jacob Brunekreef

17 testgevallen af te lopen Per testgeval wordt een geïsoleerd stukje gedrag van het programma gecontroleerd Het is mogelijk om de uitkomsten van het testen uit te drukken in een getal, bijvoorbeeld het percentage testgevallen dat geslaagd is Dit soort percentages is doorgaans weinig zeggend: het falen van één enkele essentiële functie is veel belangrijker dan het correct functioneren van een aantal onbelangrijke functies Testen is voornamelijk een handmatige activiteit, die deels ondersteund wordt met tools Testen is een vak op zich Methodes als TMap zijn ontwikkeld om het testproces zorgvuldig vorm te geven, de juiste testgevallen vast te leggen (zie Pol et al, 2000) Het is belangrijk om te beseffen dat met testen wel de aanwezigheid van fouten/problemen kan worden aangetoond, maar nooit de afwezigheid Omdat we vrijwel nooit alle toestanden van het programma kunnen testen, verkrijgen we niet de garantie dat een programma absoluut zonder fouten is Naast functionaliteit zijn er ook andere dynamische eigenschappen die kunnen worden gemeten: Performance: hoe snel komt het programma met een reactie? Belasting: in hoeverre belast het draaien van het programma de hardware (processorcapaciteit, geheugencapaciteit, bandbreedte van het netwerk)? Beschikbaarheid: op welke momenten is het programma (niet) beschikbaar voor gebruikers? Incidenten: hoeveel klachten, vragen, suggesties worden door gebruikers en beheerders gemeld? Performance en belasting kunnen zowel gemeten worden in een testomgeving als in de productieomgeving (gebruikssituatie) Alleen in het laatste geval zijn de uitkomsten echt realistisch Hierbij kunnen harde data worden gemeten, zoals responsetijden en geheugenbeslag (bytes) Het meten van deze grootheden gebeurt vaak met behulp van specifieke systeemsoftware De beschikbaarheid kan alleen gemeten worden in de gebruiksfase In feite komt dit neer op het meten van tijdsintervallen waarin het programma wel of niet beschikbaar is voor de gebruikers Dit kan vrij eenvoudig geautomatiseerd gemeten worden, maar in de praktijk wordt het vaak handmatig vastgelegd Binnen meer professioneel ingerichte organisaties worden tijdens de gebruiksfase incidenten geregistreerd, bijvoorbeeld door een service deskhet aantal en de zwaarte van de incidenten zegt iets over de kwaliteit van het pro- 17 een grijs gat

18 gramma Het registreren en afhandelen van incidenten vindt zowel handmatig als geautomatiseerd plaats Sinds jaar en dag wordt er ook gemeten aan statische eigenschappen van software, door het inspecteren van programmacode en documentatie Bij de programmacode kunnen eigenschappen worden gemeten als omvang, structuur, complexiteit en kwaliteit Bij documentatie is het minder duidelijk wat er te meten is Volledigheid en actualiteit zijn binnen zekere grenzen objectief vast te stellen; bij inhoudelijke kwaliteit wordt dat lastiger Omvang programmacode Het is verrassend om te zien hoeveel meeteenheden er zijn om de omvang van programmacode in uit te drukken Waar in de fysieke wereld een lengtemaat als de meter een onbetwist uitgangspunt is om de omvang van een object te bepalen, zien we in de virtuele wereld van de software verschillende meeteenheden die gebaseerd zijn op verschillende uitgangspunten Zo kennen we de volgende meeteenheden: Bytes: het aantal bytes dat een programma in een geheugen in beslag neemt In de begintijd van de computer was geheugen een schaars goed De omvang van een programma uitgedrukt in bytes was in die tijd dan ook een belangrijk item Tegenwoordig is geheugen in (bijna) onbeperkte mate beschikbaar en speelt deze eenheid in de meeste gevallen een ondergeschikte rol De omvang in bytes wordt gemeten met behulp van systeemsoftware Regels code: een programma is opgebouwd uit regels Het lijkt dan ook voor de hand te liggen om de omvang van een programma uit te drukken in het aantal regels Echter, er is een aantal complicerende factoren Ieder programma bevat (als het goed is) regels met commentaar en lege regels Tellen deze (voor de verwerking door de computer inhoudsloze) regels ook mee voor het bepalen van de omvang? Daarnaast kan in een programma onderscheid worden gemaakt tussen wel en niet executeerbare regels code, tussen regels die wel en niet statements bevatten We zien dan ook dat de omvang van programmacode wordt uitgedrukt in verschillende eenheden: LOC (Lines Of Code), ELOC (Executable LOC), SLOC (Statement LOC) Het tellen van regels code gebeurt vrijwel altijd geautomatiseerd, vaak met behulp van specifieke software 18 Dr Ir Jacob Brunekreef

19 Functiepunten: eind jaren zeventig van de vorige eeuw is door Albrecht bij IBM een methode ontwikkeld om de omvang van een programma uit te drukken in een eenheid die zijn basis heeft in de functionaliteit die een programma biedt aan de gebruiker: de functiepunt Op basis van een specificatie van de gewenste functionaliteit kan al in een vroeg stadium een (globale) indicatie van de omvang van het nog te bouwen programma worden vastgesteld, uitgedrukt in functiepunten Dit geeft houvast bij het verdere verloop van het project De functiepunt kan ook worden ingezet bij het vaststellen van de omvang van bestaande software Het tellen van functiepunten is een complexe activiteit die gebonden is aan een omvangrijke verzameling van telrichtlijnen (NESMA, 2004) De striktheid van de telrichtlijnen probeert te garanderen dat verschillende tellers bij het bepalen van de omvang van een programma op eenzelfde aantal functiepunten uitkomen De telmethode is niet te automatiseren Soms wordt de omvang in functiepunten van bestaande software bepaald door een relatie te leggen met het aantal regels code Er bestaan tabellen die voor vrijwel alle gangbare programmeertalen het aantal regels code per functiepunt aangeven Deze tabellen zijn gebaseerd op ervaringscijfers uit het verleden Die methode, backfiring genaamd, geldt als zeer onbetrouwbaar Het grote voordeel ervan is het feit dat er geautomatiseerd mee geteld kan worden: het aantal regels code is geautomatiseerd te bepalen, via combinatie met een tabel met ervaringscijfers is direct het aantal functiepunten te bepalen Structuur programmacode De structuur van programmatuur kan gemeten worden aan de hand van de begrippen modulariteit, koppeling en cohesie Programmatuur is doorgaans opgebouwd uit een aantal aparte modules die elkaar aanroepen, elkaars data gebruiken Deze relaties kunnen in kaart worden gebracht Daarmee ontstaat een gerichte graaf, met modules als knopen en relaties ( roept aan, wordt aangeroepen door, maakt gebruik van ) als gerichte verbindingen tussen de knopen Metrieken uit de grafentheorie, zoals de omvang van de graaf, de diepte, de breedte, het aantal ingaande en uitgaande verbindingen, de verhouding knopen/verbindingen, kunnen gebruikt worden om de structuur van de programmatuur kwantitatief in kaart te brengen 19 een grijs gat

20 De wereld van het object-georiënteerd programmeren kent een specifieke set van zes structuurmetrieken die bekendstaat onder de naam Chidamber Kemerer Metrics Suite (Chidamber, Kemerer, 1994) Ieder van de metrieken levert een getal Aan de hand van die getallen kan de kwaliteit van een programma beoordeeld worden Structuurmetrieken zijn doorgaans goed op geautomatiseerde wijze te bepalen (met tools) Complexiteit programmacode Het aantal bytes, regels code of functiepunten zegt niet direct iets over hoe complex de software in elkaar steekt Om meer inzicht te krijgen op dit punt is in het verleden een aantal complexiteitsmetrieken ontwikkeld De bekendste is de cyclometrische complexiteit van McCabe (McCabe, 1976) Deze metriek telt in essentie niets meer dan het aantal verschillende executiepaden binnen de code Daarmee is de cyclometrische complexiteit goed te bepalen met een tool Programma s met een hoge McCabe-complexiteit zijn doorgaans moeilijk te begrijpen en daarmee moeilijk te onderhouden Deze metriek speelt dan ook een belangrijke rol bij het vaststellen van de onderhoudbaarheid van code Kwaliteit programmacode Onder deze noemer valt een groot aantal aspecten: gebruik commentaar, programma lay-out, gebruik naamgeving, correct gebruik taalconstructies, etc Er zijn boeken over volgeschreven (zie bijv McConnel, 2004; Spinellis, 2006) Het meten van deze aspecten is doorgaans lastig: er zijn geen eenduidige meetvoorschriften en normen, de meetresultaten zijn subjectief Met het gebruik van checklists met concrete aandachtspunten kan zo goed als mogelijk geprobeerd worden deze bezwaren te ondervangen Volledigheid documentatie Bij een kwalitatief goed softwareproduct hoort documentatie Deze stelregel wordt breed onderschreven binnen het vakgebied der informatici Een gebruikershandleiding ter ondersteuning van de gebruikers, specificaties en ontwerpdocumenten ten behoeve van het bouwen en onderhouden van de software, installatiehandleidingen ten behoeve van beheer: het moet er allemaal zijn In de praktijk ontbreekt vaak een deel van deze documenten Met een checklist kan eenvoudig gemeten worden welke documenten aanwezig zijn en welke ontbreken 20 Dr Ir Jacob Brunekreef

dr. ir. jacob brunekreef hva publicaties Een grijs gat Meten aan software ( kwaliteit )

dr. ir. jacob brunekreef hva publicaties Een grijs gat Meten aan software ( kwaliteit ) * omslag Jacob Brunekreef 24-09-2007 16:53 Pagina 1 hva publicaties dr ir jacob brunekreef Een grijs gat Meten aan software ( kwaliteit ) 9 789056 295035 Een grijs gat Meten aan software(kwaliteit) Dr

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

Het menselijk leven gaat boven alles. Chris C. Schotanus

Het menselijk leven gaat boven alles. Chris C. Schotanus Het menselijk leven gaat boven alles Chris C. Schotanus Kost waarschijnlijk 3 tot 7 levens en 17 tot 34 meer gewonden per jaar! Het menselijk leven gaat boven alles Het menselijk lichaam bestaat uit: 65

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

a. Wat wordt verstaan onder V&V? b. Uit welke kernactiviteiten bestaat V&V? c. Noem enkele voor- en nadelen van inspecties. d. Idem voor testen.

a. Wat wordt verstaan onder V&V? b. Uit welke kernactiviteiten bestaat V&V? c. Noem enkele voor- en nadelen van inspecties. d. Idem voor testen. Eindtoets T07351 Software engineering Een eindtoets staat in het algemeen model voor het tentamen van de betreffende cursus. Aangezien deze cursus een mondeling tentamen heeft, bevat deze eindtoets slechts

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

Functioneel beheer in Nederland

Functioneel beheer in Nederland Functioneel beheer in Nederland Achtergrond Op initiatief van Marjet Smits (ad Matres), Martijn Buurman (Functioneel-beheerder.com) en Günther Nijmeijer (inmezzo) is eind 2012 de eerste verkiezing voor

Nadere informatie

ISO 25010: 2011. Een introductie SYSQA B.V.

ISO 25010: 2011. Een introductie SYSQA B.V. ISO 25010: 2011 Een introductie SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 15 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 4 2 OPBOUW VAN HET MODEL... 5 3 DE KWALITEITSEIGENSCHAPPEN

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

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten 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

Kwaliteit. 1. Introductie. Deel 1. Algemene Kennis

Kwaliteit. 1. Introductie. Deel 1. Algemene Kennis 1. Introductie Kwaliteit In deze module gaan we iets verder in op het begrip "kwaliteit". Het is de bedoeling om wat achtergrondinformatie te geven die van pas kan komen bij de andere modules. Kwaliteit

Nadere informatie

Functiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Functiepuntanalyse. 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 informatie

Parasoft toepassingen

Parasoft toepassingen Testen op basis van OSB en Digikoppeling Voor de bestaande Overheid Service Bus en de nieuwe standaard Digikoppeling zijn verschillende test- omgevingen opgezet. Hiermee kan het asynchrone berichtenverkeer

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

ProduPlus. Wat is ProduPlus

ProduPlus. Wat is ProduPlus ProduPlus Wat is ProduPlus ProduPlus is een machine monitoring systeem welke ook functies heeft voor order registratie, product data beheer en preventief onderhoud. ProduPlus is ontwikkeld voor gebruik

Nadere informatie

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 Functional Model Driven Development MDA in de praktijk Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 FMDD agenda FMDD Waarom FMMD De praktijk Wat is FMDD Ervaringen en lessons learned Ervaringen

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

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

Scenario analyse ABC

Scenario analyse ABC analyse Juiste in FP huidig De intelligentie Inleiding Voor u ligt de QSM analyse voor het project (fictief project om u een indruk te geven van de toegevoegde waarde die de QSM project bieden). Project

Nadere informatie

TE LAAT OPGELEVERD, IS DUURDER DAN GEPLAND OF BIEDT NIET DE GEWENSTE FUNCTIONALITEIT EN KWA- VAN ZIJN TERUG TE VOEREN OP EEN ONJUISTE PLANNING

TE LAAT OPGELEVERD, IS DUURDER DAN GEPLAND OF BIEDT NIET DE GEWENSTE FUNCTIONALITEIT EN KWA- VAN ZIJN TERUG TE VOEREN OP EEN ONJUISTE PLANNING SOFTWARETOOLS VOOR PROJECTNAVIGATIE CIJFERMATIGE ONDERBOUWING NOG STEEDS ONMISBAAR IN ICT-PROJECTEN Auteur: Ernst van Waning ZO N ZEVENTIG PROCENT VAN ALLE ICT-PROJECTEN WORDT TE LAAT OPGELEVERD, IS DUURDER

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

Leones. Business Case Service Management Tool

Leones. Business Case Service Management Tool Leones Business Case Service Management Tool Inhoudsopgave 1. AFBAKENING... 3 1.1 DOEL... 3 1.2 AANNAMES... 3 1.3 HUIDIGE SITUATIE... 3 1.4 PROBLEEMSTELLING... 3 1.5 WAT ALS ER NIETS GEBEURT?... 3 2. OPTIES...

Nadere informatie

Contractmanagement voor Software-ontwikkeling

Contractmanagement voor Software-ontwikkeling Contractmanagement voor Software-ontwikkeling Presentatie PIANO / NEVI Regionale bijeenkomst Den Haag nieuwe inzichten in contracteren en besturen November 2009 Marcel Blommestijn 2 Doel van deze presentatie

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

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

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

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

Softwareproductkwaliteit

Softwareproductkwaliteit informatie / maand jaar softwarekwaliteit Overdruk Softwareproductkwaliteit Florijn & Greefhorst informatie 0101 1 Softwareproductkwaliteit Ervaringen en ontwikkelingen Met de groeiende interesse voor

Nadere informatie

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

Nadere informatie

Testen kost te veel tijd

Testen kost te veel tijd Testen kost te veel tijd De oplevering van een nieuwe ICT applicatie betekent in de praktijk voor de opdrachtgever nog geen reden voor een feest. Vaak blijkt het product in onvoldoende mate te voldoen

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

Procesgerichte IT BPM de link tussen bedrijf en IT

Procesgerichte IT BPM de link tussen bedrijf en IT 24 november 2010 Procesgerichte IT BPM de link tussen bedrijf en IT ir. Martin R. Meijer senior BPM/EAI consultant Agenda Business Process Management, een historisch overzicht BPM als bindmiddel geschikte

Nadere informatie

Wij testen..maar....wat test jij?

Wij testen..maar....wat test jij? Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks

Nadere informatie

Beter meten met Cffp. Omvangbepaling voor eigentijdse ontwikkelmethoden. kwantificeren. Functiepuntanalyse is de meest gebruikte methode

Beter meten met Cffp. Omvangbepaling voor eigentijdse ontwikkelmethoden. kwantificeren. Functiepuntanalyse is de meest gebruikte methode kwantificeren Beter meten met Cffp Omvangbepaling voor eigentijdse ontwikkelmethoden Functiepuntanalyse is de meest gebruikte methode voor omvangbepaling van softwareontwikkelprojecten. De telrichtlijnen

Nadere informatie

Last but not least. Hoofdstuk 35. Bijlagen

Last but not least. Hoofdstuk 35. Bijlagen Last but not least Hoofdstuk 35 Bijlagen V1.2 / 01 februari 2016 Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

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

Contractmanagement voor Software-ontwikkeling

Contractmanagement voor Software-ontwikkeling Contractmanagement voor Software-ontwikkeling nieuwe inzichten in contracteren en besturen Presentatie PIANO / NEVI Regionale bijeenkomst Zwolle Oktober 2009 Ralph Hofman 2 Doel van deze presentatie De

Nadere informatie

Ontwikkelaar ICT. Context. Doel

Ontwikkelaar ICT. Context. Doel Ontwikkelaar ICT Doel Ontwikkelen en ontwerpen van ICT-producten, binnen overeen te komen dan wel in een projectplan vastgelegde afspraken ten aanzien van tijd, budget en kwaliteit, opdat overeenkomstig

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

Kwaliteitskenmerken van softwareproducten: specificeren, evalueren en certificeren

Kwaliteitskenmerken van softwareproducten: specificeren, evalueren en certificeren Kwaliteitskenmerken van softwareproducten: specificeren, evalueren en certificeren J.J.M. Trienekens en E.P.W.M. van Veenendaal Kwaliteit van softwareproducten is reeds lange tijd een ongrijpbaar concept,

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

Business Analyse en User Experience

Business Analyse en User Experience Business Analyse en User Experience Een handreiking voor de Business Analyst Auteur: Marco Theunissen Versie: 1.0 Datum: Januari 2012 Copyright: Marco Theunissen, onder een licentie van Creative Commons

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software

Oplossingen voor het testen van objectgeoriënteerde software Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

TESTAUTOMATISERING IN EEN ETL-OMGEVING

TESTAUTOMATISERING IN EEN ETL-OMGEVING Pagina 21 TESTAUTOMATISERING IN EEN ETL-OMGEVING Door John Kronenberg John.Kronenberg@bartosz.nl @johnkronenberg Edward Crain Edward.crain@divetro.nl Welke groeifasen werden doorlopen in testautomatisering

Nadere informatie

Plan van Aanpak. project Tetris Packing

Plan van Aanpak. project Tetris Packing Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!

Nadere informatie

Het ontwerpproces verloopt meestal volgens een vastomlijnd traject: 1)opstellen van de specificaties - van de klant - normering - onze eigen spec's

Het ontwerpproces verloopt meestal volgens een vastomlijnd traject: 1)opstellen van de specificaties - van de klant - normering - onze eigen spec's Kennismaking met ADD-Controls. De firma ADD-Controls ontwerpt en fabriceert elektronica voor industriële toepassingen. Een groot deel hiervan bestaat uit machinebesturingen. Voorbeelden hiervan zijn: een

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

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

ADAPTABLE. Microsoft Dynamics TM NAV. Manufacturing Foundation 5.0 Snelzoekgidsen

ADAPTABLE. Microsoft Dynamics TM NAV. Manufacturing Foundation 5.0 Snelzoekgidsen ADAPTABLE Microsoft Dynamics TM NAV Manufacturing Foundation 5.0 Snelzoekgidsen Inhoudsopgave Productie instellen Setup Guide 1... Een artikelkaart maken Setup Guide 2... Een productiestuklijst maken Setup

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

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

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

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

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

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh.

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh. Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

VOICE OF THE CUSTOMER

VOICE OF THE CUSTOMER 4/20/ E-BOOK VOICE OF THE CUSTOMER Gratis e-book leansixsigmatools.nl Introductie Bij Six Sigma staat het denken vanuit de behoeften van de klant centraal. Juist de vertaling van de stem(men) van de klant(en)

Nadere informatie

Project benchmark. Vaststellen van feitelijke projectresultaten. Basis voor toekomstige succesvolle projectscenario s

Project benchmark. Vaststellen van feitelijke projectresultaten. Basis voor toekomstige succesvolle projectscenario s Quantitative Software Management Project benchmark Vaststellen van feitelijke projectresultaten Basis voor toekomstige succesvolle projectscenario s Het projectresultaat in perspectief tot vergelijkbare

Nadere informatie

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. XP Extreme Programming Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING...3 2. EXTREME PROGRAMMING...4 3. FASERING...5

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol SAMENVATTING ITIL ITIL is nog steeds dé standaard voor het inrichten van beheerspocessen binnen een IT-organisatie. En dekt zowel applicatie- als infrastructuur beheer af. Indien gewenst kan ITIL worden

Nadere informatie

Procesdenken en de cultuur van de organisatie

Procesdenken en de cultuur van de organisatie INLEIDING Procesmanagement dient bij te dragen aan de organisatiedoelstellingen zoals HRM en Finance bijdragen aan de organisatiedoelen. Procesmanagement, ook procesgericht werken genoemd, maakt iets bestuurbaar

Nadere informatie

Geef handen en voeten aan performance management

Geef handen en voeten aan performance management Geef handen en voeten aan performance management De laatste jaren is het maken van concrete afspraken over de ICT-serviceverlening steeds belangrijker geworden. Belangrijke oorzaken hiervoor zijn onder

Nadere informatie

Functieprofiel: Beheerder ICT Functiecode: 0403

Functieprofiel: Beheerder ICT Functiecode: 0403 Functieprofiel: Beheerder ICT Functiecode: 0403 Doel Zorgdragen voor het doen functioneren van ICT-producten en de ICTinfrastructuur en het instandhouden van de kwaliteit daarvan, passend binnen het beleid

Nadere informatie

HANDLEIDING VOOR HET OPSTELLEN VAN MEETBARE DOELSTELLINGEN

HANDLEIDING VOOR HET OPSTELLEN VAN MEETBARE DOELSTELLINGEN HANDLEIDING VOOR HET OPSTELLEN VAN MEETBARE DOELSTELLINGEN drs. A.L. Roode Centrum voor Onderzoek en Statistiek (COS) juni 2006 Centrum voor Onderzoek en Statistiek (COS) Auteur: drs. A.L. Roode Project:

Nadere informatie

Releases en change-management bij maatwerkapplicaties

Releases en change-management bij maatwerkapplicaties Releases en change-management bij maatwerkapplicaties door Wim - 01-26-2011 http://www.itpedia.nl/2011/01/26/releases-en-change-management-bij-maatwerk-applicaties/ Op grote maatwerk informatiesystemen

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

Checklist basisontwerp SDM II

Checklist basisontwerp SDM II Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance

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

Stakeholder behoeften beschrijven binnen Togaf 9

Stakeholder behoeften beschrijven binnen Togaf 9 Stakeholder behoeften beschrijven binnen Togaf 9 Inventarisatie van concerns, requirements, principes en patronen Bert Dingemans Togaf 9 kent verschillende entiteiten om de behoeften van stakeholders te

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 DocumentManager

Functionele beschrijving: scannen naar UNIT4 DocumentManager Functionele beschrijving: scannen naar UNIT4 DocumentManager Algemeen Met de KYOCERA Scannen naar UNIT4 DocumentManager beschikt u over een efficiënte oplossing om uw documenten te scannen naar UNIT4 DocumentManager

Nadere informatie

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over

Nadere informatie

Digikoppeling adapter

Digikoppeling adapter Digikoppeling adapter Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555

Nadere informatie

slides2.pdf 2 nov 2001 1

slides2.pdf 2 nov 2001 1 Opbouw Inleiding Algemeen 2 Wetenschap Informatica Studeren Wetenschap en Techniek Informatica als wetenschap Informatica studie Wetenschappelijke aanpak Organisatie Universiteit Instituut Piet van Oostrum

Nadere informatie

Kritieke succesfactoren bij ERP-implementaties in het MKB

Kritieke succesfactoren bij ERP-implementaties in het MKB Kritieke succesfactoren bij ERP-implementaties in het MKB ERP nu ook geschikt voor midden- en kleinbedrijf Was Enterprise Resource Planning (ERP) tot aan het begin van het millennium vooral voor de grote

Nadere informatie

ISM: BPM voor IT Service Management

ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management Het jonge IT-vakgebied wordt bestookt met allerlei frameworks om grip te krijgen op de input en output: ITIL, ASL, BiSL, COBIT en

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

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

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Sinds de kredietcrisis en door opkomende technologieën staan banken

Nadere informatie

Modelleren C Appels. Christian Vleugels Sander Verkerk Richard Both. 2 april 2010. 1 Inleiding 2. 3 Data 3. 4 Aanpak 3

Modelleren C Appels. Christian Vleugels Sander Verkerk Richard Both. 2 april 2010. 1 Inleiding 2. 3 Data 3. 4 Aanpak 3 Modelleren C Appels Christian Vleugels Sander Verkerk Richard Both 2 april 2010 Inhoudsopgave 1 Inleiding 2 2 Probleembeschrijving 2 3 Data 3 4 Aanpak 3 5 Data-analyse 4 5.1 Data-analyse: per product.............................

Nadere informatie

GEBRUIKERSHANDLEIDING AREX DIGICOMM

GEBRUIKERSHANDLEIDING AREX DIGICOMM GEBRUIKERSHANDLEIDING AREX DIGICOMM Arex Test Systems bv, Vennestraat 4b, 2161 LE Lisse, Holland Product van: Arex Test Systems bv Vennestraat 4b 2161 LE Lisse Holland Tel: +31 (0)252 419151 Fax: +31 (0)252

Nadere informatie

Goed functioneel beheer noodzaak voor effectievere SPI

Goed functioneel beheer noodzaak voor effectievere SPI getronicspinkroccade.nl Goed functioneel beheer noodzaak voor effectievere SPI Machteld Meijer Zeist, 3 oktober 2006 Inhoud Domeinen en modellen Functioneel beheer en BiSL Rol van BiSL in SPI 1 Goed functioneel

Nadere informatie

Functionele beschrijving: scannen naar Exact Globe.

Functionele beschrijving: scannen naar Exact Globe. Functionele beschrijving: scannen naar Exact Globe. Algemeen Met de KYOCERA scannen naar Exact Globe beschikt u over een efficiënte oplossing om uw documenten te scannen naar Exact Globe. Met deze oplossing

Nadere informatie

Verborgen gebreken in de defence in depth theorie

Verborgen gebreken in de defence in depth theorie Verborgen gebreken in de defence in depth theorie Iedere beveiligingsprofessional kent waarschijnlijk het schillenconcept. Dit staat bekend onder verschillende benamingen zoals defence in depth of layers

Nadere informatie

kwaliteitsmeterplus 4

kwaliteitsmeterplus 4 kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus

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

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

Cosmic Full Function Points (CFFP) Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Cosmic Full Function Points (CFFP) Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Cosmic Full Function Points (CFFP) Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

Introductie tot de cursus

Introductie tot de cursus Inhoud introductietalen en ontleders Introductie tot de cursus 1 Plaats en functie van de cursus 7 2 Inhoud van de cursus 7 2.1 Voorkennis 7 2.2 Leerdoelen 8 2.3 Opbouw van de cursus 8 3 Leermiddelen en

Nadere informatie

CMM 3: levert het wat op?

CMM 3: levert het wat op? CMM 3: levert het wat op? Philips Analytical De noodzaak en voordelen van Software Process Improvement Wie is Philips Analytical? Waarom is voor ons software proces verbetering zo essentieel? Hoe hebben

Nadere informatie

Software Test Document

Software 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 informatie

Kenmerken. Wat is een project, wat zijn de kenmerken van een project? Een project is

Kenmerken. Wat is een project, wat zijn de kenmerken van een project? Een project is Kenmerken Wat is een, wat zijn de kenmerken van een? Bepaalde periode begin- en eindtijd Bepaald budget Vooraf overeengekomen resultaat Tijdelijke organisatievorm www.gertjanschop.com/management Een is

Nadere informatie

Snel te implementeren. Inpasbaar in uw situatie

Snel te implementeren. Inpasbaar in uw situatie Everything4Office ProjectManager Software voor Project Management Snel te implementeren Inpasbaar in uw situatie Economisch zeer verantwoord Everything4Office Software, Tolnasingel 1, 2411 PV Bodegraven

Nadere informatie

Beoordelingscriteria scriptie CBC: instructie en uitwerking

Beoordelingscriteria scriptie CBC: instructie en uitwerking Nederlandse Associatie voor Examinering 1 Beoordelingscriteria scriptie CBC: instructie en uitwerking Met de scriptie voor Compensation & Benefits Consultant (CBC) toont de kandidaat een onderbouwd advies

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

Functieprofiel: Medewerker Gebouw en Techniek Functiecode: 0702

Functieprofiel: Medewerker Gebouw en Techniek Functiecode: 0702 Functieprofiel: Techniek Functiecode: 0702 Doel Uitvoeren van onderhoudswerkzaamheden, het doen van aanpassingen, alsmede bedienen van installaties/machines, binnen geldende werkprocessen en afspraken

Nadere informatie

Kwalificeren van meetcentra. Assessment Meetproces by Carl Zeiss

Kwalificeren van meetcentra. Assessment Meetproces by Carl Zeiss Kwalificeren van meetcentra. Assessment Meetproces by Carl Zeiss Bert Heijenk Carl Zeiss Measuring House Opdrachtprogrammeren Loonmetingen MSA (R&R) studies Reverse engineering Computertomografie Trainingen

Nadere informatie

Het 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 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 informatie

Testomgevingen beheer

Testomgevingen beheer Testomgevingen beheer Testen brengt het verwachte resultaat en de huidige toestand bij elkaar. Het geeft aanknopingspunten om de planning te maken, het product te verbeteren en om zorgen bij belanghebbenden

Nadere informatie