Integrerat ingenjörsprojektwebstaff.itn.liu.se/~marka/TNIU21/03_Slides/slides.pdf · 2008. 1. 18. · Martin Karlsson TNIU21 Integrerat ingenjörsprojekt Reliabilitet & Validitet

Martin Karlsson

TNIU21 Integrerat ingenjörsprojekt

Integrerat ingenjörsprojekt

TNIU21

Martin Karlsson


Kursmål

• Studenten skall efter genomgången kurs kunna• arbeta efter en projektmodell i en autentisk situation• medverka aktivt och väl fungerande i en projektgrupp• utveckla initiativförmåga och visa på kreativa

lösningar• införskaffa tillräckliga kunskaper inför utförande av

projektarbete• anpassa projektmodellen och teknik till

projektkontext• redovisa delresultat muntligt och skriftligt inom givna

tids- och projektramar• reflektera över utfört projektarbete och föreslå

förbättringar runt metod och resultat

2

Martin Karlsson


Examination

• “Exjobbsrapport”• Behandlar metod/process, fokuserar ej på

produkt

• Struktur:• Sammanfattning / Abstract • Introduktion • Teori • Metod • Resultat • Diskussion• Slutsats

3

Martin Karlsson


Reliabilitet & Validitet

• Validitet ser till att det som mäts är relevant i sammanhanget

• Reliabilitet ser till att det mäts på ett tillförlitligt sätt

• Validitet handlar om att använda rätt sak vid rätt tillfälle. Att kunna ange i vilken situation och för vilken population resultaten är giltiga

• Reliabilitet handlar om pålitlighet. Vilka beslut kan fattas om de baseras på mätningar som man inte kan lita på?

4

Exempel

Om vi vill räkna ut BMI (Body Mass Index) för en person så behöver vi längd och vikt. Om vi då har mätt skostorlek mycket noggrant så har vi uppnått hög reliabilitet, men låg validitet, för vi kan ju inte avgöra BMI med bara skostorleken. Om vi istället tittar på personen och skattar längd och vikt så har vi låg reliabilitet, men validiteten är högre.

Martin Karlsson

TNIU21 Integrerat ingenjörsprojekt 5

Kvantitativ validitet

• Innehållsvaliditet: Avgöra om metoden mäter vad den ska

• Samtidig validitet:Säkerställer att resultat stämmer överens med resultat från andra undersökningar gjorda av andra (med en annan metod)

• Konstruktionsvaliditet:Stämmer relaterade begrepp överens med våra mätningar?

• Kommunikativ validitet:Att kommunicera sin vandring genom forsknings-processen, så att försöket kan generaliseras/upprepas

• Pragmatisk validitet:Är den kunskap man kommer fram till användbar?

Martin Karlsson


Kvalitativ validitet

• Kommunikativ validitet (inre validitet)• Beskrivning av förförståelse/fördomar som

författaren har• Beskrivning av metod• Beskrivning av urval av deltagare• Beskrivning av analysprocessen

• Triangulering (inre validitet)• Intervjua deltagare med olika relation till

problemet• Analysera materialet enligt olika paradigm

• Överförbarhet (yttre validitet)• Författaren presenterar vägen och undersöker om

resultaten är tillämpbara (ej generaliserbarhet)

Martin Karlsson


Reliabilitet

• Kvantitativ reliabilitet• Är mätningen fri från bias (fördom/vinkling) av

personen som mäter?

• Påverkas mätningen av tiden?

• Finns det en samstännighet i utfallet mellan olika delar i en enkät som tar upp samma fenomen?

• Kvalitativ reliabilitet• Är mätinstrumenten pålitliga?

• Är forskarens kvalitet tillräcklig?• Är forskaren objektiv (inre validitet)?

Martin Karlsson


Frågor på examination?

8

Martin Karlsson


Iterativ utveckling

9

Planera

Genomföra

Utvärdera

Förstå/Besluta

Martin Karlsson


Inkrementell utveckling

10

Martin Karlsson


Agil utvecklingsmetodik

• Inkrementell och iterativ utvecklingsmetod

• Agile Manifest• Individer och samspel

• framför metoder, processer och verktyg

• Körbar programvara• framför omfattande dokumentation

• Kundsamarbete• framför kontraktsförhandlingar

• Anpassning till förändring• framför att följa en statisk plan

11

Martin Karlsson


Extreme Programming

• För de dagliga aktiviteterna i projektet

• Utvecklarna sätts i första rummet

• Bill of rights

• Sustainable pace

• Fyra värden (öh, nej, fem...)• Kommunikation, enkelhet, feedback, mod, respekt

