Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

Transkript

1 Prosessmodeller og smidig programvareutvikling INF1050: Gjennomgang, uke 02

2 Kompetansemål Prosessmodeller Kunne redegjøre for hva som kjennetegner ulike prosessmodeller Vurdere prosesser for utvikling av ulike typer systemer Drøfte fordeler og ulemper Smidig utvikling Redegjøre for de ulike konseptene som inngår i smidig utvikling Struktur, roller, arbeidsmetoder

3 Gjennomgang av ukesoppgaver Ukens tema: Prosessmodeller og smidig utvikling

4 Oppgave 1 Hvorfor er det hensiktsmessig å definere prosessmodeller på ulike nivåer (generelle, bedriftsnivå, avdeling/prosjektnivå)?

5 Oppgave 1: Løsningsforslag Hvorfor er det hensiktsmessig å definere prosessmodeller på ulike nivåer (generelle, bedriftsnivå, avdeling/prosjektnivå)? Først: Hva er en prosessmodell? Abstrakt / forenklet modell Aktivitetene som utføres for å utvikle et datasystem Definerer hvordan man skal strukturere arbeidsprosessen i et prosjekt Normativ Beskriver en prosess slik den bør være

6 Oppgave 1: Løsningsforslag Hvorfor er det hensiktsmessig å definere prosessmodeller på ulike nivåer (generelle, bedriftsnivå, avdeling/prosjektnivå)? Ingen prosjekter er like Nødvendig å tilpasse prosessen etter det gitte prosjektet Mindre abstrakt Fra generelle modeller (fossefall/scrum) til bedrifts- eller prosjektspesifikke modeller Skreddersydd til den aktuelle konteksten Følgende kan tilpasses Faser / aktiviteter / roller / ansvarsforhold Dokumentformater / formalitet / frekvens på rapportering og gjennomganger

7 Oppgave 2(a) Beskriv fossefallsmodellen

8 Oppgave 2(a): Løsningsforslag Beskriv fossefallsmodellen Plandrevet prosessmodell Utviklingen styres av forhåndsspesifiserte planer Separate, veldefinerte faser Kravspesifisering Design (av system og programvare) Implementasjon (og enhetstesting) Integrasjon (og systemtesting) Drift (installasjon og vedlikehold)

9 Oppgave 2(a): Løsningsforslag Beskriv fossefallsmodellen

10 Oppgave 2(a): Løsningsforslag Beskriv fossefallsmodellen Hva skjer når vi er ferdig med en fase? Arbeidsflyt ved endt fase Avvik mellom prinsipp og praksis Prinsipp Beveg deg nedover modellen, til neste aktivitet. Ikke tilbake Praksis Kan forekomme overlapp i aktiviteter

11 Oppgave 2(b) Redegjør for forskjellene mellom smidig og plandrevet utvikling.

12 Oppgave 2(b): Løsningsforslag Redegjør for forskjellene mellom smidig og plandrevet utvikling Hovedpunkter som skiller smidig fra plandrevet utvikling Planlegging Hvordan fokuseres arbeidsinnsatsen? Kravendring Hva skjer hvis kravene må endres/kommer frem? Formalitet og dokumentasjon Roller, ansvarsområder og rapportering

13 Oppgave 2(b): Løsningsforslag Redegjør for forskjellene mellom smidig og plandrevet utvikling

14 Oppgave 2(c) Foreslå et utviklingsprosjekt der det kan være gunstig å benytte fossefallsmodellen. Begrunn svaret.

15 Oppgave 2(c): Løsningsforslag Foreslå et utviklingsprosjekt der det kan være gunstig å benytte fossefallsmodellen. Begrunn svaret. Først: Kjennetegn ved fossefallsmodellen Utviklingen styres av planer Separate faser for de ulike aktivitetene Går vanligvis ikke tilbake til tidligere faser Utfordrende å tilpasse endringer i brukerkrav underveis i utviklingen Planene er allerede definerte og vedtatt

16 Oppgave 2(c): Løsningsforslag Foreslå et utviklingsprosjekt der det kan være gunstig å benytte fossefallsmodellen. Begrunn svaret. Derfor: Fossefallsmodellen er gunstig for prosjekter hvor... Systemet er velkjent Kravspesifikasjonen er godt forstått / kravene er stabile Store geografiske avstander mellom utviklere Sikkerhetskritiske systemer (konsekvensene kan være fatale) Stilles krav til en komplett kravspesifikasjon før utviklingen starter Eksempel: Ulike transport-, trafikk- og navigasjonssystemer

