SOFTWAREMETRIEKEN. versie 1.0 NEDERLANDSE SOFTWARE METRIEKEN GEBRUIKERS ASSOCIATIE

Transcriptie

1 SOFTWAREMETRIEKEN versie 1.0 NEDERLANDSE SOFTWARE METRIEKEN GEBRUIKERS ASSOCIATIE

2 NESMA/GIA 2002 Alle rechten voorbehouden. NEderlandse Software Metrieken Gebruikers Associatie (NESMA) en Genootschap van Informatie Architecten (GIA). Niets uit deze uitgave mag worden verveelvoudigd of openbaar gemaakt, in enige vorm of op enige wijze, zonder voorafgaande schriftelijke toestemming van de NESMA en GIA. Na toestemming dient de titelpagina van het document waarin gedeelte(n) uit deze uitgave zijn overgenomen, de volgende bepaling te bevatten: "Deze uitgave bevat materiaal dat afkomstig is uit producten van NESMA en GIA. Deze openbaarmaking geschiedt met toestemming van de NESMA en GIA.

3 Voorwoord Voorwoord De NESMA heeft als doel het bevorderen van de ontwikkeling en het gebruik van methoden, technieken en hulpmiddelen ten behoeve van de beheersbaarheid van automatiseringsprocessen in de software lifecycle, vanuit de filosofie: Meten is weten. Van oudsher is de aandacht sterk gericht op functiepuntanalyse, als belangrijke methode in dit kader. De telrichtlijnen van NESMA zijn inmiddels toonaangevend in Nederland en vinden ook steeds meer internationale erkenning. In de afgelopen jaren is daarnaast door verschillende werkgroepen aandacht besteed aan het beheersen van verschillende processen in de software lifecycle: nieuwbouw, onderhoud en exploitatie, waar mogelijk met toepassing van functiepuntanalyse. Verder is en wordt onderzoek gedaan naar hulpmiddelen en toepassingsmogelijkheden in nieuwe technieken voor systeemontwikkeling en onderhoud. Al met al is op het werkterrein vanuit de invalshoek van functiepuntanalyse reeds het nodige werk verricht. De doelstelling van NESMA is in 1995 bewust verbreed naar methoden, technieken in het algemeen, kortweg aan te duiden als softwaremetrieken. Het was dan ook niet meer dan logisch om in deze richting activiteiten te ontwikkelen. Om meer zicht te krijgen op vooral praktisch toepasbare softwaremetrieken is eind 1998 de werkgroep Software Metrics opgericht. Deze werkgroep is opgezet als een samenwerkingsverband tussen NESMA en GIA. Dit paste uitstekend in het streven van zowel GIA als NESMA om te komen tot samenwerking met verwante vakorganisaties. Een onderzoek naar softwaremetrieken omvat noodzakelijkerwijs verschillende elementen, min of meer oplopend in voorschrijvend karakter: - inventariseren - ordenen, classificeren, waarderen - aangeven praktische toepassingsmogelijkheden - aangeven mogelijke richtingen voor implementatie. Vanuit dit gegeven is de opdracht voor de werkgroep als volgt geformuleerd: - Inventariseer welke softwaremetrieken er bestaan om vanuit het oogpunt van beheersing te meten aan processen voor systeemontwikkeling, onderhoud, beheer en exploitatie en aan informatiesystemen zelf, zijnde de producten van deze processen. - Onderzoek per softwaremetriek het toepassingsgebied en de toepasbaarheid, volgens nader vast te stellen criteria. - Onderzoek de mogelijkheden voor praktische toepassing van softwaremetrieken. - Formuleer een visie en aanwijzingen voor implementatie van softwaremetrieken. Softwaremetrieken 1

4 Voorwoord In de werkgroep Software Metrics hebben de volgende personen deelgenomen: Henry Peters (Voorzitter) Cornelly Spier-Spalburg Jan Jansen Teade Punter Harrie Vaasen Mans Mesken André Heijstek Exit Cap Gemini Ernst & Young ING Bank Fraunhofer IESE Getronics Emendo/Techforce Q-Labs Het onderzoek heeft vele uren werk van alle werkgroepleden gevergd, met het nodige doorzettingsvermogen om in het zeer brede werkterrein toch de juiste weg te vinden. Wij zijn van mening dat de werkgroep hier zeker in is geslaagd. Tijdens het onderzoek zijn de tussenproducten getoetst door een klankbordgroep. Hierin hebben verschillende leden vanuit GIA en NESMA deelgenomen. Wij danken hen hierbij voor de constructieve bijdragen. Het resultaat van alle inspanningen is dit handboek. Het geeft een overzicht van toepasbare softwaremetrieken, met daarbij de nodige aanwijzingen voor ontwikkeling en gebruik in de dagelijkse praktijk. Wij hopen dat dit handboek een goede aanzet is tot een voortgaande toepassing van softwaremetrieken in de dagelijkse praktijk, en daarmee tot de verdere professionalisering van uw automatiseringsactiviteiten. Zeist, maart 2002, Het NESMA-bestuur Softwaremetrieken 2

5 Inhoudsopgave Inhoudsopgave Voorwoord... 1 Inhoudsopgave... 3 INLEIDING Waarom dit onderzoek? Doelgroep Afbakening en kenmerken Overzicht en leeswijzer De samenhang tussen proces- en gegevensmodel DEEL I RAAMWERK VAN BEGRIPPEN Inleiding Dit deel Noodzaak en nut van een raamwerk Raamwerk overzicht Inleiding Bedrijfsdoel, bedoeling, gezichtspunten en meetdoelen Indicatoren en objecten Metrieken Metingen Raamwerk Details Bedrijfsdoel (Business Goal), bedrijfsstrategie en -oriëntatie Gezichtspunt (Viewpoint) Bedoeling (Purpose) Meetdoel (Measurement goal) Object (Entity) Indicator (External attribute) Attribuut (Internal attribute) Metriek (Metric, Metric specification, Measurement method) Attribuutwaarde, Metriek resultaat en Indicator resultaat Softwaremetrieken 3

6 Inhoudsopgave DEEL II BEPALEN EN TOEPASSEN VAN METRIEKEN Inleiding Dit deel Noodzaak en nut van een procesmatige beschrijving Proces overzicht Inleiding Bedrijfsdoel, bedoeling, gezichtspunten en meetdoelen Indicatoren en objecten Metrieken Metingen Proces details Meetdoelstellingen bepalen Indicatoren definiëren Metrieken ontwerpen Metrieken vooraf toetsen en instellen Doelwaarden bepalen Metingen uitvoeren Resultaten vaststellen Resultaten evalueren Toepassing van vragen Kwaliteitseisen voor metrieken DEEL III TYPEN METRIEKEN Inleiding Dit deel Hoofdindeling in typen Inleiding Typering naar Bedrijfsdoel (Goal) Typering naar Gezichtspunt (Viewpoint) Typering naar Bedoeling (Purpose) De typen samengevat Typen metrieken in detail Beschrijvingswijze per type Metrieken voor processnelheid Metrieken voor proceskosten Metrieken voor productkwaliteit Metrieken voor stabiliteit van de omgeving Attributen Literatuur Softwaremetrieken 4

