HB Guide. Feilsøkingsverktøy for Homebase AS. Hovedprosjekt i Anvendt Datateknologi ved HiOA, 2013

Transkript

1 HB Guide Feilsøkingsverktøy for Homebase AS Hovedprosjekt i Anvendt Datateknologi ved HiOA, 2013 Gruppe 33: Karl Øgaard, s Aria Nejad, s Fredrik Ung, s Morten Iversen, s /136

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL FEILSØKINGSVERKTØY FOR HOMEBASE AS DATO PROSJEKTDELTAKERE Fredrik Ung Aria S. Nejad Karl Alexander Øgaard Morten Iversen S S S S ANTALL SIDER / BILAG 136 INTERN VEILEDER Geir Skjevling OPPDRAGSGIVER Homebase AS KONTAKTPERSON Angelica Dalhaug SAMMENDRAG Homebase AS er leverandør av IP-TV, IP-telefoni og Internett. Tjenestene tilbys over en åpen infrastruktur. De har et kundesenter som driver med support og feilsøking for kunder som trenger hjelp med bedriftens tjenester. Målet med dette prosjektet er å utvikle en web-basert applikasjon, som skal hjelpe kundebehandlerne med å feilsøke mer effektivt. Den skal også bidra til en grundigere loggføring av kundehenvendelser. Kundesenteret er avhengig av gode rutiner for å feilsøke og loggføre. En applikasjon som gjør denne prosessen enklere, er til stor nytte for bedriftens 2. -linje support (backoffice), som daglig mottar oppfølgingssakene. 3 STIKKORD Feilsøking Sjekklister Web-applikasjon 2/136

3 Forord Feilsøkingsverktøy for Homebase AS er et hovedprosjekt som ble utført i slutten av en treårig studie ved Anvendt Datateknologi, Høgskolen i Oslo og Akershus (HiOA). Prosjektet eksiserte i perioden til Sluttrapporten omfatter dokumentasjon til produktet Feilsøkingsverktøy for Homebase AS og prosessen knyttet til produktets utforming. Takk til Det rettes en stor takk til intern og ekstern veileder, henholdsvis Geir Skjevling ved HiOA og Angelica Dalhaug ved Homebase AS. Takk til vår venn Anders Grimsrud for god teknisk hjelp og Philippe Sørensen for hjelp til rettskrivning. Brukersamfunnet på skal også takkes, for gode svar på mange tekniske spørsmål. Dette dokumentet er delt inn i følgende hoveddeler: Prosessrapport; Beskriver vår utviklings- og arbeidsprosess, fra prosjektets start til slutt Kravspesifikasjon; Beskrivelse av kravene som er satt for dette prosjektet Produktrapport; Beskrivelse av den ferdige applikasjonen Testrapport; Gjennomføring, resultater og analyse fra testingen av applikasjonen Prosjektsiden for dette prosjektet er å finne her: En fungerende demonstrasjon av kildekoden finnes her: Innloggingsdetaljer ligger i vedlegg 9. Kildekode, i denne rapporten. All kildekode til produktet vil bli levert i en passordbeskyttet RAR-fil til sensor og veileder. Alle rapporter er å finne i PDF-format på prosjektsiden. 3/136

4 Hovedelementer Del I. Prosessrapport...5 Del II. Kravspesifikasjon...42 Del III. Prosjektrapport...51 Del IV. Testrapport...90 Kilder Vedlegg /136

5 Prosessrapport DEL I: Prosessrapport 1 5/136

6 Prosessrapport Innhold Forord Innledning Gruppen Oppdragsgiver Dagens situasjon Mål og rammebetingelser Planlegging og metode Før prosjektstart Prosjektstyringsdokumenter Arbeidsplan Fremdriftsplan Møtereferat Prosjektdagbok Arbeidsteknikker og utviklingsmetoder Extreme Programming ( XP ) Workshops Ansvarsområder Skypemøter Intern Prosjektveileder Kontaktperson hos bedrift Verktøy Utviklingsverktøy Andre verktøy Hjelpemidler Utviklingsprosessen Prosjektstart Prosjektside for gruppemedlemmer Forprosjektrapporten Kartlegging av prosjektfaser Konseptutvikling Datainnsamling Normalflyt Konseptskisse /136 2

7 Prosessrapport Use-Case Modell Diskusjon med oppdragsgiver Utforming og Design Design High-fidelity Prototype Implementering Databaseutvikling E/R-modell Koding Applikasjonen Administrasjondelen av applikasjonen Testing og feilsøking Brukertesting av prototype Sikkerhet Optimalisering av kode Dokumentasjon Rapporter Brukermanual Kravspesifikasjonens rolle Resultatet Evaluering Hva kunne vært gjort annerledes Tilbakemelding fra oppdragsgiver Avsluttende del Samarbeidet i gruppen Samarbeid med oppdragsgiver Konklusjon /136 3

8 Prosessrapport Forord Dette dokumentet beskriver hvordan vi har planlagt og gjennomført vårt prosjektarbeid. Rapporten tar også for seg alle fasene i utviklingsprosessen og de utfordringer vi har støtt på underveis. Dokumentet er primært ment for sensor, oppdragsgiver og veileder. Det vil være en fordel at personen som leser rapporten har tekniske forkunnskaper, men det er ikke et krav for å forstå innholdet i rapporten. Datatekniske ord og begreper forklares i egen ordliste. (se vedlegg 1. Ordliste) 4 8/136

9 Prosessrapport 1. Innledning 1.1 Gruppen Gruppen består av fire studenter fra studiet Anvendt datateknologi ved Høgskolen i Oslo og Akershus: Karl Øgaard Fredrik Ung Aria Nejad Morten Iversen Gruppen ble stiftet i god tid før prosjektperioden begynte. Samtlige gruppemedlemmer har et høyt ambisjonsnivå og har oppnådd gode resultater ved tidligere prosjekter. 1.2 Oppdragsgiver Homebase AS er et datterselskap av Get AS som leverer IP-TV, IP-telefoni og Internett over åpen infrastruktur i mange ulike deler av landet. De tilbyr følgende tjenester: Skreddersydd TV-pakke av standardkanaler Ekstra kanalpakker fra leverandører som CMORE og Viasat Opptak av TV-kanaler Filmleie Internett IP-telefoni 9/136 5

10 Prosessrapport 1.3 Dagens situasjon Homebase kundeservice tilbyr brukerstøtte for kunder som trenger hjelp med bedriftens tjenester; TV, Internett, telefoni, faktura eller salg. Bedriften har kunder spredt over hele landet, tilknyttet ulike fiberleverandører, heretter omtalt som sites. Det tekniske utstyret hos kundene kan variere, avhengig av hvilken site kunden hører til. Konsekvensen av dette er at det blir svært mye teknisk informasjon og ulike feilsøkingsprosedyrer, som kundebehandlerne må sette seg inn i. Homebase har allerede et støtteverktøy for kundebehandlere; en intern wiki. Dette er en samling av lenker og artikler for feilsøking, informasjon og rutiner. For kundebehandlerne kan det være vanskelig å navigere seg frem til relevant informasjon som skal tas med i feilsøkingsprosedyren, mens de har en kunde på tråden. Dersom en kundebehandler ikke får løst problemet til en kunde, må en oppfølgingssak opprettes. Denne sendes til 2.-linje support, heretter omtalt som backoffice. Denne avdelingen mottar saken og feilsøker videre. Backoffice er avhengig av god loggføring; hva som har blitt forsøkt, hvor problemet oppstår og eventuelle andre kommentarer fra kundebehandler. Slik det er per dags dato inneholder oppfølgingssakene ofte mangelfull informasjon og enkelte ganger har viktige feilsøkingssteg blitt oversett. Dette fører til unødvendig ekstraarbeid for backoffice. Homebase ønsker et verktøy som hjelper kundebehandlere med feilsøking og loggføring på en effektiv måte. 10/136 6

11 Prosessrapport 1.4 Mål og rammebetingelser Hovedmålet med oppgaven er å utvikle en brukervennlig web-basert applikasjon som skal gjøre feilsøking og loggføring lettere for Homebase sine kundebehandlere. Bruk av applikasjonen skal også øke kvaliteten på loggføring slik at oppfølgningssaker lettere kan behandles av backoffice. Systemet skal hovedsakelig tilby sjekklister basert på rutiner fra Homebase sin wiki. En kundebehandler skal kunne krysse av for utført feilsøk, underveis i en kundesamtale. Etter endt samtale vil kundebehandleren ha muligheten til å kopiere ut data og lime det inn i et loggføringsprogram. Vi skal fokusere på å lage et rammeverk med god funksjonalitet for feilsøking. Oppdragsgiver ønsker at vi implementerer et administrasjonspanel i applikasjonen. Her skal man ha mulighet til å legge til, redigere og slette innhold. Det er Homebase som står ansvarlige for innholdet som legges inn i applikasjonen. Likevel legger vi inn noen sjekklister og annen relevant data, for å gi en realistisk opplevelse av sluttproduktet. 11/136 7

12 Prosessrapport 2. Planlegging og metode 2.1 Før prosjektstart Semesteret før hovedprosjektet, hadde vi allerede bestemt oss for at vi skulle jobbe sammen i gruppe, og vi diskuterte mulige oppgaver allerede da. Vi kom frem til at vi ønsket å enten jobbe med forbedring av et eksisterende produkt (feks. et nettsted eller en app ), eller å lage noe fra bunnen av. Vi bestemte oss senere at det skulle være oppdragsgiveren og deres behov som ville avgjøre hvilken type prosjektoppgave vi endte opp med. Det viste seg å være vanskeligere å finne en oppdragsgiver enn vi hadde trodd. Til å begynne med hadde vi utformet en søknadsmal som presenterte gruppemedlemmene, skolen og studierettningen vi gikk. I søknaden listet vi videre opp fagene vi har hatt i studietiden og type arbeidsoppgaver vi var interessert i. Malen ble hovedsakelig sendt til IT-selskaper innenfor utvikling, drift og konsulenttjenester. I tillegg la vi ut søknaden på forumene og for å se om det var noe å få tak i der. Siden responsen var fraværende, bestemte vi oss for å bruke våre egne nettverk for å se om vi kunne få tak i en oppdragsgiver. Kort tid før statusrapporten skulle leveres, hadde gruppemedlem Karl funnet en mulig oppgave. Hans søster trengte hjelp til å forbedre nettstedet sitt; Grorud Gård driver et dyrehotell og en rideskole. Det var ønskelig å blant annet implementere et bookingsystem for dyrehotellet. Da vi leverte statusrapporten, var det denne idéen vi presenterte til intern veileder. Etter at statusrapporten var levert, meldte gruppemedlem Aria ifra om at bedriften hun tidligere jobbet deltid hos, var interessert i et møte med oss. Bedriften heter Homebase AS og er et datterselskap av bredbånd- og kabeltv-leverandøren Get AS. Gruppemedlem Karl og Morten jobber for tiden som kundebehandlere hos Get og Fredrik jobber i Homebase sin kundeserviceavdeling. Siden vi alle hadde god kjennskap til kundeservice, ønsket vi å inngå et samarbeid med Homebase. Vi forhørte oss med intern veileder om det var mulig å bytte oppdragsgiver, selv om statusrapporten var levert. Han svarte at dette ikke skulle være noe problem. 12/136 8

