Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus

Transkript

1 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Et oppfølgings- og dokumentstyringsverktøy for Takst og Prosjektkontroll AS Gruppe 19 Thomas Myklebust Fjørstad Marius Lørstad Solvang Espen Jøstne Hansen Lars-Erik Holte Steffen Sand

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Oppfølgings- og dokumentstyringsverktøy for Takst og Prosjektkontroll AS DATO ANTALL SIDER / VEDLEGG 185/5 PROSJEKTDELTAKERE Thomas Myklebust Fjørstad - s Marius Lørstad Solvang - s Espen Jøstne Hansen - s Lars-Erik Holte - s Steffen Sand - s INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Takst og Prosjektkontroll AS KONTAKTPERSON Ketil Johansen SAMMENDRAG Webapplikasjonen og Android-applikasjonen er utviklet for oppfølging av utbyggingsprosjekter og et verktøy for dokumentstyring. Applikasjonene er utviklet for Takst og Prosjektkontroll AS. 3 STIKKORD Webapplikasjon Android-applikasjon Dokumentstyring

3 HOVEDINNHOLDSFORTEGNELSE Her finnes en oversikt over delrapporter og vedlegg Innledning Kravspesifikasjon Prosessrapport Produktrapport Brukerveiledning Vedlegg o Vedlegg 1 Testrapport o Vedlegg 2 Ordliste o Vedlegg 3 Kilder o Vedlegg 4 Tilbakemelding o Vedlegg 5 - Kontrakt Side 3 av 185

4 Innledning INNLEDNING FORORD Dette prosjektet er resultatet av et semesters arbeid på informasjonsteknologistudiet på Høgskolen i Oslo og Akershus. Prosjektet har resultert i en fullverdig Android applikasjon som supplerer en webapplikasjon for takstmann Ketil Johansen og hans firma Takst og Prosjektkontroll AS. Arbeidet har vært spennende og samtlige medlemmer av gruppen har blitt utfordret. Her vil rette en stor takk til alle medvirkende under prosjektets gang. Først og fremst vil vi takke vår eminente oppdragsgiver som har kommet opp med en spennende og utfordrende oppgave til oss. Vi har fått inntrykk av andre grupper at vi har vært veldig heldig som har hatt en såpass interessert og ivrig oppdragsgiver som Ketil Johansen. Ketil har vært veldig god på å gi oss tilbakemeldinger underveis i arbeidsprosessen og har vært en super hjelp for oss. Tor Krattebøl og Torunn Gjester har vært til stor hjelp innenfor sine respektive fagfelt. Tor Krattebøl er faglærer i Webapplikasjoner og Torunn Gjester er faglærer i Applikasjonsutvikling. Samtlige på gruppen hadde begge disse fagene semesteret før det virkelige arbeidet med denne bacheloroppgaven startet. Selv om hverken Tor eller Torunn har vært veilederne våre, har begge to tatt seg tid til å hjelpe oss med vanskelige tekniske spørsmål og vært veldig gode å ha hvis vi har stått fast på et punkt. Vi vil til slutt rette en stor takk til vår veileder ved Høgskolen i Oslo og Akershus, Kirsten Ribu, som har bidratt med sine erfaringer fra veiledning av mange tidligere prosjekter. Hennes innspill til gjennomføring av bacheloroppgaven har vært til stor hjelp. Signert Oslo Steffen Sand Lars-Erik Holte Espen Jøstne Hansen Marius Lørstad Solvang Thomas Myklebust Fjørstad Side 4 av 185

5 Innledning INNHOLD Forord... 4 Innhold... 5 Presentasjon... 6 Om gruppen... 6 Om oppdragsgiver... 7 Bakgrunn for oppgaven... 7 Hvordan vi ble med... 8 Testbrukere... 8 Side 5 av 185

6 Innledning PRESENTASJON Dette dokumentet er ment som en presentasjon av involverte parter og en innledning til oppgaven. Før man leser de andre delrapportene i denne dokumentasjonen er det forventet at man har lest denne innledningen for å få et innblikk og en innføring i oppgaven. Ut gjennom rapporten har vi brukt et gjennomgående teknisk språk og sjargong som har vært nødvendig for å beskrive Android applikasjonen og webapplikasjonen. Se ordlisten(vedlegg 2) hvis det er noe som er uklart eller man lurer på noe. OM GRUPPEN Gruppen består av 5 informasjonsteknologistudenter som har jobbet sammen i forskjellige grupperinger i løpet av disse 3 årene på bachelorstudiet. Vi har vært en sammensveiset gjeng og brukt hverandre i læringen i alle de forskjellige fagene vi har hatt, også utenom gruppearbeider. Figur 1: Organisasjonskart Side 6 av 185

7 Innledning OM OPPDRAGSGIVER Takst og Prosjektkontroll AS er et selskap som utfører taksering av eiendommer og har autorisasjoner innen verditaksering, boligsalgsrapporter, skader, skjønn, nærings- og landbruks-eiendommer. Ketil Johansen, daglig leder, er utdannet bygningsingeniør, økonom og takstmann gjennom Norges Takseringsforbund. Han har 30 års erfaring med utbyggingsprosjekter på Nesodden. Dette har resultert i 75 boliger og 1 næringsbygg. Firmaet er nå i gang med et nytt prosjekt med 4 eneboliger og planlegger et større prosjekt på Nesoddtangen sentrum med 2 byggetrinn. Takst og Prosjektkontroll AS kan heretter bli referert til som oppdragsgiver videre i denne dokumentasjonen. BAKGRUNN FOR OPPGAVEN Primærformålet med oppgaven var å lage en nettløsning for å lette hverdagen og få bukt med den store papirmøllen det ble ved alt av rapporter, kontrakter og alt annet av papirer som er knyttet til utbyggingsprosjekter. Det som tidligere var den eksisterende hjemmesiden til oppdragsgiver var i all hovedsak en informasjonsside for et gammelt prosjekt. Løsningen kommer først og fremst til å bli brukt av Ketil Johansen, ene og alene fordi han per dags dato er Takst og Prosjektkontroll AS. Uavhengig av dette er det lagt opp for å tilegne brukere forskjellige rettigheter enten det skulle vært en ny kollega eller ha en portal mellom kunder og oppdragsgiver på et byggeprosjekt. Android-applikasjonen er ment som et verktøy for blant annet rapportering og møtereferater. Dette er en applikasjon som i første omgang er ment for Ketil Johansen og for bruk ute av kontoret. De største fordelene det nye systemet og tilhørende Androidapplikasjon tilfører er: Minimerer papirbruken til det absolutte minimum Samler alt av informasjon for et prosjekt på et sted Enkelt å lage en rapport på «farten» med Android-applikasjon Et profesjonelt og moderne bilde av bedriften utad Digitalisering av hverdagen Sikker innlogging sikrer informasjon som er klassifisert Side 7 av 185

8 Innledning HVORDAN VI BLE MED Så fort vi ble enige om å være en bachelorgruppe, høsten 2014, satte vi oss ned og diskuterte hva slags type oppgave vi ville jobbe med det neste semesteret. Når vi ble enige og hadde fått snevret ned fagområdene vi helst ville jobbe med, sonderte vi terrenget med oppgaver skolen hadde lagt ut. Dette var mange forskjellige typer oppgaver og vi sendte ut mail med søknader på de av dem som var innen for de løserammene vi hadde satt i gruppen. Før vi rakk å få svar på noen av disse søknadene datt det en perfekt oppgave omtrent i fanget på oss. Alle gruppemedlemmene hadde tatt en runde blant familie og bekjente som vi kunne tenke oss kanskje hadde en ide til bacheloroppgave. Vi fikk veldig rask respons fra Ketil Johansen, stefaren til gruppemedlem Steffen Sand. Fra denne første mailen hvor Ketil beskrev ideen sin og hva han kunne ønske seg, sa vi ja øyeblikkelig. Fram til det første møtet med Ketil hadde vi fått frie tøyler til å komme med et par forskjellige forslag og utkast til oppgaveutforminger. Etter det første møtet var samtlige i gruppen og Ketil veldig fornøyde med den oppgaven vi hadde utformet sammen. TESTBRUKERE Det er satt opp en vanlig test bruker og en administrator bruker som kan brukes til å logge seg inn i webapplikasjonen. Her kan det testes forskjellig funksjonalitet, navigering og løsninger på forskjellige ting. Vi anbefaler å bruke Google Chrome som nettleser. Webløsningen finner man på: Vanlig bruker Brukernavn: bruker@bruker.com Passord: ***** Administrator bruker Brukernavn: admin@hotmail.com Passord: ***** Side 8 av 185

9 Side 9 av 185

10 Kravspesifikasjon KRAVSPESIFIKASJON FORORD Kravspesifikasjonen er laget for at både utviklere og oppdragsgiver vil få en forståelse av rammeverket og funksjonaliteten til produktene. Kravspesifikasjonen vil også fungere som en avtale, slik at produktet blir som begge parter er enige om. Eventuelle endringer av kravspesifikasjonen krever et møte med begge parter til stede, hvor det blir enighet. Kravspesifikasjonen vil være som en retningslinje for utviklerne underveis i produktutviklingen, slik at utviklerne holder seg til de rammene som er definert for prosjektet. Side 10 av 185

11 Kravspesifikasjon INNHOLD Forord Innhold Innledning Bakgrunn for oppgaven Krav til funksjonalitet Kundens krav til funksjonalitet Mål for funksjonalitet gjort i forprosjektrapport Oppdragsgivers krav til funksjonalitet på webapplikasjon oppdragsgivers krav til funksjonalitet på Android-applikasjon Prosjekter Rapporter Brukere Brukere (Administrering) Filer Nettsted Applikasjon Tilleggs funksjonalitet Rapporter Nettside Prosjekt Tekniske krav Krav til koden Sikkerhetskrav Designkrav Konklusjon Side 11 av 185

12 Kravspesifikasjon INNLEDNING Denne bacheloroppgaven i informasjonsteknologi ved Høgskolen i Oslo og Akershus er gitt av firmaet Takst og Prosjektkontroll AS. Oppgaven går ut på å utvikle et oppfølgnings- og dokumentstyringsverktøy for prosjekter under dette firmaet. Verktøyet skal ligge på en nettside og skal ha en mobil-applikasjon som skal snakke med samme database som nettstedet. Applikasjonen skal fungere på Android-telefoner og være nyttig for daglig leder når han ikke har tilgang til en datamaskin. Styringsdokumentene bestod blant annet av hvilken funksjonalitet oppdragsgiver ønsket. Oppdragsgiver har ingen bakgrunn fra programmering eller generell utforming av nettsider. Dette ga oss som utviklere mulighet til å komme med forskjellige forslag om oppbygning og struktur. På denne måten fikk oppdragsgiver flere gode alternativer for framstilling av ønsket funksjonalitet. Design er blitt jobbet på etterhvert som funksjonaliteten til nettstedet har kommet på plass, og har undergått flere modifikasjoner underveis etter ønske av oppdragsgiver. Til tross for disse små endringene har implementering av funksjonalitet vært høyere prioritert enn design, da oppdragsgiver hadde ønske om et simpelt design uten mye sterk og forskjellig fargebruk. BAKGRUNN FOR OPPGAVEN Oppdragsgiver arbeider gjerne med flere utbyggingsprosjekter samtidig. Dette innebærer å bygge boliger, følge med at alt går etter planen og orientere involverte aktører som for eksempel snekkere, rørleggere og elektrikere. Ettersom dette blir gjort av kun en person og alle filene tidligere har blitt lagret på en datamaskin, har dette over ført til enorme mengder filer og rot på datamaskinen. Av denne grunn var ønsket til oppdragsgiver å kunne laste opp filer til ett nettsted og kunne sortere disse filene på de forskjellige prosjektene. Det var også et ønske å kunne beholde filer til prosjekter var fullført, slik at oppdragsgiver kunne gå tilbake til disse. Ettersom det er boliger som skal selges og aktører som skal orienteres, er det også lagt til funksjonalitet som gjør det mulig for administrator å opprette og dele ut brukerkontoer slik at diverse aktører har mulighet til å logge inn på nettstedet og se filer som er relevante for dem. Side 12 av 185

13 Kravspesifikasjon KRAV TIL FUNKSJONALITET KUNDENS KRAV TIL FUNKSJONALITET Kravet fra oppdragsgiver er å ha et verktøy der alt av filer og informasjon skal kunne legges ut på nettstedet, slik at han ikke trenger å arbeide med papir og heller ha alt på en server. Samtidig skal det være tilgjengelig for andre brukere. MÅL FOR FUNKSJONALITET GJORT I FORPROSJEKTRAPPORT Nettsiden skal være et enkelt verktøy for deling av filer mellom gitte brukergrupper og administrator Nettstedet skal være et rapporteringsprogram for deltagerne i et utbyggingsprosjekt Mobilapplikasjonen skal være et enklere og kjappere verktøy for å rapportere til nettstedet når en datamaskin ikke er innen rekkevidde Nettstedet skal markedsføre bedriften og dens prosjekter Nettsiden skal være et kommunikasjonsverktøy for deltagerne i bedriftens prosjekter Nettstedet skal arkivere tidligere prosjekter OPPDRAGSGIVERS KRAV TIL FUNKSJONALITET PÅ WEBAPPLIKASJON Innlogging av enten bruker eller administrator med passord med forskjellig tilgang og muligheter OPPDRAGSGIVERS KRAV TIL FUNKSJONALITET PÅ ANDROID-APPLIKASJON Ta bilder og legge rett inn i ønsket rapport eller skjema Side 13 av 185

14 Kravspesifikasjon PROSJEKTER Opprette prosjekter Liste ut alle pågående prosjekter Liste ut alle prosjekter som er fullførte Endre prosjektinformasjon Laste opp filer til prosjekter, som lagres på server og kan lastes ned Gi rettigheter til brukere eller brukergrupper for prosjekter og filer Slette rapporter Forhåndsbestemte brukergrupper til alle prosjekter Endring av brukergrupper Sletting av brukergrupper RAPPORTER Opprette rapportert som er knyttet til et prosjekt Liste ut alle rapporter på et prosjekt Vise en rapport med eventuelt bilde Legge til bilder på rapporter Endre rapporter Slette rapporter BRUKERE Se filer innad prosjekter du er knyttet til Laste opp filer til din personlige mappe Side 14 av 185

15 Kravspesifikasjon BRUKERE (ADMINISTRERING) Opprette brukere Liste ut alle brukere Endre brukere Slette brukere Se alt av informasjon til brukeren og filer de har lastet opp Legge bruker i et prosjekts brukergruppe FILER Mulighet for opplastning av pdf, excel, doc, jpg, png og liknende dokumentasjonsfiler Liste ut alle filer Mulighet for nedlastning NETTSTED Endre forside med tekst og bilder (CMS) Endre informasjonsside med tekst, bilder og kontaktinformasjon (CMS) Kontrollpanel for administrator Min side for brukere APPLIKASJON Opprette rapporter på prosjekter Ta bilde og legge til på rapporten Liste ut rapporter Vise enkelte rapporter Endre rapporter Side 15 av 185

16 Kravspesifikasjon TILLEGGSFUNKSJONALITET Tilleggsfunksjonalitet er noe som enten oppdragsgiver eller vi har tenkt på som kan forbedre verktøyet. RAPPORTER Opprettelsesskjemaet til rapporter skal se likt ut som papirutgaven NETTSIDE Logging av databaseendringer Liste ut databaselogg Forside med bildekarusell PROSJEKT Opprette egendefinerte brukergrupper TEKNISKE KRAV Vi har ikke hatt noen tekniske krav fra oppdragsgiver ettersom han ikke vet hvilket kodespråk eller utviklingsverktøy som ville være bra for oppgaven. Dette har vært en tilleggsoppgave for oss å finne ut hvordan vi kunne utvikle det oppdragsgiver ønsket på en best mulig måte. Så dette avsnittet blir de tekniske kravene som vi har satt for nettstedet og applikasjonen. Side 16 av 185

17 Kravspesifikasjon Nettstedet skal utvikles i.net med MVC-oppsett i utviklingsverktøyet Visual Studio Nettstedet skal kodes i hovedsakelig C# og JavaScript Nettstedet skal bruke rammeverket Entity Framework Passord skal hashes Filene på nettstedet må linkes mellom mapper og brukere, slik at det ikke blir dobbeltlagring av filer Android-applikasjonen skal utvikles i Eclipse Android-applikasjonen skal kodes i Java og XML KRAV TIL KODEN I starten av utviklingsprosessen ble vi enige om at alt av kode skal skrives på engelsk, noe som gjør at nettsiden blir enklere å oppdatere for eventuelle videreutviklere. Ettersom oppdragsgiver ikke kan kode selv, er det sannsynlig at han kommer til å få noen andre til å vedlikeholde nettsiden, ved feil eller endringer. Navn på klasser, metoder og variable skal ha gode og konsistente navn slik at utenforstående programmerere enkelt kan sette seg inn i koden Oppsettet til alle kontrollere skal inneholde de samme navnene med små justeringer for lett gjenkjennelighet. public bool deleteproject(int id) public bool deleteusergroup(int id) SIKKERHETSKRAV Her følger en liste med sikkerhetskrav som er satt av oppdragsgiver og utviklere. Brukere skal kun opprettes av administrator Passord skal krypteres med SHA512 Filer skal ikke kunne sees av andre enn de som er innlogget med definerte rettigheter Kun administrator har tilgang til administrasjonspanelet Endring av brukerinformasjon er kun mulig for administrator Side 17 av 185

18 Kravspesifikasjon DESIGNKRAV Oppdragsgiver hadde ikke mange ønsker om hvordan nettstedet skulle se ut, så utseende på nettstedet har vært ikke vært prioritert i oppgaven vår. Han ville ha et nettsted som var så enkelt som mulig, og det var viktigere med funksjonalitet enn design. Hvordan det har blitt seende ut har blitt bestemt ved at vi (utviklerne) har kommet med forslag til oppdragsgiver og fått dette godkjent. Vi gikk til oppdragsgiver med spørsmål om vi skulle lage en mulighet for han å endre noe på forsiden, slik at han kunne markedsføre prosjektene sine. Denne idéen likte han og vi lagde da en CMS for han. Nettstedet skal være enkelt å bruke Nettstedets sider skal være gjenkjennbare og konsistent satt opp Lik fargebruk overalt Rapporter skal være så like papirutgavene som mulig. Både ved utfylling og i utskriftsformat Mulighet for å endre tekst og bilde på forside og informasjonssiden KONKLUSJON Kravspesifikasjonen har blitt bygd opp i henhold til hvordan vi som utviklere tolket oppdragsgivers idé om utviklingen. Ettersom oppdragsgiver ikke hadde særlig stor kunnskap om programmering og nettsider, ble det vår oppgave å få hans idé til virkelighet på måten vi synes var best. Kravspesifikasjonen ble laget ut i fra de forskjellige møtene vi hadde sammen med oppdragsgiver, der vi viste forskjellige utgaver av nettstedet og fikk tilbakemelding om det var slik han ønsket det. Android-applikasjonen var ikke et direkte ønske fra oppdragsgiver, men derimot var det vi som kom med forslaget og fortalte at han kunne ha mulighet til å utføre noen av funksjonene via denne applikasjonen enklere. Dette verktøyet skal brukes som et "on-thego" verktøy, for eksempel rapporter som skal fylles ut kan bli gjort på byggeplassen og han har muligheten til å ta bilder av det som rapporteres og laste det raskt opp til samme server som nettstedet bruker. Side 18 av 185

19 Kravspesifikasjon Utviklingen av oppgaven har vært veldig tidskrevende, ettersom oppdragsgiver kun hadde en formening om hva han ønsket å kunne gjøre på nettstedet. Det ble da vår oppgave å finne en måte å gjøre dette med vår kunnskap. Tilbakemeldingen vi har fått fra oppdragsgiver og hans tilknytninger har vært veldig bra, og han har blitt overrasket over hvor mye vi fikk til av det han ønsket. Vi har utfylt alle de kravene oppdragsgiver ønsket å ha med, og i tillegg har vi lagt til flere funksjoner han ikke hadde tenkt på, som for eksempel endring av informasjon på noen av nettsidene. Etter at nettstedet er blitt lastet opp har oppdragsgiver allerede startet å bruke det i sine prosjekter, og er godt fornøyd med applikasjonene. Side 19 av 185

20 Side 20 av 185