7 INLEIDING Softwaremetrieken 5

8 Softwaremetrieken 6

9 INLEIDING 1 Waarom dit onderzoek? 1 Waarom dit onderzoek? De kwaliteit van softwareproducten en de kwaliteit van de processen, die deze producten moeten voortbrengen en onderhouden, vormen een algemeen probleem in het IT-vakgebied. Daarbij is in het algemeen niet duidelijk wat precies de tekortkomingen en de oorzaken daarvan zijn. Om de kwaliteit van software te kunnen beheersen en verbeteringen te kunnen realiseren is het noodzakelijk het inzicht in de kwaliteitsproblemen en de oorzaken daarvan te vergroten. Dit vergt duidelijke en praktisch bruikbare meetmethoden. De belangstelling voor kwaliteit in het IT-vakgebied is, door de jaren heen bezien, wisselend. Dat geeft een enigszins wankele basis voor kwaliteitsbeheersing en -verbetering. Dit maakt het niet makkelijker om goede meetmethoden te vinden en in de praktijk ook toe te passen. Er zijn reeds veel softwaremetrieken 1 ) gedefinieerd, zowel voor de processen als voor softwareproducten. Deze zijn op talrijke manieren te classificeren en te ordenen. Er zijn daarnaast verschillende raamwerken voor het managen van de kwaliteit van diensten en/of processen. Juist door het grote aanbod van mogelijkheden is het moeilijk een goed beeld te krijgen van bruikbare en samenhangende metrieken. Er zijn diverse ontwikkelingen met een raakvlak met softwaremetrieken (o.a. ontwikkeling en toepassing van CMM, SPI, ISO9000, Business Balanced Score Card). Deze ontwikkelingen liggen op het gebied van Software Process Improvement of meer algemener op het vlak van verbetering van bedrijfsprocessen. Tevens zijn er op verschillende fronten activiteiten betreffende de ordening van kwaliteitsaspecten van software (oa. ISO9126, QUINT). In de dagelijkse praktijk is de toepassing van metrieken nog zeer beperkt. Voor het ontwikkelen en gebruiken van metrieken is de relatie met praktijkervaringen onontbeerlijk. Door tijdsdruk en druk op de IT-budgetten zijn er relatief weinig mogelijkheden om in de praktijk softwaremetrieken daadwerkelijk toe te passen. In hoofdzaak organisaties die bezig zijn met een vorm van gestructureerde Software Process Improvement maken een begin met toepassing van metrieken. Dit onderzoek is bedoeld om meer zicht te krijgen op de softwaremetrieken en vooral op de praktische toepassingsmogelijkheden van metrieken voor kwaliteitsbeheersing en kwaliteitsverbetering 1) De term softwaremetrieken (software metrics) is in de literatuur op uiteenlopende wijzen gedefinieerd. In dit onderzoek wordt de term gebruikt om een standaard methode aan te duiden waarmee men kenmerken kan meten van een software product of van een proces dat een dergelijk product voortbrengt of onderhoudt. Softwaremetrieken 7

10 INLEIDING 2. Doelgroep 2. Doelgroep De doelgroep voor dit handboek bestaat uit projectleiders, kwaliteitsmanagers, projectmedewerkers en het verantwoordelijke lijnmanagement. In het lijnmanagement kan onderscheid gemaakt worden naar strategisch, tactisch en uitvoerend niveau. De belangrijkste resultaten van het onderzoek voor deze doelgroep zijn als volgt samen te vatten: - Een samenhangend bruikbaar stelsel softwaremetrieken, dat gerelateerd kan worden aan de situatie waarin een organisatie verkeert en de doelstellingen die men voor ogen heeft, op het gebied van de kwaliteit van softwareontwikkeling, voor ogen heeft - Aanwijzingen voor de implementatie van een dergelijk stelsel van softwaremetrieken. 3 Afbakening en kenmerken Om te voorkomen dat de resultaten van het onderzoek te ver af staan van de dagelijkse praktijk is de aandacht steeds gericht op de behoefte aan metrieken in praktijk, praktijksituaties waar metrieken een rol zouden kunnen spelen, mogelijkheden of belemmeringen voor invoering en gebruik, etc. De behoefte aan en het toepassen van een metriek valt of staat immers met de aansluiting bij de dagelijkse praktijk. Verder is er naar gestreefd om relatief snel tot producten te komen, om de aansluiting met de praktijk en met lopende ontwikkelingen te behouden. Tijdens het onderzoek is meer de nadruk gelegd op typen metrieken en hun toepassingsmogelijkheden dan op een volledige, diepgaande inventarisatie. Daarbij is ook sterk gelet op het verkrijgen van toegevoegde waarde ten opzichte van hetgeen reeds in de vakliteratuur is vastgelegd. Softwaremetrieken 8

11 INLEIDING 4. Overzicht en leeswijzer 4. Overzicht en leeswijzer De resultaten van het onderzoek zijn vastgelegd in 3 delen : I Raamwerk van begrippen, te beschouwen als een gegevensmodel voor softwaremetrieken II Het bepalen en toepassen van metrieken. Dit deel kan gezien worden als een procesmodel voor het proces van zoeken, definiëren, invoeren en gebruiken van softwaremetrieken. III Typologie van metrieken; typen en voorbeelden, gerangschikt naar het beoogde doel van het meten. De gegevens en processen rond softwaremetrieken zijn in de delen I en II op twee niveaus beschreven: op een globaal (overzicht-)niveau en op een meer gedetailleerd niveau. Deel III kent eveneens een globale en een detailbeschrijving. Dit levert de onderstaande indeling die men tevens als leeswijzer kan hanteren: Inleiding Deel I Deel II Deel III Achtergrond: 1 tm Globaal beeld: Detail beeld: Bijzonderheden: 3,4 3 Softwaremetrieken 9

12 INLEIDING 5. De samenhang tussen proces- en gegevensmodel 5. De samenhang tussen proces- en gegevensmodel De samenhang tussen de processen en gegevens, die bij het ontwikkelen en toepassen van softwaremetrieken een rol spelen, is in het navolgende schema weergegeven. In de volgende delen wordt een en ander beschreven.. Gegevens (zie deel I) Processen (zie deel II) Doelstellingen Bedrijfsdoel Bedoeling Gezichtspunt Meetdoelstellingen bepalen Meetdoel Indicatoren en objecten Objecten Indicatoren Indicatoren definiëren Metrieken Attributen Metrieken Metrieken ontwerpen Metrieken vooraf toetsen en instellen Metingen Doelwaarden bepalen Attribuut waarden Meetresultaten Metingen uitvoeren Resultaten vastleggen Resultaten evalueren Softwaremetrieken 10

13 DEEL I RAAMWERK VAN BEGRIPPEN Softwaremetrieken 11

14 Softwaremetrieken 12

