Merk at besvarelsen ikke er rettet. Besvarelsen tilsvarte karakter C. Løsningsforslag eksamen 2023

Eksamen 2023

Oppgave 1. Begreper fra pensum (10 %)

For hvert av begrepene under skal du beskrive hva dette er:

• Code Reviews
• DevOps
• eXtreme Programming
• Ekvivalenspartisjonering

Code reviews innebærer at noen andre går over koden og sjekker at alt ser riktig ut og at koden som er skrevet gir mening. På denne måten kan man avdekke død kode eller andre uregelmessigheter før man tar det videre ut i testing. Dette er en billig måte å teste på, og reduserer kostnadene. Kan både gjøres av noen andre i teamet eller en ekstern part som er leid inn for å kvalitetssikre koden.

DevOps innebærer mer smidig utvikling. Dette innebærer at man koder med tanke på effektivitet og velger metoder som tillater at koden er så selvstendig som mulig. Man deler gjerne applikasjonen opp i services, (Microservices), slik at dersom en del av applikasjonen går ned vil resten av applikasjonen fremdeles fungere. Formålet med dette er at koden utvikles del for del, og hver del er fungerende med en gang den er ferdig utviklet. Man venter ikke på andre deler av applikasjonen. Fordelen er at man har flere baller i luften og får høyere effektivitet, men ulempen er at det kan bli mye å holde styr på, og mer arbeid dersom noe skulle gå ned.

Extreme programming er en smidig utviklingsmetode. Den er basert på 4 prinsipper, deriblant mot og respekt. Man koder i par, og fokuserer på å utvike raskt, samtidig som koden skal følge best practices. De baserer seg på ett sett med verdier (ofte nevnt 12 i pensum, men ifølge extremeprogramming.org finnes det noen flere). Likevel er det viktigste at alle som er med på utviklingsprosessen skal ha eierskap til koden. Man skal ha kunden i lokalet og nyanssatte skal ha samme mulighet til å endre på koden som mer erfarne i bedriften. Fordeler med dette er at man får inn nye tanker og innspill, og dermed får fornyet koden i henhold til nye best practices. Man fokuserer på å ofte ha små releaser med høy kvalitet, fremfor store releaser med lav kvalitet.

Ekvivalenspartisjonering innebærer at man deler opp applikasjonen i flere forskjellige like deler, som deretter kan kodes separat. Dette fører til mer smidig utvikling, og tillater at flere kan jobbe samtidig, uten at en del av applikasjonen holder tilbake de andre. Dette står i kontrast til for eksempel Fossefallsmodellen, hvor man koder en og en ting, og dermed automatisk blir nødt til å vente på at alt i hvert steg blir ferdig før man går videre.

Oppgave 2. Testing i programvareutviklingsprosjekter (10 %)

List opp og gi en kort beskrivelse av de ulike testtypene vi har dekket i emnet.

Black box Innebærer at man tester applikasjonen for å se om noe ikke fungerer. Testpersonen er ikke kjent med den underliggende koden,og har dermed kun mulighet til å kommentere på det hen ser, og ikke selve kildekoden. Formålet er å sjekke at applikasjonen gjør det samme som det ser ut som.

Står i kontrast til Black Box. Denne test typen innebærer at testeren kjenner kildekoden, og utfører tester for å se om kildekoden gjør det den skal. Formålet med White box testing er å avdekke bugs som Black box testing ikke vil finne. Dette vil også kunne finne død kode, som man ikke ellers ville oppdaget. Dette kan også avklare bugs dersom man ser noe rart i kildekoden til en feature, som man dermed kan prøve og sjekke hvordan påvirker selve brukergrensesnittet.

Unit test Enhetstesting innebærer at man tester at hver klasse / funksjon utfører det den skal. Dette gjøres ved å lage tester både med riktig input, og med feil input. Man må være kjent med hvilket resultat hver test skal gi dersom koden er riktig for å kunne avdekke feil her. Formålet er å teste både at koden responderer riktig dersom alt går greit, og at koden responderer riktig dersom noe går feil. Dette er tester som gjerne automatiseres ettersom de er blant de billigste å utføre, og dermed en av test typene man utfører oftest.

