Kwaliteitszorg van softwareontwikkeling

Transcriptie

1 overdruk informatie november 00 Kwaliteitszorg van softwareontwikkeling Hendriks informatie overdruk 1 1

2 softwarekwaliteit Paul Hendriks Kwaliteitszorg van softwareontwikkeling Een overzicht van de belangrijkste ontwikkelingen Kwaliteitszorg bij softwareontwikkeling is op zeer veel manieren te bedrijven en met heel veel verschillende uitgangspunten. Paul Hendriks zet in dit artikel de meest gebruikte methoden en invalshoeken op een rij. De eerste vraag bij kwaliteitszorg van softwareontwikkeling is: waarom zou ik aan kwaliteitsverbetering moeten werken? Waarom moet ik daarin geld investeren? Wat zijn de voordelen van kwaliteitszorg? Wat zijn de doelen die met kwaliteitsverbetering te behalen zijn? Alhoewel in de literatuur steeds meer data over de te behalen successen en return on investment met kwaliteitsverbetering van softwareontwikkeling worden genoemd, blijkt het niet eenvoudig om dergelijke data te vertalen naar specifieke situaties. Zijn de resultaten wel toe te schrijven aan het verbeterproces en welke activiteiten hebben daaraan bijgedragen? De algemene tendens laat echter duidelijk zien dat kwaliteitszorg van softwareontwikkeling ertoe bijdraagt dat men beter kan voorspellen wat de kwaliteit van het geleverde product zal zijn en dat men ook beter in staat is om het product binnen de geschatte tijd en kosten op te leveren. Kwaliteitszorg heeft tot doel om middels voortdurende stapsgewijze verbetering de kwaliteit van het geleverde softwareproduct te verbeteren (zie figuur 1). Men wil leren van hetgeen men in het verleden goed deed, maar ook van de gemaakte fouten. Door verbeteracties worden veranderingen aangebracht die door borgende activiteiten verankerd worden in een organisatie. Dit alles gebeurt zodanig dat gewerkt wordt aan de bedrijfsdoelstellingen van de organisatie. Die bedrijfsdoelstellingen moeten de leidraad vormen die bepaalt hoe het verbetertraject moet worden ingericht. In de praktijk blijkt echter vaak dat bedrijfsdoelstellingen allerminst helder zijn. De methodes voor kwaliteitszorg die in dit artikel worden geschetst, zijn middelen. Zij vormen geen doel in zichzelf, en moeten worden aangepast aan de specifieke bedrijfsdoelstellingen en bedrijfscultuur van een organisatie. Verschillende invalshoeken Er zijn verschillende invalshoeken waarlangs kwaliteitszorg van softwareontwikkeling kan worden ingericht. Zowel in de praktijk als in onderzoek ligt veel nadruk op de verbetering van de kwaliteit van het ontwikkelproces (software process improvement, SPI). Het uitgangspunt daarbij is dat men door een verbeterde grip op het proces van softwareontwikkeling in staat moet zijn om betere producten te leveren. Naast procesverbetering komt steeds meer aandacht voor de andere P s: product, people en performance. Vanuit deze vier invalshoeken worden hierna de belangrijkste methoden kort besproken. 20