15 DEEL I 0. Inleiding 0. Inleiding 0.1 Dit deel Dit deel bevat het raamwerk voor softwaremetrieken. In dit raamwerk is een aantal begrippen en concepten met hun onderlinge samenhang gedefinieerd 1 ). Het raamwerk is, samen met de delen II en III van dit onderzoek, bedoeld om organisaties houvast te geven bij het ontwikkelen van een softwaremetrieken programma 2 ). Een raamwerk in onontbeerlijk om de zaken goed te kunnen ordenen. In par. 0.2 is aangegeven waarom dit het geval is. Het raamwerk zelf bestaat uit twee delen: 1. Raamwerk overzicht Het raamwerk is weergegeven in de vorm van een datamodel. Dit wordt in hoofdlijnen besproken in dit hoofdstuk 2. Raamwerk details De afzonderlijke gegevensgroepen in het model worden toegelicht en beschreven in detail. Voor een aantal groepen wordt de mogelijke inhoud aangegeven, als een eerste implementatievoorbeeld. Dit verduidelijkt het abstracte model en kan het maken van keuzes in een bepaalde situatie vergemakkelijken. 0.2 Noodzaak en nut van een raamwerk Het opstellen van software-meetprogramma s levert in de praktijk belangrijke problemen op. Het kost veel tijd om een goed programma vast te stellen en vervolgens ook uit te voeren. Daarbij komt dat de resultaten vaak afhankelijk zijn van de context. Dit maakt het moeilijk vast te stellen of meetresultaten enige geldigheid hebben. Resultaten zijn moeilijk te interpreteren en nog moeilijker te vergelijken met andere resultaten. Daarom is meer informatie over metrieken nodig, en speciaal informatie waarmee er voor een specifieke behoefte aan meting snel en met beperkte kosten een uitvoerbaar en beheersbaar voorstel kan worden gedaan. 1) Begrippen worden met een Nederlandse term aangeduid. Om aansluiting met de veelal Engelstalige literatuur te vergemakkelijken is de Engelse term op veel plaatsen toegevoegd. 2) De term softwaremetrieken programma wordt hier gebruikt om het geheel van activiteiten aan te duiden waarmee een organisatie metrieken wil gaan ontwikkelen, invoeren en toepassen. Een dergelijk programma heeft in het algemeen het karakter van een project, maar ook andere organisatievormen zijn denkbaar, variërend van een beperkte set van acties gericht op een geïsoleerd probleem, tot een omvangrijk kwaliteitsprogramma met een semi-permanent karakter. Softwaremetrieken 13

16 DEEL I 0. Inleiding Het raamwerk kan hierin een belangrijke taak vervullen, omdat het helpt bij: Het bepalen van grenzen voor een softwaremetrieken project Het gebied van softwaremetrieken is uitgebreid en de inspanning en tijd die een organisatie aan softwaremetrieken kan of wil besteden is in de regel nogal beperkt. Om een softwaremetrieken programma beheersbaar te houden, waarbij de mogelijkheden en beperkingen goed in het oog worden gehouden, moeten grenzen worden bepaald. Men kan echter alleen maar effectieve grenzen bepalen als men een heldere zienswijze op softwaremetrieken heeft. Een raamwerk van softwaremetrieken kan helpen om een programma af te bakenen. Dat kan bijvoorbeeld door specifieke delen van het raamwerk te selecteren of specifieke voorkomens en waarden, zoals bepaalde typen van objecten, doelstellingen etc. De voorbeeld-invulling beschreven in hoofdstuk 2 biedt mogelijkheden om een gewenste subset te kiezen. Het toepassen van ontwikkelingen op verwante vakgebieden Het raamwerk biedt enige aanknopingspunten om in een organisatie het verband met andere ontwikkelingen in het vakgebied duidelijker te maken. De belangrijkste ontwikkelingen die verband houden met metrieken zijn: - ISO- en andere kwaliteitsmodellen. - Ontwikkelingen op het terrein van procesverbeteringen, zoals ISO, CMM (met de daarin benoemde Key Process Area s), SPICE etc. - Systeemontwikkelingsmethoden (waterval, RAD, OO etc.) - Het beschouwen van systemen met hun gehele lifecycle. - Algemene concepten voor projectbeheersing en organisatie. De verbanden met en tussen diverse ontwikkelingen zijn in het kader van dit onderzoek niet verder uitgewerkt. Het zoeken en analyseren van metrieken Het raamwerk is verder te hanteren als een leidraad voor het gericht zoeken van metrieken, het analyseren en samenstellen van de juiste verzameling metrieken. Dit zijn activiteiten die in elk metrieken programma noodzakelijk aan bod komen. Het vaststellen van een systeem concept voor het toepassen van softwaremetrieken Het raamwerk is te zien als het gegevensmodel van een softwaremetrieken systeemconcept. Samen met het procesmodel levert het een compleet systeemconcept, ofwel een eerste globaal ontwerp voor een softwaremetrieken systeem in een organisatie. Het verkopen, implementeren en managen van een softwaremetrieken project De doelgroep voor softwaremetrieken bestaat in het algemeen zowel uit projectmanagers (en in project/productbeheersing of kwaliteitsbeheersing gespecialiseerde projectmedewerkers) als uit verantwoordelijke lijnmanagers. De doelgroep moet bij het softwaremetrieken programma worden betrokken, van begin tot eind. Het raamwerk moet hen een indruk geven van de impact, mogelijkheden en opbrengsten van softwaremetrieken. Dit maakt het mogelijk softwaremetrieken aan of binnen een organisatie te verkopen, maakt beslissingen en prioriteitsstelling mogelijk en kan er aan bijdragen dat het programma de noodzakelijke voortgang houdt. Softwaremetrieken 14

17 DEEL I 1. Raamwerk overzicht 1. Raamwerk overzicht 1.0 Inleiding Het raamwerk heeft de vorm van een gegevensmodel, dat de gegevensgroepen beschrijft die van belang zijn voor softwaremetrieken. Er zijn vier hoofd-gegevensgroepen onderscheiden: 1. Doel, bedoeling, gezichtspunt en meetdoelen 2. Indicatoren en objecten 3. Metrieken 4. Metingen. Het diagram op pag. 18 geeft de gegevensgroepen en hun relaties weer. De gebruikte symbolen zijn: bedrijfs oriëntatie gegevensgroep, waarbij in hoofdstuk 2 naast de uitwerking ook een voorbeeld-invulling is gegeven meetdoel gegevensgroep, uitgewerkt in hoofdstuk 2 gezichtspunt - meetdoel gegevensgroep die een relatie tussen andere gegevensgroepen weergeeft, niet nader uitgewerkt. relatie tussen gegevensgroepen (1 op n) In de Goal-Question-Metric methode [1], [3] wordt een driedeling gehanteerd. Van geformuleerde doelen komt men via het formuleren van de juiste vragen tot de toe te passen metrieken. In het hier geschetste raamwerk zijn de vragen niet direct als aparte gegevensgroep of laag van groepen terug te vinden, en tussen doelen en metrieken zitten verschillende andere groepen van gegevens. Vragen zijn vanuit dit raamwerk bezien hulpmiddelen om bijvoorbeeld de meetdoelen te vinden, de indicatoren en/of de objecten die gekoppeld zijn aan een meetdoel, de benodigde interne attributen, etc. De gegevensgroepen in het model die enkel een relatie weergeven tussen andere gegevensgroepen, zijn te zien als representatie van de toepassing van vragen. Door middel van gerichte vragen wordt immers de relatie tussen bepaalde gegevensgroepen duidelijk gemaakt. In deel II wordt hierop verder ingegaan. Softwaremetrieken 15

