Gruppe 32 Hovedprosjekt 2018 ematte

Transkript

1

2 PROSJEKT NR TILGJENGELIGHET Åpen Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL EMATTE KOMMUNEFORLAGET DATO 23 / 05 / 18 ANTALL SIDER / BILAG 126 / 40 PROSJEKTDELTAKERE Dag Brede Ihle s Martin Sommerseth s Tobias Markussen Høiland s INTERN VEILEDER Ismail Hassan OPPDRAGSGIVER Netcompany AS KONTAKTPERSON Christoffer Daae-Qvale SAMMENDRAG Netcompany AS leverer skreddersydde IT-løsninger til ulike bedrifter og er et godt etablert kunsulentselskap i Europa. Prosjektet har bestått i å begynne utvikling av en matte-applikasjon for Kommuneforlaget som over tid skal tas i bruk blant lærere og elever på norske skoler. Denne rapporten er en dokumentasjon av alle aspekter rundt utviklingen av vår IT-løsning fra start til slutt. 3 STIKKORD WEBAPPLIKASJONER SYSTEMUTVIKLING KONSULENTVIRKSOMHET 2

3 Forord Denne rapporten er en detaljert beskrivelse av produktet som har blitt utviklet, og prosessen vi har vært gjennom, i forbindelse med vår bacheloroppgave i Anvendt datateknologi, våren Oppgaven vår har gått ut på å lage en løsning for en kunde, Kommuneforlaget, for et konsulentfirma, Netcompany. Løsningen er en portal for lærere ved navn ematte som skal gi mattelærere muligheten til å lage oppgaver, laste disse opp og sette dem sammen til oppgavesett som man kan gi til elevene sine som lekser eller til prøver. Ved å lage oppgaver på ematte vil man dele oppgaven med samtlige lærere som tar i bruk applikasjonen, og dermed åpne for at man kan gjenbruke gode matteoppgaver som ikke er på trykk i dagens mattebøker. Ettersom ambisjonene for ematte er veldig store, måtte vi begrense hva vi kunne utvikle på den begrensede tidsperioden vi hadde. Fra januar til mai utviklet vi en PoC 1, et produkt som inneholder kjernefunksjonaliteten som er nødvendig for at applikasjonen kan brukes, og er en plattform for videre utvikling. Vårt arbeid med prosjekt har gjort det mulig å opprette oppgaver og oppgavesett, samt filtrere, sortere og favorisere disse. Vi er stolt av det arbeidet vi har lagt ned og håper Kommuneforlaget får god nytte av ematte. Vi ønsker å takke Netcompany for et svært lærerikt og spennende bachelorprosjekt. Tusen takk til vår tekniske bistand ved Petter Fagerlund Asla og Fredrik Christoffer Berg, UX ved Maren Moe Stokke, Petrit Holmgaard Gerxhaliu og Trine Rydningen Kirkhaug, vår prosjektleder Ingri Maude og Hanne Karlsen som produkteier hos Kommuneforlaget. Vi vil også takke vår veileder, Ismail Hassan, som har veiledet oss gjennom prosjektet på en god måte og hjulpet til der det har vært behov for det. 1 Proof of Concept produkt som beviser at gjennomføring er mulig 3

4 Innholdsfortegnelse 1. Introduksjon Om prosjektet Prosjektgruppen Oppdragsgiver Netcompany Kunden Kommuneforlaget Prosjektplan Bakgrunn for prosjektet Presentasjon av ematte Prosjektorganisering Rapporter og rutiner Rapporter Rutiner Dokumenthåndtering Endringshåndtering Milepæler Prosjektavslutning Gjennomføring av prosjektet Estimering og planlegging Gjennomføring av sprint Avslutting av sprinter Kravspesifikasjon Sider uten innlogging Sider for lærer (innlogget) Sider for admin(innlogget) Mål Produktrapport Innledning Design Innledning Informasjonsarkitektur Brukergrensesnitt Overordnet arkitektur Arkitektur Logisk Datamodell

5 2.3.3 Teknologivalg Backend Oversikt Arkitektur Hibernate CAS Flyway Frontend Oversikt React Arkitektur Testrapport Innledning Teststrategi og metoder Brukertester Brukerveiledning Oversikt over brukergrensesnittet Inn- og utlogging Filtrere listen Søk Lage oppgave Lage oppgavesett Legge til oppgaver og oppgavesett som favoritt Egenevaluering Backend Frontend Oppsummering Prosessrapport Innledning Inngangen til prosjektet Valg av oppdragsgiver Første møtet med teamet Code of Conduct Planlegging av prosjektet Scrum

6 3.3.2 Design Database Backend Frontend Verktøy Utviklingsverktøy Dokumentasjonsverktøy Kommunikasjonsverktøy Testverktøy Utviklingsprosessen Første møte med kunden Netcompany sitt bidrag Forsinket start Sprint Sprint Sprint Sprint Sprint Forventningsstyring Statusmøter Produktdemo Avslutning av prosjektet Evaluering Hva er vi fornøyd med? Hva kunne vi gjort bedre? Hva har vi lært? Ord fra prosjektleder Vedlegg Litteraturliste Attest fra Netcompany Prosjektdagbok Teknisk dokumentasjon for Kommuneforlagets SSO-løsning Risikokoder og faktorer Installasjonsguide Time-tracking-report fra JIRA

7 4.8 Brukertester

8 1. Introduksjon 1.1 Om prosjektet Prosjektgruppen Gruppen vår består av tre studenter ved Anvendt datateknologi på OsloMet. Gruppen har jobbet med gruppearbeid ved flere anledninger siden høsten 2016 og vi er dermed godt kjent med hverandre fra før og har et godt samarbeid. Gruppemedlemmer: Martin Sommerseth - s Dag Brede Ihle - s Tobias Markussen Høiland - s Oppdragsgiver Netcompany Netcompany AS er et konsulentfirma som leverer skreddersydde IT-løsninger til bedrifter. Med kontorer i både Europa og Asia er de et veletablert selskap. Den norske avdelingen til Netcompany AS het tidligere Mesan, men ble kjøpt opp av danske Netcompany høsten Netcompany AS vil heretter bli referert til som Netcompany eller oppdragsgiver Kunden Kommuneforlaget Kommuneforlaget AS arbeider med å lage digitale løsninger og faglitteratur som skal sørge for høy kvalitet og effektiv tjenesteyting i den kommunale sektor. I forbindelse med vårt prosjekt har Kommuneforlaget AS kjøpt opp og inngått en samarbeidsavtale med grunnleggeren av ematte, Carl Erik Melhus. Kommuneforlaget AS vil heretter bli referert til som Kommuneforlaget eller kunden. 1.2 Prosjektplan Prosjektplanen skal gi en overordnet beskrivelse av prosjektgjennomføringen og de viktigste elementene ved dette. Planen skal dermed legge til rette for en oversiktlig og smidig gjennomføring av prosjektet. 8

9 1.2.1 Bakgrunn for prosjektet Som IT-studenter fant vi ut høsten 2017 at å ha en godt utfylt Linkedin-profil vil være svært viktig for å være synlig på arbeidsmarkedet. Dette viste seg å være en genistrek da vi alle fikk tilbud om å komme på jobbintervju om fremtidig stilling hos Netcompany. Vi valgte å høre med dem om det var mulig for oss å komme til dem å skrive vår bacheloroppgave, og i november 2017 ble det avholdt et møte med Christopher Daae-Qvale, partner i Netcompany, og Helene Brennhovd Holth, HR-rekruttering i Netcompany. På møtet ble Netcompany som bedrift presentert og de la fram deres tidligere arbeid med studenter. De har nemlig tidligere hatt svært stor suksess med studentprosjekter og satser dermed mye på dette området. Ved møtets ende fikk vi beskjed om at vi var svært ønsket til å være en av deres to bachelorgrupper denne våren og de var allerede klare med arbeidskontrakt. Prosjektet vi har jobbet med var på dette tidspunkt ikke helt klart enda. Netcompany hadde opprinnelig en avtale med et annet firma, men denne avtalen falt sammen og ble dermed ingenting av. Det var derfor ikke klart for oss før i januar 2018 at vi skulle jobbe med ematte. Prosjektet vi har blitt tildelt består i å bygge opp en allerede eksisterende løsning med en annen teknologi enn det som er brukt i dag. Applikasjonen skal også tilpasses slik at den fremstår på samme måte som resten av kundens nettsider og applikasjoner (fargebruk, font etc.). På teamet vårt har vi en gjeng UX ere 2 som utarbeidet en skisse før vi tiltrådte på prosjektet. Denne skissen er godkjent av kunden og er vår pekepinn. Disse skissene har dog endret seg endel i løpet av prosjektet, og dette er gjort på bakgrunn av brukertester og hva vi utviklere mener kan være bedre for kundens totalprodukt Presentasjon av ematte Kommuneforlaget har nylig kjøpt opp nettsiden ematte.no som skal være et hjelpemiddel for matematikklærere. Løsningen er i en tidlig fase og Kommuneforlaget ønsker at siden videreutvikles for å få opp volumet av oppgaver som er tilgjengelig. Per nå er det svært begrenset hvilke oppgaver som er tilgjengelig gjennom siden. På sikt ønsker Kommuneforlaget at siden skal få innloggingsfunksjoner for elever i tillegg til lærere og ønsker å knytte en abonnementsløsning til ematte. Dette vil ikke implementeres i dette prosjektet, men er en PoC for nettsidens potensiale. Tanken bak er at det i dag er vanskelig for lærere å treffe nøyaktig på læreplanen ved bruk av oppgaver i skolebøker. Disse blir gjerne gjenbrukt i flere år og oppgavene vil være de samme. Dette gjør det stadig vanskeligere for lærere å velge ut oppgaver som utfyller alle de målene en elev skal oppnå ved gjennomføring av en matteoppgave. 2 User Experience interaksjonsdesignere som jobber med brukeropplevelse 9

10 Kommuneforlaget har, som nevnt tidligere, valgt å kjøpe opp og inngå et samarbeid med Carl-Erik Melhus da de ser hvilke muligheter ematte kan ha for mattelærere i fremtiden. I deres arbeid med å øke effektivitet og kvalitet i kommunal sektor vil ematte kunne bidra til at elevene får en hverdag med mer skreddersydde oppgaver og lærere vil ta i bruk hverandres kreativitet for å skape mer utfordrende og lærerike oppgaver. I 2020 vil det bli gjort en restrukturering av kompetansemålene i matematikk, noe som gjør at oppgaver i mattebøker vil bli enda mer utdatert. Med ematte vil det ikke være nødvendig for lærerne å forholde seg til det, men heller bare bruke hverandres oppgaver Prosjektorganisering Prosjektet er organisert med bachelorgruppen som utviklere, med støtte og oppfølging fra interne ressurser i Netcompany som prosjektledelse, teknisk arkitektur, teknisk support, UX og funksjonell arkitektur Roller 1) Produkteier I. Ekspert på domenet og vil bistå prosjektet i å ta de rette valgene gjennom utviklingsperioden 2) Prosjektleder (kommuneforlaget) I. Sørger for at de rette personene fra Kommuneforlaget involveres i prosjektet II. Bidrar på statusmøter, og jobber sammen med Prosjektleder fra Leverandør for å identifisere forbedringsområder for prosjektet III. Kontraktseier 3) Prosjektleder (Netcompany) I. Følger opp prosjektdeltakere fra Netcompany II. Ansvarlig for statusrapporter III. Hovedkontaktperson for henvendelser relatert til prosjektet som ingen andre roller er ansvarlig for 4) Salgsansvarlig (Netcompany) I. Kontraktseier II. Kan motta henvendelser som ligger utenfor prosjektet (endringsordre etc.) 5) Arkitekt og teknisk ansvarlig I. Sørger for en god teknisk arkitektur II. Legger en strategi for teknisk implementasjon III. Følger opp teknisk kvalitet 6) UX Designer I. Ansvarlig for design og brukeropplevelse 10

11 7) Utvikler (Netcompany) I. Leverer kode med høy teknisk kvalitet II. Følger gitt strategi for implementasjon Figur 1 Tabell som viser alle roller Ingri Maude prosjektleder Ingri har vært vår prosjektleder gjennom dette prosjektet og har vært den som har styrt hele prosjektet og vært bindeledd mellom kunde og oppdragsgiver. Hun er selv ikke utvikler, men hun har holdt de ukentlige statusmøtene med kunden, samtidig som hun også har minnet oss på tidsfrister og hjulpet oss dersom vi har hatt spørsmål om alt mulig innen konsulentyrket. Petter Fagerlund Asla og Fredrik Christoffer Berg teknisk arkitekt og teknisk bistand Som helt nyutdannede utviklere var det veldig greit å ha noen i ryggen som man kan spørre om hjelp. Petter og Fredrik er selv konsulenter og sitter ute på henholdsvis Norgesgruppen og Kulturrådet, men er alltid tilgjengelig for oss gjennom Hipchat 3 dersom det skulle være 3 HipChat - chatteprogram for samarbeid innad i teamet 11

12 behov for teknisk bistand. De hadde også muligheten til å komme på HQ 4 hvis det var behov for det. Maren Moe Stokke, Trine Rydningen Kirkhaug og Petrit Homlgaard Gerxhaliu UX Allerede før vi startet med prosjektet i januar hadde Maren og Trine startet å utarbeide skisser til ematte. Dette gjorde at vi helt fra start hadde noe å strekke oss etter når vi skulle begynne å programmere. UX gjennomførte også brukertester og endret skissene fortløpende dersom det skulle være behov for det. Etter at Maren sluttet i februar tok Petrit over hovedansvaret for UX, og har gjennomgått QA på løsningen flere ganger for å sikre at brukervennligheten opprettholdes. 1.3 Rapporter og rutiner Rapporter Rapport Beskrivelse Utarbeides av Frekvens Ukentlig status Ukentlige rapporter som distribueres i forkant av statusmøte Prosjektleder for Netcompany (Ingri Maude) Ukentlig/før statusmøter Rutiner Møte Frekvens Sted Ansvarlig for agenda Deltakere Ukentlig statusmøte Ukentlig Kommuneforlaget(evt. telefon/skype) Ingri Maude Ingri Maude, Hanne Karlsen Dokumenthåndtering Dokumentasjon vil til enhver tid være tilgjengelig på Confluence 5. Dette er en dokumentasjon som kontinuerlig oppdateres og gjøres gjennom Kommuneforlagets interne 4 HQ kontoret til Netcompany i Henrik Ibsens Gate 5 Confluence - dokumentasjonsverktøy 12

13 Confluence og JIRA 6 for at det skal bli enklere å følge opp prosjektet for begge både kunde og oppdragsgiver Endringshåndtering For å kunne håndtere endringer i krav fra kunden, har det blitt utviklet en backlog 7 med ønsket funksjonalitet som i samarbeid med Netcompany og Kommuneforlaget prioriteres slik at den viktigste funksjonaliteten blir behandlet først.prosjektgruppa vil gjennomføre det de rekker i løpet av perioden som er til disposisjon. 1.4 Milepæler Figur 2 Milepæler 3. jan til 1. April 6 Jira - dokumentasjonsverktøy 7 Backlog samling av brukerhistorier som skal implementeres 13

14 Figur 3 Milepæler 2.april til 14. mai 1.5 Prosjektavslutning Prosjektet avsluttes og løsningen overleveres kunden 11. mai Metode for overtagelse, installasjonsdokumenter o.l. blir bestemt sammen med kunden tett opptil avslutning av prosjektet. 1.6 Gjennomføring av prosjektet Netcompany tar i bruk Scrum som sin vanlige prosjektmetodikk for gjennomføring av prosjekter. Vi hadde kunnskap om Scrum fra faget Systemutvikling, som vi tok høsten 2016, noe som kom til nytte i gjennomføringen av prosjektet. For vårt prosjekt tok vi i bruk en tilpasset versjon av Scrum. I Scrum har en sprint en fast varighet, men vi baserte sprintens varighet på mengden funksjonalitet vi tok med i sprint backloggen. Dette var på grunn av prosjektets begrensede varighet som gjorde at tilpasning var nødvendig Estimering og planlegging 14

15 Prosjektet har en ganske omfattende produkt backlog som tar for seg mange funksjonaliteter. For å strukturere gjennomføringen deler vi opp prosjektet i sprinter (se 3.6 Utviklingsprosessen), hvor vi tar med oss funksjonalitet som skal prioriteres og som på forhånd er blitt avklart med kunden. Dermed kan vi estimere hvor lang tid hver av oppgavene vil ta. For å bli enige om hvor lang tid det vil ta å gjennomføre oppgaver tok vi i bruk metoden planning poker (se Estimering). Ved endt estimering kan man begynne arbeidet med sprinten Gjennomføring av sprint En sprints varighet vil vanligvis være mellom 2 og 4 uker. I vårt prosjekt har det ikke vært en fast tidsramme for hver sprint, men denne har variert mellom 3 og 4 uker. Målet med sprinten er at samtlige oppgaver i sprint backlogen skal ferdigstilles før man avslutter sprinten. Daglig gjennomføres det stand-ups hvor vi stiller spørsmålene: Hva gjorde jeg i går? Hva skal jeg gjøre i dag? Hva hindrer meg fra å gjennomføre det jeg skal gjøre i dag? Dette er for at samtlige skal være klar over sin egen oppgave, andres oppgaver og bidra til minst mulig dødtid i prosjektet. Hver onsdag ble det også gjennomført et statusmøte med kunden. Vi i utviklingsteamet deltok ikke på disse møtene hver eneste uke, men var med når det var behov for avklaringer Avslutting av sprinter Ved avsluttet sprint skal alle oppgaver være ferdigstilt. For å ta læring gjennomfører vi en sprint review med kunden og retrospekt internt i teamet: Sprint review Se på estimering (over- eller underestimert oppgaver?) Hva skal prioriteres i neste sprint? Retrospekt Hva har gått bra? Hva burde vi gjort bedre? Hva skal vi ta med oss videre? 15

16 Figur 4 - slik så det ut på tavla under retrospekt Her var det mulig å komme med alle slags synspunkter, både på det faglige, sosiale, samarbeid og arbeidsmiljøet. Dette var en fin måte for teamet å reflektere over arbeidet. Etter endt retrospekt er man klare til å begynne prosessen på nytt og starte neste sprint. 1.7 Kravspesifikasjon Kunden har spesifisert en kravspesifikasjon bestående av funksjonalitet som allerede finnes på ematte.no i dag, og funksjonalitet som de ønsker at skal legges til (markert med ). De ulike funksjonalitetene er delt inn i 3 nivåer. Per dags dato bruker ematte.no php 7.0, selvskrevne javascript-filer (myscript.js og ajax.js),css (mystyle.css), bootstrap (3.x) og jquery (siste utgave), mariadb, phpmyadmin. Som nevnt er denne kravspesifikasjonen basert på funksjonalitet som er på dagens ematte.no, og det var ikke meningen at vi skulle implementere all funksjonalitet som er listet nedenfor Sider uten innlogging Index.php 16

17 Førstesiden «Hva er ematte?». Video med forklaring Lenke til oppgaver for elever Elever kan gå inn her og løse matematikk oppgaver selv. Disse vil ikke få samme nummer som i en matematikklekse, men tallet vil være i forhold til når det er lagt inn. Dette bør forbedres, men det viktigste er at en elev kan gjøre 9 oppgaver en time og fortsette neste time på oppgave 10. Hvis oppgavene er tilfeldige kan det ta litt motivasjon fra elevene ettersom de føler de må starte på nytt hver gang. Innloggede elever kan få mulighet til å få opp en boks om de svarte riktig eller ikke. Iallfall få frem fasit på en måte, men bør ikke ligge åpent, da de vil gå inn der stedets for å gjøre leksene. About.php Om ematte.no. Statisk side News.php Statisk side. Legger ut siste endringer Hjelp.php Hjelpeside med videoer Hvordan legge inn en oppgave Hvordan legge inn flere oppgaver Hvordan publisere fasit m.m. Contact.php Kontaktskjema som sender til post@ematte.no Login.php Bruker kan logge seg inn Bruker kan bestemme nytt passord (register.php) Bruker kan registrere seg (register.php) Feide Show.php Viser leksene for elevene. En knapp øverst hvor elevene kan velge om de ønsker å se fasit (hvis lærerenhar publisert fasit). Da kommer de til en visfasit-side..htaccess Hvis URL består av ematte.no/[10 tegn]. Vil den vise siden show.php?q=[10 tegn] Sider for lærer (innlogget) Min profil Endre informasjon og e-post E-post-varsling hvis noen i klassen ikke har gjort leksene til tiden Tema: 2 temaer: Hvit (enkel) eller med bilde(litt slik som i dag). 17

18 Legg inn en oppgave Tittel Ca. Vanskelighetsgrad (1-13). Dette blir forhåpentligvis styrt automatisk når man vet hvilke trinn oppgavene blir brukt på. Interaktive oppgaver:drag-and-drop. Trykk på riktig bildet ++ Oppgave (muligheter for formler og tabeller i tekstfelt) Fasit Bilde Kommentar fra lærer som legger inn oppgave Hjelpelenker/videoer. Samarbeid med noen som har mange lenker? Type oppgave (checkbox): Åpen oppgave, Problemløsningsoppgave,Tekstoppgave, Puggeoppgave, Begrepsbruk. Legg til undervisningsopplegg, knyttet til oppgaven. Gjemme noen av disse mulighetene under «Flere valg» for at siden ikke skal virke så overveldende Legg inn flere oppgaver Her kan man legge inn flere oppgaver, opp til 20 oppgaver. Dette er en enklere utgave enn den første. Mine oppgaver Her kan du se og endre oppgavene du har laget Lag gjøremål Her lager du gjøremål/lekser Her kan man skrive navn på leksen, f.eks. «Lekser uke 45» Når vi har koblet på feide bør dette komme «automatisk», med muligheter for å endre i skrivefeltet. F.eks. Lekser for [Klasse] [år]. Siden bruker javascript/ajax for å være responsiv og unngå oppdatering av siden Oversikt over valgte oppgaver. Kriterier for oppgavene kan være tema, nivå, type osv. Sette tidsfrist for leksen Hjelpevideo: Hvordan lage gjøremål Stemme oppgave opp/ned Stjernemerke oppgave (favoritt) Her bør man kunne endre rekkefølge på oppgavene Del gjøremål (med andre lærere og klasser). Da slipper man å lage samme lekse flere ganger Varsle meg hvis noen ikke har gjort leksen (innstilling) La andre lærere kommentere. La andre lærere legge til undervisningsopplegg Stemme opp/ned undervisningsopplegg Mine gjøremål Oversikt over leksene brukeren har gitt. Endre rekkefølge Få kode Skriv ut oppgavene Se fasit Publiser fasit 18

19 Bruk lekse på nytt Logg ut Sider for admin(innlogget) Siste brukere (liste over siste brukere som ikke er godkjent. Siden lister også opp lenken medlemmene selv la inn) Trykk her (godkjenner en lærer og setter rolle til 1) Siste oppgaver (liste over de sistes oppgavene) Liste over de 100 siste oppgavene Mål Formålet med prosjektet kan deles inn i et hovedformål, samt flere delmål: Hovedformålet er at Kommuneforlaget ønsker å få opp volumet av oppgaver som ligger tilgjengelig samt å gjøre siden til et foretrukket hjelpemiddel for mattelærere For at det skal være mulig å nå hovedformålet for prosjektet, er det behov for å legge stor vekt på brukeropplevelse ved utformingen av ematte. For at nettsiden skal være et foretrukket hjelpemiddel er det nødvendig at den er intuitiv, oversiktlig og rask å bruke Den må være tidsbesparende for lærere å bruke. 2. Produktrapport 2.1 Innledning Dette kapitlet inneholder dokumentasjon av produktet som har blitt utviklet gjennom dette prosjektet. Rapporten vil ta for seg en beskrivelse av produktet og en gjennomgang av teknologiene som ligger bak. Dette kapitlet inneholder dokumentasjon av produktet som har blitt utviklet gjennom dette prosjektet. Rapporten vil ta for seg en beskrivelse av produktet og en gjennomgang av teknologiene som ligger bak. Rapporten inneholder fire deler, en beskrivelse av designet, en beskrivelse av den overordnede arkitekturen og dokumentasjon av backend og frontend. Under kapittelet Design finner du en beskrivelse av sidens utforming og informasjonsarkitektur. I kapittelet Overordnet arkitektur tar vi for oss den tekniske arkitekturen til løsningen og teknologiene som ble brukt. Deretter kommer kapitlene som inneholder dokumentasjon av løsningens back- og frontend, der vil du finne informasjon om produktets teknologier og hvordan disse er tatt i bruk. Ved oppstart av prosjektet satte vår tekniske arkitekt Petter Fagerlund Asla og tekniske ressurs Fredrik Christoffer Berg opp og konfigurerte prosjektet, med eksempel på metoder 19

20 som viste flyten fra frontend til backend, slik at vi kunne starte utviklingen så raskt som mulig. 2.2 Design Innledning I dette kapittelet beskrives løsningens design i detalj, herunder løsningens informasjonsarkitektur, utforming og hvordan viktige designprinsipp har blitt tatt hensyn til Informasjonsarkitektur Organisering av innhold Innholdet i løsningen består av oppgaver og oppgavesett som er lagd av brukerne, og målet er å få så mye innhold som mulig for å gi lærere et bredt utvalg å velge i og kunne gi de beste oppgavene til elevene sine. Dette fører til at det kan bli veldig mye innhold på siden, og det å organisere innholdet godt blir nødvendig for en god brukeropplevelse. Det første du ser på landingssiden er en liste med oppgaver og oppgavesett, og det er nettopp denne som kan bli veldig lang og uoversiktlig. Kapittel (se Informasjonsarkitektur) går gjennom hvordan innholdet struktureres slik at brukeren enklest mulig kan få oversikt over innholdet Grupperingsmetoder Innholdet er gruppert etter en eksakt grupperingsmetode, ettersom innholdet grupperes på egenskapene til oppgavene og oppgavesettene. 8 Oppgavene har mange egenskaper, hovedsakelig tema, type oppgave, klassetrinn og vanskelighetsgrad. Oppgavesettene har de samme egenskapene og disse baseres på hvilke egenskaper oppgavene i oppgavesettet har. I tillegg grupperes innholdet etter om det er brukeren som har laget det, og om brukeren har det som favoritt. Egenskapene til innholdet er presist definert og stort sett gjensidig utelukkende, for eksempel en oppgave for femte trinn kan ikke også være en oppgave for tiende trinn, og hvis man sorterer etter favoritt får man åpenbart bare favorittene sine. En slik grupperingsmetode er hensiktsmessig i denne løsningen ettersom det nesten er nødvendig med en eksakt grupperingsmetode for å finne frem til innholdet man vil ha Organiseringsstruktur Løsningen benytter seg av en database-orientert organiseringsstruktur, altså en flat struktur der alt innhold er likestilt, men innhold har felter og metadata, som emne, type, antall 8 Rosenfeld, L., Morville, P. & Arango, J, 2015, s