Systemtest Tester systemet i sin helhet, sjekker at hele koden fungerer som en sammenhengende applikasjon, og at det ikke finnes dårlige koblinger eller andre feil eller uklarheter i bindeleddene mellom forskjellige deler av applikasjonen.

Stresstest Innebærer at man bevisst overbelaster koden for å teste hvordan koden reagerer på unormalt store mengder trafikk. Formålet er både å bli kjent med grensene til applikasjonen, og å sikre at det ikke finnes kritiske feil dersom det er for mye trafikk. (F. eks ville det vært dumt dersom en butikk plutselig lot deg kjøpe en vare som de var tomme for, fordi den ikke sjekket beholdningen din først fordi den ikke fikk kontakt med databasen pga trafikken).

Brukertest Innebærer at en bruker tester applikasjonen, og sjekker at alt fungerer som tenkt. Formålet med dette er at utvikleren ser dersom noe er ulogisk eller det er noe brukeren ikke får til, som de kanskje må endre på i ettertid. Dette fører til bedre bruker opplevelse, og kan avdekke ting utviklerne ikke har tenkt på i utviklingsfasen.

Integrasjonstest Innebærer at man setter sammen en ny feature eller del av koden med resten av systemet, og sjekker at ingenting går galt. Formålet med dette er å teste både grensesnittet mellom den nye og allerede eksisterende delen av koden, samtidig som man også sjekker at det ikke har uventede konsekvenser for andre deler av koden.

Akseptansetest Innebærer at man tester helheten i applikasjonen. Dette vil si at man tester både at brukeren er fornøyd, at forretningslogikken i applikasjonen er logisk, og at applikasjonen fungerer som en helhet. Dette er som regel den siste testen man gjør før applikasjonen settes i drift. Dette vil kunne avdekke kritiske feil som at banktransaksjoner ikke går gjennom, og dermed dårlig business.

Oppgave 3. Programvarearkitektur (10%):

Fortell om hovedprinsippene innen hver av de to programvarearkitekturene Lagdeling (layer) og Mikrotjenester (microservices). Kommenter spesielt ulikheten knyttet til hvordan dataene håndteres og lagres.

Lagdeling Prinsippet med lagdeling er at applikasjonen deles inn i forskjellige logiske lag. For eksempel kan man ha ett lag med user interface, hvor f.eks kunden samhandler kun med nettleseren eller en mobilapplikasjon. Deretter sender brukergrensesnittet informasjonen videre til et mellomlag med tjenester som har hvert sitt ansvarsområde. For eksempel kan det være en klasse som er ansvarlig for lagerbeholdningen, og sender en request videre til en database. Databasen vil naturlig være i det nederste laget, ettersom det er her dataen ligger lagret. Til motsetning fra Microservice kan flere forskjellige funksjoner nå den samme databasen, og man har ikke nødvendigvis forskjellige databaser knyttet til hver klasse. Dette innebærer noe høyere koblinger, men fordelen er at koden er lettere å teste og vedlikeholde ettersom det er mindre som kan gå galt.

Microservices Mikrotjenester innebærer at applikasjonen deles opp i forskjellige services. Hver service kan sees på som en "egen kode", som kun samhandler med andre deler av applikasjonen via APIer. Hver service har sin egen database. Formålet med dette er at hver service er uavhengig av hverandre. Dette tilstreber høy styrke og lave koblinger. F. eks i en butikkapplikasjon kan lagerbeholdningen være en egen service. Det vil si at det er en egen database og et eget system som tar ansvar for lagerbeholdningen i applikasjonen, og dersom denne går ned vil fremdeles resten av applikasjonen fungere som normalt. Dette er grunnen til at man kan gå inn i en applikasjon og finne at kun en liten del av applikasjonen ikke fungerer. Det er da en microservice som har gått ned, mens resten av applikasjonen fremdeles fungerer som normalt.

Oppgave 4 a) Scrum (10%)

Beskriv de ulike møtene, rollene og artefaktene (informasjonsbærende elementene) som benyttes i Scrum-prosjekter og kommenter sammenhengene mellom dem.

Møter og artefakter