13 Prosessrapport 16. januar 2013 hadde vi et uformelt møte med Homebase. Vi hadde forberedt en idé om å lage en interaktiv feilsøkingsguide for kundene deres, men de var heller interessert i å få utviklet et feilsøkingsverktøy for kundebehandlere. Dette virket spennende for oss, og vi ga beskjed om at vi var interesserte. Mens vi avventet et endelig svar fra Homebase, opprettet vi noen interne dokumenter. Det ble laget en risikoplan, som kartla potinsielle risikoer gruppen kunne støte på. (Se vedlegg 2. Risikoplan). Gruppen laget også en samarbeidsavtale. Avtalen beskrev ambisjonsnivå, arbeidsmengde og våre forventninger til hverandre. (Se vedlegg 3. Samarbeidsavtale) 21. januar 2013 fikk vår kontaktperson på Homebase, Angelica Dalhaug, klarsignal fra ledelsen til å igangsette et samarbeid med oss. 2.2 Prosjektstyringsdokumenter Arbeidsplan Gruppen har satt sammen en aktivitetsplan i Google Drive, som alle kan jobbe på samtidig. I utgangspunktet inneholdt denne kun de ulike arbeidsfasene, men etter hvert også konkrete arbeidsoppgaver og aktiviteter. Den er satt opp med følgende hovedkategorier: Innledende arbeid Datainnsamling Utforming og Design Implementering Testing og Feilsøking Dokumentasjon Avslutning Ved å hele tiden gå gjennom oppsettet og punktene til denne planen, sørget vi for at dette var vårt mest oppdaterte dokument. Aktivitetsplanen var et godt styringsdokument som holdt oss oppdatert på hva som skulle gjøres. Den viste også hvem som var ansvarlig for ulike aktiviteter, hvilken prioritet en aktivitet hadde, versjonnummer, start- og slutt dato, eventuelle forsinkelser og frister. De enkelte aktivitetene var også fargekodet etter prioritet; lav, middels eller høy. Figur 1 viser et lite utsnitt fra denne. 13/136 9

14 Prosessrapport Figur 1. Utsnitt av delt aktivitetsplan fra fasen Innledende arbeid Fremdriftsplan Fremdriftsplanen besto av hoveddelene i prosjektet og viste hvor lang tid man regnet med å bruke på hver fase. Vi brukte programmet GanttProject for å lage et Gantt diagram. Diagrammet illustrerte størrelsen på de forskjellige fasene og hvilke faser som overlappet. Milepæler ble brukt for å markere når en fase var avsluttet. (Se vedlegg 4). Planen hjalp oss med å holde oversikt over tidsfordelingen i prosjektperioden Møtereferat I første fase av prosjektet var gruppemøtene relativt formelle og strukturerte, da det var en del planlegging som skulle gjøres. Ved hvert møte ble det ført referater som ble lagt ut på prosjektsiden. Disse inneholdt dato, navn på tilstedeværende gruppemedlemmer, og en oppsummering av hva vi hadde kommet frem til, samt oppgaver til neste møte Prosjektdagbok Prosjektdagboken var et godt hjelpemiddel for oss. Vi anså det som god praksis å bruke dagboken som en slags loggføring. Det var opp til den enkelte å vurdere om noe burde loggføres eller ikke. Tommelfingerregelen var at større endringer, utfordringer, tanker og andre viktige ting, skulle skrives ned mens de lå ferskt i minnet. Dokumentet var en god ressurs å ha når vi jobbet med prosessrapporten og bidro til gode beskrivelser av viktige hendelser. (Se vedlegg 5. Prosjektdagbok). 14/136 10

15 Prosessrapport 2.3 Arbeidsteknikker og utviklingsmetoder Nedenfor vises en oversikt over hvordan vi arbeidet i løpet av prosjektperioden, og hvilke utviklingsmetoder vi tok i bruk Extreme Programming ( XP ) Utvikingsmetoden vi har basert arbeidet på heter Extreme Programming. Dette er en metode innen agil utvikling som baserer seg på følgende karakteristikker: Hyppige utgivelser (mange versjoner) Pair Programming (to personer programmerer sammen på én maskin) Korte og iterasjonsbaserte utviklingssykluser Hyppig testing Kodeanalyse Det har vært fokus på rask og hyppig utvikling av funksjoner. Tanken bak dette var at vi først skulle lage et skall, for så å bygge funksjonaliteten steg for steg. Etter å ha testet og godkjent en funksjon, gikk vi videre til neste. Arbeidsdisiplinen har ikke blitt fulgt til punkt og prikke, men vi tatt i bruk de vi syntes var relevant for vårt prosjekt. Utfordringer: Koden som vi jobbet på lå i en delt mappe i Dropbox, slik at alle gruppemedlemmene når som helst kunne redigere denne. Erfaringsmessig er det tryggere å bruke et versjonskontrollsystem, slik som GIT. Da vil man først hente ned nyeste versjon av programmet, for så å oppdatere filene i den delte mappa med sine endringer. Versjonkontroll ble ikke brukt i prosjektet, og det ble derfor rotete til tider. Etter å ha sett hvor mye ekstraarbeid som skulle til for å få ryddet opp i kode, bestemte vi oss løse dette ved å endre arbeidsstruktur. Gruppemedlem Morten ble hovedansvarlig for kodingen, og alle endringer gikk via han. 15/136 11

16 Prosessrapport Workshops Vi hadde gruppearbeid jevnlig. Som regel reserverte vi grupperom på skolen, og jobbet sammen der. Enkelte ganger jobbet vi også hjemme hos et av gruppemedlemmene, hvis det var dårlig med plass på skolen. I disse arbeidsøktene følte vi at mye arbeid ble gjort. Det var produktivt og effektivt, fordi man raskt kunne dele tanker og forslag med de andre gruppemedlemmene. Dermed kunne man få tilbakemelding med en gang, som førte til at avgjørelser kunne bli tatt relativt fort. En typisk dag tidlig i prosjektperioden: Jobbet på skolen Etterhvert økte vi arbeidsmengden, og dagene så typisk slik ut: Gruppearbeid på skolen/hjemme hos gruppemedlem, kl Jobbet videre hjemmefra, over skype, 1-3 timer på kveldstid Ansvarsområder I starten av prosjektet, fordelte vi styringsdokumentene mellom gruppemedlemmene. Slik fikk alle ansvar for ulike dokumenter som skulle opprettes i den tidlige fasen. Etterhvert ble det naturlig at gruppen delte seg, og vi fordelte ansvarsområdene parvis. To av gruppemedlemmene hadde ansvar for design, brukertesting og dokumentasjon. De to andre var ansvarlige for utvikling av hi-fi prototype, funksjonstesting og koding av applikasjonen Skypemøter Når gruppen ikke hadde mulighet til å samle seg, jobbet vi hjemmefra. I disse tilfellene ble Skype brukt som et kommunikasjonsmiddel for samarbeid; utveksling av ideer og tilbakemeldinger på arbeid. Her vekslet vi mellom å chatte, holde konferansesamtaler og sende hverandre filer eller nyttige lenker. Skype ble brukt som et supplement til de andre hjelpemidlene og verktøyene. 16/136 12

17 Prosessrapport Intern Prosjektveileder Geir Skjevling var vår veileder for dette prosjektet. I begynnelsen av prosjektfasen hadde vi ukentlige møter med Geir. Han kom med gode innspill og forslag til løsninger hvis vi sto fast. Han var en god ressurs å ha når vi hadde tekniske spørsmål. Da vi hadde kommet godt i gang med prosjektet, reduserte vi antall møter med prosjektveileder til 1-2 ganger i måneden. Ut over dette sendte vi e-post hvis vi hadde noen enkle spørsmål eller trengte tilbakemeldinger på dokumenter Kontaktperson hos bedrift Angelica Dalhaug var vår kontaktperson hos Homebase AS. Hovedfunksjonene til produktet diskuterte vi tidlig sammen med Angelica. Hun hadde derfor en sentral rolle i utformingen av det første utkastet til kravspesifikasjonen og prototypen. Det var Angelica som skaffet oss arbeidsrom, kandidater for brukertesting og andre ressurser. 2.4 Verktøy Utviklingsverktøy NetBeans Netbeans IDE er brukt som et utviklingsverktøy. Programmet er oversiktlig, tilbyr live syntax-sjekking og intelli-sense, som gjør at navn på variabler og funksjoner blir foreslått i sanntid. Programmet krever at man lager et eget project, som gjør det ikke egner seg for redigering av enkeltfiler. Notepad ++ Notepad ++ ble også brukt som et utviklingsverktøy. Dette er et enkelt program for å redigere kode. Det har syntax sjekking i PHP, HTML, CSS, SQL, og mange flere språk. Det er svært raskt og stabilt, gir god oversikt, og har rikelig med funksjoner. 17/136 13

18 Prosessrapport FileZilla FileZilla tilbys som open source programvare. Den er en FTP klient som tilbyr enkel opp- og nedlastning av filer til og fra server. Programmet har vært nyttig i arbeidet med å laste opp filene til publisering på web-server. phpmyadmin phpmyadmin er en gratis web-basert applikasjon for å administrere databaser. Programmet ble brukt til oppretting, endring og testing av tabeller, samt eksportering og importering av SQL-filer. phpmyadmin er inkludert i mange av de mest populære webutviklingspakkene. Figur 2 viser et utsnitt av phpmyadmin. Figur 2. Utsnitt fra programmet phpmyadmin XAMPP Xampp er en programpakke til Windows som installerer Apache, MySQL, PERL og PHP samtidig. Pakken inkluderer også phpmyadmin. Det kommer med et smart og oversiktlig kontrollpanel, hvor du kan skru av og på de ulike tjenestene. Man kan da kjøre websider for å testing lokalt. 18/136 14

19 Prosessrapport Andre verktøy Adobe Photoshop Adobe Photoshop CS6 ble brukt til bildebehandling.programmet støtter også batch-mode, som gjør det mulig å endre mange bilder samtidig. Dette var nyttig for blant annet å nedskalere mange bilder på en gang. Adobe Illustrator Adobe Illustrator CS5 er en vektorbasert programvare for grafikkbehandling. Programmet ble brukt til oppretting av ikoner og grafikk til applikasjonen Hjelpemidler Dropbox Nettskytjenesten Dropbox ble brukt for enkel lagring og deling av filer med hverandre. En stor fordel med å bruke denne tjenesten, er at vi hadde filene tilgjengelig overalt, uansett hvilken datamaskin vi valgte å bruke. Google Drive Google Drive er en nettbasert tjeneste, som gruppen har brukt under hele prosjektperioden. Drive gjør det mulig for flere å jobbe på samme dokument, samtidig. Tjenesten tilbyr blandt annet tekstbehandling, regneark og presentasjoner. Fordelen er at den gir tilgang til dokumentene fra alle datamaskiner som har nettilkobling. Microsoft Word Da vi skulle sette sammen alle dokumentene til en sluttrapport, valgte å bruke Microsoft Word. Dette fordi Google Drive har noen begrensninger i forhold til formatering, særlig ved eksportering til PDF-fil. Gruppen har god erfaring med Microsoft Word, som i dag blir ansett som standarden for tekstbehandling. Sluttrapporten ble formatert med overskrifter, innholdsfortegelse, topptekst, og sidetall /136