21 Prosessdokumentasjon PROSESSDOKUMENTASJON FORORD I denne rapporten greier vi ut om hele prosessen som til slutt kulminerte i et nettbasert oppfølgingsverktøy for oppdragsgiver. Av nødvendige forkunnskaper anbefaler vi leseren å gjøre seg kjent med innledningsdokumentet for å skaffe seg et helhetlig inntrykk av prosjektet. For å unngå eventuelle misforståelser med hensyn til terminologi refererer vi til ordlisten i vedlegg 2. Prosessrapporten forklarer hvordan vi har jobbet og hvilken utviklingsmetode vi har valgt å bruke. Den er delt inn i 4 kapitler: Planlegging og metode: En gjennomgang av planleggingen og hvilke arbeidsmetoder, teknikker og verktøy som ble brukt i prosjektperioden. Utviklingsprosessen: En beskrivelse av hele utviklingsprosessen. Fra startfasen og konseptutviklingen til ferdigstillingen av produktet. Kravspesifikasjonen og dens rolle: Hvordan kravene til produktet påvirket oss under utviklingen. Avsluttende del: Våre tanker og meninger om hovedprosjektet, lærerutbyttet og det ferdige produktet. Side 21 av 185

22 Prosessdokumentasjon INNHOLD Forord Innhold Planlegging og metode Tiden før prosjektstart Ansvarsfordeling Webapplikasjon Android-applikasjon Metodikk og arbeidsteknikker Smidig metodikk Scrum Daglige og ukentlige Scrum-rutiner Kommunikasjon med oppdragsgiver og veileder Styringsdokumentene Statusrapport Prosjektskisse Forprosjekt Arbeidsforhold Pilestredet 35, 0166 Oslo (P35) Pilestredet 32, 0166 Oslo (P32) Verktøy Språk C# HTML (HyperText Markup Language) CSS (Cascading StyleSheet) JavaScript PHP (Hypertext Preprocessor) Java Utvikling Side 22 av 185

23 Prosessdokumentasjon Visual Studio Eclipse 4.2 Juno Java Development Kit (JDK) Android SDK Logcat Android debug bridge (ADB) Dalvik Debug Monitor Server (DDMS) Adobe Photoshop Utvidelser og rammeverk Entity Framework Bootstrap jquery JSON (JavaScript Object Notation) StudioDonder TestHelper Toastr Versjonskontroll Team Explorer/Team Foundation Server (TFS) Dropbox Dokumentasjon Microsoft Word yed Utviklingsprosessen Konseptutvikling Risikoplan Kortvarig sykdom/fravær Langvarig sykdom/fravær Tidsklemme Tap av data Konflikter i gruppa Side 23 av 185

24 Prosessdokumentasjon Datainnsamling Målgruppe og behov Gruppemøter og brainstorming Testing av Androidapplikasjon Testing av webapplikasjon Faglige utfordringer Design av webapplikasjonen Android PHP Webserver Avansert database Mangelfull enhetstesting Personvern og konfidensialitet Dokumentasjonsfasen Kravspesifikasjonen og dens rolle Avsluttende del Ord fra oppdragsgiver Samarbeid i gruppen Veiledning ved HiOA Læringsutbytte Det ferdige produktet Nytteverdi Videreutvikling Webapplikasjon Android-applikasjon Konklusjon Side 24 av 185

25 Prosessdokumentasjon PLANLEGGING OG METODE Planlegging er en viktig del i all slags arbeid. Tidlig i prosjektet planla vi å dele oss i to grupper, fordelt på applikasjonene vi skulle lage. I denne delen av prosessrapporten vil vi gå gjennom og beskrive arbeidsmetoder, teknikker, verktøy og hjelpemidler som er felles for hele gruppa og som har blitt benyttet i hele prosjektperioden. TIDEN FØR PROSJEKTSTART Gruppen vår ble stiftet medio oktober Under vårt første gruppemøte skulle vi diskutere og kartlegge hva slags type hovedprosjekt vi ønsket å jobbe med. Alle gruppemedlemmene kjente hverandre fra før, noe som ga et godt grunnlag for å kunne avgjøre hvilken type hovedprosjekt vi ønsket å arbeide med. Vi lagde en liste med områder vi foretrakk å arbeide med i tillegg til å vurdere mulige oppdragsgivere. Blant aktuelle oppdragsgivere var vi innom prosjektforslagene til HiOA og andre bedrifters. Vi kontaktet bedriftene vi syntes var mest aktuelle og appellerende. Responsen fra bedriftene var begrenset, men innen kort tid kom vi i kontakt med bygningsingeniør, økonom, takstmann og daglig leder i Takst og Prosjektkontroll AS Ketil Johansen som vi syntes tilbød den mest spennende oppgaven. Etter en telefonsamtale med utveksling av idéer og mål falt valget på denne. ANSVARSFORDELING Prosjektet vårt bestod av to applikasjoner. Ut ifra ønsker og ferdigheter fordelte vi oss slik: WEBAPPLIKASJON Lars-Erik Holte Marius Lørstad Solvang Steffen Sand Side 25 av 185

26 Prosessdokumentasjon ANDROID-APPLIKASJON Espen Jøstne Hansen Thomas Myklebust Fjørstad METODIKK OG ARBEIDSTEKNIKKER SMIDIG METODIKK Smidig metodikk er en utviklingsmetode som ofte brukes i prosjekter hvor det kan oppstå usikkerheter vedrørende tidsbruk og omfang. Oppdragsgiver var ikke sikker på hvordan han ønsket at vi skulle løse problemstillingen hans. Løsningens innhold var ikke fastlagt. Med stadig skiftende rammebetingelser var vi nødt til å jobbe smidig og fleksibelt. Endrings- og tilpasningsdyktighet var viktig og gruppen valgte derfor Scrum som smidig metodikk. SCRUM Scrum er en utviklingsmetode som ofte brukes i utviklingen av avanserte informasjonssystemer. Metoden er basert på empirisk prosesskontroll, og oppfordrer til iterativ og inkrementell utvikling i form av sprinter. Sprintene varer i 1-4 uker. Hver sprint bidrar til små produktinkrementer, og inneholder en rekke funksjoner som skal implementeres i produktet. Denne listen med funksjoner kalles sprintbacklogg. Denne listen blir i rekkefølge utført, testet og avsluttet. Når en funksjon har blitt ferdigtestet og avsluttet, begynner man på neste funksjon. Beregnet tidsforbruk på hele sprintbackloggen er grov estimert, og dermed vil sprintene ha varierende tidsomfang. Hele samlingen av funksjoner som skal implementeres og til sammen utgjøre hele produktet, kalles produktbacklogg/produkt kø. Side 26 av 185

27 Prosessdokumentasjon DAGLIGE OG UKENTLIGE SCRUM-RUTINER Før oppstart av en sprint lagde vi en sprintbacklogg med funksjoner som vi ønsket å fullføre. Funksjonene som skulle implementeres ble ofte utformet som user stories. Slik så noen av våre user stories ut: Som en ønsker jeg å kunne slik at Administrator legge til brukere i databasen jeg kan starte å involvere andre parter i prosjektene. Administrator legge til bruker til prosjektet jeg kan begynne å tildele filrettigheter til de forskjellige brukerene. Administrator jeg kan få en visuell legge til bilder i forståelse av hvor stort skaderapportene omfang skaden har. bruker få filrettigheter fra administrator jeg kan få tilgang til de filene som angår meg i prosjektene jeg er involvert i. Denne sprint backloggen utgjorde hele «to-do-listen» for hver enkelt sprint. For å ha oversikt og kontroll over denne listen benyttet vi oss av en scrum-tavle på nettet. Scrumtavlen ble fortløpende oppdatert. Figur 2: Scrum-tavle fra Side 27 av 185

28 Prosessdokumentasjon Under produksjonen av mer omfattende funksjoner benyttet vi oss av «pair programming». To hoder kan ofte fungere bedre enn ett. Ved mer kompliserte problemstillinger var det fordelaktig å være flere som diskuterte og kom med innspill. Denne typen programmering er hentet fra den smidige prosessmodellen Extreme Programming (XP). Når en funksjon var i testfasen, testet vi den internt i gruppen først. Når vi hadde ferdigtestet en gruppe funksjoner, publiserte vi nettsiden på skolens server. På den måten ble det mulig for oppdragsgiver å teste funksjonene og komme med eventuelle tilbakemeldinger. Når oppdragsgiver sa seg fornøyd med funksjonen, ble den lagt til i kolonnen for ferdige funksjoner. Flere ganger i uken startet vi dagen med et kort møte hvor hvert gruppemedlem fortalte kort og presist hva som har blitt gjort siden forrige møte, samt hva dagens arbeidsoppgaver er. Hensikten med slike møter er å få oversikt over hva som har blitt gjort, og hva som må gjøres for å kunne avslutte en sprint og opprettholde progresjonen i prosjektet. Vi førte dagbok under hele prosjektperioden. Dagboken blir beskrevet nærmere i kapittelet om styringsdokumentene. KOMMUNIKASJON MED OPPDRAGSGIVER OG VEILEDER Vi har gjennom hele prosjektperioden hatt jevnlig kontakt med oppdragsgiver. Vi har først og fremst kommunisert over telefon eller mail. De gangene vi følte det var nødvendig med en lengre samtale, avtalte vi et møte. Disse møtene fant sted på Aker Brygge eller i HiOAs lokaler. Fysiske møter var nødvendig de gangene vi hadde gjort store endringer eller hadde viktige spørsmål. Møtene var også svært viktige for å få tilbakemeldinger på mobilapplikasjonen. Disse møtene fikk vi svært mye ut av, og kunne ikke vært foruten. Med unntak av de fysiske møtene, gikk mye av kommunikasjonen som sagt over telefon eller mail. Vi har publisert nye versjoner av produktet og bedt om tilbakemeldinger fra oppdragsgiver. Vi har gjennom hele prosjektperioden fått raske tilbakemeldinger, og oppdragsgiver har alltid vært lett tilgjengelig. Den korte responstiden gjorde at vi hadde god flyt i sprintene, og sjeldent gikk ut over beregnet tid. Kontakten med vår veileder Kirsten Ribu har variert ut ifra vårt behov. I startfasen av prosjektet ble vi enige med Kirsten om at vi skulle henvende oss til henne hvis vi trengte noe fremfor å ha faste møter. Hun har hatt mye å gjøre i prosjektperioden, og vi så ikke Side 28 av 185

29 Prosessdokumentasjon nytteverdien i å ha ukentlige møter. Tidlig i prosjektperioden benyttet vi oss flere ganger av HiOAs ilab, som er et rom med flere maskiner og annet utstyr som kunne bli aktuelt å bruke. For å booke dette rommet måtte vi gå gjennom Kirsten. STYRINGSDOKUMENTENE Både før og underveis i prosjektperioden var det noen rapporter og skisser vi var nødt til å publisere på gruppens nettside. Huskelisten med frister så slik ut: Nr Oppgave Hvor Frist 1 Statusrapport På nettet Prosjektskisse På nettet Forprosjekt På nettet STATUSRAPPORT Statusrapporten var den første rapporten vi produserte sammen som en bachelorgruppe. Denne rapporten skulle beskrive arbeidet vårt med å finne et hovedprosjekt. Den skulle blant annet inneholde disse punktene: Navn på gruppemedlemmene. En beskrivelse av hva vi hadde gjort til da for å få tak i et prosjekt. Beskrive hvilke prosjekttyper som var aktuelle og hvilken type oppdragsgiver vi kunne tenke oss. I denne perioden begynte vi også å føre dagbok. Vi startet med å skrive i dagboken etter hvert møte vi hadde, men vi modererte oss etter hvert. Vi hadde såpass mange møter at det hadde resultert i mange entries med lite innhold. Dagboken ble da oppdatert ukentlig, direkte på gruppens nettside. Side 29 av 185

30 Prosessdokumentasjon Figur 3: Dagbok fra gruppens hjemmeside PROSJEKTSKISSE Dette dokumentet skulle skissere og presisere hva slags prosjekt vi hadde valgt å jobbe med. Vi utformet en prosjektbeskrivelse og en kort beskrivelse av oppdragsgiver. Videre skulle vi redegjøre for mulige krav til maskinplattform, dataverktøy og andre rammebetingelser. Kontaktinformasjonen til oppdragsgiver og kontaktpersonen i bedriften skulle også oppgis i denne skissen. I tillegg måtte vi gi hovedprosjektet en foreløpig tittel. FORPROSJEKT Dette dokumentet ble påbegynt så snart prosjektet ble godkjent som bachelorprosjekt og vi hadde fått tildelt en intern veileder. I forprosjektet skulle problemområdet defineres ytterligere og skildres så presist som mulig. Her skulle det også avgjøres om prosjektet lot seg gjennomføre og ferdigstilles innenfor de gitte tidsrammene, eller om det måtte bli avgrenset. Vi måtte avgjøre rammebetingelser som maskinplattform og utviklingsmiljø vi skulle benytte oss av. I tillegg utarbeidet vi en risiko plan og en grov estimert fremdriftsplan for resten av prosjektet. Side 30 av 185

31 Prosessdokumentasjon Figur 4: Fremdriftsplan ARBEIDSFORHOLD PILESTREDET 35, 0166 OSLO (P35) I all hovedsak har vi arbeidet i HiOAs lokaler i Pilestredet 35. Fakultet for teknologi, kunst og design og fakultet for samfunnsfag har base her. Det gjorde at vi raskt kunne komme i kontakt med veilederen vår og tidligere forelesere. P35 har store og flotte lesesaler, tilgang til stasjonære datamaskiner, bibliotek og utallige grupperom med nødvendig utsyr. Det er også en stor kantine som serverer varm mat hele dagen. For å sikre oss tilgang til et av grupperommene brukte vi HiOAs reservasjonsverktøy WebUntis. Dette verktøyet lar studenter velge tidsperiode og utvalgskriterier for den romtypen man ønsker å reservere. Begrensningen er fem reservasjoner per student. Stort sett trengte vi ikke noen spesielle ressurstyper som projektor, overhead Figur 5: Lokalene i P35 o.l. Enkelte ganger hadde vi ikke reservert rom, eller trengte et grupperom med en ressurs som ikke var tilgjengelig i P35. Da benyttet vi oss av P32. Side 31 av 185

32 Prosessdokumentasjon PILESTREDET 32, 0166 OSLO (P32) P32 ligger et steinkast unna P35. De gangene vi ikke hadde tilgang på tilstrekkelige fasiliteter i P35, benyttet vi oss av P32. Fakultetet for helsefag holder til her. Lokalene eies også av Høgskolen i Oslo og Aershus, og man kan bruke WebUntis til å reservere rom. Fasilitetene er like gode her. VERKTØY SPRÅK C# C# er et objekt orientert programmeringsspråk utviklet av Microsoft og tilhører.netplattformen. HTML (HYPERTEXT MARKUP LANGUAGE) HTML er det standardiserte markeringsspråket for formatering av nettsider med informasjon som skal vises i en nettleser. CSS (CASCADING STYLESHEET) CSS er et språk som brukes til å definere utseende på filer skrevet i HTML. Side 32 av 185

33 Prosessdokumentasjon JAVASCRIPT JavaScript er et programmeringsspråk som benyttes for å gjøre nettsider interaktive og dynamiske. PHP (HYPERTEXT PREPROCESSOR) PHP har flere bruksområder, blant annet har det ofte blitt brukt i utviklingen av dynamiske nettsider. En annen nyttig funksjon ved PHP er muligheten til å behandle informasjon på tjener og sende det til klient. PHP har støtte for mange forskjellige databasesystemer og mulighet til å jobbe med filer, datautvekslingsformater som for eksempel JSON, samt behandle tekst, PDF og liknende dokumenter. JAVA Java er et objekt orientert programmeringsspråk. Mobile applikasjoner til Android er en type program som man kan utvikle med dette språket. UTVIKLING VISUAL STUDIO 2013 Visual Studio er et IDE fra Microsoft. Visual Studio blir brukt til å utvikle nettsider, webapplikasjoner og web servicer. Side 33 av 185

34 Prosessdokumentasjon ECLIPSE 4.2 JUNO Eclipse er en fullverdig Java IDE som har alt som skal til for å utvikle fullverdige Java applikasjoner med unntak av Java JDK. JAVA DEVELOPMENT KIT (JDK) JDK er en programvareutviklingspakke for å utvikle, kompilere, debugge og overvåke Javaapplikasjoner. ANDROID SDK Android SDK er en programvareutviklingspakke som gjør det mulig å utvikle Androidapplikasjoner. Android SDK inneholder flere nyttige verktøy og en emulator. LOGCAT LogCat følger med Android SDK, og gjør det mulig å debugge/feil søke i Androidapplikasjoner. ANDROID DEBUG BRIDGE (ADB) ADB Følger med Android SDK. Dette er et verktøy som gjør det mulig å få Eclipse til å kommunisere med emulatoren eller en tilkoblet enhet. Side 34 av 185

35 Prosessdokumentasjon DALVIK DEBUG MONITOR SERVER (DDMS) DDMS kan gjennom ADB feil søke kjørende applikasjoner på emulatoren eller en tilkoblet enhet. Her kan man feil søke og overvåke nettverkstrafikk, diskplass, minnebruk o.l. ADOBE PHOTOSHOP Photoshop er et kraftig bilderedigeringsprogram. De flest ikoner og logoer er lagd eller redigert i dette programmet. UTVIDELSER OG RAMMEVERK ENTITY FRAMEWORK Entity Framework ( EF ) er et åpent kildekode rammeverk med ORM (object-relational mapping) for.net. BOOTSTRAP Bootstrap er et front-end-rammeverk. Det er et bibliotek med verktøy for å designe nettsider og webapplikasjoner. Det inneholder HTML- og CSS-baserte design templates. JQUERY jquery er et JavaScript-rammeverk, hvis hensikt er å forenkle bruken av JavaScript. Side 35 av 185

36 Prosessdokumentasjon JSON (JAVASCRIPT OBJECT NOTATION) JSON er en tekst basert struktur for enkel overføring av data. Avledet fra, men allikevel uavhengig av JavaScript. STUDIODONDER TESTHELPER Testhelper er en utvidelse til Visual Studio som brukes når man skal enhetsteste webapplikasjoner. TOASTR Toastr er et notifikasjonsbibliotek for JavaScript. Brukes til å gi enkle tilbakemeldinger til brukere. VERSJONSKONTROLL TEAM EXPLORER/TEAM FOUNDATION SERVER (TFS) TFS er en funksjon integrert i Team Explorer og gjør det mulig å endre kode, hente gamle versjoner og laste opp nye versjoner. DROPBOX Dropbox er et filarkiv som ligger lagret på internett men vises på datamaskinen. Det ble brukt som versjonskontroll for Android-applikasjon. Side 36 av 185

37 Prosessdokumentasjon DOKUMENTASJON MICROSOFT WORD Word er et tekstredigeringsprogram utviklet av Microsoft. Programmet gjør det enkelt å forfatte innhold, plassere grafikk og endre stiloppsett. YED yed er en skrivebords applikasjon som brukes til å generere diagrammer og oversikt over entiteter. UTVIKLINGSPROSESSEN I dette kapitlet beskriver vi de forskjellige fasene i utviklingsprosessen. Etter konseptutviklingsfasen vil vi dele opp denne delen i to deler, en for hver av produktene. Utviklingsprosessene til Android- og webapplikasjonen blir beskrevet i hver sin del. Dette for å enklere kunne få innsikt i produktene individuelt. KONSEPTUTVIKLING RISIKOPLAN I begynnelsen av prosessfasen utformet vi en risiko plan for å bevisstgjøre alle medlemmene hvilke utfordringer som kunne oppstå i løpet av prosjektperioden. Det var viktig å komme med forslag på tiltak som kunne forhindre og møte på disse utfordringene. Side 37 av 185

