Denne siden er blank med hensikt.

Transkript

1 Me s ocl oudcr M Hov e dpr os j e k t v å r E r i kma x i mi l i a nf or s ma n, s S i me nandr éha ns e n, s L a r she nr i knor dl i, s

2 Denne siden er blank med hensikt.

3 PROSJEKT NR. 32 a Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Offentlig HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Meso Cloud CRM DATO 20.Mai 2014 ANTALL SIDER TOTALT / VEDLEGG 305 / 82 PROSJEKTDELTAKERE Erik Maximilian Forsman s163351@stud.hioa.no Lars Henrik Nordli s180492@stud.hioa.no Simen André Hansen s180493@stud.hioa.no INTERN VEILEDER Yngve Lindsjørn yngve.lindsjorn@hioa.no OPPDRAGSGIVER Meso Capital Markets KONTAKTPERSON Lasse Bøe lb@mesocm.no SAMMENDRAG CRM (Customer Relationship Management) med kontraktsopprettelse for invisteringsrådgivere med lagring i skyen 3 STIKKORD CRM PDF Laravel/PHP

4 Denne siden er blank med hensikt.

5 Forord Dette produktet er et resultat av hovedprosjekt ved Høgskolen i Oslo og Akershus (HiOA), avdeling for ingeniørutdanning, våren Vi vil gjerne takke oppdragsgiver, Meso Capital Markets for et interresant og utfordrene prosjekt. Og for gode tilbakemeldinger og entusiasme rundt vårt arbeid gjennom hele prosjektperioden. Leserveiledning Denne rapporten følger Høgskolen i Oslo og Akershus dokumentstandard 1 så langt det er hensiksmessig, men har med momenter som reflekterer produktstrukturen vi har fulgt på en bedre måte. Rapporten bygger på hoveddelene kravspesifikasjon, prosessdokumentasjon, produktdokumentasjon, testdokumentasjon og brukerveiledning, samt appendikser. Denne rapporten er laget slik at innholdfortegnelsene er klikkbare, og egner seg derfor godt å leses digitalt. Oppbygningen av rapporten er slik at man ikke skal trenge noen større teknisk innsikt for å lese hoveddelene av rapporten, men alikevel få likt stor forståelse og utbytte av innholdet. Har man større teknisk innsikt eller ønsker en dypere gjennomgang av den kodetekniske strukturen og oppbyggnigen i webapplikasjonen kan man lese de to tekniske appendiksene, Appendiks A for PDFtk (Kapittel 7) og Appendiks B for Laravel (Kapittel 8). Som siste vedlegg (vedlegg 9.5) i rapporten er det vedlagt en DVD med komplett kildekode for webapplikasjonen, samt anvisninger til en kjørbar versjon av applikasjonen (Merk! Gjelder fysisk sluttraport)

6 Oppsummering Vår oppdragsgiver i dette prosjektet var Meso Capital Markets 2 og er en uavhengig aktør i det norske markedet for finansielle tjenester som tilbyr investeringsrådgivning og kapitalforvaltning til formuende privatpersoner og institusjonelle investorer. Deres arbeidshverdag består av å ha møter med kunder hvor de skriver under kjøps- og salgskontrakter, i tillegg til å følge opp eksisterende kunder. Meso Cloud CRM er en webbasert applikasjon utviklet for og i samarbeid med Meso Capital Markets. Applikasjonen er en reaksjon på bedriftens misnøye rundt dagens utvalg av programvare relevant til deres arbeidshverdag. Dette innebærer kunde-, ansatt- og kontraktsbehandling samt kalenderfunksjonalitet. Særlig dagens behandling av kontrakter blir gjort med penn og papir og en digitalisering av dette vil være meget hensiktsmessig. Ved å bytte ut deres nåværende tre systemer med ett system har vi og oppdragsgiver tro på at det vil gi deres arbeidshverdag et løft. Primærfunksjonaliteten til applikasjonen er følgende: Opprette, se og endre kunder Opprette, se, endre og slette ansatte Opprette og se kontrakter Opprette, se, endre, slette og legge ved vedleggsskjemaer til en kontrakt Signere kontrakter med eventuelle kontraktsvedlegg og ha et arkiv over disse Distribuere ferdig utfylte og signerte kontrakter til alle parter Opprette og se kalenderavtaler Knytte en kalenderavtale opp mot en kontrakt og en kunde Vi er fornøyde med oppgavevalget, utviklingsprosessen og metodikken som ble brukt til å utvikle det ferdige produktet. Etter kravene som ble 2 6

7 satt tidlig i prosjektet ble alle disse oppfylt og vi anser derfor dette som et vellykket prosjektarbeid. Gjennomgående i prosjektet har vi tilegnet oss god erfaring og kunnskap som vi vil få omfattende nytte av i vårt fremtidige arbeids- og privatliv. 7

8 Denne siden er blank med hensikt.

9 Innholdsfortegnelse 1 Kravspesifikasjon Forord Presentasjon Om bakgrunnen Motivasjon Funksjonalitet Kort systembeskrivelse Rammekrav i systemet Funksjonelle krav Ikke-funksjonelle krav Prosessdokumentasjon Forord Forbedredelser og planlegging Valget av oppgaven Definere oppgaven og omfang Finne riktig rammeverk Oppstartsfasen Utviklingsverktøy Netbeans IDE 7/ Git & Github Trello Google Docs Dropbox Testmiljø L A TEX & Texmaker Om utviklingsprosessen (Utviklingsmetodikk) Innledning

10 2.4.2 Daglige utfordringer Gruppesiden Dagbok Scrumbrett Versjonskontroll Møter med veileder Møter med oppdragsgiver Kravspesifikasjonen og dens rolle Endringer i kravspesifikasjonen underveis Kravspesifikasjonens betydning for webapplikasjonen Samsvar med endelig kravspesifikasjon Fremdriftsplan og dens rolle Innledning Tre utviklingsfaser Tidsberegning Samspillet mellom fremdriftplan og scrumbrett Designutvikling Refleksjoner og utbytte Innledning Ting vi ville gjort annerledes Tverrfaglig utbytte Veien videre Nytteverdi for oppdragsgiver Oppdragsgiver om webapplikasjonen Oppsummering og konklusjoner Produktdokumentasjon Forord Beskrivelse av webapplikasjonen Hva webapplikasjonen gjør i korte trekk Webapplikasjonens byggeklosser Samsvar mellom kravspesifikasjon og ferdig produkt Sentrale datastrukturer i programmet Innledning På et overordnet plan - MVC De sentrale modellene Modellrelasjoner Handlinger

11 3.4.6 Roller Logger Biblioteker Mappestruktur Programmets virkemåte Oppstart av webapplikasjonen Ansatthandlinger i nettleseren Kundehandlinger i nettleseren Ansatthandlinger i bruk Kundehandlinger i bruk Spesifikke handlinger i bruk PDF håndtering Design Innledning Brukersentrert design Brukergrensesnitt (UI) Brukeropplevelse (UX) Optimalisering for tablets og smarttelefoner Universell utforming Rammeverk og teknologier tatt i bruk Sikkerhet Kryptert kommunikasjon - HTTPS Filaksess Passordblokkering Regex Backup Systemkrav Klientside Serverside Testdokumentasjon Forord Enhetstesting Formål med testen Utførte tester Gjenstående testing Utforming av testen Testing av modeller

12 4.2.6 Testing av controllere Assertions Kjøring av enhetstest/enhetstester Resultater og tiltak Brukertest Formål med testen Utforming av testen Resultater og tiltak Belastningstest Gjennomføring av testen Resultater av testen Konklusjon av testen Brukerveiledning Forord Terminologi Innledning Veiledning Innlogging, utlogging og glemt passord Søk Kunde Ansatt Kontrakt Skjema Kalender For deg som bruker Feil- og rettingsmuligheter Oppslag Figurer Kodesnutter Kilder Appendiks A: Teknisk appendiks for PDFtk Forord Programvare Bruk i applikasjonen Konfigurere skjemaer

13 7.5 Fylle ut skjemaer Fyll ut data Generering av XFDF Unik XFDF-fil for hver ansatt Kombinere XFDF og mal Kontraktskansellering Appendiks B: Teknisk appendiks for Laravel Forord Laravelversjon Composer Artisan Rammerverkets mappestruktur Filters Filters overs HTTPS Routes Database og modeller Databasedefinisjon Migrations Seeds Eloquent Mange-til-mange-relasjoner Softdeletes Views Innledning Mappestruktur for views Views for ansatthandlinger(useractions) Gjenbruk Controllere Generelt om controllere UsersAction- og CustomerController Sikkerhetsfaktorer Filaksess Backdoor SorteringsID Ting vi kunne gjort annerledes og forbedringspotensiale Databasemodell Flere controllere

14 8.13 Design Layouts Blade Visualisering Ikoner Bruk av CSS-filer CSS Media-queries LESS.css Vedlegg Prosjektdagbok Fremdriftsplaner Fremdriftsplan for implementering Fremdriftsplan for testing og rapport Møter med oppragsgiver Møte 21.Januar Møte 10.Februar Møte 7.Mars Møte 4.April Brukertest Brukertestoppgaven Resultater brukertest Kildekode og anvisninger til kjørbar versjon For fysisk sluttrapport For digital sluttrapport

15 Kapittel 1 Kravspesifikasjon 1.1 Forord Denne kravspesifikasjonen er ment som en hjelp til veileder, gruppemedlemmene og oppdragsgiver for å viske ut eventuell tvil om hva som skal lages. Ved å definere avgrensninger, funksjonalitet og nytteverdi av hva som skal lages øker vi forståelsesevnen til alle parter. Denne kravspesifikasjonen har vært til god hjelp i tilfeller hvor vi har vært usikre på om en funksjon er med i omfanget av prosjektet eller ikke. Contents 1.1 Forord Presentasjon Om bakgrunnen Motivasjon Funksjonalitet Kort systembeskrivelse Rammekrav i systemet Funksjonelle krav Ikke-funksjonelle krav

16 Denne siden er blank med hensikt.

17 1.2 Presentasjon Tittel Meso PDF (arbeidstittel) Definisjon Meso PDF er en webapplikasjon som skal håndtere PDF-dokumenter, fortrinnsvis kjøpskontrakter som skal fylles inn, og proseseres via web. Tjenesten skal laste inn eksisterende PDF-dokumenter og gjenkjenne hvilke posisjoner som kan fylles ut og generere opp en rekke input-felter i webtjenesten som skal kunne fylles ut direkte derfra. Oppdragsgiver skal så kunne koble opp disse skjemaene mot ny eller eksisterende kunde. Tjenesten skal også kunne lagre PDF-ene som et arkiv i skyen. Gruppemedlemmer Erik Maximilian Forsman Lars Henrik Nordli Simen André Hansen Gruppenummer 32 Oppdragsgiver Meso Capital Markets Kontraktperson hos oppdragsgiver Investeringsrådgiver Lasse Bøe lb@mesocm.no Intern veileder Høgskolelektor Yngve Lindsjørn yngve.lindsjorn@hioa.no 1.3 Om bakgrunnen Motivasjon Meso PDF er en webapplikasjon som fungerer som et CRM-system for bedriften Meso Capital Markets, som heretter vil bli referert til som oppdragsgiver. Webapplikasjonen er en reaksjon på utfordringene som oppdragsgiver har hatt tidligere, og kan bli beskrevet slik: Enklere utfylling av kjøps- og salgskontraker som før ble fylt ut med penn og papir og gjennom utallige kopierings- og utskrivningsprosesser. Disse prosessene blir forenklet i webapplikasjonen ved å lagre kundeinformasjon og digitalisere kontraktskrivingsprosessen. 17

18 1.3.2 Funksjonalitet Webapplikasjonen skal ha mulighet for at en bruker skal logge inn, for så å komme til en side hvor den kan velge mellom forskjellige handlinger som skal gjøres. Herunder kjøp, salg eller kjøp og salg. Brukeren skal også ha mulighet til å laste opp vedleggsskjemaer til kontraktene, hvor disse skal analyseres for utfyllbare felter og lagres i databasen. Brukeren skal så kunne velge å knytte en kontrakt, med tilhørende vedleggsskjema(er), til en ny eller eksisterende kunde. Kontrakten og tilhørende vedleggsskjema skal så fylles ut med (oppgitt) kundeinformasjon og eventuell annen gjentakende tilleggsinformasjon slik at dette ikke trengs å skrives inn flere ganger. Ansvarlig ansatt, kontrakt, vedleggsskjemaer og kundeinformasjon samt knytningen mellom disse skal så lagres i en database og gis mulighet til å skrive ut og sendes på e-post til valgte parter og eventuelt lagres på brukernes egne datamaskiner. Brukerne skal også ha roller som bestemmer tilgangsnivåer som se, opprette, endre slette og lignende. Applikasjonen skal være webbasert og skal primært fungere på bærbare og stasjonære datamaskiner, og idéelt også smarttelefoner og nettbrett med nettlesere. 1.4 Kort systembeskrivelse Systemet skal effektivisere og forenkle prosessen med å skrive kontrakter, med og uten kontraktvedlegg, og å knytte de opp mot nye eller eksisterende kunder. Dette gjøres i dag med penn og papir. Webapplikasjonen skal ha følgende overordnet funksjonalitet: Opprette, endre og vise kunde Opprette, endre, slette og vise ansatte Opprette, endre og vise kontraktvedleggsskjema Opprette, lagre og vise en kontrakt, og knytte denne opp mot ansatt, kunde og kontraktvedleggsskjema Kansellére kontrakt Skrive ut kontrakt 18

19 Sende kontrakt med tilhørende kontraktsvedlegg og kundeinformasjon på e-post til valgte parter Lagre alle kontrakter på egen datamaskin Se figur 1.1 for å se generell gang i systemet, og figur 1.2 for en skisse av databaseoppsett. Figur 1.1: Figur av den generelle gangen i systemet. 1.5 Rammekrav i systemet Følgende rammekrav og forutsetninger er satt for systemet: Webapplikasjonen krever en bærbar eller stasjonær datamaskin og/eller smarttelefon/nettbrett for å kunne brukes. Webapplikasjonen krever en nettleser for å kjøre. Dette følger med de aller fleste nye og eldre datamaskiner. Dette kan være nettlesere som Mozilla Firefox, Microsoft Internet Explorer, Google Chrome og lignende. 19

20 Figur 1.2: Skisse av databaseoppsett. Webapplikasjonen krever at enheten den kjører på har tilgang til internett. Hastighet er ikke et krav for at webapplikasjonen skal fungere. Webapplikasjonen krever at oppdragsgiver selv har server eller at leverandør av serverløsninger eksisterer. Oppdragsgiver og/eller leverandør er ansvarlig for oppetid. Verktøy som skal taes i bruk i utviklingen: Netbeans IDE som teksteditor Git og GitHub for versjonskontroll Adobe Photoshop CS5 for design og mock-ups 20

21 Adobe Acrobat Reader Pro til PDF-håndtering Dia for tegning av figurer og diagrammer WAMP/LAMP til lokalt testmiljø Trello til SCRUM-metodikk Programmeringsspråk som skal taes i bruk i utviklingen: HTML5 CSS3 JavaScript/jQuery PHP5 PHP-rammeverket Laravel LESS MySQL Bash Powershell 21

22 1.6 Funksjonelle krav 2 A En admin skal kunne legge til en ny bruker 3 A En bruker skal ha en profil som viser personalia 4 A Brukerprofilen skal vise hendelseslogg for brukeren 5 A En admin skal kunne endre på brukerpersonalia og rolle # Prioritet Krav Spesifisering 1 A En bruker skal kunne logge En bruker får tildelt innloggingsinformasjon inn for å få aksess til systemet. Når en admin har mulighet til å legge til flere brukere i systemet. En bruker har oversikt over personaliaen på en egen side samt andres så fremt de har en rolle som gir tilgang En bruker kan se sin egen logg og andres logger så fremt de har en rolle som gir tilgang En bruker med admin-rolle kan endre personalia på alle brukere i systemet med unntak av passord. 6 A En bruker skal ha en rolle Hver enkelt bruker som blir lagt til skal ha en rolle som har gitte muligheter. 7 A En bruker skal ikke kunne utføre uautoriserte handlinger/operasjoner 8 A Systemet skal forhindre uautorisert tilgang til kundeinformasjon 9 A Systemet skal forhindre uautorisert tilgang til kontrakter og vedlegg All funksjonalitet og sider sjekker innlogget brukers rolle for å se om den har tilgang. Hver enkelt kunde har en tilgangsliste med handlinger som styrer hvem som ser og får gjort hva. Når det ikke er mulig å få frem denne informasjonen uten at man er logget inn og har riktige tilgangsnivåer. 22

23 10 A En bruker skal kunne legge til en kunde 11 A En kunde skal kunne være privatperson eller bedriftskunde 12 A En kunde skal ha en kundestatus Brukeren har mulighet til å legge til nye kunder Bruker får opp valg om kundetype ved opprettelse. En kunde har en standard kundestatus ved opprettelse, men kan senere endres til ønsket status (Herunder avsluttet kundeforhold) 13 A En kunde skal ha en profil Bruker får (såfremt man har tilgang) tilgang på kundeprofil 14 A En kundeprofil skal inneholde detaljer om kunden 15 A En kundeprofil skal vise hendelsesloggen for kunden 16 A En kundeprofil viser alle kontrakter og maler tilhørende kunden 17 A En kundeprofil skal vise de funksjoner innlogget bruker har i henhold til tilgangsnivåer. 18 A En kontrakt skal kunne inneholde en utfylt versjon av malene. 19 A En kontrakt skal kunne inneholde vedlegg Bruker får (såfremt den har tilgang) opp detaljert kundeinformasjon Bruker har (såfremt den har tilgang) mulighet til å se på loggen til kunden om hva som er gjort/logget Bruker har (såfremt den har tilgang) mulighet til å liste opp ønsket informasjon om kunden Bruker har de valg den skal ha i henhold til de tilgangsnivåer den har til kunden (Om noen). Bruker har mulighet til å fylle ut malene og knytte de mot en kontrakt Bruker har mulighet til å laste opp vedlegg og knyte de mot en kontrakt 23

24 20 A En kontrakt skal ha en kontraktstatus 21 A En kontrakt som er signert skal ikke kunne endres. 22 A En signatur skal ikke kunne gjenbrukes på fler kontrakter 23 A En bruker skal kunne legge til PDF-mal tilknyttet en kunde 24 A En bruker skal kunne legge til en generell PDF-mal 25 A En bruker skal kunne oppdatere malversjon 26 A Systemet skal analysere et PDF-skjema for digital utfylling av felter. 27 A Systemet skal logge hendelser gjort på bruker og av hvem 28 A Systemet skal logge hendelser gjort på kunde og av hvem En opprettet kontrakt har en standard status som kan endres i henhold til fremdrift En kontrakt som er satt til signert er låst for endring En signatur er knyttet til en kontrakt og ikke vil være gyldig for andre kontrakter på samme kunde En bruker kan velge en kundespesifikk PDF-fil for opplasting. En bruker kan velge en generell PDF-fil for opplasting som skal være tilgjengelig for alle kunder En bruker kan erstatte mal med oppdatert versjon En opplasting av mal fører til en analyse av dokumentet som gjør det mulig å digitalt fylle ut PDF-filen En brukerspesifikk endring/handling blir logget på brukeren, også hvem som har foretatt dette En kundespesifikk endring/handling blir logget på kunden, også hvilken bruker som har foretatt dette 24

25 29 A Systemet skal kombinere kundeinformasjon og generere opp en eller flere PDF-dokumenter, basert på denne informasjonen 30 A Systemet skal filtrere ut hvilke PDF-maler som skal fylles ut avhengig av handlingen som velges 31 A En bruker skal kunne velge kontrakttype ved opprettelse av kontrakt 32 A En bruker skal kunne endre passord 33 A Systemet skal bruke SSLkryptering i all interaksjon med bruker 34 A Systemet skal lagre ferdige PDF i et arkiv 35 A Systemet skal tilby muligheten å laste ned alle dokumentene knyttet til en kunde 36 A Systemet skal kunne printe ut ferdige PDF 37 C En kunde skal kunne logge inn på sin profil Informasjon som er lagret på kunden i systemet blir ferdig utfylt på skjemaene Brukeren har valgt hva slags kontrakt som skal opprettes og kun de nødvendige malene kommer opp for utfylling Brukeren får mulighet til å huke av hva slags kontrakt som skal opprettes før prosessen går videre En bruker kan gå inn å endre passord på innloggingen Alle kommunisering mellom tjener og server er kryptert Alle filer i en kontrakt lagres i et eget arkiv for ferdige og signerte kontrakter En bruker skal enkelt sikkerhetskopiere alle dokumenter tilkyttet en eller flere kunder til lokal kopi Nå en kontrakt er opprettet skal det være mulig å skrive ut feridige dokumenter rett i løsningen Når en kunde kan logge inn på sin profil med oppgitt brukernavn og passord 25

26 38 A Systemet skal kunne sende mail til kunden nå er kontrakt er laget med kunden 39 B En bruker skal kunne redigere egen profil 40 B En bruker skal kunne legge til manuelle oppføringer i kundelogg 41 B Systemet skal tilby kategorier for manuelle oppføringer 42 C En bruker skal kunne opprette et prosjekt 43 C En bruker skal kunne knytte en kunde mot et prosjekt. 44 C En kunde skal ha oversikt over hvilke prosjekter det er i 45 C Et prosjekt skal være tilknyttet kunder og deres andel i prosjektet Systemet skal sende en bekreftelse på inngåtte avtaler gjort med en kunde. Når bruker fullfører en kontrakt, og setter status som fullført. En bruker skal kunne endre personinfo på sin egen profil. Bruker av systemet skal kunne logge ulike interaksjoner gjort med en kunde. Være seg telefonsamtaler, eposter, møter etc. Dette skal legges inn på en brukers profil, og inneholder bruker, dato, kategori og kommentar En bruker skal kunne legge til ukategoriserte oppføringer på en kunde. En bruker skal kunne laget et nytt prosjekt hvor sentral informasjon skal kunne vises i en Prosjekt profil. Et prosjekt skal kunne ha tilknyttet en eller flere kunder. Det skal vises på en kundes profil hvilke prosjekter kunden er den del av. En kunde skal ha en andel tilknytning i prosjektet. 26

27 46 D En bruker skal kunne opprette møte/avtale med kunde. 47 D En bruker skal ha tilgang til Min kalender som viser kommende møter/avtaler. 49 D Laste inn Excelfiler med informasjon om prosjekt og tilhørende kunder som integreres i systemet 50 D Eksportere utgående korrespondanse med dato til Excel 51 D Dokumenter skal kunne signeres med elektronisk signatur ( ved hjelp en digital skrivefalte) 52 A En bruker skal kunne opprette en kontrakt med en kunde 53 A Systemet skal kunne søke etter kunder/prosjekter etter gitte kriterier Systemet har en ønsket funksjon om en kalander hvor brukere kan legge inn fremtidige møter og avtaler med kunder. En bruker skal kunne se sine avtaler i kalenderen i en oversiktlig struktur som viser nærstående avtaler. En bruker skal kunne importere større lister med data som skal brukes til å opprette nye kunder i systemet. En bruker skal kunne eksportere aktiviteter fra hendelsesloggen til et Excelark. Basert på kunde, prosjekt og tidsintervall. Et dokument skal kunne signeres av kunden ved hjelp av en digital skrivefalte, og legges på et dokument. Prosessen skal føre til gyldige dokumenter. En bruker (såfremt den har tilgang) kan opprette en kontrakt med tilhørende dokumentasjon. En bruker har tilgang til en søkefunksjonalitet som gir de llister over data i systemet 27

28 54 A En bruker med tilgang skal kunne redigere tilgang til kunde 55 B En admin skal kunne redigere roller 56 A En bruker skal bli blokkert etter x antall feilinnlogginger 57 A En bruker skal kunne få et midlertidig passord på mail En bruker som allerede har rettigheter for dette på kunden kan legge til/fjerne andre brukere En bruker mer admin-rolle også har mulighet til å styrke hvilke tilganger hvilke roller har og legge til/endre på roller En bruker ikke får logget inn med sitt vanlige passord om han har nådd antall feilinnlogginger En bruker mottar midlertidig passord på mail som kan benyttes for å gjenopprette profilen Tabell 1.1: Figur over funksjonelle krav Merk! Krav med prioritet lavere enn B blir ikke prioritert som en del av fremdriftsplanen for hovedprosjektets rammer, men kan være aktuelle for videreutvikling av webapplikasjonen. 28

29 1.7 Ikke-funksjonelle krav # Prioritet Krav Spesifisering 58 A Systemet skal være brukervennlig og raskt Brukerne er fornøyde med hvordan systemet er laget og at de er fornøyde med 59 B En bruker skal ikke bruke mer enn 10 minutter på en hovedprosessen (i verste tilfelle) 60 A En bruker skal ikke trenge mer enn to klikk i menyen for å komme til ønsket menyvalg 61 B Nettsiden skal kunne tilpasse seg ettersom brukeren har en bærbar eller stasjonær enhet, nettbrett eller smarttelefon 62 A Systemet skal kunne utvides på en enkel måte 63 A Spørringer fra databasen skal ikke ta mer enn 2.5 sek ved normal bruk og i verste tilfelle 64 A Systemet skal ha et innbydende og funksjonelt design Tabell 1.2: Figur over ikke-funksjonelle krav farten Gangen i systemet er så raskt at det ikke tar mer enn 10 minutter å gjennomføre en hovedprosess Menyhierarkiet ikke har mer enn to forgreninger Nettsiden skaleres og er brukervennlig på alle tre enhetstyper Systemet skal utvikles etter standarder og god praksis slik at opplæring og vedlikehold av andre enn utviklerne er mulig Spørringer mot databasen skal hente så lite som mulig slik at en spørring ikke tar med enn 2.5 sekunder Brukerne av systemet synes designet er rent, pent og satt opp slik at det er lett å gjøre det man vil 29

30 Merk! Krav med prioritet lavere enn B blir ikke prioritert som en del av fremdriftsplanen for hovedprosjektets rammer, men kan være aktuelle for videreutvikling av webapplikasjonen. 30

31 Kapittel 2 Prosessdokumentasjon 2.1 Forord I prosessdokumentasjonen vil vi ta for oss hvordan vi har jobbet frem til det ferdige resultatet, utfordringer vi har møtt på vegen og hvordan vi har løst disse. Prosessdokumentasjonen gir et innblikk i arbeidsmetoder vi har benyttet for å nå de målene som vi, i samarbeid med oppdragsgiver, satt oss i kravsepsifikasjonen. Contents 2.1 Forord Forbedredelser og planlegging Valget av oppgaven Definere oppgaven og omfang Finne riktig rammeverk Oppstartsfasen Utviklingsverktøy Netbeans IDE 7/ Git & Github Trello Google Docs Dropbox

32 2.3.6 Testmiljø L A TEX & Texmaker Om utviklingsprosessen (Utviklingsmetodikk) Innledning Daglige utfordringer Gruppesiden Dagbok Scrumbrett Versjonskontroll Møter med veileder Møter med oppdragsgiver Kravspesifikasjonen og dens rolle Endringer i kravspesifikasjonen underveis Kravspesifikasjonens betydning for webapplikasjonen Samsvar med endelig kravspesifikasjon Fremdriftsplan og dens rolle Innledning Tre utviklingsfaser Tidsberegning Samspillet mellom fremdriftplan og scrumbrett Designutvikling Refleksjoner og utbytte Innledning Ting vi ville gjort annerledes Tverrfaglig utbytte Veien videre Nytteverdi for oppdragsgiver Oppdragsgiver om webapplikasjonen Oppsummering og konklusjoner

33 2.2 Forbedredelser og planlegging Valget av oppgaven Gruppen startet i oktober 2013 å sende ut forespørsler om bacheloroppgaver til eksterne aktører. Det ble sendt ut e-poster til blant annet Accenture, Finn.no og Steria. Tilbakemeldingene fra både Accenture og Finn.no var at de gjennomførte bacheloroppgave. Finn.no kun som veiledere på et eksisterende tenkt prosjekt, Accenture som kunne tilby ulike prosjekter, og Steria hadde ikke et opplegg for dette. Accenture ville ha litt mer detaljert informasjon om kandidatene, så vi holdt denne muligheten åpen samtidig som vi overveide andre muligheter. Vi kom i befatning med denne oppgaven gjennom et av gruppemedlemmenes private foretak, hvor det tidligere hadde kommet en forespørsel om å utvikle en tjeneste som kunne effektivisere måten bedriften skrev kontrakter på. Denne forespørselen dreide seg i all hovedsak om kun en digitalisering av skjemautfylling, og ble på daværende tidspunkt lagt på is. Bedriften som hadde forespørselen, Meso Capital Markets, er en mindre lokal Oslobedrift som driver i et helt annet fagmiljø enn det vi kommer fra. Derfor så vi på denne oppgaven som både utfordrene og spennende da den ville gjøre oss til fagpersoner i løsningen av oppgaven, som igjen ville bety at vi kunne ha stor grad av frihet i løsningen, men samtidig ha et større ansvar. Da bacheloroppgave skulle velges ble denne forespørselen dratt frem som en mulig kandidat, men da med en større visjon og en bedre ramme for et mer helhetlig system. Vi presenterte forslaget for bedriften (Meso Capital Markets), og forhørte oss om det var noe de var villige til å ha som et bachelorprosjekt. Etter noe mailkorrespondanse om hva et hovedprosjekt innebar for begge parter, ble vi enige om at dette ville være et spennende prosjekt, og noe de gjerne ville være en del av Definere oppgaven og omfang Ut i fra kommunikasjon via e-post med oppdragsgiver satte gruppen seg ned for å klargjøre hva oppgaven skulle innebære. Dette innebar ulike tanker om hvordan oppgaven skulle løses fra et teknisk ståsted, men også hvor omfattende det skulle være. Det ble satt opp et møte med oppdragsgiver den

34 januar 2014 og en møteagenda ble laget (se vedlegg). Til dette møtet hadde vi laget noen skisser basert på de tankene vi hadde om hvordan systemet skulle fungere, slik at det ble lettere å forholde seg til for oppdragsgiver i møtesituasjonen. I møtet ble det avklart at oppdragsgiver også ønsket seg en mer helhetlig løsning, mer mot en portalløsning hvor alle deres dokumenter og kundearkiv kunne eksistere. Dette ønsket, samt en gjennomgang av hvordan oppdragsgiver gjør tingene på det nåværende tidspunkt, ble lagt til grunne for kravspesifikasjonen Finne riktig rammeverk For å løse oppgaven ønsket vi å bruke et rammeverk med MVC-støtte og samtidig ha god støtte for automatisert testing. Vi valgte å gå for et PHPrammeverk, da dette passet best med eksisterende miljøer hos oppdragsgiver. Vi var innom de store PHP-rammeverkene Zend og CodeIgniter, før vi havnet på det ganske nye, men sterkt i vinden, rammeverket Laravel 3. Laravel har støtte for MVC-arkitekturen med en enkel templating i Blade, integrert støtte for testing med PHPUnit, og god mulighet for å legge til en rekke andre pakker Oppstartsfasen I oppstartsfasen satt vi opp noen predefinerte oppgaver i Scrum-brettet vårt, som besto av å finne ut styrker og svakheter i de ulike rammeverkene, Zend, CodeIgniter og Laravel. Vi gjorde oss også noen tanker rundt det å finne riktig verktøy for å behandle PDF-dokumenter. En del av denne prosessen var å sette opp et Proof-of-concept med verktøyet PDFtk. Da valget falt på Laravel som rammeverk, ble det lagt til noen nye punkter, som besto i å tilegne seg ny kunnskap rundt dette rammeverket. Vi måtte blant annet sette oss inn databasehåndteringen (Migration og Eloquent) og templating (Blade). For nærmere spesifisering rundt dette, se appendiks B. Som en forberedelse frem mot første møte med oppdragsgiver, ble det også laget noen skisser av hvordan vi tenkte systemet skulle være slik at det ble lettere å ha noen holdepunkter å vise til. 3 Laravel: 34

35 2.3 Utviklingsverktøy For å lage et godt produkt for Meso Capital Markets, og samtidig ha en strukturert og agil tilnærming til utviklingen har de rette verktøyene vært viktig for oss. I utviklingen har vi derfor benyttet oss av følgende programvare: Netbeans IDE 7/8 Netbeans 4 er et integrert utviklingsverktøy med støtte for en rekke programmeringsspråk. Netbeans er gratis og åpen kildekode, har blant annet god PHP-støtte og integrert versjonshåndtering via Git 5. Alle faktorer var sterkt avgjørende i valget av IDE Git & Github Git er et versjonshåndteringssystem som er et populært og mye brukt verktøy i utvikling av åpen kildekode. Github 6 er et webbasert verktøy laget for Git - som holder enkel oversikt over alle versjonene og inkrementene av kildekoden. Git kommer inkludert i vårt utviklingsverktøy, Netbeans, men kan også benyttes selvstendig i de fleste operativsystemer. Github kommer i ulike former, hvor åpne prosjekter er gratis, mens lukkede prosjekter krever en skolekonto, eller mot betaling. Vi har benyttet oss av skolekontoutgaven som gjør at vårt prosjekt ikke er offentlig tilgjengelig Trello Trello 7 er et organiseringsverktøy som vi har brukt for å jobbe smidig og for å ha oversikt over de ulike sprintene og backloggen til enhver tid i utviklingen Google Docs Google Docs 8 er Googles dokumentbehandlings-pakke som tilbyr en enkel oversikt over dokumenter lagret i skyen, samt muligheten for at flere kan 4 Netbeans: 5 Git: 6 Github: 7 Trello: 8 Google Docs: 35

36 behandle samme dokument i sanntid. Vi har tatt dette i bruk til å skrive møteagendaer og møtereferater, samt en del styringsdokumenter Dropbox Vi har også hatt en delt mappe på skylagringstjenesten Dropbox 9. Dette for å ha et felles samlingspunkt for ulike filer som har vært av interresse for alle gruppemedlemmene Testmiljø Vi har i sammarbeid med høgskolens IT-avdeling fått tildelt en virtuell maskin, hvor vi har kjørt en live-test av webapplikasjonen for testing og utvikling. Denne maskinen er satt opp med de nødvendige programmene i LAMP-stakken samt de andre kravene som er gitt i systemkravene. Her har vi også satt opp en prototype som ble presentert og brukertesten underveis i utviklingen L A TEX & Texmaker LaTeX 10 ansees ofte som WYSIWYM (What You See Is What You Mean, det du ser er det du mener) editor. Vi har brukt denne skrivestandarden til å produsere denne rapporten. For å skrive og produsere dokumentene har vi brukt Texmaker 11, en Latex-editor som er gratis og kryssplattformkompatibel. 2.4 Om utviklingsprosessen (Utviklingsmetodikk) Innledning Vi har fra planleggingen av prosjektet vært nøye med å dokumentere arbeidet for å lettere kunne gå tilbake å se på tidligere valg, men også for å ha et solid fundament for å dokuementere prosessen frem til det ferdige resultatet. Vi har også valgt å jobbe agilt og tatt i bruk Scrum som vår arbeidsmetode, 9 Dropbox: 10 LaTeX: 11 Texmaker: 36

37 med sprinter på én uke hver. Vi har møttes og jobbet som én enhet 5 dager i uka, hvor hver dag har vært bestående av en liten samtale om hva som ble gjort dagen før, og hvilke mål man hadde for dagen. Vi hadde også hver fredag et møte hvor vi gjennomgikk den avsluttede Scrum-sprinten, og førte progresjon i fremdriftsplanen Daglige utfordringer I det daglige arbeidet har en av de største utfordringene vært tekniske utfordringer knyttet til webapplikasjonen. Vi har savnet en fagperson å konferere med underveis for å få avklart større tekniske utfordringer. I denne forbindelse ble Laravels dokumentasjon 12 samt andre litteratursøk løsningen. En annen utfordring har vært vår manglende domenekunnskap innefor oppdragsgivers fagfelt, hvor termer og arbeidsmetoder de operere med til daglig, ikke alltid var like klart for oss. Ved å holde en åpen dialog med kontaktperson hos oppdragsgiver klarte vi å holde dette problemet i sjakk Gruppesiden Oppdaterte dokumenter ble ukentlig lagt inn på gruppesiden 13 slik at disse var tilgjengelige for både veilder og oppdragsgiver i løpet av prosjektet. I tillegg nyttige lenker la vi til kildekode og Scrumbrett Dagbok Vi førte dagbok kontinuerlig fra vi begynte planleggingen av hovedprosjektet, fra 3. oktober 2013 frem til innleveringen 27. mai, både for vår egen skyld for å holde rede på hva og når oppgaver er gjort, men også for at veielder og oppdragsgiver skulle ha oversikt over hva som ble gjort. I begynnelsen av prosjektet ble alt vårt arbeid loggført i dagboken, men da selve implementeringen begynte ble den spesifikke informasjonen rundt dette systematisert på Scrumbrettet. Alle møter med de forskjellige partene, og vesentlig informasjon utover implementeringen, ble imidlertid logget i dagboken. 12 Laravel dokumentasjon: 13 Gruppesiden: 37

38 Dagboken er å finne som vedlegg med oppdateringer frem til print av sluttrapport 20. mai. Oppføringer etter dette fremkommer kun på gruppesiden Scrumbrett Fra begynnelsen av implementeringen jobbet vi på scrumbrett via nettsiden Trello. Dette var til stor hjelp med å organisere arbeidet som skulle utføres fra uke til uke og ga oss en god struktur på arbeidet, både med tanke på det pågående arbeidet, men også historikk på hva som var blitt gjort tidligere. Ettersom vi ikke til enhver tid jobbet på samme fysiske sted hjalp også scrumbrettet oss med å se hva de andre gjorde til enhver tid for å unngå dobbelarbeid og misforståelser. Se vedlagt fremdriftsplaner for å se skjermbilder fra scrumbrettet Versjonskontroll Både implementering av webapplikasjonen skrevet i PHP, samt sluttrapporten skrevet i LaTeX er begge blitt utviklet/skrevet ved brukt av Git, med lagring og visuell fremvisning på Github. På denne måten fikk vi en komplett logg over arbeidet samtidig som det forenklet utviklingen mellom gruppemedlemmene drastisk. I tillegg til dette fikk vi en backup av arbeidet, ikke bare på hver enkelts gruppemedlems maskin men også hos GitHub. Jobbing med branches Repository er en mappe med kode som benyttes sammen med Git, som på Github kan være private eller public. Ettersom det ikke er ønskelig fra oppdragsgivers side er ikke repository ene benyttet i forbindelse med denne webapplikasjonen public, men kan kun aksesseres av gruppemedlemmene. En branch er en forgrening av koden som kan benyttes i forbindelse med for eksempel testing eller om man skal utgi en ny versjon kan man lage en branch som heter Versjon 1.2. Alle repositorier har en masterbranch som er branchen vi har jobbet mot i oppstarten av denne webapplikasjonen, men vi har også en branch som heter prototype som viser hvordan koden var i det vi utførte en brukertest (se testdokumentasjonen for nærmere informasjon). 38