20 Prosessrapport Skype Gruppen jobbet av og til hjemmefra. I disse tilfellene ble Skype brukt som et kommunikasjonsmiddel for samarbeid, utveksling av ideer og tilbakemeldinger på arbeid. Her vekslet vi mellom å chatte, holde konferansesamtaler og sende hverandre filer eller nyttige lenker. Facebook Facebook har blitt brukt som et kommunikasjonsmiddel. Ved prosjektets start, opprettet vi en privat facebook-gruppe, som ble delt med alle medlemmene. Denne har vi hovedsakelig brukt til planlegging av møter, og for å informere om reservering av grupperom. 20/136 16

21 Prosessrapport 3. Utviklingsprosessen Nedenfor vises en oversikt over de forskjellige utviklingsfasene i prosjektet, hvordan utviklingsprosessene ble gjennomført, samt hvilke utfordringer vi har støtt på underveis. 3.1 Prosjektstart Prosjektet startet offisielt etter at Homebase takket ja til å samarbeide med oss den Prosjektside for gruppemedlemmer Før prosjektet startet, opprettet vi en nettside for gruppen. Her viste vi fremdriften i prosjektet, informasjon om gruppemedlemmer og møtereferater. Rapporter, avtaler og andre viktige dokumenter ble også lastet opp her. Prosjektsiden var også ment for å holde veileder og oppdragsgiver oppdatert Forprosjektrapporten Kort tid etter at prosjektet var i gang, drøftet vi feilsøkingskonseptet med oppdragsgiver. Målet var å komme frem til en felles forståelse av hva som skulle lages. Deretter begynte arbeidet med forprosjektrapporten og første utkast av kravspesifikasjonen Kartlegging av prosjektfaser Da vi jobbet med forprosjektrapporten, opprettet vi skisser for det som skulle bli arbeidsplanen og fremdriftsplanen. De var ment for å tydeliggjøre hva som skulle gjøres, og når. Underveis i prosjektet, ble disse stadig oppdatert, slik at vi hadde en god oversikt over prosjektets faser. 21/136 17

22 Prosessrapport 3.2 Konseptutvikling I første møte med oppdragsgiver kom det tydelig frem at de ønsket en applikasjon for å hjelpe kundebehandlere med feilsøking og loggføring. Applikasjonen skulle også ha en administratordel, slik at Homebase har mulighet til å endre og oppdatere innholdet selv. Forprosjektrapporten inneholdt første versjon av kravene til feilsøkingsverktøyet. Her fokuserte vi på hvilke funksjoner en kundebehandler ville trenge ved bruk av systemet Datainnsamling Som tidligere nevnt, bruker Homebase en intern wiki som kunnskapsdatabase for sine kundebehandlere. Vi så på informasjon som eksisterte der, og noterte oss elementer vi mente var viktig å ta med videre i utviklingen. To av gruppemedlemmene har også jobbet som kundebehandlere for Homebase. Vi hadde derfor et godt utgangspunkt til å forstå forskjellige utfordringer som kan oppstå når man feilsøker. Det ble holdt flere gruppemøter, der vi diskuterte og noterte ned hva som var viktig å få med i løsningen vår Normalflyt Da vi hadde samlet inn nok opplysninger, startet vi med å utforme normalflyten til systemet, som vist i figur 3. Vi gjorde dette blant annet for å få oversikt over systemet; finne ut hvor mange sider løsningen ville bestå av, og for å tydeliggjøre hvor mesteparten av funksjonaliteten skulle ligge. Her fant vi nye krav som ble lagt til i kravspesifikasjonen. 22/136 18

23 Prosessrapport Figur 3. første utkast av normalflyt for kundebehandlere Konseptskisse Vi ønsket å tidlig visualisere konseptet. Derfor utarbeidet vi flere skisser, som ga oss idéer til hvordan brukergrensesnittet kunne se ut. Skissene ble utviklet i Adobe Photoshop, og la grunnlaget for prototypen vi laget senere. Eksempel på en av skissene som ble laget i idéprosessen: 23/136 19

24 Prosessrapport Figur 4. tidlig skisse av systemets forside Skissen over viser hvordan vi i utgangspunktet hadde tenkt at applikasjonen kunne se ut. I etterkant fant vi ut at det ikke var nødvendig med de to boksene nederst, siden hovedfokus lå på feilsøking, og ikke nyheter. Derfor bestemte vi oss for å fjerne disse Use-Case Modell Litt over en uke ut i prosjektet, opprettet vi use-case modeller for å få oversikt over alle stegene systemet skulle bestå av. Disse hjalp oss med å avdekke om det var noen kritiske hull i kravspesifikasjonen. Modellene illustrerer også hva en bruker kan gjøre i systemet, og hvordan systemet er ment til å brukes. (se vedlegg 6) Diskusjon med oppdragsgiver Da vi var fornøyde med skissene, ble disse presentert for oppdragsgiver. Use-case modellene og normalflyten i systemet ble forklart muntlig, samtidig som vi viste frem skissene. Disse mottok vi gode tilbakemeldinger på, men vår kontaktperson, Angelica, hadde noen ting å tilføye. Det var et ønske om en funksjon der kundebehandlere kunne rapportere om feil eller mangler på innholdet i feilsøkingsverktøyet. Etter oppdragsgiver sitt ønske, oppdaterte vi kravspesifikasjonen med dette. 24/136 20

25 Prosessrapport 3.3 Utforming og Design Design Vår oppdragsgiver hadde ikke stilt noen krav til brukergrensesnittet. Vi hadde derfor frie tøyler til å utforme løsningen slik vi ville. Samtlige gruppemedlemmer har tidligere hatt flere fag som blant annet omhandler utforming av brukervennlig design. Jacob Nielsens 10 heuristiske prinsipper var ofte nevnt i undervisningssammenheng, når det gjaldt design av brukergrensesnitt. Under en workshop diskuterte vi hvilke av Nielsens prinsipper som ville passe for vår løsning. Andre designvalg ble også diskutert. Da vi var fornøyde, oppdaterte vi kravspesifikasjonen med krav til design og brukergrensesnitt High-fidelity Prototype Prototypen var noe vi startet med tidlig, mer eller mindre parallelt med Use-Case modellen. Vi valgte å lage en high-fidelity prototype istedet for en low-fidelity, fordi det gir flere fordeler. Blant annet vil prototypen ligne på det ferdige produktet og gi en interaktiv opplevelse når man gjennomfører brukertester. Utviklingen ble gjort i HTML5 og CSS. Prototypen inneholder applikasjonens hovedstruktur og feilsøkingssteg. Den viser ikke grensesnittet for administrasjonsdelen. Begrunnelsen for dette valget, er redegjort for under punkt Applikasjonen. Vår strategi for arbeidet med prototypen: 1. Kartlegging og testing av designprinsipper. 2. Starte tidlig med front-end koding for å visualisere konseptet. 3. Brukertesting av prototypen, for å avdekke om vi var på riktig spor. 4. Konvertere prototypen til et ferdig produkt for å minimere programmeringsmengden senere. 25/136 21

26 Prosessrapport Skjermbilder av prototypen: Figur 5. Skjermbilde av prototype - steg 2. Bruker velger kategori. Figur 6. Skjermbilde av prototype - steg 3. Her skal brukeren velge et passende problem /136

27 Prosessrapport Figur 7. Skjermbilde av prototype - steg 4. Her vises sjekklisten for det aktuelle problemet som brukeren har valgt. Brukeren kan samhandle med systemet ved å klikke på lenker, knapper og huke av på sjekklistene. 3.4 Implementering Da vi startet med utviklingen av produktet, sluttet vi med de tradisjonelle møtene. Det ble istedenfor holdt work shops, der vi satt sammen i flere timer og jobbet med ulike oppgaver som skulle løses. Nedenfor vises det til hvordan vi arbeidet i implementeringsfasen Databaseutvikling E/R-modell Før vi kunne begynne for fullt med programmering av applikasjonen, ønsket vi å lage en enkel database, for å kunne bruke persistent data på siden. Gruppen arbeidet i plenum med utviklingen av en overordnet E/R-modell av databasen. Vi gikk gjennom tenkte scenarioer, samtidig som vi førte ned tabellene på papir, som vist i figur 8. 27/136 23

28 Prosessrapport Figur 8. Førsteutkast, E/R-modell for HB Guide Antall hjelpetabeller, koblinger og attributter var ikke tema i denne fasen. Det var kun fokus på hovedentitetene i systemet; brukere, sjekklister, problem, og så videre. Etter mye diskusjon og mange utkast kom vi fram til modellen i figur 9. Figur 9. Endelig E/R-modell for HB Guide 28/136 24

29 Prosessrapport Logisk Skjema Neste steg etter E/R-modellering, var å lage et logisk skjema; en modell over hele databasestrukturen, inkludert alle hjelpetabeller og attributter. Morten og Fredrik var ansvarlige for å utforme denne, samt opprette den i en databaseapplikasjon. Database Vi visste hvilke tabeller, nøkler og attributter som skulle lages i databasen, og hadde ikke regnet med at strukturen måtte endres noe særlig etter at den var opprettet. Vi var alle enige om hvilken informasjon som skulle legges hvor, og vi så for oss hvordan spørringene ville fungere. Det viste seg etterhvert at nye atributter og koblinger måtte opprettes. For hver endring vi gjorde, eksporterte vi en ny.sql-fil fra som vi la i en delt mappe i Dropbox. Slik kunne de som trengte det, oppdatere sin lokale database Koding Feilsøkingsverktøyet ble hovedsakelig kodet i PHP, HTML og CSS. Alt ble kodet fra bunnen av, uten hjelp fra noe rammeverktøy. Det vi brukte til å bygge opp koden, var programmeringsverktøy Netbeans og Notepad++. Alle funksjoner og viktige elementer i koden ble kommentert slik at det skulle bli enklere å forstå hvordan løsningen vår er satt sammen. Det ble opprettet egne filer for funksjoner og klasser, for å holde ting ryddig. Under testing av kode, var det ikke alltid ting fungerte som forventet. Det ble da gjort søk på google for å finne frem til løsninger. (PHP, 2013) og (StackExchange, 2013) ble brukt flittig, og ga oss svar på flere av problemene som oppstod underveis. Det skal også sies at vi kontinuerlig har iterert koden gjennom hele prosjektperioden. 29/136 25

