Løsningsforslag til kapittel 11

Her finner du løsningsforslag, råd og vink til oppgavene i kapittel 11.

11.1.1 Se tekst på gul bakgrunn øverst på side 311.

11.1.2 a og b Se side 312 og 313

11.1.2 c Hvis vi er helt sikre på hva som skal lages, kan vannfallsmetoden kunne fungere. Det kan for eksempel være når vi har en fungerende prototyp til et system og vi ønsker å oppskalere systemet for å takle flere brukere. Likevel er det som regel bedre å velge en smidig utvikling. Det dukker som regel opp feil og andre uforutsette utfordringer underveis i en utviklingsprosess og disse feilene blir oppdaget tidligere og behandlet på en mer effektiv måte ved å bruke en smidig utviklingsprosess. Les mer om smidig utvikling i neste delkapittel.

11.2.1 Kort forklaring på gul bakgrunn midt på side 314.

11.2.2 Ved bruk av smidig utvikling har man mange korte iterasjoner bestående av planlegging, utvikling og testing. Mellom hver iterasjon snakker alle på utviklingsteamet sammen for å finne ut av feil, korrigere kursen og prioritere hva man skal fokusere på. Dette gjør at alle på teamet lærer av feil og utfordringer underveis og dermed kan jobbe smartere for hver iterasjon. Ved vannfallsmetoden fant man gjerne ikke ut av feil og uhensiktsmessig funksjonalitet før i slutten av systemutviklingsprosessen. Da var jo det for seint å gjøre noe med systemet. Ved vannfallsmetoden var man også ekstremt avhengig av en uhyre gjennomarbeidet og detaljert kravspesifikasjon. Det viser seg at det er vanskelig for brukerne av systemet å forutse alt som burde vært med i kravspesifikasjonen. Da er det bedre med smidig utvikling der brukere er med underveis og får komme med innspill til systemet mellom hver iterasjon.

11.2.3 Se øverst side 315.

11.2.4 a Det overordnede målet ved en sprint er å ha klar en delleveranse som kan testes av brukerne.

11.2.4 b Hver sprint avsluttes med en evaluering (retrospekt) for å lære og planlegge neste sprint smartest mulig.

11.2.5 Se side 317.

11.2.6 Utviklerne på teamet har beregnet at arbeidsoppgavene i sprinten vil ta 80 timer og skal gjøres i løpet av 14 arbeidsdager. I starten bruker utviklerne litt mer tid på oppgavene enn de hadde beregnet. Etter 3 dager går arbeidet fortere enn de hadde beregnet og de tar igjen tapt tid i forhold til det de beregnet. Fra 5. dagen stopper utviklingen opp. Det ser ut til at teamet har støtt på problemer som gjør at de bruker mye mer tid enn de beregnet. På dag 9 løser det seg og de jobber mye fortere enn beregnet. Etter 12 dager har de totalt sett brukt mindre tid enn de hadde beregnet og ligger godt an til å bli ferdige med alle arbeidsoppgavene før de 14 dagene er gått. 

11.4.1 Vannfallsmetoden kan for eksempel egne seg når man ønsker å konvertere gamle flash-animasjoner til html5-animasjoner. Da er kravspesifikasjonen i hovedsak de eksisterende og fungerende flash-animasjonene. Dette er konkret å teste den ferdige løsningen opp mot.
Problemet er kjent og løsningen er kjent.

11.4.2 Lean Startup ville vært en smart måte å jobbe på. Vi ønsker jo først å finne ut om produktet er noe som folk er interessert i å ta i bruk og betale for før legger for mye ressurser i utvikling. Arbeidet ville startet med å lage en produkthypotese og utført markedsundersøkelse.
Problemet er ukjent (vi vet ikke hvordan kundene vil ha tjenesten ennå) og løsningen er ukjent (vi vet ikke hva vi skal lage og hvordan vi skal lage det ennå).

11.4.3 Kunden vet hva han vil ha. Problemet er kjent, men løsningen er ukjent. Vi velger en smidig utviklingsmodell.

11.5.1 a Fra skissen ser vi at brukeren skal kunne velge varer og legge dem i en handlekurv, slette dem fra handlekurven og betale med kort. 

11.5.1 b Ulemper med å bruke skissen som dokumentasjon av funksjonelle krav er for eksempel at skissen ikke nødvendigvis forteller nok om funksjonaliteten i det gitte brukergrensesnittet. Skal det gå an å bestille flere av den samme varen? Hva er summen man skal betale? Hva slags betalingsløsning skal brukes? Skissen viser heller ikke hvordan det ferdige designet til systemet skal bli. Det er jo veldig sentralt i en nettbutikk hvordan varene presenteres for brukeren. Hvordan kundene skal finne varene de ønsker er heller ikke beskrevet i skissen.

11.5.1 c

  • Mobilvennlig visning
  • Mulig å velge produkter og legge dem i handlekurven
  • Mulig å slette produkter
  • Vise bilde av produktet
  • Vise pris og mengde
  • Betale med kort

11.5.2 Det er færre detaljer i beskrivelsen av krav ved smidig utvikling fordi brukeren er representert i utviklingsteamet og får komme med innspill underveis i prosessen. Behovet for detaljerte beskrivelser er derfor ikke nødvendig. Det kan faktisk virke hemmende i en smidig utviklingsprosess.

11.5.4 Noen funksjonelle krav vil man lage i starten av prosessen. De blir en del av produktbackloggen. Underveis i prosessen dukker behovet for ytterligere funksjonelle krav opp eller behov for å justere de eksisterende funksjonelle kravene. Vi oppdaterer dermed produktbackloggen.

11.6.1 Teknisk dokumentasjon er for eksempel kommentarer i koden som hjelper til med å forklare hvordan koden virker. Det er også å skrive koden på en systematisk måte og bruke variabelnavn og funksjonsnavn som betyr noe og er selvforklarende. Man kan bruker psaudokode eller flytdiagrammer for å forklare hvordan et program skal fungere, uten at man har programmert det ferdig.

11.6.5 a Tidligere hadde man ikke nødvendigvis tilgang til ressurser på internett. Da var man avhengig av å legge ved brukerveiledninger til systemet. Nå er det vanlig å søke etter hjelp på internett, se på opplæringsvideoer på YouTube, lese og spørre i forumer. Systemene har nå også gjerne brukerveiledninger sin på sine nettsteder.