Föreläsning 4. Programvaruutveckling för Stora System. Det var en gång en nallebjörn... Felkostnader. Christin Lindholm.

Relevanta dokument
Vad ska ni göra? Programvaruutveckling för Stora System. Felkostnader. Föreläsning 4. Christin Lindholm. Granskningar. Test, Konfigurationshantering

Föreläsning 4. Programvaruutveckling för Stora System

Programvaruutveckling för Stora System. Projekthandledning

Föreläsning 3. Programvaruutveckling för Stora System. Målsättning i programvaruprojekt. Fel och risker. Christin Lindholm

Föreläsning 3. Programvaruutveckling för Stora System. Målsättning i programvaruprojekt. Veckan. Christin Lindholm.

Christin Lindholm. Programvaruutveckling av Stora System, PUSS ETS032. Välkomna! Vad är ett projekt?

Föreläsning 3 Verifiering och Validering

Christin Lindholm. Programvaruutveckling av Stora Projekt, PUSP ETSF20. Välkomna! Vad händer idag?

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Christin Lindholm. Programvaruutveckling av Stora Projekt, PUSP ETSF20. Välkomna! Vad händer idag?

Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Några grundläggande begrepp

Föreläsning 3 Verifiering och Validering

Är instruktionerna oklara, projektet rörigt och allmänt frustrerande?

Programvaruutveckling - Metodik 2016 Jonas Wisbrant

Vad är RTCA DO-178C? och: Hur arbetar Saab med dessa krav? Lars Ljungberg, Saab AB, Avionics Systems

Detta har hänt... Kursinformation. Utse kursombud - nytt försök. Föreläsning 3: Test, Konfigurationer. Pratat och skapat krav och plan

CM FORUM. Introduktion till. Configuration Management (CM) / Konfigurationsledning. Tobias Ljungkvist

Agenda. Föreläsning 6: Utvärdering och om tentamen. Kursinformation

Agenda. Kursinformation. Manual för systemstart... Föreläsning 6: Utvärdering och om tentamen

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Verifikation, validering och testning

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? Robert Bornelind

Föreläsning 4: Konfigurationer, Plattformar & Design I Programvaruutveckling - Metodik 2016 Jonas Wisbrant

Agenda. Projektbeskrivning avsnitt 8: Acceptanstest - MS4 i korthet. Kursinformation

INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT

Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Filip Strömbäck. Verifikation, validering och testning

Kursprogram, ETSF20 Programvaruutveckling för stora projekt (PUSP), 7,5 hp

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod

Hemtentamen: ETSA01 Ingenjörsprocessen för programvaruutveckling metodik

Platina och kvalité. Rasmus Staberg, Teknisk direktör,

INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT. Övning 2 Riskhantering, intressenter och kravgranskning.

Föreläsning 3: Test, Konfigurationer. Övning 2 Riskhantering, intressenter och kravgranskning.

Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning

Steget efter CAD Data Management. Per Ekholm

Övningstenta (Kursplan 2011) Ver 2015,

Kursprogram: ETSN05 Programvaruutveckling för stora system, 2014 (7,5 hp)

Detta har hänt... Jonas Wisbrant - kort CV. Kursombud - nytt försök. Föreläsning 3: Test, Konfigurationer. Pratat och skapat krav och plan

Kurser och seminarier från AddQ Consulting

Dokumenthantering. Tieto PPS AH016, 5.1.0, Sida 1

Sammanfattningar Essentials of Software Engineering

Regressionstestning teori och praktik

Ramverk för projekt och uppdrag

Processbeskrivning Test

Föreläsning 6. Utvärdering, om tenta, avrundning

Föreläsning 6. Utvärdering, om tenta, avrundning. Agenda. Kursinformation. Schemalagda kursmoment. Jonas Wisbrant. Kursinformation

Testplanering, test-first, testverktyg

Detta har hänt... Föreläsning 2: Projektplanering & granskning. Pratat och provat kravhantering. Bildat projektgrupper :-) Skaffat litteratur?

Kursöversikt Certifierad Mjukvarutestare

REGELVERK & HANDBÖCKER

