Kvalitetssäkring

=**Kvalitetssäkring**=

Den här uppgiften har vi strukturerat så att vi först har listat alla mål som angavs i uppgiftstexten, sedan har vi fyllt in frågorna som skall peka mot målet med fyllda punkter framför och till slut har mätdatat som skall ge svar på frågorna placerats under frågorna samt markerats med icke-fyllda punkter. I slutet har vi sammanställt alla mätdata som behövs i uppgiften och grupperat in dem för att göra det hela lite lättare att få en överblick av. Uppgifterna är numrerade enligt uppgiftstexten.

( Uppställning: ) Mål o Mätdata
 * · Frågor

1) Produkten skall levereras i tid o Tidsestimering  o Personliga erfarenheter  o Tidsestimering  o Enkät om hur stressigt projektet är bland gruppmedlemmarna  o Andelen sprinter som är färdiga/ ännu ogjorda  o Antalet funktioner som är färdiga / totala antalet funktioner  o Projektchefens subjektiva bedömning
 * · Hur lång tid tar det att leverera
 * · Hur mycket marginal har vi i tid?
 * · Hur stor del av programmet som är färdigt?

2) Produkten skall levereras med god kvalitet, med få buggar o Andel av tiden som utgörs av parprogrammering  o Antalet parallella delprojekt som utförs samtidigt  o Antal personer per delprojekt  o Testintervall  o Tidsuppföljning  o Testtid/programmeringstid  o Antal personer som arbetar  o Antal testare mot antal programmerare  o Antal testare som också är programmerare  o Antal buggar för tillfället per 1000 rader kod  o Antalet kritiska buggar i systemet  o Antal fungerande funktioner
 * · Hurudana processer har vi i projektet?
 * · Hur pass regelbundet körs tester i programmeringen?
 * · Hur mycket tid används till testning?
 * · Hur arbetar man inom gruppen?
 * · Hur bra är kvaliteten?

3) Koden bör vara väldokumenterad, bör underlätta underhåll o Antalet parallella delprojekt som utförs samtidigt  o Antal personer per delprojekt  o Subjektiv bedömning av programkodens dokumentation  o Tidsuppföljning  o Enkät bland programmerarna  o Subjektiv uppskattning av programmet  o Kravspecifikation  o Designspecifikation  o Antal rader dokumentation i projektet  o Antal rader dokumentation per del  o Subjektiv uppskattning av dokumentationen
 * · Hur många arbetar med projektet?
 * · När sker dokumenteringen?
 * · Hur mycket dokumentation behövs?
 * · Hur mycket dokumentation finns?
 * · Hur relevant är dokumentationen?

4) Koden bör vara välskrivenså att underhåll förenklas

o Antal personer per grupp som arbetar med projektet o Antal parallella programmeringsgrupper o Antal kodrader dokumentation / programkod o Enkät bland programmerarna o Subjektiv bedömning av projektchefen o Enkät bland programmerarna o Stickprov från olika funktioner och subjektiv bedömning
 * · Hurudana processer har man?
 * · Hur mycket dokumentation finns inne i koden?
 * · Hur standardiserad är programkoden?
 * · Hur enhetligt är programmet skrivet?

5) Effektiviteten för utvecklarna bör öka o Antalet färdiga cykler /sprint  o Antalet buggar /sprint  o Enkät bland de anställda  o Enkät bland de anställda  o Subjektiv uppskattning av projektchefen
 * · Hur effektiva är programmerarna?
 * · Hur bra trivs programmerarna med sina arbeten?
 * · Hur bra är motivationen i projektgruppen?

6) De flesta av våra mätdata i denna uppgift är interna mätdata, som mestadels kommer att vara ostandardiserade dokument för jämförelse inom projektgruppen. Det finns dock vissa dokument som kommer att användas som mätdata som kan anses vara externa mätdata och det är i den tredje uppgiften där vi tänkte använda oss av kravspecifikationen och designspecifikationen för att få reda på hur mycket dokumentation som behövs i projektet.