30 Prosessrapport Utfordringer: ÆØÅ-problem Vi hadde problemer med at bokstavene ÆØÅ ikke ble vist riktig i applikasjonen. Vi fant etterhvert ut at det kun gjaldt informasjon som ble hentet fra databasen. Det som ble liggende med ÆØÅ i databasen var problemet, mens det som ble lagret i UTF-8 (se ordliste) ble vist riktig. Problemet ble løst da vi fjernet UTF-8 decode-funksjonen, som vi tidligere hadde lagt inn for å få ÆØÅ til å vises riktig i databasen. Dette kunne løses med funksjonen UTF-8 encode, men dette måtte i så fall gjøres med all tekst som skulle hentes fra databasen.vi valgte derfor å droppe decode funksjonen, dette gjør at ÆØÅ ser litt rart ut i databasen, men det vises riktig i applikasjonen. Innlogging Problemene vi hadde med ÆØÅ, gjorde at vi hadde feilsøkt med mange forskjellige tegnsett. Dette førte til at det oppstod et nytt problem med innlogging på siden når den publisert på server. På localhost fungerte innlogging helt fint, men når vi la den ut på en server ble man logget ut like etter at man ble logget inn. Vi fant etterhvert ut at dette skyldtes et usynlig tegn foran <? php session_start();?> i koden. Dette hadde skjedd under bytting av tegnsett. En annen utfordring var at dette tegnet også var usynlig i Notepad ++, men åpnet man dokumentet i NetBeans, var det bare å fjerne tegnet og lagre, så løste problemet seg. Problemet hadde oppstått under feilsøking av hvorfor ÆØÅ ikke fungerte, hvor vi byttet tegnsett på dokumentet flere ganger. JavaScript Regex-validering Vi ønsket at alle input-felter i applikasjonen skulle valideres etter regulære uttrykk ( regex - se ordliste) på to nivåer; javascript på klient-siden og PHP på server-siden. Det skal sies at JavaScript-validering ikke er noen form for sikkerhet, fordi man simpelten kan skru av JavaScript i nettleseren sin for å komme rundt en slik sjekk. Det er likevel en nyttig implementering, siden brukere med javascript aktivert kan se om dataen de sender inn er godkjent, før den godkjennes av PHP på server siden. 30/136 26

31 Prosessrapport Figur 10 - ønsket javascript-funksjon for validering av input Det var problematisk å få implementert funksjonen slik vi ønsket. Vi forhørte oss med veileder, og gjorde mange søk på Google uten hell. Siden vi fant ut at det gikk an å validere input-felter med HTML5, valgte vi å kutte ut JavaScript-validering. HTML5-valideringen er ikke like presis som en Javascript validering, men den gjør at man kan definere obligatoriske felter Applikasjonen Da databasen var klar, implementerte vi denne i prototypen og begynte å lage funksjoner. To av gruppemedlemmene hadde god innsikt i webprogrammering fra før, så det var naturlig at de fikk hovedansvaret. Fancybox-scriptet som ble brukt til bildevisning, krevde at vi måtte lære en del JavaScript kode. Heldigvis var dette godt dokumentert på nettet. Vi fant en fin veiledning for hvordan man bruker Fancybox. (Fancybox, 2013). I starten av utviklingen brukte vi en del tid på å lage alle funksjonene, klassene og databaseoppsettet som måtte være med i løsningen. Dette ble ikke helt perfekt i første omgang, og vi måtte gjøre endringer i løpet av utviklingsprosessen. Endringene som ble gjort, førte ikke til noen store konsekvenser. 31/136 27

32 Prosessrapport Utfordringer Opprinnelig hadde vi tenkt at systemet skulle vise frem bilder av utstyr relatert til en spesifikk site. Dette viste seg å være vanskelig å gjennomføre, og det ville medført mye arbeid ved innlegging av nytt utstyr. Administrator måtte da ha valgt fra en lang liste med mange sites, og hvilke sites som hadde dette utstyret tilgjengelig. Her ville det oppstått scenarioer hvor et utstyr hørte til svært mange sites, men ikke samtlige. Dette ville ha medført mye arbeid for administratoren, og vi bestemte oss derfor for å fjerne koblingen mellom site og utstyr Administrasjondelen av applikasjonen I arbeidet med utviklingen av administrasjonssiden, valgte vi å ikke lage noe flytdiagram eller prototype. Dette var et bevisst valg, fordi vi var alle enige om at det ikke var nødvendig. Kriteriet for administrasjonssiden var hovedsaklig at alle delene av applikasjonen, som inneholdt informasjon for å hjelpe kundebehandlere, skulle kunne redigeres. Så lenge dette ble gjort på en god måte, så vi ikke noe poeng i å bruke tiden vår på noe annet en koden. Det er heller ikke en stor brukergruppe for adminpanelet. Det var derfor tilstrekkelig å vise denne til vår oppdragsgiver, samt en av de ansatte på backoffice. Underveis i utviklingen fikk vi tilbakemelding om hva som kunne endres, men alt i alt tok det ikke lang tid å gjøre disse endringene. Som designprinsipp valgte vi å legge administrasjonsmenyen linjært øverst på siden, i samme stil som brødsmulestien i brukerdelen. Dette for å opprettholde konsistens. Egne sider ble opprettet for å administrere brukere, sites, utstyr, problemer, sjekklister, lenker og bilder. Vi gjorde dette for å unngå å ha for mange valg per side. Da administrasjonspanelet begynte å bli ferdig, oppdaget vi at enkelte situasjoner ikke var helt selvforklarende. Løsningen ble å legge til hjelpetekst i form av spørsmålstegn-ikoner som man kan holde musepekeren over, for å se hjelpetekst. 32/136 28

33 Prosessrapport Utfordringer: Bildeopplastningsscript Det var enkelte funksjoner vi hadde problemer med å lage fra bunnen av. Vi forsøkte å lage et bildeopplastningsscript, men fant fort ut at dette ble for vanskelig, siden vi ikke hadde nok kunnskaper om PHP sitt GD-bibliotek. Vi løste dette ved å ta i bruk et open-source script som tilbydde de funksjonene vi syntes var nødvendig, blant annet bildeopplasting, størrelseendring og støtte for flere formater. Det var ganske komplekst å forstå så det måtte en god del prøving og feiling til. Gjennomsiktighet i bilder Gjennomsiktighet i PNG-bildefiler var et stort problem. Når man prøvde å endre størrelsen på et bilde, ble den gjennomsiktige bakgrunnen erstattet med svart. Det var mange delte meninger på ulike forumer om hvordan dette kunne løses. Vi prøvde så mange forslag vi rakk, men vi måtte gi opp til slutt, rett og slett fordi vi brukte for mye tid på det. Det var andre ting som måtte prioriteres. Dette ble ikke løst innen fristen for innlevering 28.mai. Tiden som ble brukt på å feilsøke dette, kunne heller blitt brukt til å muliggjøre opplasting av flere bilder på en gang. 3.5 Testing og feilsøking Brukertesting av prototype Tidlig i implementeringsfasen utførte vi en brukertest som foregikk i oppdragsgiver sine lokaler. Her lånte vi ansatte fra både frontoffice og backoffice. Vi tok inn én ansatt om gangen og fikk dem til å gå igjennom ulike scenarioer mens vi tok notater. Vi spurte også de ansatte noen åpne og lukkede spørsmål. Planleggingen av testene er beskrevet i vedlegg 7. Testplan. For detaljert beskrivelse av brukertestingen og dens påvirkning på sluttproduktet, se Del IV, Testrapport. 33/136 29

34 Prosessrapport Sikkerhet Av sikkererhetsmessige årsaker, bestemte vi oss for å beskytte mot SQL-injection (se ordliste), gjennom Regex funksjoner og mysqli_real_escape_string. Passord til brukere er kryptert med salt + hash som gjør at disse de blir tilstrekkelig beskyttet. Salt er en tilfeldig generert string på 20 tegn som legges på passordet før det krypteres med hash. Selv om noen skulle fått uautorisert tilgang til informasjonen i databasen, vil det være vanskelig å finne et gyldig passord. Alle sider er avhengig av at man er logget inn for å vise noe innhold Optimalisering av kode All kode var, fra begynnelsen av, ment å være objektorientert, for at systemet skulle være så oversiktlig og effektivt som mulig. Et objekt skulle lett kunne opprettes og dets metoder kalles. Etterhvert så vi at det ble noe gjentakende kode. Et eksempel på kode som gjentas, er den som kontrollerer at en MySQL spørring fungerer. Se Figur /136 30

35 Prosessrapport Figur 11 - funksjonen som sender og sjekker spørringer til databasen Grunnen til at denne gjentas mye er at man med forskjellige spørringer kan skrive ut forskjellige feilmeldinger om $db->affected_rows==0, dette er det som printes ut om spørringen er korrekt, men det er ingenting i databasen som blir påvirket. I tillegg til klasser bruker vi også noen funksjoner, bl.a. for regex og sjekking av login. Disse ligger i sitt eget dokument, functions.php. Vi endte opp med at det meste av koden som brukes av adminpanelet er objektorientert med hver sine klasser i klasser.php. I applikasjonen er det for det meste ulik kode på alle sidene, og her er all kode på samme side og ikke separert i en klasse eller funksjon. 35/136 31

36 Prosessrapport 3.6 Dokumentasjon Rapporter Vi bestemte oss for å starte tidlig med å skrive i rapporter. Vi opprettet dokumenter for produkt-, prosess- og testrapport som vi, mot slutten av prosjektet, kunne samle sammen for å danne sluttrapporten. Ved å ha disse dokumentene separert, var det enklere å holde oversikt over hvor informasjon skulle plasseres. Vi lagde en mal for hvert dokument; en struktur med kapitler og tematiske overskrifter for hvert punkt. Da grunnstrukturen på dokumentene var på plass, ble det enklere for gruppemedlemmene å gradvis fylle ut rapportene. Vi startet med å plukke ut informasjon som kunne gjenbrukes fra forprosjektrapporten. Møtereferater og notater fra prosjektdagboken brukte vi hyppig, slik at vi kunne være trygge på at prosesser og hendelsesforløp ble beskrevet korrekt. Vi merket oss at det å drive med litt rapportdokumentasjon, parallelt med utvikling av produktet, bidro til redusert stress. Det er veldig vanlig å feilberegne avsatt tid for rapportskrivning og vi ønsket derfor å ha så mye som mulig dokumentert før gruppen begynte siste fasen av sluttrapporten Brukermanual Vi så ikke et behov for en dedikert brukermanual. Det var hovedsakelig to årsaker til dette. For det første viste brukertesten at samtlige deltakere utførte alle oppgavene uten problem. For det andre inkluderte vi hjelpetekst i adminpanelet, for å unngå misforståelser. 36/136 32