Teststrategier och Testcertifiering. Per Strandberg, Maj 2013

Exercise 4a: Test 2 ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15. Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT15 Exercise 1

LIPS 1, 2002 Lätt Interaktiv Projektstyrningsmodell

Programvara i säkerhetskritiska tillämpningar

Projekthandledning (PH) Grundsystemet (GS) Utvecklingsmiljön (UM)

STUM. Övergripande Testplan. Sammanfattning. Redaktör: Thomas Janowski Version: Syntetiskt tal utan modulering

Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer

Exempel på verklig projektplan

Kursprogram, ETS032 Programvaruutveckling för stora system (PUSS), 7,5 hp

ISTQB Testarens ledstjärna

Specifikationer i kompendiet Övningar på moodle.cs.lth.se Support Onsdag kl i E: (84?) Frågestund: F3

Idag. EDAA35: Utvärdering av programvarusystem. Mål. Innehåll. Kursmoment. Lärare

INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT

Exercise 1b: Requirements evaluation

Agenda. Kursinformation. Manual för systemstart. Föreläsning 6: Summering och om tentamen. Målgrupp:

Agil testning i SCRUM

Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) Europa-projektet. Dokumenthistorik

Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning

Exercise 1b: Requirements evaluation

Certifierad testare SSTB Ingvar Nordström

Test av livsuppehållande system på Maquet Critical Care

F4 Testning och Parprogrammering i XP EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH

Säkerhetsstandarder: Säkerhetsinriktning

Verifiering & validering -

Detta har hänt... Agenda. Kursinformation. Kursinformation

Metoder och verktyg för funktionssäkerhet

Symptom på problemen vid programvaruutveckling

Alla rättigheter till materialet reserverade Easec

Exercise 1b: Requirements Evaluation ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15

Agenda. Föreläsning 6: Summering och om tentamen Kursinformation

Detta har hänt... Kursinformation. Agenda. Kursinformation

Testning som beslutsstöd

Konstruktion av datorspråk

ALM Live. April 2008 Effektivare projektarbete med Visual Studio 2008

Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning

PL_Rutin_Ändringshantering Version 0.2. Ladok3-projektet Lars Jackalin Sida: 1 (8) Ändringshantering

Kravspecifikation för hårdvaruprojekt i kursen Datorsystemteknik, HT2005. Temperaturvakt med loggningsfunktion

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget % misslyckades!

Vad händer med L3: ΔL3-L4 för Krav följs upp av annan projektgrupp. Föreläsning 5: V&V II + Design II Efterläsning Kodning

Föreläsning 4 Arkitektur, design, kodning

RUP - Rational Unified Process

Var är vi? Föreläsning 4 Arkitektur, design, kodning. Agenda. Kursinformation. Produktlinjer. Konfigurationshantering - forts. Detta har hänt...

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design

Föreläsning 4 Arkitektur, design, kodning

Transkript:

Föreläsning 4 Programvaruutveckling för Stora System Granskningar Test, Konfigurationshantering Christin Lindholm 2 Felkostnader Det var en gång en nallebjörn... [Alan Davies, 1992] 3 4