I frågan om produktdata eller processdata så använder vi oss av båda delarna, men försöker i mån av möjlighet använda oss av produktdata. Processdata är mer svårbestämt eftersom detaljerna kring arbetsmetoderna i projektet är odefinierade och det finns inte i samma utsträckning objektiva data klara data att utgå ifrån. Å andra sidan så kan också produktdata vara subjektiva ifall de anställda är medvetna om på vilket sätt kvaliteten på produkten mäts, så egentligen borde projektgruppen inte delges information om vilka mätdata som samlas in. Dock kan det leda till misstro i gruppen om det kommer fram att man granskar dem på ett sätt de inte vet om, så här har vi också en balansgång för att hitta en fungerande lösning.

7) Mätdata i hela kvalitetssäkringssystemet:

o Tidsestimering o Tidsuppföljning o Personliga erfarenheter av tidsestimeringen

o Andelen sprinter som är färdiga/ ännu ogjorda o Antalet funktioner som är färdiga / totala antalet funktioner o Antal fungerande funktioner o Antalet färdiga cykler /sprint o Antalet buggar /sprint o Antal buggar för tillfället per 1000 rader kod o Antalet kritiska buggar i systemet

o Antal rader dokumentation i projektet o Antal rader dokumentation per del o Antal kodrader dokumentation / programkod o Stickprov från olika funktioner och subjektiv bedömning av dokumentationen o Subjektiv bedömning av programkodens dokumentation

o Testintervall o Testtid/programmeringstid o Antal personer som arbetar på projektet o Antal testare mot antal programmerare o Antal testare som också är programmerare o Antal personer per delprojekt o Antal parallella programmeringsgrupper o Andel av tiden som utgörs av parprogrammering o Subjektiv bedömning av projektchefen

o Enkät bland programmerarna o Kravspecifikation o Designspecifikation

Som här synes har vi ett relativt stort antal olika mätdata, men de flesta av dem borde vara relativt enkla att samla in och analysera. Den troligen mest arbetskrävande delen, som även kräver alla gruppmedlemmars uppmärksamhet, kommer i det här fallet att vara den planerade enkäten. Den kommer att ta relativt mycket tid i anspråk början av projektet, men vartefter kommer medlemmarna att bli effektivare att svara på den och alla frågor behöver inte efter början ingå i enkäten varje gång. Dock borde man ändå regelbundet samla in tillräckligt med information för att kunna identifiera projektets läge och riktning. I slutet av projektet är det möjligt att en ännu mer omfattande enkät än den första enkäten vore på sin plats för att utvärdera projektet och samla in data för att stöda framtida förändringar av företagets processer och produkter.

En annan eventuellt problematisk sak är tidsuppföljningen, vilken kan vara krävande att implementera smidigt i ett litet projekt som TopBike. Oberoende av vilket verktyg som används för tidsuppföljning så kan man inte perfekt övervaka hur folk arbetar. Alltför noggrann tidsuppföljning kan också leda till att programmerarna i gruppen känner sig hotade och mister sin motivation att arbeta effektivt på grund av ”storebror ser dig”- känsla.

Buginsamling kan också vara problematisk, eftersom gruppmedlemmar relativt enkelt kan skapa missvisande data genom att låta bli att rapportera buggar, men å andra sidan kan man inte heller belöna uppsökning av buggar då detta kan leda till att programmerarna med vilje skapar buggar som de senare löser enkelt och på så vis förbättrar sina mätdata. Också vårt förslag att mäta antalet rader dokumentation kan leda till att programmerare skriver onödigt långa och omständiga kommentarer i programmet, som då samtidigt innebär att den effektiva programmeringstiden minskar och tiden satt på kommentarer ökar, medan koden i värsta fall till och med kan bli svårare att förstå.