18 DEEL I 1. Raamwerk overzicht 1.1 Bedrijfsdoel, bedoeling, gezichtspunten en meetdoelen Metingen dienen een bepaald doel. Een organisatie die metrieken toepast wil hier iets mee bereiken. In het raamwerk zijn drie groepen van gegevens onderscheiden om dit te kunnen aanduiden: - De bedrijfsdoelen (goals) vanuit het bedrijfsmatige perspectief, gekoppeld aan de bedrijfsoriëntatie en -strategie Deze zaken zijn hier geordend in een eenvoudig hiërarchisch model: de oriëntatie leidt naar een of meer strategische keuzes, die op hun beurt leiden naar een set doelstellingen. - Het gezichtspunt, dat weergeeft welke partijen betrokken zijn in het proces van toepassen van metrieken, bij het behalen van de doelstellingen etc. - De bedoeling (purpose) van het meten op zich: bijvoorbeeld het enkel vaststellen van een situatie of ook het actief bewaken van het verloop van zaken. De bedoeling die men kan hebben hangt samen met het ontwikkelingsstadium waarin een organisatie zich bevindt. De bedrijfsdoelstellingen, gezichtspunten en de bedoeling van het toepassen van metrieken moeten worden vertaald in meer concrete meetdoelen. Een meetdoel kan te maken hebben met verschillende bedoelingen, gezichtspunten en bedrijfsdoelstellingen en omgekeerd. Dit is in het model weergegeven door de drie relatie-groepen: bedrijfdoel-meetdoel, gezichtspunt-meetdoel, en bedoeling-meetdoel. Elk meetdoel kan geformuleerd worden in de vorm van een aantal operationele vragen. Operationeel betekent in dit verband dat een object bij het doel aangewezen kan worden, en dat een resultaatwaarde gespecificeerd kan worden die aangeeft hoe men gemeten waarden moet interpreteren (bijvoorbeeld wel of niet voldoende). 1.2 Indicatoren en objecten Dit deel van het model omvat de belangrijkste objecten waaraan gemeten kan worden en de eisen die de organisatie stelt aan deze objecten, in de vorm van indicatoren. De objecten (entities) zijn producten, processen of resources, de belangrijkste objecten voor softwaremetrieken. Deze objecten zijn in hoge mate onderling verbonden. Bijvoorbeeld: een softwareontwikkelingsproces gebruikt verschillende soorten resources (mensen, hulpmiddelen, infrastructuur) en levert verschillende producten (specificaties, ontwerpen, sources, rapporten) op, die op hun beurt weer input zijn voor andere processen. In het kader van dit onderzoek zijn al dergelijke relaties niet verder uitgewerkt. Dit zou leiden tot een metamodel van bijv. de software-ontwikkelingsmethoden. In dit raamwerk is alleen een relatie-gegevensgroep (object structuur) opgenomen, die in principe alle typen relaties zou kunnen specificeren. De indicatoren zijn de externe (van buiten zichtbare) kenmerken van de objecten, waarvoor een organisatie criteria en waarden kan aangeven. Sommige indicatoren zijn direct gekoppeld aan objecten, andere hebben hiermee een meer complexe samenhang. Dit is aangegeven als de relatie-gegevensgroep object-indicator. Een meetdoel kan van toepassing zijn op een of meer objecten en op een of meer indicatoren. Ook omgekeerd kunnen objecten en indicatoren in verschillende meetdoelen een rol spelen. Dit is uitgewerkt in de vorm van de relatie-gegevensgroepen object-meetdoel en indicator-meetdoel. Softwaremetrieken 16

19 DEEL I 1. Raamwerk overzicht 1.3 Metrieken Het metrieken-deel van het model bevat de verzameling van de attributen: eigenschappen die direct meetbaar zijn, zoals tijdsduur, inspanning, aantal incidenten. Deze attributen betreffen verschillende objecten, aangegeven door de relatie-gegevensgroep object-attribuut. De metingen van deze primitieve attributen kunnen samengevoegd worden in meer ingewikkelde maten via een formule, samenstelling etc.. De manier waarop de primitieve attributen samengevoegd worden is de methode ofwel metriek. Het resultaat geeft enige informatie over de indicator. Dit betekent dat een attribuut, gekoppeld aan een bepaald object, een rol speelt in een metriek. Bijvoorbeeld de tijdsduur (attribuut) van een proces (object) is een component in een metriek die vertraging weergeeft. De rol die een attribuut van een object speelt in een metriek wordt gerepresenteerd door de relatie-gegevensgroep metriek detail. De situatie hoeft in de praktijk niet altijd zo complex te zijn als hier geschetst. Het kan voorkomen dat een waarde van een attribuut zonder veel bewerking als indicator toepasbaar is. In deel II zijn diverse voorbeelden uitgewerkt. Meer gedetailleerde kenmerken van metrieken, zoals schaaltype, meeteenheid, zijn in dit raamwerk niet uitgewerkt. Dergelijke kenmerken zijn in de literatuur uitgebreid beschreven (zie bijv. [2], [4]). 1.4 Metingen Het deel Metingen bevat de resultaten van werkelijke metingen: de interne attribuut waarden, die samengesteld kunnen worden tot het meetresultaat. De werkelijke bijdrage van de waarde van het attribuut in het meetresultaat is gespecificeerd in de relatie-gegevensgroep metriek detail resultaat. Het meetresultaat moet leiden tot beantwoording van de vraag die gekoppeld is aan het meetdoel, ofwel een resultaat op het niveau van de indicator (indicator resultaat). Afhankelijk van welke bedoeling men heeft met het meetprogramma kan het nodig zijn de resultaten te vergelijken met een beoogde of verwachte doelwaarde die men dan van tevoren moet hebben vastgesteld. Deze doelwaarden (bijv. een verwacht aantal van maximaal 20 probleemmeldingen per week) moeten dan geformuleerd worden per indicator-resultaat en voorzover mogelijk terugvertaald worden naar gedetailleerde meetresultaten. Softwaremetrieken 17

20 DEEL I 1. Raamwerk overzicht 1. bedrijfsdoel, bedoeling, gezichtspunt en meetdoel bedrijfsoriëntatie bedrijfsstrategie bedrijfsdoel gezichtspunt bedoeling bedrijfsdoel - meetdoel gezichtspunt - meetdoel bedoeling - meetdoel meetdoel 2. indicatoren en objecten object - meetdoel indicator - meetdoel object structuur object objectindicator indicator 3. metrieken object - attribuut metriek detail metriek attribuut 4. metingen attribuut waarde metriek detail resultaat metriek resultaat indicator resultaat Softwaremetrieken 18