39 Commits Commits er kode som legges til i versjonskontrollen (inn i repository et) som sendes inn med en tekststreng som beskriver hva som er blitt gjort. Det er i alt ca commits for implementeringen, og ca. 300 commits for repository et med rapporten. Figur 2.1: Commit-graf for Github-repository for implementasjonen Grafen viser antall commits i løpet av perioden vi jobbet med implementeringen av prosjektet. Her kommer det frem en intensiv periode i Mars måned, mens det flatet ut mot April/Mai da rapporten ble påbegynt. Figur 2.2: Commit-graf for Github-repository for rapporten Grafen viser antall commits i løpet av perioden i jobbet med rapporten av prosjektet. Grafen viser at mesteparten av rapporten ble skrevet i Mai måned. 39

40 2.4.7 Møter med veileder Det første møtet vi hadde med veileder fant sted 15. januar Fra og med dette hadde vi jenvlige møter med veileder, som oftest med to ukers mellomrom såfremt annet ikke var ønskelig fra veileders side eller at vi hadde spesifikke temaer å drøfte med veileder. På de fleste møtene var det kun veileder og gruppen som var tilstede, men i et par tilfeller hadde vi også møter sammen med veilederens andre grupper for å dele erfaringer og øve på fremføring av prosjektet. Dette ga oss et nyttig innblikk i hvordan andre grupper jobbet og planla prosessen deres Møter med oppdragsgiver Vi hadde gjennom hele prosessen jevnlig kontakt med oppdragsgiver, særlig i planleggingsfasen og da webapplikasjonen ble implementert. Mye av de mindre tingene ble avklart over mailkorrespondanse, men vi hadde i alt fire møter med oppdragsgiver hvor vi fikk avklart situasjoner og drøftet problemer. I forkant av hvert møte skrev gruppen en møteagenda med temaer vi ønsket å ta opp med oppdragsgiver, samt at vi tok imot innspill og eventuelle andre teamaer oppdragsgiver ønsket. For å få mest mulig ut av møtene noterte hele gruppen ned vesentlige punkter og informasjon slik at vi ved endt møte kunne skrive et fyldig møtereferat basert på disse notatene. Særlig de første møtene var veldig viktige for gruppen til å forstå akkurat hva oppdragsgiver ønsket og hvordan de jobbet per i dag. På denne måten var det mye enklere for oss å forstå hva som faktisk var ønskelig, og ved å ha tidlige avklaringsmøter slapp vi å kaste bort tid på hvordan vi trodde oppdragsgiver ønsket det. I løpet av møtene beveget oppgavens skop seg fra i første omgang å kun generere PDF-filer basert på input, til å bli et større CRM-system. Vi så at vi til en viss grad kunne utvide webapplikasjonen slik oppdragsgiver ønsket, men på et punkt måtte vi avgrense oppgaven slik at det som ble implementert ble implemenetert på en tilstrekkelig måte, mens de resterende forslagene vil 40

41 stå som utviklingspotensiale i webapplikasjonen. Både møteagendaene og møtereferatene er å finne som vedlegg 2.5 Kravspesifikasjonen og dens rolle Endringer i kravspesifikasjonen underveis Underveis i prosjektarbeidet ble kravspesifikasjonen noe endret fra den versjonen vi startet prosjektet med. Dette kan begrunnes, hovedsakelig, med at oppdragsgiver så rom for at applikasjonen kunne, og i noen tilfeller måtte, ha videre funksjonalitet. Siden vi hadde en såpass tett kontakt med oppdragsgiver hvor vi blant annet viste de status opptil flere ganger i løpet av en måned, kom oppdragsgiver inn med flere ønsker om funksjonalitet underveis. Noe av denne funksjonaliteten var avhengig av den opprinnelige kravspesifikasjonen: Aktiviteter (internt møte, telefonmøte, eksternt møte o.l.) måtte implementeres for at koblingen mellom kunde og kontrakt skulle bli riktig etter deres egen arbeidsflyt, da en kontrakt alltid måtte knyttes opp mot et møte. Dette var et nytt krav som ble introdusert for oss, noe vi valgte å implementere i applikasjonen. Kontaktperson hos en bedrift måtte implementeres for at knytningen mellom en bedriftskunde og kontrakt skulle bli riktig etter deres arbeidsflyt. Dette var fordi oppdragsgiver omtrent alltid gjorde kjøp og salg med én person fra et firma, ikke hele firmaet. Fra starten av hadde vi kun bedriftsnavnet som en kunde, men dette ble vi gjort oppmerksomme på underveis i prosjektet. Dette valgte vi også å implementere i applikasjonen. I sammenheng med aktivitetsfunksjonaliteten ble aktivitets-/møtelogging påkrevd av applikasjonen. Av oppdragsgivers samarbeidspartnere krevdes det at hvert gjennomførte møte med kunder måtte ha et møtereferat, som vi valgte å implementere som en aktivitetslogg. Etter aktivitetsloggingen ble en funksjonalitet forespurte oppdragsgiver om utvidet logging i applikasjonen. Dette var alt fra handlings- 41

42 /aktivitetslogg til logging av uautorisert aksess hos brukere (ansatte) i forhold til gitt rolle. Dette valgte vi å implementere i applikasjonen. I tillegg etterspurte oppdragsgiver ekstra funksjonalitet som ikke var en direkte nødvendighet for at den første versjonen av kravspesifikasjonen skulle oppfylles. Av disse kravene tok vi en vurdering med tanke på tid og gjennomførbarhet og valgte å implementere følgende tilleggsfunksjonalitet: Oppslagstavle med informasjon om og presentasjon av kunder, kontrakter og aktiviteter Ha muligheten til å lagre kontonummer (bankkonto- og VPS-nummer) hos en kunde Kundefiler, dvs. å ha et arkiv over f.eks. kopi av legitimasjon, kundespesefikke skjemaer o.l. for å lettere skrive kontrakter med eksisterende kunder Av ønskene om tilleggsfunksjonalitet ble følgende ønsker ikke implementert på grunn av tid og gjennomførbarhet i forhold til tiden: Ringe en kunde direkte fra webapplikasjonen Importere kundelister i Excel-format og opprette kunder automatisk fra denne. Endre tidspunkt og innhold på aktivitetslogg i etterkant av opprettelse av denne. Endre innhold i kontrakt etter utfylling Kravspesifikasjonens betydning for webapplikasjonen Etter implementeringen av overnevnte punkter utviklet prosjektet seg til å bli noe mer enn bare en digitalisering av kontraktskriving, som i korte trekk var det den tidlige versjonen av kravspesifikasjonen tilsa. Applikasjonen gikk nå i retning av å bli et mer fullstendig kundebehandlingssystem. Tidligere i prosjektet hadde oppdragsgiver uttrykt deres frustrasjon i forhold til graden av skreddersying av deres eksisterende kundebehandlingssystem, og med de 42

43 nye kravene på plass følte både vi og oppdragsgiver at dette kunne, muligens, erstatte deres nåværende systemer grunnet høy grad av skreddersying til deres arbeidsflyt. Dette ble da en naturlig tilnærming vi jobbet mer og mer mot i den resterende tiden av prosjektet. Betydningen denne endringen hadde for prosjektet var i hovedsak tidsberegningen. Ettersom vi ble oppmerksomme på flere ønsker om funksjonalitet i systemet måtte vi revurdere tidsplanen vår og prøve å bruke den resterende tiden vi hadde til rådighet på mest mulig effektiv måte. Dette resulterte i at flere arbeidstimer måtte bli lagt inn i prosjektet per uke og at krav måtte bli flyttet til andre sprinter. Konkrete eksempler på dette: Fra sprint 2 ble det overført et krav knyttet til brukerprofil Fra sprint 3 ble det overført to krav, knyttet til skjematilknytning til kunde og skjemautfylling Fra sprint 4 ble et krav overført knyttet til kombinering av kundeinformasjon, skjemagenerering og knytningen mellom dette flyttet grunnet underestimering av tid. Fra sprint 7 ble det overført et krav knyttet til e-postsending til diverse parter hos oppdragsgiver. Fra sprint 8 ble flere krav overført til det vi kalte en buffer-periode under testfasen. Dette var direkte krav som vi ble oppmerksomme på underveis i prosjektet og som, til dels, speiler endringen i kravspesifikasjon. Dette var i hovedsak krav knyttet til aktiviteter, kontonummer på kunder og logging samt generell finpuss. I tillegg til dette ble det satt flere krav til designet i applikasjonen, slik at det ble mer tilpasset med tanke på oversiktlighet og brukervennlighet, i og med at det nå var mer funksjonalitet inne i bildet. I denne sammenhengen ble det også utviklet en brukertest for å se hvordan brukerne av systemet reagerte på endringene. Les mer om dette i Testrapporten 43

44 2.5.3 Samsvar med endelig kravspesifikasjon Som nevnt over fikk applikasjonen vesentlig mer funksjonalitet og kom til å spille en større rolle hos oppdragsgiver enn først antatt. Den opprinnelige kravspesifikasjonen og dens krav ble oppfylt, både med endringene som vi ikke var oppmerksomme på i starten samt tilleggsfunksjonalitet som også ble lagt til. Les mer om dette under Produktrapporten 2.6 Fremdriftsplan og dens rolle Innledning Vi oppdaterte ukentlig fremdriftsplanen etter endt sprint, både når webapplikasjonen ble implementert, men også ved testing og skriving av rapporten. Dette ga både oss, veileder og oppdragsgiver oversikt over fremgangen i prosjektet uten å gå inn på scrumbrettet som kun viste aktiv uke Tre utviklingsfaser Planleggingen av prosjektet var naturligvis første del av prosjektet, og ble dokumentert i statusrapport, prosjektskisse og forprosjektrapport. Tilknyttet dette arbeidet hadde vi ingen fremdriftsplan. Implementeringens kompleksitet åpnet behovet for en fremdriftsplan for arbeidet fremover for å få en pekepinn på hvordan vi skulle jobbe, og hvor mye tid vi hadde til å implementere. Vi vedlikeholdt en fremdriftsplan som var tett knyttet mot kravspesifikasjonen som ga oss oversikt over utført og gjenstående arbeid. Testingen og rapporten hadde i sin tur ikke en like tett knytning mot kravspesifikasjonen, og ble derfor skilt ut som en egen fremdriftsplan da implementeringen var ferdig. Begge fremdriftsplaner er lagt ved som vedlegg. Fremdriftsplanen for testingen og rapporten inneholder oppdateringer frem til print av sluttrapport 20. mai 44

45 2.6.3 Tidsberegning Arbeidsmengde Som grunnlag for våre tidsberegninger la vi til grunn for at hovedprosjektet tilsvarte 20 studiepoeng, som for oss var 2/3 av uken. Gitt at en arbeidsuke er 37,5 timer ga dette oss 25 arbeidstimer i uken hver til prosjektet, totalt 75 arbeidstimer i uken. Fristen for levering av prosjektrapport var satt til 27. mai 2014 klokken For å gi oss selv rom for avvik og utarbeidelse av prosjektrapport satt vi som en tidsfrist for selve produktet til å være ferdig i løpet av uke 17 (med siste arbeidsdag fredag 25. april). Vi så oss ferdig med planleggingsfasen i uke 5. Dette ga oss fra og med første dag etter planleggingsfasen (mandag 3. februar, uke 6) frem til nevnte tidsfrist for produktet totalt 12 uker. Dette ga hele gruppen totalt 900 arbeidstimer samlet. Ettersom vi la stor vekt på enhetstesting anslo vi at 2/3 (66,67%) av tiden ville gå med på direkte koding og utvikling av webapplikasjonen. De resterende 300 timene ville gå til enhetstesting av systemet. 45

46 Grov tidsplan Tidsperiode 3. februar mars 31. mars april 28. april mai 19. mai mai Antall uker uke og 2 dager juni juni 1 uke og 2 dager 105 Totalt 1335 Arbeidstimer for hele gruppen Arbeidsoppgave Implementering med tidvis dokumentasjon om arbeidet underveis. Enhetstesting med dokumentasjon av testene som gjøres, samt eventuelle utbedringer basert på testresultater. Sette sammen og skrive ferdig dokumentasjon. Periode satt av til finskriving, dobbelsjekking og bufferperiode om overnevnte perioder ikke holder tidsrammene. Lage klar presentasjon av prosjektet. Tabell 2.1: Grov tidsplan for prosjektet Planning poker Ut fra kravspesifikasjonen som vi hadde prioritert etter oppdragsgivers ønsker benyttet gruppen planning poker for å estimere et timeantall for kravene. Vi estimerte da tiden for hvert enkelt krav hver for oss og regnet gjennomsnittlig timeantall for hvert enkelt krav. Vi la inn en feilmargin på 10% på de 600 timene for implementasjon som ga oss 540 timer å planlegge arbeid på. Dette ga oss mulighet til å dekke alle A- og B-krav i kravspesifikasjonen. 46

47 2.6.4 Samspillet mellom fremdriftplan og scrumbrett Vi har kontinuerlig oppdatert fremdriftsplanene sammen med scrumbrettet slik at disse er synkronisert. For planlegging av hver uke tok vi for oss et gitt antall krav i kravspesifikasjonen som skulle dekke ukens timeantall. Videre ble disse markert med sprintens farge som også ble gjenspeilet på scrumbrettet. Figur 2.3: Utsnitt fra kravspesifikasjon Figuren 2.3 viser kravnummer, prioritering, spesifisering av krav samt planning poker med gjennomsnitt lengst til høyre. Fargen i høyre kolonne viser til sprint 3 og 4 Figur 2.4: Utsnitt fra sprintsummering Figuren 2.4 viser oppsummeringen av fullførte sprinter med oppsummering av sprint. Prosenttallet viser hvor stor andel av 47

48 sprintens planlagte arbeid som ble gjennomført, mens den røde kolonnen viser eventuelle krav overført til neste sprint. Figur 2.5: Utsnitt fra scrumbrett på Trello Figur 2.5 viser scrumbrettet hvor sprint 4 er planlagt, samt overførte krav fra sprint 3 som ikke er fullførte. Disse ble markert både med sin sprints farge sammen med rødt tilsvarende høyre kolonne i figur

49 2.7 Designutvikling Etter kravspesifikasjonen var skrevet og alle parter var enige om denne startet planleggingen av designet til webapplikasjonen. Siden applikasjonen skulle kjøres i en nettleser var vi nødt til å forholde oss til designmulighetene dette gav oss. Dette innebar at designet måtte utvikles i HTML, CSS og JavaScript. Fra kravspesifikasjonen ble det laget designskisser i Adobe Photoshop 14 som videre ble sendt til oppdragsgiver for tilbakemelding. Tilbakemeldingene fra oppdragsgiver var meget positive, og vi valgte å gå i den retningen. Se figurene fra 2.6 til 2.13 for disse designskissene. Figur 2.6: Designskisse: Innloggingsskjerm 14 Bildebehandlingsverktøy fra Adobe, 49

50 Figur 2.7: Designskisse: Innlogget skjerm Figur 2.8: Designskisse: Eksisterende dokument 50

51 Figur 2.9: Designskisse: Nytt dokument Figur 2.10: Designskisse: Eksisterende kunde 51

52 Figur 2.11: Designskisse: Ny kunde Figur 2.12: Designskisse: Opprettet dokument 52

53 Figur 2.13: Designskisse: Opprettet dokument m/ innfelt meny 53

54 Etter hvert som kravene i oppgaven endret seg underveis i prosjektet ble det nødvendig å endre på designet. I den neste utviklingen av designet ble det lagt mer tilrette for å ha bedre oversikt over kunder, ansatte, dokumenter og prosjekter. Prosjekter var noe som oppdragsgiver i noen tilfeller hadde bruk for og det ble derfor implementert i nytt design. Menyen ble også flyttet til å være oppe fra å være på siden, da det la bedre tilrette for flere menyvalg. Vi introduserte også en sekundærmeny ved visning av kontrakter, kunder og bruker som hadde relevante menyvalg innenfor disse. Figur viser skjermbilder fra dette designet. Figur 2.14: Skjermbilde: startside Underveis implementerte vi en kalender i brukermenyen og flyttet brukerbilde til høyre. Se figur 2.19 for et skjermbilde av den nye brukermenyen. 54

55 Figur 2.15: Skjermbilde: kontraktvisning Figur 2.16: Skjermbilde: åpen hovedmeny 55

56 Figur 2.17: Skjermbilde: åpen brukermeny Figur 2.18: Skjermbilde: kontraktvisning 56

57 Figur 2.19: Skjermbilde: ny brukermeny 57

58 På dette punktet implementerte vi kalenderfunksjonalitet, samt en stegfor-steg-prosess for å skrive under en kontrakt. Vi implementerte informasjonsbokser på startsiden som planlagt skulle vise informasjon om kunder, kontrakter, inntjening blant annet. Det ble også implementert en mulighet for å ta backup av alle kontrakter. Brukermenyen ble endret ved å gjøre den kortere, det ble lagt til en egen menykategori PDF-maler samt å inneholde et søkefelt. Kontraktvisningen fikk også en statusvisning. I brukermenyen ble den tidlgere kalenderfunksjonen fjernet, og ble istedet erstattet med Kommende events og Siste aktivitet grunnet høyere grad av relevans for brukeren. Vi introduserte også design for skjemaoppsett. Se figur for skjermbilder på dette. Figur 2.20: Skjermbilde: kalendervisning 58

59 Figur 2.21: Skjermbilde: lag ny kontrakt Figur 2.22: Skjermbilde: oppslagstavle 59

60 Figur 2.23: Skjermbilde: last ned sikkerhetskopi Figur 2.24: Skjermbilde: ny hovedmeny 60

61 Figur 2.25: Skjermbilde: ny kontraktvisning Figur 2.26: Skjermbilde: nyeste brukermeny 61

62 Figur 2.27: Skjermbilde: skjemaoppsett 62

63 På dette punktet hadde vi implementert all funksjonalitet men vi så likevel rom for flere designendringer. Den største forbedringen var at menyen nå hadde fått større ikoner og mindre menyvalg, grunnet høyere relevans for brukeren. Søkefeltet ble flyttet utenfor menyen og det ble implementert en hurtigknapp til brukers kalender i tillegg til den i brukermenyen. Det ble også implementert kakediagrammer i oppslagstavlen samt at en ny kundevisning ble designet. Det ble også foretatt noen mindre endringer på tabellene og knappene i systemet. Se figur for figurer. Figur 2.28: Skjermbilde: nyeste meny 63

64 Figur 2.29: Skjermbilde: relokalisert søkefelt og Min kalender -knapp Figur 2.30: Skjermbilde: ny oppslagstavle 64

65 Figur 2.31: Skjermbilde: ny kundevisning Figur 2.32: Skjermbilde: nytt tabelldesign 65

66 Figur 2.33: Skjermbilde: nytt knappedesign 66

67 2.8 Refleksjoner og utbytte Innledning Dette prosjektarbeidet har vært interessant, lærerikt og til tider meget arbeidskrevende og utfordrende. Likevel fikk vi laget et sluttprodukt både vi og arbeidsgiver er meget fornøyd med. Ved å arbeide såpass intensivt og målrettet mot et sluttprodukt til en virkelig bedrift har det lært oss å utvikle en webapplikasjon der vi må være nøye, konsekvente og profesjonelle. Ved å simulere en arbeidssituasjon på denne måten som HiOA har gjort, får alle medlemmene på gruppen et lite forsprang ut til arbeidslivet. Dette er kunnskap og erfaring som er mye verdt for nyutdannede studenter Ting vi ville gjort annerledes Når vi ser tilbake på prosjektet fra planleggingsfasen, løpet gjennom styringsdokumentene og implementeringen ser vi oss meget godt fornøyd med gjennomføringen. Det eneste vi ville gjort annerledes om vi kunne starte helt fra bunnen av ville vært å sette av mer tid til særlig enhetstesting av webapplikasjonen og også noe mer tid til fullføring av sluttraporten. Dette kunne vi muliggjort ved å redusere antall krav vi tok med til fremdriftsplanen. Vi har også noen punkter for ting vi ville gjort annerledes som er å finne i Appendiks B for Laravel (Kapittel 8) Tverrfaglig utbytte Gjennom dette prosjektarbeidet fikk vi svært god bruk for tidligere og pågående kurs vi har / har tatt ved Høgskolen i Oslo og Akershus. Ikke bare fikk vi bruk for kursene direkte, men kursene har gitt oss en base til å utvikle kunnskapen vår videre på. Ved å være bevisst på dette lærte vi mer og på en mer fordelaktig måte enn å ikke ta tverrfagligheten i betraktning. Under følger en liste over kurs vi har fått bruk for, og en liten beskrivelse av hva det spesefikke kurset ga oss i forhold til dette prosjektarbeidet. 67

68 Kursnavn Webprogrammering Databaser Webprosjekt Systemutvikling Menneske maskin interaksjon Operativsystemer Datasikkerthet Nettverk og systemadministrasjon Effektiv kode med C og C++ Algoritmer og datastrukturer Bruksområder HTML og CSS, databaseoppbygging og kodespråkene PHP og JavaScript samt arbeid i NetBeans Databaseoppbygging/-struktur og SQL-spørringer HTML, CSS og generell nettsideoppbygging Prosjektarbeid og metodikk, planlegging, skjemaer/figurer Universell utforming herunder designbeslutninger o.l. Bash-programmering, PowerShell-programmering, kommandolinje i Unix og Windows Passordsikring, sikkerhetsprinsipper i webapplikasjoner Kommandolinje i Unix, serverkunnskaper i forhold til webapplikasjonen Grunnleggende erfaring ved bruk av Git og Github Logisk oppsett av datastrukturer og algortimer i webapplikasjonen, som for eksempel sorteringsalgoritme i roller (Se appendiks B for nærmere informasjon om sortering i roller) I denne listen burde egentlig alle tidligere kurs stått, da programmeringskunnskaper, datastrukturer og fordypning/trening i forskjellige kodespråk har hjulpet oss i dette prosjektarbeidet, men listen over gir en mer spesefikk beskrivelse av hvilke, og hvordan vi har fått bruk for kursene. 68

69 Eget utbytte Som nevnt tidligere har vårt hovedutbytte av dette prosjektarbeidet vært erfaringen og kunnskapene som vi vil få meget god nytte av i arbeidslivet. I tillegg har vi lært mye om hvordan å være mer nøye, strukturerte og vi har også forbedret vår evne til å tilegne oss ny og ukjent kunnskap. Det å jobbe i en gruppe har helt klart gitt oss erfaring og kunnskap om hvordan dette gjøres på mest mulig fordelaktig måte, herunder planlegging, delegering av arbeidsoppgaver, samhandling (både internt og eksternt) og det å løse små og større problemer innad i gruppen. Dette er kunnskap som er mye verdt i fremtiden, enten det er i en arbeidssituasjon eller ikke Veien videre Oppdragsgiver ønsket å begynne å bruke implementasjonen så fort som mulig, og har etter siste møte ytret ønsket om å kunne teste webappliasjonen på møter. Ettersom vi ikke kunne garantere for innholdet som ble generert og lagret før webapplikasjonen var ferdig utviklet har ikke oppdragsgiver benyttet webapplikasjonen etter prototypen som ble benyttet under brukertesten (se testdokumentasjon for brukertesten). I skrivende stund er selve implementasjonen klar til å settes i bruk, men utrullingen av webapplikasjonen er satt på hold til sluttrapporten er levert. Vi anslår at webapplikasjonen vil være ute i sin første kjørende versjon i løpet av sommeren. Oppdragsgiver har et sterkt ønske om at gruppemedlemmene fortsetter å utvikle webapplikasjonen fra hva den er i dag. Dette innebærer hovedsakelig å legge inn mer funksjonalitet, samt vedlikeholde og forbedre allerede implementert funksjonalitet. Både vi og oppdragsgiver ville hatt mye glede av å utvide og vedlikeholde prosjektet i fremtiden. Selve implementasjonen er satt opp på en slik måte at det enkelt skal la seg gjøre å utvikle webapplikasjonen videre. 69

70 2.8.5 Nytteverdi for oppdragsgiver Oppdragsgivers nåværende arbeidsmetode og verktøy har lenge vært til stor frustrasjon hos oppdragsgiver. De følte at deres nåværende verktøy var tungvindte og lite skreddersydde deres bedriftsmodell. Etter testing av webapplikasjonen har de vist stor interesse og glede over at det endelig er skreddersydd og at de kan bruke det som et virkelig verktøy. Dette vil resultere i bedre stuktur og mindre tid brukt til opplæring og problemer. I et fremtidig perspektiv kan også denne webapplikasjonen øke nivået av trivsel hos oppdragsgiver, da en faktor til frustrasjon er nåværende og ikke-fungerende verktøy Oppdragsgiver om webapplikasjonen Gjennom prosessen av denne oppgaven har vi hatt flere møter. For det meste har kontaktperson i Meso hatt de fleste møtene med studentene, men vi har også samlet alle i selskapet for en felles gjennomgang og presentasjon. For oss i Meso har dette vært en god prosess, hvor studentene har vært enkle å prate med, og flinke til å sette seg inn i vår situasjon og våre ønsker og krav. Det har ikke blitt avtalt for mange møter, noe vi syns er bra ettersom begge parter er opptatt med hvert sitt. I vært eneste møte har det vært konkrete spørsmål, gode presentasjoner og oppdatering på hvordan studentene ligger an. Slik prosjektet ser ut i dag, vil dette løse store utfordringer for oss i Meso. Det vil skape en mer effektiv hverdag, hvor alt av papirarbeid kan utføres digitalt. Løsningen for lagring av kundeopplysninger vil også føre til at vi kan gå bort i fra en tilsvarende løsning vi bruker i dag, som er lite tilpasset og innebærer store kostnader. Løsningen studentene har laget blir pratet om i forskjellige selskaper i Finans-Oslo i dag, og vi er overbevist om at det er flere enn oss som kunne ha behov for et tilsvarende produkt en dag i fremtiden. - Lasse Bøe, Co-Founder og invisteringsrådgiver, Meso Capital Markets 70

71 2.8.7 Oppsummering og konklusjoner Vi ser oss meget fornøyd med prosessen som har ført til det ferdige resultatet, alt fra valget av oppgaven som viste seg å være en perfekt utfording innenfor tidsrammene et hovedprosjekt legger til grunne, frem til ferdigstilling av rapporten. Både utviklingsverktøyene og utviklingsmetodikken har passet godt til både oppgaven og hvordan gruppemedlemmene har jobbet sammen. Ved å være nøye med kravspesifikasjon og vedlikeholde en fremdriftsplan har vi hatt et ypperlig forhold til oppdragsgiver og vi har hatt få uoverensstemmelser. At webapplikasjonen, etter alle solemerker å dømme, ser ut til å dekke de kravene som ble satt i begynnelsen av planleggingsfasen kan vi se tilbake på en vellykket prosess som har ført til det ferdige produktet. 71

72 Denne siden er blank med hensikt.

73 Kapittel 3 Produktdokumentasjon 3.1 Forord I produktdokumentasjonen tar vi for oss det ferdige resultatet av webapplikasjonen. Vi tar for oss de viktigste elementene i webapplikasjonen for å forstå hvordan den er bygd opp og samspillet mellom de forskjellige delene av webapplikasjonen. I produktdokumentasjonen tar vi ikke for oss konkrete kodeeksempler og går heller ikke dypere teknisk enn hva som er nødvendig for å få en helhetlig forståelse for webapplikasjonen. Man skal derfor kunne lese produktdokumentasjonen uten større teknisk innsikt. For å få en nærmere beskrivelse av webapplikasjonen på et teknisk plan vises det til appendiks A for PDFtk (Kapittel 7) og appendiks B for Laravel (Kapittel 8). Contents 3.1 Forord Beskrivelse av webapplikasjonen Hva webapplikasjonen gjør i korte trekk Webapplikasjonens byggeklosser Samsvar mellom kravspesifikasjon og ferdig produkt Sentrale datastrukturer i programmet Innledning På et overordnet plan - MVC

74 3.4.3 De sentrale modellene Modellrelasjoner Handlinger Roller Logger Biblioteker Mappestruktur Programmets virkemåte Oppstart av webapplikasjonen Ansatthandlinger i nettleseren Kundehandlinger i nettleseren Ansatthandlinger i bruk Kundehandlinger i bruk Spesifikke handlinger i bruk PDF håndtering Design Innledning Brukersentrert design Brukergrensesnitt (UI) Brukeropplevelse (UX) Optimalisering for tablets og smarttelefoner Universell utforming Rammeverk og teknologier tatt i bruk Sikkerhet Kryptert kommunikasjon - HTTPS Filaksess Passordblokkering Regex Backup Systemkrav Klientside

75 3.8.2 Serverside

76 Denne siden er blank med hensikt.

77 3.2 Beskrivelse av webapplikasjonen Hva webapplikasjonen gjør i korte trekk Webapplikasjonen tar sikte på å digitalisere en arbeidsrutine som i dag fremstår som en papirmølle. Dette for å forenkle jobben for invisteringsrådgiverne i Meso Capital Markets (oppdragsgiver). Webapplikasjonen fungerer som et kundebehandlingsverktøy, men dens viktigste funksjon er å opprette, lagre og distribuere kontraktene til Meso Capital Markets samarbeidspartnere, samt kunden selv Webapplikasjonens byggeklosser Webapplikasjonen er i all hovedsak bygget opp i PHP-rammeverket Laravel med underliggende programmer for å tilby den helhetlige funksjonaliteten som oppdragsgiver ønsket. Figur 3.1: Webapplikasjonens byggeklosser Boksene med heltrukket linje indikerer språk, og boksens størrelse indikerer bruk i webapplikasjonen. Boksene med stiplede linjer indikerer programmer/rammeverk og er plassert der de hører hjemme i forhold til språkene. 77

78 1. PHP er programmeringsspråket som danner grunnlaget for webapplikasjonen, og som rammeverket Laravel (Se punkt 4.) er skrevet i. 2. Bash benyttes både i forbindelse med PDFtk (Se punkt 5) men også i forbindelse med Laravel da visse funksjoner for Laravel kjøres gjennom Bash. Se Teknisk Appendiks - Artisan for mer informasjon. 3. MySQL har en meget sentral rolle i webapplikasjonen selv om det ikke ser slik ut ved første øyekast på koden. Dette skyldes at all kommunikasjon med MySQL skjer via rammeverket Laravel (Se punkt 4) og dermed blir en passiv del av webapplikasjonen. 4. Webapplikasjonens ryggrad ligger forankret i rammeverket Laravel som setter opp den logiske strukturen for webapplikasjonen. 5. PDFtk er et kommandolinjeverktøy som manipulerer PDF-filer, og brukes i kontraktsprosessen, og er dermed en kjernefunksjonalitete i webapplikasjonen, selv om det kun er et par linjer med kommandoer som benyttes. 3.3 Samsvar mellom kravspesifikasjon og ferdig produkt Kravspesifikasjonen bestod av en liste med funksjonelle og ikke-funksjonelle krav. Disse kravene kom vi frem til i samarbeid med oppdragsgiver. Av alle kravene valgte vi å kategorisere disse med en prioritet avhengig av hvor vesentlig kravet var, med en bokstavrangering fra A-D. Etter dette tok vi en helhetlig vurdering av hva vi kom til å rekke og ikke med tanke på tiden vi hadde til rådighet, og bestemte oss for å oppfylle alle krav med A- og B-prioritet. Alle de kravene vi satt oss til å gjennomføre ble gjennomført etter satt tidsplan. De resterende kravene vil vi mulig oppfylle i en videre utvikling av webapplikasjonen, les mer i prosessdokumentasjonen under punktet 2.8.4, Veien videre. 3.4 Sentrale datastrukturer i programmet Innledning For å ha en god oppfattelse om hvordan webapplikasjonen henger sammen er det viktig å forstå relasjonene som danner grunnlaget for webapplikasjo- 78

79 nen. Her fremkommer en forklaring og logisk beskrivelse av hvordan webapplikasjonen er satt sammen, mens en mer teknisk beskrivelse av de forskjellige komponentene fremkommer i appendiks B for Laravel (Kapittel 8) På et overordnet plan - MVC MVC er en lagdelt struktur som gjør det enklere å strukturere kode og muliggjør mer kompliserte webapplikasjoner. MVC deler opp i tre lag, se figur 3.2. Modeller Modellene representerer objektene som behandles i webapplikasjonen. Ved å gjenbruke en modell har man en fast struktur på objektene man initierer og kan på denne måten gjenbruke kode flere steder i webapplikasjonen. De viktigste modellene i webapplikasjonen er modellene som skaper fundamentet i webapplikasjonen og som har relasjoner til de andre modellene i webapplikasjonen. Views Views er det visuelle som møter brukeren av webapplikasjonen. Viewene får inn data fra controllerne i form av modeller. I viewene omformes dataen til HTML som vises i brukerens nettleser. Våre views skiller på om de er hovedviews eller underviews. Et hovedview kan aksesseres via nettleseren som vist i figur 3.4 og 3.5 mens underviews aksesseres gjennom hovedviewene. Hver enkel handling i webapplikasjonen er knyttet mot enten et hovedview eller underview, så hvor mye innhold en bruker av webapplikasjonen får frem på en side avhenger av dens tilgangsnivåer. (Les mer om dette under handlinger og ACL nedenfor). 79

80 Controllere Controllerne er selve hjertet i applikasjonen som tar imot henvendelser fra brukeren og henter frem alle modeller som skal til for å generere etterspurt side, og eventuelle annen data som skal vises for brukeren 15 Figur 3.2: Gangen i MVC-strukturen

81 3.4.3 De sentrale modellene Ansatt (user) Ansatt er modellen som representerer en ansatt i webapplikasjonen og kan være admin, rådgiver eller resepsjonist. Den ansatte logger inn på webapplikasjonen og får tilgang på sin begrensede del av webapplikasjonen. Kunde (customer) Kunde er modellen som representerer en kunde i webapplikasjonen. Kunden kan enten være en bedriftskunde med kontaktinformasjon, eller en privatkunde. En kunde kan ikke logge inn på webapplikasjonen. Kalenderoppføring (calendarevent) Kalenderoppføring er modellen som representerer en kalenderoppføring i webapplikasjonen. Alle kontrakter skal knyttes mot en kalenderoppføring slik at det er mulig å hente frem statistikk på hvor mange kontrakter som er opprettet i forhold til hvor mange møter som er blitt holdt. Kontrakt (otccontract) Kontrakt er modellen som representerer en kontrakt i webapplikasjonen. Kontrakten inneholder nøkkelinformasjon om kontrakten (informasjon om kontrakten som benyttes til å genrere statistikk og oversikt over fortjeneste). All innholds-informasjon i kontrakten lagres kun i PDF-filen som genereres. ACL (customercustroleuser) ACL (Access Control List) er kontrollen på hvilke ansatte som har tilgang på hvilke kunder, og hvilken form for tilgang de har. ACL innholder informasjon om hvilken kunde det gjelder, hvilken ansatt det gjelder, og tilgangsnivået den har. For oppslag på en kunde er det ACLen som vil sjekkes for å se om innlogget kunde har tilgang på etterspurt handling. 81

82 I tillegg til overnevnte modeller er handlinger og logger sentrale modeller i webapplikasjonen, men blir nærmere beskrevet i kommende avsnitt Modellrelasjoner I webapplikasjonen er det i alt 26 modeller. En av disse er kun for å lagre informasjon om oppdragsgivers bedrift, og det er da i alt 25 modeller som er med på å bygge opp den logiske strukturen i webapplikasjonen. For en nærmere beskrivelse om hvordan dette fungerer sammen på et teknisk plan se Appendiks B for Laravel (Kapittel 8). Figuren på påfølgende side viser alle de 25 modellene og relasjonen mellom dem. 82

83

84 3.4.5 Handlinger Hele webapplikasjonen og dens funksjonalitet bygger på handlinger som har sin bestemte oppgave. Ettersom webapplikasjonen skal inneholde sensitiv informasjon om kunder og deres kontrakter er det viktig å knytte alle endringer tilknyttet både kunder og ansatte mot en bestemt handling slik at alle opprettelser og endringer kan spores opp. Ved å legge til restriksjoner på hvem som har tilgang på hvilke handlinger samt at det kan logges bruk av en handling, vil alle endringer i systemet kunne knyttes mot én bestemt handling av én ansatt. Webapplikasjonen har to sett med handlinger. Handlinger som er direkte tilknyttet ansatte, og handlinger som er knyttet til kundene. På denne måten kan man ha tilgang på alle ansatthandlinger, men har ikke av den grunn innsyn på kunder, såfremt de ikke er rådgivere for kunden. I kraft av dette har man også tilgang på kundehandlinger på den bestemte kunden. Både kundehandlinger og ansatthandlinger har en variabel som tilsier om handlingen trenger en id for å bli utført eller ikke. Et eksempel på en handling som trenger id er å endre informasjon på en bestemt ansatt, mens det å se på alle ansatte ikke trenger noen konkret id for å utføres. Om handlingene trenger id eller ikke kommer frem av tabell 3.1 og 3.2. Ettersom alle kundehandlinger er knyttet mot en kunde med variabelen $custid er det for kundehandlinger id-avhenig når det spesifiseres for eksempel en enkelt kontrakt, eller en enkelt kalenderoppføring. Ansatthandlinger (actions) Ansatthandlinger er handlinger som utføres av og på en ansatt. Dette kan være alt fra å opprette en ny ansatt, endre en ansatts rolle eller endre passordet på en ansatt. Disse handlingene er (med visse unntak, se avsnitt 3.4.5) løsrevet fra kundene. Det vil si at en rådgiver som får tilgang på alle ansatthandlingene i systemet fortsatt ikke kan se på andre rådgiveres kunder såfremt de ikke er rådgiver for kunden selv. 84

