63,4 6RIWZDUH 3URFHVV,PSURYHPHQW IRUEHWWHU4XDOLW\ SAMMENSTILL ANALYSER GJENNOMFØR KARAKTERISER SETT MÅL PLANLEGG $QDO\VHRJSUHVHQWDVMRQDYPnOHGDWD 9HUVMRQ 9 'DWR 6WDWXV,DUEHLG )RUIDWWHU.DUL-XXO:HGGH 7LOJMHQJHOLJKHW 63,4LQWHUQ
5(9,6-216+,6725,.. 9HUVMRQ 3URGDY 'DWR.6DY 'DWR 2YHUOHY 'DWR *RGNMDY 'DWR 'LVWULEXHUW 'DWR (QGULQJ 0.1 1997-09.05 Foreløpig versjon 1.0 1997-11-07 Innarbeidet kommentarer
,11+2/'6)257(*1(/6(,11/('1,1* 3/277(7(.1,..(5 +YDHUHQSORWWHWHNQLNN 1nUVNDOYLEUXNHSORWWHWHNQLNNHU +YDNDQYLEUXNHSORWWHWHNQLNNHUWLO +YLONHQSORWWHWHNQLNNVNDOEUXNHV 6SUHGQLQJVGLDJUDP 7LGVGLDJUDP;WSORW.LYLDWGLDJUDP 6WROSHGLDJUDP.DNHGLDJUDP.RQWUROOGLDJUDP %R[GLDJUDP )(('%$&.6(6-21(5 +YDHUIHHGEDFNVHVMRQHU )RUEHUHGHOVHU 3UHVHQWHUHRJWRONHGDWD 2336800(5,1*
,QQOHGQLQJ Dette bruksnotatet gir en veiledning i hvordan vi kan analysere og presentere metrikkdata på en effektiv måte ved hjelp av plotteteknikker. Notatet kan brukes både ved planlegging og gjennomføring av dataanalyse. Første del av notatet vil ta for seg hvordan vi kan bruke plotteteknikker til å analysere og presentere data. Andre del av notatet vil beskrive feedback-sesjoner, hvordan disse kan brukes til å tolke data, relatere disse til oppsatte mål og identifisere idéer til forbedring. Denne delen er relatert direkte til GQM hvor feedback-sesjoner er en sentral del. Feedback-sesjoner kan imidlertid også med hell brukes sammen med andre metoder der en samler data, f. eks. årsaksanalyse. Generalisering og pakking av erfaringer for bruk i senere prosjekter blir beskrevet i bruksnotat Erfaringsinnsamling. Analyse ved hjelp av statistiske metoder blir behandlet i et eget bruksnotat - Bruk av statistiske metoder. 3ORWWHWHNQLNNHU +YDHUHQSORWWHWHNQLNN Plotteteknikker er enkle grafiske fremstillinger av data i diagrams form. Diagrammene utarbeides av den som er ansvarlig for forbedringsprosjektet og presenteres på feedbacksesjoner. Den primære målgruppen er prosjektdeltakerne, dvs. de som dataene angår direkte og som har vært med på å samle inn dataene. Plotteteknikker som er beskrevet i dette notatet er som følger: Spredningsdiagram viser sammenhengen mellom to parametre Tidsdiagram viser sammenhengen mellom to parametre hvorav den ene representerer tid Kiviatdiagram viser sammenhengen mellom flere parametre Stolpediagram en eller flere parametre, en stolpe for hver parameterverdi Kakediagram viser relative forskjeller mellom parametre Kontrolldiagram en parameter, flere observasjoner samlet inn over tid Box-diagram en parameter, flere observasjoner Med parameter menes her metrikk eller egenskap knyttet til en metrikk. De fleste regneark har gode funksjoner for å tegne disse diagrammer. Unntaket er Box-diagram. 1nUVNDOYLEUXNHSORWWHWHNQLNNHU Plotteteknikker brukes for å sammenstille innsamlede måledata på en slik måte at de kan presenteres for prosjektdeltakerne. Diagrammene bør vise dataene slik de ble samlet inn, uten forutgående analyse. Dette er viktig for å sikre at vi ikke legger for mye av vår egen tolkning
inn i de dataene vi presenterer. Siden det er prosjektdeltakerne som er eksperter på utviklingsprosessen er det først og fremst de som skal tolke dataene. Plotteteknikker blir ofte brukt til en første, enkel analyse av metrikkdata. I mange tilfeller vil denne analysen være tilstrekkelig til å kunne ta beslutninger. Noen ganger må den følges opp med mer omfattende analyse for å kunne avgjøre om de foreløpige tolkningene er gyldige eller ikke. Konklusjonen kan også være at vi ikke kan ta noen beslutning ut fra de innsamlede data. Vi kan da enten droppe den gitte metrikken i det videre arbeidet eller vi kan samle inn mer eller andre data. +YDNDQYLEUXNHSORWWHWHNQLNNHUWLO Plotteteknikker kan brukes til å Analysere et eller flere datasett for å Se på spredningen av dataene Identifisere outliers atypiske verdier Se på sammenhengen mellom metrikker eller egenskaper knyttet til en metrikk Sammenligne flere datasett Følge opp datainnsamling over tid for å se på Trender Om dataverdiene holder seg innenfor gitte grenser Effekten av endringer i produkt eller prosess Diagrammene bør være enkle. Ofte viser vi derfor kun en metrikk i hvert diagram, f.eks Antall feil fordelt over fase slik som vist i Figur 6. Dersom vi ønsker å sammenligne måledata for flere metrikker, f. eks metrikker knyttet til samme spørsmål i GQM, kan vi vise flere metrikker i samme diagram. Det er gjort i Figur 5 hvor vi viser metrikkene Antall feil funnet under systemtest og Systemtest volum. Dersom diagrammene viser at vi har atypiske verdier, må vi finne årsaken til disse før vi kan gå videre, dvs. beslutte om de representerer et problem eller om de er et resultat av en tilfeldig variasjon og kan fjernes. +YLONHQSORWWHWHNQLNNVNDOEUXNHV Figur 1 viser grovt sammenhengen mellom hva vi ønsker å vise og hva slags plotteteknikk vi bør bruke. Et datasett er et sett med observasjoner knyttet til en metrikk. Hovedskillet i valg av plotteteknikk går på hvorvidt data knyttet til samme metrikk skal samles inn flere ganger for å følge utviklingen over tid eller om vi skal se på egenskaper separat eller relatert til hverandre. Hvilken plotteteknikk vi så velger kommer an på hva som er målet med analysen, hvor vi ønsker fokus, f. eks. om vi ønsker å se på spredningen i dataene eller om vi ønsker å finne atypiske data. Diagrammene overlapper i anvendelsesområde og det vil noen ganger være en smakssak hva man velger.
Ett eller flere datasett Spredning Sammenheng Atypiske verdier Sprednings-diagram Stolpediagram Kakediagram Sprednings-diagram Stolpediagram Box-diagram Sprednings-diagram Stolpediagram Trendanalyse Sprednings-diagram Stolpediagram Presentere data Relativt til optimale verdier Sammenheng Kiviat-diagram Tidsdiagram Stolpediagram Atypiske verdier Kontrolldiagram Box-diagram Ett eller flere datasett - samlet inn over tid Trendanalyse Tidsdiagram Kontrolldiagram Kontroll Kontrolldiagram Forbedrings -effekt Box-diagram )LJXU+YLONHQSORWWHWHNQLNNVNDOYLEUXNH Nedenfor er gitt noen eksempler på hvilke plotteteknikker vi kan velge. Vår erfaring er at i tidlige faser før man har mye data og kan foreta statistiske analyse, så er det best å bruke stolpediagram og kiviatdiagram. Andre muligheter er spredningsdiagram og tidsdiagram. (NVHPSHO Vi har flere datasett knyttet til spesifikasjoner. De er knyttet til forskjellige egenskaper ved spesifikasjonene slik som kompletthet, lesbarhet, kravtetthet (krav pr. side) og volum. Vi kan f. eks. velge: 1. Kiviatdiagram for å få et bilde av hvordan egenskapene kompletthet, lesbarhet og kravtetthet ligger an i forhold til optimale verdier. 2. Spredningsdiagram for å se om alle utviklerne har samme oppfatning når det gjelder spesifikasjonens lesbarhet.. Dersom det er få data kan vi også bruke stolpediagram.
(NVHPSHO Vi samler data knyttet til ressursforbruk, dvs. timeforbruk fordelt på aktivitet. Vi kan da velge: 1. Tidsdiagram eller stolpediagram dersom vi ønsker å sammenligne ressursforbruket med planlagt tidsforbruk. 2. Tidsdiagram for å se hvordan ressursforbruket fordeler seg over tid, om det er store topper, eventuelt perioder med liten aktivitet. 6SUHGQLQJVGLDJUDP Spredningsdiagram brukes til å plotte alle data for å se etter mønstre og trender som et resultat av sammenhengen mellom to parametre. En variant av spredningsdiagram er tidsdiagram hvor den ene aksen er tid, fase eller lignende. Tidsdiagram er behandlet i et eget delkapittel. I mange tilfeller vil spredningsdiagram være tilstrekkelig til å foreta en første grov analyse av dataene. Vi kan se om det er sterk sammenheng mellom parametre og vi kan se etter trender. Diagrammet er også godt egnet til å oppdage atypiske dataverdier (outliers). (NVHPSHO Spredningsdiagrammet i Figur 2 viser sammenhengen mellom Systemtest volum og Antall feil funnet under systemtest for fem systemtester. Diagrammet viser at det generelt er en sammenheng mellom volumet på systemtesten og antall feil som blir funnet. Verdiene med ett unntak grupperer seg rundt ei linje. Vi vil imidlertid gå videre for å finne årsaken til at vi ved en av testene fant mange feil til tross for at antall testcase var moderat. To mulige forklaringer er: 1. Produktet var uferdig og lite testet da det ble levert til systemtest 2. Vi kjørte færre tester, men vi kjørte de testene som avdekket feil. Dersom det er riktig, kan vi redusere ressursforbruket i testfasen ved å bli bedre til å finne de riktige testene. For å finne ut av hvilken forklaring som er den rette, må vi definere en ny metrikk som gir oss oversikt over feil fordelt på hvilken testcase som avdekker de.
14 Antall feil 12 10 8 6 4 5 12 9 11 12 2 0 0 20 40 60 80 100 120 Antall testcase )LJXU6SUHGQLQJVGLDJUDP 7\SLVNHDQYHQGHOVHU Sammenhengen mellom ressursforbruk og kodevolum Sammenhengen mellom antall feil og kodevolum Sammenhengen mellom planlagt og virkelig ressursforbruk Sammenhengen mellom antall personer i et prosjekt og tid brukt til prosjektledelse
7LGVGLDJUDP;WSORW Tidsdiagram viser hvordan data varierer over tid og er derfor spesielt egnet til å identifisere trender som er knyttet til tid. Vi kan også se på sammenhengen mellom flere datasett, f. eks følge opp virkelig tidsforbruk mot plantall. (NVHPSHO Figur 3 viser virkelig og planlagt forbruk i et prosjekt til og med kodingsfasen. Prosjektet følger planene godt i starten. Kodingsfasen derimot, er underestimert. 800 700 600 7LPHYHUN 500 400 300 200 100 Virkelig Estimat 0 Krav Design Kode Integr Syste )LJXU7LGVGLDJUDP 7\SLVNHDQYHQGHOVHU Oppfølging av ressursforbruk over kalendertid eller fase Oppfølging av feil funnet i ulike faser Oppfølging mot planer eller estimater, f.eks. virkelig mot planlagt tidsforbruk, Feil funnet mot estimert antall feil osv.
.LYLDWGLDJUDP Kiviatdiagram (også kalt radardiagram) benyttes til å vise flere egenskaper ved et produkt eller en prosess. Formålet er å få en oversikt over hvor god produktet eller prosessen er på de forskjellige områdene. Dersom vi skal kunne bruke Kiviatdiagram må det finnes en største eventuelt minste - eller beste verdi for hver egenskap. Egenskapene kan ha forskjellig måleskala. Vi kan bruke en skala fra 0-10 for Testbarhet samtidig som vi bruker Høy, Middels, Lav for Modenhet. Når vi plotter dataene må vi imidlertid passe på at beste verdi for alle egenskapene ligger i samme avstand fra sentrum i diagrammet. Tilsvarende for dårligste verdi. Det betyr at Høy for Modenhet og 10 for Testbarhet må ligge like langt fra sentrum. Tilsvarende for Lav og 0. Diagrammet gir en god oversikt over hvordan de observerte verdiene ligger relativt til optimale verdier. Det ser vi av hvor stor del av arealet som er fylt. Det er også lett å se hvilke egenskaper som må forbedres for at vi skal kunne øke fyllingsgraden. (NVHPSHO I Figur 4 har vi karakterisert et produkt ved hjelp av seks attributter. Disse er gitt en skår fra 0 til 5 der 5 er best. Diagrammet viser hvordan det gitte produktet er vurdert. Modenhet og Endringsvennlighet kommer dårligst ut og vi kan gå videre for å finne årsakene til dette. Modenhet 5 4 Testbarhet 3 2 1 0 Feiltoleranse Stabilitet Analyserbarhet Endringsvennlighet 7\SLVNHDQYHQGHOVHU )LJXU.LYLDWGLDJUDP Karakterisering av programvaremoduler, prosjekt, produkt, prosess osv. Visualisere resultatet fra spørreundersøkelser
6WROSHGLDJUDP Stolpediagram brukes til å vise sammenhengen mellom parametre for ulike hendelser. Det er også velegnet når vi ønsker å sammenligne nåværende verdier med tidligere verdier, f. eks. sammenligning med en baseline (NVHPSHO Eksemplet nedenfor viser sammenhengen mellom antall testcase og antall feil funnet for de utførte systemtestene. Vi ser at Test 2 og Test 4 finner omtrent like mange feil. Test 4 består imidlertid av vesentlig færre testcase enn Test 2. Vi finner altså flere feil pr. testcase i Test 4. Dette eksemplet er basert på de samme data som i eksemplet i kapitlet om spredningsdiagram. Den atypiske verdien som ble identifisert der tilhørte Test 4. Den videre årsaksanalysen blir den samme i begge tilfellene. 120 100 80 60 Testcase Feil 40 20 0 Test 1 Test 2 Test 3 Test 4 Test 5 )LJXU6WROSHGLDJUDP 7\SLVNHDQYHQGHOVHU Sammenhengen mellom erfaringsnivå i utviklingsteamet og ressursforbruk Sammenhengen mellom feil funnet og tid brukt til testing Sammenhengen mellom testvolum og antall feil funnet Produktivitet fordelt på fase sammenlignet med bedriftens baseline Feiltyper sammenlignet med bedriftens baseline
.DNHGLDJUDP Kakediagram brukes til å vise relative størrelser. Det er spesielt egnet til å få fram hvilke deler som er store og dominerende, eventuelt hvilke som er mye mindre enn de andre. (NVHPSHO I vårt eksempel ser vi at dersom vi lager et diagram for antall feil fordelt på fase, så ser vi at designfasen dominerer. Neste skritt er så å finne ut hvorfor de fleste feil stammer fra designfasen. Det kan føre til at vi må definerer nye metrikker for å finne ut hva slags feiltyper eller kategorier vi har. Et annet alternativ er å se på feilkostnader. Vi vet at de fleste feilene stammer fra design, men vi vet ikke om de koster mest. For å finne ut av dette kan vi definere og samle inn data for to nye metrikker. en metrikk for feilkostnader en metrikk for alvorlighetsgrad 28 % 18 % spec design kode 54 % 7\SLVNHDQYHQGHOVHU )LJXU.DNHGLDJUDP Ressursforbruk fordelt på fase Feil funnet fordelt på type test ( f. eks. enhetstest, integrasjonstest, systemtest, FAT, SAT) Feil, fordelt på introduksjonsfase Feil fordelt på feiltyper
.RQWUROOGLDJUDP Kontrolldiagrammer er viktige når vi skal følge med på verdien til en eller flere parametre, f. eks antall feil funnet pr. testcase under systemtest. Kontrolldiagrammer er særlig viktig dersom en kan samle data over en lengre periode slik at en kan følge utviklingen i et prosjekt. Et kontrolldiagram består av en øvre og en nedre grense samt et gjennomsnitt. Øvre og nedre grense angir grensene for prosessens naturlige variasjon. Det å bestemme verdiene for disse grensene er en del av arbeidet med å utarbeide måleplanen. Ved bruk av kontrolldiagrammer skal vi spesielt være oppmerksomme på verdier som ligger utenfor øvre og nedre grense. Verdier som ligger utenfor grensene på grunn spesielle forhold må fjernes før resten analyseres. Vi må derfor alltid forsøke å finne årsaken til avvikende verdier. Dette gjelder også når resultatet er bedre enn forventet. Dersom vi får bedre resultater enn forventet må vi finne ut hva som gjorde at det gikk så bra, om det var et engangstilfelle eller om det er noe å lære. Ved dårligere resultat enn forventet må tiltak settes i verk. Valg av tiltak bør være en del av forbedringsplanen. Det har begrenset verdi å vite at dette kommer til å gå galt dersom en ikke kan gjøre noe med det. (NVHPSHO I dette eksemplet har vi brukt spredningsdiagram i Excel for å tegne et kontrolldiagram. Vi bruker her kontrolldiagram for å følge opp feiltetthet ved systemtest. Formålet med systemtesten er å sjekke påliteligheten til systemet. Systemet ble regnet som klart for levering dersom antall feil lå innenfor kontrollgrensene. Den første systemtesten hadde bedre resultat enn forventet, dvs. antall feil lå under nedre grense. Årsaken til dette ble identifisert som mangelfulle tester og tiltaket var å øke antall testcase. Dersom vi går tilbake til Figur 5 vil vi se denne sammenhengen også der. Test 4 har en høy feiltetthet. Dette skyldtes at produktet på grunn av tidspress ble sendt til systemtest før den interne testinga var avsluttet. Produktet måtte sendes tilbake til utviklingsavdelingen og en ny test utføres senere.
20 15 10 Nedre Middel Øvre Feiltetthet 5 0 1 2 3 4 5 6 Test )LJXU.RQWUROOGLDJUDP 7\SLVNHDQYHQGHOVHU Kontrollere at feiltetthet holder seg innenfor spesifiserte verdier Kontrollere at f. eks tid som går med til ikke-planlagte aktiviteter ikke går ut over spesifiserte grenser Kontrollere at produktiviteten ikke avviker fra det som har vært normalt i bedriften ( baseline )
%R[GLDJUDP Box-diagram er en nyttig plotteteknikk når vi har flere observasjoner i hvert observasjonspunkt, f. eks. for hvert sekvensnummer. Box-diagram er spesielt viktige når vi vil se på effekten av endringer i produkt eller prosess. Diagrammene skiller seg fra de andre plotteteknikkene ved at den krever noe bearbeiding av dataene før de kan presenteres. Box-diagram er en fornuftig første-analyse også i de tilfeller hvor vi har planlagt en mer avansert dataanalyse senere. Box-diagram gjemmer det som er normalt og har fokus på det som er unormalt i et datasett. Figur 8 viser hvordan vi tegner et Box-diagram. Om man bruker middelverdi og varians eller median og kvartile avhenger av hvilken måleskala vi har. Vi har her benyttet median og kvartiler. Median representerer elementet som er rangert midt i datasettet, dvs elementet hvor halvpartene av elementene har en verdi som er mindre og halvparten av elementene har en verdi som er større. Øvre kvartil er median for elementene som er større enn median og nedre kvartil median for elementene som er mindre enn median. Selve boksen dekker verdiene mellom nedre og øvre kvartil. Nedre og øvre grense representerer de grensene som vi forventer å finne dataverdiene innenfor. Nedenfor er angitt normale verdier for øvre og nedre grense. Box-lengde = Øvre kvartil Nedre kvartil Nedre grense = Max (Nedre kvartil 1,5 Box-lengde, laveste element) Øvre grense = Min(Øvre kvartil + 1,5 Box-lengde, høyeste element) Observerte verdier utenfor øvre og nedre grense kalles outlier og må gies spesiell oppmerksomhet. Nedre grense Nedre kvartil Median Øvre kvartil Øvre grense Outlier X Måleskala Vi kan bruke Box-diagram til å )LJXU(OHPHQWHULHW%R[GLDJUDP Analysere et datasett Vi kan se om dataene er skjevfordelt. Det ser vi på plasseringen av median, om den ligger midt i boksen eller ikke. Vi kan analysere outliers verdier utenfor nedre eller øvre grense. Sammenligne flere datasett Vi kan f.eks. lage Box-diagram for antall anmerkninger pr. forbrukt time ved granskninger og sammenligne granskninger foretatt med og uten sjekklister. Datasettet vi sammenligner med kan også være en baseline, basert på tidligere innsamlede data eller på anslag eller hypotese om hvordan datasettet er sammensatt.
(NVHPSHO Som eksempel kan vi se på effektiviteten ved granskninger definert som antall anmerkninger dividert på tidsforbruk. Vi har et datasett som dekker granskninger slik de opprinnelig ble utført uten sjekklister. Deretter ble sjekklister innført og vi ønsker å se på effekten. Box-diagrammet viser at spredningen på dataene er mindre med sjekklister enn uten. Effektiviteten har i gjennomsnitt blitt litt høyere, dvs man finner flere anmerkninger uten at en bruker tilsvarende mer tid. Den første konklusjonene på dette var at bruk av sjekklister forbedret effektiviteten ved granskninger. En skal imidlertid være noe forsiktig med å dra for bastante konklusjoner ut fra et diagram. Samtidig med at man så på effektiviteten, ble det også undersøkt hva slags type feil som ble funnet i de to tilfellene og det viste seg at sjekklistene konsentrerte seg om layout og at en stor del av anmerkningene angikk slike. Etter å ha fjernet alle feil av denne typen fra datasettet og laget nye Box-diagram viste det seg at bruk av sjekklister senket effektiviteten. Dette var i strid med det vi hadde forventet. Da diagrammene ble lagt fram for prosjektgruppa kom imidlertid forklaringa. Når man bruker en sjekkliste finner en bare det som er tatt hensyn til der. Det var stort sett layoutproblemer og lignende. Resultatet av analysen ble at sjekklistene måtte omarbeides. Antall anmerkninger/antall timeverk 2.0 1.5 X 1.0 0.5 0 X Uten sjekkliste Med sjekkliste )LJXU%R[GLDJUDP 7\SLVNHDQYHQGHOVHU Se på variasjon i produktivitet over flere prosjekter Se på variasjon i feiltetthet over moduler Sammenligne spredningen av feiltetthet over moduler i flere prosjekter Sammenligne antall anmerkninger ved inspeksjoner i to eller flere prosjekter Se på spredningen i resultatet fra en spørreundersøkelse
)HHGEDFNVHVMRQHU +YDHUIHHGEDFNVHVMRQHU Feedback-sesjoner er et viktig hjelpemiddel for å analysere data, og en viktig kilde til å identifisere forbedringstiltak i prosjektet. Feedback-sesjoner må sees i sammenheng med organisatorisk læring. For dette se bruksnotatet Organisatorisk læring. Feedback-sesjonene går ut på å presentere data for prosjektdeltakerne for å få deres tolkning. Dataene presenteres normalt ved hjelp av diagrammer slik som beskrevet i kapittel 2. En feedback sesjon består av følgende trinn: 1. Forberedelser Analysere de innsamlede data og lage diagrammer 2. Presentasjon og tolkning Denne prosessen består av Presentere dataene - i diagrams form for prosjektdeltakerne Diskutere resultatet, se etter atypiske verdier, trender osv. Identifisere forslag til endringer og nye metrikker Feedback-sesjoner er en integrert del av GQM-prosessen og er det som skiller denne metoden fra andre metoder. Feedback-sesjoner kan imidlertid også med hell brukes sammen med andre metoder hvor man samler inn metrikkdata, f. eks. ved årsaksanalyse. Se bruksnotatet Forbedring gjennom årsaksanalyse (RCA). Feedback-sesjoner bør arrangeres regelmessig under datainnsamlingen. Hvor ofte, avhenger av hvor mye data vi har samlet inn. En gang pr. måned er imidlertid passe for de fleste prosjekter. Siden dette i stor grad er en læreprosess, må man ikke ha for store forventninger til den første sesjonen. Resultatene vil komme etter hvert. )RUEHUHGHOVHU Målet med dette trinnet er å få dataene over på en form som gjør at de kan presenteres for prosjektdeltakerne. Grafiske fremstillinger av dataene er ofte det mest hensiktsmessige. Dataene kan analyseres før plotting, men for metrikker kan det være hensiktsmessig å plotte dataene direkte. En analyse kan føre til at vi maskerer atypiske dataverdier og at vi legger egne tolkninger inn i dataene. Ved å bare plotte dataene får vi en friere tolkning fra prosjektdeltakerne. Vi får også en ekstra verifiseringsrunde på de innsamlede data. Statistiske analysemetoder kan brukes når vi har nok data. Også i disse tilfellene vil det imidlertid være fornuftig å presentere enkle diagrammer først og få prosjektdeltakernes reaksjoner på disse. Dersom plottene viser trender eller andre mønstre vil det være fornuftig å følge opp med en statistisk analyse for å se hvor sannsynlig det er at det mønsteret vi har observert ikke bare representerer tilfeldige variasjoner. Dersom vi bruker regneark til å registrere data, kan disse enkelt brukes til å lage grafiske fremstillinger. Regnearkpakker som f. eks. Excel inneholder også verktøy for en del enkle statistiske analyser.
3UHVHQWHUHRJWRONHGDWD Dette er selve feedback-sesjonen. Her skal metrikkdefinisjonene og de innsamlede dataene presenteres for prosjektdeltakerne. Det er prosjektdeltakernes kunnskap om prosjektet og organisasjonen, kombinert med den ekstra innsikt som dataene kan gi, som gir opphav til forbedringsideer. Hovedideen bak feedback-sesjoner er at ved å supplere de innsamlede dataene med subjektive data fra prosjektdeltakerne, kan vi få mer informasjon ut av færre data. Feedback-sesjonene ledes av personen som er ansvarlig for forbedringsprosjektet. Hvor ofte en skal ha slike sesjoner vil variere avhengig av hva slags data en har og hvor ofte de samles inn. Feedback-sesjonene skal imidlertid foregå regelmessig i hele prosjektperioden, f.eks. en gang pr. måned. Det er ikke en etteranalyse som skal utføres når prosjektet er slutt. Feedback-sesjonene er en prosess hvor den som leder sesjonen presenterer metrikkdefinisjoner og tilhørende data. Presentasjonen bør ikke inneholde konklusjoner. Deretter følger en diskusjon hvor prosjektdeltakerne kommer med sine reaksjoner på resultatet. Dette er en kreativ prosess og bør være en fri diskusjon som ikke styres for hardt. Det vi ønsker å få fram i feedback-sesjonene er: 3URVMHNWGHOWDNHUQHVWRONQLQJDYGDWDHQH Se etter atypiske verdier Det kan finnes forklaringer på spesielle verdier. Det trenger ikke å bety at prosessen er feil. Atypiske verdier som skyldes spesielle situasjoner fjernes fra det opprinnelige datasettet og samles i et eget datasett for separat analyse. Et eksempel på en atypiske verdier er lav produktivitet i en periode på grunn av at flere i prosjektgruppen ble forstyrret av feilretting på et annet prosjekt. Se etter trender i dataene, men husk at plottene kun gir indikasjoner. Sørg for at slike tilsynelatende trender følges opp med statistisk analyse før en endelig konklusjon trekkes. Er verdiene de vi hadde forventet? Uventa verdier kan bety at datainnsamlingsprosedyrene ikke er gode nok slik at ikke alle har samlet data på samme måte. Det kan også bety at våre oppfatninger av hva som foregår er feil og må endres. 6YDUSnRJWRONQLQJDYVS UVPnOHQHL*40WUHHW Har vi etter å ha tolket metrikkdataene nok informasjon til å besvare spørsmålene? Hvis ikke, må vi komme med forslag til nye data som må innhentes. Er svarene som forventet? Uventa svar kan ha naturlige forklaringer knyttet til atypiske hendelser i den perioden dataene ble innhentet, men kan også bety at en eller flere hypoteser må forkastes.
)RUVODJWLOHQGULQJHUL*40WUHHW På grunnlag av resultatet fra de to første punktene kan vi ha kommet fram til at vi må endre GQM-treet. Slike endringer vil være av typen Definere nye metrikker knyttet til spørsmål. Dersom f. eks. feiltettheten er større enn forventet kan vi ønske å gå videre og finne ut hvilke feil som er hyppigst før vi setter i gang andre tiltak. Dette kan gjøres ved å introdusere en ny metrikk for å registrere feiltyper. Lage nye hypoteser for metrikker og spørsmål. Vi må utføre statistiske analyser før vi forkaster hypoteser og lager nye.,ghhuwlohqgulqjhulghwwhsurvmhnwhw Forbedringsforslag vil vanligvis dukke opp når dataene blir presentert. Disse forslagene vil ofte føre til at en justerer prosessen før en kjører videre. Eksempler er Oppdatering av datainnsamlingsprosedyrene. Vi har i utgangspunktet telt alle anmerkninger ved inspeksjoner. Det viste seg imidlertid at anmerkninger angående skrivefeil og layoutfeil ble dominerende. Vi gikk derfor over til kun å telle feil som angikk systemets oppførsel. Justering av planer Det viser seg at tida hver enkelt systemutvikler har tilgjengelig til å arbeide på prosjektet er mindre enn forventet. Vi må da enten endre planer eller sette i gang tiltak for å frigi utviklerne fra andre oppgaver.,ghhuwloodqjvlnwljhiruehgulqjhu Dette er ikke noe sentralt punkt i feedback-sesjoner. En etteranalyse av prosjektet vil ta seg av generalisering og pakking av slike resultater. Gode forslag til forbedringer bør likevel dokumenteres allerede på dette tidspunktet. Det å ta vare på og dokumentere slike forslag vil også være en viktig del av den læring som bør foregå i hele organisasjonen. Eksempel på et langsiktig forbedringstiltak kan være Justering av utviklingsprosessen. Dersom vi ser at de feilene i systemet som koster mest er logiske feil introdusert i designfasen, må vi finne tiltak for å endre akkurat dette. Tiltakene kan f. eks. være flere inspeksjoner i designfasen eller opplæring innenfor applikasjonsområdet.
2SSVXPPHULQJ Tabellen nedenfor gir en kort oppsummering over hva hver enkelt plotteteknikk kan brukes til. Diagramtype Anvendelse Spredningsdiagram Trendanalyse Vise spredning i dataene (mønstre) Vise sammenhengen mellom to metrikker Luke ut atypiske verdier ( outliers ) Tidsdiagram Trendanalyse trender over tid Vise sammenhengen over tid for flere metrikker Kiviatdiagram Vise flere egenskaper relativt til en optimale verdier for å vise hvor godt et objekt møte/oppfyller et sett med kriterier Stolpediagram Vise spredning i dataene (mønstre) Vise sammenhengen mellom metrikker eller datasett for metrikker Kakediagram Vise spredning i dataene (mønstre) Kontrolldiagram Identifisere outliers atypiske verdier Trendanalyse Kontrollere at variasjon i dataverdier holder seg innenfor naturlige grenser Box-diagram Identifisere outliers atypiske verdier Sammenligne flere datasett Sjekke at dataverdiene holder seg innenfor gitte grenser Sjekke effekten av endringer i produkt eller prosess 7DEHOO2YHUVLNWRYHUSORWWHWHNQLNNHU Ideen bak feedback-sesjoner er at det er prosjektdeltakerne som er eksperter på prosessen og som derfor er de rette til å tolke dataene som blir samlet inn. Ved å supplere de innsamlede dataene med subjektive data fra prosjektdeltakerne, kan vi også få mer informasjon ut av færre data. For å gjøre dataene lett tilgjengelig for prosjektdeltakerne blir de presentert på grafisk form. For ikke å legge for mye av vår egen tolkning inn i dataene bør de presenteres slik de ble samlet inn uten forutgående analyse. Det som er viktig å få fram i en feedback-sesjoner er Prosjektdeltakernes tolkning av dataene Svar på og tolkning av spørsmålene i GQM-treet Forslag til endringer i GQM- treet Ideer til forbedring i dette prosjektet. kortsiktige og langsiktige