21 ganger en oppgave har blitt lagt til som favoritt, osv. 9 Disse kan man søke, filtrere og sortere på hvilket muliggjør navigasjon i innholdet Navigering For å navigere i en flat struktur så er det nødvendig med filtrering og sortering. En av hovedmåtene å navigere seg på i denne løsningen er filtering. Innholdet kan filtreres på om det er du som har lagd innholdet, eller om det er andre, om det er oppgave eller oppgavesett, om du har innholdet som favoritt eller ikke, man kan filtrere på klassetrinn, vanskelighetsgrad, type oppgave og tema. Man kan velge så mange filter fra så mange kategorier som man vil for å snevre inn informasjonen, og man kan velge flere filter fra samme kategori, for eksempel vanskelighetsgrad 1 og 2, for å få mer å velge i. Et annet navigeringsverktøy er søk. I noen tilfeller der filtrering ikke er tilstrekkelig, eller brukeren husker navnet på en oppgave han/hun så tidligere som han/hun likte, er søk et naturlig alternativ for navigering. I løsningen er søk kun implementert på tittel på grunn av tidsbegrensninger i utviklingen, da søkefunksjonalitet var nedprioritert. I tilfeller der man har filtrert og/eller søkt, og har en liste med resultater, er det naturlig å sortere disse etter visse egenskaper. Som standard står sortering på nyeste, altså de oppgavene eller oppgavesettene som ble senest opprettet, men dette kan byttes til mest populære, altså antall ganger en oppgave eller et oppgavesett har blitt lagt til som favoritt, eller eldste, alt ettersom hva brukeren er ute etter. Ellers i løsningen er navigering veldig intuitivt da vi benytter modaler for navigering som ellers ville ført deg til en ny side, dette beskrives nærmere under (se Brukergrensesnitt) Brukergrensesnitt Løsningen har et gjennomgående minimalistisk design, dette for å gjøre løsningen enklere og mer oversiktlig og dermed skape en bedre brukeropplevelse. Løsningen har en layout som for de fleste brukere vil virke kjent, med en header, en meny langs siden, en linje med knapper like under headeren, og hovedinnholdet på siden under denne igjen. 9 Rosenfeld et al., 2015, s

22 Figur 5 - landingssiden Et layout som brukerne mest sannsynlig er kjent med, kan hjelpe til med å gjøre løsningen enklere å bruke ettersom brukeren har brukt noe lignende fra før. Listen skiller mellom oppgaver og oppgavesett ved å ha forskjellige ikoner, der en oppgave har ett ark, mens et oppgavesett har to, i tillegg har oppgavesettene et ekstra ikon som inneholder oppgaveikonet og et tall. Dette tilsier hvor mange oppgaver det er i oppgavesettet. Som vi kan se på figur 5, bidrar det minimalistiske designet til å vise hvilken funksjonalitet som er tilgjengelig i løsningen, ettersom det er få, og beskrivende knapper i den horisontale og vertikale menyen, altså stort sett all funksjonalitet som er tilgjengelig er synlig fra landingssiden. Menyen til venstre kan filtrere objektene som vises, etter Alle og Mine, og om det er oppgaver, oppgavesett, og/eller om brukeren har lagt de til som favoritt, basert på hva man har krysset av for. Om dette ikke skulle være intuitivt, er det en knapp under der igjen med teksten Vis flere filtre, noe som tilsier at avkrysningsboksene over er filtre. Tilhørende til lista med oppgaver og oppgavesett har man sorteringsmenyen. Pilen som peker ned tilsier at dette er en dropdown-meny som kan trykkes på. Som man kan se på figur 6 peker denne pilen oppover når man har trykket på den som tilsier at den kan lukkes igjen. Teksten som står som standard når man åpner siden er nyeste, noe som tilsier at innholdet på siden er sortert etter de nyeste. I denne menyen kan man sortere på de nyeste oppgavene og oppgavesettene, de mest populære, eller de eldste. 22

23 Figur 6 - sorteringsmeny Hvis brukeren er kjent med denne typen layout, kan fokuset fort bli på hovedinnholdet på siden, altså listen med oppgaver og oppgavesett. Ettersom dette kan bli en lang liste etterhvert som applikasjonen blir mer og mer brukt, vil denne lista bli mer aktuell å sortere og filtrere. Da er det spesielt hensiktsmessig at all viktig funksjonalitet er synlig og lett tilgjengelig. Løsningen benytter seg av modaler for all funksjonalitet som krever et nytt vindu. En modal i denne sammenhengen er et vindu på toppen av hovedsiden, slik at brukeren ser at man ikke forlater siden, som gjør brukeropplevelsen sammenhengende blant annet ved at man slipper å trykke på tilbakeknappen i nettleseren hvis man trykker feil ettersom man enkelt ser hvor man kan trykke for å komme tilbake. I listen er det oppgaver og oppgavesett, og for å se disse må man klikke på de. Når man trykker på noe i lista åpnes en modal, med en oppsummering av oppgavens egenskaper, herunder klassetrinn, type oppgave, vanskelighetsgrad og tema. I tillegg er det en knapp med tekst Favoritt som setter oppgaven til favoritt. Ikonet for dette er et bokmerke, noe som kan diskuteres om er intuitivt, og det var noe diskusjon om å bruke et hjerte eller lignende i stedet, men kunden ønsket et bokmerke. Under dette har man selve oppgaven, med tittel og beskrivelse øverst, deloppgavene under, og tilleggsinformasjon som fasit, tips og nyttige verktøy nederst. Figur 7 - visning av en oppgave 23

24 Som man kan se på figur 8 er måten oppgavesett blir vist på helt lik, men med en liste av oppgaver nedover siden. Oppgavesettets egenskaper er basert på oppgavene i oppgavesettet. Figur 8 - visning av oppgavesett Figur 9 - meny for ny oppgave eller oppgavesett Figur 10 - meny for å legge til i oppgavesett og favoritter 24

25 Som man kan se på figurene over åpner knappene i den horisontale menybaren seg på samme måte, og brukeren får valg mellom å lage nye oppgaver og oppgavesett, eller å legge valgte oppgaver til eksisterende oppgavesett, eller valgte oppgaver og/eller oppgavesett som favoritter. Figur 11 - lage nytt oppgavesett I figuren over ser man hva som skjer når man har trykt nytt oppgavesett, lagt inn tittel, beskrivelse og vanskelighetsgrad, og lagt til fire oppgaver. Figur 12 - nytt oppgavesett uten oppgaver 25

26 Figuren over viser hva som skjer hvis man trykker nytt oppgavesett, men ikke legger til oppgaver i settet. På knappen der det ville stått neste på grønn bakgrunn, står det her publiser tomt oppgavesett på grå bakgrunn. Dette for å vise brukeren at man kan publisere et tomt oppgavesett, men i de fleste situasjoner vil det kanskje være hensiktsmessig å legge til oppgaver i settet først. Et mål for designet var å skape mest mulig konsistens, som er et viktig designprinsipp. Dette kan vises til mange steder i løsningen. For eksempel er kortene til oppgavene og oppgavesettene, altså objektene i lista over innhold, som man kan trykke på for å åpne de, gjort like overalt i løsningen, som på landingssiden, etter man trykker nytt oppgavesett, og legg til i oppgavesett, vil de oppføre seg stort sett på samme måte overalt. Som man kan se på figur 12 og figur 13 er skjemaene for å lage nytt oppgavesett og legge til oppgaver i oppgavesett veldig like ettersom de har en ganske lik funksjon, hvilket bidrar til å gjøre det fort og enkelt å bli kjent med løsningen. Figur 13 - legge til oppgave i oppgavesett Et annet eksempel på konsistens er filtrering- og sorteringsmenyen. Disse er implementert tre steder: på landingssiden, i nytt oppgavesett-skjemaet og i legg til i oppgavesett-skjemaet. Hvis man ser på figur 12 og figur 13 kan man se at menyknappene er helt like. Sorteringsmenyen er også helt lik som på landingsiden, og dette mener vi er hensiktsmessig ettersom menyen er relativt liten. Som vi kan se på figur 14 blir filteringsmenyen veldig lang, ettersom det er mange valg å filtrere på. Denne menyen passer fint ved siden av listen med oppgaver og oppgavesett, men når man skal filtrere oppgaver inne på et skjema for å lage oppgavesett ville en vertikal meny ført til at siden blir veldig uoversiktlig, og man ville måtte bla veldig mye opp og ned i modalen for å kunne produsere et oppgavesett. Derfor hadde vi akkurat samme menyen som på landingssiden, men vi la den horisontalt, vist på figur 15, noe som gjør at man får bedre oversikt og kan velge filter og oppgaver uten å måtte bla like mye. 26

27 Figur 14 filtrering for sidemeny Figur 15 - filtrering for modal Et annet viktig designprinsipp er feedback, eller tilbakemelding. Brukeren bør få tilbakemelding på det brukeren gjør, slik at man vet at det man gjør er riktig og fungerer. Som man kan se på figurene 16 og 17 får man tilbakemelding i form av en slags pop-up som beskriver hva som har blitt gjort etter man publiserer en oppgave eller et oppgavesett. Figur 16 - publisering vellykket 27

28 Figur 17 - publisering vellykket Man får også tilbakemelding når man velger oppgaver eller oppgavesett som favoritter ved at bokmerket man klikker på blir blått, som man ser på figurene 18 og 19. Hvis man velger flere oppgaver og/eller oppgavesett som favoritt blir bokmerkene blå, og man får i tillegg en pop-up som forteller at de ble lagt til som favoritter, dette i tilfelle de oppgavene man valgte ikke lenger er synlig når man trykker på legg til i favoritter og ikke ville sett at noe skjedde, men med pop upen får man tydelig beskjed om at det man prøvde å gjøre fungerte. Figur 18 - oppgavesett ikke favoritt Figur 19 - oppgavesett favoritt Utformingen av siden er gjort med viktige designprinsipp i baktanke, noe som tilrettelegger for en god brukeropplevelse. Alle designvalg, eksempelvis konsistens, synlighet og tilbakemelding, er gjort med hensikt å gjøre løsningens implementerte modell mest mulig lik brukerens mentale modell. 2.3 Overordnet arkitektur Arkitektur 28

29 Figur 20 - arkitektur På figur 20 ser vi en visualisering av den overordnede arkitekturen i applikasjonen. Klienten kaller på et REST API som blir drevet av backenden. REST-laget kaller videre på et servicelag der eventuell logikk blir utført, før servicelaget kaller på et dataaksesslag, som igjen opererer mot databasen Logisk Datamodell Figur 21 - logisk datamodell 29

30 Over vises den logiske datamodellen for applikasjonen, dette tilsvarer da databasen Teknologivalg I dette kapittelet listes teknologiene som er brukt i applikasjonen sammen med en kort beskrivelse. Database PostgreSQL - Relasjonsdatabase, Open Source og mye brukt. Flyway/Liquibase - Versjonskontroll for databasen. Backend Spring Boot - Modulbasert rammeverk for oppsett og bygging av applikasjoner i Java miljø. Hibernate - Rammeverk for å mappe en domenemodell mot en relasjonsdatabase. Frontend React - JavaScript-rammeverk for oppbygging av brukergrensesnitt. Utbredt, velprøvd og har et godt rykte i bransjen og i Netcompany. Redux - Bibliotek for vedlikehold av tilstander. Ofte brukt med React. NodeJS - Rammeverk for lettvekts server-applikasjoner. Meget skalerbart og har utmerket ytelse. Bulma - CSS-rammeverk. 2.4 Backend I dette kapittelet går vi gjennom backenden, dens arkitektur og de forskjellige rammeverkene som er benyttet. I tillegg er det en gjennomgang av CAS, SSO-protokollen 10 som er benyttet i denne applikasjonen Oversikt Backenden er skrevet i Java 8, og vi har benyttet Spring Boot for å bygge applikasjonen. Vi har benyttet rammeverket Hibernate 11 for å kunne mappe domenemodellene i backenden mot databasen. Backenden er bygd opp slik at den kan tjene mange forskjellige klienter, eller frontender, som et web API, noe som gjør at for eksempel en separat mobil-klient kan benytte seg av den Web API 10 Single sign-on protokoll 11 Hibernate rammeverk for å mappe domenemodeller til databaser 30

31 Et web API 12 består av endepunkt som kan nås ved hjelp av request-response metode, altså en metode som består på at en maskin sender en forespørsel til en annen maskin som svarer på forespørselen. APIet vårt baserer seg på request-response metoden REST 13 som enkelt forklart benytter HTTP-protokollen for å overføre data mellom maskiner. APIet består altså av restendepunkter(se Restendepunkter) som kan nås av frontenden via en URI. Hvordan dette fungerer kommer vi nærmere inn på under kapittelet om arkitektur Arkitektur Backenden er bygget opp i tre lag, DAO 14, et servicelag, og et REST-lag, og i tillegg har vi domenemodellene. I dette underkapittelet får du vite om disse lagene, hvordan domenemodellene fungerer, og hvordan alt dette samhandler for å fungere som et web API. For å vise hvordan domenemodellene, servicelaget, DAOet og REST-laget henger sammen, vil vi i dette kapittelet vise kode-eksempler fra Task(en oppgave) siden Task inneholder mye funksjonalitet og er representativ for hele backenden. 12 API application program interface 13 REST Representational state transfer 14 DAO data access object 31

32 Mappestruktur Figur 22 - her kan man se mappestrukturen i backenden. Under er en gjennomgang av de forskjellige lagene IndexController IndexControlleren blir kalt når backenden kjører og den inneholder metoder for å logge inn brukere, autorisere brukere og for å lagre brukere i databasen når de logger inn for første gang. Dette er nødvendig ettersom vi bruker en ekstern SSO-protokoll, noe som blir beskrevet nærmere under kapittel om CAS. 32

33 Over ser man autoriseringsmetoden som autoriserer en bruker om securitycontext returnerer OK, denne kjøres når en applikasjon starter etter en bruker logger inn. Dette kommer vi tilbake til i kapittel CAS. Over ser vi metoden som logger inn en bruker om responsen fra CAS-serveren er OK. Dette betyr at når en bruker forsøker å logge inn, sjekker denne metoden om brukeren faktisk er logget inn. Metoden vist over sjekker om innlogget bruker er lagret i databasen til applikasjonen vår, og hvis den ikke er det, persisteres brukeren. Dette er nødvendig siden vi benytter en ekstern SSO-protokoll, altså at brukernes informasjon ikke ligger i vår database fra før. 33

34 Domenemodell Oversikt over domenemodellene Navn TaskEntity SubTaskEntity TaskSetEntity TopicEntity TypeEntity UserEntity FavouriteTaskEntity Beskrivelse En oppgave En deloppgave Et oppgavesett Et oppgavetema En oppgavetype En bruker En favorittoppgave, består av primærnøkkelen til oppgave og bruker FavouriteTaskSetEntity Et favorittoppgavesett, består av primærnøkkelen til oppgavesett og bruker Beskrivelse av domenemodell Hver entitet i backenden, altså et objekt som tilsvarer en tabell i databasen som er beskrevet under kapittel 2.3.2, har en domenemodell. I dette kapittelet er det en gjennomgang av domenemodellen til Task, en oppgave, ettersom den er relativt stor og er stort sett representativ for alle domenemodellene i backenden. 34

35 Figur 23 - domenemodell for task På figur 23 ser vi første del av domenemodellen til Task, altså en oppgave. Øverst ser vi annotasjon som kommer fra Hibernate, i tillegg har med flere. Disse annotasjonene kommer vi tilbake til i underkapitlet om Hibernate. Nedover siden ser man egenskapene til modellen som tilsvarer attributtene til entiteten i databasen. Figur 24 - eksempel på mapping På figuren over ser vi hvordan entiteten forholder seg til andre entiteter. Vi ser hvordan mange-til-mange, mange-til-en og en-til-mange relasjonene i databasen er beskrevet i domenemodellen. Hvordan dette fungerer blir videre beskrevet under kapitlet om Hibernate. Mange-til-mange relasjonene inkluderer topics(temaer), types(typer), og taskset(oppgavesett), ettersom hver oppgave kan ha mange temaer og typer, og tilhøre 35

36 mange oppgavesett, mens mange temaer og typer kan tilhøre mange oppgaver, og mange oppgavesett kan ha mange oppgaver. Nederst ser vi annotasjon som heter favourites, som tilsvarer hvor mange ganger en oppgave har blitt lagt til som favoritt. Figur 25 - eksempel på get og set metoder På figur 25 ser vi eksempler på get- og set-metoder, altså metoder som blir brukt til å hente og sette verdier på en instans av domenemodellen. Hver attributt har en get- og set-metode, men som man kan se blir ikke alle brukt, ettersom det ikke er implementert funksjonalitet som benytter disse, men det er allikevel god praksis å skrive disse metodene når domenemodellen lages siden man aldri vet når man kan trenge de DAO DAO står for data access object som er et objekt som opererer mot databasen. For hver domenemodell i prosjektet finnes et DAO. I vårt prosjekt er DAO en interface, med en implementasjon av interfacet. I implementasjonen er det metoder som samhandler med databasen. 36

37 Figur 26 - eksempelkode På figur 26 kan vi se metodene som brukes for å operere mot databasen for Task. De har en veldig enkel oppbygging der man definerer en sql-setning, og benytter disse sammen med Hibernate sin EntityManager, som er et API fra Hibernate, for å hente data fra databasen. Figur 27 - eksempelkode 37

38 På figur 27 ser vi metoder for å slette favoritter fra databasen, hentet fra implementasjonen av FavouriteDAO. Her henter vi først det vi ønsker å slette fra databasen med en sql selectsetning, for så å slette disse med EntityManager sin remove-funksjon Service Servicelaget er der hovedsakelig all logikk skal foregå i backenden. Etter eventuell logikk er blitt utført, skal den kalle på DAO for å utføre operasjoner mot databasen. Figur 28 - eksempelkode På figur 28 ser vi deklarasjonen av TaskService med konstruktør. Figur 29 - eksempelkode På figur 29 ser vi metoden for å opprette oppgaver. Den tar imot en implementasjon av domenemodellen til Task. Deretter sjekker den om oppgaven har deloppgaver, for så å manuelt sette deloppgavene sin eier til oppgaven som følger med, dette gjøres ettersom oppgaven ikke enda er persistert, og ville da ikke fungert. Deretter settes den innloggede brukeren som eier av oppgaven, og man kaller på DAOet som persisterer oppgaven i databasen. 38

39 Figur 30 - eksempelkode fra service På figur 30 ser vi et par metoder i TaskService som benytter seg av FavouriteDAO for å persistere favorittoppgaver i databasen. Den øverste metoden brukes i de to nederste, og det den gjør er å lage et objekt av domenemodellen til en favorittoppgave ved å ta imot oppgaven og hente innlogget bruker, da en FavouriteTaskEntity består av disse to. På metode nummer to bruker man den øverste metoden til å lage en FavouriteTaskEntity og så kalle på FavouriteDAO som persisterer denne i databasen. I den nederste metoden får man en liste med oppgaver som skal legges til som favoritt, og da går man gjennom denne lista, lager FavouriteTaskEntity ved hjelp av den øverste metoden, for så å kalle på samme metode fra FavouriteDAO som metode nummer to REST REST-laget er det som gjør at backenden kan fungere som et REST API. Oppbyggingen av REST-laget er relativt enkel. Metodene i REST-laget består av REST-endepunkter som frontenden kaller på, og den returnerer en respons som inkluderer status og hvilke metoder som kalles på. Når et REST-kall er fullført kalles metoder i service laget, som igjen kaller på DAO. Med et REST-kall følger det med hvilken HTTP-metode som blir benyttet, headers og en body. Headers kan være for eksempel hvilken type innholdet bodyen er på, og derfor har alle API-kall i vår applikasjon en Content-Type header med verdi application/json som beskriver at verdien i bodyen er på json format. I body følger også verdiene man skal operere på i backenden, som kan være for eksempel en TaskEntity i json-format. 39

40 Figur 31 - eksempelkode fra REST På figur 31 ser vi deklarasjon av REST-laget for Task. Der beskrives hva som er base uri, altså /api som er uri-en til APIet, og hvilke klienter som er tillatt å benytte seg av APIet, i denne sammenheng som da tilsvarer frontenden til ematte. Her kan flere klienter legges til. I tillegg instansieres TaskService, som blir benyttet videre. Figur 32 - eksempelkode fra REST På figur 32 ser vi et eksempel på en metode i REST-laget. REST API kan gjøre fire ting: opprette, lese, oppdatere og slette. Dette er kjent som CRUD(Create, read, update, delete), som i REST heter, i rekkefølge, POST, GET, PUT og DELETE. Denne metoden har annotasjon, som sier at det er en read operasjon som skal utføres. Klienter som kaller på denne metoden må dermed ha satt metoden i API-kallet til GET. står det /task/published, noe som sammen med base uri utgjør der localhost:8080 ville være kalt noe annet i produksjon, dette er da restendepunktet. Den returnerer en respons med en status og kaller dermed på servicelaget. Figur 33 - eksempelkode fra REST 40

41 Metoden på figur 33 fungerer veldig likt som metoden på figur 32, men denne metoden kaller på noe som skal persistere noe i databasen, altså en create, som i REST heter POST, og dermed har metoden annotasjon, som tillater restendepunkt å ha samme URI, men med de forskjellige annotasjonene utføre forskjellige ting basert på hvilken av CRUD-metodene man vil utføre. I tillegg ser vi her annotasjon med en TaskEntity som innparameter, som henter bodyen fra API-kallet. Figur 34 - eksempelkode fra REst Det er hovedsakelig to måter å hente data fra et API-kall på, å hente bodyen ved hjelp som er beskrevet over, men hvis det er et tall eller lignende man vil ha tak i er det hensiktsmessig å inkludere dette i URI-en til API-kallet. På figur 34 ser vi annotasjon med type Long som henter tallet fra URI-en, som i dette tilfellet er id en, eller primærnøkkelen, til en oppgave. Figur 35 - eksempelkode fra REST På figure 35 ser vi et eksempel som da kaller på en metode som skal slette data fra databasen Restendepunkter Under er en tabell som beskriver alle restendepunktene i backenden. Den inkluderer en beskrivelse av hva som blir gjort, URI-en til restendepunktet, hvilken HTTP-metode som blir benyttet, hvilke parametre som følger med, med type, og hva returverdien er, som inkluderer både HTTP-status, og hvilke data som blir returnert. 41

42 URI HTTPmetod e Beskrivelse Parameter Returverdi /authorize GET Autoriserer bruker /task/{id} GET Henter en spesifikk oppgave /task GET Henter alle oppgave /task/published GET Henter alle publiserte oppgaver /task POST Persisterer en oppgave /task/favourite GET Henter en brukers favorittoppgaver /task/user GET Henter en brukers oppgaver /task/favourite/{taskid} POST Legger til en oppgave som favoritt /task/favourite/tasks POST Legger til en liste med oppgaver som favoritt Long taskid TaskEntity Long taskid List<Long taskid> 200(OK) / 403(Forbidden) 200(OK), TaskEntity 200(OK), List<TaskEntity> 200(OK), List<TaskEntity> 201(Created) 200(OK), List <Long TaskId> 200(OK), List<TaskEntity> 201(Created) 201(Created) /task/favourite{taskid} DELET E Fjerner en oppgave fra favoritt Long taskid 200(OK) /taskset/{id} GET Henter en spesfikk oppgave /taskset GET Henter alle oppgavesettene /taskset/published GET Henter alle publiserte oppgavesett /taskset POST Persisterer et oppgavesett Long id TaskSetEntity 200(OK), TaskSetEntity 200(OK), List<TaskSetEntit y> 200(OK), List<TaskSetEntit y> 201(Created) 42

43 /taskset/favourite GET Henter en brukers favorittoppgaves ett /taskset/user GET Henter en brukers oppgavesett 200(OK), List <Long tasksetid> 200(OK), List <TaskSetEntity> /taskset/favourite/{taskse tid} POST Legger til et oppgavesett som favoritt Long tasksetid 201(Created) /taskset/favourite/taskset s POST Legger til en liste med oppgavesett som favoritt List <TaskSetEntit y> 201(Created) /taskset/favourite/{taskse tid} DELET E Fjerner et oppgavesett fra favoritt Long tasksetid 200(OK) /type GET Henter alle oppgavetypene /topic GET Henter alle oppgavetemaen e 200(OK), List<TypeEntity> 200(OK), List<TopicEntity> Hibernate Vi brukte rammeverket Hibernate for å knytte domenemodellene, altså Java-objekter, sammen med hverandre, og til databasen. Dette kan gjøres ved konfigurering via XML, eller ved hjelp av Java-annotasjoner som vi benyttet. På klassenivå på domenemodellene har vi to som beskriver at det modellen tilsvarer er en entitet i databasen, med et innparameter som er navnet på tabellen i databasen. 43

44 For hver attributt domenemodellen har, er det en kolonne i databasen, og dette annoteres med et innparameter som er kolonnenavnet. På figuren over ser man primærnøkkelen til entiteten Task. Dette annoteres og den er autoinkrementell ved hjelp av sequences, som blir satt opp med Vi bruker sequence over alternativet identity ettersom det er hensiktsmessig med tanke på ytelse, da identity vil legge objektet til i databasen for så å sjekke databasen etter neste ledige id, der man med sequence referer til et sequence-objekt for å hente sin neste verdi. Dette betyr at man ved sequence henter sin neste verdi fra minne, der man med identity henter sin neste verdi basert på hva som er i databasen, noe som tar lengre tid. annotasjon beskriver at verdien ikke tilhører databasen som er knyttet til domenemodellen, men allikevel beskriver objektet. I eksempelet over er det antall ganger brukere har lagt til en oppgave som favoritt. Figur 36 - mapping av tasks og topics På figurene over ser vi hvordan Hibernate håndterer mange-til-mange-relasjoner i databasen. Først annoteres attributten med etterfulgt som gjør at det opprettes en hjelpetabell, sier hvilke kolonner fra hver tabell som skal inkluderes i hjelpetabellen. På andre siden av relasjonen, som på 36 er i TopicEntity, ser vi hvordan relasjonen mappes, der TopicEntity har en attributt som er en liste med TaskEntity, der de mappes ved hjelp av topics som er på eiersiden av mange-til-mange-relasjonen, altså på TaskEntity. På over ser vi hvordan Hibernate håndterer mange-til-en-relasjoner. Det gjør den på relativt lik måte som mange-til-mange, men etter som det bare er mange-til-en trengs ikke en 44

45 hjelpetabell. Det som blir gjort her er at SubTaskEntity får en egen attributt som er primærnøkkelen til oppgaven den tilhører. For å operere mot databasen benytter vi en EntityManager, som er et API. Dette brukes ved å lage SQL-spørringer, og den benyttes i dataaksesslaget. På figuren over ser vi hvordan EntityManager brukes for å hente data fra databasen ved hjelp av en funksjon som heter CreateNativeQuery, som tar i mot en egendefinert sqlspørring, og hvilken domenemodell objektet man skal hente har. På figuren over ser vi hvordan EntityManager brukes til å persistere en oppgave i databasen på en linje kode, ved hjelp av funksjonen persist. På figuren over ser vi hvordan EntityManager sin remove metode brukes for å slette objekter i databasen. Først hentes favorittoppgaven man vil slette ved hjelp av createnativequery, for så å slette dette objektet man får ved hjelp av remove CAS CAS er en SSO-protokoll som Kommuneforlaget benytter i sine løsninger, og denne er integrert i vår løsning. I grove trekk fungerer det ved at man logger inn via Kommuneforlaget sin CAS-server som autoriserer applikasjonen vår. 45

46 På figuren over ser vi en del av application.yml, en konfigurasjonsfil, som beskriver Kommuneforlagets CAS-server og vår service, som er backenden som skal autoriseres. Frontenden sender et kall til restendepunktet /authorize som sjekker om backenden er autorisert. Er svaret OK får brukeren fortsette, hvis ikke blir man sendt tilbake til innloggingssiden til CAS, og på denne måten autoriseres frontenden. Konfigurasjonen for CAS på applikasjonen vår ble satt opp av vår tekniske arkitekt. Han benyttet Kakawait sin mal for konfigurasjonen 15, som er en mal for oppsett av CAS for Spring Boot-applikasjoner. Figur 37 - CAS konfigruasjon På figur 37 ser vi et utdrag fra konfigurasjonsfila for CAS, CasSecurityConfiguration.java. Her ser vi metoden som blant annet konfigurerer hva som skal være blokkert om man ikke er innlogget i CAS. Dette kan man se under.antmatchers, der alt under /api er blokkert med mindre man har rollen user eller admin, derav.hasanyrole( USER, ADMIN ), og under den 15 Lepretre,