85 Tabell for ansatthandlinger Handling HV ID Beskrivelse AD RÅ RE adduser x Legg til ansatt x addcustomer x Legg til kunde x x x viewusers x Se alle ansatte x x x viewdeletedusers Se tidligere ansatte x viewcustomers x Se alle kunder x x x viewmyprofile x Min profil x x x viewmylog x Min logg x x x viewmyactions x Mine rettigheter x x x viewmycalendar x Min kalender x x x viewmycontracts x Mine kontrakter x x x viewmycustomers x Mine kunder x x x viewactions x x Se tilganger x x x edituser x Endre ansatt x editpassword x Endre passord x viewuser x x Ansattoversikt x x x grantactions x Legg til tilleggstilgang x viewuserlog x x Ansattlogg x x x viewuserautlog x Automatiske logger x x x deleteuser x Slett ansatt x viewcontracts x x Se alle kontrakter x x viewlastuserlogs x Siste logger tilknyttet ansatte x viewlastcustlogs x Siste logger tilknyttet kunder x x x changerole x Endre rolle x viewuserunauthlog x Logg for uautorisert kundeaksess x post x Endring av mine detaljer x x x createnewotccontract x x Lag ny annenhåndskontrakt x x viewcalendar x x Kalender x x x addevent x Legg til aktivitet x x x viewassoccustomers x x Tilhørende kunder x x x 85

86 addtemplate x Legg til nytt skjema x x viewtemplates x Se alle PDF-skjemaer x x x viewtemplate x x Skjemavisning x x x filltemplate x x Fyll skjema x x setuptemplate x x Sett opp skjema x x edittemplate x x Endre skjema x x search x Søk x x x settings x Systeminstillinger x editcompany Endre bedriftsdetaljer x takecontractsbackup x Ta backup av kontrakter x Tabell 3.1: Oversikt over ansatthandlinger HV=Er et hovedview, ID=Trenger id for å utføres, AD=Inngår i nsattrollen administrator, RÅ=Inngår i ansattrollen rådgiver, RE=Inngår i ansattrollen resepsjonist 86

87 Kundehandlinger (custactions) Kundehandlinger er handlinger som utføres av en ansatt på en kunde. Dette kan være alt fra å redigere kundeprofilen til å signere en kontrakt. Handling HV ID Beskrivelse FT BT view x Se på kunde x x viewcontracts x Se kontrakter x x viewcontract x x Se på kontrat x x viewcontractpdf x x Se på kontraktsdokement x x viewcustomerlog x Kundelogg x x viewcustautlog Se automatiske logger x x viewusers x Se rådgivere med tilgang x x adduser Legg til rådgiver x edituser Endre tilgang x deleteuser Fjern rådgiver x viewattachments Vise alle vedlegg x addattachment Legg til vedlegg x addexistingattachment kundefil Legg til eksisterende x viewattachment x x Se på vedlegg x x viewfiles x Vis kundefiler x x editcustomer Endre kundeinformasjon x cancelotccontract x x Slette kontrakt x signotccontract x Signere kontrakt x custaddfile Legg til kundefil x viewfile x x Se på kundefil x x downloadzip x Last ned backup x x viewevent x x Se på aktivitet x x addevent x Legg til ny aktivitet x Tabell 3.2: Figur over alle kundehandlinger HV=Er et hovedview, ID=Trenger id for å utføres, AD=Inngår i ansattrollen administrator, FT=Inngår i kunderollen full tilgang, BT=Inngår i kunderollen begrenset tilgang. 87

88 Mulighet for tilleggs- ansatthandlinger Det er også mulig å gi en ansatt tilgang på handlinger som den ikke har via sin rolle, men som ekstrahandlinger. Fra de predefinerte rollene er det kun en administrator som kan gjøre dette, men ettersom det også er mulig for å andre å få tildelt denne handlingen (grantactions) er dette satt opp på en slik måte at man kun kan gi tilgang på handlinger man har i kraft av sin rolle, ikke som man selv har som tilleggshandlinger. Handlinger på tvers av handlingssettene addcustomer er hovedsaklig en ansatthandling ettersom handlingen i seg selv ikke er tilknyttet en bestemt kunde, men vil være det etter at handlingen er gjennomført. addevent og createnewotccontract var ønsket fra oppdragsgiver å ha en generell visning for å legge til oppføringer i kalenderen uten at man måtte gå inn på kunden først. Dermed ble også disse handlingene ansatt-handlinger selv om de ved gjennomført handling vil knyttes mot en bestemt kunde når handlingen er gjennomført Roller Ansattroller For å forekle bruken av webapplikasjonen er det predefinerte roller som kan benyttes. Dette gjør det mulig å opprette nye ansatte ut fra et sett med handlinger istedenfor å spesifisere tilgangen til hver enkelt bruker. Rollene har et predefinert sett med handlinger som gir de ansatte den tilgangen de trenger for å utføre sitt arbeid (Se tabell 3.1). I tillegg til disse predefinerte rollene er det mulig å gi tilleggsrettigheter utover hva rollen inneholder. Se avsnitt De forskjellige ansattrollene: Administrator (admin) er den høyest rangerte ansatte i webappliksjonen og er tiltenkt sjefer som skal ha tilgang på alle funksjoner og alle kunder. For å bevare sikkerhetsmekanismene i webapplikasjonen som baserer seg på least privileged (At man kun har tilgang på det som trengs for å utføre sine arbeidsoppgaver) er det viktig å avgrense denne 88

89 rollen til kun de som trenger og har krav på denne rollen. Om alle skal være administrator vil det undergrave alle sikkerhetsmekanismene som er satt opp for å bevare kundesikkerheten. Rådgiver (user) er rollen for den vanlige bruker i webapplikasjonen som jobber som rådgiver hos oppdragsgiver. For å kunne bli lagt til som en ny rådgiver på en kunde må man ha denne rollen. Resepsjonist (logger) er rollen for ansatte som skal ta i mot samtaler og henvendeler fra kundene, men ikke har noen direkte tilknytning til kontrakter. I motsetning til en rådgiver kan resepsjonisten se informasjon og manuelle logger for alle kunder, men har aldri tilgang på kontrakter på kunden. Kunderoller Tilsvarende som med ansattroller er det laget et par predefinerte roller som styrer den ansattes muligheter på en kunde. Dette igjen for å begrense hvem som har full tilgang når de ikke trenger det for å utføre sin arbeidsoppgave. De forskjellige kunderollene: Full tilgang (editer) er rollen om man er en av kundens primære rådgivere og hjelper kunden aktivt med kjøp og salg. Med denne rollen har man, som navnet sier, full tilgang på kunden. Begrenset tilgang (viewer) er en noe mer begrenset tilgang på en kunde som gir muligheten til å se alt av informasjon og kontrakter, men har ikke mulighet til å endre informasjon på kunden eller opprette nye kontrakter. Dette gjør det mulig å gi kollegaer innsyn på en kunde uten at de kan gjøre endringer på grunn av dette Logger Med handlinger som grunnlag for alle endringer i webapplikasjonen er det mulig å knytte alle endringer mot en bestemt handling av en bestemt ansatt. For å få utnyttet dette potensialet finnes det i webapplikasjonen flere forskjellige logger som utdyper den utførte handlingen, samt gjør den tilgjengelig i webapplikasjonen, slik at man ikke må gjøre et dypdykk i databasen for å avklare en situasjon. 89

90 Logger i webapplikasjonen: Automatisk kundelogg (custlogauto) som logger utførte kundehandlinger på en kunde. Automatisk ansattlogg (userlogauto) som logger utførte ansatthandlinger på en ansatt. Logg for forsøk på uautorisert aksess (userlogunauth) som logger om en ansatt forsøker å foreta seg noe på en kunde den ikke har tilgang på. Manuelle logger på en kunde (custlogmanual) som manuelt legges til av en ansatt. Manuelle logger på en ansatt (userlogmanual) som manuelt legges til av en ansatt. I tillegg til loggene som genereres automatisk ved bruk av handlinger i webapplikasjonen er det mulig å legge til manuelle loggoppføringer på både ansatte og kunder (de to siste loggene i listen over). Disse loggene knyttes imidlertid ikke mot en bestemt handling, men blir knyttet mot predefinerte loggtyper. Manuelle loggtyper: Telefon inn Telefon ut Mail inn Mail ut Møte inne Møte ute Notis 90

91 3.4.8 Biblioteker For å kunne gjenbruke kode som ikke er direkte tilknyttet en bestemt modell har vi laget flere biblioteker med kode som kan benyttes uansett hvor i strukturen man befinner seg. Dette forenkler koden og gjør at lignende elementer i webapplikasjonen blir like alle steder, og eventuelle forbedringer eller endringer vil gjenspeiles over alt biblotekmetoden benyttes, ikke bare et spesifikt sted. Biblotek ENUM Filetypes FlxZipArchive Helpers HorizontalMenu Mails PDF Templates Timpestamp Bruksområde Tallkonstanter Generelle metoder for å bestemme om det er en tillatt eller forbudt filtype, samt andre tester eller endringer på filer i webapplikasjonen. Importert bibliotek for å rekursivt lage ZIP-fil av en mappe og dens innhold. Et generelt bibliotek med metoder som ikke faller naturlig under ett av de andre bibliotekene. Setter den horisontale menyen i webapplikasjonen basert på innlogget brukers tilgangsnivåer og returnerer den til viewene. Bibliotek for sending av mail ut fra webapplikasjonen. Innholder metoder som bestemmer innhold og mottaker for mailer. Biblioteket som er knytningspunktet mellom PHP og Bash. Gjør PDFtk operasjoner for å manipulere PDF-filer. Bibliotek for metoder tilknyttet oppsett av skjemaer Bibliotek for generalisering av tid. Både for å printe ut riktig tidsformat og finne tidsdiffernaser 91

92 URLS math paths Bibliotek for å generere lenker i webapplikasjonen Bibliotek for å gjøre utregninger og omforminger av tall Bibliotek for mappestrukturen i webapplkasjonen ( Se avsnitt for nærmere informasjon om mappestrukturen). Tabell 3.3: Oversikt over biblioteker Mappestruktur For at filene i form av kontrakter, vedlegg og annen sensitiv informasjon ikke skal være lagret slik at dette kan aksesseres direkte er all lagring lagt før serverens internettkatalog (public html\). Alle filer er lagret i en mappe PDF\ som befinner seg på samme nivå som internettkatalogen. Videre for å kunne hente frem disse filene i webapplikasjonen har vi laget flere viewere som henter frem filene fra PDF\-mappen og viser de til brukeren i nettleseren. Se teknisk appendiks for mer om Viewers. 92

93 Kodesnutter 3.1: Filstruktur p u b l i c h t m l / PDF/ Core/ Final / [ 1 ] KundesNavn/ f i l e s / attachments / f i l l e d t e m p l a t e s / o t c c o n t r a c t s / [ 1 ] Kontraktnavn / c o n t r a c t. pdf c o n t r a c t s i g n e d. pdf c o n t r a c t c a n c e l e d. pdf f i l l e d t e m p l a t e s / attachments / Temp/ Templates / 1. Mappen hvor webapplikasjonens implementering er plassert i 2. Rotmappen for PDF-håndtering til webapplikasjonen 3. Mappen som inneholder filene som benyttes for PDFtk 4. Mappen som inneholder kundefiler 5. En eksempelkundes mappe med ID i firkantparantes 6. Kundens filer 7. Kundens opplastede vedlegg 8. Kundens utfylte skjemaer som er lagret som kundefil 9. Kundens kontrakter 10. En eksempelkontrakt med ID i firkantparantes 11. Selve kontraktsdokumentet 12. Signert kontraktdokument (eksisterer kun om den er signert) 13. Kansellert kontraktdokument (eksisterer kun om den er kansellert) 14. Utfylte skjemaer på en kontrakt 15. Vedlegg tilknyttet en kontrakt 16. Mappen som inneholder hver enkelt brukers datafil for generering av skjemaer via PDFtk 17. Mappen som inneholder opplastede skjemaer 93

94 3.5 Programmets virkemåte Oppstart av webapplikasjonen Figur 3.3: Illustrasjon av oppstart av webapplikasjonen 1. Den ansatte etterspør en side i webapplikasjonen. 2. Webapplikasjonen undersøker om den ansatte er logget inn. 3. Om den ansatte ikke er logget inn må den ansatte logge inn i webapplikasjonen. 4. Webapplikasjonen verifiserer innloggingen. 5. Webapplikasjonen ser om den ansatte er blokkert, om ikke økes antall feilinnlogginger. 6. Den ansatte får fremvist etterspurt side. Om den ansatte i punkt 1. har spurt etter en spesifikk side blir den ansatte sendt videre til etterspurt side. 94

95 3.5.2 Ansatthandlinger i nettleseren Når man bruker webapplikasjonen kommer aktiv ansatthandling frem av REST-ful lenken som siste paramenter i lenken, så fremt handlingen ikke benytter en id, da vil dette legges til som en /id. Figur 3.4: Illustrasjon av ansatthandling i nettleseren Kundehandlinger i nettleseren Når man bruker webapplikasjonen på kundesiden vil det av REST-ful lenken komme frem kundenummer bak customer, og videre aktiv kundehandling som siste parameter i lenken, også her så fremt handlingen ikke benytter en id som også vil legges til som /id i lenken. Figur 3.5: Illustrering av ansatthandling i nettleseren 95

96 3.5.4 Ansatthandlinger i bruk Figur 3.6: Aktivitetsdiagram for ansatt-handlinger 1. Ansatte befinner seg på oppslagstavlen eller annen side i webapplikasjonen. 2. Ansatte etterspør en ansatthandling. 3. Webapplikasjonen undersøker om den ansatte har tilgang til etterspurt ansatthandling via sin ansattrolle. 4. Webapplikasjonen undersøker om den ansatte har tilgang på etterspurt ansatthandling via sine tilleggshandlinger. 5. Ansatt får tilgang på ansatthandling. 96

97 3.5.5 Kundehandlinger i bruk Figur 3.7: Aktivitetsdiagram for kunde-handlinger 1. Ansatte befinner seg på oppslagstavlen eller annen side i webapplikasjonen. 2. Ansatte etterspør en spesifikk kunde. 3. Webapplikasjonen undersøker om den ansatte har tilgang til kunden via sin ansattrolle. 4. Webapplikasjonen undersøker om den ansatte har tilgang til kunden via sin kunderolle for kunden. 5. Den ansatte etterspør en spesifikk kundehandling 6. Webapplikasjonen undersøker om den ansatte har tilgang til den spesifikke kundehandlingen på etterspurt kunde. 7. Ansatt får tilgang på kundehandlingen på etterspurt kunde Spesifikke handlinger i bruk De fleste handlingene i webapplikasjonen med endringsmuligheter (POSTmetoder) gjør som beskrevet i tabell 3.1 og 3.2. Det er imidlertid et par 97

98 handlinger som er sammensatt til et handlingssett og trenger en næmere beskrivelse. Disse er også en vitale funksjoner i webapplikasjonen. Sette opp et skjema Det å sette opp et skjema er nødvendig for å kunne legge ved og bruke en PDF på en kontrakt. Ved å sette opp et skjema analyseres skjemaet ved hjelp av PDFtk, og finner alle feltene i PDF-filen. Når skjemaet er satt opp én gang kan skjemaet gjenbrukes i senere kontrakter. Ordene i parentes er ansatthandlingene som gjennomføres. Figur 3.8: Aktivitetsdiagram for å opprette et skjema 1. Ansatte laster opp et PDF-skjema. 2. Webapplikasjonen sjekker om skjemaet er et gyldig PDF-format som inneholder metadata. 3. Webapplikasjonen sender den ansatte videre for å sette opp PDF-filen til et skjema. Her predefineres felter, slik at felt A f.eks. alltid viser til kundens navn, felt B alltid viser til rådgiverens navn og så videre. Å sette opp et skjema er nødvendig for å kunne bruke det i en kontrakt. 4. Skjemaet er klart til bruk. Om man avbryter prosessen med å sette opp skjemaet vil det ikke kunne bli brukt i kontrakter før dette er gjennomført. 98

99 Opprette en kontrakt Skjemaet som har identifikasjonsnummer 1 er ordreblanketten som benyttes i alle kontrakter. Man trenger derfor ikke å spesifisere at den skal være med på en kontrakt, den vil derimot legges ved automatisk. Det å opprette en kontrakt går på tvers av handlingssettene. Dette er vist i figuren nedenfor med en horisontal strek. Ordene i parentes er ansatthandlingene/kundehandlingene som gjennomføres. Figur 3.9: Aktivitetsdiagram for å opprette et skjema 1. Den ansatte oppretter en kalenderoppføring med en kunde. 2. Den ansatte velger videre å opprette en kontrakt. Ettersom en kontrakt alltid skal knyttes mot en kalenderoppføring sendes den nylig op- 99

100 prettede kalenderoppførings-iden med til kontraktopprettelsen. I kontraktopprettelsen spesifiseres det hvilke skjemaer som skal legges ved i kontrakten, og om den utfylte utgaven eventuelt skal lagres i kundefiler for gjenbruk senere. 3. Webapplikasjonen sender den ansatte videre til utfylling av valgte skjemaer, dette inkluderer den forhåndsvalgte ordreblanketten. Alle felter som er predefinerte i oppsettet av skjemaet vil her være ferdig utfylte. 4. Webapplikasjonen oppretter kontrakten, genererer et kontraktsdokument og alle utfylte skjemaer, samt legger dem på riktig sted i mappestrukturen (Se avsnitt 3.4.9). 5. Den ansatte velger eventuelle kundefiler som tidligere er lastet opp og som også skal legges ved i kontrakten. Disse blir fysisk kopiert inn i kontraktes mappestruktur. Signerte utgaver av vedleggene må også lastes opp om de skal signeres. 6. Den ansatte velger om det skal legges ved ytterligere vedlegg som skal lastes opp kun tilknyttet kontrakten. Signerte utgaver av vedleggene må også lastes opp om de skal signeres. 7. Den ansatte laster ned kontrakten, og får en kundesignatur på dokumentet, før det lastes opp igjen i systemet. Signeringsprosessen kan man lese mer om i Brukerveiledningen. 8. Webapplikasjonen sjekker at det er lagt ved kopi av legitimasjon enten i punkt 5 eller 6. Om ikke må dette gjøres før kontrakten er ferdig. 9. Den ansatte kan velge å sende kontrakten ut til både kunden og til sine samarbeidspartnere PDF håndtering Innledning For å håndtere sluttbrukers allerede eksisterende skjemaer, som systemet skulle kunne operere med, var det meget avgjørende å finne et verktøy som kunne hente ut meta-data fra eksisterende PDF-dokumenter, og legge til nytt innhold på disse. Alle de konvensjonelle PDF-verktøyene som kunne integreres tett ved hjelp av biblioteker i de ulike språkene var gode på å produsere PDF-dokumenter fra bunnen av, og gjøre ulike manipulasjoner, men ingen traff vårt spesifikke krav om å hente ut meta-dataene fra allerede eksisterende dokumenter. Til slutt falt valget på kommandolinjeverktøyet 100

101 PDFtk 16. Dette verktøyet gir oss muligheten til å hente ut de meta-dataene vi trenger, identifiserer de ulike feltene i et allerede eksisterende dokumenter, og kan også kombinere en datafil og et allerede eksisterende dokument til en utfylt versjon av PDF-dokumentet. Prebetingelser For at webapplikasjonen skal kunne behandle de eksisterende PDF-dokumentene, fylle disse med automatisk generert informasjon og tilleggsinformasjon gitt av bruker, er det én sentral prebetingelse som må oppfylles. De dokumentene som skal brukes som skjemaer i systemet, må være elektronisk utfyllbare. Det vil si at PDF-filen allerede har identifisert hvor i dokumentet de ulike feltene som skal fylles ut befinner seg. Når disse prebetingelsene er oppfylte kan webapplikasjonen benytte seg av de bakenforeliggende meta-dataene, og kombinere disse med data gitt av applikasjonen til et ferdig utfylt dokument. Implementasjon i webapplikasjonen Da PDFtk er et kommandolinjeverktøy er applikasjonen avhengig av å kommunisere ned på kommandolinjen i servermiljøet. Dette er løst ved at applikasjonen kaller på shell-skript skrevet for server-miljøet (Bash for UNIXbaserte miljøer, Powershell for Windows-baserte), som igjen bruker metoder gitt i verktøyet, og sender resultatene av disse kallene opp igjen til applikasjonen. 3.6 Design Innledning I denne delen skal det begrunnes valg tatt i henhold til design, herunder metodikk, brukergrensesnitt og brukeropplevelse, og andre valg tatt rundt dette. Det skal også nevnes at vi i denne sammenhengen også laget en brukertest til oppdragsgiver. Mer om dette kan leses i Testdokumentasjon - Brukertest. 16 PDFtk: 101

102 3.6.2 Brukersentrert design For denne webapplikasjonen valgte vi å aktivt la brukerne styre designet, en metode kalt brukersentrert design. Vi valgte å gå for denne metodikken da webapplikasjonen hovedsakelig skulle brukes av et lukket publikum, med andre ord kun de ansatte hos oppdragsgiver. Ved å ta i bruk denne metodikken forsikret vi oss om at webapplikasjonen ble mest mulig skreddersydd til deres ønsker, noe oppdragsgiver savnet i dagens løsninger. Denne metodikken byr også på utfordringer i form av hyppig og tett kontakt med brukerne. I vårt tilfelle var ikke dette et fremtredende problem, da vi gjennom hele prosjektarbeidet hadde god kontakt, og god mulighet til å spørre oppdragsgiver underveis. Gjennom flere møter, e-poster og direkte kontakt med oppdragsgiver fikk vi mange gode tilbakemeldinger på hva slags design de så for seg, samt endrings- og forbedringsforslag til designet underveis Brukergrensesnitt (UI) Farger og skrifttype ble hovedsaklig valgt ut fra oppdragsgivers eksisterende nettside 17 i samarbeid med oppdragsgiver. I planleggingsfasen ble det laget designskisser der både farger, fonttype og generell designretning forekom. Tilbakemeldingen på disse skissene var positive fra starten av, og disse la grunn for designet videre. Les mer under Designutvikling i prosessrapporten. Rent visuelt ble det lagt vekt på å ikke ha fokusstjelende elementer som skygger, animasjoner og liknende, men heller rette linjer og gode kontraster for å skape et oversiktlig, presist og rent bilde av webapplikasjonen utad. Her kan man også finne flere prinsipper fra designretningen flat design Brukeropplevelse (UX) Generelt er bruken av ikoner (ofte sammen med beskrivende tekst), fargekontraster og størrelse virkemidler som ble tatt i bruk for å hjelpe brukeren med å bruke webapplikasjonen på tiltenkt og best mulig måte. Under forklares det litt dypere om disse virkemidlene

103 Ikoner Alle ikoner er hentet fra open-source prosjektet Font Awesome 19. Vi valgte å ta i bruk denne ikonpakken da alle ikonene er i vektorgrafikk (i motsetning til rastergrafikk) noe som gjorde ikonene skarpere og klarere på forskjellige skjermstørrelser og enheter. I de fleste tilfeller av ikonbruk er et ikon represenert sammen med en beskrivende tekst. Disse elementene er ment å bygge hverandre opp slik at brukeren lettere kunne forstå både ikonet og teksten. I de tilfellene hvor det kun ble tatt i bruk et ikon var vi påpasselige med å velge et ikon som var mest mulig selvbeskrivende, for å fortsatt opprettholde en god brukeropplevelse. Disse tilfellene var som oftest de stedene hvor tekst, eller tilhørende tekst, var uhensiktsmessig for brukeropplevelsen. Dette var tilfeller hvor det ikke var plass til beskrivende tekst, det var overflødig (ikonet selv beskrev det godt nok) eller liknende. Det bør også nevnes at vi i noen tilfeller hadde vanskeligheter med å finne et passende ikon til vår situasjon ettersom vi måtte velge ut fra biblioteket til Font Awesome. Til tross for dette viste tilbakemeldinger fra brukerne oss at ikonbruken var forståelig og at det bidro til en god brukeropplevelse. Farger og -kontraster For å ha god synlighet og for at brukerne lettere skulle kunne skille på de ulike elementene i webapplikasjonen valgte vi hvit tekst på en blågrønn bakgrunn til hovedmenyen og toppinnholdet. For å skille meny/topp og innhold valgte vi en svært mørk grå tekst på hvit bakgrunn. Dette hadde som mål å skape tilstrekkelig kontrast for brukeren. For å indikere interaksjon, dette være seg interne lenker og åpning/skjuling av delinnholdet på utvalgte sider, valgte vi å bruke en lys blågrønn farge for å skille det fra resten av tekstinnholdet. Der det var hensiktsmessig valgte vi å lage en knapp av handlingen som utføres, for igjen å gjøre brukeren mer bevisst på hva slags operasjon den gjør. Knappene som utfører større oppgaver som lagre, legg til, utfør og liknende, har hvit tekst på en grønn bakgrunn. Den grønne bakgrunnen skiller seg kraftig ut med resten av designet, og trekker brukeren lettere mot målet av den spesefikke operasjonen. Grønn er også en vennlig farge som tilsier ting som går fremover (gå, klart og liknende) og kan sees i flere tilfeller i dagliglivet, for eksempel i trafikklys og grønn mann i gangfelt. Knapper med mindre oppgaver som last opp, velg og liknende, har samme blågrønne

104 fargen som man finner igjen i toppmenyen, dette for å ikke la knappene være for fremtredende. Valgene vi tok gjorde at brukeren raskere forstod hvilken rolle en spesefikk knapp spilte ved hjelp av fargebruken, i følge brukerne selv. Størrelse For å hjelpe brukeren med å skille innholdet i webapplikasjonen har vi også valgt å ta i bruk størrelseforskjeller hvor den tiltenkte effekten var at større størrelse ga mer fokus. Størrelsene og -forskjellene på tekstinnholdet er hentet fra nettstedet modularscale 20 som regner ut størrelseforhold ut fra en tekststørrelse man skriver inn. Vi valgte å øke tekststørrelsen på overskrifter, for at brukeren skal vite hvor den er, og på knapper, for at brukeren raskere skulle rettes mot operasjonen. Der det var innhold som krevde mindre oppmerksomhet av brukeren, men forstsatt var vensentlig, valgte vi å gå for en noe mindre størrelse. Basert på tilbakemelding fra brukerne var dette hensiktsmessig. Språk Rammeverket vi benyttet oss av i denne webapplikasjonen hadde et system for språk som vi valgte å ta i bruk. Vi laget flere språkfiler som en slags kategorisering, hvor hver fil hadde en liste med nøkkel-verdi-par for oversettelsen. Alle tekststrenger gjennom hele webapplikasjonen ble byttet ut med en referanse til riktig språkfil og nøkkel. Som et eksempel fikk man skrevet ut Fornavn ved å bruke rammeverkets metode for dette. Dette systemet la til rette for at en oversettelse av hele systemet i fremtiden vil være mye mindre arbeidskrevende. Ved å sette hvilket språk man skal bruke og å bytte ut verdiene i språkfilene vil en oversettelse av hele systemet være fullført. Til dette prosjektet valgte vi kun å oversette til norsk, da det er dette språket oppdragsgiver hovedsakelig skulle benytte seg av. I tabell 3.4 er det en liste over språkfilene med beskrivelse på hva slags tekststrenger som den respektive kategorien innehar

105 Språkfil actions custactions customerstatuses dbnames eventtypes feedback log logicons logtypes menus otccontract pagination pdf reminders text userroles validation Type tekststrenger De generelle handlingene i systemet Kundehandlinger i systemet Kundestatuser i systemet Databasefelter i systemet Aktivitetstyper i systemet Tilbakemeldinger i systemet Loggtekster i systemet Loggikoner i systemet Loggtyper i systemet Tekststrenger i menyer til systemet Tekststrenger tilhørende kontrakter i systemet Navigasjonsstrenger (frem, tilbake osv.) i systemet Tekststrenger tilhørende PDF-skjemaer i systemet Tekststrenger tilhørende glemt passord o.l. Generelle tekststrenger uten spesiell tilhørlighet Brukerroller i systemet Tekststrenger tilhørende validering i systemet Tabell 3.4: Språkfiler og hvilke tekststrenger de inneholder Tilbakemeldinger For å forsikre oss om at en bruker benyttet seg av systemet på tiltenkt måte var det nødvendig med validering og tilbakemeldinger rundt dette. Vi valgte å kategorisere tilbakemeldinger i følgende tre nivåer Feilmelding Meldinger der en operasjon ikke fullføres grunnet feil på input eller annet kritisk Suksessmelding Meldinger der en bekreftelse på en vellykket gjennomført operasjon gis Tilbakemelding Generelle tilbakemeldinger som verken er feil eller riktig Designmessig valgte vi å gi tilbakemeldingene et ikon og en farge etter hvilken type tilbakemelding det var. Fargene og ikonene ble valgt ut fra assosiasjoner som fargene gir. Rødt tilsier stopp, feil, fare og annet, grønt 105

106 tilsier gå, videre, vellykket og blått er en nøytral farge som gir verken gode eller dårlige assosiasjoner. Feilmelding Rød farge med et utropstegn som ikon Suksessmelding Grønn farge med en hake som ikon Tilbakemelding Blå farge med en snakkeboble som ikon Det ble gitt en mulighet for å lukke tekstboksene etter visning. Dette ble gjort for at brukeren skulle ha mulighet til å rydde opp på siden og fjerne lest innhold om ønskelig. Søk For å forenkle prosessen med å lete etter kunder, kontrakter og annen info i systemet valgte vi å implementere en søkefunksjon. På startsiden plasserte vi en søkeboks oppe i høyre hjørne på siden. Tekstboksen er også forsterket med en hjelpetekst Søk... og et søkeikon (forstørrelsesglass) for at brukeren umiddelbart skulle forstå at dette var et søk. Etter ønske fra oppdragsgiver søker dette søket kun på kunder og resultatene oppdateres for hver nye bokstav som skrives inn eller fjernes. Ved å trykke på entertasten etter innskrevet tekst vil man komme til søkeresultatene, hvor man også får frem resultater fra resten av webapplikasjonen. Her må man imidlertid trykke enter for hvert nøkkelord brukeren vil søke etter. Det er også implementert et søk i noen handlinger som for eksempel ved opprettelse av en aktivitet. Dette søket søker kun etter kunder, med en tilhørende sjekkboks. Søkefunksjonene er plassert i en egen kontroller JsonController. Det bør også nevnes at alle søk krever minimum tre tegn for å returnere resultat. Dette valgte vi å gjøre da to tegn ga alt for lite spisefikk informasjon, og ble mer en oppramsing enn et søk (mot sin hensikt) Optimalisering for tablets og smarttelefoner Optimalisering for tablets/nettbrett og smarttelefoner var ikke et spesefikt krav fra oppdragsgivers side, men senere i prosjektet valgte vi likevel å ta dette i betraktning. Hele idéen bak optimaliseringen var å fortsatt holde brukeren på den samme siden, uten en spesefikk side for enhetene. Dette 106

107 gjør at vedlikehold og endring av optimaliseringen ble vesentlig mindre arbeidskrevende, da det kun fokuseres på ett produkt, i motsetning til tre (eller flere). Dette førte også med seg utfordringer til designet, på den måten at applikasjonen ikke skulle være enhetsspesifikk, som igjen tilsa at siden måtte vises hensiktsmessig på alle enheter og plattformer. Les mer om hvordan dette ble gjort i Teknisk Appendiks - Design: CSS Media-Queries Universell utforming Gjennom hele prosjektet har vi tatt universell utforming i betraktning. Fra oppdragsgiverens side var dette ikke et krav men ettersom vi valgte å lage webapplikasjonen med mulighet for utvidelse senere, ble dette en naturlig del av vår designprosess. Ved å ha alt av tekstinnhold lesbart for tekst-til-taleverktøy, i motsetning til for eksempler å ha tekst i bilder, er både døve og blinde tatt i betraktning. Også ved å ha tilstrekkelig alternativ informasjon på bilder, lenker og andre elementer, som ikke nødvendigvis sier seg selv, oppnår vi en høyere grad av universell utforming. Også i tilbakemeldingene i applikasjonen vil bruken av ikoner hjelpe til å skille de forskjellige typene tilbakemeldingene for fargeblinde som for eksempel har problemer med å skille grønn og rød fra hverandre. 107

108 3.6.7 Rammeverk og teknologier tatt i bruk I designprosessen ble følgende rammeverk og teknologier tatt i bruk. Her nevnes utvikler, nettsted og en kort beskrivelse av den aktuelle tjenesten. Navn Beskrivelse Utvikler Kilde LESS.css Et css rammeverk som Alexis Sellier 21 Nettside 22 gjør det mulig å ta i bruk funksjoner, variabler og tag-nesting FontAwesome En ikonpakke med Dave Gandy 23 Nettside 24 ikoner i vektorgrafikk jquery Et javascript-bibliotek - Nettside 25 for animasjoner og effekter modularscale Verktøy som setter Tim Brown 26 Nettside 27 opp skriftstørrelser etter valgte skalaer. 3.7 Sikkerhet Da applikasjonen skulle være et internt system, men likevel være tilgjengelig over internett, ble sikkerhet en viktig del av applikasjonen Kryptert kommunikasjon - HTTPS Som et tiltak til økt sikkerhet er det mulig i filters.php (se appendiks B for Laravel, avsnitt 8.6.1) å legge til en Laravel-modul som tvinger all kommunikasjon til å bli kryptert og sendt over HTTPS. Ettersom servermiljøet den ferdige webapplikasjonen skal kjøres på ikke er klar er ikke dette en del av koden, men er nærmere beskrevet i nevnte appendiks

109 Da systemet kun er et internt system og kommer aldri til å bli eksponert ut mot sluttkunder for oppdragsgiver valgte vi en løsning med Self-Sign SSL Certiticate. Det vil i praksis si at HTTPS-sertifikatet er signert på egenhånd, og ikke av en tredjepartsautoritet. Dette er vanlig praksis for utviklingsprosjekter og en del interne systemer. Egensignerte sertifikater svekker ikke kvaliteten på krypteringen men er et kostnadsbesparende tiltak som ble gjort i samråd med oppdragsgiver Filaksess Systemet lagrer en del dokumenter som skal være tilgjengelige over nettet. For at ikke uautoriserte brukere skal kunne aksessere disse ved hjelp av direktelenker til filen, eller ved å finne lagringsstedet, er det gjort to hovedtiltak. Det første tiltaket er at ingen filer blir servert ved direktelenke til filen, men heller via egne Viewer-funksjoner som følger systemets øvrige autoriseringskrav. En mer detaljert beskrivelse av de ulike Viewer-funksjonene kan du lese mer om i appendiks B for Laravel, avsnitt Det andre tiltaket gjort i denne sammenhengen er at alle kundespesifikke dokumenter er lagt utenfor serverens webområde, slik at selvom om man vet den fysiske lokasjonen til en fil på servern, vil den aldri kunne serveres over nettleseren Passordblokkering Innloggingssiden er det eneste punktet systemet har ut mot internett og almennheten, derfor var det også viktig at det her ble satt noen begrensninger. I webapplikasjonen gikk vi for et tiltak som blokkerer innlogging ved et gitt antall feilinnlogginger. Antall forsøk og antall minutter med timeout kan enkelt settes i et av bibliotekene Regex En del av sikkerheten i applikasjonen ble også tatt hånd om ved at alle interaksjoner med brukerinput sjekkes mot en serverside-validering, primært ved hjelp av regulære utrykk. 109

110 3.7.5 Backup Løsningen er også laget med tanke på å sikre data. Foruten å kjøre på servermiljøer som tilbyr backupløsninger av hele oppsettet, er det også lagt opp til at en bruker kan laste ned de sentrale dokumentene, nemlig kontraktene manuelt. Man kan laste ned en backup av alle kontraktene i hele systemet i form av en komprimert zip-fil, eller enkeltvis alle kontraktene på én kunde. 3.8 Systemkrav Klientside Klientsiden er webbasert og krever en nettleser med støtte for JavaScript. Applikasjonen følger et responsivt designprinsipp, og skalerer til ulike skjermstørrelser og enheter. Hele applikasjonen lever i skyen og krever en kontinuerlig internettforbindelse. For best mulig brukeopplevelse anbefales det alltid å bruke nyeste versjon av en av de største nettleserne. Anbefalte nettlesere (per ): Mozilla Firefox 20 eller høyere Google Chrome 30 eller høyere Opera 15 eller høyere Safari 5 eller høyere Serverside Serversiden bygger på PHP-rammeverket Laravel versjon 4.1. Applikasjonen krever PHP-versjon høyere enn eller lik versjon og MCrypt PHP Extension, samt en vilkårlig webserver. Anbefalt er Apache 2.2 eller nyere. En MySQL-database, versjon 5.5 eller nyere et godt alternativ. Applikasjonen tar også i bruk en tredjeparts-programvare PDFtk 1.44 (for UNIX). Det kreves også, for full funksjonalitet, at servermiljøet er UNIX-basert. Servermiljøet må også ha tilstrekkelig med lagringskapasitet til å håndtere alle dokumentene som produseres av applikasjonen over tid. Applikasjonen produserer i snitt PDF-dokumenter på 250kB. Applikasjonen i seg selv tar 110

111 ikke mer en rundt 40MB. Det vil derfor være å anbefalle å ha systemet kjørende på miljøer som har fra 10GB og oppover med lagring, for å sikre tilstrekkelig lagring. 111

112 Denne siden er blank med hensikt.

113 Kapittel 4 Testdokumentasjon 4.1 Forord Testdokumentasjonen gir et overblikk over alle tester vi har gjort i tilknytning til eller på webapplikasjonen. I tillegg til planlagt enhetstesting av webapplikasjonen har vi funnet plass til en brukertest, og en mindre belastningstest av webapplikasjonen. Testdokumentasjonen tar sikte på å underbygge robustheten i webapplikasjonen ved teste både funksjonelle og ikke-funksjonelle krav, samt dokumentere tester og resultatene av testene. Contents 4.1 Forord Enhetstesting Formål med testen Utførte tester Gjenstående testing Utforming av testen Testing av modeller Testing av controllere Assertions Kjøring av enhetstest/enhetstester

114 4.2.9 Resultater og tiltak Brukertest Formål med testen Utforming av testen Resultater og tiltak Belastningstest Gjennomføring av testen Resultater av testen Konklusjon av testen

115 4.2 Enhetstesting Formål med testen Enhetstesting er en uvurderlig måte å teste webapplikasjonens funkjsonalitet på, og få ordnet på feil som man muligens ikke oppdager ved en normal test i nettleseren. På denne måten kan man fikse bugs/hull i koden før det blir utnyttet eller får weballikasjonen til å feile. Særlig med tanke på videreutvikling av webapplikasjonen (se avsnitt 2.8.4) har enhetstesting en meget høy nytteverdi for denne. Ved å vedlikeholde enhetstestene vil man ved en kort kommando (se avsnitt 4.2.8) kunne teste enten den modulen det er gjort endringer i for å teste spesifikt på den nye funksjonen, eller hele webapplikasjonen i ett for å se om nylig implementerte funksjoner har innvirkning på webapplikasjonen i sin helhet Utførte tester Vi la vekt på å teste alle modellene i webapplikasjonen i sin helthet ettersom vi har lagt de fleste databasespørringene i modellene. På denne måten får vi testet at all interaksjon med å hente ut data fra databasen går som forventet. I tillegg til dette har vi testet de to viktigste controllerne, UsersAction- Controller og CustomerController. I samspill med disse testene er også routes.php og filters.php blitt indirekte testet da disse filene henholdsvis styrer bruker til riktig sted i henhold til etterspurt side, samt ser at brukeren har tilgang til etterspurt side. Ved å sette testen til å simulere en normal kjøring som også tar med seg filters (se teknisk appendiks B) får vi i enhetstestingen testet om man kommer riktig sted i forhold til hvilken tilgang man har i webapplikasjonen. Dette muliggjøres ved linje 10 nedefor som aktiverer filters også i enhetstestingen. 115

