OnTime nr 1 2003 - Combitech.se

More documents

Recommendations

Info

STRATEGIER FÖR EFFEKTIV TEST Gambros AK 200 ULTRA S, framtagen och tillverkad på Gambro i Lund. ytterligare trovärdighet. Att samarbeta med externa parter som är väl kända och erkända för sin verksamhet kan också ge ett mervärde till produkten när den ska marknadsföras. Formellt överlämningsmöte När utvecklingsprocessen har nått så långt att produkten existerar som ett system och tillverkningsprocessen är validerad, inleds produktvalideringen med ett formellt överlämningsmöte mellan utvecklingsavdelningen och DQ. – Valideringen är den stora biten för oss på DQ. Det är då vi bland annat testar produkten mot krav baserade på avsedd användning och användarnas behov. På överlämningsmötet går vi igenom en checklista för att kontrollera att alla tester och verifieringar är utförda enligt vår utvecklingsprocess. På så vis försöker vi minimera risken att identifiera fel under produktvalideringen eftersom de problem som vi hittar i den fasen ofta är dyra att åtgärda. Som en del i valideringen säkerställs också att alla tester och verifieringar är utförda enligt Gambros utvecklingsprocess och med godkänt resultat. Valideringen utförs på systemnivå, varför testerna oftast är så kallade black-box-tester; produkten betraktas inte som en uppsättning delsystem, utan testerna är inriktade på hur produkten ska fungera när den används av kunderna. Som en del av valideringen utförs bland annat ett stort antal simulerade behandlingar. Valideringen sker alltid på serietillverkade produkter eller ekvivalenta. Slutligen CE-märks produkterna. Serviceteknikerna involveras Att testa nya produkter är inte hela arbetet för DQ. Varje år inkommer mellan 500 och 600 ändringsmeddelanden på existerande produkter. Det som föranleder förändringar kan vara förslag från produktionsavdelningen, önskemål om nya funktioner från marknadsavdelningen eller klagomål från kunder. Samtliga förändringar i dialysapparaterna ska testas och godkännas. – När en förändring ska genomföras är det första steget att genomföra en problemanalys. Ofta är det svårt att utifrån rapporten veta exakt vad i maskinen som ska ändras. Det första steget är alltså att ta reda på vilket problem som ska lösas. Processen som används vid ändringar bygger i stort sett på samma principer som den som används för nyutveckling. Problemställningen leder fram till en System Change Request, CR, det vill säga en kravspecifikation som granskas och godkänns av DQ. Efter implementering testas ändringen för att säkerställa att den uppfyller kraven i CR och att den inte lett till oönskade sidoeffekter på övriga delar av systemet. Dessa tester granskas och godkänns också av DQ. I vissa fall utnyttjas även tekniker från säljbolagen i olika länder för att på ett tidigt stadium testa införda ändringar. På så sätt tas erfarenheter till vara från dem inom Gambro som arbetar närmast slutkunden. Som sista steg utför sedan DQ valideringen. – Att serviceteknikerna är involverade under testningen är av stort värde. Dels har de med sin erfarenhet mycket att tillföra och dels kan de bekräfta att vi förstått det aktuella problemet och rättat till det. Effektivare test Arbetet med att testa och validera dialysutrustning måste alltid ske inom ramarna för de strikta regelverken för medicinteknisk utrustning. Men även inom dessa ramar går det att effektivisera testerna. – Det är viktigt att DQ inte uppfattas som den sista barriären, säger Magnus Grén och menar att DQ:s roll aldrig får bli polisiär. – Det arbetssättet är inte effektivt och kan aldrig accepteras. Det måste finnas en samsyn mellan utvecklingsingenjörerna och kvalitetsingenjörerna om vikten av tillräcklig testning, eller rättare sagt verifiering och validering. Den samsynen tycker jag finns här på Gambro och det ger styrka åt hela processen Istället vill Magnus Grén att DQ ska komma in så tidigt som möjligt i utvecklingsprocessen, för att se till att granska krav, testmetoder och testresultat. – Ett sådant arbetssätt säkerställer produktkvaliteten på ett effektivt sätt. Dessutom kostar det betydligt mindre än om vi istället kommer med kommentarer eller identifierar fel i slutet av processen och därmed tvingas göra om mycket av arbetet. Ju närmare vi är deadline, desto svårare är det naturligtvis att vinna gehör för de här tankarna. Samtidigt inser alla att det finns potential att göra utvecklingen snabbare, billigare och med bättre kvalitet om det här perspektivet följs från början. ■ 18 Nr 1 mars 2003 Combitech Systems AB
Kom igång med prediktions- och evolutionsmodeller Det behöver inte vara svårt att komma igång med prediktions- och evolutionsmodeller. Med ganska enkla medel kan man uppnå användbara resultat. Men det gäller att i förväg tänka igenom vad man vill uppnå. Största delen av dagens mjukvaruprojekt är i huvudsak vidareutveckling av befintlig mjukvara, där man utökar funktionaliteten eller uppdaterar den mot nya standarder. Många projekt utvecklas inkrementellt, vilket också kan ses som en form av vidareutveckling. Skillnaden mot att nyutveckla ligger i att strukturer och beroenden till viss del finns på plats och man måste anpassa sig och bygga efter dessa. Detta resulterar i att man hela tiden får med sig ett “arv” från de äldre delarna, med allt vad detta innebär. Förutsättningarna för vidareutvecklingen bestäms redan på ett tidigt stadium i projektet. Även om man utvecklar inkrementellt är det lätt att glömma och hålla all väsentlig information i huvudet. Bra dokumentation av systemet och dess arkitektur underlättar därför. Tyvärr är inte dokumentationsnivån den önskvärda i alla projekt. Många organisationer hamnar därför i en situation där man efterhand som man bygger vidare på systemet spenderar mer och mer tid på att rätta fel som uppkommer. Situationen kan även vara den att man släpper nya versioner av mjukvaran efterhand som man rättar problem man har funnit. I slutänden är det oftast bara ett fåtal fel kvar, men dessa är oftast väldigt svåra att handskas med på grund av olika anledningar. Oftast är det bara en delmängd av komponenterna som skapar de största problemen, och man har en känsla för vilka de är. Det är lätt att bli förblindad av dessa och förbise komponenter som inte utmärker sig men som ändå kan vara problematiska. Prediktion och evolution Hur ska man då hantera dessa komponenter och hur kan man på ett tidigt stadium agera för att undvika problem längre fram i utveck- Nr 1 mars 2003 Combitech Systems AB lingen? Att arbeta preventivt kan låta självklart, men är inte alltid enkelt om man inte vet var man ska börja. Om man redan har hamnat i en nedåtgående spiral av ständiga rättningar och uppdateringar kan man behöva hjälp. Ett hjälpmedel för att fokusera sina resurser (till exempel granskningar och test) på de mest problematiska komponenterna är prediktionsmodeller. Dessa kan användas i förebyggande syfte för att tidigt peka ut komponenter som är på väg att bli problematiska. Beroende på hur de appliceras, och med vilka förutsättningar, kan de användas i både kortoch långsiktigt syfte. När man arbetar med prediktionsmodeller finns det två avvägningar man måste ta hänsyn till, förhållandet mellan hur lättanvänd och hanterbar den ska vara kontra hur exakt prediktionen ska bli. Man måste även ha en bra uppfattning om vad syftet med modellen är för att den ska bli ändamålsenlig. Datainsamling Grunden för att bygga modeller är tillgången till data från mjukvaran och processen samt om resurserna. Många organisationer ställs ofta inför dilemmat att inte ha en såpass utvecklad process att data samlas in kontinuerligt. Detta behöver inte hindra byggandet och användandet, då man oftast med en relativt enkel insats kan samla in nödvändig information. Det är ett av de ställningstaganden man måste göra när det gäller avvägningen mellan användbarhet och prediktionsprecision. Oftast finns möjlighet att på ett smidigt sätt inhämta data från befintliga verktyg och processer. Man kan till exempel från versionshanteringsverktygen extrahera information om komponenterna som ingår i systemet, hur ofta det har gjorts ändringar i dem och vilka ändringar som har gjorts. Vidare kan man nyttja informationen i tidrapporteringssystemen för att se hur mycket tid som har använts till olika aktiviteter. Ett fel man bör undvika för att ge en rättvisande prediktion är att samla in data från de sena processfaserna. Till exempel bör man AV MAGNUS OHLSSON inte samla in information om hur mycket tid man har lagt på att testa olika komponenter, för att prediktera hur felintensiva de är. Det är dock rimligt att göra detta om man vill arbeta med evolution eller prediktion för nästa release. Istället bör man fokusera på att använda sig av data från till exempel designfasen. Man måste ha klart för sig vad syftet med modellen är och vilken information som är relevant att samla in. När det gäller prediktions- och evolutionsmodeller finns ett antal måttyper som man bör fokusera på: • Storleksmått Till exempel rader kod eller antalet if-satser. Antalet if-satser (och även vissa andra mått) kan ses som ett storleksmått eftersom antalet bidrar till storleken. En annan möjlighet är att använda dem som strukturmått. • Strukturmått Cyklomatisk komplexitet, mängden modifierad kod och interface-karakteristika är exempel på strukturmått. Mängden modifierad kod kan ses som ett strukturmått med avseende på att det indikerar mängden strukturella förändringar i koden. • Processmått Till exempel frekvensen för vissa aktiviteter i olika utvecklingsfaser, eller tiden att utföra vissa förändringar. • Feldata Klassificering av olika fel och antalet fel funna i olika faser är exempel på olika typer av feldata. Alla dessa mått kan dessutom kombineras för att få fram andra intressanta, så kallade indirekta, mått. Det är till exempel möjligt att kombinera antalet funna fel med antalet rader kod för att räkna ut feldensiteten. Detta mått kan i sin tur sedan kombineras med mängden modifierad kod i olika komponenter för att ta reda på hur förändringarna påverkar feldensiteten. En sak som har utelämnats är kvalitativa 19
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: När fel inte får förekomma För
Page 21 and 22: in, samt antalet fel som rapportera
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

Create successful ePaper yourself

Delete template?

Save as template?