OnTime nr 1 2003 - Combitech.se

More documents

Recommendations

Info

STRATEGIER FÖR EFFEKTIV TEST mätningar, det vill säga de subjektiva mätningarna eller uppfattningarna. Dessa kan tillföra olika aspekter, klargöra oklarheter och besvara frågor angående vissa omständigheter. Problemet är att det tar en hel del tid att samla in denna information och syftet med våra prediktions- och evolutionsmodeller är inte att skapa denna djupa inblick. Modellbygge Baserat på insamlad information kan vi bygga modeller för att analysera data, med syfte att förbättra och kontrollera våra processer. En modell bygger på en teori (syftet) som beskriver bakgrunden och det förväntade resultatet. Viktigt att veta är att modeller av sin natur är instabila. När en organisation blir medveten om ett fenomen förändras ofta beteendet, och därmed förutsättningarna för modellen. Därför är det viktigt att kontinuerligt uppdatera sina modeller. Byggstenarna i själva modellen är ett antal statistiska metoder av olika avancerad karaktär, beroende på vad man vill uppnå. Dessa metoder kan i sin tur kombineras på olika sätt, ungefär som man kombinerar olika mått, för att uppnå önskat resultat. Inom de statistiska modellernas ramar finns det även utrymme för justering och anpassning på ett antal punkter. Detta ligger dock utanför ramarna för denna artikel. Modellexempel Vi ska visa hur man kan bygga en modell för prediktion av felintensiva komponenter som sedan kan utökas och användas för att följa evolutionen hos dessa. Vi visar även hur man kan undersöka strukturella förändringar hos komponenterna i det berörda systemet för att få indikationer på vad som orsakar problemen. Prediktion och evolution De två modellerna har sitt upphov i att skapa ett gemensamt språk för kvalitetsfolk, utvecklare och chefer för att kunna fatta gemensamma beslut som alla förstår innebörden av. Modellerna bygger på teorin om att det till Felintensitet * Figur 1.Trenden för en komponent över ett antal releaser. största delen är samma komponenter som uppvisar flest fel i varje release. Man kan dela in dem i tre kategorier beroende på hur felintensiva eller degenererade de är: • Gröna (normal evolution) Dessa representerar normal evolution och en viss fluktuation är normal. Komponenterna är enkla att uppdatera, dvs funktionaliteten kan utökas och fel kan rättas utan att man behöver spendera allt för mycket tid. Dessutom behövs inte systemexperter för att underhålla dessa komponenter. Man ska följa upp komponenterna från release till release för att kunna hitta illavarslande trender och ifall någon komponent överstiger en viss felnivå, (den undre nivån i figur 1), ska man hantera problemet innan den klassificeras som gul. • Gula (kod-degenerering) När en komponent passerar den undre nivån klassificeras den som gul och behöver speciellt fokus för att framtida problem ska undvikas. Komponenter som klassificerats gula är kandidater för specifikt riktade förbättringsinsatser. Detta kan innebära en mer rigid process, där fokus ligger på till exempel granskningar. Komponenten kan även vara kandidat för re-engineering. Ifall man inte reagerar och hanterar de gula komponenterna finns risk för att de passerar den övre felnivån och klassificeras som röda. • Röda (”mission impossible”) En röd komponent är problematisk och kostsam att underhålla. Röda komponenter har en tendens att ställa till stora problem i slutet av projekten, när det dessutom finns lite tid och pengar kvar att spendera. De ses oftast vara i allt för dåligt skick, dvs ”mission impossible”. För att hantera dessa komponenter behöver vi människor med expertkunskap. Dessa komponenter är inte längre kandidater för re-engineering, de måste göras om. De olika kategorierna finns exemplifierade i Figur 1. Exemplet visar utvecklingen för en specifik komponent över ett antal releaser. De data vi använder oss av i exemplen kommer från 28 mjukvarukomponenter som är från två releaser. Dessa utgör en del av ett stort realtidssystem inom telekommunikationsområdet. Programspråket är ett företagsinternt språk som är en föregångare till SDL. För komponenterna samlades tio olika mått 20 Nr 1 mars 2003 Combitech Systems AB * * * * * * * Röd Gul Grön Övre nivå Undre nivå Release
in, samt antalet fel som rapporterats i varje release under systemtest. Prediktion För prediktionsmodellen har vi ett kortsiktigt perspektiv, det vill säga att kunna prediktera vilka komponenter som kommer att orsaka problem i testfasen eller nästa release. Vi vill få upp synligheten på de problematiska komponenterna. Hypotesen är att det oftast är samma komponenter som återfinns bland de mest felintensiva. Vi nyttjar därför data från test i den ena releasen för att prediktera vilka komponenter som kommer att uppvisa många fel i nästa release-test (se figur 2). Resultatet från prediktionen kan nyttjas för att lägga mer resurser på test (eller granskningar) av vissa komponenter. Angreppssättet för prediktionen är att vi rangordnar komponenterna efter hur många fel de uppvisade i systemtest. Anledningen till att inte använda det exakta antalet fel för varje komponent är att vi kan reducera skill- Nr 1 mars 2003 Combitech Systems AB STRATEGIER FÖR EFFEKTIV TEST naderna som kan finnas mel- Release n Release n+1 lan olika releaser med avseende på totala antalet fel som har rapporterats. Design Design Användningen av rangordning innebär också att vi inte Kodning Data n Kodning Data n+1 behöver använda avancerade statistikverktyg. Test Test I det här fallet gjordes rangordningen med hjälp av Figur 2. Flöde över insamling av data, samt användandet. en funktion i Excel. Om vi till exempel har tio eller välja ut ett specifikt antal komponenter, komponenter får den komponent med flest till exempel de 25 procent mest felintensiva. I fel värdet 10 och den med minst antal fel 1. I det här fallet väljer vi det senare, det vill säga fallet då flera komponenter har samma antal vi väljer ut de sju komponenterna med högst fel tilldelas de samma värde, medan nästa rangordning (gulmarkerade i tabell 1). Ett komponents värde förskjuts med samma problem är att det finns ett antal komponen- antal steg. Det innebär att om två komponenter med rangordningsvärdet 19 i första releater inte har några fel alls och får rangordsen. Vi valde ut en av dessa slumpmässigt ningsvärdet 1, får den komponent som har ett eftersom detta är ett exempel. Vi var även fel värdet 3 (istället för 2). tvungna att göra detta i den andra releasen. I Rangordningen ger oss möjlighet att ett annat fall hade man varit tvungen fundera antingen peka ut felintensiva komponenter lite mer. Resultatet för de två releaserna som har högre rangordning än ett visst värde, redovisas i tabell 1 och 2. Komponent A B C D E F G H I J K L M N Defekter 0 0 0 0 0 0 1 2 2 2 3 4 4 5 Rangordning 1 1 1 1 1 1 7 8 8 8 11 12 12 14 Komponent O P Q R S T U V W X Y Z AA AB Defekter 7 7 7 8 9 9 9 9 10 11 15 20 22 32 Rangordning 15 15 15 18 19 19 19 19 23 24 25 26 27 28 Tabell 1. Defekter i release n. Komponent A B C D E F G H I J K L M N Defekter 8 18 0 0 3 4 7 3 8 0 9 2 12 14 Rangordning 15 25 1 1 9 11 14 9 15 1 17 8 21 23 Komponent O P Q R S T U V W X Y Z AA AB Defekter 0 0 10 11 1 0 22 30 23 11 15 6 5 12 Rangordning 1 1 18 19 7 1 26 28 27 19 24 13 12 21 Tabell 2. Defekter i release n+1. 21
Page 1 and 2: nTimeGER INSIKT I TID Vad är test
Page 3 and 4: Effektiv test - en fråga om överl
Page 5 and 6: 4. Om en mycket ljus bild visas fö
Page 7 and 8: trollers och andra inbyggda system)
Page 9 and 10: • Gör ett urval av vägar som sa
Page 11 and 12: • Har jag tänkt igenom de sätt
Page 13 and 14: Test av felhantering i distribuerad
Page 15 and 16: Miljölagar driver på testutveckli
Page 17 and 18: När fel inte får förekomma För
Page 19: Kom igång med prediktions- och evo
Page 23 and 24: Mått Beskrivning SDL-pages Antalet
Page 25 and 26: den behöver man inte testa, därf
Page 27 and 28: Kursschema VÅREN 2003 STRATEGIER F

OnTime nr 1 2003 - Combitech.se

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?