• Product backlog
• Sprint planning meeting
• Sprint backlog Sprint
• Daily scrum meeting Sprint review
• Sprint retrospective Scrum board

Roller

Scrum owner - Eieren av applikasjonen. Bestemmer hvilke features som bør prioriteres og hva som er det viktigste å få med i applikasjonen. Det er denne personen som har ansvar for de som skal bruke applikasjonen etter den er ferdig utviklet, og det er derfor viktig at man utvikler i henhold til denne personen, og stakeholderene sine tanker.

Scrum master - En person med mye erfaring med utvikling eller design av applikasjonen. Scrum master er gjerne en utvikler som koder sammen med resten av teamet, men denne personen har lang erfaring, og får i tillegg ansvar for oppfølging. Dette innebærer at hen til enhver tid i prosjektet skal ha oversikt over hvordan utviklingsteamet ligger an i forhold til tidsfrister, og ta tak i eventuelle problemer i teamet. Det innebærer at tid kan gis til kompetanseheving dersom de ligger foran tidsrammen, eller at man gir beskjed til resten av teamet om å sette inn et ekstra gir dersom man ligger bak tidsskjema. Denne personen har også ansvar for at teamet kommer overens med hverandre, og kan for eksempel kjøre teambuilding arrangementer dersom det er noen i teamet som ikke er komfortable med å snakke med hverandre etc.

Stakeholder Tredjeparter som har interesse av applikasjonen. Dette kan være eksterne sponsorer, eller interessenter som vurderer å ta i bruk løsningen hvis den blir en suksess, eller som har indirekte nytte av applikasjonen, slik som forskere som får data ut fra applikasjonen. Tankene deres blir hørt gjennom de forskjellige møtene som holdes, deriblant sprint planning meeting hvor de får sagt sine tanker og hva de tenker er viktig, og sprint review hvor de får sett den delen av applikasjonen som er utviklet til nå og hva som gjenstår av utviklingen. Her får de også mulighet til å komme med innspill dersom det er noe de vil endre eller noe de ikke er fornøyde med.

Team er utviklingsteamet på (helst) 5-9 personer. Disse personene har ansvar for selve utviklingen (kodingen) av applikasjonen, og er de som skal jobbe hver sprint med å utføre de forskjellige backlog itemene. Det er viktig at teamet er motivert for at utviklingen skal gå fremover, noe Scrum master skal følge med på og ta ansvar for.

Scrum starter med at man utvikler krav til applikasjonen. Dette kan eksempelvis gjøres i form av user stories, personas og scenarier. Deretter vil man lage en product backlog ut ifra dette. Product backloggen består av forskjellige features som man ønsker å integrere i applikasjonen eller bugs som man ønsker å rette opp i. Backloggen er veldig stor, derfor har man et sprint planning meeting, hvor man deler backloggen opp i forskjellige deler, som etterhvert blir sine egne sprint backlogs. Det er viktig at man plukker ut det som må på plass først til å begynne med, og at man plukker ut det som henger sammen samtidig. Hver sprint backlog blir utviklet i løpet av sin egen sprint. En sprint varer typisk i 1-4 uker, hvor 2-3 er optimalt. Lengden er likevel basert på omfanget av applikasjonen. Man velger ønsket lengde i starten av prosjektet, og holder denne lengden så lenge som mulig. Dersom man i løpet av et sprint review finner ut at lengden på sprinten er for lang eller kort har man mulighet til å endre dette, men man ønsker å endre så få ganger som mulig ettersom endringer fører til at strukturen blir mindre oversiktlig.