21 DEEL I 2. Raamwerk Details 2. Raamwerk Details 2.1 Bedrijfsdoel (Business Goal), bedrijfsstrategie en -oriëntatie Bedrijfsdoelen worden afgeleid van de bedrijfsoriëntatie en de bedrijfsstrategie. Dit raamwerk bevat een eenvoudig hiërarchisch model. Er zijn tal van indelingen te geven. Het onderstaande voorbeeld gaat vooral uit van de manier waarop een organisatie zich oriënteert op haar omgeving: Bedrijfs Oriëntatie Bedrijfs Strategie Bedrijfsdoel Klant gericht Customer relationship management Klanttevredenheid vergroten Klant loyaliteit vergroten Product kwaliteit verbetering Product/service individualisatie Optimaliseren prijs/prestatie ratio Service level verbetering Reduceren response tijden Klantenservice verbeteren Op tijd leveren Markt gericht Market development Competitief voordeel behalen/houden Reduceren time to market Commercialiseren nieuwe technologie Percentage nieuwe producten vergroten Product/service diversificatie Productie flexibiliteit vergroten Verkoop gericht Voorwaartse externe integratie Distributiekanalen uitbreiden/beheersen Verkoop promotie Omzet verhogen Marktaandeel vergroten Productieproces gericht Schaalvergroting Productiviteitsverbetering Benuttingsgraad verbetering Achterwaartse externe integratie Minimaliseren van productieproblemen Interne integratie Productiviteitsverbetering Business process redesign Reduceren productie doorlooptijden Ontwikkelen nieuwe technologie Reduceren productie doorlooptijden Product/service gericht Product/kwaliteit leiderschap Kwaliteit producten/services verbeteren Product differentiatie Percentage nieuwe producten vergroten Technologie leiderschap Nieuwe technologie toepassen Product innovatie Product lifecycle beheersen Softwaremetrieken 19

22 DEEL I 2. Raamwerk Details (Vervolg) Bedrijfs Oriëntatie Bedrijfs Strategie Bedrijfsdoel Kosten gericht Kosten management Kosten beheersen Kosten reductie Productie standaardiseren Hergebruik toepassen Inkoopkosten verminderen Financieel resultaat gericht Portfolio management Financiële diversificatie Voorraadkosten verminderen Toename Shareholder's value Verkorten return of investment (roi) Kosten/opbrengsten ratio verbeteren Financiële onafhankelijkheid vergroten Budget limieten beheersen Budgetteren Resource gericht Capaciteitsontwikkeling Werknemer voldoening vergroten Werknemer loyaliteit vergroten Resource utilization Resource productiviteit vergroten management Creativiteit ontwikkeling Idee generatie vergroten Organisatie ontwikkeling Organisatie structuur verbeteren Communicatie verbeteren Flexibiliteit (taak/roltoewijzing) vergroten Softwaremetrieken 20

23 DEEL I 2. Raamwerk Details 2.2 Gezichtspunt (Viewpoint) Een gezichtspunt geeft een bepaald niveau van beschouwing aan. In de eerste plaats is een verdeling te maken in extern en intern gezichtspunt. - Extern Beschouwing van organisatie van buitenaf, bijv. vanuit het (vaak toegepaste) standpunt van de klant. Andere gezichtspunten die van belang kunnen zijn, zijn het gezichtspunt van de leverancier of van de externe organisatie die bijvoorbeeld kwaliteits- of performance-beoordelingen uitvoert of op een andere wijze controle uitoefent op of een beoordeling geeft van producten of processen van de organisatie. Klant gezichtspunt Externe organisatie gezichtspunt Externe leverancier gezichtspunt Extern management gezichtspunt Gebruiker gezichtspunt Beheer gezichtspunt Exploitatie gezichtspunt Externe kwaliteitsmeting gezichtspunt Externe auditor gezichtspunt Extern management gezichtspunt - Intern Het interne gezichtspunt kan gedefinieerd worden volgens de breedte van het blikveld: - Top management Beschouwing van de organisatie in de context: de raakvlakken met de buitenwereld - Middle management Het gezichtspunt van het middle management betreft afdelingen binnen organisatie en hun onderlinge raakvlakken - Project/teammanagement Beschouwing van processen en producten binnen een projectmatige activiteit - Persoon Bij dit viewpoint wordt het persoonlijk functioneren van een afzonderlijke medewerker bezien. Verder kan intern gekeken worden vanuit specifieke diensten, producten of processen. Scope binnen Organisatie Service/product/proces Top (corporate) management gezichtspunt Afdelings (middle) management gezichtspunt Project management gezichtspunt Team management gezichtspunt Individueel gezichtspunt Delivery gezichtspunt Quality gezichtspunt Softwaremetrieken 21

24 DEEL I 2. Raamwerk Details 2.3 Bedoeling (Purpose) Een organisatie zal een bepaalde bedoeling hebben met het toepassen van metrieken. In het algemeen kan deze bedoeling worden onderscheiden in (zie o.a.[4]): - Vaststellen (Leren kennen, Herkennen, Begrijpen, Understand) Door te meten ontstaat inzicht in de producten en processen - Sturen (Control) Op basis van inzicht kan men een doelwaarde vaststellen en sturen op het bereiken van deze waarde. Om een realistische doelwaarde te kunnen vaststellen moet men beschikken over voorspellingen, normen. - Verbeteren (Improve) Wanneer men in staat is om te sturen op een beoogd resultaat kan het proces verder geoptimaliseerd worden. Er is een globale relatie te leggen tussen deze bedoeling en de CMM-niveaus: Bedoeling Vaststellen Sturen Verbeteren CMM-niveau 1 Initial, 2 Repeatable 3 Defined, 4 Managed 5 Optimizing Afhankelijk van de maturity in het software engineering werkveld kan een organisatie geïnteresseerd zijn in het enkel begrijpen van haar processen en producten, het beheersen ervan of het verbeteren van de processen en producten. Een organisatie die zich bevindt in level 2 zal gebaat zijn met het toepassen van metrieken om meer zicht te krijgen op de eigen processen voor softwareontwikkeling en -maintenance, en de kwaliteit van de producten. Organisaties op level 3 of 4 passen metrieken toe om hun standaardprocessen voor softwareontwikkeling met behulp van normen en binnen vastgestelde marges te kunnen sturen. Voor level 4 organisaties is deze sturing meer verfijnd (van globale bandbreedte naar meer statistisch onderbouwde en analyseerbare variatie). Tenslotte is een level 5 organisatie gericht op het door meting continu zichtbaar maken van zwakke plekken in processen of producten, het afwegen van maatregelen en het ook weer zichtbaar maken van de resultaten van deze maatregelen. De onderstaande invulling geeft nog enkele mogelijke varianten aan: Vaststellen Sturen Verbeteren Algemeen Beperkt aandachtsgebied Specifiek aandachtspunt Binnen bepaalde grenzen houden Sturen op een specifiek doel Signaleren en benutten van voorkomende kansen Verbeteren volgens vooropgezet plan Softwaremetrieken 22