• Practices

• Kodstandard, Kontinuerlig integration, Parprogrammering, TDD, Refactoring, m.m.

12

Martin Karlsson


Extreme Programming

13

•Kundens rättigheter• Ledningen har rätt att bestämma kostnader • Ledningen har rätt att bestämma prioriteter• Ledningen har rätt att se hur långt arbetet har fortskridit

•Teamets rättigheter• Teamet har rätt att uppskatta hur lång tid en viss uppgift kommer ta • Teamet har rätt att få sin uppskattning respekterad• Teamet har rätt att ärligt rapportera fortgång• Teamet har rätt att få veta vad som är viktigast att göra härnäst• Teamet har rätt att få stöd närhelst teamet behöver det

Bill of rights

Martin Karlsson


Parprogrammering

• Två programmerare jobbar sida vid sida

• En programmerare, föraren, har kontrollen över tangentbordet och implementerar aktivt.

• Den andre programmeraren, observatören, observerar kontinuerligt det som föraren kodar för att identifiera taktiska defekter

• Vid behov kan de två programmerarna brainstorma runt hinder de möter på vägen och eftersom de ibland byter roller, arbetar de jämlikt tillsammans.

14

Martin Karlsson


Parprogrammering

15

• Parprogrammerare spenderar ungefär 15% mer tid än individuella programmerare på samma uppgift. Dock är denna extra tid inte statistiskt signifikant.

• Parprogrammerare får 15% färre fel i koden än individuella programmerare. Denna högre kvalitet är statistiskt signifikant.

• 95% av parprogrammerare säger att de trivs bättre med arbetet, är mer självsäkra och litar på att den kod de har producerat fungerar.

• I det långa loppet tjänar man alltså både moral och pengar, eftersom det tar mycket lång tid att rätta buggar

Martin Karlsson


Parprogrammering

16

Martin Karlsson


Refactoring• Omfaktorisering (refactoring)

• Effektivisera, optimera och öka läsbarhet utan att ändra funktionalitet

• Förbereder för och förenklar återanvändbarhet• Ökar flexibiliteten i arkitekturen, vilket bidrar till okomplicerad

design och en enkelhet att lägga till eller ändra krav• Ökar underhållbarheten

• Unken kod är skäl för omfaktorisering• Duplicerad kod• Långa metoder• Stora klasser• Utspridda ändringar• Switch/Case-satser• Onödig generalitet• Primitiva tvångstankar• Kommentarer

17

Martin Karlsson

TNM021 Programvaruutveckling

• Ger direkt feedback på felaktigheter i kod• Ju längre en defekt finns i systemet desto svårare och

kostsamt är det att ta bort den• Därmed kan man hitta defekter och dess orsaker med

lätthet

•Använder sig av en testfall som samlas i en testbänk (scaffolding)• Genom att kontinuerligt köra dessa automatiska

testfall kan man lätt se om en förändring påverkar systemet negativt

• Den automatiska testbänken gör därmed att ny funktionalitet lätt integreras i koden

18

Testdriven utveckling(TDD)

Martin Karlsson

TNM021 Programvaruutveckling

• Hur då?1. Skriv en testmetod för din metod2. Kompilera testet. Det ska fallera, eftersom du

inte har skrivit koden som testet ska anropa och testa

3. Implementera precis tillräckligt i metoden för att kompileringen ska gå igenom

4. Kör testet och kolla om det fallerar5. Implementera precis tillräckligt i metoden för

att testet ska gå igenom6. Kör testet och kolla så att det inte fallerar7. Omfaktorisera för förtydligande och

borttagning av duplicit kod i metoden19

Testdriven utveckling(TDD)

Martin Karlsson


Scrum

• Scrum sköter den omkringliggande verksamheten, specifikt planering

• Scrum ger teamet chans att organisera sig själva

20

Martin Karlsson


Scrum

• Produktägare• Har tätast kontakt med kund eller är kund

• Tar hand om kravarbetet (backlog i Scrum)

• Måste vara en gris

• Scrummaster• Är processägare och ansvarig för att teamet ska lyckas med Scrum

• Är teamledare, inte projektledare

• Skyddar teamet mot omvärldens höns

• Är utvecklare i teamet och således gris

• Team/Utvecklare• Storlek - 7 +/- 2

• Självorganiserande, är sina egna projektledare

• Grisar

21

Roller

Martin Karlsson


Product backlog

Sprint backlog

SPRINT

Leveransobjekt

1-4 veckor sprint

24 timmar (daily scrum)

Scrum