En sprint har gjerne et scrum board, dette er nokså likt et Kanban board, bare med forskjellig navn. Scrum boardet innebærer at man har listet opp hele sprint backloggen som "todo". Det vil si oppgaver som må gjøres i løpet av sprinten. Deretter plukker man ut eller delegerer ansvar for forskjellige backlog items til forskjellige teammedlemmer. De flyttes da til "in progress", som vil si at de er under utvikling for øyeblikket. Når de er ferdig utviklede flyttes de videre til "testing", som vil si at de er ferdig utviklet, men ikke har gjennomgått testing. Når de også har gjennomgått testing flyttes de videre til "done", dersom alt er greit. Done vil si at featuren er ferdig eller at buggen er løst. Dette innebærer at man kan begynne på et nytt backlog item. Under en sprint arbeider utviklingsteamet i fred og ro med applikasjonen, uten avbrytelser eller endringer. Det vil si at dersom en stakeholder plutselig ønsker noe annet skal dette inn i product backloggen, ikke inn midt i en sprint. Formålet med dette er å skape mer strukturerte sprinter, og sikre at hver sprint er motiverende å jobbe med ettersom man vet at man aldri trenger å endre løsning midt i en sprint. Man utfører et standup møte hver morgen på 15 minutter. Under dette møtet går teamet over og ser hva som ble gjort i går, hva som skal gjøres i dag og hvordan man ligger an med tanke på slutten av sprinten. Scrum master kan i samarbeid med scrum owner velge bort features eller bugs basert på informasjonen fra disse møtene, dersom de merker at teamet ikke kommer i mål.

Etter hver sprint gjennomfører man sprint review. Under dette møtet er alle med. Her får utviklingsteamet mulighet til å vise frem det de har kodet, gjerne ved at en stakeholder tester koden. Dette innebærer at koden blir testet, samtidig som den blir vist frem. Her går man over hva som har blitt utviklet, hva som gikk bra og hva som gikk dårlig i løpet av sprinten. Dersom noe gikk dårlig kan det være behov for endringer. Samme dag eller ganske fort (innen noen dager) etterpå gjennomfører man også sprint retrospective.

Sprint retrospective innebærer at man ser på helheten i applikasjonen både med tanke på det som ble gjort i den siste sprinten, hva som har blitt gjort tidligere, hvordan applikasjonen henger sammen og sjekker at helheten gir mening. Formålet er å avdekke konflikter mellom forskjellige deler av applikasjonen og i grensesnittene mellom applikasjonen. Det fører til en mer helhetlig applikasjon, hvor alt henger sammen og er nyttig.

Oppgave 4 b) Scrum Board (besvares på ark) 10 %

Oppgave 5 a. Forklaring til figur fra pensum (5%)

Fortell kort om Personas, Scenarios, Stories og Feature og kommenter sammenhengen mellom dem.

Personas Personas er oppdiktede personer som man kunne tenke seg at kunne bruke denne applikasjonen. Her dikter man ofte opp personer fra forskjellige samfunnsgrupper, i forskjellige økonomiske situasjoner og med forskjellige karaktertrekk. Man beskriver disse personene, og forklarer gjerne overordnet hva de ønsker, og dermed indirekte hva applikasjonen burde inneholde.

Scenarios Personaene inspirer scenarios. Dette er eksempler på situasjoner i hverdagen hvor en bruker har et problem som man ønsker å løse. For eksempel dersom en student syntes det er vanskelig å huske hva de kjøper på vegne av andre i kollektivet hadde det vært nyttig med en applikasjon hvor de kan legge inn varer som de andre i kollektivet deretter må betale for. Dette definerer features som "opprette kollektiv" og "opprette bruker". Stories

Stories vil være "historier" hvor en bruker får ett problem som de ønsker å løse. For eksempel dersom en bruker ønsker å henge opp et bilde med svart hvitt stil i huset sitt, men ikke har noen måte å fjerne fargene vil man gjerne få en feature i en Photoshop app: "gjør om til svart hvitt", som automatisk endrer alle fargene i bilde til svart hvitt.

Features er funksjoner man ønsker å ha med i applikasjonen. Det er noe som skal kunne gjøres i applikasjonen man utvikler. For eksempel "opprette kollektiv" i en kollektivapp. I Photoshop vil muligheten til å gjøre et bilde med farger om til svart-hvitt være en feature. Alle applikasjoner består av mange features, for eksempel i Inspera har man mulighet til å navigere frem og tilbake mellom forskjellige spørsmål ved bruk av piltastene nederst til høyre. Dette er et eksempel på en feature.

Oppgave 5 b. Forklaring til figur fra pensum (5%)