25 DEEL I 2. Raamwerk Details 2.4 Meetdoel (Measurement goal) Het meetdoel is het antwoord op de vraag WAAROM (bijv. voor welk bedrijfsdoel en met welke bedoelingen) en de vraag voor WIE (bijv. vanuit wiens gezichtspunt) de metingen worden uitgevoerd. Als de meetdoelen juist zijn geformuleerd kunnen ze worden vertaald in indicatoren en gewenste waarden voor deze indicatoren. Bijvoorbeeld een high-level bedrijfsdoel kostenreductie kan leiden tot een meetdoel meten van kosten van productiefouten van afdeling Y. Dit hangt vanzelfsprekend af van de gekozen bedoeling (bijv. vaststellen) en gezichtpunt (bijv. binnen een bepaalde afdeling). 2.5 Object (Entity) Objecten op het hoogste te onderscheiden niveau zijn: - processen - producten - bronnen (resources). Deze kan men onderverdelen in meer gedetailleerde objecten. Voor producten van systeemontwikkeling valt te denken aan technisch ontwerp producten, technische modules, source statements. Proces-objecten omvatten alle activiteiten uit de lifecycle van een informatiesysteem, van de eerste analyses tot onderhoud, gebruik en exploitatie van systemen. De activiteiten kunnen zowel projectsgewijs uitgevoerde activiteiten als activiteiten binnen reguliere processen in een organisatie zijn. De decompositie van de objecten geeft antwoord op de vragen WAT (producten, bronnen) en WAAR (processen) gemeten moet worden. Voorbeelden (volgende pagina s): Softwaremetrieken 23

26 DEEL I 2. Raamwerk Details Processen: Ontwikkeling Analyse/ontwerp Business Ontwerp Functioneel Ontwerp Technisch Ontwerp Realisatie Bouw Test Unit test Systeem test Acceptatietest Productie (Exploitatie) Applications Batch verwerking Utilities&Monitoring Online processen Utility jobs System monitoring Support (Beheer) ITIL processes Service Level Management Problem Management Change Management Configuration Management Performance Management Security Management Capacity Management Availability Management Accounting Management Maintenance Object Analyse Business Analyse Functionele Analyse Technische Analyse Programma Analyse Impact Analyse Configuratie Mgmt Scope Analyse Sizing / Estimating Configuratie administratie Configuratie beheer Re-engineering Forward Engineering (zie Ontwikkeling) Reverse Engineering Ontwerp generatie Documentatie generatie Object Analyse (zie Maintenance) Impact Analyse (zie Maintenance) Alternatieven Analyse Renovatie, Redesign, herstructurering etc. Softwaremetrieken 24

27 DEEL I 2. Raamwerk Details Producten: Faseproduct Business Ontwerp Documentatie Componenten Functioneel Ontwerp Documentatie Componenten Technisch Ontwerp Documentatie Componenten Realisatie Documentatie Productie manuals Batch schedules User manuals Interface beschrijvingen Componenten Test Documentatie Test plannen Test cases Test resultaten Configuratie documentatie Jobs/procedures Executables Sources/modules Copybooks/Includes etc Repository Database/segment/view/table Flat files Screens/forms/reports Parameters Componenten Test scripts etc Assemblage Geconfig. product Applicatie Units Ext.product Geconfig. product Applicatie Units Informatie Info-package Rapporten etc. Softwaremetrieken 25

28 DEEL I 2. Raamwerk Details Resources: Mensen Management Lijn Management Corporate Division Department Project Management Project Manager Team Manager Operational Analysis/Design Business Design Engineers Funct. Design Engineers Technical Design Engineers Support Construction Test Maintenance Operations System Support Middelen Infrastructuur Hardware Software Implementation Engineers Testing Engineers Maintenance Engineers Re-engineering Engineers Production Engineers Support Engineers Quality engineers Infrastructuur engineers Communicatie Netwerk Infrastructuur Tools Ontwikkeltools Programmeertalen Ontwikkelplatforms Maintenance Tools Support Tools Re-engineering Tools Meettools Methoden Mgmt&control Project management Methodologie Technieken Quality management Methodologie Technieken Ontwikkeling Ontwikkelingsmethoden Methodologie Technieken Faciliteiten Office Office faciliteiten Personal Werkplek faciliteiten Personal equipment Softwaremetrieken 26

29 DEEL I 2. Raamwerk Details 2.6 Indicator (External attribute) De indicatoren (external attributes, ook wel aangeduid als focus) representeren de grootheden die bijdragen aan het meetdoel. Bijvoorbeeld de indicator uitval kosten draagt bij aan een meetdoel meten van kosten van productiefouten. Indicatoren op een globaal niveau, zoals de algemeen bekende kwaliteitsattributen, kunnen ontleed worden naar detailniveau, zoals onderhoudbaarheid, flexibiliteit, integriteit. Zo ontstaat een hiërarchie van indicatoren. Deze kan opgezet worden overeenkomstig algemene standaards zoals ISO, maar ook zelf-gedefinieerde indelingen zijn toepasbaar. De indicatoren hebben binnen een metrieken programma een bepaalde doelwaarde. Deze waarde komt voort uit de kwantificering van het meetdoel, bijv: een doelwaarde van minder dan x defects per tijdseenheid voor een operationeel systeem, of een beschikbaarheid van 99% voor een operationeel systeem. Deze doelwaarden kunnen bepaald worden uit verzamelde historie. De waarden zijn in het algemeen specifiek voor een organisatie, object en gezichtspunt. Indicatoren kan men bijvoorbeeld verdelen in: - financiële indicatoren, te ordenen in een kosten-opbrengsten onderverdeling - productiviteitsindicatoren - kwaliteitsindicatoren. Financiële indicatoren: Kosten Investeringen Ontwikkelkosten Kapitaal kosten Operationeel Beheerskosten Performance metingen Audits&reviews Uitval kosten Proces kosten Product kosten Kapitaal kosten Opbrengsten Prod.&diensten Besparingen Productiviteitsindicatoren: Verkopen Kapitaal besparingen Proces besparingen Product besparingen Proces efficiency Tijd gedrag Doorlooptijd Volume/Throughput Product hoeveelheid Functionaliteit Omvang Complexiteit Resource efficiency Mensen Werk-inspanning Hardware Productiviteit Software Productiviteit Tools Productiviteit Softwaremetrieken 27

30 DEEL I 2. Raamwerk Details Kwaliteitsindicatoren (volgens ISO9126, [10] ) Functionaliteit Betrouwbaarheid Bruikbaarheid Onderhoudbaarheid Portabiliteit Efficiency Suitability Accuracy Interoperability Compliance Security Traceability Maturity Fault tolerance Recoverability Availability Degradability Understandability Learnability Operability Explicitness Customisability Attractivity Clarity Helpfulness User-friendliness Analysability Changeability Stability Testability Manageability Reusability Adaptability Installability Conformance Replaceability Time behaviour Resource behaviour Softwaremetrieken 28