38 Prosessdokumentasjon KORTVARIG SYKDOM/FRAVÆR Risikonivå: Høy Konsekvens: aktiviteter kan bli forsinket eller ikke gjort, avhengig av sykdommens hemming. Forebygging: kommunisere med gruppen, legge dokumenter ut i Dropbox/Team Foundation og sørge for at de andre gruppemedlemmene er klar over situasjonen, og kan hjelpe til med- eller ta over eventuelle oppgaver. LANGVARIG SYKDOM/FRAVÆR Risikonivå: Lav Konsekvens: mer arbeid på resten av gruppen, aktiviteter kan bli forsinket og det blir hull i aktivitetsplanen som må fylles opp. Forebygging: gruppemedlem må kommunisere med gruppen, legge dokumenter ut i Dropbox/Team Foundation og sørge for at de andre gruppemedlemmene er klar over situasjonen. Gruppen må fylle opp eventuelle hull i arbeidsfordeling, og holde god kommunikasjon. TIDSKLEMME Risikonivå: Middels Konsekvens: Kan risikere å ha så dårlig tid at ting leveres uferdig, eller i verste fall at vi ikke får levert i tide, og dermed får trekk i karakter/stryk. Forebygging: Starte tidlig å fordele oppgavene. Jobbe effektivt når vi møtes, og hele tiden å ha god kommunikasjon. TAP AV DATA Risikonivå: Lav Konsekvens: Miste arbeidet vårt, og må gjøre ting på nytt. Da vil det også få konsekvenser for tidsfristene. Side 38 av 185

39 Prosessdokumentasjon Forebygging: Bruke Dropbox/Team Foundation, samt være flinke til å stadig lagre dokumenter lokalt for å ha back-up lagret på flere steder. KONFLIKTER I GRUPPA Risikonivå: Lav Konsekvens: Bli uenige om prosjektet. Kan skape dårlig arbeidsmoral. Kan gi dårligere resultat. Forebygging: Gjøre de oppgavene vi må. Møte opp på møter. Bli ferdig til avtalt tidsfrister. Være behjelpelige og imøtekommende. DATAINNSAMLING Fra første stund har vi visst hva hovedfunksjonen til applikasjonen vår skulle være. Vi fikk derimot veldig frie tøyler når det kom til hvordan vi skulle nå målene. Det fantes ingen tidligere utgave av applikasjonen, så vi måtte planlegge og bygge alt fra bunnen. Vi forespeilet oss en applikasjon basert på samme konsept som Dropbox, en lagringstjeneste på internett. Oppdragsgiver hadde i svært liten grad spesifisert noen krav til løsningen på forhånd. Datainnsamlingen foregikk derfor kontinuerlig gjennom hele prosjektperioden. Personlige møter og annen kommunikasjon har vært en viktig del av dette prosjektet. Vi fikk innspill fra oppdragsgiver i møter og på mail og utviklet prototyper som oppdragsgiver kunne teste. Deretter fikk vi tilbakemeldinger og kunne endre prototypene slik at løsningene samsvarte med oppdragsgivers ønsker og forventninger. MÅLGRUPPE OG BEHOV Oppfølgingsverktøyet vi har utviklet skal forenkle hverdagen til oppdragsgiver. Produktet vårt er først og fremst rettet mot oppdragsgiver og andre parter involvert i oppdragsgivers arbeidsoppgaver. Det er i all hovedsak ment som et internt oppfølgingsverktøy, og har dermed en ganske smal målgruppe. I tillegg er det lite variasjon i hvem de eksterne partene er. Det kan være et stort sprik i alder, og valgene våre har blitt påvirket av dette. Side 39 av 185

40 Prosessdokumentasjon GRUPPEMØTER OG BRAINSTORMING Etter den innledende datainnsamlingen begynte vi med hyppige gruppemøter. For å samle tankene og organisere arbeidet var dette nødvendig. Det vi følte var viktigst å gjøre først var å skissere modeller av databasen. Produktet er avhengig av en godt utformet database. Vi antok at det kom til å bli gjort en del endringer underveis, men det var viktig med et godt utgangspunkt. Vi begynte også tidlig med skissering av brukergrensesnittet til både web- og androidapplikasjonen. Oppdragsgiver var opptatt av at begge applikasjonene skulle ha en minimalistisk stil og være intuitiv å bruke. Etter noen uker med diskusjon, skissering og prototyping var vi klare til å presentere konseptet for oppdragsgiver. TESTING AV ANDROIDAPPLIKASJON Se vedlegg 1. TESTING AV WEBAPPLIKASJON Se vedlegg 1. FAGLIGE UTFORDRINGER DESIGN AV WEBAPPLIKASJONEN En av de største utfordringene vi har hatt er å designe webapplikasjonen. Oppdragsgiver ønsket seg et mest mulig minimalistisk design. Vårt hovedfokus har dessuten vært på funksjonalitet, og design har ikke vært hovedprioritet. Det viktigste har vært å lage et rent og forståelig design i admin- og brukerdelen av webapplikasjonen. All funksjonaliteten hos admin kan skape forvirring i navigasjonen, så vi har lagt mye vekt på brukerveiledningen. Side 40 av 185

41 Prosessdokumentasjon ANDROID PHP WEBSERVER Å få Android-applikasjonen til å kommunisere med webserveren har vært en utfordring. Vi ble tvunget til å ha et knippe PHP-filer som mellomledd. Etter mye prøving og feiling fikk vi bekreftet kontakt mellom applikasjonene. Det oppstod i midlertidig trøbbel da vi implementerte login-funksjonen i mobilapplikasjonen. Resultatet av hashing av samme passord på de forskjellige applikasjonene ga forskjellig resultat. Tatt i betraktning at mobilapplikasjonen har begrenset funksjonalitet og et fåtall brukere, valgte vi derfor å droppe kravet om å logge inn. AVANSERT DATABASE Databasen til webapplikasjonen er den mest avanserte databasen vi har lagd. Mange modeller og relasjoner har gjort den kompleks. I tillegg hadde vi bekymringer for hvordan det skulle gå med kommunikasjonen på tvers av applikasjonene. Det viste seg å fungere som ønsket, men databasen har krevd mer tid og arbeid enn planlagt. MANGELFULL ENHETSTESTING Selv om testdrevet utvikling ikke har vært i hovedfokus, har vi utviklet noen enhetstester. Dessverre fikk vi ikke tid underveis til å lage like mange vi i utgangspunktet ønsket og det endte med et litt mangelfullt sett med slike tester. Med tanke på webapplikasjonens omgang kunne vi med fordel satt av mer tid til dette. Planlegging av tidsbruk rundt utviklingen av disse kunne vært bedre. Side 41 av 185

42 Prosessdokumentasjon PERSONVERN OG KONFIDENSIALITET Under utformingen av produktet vårt har vi hele tiden blitt tvunget til å tenke på konfidensialitet og sikkerhet. Dette gjaldt både for innloggingsinformasjon og rundt opplastede dokumenter. For oppdragsgiveren vår er det særdeles viktig å holde visse dokumenter skjult for andre parter. Kunder skal ikke ha innsyn i et prosjekts budsjett, en murer skal ikke kunne se en annen murers kontrakt osv. Mange av dokumentene vil inneholde sensitiv informasjon om forskjellige parter, og det er viktig og påkrevd at denne typen informasjon beskyttes og hemmeligholdes. Dette har vi løst ved at administrator må manuelt gi tilgang til hver fil, og på denne måten unngå filrettigheter på ville veier. Det er også lagt til rette for rask fjerning av filrettigheter. DOKUMENTASJONSFASEN Denne fasen ble påbegynt dagen gruppen ble dannet, og varte helt til prosjektet ble avsluttet. Tidlig i prosjektet var det styringsdokumentene som hadde hovedfokus med sluttrapporten liggende i bakhodet. Vi utformet en mal til sluttrapporten tidlig, og gjorde den mer utfyllende underveis. Vi noterte stikkord i sluttrapporten hele tiden, noe som gjorde det lettere å huske alle elementer som skulle med i rapporten. Utformingen av sluttrapporten har vært en oppgave alle gruppemedlemmene har deltatt på. Som tidligere forklart ble gruppen vår etter hvert delt inn i to grupper etter applikasjonene, og hver gruppe hadde derfor et bedre grunnlag til å greie ut om sin respektive applikasjon. For å kunne holde styr på alle delene i rapporten har vi brukt DropBox som lagringssted, men vi har jobbet lokalt for å unngå overflødige kopier. Dokumentasjonsstandarden til HiOA har blitt brukt flittig, selv om den enkelte ganger har virket mot sin hensikt og skapt mer forvirring. Hovedprosjektet vårt har omfattet utviklingen av to applikasjoner, og det har derfor vært nødvendig med noen endringer i sluttrapportens oppsett. Vi har prøvd etter beste evne å tolke det som standarden beskriver, og føler vi har fulgt standarden i stor grad. Side 42 av 185

43 Prosessdokumentasjon KRAVSPESIFIKASJONEN OG DENS ROLLE Kravspesifikasjon har hjulpet oss med å utforme user stories. Vi har brukt kravspesifikasjonens brukerbehov til å lage mer spesifikke brukerkrav. Dette var krav oppdragsgiver satte for oss. Kravene ble rangert etter viktighet, og tilhørende funksjoner implementert i rekkefølge sprint vis. Dette gjorde vi for at oppdragsgiver fortest mulig kunne teste og gi tilbakemeldinger på de viktigste og mest sentrale funksjonalitetene. På denne måten blir det enklere å droppe funksjoner som ikke er essensielle for produktet vårt, skulle det oppstå tidsnød. Underveis i prosjektperioden har krav og rammebetingelser endret seg. Både ved at oppdragsgiver har kommet med nye ønsker og tanker, og ved at utviklingsteamet har kommet med forslag. Den største endringen var å droppe utviklingen en ios-versjon av Android-applikasjonen. Det var i utgangspunktet usikkert om det var et behov for en mobilapplikasjon for ios-plattformen. Da det viste seg at ingen i applikasjonens brukergruppe var i besittelse av mobile enheter med dette operativsystemet, ble denne idéen forkastet. AVSLUTTENDE DEL ORD FRA OPPDRAGSGIVER Se vedlegg 4. SAMARBEID I GRUPPEN Når man skal jobbe tett på hverandre over en lengre periode er det viktig å unngå konflikter og sørge for å skape et positivt arbeidsmiljø. Problemer innad i gruppa kunne ha ført til tidspress og at oppdragsgiver endte opp med et produkt som ikke holdt mål. Dette har aldri vært et aktuelt problem. Alle gruppemedlemmene kjenner hverandre godt, og samarbeidet har fungert meget bra. Man må forholde seg til oppgaven, samspill og planlegging på en helt annen måte når man jobber i grupper. Etter vår oppfatning har dette gått knirkefritt. Side 43 av 185

44 Prosessdokumentasjon I begynnelsen av prosjektet jobbet hele gruppen sammen, men etter konseptutviklingen delte vi oss i to grupper. Én gruppe fokuserte på webapplikasjonen, og den andre fokuserte på Android-applikasjonen. Gruppene jobbet alltid sammen og kunne hjelpe hverandre hvis det behøvdes. Alle valg har blitt diskutert i plenum og blitt løst demokratisk. Vi har alle hatt ulike roller og forskjellige oppgaver gjennom hele prosjektet. Vi utnevnte en gruppeleder tidlig i prosjektet, men gjorde det klart at alle skulle være med å bestemme. Når vi har delt ut ansvar for forskjellige områder og oppgaver har vi sagt at den som får ansvaret ikke nødvendigvis skal gjøre alt selv, men ta ansvar for at det blir gjort og eventuelt hjelpe til, dersom noen trenger det. VEILEDNING VED HIOA Den interne veilederen vår Kirsten Ribu har først og fremst gitt oss tips og råd om selve bachelorprosjektet. Hva som er viktig å huske på i dokumentasjonen, viktigheten med planlegging og tips for å unngå tidsklemmer. Hennes kompetanse har hjulpet oss å komme i mål med prosjektet. Kommunikasjonen med Kirsten har stort sett foregått gjennom fronter, da hun som regel befant seg andre steder enn kontoret sitt. De gangene vi hadde mer tekniske spørsmål, henvendte vi oss til tidligere forelesere. Tor Krattebøl er faglærer og underviser i Webapplikasjoner (ITPE3200) og Torunn Gjester er faglærer og underviser i Applikasjonsutvikling (DAVE3600). Disse var stort sett alltid tilgjengelig, det var bare å oppsøke kontoret deres. Veiledningen deres har vært verdifull og til stor hjelp. Vi er veldig fornøyd med veiledningsmulighetene under bachelorprosjektet. Vårt inntrykk er at veiledere og forelesere har ønsket å gjøre sitt ytterste for å hjelpe studentene med å oppnå best mulig resultat. Dette vil vi takke for. LÆRINGSUTBYTTE Før hovedprosjektet hadde vi gode kunnskaper innen kodespråkene C#, Java, CSS, HTML. Erfaring med utviklerrollen i et stort prosjekt var helt ny, og vi er sikre på at denne erfaringen vil gagne oss i arbeidslivet. En liten del av prosjektperioden har gått med på å lese oss opp på teknologien vi har benyttet, men stort sett har vi fulgt konseptet «learning by doing». Blant kilder vi har brukt hyppigst inngår både StackOverflow, YouTube og C# Corner. Vi føler vi har lært masse nytt om utviklingsprosessen, og hvor vanskelig det er å estimere hvor lang tid man kommer til å bruke på de forskjellige delene i et prosjekt. Vi har fått erfaring med Side 44 av 185

45 Prosessdokumentasjon smidig utvikling, noe vi tidligere bare kunne i teorien. Vi har også fått erfaring med å koble en Android-applikasjon til en webserver og kommunisere med den. DET FERDIGE PRODUKTET NYTTEVERDI Idéen til webapplikasjonen kommer fra oppdragsgiver som arbeider med utbyggingsprosjekter. Etter flere år med prosjekter endte det med at han fikk en dårlig oversikt over hvilke filer som tilhørte hvilke prosjekter og ville ha en mulighet for å lagre alle filer på samme sted. Ettersom oppfølgingsverktøyet vårt lagrer alt av filer på en server og linker disse til hvilke prosjekter de hører til, vil dette løse problemet til oppdragsgiver. Oppdragsgiver arbeider også med å selge byggene som han bygger, dette innebærer å reklamere prosjektene sine slik at eventuelle kunder blir interessert. Dette gjøres fra webapplikasjonens forside ved at oppdragsgiver kan oppdatere informasjonen på nettstedet med informasjon og bilder om de pågående prosjektene. Kunder vil da kunne se prosjektet som det reklameres for, og via informasjonssiden kan kunden skaffe kontaktinformasjonen til oppdragsgiver for å få mer informasjon. Kunder kan avtale et kjøp med oppdragsgiver før et bygg er ferdigbygd. da vil det være nødvendig for daglig leder og holde kundene oppdaterte om hvordan utbyggingen går, og om eventuelle endringer i bygget. Nettstedet løser dette ved at administrator kan opprette en bruker som kan legges til et prosjekt og da bli lagt til som en kunde. En kunde vil da få innloggingsinformasjon og vil få en side på nettsiden, her har kunden en mappe med filer som administrator kan laste opp, som for eksempel bilder av kjøkkeninnredning. Dette gjør at oppdragsgiver slipper mye spørsmål fra kundene, fordi kundene har allerede informasjonen de skal ha på nettstedet. Vi utviklere har hatt stor nytte av å utvikle et så komplekst prosjekt. Vi har hatt ansvaret for organiseringen og oppbyggingen av produktet da oppdragsgiver ikke hadde noen kunnskap innen webutvikling. Når vi skulle starte utviklingen måtte vi finne ut av hvordan vi skulle løse de forskjellige problemstillingene oppdragsgiver hadde til oss. Dette ga oss god kunnskap for å utvikle et prosjekt helt fra starten av og sette alt sammen til en ferdigstilt løsning. Ettersom vi har arbeidet for en oppdragsgiver som ikke helt vet hva slags ferdig løsning han er ute etter, har vi lært mye om at det er noe funksjonalitet som vi ikke kunne implementere i løsningen ut ifra oppdragsgivers ønsker. Det var også veldig lærerikt å jobbe med noen som ikke helt vet hva han vil ha, og på den måten bli involvert i konseptutviklingsfasen. Vi fikk Side 45 av 185

46 Prosessdokumentasjon innsikt i alle deler av systemutvikling. Vi var nødt til å hele tiden å holde oppdragsgiver oppdatert med endringer og implementering. Tiden etter første møte med oppdragsgiver handlet mest om systemutvikling i teamet. Vi opplevde at det gikk litt for lang tid til neste møte, noe som er vår egen feil. Under det neste møte merket vi at oppdragsgiver hadde mange nye idéer og tanker, og vi var nødt til å endre mye som allerede var testet og ferdigstilt. Etter dette skjønte vi at vi var nødt til å oppdatere oppdragsgiver kontinuerlig gjennom hele prosjektutviklingen. Vi innså viktigheten av tett og jevnlig kommunikasjon med oppdragsgiver. VIDEREUTVIKLING Vi føler produktet vårt er et produkt som kan være veldig nyttig i mange forskjellige bransjer. Potensialet er stort, og det finnes mange bruksområder. Et oppfølgingsverktøy for oppdrag og prosjekter er nyttig, og noen endringer og tillegg i koden kan tilpasse verktøyet til å passe for andre bedrifter i andre bransjer. WEBAPPLIKASJON Webapplikasjonen vår er finjustert til å fungere for oppdragsgiver. Når man oppretter et prosjekt, opprettes det et bestemt antall brukergrupper og mapper. Ved en eventuell videreutvikling er det mulig å endre koden til nettstedet slik at den kan brukes i andre prosjekter enn utbyggingsrelaterte. Behovet for brukertesting blir større hvis produktet eventuelt skal videreutvikles til å kunne benyttes av flere typer bedrifter. Vi har først og fremst fokusert på oppdragsgiver og hans preferanser. Det er derfor et stort forbedringspotensial med utformingen av et universelt brukergrensesnitt. Muligheten til å legge til flere administratorer har blitt implementert, men har ikke blitt gjort tilgjengelig. Oppdragsgiver gjorde det klart at det kun er aktuelt med en administrator (Ketil Johansen). Tilgjengeliggjøring av denne funksjonen er enkel å gjøre, og kan bli nødvendig ved videre utvikling av verktøyet. Webapplikasjonen har best støtte i nettleseren Google Chrome. Oppløsningen varierer fra browser til browser, og dette er et område som er aktuelt for videreutvikling. Det samme gjelder skalering avhengig av skjermstørrelsen på enheten som benyttes. Side 46 av 185

47 Prosessdokumentasjon ANDROID-APPLIKASJON Android-applikasjonen er en lettere utgave av webapplikasjonen. Utviklingspotensialet i denne mobile applikasjonen er stort. Det ultimate vil være å utvikle den slik at den er et tilsvarende produkt til webapplikasjonen. Det aller første som må gjøres da er å implementere et login-system. Slik kan både brukere og administratorer logge seg inn og bruke verktøyet. Ettersom oppdragsgiver ikke hadde noe behov for å ha en mobilapplikasjon til Appleenheter, var denne idéen noe vi forkastet. Skulle det hende at verktøyet når et større publikum og flere brukere, hadde vi blitt tvunget til å utvikle en tilsvarende ios-applikasjon for å nå et større publikum. Manglende skalering for større enheter må også gjøres noe med. Flere brukere betyr et større mangfold av enheter og varianter. KONKLUSJON Oppfølginsverktøyet vi har utviklet er et resultat av mangfoldige arbeidstimer. Oppgaven har vært utfordrende og interessant, og vi har fått ekstremt mye ut av perioden. Vi har fått erfart hvordan det er å jobbe som utvikler i et team, og hvordan man skal takle utfordringer og tidspress. I tillegg har vi vært nødt til å forholde oss til en oppdragsgiver, og det har vært ekstremt givende å kunne realisere oppdragsgivers visjon så godt som mulig. Vårt inntrykk er at vi har vært for dårlige til å planlegge i forkant av prosjektstart. Dette inkluderer også planlegging i konseptutviklingsfasen. Dette kan skyldes manglende forståelse av prosjektets størrelse. Vi hadde en mistanke om at konseptet for produktet var i minste laget, men dette tok vi helt feil av. Med bedre planlegging kunne vi ha oppnådd et enda bedre resultat. Kjemien og arbeidsmiljøet innad i utviklerteamet har vært positivt hele veien. De utfordringer vi har støtt på gjennom perioden har vi taklet på en god måte. Vi har hatt mange konstruktive diskusjoner, og tatt demokratiske valg. Det har vært en god tone mellom alle gruppemedlemmene, noe som er viktig og bidrar til positivitet og engasjement. Side 47 av 185

48 Prosessdokumentasjon På bakgrunn av oppdragsgivers respons sitter vi igjen med et positivt inntrykk av prosjektperioden. Vi føler at vårt produkt kan bidra til en bedre hverdag for oppdragsgiver og alle involverte parter. Med et inntrykk av høy måloppnåelse, ser vi tilbake på bachelorprosjektet som ekstremt lærerikt og givende. Side 48 av 185