Kommenter og gi korte eksempler på hva som ligger i følgende tre begreper hentet fra figuren under: Portability, Interoperability og Reliability

Portability Innebærer at koden skal være lett å flytte på og gjenbruke i andre systemer eller miljøer. Her vil det være en fordel med for eksempel Microservices som lett kan knyttes opp til andre applikasjoner, og fungere i andre sammenhenger. Dette fører til mer robust kode, som også vil få lavere koblinger, og det blir dermed lavere sannsynlighet for at noe går galt under driften.

Interoperability innebærer at koden skal fungere godt i flere forskjellige miljøer, den skal ikke være avhengig av et spesifikt miljø eller system, men skal være så universell som mulig, slik at den lett kan flyttes til et annet system eller brukes i en annen sammenheng. Dette innebærer at en applikasjon som fungerer i Windows også skal fungere på Mac eller Linux, slik at man lett kan drifte applikasjonen på forskjellige systemer, uten at det oppstår problemer med en gang man går utenfor f.eks Windows miljøet.

Reliability Innebærer at koden skal kunne stoles på. Det er viktig å utvikle sikker kode som man vet at ikke kommer til å svikte. Reliability innebærer at man skal kunne ha høy tillit til koden, og vite med sikkerhet at den ikke plutselig kommer til å slutte å fungere mens den er i drift. Det innebærer også å ha så lave koblinger som mulig, slik at man vet at dersom en del av koden går ned kommer resten av koden fremdeles til å fungere som normalt.

Oppgave 5 c) Etikk (5 %)

Under ser du overskriften på pensumartikkelen om etikk innen profesjonen programvareutvikling. Artikkelen beskriver i alt åtte prinsipper programvareutviklere bør følge. Trekk frem og kommenter fokuset for tre av disse prinsippene.

Effektivitet Man bør utvikle effektiv kode som utfører oppgaver med så lavt mulig energibruk som mulig. Dette innebærer at man skriver effektiv kode, og tar i bruk algoritmer som tillater at koden utfører nødvendige utregninger ved bruk av så lite maskinkraft som mulig. Dermed får man minst mulig informasjon sendt mellom bruker og databasen, samtidig som det som sendes også er det mest relevante.

Sikkerhet Man bør utvikle sikker kode, og fra start tenke på personvern og hvordan applikasjonen utføres med tanke på sikker lagring av brukerdata, at hemmelig informasjon er skjult bak passord, og at enhver bruker ikke har tilgang til mer enn nødvendig. Det innebærer også at man sikrer koden mot feil gjennom testing. Man skal for eksempel fikse alle bugs man er kjent med selv de man vet at nesten aldri kommer til å oppstå, ettersom det vil være til skade for brukeren dersom for eksempel en flymotor automatisk stopper å fungere etter x antall timer.

Testing Det er etisk å utføre testing. Testing innebærer at man tester koden godt på forskjellige måter, dette innebærer både brukertesting, stresstesting, integrasjonstesting etc. Formålet med dette er å avdekke alle typer feil som kan oppstå, og dermed utvikle sikrere kode. Dette er til fordel for brukerne ettersom de slipper å bruke tid på å finne ut av en applikasjon som kun fungerer halvveis.

Casebeskrivelse som skal benyttes ved løsing av deloppgavene i oppgave 6b

Casebeskrivelse på et fiktivt utviklingsscenarie til bruk i oppgave 6 a ,b og c Du skal som din avsluttende bacheloroppgave i ditt IT-studium gå sammen med tre medstudenter og utvikle en programvare. Oppdragsgiver for oppgaven er Miljødirektoratet og dere skal jobbe tett med tre ansatte fra Seksjon for truede arter og naturtyper. I tillegg skal en person fra miljøavdelingen i en stor kommune, en representant fra Norsk Miljøvernforbund og en planteforsker fra Universitetet i Oslo delta både for å fremme krav og ønsker og for å teste programvaren dere utvikler.

