Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT PROSJEKT NR. TILGJENGELIGHET Offentlig Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Bachelor Manager DATO 23/05-17 ANTALL SIDER / BILAG 130/115 PROSJEKTDELTAKERE: Adrian Siim Melsom (s236308) INTERN VEILEDER Torunn Gjester Duy Johnny Khac Nguyen (s929591) Håkon Thorkildsen Smørvik (s929559) Kim Long Vu (s236322) OPPDRAGSGIVER Accenture KONTAKTPERSON Fredrik Bjørnøy SAMMENDRAG Bachelorprosjektet er skrevet ved HiOA i samarbeid med Accenture. BachelorManager er en single page application for administrering av bachelorgruppene Accenture tar inn hvert år. Gjennom prosjekttiden har gruppen implementert scrum-metodikken i utviklingsprosessen. Noe som har ført til godt dokumentert arbeid og god dokumentasjon av applikasjonen. I tillegg er det brukt mange timer på å sette seg inn i nye teknologier som ikke ellers er del av høgskolens pensum. 3 STIKKORD Enterprise Resource Planning REST-API Single Page Application

2 FORORD Rapporten er delt inn i en hovedrapport, en produktdokumentasjon og vedlegg. Hovedrapporten gir et godt overblikk over målene med oppgaven, hva slags teknologi som er brukt, arbeidsmetode, utviklingsmiljø, og avsluttes deretter med en presentasjon av sluttproduktet. Produktdokumentasjonen er en detaljert gjennomgang av koden og funksjonaliteter i produktet. Denne rapporten blir godt støttet av skjermbilder og kodeeksempler. Grundig dokumentasjon som underbygger vår implementasjon av scrum-prosessen ligger som vedlegg. I tillegg blir verktøy og rammeverk forklart i mer detalj i vedlegget. I tillegg vil vi takke produkteiere Fredrik Bjørnøy, Christian Møller Andersen, Marius Torsrud som har kommet med innspill og ønsker. I tillegg har Marius spilt en rolle i organisering av kurs. I tillegg vil vi takke veilederne fra Accenture, Joakim Kartveit og Jostein Guldal. Disse har bidratt med faglig veiledning, kontaktnettverk, og god kritikk, blant mye mer. Til slutt vil vi takke Torunn Gjester for sitt store bidrag under rapportskrivingen. 1

3 BACHELOR MANAGER Adrian Siim Melsom, Duy Johnny Khac Nguyen, Håkon Smørvik, Kim Long Vu 2

4 1 Contents 2 Innledning Bachelor Manager Oppdragstakere Oppdragsgiver Bakgrunn Mål Kravspesifikasjon Arkitektur Teknologi Innledning Teknologier i miljøet Front-end Back-end Både front- og back-end Arbeidsmetode Innledning Planleggingsfase Utviklingsfase Dokumentasjon Miljø Innledning Utviklingsmiljø Versjonskontroll Testmiljø Utrullingsmiljø Produktpresentasjon Innledning Aksess

5 6.3 Felles elementer Tags Filsystem Mail Diskontinuerte elementer Konklusjon Produktdokumentasjon Forord Innholdsfortegnelse Innledning Beskrivelse av produktet Samsvar mellom kravspesifikasjon og produkt Tagsystemet Mailsystemet Struktur Vedlegg Teknologier Elementer Designmodeller Arbeidsmetodikk Sprinter Sprint dokumentasjon Testing Prototype Brukergrensesnitt v Prototype Brukergrensesnitt v Brukerhistorier - Planlegging Brukerhistorier - Endelig Risikovurdering Komponentstruktur

6 9.14 Modalstruktur Delte komponenter Kilder

7 2 Innledning 2.1 Bachelor Manager Bachelor Manager er en applikasjon for håndtering og administrering av bachelorgrupper internt i Accenture. Applikasjonen skal gjøre det lettere for Accenture å opprette studentgrupper og linke disse sammen med en problemstilling og et utvalg veiledere. I tillegg skal applikasjonen gi muligheten til å opprette nye brukere, problemstillinger, samt tilby en plattform for å lagre relevant dokumentasjon for hver gruppe. 2.2 Oppdragstakere Adrian Siim Melsom, s236308@stud.hioa.no Duy Johnny Khac Nguyen, s929591@stud.hioa.no Håkon Thorkildsen Smørvik, s929559@stud.hioa.no Kim Long Vu, s236322@stud.hioa.no 2.3 Oppdragsgiver Accenture er en ledende global organisasjon som leverer et bredt spekter av tjenester og løsninger innen strategi, rådgivning, digital, teknologi og outsourcing. Med sin omfattende bransjeekspertise, sine globale ressurser og sin erfaring innen konsulentvirksomhet og outsourcing kan de mobilisere de riktige menneskene og den nødvendige kompetansen for å hjelpe sine kunder til å bli virksomheter med høy prestasjonsevne. Accenture har mer enn ansatte og leverer tjenester til kunder i mer enn 200 land. De har bransjeekspertise innenfor de fleste nisjer i markedet. Det er et tett samarbeid mellom de lokale selskapene og de øvrige enhetene i Accentures globale organisasjon. (Accenture, 2017). Accenture tilbyr en rekke kurs for sine ansatte. Som studentgruppe hos dem er det forventet at vi deltar på kurs i blant annet scrum og presentasjonsteknikk. 6

8 2.4 Bakgrunn Accenture tar årlig inn 3-5 bachelorgrupper fra utdanningsinstitusjoner, hovedsakelig fra Oslo og omegn. For å håndtere det administrative rundt disse gruppene, bruker de verktøyet SharePoint. Dette verktøyet brukes for å registrere studenter, linke dem sammen som en gruppe, tilordne dem problemstillinger og veiledere, og laste opp filer relatert til hver enkelt gruppe/student. Møter med produkteiere viser at dette ikke er et egnet verktøy for slike oppgaver. En av de store utfordringene ved dagens løsning er den tungvinte registreringsprosessen. Komponentene som brukes for å registrere, er separert på en måte som gjør at prosessen kan ta inntil 10 minutter per gruppe (Produkteier, 2017). Registreringsprosessen innebærer å registrere hver student individuelt, for deretter å koble disse studentene til en gruppe. Produkteier har heller ikke muligheten til å opprette årskull for grupper, noe som vanskeliggjør sortering. Oversikten over de registrerte oppgavene er heller ikke mulig å sette opp på en oversiktlig måte, som igjen gjør hele prosessen vanskelig. Ønsket fra produkteier er å gå helt vekk fra denne løsningen og heller gå over på en spesialisert plattform for administrasjon av gruppene og de relaterte dokumentene. Det var to design vi anså som potensielle løsninger i planleggingsfasen. Den første var en dashboardløsning, der brukeren selv kunne flytte rundt på oversikt, registreringsvinduer og liknende. Dette ville gi brukeren frihet til å bestemme arbeidsflyt helt selv, men kunne bli uoversiktlig med alle vinduene. Den andre var en statisk løsning, der kun en side er aktiv om gangen. Dette ville føre til en strengere arbeidsflyt, men var ikke i fare for å bli uoversiktlig på samme måte som dashboard-løsningen. 2.5 Mål Effektmål 1. Effektivisere registreringsprosessen rundt grupper og tilhørende studenter. 2. Sentralisere og effektivisere dokumenthåndtering. 3. Effektivisere tidsbruken til produkteierne. 4. Erstatte SharePoint. 5. Applikasjonen skal kunne skaleres for videre funksjonalitet Resultatmål Oppdragsgiver ønsker en webapplikasjon for administrering av bachelorgruppene de tar inn hvert år. Dette for å få en bedre flyt, spesielt i registreringsprosessen. Et resultatmål av dette vil være å implementere et registreringsskjema for grupper, der studenter og oppgaver kan registreres samtidig. Ved å implementere et filhåndteringssystem direkte i applikasjonen kan brukere laste opp og håndtere filene sine på en tidsbesparende måte. 7

9 Oppdragsgiver har også ønske om å erstatte dagens løsning. Målet med applikasjonen blir derfor å fullstendig erstatte SharePoint som plattform for administrering av grupper. Ved å utvikle et REST-API, tilrettelegger vi for skalering i alle deler av applikasjonen. For eksempel kan man utvikle en mobilapplikasjon som kommuniserer med samme data, eller åpne for at studenter og veileder har et forum i applikasjonen. Applikasjonen blir utviklet for å brukes på PC, men et mål er at brukergrensesnittet også skal tilpasses håndholdte enheter Læringsmål Ett av hovedmålene ved dette prosjektet var å lære oss flere nye rammeverk og teknologier som ikke har vært gjennomgått på høgskolen. Dette er et svært stort mål for oss ettersom vi vil vise vår evne til å tilegne oss ny kunnskap. Samtidig vil det gjøre oss bedre rustet for utfordringer i arbeidslivet. To av hovedmålene innenfor rammeverk og teknologier var å sette seg inn i Angular 2 og REST-API. Angular 2 er ett av de større rammeverkene for utvikling av webapplikasjoner. REST-API har etablert seg som en industristandard på hvordan web-servicer skal oppføre seg. Dermed har vi et ønske om å se mer på hvordan disse APIene lages. Vi har som mål å lage en applikasjon som følger arkitekturstandarder innenfor Enterpriseapplikasjoner, det vil si implementere de fem lagene: Presentasjonslag, Servicelag, Businesslogikklag, Dataaksesslag og Persistenslag. Vi har i tillegg som mål å utnytte det vi har lært om prosjektstyring, estimering og prosjektarbeid gjennom studieløpet. 2.6 Kravspesifikasjon Accentures team benytter scrum i sine prosjekter og det var derfor et ønske at vi implementerte dette i prosjektet. I prosjektet definerer vi kravspesifikasjonen som listen med brukerhistorier fra produkteierne. Roller: Administrator Veileder Bruker Figurene nedenfor er en forenklet oversikt over brukerhistorier for de forskjellige rollene. For en helhetlig oversikt over brukerhistoriene, se punkt 9.10 Brukerhistorier - Planlegging og 9.11 Brukerhistorier - Endelig. 8

10 Figur 1. viser hva en administrator kan gjøre på applikasjonen Figur 2. viser hva en veileder kan gjøre på applikasjonen 9

11 Figur 3. viser hva en bruker kan gjøre på applikasjonen 2.7 Arkitektur Figur 4. Overordnet oversikt over systemets arkitektur. Dette blir videre forklart i 8.8 Struktur. 10

12 3 Teknologi 3.1 Innledning Gruppen hadde som et personlig mål å lage en webapplikasjon som opprettholdt moderne bransjestandarder, hvilket innebar tilnærming av nye teknologier. Valg av verktøy og rammeverk ble gjort basert på hva som anvendes i bedriftsløsninger. Det ble derfor dedikert mange timer til undersøkelsesprosessen. For en mer detaljert beskrivelse og bruk av teknologiene se punkt 9.1 Teknologier. I de følgende underkapitlene viser vi til tabeller med en oversikt over alle teknologiene anvendt i prosjektet. Teknologiene er delt inn i teknologi i miljø, front-end, back-end, og de som brukes i både front- og back-end. 3.2 Teknologier i miljøet Navn Bruk Beskrivelse Brukt i fase IntelliJ Skrive kode for APIet Utviklingsmiljø som er Alle. og Front-end. en smart editor for kode. WebStorm Skrive kode for front- Utviklingsmiljø som er Alle. end. en smart editor for kode. Docker Utrulling av Konteinerplattform som Alle. applikasjonen. sikrer likt kjøringsmiljø i ulike systemer. Slack Intern kommunikasjon i gruppen. Kommunikasjonsverktøy. Alle. Jenkins Bygging av Verktøy for Begynnelsen av programmet. automatisering av ikke- utvikling. humane oppgaver. Trello Oppslagstavle for Verktøy som Planlegging og test. oppgaver som må representerer en gjøres. oppslagstavle. Node.js Applikasjonsmiljø for Kryssplattform-runtime- Utvikling, test og Angular 2. system for applikasjoner. utrulling. 11

13 Payara Applikasjonsmiljø for Applikasjonsserver for Utvikling, test og JavaEE. applikasjoner skrever i utrulling. JavaEE. AWS Skytjenesten En rekke tjenester tilbudt Utvikling, test og applikasjonen kjører av Amazon. utrulling på i sin helhet. 3.3 Front-end Navn Bruk Beskrivelse Brukt i fase Marvel Lage visuelle prototyper Prototypeverktøy. Planlegging. for applikasjonen. Angular 2 Rammeverket brukt til å Rammeverk for å Utvikling, test og kode front-end i utvikle modulære utrulling. applikasjonen. webapplikasjoner. Karma/Jasmine Karma kjører tester Karma er et Utvikling og test. skrevet ved bruk av rammeverk for Jasmine. testing. Jasmine er et adferdsdrevet rammeverk for testing. Material Design Representere visuelle Bibliotek for Angular Deler av utvikling. deler av applikasjonen. 2 som tilbyr UI- Kuttet grunnet dårlig komponenter. plassbruk. Bootstrap Rammeverket brukt for Populært rammevært Utvikling, test og generelt design av for responsivt design. utrulling. applikasjonen. Angular2-grid Holde komponentene i Angular 2 bibliotek Deler av utvikling. paneler. som muliggjør Kuttet grunnet lar paneler-elementer brukervennlighet. som kan dras rundt på skjermen. 12

14 TinyMCE Skrive oppgaver Angular 2 bibliotek som gjør at man kan definere en egen tekst editor. Utvikling Chrome Developer Feilsøke Google sitt Utvikling og testing. Tools opptimaliseringsproblemer utviklerverktøy for og debuging deres nettleser 3.4 Back-end Navn Bruk Beskrivelse Brukt i fase Maven Bygge og teste APIet. Automasjonsverktøy for prosjektbygging. Utvikling, test og utrulling. JavaEE Kodespråket brukt til å Plattform for Utvikling, test og lage APIet programmering og utrulling. distribusjon av programvare. JAX-RS Rammeverk brukt til å Rammeverk for Utvikling, test og lage APIet. JavaEE brukt til å lage utrulling. REST-APIer. Hibernate Laget mellom Rammeverk for å Utvikling, test og logikken i APIet og abstrahere arbeidet utrulling. databasen. med databaser. 3.5 Både front- og back-end Navn Bruk Beskrivelse Brukt i fase HTTP Protokoll brukt til å Protokoll for Utvikling kommunisere mellom kommunikasjon over front- og back-end. verdensveven. JSON Formatet data sendes Dataformat Utvikling mellom front- og backend 13

15 GitHub Fillagring Kodebase med versjonskontroll Alle 4 Arbeidsmetode 4.1 Innledning Det er viktig for prosjekter å ha en solid grunnleggende plan. Dette trenger ikke være en presis instruksjonsmanual på hva som må gjøres, men en veiledende samling målbeskrivelser. Disse målbeskrivelsene skal gi gruppen en oversikt over prosjektet, og gjøre dens arbeidsoppgaver mer håndterbare. For å kunne tilfredsstille kravet om arbeidsmetodikk fra Accenture, og standarden på prosjektet gruppen hadde satt, var det viktig at planleggingsdokumentene var grundig skrevet. Dette resulterte derfor i en rekke dokumenter som skulle støtte Scrumutførelsen i prosjektet, samt være tilstrekkelig dokumentasjon for overføring av prosjektet. Utviklingsfasen er den mest krevende fasen i prosjektet, og er utsatt for potensielle avvik i forhold til ønsket sluttprodukt. Her er kommunikasjonen ekstra viktig, endringer og nye funksjoner vil alltid dukke opp. Ved å bruke Scrummetodikken minskes denne faren, fordi metodikken har fleksibilitet som fokus. Dette oppnås gjennom mye kommunikasjon mellom produkteier og gruppen. Gjennom den iterasjonsbaserte metodikken tilbyr scrum muligheten til skifte av fokus i prosjektet. I dette kapittelet skal vi ta for oss temaer rundt planlegging, prosjektets produkteiere og veiledere, arbeidsprosess og resultatet av planlegging. 4.2 Planleggingsfase Planlegging Kravspesifikasjon skal beskrive det produkteier ønsker av prosjektet. I dette prosjektet var brukerhistorie tilstrekkelig som beskrivelse, men ikke alle brukerhistoriene var klare ved prosjektstart. Det ble dermed valgt å fokusere på å sette opp et utviklingsmiljø fremfor å planlegge selve produktet. Kanban ble benyttet i planleggingsfasen som en følge av fokuset på utviklingsmiljøet. Det var hovedsakelig «Kanban Board» som ble implementert fra Kanban. Dette ga struktur og oversikt over hva som måtte gjøres gjennom å sette opp oppgaver som kort på tavlen. En del av planleggingen var å definere et miljø for utvikling, samt deler av programvarestacken. En programvarestack er en samling av teknologi som omfatter løsningen. Miljøer i utviklingssammenheng er verktøy og programmer som blir brukt i utvikling, testing og produksjon. 14

16 Valg av programvarestack og miljø er basert på en kombinasjon av produktbeskrivelse, anbefalinger fra produkteier, egne erfaringer, og et ønske om å prøve ny teknologi. Accentures Fornebu-kontorer har streng sikkerhetspolitikk på nettverket. Dette begrenset muligheter for hva som kunne benyttes av nettverksavhengige teknologier, spesielt med tanke på Jenkins og Docker, da disse krever tilgang til flere porter på nettverket. Som et resultat av sikkerhetspolitikken, ble det brukt tid på å undersøke måter å få til Jenkins og Docker Prosjektstart Kommunikasjon med produkteierne skjedde hovedsakelig over mail, ettersom gruppen satt på et annet kontor. Om lag en uke etter prosjektets start var de første brukerhistoriene mottatt fra produkteierne. Det ble holdt et møte kort tid etter, og i den forbindelse ble det laget en agenda for møtet. Denne agendaen ble laget for å kunne holde møtet kortfattet og presist, da vi var avhengig av god dialog rundt problemstillingen. Målet med møtet var følgende punkter: Kartlegge prosessene av arbeidsmål i nåværende system Definere omfanget av applikasjonen gruppen skulle lage. o Se hvor i prosessen applikasjonen skulle komme inn. o Var applikasjonen brukt fra start? o Skulle den ta hånd om søknadsprosessen? o Skulle applikasjonen fungere som et kommunikasjonsverktøy for bachelorstudenter og veileder? Definere en prioriteringsliste for brukerhistoriene. Møtet ble planlagt å vare en time. Denne timen ble delt i to bolker der vi de første 30 minuttene gikk gjennom dagens løsning, de relevante prosessene og problematikken rundt disse. Den andre halvdelen av møtet ble brukt på å gjennomgå en del spørsmål rundt applikasjonen og brukerhistoriene. I tillegg til møtet med produkteierne ble det avtalt et Figur 5. Møteagenda møte med et sett med veiledere fra Accenture. Veiledernes rolle gikk ut på å gi tilbakemeldinger, kritikk og tips i forhold til prosjektarbeid og teknologi Arbeidsprosess Dagene i planleggingsfasen startet med et morgenmøte der dagens plan ble diskutert. Oppgaver ble notert ned på en Kanban-tavle etter hvert som de oppstod under møtet. Nye oppgaver blir lagt inn på «New Tasks» eller «Important». «Stand By» ble oppgavene plassert i hvis det var en avhengighet som 15

17 hindret videre progresjon for oppgaven. Oppgaver under arbeid ble plassert i «In Progress», og ferdig oppgaver i «Done». Figur 6. Trello Kanban-tavle Denne måten å arbeide på ga struktur til prosjektets start. Gruppemedlemmer kunne se på tavlen hvis de ikke hadde noen arbeidsoppgaver, og samtidig får et overblikk over prosjektets framgang. Dette førte til en god arbeidsflyt, og økt effektiviteten i start- og avslutningsfasen. For mer grunnleggende om Kanban se punkt Kanban Resultat av planlegging Planleggingsfasen resulterte i et sett av dokumenter for å støtte utviklingsfasen. Det viktigste dokumentet for Scrum-prosessen er burndown-dokumentet. Selve dokumentene ligger i punkt 9.6 Sprint dokumentasjon. Risikovurdering Applikasjons Arkitektur Brukerhistorie Gir gruppen oversikt og bevisstgjør relevante risikofaktorer i prosjektet. Tvinger gruppen til å lage preventive tiltak for å redusere sannsynligheten for feil. Gir en teknisk oversikt over hele prosjektet, med dets moduler og hvordan de er koblet sammen. Listen med alle brukerhistoriene gir en oversikt over hvilke funksjoner applikasjonen må ha, og fungerer som en kravspesifikasjon. Gantt Skjema Burndown Oversikt over hvilke tidsfrister gruppen må jobbe mot. Hvilke funksjoner som må bli ferdig, i tillegg kan gruppen se om prosjektet henger etter eller ikke. Inneholder sprinter med planlagte arbeidsoppgaver, delegert tid på hver oppgave, forventet tidsbruk og burndown av prosjektet 16

18 4.3 Utviklingsfase Scrum Scrum brukes i applikasjonens utvikling. Gruppens størrelse og prosjektets behov avgjorde hvilke aspekter ved scrum som ble implementert. Vanligvis er det en «Scrum Master» som tar seg av kommunikasjon med produkteier for å skjerme utviklergruppen slik at de kan fokusere på utvikling. En gruppe på fire medlemmer vil ikke være like avhengig av en scrum master for å ta seg av intern og ekstern kommunikasjon. Gruppen har et felles ansvar for å opprettholde scrum-metodikken og følge dens prinsipper. For å støtte scrum-implementasjonen brukes det flere dokumenter, blant annet sprintog produkt-backlog. Det samarbeides om scrum-dokumentene, men gruppen har en valgt «sekretær». Sekretærens rolle er å skrive referat fra hvert møte, skrive intern-review og innkalle veiledere og produkteiere til møtene. Se punkt Scrum for forklaring av metodikken Sprint Hver dag skjer en daily stand-up slik at hele gruppen blir orientert om den kommende arbeidsdagen, og sprintens foreløpige situasjon. Møtet finner oftest sted mellom 09:15 og 10:30. For gruppens behov er det ikke alltid nødvendig med disse møtene. Ved rapportskriving for eksempel er det ikke like viktig med møte før arbeid kan begynne. Problemer som oppstår er heller ikke viktig å ta opp formelt i møtet, ettersom det er konstant kommunikasjon innad i gruppen. Generelt: Delt i to-ukers perioder med implementasjon (sprinter). Dagene varer fra 09:00 til 17:00. Beregnet syv timer med effektiv koding/dokumentering per person per dag. Lørdag og søndag brukt som fleksible dager, men inkludert i sprintplanen. Brukes dersom det skulle være behov for ekstra arbeid. Mot slutten av dagen skal det føres timer og loggføre i den personlige dagboken. Sprinter består av fire faser: Figur 7. Sprint-prosess 17

19 4.3.3 Sprintplanlegging Sprinten må planlegges før den kan starte. Planleggingen utføres i plenum, der det diskuteres hvilke brukerhistorier som bør utføres i kommende sprint. Hvilke brukerhistorier som blir valgt er basert på produkteiernes ønsker og hva som trengs i applikasjonen. Etter at brukerhistoriene er valgt, deles brukerhistorien i mindre oppgaver som er mer konkrete og håndterbare. Når oppgavene er satt og tildelt, estimeres tid på hver oppgave. Figur 8. Eksempel på en oppgave i et Sprint-Dokument Under planleggingen blir det gjort en helhetlig revurdering av risikovurderingen. Nye risikoer vil dukke opp og gamle falle vekk underveis i prosjektet, det er da viktig at dokumentet reflekterer dette. Mer om risikovurdering kan leses i punkt Risikovurdering. Hver arbeidstime logges daglig i sprint-dokumentet. Dokumentet generer så en «burndown chart», som viser hvordan prosjektet ligger an i forhold til det som er planlagt. Se punkt i 9.6 Sprintdokumentasjon for «burndown chart»-dokumentene. Figuren nedenfor viser en burndown med to forskjellige grafer der den blå viser planlagt arbeid og den oransje utført arbeid. I tillegg er det grå søyler som viser fullførte arbeidsoppgaver fra dag til dag Daily Completed Planned Actual Figur 9. Burndown for sprint 4 hentet fra Burndown excel fil Daily stand-up Agendaen for «daily stand-up» består av tre hoveddeler: Hva ble gjort i går? 18

20 Hvert gruppemedlem forteller hva som ble gjort dagen før. Dette er for å oppdatere resten av gruppen, slik at alle har en oversikt over sprintens framgang. Hva skal gjøres i dag? Gruppemedlemmer vet som oftest hva som må gjøres for dagen, men dette kan endres etter gruppens behov. Utfordringer? Som tidligere nevnt er det konstant kommunikasjon og samarbeid innad i gruppen. Det er derfor ikke mye behov for å ta opp tekniske utfordringer formelt i møtene. Denne delen av møtet har også blitt brukt til å ta opp design spørsmål, og andre utfordringer som ikke er knyttet til utvikling Intern Review Mot slutten av en sprint utføres en internvurdering. Det gjøres da en helhetlig vurdering av utførelsen. Ved å se på «burndown chart»-dokumentet, kan det ses om gruppen har estimert riktig basert på estimert og brukt tid. Dette kan brukes til å forbedre tidstilnærmingen for neste sprint. Hovedmålet med internvurderingen er å gjøre klar en agenda for hovedvurderingen. Implementerte funksjoner, moduler og kode blir da dokumentert, slik at det kan presenteres for veiledere og produkteiere. Interne problemer blir også tatt opp. Det kan være alt fra kommunikasjonsproblemer til Scrum-utførelse. Siste delen av internvurderingen blir brukt på å gå gjennom hvordan gruppen følte utførelsen gikk. Spesifikt, hva gikk bra? Hva gikk dårlig? Og hva kan gjøres annerledes Review Hovedvurderingen skjer med gruppen, veiledere og produkteiere. Alle er invitert til å møte opp fysisk i et lokale, eller via Skype. I møtet gjennomgås agendaen lagd fra internvurderingen. Det presenteres implementerte funksjoner med en live-demo, om det er mulig. Rollen til veiledere og produkteiere er å gi tilbakemelding på dette. Produkteiere har muligheten til å komme med innspill om hva de ønsker skal bli implementert eller fjernet til neste sprint Testing «Debug & Issues» For intern brukertesting brukes Kanban-tavle til å rapportere ulike bugs og problemer med løsningen. Blir det oppdaget en nødvendig endring, settes den opp som en oppgave på tavlen i riktig kolonne etter dens status. Dette gir oversikt til gruppen over hvilke oppgaver som må gjøres fortløpende, og gir en historikk over problemer og bugs. 19

21 Figur 10. Kanban-tavle for intern brukertesting Brukertesting Underveis i utviklingen hadde gruppen en større brukertest for å kunne kartlegge sluttbrukers opplevelse av produktet. Brukertester er kritisk å utføre for å finne ut om det gruppen produserer virkelig er det kunden ønsker. Resultatene fra brukertesten viste at applikasjonen ikke var brukervennlig i sin daværende tilstand. Denne brukertesten ble gjort midtveis i utviklingsprosessen, noe som satte gruppen under press siden det burde vært testet før. Grunnen til at testene ikke ble gjennomført tidligere var fordi gruppen hadde en bred tilnærming til kodingen. Med bred tilnærming menes det at vi utviklet mye funksjonalitet samtidig, slik at ikke en del ble ferdig av gangen. En mer direkte tilnærming hadde resultert i flere brukertester, da man ferdigstiller individuelle moduler før en ny blir påbegynt. For å se mer om denne brukertesten se punkt Brukertesting Enhetstesting Da utviklingen startet ble det tidlig bestemt at det skulle tas i bruk testdreven utvikling. Dette hadde ingen av gruppemedlemmene tatt i bruk, så det var ønskelig å utforske. Til tross for at det ble opprettholdt i flere sprinter etter at prosjektet startet, ble det bestemt at det tok for mye tid fra den faktiske utviklingen i prosjektet. Erfaringen var at alle ble mer bevisste på forandringer i koden, noe som førte til mer solid kode. Hadde tiden strukket til, ville testkoden blitt opprettholdt og brukt i stor grad. I back-end var det på høydepunktet om lag 200 aktive tester som ble kjørt hver gang prosjektet ble bygd. For testene ble det brukt Mockito for å simulere klasser og metoder som ikke skulle testes. Mockito er forklart i punkt Mockito. I front-end bruker vi Karma og Jasmine til enhetstesting. Større deler av en sprint ble brukt på å undersøke hvordan testing i Angular 2 ble utført. Senere i utviklingen fant vi en god løsning på det. Det ble lagd totalt 50 antall tester før de ble nedprioritert. Mer om Karma og Jasmine se punkt Karma/Jasmine. 20

22 4.4 Dokumentasjon Risikovurdering Risikovurderingen er en vurdering av risikoer som kan oppstå under prosjektet. Dette kan være alt fra å bli syk til feilestimering av tid. Risikoene tilordnes en grad av sannsynlighet og konsekvens fra en til fem. Dette multipliseres for å få en risikofaktor. # Risiko Beskrivelse Årsak Sansynelighet Konsekvens Risikofaktor Tiltak Eier Status 1 Feilestimering av tid Estimere for mye eller for lite tid for prosjektet Eksempel: undervurdere hvor vanskelig det er å implementere en løsning Revurdere tidsbruk underveis? Forekommet og håndtert Figur 11. Risiko nummer 1, hentet fra dokument risikovurderingv5.xlsx. Figur 10 viser hvordan vi vurderer risikoer. Her føres beskrivelse, årsak, sannsynlighet, konsekvens, risikofaktor, tiltak, eier, og status. Tiltak er den viktigste kolonnen i vurderingen da denne inneholder preventive handlinger. Denne vurderingen er nødvendig for at prosjektet ikke skal møte uventede utfordringer. Om gruppen ikke tar hensyn til en risiko og den forekommer, kan dette gi store konsekvenser for prosjektet. Derfor utføres en revurdering ved hver sprint Gantt-skjema Skjemaet illustrerer prosjektets forventede tidsplan og gir en oversikt over planlagt tidsbruk under hele prosjektet. Hver sprint har arbeidsoppgaver som strekker seg over en gitt periode. Oppgavene kan strekke seg over flere sprinter. Selv om vi prøvde å følge denne planen så presist så mulig, ble den reelle tidsbruken mye annerledes enn det som var forventet. Dette skyldes lite prosjekterfaring og dårlige estimeringer. Mange av arbeidsoppgavene i Gantt-skjemaet reflekterer ikke den faktiske tidsbruken. 21

23 Sprint 1 Registere oppgave Sprint 2 Registrere på database Registrere bruker Google Docs api Endre grupper Sprint 4 Søking Logg inn Sprint 6 Sprint 7 Mail funksjon Sprint 8 Dokumentering Figur 12. Gantt-skjema Scrum For å ha kontroll over scrummetodikken, kreves det mye dokumentasjon og opprettholdelse av disse. Filene som brukes for å oppnå dette, deles på OneDrive. Se vedlegget 9.6 for sprint-dokumentene. Planleggingen foregår i et Excel-dokument som alle i gruppen har tilgang til. Dokumentet brukes under sprintplanleggingen der gruppen går gjennom en produkt-backlog og vurderer hvilke brukerhistorier som har høyest prioritet for kommende sprint. Videre blir det estimert tidsbruk på de forskjellige arbeidsoppgavene som baseres på brukerhistoriene. Alt dette fylles inn i et Exceldokument med oversikt over hvor mange timer brukt på hver oppgave. Figur 13. Sprintplanlegging Dokumentet inneholder et «burndown chart» som viser hvor mange timer arbeid det gjenstår i forhold til det estimerte antall timer. Grafen brukes til å se om vi har oppnådd arbeidsmålet i en gitt sprint, i 22