47 igjen ser man at restendepunket /authorize skal være tilgjengelig for alle, derav.permitall, ettersom det er nødvendig for å kunne autorisere applikasjonen Flyway Vi benyttet Flyway for å ha versjonskontroll på databasen vår. Dette gjorde vi ved å lage SQLfiler som ble kjørt hver gang backenden ble kjørt. Hvis vi skulle gjøre endringer på databasen, måtte vi lage nye SQL-filer som endret databasen. På denne måten kan vi enkelt holde kontroll på databaseversjonen, og enkelt gå tilbake om det skulle oppstå feil. Figur 38 - sql script På figur 38 ser vi SQL-filene. Som man kan se heter de V, for versjon, etterfulgt av et tall, etterfulgt av en beskrivelse av hva filen inneholder. Tallet setter vi i økende rekkefølge når vi lager de, slik at vi ser i hvilken rekkefølge de ble opprettet. Flyway ser da hvilken rekkefølge disse filene skal kjøres i. 2.5 Frontend I dette kapittelet får du vite om hvordan klientsiden av applikasjonen er bygget opp. Først kommer en oversikt over hva vi har tatt i bruk og hvorfor, og deretter vil vi går mer inn i dybden på hvordan de forskjellige teknologiene og rammeverkene binder applikasjonen sammen Oversikt Kundens eksisterende applikasjoner er bygget med React/redux, og derfor ønsket de at vi skulle bygge vår applikasjon i det samme biblioteket. React, sammen med redux, har i det siste blitt et svært populært bibliotek for å lage single-page applications(spa). Siden vi kun brukte Angular 2+ til å bygge SPA i tidligere fag fra skolen, var React noe vi ikke hadde noe tidligere erfaring med. 47

48 Sammen med React/redux ble klientsiden av applikasjonen bygget med JavaScript, HTML, CSS. Kunden ønsket også at vi tok i bruk rammeverket bulma.io, siden dette var noe de også hadde brukt i eksisterende applikasjoner. Bulma er et css rammeverk som inneholder en rekke komponenter og moduler, samt andre css klasser for design av klienten. Frontenden er delt opp i containers, components, actions og reducers noe du vil få vite mer om i Arkitektur React React er et svært effektivt og fleksibelt JavaScript bibliotek for å bygge web-baserte brukergrensensitt. React er laget og vedlikeholdt av Facebook. Det er komponentbasert og blir ofte brukt til å lage single-page applikasjoner, veldig ofte sammen med Redux, dette får du vite mer om i Redux. Det finnes to utgaver av React: ReactJS(som vi har brukt), og React Native. Sistnevnte brukes for å lage mobilapplikasjoner med JavaScript med mulighet for native kode sammen med JavaScript (som f.eks Swift og Objective-C) Dataflyt React har en en-veis dataflyt ved bruk av properties(ofte kalt bare props, se Komponenter og Props), som kan sendes fra en komponent og til et child av den komponenten, og ikke andre veien. Se eksempel under: Figur 39 - eksempel på et React element Ved bruk av state, kan man bruke en to-veis dataflyt, slik at innhold i en komponent kan oppdateres asynkront i viewet i applikasjonen når dataene som skal vises endres. Se eksempel under: Figur 40 - ES6 klasse med props Komponenter og Props Komponenter i React lar deg dele opp user-interfacet i mindre, gjenbrukbare deler, hvor hver del er isolert fra de andre. Dette forenkler både testing og vedlikeholdsprosessen. Konseptet med en React komponent er at det er en javascript funksjon, som kan ta imot input gjennom det som kalles props. En komponent returnerer hva som skal vises i DOM DOM document object model 48

49 I 39 ser du hvordan en enkel komponent kan lages og ta imot props og i figur 40vser du hvordan man kan bruke en ES6(ECMAScript 6) klasse til å lage en komponent. Vi har i vår applikasjon begge deler, dette får du vite mer om i Komponenter og Containers JSX JSX er en syntax-utvidelse av JavaScript. JSX syntax er verken en string eller HTML, men det er en blanding. Det brukes for å opprette React elementer som kan skrives direkte ut i viewet i applikasjonen. Et React-element ved bruk av JSX syntax kan se ut som følger: Figur 41 - JSX element Med JSX kan man lage større og mer komplekse react elementer, som også tar inn data via props og kan skrives ut i elementet. Props kan også inneholde funksjoner som kan brukes til for eksempel onclick funksjoner. På bildet under kan du se hvordan vi har brukt JSX i vår applikasjon til å opprette et Reactelement. Dette elementet er en checkbox, her brukes også komponenten Field som du vil få vite mer om i ReduxForm. Figur 42 - eksempel på et React element Redux Redux blir svært ofte brukt sammen med React. Redux er en såkalt state container 17 for å behandle tilstanden til forskjellige klasser i applikasjonen. Grunnen til at man bruker Redux, er for å gjøre tilstandsbehandling ryddig og forutsigbart. Med redux kan du sende data til noe som kalles store slik at de ligger der tilgjengelig fra andre containere i applikasjonen. Måten dette gjøres på er å gjøre et kall mot et API, deretter sendes resultatet av API-kallet med en innebygd dispatch funksjon. Her sender man med en type av hvilken action som er en konstant string vi har laget selv. F.eks. FETCH_NAME_SUCCESS eller FETCH_NAME_ERROR basert på statuskoden som returneres fra API et. Hvis suksess, sendes også dataene (ofte kalt payload) sammen med typen til en reducer. En reducer er et sted hvor man kan bestemme hva som skal gjøre med dataene(payload) som mottas. Deretter returneres dataene til store hvor de ligger tilgjengelig globalt i applikasjonen fra andre containere. 17 State container - En container som inneholder states 49