Applikasjonen skal støtte opp under arbeidet med å ta vare på biologisk artsmangfold og skal spesielt rettes mot planter. En viktig målsetting i prosjektet er å få engasjert befolkningen i innsamling av data om utbredelse av ulike plantearter. Miljødirektoratet vil i samarbeid med planteforskere ajourføre en liste av de planter man ønsker å få inn data for med bruk av appen. Her skal det til enhver tid ligge 30 - 40 truede arter og 30 - 40 uønskede arter som man ønsker å få inn data på.

Alle planteinteresserte rundt omkring i landet skal, når dere er ferdig med utviklingen kunne laste ned en mobilapp for å registrere funn de gjør av disse artene. Brukeren starter registreringen med å ta bilde av planta og kjøre bildegjenkjenningsfunksjonaliteten i programvaren for å få avklart hvilken plante man har funnet. Gjenkjennes ikke planten kan man likevel fortsette ved å selv skrive inn hvilken art man mener det er. Videre registrerer man tidspunkt for funnet, legger ved flere bilder av planten og gir et anslag på antall planter på stedet. Posisjonen markeres ved å avlese mobiltelefonen sine GPS-koordinater hvis dette er aktivert, alternativt blir man bedt om å oppgi stedsnavn og kommunenavn.

For å holde på engasjementet og motivere til mange registreringer kan brukerne se alle sine registreringer og komme opp på topp-ti lister av registreringer gjort innen et område og tidsrom på enkeltarter og samlet. Det skal være mulig for skoleklasser å registrere seg og delta i registreringskonkurranser Miljødirektoratet setter opp for ulike klassetrinn. Målet er både å få mange registreringer og å bidra til økt kunnskap knyttet til artsmangfold.

Offentlige ansatte som jobber innen fagfeltet vil også kunne registrere funn på samme måte, men her vil applikasjonen også lagre informasjon om at det er gjort av en faglig ansatt. Disse brukerne skal også har statistikkfunksjonalitet for å drive oppfølging av både de truede og de uønskede artene. Her skal de kunne søke på ulike geografiske områder, se utvikling over tid og se på sammenhengen mellom ulike arter. Applikasjonen baserer seg på at alle kartoppslag gjøres mot Kartverket sine fritt tilgjengelige kart.

Et annet ønske fra de ansatte er å ha muligheten til å legge inn tiltak som gjøres for å hindre utbredelse eller verne om enkelte arter. Tiltak kan for eksempel være kantslått, sprøyting, informasjonskampanjer og tilbakestilling av natur. Tiltakene registreres med tidspunkt, type, artene det gjelder og geografisk område. Dermed kan man sjekke endringer i utbredelse før og etter tiltak.

Siden de ulike brukergruppene skal ha ulik tilgang til funksjonalitet må man ved opprettelse av ny bruker få skilt mellom ansatte og vanlige brukere.

Selv om applikasjonen vil være et positivt bidrag i form av at befolkningen blir mer oppmerksom på og interessert i artsmangfold, og at fagfolkene får en bedre oversikt, er man klar over at denne type programvare også kan åpne opp for mulig misbruk. Selv om de teknologiske mulighetene i dag er meget store vil man også i denne type applikasjon stå overfor enkelte risikoer.

Siden dere i bachelorgruppa fortsatt er under utdanning har dere relativt lite erfaring både med å vurdere både omfang og kompleksitet i oppgaven dere står overfor. Desto viktigere er det derfor å få et godt bilde av hva som skal gjøres og legge en plan for hvordan dere skal gå frem for å utvikle mest mulig av applikasjonen innen de fire månedene dere har tilgjengelig for jobbing med bachelorprosjektet (januar til mai). Dere er enige om at bildegjennkjenningsmekanismen vil være svært utfordrende, men at det også er mange andre interessante elementer i oppgaven. Veilederen dere har fått tildelt har kompetanse til å gi dere ekstra oppfølging innen bildegjenkjenning.

Du gleder deg til å ta fatt på arbeidet, og som en forberedelse på dette skal du nå løse enkelte oppgaver.

---- slutt på casebeskrivelse ----

Oppgave 6a Use Case Diagram inkl. Misuse case (15%)

Lag et Use Case diagram som er dekkende for casebeskrivelsen. Tilføy to Misuse Case du mener er svært relevante for dette utviklingsscenariet og vis i diagrammet hvordan disse kan håndteres.

