Modellering IT konferanse 1. Interessenter Utviklere som besøker konferansen: besøke IT konferanse Frivillige hjelpere: få gratis inngang på konferansen Ledelse: Tjene penger Matkjeder: Selge mat og drikke, tjene penger Utviklere som utvikler systemet: tjene penger, få godt rykte Foredragsholdere på konferansen: dele kunnskap om det de kan, få godt rykte Myndigheter, DIFI, datatilsyn: Sikkerhet, personvern, universell utforming
Modellering IT konferanse 2. Use Case diagram Primære aktører: utvikler (besøkende av konferanse), frivillig hjelper, ledelse Sekundære aktører: betalingsmodul, administrasjonsmodul
Modellering IT konferanse 3. Brukerhistorier Som utvikler ønsker jeg å kjøpe billetter til IT konferanse for å lære meg mer om systemutvikling Som en i ledelsen av IT konferansen ønsker jeg å se hvor mange som har kjøpt billetter for å kartlegge om denne konferansen er av interesse for utviklere Som frivillig hjelper ønsker jeg å sende inn søknad for å komme inn på konferansen gratis Som en i ledelsen ønsker jeg å kunne godkjenne hvem som får lov til å være frivillig hjelper for å sikre god service under konferansen -Som utvikler ønsker jeg å kunne velge hvilken dag av konferansen jeg skal kjøpe billetter for for å kun få med meg de foredragene jeg ønsker
Modellering IT konferanse 4. Sekvensdiagram Antagelse: Det er ikke begrenset antall billetter som kan selges (dvs. når brukeren har lyst til å kjøpe en billett vil det alltid være en ledig billett for den/de dagene)
Modellering IT konferanse 5. Klassediagram Antagelser: En person kan bare ha en billett fordi jeg antar at en og samme billett kan være billett for en, to eller alle dagene. Klassen Frivillig som er subklassen til Person kan ha flere attributter (variabler) avhengig av hvilke opplysninger som skal legges inn.
Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 1. Forklar arkitekturen bak MVP (Model View Presenter) og redegjør for hvordan dere brukte det i prosjektet?
MVP (Model View Presenter) er et arkitekturmønster som er anbefalt for utvikling av native Android applikasjoner. Denne arkitekturen tilrettelegger for en lagdeling som blant annet gjør det enklere å teste og videreutvikle applikasjonen. - Model har ansvaret for hvordan dataene blir lagret og behandlet - View viser passivt dataene og tar i mot hendelser fra bruker (f.eks. klikk eller scrolling) - Presenter har ansvar for å tolke hendelser fra bruker som View-et får i tillegg til å avgjøre hvilke data som trengs og hvordan det skal vises fram. I applikasjonen vår er denne arkitekturen ivaretatt på følgende måte: - Vi har en Backend klasse som får melding fra presentere til de ulike sidene om hvilke data som skal hentes. Backend gjør et metodekall til HTTPMethod-klassen som i sin tur avgjør om dataene ligger i cachen (lagret fra før) eller må hentes fra databasen med et API-kall. Hvis dataene skal hentes fra cache ligger all nødvendig informasjon lagret i objektene som Movie, Person eller Genre. Dette er Model-laget. - Hver side i applikasjonen består av en kontraktklasse som definerer tre interfaces (View, Presenter og Backend) som de ulike delene må implementere, en Fragmentklasse og en Presenterklasse. Fragmentklassen utgjør viewet og har dermed ansvaret for å vise fram dataene og ta i mot hendelser fra bruker. Presenterklassen inneholder i sin tur metoder som er relatert til tolkning av hendelser fra bruker og sending av meldinger til Backend, dvs. avgjøre hvilke data som skal hentes.
Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 2. Forklar prinsippene høy kohesjon og lav kobling. Forklar med eksempler hvordan dere brukte dette i prosjektet?
Kohesjon er et mål på hvor mye ansvar et objekt har og hvor fokusert dette ansvaret er. Objekter med høy kohesjon har et moderat ansvar og et begrenset mengde oppgaver den kan utføre. Kobling er et mål på hvor avhengig et objekt er av andre klasser og objekter. Objekter med lav kobling har få avhengigheter. På denne måten blir det enklere å erstatte et objekt med et annet, noe som gjør vedlikehold og videreutvikling lettere. I prosjektet vårt har vi fra utviklernes perspektiv fokusert på at applikasjonen skal være lett å teste og videreutvikle. Derfor har vi laget klasser som har ansvar for en bestemt oppgave i stedet for å ha klasser som har ansvar for mye forskjellig funksjonalitet i applikasjonen. Eksempel på dette kan være at funksjonaliteten til de ulike sidene ("de mest populære"-siden, "filmdetaljer"- siden, "persondetaljer"-siden) er fordelt på forskjellige klasser og hver klasse har kun metoder som tilhører en bestemt side. På denne måten sikrer vi høy kohesjon til objektene våre. Prinsippet om lav kobling er ivaretatt i applikasjonen vår blant annet gjennom lagdelingen som ble beskrevet i oppgave 12.1 for eksempel ved at View-klassene ikke er direkte koblet til Model-klassene, men all kommunikasjon foregår gjennom Presenter. Slik vil det være enklere å skifte ut modellene ved eventuell videreutvikling av applikasjonen.
Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 3. I hvilken grad har programvaren deres i appen fått teknisk gjeld, og hva har har dere gjort for å begrense denne gjelden?
Teknisk gjeld innebærer alle suboptimale løsninger gjort under utvikling som fører til lav kodekvalitet og dermed økte kostnader for vedlikehold og videreutvikling av applikasjonen. I prosjektet vårt opplevde vi teknisk gjeld som følge av lite førarbeid knyttet til etablering av en mer detaljert arkitekturdesign. Vi hadde blitt enige om en overordnet arkitektur og hadde MVP-mønstret i bakhodet, men implementerte det ikke slik vi burde fra starten av. Dette førte til at appen ble vanskelig å teste og i det lange løp kunne føre til at det ble vanskeligere og vanskeligere å legge til funksjonalitet. Når vi ser tilbake på prosjektet vårt, kan vi si at ekstra tid brukt på å tilegne se. kunnskaper om arkitekturmønstre før utviklingsfasen kunne vært en god løsning for å hindre at teknisk gjeld oppstod. Vi kan derfor si at mangel på kunnskap var en av grunnene til at den tekniske gjelden oppstod. I tillegg var tidspress en faktor som vi måtte ta hensyn til og som kanskje førte til at vi implementerte suboptimale løsninger først. Når vi først hadde opparbeidet oss en teknisk gjeld ønsket vi å synliggjøre at vi hadde fått en teknisk gjeld. Vi la inn en issue på Kanban-boardet vårt slik at denne oppgaven kunne bli prioritert i en av sprintene. En av sprintene våre gikk altså ut på å gjennomføre en omfattende refaktorering som hjalp oss å kvitte oss med gjelden knyttet til dårlig arkitektur. Vi var også nøye med å teste applikasjonen statisk, altså se etter potensielle forbedringer i koden for å hindre at vi opparbeidet oss enda mer teknisk gjeld. Til dette fikk vi hjelp av vektøy i AndroidStudio (InteliJ) som pekte på steder der vi hadde dårlig kodeskikk eller små feil som for eksempel ubrukte variabler.
Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 4. Beskriv de fire testnivåer som er sentrale i systemutvikling? For hvert testnivå, nevn minst ett eksempel fra prosjektet deres som dere har testet/ evt. kunne hatt testet.
De fire mest sentrale testnivåene i systemutvikling er enhetstesting, integrasjonstesting, systemtesting og brukertesting (akseptansetesting). Enhetstesting går ut på å teste de enkelte komponentene hver for seg. I prosjektet har vi hatt mye fokus på dette testnivået der vi testet at klassene fungerer slik de skulle. I og med at vi ikke hadde et eget testteam ble testing gjennomført av utviklerne innad i teamet og white-box testing ble brukt som metode fordi vi kjente godt til koden og kunne raskt avdekke hvilken del av kode som førte til feil i testene. For å gjennomføre enhetstesting brukte vi verktøy som JUnit for å automatisere testene, Mockito som lar oss lage testobjekter av klasser som klassen vi tester er avhengig av og Roboelectric som lar oss enklere teste klasser som er avhengige av mange bibliotekklasser. Integrasjonstesting innebærer testing av hvordan de ulike komponentene samhandler og kommuniserer med hverandre. Vi hadde litt mindre fokus på dette testnivået enn på enhetstesting i prosjektet vårt da vi ønsket å forsikre oss om at klassene fungerer som de skal hver for seg før vi testet samhandling mellom de ulike klassene, men vi gjennomførte også noe integrasjonstesting ved å blant annet bruke de samme verktøyene som beskrevet under enhetstesting for å teste kommunikasjonen mellom klassene. Systemtesting går ut på å teste programvaren som en helhet. I prosjketet vårt testet vi applikasjonen vi hadde laget ved å blant annet bruke spesifikasjonsbasert testeteknikk som kalles use-case testing. Vi tok altså utgangspunkt i hvilke use-case systemet skulle implementere og testet at disse use-casene ble utført feilfritt. Brukertesting (akseptansetesting) gjennomføres av kunden/brukere til applikasjonen med mål om å forsikre seg om at applikasjonen tilfredsstiller kundenes ønsker og forventninger og funksjonene fungerer slik de skal. Brukertesting ble gjennomført jevnlig gjennom hele prosjektet som en del av designiterasjoner vi hadde. Teknikkene som ble brukt under brukertesting er observasjoner av hvordan brukerne brukte applikasjonen, samt uformelle intervjuer der brukerne ga tilbakemeldinger både på design av applikasjonen og eventuelle tekniske feil som hadde oppstått.
Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 5. Forklar hvilke prinsipper eller praksiser fra smidig utvikling dere hadde nytte av. Beskriv prinsipper eller praksier som eventuelt ikke passet for deres prosjekt, og hvorfor de ikke virket.
Svar del 1: I prosjektet vårt brukte vi metodikken Scrum med enkelte tilpasninger av aktivitetene som Scrum rammeverket anbefaler. Vi valgte å bruke Scrum fremfor Kanban fordi Scrum virket som mer strukturert metodikk, noe vi trengte i vårt team som aldri hadde jobbet sammen før. Vi brukte rollene som Scrum rammeverket anbefaler, altså ScrumMaster som sørger for at reglene i Scrum blir fulgt og gjennomfører daglige stand-up møter og PO (produkteier) som er et bindeledd mellom kunden og teamet og har ansvar for å prioritere oppgavene i backlogen. ScrumMaster rollen rullerte vi på gjennom hele prosjektet slik at alle kunne prøve seg på det. I etterkant av prosjektet ser vi at det kan være bedre med en fast ScrumMaster som har god forståelse av Scrum rammeverket. Produkteierrollen var fast gjennom hele prosjektet for å sikre at prioritering av oppgavene i backlogen var konsistent. Vi så nytten av å ha en produkteier fordi det var til tider utfordrende å bli enige om hvilke oppgaver som skulle prioriteres. Ved hjelp av produkteier fikk vi derimot en bedre felles mentale modell ved at vi hadde et mål og en visjon for sprinten (og hele prosjektet). Vi gjennomførte både sprintplanleggingsmøter, stand-up møter og en form for sprint review og sprint retrospective møter.
Svar del 2: Under planleggingsmøter ble teamet og produkteieren enige om målet for sprinten. Deretter brukte vi planning poker som metode for estimering av tid og kompleksitet til oppgavene. Vi lagde sprint backlog ved å flytte noen oppgaver fra product backlog og markere den som "Planned" på Kanban-boardet vårt. Kanban board har vært et viktig verktøy for å kunne se progresjonen og holde seg oppdatert på hvem som jobbet med hva til enhver tid. Stand-up møter ble ikke gjennomført hver dag, men dette var en av de mest nyttige møtene vi hadde blant annet for å støtte prinsippet om at den beste kommunikasjonen er ansikt-til-ansikt kommunikasjon. ScrumMaster sørget for at alle fikk fortelle hva de har gjort siden siste møte, hvilke problemer eller utfordringer de har og hva de planlegger å gjøre til neste gang. På denne måten holdt alle seg oppdatert. Selve møtene ble gjennomført stående for å gjøre de korte og konsise, etter stand-up møter hadde vi ofte en aktivitet der vi kunne hjelpe hverandre med problemene vi eventuelt hadde. Siden møtene ikke ble gjennomført hver dag var vi nødt til å finne alternative løsninger for å holde seg oppdatert og da ble chat mye brukt. Sprint review og sprint retrospective gjennomførte vi ikke like formelt som Scrum rammeverket anbefaller, men hadde fortsatt vår versjon av disse. På slutten av hver sprint hadde vi et møte der vi først diskuterte eventuelle forbedringer eller feil knyttet til selve applikasjonen (sprint review). Vi hadde ikke nytte av å lage en demo-presentasjon da det ikke var andre enn utviklere i teamet til stede. Denne diskusjonen gikk over i sprint retrospective der vi diskuterte selve prosessen og hva vi kunne forandre på i gjennomføring av de neste sprintene. Vi prøvde ut noen teknikker for å "sette atmosfære" som er den første anbefalte fasen i en retrospective møte, men dette fungerte ikke så godt for oss på grunn av tidsrammer for møtet og fordi vi allerede hadde sprint review før det slik at diskusjonen allerede var i gang.