3 Dr. P.R.H. Hendriks is sinds kort werkzaam als senior adviseur bij M&I/Partners. Dit artikel is totstandgekomen als onderdeel van zijn eerdere werkzaamheden bij het Software Engineering Research Centre SERC ( Als projectmanager bij SERC is hij verantwoordelijk geweest voor projecten met betrekking tot softwarekwaliteit. Daarbij ligt de nadruk zowel op kwaliteitsverbetering van het softwareproduct als het softwareontwikkelproces. Hij heeft ervaring met audits en assessments bij diverse softwareontwikkelende organisaties. Process ISO-normen De bekendste algemene standaard voor borging en certificatie van de kwaliteit van de processen in een organisatie wordt gevormd door de reeks van ISO 9000-standaarden. Deze zijn algemeen toepasbaar en niet specifiek toegesneden voor de softwareontwikkelende branche. Certificatie van processen kan volgens twee normen plaatsvinden: ISO 9001 ( model voor de kwaliteitsborging bij het ontwerpen, het ontwikkelen en vervaardigen, het installeren en de nazorg ) dan wel ISO 9002 ( model voor de kwaliteitsborging bij het vervaardigen en het installeren ). Daar softwareontwikkeling ook altijd het ontwerp en de nazorg behelst, zal een softwareontwikkelende organisatie altijd volgens ISO 9001 moeten worden gecertificeerd. Voor diverse toepassingsgebieden van deze ISOnormen zijn richtlijnen beschikbaar. Specifiek toegesneden op softwareontwikkeling is de ISO standaard ( richtlijnen voor de toepassing van ISO 9001 op ontwikkeling, toelevering en onderhoud van software ). TickIT is een in Engeland ontwikkelde methode voor assessment en certificatie middels deze standaard. CMM De bekendste methode voor het in kaart brengen van de kwaliteit van het softwareontwikkelproces is de door het Software Engineering Institute (SEI) ontwikkelde methode CMM (capability maturity model). CMM is beschreven door Watts Humphrey. Het model is ontstaan door bestudering van de manier waarop in de praktijk van softwareontwikkeling succesvolle organisaties hun softwareontwikkelproces hebben ingericht. Nadat een softwareontwikkelende organisatie is doorgelicht, wordt zij ingedeeld in één van de vijf kwaliteitsniveaus (zie figuur 2). In CMM kwaliteit hoog laag borging van het bereikte niveau effectieve verbeteractie wordt tevens aangegeven op welke delen van processen men de aandacht kan of moet richten om verbetering naar een hoger niveau te realiseren. (Zie voor de meest recente ontwikkeling het kader CMMI.) Op het laagste niveau bevindt de organisatie zich in het initiële stadium ( initial ). Er wordt door de organisatie software ontwikkeld. Dit gebeurt echter op een ad hoc manier, waarbij er voor de ontwikkeling van elk afzonderlijk product een andere werkwijze wordt gevolgd. Er is vaak sprake van overschrijdingen van budget- en tijdsplanning, indien deze al aanwezig zijn. De kwaliteit van het geleverde eindresultaat is onvoorspelbaar omdat deze gebaseerd is op de inzet, kennis en kunde van individuele ontwikkelaars. Door in deze situatie ervoor te zorgen dat de basismanagementactiviteiten worden ingevoerd, kan de organisatie werken naar het tweede niveau: repeatable. Er wordt meer uniformiteit in het softwareontwikkelproces gebracht, waardoor het voor de organisatie mogelijk wordt om vergelijkbare producten van een vergelijkbare kwaliteit op een vergelijkbare manier te produceren. Bij de overgang van niveau 1 naar 2 spelen tevens de inrichting van kwaliteitszorg en het gebruik van configuratiemanagement een cruciale rol. Door beschrijving van het proces en controle op de manier waarop dat proces in de praktijk wordt uitgevoerd, kan de organisatie groeien naar het defined -niveau. Doordat het proces gedefinieerd wordt, krijgt men grip op de afzonderlijke onderdelen van het proces en kan men daaraan sturing geven. Om echter te komen tot beheersing van het softwareontwikkelproces (het niveau managed ) is het noodzakelijk kwantitatieve informatie over het proces te verzamelen, deze te analyseren en te gebruiken bij het vaststellen en bijsturen van de planning. kwaliteitsvisie voortdurende stapsgewijze verbetering tijd Figuur 1: Het doel van kwaliteitszorg thema 21

4 softwarekwaliteit Figuur 2: Maturity levels in CMM disciplined process standard, consistent process Op het laatste niveau ( optimizing ) is de organisatie in staat om op flexibele wijze het ontwikkelproces aan te passen aan de karakteristieken van het te ontwikkelen product. De organisatie weet hoe zij met veranderingen moet omgaan. CMM is primair bekend als methode voor proces-assessment. Een assessment heeft tot doel het softwareontwikkelproces van een organisatie door te lichten. Daarbij wordt bepaald in hoeverre de diverse delen van het proces adequaat zijn ten opzichte van de doelstellingen die de organisatie zich heeft gesteld ten aanzien van het softwareontwikkelproces. Aan de hand van een assessment wordt een plan opgesteld en wordt actie ondernomen om verbeteringen in het softwareontwikkelproces te realiseren. Bij elk niveau kent CMM een aantal aandachtsgebieden, de zogenaamde KPA s (key process areas). Dit zijn de gebieden waarvan CMM adviseert dat een organisatie die moet aanpakken om te groeien naar een hoger niveau van volwassenheid in haar softwareontwikkeling. Verder zijn voor elk van deze aandachtsgebieden activiteiten beschreven die bijdragen aan de realisatie van de doelen die voor dat aandachtsgebied worden gesteld. CMM bevat daarmee een praktisch raamwerk dat aangeeft hoe men verbeteringen in de organisatie van het softwareontwikkelproces kan doorvoeren. 1 continuously improving process predictable process 2 initial 3 4 repeatable defined CMMI 5 managed optimizing procesmetingen procesdefinitie procescontrole basis-managementactiviteiten Een praktisch probleem bleek in de afgelopen jaren het gebruik van meerdere CMM s. Grote organisaties gebruikten bijvoorbeeld een software-cmm en een productontwikkelings-cmm. Dat was onnodig complex. Het Amerikaanse ministerie van Defensie gaf daarom de aanzet tot het integreren van die afzonderlijke CMM s. Het moest de beste elementen uit de software- en systeemontwikkeling en de productontwikkelingsversies samenbrengen. Dat is inmiddels gedaan en het resultaat heet CMMI, ofwel CMM Integration. Kenners herkennen in CMMI een compromis. Het kent zowel de continuous approach uit EIA/IS 731 (Electronic Industries Association Interim Standard 73) en de staged approach uit software- CMM. Maar toch is ook een mogelijkheid tot bedrijfsbrede procesverbetering aanwezig. Meer informatie is te vinden op: Op de website van Informatie is in het dossier softwarekwaliteit een artikel te vinden van Mike Phillips en Sandy Shrum van het SEI over de totstandkoming van CMMI. (FN) 22

5 Bootstrap Bootstrap is eveneens een methode voor assessment en verbetering van het softwareontwikkelproces. De methode is in de periode van 1990 tot 1993 ontwikkeld in het kader van het door de Europese Gemeenschap gesubsidieerde programma Esprit. Dat project had tot doel om gebaseerd op CMM, ISO en ESAstandaards te komen tot een geschikte methode voor softwarekwaliteitsverbetering. Een van de verschillen tussen CMM en Bootstrap is dat Bootstrap meer nadruk legt op een sterkte/zwakte-profiel van de organisatie dan de niveau-indeling die CMM kenmerkt. Een softwareontwikkelende organisatie hoeft niet een aantal processen volledig onder controle te hebben alvorens men naar een hoger niveau kan, maar er wordt voor een groot aantal processen geanalyseerd in hoeverre de organisatie als geheel ze heeft ingericht. Door Bootstrap worden naast primaire ontwikkelprocessen als specificatie, ontwerp, programmering en testen ook ondersteunende processen bekeken zoals projectmanagement, kwaliteitsbeheersing en configuratiebeheer. In het bijzonder wordt ook gekeken naar de algemene managementpraktijken, die bijvoorbeeld ook de relatie met klanten en gebruikers, omgang met personeel (taakverdeling, scholing) en kwaliteitszorg omvatten. In de meeste Europese landen (en ook daarbuiten) is inmiddels een groot aantal assessments volgens Bootstrap uitgevoerd. De tijdens een assessment verzamelde gegevens worden anoniem in een database opgeslagen. De toegang tot die database beperkt zich tot diegenen die over een licentie voor het uitvoeren van Bootstrap-assessments beschikken. De opgeslagen gegevens maken vergelijkende analyses en benchmarks mogelijk. Aan de hand van de database kan men voor een specifieke onderneming bepalen wat de huidige positie is ten opzichte van vergelijkbare organisaties. SPICE SPICE (Software Process Improvement and Capability determination) is een internationale standaard die ontwikkeld is met als doelstelling standaardisatie van softwareproces-assessment en -verbetering te bereiken. Deze standaard wordt ontwikkeld binnen het ISO-kader en komt beschikbaar als ISO De standaard is net goedgekeurd binnen de formele kaders van ISO. Het project dat zorgdraagt voor de ontwikkeling van SPICE is gestart in Daarin wordt bijgedragen door diverse partijen die betrokken zijn geweest bij de ontwikkeling van de belangrijkste methodes voor softwareproces-assessment en -verbetering of die daarmee in de praktijk uitgebreid ervaring hebben opgedaan. In zijn uiteindelijke vorm zal ISO bestaan uit negen documenten (figuur 3): concepts and introductory guide Geeft een overzicht van de concepten en ideeën die aan SPICE ten grondslag liggen. Er wordt tevens een overzicht gegeven van de documen- 1 concepts and introductory guide 9 vocabulary 7 guide for use 8 guide for use in 6 guide to in process improvement determining supplier process capability competency of assessors 3 performing 4 an assessment guide to performing assessments 2a reference model 5 an assessment for process and model and process capability indicator guidance Figuur 3: De producten van SPICE thema 23

6 softwarekwaliteit ten die SPICE levert en hun onderlinge samenhang. a reference model for processes and process capability Beschrijft een tweedimensionaal referentiemodel waarmee het resultaat van een assessment kan worden beschreven. Het referentiemodel bevat een verzameling processen en een raamwerk voor de evaluatie van de volwassenheid van die processen. performing an assessment Beschrijft de eisen die aan de uitvoering van een assessment worden gesteld opdat de resultaten daarvan herhaalbaar, betrouwbaar en consistent zullen zijn. guide to performing assessments Geeft richtlijnen voor de uitvoering van een assessment waarbij de eisen die aan een assessment worden gesteld worden geïnterpreteerd naar de verschillende omstandigheden voor assessments. an assessment model and indicator guidance Beschrijft een exemplarisch voorbeeld van de uitvoering van een assessment gebaseerd op en compatibel met het referentiemodel uit het vorige document. guide to competency of assessors Bevat een beschrijving van de kennis, vaardigheden, opleiding en ervaringen die een assessor moet hebben om op een verantwoorde wijze assessments te kunnen uitvoeren. guide for use in process improvement Geeft aan op welke manier assessments kunnen worden gebruikt binnen het traject van softwarekwaliteitsverbetering: welke stappen kan men in een dergelijk traject onderkennen en hoe kan men die invullen? guide for use in determining supplier process capability Laat zien hoe het resultaat van een assessment kan worden gebruikt om in de relatie tussen softwareontwikkelaar en afnemer aan te tonen wat de capaciteiten van de softwareontwikkelaar zijn. vocabulary Bevat een omschrijving van de gebruikte terminologie. INK Managementmodel Het INK Managementmodel is een nadere invulling van het model dat door de EFQM (European Foundation for Quality Management) is ontwikkeld voor de evaluatie van de totale kwaliteit van een organisatie. Het model is algemeen toepasbaar en niet specifiek toegesneden voor softwareontwikkelende organisaties. De primaire doelstelling van het model is de ondersteuning van organisaties bij het uitvoeren van een self-assessment. De negen verschillende aandachtsgebieden waarop het INK Managementmodel zich richt, zijn weergegeven in figuur 4. Bij de hiervoor behandelde methodes ligt de nadruk op het management van processen, waarbij in een aantal gevallen ook een paar van de randgebieden (vooral middelenmanagement) worden meegenomen. De reikwijdte van dit model is duidelijk groter. Anderzijds is het een meer beschrijvend model dat houvast biedt voor assessment, maar minder invulling geeft aan het antwoord op de vraag hoe een (volgend) kwaliteitsniveau kan worden bereikt. organisatie resultaat leiderschap HRM beleid & strategie processen tevredenheid klanten tevredenheid medewerkers resultaat middelen waardering maatschappij Figuur 4: Aandachtsgebieden van het INK Managementmodel innovatie & leren 24

7 Figuur 5: Overzicht van extended ISO model kwaliteitseigenschappen van softwareproducten (de door QUINT toegevoegde eigenschappen zijn met een functionality usability maintainability bullet weergegeven) - suitability - accuracy - interoperability - compliance - security traceability - understandability - learnability - operability explicitness customisability attractivity clarity helpfulness user-friendliness - analysability - changeability - stability - testability manageability reusability reliability - maturity - fault tolerance - recoverability availability degradability Product Als over kwaliteit van een softwareproduct gesproken wordt, dan doelt men daarbij vaak op de geboden functionaliteit en het ontbreken van fouten na oplevering van het product. Vaak blijken dit niet de eigenschappen te zijn die voor gebruikers de kwaliteit van de software bepalen. Zij zijn bijvoorbeeld geïnteresseerd in de gebruiksvriendelijkheid, de beschikbaarheid en/of het tijdgedrag. Het is daarom belangrijk om in de communicatie tussen gebruikers en ontwikkelaars van softwareproducten aandacht te besteden aan dergelijke kwaliteitseigenschappen. Eerste voorwaarde daarbij is dat beide partijen weten wat dergelijke eigenschappen betekenen. Er is behoefte aan een begrippenkader voor specificatie en validatie van kwaliteitseigenschappen van softwareproducten. ISO 9126 efficiency - time-behaviour - resource behaviour In de huidige ISO 9126 ( kwaliteitseigenschappen en richtlijnen voor hun gebruik ) worden definities van kwaliteitseigenschappen gegeven. In deze norm worden zes eigenschappen gedefinieerd, en in de appendix van de norm wordt voor elke eigenschap een aantal deeleigenschappen gedefinieerd. Momenteel wordt binnen ISO gewerkt aan nieuwe versies van deze norm. In het kader van QUINT (Quality in Information Technology) is door SERC in samenwerking met een aantal partijen in een tweetal projecten portability - adaptability - installability - conformance - replaceability gewerkt aan een begrippenkader voor kwaliteit van softwareproducten. QUINT heeft geresulteerd in een uitbreiding van het kwaliteitsmodel zoals dat in ISO 9126 is beschreven. Er zijn nog elf eigenschappen toegevoegd, die in de praktijk een zinvolle aanvulling bleken te vormen. Figuur 5 geeft een overzicht van de hiërarchie van kwaliteitseigenschappen. Naast de uitbreiding met een aantal eigenschappen zijn indicatoren, meetschalen en meetvoorschriften toegevoegd. Deze blijken in de praktijk de handvaten te vormen waarmee specificatie en validatie van software-eigenschappen mogelijk worden. Een indicator is een meetbare eigenschap van een softwareproduct die een indicatie geeft in hoeverre een bepaalde eigenschap gerealiseerd is. Zo is bijvoorbeeld de mean time between failures een indicatie voor de beschikbaarheid (availability) van het product. Van elke indicator is aangegeven wat de meetschaal is waarop deze gemeten kan worden. Ook wordt een meetvoorschrift beschreven volgens welke de indicator te meten is. ITIL De kwaliteiten van een product worden niet alle bepaald door het product zelf, maar ook door de services die bij dat product worden geleverd. In dat kader wordt hier ITIL (IT Infrastructure Library) genoemd. ITIL bestaat uit een verzameling handboeken waarin de praktijk van IT-servicemanagement wordt behandeld. thema 25

8 softwarekwaliteit People Performance P-CMM Naast het CMM heeft het SEI ook het People- CMM (ook wel P-CMM) ontwikkeld. Dit is een met CMM vergelijkbaar raamwerk dat zich richt op het ontwikkelen en managen van kennis, ervaringen en motivatie van de werknemers in de organisatie. Net als bij CMM wordt de volwassenheid van de organisatie ten aanzien van human resource management in kaart gebracht en worden prioriteiten voor verbetering aangegeven. PSP Naast verbeteractiviteiten op het gebied van het softwareontwikkelproces en het softwareproduct ontstaat steeds meer aandacht voor verbetering van de capaciteiten van de individuele softwareontwikkelaar. Vooral het PSP (personal software process) richt zich hierop. PSP is eveneens ontwikkeld door de geestelijk vader van het CMM, Watts Humphrey. De doelstelling van PSP is om de individuele softwareontwikkelaar bewust te maken van zijn softwareontwikkelproces om daarmee de kwaliteit van dat proces, de voorspelbaarheid en de kwaliteit van het resultaat te verbeteren. De ontwikkelaar wordt geleerd om zijn werk te analyseren en te meten en om zichzelf persoonlijke doelen te stellen voor verbetering. TSP Vorig jaar is het boek Introduction to the Team Software Process verschenen, waarin Watts Humphrey et al team software process (TSP) beschrijven. Na CMM voor de gehele softwareontwikkelende organisatie en PSP voor de individuele software engineer, is dit het derde (tussenliggende) niveau waarop processen in kaart worden gebracht en verbeterd. De claim is dat deze drie methodieken elkaar in combinatie kunnen versterken. Het is nog de vraag of de praktijk daarvoor bewijsmateriaal zal aandragen. Ook voor softwareontwikkeling moeten onder het motto meten is weten metrieken worden gebruikt om inzicht in het ontwikkelproces te verkrijgen en om het te kunnen besturen op basis van die metingen. Een van de meest voorkomende fouten bij de introductie van metriekenprogramma s in softwareontwikkelende organisaties is dat men allerlei gegevens gaat verzamelen zonder dat men weet waarvoor de meetresultaten bedoeld zijn. Het gevolg is dat de meetresultaten niet daadwerkelijk gebruikt worden en het meetprogramma mislukt. GQM Het GQM (goal question metric)-paradigma komt hieraan tegemoet door een gestructureerde aanpak voor introductie van een metriekenprogramma. Daarbij worden eerst de doelen bepaald ten aanzien van het softwareontwikkelproces en de daaruit voortkomende producten. Die doelen worden verfijnd in een aantal vragen en deze worden uitgewerkt in metrieken die antwoord moeten geven op de gestelde vragen. Ook de introductie van een meetprogramma zelf is een proces waarvoor GQM een aantal stappen onderscheidt. In de eerste stap wordt de huidige situatie geanalyseerd. Dit dient als basis voor de volgende stap, waarin de doelen worden geïdentificeerd en beschreven. Daarna worden deze uitgewerkt in een GQM-plan met vragen en metrieken. In de vierde stap wordt dan het uiteindelijke plan voor de uitvoering van de metingen opgesteld, waarbij ook de omgeving wordt gedefinieerd waarin de metingen zullen worden verzameld en geanalyseerd. In de vijfde stap wordt dat plan dan daadwerkelijk uitgevoerd en worden de meetgegevens verzameld, gevalideerd en geanalyseerd. Op basis van die informatie kan dan een verbeterprogramma worden ingevuld. Productiviteit Op de markt verschijnen steeds meer commerciële tools waarmee men de productiviteit van een softwareontwikkelende organisatie kan bepalen. Van softwareontwikkelprojecten worden diverse data verzameld: de benodigde capaciteit, de doorlooptijd, de grootte van het ont- 26

9 wikkelde product (in termen van coderegels of functiepunten), de kwaliteit van het product (in termen van het aantal ontdekte fouten tijdens ontwikkeling en/of na oplevering) en een aantal karakteristieken van het project (bijvoorbeeld de ontwikkelomgeving en de kennis en ervaring van het ontwikkelteam). Verschillende tools bevatten een uitgebreide database met gegevens van reële projecten. Door toevoeging van data uit de eigen organisatie en op basis van statistische analyse kan men zijn eigen productiviteit vergelijken met de data uit de database. Op basis van statistische analyse kan men beter schattingen maken bij het plannen van projecten. Bij sommige tools kan men de status van een lopend project vergelijken met de planning van dat project. De tool kan dan aangeven of het project nog op planning ligt, enigszins achterligt of dat er drastische maatregelen moeten worden genomen wil het project nog binnen een acceptabele tijdsinspanning tot resultaat leiden. Het hier gepresenteerde overzicht van mogelijkheden voor kwaliteitsverbetering toont aan dat dit onderwerp in de belangstelling staat. Het is niet alleen een onderzoek van theoretisch werk, maar bij uitstek een onderwerp dat geworteld is in de dagelijkse praktijk (en problematiek) van softwareontwikkeling. Geen enkele methode zal een pasklaar antwoord geven op de problemen in de eigen softwareontwikkeling, maar zij vormen wel een leidraad om verbeteringen aan te brengen. Literatuur ISO 9126: Quality character- Zeist, B. van, P. Hendriks, R. In het dossier istics and guidelines for their Paulussen, J. Trienekens: softwarekwaliteit Basili, V.R., G. Caldiera, H.D. use, ISO/IEC Kwaliteit van op staan Rombach: The Goal Kuvaja, P. et al: BOOTSTRAP: softwareprodukten; vele links naar websites met Question Metric Approach, Europe s assessment method, praktijkervaringen met een meer informatie over de Institute for Advanced In: IEEE Software, Vol. 10, kwaliteitsmodel, Kluwer hier gepresenteerde Computer Studies, no. 3, Bedrijfswetenschappen, methoden. Department of Computer, Kuvaja P. et al: Software Deventer, ISBN Science, University of Process Assessment & , Maryland. Improvement The BOOT- Zeist, R.H.J. van, P.R.H. Humphrey, W.S.: Managing STRAP Approach, Blackwell, Hendriks: Specifying the Software Process, SEI ISBN , software quality with the Series in Software Paulk, M.C., B. Curtis, M. extended ISO model, In: Engineering, Addison-Wesley Chrissis, C.V. Weber: Software Quality Journal, Publishing Company, ISBN Capability Maturity Model part 5, no 4, Chapman & , for Software, Version 1.1, Hall, Humphrey, W.S.: A Discipline technical report, CMU/SEI- for Software Engineering, SEI 93-TR-24, Software Series in Software Engineering Institute SEI, Engineering, Addison-Wesley Pennsylvania, USA, February Publishing Company, ISBN , Solingen, R. van, E. Berghout: Humphrey, W.S., M. Lovelace, The Goal/Question/Metric R. Hoppes: Introduction to Method; A Practical Guide the Team Software Process, for Quality Improvement of SEI Series in Software Software Development, Engineering, Addison-Wesley McGraw-Hill, ISBN 007- Publishing Company, ISBN , X, thema 27