Oppgave 6 b) Sekvensdiagram (10 %) Besvares på ark

Lag et Sekvensdiagram som dekker alt som beskrives i caset knyttet til funksjonaliteten "Registrering av funn".

Oppgave 6 c) Valg av systemutviklingsmodell (10 %)

Argumenter for hvilken systemutviklingsmodell, blant dem vi har hatt som pensum, du ville anbefale for dette prosjektet. Beskriv deretter i korte trekk hvordan utviklingsprosessen burde organiseres og deles inn og angi hvor i prosessen de ulike brukerne bør involveres. For dette prosjektet vil jeg anbefale Scrum. Dette er fordi prosjektet består av en mindre gruppe som skal utvikle, samtidig som man har en tredjepart som er ansvarlig for oppfølging, og en annen tredjepart som vil bruke applikasjonen etter den er ferdig utviklet.

I dette prosjektet ville jeg satt en person fra miljødirektoratet som product owner. Det vil være naturlig at Norsk Miljøvernforbud og planteforskeren er stakeholders, ettersom disse vil komme med krav og ønsker å teste programvaren. Dermed har de mulighet til å komme med kravene sine under sprint planning meeting, og teste applikasjonen etterhvert som den utvikles under sprint review møtene. Dette vil føre til god informasjonsflyt, og føre til at alle får sett produktet etterhvert som det utvikles.

Prosjektet bør deles opp i en rekke sprinter, avhengig av størrelsen på product backloggen. Det vil likevel være naturlig å lage det av et omfangsnivå som gjør at man rekker det i løpet av disse 4 månedene. Det vil være naturlig å ha 4 sprinter på 3 uker, slik at man har tid til å planlegge først, og deretter kjøre 4 sprinter i tillegg tl at man har en avsluttende runde etter dette. Det er også mulighet for en liten sprint på f.eks 2 uker dersom det er noe man ser at man trenger mer tid til, eller for å klargjøre sammensettingen av programvaren etter utviklingens slutt. Man kan legge opp til at man utvikler infrastrukturen under den første sprinten. Dette innebærer å utvikle databasen og brukersystemet. Det vil være naturlig at brukersystemet vises frem og testes under første sprint review. Dermed får man først etablert enighet rundt basen av applikasjonen.

I neste sprint vil det være naturlig å ta tak i bildegjenkjenningen. Det vil være naturlig å dedikere en hel sprint til dette ettersom det er mest omfattende og mest ukjent. Det tas også før kart ettersom kart er mer kjent og dermed en sikrere del av utviklingen. Under andre sprint review meeting vil det være naturlig å vise frem bildegjenkjenningen og teste at bildene gjenkjennes, og at resultatene lagres i databasen.

Den tredje sprinten bør gå til utvikling av kartsystemet, og man bør begynne på sammensettingen av programmets helhet. Det vil si at brukeren har mulighet til å åpne kartet og registrere funn via bildegjenkjenningen. Dersom bilde ikke gjenkjennes får personen selv mulighet til å søke etter art ut ifra de andre resultatene i databasen. Dersom den ikke allerede finnes vil det bli lagt inn en ny.

Den siste sprinten vil gå til det som eventuelt skulle være igjen, det vil si funksjoner det ikke ble tid til, og å sette programmet sammen til en helhetlig applikasjon. Det vil være naturlig å dokumentere koden underveis, men i løpet av denne sprinten er det også viktig å få på plass eventuelt manglende dokumentasjon.

Registrering av 30-40 truede arter som man ønsker å få inn data på gjøres av fagbekreftede brukere når disse logger inn. Det vil være fagpersonellet som er ansvarlige for at riktig mengde ligger inne til enhver tid, og ikke noe koden selv passer på annet enn å gi fagpersonellet en påminnelse dersom det ligger for mange, for få, eller de ikke har blitt endret på lenge.

I sprint retrospective vil man naturligvis se på helheten i prosjektet og hvordan man ligger an i forhold til å nå prosjektmålene. Dersom teamet ser at de ikke kommer i mål vil det være naturlig at scrum master går sammen med scrum owner og bestemmer hvilke features som bør prioriteres.