Prøveeksamen INF1050: Gjennomgang, uke 15

Like dokumenter
Gjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Konfigurasjonsstyring

Oppgave 1: Multiple choice (20 %)

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

UNIVERSITETET I OSLO

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

Forskningsmetoder. INF1050: Gjennomgang, uke 13

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Eksamen INF1050: Gjennomgang, uke 15

Kravhåndtering. INF1050: Gjennomgang, uke 03

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

Use Case-modellering. INF1050: Gjennomgang, uke 04

UKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Forside Eksamen INF1055 V17

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16

UNIVERSITETET I OSLO

1. Hvilke type krav angår sikkerhet og pålitelighet?

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

1. Hvilke type krav angår sikkerhet og pålitelighet?

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Fra krav til objekter. INF1050: Gjennomgang, uke 05

UKE 11 UML modellering og use case. Gruppetime INF1055

UNIVERSITETET I OSLO

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.

Systemarkitektur. INF1050: Gjennomgang, uke 07

Oppgave 1 Multiple Choice

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Eksamen 2013 Løsningsforslag

Modellering av krav. INF1050: Systemutvikling 11. februar Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Løsningsforslag Sluttprøve 2015

GJENNOMGANG UKESOPPGAVER 9 TESTING

Modellering IT konferanse

Kontrakter. INF1050: Gjennomgang, uke 12

GJENNOMGANG OBLIGATORISK OPPGAVE 1

Testing av programvare. INF1050: Gjennomgang, uke 08

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Obligatorisk oppgave 5: Modellering av krav

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise IMT2243 : Systemutvikling 1

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKE 10 Kravhåndtering. Gruppetime INF1055

Fra krav til modellering av objekter

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Inf1055 Modul B 26 april 2017:

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Hensikten med denne delen av kurset. Objektorientering hva er det? Objektets egenskaper. Best practises ved programvareutvikling

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Gruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0>

Conference Centre Portal (CCP)

11 Planlegging og dokumentasjon

Eksamen INF

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UML-Unified Modeling Language

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Teamarbeid og smidig metodikk. Lean og Scrum. Prosjektarbeid

Forelesning IMT mars 2011

t Institutt for informatikk Erik Arisholm 13. mai 2009 INF1050-oppsummering-1

Lykke til! Eksamen i fag TDT4140 Systemutvikling NTNU Norges teknisk-naturvitenskapelige universitet

Kap 11 Planlegging og dokumentasjon s 310

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise IMT2243 : Systemutvikling 1

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

Estimering. INF1050: Gjennomgang, uke 09

Prosjektledelse, prosjektplanlegging, teamarbeid

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process

Prosessmodeller og smidig programvareutvikling

Prosjektledelse, prosjektplanlegging, teamarbeid

Prosessmodeller og smidig programvareutvikling

IN2001: Kravhåndtering, modellering, design

Systemutvikling (Software Engineering) Professor Alf Inge Wang

UKEOPPGAVER 13: KONFIGURASJONSSTYRING

Gruppe 43. Hoved-Prosjekt Forprosjekt

Hvordan evaluerer man kvaliteten på et IT-system?

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering. av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe

Altinns nye tjenesteverksted. Lars Vegard Bachmann, produkteier portal og tjenester, Altinn

Prosjektledelse, prosjektplanlegging, teamarbeid

UML 1. Use case drevet analyse og design Kirsten Ribu

Livsløpstesting av IT-systemer

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder.

Prosjektrettet systemarbeid

Velkommen til andre del av IN1030

Testing av programvare

INF1050 Systemutvikling

Transkript:

Prøveeksamen 2016 INF1050: Gjennomgang, uke 15

Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk

Multiple Choice

Oppgave 1.1 Hvilket av følgende krav til en billettautomat er funksjonelt? a. Utskrift av en billett skal ikke ta mer enn 5 sekunder b. Teksten på skjermen skal være svart med hvit bakgrunn c. Det skal være valg for utskrift av kvittering d. Koden skal være enkel å endre

Oppgave 1.1: Løsningsforslag Hvilket av følgende krav til en billettautomat er funksjonelt? a. Utskrift av en billett skal ikke ta mer enn 5 sekunder b. Teksten på skjermen skal være svart med hvit bakgrunn c. Det skal være valg for utskrift av kvittering d. Koden skal være enkel å endre