17 Oppgave 3 Nevn noen praksiser som blir benyttet i Extreme Programming.

18 Oppgave 3: Løsningsforslag Nevn noen praksiser som blir benyttet i Extreme Programming. Først: Hva er ekstrem programmering (XP)? XP = Programmeringsfokusert og smidig metode Ekstrem fordi: Hele systemet kan bygges opp flere ganger daglig Inkrementer leveres jevnlig til kunden (annenhver uke) Tester kjøres før hver bygging (build) Build en aksepteres kun hvis testene lykkes / passerer

19 Oppgave 3(a): Løsningsforslag Nevn noen praksiser som blir benyttet i Extreme Programming. Små releaser og inkrementell planlegging Lag først minste settet funksjonalitet som gir verdi for kunden Lever hyppige inkrementer Enkelt design Design kun det som er nødvendig Refaktorering (refactoring) Kontinuerlig forbedring / restrukturering av koden Selv før behovet oppstår Reorganisering av klasser / Forbedring av navn på attributter og metoder

20 Oppgave 3(a): Løsningsforslag Nevn noen praksiser som blir benyttet i Extreme Programming. Kunde på stedet Representant for sluttbruker / kunde bør være tilgjengelig for utviklere hele tiden Parprogrammering To programmerere utvikler kode sammen (fører og kartleser) Holdbart tempo Unngå å jobbe overtid, da det kan føre til dårligere kode og redusert produktivitet "Test-først"-prinsippet Skriv tester for ny funksjonalitet før funksjonaliteten implementeres

21 Oppgave 4(a) Hva er Scrum?

22 Oppgave 4(a): Løsningsforslag Hva er Scrum? Smidig utviklingsmetode Arbeid deles opp i sprinter (varighet på 2-4 uker) Definerte faser i Scrum Planleggingsfasen Overordnede mål etableres / arkitektur designes Gjennomføringsfasen Serie med iterasjoner Sprinter Hver iterasjon leverer et inkrement av systemet Avslutningsfasen Dokumentasjon og manualer ferdigstilles

23 Oppgave 4(a): Løsningsforslag Hva er Scrum?

24 Oppgave 4(a): Løsningsforslag Hva er Scrum? Definerte roller i Scrum Produkteier Product Owner Utviklerteam Development Team Scrum Master Tett og kontinuerlig kommunikasjon gjennom daglige standups Hva har jeg gjort siden sist? Hva skal jeg gjøre i dag? Hvilke hindringer / utfordringer har jeg?

25 Oppgave 4(b) Hva er en sprint, og hvilke faser består den av?

26 Oppgave 4(b): Løsningsforslag Hva er en sprint, og hvilke faser består den av? Sprint Iterasjon i gjennomføringsfasen Forhåndsbestemt varighet Normalt 2-4 uker Hver iterasjon leverer et inkrement av systemet Utvikler funksjonalitet som leveres til kunden etter hver sprint Faser i sprinten Assess / Select / Develop (implementasjon) / Review (evaluering)

27 Oppgave 4(b): Løsningsforslag Hva er en sprint, og hvilke faser består den av?

28 Oppgave 4(b): Løsningsforslag Hva er en sprint, og hvilke faser består den av? Assess Vurderer nye/eksisterende oppgaver fra oppgavelisten (backlog) Select Setter mål for sprinten / Kunden kan komme med nye krav Velger oppgaver til sprinten Fokus på de høyest prioriterte oppgavene Develop Design / Koding / Testing Utviklerne isoleres fra kunden og organisasjonen Review Resultatene evalueres opp mot målene som ble satt i planleggingsmøtet Presenterer resultatene til kunden Retrospective

29 Oppgave 4(c) Hva er en Scrum Master?

30 Oppgave 4(c): Løsningsforslag Hva er en Scrum Master? Scrum Master En slags guru og ekspert på Scrum Tilrettelegger for utviklerteamet Sørger for at Scrum-teori følges i praksis Forstår alle hva Scrum er? Følges Scrum-prinsippene? Ansvarlig for å holde daglige standups Hva har jeg gjort siden sist? / Hva skal jeg gjøre i dag? Beskytte utviklere mot forstyrrelser (eksempelvis fra kunder)