Sprint retrospective

Sprint planning

Martin Karlsson


Scrum• Product backlog

• En lista av prioriterade arbetsuppgifter i projektet

• Listan baseras på kundens vision/krav

• Sprint backlog• En prioriterad och tidsestimerad lista över arbetsuppgifter från

projektet att utföra i aktuell sprint

• Tar de viktigaste sakerna ur Product backlog först

• Sprint planning• Prioritering och tidsestimering av en lagom mängd uppgifter

från product backlog som räcker för att ge ett leveransobjekt

• Man väljer ut så mycket som man lämpligen kan hinna med under en sprint (säg 1 vecka för detta projektet)

• Tidsestimering görs så bra man kan, estimerar man fel så har man lärt sig det till nästa sprint planning

23

Martin Karlsson


Scrum• Product backlog innehåller stories

• ID - unik identifering (det räcker med ett löpnummer)

• Namn - kort och beskrivande, verb och substantiv, 2-10 ord

• Viktighetsgrad - Produktägarens viktning, 1-150 kanske, prioritet är ett dåligt ord. OBS! Olika viktning på alla delar!

• Ett första estimat - En enklare tidsuppskattning ifrån teamet

• Enheten är “points” och matchar något bra, i vårt fall ideala-ingenjörs-timmar.

• Ta ett lagom stort antal personer (2-4), lås in er i ett rum där det finns mat och inga telefoner, hur många timmar skulle det ta att slutföra arbetet? Om svaret är 3 personer och 4 timmar, då är estimatet 12 points

• Det viktigaste är att estimatet används för att jämföra mot andra estimat ... 2 points är dubbelt så mycket som 1, och matchar inte nödvändigtvis 2 timmar.

• Hur det ska testas/demas - “gör det här, och sen det här, då borde det här inträffa.” Ett användningsfall. (För TDD)

• Tillägg - annan info, referenser, m.m.

Martin Karlsson


Scrum

25

Product backlogID Name Imp Est Demo Notes

1 Deposit 30 5

Log in, open deposit page, deposit €10, go to my balance and check that it has increased by €10.

Need an UML sequence diagram. No need to worry about encryption for now

2

See your own transaction story

10 8

Log in, click on “transactions”. Do a deposit. Go back to transactions, check that the new deposit shows up

Use paging to avoid large DB queries. Design similar to “view users page”.

Martin Karlsson


• Leveransobjekt• En tillräckligt stor delmängd av systemet för att ge direkt nytta

• En helhet som fungerar och bara innehåller det viktigaste just nu

• Ger chans till utvärdering innan hela produkten är färdig

• Daily Scrum• Vad har du gjort sedan igår?

• Vad planerar du att göra idag?

• Vad hindrar dig från att nå ditt mål?

• Sprint retrospective• Ett möte där alla gruppmedlemmar reflekterar över genomförd

sprint. Diskussion om vad som gick bra och vad man kan göra bättre nästa sprint.

26

Scrum

Martin Karlsson


Daily Scrum

SprintBacklog

BurndownChart

SprintPlanning

SprintReview

ScrumMaster

ProductOwner

ProductBacklog

Team

TDDCoding

Standard

PlanningGame

SmallReleases

Metaphor

SimpleDesignContinuous

Integration

Refactoring

Pair programming

CollectiveOwnership

SustainablePace

XP

SCRUM

Whole team

Tracker

Martin Karlsson


Feedback cycles

28

Par-programmering

TDD/Enhetstest

Kontinuerlig integration

Daily Scrum

Sprint demo

Martin Karlsson


Agile & Usability

29

Martin Karlsson


Frågor så långt?

30

Martin Karlsson


Backlogbygge

• Timeboxed, som allt i Scrum (30 min)

• Resultat, en lista i viktighetsordning

31

ID Name Imp Est Demo Notes

1 Deposit 30 5

Log in, open deposit page, deposit €10, go to my balance and check that it has increased by €10.

Need an UML sequence diagram. No need to worry about encryption for now

2

See your own transaction story

10 8

Log in, click on “transactions”. Do a deposit. Go back to transactions, check that the new deposit shows up

Use paging to avoid large DB queries. Design similar to “view users page”.

Martin Karlsson


Sprint planning

32

• Vad krävs för sprint planning• En product backlog!

• Att varje teammedlem vet hur mycket de kan lägga in i sprinten

• Vad kommer ur en sprint planning• Ett sprint goal

• En lista på teammedlemmar och deras commitment

• Ett givet demodatum/tid

• En definierad plats och tid för daily scrum

• En sprint backlog