116 Kodesnutter 4.1: TestCase.php for enhetstesting 0 <?php 1 2 c l a s s TestCase extends I l l u m i n a t e \ Foundation \ Testing \ TestCase { 3 4 p u b l i c f u n c t i o n setup ( ) { 5 parent : : setup ( ) ; 6 $ t h i s >preparefortests ( ) ; 7 } 8 p r i v a t e f u n c t i o n preparefortests ( ) { 9 Artisan : : c a l l ( migrate ) ; 10 Route : : e n a b l e F i l t e r s ( ) ; 11 } 12 p u b l i c f u n c t i o n c r e a t e A p p l i c a t i o n ( ) { 13 $ u n i t T e s t i n g = true ; 14 $testenvironment = t e s t i n g ; 15 return require DIR. /.. /.. / bootstrap / s t a r t. php ; 16 } 17 } Gjenstående testing På grunn av noe feilberegning av tid hadde vi satt av for kort til enhetstesting i forhold til det vi trengte for å enhetsteste hele webapplikasjonen. Det mest prekære som står for tur å teste er POST-metodene i både UsersActionController og CustomerController, ettersom disse gjør direkte endringer i databasen. Vi skulle gjerne sett at vi også hadde fått enhetstestet ferdig denne delen av webapplikasjonen. I tillegg står de andre controllerne (se teknisk appendiks B) utestet, men disse er ikke like vesentlge for webapplikasjonens funksjonalitet som de overnevnte POST-metodene Utforming av testen Generelt oppsett av testene Arrange setter opp alt av objekter og struktur som skal til for å utføre testen som skal kjøres. Her kan det også settes opp forventet (expected) resultat av testen som kan gjenbrukes i assert. 116

117 Act kaller på funksjonen, eller funksjonene, som skal testes på objektet som ble opprettet i arrange. Assert tester om handlingen utført i act har hatt ønsket effekt i henhold til hva som skal skje. Det er i dette punktet man eventuelt vil få feilmelding ved kjøring av testen om det er avvik fra ønskelig resultat. PHPUnit PHPUnit er et rammeverk for enhetstesting i PHP utviklet av Sebastian Bergmann 28. I rammerverket vi har benyttet, Laravel, er PHPUnit bygget inn slik at denne enhetstestingsplattformen kunne brukes out of the box 29. Enhetstesting i Laravel Ettersom enhetstesting er bygget inn i rammeverket har vi lagt inn tester i undermappen tests, hvor overnevnte fil TestCase.php ligger direkte i mappen mens tester på modeller og controllere er lagt i hver sin undermappe med tilhørende navn. Figur 4.1: Menystruktur for enhetstesting Ved å legge testene under app/test/.. og extende TestCase.php vist i figur 4.1 vil disse klassene kjøres når man kjører enhetstesten (se punkt 4.3.8). Videre må man ha alle testmetoder public med test som prefix på metodenavnet for at de skal kjøres. 28 GitHub-Repository for PHPUnit: phpunit/ 29 Dokumentasjonsside for Laravel Unit Testing: 117

118 Kodesnutter 4.2: CustomerControllerTest.php under app/test/controllers/ 0 <?php 1 2 use Zizaco \ FactoryMuff \Facade\ FactoryMuff ; 3 4 c l a s s CustomerControllerTest extends TestCase { 5 / 6 Metoder g e n e r e l t f o r a l l e h a n d l i n g e r. 7 B l i r av implementasjonen b e h a n d l e t i f i l t e r s. php 8 / 9 10 // B l i r sendt en r e q u e s t med u g y l i d i g handling 11 p u b l i c f u n c t i o n t e s t a c t i o n g e t i n v a l i d a c t i o n ( ) { } Database i enhetstesting Som vist i figur 4.1, linje 14, settes variabelen testenviroment til testing, dette spesifiserer hvor konfigurasjonsfilene som skal benyttes under testing skal ligge, og havner da under app/config/testing/. Her ligger blant annet en egen databasekonfigurasjonsfil 30. Dette gjør at man kjører testene helt uavhengig av webapplikasjonens vanlige databasekonfigurasjon og database. Istedenfor benyttes en In-Memory -database som gjør at testene kan foretas mye raskere enn ved å gjøre spørringer mot en vanlig database, og uavhengig av hverandre. 30 Guide for enhetstesting i Laravel for testing-like-a-boss-in-laravel-models--net

119 Kodesnutter 4.3: Komplett fil database.php under app/config/testing/ 0 <?php 1 2 return array ( 3 4 d e f a u l t => s q l i t e, 5 6 c o n n e c t i o n s => array ( 7 s q l i t e => array ( 8 d r i v e r => s q l i t e, 9 database => : memory :, 10 p r e f i x => 11 ), 12 ) 13 ) ; Mockery og FactoryMuff Mockery hjelper til å forenkle enhetstester, særlig når modellrelasjone 31 skal testes. Om man skal opprette en instans av modell A som har en kobling mot en instans av både modell B og C må begge de sistnevnte opprettes før modell A kan initialiseres. Ved å benytte mocking i enhetstesten vil man dratisk forenkle testene ved at slike avhengigheter vil bli satt opp av mockingen. Det vil ved å mocke en instans av modell A bli simulert både en instans av modell B og C som oppfører seg på samme måte som en vanlig initalisert modell. Kort sagt kan man si at mockery simulerer oppførselen til ekte objekter. FactoryMuff 32 er en implementasjon av mockery til PHP som både setter datafelter og relasjoner automatisk. Med FactoryMuff definerer man en liste (array) i modellen ved navn $factory som FactoryMuff benytter når en modell FactoryMuffes. 31 Unit Testing for Software Craftsmanship mocking/unit-testing.aspx 32 GitHub-Reposityory til FactoryMuff 119

120 Kodesnutter 4.4: FactoryMuff-array for modellen User 0 p u b l i c s t a t i c $ f a c t o r y = array ( 1 u s e r r o l e i d => f a c t o r y U s e r r o l e, 2 => , 3 f i r s t n a m e => s t r i n g, 4 lastname => s t r i n g, 5 telephone => s t r i n g, 6 b i r t h d a t e => , 7 department => s t r i n g, 8 password => s t r i n g, 9 e r r o r l o g i n s => 0 10 ) ; Syntaksen factory Modell benyttes på fremmednøkler som knytter modellen til andre modeller. Ved å bruke denne syntaxen vil FactoryMuff automatisk opprette alle modellene den relaterer til. string, og text vil generere automatisk genererte variabler tilsvarende sin type Testing av modeller Ved testing av modellene har vi testet alle metodene i hver enkelt modell, også relasjonsmodellen som er definert for databasen (se appendiks B). På denne måten vet vi at all bruk av modeller i webapplikasjonen er gjennomtestet. Eksempel på modelltest Kodesnutter 4.5: Tester metoden getname i Usermodellen 0 p u b l i c function test memberfunction getname ( ) { 1 $ f i r s t n a m e = Test ; 2 $lastname = Testesen ; 3 $user = FactoryMuff : : c r e a t e ( User, array ( 4 firstname =>$firstname, 5 lastname =>$lastname ) ) ; 6 7 $expected = $ f i r s t n a m e.. $lastname ; 8 $ t h i s >a s s e r t E q u a l s ( $expected, $user >getname ( ) ) ; 9 } 120

121 Sammenligne objekter For å sammenligne objekter mot hverandre i enhetstestene og for å være sikker på at det er korrekt objekt som returneres testes ikke bare ID, men alle parametre i objektene mot hverandre og returnerer false så fort det er avvik mellom de to objektene. Kodesnutter 4.6: Sammenligingsmetode for User i UserTest 0 p u b l i c s t a t i c f u n c t i o n compare objects ( $user1, $user2 ){ 1 i f ( $user1 >id!= $user2 >id ) return f a l s e ; 2 i f ( $user1 >u s e r r o l e i d!= $user2 >u s e r r o l e i d ) return f a l s e ; 3 i f ( $user1 > != $user2 > ) return f a l s e ; 4 i f ( $user1 >f i r s t n a m e!= $user2 >f i r s t n a m e ) return f a l s e ; 5 i f ( $user1 >lastname!= $user2 >lastname ) return f a l s e ; 6 i f ( $user1 >image!= $user2 >image ) return f a l s e ; 7 i f ( $user1 >telephone!= $user2 >telephone ) return f a l s e ; 8 i f ( $user1 >b i r t h d a t e!= $user2 >b i r t h d a t e ) return f a l s e ; 9 i f ( $user1 >department!= $user2 >department ) return f a l s e ; 10 i f ( $user1 >password!= $user2 >password ) return f a l s e ; 11 i f ( $user1 >e r r o r l o g i n s!= $user2 >e r r o r l o g i n s ) return f a l s e ; 12 i f ( $user1 >u s e r b l o c k e d!= $user2 >u s e r b l o c k e d ) return f a l s e ; 13 i f ( $user1 >c r e a t e d a t!= $user2 >c r e a t e d a t ) return f a l s e ; 14 i f ( $user1 >updated at!= $user2 >updated at ) return f a l s e ; 15 i f ( $user1 >d e l e t e d a t!= $user2 >d e l e t e d a t ) return f a l s e ; 16 return true ; 17 } Testing av controllere Ved testing av controllerne testes det at man kommer til riktig side med riktig tilbakemelding i henhold til de parametre som er satt. For å imitere en request på en side kjøres en crawler som gjør at man videre kan teste ut i fra requesten som ble sendt. Ut i fra dette kan man teste om man er omdirigert til en annen side, eller om man kommer frem til ønsket side. 121

122 Eksempel på controllertest Kodesnutter 4.7: Tester metode som behandler ugyldige handlinger sendt inn til UsersActionController 0 p u b l i c function t e s t a c t i o n g e t i n v a l i d a c t i o n ( ) { 1 $user = FactoryMuff : : c r e a t e ( User ) ; 2 $ t h i s >be ( $user ) ; 3 $ a c t i o n = i n v a l i d a c t i o n ; 4 $ c r a w l e r = $ t h i s >c l i e n t >r e q u e s t ( GET, 5 URLS : : useractionlink ( $ a c t i o n ) ) ; 6 $ t h i s >a s s e r t S e s s i o n H a s ( message, 7 Lang : : get ( feedback. n o t v a l i d a c t i o n, 8 array ( action =>$action ) ) ) ; 9 $ t h i s >a s s e r tredirectedto (URL : : p r e v i o u s ( ) ) ; 10 } Assertions Benyttet i modeller Kodesnutter 4.8: Assertions benyttet i modeller 1 $ t h i s >a s serttrue (... ) ; 2 $ t h i s >a s s e r t F a l s e (... ) ; 3 $ t h i s >a s s e r t E q u a l s ( $a, $b ) ; 1. Tester om uttrykket som parameter er sant. Om parameteren er sann går testen gjennom, ellers feiler testen. Det er denne asserten som benyttes når modellenes sammenligningsmetoder compare object (se kodesnutt 4.6) skal testes ettersom de returnerer henholdsvis true eller false. 2. Tilsvarende assertion, men med motsatt utfall. 3. Tester objekt/variabel $a mot objekt $b for å undersøke om de er like. 122

123 Benyttet i controllere Kodesnutter 4.9: Assertions benyttet i controllere 1 $ crawler = $ t h i s >c l i e n t >r e q u e s t ( GET, $ l i n k ) ) ; 2 $ t h i s >a s s e r t S e s s i o n H a s ( message, message content ) ) ; 3 $ t h i s >a s s e r t R e d i r e c t e d T o ( l i n k ) ; 4 $ t h i s >assertresponseok ( ) ; 1. Crawler som er tilsvarende en request på en side. Første parameter sier hva slags HTML-verb requesten skal sendes med, andre parameter lenken til requesten. Det har som tidligere nevnt kun vært tid til å teste GET-siden av controllerne fullt ut, men det er i UsersActionController vist hvordan dette fungerer med POST-test, for metoden som leger til ansatt (adduser). 2. Tester om det en session-variabel som er satt og som heter tilsvarende første parameter, og inneholder andre paramenter. 3. Tester om utfallet av requesten fører til en omdirigering til lenken som er sendt med som parameter. Som oftest i våre tester benyttes dette med URL::previous() (omdirigering til forrige side). 4. Tester om requesten har endt opp på siden den skulle i henhold til andre paramenter sendt med ved opprettelse av crawleren Kjøring av enhetstest/enhetstester Enhetstetene i webapplikasjonen kan kjøres når man står i mappen Laravel ved å skrive kommandoene nedenfor. Det finnes to forskjellige måter å kjøre enhetstestene på, samt mulighet til å kjøre kun en enkelt test. Kodesnutter 4.10: Kjøre enhetstester 0 phpunit 1 phpunit f i l t e r =UserTest 2 3 php phpunit. phar 4 php phpunit. phar f i l t e r =UserTest Vær obs på at å kjøre alle enhetstestene vil bruke mer minne enn hva PHP er satt opp til ved en standard installering, så dette må økes i php.ini for å få kjørt alle testene i ett. 123

124 4.2.9 Resultater og tiltak Figur 4.2: Resultat av enhetstesting Det er i alt 253 tester med 462 assertions. Ved denne spesifikke kjøringen tok det 31 sekunder, og benyttet Mb minne. Dette er imidlertid avhengig av datamaskin og miljø testen kjøres på. Som konsekvens av testingen møtte vi på flere problemer/feil som vi fikk rettet opp i. Dette var særlig i forbindelse med testing av modeller tilhørende databasespørringer. Det viktigste vi fikk rettet opp i under enhetstestingen gjaldt definering av relasjoner mellom modellene med tanke på den underliggende databasen. Ettersom vi hadde satt som kotyme at vi la inn alle relasjoner i modellene selv om de ikke ble benyttet direkte, var det flere metoder vi måtte gjøre rettinger på slik at disse kan benyttes i videreutvikling av webapplikasjonen. Videre har vi endret mer spesifikke spørringer opp mot databasen for å sikre at spørringen kun returnerer etterspurt innhold. Dette var blant annet sentralt ved opphenting av kalenderoppføringer i henhold til ønsket resultat. 124

125 4.3 Brukertest Formål med testen Brukertesten baserte seg på prototypen som ble laget av applikasjonen. Vi ønsket å gjennomføre en blackbox-test, hvor de ansatte hos oppdragsgiveren skulle gjennomføre noen oppgaver relatert til prototypen. En blackboxtest fungerte utmerket i dette tilfellet, da oppdragsgiver ikke kommer fra et teknisk miljø og kun er interessert i resultatet applikasjonen gir, ikke nødvendigvis hvordan det gis. Denne prototypen hadde som primærhensikt å få et sluttbruker-perspektiv på hvor håndterlig systemet var. Vi ville avdekke om sluttbruker var inneforstått med navigeringen og om den kunne operere de sentrale funksjonene på en lettfattet måte. Vi ville også avdekke feil eller mangler som ikke tidligere hadde kommet tydelig nok frem i kravspesifikasjonen, eller ved de møter vi har hatt. I tillegg ble avklaringer på forumuleringer et fokus. Vi ville også bruke resultatene av denne testen til å fremme de sentrale operasjonene en sluttbruker vil bruke mesteparten av tiden på og til å strømlinjeforme design og navigering basert på resultatene Utforming av testen Under utformingen av brukertesten ble det satt fokus på at oppgavene skulle ha varierende (tiltenkt) tidsbruk og vanskelighetsgrad samt at oppgavene skulle ha forskjellige typer ordlyd. Dette ble gjort for å skape en situasjon mer enn en oppgave, og dermed kunne resultatet bli noe helt uforventet, som i de fleste tilfeller er en god ting. Ved å benytte oss av spørsmål som liknet hverdagslige arbeidsoppgaver for oppdragsgiver styrte vi brukeren vekk fra å gjøre nøyaktig det spørsmålet bad om, og lot det bli mer opp til egen tolkning. Dette gjorde vi ved å unngå konkrete deloppgaver i et spørsmål og heller utforme spørsmålet med gjør følgende endringer eller utfør nødvendige operasjoner etter en situasjon er forklart i oppgaveteksten. Testen ble utformet med en spørsmålstekst, en gradering på vanskelighetsgrad, en tekstboks til notater og en tekstboks for forslag til endring. Graderingen var på fem nivåer, hvorav disse var Umulig, Vanskelig, Helt greit, Ganske lett og Lett. Det nederste nivået Umulig ble byttet ut fra Veldig vanskelig da vi med nevnte nivå utelukket det tilfellet hvor brukeren ikke hadde fått gjennomført oppgaven i det hele tatt. Vi 125

126 fikk også mye gode forslag til forbedring (fra brukernes synspunkt) ved å ha tekstboksen for forslag til forbedring. Vi valgte også å gi brukerne testen i papirform istedet for digitalt, da penn og papir ofte kan trigge en annen respons som f.eks. figurer, tegninger og liknende. Ved å gjøre dette forsterket vi også impulsiviteten til brukeren og vi fikk dermed mer direkte og klar tilbakemelding i motsetning til å få noe som var tenkt over og pyntet på. Testen ble presentert kort til brukerne under et møte, der vi forklarte litt hvordan vi ville at den skulle gjennomføres, samt når vi ville ha den tilbake med svar Resultater og tiltak Etter å ha gjennomført testen hadde vi et møte med oppdragsgiver hvor vi sammen gikk gjennom testen, og hørte på tilbakemeldinger de hadde rundt prototypen. Dette var første virkelige kjørbare utgave av systemet, som hele bedriften fikk prøve seg på og det var stor entusiasme på tilbakemeldingene. De fleste oppgavene knyttet til brukertesten lot seg gjennomføre med enkelhet, men det kom likevel en god del konkrete tiltak som kunne gjennomføres for å forbedre helheten. Testen ga oss også noen pekepinner på hvor i systemet det var punkter som trengte større fokus. Ut i fra dette møtet og de tilbakemeldingene som ble gitt i oppgavebesvarelsen kom vi frem til følgende tiltakslister: Konkrete forslag til forbedringer: VPS-nummer skal være 12 siffer, regex er på 11. Kurs-feltet på kontrakter må tillate desimaltall Aksje-feltet på kontrakter må tillate tekst, tegn og tall Opprettelse av kunder må ha valgfritt personnummer Mangler poststed i registrering av adresser Kalender: Sluttdato-feltet bør settes til samme dato som startdato når startdato er valgt. Kunne huke av for at det er en bedrift, og få ekstra felter (for eksempel organisasjonsnummer). Bedrift må kunne ha en kontaktperson. Registrere i loggen når det lastes opp kundefiler, med link til filen. Beskrivelsesfelt på kundefiler Åpne filer i ny fane 126

127 Mulighet for å slette filer Kan ikke bruke tegnsetting i logg notater Uklare momenter: Dårlig formulering av roller for opprettelse av ansatt - hva innebærer de ulike rollene? Usikkerhet på om man kan lage kontrakter når det ikke er noen vedlegg tilgjengelige Usikkerhet rundt bedrift og hvilke felter som brukes til dette Litt uklarhet i hvilke menyvalg som fører hvor Vaghet i hvor man kan trykke i søkeresultatene for å komme inn på funnet kunde Ut i fra tilbakemeldingene konkretisert ned til disse listene ble det lagt til oppgaver på Scrumbrettet for å forbedre disse konkrete tiltakene. Disse punktene var i all hovedsak enkle å rette på, da fokuset la en del begrensinger gitt av validering på bruker-input, og mer konkretisert ordlyd. Utover de konkrete tiltakene ga denne testen oss en klar forståelse av hvilken arbeidsflyt oppdragsgiver ville ha i webapplikasjonen. Vi gjorde derfor en større designendring i menystrukturen. I prototypen var alle menyvalgene likt vektet men basert på den bruken vi så oppdragsgiver hadde i webapplikasjonen, samt deres uttrykk om at det ikke alltid var full klarhet i hvor man skulle trykke, valgte vi å øke størrelsen på de sentrale funksjonene og heller flytte de mindre brukte funksjonene mer mot høyre i menyen. 127

128 Figur 4.3: Meny fra prototype 1 Figur 4.4: Meny fra prototype sluttprodukt Som vist i 4.3 og 4.4 har brukervennligheten økt betraktelig som følge av denne designendringen. I menyen fra sluttproduktet faller øynene fortere på det valget man i de fleste tilfeller skal benytte seg av. Andre resultater denne brukertesten ga oss gjorde det at det nå ligger en knapp direkte til kalenderfunksjonaliteten på toppen av siden hele tiden. Dette var etter ønske i brukertesten, da denne tidligere lå noe skjult inne i brukermenyen. 128

129 4.4 Belastningstest Gjennomføring av testen Ved å utføre en belastningstest på webapplikasjonen kan vi simulere et fremtidig stadie av den og se hvordan den vil oppføre seg i hverdagen. Ved å mocke (les mer i avsnittet om enhetstesting) sjekker vi forskjellen i nedlastningstid/responstid ved å vise alle av de undernevnte elementene i applikasjonen kunder mot 2 kunder 2004 ansatte mot 4 ansatte 2000 aktiviteter mot 0 aktiviteter Kontrakter og skjemaer er ikke mulig å mocke reelt, da disse inneholder eksterne filer og ikke vil gi oss et sant bilde i belastningstesten. Som et generelt krav har vi satt at visning av alle elementer ved lite antall ikke skal være mer enn 5 sekunder, og ved stort antall ikke skal være mer enn 10 sekunder. Testen kjøres med følgende konfigurasjoner: HiOA webserver (1GB RAM, Ubuntu 12.04) Macintosh OS X versjon operativsystem Mozilla Firefox nettleser Firefox webutviklerverktøy sitt network-verktøy til tidsmåling Gjennomsnittlig nedlastningsfart på 68,88 Mbps (målt 12. mai 2014) Det vil kjøres fem tester for hvert av elementene, for hvert av antallene, dvs. at det kjøres 5 * 3 * 2 = 30 tester. Merk! Nettleseren i denne testen cacher stilark, bilder og scripts som hentes til nettstedet. For en helt ny bruker som åpner applikasjonen første gang kan disse resultatene være høyere enn hva som fremkommer av testen. Alle testene er utført med caching, så forholdet mellom disse er reelle. 129

130 4.4.2 Resultater av testen Test nummer Snitt Faktor Kunder 1,52s 1,53s 1,41s 1,53s 1,48s 1,49s Lite antall Ansatte 1,48s 1,53s 1,54s 1,65s 1,48s 1,54s Aktiviteter 1,36s 1,89s 2,07s 1,99s 2,09s 1,88s Kunder 3,43s 3,78s 3,46s 3,35s 3,39s 3,48s 2,33 Stort antall Ansatte 5,27s 6,68s 5,11s 5,01s 5,21s 5,46s 3,55 Aktiviteter 9,96s 10,01s 10,04s 10,04s 9,78s 9,97s 5, Konklusjon av testen Ut fra responstidene får vi nyttig informasjon om hvordan en faktisk brukersituasjon kan utspille seg. Også ved et, noe usannsynlig høyt antall ansatte og aktiviteter, er responstiden akseptabel i forhold til kravene vi har satt. Vi ser imidlertid at visning av aktiviteter er det som tar desidert lengst tid, og går noen ganger over kravet. Dette ser vi ikke på som et brudd på kravet, i og med at overskridningen er såpass liten. Ut fra faktorene ser vi at økningen av den gjennomsnittlige visningstiden økte mest ved økning av antallet aktiviteter. Med disse resultatene kan vi konkludere med at henting og visning av aktiviteter bør forbedres i fremtiden, men at den generelle responstiden er akseptabel i forhold til kravene vi har satt. 130

131 Kapittel 5 Brukerveiledning 5.1 Forord Dette dokumentet skal fungere som en brukerveiledning for sluttbruker og som en hjelp til å bruke systemet på tilegnet måte, og for oppklaring rundt hvordan webapplikasjonen fungerer front-end. Dette dokumentet kan enten leses som et frittstående dokument eller sammen med resten av rapporten. Contents 5.1 Forord Terminologi Innledning Veiledning Innlogging, utlogging og glemt passord Søk Kunde Ansatt Kontrakt Skjema Kalender For deg som bruker

132 5.5 Feil- og rettingsmuligheter

133 5.2 Terminologi Meso Meso Capital Markets Systemet webapplikasjonen Kunde privat- eller bedriftskunde av Meso Bruker bruker av systemet, med andre ord en ansatt i bedriften Aktivitet generell betegnelse for møte, opplæring, telefonmøte, oppfølging og lignende Kontrakt salgs- eller kjøpskontrakt for andeler i et fond Webbasert aksesseres og krever en nettleser som f.eks Internet Explorer, Firefox, Opera og lignende Applikasjon Program, system og lignende Kundetype privat- eller bedriftskunde Kundestatus status en kunde har, dette kan være ikke kontraktet, potensiell og lignende Avdeling hvor en ansatt hører til, for eksempel salg, resepsjon, regnskap og lignende Avatar også kalt profilbilde Rolle rolle som plasserer en ansatt i systemet, og styrer tilgangskontrollen Vedlegg bilder, dokumenter og andre vedlegg til en kontrakt Kontraktstype kjøps- eller salgskontrakt Kurs hvilken kurs et antall aksjer skal kjøpes og/eller selges med Kurtasje inntjening, profit, provisjon og lignende Tredjepart Parten som verken er Meso eller kunden Skjema et type vedlegg som kan legges ved i kontrakter 133

134 (Type)-visning detaljer om en enkelt type (Type)-oversikt oversikt over alle elementer av gitt type 5.3 Innledning Denne webapplikasjonen har som hovedoppgave å være en intern, webbasert back-end-løsning for lagring, oppdatering og visning av kunder, ansatte, aktiviteter, samt kontrakter. Webapplikasjonen har følgende, overordnet funksjonalitet: Opprette kunde Endre kunde Opprette ansatt Endre og slette ansatt Tilegne rettigheter på en ansatt Opprette aktivitet Opprette kontrakt tilknyttet aktivitet Ettersom applikasjonen er webbasert kan man aksessere den gjennom en hvilken som helst nettleser. Dette være seg nettbrett, smarttelefon, bærbar eller stasjonær datamaskin. Ved bruk av fingre, touch-penn eller mus og tastatur kan man benytte seg av webapplikasjonen på tiltenkt og tilstrekkelig måte. Applikasjonen har som oppgave å gi tilstrekkelig tilbakemelding på alle handlinger brukeren gjør. Ved opprettelse og endring gir applikasjonen tilbakemelding på om handlingen var vellykket eller mislykket. Dette signaliseres med en rød tekstboks (mislykket) eller en grønn tekstboks (vellykket) øverst på skjermen. I tilfeller hvor en operasjonen verken gir mislykket eller vellykket tilbakemelding gir systemet en blå tekstboks med en generell tilbakemelding. Merk at du ikke nødvendigvis har tilgang på alle handlingene som blir beskrevet i brukerveiledningen da dette kommer an på 134

135 hva slags tilganger du har. Hvilke tilganger du har kan du se på Din profil, under valget Tilganger. 5.4 Veiledning Innlogging, utlogging og glemt passord Logge inn Når du først skriver inn adressen til webapplikasjonen blir man møtt med en innloggingsskjerm. Her skriver du inn e-postadresse og passord i sine respektive felter. Etter disse er fylt ut klikker du på knappen Logg inn eller trykker enter-tasten på tastaturet. Om innloggingen feiler vil du få en tilbakemelding på dette, og du vil få mulighet til å skrive inn informasjonen på nytt. Ved vellykket innlogging kommer du til Oppslagstavlen med en melding om vellykket innlogging. Figur 5.1: Innloggingsskjermen Merk at du etter 5 mislykkede forsøk på innlogging blir blokkert fra innlogging i 5 minutter. Logge ut Gitt at du er logget inn klikker du på ditt navn oppe i høyre hjørne på nettsiden og velger Logg ut. Ved vellykket utlogging kommer du til innloggingsskjermen med tilhørende tilbakemelding. 135

136 Glemt passord Figur 5.2: Logg-ut-knapp Hvis du har glemt innloggingspassordet kan du på innloggingsskjermen klikke på Glemt passord for å få et nytt passord. Skriv så inn din e-postadresse og trykk på knappen Send meg nytt passord. Gå så inn på den tilhørende mailkontoen og klikk på linken i e-posten. Du vil da komme til en ny side hvor du kan skrive inn nytt passord. Bekreft ved å skrive passordet på nytt og klikk på knappen Endre passord. Ved vellykket passordendring vil du bli sendt til innloggingsskjermen med tilhørende tilbakemelding. Ved mislykket passordendring vil du få muligheten til å skrive inn det nye ønskede passordet på nytt med tilhørende feilmelding på hva som gikk galt Søk Applikasjonen har tre søk: Hurtigsøk Fullstendig søk Kundesøk Til enhver tid er det et søkefelt øverst i høyre hjørne. Ved å klikke i dette feltet og skrive inn søkeordet vil systemet søke etter kunder etter kriteriene som skrives inn. Her kan du søke etter navn, telefonnummer, e-post eller 136

137 (a) Glemt passordskjerm sendt (b) Nytt passord er nå (c) Endre passordskjerm Figur 5.3: Skjermbilder for glemt passord adresse. Resultatene vil oppdateres etterhvert som du endrer søkekriteret, ved å skrive mer eller fjerne tegn i søkeordet.for å få resultater må du skrive minst 3 tegn.bedrifter vil ha et ikon av en bygning, og privatpersoner har et ikon av en person. Figur 5.4: Eksempel på hurtigsøk For å gå til fullstendig søk kan man bruke entertasten på tastaturet. Du vil da komme til et nytt vindu med resultatene til ditt søkekritere. For å endre søkekriteret skriver du inn nytt kritere i søkeboksen og bruker entertasten på tastaturet. Resultatene vil da oppdateres etter nytt søkekritere. Ved opprettelse av aktivitet finnes det et søkefelt under Kunde. Dette søket fungerer på samme måte som hurtigsøket, og resultatene vil oppdateres 137

138 Figur 5.5: Eksempel på et fullstendig søk ettersom du legger til eller fjerner tegn i søkekriteriet. For å velge kunde klikker du på avhukingsboksen til venstre for den kunden du vil koble til aktiviteten. Figur 5.6: Kundesøk Kunde Opprette kunde For å opprette en kunde klikker du på Meny oppe i venstre hjørne, og klikker videre på valget Ny kunde. Ved å klikke på kundetype vil du få felter spesefikke til den valgte kundetypen. 138

139 Figur 5.7: Menyvalget Ny kunde (a) Felter til privatkunde (b) Felter til bedriftskunde Figur 5.8: Felter ved kundeopprettelse Privat Velg kundestatus fra nedtrekkslisten og fyll så inn fornavn, etternavn, personnummer, e-postadresse, telefonnummer, adresse, postnummer og poststed og klikk så Legg til kunde -knappen for å opprette kunden. Bedrift Velg kundestatus fra nedtrekkslisten og fyll så inn bedriftsnavn, kontaktpersons fornavn, kontaktpersons etternavn, organisasjonsnummer, e-postadresse, telefonnummer, adresse, postnummer og poststed og klikk så på Legg til kunde -knappen for å opprette kunden. 139

140 Ved vellykket opprettelse av kunden vil du komme til kundevisningen med en tilbakemelding om vellykket opprettelse av kunden. Ved mislykket opprettelse av kunden vil du komme tilbake til samme side med tilbakemelding om hva som gikk galt, for å få muligheten til å skrive inn info på nytt og/eller rette opp i feilene spesifisert i tilbakemeldingen. Endre kunde For å endre en kunde klikker du på Meny oppe i venstre hjørne. Klikk så på Kunder under Se alle til høyre i menyen. Finn frem den kunden du vil endre informasjonen på og klikk på Vis. Klikk så på teksten Endre kundeinformasjon og endre ønsket informasjon. Etter ønsket endring er gjort klikker du på Lagre kunde -knappen for å fullføre endringen. Ved vellykket endring(er) vil du få en tilbakemelding på toppen av siden med beskjed om vellykket endring(er). Ved mislykket endring(er) av informasjonen vil du bli på den samme siden med en tilhørende feilmelding. Figur 5.9: Endre-kunde-skjerm Vis kunde For å vise en kundes informasjon klikker du på Meny oppe i venstre hjørne. Klikk så på Kunder under Se alle til høyre i menyen. Finn frem den kunden du vil se på og klikk på Vis. Du vil da komme til kundevisningen. Her 140

141 vil du se informasjon om tilhørende aktiviteter og kontrakter til kunden sammen med spesefikk info for kunden. Figur 5.10: Kundevisning I kundevisningen finnes det også en toppmeny med følgende valg: Oversikt Her finner du kontaktinformasjon og generell informasjon om kunden, samt informasjon om antall møter, hvorav møtte og ikke møtte, og kontrakter, hvorav kjøp og salg. Klikk på knappen Vis fullstendig kundeinformasjon for å se alle detaljer. Klikk på teksten Endre kundeinformasjon for å endre kundens informasjon. Kontrakter Her finner du en oversikt over alle kundens kontrakter. Ved å klikke på knappen Last ned kontraktbackup lastes kundens kontrakter ned som en ZIP-fil. Logg Her kan du legge til en logg på kunden. Man kan legge til en logg i følgende kategorier; Telefon Inn, Telefon Ut, Mail Inn, Mail Ut, Møte Inne, Møte Ute og Notis. Ved å klikke på teksten Vis automatiske logger ser man alle automatiske logger som gjelder kunden. 141

142 Rådgivere Her ser man hvilken, eventuelt flere, rådgivere kunden har. Ved å klikke på Legg til rådgiver og Fjern rådgiver kan man legge til og fjerne rådgivere. Filer Her har man en oversikt over kundens filer. Dette er filer som gjelder den enkelte kunden og kan legges ved på en kontrakt. Dette kan være for eksempel kundebilde eller andre kundespesefikke dokumenter. Ved å klikke på teksten Legg til kundefil kan man legge til en ny fil tilknyttet kunden. I opprettelsen av filen kan man velge om filen er legitimasjon eller om filen må signeres. Kontoer Her finner du en oversikt over kundens bankkontonummer og eventuelt VPS-kontonummer. Ved å klikke på teksten Legg til konto kan du legge til en ny konto på kunden. Aktiviteter Her finner du en oversikt over kundens kommende og tidligere aktiviteter. Ved å klikke på knappen Opprett ny aktivitet med kunde kommer man rett til aktivitetsopprettelse hvor kunden er forhåndsvalgt. Ikon: kalender med pluss Denne knappen sender deg videre til aktivitetsopprettelsen hvor kunden er forhåndsvalgt. Høyre: kundenavn Ved å klikke på dette kommer du til kundeoversikten tilsvarende valget Oversikt Ansatt Opprette ansatt For å opprette en ny ansatt klikker du på Meny oppe i venstre hjørne. Klikk så på Ny ansatt til høyre i menyen. Velg den ansattes rolle, og fyll så ut fornavn, etternavn, e-postadresse, telefonnummer, avdeling, fødselsdato, ønsket passord og bekreft passordet trykk så på Legg til ansatt -knappen for å fullføre opprettelsen. Endre ansatt For å endre en ansattes informasjon klikker du på Meny oppe i venstre hjørne. Klikk så på Ansatte under Se alle til høyre i menyen. Finn frem den ansatte du vil endre informasjonen til og klikk på Vis. Du vil 142

143 Figur 5.11: Menyvalg for opprett ansatt da komme til visningen av den ansatte. Under informasjonen har du flere endre-valg. Figur 5.12: Endre ansatt-skjerm Endre ansatt Her kan du endre fornavn, etternavn, telefonnummer, e-postadresse, fødselsdato, avdeling og avatar. Klikk så på Endre - knappen for å fullføre endringen. Endre passord Her kan du endre passordet til den ansatte. Skriv inn nytt passord og bekreft passordet. Klikk så på Endre -knappen for å fullføre passordendringen. Endre rolle Her kan du endre den ansattes rolle. Velg den nye rollen fra nedtrekkslisten og klikk så på Endre -knappen for å fullføre rolleendringen. 143

144 Vis ansatt For å vise en ansattes informasjon klikker du på Meny oppe i venstre hjørne. Klikk så på Ansatt under Se alle til høyre i menyen. Finn frem den ansatte du vil se informasjonen til og klikk på Vis. Du vil da komme til visningen av den ansatte. Figur 5.13: Ansattvisning Slette ansatt For å slette en ansatt klikker du på Meny oppe i venstre hjørne. Klikk så på Ansatte under Se alle til høyre i menyen. Finn frem den ansatte du ønsker å slette og klikk på Vis. Du vil da komme til visningen av den ansatte. Velg nederste valg, Slett ansatt, trykk så på Slett ansatt - knappen for å gjennomføre slettingen. Denne handlingen kan ikke reverseres! Kontrakt Opprette kontrakt For å opprette en ny kontrakt må man først opprette en aktivitet med en kunde. Dette er gjort for at knytningen mellom en kunde, en aktivitet 144

145 Figur 5.14: Sletting av ansatt og en kontrakt skal fungere som tiltenkt. Opprett først en kunde, opprett så en aktivitet knyttet til den opprettede kunden (eventuelt på en eksisterende kunde). Klikk så på Min kalender oppe i venstre hjørne for å komme til kalendervisningen. Finn frem aktiviteten du vil opprette en kontrakt til og klikk Vis (Eventuelt opprett ny aktivitet). Fra aktivitetsvisningen klikker du på knappen Opprett kontrakt tilknyttet aktivitet. Vennligst påse at kontrakten er knyttet mot riktig kunde og aktivitet. Under Velg skjemaer finner du en liste over alle mulige skjemaer som er satt opp i systemet. Ved å huke av Legg ved -boksen vil du legge ved skjemaet til kontrakten, og kan fylles ut i neste steg. Ved å huke av Kopier til kundefiler -boksen vil utfylt skjema bli overført til kundens egne filer for gjenbruk. Fyll så ut kontraktsnavn, kontraktstype, aksjenavn, antall aksjer, kurs, total kurtasje og tredjepartskurtasje. Du vil ettersom du endrer antall askjer og kurs få en oversikt over de forskjellige parters data i henhold til kjøpet eller salget. Etter at du har fylt ut informasjonen klikker du på Videre til utfylling - knappen for å gå videre til sjemautfylling. Fyll ut de skjemaspesefikke feltene og klikk så på Lagre -knappen. (Merk at første skjema som fylles ut alltid vil være kontraktskjemaet selv om dette ikke er valgt som skjema tidligere). Hvis du tidligere valgte ett eller flere skjemaer til kontrakten vil du også fylle ut disse i dette steget. Eventuelle predefinerte felter vil allerede være fylt ut, men du vil ha muligheten til å endre også på disse. Ved vellykket kontraktopprettelse og skjemautfylling vil du bli sendt til 145