49 Side 49 av 185

50 Produktdokumentasjon Webapplikasjon PRODUKTDOKUMENTASJON WEBAPPLIKASJON FORORD Produktet vi har utviklet er i all hovedsak et administrasjonsverktøy for oppdragsgiver, med unntak av noen sider med generell informasjon til andre besøkende. Kapitlene i denne rapporten tar for seg hvordan løsningen er bygget opp kodemessig, hvordan mappestrukturen ser ut på serveren og produktets funksjonalitet. Før denne rapporten leses vil det være fordelaktig å ha lest innledningen og presentasjonen av oppgaven. For å unngå eventuelle misforståelser med hensyn til terminologi refererer vi til ordlisten i vedlegg 2. Side 50 av 185

51 Produktdokumentasjon Webapplikasjon INNHOLD Forord Innhold Systemkrav og installasjon Database-, kode- og mappestruktur ER-diagram Model View Controller (MVC) MODEL (.cs) VIEWS (.cshtml) Administrator-mappen Folder-mappen Home-mappen Project-mappen Report-mappen Shared-mappen User-mappen Controllers (.cs) ViewModels (.cs) Lagdeling Mappestruktur Funksjonalitet Programflyt Administrasjonsdel Administrasjon av prosjekter LEgg til nytt prosjekt Oversikt over prosjekter FILBEHANDLING, Brukere og brukergrupper i prosjekt Rapporter Administrasjon av den offentlige delen (Content Management System) Side 51 av 185

52 Produktdokumentasjon Webapplikasjon Administrasjon av brukere Legge til, endre og slette Brukergrupper Databaselogg Brukerdel Filbehandling Prosjektfiler Personlige filer Offentlig del Forside Informasjonsside Tilbakemeldinger Modaler Toasts Design Fargebruk Bootstrap Feilhåndtering Try, Catch Regex Enhetstesting (Unit-Testing) Sikkerhet Hashing av passord Sessions Videreutvikling av produktet Side 52 av 185

53 Produktdokumentasjon Webapplikasjon SYSTEMKRAV OG INSTALLASJON For at webapplikasjonen skal kunne kjøre på internett, er brukeren nødt til å ha en server som kan kjøre.net-løsninger for eksempel Windows Server og kunne sette opp en database for dette nettstedet. Serveren må også kunne kjøre en SQL-database. Det absolutt beste for løsningen er hvis brukeren har en server som både har webapplikasjonen og lagringsplassen på server, hvis ikke er det nødvendig å endre i koden til webapplikasjonen. Vi kjører per nå webapplikasjonen på azurewebsites hos microsoft, noe som er veldig gunstig for løsninger laget i Visual Studio med.net-rammeverk. DATABASE-, KODE- OG MAPPESTRUKTUR ER-DIAGRAM Vi designet en ER-modell etter første møte med oppdragsgiver. Etter vi hadde begynt på webapplikasjonen og kom på neste møte, måtte vi fort legge fra oss denne modellen. Nettstedet ble veldig komplekst på kort tid, og vi måtte utvikle databasemodeller fortløpende gjennom prosjektet. Figuren under viser hva vi endte med. Figur 6: ER-modell Side 53 av 185

54 Produktdokumentasjon Webapplikasjon MODEL VIEW CONTROLLER (MVC) Produktet er satt opp i en bestemt arkitektur kalt MVC. MVC går ut på å skille programmet i tre deler, der modellen tar hånd om data og viewet håndterer brukergrensesnittet. Kommunikasjonen mellom disse går via kontrolleren. Under er en oversikt over hva som befinner seg i vår løsning under disse tre delene og mer informasjon om hva de utretter. MODEL (.cs) Modellklassene i løsningen representerer objekter og er definert med egenskaper. Alle modellklassene har en definert primærnøkkel ved navn ID i form av en integer. Under følger et enkelt eksempel av en slik klasse. namespace Model { public class Admin : IEntity { [Key] public int ID { get; set; } public string Username { get; set; } public string Password { get; set; } } } KLASSE Admin User UserGroup AccessFile Project ProjectLink ConditionReport Report MeetReport Attending BESKRIVELSE Modell for adminbrukere Modell for brukere Modell for brukergrupper Modell for linking av filer til brukere Modell for prosjekter Modell for linking av prosjekter og brukere Modell for tilstandsrapporter Modell for en av delene til tilstandsrapporter Modell for møterapporter Modell for linking mellom deltakere og møterapporter Side 54 av 185

55 Produktdokumentasjon Webapplikasjon Protocol Modell for en av delene til møterapport DeviationReport Modell for avviksrapport del 1 DeviationTreatment Modell for avviksrapport del 2 (behandling) DeviationConsequens Modell som mellomledd i avviksrapport del 2 DeviationClosure InjuryReport InjuryType ReportImage Image FrontPage InfoPage Audit IEntity* Modell for avviksrapport del 3 (avslutning) Modell for skaderapporter Modell som mellomledd i skaderapport for skadetype Modell for bilder tilhørende rapporter Modell for bilder Modell for nettsidens forside Modell for nettsidens Om oss Modell for databaselogg Modell for IEntity interface *IEntity-klassen skiller seg ut fra de andre modellene da det er et interface for å hente ut egenskapene til de øvrige modellene. Når dataen er hentet blir dette lagret i klassen Audit.cs og kan videre listes ut som databaselogg i viewet AuditLog.cshtml. VIEWS (.cshtml) Views er grensesnittet på siden som har i oppgave å vise informasjon til brukerne. Views består stort sett av HTML (HyperText Markup Language), men også C# for å liste ut informasjon fra modeller og noen JavaScript. Informasjonen fra modellen blir hentet og forberedt av kontrolleren og deretter sendt til viewet for presentasjon. Øverst defineres alltid hvilken model som skal brukes, og informasjonen som finnes i dette objektet listes ut i en C# foreach. Under følger et eksempel på et view. Side 55 av 185

56 @model ViewBag.Title = "ProjectFiles"; } Produktdokumentasjon Webapplikasjon <h2>projectfiles</h2> <table> <tr> <th>filnavn</th> <th>dato</th> (var item in Model) { using (Html.BeginForm()) { <tr> <td><a href="~/folders/projects/@session["projectname"] /@item.file name" download>@item.filename</a></td> <td> </td> <td>@html.displayfor(modelitem => item.uploaddate)</td> </tr> } } </table> // Kode for oppsett av sider < Model.PageNumber? 0 : page => Url.Action("UserFolder", new { page })) I løsningen er det lagt opp undermapper til views der det ligger.cshtml-filer som tilhører mappens kategori. Figur 7: Oversikt over View-mapper Side 56 av 185

57 Produktdokumentasjon Webapplikasjon Administrator-mappen KLASSE _PartialFileDelete _PartialFrontPage _PartialInfoPage _PartialInfopageFileDelete AuditLog Create CreateFolder CreateProject CreateUser CreateUsergroup EditFolder EditFrontpage EditInfopage EditProject EditUser EditUsergroup Error Index ListProjects ListUsergroups ListUsers ProjectUser BESKRIVELSE PartialView for sletting av filer PartialView for opplasting av bilder til forsiden PartialView for opplasting av bilder til Om oss PartialView for sletting av filer på Om oss View for visning av databaseloggen. (Endret, slettet, lagt til. Hvilken bruker som har gjort det) View for å lage administrator (NB! Ikke aktivt på nettet) View for opprettelse av mapper View for opprettelse av prosjekter View for opprettelse av brukere View for opprettelse av brukergrupper View for endring av mappe View for endring av nettsidens forside View for endring av nettsidens Om oss -side View for endring av prosjekt View for endring av bruker View for endring av brukergruppe View som en blir omdirigert til om noe går galt med en passende feilmelding via TempData View som viser administratorpanelets forside View med liste av alle prosjekter i databasen View med liste av alle brukergrupper i databasen View med liste av alle brukere i databasen View for å legge til brukere til et prosjekt Folder-mappen KLASSE _PartialFolderIndex _PartialPartial _PartialProjectFiles _PartialUserFolder AddFileUser FolderAdmin FolderFiles BESKRIVELSE Lister ut brukergrupper sine mapper i prosjekt Brukes ikke Brukes ikke Brukes ikke Brukes ikke Brukes ikke Veiw for å gi filrettigheter til brukergrupper i et prosjekt Side 57 av 185

58 Produktdokumentasjon Webapplikasjon Index ProjectFiles subfolder UserFolder UserPersonalFolder View for å liste brukergruppers mapper i et prosjekt View for å gi filrettigheter til brukere i et prosjekt View for å liste filer inne i en brukergruppe tilhørende et prosjekt View for å liste en brukergruppes filer i et prosjekt (på brukersiden) View for å liste alle filer en bruker har lastet opp eller har tilgang til å se Home-mappen KLASSE _PartialAbout _PartialIndex About Index Login LoginFailed Mail BESKRIVELSE PartialView som viser bilder på nettsidens Om oss Hovedview for Om oss View for nettstedets startside View for login-modal View som oppsdaterer seg med feilmeldinger om brukeren har skrevet inn feil innloggingsinformasjon PartialView for sending av via kontakt oss på Om oss Project-mappen KLASSE _PartialProjectIndex FilesInProject Index InsertUserToProject ListProjectUsers UserToUsergroup BESKRIVELSE PartialView tilhørende valgts prosjekts hovedside som viser prosjektets mapper View som lister alle filer tilhørende valgt prosjekt View for valgt prosjekts hovedside View for å legge til brukere i valgt prosjekt View for listing av alle brukere tilhørende valgt prosjekt View for å legge til brukere i brukergruppe tilhørende valgt prosjekt Side 58 av 185

59 Produktdokumentasjon Webapplikasjon Report-mappen KLASSE BESKRIVELSE _PartialShowConditionReport PartialView som viser bilder tilhørende valgt tilstandsrapport _PartialShowDeviationClosure PartialView som viser avviksskjema del 3 _PartialShowDeviationTreatment PartialView som viser avviksskjema del 2 AllConditionReports View som lister alle tilstandsrapporter i databasen AllDeviationReports View som lister alle avviksrapporter i databasen AllInjuryReports View som lister alle skaderapporter i databasen AllMeetReports View som lister alle møterapporter i databasen ConditionReport View for opprettelse av ny tilstandsrapport DeviationClosure View for opprettelse av ny avviksrapport (del 3) DeviationReport View for opprettelse av ny avviksrapport (del 1) DeviationTreatment View for opprettelse av ny avviksrapport (del 2) EditConditionReport View for endring av valgt tilstandsrapport EditDeviationReport View for endring av valgt avviksrapport EditInjuryReport View for endring av valgt skaderapport EditMeetReport View for endring av valgt møterapport InjuryReport View for opprettelse av ny skaderapport Meetsummary View for opprettelse av ny møterapport ShowConditionReport View for å vise valgt tilstandsrapport ShowDeviationReport View for å vise valgt avviksrapport (alle tre delene via partialviews om de finnes) ShowInjuryReport View for å vise valgt skaderapport UploadImage View for å laste opp bilde til valgt rapport Shared-mappen KLASSE _Layout _PublicLayout BESKRIVELSE Standard MVC layoutview som inkluderes på alle administratorsider Standard MVC layoutview som inkluderes på alle ikke-administratorsider Side 59 av 185