Oppgave 1.1: Notat Kunne redegjøre for ulike typer krav Funksjonelle Ikke-funksjonelle Pensum Forelesning: 31.01.17 Kravhåndtering Gjennomgang: Uke03 - Kravhåndtering

Oppgave 1.2 Et eksperiment i systemutvikling brukes til å... a. Kartlegge virkningen av å bruke bestemt teknologi b. Finne utviklernes mening om hvor god en teknologi er c. Studere en teknologi i dybden i et prosjekt d. Intervjue utviklere som bruker teknologi

Oppgave 1.2: Løsningsforslag Et eksperiment i systemutvikling brukes til å... a. Kartlegge virkningen av å bruke bestemt teknologi b. Finne utviklernes mening om hvor god en teknologi er c. Studere en teknologi i dybden i et prosjekt d. Intervjue utviklere som bruker teknologi

Oppgave 1.2: Notat Kunne redegjøre for ulike forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Pensum Forelesning: 18.04.17 Forskningsmetoder Gjennomgang: Uke13 - Forskningsmetoder

Oppgave 1.3 Et inkrement i inkrementell utvikling indikerer... a. Et tillegg i programvaren b. En iterasjon i smidig utvikling c. Et tillegg i kravspesifikasjonen d. En milepæl for prosjektet

Oppgave 1.3: Løsningsforslag Et inkrement i inkrementell utvikling indikerer... a. Et tillegg i programvaren b. En iterasjon i smidig utvikling c. Et tillegg i kravspesifikasjonen d. En milepæl for prosjektet

Oppgave 1.4 Validering i testing av programvare betyr å teste at... a. Komponenter og delsystemer fungerer sammen b. Produktet bygges på riktig måte c. Systemet gjør det brukeren ønsker d. Systemet er robust

Oppgave 1.4: Løsningsforslag Validering i testing av programvare betyr å teste at... a. Komponenter og delsystemer fungerer sammen b. Produktet bygges på riktig måte c. Systemet gjør det brukeren ønsker d. Systemet er robust

Oppgave 1.4: Notat Kunne redegjøre for ulike testtyper og deres formål Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting Hvorfor tester vi? Pensum Forelesning: 07.03.17 Testing Gjennomgang: Uke08 - Testing

Oppgave 1.5 Hva representerer en valgdiamant i et aktivitetsdiagram? a. For-løkke b. Class c. While-løkke d. If-then-else -test

Oppgave 1.5: Løsningsforslag Hva representerer en valgdiamant i et aktivitetsdiagram? a. For-løkke b. Class c. While-løkke d. If-then-else -test

Oppgave 1.5: Notat Kunne redegjøre for ulike UML-diagrammer Use case-diagrammer Sekvensdiagrammer Klassediagrammer Aktivitetsdiagrammer Tilstandsdiagrammer Pensum Forelesning: 07.02.2017 / 14.02.2017 / 21.02.2017 UML Gjennomgang: Uke04 / Uke05 / Uke06 - UML

Oppgave 1.6 Hva er en baseline? a. En kontrollert konfigurasjon av komponenter som fungerer som plattform for videreutvikling b. Et element som er under konfigurasjonskontroll c. En sekvens av mainlines d. En sekvens av branches

Oppgave 1.6: Løsningsforslag Hva er en baseline? a. En kontrollert konfigurasjon av komponenter som fungerer som plattform for videreutvikling b. Et element som er under konfigurasjonskontroll c. En sekvens av mainlines d. En sekvens av branches

Oppgave 1.6: Notat Kunne redegjøre for hva konfigurasjonsstyring innebærer Hovedaktiviteter Systembygging Versjonhåndtering Endringshåndtering Relsease-håndtering Sentrale begreper Pensum Forelesning: 28.03.2017 Konfigurasjonsstyring Gjennomgang: Uke11 - Konfigurasjonsstyring

Oppgave 1.7 Hva er den viktigste kvalitetsdimensjonen? a. Pålitelighet b. Brukskvalitet c. Vedlikeholdbarhet d. Varierer, må avgjøres av interessentene (stakeholders) for et gitt prosjekt /system

Oppgave 1.7: Løsningsforslag Hva er den viktigste kvalitetsdimensjonen? a. Pålitelighet b. Brukskvalitet c. Vedlikeholdbarhet d. Varierer, må avgjøres av interessentene (stakeholders) for et gitt prosjekt /system