146 kontraktvisning med tilhørende tilbakemelding. Ved mislykket kontraktopprettelse eller skjemautfylling vil du bli værende på siden med feil og du vil få mulighet til å rette opp i disse. Kontrakten er nå opprettet, og er klar til signéring. Se mer under Endre/behandle kontrakt for mer info om disse statusene. Signere via tredjepart For å legge en fysisk signatur på en ferdig utfylt kontrakt må du gå gjennom en tredjepartsprogramvare. Et godt alternativ til et slikt program er Adobe Reader 33. Veiledningen bruker denne programvaren i skjermbilder hentet fra en Mac. Vær obs på at tastevalg kan variere noe på PC, og eventuell norsk språkpakke. 1. Gå inn på kontrakten du skal signere og trykk på knappen Se kontraktdokument. 2. Last ned dokumentet til din datamaskin. 3. Åpne det nedlastede dokumentet i Adobe Reader. 4. Trykk på knappen Sign oppe i høyre hjørne. 5. Velg enten å plassere initialer eller signatur avhengig av hva kontrakten krever

147 Merk! Hvis du har plassert en signatur før må du velge å nullstille eller bytte denne da den forrige lagrede signaturen vil være standardvalg. 6. Huk av for den måten du vil ha signaturen på via tastaturskriving, håndskriving (eller tegneflate til datamaskin), fra et bilde eller et sertifikat. Velg Accept når du har gjort dette. 7. Plassér signaturen der den hører til. 8. Klikk på knappen Signed. Proceed to send. 9. Velg så Save a copy og lagre kontrakten et sted du kan lett finne den igjen på datamaskinen. 147

148 10. Gå tilbake til webapplikasjonen og klikk på teksten eller knappen Signér kontrakt, så Velg signert kontrakt. Velg filen du nettopp signerte og lagret og klikk så Last opp signert kontrakt -knappen. 11. Kontrakten er nå signert og status på kontrakten er signert. Dette indikeres med en låst hengelås og teksten Signert. Figur 5.15: Opprett kontrakt-skjerm Endre/behandle kontrakt Grunnet gyldighet på kontrakter har man ikke samme endre-valg som på de andre elementene i systemet. I denne sammenhengen er det riktigere å bruke ordet behandling. Herunder inngår følgende handlinger: 148

149 Signére en kontrakt Klikk på knappen Signér kontrakt eller trykk på teksten Signér helt nederst i kontraktvisningen. Klikk på knappen Velg signert kontrakt, og velg den signerte utgaven av kontrakten. Les mer om denne prosessen under Signer kontrakt. Klikk så på Last opp signert kontrakt -knappen for å fullføre signeringen. Merk! Du må huske på å laste opp en kopi av legitimasjon til kontrakten før du signérer. Figur 5.16: Signér-kontrakt-knapp Figur 5.17: Knapper for Velg signert versjon og Last opp signer versjon Kansellere en kontrakt Klikk på knappen Kanseller kontrakt for å kansellere kontrakten. Etter en kontrakt er kansellert må en ny opprettes om den skal være gyldig. Det er ikke mulig å reversere kanselleringen. Se kontraktdokument Klikk på knappen Vis kontraktdokument for å se PDF-versjonen av dokumentet. Dette er den utfylte versjonen av kontrakten. Om kontrakten er signért vil den signérte versjonen vises, og om den er 149

150 kansellert vil kansellert versjon vises (markert med et kansellert - stempel). Se tilhørende aktivitet Klikk på knappen Se tilhørende aktivitet for å komme til aktivitetsvisningen for kontrakten. Vise vedlegg Klikk på teksten Vis alle vedlegg for å se en liste over vedlegg til kontrakten. Dette kan for eksempel være utfylte utgaver av skjemaer valgt under kontraktopprettelsen, kopi av legitimasjon eller andre vedlegg som er lagt ved som vedlegg, eller kopiert fra kundens filer. For vedlegg som krever signering kan man laste opp en signert versjon ved å klikke Browse og så finne frem signert vedlegg. Klikk deretter på Last opp signert versjon -knappen for å fullføre. Klikk Vis for å se vedlegget før eller etter signering. Legg til eksisterende kundefil Klikk på teksten Legg til eksisterende kundefil for å legge til en fil som kunden allerede har knyttet opp mot seg. Dette kan være fullmaktskjemaer, kopi av legitimasjon, utfylte skjemaer eller andre vedlegg som tilhører kunden. Legg til vedlegg Klikk på teksten Legg til vedlegg for å legge til et vedlegg på kontrakten. Fyll ut vedleggsnavn og huk av om vedlegget er legitimasjon eller om den krever signering. Klikk på knappen Velg vedlegg for å velge vedlegg fra din lokale harddisk. Klikk så på Last opp vedlegg - knappen for å fullføre vedleggingen. Vis kontrakt Man kan finne frem til ønsket kontrakt å vise gjennom en spesefikk kunde, knyttet til en aktivitet, eller alle egne opprettede kontrakter. 1. For å finne frem til en kontrakt gjennom en kunde kan du bruke søkefunksjonen eller Meny, Kunder under Vis alle, klikk Vis på ønsket kunde, velg Kontrakter i toppmenyen og klikk Vis på ønsket kontrakt for å komme til kontraktvisning. 150

151 2. For å finne frem til en kontrakt gjennom en aktivitet kan du klikke Min kalender oppe i venstre hjørne, finne frem til ønsket aktivitet og trykke Vis for å komme til aktivitetvisning. Klikk så på knappen Tilknyttede kontrakter eller klikk på teksten Vis tilknyttede kontrakter, deretter Vis på ønsket kontrakt for å komme til kontraktvisning. 3. For å finne frem til ønsket kontrakt av egne opprettede kontrakter klikker du på navnet ditt oppe i høyre hjørne, så Min profil. Klikk så på Kontrakter i toppmenyen, og klikk så Vis på ønsket kontrakt for å komme til kontraktvisning. Figur 5.18: Kontraktvisning Kontraktstatuser En kontrakt har ulike statuser som man kan se til høyre i kontraktvisningen. Klar til signering Dette indikerer at kontrakten er koblet opp mot en aktivitet og en kunde og at den er klar til signering. Signert Dette indikerer at kontrakten er signert. Dette betyr også at kontrakten ikke lenger kan endres. Hvis en endring kreves må kontrakten kanselleres og det må skrives en ny kontrakt. 151

152 Kansellert før signering Indikerer at kontrakten er kansellert før den ble signert. Kansellert etter signering Indikerer at kontrakten er kansellert etter den ble signert, altså på angrefrist Skjema Opprette skjema Skjemaer kan legges ved som utfylte utgaver på kontrakter, men er isolert sett en mal som kan gjenbrukes. For å opprette et nytt skjema klikker du Meny oppe i venstre hjørne og klikk deretter på Nytt skjema. Fyll ut ønsket navn på skjema, beskrivelse og klikk så på Velg fil.... Finn frem skjemaet du vil laste opp og klikk så på Legg til skjema -knappen for å fullføre opprettelsen. Ved vellykket opprettelse vil du komme til oppsettet av skjemaet. Ved mislykket opprettelse av skjemaet vil du få tilbakemelding. Dette vil skje i de tilfellene du forsøker å laste opp et skjema som ikke er gyldig. Figur 5.19: Menyvalget Nytt skjema Sett opp/ endre skjema For å endre på et skjema klikker du på Meny oppe i venstre hjørne og deretter på Skjemaer under Vis alle til høyre i menyen. Du vil da komme til skjemaoversikten. Finn frem til det skjemaet du vil endre og klikk på teksten Endre. Du har nå kommet til endringsskjermen for skjemaet. Dette vil være tilsvarende visning som ved oppsett av skjemaet, men med tidligere 152

153 Figur 5.20: Opprett-skjema-skjerm satte felter. Disse visningene har fire kolonner: Venstre kolonne Her finner du det originale navnet på feltet fra skjemaet du lastet opp. Dette er hva avsender/oppretter av skjemaet har valgt. Dette kan ikke endres, men er ment som informasjon. Midterste kolonne Her kan du endre navnet på feltet fra originalnavnet. Dette er det feltet vil hete når du fyller den ut i kontraktopprettelsen, og dette endrer du slik at feltet blir logisk og forståelig. Høyre kolonne Her kan du velge hva feltet skal representere. Avhengig av hva du velger i nedtrekkslistene vil den valgte informasjonen hentes fra databasen. Dette kan typisk være kundens navn eller lignende, slik at man ikke behøver å skrive inn denne informasjonen. Hvis feltet ikke skal hente data, benytter man seg ikke av nedtrekkslisten. Ved unødvendig felt som ikke skal fylles ut kan man velge Annet deretter Ubenyttet felt i den skjulte kolonnen (Se punktet nedenfor) og feltet vil da bli hoppet over i kontraktopprettelse. Skjult kolonne Denne kolonnen er skjult frem til man eventuelt velger noe i høyre kolonne. Når noe er valgt i høyre kolonne vil denn kolonen bli snylig, og du kan videre spesifisere hva feltet skal knyttes mot. 153

154 Figur 5.21: Endre skjema- og sett opp skjema-skjerm Vis skjema For å se på et skjema klikker du på Meny oppe i venstre hjørne og deretter på Skjemaer under Vis alle til høyre i menyen. Du vil da komme til skjemaoversikten. Klikk på Vis på ønsket skjema for å se detaljer Kalender Opprette aktivitet For å opprette en ny aktivitet klikker du først på Min kalender oppe i venstre hjørne, deretter på teksten Legg til aktivitet. Fyll inn startdato og -tid, sluttdato og -tid, søk etter den kunden aktiviteten skal knyttes opp mot, aktivitetstype, aktivitetsted, en kort beskrivelse og aktivitetsdeltakere og klikk deretter på Opprett aktivitet -knappen for å fullføre opprettelsen. Ved vellykket opprettelse vil du bli på siden med tilhørende tilbakemelding. Ved mislykket opprettelse vil du bli på samme side og har muligheten til å rette opp i feilene. 154

155 Figur 5.22: Menyvalg for ny aktivitet Endre aktivitet For å endre en aktivitet klikker du først på Min kalender oppe i venstre hjørne, deretter klikker du Vis på den aktiviteten du vil endre. Du kommer da til aktivitetsvisningen. Klikk så på knappen Endre aktivitet eller teksten Endre aktivitet nederst på siden. Endre ønsket informasjon og klikk så på Lagre event -knappen for å fullføre endringen. Behandle aktivitet For å behandle en aktivitet klikker du på Behandle aktivtet. Her kan du sette en aktivitet til ferdigbehandlet, og du kan også si om kunden møtte opp på aktiviteten eller ikke ved å huke av de respektive avhukingsboksene. Du kan også legge til en aktivitetslogg, også kalt et møtereferat. Klikk på Behandle aktivitet -knappen for å fullføre behandlingen. Ved vellykket behandling vil du bli på aktivitetoversikten med tilhørende tilbakemelding. Ved mislykket behandling vil du bli på samme side med mulighet for å rette opp i feilene. Vis aktivitet For å vise en aktivitet klikker du først på Min kalender oppe i venstre hjørne, deretter klikker du Vis på den aktiviteten du vil se detaljer til. Du kommer da til aktivitetsvisningen. Her har man også noen menyvalg: Opprett kontrakt tilknyttet aktivitet Oppretter en kontrakt mot tilknyttet aktivitet og aktivitetens tilknyttede kunde. Ved å klikke på denne knappen kommer man direkte til kontraktopprettelse. 155

156 Figur 5.23: Opprett aktivitet-skjerm Endre aktivitet Endrer aktivitetsdetaljer. Ved å klikke på teksten Endre aktivitet får du frem redigerinsskjermen. Behandle aktivitet Ved å trykke på knappen og på teksten Behandle aktivitet kan man sette kunden til møtt eller ikke, møtet kan settes som 156

157 Figur 5.24: Behandle aktivitet ferdigbehandlet eller ikke, og en aktivetslogg (også kalt møtereferat) kan legges til. Klikk på knappen Behandle aktivitet for å fullføre behandlingen. Tilknyttede kontrakter Viser en oversikt over alle tilknyttede kontrakter til denne aktiviteten. Klikk på teksten Vis tilknyttede kontrakter for å få frem oversikten. 157

158 Figur 5.25: Vis aktivitet For deg som bruker Oppslagstavle Oppslagstavlen er den siden du blir møtt med etter vellykket innlogging. Du kan også gå til oppslagstavlen ved å klikke på logoen eller ved å trykke på ditt navn oppe i høyre hjørne, så Oppslagstavle. På oppslagstavlen finner du statistikk og informasjon om systemet. Dette er informasjon om Antall kontrakter, hvorav antall salg og kjøp også er oppgitt. Merk! Gjelder kun for signerte kontrakter Antall kunder, hvorav antall privat- og bedriftskunder er oppgitt Antall aktiviteter, hvorav antall aktiviteter møtt, ikke møtt og ubehandlet er oppgitt Mine kunder med siste aktivitet på de kunder du er rådgiver for. 158

159 Min profil Figur 5.26: Oppslagstavle Ved å klikke på ditt navn, og så klikke på Min profil kommer du inn på din egen profil. Her vil du bli presentert med din informasjon, og du har også en toppmeny. På din profil kan du gjøre følgende Oversikt Oversikt over din egen informasjon. Ved å klikke på de respektive lenkene kan du henholdsvis endre informasjon, endre passord eller endre rolle. Logg Her kan du legge til en ny logg, og også se informasjon for logger tilhørende kunder, automatiske logger, logger for uautorisert kundeakess, siste logger tilknyttet kunder og siste logger tilknyttet ansatte ved å klikke på de respektive linkene. Tilganger Her finner du en oversikt over tilgangsnivået ditt og hvilke handlinger du har tilgang til å utføre. Man kan også legge til tilleggstilganger ved å klikke på Legg til tilleggstilgang helt nederst på siden. Kontrakter Her finner du en oversikt over dine egne opprettede kontrakter. Klikk på Vis på ønsket kontrakt for å komme til kontraktvisningen. Kunder Her finner du en oversikt over dine egne opprettede kunder. Ved å klikke på Vis på ønsket kunde kommer du til kundevisningen. 159

160 Kalender Her vil du se din kalender, og har mulighet til å legge til, se og endre aktiviteter. (Dette er den samme visningen som om du klikker på Min kalender oppe i venstre hjørne). Se mer under Aktiviteter for å lese mer om hvordan man gjør dette. Min profil Ved å klikke på denne knappen kommer du tilbake til oversikten over din egen info. Figur 5.27: Min Profil-knapp Systeminnstillinger Ved å klikke på navnet ditt oppe i høyre hjørne, deretter på Systeminnstillinger har du mulighet til å Ta backup av alle kontrakter Om du vil ta en hardkopi av alle kontrakter til systemets nåværende tilstand bruker du denne knappen. 160

161 Denne kan du legge på din lokale harddisk eller på en backupdisk. Disse kommer i en ZIP-fil og det trengs et program som kan pakke ut disse filene om den skal vises. Endre bedriftsdetaljer Om du vil endre på Mesos bedriftsdetaljer klikker du på denne lenken. Du kan da endre på din bedrifts navn, e- postadresse, telefonnummer, hjemmeside, faksnummer, organisasjonsnummer, adresse, postnummer og poststed. Klikk på Lagre -knappen for å fullføre endringen. Ved vellykket endring vil du komme til samme side med tilhørende tilbakemelding. Ved mislykket endring vil du bli på den samme siden og har da muligheten til å rette opp feilene i feilmeldingen. Figur 5.28: Systeminnstillinger 5.5 Feil- og rettingsmuligheter Generelt i hele systemet får man tilbakemelding på hver eneste handling som gjøres. Ved vellykkede handlinger vil man enten gå til en side hvor man ser resultatet av hva handlingen som nettopp ble gjort var, eller bli værende på 161

162 den samme siden. Man vil etter envher handling få en tilbakemelding om handlingen var vellykket eller mislykket. Man har også muligheten til å ta en full backup av alle kontrakter i systemet i en ZIP-fil. Ved en eventuell serverkrasj, brann, ran eller andre uforutsette hendelser kan systemet gjennoprettes via denne. Tredjeparten som leverer servertjenester tar også backup av hele systemet ved gitte mellomrom. (a) Eksempel på feilmelding (b) Eksempel på suksessmelding (c) Eksempel på tilbakemelding uten feil eller suksess 162

163 Kapittel 6 Oppslag Contents 6.1 Figurer Kodesnutter Kilder

164 Denne siden er blank med hensikt.

165 6.1 Figurer Oversikt over figurer 1.1 Figur av den generelle gangen i systemet Skisse av databaseoppsett Commit-graf for Github-repository for implementasjonen Commit-graf for Github-repository for rapporten Utsnitt fra kravspesifikasjon Utsnitt fra sprintsummering Utsnitt fra scrumbrett på Trello Designskisse: Innloggingsskjerm Designskisse: Innlogget skjerm Designskisse: Eksisterende dokument Designskisse: Nytt dokument Designskisse: Eksisterende kunde Designskisse: Ny kunde Designskisse: Opprettet dokument Designskisse: Opprettet dokument m/ innfelt meny Skjermbilde: startside Skjermbilde: kontraktvisning Skjermbilde: åpen hovedmeny Skjermbilde: åpen brukermeny Skjermbilde: kontraktvisning Skjermbilde: ny brukermeny Skjermbilde: kalendervisning Skjermbilde: lag ny kontrakt Skjermbilde: oppslagstavle Skjermbilde: last ned sikkerhetskopi Skjermbilde: ny hovedmeny Skjermbilde: ny kontraktvisning

166 2.26 Skjermbilde: nyeste brukermeny Skjermbilde: skjemaoppsett Skjermbilde: nyeste meny Skjermbilde: relokalisert søkefelt og Min kalender -knapp Skjermbilde: ny oppslagstavle Skjermbilde: ny kundevisning Skjermbilde: nytt tabelldesign Skjermbilde: nytt knappedesign Webapplikasjonens byggeklosser Gangen i MVC-strukturen Illustrasjon av oppstart av webapplikasjonen Illustrasjon av ansatthandling i nettleseren Illustrering av ansatthandling i nettleseren Aktivitetsdiagram for ansatt-handlinger Aktivitetsdiagram for kunde-handlinger Aktivitetsdiagram for å opprette et skjema Aktivitetsdiagram for å opprette et skjema Menystruktur for enhetstesting Resultat av enhetstesting Meny fra prototype Meny fra prototype sluttprodukt Innloggingsskjermen Logg-ut-knapp Skjermbilder for glemt passord Eksempel på hurtigsøk Eksempel på et fullstendig søk Kundesøk Menyvalget Ny kunde Felter ved kundeopprettelse Endre-kunde-skjerm Kundevisning Menyvalg for opprett ansatt Endre ansatt-skjerm Ansattvisning Sletting av ansatt

167 5.15 Opprett kontrakt-skjerm Signér-kontrakt-knapp Knapper for Velg signert versjon og Last opp signer versjon Kontraktvisning Menyvalget Nytt skjema Opprett-skjema-skjerm Endre skjema- og sett opp skjema-skjerm Menyvalg for ny aktivitet Opprett aktivitet-skjerm Behandle aktivitet Vis aktivitet Oppslagstavle Min Profil-knapp Systeminnstillinger Aktivitetsdiagram for skjema-konfigurasjon Oppsett av et skjema Oppsett av et skjema, med tilkoblinger Tabellen pdftemplates Skjemalogikk Mappestruktur for rammeverket Mappestruktur for views Mappestruktur for useractions Eventuelle tilbakemeldinger skrives ut her 2. Her endrer innholdet seg Statisk topp 2. Eventuell toppmeny vises her 3. Eventuelle tilbakemeldinger kommer her 4. Dynamisk innhold, alle applikasjonens handlingers sider Reultat av koden i kodesnutt

168 6.2 Kodesnutter Oversikt kodesnutter 3.1 Filstruktur TestCase.php for enhetstesting CustomerControllerTest.php under app/test/controllers/ Komplett fil database.php under app/config/testing/ FactoryMuff-array for modellen User Tester metoden getname i Usermodellen Sammenligingsmetode for User i UserTest Tester metode som behandler ugyldige handlinger sendt inn til UsersActionController Assertions benyttet i modeller Assertions benyttet i controllere Kjøre enhetstester pdftk-kall for metacheck.bash Utsnitt fra library ENUM Utsnitt Usersmodellen Hente felter fra database Hente felter fra database Hente felter fra database Hente felter fra database Utsnitt av filters.php Eksempel på å tvinge alle requester til webapplikasjonen over HTTPS routes.php Migration for Bankaccount DatabaseSeeder.php UserrolesTableSeeder Bankaccount-modellen med Eloquent-metoder Utsnitt fra User

169 8.9 Utsnitt fra Calendarevent Metoden identifier fra UsersActionController Funksjonen db viewusers i UsersActionController Funksjonen fileviewer i biblioteket Helpers Funksjonen canchangerole($user id) i Usermodellen Funksjonen addrole() i Usermodellen Sjekk for tilbakemeldinger Sjekk for toppmeny og elementer Blade-eksempel Makro-eksempel Visualisering med Google Charts Ikoneksempel Media queries LESS.css deklarasjon LESS.css nesting-eksempel LESS.css variabel-eksempel LESS.css mixin-eksempel Kilder Kildene viser hvilket avsnitt de er benyttet i, lenken til kilden samt sidenummeret kilden refereres til på. Man kan klikke på avsnittet som en intern lenke i rapporten, eller på lenken for å komme til kilden. Oversikt over kilder pdf Laravel: Netbeans: Git:

170 2.4 Github: Trello: Google Docs: Dropbox: LaTeX: Texmaker: Laravel dokumentasjon: Gruppesiden: /32/ Bildebehandlingsverktøy fra Adobe, PDFtk: http://fortawesome.github.io/Font-Awesome/ http://jquery.com/ http://tbrown.org/ http://modularscale.com/ GitHub-Repository for PHPUnit: phpunit/ Dokumentasjonsside for Laravel Unit Testing: com/docs/testing Guide for enhetstesting i Laravel for tutorials/testing-like-a-boss-in-laravel-models--net Unit Testing for Software Craftsmanship com/products/mocking/unit-testing.aspx GitHub-Reposityory til FactoryMuff factory-muff PDFtk: 7.2 XFDF-standard: en/xml/xfdf_spec_3.0.pdf

171 https://developers.google.com/chart/interactive/docs/gallery/ piechart

172 Denne siden er blank med hensikt.

173 Kapittel 7 Appendiks A: Teknisk appendiks for PDFtk 7.1 Forord Dette tekniske appendikset tar for seg prosessen med å gjøre om PDF-filer til skjemaer som kan taes i bruk i applikasjonen. Den tar for seg bruken av kommandolinjeverktøyet PDFtk og hvordan det kalles fra applikasjonen og på operativsystemet. Contents 7.1 Forord Programvare Bruk i applikasjonen Konfigurere skjemaer Fylle ut skjemaer Fyll ut data Generering av XFDF Unik XFDF-fil for hver ansatt Kombinere XFDF og mal Kontraktskansellering

174 Denne siden er blank med hensikt.

175 7.2 Programvare For å håndtere PDF-dokumentene tar applikasjonen i bruk tredjepartsprogramvaren PDFtk 34. Dette kommandolinjeverktøyet kan gjøre en rekke operasjoner og å manipulere PDF-dokumenter. PDFtk er det eneste av de PDF-verktøyene ute som kan gjøre de ønskede operasjonene som trengs i denne applikasjonen. 7.3 Bruk i applikasjonen I applikasjonen brukes PDFtk til å hente ut metadata, i form av utfyllbare felter ( forms ), fra eksisternede skjemaer og å kombinere data fra systemet til et ferdig utfylt dokument. Det benyttes også til å legge på kanselleringsstempel på kansellerte kontrakter. Webapplikasjonen tar nytte av XML Forms Data Format (XFDF) som er et datalag som kan skilles ut fra et PDF-dokument. Dette laget fylles med data via enkle XML-notasjoner, og kombineres tilbake til et PDF-dokument. 34 PDFtk: 175

176 7.4 Konfigurere skjemaer Figur 7.1: Aktivitetsdiagram for skjema-konfigurasjon Last opp skjema For å ta i bruk et skjema i applikasjonen må man først sette opp dokumentet for bruk. Det gjør man ved først laste opp et skjema i systemet. I denne prosessen sjekker systemet om filen som blir valgt inneholder de riktige metadataene for å kunne brukes i systemet. Sjekk for felter Når en fil blir lastet opp kalles det på postmetoden postaddtemplate() i UsersActionController. Denne metoden sjekker om filendelsen på opplastet fil er.pdf og kaster feilmelding hvis det ikke er det. Hvis den første testen passerer sjekkes det videre om det opplastede skjemaet inneholder metadata i form av utfyllbare felter. Dette gjøres via et bash-script, metacheck.bash, som gjør PDFtk-kallet i kodesnutt 7.1 og returnerer true eller false basert på om kommandoen returnerer verdier eller ikke. Kodesnutter 7.1: pdftk-kall for metacheck.bash 1 pdftk $1 d u m p d a t a f i e l d s u t f 8 grep FieldName : cut d f2 Hvis filen som blir forsøkt lastet opp ikke inneholder metadata, blir det kastet en feilmelding. Hvis den passerer blir man sendt videre for å sette opp et skjema. 176

177 Importere felter For å hente ut de aktuelle feltene i et dokument brukes det et bash-script som kjører følgende kommando: pdftk skjema.pdf dump_data_fields_utf8 Denne kommandoen henter ut og lister opp alle de utfyllbare feltene som finnes i et dokument. Resultatet legges i et array, og sendes opp igjen til applikasjonen. Sett opp skjema Filen har nå gått gjennom de første sjekkene og er dermed klart til å settes opp. Vi har importert de feltene vi kan operere med og vi må nå definere hva hvert felt skal gjøre, slik at skjemaet automatisk fylles ut med data lagret i databasen når det skal lages kontrakter. Figur 7.2: Oppsett av et skjema Venstre kolonne Her finner du det originale navnet på feltet fra skjemaet du lastet opp. Dette er hva avsender/oppretter av skjemaet har valgt. Dette kan ikke endres, men er ment som informasjon. Midterste kolonne Her kan du endre navnet på feltet fra originalnavnet. Dette er det feltet vil hete når du fyller den ut i kontraktopprettelsen, og dette endrer du slik at feltet blir logisk og forståelig. 177

178 Høyre kolonne Her kan du velge hva feltet skal representere. Avhengig av hva du velger i nedtrekkslistene vil den valgte informasjonen hentes fra databasen. Dette kan typisk være kundens navn eller lignende, slik at man ikke behøver å skrive inn denne informasjonen. Hvis feltet ikke skal hente data, benytter man seg ikke av nedtrekkslisten. Ved unødvendig felt som ikke skal fylles ut kan man velge Annet deretter Ubenyttet felt i den skjulte kolonnen (se punktet nedenfor) og feltet vil da bli hoppet over i kontraktopprettelse. Skjult kolonne Denne kolonnen er skjult frem til man eventuelt velger noe i høyre kolonne. Når noe er valgt i høyre kolonne vil denn kolonen bli synlig og du kan videre spesifisere hva feltet skal knyttes mot. Figur 7.3: Oppsett av et skjema, med tilkoblinger I figur 7.3 er det satt opp et eksempel på ulike knytninger. Når man har satt alle koblingspunktene lagres alle feltene i databasen. Hvert skjema får én oppføring per felt, hvor alle egenskapene til et enkeltfelt er beskrevet. 178

179 Figur 7.4: Tabellen pdftemplates Figur 7.4 viser alle attributtene til tabellen pdftemplatesfields. Koblingspunktene blir lagret i feltene table id og attribute name. table id representerer hvilken tabell feltets innhold skal hentes fra, mens attribute name sier hvilken metode i tabellen det skal hentes fra. table id sine koblingstabeller er definert som enums i ENUM-biblioteket, hvor tabellene er knyttet mot kunde, ansatt, kontrakt, Meso eller annet (se figur 7.2). pdftemplate id er knytningen mot hvilket skjema det gjelder, fieldname er navnet på feltet fra vedkommende som har laget PDF-skjemaet og displayname er navnet man selv definerer for lettere forståelse. Kodesnutter 7.2: Utsnitt fra library ENUM 1 const DB NO TABLE CHOSEN =0; 2 const DB NO ATTRIBUTE CHOSEN= n o t s e t ; 3 const DB USER TABLE ID = 1 ; 4 c o n s t DB CUSTOMER TABLE ID =2; 5 const DB OTCCONTRACT TABLE ID =3; 6 const DB COMPANY TABLE ID =4; 7 const OTHER ID =5; Kodesnutten viser de forskjellige variablene table id kan være knyttet mot. 179

180 Kodesnutter 7.3: Utsnitt Usersmodellen 1 p u b l i c f u n c t i o n dd getname ( ) { 2 return $ t h i s >getname ( ) ; 3 } 4 p u b l i c f u n c t i o n dd getnameupper ( ) { 5 return strtoupper ( $ t h i s >getname ( ) ) ; 6 } 7 p u b l i c f u n c t i o n dd gettelephone ( ) { 8 return $ t h i s >telephone ; 9 } 10 p u b l i c f u n c t i o n dd get ( ) { 11 return $ t h i s > ; 12 } 13 p u b l i c f u n c t i o n dd getbirthdate ( ) { 14 return $ t h i s >b i r t h d a t e ; 15 } Kodesnutten viser de forskjellige metodene som er tilgjengelige for attribute name når table id er satt til DB USER TABLE ID (Se kodesnutt 7.2). Tabellen pdftemplatesfields holder styr på hvert enkelt felt i et skjemaet, og de eventuelle koblingspunktene mot eksisterende data. Når alle feltene er lagret i databasen, er skjemaet klart til bruk. 7.5 Fylle ut skjemaer Figur 7.5: Skjemalogikk Den andre sentrale operasjonen som gjøres på skjemaer er å lage kontrakter. Her kombineres data fra databasen, tilknyttede felter og de resterende feltene i dokumentet. 180

181 Hent felter fra database Først hentes det opp fra databasen alle feltene et skjema inneholder. Dette gjøres enkelt via en databasespørring: $fields = $template->pdftemplatefields()->get(); Hente knyttet data For å hente ut innholdet til de knyttede feltene kjøres følgende kodesnutt 7.2. Kodesnutter 7.4: Hente felter fra database 1 for ( $ i =0; $i<count ( $ f i e l d s ) ; $ i++){ 2 $ a c t i v e F i e l d = $ f i e l d s [ $ i ] ; 3 i f ( $ a c t i v e F i e l d >t a b l e i d!= ENUM: : DB NO TABLE CHOSEN) { 4 $ a t t r i b u t e = $ a c t i v e F i e l d >attribute name ; 5 i f ( $ a c t i v e F i e l d >t a b l e i d == ENUM: : DB USER TABLE ID) 6 $ p r e F i l l e d F i e l d s [ $ i ]=Auth : : user ( ) >$ a t t r i b u t e ( ) ; 7 e l s e i f ( $ a c t i v e F i e l d >t a b l e i d == ENUM: : DB CUSTOMER TABLE ID) 8 $ p r e F i l l e d F i e l d s [ $ i ]=Customer : : getcustomer ( $customerid ) >$ a t t r i b u t e ( ) ; 9 e l s e i f ( $ a c t i v e F i e l d >t a b l e i d == ENUM: : DB OTCCONTRACT TABLE ID) 10 $ p r e F i l l e d F i e l d s [ $ i ]= $contract >$ a t t r i b u t e ( ) ; 11 e l s e i f ( $ a c t i v e F i e l d >t a b l e i d == ENUM: : DB COMPANY TABLE ID) 12 $ p r e F i l l e d F i e l d s [ $ i ]=$company >$ a t t r i b u t e ( ) ; 13 e l s e i f ( $ a c t i v e F i e l d >t a b l e i d == ENUM: : OTHER ID) 14 $ p r e F i l l e d F i e l d s [ $ i ]= Templates : : getotherchoices ( $ a t t r i b u t e ) ; 15 } 16 } Denne løkken itererer over alle feltene i skjemaet. I linje 3 sjekkes det først om det valgte feltet har en tilknytning til en tabell. Hvis feltet har en tilknytning hentes attribute-navnet og lagres i variabelen $attribute. Feltet sjekkes så opp mot alle de ulike modellene som er gitt ved syntaksen ENUM::DB modell TABLE ID. Hvis denne testen slår inn hentes det ut en verdi fra tilhørende objekt med metodenavnet som er det samme som attribute name. Hvis et felt har attributt-verdien dd getname vil dette tilsvare metoden som kjøres i linjene med $prefilledfield[$i] hvor $attribute() delen svarer til dd getname. 181

182 Når alle feltene er hentet ut settes de verdiene inn i input-boksene i utfyllingen. Slik blir verdiene ferdig utfylte, men ikke lukket, slik at de kan endres dersom data fra databasen ikke tilsvarer det man ønsker å ha med. 7.6 Fyll ut data Når de ferdige feltene er satt opp fyller man ut resterende felter manuelt som man vil ha med i kontrakten. 7.7 Generering av XFDF Neste steg i prosessen er å generere opp en XFDF-datafil som følger XFDFstandarden 35. Denne filen bygger på en XML-struktur gitt ved følgende kodesnutt: Kodesnutter 7.5: Hente felter fra database 1 <?xml version= 1. 0 encoding= UTF 8?> 2 <x f d f xmlns= h t t p : // ns. adobe. com/ x f d f / xml:space= p r e s e r v e > 3 <f h r e f= / l i n k / t i l / skjema. pdf /> 4 < f i e l d s> 5 < f i e l d name= Selskap a k s j e > 6 <value>mitt s e l s k a p</ value> 7 </ f i e l d> 8 < f i e l d name= ISIN nr evt org nr > 9 <value>12345</ value> 10 </ f i e l d> 11 < f i e l d name= H e f t e l s e r kun f o r s e l g e r > 12 <value>kun kontant</ value> 13 </ f i e l d> 14 </ f i e l d s> 15 </ x f d f> Field name er navnet på det feltet man ønsker å fylle, mens value er den verdien du ønsker å fylle feltet med. 35 XFDF-standard: Spec_3.0.pdf 182

183 7.7.1 Unik XFDF-fil for hver ansatt Når det genereres XFDF-datafiler, lagres det én unik fil per bruker i systemet, under PDF/Temp-katalogen. Dette for at brukere ikke skal kunne overskrive hverandres datafil, og at flere kan opprette kontrakter samtidig i systemet. 7.8 Kombinere XFDF og mal Når den ferdige XFDF-filen er generert kombineres denne filen og det skjemaet feltene er knyttet til. Dette gjøres ved hjelp av bash-scriptet generatepdf.bash Kodesnutter 7.6: Hente felter fra database 1 #!/ bin / bash 2 #Parameter: $1 :template, $2 : x f d f, $3 :output 3 4 pdftk $1 f i l l f o r m $2 output $3 f l a t t e n Dette scriptet kombinerer malen (template), med datafilen (xfdf) og lager en ny fil (output) som er den ferdige utfylte kontrakten. Parameteret flatten blir også brukt, slik at kontrakten nå ikke kan endres og er låst med de feltene som er satt. 7.9 Kontraktskansellering Systemet kan også kansellere kontrakter som er opprettet. Teknisk sett er dette løst ved at det legges på et stempel som inneholder ordet KANSELLERT over det eksisterende dokumentet. I PDFtk brukes stamp-funksjonen, som legger et PDF-dokument over et annet. Vi har laget en fil, cancelstamp.pdf som legges over alle kontraktene. Bash-scriptet som utfører kansellering er slik: Kodesnutter 7.7: Hente felter fra database 1 #!/ bin / bash 2 #Parameter: $1 :stempel, $2 :kontrakt, $3 :output 3 pdftk $1 stamp $2 output $3 183

184 Denne siden er blank med hensikt.

185 Kapittel 8 Appendiks B: Teknisk appendiks for Laravel 8.1 Forord Dette tekniske appendikset bygger videre på produktdokumentasjonen og tar for seg rammeverket Laravel og dets design på et mer teknisk plan. Vi anbefaler å lese produktdokumentasjonen før det tekniske appendikset da mye av innholdet bygger videre på produktdokumentasjonen. Contents 8.1 Forord Laravelversjon Composer Artisan Rammerverkets mappestruktur Filters Filters overs HTTPS Routes Database og modeller Databasedefinisjon Migrations Seeds

186 8.8.4 Eloquent Mange-til-mange-relasjoner Softdeletes Views Innledning Mappestruktur for views Views for ansatthandlinger(useractions) Gjenbruk Controllere Generelt om controllere UsersAction- og CustomerController Sikkerhetsfaktorer Filaksess Backdoor SorteringsID Ting vi kunne gjort annerledes og forbedringspotensiale Databasemodell Flere controllere Design Layouts Blade Visualisering Ikoner Bruk av CSS-filer CSS Media-queries LESS.css

187 8.2 Laravelversjon Webapplikasjonen er skrevet i Laravel versjon 4.1. I sluttfasen av implementeringen ble det lansert en versjon 4.2 beta med endringer på blant annet softdeletes (se punkt 8.8.6) som vi ikke har testet implementasjoen med og kan være utslagsgivende for blant annet softdeletes som er benyttet. 8.3 Composer Composer benyttes som et pakkebehandlingsverktøy i Laravel, som med andre ord administrerer pakkeavhengigheter i prosjektet 36. Composer installerer pakker som trengs for å kunne kjøre webapplikasjonen, og installerer dem i en mappen vendor i prosjektet. Composer løser fire problemer Installerer alle pakker som prosjektet er avhengig av for å kunne kjøre. 2. Installerer alle pakker som pakkene i punkt 1 er avhengige av. 3. Man definerer hvilke pakker prosjektet er avhengig av og composer ordner resten. 4. Composeren finner ut hvilken versjon av hvilke pakker som må installeres, og installerer det som er nødvendig. 8.4 Artisan Artisan er navnet på kommandolinjegrensesnittet som benyttes i Laravel. I vår webapplikasjon har dette primært blitt brukt i forbindelse med databasebehandling (Se avsnitt 8.8). Artisan benyttes ved at man står i rotmappen til prosjektet i Bash/Powershell og skriver kommandoer på formen php artisan