31 Oppgave 4(d) Hva er en backlog?

32 Oppgave 4(d): Løsningsforslag Hva er en backlog? Scrum backlog En slags to-do -liste Prioritert liste med arbeidsoppgaver og funksjonalitet Inneholder som regel Beskrivelse / Prioriteringsgrad / Estimat / Verdi Av hver oppgave Funksjoner / Bugs Teknisk arbeid som må utføres (eksempelvis koding) Vedlikeholdes av produkteieren (Product Owner) Består ofte av en samling av brukerhistorier

33 Oppgave 5(a) Hva er Kanban?

34 Oppgave 5(a): Løsningsforslag Hva er Kanban? Kanban Rammeverk med rot i lean production Baserer seg på prinsipper fra Toyota Studerte dagligvarekjeder og deres forhold til lagerbeholdninger Kunder pleier vanligvis å kjøpe det nødvendige; ikke mer Dagligvarekjeder bestiller kun det de forventer å selge; ikke mer Med andre ord Produser kun det som er nødvendig; ikke mer

35 Oppgave 5(a): Løsningsforslag Hva er Kanban? Mål: Et system for å opprettholde et høyt produksjonsnivå Jobber med en oppgave til man er ferdig med den Pull fremfor push Just-in-time: Når man er ferdig med en oppgave etterspørres en ny (pull) Setter ikke nødvendigvis tid for oppgaven Oppgaver skal flyte uten avbrudd gjennom de nødvendige aktivitetene Mindre fokus på estimering

36 Oppgave 5(a): Løsningsforslag Hva er Kanban? Problemhåndtering underveis Stopp produksjonen Fokus på å løse problemet Gjenoppta normal produksjon etter at problemet er løst Sikrer god flyt og gjennomstrømningshastighet Utfører ikke flere oppgaver enn det teamet har kapasitet til WIP (Work in progress) begrenser antall oppgaver som kan utføres til enhver tid Unngå flaskehalser

37 Oppgave 5(b) Beskriv forskjellene på Scrum og Kanban.

38 Oppgave 5(b): Løsningsforslag Beskriv forskjellene på Scrum og Kanban. Scrum Time-boxing Definerer tidsbokser som oppgaver skal utføres innen Tydeligere definerte faser og roller utviklingen Utfordring: Kan være vanskelig å dele inn oppgaver i sprinter Kanban Task-boxing Definerer et sett med arbeidsoppgaver og leveres så snart man er ferdig Fokus på gjennomstrømningshastighet Slakk i tidsplanen kan aksepteres

39 Oppgave 6 Foreslå et utviklingsprosjekt der det kan være gunstig å benytte smidig utvikling. Begrunn svaret.

40 Oppgave 6: Løsningsforslag Foreslå et utviklingsprosjekt der det kan være gunstig å benytte smidig utvikling. Begrunn svaret. Kjennetegn for smidig utvikling Planlegging gjøres inkrementelt Enklere å endre prosessen ved endringer i krav De delene som må endres er mindre sammenlignet med plandrevet utvikling Derfor gunstig ved Utvikling av nye/innovative ideer Små utviklingsteam og prosjekter Prosjekter med betydelig sannsynlighet for at kravspesifikasjonen endres

41 Oppgave 7: Diskusjon Et system utvikles i henhold til en presis og detaljert kravspesifikasjon skrevet av kunden. Systemutviklere har argumentert for å bruke fossefallsmodellen. Det er først under testing at kunden begynner å ane at det var mangler ved kravspesifikasjonen. Systemet tas i bruk og brukerne oppdager at systemet er ubrukelig fordi det ikke løser deres problem. Hva kunne vært gjort for å hindre/redusere dette problemet?

42 Oppgave 7: Diskusjon Hva kunne vært gjort for å hindre/redusere dette problemet? Levere inkrementelt La brukere prøve tidlige versjoner av systemet, gjerne i naturlige omgivelser (miljø) Utviklere får bekreftet / avkreftet hvorvidt de er på rett vei Tidligere oppdagelse av mangler / feil Involvere kunden i større grad Forstå hvilke problemer kunden egentlig trenger å få løst Vet kunden hva de vil ha? Har utviklerne faktisk laget dette?

43 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

44 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

45 Takk for meg Neste uke : Kravhåndtering