37 Prosessrapport 4. Kravspesifikasjonens rolle Kravspesifikasjonen har vært av stor verdi for oss i prosjektperioden. Den har fungert godt som et styringsdokument, og sørget for at vi har holdt oss på rett spor under utviklingen av applikasjonen. Vi startet tidlig med å utarbeide en god kravspesifikasjon. Slik ble det enklere å kartlegge funksjonaliteten til feilsøkingsverktøyet. Den første versjonen av kravspesifikasjonen opprettet vi sammen med vår kontaktperson. Utover dette fikk vi mer eller mindre frie tøyler til å gjøre endringer og justeringer. Skisse, analyse av brukertest og annen innsamlet data, hjalp oss med å avdekke nye funksjoner som førte til flere oppdateringer av kravspesifikasjonen. Den ble altså stadig iterert, og endret i løpet av prosjektperioden. Hver gang vi gjorde betydelige endringer i kravspesifikasjonen, ble disse sendt til vår kontaktperson i Homebase. Som regel var hun enig i kravene vi hadde satt for systemet. Andre ganger hadde hun ønsker om tilleggsfunksjonalitet. Et av kravene vi la til, som et resultat av diskusjon med vår kontaktperson, var kundebehandlernes mulighet til å rapportere om feil eller mangler til innholdet i sjekklistene. Det var enkelte krav vi hadde lagt inn sent i prosjektet, som vi ikke fikk tid til å utføre. Derfor ble de ble fjernet. Dette var krav av typen fint å ha men som ikke var absolutt kritisk for applikasjonen. Vi mener selv at vi har oppfylt alle kravene fra spesifikasjonen, og implementert dem på en god måte. 37/136 33

38 Prosessrapport 5. Resultatet Applikasjonen består av en feilsøkingsguide med fire grunnleggende steg. Informasjonen som dukker opp i løpet av disse stegene er basert på det administrator velger å legge inn av data gjennom administrasjonspanelet. Sluttproduktet ble vist til vår kontaktperson ved Homebase, og hun virket veldig fornøyd. Hun syntes det var responsivt og enkelt for den alminnelige bruker. Sluttproduktet er beskrevet i Del III. Produktrapport. 38/136 34

39 Prosessrapport 6. Evaluering 6.1 Hva kunne vært gjort annerledes Vi ser i ettertid at vi burde ha brukt vårt eget nettverk tidligere, i jakten på et samarbeid med en oppdragsgiver. I stedet for å bruke mye tid på å sende søknader til virksomheter vi ikke hadde kjennskap til fra før, burde vi ha startet med å ta kontakt med de bedriftene der vi hadde kontakter. Dersom vi hadde gjort det, kunne vi ha fått til et samarbeid tidligere i prosjektperioden. Da hadde vi spart oss for en god del tid. Noe annet vi kunne ha gjort annerledes, var innføring av versjonsstyring. Filene vi lagret i Dropbox ble litt vanskelige å holde oversikt over. 6.2 Tilbakemelding fra oppdragsgiver Vår kontaktperson og andre ansatte ved Homebase, har gitt gode tilbakemeldinger på vår applikasjon. Det som særlig har blitt trukket frem som positivt, er muligheten for å generere kopierbar tekst fra sjekklistepunktene som brukeren har huket av. 39/136 35

40 Prosessrapport 7. Avsluttende del 7.1 Samarbeidet i gruppen Gjennom prosjektperioden har vi jobbet noe individuelt, noe samlet og noe parvis. I begynnelsen jobbet vi tett sammen frem til implementeringsfasen. I denne fasen ble gruppen delt opp. To gruppemedlemmer jobbet med programmeringen av hi-fi prototypen og applikasjonen, de to andre jobbet med dokumentasjonen, brukertesting, bilderedigering og andre oppgaver. Vi har hele veien sørget for å holde hverandre oppdatert om fremdriften på det vi har jobbet med. Dersom vi støtte på et problem og sto fast, skulle vi ikke nøle med å be hverandre om hjelp. I prosjektperioden kom vi over slike situasjoner og løste disse i plenum. Alt i alt er samtlige medlemmer fornøyd med innsatsen og samarbeidet. 7.2 Samarbeid med oppdragsgiver Det har blitt holdt jevnlig kontakt med vår oppdragsgiver gjennom prosjektperioden. Naturligvis var kommunikasjonen med vår kontaktperson hyppigere i startfasen og mot slutten av implementeringsfasen. Oppdragsgiver fikk tilgang til en versjon av produktet via vår server. Denne har vi gått gjennom sammen med vår kontaktperson, Angelica, som var svært fornøyd med helheten, men hadde noen få innsigelser. Innsigelsene var: Om man er logget inn som administrator, vises en lenke i applikasjonens sjekkliste til en side hvor man kan endre den aktuelle sjekklisten. Rette opp i lenker på sjekklisten disse ble lenket som og ville vise til en side som ikke finnes. Endre navn på knapp under Rediger utstyr i admin panelet fra Rediger til Lagre. Dette har nå blitt rettet opp i, og siste versjon er sendt til oppdragsgiver. 40/136 36

41 Prosessrapport 7.3 Konklusjon Kunnskap Dette prosjektet har vært spennende, krevende og læringsrikt for oss. Mange av oppgavene vi har gjennomført i denne perioden har gitt oss muligheten til å bruke kunnskap vi har tilegnet oss fra forskjellige fag, som har blitt tatt på Høgskolen i Oslo og Akershus. Det har også vært behov for å tilegne seg ny kunnskap. Javascript var den delen vi kunne minst om, og vi måtte derfor lære oss mer om dette. Arbeidsmetode Vi har gjennom dette prosjektet erfart at det lønner seg å fastsette en tydelig arbeids- og utviklingsmetode helt fra starten. Når det gjelder utviklingsmetode burde vi muligens ha fulgt XP (Extreme Programming) mer nøye, og i tillegg brukt et system for versjonskontroll. Til tider kom vi i tidsklemma og merket fort at det var vanskelig å beregne tidsforbruk i de forskjellige fasene. Dette førte til noen stressende perioder, men vårt gode samarbeid førte til at vi klarte å løse de fleste utfordringene. Hvis vi hadde vært litt flinkere til å planlegge, kunne vi ha minsket antallet av slike perioder. Funksjonalitet Vi klarte å implementere alle funksjonene fra kravspesifikasjonen, men vi ser at det finnes forbedringspotensiale. Det er enkelte kodesnutter vi kunne iterert flere ganger, for å gi bedre funksjonalitet. Dette er noe vi skal se nærmere på etter hovedprosjektet. Alt i alt, syns vi at produktet vi leverte til oppdragsgiver er et godt rammeverk og en stabil applikasjon. Vi er spesielt fornøyde med utformingen av adminpanelet. 41/136 37

42 Kravspesifikasjon DEL II: Kravspesifikasjon 1 42/136

43 Kravspesifikasjon Innhold Forord Innledning Bakgrunnen for prosjektet Funksjonelle krav: Krav til funksjonalitet Krav til administrasjon Krav til design og brukergrensesnitt Ikke-funksjonelle krav Tekniske krav Krav til kode Øvrige krav Konklusjon /136 2

44 Kravspesifikasjon Forord Betingelser som er satt for prosjektet, funksjonalitet til applikasjonen som skal utvikles og krav til design finnes i dette dokumentet. Dokumentet er også en kontrakt mellom oppdragsgiver og studentene om hva som skal gjøres i prosjektperioden. Oppdragsgiver stilte i utgangspunktet få krav til applikasjonen. Det er hovedsakelig vi som har utarbeidet de funksjonelle kravene og andre krav. Underveis i prosjektet har oppdragsgiver kommet med nye ønsker, etter å ha sett på prototypen. Kravspesifikasjonen har derfor blitt oppdatert flere ganger i prosjektperioden. Dokumentet er delt opp i tre deler; Funksjonelle Krav, Ikke-funksjonelle krav og Dokumentasjonskrav. Funksjonelle krav er ytterligere delt opp i tre deler; feilsøkings-del, administrasjon-del og design-brukergrensesnitt. Ikke-funksjonelle krav inneholder tekniske krav, krav til ytelse og andre krav ikke direkte knyttet til en funksjon. Dokumentasjonskrav er krav som omfatter prosjektets dokumentasjon. Kravspesifikasjonen har fungert som en rød tråd igjennom hele prosjektperioden. Den tydeliggjorde hva vi skulle jobbe med og bidro til at vi holdt oss innenfor rammene som var definert. 44/136 3

45 Kravspesifikasjon 1. Innledning Prosjektet skal gjennomføres som hovedprosjekt ved HiOA avd. for Anvendt Datateknologi, i samarbeid med Homebase AS. Kort oppsummert består oppgaven av å utvikle en feilsøkingsapplikasjon for kundebehandlere. Det skal være en nettbasert plattform utviklet hovedsakelig i PHP og HTML. Applikasjonen skal inneholde sjekklister som en kundebehandler kan krysse av på underveis i en kundesamtale. Kundebehandleren vil få mulighet til å kopiere ut det som er sjekket av og lime dette inn i sitt loggføringsprogram. Formålet er å optimalisere feilsøkingsprosessen og kvalitetssikre loggføringen. Det skal også utvikles en administrasjon-del slik at oppdragsgiver selv kan stå for innholdet i applikasjonen. 45/136 4

46 Kravspesifikasjon 2. Bakgrunnen for prosjektet Homebase AS er et datterselskap av Get AS, som leverer IP-TV, IP-telefoni og Internett i mange ulike deler av landet. Homebase Kundeservice tilbyr support til kunder som trenger hjelp med disse tjenestene. Enkelte ganger må kundebehandlere sende en sak til backoffice (se ordliste) for å få kundens henvendelse løst. Backoffice mottar saken og feilsøker videre. Avdelingen er avhengig av god loggføring, men ofte inneholder oppfølgningssakene mangelfull informasjon. Enkelte ganger har viktige feilsøkingssteg blitt oversett. Dette fører til unødvendig ekstra arbeid. Homebase ønsker et verktøy som hjelper kundebehandlere med feilsøking og loggføring på en effektiv måte. 46/136 5

47 Kravspesifikasjon 3. Funksjonelle krav: 3.1 Krav til funksjonalitet Oppdragsgiver ønsker hovedsakelig at man skal kunne bruke sjekklister for å krysse av på de feilsøkingsstegene som er utført. Denne informasjonen skal så kunne kopieres ut for videre loggføring. Nedenfor er en liste som beskriver funksjonaliteten vi mener må være grunnleggende i applikasjonen. Systemet skal tilby: Mulighet til å logge inn og ut. To type brukerkontoer; administrator og ansatt. Kun leserettigheter for standard brukerkonto Sjekklister til forskjellige typer problem Muligheten til å generere tekst-sammendrag ut i fra det som er avhuket i sjekklisten Bildevisning av teknisk utstyr Alle brukere har mulighet til å rapportere feil i sjekklister eller annen informasjon Feilrapport sendes fra et web-skjema til en valgfri epost-adresse. Skjema skal inneholde følgende obligatoriske felt: Navn, emne, e-post og kommentar. 47/136 6

48 Kravspesifikasjon 3.2 Krav til administrasjon Systemet skal tilby administrator: Muligheten til å enkelt kunne slette, redigere eller legge til informasjon. Muligheten til å slette, redigere eller legge til bilder. Muligheten til å slette, redigere eller legge til sites. Muligheten til å slette, redigere eller legge til problemstillinger. Muligheten til å slette, redigere eller legge til sjekklister. Muligheten til å slette, redigere eller legge til lenker Muligheten til å slette, redigere eller legge til utstyr. Muligheten til å slette, redigere eller legge til brukere. 3.3 Krav til design og brukergrensesnitt Feilsøkingsdelen skal fungere som en guide for kundebehandlere: Feilsøkingssteg skal være tydelig markert for å veilede brukeren Applikasjonen skal følge gode retningslinjer for brukervennlighet: Hvert steg skal være kort og presist. Brukergrensesnittet skal være enkelt og minimalistisk. Brukere kan lett avbryte en sekvens i systemet. Brukere skal til enhver tid vite hvor de befinner seg ved hjelp av en brødsmulesti. Hver side skal inneholde få elementer. Alle bildeikoner skal ha tilhørende tekst. Det skal brukes hjelpetekst på administratorsiden. 7 48/136