24 tillegg fungerer den som en oversikt for å se hvilke dager som mangler arbeid. Denne informasjonen kan videre brukes for å forbedre estimeringen. Figur 14. «Burndown chart» «Daily stand-up» blir dokumentert i et Word-dokument der punkter fra møtet noteres. Dette dokumentet blir brukt til å holde styr på hvilke arbeidsoppgaver som blir planlagt for dagen. I tillegg hjelper den hvert enkelt medlem med å få innsikt over hva resten av gruppen arbeider med. Se vedlegg Eksempel «daily stand-up». På slutten av en sprint lages en «sprint review» som i seg selv er et eget Word-dokument. Den inneholder en liten oppsummering av hele sprinten, samt nye implementasjoner i både back- og frontend. Nederst på dokumentet ligger en sprint retrospective som er tanker/refleksjoner rundt gruppen og dens arbeidsprosesser Dagbøker Dagbøkene skal inneholde alt som har skjedd på de ulike arbeidsdagene i prosjektet. Det finnes to typer dagbøker som benyttes: Hoveddagbok og en personlig dagbok. Hoveddagboken inneholder møtereferater fra «daily stand-up», og eventuelle møter med veiledere fra HiOA/Accenture og produkteiere. Denne dagboken ligger på skyen i One Drive, og kan aksesseres til enhver tid. Den personlige dagboken inneholder en logg fra hvert medlem i gruppen. Disse dagbøkene inneholder notater av research, implementasjoner gjort i prosjektet og problemer oppstått med eventuelle løsninger. 5 Miljø 5.1 Innledning IT-prosjekter krever ulike miljøer basert på hvilke oppgaver som skal gjennomføres. I dette kapitlet skal vi se på de ulike miljøene som var nødvendig for alle stadiene i prosjektet. Innledningsvis skal vi 23

25 ta for oss utviklingsmiljø, fulgt av hvordan vi har tatt i bruk versjonskontroll. Deretter følger testmiljø og avslutningsvis utrullingsmiljø. 5.2 Utviklingsmiljø Til utviklingen brukes editorene WebStorm og IntelliJ fra JetBrains. WebStorm er en editor for webutvikling. IntelliJ er en editor for en mer generell bruk. Denne brukes hovedsakelig til utviklingen av back-end, men blir også brukt til annet. Alle i gruppen har erfaring med disse produktene, og det vil derfor ikke brukes tid på å lære seg en ny editor. 5.3 Versjonskontroll I større IT-prosjekter er versjonskontroll et viktig aspekt for å kunne jobbe parallelt i team. Det skal være mulig å jobbe på samme fil eller del av prosjektet uten at arbeid blir tapt under synkroniseringsprosessen. Funksjoner eller moduler bør bli integrert uten at man bruker mye tid på manuell synkronisering av versjoner. Git er et versjonskontrollsystem som tilrettelegger for samarbeid mellom prosjektdeltagere. Git tilfredsstiller disse kravene som et VCS (Version Control System) for prosjektet. I tillegg er dokumentasjon lett tilgjengelig. 5.4 Testmiljø For å utføre tester på applikasjonen er det viktig at dette skjer i et kontrollert miljø. Det er viktig at tester som skjer i miljøet ikke påvirker faktiske data i det utrullede systemet. For å sette opp våre testmiljøer bruker vi Docker. Her anvendes et konsept kalt «container». Dette er et verktøy som gir oss muligheten til å sette opp et miljø i en form for beholder. For mer om Docker se punkt Docker. 5.5 Utrullingsmiljø Utrullingsmiljøet anvender «container» fra Docker. Gjennom images, blåkopier på predefinerte «container», kan man produsere en «container» med et miljø definert i blåkopien. Fordelen med dette er at man kan prøve ulike images på kort tid. Dette åpner også muligheten for at interessenter kan prøve ulike versjoner av applikasjonen underveis i utviklingen. Applikasjonen driftes på en server. Drift er et område gruppen har lite erfaringer med, ettersom dette er noe få skoleprosjekter krever. Amazon sin sky-tjeneste AWS (Amazon Web Service) gjør det enkelt å sette opp en server. Selve driften av maskinvare blir ansvarsområdet til Amazon, og krever kun konfigurasjon fra brukerens side. Gjennom AWS-kredit fra GitHubs studentpakke leier vi servere. Det gjør det mulig å ha servere oppe og kjørende for drift av applikasjonen. 24

26 6 Produktpresentasjon 6.1 Innledning Ut fra målene og planleggingen vi hadde satt oss, utviklet vi et produkt i form av en webapplikasjon. Utviklingsprosessen har blitt utført gjennom en smidig arbeidsmetode som resulterte i et produkt som gir en høy verdi for produkteier. Applikasjonen er bygd opp av en rekke komponenter både i front- og back-end. I dette kapitlet går vi gjennom en presentasjon av produktet der alle komponentene blir forklart. Presentasjonen inneholder forklaring av grunnleggende konsepter og funksjonalitet. I tillegg er det bilder og illustrasjoner som viser hvordan applikasjonen fungerer. For en teknisk gjennomgang av løsningen, se punkt 8 Produktdokumentasjon. 6.2 Aksess Innlogging Det første en bruker møter idet de starter applikasjonen, er et innloggingsvindu med to felt, ett for brukernavn og ett for passord. I tillegg er det tre interaktive objekter. «Husk meg» gir muligheten til å forbli innlogget. Dersom brukeren har glemt brukerlegitimasjonen, vil «Glemt passordet?» sette i gang prosessen for tilbakestilling av passord. Til slutt har vi knappen for å logge inn. Se punkt LoginComponent for detaljer om innloggingsprosessen. Figur 15. «Logg inn»-skjerm Hvis en bruker allerede har vært innlogget, og huket av «husk meg» ved innloggingen vil brukeren bli sendt direkte inn i applikasjonen uten å gå gjennom en ny innlogging. Prosessen bak denne funksjonen er forklart i punkt Token Passordtilbakestilling Figur 16. Skjermdump for modal "Glemt passord" Ved tilfellet der brukeren ikke kan huske passordet sitt, har applikasjonen funksjonalitet for manuell tilbakestilling. Ved å trykke på denne linken for glemt passord, vil det åpnes et nytt vindu som har et felt og en knapp. I dette feltet skal det skrives inn en til brukeren som har glemt passordet. Knappen er for å sette i gang prosessen med tilbakestilling av passordet. Gitt at en bruker med den -adressen eksisterer, vil det bli 25

27 sendt en med en link brukeren må følge. Denne linken vil føre brukeren tilbake til applikasjonen og åpne et vindu som inneholder to felter. Her kan brukeren skrive inn sitt nye passord i de to feltene. Knappen er i utgangspunktet deaktivert. For at knappen skal aktiveres, må passordene stemme overens. Når det nye passordet er sendt inn, blir brukeren sendt tilbake til innloggingsvinduet. Figur 17. Skjema for bytte av passord Aksessnivå Aksessnivå bestemmer hvilke funksjoner en bruker har tilgang på. For eksempel er det kun en administrator som skal ha muligheten til å opprette brukere, tags og grupper. Navn Aksessnivå Beskrivelse Admin 9 Administrator i systemet Veileder 2 Veileder for en eller flere grupper Bruker 1 Vanlig bruker i systemet Student 0 Informasjonskapsler om studenter 6.3 Felles elementer Oversikt Applikasjonen inneholder oversiktssider for tags, brukere, oppgaver og grupper. Disse sidene er det mulig å navigere seg til via menyen. Alle oversiktene med unntak av tag-oversikt viser nåværende år som «default»-tag. Dette er for å vise fram relevant data for dette året. En oversiktsside inneholder en liste over registrert data, der det er mulig å søke på navn og tags. Ved å trykke på en bruker eller gruppe åpnes et nytt vindu med mer informasjon. Når dette vinduet åpnes, kan dataen også bli endret og oppdatert. Dette gjelder ikke for tags. Sletting skjer også via oversiktssiden. På hver eneste oversiktsside har «kortene» en slette-knapp som sletter objektet. Kortene viser også relevant informasjon som for eksempel tags og medlemmer i gruppen. 26

28 Figur 18. Brukeroversikt I tilfeller der oversikt over grupper blir vist, er det mulig å utvide kortet for å se medlemmene og oppgaven knyttet til gruppen. Dette gjør at man kan få mer informasjon om gruppen uten å måtte trykke på «endre» knappen for å åpne den enkelte gruppen. Figur 19. Utvidet gruppekort Registrering Registrering innebærer å fylle ut et skjema der noen av feltene er obligatoriske for å gjennomføre prosessen. Dette gjelder for alt som skal registreres på applikasjonen. Mer om bruk av skjema, se punkt Forms. 27

29 I tilfellet der gruppe registreres, er det mulig å legge til ekstra felter for nye studenter. Det er også mulig å legge til eksisterende studenter til gruppen under registreringen. Figur 20. Bilde av registreringsvinduet til grupper Et annet tilfelle er når oppgave registreres, så kan dette gjøres på to forskjellige måter. Den første måten er å skrive oppgaven direkte i editoren (se punkt Editor), mens den andre er å laste opp et Word-dokument via filsystemet (se punkt Filsystemet). Begge måter vil laste opp dokumentet til filsystemet, og kan deretter åpnes i editoren hvis ønskelig. Figur 21. Editorsiden 28

30 Figur 22. Last opp fil fra filsystemet Søk Søking eksisterer på grupper, tags og brukere. Her kan man søke på oppgavenavn, gruppenavn eller tag-navn. Les mer om søk i punkt Søk I tilfellet der man søker på grupper eller brukere, er også søking på tags en mulighet. Resultatet vil da vise alle objektene med den valgte taggen. Søking på tvers av navn og tags er også et alternativ der resultatet er objektene som inneholder både tag(ene) og søkt navn. Figur 23. Søking på 'e' og tag: 2017, Student i brukeroversikt 29

31 Figur 23 viser hvordan man kan søke med navn og tags. Her er resultatet alle brukere som har taggene 2017, Student og i tillegg har «e» i navnet sitt. 6.4 Tags For å bedre beskrive en gruppe, bruker eller oppgave er det implementert et tag-system. Taggene kan brukes til å definere alt fra skoletilhørighet til om en oppgave er tildelt eller ikke. Taggene deles inn i typene: Skole, Status, Rolle, Dokument, År og Oppgave. Mer om presentasjon av tags eller tekniske detaljer 8.6 Tag-system. Figur 24. Søking av tags Tags kan bli valgt under registrering eller ved søk. Ved registrering er det mulig å søke på den taggen som man ønsker å gi til en oppgave, brukere eller gruppe. Det er mulig å gi flere tags til et objekt. Disse vises i oversikten på hvert eneste kort samt når en gruppe eller bruker er trykket på. I brukeroversikt er det mulig å se taggene som en bruker har fått. Figur 25 viser et eksempel på hvordan et sett med tags kan se ut for en bruker. Figur 25. Eksempel på visualisering av tags 6.5 Filsystem Filsystemet representert i applikasjonen baserer seg på data som er lagret på Google Drive. Løsningen tilbyr et liknende utseende, med kontrollert funksjonalitet basert på aksessnivået til den innloggede brukeren. I utgangspunktet er det tre tilgjengelige knapper øverst til venstre. «Tilbake», «Ny mappe» og «Last opp fil». «Tilbake» vil sende brukeren ett nivå tilbake i filsystemet, hvis dette ikke er mulig er knappen deaktivert. «Ny mappe» oppretter en ny mappe på det nivået man er på i filstrukturen. Hvis en mappe med samme navn allerede eksisterer, vil brukeren bli spurt om det er ønskelig å opprette en ny mappe med samme navn. «Last opp fil» åpner et vindu der man kan velge en fil å laste opp på til filsystemet. 30

32 Figur 26. Filsystem Under knappene er det en rad av linker separert med en /. Hver link representerer et nivå i filsystemet. Ved trykk vil det aktuelle nivået i filsystemet bli lastet inn. I Figur 26 er dette vist ved «My Drive / Oppgaver». På hvert nivå av filsystemet vil det være en mulighet for at det ligger ytterligere mapper og filer. Disse blir hver for seg representert i seksjoner. Hvert av elementene er interaktive. Ved trykk på en mappe, vil mappens innhold bli lastet inn. Ved trykk på en fil, blir en kontekstmeny åpnet. Her vil det være ulike valg som for eksempel åpne eller slett basert på hvilken type fil det er og hvilket aksessnivå brukeren har. For en detaljert gjennomgang av filsystemet, se punkt Filsystemet. Figur 27. Kontekstmeny 6.6 Mail Det er mulig å sende mail til alle i en gruppe, eller velge enkeltvis fra brukeroversikten. For tekniske detaljer, se punkt 8.7 Mail-system. Mailknappen på hver gruppe i gruppeoversikten vil åpne Outlook der mottakeren er alle studentene i gruppen og veilederne i gruppen blir satt som CC. Figur 28. Et gruppe-kort med mailknappen ringet rundt 31

33 Figur 29. Outlook med utfylte felter 6.7 Diskontinuerte elementer Gridsystem Det ble implementert et gridsystem i applikasjonen. Konseptet var å legge komponenter i paneler som man kunne ha aktive til enhver tid. Dette systemet var del av kjernen i applikasjonen og krevde derfor mye tid og arbeidskraft. For en mer detaljert beskrivelse og funksjonalitet av gridsystemet, se punkt Gridsystem. Figur 30. Gridsystemet Ideen bak gridsystemet var å gi brukeren muligheten til å bestemme sin egen arbeidsflyt ved å kunne bestemme selv hvilke vinduer som var ønskelig å ha aktive. Etter en brukertest var det tydelig at det å gi brukeren for mye frihet kan være forvirrende og lite brukervennlig. Dette endte med at applikasjonen måtte omstruktureres til en mer statisk løsning som er nåværende produkt. 32

34 6.7.2 Angular/Material2 Angular/Material2 er en modul utviklet for Angular 2. Den endrer utseende på applikasjonen til et mer rent og minimalistisk design. Vi så en ulempe ved at det blir for mye whitespace som gjør at det blir mye tomrom. For mer om material2 se punkt Angular/Material2. Etter en revurdering ble det valgt å bruke Bootstrap istedenfor. Bootstrap gir oss mer frihet til å selv designe elementer i applikasjonen som gjør at vi kan gjøre sidene fyldigere Angular2-modal Angular2-modal er et bibliotek med åpen kildekode som er utviklet for å lage modaler. Biblioteket gjør det mulig å selv definere modaler som ble brukt for noen av komponentene. Hovedgrunnen til at biblioteket ikke kunne brukes lenger var at den hadde dårlig kompatibilitet med Bootstrap 4 samt var vanskelig å anvende. Mer om angular2-modal se punkt Angular2-modal 7 Konklusjon Accenture tidligere løsning bød på en rekke utfordring som en tungvint registreringsprosess og dårlig oversikt. En av årets oppgaver var derfor å lage en applikasjon som løste disse utfordringene. Oppgaven hadde ingen krav til teknologier, men Docker, JavaEE og Maven var et ønske fra produkteiers side. Maven og JavaEE ble kun brukt i back-end. I front-end ble det heller valgt å bruke et eget rammeverk og derfor falt valget på Angular 2. Valgene støtter opp under læringsmålene vi hadde for prosjektet. Det var viktig for oss at teknologiene var moderne og relevante i bransjen, og ikke minst at det var noe vi ikke hadde lært på høgskolen. Vi har vært innom og brukt store mengder teknologier, noe som har ført til et godt læringsutbytte. Gjennom fasene i prosjektet er det brukt ulike utviklingsmetoder. En kanban-tilnærming har vært brukt i start- og avslutningsfasen. Gjennom hele utviklingsfasen ble det brukt scrum, noe som var et ønske fra Accenture. Dette har vist seg å gi oss en god oversikt over prosjektet. Det har hele tiden vært klart hva som må gjøres og hva som gjenstår. Vi sitter også igjen med tall på arbeidsmengde per oppgave, samt total arbeidsmengde lagt inn i prosjektet. Presist tall per 23. Mai 2017 er 2616 timer totalt. Gjennom prosjektets gang har vi erfart det å delta i en hverdag som konsulent. I Accenture har vi fått muligheten til å delta på ulik kursing, ha møter med fagpersoner innen alt fra UX-design til eksperter på REST-API. Løsningen vi har kommet med fremmer et enkelt, men raffinert og oversiktlig design som samler det som var spredt i den tidligere løsningen. Nå kan en gruppe registreres i ett vindu med studenter, veiledere, oppgaver og ikke minst tags som muliggjør avanserte søk. Løsningen tilbyr et grensesnitt mot Google Drive som kontrollerer aksess på filer og mapper. Den innebygde editoren åpner for 33

35 muligheten til å opprette dokumenter direkte i applikasjonen uten å ha andre programmer involvert. Mail har blitt en enkel operasjon da det er lagt opp til at man kan sende mass til et helt kull på få tastetrykk. EFFEKTMÅL Effektivisere registreringsprosessen rundt grupper og tilhørende studenter. Sentralisere og effektivisere dokumenthåndtering Effektivisere tidsbruken til produkteierne Applikasjonen skal kunne skaleres for videre funksjonalitet LØSNING Samlet registrering av grupper til et skjema: Mulig å registrere gruppe med studenter og oppgave i et og samme skjema. Mulig å legge til nye studenter og eksisterende studenter i samme prosess. Implementert «Google Drive»-API med et selvutviklet grensesnitt i løsningen. Følgende tiltak er implementert: Samlet registrering av grupper til et skjema. Samlet informasjon om en gruppe (studenter, veiledere, oppgave) på én oversiktsside. Implementert Tag-system som gir effektive søk. Mulig å legge til tags som for eksempel «2017» eller «Veileder». Mulig å sende mail til flere brukere basert på tags (for eksempel alle studenter), eller til de i samme gruppe på engang. Implementert designmodeller som «Repository Pattern», RESTful API, Enterprise Architecture og rammeverk som Angular 2 for å få modularitet i koden. Mer informasjon i punkt 9.3 Designmodeller. 34

36 PRODUKTDOKUMENTASJON Adrian Siim Melsom, Duy Johnny Khac Nguyen, Håkon Smørvik, Kim Long Vu 35

37 8 Produktdokumentasjon 8.1 Forord Formålet med produktdokumentasjonen er å gi leseren et dypt teknisk innblikk i alle deler av programmet. Den er beregnet på lesere som skal drive med drift, vedlikehold og videreutvikling. Det forutsettes at leseren har tekniske forkunnskaper innen programmering. For at leser skal ha best utbytte av dette dokumentet anbefales det å lese kapittel 6 i hovedrapporten. 8.2 Innholdsfortegnelse 8.3 Innledning Beskrivelse av produktet Samsvar mellom kravspesifikasjon og produkt Tagsystemet Mailsystemet Mail i gruppeoversikt Mail i brukeroversikt Struktur Back-end API-logikk Database Data Access Layer Front-end Oversikt LoginComponent PasswordResetComponent Sidemeny Elementer Servicer Editor Filsystemet Kontekstmeny

38 Gruppeoversikt GroupForm Brukeroversikt Brukerregistrering Tagoversikt TagForm

39 8.3 Innledning Gjennom fem måneder har gruppen utviklet et produkt som skal gjøre administrering av bachelorgrupper enklere, raskere og mer oversiktlig. Rapporten starter med en beskrivelse av løsningen og hvordan implementasjonen er i henhold med kravspesifikasjonen. Deretter går rapporten i detalj om tag- og mail-systemene. Til slutt er det en teknisk gjennomgang av back- og front-end. Denne delen av rapporten skal kunne støtte for videre utvikling av applikasjonen, og er rettet mot lesere med teknisk bakgrunn. Kodesnutter blir forklart med bilder og detaljerte forklaringer. Under utviklingen har scrum-metodikken blitt brukt. Dette har ført til flere iterasjoner av løsningen. Produktet er implementert i henhold til brukerhistorier fra kravspesifikasjonen. I samarbeid med produkteiere, har brukerhistoriene blitt prioritert i den rekkefølgen de mente var naturlig å implementere. Utviklingen har møtt på flere utfordringer som førte til at noen funksjoner ble implementert annerledes enn originalt tenkt. Merk at kode er skrevet på engelsk, mens produktets grensesnitt er norsk. 8.4 Beskrivelse av produktet Produktet er et system for å håndtere prosesser rundt bacheloroppgaver og studenter. For å oppnå dette brukes modeller for grupper, bruker, tag, oppgave. I tillegg er systemet delt i fire moduler som kan erstattes ved: Klient Håndterer interaksjon med brukere. Klienten har et brukergrensesnitt for å representere data på en brukervennlig måte. API Håndterer data fra klientene. Her er det logikk for å avgrense aksess til brukere, samt logikk for å håndtere data. APIet har muligheten til å sende tilbakemeldinger på eventuelle feil som oppstår i forbindelse henting og lagring av data. Database Håndterer lagring og henting av grupper, brukere, tags, og metadata om oppgaver. Google Drive Håndterer filer. Dette kan være alt fra oppgavetekster til PDF-filer og Excelark. Endringer skal ikke ha noen effekt på de andre modulene. Her er det viktig å merke seg skalerbarheten til systemet med tanke på at APIet ikke er avhengig av en spesiell type klient. I fremtidige prosjekter er det mulig å bruke APIet i en mobilapplikasjon eller lage en helt ny versjon av klienten hvis det skulle være nødvendig. 38

40 8.5 Samsvar mellom kravspesifikasjon og produkt Brukerhistoriene ble brukt som en «backlog» i prosjektet. Disse ble, i samarbeid med produkteier, rangert etter prioritet. Den endelige backloggen hadde flere forandringer i forhold til den originale. Nye brukerhistorier kom frem underveis og flere ble avviklet etter ønske fra produkteier. Alle brukerhistoriene i backloggen ble implementert. Flere brukerhistorier ble løst under en og samme implementasjonen. For eksempel ble brukerhistorie #30, som omhandler søk på brukere, løst når vi implementerte søking på tags. Se punkt 9.10 Brukerhistorier Planlegging for den originale versjonen og punkt 9.11 Brukerhistorier Endelig for endelig versjon. 8.6 Tagsystemet Tags brukes til å beskrive grupper, brukere og oppgaver i applikasjonen. Dette gjør det mulig å søke og filtrere modellene gjennom tags. Det er hovedsakelig seks typer tags: År, Skole, Rolle, Status, Oppgave og Dokument. Disse er ikke mulig å slette, da flere funksjoner er avhengig av disse. Det er derimot mulig å legge til flere typer gjennom en konfigurasjonsfil. I tillegg er det ikke mulig å slette taggene Student, Veileder, Bruker, Oppgave, og alle tags av typen År. Tilhørende tagger vises for objektene i de forskjellige oversiktsskjermene. Hvordan taggene blir visualisert kan leses i Tags. Type tags tilgjengelig Gruppe Bruker Dokument Bruk År X X X Blir brukt for å filtrere objektene på år, slik at bruker av system kan behandle års-relevant data. Blir automatisk generert hvert år Skole X X Blir brukt til å vise skoletilhørighet Rolle X Blir brukt til å definere roller som: Student, veileder, admin og liknende. Status X X X Blir brukt til å tilordne egendefinerte statuser. Oppgave X Blir brukt til å legge til beskrivende tagger om oppgaven, som Java, Webapplikasjon og liknende. Dokument X Blir brukt til å definere hva slags type dokumentene er. 39

41 8.7 Mailsystemet Mail i gruppeoversikt Figur 31. Et gruppe-kort med mailknappet ringet rundt Gruppeoversikten inneholder en mail knapp for hver gruppe. Når knappen blir trykket på, kjøres metoden sendmail. Metoden tar imot en gruppeid og finner gruppen med tilsvarende id. Deretter mellomlagres enterpriseiden til hver student og veileder. Dersom en student ikke har en slik ID, mellomlagres den registrerte en. Figur 32. sendmail() metoden i group-view.component.ts Metoden generer til slutt en «mailto:»-string der hver student blir lagt til som mottakere, og veilederne som CC.. Gjennom JavaScripts «window.open»-funksjon, åpnes Outlook. 40

42 8.7.2 Mail i brukeroversikt Figur 33. Brukeroversikten med mailfunskjonene ringet rundt Figur 33 viser en «Send mail»-knapp og en checkbox. Dersom ingen av boksene er avkrysset er knappen inaktiv. Hver gang et brukerkort markeres, blir knappen reaktivert og metoden addmail kjøres. Metoden tar imot en brukermodell. Brukeren blir så lagt inn i et array som inneholder alle brukerne som har blitt huket av. Metoden vil også fjerne brukeren fra dette arrayet, dersom markeringen fjernes. Figur 34. addmail() metoden i user-view.component.ts For å gjøre det enklere å markere er det en «Marker alle» checkbox, som markerer alle synlige brukere i oversikten. Dette gjør at brukeren av applikasjonen har muligheten til å f.eks. filtrere brukerne på veiledere og sende mail til alle sammen via å markere alle fra det søket. «Send mail»-knappen er en anker-tag med Bootstrap-styling for knapper. I taggen blir det interpolert gjennom metoden sendmail en string med de markerte brukernes . Denne stringen blir prefikset med «mailto:». 41

43 8.8 Struktur Løsningen er bygget opp av tre hoved moduler: et REST-API, en MySQL Database og en webapplikasjon skrevet i Angular 2. Disse kjøres i hver sin Docker Container med hvert sitt Docker Image. Dette kjøres igjen på hver sin virtuelle maskin på Amazon Web Service i skyen. APIet kjører med et «Payara Server-Full»-image, databasen på et «MySQL-server»-image og webapplikasjonen på et «Tomcat»-image. Mer om dette se punkt Docker, MySQL, Payara, AWS Figur 35. Utrullingsmiljø Back-end I dette delkapittelet er målet å gi en oversikt over strukturen og funksjoner i back-end delen av applikasjonen. Dette inkluderer APIet for Bachelor Manager, databasen og Google Drive sitt API. APIet vi lagde har intern arkitektur illustrert av følgende figur: 42

44 Figur 36. Back-end arkitektur API-logikk I dette delkapittelet er målet å gi en oversikt over hvordan samhandlingen mellom de individuelle komponentene i back-end fungerer. Det vil bli tatt utgangspunkt i figuren ovenfor. Det er forventet at leser har gjort seg kjent med JSON da det ikke vil bli forklart i forbindelse med innkommende requests og utgående responses. Mer om JSON se punkt JSON RequestFilter Klassen RequestFilter håndterer innkommende forespørsler gjort mot APIet. 43

45 Figur 37. Metoden filter I starten av metoden filter håndteres preflight request. Det gjøres ikke noe spesielt med preflighten, siden den ikke inneholder noe annet enn metadata om det faktiske requestet som kommer. Derfor gjøres det kun en sjekk på hvorvidt det er en preflight eller ikke, og returnerer hvis dette er tilfellet. Dette trigger ResponseFilteret som forklares i detalj i kapittelet om ResponseFilter. Videre når requestet med den faktiske dataen kommer, gjennomføres en verifisering av klienten som prøver å aksessere APIet. Verifiseringen gjøres på én av to måter. Den første måten er Basic Authorization. Denne bruker brukernavn og passord til å verifisere klienten. Den eneste jobben denne autoriseringsmetoden har i APIet er å generere et token som kan brukes til å aksessere APIet uten innlogging. Følgende steg gjøres for å verifisere tokenet. 44

46 Figur 38. Metodene verify og decode Først dekodes tokenet (se metode decode i Figur 38). Hvis alt går som det skal blir tokenets komponenter lagt i et returobjekt for videre behandling. Hvis noe skulle gå galt under dekodingen returneres en null-referanse som stopper verifiseringsprosessen. Deretter brukes dataen i tokenet til å lete frem en bruker hvis den eksisterer. Hvis brukeren ikke skulle eksistere vil det bli kastet en EntityNotFoundException som avslutter verifiseringsprosessen. Hvis brukeren eksisterer sjekkes datoen på tokenet for om det fortsatt er gyldig. Hvis det er gyldig blir brukerobjektet sendt videre for å sette rollen den har i APIet. 45

47 Figur 39. Metode getuserallowance Figur 39 viser hvordan vi bruker en egen SecurityContext til å holde på rollen og konto-detaljene til klienten. Dette Objektet kan aksesseres innenfor request-konteksten med følgende kode: Figur 40. Hente brukerinformasjon Ressursklasser Ressursklassene er der man begynner behandlingen av selve forespørselen. Oppgaven til disse klassene er å definere endepunktet i en URL for å samle handlinger man kan gjøre på en viss type data. Eksempelvis vil lede til ressursklassen som har metoder som har med brukere å gjøre. I vår applikasjon brukes HTTP-metodene GET, POST, DELETE og PUT. Hver av disse kan forekomme én gang hver, på samme endepunkt. Ønsker man flere versjoner av en GET- 46

48 metode må man utvide URL-endepunktene. Et eksempel kan være at man ønsker å hente informasjon om en bruker. Da kan URL-en se slik ut: for å hente bruker med ID 1. Figur 41. GET-metode Figur 41 viser et eksempel på hvordan vi har bygd opp våre GET-metoder i applikasjonen. De, som de tre andre metodene (POST, DELETE og PUT) skal håndtere svært lite logikk. Arbeidet som skal gjøres sendes videre i en gitt service-klasse. Metodene blir annotert med rollen de skal fylle, som i tilfellet med Error! Reference source not found. Det er også en del andre annoteringer til rådighet. Sti (@Path) definerer ytterligere URL-sti for å treffe definerer datatypen som sendes med Respons-objektet. brukes i tilfeller der metoden krever mer data fra brukeren for å gjennomføre jobben. Metoder som POST og PUT i bruk da de naturlig handler om å tilføye ny data. APIet tilbyr følgende ressursklasser. AccountResource Aksesseres på */bm-rest-api/api/accounts og har følgende metoder: Metode Sti Parameter Beskrivelse GET /login Ingen Returnerer et token for å aksessere applikasjonen uten innlogging POST /password JsonObject Forsøker å finne en bruker og oppdatere dens passord. POST /newuser/{id} Ingen Forsøker å finne en bruker for å sende en mail med en passordtilbakestillings-link. 47

49 FileResource Aksesseres på */bm-rest-api/api/files og har følgende metoder: Metode Sti Parameter Beskrivelse GET /folder/{id} String GET /folder Ingen GET {id} long GET /open/{id} String GET /structure Ingen GET / List<String> POST /folder JsonObject Returnerer et json-objekt med metadata om alt som ligger i folderen med en gitt id Returnerer et json-objekt metadata om alt som ligger i root folder Returnerer et json-objekt metadata om en fil med en gitt id Returnerer en fil på HTMLformat basert på en gitt id Returnerer et json-objekt bygd for en rekursiv representasjon av filsystemet Returenerer et json-objekt med metadata om alle filer som har tags som samsvarer med parameterne. Oppretter en folder basert på dataen i json-objektet. POST /upload/{id} File, String, boolean, List<Integer> Uploads a given file to google Drive DELETE {id} String, boolean PUT {id} File, String, List<Integer> Forsøker en id-basert sletting. Dette kan gjelde både filer og foldere. Fosøker en id-basert oppdatering av en fil. 48

50 GroupResource Metode Sti Parameter Beskrivelse GET {id} int GET / List<String>, boolean POST / JsonObject DELETE {id} int PUT / JsonObject Returnerer et json-objekt med data om en gruppe basert på id Returnerer et json-objekt enten med alle grupper, grupper som har alle tags definert i listen, eller en av taggene definert i listen. Oppretter en gruppe basert på json-objektet Forsøker en id-basert sletting av en gruppe Forsøker en oppdatering på en gruppe basert på json-objektet TagResource Metode Sti Parameter Beskrivelse GET {id} int GET / List<String> POST / JsonObject DELETE {id} int PUT / JsonObject Returnerer et json-objekt med data om en tag basert på id Returnerer et json-objekt med data om alle tags, eller de som samsvarer med tags nevnt i parameter Oppretter en tag basert på jsonobjektet Forsøker en id-basert sletting av en tag Forsøker en oppdatering på en tag basert på json-objektet 49

51 UserResource Metode Sti Parameter Beskrivelse GET {id} int GET / List<String>, boolean POST / JsonObject DELETE {id} int, boolean PUT / JsonObject Returnerer et json-objekt med data om en bruker basert på id json-objekt enten med alle brukere, brukere som har alle tags definert i listen, eller en av taggene definert i listen. Oppretter en bruker basert på json-objektet Fosøker en id-basert sletting av en bruker Forsøker en oppdatering på en bruker basert på json-objektet Figur 42. POST-metode annotasjon Figur 42 viser hvordan brukes til å vise typen returdata klienten kan forvente. Det er ikke nødvendig i de fleste tilfeller, men gjøre APIet mer lesbart og brukervennlig. I figuren vises også hvordan dataen kan brukes som parameter direkte i metoden. 50