• En schysst plan som gör att teamet kan arbeta ostört en sprint

• Vilka deltar• Kund / produktägare

• Alla andra grisar

Martin Karlsson


Sprint planning

33

• Varför måste kund/produktägare delta?• Fyra variabler

• Omfattning, estimat (tid), viktighetsgrad (kostnad), kvalitet

• Vem bestämmer vad?

• Extern kvalitet bestäms av användarna (en del av omfattning)

• Intern kvalitet är bestämd. Den tummar ingen på!

• Agenda• Timeboxed!

• Produktägare bestämmer sprint goal (en helhet!)

• Teamet estimerar samt bryter ned stories tillsammans med kund/produktägare

• Produktägare uppdaterar ev. viktighetsgrad

• Alla tillsammans bestämmer vilka stories som ska vara med

• Teamet sätter tid och plats för daily scrum

Martin Karlsson


Sprint planning

34

• Vilka stories ska vara med? Om D ska få plats?

A

Product backlog

B

C

D

E

}Velocity

D

Alt. 1Omprioritera

A

Product backlog

B

C

E

}Velocity

Alt. 2Ändra omfattning

A

Product backlog

B

C

D

E

}Velocity

Alt. 3Dela stories

Product backlog

}Velocity

A1

B

C

D

E

A2

Martin Karlsson


Sprint planning

• Velocity• Hur många story points är

utförda?

• Focus factor• Teamets effektivitet

• Available time• Räknas i ideala-ingenjörs-

timmar/dagar

35

Focus factor =Actual Velocity

Available timeLast

sprint

ThisSprint

Estimated Velocity =Focus factor * Available time

Martin Karlsson


Sprint planning

• Bryt ner stories i aktiviteter• Det blir mycket diskussion och mycket ändringar i denna fas

• Smidigast att göra med post-it-lappar

• Produktägaren/kunden behöver inte delta

• Exempel: Storyn “Query Users” får aktiviteterna “Clarify requirements”, “Write test code”, “Design GUI”, “Test GUI”, “Find reporting tool and do spike”, “Implement user list”, “Integration test, debug, refactor”, “Implement query form”

• En story är färdig när den • Är accepterad av produktägaren

• Håller tillräckligt hög kvalitet (dvs. är parprogrammerad, testad och omfaktoriserad enligt XP)

• Därmed bör test-first och omfaktorisering vara aktiviteter till en story (se ovan)

36

Martin Karlsson


Sprint running

37

Arbeta tillsammans och synliggör arbetet

Sprint taskboard direkt efter sprint planning

Martin Karlsson


Sprint running

38

Ta från den översta storyn (viktighetsgrad 150)

Sprint taskboard under dag 2

Martin Karlsson


Sprint running

39

Tydliggör oplanerade aktiviteter

Sprint taskboard under dag 10

Martin Karlsson


Sprint running

• Nya krav och förändrade krav som dyker upp mitt i sprinten?• Placeras i product backlog av produktägaren,

prioriteras/viktighetsgraderas av kund och estimeras (i mån av tid) av teamet

• Sätts upp som story under nästa sprint planning och utförs under den sprinten

• Om kravet är en rejäl förändring, stoppas sprinten och en ny sprint planning görs

40

Martin Karlsson


Sprint tracking

41

• Burndown chart• Om grafen glider över normalstrecket så är det läge att ta bort

några planerade stories

• Om grafen glider under normalstrecket så lägger man till några ifrån backlog:en

Martin Karlsson


Sprint retrospective

42

• Låt alla komma till tals

• Försök förklara estimated vs. actual velocity

• Dela upp i enkla kategorier, som “good”, “could have been better”, och “improvements”

Martin Karlsson


Ert projekt• Roller

• Flera produktägare

• Flera processägare (Scrum masters)• Teamleaders

• Tisdagar demo / sprint planning

• Sista dagen• Demo för examinator & kund

• Release

• Inlämning av rapport

• Kickout (lunch - boka bord! :)43

Martin Karlsson


Referenser

• Extreme programming explained, Kent Beck

• Agile Software Development with Scrum, Ken Schwaber/Mike Beedle

• Agile Project Management with Scrum, Ken Schwaber

• Scrum and XP from the Trenches, Henrik Kniberghttp://www.infoq.com/minibooks/scrum-xp-from-the-trenches

44

Documents

Integrerat ingenjörsprojektwebstaff.itn.liu.se/~marka/TNIU21/03_Slides/slides.pdf · 2008. 1. 18. · Martin Karlsson TNIU21 Integrerat ingenjörsprojekt Reliabilitet & Validitet