188 8.5 Rammerverkets mappestruktur For å få et godt overblikk over rammerverket før vi tar for oss spesifikke deler er det hensiktsmessig å få forstå hvordan rammeverket er satt sammen. Figur 8.1: Mappestruktur for rammeverket De røde varselindikatorene skyldes kode som er gyldig for rammeverket men Netbeans tolker som ugylidg syntax. 8.6 Filters Filters er delen av rammeveket som i første omgang undersøker om requesten er gyldig, og om den innloggede brukeren har tilgang til etterspurt side. Det finnes et predefinert filter Auth som sjekker om brukeren er logget inn, men videre har vi laget filtre for å beskytte innhold i forhold til tilgangsnivåer. 188

189 Kodesnutter 8.1: Utsnitt av filters.php 1 Route : : pattern ( id, [1 9][0 9]{0,15} ) ; 2 Route : : pattern ( c u s t i d, [1 9][0 9]{0,15} ) ; 3 Route : : when ( u s e r s / a c t i o n /, auth u s e r a c c e s s ) ; 4 Route : : when ( customer /, auth customeraccess ) ; 5 6 Route : : f i l t e r ( customeraccess, f u n c t i o n ( ) 7 { 8 $id = Route : : input ( id ) ; 9 $ c u s t i d = Route : : input ( c u s t i d ) ; 10 $ a c t i o n = Route : : input ( a c t i o n ) ; 11 $actionmodel = Custaction : : where ( name, =, $ a c t i o n ) > f i r s t ( ) ; // Tester om det er en g y l d i g a c t i o n 14 i f ( $actionmodel==n u l l ) { 15 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( message =>Lang : : get ( feedback. n o t v a l i d a c t i o n, array ( a c t i o n =>$ a c t i o n ) ), message type => f a i l ) ) ; 16 } 17 // Tester om det er en g y l d i g kunde 18 i f ( Customer : : f i n d ( $ c u s t i d )==n u l l ) { 19 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( message =>Lang : : get ( feedback. i n v a l i d c u s t o m e r i d, array ( id =>$ c u s t i d ) ), message type => f a i l ) ) ; 20 } 21 // Tester om brukeren har t i l g a n g 22 $auth = Auth : : user ( ) ; i f (! ( $auth >hascustomeraccess ( $custid, $actionmodel >id ) ) ) { 25 Userlogunauth : : addlog ( $auth >id, $custid, $actionmodel >id, Lang : : get ( l o g. u n a u t h o r i z e d a c c e s s ) ) ; 26 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( message =>Lang : : get ( feedback. n o a c c e s s c u s t a c t i o n, array ( a c t i o n =>Lang : : get ( c u s t a c t i o n s.. $ a c t i o n ) ) ), message type => f a i l ) ) ; 27 } 28 // Tester om actionen k r e v e r id, og om denne er g i t t 29 i f ( $actionmodel >id dependent && $id==n u l l ) { 30 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( 189

190 message =>Lang : : get ( feedback. i d d e p e n d e n t a c t i o n, array ( a c t i o n =>Lang : : get ( c u s t a c t i o n s.. $ a c t i o n ) ) ), message type => f a i l ) ) ; 31 } 32 // Tester om actionen i k k e k r e v e r id, og i d er g i t t 33 i f (! $actionmodel >id dependent && $id!= n u l l ) { 34 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( message =>Lang : : get ( feedback. i d i n d e p e n d e n t a c t i o n, array ( a c t i o n =>Lang : : get ( c u s t a c t i o n s.. $ a c t i o n ) ) ), message type => f a i l ) ) ; 35 } 36 }) ; Linje 1 og 2 tester om variabelen $id og $custid i requesten er gyldige innenfor et gitt regex-mønster. Linje 3 beskytter alle sider under users/action/ ved at man må være logget inn og komme forbi useraccess-filteret. Linje 4 beskytter alle sider under customers/ ved at man må være logget inn og kommer forbi customeraccess-filteret. Fra linje 6 og utover vises hele customer-accessfilteret som nevnt i linje 4. Finnes også lignende filter for useraccess-filter som fungerer på samme måte. Konkrete deler i filteret kommer frem som kommentarer i kodesnutten. Den viktigste delen av filteret kommer frem på linje 24 hvor det testes om innlogget bruker har tilgang på etterspurt handling på kunden, om brukeren ikke har tilgang vil det logges som et uautorisert tilgangsforsøk Filters overs HTTPS For å kunne benytte webapplikasjonen med kryptering er det i filters.php mulig å tvinge sidene til å kun aksesseres via https 39. Dette er ikke en del av implementasjonen per nå, men tiltenkt når oppdragsgivers server er klar. For å få denne ønskede funksjonaliteten må det endres på filters sin metode App::before 40 som vist i kodesnutten under. Dette vil sikre alle deler av webapplikasjonen med kryptert overføring

191 Kodesnutter 8.2: Eksempel på å tvinge alle requester til webapplikasjonen over HTTPS 1 App : : b e f o r e ( f u n c t i o n ( $ r e q u e s t ) 2 { 3 i f (! Request : : s e c u r e ( ) ) 4 { 5 return Redirect : : s e c u r e ( Request : : path ( ) ) ; 6 } 7 }) ; 8.7 Routes Routes er delen av rammeverket som alle requester til webapplikasjonen kommer om den har passert Filters. Her undersøkes det om requesten er gyldig. Om requesten er gyldig vil en routes-oppføring sende requesten videre i webapplikasjonen, ellers vil brukeren bli møtt med en 404-side som informerer om at etterspurt side ikke eksisterer. Vi har benyttet tre forskjellige routes-oppføringer: En GET-route som omdirigerer til andre sider En GET-route som viser til en spesifikk funksjon i en controller. En controller-route som sender alle requester etter et gitt mønster sendes til en controller. Hvis det for eksempel sendes en request med mønster users og funksjon login vil rammeverket søke gjennom controlleren om det finnes en metode som heter getlogin og om det er et GET-kall, eller postlogin om det er et POST-kall. Kodesnutter 8.3: routes.php 1 Route : : get ( /, f u n c t i o n ( ) { 2 return Redirect : : to (URLS : : userlink ( dashboard ) ) ; 3 }) ; 4 5 // J a v a s c r i p t r e s s u r s e r 6 Route : : get ( / e v e n t j s o n, JsonController@eventsToJson ) ; 7 Route : : get ( / c o n t r a c t j s o n, JsonController@contractsToJson ) ; 8 Route : : get ( / customerjson, JsonController@customersToJson ) ; 9 Route : : get ( / hasevents /{ id }, JsonController@getUsersEventsJson ) ; 191

192 10 Route : : get ( / a j a x s e a r c h /{q}, JsonController@customerSearchJson ) ; // Ansattdelen 13 Route : : get ( u s e r s / a c t i o n /{ a c t i o n }, UsersActionController@action ) ; 14 Route : : get ( u s e r s / a c t i o n /{ a c t i o n }/{ id }, U s e r s A c t i o n C o n t r o l l e i d e n t i f i e r ) ; 15 Route : : c o n t r o l l e r ( u s e r s / a c t i o n /{ a c t i o n }/{ id }, U s e r s A c t i o n C o n t r o l l e r ) ; 16 Route : : c o n t r o l l e r ( u s e r s / a c t i o n /{ a c t i o n }, U s e r s A c t i o n C o n t r o l l e r ) ; // I n n l o g g i n g 19 Route : : c o n t r o l l e r ( u s e r s, U s e r s C o n t r o l l e r ) ; // Kundedelen 22 Route : : get ( customer /{ c u s t i d }/{ a c t i o n }, CustomerController@action ) ; 23 Route : : get ( customer /{ c u s t i d }/{ a c t i o n }/{ id }, C u s t o m e r C o n t r o l l e i d e n t i f i e r ) ; 24 Route : : c o n t r o l l e r ( customer /{ c u s t i d }/{ a c t i o n }/{ id }, CustomerController ) ; 25 Route : : c o n t r o l l e r ( customer /{ c u s t i d }/{ a c t i o n }, CustomerController ) ; // Glemt passord f u n k s j o n a l i t e t 28 Route : : c o n t r o l l e r ( password, RemindersController ) ; Linje 1-3 omdirigerer brukeren til dashboard når den går til rotmappen. Om brukeren i sin tur ikke er logget inn vil dashboardet omdirigere til logginn-skjermen gjennom controlleren. Linje 6-9 inneholder routes til javascriptressurser tilknyttet arrangementer, kontrakter og kunder. Linje 13 behandler alle requester for ansatthandlinger som ikke har id, og blir videresendt til UsersActionControllers funksjon action. Linje 14 behandler tilsvarende requester som linje 13, men med id. De blir da videresendt til UsersActionControllers funkson identifier Linje 15 og 16 behandler POST-request for alle funksjoner i UsersActionControllers Linje 19 sender alle metoder med /users/ inn til UsersController Linje er tilsvarende for kundedelen som beskrevet for ansattdelen 192

193 i linje Linje 28 sender alle metoder med /password/ inn til RemindersController 8.8 Database og modeller Databasedefinisjon Under mappen config/database.php defineres det hva slags database man skal bruke. Det eneste som da trenger å defineres er databasetype (i vårt tilfelle MySQL), navn på databasen og brukernavn. Når disse parameterne er satt, og tilsvarende database opprettes vil man ved hjelp av migrations kunne fylle databasen. Både migration og seeds som nevnt i avsnittene under ligger i database/ og undermapper med tilhørende navn Migrations Migrations 41 er SQL-substitutt for create table.... I migrationen defineres alle tabeller, datafelter og relasjoner tilsvarende en lengre SQL-setning for å opprette en tabell og å sette fremmednøkler. I en migration defineres 42 en funksjon for å sette opp migrationen (up) og en for å rulle tilbake migrationen (down). Ved å sette opp databasen på denne måten er det mulig å kunne sette opp tilsvarende miljø andre steder ved å sette i gang migrationen på kommandolinjen. Måten man oppretter en migration på er å skrive en artisan-kommando som genererer en php-fil med et skall som legger seg inne i mappen migrations. Denne filen får et timestamp slik at de legger seg løpende nedover i forhold til når de ble opprettet. For å for eksempel lage users-tabellen ble kommandoen php artisan migrate:make create\textunderscore users\textunderscore table create=users benyttet. For å kjøre alle migrations i undermappen med samme navn skrives php artisan migrate. Da vil rammeverket oversette dette til valgt databasespråk, i vårt tilfelle MySQL, og opprette hele databasen med tabeller og relasjoner

194 mellom dem. Om man ved et senere tidspunkt ønsker å legge til en tabell kan man lage en egen migration for dette og spesifisere hvilken migration som skal kjøres, om ikke alle skal kjøres som beskrevet ovenfor. Kodesnutter 8.4: Migration for Bankaccount 1 <?php 2 3 use I l l u m i n a t e \ Database \ Migrations \ Migration ; 4 5 c l a s s CreateBankaccountsTable extends Migration { 6 7 p u b l i c f u n c t i o n up ( ) 8 { 9 Schema : : c r e a t e ( bankaccounts, f u n c t i o n ( $ t a b l e ) { 10 $table >engine = InnoDB ; 11 $table >increments ( id ) ; 12 $table >i n t e g e r ( customer id ) >unsigned ( ) ; 13 $table >s t r i n g ( number, 30) ; 14 $table >boolean ( primary ) >default ( f a l s e ) ; $table >timestamps ( ) ; 17 $table >s o f t D e l e t e s ( ) ; $table >f o r e i g n ( customer id ) 20 >r e f e r e n c e s ( id ) >on ( customers ) 21 >ondelete ( cascade ) ; 22 }) ; 23 } p u b l i c f u n c t i o n down ( ) 26 { 27 Schema : : drop ( bankaccounts ) ; 28 } 29 } Linje 5 er klassedefinisjonen som extender Migration og gjør at rammeverket gjenkjenner klassen som en migration. Fra linje 7 til 22 defineres funksjonen up som kjøres når man sette opp migrationen, I linje defineres selve innholdet i tabellen. Det viktigste i denne sammenheng er at id er som skal benyttes som fremmednøkler må være unsigned og at primærnøkkel settes opp som vist på linje

195 Linje 16 setter attributtene created at, updated at i tabellen. Linje 17 settes attributten deleted at i databasen som benyttes i sammenheng med sletting. Linje beskriver relasjonen tilhørende fremmednøkkelen definert på linje 12. For at dette skal fungere må tabellen man definerer relasjonen til være opprettet fra før. Fra linje 25 og utover defineres funksjonen down som kjøres når man ønsker å gjøre rollback for migrationen, altså å tilbakestille databasen til slik det var før migrationen ble kjørt Seeds Seeds benyttes for å fylle databasen med innhold og fungerer således som SQL s insert into... Det benyttes fortrinnsvis predefinert innhold som får webapplikasjonen til å fungere som ønsket. Dette gjelder blant annet alle ansatt- og kunderoller samt et par brukere og testkunder for å kunne ta i bruk webapplikasjonen. Om man for eksempel ønsker å legge til flere ansattroller senere kan man lage en UserrolesTableSeeder php som legger til ytterligere roller. På denne måten tar man vare på koden for eventuelt å gjenskape et tilsvarende miljø. For å seede databasen skriver man i kommandolinjen for rammeverket php artisan db:seed. Da kjøres automatisk seeden DatabaseSeeder (se figur under) som igjen kaller på definerte seeder. For å kun kjøre en annen type seed, slik som vi gjorde under brukertesten (se testdokumentasjonen) brukte vi kommandoen php artisan db:seed class=testseeder. Man kan også gjøre tilsvarende om man skal fylle på informasjon i databasen som beskrevet ovenfor ved å legge til flere ansattroller. 195

196 Kodesnutter 8.5: DatabaseSeeder.php 1 <?php 2 3 c l a s s DatabaseSeeder extends Seeder { 4 5 p u b l i c f u n c t i o n run ( ) 6 { 7 Eloquent : : unguard ( ) ; 8 $ t h i s >c a l l ( U s e r r o l e s T a b l e S e e d e r ) ; 9 $ t h i s >c a l l ( UseractionsTableSeeder ) ; 10 $ t h i s >c a l l ( U s e r a c t i o n U s e r r o l e T a b l e S e e d e r ) ; } 15 } Linje 3 er klassedefinisjonen som inneholder extends Seeder som forteller rammeverket at klassen er en seed. Navnet DatabaseSeed er definert som hovedseed og vil kjøres om man ikke spesifiserer annet ved kjøring. Det resterende av koden kaller videre på seeder vi har laget slik at alle kjøres ved en normal seed av databasen. Kodesnutter 8.6: UserrolesTableSeeder 1 <?php 2 3 c l a s s U s e r r o l e s T a b l e S e e d e r extends Seeder 4 { 5 p u b l i c f u n c t i o n run ( ) 6 { 7 DB: : t a b l e ( u s e r r o l e s ) >i n s e r t ( 8 array ( 9 array ( name => admin, s o r t i d =>0), 10 array ( name => user, s o r t i d =>1), 11 array ( name => l o g g e r, s o r t i d =>2), 12 ) ) ; 13 } 14 } Linje 3 er klassedefinisjonen som inneholder extends Seeder som forteller rammeverket at klassen er en seed. 196

197 Linje 7 beskriver hvilken tabell det skal settes inn i. Linje 9 og utover inneholder data som legges inn i tabellen. Se neste avsnitt for knytningen mellom modellene og databasen Eloquent Eloquent 43 er en databaseimplementasjon som gjør om vanlige modeller til databasemodeller. Dette gjøres ved å extende Eloquent i tillegg til å definere modellenes relasjoner til andre modeller. Definisjonene av modellene er metoder som kan kalles på for å hente ut informasjon fra databasen, uten å gjøre en direkte spørring mot databasen. Metodene returnerer et resultat man kan løpe gjennom og vise. Det finnes også flere statiske funksjoner som for eksempel all () som tilsvarer select * from tabell tilhørende modell. Kodesnutter 8.7: Bankaccount-modellen med Eloquent-metoder 1 <?php 2 3 c l a s s Bankaccount extends Eloquent { 4 5 // Regler f o r i n put 6 7 p u b l i c s t a t i c $ r u l e s = array ( 8 number => r e q u i r e d d i g i t s : 1 1, 9 ) ; // Database informasjon & 12 // Eloquent R e l asjoner p r o t e c t e d $ t a b l e = bankaccounts ; p u b l i c f u n c t i o n customer ( ) { 17 return $ t h i s >belongsto ( Customer ) ; 18 } // Factory muffing 21 // Benyttes sammen med e n h e t s t e s t i n g p u b l i c s t a t i c $ f a c t o r y = array ( 24 customer id => f a c t o r y Customer, 25 number => ,

198 26 primary => 0, 27 ) ; 28 } Linje 3 inneholder klassedefinisjonen hvor klassen extender Eloquent. Linje 7-9 benyttes til regex på input når en ny bankkonto skal registreres. Dette er en static metode slik at man ikke trenger å opprette et bankobjekt for å bruke metoden. Linje 14 til 18 beskriver relasjonen til andre modeller. Det er dette punktet som må gjøres for å få modellene til å fungere som databasemodeller med Eloquent. Ved større klasser som User og Customer er det flere relasjonsdefinisjoner. Linje innholder et array som kun benyttes i forbindelse med enhetstesting. Les mer om dette arrayet i testdokumentasjonen Mange-til-mange-relasjoner For å muliggjøre mange-til-mange-relasjoner med Eloquent er tabellene som blir opprettet i migration nødt til å følge en viss syntaks 44. Vi har flere slike relasjoner i webapplikasjonen, for eksempel at en ansatt kan være med på mange arrangementer, og et arrangement kan ha mange ansatte. Kodesnutter 8.8: Utsnitt fra User p u b l i c f u n c t i o n events ( ) { 4 return $ t h i s >belongstomany ( Calendarevent ) ; 5 }

199 Kodesnutter 8.9: Utsnitt fra Calendarevent p u b l i c f u n c t i o n u s e r s ( ) { 4 return $ t h i s >belongstomany ( User ) ; 5 } Figurene viser hvordan denne relasjonen er definert i hver enkelt modell, og ved å kalle på en ansatts funksjon events() vil man få returnert alle arrangementer den ansatte er med i. Tilsvarende returnerer metoden users() alle ansatte som er med på et arrangement. For å muliggjøre dette er relasjonstabellen nødt til å ha en bestemt syntaks. I dette konkrete eksempelet er det en mange-til-mange-relasjon mellom modellen Calendarevents og Users. For at dette skal fungere må relasjonstabellen hete calendarevent user. Syntaksen tilsier at man fjerner flertallsendingen s fra modellene og setter de sammen med en understrek. Det er også viktig at det kommer i alfabetisk rekkefølge, som medfører at tabellen for eksempel ikke kan navngis som user calendarevent. Inne i relasjonstabellen må fremmednøklene defineres, og kalles modellnavn id, i dette eksempelet user id og calendarevent id (det går eventuelt å ha andre navn på fremmednøklene i relasjonstabellen, men da må dette spesifiseres ved definisjonen av relasjonene i hver enkelt modell). Når dette er gjort vil Eloquent automatisk generere databasespørringer som henter ønsket innhold ved bruk av metodene events() og users() Softdeletes I alle tabeller (med unntak av noen relasjonstabeller) er det lagt inn mulighet for softdelete som kaller på Eloquent-metoden delete(). Denne setter deleted at i databasen til et tidspunkt som viser til når objektet ble slettet. Når et objekt slettes på denne måten vil det fortsatt ligge i databasen, i motsetning til en harddelete som fysisk fjerner oppføringen i databasen. I webapplikasjonen er dette kun tatt i bruk for ansatte, ettersom dette var mest prekært med tanke på å slette en ansatt om den for ekspempel sluttet og dermed ikke lenger kan logge inn i webapplikasjonen. 199

200 For videreutvikling av webapplikasjonen kan imidlertid softsletting implementeres for alle andre modeller slik databasen er satt opp. Grunnen til at det benyttes softdeletes er for å beholde relasjonene i databasen slik at sletting av en ansatt ikke innebærer sletting av alle objekter som denne ansatte er/var knyttet til. Om en slik hard delete hadde blitt gjort ville alle kontrakter og arrangementer den ansatte var knyttet mot blitt korrupte. Komplett oversikt over alle modeller og deres relasjoner kommer frem av figur i produktdokumentasjonen. 8.9 Views Innledning Innenfor views-mappen er det flere submapper som innholder views til forskjellig funksjonalitet i webapplikasjonen. De to viktigste mappene med tanke på funksjonaliteten ligger undermappene i useractions og customeractions som viser til de forskjellige handlingene i webapplikasjonen (se produktdokumentasjonen for nærmere informasjon om handlingene). Begge disse undermappene har igjen sine undermapper som er bygget opp i et hierarki som gjenspeiler den visuelle presentasjonen av handlinger i webapplikasjonen. Undermappen layouts inneholder maler for designet på webapplikasjonen, mens de resterende viewene (med noen unntak)kun genererer views som settes inn i malens innholdsområde som i HTML er en div som heter view content. Både layouts og bruken av Blade som benyttes for presentasjon av views er nærmere beskrevet senere i appendikset Mappestruktur for views Tilsvarende oppdeling av views finnes også for customeractions. De røde varselindikatorene skyldes kode som er gyldig for rammeverket men som Netbeans tolker som ugyldig syntaks. 200

201 Figur 8.2: Mappestruktur for views customeractions inneholder views for alle kundehandlingene i webapplikasjonen. dashboardtiles inneholder views som lager flisene data blir representert i på webapplikasjonens oppslagstavle. s inneholder maler på eposter som sendes ut i forbindelse med signert kontrakt. includeforms inneholder deler av views som brukes inne i HTMLforms for å kunne gjenbruke koden i flere HTML-forms (Se avsnittet for gjenbruk nedenfor). includes inneholder deler av views som kan benyttes i andre views for å gjenbruke kode (Se avsnittet for gjenbruk nedenfor). layouts inneholder Masterviews for webapplikasjonens design. password inneholder views som benyttes i glemt passord-funksjonaliteten. static inneholder views som benyttes i forbindelse med layouts, samt menyer som brukes gjennomgående i webapplikasjonen. 201

202 useractions inneholder views for alle ansatthandlingene i webapplikasjonen (Blir nærmere beskrevet i neste avsnitt). users inneholder views som benyttes i forbindelse med UsersController (Se avsnittet for Controllers) Views for ansatthandlinger(useractions) Useractions er igjen delt opp i to, en mappe for profile som gjelder alle views tilknyttet en ansatts profil, og general som inneholder views for resterende funksjonalitet. Alle mappene som ligger under profile har navn som gjenspeiler ansatthandlinger og er hovedviews. For General er det samme struktur, men navn på actions kommer et hakk dypere inn i hierarkiet. Figur 8.3: Mappestruktur for useractions Mappene som har samme navn som en ansatthandling, og er et hovedview har en fil som heter det samme som mappen, med endelsen blade.php (Blade blir nærmere beskrevet senere i appendikset). Dette er viewet som 202

203 inneholder den visuelle presentasjonen av ansatthandlingen. I samme mappe er det også en undermappe som heter subviews som inneholder views til ansatthandlingen som er underviews til tilhørende hovedview Gjenbruk For å ha et helhetlig uttrykk på webapplikasjonen finnes det to mapper, includes og includeforms som inneholder deler av views som gjenbrukes i andre views. Dette brukes blant annet til å liste opp kunder, kontrakter og ansatte, slik at listingen er lik uansett hvor man i webapplikasjonen ønsker å liste opp innhold Controllere Generelt om controllere 1. BaseController er rotcontrolleren som alle andre controllere arver. Denne controlleren setter layouten. 2. UsersController benyttes for funksjonalitet utenom de to handlingssettene i webapplikasjonen. Den autentiserer de ansatte med innlogging/utlogging, samt viser oppslagstavlen etter innlogging, hvor ansatte for oppsumert data for bedriften. 3. RemindersController benyttes i forbindelse med Glemt passord -funksjonen. 4. JsonController benyttes for å få returnert data i Json-format og for søkefunksjon. 5. UsersActionController inneholder all funksjonalitet tilknyttet ansatthandlinger. 6. CustomerController inneholder all funksjonalitet tilknyttet kundehandlinger UsersAction- og CustomerController Kjernen i webapplikasjonen, handlingssettene ansatthandligner og kundehandlinger har hver sin controller som er satt opp på samme måte. De har begge to public GET-metoder, action og identifier som nevnt i avsnittet 203

204 om Routes (avsnitt 8.7), en private for hver handling, samt public POSTmetoder for alle handlinger med HTML-forms. Forskjellen på metodene action og identifier er at sistnevnte benyttes med handlinger som er id-avhengige, at det spesifiseres en id om objektet som skal vises eller behandles (se produktdokumentasjon for mer informasjon om dette), mens action behandler handlinger som ikke trenger spesifisert id. UsersActionController identifier Kodesnutter 8.10: Metoden identifier fra UsersActionController 1 p u b l i c f u n c t i o n i d e n t i f i e r ( $custid, $action, $id ) { 2 $viewdata=n u l l ; 3 // Tester om e t t e r s p u r t a c t i o n f i n n e s 4 try { 5 $viewdata = call user func array ( array ( $ t h i s, db. $ a c t i o n ), array ( $custid, $id ) ) ; 6 } 7 // Om funksjonen i k k e f i n n e s g i s t i l b a k e m e l d i n g 8 catch ( BadMethodCallException $bmce ) { 9 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( message =>Lang : : get ( feedback. n o t a c c e s s i b l e a c t i o n, array ( a c t i o n =>Lang : : get ( c u s t a c t i o n s.. $ a c t i o n ) ) ), message type => f a i l ) ) ; 10 } ; 11 // Om metode har r e t u r n e r t n u l l er det sendt med en u g y l d i g ID 12 i f ( $viewdata==n u l l ) 13 return Redirect : : to (URL : : p r e v i o u s ( ) ) >with ( array ( message =>Lang : : get ( feedback. i n v a l i d g e n e r a l i d, array ( id =>$id ) ), message type => f a i l ) ) ; 14 // Om metode har r e t u r n e r t noe annet enn e t array er det en r e d i r e c t som r e t u r n e r e s v i d e r e 15 i f ( gettype ( $viewdata )!= array ) 16 return $viewdata ; // Om ingen av t i l f e l l e n e over har s k j e d d s e t t e s view og subviews med s i n data 19 foreach ( $viewdata a s $vd ) { 20 $viewname = $vd [ viewname ] ; 21 $viewarray = $vd [ viewarray ] ; 22 i f ( $viewarray!= n u l l ) 204

205 23 $ t h i s >layout >content [ ] = View : : make( $viewname, $viewarray ) ; 24 else 25 $ t h i s >layout >content [ ] = View : : make( $viewname ) ; 26 } // S e t t e r v a r i a b l e r som d e l e s f o r h e l e v i e w e t ( i n k l u d e r t subview ) 29 $layoutarray=array ( ) ; 30 $layoutarray [ id ]= $id ; 31 $layoutarray [ c u s t i d ]= $ c u s t i d ; 32 $layoutarray [ customer ]=Customer : : f i n d ( $ c u s t i d ) ; 33 $layoutarray [ p a g e t i t l e ]= u cfirst ( Lang : : get ( c u s t a c t i o n s.. $ a c t i o n ) ) ; 34 $layoutarray [ menu item array ]= HorizontalMenu : : viewcustomer ( Auth : : user ( ) >id, $ c u s t i d ) ; 35 View : : share ( $layoutarray ) ; 36 } Linje 1 definerer funksjonen og dens parametre. $custid er kunde-id, $action er navnet på ansatthandlingen, og $id er id til det spesifikke objektet som skal behandles/endres. Linje 4-6 kaller på en privat funksjon som heter db action og sender med $custid og $id som paramentre. (Se kodesnutt 8.10). Linje 8-10 slår inn om funksjonen beskrevet ovenfor ikke eksisterer, dette skjer om brukeren sender en request direkte på et underview. Brukeren blir da sendt tilbake med feilmelding. Linje 12 tester om resultatet av den private funksjonen er null, dette indikerer at $id som ble sendt inn til en private funksjonen ikke var gyldig. Brukeren blir da sendt tilbake med feilmelding. Linje 15 Tester om resultatet av den private funksjonen er noe annet enn et array, om så er tilfelle skal resultatet returners. Dette skjer i de private funksjonene som skal vise filer i netleseren, eller laste ned filer. På Linje skjer i normale tilfeller når hovedviews og underviews skal returneres til brukeren. (Se kodesnutt 8.10 for eksempel på en privat funksjon). Den private funksjonen returnerer et array med de forskjellige viewene som skal presenteres for brukeren. Disse linjene itererer over dette arrayet og setter det som en del av innholdsarrayet i layouten. Linje Setter variabler som skal være tilgjengelige for alle views som returneres, både hovedview og underviews. 205

