prosessmodeller og smidig programvareutvikling · 1/21/14 1 inf1050/ 22.1.2014 / © dag sjøberg...
Post on 09-Jul-2020
8 Views
Preview:
TRANSCRIPT
1/21/14
1
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 1
Prosessmodeller og smidig programvareutvikling
Professor Dag Sjøberg
INF1050: Systemutvikling
22. januar 2014
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 2
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
1/21/14
2
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 3
Reell prosess versus modell av prosess
• Systemutviklingsprosess (= faktisk, reell prosess): – de aktivitetene som utføres i et utviklingsprosjekt
• Prosessmodell (=formell prosess) (kalles også gjennomføringsmodell)
– En abstrakt, forenklet representasjon av en prosess • Deskriptiv
– beskriver en prosess slik vi mener vi utfører den • Normativ (preskriptiv)
– beskriver en prosess slik noen mener den bør være (vanligste betydning)
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 4
Modell versus virkelighet
1/21/14
3
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 5
Formell versus reell prosess
Det vi sier vi gjør eller det vi bør gjøre
Det vi gjør
Prosessbeskrivelse Prosessutførelse
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 6
Nivåer av prosessmodeller
Generelle prosessmodeller (fossefall, spiral, RUP, Scrum etc.)
Firma-spesifikke prosessmodeller
Prosjekt/gruppe-spesifikke prosessmodeller
Systemutviklingsprosess
Prosess-samsvar
Definerte prosess- modeller (formell prosess)
Reell prosess
1/21/14
4
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 7
Hvordan tilpasse prosesser?
• Prosesser må tilpasses – ingen prosjekter er like – Mange faktorer påvirker prosessen
• Hva kan tilpasses? – Antall faser/aktiviteter, roller, ansvarsforhold, dokumentformater,
formalitet/frekvens på rapporter og gjennomganger • Hvordan tilpasse?
1. Identifiser prosjektomgivelser – utviklingsstrategi, risiko, krav, applikasjonsområde, type kunde etc.
2. Innhent synspunkter fra utviklere, brukere, kunder 3. Definer prosesser, aktiviteter og roller 4. Dokumenter og begrunn tilpasningene
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 8
Myndighetene anbefaler felles prosjektmodell
• For å sikre kvalitet anbefaler myndighetene at offentlige virksomheter skal bruke en felles prosjektmodell. Er det lurt?
• Ulempe – Sjelden at samme modell passer for alle type virksomheter
• Fordel – Læring på tvers av etater
Se artikkel i Aftenposten: http://www.aftenposten.no/digital/nyheter/Haper-klare-rad-skal-fa-fart-pa-digitaliseringen-7073514.html
1/21/14
5
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 9
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 10
Fossefallsmodellen
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Fra Ian Sommerville
I prinsippet går man ikke tilbake til tidligere hovedaktiviteter før systemet er satt i drift.
1/21/14
6
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 11
Kjennetegn ved fossefallsmodellen
• Plandrevet, dvs. utviklingen styres av planer. Separate faser • Vanskelig å tilpasse endringer i brukerkrav underveis • Best ved godt forståtte krav og når det er lite sannsynlig med
mye endringer underveis – Men få systemer har stabile krav …
• Brukes mest i store prosjekter som gjerne utvikles på ulike steder. Plandreven utvikling gjør det enklere å koordinere arbeidet
• Men brukes også i små, godt forståtte prosjekter (jfr. de 4 bedriftene som lagde samme system)
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 12
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
1/21/14
7
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 13
Inkrementer og iterasjoner i systemutvikling
• Et inkrement er et tillegg i funksjonaliteten – et aspekt ved systemet
• En iterasjon er en syklus i utviklingen – et aspekt ved prosessen
– Et nytt inkrement utvikles gjennom en ny iterasjon – En ny iterasjon kan også forbedre kvaliteten på samme
funksjonalitet, dvs. man lager ikke noe nytt inkrement, men bare forbedrer det eksisterende systemet
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 14
Inkrementell utvikling
• Systemet utvikles gradvis i form av nye inkrementer som blir lagt til. Hvert inkrement evalueres før utviklingen av neste inkrement starter
• Vanlig tilnærming i smidige metoder • Evalueringen gjøres av en bruker- eller kunderepresentant
(“product owner”)
1/21/14
8
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 15
Inkrementell installering
• Istedenfor at hele systemet leveres til kunden på en gang, leveres ett inkrement av gangen som tilsvarer en del av all funksjonalitet
• De viktigste kravene implementeres i de første inkrementene • Når utviklingen av et inkrement er startet, så fryses kravene
til det inkrementet, men kravene til senere inkrementer kan fortsatt endres
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 16
Fordeler ved inkrementell utvikling og installering • Kostnadene ved endrede brukerkrav reduseres
sammenlignet med fossefallsmodellen da delene som må endres, er mindre
• Enklere å få tilbakemeldinger fra kunden på det som har blitt utviklet
• Lettere å se hvor mye som er utviklet så langt • Raskere levering av deler av systemet gir verdi for
kunden raskere enn ved fossefallsmodellen • Den prioriterte funksjonaliteten blir testet mest • Lavere risiko for total prosjektfiasko
1/21/14
9
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 17
Utfordringer ved inkrementell utvikling og installering
• Store prosjekter og systemer krever en relativt stabil arkitektur som inkrementene og teamene må forholde seg til, dvs. arkitekturen kan ikke utvikles i inkrementer
• Strukturen til systemet har en tendens til å bli stadig verre etter hvert som inkrementer legges til
• Derfor stadig vanskeligere å foreta endringer hvis ikke ressurser brukes på re-strukturering (re-faktorering)
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 18
Utviklings-
strategi
Fossefall
Inkrementell
Iterativ (evousjonær)
Definer alle Krav først?
Ja Ja
Nei
Flere utviklings-
sykluser?
Nei
Ja
Ja
krav design
kode test
lever
lever
krav design
kode test
lever
design kode
test
krav
design kode
test lever
test
kode
krav
design
lever
krav
1/21/14
10
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 19
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 20
Prototyping
• Prototype: en foreløpig versjon av et system utviklet for å utforske:
– kravene til et system – alternative brukergrensesnitt – ulike måter å teste systemet på
• Potensielle fordeler: – bedre match mot brukernes faktiske behov – bedre brukskvalitet – bedre design og vedlikeholdbarhet – reduserte utviklingskostnader
1/21/14
11
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 21
Utvikling ved bruk av prototype
• Prototypen bør fokusere på områder av systemet som ikke er godt forstått
• Det finnes egnede språk og verktøy
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 22
“Throw-away” prototype
• Protypen bør skrotes etter at den lagd og brukt – for dårlig basis for et produksjonssystem
– Vil kunne være umulig å møte ikke-funksjonelle krav (f.eks. ytelse, pålitelighet og sikkerhet)
– Prototyper er normalt udokumenterte – Strukturen til prototyper er vanligvis degradert gjennom
raske endringer
1/21/14
12
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 23
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 24
Spiralmodellen
• Utviklingsprosessen er representert som en spiral istedenfor en sekvens med aktiviteter
• Hver runde i spiralen representerer en fase i prosessen, f. eks. kravspesifisering eller design
• Løkkene i spiralen velges etter behov. F.eks. kan man gå tilbake til tidligere aktiviteter
• Risikoanalyse: hva som kan gå galt, og med hvilken sannsynlighet og konsekvens, er vurdert og håndtert eksplisitt gjennom prosessen
1/21/14
13
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 25
Boehm’s spiral model of the software process
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2
Prototype 3Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternatives,identify, resolve risks
Determine objectives,alternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Evaluer prosjektet og planlegg neste fase
Identifiser spesifikke mål for fasen Analyser risiko og utfør aktiviteter for å redusere de viktigste
Design, koding (programmering) etc.
Fra Ian Sommerville
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 26
Bruk av spiralmodellen
• Blant de mest kjente, klassiske modeller • hatt stor betydning i utviklingen av tankegangen
rundt iterasjoner og risikovurderinger i systemutviklingsprosessen
• Men brukes sjelden i konkret systemutvikling
1/21/14
14
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 27
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 28
Rational Unified Process (RUP)
• Ikke en konkret prosessmodell, men et rammeverk for å bygge arkitektur/UML-modeller (se senere forelesninger)
• Programvarebedrifter eller team kan ta utgangspunkt i RUP for å skreddersy en modell for sin utvikling
• Benytter seg av prinsipper fra prosessmodellene beskrevet tidligere i forelesningen
• Vanligvis beskrevet med fokus på faser, disipliner (aktiviteter) og anbefalt god praksis
1/21/14
15
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 29
Inception Elaboration Construction
Phase iteration
Transition
Fire faser i RUP
• Innledning/idé (lag business case) (inception) – Lag overordnet målsetting, behovsanalyse, budsjett, prosjektplan – Identifisere funksjonelle krav og modellere use cases (brukstilfeller)
• Utdypning (elaboration) – Fortsett med å forstå problemområdet, lag use cases – Start design av arkitektur, lag arkitektur prototype – Ferdigstill prosjektplanen
• Konstruksjon (construction) – Design-programmer-test, typisk i flere iterasjoner
• Installering/driftssetting (transition) – Overfør systemet til sitt produksjonsmiljø og sett det i drift; gi
nødvendig opplæring til sluttbrukerne og vedlikeholdere; valider systemet i forhold til kvalitetskrav spesifisert i innledningen etc.
Hver fase er iterativ med resultater som utvikles i inkrementer
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 30
Anbefalte praksiser i RUP
• Utvikle systemet i iterasjoner – I hver iterasjon, legg til et nytt inkrement. Først lag de inkrementene som kunden har
prioritert høyest
• Sørg for god håndtering av krav – Dokumenter kundekrav nøye og sørg for dokumentasjon av endringer i kravene
• Bruk komponent-basert arkitektur – Organiser systemets arkitektur som en mengde gjenbrukbare komponenter
• Lag visuelle modeller av programvaren – Bruk grafiske UML-modeller for å presentere statiske og dynamiske sider ved systemet
• Verifiser kvaliteten – Sjekk at programvaren tilfredsstiller organisasjonens kvalitetsstandarder
• Kontroller endringer i programvaren – Bruk endringshåndteringsverktøy og konfigurasjonsstyringsverktøy
1/21/14
16
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 31
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 32
Gjenbruksbasert utvikling
• Eksisterende programvare gjenbrukes i større eller mindre grad utviklingen av nye systemer
• Komponentbasert utvikling – Samling av komponenter i en pakke som del av
komponentrammeverk som .NET eller J2EE eller andre typer komponent-biblioteker
– Selvstendige programvare-systemer som er utviklet for bruk i et spesielt miljø
• Service-orientert (tjenesteorientert) utvikling – Web-services som er utviklet i henhold til en standard og som kan
kalles fra andre steder – Service-orientert arkitektur (SOA): Forelesning 12. mars
1/21/14
17
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 33
Hvilken prosess er best?
• Sommerville skriver: “There are no right or wrong software processes”
• Ikke eksakt fagfelt; man mangler fortsatt sikker kunnskap om hvordan ulike prosesser fungerer i ulike situasjoner
• MEN: opplagt at noen prosesser er bedre enn andre avhengig av hva slags system som skal utvikles og i hvilken kontekst det skal foregå
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 34
Quiz • For å redusere belastningen på nettet
– Alle med mobiltelefon: Skru av nett-tilgang og bruk mobilnettet isteden – De som har laptop og nettbrett, stopp alt nettbruk annet enn Kahoot
• Gå til kahoot.it på mobil, nettbrett, PC etc. • Pass på at mobilen ikke lukker seg • Tast inn Game pin • Lag ”Nick name”). Brukernavnet sensitivt for små og store
bokstaver. Navnet blir synlig • Det samme brukernavnet må benyttes resten av semesteret • De som blir kastet ut og må logge seg inn igjen, får nullet ut
sin poengsum i øyeblikket, men etterpå blir resultatet likevel summert på samme navn
1/21/14
18
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 35
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 36
Behov for smidighet
• Den klassiske ingeniørtilnærmingen med fokus på plan-legging og dokumenter (jfr. fossefall) har vist seg ofte å ikke være egnet
• Derfor er “smidige metoder” blitt vanlige – Vektlegging av kode fremfor (omfattende) design og dokumentasjon – Vektlegging av samarbeid med kunde fremfor kontraktsforhandlinger – Raskere levering av kode og raske endringer tilpasset endrede
brukerkrav
1/21/14
19
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 37
Plandrevne (tunge) prosesser
• Prosessaktivitetene planlagt på forhånd. Progresjon måles i henhold til planen
• En tung prosess inkluderer mange aktiviteter og ofte roller. Krever formelle, detaljerte og konsistente prosjektdokumenter
• Ofte “for-tunge”, dvs. vektlegger aktiviteter som gjøres tidlig i prosessen (planlegging, analyse & design)
Smidige (lette) prosesser
• Planleggingen gjøres litt etter litt (inkrementelt)
• Enklere å endre prosessen for å tilpasse endrede krav fra kunden
• Fokuserer mer på fundamentale prinsipper (f.eks. ”kontinuerlig testing”). Har færre formelle dokumenter og er ofte mer iterative
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 38
En samling software-guruer i 2001: Agile Manifesto – 12 prinsipper*
*http://agilemanifesto.org og http://agilemanifesto.org/iso/no/principles.html
1/21/14
20
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 39
Agile Manifesto 2001 (forts.)
*http://agilemanifesto.org og http://agilemanifesto.org/iso/no/principles.html
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 40
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
1/21/14
21
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 41
“Ekstrem programmering” (XP)
• Ekstrem ved at: – Hele systemet kan bygges (rekompileres) opp til flere
ganger daglig – Inkrementer av systemet leveres til kunden annenhver uke – Alle tester må kjøres før hver bygging* – Byggingen aksepteres bare hvis testene er vellykkede
*Bygging: Alle komponentene til systemet kompileres og linkes til hverandre og til data og biblioteker som er nødvendige for å lage et kjørbart system
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 42
Praksiser i XP Praksis Beskrivelse Inkrementell planlegging
Kravene skrives som brukerhistorier som typisk tilsvarer en utviklingsoppgave. Hvilke som skal inkluderes i en release blir bestemt ut fra prioritet og tilgjengelig tid.
Små releaser Lag først det minste settet av funksjonalitet som gir verdi for kunden. Lever hyppig nye inkrementer med funksjonalitet.
Enkelt design Bare design så mye som strengt tatt nødvendig. Test-først utvikling Bruk et automatisk testrammeverk til å skrive tester for ny
funksjonalitet FØR funksjonaliteten selv implementeres. Refaktorering Forbedre koden kontinuerlig når muligheter for forbedring oppdages. Parprogrammering Programmer i par. Kollektivt eierskap Alle par skal jobbe på og ta ansvar for alle deler av koden – ikke ha
lokale eksperter på deler av koden. Kontinuerlig integrasjon
Umiddelbart etter at en oppgave er ferdig, må den tilhørende koden integreres i hele systemet. Alle enhetstester må kjøres.
Holdbart tempo Ikke jobb mye overtid fordi konsekvensen er dårligere kode og lavere produktivitet i lengden.
Kunde på stedet Representant for sluttbruker eller kunde bør være tilgjengelig for utviklingsteamet hele tiden.
1/21/14
22
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 43
Brukerhistorie (user story)
• Én eller flere setninger som beskriver hva brukeren av et system ønsker å få ut av systemet på formen:
– ”Som en <rolle> ønsker jeg <funksjon> for å oppnå <verdi>”
• Kort beskrivelse, passer på et kort eller gul lapp
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 44
Refaktorering (omstrukturering) • Se etter forbedringsmuligheter og implementer dem selv om
ikke umiddelbart behov for dem • Koden mer forståelig og enklere å endre, og mindre behov
for dokumentasjon • Noen endringer krever at arkitekturen omstruktureres
(kostbart) • Eksempler på refaktorering
– Reorganisering av klassehierarki for å fjerne duplisert kode – Forbedre navn på attributter og metoder – Erstatte kode med kall til metoder i et programbibliotek
1/21/14
23
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 45 45
Parprogrammering - kan brukes uavhengig av smidig
To programmerere utvikler kode sammen: – Fører
• skriver på tastaturet – Navigatør
• observerer arbeidet til føreren og ser etter feil og svakheter
• ser etter alternativer • noterer ting som må gjøres • slår opp referanser
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 46
Hva er kost-nytten ved parprogramming? • Sommerville skriver i boka s. 70:
– “However, studies with more experienced programmers (Arisholm et al., 2007*; Parish et al., 2004) did not replicate these results. They found that there was a significant loss of productivity compared with two programmers working alone.”
*E. Arisholm, H.E. Gallis, T. Dybå and D.I.K. Sjøberg. Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise, IEEE Transactions on Software Engineering 33(2):65-86, 2007
Dette eksperimentet vil bli gjennomgått på metode-forelesningen 9. april.
1/21/14
24
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 47
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 48
Prosessfokuserte metoder • Fokus på prosjektledelse av iterativ utvikling
fremfor mer tekniske praksiser • To hovedretninger
1. Velg noen prioriterte oppgaver og jobb med dem i faste tidsintervaller (tidsbokser*) med definerte oppstarts- og avslutningsaktiviteter (Scrum)
2. Fokuserer på at oppgaver skal ”flyte” uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige (Kanban)
*Tidsboks: en fast tidsperiode som et gitt arbeid skal være ferdig innenfor
1/21/14
25
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 49
Scrum – tre faser
• Planleggingsfasen: overordnede mål for prosjektet etableres og programvarearkitekturen designes
• Gjennomføringsfasen: en serie med iterasjoner (kalt ”sprint”), der hver iterasjon leverer et inkrement av systemet
• Avslutningsfasen: nødvendig dokumentasjon som hjelp-funksjoner og brukermanualer fullføres, og man oppsummerer hva man har lært i prosjektet
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 50
Scrum
Outline planningand architectural
designProject closure
Assess Select
Review Develop
Sprint cycle
Planlegging
Gjennomføring
Avslutning
Resultatene evalueres mot målene som ble satt i sprint-planleggingsmøtet, og presenteres for kunden (”retrospective”)
Input: Product backlog – liste av arbeidsoppgaver (Work Items) som skal utføres i prosjektet
I sprint-planleggingsmøtet evalueres oppgavelisten (backlog) som er en samling av brukerhistorier. Mål for sprinten settes inkl. prioriteter og risiko. Kunden kan sette nye krav el. gi nye oppgaver
Utviklingsteam og kunde velger egenskaper og funksjonalitet som skal utvikles i sprinten
Design, koding, testing. Utviklings-teamet isoleres fra kunden og organisasjonen, dvs. all kommunika-sjonen skjer via Product Owner eller Scrum Master for å unngå forstyrrelser
Tidsboks: 2-4 uker
Lag dokumentasjon (hjelpefunksjoner, brukermanualer) og oppsummer hva man lærte
1/21/14
26
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 51
Visualisering
User stories
Noter en oppgave eller arbeidspakke på en gul lapp og sett den på en tavle
US1
US2
US4 US3 US5
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 52
(Antatte) fordeler ved Scrum
• Systemet blir delt opp i en mengde forståelige og håndterbare deler
• Ustabile krav hindrer ikke progresjon i prosjekt-gjennomføringen
• Hele teamet observerer hva som skjer i prosjektet, og kommunikasjon innen teamet blir god
• Kundene får inkrementer levert til avtalt tid og får fortløpende tilbakemelding på hvordan deler av systemet fungerer
• Tillit mellom kunder og utviklere etableres tidlig og en positiv kultur skapes
• Kryss-funksjonelle team (kompetansene på ulike områder finnes innen teamet) sikrer framdrift og reduserer risiko
Mer om teamarbeid i Scrum på forelesningen 26. mars
1/21/14
27
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 53
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 54
Prosessprinsipp: Timeboxing versus “task-boxing” / “task-flyt”
Scrum • Ikke alltid greit å dele inn oppgaver eller “features” av
systemet tilpasset ”sprintene”, f.eks. vedlikehold, videreutvikling og support
Kanban • Definerer et sett med oppgaver eller “features” og lever så
snart man er ferdig. Oppgaver skal ”flyte” uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige (oppgaveboksing)
1/21/14
28
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 55
Flytbasert utvikling
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 56
Fokus på flyt
• Flyt av materialer, folk og penger: arbeidskraft var billig, hadde nok folk, OK om folk i periode ikke hadde noe å gjøre
• Tilpasset høyden til hva de kunne produsere – ikke omvendt • Tett samarbeid mellom arkitekter, bygningsarbeidere og
underleverandører • Erfarne arbeidere • Fast pris kontrakt • Fokus på materialflyt (500 lastebiler om dagen) – ingen
mellomlagring • Dekobling (modularisering): ulike systemer skulle være uavhengige • Tid var penger: Hver dag forsinket kostet $10 000 ($120 000 i dag)
1/21/14
29
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 57
Kanban
• Fokus på gjennomstrømningshastighet på arbeidspakkene = antall brukerhistorier (features) implementert per tidsenhet
• Begrense antall arbeidspakker som det jobbes med i parallell (WIP = Work In Progress) for å hindre flaskehalser
• Antakelse: Jo høyere WIP, jo saktere flyter arbeidspakken gjennom arbeidsprosessene
• Når en pakke er ferdig, kan man etterspørre en ny som man begynner å jobbe med (pull)
• Slakk i tidsplanen er OK, dvs. en utvikler vil kunne vente hvis det optimaliserer overordnet flyt
• Mindre fokus på estimering
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 58
Forskjell på Scrum-tavle og Kanban-tavle
From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009
Max WIP
1/21/14
30
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 59
Fordeler ved Kanban
• Flaskehalser i prosessen blir synlige – Fokus på å bli ferdig med oppgaver som hindrer
gjennomstrømning fremfor å begynne på flere oppgaver som vil hope seg opp
• Kan drive smidig utvikling uten å bruke “tidsbokser” – Spesielt for drifts- og supportoppgaver og
vedlikeholdsoppgaver vil veldefinerte “sprinter” ofte ikke gi mye mening
• Gunstig der det er svært vanskelig å estimere oppgavene
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 60
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
1/21/14
31
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 61
Kanban – en teknikk fra Lean (slank) production
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 62
Lean – “den japanske skolen”, primært Toyota – Kontinuerlig læring og forbedring (Kaizen)
• Forbedre helheten, dvs. ikke sub-optimalisere • Ved feil, stopp samlebåndet og finn årsaken til feilen fremfor
å samle og rette opp alle feil i bolker – “Just-in-time”-prinsippet:
• Ikke lag noe før noen etterspør det – Komponentbasert produksjon (samme understell etc. på
ulike biltyper) – Kundefokus – Unngå ”waste”
• Fjerning av mellomlagring
1/21/14
32
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 63
Waste
• Alt som krever ressurser – tid – arbeidsinnsats – rom – lager (unngå mellomlagring) – utstyr – penger som ikke gir verdi for kunden
• Verdi = det kunden ønsker og er villig til å betale for
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 64
Resultat
• Toyota færrest feil og raskest produksjon – Skyldes også hard jobbing
• De mest produktive bedriftene brukte færrest ressurser på ledelse og administrasjon (”lean management”)
1/21/14
33
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 65
Den norske/nordiske modellen
• Selvstyrte (autonome) team • Læring, redundans/jobbrotasjon • Medvirkning og arbeidsmiljø • Livskvalitet • Samarbeid ledelse, arbeidstakerorganisasjoner og
myndigheter • Hydro, Volvo og mange flere
B. Gustavsen, T.U. Quale, B.A. Sørensen, M. Midtbø og P.H. Engelstad. Innovasjonssamarbeid mellom bedrifter og forskning – den norske modellen. Gyldendal 2010
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 66
Bilproduksjon vs. programvareutvikling
• Bilindustri er produksjon av fysiske produkter, mens programvareutvikling fokuserer på kode (tekst)
• Likevel, lean prinsippene kan anvendes i programvareutvikling
• Lean management er et hett tema i mange sektorer som ikke driver produktutvikling
– Offentlig forvaltning (f.eks. helsevesen, universiteter)
– Privat sektor
1/21/14
34
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 67
Plan
• Kap. 2: – Begrepet ”prosessmodell” – Prosessmodeller og prinsipper for
utvikling • Fossefallsmodellen • Inkrementell og iterativ utvikling • Prototyping • Spiralmodellen • Rational Unified Process (RUP) • Gjenbruksbasert utvikling
• Kap. 3 – Begreper og prinsipper innen
smidig utvikling – Programmeringsfokuserte
smidige metoder • Ekstrem programmering (XP)
– Prosessfokuserte smidige metoder
• Tidsboksbasert (Scrum) • Flytbasert (Kanban)
– Lean systemutvikling – Oppsummering smidige metoder
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 68
Utfordringer ved smidige metoder
• Vanskelig å opprettholde kundens interesse i prosjektet hele tiden
• Utviklerne vil kunne mangle det intense engasjement som kreves
• Vanskelig å prioritere endringer hvis mange interessenter (stakeholders)
• Krever ekstra tid å stadig gjøre endringer og opprettholde enkelhet
• Kontrakter kan være et vanskelig tema (se forelesning 23. april)
1/21/14
35
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 69
Utfordringer ved utvikling av store systemer • Hvordan skalerer smidige metoder i
– store, langvarige prosjekter med – mange utviklingsteam som kanskje – jobber distribuert, kanskje innen ulike kulturer og tidssoner – med hvert sitt del-system som skal kommunisere med hverandre?
• Krav til kommunikasjon mellom del-systemer vanskeliggjør fleksibilitet og inkrementell utvikling. Lite fokus på integrering av del-systemer.
• Store systemer tar lang tid å utvikle. Vanskelig å ha fokuserte team hele tiden som kjenner prosessen og produktet godt. Folk begynner i andre prosjekter og jobber.
• Store systemer har mange interessenter som kan være vanskelig å involvere i utviklingsprosessen.
• Design og system-dokumentasjon viktig i store systemer, ikke bare kode.
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 70
Merk:
• Sommerville diskuterer ikke flytbasert utvikling (Kanban)
• Temaet er likevel viktig
1/21/14
36
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 71
Oppsummering
• Smidige metoder er kommet for å bli • Finnes mange måter å være smidig på • Mer om smidig i forelesningen om prosjektledelse 26.
mars og studier av smidig utvikling 9. april. • NF5181 – Prosessforbedring og smidige metoder i
systemutvikling
INF1050/ 22.1.2014 / © Dag Sjøberg Slide 72
Quiz
top related