Oppgave 1.8 Hva kjennetegner EDA (Event-Driven Architecture)? a. Cloud services b. Fysisk arkitektur c. Agenter som subscriber/lytter på hendelser d. Et abstrakt klassehierarki

Oppgave 1.8: Løsningsforslag Hva kjennetegner EDA (Event-Driven Architecture)? a. Cloud services b. Fysisk arkitektur c. Agenter som subscriber/lytter på hendelser d. Et abstrakt klassehierarki

Oppgave 1.8: Notat Kunne redegjøre for aspekter ved systemarkitektur Ulike views Lagdeling Fysisk og logisk Arkitektoniske stiler Pensum Forelesning: 28.02.2017 Systemarkitektur Gjennomgang: Uke07 - Systemarkitektur

Oppgave 1.9 Hvilket av følgende prinsipper er ikke del av LEAN utvikling? a. Kundefokus b. Fokus på flyt ( flow ) c. Unngå sløsing ( waste ) d. Bruk av tidsbokser

Oppgave 1.9: Løsningsforslag Hvilket av følgende prinsipper er ikke del av LEAN utvikling? a. Kundefokus b. Fokus på flyt ( flow ) c. Unngå sløsing ( waste ) d. Bruk av tidsbokser

Oppgave 1.9: Notat Kunne redegjøre for ulike prosessmodeller og metoder Prosessmodeller Prinsipper for utvikling Plandrevet og smidig Pensum Forelesning: 24.01.2017 Prosessmodeller Gjennomgang: Uke02 - Prosesser

Oppgave 1.10 Hva brukes i UML for spesifikasjon av grensesnitt (interface)? a. Sekvensdiagrammer b. Klassediagrammer c. Use case-diagrammer d. Tilstandsdiagrammer

Oppgave 1.10: Løsningsforslag Hva brukes i UML for spesifikasjon av grensesnitt (interface)? a. Sekvensdiagrammer b. Klassediagrammer c. Use case-diagrammer d. Tilstandsdiagrammer

Oppgave 1.10: Notat Kunne redegjøre for ulike UML-diagrammer Use case-diagrammer Sekvensdiagrammer Klassediagrammer Aktivitetsdiagrammer Tilstandsdiagrammer Pensum Forelesning: 07.02.2017 / 14.02.2017 / 21.02.2017 UML Gjennomgang: Uke04 / Uke05 / Uke06 - UML

Konfigurasjonsstyring

Oppgave 2(1) Hvorfor er konfigurasjonsstyring viktig?

Oppgave 2(1): Løsningsforslag Hvorfor er konfigurasjonsstyring viktig? Programvaresystemer er i konstant endring Systemer og kode kan bli veldig komplekse Lett å miste oversikten over endringer / versjoner Varierer fra versjon til versjon Ønsker kontroll over endringer Hva ble endret? Hvem har endret hva? Bringer kontroll over systemutviklingsprosessen! Forenkler teamarbeid og koordinering / Unngår endringsrelaterte problemer

Oppgave 2(2) Hva er distribuert versjonhåndtering?

Oppgave 2(2): Løsningsforslag Hva er distribuert versjonhåndtering? Versjonhåndtering Oversikt over ulike versjoner av et system og systemkomponenter Sørger for at endringer fra ulike utviklere ikke kolliderer med hverandre Distribuert versjonhåndtering Master repository ligger på en server Utviklere laster ned (pull) en klone til privat arbeidsområde Har nå tilgang til hele historien på egen maskin (Data + metadata) Endringer blir oppdatert privat gjennom commit Endringer oppdateres globalt ved push til master repository

Oppgave 2(3) Nevn noen viktige faktorer i endringsanalyse

Oppgave 2(3): Løsningsforslag Nevn noen viktige faktorer i endringsanalyse. Konsekvenser Hva skjer dersom foreslåtte endringer ikke følges opp? Fordeler / gevinst av foreslåtte endringer Brukere Hvem, hvor mange, berøres av de foreslåtte endringene? Kostnader knyttet til implementasjon av endringene Erfaringen til utviklerteamet Påvirker hvordan endringer håndteres

Oppgave 2(4) Hva er et repository?