50 I vår applikasjon har vi brukt Redux på følgende måte: Figur 43 - utføre en dispatch basert på resultat fra API-kallet Figur 44 - dette sendes ved en suksess Figur 45 - her mottas payload i reducer og returneres til store ReduxForm Redux Form er en open-source pakke som enkelt kan installeres med npm 18. Alle forms vi har brukt i løsningen er Redux Form. Hensikten med bruken av Redux Form, er å gjøre det lettere å behandle større og komplekse forms, noe vi på forhånd visste at våre forms kom til å bli. Redux Form håndterer følgende data i Redux store: Feltene i formet Verdien i hvert felt Om verdiene i feltene er gyldig Om feltene er rørt Om formet blir innsendt 18 Npm Node package manager ( 50

51 Figur 46 - reduxform dataflyt 19 En del av Redux Form pakken, er Field komponenten. Denne komponenten lager og binder hver input i formet til Redux store. En Field komponent tar inn en rekke forskjellige properties under panseret, som kan brukes til å behandle endringer i komponenten. En Field komponent kan også ta imot en egen custom komponent, hvor man kan sende inn sitt eget custom inputfelt, som da vil bli bundet til formets state i redux store. Alle våre Fields tar imot en egen komponent som vi har lagd selv, som igjen lager en Field komponent som skriver f.eks. ut en checkbox 19 Rasmussen, udatert 51

52 Figur 47 - hvordan "picktopics" lager en Field hvor den tar inn "renderinput" i props Arkitektur Frontenden er bygget opp av komponenter, containers, reducers og actions, som vist i figur 48. Slik holder vi strukturen ryddig og oversiktlig, samtidig som det blir lettere å gjenbruke komponenter. Det vi omtaler som komponenter er statiske, dumme komponenter, som kun tar imot data og viser disse. Containers inneholder funksjonaliteten til komponentene, actions utfører handlinger og reducers sørger for at data blir tatt vare på. Dette vil forklares nærmere i de neste avsnittene 52

53 Figur 48 - React/redux arkitektur Figur 48 viser hvordan en komponent trigger en action, som behandles av reduceren, som sender resultatet til store, som igjen kan taes imot i containeren, som kan sende dataene til komponenten igjen Mappestruktur og navngivning Det øverste nivået i mappestrukturen er delt inn slik man kan se i figur 49, bortsett fra store, som er en egen fil som ligger øverst i prosjektet. Under hver av disse har vi en mappe som heter common, hvor filer som skal brukes på mange forskjellige steder i applikasjonen blir lagt. Containers har ikke en common mappe, siden det er dette som er seksjonene i applikasjonen. I tillegg ligger det mapper som beskriver seksjoner av applikasjonen, med mapper under der igjen som beskriver seksjonen innenfor. 53

54 Figur 49 - mappestruktur Komponenter Komponentene beskriver små eller store visuelle deler av applikasjonene. Disse komponentene tar i mot props, som brukes til å vise endringer i data som kommer inn til komponenten. Disse er statiske og alle har en container som parent. Det er containeren som styrer hva komponenten skal gjøre, og hvilke data den skal inneholde. Hvordan en komponent ser ut og deklareres, kan du se i figur 41. Nedenfor ser du en beskrivelse av hver komponent i applikasjonen. Det er lagt ved et bilde på alle komponenter vi fant det var hensiktsmessige å gjøre dette med. På øverste nivå finner man App, Footer og Login. App komponenten er selve inngangsporten til løsningen, den inneholder en Route til containeren Home, som er landingssiden. Footer komponenten er ikke i bruk i første versjon, siden det kun brukes i login siden som heller ikke er i bruk. Login siden ble laget tidlig i prosjektet, men siden det ble avklart at vi måtte bruke kundens egen login side i CAS, er denne ikke lenger i bruk. 54

55 Alerts(Common) Komponent installert med npm, tar inn tittel, melding, bekreftelsestekst, kanselleringsknapp og en funksjon som skal utføres da man klikker confirm. Vi har tre forskjellige, en for å spørre brukeren om h*n er sikker på at h*n vil gå ut i det man holder på å lage en oppgave eller oppgavesett. En for å bekrefte at valgte oppgaver er lagt til i favoritter og en for å bekrefte en publisering av en oppgave. Vi går ikke dypere inn i komponenten da den er installert fra en tredjepart. Dokumentasjon finnes her: (Slik vil en react-confirm-alert se ut) Filter(common) Dette er komponenter som viser alt som har med filtreringsmenyen å gjøre. FilterDifficulty Denne komponenten tar inn en label og onchange. Skriver ut 3 checkboxer med value 1, 2 og 3. Brukes for å filtrere på vansklighetsgrad FilterGrade Får inn verdien som er valgt i select dropdownen og en onchange, som brukes til å behandle endring i dropdownen. FilterTopic Tar inn label, temaer og en filter metode som sendes inn i FilterButton komponenten, Looper gjennom alle temaene som kommer inn og lager en FilterButton for hvert tema. 55

56 FilterType Tar inn en label, liste over oppgavetyper og en filter metode som sendes til FilterButton. På samme måte som FilterTopic, looper denne gjennom alle typer og skriver ut en FilterButton for hver type. FilterModal Dette er parent komponenten til FilterDifficulty, FilterGrade, FilterTopic og FilterType og fungerer som en wrapper for disse komponentene. Denne brukes for å lage en horisontal filtermeny, slik som den man ser der man kan legge inn oppgaver i et oppgavesett. Den tar inn: hiddenfilters: boolean for å bestemme om den skal vises eller ikke filter: funkjson for å gjøre en filtrering i FilterGrade onchange: funksjon for å behandle en endring i GradeFilter toggledifficultyfilter: funksjon for å endre vanskelighetsgrad filtrering toggletypefilter: funksjon for å endre type-filter toggletopicfilter: funksjon for å endre tema-filter handedifficultychange: funksjon for å endre verdien til FilterDifficulty select types: liste av alle type oppgave tilgjengelig topics: liste av alle temaer tilgjengelig 56

57 FilterSidebar Dette er også en parent komponent på samme måte som FilterModalMenu, men denne er vertikal og laget for side-menyen på landingssiden. Den fungerer på samme måte som FilterModalMenu med de samme innparameterene, men den tar også inn et ekstra innparameter: toggletasktypefitlter. Dette er for å filtrere på om det er et oppgavesett, oppgave eller favoritt Modal(Common) Dette er komponentene som brukes i modalen. De varierer veldig i kompleksitet og noen bruker også andre komponenter. AddToCollection Dette er en knapp som kan vise en knapp med ikon for å legge til i samling(ikke i bruk i nåværende versjon). 57

58 BottomRowButtons Denne komponenten viser raden med knapper på bunn av modalen, den tilpasser seg etter hvilken type modal som er aktiv og hvilken side som er aktiv. Tar inn følgende props: page: integer, sidetall previouspage: funksjon for å gå tilbake til forrige side hasremovetasks: boolean for å sjekke om knapp som gir brukeren mulighet til å fjerne valgte oppgaver skal være tilstede. showremovebutton: boolean for å sjekke om fjern valgte knappen skal vises eller ikke isdisabled: boolean for å sjekke om fjern valgte knappen skal være disabled showemptytaskset: boolean for å sjekke om knappen som lar deg publisere tomt oppgavesett skal vises. modaltype: Et objekt av typen ModalType[LINK TIL DECLARATIONS], brukes for å sjekke at det er nytt oppgavesett modalen som er aktiv eller ikke total: integer, totalt antall pages der komponenten brukes ChosenTaskList Komponent som viser en liste over alle valgte oppgaver i oppgavesettmodalen. Tar inn en liste av oppgaver, en boolean om den er en TaskPicker([SE LINK TASKPICKER]) og en funksjon(toggleisdisabled) for å toggle om fjern valgte knappen skal være disabled eller ikke. Den looper igjennom alle oppgavene som kommer inn og skriver ut en Task container for hver oppgave(se [LINK TIL TASK CONT]). Feedback Denne komponenten viser en stjerner som man kan bruke for rating og kommentarer til oppgaven eller oppgavesettet. Denne tar ikke inn noe props enda siden dette ikke er implementert i første versjon. FormTopicPage 58

59 Denne tar inn en liste av temaer og lager et FieldArray(se [FIELD ARRAY BESKRIVELSE]) av alle temaene. Dette blir til slutt en flex liste med checkboxer av hvert tema. Komponenten representerer siden i modalen hvor man velger tema. FormTypePage Denne representerer siden i modalen hvor man velger type oppgave. Den bruker SelectGrade og PickDifficulty komponentene. Tar også inn en liste over oppgave-typer som brukes til å lage et FieldArray på samme måte som FormTopicPage. Pageinator Komponenten tar inn sidenummer og totalt antall sider, og viser hvilken side man befinner seg på. ShareLink Viser del-linken med knapp på venstre side. Tar inn en string som inneholder linken. (Ikke i bruk i versjon 1). TaskPicker Dette er en mer kompleks komponent, med mange props: choosetasks: funksjon for å velge de valgte oppgavene tasks: liste over alle oppgaver showmore: boolean for å bestemme om knapp som gjør at man kan vise flere oppgaver skal vises types: alle oppgave-typer topics: alle temaer filter: funksjon for å utføre en filtrering sorting: et objekt av typen Sorting(se [SORTING OBJEKT BESKRIVELSE]) hiddensort boolean om sorteringsmenyen skal vises eller ikke handesortingchange: funksjon for å utføre en endring i sorteringsmenyen loaded: boolean som sier om oppgaver er lastet eller ikke maxitems: maks antall oppgaver som skal vises searchchange: funksjon for å utføre en endring når man skriver i søkefeltet 59

60 isselected: boolean for å sjekke om oppgaven er valgt hiddenfilter: boolean for å sjekke om filtermenyen skal vises eller ikke toggleshowmorefilters: funksjon for å åpne og lukke filtermenyen Komponenten brukes for å vise en oppgavevelger da man enten vil lage et nytt oppgavesett, eller legge til en oppgave i et oppgavesett. Komponenten bruker også SearchBar, SortDropdown, Filters og TaskList(se egen dokumentasjon). TaskProperties Denne komponenten viser en oppgave sine temaer, typer, klassetrinn og vanskelighetsgrad. Den tar inn følgende props: grade: integer som beskriver hvilket klassetrinn types: liste over alle oppgave-typer difficulty: integer vanskelighetsgrad topics: liste over alle emner TaskSetProperties Denne fungerer nesten på samme måten som TaskProperties, bare at den tar inn alle oppgaver i oppgavesettet, siden det er oppgavenes temaer, emner og vanskelighetsgrader som skal brukes til å beskrive oppgavesettet. Props: tasks: liste av tasks grade: integer klassetrinn TaskViewer 60

61 Denne brukes til å vise selve oppgaven i en oppgave, altså beskrivelsen og deloppgavene. Den tar inn følgende props: title: string tittel på oppgaven subtask: liste av alle deloppgaver link: string link tools: string nyttige verktøy description: string beskrivelse av oppgaven TopBarButtons Denne komponenten inneholder alle knapper som skal være tilgjengelig øverst i høyre hjørne da man viser en oppgave eller oppgavesett. Får inn følgene props: onfavouriteclick: funksjon for å utføre et klikk på favoritt isfavourite: boolean som bestemmer om oppgaven er klikket på TopBarRating Denne brukes helt øverst hvor man viser en oppgave eller oppgavesett, til å vise ratingen til oppgaven(ikke i bruk i første versjon, tar derfor ikke inn noen props) RenderFields(Common) Disse komponentene er de som sendes inn i Field-komponenten (se ReduxForm) til å vise input-felter i ReduxFormet. De komponentene som tar inn label, bruker label til å vise en overskrift over hva komponenten viser. Alle komponentene tar også inn metadata som brukes til å validere input-feltene. PickDifficulty Denne brukes til å skrive ut radio buttons for å velge vanskelighetsgrad. Tar inn input, som kommer fra FieldArray, som brukes for å bestemme navnet til inputfeltet. PickTopics Denne komponenten brukes til å lage checkboxer med label for alle temaer. Tar inn alle temaer som det skal lages checkboxer av. 61

62 PickType Fungerer på samme måte som PickTopics, bare at den tar inn oppgavetyper i stedet. SelectGrade Brukes for å lage en select med alle klassetrinn som kan velges. Den tar inn input fra FieldArray komponenten, og importerer Grade (se Declarations). SelectTaskSet Denne tar inn en liste over oppgavesett og lager en select-dropdown med titlene på disse oppgavesettene, bruker oppgavesettets id som verdi. TextInput Et helt vanlig text input-felt. Tar inn type som sier hva slags input type som skal lages og en placeholder-tekst. TitleInput Samme som TextInput, men med annen styling siden dette er for tittel SearchBar(Common) SearchBar Denne komponenten lager input-feltet som brukes for å søke. Her har det blitt gjort en glipp siden dette er en ES6 klasse, så den hadde egentlig bare trengt å være en const. Den får inn en searchchange, som brukes for å behandle endringer i søkefeltet. 62

63 TaskList(Common) Disse komponentene tilhører listen til oppgavene og oppgavesettene som vises. TaskList Dette er selve listen over oppgaver og oppgavesett, den tar inn følgende props: tasks: liste over oppgaver loaded: boolean som brukes for å sjekke om data er hentet istaskpicker: boolean for å sjekke om listen er en del av TaskPicker komponenten (se TaskPicker). maxitems: integer med maks elementer som skal vises showmore: boolean for å sjekke om vis flere isselected: boolean for å sjekke om en oppgave er valgt Komponenten bruker også en Spinner som er installert via npm(dokumentasjon: og TaskListEmpty(se TaskListEmpty). Hvis data er hentet og tasks sin lengde er mindre enn 1, vil TaskListEmpty komponenten vises, hvis data ikke er hentet vil spinneren vises for å illustrere at data hentes. TaskListEmpty Denne komponenten brukes for å vise en melding til brukeren om at listen er tom, den tar inn en melding om hva som skal vises til brukeren Header Dette er komponenter som brukes i headeren til siden 63

64 Header En enkel komponent som viser headeren til applikasjonen, tar ikke imot noen props. Info Dette er en komponent som viser en boks med info om kunden og logg-ut-knapp. Den tar i mot følgende props: infopreviewclass: string som forteller om boksen skal være aktiv eller ikke exit: funksjon for å endre på infopreviewclass ProfileInfo Denne er ikke i bruk i første versjon. Den skal brukes for å logge ut, vise hvem som er logget inn og navigere til min profil siden Task Dette er komponentene som kun brukes i Task containeren. TaskHover Denne komponenten fungerer som en wrapper for en TaskViewer. Den har en id som brukes for å hente posisjonen slik at man kan få den til å følge musens posisjon da man hoverer over en bestemt knapp, dette er implementert i Task containeren (se Task). TaskPreview 64

65 Denne komponenten er en modal som viser all informasjon om en oppgave, den bruker også TopBarButtons, TaskProperties og TaskViewer komponentene. Tar inn følgende props: onfavouriteclick: funksjon for å sette oppgaven som favoritt isactive: string som bestemmer om modalen skal være aktiv eller ikke exit: funksjon for å skjule modalen isfavourite: boolean for å sjekke om oppgaven er favoritt TaskSet TaskSetPreview Denne fungerer på samme måte som TaskPreview, men er noe mer kompleks, siden den viser forskjellig innhold basert på om oppgavesettet inneholder oppgaver eller ikke. Får inn følgende props: onfavouriteclick: funksjon for å sette oppgavesettet som favoritt isactive: string som forteller om modalen skal være aktiv exit: funksjon som gjør at man skjuler modalen isfavourite: boolean som sjekker om oppgaven er satt som favoritt title: string tittel på oppgavesettet description: string beskrivelse av oppgavesettet tasks: liste over oppgaver i oppgavesettet 65

66 TopBar Dette er alle komponentene som brukes i top-baren som ligger over oppgave-listen og under headeren Menus (AddToMenu, NewMenu) Dette er menyene som brukes til å velge om man vil lage nytt oppgavesett eller oppgave, legge til oppgave i oppgavesett, eller legge til som favoritt. De får inn en boolean for å bestemme om den skal vises eller ikke. De får også inn en funksjon for hver knapp for å bestemme hva som skal skje etter hvilken knapp som blir trykket. NewButton Viser en knapp inne i meny komponentene, tar inn en string tittel på knappen og string icon som sier hvilken font awsome ikon som skal brukes. SortDropdown Denne komponenten viser en dropdown med de sorteringene som er tilgjengelig. Den tar imot en boolean hidden, som brukes til å bestemme om den skal vises eller ikke, og en onclick som beskriver hva som skal skje da en sortering blir valgt. 66

67 Modal(Common) Denne komponenten er en modal som legges på toppen av det innholdet som befinner seg på siden. Den inneholder containerene TaskForm, TaskSetForm og TaskSetForm for å legge til en oppgave i et oppgavesett. Den viser det formet som blir bestemt av modalclass.modal, som er et Objekt av ModalType (se Declarations). Den tar også i mot følgende props: modalclass: et objekt som inneholder en string: class og type: ModalType exit: funksjon for å lukke modalen updatetasklist: funksjon for å oppdatere listen over oppgaver som skal vises types: liste over alle oppgave-typer topics: liste over alle emner loaded: boolean for å sjekke om data er hentet isselected: boolean for å sjekke om en oppgave er valgt Containers Containers er de som styrer alle komponentene. Disse er laget med ECMAScript 6 klasser og extender React.Component, som har en livssyklus hvor den mountes, oppdateres og unmountes. Disse har en state, som kan oppdateres og endres, som trigger forskjellige metoder i containerene. React.Component tilbyr forskjellige metoder, som trigges på spesifikke tidspunkt. Mount metodene blir kalt når containeren lages og puttes inn i DOM en. Oppdateringsmetodene blir kalt når det skjer endringer i enten props eller state og unmount metodene kalles når en komponent fjernes fra DOM. Under ser du en oversikt over de viktigste metodene: Mount: constructor() o En vanlig konstruktør static fetchderivedstatefromprops() o Denne kalles når en container blir initiert. Denne metoden kan brukes til å returnere et objekt for å oppdatere en containers state, eller returnere null for å indikere at nye data ikke behøver å oppdatere state. componentwillmount() o Denne kalles rett før mountingen skjer, og før render kalles. componentdidmount() o Denne kalles rett etter en container er initiert render() o Når denne kalles, sjekker den props og state og returnerer enten et React element(det vi omtaler som en komponent), string og numre, en portal(vi har ikke brukt React portals, derfor forklarer vi ikke dette noe nærmere), null eller booleans Update: render() o Beskrevet over componentdidupdate() o Denne kalles rett etter en oppdatering av state eller props skjer. 67

68 Unmount: componentwillunmount() o Denne kalles rett etter en container fjernes fra DOM Et annet viktig funksjon som kommer med en React.Component, er setstate(). Denne metoden kalles da man vil gjøre endringer i state, som igjen trigger render() metoden, slik at DOM blir oppdatert med de nye dataene i state. I figur 50 kan man se et eksempel på hvordan vi henter inn alle emner og type oppgaver fra databasen med en componentwillmount(), disse dataene skal vises frem i en komponent. Figur 50 - componentwillmount I figur 51 ser man hvordan en render metode returnerer et JSX React element. Denne metoden kalles ved endringer i state (med setstate() metoden), slik at DOM blir oppdatert med de nye dataene. Figur 51 - return av et JSX element Nederst i containererne kan man finne metodene mapdispatchtoprops og mapstatetoprops. Disse er en del av Redux pakken. Metodene brukes til å binde actions til propsene til containeren og staten til containeren til reduceren. Under får du en introduksjon til alle containerene, pluss bilde der vi synes det var hensiktsmessig. 68

69 Filter FilterButton Denne containeren er parent for alle filtrerings-checkboxer. Den inneholder en state som sier om den er valgt eller ikke og om den skal vises som checked eller ikke. Den får inn funksjonen filter som brukes for å gjennomføre en filtrering da brukeren trykker på en checkbox. Filters Dette er containeren til alt som har med filtreringsfunksjonalitet å gjøre. Den har en funksjon for hver av filtreringene som er mulig, og rendrer en FilterModal og FilterSidebar basert på om filtermenyen hører til side-menyen, eller en modal Home Home Dette er containeren til landingssiden, og styrer hele løsningen, da dette er den eneste siden som er implementert enda. Den henter alle initielle data som er nødvendig i de andre containerene og komponentene og sender disse dit de trengs. Den renderer en Header, Sidebar, Topbar, TaskList og en Modal. Den inneholder også mye kjernefunksjonalitet som sendes til andre containers og komponenter Login LogInForm Denne er ikke i bruk i nåværende versjon. Det var ment at denne skulle styre innloggingssiden, men denne blir nå håndtert av CAS ProfileInfo ProfileBar Dette er containeren til knappene hvor man kan vise Info og ProfileInfo komponentene. I nåværende versjon er bare Info-komponenten som renderes Sidebar Sidebar Dette er containeren til sidemenyen på landingssiden. Den renderer menyen hvor man kan velge om man vil vise alle oppgaver eller bare dine egne, og en Filters container som igjen 69

70 renderer enten en FilterSidebar eller en FilterModal ettersom hva den hører til. Den inneholder primært funksjonalitet for å bytte mellom alle og mine oppgaver Task Dette er containerene som har med en oppgave å gjøre, det vil si både visningen av oppgaver og skjemaet for å lage en ny. Den inneholder alle sidene i skjemaet og en validate fil som validerer all input i skjemaet Task Task containeren inneholder all informasjon om en oppgave og funksjonalitet for å åpne en oppgave og lignende. Den renderer kortet brukeren får se av en oppgave. Den renderer også en TaskPreview og TaskHover. TaskPreview vises når isactive blir satt til true. TaskHover vises da musen er over forhåndsvisningknappen. TaskForm Denne containeren styrer hele skjemaet som brukes for å lage en ny oppgave. Den inneholder metoder for navigering, publisering og sletting av deloppgaver. Den renderer en Pageinator med side 1, 2, 3, 4 eller 5 ettersom hvilken side man befinner seg på. Validate Validate filen er ikke en container, men en const som tar imot alle verdier som finnes i skjemaet som det blir knyttet opp mot. Forbindelsen mellom validate filen og formet skjer i en funksjon som kommer med ReduxForm. Validate filen returnerer et objekt som inneholder feilmeldinger der input ikke er gyldig. TaskPage1 Dette er side 1 i skjemaet for å lage en ny oppgave. Den tar inn følgende props: handlesubmit: funksjon for hva som skal skje når man trykker submit addsubtaskrow: funksjon for å legge til en ny deloppgave removesubtaskrow: funksjon for å fjerne en deloppgave subtaskrows: integer hvor mange subtask rows som eksisterer page: integer side man befinner seg på i formet subtasks: Objekt med deloppgavene total: totalt antall sider i formet Siden lar deg lage tittel, beskrivelse og deloppgaver. TaskPage2 70

71 Side 2 i skjemaet for å lage en ny oppgave. Tar inn følgende props: handlesubmit: funksjon for hva som skal skje når submit blir trykket types: liste over alle oppgavetyper page: hvilken side man befinner seg på i skjemaet previouspage: funksjon for å gå til forrige side total: integer hvor mange sider det er totalt i skjemaet Denne siden lar deg velge vanskelighetsgrad, klassetrinn og oppgavetype. TaskPage3 Side 3 i skjemaet, tar inn følgende props: handlesubmit: funksjon for hva som skal skje når submit blir trykket topics: liste over alle temaer page: integer hvilken side man befinner seg på previouspage: funksjon for å gå til forrige side total: integer hvilken side man befinner seg på i skjemaet Siden lar deg velge hvilke temaer som inngår i oppgaven. TaskPage4 Side 4 i skjemaet, tar inn følgende props: handlesubmit: funksjon for hva som skal skje når man trykker submit page: integer hvilken side man befinner seg på i formet previouspage: funksjon for å gå tilbake i skjemaet total: integer hvor mange sider skjemaet består av totalt Siden lar deg fylle inn forskjellige informasjon om oppgaven, f.eks nyttige verktøy og link TaskPage5 Side 5 i skjemaet, tar inn følgende props: handlesubmit: funksjon for hva som skal skje når submit blir trykket task: Objekt av en oppgave page: integer hvilken side man befinner seg på previouspage: funksjon for å gå til forrige side total: integer totalt antall sider i formet Denne siden viser en oversikt over oppgaven brukeren akkurat har opprettet, før den publiserer i ematte SubTaskGenerator Denne brukes i TaskPage1 for å generere deloppgaver. Den tar inn et array bestående av hele alfabetet, og en index, som er nummeret på deloppgaven. TextAreaInput Input felt for et textarea, tar inn placeholder, input og meta fra Field komponenten. TextInputLogo 71

72 Samme som TextInput, bare med et ikon som på venstre side TaskSet Dette er containerene som styrer et oppgavesett og skjemaet for å lage et nytt oppgavesett. Inneholder også alle sidene til skjemaet og en validate fil for å validere inputen fra skjemaet. TaskSet Styrer et oppgavesett og alt den inneholder. Den renderer et oppgavesett-kort og en TaskSetPreview. TaskSetPreview vises da isactive blir satt til true i state. TaskSetForm Denne containeren behandler alt som har med å lage nytt, eller legge til en oppgave i et oppgavesett å gjøre. Den inneholder filtreringsfunksjonalitet, navigering og andre funksjoner som trengs for å oppdatere oppgavelisten og lignende. Den renderer en Pageinator og TaskSetPage 1 og 2 etter hvilken side man befinner seg på. Validate Validate filen gjør det samme som i Task, se Validate(se Task) TaskSetPage1 Dette er side 1 i skjemaet for å lage nytt oppgavesett. Noe mer kompleks en TaskPage1 siden denne har filtrering og oppgaveliste. Tar inn følgende props: handlesubmit: funksjon for hva som skal skje når submit trykkes page: integer hvilken side det er i formet total: integer totalt antall sider i skjemaet tasks: liste over oppgaver choosetasks: funksjon for å velge valgte oppgaver chosentasks: liste av alle valgte oppgaver showmore: funksjon for å vise fler oppgaver i oppgavelisten maxitems: integer maks antall oppgaver som skal vises i oppgavelisten isdisabled: boolean om fjern valgte knappen skal være disabled eller ikke toggleisdisabled: funksjon for å sette isdisabled til true eller false removetasks: funksjon for å fjerne valgte oppgaver showremovebutton: boolean for å sjekke om fjern valgte knappen skal vises showemptytaskset: boolean for å sjekke om oppgavesettet er tomt modaltype: Objekt av ModalType(se Declarations) tasksets: liste av oppgavesett switchtonewtaskset: funksjon for å bytte modal fra legg til i til ny topics: liste av temaer types: liste av oppgave-typer filter: funksjon for å utføre en filtrering sorting: Objekt av Sorting(se Declarations) hiddensort: boolean for å sjekke om sorteringsmenyen skal vises eller ikke handlesortingchange: funksjon for å utføre en endring i sortering 72

73 handlesortdropdownclick: funksjon for hva som skal skje når sorteringsdropdownen klikkes på taskamount: integer antall oppgaver loaded: boolean for å sjekke om data er hentet searchchange: funksjon for å behandle en endring i søkefeltet isselected: boolean for å sjekke om en oppgave er valgt hiddenfilter: boolean for å sjekke om filtreringsmenyen skal vises toggleshowmorefilters: funksjon for å vise og skjule filtreringsmenyen Denne siden brukes for å velge oppgaver til å enten legge til en oppgave i et eksisterende eller i et nytt oppgavesett. Her kan man også filtrere, søke og sortere på samme måte som på landingssiden. TaskSetPage 2 Dette er side 2 i skjemaet, den viser en oversikt over oppgavesettet som er lagd. Tar inn følgende props: handlesubmit: funksjon for hva som skal skje når submit trykkes på taskset: Objekt et oppgavesett page: integer hvilken side det er i skjemaet previouspage: funksjon for å gå til forrige side i skjemaet total: integer totalt antall sider i skjemaet Topbar Dette er containeren til top-baren som ligger i mellom headeren og oppgavelisten på landingssiden. Den inneholder menyen med knappene legg til i... og ny.... Den inneholder også et søkefelt og en SortDropdown Reducers En reducers oppgave er å ta imot hvilken type action som blir sendt fra en komponent. De returnerer deretter de dataene man velger å returnere. Om det er en feilmelding om at man ikke kunne hente data, eller de nye dataene som er hentet er korrupte, vil man for eksempel kunne sende en feilmelding til brukeren. I figur 52 ser man hvordan en switch bestemmer hva som skal returneres til store. Figur 52 - reducer 73

74 Alle reducerene blir eksportert i en combinereducers, som er en del av Redux pakken. Denne blir deretter sendt til Store, som gjøre det mulig å hente ut dataene i andre containere. Dette gjøres i en fil kalt rootreducer. I figur 53 ser man hvordan det vil se ut Figur 53 rootreducer Common Under kan du lese om de forskjellige reducerene som brukes på forskjellige steder i løsningen. AllTopicsReducer Returnerer et tomt objekt hvis den mottar en request, og returnerer data som er kommet inn ved suksess. Brukes for temaer. AllTypesReducer Returnerer et tomt objekt hvis den mottar en request, og returnerer data som er kommet inn ved suksess. Brukes for oppgavetyper. ModalReducer Denne reduceren brukes for å bestemme hvilken modal-type som skal være aktiv. Returnerer uansett data om den skal skjules eller gjemmes. PickGlobalTaskReducer Denne reduceren brukes for å lagre valgte oppgaver fra landingssiden i store, slik at disse oppgavene er mulig å hente ut andre steder. Den pusher oppgaven ut i arrayet hvis den legges til, filterer vekk hvis den skal fjernes og returnerer et tomt objekt hvis den resettes. PickGlobalTaskSetReducer Denne brukes for å lagre hvilke oppgavesett som er valgt på landingssiden, oppfører seg på samme måte som PickGlobalTaskReducer. 74

75 PickSelectedTaskReducer Brukes for å lagre hvilke oppgaver av de som er valgt i et oppgavesett, som er valgt av brukeren, slik at disse kan fjernes igjen. Oppfører seg på samme måte som PickGlobalTaskReducer. PickTaskReducer Brukes for å lagre hvilke oppgaver som velges fra TaskPicker, slik at disse kan legges til i et oppgavesett. Oppfører seg på samme måte som PickGlobalTaskReducer Task, TaskSet og User Reducerene i Task, TaskSet og User fungerer helt likt og velger derfor ikke å gå inn på hver av reducerene i nærmere detalj. Alle returnere tomt under en request, og returnerer data ved suksess. For å se nøyaktig hva som blir sendt til reducerene og hva de returnerer, se Actions Actions Actions beskriver hva som skal gjøres ved en bestemt hendelse. Det er denne som forteller hva som skal sendes og returneres til og fra reduceren ved hjelp av en dispatch metode. Figurene i Redux viser hvordan en fullstendig action ser ut. En action trenger ikke nødvendigvis å gjøre en dispatch til en reducer. For å se format på hvordan dataene blir returnert fra alle actions som utfører et API-kall, se Restendepunkter. Under vil du kunne finne mer om hva hver enkelt action gjør Common CombineLists Denne action tar inn en liste av oppgaver, oppgavesett, favoritt-oppgaver og favorittoppgavesett. Den setter typen på oppgaver og oppgavesett, og hvilke av de som er favorisert av brukeren. Deretter returnerer den et samlet array bestående av oppgaver og oppgavesett. DuplicateRemover Denne tar inn en liste av oppgaver og en property. Property er en string sier om det er emne, oppgave-type eller vansklighetsgrad. Deretter fjerner den alle duplikater i arrayet, og returnerer et array med kun distinkte verdier. FetchAllTopics Denne action henter alle emner fra databasen. Den sender type action som blir utført pluss dataene som har blitt hentet til reduceren. FetchAllTypes 75

76 Denne action henter alle oppgavetyper fra databasen. Den sender type action som blir utført pluss dataene som har blitt hentet til reduceren. FilterList Denne action utføres for å filtrere på en liste av oppgaver, oppgavesett eller begge deler. Den tar inn en liste av oppgaver, oppgavesett eller begge deler pluss arrays av hvert filter. Den tar også inn FilteredTypes som er et array bestående av hvilke filtreringer som er aktive. Dette arrayet består av objekter av FilterTypes objektet(se Declarations) Metoden fungerer på den måte at den kjører gjennom en foreach-løkke på hver av filter typene og filtrerer listen av oppgaver eller oppgavesett som ble sendt inn i metoden basert på alle de aktive filtreringene. Deretter returneres den filtrerte listen. GradeCheck Denne action brukes for å lage en beskrivende string av klassetrinnet ute i DOM. Tar inn en integer av klassetrinn og returnerer en beskrivende string. PickGlobalTask, PickGlobalTaskSet, PickSelectedTask, PickTask Denne brukes til å legge til, fjerne eller resette reduceren i store bestående av valgte oppgaver eller oppgavesett. De tar inn en oppgave eller oppgavesett og type action som skal utføres. Deretter dispatcher den en type action basert på typen som er kommet inn som innparameter, sammen med oppgaven. Hvis reset er valgt, sendes bare typen action til reduceren, som igjen resetter arrayet. SortList Denne action brukes for å sortere en liste av oppgaver eller oppgavesett. Den tar imot en liste og et objekt av Sorting(se Declarations). De gjør en switch på sorting-objektet og returnerer den sorterte listen. ToggleModal Denne action viser og skjuler modalen. Den tar inn et klassenavn, som er enten en tom string, eller is-active som bulma.io bruker for å sette en modal aktiv. Den dispatcher type modal og om den skal være aktiv eller ikke Task Dette er actions som omfatter kun oppgaver AddTasksToFavourites Dette er en action for å sette flere oppgaver som favoritt samtidig. Den tar inn et array av oppgave ID-er og gjør et API-kall med disse ID-ene i bodyen til API-kallet. AddTaskToFavourites 76

77 Denne brukes til å legge en enkelt oppgave inn som favoritt. Den tar inn en ID og sender denne som parameter i URL-en til API-kallet. CreateTaskDTO Brukes til å lage en domenemodell av en oppgave(se Domenemodell). Den tar imot values som er et assosiativt array bestående av verdier fra TaskForm. Her settes alle verdier som skal sendes til backend, og deretter returnerer den objektet. FetchAllTasks Henter alle oppgaver fra backend og dispatcher disse til reducer. FetchFavouriteTasks Henter alle favoriserte oppgaver fra backend og dispatcher disse. FetchPublishedTasks Henter alle publiserte oppgaver fra backend og dispatcher disse. FetchTask Brukes for å hente en bestemt oppgave fra backend. Tar inn en ID som sendes med som parameter i API-kallet. FetchUserTasks Henter alle oppgaver som hører til den innloggede brukeren. Dispatcher dataene til reduceren. RemoveTaskFromFavourites Tar inn en ID på hvilken oppgave som skal fjernes fra favoritter og sender den i en API-kall mot backend. SubmitNewTask Brukes for å lagre en oppgave i databasen. Tar inn en modell av en oppgave(se Domenemodell) og utfører et API-kall med modellen i body TaskSet AddTaskSetsToFavourites Brukes for å sette flere oppgavesett som favoritt samtidig, tar inn et array av ID-er og sender disse med bodyen til API-kallet. AddTaskSetToFavourites 77

78 Brukes for å sette et enkelt oppgavesett som favoritt. Tar inn en ID på et oppgavesett og sender dette med som parameter i URL-en til API-kallet. CreateTaskSetDTO Brukes for å lage en domenemodell av et oppgavesett. Tar imot values som er et assosiativt array med alle verdier fra oppgavesett-skjemaet. Tar også inn tasks som er de oppgavene som skal legges inn i oppgavesettet, og taskset som representerer det oppgavesettet det skal legges inn oppgaver i. Returnerer et objekt av et oppgavesett. FetchAllTaskSets Henter alle oppgavesett fra backend og dispatcher disse til reducer. FetchFavouriteTaskSets Henter alle favoriserte oppgavesett og dispatcher disse til reducer. FetchPublishedTaskSets Henter alle publiserte oppgavesett og dispatcher disse til reducer. FetchTaskSet Henter et bestemt oppgavesett basert på ID. Tar inn en ID som parameter og sender denne som parameter i URL-en i API-kallet. FetchUserTaskSets Henter alle oppgavesett som tilhører den innloggede brukeren og dispatcher disse til reducer. RemoveTaskSetFromFavourites Brukes til å fjerne et oppgavesett fra favoritter basert på ID. Tar inn en ID og sender denne med som parameter i URL-en til API-kallet. SubmitNewTaskSet Sender en modell av et oppgavesett til backend for å lagre dette i databasen. Tar inn oppgavesettet som inn-parameter og sender dette i body i API-kallet User Disse actionene har med brukeren å gjøre, som innlogging og utlogging. AuthUser Denne kaller authorize i backend og sjekker om brukeren er autorisert. Hvis brukeren ikke er autorisert, dvs at man får tilbake en 403 HTTP status, blir man returnert tilbake til login- 78

79 siden. Ellers returneres brukerinformasjonen til reducer og brukeren får fortsette å bruke løsningen. LogOut Gjør et kall til backend som logger brukeren ut av applikasjonen. ShowInfo Denne brukes til å vise og skjule Info-komponenten(se Header) med enten å dispatche is-hidden eller en tom string. ShowProfileInfo Denne brukes til å vise og skjule ProfileInfo komponenten(se Header) med enten å dispatche is-hidden eller en tom string Declarations Declarations er en fil som vi har brukt til å definere typer av forskjellige egenskaper, entiteter og linker som skal taes i bruk. Dette forenkler vedlikehold og gjør det mulig å enkelt bytte mellom test og produksjonsmiljø da løsningen bruker for eksempel innloggings linker fra Declarations filen. En annen fordel er at det gjør koden mye mer leselig, da vi kan lage beskrivende navn på objektene. Vi har brukt JavaScript s Object.freeze(), som lager et objekt som ikke er mulig å endre på. Fungerer som en slags enum, men denne datatypen brukes ikke i JavaScript. Objektene i Declarations filen: Objekt TaskType Grade FilterTypes Beskrivelse Forteller om det er en oppgave, oppgavesett eller favoritt Sier hvilket klassetrinn Inneholder alle mulige filtreringsmuligheter TaskSelectType Beskriver om man vil legge til, fjerne eller resette et array Sortings SSOLink API Inneholder alle sorteringsmuligheter Dynamiske logg in og logg ut linker Dynamisk link som skal brukes for API-kall 79

80 2.6 Testrapport Innledning Testingen skal sørge for at brukeren av applikasjonen, skal kunne gjøre alt som forventes av løsningen, på en god måte uten avbrytelser fra systemet. Man skal kunne se alt som løsningen skal kunne gjøre, se 1.7 Kravspesifikasjon. I backend er alle metoder dekket av enhetstester, mens frontend har vi tatt i bruk andre testteknikker, dette får du lese mer om i dette kapittelet Teststrategi og metoder Vi har brukt både statisk, erfaringsbasert, enhet, integrasjon og systemtesting. Her vil vi gå igjennom de testmetodene som vi har brukt, hvorfor vi har brukt de og hvordan Eksplorativ testing Dette er en testmetode som går hovedsakelig ut på testers erfaringer og kunnskap. Man tester ut funksjonalitet der man tror at noe feil kan skje, slik at feil blir avdekket. Dette er en svært billig og enkel testmetode, men veldig effektiv hvis testeren har bred kunnskap om både domene, teknologi og testing. Måten vi utførte dette på var å ta i bruk et QA-UX felt i JIRA(se JIRA). Da en brukerhistorie ble lagt hit, ble den testet av bachelorgruppa og vår UX ressurs. Her prøvde vi å trigge feil i løsningen. Hvis en feil ble funnet ble den kommentert og lagt tilbake i In progress Automatisk analyse Automatisk analyse går ut på at koden blir automatisk analysert av et program kontinuerlig. I vårt tilfelle foregikk dette med IntelliJ sitt analyseringsverktøy. Denne vil kontinuerlig fortelle utvikleren om feil og mangler i koden. Dette kan være alt fra en ubrukt variabel, til utradisjonelle programmerings-strukturer. Vi satt også opp IntelliJ til korrekt konfigurasjon i forhold til språkene vi skrev, slik at den ville gi beskjed hvis noe var feil Manuell kontroll Denne teknikken går ut på å manuelt se og granske egen og andres kode. Dette er også en svært billig, men effektiv måte å utføre testing på, særlig i starten da mange av teknologiene var veldig nye for oss. Måten vi utførte denne type testing på, var å gjennomføre QA på all kode som ble skrevet. Dette ble organisert i JIRA(se [LINK TIL PROSESS]). Slik kunne vi gå over hverandres kode, og spørre hvorfor og hvordan noe ble løst, hvis det var noe usikkerhet. 80

81 Debug Både i backend og frontend brukte vi forskjellige debugging verktøy for å finne feil i kildekode. I frontend brukte vi Chrome s innebygde utviklerverktøy, som lar utvikleren debugge på forskjellige måter. Den mest brukte var console.log(inn-parameter), som skriver ut det man gir som inn-parameter i konsollen i Chrome s utviklerverktøy. I backend, brukte vi Java sin System.out.println(inn-parameter) for å konsoll logge verdier som vi trengte å teste at var korrekte. Dette brukte vi kontinuerlig i utviklingen, slik at vi tydelig kunne se hvordan dataene flyter og modifiseres underveis i løsningen Enhetstesting I backend er alle lag dekket 100% av Code Coverage, det vil si DAO, Service og REST. Det eneste som ikke har 100% dekning, er modellene og andre diverse konfigurasjons og oppsett-filer. For enhetstestingen satt vår tekniske arkitekt opp en test-konfigurasjon som bruker en in-memory database, hvor vi putter inn data da man kjører testene med en.yml fil. Vi benytter IntelliJ sin egen implementasjon for testing og Spring Boot s test annotasjoner og et rammeverk kalt Mockito 20 for å mocke metoder og data for testene. Figur 54 - mock av TaskDAO Figur 55 - enhetstest fra TaskServiceTest På figurene 54 og 55 kan vi se et eksempel på enhetstesting av TaskService ved hjelp av Mockito. På figur 54 mocker vi en TaskDAO, og på figur 55 lager vi et nytt TaskEntity-objekt som blir returnert når testen kaller på taskdao.gettask ved hjelp av Mockito sin when().then(). På den måten kan vi teste om metoden i servicelaget oppfører seg som den skal. 20 Mockito, udatert 81

82 Prosedyre Testene skal lages i samsvar med funksjonene i systemet og all stubbede data skal returnere gyldige verdier, for at testene skal bli så korrekte som mulig. Det er også viktig at stubbet data har riktige datatyper som samsvarer med domenemodellene. Kriteriene for at testene er godkjent, er at alle tester kjører grønt, og at alle lagene i løsningen har 100% code coverage. Alle metoder som ble laget i applikasjonen, skulle alltid bli testet med en gang, og kjøre grønt før koden ble satt til done. Underveis da endringer ble gjort kunne det oppstå feil som gjorde at tidligere tester feilet. Denne måtte da fikses opp i, slik at alle tester alltid kjørte grønt til alle metoder. Testene ble kjørt flere ganger om dagen, da det ble jobbet med backend, slik at vi visste at alt fungerte som det skulle etter endringer ble gjort. Figur 56 viser hvordan testene ser ut i IntelliJ da de kjører grønt, figuren er bare et eksempel og illustrerer ikke alle, eller fullstendige enhetstester. Figur 56 - slik ser godkjente tester ut Integrasjonstesting Integrasjonstestingen vi har utført, er testing mot vårt eget API. Alle restendepunker som ble lagd, ble returverdien av API-kallet testet med Postman(se Postman). Dette er et verktøy hvor man kan velge metode, body, headers, authentication mm. og kalle på API-er og få tilbake verdien. Man kan teste både metoder som returnerer og metoder som tar imot data for å f.eks. sette dataene inn i en database. Dette gjorde også at vi kunne sjekke at metodene returnerte korrekte verdier på korrekt format, før man brukte API-et i frontenden. Da vi gjorde kall med Postman til vårt API, valgte vi metode, som kan være enten GET, POST, PUT eller DELETE, headers og eventuelt body. Figur 57 viser hvordan dette vil se ut i Postman 82

83 Figur 57 - postman GET kall Der vi testet API-kall hvor man for eksempel skulle persistere en oppgave, sendte vi med oppgaven i body. Da mocket vi en TaskEntity(se Logisk datamodell) og sjekket på responskoden vi fikk tilbake. Var responsen 201(created), var kallet suksess. Figur 58 viser hvordan en test med body vil se ut. Figur 58 - postman POST kall med body Postman er også en fin måte å regresjonsteste 21 på. Hvis noen har gjort en endring på en service eller lignende, som blir brukt av REST laget, kan man bruke Postman til å sjekke at dataene fortsatt blir returnert på riktig måte i riktig format. 21 Regresjonsteste å teste noe om igjen 83

84 Systemtesting For å sikre at applikasjonen oppførte seg som forventet gjennomførte vi jevnlig systemtesting på applikasjonen. Vi brukte en utvidelse i Mozilla Firefox som heter Selenium IDE til å gjøre opptak av funksjonalitet, og ved å kjøre testene vil Selenium automatisk kjøre gjennom testene og utføre dem på applikasjonen. Dersom den kjører gjennom og returnerer suksess vet vi at funksjonaliteten er i orden. Ved hjelp av systemtesting avdekket vi feil på et mye tidligere tidspunkt enn om vi ikke hadde testet. Vi opplevde til tider at ny funksjonalitet kunne gjøre at annen funksjonalitet oppførte seg annerledes eller ikke ville virke lenger. Istedenfor å måtte gjennomgå all funksjonalitet som er blitt lagt til i løpet av sprinten kunne vi bare falle tilbake til forrige gang systemtest var blitt gjennomført og lete etter feilen. Figur 59 - slik ser selenium ut Innlogging Selenium sendes til applikasjonen og logger inn. Deretter verifiserer den om den finner tittelen ematte og returnerer suksess. Lage en oppgave En oppgave blir laget og returnerer suksess dersom den finnes i oppgavelista med riktige input-verdier. 84

85 Lage et oppgavesett Samme som testen over, men for oppgavesett. Ny oppgave: Sjekke validering Sjekker om valideringen på tekstfelt virker som den skal og ikke tillater at bruker oppretter oppgaver med mindre valideringen er godkjent, og returnerer suksess når alle feilmeldinger har blitt funnet. Nytt oppgavesett: Sjekke validering Samme som testen over, men for oppgavesett. Legge til oppgave i oppgavesett Oppretter først en oppgave og et oppgavesett og forsøker å legge til oppgaven i oppgavesettet. Sjekker deretter om oppgaven befinner seg i oppgavesettet og returnerer suksess. Sortere oppgaver Oppretter tre oppgaver og sjekker om disse legger seg i forventet rekkefølge når man sorterer etter eldste og nyeste. Filtrere oppgaver Oppretter fire oppgaver med ulike temaer og klassetrinn og putter disse inn i et oppgavesett. Filtrerer deretter på de ulike temaene og klassetrinnene og verifiserer at de dukker opp i lista. Deretter filtreres det på alle temaene til oppgavene i oppgavesettet og verifiserer at oppgavesettet dukker opp i lista. Returnerer dermed suksess. Søke etter oppgaver Oppretter tre oppgaver med ulike navn og søker etter disse. Returnerer suksess når alle tre oppgavesettene er funnet. Utlogging Logger bruker ut og verifiserer at brukeren må logge inn igjen ved å verifisere at man returneres til innloggingssiden Brukertester Applikasjonen skal lages for at lærere skal få sin hverdag forenklet ved å lett kunne finne fram til oppgaver. Det er viktig å tenke på at det er et vidt spekter av lærere, også de som er litt opp i årene, som skal bruke dette. Derfor må man gjennomføre brukertesting slik at man er sikker på at brukerne forstår hvordan applikasjonen virker. 85

86 Brukertesting ble gjennomført av UX i slutten av januar, og de brukte hi-fi skissene til å gjennomføre disse testene. De kontaktet tre mattelærere på ulike skoler i Oslo, og gikk gjennom en liste av spørsmål for å kartlegge deres lærerhverdag og læringsstil, se 4.8 Brukertester. Brukertestingen avdekket flere spørsmål som trengte avklaring med kunde. For at man skal kunne lage et ideelt produkt bør man finne løsninger på spørsmålene, implementere disse og deretter gjennomføre mer testing for å se om den nye løsningen fungerer. Det var planlagt at det skulle gjennomføres mer brukertesting, helst med applikasjonen som er utviklet i løpet av prosjektet istedenfor å bare teste mot skissene, men det ble ikke tid til dette for UX. 2.7 Brukerveiledning Dette kapittelet er en brukerveiledning for ematte. Den går gjennom hvordan en bruker, altså en mattelærer, kan benytte løsningen til å se, opprette og dele matteoppgaver og oppgavesett Oversikt over brukergrensesnittet Figur 60 - oversikt over brukergrensesnittet 86

87 2.7.2 Inn- og utlogging Figur 61 - login For å kunne benytte løsningen må man logge inn med brukeren man får fra Kommuneforlaget. Fyll inn brukernavn og passord og trykk logg inn. Figur 62 - hvordan logge ut For å logge ut igjen, trykk på infoboksen i hjørnet øverst til høyre, og trykk logg ut Sortere listen For å sortere listen med oppgaver og oppgavesett, trykk på knappen øverst til høyre over listen. Som standard er sorteringen satt til nyeste. Figur 63 - sorteringsmeny Her kan du velge om du vil sortere på de nyeste, eldste, eller mest populære oppgavene. Etter man trykker på et alternativ, vil listen sorteres etter valgt alternativ. 87

88 2.7.4 Filtrere listen Figur 64 - filtrering Du har mange ting du kan filtrere listen av oppgaver og oppgavesett på. Til venstre for lista ser du figuren over. Der kan du filtrere på Alle eller Mine, altså alle oppgaver og oppgavesett i løsningen, eller bare de du har laget selv. Under kan du trykke på oppgaver som bare vil vise oppgaver, oppgavesett som bare vil vise oppgavesett, og favoritter som bare vil vise favorittene dine. Hvis du velger flere filtre, for eksempel oppgaver og oppgavesett, vil både oppgaver og oppgavesett vises i listen. Figur 65 - utvidet filtrering 88

89 Hvis du trykker på Vis flere filtre, vil du få flere valg å filtrere på, som vi ser på figur 65. Her kan du filtrere på klassetrinn, vanskelighetsgrad, type oppgaver og emner Søk For å søke på oppgaver, kan du skrive inn søkeord i søkefeltet over listen med oppgaver og oppgavesett. Oppgaver med dette søkeordet i tittelen vil da vises i listen Lage oppgave For å lage en ny oppgave må du trykke på Ny... så Oppgave. Etter du har trykket ny oppgave, vil denne modalen dukke opp. Her fyller du inn tittelen på oppgaven, en oppgavebeskrivelse og eventuell fasit, hvis oppgaven bare er en tekstoppgave. Obligatoriske felter er markert med en stjerne, altså i dette tilfellet er tittel og beskrivelse obligatorisk. Som du kan se nesten nederst på modalen kan du også legge til deloppgaver. Hvis du trykker på Legg til deloppgave dukker det opp to felt: et til selve deloppgaven, og en til fasiten til deloppgaven. Hvis du angrer og vil fjerne deloppgaven, trykk på krysset til høyre. Hvis du vil legge til flere deloppgaver, trykk på Legg til deloppgave. Når du er fornøyd med oppgaven din, trykk neste. 89

90 Neste side i skjemaet er for å fylle ut klassetrinn, vanskelighetsgrad og type oppgave. Velg klassetrinnet oppgaven hovedsakelig gjelder for, og gi den en vanskelighetsgrad fra en til tre. Den kan bare ha ett klassetrinn og én vanskelighetsgrad. Neste du må velge er type oppgave. Velg en eller flere typer, og trykk neste. Den neste siden i skjemaet er å velge ett eller flere tema som oppgaven din inneholder. Velg den eller de du mener passer til oppgaven, og trykk neste. Her kan du fylle ut tilleggsinformasjon til oppgaven, men dette er ikke obligatorisk. Du kan velge å skrive tips til løsningen som elevene kan benytte, en lenke til eksterne ressurser som kan være til hjelp for elevene, en tilhørende beskrivelse til lenken, og nyttige verktøy som for eksempel kalkulator eller passer. Når du er fornøyd, trykk neste. 90

91 På skjemaets siste side får du en oversikt over hva du har fylt inn. Hvis det er noe du vil endre på, naviger deg tilbake i skjemaet ved å trykke Tilbake, eller hvis du er fornøyd, trykk Publiser i ematte. Oppgaven vil da publiseres og dukke opp under dine oppgaver Lage oppgavesett For å lage oppgavesett, trykk på Ny... så Oppgavesett. 91

92 Her må du fylle ut tittel, beskrivelse og klassetrinn for oppgavesettet. Du kan deretter velge å publisere et tomt oppgavesett, eller legge til oppgaver. For å finne oppgaver du vil legge til kan du filtrere, søke og sortere på samme måte som på hovedsiden. 92

93 For å se en forhåndsvisning av en oppgave, kan du holde musen over der det står Forhåndsvisning, og det vil dukke opp en forhåndsvisning av oppgaven. Velg oppgavene du ønsker å ha i ditt oppgavesett, og trykk Legg til valgte. Dine valgte oppgaver vil da vises øverst. Hvis du ønsker å fjerne oppgaver, kan du velge de og trykke Fjern valgte. Hvis du er fornøyd med oppgavesettet ditt, trykk neste. 93

94 Du vil da få en oversikt over oppgavesettet du har lagd. Nederst på denne oversikten kan du velge å gå tilbake om det er noe du vil endre, eller trykke Publiser i ematte for å publisere oppgavesettet Legge til oppgaver i oppgavesett Om du ønsker å legge til nye oppgaver i et oppgavesett du har laget, kan du enkelt gjøre dette fra hovedsiden. Det kan være oppgaver enten du eller andre har laget. For å gjøre dette kan du velge en eller flere oppgaver fra listen på hovedsiden, trykke på Legg til i også Oppgavesett. 94

95 Da vil du få opp en lik meny som for å opprette oppgavesett, men her kan du velge hvilket av dine oppgavesett du ønsker å legge oppgavene til, eller trykke på Nytt oppgavesett for å opprette et nytt et. På samme måte som med å opprette oppgavesett kan du herfra filtrere, søke og sortere på oppgaver for å legge til nye oppgaver fra dette skjemaet. 95

96 Trykk neste, og du vil se hvordan oppgavesettet ditt nå ser ut etter at du har lagt til de valgte oppgavene. Her kan du på samme måte som å opprette et oppgavesett velge å gå tilbake og endre, eller publisere Legge til oppgaver og oppgavesett som favoritt For å legge til oppgaver og oppgavesett som favoritt kan du gjøre en av to ting. Du kan enten trykke på bokmerket som er på oppgaven eller oppgavesettet, og den vil da bli markert mørkeblå. 96

97 Den andre måten er å velge en eller flere oppgaver eller oppgavesett fra hovedsiden, også trykke på Legg til i også Favoritter. Da vil du se at det du valgte blir satt som favoritt. 2.8 Egenevaluering I dette kapittelet går vi igjennom og evaluerer backend og frontend. Vi vil fortelle litt om løsninger vi tenker kunne blitt gjort annerledes, løsninger vi synes vi har løst på en god måte og hva som kunne blitt forbedret. Vi vil også få frem hva vi har lært i løpet av utviklingen av både backend og frontend Backend Backenden til applikasjonen er relativt enkel i og med at den aller meste logikken foregår i frontenden. Hovedsakelig mener vi at vi har utviklet en robust backend, men fremdeles kan man finne ting vi kanskje burde gjort annerledes Hva kunne vi gjort bedre? Når vi ser tilbake på ting vi kunne gjort bedre er det ting som ikke ble tenkt på fordi vi var uerfarne med systemutvikling. En ting er at klasser som burde hatt konstruktør mangler dette. 97

98 Et eksempel på dette kan vi se på figuren over. Kodesnutten kommer fra en enhetstest, der man instansierer en nytt objekt av type TaskEntity. TaskEntity mangler konstruktør, og dermed på vi bruke set-metodene i stedet for å ha med informasjonen som innparameter når man instansierer. En annen ting vi kanskje burde gjort annerledes, var å bruke Hibernate til å persistere favorittoppgaver og favorittoppgavesett ved hjelp av annotasjonene for mange-til-enrelasjoner slik som vi gjorde for eksempel med oppgaver og deloppgaver, som beskrevet under kapittel Hibernate. På figuren over ser vi hvordan FavouriteTaskEntity ikke annotasjonen, men bare beskriver hvordan tilsvarende tabell skal se ut i databasen. Dette har ingen praktisk betydning på persistering i databasen, men det skaper ikke et forhold mellom domenemodellene. Hadde vi utformet FavouriteTaskEntity og FavouriteTaskSetEntity slik vi gjorde i resten av applikasjonen, ville vi annotert på TaskEntity og UserEntity med annotasjon på Favourite-entitetene slik at hver instans av oppgave- og brukerklassene har en liste med favoritter Hva er vi fornøyd med? I det store bildet er vi veldig fornøyd med backenden, ettersom: den gjør det den skal og tjener frontenden på en god måte den har en god og tydelig struktur Hibernate er stort sett benyttet på en meget god måte restendepunktene er strukturert bra for eksempel /task/favourite/{taskid} blir brukt for flere operasjoner, både create og delete Hva har vi lært? Ettersom dette er første gang vi jobber med mange av teknologiene, har vi lært mye om hvordan rammeverk kan forenkle og effektivisere arbeidet med backend. Vi har lært hvordan benytte blant annet Spring og Hibernate i Java, og det å jobbe med en PostgreSQL 98

99 database. Dette er også første gang vi har hatt versjonskontroll på databasen vår, og første gang vi har benyttet en ekstern SSO-protokoll. For å oppsummere har vi lært å bruke mange nye teknologier og rammeverk i backend, og verdien av det å bruke disse Frontend Alt i alt er vi veldig fornøyd med vår frontend. I ettertid er det en del pirk som vi ser kunne og kanskje burde blitt gjort annerledes hvis vi skulle laget alt på nytt igjen, men dette er en del av læringsprosessen Hva kunne vi gjort bedre? Mer generiske komponenter: o Etterhvert utover i utviklingen så vi at vi lagde komponenter som ble svært like, som egentlig kunne blitt laget som en enkelt komponent, evt. med et valg om hva komponenten skal gjøre og inneholder. Et eksempel på dette er oppgavetype, tema-checkboxes og filtreringsknappene, da disse nesten er helt like. Da vi oppdaget dette var vi såpass langt ute i utviklingen, slik at det ville få store konsekvenser å endre på det, og det fungerte slik det allerede var. Derfor valgte vi å ikke bruke tid på dette. Kunne brukt samme reducere på forskjellige state variabler i store: o Vi mistenker at vi har skrevet unødvendig mye lik kode i reducerene. Vi tror det er mulig å bruke samme reducer, og binde disse til forskjellige variabler i rootreduceren. Dette er noe vi egentlig ikke er helt sikre på, men vi mistenker dette siden vi så det ble mye lik kode, noe som ofte indikerer at noe kunne ha blitt gjort bedre. Mer generisk CSS: o Ingen av oss i gruppen hadde lagd løsninger på denne størrelsen tidligere, og derfor ble CSS en mer rotete enn den burde ha blitt. Vi synes det ble skrevet for mye CSS, det vil si at flere klasser kunne blitt brukt og lage modifier til disse klassene i stedet for å lage helt nye. Generisk navngivning: o Etter hvert som løsningen ble veldig stor, merket vi at navngivningen vår vanskeliggjorde det å navigere i løsningen. Det vi tenker er at den kunne vært mer generisk, altså ikke navn etter hva komponenten inneholder, men hva komponenten gjør. Filtreringsfunksjonaliteten: o Vi er ikke helt fornøyd med filtreringsfunksjonaliteten, da denne er noe rotete, og gjøres to ganger, en i Home containeren og en i TaskSetForm containeren. Denne ser vi at burde blitt laget kun en gang, men det ble heller aldri prioritert. 99

100 Hva er vi fornøyd med? Høy kompleksitet o Løsningen ble etter hvert veldig stor og kompleks, men vi føler vi klarte å mestre dette svært godt, selv om det var noe kode som ble skrevet flere ganger. Arkitektur o Arkitekturen, med tanke på actions, containers, komponenter og reducers er vi svært fornøyd med. Vi synes dette fungerer veldig bra og gjør koden strukturert, vedlikeholdbar og leselig. Få containers, mange komponenter o Dette gjør at det blir enklere med gjenbruk av visuelle komponenter, og å holde styr på hvor funksjonaliteten skjer Hva har vi lært? Mye som vil endres underveis o Siden vi tok i bruk teknologier vi ikke hadde brukt før, er det mye som vi ser burde blitt gjort annerledes underveis, men det betyr også at vi lærer kontinuerlig når vi utvikler. Den første løsningen er ikke alltid den beste o Vi opplevde mange ganger at vi kom på en bra løsning på et problem, men denne ble endret opptil flere ganger, siden vi kom på en bedre løsning. Tidlig uvitenhet forplanter seg o Hvis vi har gått for en dårlig løsning tidlig i utviklingen så er det veldig lett å gjenbruke denne løsningen andre steder i applikasjonen, da vil den forplante seg veldig og når man har innsett at det var en dårlig løsning, vil det kanskje være veldig mye arbeid å gjøre det om igjen Oppsummering Backenden er strukturert på en veldig god måte som gjør den oversiktlig og enkel å ha med å gjøre for videre utvikling, men som nevnt ovenfor kunne noen småting vært gjort litt annerledes. Frontenden er stor og kompleks ettersom den gjør veldig mye, og vi føler vi har håndtert størrelsen og kompleksiteten bra ved hjelp av god og oversiktlig arkitektur. Spesielt i frontenden ser vi i ettertid ting som burde blitt gjort annerledes. Dette er noe vi anser som naturlig ettersom den er veldig stor og kompleks, og uten erfaring med React/Redux fra før av, ble det gjort en del ting i begynnelsen som vi senere ser at burde vært endret, som vi ikke fikk tid til å endre innenfor prosjektets tidsramme. Stort sett mener vi at vi har utviklet en god løsning for Kommuneforlaget med noe småpirk her og der. Det har vært veldig mange nye teknologier for samtlige gruppemedlemmer å sette seg inn i, og vi føler at vi har håndtert den utfordringen bra, og utviklet grunnlaget for noe som kan utvikles videre til å bli en mye brukt og komplett løsning. 100

101 3. Prosessrapport 3.1 Innledning Denne rapporten har som hensikt å ta for seg gruppens utviklingsprosess gjennom prosjektet. Rapporten vil ta for seg alle de ulike aspektene av prosjektet fra inngangen til prosjektet, planlegging, valg av verktøy, utviklingen av produktet og en evaluering av prosessen til slutt. 3.2 Inngangen til prosjektet Valg av oppdragsgiver Høsten 2017 startet arbeidet vårt med å finne en oppdragsgiver i forbindelse med bachelorprosjektet vårt i Anvendt Datateknologi. Vi var ganske usikre på hvor vi skulle starte i arbeidet med å finne en oppdragsgiver og følte at vi begynte å få noe dårlig tid når vi satt i midten av oktober uten et klart bachelorprosjekt. Det var derimot dette som gjorde at vi kom i kontakt med den oppdragsgiveren vi har i dag. Samtlige gruppemedlemmer ble kontaktet av Netcompany via LinkedIn for en prat om mulig jobb høsten 2018, men det endte heller med at vi ble tilbudt å gjennomføre vårt bachelorprosjekt hos dem. De kunne vise til god erfaring med studentprosjekter fra tidligere år, samt flere spennende prosjekter hos mange store aktører, blant annet Oslo Kommune, Norgesgruppen, Møller Bil og mange fler. Vi bestemte oss ganske fort at dette var en svært god mulighet for oss til å skrive en god oppgave, og få en fot innenfor konsulentbransjen Første møtet med teamet Netcompany ønsket å gi oss en best mulig start i forbindelse med vårt prosjekt og innledning til konsulentyrket. Allerede i midten av desember var vi på velkomstmøte på hovedkontoret. Her fikk vi hilse på samtlige personer som skulle være på vårt team i forbindelse med prosjektet. På dette tidspunktet var det ikke avklart hvilket prosjekt vi skulle jobbe med. Dette grunnet i at prosjektet de først hadde planlagt som vårt ikke ble noe av og at det dermed måtte bli funnet et nytt prosjekt på kort tid. Dette skulle derimot bli klart innen prosjektoppstart i januar Code of Conduct Som nyansatt i Netcompany er man pålagt å gjennomføre et kurs ved navn Code of Conduct. Dette kurset er en introduksjon til konsulent- og ansattrollen i Netcompany. Her gjennomgås sentrale ting ved det å jobbe i Netcompany og en introduksjon til partnerne og 101

102 managerne. Det ble også gjennomgått hvordan fakturering av timer hos kunden fungerer, men akkurat det var ikke vi med på da vi ikke var blitt ansatt, men det var nyttig for oss å delta på dette kurset for å få en innføring i konsulentyrket Kunden og prosjektet Ved oppstart i januar var prosjektet klart. Netcompany hadde inngått en avtale med Kommuneforlaget om å utvikle en applikasjon ved navn ematte. Dette kan leses mer om under Bakgrunn for prosjektet. 3.3 Planlegging av prosjektet Scrum Netcompany hadde et ønske om at vi skulle ta i bruk Scrum. Denne prosjektmetodikken er et av de mest benyttede for smidig utvikling og brukes hovedsakelig til å utvikle programvarebaserte systemer. Vi hadde kjennskap til Scrum fra tidligere og vi følte det ville være nødvendig å følge en smidig metode da dette prosjektets omfang er mye større enn det samtlige i gruppen har vært borti tidligere. Ved hjelp av Scrum var det mulig for oss å dele opp oppgavene som skulle gjøres, hvilken prioritet de ulike oppgavene skulle ha og hvor lang tid Sprinter Det ble delt opp i 5 sprinter, se 1.4 Milepæler, der sprintene var tiltenkt å gjennomføres på et tidsrom mellom 2 og 4 uker. Prosjektet hadde en svært detaljert product backlog så det var viktig for oss å bli enige med kunden om hva som skulle prioriteres først. Dette ble gjort første møte med kunden for sprint 1, og under hver sprint review for hver påfølgende sprint Estimering For å estimere sprintene benyttet vi en tilpasset versjon av planning poker. Vår versjon av planning poker gikk ut på å estimere vanskelighetsgraden til oppgavene vi har tatt for oss i sprinten, og deretter estimere hvor lang tid hver oppgave vil ta å ferdigstille. Det gikk ut på at vi hadde en kortstokk med kort fra 1 til 13, og tok for oss hver oppgave og deretter viste hverandre hvilket tall vi hadde valgt for å representere hvor kompleks, vanskelig og tidkrevende oppgaven var. Personen med høyest tall på kortet og personen med lavest tall på kortet diskuterte deretter om hvorfor de mener oppgaven fortjener det valgte tallet. Vi kommer deretter til enighet om hvilket tall vi velger. Hvert tall i kortstokken representerer et tall i et utdrag fra Fibonacci-rekken, i vårt tilfelle og videre fram til 987, og det tallet i rekken som tallet representerte ble oppgavens mengde med story points 22, som beskriver hvor kompleks en oppgave er. Etter dette ble hver oppgave delt opp i mindre deloppgaver, og så estimerte vi disse i antall timer Daglige standups En del av scrum-metodikken, er å utføre daglige standups. Dette var noe vi alltid gjennomførte, sammen med både prosjektleder og UX-ressurs. På disse standupene gikk vi 22 Story points poeng som gis til en story avhengig av hvor kompleks den er 102

103 igjennom hva vi har jobbet på siden sist standup, hva som var planen fremover og hvilke hinder vi eventuelt så for oss. Dette gjorde at noen slapp å sitte og lure på hva man skulle gjøre, og eventuelt gjøre noe som krasjer med noen andres arbeid. Det ble også avklart UX spørsmål på disse standupene. Vi hadde standupen kl 10 på dagen, slik at alle fikk tid til å sette seg inn i det man jobbet med, og komme opp med eventuelle hinder man så for seg. Vi brukte sjelden mer enn 10 minutter og vi sto alltid oppreist. Hvis vi hadde mer komplekse spørsmål, booket vi heller et møte og satt oss ned og fikk en avklaring på utfordringen Design På teamet vårt hadde vi tre personer som jobbet med design og UX. De gikk i gang med å lage lo-fi skisser på papir ved prosjektets start og gjorde dette klart til første møte med kunden. Skissene ble presentert for kunden som ga sine meninger og det ble gjennomført et internt møte med teamet om mulige forbedringer. Dette ga oss utviklere mulighet til å delta på designprosessen og påvirke designet. 103

104 Lo-fi prototyp Figur 66 - vise oversikt over oppgaver og oppgavesett 104

105 Figur 67 - vise oppgave 105

106 Figur 68 - redigere opppgave 106

107 Figur 69 - vise et oppgavesett 107

108 Figur 70 - redigere oppgavesett Hi-fi prototyp Etter diskusjon om skissene, begynte UX arbeidet med hi-fi prototypen 23. Den er laget i InVision og du kan finne skissene her: 23 Hi-fi prototype digitalisert prototype med funksjoner 108

109 3.4 Teknologivalg Ved valg av teknologier var det ønskelig å kunne levere et robust og moderne produkt som kan skaleres sammen med kundens egne ønsker. Det ble valgt teknologi som Netcompany har god kompetanse og erfaring med fra tidligere, noe som vil gi størst muligheter for et vellykket prosjekt Database PostgreSQL - Relasjonsdatabase, Open Source og mye brukt. Flyway/Liquibase - Versjonskontroll for databasen Backend Spring Boot - Modulbasert rammeverk for oppsett og bygging av applikasjoner i Java miljø Frontend React - JavaScript-rammeverk for oppbygging av brukergrensesnitt. Utbredt, velprøvd og har godt rykte i bransjen og i Netcompany. Redux - Bibliotek for vedlikehold av tilstander. Ofte brukt med React. NodeJS - Rammeverk for lettvekts server-applikasjoner. Meget skalerbart og har utmerket ytelse. 3.5 Verktøy Utviklingsverktøy IntelliJ IDEA IntelliJ 24 er en IDE 25 utviklet av JetBrains og var et kjent utviklingsverktøy for oss fra tidligere. På bakgrunn av at Netcompany har mye erfaring med verktøyet, med tilgang til profesjonelle lisenser for produktet, samt at alle i gruppen hadde god erfaring med verktøyet fra tidligere ble dette valgt som IDE for prosjektet Git og Gitlab Git 26 er et versjonskontrollsystem som brukes i utvikling av programvare. Ved hjelp av Git kan vi dele prosjektet vårt opp i branches 27 som inneholder ulike versjoner av produktet. Ved utvikling av ny funksjonalitet blir dette lagt i en egen branch og blir merget 28 inn i hovedversjonen av produktet så fort det er blir testet og kvalitetssikret. 24 Jetbrains, udatert 25 IDE Integrated Development Environment 26 Git, udatert 27 Branch et nivå som inneholder en versjon av et program 28 Merge sammensetting av ulike versjoner av et program 109

110 Gitlab 29 er programvare for å håndtere git repositories 30. Det ble foretrukket av teknisk bistand å ta i bruk Gitlab ved oppsett av repository til prosjektet Postman Postman 31 ble brukt til å teste WEB API-et i backend. Ved hjelp av dette kunne vi kalle på de ulike restendepunktene i backend og lese ut hvilken verdi som ble returnert Chrome DevTools For å enkelt kunne gjøre endringer i CSS, se oppbyggingen av HTML-elementer og foreta debug av JavaScript-koden tok vi i bruk Chrome DevTools. Dette er et svært behjelpelig verktøy som effektiviserer utviklingen Redux DevTools Redux DevTools 32 gjør det mulig å se endringer i state i det øyeblikket det skjer, og holde styr på hvilke og hvor data endres i store. Redux DevTools ligger som et open-source prosjekt på github men er blitt gjort tilgjengelig gjennom en Chrome-utvidelse som ble brukt gjennom prosjektet JIRA For å holde styr på product backlogen er denne blitt lagt inn i JIRA for at alle skal kunne ha tilgang. Oppgavene deles opp i sprinter, og ved hjelp av et Kanban board 33 er det enkelt å holde styr på hva som skal gjøres av hvem i hver sprint. Oppgavene legges først i kategorien To do, hvor hver av utviklerne selv har ansvar for å delegere oppgaver til seg selv og deretter gjennomføre dem. Når en oppgave er under arbeid legges den i kategorien In progress og blir tildelt en utvikler. Når en oppgave er ferdig gjennomført vil den bli lagt i kategorien QA 34. Dersom oppgaven inneholder visuelle elementer som må vurderes blir den lagt videre i QA UX 35. Dersom en oppgave ikke består QA vil den bli lagt tilbake i In progress. Når en oppgave er ferdig og blitt godkjent i QA settes oppgaven til Done. Når alle oppgavene har nådd kategorien Done er man ferdig med sprinten, og dette skal skje innen fastsatt deadline for sprinten. Dersom man er tidlig ute med å være ferdig med sprinten kan man hente inn flere oppgaver fra product backlogen. Dette bør dog skje i samhandling med kunde slik at man prioriterer etter kundens ønske. 29 Gitlab, udatert 30 Repository område prosjektet ligger på i git 31 Postman, udatert 32 Redux DevTools, Kanban board arbeidsbrett for fordeling av oppgaver 34 Quality Assurance sikring av kodekvalitet 35 Quality Assurance av UX sikring av visuell kvalitet 110

111 3.5.2 Dokumentasjonsverktøy Confluence Confluence er et verktøy fra Atlassian som brukes til å dokumentere og dele viktig informasjon om et prosjekt. Man kan lage egne områder for team og deretter dele dem inn i mindre områder ved behov. For å dokumentere alt arbeidet vi har gjort med produktet har dette blitt tatt i bruk, noe som Netcompany sterkt anbefalte oss å gjøre for å blant annet forenkle arbeidet med denne rapporten. For at kunden skal ha mest mulig innsyn i vårt arbeid fikk vi tilgang til deres Confluence og la alt av dokumentasjon hos dem. Dette bidrar til at kunden aldri trenger å lure på hvordan arbeidet ligger an, siden progresjonen ligger dokumentert i Confluence Google Docs For å samarbeide om rapportskriving har vi tatt i bruk Google Docs. Gruppen har brukt dette gjennom hele studiet og er godt kjent med verktøyet. Dette tillater oss å skrive dokumenter sammen, på samme tidspunkt, og synliggjør alles deltakelse i arbeidet Google Sheets For å dokumentere arbeidsmengden førte vi timelister på Google Sheets. Dette ble foretrukket framfor at en på gruppa førte timer i Excel, fordi det ikke er sikkert alle er på jobb til samme tidspunkt hver dag Google Slides For prosjektets presentasjon ble Google Slides tatt i bruk. På samme måte som Google Docs kan alle i gruppa jobbe sammen med presentasjonen, på samme tidspunkt Kommunikasjonsverktøy Microsoft Outlook E-post For kommunikasjon med kunden ble det sendt e-poster gjennom Microsoft Outlook. Interne møteinnkallelser i teamet ble også sendt på e-post Kalender For booking av grupperom på HQ ble kalendersystemet til Microsoft Outlook benyttet. Dette verktøyet gjorde det også mulig for oss å holde styr på møter, både internt, men også med kunden. 111

112 HipChat HipChat er en chatteapplikasjon, og ble brukt til å holde kontakten innad i teamet når ikke alle var tilstede. Dette var veldig nyttig for oss ettersom teknisk bistand ikke alltid sitter på HQ, men er ute på prosjekt hos andre kunder. HipChat ble også benyttet til å få teknisk bistand fra andre enn teamet. Ved å spørre i de ulike chattene på HipChat vil man kunne få hjelp fra samtlige i Netcompany som har relevant kunnskap om det temaet man trenger hjelp med Testverktøy Selenium IDE for Mozilla Firefox For å systemteste applikasjonen benyttet vi oss av Selenium. Dette er en utvidelse til nettleseren Mozilla Firefox, som gjør det mulig å ta opptak av funksjonalitet i applikasjonen og la nettleseren gjennomføre det i ettertid. 3.6 Utviklingsprosessen I dette kapittelet vil vi forklare hva som skjedde underveis i utviklingsprosessen. Vi hadde totalt 5 sprinter, flere kundemøter hvor avklaringer ble avklart og ukentlige statusmøter hos kunden, hvor en statusrapport ble lagd for hver uke. Statusrapporten inneholder en oppdatert risikoanalyse og hva som har blitt gjennomført siden sist, i tillegg til diverse avklaringer som dukket opp underveis Første møte med kunden Den 9. januar ble det innkalt til første møte med kunden. Her ble bakgrunnen for ematte gjennomgått og tanken om læringsutbytte og effektivitet for elever og lærere. Dette kan leses mer om i Presentasjon av ematte. UX presenterte skissene som var blitt laget i forkant av møtet. Kundens syn på skissene virket svært positivt, og det var kun noen endringer innen fargevalg og forflytting av logoer som var nødvendig. Det ble avtalt med kunden at sentrale funksjoner skulle komme på plass. Dermed ble det bestemt at sprint 1 skulle prioritere: Login-integrasjon (CAS) Oppsett av det visuelle for login- og landingpage Visning av oppgaveliste Netcompany sitt bidrag Netcompany ønsket å bidra til å gjøre vår hverdag enklest mulig. Da vi fortalte om mangelen på grupperom på høgskolen var de klare på at vi mer enn gjerne fikk sitte på deres kontorer og utvikle produktet vårt. Det gjorde at vi alltid hadde et sted vi kunne gå til, men også ha en nærhet til teamet vårt som gjorde at en hjelpende hånd aldri var langt unna. 112

113 I tillegg fikk vi en Lenovo Thinkpad hver, og på plassene våre på kontoret hadde vi også hver vår pc-skjerm. Dette bidro til at alt av programvare var installert på forhånd og det var bare å starte utvikling så fort det lot seg gjøre. Med en ekstra pc-skjerm har man også en større arbeidsplass som gjør det mer praktisk å utvikle Forsinket start Det var på forhånd bestemt at vi skulle ta i bruk kundens Confluence framfor Netcompany sin da dette bidrar til et mer transparent prosjekt. Confluence er koblet opp mot utviklingsverktøyet JIRA, som vi trenger tilgang til for å kunne begynne arbeidet med sprinten. I forbindelse med at kunden skulle skaffe teamet vårt brukere oppsto det noe som gjorde at opprettelsen av disse ble forsinket og vi fikk dermed ikke offisielt gått i gang med sprint 1 før den 24. januar. For oss var det fint å få litt ekstra tid på å sette oss inn i teknologien vi skulle bruke på prosjektet, og vi hadde også en forprosjektrapport som måtte bli skrevet og levert innen 19. januar. Men etter at rapporten var ferdigstilt og vi følte oss ganske gode på de nye teknologiene ble vi enig internt i teamet at vi skulle gå i gang med å lage login-siden før sprinten var i gang Sprint 1 Den 24. januar var Confluence-brukerne klare og vi kunne begynne med sprint 1. Sprinten skulle vare frem til 7. februar, som tilsvarer litt over 2 arbeidsuker Utvikling I denne sprinten skulle vi utvikle følgende: Nøkkel Oppgave Type Prioritet Story points HOVPRO-58 Login - autentisere bruker Story Normal 34 HOVPRO-21 Vise oppgaveliste Story Normal 21 HOVPRO-31 Vise oppgavesettliste Story Normal 21 HOVPRO-60 Logout - autentisere bruker Story Normal 5 Hvert av disse punktene kalles for stories 36 og har underliggende oppgaver som skal gjøres innenfor hver story. Hver story estimeres ved hjelp av planning poker og gis et story point basert på Fibonacci-rekken. Tallet vil være høyere basert på hvor vanskelig og tidkrevende oppgaven er å gjennomføre. 36 Story brukerhistorie med tilhørende funksjonalitet 113

114 Figur 71 - burndown sprint 1 Figur 71 viser et sprint burndown chart 37 for sprint 1. På venstre side ser vi den totale mengden story points i sprinten. Den sorte streken indikerer optimal fremdrift for sprinten, mens den røde streken viser reell fremdrift. For at den røde streken skal krabbe nedover må stories settes til done på JIRA-boardet. Vi kan se at den røde og sorte linjen er langt ifra hverandre. Disse strekene baseres utelukkende på forventet fremdrift basert på estimater satt av teamet. For at dette skal treffe så godt som mulig må teamet estimere godt, noe vi ikke hadde noe erfaring med før denne sprinten. Dermed var det ganske forventet at vi ikke kom til å matche denne grafen. Av grafen kan vi også se at den røde linjen ikke nådde bunnen før 21. februar, 2 uker etter planlagt avslutning Sprint rapport Nedenfor kan vi se en rapport over sprinten. Her kan man se storiene, samt alle tasks 38. Vi kan også se at tasks ikke blir estimert med story points, men disse estimeres i timer. Dermed kan man logge antall timer man har brukt på hver task og på slutten av hver sprint vurdere estimatet man har satt. Se 4.7 Time-tracking-report for JIRA for tidsestimater på alle taskene i løpet av prosjektet. Figur 72 - ferdige "tasks" 37 Graf som viser fremdriften til en sprint 38 Oppgaver underliggende stories 114

115 Figur 73 - fjernet "tasks" Som vi kan se av figur 73 er to av storiene ikke fullført innen avslutning av sprinten. Grunnen var at vi fikk problemer med å implementere login-funksjonalitet i løsningen, som skulle implementeres med CAS CAS For inn- og utlogging av egne systemer bruker kunden CAS, Central Authentication Service, og av praktiske grunner var det ønskelig at dette også skulle bli benyttet for ematte. CAS er en SSO-protokoll for webapplikasjoner. Ved hjelp av CAS kan brukeren logge seg inn et sted, med et sett brukernavn og passord, og trenger dermed ikke skrive inn dette igjen dersom brukeren besøker et nettsted tilknyttet kundens systemer. Dette er noe av det samme som FEIDE 39, som gjør at studenter og elever er både innlogget fronter, canvas, studentweb og lignende etter kun en innlogging. CAS skulle derimot være vår første store utfordring. Ingen på gruppa har tidligere implementert CAS eller noen annen SSO-protokoll i et produkt, og det hadde heller ingen andre på teamet vårt erfaring med. Dette ble derfor en noe vanskelig oppgave som tok mye lenger tid enn vi estimerte. Dette gjorde at sprinten ble forsinket og utvidet Sprint review Sett fra et utviklingsteam med mye erfaring kan man si at denne sprinten ikke var godt gjennomført. Sprinten varte lenger enn forventet, og det var også to av storiene som ikke ble ferdigstilt. For oss var det på estimerings tidspunkt vanskelig å fastsette hvor stor jobb det var å implementere CAS i applikasjonen, og vi la mye innsats i å få det til før vi valgte å informere kunden om det. Omtrent halvveis valgte vi å ta opp problemene med kunde, og vi var klare på at vi hadde lite kunnskap om hvor mye mer tidsbruk det ville kreve. På grunn av god kommunikasjon og et transparent prosjekt hvor kunden har innsyn i alt som skjer ble dette et problem som ble løst ved å videreføre storiene til neste sprint. Problemer kan oppstå når som helst i løpet av et prosjekt. Denne sprinten lærte oss viktigheten av å holde kunden informert og løse det sammen med kunden. Det ble bestemt at opprettelse av oppgaver og forhåndsvisning av disse skulle prioriteres i neste sprint Statusmøter Under denne sprinten ble det gjennomført ett statusmøte hos kunden. Her avklarte vi datoer for fremtidige statusmøter og rapporterte til kunde at vi hadde problemer med CAS innlogging. Risikoanalyse var enda ikke etablert, så dette kommer ikke før neste sprint. På møte ble vi også enige om å utsette sprinten på grunn av problemene som oppsto med CAS. 39 SSO-protokoll brukt av OsloMet for innlogging i systemer 115

116 3.6.5 Sprint 2 Den 21. februar avsluttet vi sprint 1 og startet opp arbeidet med sprint 2. Nye estimeringer ble gjort og denne gangen tok vi med oss erfaringer fra forrige estimering. Sprintens varighet ble satt til 3 arbeidsuker og skulle vare frem til 14. mars Utvikling Nøkkel Oppgave Type Prioritet Story points HOVPRO-25 Opprette ny oppgave Story Normal 89 HOVPRO-2 Vise en oppgave Story Normal 55 HOVPRO-58 Login - autentisere bruker Story Normal 34 HOVPRO-41 Vise oppgavesett Story Normal 21 HOVPRO-60 Logout - autentisere bruker Story Normal 5 HOVPRO-7 Registrere tittel Story Normal - HOVPRO-8 Registrere fagemne Story Normal - HOVPRO-10 Registrere oppgavetype Story Normal - HOVPRO-12 Registrere oppgavetekst Story Normal - Ved å sammenligne sprint 1 og 2 kan vi se at den vanskeligste storien nå har fått et mye høyere story point enn den storien som ble estimert som den mest tidkrevende i forrige sprint. Disse er basert på fibonacci-rekken, men vi syntes det ble lite praktisk at en så vanskelig oppgave som CAS skulle ha 34 i vanskelighet, mens to stories som var langt lettere lå på nivået under, som er 21. Dermed valgte vi å estimere med høyere tall i fibonaccirekken for å få en mer detaljert vanskelighetsgrad. Figur 74 - burndown chart sprint 2 116

117 Figur 74 viser at reell fremdrift er langt unna den optimale fremdriften. Av grafen kan det se ut som det har blitt gjort et ordentlig skippertak rett før avslutning av sprinten for å bli ferdig med alt. Denne sprinten inneholdt flere stories som tok for seg sentrale, visuelle elementer, og det var nødvendig å få gjennomført UX QA før vi kunne ferdigstille storiene. Dermed ble det til at disse ikke ble satt til done før sprinten ble avsluttet. Denne måten å gjennomføre QA på er dog ikke anbefalt. Dersom det skulle oppstå feil eller mangler er det viktig å ha satt av en forsvarlig mengde tid så man ikke må utvide sprinten. Dersom det hadde oppstått i dette tilfellet ville vi ha fått problemer med å gjennomføre til planlagt tid. Heldigvis ble det ikke avdekket annet en småfeil og det var derfor ikke noe problem å fikse dette helt til slutt Sprint rapport Figur 75 - ferdige "tasks" Figur 76 - uferdige "tasks" Denne sprinten bestemte vi oss for å detaljere oppgavene ytterligere. Dermed ble det laget mange små oppgaver istedenfor få store oppgaver. Dette gjorde vi for å holde bedre oversikt over hva hver enkelt skulle gjøre på hver task. Vår tekniske arkitekt brukte mye tid på å lese dokumentasjonen til CAS enda nøyere enn det som hadde blitt gjort tidligere, og fant etterhvert ut hvordan problemene skulle løses. Sprint-rapporten viser at HOVPRO-58 ble som planlagt ferdigstilt, men HOVPRO-60 og noen andre tasks ble ikke det 117

118 Som nevnt bestemte vi oss for å lage små detaljerte oppgaver denne sprinten, og alle de uferdige oppgavene er laget basert på hvilke forventninger vi hadde til hvordan CAS virker. Fra tidligere har vi operert med session-variabler 40 som settes ved login og som enten timer ut eller slettes ved utlogging. Dette er derimot ikke slik CAS virker, se CAS. Teknisk arkitekt hadde begrenset med tid og fikk derfor ikke sett så mye på HOVPRO-60, men i samsvar med kunde ble det bestemt at behovet for utlogging er mindre viktig enn annen funksjonalitet per nå. Dermed ble det bestemt at HOVPRO-60 videreføres til neste sprint Sprint review I motsetning til sprint 1 ble denne sprinten avsluttet til planlagt tid, men ikke alle oppgavene ble gjennomført. Nok en gang ble dette løst gjennom jevnlig kommunikasjon med kunde og videreføring av stories til neste sprint. Det er nå mulig å opprette oppgaver, se disse i oppgavelista og åpne en forhåndsvisning av disse. Sprinten ble gjennomført på en tilfredsstillende måte der mye funksjonalitet ble utviklet. Sammen med kunden ble det bestemt at neste sprint skulle opprettelse av oppgavesett prioriteres, og muligheten for å legge til oppgaver i disse Statusmøter Under denne sprinten ble det gjennomført tre statusmøter Det ble bedt om en avklaring omkring usikkerhet om vanskelighetsgrad. Kunden var usikker på om det var ønsket 3 eller 10 vanskelighetsgrader og det er ønsket en avklaring om dette innen kort tid. Ble enige om fokus for sprint Avklaringen fra forrige møte om vanskelighetsgrad er nå kommet til enighet. Vi avtaler med kunde at vanskelighetsgrad skal være fra 1-3 der 1 er enklest Produktdemo Fokus for sprint 3 Risikoanalyse: 40 Global variabel som slettes etter en viss tid 118

119 For å se hva risiko-kodene betyr, se 4.5 Risikokoder og faktorer Sprint 3 Etter avslutning av sprint 2 startet sprint 3 den 14. mars. Sprintens varighet var 4 arbeidsuker og skulle avsluttes den 11. april Utvikling Nøkkel Oppgave Type Prioritet Story points HOVPRO-35 Opprette nytt oppgavesett Story Normal 89 HOVPRO-53 Legge til oppgave Story Normal 55 HOVPRO-56 Publisere oppgavesett Story Normal 34 HOVPRO-60 Logout - autentisere bruker Story Normal 13 HOVPRO-34 Vise publisert oppgavesett Story Normal 5 HOVPRO-46 Vise oppgavesett Story Normal - HOVPRO-47 Registrere tittel Story Normal - Figur 77 - burndown chart sprint 3 I figur 77 ser vi at den reelle fremdriften som fra tidligere sprinter ikke følger det som er forventet ut fra grafen. Som i sprint 2 var det også behov fra UX QA, hvilket var noe vanskelig å gjennomføre ettersom UX har en tettpakket timeplan. Som nevnt i Utvikling er det viktig å ha tid til å fikse feil fra QA. Dermed forsøkte vi å få UX til å gjennomføre QA så ofte som mulig. Likevel kan vi se at ble vanskelig å ferdigstille mesteparten av storiene før nærmere slutten av sprinten likevel. Det ble ikke avdekket store feil eller mangler denne gangen heller, noe som gjorde at sprinten ble avsluttet til rett tid. 119

120 Sprint rapport Figur 78 - ferdige "tasks" Figur 79 - ikke ferdige og fjernede "tasks" Vi tok lærdom av forrige sprint og videreførte små detaljerte oppgaver, men denne gangen ble det også laget oppgaver merket bug dersom det var feil som måtte fikses, eller improvement dersom ting kunne bli gjort annerledes eller forbedres. 120

121 Av figur 79 kan vi se at noen oppgaver ikke ble ferdigstilt, og noen ble fjernet fra sprinten. Her ligger det oppgaver om å lage tester, samt en liten bug tilknyttet CAS. HOVPRO-154 skulle vært markert med improvement, men den skulle også vært satt til done før sprinten ble avsluttet da det ble gjennomført og ferdigstilt. Oppgavene som ble fjernet var basert på en feil fra skissene, der oppgavesettmodalen inneholdt fire sider, mens den egentlig kun skal ha to sider. Denne endringen ble gjort i samsvar med kunde på et statusmøte helt i starten av prosjektet Sprint review Sprinten ble gjennomført innen avtalt tid, men ikke alle oppgavene ble ferdigstilt innen tiden. Som tidligere i prosjektet ble dette avklart med kunde og videreført til neste sprint. Det ble avgjort sammen med kunde at neste sprint skulle være den siste, til tross for at milepælsplanen, se 1.4 Milepæler, har enda en sprint planlagt. Sprint 1 varte lenger enn først planlagt, og ble også noe forsinket før vi fikk startet. På bakgrunn av dette var det viktig at siste sprinten tok for seg sentral funksjonalitet som er viktig for at produktet skal virke så fullstendig som mulig ved overlevering. Sammen med kunde ble det bestemt at filtrering, sortering og favorisering av oppgaver skulle være fokuset for neste sprint. Dette er funksjonalitet som er svært sentral for vår applikasjon da det vil være vanskelig å lete gjennom en stor oppgavedatabase uten å ha mulighet til å filtrere og sortere. I tillegg vil det være lurt å kunne søke etter oppgaver, men det ble bestemt at vi ikke skulle prioritere dette neste sprint fordi det var usikkert hvor lang tid det ville ta å utvikle filtrering, sortering og favorisering Statusmøter Det ble avholdt tre statusmøter i løpet av denne sprinten Fokus for sprint 3 Avklaring rundt ønske av bildefunksjon Hva skal gjøres med brukertesting? (møtet ble avlyst) Ber om avklaring rundt fokus for sprint 4 Endring i risikoanalyse Mer om fokus for sprint 4 Kunde gis beskjed om at ikke alle ønskede brukerhistorier fra backlogen vil være mulig å prioritere på grunn av kort gjenstående tid Avslutningsaktivitet? 121

122 Se 4.5 Risikokoder og faktorer Sprint 4 Etter avslutning av sprint 3 den 11. april startet sprint 4. Sprintens varighet var litt over 3 arbeidsuker og skulle være ferdig den 4 mai Utvikling Nøkkel Oppgave Type Prioritet Story points HOVPRO-23 Sortere oppgavelisten Story Normal 89 HOVPRO-30 Flagge oppgave som favoritt Story Normal 89 HOVPRO-33 Sortere oppgavesettliste Story Normal 89 HOVPRO-44 Flagge oppgavesett som favoritt Story Normal 89 HOVPRO-22 Filtrere oppgaveliste Story Normal 55 HOVPRO-32 Filtrere oppgavesettliste Story Normal 55 HOVPRO- 174 Legg til eksisterende oppgave i et av mine oppgavesett Story Normal 13 HOVPRO-40 Flagge oppgavesett som favoritt Story Normal 8 122

123 Figur 80 - burndown chart sprint 4 Figur 80 viser at fremdrift er fortsatt et godt stykke unna den optimale fremdriften. Som tidligere har det vært mye å gjøre for UX som gjør at det ikke alltid er så lett for dem å gjennomføre QA. Vi ser også at den røde linjen strekker seg forbi avslutningsdatoen 4. mai, og stopper ikke før 12. mai. Sprinten ble fullført på tiden, men sprinten ble ikke avsluttet inne på JIRA før etter at prosjektet ble overlevert til kunden den 11. mai, en liten glipp fra vår side Sprint rapport 123

124 Figur 81 - ferdige "tasks" Av rapporten kan vi se at alle oppgavene ble fullført og ingen oppgaver ble utsatt. Det var det heller ikke rom for denne gangen ettersom dette var siste sprint. Vi fikk gjennomført alt som ble planlagt på forrige sprint review, og fikk også gjennomført implementasjon av søk på oppgavetittel Sprint review Sprinten ble ferdigstilt til avtalt tid og alle oppgaver ble gjennomført. I tillegg til dette fikk vi også gjennomført implementasjon av søkefunksjonen som ikke skulle prioriteres, men gjennomføres hvis det ble tid. Dette fikk vi tid til, og kunden virket svært fornøyd med at dette ble implementert Statusmøter Avslutningsaktivitet? Opprydning i backlog er nødvendig Avslutningsaktivitet? Avklaring rundt overlevering av produktet Produktdemo 124

125 3.6.5 Sprint 5 Ifølge milepælsplanen var det planlagt en sprint 5. På dette tidspunktet gjensto det kun en uke av prosjektet. For å gjøre klart til overlevering ble den siste uka satt av til å fikse bugs, skrive installasjonsguide og fullføre nødvendig dokumentering. 3.7 Forventningsstyring En stor del av konsulentbransjen handler om å samarbeide med kunden. Dette er viktig for utviklingen da kunden skaper seg et bilde av produktet og vi som utviklere skal etter beste evne gjenskape dette bildet. Da er det viktig at man ikke lover for mye i kommunikasjonen med kunde, men styrer forventningene mot det som er realistisk å forvente Statusmøter Hver uke ble det gjennomført et statusmøte for at kunden skulle få et innblikk i hvordan prosjektet lå an. Her var det viktig å ikke overdrive den reelle fremdriften så kunden ikke ville bli misfornøyd med utfallet av sprinten. Dette var blant annet svært viktig i sprint 1 hvor vi opplevde problemer med CAS. Da var det mye bedre å være åpne om problemene istedenfor å skjule dem, og det gjorde at kunden viste oss forståelse istedenfor å bli misfornøyd Produktdemo Etter hver sprint avholdt vi en produktdemo for å vise frem hva som var blitt utviklet i løpet av sprinten. I tillegg ble det også avholdt noen små demoer dersom det var nødvendig å avklare funksjonalitet med kunden som er vanskelig å forklare med ord. Det viktig å huske på at man viser fram produktet til en kunde som antakeligvis har mindre kompetanse innenfor programmering enn det vi har. Dette gjør at visuelle elementer som kanskje er lette å lage, men som er vanskelig å sette opp bakomliggende funksjon til muligens ikke bør vises med mindre man har startet utvikling av funksjonen bak. Dersom kunden ser dette kan det virke som det er blitt utviklet mye mer enn det som faktisk er blitt, og da vil det være skuffende hvis det ikke er det likevel. 3.8 Avslutning av prosjektet Den 9. mai, to dager før overlevering av produktet, holdt vi en avslutning for prosjektet på HQ. Her ble kunden invitert, og interne ledere i Netcompany var også med. Her fortalte vi om hvordan vi har opplevd rollen som utviklere i konsulentbransjen og gjennomførte en produktdemo for å vise fram det vi har utviklet i løpet av prosjektet. På kvelden ble det avholdt en hyggelig middag ute på restaurant med god mat og god stemning. Hele teamet deltok, kundens produktsjef, interne ledere hos Netcompany og den andre studentgruppa som også har hatt bachelorprosjekt på Netcompany. 125

126 3.9 Evaluering Hva er vi fornøyd med? Scrum Vi har tidligere lært om Scrum på skolen, men dette ga oss kun teoretisk erfaring. Gjennom prosjektet har vi fått brukt det vi har lært i praksis og sett hvor god prosjektstyring man får av ta i bruk Scrum. Forventningsstyring som konsulent Vi har fått muligheten til å få et innblikk i måten en konsulent takler forventningspresset til kundene ved å styre forventningene mot realistiske mål. Dette har vi vært nødt til å gjøre i vårt prosjekt og har både vært lærerikt og spennende. Samarbeid med teamet Vi har vært nødt til å gå fra en hverdag som en gruppe på tre utviklere til et team med flere utviklere og UXere som man må samarbeide med. Vi er veldig fornøyd med måten vi har fått erfare et slikt samarbeid, ettersom det er slik man arbeider i konsulentbransjen Hva kunne vi gjort bedre? Estimering Estimeringen kunne vært gjennomført bedre. Vi kan se på sprint burndown - grafen at den reelle fremdriften ikke nådde den planlagte fremdriften ved noen anledninger i løpet av prosjektet, noe som kunne vært løst om vi hadde estimert annerledes. QA-rutiner QA, både av oss og av UX, kunne vært planlagt og lagt opp til på en mer strukturert måte. Det ble ofte til at QA ble gjort litt i siste liten istedenfor å bli gjennomført jevnlig. Med bedre planlegging kunne man antageligvis unngått flere unødvendige småfeil ved å gjennomføre QA på en jevnlig basis Hva har vi lært? Prosjektet vårt hos Netcompany har gitt oss svært nyttig lærdom. Samtlige i gruppa skal inn i konsulentyrket ved fullført bachelor og vi tror at denne erfaringen er med på å gi oss en god start på yrket som utvikler i konsulentbransjen. Mulighetene vi har fått til å tillære oss ny teknologi, samarbeide med et helt nytt team, kundemøter, deltakelse på faghelg hos oppdragsgiver og mer har gitt oss innblikk i konsulentbransjen som mange andre ikke har mulighet til å få. Vi har fått oppleve forskjellen mellom å utvikle applikasjoner i forbindelse med skoleoppgaver kontra det å utvikle reell programvare som skal til en kunde som betaler penger for det. Ønsket om å utvikle et produkt som kunden opplever som godt og robust er noe man virkelig kjenner på i denne bransjen, og det har vi kjent mye på i løpet av tiden vår hos Netcompany. 126

127 3.9.4 Ord fra prosjektleder Det største fokuset for oss i Netcompany er at de tjenestene vi leverer kundene våre skal være av god kvalitet. Vi etterstreber dette i utviklingen av løsninger, relasjonsbygging med kundene våre og ved rekruttering av nye medarbeidere til bedriften. Martin, Dag og Tobias har imøtegått de kravene vi har til kvalitet på en svært god måte. Hovedhensikten bak studentprosjektene er å tilby et spennende prosjekt for en reell kunde der studentene kan lære og erfare hvordan det er å arbeide på prosjekt i Netcompany. Vi har lagt stor vekt på at den utviklede løsningen skal være deres eget arbeid og har fulgt studentene tett for å sikre at utviklingen møter de kravene vi har til kvalitet. Vi er svært fornøyde med det arbeidet Martin, Dag og Tobias har gjort for oss og er glade for å kunne bekrefte at løsningen er i henhold til de krav og kvaliteter både vi som selskap har satt, men også i forhold til kundens krav. De har vist en svært høy arbeidsmoral og innsatsvilje. Gjennom prosjektforløpet har de fått mulighet til å utvikle både på frontend og backend, samt at de har deltatt i kundemøter. De har taklet alle utfordringer på en god måte og vi gleder oss til alle tre begynner å arbeide hos oss etter endt bachelor. - Ingri Maude, Netcompany. 4. Vedlegg 4.1 Litteraturliste Rosenfeld, L., Morville, P. & Arango, J (2015). Information architecture for the web and beyond. Sebastopol: O Reilly Media Inc. Lepretre, T. (2018, 25. april) Spring Security CAS Starter. Hentet fra Rasmussen, E. (Udatert) Getting started with Redux-form. Hentet fra npm, Inc. (Udatert) react-confirm-alert. Hentet fra Mockito. (Udatert) Tasty mocking framework for unit tests in Java. Hentet fra Berglihn, A. (2017) react/redux og Javascript. Hentet fra JetBrains. (Udatert) IntelliJ IDEA. Hentet fra Git. (Udatert) Git. Hentet fra Gitlab. (Udatert) Gitlab - Concurrent DevOps. Hentet fra 127

128 Postman. (Udatert) Postman makes API development simple. Hentet fra Redux DevTools. (November, 2017) Redux DevTools - A live-editing time travel environment for Redux. Hentet fra 128

129 4.2 Attest fra Netcompany 129

130 4.3 Prosjektdagbok Onsdag 3.januar Første dag hos Netcompany. Introduksjon, foredrag om konsulentrollen og ansattrollen i Netcompany. Gjennomgang av Code of Conduct som er standardprosedyre for alle nyansatte i Netcompany. Vi fikk også en nærmere presentasjon av ematte.no, løsningen vi skal utvikle, og møtte teamet vårt. Torsdag 4.januar 130

131 Kurs i Confluence, samarbeidsplattformen Netcompany benytter. Innføring i arbeidsmetodene vi kommer til å benytte oss av i prosjektet (Scrum, lean innovation, møter, estimering), samarbeid mellom UX og utviklere. Fredag 5.januar Utlevering av PC-er og oppsett av disse. Kurs i Git, versjonskontrollsystem. Innføring i backend-teknologi og utviklingsmiljø. Java / Spring Boot, PostgreSQL. Innføring i prosjektstyringsverktøyet Jira. Mandag 8.januar Innføring i frontend-teknologi og utviklingsmiljø. Gjennomgang av funksjonelle krav for løsningen. Teambuilding - middag med teamet og den andre prosjektgruppa. Tirsdag 9.januar Første møte med kunden, Kommuneforlaget. Gjennomgang av deres mål og ønsker for ematte. Vi fremviste designskisser sammen med UX-teamet og fikk en introduksjon til viktigheten av forventningsstyring i konsulentbransjen. Onsdag 10.januar Avventer tilgang til Kommuneforlagets Confluence og Jira, så vi kan ikke offisielt starte første sprint, så vi benytter tiden til å sette oss inn i de nye teknologiene. Hovedsakelig React/redux og Spring Boot. Torsdag 11.januar Avventer tilgang til Jira, jobber med de nye teknologiene. Vi har gått i gang med å skrive forprosjektsrapport. Dokumentasjonsverktøyet Confluence er svært nyttig for oss da vi får tilgang på alt av nødvendig dokumentasjon herfra. Vi har også laget en midlertidig datamodell basert på kravspesifikasjonen som vi kan bruke til senere. Denne kommer til å endre seg, men vil gi oss en pekepinn på hvordan vi skal bygge opp databasen vår når vi får startet første sprint Fredag 12.januar Avventer tilgang til Jira, jobber med de nye teknologiene og skriver forprosjektsrapport UX-ressursene har i dag hatt møte med kommuneforlaget for å gjennomgå prototypen de har laget. Onsdag 17.januar Avventer tilgang til Jira. Vi begynner å bli noe utålmodige etter å starte, så vi har begynt utviklingen av en funksjonsløs login-side som vi satser på å ta i bruk i første sprint. 131

132 Torsdag 18.januar Avventer tilgang til Jira. Vi har i dag laget ferdig login-siden som matcher skissen Kommuneforlaget var svært fornøyd med. Fortsatt ingen tilgang på Jira, vi håper det nærmer seg nå. Fredag 19.januar Innlevering av Forprosjekt Vi har i dag fått en bruker på Kommuneforlagets Jira og kan dermed starte første sprint. Vi har brukt dagen på å velge ut oppgaver fra backlogen, estimere og gjennomgå hvordan sprinten vil foregå. Sprinten vil vare i 3 uker, fram til 9. februar. UX har i dag gjennomført sin første brukertest på en potensiell fremtidig bruker av ematte. Neste uke vil det bli gjennomført to brukertester på mandag og tirsdag og vi er spent på å høre input fra brukerne. I dag har vi også innlevering av forprosjektsrapporten og har også brukt tid på å finpusse og levere denne. Onsdag 24.januar Nå har alle fått tilgang på Kommuneforlagets Jira og vi har gått i gang med første sprint. Sprinten består hovedsakelig av innloggings-funksjonalit, samt visning av oppgaver og oppgavesett. Vi har beregnet mye tid til innlogging da vi aldri har hatt erfaring med CAS før. Torsdag 25.januar I samsvar med teamets tekniske support og arkitekt har vi i dag pauset jobbingen med innloggings-funksjonalitet. Ettersom at det skal gjøres via kommuneforlagets CAS viser det seg at vi antageligvis ikke får brukt vår egen loginside, men heller en egen standardside som CAS tar i bruk.. Vi har derfor gått i gang med en landingsside for applikasjonen der en liste med oppgaver og oppgavesett skal vises. Fredag 26.januar Denne uken har ⅔ gruppemedlemmer vært slått ut med influensa og ikke vært i stand til å være på jobb, så vi har vært noe redusert. Vi ser på dette som god læring ettersom man alltid vil oppleve sykdom i arbeidslivet. Vi er fortsatt i startfasen av prosjektet så dette er ikke et alvorlig problem for prosjektet. Jobbet med landingssiden og funksjonalitet for å vise oppgaver og oppgavesett Onsdag 31.januar Samtlige gruppemedlemmer er blitt friske og er tilbake på jobb. Vi har fortsatt arbeidet med landingssiden. Torsdag 1.februar I dag har teknisk support- og arkitekt vært hos oss for å snakke om CAS. De har ingen tidligere erfaring med denne innloggings-funksjonaliteten og er derfor like avhengig av å lese dokumentasjon som oss. Dette byr på en del utfordringer for CAS har mye funksjonalitet 132

133 som foregår bak kulissene, eller som vår tekniske support sier: automagisk. Vi satser på å få implementert dette i løpet av de neste dagene så vi rekker å ferdigstille det innen sprinten avsluttes. Fredag 2.februar Fortsetter med landingssiden og funksjonalitet for å vise oppgaver og oppgavesett Fortsetter å jobbe med innlogging via CAS. Tirsdag 6.februar Statusmøte med kommuneforlaget, gjennomgang av det vi har utviklet så langt. Onsdag 7.februar Vi har ferdigstilt landingssiden og levert denne til QA slik at vi kan få tilbakemeldinger og kommentarer. Vi har også fortsatt med CAS. Torsdag 8.februar Fortsetter med feilretting etter tilbakemeldinger fra QA og CAS. Fredag 9.februar Avslutning første sprint (utsatt) Alle tasks, utenom innlogging, har gjennomgått QA og blitt rettet på slik at de kan settes som ferdig. Vi har fått merget branches sammen og fått dette inn i master-branchen. Sprinten var estimert ferdig i dag, men problemer med CAS gjør at vi må utsette dette noen dager. Vi har løpende kontakt med Kommuneforlaget for å holde dem orientert om problemene. Tirsdag 13.februar Ringer en med kompetanse på CAS hos Kommuneforlaget, ettersom både vi og vår tekniske arkitekt sliter med å få dette til å fungere, og han forteller at han ikke har vært borti implementasjon av CAS på prosjekter med vår struktur. Vi har oppdelt backend og frontend separat fra hverandre, noe som gjør at prosjektet kjører på forskjellige porter. Vi og vår tekniske support har forsøkt mye for å åpne opp API-kall ved innlogging, men vi klarer ikke få det til å virke. I samsvar med teknisk support kommer vi frem til at CAS er er umulig, eller svært vanskelig å implementere med vår nåværende arkitektur. For å spare mest mulig tid har vi derfor bestemt oss for å gå i gang med restrukturering av hele prosjektet. Onsdag 14.februar Utsatt avslutning av sprint 1. I dag har Martin gått i gang med restrukturering av prosjektet, mens Dag og Tobias har avsluttet første sprint og begynt å se på hva som bør gjøres i den neste. 133

134 I arbeidet med å restrukturere prosjekt har vi kommet fram til at vi må ta i bruk webpack for å pakke frontend-filene slik at backend kan aksessere og lese disse gjennom en bundle - fil. I neste sprint ser vi for oss at forhåndsvisning av oppgaver og oppgavesett vil være et naturlig startpunkt og har derfor gått i gang med å utvikle modaler som viser disse. Torsdag 15.februar Jobbet videre med restrukturering av prosjektet og utvikling av forhåndsvisning-modaler. Fredag 16.februar Sprint review hos kommuneforlaget, gjennomgang av hva som har blitt gjort og hva som har bydd på problemer. I dag har vi hatt et stort gjennombrudd i restruktureringen av prosjektet. Etter mye lesing på dokumentasjon har vi fått implementert webpack i prosjektet og fått pakket alle frontendfilene inn i en bundle fil. Nå gjenstår det kun å få denne ut i index.html, men dette ordner vi til uka. Tirsdag 20.februar Webpack virker nå som det skal. Alle frontend-filene pakkes i bundle og vises til bruker når man aksesserer applikasjonen. Har begynt implementeringen av CAS i det restrukturerte prosjektet, men har støtt på de samme problemene som oppsto i det andre prosjektet. Kommer til å bruke endel tid framover på å lese dokumentasjon på CAS og se på eksempler Onsdag 21.februar Statusmøte med Kommuneforlaget, hva skal være med i sprint 2? Sprint retrospekt, utfordringer, hva som har gått bra og forbedringspotensiale. Planlegging og estimering av sprint 2. Sprint 2 består hovedsakelig av: ferdigstilling av innloggings-funksjonaliteten, visning av individuelle oppgaver og oppgavesett, og oppretting av nye oppgaver. Martin fortsetter arbeidet med restrukturering av prosjektet, mens resten går i gang med den nye sprinten. Torsdag 22.februar Begynt å lage funksjonalitet for å forhåndsvise oppgaver og oppgavesett, samt backendfunksjonalitet for å hente riktig oppgave med deloppgaver, pluss modalen i frontenden. Vi har laget nye tabeller for å få databasen på 3.normalform og puttet disse inn i DTO til en Task. Fortsatt arbeidet med å implementere CAS i det restrukturerte prosjektet Fredag 23.februar Jobbet med modalen som viser oppgavesett, hovedsaklig frontend. Ferdigstilt modalen som viser en oppgave samt mange forbedringer i backend. Også laget meny hvor man kan velge å lage en ny oppgave. 134

135 Martin har i samsvar med teknisk arkitekt blitt enig om at han begynner med oppgaver tilknyttet den nye sprinten fra neste uke ettersom implementeringen ble langt mer tidkrevende og vanskeligere enn først antatt. Teknisk arkitekt- og support vil ta over arbeidet med CAS. Tirsdag 27.februar Jobbet med modal som skal vises når man skal lage ny oppgave. Veldig mye logikk og funksjonalitet som trengs for å lage et multi-page form med redux. Petter var også tilstede på morgenen og jobbet med CAS. Onsdag 28.februar Statusmøte med kommuneforlaget Begynner å haste med å få ferdigstilt login så dette har blitt prioritert. Fortsatt en del problemer her, er noe usikre på om vi må gå til kunden og si at vi bør velge en annen løsning. Vil forsøke å løse dette denne uken. Begynt med backend funksjonalitet for å ta i mot en oppgave fra frontenden og lagre dette i databasen. Jobbet med modalen som skal vises for å lage en ny oppgave, litt komplikasjoner med å få redux form til å ta imot data fra formet Torsdag 1.mars Begynt å lage input-form og begynt med backend-delen som tar i mot datene og lagrer disse i databasen. Modalen for å lage ny oppgave begynner å nærme seg, men er mer komplekst enn først antatt. Input-formet strekker seg over flere sider og inneholder veldig mye og varierende data. Fredag 2.mars Fortsetter jobben med input-formet samt backend-delen for å lagre en oppgave i databasen. Dette begynner å nærme seg nå, men en-til-mange relasjonen mellom oppgave og deloppgave viste seg å være litt kinkig. Har også gjennomført QA på en del tasks i dag ettersom at det lå mye som var klart for QA. Frontend-delene av dette er sendt videre til UX for QA hos dem. Onsdag 7.mars Ferdigstilt funksjonaliteten i back end som lagrer en oppgave i databasen, fortsetter med å sende oppgave fra front end til back end. Endelig er CAS på plass og innloggingsfunksjonaliteten fungerer som den skal. Du blir nå redirectet til kommuneforlagets login side. Man kan også nå opprette en ny oppgave, men her trengs det fortsatt en del forbedringer. I dag har vi også gjort en del dokumentasjonsarbeid. Vi har begynt å sette opp prosjektrapporten og begynt å adressere hvor og hva på confluence vi har behov for å bruke. Torsdag 8.mars Jobbet med flere forskjellige ting for å få applikasjonen klar til vår første demo neste onsdag. Her skal vi vise Kommuneforlaget hva vi har utviklet så langt. I dag har vi fått input-formet til 135

136 å resette seg ved submit og exit, ordnet med autentisering av brukeren som er innlogget, fikset parsingen og ordnet med valideringen til formet. Vi hadde planer om å ordne utloggings-funksjonalitet før demoen, men dette blir noe nedprioritert da vi har mye QA å gjøre. Fredag 9.mars I dag har vi gjennomført mye QA og finpusset på det som trengte finpuss. Ellers har Martin og Tobias fortsatt med CAS og prøvd å få utloggingsfunksjonaliteten til å virke. Vi har enda fått det helt til, og forventer heller ikke å være klare med dette til demoen på onsdag. Det viktigste er likevel på plass: vi har nå muligheter for å lage oppgaver i frontenden gjennom et form. Dag og Martin har finpusset på dette så det matcher skissene vi har fått fra UX-teamet. Ved å gjennomgå formet blir tasken lagt inn i databasen og kan vises ut på hjemskjermen. Tirsdag 13.mars I morgen er det demo hos Kommuneforlaget. Vi ser frem mot å vise frem produktet vi har utviklet til nå og ønsker selvfølgelig at kunden skal få best mulig inntrykk. Vi har derfor gjort ferdig de siste taskene som lå på scrum boardet: ferdigstilt utloggingsfunksjonalitet og fikset validering på formet for ny oppgave. Vi har også gått gjennom QA og UX-QA og gjort en del bugfixes som ikke skal være i programmet når det overleveres til Kommuneforlaget i mai. Onsdag 14.mars Avslutning Sprint 2 Vi har i dag planlagt avslutning av sprint 2. Denne sprinten har gått veldig bra, og vi må ærlig innrømme at jobbtilbudet vi fikk i starten av sprinten har vært med på å holde motivasjonen skyhøy. Derfor har vi jobbet knallhardt for at vi skulle komme gjennom denne sprinten, og resultatet har blitt veldig bra. Sprint review hos Kommuneforlaget Vi og prosjektleder hadde et møte med Kommuneforlaget der vi gikk gjennom hva som har blitt gjort fram til nå, og hadde en liten demo av den nye funksjonaliteten, hovedsakelig logg-inn med CAS og oppretting av nye oppgaver. I tillegg kom vi til enighet med Kommuneforlaget over hva som skal være hovedfokus for neste sprint. Sprint retrospekt Etter sprint review holdt vi internt et sprint retrospekt sammen med prosjektleder og ressursen vår, der vi ved avvikling av sprinten gjennomgår hva som gikk bra, hva som kunne 136

137 gått bedre, og hvilke punkter vi tar med oss videre. Etter denne retrospekten brainstormet vi litt om løsningen og Petrit foreslo å implementere google sin søkemotor for bilder med fri lisens, noe som kan være en løsning på problemet om at brukere skal kunne laste opp bilder fritt fra internett. I tillegg ble det foreslått å iverksette brukertesting av løsningen, ettersom den er utviklet til et punkt der brukertest er mulig. Dette tar vi med til statusmøtet 20. mars. Veiledningsmøte med Ismail 14:00-15:00 Var på møte hos veileder hvor vi snakket om løsningen vår så langt, og viste en demo av hvor langt vi hadde kommet. Vi fikk mye klarhet i hva som bør fokuseres på og viktigheten av dokumentering av prosessen. Vi fikk også vite hva som bør vektlegges på presentasjonen og at det er veldig positivt å ha med noen fra NC til presentasjonen Planlegging og estimering av sprint 3 På slutten av dagen planla vi hva av funksjonalitet som skal implementeres i løpet av sprint 3, og estimering av tidsbruk på denne funksjonaliteten. Hovedsakelig skal fokuset for sprint 3 være at brukeren skal kunne opprette oppgavesett, i tillegg lagre brukeren i databasen for å for eksempel bare kunne vise egne publiserte oppgaver, men også legge til rette for videre funksjonalitet, som for eksempel kommentarer og rating. Torsdag 15.mars Begynt arbeidet med sprint 3, lagde backendfunksjonalitet for å lagre oppgavesett i databasen, og for å koble brukere til oppgaver og oppgavesett. 137

138 Vi oppdaget at vi har mye refaktorering å gjøre, slik at komponenter blir mer tilgjengelig for gjenbruk. Dette fikk vi gjort veldig mye av i dag. Søndag 18.mars Resktrukturer nesten all css og modulisert nesten hele frontenden. Dette var veldig nødvendig for å opprettholde en høy kodekvalitet og unngå redundans i koden. Ytelsen blir også hevet. Tirsdag 20.mars Statusmøte hos kommuneforlaget, vi hadde spørsmål om bildebruk i oppgaver, brukertesting og noen avklaringer om oppgavesett. Kom frem til at bilder er viktige, og burde implementeres flere steder, som f.eks. oppgave, fasit og vedlegg, og at man skal kunne bruke lokale bilder, og bilder fra internett. De var enige om at brukertester bør iverksettes. Etter litt diskusjon kom vi frem til at oppgavesett sine typer og temaer burde bestå av oppgavene i oppgavesettet sine typer og temaer. En bruker som oppretter oppgavesett bør kunne velge ett klassetrinn for oppgavesettet, men ikke vanskelighetsgrad. I en lærer sitt preview av et oppgavesett bør oppgavene sine trinn og vanskelighetsgrad vises, men dette bør skjules for elever. I tillegg kom vi frem til at visningen av vanskelighetsgrad for oppgaver i løsningen nå ikke er brukervennlig, ettersom det ikke er indikert hva skalaen går til. Et forslag var å vise alle vanskelighetsgradene og highlighte oppgavens vanskelighetsgrad. Onsdag 21.mars Jobbet med formet for å lage oppgavesett. Mye frontend som må gjøres. Torsdag 22.mars Fortsettet arbeidet med form for å lage oppgavesett. Lagd enums for å sjekke på hvilken type av modal man skal vise frem og om man vil legge til, fjerne eller resette pickedtasks. Man kan nå velge oppgaver fra en liste og legge disse inn i et oppgavesett og publiserer de. Fredag 23.mars Nesten ferdigstilt skjemaet for å lage oppgavesett, bare små bugfixes + QA igjen. Gjenstår ikke så mye igjen i sprinten, kan hende vi henter noe fra backloggen til denne sprinten hvis det blir ekstra tid. Tirsdag 3.april Ferdigstilt skjemaet for å lage oppgavesett, levert til UX-ressursen for QA. Mye bugfixing og forbedringer idag. Task og taskset er nå i en liste. Gjort slik at hibernate håndterer setting av many to many og one to many relasjoner. Onsdag 4.april Statusmøte hos kommuneforlaget Vi har internt vurdert viktigheten av å kunne forhåndsvise oppgaver ved sammensetting av oppgavesett, til svært viktig, men dette er ikke en del av speccen til produktet. Vi har brukt noe tid på å lage en slik forhåndsvisning, og i dag valgte vi å vise dette fram for KF. De svarte at de hadde også tenkt på dette, og syntes vår løsning så svært bra ut. 138

139 I dag har vi oppdaget problemer ved oppgaveinput. Subtasks blir ikke tildelt en task_id og blir derfor ikke lagt ved oppgavene. Dette har vi fått ordnet opp i, og startet med å lage tester slik at det skal være enklere å oppdage feil. Ellers har vi ryddet opp i en del små bugfixes og gjort noen små forbedringer her og der. Torsdag 5.april I dag har vi ferdigstilt mange enhetstester, og mangler bare litt på tasksets før vi er ferdig. Vi har også begynt å utvikle automatiserte enhetstester slik at vi lettere skal kunne oppdage feil som oppstår. Et godt eksempel på når vi hadde trengt dette hadde vært i går når vi oppdaget problemene med subtasks. Hadde vi hatt automatiserte tester ville vi kunne oppdaget feilen tidligere og også funnet roten til problemet raskere. Vi skal innen kort tid sette oss ned og lage en testplan Har i dag hatt et møte med teknisk support. Han har vært borte de siste 3-4 ukene siden han har blitt pappa, så vi gjennomgikk det vi har gjort så langt mens han har vært borte. Vi ble enige om at siden neste sprint er den siste vil vi måtte ha et lite internt møte i teamet slik at vi kan sette oss ned og definere de viktigste aspektene ved applikasjonen. For oss er det viktig å levere et så helt produkt som mulig og derfor er det viktig at dette blir fokus i siste sprint. Den siste tiden fram til levering kommer til å brukes på bugfixes. Håndterer nå godkjent publisering med en popup som brukeren må trykke vekk, etter anbefaling fra Petrit(UX). Her vises også kopier og del linken. Har også lagt inn beskjed om at et oppgavesett er tomt hvis ingen oppgaver er lagt til. Søndag 08.april Jobbet med å ferdigstille sprinten, noen bugfixes og tester som måtte skrives før sprint review på onsdag. Mandag 9.april Dro til kontoret på kvelden for å jobbe med bugfixes som bør være på plass før sprint review på onsdag. Tirsdag 10.april Siste innspurt før sprint review onsdag. Gjorde om måten listen med oppgaver vises, slik at den er responsiv, pluss andre bugfixes. Ettersom det bare er en måned igjen av prosjektet, kalte prosjektleder hele teamet inn til møte klokka 15 for å diskutere/brainstorme hva som bør være fokus for siste del av prosjektet. Onsdag 11.april Sprint review hos Kommuneforlaget Sprint 3 ble gjennomført i henhold til estimeringen, pluss at vi fikk en liten tyvstart på litt funksjonalitet som egentlig tilhører sprint 4. Vi holdt en demo, og KF var fornøyd med resultatet av sprinten. KF stilte i tillegg med Carl-Erik, som er utvikleren av den originale løsningen ematte.no. Han hadde mange ideer og innspill, og i sammen kom vi frem til at filtrering av oppgaver, markere oppgaver som favoritt og sortere oppgaver og oppgavesett 139

140 etter flest favoritter, og etter nyeste og eldste, og det å kunne legge oppgaver til i eksisterende oppgavesett. Etter sprint review tok vi en sprint retrospekt sammen med prosjektleder og Petrit(UX) der vi kom fram til blant annet at vi bør forbedre QA-rutinen vår internt i teamet og skrive flere kommentarer i koden for å gjøre den mer vedlikeholdbar og leselig. I planlegging av sprint 4 tok vi det vi kom frem til i sprint reviewet og laget tasks til det i JIRA og estimerte story points til brukerhistorier ved hjelp av planning poker, og estimerte timer på taskene vi lagde. Torsdag 12.april Mye bugfixing og omstrukturering på CSS. Fredrik, den tekniske ressursen vår, begynte på backenden for favoritt-funksjonaliteten, bl.a. lagd tabellen i databasen. Fredag 13.april Arbeidet videre med filtrering på nettsiden Tirsdag 17.april Ferdigstilt filtering på oppgave/oppgavesett og klassetrinn. Laget en funksjon som tar inn filtrering type og relevante filtre som deretter filtrer på alle parametrene. Lagt til funksjonalitet i backend for å hente antall ganger en oppgave eller et oppgavesett har blitt lagt til favoritter, noe som er nødvendig for sorteringen. Onsdag 18.april Mer arbeid med backend-funksjonalitet for favoritter, laget to tabeller for oppgaver og oppgavesett-favoritter, og endret metodene i backend for å tilsvare de nye tabellene. Lagd actions i front end til å lagre og fjerne valgte oppgaver som favoritter i databasen. All filtrering fungerer nå som det skal. FIltrering foregår i frontenden etter alle oppgaver og oppgavesett er hentet. Vi tror filtreringen må forbedres noe, da koden er svært kompleks Torsdag 19.april Mer arbeid med favoritt-funksjonaliteten i backend, begynt med arbeidet å sette oppgaver/oppgavesett i frontend til favorisert basert på dataene databasen. Ferdigstilt filtrering i sidebar, og laget filtrering for å legge til oppgaver i oppgavesett. Nå er filtreringen helt ferdig, og vi har også ferdigstilt sortering på nettsiden Fredag 20.april Laget en informasjonsboks på nettsiden og gjort QA på oppgaver som er ferdigstilt. Jobbet med den skriftlige rapporten til bacheloren Tirsdag 24.april Gjort forbedringer på tilbakemeldinger fra QA og jobbet med rapporten Onsdag 25.april Jobbet med å ferdigstille favoritt-funksjonalitet både frontend og backend, fikset blant annet et sikkerhetsproblem som gikk ut på at vi sendte med identifikatoren til innlogget bruker 140

141 over REST-kall, dette gjøres nå i backend. La til funksjonalitet for å legge til flere oppgaver og oppgavesett til som favoritt samtidig. Diverse bugfixes og forbedringer. Mandag 30.april Bugfiksing med å gjøre slik at valgte oppgaver ble deselected da man navigerte bort fra der man velger oppgaver og fikset slik at ikke hele oppgavelisten blir skrevet ut med en gang Tirsdag 1.mai Fikset en kritisk bug der forhåndsvisning av oppgaven ikke ble vist på riktig sted. Forbedringer i backend der vi fjernet mulighet til å forsøke å lagre noe som eksisterer fra før. UX-forbedring ved å gi brukeren beskjed når den legger til ting som favoritter. Søking er implementert og favoritter kan nå settes og en del optimalisering av filtrering. Onsdag 2.mai Review av siste sprint hos Kommuneforlaget. Feilkommunikasjon mellom oss og prosjektleder, ettersom vi trodde sprint review skulle være på fredag. Endte med at vi fikk 40 minutter til å forberede en demo på det vi har gjort i denne sprinten. Sprint reviewet gikk bra, og kunden er fornøyde med det vi har levert hittil. Sprinten avsluttes fredag, og gjenstår diverse forbedringer og bugfixes som må jobbes med til da. Torsdag 3.mai Nest siste på sprint 4, vår siste sprint i dette prosjektet. Diverse forbedringer og bugfixes som må på plass. Mye enhetstesting av backend + mange forbedringer front end. Vi ser på muligheten for å forbedre filtreringsmetoden. Fredag 4.mai Avslutning Sprint 4 I dag er siste dagen av sprint 4. Vi har brukt dagen på å gjennomføre QA og gjort endel bugfixes. Nå som det kun er en uke til prosjektet skal overleveres til kunden vil det ikke være rom for å utvikle flere funksjoner. Vi har derfor neste uke på å fjerne bugs, fjerne visuelle elementer uten funksjon og rydde opp i kode. Dette blir neste ukes fokus slik at produktet er klart for kunden til overleveringsdato. Onsdag 9.mai To dager til innlevering, dagen gikk til å klargjøre for overlevering til kunde. Fjernet front end som tilsa at funksjonalitet som ikke var der var implementert, for eksempel rating og kommentarer. Intern avslutning for bachelorprosjektene, presenterer vårt prosjektet både for de interne, men også produkteier hos Kommuneforlaget. Torsdag 10.mai Klargjort for produksjon, lagt til javadoc for frontend. Fredag 11.mai Overlevering av produkt 141

142 4.4 Teknisk dokumentasjon for Kommuneforlagets SSOløsning Innhold Dette dokumentet beskriver hvordan leverandører integrerer seg med Kommuneforlagets Singlesign-on løsning (SSO). Helt konkret er det to komponenter man må integrere med Microsoft Active Directory (AD) og Central Authentication Service (CAS). I tillegg kan det være aktuelt å integrere mot KF Brukeradm, dersom man trenger tilgang til hvilke applikasjoner en organisasjon har tilgang til, organisasjonsenhetstrær, tilgangsstyring, organisasjonsspesifikke logoer og lignende. Innhold Begrep og forkortelser Microsoft Active Directory KFApplications KF-Administrator KFOrganizationAffiliation KFUsers Hvordan integrere med AD Brukeradm services Organisasjonstilgang versjon 1 (deprekert, vil bli fjernet i fremtidige versjoner - bruk nyeste versjon av tjenesten) Organisasjonstilgang versjon 2 (med språk) Organisasjonens IP-adresser Organisasjoner som eier en gitt IP Organisasjonsenheter og struktur Tilgangene til en gitt bruker Brukere med tilganger til en organisasjonsenhet Organisasjonslogo Organisasjonsbanner Endre egen bruker Central Authentication Service Begrep og forkortelser KF - Kommuneforlaget. SSO - Single-sign-on. AD Microsoft Active Directory. OU Organizational Unit, en objekt-type i AD. InetOrgPerson En objekt-type i AD, representerer en bruker. Security Group En objekt-type i AD, representerer en rolle eller en organisasjon. Brukeradm Brukeradministrasjons applikasjon JSON Java Script Object Notation. CN CommonName, et attributt i AD. UUID Universally Unique Identifier. CAS - Central Authentication Service. KF Brukeradm - Et KF-spesifikt system for administrasjon av brukere og organisasjoner tilknyttet KFs SSO-løsning. Microsoft Active Directory AD er brukerdatabasen. Denne bruker man for å hente ut all brukerinformasjon, og er også basis for data og funksjonsautorisasjon. AD inneholder følgende rotnoder av typen "Organizational Unit": KFApplications - applikasjoner og roller KFOrganizationAffiliation - organisasjonstilhørighet KFUsers - brukere i KF SSO Tilgang fra applikasjoner til disse OUene i AD skal kun benyttes for lesing. Applikasjoner og deres roller legges inn manuelt av KF's driftsorganisasjon. All annen administrasjon av (skriving til) disse OUene gjøres via Brukeradm-applikasjonen. Se ellers "Hvordan integerere med AD" nedenfor. 142

143 KFApplications Her ligger det en «Organizational Unit» for hver applikasjon. Navnet som brukes her vil gjenspeiles i Brukeradm applikasjonen, og i web service'en man bruker for å sjekke hvilke organisasjoner som Felt/forretningsnavn AD attribute Kommentar ID cn UUID - Systemgenerert Fornavn Etternavn Telefon givenname surname telephonenumber Epost/Bruker-id mail Må være unik Passord unicodepwd Kan aldri hentes ut, men kan "bindes" (logge inn) med. Språk Tittel Kommentar preferredlanguag e title comment har hvilke tilganger til applikasjoner (se "Brukeradm webservices"). Under hver OU finner man grupper, en gruppe per rolle. Den globale «KF-Administrator» rollen ligger også her. Rollene din applikasjon trenger skal legges her. Applikasjonsnavn og navnet på rollene (Groups) applikasjonen trenger fortelles til IT avdelingen til KF, så legges det inn. F.eks. finnes følgende i AD i dag: Brukeradm (OrganizationUnit) Brukeradm-Administrator (Group) Applikasjonen "Brukeradm" har en rolle, Brukeradm-Administrator. Obs: Rollene gjenspeiles i brukeradm-applikasjonen uten navnet på den omfavnende OUen. Rollene bør derfor ha navn som gjenspeiler applikasjonsnavnet, som i eksemplet over: Administratorrollen i brukeradm heter "Brukeradm- Administrator", ikke bare "Administrator". KF-Administrator Dette er en helt spesiell rolle som ligger rett under "KFApplications" OU'en. Denne rollen tilhører ingen applikasjon, men er tenkt som en global rolle som skal gi tilgang til alt. Brukere som har denne rollen er typisk driftere i Kommuneforlaget. I flere av applikasjonene er denne rollen implementert med at en bruker med rollen først velger organisasjon han/hun skal se på, for deretter å bruke applikasjonen som en applikasjons- 143

144 administrator. Det må avtales med KF hvordan denne rollen skal fungere i din applikasjon. KFOrganizationAffiliation Hver organisasjon er lagret som en gruppe. Gruppenavn (attribute "cn"), er organisasjons id (typisk kommunenummer), Gruppebeskrivelse (attribute "description") er organisasjonens navn (typisk kommunenavn) KFUsers Her lagres brukerne Brukerne lagres under «organizational units», men disse har ingen funksjonell betydning. Dette er en splitting gjort for at ikke alle brukere skal havne under samme node. Brukerne lagres som «InetOrgPerson»-objekter Den enkelte brukers organisasjonstilhørighet styres av memberof attributtet. En bruker kan være tilknyttet flere organisasjoner samtidig. Den enkelte brukers rolletilhørighet styres med memberof attributtet. brukes som brukernavn. CN blir generert av Brukeradm som en UUID. Roller styres ved å legge rolle-grupper til en bruker. Organisasjonstilhørighet styres ved å legge organisasjons-grupper til en bruker. Brukerdata lagres i henhold til følgende tabell: Et eksempel på LDIF output for en bruker fra AD: objectclass: inetorgperson objectclass: organizationalperson objectclass: person objectclass: top objectclass: user cn: abc2ac98-15d2-4f00-a a5 instancetype: 4 objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=kinn,DC=id,DC=loca l accountexpires: badpasswordtime: badpwdcount: 0 codepage: 0 comment: En kommentar countrycode: 0 description: distinguishedname: CN=abc2ac98-15d2-4f00-a a5,OU=1622,OU=KFUsers,DC=kinn,DC=id,D C=local dscorepropagationdata: Z givenname: Alf Kristian lastlogoff: 0 144

145 lastlogon: lastlogontimestamp: logoncount: 0 mail: alf.kristian@gmail.com name: abc2ac98-15d2-4f00-a a5 objectguid:: 9+NJEsdRIU+HkwrhXi1apw== objectsid:: AQUAAAAAAAUVAAAA3RA2vrEMNRW1Yx/bHAUAAA== preferredlanguage: no_no primarygroupid: 513 pwdlastset: samaccountname: abc2ac9815d24f00a256 samaccounttype: sn:: U3TDuHlsZQ== telephonenumber: title: Utvikler useraccountcontrol: usnchanged: usncreated: whenchanged: Z whencreated: Z memberof: CN=1622,OU=KFOrganizationAffiliation,DC=kinn,DC=id,DC=loca l memberof: CN=1820,OU=KFOrganizationAffiliation,DC=kinn,DC=id,DC=loca l memberof: CN=Brukeradm- Administrator,OU=BrukerAdm,OU=KFApplications,DC=kinn,DC=id,DC =local memberof: CN=Kvalitet- Administrator,OU=Kvalitet,OU=KFApplications,DC=kinn,DC=id, DC=l ocal Veldig mange av disse feltene er generet av AD. Det er feltene i tabellen over som har forretningsverdi i tillegg til memberof. "memberof" attributtet noe av det viktigste her. Denne angir både organisasjonstilhørighet og brukerens roller. Denne brukeren tilhører organisasjonen 1622 og Og brukeren har rollene "Brukeradm-Administrator" og "Kvalitet-Administrator". Hvordan integrere med AD 1. Be KF opprette en «Organizational Unit» under «KFApplications» i AD 2. Be KF opprett grupper under den nyopprettede applikasjonens organizational unit», en gruppe 145

146 for hver rolle som finnes i systemet. Gruppen bør ha et unikt navn, f.eks. NTK- Oversetter. 3. Be KF opprette en applikasjonsbruker for den nye applikasjonen. Og motta fullt distinguished name (DN) og passord for denne for å logge seg på AD. 4. Få en tilgangsnøkkel fra kommuneforlaget som kan brukes for å aksessere Brukeradm sin webservice. Applikasjonen står deretter fritt til å gjøre ldap søk mot AD, for å hente ut nødvendig brukerinformasjon. I hovedsak er det tre ting som er interessante: Brukerinformasjon - epost, navn, telefonnummer osv. Roller - Funksjonsautorisasjon, f.eks. NTK-Oversetter eller Brukeradm-Administrator Organisasjonstilhørighet - Data autorisasjon, f.eks. bruker tilhører Storevik kommune, og skal ha tilgang til Storevik sine data. Brukeradm services Organisasjonstilgang versjon 1 (deprekert, vil bli fjernet i fremtidige versjoner - bruk nyeste versjon av tjenesten) Brukeradm eksponerer en web service som angir hvilke organisasjoner/kommuner som har tilgang til en applikasjon. Denne web servicen kan aksesseres på: Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <app-navn> - f.eks. ntk, dette er navnet på din applikasjon <nøkkel> - et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. For eksempel: Webservicen vil gi svar i form av en JSON-streng som inneholder informasjon (id og navn) på alle organisasjoner som har tilgang til applikasjonen. Eksempel på svar: Dette betyr at "1820 Alstahaug" og "9900 Kommuneforlaget" har tilgang til applikasjonen "kvalitet". Organisasjonstilgang versjon 2 (med språk) Brukeradm eksponerer en web service som angir hvilke organisasjoner/kommuner som har tilgang til en applikasjon. Fra og med versjon 2 av denne tjenesten gir denne også noe tilleggsinformasjon om organisasjonen, i versjon 2 hvilket språk som er satt som standardenhet. Obs! Strukturen er endret vesentlig siden versjon 1. /accesskey/<nøkkel> n-access/kvalite t/accesskey/3a1e 146

147 {"1820":"Alstahaug","9900":"Kommuneforlaget"} vn>/accesskey/<nøkkel> Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <app-navn> - f.eks. ntk, dette er navnet på din applikasjon <nøkkel> - et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. For eksempel: Webservicen vil gi svar i form av en JSON-streng som inneholder informasjon (id og navn) på alle organisasjoner som har tilgang til applikasjonen, pluss informasjon om disse der slik er tilgjengelig. Eksempel på svar der Alstahaug ikke har valgt språk, men Kommuneforlaget har det: Dette betyr at "1820 Alstahaug" og "9900 Kommuneforlaget" har tilgang til applikasjonen "kvalitet". Alstahaug har ikke valgt språk, Kommuneforlaget har valgt nynorsk. (Den andre muligheten per i dag er "nb" for bokmål.) Organisasjonens IP-adresser Brukeradm eksponerer en web service som angir hvilke IP-adresser som tilhører en kommune. Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <org> - "organisasjonsnummeret" eller kommunenummeret for organisasjonen, f.eks for Alstahaug eller 9900 for Kommuneforlaget. <nøkkel> - et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. For eksempel: Webservicen vil gi svar i form av en JSON-streng som inneholder en liste over IPer og IP-ranges organisasjonen har definert som sine egne. Wildcards støttes i IPen. Eksempel på svar der en kommune ikke har definerte IP'er: n-access/v2/kval itet/accesskey/3a1e [{"id":"1820","name":"alstahaug"},{"id":"9900","name":"kom muneforlaget","l anguage":"nn"}] ey/<nøkkel> 147

148 on-ip/1820/acces skey/3a1e [] Eksempel på svar der en kommune har to definerte IP'er: [" "," "] Eksempel på svar der en kommune har en definert IP-range: Organisasjoner som eier en gitt IP Brukeradm eksponerer en web service som lar deg slå opp hvilke organisasjoner (om noen) som står som eiere av en gitt ip-adresse. Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <ip> - IPadressen du ønsker å slå opp, f.eks <nøkkel> - et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. For eksempel: Webservicen vil gi svar i form av en JSON-streng som inneholder en liste over "organisasjonsnumre", f.eks. kommunenummere, som har definert IP'en som sin egen. Organisasjonsenheter og struktur Brukeradm eksponerer en web service som gir informasjon om organisasjonsstrukturen en kommune har definert for en gitt organisasjon. Obs: Dette kan endre seg over tid, og det er den enkelte applikasjon sitt ansvar å håndtere endringer i strukturen. Merk videre at strukturen kan ha et annet navn Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <org> "organisasjonsnummeret" eller kommunenummeret for organisasjonen, f.eks for Alstahaug eller 9900 for Kommuneforlaget. <app> ID'en til applikasjonen som organisasjonsstrukturen er definert for, f.esk. BS2 for Bedre Styring. I tillegg må følgende header settes i requesten: accesskey=<nøkkel>, der <nøkkel> er et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. [" *-100"] 148

149 id/<ip>/accesske y/<nøkkel> ion-id/ /accesskey/123 For eksempel: ["1622"] Webservicen vil gi svar i form av en JSON-streng som inneholder strukturen. For eksempel: [ { }, { } ] "id": "540f36d7-fbbf-48fb-848a-ec91bd8a9078", "title": "Agdenes", "externalorgid": "1622" "id": "d7cddb91-52f4-4d20-95b5-45fb27d8ee14", "title": "ueouoa", "externalorgid": "1622", "parentid": "540f36d7-fbbf-48fb-848a-ec91bd8a9078" Tilgangene til en gitt bruker Brukeradm eksponerer en web service som gir informasjon om hvilke brukere som har tilgang til en organisasjonsenhet for en gitt applikasjon. Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <org> "organisasjonsnummeret" eller kommunenummeret for organisasjonen, f.eks for Alstahaug eller 9900 for Kommuneforlaget. <app> ID'en til applikasjonen som organisasjonsstrukturen er definert for, f.esk. BS2 for Bedre Styring. <epost> Epost-adressen som idenfisierer brukeren. I tillegg må følgende header settes i requesten: accesskey=<nøkkel>, der <nøkkel> er et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. For eksempel: Webservicen vil gi svar i form av en JSON-streng som inneholder organisasjonsenhetene 149

150 brukeren har tilgang til, og hvilke tilganger det er snakk om. I dette tilfellet er permission 1 = read, 2 = write og 3 = owner. >& =<epost> S2& =kf-test@knowit.no [ { "orgunitid": "540f36d7-fbbf-48fb-848a-ec91bd8a9078", "permission": 1 } ] Brukere med tilganger til en organisasjonsenhet Brukeradm eksponerer en web service som gir informasjon om hvilke brukere som har tilgang til en organisasjonsenhet for en gitt applikasjon. Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <orgunit> ID til en organisasjonsenhet, f.eks. 540f36d7-fbbf-48fb-848a-ec91bd8a9078 <tilgang> Kan være en av tre gyldige verdier: write, read eller owner <app> ID'en til applikasjonen som organisasjonsstrukturen er definert for, f.esk. BS2 for Bedre Styring. I tillegg må følgende header settes i requesten: accesskey=<nøkkel>, der <nøkkel> er et stort random generert tall, som gir tilgang til tjenesten. Denne genereres og utleveres av KF. For eksempel: Webservicen vil gi svar i form av en JSON-streng som inneholder brukere med den angitte tilgangen, identifisert ved epostadresse. For eksempel: Organisasjonslogo Brukeradm eksponerer en web service som lar deg hente ut bildet en organisasjon har definert som sin logo Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <org> - "organisasjonsnummeret" eller kommunenummeret for organisasjonen, f.eks for Alstahaug eller 9900 for Kommuneforlaget. icationid=<app> 150

151 access/540f36d7-fbbf-48fb-8 48a-ec91bd8a9078/read?applicationId=BS2 [ "kf-test@knowit.no", "krilan@knowit.no" ] For eksempel: Respons vil være bildet som er lastet opp. Organisasjonsbanner Brukeradm eksponerer en web service som lar deg hente ut bildet en organisasjon har definert som sitt banner Tilkoblingsverdier skal overleveres fra KF: <server> - domene til server <contextpath> - path til brukeradm applikasjonen <org> - "organisasjonsnummeret" eller kommunenummeret for organisasjonen, f.eks for Alstahaug eller 9900 for Kommuneforlaget. For eksempel: Respons vil være bildet som er lastet opp. Endre egen bruker I dag lar noen applikasjoner brukere modifisere sin egen bruker-informasjon. Brukeradm støtter dette ved at en innlogget bruker kan gå til: For eksempel: Dersom man i tillegg setter parameteren "backlink" vil siden vise en tilbake lenke som enkelt kan føre brukeren tilbake til det opprinnelige systemet. Eksempel:

152 urrentuser/ r r?backlink=http: // Central Authentication Service SSO bruker Jasig CAS som autentiserings server, for web Single Sign-on. CAS igjen bruker AD som brukerdatabase, altså for å sjekke gyldighet av brukernavn og passord. KF SSO benytter versjon 2 av CAS protokollen. Følgende skisse beskriver oppsettet. "Autentiser med CAS protokoll" er rekke redirects med nettleser. For mer informasjon om protokollen, se CAS sine offisielle sider: - detaljert beskrivelse av protokoll - offisiell dokumentasjon CAS distribuerer en rekke klient biblioteker, blant annet for Java,.NET, Apache (som modul), og php. For mer informasjon sjekk CAS Clients Home ( Ved å benytte en av disse klientene, trenger man ikke å forstå alle detaljer av CAS protokollen, det håndteres av klient-bibliotekene. KF skal overlevere URL til CAS servere for test og prod. Eksempelvis vil dette kunne være URL'er som skal benyttes for login og logout vil i så fall være

153 4.5 Risikokoder og faktorer Sannsynlighet (S): Aktuell bedømmelse av sannsynligheten for at hendelsen inntreffer dersom planlagte tiltak ikke gjennomføres Konsekvenser (K): Bedømmelse av konsekvensene om hendelsen inntreffer Kode (S) Sannsynlighet Kode (K) Konsekvenser 5 - Svært høy sannsynlighet Sikker hendelse (mer enn 90 % sannsynlighet) 5 - Høy negativ konsekvens Hele prosjektet er i fare, målene oppnås ikke 4 - Høy sannsynlighet Høy sannsynlighet (60 90 %) 4 - Hele prosjektets planer må gjøres om, usikkert om målene nås 3 - Middels sannsynlighet Middels sannsynlighet (30 60 %) 3 - Middels negativ konsekvens Hele prosjektets planer påvirkes, men totalrammen for prosjektet kan holdes 2 - Lav sannsynlighet Lav sannsynlighet (10 30 %) 2 - Delplaner for prosjektet påvirkes, men totalrammen holdes 1 - Usannsynlig Usannsynlig (mindre enn 10 %) 1 - Lav negativ konsekvens Begrenset innvirkning, kan innhentes Aktuelle risikofaktorer Risikofaktorer, alle Nr. Beskrivelse S K Tiltak Ansvarlig 01 Kort gjennomføringstid Ettersom varigheten av prosjektet er svært begrenset er vi avhengige av uforutsette faktorer og utfordringer kan bli løst så raskt som mulig. Tilgjengeligheten gjør også at det ikke er mulig å forlenge varigheten av prosjektet på nåværende tidspunkt. 4 4 Ta tak i uforutsette hendelser og utfordringer så raskt som mulig for å sikre kort oppklaring Revidere prosjektplanene jevnlig i forhold til brukt tid, tilgjengelig tid, osv. Kunde, leverandør 153

154 Nr. Beskrivelse S K Tiltak Ansvarlig Uforutsette hendelser kan få større konsekvenser ettersom det er begrensede muligheter til å utvide gjennomføringstiden. Det anbefales heller ikke å legge på flere ressurser ettersom det er avtalt en øvre kostnadsramme. Jobbe kontinuerlig med å prioritere funksjonalitet slik at man kan fokusere arbeidet på det som er viktigst for å få en tilfredsstillende løsning Kommunisere forventninger slik at disse er realistiske 02 Uforutsett behov for funksjonalitet Det åpnes for en viss grad av fleksibilitet i forhold til funksjonalitet. Etter hvert som løsningen manifisterer seg vil man kunne vurdere om hvorvidt funksjonaliteten som er tegnet opp er tilstrekkelig i forhold til kvaliteten på løsningen, dette må imidlertid samholdes med prosjektets korte gjennomføringstid og vurderes i forhold til ønsket funkjsonalitet osv. 3 4 Koordinering og informasjonsflyt mellom leverandør og kundens fagperson(er) Det er Netcompany sin oppgave å kontinuerlig rapportere om fremdrift og status. Det må avklares med kunden hva som inngår i en endelig leveranse Det er utarbeidet en beskrivelse av funksjonalitet som skal fungere som rettesnor for prosjektet Leverandør, kunde 03 Tilgang til ressurspersoner For å sikre at løsningen som utvikles får tilfredsstillende funksjonalitet og kvalitet betinges det god deltakelse fra fagpersoner innen systemområdet. Mangelfull tilgang til ressurspersonell, manglende eller forsinkede avklaringer i forbindelse med 3 4 Avsette faktisk tid for ressurspersonell Det er utarbeidet en belegningsplan som gir oversikt over tilgjengelighet gjennom prosjektet Kunde 154

155 Nr. Beskrivelse S K Tiltak Ansvarlig spesifikasjons- utviklingsarbeid, vil kunne forsinke fremdriften i prosjektet. 04 Ekstra runder med brukertesting Dersom det viser seg at brukerinnsikten som er innsamlet ikke er tilstrekkelig for å forutsi ønsket funksjonalitet, må det vurderes om man ønsker ytterligere bruekrtesting. Dette kan påvirke både budsjett og tid til prosjektgjennomføringen 05 Opphold i prosjektprosessen knyttet til teknisk miljø (testmiljøer, servere, infrastruktur, mm.) Det er ikke fastsatt hvilke miljøer som er tilgjengelig. Av den grunn kan det dukke opp utfordringer knyttet til det tekniske miljø 06 Omfang og kompleksitet i utvikling av løsningen er mer krevende enn planlagt Utviklingen av de planlagte leveransene er mer komplekse enn antatt/forutsatt, og det kreves mer tid pr brukerhistorie enn forutsatt. Prosjektet greier ikke levere planlagte brukerhistorier til avtalt tid. Risiko for at prosjektet forsinkes. 07 Uenighet om leveransen Ved overlevering av løsningen kan det oppstå uenighet om hva leveransen skulle inneholde. Ulike forventninger til hva en 2 3 Det skal gjennomføres en rekke brukerintervju og brukertester som vil fungere som en rettesnor for om ønsket funksjonalitet er implementert i løsningen 2 3 Kunden er oppdatert på den tekniske plattformen Det må avklares hvilket miljø den endelige løsningen skal kjøres i 2 4 Estimere tidsbruk per brukerhistorie Sprint Review for å undersøke hvordan estimatene har truffet Vurdere fortløpende hva som er gjort i forhold til hvor mye som gjenstår 1 4 Det opprettes dokumentasjon som illustrerer hva som er gjort og hva som gjenstår. Kunde, leverandør Leverandør, kunde Leverandør, kunde Leverandør, kunde 155

156 Nr. Beskrivelse S K Tiltak Ansvarlig brukerhistorie skal innebære samt hvilke bruekrhistorier som skal prioriteres i backlogen kan medføre uenighet mellom kunde og leverandør Det er enighet mellom kunde og leverandør at man skal prioritere brukerhistorier i backlogen og utvikle det man rekker innenfor prosjektperioden. 08 Utviklingspersonell og utforutsett fravær Spesielt sykdom forbundet med korte tidsfrister kan påvirke prosjektgjennomføringen. Prosjektet er spesielt sårbart da det er et studentprosjekt og utviklingsarbeidet fordeles på 3 studenter. 3 4 Ved sykdom og uforutsett fravær for allokerte ressurser, skal Netcompany eksalere dette internt. Det vil bli undersøkt internt om det finnes ressurser som eventuelt kan avlaste prosjektet, samt andre løsninger Leverandør 09 Ny teknologi det benyttes ny teknologi for de fleste i utviklingsteamet. dette kan påvirke fremgangen i teamet. Det må beregnes noe tid til å lære seg og sette seg inn i ny teknologi 4 2 Utviklerne har fått kursing og opplæring av leverandør Det er avsatt nøkkelpersonell av leverandøren - tekniske ressurser bistår utviklingsteamet ved behov og er involvert i QA-arbeid I startfasen er det satt av ekstra ressurser til opplæring Leverandør Positive risikofaktorer 156

157 Nr. Beskrivelse S K Tiltak Ansvarlig 01 Videreutvikling av løsningen Løsningen har mye potensiale som et godt verktøy for lærere. Dette trenger ikke begrense seg til mattelærere, det ligger et potensiale i løsningen som sannsynligvis kan overføres til andre fagområder, eksempelvis norsk, engelsk, historie osv. Både leverandør og kunde ser også stort potensiale ved å kunne videreutvikle løsningen i forhold til ny teknologi, fortrinnsmessig maskinlæring og VR. 02 Synergi effekter En god løsning vil inneha god teknisk kvalitet og brukeropplevelse. Av den grunn er det å foretrekke at kompetanse fra kunde og leverandør blir utnyttet best mulig. 03 Brukerinnsikt Gjennom brukertesting og brukerinvolvering kan det identifiseres ytterligere ønsker og behov for lærere som det kan være aktuelt å adressere. Enten implementere i denne løsningen, eller bli en del av videreutvikling. 4 4 Potensialet som ligger i løsningen må vurderes av leverandør. Løsningen vil kunne være et utgangspunkt for nye forretningsområder for kunde, dette må av leverandør vurderes hvordan man ønsker å gå videre med dette. Ved overlevering av løsningen vil man kunne vurdere det videre potensialet for hvordan man kan videreutvikle løsningen. 4 3 Det burde ses på muligheten for samarbeid mellom Netcompanys UX ressurser og nøkkelpersonell hos kunden 4 4 Innsikten som innhentes gjennom brukerintervju og brukertesting bør til enhver tid vurderes og ta til etterretning i forhold til hvordan man ønsker at løsningen skal være, men også i forhold til aktuelle andre mulige løsninger som kan utvikles av Kommuneforlaget Kunde Kunde, leverandør Kunde, leverandør 157

158 4.6 Installasjonsguide Git Maven Java 8 eller høyere Node med NPM PostgreSQL Git Last ned koden Åpne terminalvindu Naviger til mappeområdet du vil kodebasen skal ligge. # Laster ned kodebasen Denne linken er fjernet fra rapporten av sikkerhetsmessige årsaker IDE For dette prosjektet har Intellij fra JetBrains blitt brukt til utvikling. Intellij anbefales på det sterkeste med bakgrunn av at dette er en kraftig editor med støtte for utallige språk, syntaxhjelp, versjonskontroll og plugins. Dette medfører at man ikke trenger to editorer for dette prosjektet. Det ligger en fil i rota i ematte-backend som heter pom.xml. Denne kan bli benyttet til å åpne backend som prosjekt i Intellij. Backend: PostgreSQL Installer PostgreSQL Kjør følgende kommando når Postgres er installer: psql -U postgres CREATE USER ematte WITH PASSWORD 'password'; CREATE DATABASE ematte OWNER ematte; Databasen er nå opprettet og klar for kjøring i utvklingsmiljø. Java Backenden har blitt utviklet med programmeringsspråket Java. For å bygge og kjøre prosjektets backend, må maskinen ha minimum versjon 8 av Java Development Kit. Windows: Instruksjoner for å legge til Java som miljøvariabel kan du finne under Sommerprosjektet 2017 på denne confluencen. 158

159 Maven Maven er et byggverktøy. Maven kompilerer, pakker sammen kode og gjør prosjektet klart for kjøring. I dette prosjektet er det kun backend som har tatt i bruk maven. Etter å ha lastet ned kodebasen som anvist over, kjør følgende kommandoer: # Naviger til backend root. cd ematte/ematte-backend # Fjerner, kompilerer og bygger kodebasen med tester mvn clean install # Bygg koden uten test mvn clean install -DskipTests Kjør server: mvn spring-boot:run, or mvn package && java -jar target/ematte-*.jar, or Run EmatteApplication from your IDE. Frontend: Naviger til ematte-frontend og kjør fra terminalen: npm install npm start Din favorittnettleser vil åpnes med URL Eksempelfil Det ligger ingen typer eller temaer i databasen ved opprettelse og kjøring av prosjektet. Det må det for å opprette oppgaver. Det er lagt ved to eksempelfiler i kodebasen, en for typer og en for temaer. ematte/ematte-backend/src/main/resources/inserts/ For å legge til kan enten scriptene over editeres og kjøres i databasen, eller kjøre manuelt som beskrevet under: Tema Det ligger ingen temaer i databasen ved opprettelse og kjøring av prosjektet. Dette må bli populert manuelt i databasen for at man skal kunne opprette oppgaver i frontend. Under er et eksempel hvor teamet "Tall" blir lagt til. INSERT INTO topic ( topic_id, topic ) VALUES ( 1, 'Tall' 159

160 ); Type Samme gjelder for type som tema. Dette må bli lagt til for at løsningen skal virke: INSERT INTO type ( type_id, type ) VALUES ( 1, 'Problemløsing' ); 160

161 4.7 Time-tracking-report fra JIRA 161

162 4.8 Brukertester Testpersoner Dato Tid Testpersoner Skole og klassetrinn Fredag 19. januar 13:00-14:30 Tone 1. trinn / PPT alle trinn på barneskolen Mandag 22. januar 11:00-12:00 (Skype) Lise Marie Sitter Bersmo Ole Vig videregående skole Tirsdag 23. januar 12:45-13:45 Kine Lambertseter skole Viktigste funn - oppsummering 162