206 UsersActionController db viewusers Kodesnutter 8.11: Funksjonen db viewusers i UsersActionController 1 p r i v a t e f u n c t i o n db viewusers ( ) { 2 // Viewmapper 3 $viewfolder = u s e r a c t i o n s. g e n e r a l. user. viewusers. ; 4 $viewsubfolder = $viewfolder. subviews. ; 5 6 // Hovedview 7 $actionname = v iewusers ; 8 $viewdata = array ( ) ; 9 $viewdata [ ] = array ( viewname =>$viewfolder. $actionname, viewarray =>array ( 10 u s e r s =>User : : a l l ( ), 11 v i e w t i t l e =>Lang : : get ( $ t h i s >l a n g F i l e. $actionname ) ) ) ; // Underviews 14 $actionname = v i e w d e l e t e d u s e r s ; 15 i f ( Auth : : user ( ) >hasaccess ( $actionname ) ) { 16 $viewdata [ ] = array ( viewname =>$viewsubfolder. $actionname, viewarray =>array ( 17 u s e r s =>User : : onlytrashed ( ) >get ( ), 18 v i e w t i t l e =>Lang : : get ( $ t h i s >l a n g F i l e. $actionname ) ) ) ; 19 } 20 return $viewdata ; 21 } Linje 1 er funksjonsdefinisjonen. Ettersom denne funksjonen ikke får inn en $id som parameter er det GET-funksjonen action som behandler denne. Linje 3 og 4 defineres viewsmappene for viewusers. Dette er samme mappestruktur som beskrevet i avsnitt Linje 7-11 Definerer hovedviewet, og legger all data viewet trenger i variabelen $viewdata. For hovedviewet er det ingen test på brukerens tilgangsnivåer, da dette allerede er sjekket i Filters (Se punkt 8.6). Linje Legges det til eventuelle underviews, i dette tilfellet er det kun et underview som heter viewdeletedusers. Linje 15 kaller på den innloggede brukerens funksjon hasacccess($actionname) som returnerer true om brukeren har tilgang, false ellers. På denne måten blir variabelen $viewdata fylt opp i forhold til den innloggede brukers tilganger. 206

207 Linje 20 returneres arrayet med views som behandles videre i funksjonen action på samme måte som linje i kodesnutt Sikkerhetsfaktorer Filaksess Som beskrevet i produktdokumentasjonen, avsnitt la vi stor vekt på at filer ikke skulle kunne aksesseres direkte, men det er laget forskjellige handlinger som fungerer som viewers. Alle handlinger som viser en fil i nettleseren er implementert med samme funksjon i biblioteket Helpers. Funksjonen heter fileviewer som vist i sin helhet i kodesnutten under. Ved å aksessere filene på denne måten er det ikke mulig for brukeren å se den fysiske plasseringen av filen på serveren. Kodesnutter 8.12: Funksjonen fileviewer i biblioteket Helpers 1 p u b l i c s t a t i c f u n c t i o n f i l e v i e w e r ( $path, $contenttype=n u l l ) { 2 i f (! f i l e e x i s t s ( $path ) ) return f a l s e ; 3 4 i f ( $contenttype!= n u l l ) { 5 $content = file get contents ( $path ) ; 6 return Response : : make( $content, 200, array ( content type =>$contenttype ) ) ; 7 } 8 else { 9 $content = F i l e : : get ( $path ) ; 10 $ t e s t = new \Symfony\Component\ HttpFoundation \ F i l e \ UploadedFile ( $path, $path ) ; 11 $mime = $ t e s t >getmimetype ( ) ; 12 return Response : : make( $content, 200, array ( content type =>$mime) ) ; 13 } 14 } Linje 1 er klassedefinisjonen og har en paramenter $path, og en valgfri parameter $contenttype. Siste parameter sendes med om man ved hva slags MIME type (Filtypebeskrivelse) filen som skal vises har. Linje 2 returnerer false om filen på gitt lokasjon ikke finnes. Linje 4 til 7 returnerer filen til nettleseren om $contenttype er spesifisert. 207

208 Linje 8-13 returnerer filen til nettleseren om $contenttype ikke er spesifisert. Linje 11 finner MIME type som tilsvarer $contenttype når den ikke er spesifisert som parameter Backdoor Et problem vi opplevde i webapplikasjonen som en backdoor forbi sikkerhetsmekanismene var ved ansatthandlingen grantactions. Denne ansatthandlingen gir ansatte mulighet til å gi andre ansatte nye rettigheter. Om en rådgiver får tildelt ansatthandlingen grantactions kunne den tidligere gi seg selv og andre tilgang på ansatthandlinger den selv ikke hadde. Dette ble løst ved at man via grantactions kun kan gi tilleggsrettigheter man har i kraft av sin egen ansattrolle SorteringsID Et annet problem som også gjorde webapplikasjonens sikkerhetsmekanismer sårbare var om en rådgiver for eksempel fikk tildelt ansatthandlingen changerole, så kunne den endre seg selv til administrator, og nedgradere en faktisk Administrator. Dette løste vi ved å implementere en sorteringsid i blant annet userrole som også er synlig for seed av tilhørede tabell i kodesnutt 8.5. På denne måten kan man kun endre ansattrolle for en bruker om man selv har en høyere, eller likt rangert ansattrolle. Kodesnutter 8.13: Funksjonen canchangerole($user id) i Usermodellen 1 p u b l i c f u n c t i o n canchangerole ( $ u s e r i d ) { 2 $ s o r t i d = User : : getuser ( $ u s e r i d ) >u s e r r o l e ( ) > f i r s t ( ) >s o r t i d ; 3 return $ s o r t i d >= $ t h i s >u s e r r o l e ( ) > f i r s t ( ) >s o r t i d ; 4 } Det er også laget en metode som står som utkommentert, men gyldig kode i modellen for ansattroller som er en metode for å sette inn en ny ansattrolle med en gitt rangering. Denne metoden endrer på de andre ansattrolene som kommer etter den nye rollen slik at rangeringen blir endret i databasen. Kodesnutter 8.14: Funksjonen addrole() i Usermodellen 208

209 1 p u b l i c s t a t i c f u n c t i o n addrole ( $ s o r t P o s i t i o n, $rolename ) { 2 $ r o l e s = U s e r r o l e : : orderby ( s o r t i d, ASC ) >get ( ) ; 3 $ l a s t I n d e x = count ( $ r o l e s ) 1; 4 $ h i g h e s t S o r t I d = $ r o l e s [ $ l a s t I n d e x ] > s o r t i d ; 5 i f ( $ s o r t P o s i t i o n > $ h i g h e s t S o r t I d ) 6 $ s o r t P o s i t i o n = $ h i g h e s t S o r t I d +1; 7 e l s e i f ( $ s o r t P o s i t i o n <= 0) 8 $ s o r t P o s i t i o n = 1 ; 9 10 for ( $ i=$ l a s t I n d e x ; $ i >= $ s o r t P o s i t i o n ; $i ){ 11 $ r o l e = U s e r r o l e : : f i n d ( $ r o l e s [ $ i ] >id ) ; 12 $ r o l e >s o r t i d ++; 13 $ r o l e >save ( ) ; 14 } 15 $newrole = new U s e r r o l e ; 16 $newrole >name=$rolename ; 17 $newrole >s o r t i d=$ s o r t P o s i t i o n ; 18 $newrole >save ( ) ; 19 } 8.12 Ting vi kunne gjort annerledes og forbedringspotensiale Databasemodell Med modeller som benytter Eloquent slik som vi har benyttet i webapplikasjonen kan man ved en kunde hente ut fornavn ved å bruke kommandoen $user >firstname ettersom firstname er et felt i databasen. Dette kan skape utfordringer om man senere skulle ønske å endre databaseimplementasjon. Vi burde laget GET-metoder for alle felter i databasen istedenfor å kalle direkte på feltene, alternativt delt opp i en databasemodell og en modell menyttet for interaksjon med controllere Flere controllere Ved å legge alle ansatthandlinger i en controller, og alle kundehandlinger i en annen har disse controllerne blitt veldig lange med mange linjer kode. Dette kan til en viss grad bli uoversiktlig for å finne frem til metoden man skal 209

210 gjøre endringer på. Ved for eksempel å ha en ContractController, CalendareventController og lignende kunne vi ha fått en mer ryddig struktur i funksjonene. Grunnen til at dette ikke ble gjort var den dype forankringen i handlinger i webapplikasjonen som også gjorde dette som et naturlig skille for controllere. En eventuell oppstykking av controllere senere i utviklingen kunne skapt brister i sikkerhetsmekanismene som er vitalt for webapplikasjonen Design I denne delen gåes det mer teknisk gjennom hvordan de tekniske ressursene knyttet til design er utformet i webapplikasjonen Layouts For å enklere holde styr på de forskjellige sidene og for å spare oss selv for arbeid valgte vi å bygge opp applikasjonen ved hjelp av layouts. Dette vil si at vi har en side som inneholder både statisk og dynamisk informasjon, der den dynamiske informasjonen er de forskjellige sidene i applikasjonen ( legg til kunde, vis kontrakt og liknende). I disse layoutene er det lagt opp til at tilbakemeldinger kan vises og i tillegg vil de innholde forskjellige elementer avhengig av hva som mottas fra controlleren. Hvis en tilbakemelding skal vises må det sjekkes om det er satt en Session-variabel på den aktuelle siden, se kodesnutt Hvis toppmenyen skal vises sendes denne og menyelementer fra controlleren. Se kodesnutt 8.14 Kodesnutter 8.15: Sjekk for tilbakemeldinger ( S e s s i o n : : has ( message ) ) 2 <div class= message {{ S e s s i o n : : get ( message type ) }} > 3 4 <button type= button class= c l o s e c l o s e {{ S e s s i o n : : get ( message type ) }} data d i s m i s s= a l e r t aria hidden= true >&times ;</button> 5 <h2>{{lang : : get ( v a l i d a t i o n. e r r o r m e s s a g e.. S e s s i o n : : get ( message type ) ) }}</h2> 6 <ul> 7 {{ S e s s i o n : : get ( message ) }} 210

211 ( $ e r r o r s >a l l ( ) as $ e r r o r ) 9 < l i>{{ $ e r r o r }}</ l i> endforeach 11 </ ul> 12 </ div> Kodesnutter 8.16: Sjekk for toppmeny og elementer 1 <div class= p a g e s e c t i o n horizontal menu {{ i s s e t ( $menu item array )? v i s i b l e : }} > 2 <nav> ( i s s e t ( $menu item array ) ) ( $menu item array as $item ) 5 // s k r i v e r ut menyelementer her endforeach </ nav> 10 </ div> Applikasjonen er bygget opp av følgende to layouter som brukerne ser: login.blade.php Dette er layouten som viser logg inn, glemt passord og bytt passord. Se 8.4 for oppbygging. default.blade.php Dette er layout som viser alt det en innlogget bruker ser som menyer, søkefelt og alle applikasjonens handlingers sider. Se 8.5 for å se oppbygging Blade I sammenheng med rammeverket som applikasjonen bygger på, Laravel, har vi tatt i bruk Blade. Blade er en såkalt templating engine, som gjør det lettere å håndtere flere sider med minst mulig kode, da Blade belager seg på å hente inn ( inkludert ) innhold etter diverse parametre. Ved å sette opp et utgangspunkt, en layout med statiske og dynamiske deler, trenger vi kun å forholde oss til én fil for flere sider, isteden for én til alle sidene. Dette gjorde at vi i applikasjonen kun trengte å ha to hovedsider med dynamisk innhold. I vårt prosjekt gjorde Blade det lettere for oss å gjøre følgende: Lage god struktur på sider og hente de lettere ved å ta i bruk mappe.side ) 211

212 Figur 8.4: 1. Eventuelle tilbakemeldinger skrives ut her 2. Her endrer innholdet seg Figur 8.5: 1. Statisk topp 2. Eventuell toppmeny vises her 3. Eventuelle tilbakemeldinger kommer her 4. Dynamisk innhold, alle applikasjonens handlingers sider Skrive ut objekter og dets datafelter ved å ta i bruk syntaksen {{$objekt >datafelt}} Kjøre tester og løkker på objekter og dets datafelter for å tilpasse 212

213 innhold, ved å ta @for(uttrykk) og ev. andre løkker. Hente ut data fra en database ved å ta i bruk syntaksen Modell::find( indeks) >datafelt som eksempel. Merk! Dette er ikke anbefalt da det ikke følger MVC-strukturen i vår applikasjon. Dette bør holdes til et minimum. For at en fil skal tolkes som en Blade-fil og lese Blade-syntaksen må filen lagres med endelsen.blade.php. Hvis filen ikke er lagret i dette formatet vil ikke koden tolkes, og vil bare bli lest som vanlig tekst. Der man vil utføre operasjoner på et objekt som kommer fra controlleren må all denne koden rammes inn i {{ og }} med unntak av nøkkelord som starter I tillegg har Blade en hel rekke hjelpefunksjoner som generer HTML-kode for deg. Det å lage en lenke til en annen side kan f.eks. gjøres på denne måten HTML::link ( lenke/til/view, Klikk her, $attributter = array(), $secure = null ) hvor attributter er HTML-nøkkelord som id, klasser o.l. og secure er om lenken skal kryptere overføringen eller ikke. Kodesnutter 8.17: Blade-eksempel 1 <div class= content > ( content. main content ) <! Henter n e t t s i d e n main content. b l a d e. php f r a mappen content > 3 4 <p>her kan {{ $bruker >fornavn }} hentes f r a k o n t r o l l e r e n</p> 5 ( $bruker >fornavn == ) 7 <p>brukeren har ikke fornavn</p> 9 <p>brukeren har et fornavn</p> <p>vi kan i t i l l e g g hente ut {{ Ordre : : f i n d ( $bruker > ordrenummer ) >ordresum }} r e t t f r a databasen.</p> </ div> viser eksempler på dette sammen med HTML-kode. 213

214 Makroer I tillegg til Blade og Laravels hjelpefunksjoner er det også mulig å lage sine egne funksjoner, også kalt makroer. Dette var spesielt fordelaktig for oss ved gjentakende operasjoner, f.eks. ved utskrift av søkeresultater eller menyelementer. Ved å definere en funksjon som skriver ut info på en gitt måte er det mye lettere å lese koden som tar i bruk dette og det er raskere enn å skrive det samme gang på gang. Kodesnutt 8.16 viser hvordan vi laget en makro for å vise et menyelement med ikon. Kodesnutter 8.18: Makro-eksempel 1 {{ 2 //Makro f o r l e t t e r e i n n l e g g i n g av menyelementer. 3 4 HTML: : macro ( menu item, f u n c t i o n ( $ l i n k t o v i e w, $icon, $ t e x t ) { 5 return HTML: : decode (HTML: : link ( $ l i n k t o v i e w, <i c l a s s = f a fa. $icon. ></i >. $text., array ( c l a s s => menu item ) ) ) ; 6 }) 7 }} 8 9 //Denne makroen brukes s l i k e t t e r den er d e f i n e r t {{ HTML: : menu item ( l i n k / t i l / view, user icon, Brukerinformasjon ) }} Visualisering På brukerens Oppslagstavle er det en visualisering av forskjellige typer informasjon presentert gjennom kakediagrammer. Disse diagrammene er hentet fra Google Charts 45 og er gratis å bruke. For å vise diagrammet må man ta i bruk JavaScript, og man må lage sine egne funksjoner (hvis Google s ikke er tilstrekkelige) for å vise dataen på riktig måte. I denne webapplikasjonen hentet vi den informasjonen vi trengte fra databasen gjennom en controller som sendte den ønskede informasjonen tilbake i JSON-format. På denne måten fikk vi hentet inn et nøkkel-verdi-par fra JSON-strengen og skrevet dette ut i JavaScript og brukt Google Charts for å visualisere

215 dataene. Kodesnutt 8.17 viser hvordan vi tok i bruk Google Charts for å presentere data. Kodesnutter 8.19: Visualisering med Google Charts 1 f u n c t i o n drawspecificchart ( type ) { 2 $. getjson ( u r l [ 0 ] + / p u b l i c / + type + j s o n, f u n c t i o n ( data ) { 3 4 var div name = type + c h a r t d i v ; 5 6 var c h a r t d a t a = new google. v i s u a l i z a t i o n. DataTable ( ) ; 7 8 c h a r t d a t a. addcolumn ( s t r i n g, type + type ) ; 9 c h a r t d a t a. addcolumn ( number, amount ) ; $. each ( data, f u n c t i o n ( key, val ) { 12 c h a r t d a t a. addrows ( [ [ key, val ] ] ) ; 13 }) ; var c o l o r s = [ #1C8590, #3fb1bd, #219daa ] ; var o p t i o n s = { 18 width : 200, 19 height : 150, 20 c o l o r s : c o l o r s, 21 legend. p o s i t i o n : bottom, 22 t e x t S t y l e : { c o l o r : #333, f o n t S i z e : 50 px, fontname : Myriad Pro }, 23 backgroundcolor : none, 24 chartarea : { width : 100%, h eight : 100% } 25 } ; var chart = new g oogle. v i s u a l i z a t i o n. PieChart ( document. getelementbyid ( div name ) ) ; 28 chart. draw ( chart data, o p t i o n s ) ; 29 }) ; 30 } Hvis denne funksjonen s k a l hente ut kundedata k a l l e s den s l i k : drawspecificchart ( customer ) ; Funksjonen henter den JSON-formaterte arrayen fra URL en public/<type> json. Det lages så en HTML-boks med tilhørende navn hvor dataen skal visualiseres, chart div. For-each-løkken legger innhold i en tabell og chart.draw( 215

216 chart data, options) er ansvarlig for selve visualiseringen. var options-variabelen er kun for visuelle endringer som skriftstørrelse, farger, høyde og liknende Ikoner Alle ikoner i applikasjonen er hentet fra open source-prosjektet Font Awesome versjon 4.1.0, og implementeres lett til nettstedet med én linje i head-taggen. Alle ikoner er i vektorgrafikk og egner seg veldig godt til opp- og nedskalering i størrelse uten tap av kvalitet. Et ikon kan plasseres som et hvilket som helst HTML-element ved å skrive <i class= fa fa icon ></i>, der icon er det valgte ikonet. Ikonene kan få stilregler som størrelse, farge, plassering o.l. gjennom vanlig CSS og vi så derfor at dette var meget hensiktsmessig for oss å ta i bruk. På Font Awesome sine nettsteder finnes en oversikt over alle ikoner. Kodesnutt 8.18 viser hvordan vi har tatt i bruk ikoner i denne applikasjonen, hvor kodesnutt 8.18 viser hvordan dette tolkes og vises av en internettleser. Kodesnutter 8.20: Ikoneksempel 1 <head> 2 <! Denne l i n j e n henter i koner f r a Font Awesome > 3 <link href= // netdna. bootstrapcdn. com/ font awesome / / c s s / font awesome. min. c s s rel= s t y l e s h e e t > 4 </head> 5 <body> 6 7 <h1> <i class= f a fa user ></ i> O v e r s k r i f t med brukerikon </h1> 8 <button> <i class= f a fa copy ></ i> Knapp med et kopi ikon</ button> 9 10 </body> Figur 8.6: Reultat av koden i kodesnutt

217 Bruk av CSS-filer CSS-filer spiller en meget stor rolle i webapplikasjonen. Et godt design var nødvendig for god brukervennlighet og vi gjorde vårt ytterste for å utnytte de mulighetene vi hadde med posisjonering, farger, tekststørrelser og oppførsel blant annet. I vår applikasjon valgte vi å bruke CSS3, imidlertid kan dette føre til at visse regler ikke vil fungere på eldre nettlesere. Dette vil likevel ikke sette en stopper for applikasjonens funksjonalitet, da alle brukerne til applikasjonen har oppdaterte nettlesere. For å lettere finne frem til riktig CSS-fil valgte vi å dele opp all CSS-kode i flere filer, med logiske navn i forhold til hva de styrte. Listen under viser en oversikt over disse og hvilke deler av webapplikasjonen de er ansvarlige for. dashboard.css Har ansvar for designet på sidene etter man er logget inn. jquery.datetimepicker.css Har ansvar for designet til vår valgte jquerykalender plug-in. login.css Har ansvar for innloggingsskjermen samt glemt- og bytt passordskjermen. menus.css Har ansvar for menyer i applikasjonen som hoved-, bruker- og toppmeny. responsive.css Har ansvar for egne stilregler ved smarttelefon- og nettbrettvisning. style.css Har overordnet ansvar for stilregler til paragrafer, lenker, knapper og alt annet generelt. userbar.css Har ansvaret for spesielle elementer i brukermenyen. variables mixins.css Inneholder regler for gjenbruk av CSS-kode. Les mer under avsnitt om LESS.css CSS Media-queries Siden vi valgte at webapplikasjonen skulle være brukbar på smarttelefon og nettbrett måtte vi tilpasse oss de skjermer som leveres til denne. I CSS3 finnes det media queries som lar deg legge til eller overstyre visse regler 217

218 basert på skjermstørrelse. Kodesnutt 8.19 viser hvordan vi har tatt i bruk dette i applikasjonen. Kodesnutter 8.21: Media queries 1 / Disse r e g l e n e v i l o v e r s t y r e andre r e g l e r ved en skjermbredde under 650 px / 2 s c r e e n and (max width : 650px ) { 4. p a g e s e c t i o n { 5 margin l e f t : 1.25em! important ; 6 margin r i g h t : 1.25em! important ; 7 } 8. l o g i n w r a p p e r { 9 width : 50%! important ; 10 } 11. d a s h b o a r d t i l e { 12 d i s p l a y : block ; 13 width : 100%; 14 } 15. c u s t i n f o w r p { 16 width : 100%; 17 } 18 } LESS.css LESS.css er en CSS pre-prossesor, som betyr at den utvider eksisterende CSS kode med mulighet for variabler, funksjoner, regneoperasjoner og mye annet. Dette gjør det mye enklere å skrive, vedlikeholde og gjenbruke. LESS.css tolker og gjør om.less-filer til tilhørende.css filer som internettleseren kan tolke og forstå. Man må ha en LESS-kompilator innstallert på maskinen koden skrives på for at dette skal fungere, i tillegg til å referere til en JavaScriptfil på nettsiden. Kodesnutt 8.20 viser hvordan man implementerer dette i head-taggen på nettstedet. Man vil da ende opp med én.less-fil med en tilhørende.css-fil, hvorpå det er denne internettleseren klarer å tolke og kun den det trengs å refereres til. Les mer om de forskjellige funksjonene i påfølgende avsnitt. 218

219 Kodesnutter 8.22: LESS.css deklarasjon 1 <head> 2 <link rel= s t y l e s h e e t type= t e x t / c s s href= s t y l e. c s s /> 3 <script src= l e s s. j s type= t e x t / j a v a s c r i p t ></ script> 4 </head> Nesting Med nesting menes det at man kan hierarkisk skrive CSS-regler. Dette vil med andre ord si at hvis man skal si at all tekst som er i divisjonen maincontent skal være rød vil man med vanlig CSS skrive #main content p { color :red; }, noe som gjør at koden fort kan bli vanskelig å lese hvis man f.eks. skal legge til egne regler for lenker og andre tagger. Kodesnutt 8.2 viser hvordan dette gjøres i LESS.css, og kan gjøre CSS-kode mer lettleselig. 1 #main content { 2 c o l o r : black ; 3 4 p { 5 c o l o r : red ; 6 } 7 8 a{ 9 c o l o r : blue ; 10 } } Kodesnutter 8.23: LESS.css nesting-eksempel Variabler Ved å lagre f.eks. farger, tekststørrelser, høyde, bredde og liknende i variabler er det mye lettere å gjenbruke disse attributtene på tvers av CSS-filer, i tillegg til at man kan gjøre matematiske operasjoner på disse. I filen variables mixins. less er alle farger, tekststørrelser, teksttyper, margins og paddings lagret og hentes frem hvor det behøves. Dette gjorde det mye lettere å gjenbruke regler ved å ikke måtte huske fargekoder, mål og liknende. Kodesnutt 8.22 viser hvordan vi typisk tok i bruk dette i applikasjonen. 219

220 Kodesnutter 8.24: LESS.css variabel-eksempel 1 / D e k l a r e r e r v a r i a b e l e n / red : #ee0000 ; width : 60em ; 4 5 / Tar i bruk v a r i a b e l e n e / 6. content { 7 c o l o r red ; / #ee0000 / 8 } quarter { 11 width width / 4 ; / 60/4 = 15em / 12 } Mixins Mixin er LESS.css sitt svar på funksjoner. Dette gjør at gjenbruk av en rekke regler gjøres mye lettere ved at man ikke behøver å kopiere eller ev. huske en rekke regler. Dette hadde vi stor nytte av ved elementer i applikasjonen som f.eks. skulle ha egendefinerte skrifttyper, noe som krever 4-5 linjer med CSS-regler. En mixin kan også ta inn en verdi som parameter og operere med denne. Kodesnutt 8.23 viser et eksempel på dette. Kodesnutter 8.25: LESS.css mixin-eksempel 1. ubuntu font = black ) { f a c e { 3 font f a m i l y : Ubuntu ; 4 s r c : u r l (.. / misc / f o n t s /Ubuntu R. t t f ) ; 5 font weight : normal ; 6 font s t y l e : normal ; 7 } 8 font f a m i l y : Ubuntu ; 9 c o l o r ; 10 } / Funksjonen t a e s i bruk s l i k : / main paragraph { 15. ubuntu font(#eee ) ; 16 } I funksjonen over kan man velge å sende med en farge på skrifttypen eller ikke (da vil tekstfargen bli sort). Man ser at dette lager en mye mer lesbar 220

221 kode enn å ha alle de overnevnte linjene for hver gang man skal ha en ny eller bruke en eksisterende skrifttype igjen. 221

222 Denne siden er blank med hensikt.

223 Kapittel 9 Vedlegg Contents 9.1 Prosjektdagbok Fremdriftsplaner Fremdriftsplan for implementering Fremdriftsplan for testing og rapport Møter med oppragsgiver Møte 21.Januar Møte 10.Februar Møte 7.Mars Møte 4.April Brukertest Brukertestoppgaven Resultater brukertest Kildekode og anvisninger til kjørbar versjon For fysisk sluttrapport For digital sluttrapport

224 Denne siden er blank med hensikt.

225 9.1 Prosjektdagbok 225

226 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 2013/2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Prosjektdagbok Lars sender mail til tre bedrifter for å undersøke muligheten for å skrive hovedprosjektoppgave. Disse bedriftene var Accenture, Finn.no og Steria Av de tre bedriftene var det kun Steria som ikke hadde et opplegg rundt hovedprosjektoppgave. Finn.no og Accenture hadde muligheten til dette, og vi skulle sende svar tilbake om hva vi hadde planer om å ha som hovedprosjektoppgave. Hos Accenture måtte vi i tillegg gjennom en litt lengre søkeprosess. Dette hadde vi ikke planlagt på forhånd og sa at vi måtte komme tilbake til de aktuelle bedriftene når vi hadde et klarere svar Simen forhører seg med en bekjent om en mulig prosjektoppgave hos en liten lokal bedrift. Denne bedriften ønsker en løsning av sin håndtering av ulike skjema. Det ønskes at en rekke PDF dokumenter skal kunne lastes opp til en tjenste, som registrere de ulike feltene som skal fylles ut, og gjør disse om til et webskjema, for enklere utfylling. Systemet skal holde rede på en rekke PDF maler, og kunne fylle ut disse raskere enn manuell utfylling for hånd. Bedriften kunne se på dette som en hovedprosjektoppgave, hvis ønskelig av gruppen Gruppen samles for registrering av gruppe, samt utarbeiding og levering av statusrapport.

227 Gruppen samles for å begynne utarbeiding av prosjektskisse. Sender epost til oppdragsgiver for å få avklart punktet for tilgjengelig maskinvare, samt prosjektets plass i oppdragsgivers virksomhet og legger dette til i prosjektskissen. Begynner også utarbeiding av design for nettsiden samt etablering av gruppeside, samt levering av lenke til gruppeside og prosjektskissen Gruppen samles for å starte med prosjektet og utarbeide forprosjekt. Begynner smått med å lage illustrerende figurer og lager private Git repository. Sammen med dette ser vi på å bruke rammeverket CodeIgniter ( Undersøker også muligheten for Zend rammeverk da de ser ut til å ha støtte for manipulering av pdf filer Gruppen samles for å starte med forprosjektrapport og for å legge en plan for jobbingen fremover. Vi konsulterer med oppdragsgiver og veileder for å lettere sette opp overnevnte plan. Vi har også bestemt oss for å bruke den smidige utviklingsmetoden SCRUM, og meldte oss inn i den nettbaserte SCRUM tjenesten Trello.com. Før vi skilte lag fikk vi startet på forprosjektrapporten og laget en foreløpig skisse over denne. Vi har på dette punktet ikke fått svar fra veileder Får svar og mailer videre med veileder og fastsetter første møte i morgen (15.01). Har også fastsatt første møte med oppdragsgiver kommende tirsdag (21.01). Gruppen jobber under hovedpunktet Oppstartsfase hvor vi lager grove skisser til første møte med oppdragsgiver. Mer konkret logg om oppgaver og utført arbeid finnes på Trello som vi har begynt å benytte fra og med i dag under nevnte hovedpunkt Møter veilder for første gang. Innfører og informerer kort rundt prosjektet for veileder. Gruppen kommer også med et par henvendelser tilknyttet forprosjektrapport/linsesbelagte prorgramvarer veileder skal undersøke videre. Veileder ønsker også tilgang til Trello for å kunne se mer konkret fremgang/utviklingsmetode Gruppen møtes først for å sette opp agenda for møte med oppdragsgiver (se MoteAgenda2101.pdf). Møter oppdragsgiver for første gang og får her avklart mye med tanke på punktene i nevnte dokument samt hva de ønsker av den ferdige løsningen. Etter møtet begynner

228 gruppen å skrive et møtereferat av det som ble gjennomgått på møtet. Dette sammen med forprosjektrapporten ferdigstilles senest fredag (24.01). Sender mail til hovedprosjektkoordinator med tanke på rammeverk for applikasjonen og forhører også med tanke på teknisk veileder. Har nå endret fokus fra CodeIgniter/Zend over til Laravel ( som ser ut til å være PHP rammeverket som er i vinden og er mest utbredt i 2013 ( php frameworks 2014/). Sender også mail til veileder for å få avklart kontrakt mellom oppdragsgiver og skolen Gruppen møtes for å ferdigstille møterapport og forprosjektrapporten, samt legger ut dette på gruppenettsiden sammen med møteagendaen. Informerer både oppdragsgiver og veileder om dette. Bestemmer oss også for å gå for PHP rammeverket Laravel Gruppen møtes for å sette opp kravspesifikasjon for prosjektet med prioriteringsgrad. Begynner også å sette opp fremdriftsplan med tidsestimering av kravene for å anslå hva vi kan rekke i løpet av prosjektets periode. Sender mail til veileder om hjelp med tidsestimeringen. Sender også mail til UniWeb hvor oppdragsgiver har webhotell med spørsmål tilknyttet SSL kryptering. Endrer oppdateringstidspunkt av dagbok på gruppesiden til Torsdag/Fredager Gruppen møtes og renskriver kravspesifikasjonen, samt ferdigstiller Fremdriftsplan med tidsestimering av punktene i kravspesfikasjonen. Bestemmer oss også for å utvikle med en ukes sprint, hvilket det legges opp til i fremdriftsplanen. Legger inn første sprint i Fremdriftsplanen, samt i Trello. Til slutt lager gruppen en kort presentajon for morgendagens møte med veileder. Printer i denne forbindelse ut begge dokumentene til veilder Gruppen møter to andre grupper og veileder for felles veiledning og presentasjon av gruppenes prosjekter. Her fikk vi en foreløpig tidsplan for veiledning og fikk oppklaring i noen praktiske spørsmål rundt gjennomføringen av prosjektet. Som nevnt over presenterte vi vårt prosjekt og fikk mange gode innspill fra de andre gruppene samt veileder. Etter dette hadde vi en generell diskusjon i plenum samt ris og ros fra de andre gruppene. I denne sammenhengen utleverte vi også en papirversjon av vår foreløpige fremdriftsplan og forprosjektrapport til veileder.

229 Gruppen møtes for å gjøre klart til første sprint på scrum brettet. Setter opp Git repo og legger til rette for god versjonshåndtering. Fremdriftsplanen sendes til produkteier (Meso) for å ta i betraktning hvordan de stiller seg til de ulike avgjørelsene gruppen tok i sammensetningen av denne Gruppen sender mail til hovedprosjektansvarlig for å få avklart lisenser og testmiljø. Testmiljø, i form av virtuell maskin (unix), må videre taes med Amir. Lisens for Adobe Acrobat Reader Pro, som kan skaffes på enkeltlisens, kan skolen ikke stå til disposisjon med Sender mail til oppdragsgiver og planlegger nytt møte førstkommende Mandag (10.Februar) klokken 11:00. Har nå en design/prototype utkast å vise på møte sammen med at vi må få avklart serversituasjon samt ordne med avtale mellom oppdragsgiver og skole. Oppdaterer Fremdriftsplan med gjennomført sprint, samt planlegging av ny sprint. Legger også til nye kort for neste sprint på Trello Har møte med oppdragsgiver. Gruppen utarbeider i etterkant ut både møteagenda og møtereferat som legges ut på gruppesiden. Legger på møtereferatet også med figurer fra løsningen per i dag tilsvarende slik det ble fremvist på møtet. Sender mail til UniWeb for å få avklart pris på backup av VPS server samt mail til oppdragsgiver med møtereferat og spørsmål tilknyttet hva som skal lagres tilknyttet Prosjekter i løsningen Har møte med veileder hvor vi informerer om nylig møte med oppdragsgiver samt hvordan jobbingen med prosjektet går. Får bra tilbakemeldinger på fremdriftsplan/kravspesifikasjon og får råd om å opprettholde dokumentasjon mens vi jobber ettersom det vil være god dokumentasjon til sluttrapport. Får også VM fra Amir oppe å gå slik at vi nå har et fungerende testmiljø tilsvarende det som den ferdige løsningen skal kjøre på.

230 Har videre dialog med kontaktperson hos oppdragsgiver. De er i dialog med finanstilsynet angående gyldigheten på elektronisk signatur. Det virker som det ikke skal være noe problem å legge på signatur på pdfen. "Snakket med en nå som mente at det ikke skulle være noe problem siden de godkjenner telefon, fax, mail og alt mulig annet skal sende et konkret eksempel til han på mail på mandagen, så skal de prate om det på avdelingen og deretter få et konkret svar. De sa i tilsynet at dette virket veldig innovativt og bra, de hadde ikke hørt om noen som hadde dette fra før så jeg tror at dette virkelig kan være et bra program. " Lager også nye kort i Trello med To do kort til hver enkelt for småoppgaver vi må ordne som ikke faller inn under et aktivt kort. Disse er lagt i hovedkategorien Generelt. Setter også opp ny sprint til kommende uke i Trello Har møte med veilder hvor vi forteller kort om fremdriften i prosjektet. Diskuterer kort det største utfordringen i prosjektet med tanke på gyldig signering av dokumenter. Gruppen har ikke begynt med dette kravet enda, men etter undersøkelser både fra gruppen og oppdragsgiver ser dette ut til å være i orden med tanke på gyldighet. Veilder informerer om fremtidig fremføring av prosjekt både med tanke på produkt og fremgang/dokumentering, informerer om at vi ikke vil ha noe direkte å vise frem før om 3 4 uker. Får også informasjon fra oppdragsgiver at deres nærmeste samarbeidspartner vil skiftes ut og dermed vil også den mest brukte PDF malen byttes ut. Får tilsendt den nye malen som så og si er lik den gamle, og fungerer sammen med resten etter litt modifikasjoner Setter opp nødvendig programvare på testmiljø tildelt fra skolen. Setter også opp laravel rammeverket, og henter en utgave fra Github. Lager en guide for hvordan dette oppsettet kan gjenproduseres ved publisering til oppdragsgiveres systemer.

231 Har møte med oppdragsgiver hvor oppdragsgivers sjef er med på møtet i tillegg til vår kontaktperson. Får avklart mye med tanke på hvordan deres jobbhverdager er, og hvordan vi kan speile dette i resultatet. Særlig gjelder dette krav 29 i kravspesifikasjonen som omhandler opprettelse av en annenhåndsmarkedskontrakt. Får også gitt oppdraggivers lenke til testmiljøet hvor vi jevnlig henter inn nyeste versjon. Møteagende for møtet ligger per dags dato ute på gruppesiden, men møtereferat vil ikke bli laget og publisert før på Mandag (10.03) Har møte med veileder hvor vi mottar signert utgave av kontrakten som vi nå kan gi til oppdragsgiver ved neste møte. Viser status siden forrige møte, samt en rask gjennomgang av nylige møte vi hadde med oppdragsgiver. Vi får også vist prototypen på systemet til veielder for første gang, nå som testmiljøet er oppe og kjører. Vi får informasjon om at vi om fire uker, 9. april, skal ha en fremføring sammen med de to andre gruppene samt veileder for å hovedsakelig få øvd på presentering til selve fremføringen av prosjektet. Vi vil motta nærmere informasjon om dette senere. Etterspør rapportmal / eksempel vi kan forholde oss til når vi skal skrive rapporten. Veileder har ikke noe konkret infromasjon om dette, men anbefaler at vi hører med hovedprosjektkoordinator. Vi kommer i møtet så vidt frem til en grov skisse, selv om vi mangler informasjon om hva del 1 (under) skal inneholde. Gruppen sender mail til hovedprosjektkoordinator i etterkant av møtet i påvente av mer informasjon rundt dette. 1. Selve rapporten om systemet generelt fra et overordnet synspunkt som kan leses og forstås selv om man ikke har mulighet til å gå inn i, og / eller forstå selve koden. 2. Kode / teknisk appendix hvor vi tar for oss rammeverk, oppbygging, enkelte metoder og kode valg. 3. Test appendix hvor vi tar for oss enhetstesting og eventuelt andre tester som gjøres på systemet. 4. Brukerveledning appendix til systemet som beskriver hvordan det brukes i praksis (denne er også aktuell å levere til oppdragsgiver).

232 Oppdragsgiver har fått svar fra Finanstilsynet angående gyldigheten av digitale signaturer som skal brukes i systemet. Det vises til tidligere korrespondanse mellom Finanstilsynet og Meso Capital Markets AS, senest ved deres e post 5. mars Meso Capital Markets AS har forespurt Finanstilsynet om foretaket kan innhente kundenes signatur digitalt. Finanstilsynet kan ikke se at verdipapirhandelloven eller verdipapirforskriften er til hinder for bruk av digital signatur så lenge denne er etterprøvbar på lik linje med alminnelig signatur. Finanstilsynet vil likevel minne om at Meso Capital Markets AS må sørge for at det i henhold til vphl (7) kan dokumentere at det etterlever verdipapirhandellovens krav. Det vil si at tiltenkt signeringsmekanisme vil være gyldig etter dette reglementet. Sender også en mail til oppdragsgiver hvor vi kommer med våre innspill til backupløsningen av systemet. Mailen forklarer at deres tjensteleverandør Uniweb oprerer med en 14 dagers rullerende backup, men at dette ikke vil si at de kun har kontrakter 14dager tilbake i tid, men heller at de har 14 dager fra systemet feiler, til det må oppdages. Forklarer også at systemet som vi produserer kommer med egne funksjoner for å håndtere datatap, da de selv kan ta egne backuper av alle kontraktene de har laget i systemet. Og foreslår at de gjør dette ved en regelmessig basis, for å lagre på en minnepenn, eller annet medium, i en av sine arkiver, med en periodisk hyppighet på 1 2 ganger per år Vår kontaktperson hos oppdragsgiver møtte oss på skolen for å se status og slik at vi også kunne få svar på ting som vi lurte på. På møtet viste vi frem nytt design og hvordan mal utfylling fungerte. I denne prosessen fikk oppdragsgiver svar på deres spørsmål, og konkluderte med at mal utfyllingen så veldig bra ut. For vår del gjenstår fortsatt testing rundt dette, men foreløpig fikk vi god tilbakemelding på det. Oppdragsgiver ønsket å søke etter kunder under kontraktopprettelse, noe som blir løst i nærmeste fremtid. Vår kontaktperson presenterte oss også for en funksjonalitet som vi ikke tidligere hadde kunnskap om. Dette var en slags portal for kunder der de kunne se hvilke, hvor mye andeler og hvor de hadde fondene sine. De enkelte tjenestene som behandler dette krever innlogging, og denne informasjonen vil derfor være utilgjengelig fra vårt system, så vi kom frem til en mulig løsning som kanskje kunne være en erstatning for dette. Denne funksjonaliteten blir imidlertid ikke prioritert nå, og vil ikke være en del av hovedprosjektet. I sammenheng med å sende automatisk mail til de partene som skal ha forskjellige deler av en kontraktinngåelse skal oppdragsgiver i løpet av neste uke sende en mail med hvordan typisk

233 ordlyd og tekst til de forskjellige partene skal være. Derfor blir noen timer til kravet dette gjelder overført til neste sprint Sprint 8 som nå er planlagt til kommende uke er siste planlagte uke med direkte arbeid med produktet, og fører prosjektet videre inn i teststadiet. Vi ser for oss at uke 14 vil bli brukt til å korrigere feil på siden vi opplever fra et brukerståsted, slik at vi senere samme uke kan ha en ferdig prototype vi kan teste på oppdragsgiver og få tilbakemeldinger om feil/endringer som må utbedres/gjøres. Konkretisering av dette vil komme i løpet av neste uke hvor fremdriftsplanen vil oppdateres med nærmere informasjon om planlagt arbeid innenfor testperioden Som planlagt ble sprint 8, siste sprint i utviklingsfasen, fullført og prosjektet går nå inn i teststadiet etter planen. I forbindelse med dette er det opprettet en egen fremdriftsplan for testing og rapportskriving. Dette dokumentet er ment som en tidsplan og hjelp til oss, men vi skal også i denne fasen ha kontinuerlig kontakt med oppdragsgiver for å gjøre eventuelle endringer underveis. I tillegg til fremdriftsplanen har vi laget et nytt SCRUM brett for dette og laget tilhørende sprinter og kort for å fortsette med den samme utviklingsmetodikken. Lenke til dette brettet ligger i filen Fremdriftsplan testing. Neste uke vil hovedsakelig gå ut på forberede systemet til brukertest hos kunden. Fremover ser vi for oss en blanding av forbedring (basert på brukertesten), enhetstesting og rapportskriving. Fremdriftsplanen for implementering er også oppdatert med seneste sprints oppsummering Tar kontakt med oppdragsgiver og avtaler et møte fredag 4.april 2014, hvor vi presenterer prototypen vi ferdigstiller. Samt gir et utvalg av de ansatte i bedriften et oppgavesett for å teste de ulike funksjonene i systemet. Resultatene av disse vil brukes til å strømmlinjeforme systemet etter den daglige aktiviteten i bedriften Vi hadde et møte med oppdragsgiver hvor vi viste frem prototypen som skulle benyttes til kommende brukertest. Møteagendaen ligger på gruppesiden, mens møtereferat kommer i løpet av mandag.

234 Har i samråd med oppgradsgiver bestilt miljø hvor det ferdige produktet skal kjøres. Vi vil da i løpet av kommende periode sette opp dette miljøet, og til slutt implementere vårt prosjekt på dette. Har også fått tilgang til å legge til nye e post kontoer, som skal brukes i utsendingen av e poster fra systemet. Videre har vi samlet inn resultater fra helgens brukertest, som er utført av de ansatte i bedriften. Resultatene av disse ser ved første øyekast veldig konstruktive og gode ut, og vi vil i løpet av de neste dagene bearbeide disse i et eget dokument Vi opprettet et git repository for rapporten til hovedprosjektet. Vi satt opp våre respektive maskiner til å synkronisere til og fra denne mappen, og vi installerte programvare for å skrive i LatTex Gruppen er godt på veg med enhetstesting. Har fullført enhetstesting av alle modeller i webapplikasjonen, men enhetstesting av Controllere gjenstår. Har også gått gjennom og dokumentert tidligere brukertest. I tillegg har gruppen laget et skall til rapporten og skrevet deler av den, men er dette punktet mesteparten av tiden fremover vil gå til Gruppen er ferdig med enhetstesting så langt vi kommer med tanke på tid. Sender mail til koordinator for hovedprosjekt og skolens serveransvarlig. Koordinator har fått spørsmål om tilgang til kildekode for sensor, og serveransvarlig har fått spørsmål om levetid på virituell server mtp sensur av hovedprosjektet. Serveransvarlig svarte at vi kan utvide levetiden over sommeren hvis det er ønskelig. Kommer tilbake til dette nærmere leveringsfristen. Gruppen sender også mail til Netprint og Allkopi for å forhøre angående pris og hvor lenge før de må ha inn rapporten for å få trykket den opp til firsten 27. mai ettersom printing på skolen krever innlevering av rapport senest 21. mai Har møte med veilede, og har med et par spørsmål vi ønsker ønsker klarhet i rundt rapport og levering av oppgaven, og fikk svar 8.Mai.

235 Brukerveiledning i rapport: Står i dokumentasjonsstandarden at den skal inneholde termologi, stikkordregister og generell ordliste. Hva er forskjellen? Svar: Ikke viktig med ordlister, stikkordslister etc. Bruk det som virker mest naturlig. Skal de forskjellige dokumentene fungere alene? Skal noen for eksempel kun ha produktrapporten? Kan man for eksempel i prosessrapporten referere til en figur i produktrapporten? Svar: Når det gjelder sluttrapport: Tor mente at mange deler rapporten inn i 2 deler + vedlegg (produktrapport og prosessrapport). Men det er ikke noe som er absolutt. Når jeg foreslo at sluttrapporten kunne deles inn i fem hovekapitler; 1. Kravspesifikasjon, 2. Prosessrapport, 3. Produktrapport, 4. Testdokumentasjon og 5. Brukerdokumentasjon samt referanser og vedlegg til slutt, synes han det var helt OK. Må presentasjonen være i sluttrapporten? Eller kan vi bruke tiden mellom levering av rapport og fremføring til å lage presentasjon? Svar: Presentasjonen skal ikke være en del av sluttrapporten. Skal sensor ha tilgang på en kjørbar versjon av webapplikasjonen? Slik at de kan se produktet, ikke bare dokumentasjon og kode. Svar: Noen sensorer vil ha kjørbar versjon, andre ikke. Kode på vedlagt CD /DVD plate skal holde. Her gjør vi litt etter hva vi har tid til mot innlevering. Skal sensor ha tilgang på GIT repository? Må vel være lurt for å se hvordan vi har jobbet i løpet av prosjektet? Svar: Dette er ikke nødvendig, prosessrapporten dekker dette. Hva legges det i punktet Om resultatet i dokumentasjonsstandaren? Noe i tabellform? Svar: Vi skal glemme det spesfikke punktet, men skal reflektere over resultatet av prosjektet, mao. hva har vi lært, hva kunne bli gjort bedre osv. Må rapporten printes 1 sidig? Eller kan den printes 2 sidig? Svar: Rapporten bør printes 2 sidig Hvor står det om plakaten vi skal lage? Hva skal det brukes til? Hvor skal vi legge den? Hva skal den inneholde? Svar: Ingen plakat skal lages

236 Gruppen sender utkast av sluttrapport til veielder for en gjennomlesing før ny veiledningstime på onsdag (14. mai) Gruppen har møte med veilelder hvor vi får tilbakemeldinger på utkastet til sluttrapport som ble levert 9. Mai. Får en del god pekepinner på hva vi bør endre/forbedre i rapporten. Dette gikk særlig på oppsettet i rapporten, men også å ha en kortere innledning av prosjektet før kravspesifikasjonen blir beskrevet. Blir enig eom å sende veileder rapporten førstkommende Mandag (19.Mai) slik at han får tatt et siste overblikk før den leveres 20. eller 21. Mai. Videre får gruppen informasjon om at vi skal ha øving på presentasjon 4.Juni sammen med veileders resterende grupper Gruppen har sluttrapporten så godt som klar, men mangler en siste gjennomlesing som blir gjort i løpet av morgendagen. Sender sluttrapport til veileder for eventuelle siste endringer Gruppen gjør siste gjennomlesing av rapporten og sender den til printing. Generelt om oppdatering av prosjektdagbok For hver gang gruppen samles for møter eller arbeid oppdateres dagboken med informasjon om hva som er blitt avtalt og hovedpunkter som er gjort. Konkrete oppføringer om hvem som gjør hva på hvilke tidspunkt kommer imidlertid frem fra Trello bordet på lenken nedenfor. (Kan kun aksesseres for personer som er blitt lagt til). Legger så fremt det har skjedd oppdateringer ut oppdatert prosjektdagbok på gruppens hjemmeside hver Torsdag/Fredag slik at en oppdatert versjon til en hver tid kan nås av først og frem veileder.

237 9.2 Fremdriftsplaner Fremdriftsplan for implementering 237

238 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Fremdriftsplan Generelt om tidsberegning Som grunnlag for vår tidsberegninger har vi tatt for oss at hovedprosjektet for oss tilsvarer 20 studiepoeng som for oss er ⅔ av uken. Gitt at en arbeidsuke er 37,5 timer gir dette oss 25 arbeidstimer i uken hver til hovedprosjektet, totalt 75 arbeidstimer i uken. Fristen for levering av prosjektrapport er satt til 27. mai 2014 klokken For å gi oss selv rom for avvik og utarbeidelse av prosjektrapport setter vi som en tidsfrist for selve produktet til å være ferdig i løpet av uke 17 (med siste arbeidsdag fredag 25. april). Gruppen anser seg ferdig med planleggingsfasen i løpet av denne uken (uke 5, med siste arbeidsdag fredag 31. januar) da dette også skal presenteres for veileder denne uken. Dette gir oss fra og med første dag etter planleggingsfasen (mandag 3. februar, uke 6) frem til nevnte tidsfrist for produktet totalt 12 uker. Dette gir hele gruppen totalt 900 arbeidstimer samlet. Ettersom vi skal utføre enhetstesting av siden som er meget viktig, samt at en del dokumentasjon vil bli gjort i løpet av denne tiden anslår vi at ⅔ (66,67%) av tiden vil gå med på direkte koding og utvikling av produktet. Dermed sitter vi igjen med 600 timer til planlegging for den spesifikke tidsberegningen under. De resterende 300 timene vil gå til enhetstesting av systemet. Vi ser for oss at nevnte 25 timer per gruppemedlem fordeler seg på følgende måte i uken uten at selve tidspunktene er låst for alle uker. Dag Tidspunkt Timeantall Mandager 09:30 15:00 5,5 timer Tirsdager 08:30 15:00 6,5 timer Torsdager 08:30 15:00 6,5 timer Fredager 08:30 15:00 6,5 timer Totalt 25 timer

239 Grov tidsplan Tidsperiode Antall uker Antall arbeidstimer for hele gruppen Arbeidsoppgave 3. Februar 28.Mars Implementering med tidvis dokumentasjon om arbeidet underveis. 31.Mars 25.April Enhetstesting med dokumentasjon av testene som gjøres, samt eventuelle utbedringer basert på testresultater. 28.April 16.Mai Sette sammen og skrive ferdig dokumentasjon. 19.Mai 27. Mai 2.Juni 10. Juni* 1 uke og 2 dager 1 uke og 2 dager 105 Periode satt av til finskriving/dobbelsjekking og buffer periode om overnevnte perioder ikke holder tidsrammene. 105 Lage klar presentasjon av prosjektet. Totalt 1335 * Presentasjon i tidsrommet 10.Juni til 13.Juni

240 Om planning poker og krav Vi har tatt utgangspunkt i de funksjonelle kravene fra kravspesifikasjonen og listet disse opp i prioritert rekkefølge også innenfor hver enkelt prioriteringsgrad (A D). Vi regner med en feilmargin i tidsberegningen på 10% hvilket gir oss 540 timer å planlegge arbeid på. For å få et best mulig tidsestimat har vi benyttet os av planning poker hvor hver gruppemedlem hver for seg estimerte timer oppgaven ville ta. Videre setter vi ingen konkrete tidsestimater på de ikke funksjonelle kravene ettersom det er vanskelig å sette direkte tidsestimater på dette. Vi setter imidlertid av en arbeidsuke (75 timer) til å dekke dette strødd utover prosjektet. Ideelt er det da 465 timer som står igjen til skjemaet under. Setter videre opp en sprint (75 timer per sprint) ved endt sprint slik at vi har mulighet til å ta med punkter som ikke ble ferdig i sist sprint. Markerer sprintene med hver sin farge i tabellen nedenfor. Tidsberegning Tidsberegning (i hele timer) # PRI Krav Utdyping av krav E L S Snitt* #Sprint Herunder opprettes tilhørende databasedel for brukerhåndtering. Samt bestemme hashfunksjoner En bruker skal kunne logge og lagring av dette i 1 A inn database Systemet skal analysere et Herunder faller testing av 26 A PDF skjema for digital utfylling av felter. pdftk og bash scripting for å få dette til å fungere A En kunde skal kunne være privatperson eller bedriftskunde Herunder faller strukur/modell på kunde og tilhørende databasedel for håndtering av bruker A En kunde skal ha en kundestatus A En bruker skal ha en rolle Herunder faller databasedel for roller og handlinger de forskjellige

241 32 A 7 A 10 A rollene skal ha tilgang på En bruker skal kunne endre passord Herhunder faller sikring på sider som begrenser En bruker skal ikke kunne synlighet/muligheter i utføre uautoriserte henhold til hvilken rolle handlinger/operasjoner man har En bruker skal kunne legge til en kunde 13 A En kunde skal ha en profil 14 A 3 A 2 A 52 A 20 A 24 A 23 A En kundeprofil skal inneholde detaljer om kunden En bruker skal ha en profil som viser personalia En admin skal kunne legge til en ny bruker En bruker skal kunne opprette en kontrakt med en kunde En kontrakt skal ha en kontraktstatus En bruker skal kunne legge til en generell PDF mal En bruker skal kunne legge til PDF mal tilknyttet en Herunder faller stuktur/modell for bruker og tilhørede databasedel for håndtering av kunde Herunder faller opprettelse av unik visningsside for hver kunde Herunder faller henting av kundeinformasjon fra databasen tilknyttet den spesifikke kunden Herunder faller en unik side for hver bruker og henting av informasjon fra databasen tilknyttet den spesifikke brukeren ** Herunder faller opprettelse av hendelser(actions) i databasen som tilegnes adminbruker Herunder faller struktur/modell av kontrakten samt databasedel for håndtering av kontrakter Herunder faller database del for å endre kundestatus Herunder faller opplasting av PDF filer som analyseres. Databasedel for maler og lagring av felter Herunder faller opplasting av PDF filer og database **

242 27 A 18 A 19 A 28 A 4 A 15 A 29 A 31 A 30 A kunde del som knytter denne malen til en spesifikk kunde Herunder faller databasedel for logging av hendelser, samt en generell loggedel som blir Systemet skal logge kalt hver kan det gjøres hendelser gjort på bruker ogendringer i systemet for å av hvem sikre at alt blir logget En kontrakt skal kunne inneholde en utfylt versjon av malene. En kontrakt skal kunne inneholde vedlegg Systemet skal logge hendelser gjort på kunde og av hvem Brukerprofilen skal vise hendelseslogg for brukeren En kundeprofil skal vise hendelsesloggen for kunden Systemet skal kombinere kundeinformasjon og generere opp en eller flere PDF dokumenter, basert på denne informasjonen Herunder faller funksjonalitet for å laste opp riktige maler og klargjøre disse for utfylling ** Herunder faller funksjonalitet for opplasting av statiske vedlegg som skal tilhøre kontrakten, men ikke editeres. Databasedel for dette må også implementeres Herunder faller databasedel for kundespesifikke logger Herunder listing av logg tilknyttet spesfikk bruker Herunder av logg tilknyttet speslisting fikk kunde Herunder faller automatisk utfylling av de feltene i malen som allerede er lagret i databasen ** En bruker skal kunne velge Herunder faller det visuelle kontrakttype ved opprettelsebrukergrensesnittet ved av kontrakt opprettelse av kontrakten Herunder faller det å sette paramentre for kontrakten Systemet skal filtrere ut som videre benyttes til å hvilke PDF maler som skal analysere hvilke fylles ut avhengig av dokumenter som trengs i handlingen som velges kontrakttypen og vise disse

243 8 A 9 A 5 A 17 A 21 A 34 A 36 A 22 A Systemet skal forhindre uautorisert tilgang til kundeinformasjon Systemet skal forhindre uautorisert tilgang til kontrakter og vedlegg En admin skal kunne endre på brukerpersonalia og rolle En kundeprofil skal vise de funksjoner innlogget bruker har i henhold til tilgangsnivåer. En kontrakt som er signert skal ikke kunne endres. Systemet skal lagre ferdige PDF i et arkiv Systemet skal kunne printe ut ferdige PDF En signatur skal ikke kunne gjenbrukes på fler kontrakter Herunder faller aksessliste for kundeforholdet i tillegg til hvilke handlinger man har tilgang på. Dette gjelder modellering og database del både for aksessliste og handlinger man kan utføre på en kunde Herunder faller sikker lagring av dokumentene og en funksjon all visning går gjennom som alle sikkerhetsmekanismer blir gjennomgått før visning Herunder faller funksjonalitet for å hente ut rolleinformasjon og endre handlinger roller har Herunder faller visning av valg basert på tilgangsnivåer samt hindring av "url injection" Herunder faller sikkerhetsmekanismer som sikrer at en kontrakt ikke kan endres når den først er signert Herunder faller sikker lagring av ferdige kontrakter Herunder printing av alle dokumenter som faller under kontrakten, utfylte maler så vel som vedlegg og kopi av legitimasjon Herunder faller sikkerhetsmekanismer som knytter signatur mot en enkelt kontrakt og ikke kan misbrukes til bruk på andre kontrakter for

244 16 A 53 A 33 A 35 A 38 A 25 A 54 A 56 A 57 A En kundeprofil viser alle kontrakter og maler tilhørende kunden samme kunde Herunder faller søking i databasen etter kundespesifikke maler og liste disse opp Herunder faller Systemet skal kunne søke databasespørringer som etter kunder/prosjekter etter endres i henhold til de valg gitte kriterier brukeren setter på søket Systemet skal bruke SSL kryptering i all interaksjon med bruker Systemet skal tilby muligheten å laste ned alle dokumentene knyttet til en kunde Systemet skal kunne sende mail til kunden nå er kontrakt er laget med kunden En bruker skal kunne oppdatere malversjon En bruker med tilgang skal kunne redigere tilgang til kunde En bruker skal bli blokkert etter x antall feilinnlogginger En bruker skal kunne få et midlertidig passord på mail Herunder faller kartlegging om muligheter på nåværende webhotell for å få en sikker https overføring av filer og informasjon slik at dette ikke overføres i klartekst Herunder listing av kundens kontrakter og mulighet til å laste ned dette som en "kundeprofil" i zip eller lignende Herunder funksjonalitet om å sende ut mail når en kontrakt er signert som en slags kvittering ** Herunder funksjonalitet for å bytte ut eksisterende mal om det er gjort endringer i den Herunder funksjonalitet for å endre aksesslister tilknyttet en kunde slik at andre bruker får nye rettigheter Herunder en sperre for innlogging for å forhindre "brute force attack" på systemet Herunder mailfunksjonalitet som sender ut et generert passord som fungerer i et døgn

245 40 B 41 B 55 B 39 B En bruker skal kunne legge til manuelle oppføringer i kundelogg Systemet skal tilby kategorier for manuelle oppføringer En admin skal kunne redigere roller En bruker skal kunne redigere egen profil Herunder manuelle oppføringer i loggen slik at systemet kan benyttes til logging av samtaler/ notiser som ønskes lagret mot kunden Herunder valg som telefon/epost /merknad tilknyttet manuelle oppføringer Herunder endring og etablering av nye roller og hvilke muligheter disse rollene skal ha Åpner for at bruker kan endre egen profil, ikke bare admin Tot funksjonelle krav 468 Ikke funksjonelle krav 75 Totalt alle krav 543 * Nærmeste hele time ** Har blitt overført videre til annen sprint. Nærmere spesifisering kommer frem i avsnittet om oppsummering av sprinter nedenfor. Om sprintene Etter endt sprint på Fredager oppsummerer vi sprinten og fyller ut skjemaet nedenfor både for nylig tilbakelagt sprint, samt planlegger neste ukes sprint. Vedplanlegging av sprint legges også sprinten med tilhørende oppgaver inn på scrumbrettet hvor oppgavene deles mellom gruppemedlemmene. Mer spesifikk fremgang fremkommer kun på Trello (Scrumbrett Implementering). Fargekodene som benyttes her går igjen på Trello slik at man enkelt kan bruke denne fremdriftsplanen mot Trello. For å dokumentere fremdrift i Scrumbrettet tar vi skjermbilder av scrumbrette i midten av hver sprint med unntak av kolonnen Ferdig. implementering (Krever innlogging og tilgang)

246 Sprinter # Antall timer* Ukenr Oppsummering Prosent ferdig Timer overført til neste sprint 1 70,0 6 Gruppen har dekket alle punktene i sprinten, samt gjort innlendende arbeid på oppgaver/krav som ikke var en del av sprinten. Velger av den grunn å ha et noe større timeantall på kommende sprint ettersom deler av kravene er påbegynte. På dette stadiet har vi en kjørende prototype med meget begrenset funksjonalitet Gruppen utfører alle punktene i sprinten, men det gjenstår et par underpunkter på det ene kortet tilknyttet brukers profil.(#3) Overfører derfor 5 timer til neste sprint Gruppen utfører alle planlagte krav med unntak av to krav, #23 som er planlagt for 4 timer samt krav #18 planlagt for 6 timer. Sistnevnte krav flyttet da kravet avhenger av andre deler som ikke er på plass. Begge flyttet til neste sprint. 100% 0 94,73% 5 ** 86,67% 10** Gruppen utfører de fleste av punktene satt av til denne sprinten. Et av kravene i denne sprinten, #29, ble i midlertid en del vanskeligere enn først anslått i tidsestimeringen. Punktet vil ha en estimert tid ytterligere legger til 10 timer på dette punktet. Disse ytterligere timene må derfor overføres til neste sprint. Det andre punktet som ikke ble fullført i denne sprinten er #18, dette punktet er dirkekte avhengig av #29, og er derfor ikke påbegynt i det hele tatt. Dette punktet må overføres i sin helhet til neste sprint. 79,22% 16**

247 Gruppen utfører alle punkter, også krav #18 selv om vi ikke har fått testet dette ettersom det ikke kan bli gjørt før krav #29 er ferdig. Punkt #29 er fortsatt ikke ferdigstilt ettersom vi har møtt på komplikasjoner med gjenbruk av kode for dette punktet. Skal ha møte med oppdragsgiver for å få avklart spørsmål tilknyttet dette kravet. Må derfor legge til ytterligere 10 timer for å dekke dette kravet i neste sprint. Planlegger neste sprint med 8 timer mindre enn en planlagt sprint for å jobbe mer med å ferdigstille en prototype til oppdragsgiver Gruppen utfører alle krav satt. Også krav #29 som har blitt overført over flere sprinter. I tillegg blir et testmiljø satt opp riktig for en prototype som oppdragsgiver kan aksessere for å se konkret fremdrift. I tillegg testet vi fremgangsmåten for å kryptere overføringer i systemet ved hjelp av SSL teknologi, slik at dette er kjent ved levering til oppdragsgivers servermiljø. 85,92% 10** 100% Gruppen utfører alle krav i sprinten, med unntak av #38 som etter et kort møte med oppdragsgiver også vil dekke mail til samarbeidspartnere i tillegg til kunden. Avventer maler fra oppdragsgiver før dette kan ferdigstilles, og overfører 5 timer til neste sprint. Til kommende sprint er alle krav B krav. Imidlertid er mange av disse kravene påbegynt i forbindelse med tidligere krav, men ettersom sprint 8 blir siste planlagte arbeidsuke med selve produktet, gjenstår mye arbeid med å ferdigstille alle funksjoner og sy sammen produktet til en helhet før testingen 93,67% 5**

248 kan starte neste uke Gruppen gjør ferdig de resterende krav satt. Er imidlertid noe mindre funksjonalitet som gjenstår som vi tar sikte på å ordne i forbindelse med testingen og bufferperioden satt av til Mai. Herunder: Laste opp utfylt utgave av vedlegg. Kontonummer på kunder. Unik XFDF fil for hver bruker. Kalender på kunder. Logge hendelser Mindre oppgaver i hver enkelts To do kort Oppsett av tjenester på oppdragsgivers miljøer. (Mail, webserver, SSL) 100% * Sum av timesnitt fra fargemarkerte krav pluss eventuelle timer overført fra foregående sprint, i tillegg til del av ikke funksjonelle krav (75/8 10) ** Timer overført til neste sprint illustreres både i dette skjemaet og på Trello med rød farge i tillegg til original sprintfarge.

249 Skjermdump av sprinter Figur 1: Scrumbrett per kun med oppstartsfasen Figur 2:Scrumbrett per Sprint 1 ferdig, og Sprint 2 planlagt for kommende uke

250 Figur 3:Scrumbrett per Sprint 2 ferdig, og Sprint 3 planlagt for kommende uke Figur 4:Scrumbrett per Sprint 3 ferdig, og Sprint 4 planlagt for kommende uke

251 Figur 5:Scrumbrett per Sprint 4 ferdig, og Sprint 5 planlagt for kommende uke Figur 6:Scrumbrett per Sprint 5 ferdig, og Sprint 6 planlagt for kommende uke

252 Figur 7:Scrumbrett per Sprint 6 ferdig, og Sprint 7 planlagt for kommende uke Figur 8:Scrumbrett per Sprint 7 ferdig, og Sprint 8 planlagt for kommende uke

253 Figur 9:Scrumbrett per Sprint 8 ferdig. Sprintbrett ferdig.

254 9.2.2 Fremdriftsplan for testing og rapport 254

255 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Fremdriftsplan for testing & rapport Kort om test og rapportperioden I den opprinnelige tidsplanen i fremdriftsplanen er det satt av 4 uker testing med tilhørende dokumentasjon, 3 uker med direkte skriving av rapport, samt 1 uke bufferperiode for tidsavvik både på de nevnte 8 ukene, men også de 8 foregående ukene. Etter denne planen vil vi først 28. april, en måned før levering, sette alt fokus på rapporten, men denne vil også bli skrevet på i løpet av testperioden, da i all hovedsak med fokus på testing, men også oppbygging av rapporten. Ettersom vi ikke har satt oss konkret inn i hvilke tester som skal gjøres, eller hvordan rapporten skal bygges opp kan vi på dette stadiet ikke sette opp konkrete oppgaver/krav, men setter en tidsplan på de kommende sprintene hva gjelder testing og rapportskriving. Beskrivelse av sprint og sprintkort vil derfor kun være tilgjengelig for foregående og kommende ukes sprint. Sprinter Beholder sprintfarger til nytt sprintbrett på Trello (Scrumbrett Testing og Rapport testing og rapport) hvor oppgaver blir lagt til for hver uke som kommer når mer konkrete oppgaver foreligger. # Ukenr Beskrivelse Oppsummering 9 14 Legge til rette for en brukertest av systemet* hvor brukere hos oppdragsgiver får oppgaver å gjøre og melder fra om feil/forslag til endringer. Dette blir en test for å få effektivisert arbeidet hos bruker og få tilbakemelding om hva som fungerer, og ikke fungerer. Ny funksjonalitet vil ikke være en del Får gjennomført store deler av sjeklisten, men gjenstår noe arbeid særlig med punkt 5 (Flytte DBspørringer til metoder i modellene.) Istedenfor å sende en brukertest til oppdragsgiver avatler vi et møte på Fredag hvor alle brukere i Meso er tilstede. Før dette møtet setter vi opp

256 av testen såfremt det ikke er vitale deler som mangler for at systemet skal fungere, i henhold til kravspesifikasjonen. Planen er å sende oppgaven til oppdragsgiver hvor de kan utføre og returnere med tilbakemeldinger. Hvis det lar seg gjøre hadde det også vært nyttig å være tilstede hos oppdragsgiver for å ta notater (hvor bruker ser og hvor bruker oppholder seg mest iht. fokus o.l.) et eget prototypemiljø med brukere for testing. (Se egne dokumenter for nærmere informasjon om møtet) På møtet viser i frem prototypen og gir ut brukertester. Får av denne grunn ikke bearbeidet testresultat denne uken, men først kommende uke. Mandag & Tirsdag: Gjøre systemet klart for brukertesting. Herunder sjekkliste: 1. Endre formuleringer. 2. Flytte språk til språkfil. 3. Bruker libraries til lenker. 4. Gå gjennom og kommentere på kode. 5. Flytte DB spørringer til metoder i modellene. 6. Logge hendelser i systemet (særlig viktig før brukertest) 7. Gode tilbakemelding til bruker (særlig viktig før brukertest). 8. Legge gjentakende kode i libraries. 9. Regex på postmetoder. Torsdag: Lage oppgaver til testpersonene, herunder ha enkle oppgaver og i tillegg oppgaver som tar for seg de sjeldne tilfellene. Fredag: Bearbeide og skrive om testresultat.

257 10 15 Mandag & Tirsdag: Utføre de endringer som gjenstår fra sist uke samt endringer påpekt på møtet. Onsdag: Gå gjennom og Implementere endringer i systemet basert på brukertest i tillegg til å gjøre klar en fremvisning til veileder. Torsdag & Fredag Sette oss inn i enhetstesting med Laravel rammeverket og foreta småtester. Fått implementert de fleste endringer etter møte og resultater av brukertest (for resultatene vi har fått fått inn per nå). Det som gjenstår er: implementere poststed basert på postnummer (eller felt for poststed). Slette kundefiler. Sjekklisten fra forrige sprint for å gå gjennom Controllere har vist seg å være mer arbeidskrevende enn først antatt. Står fortsatt igjen å: Flytte DB spørringer til metoder i modellene. Logge alle hendelder. Avventer også brukertesten fra noen av testpersonene for å ferdigstille evaluering av brukertest Enhetstesting Mandag: Fullføre det som står igjen fra sist uke. Tirsdag Fredag: Enhetstesting av modeller og begynne på enhetstesting av UserActionController Enhetstesting og implementering av systemet på oppdragsgivers server i ferdig utgave Fullføre enhetstesting og skrive Rapport Får ikke fullført alle oppgaver i sprinten på grunn av at enhetstestingen av modeller viste seg å være mye mer arbeid en først antatt, samt berenset arbeidsmengde bla.a. i forbindelse med påske. Overfører gjenstående fra sist sprint inn i ny, samt starte å enhetsteste controllere. Fullført alle gjenstående oppgaver fra tidligere spirinter i tillegg til å ha enhetstestet alle modeller i systemet. Har også et skall for rapport oppe hvor deler er påbegynt, deriblant dokumentasjon av brukertest. Har fått enhetstestet store deler av UsersActionController og CustomerController hva gjelder GET metoder og filters.php.

258 Får ikke enhetstestet alle POST metoder grunnet tid. Ser ut til at vi har satt av noe for kort tid til enhetstesting, men har fått testet det viktigste som gjelder databasespørringer i modeller og aksesskontroller i Controllerne. Er også på god veg med rapporten, anslår at rapporten er ca. 35% ferdig. Setter opp resterende punkter i raport i Scrumbrett Rapport Alle punkter som gjenstår er startet og så godt som fullført, med unntak av teknisk appendiks for laravel/php + Bash, samt å skrive om designutvikling. Tar også sikte på å lage en Virtual Machine som kjører webapplikasjonen som kan legges ved på CD sammen med CD med kode. 15 uke20 19.Mai 20.Mai Mai til 26.Mai Fullføre rapport uke 20 Gå gjennom rapport 19 og 20 mai før levering av oppgave til print senere 20.mai Mai: Gjøre siste fiks på implementasjonen samt gruppeide Mai: Lage Virtual Machine og CD med kode til levering. 26. Mai levere oppgaven. Gruppen fullfører sluttrapport og sender den til printing 20. Mai Skisse på rapport Etter tips og erfaring fra andre skriver vi rapporten i LaTeX. ( project.org/). Per i dag ser vi for oss en oppbygging på rapporten som følger:

259 1. Selve rapporten til systemet generelt vil bli skrevet fra et overordnet synspunkt som kan leses og forstås selv om man ikke har mulighet til å gå inn i, eller forstå, selve koden. Herunder aspekter som: a. Formål & Nytteverdi b. Design c. Brukervennlighet d. Rammeverk e. Sikkerhet f. Robusthet g. Utbedringspotensiale / Utvidbarhet / Skalérbarhet 2. Teknisk appendix hvor vi tar for oss rammeverk, oppbygging, enkelte metoder, teknologier og kode valg. 3. Test appendix hvor vi tar for oss enhetstesting, brukertesting og eventuelt andre tester som gjøres på systemet. 4. Brukerveiledning appendix til systemet som beskriver hvordan systemet brukes i praksis. Dette er til hjelp både for sensor og oppdragsgiver. Skjermdump av sprinter

260 Figur 10 :Scrumbrett per Sprint 9 planlagt for kommende uke. Figur 11 :Scrumbrett per Sprint 10 planlagt for kommende uke.

261 Figur 12 :Scrumbrett per Sprint 11 planlagt for kommende uke. Figur 13 :Scrumbrett per Sprint 12 planlagt for kommende uke.

262 Figur 14 :Scrumbrett per Sprint 13 planlagt for kommende uke. Figur 15 :Scrumbrett per Sprint 14 planlagt for kommende uke.

263 Figur 16 :Scrumbrett per Sprint 15 planlagt for kommende uke. Figur 17 :Scrumbrett per Sprint 16 planlagt for kommende uke.

264 9.3 Møter med oppragsgiver Møte 21.Januar

265 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Møte Agenda 1. Tekniske spørsmål a. Webhotell i. Størrelse (M, L, XL) / egen server ii. Database iii. VPN iv. Støtte 1. PHP versjon 2. HTTPS? 3. Størrelse > lagring? 4..NET? v. b. Sikkerhet > hvor sikkert skal det være? 2. Funksjonalitet a. Skal kundene ha tilgang på sine sider? b. Konkrete krav til funksjonalitet? c. Kundebehandler til kunde forhold i. Vil alle kundebehandlere ha alle rettigheter til alle kunder? d. Tablet og smartphone vennlig? e. Kundevalg i. Søke, lete i liste, lage nye > gjøres oftest? f. Ved ferdig skjema i. Lagring skjer automatisk ii. Sjekkbokser eller knapper? g. Trinnvis? 3. Praktiske spørsmål a. Hvordan gjøres dette i dag? (Gjennomgang) b. Hvor ofte får dere nye PDF? c. Egenproduserte eller eksternproduserte dokumenter? d. Faste dokumenter? (mest brukte) > Sende til oss?

266 Vedlegg 1 : logg inn Vedlegg 2: logget inn

267 Vedlegg 3: Eksisterende dokument Vedlegg 4 : Nytt dokument

268 Vedlegg 5: Eksisterende kunde Vedlegg 6: Ny kunde

269 Vedlegg 7 : Ferdig Vedlegg 8: Ny kunde med minimert meny

270 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Møtereferat Tilstede: Gruppe 32 Simen André Hansen Lars Henrik Nordli Erik Maximillian Forsman Lasse Bøe, kontaktperson hos Meso Capital Markets Møtet gikk ut på å diskutere og få mer spesifikke krav, idéer og tanker rundt applikasjonen som skal lages. Har også med møteagenda samt tidlige skjermbilder av utkast for løsningen. Under følger hovedpunkter for møtet: Vi diskuterte utstyr ift. hva vi trengte for at vår tenkte løsning skulle fungere. Vi kom frem til at oppdragsgiver per i dag har Webhotell L fra Uniweb AS ( og dette skulle foreløpig være tilstrekkelig for applikasjonen. Av møtet fikk vi en grov gjennomgang på hvordan oppdragsgiver per i dag gjennomfører hva applikasjonen er ment til å gjøre, og fikk ut fra dette en bedre oversikt over hvordan vi skal legge opp systemet. Hovedpunkter som kom frem under møtet var: Oppdragsgiver fyller som oftest ut flere dokumenter om gangen som skal kobles opp mot samme kunde (en slags kontrakt som inneholder flere dokumenter). En kunde bør ha et felt for vedlegg der bilder og dokumenter som ikke nødvendigvis gjelder for hver kunde skal ligge Hvis mulig vil oppdragsgiver ha muligheten til å laste ned kundeinformasjon lokalt på egne datamaskiner Handlingsbasert bruksmønster (én handling for selge, én handling for kjøpe osv.) fremfor enkeltdokumenter som vi først hadde sett for oss Det er også egne utfyllinger basert på om dokumentet omhandler privatpersoner, eller firmaer. Det kan være flere like skjemaer i en kontrakt om det gjelder salg/kjøp i forskjellige prosjekter.

271 Oppdragsgiver har et utvalg faste dokumenter i sitt arkiv, men får også inn nye prospekter på en regelmessig basis som må inn i systemet. Det er muligheter for at disse prospektene kan ha en viss standard når det kommer til utfyllingen. Det ønskes også at hver kunde i systemet skal ha sin egen profil der all interaksjon mot denne kunden er, samt ulike dokumenter knyttet opp til denne kunden skal kunne aksesseres. Etter endt prosess i systemet er det ønskelig at kunder i systemet skal få tilsendt en form for bekreftelse på mail om at en handel/kontrakt er gjennomført, imidlertid er det ikke nødvendig å legge ved kopi av dokumentet/dokumntene (vil fungere med som en logg ). Oppdragsgiver ønsker også at tjenesten skal kunne utvides til en mer helhetlig løsning, som kan fungere som en portal for hele bedriftens virke. Denne portalen skal samle sammen en rekke eksisterende løsninger bedriften nå tar i bruk, og samle alt til en sentral løsning. Herunder kommer nye punkter som; Status på kundeforhold, Potensiell kunde, Aktiv kunde og lignende. Mulighet for å legge inn manuell logg på kunden ved for eksempel forsøk på kontakt. Mulighet for å legge til møte med kontakt som videre vil samles i en liste om kommende møter. Importere store eksisterende Excel lister inn i denne portalen med navn og formatering av disse (Prosjekt exceler). Eventuell legge opp mulighet for en kunde innlogging på samme portal. Vi møter på noen utfordringer når det kommer til lagring kundeinformasjon i form av personvern. Per i dag vil oppdragsgiver lagre blant annet personnummer og kopi av legitimasjon (bankkort, førerkort, pass eller annet). Siden dette kategoriserer seg som sensetiv informasjon, må vi sjekke med Datatilsynet (eller andre statlige organer som har retningslinjer rundt dette) for å forsikre oss om at løsningen blir riktig satt opp. Dette spiller inn på: Valg av serverløsning (ekstern eller intern server) Backup rutiner og plasseringer Sikkerhet (kryptering, aksesskontroll) Valg av serverstørrelse og lokasjon (brannsikkert, flere steder i landet etc.) Oppdragsgiver har også sett på USB signering/elektronisk signering. Informerer oppdragsgiver om at vi innenfor de rammene som er satt ikke vil ha muligheten til å inplementere full elektronisk signering, men at vi skal se videre på USB signering; Om eventuell USB signering er tilstrekkelig i denne sammenheng, eller om dokumentene må printes og signeres (legalt). Om dette lar seg implementere i løsningen.

272 Informerer oppdragsgiver om at de vil motta møtereferat i løpet av et par dager. Informerer også om at vi vil se på all ny informasjon vi har fått i møtet og sette opp forslag til en prioriteringsliste på hva vi tenker å implementere innenfor hovedprosjektets rammer og at de vil motta denne og få mulighet til å eventuelt endre på prioriteringene eller komme med flere innspill. Får også god tilbakemelding på designutkastene vi hadde med på møtet slik at vi videre kan begynne å implementere dette. Informerer også om at hovedprioriteten vår er å få PDF delen til å fungere som ønsket, og at funksjonalitet for nevnte portal vil komme i andre rekke.

273 9.3.2 Møte 10.Februar

274 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Møte Agenda 1. Tekniske spørsmål a. Server VPS i. leie/virtuell server , per måned 10 gb , per måned 20 gb , per måned 50 gb b. Backup i. Har sendt mail til UniWeb for å få avklart pris på tjenesten. ii. Man kan bestille backup av VPS, denne vil bli kjørt hver natt (eller annet ønsket tidspunkt) og er tilgjengelig 14 dager tilbake. iii. Det blir fakturert en halvtimes konsulenttjeneste for restore av backup (750, eks. Mva) 10GB = 100, eks. Mva, 50GB = 200, eks. Mva og 100GB = 300, eks. Mva. (Backup bestilles manuellt via epost) c. SSL i. SSL Sertifikat p%c3% A5 hjemmesiden 1. fra 500, per år med ekstern signering 2. Self sign gratis 2. Prototype / utkast a. Meny i. Menyposisjon: høyre, venstre eller oppe ii. Hovedkategorier med undervalg eller alle valg tilgjengelig iii. Mest brukte menyvalg? b. Søkefunksjon i. Hva søker dere mest etter i dag? 3. Kontrakt

275 Appendix A svar fra support hos uniweb ang SSL og serverplass Aleksander Aakvik (Uniweb support) Jan 28 14:36 Hei Lars Henrik. 1. SSL sertifikatet koster 750 NOK pr år. Det kreves også en statisk IP adresse. Denne koster også 750 NOK pr år. 2. Våre sertifikater er av typen RapidSSL og utstedes av RRPProxy som er en toppregistrar for internasjonale domener. Sertifikatene må godkjennes av domeneeier gjennom epost admin@domene.tld for ønsket domene. Dette kan ikke omgås. Ha en fortsatt fin dag. Mvh Aleksander Aakvik

276 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Møtereferat Tilstede: Gruppe 32 Simen André Hansen Lars Henrik Nordli Erik Maximillian Forsman Lasse Bøe, kontaktperson hos Meso Capital Markets Møtet gikk ut på å få avklart tekniske punkter, samt visning av prototype/utkast til oppdragsgiver. Tekniske og sikkerhetsmessige aspekter Etter diskusjon med oppdragsgiver ble det godkjent å utvide deres nåværende serverløsning. Dette innebar en VPS (virtual private server) på 10GB til 150, pr. måned. Ble enige om å lage en spesifisert liste på utgifter som forventes til dette prosjektet. Ettersom nettsiden i første omgang ikke skal fungere som en portal for kundene hvor de skal logge inn bestemmer vi oss for at vi i første omgang ikke skal benytte en ekstern signering av sertifikat for SSL, men går for egensignert kryptering så lenge da dette kun skal være til intern bruk for bedriften. Når det gjelder backup avventer vi fortsatt svar fra serverleverandør (UniWeb) med tanke på pris for dette men blir på møtet avklart at dette er ønskelig fra oppdragsgivers side. Vi kom fram til, i samråd med vår kontakt hos bedriften, at vi velger å gå for et SSL sertifikat som er av typen self signed. Da systemet kun skal brukes internt, vil dette gi en kostnadseffektiv løsning, men samtidig gi kryptering i de nødvendige fasene av tjenesten. Det er videre inneforstått at om tjenesten utvides til åpent bruk for bedriftens kundebase, at et eksternt signert sertifikat er veien å gå. Oppdragsgiver nevner igjen digital signering med USB penn/ signering på tablet. Har ikke fått undersøkt dette noe fra sist gang, men oppdragsgiver skal kontakte Finanstilsynet for å få avklart om dette er gyldig/ eventuelle krav ved en slik implementasjon.

277 Designmessige og funksjonalitet- aspekter Oppdragsgiver hadde ingen klar formening eller kommentar på hvordan menysystemet var i dag, og vi ble enige om at vi som utviklere hadde frie tøyler så lenge det var funksjonelt og logisk. Ved spørsmål om søkefunksjonen på siden ble vi enige om at vi skulle tilpasse et hurtigsøk for Personer og Prosjekter, og ha resten av søkefunksjonalitet i et avansert søk for å holde det kjapt. Etter ny informasjon fra oppdragsgiver ble vi enige om at vi på startsiden skal ha funksjonaliteten Min nylige aktivitet hvor siste logger, kontrakter, kunder og annen aktivitet skal listes opp. Les mer i neste punkt om logging. Oppdragsgiver kommer også med ønske om ny funksjonalitet/ endring på eksisterende funksjonalitet, som omfatter Logge forsøk på uautoriserte forespørsler. For eksempel om en person som ikke skal ha tilgang til et sted forsøker å få frem innholdet. Implementere Møtelogg/Prosjektlogg som en del av systemet tilsvarende automatiske logg som allerede er på plass for brukere. Liste ut Mine siste logger / Mine siste kunder som gjør at det er enkelt å finne frem til sist kunde man var inne på og lignende. Kunne registrere en kunde uten at alle felter er utfylt om man for eksempel ikke har epost på kunde tilgjengelig. Når en kunde knyttes mot et prosjekt skal faste felt fylles inn som ønskes lagret. Kunne liste ut statistikk om antall møter og signerte kontrakter på en enkelt bruker. Også statistikk tilknyttet felter i forrige punkt. Ble enige om å starte med en prototype på hovedoperasjonene ved kjøp og/eller salg av andeler som er noe av hovedløpet til bedriften. Skal vise frem denne ved neste møte. Annet Får oppdragsgivers signatur på Avtale om prosjektoppgave. Sender i etterkant av møtet mail til oppdragsgiver for å få innhentet hvilke felter som skal være generelt og gjentagende for et prosjekt, samt hvilke felter som skal fylles inn ved en typisk situasjon av salg og/eller kjøp

278 Appendix A: Skjermbilder fra prototype anno (git commit 67f270c54311b351ad2688dc af115b8d4) Figur 1: Viser fungerende innloggingsbilde med Glemt password funksjonalitet. Figur 2: Bilde etter innlogging.

279 Figur 3: Viser Hovedmeny åpen hvor alle undervalg er påbegynt. Blant annet list users som fremkommer i figur 5 Figur 4: Høyre meny tilknyttet innlogget bruker åpen.

280 Figur 5: Lister alle brukere i systemet med tilhørende valg til hver enkelt bruker. Kan per nå endre personalia, endre tilgangsnivåer og se/legge til logger. Figur 6: Vindu hvor man kan legge til enkeltrettigheter på en bruker utover rettigheter brukeren har fra sin rolle (Admin/Bruker per dags dato)

281 Figur 7: Viser logg på en bruker som vil være tilsvarende for en kunde hvor man kan legge inn manuelle oppføringer, samt at systemet logger i henhold til bruk av systemet.