Oppgave 2(4): Løsningsforslag Hva er et repository? Lagringsplass Kildekode / Programvarekomponenter Verktøy for versjonhåndtering Oversikt over endringer som utføres Kan være Sentraliserte Distribuerte

Oppgave 2(5) Hva er systembygging?

Oppgave 2(5): Løsningsforslag Hva er systembygging? Bygging av systemet Setter sammen systemkomponentene Programvare Data Biblioteker Kompilering og integrering Skaper et fullstendig, kjørbart system

Oppgave 2(6) Nevn noen viktige faktorer som påvirker releaseplanlegging

Oppgave 2(6): Løsningsforslag Nevn noen viktige faktorer som påvirker releaseplanlegging. Release-håndtering og planlegging Forberede og ferdigstille programvare for ekstern utgivelse Oversikt over ulike versjoner som har blitt gitt til kunden Påvirkende faktorer Har kunden bruk for det (releasen)? Gir det kunden verdi i form av ny og nødvendig funksjonalitet eller forbedring? Er det en major (betydelig tillegg i funksjonalitet) eller minor release Hvordan ligger man an i forhold til konkurrentene?

Oppgave 3: Modellering av krav Du skal modellere deler av et web-basert system for kjøp av billetter til en fornøyelsespark. Billettene kjøpes på web, og du kan kjøpe ulike typer billetter. Alle billetter gjelder én bestemt dag. Det er også mulig å kjøpe billetter i luka, men dette skal ikke modelleres. Når det gjelder billetter til selve fornøyelsesparken, er det mest vanlige å kjøpe en billett som inkluderer alle attraksjoner, bortsett fra én; Air Fantasy. Denne må betales for separat og koster 100 kr per tur. Det er også mulig å kjøpe kun inngangsbillett (uten attraksjoner) for 100 kr.

Oppgave 3: Modellering av krav Ved bestilling av billetter på nett (inngangsbilletter med/uten attraksjoner, Air Fantasy, og billetter til mat) skal det være mulig å bestille et vilkårlig antall av hver type billett til vilkårlig mange dager (legg i handlekurv) før man går til betaling. Hvis du vil, kan du i det web-baserte systemet lage en profil med personlig informasjon og opplysninger om bankkort. Hvis du også legger inn ønsket brukernavn og passord slipper du å legge inn personlig informasjon og betalingsopplysninger hver gang du bruker systemet. Systemet har en betalingsmodul. Når betalingen er godkjent, blir billetten(e) tilgjengelige i PDF-format med en strekkode for hver billett som scannes ved inngangen og ved hver attraksjon, og eventuelt spisesteder.

Oppgave 3: Modellering av krav Følgende priser gjelder billetter inkludert attraksjoner: Over 120 cm: 400 kr Under 120 cm: 200 kr (noen av attraksjonene er ikke tilgjengelige) Senior (over 60 år): 200 kr I tillegg kan man kjøpe billett(er) til én eller flere turer med Air Fantasy. Følgende priser gjelder billetter til mat, som kan benyttes på to ulike steder Pizzastedet 300 kr for stor pizza 150 kr for liten pizza Burgersjappa 150 kr for stor burger 100 kr for liten burger

Oppgave 3(a) Lag et aktivitetsdiagram for Bestill billetter. Det skal være mulig å bestille (én eller flere) av alle typer billetter i vilkårlig rekkefølge.

Oppgave 3(a): Løsningsforslag Lager først en oversikt over aktiviteter Aktiviteter som inngår i Bestill billetter Velg dag Velg antall Både for alle attraksjoner eller kun inngangsbillett Velg antall for Air Fantasy Velg flere eller ferdig Velg mat Oppgi personopplysninger og betalingskort Opprett profil Hent / Se billett

Oppgave 3(a): Løsningsforslag Kartlegger hvordan aktivitetene henger sammen: Hvordan bestilles billetter? Først velges dag Deretter velges billettype Alle attraksjoner eller kun inngangsbillett? Air Fantasy -billetter? Kan kun kjøpes dersom du har en inngangsbillett Fortsett handelen? Ferdig eller flere: Nye billetter eller Matbilletter? Betaling Direkte? Registrer informasjon / Via innlogging eller opprett profil? Utfør betaling og hent billett(er)

Oppgave 3(a): Løsningsforslag