52 Serviceklasser Serviceklassene er leddet i back-end som binder ressursklassene sammen med klassene som styrer database-, mail- og drive-logikk. Jobben til serviceklassene er å lage en best mulig respons til klienten basert på hvordan forespørselen går. Applikasjonen bruker følgende responstyper: OK brukes ved hending av data CREATED brukes ved en suksessfull opplasting av data NO CONTENT brukes ved en suksessfull sletting av data MULTIPLE CHOICES brukes hvis klienten prøver å overskrive eller slette data som har avhengigheter som kan påvirkes ved endring eller sletting BAD REQUEST brukes hvis klienten etterspør data som ikke eksisterer UNAUTHORIZED brukes hvis klienten ikke kommer gjennom autoriseringsprosessen, eller hvis en autorisert bruker prøver å aksessere en ressurs de ikke har tilgang på NOT ACCEPTABLE brukes hvis dataen fra klienten har kommet på et feil format ved bruk av POST- og PUT-metoder SERVICE UNAVAILABLE brukes i spesialtilfellene der servicen til gmail skulle være nede eller ikke er i stand til å sende mail. Figur 43. metoden newuser Figur 43 viser hvordan de ulike tilbakemeldingene brukes til å gi klienten en tydelig beskjed på hvordan forespørselen gikk. Ved sletting og oppretting av data er det lagt inn sikkerhetsmekanismer som hindrer en klient fra å overskrive eller slette data ved en feil. Et eksempel på dette kan bli sett i følgende figur. 51

53 Figur 44. Metoden deleteuser Her blir variabelen «forced» brukt til å tvinge en sletting hvis brukeren klienten prøver å slette er siste medlem i en gruppe. Dette er en handling som innebærer at gruppen også blir slettet. Det er to unntak fra det generelle for hvordan servicene er bygd opp. FileService og AccountService er to klasser som har roller som går utover det å delegere videre. FileService samhandler med FileResource og FileHandler (Se punkt FileHandler). 52

54 Figur 45. Metode uploadanyfile Figur 45 viser hvordan det gjøres ulike sjekker på det som lastes opp for å sikre at det stemmer over ens med det som er tillatt å laste opp. Det er et spesialtilfelle der man laster opp en HTML-fil. Dette er noe applikasjonen bruker for å laste opp fra editoren. For å kunne laste dette opp til google drive må HTML-filen bli oversatt til en word-fil slik at den holder samme format som den gjorde i editoren. 53

55 Figur 46. Metoden uploadashtml Figur 46 viser hvordan filen som en InputStream blir brukt til å lage en.docx-fil. Etter at filen er lagd lokalt blir den sendt videre inn i en metode som sikrer lagring på google drive. Deretter lagres metadata om filen på databasen. Til slutt slettes den lokale filen for å ikke bruke unødvendig plass. For å kunne åpne tekstdokumentene på Drive i editoren må filen først oversettes til HTML. Til denne jobben tas et bibliotek i bruk, Docx4j. Figur 47. Metoden getfileashtml (første overload) 54

56 Figur 47 viser hvordan FileService bruker biblioteket til å pakke inn en gitt fil på.docx-format og deretter plasserer innpakningen i et objekt med en rekke innstillinger på hvordan filen skal bli lest. Objektet med innstillingene blir så sendt videre for å bli lest inn i en OutputStream. Figur 48. Metoden getfileashtml (andre overload) Figur 48 viser hvordan vi benytter innstillingsobjektet til å skrive ut innholdet av filen til en streamen som til slutt returneres som et String-objekt. Denne tekststrengen er det som brukt i Responsen til klienten. AccountService håndterer prosessen rundt det å sende link for å tilbakestille passordet til en bruker. Figur 49. Metoden resetpassword 55

57 Det at APIet jobber med JWT (JSON Web Token se Om HTTP) gjorde tilbakestilling av passord til en relativt simpel oppgave. Ved å bruke en ID sendt fra en klient, prøver APIet å finne en bruker som stemmer over ens. Hvis brukeren eksisterer blir det generert er token som er gyldig i en halvtime på brukerens vegne. Dette tokenet blir så lagt på slutten av en link som fører til applikasjonens side for tilbakestilling av passord. Når beskjeden er bygd tar MailHandler over jobben med å faktisk sende mailen. Se MailHandler for utdyping av denne prosessen GoogleService GoogleService er en klasse som bruker kode fra API sidene til Google Drive og Gmail til å generere et autorisert service-objekt. Figur 50. Metoden autorize Credenial-objektet returnert fra denne metoden brukes på følgende måte. 56

58 Figur 51. Metodene getgmailservice og getdriveserive Objektene returnert fra de to metodene i Figur 51 brukes av MailHandler og FileHandler slik at de kan kommunisere med APIene til google FileHandler FileHandler håndterer alt som har med opplasting og sletting av filer, oppretting og sletting av mapper og henting av representativ data i forhold til filstruktur. Alle metodene går ut ifra Drive-objekt. Driveklassen er bygd opp av google, men krever en API-nøkkel for å bli brukt. Med dette objektet kan man operere på dataen på Drive. Metodene operer med HTTP-protokollen, og tilbyr derfor metoder som GET, POST, PUT og DELETE. Applikasjonen tilbyr et grensesnitt mot google drive. 57

59 Figur 52. Metoden getfolder Figur 52 viser hvordan APIet kontrollerer aksessen til en bruker på hver enkelt fil som ligger på Drive. Det er gjort på denne måten for å brukeren skal slippe å måtte lage en Google-konto ved siden av. APIet er den eneste faktiske brukeren av Drive, og skaper et grensesnitt mellom klienter og Drive. Drive har ikke noen naturlige mekanismer som stopper en bruker fra å lage filer med samme navn. Dette er fordi at Drive bruker en ID-basert løsning for å skille filene fra hverandre. Det er også mulig å 58

60 slette mapper med innhold. Disse mekanismene ble derfor lagt i applikasjonens API i stedet. Figur 53. Metoden createfolder Figur 54. Metoden deleteitem Figur 53 og Figur 54 viser hvordan sikkerhetsmekanismene til APIet sikrer at dobbellagring og sletting av mapper med innhold ikke forekommer uten klienten gjøres oppmerksom på situasjonen. 59

61 MailHandler MailHandler håndterer det å sende automatisert mail til en bruker av applikasjonen. Målet med denne klassen var å automatisere tilbakestillingsprosessen uten menneskelig interaksjon fra andre enn brukeren som skal tilbakestille passordet sitt. Klassen bruker totalt tre metoder for å bygge, generere og sende . Figur 55. Metoden create Figur 55 viser hvordan en bygges som en MIMEmessage, med mottaker, avsender, emne og innhold. MIMEmessage er en internettstandard som utvider formatet på en til å inkludere for eksempel ikke-tekstkomponenter som lyd, bilde og video. For at Gmail sitt API skal kunne sende mailen, må MIMEmessage-objektet bli pakket inn i et Message-objekt google har definert. 60

62 Figur 56. Metoden createmessagewith Message-objektet bygd i Figur 56 er det som blir sendt til Gmail sitt API for å gjøre et forsøk på å sende en automatisert til brukeren som etterspurte en tilbakestilling av passordet sitt. Figur 57. Metoden sendmessage Figur 57 viser siste steg i den automatiserte sendingen av . Her tar google sitt API over jobben, og ved mindre en exception blir kastet anses en som sendt i applikasjonens API ResponseFilter ResponseFilter-klassen brukes til å konstruere akseptresponsen til klienten. Dette er nødvendig, fordi de fleste nettlesere bruker CORS. Dette innebærer at nettleseren sender en preflight request. Denne inneholder data om hva nettleseren skal gjøre på nettressursen den etterspør. Ressursen, APIer i 61

63 applikasjonens tilfelle, kan da filtrere for eksempel hvilke HTTP-metoder som er lovlige og hvilke IPadresser som har tilgang. Hvis dette preflight-requestet ikke blir godkjent vil ikke nettleseren sende det faktiske requestet, men heller få en feilmelding. Figur 58. Metoden filter Links Linkene som blir lagt til i modellene genereres av Links-klassen. For at repositoriene skal kunne legge til disse linkene må de bruke «Links.generateLinks»-metoden. Disse linkene er lagd etter HATEOAS prinsippet i RESTful API design. Figur 59. Hvordan links legger på et objekt Token APIet bruker JWT, forklart i punkt Om HTTP, for å autorisere forespørsler. Det er to ulike versjoner av tokenet det jobbes med. Det første og vanligste er et «Access token» (AT). Det andre er et «Refresh token» (RT). Forskjellen mellom dem er at AT har en varighet på 90 dager, der RT har en varighet på 30 minutter. AT brukes i det en bruker logger inn, slik at innlogging ikke er nødvendig over en lengre periode. RT brukes ved passordtilbakestilling slik at linken er ubrukelig etter at en halvtime har gått. 62

64 Figur 60. Metoden generatetoken Metoden vil gå gjennom id-listen og lage linker basert på hva slags type som er oppgitt. Disse typene ligger i klassen som «static final» variabler. Figur 61. Metoden generatelinks 63

65 Database Tabellnavn USER PASSWORD DOCUMENT BACHELOR_GROUP TAG USER_TAG GROUP_TAG DOCUMENT_TAG GROUP_ASSOCIATE GROUP_DOCUMENT Beskrivelse Inneholder personalia, aksessnivå og salt. Brukes til å lagre informasjon for veiledere, studenter og generelle brukere. Inneholder hashet passord og brukernavn til bruker. Inneholder tittel, sti og bruker-id. Sti inneholder lokasjonen i Google Drive, som brukes i APIet for å hente filen. bruker-id sier hvem som eier filen. Inneholder navn på gruppen. Inneholder navn, beskrivelse og type for tags. Mellomtabeller som skaper relasjonene på hvilke tagger disse entitetene eventuelt har. Mellomtabell som skaper gruppetilhørighet for brukere. Mellomtabell som skaper relasjon på hvilke dokumenter som er knyttet til hvilken gruppe. For eksempel kan et oppgavedokument kobles til en gruppe gjennom denne tabellen. 64

66 Figur 62. ER-diagram lagd i MySQL Workbench Diagrammet ble lagd med MySQL Workbench. I tillegg til diagrammet genererte verktøyet også et SQL-Script. Dette ble brukt som et utgangspunkt for videre modellering av databasen. Figur 63. eksempel av en tabell i skriptet I MySQL databasen må det gis rettigheter for hva det kommuniserende programmet kan gjøre. Dette gjøres i databasen ved å kjøre kommandoen: 65

67 Figur 64. Hvordan gi rettigheter på DB Data Access Layer AbstractRepository og Repository Interface Hver repository implementerer interfacet Repository som definerer de fire CRUD-metoder og en spesiell read metode som returnerer objekter med mindre informasjon. Figur 65. Repository-interface I tillegg til dette arver alle repository fra AbstractRepository. Inne i forelder-klassen ligger da selve metoden for å opprette kommunikasjonen til databasen, som bruker Hibernate sin SessionFactory. Denne koden er hentet fra Hibernate sin dokumentasjon på hvordan SessionFactory skal brukes. SessionFactory benytter en konfigureringsfil (hibernate.cfg.xml) til å koble seg til databasen. I første omgang vil SessionFactory danne koblingen mellom applikasjon og databasen, deretter vil det være mulig å tilkalle metoden opensession som vil gjøre det mulig å snakke med databasen gjennom Hibernates metoder. Figur 66. metoden buildsessionfactory 66

68 Konfigurasjon av Hibernate Property Dialect Effekt Konfigurer Hibernate til å generere på et SQL-språk samsvarende med databasen, som i dette tilfellet er en MySQL database Driver_class Bestemmer hva slags implementasjon av JBDC Hibernate skal bruke for å koble seg til databasen. JBDC er Javas spesifikasjon på API som brukes til å koble programmer med databaser Url Username Password Show_sql Adressen til databaseserveren Brukernavn for databasen Passord for bruker i databasen Bestemmer om Hibernate skal inkludere SQL-setningene i konsoll ved eksekvering Mapping_class Referanse til klassene som inneholder ORM-notasjonene. Dette bruker Hibernate til å finne mappingen til de ulike tabellene. Figur 67. hibernate.cfg.xml Metodene fra AbstractRepository bruker Hibernate sine persisterings metoder for å gjøre spørringer mot databasen. Hibernate tilbyr blant annet fire metoder for persistens. Det finnes flere metoder som utfører samme funksjonaliteten, men disse fire er de mest grunnleggende: Metode Parameter Bruksområde session.save(item) session.update(item) Entitet Objekt Henholdsvis lagrer, oppdaterer og sletter metodene entiteten i 67

69 session.delete(item) databasen basert på JPAmappingen. session.createquery(query) String Lager og eksekverer en spørring basert på HQL spørringen sendt som parameter. Retunerer en liste av objekter. Disse metodene må bli kalt innenfor en transaction scope. Dette kan ses på som en tråd som skal utføre en batch med sql-spørringer mot databasen. For å starte denne tråden, må det åpnes en session. Dette gjøres i SessionFactory. I de nyere versjoner har Hibernate gitt støtte for bruk av metoden opensession med «try-catch resource», slik at vi slipper å lukke session etter bruk. Etter kallet kan man starte en transaction med metoden begintransaction, som åpner muligheten for å gjøre spørringer. Det er da mulig å gjennomføre commit og rollbacke mot databasen. Figur 68. updateentity() som et eksempel på anvendelse av session og persistens metoder i Hibernate CRUD-metodene gjør en automatisk rollback når Hibernate oppdager noe feil, som ukorrekt mapping og når tilkoblingen med server mistes. Alle spørringene må være gyldige for at batchen skal utføres. De fire metodene for persistens i AbstractRepository kaster alle en EntityNotFoundException i tilfeller der entiteten ikke finnes, eller at relasjonene til entiteten skaper problemer. Disse blir behandlet i de spesifikke repositoriene slik at de kan gi en mer detaljert tilbakemelding. 68

70 Figur 69. Repository mappen Det skal være en repository for hver business-modell som applikasjonen benytter: Document-, Group-, Tag- og UserRepository. I tillegg er det et eget repository for kontobehandling. Alle implementerer interfacet Repository utenom AccountRepositoryImpl, som implementerer sitt eget interface. Grunnen til dette er at AccountRepositoryImpl ikke skal ha like metoder som de vanlige repositoriene (add, get, remove og update) Entiteter Tabellene er designet etter modellene som applikasjonen trenger, derfor er det en tabell for hver modell. Mappingklassene er kalt «Hbn» (Hibernate) for å skille de fra modellene. Alle implementerer interfacet HbnEntity, dette er for å kunne la AbstractRepository sine metoder behandle alle entiteter. Alle mappingklasser annoteres (name = TABLE_NAME). Dette forteller Hibernate at klassen Figur 70. Entity mappen representerer en tilsvarende tabell i databasen. Disse klassene er bygd opp som «Plain Old Java Objects». Det kreves en tom konstruktør, og datafelter med get og set metoder for at Hibernate skal kunne behandle entitetene. Hvis det er mange-til-mange relasjoner benyttes Set for å representere dette. Figur 71. Entitet eksempel del 1 Annotasjonene for mapping av kolonnene kan både plasseres på datafeltene eller get-metodene. Indekser blir i som alle andre vanlige kolonner har. 69

71 Figur 72. Entitet eksempel del 2 Ved mange-til-mange relasjoner annoteres det for å beskrive hjelpetabellen mellom tabellene. Name må tilsvare tabellnavn, joincolumns og inversejoinscolumn må tilsvare de fremmednøklene som ligger i tabellen. Denne annoteringen plasseres hos «eier» av forholdet. Figur 73. Entitet eksempel del 3 På den andre siden av relasjonen refereres datafeltet som representerer relasjonen. Figur 74. Entiet ekesempel del 4 70

72 Implementasjonen av Repository AccountRepositoryImpl skal ha to metoder: En registreringsmetode og en «match»-metode som skal autentisere passord og brukernavn. Registreringsmetoden lager et salt ved hjelp av «BCrypt» biblioteket. Saltet blir så brukt i BCrypthashingen for både passord og brukernavn. Dette brukes til å lage kontoen som ligger lagret i en egen tabell (Password), og deretter blir brukers (User) salt og aksessnivå oppdateres. Metoden validerer for tomme parametere, og kaster en IllegalArgumentException (IAE) hvis dette er tilfellet. Det kastes en EntityNotFoundException (ENFE) i tilfeller der id ikke finnes i databasen. Figur 75. Eksempel på en generert salt Figur 76. AccountRepositoryImpl.regsiter() Metoden matchpassword() tar imot brukernavn og passord. Først gjøres en sjekk for om oppgitt brukernavn er tilknyttet en bruker, deretter hasher metoden brukernavn og passord. Det hashede brukernavnet brukes i en spørring mot databasen. Hvis det returneres et innlegg fra databasen, finnes en registrert konto med brukernavnet, hvis ikke kastes et IAE. Til slutt sjekkes det om passord stemmer (kaster også IAE), og retunerer bruker ved gyldig innlogging. 71

73 Figur 77. AccountRepositoryImpl Metoden getaccount() brukes for å se om en bruker faktisk har en konto. Dette benyttes i «glemtpassord» for å sikre at bruker ikke kan be om et nytt passord uten en konto. Figur 78. AccountRepositoryImpl Som tidligere nevnt, behandler alle repository modeller. Så i UserRepository skal add metoden ta imot et User-objekt. Dette mappes til et HbnUser og sendes til Hibernate for å utføre innleggingen i databasen. Typene exceptions som kastes av repository vil være enten ENFE eller IAE. ENFE blir kastet i tilfellet der Hibernate ikke finner en entitet med en gitt id eller et annet kriterium. For eksempel i UserRepository.add(), som tar imot en User-modell. Denne modellen har blant annet en liste av Tags (Merk at disse objektene inne i modellen ofte bare har id). Dersom det er en eller flere tags som ikke 72

74 finnes, kastes det en ENFE. IAE kastes som regel når input ikke er gyldig. Figur 79. Alle repository har en lik struktur på metodene, men GroupRepository er noe mer omfattende. Dette er fordi Group-modellen har mange modeller den holder styr på, som Users, Tags og Documents. Det må sjekkes for om Gruppe-objektet har tags, dokumenter, brukere (veiledere, studenter). Hvis de ikke er null, kalles en get-metode som henter entitetene fra databasen basert på id. Studenter trenger ikke å eksitere for å kunne registrere en gruppe. De må legges inn i databasen hvis det er tilfelle. Dette gjøre addifnotexist(). Metoden gjør en prosess lik add() i UserRepository, bare at den sjekker om studenten eksisterer eller ikke basert på id. Merk at Gruppe-modellen har to separate lister for studenter og veiledere, i motsetning til HbnGroup som bare har et set av HbnUser. Figur

75 I update-metoder må bare objektet mappes og sendes inn som parameter til Hibernate sin updatemetode. Her må det også sjekkes om tags, dokumenter eller brukere faktisk eksiterer. Er det feil id vil en ENFE bli kastet. Figur 81. Metoden update I remove-metoder tas det kun id som parameter. Dette er alt Hibernate trenger for å utføre spørringen. Figur 82. Metoden remove Metoden remove tar imot en id og en boolean-variabel som parameter. Denne variabelen blir brukt til å tvinge slettingen til å bli utført. Dette ble implementert for situasjoner der en bruker er det siste medlemmet i en gruppe. 74

76 Figur 83. Metoden remove I metoden getquery hentes elementet basert på en Specification. Databasen gir tilbake en liste av entiteter basert på kriteriet i Specification-objektet. Hvert Hbn-objekt i listen må mappes til businessmodeller slik at applikasjonen kan bruke objektene. Figur 84. Metoden getquery (1/2) Alle studenter og veiledere er lagret som Users i databasen, det er kun relasjonen med Tag som sier noe om rollen til User. Derfor må det sjekkes etter Tag for å finne ut om den hentede HbnUser er en 75

77 student eller ikke. Før modellen returneres, må Links bli lagt til i objektet. Links kan leses om videre i punkt Links Figur 85. Metoden getquery (2/2) Metoden getminimalquery skal gi businessmodeller med mindre informasjon, dette den eneste informasjonen som er nødvendig for oversiktssidene i front-end. Det blir heller ikke lagt til noen andre entiteter i modellen. Kun informasjon om gruppen. Hvis front-end skal ha mer informasjon om for eksempel en bruker i gruppen, bruker de Links for å finne mer informasjon. 76

78 Figur 86. Metoden getminimalquery (2/2) Noen tags kan ikke slettes fra databasen, som konsekvens av at de blir brukt i andre metoder. Denne listen over de essensielle taggene er definert i TagRepository. Figur 87. Obligatoriske tags Dette blir brukt i en hjelpemetode for å se om taggene er lov å slette. 77

79 Figur 88. Metoden candelete Specification Spesifications er objekter med HQL-spørringer som brukes for å gjøre spørringer mot databasen. HQL baserer seg på SQL, men den største forskjellen er at det er mulig å referere til mapping-klassene i disse spørringene. Istedenfor FROM Document (faktiske tabellen i databasen), refereres mappingklassen direkte. Figur 89. Eksempel på en Specification 78