49 Kravspesifikasjon 4. Ikke-funksjonelle krav 4.1 Tekniske krav Applikasjonen skal være nettbasert og bygget opp av HTML, PHP & CSS Verktøyet skal ha rask responstid. Ingen av normalfunksjonene skal ta mer enn 1 sekund å fullføre MySQL skal brukes for lagring av data Nettsiden skal være optimalisert for nettleseren Internet Explorer 8.0 Nettsiden skal også fungere i alle senere versjoner av Internet Explorer, samt siste versjon Google Chrome, Mozilla Firefox og Apple Safari. 4.2 Krav til kode For å unngå duplisering av kode, bidra til effektivitet og et dynamisk verktøy, brukes funksjoner og objektorientert PHP Kode skal være godt kommentert Navn på funksjoner, klasser og variabler skal ha logiske navn. 8 49/136

50 Kravspesifikasjon 5. Øvrige krav 5.1 Applikasjonen skal ikke ligge fritt på HiOA sine sider, filer som legges ut skal være passordbeskyttet 5.2 Sluttrapporten skal bestå av følgende selvstendige deler; prosessdokumentasjon, kravspesifikasjon, produktdokumentasjon og testrapport. 5.3 Sluttrapporten, inkludert produktet, skal leveres til sensur senest Konklusjon Kravspesifikasjonen har vært et sentralt dokument i dette prosjektet. Den har gitt prosjektgruppen faste rammer å gå etter. Etter hvert som et av kravene ble oppfylt, ble de markert som ferdig i dette dokumentet, og siden dokumentet er delt, kunne alle se hva som gjenstod. Denne markeringen fjernet vi før innleveringen.enkelte krav ble slettet og enkelte lagt til underveis i prosjektgangen. Alle større endringer ble gjort i samsvar med oppdragsgiver. Vi fikk ganske frie tøyler av oppdragsgiver. I starten gjorde dette at det ble vanskelig å se for seg hvilke krav som burde tas med. Det var derfor en stor fordel at samtlige gruppemedlemmer har erfaring med brukerstøtte. For en beskrivelse av hvordan produktet samsvarer med kravspesifikasjonen, se Del III, Produktrapport, punkt 3. Funksjonalitet. 50/136 9

51 Produktrapport DEL III: Produktrapport 1 51/136

52 Produktrapport Innhold Forord Innledning Gruppen Oppdragsgiver Dagens situasjon Mål og rammebetingelser Beskrivelse av applikasjonen Generell beskrivelse Systemets posisjon Installasjonsveiledning Forutsetninger Kildekode Oppsett av database og tabeller med MySQL Oppsett av konfigurasjonsfil Sikkerhet Kodespråk HTML5 og CSS Javascript MySQL Design Oppbygning av brukergrensesnitt Systemet vi har laget, er et nettsted bygget opp av et sett med teknologier; HTML, PHP, CSS og JavaScript Designprinsipper Designvalg Typografi Brukere Standardbruker Administrator Navigasjon / Den globale navigasjonsmenyen for frontoffice Den globale navigasjonsmenyen; for backoffice

53 Produktrapport Brødsmulesti Guide Funksjonalitet Applikasjonen Legge til elementer Oppbygning og virkemåte Introduksjon Kildekode Databasestruktur Forslag til forbedringer og utvidelser Brukergrensesnitt Kreve bekreftelse på endringer Rapportering går til egen side inne i adminpanelet Funksjonalitet Bedre bildeopplastning Fjerne redundans i databasen /136 3

54 Produktrapport Forord Dette dokumentet er prosjektets produktrapport. Den beskriver funksjonalitet, oppbygning og design av applikasjonen. Produktrapporten er ment for sensor, veileder, oppdragsgiver, og de som skal drifte og videreutvikle applikasjonen. Det vil være en fordel at personen som leser rapporten har tekniske forkunnskaper, men det er ikke et krav for å forstå innholdet i rapporten. Datatekniske ord og begreper forklares i egen ordliste. (se vedlegg 1. Ordliste). 54/136 4

55 Produktrapport 1. Innledning 1.1 Gruppen Gruppen består av fire studenter fra studiet Anvendt datateknologi ved Høgskolen i Oslo og Akershus: Karl Øgaard Fredrik Ung Aria Nejad Morten Iversen Gruppen ble stiftet i god tid før prosjektperioden begynte. Samtlige gruppemedlemmer har et høyt ambisjonsnivå og har oppnådd gode resultater ved tidligere prosjekter. 1.2 Oppdragsgiver Homebase AS er et datterselskap av Get AS som leverer IP-TV, IP-telefoni og Internett over åpen infrastruktur i mange ulike deler av landet. De tilbyr følgende tjenester: Skreddersydd TV-pakke av standardkanaler Ekstra kanalpakker fra leverandører som CMORE og Viasat Opptak av TV-kanaler Filmleie Internett IP-telefoni 55/136 5

56 Produktrapport 1.3 Dagens situasjon Homebase kundeservice tilbyr brukerstøtte for kunder som trenger hjelp med bedriftens tjenester; TV, Internett, telefoni, faktura eller salg. Bedriften har kunder spredt over hele landet, tilknyttet ulike fiberleverandører, heretter omtalt som sites. Det tekniske utstyret hos kundene kan variere, avhengig av hvilken site kunden hører til. Konsekvensen av dette er at det blir svært mye teknisk informasjon og ulike feilsøkingsprosedyrer, som kundebehandlerne må sette seg inn i. Homebase har allerede et støtteverktøy for kundebehandlere; en intern wiki. Dette er en samling av lenker og artikler for feilsøking, informasjon og rutiner. For kundebehandlerne kan det være vanskelig å navigere seg frem til relevant informasjon som skal tas med i feilsøkingsprosedyren, mens de har en kunde på tråden. Dersom en kundebehandler ikke får løst problemet til en kunde, må en oppfølgingssak opprettes. Denne sendes til 2.-linje support, heretter omtalt som backoffice. Denne avdelingen mottar saken og feilsøker videre. Backoffice er avhengig av god loggføring; hva som har blitt forsøkt, hvor problemet oppstår og eventuelle andre kommentarer fra kundebehandler. Slik det er per dags dato inneholder oppfølgingssakene ofte mangelfull informasjon og enkelte ganger har viktige feilsøkingssteg blitt oversett. Dette fører til unødvendig ekstraarbeid for backoffice. Homebase ønsker et verktøy som hjelper kundebehandlere med feilsøking og loggføring på en effektiv måte. 56/136 6

57 Produktrapport 1.4 Mål og rammebetingelser Hovedmålet med oppgaven er å utvikle en brukervennlig web-basert applikasjon som skal gjøre feilsøking og loggføring lettere for Homebase sine kundebehandlere. Bruk av applikasjonen skal også øke kvaliteten på loggføring slik at oppfølgningssaker lettere kan behandles av backoffice. Systemet skal hovedsakelig tilby sjekklister basert på rutiner fra Homebase sin wiki. En kundebehandler skal kunne krysse av for utført feilsøk, underveis i en kundesamtale. Etter endt samtale vil kundebehandleren ha muligheten til å kopiere ut data og lime det inn i et loggføringsprogram. Vi skal fokusere på å lage et rammeverk med god funksjonalitet for feilsøking. Oppdragsgiver ønsker at vi implementerer et administrasjonspanel i applikasjonen. Her skal man ha mulighet til å legge til, redigere og slette innhold. Det er Homebase som står ansvarlige for innholdet som legges inn i applikasjonen. Likevel legger vi inn noen sjekklister og annen relevant data, for å gi en realistisk opplevelse av sluttproduktet. 57/136 7

58 Produktrapport 2. Beskrivelse av applikasjonen 2.1 Generell beskrivelse Applikasjonen består av to deler. De ulike delene baserer seg på forskjellige brukerkontoer, som har hvert sitt tilgangsnivå i systemet; bruker og admin. De er begge passordbeskyttet. Hoveddelen er presentert i form av en trinnvis guide, som veileder brukeren gjennom fire steg. Siste steg er en sjekkliste som skal hjelpe brukeren med å feilsøke et problem. Brukeren har også tilgang til bilder av utstyr og nyttige lenker. Frontoffice (se ordliste) har en felles brukerkonto for å få tilgang til hoveddelen av applikasjonen. Hvis det skulle være noen mangler i sjekklister eller annet innhold, er det mulig å komme med forslag til endringer via et rapporteringsskjema. Forslaget blir sendt til en e-postkonto, som brukes av backoffice (se ordliste). Det er denne avdelingen som bestemmer om forslagene skal godkjennes eller avslås. Den andre delen av applikasjonen er et administrasjonspanel. Denne er kun synlig for de som logger inn med en admin-konto. Her er det mulig å legge til, endre eller slette informasjon, som for eksempel site, utstyr, lenker, sjekklister og brukere. 58/136 8

59 Produktrapport Systemets posisjon Figuren under illustrerer hvor vårt system skal ligge i forhold til de andre systemene som allerede brukes på Homebase. Se figur 1. Figur 1. HB Guide sin plassering i forhold til eksisterende systemer. De svarte pilene viser hvordan BRUKER (kundekonsulent på frontoffice) benytter systemet; først gjøres feilsøkingen i applikasjonen (HB Guide), hvor tekst blir kopiert ut. Tekst limes deretter inn i CTI (loggføring), og CTI-henvendelsen kan eventuelt eskaleres til CTS (saksbehandling) for videre behandling (stiplet svart pil). Som vi ser, er loggføring avhengig av å bli knyttet mot en kundedatabase. Det var derfor ikke aktuelt å implementere loggføringsdelen i vårt system. 9 59/136

60 Produktrapport 2.2 Installasjonsveiledning Forutsetninger Denne applikasjonen burde installeres av en IT-kyndig person. Det kreves kunnskap om bruk av SQL- og web-server. Vi går ut ifra at IT-ansvarlig hos oppdragsgiver har dette. Klient Klientene må ha installert nettleseren Internet Explorer versjon 8.0 (eller høyere), eller en annen moderne nettleser. Vi vet at klientene på Homebase for tiden bruker førstnevnte. Internet Explorer 8.0 er også kompatibel med JavaScript, som er skrudd på som standard. JavaScript trengs for optimal visning av visse elementer på siden. Server Listen under viser hvilke tjenester Homebase må installere på server for å ta i bruk HB Guide. Det kan benyttes nyere versjoner enn det som er oppgitt. PHP versjon Apache web-server versjon 2.22 SQL-server 5.5 Om man har PHP versjon 5.3 eller nyere, er det ikke nødvendig med noen ekstra moduler. Vi vet at det finnes.php-sider og en databaseapplikasjon hos Homebase allerede. Med stor sannsynlighet trenger IT-ansvarlig kun kopiere mappen med alle filene, og legge den i Apache-mappen på deres server Kildekode I kildekoden finnes mappen HB Guide. Denne inneholder mappene sql, kode og installasjon. Sql-mappen inneholder en SQL-fil for importering av tabeller og tilhørende data. Kode-mappen inneholder kildekoden til applikasjonen. Installasjonsmappen inneholder instrukser for installasjon av systemet. 60/136 10