Oppgave 3(b) Lag et sekvensdiagram for Bestill billetter.

Oppgave 3(b): Løsningsforslag Lager først en tekstlig beskrivelse for Bestill billetter

Oppgave 3(b): Løsningsforslag

Oppgave 3(c) Lag et klassediagram for Bestill billetter som tilsvarer sekvensdiagrammet i oppgave (b). Ha med attributter, metoder, og assosiasjoner med multiplisitet.

Oppgave 3(c): Løsningsforslag

Oppgave 3: Fortsettelse Et typisk ikke-funksjonelt krav til systemet er brukskvalitet. Slike krav er ofte uttrykt svært generelt, noe som gjør det vanskelig for utviklingsteamet å teste om kravene innfris. For eksempel: Systemet skal være enkelt å bruke for alle typer brukere og organisert slik at brukerfeil forekommer minst mulig.

Oppgave 3(d) Beskriv dette kravet på en måte som gjør det mer testbart.

Oppgave 3(d): Løsningsforslag Beskriv dette kravet på en måte som gjør det mer testbart. Kravet må gjøres målbart Hva ønsker vi å måle? Hvor enkelt et system er Hvordan kan enkelthet karakteriseres? Tiden det tar for en bruker å gjennomføre et gitt bruksmønster Antall feil i gjennomføringen Definere metrikker for målene, med følgende spesifisert: Hvem? Hva? Hvordan?

Oppgave 3(d): Løsningsforslag Beskriv dette kravet på en måte som gjør det mer testbart. (*) Angir at kravet bør spesifiseres ytterligere

Oppgave 3(e) En av attraksjonene er kjøring av radiobil (for én person). Radiobilen kan stå stille eller være i bevegelse, enten forover eller bakover. For at radiobilen skal kunne settes i bevegelse, må det sitte en person i bilen og sikkerhetsbeltet må være festet. Når radiobilen er i bevegelse, er det ikke mulig å ta av sikkerhetsbeltet eller gå ut av radiobilen. Tegn et tilstandsdiagram for radiobilen.

Oppgave 3(e): Løsningsforslag Lager først en oversikt over tilstander Tilstander som inngår kjøring av radiobil Står stille (to ulike tilstander) Enten fordi du har festet sikkerhetsbeltet og er klar til å kjøre, Eller fordi sikkerhetsbeltet ikke er festet Kjører forover Tråkker på gassen Kjører bakover Setter bilen i revers

Oppgave 3(e): Løsningsforslag Deretter ser vi på tilstandsendringer Står stille (to ulike tilstander) Enten fordi du har festet sikkerhetsbeltet og er klar til å kjøre, Eller fordi sikkerhetsbeltet ikke er festet

Oppgave 3(e): Løsningsforslag Deretter ser vi på tilstandsendringer Kjører forover Tråkker på gassen

Oppgave 3(e): Løsningsforslag Deretter ser vi på tilstandsendringer Kjører bakover Setter bilen i revers

Oppgave 3(e): Løsningsforslag Gir oss tilstandsdiagrammet:

Oppgave 4: Smidig utvikling Anta at du er en konsulent som er leid inn til et prosjekt som har som hovedoppgave å rette feil i et stort og avansert system. Det viser seg at teamet som jobber med feilretting ikke klarer å rette alle feil som blir rapportert, raskt nok. Teamet bruker Scrum. Du har god erfaring fra bruk av Kanban fra tidligere og mener at Kanban også kan brukes i dette prosjektet. Argumenter for at teamet bør gå over til bruk av Kanban.

Oppgave 4: Løsningsforslag Argumenter for at teamet bør gå over til bruk av Kanban. Kanban Smidig Baserer seg på prinsipper fra Lean-produksjon Fokus på flyt av arbeidsoppgaver (Work in Progress, WIP) Just-in-time Sikre god og effektiv utførelse Waste Redusere tid- og ressursbruk på oppgaver som ikke har verdi for koden Teamets hovedoppgave er å rette feil Enklere å forholde seg til flyt fremfor avgrensede oppgaver innen et gitt tidsrom Kan legge til nye oppgaver når som helst I Scrum må iterasjoner fullføres Ledige utviklere trenger ikke vente på neste sprint

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.

Takk for meg Neste uke : Gjennomgang av oblig 3