Det var en gång en nallebjörn som trivdes bra med sitt liv tillsammans med pojken som han var nallebjörn åt. Det vill säga, sånär som på en sak: han tyckte inte om när pojken bar honom uppför trappan till sovrummet när de skulle gå och lägga sig. Pojken brukade hålla i nallens ena fot medan han bar honom. I den ställningen kom nallens huvud att hänga ner och slå mot trappstegen - duns, duns, duns, duns, duns...nallen undrade ofta om detta var det enda sättet att bära en björn upp för en trappa. Ibland kände han på sig att det måste finnas ett annat, bättre sätt. Det var bara det att han aldrig kom ihåg att han skulle tänka ut ett bättre sätt, förrän han hängde där med huvudet nedåt igen och det började dunsa; och så länge det dunsade var det svårt att tänka överhuvudtaget, och när det slutat dunsa var ju nallen redan uppe i sovrummet och då fick han annat att tänka på och glömde återigen bort vad det var han skulle komma på ett bättre sätt att göra. Därför blev det hellre aldrig annorlunda Likadant är det med många av dem som utvecklar produkter och tjänster åt industrin. De vet att de inte räcker till för att möta den ständiga efterfrågan på nya produkter och tjänster eller ändra och rätta de gamla och just därför har de inte tid att analysera orsakerna ordentligt. Man slår sitt huvud mot trappstegen. Medan trapporna blir högre och högre. Duns, duns, duns, duns,duns,duns... Granskningar Grundläggande tanken enkel: läs granskningsobjektet systematiskt Dvs en manuell teknik med målen att: Hitta fel Sprida kunskap Få beslutsunderlag Dessa mål kan vara olika mycket betonade i olika granskningsformer. 5 6 Granskningar Viktig teknik för att hitta fel tidigt, istället för att spara dem till testfasen. kan användas i alla steg i utvecklingen, kan ligga till grund för formulering av ingångs- och utgångskriterier ( entry and exit criteria ), kan utgöra värdefulla kontrollpunkter i utvecklingen, ger oss en chans att kvantifiera kvaliteten. Om granskningar Olika undersökningar har visat på vinsten med granskningar. Omarbete efter granskning måste läggas in i tidplaner. Positiva bieffekter: spridning av kunskap, gruppkänsla och gemensamt ansvar. En granskning är ingen rättegång! Skilj på sak och person! 7 8

Granskningars egenskaper Granskningsprocess Effektiv, Ekonomisk, Formell. Granskningar är en process: det finns faser och roller i samband med en granskning. 9 Planering - rätt personer, lokal etc. Översikt - genomgång och distribution av material Förberedelser - stöds med checklistor från tidigare erfarenheter Granskningsmöte Sammanställa felen - inte lösa problemen på mötet. Granskningsprotokoll olika typer av fel granskningsbeslut (godkänd, godkänd efter ändringar, omgranskning) Omarbete - identifierade fel skall åtgärdas Uppföljning 10 Resultat av granskningsmötet Fyra resultat: Godkänt Godkänt med komplettering Omgranskning Mötet skjuts upp 11 Granskningsroller Koordinator - ordförande, medlare Sekreterare - skriver protokoll Författare - svarar på frågor Granskare - har före mötet granskat (del av) dokument Designer, Programmerare, Testare, Kund, Kvalitetsutvärderare, Underhållspersonal. 12

Checklistor Granskningstekniker Användningsfall Datainsamling datum för distribution av granskningsmaterialet förberedelsetid mötesdatum datum då omarbete avslutades första granskningen eller en omgranskning identitet på granskningsmaterialet (t.ex. dokumentnummer) storlek på granskningsmaterialet namn på deltagare antal granskare längd på mötet antal fel av olika typer och allvarlighetsgrad hittade beslut (godkänd, rättning eller omgranskning efter rättning) 13 Jämför Granskningsprotokoll & Problemrapporter 14 Användning av data Kortsikt: Processtyrning (jmf projektstyrning) exempel: estimering av kvarvarande fel Långsikt: Processförbättring Feltyper Feltyper för varje dokument (se PH:9.15): SRS SVVP & SVVR STLDD & SDDD Generella feltyper om ej ovanstående passar Feltyper vid dynamisk test Felgradering: A, B, C 15 Felklassificering är svårt - kom gärna med förslag på förbättringar. 16

Exempel på ingångskriteria för granskning ( entry criteria ) Tidigare dokument skall vara granskade, t.ex. design ska ej granskas förrän specifikationen är granskad. Eventuella standards har följts. Automatiska kontroller skall ha gjorts och vara godkända (t.ex. stavningskontroll) Erfarenheter Effektiviteten i granskningar kan mätas t.ex. m.h.a.: medelantalet nedlagda timmar per hittat fel antalet fel hittade per granskningsenhet (t.ex. per sida design) En del siffror: Effektivitet: granskning är 2-10 gånger mer effektivt än test. Granskning tar tid: 4-15% av ett projekts tid Kan vi motivera detta? Granskningar förbättrar kvaliteten. Granskningar förbättrar produktiviteten. Exempel: fel i drift $10.000, vilket kan bekosta många granskningstimmar. Kan granskningar ersätta test? 17 18 Granskningar i projektet Informella granskningar - kund ej representerad, görs före varje formell granskning. Formella granskningar: Software Specification Review SDP, SRS, SVVS Preliminary Design Review STLDD, SVVI, Monitorfiler (ej på papper) Product Review Acceptanstest Ju bättre informell granskning desto bättre formell granskning 19 20