61 Produktrapport Installasjonen av systemet gjøres manuelt ved at alle filene i mappen HBguide/kode legges på en webserver. Spesifikt hvor disse filene legges, velges av IT-administrator og må samsvare med innstillingene til web-server Oppsett av database og tabeller med MySQL IT-administrator skal kjøre SQL-filen gjennom valgfri databaseapplikasjon, for eksempel phpmyadmin, gjennom bruk av Import -knapp. Scriptet kan også implementeres gjennom command-line på SQL-server. IT-administrator må være logget på serveren med en bruker som har rettigheter til å kjøre script. Hvis filen ligger på lokasjon /sti/mappe/, er syntaksen slik: mysql>source /sti/mappe/hbguide.sql Resultatet av dette blir at alle nødvendige tabeller med tilhørende data blir opprettet Oppsett av konfigurasjonsfil Filen config.php, som ligger under /HBguide/kode-mappen, inneholder parametere som må endres ut ifra Homebase sine server-innstillinger. Her setter man innloggingsdetaljer for database, tittel på siden, URL til rotmappen og e- postadresse til den ansvarlige for siden. Se figur 2. 61/136 11

62 Produktrapport Figur 2. php sin konfigurasjonsfil for HB Guide. Forklaring av variabler: $sql_host: adresse til MySQL server. $sql_user: brukernavn til MySQL server $sql_pass: passord til MySQL server $sql_db: database man vil benytte seg av på SQL serveren, standard er hbguide. $db: starter tilkobling til database. Det er ikke nødvendig å endre denne. Bruker variablene $sql_host, $sql_user, $sql_pass og $sql_db. $domene: URL til der rotmappen er. Denne brukes av menyen slik at lenker alltid er riktige. $site_title: Tittel på siden. $site_admin: E-postadressen til den som er ansvarlig på siden. Denne e-postadressen vil motta en e-post når noen rapporterer et problem. 62/136 12

63 Produktrapport Sikkerhet Nettsiden skal implementeres i et nettverk der et annet firma, GET AS, også har tilgang. Derfor er den passordbeskyttet, slik at innholdet kun vises etter å ha logget inn. Passord lagres kryptert i databasen, med både hash og salt (se ordliste), for ekstra sikkerhet. Vi anbefaler at siden kjører på SSL (se ordlisten), fordi dette beskytter mot pakkesniffing på nettverket, men det er ikke noe krav til dette. 2.3 Kodespråk PHP PHP er et dynamisk programmeringsspråk som tolkes av webserver, for så å skrive ut HTML til brukerens nettleser. PHP-koden er skrevet objektorientert, med bruk av klasser og funksjoner. Koden er i tillegg kommentert, og gjort så oversiktlig som mulig. Dette er gunstig for gruppen selv, men også for en eventuell programmerer som ønsker å videreutvikle produktet. Objektorientering gir flere muligheter enn tradisjonell flat programmering: Sterkere sikkerhet (private variabler i klasser) Fleksibilitet (lett instansiere nye objekter) Oversikt (mer ryddig og leselig kode) Færre linjer kode HTML5 og CSS HTML5 (Hypertext Markup Language) er et mark-up language, og er brukt for å strukturere nettstedet. Koden er optimalisert for Internet Explorer. Det er denne nettleseren som hovedsakelig benyttes av Homebase. Fordelen med å optimalisere koden for IE, er at den også skal fungere bra i de andre nettleserne, slik som Google Chrome, Mozilla Firefox og Opera. 63/136 13

64 Produktrapport CSS (Cascading Style Sheets) er brukt til design og layout, for å vise hvordan sidene skal se ut Javascript Javascript er et scriptspråk som tilbyr dynamiske og interaktive nettsider. Alle javascript kjører på klient-siden og kan derfor lett skrues av. Dette gjør at man alltid må ha alternative løsninger for de som velger å gjøre dette (Horgen, 2009: 35). Vi har brukt et script som heter Fancybox, som benytter seg av Javascript. Formålet med dette scriptet i vår applikasjon, er å vise bilder uten å måtte forlate nettsiden. Det er laget på en slik måte at bildene dukker opp i en boks, på samme siden som man står på. Fancybox kan også benyttes til andre ting, for eksempel visning av videoer eller vise en annen side inne på siden MySQL Vi har benyttet oss av en MySQL database, som systemet henter persistent informasjon fra. MySQL er verdens mest populære open source database-programvare. (MySQL, udatert) Design Oppbygning av brukergrensesnitt Systemet vi har laget, er et nettsted bygget opp av et sett med teknologier; HTML, PHP, CSS og JavaScript. Strukturen Utseende på alle sider er bygget opp av HTML5 og CSS3 (bildevisning bruker JavaScript). De har veldig mye kode til felles, og er i all hovedsak organisert slik: <!DOCTYPE html> starter HTML5 <head> inneholder meta informasjon og inkuderer Javascript filer og CSS <body> her starter selve innholdet på siden <div id="nav_cont"> Ramme for toppmenyen tar hele bredden på siden 64/136 14

65 Produktrapport <div id="nav"> Ramme for selve menyen, er satt til 800px her. <ul id="nav_menu"> <li> Hvert element i toppmenyen Når disse taggene avsluttes, begynner innholdet på selve siden. <div id="content"> Ramme for innhold <div id="main_cont"> Setter bredden på siden, i vårt tilfelle 900px Figur 3. Viser oppbygning av hovedinnhold på siden. Her inkluderes innhold fra andre filer, som bruker noen forskjellige tags. Men de som går igjen oftest er <article>,<h(1-6)> <ul>, <table> og <form>. Etter dette inkluderes brødsmulestien i selve applikasjonen og admin-menyen i admin panelet. Begge disse bruker <p> tags /136

66 Produktrapport Designprinsipper Vi har laget en brukervennlig applikasjon, som vi mener kundebehandlerne kan lære og bruke på kort tid. Vi har valgt å følge utvalgte heuristiske retningslinjer (Nielsen Norman Group, 1995) for utforming av brukervennlige systemer, og nedenfor kommer en oversikt over disse: Systemstatus ; brukeren vet alltid, ved hjelp av navigeringshjelpemidler, hvor han/hun befinner seg. Konsistens ; et helhetlig design gjennom applikasjonen, bidrar til at brukerne, etter minimal bruk, vet hva de skal velge. Forhindring av feil ; dersom brukeren unnlater å fylle ut et obligatorisk input-felt, vil en feilmelding dukke opp. Slik forhindrer systemet at feil oppstår. Gjenkjenning fremfor erindring ; brukerne skal kunne gjenkjenne elementer på siden ved bruk av familiære ikoner Designvalg Typografi Applikasjonen har en lettlesig sans-serif font. Sans-serif betyr at den kommer uten seriffer ( fnutter på endene av bokstavene). En slik font sies å være lettere å lese for mennesker med nedsatt synsevne. Valget falt på Arial, som er en av de mest vanlige sans-serif fontene. For å skille innholdet på sidene fra hverandre, har vi brukt en god del whitespace (mellomrom). I tillegg er alle overskrifter HTML-tagget med h1- h6. Slik vil det bli enklere for brukere å lese og skille elementer fra hverandre. 66/136 16