80 8.8.2 Front-end Oversikt Figur 90. Oversikt over front-end For å få en oversikt over klasseavhengigheter og struktur på komponentene se punkt Komponentstruktur og Modalstruktur LoginComponent Bak kulissene for innloggingsskjermen ligger det en AuthenticationService som brukes for validering av brukerinformasjon. Dersom brukerinformasjonen stemmer med en bruker i systemet vil det genereres et «JWT» som sendes tilbake. Dette tokenet inneholder informasjon om brukeren som er innlogget. Når en bruker logger inn lagres tokenet i nettleserens lokallagring, samt i en bakgrunnsservice. Figur 92 viser hvordan vi gjør et «request» av typen GET mot APIet, der vi bit64-enkoder brukernavn og passord og deretter gjør en mapping av responsen. Det vil si at responsen, i dette tilfellet, Figur 91. Skjermdump fra innloggingsskjema filtreres og de nødvendige operasjonene utføres for å hente ut tokenet og lagre det i servicen og local storage. Deretter returneres en respons på om tokenet finnes eller ikke. Dersom tokenet eksisterer vil brukeren navigeres videre til startsiden eller den opprinnelige siden brukeren forsøkte å logge seg på. public login( username: string, password: string ): Observable<boolean> { return this._http.get( AuthenticationService.LOGIN, { headers: new Headers( { 'Content-Type': 'application/json', 'Authorization': 'Basic ' + btoa( username + ':' + password ) } ) } ).map( ( response: Response ) => { let token = response.json() && response.json().token; if ( token ) { this.token = token; localstorage.setitem( 'token', token ); } return!!token; } ); Figur 92. Kode fra AuthenticationService 79

81 I tillegg kan man trykke på en link dersom man har glemt passordet. Denne linken åpner en modal, der man kan skrive inn mailen sin. Videre blir brukeren tilsendt en mail, som inneholder en link. Denne linken sender brukeren videre til en komponent for omstilling av passord PasswordResetComponent Figur 93. Skjermdump av modal "Glemt Passord" Applikasjonen tilbyr automatisk passordtilbakestilling. APIet har en funksjon som sender ut en mail til eieren av en konto, gitt at mailen er registrert i sammenheng med en konto. Denne mailen vil inneholde en link som fører brukeren til en del av applikasjonen som er låst bak en tokenvalidering. Figur 94. Skjema for "Bytt Passord" Sidemeny Linken i mailen vil ha et token på slutten av URL-en, som verifiserer for applikasjonen at riktig bruker prøver å tilbakestille passordet sitt. Tokenet som brukes har en tidsramme på 30 minutter før det går ut. Skulle tokenet være ugyldig eller ikke lenger aktivt, vil klienten dirigeres til innloggingsskjermen. Hvordan tokenet er bygd opp kan leses om i punkt Token. På de innloggede sidene i applikasjonen er det en sidemeny. Menyen henter elementene sine fra en konfigurasjonsfil. Konfigurasjonen er delt inn i kategorier, der hver kategori har et navn, en type (cssklasser), et ikon (css-ikon), et sett med menyelementer, en variabel for tilstand, et aksessnivå som sier hvem som har tilgang til område og om området er aktivert. I samme grad har hvert menyelement flere av de samme feltene, bortsett fra egne underelementer og en tilstand. Derimot inneholder de en URL. Denne URL-en brukes til å navigere applikasjonen. 80

82 export class NavigationCategoryModel { name: string; type: string; icon?: string; items: NavigationItemModel[]; state?: string; accesslevel: Access; enabled: boolean; } Figur 95. Konfigurasjonsfilens modell for kategorien export class NavigationItemModel { name: string; type: string; icon?: string; url?: string; accesslevel: Access; enabled: boolean; } Figur 96. Konfigurasjonsfilen modell for menyelement Figur 97 viser et eksempel på hvordan konfigurasjonsfilen ser ut. Denne konfigurasjonsfilen vil da gjengis i nettleseren som i Figur 98 export const NavigationItems: NavigationCategoryModel[] = [{ name: 'Grupper', //Displayed name of menu item type: 'list-group-item-heading', //Bootstrap css class for list items icon: 'fa fa-users', //Font Awesome icon state: 'in', //Default state of the menu item accesslevel: Access.BRUKER, //Access level needed to be displayed enabled: true, //Enabled items: [ { name: 'Oversikt', //Displayed name of child item type: 'list-group-item-action', //Bootstrap css class for list items icon: 'fa fa-list', //Font Awesome icon url: './gruppeoversikt', //URL to "Gruppeoversikt"-area accesslevel: Access.BRUKER, //Access level needed to be displayed enabled: true //Enabled }, { name: 'Mine Grupper', type: 'list-group-item-action', icon: 'fa fa-list', url: './minegrupper', accesslevel: Access.VEILEDER, enabled: true }, { name: 'Opprett', type: 'list-group-item-action', icon: 'fa fa-plus', url: './grupperegistrer', accesslevel: Access.ADMIN, enabled: true } ] }] Figur 97. Eksempel på en konfigurasjonsfil 81

83 Figur 98. Gjengivelse av konfigurasjonen i Figur 97 i nettleseren Når applikasjonen lastes inn sjekkes konfigurasjonen opp mot brukerens aksessnivå og om området er aktivert. Deretter loopes det gjennom konfigurasjonen og menyen gjengis i nettleseren. Menyen har to modi den kan veksles mellom. Synlig og delvis skjult. Når menyen er skjult vil hver kategori komme frem dersom man svever musepekeren over kategorien. s Figur 99. Kategori ved sveving av musepeker Elementer Forms HTML-forms blir brukt for å registrere. Videre vil disse bli referert til som skjema. Gjennom rammeverket Angular 2, er det mulig å legge til eller fjerne elementer i skjemaet på en dynamisk måte. Flere detaljer om dette finnes i punkt Forms i Angular 2. Denne dynamikken brukes i følgende registreringskomponenter: GroupForm AssignmentForm Tagform UserForm Hvert skjema er bygd opp med samme logikk. Gjennom dette kapitlet blir skjemaene i GroupFormkomponenten forklart i detalj. Denne logikken kan også anvendes til skjemaene til de resterende komponentene. 82

84 Figur 100. Skjermdump av GroupForm Formstrukturen Et skjema inneholder en itererbar kontrollstruktur. I koden blir denne strukturen initialisert gjennom en metode. Denne metoden klargjør feltene, deres valideringskontroller og startverdier, i skjemaet. Figur 101. Metoden initform Figur 102. metoden initstudent 83

85 Klassen Validators inneholder en rekke metoder for valideringer av felter i et skjema. Blant annet om et felt er et krav, eller om feltet må følge et regulært uttrykk. Skjemaet har i tillegg en variabel som angir om verdiene i skjemaet er i samsvar med valideringen. I HTML-koden blir dette brukt til å deaktivere registreringsknappen ved å binde verdien til et HTML-attributt [disabled]="!myform.valid". I skjemaet er det brukt FormArrays og FormGroups. FormGroup brukes for å lage et objekt ut ifra all dataen som er skrevet inn. Dette gjør at vi kan relatere oss til objekter når vi itererer gjennom dataen i et skjema. FormArray er et array brukt innenfor skjemaet og fungerer som et array for verdier i skjemaet. Dette kan være ønskelig når man skal ha flere identiske sett med inputfelter og ønsker å ha kontroll over disse. Figur 101 inneholder følgende skjema: FormGroup (samler all data til et objekt) o name, navnet til gruppen o assignment, IDen for valgt oppgave o supervisors, FormArray som inneholder IDene til alle veilederne som er valgt o students, FormArray som inneholder alle studentene som er valgt (både eksisterende og nye studenter) o tags, FormArray som inneholder IDene til de tags som er valgt for gruppen. Figur 102 viser metoden initstudent, som brukes i FormArray «students». Dette er initialiseringen som behøves for å lage registertingsstrukturen til en student. Den har samme oppbygning som metoden initform, men med andre felter spesifikk for en student. Kallet på initialiseringen ligger her fordi det skal alltid være minst 1 student som skal lagres i en gruppe Endring av skjema Skjema er dynamisk dette betyr at det kan legges til eller fjernes elementer ved behov. I grupperegisteringen kan man legge til eksisterende eller nye studenter til gruppen. Figur 103. Legg til ny eller eksisterende student i grupperegistreringen. Figur 103 viser til to valg for å legge til studenter: 1. Trykke på «Ny student» 2. Trykke på «Legg eksisterende student», valgt minst 1 student og til slutt trykker «Bekreft» 84

86 I begge tilfeller vil metoden addform kjøres. Det er en generisk metode for å legge til felter i skjemaet. Dette kan være i form av ny student, veileder, oppgave eller tag. Metoden tar imot en parameter for hvilket felt som skal utvides. Figur 106 viser hvordan metoden håndterer parametere, og deretter utvider skjema. I det tilfellet der student utvides, blir det også injisert et userformcomponent i HTML-koden. Se punkt Brukerregistrering. Figur 104. To UserFormComponent Figur 105. Øvre del av grupperegisteringen Figur 106. Metoden addform 85

87 For å få tak i de forskjellige delene av et skjema brukes «controls». Figur 107 viser hvordan vi kan legge tags til et studentskjema via studentcontrol.controls[ tags ]. Legg merke til at man er nødt til å navigere gjennom flere kontrollstrukturer. Figur 107. Hvordan finne tags til en student i en gruppe. For å gjøre dette deklareres tre konstanter som er avhengige av hverandre Konstanten «control» er kontrollstrukturen «students», dette er en FormArray med skjemaene til studentene. Neste nivå i kontrollstrukturen legges i konstanten «studentcontrol». Denne kontrollstrukturen er strukturen til den siste studenten som ble lagt inn i skjemaet. Til slutt blir deklareres konstanten «tagscontrol» gjennom studentcontrol.controls[ tags ]. I denne kontrollstrukturen kan en students tags patches inn i skjemaet Lagring av skjema Metoden save brukes for å konvertere skjemaet til JSON-format, og deretter sende dette til APIet gjennom HTTP-POST. Metoden gjør følgende: 1. Nye studenter får årets tag og tagget student. 2. En modell for gruppen blir bygd opp med data fra skjemaet 3. Sender modellen til APIet via klassen httpservice 4. Behandler respons fra APIet. 86

88 Figur 108. Utsnitt fra metoden save. Viser håndtering av HTTP-respons Ved oppdatering av en gruppe brukes den samme komponenten som ved registering av en gruppe. Hvis komponenten oppdager at den åpnet med en gruppe, vil metoden save bruke HTTP-PUT isteden. En gruppe kan endres ved et trykk på endreknappen. Da blir URLen endret fra /bm/gruppeoversikt/ til /bm/gruppeoversikt/:id. Det siste leddet i URLen er IDen til en gruppe. Dette blir sjekket i metoden checkurl, som kjøres i metoden ngoninit. Figur 109. Metoden checkurl Figur 109 viser metoden checkurl. Hvis URLen inneholder en parameter id, hentes informasjonen om gruppen. Deretter blir metoden fillform kalt, som tar resultatet av spørringen og «patcher» verdiene inn i feltene som ligger i siden for grupperegistrering. Figur 110 viser hvordan en gruppe patches inn i skjemaet. 87

89 Figur 110. Metoden fillform Til forskjell fra gruppe, registreres og oppdateres bruker gjennom oversiktssiden. Ved å trykke på endreknappen, åpnes en modal med utvidet informasjon om brukeren. Modalen får informasjonen gjennom en referanse til modalkomponenten som vist i Figur 111. Denne referansen hentes gjennom metoden open fra klassen NgbModal. Figur 111. Metoden openuser 88

90 Figur 112. Metoden patchform Figur 112 viser hvordan RegisterUserComponent får sine verdier patchet inn i skjemaet. Denne komponenten er modalen som åpnes når endreknappen, eller «ny bruker»-knappen trykkes. Metoden sjekker om det er en bruker som er sendt med og endrer skjemaet ved å patche inn verdiene. Deretter setter editmode til TRUE for å indikere at det er en bruker som skal oppdateres når metoden save kalles på Tags Tags brukes til å beskrive modellene gruppe, bruker og oppgave. Dette er for å kunne skille mellom de forskjellige modellene i registrerer og gjør det mulig å søke gjennom systemet via tags. Taggene fargekodes slik: Brukertaggen har fargen gul. Studenttaggen har fargen grønn Veiledertaggen har fargen rød 89

91 Resterende tags er grå Disse er fargetkodet slik for å bli lett kunne identifisere brukerroller i applikasjonen. De resterende tagsene spiller en større rolle i søk, og er derfor fremhevet i lik grad. Idet en tag velges, blir den lagt til venstre i søkefeltet. Ytterligere tags som velges legges til høyre for den opprinnelige taggen. Dette er et design man ser brukt på store sider som for eksempel StackOverflow. Avhengig av hvilken oversikt som er aktiv, vil kun relevante tags søkes på. Figur 113. Velge tags Søk For å kunne finne ønsket gruppe, bruker eller tags har vi implementert forskjellige søk-funksjoner i oversiktene og registeringene. Søking fungerer likt i alle oversiktene med unntak av tagoversikten. Figur 114. De generelle søkefeltene for gruppe og bruker Figur 114 viser søkefeltene som brukes i både gruppe- og brukeroversikt. Det første feltet søker etter bruker eller gruppers navn. Søkefeltene bruker lyttere til å reagere på endringer i søkefeltene. Det er lagt til en debouncer som gjør at søket blir utsatt inntil det ikke har kommet nye endringer på 500ms. I Figur 115. Eksempel på lyttere tillegg er det en metode distinctuntilchanged som gjør at søkingen bare skjer når en endret verdi oppdages. Både søket på navn og tag bruker en metode av to metoder, filterusers eller filtergroups, basert på hva som søkes på. Parameteren som tas inn i metoden er hentet fra første søkefelt. Når man søker på navn, vil metoden også ta hensyn tags. Dersom tags er valgt, via «søk tags»-feltet, vil kun disse tags bli hentet fra APIet. Når det skrives i «søk tags»-feltet, filtreres en array med tags. Filtreringen utelukker alle tags som ikke inneholder søkestrengen. Deretter kan en tag velges, og et søk utføres. 90

92 Figur 116. Metoden filtertag Figur 117. Filtrering av tags det er mulig å søke på. Søk på brukere/grupper via tags skjer på akkurat samme måte som ved navn. En søkestreng blir generert etter taggene som har blitt valgt som ligger i en array, og via en HTTP.get får vi tilbake alle brukerene/gruppene som inneholder disse. Et typisk brukersøk mot APIet ser slik ut:. Responsen filtreres deretter på den gitte inputen. Figur 118 viser hvordan dette fungerer i kode. Figur 118. Metoden filterusers Tagoversikten har en egen variant av søket. Dette søket baserer seg på navn og tagens type. Typen velges i en flervalgsmeny. Figur 119. Søkefeltene i tagoversikt 91

93 Tilbakemeldingsvinduer Applikasjonen kommuniserer ofte med et API. For brukeropplevelsen er det viktig å gi tilbakemeldinger når en handling utføres. Vi har dermed valgt å ha to modaler for å vise noen av disse meldingene fram: Confirm og Warning modal. Gjennom referansen til en modal kan man lytte på en Promise. Success returneres hvis brukeren av applikasjonen har trykket på «Ja» og fail hvis «Nei» er trykket på. For warning-modal er det ikke satt en lytter, da responsen ikke blir tatt i bruk. Figur 120. Hvordan en modal åpnes og resultatet anvendes Confirm-modal Denne modalen brukes når noe skal slettes eller der applikasjonen trenger tilbakemelding fra brukeren. Et spesialtilfelle der modalen får ett ekstra alternativ, er når en fil skal lastes opp fra filsystemet og det allerede eksisterer en fil med samme filnavn. Figur 122 viser Figur 121. «Confirm modal» når en bruker skal slettes dette tilfellet. her er det to resultater som befinner seg i success-responsen. Responsen kan enten være «Confirm», «Change» og for reason gjelder bare «Declined». Figur 122. Muligheten til å overskrive en eksisterende fil 92

94 Warning-modal Figur 123. Hvordan warningmodal brukes Modalen warning brukes når en liten melding skal informere brukeren om hva som har skjedd. Tilfeller som fullført registrering eller lagring er eksempler på dette. Modalen viser en melding der man kan enten trykke «Ok», escape knappen eller kryss for å fjerne meldingen. Det eneste som trenger å konfigureres er melding og tittel hvis ønskelig. Tittel har «Advarsel!» som default verdi og kan endres enkelt via modalref.componentinstance.title = Ny tittel Servicer Servicer er tjenester tilgjengelige for alle komponentene i front-end. Noen av serviceklassene gjør spørringer direkte mot APIet, der andre er for å utføre oppgaver internt på front-end. Alle serviceavhengigheter til en komponent blir initialisert i komponentens kontruktør Figur 124. Konstruktøren i group-view.component.ts AlertService Klassen AlertService blir brukt til å gi tilbakemeldinger til brukeren av applikasjonen. Denne anvendes der man vil gi en rask tilbakemelding, heller enn å stoppe brukeren med en advarselsmodal. Selve meldingen blir presentert i AlertComponent, men man kan velge å bruke servicen uavhengig. Figur 125. Eksempel på en alert 93

95 Servicen inneholder to metoder for å kringkaste meldingen til sine lyttere. En for success-meldinger, og en for error-meldinger. Begge metodene tar imot en melding og en boolean-verdi som parameter. Den boolske verdien bestemmer om meldinger skal persistere mellom ruternavigeringer. Figur 126. Metodene success og error Figur 127. Når en årstag slettes AuthenticationService AuthenticationService håndterer alt relatert til innlogging og aksesskontroll. Denne servicen bruker tokens for å holde styr på hvem som er innlogget. Mer om innlogging LoginComponent. Når en bruker logger inn, kjøres metoden login. Metoden tar imot brukernavn og passord og gjør deretter et kall til APIet. Figur 128. Metoden login 94

96 Hvis GET-responsen returnerer et token, blir tokenet satt inn i nettleserens lokallagring. Deretter returnerer metoden true som indikerer en vellykket innlogging. Andre metoder som ofte blir brukt er metodene accesslevel og enterpriseid. For eksempel brukes accesslevel for å sjekke om visse elementer i grensesnittet er tilgjengelig for den innloggede brukeren. EntrepriseID kan brukes for å Figur 129. Metodene accesslevel og enterpriseid den innloggede brukerens grupper, dersom brukeren er en veileder. Disse metodene bruker en hjelpeklasse som dekoder tokenet for å få ut nødvendig informasjon. Metoden updatepassword blir brukt når bruker skal oppdatere passordet sitt Dette gjøres via en HTTP.post mot følgende URL-sti '/bm-rest-api/api/password'. Figur 130 viser metoden uppdatepassword. Figur 130. Metoden updatepassword DefaultYearService DefaultYearService er en serviceklasse som har to metoder: checkyear og addthisyear. Metoden checkyear gjør et søk til APIet, om databasen inneholder en års-tag for gjeldene år. Dersom det ikke er et tag for gjelende år, vil metoden addthisyear legge til en tag for året. Figur 131. Metodene checkyear og addthisyear 95

97 Servicen brukes I bruker- og gruppeoversikten. Grunnen til at servicen er nødvendig i disse komponentene er fordi bruker og gruppe er avhengig av års-tagg i registreringsprosessen EventService EventService brukes til å holde styr på events. Eventer blir lagt til i en liste og har muligheten til å bli broadcastet via en metode «broadcast». Figur 132. Et eksempel på broadcast Bildet ovenfor bruker servicen for å broadcaste en event med en tekst «request offset». Alle andre komponenter som lytter på «request offset» vil da reagere på dette signalet og kunne uføre handlinger basert på signalet. Lyttingen skjer via listen() funksjon som tar imot en EventModel som inneholder navn og data. Via parameteret blir event en lagt inn i en array for å kunne ha bedre kontroll over dem. Denne listen oppdateres ved å tømme den når en komponent ikke lenger er aktiv. Figur 133. Metoden listen Servicen brukes ofte for å kringkaste når en funksjon eller et view er ferdig med utførelsen av sin handling GUIDService GUIDService brukes bare i EventServicen for å genere «Globally Unique Identifier». Denne ID en vil være unik globalt i prosjektet og vil aldri kollidere med andre Id er. Hver eneste lytter som blir laget av EventService vil ha en generert ID fra denne servicen. Dette skjer via metoden getnewguidstring som generer IDen ut fra de standarder som gjelder for GUID. 96

98 Figur 134. Metoden getnewguidstring FileService FileService brukes for opplasting og oppdatering av filer. Forskjellen her er at AuthHttp ikke blir brukt men bare Angulars kjerneklasse HTTP. Dette gjør at vi selv kan definere hvilke headere som skal brukes i HTTP-kallet. Metoden uploadfile har flere parameter: selve filen, tags og en forced variabel som forteller APIet å ignorere duplikatsikringen for filer. Et eksempel på dette er når en fil allerede eksisterer, men det er ønskelig å lage 2 filer med samme navn. Basert på metodeparameterne blir det generert en URL. Denne vil inneholde IDen på mappen filen skal lastes opp i, samt navn på eventuelle tags. Variabelen forced legges til som siste element i URLen. Figur 135. Metoden uploadfile Som bildet viser er det en ekstra Headers som blir generert med token fra authenticationservice. Et eksempel på hvordan pathen kan se ut er /files/upload/0byi1hjm5emifcxrtsvplqmjyja?tags=oppgave&tags=2017&forced=false. Her opplastes en fil i mappen med id 0ByI1HjM5emiFcXRtSVplQmJ6YjA der den skal ha taggene «oppgave» og «2017». Metoden updatefile gjør det samme, men kjører en HTTP.PUT og bruker ID på filen istedenfor parent. Metoden brukes for å oppdatere fil i to tilfeller: 97

99 1. Når en fil lastes opp fra filsystemet og filnavnet eksisterer fra før av. Hvis brukeren velger å overskrive filen med et samme navnet så blir updatefile() metoden kjørt. 2. Når en fil blir åpnet i editor og oppdatert med nytt innhold, filnavn eller tag HttpService HttpService er en av de mest brukte servicene. Dette er hovedsakelig fordi den brukes til å sende kall for oppretting, henting, endring og sletting mot APIet. For å gjøre disse kallene brukes en klasse, AuthHttp, som legger til tokenet til den innloggede brukeren inn i hvert eneste kall. Servicen fungerer ved at vi gjør et kall mot et API som har en slik rot: ' Denne roten kan bygges videre på for å aksessere ulike ressurser. Utbyggingen skjer ved å bruke metoden seturl. Figur 137 viser konfigurasjonsfilen, de forskjellige utbyggingsstiene blir definert. Denne konfigurasjonen er global og kan brukes i alle komponenter. Det er mulig å gjøre en spørring mot de forskjellige stiene. Alle spørringene returnerer et respons-objekt som pakkes i en Observable. Dette gjør at resultatet av spørringen kan bli lyttet på via en subscribe-metode. Dette gir muligheten til å håndtere responsen Figur 136. Filen Base.ts asynkront. Før en spørring gjøres i metodene add og update, blir dataen oversatt til JSON-format. De andre metodene trenger ikke noen formatering siden de skal hente eller slette data Get Metoden get anvender HTTP-GET til å hente data fra APIet. Denne metoden kan ta imot en id og en boolean-verdi. Verdien bestemmer og responsen skal dekodes fra JSON til en modell. Hvis en id blir sendt med, vil metoden etterspørre et spesifikt objekt. Figur 137. Metoden get 98

100 For eksempel en HTTP-GET mot ' finne brukeren i applikasjonen med id lik 2. Dette vil bli returnert som JSON-objekt Add Metoden add anvender HTTP-POST til å registrere de forskjellige objektene i applikasjonen. Parameteren som tas inn kan være en oppgave, gruppe, bruker eller tag. Det som returneres i en HTTP-POST er et responsobjekt. Figur 138. Metoden add Update Metoden update anvender HTTP-PUT til å oppdatere en gruppe, oppgave, tag eller bruker. Dette er basert på hvordan URL-en ser ut. Hvis det kjøres en HTTP-PUT mot ' blir gruppen med ID lik 21 oppdatert med parameterverdien. Responsen fungerer på lik måte som i metoden add. Det er mulig å hente ut statuskode og et eventuelt entitet-objekt. Figur 139. Metoden update Slettmetoder Metodene remove og deletefolderfile bruker HTTP-DELETE for å forespørre en sletting i databasen. Om en mappe har innhold er det nødvendig å fortelle metodene at den skal overse duplikatsikringen. Se Filsystemet. Figur 140. Metodene remove og deltefolderfile 99

101 CreateFolder En annen metode som sender data til APIet er metoden createfolder. Denne metoden brukes for å lage mapper innenfor filsystemet. Logikken for dette, ligger i filsystemkomponenten. Figur 141. Metoden createfolder Editor Figur 142. Editorsiden Editorsiden er bygd opp av to inputfelter og en editor. Editoren er hentet fra et bibliotek som gjør det mulig å konfigurere den med de egenskapene som er ønskelig. Se punkt TinyMCE, for mer informasjon om editoren. For å lagre en oppgave kreves det tittel, tags og innhold. I metoden save blir innholdet hentet fra editoren og pakket inn i «<html>»-tags. Alt som blir skrevet innenfor editoren kommer ut som HTML og blir sendt videre til APIet som en HTML-fil. For å få tags sendt til APIet blir de valgte tags lagt til i en array som inneholder deres IDer. Til slutt blir en fileservice brukt for å laste opp filen til APIet. 100

102 Figur 143. Metoden save Editoren brukes også til å endre tekstfiler åpnet fra filsystemet. Denne prosessen skjer via metoden open i filsystemet. Først sjekkes det om filen har tags. Eventuelle tags legges i et array. Deretter navigeres det til området bm/editor. I tillegg sendes filen med sin id, arrayet, og filens navn. Figur 144. Metoden open Metoden ngafterviewinit sjekker om den aktive linken har parametere. Når en fil blir åpnet har URLen følgende format bm/editor/:id, der id er en parameter som kan brukes for å hente informasjon om filen. Dette inkluderer tags. Taggene og tittelen vil bli patchet inn i inputfeltene, mens selve innholdet i filen blir åpnet i editoren. 101

103 Figur 145. Metoden ngafterviewinit Filsystemet Filsystemet i applikasjonen er basert på Google Drive. Dette er gjort fordi det faktiske filsystemet applikasjonen bruker er Google Drive. Ved å representere dataen tilsvarende Drive, har det ikke vært nødvendig med konvertering i APIet før det kommer til front-end. Filsystemet slik det ser ut er bygd opp i tre lag. Først har man navigasjon, deretter kommer mapper og til slutt vises filer. 102

104 Figur 146. Annotert filsystem Første nivå består av tre knapper og brødsmuler som viser hvor klienten befinner seg i filsystemet. Tilbakeknappen er tilstede for å navigere ett steg tilbake i filsystemet. Tilbakeknappen og brødsmulene ( ) deler funksjon, så samme prosess gjøres når de trykkes. Knappen baserer seg ikke på en ID, og sender derfor null som parameter. Dette trigger at det øverste elementet i listen blir fjernet, og nest siste blir hentet ut og jobbet med. Brødsmulene jobber direkte med IDen til mappen. Dette gjør at man kan hoppe flere steg tilbake med kun ett trykk. Knappen «Ny mappe» setter i gang en prosess med å lage en ny mappe i filsystemet. Figur 147. metoden previousfolder 103

105 Figur 148. Metoden toggleinput Først åpnes en modal som inneholder et inputfelt brukeren kan skrive inn navnet på den nye mappen. Figur 149. Modal ny mappe Når brukeren har tastet inn navnet og trykket på «Opprett» sendes navnet videre til en ny metode som gjør en forespørsel mot applikasjonens API. 104

106 Figur 150. metoden createfolder APIet gir en respons basert på en sikkerhetsmekanisme forklart i punkt Serviceklasser. Hvis responsen har status 300, betyr det at en mappe med samme navn allerede eksisterer på samme nivå i filsystemet. Brukeren vil da bli spurt om å bestemme hva som skal gjøres. Det er lov å opprette mapper med samme navn, men det må godkjennes slik at brukeren er klar over det. Det vil ikke være noe problemer i forhold til overskriving da Google Figur 151 modal Ny mappe eksisterer 105

107 Drive ikke jobber ut fra navn, men en unik ID på hver fil. «Last opp fil» er den siste knappen man ser i filsystemet. Blir den trykket på får man opp et vanlig vindu for å velge en fil. Etter at filen er valgt, blir den sendt opp imot applikasjonens API. Det vil bli gjort en liknende sikkerhetssjekk på APIet som når det lages en ny mappe. Hvis filen allerede eksisterer, kan man velge å overskrive denne. Figur 152 Modal fil med samme navn eksisterer Brukeren er, som med mapper, ikke låst til å ha unike navn for filene. Brukeren blir derimot stilt spørsmålet om det er ønskelig å overskrive den eksisterende filen eller lage en ny fil med samme navn. De to neste nivåene har en del til felles. Hver for seg representerer de to forskjellige entiteter: mapper og filer. Begge har sin egen kontekstmeny assosiert meg seg. Kontekstmenyen plasserer seg basert på hvor musepekeren er på skjermen idet den åpnes. Høyreklikk åpner kontekstmenyen for mapper, men for filer åpnes den ved begge museklikk. Innholdet i kontekstmenyen bestemmes av aksessnivå og eier av objektet. En administrator vil alltid kunne slette alle mapper og filer, imens en bruker kun kan slette de den har lagd selv. Spesielt for filer er at tekstfiler (.docx) kan åpnes i applikasjonens editor. Dette kan kun administrator og eier av filen gjøre. Figur 153. Kontekstmeny mappe, Fil 1 og Fil 2 Figur 153 viser hvordan kontekstmenyene gir brukeren valg. Mer detaljer om hvordan kontekstmenyen er bygd kan leses i punkt Kontekstmeny. Ved å åpne en mappe vil alt innhold i den mappen bli lastet inn i applikasjonen. Hvis man ønsker å slette en mappe, så er det lagt en beskyttelse i APIet slik at man ikke kan slette ved en feil. Hvis en mappe har innhold, blir brukeren gjort oppmerksom på dette ved hjelp av en modal. 106

108 Kontekstmeny Kontekstmenyen er en komponent ment for å erstatte kontekstmenyen i nettleseren. Den skal kun gi relevante valg i forhold til objektet den trigges på. Applikasjonens filsystem hadde behov for kunne ha egendefinerte valg på utvalgte objekter. Etter kontakt med to UX-designere fra Accenture falt valget på en kontekstmeny. Oppbyggingen av komponenten baserte seg på transclusion, som hovedsakelig er kobling av et annet dokument via en hypertekst referanse. På grunn av det kan komponenten bygges opp der den skal brukes, noe som i dette tilfellet lot oss holde kodelinjene til et minimum for selve kontekstmenyen. Figur 154. bruk av kontekstmeny Plasseringen av komponenten tar utgangspunkt i hvor musepekeren befinner seg. Objektet som vises på skjermen bygges i positiv x- og y-retning relativt til musepekeren. Oppgavene komponenten skal gjøre inkluderer plassering, åpning og lukking av kontekstmenyen. For å unngå at flere menyer åpnes samtidig har det blitt lagt til en åpningsprosess på kontekstmenyen. I 100 millisekunder vil den være i åpningsstatus. Alle andre kontekstmeny-komponenter vil da bli lukket. Figur 155 bygging i x- og y-retning i browser 107

109 Figur 156. metodene show og outsideclicked Linken i mailen vil ha et token på slutten av URL-en, som verifiserer at riktig bruker prøver å tilbakestille passordet sitt. Tokenet som brukes, har en tidsramme på 30 minutter før det er ugyldig. Skulle tokenet ikke lenger være aktivt, eller vært ansett som ugyldig, dirigeres klienten til innloggingsskjermen. Hvordan tokenet er bygd opp, kan leses om i punkt Token. 108

110 Gruppeoversikt Figur 157. Gruppeoversikt GroupViewComponent er en oversikt over alle gruppene i systemet. Oversikten er det som oftest de første siden det navigeres til etter innlogging. Dette er oversikten med høyest konsentrasjon av informasjon med verdi for en bruker. I tillegg har oversikten søk via navn og tags, forklart i Søk og mailfunksjon forklart 8.7 Mailsystem. Oversikten fungerer sånn at når komponenten startes kjøres det en HTTP-GET på grupper som da vises i HTML-koden. Når oversikten lastes inn, hentes store mengder data fra databasen. Mange av metodene er avhengig av denne dataen, denne dataen hentes asynkront. Observable.forkJoin() benyttes derfor for å unngå synkroniseringsfeil. Det vil si at alle funksjonene i denne metoden venter til den siste funksjonen er ferdig med sitt arbeid. 109

111 Figur 158. Eksempel på metoden forkjoin Oversikten blir også brukt til å vise en veileders grupper. Da vil metoden checkifsupervisor returnere «true» og kjøre metoden filtersupervisorgroup som gir en liste med gruppene til veilederen. Ellers vil alle gruppene i applikasjonen listes ut. HTML-koden vil ta objektene i listen displaygrouplist og vise deres innhold i form av kort. Figur 159 viser koden som genererer et kort for en gruppe i oversiktssiden. 110

112 Figur 159. Hvordan gruppekortene blir generert Funksjoner Sletting av gruppe Figur 160. Et gruppekort med slettknappen ringet rundt Ved å trykke på slettknappen, på et gruppekort, vil metoden deletegroup kjøres. Metoden tar imot gruppens id og navn. En confirm-modal ( Confirm modal) åpnes, der det blir forespurt om man ønsker å slette gruppen. Slik at man ikke sletter ved feil. Hvis confirm-modalen returnerer et success, vil metoden remove kjøres. Når resultatet av HTTP kallet er tilbake og statusen er 204, blir listen oppdatert og gjengitt på nytt i viewet. Samtidig vil brukeren få respons via alertservice en. 111

113 Figur 161. Metoden deletegroup Endring av gruppe Figur 162. Et gruppekort med endreknappen ringet rundt Endreknappen er tilgjengelig for administratorer. Dette navigerer, gjennom metoden groupclicked, til et nytt område som viser informasjon om en gruppe i systemet. Det kjøres da en metode, groupclicked, som tar inn ID til gruppen. Komponenten blir forklart i kapittelet GroupForm Preview av gruppe Figur 163. Metoden groupclicked En egen komponent blir brukt for å vise utvidet informasjon om en gruppe uten å navigere ut av oversikten. GroupInfoComponent ligger innenfor hvert eneste gruppekort og blir bundet sammen med gruppen via <bm-group-info #groupinfo [groupid]="group.id"></bm-group-info> Figur 164. Mer info om et gruppekort 112

114 For å åpne den utvidede informasjonen om gruppen kan man trykke må det blå området i et kort. Dette gjør et kall til metoden togglegroupinfo.. Ved første åpning av et kort vil utvidet informasjon om gruppen hentes fra APIet og caches i komponenten. Ved flere åpninger vil den cachede informasjonen brukes for å redusere antall kall til APIet. Det Figur 165. Metoden togglegroupinfo er lagt en settimeout for å gi tid til den visuelle oppdateringen GroupForm GroupForm er den eneste siden for registrering som ikke er en modal. Dette kommer av at størrelsen på skjema for å registrere en gruppe, ikke er egnet for en modal. Her velges tag på samme måte, som det har blitt forklart i 8.6 Tag-system. Figur 166. Side for grupperegistrering 113

115 Registeringssiden er tilgjengelig gjennom sidemenyen og inneholde følgende: Input for gruppenavn (required) Select for en eller flere veiledere Select for en oppgave Studenter (minst én) o Input for fornavn (required) o Input for etternavn (required) o Input for epost (required) o Input for enterpriseid (det som er required må fylles inn før en kan registrere en gruppe) Figur 167. Metoden initform Som nevnt i Endring av skjema, brukes denne komponenten også til endring av gruppe. Under initialisering, kjøres metoden checkurl. Denne sjekker om den aktive ruten har noen parametere. Hvis dette er tilfellet hentes informasjon om gruppen og patches inn i skjema gjennom metoden fillform. En modell av gruppen blir også lagret. Denne modellen kan oppdateres og sendes tilbake til APIet. Figur 168. Metoden checkurl Knappen for å registrere informasjon er deaktivert, til alle påkrevde felter er fylt inn med gyldige verdier. Figur 169. En gyldig og ugyldig 114

116 Figur 170. Metoden save Sjekken på om de nødvendige feltene er fylt inn og om de er gyldige skjer via forms. Dette er beskrevet tidligere i kapittel Formstrukturen. Når all gyldig data er fylt inn og registreringsknappen trykkes kjøres metoden save. Metoden gir først nye studenter i gruppen tags: årstag og student. Dette skjer via metoden givedefaulttag, som patcher alle studentenes tags i formen. Se punkt Endring av skjema for forklaring av patching. Etter dette må skjemaet gjøres om til en GroupModel gjennom metoden createformbody. Dette er for å kunne konvertere skjemaet til JSON, og deretter sende det til APIet. Hvis en gruppe allerede er åpnet, brukes HTTP-UPDATE. Denne sender den gruppemodellen og oppdaterer den. HTTP-ADD 115

117 blir kjørt dersom ingen gruppe er aktiv. Dette vil registrere den nye gruppen. I begge tilfeller sjekkes statusen på responsen. Hvis verdien har status 200 eller 201, betyr dette at innlegge gikk bra. Så gir applikasjonen tilbakemelding via en WarningComponent Funksjoner Legge til eksisterende studenter Figur 171. Legg til eksisterende studenter Når knappen trykkes åpnes modalen AddStudentComponent, som viser alle studenter fra nåværende år som ikke er knyttet til noen grupper. Idet knappen «Bekreft» blir trykket, returnerer modalen alle studentene som har blitt valgt og «patcher» skjemaet. Figur 172. Valg av eksisterende studenter modal Skjemaet vil da få ett nytt UserFormComponent for hver eneste student, og samtidig knytte seg til hovedformen som ligger i GroupFormCompoent. Dette gjøres ved at for hver av de valgte studentene, blir det lagt til ett sett med inputfelter. Deretter patches informasjonen fra studentene inn. Figur 173 viser koden som utfører dette. 116

118 Figur 173. Metoden showexistinguser Legge til nye studenter Figur 174. Knapp - Legg til ny student en gruppe. Mer om metoden i Endring av skjema. Knappen i Figur 174 brukes for å legge til et nytt studentskjema i skjemaet til 117

119 Velge veiledere Figur 175. Valg av veiledere Veiledere som kan velges må ha en «Veileder»-tag. De hentes fra APIet i initialiseringsprosessen av klassen. Når en veileder blir valgt via «Select»-feltet kjøres en metode som legger veilederen inn i en liste. Figur 176. Hvordan de røde veileder "knappene" blir lagd Krysset på veilederen kan trykkes for å fjerne den fra skjemaet. Dette gjøres ved et kall på metoden removeform Velge oppgave Oppgavene hentes fra APIet, og filtreres slik at en gruppe ikke kan velge en annen gruppes oppgave. En oppgave som har links til en gruppe, anses å allerede være delegert. Valget av oppgavene skjer via en «dropdown», der oppgaver vises i en alfabetisk rekkefølge. Dette gjør det enklere å finne en oppgave. Figur 177. Velge oppgave i grupperegistrering Figur 178. Filtrering av oppgaver i group-form.component.ts 118

120 Brukeroversikt UserViewComponent er oversikten over alle brukere i systemet. Brukerne i systemet kan tilordnes aksessnivåene administrator, veileder, bruker, eller student. En student vil aldri tilordnes en konto, men brukes som en informasjonskapsel. I likhet med gruppeoversikten brukes en forkjoin-metode for å sørge for at asynkrone kall til APIet fullføres før siden lastes inn. Figur 179. Brukeroversikt Kortene er bygd opp av en liste med brukermodeller og Figur 181 viser hvordan kortene genereres. Brukeroversiktene har søk på navn og tags ( Søk), så det er mulig å finne spesifikke brukere. Søket vil da filtrere listen, og deretter generes kortene på nytt. Kortene viser også hvilke tags en bruker har. Figur 180. Tags for en bruker 119

121 Figur 181. Hvordan brukerkortene blir generert Funksjoner Ny bruker Figur 182. «Ny bruker»-knappen i brukeroversikten For å legge til en ny bruker trykkes knappen i Figur 182. Denne knappen ligger i brukeroversikten, da den kun åpner en modal. Når knappen trykkes kjøres metoden openuser, som tar inn en bruker som parameter. Dersom metoden utføres uten parameter, åpnes en RegisterUserComponent. Dette er en modal for å registrere brukere. Mer om denne komponenten kommer i Brukerregistrering. 120

122 Figur 183. Metoden openuser Endre bruker Figur 184. Brukerkort med endreknappen ringet rundt Når endreknappen trykkes, kjøres samme metoden som kjøres når en ny bruker registreres. Metoden openuser vil nå bli kjørt, men med en bruker som parameter. Gjennom referansen til modalkomponenten, injiseres brukeren. RegisterUserComponent vil da få patchet verdier inn i inputfeltene som kan endres Slette bruker Ved å trykke på sletteknappen kjøres metoden opendeletemodal. Denne åpner en ConfirmModal ( Confirm Modal), som ber om bekfreftelse på om brukeren skal slettes. Dette er for å ungå feiltagelser ved sletting. 121

123 Figur 185. Confirm Modal når en bruker slettes Hvis «Nei» velges, beholdes brukeren. Blir «Ja» valgt, sendes det en HTTP-REMOVE request som sletter brukeren. Tilbakemeldingen fra dette kallet brukes til å sjekke om brukeren ble slettet eller om han er den siste i en bachelorgruppe. Hvis brukeren ble slettet er statusen 204 og man får en enkel tilbakemelding på at brukeren er slettet, men hvis statusen er 300 betyr dette at brukeren som slettes er den siste i en gruppe. Figur 186.Metoden deletegroupanduser 122

124 Figur 187. Metoden opendeletemodal I tilfeller der statusen er 300, kjøres metoden deletegroupanduser. Metoden tar inn brukeren og feilmeldingen fra statusen. En ny Confirm Modal kommer opp og viser meldingen. Hvis «Ja» er valgt blir både gruppe og bruker slettet via en deleteuser() og deletegroup() metode. Alternativet «Nei» vil beholde Figur 188. Confirm Modal når bruker slettes og er siste i en bruker begge Brukerregistrering RegiststerUserComponent blir presentert i en ng-modal (se Ng-modal). Det som er spesielt med komponenten, er at den i seg selv er bare en ramme som går rundt en UserFormComponenten. UserFormComponenten er en modulær komponent som blir brukt i RegisterUserComponenten og i GroupFormComponenten nevnt i Legge til eksisterende studenter. 123

125 UserFormComponent sitt utsende er ett sett med inputfelter for brukere, samt et felt for å velge tags som brukeren skal få. Måten tags fungere på er forklart ved 8.6 Tag-system Figur 189. Innholdet av en UserFormComponenten Figur 190. form inputten i user-form.component.ts Komponenen og den forelders skjema bindes gjennom et enveisbindingsdirektiv fra Angular. Denne koblingen ser slik ut: <bm-user-form [myform]="myform"></bm-user-form>. Bm-user-formtagen er selectoren til UserFormComponent. Denne kan plasserer der du vil ha et skjema for en bruker. Figur 191. Registerer bruker Når en bruker registreres, brukes skjema vist i Figur 192. Denne inneholder fornavn, etternavn, , telefon, enterpriseid og tags. Det er bare fornavn, etternavn og som er påkrevd for at registreringen skal være gyldig. For inputvalidering brukes det regulære uttrykk som er definert i enum-klassen RegEx. 124

126 Figur 192. createform i register-user.component.ts RegisterUserComponent brukes også når en bruker skal endres. Dette skjer via endreknappen som nevnt tidligere i punkt Endre bruker. Når denne modalen åpnes, får den en bruker sendt med og brukeren blir deretter patchet inn i skjemaet. Det utføres også en sjekk for om brukeren er veileder. Hvis brukeren er det så dukker det opp en liste over hvilke grupper brukeren er veileder for. Figur 193. patchform() i register-user.component.ts 125

127 Figur 194. En veilder som skal endres Funksjoner Lage innloggingsbruker Figur 195. Gi konto for en bruker Denne knappen er vises kun hvis innlogget bruker er administrator. Den blir vist i «Endre bruker»- kompontenten, som blir åpnet når endreknappen blir trykket på en av brukerne. Knappen aktiverer en prosess som sender mail til brukeren, der brukeren kan opprette et passord for sin konto. Mer om dette se PassordResetComponent. 126

128 Bytte aksesslevel Figur 196. Endre bruker med "Velg aksessnivå" Når admin trykker på endreknappen og brukeren som skal endres på allerede har en konto, vil «Gi konto» knappen bli erstattet med en flervalgsmeny, «Velg aksessnivå». Her kan man sette aksessnivået til brukeren Tagoversikt Tagoversikten er en oversikt over tagene som ligger i systemet. Det er mulig å søke på tagens navn og type (se Søk). Kortene i denne komponenten er mye mindre og kommer i rekker og rader. Dette er fordi tags ikke inneholder mye data og det er plass til mange flere kort. Det eneste som lagres på en tag er: navn, type og beskrivelse. Figur 197. Tagoversikt 127

129 Funksjoner Registrer tag Figur 198. gistrere tag i tagoversikt Registrering av tags kan kun gjøres av administrator. Knappen vil åpne registreringsmodalen TagForm. Denne modalen inneholder felt for navn, type og en beskrivelse av tagen Slett tag Ved å trykke på slettknappen på et tag-kort, kjøres en deletetag() metode som åpner en Confirm Modal. Den spør om brukeren av applikasjonen er sikker på slettingen eller ikke. Hvis «Ja» er valgt blir det kjørt en HTTP.GET metode som sletter taggen fra databasen. Om dette ble vellykket eller ikke får brukeren tilbakemelding fra AlertService. Figur 199. Sletteknappen på en tag Figur 200. deletetag() metoden i tag-view.component.ts Denne funksjonen er svært viktig for å ikke ha for mange taggs i systemet. Det er noen tags som er nødvendig fra start og ikke kan slettes. Alle andre tags som blir lagd utenom standartaggene kan bli slettet. 128

130 TagForm TagForm er en ng-modal (se Ng-modal), som viser tre input felter for å registrere tags. Navn, beskrivelse og type tag lagres om en tag, men det er kun navn og type som er påkrevd. Det er ikke alltid nødvendig å ha beskrivelse på en tag hvis navnet på taggen allerede beskriver den godt nok. Figur 201. Registrere tags De forskjellige typene blir hentet fra en konfigurasjonsfil. Dette er en fil som vi konfigurer selv og har noen standard typer. Tanken bak å ha dette som en konfigurasjonsfil istedenfor en egen registeringsside, er at type tag er et navn. Registreringen skjer som andre registreringer, gjennom en form. Den eneste valideringen som brukes her er at både navn og type er valgt, og at navnet ikke skal være over 50 tegn. Figur 202. tag-type.config.ts Figur 203. initialisernig av form i register-tag.component.ts Funksjoner Velg type tag Når en type velges, patches verdien inn i formen via metoden settype. Grunnen til at typen velges på navn, og ikke id, er fordi typen brukes for å sortere tags under henting og vi vil derfor ikke være avhengig av å vite dens id. Til slutt så kjøres metoden save lagrer taggen. 129

131 Figur 204. Typer tags Figur 205. settype() metoden i register-tag.component.ts Figur 206 save() metoden i register-tag.component.ts 130

132 9 Vedlegg 9.1 Teknologier Verktøy Slack Om Slack Slack er et cloud-basert samarbeidsverktøy for prosjekter startet av Stewart Butterfield. Verktøyet inneholder mange funskjoner og tjenester som gjør prosjektsamarbeid mye lettere. For eksempel er det mulig å opprette «chat rooms» innad et prosjekt. I tillegg har Slack plugins for mange andre verktøyer som kan lett synkronisere med for å kunne få oppdateringer i «real-time» Bruk i prosjektet I prosjektet brukes Slack som et kommunikasjonsverktøy, samt et nyttig arkiv for linker og filer som gruppen har funnet/opplastet gjennom prosjektet. For å skille mellom de forskjellige delene av prosjektet har vi laget «chat rooms» for hver del av dem: bugsquashing, front-end, back-end. Dette er for å skille innholdet i samtalene i flere deler, så et teammedlem kan for eksempel gå innenfor frontend for å finne en front-end relatert link. Figur 207. Slack 131

133 Jenkins Om Jenkins Jenkins er et prosjekt med åpen kildekode som er skrevet i Java. Jenkins brukes til å gjøre oppgaver som ikke krever menneskelig interaksjon for å gjøre i kodeprosjekter. Dette er oppgaver som for eksempel bygging, testing og utrulling av prosjektet. Målet med Jenkins er å bygge opp under et utviklingskonsept som innebærer kontinuerlig levering av programvare. Kontinuerlig levering av programvare er en prosess man gjerne brukes i agile utviklingsprosjekter. Dette betyr at bruk av Jenkins er godt egnet i kombinasjon med utviklingsprosessen Scrum. Scrum er forklart i punkt Scrum Måten Jenkins fungerer på er at man manuelt setter opp oppgaver man vil at Jenkins skal gjøre. Når man jobber med kodeprosjekter er det vanlig å bruke GitHub for lagring av koden og Git for versjonskontroll. Det man kan gjøre på GitHub er å sette opp en webhook. En webhook lytter på forandringer som skjer på GitHub og sier ifra over til annen programvare at forandringer har skjedd. Dette fanges opp av Jenkins som da tar den nye koden og gjennomfører oppgaver på den som tidligere nevnt. Gitt at disse oppgavene går som gjennomførte og godkjente vil Jenkins rulle det ut i produksjon for å brukes fortløpende Bruk i prosjektet Under prosjektstart var Jenkins noe som ble undersøkt og satt opp. Vi satt opp en jobb, som var at prosjektet skulle bygges hver gang det ble lagt ut på GitHub. Målet med å gjøre dette var at hver gang vi pushet kode opp på master, skulle koden bli bygd. Hvis koden ikke bygde riktig ville den bli kastet og vi ville få en feilmelding om hva som gikk galt. Grunnet utfordringer under oppstarten av prosjektet endte vi opp med å gå vekk fra Jenkins. Det krevde mer vedlikehold enn det var verdt for oss i tid Marvel Om Marvel Marvel(App) er et veldig simpelt prototypings verktøy som er lett å anvende. Marvel gjør at man kan lage prosjekter der man kan legge til forskjellige lysbilder, som er en fremstilling av nettside(r). I tillegg til dette kan man legge til en kobling mellom et område i grensesnittet og et nytt lysbilde, slik at det simulerer navigering på en nettside. Designdelen av verktøyet er ikke perfekt, men fungerer til formålet med prototyping. Her kan man lage bokser og legge til tekst hvor man vil. Marvel har støtte for embedded view, noe som gjør at man kan gjengi prototypen der en måtte ønske via et iframe-tag. 132

134 Bruk i prosjektet I prosjektet ble Marvel brukt til å lage de første prototypene av applikasjonen. Prototypene ble brukt som eksempler på tanker vi hadde rundt funksjonaliteten til applikasjonen, spesielt i forhold til å vise dette til Produkteier. Med tanke på at Marvel har støtte for embedded view har vi gjengitt prototypen vår på prosjektsiden. Se punkt 9.8 Prototype Brukergrensesnitt v2 og 9.9 Prototype Brukergrensesnitt v1 for prototyper lagd av Marvel Trello Om Trello Trello er en web-basert applikasjon for oppgavetavle. Typiske oppgavetavler som i Kanban eller Scrum kan implementeres med applikasjonen. I Trello kan oppgaver tilordnes til personer, slik at man unngår konflikter der flere jobber med samme arbeidsoppgaver. Oppgavene kan legges i forskjellige lister basert på hvor i utviklingsprosessen de er. For eksempel vil en oppgave flyttes fra «Work-in-progress» til «Testing» når en funksjon anses som ferdig utviklet Bruk i prosjektet Trello brukes til å lage oppgavetavler relatert med planleggingsfasen og utviklingsfasen. For planleggingsfasen settes opp ulike oppgaver angående planlegging på oppgavetavlen. For Utviklingsfasen blir brukt til å rapportere diverse bugs og problemer med applikasjonen som blir oppdaget underveis Docker Om Docker Docker er et verktøy for å automatisere utrulling av applikasjoner i «programvare-container». En «programvare-container» er et konsept som går ut på å pakke inn programvare i et komplett filsystem som inneholder det som trengs for at programvaren skal kjøre. I forbindelse med Docker, er en «container» en kjørbar instans av et image. Et image kan sees på som en bruksanvisning for hvordan en «container» skal fungere. Målet er at man skal kunne kjøre applikasjonen uavhengig av miljøet det kjøres på. Miljøene vil typisk være enten Windows eller en versjon av Linux. Docker blir da et lag mellom operativsystemet, som kjører på serveren og operativsystemet som kjører på «containern». Fordelen med å bruke Docker er at «containerne» koster lite kraft for en maskin å kjøre. «Containeren» tar seg kun av det som trengs for at applikasjonen skal kjøre, og ikke mer. Dette betyr igjen at man kan ha flere «container» kjørende på samme system. For brukeren kan dette se ut som at en applikasjon kjører på ulike servere, når det faktisk er på samme maskin men i ulike «container». 133

135 Docker er bygd opp med en «klient-server»-arkitektur. Klienten er grensesnittet en bruker tar i bruk for interaksjon med Docker. Klienten snakker igjen med Docker Daemon ved bruk av et REST API som vil tilsvare serveren i arkitekturen. En Daemon er et program som kjører som en bakgrunnsprosess og unngår direkte interaktiv kontroll av brukeren. I tilfellet med Docker er Docker Daemon punktet de faktiske kommandoene kjøres fra. Hvis man skal lage en ny kontainer vil Docker Daemon sørge for at det skapes en kjørbar instans av et image basert på brukerens kommando via klienten. For å kunne lage en «container» trenger man et image. Dette bygges med en Dockerfile som inneholder informasjonen om hvordan imaget skal bygges. Dette imaget er det man bruker til å lage den kjørbare «containern» man ruller ut i bruk. I det brukeren skal lage en «container» kan det legges til informasjon som hvilken port «containern» skal lytte på eller hvilke filer som skal brukes for å kjøre en applikasjon Bruk i prosjektet Docker brukes i fire deler av prosjektet: REST-API Databaseserver Front-end Jenkins Applikasjonens REST-API kjører i en «container» som er satt opp med et image av en Payara-server. Databaseserveren bruker en «container» som kjører et MySQL-server image. Front-end bruker et NodeJS image i sin «container», som brukes til utrulling av applikasjonen. Den siste «containern» kjører et image av Jenkins. Se avsnitt om Jenkins MySQL Server Om MySQL Server MySQL er et fullstendig databasesystem som tilbyr konfigurasjon, lagring av entiteter og administrasjon av dette. Databasen som tilbys i systemet er basert på SQL, og dermed relasjonsbasert. Selve databasen blir laget basert på SQL-scriptet, som kan lages på enten MySQL-Workbench eller fra bunn av. Alt dette tilbys gratis av MySQL, og er enkel å sette opp med Docker. MySQL tilbyr et MySQL Server Image på DockerHub, og dette kan brukes til å sette opp en database på server. 134

136 Bruk i prosjektet Docker-imaget av MySQL brukes som Dockerfile for å lage «containern» med databasen. «containern» har en fullstendig og kjørende database, som kan konfigureres og eksekvere SQL på. Denne «containern» kjøres på en AWS (Amazon Web Service) server MySQL Workbench Om MySQL Workbench MySQL Workbench er et verktøy som både støtter ER modellering av MySQL databaser. Med modelleringsverktøyet er det mulig å lage en relasjonsbasert database. Constraints Primary/Foreign Key One-To-Many, Many-To-Many etc. Relasjonene blir automatisk lagd av verktøyet og bruker trenger bare å si ifra hvilke entiteter som har relasjoner. Dette er mulig å eksportere som et vanlig SQL-skript, som kan brukes til databasen i MySQL Server Bruk i prosjektet Workbench ble brukt i starten av prosjektet til å modellere databasen, men senere gikk gruppen vekk fra verktøyet og implementerte endringer direkte i scriptet Chrome Developer Tools Om Chrome Developer Tools Google Chrome har sin egen utviklingsverktøy som gjør det mulig å gå dypere inn i webapplikasjonen. Verktøyet er bygd inn i nettleseren og blir brukt av utviklere for å effektivt finne layout feil, sette «breakpoints» og kode optimalisering Bruk i prosjektet Under prosjektet har vi brukt dette verktøyet i flere faser. I utviklingsfasen ble verktøyet brukt til å finne feil i «layout» en eller design. Dette fungerte med at vi kunne bruke verktøyet for å endre HTML en realtime og se endringer umiddelbart. 135

137 Figur 208. Chrome Developer Tools Elemenet For å se hva som sendes mellom front-end og API, har verktøyet en «Network» fane som overvåker all aktivitet fra og til front-end. Her kan man se hva som skjer med et API kall og dens «Request Header» og «Respone Header». Gruppen brukte dette for å feilsøke når API kallet ikke fungerte som forventet. Figur 209. Chrome Developer Tools 'Network' Verktøyet ble også brukt under testfasen der vi måtte se over ressursbruk av webapplikasjonen. Det er mulig å se over hva applikasjonen bruker av minne og overvåke hvilke funksjoner som blir kjørt når 136

138 spesifikke handlinger forekommer. I tilfelle der bruken av minne bare øker uten å gå ned til et normalt nivå igjen, vil si at det er noe som starter repetitivt uten å stoppe. Figur 210. Chrome Develeper Tools 'Performance' GitHub Om GitHub Web-basert oppbevaringsplass med versjonskontroll og aksesskontroll. Da alle prosjekter er offentlige ved mindre man betaler, så er det bare eier og brukere eieren godkjenner som kan legge ut kode på prosjektet Bruk i prosjektet Front-end og back-end er delt inn i to uavhengige moduler. Det var derfor naturlig å ha to lagringsplasser for koden. For at gruppen effektivt skulle kunne jobbe på begge delene av prosjektet var det viktig med versjonskontroll slik at kode ikke ble slettet ved en feil. 137

139 9.1.2 Rammeverk/Bibliotek Angular Om Angular Development platform for building mobile the desktop web applications Cross-platform: web, mobile web, native ios/android, app win/mac/*nix Typescript, Progress on performance, Clean code, More powerful applications, Faster, Simpler Åtte hoveddeler Moduler Angular 2 er et modulært rammeverk der hver funksjonalitet er innkapslet i en modul, som igjen kan bli eksponert andre steder i applikasjonen som en service. De vanligste modulene å bygge opp, er ettansvars-moduler eller område-moduler. Den første varianten er en modul der man tar for seg et enkelt ansvarsområde, for eksempel et view med en liste med brukere, som hentes fra en service. Område-moduler er en samling ettansvars-moduler for å eksportere disse som en enhet. Et eksempel på dette som er en samling kjernemoduler i Angular-rammeverket Komponenter Komponenter tilsvarer view-modellen i MVVM(Model View View-Model)-mønsteret, det vil si de fungerer som en kontroller for en del av grensesnittet gjennom styring av data og logikk. Sammen med en template, metadata og eventuelt stiler, utgjør de en isolert enhet i grensesnittet. Template er en representasjon på hvordan komponenten skal gjengis i nettleseren. View-modellen inneholder den nødvendige logikken for å gi grensesnittet funksjonalitet og data. Stilene er vilkårlig og gir grensesnittet et viss utseende, i likhet med stiler ellers i web-programmering. Komponentstiler skiller seg ut ved at de kun gjengis for komponenten det tilhører. Kjernen i komponenter er metadata, dette er bindeleddet mellom alle delene i en komponent. Metadata inneholder konfigurasjonene til en komponent som hvor den skal se etter en template, stiler, animasjoner og mye mer Metadata Metadata er det som gjør en komponent til en komponent, eller en service til en service. En komponent er en vanlig typescript-klasse inntil den blir annotert Denne dekoratøren inneholder en rekke informasjon om hvordan komponenten skal gjengis i applikasjonen. De viktigste er selector, templateurl/template og styleurls. Disse forteller hva HTMLtaggen skal hete dersom den brukes i en annen komponent, hvilken template som skal gjengis i denne taggen og også hvilke stiler som skal brukes. En annen viktig dekoratør som forteller at klassen kan injiseres direkte i en komponent, en injisert klasse har ikke en template. 138

140 Databinding Databinding lar deg binde data og interaksjon mellom en template og en komponent, på en deklarativ måte. Det finnes fire forskjellige varianter: interpolering, egenskapsbinding, hendelsesbinding og toveisbinding Direktiver Direktiver lar deg fortelle Angular hvordan et element skal gjengis. Komponenter er en form for direktiv. Strukturelle direktiver lar deg legge til eller fjerne noder fra DOM en. Attributtdirektiver lar deg endre utseende eller oppførsel på et bestemt element Servicer Servicer innkapsler en bit av logikken og gjør denne tilgjengelig for resten av applikasjonen. Ideelt sett delegerer komponenter de tyngre oppgavene til servicer som gjør denne oppgaven godt. Dette gir mindre kompliserte klasser med mer fleksibilitet, og testbarhet Template En template representerer view-delen av en komponent, den forbedrer ren HTML med ny syntaks og oppførsel som tillater interpolering og toveis data binding og annet Bruk i prosjektet Det var et naturlig valg å bruke Angular for utviklingen i front-end. Dette er et rammeverk med mye støtte, jevnlige oppdatering og god dokumentasjon. I tillegg inkluderer utviklingsgruppen personer fra Google, noe som gir det gode framtidsutsikter og man kan forvente at de blir støttet i lang tid fremover. Angular er også et rammeverk som gjør det lett å kommunisere med back-end da det har mye støtte for HTTP gjennom et av sine kjernebiblioteker Maven Om Maven Maven er et automasjonsverktøy hovedsakelig for Javaprosjekter. Maven tar seg av to aspekter ved prosjektbygging: hvordan prosjektet skal bygges og holder kontroll på avhengighetene til prosjektet. Maven kan også konfigureres til å gjennomføre tester av programmet. Konfigurasjonen til Mavenprosjektet gjøres i en eller flere pom-filer (Project Object Model). Her defineres prosjektbyggingen samt avhengighetene og deres versjoner. Avhengigheter i forbindelse med Maven betyr annen kode prosjektet trenger for å kjøre riktig. For eksempel hvis man trenger en kalkulator i prosjektet kan man laste ned en avhengighet, gjerne kalt en modul, i stedet for å lage det på nytt selv. Ved prosjektbygging laster Maven ned modulene definert i pom-filene. 139

141 Bruk i prosjektet På grunnlag av produkteieres forslag ble Maven valgt for å styre byggeprosessen til prosjektet. Til tross for at det ikke var et direkte krav, så var det en anbefaling fra Accenture. Maven er brukt i høy grad i Accentures prosjekter, og sees derfor på som relevant kunnskap å ha. Maven tar seg av hele bygg og testfasen av prosjektet. Ved å bruke en Modul kalt JUnit har vi konfigurert Maven til å ta seg av gjennomføringen av enhetstestene som er skrevet for prosjektet. Enhetstester er kode som tester at enkelte deler av produksjonskoden gjør det den skal. Produksjonskode er det som til sist går ut på serveren Java EE Om Java EE Formelt kalt Java 2 Platform, Enterprise Edition; Java EE er en utbredt programmerings- og distribusjonsplattform for programvare rettet mot bedrifter (nettverk og nettjenester). Plattformen er en utvidelse av Javas standardversjon som er et objektorientert programmeringsspråk. Java EE har et design som baserer seg på å ha modulære komponenter kjørende på en webserver. Dette betyr at man skal skille kode ut i uavhengige og utskiftbare moduler. Disse komponentene kan eksempelvis være et grensesnitt for å snakke med en database eller et rammeverk for å konvertere JSON til objekter i Java. JSON beskrives i punkt JSON Bruk i prosjektet Utgangspunktet for valget av Java EE kommer fra kravspesifikasjonen fra Accenture. Det stod ikke som et krav, men et ønske dette fordi at applikasjonen er noe de ønsker å bruke og videreutvikle ved behov. Java EE er noe Accenture bruker over flere av deres prosjekter, så det var også en direkte anbefaling til prosjektgruppen å sette seg inn i det. Java EE legger grunnlaget for «back-end»-delen av prosjektet. Applikasjonens «front-end» skal kommunisere med et REST-API som omtales i detalj i kapittelet om REST-APIet. APIet i seg selv skal bruke en implementasjon av en spesifikasjon for persistens API (JPA) for å snakke med applikasjonsdatabasen. Hibernate og JPA beskrives i mer detalj i punkt Hibernate og Persistens / Data Accsess Karma/Jasmine Om Karma Karma er et åpen-kilde rammeverk for testing. Det har som hensikt å gjøre konfigurering og kjøring av tester og testmiljøet til en triviell oppgave. Dette gjøres ved at karma setter opp en lokal web server der testene gjennomføres, og når testene er ferdig får utvikleren tilbakemelding på. 140

142 Om Jasmine Jasmine er et atferds-drevet utviklingsrammeverk for testing av JavaScript-kode. Dette er et rammeverk for testing av JavaScript og DOM, men det er ikke avhengig av DOM for å gjøre testene i JavaScript Bruk i prosjektet I prosjektet ble Karma brukt som en test runner, altså en konfigurasjon som starter testene. Disse testene ble skrevet ved hjelp av Jasmine Mockito Om Mockito Mockito er et åpent testrammeverk for Java. Fordelen med Mockito er at det lar utvikleren lage såkalte «Mocks» av klasser. «Mocks» er simulerte instanser av klasser. Disse kan igjen bli brukt i klassene og metodene man ønsker å teste for å simulere ulik oppførsel fra koden man skal teste. En ulempe ved å bruke Mockito er at det kan være mye jobb å opprettholde koden. Siden «mock»-objektene etterlikner reell kode må også oppførselen til «mock»-objektene skrives om hvis koden bak forandrer seg Vår bruk Mockito ble brukt til å simulere serviceklasser og repositoryklasser HTTP Om HTTP Hypertext Transfer Protocol (HTTP) er fundamentet for kommunikasjon over verdensveven. Hypertext er tekst som kan vises på en skjerm, og inneholder hyperlinker som refererer til annen aksessbar tekst. HTTP er en protokoll som definerer hvordan «forespørsel-svar»-operasjoner over verdensveven skal foregå. Protokollen opererer med en rekke metoder som indikerer hvilken type handling en forespørsel ønsker å gjennomføre. Hovedsakelig er det fire metoder som blir brukt. GET, POST, PUT og DELETE. GET Gjør en forespørsel om å få representert en type ressurs på et format definert i headerfeltene til forespørselen. Formålet med GET er utelukkende å hente data. POST Gjør en forespørsel om at tjenesten skal behandle dataen som ligger i forespørselen. Dette innebærer gjerne at noe data legges på en database. PUT Oppdaterer dataen som er lagret på den ressursen man prøver å aksessere. DELETE Sletter dataen på ressursen man prøver å aksessere. Alle metodene er laget for å dekke hvert sitt behov, men generelt er en forespørsel bygd opp på en spesiell måte. Først har man en «request line». En «request line» er bygd opp som følgende: Først 141

143 definerer man hvilken metode som skal brukes, deretter hvilken ressurs man etterspør, og til slutt hvilken versjon av HTTP som er brukt til å konstruere forespørselen. Denne linjen kan se slik ut «GET /users/ola HTTP1.1». Deretter kommer «request header fields». Disse feltene kan brukes for å informere om hva slags type format man ønsker svaret på. Typisk er dette også data for å identifisere en bruker, type datainnhold i forespørselen, og liknende. Til sist kommer «request body». Body brukes til å sende data, men det er ikke alle metodene som inneholder en «request body». Svarene på metodene har et format det må leveres på. De bygges på lik måte som en forespørsel, men inneholder litt annen type data. Svar i HTTP bruker statuskoder som er en effektiv måte å gi beskjed om hvordan behandlingen av forespørselen gikk. Et brukergrensesnitt kan reagere på de forskjellige statuskodene, noe som fører til økt brukervennlighet i applikasjonen. Det er 5 grupper av responskoder. I de følgene eksemplene representerer X et tall. 1XX Informasjonsresponser. Disse kodene betyr at dataen har blitt mottatt og forstått, men at klienten må vente på en endelig respons. For eksempel kan dette bety at serveren jobber med å behandle dataen, men at klienten kan fortsette med annet arbeid før responsen kommer. 2XX Suksessresponser. Disse kodene betyr at dataen har blitt mottatt og blitt behandlet med suksess. 3XX Omdirigeringsresponser. Disse kodene betyr at klienten må gjøre ytterligere forespørsler for å gjennomføre forespørselen. 4XX Feil fra klient. Disse kodene betyr at klienten har gjort en feil. Dette kan være alt fra manglende autorisering til forespørsel mot en ressurs som ikke eksisterer. 5XX Serverfeil. Disse kodene betyr at serveren støter på en feil under behandling av en forespørsel og ble derfor avbrutt Vår bruk HTTP har en sentral rolle i applikasjon siden det er måten vi kommuniserer mellom APIet og grensesnittet. Hovedsakelig blir to felter brukt: Ett for å definere typen data som blir overført, og ett for autorisering. I applikasjonens tilfelle er det JSON som brukes til overføring, men i noen tilfeller brukes MIME-type. Det er brukt to forskjellige typer autorisering. Det første er BASIC autorisering. Dette betyr at man bruker en hash-funksjon på brukernavn og passord, og legger resultatene sammen med et kolon som skiller dem. Tekststrengen man sitter igjen med blir da «base64»-enkodet før det legges i header-feltet. Den andre typen brukt i applikasjonen er JSON Web Token (JWT). JWT er en standard for å sende digitalt signert data på en trygg måte. Dette tokenet kan inneholde informasjon som for eksempel hvem brukeren er, hvor lenge tokenet er gyldig, hvilket aksessnivå brukeren har og liknende. Dataen sendt mellom brukergrensesnittet og APIet er på JSON-format. Selve dataen som behandles blir lagt i forespørselen, og etter den er behandlet i svaret. 142

144 JSON Om JSON JSON eller JavaScript Object Notation er et dataformat som, til tross for sitt navn er uavhengig av språk. Det er et åpent standardformat som representerer data på. Det blir representert som en assosiativ mengde, der man kan nøkkel- og verdipar Bruk i prosjektet JSON er formatet data sendes på mellom API og grensesnitt i applikasjonen Node.js Om Node.js Node.js er et åpent kryssplattform-runtime-system for applikasjoner, hovedsakelig i forbindelse med server og nettverk. Et runtime-system er noe som holder styr på hvordan arbeid skrevet i et gitt språk blir utført. Node.js er ikke et javascriptrammeverk i den forstand at det er bygd i kun JavaScript. Det er bygd opp av ulike moduler, der noen er skrevet i JavaScript og andre i C og C++. Googles V8- motor er det som brukes til å kompilere JavaScript direkte til maskinkode før det eksekveres. Arkitekturen til Node.js baserer seg på hendelsesdreven modell, som er i stand til å utføre asynkron I/O. Dette er en fordel siden I/O ofte er en fartssperre for programmer. Det at det er asynkront tillater oss å fortsette prosessering før I/O-overføringen har gått gjennom. Det at arkitekturen er hendelsesbasert betyr at det er fokus på å skape, lytte på og reagere på ulike hendelser. En av de pre-installerte modulene er npm. Npm er det Node.js bruker for pakkehåndtering. Det brukes til å installere programvare og håndtere avhengigheter i applikasjonen Bruk i prosjektet Vi bruker Node.js som miljø for applikasjonen vår skrevet i Angular 2. Via Node.js bruker vi npm til å håndtere avhengigheter i applikasjonen som kan være alt fra enkelte komponenter til moduler for å håndtere HTTP-kall Payara Om Payara Payara en applikasjonsserver med åpen kildekode som avledet fra GlassFish Server Open Source Edition. Grunnen til at Payara ble skapt i utgangspunktet var fordi Oracle avviklet kommersiell støtte for GlassFish. Begge er servermiljøer som kan brukes til å kjøre applikasjoner i JavaEE Bruk i prosjektet Prosjektet er avhengig av Payara som applikasjonsserver for å kjøre APIet. Payara gjør utrullingen på server simpel oppgave noe som har tilrettelagt for enkel testing av ny kode på kort tid. 143

145 JAX-RS Om JAX-RS JAX-RS er et API for programmeringsspråket Java. API står for Application Programming Interface og er generelt et sett med klart definerte metoder for å kommunisere mellom forskjellig programvaredeler. Målet med JAX-RS er å gjøre utvikling av web-servicer som er kodet med tanke på REST-arkitekturen. REST står for Representational State Transfer som er forklart i REST API. JAX-RS bruker annotasjoner for å definere endepunkter for ulike HTTP-kall mot serveren applikasjonen kjører på. Annotasjoner definerer en oppførsel en metode eller klasse skal ha. For eksempel vil en metode annotert med annotasjonen «@POST» lytte på HTTP-post-metoder gjort mot endepunktet metoden ligger under Bruk i prosjektet JAX-RS er byggesteinen i APIer lagd for prosjektet. APIet er bygd opp med tanke på de ressursene det skal eksponere. Det vil si at det man skal kunne gjøre med APIet er lagt inn i egne klasser vi har kalt ressursklasser. Disse klassene har metoder som lytter på ulike HTTP-metoder og følger opp med en respons avhengig av hvordan operasjonen man prøvde å gjøre gikk Hibernate Om Hibernate Hibernate er et rammeverk som tilbyr ORM (Object-Relational Mapping) og persistens av data for Java applikasjoner. ORM gir utvikler muligheten til å konvertere databaseentiteter til Java-klasser, uten å måtte skrive SQL. Entitetsklassene fungerer som en blåkopi for hver tabell. Disse klassene er POJO (Plain Old Java Objects), hvilket betyr at klasse kun inneholder datafelter og get() og set() metoder. Annotasjoner (@Annotations) blir brukt til å fortelle Hibernate hva som representerer en kolonne og hvilke relasjoner som tilhører den. Hibernate vil så lage SQL spørringer basert på informasjonen gitt i entitetsklassene. Rammeverket tar seg av databasekobling gjennom en konfigurasjonsfil. I denne filen definerer man blant annet brukernavn og passord, og IP-adresse til databasen for at Hibernate skal sette opp en kobling. Hibernate trenger informasjon om hvor entitetsklassene ligger i prosjektet, dette defineres i samme fil. Persistens kan løses på to måter med Hibernate. Rammeverket tilbyr både en EntityManager og SessionFactory. EntityManager er den nyeste og den anbefalte måten å løse persistens med. En fordel med den nye måten å implementere persistens er at man kan utnytte Java annotasjoner som vil behandle transaction scope for utvikler. Det betyr at utvikler ikke trenger å definere når transaksjonene skal begynne og når den slutter. Med SessionFactory er man nødt til å ta 144

146 hånd om commits og rollbacks direkte i koden. Hibernate-gruppen har valgt å ikke fjerne SessionFactory grunnet mange av dagens Enterprise applikasjoner bruker SessionFactory Hvorfor? Hibernate er valgt som løsning for persistens og ORM grunnet at rammeverket er standarden i bransjen for de nevnte formålene. Rammeverket ble i tillegg anbefalt fra produkteier for å håndtere persistens. Med tanke på at applikasjonen kan potensielt bli videreutviklet, er det derfor lurt å ta i bruk teknologi som produkteier anbefaler/ønsker. Som følge av populariteten finnes det mye dokumentasjon om Hibernate, som er viktig for å implementere ny og ukjent teknologi. Rammeverket har vært i utvikling siden 2001, så det finnes derfor mye utdatert dokumentasjon på anvendelse av rammeverket. Dette har medført til bruk av gammel anvendelse, som bruk av SessionFactory. Med denne måten er det fortsatt mulig å utføre hensikten med rammeverket, men EntityManager hadde vært gitt flere fordeler og ikke minst vært lettere å implementere. Grunnet at dette ble oppdaget etter at SessionFactory var implementert, ble det besluttet å ikke bytte over. Dette kunne potensielt være tidskrevende, og potensielt føre til store omstruktureringer i koden. Hibernate vil gjøre koden mer modulært og lettere å implementere forandringer. Er det forandringer i databasen, kreves kun endring på deler av koden assosiert med for eksempel tabellen. Og med riktig implementasjon av JPA vil man kunne bytte persistens rammeverk uten store forandringer i koden Bruk i prosjektet I applikasjonen brukes Hibernate til ORM, databasekobling og persistering av data AWS Om AWS AWS (Amazon Web Services) er en serie med tjenester Amazon tilbyr. Det er en skyplattform som hvem som helst kan bruke til å for eksempel lagring, database, applikasjonsserver og verktøy for «Internet of Things» Vår bruk Prosjektet krevde servere for å kjøre de ulike delene av applikasjonen. Amazon sin Elastic Cloud Computing (EC2) virtuelle vertsservere brukes til dette formålet. Amazon tilbyr en versjon av denne typen servere som er gratis å bruke. Problemet er at den har lite lagringsplass, noe som gjør at applikasjoner som krever lagring ikke kan kjøre komfortabelt. En oppgradering var da nødvendig. Applikasjonen kjører over totalt 3 servere som er uavhengige av hverandre og kan byttes ut. 145

147 Angular/Material Om Angular/Material2 Material Design for Angular2 er en modul som utvikles i samarbeid med Angulars kjerneteam. Modulen er bygd med Googles Material Designprinsipper, et prinsipp som henter inspirasjon fra papir og blekk. Prinsippet har fokus på sterke kontraster, bruk av lys, harde kanter, bevegelse og et minimalistisk uttrykk. Modulens mål er å levere komponenter med god kvalitet og en enkel implementerings- og modifiseringsprosess Vår bruk Angular/Material2 ble valgt fordi vi ønsket å følge Material Designprinsippene. Det leveres gode og brukervennlige komponenter som var enkel i bruk. Etter brukertest 1 (punkt Brukertest 1) kom det frem at det var for mye tomrom mellom komponentene og det var mye rom som ikke ble brukt i brukergrensesnittet. Det ble dermed sluttet at modulen droppes til fordel for Bootstrap Bootstrap Om Bootstrap Bootstrap er et av verdens mest populære rammeverk for responsive design. Rammeverket bygger på CSS, i tillegg inkluderer det en del JavaScript og jquery. Bootstrap ble utviklet av et team i Twitter for å få konsistens på tvers av prosjektene i firmaet. De innså at de var i ferd med å lage noe større enn et internt rammeverk og valgte derfor å publisere det som et åpen-kilde bibliotek. Bootstrap er i sin tredje versjon. Versjon 4 er i alpha og er en komplett omskrivning av rammeverket, selv i alpha-stadiet er dette en stabil nok versjon til å bruke i produksjon Vår bruk Applikasjonen bygges med Bootstrap 4. Dette for å ha et responsivt design og legge opp for at det skal skalere godt for håndholdte enheter. I all hovedsak er det hjelpeklassene Bootstrap tilbyr som gjør Bootstrap til et godt rammeverk. Disse klassene hjelper i stor grad med å gjøre jobben med å gjengi elementer i forhold til hverandre lettere. I tillegg har de en del klasser for utseende på elementer som gir et konsistent uttrykk i applikasjonen Angular2-grid Om Angular2-grid Angular2-grid er en modul utviklet av en GitHub-bruker som går ved navnet BTMorton. Denne modulen inneholder et direktiv som kan brukes i Angular-applikasjoner for å få en løsning med flyttbare paneler. Størrelsen på disse panelene kan også endres. Systemet inkluderer flere «Interface» man kan bruke for å sette opp egendefinerte konfigurasjoner på hvordan rutenettet og 146

148 panelkomponentene skal oppfør seg internt og i forhold til hverandre (Morton, 2015). Figur 211 Systemet i applikasjonen Vår bruk Modulen ble valgt for å kunne realisere en «dashboard»-løsning. Dette var et ønske fra vår side som utviklere å implementere for å øke kompleksiteten i applikasjonen. Ved å la brukeren ha full frihet rundt oppsett av grensesnittet var tanken å øke brukervennligheten. Det viser seg at brukere trenger visse rammer og begrensinger å jobbe ut ifra, og det ble dermed bestemt under første brukertest at denne teknologien måtte bli faset ut av prosjektet TinyMCE Om TinyMCE TinyMCE er en tekst editor tilgjengelig gjennom et Angular-2 bibliotek. Editoren er konfigurerbar med de funksjonene som er ønskelig. Den har for eksempel funksjoner som last opp bilde, laste opp video, lage tabell og sjekke aksessibilitet. Denne editoren ble valgt grunnet enkelt implementasjon og kompatibilitet med Angular2. 147

149 Figur 212. Tekst editoren brukt i applikasjonen Vår bruk Applikasjonen vår bruker teksteditoren for å skrive dokumenter. Dette var en grei og enkel løsning til registrering av dokumenter med tanke på at editoren har mange funksjoner tilgjengelig allerede. Dette gjorde at vi enkelt kunne sende over alt HTML-tekst i editoren rett til APIet uten å måtte håndtere noen konverteringer. Editoren brukes også for å åpne og endre word-filer. Innholdet av filen vill bli åpnet i editoren og utseende vil være tilsvarende likt. Figur 213. Editoren med fil åpnet 148

150 9.2 Elementer Gridsystem Det kom fram først under designet av andre versjonen av grensesnittet spørsmålet om hvordan systemet skulle se ut. Designet på den første og andre versjonen av skissene har tatt inspirasjon fra (hentet ) og (hentet ). Se punkt 9.9 og 9.8 for versjon 1 og 2. Figur. 214 Her er applikasjonen med grid-systemet. GroupView, UserView og UserForm er åpen her. Vi ble enige om at en dashboard-løsning kunne gi brukeren muligheten til å bestemme sin egen arbeidsflyt via å bestemme hvilke paneler som var oppe til enhver tid. For å realisere denne løsningen brukte vi et bibliotek som muliggjør funksjoner som «drag», «drop» og «resize» av paneler. Se punkt Angular2-grid for mer info om biblioteket. Løsningen er nå diskontinuert og var aktiv fram til sprint 6. Det ble brukt mye tid på å få implementert paneler som skulle være funksjonelle, skalerbare, brukervennlige, modulære og feilfrie. Læringsprosessen i denne perioden var også en stor utfordring med tanke på at ingen av gruppen har erfaring med grid-baserte løsninger. Grunnlaget for diskontinueringen er fordi UX-eksperter har fått sett en demo og vurdert løsningen. I tillegg har produkteier fått brukertestet gridsystemet. I begge tilfellene ble konklusjonen at gridsystemet ikke er brukervennlig. Løsningen ble å endre applikasjonen fra en dynamisk løsning til en mer statisk løsning. Hvorfor gridsystemet ikke var bra: 1. Kronglete med så mange paneler samtidig 149

151 2. Må endre på størrelse på panelene hele tiden 3. Mye som fløy over alt når ett panel skulle bevege seg. 4. Lite intuitivt over hvor ting plasserte seg etter at man hadde aktivert panelet. Under konverteringen fikk vi mange problemer som vi måtte bruke tid på: 5. Flytte alt innhold fra en gridbasert løsning til enkelt sider 6. Gjøre Tag- og UserForm til modaler 7. Routing mellom komponentene måtte skapes 8. Fjernet grid-layout Statiske sider Denne løsningen inneholder statiske sider som dekker hele skjermen. Den ble først foreslått under første brukertest da grid-systemet viste seg å være lite brukervennlig og er en alternativ løsning på dette problemet., Figur 215. Statiske sider Ved å ha en statisk løsning tar vi litt av friheten til brukeren vekk, men til gjengjeld er det mye enklere å navigere seg rundt og ha kontroll på hva som skjer. Muligheten til å øke størrelsen på hver enkelt side ble også mulig, noe som ga oss plass til å fylle sidene med mer nyttig informasjon. Opprettelse av bruker, tags og oppgaver i denne løsningen er bare tilgjengelige gjennom deres oversikter. Dette var et ønske fra produkteier fordi de opererer mest innenfor oversiktene og trenger dermed ikke en ekstra opprett-knapp fra menyen. Den eneste opprettelses knappen som er i menyen er 150

152 for registrering av gruppe. Dette er fordi størrelsen på registeringssiden er så stor og ville ikke passet i samme format som de andre Quickstart For å starte utviklingen i front-end valgte vi å bruke en quickstart. Dette er en ferdigbygd startapplikasjon med en del verktøy for bygg og distribusjon. Denne er bygd opp etter best practises for angular og typescript, og dette gjorde det til en god plattform for å starte utviklingen i riktig retning. Et viktig punkt er at det er lett å forstå og utvide etter eget behov. Samtidig oppdateres det og kan lett integreres Forms i Angular 2 Det er to måter å bruke forms på i Angular2, template-driven og model-driven forms. Model-driven forms er brukt i programmet grunnet at det passer bedre i dette tilfellet (Angular University, 2016). For å få til å registrere en gruppe med en til flere studenter og veiledere, må applikasjonen ha en dynamisk «form» som skaper muligheten for å legge til ekstra sett med felter for en student eller veileder. Dette fungerer ved å bruke FormGroup som blir laget av en FormBuilder. Hver gang et ekstra sett med input legges inn, oppdaterer FormBuilder en FormGroup en med de inputfeltene som blir lagt til. Til slutt blir alt av input som blir lagt til i FormGroup en lagret via en save() funksjon. (Yeen, 2016) Angular2 modaler Angular2-modal En generisk konfigurerbar modalenhet for Angular. Dette betyr at hvilken som helst implementasjon av modal kan bli «porta» inn i angular2-modal. Angular2-modal vill ha noen UI platformer bygd inn fra før av. Eventuelt kan eksterne UI platformer bli påførst i et senere tidspunkt. (Assaf, 2016) Biblioteket blir brukt for å lage egendefinerte modaler. Figur 216. Her brukes modalen til å vise/velge eksisterende studenter når man skal registrere en bachelorgruppe. 151

153 Denne typen modal er blitt diskontinuert grunnet dårlig kompatibilitet med Bootstrap 4 samt vanskeligheter med å implementasjon. Den ble brukt for å legge til eksisterende brukere i en gruppe. Bilde ovenfor viser akkurat dette Ng-modal Når vi byttet til Bootstrap 4 ble det introdusert mange nye bugs med Angular2-modul. Dette skapte problemer som gjorde at biblioteket ikke fungerte optimalt. Løsningen ble at Angular sitt egen Modal bibliotek ble anvendt slik at vi var sikre på at det var kompatibelt. Utseendemessig ser de helt like ut, men denne er utviklet av Angular og ser ut til å ha en mer stødig versjon for Bootstrap 4. Anuglar sitt modalbibliotek blir brukt for registrering av brukere og tags. Dette valget ble gjort på grunn av at form en til både userform og tagform er liten nok til å ikke trenge en egen side. I tillegg til dette blir også modalene brukt til dialogbokser/tilbakemeldingsvinduer. Figur 217. Modal når noe blir slettet. 9.3 Designmodeller Single-Page Application (SPA) En Single-Page Application, eller SPA, er en applikasjon som gjengis på én side. Tanken bak dette er å gi brukere den samme opplevelsen som om det skulle vært en skrivebordapplikasjon. Det betyr at alle ressurser må hentes ved innlasting av siden, eller ved at ressursene hentes dynamisk når det er nødvendig. En SPA overlater aldri kontrollen til en annen side, og siden lastes aldri inn på nytt. Gjennom rammeverk kan man skape oppfatning av at man navigerer rundt en nettside. En av fordelene med SPA er at navigering er raskt. Siden alt, eller de største ressursene, allerede er lastet inn vil navigering kun medføre at man må laste inn mindre deler av applikasjonen. Samtidig er navigeringen 152

154 en utfordring. Med tanke på at hele applikasjonen lastes inn på en side, vil ikke navigering nødvendigvis legges inn i nettleserhistorien. For den generelle brukeren kan dette oppleves som negativt da man mister en del nettleserhistorikk. For «Bachelor Manager» var dette den naturlige tilnærmelsen å bruke. Den skal føles mer som en applikasjon enn en nettside, og ved å bruke SPA-modellen REST API REST API står for Representational State Transfer Application Programming Interface. I forbindelse med REST snakker man ofte eksponering av web-ressurser via en web-service. En web-ressurs kan være alt fra en database og dokumenter til kunstig intelligens som kan finne ut av hva som er på et bilde man gir det. En web service er det som gjør kommunikasjonen mellom to elektroniske enheter. Man ser gjerne på web-servicer som en service som tilbys av en enhet til en eller flere andre enheter. Denne kommunikasjonen foregår som regel ved bruk av HTTP (Hypertext Transfer Protocol) som primært er protokollen brukt for å utveksle informasjon over verdensveven. Det er ikke en klar definisjon på hvordan man skal bruke REST eller hvordan det skal kodes. Derimot er det prinsipper man skal følge for at servicen skal kunne kalles en REST-service. En REST-service skal være klient- og plattformuavhengig. I praksis vil det si at et brukergrensesnitt ikke skal være en del av servicen. Det at et brukergrensesnitt ikke er en direkte del av servicen, betyr at man heller kan se på brukergrensesnitt som en bruker som etterspør tjenester på ressursen servicen tilbyr. Siden denne overføringen av data foregår over HTTP er det ikke noen grense for hvordan dataen blir brukt og representert i et brukergrensesnitt. En REST-service skal være tilstandsløs. Med dette menes det at konteksten rundt en klient ikke blir lagret mellom forespørslene gjort mot servicen. Dette forutsetter at man i hver forespørsel sender med all informasjon som er nødvendig for å behandle den. Hvis ressursen krever innlogging, så må forespørselen inneholde tilstrekkelig informasjon for at servicen kan identifisere brukeren og deretter gi tilgang på ressursen. Når forespørselen er behandlet kuttes linjen og servicen er klar til å behandle en ny forespørsel Persistens / Data Access Persistence Layer eller Data Access Layer eksisterer mellom databasen og applikasjonen. Dette er for å isolere databaselogikken, så resten av applikasjonen ikke må forholde seg til den type logikk. Ofte er database relasjonsorientert, mens lagene over som BLL (Business Logic Layer) objektorientert. Med persistens laget vil for eksempel BLL slippe å forholdet seg til SQL. BLL skal kun kalle på getallcustomer-metoden og få en liste med kundeobjekter. Utviklere trenger ikke da å omstille seg fra objektorientert programmering til logikken som ligger i databasen. 153

155 Det finnes ulike verktøy og rammeverk som skaper abstraksjonen av databasen. Java EE for eksempel tilbyr JPA (Java Persistence API), som er et API/spesifikasjon for ORM (Object-Relational Mapping) og persistens. For at vanlige Java objekter skal kunne persisteres, benyttes ORM slik at databasen forstår objektene som sendes. Dette oppnås med å ha Java-klasser som skal representere entitetene i databasen. Annotasjoner brukes i koden for å fortelle JPA at feltene i Java-klassen samsvarer med kolonnene i en tabell. På denne måten kan rammeverket se hvordan den skal oversette objektet til en SQL setning som databasen forstår og eksekverer Repository Design Pattern Designet implementeres i Data Access Layer, og bygger på same prinsipper og mål et DAL har. Det vil si å isolere applikasjonen for databaselogikk. Dette oppnås ved å designe laget etter modellene applikasjonen trenger å persistere. For hver modell finnes det en repository som skal oppføre seg som en «collection». I repositorien skal det være mulig å legge til, hente basert på et kriterium, slette og oppdatere data. Vanligvis er det Business Logic Layer som kommuniserer med DAL. BLL skal da ikke vite at det skjer komplekse spørringer, i det BLL spør etter en bruker-modell med data fra bruker-repository. For å oppnå funksjonaliteten med kriterium benytter designet «Specification» objekter. Disse er objekter som inneholder spørringer. Disse sendes til databasen når BLL for eksempel ønsker alle brukere over 18 år. «Repository Design Pattern» kombineres ofte med «Specification Pattern» som er en mer avansert og fleksibel design på «Specification» objekter. 9.4 Arbeidsmetodikk KANBAN Arbeidsmetodikken Kanban fokuserer sterkt på prinsippet «just in time», og visualisering. Kanban kommer fra Japan og ble først utviklet som en smidig arbeidsmetodikk hos Toyota. Prinsippet «just in time» handler om å produsere når det er et behov for det. Det handler om å begrense antall oppgaver under arbeid (Work In Progress). Man skal gjøre oppgave etter hvert som det er et behov for det. Ved å fokusere på få oppgaver, reduserer man tid på alt det ekstra arbeider som følger det å jobbe med mange oppgaver samtidig. For eksempel å koordinere oppgavene, delegere ressurser og re-prioritering av oppgaver. Med Kanban handler det som i andre smidig-metodikk om å kunne utvikle og tilpasse arbeidsmåten, det er da viktig å se på arbeidsflyten i prosjektet. I Kanban er det viktig å analysere arbeidsflyten og forbedre den. 154

156 Det er derfor visualisering er spesielt viktig. For at gruppen skal kunne se hva som skjer i prosjektet til enhver tid. Ikke minst er det lettere å kommunisere innad i gruppen og man får se hva som er må gjøres for at prosjektet skal komme seg videre. Dette oppnås med Kanban-Tavle, der hver arbeidsoppgave er representert med en Post-it lapp. Oppgaven vil bli plassert på tavlen tilpasset statusen. Da kan hvem som helst i gruppen ta på seg oppgaver som har status «TO DO» for eksempel SCRUM Scrum er en agil arbeidsmetode som brukes hovedsakelig i utviklingsprosjekter. Det at Scrum er en agil arbeidsmetode betyr at den har iterasjonsbasert utvikling, rom for forandringer, kontinuerlig forbedringer og oppfordrer til fleksible endringer. Metoden har noen definerte roller i prosessen: Scrum-teamet. I scrum blir alt arbeidet levert til kunden av et scrum team. Gruppen består av en individer som arbeider sammen i inkrementer for å levere en ønsket løsning. Scrum master En scrum master fungerer som en team-leder som har noen spesifikke jobber o Skjerme teamet fra distraksjoner o Sørge for at ingen hindringer forekommer for teamet o Fungere som et kommunaksjonsled mellom gruppen og produkteier o Lede de forskjellige scrum aktivitetene Det er viktig at gruppen har stor tillit til scrum masteren. Som følge av dette er det mest idealt at scrum masteren velges utifra teamet, men som regel tas dette valget av ledelsen. Produkteier Produkteieren er personen som representerer sluttbrukeren og må sørge for at riktig arbeid blir gjort på riktig tidspunkt for å få størst verdi ut av produktet. Et resultat av dette er at produkteier må ha sterk kommunikasjon mellom teamet for å styre arbeidsflyten i prosjektet. Ingen andre enn produkteier har rettigheter til å endre prioritetene til teamet. Produkt backlog er en prioriteringsliste over brukerhistorierer og krav som må implementeres for å lage eller opprettholde et produkt. Produkteieren eier dette dokumentet og er den som prioriterer kravene/brukerhistoriene etter hva som gir mest verdi til kunden. Det er viktig at det som legges inn er detlajert og forståelig så det ikke kan misforstås Sprint backlog er en undergruppe av produkt backlog. Denne inneholder de noen av de viktigste brukerhistoriene fra produkt backlog. Antall brukerhistorier er avhengig av gruppens arbeidskraft. Hver brukerhistorie har arbeidsoppgaver som er nødvendig for å fullføre implementeringen av brukerhistorien. 155

157 En sprint er en arbeidsperiode som varer som regel to til fire uker. Etter hver eneste sprint skal det være et fungerende inkrement av produktet Gjennom denne perioden er skjer det en «daily stand-up» hver eneste dag. Denne er internt i scrum teamet og er med på å få en oversikt over arbeidsprosessen. Det som gås igjennom er hva som gikk bra, hva som ikke gikk bra og problemer/hindringer. Figur 218 Bilde av sprintprosessen Arbeidsprosessen går som følgende: 1. Produkteier lager en prioritert ønskeliste kalt produkt backlog 2. Under planlegging av en sprint velger gruppen de viktigste ønskene fra backloggen. Og utifra disse skaper arbeidsoppgaver som må fullføres. 3. Gjennom to til fire uker har gruppen som mål å fullføre arbeidsoppgavene, men de har daglige møter for å meddele prosessen. 4. En scrum master passer på at gruppen blir skjermet av distraheringer. 5. På slutten av hver sprint skal produktet være i en fungerende tilstand, klar til å vises til interessenter. 6. Selve sprinten slutter med en sprint review og retrospective. 7. Starte ny sprint, begynne fra punkt

158 9.5 Sprinter Sprint Mål Målet med første sprint var å sette opp et for systemet Sprintplanlegging Risikovurdering Første versjon av risikovurderingen. Den inneholdt mange forskjellige risikoer fra alle aspekter og risikoer som var linket til erfaring, egenskaper og kompetanse hadde stor sannsynlighet og konsekvens i dette stadiet av prosjektet Valgt brukerhistorier #5 Som administrator ønsker jeg å kunne tilegne en studentgruppe en eller flere veiledere slik at vi kan sikre at alle studentgrupper har minst en veileder #7 Som administrator ønsker jeg å kunne registrere studenter og grupper i systemet med kontaktinformasjon slik at disse kan knyttes sammen #24 Som administrator ønsker jeg å kunne registrere oppgaver i systemet slik at disse kan distribueres til studentgrupper Brukerhistoriene er valgt på bakgrunn av at de ligger høyt på prioriteringslisten, og dekker hovedfunksjonaliteten til løsningen Framgangsmåte Se punkt Sprint 1 planlegging Planlagt arbeid Brukerhistorie #5 og #7 krever disse arbeidsoppgavene her: Front-end o Lage en root «container»(gui) o Lage registrerings-view et for å kunne registrere studenter. o Lage registrerings-view et for å kunne registrere grupper. o Lage en service klasse som skal kommunisere med APIet Back-end o Moddellere back-end-arkitektur o Lage en «Controller» o Lage APIet som kommuniserer med databasen 157

159 Brukerhistorie #24 krever disse arbeidsoppgavene her: Front-end o Lage registrerings-view et for å kunne registrere oppgaver. o Lage oversikts-view et for å få oversikt over oppgaver. Back-end o Tilpasse kontrolleren for oppgaver. o Tilpasse API for oppgaver. Annet arbeid: Side panel med toggle funksjon. Dette gjør det mulig å navigere på applikasjonen og togglefunskjonen er ønsket av produkteier. Fikse en save-problem i back-end Sprint review Oppsummering Vi fikk utføre alt vi skulle men ut ifra burndown charten (se vedleg Sprint 1 Burndown), så er det stor avvik mellom planlagt arbeid og utført arbeid. Dette er på grunn av at vi planla 8 timer effektivt arbeid, mens vi egentlig bare brukte 6 timer Nye implementasjoner Front-end o Root «container» med en routeroutlet som sier hvor content skal plasseres o Lagd view for registering av grupper Velge tilgjengelige veileder(e) Legge til /fjerne tilgjengelige veildere Legge til /fjerne flere studenter i en gruppe o Lagd view for registering av oppgave Tittel og oppgavetekst Oppgaveteksten er en dynamisk textarea. o View over registrerte grupper o View over registrerte oppgaver o Routing av komponentene o Hver komponent er lagd som egne moduler med servicer og routing mm. o Sidebar Hver link lages dynamisk basert på en enum og legges i et eget menyitemkompontent ved bruk av transclusion. 158

160 o o o Emitter en event ved å trykke på sidebar knapp Animasjon Post metode for å sende skjema til API Get metode for å hente data fra API Hente gruppene som er registrert Hente oppgavene som er registrert Global Eventhandler service. Back-end o Docker conteinere API Database Mysql Angular2 o AWS Servere for deployment o API service GET, POST, PUT og DELETE Resources Statiske data som sendes til front-end Authorization: BASIC o Database INSERT Connection Nye brukerhistorier #25 Som administrator ønsker jeg å kunne åpne flere paneler slik at jeg kan få bedre oversikt Diskontinuerte brukerhistorier Etter vårt første møte med produkteier var det klart at disse brukerhistoriene måtte bli diskontinuert: #1 Som administrator ønsker jeg å kunne registrere mottatte søknader fra studentgrupper slik at vi har oversikt over alle grupper som har søkt om å skrive oppgave for oss i et gitt årskull #2 Som administrator ønsker jeg å kunne sette statusene "søknad mottatt", "til intervju", "godtatt" eller "avslag" på studentgruppene slik at jeg til enhver tid har oversikt over hvilke grupper som er i hvilket stadium 159

161 #3 Som administrator ønsker jeg å kunne oppgi kommentar på beslutninger tatt for en studentgruppe slik at vi kan gå tilbake i systemet og se på begrunnelser for avslag eller godkjente grupper Sprint retrospective Hva fungerte denne sprinten? o Målet ble oppnådd o Bra forståelse på Angular, moduler, services og routing. o Parprogrammering o Modellering var solid o Kodet ikke før vi visste hva vi skulle gjøre o Generell forståelse av et REST-api o Forståelse av HTTP-metoder og responser Hva fungerte ikke? o Feil oppstod som tok for lang tid å fikse o Lite testing Hva kan vi gjøre annerledes for å forbedre oss? o Mer effektive google-søk o Håkon må høre på kim. Ikke ignorere 5 timer o Mer testing Sprint Mål Forsete med forrige sprint mål, få i gang testing, starte med å implementere brukere i applikasjonen og starte med integrering av grid-system Sprintplanlegging Risikovurdering Andre versjon av risikovurderingen. Nye risikoer: #22 Overvurdere arbeidsmengde for en sprint #23 Undervurdere arbeidsmengde for en sprint Disse risikoene har forekommet og er veldig aktive under hele prosjektet. Diskontinuerte risikoer: #6 Server crasher/går ned 160

162 #16 Integrasjon mellom arkitekturlagene feiler #21 Sikkerhetsbarriere hos Accenture stanser utvikling Endringer: #2 Mangel på kunnskap. fra sannsynlighet 3, konsekvens 3 og risikofaktor 9 til sannsynlighet 5, konsekvens 3 og risikofaktor 15. Dette ble endret på fordi etter å ha prøvd å sette oss in i alle teknologiene vi skal bruke, merker vi at sannsynligheten for mangel av kunnskap har økt. #3 Sykdom. fra sannsynlighet 2, konsekvens 1 og risikofaktor 2 til sannsynlighet 1, konsekvens 1 og risikofaktor 1. Vi endret dette på grunn av at alle på gruppen aldri er syke og mener det er minimal sannsynlighet. #7 Server har ikke mer lagringsplass. fra sannsynlighet 1, konsekvens 5 og risikofaktor 5 til sannsynlighet 3, konsekvens 3 og risikofaktor 9. Denne endringen kommer med at risikoen faktisk forekom og vi måtte håndtere det. Konsekvensene var ikke fatale så vi endret den ned til 3. #12 Misforståelse av kravspesifikasjon. fra sannsynlighet 3, konsekvens 5 og risikofaktor 15 til sannsynlighet 2, konsekvens 4 og risikofaktor 8. Gruppen har god kontakt med produkteier og dermed mener vi at den kan endres til en lavere sannsynlighet og konsekvens. #14 Teknologien/verktøy som brukes mangler sikkerhet. fra sannsynlighet 3, konsekvens 4 og risikofaktor 12 til sannsynlighet 2, konsekvens 4 og risikofaktor 8. Teknologiene/verktøyene vi bruker er kjente og er godt dokumentert. Derfor mener vi at sannsynligheten minker #15 Teknologien/verktøy krasjer/stopper. fra sannsynlighet 3, konsekvens 1 og risikofaktor 3 til sannsynlighet 1, konsekvens 2 og risikofaktor 2. Teknologiene/verktøyene vi bruker er kjente og er godt dokumentert. Derfor mener vi at sannsynligheten minker, men konsekvensen øker fordi i dette stadiet av prosjektet føler vi at det ville vært farlige om teknologien/verktøyene krasjer/stopper. #18 Ikke følge arbeidsmetodikk. fra sannsynlighet 3, konsekvens 4 og risikofaktor 12 til sannsynlighet 3, konsekvens 2 og risikofaktor 2. Selv om vi ikke følger arbeidsmetodikken helt ordentlig så blir ikke konsekvensen så stor, dermed minke konsekvens. #19 Ikke re-evaluere risiko. fra sannsynlighet 2, konsekvens 4 og risikofaktor 8 til sannsynlighet 2, konsekvens 3 og risikofaktor 6. Siden vi ikke er på et veldig stort prosjekt, er ikke konsekvensene så store Valgt brukerhistorier #7 Som administrator ønsker jeg å kunne registrere studenter og grupper i systemet med kontaktinformasjon slik at disse kan knyttes sammen 161

163 #10 Som administrator ønsker jeg å kunne registrere nye brukere av systemet slik at alle brukere kan logge inn og finne relevant informasjon #24 Som administrator ønsker jeg å kunne registrere oppgaver i systemet slik at disse kan distribueres til studentgrupper #25 Som Administrator ønsker jeg å kunne åpne flere paneler slik at jeg kan få bedre oversikt #7 og #10 er valgt her grunnet forrige sprint ikke ble ferdig med brukerhistorien Framgangsmåte Se punkt Sprint 1 planlegging Planlagt arbeid Brukerhistorie #7, #10 og #24 krever disse arbeidsoppgavene her: Back-end o Registrere oppgaver i databasen o Registrere brukere i databasen o Registrere grupper i databasen o Integrering av databasen o Research av integrasjon av database/api o Få bruker fra database o Få oppgave fra database Brukerhistorie #25 krever disse arbeidsoppgavene her: Front-end o Integrere gridsystemet i løsningen vår o Få en komponent i et panel o Få kontroll over komponentene Testing krever disse arbeidsoppgavene her: Back-end o Testing av API o Testing av DAL Front-end o Testing av front-end Annet arbeid: Remodellere databasen 162

164 Sprint review Oppsummering Denne sprinten var mye bedre planlagt og førte til at burndown en(punkt Sprint 2 Burndown) hadde minimalt med avvik. Sen start på sprint grunnet sen sprint-review som kuttet sprinten ned til bare 9 dager. Selv om sprinten bare varte 9 dager, ble alle oppgave utført. Dette burde egentlig blitt reflektert i sprint burndown en, men vi på grunn av mangel på kunnskap om arbeidsmetodikken har vi ikke greid å følge dette Nye implementasjoner Front-end o Gridsystemet Gjør at vi kan flytte panelene. o Paneler («container» for komponentene) Kan forstørres Flere paneler åpne samtidig Fjerne et panel o Testing Research Karma Teste service o Mocking Teste komponenter Jasmine Back-end o Bruke repository o Design pattern o Database kjører Legge inn o Ressurser for User, Problem og Group o Prøver ny servicearkitektur (En generisk service) o Modelklasser med egen tojson o Klar for level 3 Rest 163

165 Nye brukerhistorier Etter møte med produkteier: #26 Som administrator skal jeg kunne minimere paneler slik at jeg kan få bedre oversikt Sprint retrospective Hva fungerte denne sprinten? o Fikk til ganske mye o Effektivt arbeid o Mye enklere å få opp panelet enn forventet o Bedre på scrummøte. Mer presist. o Testing Hva fungerte ikke? o Duy finner for mange kilder som fører til at han endrer mening på arkitektur o Testing av front-end, vanskelig å få til testing o Service på APIet fungerer ikke ennå o Ikke registrert ting på databasen via APIet o Håkon samarbeide bedre. Hva kan vi gjøre annerledes for å forbedre oss? o Bedre estimering Sprint Mål Minimering av paneler, registrere brukere, dokumentert litt og fortsettelse av testing Sprintplanlegging Risikovurdering Denne sprinten følte vi var en fortsettelse av forrige sprint så vi konkluderte med å ikke revurdere risikoene Valgt brukerhistorier #10 Som administrator ønsker jeg å kunne registrere nye brukere av systemet slik at alle brukere kan logge inn og finne relevant informasjon #17 Som administrator ønsker jeg å kunne registrere medlemmer av styringsgruppen fra år til år slik at jeg enkelt kan se hvem som sitter i styringsgruppen 164

166 #26 Som administrator ønsker jeg å kunne minimere paneler slik at jeg kan få bedre oversikt #26 er valgt på grunn av ønske fra produkteier. #10 og #17 går under registering av bruker og vill ofte være aktiv Framgangsmåte Se punkt Sprint 3 planlegging Planlagt arbeid Brukerhistorie #10 og #17 krever disse arbeidsoppgavene: Front-end o Lage et panel for registrering og view av bruker o Lage form for registrering av bruker o Koble sammen service til API o Lage en bruker-view for å se alle brukere Brukerhistorie #26 krever disse arbeidsoppgavene: Front-end o Funksjon som endrer størrelse på objektet o Event som holder styr på individuelle objekter o Oppdatere config filer for å kunne utføre brukerhistorien Testing krever disse arbeidsoppgavene: Front-end o Testing av HttpService o Testing av AssignmentFormComponent o Testing av GroupFormComponent Back-end o Testing av Service o Testing av Resource Uforventa arbeidsoppgaver: Presentasjon til ledelsen Accenture Security Compliance Kurs om Scrum/Maven/Spring Resterende arbeidsoppgaver: Få panelene til å flytte seg rundt smooth Scroll i y-retning når paneler begynner å fylle skjermen 165

167 Resize lock på x-retning når ett komponent treffer ytterkanten Kobling av API og database Skrive ferdig service'en Skrive ferdig alle repo's Skrive ferdig alle ressurser Få skoler in som en dropdown i GroupForm Sprint review Oppsummering Denne sprinten kom det veldig mye uforventa arbeid. Presentasjonen til ledelsen var ikke tatt hensyn til i planlegging selv om det er en del av arbeidet vi gjorde. Fortsatt så er mye av planleggingen vanskelig å få til riktig. Mye som er feil estimert og mange uforutsigbare oppgaver dukker opp. Vi byttet litt på hvordan vi arbeidet denne sprinten. Fra å gjøre alt arbeid delt i front-end og back-end til å ta for oss en brukerhistorie og få den til å fungere fra «create, read, update, delete» (CRUD). Så vi tok for oss f. eks. Registrering av bruker og prøver å få det til å lages og lagres i databasen, hente brukeren, oppdatere brukeren og til slutt slette brukeren Nye implementasjoner Generelt o CRUD bruker done. (Funker ikke back-end) Front-End o Bedre flyt i front-end o Edit user view o Trykke på en bruker for å få oversikt og endre. o Registrere user view Nye brukerhistorier #27 Som administrator skal jeg kunne bytte mellom gridpaneler eller statiske sider slik at jeg øker brukeropplevelsen min #28 Som administrator skal jeg kunne opprette tags slik at jeg kan definere roller #29 Som administrator skal jeg kunne søke gjennom alle tags slik at jeg kan finne en spesifikk tag #30 Som administrator skal jeg kunne søke gjennom alle brukere slik at jeg kan finne en spesifikk bruker 166

168 Sprint retrospective Hva fungerte denne sprinten? o Fant løsningene til oppgavene mye raskere enn det vi hadde trodd. o Vi fikk gjort mye og det var oppgaver som løste hverandre. o Presentasjonen til styringsgruppen o Bra med daily-stand-ups Hva fungerte ikke? o Database modellen sluttet å fungere. o Estimering og planlegging av sprint Hva kan vi gjøre annerledes for å forbedre oss? o Bedre gjennomtenkt sprint Sprint Mål Implementere tags i applikasjonen, fortsette med registrering av oppgave, grupper og studenter Sprintplanlegging Risikovurdering Tredje versjonen av risikovurderingen Nye risikoer: #24 Skade. Denne risikoen hadde forekommet i sprint 3 og hadde moderat med konsekvens. Dette var en risiko som ikke var tatt hensyn til og gjorde at vi mistet arbeidskraft. Diskontinuerte risikoer: #9 Scope blir feildefinert #14 Teknologien/verktøy som brukes mangler sikkerhet #15 Teknologien/verktøy krasjer/stopper Endringer: #7 Server har ikke mer lagringsplass. fra sannsynlighet 3, konsekvens 3 og risikofaktor 9 til sannsynlighet 3, konsekvens 2 og risikofaktor 6. Vi har nå flere servere å flytte systemet imellom som gjør at konsekvensen ikke er like stor lenger. 167

169 Valgt brukerhistorier #14 Administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet #19 Administrator ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet #20 Administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet #32 Administrator se alle oppgaver for å få oversikt #36 Bruker logge inn for å se relevant data Vi følte å kunne få en tags på bruker og gruppe var den største prioriteringen i denne stadiet av prosjektet. Så CRUD på tags var i sterk prioritering denne sprinten (#28, #29 og #30) Framgangsmåte Se punkt Sprint 4 planlegging Planlagt arbeid Brukerhistorie #6, #28, #29 og #30 krever disse arbeidsoppgavene: Front-end o Koble front-end mot API (Registrering av Tags) o Søkekomponent Back-end o Søkemotor API Brukerhistorie #7 krever disse arbeidsoppgavene: Back-end o Registrere gruppe på databasen Brukerhistorie #24 krever disse arbeidsoppgavene: Front-end o Registere oppgaver front-end Uforventa arbeidsoppgaver: Use case #26 168

170 Legge til eksisterende brukere Sidebar pimping Remodellering og Mapping Google Drive API Resterende arbeidsoppgaver: Få bruker basert på id fra databasen Kobling av API og database Forsette med første versjon av servicene Fortsette med første versjon av repo's Forsette med første versjon av ressursene Sprint review Oppsummering Denne sprinten var det ekstremt mye uforventa oppgaver som ble brukt tid på (67,5 timer). Google Drive API var noe nytt som vi ikke hadde brukt og måtte bruke mange timer på dette. Dette burde egentlig gå in planlagt arbeid, men ble ikke tatt hensyn til. Mye tid ble brukt på visuelt design av applikasjonen Nye implementasjoner Front-end o Søk På tags På navn På tags + navn o Sidepanel Styling Animasjon Ikoner o Tags Registrere tag Gi tag til gruppe, brukere Søke på tags o Minimering av paneler 169

171 o Registrere gruppe Legge til eksisterende studenter Legge til flere eksiterende studenter Back-end o Google drive API. Lagre fil Oppdatere fil Hente fil Hente filstruktur og sortere dem o UserService / UserResource Man kan nå søke via query params. Kombinert alle brukere med søk for å komprimere koden. o ProblemService / ProblemResource Full pipeline for å lagre fil er oppe. o GroupService / GroupResource Første versjon er klar. o TagService / TagResource Første versjon er klar o Ytterligere tester for ressurser og servicer o CRUD funksjoner for repositoriene klare o Tester for repositoriene o Remodellering av databasen Nye brukerhistorier Gruppen mener disse nye brukerhistoriene egentlig burde vært en del av første versjon av brukerhistoriene. Derfor er de lagt til når vi kom over brukerhistorie scenario et. #31 Som bruker ønsker jeg å kunne foreslå studenter som ønsker å skrive oppgave for Accenture slik at jeg kan skal kunne foreslå studenter for neste kull til administrator. #32 Som administrator ønsker jeg å se alle oppgaver slik at jeg kan få oversikt #33 Som bruker ønsker jeg å se alle mine oppgaver slik at jeg kan få oversikt #34 Som administrator ønsker jeg å se alle grupper slik at jeg kan få oversikt #35 Som administrator ønsker jeg å se alle brukere slik at jeg kan få oversikt #36 Som bruker logge inn for å se relevant data 170

172 Sprint retrospective Hva fungerte denne sprinten? o Fikk til det vi sa vi skulle få til + ekstra o Effektivt arbeid o Enda bedre på daily stand-ups. o Google API og opplastning av filer. o Mer respons fra Håkon. Hva fungerte ikke? o Fortsatt mange unexpected tasks o Mye remodellering av database. o Ingen UX eksperter tilgjengelig o Vanskelig å få tak I produkteiere Hva kan vi gjøre annerledes for å forbedre oss? o Bedre estimering Sprint Mål Bruker testing, implementerer innlogging, CRUD oppgave og filsystem Sprintplanlegging Risikovurdering Nye risikoer: #25 Feilestimering av sprint. Denne kommer in fordi det er for mye uforventa arbeidsoppgaver Valgt brukerhistorier #14 Som administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet #19 Som administrator ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet #20 Som administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet #32 Som administrator ønsker jeg å se alle oppgaver slik at jeg kan få oversikt 171

173 #36 Som bruker ønsker jeg å logge inn slik at jeg kan se relevant data Prioriteringen her gikk til innlogging og lagring av dokumenter Framgangsmåte Se punkt Sprint 5 planlegging Planlagt arbeid Brukerhistorie #6, #28, #29 og #30 krever disse arbeidsoppgavene: Front-end o Koble front-end mot API (Registrering av Tags) o Søkekomponent Back-end o Søkemotor API Brukerhistorie #7 krever disse arbeidsoppgavene: Back-end o Registrere gruppe på databasen Brukerhistorie #24 krever disse arbeidsoppgavene: Front-end o Registrere oppgaver front-end Brukertesting krever disse arbeidsoppgavene: Lage use cases Gjøre programmet klart for use case ene Observere brukertest Uforventa arbeidsoppgaver: Bm-loader Trekke student form ut av group og user JWT/Oauth Bli ferdig med CRUD grupper. Planlegge dokumentasjon Resterende arbeidsoppgaver: Søke på tags med type Søke på bruker 172

174 Vedlikeholde repo's Forsete med første versjon av ressursene og servicene Sprint review Oppsummering Denne sprinten fikk en reality check, Vi fikk bruker testet applikasjonen litt og fant ut at den ikke er stabil i det hele tatt. Masse bugs og ikke brukervennlig i det hele tatt. Vi satt en frist for å fiksene buggene og hvis det ikke hadde blitt fikset innen tiden, var planen å gå vekk fra grid-systemet. Brukertesting ble forsovet grunnet vanskeligheter med å få satt opp et tidlig møte med produkteier. Mye tid ble brukt på å fikse bugs på CRUD grupper. Dette ble satt høyt i prioriteringslisten etter at vi fant så mange bugs under brukertestingen Nye implementasjoner Front-end Gruppe o Tagg ene til student vises o Legge til eksisterende studenter (blitt filtrert ordentlig) o Endre student i gruppe Generisk student-form laget for å bli brukt på andre steder. Innlogging o View for innlogging Back-end Fikset en del bugs i GroupRepository Databasen remodellert og oppdatert AccountRepository, for innlogging og registrering o Hashing med BCrypt Repository kaster nå exceptions med passende feil melding Man kan laste opp, slette og oppdatere og hente filer. Vi har gått over til å bruke JWT. Flere bugfikser gjennom programmet generelt. 173

175 Nye brukerhistorier Gruppen mener disse nye brukerhistoriene egentlig burde vært en del av første versjon av brukerhistoriene. Derfor er de lagt til når vi kom over brukerhistorie scenario et. #31 Som bruker ønsker jeg å kunne foreslå studenter som ønsker å skrive oppgave for Accenture slik at jeg kan skal kunne foreslå studenter for neste kull til administrator. #32 Som administrator ønsker jeg å se alle oppgaver slik at jeg kan få oversikt #33 Som bruker ønsker jeg å se alle mine oppgaver slik at jeg kan få oversikt #34 Som administrator ønsker jeg å se alle grupper slik at jeg kan få oversikt #35 Som administrator ønsker jeg å se alle brukere slik at jeg kan få oversikt #36 Som bruker logge inn for å se relevant data Sprint retrospective Hva fungerte denne sprinten? o Vi fikk til mye o Fant problemer som vi greide å fikse o Google Drive API o CRUD Gruppe klar for brukertesting o getposition(null) fikset Hva fungerte ikke? o Ustabilt program Hva kan vi gjøre annerledes for å forbedre oss? o Feilsøke mer og teste programmet bedre Sprint Mål Bruker testing, dokumentere, endre hele programmet til å være statisk (kom etter at brukertestingen hadde blitt utført) Sprintplanlegging Risikovurdering Ingen endringer. 174

176 Valgt brukerhistorier #11 Som administrator ønsker jeg at kun administratorer skal kunne redigere studentgrupper slik at systemet i minst mulig grad kan misbrukes #14 Som administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet #15 Som bruker ønsker jeg at ingen andre brukere (utenom administratorer) skal kunne endre på oppgaver jeg har registrert at jeg til enhver tid vet hvordan min oppgave ser ut #19 Som administrator ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet #20 Som administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet #32 Som administrator ønsker jeg å se alle oppgaver for å få oversikt #36 Som bruker ønsker jeg å kunne logge inn slik at jeg kan se relevant data Disse brukerhistoriene ble prioritet før vi fant ut at vi måtte rekonstruere hele applikasjonen til en statisk løsning. Prioriteringen ble da: Restrukturere/konstruere front-end og back-end til en statisk løsning Dokumentasjon Framgangsmåte Se punkt Sprint 6 planlegging Planlagt arbeid Brukertesting krever disse arbeidsoppgavene: Lage use cases Gjøre programmet klart for use case ene Observere brukertest Brukerhistorie #32 og #14 krever disse arbeidsoppgavene: Lage view for å vise oppgaver Lage view for å endre på oppgaver Oppdatere databasen Sette opp til oppdatering Brukerhistorie #19 og #20 krever disse arbeidsoppgavene: Skrive videre på problem ressource 175

177 Google Drive API filehandler Skrive videre på problem service Brukerhistorie #36, #11 og #15 krever disse arbeidsoppgavene: Front-end logg inn view Endre hva en bruker kan se basert på tags Håndtering av innlogging Lagre brukerens informasjon på databasen Uforventa arbeidsoppgaver: Omstrukturere hele programmet til en statisk løsning Filsystem front-end I denne sprinten hadde vi også planlagt å ha 15,5 timer uforventa arbeidsoppgaver siden vi alltid har noe uforventa som må gjøres Sprint review Oppsummering Brukertestingen gikk ikke helt som planlagt. Vi hadde ikke forberedt oss godt nok og det var fortsatt for mange bugs som fortsatt ikke fikset. Dette kunne blitt bedre gjennomført hvis vi hadde brukt mer tid på å samarbeide med feilsøking tidligere. Under brukertestingen fikk vi en viktig tilbakemelding angående grid-systemet vi bruker: Uoversiktlig med så mange paneler Man endte ofte med å flytte på panelene før man brukte dem Vanskelig å endre størrelse på panelene Så konklusjonen ble å fjerne hele grid-systemet fra applikasjonen og heller gå over til en statisk løsning. Tanken her var at Alt startes fra en oversiktsside og alt som omhandler den oversikten skjer rundt der. F eks. gruppeoversikt viser alle bachelorgruppene, men har en legg til gruppe knapp Menyen kobles bare til oversiktssidene: gruppeoversikt, brukeroversikt, tagoversikt og oppgaveoversikt Det ble mye skrolling som skaper et ekstra unødvendig steg for å utføre en handling. Etter brukertestingen brukte vi mye tid på dette. 176

178 Dokumenteringen var også på tide å få på plass. Vi har skrevet litt underveis og begynte denne sprinten å fylle in på selve rapporten. Siden vi alle har dagbøker så er det veldig enkelt å finne ut hva som har blitt gjort når og sprintplanleggingen vår er grunnmuren bak utviklingsrapporten. Filsystemet med Google Drive API ble også jobbet med Nye implementasjoner Front-end Statisk løsning Routing Endringer på utseende Fjerne alt med grid Byttet material design med vanlig bootstrap Filsystem Front-end filsystem Laste opp word filer Nye brukerhistorier Ingen nye Diskontinuerte brukerhistorier Ingen diskontinuerte Sprint retrospective Hva fungerte denne sprinten? o Dokumentering o Vi hadde tatt mange notater fra før, så dokumenteringen ble litt lettere. o Implementasjon av filsystemet front-end Hva fungerte ikke? o Brukertesting o Motivasjon til å dokumentere Hva kan vi gjøre annerledes for å forbedre oss? o Forberedt brukertesten bedre o Mer struktur på «portingen» 177

179 9.5.7 Sprint Mål Implementere mail funksjon, passordreset, view for filsystem og dokumentasjon Sprintplanlegging Risikovurdering Ingen endringer Valgt brukerhistorier #12 Som administrator ønsker jeg at alle endringer på studentgrupper og brukere skal logges med fra og til status til egnet loggfil slik at jeg kan se hvem som har gjort hvilke endringer #14 Som administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet #19 Som administrator, bruker eller veileder ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet #20 Som administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet #21 Som administrator ønsker jeg å kunne generere mail til alle studenter i et årskull fra systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle studenter #22 Som administrator ønsker jeg å kunne generere mail til alle veiledere i et årskull fra systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle veiledere #23 Som administrator ønsker jeg å kunne generere mail til alle veiledere og studenter i et årskull fra systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle veiled #37 Som administrator ønsker jeg å sende passord-tilbakestillings-link til brukeren slik at de kan endre passord Framgangsmåte Se punkt Sprint 7 planlegging Planlagt arbeid Brukerhistorie #18 krever disse arbeidsoppgavene: Modellere databasen Fikse data accesslayer Brukerhistorie #19, #20 og #14 krever disse arbeidsoppgavene: Implementere knapp for å laste opp fil Research på «skrive over fil», eventuelt fiksing 178

180 Google API filehandler Brukerhistorie #12 krever disse arbeidsoppgavene: Implementere logger og bestemme hva som skal logges Brukerhistorie #21, #22 og #23 krever disse arbeidsoppgavene: Implementere mailfunksjon Brukerhistorie #37 krever disse arbeidsoppgavene: Lage view for passordresetting Lagring av det nye passordet Uforventa arbeidsoppgaver: Teksteditor Lage view for filsystem Resterende arbeidsoppgaver: Tilbakemelding og «action» når noe er registrert Endring av design Generalisere søk/fikse søk Brukertesting, feilsøking og design Sprint review Oppsummering Denne sprinten brukte vi mye tid på å implementere nye funskjoner, men også feilsøke på de gamle funksjonene vi allerede har. Mange funskjoner er fortsatt full av bugs og det jobbes hardt med å fjerne disse. Dokumenteringen er også i full gang og vi jobber med å få et førsteutkast av selve hovedrapporten ferdig. Mye mangler fortsatt sånn som produktrapport. Dette blir skrevet på seinere på grunn av ufullstendig produkt Nye implementasjoner Front-end Mail funksjon for brukere Teksteditor Endringer på utseende 179

181 Tilbakemeldings vinduer Nye brukerhistorier Ingen nye Diskontinuerte brukerhistorier Ingen diskontinuerte Sprint retrospective Hva fungerte denne sprinten? o Dokumentering o Text editoren var lett å få til o Mail funksjonen fungerer bra Hva fungerte ikke? o Motivasjon til å dokumentere Hva kan vi gjøre annerledes for å forbedre oss? o Ikke spore av for mye Sprint Mål Implementere mail funksjon, passordreset, view for filsystem og dokumentasjon Sprintplanlegging Risikovurdering Ingen endringer Valgt brukerhistorier #11 Som administrator ønsker jeg at kun administratorer skal kunne redigere studentgrupper slik at systemet i minst mulig grad kan misbrukes #12 Som administrator ønsker jeg at alle endringer på studentgrupper og brukere skal logges med fra og til status til egnet loggfil slik at jeg kan se hvem som har gjort hvilke endringer #14 Som administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet #19 Som administrator, bruker eller veileder ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet #20 Som administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet #36 Som bruker ønske jeg å kunne logge inn for å se relevant data 180

182 #37 Som administrator ønsker jeg å sende passord-tilbakestillings-link til brukeren slik at brukeren kan endre passord Disse er de resterende brukerhistoriene vi har igjen Framgangsmåte Se punkt Sprint 8 planlegging Planlagt arbeid Brukerhistorie #38 krever denne arbeidsoppgaven: Implementere mailfunksjon i gruppe Brukerhistorie #11 krever denne arbeidsoppgaven: Endre på hvilke oppgave gruppen er knyttet til Brukerhistorie #12 krever disse arbeidsoppgavene: Implementere logger og bestemme hva som skal logges Brukerhistorie #14 krever disse arbeidsoppgavene: Endre oppgaver/dokumenter Brukerhistorie #16 og #36 krever disse arbeidsoppgavene: Endre view når en bruker/veileder/admin er logget in Brukerhistorie #19 krever disse arbeidsoppgavene: Velge hvor filen skal lastes ned (front-end) Brukerhistorie #20 krever disse arbeidsoppgavene: Prompt (user input) om du vil lage duplikat av mappen hvis samme navn Brukerhistorie #37 krever disse arbeidsoppgavene: Lage view for passwordtilbakestilling Lagring av nye password Uforventa arbeidsoppgaver: Validering Sende mail fra API Resterende arbeidsoppgaver: Brukertesting, feilsøking og design 181

183 Sprint review Oppsummering Denne sprinten brukte vi tiden på å implementere det som manglet. Noe av det er fortsatt ikke fullstendig eller har bugs i seg. Første utkast av dokumentasjonen ble sendt og vurdert av intern sensor fra HiOA og vi fikk ny first til å lage en nyere og bedre iterasjon. Nye implementasjoner Front-end Mail funksjon for brukere Teksteditor Endringer på utseende Tilbakemeldings vinduer Nye brukerhistorier Ingen nye Diskontinuerte brukerhistorier Ingen diskontinuerte Sprint retrospective Hva fungerte denne sprinten? o Dokumentering Hva fungerte ikke? o Fortsatt mye som mangler av fullstendige funksjonalitet o Mye bugs. Hva kan vi gjøre annerledes for å forbedre oss? o Ikke spore av for mye Sprint Mål Få en presenterbart applikasjon og bli ferdig med rapporten 182

184 Sprintplanlegging Risikovurdering Ingen endringer Valgt brukerhistorier Ingen valgt brukerhistorier, bare dokumentasjon og feilsøking/bugfiksing igjen Framgangsmåte Se punkt Sprint 9 planlegging Planlagt arbeid Dokumentering og ferdigstilling Sprint review Oppsummering Siste sprint. Bruke mesteparten av tiden på å dokumentere og få fikset små feil i koden Nye brukerhistorier Ingen nye Diskontinuerte brukerhistorier Ingen diskontinuerte Sprint retrospective Hva fungerte denne sprinten? o Dokumentering o Brukertesting o Debugging Hva fungerte ikke? o Test serveren kom ikke opp før I denne sprinten Hva kan vi gjøre annerledes for å forbedre oss? 9.6 Sprint dokumentasjon Sprint 1 dokumenter Sprint 1 planlegging Backlog Item Responsib le Origina l Estimat e Da y 1 Da y 2 Da y 3 Da y 4 Da y 5 Da y 6 Da y 7 Da y 8 Da y 9 Da y 10 Da y 11 Da y 12 Da y 13 Sprint Revie w User Story #7,# Root Container (gui) H/K Tas k Tot al 183

185 Side panel w/ toggle Håkon Register panel (gui) Kim Group View Kim Servicer angular Kim Modellere back-endarkitektur A/D Controller (back-end) A/D API back-end A/D User Story # Register problem panel Kim, Håkon Problem list view Kim Extend controller for problem distribution A/D Back-end save problem A/D Extend API post/get problem A/D Total Sprint 1 review During this meeting, the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features. Userstory: #24, #7, (#5) 24 Administrator ønsker jeg å kunne registrere oppgaver i systemet slik at disse kan distribueres til studentgrupper 7 Administrator ønsker jeg å kunne registrere studenter og grupper i systemet med kontaktinformasjon slik at disse kan knyttes sammen 5 Administrator ønsker jeg å kunne tilegne en studentgruppe en eller flere veiledere slik at vi kan sikre at alle studentgrupper har minst en veileder I denne sprinten har vi delt oss in i 2 grupper: Front-end o Root container med en routeroutlet som sier hvor content skal plasseres o Lagd view for registering av grupper Velge tilgjengelige veileder(e) Legge til /fjerne tilgjengelige veildere Legge til /fjerne flere studenter i en gruppe o Lagd view for registering av oppgave Tittel og oppgavetekst Oppgaveteksten er en dynamisk textarea. o View over registrerte grupper o View over registrerte oppgaver 184

186 o o o o o o Routing av komponentene Hver komponent er lagd som egne moduler med servicer og routing mm. Sidebar Hver link lages dynamisk basert på en enum og legges i et eget menyitemkompontent ved bruk av transclusion. Emitter en event ved å trykke på sidebar knapp Animasjon Post metode for å sende skjema til API Get metode for å hente data fra API Hente gruppene som er registrert Hente oppgavene som er registrert Global Eventhandler service. Back-end o Docker conteinere API Mysql Angular2 o AWS Servere for deployment o API service GET, POST, PUT og DELETE Resources Statiske data som sendes til front-end Authorization: BASIC o Database INSERT Connection Sprint 1 retrospective What went well during the sprint cycle? o Målet ble oppnådd o Bra forståelse på Angular, moduler, services og routing. o Parprogrammering o Modellering var solid o Kodet ikke før vi visste hva vi skulle gjøre o Generell forståelse av et REST-api o Forståelse av HTTP-metoder og responser What went wrong during the sprint cycle? o Feil oppstod som tok for lang tid å fikse o Lite testing What could we do differently to improve? o Mer effektive google-søk o Håkon må høre på kim. Ikke ignorere 5 timer o Mer testing Sprint 1 Burndown Day Burned Down Balance Daily 185

187 Planned Actual Planned Actual Completed Completed Planned Actual Sprint 2 dokumenter Sprint 2 planlegging Backlog Item Responsibl e Statu s Original Estimat e Da y 1 Da y 2 Da y 3 Da y 4 Da y 5 Da y 6 Da y 7 Da y 8 Da y 9 Sprint Revie w User Story #7/#24/# Registrere oppgave på database Registrere bruker på database Registrere gruppe på database Duy, Adrian Duy, Adrian Duy, Adrian Task Tota l Integrering av database Duy Research av integrering av database/api Duy

188 Få bruker fra database Duy Få oppgave fra database Adrian User Story # Integrere et grid-system i løsningnen vår Få et komponent i et panel Kontrol over komponenter Kim, Håkon Kim, Håkon Kim, Håkon Testing Testing av API Testing av front-end Duy, Adrian Kim, Håkon Testing av DAL Duy Unexpected tasks Remodellering av database Duy Total Sprint 2 review Denne sprinten kom litt seinere I gang pga. sen review av forrige sprint. Dette har gjort denne sprinten veldig kort med bare 9 dager som førte til mindre oppgaver og mål denne sprinten. Userstory: #24, #7, #10, #25 24 Som administrator ønsker jeg å kunne registrere oppgaver i systemet slik at disse kan distribueres til studentgrupper 7 Som administrator ønsker jeg å kunne registrere studenter og grupper i systemet med kontaktinformasjon slik at disse kan knyttes sammen 10 Som administrator ønsker jeg å kunne registrere/godkjenne nye brukere av systemet slik at alle brukere kan logge inn og finne relevant informasjon 25 Som administrator ønsker jeg å kunne åpne flere paneler slik at jeg kan få bedre oversikt Front-end o Gridsystemet Gjør at vi kan flytte panelene. o Paneler (containere for komponentene) Kan forstørres Flere paneler åpne samtidig Fjerne et panel o Testing Research Karma Teste service o Mocking Teste komponenter Jasmine 187

189 Back-end o Bruke repository o Design pattern o Database kjører Legge inn o Ressurser for User, Problem og Group o Prøver ny servicearkitektur (En generisk service) o Modelklasser med egen tojson o Klar for level 3 Rest Sprint 2 retrospective What went well during the sprint cycle? o Fikk til ganske mye o Effektivt arbeid o Mye enklere å få opp panelet enn forventet o Bedre på scrummøte. Mer presist. o Testing What went wrong during the sprint cycle? o Duy finner for mange kilder som fører til at han endrer mening på arkitektur o Testing av front-end, vanskelig å få til testing o Service på APIet fungerer ikke ennå o Ikke registrert ting på databasen via APIet o Håkon samarbeide bedre. What could we do differently to improve? o Bedre estimering Sprint 2 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed

190 Planned Actual Sprint 3 dokumenter Sprint 3 planlegging Backlog Item Respons ible Stat us Origin al Estim ate Da y 1 Da y 2 User Story # Funksjon som endrer størrelse på objektet Event som holder styr på individuelle objekter Se over config og gjøre endringer Da y 3 Da y 4 Da y 5 Da y 6 Da y 7 Da y 8 Da y 9 Da y 10 Da y 11 Da y 12 Da y 13 Sprin t Revi ew Kim Kim Kim, Håkon User Story #10/# Lage et panel for registering og view av bruker Lage form for registering av bruker Koble sammen med service til API Lage en bruker-view for å se alle brukere Kim, Håkon Kim Kim , 5 2, 5 0, 6 0, , 5 0, 5 Tas k Tot al 16, 5 10, , ,9 Kim Overordnet Dokumentering Alle ,5 7, , 5 4, , 5 2, 5 13,5 72 5,5 38 Møte med veiledere Alle Daily stand-up Alle Sprint-planlegging Alle Sprint review/retrospective Alle Testing , 5 2,5 15 Testing av HttpService Håkon Testing av AssingmentFormComponent Testing av GroupFromComponent Håkon ,5 8,5 Håkon Testing av service(api) Adrian , 5 0 2,5 189

191 Testing av ressurser(api) Adrian Unexpected tasks Kurs om Scrum/Maven/Spring Accenture Security Compliance Duy Presentasjon til ledelsen Interne problemer Få panelene til å flytte seg rundt smooth Scroll i y-retning når paneler begynner å fylle skjermen Kim, Håkon , 5 4, , ,5 Håkon Resize lock på x-retning når et komponent treffer ytterkanten Håkon Kobling av API og database Adrian, Duy Skrive ferdig service'en Adrian Skrive ferdig alle repo's Duy Skrive ferdig alle ressurser Adrian Få skoler in som en dropdown i GroupForm 6, 5 1, Kim Total Sprint 3 review Denne sprinten var veldig, med tanke på at det ble for mange «unexpected tasks» som gjorde at vi brukte mye tid på det istedenfor task ene vi hadde satt oss. Selv om vi hadde mange «unexpected tasks» så rakk vi å fullføre alle målene i sprinten vår. (Dårlig planlegging?) En stor task vi ikke tok hensyn til i sprinten var presentasjonen til styremedlemmene. Etter tips fra fredrik valgte vi å ta en top-down approach der vi går gjennom hele prosessen av en userstory, og får dette til å fungere. Front-end og back-end. Denne gangen tok vi CRUD bruker Userstory: #17, #10, #26 17 Som administrator ønsker jeg å kunne registrere medlemmer av styringsgruppen fra år til år slik at jeg enkelt kan se hvem som sitter i styringsgruppen 10 Som administrator ønsker jeg å kunne registrere/godkjenne nye brukere av systemet slik at alle brukere kan logge inn og finne relevant informasjon 26 Som administrator ønsker jeg å kunne minimere paneler slik at jeg kan få bedre oversikt Generelt o CRUD bruker done. (Funker ikke back-end) 190

192 Front-End o Bedre flyt i front-end o Edit user view o Trykke på en bruker for å få oversikt og endre. o Registere user view Hva vi ikke fikk til: User Story #26. Vanskelig å finne noe om å minimere Testing av HttpService Testing av GroupFormComponent Skrive ferdig alle repo s(vil aldri være aktiv) Skrive ferdig alle ressurser (vil aldri være aktiv) Sprint 3 retrospective What went well during the sprint cycle? o Fant løsningene til oppgavene mye raskere enn det vi hadde trodd. o Vi fikk gjort mye og det var oppgaver som løste hverandre. o Presentasjonen til styringsgruppen o Bra med daily-stand-ups What went wrong during the sprint cycle? o Database modellen sluttet å fungere. o Estimering og planlegging av sprint What could we do differently to improve? o Bedre gjennomtenkt sprint Sprint 3 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed

193 Daily Completed Planned Actual Sprint 4 dokumenter Sprint 4 planlegging Backlog Item User Story #6/#28/#29/#30 Koble front-end mot API (Registrering av Tags) Søkekomponent Søkemotor API User Story #24 Registere oppgaver front-end Resp onsi ble St at us Ori gin al Esti ma te , ,5 5,5 Kim , ,5 0 Kim, Håko n Adri an Kim ,5 2 5, , ,2 5 7, User Story # , Registere gruppe på databasen Overordnet Dokumentering Møte med veiledere Duy , Alle 75, 5 40, 5 9, ,5 3 3, , ,5 1 1, Alle Daily stand-up Alle Sprint-planlegging Alle Sprint review/retrospectiv e Alle Sp rin t Re vie w T as k T ot al 3 1, , 5 7, 5 7, 5 3 9, 5 8,

194 Testing 38 9, ,5 6, ,5 4,5 3,5 Testing av UserFormCompone nt Testing av AssingmentViewCo mponent Testing av GroupFromCompo nent Testing av Repositories Testing av service(api) Testing av ressurser(api) Håko n Håko n Håko n , ,5 3, Duy ,5 4,5 3,5 Adri an Adri an 8 2, Unexpected tasks ,5 6,5 18,5 19, ,5 5,5 5,5 Use case #26 Kim , Legge til eksisterende brukere Sidebar pimping Remodellering og Mapping Google Drive API Interne problemer Få bruker basert på id fra databasen Kobling av API og database Forsette med første versjon av servicene Fortsette med første versjon av repo's Forsette med første versjon av ressursene Kim , Håko n , ,5 5,5 5,5 Duy Adri an ,5 6,5 6, , , , ,5 6,5 Kim Adri an, Duy Adri an Duy Adri an ,25 37, , , ,25 Total ,2 5 2, , , 5 7, , 5 5, 5 1 4, , , , Sprint 4 retrospective What went well during the sprint cycle? o Fikk til det vi sa vi skulle få til + ekstra o Effektivt arbeid o Enda bedre på daily stand-ups. o Google API og opplastning av filer. o Mer respons fra Håkon. What went wrong during the sprint cycle? o Fortsatt mange unexpected tasks 193

195 o Mye remodellering av database. o Ingen UX eksperter tilgjengelig o Vanskelig å få tak I produkteiere What could we do differently to improve? o Bedre estimering Sprint 4 review Måtte sette oss inn i google drive API. Det kom med utfordringer som var uvant. De bruker en referansebasert filstruktur der filene sitt forhold til foreldrene kun er basert på en ID. Dette førte til at en vanlig fremstilling av filsystemet ble vanskelig. Planen nå er å gå for noe som likner på windows. Der man kun ser innholdet av mappen og må navigere seg videre. Endret på at grupper skal ha tags for å gi den skoletag og eventuelt andre tags. Userstory: #6,#28,#29,#30,#24,#7,#26 6 Administrator ønsker jeg å kunne tilegne alle brukere i systemet rollen veileder slik at systemet håndterer at alle personer kan være veiledere 28 Administrator kunne opprette tags definere roller 29 Administrator kunne søke gjennom alle tags for å finne en spesifikk tag 30 Administrator kunne søke gjennom alle brukere for å finne en spesifikk bruker 24 Som administrator ønsker jeg å kunne registrere oppgaver i systemet slik at disse kan distribueres til studentgrupper 7 Som administrator ønsker jeg å kunne registrere studenter og grupper i systemet med kontaktinformasjon slik at disse kan knyttes sammen 26 Administrator kunne minimere paneler slik at jeg kan få bedre oversikt Front-end o Søk På tags På navn På tags + navn o Sidepanel Styling Animasjon Ikoner o Tags Registrere tag Gi tag til gruppe, brukere Søke på tags o Minimering av paneler o Registrere gruppe 194

196 Legge til eksisterende studenter Legge til flere eksiterende studenter Back-end o Google drive API. Lagre fil Oppdatere fil Hente fil Hente filstruktur og sortere dem o UserService / UserResource Man kan nå søke via query params. Kombinert alle brukere med søk for å komprimere koden. o ProblemService / ProblemResource Full pipeline for å lagre fil er oppe. o GroupService / GroupResource Første versjon er klar. o TagService / TagResource Første versjon er klar o Ytterligere tester for ressurser og servicer o CRUD funksjoner for repositoriene klare o Tester for repositoriene o Remodellering av databasen Sprint 4 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed

197 Daily Completed Planned Actual Sprint 5 dokumenter Sprint 5 planlegging Backlog Item Resp onsi ble St at us Ori gin al Esti ma te Bruker testing Lage use cases Alle Gjøre programmet klar for use case'ene Observere bruker test User Story #32/14 Lage view for å vise oppgaver Lage view for å endre på oppgaver Oppdatere databasen Sette opp til oppdatering User Story #19/#20 Skrive videre på problem ressource Google Drive API filehandler Skrive videre på problem service User Story #36 Front-end logg inn view Endre hva en bruker kan se basert på tags Håndtering av innlogging Alle Alle Kim Kim Adri an Adri an Adri an Adri an Adri an Kim, Håko n Kim, Håko n Duy , , , , , , ,5 7 6,5 0 Sp rin t Re vie w T as k T ot al 1 2, 5 8, 5 6, 5 6, 5 196

198 Lagre brukerens informasjon pådatabase Duy Overordnet , Dokumentering Alle ,5 1, Møte med veiledere Alle Daily stand-up Alle , Sprintplanlegging Sprint review/retrospect ive Testing Testing av UserFormCompo nent Testing av AssingmentViewC omponent Testing av MenuComponent Testing av GroupFromComp onent Testing av service(api) Testing av ressurser(api) Unexpected tasks Bm-loader Trekke student form ut av group og user JWT/Oauth Bli ferdig med CRUD grupper. Planlegge dokumentasjon Alle Alle Håko n Håko n Håko n Håko n Adri an Adri an Håko n Kim, Håko n Adri an Kim 25, , , , , , ,2 5 3, ,5 0 6, ,5 6, ,5 5,5 6, ,5 3, Rest tasks Søke på tags med type Kim Søke på bruker Kim Vedlikeholde repo's Forsette med første versjon av ressursene og servicene Duy ,5 0 6, Adri an ,5 0 6, Total ,5 15, , 5 5 5, , 5 6 6, ,

199 Sprint 5 review Mye av denne sprinten gikk til å få til CRUD bruker og fikse generelle bugs i programmet.(ikke planlagt). Selv om vi gjorde mye uplanlagt så ble mange mål fortsatt truffet. Fant ut at programmet er ganske ustabilt og tok et steg tilbake for å få den til å bli mer stabil Brukertesting ble litt forskyvet pga. vanskeligheter med å få tak i produkteier/sluttbruker. Userstory: #14,#19,#20,#36 14 Administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet 19 Administrator ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet 20 Administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet 32 Administrator se alle oppgaver for å få oversikt 36 Bruker logge inn for å se relevant data Front-end Gruppe o Tagg ene til student vises o Legge til eksisterende studenter (blitt filtrert ordentlig) o Endre student i gruppe Generisk student-form laget for å bli brukt på andre steder. Innlogging o View for innlogging Back-end Fikset en del bugs i GroupRepository Databasen remodellert og oppdatert AccountRepository, for innlogging og registrering o Hashing med BCrypt Repository kaster nå exceptions med passende feil melding Man kan laste opp, slette og oppdatere og hente filer. Vi har gått over til å bruke JWT. Flere bugfikser gjennom programmet generelt. 198

200 Sprint 5 retrospective What went well during the sprint cycle? o Vi fikk til mye o Fant problemer som vi greide å fikse o Google Drive API o CRUD Gruppe klar for brukertesting o getposition(null) fikset What went wrong during the sprint cycle? o Ustabilt program What could we do differently to improve? o Feilsøke mer og teste programmet bedre Sprint 5 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed , , , , , Daily Completed Planned Actual 199

201 9.6.6 Sprint 6 dokumenter Sprint 6 planlegging Backlog Item Resp onsi ble St at us Ori gin al Esti ma te Brukertesting Lage use cases Alle Gjøre programmet klar for use case'ene Utførelse av brukertest Alle Alle User Story #32/14 3, Lage view for å vise oppgaver Lage view for å endre på oppgaver User Story #19/#20 Skrive videre på problem ressource Google Drive API filehandler Skrive videre på problem service User Story #36/#11/#15 Endre hva en bruker kan se basert på tags Kim Kim 2, Adri an Adri an Adri an Kim, Håk on 16, , , , Overordnet Dokumentering Alle Møte med veiledere Alle Daily stand-up Alle Sprint-planlegging Alle Sprint review/retrospectiv e Alle Testing Testing av UserFormCompone nt Testing av AssingmentViewCo mponent Testing av MenuComponent Testing av GroupFromCompon ent Håk on Håk on Håk on Håk on Sp rin t Re vie w T as k T ot al , 5 1 8,

202 Testing av service(api) Testing av ressurser(api) Unexpected tasks Adri an Adri an , Unexpected tasks Kim Unexpected tasks Redesigne hele programmet til en statisk løsning Filsystem front-end Håk on 9, Alle Adri an Exception handling Rest tasks Reloade sider når noe oppdateres/lages/sl ettet Lage restriksjoner Kim, på hvilke tag som Håk kan gis on Testing og bugfiksing av Duy system Forsette med første versjon av Adri ressursene og an servicene 38, , Total , , Sprint 6 review Vi hadde en brukertest 2. dagen i denne sprinten. Dette endte med at vi måtte fjerne grid-systemet vårt for å øke brukeropplevelsen. Det ble ikke brukervennlig med gridsystemet. Så alle brukerhistoriene som var planlagt å jobbe med ble satt på pause for å flytte alt det vi hadde over til en statisk løsning. Halve sprinten skulle vi skrive dokumentasjon. Dette var veldig vellykket og vi fikk til å skrive mange ord. Vi forskjøv sprinten 1 dag ekstra for å kunne se gjennom dokumentasjonen før vi sendte den videre. Userstory: #11, #14, #15, #19, #20, #32, #36 #11 Som administrator ønsker jeg at kun administratorer skal kunne redigere studentgrupper slik at systemet i minst mulig grad kan misbrukes #14 Som administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet 201

203 #15 Som bruker ønsker jeg at ingen andre brukere (utenom administratorer) skal kunne endre på oppgaver jeg har registrert at jeg til enhver tid vet hvordan min oppgave ser ut #19 Som administrator ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet #20 Som administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet #32 Som administrator ønsker jeg å se alle oppgaver for å få oversikt #36 Som bruker ønsker jeg å kunne logge inn slik at jeg kan se relevant data Front-end Statisk løsning Routing Endringer på utseende Fjerne alt med grid Byttet material design med vanlig bootstrap Filsystem Front-end filsystem Laste opp filer Sprint 6 retrospective What went well during the sprint cycle? o Dokumentering o Vi hadde tatt mange notater fra før, så dokumenteringen ble litt lettere. o Implementasjon av filsystemet front-end What went wrong during the sprint cycle? o Brukertesting o Motivasjon til å dokumentere What could we do differently to improve? o Forberedt brukertesten bedre o Mer struktur på «portingen Sprint 6 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed , , ,

204 , Daily Completed Planned Actual Sprint 7 dokumenter Sprint 7 planlegging Backlog Item User Story #19/#20/#14 Implementere knapp for å laste opp Research på "skrive over fil", eventuelt fiksing Google Drive API filehandler Respon sible St at us Ori gin al Est im ate Adrian Adrian Adrian User Story # Modellere databasen Duy Fikse dataaccesslayer Duy User Story # Implementere logger og bestemme hva som skal logges User Story #21/#22/#23 Implementere mail funksjon Adrian Adrian, Håkon, Kim User Story # Sp rin t Re vi e w T as k T ot al

205 Lage view for passwordtilbakestillin g Lagring av nye password Overordnet Dokumentering Adrian Adrian Alle Møte med veiledere Alle Daily stand-up Alle Sprint-planlegging Alle Sprint review/retrospective Alle Testing Testing av UserFormComponent Testing av AssingmentViewCom ponent Testing av MenuComponent Testing av GroupFromCompone nt Testing av service(api) Testing av ressurser(api) Håkon Håkon Håkon Håkon Adrian Adrian Unexpected tasks Unexpected tasks Alle Hjelp andre Alle Text editor Kim Lage view for filsystem Adrian Rest tasks Tilbakemelding og "action" når noe er registrert Endring av design Generalisere søk/fikse søk Brukertesting, feilsøking og design Total Kim, Håkon Kim, Håkon Kim, Håkon Duy , 5 0, 5 8, , , , Sprint 7 review Denne sprinten handlet mye om å implementasjon av funskjoner som mail og oppgave. Userstory: #12, #14, #19, #20, #21, #22, #23, #37 204

206 12 Som administrator ønsker jeg at alle endringer på studentgrupper og brukere skal logges med fra og til status til egnet loggfil slik at jeg kan se hvem som har gjort hvilke endringer 14 Som administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet 19 Som alle ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet 20 Som administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet 21 Som administrator ønsker jeg å kunne generere mail til alle studenter i et årskull fra systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle studenter 22 Som administrator ønsker jeg å kunne generere mail til alle veiledere i et årskull fra systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle veiledere 23 Som administrator ønsker jeg å kunne generere mail til alle veiledere og studenter i et årskull fra systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle veiled 37 Administrator sende password-tilbakestillings-link til brukerenendre password Front-end Maile brukere Text Editor Mye redesign Tilbakemeldings vindu Filsystem Front-end filsystem Laste opp filer Sprint 7 retrospective What went well during the sprint cycle? o Dokumentering o Text editoren var lett å få til o Mail funksjonen fungerer bra What went wrong during the sprint cycle? o Motivasjon til å dokumentere What could we do differently to improve? o Ikke spore av for mye 205

207 Sprint 7 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed , , Daily Completed Planned Actual Sprint 8 dokumenter Sprint 8 planlegging Backlog Item Resp onsi ble St at us Ori gin al Est im ate User Story # Implementere mail funksjon i gruppe Kim User Story # Sp rin t Re vie w T a s k T o ta l

208 Endre på hvilke oppgave gruppen er knyttet til Adri an, Håk on, Kim User Story # Implementere logger og bestemme hva som skal logges Adri an User Story # Endre på oppgave/dokumenter Adri an, Håk on User Story #16/# Endre view når en bruker/veileder/admi n er logget in Kim, Håk on User Story # Velge hvor filen skal lastes ned (Front-end) Kim, Håk on User Story # Prompt (user input) om du vil lage duplikat av mappen hvis samme navn Kim, Håk on, Adri an User Story # Lage view for passwordtilbakestillin g Lagring av nye password Overordnet Dokumentering Adri an Adri an Alle Møte med veiledere Alle Daily stand-up Alle Sprint-planlegging Alle Sprint review/retrospective Alle Testing Testing av UserFormComponent Testing av AssingmentViewComp onent Testing av MenuComponent Testing av GroupFromComponen t Testing av service(api) Testing av ressurser(api) Håk on Håk on Håk on Håk on Adri an Adri an Unexpected tasks Unexpected tasks Alle Validering Kim

209 Sende mail fra API Adri an Rest tasks Brukertesting, feilsøking og design Total Alle Sprint 8 review Denne sprinten handlet mye om å implementasjon av funskjoner som mail og oppgave. Userstory: #11, #12, #14, #19, #20, #36, #37 11 Administrator ønsker jeg at kun administratorer skal kunne redigere studentgrupper slik at systemet i minst mulig grad kan misbrukes 12 Administrator ønsker jeg at alle endringer på studentgrupper og brukere skal logges med fra og til status til egnet loggfil slik at jeg kan se hvem som har gjort hvilke endringer 14 Administrator ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere slik at jeg på en effektiv måte kan bruke systemet 19 Alle ønsker jeg å kunne laste opp dokumenter i mapper slik at vi kan laste opp relevante dokumenter i systemet 20 Administrator ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter slik at jeg kan editere dokumenter i systemet 36 Bruker logge inn for å se relevant data 37 Administrator sende password-tilbakestillings-link til brukerenendre password Fikset og implemenert det siste som manglet + masse dokumentering Sprint 8 retrospective What went well during the sprint cycle? o Fiksa masse bugs o Alt er implementert What went wrong during the sprint cycle? o Fant masse bugs o Fortsatt mye bugs 208

210 What could we do differently to improve? o Finne mindre bugs o Lage begrensninger Sprint 8 Burndown Day Burned Down Balance Planned Actual Planned Actual Daily Completed Planned Actual Sprint 9 dokumenter Sprint 9 planlegging Backlog Item Resp onsib le St at us Ori gin al Esti mat e D U E D A TE Spr int Re vie w Ta sk T ot al 209

211 Overordnet Dokumenter ing Sprintplanlegging Sprint review/retro spective Alle Alle Alle Rest tasks Brukertestin g, feilsøking og design Alle Total Sprint 9 review Denne sprinten har teamet bare jobbet med rapport og ferdigteste løsningen. Ingen nye funksjoner implementert bare feilsøking og testing av disse. Dokumentasjonen ble endelig på ca 250 sider Sprint 9 retrospective What went well during the sprint cycle? o Dokumentering o Brukertesting o Debugging What went wrong during the sprint cycle? o Test serveren kom ikke opp før I denne sprinten What could we do differently to improve? 210

212 Sprint 9 Burndown Eksempel daily stand-up Figur 219 Eksempel på daily stand-up 9.7 Testing Vi har valgt å ikke integrasjonsteste på grunn av mangel av tid Brukertesting Brukertest 1 Observert av Alle i gruppen Bruker Christian og Fredrik (produkteiere) Dato Oppgave 1 Teste grid-systemet. 211

213 Observasjoner Hva gjør brukeren? Hva skriver brukeren? Finner ikke fram de andre panelet som blir trykket på, de legger seg under. Ingen tilbakemelding når man registrerer oppgaver Opprett gruppe viser alle tags Mangler student 1,2,3 Student1, Student2. Velg veileder ødelegger programmet. Tags fjernes ikke på hver bruker når en bruker er registrert Bruker Fritekstsøk Filter Avansert søk Hjelp Logg in Ny bruker Back-knappen Navigasjon Sitater Sitater fra brukeren, uttalelser om systemet eller brukeropplevelsen Tid «Hvor er panelet?» «Hvor er det jeg akkurat åpna?» «Vanskelig å ta tak i «resize» knappen» «Hvordan bruker jeg dette?» «Lag en mer brukervennlig versjon» Start 16:15 Stopp 16:30 Tid brukt 15min Max tid: Udefinert Oppgave fullført? Ja Tja Nei Var dette brukervennlig? Note to self Statisk løsning? Husk å spørre om etter testen 212

214 Konklusjon Vi var ikke klare for denne brukertesten og det var definitivt ikke applikasjonen vår. For mange bugs og ufullstendig prosesser. Grid-systemet er ikke brukervennlig. Det ble for mye med mange paneler og det er ikke intuitivt hvor de legger seg når de skapes/flyttes. Noe som var ønsket var at alt skulle startes fra en oversiktsside også navigere seg derfra. Fjerne grid-systemet fra løsningen vår. Gå over til statiske sider. 9.8 Prototype Brukergrensesnitt v2 Gruppe oversiktsside Veileder oversiktsside 213

215 Oppgave oversiktsside Brukeroversiktsside Styringsgruppe 214

216 Dokumenter Hentet Prototype Brukergrensesnitt v1 Hentet

217 9.10 Brukerhistorier - Planlegging Som Ønsker jeg Slik at Administrator å kunne registrere mottatte søknader fra studentgrupper vi har oversikt over alle grupper som har søkt om å skrive oppgave for oss i et gitt årskull Administrator å kunne sette statusene "søknad mottatt", "til intervju", "godtatt" eller "avslag" på studentgruppene jeg til envhver tid har oversikt over hvilke grupper som er i hvilket stadium Administrator å kunne oppgi kommentar på beslutninger tatt for en studentgruppe vi kan gå tilbake i systemet og se på begrunnelser for avslag eller godkjente grupper Administrator muligheten til å opprette årskull for bachelorprogrammet Administrator å kunne tilegne en studentgruppe en eller flere veiledere Administrator å kunne tilegne alle brukere i systemet rollen veileder jeg på en enkel måte kan knytte oppgaver, veiledere og studentgrupper til et årskull å kunne tilegne en studentgruppe en eller flere veiledere systemet håndterer at alle personer kan være veiledere Administrator å kunne registrere studenter i systemet med kontaktinformasjon disse kan knyttes til studentgrupper Administrator å kunne knytte veiledere til studentgrupper jeg enkelt kan se hvilke veileder(e) som veileder hvilken studentgruppe Bruker å kunne registrere meg i systemet at jeg kan bruke systemet Administrator å kunne godkjenne nye brukere av systemet Administrator at kun administratorer skal kunne redigere studentgrupper Administrator at alle endringer på studentgrupper og brukere skal logges med fra og til status til egnet loggfil alle brukere kan logge inn og finne relevant informasjon systemet i minst mulig grad kan misbrukes jeg kan se hvem som har gjort hvilke endringer 216

218 Bruker å kunne registrere oppgaver i systemet disse kan distribueres til studentgrupper Administrator å kunne endre studenter, studentgrupper, oppgaver og brukere jeg på en effektiv måte kan bruke systemet Bruker at ingen andre brukere (utenom administratorer) skal kunne endre på jeg til enhver tid vet hvordan min oppgave ser ut oppgaver jeg har registrert Veileder at jeg får opp relevant informasjon om de(n) gruppen(e) jeg veileder når jeg logger inn jeg enkelt kan finne informasjon jeg trenger Administrator å kunne registrere medlemmer av styringsgruppen fra år til år jeg enkelt kan se hvem som sitter i styringsgruppen Administrator å kunne registrere referat fra vi har referat av disse møtene styringsgruppemøter for de individuelle studentgruppene Administrator å kunne laste opp dokumenter i mapper vi kan laste opp relevante dokumenter i systemet Administrator å kunne laste opp dokumenter og skrive over eksisterende dokumenter jeg kan editere dokumenter i systemet Administrator å kunne generere mail til alle studenter i et årskull fra systemet Administrator å kunne generere mail til alle veiledere i et årskull fra systemet Administrator å kunne generere mail til alle veiledere og studenter i et årskull fra systemet jeg på en effektiv måte kan sende ut informasjon til alle studenter jeg på en effektiv måte kan sende ut informasjon til alle veiledere jeg på en effektiv måte kan sende ut informasjon til alle veiledere og studenter 9.11 Brukerhistorier - Endelig Fargekoder: Rød diskontinuert Grønn påbegynt Blå Ferdig 217

219 User Story (#) As a <type of user> 1 Administrator 2 Administrator 3 Administrator 4 Administrator 5 Administrator 6 Administrator 7 Administrator 8 Administrator 9 Bruker 10 Administrator 11 Administrator 12 Administrator 13 Bruker 14 Administrator 15 Bruker 16 Veileder I want to <perform some task> ønsker jeg å kunne registrere mottatte søknader fra studentgrupper ønsker jeg å kunne sette statusene "søknad mottatt", "til intervju", "godtatt" eller "avslag" på studentgruppene ønsker jeg å kunne oppgi kommentar på beslutninger tatt for en studentgruppe ønsker jeg muligheten til å opprette årskull for bachelorprogrammet ønsker jeg å kunne tilegne en studentgruppe en eller flere veiledere ønsker jeg å kunne tilegne alle brukere i systemet rollen veileder ønsker jeg å kunne registrere studenter og grupper i systemet med kontaktinformasjon ønsker jeg å kunne knytte veiledere til studentgrupper ønsker jeg å kunne registrere meg i systemet ønsker jeg å kunne registrere nye brukere av systemet ønsker jeg at kun administratorer skal kunne redigere studentgrupper ønsker jeg at alle endringer på studentgrupper og brukere skal logges med fra og til status til egnet loggfil ønsker jeg å kunne registrere oppgaver i systemet ønsker jeg å kunne endre studenter, studentgrupper, oppgaver og brukere ønsker jeg at ingen andre brukere (utenom administratorer) skal kunne endre på oppgaver jeg har registrert ønsker jeg at jeg får opp relevant informasjon om de(n) gruppen(e) jeg veileder når jeg logger inn So that I can <achieve some goal> slik at vi har oversikt over alle grupper som har søkt om å skrive oppgave for oss i et gitt årskull slik at jeg til en hver tid har oversikt over hvilke grupper som er i hvilket stadium slik at vi kan gå tilbake i systemet og se på begrunnelser for avslag eller godkjente grupper slik at jeg på en enkel måte kan knytte oppgaver, veiledere og studentgrupper til et årskull slik at vi kan sikre at alle studentgrupper har minst en veileder slik at systemet håndterer at alle personer kan være veiledere slik at disse kan knyttes sammen slik at jeg enkelt kan se hvilke veileder(e) som veileder hvilken studentgruppe slik at jeg kan bruke systemet slik at alle brukere kan logge inn og finne relevant informasjon slik at systemet i minst mulig grad kan misbrukes slik at jeg kan se hvem som har gjort hvilke endringer slik at disse kan distribueres til studentgrupper slik at jeg på en effektiv måte kan bruke systemet slik at jeg til en hver tid vet hvordan min oppgave ser ut slik at jeg enkelt kan finne informasjon jeg trenger 218

220 17 Administrator 18 Administrator 19 Alle 20 Administrator 21 Administrator 22 Administrator 23 Administrator ønsker jeg å kunne registrere medlemmer av styringsgruppen fra år til år ønsker jeg å kunne registrere referat fra styringsgruppemøter for de individuelle studentgruppene ønsker jeg å kunne laste opp dokumenter i mapper ønsker jeg å kunne laste opp dokumenter og skrive over eksisterende dokumenter ønsker jeg å kunne generere mail til alle studenter i et årskull fra systemet ønsker jeg å kunne generere mail til alle veiledere i et årskull fra systemet ønsker jeg å kunne generere mail til alle veiledere og studenter i et årskull fra systemet slik at jeg enkelt kan se hvem som sitter i styringsgruppen slik at vi har referat av disse møtene slik at vi kan laste opp relevante dokumenter i systemet slik at jeg kan editere dokumenter i systemet slik at jeg på en effektiv måte kan sende ut informasjon til alle studenter slik at jeg på en effektiv måte kan sende ut informasjon til alle veiledere slik at jeg på en effektiv måte kan sende ut informasjon til alle veiled 24 Administrator ønsker jeg å kunne registrere slik at disse kan distribueres til oppgaver i systemet studentgrupper 25 Administrator ønsker jeg å kunne åpne flere paneler slik at jeg kan få bedre oversikt 26 Administrator kunne minimere paneler slik at jeg kan få bedre oversikt 27 Administrator kunne bytte mellom gridpaneler slik at jeg kan øke brukeropplevelsen eller statiske sider min 28 Administrator kunne opprette tags definere roller 29 Administrator kunne søke gjennom alle tags for å finne en spesifikk tag 30 Administrator kunne søke gjennom alle brukere for å finne en spesifikk bruker 31 Bruker foreslå studenter som ønsker å for å kunne foreslå studenter for skrive oppgave for Accenture neste kull til administrator 32 Administrator se alle oppgaver for å få oversikt 33 Bruker se alle mine oppgaver for å få oversikt 34 Administrator se alle grupper for å få oversikt 35 Administrator se alle brukere for å få oversikt 36 Bruker logge inn for å se relevant data 37 Administrator 38 Administrator, (veileder?) sende password-tilbakestillingslink til brukeren sende mail til alle i en gruppe endre password enkelt sende mail til alle medlemene i en gruppe 9.12 Risikovurdering Røde rader indikerer diskontinuerte risikoer. # Risiko Beskrivelse Årsak Sansyneli ghet Konsek vens Risikofa ktor Tiltak Eier Status 219

221 1 Feilestimering av tid Estimere for mye eller for lite tid for prosjektet Eksempel: undervurder e hvor vanskelig det er å implemente re en løsning Revurdere tidsbruk underveis? Forekom met og håndtert 2 Mangel på kunnskap Mangel på kunnskap i form av programmering sspråk, verktøy og teknologier Eksempel: Lite tid, tidlere ikke relevant Få i seg kunnskap via lesing,forskning eller læring? Forekom met og håndtert 3 Sykdom Noen i teamet blir syke og har ikke anledning til å være tilstede 4 Dårlig kommunikasj on med veiledere 5 Dårlig kommunikasj on med produkteier Lite kommunikasjo n eller misforståelse med veileder Lite kommunikasjo n eller misforståelse med produkteier Eksempel: Språkbarrier e, lite engasjert Eksempel: Språkbarrier e, lite engasjert Spise sunt, kle seg godt, trene Bli godt kjent med veileder Møtereferat fra alle møtene, og sørge for at alle partner forståer hverandre Alle Alle, Veilede re Alle, Produkt eier Forekom met og håndtert Ikke forekom met Ikke forekom met 6 Server crasher/går ned 7 Server har ikke mer lagringsplass 8 Mangel på lisens på software Server som blir brukt til å "Hoste" Docker crasher eller går ned Server som blir brukt til å "Hoste" Docker går tom for lagringsplass Software som vi bruker til å utvikle applikasjonen trenger en lisens for å brukes Eksempel: AWS stenger tilgang Eksempel: For store bilder blir lagret på serveren og tar opp alt lagring Eksempel: Office Sørge for at vi har en oppdatert kopi Sørge for at serveren er av en stor nok instanse Se om arbeidgiver kan gi lisens før programmet brukes. Alle Alle Ikke forekom met Forekom met og håndtert Ikke forekom met 9 Scope blir feildefinert Scopen blir definert dårlig eller feil og gjør at prosjektets størrelse varierer Eksempel: Tar med noe i scopen som ikke er nødvendig Snakke med produkteier/veile der detlajert før scope defineres Alle, veileder e, produkt eier Ikke forekom met 1 0 Vi legger til unødvendige funksjoner som ikke er innenfor scope Eksempel: Tar med søknaden i applikasjone n(noe som ikke var en del av bruker historiene) Snakke med produkteier/veile der detlajert før scope defineres Alle, veileder e, produkt eier Ikke forekom met 220

222 For mange drastiske endringer som endrer kompleksitete n av prosjektet og hindrer at nøkkelfunksjo ner å bli implementert Misforståelse av kravspesifikas jon Kravspesifikasj onen gitt av produkteier blir misforstått eller tolket feil. Eksempel: Tar i bruk SonarQube sent i prosjektet Eksempel: Språkbarrier e, uenigheter Bli enige om prosjektets rammebetingelse r Bli enige fra alle partner og sørge for at alt er forstått Alle Alle, veileder e, produkt eier Ikke forekom met Ikke forekom met Miste motivasjon Teknologien/v erktøy som brukes mangler sikkerthet Lite motivasjon over tid Teknologien/ve rktøy håndterer ikke sikkerhet og det skaper et problem for applikasjonen Eksempel: Miste intresse, Prosjektet er ikke gjennomfør bar Alle Ikke forekom met Sørge for at sikkerhet alltid blr opprettholdt på en eller annen måte Alle Ikke forekom met Teknologien/v erktøy krasjer/stopp er Integrasjon mellom arkitekturlage ne feiler Vi leverer noe som ikke er ønsket Teknologien/ve rktøy stopper å fungere, noe som medfører stans eller problemer Lagdelingen feiler når vi prøver å sette dem sammen Det som produkteier ønsker blir ikke levert Eksempel: IntelliJ slutter å fungere Eksempel: JavaEE koden er ikke kompatibel med det som er skrevet i Angular Holde programmet/tek onlogien oppdatert Forske på om de forskjellige språkene som ligger i lagene er kompatible Sørge for at produkteier er med under hele prosjektet Alle Alle Alle Ikke forekom met Ikke forekom met Ikke forekom met 1 8 Ikke følge arbeidsmetod ikk Arbeidsmetodi kk blir ikke fulgt helt og viktige sprinter og møter blir ingorert Eksempel: Droppe dailystandu p, ikke følge sprinter Følge at alle er med på de målene som er satt for en arbeidsmetode Alle Ikke forekom met 1 9 Ikke reevaluering av risiko Vi glemmer å kontinuerlig reevaluere risikoene under prosjekter Kan være mange årsaker til dette, manglende tid Sørge for å alltid ha en reevaluering som den del av sprint planleggingen Alle Forekom met og håndtert 221

223 Bruk av teknologi som ikke blir støttet i fremtiden Sikkerhetsbar rierer hos Accenture stanser utviklingen Vi bruker et upoplært språk som ikke blir oppdatert. Software eller lignende blir blokkert av sikkerhet hos Accenture som medfører stans av utvikling Eksempel: Bruk av ASP Eksempel: Docker får ikke koblet til porter så containere for ikke kommuniser e Ungå teknologier som er gamle og utdaterte Forsikre oss om at sikkerhetsbarrier ene ikke medfører oss full stans Alle Alle Ikke forekom met Forekom met og håndtert Overvurdere arbeidsmengd e for en sprint Undervurdere arbeidsmengd e for en sprint Planlegger for mye for en sprint Planlegger for lite for en sprint Eksempel: Teste frontend, men det er mye vanskeligere å få til testene Eksempel: Testing mye mindre tid en forventet Snakke med veileder, anta at alt arbeid tar mye lengre tid Snakke med veileder, anta at alt arbeid tar mye lengre tid Alle Alle Ikke forekom met Forekom met og håndtert 2 4 Skade Eksempel: Treningsska de Kan ikke gjøre noen tiltak Alle Forekom met og håndtert 2 5 Feilestimering av sprint Eksempel: Mye unexpected task som ikke er planlagt Lage rom for uforventede oppgaver Alle Forekom met og håndtert 9.13 Komponentstruktur Mer om konseptet bak komponenter se punkt Komponenter 222

224 Editor 223

225 Filsystem 224

226 GroupForm 225

227 GroupView 226

228 Sidemeny 227

229 TagView 228

230 UserView 229

231 Passwordreset 230

232 9.14 Modalstruktur Mer om konseptet bak moduler se punkt Moduler AddStudent 231

233 Confirm 232

234 CreateFolder 233

235 ForgotPassword 234

236 RegisterTag 235

237 RegisterUser 236

238 TagChooser 237

239 Warning 238

240 9.15 Delte komponenter Alert 239

241 Loading 240

242 PageNotFound Search 241

243 TextEditor 242

244 UserForm 243