Success factors Ägandeskap över processen Stöd av ledningen Träning Nackdel Kostar mycket initialt Slarv - slöseri med tid och pengar Dock blir ett dokuments kvalitet alltid lite bättre även vid dåligt genomförd granskning 21 22 Begrepp Test Validering Är det rätt system? Uppfyller vi kundens behov och förväntningar. Verifiering Är systemet rätt? Har vi gjort det vi sa vi skulle göra? Granskning Uppfyller ett objekt sin specifikation Testning Uppfyller ett exekverbart objekt sin specifikation. 23 Målet för test är att hitta fel i programvaran att åstadkomma förtroende för produkten inte att bevisa frånvaron av fel. En stor programvaruprodukt bör testas av konstruktörer och en oberoende testgrupp; Testgruppen skall vara oberoende från implementationen och utgå från kravspecifikationen. 24

Testmetoder (PH:7) Två utgångspunkter: Whitebox -> utgår från interna strukturen Blackbox -> utgår från externt observerbar funktionalitet Två angreppssätt Statiskt -> manuell granskning Dynamiskt-> exekvering av testfall Requirements Design Code 25 26 Olika testtekniker Decision/Branch coverage White-box Coverage Decision Statement Branch Ad Hoc Black-box Equivalence Partitioning Boundary Value Random Testing Error Guessing Ad Hoc McCabe cyclomatic The number of independent paths needed to cover all paths at least once in a program Count number of conditional expressions. If compound conditional expressions, add one per compound item. Visualize by drawing a flow graph Alternative way: CC = #(edges) - #(nodes) +1 while-loop if-then-else case-of 27 28

Equivalence partitioning Boundary value analysis Systematic way to choose test cases and data values Input or output data with common properties Choose one test case per partition A systematic way to choose test cases and data values Input or output data with common properties Choose one test case on each side of the boundary -1-10 0 99 50 100 125 Component -10-20 -9 499 50 500 525-1 -1 0 99 0 99 100 100 Component -10-10 -9 499-9 499 500 500 29 30 Modultest Funktionstest* Integrationstest Systemtest* Acceptanstest* Installationstest * i detta projekt Olika testnivåer Regressionstest Omtestning av tidigare testfall i samband med: felrättning ändringar tillägg till ett existerande system Regressionstest är tämligen enkelt: Man har redan testfallen Man har ett tidigare utfall, dvs stämmer det fortfarande? Hur mycket behöver vi regressionstesta? 31 32

Test i projektet Två dimensioner: 1. Enbart SDL-system Programvara på målmaskin 2. Funktionstest Systemtest Testprocess 1. Identifiera alla testfall -> testspecifikationer (SVVS). 2. Beskriv varje testfall, såväl funktionstest som systemtest, steg för steg i naturligt språk -> testinstruktion (SVVI). 3. Ta fram monitorfiler, dvs simulera kommunikationen med MD:n (se exempel monitorfil UM:3). 4. Testa och notera fel och rapportera 5. Regressionstesta och fortsätt testa med nya testfall 6. Funktionstest och systemtest felfria i utvecklingsmiljö, då flyttas programvaran till MD:n. 7. Genomför test på MD:n genom att använda telefonerna 8. När ni är nöjda: kontakta kunden för acceptanstest Varför behövs testspecifikationer? Testinstruktioner? 33 34 Testspecifikation Kort och kärnfull formulering Unik numrering Att tänka på Täcka alla (funktionella) krav Referens till krav Testinstruktion Systemläge vid start Systemläge vid slut Förväntat resultat self contained Konfigurationshantering (Configuration Management - CM) CM = kontrollerat sätt att hantera utveckling och förändring av sammansatta system under hela livscykel Varför behövs CM? Parallellisera arbetet Veta i varje läge av utvecklingen hur olika delar beror av varandra och vilka versioner som gäller Uppdateringsstrategi hur inför vi ändringar/ rättningar? 35 36