67 Produktrapport Fargevalg Applikasjonen har få farger, og står i stil med det minimalistiske designet vi har valgt. Enkelte elementer er i rødt (#FF0000), og gjenspeiler Homebase sitt allerede integrerte design. Den røde logoen til selskapet er plassert i hovedmenyen, som er tilgjengelig på alle sider av applikasjonen. Andre steder der rødfargen blir brukt, er på lenkene i brødsmulestien og på menyen inne på administrasjonssiden. En knallblå farge (#2266EE) vises når brukeren holder musepekeren over lenkene. Siden det er en stor kontrast mellom disse primærfargene, kommer det tydelig frem hvilken lenke som er markert til enhver tid. Bakgrunnen for hele applikasjonen er lysegrå (#eeeeee). Hovedboksen er i en farge som heter floral white (#FFFAF0). Til en web-applikasjon, er denne fargen bedre å bruke enn en kritthvit farge. Dette fordi det er mer behagelig for øynene, særlig når man skal være foran skjermen i lange perioder. Alt hovedinnhold, slik som for eksempel sjekklistene, har en svart font. Den fungerer som en fin kontrast til den lyse bakgrunnen. Fargekartet nedenfor viser alle fargene vi har brukt på applikasjonen. Figur 4. Fargekart 67/136 17

68 Produktrapport 2.5 Brukere Standardbruker Brukere som er logget inn som standardbruker, har kun tilgang til feilsøkingsdelen av nettsiden. Det er denne alle på Kundesenteret logger seg inn på til daglig Administrator Brukere som er logget inn med administrasjonsrettigheter, vil få tilgang til adminpanelet. Her kan de endre informasjonen som ligger i databasen, og dermed endre innhold som vises for vanlige brukere. Etter at brukeren har trykket på lenken Admin i menyen, vises forsiden til adminpanelet: Figur 5. Adminpanelet for Backoffice 68/136 18

69 Produktrapport 2.6 Navigasjon Brukerne kan enkelt navigere seg rundt i applikasjonen. Det er flere navigeringshjelpemidler tilgjengelig, som hjelper brukerne å få oversikt over hvor de befinner seg, og hvor de kan gå videre Den globale navigasjonsmenyen for frontoffice Den globale navigasjonsmenyen er tilgjengelig på hver eneste side av nettstedet. (Morville & Rosenfeld, 2007: 122). I applikasjonen er denne implementert øverst på siden, i form av en meny. Figur 6. Det globale navigasjonssystemet for Front-Office Figur 6 viser den globale menyen til applikasjonen, slik den vises for kundebehandlerne på frontoffice. Siden den er tilgjengelig på alle sidene, er det liten sannsynlighet for at brukerne går seg vill. Uansett hvor vedkommende befinner seg, kan han/hun enkelt navigere seg mellom følgende sider; Forside, Utstyr og Lenker. I tillegg er bildet av logoen klikkbar, og leder til forsiden. Logg ut knappen på høyre side, logger ut brukeren og man tas tilbake til logg inn siden Den globale navigasjonsmenyen; for backoffice Figur 7. Den globale navigasjonsmenyen- for backoffice. I figur 7 ser man den globale navigasjonsmenyen som vises for brukere som er logget inn med admin-rettigheter. Denne består av to deler. Den øverste menyen er relativt lik som den for frontoffice. Den skiller seg imidlertid ut, ved at den har en lenke som heter Admin. Her kan brukerne trykke for å få opp en ny menylinje, som er tilgjengelig på alle admin-sidene. Hver av disse lenkene; Site, Brukere, Utstyr, Problem, Sjekkliste, Lenker og Bilder, tar brukerne til en ny side der de kan velge mellom å legge til, redigere eller slette en entitet. 69/136 19

70 Produktrapport Brødsmulesti I tillegg til den globale navigasjonsmenyen, har applikasjonen en brødsmulesti, som vist i figur 8. Den viser hvert nivå av hierarkiet, frem til brukerens posisjon. Brødsmulestien er lineær, og inneholder klikkbare lenker, som hjelper brukeren til å navigere seg mellom de ulike sidene i hierarkiet. Den er nyttig fordi den viser hvor brukeren befinner seg i forhold til resten av nettstedet. (Tidwell, 2006: 78). Figur 8. Brødsmulesti som vises i applikasjonen Guide Et hjelpemiddel som er sentralt, og som applikasjonen er bygget rundt, er guiden. Denne formen for navigering er lineær. Når brukeren har fullført et steg, føres han videre til neste. Da vi designet denne, var vi bevisst på noen designprinsipper spesielt egnet for guider; stegene skulle være korte, og brukeren måtte ha mulighet til å avbryte når som helst, ved hjelp av knappen Start på nytt. Brukeren kan når som helst hoppe til forrige steg ved å klikke i brødsmulestien. (Morville & Rosenfeld, 2007: 136, 137). 70/136 20

71 Produktrapport 3. Funksjonalitet Kravspesifikasjonen er en avtale mellom prosjektgruppen og oppdragsgiver om hvilke krav som stilles til applikasjonen. Nedenfor forklarer vi hva applikasjonen kan gjøre, og viser at den samsvarer med kravspesifikasjonen. 3.1 Applikasjonen Inn- og utlogging Når brukere først åpner systemet, og de ikke har en aktiv session (se ordliste), vises et innloggingsbilde med brukernavn- og passordfelt. Feltene må fylles ut med et gyldig brukernavn og passord for at brukeren skal bli videreført til applikasjonen. Forside / Site Den første siden brukeren kommer inn på etter innlogging, er Site. Site er hvilket nettverk en kunde befinner seg i. Ulike nettverk kan ha ulike tilgjengelige tjenester. Brukeren velger site fra en nedtrekksmeny, og klikker på knappen velg når han/hun vil gå videre. Kategori Når brukerne har valgt en site, kommer de videre til en side hvor de velger hvilken kategori problemstillingen befinner seg i. Alternativene her er Internett, TV og Telefoni, og bare de tjenestene som er tilgjengelige på den valgte siten vil være klikkbare. Figur 9 viser at Homebase ikke støtter Internett på valgt site. 71/136 21

72 Produktrapport Problemstillinger Velg problem er tredje steg i feilsøkingen. Her dukker det opp en liste med problemstillinger, som gjelder for den kategorien som ble valgt i forrige steg. Her må brukeren finne en problemstilling som er relevant til kundens problem. Sjekklister Fjerde og siste steg er sjekklister. Her får brukeren opp en liste over punkter som bør kontrolleres under feilsøking av det valgte problem. Brukeren krysser av de punktene som har blitt sjekket, og trykker til slutt på Ferdig knappen. Det brukeren har krysset av på, kommer inn i en tekstboks. Der kan brukeren skrive ytterligere kommentarer om hva som løste problemet, eventuelt hva som ikke ble løst. Dette kan da kopieres til loggføringssystemet. Figur 10. Sjekkliste der man har trykket på ferdig 72/136 22

73 Produktrapport Figur 11. Utstyr hjelpeliste, lenker til bilder av utstyr I tillegg vil brukeren på denne siden se en liste over alt utstyr, hvor man kan klikke seg inn for å se bilder av det aktuelle utstyret. Hvis det er lagt inn lenker til andre nettsider, som er relatert til valg av site eller problemstilling, vil også disse vises på denne siden. Figur 12: Relevante lenke 73/136 23

74 Produktrapport Utstyr Denne siden står for seg selv og inneholder en liste med bilder av teknisk utstyr. Disse vises i et Fancybox album. Alle bilder som er relatert til et utstyr vises i samme album, som gjør at brukeren kan scrolle seg gjennom albumet. Lenker Undersiden Lenker står for seg selv, og inneholder lenker til andre sider som kan være nyttige, slik som for eksempel lenke til intern wiki og andre feilsøkingssider på nettet. Alle lenker åpnes i en ny fane eller nytt vindu i nettleseren. Rapporteringsskjema På alle sidene av applikasjonen finnes det en lenke som heter Rapporter en feil. Klikker man på lenken, blir man ført videre til et skjema. Her kan brukeren fylle ut informasjon om hvilke feil eller mangler som har blitt oppdaget. En e-post vil da bli sendt til administrator av siden, sammen med informasjon om hvilken side brukeren var på da han trykket på lenken, og hvilket tidspunkt det ble sendt inn. 3.2 Adminpanel Adminpanelet inneholder sider hvor brukere med administrator-rettigheter kan redigere elementer i databasen. Følgende elementer kan redigeres: site, brukere, utstyr, problem, sjekklister, lenker og bilder. Vi har lagt til hjelpetekst (se figur 13), slik at brukerne enklere kan forstå hvordan de kan gjennomføre en oppgave. Figur 13. Legg til en Site fra administrasjonspanelet, hjelpetekst vises når man holder musepekeren over spørsmålstegnene. 74/136 24

75 Produktrapport Legge til elementer Generelt Hvis admin-bruker skal legge til noe i databasen, må vedkommende først skrive inn det som er ønskelig i et eller flere tekstfelt. Når vedkommende er ferdig, trykker man på legg til, og informasjonen blir lagt til i databasen. Vi har valgt å gå litt mer detaljert inn på enkelte områder, men prinsippet er det samme for de andre sidene. Legge til site For å legge til site skriver man inn et navn og krysser av for hvilke kategorier som skal være tilgjengelige. Dette kjøres da igjennom et script i klasser.php som legger dataen inn i databasen. En linje fra site tabellen i databasen vil da se slik ut: Figur 14. Noen rader fra tabellen site, slik det ser ut i databasen Feltet SideID er en ID som er satt til Auto Increment, altså at databasen selv setter dette til 1 tall høyere enn den forrige linjen. De vil derfor aldri bli det samme. int, tv og tlf er satt til 1 dersom dette ble krysset av når man la inn dataen. Dette brukes i feilsøkingen for å vise tilgjengelige tjenester i området som er valgt. Legge til bruker Under legge til bruker er det et tekstfelt for brukernavn, og et annet for passord. En sjekkboks kan krysses av for å gi brukeren admin-rettigheter. 75/136 25

76 Produktrapport Legge til utstyr Når brukeren har fylt ut navn på utstyr, kan han velge hvilken type utstyr det er, fra en nedtrekksliste. Ønsker han å legge til bilde av utstyret, må han krysse av i sjekkboksen. Etter at knappen legg til utstyr er trykket på, lagres utstyret, og brukeren vil så få muligheten til å laste opp et bilde. Slette elementer Brukeren kan slette site, brukere, utstyr, problem, sjekkliste, lenker og bilder. Først må vedkommende redigere et av elementene. Etter det, er det mulig å trykke på slett -knappen. Se figur 15. Endre elementer Admin-bruker kan endre site, brukere, utstyr, problem, sjekkliste, lenker og bilder. Se figur 15 Figur 15. Viser rediger lenker, her har man også muligheten til å slette. 76/136 26

77 Produktrapport 4. Oppbygning og virkemåte 4.1 Introduksjon Denne delen av rapporten går gjennom kildekode og struktur. Hensikten med å lese denne delen er at leseren skal forstå oppbyggingen av systemet og få et innblikk i hvordan de forskjellige filene og funksjonene henger sammen. 4.2 Kildekode Kildekoden er laget med tanke på oversiktlighet og lesbarhet. Så mye som mulig er kommentert og utformet objektorientert. Alt innhold på nettstedet blir inkludert i URL en med bruk av GET-variabler. Feks. hvis siden heter utstyr.php, så vil lenken til den være url.no/?content=utstyr index.php: index php er hovedfilen som inkluderer de andre sidene. Index.php og admin/index.php inneholder session_start(), dette er de eneste stedene en session (se ordliste) startes, da alle sidene inkluderes igjennom disse. Videre starter HTML dokumentet med <!DOCTYPE html>, som er standard for HTML5. Deretter følger meta tags. Filene config.php, header.php, functions.php og navsti.php inkluderes i index.php. 77/136 27

78 Produktrapport Figur 16. Viser scriptet som inkluderer innhold I figuren over vises scriptet som inkluderer selve innholdet på siden. Innholdsfilene ligger i./content og alle filene er av typen PHP. Scriptet sjekker først om?content variablen er satt i URL. Om den ikke er det, vises innhold fra site.php. Hvis den er satt, sjekkes innholdet i variablen av RegEx. Om sjekken går bra, sjekkes det om den etterspurte filen eksisterer. Gjør den det, vises innhold fra filen som er satt i?content variabelen. config.php Config.php inneholder variabler som det vil være nødvendig å endre, ved bytte av driftsmiljø. Her settes innlogging til databasen, URL til rotmappen der siden ligger, tittel på siden, og e- postadressen til den som administrerer siden. 78/136 28

79 Produktrapport header.php Filen header.php inneholder navigasjonsmenyen på siden, samt et script som sjekker om man er logget inn eller ikke. Her sjekkes det også om man er logget inn som en bruker med adminrettigheter. Hvis man er det, skrives det ut en lenke til admin panelet i menyen. Videre inneholder headeren et script som sjekker om noen av SESSION variabelene skal slettes. Dette scriptet bruker variabelen $_GET[ clear ] og tar imot verdier clearall, clearfeil og clearlist. Dette brukes av navigeringstien på siden. Hvilken variabel som settes kommer an på hvilken lenke man trykker i brødsmulestien, f.eks. trykker man på Kategori så slettes variabelen $_SESSION[ sjekkliste ]. Se figurene 17 og 18. Figur 17. Viser brødsmulesti og lenkeoppbygging. Figur 18. Script som sletter session variabler Filen inkluderer også filer som brukes av fancybox. 79/136 29

80 Produktrapport Login scriptet Login scriptet ligger også i header.php og strukturen ser slik ut: Figur 19. Viser login scriptet, her er enelte linjer sensurert av sikkerhetsmessige årsaker. Denne funksjonen sjekker om Logg inn knappen er trykket. Om den er det, renser den variabelene og sjekker opp mot databasen om det finnes en bruker med det brukernavnet som ble skrevet inn. Om det er det, vil $db->affected_rows være lik 1, og den siste delen av koden kjøres. Funksjonen henter ut objektet fra databasen, lager en hash av kombinasjonen salt og passord, og sjekker om denne er den samme hashen som den som ligger i databasen. Dersom de er like settes $_SESSION[ login ] variabelen til brukerid til den innloggede bruker. Om hashene ikke er like, printes det ut en feilmelding. 80/136 30