Velkommen til andre del av IN1030 Introduksjon til systemutvikling Prosesser og prosessmodeller Professor Dag Sjøberg IN1030/ 14.3.2019 / Dag Sjøberg Slide 1 Dag Sjøberg (dagsj@ifi.uio.no) Professor i software engineering ved Ifi, UiO siden 1999 Seniorforsker II ved SINTEF IKT siden 2014 Mastergrad Ifi, UiO 1987 PhD (dr.grad), Universitetet i Glasgow 1993 Forskningsdirektør Simula Research Laboratory 2001-2008 2 år som konsulent ved Rikshospitalets IT-avdeling 2,5 år som systemutvikler og gruppeleder i Statistisk Sentralbyrå Medgründer og styremedlem i tre IT-selskaper IN1030/ 14.3.2019 / Dag Sjøberg Slide 2 1
Forventninger: Lære mer om systemutvikling, inkl. teamarbeid Lære hvordan utvikle systemer / systemutviklingsprosessen 19 Teamarbeid / samarbeid / gruppearbeid / jobbe sammen med andre om utvikling 16 Lære nyttige ting som er relatert til arbeidslivet 9 Annet: Lære å forstå software-brukeres behov Forventer mye praksis erfaring Mest mulig konkret, og gjerne knyttet til dagsaktuelle hendelser Lære om systemer, krav og konsekvenser Informatikk i samfunnet (digitalisering osv.) Versjonshåndtering Antall svar IN1030/ 14.3.2019 / Dag Sjøberg Slide 3 Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 4 2
Pensum 1: Lærebok Sjøberg & Lindsjørn, Selected chapters from Ian Sommerville: Software Engineering, 10th ed, pluss noe tilleggsstoff. Pearson ISBN 978-1-78448-724-9 Eller hele boka: Ian Sommerville: Software Engineering, 10th ed., Pearson. ISBN-13: 978-0133943030 ISBN-10: 0133943038 IN1030/ 14.3.2019 / Dag Sjøberg. Slide 5 Slide 6 Artikkel av Dag S. om forskningsmetoder i Seleced chapters boka er ikke i Sommervilles bok (ikke pensum men relevant). Artikkelen legges ut for spesielt interesserte og som har kjøpt hele Sommerville-boka IN1030/ 14.3.2019 / Dag Sjøberg 3
Pensum 2: Lysark fra forelesningene Inkluderer pensum som utfyller læreboka Undervisningen på universitetet skal være forskningsnær. Derfor presenteres noen forskningsresultater som ikke står i læreboka Tekstbaserte, dvs. godt egnet for lesing til eksamen IN1030/ 14.3.2019 / Dag Sjøberg Slide 7 Obligatoriske oppgaver Oblig 4 har frist fredag 12. april kl. 23:59 Oblig 5 har frist fredag 10. mai kl. 23:59 Krav for å gå opp til eksamen IN1030/ 14.3.2019 / Dag Sjøberg Slide 8 4
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 9 Magic triangle *Scope: hvor mye funksjonalitet systemet omfatter IN1030/ 14.3.2019 / Dag Sjøberg Slide 10 5
Definisjon: Systemutvikling (software engineering) er læren om utvikling og forvaltning av programvaresystemer av høy kvalitet innen gitte tids- og kostnadsrammer Viktige kvalitetsegenskaper er funksjonell egnethet, effektivitet, pålitelighet, brukskvalitet, kompatibilitet, vedlikeholdbarhet, sikkerhet og overførbarhet Typiske aktiviteter er planlegging, kravinnsamling og kravanalyse, design, programmering/koding, testing, konfigurasjonsstyring og versjonshåndtering Software engineering inkluderer også å utvikle og evaluere arbeidsmåter, metoder og verktøy som støtter slike aktiviteter IN1030/ 14.3.2019 / Dag Sjøberg Slide 11 Programvare finnes nærmest overalt! IN1030/ 14.3.2019 / Dag Sjøberg Slide 12 6
Hvilke konsekvenser har det at systemer er av ulike typer? Ulike typer systemer har ulike egenskaper og stiller ulike typer krav Systemene må derfor utvikles på ulike måter Hva vil være forskjellig ved utvikling et fly/tog-kontrollsystem og web-system som gir oversikt over Ifi s kurs? IN1030/ 14.3.2019 / Dag Sjøberg Slide 13 Variasjon i størrelse og kompleksitet Programvaren Fra noen få tusen til mange millioner linjer kode Utviklingsteamene fra enkeltpersoner til over 1000 utviklere (MS Windows) Kostnad utvikling og vedlikehold fra noen tusen kroner til flere milliarder IN1030/ 14.3.2019 / Dag Sjøberg Slide 14 7
IT-skandaler: Aftenposten IN1030/ 14.3.2019 / Dag Sjøberg Slide 15 Stor usikkerhet i IT-prosjekter Få prosjekter blir skandaler, men mange prosjekter har stor usikkerhet når det gjelder tid kostnader levert funksjonalitet og kvalitet IN1030/ 14.3.2019 / Dag Sjøberg Slide 16 8
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 17 Tilstanden på systemutvikling i Norge? 81 firmaer invitert til å komme med anbud på et lite web-basert informasjonssystem 35 firmaer la inn anbud Hvor stor variasjon i pristilbud? IN1030/ 14.3.2019 / Dag Sjøberg Slide 18 9
Fra kr. 21.000 til kr. 560.000! Kroner 600000 500000 400000 300000 200000 100000 0 Firma 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 IN1030/ 14.3.2019 / Dag Sjøberg Slide 19 Variasjon anbud IT-prosjekter versus veiprosjekter Kroner 3 X 600000 500000 400000 300000 200000 100000 0 Kroner 9,000,000 8,000,000 7,000,000 6,000,000 5,000,000 4,000,000 3,000,000 2,000,000 1,000,000 0 * 1 2 3 4 5 6 7 8 9 10 *H. Pedersen, Tender Prices: Bridge, Tunnel, Electro and Road Building and Maintenance 1998-2006, Technology Report 2468, Norwegian Public Roads Administration, 2006 10
Spennende studie valgte fire firmer istedenfor ett! Tilbud, Kroner 600000 500000 400000 300000 200000 100000 0 Firma 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 A B C D B.C.D. Anda, D.I.K. Sjøberg and A. Mockus. Variability and Reproducibility in Software Engineering: A Study of four Companies that Developed the same System, IEEE Transactions on Software Engineering 35(3):407-429, IN1030/ 14.3.2019 / Dag Sjøberg Slide 21 2009 Hvilket firma gjorde det best? Hva betyr best? Sammenheng mellom pris/arbeidsmengde og kvalitet? IN1030/ 14.3.2019 / Dag Sjøberg Slide 22 11
Dårlig Godt 900 880 860 840 820 800 780 760 740 720 700 680 660 640 620 600 580 560 540 520 500 480 460 440 420 400 380 360 340 320 300 280 260 240 220 200 180 160 140 120 100 80 60 40 20 0 Arbeidsmengde Effort company firma (hours) (timer) Prosjektkvalitet Arbeidsmengde Effort customer Lead Ledetid time (kal- (days) Overskridelse Overrun (%) (%) kunde (hours) (timer) endertid (dager) Compan Firma IN1030/ 14.3.2019 / Dag Sjøberg Slide 23 Systemkvalitet God 3 2 Gjennomsnitt: B D A and C Dårlig 1 0 Brukervennlighet Pålitelighet (feil) Brukskvalitet Vedlikeholdbarhet Firma A B C D IN1030/ 14.3.2019 / Dag Sjøberg Slide 24 12
Vedlikehold (forvaltning) Vedlikehold av IT-systemer betyr ikke å bevare originalversjonen mest mulig slik som for bil, hus etc. Vedlikehold er alle endringer utført på et system etter at det er satt i drift Utgjør 50% 90% av kostnadene i levetiden til et system Stor andel av nedarvede ( legacy ) systemer: bank, forsikring, offentlige etater IN1030/ 14.3.2019 / Dag Sjøberg Slide 25 Alle fire systemene satt i drift i parallell. Etter to år, behov for vedlikehold: Tre endringer To tilpasninger etter plattformendringer Ett ønske om ny funksjonalitet Leide inn 6 utviklere fra Tsjekkia og Polen som hver utførte vedlikeholdsoppgavene på 2 av systemene Brukte ca. 3 uker hver på hvert system kostnad kr. 400.000 Tid brukt på hver fil ble automatisk registrert IN1030/ 14.3.2019 / Dag Sjøberg Slide 26 13
Størrelse versus vedlikehold 60 55 50 45 40 35 30 25 20 15 10 5 0 System A System B System C System D Average effort (hours) Java lines of code (KLOC) Programmeringstips: Etter at du har skrevet en kodebit, tenk igjennom om du kan skrive samme funksjonalitet på en kortere, og mer forståelig måte IN1030/ 14.3.2019 / Dag Sjøberg Slide 27 Hva var årsaken til forskjellene? Ulike måter å jobbe på, dvs. ulike systemutviklingsprosesser, gir ulike resultater Viktig å være bevisst hvilke kvalitetsegenskaper man ønsker å vektlegge IN1030/ 14.3.2019 / Dag Sjøberg Slide 28 14
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 29 Systemutviklingsprosess er de aktivitetene som utføres for å utvikle et IT-system Aktivitetene varierer, men vil alltid ha elementer av spesifisering av kravene, dvs. hva systemet skal gjøre design av systemet (for eksempel lage en datamodell) implementering av koden (programmering) validering av at systemet gjør det kunden ønsker endringer av systemet i forhold til nye og endrede krav hos kunden IN1030/ 14.3.2019 / Dag Sjøberg Slide 30 15
Prosessen påvirker resultatet Systemutviklingsprosessen vil påvirke kvaliteten både på prosjektet selv og systemet som utvikles Måten man jobber på påvirker også arbeidsmiljøet (trivsel, motivasjon, kompetanseutvikling etc.) som igjen påvirker prosjekt- og produktkvalitet Din kompetanse og måten du og ditt team jobber på avgjør hvordan prosjektet og sluttproduktet blir! IN1030/ 14.3.2019 / Dag Sjøberg Slide 31 Prosess-egenskaper Hvilke aktiviteter inngår i prosessen? Hvor mye av hver aktivitet (absolutt og relativt i forhold til hverandre)? Når i utviklingsfasen gjøres (hvor mye) av hver aktivitet? Prosessbeskrivelser vil også kunne inneholde delprodukter/resultater av en aktivitet rollene til dem som er involvert i prosessen hvordan teamene organiseres (man jobber sjelden alene) metoder, verktøy og teknikker som brukes IN1030/ 14.3.2019 / Dag Sjøberg Slide 32 16
Aktiviteter i de fire firmaene IN1030/ 14.3.2019 / Dag Sjøberg Slide 33 Relativ vektlegging IN1030/ 14.3.2019 / Dag Sjøberg Slide 34 17
Vektlegging underveis A B C D IN1030/ 14.3.2019 / Dag Sjøberg Slide 35 Eksempel på roller Utvikler Vedlikeholder Arkitekt/system designer Grafisk designer Tester Prosjektleder Bruker-/kunderepresentant Ikke trivielt å besette et prosjekt med den riktige kompetansen! IN1030/ 14.3.2019 / Dag Sjøberg Slide 36 18
Eksempel på verktøy Verktøy for: Utvikling (IDE Integrated Development Environment) Konfigurasjonsstyring/endringshåndtering Testing Diagramkonstruksjon Prosjektstyring Feil- og problemhåndtering (bug & issue tracking) Valg av verktøy er heller ikke trivielt! IN1030/ 14.3.2019 / Dag Sjøberg Slide 37 Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 38 19
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 Normativ (preskriptiv) beskriver en prosess slik noen mener den bør være (vanligste betydning), dvs. oppskrift på hvordan jobbe Deskriptiv beskriver en prosess slik vi mener vi utfører den IN1030/ 14.3.2019 / Dag Sjøberg Slide 39 Formell versus reell prosess Prosessbeskrivelse IN1030/ 14.3.2019 / Dag Sjøberg Prosessutførelse Slide 40 20
Nivåer av prosessmodeller Generelle prosessmodeller (fossefall, Scrum, Kanban etc.) Definerte prosessmodeller (formell prosess) Firma-spesifikke prosessmodeller Prosjekt/gruppe-spesifikke prosessmodeller Prosess-samsvar ( Process compliance ) Reell prosess Systemutviklingsprosess IN1030/ 14.3.2019 / Dag Sjøberg Slide 41 Hvordan tilpasse prosesser? Prosesser må tilpasses ingen prosjekter er like Mange faktorer påvirker prosessen Hva kan tilpasses? Faser/aktiviteter, roller, ansvarsforhold, utforming/frekvens på rapporter og gjennomganger Hvordan tilpasse? Identifiser prosjektomgivelser utviklingsstrategi, risiko, krav, applikasjonsområde, type kunde etc. Innhent synspunkter fra utviklere, brukere, kunder Definer prosesser, aktiviteter og roller Begrunn og dokumenter tilpasningene IN1030/ 14.3.2019 / Dag Sjøberg Slide 42 21
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 43 Fossefallsmodellen klassisk ingeniørtilnærming Sivilingeniørprosjekter (bygg & anlegg) er plandrevet, dvs. relativt mye tid på planlegging og utviklingen dokumenter som styrer prosjektet Separate faser Vanskelig å tilpasse endringer i krav underveis IN1030/ 14.3.2019 / Dag Sjøberg Slide 44 22
Fossefallsmodellen Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance I prinsippet går man ikke tilbake til tidligere hovedaktiviteter før systemet er satt i drift. IN1030/ 14.3.2019 / Fra Dag Ian Sjøberg Sommerville Slide 45 Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 46 23
Behov for smidighet Klassisk ingeniørtilnærming vist seg ofte å ikke være egnet Derfor er smidige metoder nå blitt det normale 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 IN1030/ 14.3.2019 / Dag Sjøberg Slide 47 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 IN1030/ 14.3.2019 / Dag Sjøberg Slide 48 24
Inkrementell utvikling i smidige metoder Systemet utvikles gradvis i form av tillegg av nye inkrementer. Hvert inkrement evalueres av en bruker- eller kunderepresentant (produkteier) før neste inkrement utvikles Viktigste krav utvikles først Når utviklingen av et inkrement er startet, så fryses kravene til det inkrementet. Krav til senere inkrementer kan fortsatt endres IN1030/ 14.3.2019 / Dag Sjøberg Slide 49 Plandrevne (tunge) prosesser Smidige (lette) 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) Planleggingen gjøres litt etter litt Enklere å endre prosessen for å tilpasse endrede krav fra kunden Fokuserer mer på fundamentale prinsipper (f.eks. kontinuerlig testing ). Har færre formelle dokumenter IN1030/ 14.3.2019 / Dag Sjøberg Slide 50 25
En samling software-guruer i 2001: Agile Manifesto 12 prinsipper* *http://agilemanifesto.org og http://agilemanifesto.org/iso/no/principles.html IN1030/ 14.3.2019 / Dag Sjøberg Slide 51 Agile Manifesto 2001 (forts.) *http://agilemanifesto.org og http://agilemanifesto.org/iso/no/principles.html IN1030/ 14.3.2019 / Dag Sjøberg Slide 52 26
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 53 Prosessprinsipp: Timeboxing versus task-boxing / task-flyt Tidsbokser (Scrum) Velg noen prioriterte oppgaver og jobb med dem i faste tidsintervaller (tidsbokser*) med definerte oppstarts- og avslutningsaktiviteter Flyt av oppgaver (Kanban) Definerer et sett med oppgaver eller features som skal lages, og lever så snart man er ferdig. Oppgaver skal flyte uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige ( oppgaveboksing ) *Tidsboks: en fast tidsperiode som et gitt arbeid skal være ferdig innenfor IN1030/ 14.3.2019 / Dag Sjøberg Slide 54 27
Scrum analogi fra rugby IN1030/ 14.3.2019 / Dag Sjøberg Slide 55 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 hjelpfunksjoner og brukermanualer fullføres, og man oppsummerer hva man har lært i prosjektet IN1030/ 14.3.2019 / Dag Sjøberg Slide 56 28
Scrum I sprint-planleggingsmøtet evalueres oppgavelisten (sprint 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 Gjennomføring Utviklingsteam og kunde velger egenskaper og funksjonalitet som skal utvikles i sprinten Planlegging Outline planning and architectural design Input: Product backlog liste av arbeidsoppgaver (Work Items) som skal utføres i prosjektet Assess Review Resultatene og teamarbeidet evalueres mot målene som ble satt i sprint-planleggingsmøtet ( retrospective ), og ferdigstilt funksjonalitet presenteres for kundene ( demo ) Select Develop Sprint cycle 2-4 uker (iterasjon) Avslutning Project closure IN1030/ 14.3.2019 / Dag Sjøberg Slide 57 Lag dokumentasjon (hjelpefunksjoner, brukermanualer) og oppsummer hva man lærte Design, koding, testing. Utviklingsteamet isoleres fra kunden og organisasjonen, dvs. all kommunikasjonen skjer via Product Owner/ Scrum Master for å unngå forstyrrelser 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 IN1030/ 14.3.2019 / Dag Sjøberg Slide 58 29
Visualisering Noter en oppgave eller arbeidspakke på en gul lapp og sett den på en tavle User stories US5 US4 US3 US1 US2 IN1030/ 14.3.2019 / Dag Sjøberg Slide 59 (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 fortløpende og kan gi tilbakemelding på hvordan deler av systemet fungerer Tillit mellom kunder og utviklere kan etableres tidlig Kryss-funksjonelle team (kompetansene på ulike områder finnes innen teamet) sikrer framdrift og reduserer risiko Mer om teamarbeid i Scrum på forelesningen 25. april IN1030/ 14.3.2019 / Dag Sjøberg Slide 60 30
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 61 Kanban Fokus på å få oppgaver (arbeidspakker) raskt utført = 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 av tid og kostnader *Spesielt interesserte kan lese om WIP i et norsk firma (ikke pensum): SJØBERG, Dag IK. An empirical study of WIP in kanban teams. In: Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. Oulu, Finland, ACM, 2018. p. 13. IN1030/ 14.3.2019 / Dag Sjøberg Slide 62 31
Scrum board versus Kanban board Max WIP From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009 IN1030/ 14.3.2019 / Dag Sjøberg Slide 63 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 *Sommerville diskuterer ikke flytbasert utvikling (Kanban). Temaet er likevel viktig IN1030/ 14.3.2019 / Dag Sjøberg Slide 64 32
Læremidler Kap. 1: introduksjon Plan for forelesningen Hva er systemutvikling og hvorfor lære om det? Eksempel på systemutvikling Kap. 2: Systemutviklingsprosessen hvordan jobbe smart i ITprosjekter Prosessmodeller (modeller for systemutviklingsprosesser) Fossefallsmodellen Kap. 3: Smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Eksempler på praksiser ved smidig utvikling IN1030/ 14.3.2019 / Dag Sjøberg Slide 65 Refaktorering (forbedring) Forbedre koden selv om ikke umiddelbart behov for dem Koden mer forståelig og enklere å endre, og mindre behov for dokumentasjon (mer vedlikeholdbar) 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 Dårlig kode vil ha teknisk gjeld IN1030/ 14.3.2019 / Dag Sjøberg Slide 66 33
Parprogrammering 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 Kan brukes uavhengig av smidige metoder IN1030/ 14.3.2019 / Dag Sjøberg Slide 67 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. Verdens største eksperiment i software engineering med 300 profesjonelle utviklere som deltakere *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 IN1030/ 14.3.2019 / Dag Sjøberg Slide 68 34
160 % Total Effect of PP Difference from individuals 140 % 120 % 100 % 80 % 60 % 40 % 20 % 0 % 84 % 7 % -20 % -40 % -8 % Duration Effort Correctness Correctness = Prosent flere riktige løsninger enn hos individuelle programmerere IN1030/ 14.3.2019 / Dag Sjøberg Slide 69 160 % Moderating Effect of System Complexity on PP Difference from individuals 140 % 120 % 100 % 80 % 60 % 40 % 20 % 0 % CC (easy) DC (complex) 6 % 60 % 112 % 48 % -20 % -40 % -20 % -16 % Duration Effort Correctness IN1030/ 14.3.2019 / Dag Sjøberg Slide 70 35
160 % Effect of PP for Juniors 140 % Difference from individuals 120 % 100 % 80 % 60 % 40 % 20 % 0 % 5 % 111 % 73 % -20 % -40 % Duration Effort Correctness IN1030/ 14.3.2019 / Dag Sjøberg Slide 71 Difference from individuals 160 % 140 % 120 % 100 % 80 % 60 % 40 % 20 % 0 % Moderating Effect of System Complexity for Juniors CC (easy) DC (complex) 4 % 6 % 109 % 112 % 32 % 149 % -20 % -40 % Duration Effort Correctness IN1030/ 14.3.2019 / Dag Sjøberg Slide 72 36
160 % Effect of PP for Seniors Difference from individuals 140 % 120 % 100 % 80 % 60 % 40 % 20 % 0 % -20 % -9 % 83 % -8 % -40 % Duration Effort Correctness IN1030/ 14.3.2019 / Dag Sjøberg Slide 73 Difference from individuals 160 % 140 % 120 % 100 % 80 % 60 % 40 % 20 % 0 % -20 % -40 % Moderating Effect of System Complexity for Seniors CC (easy) DC (complex) -23 % 8 % 55 % 115 % -13 % -2 % Duration Effort Correctness IN1030/ 14.3.2019 / Dag Sjøberg Slide 74 37
Effekten av å bruke parprogrammering kommer an på Programmeringsekspertise Oppgavekompleksitet Bruke PP? Kommentar Junior Mellomnivå Lett Ja Gitt at hovedmålet er god kvalitet Vanskelig Ja Gitt at hovedmålet er god kvalitet Lett Nei Vanskelig Ja Gitt at hovedmålet er god kvalitet Senior Lett Vanskelig Nei Nei* * Med mindre oppgaven er svært for vanskelig, selv for en senior IN1030/ 14.3.2019 / Dag Sjøberg Slide 75 Oppsummering Software engineering er læren om utvikling og forvaltning av programvaresystemer av høy kvalitet innen gitte tidsog kostnadsrammer Finnes mange ulike kriterier for prosjekt- og systemkvalitet Ulike prosessegenskaper vil påvirke prosjekt- og systemkvaliteten Valg av prosess vil avhenge av hvilke kvalitetsaspekter man ønsker å vektlegge Det å jobbe smart, dvs. ha gode og effektive arbeidsprosesser vil alltid være et aktuelt tema IN1030/ 14.3.2019 / Dag Sjøberg Slide 76 38
Takk for i dag! IN1030/ 14.3.2019 / Dag Sjøberg Slide 77 39