Olika aktiviteter i CM Identifiering av konfigurationsenheter Benämning av versioner Ändringshantering Statusrapportering Systembyggande sätta samman delar till en helhet Change Control Board (CCB) Förändringskontrollgruppen (FKG) Fattar beslut om ändringar Statusrapport anger historik för varje konfigurationsenhet Problemrapport en slags stafettpinne som dokumenterar besluten och åtgärderna för en specifik ändring/rättning Problemrapport Förändringskontrollgruppen (FKG =PG+SG) Problemrapport Ändringsansvarig 37 Statusrapport 38 Identifikation av konfigurationsenheter Att peka ut och namnge de olika enheter som ska ändringshanteras Regler för namngivning: MD0204xyy 02=år, 04=av projektgrupp, x=gruppnr, yy=löpnr Dokument, delar av dokument, systemdelar i arkitekturen, kod Vid inlämning till formell granskning 1 skall en lista på konfigurationsenheter skickas med Konfigurationsenhetslistan är en konfigurationsenhet!!! För varje konfigurationsenhet ska en statusrapport skapas Benämning av versioner Version x.y Vid uppdateringar ökas y med 1 Vid upprättande av baselines ökas x med 1 Första versionen: 0.1 0.9, 0.10, 0.11, Första baselinen: 1.0 Baseline till kund kallas Release (utgåva) 39 40

Exempel på arbete med SDDD Efter STLDD i baseline: Lägg in allt enligt STLDD i OA (Original area) OA=Grundsystemet+tomma processer+... (PH kap 4 sid 33) Uppdateras bara igen när allt är klart för leverans Lägg även i början in en kopia av OA i Transfer Transfer kommer sedan att byggas på med ändringar Transfer Check-out(X) Check-in(X) Working Area UGx Process X is locked SG har ansvaret att ingen ändring förstör för andra! SG har ansvar för grundsystemets processer. UG för resp. tjänst. 41 Dokument: SRS DEL A: Dokumentstatus Pr nr. Åtgärdas ja/nej Statusrapportering Ansvarig för åtgärd STATUSRAPPORT Dokumentansvarig: Kent Larsson Förändringskontrollansvarig: Lars Björklund Deadline datum Version Nr. efter ändring Godkänd datum Kommentar 0.1 Första version skapad 0.2 till. Inform.granskning 0.3 Till formell granskning PR4 ja MJ 990916 1.0 990917 Baseline PR8 ja MJ 990918 1.1 990918 Kravändring PR9 nej PP 990918 Nytt krav 42 Livscykeln för ett problem Upptäckt Utredd Förkastad Created Accepterad Investigation Rejected Åtgärdad Kontrollerad Införd Customer Fixing Fixed 43 Problemrapport Del A: Ursprung (Origin) Var blev det problem? Vad är problemet? Del B: Utredning & Beslut (Investigation) Ska problemet åtgärdas? Hur ska det åtgärdas? Vad påverkas? Hur lång tid uppskattas åtgärden ta? Del C: Åtgärd (Action) Åtgärdsansvarig? Hur lång tid tog åtgärden att göra? Del D: Uppföljning & avslut (Follow up and completion) Vem kontrollerade och godkände åtgärden? När blev det färdigt? 44

Att göra! Förbereda terminalövning (Design av Hotline) Åtgärda fel ni hittade vid informella granskningen Obligatorisk närvaro vid formella granskningar PG: Se till att allt är i ordning (inkl. mötesprotokoll etc.) PG: Se till att statusrapporter finns för SRS, SVVS, SDP 45 Mål Kunskap centrala begreppen kring storskalig utveckling av programvarusystem grundläggande principer kring utvecklingsprocessen styrprogramvaran för en enkel telefonväxel är uppbyggd Färdighet arbeta i ett stort programvaruprojekt strukturerad och väldokumenterad arbetsprocess grafiska programspråket SDL Attityd: förstå varför en process behövs samarbete och systematik 46