60 Produktdokumentasjon Webapplikasjon User-mappen KLASSE _PartialUser _PartialUserIndex _PartialUserProjects Index UserIndex BESKRIVELSE Brukes ikke PartialView for å vise en brukers personlige mappe PartialView for å liste hvilke prosjekter en bruker er med i View når administrator er inne på en bruker View for å vise en brukers Min side CONTROLLERS (.CS) Kontrollerne er satt opp med navn som tilsvarer viewundermappenes navn. Dette vil eksempelvis si at AdminController.cs tar seg av kommunikasjonen mellom views under Admin-mappen og modellene disse bruker. Kontroller-metoder er stort sett ActionResults som returnerer views på en av to varianter. Forskjellen på disse to variantene er at den ene åpner viewet med likt navn som ActionResulten, og den andre sender videre eventuell informasjon fra det åpnede viewet med HttpPost. public ActionResult CreateUser() { //return View(); } [HttpPost] [ValidateAntiForgeryToken] public ActionResult CreateUser(UserViewModel UserView) { //Opprette nytt objekt av User med det som sendes med i UserView //Databasemetoder //Fange exceptions } Side 60 av 185

61 Produktdokumentasjon Webapplikasjon KLASSE AdminController FolderController HomeController ProjectController ReportController UserController BESKRIVELSE Kontrollermetoder tilhørende adminviews og deres tilhørende objekter Kontrollermetoder tilhørende mappeviews og deres tilhørende objekter Kontrollermetoder tilhørende publicviews og login/logout Kontrollermetoder tilhørende prosjektviews og deres tilhørende objekter Kontrollermetoder tilhørende rapportviews og deres tilhørende objekter Kontrollermetoder tilhørende brukerviews og deres tilhørende objekter VIEWMODELS (.CS) ViewModels er brukt i løsningen for å enkelt ha mulighet til å vise akkurat den informasjonen vi ønsker fra modeller. Forskjellen på disse og vanlige modeller er at vi kan bygge de opp slik vi vil og ikke nøyaktig slik som de ordinære database-modellene. Eksempelet under illustrerer hvordan denne teknikken er tatt i bruk for å kunne hente ut både UsergroupID og UserID i samme view, opprette en SelectList med brukergrupper og i tillegg bruke IPagedList for å kunne ha flere sider med informasjon. namespace Takst.Views.ViewModels { public class UserUsergroupViewModel { public SelectList Usergroup { get; set; } public PagedList.IPagedList<User> User { get; set; } } public IEnumerable<User> Users { get; set; } public int UsergroupID { get; set; } public int UserID { get; set; } } public class ListUserUsergroupViewModelList { public List<UserUsergroupViewModel> ListUserUsergroup { get; set; } } Side 61 av 185

62 Produktdokumentasjon Webapplikasjon KLASSE BESKRIVELSE AdminViewModel ViewModel for admin AttendingViewModel ViewModel for attenders (knyttet til møterapport) AuditLogViewModel ViewModel for auditlog ConditionReportViewModel ViewModel for tilstandsrapport DeviationClosureViewModel ViewModel for avviksrapport (del 3) DeviationReportFullViewModel ViewModel for avviksrapport (visning av alle delene sammen) DeviationReportViewModel ViewModel for avviksrapport (del 1) DeviationReportTreatmentModel ViewModel for avviksrapport (del 2) FolderViewModel ViewModel for mapper FrontpageViewModel ViewModel for forsiden InfoPageViewModel ViewModel for om oss -siden InjuryReportViewModel ViewModel for skaderapporter ListUsergroupViewModel ViewModel for listing av brukergrupper ListUsersViewModel ViewModel for listing av brukere MeetReportViewModel ViewModel for møterapporter ProjectFilesViewModel ViewModel for prosjektfiler ProjectUserViewModel ViewModel brukere knyttet til prosjekt ProjectViewModel ViewModel for prosjekt ProtocolViewModel ViewModel for protokoll (knyttet til møterapport) ReportViewModel ViewModel for rapporter UsergroupViewModel ViewModel for brukergrupper UserUsergroupViewModel ViewModel for brukere i brukergrupper UserViewModel ViewModel for brukere Side 62 av 185

63 Produktdokumentasjon Webapplikasjon LAGDELING Figuren til høyre viser hvilke lag vi har i løsningen. BLL (Business Logic Layer) - Logikk og metoder som kaller på databasemetoder i DAL. DAL (Data Access Layer) - DAL-laget tar seg av spørringer direkte til databasen. Model - Databasemodeller. Takst - Kontrollere, Views og ViewModels UnitTest - Automatiserte tester for kontrollerne. Figur 8: Lagdelingen Denne lagdelingen er satt opp slik at dataforespørsler fra brukergrensesnittet ikke snakker direkte med databasemetodene, men i stedet via et ekstra lag som sender informasjonen videre til databasespørringene. Figur 9: Hieriarki i lagdeling Side 63 av 185

64 Produktdokumentasjon Webapplikasjon MAPPESTRUKTUR For å få en forståelse av mappestrukturen som blir satt opp på serveren og omtalt i neste kapittel om funksjonalitet, følger her en figur av mappehierarkiet til prosjekter. I tillegg til disse har alle brukere en personlig mappe der de kan få personlig tilgang til filer. Figur 10: Mappestrukturen Side 64 av 185

65 Produktdokumentasjon Webapplikasjon FUNKSJONALITET PROGRAMFLYT Figur 11: Programflyt Aktivitetsdiagrammet over viser hovedflyten gjennom webapplikasjonen. Dette er tatt med for å gi en dypere forståelse av punktene som blir gjennomgått i de neste avsnittene og kan brukes som en referanse videre i produktrapporten. Underveis i navigasjonen rundt på nettstedet har brukere og administrator mulighet til å gå tilbake via en tilbakeknapp fra alle sidene, såfremt det ikke er erstattet med en avbrytknapp. I tillegg har vi i diagrammet unngått å ta med tilbakemeldinger i form av bekreftelser og feilmeldinger, selv om dette er implementert om det for eksempel blir lagt til eller slettet elementer fra databasen. Noe av prosjektadministrasjonen er forenklet i dette diagrammet. Side 65 av 185

66 Produktdokumentasjon Webapplikasjon ADMINISTRASJONSDEL Hovedfunksjonaliteten til nettstedet er å tilby et oppfølgingsverktøy for firmaets utbygningsprosjekter. Dette innebærer mange involverte parter, rapporter og andre filer, og administrasjonsdelen gir muligheten for å holde kontroll på dette digitalt. I avsnittene under blir det utredet hvordan vi har satt opp dette. Figur 12: Administrasjonspanelet ADMINISTRASJON AV PROSJEKTER LEGG TIL NYTT PROSJEKT Fra administratorpanelets forside kan det opprettes nye prosjekter. Dette er gjerne første steg når nye prosjekter settes i gang og i senere avsnitt blir det tatt for seg hvordan filbehandling og tildeling av rettigheter til brukere gjøres. Når nye prosjekter lages vil det også settes opp en forhåndsbestemt mappestruktur på serveren. Eksempelvis blir hovedmappen til prosjektet opprettes slik: var NewFolder = new Folder() { Title = inproject.projectname Figur 13: Opprette nytt prosjekt Side 66 av 185

67 Produktdokumentasjon Webapplikasjon }; Tilsvarende legges det automatisk til 36 undermapper til prosjektet som representerer ulike kategorier og brukergrupper som vil være involverte i prosjektet. En oversikt over hele mappehierarkiet ligger i avsnittet om mappestruktur. OVERSIKT OVER PROSJEKTER Figur 14: Prosjektliste Pågående og fullførte prosjekter blir listet ut i oversikten som vist på bildet over. Herfra har administrator også mulighet til å legge til flere prosjekter, samt redigere, slette eller fullføre prosjektene i listen. Side 67 av 185

68 FILBEHANDLING, BRUKERE OG BRUKERGRUPPER I PROSJEKT Produktdokumentasjon Webapplikasjon Figur 15: Brukervalg i prosjekt Figur 16: Filvalg i prosjekt En sentral del av administrasjonsmulighetene under prosjekter er å tilegne rettigheter til brukere og brukergrupper. Nærmere bestemt vil dette si å velge hvem som skal ha tilgang til filene som ligger i mappene på serveren. På figurene til høyre ser vi disse valgmulighetene som ligger under et valgt prosjekts administratorforside. Via involverte brukere kan brukere legges inn i prosjektets brukergrupper og få rettigheter til filer via gruppen, eller få personlige rettigheter til filer slik at de kan aksesseres gjennom brukerens personlige mappe. Sistnevnte eksempel er vist på figuren under der en bruker som allerede har blitt lagt til i prosjektet vises i en dropdown-liste og gis tilgang til filen til venstre. Figur 17: TIldeling av filrettingheter Side 68 av 185

69 Produktdokumentasjon Webapplikasjon RAPPORTER Figur 18: Rapporteringsmeny Via prosjektmenyen kan administrator legge inn rapporter tilhørende prosjektet. Rapporter er sammen med filbehandling hovedfunksjonaliteten på siden, da alle rapporter nå kan lagres digitalt i stedet for på papir, men med muligheten til utprinting i fint format. Figur 19: Liste over møterapporter Figuren over viser hvordan rapporter listes ut innenfor et prosjekt etter de har blitt opprettet via et standard utfyllingsskjema med diverse valg. Denne listingen er lik for møtereferat, skaderapport og tilstands-/fremdriftsrapport, med valg om å redigere, slette, laste opp bilde eller vise rapporten i printformat. Side 69 av 185

70 Produktdokumentasjon Webapplikasjon Figur 20: Liste over avviksskjemaer Avviksskjemaene er forskjellige fra de øvrige da det finnes tre deler av dem. Fra oversikten over disse skjemaene under gitt prosjekt har man mulighet til å velge å behandle avviket eller avslutte det, der begge er rapporter med skjema som må utfylles. Velger man å redigere eller printe dette får man med alle delene sammen. Figur 21: Print av skaderapport Side 70 av 185

71 Produktdokumentasjon Webapplikasjon Her følger et bilde som viser hvordan en skaderapport blir seende ut i printformat. Det vises i tillegg en topptekst med dato og Vis skaderapport Takst og Prosjektkontroll AS. ADMINISTRASJON AV DEN OFFENTLIGE DELEN (CONTENT MANAGEMENT SYSTEM) Administratorer kan endre tekst og legge til bilder i bildekarusellen på forsiden eller på Om oss -siden. Dette gjøres via enkle tekstbokser og en lik filopplastningsmetode som det er andre steder på siden. Figur 22: Nettsidekontroll (CMS) ADMINISTRASJON AV BRUKERE LEGGE TIL, ENDRE OG SLETTE Brukere kan som nevnt i forrige avsnitt bli opprettet og koblet direkte til prosjekter, men det finnes også en mulighet for å legge dem til uten knytninger til prosjekter. Dette gjøres via skjemaer likt som ved opprettelse av prosjekt. Disse brukerne vil være i personer som jobber under prosjekter for arbeidsgiver og kan senere bli gitt tilgang for å laste opp filer i sin personlige mappe eller prosjektmapper. Side 71 av 185

72 Produktdokumentasjon Webapplikasjon Det er kun administrator som har mulighet til å opprette brukere på nettstedet og gi innloggingsinformasjonen videre til de aktuelle personene. BRUKERGRUPPER I tillegg til de automatisk genererte brukergruppene som blir lagt til ved prosjektopprettelser kan administrator legge til egendefinerte grupper. Disse kan som alle andre grupper bli tilegnet rettigheter for å se diverse filer og dokumenter på serveren. DATABASELOGG Ettersom brukere har muligheten til å laste opp filer og det kan bli opprettet flere administratorer, er det lagt til en databaselogg. Her kan administrator se hva som er blitt gjort på databasen. Det listes også ut hvilken bruker som har gjort endringer og når dette skjedde. Side 72 av 185

73 Produktdokumentasjon Webapplikasjon BRUKERDEL Figur 23: Brukers side FILBEHANDLING PROSJEKTFILER Brukere kan bli satt på en brukergruppe i et prosjekt, som for eksempel kunder. Når brukeren logger inn vil han kunne se en liste av alle prosjektene som brukeren er lagt til i, og her vil all informasjon brukeren trenger om et prosjekt ligge. Brukeren kan trykke seg inn på et prosjekt og her vil alle filer og dokumenter brukeren eller dens brukergruppe har Side 73 av 185

74 Produktdokumentasjon Webapplikasjon tilgang til ligge. Filene vil kunne bli lastet ned av brukeren ved å trykke på dem. PERSONLIGE FILER Alle brukere har en personlig mappe på nettsiden som kun er synlig for brukeren og administrator. Dette vil for eksempel være kontrakten til en snekker i et firma som administrator har lastet opp til brukeren. Her kan også brukere laste opp egne filer som kan være relevante til prosjekter eller andre ting som administrator kan se på eller laste ned. OFFENTLIG DEL I tillegg til grensesnitt for brukere på nettstedet er det mulig for utenforstående å finne generell informasjon om firmaet på forsiden og under Om oss. Dette er som nevnt informasjon som kan legges til, endres og slettes av nettstedets administrator. FORSIDE Forsiden til nettstedet er laget for å markedsføre prosjekter som oppdragsgiver arbeider med. Her er det brukt JavaScript som går igjennom alle bilder som administrator har lastet opp til nettsiden og viser bildene i en bildekarusell. Utenforstående personer som besøker nettsiden kan da få en innsikt i aktuelle prosjekter med tekst og bilde. INFORMASJONSSIDE På denne siden vil det vises en overskrift, en tekst og et bilde som administrator har lagt inn. Teksten vil være generell informasjon om firmaet og litt om firmaets erfaring. Det vil også finnes kontaktinformasjon til firmaet. Side 74 av 185

75 Produktdokumentasjon Webapplikasjon TILBAKEMELDINGER MODALER Når noe skal slettes permanent fra nettstedet vil det komme opp bekreftelsesvinduer i form av modaler som vist på figuren under. Dette er lagt til for å forhindre at administrator tar forhastede beslutninger eller trykker slettknappen ved en feil. Figur 24: Bekreftelsesmodal for sletting TOASTS Ved innlegging, endring, sletting og liknende vil det bli vist toasts øverst til høyre med en passende melding. I tilfellet med sletting vil dette komme fram som en bekreftelse på at handlingen er utført etter det er bekreftet i modalvinduet. Figur 25: Toast-notifikasjoner Side 75 av 185

76 Produktdokumentasjon Webapplikasjon Dette blir gjort med JavaScripts notifikasjonsbibliotek toaster. Kodesnutten under viser hvordan en slik melding ser ut ved opprettelse av en ny mappe. <script type="text/javascript"> $(document).ready(function () { if ('@ViewBag.message' == "Added") { kket!") } }); </script> Command: toastr["success"]("mappen ble lagt til", "Velly toastr.options = { "closebutton": false, "debug": false, "newestontop": false, "progressbar": false, "positionclass": "toast-top-right", "preventduplicates": false, "onclick": null, "showduration": "300", "hideduration": "1000", "timeout": "5000", "extendedtimeout": "1000", "showeasing": "swing", "hideeasing": "linear", "showmethod": "fadein", "hidemethod": "fadeout" } DESIGN FARGEBRUK Designet på nettsiden er hovedsakelig satt opp ved bruk av enkle farger og knapper etter forespørsel fra oppdragsgiver. Bakgrunnsfargen på alle undersider er lys grå, da kontrasten mot sort tekst passer bra. Side 76 av 185

77 Produktdokumentasjon Webapplikasjon Knappene er gitt farger etter hva som er mest naturlig. Legg til -knappene er grønne, Slett -knappene er røde og Tilbake -knappene er blå. Disse fargene er konsistent brukt på alle undersider og forenkler brukeropplevelsen. Bekreftelsestoastene (toaster) har også farge som tilsvarer handlingen som er blitt utført. Etter noe har blitt slettet, eller når noe har gått feil, altså generelt negativt ladde tilbakemeldinger, er toasten rød. Om noe blir lagt til og liknende vil toastmeldingen være på grønn bakgrunn. BOOTSTRAP For generelt sideoppsett har vi brukt Bootstrap. Bootstrap er et front-end rammeverk som inneholder html- og css-baserte designtemplates. Bruk av dette tillater oss til å velge mellom en rekke ferdigdesignede komponenter som kan plasseres hvor vi måtte ønske på siden. Hovedkonseptet med boostrap når det gjelder nettsideoppsett er å dele det opp i rader og kolonner. Dette tilrettelegger for enkel plassering av elementer der man skulle ønske. <div class="row"> <div class="col-xs-10"> FEILHÅNDTERING I dette delkapitlet forklares det hvordan feilhåndtering og tilbakemeldinger gjennomføres på nettløsningen, for eksempel at en person prøver å aksessere sider som han/hun ikke har tilgang til, eller ved registrering av nye elementer og det er skrevet feil på dataene som skal inn i databasen. TRY, CATCH Vi kjører "try, catch" formler på nettstedet som skal ta imot om noe ikke gikk som forventet ved sending av informasjon eller tilgang til sider. I "catch" delen vil vi sende med feilmeldingen til "TempDate" som lagrer feilmeldingen slik at det kan vises på en ny side, og brukeren kan få vite hva som gikk galt. Ved for eksempel at en bruker prøver å aksessere en administrator side vil han/hun bli sendt til en side som forteller at en administrator ikke er Side 77 av 185

78 Produktdokumentasjon Webapplikasjon logget inn, og får ikke sett denne siden. try { return View(); } catch (Exception error){ TempData["Error"] = "Exception: " + error.tostring(); return RedirectToAction("Error"); } Denne feilhåndteringen er definert over alle funksjonene i kontrolleren, og det brukes andre feilmeldinger ut ifra hvilke funksjoner som kjøres. REGEX Regex gjør at informasjon som lagres inn på nettstedet ikke blir fylt ut med feil informasjon, for eksempel at et telefonnummer ikke blir lagret med bokstaver, eller med flere tall enn åtte. Nettstedet bruker regex gjennom "viewmodels" som brukes på alt av oppretting og endring av informasjon. (For å få en bedre innsikt i dette se brent cd av webapplikasjonen) [ Address(ErrorMessage = "Ugyldig e-postadresse")] Når en administrator skal registrere en ny bruker, er administratoren nødt til å benytte en epost adresse som brukernavn. Dette håndteres av en "viewmodel" som bruker "regex" slik at nettstedet vet hvilke kombinasjoner av ord og tall er lovlig på det gitte feltet, som vist på kodelinjen over. Hvis en ugyldig epost adresse er oppgitt, vil administratoren få et notat under epostadressen om at epostadressen er ugyldig. Ved registrering av passord er det lagt til at passordet må være komplekst. Passordet må inneholde minimum fire tegn, derav det må være minst ett tall og passordet kan kun være 15 tegn langt. Dette gjøres med kodelinjen under. Eksempel med passord innskrevet uten tall. Side 78 av 185

79 Produktdokumentasjon Webapplikasjon Z]).{4,15}$", ErrorMessage = "Innskrevet passord samsvarer ikke med kriteri ene!")] ENHETSTESTING (UNIT-TESTING) I løsningen er det implementert flere kontrollertester som kan brukes dersom det er ønske om å endre eller videreutvikle noe av koden. Her kan det relativt enkelt endres og sjekkes om kontrollermetoden fortsatt returnerer riktig view eller gir riktig redirect. Utvikling av slike automatiserte tester er kjent for å ta en del tid og virke unødvendig, men i senere perioder i utviklingsprosessen kan det være mye ressurser å spare ved å ha disse på plass. Vi valgte å ta med utvalgte tester fra AdminController og ReportController i vår løsning. Stort sett tar disse testene for seg sjekking av hvilke views og redirects utvalgte kontroller-metoder skal returnere etter objekter enten blir listet ut eller lagt til. Som vist på figuren ligger disse under UnitTestprosjektet i løsningen. Figur 26: UnitTest-prosjektet SIKKERHET HASHING AV PASSORD Produktet består i stor grad av lagring av firmaets private dokumenter og filer som kun kan aksesseres av administratorbrukere. I tillegg har personer som har fått opprettet en bruker for seg mulighet til å se dokumenter og filer der administrator har gitt dem rettigheter til det. I denne sammenheng er det viktig med sikkerhet og en av de åpenbare måtene for å oppnå dette er hashing av passord. Under følger metoden vi bruker for å gjøre dette med en SHA512-algoritme. Side 79 av 185

80 Produktdokumentasjon Webapplikasjon private static string makehash(string inpassword) { byte[] indata, outdata; var algorithm = System.Security.Cryptography.SHA512.Create(); indata = System.Text.Encoding.Default.GetBytes(inPassword); outdata = algorithm.computehash(indata); return System.Text.Encoding.Default.GetString(outData); } Ved bruk av denne metoden ved opprettelse av en bruker eller administrator vil passordet som blir skrevet inn kryptert og lagret som en uforståelig rekke tall/tegn/bokstaver i databasen. SESSIONS De fleste sidene på nettstedet krever administratortilgang eller brukertilgang. For å kontrollere denne tilgangen bruker vi sessions. Ved login gjør vi dette slik: [HttpPost] public ActionResult Login(Admin inadmin, User inuser){ if (ModelState.IsValid){ var dbadmin = new AdminBLL(); var dbuser = new UserBLL(); var AdminId = dbadmin.isadmin(inadmin); var UserId = dbuser.isuser(inuser); if (AdminId > 0){ Session["LoggedInAdmin"] = true; Session["LoggedInUser"] = false; Session["userId"] = AdminId; ViewBag.Innlogget = true; return RedirectToAction("Index", "Admin"); } else if (UserId > 0){ Session["LoggedInUser"] = true; Session["LoggedInAdmin"] = false; Session["userId"] = UserId; ViewBag.Innlogget = true; Side 80 av 185

81 Produktdokumentasjon Webapplikasjon return RedirectToAction("UserIndex", "User", new { id = UserId }); } else{ Session["LoggedInAdmin"] = false; Session["LoggedInUser"] = false; ViewBag.Innlogget = false; TempData["LoginFailed"] = "Brukernavn eller passord er feil."; } } return RedirectToAction("LoginFailed", "Home"); } else{ return PartialView("Login"); } Koden over vil sette en session LoggedInAdmin om administratorer logger på eller LoggedInUser dersom en vanlig bruker logger på. Denne session brukes videre i to forskjellige metoder som kontrollerne bruker om views de skal returnere krever en viss tilgang. Kodesnuttene under viser hvordan disse metodene sjekker om de respektive sessions er satt og omdirigere til en feilmeldingsside med tekst satt i TempData dersom noe ikke stemmer. public void IsUserSessionTrue() { if (Session["LoggedInUser"] == null) { TempData["Error"] = "Du er ikke logget inn"; HttpContext.Response.Redirect(Url.Action("Error", "Admin")); } else { var IsUser = Session["LoggedInUser"]; if ((bool)isuser == false IsUser == null) { TempData["Error"] = "Du er ikke logget inn"; HttpContext.Response.Redirect(Url.Action("Error", "Admin " )); } } } public void IsAdminSessionTrue() Side 81 av 185

82 Produktdokumentasjon Webapplikasjon { if (Session["LoggedInAdmin"] == null) { TempData["Error"] = "Du er ikke logget inn"; HttpContext.Response.Redirect(Url.Action("Error", "Admin")); } else { var IsAdmin = Session["LoggedInAdmin"]; if ((bool)isadmin == false IsAdmin == null) { TempData["Error"] = "Du er ikke logget inn"; HttpContext.Response.Redirect(Url.Action("Error", "Admin " )); } } } VIDEREUTVIKLING AV PRODUKTET Webapplikasjonen vår er finjustert for å tilfredsstille vår oppdragsgivers behov. Dette er merkbart ved for eksempel prosjektopprettelser, da det opprettes et bestemt antall brukergrupper og mapper med forhåndsbestemte navn. Ved en eventuell videreutvikling er det mulig å endre dette oppsettet i programkoden, slik at den også kan brukes i andre type prosjekter. Om webapplikasjonen skal gjøres om for å treffe en større målgruppe, vil vi være nødt til å sette opp en installasjonsside som blant annet gir brukeren valg om hvilken server som skal brukes som lagringsplass til nettstedet. Ettersom vårt prosjekt er satt opp slik at systembrukeren både har lagringsplass og webapplikasjon på samme server, vil det ikke fungere dersom det er ønske om å ha lagringsplass lokalt på egen server eller på en annen server enn webapplikasjonen. Det er gjort slik i vårt prosjekt da oppdragsgiver ikke hadde ønske om vedlikehold av en server på egenhånd. Side 82 av 185

83 Side 83 av 185

84 Produktdokumentasjon Android-applikasjon PRODUKTDOKUMENTASJON ANDROID-APPLIKASJON FORORD Produktet vi har utviklet er et rapporteringsverktøy for oppdragsgiver. Kapitlene i denne rapporten tar for seg hvordan løsningen er bygd opp kodemessig, og produktets funksjonalitet. Før denne rapporten leses vil det være fordelaktig å ha lest innledningen og presentasjonen av oppgaven. Side 84 av 185

85 Produktdokumentasjon Android-applikasjon INNHOLD Forord Innhold Database- og Kodestruktur Er-diagram Aktivitet, adapter og klasser Adapter og klasser: Andre Klasser Funksjonalitet Programflyt Tilbakemeldinger Feilhåndtering Nettverkstilkobling Toast Nettverksspørringer Tråder AsyncTask Design (layout) TextView og EditText Knapper ListView Vis Innhold Hovedmeny Rapport Se rapport/skjema Opprette rapport Behandle/Lukke avviksrapport opplastning av rapporter fra php til databasen: Opplastning av flere checkboxer og verdier Side 85 av 185

86 Produktdokumentasjon Android-applikasjon Filbehandling Bildeopplastning Design Bildebruk Farger Feilsøking Verktøy Runtime-feil Breakpoint og Logcat Viderutvikling Side 86 av 185

87 Produktdokumentasjon Android-applikasjon DATABASE- OG KODESTRUKTUR ER-DIAGRAM Figur 27: ER-modell AKTIVITET, ADAPTER OG KLASSER Applikasjonen inneholder mange aktiviteter. En aktivitet er en av applikasjonens komponenter, og er det som skaper skjermbildet som brukeren kan interagere med. Aktivitetene arver alle egenskapene til Activity-klassen. Alle aktivitetene er koblet til en layout, som er ansvarlig for brukergrensesnittet. Side 87 av 185

88 Produktdokumentasjon Android-applikasjon ADAPTER OG KLASSER: Adapter ProsjektAdapter AvviksAdapter MoteAdapter SkadeAdapter TilstandAdapter Klasser ProsjektKlasse AvviksKlasse MoteKlasse SkadeKlasse TilstandKlasse Applikasjonen har fem egendefinerte adaptere og objektklasser. Klassen blir opprettet når dataene mottas. Koden ovenfor illustrerer hvordan man mottar dataene fra et JSON, oppretter en objektklasse og legger informasjon inn i en liste. Adapteret blir brukt til å hente ut listene og sette de inn i et ListView. For å koble en ArrayList og et ListView sammen: Side 88 av 185

89 Produktdokumentasjon Android-applikasjon Aktiviteter MainSplashScreen RapportMeny AvvikMeny NyAvvikRapport BehandleAvvik LukkingAvvik SeAvvik MoteMeny NyMoteRef SeMote SkadeUlykkeMeny SkaderUlykker Skaderulykkerdel2 SeSkaderapport TilstandFremdriftMeny TilstandRapportNy setilstand Beskrivelse Første bilde når applikasjonen åpner. Bilde av logo som varer i 5 sekunder. Fire knapper. Bruker velger rapport Listes ut alle avviksrapportene i ListView For innskriving og opplasting av avviksskjema For innskriving og opplasting behandlingsskjemaet til avvik For innskriving og opplasting av lukkingsskjemaet til avvik For å se de innskrivende skjemaet og muligheten for å laste opp bilde Listes ut alle møterapportene i ListView For innskriving og opplasting av møtereferat For å se de innskrivende referatet og mulighet for å laste opp bilde Listes ut alle skaderapportene i Listview For innskriving av skade del1 For innskriving av skade del2, og opplasting av del1 og del2. For å se innlagte rapporter og mulighet for å laste opp bilde Listes ut alle tilstandsrapportene i ListView For innskriving og opplasting av tilstandsrapport For å se de innskrivende rapportene og muligheten for å laste opp bilde ANDRE KLASSER Klasser ConnectionDetector AndroidMultiPartEntity Config JSONParser Beskrivelse Hjelpeklasse for å sjekke om applikasjonen har internett. Hjelpeklasse for progressbar ved opplastning av bilde Hjelpeklasse for nettstedlinken ved opplastning av bilde Hjelpeklasse for http Client, oppkobling mot PHP Side 89 av 185

90 Produktdokumentasjon Android-applikasjon FUNKSJONALITET PROGRAMFLYT Figur 28: Programflyt Aktivitetsdiagrammet viser hoved flyten gjennom applikasjonen. Dette er tatt med for å gi en dypere forståelse av punktene som blir gjennomgått i de neste avsnittene, og brukes som referanse i videre i produktrapporten. Side 90 av 185

91 Produktdokumentasjon Android-applikasjon TILBAKEMELDINGER FEILHÅNDTERING Applikasjonen bruker try-catch-feilhåndtering. Hvis et exception blir kastet, vil catch-blokken bli eksekvert, og brukeren vil motta en feilmelding. Applikasjonen bruker hovedsaklig to typer unntak for forskjellige feilsituasjoner: IOException: Kastes dersom det er feil i input og output. JSONException: Kastes der det er feil i JSON. I Feilsituasjoner vil applikasjonen sende ut en Alertdialog, kalt showwrongalert. Side 91 av 185

92 Produktdokumentasjon Android-applikasjon NETTVERKSTILKOBLING Applikasjonen sjekker om mobilen er tilkoblet internett opp mot klassen ConnectionDetector, er man oppkoblet til internett så går man videre i applikasjonen. Om ikke så vil applikasjonen sende ut en alertdialog med riktig melding. I ConnectionDetector klassen bruker vi koden: ConnectivityManager connectivity = (ConnectivityManager) _context.getsystemservice(context.connectivity_service); Deretter setter vi inn en if som sjekke om connectivity ikke er null. Om den er null så returnerer det false. Det betyr at applikasjonen ikke er koblet til internett. Feilmeldingen som kommer om man ikke er tilkoblet internett blir sendt til alertdialogboksen kalt showwrongalert med passende melding. Dette blir gjort før man bruker nettverksspørringer. TOAST Ved innleggelse vil det komme en bekreftelse om utførelsen ble fullført eller ikke. Her kommer det en passende melding til brukeren. Eksempel: Innleggelsen av rapport er fullført. NETTVERKSSPØRRINGER All respons er av typen InputStream før det blir parset til JSON. Alle nettverksspørringer blir kjørt i AsyncTask. Med unntak av uthenting av verdier til adapter og klasser, går alle nettverksspørringer mot tjener via JSONParser. Dette er en klasse som inneholder metoden makehttprequest, og blir kalt slik: JSONObject json = jsonparser.makehttprequest(url, POST, parms); Side 92 av 185

93 Produktdokumentasjon Android-applikasjon TRÅDER Applikasjonen blir tildelt en prosess og en tråd av Android-systemet. Denne tråden heter IUtråden. IU-tråden har ansvar for hele applikasjonen, og oppretter alle applikasjonens komponenter (aktiviteter, servicer osv.). IU-tråden har en sikkerhetsfunksjon som går ut på å hindre applikasjonen i å fryse i mer enn fem sekunder. For å forhindre dette, er det nødvendig å kjøre ressurskrevende prosesser i egne tråder. ASYNCTASK Android tilbyr en trådfunksjon for å kunne kjøre asynkrone tråder ved siden av hoved tråden. AsyncTask har følgende metoder som applikasjonen bruker: OnPreExecute DoInBackground OnCancelled OnPostExecute Side 93 av 185

94 Produktdokumentasjon Android-applikasjon OnPreExecute viser en loading-komponenet, for å illustrere at det arbeides i applikasjonens kulisser. I DoInBackground utføres selve oppgaven, i dette tilfellet hente data fra webserver. I OnPostExecute gjøres endringer av TextViews, og informasjonen vises på skjermen. OnCancelled avbryter DoInBackground-metoden. Enhver spørring mot tjener oppretter en egen AsyncTask. Oppsettet for AsyncTaskene blir brukt i hele applikasjonen ved spørring til tjener. DESIGN (LAYOUT) Layoutene i aktivitetene definerer den visuelle strukturen for brukergrensesnittet. Dette blir gjort i aktivitetens oncreate-metode ved hjelp av koden: setcontentview(r.id.activity_main); Hyppigst brukt er RelativeLayout. Det har også blitt brukt LinearLayout der det er behov for flere knapper ved siden av hverandre, da denne tilbyr enklere oppsett for slike elementer. TEXTVIEW OG EDITTEXT Applikasjonen bruker to typer EditText. Den ene har vi ikke har gjort noe med og går på input av tekst på en linje, som for eksempel navn, dato og tall. Den andre EditTexten har en bakgrunn som er satt i mappen drawable, denne type blir brukt ved edittext med flere linjer. Hva slags type input blir bestemt i layouten til edittext. Den defineres med android:inputtype= number. Om det skal være tekst, byttes number ut med text etc. Side 94 av 185

95 Produktdokumentasjon Android-applikasjon Applikasjonen har to typer TextView. Den ene går på input av tekst på en linje som navn, dato og tall, og den andre er med bakgrunn definert i mappen drawable. Teksten i TextViewene er tekst som programmereren av applikasjonen har lagt inn, eller tekst som hentes ut fra databasen. Edittext.xml filen som er i mappen drawble ser slik ut: TextView og EditText sin layout blir bestemt av en android:background, som peker til edittext.xml filen. EditText og TextView vil se slik ut når den har satt sin bakgrunn til drawtable-edittext.xml. Figur 29: Bakgrunn til drawable edittext. Side 95 av 185

96 Produktdokumentasjon Android-applikasjon KNAPPER Figur 30: Rapportmeny Layouten til knappene er bestemt på samme måte som EditText og TextViewene. I layouten blir koden android:background lagt til i knapp.xml som ligger i drawable. Knapp.xml vil eksempelvis se slik ut: Side 96 av 185

97 Produktdokumentasjon Android-applikasjon LISTVIEW ListViewet har standard layout som på alle ListViews. Med denne layouten så vil alle ListViewene ha en grå/hvit farge med svart tekst. VIS INNHOLD Ved oppstart av applikasjonen vil det bli vist et splashscreen av ikonet til oppdraggivers firma. Etter dette vil en liste av alle prosjekter som ligger i databasen vises. Figur 31: Prosjektliste Side 97 av 185

98 Produktdokumentasjon Android-applikasjon For å vise innholdet i databasen blir det brukt, som tidligere nevnt, Asynctask. Denne kobler seg til databasen via PHP. Verdiene blir sendt via JSON. Her er en noe forkortet utgave av typiske data: { id : 1, ProsjektName : Grøndahls vei 10, Opprettes av : Ketil Johansen }, { id : 2, ProsjektName : Aker Brygge Bygg, Opprettes av : Ketil } Responsen inneholder informasjon for alle prosjektene. Med id-nummeret kan brukeren navigere seg videre til Menyen til de enkelte prosjektene. For å vite hvilket prosjekt brukeren har klikket seg innpå, så lagres id og prosjektnavnet i SharedPreference. Prosjektnavnet legges ved for en raskere opplastning av bilder som vi kommer tilbake til senere i produktrapporten. HOVEDMENY I applikasjonens hovedmeny ligger det fire knapper som har blitt gitt en egen layout, som er beskrevet i knapper tidligere i produktrapporten. De fire knappene er linket til fire forskjellige aktiviteter. RAPPORT Side 98 av 185

99 Produktdokumentasjon Android-applikasjon For å finne riktig rapport til riktig prosjekt ligger prosjektet sin id sammen i databasemodell til rapportene. I actionbaren til disse fire aktivitetene ligger det en + -knapp som gir brukeren mulighet til å opprette en ny rapport. Til venstre for logoen i Actionbaren ligger det en pil til venstre. Denne pilen indikerer at man kan gå tilbake til den forrige aktiviteten. Har man klikket på en av rapportene, utføres denne koden: Intent intent = new Intent(ProjectMeny.this, RapportMeny.class); startactivity(intent); Siden visningen og opprettelsen av en rapport har det samme oppsettet, tar vi for oss én rapport for å vise framgangsmåten for å laste opp rapporten og for å se den. Avviksrapporten blir beskrevet, siden dette er den mest avanserte rapporten. Vi kommer også til å gå gjennom de rapportene som er noe annerledes. I alle rapportene er det lagt inn scrollbar i hele aktiviteten og i EditText- og TextView-feltene der det fort kan bli mye tekst. Koden for å legge til scrollbar på EditText: For TextView-feltene må vi først finne ScrollViewet i hele Layouten: Side 99 av 185

100 Produktdokumentasjon Android-applikasjon Når brukeren prøver og scrolle utenfor TextView-feltet så setter den alle de andre scroll TextViewene til å være false. For å scrolle i TextView-Feltene må vi opprette denne metoden til hvert TextView. Klikker man på en av de fire knappene i rapportmenyen vises en liste med rapportene som er lagt til i databasen. Her er alle layoutene like, og den eneste forskjellen er forskjellig innhold i TextViewet over lista. For å laste opp en rapport kan brukeren gjøre det via applikasjonen eller via hjemmesiden. Det som skjer når en rapport skal lastes inn, er at det startes en metoden som oppretter en Arraylist og et adapter som finner ListView og kobler sammen ListView og adapteret. For å få opp alle rapportene som ligger i databasen så kjører applikasjonen en AsyncTask. httpclient=new DefaultHttpClient(); httppost= new HttpPost(URL); List<NameValuePair> namevaluepairs = new ArrayList<NameValuePair>(1); namevaluepairs.add(new BasicNameValuePair("idprosjekt", idnrprosjekt)); httppost.setentity(new UrlEncodedFormEntity(nameValuePairs)); response=httpclient.execute(httppost); HttpEntity entity = response.getentity(); is = entity.getcontent(); Side 100 av 185

101 Produktdokumentasjon Android-applikasjon I doinbackground-metoden utføres nettverksspørringene. Disse spørringene sender med prosjektets id-nummer via en php-fil. Får man ikke noe tilbake vil det komme en alert-dialog med passende tilbakemelding. Finnes det noe i databasen, vil JSON-response-objektet kjøre gjennom en StringBuilder. StringBuilderen konverterer JSON om til string og sender stringen videre til onpostexecute idet doinbackground er ferdig eksekvert: JSONArray jarray =new JSONArray(result); for(int i=0;i<jarray.length();i++){ JSONObject json_data = jarray.getjsonobject(i); System.out.println(json_data.getInt("ID")); idnr.add(json_data.getint("id")); if(i == 0) { if(!list.isempty()) List.clear(); } AvviksKlasse av = new AvviksKlasse(json_data.getString("Deviationtype"), json_data.getstring("deviationnr"), json_data.getstring("name"), json_data.getstring("date")); List.add(av); } Her oppretter man Avviksklasse ut i fra de verdiene vi får hentet underveis i for-løkken. Etter opprettelsen av Avviksklassen, legges den inn i en Arraylist. Deretter blir det sendt en NotifyDataSetChanged fra adapteret som gir beskjed om at data har blitt endret og kan oppdateres. Arrayet med id-nummerene lagrer id til hver enkelt rapport, slik at vi kan hente ut riktig rapport senere via listviewet. Dette kommer vi tilbake til. public AvviksKlasse(String atype, String anr, String anavn, String adato) { super(); this.atype = atype; this.anr = anr; this.anavn = anavn; this.adato = adato; } Side 101 av 185

102 Produktdokumentasjon Android-applikasjon Når det opprettes et nytt avvikobjekt må det følge med riktig parameter. I dette tilfellet er det fire parametre av typen string. public View getview(int position, View convertview, ViewGroup parent) { convertview = ( RelativeLayout ) inflater.inflate( resource, null ); AvviksKlasse ListView = getitem( position ); } TextView atype = (TextView) convertview.findviewbyid(r.id.atype); atype.settext(listview.getatype()); Adapter arver ArrayAdapter<AvviksKlasse>, for å få tak egenskapene til denne klassen. Dette gjør vi ved hjelp av getitem(position). Adapteret finner deretter riktig TextView og plasserer verdiene på riktig sted i ListViewet ved hjelp av get metodene som ligger i klassen. int idd = 0; } for(int i = 0; i < idnr.size(); i++) { (i == position) { idd = idnr.get(i); editor.putint("idrapport", idd).commit(); } I ListViewet har brukeren mulighet til å klikke på en gitt rapport for å få all informasjonen fra rapporten. For å løse dette har vi laget en liste som kalles idnr. Her blir id-nummeret til hver rapport lagt inn etter hvert som de blir opprettet i en objektklasse. Metoden onitemclicklistener er implementert,og brukes når brukeren klikker på en av rapportene som ligger i listviewet. Da vil applikasjonen gå igjennom idnr-listen i en for-løkke for å finne Side 102 av 185

103 Produktdokumentasjon Android-applikasjon riktig id til den gitte posisjonen som brukeren har klikket på i ListViewet. Deretter vil iden bli lagret i SharedPreferences og brukeren vil bli sendt videre til aktiviteten SeAvvik, som viser hele rapporten. SE RAPPORT/SKJEMA For å kunne se rapporten trengs id-nummeret som er lagret i SharedPreferences. Her kjøres AsyncTask, og i doinbackground sendes id-nummeret med til JSONParser for deretter å sende det til PHP-filen. JSONResponse-arrayet blir konventert til et JSONObjekt. Deretter går JSONObjektet videre til onpostexecute-metoden. Her får man hente ut informasjonen man trenger med JSONObjektet som er sendt som parameter. Dette er en effektiv og kjapp måte å hente ut informasjon på. TextView og andre visuelle komponenter blir oppdatert fra onpostexecute. OPPRETTE RAPPORT Ved å klikke på + tegnet i actionbaren i rapportmenyen, vil brukeren komme til denne siden. Her ser man edittext-feltene som er beskrevet tidligere i produktrapporten. De fire første feltene er laget i en TableLayout, etterfulgt av en TableRow. Der har man et TextView og en EditText i bredden. De større EditTextene er ikke i TableLayout. Disse justerer seg etter TableLayout som ligger over seg. Om teksten blir en linje mer så justeres det en linje ned. Generelt i alle rapporter så må enkelte EditText-feltene være utfylt, avhengig hva slags rapport brukeren er fyller ut. Opplastningen skjer ved å trykke på lagringsiconet i actionbaren. Det første som skjer ved at man klikker på lagringsikonet oppe i actionbaren, er at applikasjonen sjekker input verdiene stemmer overs med en metode som sjekker om verdien inneholder noen ord. Lengden på verdien kan ikke være 0. Det samme gjelder nummer, men her sjekker den kun lengden siden brukeren ikke har noe mulighet for å legge inn bokstaver eller andre tegn. Side 103 av 185

104 Produktdokumentasjon Android-applikasjon Det man trenger for å laste opp en rapport er ferdig utfylte EditText- felter, prosjekt-id og linken til nettsiden der php fila ligger. For å få tak i inneholdet som er skrevet inn i inputfeltene, lages det en ny string variabel som henter og lagrer teksten ved hjelp av navnet til EditText sin gettext().tostring(). namevaluepairs.add(new BasicNameValuePair("Navn", Navn)); Den nye string variabelen lagres så i en List<NameValuePair>. Navnet som står i første stringen Navn er nødt til å samsvare med det som ligger i PHP-filen. Prosjekt-id ligger allerede i SharedPreference, så den hentes direkte derfra og legges til i listen namevaluepair på samme måte som er gjort med Navn. Deretter blir listen sendt videre til PHP-linken via klassen JSONParser. Her blir det bestemt om vi skal bruke POST/GET. BEHANDLE/LUKKE AVVIKSRAPPORT Forskjellen på Avviks rapportene og de tre andre rapportene er at avviksrapporten har flere deler. En del2 som er å behandle avviket og en del 3 som er å avslutte avviket. Denne har vi løst på en effektiv måte ved å lagre id-nummeret til del 1 av rapporten i modellen til del 2 og 3. Med dette så kan man raskt finne ut om avviket er eller ikke er behandlet/lukket. Dette gjøres når avviksrapporten skal vises, her gjøres det en spørring mot de to modellene, Treatment(Behandle) og Closure(Lukket), for å se om id-nummeret til del 1 ligger der. Er rapporten behandlet/lukket, får brukeren tilbake to id er, én id fra Treatment og én fra Closure. Er kun del 1 fylt ut, må man åpne del 1 og klikke på knappen for behandling av avviket(del 2). I den nye aktiviteten (behandlingen) vil brukeren kunne se alt som er lagt inn tidligere ved hjelp av nettverksspørring og bruk av AsyncTask. if(json.getstring(tag_id).equals(json.getstring(tag_idbehandlet))) //Avviket er behandlet btnshowbehandle.setvisibility(view.visible); else //Avviket er ikke behandlet btnikkebehandling.setvisibility(view.visible); Alle knapper i Avviksrapport delen er satt til Gone. Det betyr at om TAG_ID, id-nummeret til del 1, er lik TAG_IDBEHANDLET så er det kun mulig å se den ferdig utfylte del 2. Er idnummerene ulike må man fylle ut del 2 først. Samme metode brukes for del 3. Side 104 av 185

105 Produktdokumentasjon Android-applikasjon OPPLASTNING AV RAPPORTER FRA PHP TIL DATABASEN: Dataene som mottas av applikasjon gjøres ved: $navn = $_POST[ Navn ]. Når alle dataene er lagret i egne variabler så kopler PHP filen til serveren ved hjelp av koden: $conn = sqlsrv_connect( $servername, $connectioninfo); Variabelen ServerName er navnet på serveren, ConnectionInfo inneholder brukernavn, passord og databasenavn. Får man ikke kontakt med databasen vil det sendes en tilbakemelding til applikasjonen, og opplastningen avsluttes. Når alle verdiene er hentet fra applikasjonen med $_POST og lagret i variabler, vil PHP fila gå videre og sette verdiene inn i databasen. Om innleggingen feilet vil json_output[ success ] være 0, om opplastningen er fullført vil den være 1. OPPLASTNING AV FLERE CHECKBOXER OG VERDIER Flere rapporter og skjemaer inneholder flere checkboxer der brukeren kan fylle inn tekst ved siden av. Bildet viser en del av møtereferatet, der en TableRow er lagt inn i en TableLayout. Her kommer vi til å gå igjennom framgangsmåten for å laste opp flere lister til en database. Dette er generelt på alle rapportene/møtene og skjemaene. Side 105 av 185

106 Produktdokumentasjon Android-applikasjon Figur 32: Oppmøte-skjema For å se om personen har vært tilstede, har vi brukt en chechbox der vi får ut en verdi true/false. For input feltet Person, har vi brukt edittext. Her har brukeren mulighet å skrive opp til 500 bokstaver. Om inputverdiene i EditText-feltet er for langt vil det utvide seg vertikalt. TextView og alt annet som er under TableLayouten vil automatisk tilpasse seg tabellraden. Dette er gjort med en linje kode: For at applikasjonen skal skjønne at personen er tilstede eller ikke, må brukeren ha fylt ut noe i personfeltet. Her bruker vi en if-setning og sjekker om det står noe i feltet er utfylt. Er feltet utfylt, sjekkes det om checkboxen er markert eller ikke(true eller false). Når dette er gjort så legges tilstede i en egen liste kalt ChkboxBoolItemList, og personen i en egen liste kalt ChkBoxItemList. Antall personer legges til i ChkBoxItemsAntall, antallet blir satt ved hjelp av inkrement(++). Dette er gjort for å slippe å opprette hver enkel checkbox og personinfo når det skal bli opplastet. Side 106 av 185

107 Produktdokumentasjon Android-applikasjon I forbindelse med opplastningen så trenger man å få sendt med alle som var tilstede og ikke sammen med riktig personnavn. Her får vi brukt for chkboxitemsantall listen som vi laget. For å få dette til så er det brukt en for-løkke. For å få tak i informasjonen som ligger i de to listene, så har vi laget to stringer som er kalt chkboxperson, som inneholder person, og chxbool, som inneholder tilstede. Etterhvert som løkken går, plusses chkboxperson inneholdet som er person med 1. Så den første string parameter som skal sendes med namevaluepairs vil være person0 og det andre parameteret vil vere verdien som ligger i ChkBoxItemsList[0]. Når variabelen øker med en så vil neste namevaluepairs vere person1 og ChkBoxItemsList[1]. Antallet sendest så med til slutt. Dette blir gjort for å slippe å lage variabler, og for at php-filen skal kunne få hentet riktig variabel. PHP-filen får tak i verdien via en for-løkke. Her brukes antallpersoner som blir sendt med fra Android-applikasjonen. Tilstede og person hentes ved de verdiene den er satt til fra forløkken i applikasjonen. Side 107 av 185

108 Produktdokumentasjon Android-applikasjon Når for-løkken er ferdig så legges de inn i databasen. Det første som skjer her er at PHP-filen sjekker om antallpersoner er over 0, om antallet er over, så settes verdiene inn i databasen ved hjelp av en for-løkke. FILBEHANDLING BILDEOPPLASTNING Alle de fire rapportene skulle ha mulighet til å inneholde bilder. Brukeren har mulighet til å ta et nytt eller laste opp et bilde. Dette gjøres ved å klikke på kameraikonet i actionbaren. For å ta eller laste opp et bilde må brukeren velge en rapport som er ferdig utfylt og lastet opp fra før av, for så å laste opp et bilde. Brukeren har ikke muligheten til å laste opp flere bilder på en gang. Alternativet ble at brukeren kan laste opp ett og ett bilde av gangen. Det er laget to klasser for å få til opplastningen. Første klassen er en MainImage klasse, her velger brukeren om man vil bruke kameraet til å ta et nytt bilde eller å velge et bilde fra minnekortet på telefonen. ImageView imgpreview = (ImageView) findviewbyid(r.id.imgpreview); BitmapFactory.Options o2 = new BitmapFactory.Options(); o2.insamplesize = scale; final Bitmap bitmap = BitmapFactory.decodeFile(filePath, o2); imgpreview.setimagebitmap(bitmap); Side 108 av 185

109 Produktdokumentasjon Android-applikasjon Når et nytt bilde er tatt, må bruker velge om bildet skal brukes eller ikke. Denne aktiviteten kalles UploadActivity. Her vil brukeren få sett bildet som er tatt. Bildet blir lastet opp på serveren når brukeren trykker på opplastningsknappen i actionbaren. Når opplastningen er fullført vil filnavnet lagres i databasen. Dette gir brukeren mulighet til å kunne se bildene som er lastes opp. For å kunne se bildene gjøres det på hjemmesiden. Er alt vellykket vil brukeren få opp en alert dialog om at opplastningen er fullført. Deretter gis brukeren muligheten til å laste opp et nytt bilde eller å gå tilbake til menyen. Bildet legges i prosjektet sin Reports mappe, ved hjelp av verdien prosjektnavn som er lagret i SharedPreference. Denne ble lagret i SharedPreference når brukeren valgte et prosjekt i prosjektmenyen, som tidligere nevnt. Responsen fra PHP serveren hentes ut fra JSONObject parameteret i onpostexecute. Her får vi tak i Integer-verdien som er lagret i success-variabelen. Dette blir gjort gjennom en trycatch. Denne vil gi applikasjonen beskjed om opplastningen gikk fint. Er success = 1 ble opplastningen gjennomført. Er den 0 så har det skjedd en feil og response-meldingen applikasjonen får fra en PHP serveren vises i en alertdialog som blir vist til brukeren. Side 109 av 185

110 Produktdokumentasjon Android-applikasjon DESIGN BILDEBRUK Applikasjonen benytter seg av android sin standard holo dark tema. Istedenfor å bruke ord, så har vi valgt å bruke standardiserte glyphs fra android. Ikoner brukes istedenfor knapper, og fargen som er brukt er hvit. Alle bilde filer er gitt et passende navn som gir informasjon om hvor de blir brukt i applikasjonen. Bildene er lagret i res/drawable. FARGER Figur 33: Liste med brukte bilder Alle farger som er brukt i applikasjonen er lagret i en fil kalt colors.xml som ligger i values-folderen. Siden oppdragsgiver ville ha en enkel bruk av farger i applikasjonen har vi valgt en standard bakgrunn som er svart med hvit tekst. FEILSØKING Denne seksjonen vil beskrive teknikker og metode for å finne, utbedre og rette eventuelle feil og svakheter i kildekoder, og hvordan man skal angripe problemet. Feilsøking i Android er relativt enkelt, så lenge man bruker tid til å se igjennom og lære seg programkoden. Side 110 av 185

111 Produktdokumentasjon Android-applikasjon VERKTØY Her vil vi beskrive de forskjellige verktøyene som blir brukt for å feilsøke i applikasjonen. RUNTIME-FEIL Hvis applikasjonen stopper under kjøring av en spesifikk aktivitet, avsluttes applikasjonen brått. Slike feil blir kalt uhåndterlige exceptions. Denne typen feil gir ofte en forklarende tilbakemelding slik at programmereren kan rette på det. BREAKPOINT OG LOGCAT Breakpoint er en fin måte å finne feil på, og har blitt hyppig brukt. Med breakpoint kan man stoppe applikasjonen under utførelsen av en oppgave på et bestemt punkt. Hensikten bak dette er å kunne undersøke verdier på et gitt tidspunkt. Dette er en effektiv måte for å se om alle verdiene ligger der de skal og blir sendt riktig. Logcat er og en god måte å finne feil på, denne er vell blitt mest brukt. Hensikten med å bruke Logcat, er at man ikke trenger å stoppe utførelsen av en oppgave. Her går alt i en flyt, og man får opp verdiene til de vi trenger opp i Logcat på Eclipse. VIDERUTVIKLING Ved videreutvikling av applikasjonen vil det være gunstig med en innloggingsside ved oppstart. Hvis dette ble implementert kunne applikasjonen bli gitt til flere personer enn oppdragsgiver og det ville gjort det enklere for oppdragsgiver å holde et prosjekt oppdatert med rapporter. Applikasjonen kunne også blitt implementert ved at en administrator kunne ha sett på mappestrukturen til prosjektene, og kunne lastet ned eller sett på filene til disse mappene. Det er mulig å gjøre dette på en smarttelefon hvis man går på nettstedet, men hadde vært bedre hvis man ikke trengte å logge inn hver gang man skulle se på en fil. Side 111 av 185

112 Produktdokumentasjon Android-applikasjon Ettersom applikasjonen har vært laget for oppdragsgiver med ønske om en applikasjon med enklest mulig design. Hvis applikasjonen hadde vært tilgjengelige for flere personer ville det vært en prioritet å forbedre designet. Side 112 av 185

113 Side 113 av 185

114 Brukerveiledning BRUKERVEILEDNING FORORD I denne brukerveiledningen vil man finne manualer med steg for steg forklaringer og bilder for både webapplikasjonen og Android-applikasjonen. Vi har valgt og ikke å ta med en egen brukerveiledning for den offentlige delen av webapplikasjonen. Denne er selvforklarende og som en hvilken som helst annen hjemmeside i funksjonalitet. Webapplikasjonens brukermanual er delt opp i to deler. Den ene er for en innlogget bruker i systemet. Den andre brukermanualen er for en administrator i systemet. På Androidapplikasjonen er det en brukermanual siden denne er beregnet for en administrator og har derfor alle muligheter. Side 114 av 185

115 Brukerveiledning INNHOLD Forord Innhold Forord Nettstedskart Logget inn som Bruker Innhold Min side Last opp fil Pågående prosjekter brukerens filer Logget inn som administrator Innhold fellesknapper Kontrollpanel - Administrasjon prosjekt Alle prosjekter - Pågående og fullførte Prosjekt del Brukere filer Rapport Prosjekt del Lag nytt prosjekt Registrer nytt prosjekt bruker alle brukere legg til bruker Legg til Legg til bruker til prosjekt Side 115 av 185

116 Brukerveiledning Kontrollpanel nettsiden Forside Om oss Kontrollpanel logging Logg del logg del forord applikasjonskart Hvordan bruke applikasjonen Innhold Fellesknapper Prosjekt meny Rapport meny Rapport og skjema visning Lage nye rapporter sette dato i rapporter og skjemaer Sette inn bilder i rapporter Behandle avviksskjema Avslutt avviksskjema Side 116 av 185

117 TAKST OG PROSJEKTKONTROLL AS Brukerveiledning BRUKERMANUAL WEBAPPLIKASJON Figur 34: Forside på nettsiden Side 117 av 185

118 Brukerveiledning FORORD Dette er en brukermanual både for brukere og administratorer av webapplikasjonen til Takst og Prosjektkontroll AS. Nettstedskart ligger under vil være til stor hjelp med å holde styr på hvor du er og hvilke valg man har fra det stedet du er. Dette gjelder for både bruker og administrator. Hvis du vet hva du leter etter, ta en titt i innholdslisten under den delen av manualen som gjelder for deg, så finner du det med engang. NETTSTEDSKART Figur 35: Nettstedskart Side 118 av 185

119 Brukerveiledning LOGGET INN SOM BRUKER INNHOLD Logget inn som Bruker Innhold Min side Last opp fil Pågående prosjekter brukerens filer Side 119 av 185

120 Brukerveiledning MIN SIDE Figur 36: Brukerens hjemmeområde På figuren over ser du det bildet som møter deg etter at du som bruker har logget deg inn med brukernavn og passord. Figuren under ser du øverste delen som omhandler brukerkontoen din. Her står brukernavnet ditt tydelig slik at du vet at du er logget inn som deg, fullt navn står også på denne siden. Figur 37: Område for opplasting av filer Side 120 av 185

121 Brukerveiledning LAST OPP FIL På last opp filer, nede til venstre på figuren over, kan du laste opp filer til mappen din. Hvis du trykker på Velg filer knappen blir du sendt videre til opplastningsvinduet. På en Windows maskin vil det se omtrent som figuren under. Figur 38: Velg filer Her kan du velge en eller flere filer fra det stedet du vil laste opp fil fra og deretter trykke Åpne -knappen. Ved å gjøre det blir du sendt tilbake til Min side, det samme vil skje hvis du benytter Avbryt -knappen, men da vil ikke filen følge med. Figur 39: Last opp, bekreftelsesnotifikasjon Side 121 av 185

122 Brukerveiledning På figuren over til venstre ser du navnet på filen du har valgt og her er det neste steget og trykke på Last opp -knappen. Når du har gjort det, kommer det en melding oppe i høyre hjørne som sier at opplastningen var vellykket. Hvis du ikke har internett tilkobling for eksempel, ville det kommet en beskjed om at opplastningen mislyktes. PÅGÅENDE PROSJEKTER Figur 40: Liste over pågående prosjekter Det neste du kommer til på Min side er Pågående prosjekter som du kan se på figuren over. Her vil alle prosjektene du jobber på til enhver tid ligge. Her får du opp all den viktigste informasjonen om hvert prosjekt. Her det ikke noen valg knapper, men hvis du trykker på et prosjekt vil du bli komme inn til prosjekt mappen. Figur 41: Liste over filer i prosjektet Inne i prosjektmappen kan man se alle de filene som hører til det spesifikke prosjektet. Hvis man trykker på filnavnet som på figuren over er blått, vil filen lastes ned og du kan lagre det lokalt. Her er det en blå Tilbake -knapp slik at du alltid kan enkelt gå inn og ut av forskjellige prosjekter. Side 122 av 185

123 Brukerveiledning BRUKERENS FILER Figur 42: Brukers egen mappe, liste over brukers filer Nederst på Min side ligger det en blå arkivmappe, lik den på figuren til venstre over, med brukernavnet ditt på. Trykker du deg inn på denne kommer du inn til alle filene dine. Figuren til høyre viser filene som brukeren har lastet opp. Her ser du også datoen det ble lastet opp. Her finner du den blå Tilbake -knappen på samme faste plass som du så i pågående prosjekter. Side 123 av 185

124 Brukerveiledning LOGGET INN SOM ADMINISTRATOR I denne delen av brukermanualen som omhandler mulighetene for en administrator, er det veldig mange forskjellige knapper som er markert i teksten med understreking. Etter at en knapp er markert ved understrekingen, vil det bli beskrevet funksjonaliteten tilhørende denne rett under. INNHOLD Logget inn som administrator Innhold fellesknapper Kontrollpanel - Administrasjon prosjekt Alle prosjekter - Pågående og fullførte Prosjekt del Brukere filer Rapport Prosjekt del Lag nytt prosjekt Registrer nytt prosjekt bruker alle brukere legg til bruker Legg til Legg til bruker til prosjekt Kontrollpanel nettsiden Side 124 av 185

125 Brukerveiledning Forside Om oss Kontrollpanel logging Logg del logg del Side 125 av 185

126 Brukerveiledning FELLESKNAPPER Tilbake Returnerer til forrige side. Avbryt Avbryter handlingen og sender deg tilbake til kontrollpanelet. Registrer Registrerer det du har gjort og legger det inn i databasen. Slett Sletter det valgte elementet i databasen. Rediger Redigerer informasjonen til det som er valgt i databasen. Endre Endrer informasjon til det valgte elementet. KONTROLLPANEL - ADMINISTRASJON Figur 43: Administrasjonspanel Etter at du som administrator har logget inn, vil du komme til kontrollpanelet for webapplikasjonen. Her har du flere knapper å gå til, og dette skal vi nå gå igjennom. Side 126 av 185

127 Brukerveiledning PROSJEKT Figur 44: Se alle prosjekter Alle prosjekter Denne knappen lister ut alle prosjekter som er opprettet i databasen, samtidig som den viser prosjektene som er fullført. ALLE PROSJEKTER - PÅGÅENDE OG FULLFØRTE Figur 45: Liste over alle prosjekter Side 127 av 185

128 Brukerveiledning Legg til prosjekt Her kan du legge til et nytt prosjekt. Vi skal vise hvordan denne siden ser ut, lenger ned på siden. Fullfør Trykkes denne knappen vil et prosjekt legges på "Fullførte prosjekter", altså en historikk for prosjekter slik at du kan beholde gamle filer utenom om å måtte ha prosjektet som pågående. Her vil også alle brukere som var knyttet til prosjektet miste rettigheten sin, og ikke kunne se filene til prosjektet. Angre Denne knappen flytter et prosjekt tilbake til pågående prosjekter, noe som kan gjøres dersom det er blitt gjort en feil. Fjern Her vil prosjektet slettes, akkurat som på Slett -knappen. Side 128 av 185

129 Brukerveiledning PROSJEKT DEL 1 Figur 46: Prosjektets side Trykker du på et prosjekt vil du komme til denne siden, som vier informasjonen til et prosjekt øverst på siden. Nå skal vi gå igjennom alle funksjonene du kan gjøre her inne. Bildet over viser hvordan et prosjekt ser ut. Side 129 av 185

130 Brukerveiledning BRUKERE Figur 47: Brukervalg på prosjekt Involverte brukere Her vil du komme til en liste over alle brukere som er med i dette prosjektet og hvilke brukergrupper de er lagt på. Bildet under viser hvordan denne siden ser ut. Figur 48: Liste over involverte brukere Legg til bruker i brukergruppe Samme side som du kommer til med knappen "Legg til bruker" som vi forklarte i forrige avsnitt. Under ser du siden du kommer til ved å trykke på begge knappene. Side 130 av 185

131 Brukerveiledning Figur 49: Legg til bruker i brukergruppe Legg til bruker på prosjekt Her kan du legge til brukere til prosjektet. Siden vises på bildet under. Figur 50: Legge til brukere på et prosjekt Legg til bruker Legger til en bruker på prosjektet. FILER Figur 51: Filvalg i prosjekt Side 131 av 185

132 Brukerveiledning Alle filer Her vil det komme fram en liste av alle filer som er lastet opp på dette prosjektet. Figur 52: Liste over prosjektets filer Filnavn Trykker du på filnavnet til en fil, vil du laste ned filen. Gi filrettigheter til brukere Her kan du gi brukere rettigheter til filer, denne filen vil da vises i brukerens personlige mappe. Brukes som oftest til kontrakter og personlige filer som andre enn brukeren og administrator ikke skal kunne se. Figur 53: TIldele rettigheter til brukere Side 132 av 185

133 Brukerveiledning Gi rettigheter til brukergruppe Denne knappen vil sende deg til en side der du kan gi filrettighet til brukergrupper i prosjektet. Dette vil være felles filer for alle brukere som er med i denne brukergruppen. Figur 54: Gi filrettigheter til brukergruppe Last opp Her kan du laste opp filer til prosjektet, disse filene vil vises under "Alle filer"-knappen på forsiden til prosjektet. Figur 55: Last opp filer til prosjekt Side 133 av 185

134 Brukerveiledning RAPPORT Det opprettes rapporter til et prosjekt, nå skal vi gå igjennom hva du kan gjøre med disse knappene. Figur 56: Rapportmeny Møtereferat Her vil du komme til en side med alle møtereferatene til dette prosjektet. Denne siden vil være lik på alle rapportene, men på avviksskjema er det noen forskjeller, dette kommer vi tilbake til etterpå. Figur 57: Liste over møtereferat Rapport Trykker du på en rapport vil du komme inn til rapporten og kan se informasjonen og bildene som er lagret. Bilde Her kan du laste opp et bilde til en rapport. Side 134 av 185

135 Brukerveiledning Print Her kommer du til utskriftsversjonen av rapporten. Skaderapport Denne knappen sender deg til en side med alle skaderapporter til prosjektet, her vil knappene gjøre det samme som på møtereferat. Tilstand-/framdriftsrapport Her vil du komme til alle Tilstand-/framdriftsrapporter på prosjektet, her vil knappene gjøre det samme som på de forrige rapportene. Avviksskjema Her kan du se alle avviksskjemaene til prosjektet, knappene vil gjøre det samme som de forrige rapportene. Avviksskjema består av tre deler, og her forklarer vi noen av forskjellene mellom disse. Figur 58: Liste med avviksskjemaer Behandle rapport Her kan du behandle avviket og siden vises på bildet under. Side 135 av 185

136 Brukerveiledning Figur 59: Behandling av avviksskjema Side 136 av 185

137 Brukerveiledning Avslutte rapport Her kan du avslutte avviket og siden vises på bildet under. Figur 60: Lukking av avviksskjema PROSJEKT DEL 2 Denne siden ligger under prosjekt del 1, og her er mappesystemet til alle brukergruppene til prosjektet. Videre skal vi gå igjennom alt du kan gjøre her. Figur 61: Mappevalg Ny mappe Her kan du registrere en ny mappe, hvis denne knappen trykkes på forsiden, vil du opprette en ny overordnet mappe, og denne kan det ikke lastes opp filer til. Inne i den nye mappen du har laget vil du kunne opprette nye mapper som også vil opprette en mappe og en brukergruppe på dette prosjektet med samme navn, og her kan du laste opp filer. Side 137 av 185

138 Brukerveiledning Figur 62: Opprette ny mappe Mappe (for eksempel Bygg) Trykker du på mappen Bygg kommer du inn til alle brukergruppene som ligger under mappen Bygg. Bildet under viser hvordan denne siden ser ut. Figur 63: Undermappene til "Bygg"-mappen Tannhjul Trykker du på tannhjulet får du opp valgene om å slette og endre mappen. Ny mappe Oppretter en mappe under bygg mappen og lager samtidig en brukergruppe til denne mappen. Mappe (for eksempel Kunder) Her vil du kunne se alle filer som er lagt på brukergruppen "Kunder", disser er de samme filene som en kunde vil ha på sin side og brukeren kan laste disse ned. Side 138 av 185

139 Brukerveiledning Figur 64: Filer i mappen "Kunder" Slett Sletter rettigheten til en brukergruppe for den gitte filen. LAG NYTT PROSJEKT Her kan du opprette et nytt prosjekt. Figur 65: Prosjektvalg Lag nytt prosjekt Trykker du på lag nytt prosjekt, kommer du til siden under. REGISTRER NYTT PROSJEKT Side 139 av 185

140 Brukerveiledning Figur 66: Registrere nytt prosjekt Velg dato Her kommer det en kalender, som gjør det enkelt for deg å velge datoen for prosjektet. Figur 67: Date picker. Velg dato Side 140 av 185

141 Brukerveiledning BRUKER Figur 68: Brukervalg Alle brukere Trykkes denne knappen vil du komme til en liste av alle registrerte brukere i systemet. ALLE BRUKERE Figur 69: Liste over alle brukere Side 141 av 185

142 Brukerveiledning Bruker Her kan du også trykke på brukerens navn og komme til brukerens side. LEGG TIL BRUKER Legg til bruker Her kan du legge til en ny bruker til systemet. Brukeren registreres med brukernavn som en epostadresse og passord med en blanding av bokstaver og tall, dette blir brukt som innloggingsinformasjon for brukeren for å få tilgang til systemet. Figur 70: Registrer ny bruker LEGG TIL Figur 71: Legge til bruker på prosjekt Side 142 av 185

143 Brukerveiledning Legg til bruker på prosjekt Her kan du gi en bruker rettighet til et prosjekt, dette prosjektet vil da listes ut på brukerens side. LEGG TIL BRUKER TIL PROSJEKT Figur 72: Legge til bruker på prosjekt Her får du en dropdown-liste av alle brukerne i systemet og kan legge de til i et prosjekt via en annen dropdown-liste. Registrer Gir brukeren rettighet til prosjektet. KONTROLLPANEL NETTSIDEN Figur 73: Nettsidekontroll (CMS) FORSIDE Side 143 av 185

144 Brukerveiledning Endre forsiden Her kan du endre informasjonen som vises på forsiden. Du kan endre tittelen og innholdet, samtidig som du kan laste opp bilder som vil vises i en bildekarusell. Figur 74: Endre forside (CMS) Lagre Lagrer informasjonen som er skrevet inn i tekstboksen. Last opp bilde Her kan du velge et bilde som skal lastes opp i bildekarusellen på forsiden. Slett bilde Sletter et bilde som ligger i bildekarusellen. OM OSS Her kan du endre informasjonen som ligger på "Om oss", denne siden ser helt lik ut som "Endre forsiden". Side 144 av 185

145 Brukerveiledning KONTROLLPANEL LOGGING Figur 75: Vis databaselogg LOGG DEL 1 Logg Her vil du komme til en liste som inneholder alt av endringer i databasen. Her vil det også stå hvilken administrator eller bruker som har gjort endringene og når. Side 145 av 185

146 Brukerveiledning Figur 76: Databaselogg del 1 Tøm logg Her kan du slette alt av logg som ligger i databasen. LOGG DEL 2 Figur 77: Databaselogg del 2 Side 146 av 185

147 Brukerveiledning Bla gjennom sider Loggen viser 15 databaserader på hver side. Ved å trykke på tallene nederst på siden kan du se de 15 neste radene. Side 147 av 185

148 Brukerveiledning Side 148 av 185

149 TAKST OG PROSJEKTKONTROLL AS Brukerveiledning BRUKERMANUAL ANDROID-APPLIKASJON Side 149 av 185

150 Brukerveiledning FORORD Dette er en brukermanual både for Android-applikasjonen til Takst og Prosjektkontroll AS. Et applikasjonskart ligger under og kan være til stor hjelp med å holde styr på hvor du er og hvilke valg man har fra det stedet du er. Oppbygningen er ganske så lik gjennom applikasjonen, men det er variasjon i valgmuligheter. Hvis du vet hva du leter etter, ta en titt i innholdslisten under den delen av manualen som gjelder for det, så finner du det med engang. APPLIKASJONSKART Figur 78: Applikasjonskart Side 150 av 185

151 Brukerveiledning HVORDAN BRUKE APPLIKASJONEN I denne delen av brukermanualen som omhandler mulighetene for brukeren i applikasjonen, er det flere knapper som går igjen flere steder. Disse er forklart i starten av manualen. Andre knapper er utdypet og markert at det er en knapp med understreking. Etter at en knapp er markert ved understrekingen, vil det bli beskrevet funksjonaliteten tilhørende denne rett under. INNHOLD Forord Applikasjonskart Hvordan bruke applikasjonen Innhold Fellesknapper Prosjekt meny Rapport meny Rapport og skjema visning Lage nye rapporter sette dato i rapporter og skjemaer Sette inn bilder i rapporter Behandle avviksskjema Avslutt avviksskjema Side 151 av 185

152 Brukerveiledning FELLESKNAPPER Tilbake Returnerer til forrige side ved å trykke ved siden av bilde oppe i venstre hjørne. Figur 79: Tilbake + tegn øverst til høyre Åpner en rapport slik at du kan fylle den ut. Figur 80: Legg til Avhakning øverst til høyre Registrerer og lagrer det som er fylt inn. Figur 81: Avhakning PROSJEKT MENY Figur 82: Liste med prosjekt Side 152 av 185

153 Brukerveiledning Skjermbildet over viser hvordan alle prosjekter listes ut. Dette er startsiden på applikasjonen og stedet du kommer til etter å ha startet applikasjonen og oppstartslogoen har forsvunnet. Her trykker du på det prosjektet du skal skrive en rapport under. RAPPORT MENY Figur 83: Meny for rapporter Trykker du på et prosjekt vil du komme til denne siden, som gir fire knapper med forskjellige valg. Disse linker deg videre til de respektive skjemaene og rapportene innenfor det prosjektet du gikk inn på i forrige steg. Side 153 av 185

154 Brukerveiledning RAPPORT OG SKJEMA VISNING Figur 84: Liste over avviksskjema Bildet over viser hvordan de eksisterende rapportene, i dette tilfellet avviksskjemaer, vises i en liste. Øverst til høyre er + -knappen som ble beskrevet først i denne manualen. Trykker du på denne starter du et nytt skjema eller ny rapport. Denne visningen og oppsettet som er vist over, vil være likt satt opp på alle de forskjellige rapportene. Side 154 av 185

155 Brukerveiledning LAGE NYE RAPPORTER Avhengig av hvilket skjema eller rapport du skal fylle ut er det gjerne noen forskjeller. Her vil de feltene som er spesielle for den enkelte rapport ble utbrodert. På avviksskjema er det litt spesielt siden denne både har en behandlingsdel og en avslutningsdel. Hvordan dette fungerer er forklart litt lenger ned. Figur 85: Utfylling av avviksskjema og møtereferat Inne på utfyllingen av avviksskjemaet til venstre er det ingen spesielle felt, men vanlige felt for utfylling av den teksten feltet hører til. Møtereferatet er litt spesielt, da du skal kunne fylle inn alle som er innkalte og deretter huke på venstre side ved hvert navn om den enkelte var tilstede. Side 155 av 185

156 Brukerveiledning Figur 86: Utfylling av tilstands- og skaderapport En del av tilstandsrapporten, som er vist på bildet til venstre, er et skjema som må fylles ut ved å nummerere poster med bygningsdelen det gjelder. Skaderapporten er litt spesiell fordi den er delt opp i 2 sider. En skaderapport har flere felter det kan skrives mye tekst på, så her brukes pilen oppe i høyre hjørne til å gå til del 2 av skaderapporten. Side 156 av 185

157 Brukerveiledning SETTE DATO I RAPPORTER OG SKJEMAER Figur 87: Date picker. Velg dato Feltene som har med velding av dago å gjøre er lik på alle steder i applikasjonen. Når du trykker på datoen, som er satt til dagens dato automatisk, kommer det opp en dato-velger som på bildet over. Bruk trykker du når du har funnet datoen du skal bruke, mens Avbryt brukes når du vil gå tilbake til rapportutfyllingen. Side 157 av 185

158 Brukerveiledning SETTE INN BILDER I RAPPORTER Figur 88: Legg inn bilde i rapport Etter en rapport er fylt ut kan du gå inn igjen på en utfylt rapport og legge til bilder. Dette gjelder alle rapporter og skjemaer. For å gjøre dette trykker du på kamera-ikonet oppe i høyre hjørne. Når du har trykket på dette ikonet får du opp to valg. Det ene er om du vil hente et bilde fra galleriet på telefonen din og det andre om du vil ta et nytt bilde med kameraet. Når du har valgt en av disse to kommer du til bildet til høyre. Her kan du enten angre og gå tilbake, eller laste det opp til den rapporten du gikk inn på ved å trykke på Last opp til server. Side 158 av 185

159 Brukerveiledning BEHANDLE AVVIKSSKJEMA Figur 89: Etterbehandling av avviksskjemaene Når et avviksskjema er lagt inn og du går inn for å se på det, vil du få valg om å behandle og avslutte avviket nederst i visningen av rapporten slik som på bildet over. Figur 90: Behandling av avviksskjema Trykker du på Behandle avviket blir du sendt til siden som er vist på bildet over. Det å behandle gjelder kun for avviksskjemaet og ikke de andre rapportene. Side 159 av 185

160 Brukerveiledning AVSLUTT AVVIKSSKJEMA Figur 91: Lukking av avvik På bildet over vises det som kommer hvis du trykker Avslutt avviket -knappen nederst i et avvik. Her gjøres siste utfyllinger før man avslutter og laste opp ved å bruke avhakningen oppe i høyre hjørne. Side 160 av 185

161 Side 161 av 185

162 Vedlegg VEDLEGG INNHOLD Vedlegg 1 - Testrapport Vedlegg 2 - Ordliste Vedlegg 3 - Kilder Vedlegg 4 - Tilbakemelding Vedlegg 5 - Kontrakt Side 162 av 185

163 Vedlegg 1 VEDLEGG 1 TESTRAPPORT FORORD I dette kapittelet skal vi gå igjennom hvordan vi har håndtert brukertestinger gjennom utviklingen av applikasjonene. Vi vil også beskrive enhetstester og brukte verktøy. Side 163 av 185

164 Vedlegg 1 INNHOLD Forord Innhold Mål for testing Test av webapplikasjon Verktøy brukt i testing Google Chrome Mozilla Firefox Internet Explorer(IE) Test Tools i Visual Studio Brukertesting Enhetstesting Konklusjon Test av Android-applikasjon Verktøy brukt i testing LogCat Samsung Galaxy S Brukertesting Konklusjon Side 164 av 185

165 Vedlegg 1 MÅL FOR TESTING Et av målene med testingen er å unngå at vi ender opp med et produkt som er lite brukervennlig. Et annet mål er å teste metodene som blir brukt i løsningen. Det er enklere for de som har utviklet applikasjonen å få riktige tilbakemeldinger ved bruk av funksjonaliteten på webapplikasjonen, i forhold til en som aldri har brukt verktøyet. Ettersom applikasjonen skal lagre kontrakter mellom daglig leder og aktørene er det viktig at andre brukere ikke har tilgang til disse filene. Derfor er det viktig å drive testing. TEST AV WEBAPPLIKASJON VERKTØY BRUKT I TESTING Siden vi utvikler en webapplikasjon har vi brukt forskjellige nettlesere for å se om løsninger er lik på de forskjellige. GOOGLE CHROME Vi har skrevet nettsiden slik at den er mest kompatibel med Google Chrome. Det er nettleseren vi har brukt til å teste med hele veien, og er den nettleseren vi anbefaler å bruke for webapplikasjonen. MOZILLA FIREFOX Vi har vært innom Mozilla Firefox for å se om webapplikasjonen var brukbar for denne nettleseren. Vi fant fort ut at det ble noen forskjeller ved bruk av andre nettlesere, selvom funksjonaliteten til nettsiden kunne brukes i Mozilla firefox. Side 165 av 185

166 Vedlegg 1 INTERNET EXPLORER(IE) Nettløsningen fungerte bra sammen med IE, men forskjellen på oppløsningen i denne nettleseren og Google Chrome er annerledes. TEST TOOLS I VISUAL STUDIO Test Tools er Microsofts rammeverk for enhetstesting. Dette er brukt for å lage alle enhetstestene til webapplikasjonen. BRUKERTESTING Vi har kjørt brukertestinger gjennom oppdragsgiver ved at vi gjorde webapplikasjonen tilgjengelig så fort som mulig på internett, noe som gjorde at han kunne teste funksjonaliteten gjennom hele utviklingen. Vi fikk mye tilbakemeldinger på epost om hvordan ting fungerte og ikke fungerte. Det vi har gjort mest brukertesting og endringer på er rapportene i webapplikasjonen. Rapportene ble gitt til oss i papirformat og vi utviklet en side som vi tenkte ville være enkelt for oppdragsgiver å forstå, men etter noe testing fra han sin side fant vi ut at han ønsket rapportene så lik som papirutgavene som mulig. Det var derfor viktig med mange tester fra oppdragsgiver ettersom det hovedsaklig er han som skal bruke verktøyet. Side 166 av 185

167 Vedlegg 1 Funksjonalitet Test Resultat Logge inn Logge inn med brukernavn. Ok Skal fungere for både bruker og administrator. Lage, endre, fullføre og slette Administrator skal kunne Ok prosjekt lage, endre, fullføre og slette et prosjekt. Lage, endre og slette bruker Administrator skal kunne Ok lage, endre og slette en bruker. Lage, endre og slette mappe Administrator skal kunne lage, endre og slette en Ok Lage, endre og slette rapporter. Legge til bilder på rapporter Laste opp filer til prosjekt og brukermappe mappe. Administrator skal kunne lage, endre, slette, vise og printe alle typer rapporter. Administrator skal kunne legge til bilder på alle typer rapporter. Administrator skal kunne laste opp filer til et prosjekt, eller til mappen til en bruker. Omfattende test hvor noe kan ha blitt glemt å teste. Ellers Ok Ok Ok Gi filrettigheter til brukere og brukergrupper Laste opp fil til personlig mappe Endre innhold på forside Endre innhold i Om oss Se og slette logg Administrator skal kunne gi filrettigheter både til brukere og brukermapper. Bruker skal kunne laste opp filer til sin personlige mappe som han og administrator skal kunne se. Administrator skal kunne endre forsidens innhold. Dvs. tekst og bilder. Administrator skal kunne endre innhold på siden Om oss. Dvs. tekst og bilde. Administrator skal kunne se og slette loggen. Ok Ok Ok Ok Ok Side 167 av 185

168 Vedlegg 1 ENHETSTESTING I løsningen er det implementert flere kontrollertester som kan brukes dersom det er ønske om å endre eller videreutvikle noe av koden. Her kan det relativt enkelt endres og sjekkes om kontrollermetoden fortsatt returnerer riktig view eller gir riktig redirect. Utvikling av slike automatiserte tester er kjent for å ta en del tid og virke unødvendig, men i senere perioder i utviklingsprosessen kan det være mye ressurser å spare ved å ha disse på plass. Vi valgte å teste utvalgte metoder fra AdminController og ReportController i vår løsning. Stort sett tar disse testene for seg sjekking av hvilke views og redirects utvalgte kontroller-metoder skal returnere etter objekter enten blir listet ut eller lagt til. Som vist på figuren ligger disse under UnitTest-prosjektet i løsningen. Figur 92: Liste over enhetstester KONKLUSJON Ved at vi lastet opp nettstedet tidlig til oppdragsgiver, har vi fått mye testing på nettstedet og fått til slutt et produkt som oppdragsgiver ønsket. Dette har også gjort det enklere for oss å utvikle webløsningen ved at vi hele tiden kan få tilbakemeldinger. Side 168 av 185

169 Vedlegg 1 TEST AV ANDROID-APPLIKASJON VERKTØY BRUKT I TESTING LOGCAT Testing og feilsøking av Android-applikasjonen har foregått gjennom Logcat. Logcat er et program i Android SDK, og tar hånd om alt av feilsøk og breakpoints. SAMSUNG GALAXY S3 Smarttelefon fra Samsung med 4,8" skjerm. Brukt til testing av applikasjonen. BRUKERTESTING Brukertestingen har blitt utført på oppdragsgiver gjennom møtene med han. Under det første møtet vi hadde, viste oppdragsgiver oss en applikasjon han ønsket at Androidapplikasjonen skulle ligne på. Dette gjorde utformingen enklere. Vi har derfor stort sett fått positive tilbakemeldinger på designvalg. Vi fikk gode tilbakemeldinger underveis på hva han likte og hva han ville ha forbedret. Applikasjonen er dessutenprivat og ikke nedlastbart for andre. Det som ble testet mest var registrering av rapportene i applikasjonen. Rapportene ble gitt til oss i papirform og vi måtte utvikle en rapporteringsverktøy som oppdragsgiver kunne gjenkjenne. Etter noe testing fra oppdragsgivers side fant vi ut at vi skulle utforme rapportene tilnærmet lik papirutgaven, dersom det lot seg gjøre. Det ble en utfordring å få rapportene inn på en så liten skjerm. Det var derfor viktig med mange tester fra oppdragsgiver ettersom det han som skal bruke applikasjonen. Side 169 av 185

170 Vedlegg 1 Funksjonalitet Test Resultat Navigering Brukeren skal kunne Ok navigere knirkefritt mellom alle skjermene Lage rapporter. Brukeren skal kunne lage alle typer rapporter. Omfattende test hvor noe kan ha blitt glemt å teste. Hadde noe problemer med æøå som sendes over til PHP. Ellers Ok Se rapporter. Brukeren skal kunne se Ok Legge til bilder på rapporter rapporter Brukeren skal kunne legge til bilder på alle typer rapporter. Ok, problem med opplastning av bilder til server. Ellers ok KONKLUSJON Ved at vi fikk prøvd applikasjonen tidlig med oppdragsgiver, har vi fått mye testing på applikasjonen og fått til slutt et produkt som oppdragsgiver ønsket. Dette har også gjort det enklere for oss å utvikle en applikasjon ved at vi hele tiden kan få tilbakemeldinger. Side 170 av 185

171 Vedlegg Side 171 av 185

172 Vedlegg 2 VEDLEGG 2 - ORDLISTE A Asynctask: Er en trådfunksjon som fordeler arbeidet ved opplastning til Databasen. B Back-end: Kalles ofte hjernen av et program. Back-end-utviklingen er delen av applikasjonen som aldri er synlig for brukerene. Bootstrap: Bootstrap er et front-end rammeverk som inneholder html- og css-baserte designtemplates C CMS: Content Management System E Empirisk prosesskontroll: Skaffe erfaringer og bygge opp kunnskap for å komme nærmere en løsning på problemet. Entity framework: Entity Framework ( EF ) er et åpent kildekode rammeverk med ORM (object-relational mapping) for.net. ER: Entity Relationship. Viser relasjoner i en relasjonsdatabase. Side 172 av 185

173 Vedlegg 2 F Fremdriftsplan: En fremdriftsplan er en oversikt over det arbeidet man planlegger å utføre, altså en kort og skjematisk beskrivelse over de forskjellige arbeidsoppgaver. Front-end: Er utviklingen av elementer på et nettsted etc. som brukere kan se og interagere med. H HiOA: Høgskolen i Oslo og Akershus I Implementere: Gjøre det som er nødvendig for å få program eller funksjon til å virke. IDE: Står for Integrated Development Environment. På norsk er det et integrert utviklingsmiljø som hjelper utviklere med å skape og feilsøke (debugge) kode. K Klient: En klient er et dataprogram som kjører lokalt hos brukeren og som kan kobles opp mot en tjener via et nettverk slik at tjeneren bidrar til funksjonaliteten. Side 173 av 185

174 Vedlegg 2 L Learning by doing: Å lære ved å gjøre. Når man er nært og aktivt knyttet til læringsstoffet gjennom aktivitet. ListView: Et ListView er en visuell komponenet som presenterer informasjon i en skrollbar liste. M MVC: Model-View-Controller O ORM: Object-relational mapping er en teknikk for å konvertere data mellom ukompatible typesystemer i objektorienterte programmeringsspråk. P Pair programming: En teknikk hvor to programmerere sitter sammen og programmerer. Den ene skriver kode(driver), og den andre observerer og kommer med innspill(observer). PartialView: View som fungere som et tilleggsview til ordinære views. (Ofte med andre modeller). R Risikoplan: Risikoplan er en oversikt over ting som kan gå galt og ting som gjør at man bruker lengre tid en planlagt. Den inneholder også hvordan man skal forhindre at risikoene ødelegger for prosjektet. Side 174 av 185

175 Vedlegg 2 S Scrum: Smidig utviklingsmetode. Sprint: Periode på 1-4 uker hvor en mengde definerte funksjoner skal ferdigstilles. T To-do list: En liste over ting som skal gjøres. Tjener: En tjener, også kalt en server, er en programvare som tilbyr en eller flere tjenester til andre datamaskiner (klienter) over et datanettverk. U User story: En beskrivelse fra en sluttbrukers ståsted over hva han/hun må kunne gjøre for å gjøre jobben sin. Ofte formulert slik; Som en [sluttbrukers rolle], må jeg kunne [ønsket handling] slik at [resultat]. Side 175 av 185

176 Vedlegg Side 176 av 185

177 Vedlegg 3 VEDLEGG 3 KILDER Android Developer. Activity. Hentet fra Android Developer. AlertDialog. Hentet fra Android Developer. AsyncTask. Hentet fra Android Developer. ListView. Hentet fra Android Developer. SharedPreferences. Hentet fra ASP.NET. Creating Unit Tests for ASP.NET MVC Applications. Hentet fra Bootstrap. Components of Bootstrap. Hentet fra Entity Framework. Hentet fra Høgskolen i Oslo og Akershus. (udatert). Dokumentasjonsstandard. Hentet fra MSDN Magazine. Pros and Cons of Data Transfer Objects. Hentet fra Scrum Methodology. Scrum Methodology, introduction etc. Hentet fra Side 177 av 185

178 Vedlegg 3 Scrumblr. Scrumblr by Aliasaria (Scrum board). Hentet fra Wikipedia. Content Management System (CMS). Hentet fra Side 178 av 185

179 Vedlegg Side 179 av 185

180 Vedlegg 4 VEDLEGG 4 TILBAKEMELDING FRA OPPDRAGSGIVER Side 180 av 185