31 DEEL I 2. Raamwerk Details 2.7 Attribuut (Internal attribute) Een (intern) attribuut (of variabele) is een elementaire eigenschap of kenmerk van een object. De interne attributen hebben betrekking op producten, processen en resources. Proces Planning/voortgang Voortgang Budget Kosten Inspanning Kwaliteit Audit/review resultaten Trouble reports Stabiliteit Requirements stabiliteit Aantal req. wijzigingen Omvang stabiliteit Aantal omvangwijzigingen Proces stabiliteit Aantal proceswijzigingen Resourcegebruik stabiliteit Veranderingen, pieken Product Architectuur Information flow Fan-in/fan-out Gegevens structuur Structuur complexiteit Ontwerp structuur Koppeling, samenhang, modulariteit Verwerking Procedurele complexiteit Statement en data complexiteit Verwerkingsniveaus Nesting Omvang-gerelateerd Lines of code (Loc) gebaseerd Statements, comments, datafields Functionaliteit gebaseerd Aantal functies Functiepunten Gebruik gebaseerd Run time functiepunten Resources Personeel Kennis overdracht Inleertijd Uren, kosten Productiviteit Voortgang Hardware infrastructuur Kosten Performance Software infrastructuur Kosten Performance Tool Kosten Performance Faciliteiten Kosten Performance Softwaremetrieken 29

32 DEEL I 2. Raamwerk Details 2.8 Metriek (Metric, Metric specification, Measurement method) De metriek combineert de informatie over een aantal attributen. De metriek omvat een procedure om de attribuutwaarden te verkrijgen en te bewerken tot een waarde van de betreffende indicator. Dat kunnen redelijk directe berekeningen zijn volgens formules, maar ook meer indirecte afleidingen (compound metrics). De procedures kunnen worden ondersteund door hulpmiddelen die het verzamelen, berekenen/bepalen en rapporteren vergemakkelijken. De metrieken en bijbehorende technieken voor het verkrijgen en bewerken van de afzonderlijke attribuutwaarden beschrijven HOE de meting moet worden uitgevoerd. Voorbeelden en uitwerkingen zijn opgenomen in deel III. Verschillende gezichtspunten leveren op ogenschijnlijk identieke indicatoren soms heel verschillende metrieken op. Zo heeft een indicator productkwaliteit voor een ontwikkelaar vaak in hoofdzaak te maken met het softwarefouten en metrieken om deze in kaart te brengen. Een verkoper zal productkwaliteit echter veeleer invullen als een indicator gebaseerd op aantallen klachten en vragen van gebruikers van de software, niet noodzakelijk samenvallend met softwarefouten. 2.9 Attribuutwaarde, Metriek resultaat en Indicator resultaat De meetresultaten zijn de werkelijke uitkomsten van de meting per attribuut en de daarmee berekende/bepaalde uitkomsten van de metriek, als de werkelijke waarden van de attributen volgens de procedure worden verwerkt tot een indicatorwaarde. De beoogde/verwachte doelwaarden zijn indien van toepassing tevoren voor de meetresultaten bepaald. Softwaremetrieken 30

33 DEEL II BEPALEN EN TOEPASSEN VAN METRIEKEN Softwaremetrieken 31

34 Softwaremetrieken 32

35 DEEL II 0. Inleiding 0. Inleiding 0.1 Dit deel In dit deel wordt getracht een antwoord te geven op de vraag hoe men in een bepaalde situatie de juiste metrieken kan vinden en toepassen. Het is opgezet als een procesmatige beschrijving. Er zijn verschillende manieren om een dergelijk proces in te gaan en te doorlopen. In 0.2 wordt hierop ingegaan en worden de gemaakte keuzes toegelicht. Het procesmodel zelf bestaat uit twee delen: 1. Proces overzicht De processen worden in hoofdlijnen aangegeven. 2. Proces details In dit hoofdstuk worden de onderscheiden processen afzonderlijk uitgewerkt. Aan de hand van een voorbeeld wordt de werkwijze verduidelijkt. Vragen (volgens de Goal-Question-Metric aanpak, zie o.a. [1]) vormen een belangrijk hulpmiddel bij het doorlopen van het proces, met name bij het bepalen van doelstellingen, performance indicatoren en attributen. Dit wordt toegelicht in hoofdstuk 3. In hoofdstuk 4 wordt tenslotte kort ingegaan op de kwaliteitseisen die men kan stellen aan softwaremetrieken. 0.2 Noodzaak en nut van een procesmatige beschrijving Het bepalen en toepassen van metrieken kan op twee manieren worden benaderd: - Vanuit de toepassingsvraag: wat wil ik weten? Men kiest metrieken om ze toe te passen op bepaalde problemen in een organisatie. Dit kan zijn het vinden van knelpunten, vroegtijdige detectie van fouten, het leren van ervaringen, het beheersen of verbeteren van een productieproces, etc. Metrieken moeten gekoppeld zijn aan doelen die belangrijk zijn voor gedefinieerde doelgroepen. De relatie tussen het doel en het belang voor de doelgroep enerzijds en het te meten onderwerp anderzijds moet duidelijk zijn. - Vanuit de kwaliteit van de metrieken: wat kan ik meten? Een metriek moet betrouwbare informatie opleveren. Een metriek moet derhalve ook voldoen aan meer "technische" kwaliteitseisen zoals statistische betrouwbaarheid, voldoende correlatie met hetgeen men wil vaststellen, afwezigheid van meetfouten, etc. Daarnaast gelden ook praktische criteria als eenvoudige toepasbaarheid, beschikbaarheid van benodigde gegevens, begrijpelijkheid. Metrieken moeten in het algemeen direct praktisch in te zetten zijn en de resultaten moet men kunnen vertalen in maatregelen. Softwaremetrieken 33

36 DEEL II 0. Inleiding Het volgende schema geeft de twee benaderingswijzen weer: 1 ) software ontwikkeling/maintenance/exploitatie besturend systeem bedrijfsdoelen meetdoelen wat wil ik weten? indicatoren metriek metriek attributen attributen attributen attributen attributen attributen attributen resources processen producten bestuurd systeem software ontwikkeling/maintenance/exploitatie wat kan ik meten? Vanwege het onderkende belang van praktische toepasbaarheid is in het vervolg van deze beschrijving vooral ingegaan op de toepassingsvraag en minder op de kwaliteit van de metriek. Daarbij moet worden opgemerkt dat bij een goed softwaremetrieken programma aan beide invalshoeken de juiste aandacht moet worden geschonken. De kwaliteit van metrieken komt aan de orde in hoofdstuk 4. 1)schema deels ontleend aan [8], zie ook [4], [1] Softwaremetrieken 34

37 DEEL II 0. Inleiding De procesbeschrijving omvat alleen de specifieke activiteiten voor het opstellen en uitvoeren van een meetprogramma. Zaken als: - Afbakening en begrenzing zoals een tijdslimiet, budget, beschikbare capaciteit/personeel - Toelaatbare meetinspanning, gebruik van aanwezige informatie - Fasen, mijlpalen, (tussen)producten - Prioriteitsstelling, keuzes, criteria voor keuze en prioriteitstelling - Organisatie, werkwijze, communicatie zijn daarnaast van groot belang om een meetprogramma te laten slagen. Dergelijke zaken vallen echter met name in de projectmanagement disciplines en liggen derhalve buiten de scope van dit onderzoek. Voor een invulling kan worden verwezen naar bijv. [1]. Tenslotte moet worden opgemerkt dat het zwaartepunt in de procesmatige beschrijving ligt op het bepalen van de juiste metrieken. De processtappen die te maken hebben met het uitvoeren, interpreteren en evalueren zijn meer beknopt beschreven. Softwaremetrieken 35

38 DEEL II 0. Inleiding Softwaremetrieken 36

39 DEEL II 1. Proces overzicht 1. Proces overzicht 1.0 Inleiding De processen hebben een hoofdindeling die parallel loopt met de hoofdindeling in het raamwerk van gegevensgroepen (Deel I). 1.1 Bedrijfsdoel, bedoeling, gezichtspunten en meetdoelen Om te beginnen moet het kader voor een softwaremetrieken programma worden gezet, door de belangrijkste business doelstellingen, de bedoeling van het programma en het gezichtspunt te definiëren. Vanuit dit kader moet men vervolgens de meetdoelstellingen formuleren. Dit zijn de concrete doelen voor het metrieken programma. Deze groep van activiteiten moet leiden tot het antwoord op de vraag: wat wil ik weten? 1.2 Indicatoren en objecten Vervolgens moeten de juiste indicatoren worden bepaald die toepasbaar zijn om het behalen van de geformuleerde doelen vast te kunnen stellen. Daarbij moet men ook vaststellen om welke objecten het hierbij gaat. De belangrijkste kwestie in deze hoofdactiviteiten is: wat wil ik meten? 1.3 Metrieken Als de indicatoren en objecten zijn gekozen kan men bepalen welke interne attributen gemeten kunnen worden om een indicator-waarde te kunnen vaststellen, en hoe de gemeten waarden moeten worden samengesteld tot de gewenste indicator-waarde. Men kan dit zelf bepalen of gebruik maken van al bestaande, elders ontwikkelde metrieken. De volgende stap is het vooraf toetsen en mogelijk instellen van de metrieken: - toetsen of de metriek werkt voor het beoogde doel binnen de organisatie - met de beschikbaar zijnde gegevens bepaalde parameters instellen of anderszins in rekening brengen. Softwaremetrieken 37

40 DEEL II 1. Proces overzicht 1.4 Metingen Als de metrieken vaststaan en aldus zijn beproefd kan men overgaan naar het eigenlijke meetprogramma. Wel moet (afhankelijk van de meetdoelstelling die is geformuleerd) worden aangegeven wanneer een meetresultaat moet leiden tot verdere maatregelen: het vaststellen van de beoogde waarden zoals pass/fail grenzen, beoogde waarde (bijv. gewenste productiviteit als waarde van de betreffende indicator). Het uitvoeren zelf bestaat uit het meten en verzamelen van gegevens, al of niet met speciale hulpmiddelen. De meetgegevens kunnen op verschillende wijze worden gepresenteerd (tekst, diagrammen, trendlijnen, aggregaties, etc.). Uit de basisgegevens worden vervolgens de indicator-waarden berekend en deze worden (indien van toepassing) vergeleken met de doelwaarden. Dat levert in het algemeen verschillen die men moet vertalen in acties, maatregelen, verder onderzoek, etc. De resultaten kan men tenslotte, mits goedgekeurd en waar nodig geschoond, toevoegen aan het archief met eigen ervaringscijfers. De resultaten kunnen ook wijzen op tekortkomingen in de metrieken of het onderliggende raamwerk en/of proces. Softwaremetrieken 38

41 DEEL II 2. Proces details 2. Proces details 2.1 Meetdoelstellingen bepalen Allereerst worden voor een organisatie (in dit geval een software engineering-organisatie of project) de belangrijkste bedrijfsdoelstellingen bepaald. Deze worden met behulp van vragen uitgesplitst in een aantal subdoelstellingen die te formuleren zijn als meetdoelen. Aan deze meetdoelen kunnen vervolgens opnieuw vragen worden gekoppeld om te kunnen bepalen of aan die meetdoelstelling is voldaan. In een dergelijke vraag zit vaak al de indicator verborgen. De keuze van de meetdoelen hangt in de eerste plaats natuurlijk af van gemaakte beleidskeuzes (business oriëntatie en strategie), die gelden voor de bedrijfsdoelen. Bij het zoeken naar metrieken moet worden gewaakt voor een explosie aan metrieken als de bedrijfsdoelen uiteen gerafeld worden, en vooral als er meteen meerdere doelstellingen worden onderzocht. Dit geldt dan ook met name voor doelstellingen op het niveau van een gehele organisatie. Wanneer wordt ingestoken op een wat lager niveau is het aantal metrieken in ieder geval veel minder. Het is dus sterk afhankelijk van het niveau waarop de doelstellingen beschouwd worden: bijvoorbeeld vanuit een strategisch, tactisch of operationeel gezichtspunt. Niet alleen de doelstellingen maar ook het gezichtspunt (viewpoint) zijn dus van belang. De meeste organisaties die metrieken gaan opbouwen willen vaak ook op korte termijn resultaten zien. Door in eerste instantie op operationeel niveau te starten met het benoemen van doelstellingen komt men uiteindelijk op een nog te overzien aantal metrieken. Na verloop van tijd valt te overwegen of diverse doelstellingen, mogelijk aangevuld met nieuwe, kunnen worden geaggregeerd tot een hoofddoelstelling. Men verlegt dan het gezichtspunt. Het is ook van belang welke bedoeling men heeft met het meten. Als het gaat om leren kennen van de stand van zaken, vaststellen van trendmatige ontwikkelingen etc. zijn de doelstellingen voor het meten anders dan wanneer men de effecten van uitgevoerde verbeteringsmaatregelen wil toetsen en dus veranderingen wil waarnemen. De meetdoelstellingen moeten in elk geval helder, precies en meetbaar worden geformuleerd. Het kritisch bezien en waar mogelijk beantwoorden van geformuleerde vragen levert al een beperking op in de groei van het aantal metrieken en draagt bij aan bruikbare formulering. Hierna staat een voorbeeld van de uitwerking behorende bij een bedrijfsdoelstelling Verbeteren van klanttevredenheid 1 ). In de tabel staat een set van vragen die men zou kunnen stellen. De entiteiten (zie schema) Producten, Processen en Resources worden hierbij in ogenschouw genomen om de vraagstelling wat meer structuur te geven. Om te komen tot heldere vragen zijn deze entiteiten nog onderverdeeld in subentiteiten voor zover deze iets te maken hebben met de hoofddoelstelling betreffende de klanttevredenheid. In dit voorbeeld is het gezichtpunt het systeemontwikkelingsproject en het meetprogramma is gericht op verbetering. 1) Het gaat hierbij om voorbeelden van doelstellingen, objecten etc. In dit kader worden voor de als voorbeeld gebruikte termen geen nadere definities gegeven. Softwaremetrieken 39