[GILJE SELSKAPSLOKALER]

Størrelse: px
Begynne med side:

Download "[GILJE SELSKAPSLOKALER]"

Transkript

1 2013 Hovedprosjekt 2013 Gruppe 27 Sluttdokumentasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie

2 Sluttdokumentasjon 1

3 Sluttdokumentasjon Hovedprosjekt 2013 Hovedprosjekttittel: "" Oppdragsgiver: Gilje Kontaktpersoner: Per Christian Arnfinsen og Svein Erik Lunde Intern veileder: Geir Skjevling Prosjektgruppe: Gruppe 27 Prosjektdeltagere: Lars Gjestang s Hiran Piapo s Bård Skeie s Antall sider inkludert forside og vedlegg: 159 sider 2

4 Sluttdokumentasjon 3

5 Sluttdokumentasjon 1 Forord Dette er sluttrapporten til gruppe 27 sitt hovedprosjekt ved Høgskolen i Oslo og Akershus, våren Sluttrapporten viser planlegging, arbeidsmetoder og gjennomføring av oppgaven. Dokumentasjonen skal gi svar på teknologier, verktøy, forutsetninger og prosessen som ligger bak det ferdige produktet. Gruppe 27 består av tre medlemmer som alle har gjort dette hovedprosjektet som siste ledd i utdannelsen "Informasjonsteknologi" ved HiOA. Oppgaven vi har jobbet med var å utvikle en fullstendig nettløsning for Gilje AS. Dette inkluderte å lage to nettsider: 1 - En nettside for som leies ut til bryllup, konfirmasjoner, konferanser osv. 2 - En portal for medlemmer av Klubben som drifter Gilje. I utgangspunktet skulle hele løsningen være samlet på èn nettside, men underveis ble det bestemt at og Klubben skulle skilles i løsningen og lages som to nettløsninger på hvert sitt domene. Dokumentasjonen har derfor blitt ganske omfattende for å dekke begge systemene. Dokumentasjonen består av 4 hoveddeler. Prosessdokumentasjonen er spesielt beregnet på sensor og veileder mens produktdokumentasjonen og brukerdokumentasjon er utviklet mest med tanke på oppdragsgiver. Kravspesifikasjonen henvises til fra alle dokumentene så den er å finne som eget hovedkapittel i denne sluttrapporten. Testrapporten har vi valgt å legge inn i prosessdokumentasjon og produktdokumentasjon der dette er naturlig. Bakerst i sluttdokumentasjonen ligger vedlagt en CD med det ferdige produktet, denne rapporten i PDF-format og en "lesmeg" -fil som beskriver kravene for å kjøre prosjektet lokalt. Prosjektet har også lastet opp dokumentasjon til egen prosjektside: Nettløsningen til Gilje er på nett allerede. Nettadressen er: 4

6 Sluttdokumentasjon 5

7 Sluttdokumentasjon Innholdsfortegnelse Prosessdokumentasjon... 8 Kravspesifikasjon Produktdokumentasjon Brukerdokumentasjon

8 Sluttdokumentasjon 7

9 2013 Hovedprosjekt 2013 Gruppe 27 Prosessdokumentasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie

10 Prosessdokumentasjon 9

11 Prosessdokumentasjon Prosessdokumentasjon 1 Forord Dette er prosessdokumentasjonen til gruppe 27 for prosjektet "". Dokumentet beskriver utviklingen av systemet og er skrevet for å redegjøre for bakgrunnen for utviklingen, systemets bruksområde, samt metodikk og arbeidsmetode som er benyttet i utviklingsprosessen. Dokumentet er hovedsaklig skrevet for sensor og veileder, men metoder, verktøy og teknologier er beskrevet så for eksempel oppdragsgiver skal kunne lese dokumentet uten å ha mye forkunnskap om disse. Vi startet med arbeidstittel "", men da oppdragsgiver ønsket å dele løsningen i to separate deler har vi omtalt de to løsningene med arbeidstitlene "Gilje Selskapslokaler" og "Klubben". Som vedlegg til sluttdokumentasjonen har vi lagt ved en CD med løsningene vi har utviklet. 10

12 Prosessdokumentasjon 11

13 Prosessdokumentasjon Innhold 1 Forord Innledning Gruppen Om Bedriften Bakgrunn for oppgaven Mål og rammebetingelser Planlegging og metode Valg av oppgave Planleggingsfasen Risikohåndtering Verktøy og teknologier Microsoft Windows ASP.NET MVC rammeverk Microsoft Visual Studio TFS(Team Foundation Server) Dropbox Microsoft Office Skype FileZilla Notepad Whiteboard Kunnskap Kommunikasjon I gruppen Med oppdragsgiver Med Veileder Dokumentasjon Dokumentasjonsstandard Styringsdokumentene Sluttdokumentasjon Om utviklingsprosessen Analyse av suksessfaktorer for systemutviklingsprosjekt Valg av systemutviklingsmodell

14 Prosessdokumentasjon Smidig utvikling Scrum Avvik fra tradisjonell Scrum Faser Planlegging Forbereding Utvikling Frislipp Testing Kravspesifikasjon og dens rolle Utarbeiding av kravspesifikasjon Endring av versjon Samsvar med kravspesifikasjon Avvik fra kravspesifikasjon Konklusjon Referanser Vedlegg Samarbeidsavtale Risikoplan Prosjektskisse Forprosjektrapport Arbeidsplan Fremdriftsplan Eksempel - Brukertestskjema

15 Prosessdokumentasjon 2 Innledning 2.1 Gruppen Gruppen bak dette hovedprosjektet består av Lars Gjestang, Hiran Piapo og Bård Skeie. Alle på gruppen har gått i samme klasse på bachelorstudiet i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Alle på gruppen har jobbet sammen tidligere på forskjellige prosjekter, men dette er første prosjektet sammen med denne sammensetningen. Vi følte at vi gikk inn i prosjektet med like forutsetninger og tilnærmet likt kunnskapsnivå, men hver våre styrker som vi kunne utnytte i gruppearbeidet. Da vi startet prosjektet var vi klare på at alle gruppemedlemmene skulle være inkludert i prosjektets forskjellige deler, men med hvert vårt ansvarsområde. Lars ble hovedansvarlig for koding og kontakt med oppdragsgiver, Hiran jobbet mest med design og JavaScript mens Bård jobbet mest med dokumentasjon og datamodeller. Delingen har fungert greit, men alle har vært involvert i de forskjellige fasene og bidratt i alle deler av prosjektet. 2.2 Om Bedriften Gilje har en lang historie som selskapslokale i Askim. Det benyttes til bryllup, jubileer, begravelser, møter etc. Selskapet er et AS og heleid av Klubben som er en medlemsklubb hvor det blant annet spilles bridge. Gilje har et samarbeid med cateringselskapet, MatHilde, som står for booking, servering og daglig ansvar for utleie. 2.3 Bakgrunn for oppgaven Situasjonen i dag er at Mathilde har egen nettside, men Gilje har ingen nettløsning for informasjon eller bestilling av lokalet. Gilje leier i dag ut lokalet etter avtale over telefon eller i person, men dette er et tungvindt system som også krever noe tid siden kundene ikke kan finne informasjon på nettet. Mathilde har egen nettside, men både Gilje og Mathilde vil tjene på at selskapene promoteres på hverandres nettsider. Klubben er eiere av selskapet. Klubben har ingen nettside, men har ønske om en portal der medlemmer kan logge inn og få tilgang til dokumenter og nyheter som kun angår medlemmer. Ønsket er at Gilje skal få en nettløsning som promoterer, gir god informasjon til potensielle kunder, og blir en felles database for medlemmer av Klubben. 14

16 Prosessdokumentasjon 2.4 Mål og rammebetingelser Målet med denne oppgaven er å lage en nettløsning for Gilje. Løsningen kan deles i to hoveddeler: 1. Nettsted for Gilje Selskapslokale med informasjon og booking-forespørsel for besøkende på nettsiden. Innhold på siden skal administreres og booking-forespørsler skal behandles. 2. Nettsted/portal for ansatte/medlemmer av Klubben for informasjon og deling av dokumenter og kontaktinformasjon. Del 1 skal inneholde: kalender som viser bookingstatuser bildegalleri info meny kontakt oss Levende bildeshow link til MatHilde Oversikt over bookinger. Mulighet for å endre, slette og legge til bookinger. Del 2 skal inneholde: Portal for medlemmer med tildelte grupperettigheter Database for dokumenter, møtereferat, selskapssanger m.m. Sanger og dokumenter skal være søkbare administrator skal kunne legge til, fjerne og endre nyheter, dokumenter og medlemmer. Medlemmer registreres med et tilgangsnivå som forteller systemet hva brukeren skal ha tilgang til og hva brukeren skal ha lov til å gjøre. Selve bookingen er ønskelig å ha pr telefon for å ha en manuell kontroll på hva lokalet leies ut til, men booking-forespørsel og informasjon på nettet vil gjøre at kundene vet mer om lokalet og mulighetene for tilleggstjenester før de tar kontakt. Vi ønsker at nettsiden skal være kompatibel med MS Internet Explorer, Mozilla Firefox og Google Chrome som et minimum. 15

17 Prosessdokumentasjon 3 Planlegging og metode 3.1 Valg av oppgave Høsten 2012 dannet vi gruppe og startet arbeidet med å skaffe et prosjekt vi kunne jobbe med. Gruppa var enig om at vi ønsket å utvikle et nettsted, men vi ville ikke bestemme oss for hvilket språk vi skulle benytte. Vi søkte etter oppdragsgiver gjennom egne kanaler og ved å kontakte større bedrifter. Vi fikk blant annet tilbakemelding fra Oslo Vei AS om at vi gjerne kunne ta hovedprosjekt hos dem. På dette tidspunkt hadde vi vært i kontakt med Gilje også så vi takket heldigvis nei til tilbudet siden Oslo Vei slo seg konkurs kort tid etter. Vi kom i kontakt med Gilje gjennom egne kontakter og fattet interesse for Gilje som oppdragsgiver siden løsningen de ønsket seg så ut til å være i tråd med hva vi ønsket å gjøre. Etter en prat med Gilje ble enige om at vi skulle gå for denne oppgaven og avtalte et møte for å gå gjennom hva de ønsket at løsningen skulle inneholde. Etter dette møtet kunne vi starte prosessen med å velge verktøy, språk og lage modeller for løsningen. 3.2 Planleggingsfasen Vi startet planleggingen på slutten av høstsemesteret. Vi ble enige om arbeidsmetode og at vi skulle legge arbeid med hovedprosjektet til faste dager så langt det lot seg gjøre. Vi laget en grov framdriftsplan for å ha et utgangspunkt å starte med på vårsemesteret. I januar startet jobben med hovedprosjektet for fullt og vi begynte med å vurdere språk og utviklingsverktøy for å løse oppgaven. Vi vurderte om vi skulle bruke PHP som språk og Symphony2 som rammeverk. Dette var en vurdering vi gjorde av to grunner: det er ofte bedre støtte for PHP på webservere og vi syntes det kunne være interessant å lære mer PHP med et for oss helt nytt rammeverk. Vi brukte en del tid på å sette oss inn i Symphony2 og gjøre oss kjent med mulighetene vi hadde her, men til slutt ble vi enige om at vi burde bruke.net isteden siden dette er et kraftig verktøy som er etterspurt på markedet i dag og som ser ut til å være overta mer og mer. Derfor mente vi dette var et naturlig valg både for egen læring og et levedyktig produkt til oppdragsgiver. Ulempen med å velge.net var at mange webservere kjøres på Linux-servere mens.net bør ligge på Windows-server. Gilje hadde hverken domene eller webhotell på dette tidspunkt så dette kunne vi ta hensyn til ved bestilling av webhotell. Vi brukte mye tid på denne fasen. Dette mente vi var viktig for at vi skulle jobbe målrettet med prosjektet uten å måtte forkaste deler av løsningen på grunn av dårlig planlegging. I denne fasen laget vi også en skikkelig framdriftsplan og arbeidsplan[5] som vi har forsøkt å holde oss til gjennom prosjektet. Planene har vært viktige for å ha god fremdrift i prosjektet, men vi har også erfart at endringer må påregnes underveis i prosjektet. Deler av prosjektet hadde vi feilberegnet arbeidsmengden på og endringer i kravspesifikasjonen førte til noen endringer i fremdriftsplanen[6]. Vi hadde heldigvis tatt høyde for dette da vi laget planen. Vi hadde satt av bedre tid til testing enn vi regnet med å trenge for å ha litt å gå på her om andre faser i prosjektet skulle ta mer tid enn beregnet. 16

18 Prosessdokumentasjon Vi laget en prosjektside som vi lastet opp på server. Dette var en enkel side laget i HTML og CSS for å legge ut styringsdokumentasjon og etter hvert sluttdokumentasjon slik at dette skulle være tilgjengelig for veileder og oppdragsgiver på nettet. Ettersom at ingen deler av dokumentasjonen inneholder konfidensiell informasjon har vi ikke hatt behov for innlogging eller annen sikkerhet på prosjektsiden. 3.3 Risikohåndtering Da vi startet på prosjektet ble vi enige om en samarbeidsavtale[1] og en risikoplan[2] for prosjektet. Samarbeidsavtalen[1]er grei for at alle på gruppa skal ha en felles forståelse for hva som forventes av den enkelte og gir generelle spilleregler for gruppa. Risikoplanen[2] lister opp punkter vi anså som viktige for hva som kunne galt under prosjektet og hva vi kunne gjøre for å håndtere risikoen. Alle prosjekter bør ha en plan for uforutsette hendelser. I større prosjekter vil kostnadsfaktorer være en del av risikohåndteringen, men i vårt prosjekt har vi ingen økonomiske faktorer å ta hensyn til så det ble ikke relevant for denne oppgaven. Vi har kun tatt høyde for de mest sannsynlige og vanlige risikoene. Andre hendelser kan selvfølgelig inntreffe, men vi mener vi har tatt høyde for risikoer som kan lage problemer i prosjektet og tiltak vi kan gjøre for å forhindre dette. 3.4 Verktøy og teknologier I planleggingsfasen bestemte vi oss for hvilke verktøy og teknologier vi skulle bruke under prosjektet. Valg av verktøy var viktig for at gruppemedlemmene kunne være forberedt på å løse oppgavene uten å bruke unødvendig tid på konvertering mellom programmer og installasjoner av nye program. Ved å avtale dette på forhånd kunne vi installere og forberede de verktøy vi trengte til å løse selve oppgaven. Her lister vi verktøy og teknologier vi bestemte oss for å bruke. Selv om flere av disse verktøyene er kjent for alle og ikke alle er like avgjørende for utviklingen av prosjektet har vi valgt å liste alle her med forklaring og betydning for arbeidet Microsoft Windows 7 Alle på gruppen har bærbare datamaskiner med Windows 7 installert. I tillegg har vi stasjonære datamaskiner tilgjengelig som vi kan benytte. Ettersom vi skal utvikle en Windows basert applikasjon i Microsoft sitt utviklingsmiljø er dette uansett et foretrukket operativsystem for oppgaven. 17

19 Prosessdokumentasjon ASP.NET MVC rammeverk.net er en samling teknologier rundt programvareutvikling fra Microsoft. Plattformen er i dag en av de mest brukte utviklingsplattformene i verden. Språket som benyttes er i hovedsak C# sammen med standard HTML og CSS. Rammeverket MVC (model-view-controller) gir en programvarearkitektur som skiller representasjonen av data fra brukerens interaksjon med en. Dette gir økt sikkerhet og bedre kontroll. "Model" består av data, regler, logikk og funksjoner. "View" kan være alle slags representasjoner av utskrift av data til skjermen og "controller" konverterer inndata til kommandoer for modellen eller view'et. Vi valgte dessuten å lagdele applikasjonen til Klubben. Dette var et valg vi gjorde siden denne løsningen kom til å inneholde flere funksjoner og være mer kompleks enn Gilje Selskapslokaler. Grunner til å lagdele løsingen til Klubben var at vi trengte god struktur med en større applikasjon. Dette gjorde vi da ved å dele koden inn i presentasjons-, virksomhetsog datalag. Data blir dermed flyttet mellom lagene og de riktige tingene blir gjort i sitt lag av applikasjonen. Presentasjonslaget er MVC strukturen vår, DAL (Dataaksesslag) er laget som jobber mot database og BLL (Business Logic Layer) brukes til all annen logikk enn presentasjon og databaseaksess. Løsningen til vurderte vi som såpass mye mindre og mindre kompleks at vi så ingen grunn til å lagdele denne løsningen. Koden vil være oversiktlig nok, om ikke mer oversiktlig, som standard MVC Microsoft Visual Studio Ettersom vi har valgt.net MVC ble det et naturlig valg å bruke utviklingsmiljøet Microsoft Visual Studio2012 til jobben. Visual Studio er et integrert utviklingsmiljø for Microsofts.NET plattform. Verktøyet hjelper utviklere å utvikle programmer, websider og annen programvare som for eksempel en mobilapplikasjon. For å kunne ta i bruk Visual Studio, må du ha operativsystemet Windows kjørende på din PC. Skal du utvikle via Mac må du lage en Windows-partisjon for å utvikle i programmet. 18

20 Prosessdokumentasjon TFS(Team Foundation Server) TFS er et produkt utviklet av Microsoft som tilbyr datainnsamling, source control, rapportering og prosjektsporing. Verktøyet er ment for samarbeidsprosjekter innenfor utvikling av programvare. Dette er en tjeneste som tilbys i Visual Studio som en slags online server der alle forandringer i prosjektet blir registrert og oppdatert til enhver tid. Serveren vi benyttet opprettet vi Microsoft SkyDrive slik at den til enhver tid er tilgjengelig for oss uansett hvor vi jobber fra eller hvilken datamaskin vi bruker. En fordel med TFS er at man har fullstendig oversikt over hvem som har gjort hva og dessuten mulighet til å reversere endringer som er gjort JavaScript JavaScript er en implementasjon av ECMAScript, et skriptspråk som er best kjent for å tilføre dynamiske elementer til nettsider. Sammen med øvrig innhold på nettsiden (hovedsakelig HTML) sendes det kode (innenfor et <script>-tagpar), som kjøres lokalt i nettleseren, automatisk eller som reaksjon på brukervalg på siden. I vårt prosjekt ble javascript benyttet i forbindelse med bildebehandling på nettsidene. Vi brukte for det meste JQuery som er et JavaScript-bibliotek. JQuery er det mest populære JavaScript-biblioteket i bruk så vi mente det var det beste alternativet for oss å se på SQL Structured Query Language (SQL) er et programmeringsspråk for databaser som benyttes til å formulere og kjøre operasjoner mot relasjonsdatabaser (RDBMS) og som originalt er basert på relasjonsalgebra og -regning. De fleste av dagens databasesystemer tilbyr SQL som kontrollgrensesnitt. Vi benyttet SQL til lagring av administratorer, medlemmer, bilder, filer osv. Vi jobbet mot databasen vår gjennom LINQ (Language Integrated Query). LINQ er en komponent i Microsoft.NET Framework som kan brukes for å aksessere ulike datatyper. LINQ har en spesiell C#-syntaks som kan benyttes uavhengig av datakildene. 19

21 Prosessdokumentasjon Dropbox Dropbox er en web-basert fillagringstjeneste, der det er mulig å laste opp filer og dele med andre via "nettskyen. I tillegg er det en sikker måte å ta backup av alt arbeid vi har gjort, og gjøre det tilgjengelig for alle medlemmene til enhver tid. Det er også en sikkerhet at Dropbox har versjonskontroll, det vil si at vi har mulighet til å hente tidligere versjoner av filer vi har lagret på Dropbox Microsoft Office Ettersom alle gruppemedlemmene har Microsoft Office fra tidligere og er vant til å bruke programmene i programvarepakken ble det bestemt at vi skulle bruke MS Office til utvikling av dokumentasjon og modellering av logiske modeller samt planleggingsmodeller. Gruppemedlemmene benyttet versjon 2007 og 2010 av MS Office Microsoft Office Word All dokumentasjon er skrevet i MS Word. Dette er et kjent tekstbehandlingsprogram fra Microsoft som de fleste kjenner i dag. Tekst kan lagres i forskjellige formater og det er enkelt å inkludere grafikk fra fil eller fra andre Office programmer for å lage oversiktlige og informative dokumenter Microsoft Visio Visio ble blant annet benyttet for å lage ER-diagram og fremdriftsplan[6]. Visio er et grafikk- og tegneprogram du kan bruke til å visualisere, utforske og meddele sammensatt informasjon. Du kan bruke Visio til å gjøre om komplisert tekst og kompliserte tabeller som er vanskelige å forstå, til Visio-diagrammer som meddeler informasjon på et blunk. Visio inneholder moderne figurer og maler for mange ulike diagrambehov, inkludert ITadministrasjon, prosessmodellering, bygg og arkitektur, utforming av brukergrensesnitt, personaladministrasjon, prosjektstyring og mye mer. 20

22 Prosessdokumentasjon Microsoft Office PowerPoint Til hjelp i den muntlige presentasjonen vil MS PowerPoint brukes. Microsoft PowerPoint er et dataprogram som kan benyttes for å lage bildepresentasjoner vist på en dataskjerm eller projisert på et lerret. I dette programmet kan man lage, redigere og vise fremvisninger og presentasjoner for lysbildefremvisninger. I tillegg til tekst og bilder, kan man også bruke mediefiler som lyd og video. På denne måten blir det en multimediapresentasjon Skype Skype er et dataprogram som brukes til IP-telefoni. Dette ble et nyttig verktøy for oss de dagene vi jobbet hver for oss. Skype kan brukes til samtaler, meldingsformidling, filoverføring, videosamtaler og skjermdeling FileZilla FileZilla er en gratis FTP-programvare. FileZilla brukes til å laste opp prosjektene våre til server. På denne måten har vi et enkelt brukergrensesnitt mot servereområdet vårt. FTP (File Transfer Protocol, altså filoverføringsprotokoll) er en standard, operativsystemuavhengig protokoll for overføring av filer i et TCP/IP-basert nettverk. Overføringen skjer mellom en FTP-klient og en FTP-server Notepad ++ Dette er en gratis teksteditor. Programmet har funksjoner som autofullføring, syntaksmerking og regulære uttrykk. Filer for grensesnitt og stavekontroll på ulike språk kan lastes ned separat, blant annet bokmål- og nynorske utgaver. Det er støtte for Unicode, redigering av TeX-dokumenter og binærfiler og en rekke andre formater. Brukergrensesnittet benytter arkfaner. Vi brukte Notepad++ til å lage prosjektside for prosjektet. Prosjektsiden var laget med enkel HTML og CSS. Hensikten med prosjektsiden var å samle dokumentasjon for oss selv, vår veileder og oppdragsgiver Whiteboard På gruppemøter ble whiteboard mye brukt for å holde orden på ideer og modeller som vi laget i fellesskap. Dette var en god måte og visualisere tanker rundt systemet. Disse drøftingene på whiteboard førte til konkrete planer om løsninger på ideer og sikkerhet rundt at alle gruppemedlemmene hadde den samme tanken om hva som skulle gjøres før vi førte inn i dokumentasjonen. 21

23 Prosessdokumentasjon 3.5 Kunnskap Etter nøye vurdering havnet vi på.net MVC. Vi har hatt et kurs i dette høsten 2012 så det var ikke helt nytt for oss, men vi syntes det var positivt å jobbe videre med dette siden vi har tro på at dette er et rammeverk som er ettertraktet på jobbmarkedet samt at løsningen vi leverer vil ha en fremtid etter at vi leverer det fra oss. Vi måtte bruke noe JavaScript og dette var noe vi ikke hadde kunnskap om fra før, men siden vi kun trengte JavaScript til bildebehandling så vi på det som en fin utfordring til å få et innblikk i dette skriftspråket også. Vi endte opp med å bruke JQuery som er et JavaScriptbibliotek. JQuery er det mest populære JavaScript-biblioteket i bruk så vi mente det var det beste alternativet for oss å se på. HTML, CSS og dokumentasjon har vi hatt gjennom utdannelsen på Informatikk. Dette ble en fin erfaring der vi brukte all tilegnet kunnskap i praksis. Spesielt betydningen av dokumentasjon for å holde orden på alle trådene gjennom prosjektet skulle vise seg å være nyttig erfaring. 3.6 Kommunikasjon Her beskriver vi kommunikasjonen mellom gruppemedlemmer, oppdragsgiver og veileder I gruppen Vi startet tidlig i prosessen med å avtale møter på ukebasis. Alle på gruppa har hatt kurs ved siden av hovedprosjektet så dette har vi tatt hensyn til. Møtene har vært fra 2 til 5 ganger i uken. Når vi har jobbet hver for oss har vi brukt Skype mye for å holde kontakt og avklare spørsmål med en gang. I tillegg har vi hatt en internettside til prosjektdokumentasjonen. I Dropbox har vi lagret alt av dokumentasjon i tillegg til prosjektdagbøker der vi har ført arbeidsmengde, hva som er gjort og eventuelle spørsmål. 22

24 Prosessdokumentasjon Med oppdragsgiver Svein Erik Lunde har vært vår kontaktperson hos Gilje. Ved hjelp av telefon og e-post har vi når som helst kunne spørre om noe er uklart. Kommunikasjonen har vært god og oppdragsgiver har vært klare på hva de ønsker og har gitt klart uttrykk for dette slik at vi har fått en god forståelse for Giljes ønsker. Gjennom prosjektet har vi hatt flere møter med Gilje der vi har hatt en god dialog med meningsutvekslinger og idèmyldring. Møtene var svært viktige for å diskutere løsningen vi skulle produsere gjennom hovedprosjektet Med Veileder Geir Skjevling har vært vår veileder i hovedprosjektet. I starten hadde vi møte med Geir hver onsdag, men etter noen uker ble det gjort om til ett møte hver måned. Ved henvendelser pr e- post har vi raskt fått hjelp med det vi måtte lure på. Det var en trygghet for oss å få hjelp med logiske modeller og gode innspill på den logiske virkemåten i programmeringen. 3.7 Dokumentasjon Gjennom hele prosjektet har dokumentasjon vært viktig. Prosjektet startet med å lage samarbeidsavtale[1], risikoplan[2], prosjektskisse[3] og forprosjektrapport[4]. Da vi begynte å få en god oversikt over prosjektets mål og omfang var det viktig å få på plass en god kravspesifikasjon, i tillegg til arbeidsplan[5], fremdriftsplan[6] og logiske diagrammer. Dette var styringsdokumentene vi forholdt oss til gjennom arbeidet og ved endringer fra oppdragsgiver styringsdokumentene revidert. Fra vi startet jobben med hovedprosjektet startet vi å føre arbeidsdagbøker for å lette arbeidet med å lage god sluttdokumentasjon Dokumentasjonsstandard Når vi har utviklet dokumentasjon til hovedprosjektet har vi forholdt oss til "Dokumentasjonsstandard for bachelor-prosjekter (hovedprosjekt) for Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus." Dette er dokumentasjonsstandarden vi har fått henvist og siden prosjektet vårt passer godt inn i rammene for denne dokumentasjonen har vi valgt å forholde oss til den med tilpasninger for vårt prosjekt Styringsdokumentene Styringsdokumentene ble utviklet i starten av prosjektet og var viktige dokumenter å forholde oss til gjennom utviklingen av løsingen. Endringer har forekommet, men dette har da blitt rettet opp og det er de reviderte versjonene som ligger som tillegg i sluttdokumentasjonen Samarbeidsavtale (Vedlegg 1) En kort avtale der alle gruppemedlemmene forplikter seg til å bidra i prosjektets arbeid. Avtalen definerer hva som forventes av gruppemedlemmene, 23

25 Prosessdokumentasjon Risikoplan (Vedlegg 2) Risikoplan ble satt opp etter en vurdering av forhold som kunne inntreffe og skade prosjektarbeidets fremgang. Etter samtaler rundt hva som kan skje og hva som kan gjøres for å forhindre dette ble risikoplanen skrevet for å ha forhåndsregler for å slippe unødvendige forsinkelser med arbeidet Prosjektdagbok Alle på gruppen førte prosjektdagbok. Dette ble gjort for å ha et bedre bilde av vurderinger og avveiinger som er gjort underveis og arbeidsmengde som er lagt ned. Dagbøkene ble utgangspunkt for mye av dokumentasjonen vi skrev avslutningsvis. Her kunne vi brukt TFS blant annet siden TFS har verktøy for å logge arbeid. Vi visste ikke om muligheten for loggføring i TFS på forhånd, så da vi begynte å bruke TFS var vi såpass langt ut i prosjektet at vi holdt oss til prosjektdagbøkene vi allerede var godt i gang med Prosjektskisse (Vedlegg 3) Prosjektskissen var det første dokumentet vi skrev der vi hadde en grov idé om hvilken løsning vi skulle lage. Prosjektskissen skulle være et vedlegg til samarbeidsavtalen som ble inngått mellom oppdragsgiver og Høgskolen Forprosjektrapport (Vedlegg 4) Etter at prosjektskissen var godkjent skrev vi forprosjektrapporten. Her har vi gått mer i dybden på problemet vi skulle løse. Her måtte vi foreta en analyse og komme frem til hvilke elementer oppgaven skulle inneholde, hva som var mulig for oss å rekke og hva vi måtte prioritere vekk. Forprosjektrapporten var viktig for å få på plass en fremdriftsplan og en arbeidsplan. Dessuten var den viktig utgangspunkt da vi startet på kravspesifikasjonen Arbeidsplan og fremdriftsplan (Arbeidsplan - Vedlegg 5) (Fremdriftsplan - Vedlegg 6) Nå som vi visste mer om omfanget på oppgaven kunne vi sette opp en fremdriftsplan og en arbeidsplan. Dette var viktige planer for å fordele oppgavene utover semesteret for å komme trygt i havn til fristen. Disse dokumentene var helt klart viktige for oss, men vi erfarte også at vi ikke hadde jobbet med et prosjekt av denne størrelsen før. I ettertid kan vi nok si at den tildelte tiden ble kanskje ikke helt riktig disponert uten at det skadet prosjektet, men med en bedre plan hadde nok jobben blitt mer jevnt fordelt utover. 24

26 Prosessdokumentasjon Kravspesifikasjon (Eget kapittel i sluttdokumentasjon) Kravspesifikasjonen var det viktigste styringsdokumentet vi hadde å forholde oss til. Vi brukte god tid på å utforme kravspesifikasjonen og hadde et godt samarbeid med Gilje i denne fasen. Her ble alle oppgavene tydelig definert og funksjoner ble forklart. Kravspesifikasjonen kan bli endret gjennom prosjektet, men for vår del ble det kun noen små endringer som endte i en revisjon. Dette var på bakgrunn av at medlemsportalen til Klubben skulle distanseres fra Giljes nettside slik at det ikke var linket fra Gilje til Klubben. Dermed ble også administrasjonen for booking flyttet ut for seg selv som en forlengelse av Gilje. I praksis hadde det ikke så mye å si for jobben som skulle gjøres, men det var et viktig skritt for å skille Klubben og Gilje i deres nettløsning Logiske diagrammer (Vedlagt i produktdokumentasjon) Ved arbeidet med planlegging og utforming av nettstedene måtte vi lage logiske diagrammer og modeller for å holde orden på oppbygging av arkitekturen. Underveis måtte disse endres et par ganger da vi så at førsteutkastene våre ikke virket som ønsket. Da måtte vi tilbake til modellene for å se hva som kunne endres for å få til ønsket funksjonalitet. ER-diagram var spesielt viktig for å lage en database som virket slik den skulle Skisse av layout Vi laget flere skisser av layouten for å lage den layouten vi ønsket. Dette var en prosess der vi var i dialog med Gilje som hadde konkrete synspunkter på hva de ønsket og kom med konstruktive tilbakemeldinger på forslag vi la frem. Skissene ble utformet på whiteboard, papir og i Microsoft Paint før vi til slutt laget et utkast i.net. Underveis har vi endret på detaljer og lagt til og fjernet mindre elementer, men i grove trekk har vi vært tro mot den ideen vi utformet i samarbeid med Gilje Sluttdokumentasjon Noe av sluttdokumentasjonen har blitt skrevet på gjennom prosjektet, men det meste er skrevet i etterkant av at koding er avsluttet. Mye av styringsdokumentasjonen er lagt ved som vedlegg. Dette gjelder i dokumentasjon som er beregnet på sensor og veileder for hovedprosjektet. Sluttdokumentasjonen består av 4 ulike dokumenter. I vårt tilfelle har vi laget 3 dokumenter. Dette er gjort fordi vår testdokumentasjon er del av prosessdokumentasjon og produktdokumentasjon Prosessdokumentasjon Prosessdokumentasjonen er dette dokumentet. Prosessdokumentasjonen forteller om bakgrunn og underlag for prosjektet. Dokumentet er beregnet for sensor og veileder og skal gi innblikk i hvordan gruppa har jobbet, arbeidsmåter vi har valgt, rammebetingelser, utført arbeid, hvilke verktøy som er brukt, hvilke utfordringer arbeidet har bydd på og hvilke problemer og utfordringer vi har funnet løsninger på. 25

27 Prosessdokumentasjon Produktdokumentasjon Produktdokumentasjonen er beregnet på dataansvarlig, den som skal vedlikeholde og modifisere systemet. Dette dokumentet skal inneholde informasjon om programmets oppbygging, virkemåte og funksjoner, og om hvilken testing som er gjennomført. Produktdokumentasjonen består egentlig av fire deler: den endelige kravspesifikasjonen, CDen med programmet, beskrivelsen av programmet og testdokumentasjonen for programmet. Produktdokumentasjonen er vanligvis den største delen av hovedproduktdokumentasjonen Testdokumentasjon Alle typer testing som er gjort, bør dokumenteres, enten det er det som kalles brukertesting, eller det dreier seg om feiltesting av programkoden, eller for den saks skyld funksjonstesting. Testdokumentasjonen er viktig for den som skal drifte og vedlikeholde programmet. Solid og tilstrekkelig testing gjør programmet bedre. Testdokumentasjonen leveres vanligvis som en selvstendig del av sluttdokumentasjonen. Hvis det har vært lite testing, kan den utgjøre en del av prosessdokumentasjonen. Den er ellers nært knyttet til produktdokumentasjonen. Vi har valgt å legge til kapittel om testingen i prosessdokumentasjonen og produktdokumentasjonen isteden for å produsere egen testrapport Brukerveiledning I de fleste hovedprosjekter der det finnes et dataprodukt med brukere, er det nødvendig med skriftlig brukerinformasjon. Når produktet er en webside, må det riktignok være så selvforklarende at vanlige brukere kan ta det i bruk uten videre. Men ofte er det en administrator for systemet, som skal kunne endre og redigere den informasjonen som finnes på nettsiden, og da vil det trenges noe skriftlig brukerinformasjon. 26

28 Prosessdokumentasjon 4 Om utviklingsprosessen 4.1 Analyse av suksessfaktorer for systemutviklingsprosjekt Vi satt opp en liste over faktorer som kunne ødelegge for systemutviklingen i prosjektet. Dette var for å velge en utviklingsmodell som skulle hjelpe oss å unngå klassiske feil til tross for at det er første gang gruppemedlemmene jobber med et prosjekt av denne størrelsen. Grunner til fiasko i systemutvikling: Unøyaktig forståelse av krav. Håndterer ikke endrede krav. Svak arkitektur. Programvare som er vanskelig å vedlikeholde og utvide. Oppdager sent viktige mangler i prosjektet.. Uakseptabel ytelse i programvaresystemet. Upålitelig programmering og ufullstendig testing av systemet. Upresis kommunikasjon. Subjektiv vurdering av prosjektstatus. Prosjektmedlemmer arbeider ustrukturert. Manglende risikohåndtering. Manglende konfigurasjonsstyring. Utilstrekkelig bruk av verktøy. Underminering av motivasjon Legge til flere mennesker ved forsinkelser i prosjektet. Manglende input fra bruker og uklare krav. Utilstrekkelig risikostyring. Dårlig/utilstrekkelig planlegging. Mangel på kvalitetssikring, QA (Quality Assurance) Endringer i krav underveis Teknologi Ved å kjenne til risikoer og faktorer som kan velte prosjektet kunne vi velge utviklingsmodell og gjøre tiltak for at vi skulle være rustet for oppgaven vi skulle løse. 4.2 Valg av systemutviklingsmodell I planleggingsfasen måtte vi bestemme oss for en utviklingsmodell vi skulle følge. Vi valgte å bruke "Scrum" i utgangspunktet. Dette var viktig for å jobbe målrettet ut fra en metode der produktet ble utviklet gjennom sykluser. Hver syklus endte i et produkt som kunden kunne evaluere og gi tilbakemeldinger på. I praksis var vi ikke i dialog med kunden etter hver syklus, men arbeidet ble betydelig lettere ved å konsentrere oss om en del av gangen og gjøre den ferdig før vi gikk videre til neste del. Vi regnet med at kravspesifikasjonen kunne bli endret fra første utkastet slik at vi måtte være forberedt på nye eller endrede krav. Da ville vi få problemer med en tyngre systemutviklingsmodell. 27

29 Prosessdokumentasjon Smidig utvikling Agile utviklingsmetoder, eller smidige utviklingsmetoder som det heter på norsk, er en gruppe systemutviklingsmetoder som vektlegger utvikling av krav og løsninger underveis i utviklingsprosessen, gjennom en iterativ og inkrementell tilnærming. Det vil si at utviklingen går gjennom en syklus der det vektlegges å skape fungerende programvare, som for hver iterasjon blir vurdert opp mot det klienten ønsker, og styrt i den retningen. Dette gjør at prosessen er mer responsiv for endringer underveis. Metoder som Scrum og Extreme Programering ble utviklet på 90-tallet. Fra før var tyngre metoder som Fossefallmodellen og Universal Process blant de brukte metodene. Disse var tyngre, regeltunge og dokumentbaserte metoder å jobbe etter som gjerne passet svært store prosjekter godt, men som ikke var godt tilpasset mindre prosjekter. Nye, smidige metoder ble utviklet for å skape god fremdrift og være mer responsiv i mindre prosjekter. 28

30 Prosessdokumentasjon Scrum SCRUM er en agil utviklingsprosess som ønsker å ha så lite dokumentasjon og byråkrati som mulig. SCRUM kan oppsummeres som følger: 1. Prosjektgruppa og oppdragsgiverne lager en prioritert liste over alt som gruppen skal gjøre. Dette skal være en liste over aktiviteter eller en liste over funksjoner som systemet skal inneholde. Denne lista kalles produktlogg, altså en kravspesifikasjon. 2. Periodevis vil gruppa hente inn anslagsvis 30 dagers arbeid fra toppen av produktloggen. Denne arbeidsmengden ekspanderes til en detaljert aktivitetsliste som kalles sprintloggen. Når sprintloggen er bestemt er det ikke lov til å legge til mer eksternt initiert arbeid til denne. 3. Sprint er en for eksempel 30 dagers periode (kortere periode er tillatt) hvor utviklingsgruppen utvikler det som ligger i den tilhørende sprintloggen. En sprint er altså en iterasjon innen utviklingsforløpet. 4. Hver dag møtes prosjektgruppen ansikt til ansikt i fem til ti minutter for å oppdatere hverandre om status og om hindringer som senker fremdriftshastigheten. Dette kalles Den daglige scrum, og er et stående møte. Her vektlegges kommunikasjon mellom deltagerne med fast bestemte spørsmål. 5. En person har fått tildelt tittelen Scrum master. Denne personen skal sørge for at hindringer som påpekes under det stående møtet fjernes. Scrummasteren kan betraktes som en forenklet prosjektleder. 6. Demo er programvare som kan eksekveres og som kan demonstreres eller leveres kunden. Prosjektgruppen lover å demonstrere, eller levere resultatene ved utgangen av de 30 dagene, altså etter at sprinten er over. 29

31 Prosessdokumentasjon Avvik fra tradisjonell Scrum På grunn av oppgavens omfang og prosjektets tidsperspektiv har det vært naturlig for oss å ha kortere sprinter enn 30 dager. Sprintene har hatt varierende lengde fra 1 til 3 uker med utgangspunkt i de oppgaver som skal løses. Vi har ikke hatt den daglige scrum hver dag. Dette har vært etter behov, men minimum en gang i uken. 4.3 Faser Scrum er delt inn i 4 faser. Her presenteres fokus og arbeid i de enkelte fasene: Planlegging I planleggingsfasen var fokuset på å etablere visjon, forventning og sørge for ressurser. I denne fasen skaffet vi oppdragsgiver, skaffet oss et overblikk over produktet vi skulle lage og skaffet oss en oversikt over at vi hadde ressursene vi trengte til å gå løs på oppgaven. Vi laget en overordnet kravspesifikasjon en grov framdriftsplan for å vurdere om dette var et prosjekt vi kunne gå videre med. I planleggingsfasen hadde vi følgende aktiviteter: Gantt-diagram, verktøyliste og fremdriftsplan[6], i tillegg til overordnet kravspesifikasjon og enkel use case-modell Forbereding I denne fasen gikk vi grundigere til verks identifisere krav. Vi måtte beskrive funksjoner og gjøre begrensninger for å lage et godt bilde på hva vi skulle lage. Fasen avsluttes med at det foreligger en detaljert kravspesifikasjon som inneholder alt vi trenger for å starte selve utviklingen av produktet. I forberedingsfasen hadde vi følgende aktiviteter: aktivitetsdiagram, sekvensdiagram og klassediagram, i tillegg til videre arbeid med use case og kravspesifikasjon. Det forekom også justeringer av aktiviteter fra idéfasen. Arbeids- og fremdriftsplan[6] ble utarbeidet. I begynnelsen av forberedingsfasen hadde vi en risikovurdering med tiltak for å unngå risikoene Utvikling Nå kunne vi gå løs på selve utviklingen med utgangspunkt i kravspesifikasjonen vi laget i forberedingsfasen. Fortsatt kan endringer i kravspesifikasjon komme, men dette er greit å fange opp og justere seg etter da utviklingsfasen foregår i sprinter der vi henter en iterasjon fra sprintloggen som igjen er hentet fra produktloggen som er laget ut fra kravspesifikasjonen. Kravene er nå bestemt, men må revideres ved behov. Denne fasen består for det meste av koding og testing. Konstruksjonsfasen bestod av følgende aktiviteter: brukergrensesnitt og logisk arkitektur, i tillegg til revidering av tidligere aktiviteter. 30

32 Prosessdokumentasjon Frislipp I frislipp-fasen består av beta-testing før vi etterhvert kunne ferdigstille og publisere produktet. Ettersom vi har testet gjennom utviklingsfasen bør det ikke være store feil eller mangler, men om det er feil eller mangler må disse oppdages før ferdigstillelse. Fasen avsluttes med dokumentasjon og overlevering til oppdragsgiver. 31

33 Prosessdokumentasjon 5 Testing Med tanke på kompleksiteten til nettløsningen vi utviklet bestem vi oss for at vi hovedsaklig skulle holde oss til enhetstesting gjennom utviklingen og avslutte med noe brukertesting. Vi vurderte å utvikle automatiske tester, men fant ut at dette ikke var nødvendig for en såpass liten løsning med isolerte funksjoner. Vi utviklet to løsninger som ikke inneholdt mange eller veldig avanserte funksjoner. Funksjonene stod i stor grad for seg selv så det var naturlig å teste funksjonene ettersom man utviklet. Testingen ble utført manuelt av utvikler og det var et krav at vi ønsket å ha funksjoner som virket helt eller delvis før vi sjekket inn til TFS. Med delvis menes at det ikke skal lastes opp funksjoner som er så uferdige at de fremkaller feil som gjør at prosjektet ikke kan kjøres. Påbegynt funksjon skulle være ferdig før ny funksjon skulle startes på. Vi forsøkte i størst mulig grad at utvikleren som hadde påbegynt en funksjon skulle gjøre denne ferdig da det ville koste tid for en annen utvikler å sette seg inn i den ufullstendige koden. Når en funksjon ble gjort ferdig ble dette annonsert til alle gruppemedlemmene slik at alle kunne teste funksjonen og komme med tilbakemeldinger om eventuelle mangler eller forbedringer som kunne gjøres. Da vi var ferdig med utviklingen hadde vi sporadiske brukertester. Vi lot venner og kjente teste siden i henhold til et testskjema. Hensikten var å la utenforstående bruke nettsiden for å løse oppgaver der de ulike funksjonene ble tatt i bruk og at navigasjonen var brukervennlig. Dette var et viktig ledd i test av brukervennligheten og vi fikk gode tilbakemeldinger som vi tok tak i da vi skulle finpusse på prosjektet. Brukertestene var nyttige da vi fikk personer med varierende datakunnskaper til å vurdere løsningene vi hadde laget. Eksempel på utfylt testskjema ligger som vedlegg[7]. 32

34 Prosessdokumentasjon 6 Kravspesifikasjon og dens rolle I dette kapittelet tar for seg utvikling av kravspesifikasjonen, endringer som ble gjort underveis og betydningen av kravspesifikasjonen ved utvikling av design og implementering. Avslutningsvis konkluderer vi med samsvaret mellom kravspesifikasjonen og det endelige produktet. Kravspesifikasjonen var det viktigste styringsdokumentet vi hadde å forholde oss til under utviklingen så vi la mye jobb i å få på plass en god kravspesifikasjon i samarbeid med kunden. 6.1 Utarbeiding av kravspesifikasjon Allerede under forprosjektet utviklet vi en grov skisse av kravspesifikasjonen. Vi utvidet og spesifiserte denne gjennom forberedingsfasen for å få på plass en kravspesifikasjon som inneholdt det vi trengte av informasjon for å modellere og utvikle systemet. Under denne prosessen var vi i kontakt med oppdragsgiver flere ganger. Oppdragsgiver hadde en ide om hva de ønsket seg og gjennom flere reviderte utgaver fikk vi en kravspesifikasjon som gjenspeilet oppdragsgivers ønsker og som ble et konkret rammeverk for vårt utviklingsprosjekt Endring av versjon Gjennom utarbeidelsen av kravspesifikasjonen utvidet vi stadig kravspesifikasjonen for at den skulle være så konkret som mulig. Etter at vi ble ferdig med kravspesifikasjonen har vi heldigvis bare hatt en større endring. Da vi var i gang med koding av prosjektet ble det bestemt av oppdragsgiver at de ikke ønsket å blande og portalen til Klubben. og portalen til Klubben var planlagt med forskjellig design, men innlogging skulle være fra Gilje Selskapslokaler. Oppdragsgiver ønsket imidlertid ikke at skulle reklame for Klubben og deres medlemskap selv om de er eiere av. Dermed skulle dette skilles markant ved at man benyttet to forskjellige domener til sidene. I praksis ble ikke dette et stort problem, men tilgangen til nettstedene ble jo da gjort om. Den største forskjellen ble at vi valgte å skille ut administrasjonsdelen for til en egen side. Dermed ble nettstedene helt skilt som to frittstående prosjekter. Vi hadde dessuten et punkt i kravspesifikasjonen som ble fjernet mot slutten av utviklingsprosessen: " Det er ønskelig å få hente meny fra Mathilde.no til en side på Gilje's nettside. " Dette punktet ble fjernet etter at Gilje allikevel ikke ønsket denne funksjonen av andre grunner enn for oppgaven. Vi erstattet da menyen med en link til MatHilde som oppdragsgiver ønsket. 33

35 Prosessdokumentasjon 6.2 Samsvar med kravspesifikasjon Når vi ser på produktet og sammenligner det opp mot kravspesifikasjonen ser vi at vi i stor grad har lykkes med å utvikle det produktet oppdragsgiver ønsket. Kravspesifikasjonen har vært rettesnor for oss gjennom prosjektet for å sikre nettopp dette. 6.3 Avvik fra kravspesifikasjon Krav til hjemmeside -, Gilje ønsker at brukere som besøker nettsiden skal få svar på: o Drikke / alkohol o Målgruppe o Kapasitet o Standard leieavtaler Her er det noen mangler i forhold til informasjon som ligger på nettsiden. Alt skriftlig til nettstedet skal Gilje sørge for så dette er ikke noe vi kan ta på oss. Dette er informasjon som Gilje sikkert vil legge til selv når de overtar løsningen Designmål reservasjon - " Det skal være farger for de datoene som er ledige, opptatte eller delvis opptatt. Det skal være lett for bruker å fort oppfatte hva de forskjellige fargene betyr ved hjelp av en beskrivelse ved kalenderen." Her er fargeindikasjonen blitt enklere enn kravspesifikasjonen sier. Kalenderen markere dato og tid da det foreligger en reservasjon, men det gis ingen informasjon om dette gjelder hele lokalet. Dette kan gjelde en etasje mens den andre etasjen er ledig. Fargen på markeringen er lik uansett om lokalet er utleid for noen timer eller hele dagen. Dette kommer derimot godt frem rent visuelt siden markeringen i kalenderen markerer det aktuelle tidsrommet Designmål reservasjon - " Bruker skal få bekreftelse på e-post om hvilke valg og forespørsel kunden har gjort til administrator." Dette punktet valgte vi bort da vi mente at bekreftelse på skjermen ville være bra nok. 34

36 Prosessdokumentasjon 7 Konklusjon Prosjektet har vært utfordrende og spennende for oss. Vi har fått prøvd oss i en rolle der alle tilegnede kunnskaper fra studiet skulle benyttes. Vi har oppdaget nytten av god planlegging, modeller, diagrammer og rammer for å nevne noe. Vi har nok også merket at vi har undervurdert prosesser i utviklingen så vi har fått dårlig tid og feilberegnet vanskelighetsgrad på andre deler. En nyttig erfaring som minner oss på at vi er langt fra ferdig utlært etter 3 år på høgskole. Da vi startet på prosjektet hadde vi mange løse tråder og hadde på ingen måte et godt bilde av produktet vi skulle ende opp med. Gjennom fornuftig prosjektering med modelleringer og beskrivelser av de forskjellige funksjonene og kravene så vi at etter hvert et klarere bilde av løsningen. Det var spennende å jobbe med systemutviklingen over en lengre periode og på et noe større prosjekt og se at vi klarte utfordringen vi tok på oss. Vi har fått mange erfaringer gjennom hovedprosjektet og hadde nok gått løs på prosjektet på en annen måte om vi hadde gjort det igjen. Vi løste det for så vidt på en tilfredsstillende måte, men mer tanke på dokumentasjon under utviklingsfase, bedre tid til testing og bedre skisser på designet fra starten av hadde nok spart oss for en del etterarbeid, dårlig tid med testing og hatt mindre tidsbruk på designvalg. Tilbakemeldingene vi har fått fra oppdragsgiver har vært gode. Nettløsningen til Gilje Selskapslokaler er allerede i bruk og har vært et viktig ledd i markedsføringen de har satt i gang etter omfattende oppgradering av lokalene. Det ligger an til at medlemsportalen til Klubben vil være i drift i løpet av sommeren. 35

37 Prosessdokumentasjon 8 Referanser Systemutvikling (Applikasjoner og databaser) Thor E. Hasle (Forfatter) Databasesystemer, 2. Utgaver Bjørn Kristoffersen (Forfatter) Forelesingsnotater fra kurset "Webapplikasjoner" Av Tor Krattebøl. Forlesningsnotater fra kurset "Systemutvikling" av Anne Helga Seltveit 36

38 Prosessdokumentasjon 9 Vedlegg 9.1 Samarbeidsavtale 37

39 Prosessdokumentasjon 9.2 Risikoplan Risikoplan Når man jobber med et prosjekt er det flere faktorer som kan påvirke utfallet av prosjektet. Risikoer som kan oppstå: Sykdom/fravær Motivasjon Uenighet og konflikter Faglige problemer Tekniske problemer Tid Endring av prosjektkrav Lav deltagelse fra kundens side Feilprioriteringer Hva som kan gjøres for å unngå at risikoen(e) oppstår: Sykdom/fravær: For å unngå forsinkelser o.l. pga. sykdom eller annet fravær, kan det være lurt å fordele arbeidsoppgavene jevnt innad i gruppen. Siden vi bruker TFS og Dropbox har alle på gruppen tilgang til dokumenter o.l. som resten av gruppen har skrevet. Så dersom et av gruppemedlemmene er borte på et møte, kan resten av gruppen fortsette på det arbeidet som måtte ønskes. Motivasjon: Minst èn gang i uken har vi gruppemøter. For å kunne holde motivasjonen oppe er det viktig at vi har noe å snakke om på disse gruppemøtene, så vi ikke bare møtes uten grunn. Vi må ha konkret delmål å strekke oss etter. Uenighet og konflikter: Dersom det oppstår uenigheter eller konflikter innad i gruppen, bør dette tas opp snarest/umiddelbart. Slik det står i samarbeidsavtalen vår også, at dersom det er noe gruppen ikke blir enige om, skal det holdes avstemning. Faglige problemer: Det er viktig å være nøye på at de målene vi setter for prosjektet, er i forhold til de faglige kunnskapene gruppen har. En del ny kunnskap kan vi tilegne oss, men vi må ta utgangspunkt i hva vi kan. Dersom det er noe noen på gruppen lurer på eller trenger hjelp til, skal resten av gruppen prøve å hjelpe til. 38

40 Prosessdokumentasjon Tekniske problemer: Tap av data er den verste risikoen, selv om det er liten sannsynlighet for at det kan skje, er det den risikoen som kanskje får størst konsekvens for gruppen. Siden vi bruker av TFS og Dropbox har alle tilgang til alle dokumenter som legges ut, dette kan være til hjelp for å unngå at ting går tapt siden de er lagret flere steder. Tid: For å unngå forsinkelser pga sykdom eller annet, kan man for eksempel være nøye på at det ikke bare er én som gjør alt på ett av områdene. Det er viktig å holde tidsfristene som er satt i fremdriftsplanen[6], hvis ikke kan frister kollidere og gruppen ender opp med å måtte gjøre ferdig flere oppgaver til samme frist. Viktig at fristene i fremdriftsplanen[6] også er satt i forhold til mengde arbeid. Endring av prosjektkrav Endringer av kravspesifikasjon er noe man må regne med i et prosjekt på denne størrelsen. For å håndtere dette bør vi ha hyppige iterasjoner, endelige frister og høy frekvens av gode dialoger. Lav deltagelse fra kundens side Deltagelsen fra kundens side vil variere fra prosjekt til prosjekt. Faktorer kan også være kundens ressurser og kunnskap om prosjektet. Ved å gjøre klare avtaler med kunden og ha en fast kontaktperson sikrer vi en god dialog og deltagelse fra kunden. Feilprioriteringer Det kan være fort gjort å gjøre feilprioriteringer. For å unngå dette må vi gjøre klare avtaler om ansvar, tidsbruk og milepæler. Dette må følges opp underveis og endres i takt med framgang og endringer i krav. 39

41 Prosessdokumentasjon 9.3 Prosjektskisse Prosjekt - hjemmeside med portal løsninger Gilje har en lang historie som selskapslokaler i Askim. Det benyttes til bryllup, jubileer, begravelser, møter etc. Selskapet ar et AS og heleid av Klubben som er en medlemsklubb hvor det blant annet spilles bridge. Catering selskapet, MatHilde, har etablert seg i lokalene og skal samarbeide med Gilje om arrangementer. Hjemmesiden skal dekke følgende formål 1. Markedsføring av Gilje for utleie av lokaler 2. Vurdere en integrering/felles hjemmeside MatHilde og Gilje. 3. Etablere elektronisk booking system a. Utleie av lokaler (Gilje) b. Catering/leveranser 4. Integrere portal løsninger knyttet til: a. Klubbens egne aktiviteter eks. medlemslister, aktiviteter/program, historisk arkiver, møte protokoller, regnskap etc. b. For tjeneste ytere eks. serverings hjelp for registrering/rapportering av timelister Status IT løsninger i dag 1. Gilje har ingen hjemmeside 2. Mathilde som driver catering virksomhet har i dag hjemmeside Organisering 1. Gilje/Klubben utpeker 2 personer som bistår i utarbeidelse av kravspesifikasjon 2. Det gjennomføres prosjektmøter i Askim eller elektronisk ved behov 3. MatHilde peker ut en person som bistår event. Inngår i prosjekt gruppe med Gilje/Klubben om dette er aktuelt 4. Det fastlegges en prosjektplan med et omfang som samsvarer med innlevering av case til HIO Kontaktpersoner Gilje/Klubben: 1. Anders Fransson tlf

42 Prosessdokumentasjon 41

43 2013 Prosessdokumentasjon Hovedprosjekt 2013 Gruppe Forprosjektrapport [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie 42

44 Prosessdokumentasjon Innhold 1. Presentasjon Sammendrag Dagens Situasjon Mål og rammebetingelser Løsning Analyse av løsning Konklusjon

45 Prosessdokumentasjon 1. Presentasjon Tittel: Oppgave: Gruppemedlemmer: Gilje AS Lage en nettløsning for presentasjon, kontakt og bookingforespørsel for. Lars Gjestang, s Hiran Piapo, s Bård Skeie, s Prosjektgruppe: Gruppe 27 Veileder: Oppdragsgiver: Kontaktpersoner: Geir Skjevling AS Anders Fransson, Per Christian Arnfinsen og Svein Erik Lunde 2. Sammendrag Gilje har en lang historie som selskapslokale i Askim. Det benyttes til bryllup, jubileer, begravelser, møter etc. Selskapet er et AS og heleid av Klubben som er en medlemsklubb hvor det blant annet spilles bridge. Catering selskapet, Mathilde, har etablert seg i lokalene og skal samarbeide med Gilje om arrangementer. Prosjektet skal gjennomføres som hovedprosjekt ved HiOA. Vår oppgave er å utvikle et nettsted for Gilje. Nettstedet skal gi informasjon om Gilje AS, deres utleielokale, Mathilde og bookingmuligheter. Brukere kan sende bookingforespørsel via nettsiden samt forespørsel om tilleggstjenester ved leie. I tillegg skal medlemmer/ansatte tilhørende Gilje ha mulighet til å logge inn på en portal med tildelte brukerrettigheter. Her skal det også være mulighet for å lagre og søke i dokumenter. 3. Dagens Situasjon Situasjonen i dag er at Mathilde har egen nettside, men Gilje har ingen nettløsning for informasjon eller booking av lokalet. Gilje leier i dag ut lokalet etter avtale over telefon eller i person, men dette er et tungvindt system som også krever noe tid siden kundene ikke kan finne informasjon på nettet. Mathilde har egen nettside, men både Gilje og Mathilde vil tjene på at selskapene promoteres på hverandres nettsider. 4. Mål og rammebetingelser Målet med denne oppgaven er å lage et nettsted for. Nettstedet kan deles i to hoveddeler: 1 - Informasjon og booking for besøkende på nettsiden. 2 - Portal for ansatte/medlemmer av Gilje for informasjon og administrering av utleie. Den første delen skal inneholde: kalender som viser bookingstatuser 44

46 Prosessdokumentasjon bildegalleri info meny kontakt oss Levende bildeshow link til medlemsside Del to skal inneholde: Portal for medlemmer med tildelte grupperettigheter Database for dokumenter, møtereferat, selskapssanger m.m. Sanger og dokumenter skal være søkbare Selve bookingen er ønskelig å ha pr telefon for å ha en manuell kontroll på hva lokalet leies ut til, men booking-forespørsel og informasjon på nettet vil gjøre at kundene vet mer om lokalet og mulighetene for tilleggstjenester før de tar kontakt. I tillegg ønsker Gilje å implementere Mathilde sin meny på nettsiden. Vi ønsker at nettsiden skal være kompatibel med MS Internet Explorer, Mozilla Firefox og Google Chrome som et minimum. 5. Løsning Vi har valgt å utvikle nettstedet ved bruk av ASP.NET MVC, JavaScript og SQL. Vi har valgt ASP.NET MVC side vi har vært innom det tidligere, men syntes det er interessant og viktig å sette seg bedre inn. ASP.NET er et kraftig verktøy som gir mange muligheter og er mer etterspurt enn PHP i dag. Dessuten får vi da en lagdelt applikasjon som er ryddig for andre som skal vedlikeholde eller videreutvikle nettstedet etter at vi har gitt den fra oss. Vi regner med at vi må bruke en del JavaScript til å få til en del av funksjonaliteten som f.eks. bildeshow. Utviklingsprogram: Visual Studio 2012 Teknologi: ASP.NET MVC, SQL, JavaScript Database: SQL Server Programmeringsspråk: C#, ASP.NET, Javascript Andre programmer: Skype, TeamViewer 8, MS Word, MS Excel, FileZilla, MS PowerPoint Etter avtale med oppdragsgiver vil vi skaffe domene for nettstedet. 45

47 Prosessdokumentasjon 6. Analyse av løsning Vi diskuterte en del før vi valgte å utvikle nettsiden i PHP. Valget stod mellom ASP.NET og PHP. PHP har mange muligheter og stod som et godt valg til oppgaven. Derimot mener vi at ASP.NET har mange fordeler og er et veldig kraftig verktøy med mange muligheter. ASP.NET er også veldig etterspurt i dag og flere og flere nettsteder utvikles med ASP.NET. Derfor syntes vi det var riktig å utvikle siden med nettopp ASP.NET både for egen læring og at oppdragsgiver skal få et godt og levedyktig produkt. 7. Konklusjon Vi tror nettstedet vil få Gilje AS mer synlig for nye kunder, samt et sentralt punkt der eksisterende brukere kan gå inn å hente informasjon og dokumenter. Hensikten er at systemet vårt skal: Øke informasjon og tilgjengelighet for potensielle kunder av Gilje AS. Lette bookingprosessen og gi økt utleie av lokalet. Samle administrering og dokumentasjon på ett sted. Gi mer og bedre informasjon for brukere tilknyttet lokalet. Lars Gjestang Bård Skeie Hiran Piapo 46

48 Prosessdokumentasjon 9.5 Arbeidsplan Aktivitet Beskrivelse Ferdig Planlegging Statusrapport Levere statusrapport. Lete etter aktuelt prosjekt Prosjektskisse Bestemme prosjekt. Levere prosjektskisse Gruppeside Lage gruppeside for prosjektets dokumentasjon Forprosjektrapport Lage forprosjektrapport til prosjektet Arbeidsplan Lage oversikt over alt som skal gjøres med tidsfrist Fremdriftsplan Lage oversikt over hva som skal gjøres når Risikohåndtering Hva kan gå galt - tiltak Kravspesifikasjon Lage utkast Lage forslag til detaljert kravspesifikasjon Gjennomgang med Gilje Verifisere krav Kravspesifikasjon Detaljert kravspesifikasjon Forberedelse Prototyping Prototype design Modellering Lage design Utvikling Sprintmøte Hva har blitt gjort, skal gjøres og hvilke hinder? Hver uke Lage database Database for hele løsningen Lage design Hovdedesign for nettstedet Frontend Lage brukerside av systemet Backend Lage administratorside av systemet Test av nettside Hva virker? Hva mangler? Forbedringer? Gilje? Forbedring Finpuss og oppretting av feil/mangler Ferdigstille nettsted Siste endringer og klargjøring. Settes i drift Testing Funksjonstesting/Enhetstesting Teste deler av program/nettsted Kontinuerlig Systemtesting Helhetlig test av nettstedet Akseptanse testing Test gjøres av systemeiere/brukere/kunde Dokumentasjon Dagbok Arbeidslogg for hver enkelt og prosjektet Kontinuerlig Drifte hjemmeside Laste opp nye dokumenter og ajourføre Kontinuerlig Sluttdokumentasjon Prosess-, produkt-, tekst- og brukerdokumentasjon Presentasjon Forberede muntlig presentasjon ( juni)

49 Prosessdokumentasjon 9.6 Fremdriftsplan 48

50 Prosessdokumentasjon 9.7 Eksempel - Brukertestskjema 49

51 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie

52 Kravspesifikasjon 51

53 Kravspesifikasjon Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt som skal gjennomføres ved Høgskolen i Oslo og Akershus for Informasjonsteknologiavdeling i samarbeid med Gilje AS. Prosjektet går ut på å utvikle en nettløsning for. Nettløsningen skal inneholde en presentasjon av selskapet, deres lokaler, Mathilde og et reservasjonssystem. Nettløsningen skal inneholde en admin-portal der ledere og ansatte kan administrere nyheter, bilder og forespørsel. Videre skal vi utvikle en portal for medlemmer/brukere tilhørende Klubben som får tilgang til dokumenter, sanger, nyheter etc. fra en database. Vi vil utvikle systemet ved hjelp av MVC.NET. 1.2 Om Gilje Gilje har en lang historie som selskapslokale i Askim. Det benyttes til bryllup, jubileer, begravelser, møter etc. Selskapet er et AS og heleid av Klubben som er en medlemsklubb hvor det blant annet spilles bridge. Gilje har et samarbeid med cateringselskapet, MatHilde, som står for booking, servering og daglig ansvar for utleie. 1.3 Bakgrunn for prosjektet Situasjonen i dag er at Mathilde har egen nettside, men Gilje har ingen nettløsning for informasjon eller bestilling av lokalet. Gilje leier i dag ut lokalet etter avtale over telefon eller i person, men dette er et tungvindt system som også krever noe tid siden kundene ikke kan finne informasjon på nettet. Mathilde har egen nettside, men både Gilje og Mathilde vil tjene på at selskapene promoteres på hverandres nettsider. Klubben har ingen nettside, men har ønske om en portal der medlemmer kan logge inn og få tilgang til dokumenter og nyheter som kun angår medlemmer. Ønsket er at Gilje skal få en nettløsning som promoterer, gir god informasjon til potensielle kunder, og blir en felles database for medlemmer av Klubben. 52

54 Kravspesifikasjon 2 Forord 2.1 Forord Denne kravspesifikasjonen beskriver betingelse for prosjektet "". Kravene til funksjonalitet og rammebetingelser er beskrevet i dette dokumentet. Hovedkravene om funksjonalitet og design er gitt av Gilje AS, men hvordan prosjektet spesifikt og best mulig skal løses har prosjektgruppa styrt selv. Siden prosjektet omhandler to nettsteder vil vi bruke arbeidstitlene "" og "Klubben". I utgangspunktet var hele løsningen samlet under arbeidstittelen "Gilje Selskapslokaler", men har i ettertid blitt delt i to separate deler av oppdragsgiver. Dette fikk liten praktisk betydning for utviklingen, men en del av dokumentasjonen kan bære preg av delingen. 53

55 Kravspesifikasjon 3 Innhold 1 Presentasjon Innledning Om Gilje Bakgrunn for prosjektet Forord Forord Innhold Systemkrav Funksjonskrav Klubben Teknisk krav Datalagring Krav til datalagring Krav til design Design mål Generelle designmål Klubben Kode Krav til kode Dokumentasjon Krav til dokumentasjon Eventuelle krav til sikring mot tap av data

56 Kravspesifikasjon 55

57 Kravspesifikasjon 4 Systemkrav 4.1 Funksjonskrav Her tar vi for oss funksjonskravene til nettløsningen vi skal lage. Løsningen er delt i to deler som skal virke uavhengig av hverandre. Funksjonskravene er derfor fordelt under henholdsvis "" og "Klubben" som vi bruker som prosjektnavn for løsningene. I utgangspunktet var dette èn løsning, men den ble delt i to løsninger halvveis i prosessen. Derfor er kravspesifikasjonen felles Krav til hjemmeside - 1. Siden skal være strukturert og ryddig slik at det er lett for kunder å finne og navigere seg frem. 2. Den statiske delen av siden skal bestå av en logo i toppen av siden og en menylinje under som gjør det enkelt for brukeren å finne fram på siden. 3. På forsiden skal det være en seksjon for levende bildeshow av lokalet. 4. Reservasjonssystem skal bestå av kalender oversikt over ledige dato. Her kan kunden velge den dato som passer og sende en forespørsel om utleie. Ved forespørsel vil det være en vanlig opplysningsregistrering av vedkommende og ikke minst formål med utleie. Forespørsel vil bli sendt pr e-post og vil bli behandlet manuelt av ansatte. 5. Administrasjon av reservasjoner trenger ikke være en del av nettsiden. Dette kan gjøres på annen måte så lenge det jobber mot samme database som nettsiden benytter til å vise status på datoer/reservasjoner 6. Det vil være en link til Mathilde.no på siden hvor kundene kan få oversikt over matmenyer og andre delikatesser. 7. Gilje ønsker at brukere som besøker nettsiden skal få svar på: Tilgjengelighet Hvordan få besiktiget Hvordan ser fasilitetene ut (Godt bildegalleri ute/inne ) Parkering Offentlig transportmidler (kart) HC tilgjengelighet Meny Serveringsopplegg Drikke / alkohol Målgruppe Kapasitet Standard leieavtaler Kontakt info Giljes historie 56

58 Kravspesifikasjon Krav til administrasjonsside - 1. Administratorsiden skal det være for administrasjon av nyheter og bilder til galleri. 2. Administrator skal kunne legge til og slette nyheter og bilder. 3. Administrator skal kunne legge til og fjerne ytterlige administratorer. 4. Administrator skal kunne forandre passord. 5. Ved glemt passord skal passordet sendes på e-post Krav til administrasjon av reservasjoner - 1. Administrasjon av reservasjoner trenger ikke gjøres på nettsiden, men må jobbe mot samme database som nettsiden benytter til å vise status på datoer/reservasjoner. 2. Administrasjon av reservasjoner kan gjøres på en egen nettside, men må ha sikkerhet i form av brukernavn og passord 3. Brukeren/Administratoren av reservasjonssiden skal ha mulighet til å endre passord. 4. Administratoren skal kunne legge til / fjerne / endre reservasjoner. 5. Ved glemt passord skal passordet sendes på e-post Klubben Krav til medlemsportal - Klubben 1. Medlemsportalen skal ligge på eget domene. Det skal ikke linkes fra hjemmesiden til Gilje til medlemsportalen. 2. Portalen skal ha pålogging med brukernavn og passord. 3. Det skal også være mulig for administrator å logge på siden for vedlikehold og administrasjon av siden, brukere, dokumenter og områder. 4. Dokumenter skal kunne lagres og søkes opp gjennom database. 5. Dokumenter skal kunne arkiveres predefinerte grupper (f.eks.: Sanger, møtereferat..) 6. Referater fra møter skal kunne sorteres på dato. 7. Sanger skal kunne lagres i grupper som hører sammen (f.eks.: selskapssanger, sanger til maten, etc..) 8. Det skal være mulig å hente ut en medlemsliste. 9. Ved innlogging skal medlemmet få en oversikt/presentasjon av nyheter/meldinger som angår medlemmer av Klubben. 10. Brukere skal ha et tilgangsnivå som gir de tilgang til det de trenger. For eksempel trenger ikke alle ha tilgang til møtereferater. 57

59 Kravspesifikasjon Krav til administrasjon - Klubben 1. Administratorsiden skal det være for administrasjon av dokumenter, medlemslister, møtereferater og områder. Administrator skal kunne legge til, gjøre endring og sletting her. 2. Administrator skal kunne legge til og fjerne nyheter som medlemmer får presentert ved pålogging. 3. Administrator skal kunne legge til og fjerne predefinerte dokumentgrupper/områder. 4. Predefinerte grupper som inneholder dokumenter skal ikke kunne fjernes. 4.2 Teknisk krav 1. Programmet som skal brukes er Microsoft Visual Studio Utvikles med C# i MVC Det skal brukes JavaScript for å gjøre brukeropplevelse bedre. 4. Lagring av data vil skje i MS-SQL. 5. Nettsiden skal driftes på en Windows-server. 4.3 Datalagring Krav til datalagring 1. All data som skal lagres eller hentes foregår i en MS-SQL-database på serveren. 2. Validering av data skjer før innsetting, både i inputfeltene og i databasespørringene. Dette er et krav om god sikkerhet med tanke på sql-injections. 3. Alle data skal passordbeskyttes og det er kun brukere som har rettigheter og tilgang til forskjellige data. 4. MS-SQL-databasen skal være bygd opp med krav om normalisering. 58

60 Kravspesifikasjon 5 Krav til design 5.1 Design mål Generelle designmål 1. Brukere skal kunne behandle og forstå hver eneste del av siden personen har tilgang til, uten å trenge datakunnskaper. 2. Det meste av design skal kodes i CSS og ikke direkte inn i cshtml-filene. Dette blir mer oversiktlig for eventuelle andre som overtar koden samt at designet blir konsekvent. 3. Designet skal være svært ryddig, pent og oversiktlig. Det skal være behagelig å se på bilder samt at det ikke skal være forstyrrende å lese tekst. 4. Øverste del av siden skal være statisk, med logo og menylinje. Dette sikrer enkel navigering på siden. 5. Ved å klikke på et menyvalg i toppen av siden kan brukeren få ytterlige valg tilgjengelig på venstre side av hovedsiden om det trengs for å katalogisere informasjon som hører til under menyvalget. 6. Linker skal navngis på norsk for enkel navigering. 7. Målgruppen forventes å være norsk så det er ikke planlagt oversettelse av siden Designmål reservasjon - Reservasjonen skal se ut som stor kalender som man kan se hvilke datoer og tider som er tilgjengelige. Det skal være farger for de datoene som er ledige, opptatte eller delvis opptatt. Det skal være lett for bruker å fort oppfatte hva de forskjellige fargene betyr ved hjelp av en beskrivelse ved kalenderen. Kalenderen skal være godt forståelig og skal sende bruker til et kontaktskjema hvis personen klikker på en dato. Kalenderen skal ikke være en automatisk reservasjon, men det skal være en oversikt for administrator og brukere for å vite hvilke datoer som er opptatt og hvilke datoer man kan sende en forespørsel om. Bruker skal få bekreftelse på e-post om hvilke valg og forespørsel kunden har gjort til administrator Designmål administrasjon av reservasjoner - 1. Siden skal være så enkel som mulig. Brukeren/administratoren skal møtes av en enkel innlogging med brukernavn/passord forespørsel. 2. Når brukeren/administratoren er logget inn skal han/hun se kalenderen med mulighet for å legge inn reservert, delvis reservert eller opphev reservasjon pr dato. 3. Det skal kunne legges inn tidsrom på datoer som er delvis reservert. 59

61 Kravspesifikasjon Designmål administrasjon - 1. Administrasjonssiden skal ha tilgangskontroll i form av en egen innloggingsside med lenke fra siden. 2. Designet skal holdes likt, men linker skal være til administrering av nettsiden. 3. Sidene skal fortsatt ha logoen og menylinjen i toppen for å bevare et kjent miljø for brukeren. Ytterlige muligheter blir tilgjengelig på hovedsiden i form av en meny på venstre side. 4. Bakgrunnsfarge på administratordelen skal angi at brukeren er på administratordelen av nettstedet Klubben Designmål brukerportal - Klubben 1. Det skal være en egen innloggingsside før bruker kommer til selve portalen. 2. Når brukeren er innlogget skal han/hun se en side der nyheter/beskjeder blir presentert. 3. Sidene skal ha overskrift og menylinjen i toppen tilsvarende sideoppsett på Gilje's hjemmeside. Designet trenger ikke være likt Gilje sitt design da nettstedene er fullstendig adskilt. 4. Brukeren hører til et tilgangsnivå som bestemmer hva han/hun skal ha tilgang til, men dette skal ikke være noe brukeren skal se. Brukeren skal ikke se begrensningene ved sin klarering Designmål administrasjonsportal - Klubben 1. Administrasjonssiden skal kun være en utvidelse av brukerportalen. 2. Designet skal holdes likt, men muligheter for administrering skal komme opp som en del av valgene. 3. Sidene skal fortsatt ha logoen og menylinjen i toppen for å bevare et kjent miljø for brukeren. Ytterlige muligheter blir tilgjengelig på hovedsiden i form av en meny på venstre side. 4. Brukeren hører til et tilgangsnivå som bestemmer hva han/hun skal ha tilgang til, men dette skal ikke være noe brukeren skal se. Brukeren skal ikke se begrensningene ved sin klarering. 60

62 Kravspesifikasjon 6 Kode 6.1 Krav til kode 1. ASP-kontrollere (Label, TextBox etc.), metoder og variabler skal ha naturlige navn i forhold til den konteksten de er i. F.eks. en tekstboks med input navn må kalles "navntextbox". 2. Kodefilene skal kommenteres i henhold til C# XML standard som det er støtte for i C# kompilatoren. F.eks.: // Metode for å registrere Public actionresult Registrer { //Session for å sjekke om bruker er innlogget eller ikke Session[innlogget]=false; } 61

63 Kravspesifikasjon 7 Dokumentasjon 7.1 Krav til dokumentasjon 1. Det skal innføres daglig logging av hva som er blitt gjort. Her skal det forklares utfordringene som vi møter og hvordan vi løste de. 2. Referater fra møter skal dokumenteres. Gjelder både møter med Gilje og gruppe. Møter med Gilje føres i egne møtereferat mens gruppemøter føres i arbeidslogg. 3. Det ferdige prosjektet skal dokumenteres gjennom: Kravspesifikasjon Prosessrapport Produktdokumentasjon Brukerdokumentasjon Testrapport 7.2 Eventuelle krav til sikring mot tap av data 1. All dokumentasjon og data skal lagres på Dropbox delt mellom prosjektmedlemmene og Gilje. 2. All koding skal foregå ved deling via en Team Foundation Server slik at vi sikrer versjonskontroll og 3. Det skal tas en modulær backup som f.eks. med en minnebrikke eller ekstern harddisk. 62

64 Kravspesifikasjon 63

65 2013 Hovedprosjekt 2013 Gruppe 27 Produktdokumentasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie

66 Produktdokumentasjon 65

67 Produktdokumentasjon 1 Forord Dette er produktdokumentasjonen til nettsiden "" og portalen til "Klubben". Dokumentasjonen er primært beregnet for de som skal vedlikeholde, videreutvikle og drifte nettløsningene. Dokumentet er til tider svært detaljert og teknisk. Modeller og overordnet beskrivelse vil gi et godt innblikk i systemenes oppbygning, men i tillegg er en del kode og struktur grundig forklart. Det tekniske språket gjør at denne rapporten er best egnet for personer med god datateknisk forståelse. Dokumentet er en del av sluttrapporten der kravspesifikasjonen er et eget hovedkapittel. Kravspesifikasjonen vil være viktig å benytte i samsvar med dette dokumentet. 66

68 Produktdokumentasjon 67

69 Produktdokumentasjon 2 Innholdsfortegnelse 1 Forord Innholdsfortegnelse Teknologier og rammeverk Språk Nettlesere Lagringsplass System Beskrivelse av programmet Virkemåte 1 Gilje hjemmeside Virkemåte 2 Gilje Administrasjon Virkemåte 3 Booking administrasjon Virkemåte 4 Klubben Administrasjon Brukergrensesnitt Meny Farge- og fontvalg Knapper og lenker Felter/inputer Programmets oppbygging og funksjoner Klubben Gilje Kodestruktur Lagdeling Filer, klasser og mappestruktur Navngiving Database Kommentering Samsvar mellom kravspesifikasjon og produkt Endringer Avvik Sikkerhet LINQ Registrering

70 Produktdokumentasjon 9.3 Adgangsnivå (Klubben) Innlogging Passordhåndtering Session Feilmeldinger Referanser Vedlegg Sitemap - "" Sitemap - " - Administrasjon" Sitemap - " - Booking Administrasjon" Sitemap - "Klubben" Aktivitetsdiagram - "Registrer reservasjon" Aktivitetsdiagram - "Endre Profil" Aktivitetsdiagram - "Ny Administrator Booking" Aktivitetsdiagram - "Registrer medlem" UseCase - "" UseCase - "Klubben" Sekvensdiagram - Adgangsområder Sekvensdiagram - Medlemsområder edit Sekvensdiagram - Oppdater Medlemprofil Sekvensdiagram - Registrer admin

71 Produktdokumentasjon 3 Teknologier og rammeverk Begge prosjektene, Klubben og Gilje, er kodet i ASP.NET MVC. Vi har brukt Visual Studio 2012 da dette er det mest aktuelle programmet på markedet, for å ikke si det mest lettvinte og dokumenterte programmet for dette språket. Vi valgte å bruke MS SQL server for databasehåndtering da både MS SQL og ASP.NET er Microsoft teknologi. Det vil ofte være mest enkelt å søke opp feilmeldinger og hente hjelp fra internett. Det er brukt LINQ i begge prosjektene som er et lettere verktøy for å aksessere databasen i tillegg til at det er nesten helt sikkert mot sql-injections. ASP.NET MVC Framework er satt til 4.0(standard 4.5 ved oppretting) da dette var nyeste versjonen som ble støttet der server holder til. 3.1 Språk ASP.NET MVC.NET er en samling teknologier rundt programvareutvikling fra Microsoft. Plattformen er i dag en av de mest brukte utviklingsplattformene i verden. Språket som benyttes er i hovedsak C# sammen med standard HTML og CSS. Rammeverket MVC (model-view-controller) gir en programvarearkitektur som skiller representasjonen av data fra brukerens interaksjon med en. Dette gir økt sikkerhet og bedre kontroll. "Model" består av data, regler, logikk og funksjoner. "View" kan være alle slags representasjoner av utskrift av data til skjermen og "controller" konverterer inndata til kommandoer for modellen eller view'et Gilje Dette er rammeverket vi har benyttet oss av når vi har lagd Gilje. Vi så ikke noe konkret grunn til å utvide dette til en lagdelt løsning. Vi baserer oss derfor kun på bruk av Controller, View og Model.(Figur 1). Hvis dette ble lagdelt hadde det vært vanskeligere oss å kode og overtager til å forstå system. Figur 1 70

72 Produktdokumentasjon Klubben Vi valgte derimot å lagdele applikasjonen til Klubben(Figur 2). Dette var et valg vi gjorde siden denne løsningen kom til å inneholde flere funksjoner og være mer kompleks enn Gilje Selskapslokaler. Grunner til å lagdele løsningen til Klubben var at vi trengte god struktur med en større applikasjon. Dette gjorde vi da ved å dele koden inn i presentasjons-, virksomhetsog datalag. Data blir dermed flyttet mellom lagene og de riktige tingene blir gjort i sitt lag av applikasjonen. Presentasjonslaget er MVC strukturen vår, som inneholder Controllere og Views. DAL (Dataaksesslag) er laget som jobber mot database og BLL (Business Logic Layer) brukes til all annen logikk enn presentasjon og databaseaksess. Figur Javascript JavaScript er en implementasjon av ECMAScript, et skriptspråk som er best kjent for å tilføre dynamiske elementer til nettsider. Sammen med øvrig innhold på nettsiden (hovedsakelig HTML) sendes det kode (innenfor et <script>-tagpar), som kjøres lokalt i nettleseren, automatisk eller som reaksjon på brukervalg på siden. I vårt prosjekt ble javascript benyttet i forbindelse med bildebehandling på nettsidene. Vi brukte for det meste JQuery som er et JavaScript-bibliotek. JQuery er det mest populære JavaScript-biblioteket i bruk så vi mente det var det beste alternativet for oss å se på. Det er blant annet brukt til å vise kalender med data hentet fra database og vise bilder i galleri. Meste av javascript og jquery er lastet ned via NuGet i Visual Studio og er ikke produsert selv, men det er produsert noe kode for å hente ut data og vise funksjoner og bilder litt annerledes. 71

73 Produktdokumentasjon SQL og LINQ Structured Query Language (SQL) er et programmeringsspråk for databaser som benyttes til å formulere og kjøre operasjoner mot relasjonsdatabaser (RDBMS) og som originalt er basert på relasjonsalgebra og -regning. De fleste av dagens databasesystemer tilbyr SQL som kontrollgrensesnitt. Vi benyttet SQL til lagring av administratorer, medlemmer, bilder, filer osv ved hjelp av LINQ. Vi jobbet mot databasen vår gjennom LINQ (Language Integrated Query). LINQ er en komponent i Microsoft.NET Framework som kan brukes for å aksessere ulike datatyper. LINQ har en spesiell C#-syntaks som kan benyttes uavhengig av datakildene. LINQ til SQL er tatt i bruk fordi det håndterer databasekode på enklere og raskere måte, samtidig at det skal holde databasen trygge mot sql-injections CSS og HTML HTML(HyperTextMarkup Language) er et markeringsspråk som brukes til å strukturere informasjon som skal vises på nettsider. HTML er bygget opp av tags(body, head, body osv) som alle de store nettleserene tolker og viser hvordan innholdt og struktur skal vises. CSS(Cascading Style Sheets) er et språk som blir brukt til å definere utseende på filer som inneholder HTML og XML. Disse kan definere bredde, farge, posisjoner osv på de ulike taggene som er blitt opprettet i HTML-filene. CSS blir linket til i HTML-koden som betyr at de forskjellige HTML-filene kan ta i bruk forskjellige CSS-filer. I Visual studio kan disse CSS-filene legges inn i.config-fil som blir lastet kan inkluderes i et View ved hjelp av en linje kode. 3.2 Nettlesere Prosjektene Klubben og Gilje skal støttes i de mest brukte nettleserene på markedet. For å holde oss innenfor rimelighetens grenser har vi hovedsaklig holdt oss til de tre største nettleserene, som holder på over 90% av verdens brukere innen nettlesere. Nettlesere som har blitt lagt mest vekt på er: - Google Chrome - Mozilla Firefox - Internet Explorer Det visuelle og funksjonene skal vises og virke likt i disse nettleserene. Det har under hele prosessen av begge prosjektene blitt testet i disse nettleserene for å se at funksjoner eller utseende blir tapt eller forskjellig i andre nettlesere. 72

74 Produktdokumentasjon 3.3 Lagringsplass Begge systemene er angitt til å ikke ha behov for veldig stor lagringsplass eller kapasitet. Det skal i hovedsak ikke være stor datatrafikk til server da sidene for et begrenset område og begrenset brukere. Det eneste som er blitt tatt i betraktning er lagringsplass på server. Dette er med tanke på at medlemsportalen(klubben) skal håndtere en god del filer som vil ta litt plass. Ved gjeldende server som prosjektet er lastet opp på er datalagring ubegrenset. 3.4 System ASP NET MVC, Visual studio og MS Sql er alle Microsoft teknologi og da var også det mest aktuelle å bruke Windows til utvikling og server hosting da dette er det enkleste å bruke og mest dokumentert. Hvis ikke hadde det tatt ekstra jobb i tillegg til at det trengs ekstra programmer på server for at det kanskje kunne fungert. 73

75 Produktdokumentasjon 4 Beskrivelse av programmet Produktene som vi har laget er WEB baserte administrasjonssystem og hjemmeside. De er designet slik at de skal kunne kjøre på alle typer nettlesere. Utviklingsprogram som vi har brukt gjennom hele prosjektet er Microsoft Visual 2012 og kodingen skjer på C#, JavaScript, HTML og CSS. Under dette kapitlet har vi delt det inn i fem forskjellige underkapitler som er fem virkemåter. På hver av virkemåtene er det forklaringer av grunnleggende bruk, hvordan vi har tenkt og hva som er hensikten. Det er generelt beskrivelse av oppbyggingen. 4.1 Virkemåte 1 Gilje hjemmeside Startside Når en bruker besøker nettsiden er det stort sett enten for å skaffe informasjon eller for å reservere lokalet. Vi har gjort det slik at startsiden skulle gjøre et bra første inntrykk og med litt info som blant annet nyheter. Det første man ser på siden er en levende bildefunksjon som automatisk bytter bilder. Vi har brukt programpakken Galleria som man kan lett installere via Visual sin utvidelses, program NuGet. Galleria er ren kodet i JavaScript, og vi implementerte selv en liten del av vår kode i en egen js-fil under Scripts-mappa (BildeSLideShow.js). I fila er det en metode med funksjoner som vi ville ha med i bilde show, og metoden blir da kalt i chtml-fil. Galleria har også egen CSS-fil (galleria.classic.css) som vi kan tilpasse designet selv. For å kjøre denne pakke må vi inkludere pakkens egen jquery og dette gjør vi også i chtml-fil inni <script>-tag. Når det gjelder bilder som skal publiseres må de implementeres manuelt i chtml-fil (Index.chtml). Figur 3: Startsiden 74

76 Produktdokumentasjon Navigasjon Navigering skjer med navigasjonsmenyene på toppen, her linkes det til 6 forskjellige sider. Figur 4: Toppmeny Bestilling/reservasjon Under denne siden vil man først finne en kalender med oversikt over reserverte tidspunkter på den uken man er på. Kalender har funksjoner i seg selv. Her kan man ha man få kalender oversikt på spesifikk dag eller i hele måneder. Kalenderen har en navigasjonsknapp som man kan navigere til neste dag, uke eller måned. Kalenderen er en tilleggsprogram er kodet i JavaScript og kan lastes ned med NuGet. Figur 5:Kalender For å kunne booke/reservere lokalet må man først sende inn en forespørsel. Bookingen skjer helt nederst på siden der man finner et skjema som må fylles ut. Booking blir sendt inn og blir da senere behandlet av en administrator. Grunnen til dette er at det skal være en kontroll på hvem som leier lokalet og til hvilket formål. Figur 6 - Reservasjonsforespørsel 75

77 Produktdokumentasjon Galleri Bilde galleriet er et slideshow som inneholder et sett med bilder. Her har vi også brukt programmet Galleria.. Galleri er hentet fra NuGet-pakkeinstallerer. Figur 7: Galleria Galleria har innebygde funksjoner i seg selv. Men vi har begrenset til noe få typer. Funksjoner som vi har tillatt er navigeringsknapper, som man lett finne på hver side av bilde boksen, og lightbox, som er et lysbilde funksjon, som popper opp når du klikker på bildet i boksen. Her også finner man navigeringsknapper. Og for å gå ut av lightbox kan man bare enkelt klikke krysset på hjørnet eller på utsiden av boksen. Figur 8: Lightbox 76

78 Produktdokumentasjon Om Gilje Generelle informasjoner om Gilje Selskapslokalet finner man under her. Her kan man finne info om selve lokalet, historie og beliggenhet og disse tre nevnte er sidemenyer som man kan navigere seg frem. Figur 9 - Sidemeny Under Her finner du oss har vi lagt fram et kart over lokalets beliggenhet, og kartet har en funksjon som ved et klikk blir man navigert til en ny side, Gulesider-kart. Figur 10 - kart Figur 11 - Gulesider 77

79 Produktdokumentasjon 4.2 Virkemåte 2 Gilje Administrasjon Innlogging og logg ut Normalt sett skal administrasjonsside være tilgjengelig på en hjemmeside. På hjemmesiden vil man ikke kunne finne verken en knapp eller en link til administrasjonsside. Dette er på grunn av at kunden ønsket at det ikke skulle være en fysisk knapp eller link som direkte henviser til administrasjon. De vil heller at administrator skal selv manuelt taste inn url link på adresse linje.../admingilje/logginn Etter det vil du bli henvist til innloggingsside. Her er det bare å taste inn brukernavn og passord på inputfeltene og logg deg inn. For å få brukernavn og passord må man først bli registrert av administrator. Om sikkerhet bak innlogging henvises til punkt 6. Figur 12:Innlogging Gilje Admin Formål med administrasjon er vedlikehold av hjemmeside. Her kan administrator legge til og fjerne nyheter, bilder og mulighet for å registrere ny administrator for både for Gilje Admin og Booking Admin. Når det gjelder å logge ut har vi lagt til en vanlig html-link på høyre hjørnet under toppmeny. Her er det også en enkel tekst funksjon som hilser velkommen til den personen som er pålogget. Og disse funksjonene vil være statiske og vil være tilgjengelig på alle sider. Figur 13: Logg ut knapp 78

80 Produktdokumentasjon Navigasjon Navigering skjer med navigasjonsmenyen øverst på siden, her linkes det til 3 forskjellige sider. Figur 14: Toppmeny Administrasjon Og under brukere har vi plassert sidenavigasjon til venstre som henviser til de forskjellige sidene. Detter er valg som hører under menyvalget. Figur 15: Eksempel på sidemeny Legg til/slett nyheter Det første brukeren vil se etter innlogging er nyhets-administrering. Her er det oversikt over tidligere nyheter som blir publisert på startsiden til hjemmeside. På samme side kan man også slette nyheter. På hvert av de elementene er det en slett-link (henvist med rød pil på bilde under). Når linken trykkes vil den valgte nyheten fjernet både fra listen og på startsiden på hjemmesiden. Siden er beregnet til slett funksjon. Men vi valgte å kombinere listing og sletting. Dette er for å slippe unødvendig mange undersider. På sidenavigasjon til venstre kan man se at det ikke finnes noe link til listing av nyheter. For det ligger under samme link som slett nyheter. Figur 16: list og slett nyheter 79

81 Produktdokumentasjon På Legg til nyheter har vi en implementert en vanlig tekstboks hvor brukeren kan skrive inn nyheter og for å legge til har vi en knapp rett under. Nyheten som blir lagt til blir da listet opp på Slett nyheter side og publisert på startsiden til hjemmeside. Figur 17: Legg til nyheter 80

82 Produktdokumentasjon Bilder administrering Sidene er mye av det samme som på administreringen av nyheter. Første side under Galleri får man en liste over opplastete bilder, også her er det slett-bilder-funksjon i en html-link. Figur 18: Liste over bilder For å legge til bilder har vi implementert en html objektet FileUpload som gjør det mulig for fil-opplasting til en server. Ved å klikke på Velg fil -knappen åpner du en dialogbox som du kan søke etter og velge den filen du vil laste opp. Figur 19: Last opplasting 81

83 Produktdokumentasjon Registrering av administrator Registrering av en ny administrator både til Gilje Admin og Booking Admin, under BRUKERE er ryddig plassert med link for hver av funksjonene. For registrering er det tre inputfelt; Brukernavn, passord og fornavn, etternavn Gilje admin Figur 20: Registrer Gilje admin Gilje booking Grunnen til at registrering av administrator til Booking Admin skjer på Gilje Admin er at Gilje har ansvaret for vedlikehold av hjemmeside og administrasjonssidene. Mathilde er de som skal kun håndtere reservasjonene som blir sendt inn og bare det, dermed skal de kun ha tilgang Booking og ikke noe annet. Figur 21: Registrer Gilje Booking 82

84 Produktdokumentasjon 4.3 Virkemåte 3 Booking administrasjon Innlogging Her er det veldig likt Gilje Admin. Man taster inn url-link på adresse linjen.../adminbooking/logginnbooking Og blir direkte henvist til logg inn side. Figur 22: Logg inn Booking admin 83

85 Produktdokumentasjon Registrere godkjente søknad av reservasjon av lokalet Søknadene om reservering av lokalet som ble godkjent blir behandlet av Mathilde. De vil da bruke skjemaet under RESERVER på navigasjonsmeny for å registrere. Figur 23: Registrering skjema for søknader Inputfeltenes overskrifter forklarer veldig mye i seg selv. På Start dato og Slutt dato skal man manuelt taste inn dato og time på samme felt. Forkortelse i parentes forklares slikt DD = dato, MM = måned, YYYY = år og HH= time, MM = minutt Det skal være med en / (slash) mellom hvert av tallene og i klokkeslett skal det være en : (kolon) Input kan skrives slikt: 20/05/2013 (mellomrom) 18:00 84

86 Produktdokumentasjon Kalender Kalender under KALENDER er akkurat den samme kalenderen man finner på Gilje hjemmeside under BESTILLING, men kun rettighet til behandling som redigering og sletting er begrenset på hjemmeside som da utgjør forskjellen. Formålet med en egen side for kalenderen er at administrator skal kunne holde oversikt over forskjellige arrangementene og at det skal være lett å vedlikeholde. Kalenderen er hentet fra NuGet-pakkeinstallerer. Figur 24: Kalender Oversikt over reservasjoner Under RESERVASJONER vil du finne alle reservasjonene som har blitt registrert. Her er det implementert to html-linker som er Ny reservasjon som linkes til registrering skjema på RESERVER siden og Slett link på hver enkelte reservasjonene. Figur 25: Liste over reservasjoner 85

87 Produktdokumentasjon 4.4 Virkemåte 4 Klubben Administrasjon Innlogging Innlogging til klubben har vi gjort det lik som på Gilje Administrasjon. Inputfeltet er selvforklarende og om en bruker har glemt sitt passord kan personen få tilsendt tilfeldig generert passord per e-post. Vi har en html-link Glemt passord nederst til venstre i innloggingsvindu som man blir henvist til en ny side med en inputfelt hvor man skal taste inn sin e-post adresse som man har registrert seg med. Figur 26: Innloging Klubben Navigasjon Navigasjonsfeltet/meny til Klubben består av fem elementer. Fire av dem er veldig synlig og ligger tett ved siden av hverandre. Den siste, Administrator (merket rød firkant på bilde), finner du på høyre hjørnet ved Logg ut linken. To av feltene er begrenset i forhold til brukere. Brukere som ikke er administrator vil ikke kunne ha tilgang til Administrasjon. Når det gjelder undermenyene under Dokumenter har brukeren kun tilgang til de områdene som han/hun har rettighet til. Og rettighetene er det administrator som står ansvarlig for Figur 27: Navigeringsmenyer/elementer 86

88 Produktdokumentasjon Undermenyer og rettigheter Til sammen er det seks elementer under Dokumenter. Som nevnt tidligere har hver av de forskjellige rettigheter som en hver bruker må ha for å få tilgang. Rettighetene er lese og skrive rettigheter. Hvis en bruker kun har leserrettighet får han kun oversikt over elementene og dermed får ikke redigere (figur 28). Om brukeren har begge rettighetene får han tilgang til både redigering og oversikt (figur 29). Figur 28: Eksempel på leserrettighet Figur 29: Eksempel på lese- og skriverettigheter 87

89 Produktdokumentasjon Undermenyene Som på figur 27 har vi en full oversikt over hvordan administrering av sanger ser ut. På toppen finner man et søkefelt hvor brukeren kan søke etter ønskede filer. Her er det kun søking på filnavn eller beskrivelser. Nedenfor har vi liste over filer som har blitt lastet opp og som ligger i databasen. Filer-feltet har en slett funksjon i html-link som sletter elementet både fra lista og fra databasen direkte. Til høyre har vi opplastingsfelt. Det inneholder tre felter; en til beskrivelse av fil som kan være f.eks. navnet på fila, dato av siste gang fila ble brukt og siste input felt er en FilUploader felt som laster filer til databasen. Når det gjelder dato input så er det blitt brukt datatype Date. På høyre hjørnet av feltet finner man en liten pil som peker nedover om man trykker på den vil det dukke opp en kalender. Her kan brukeren velge ønskede dato enklere. Når det gjelder resterende undermenyene har det blitt brukt den samme layouten som Sanger. Figur 30: Kalender av datatype Date 88

90 Produktdokumentasjon Index side Nyheter Index-siden i administrasjon er en nyhetsoversikt. Her kan vedkommende som logger seg inn lese nyheter om det som skjer i klubben. Nyhetene kan kun legges til av administrator. Og det kan man gjøre under administrasjonsfeltet. Figur 31: Index side & nyhet side Medlemmer Her er det liste over alle medlemmer som er registrert. Eneste funksjon på denne side er søk funksjon. Når det gjelder input så er det kun medlemsnavn som er gyldig søk. Søk på telefonnummer, e-post og dato er ikke gyldig. Små eller store bokstaver er likegyldig. Figur 32: Medlemmer side 89

91 Produktdokumentasjon Minside Dette er en profilside til brukeren som er pålogget. Her står alt av informasjon om brukeren. Html-linker (markert med rød firkant på figur 31) helt nederst ved listen er det er beregnet for endring av profil og passord. Figur 33 - Profil 90

92 Produktdokumentasjon Inputfeltet til bridgenavn på Oppdater Medlemsprofil er det valgfritt for brukeren om det skal ha noe data eller ikke. Ellers må alle feltene fylles ut. Inputfeltene til Endre passord veldig selvforklarende og standard for slike løsninger. Figur 35: Endre passord Figur 34: Endre profil 91

93 Produktdokumentasjon Administrator I denne delen er det kun administrator som har tilgang. Området er beregnet for vedlikehold av medlemmer, nyheter og brukerområder. Når du klikker deg inn på område kommer man med en gang en liste oversikt over medlemmer, og venstreside har du en tilleggsmeny/navigasjon til resterende sider. Over listen over medlemmer finner man en html-link til Opprett nytt medlem (merket med rød firkant på figur 36). Denne siden (figur 37) er for vanlig registrering og alle feltene må fylles, men bridgenavn er det valgfritt. I liste over medlemmer vil man finne et felt der det står Endre og Slette (merket med rød firkant på figur 36). Klikker man på Endre vil man få opp en redigeringsside (figur 38) av medlem. Klikker man på Slett, sletter man medlem fra listen og fra databasen og medlemmet får da ikke tilgang til Klubben. Figur 36: Administrer medlemmer Figur 37:Registrer nytt medlem Figur 38: Rediger medlem 92

94 Produktdokumentasjon Nyheter Som tidligere blir nyheter behandlet kun av administrator. Og her er det området som nyheter blir opprettet. Vi har gjort det veldig enkel (figur 40). Implementerte to editor-bokser hvor den ene er for tittel til nyhet og den andre er til artikkel. Ferdig lagrede nyheter vil da være synlige i en tabell-liste til høyre for inputfeltene og på index side (se figur 39). I tabellen har hvert av dem har en Slett html-link hvor man kan slette nyheter vekk fra listen og fra databasen. Figur 39: Adminstrering av nyheter Figur 40: Nyhet oppdatering på index-side 93

95 Produktdokumentasjon Områder På denne siden er det redigering av dokumentområder (rød firkant i figur 41). Dette er egentlig beregnet til kun første bruk, men om det en gang i fremtiden administrator ønsker å endre disse er det også mulighet for det. Funksjonen har 7 inputfelt (se figur 42) hvor brukeren skriver inn ønskelig navn på områdene. Figur 41: Administrering av dokumentområder Figur 42: Dokumentområder 94

96 Produktdokumentasjon 5 Brukergrensesnitt Det er to websteder som ble utviklet og begge har forskjellige designtyper ("Gilje Selskapslokaler" og "Klubben"). Under dette punktet er det forklaring på hvorfor og hvordan vi har tenkt ut designet på disse. Det er alt fra menyer, farge, fonter og knapper osv Meny Gilje hjemmeside Gilje ønsket at det ikke skulle være en overdrivende, fancy hjemmeside. De ønsket heller en presentabel hjemmeside som ønsker gjestene velkommen og få de til å bli interessert i å leie lokalet deres. Menyene er viktig i forhold til navigering på siden og brukervennlighet. Vi har valgt veldig enkel og grei og en statisk meny som inneholder seks linker. Linkene ligger inne i to <div> tager som utgjør en fremheving av menyen. Når det gjelder linken så har vi implementert - a:hover- både på border-top og border-bottom i CSS for å fremheve linken når brukeren setter museknapp over og velger linken (se figur 43 ved BESTILLING). Figur 43: Gilje Meny Gilje administrasjon Vi har tatt samme menydesign fra hjemmesiden Gilje til meny i administrasjonsside. Dette er fordi vi ønsket å holde design og navigasjon likt for å understreke at dette er to sider av samme system. Figur 44: Gilje admin meny 95

97 Produktdokumentasjon Klubben Vi har valgt å designe menyen til klubben helt annerledes. Her vil vi at hver av linkene skal være en TAB. For hver av dem vil det være har en farge fremheving når museknappen over den og når linken er trukket slik at det blir lettere for brukeren å kartlegge hvilken TAB de er på. Figur 45: Klubben meny 5.2 Farge- og fontvalg Fargevalg har vi tatt i betraktning av at det ikke skal være en overdrivelse i dette. Som nevnt skal det være presentabel side. Det sammen med fontene. De skal være lett leselig og skal ikke være for store og for små Gilje hjemmeside og administrasjonsside Bakgrunnsfarge har vi valgt farger som skulle være behagelig for øyne. Ikke for skarpe ikke for dempende. Det samme gjelder farge i med menyene også. Vi har lagt til logoen til Gilje som transparent i bakgrunn (se figur 46 og 47). Fontene i menyen (se figur 43/44) er i blokker slik at det skal bli lettere å lese og gjenkjenne linkene. Figur 45: Gilje logo i transparent vakgrunn Figur 46: Gilje-logo i transparent på klubben 96

98 Produktdokumentasjon Klubben Klubben har vi gjort annerledes. Vi valgte bakgrunnsfarge som vi assosierer med en administrasjonsside og valget ble en gråaktig farge. Farge på menyen har vi bestemt at det skal være mere synligere og vi valgte å ha svart og gul som strekker over hele sida og hvit på TAB'ene. (se figur 31) Når det gjelder overskrifter på innholdene under linkene som f.eks. Nyheter. Har vi valgt å bruke bold for å fremheve bokstavene og vi brukte gul fargen til å strekke ut til side for å markere at det er en overskrift. 5.3 Knapper og lenker Knapper Knapper har vi gjort forskjellig mellom Giljeadmin/Gilje booking og Gilje hjemme/klubben. Gilje admin og Gilje booking ble det valgt grå farge på knapper (figur 49). Dette er fordi vi ikke vil fremhevet så mye og at siden det er en administrasjonsside så skal designe være enkel. Mens på Gilje hjemmeside og på klubben er det gule knapper (figur 48). Klubben er en administrasjonsside men siden nettstedet blir brukt til å administrere seg selv så valgte vi å ha samme farge på knapper som på Gilje hjemmeside. Figur 48: eksempel på gul knapp Figur 47: Eksempel på grå knapp Logg inn knapper på alle innloggingsmuligheter har vi valgt å ha en fast farge (figur 49). Legg merke til at farge på banner på innloggingsboksen er det samme som på knappen. Figur 49: Eksempel på logg-inn knapp Lenker Vi har brukt mye lenker på våre nettsider. Disse er alle html-lenker. Vi synes det er de skal være selvforklarende at brukeren skal lett forstå at det er en lenke. Vi har tatt bort standard blå fargen og den svarte prikken fra lenken. Figur 51:Eksempel på en lenke Figur 50: Eksempel på en lenke 2 97

99 Produktdokumentasjon 5.4 Felter/inputer Det finnes fire typer input vi har brukt og implementert. Det er vanlig input med label-tekst over (figur 53) og input med placeholder dvs. transparent tekst inni input (input 52). To siste inputer er fil-lasting (figur 54) og dato felt. Figur 52: Input med transparent Figur 53: Input med label-tekst Figur 54: Input for fil-opplasting 98

100 Produktdokumentasjon 6 Programmets oppbygging og funksjoner Under blir det forklart noen av de ulike hoved- og undermetodene brukt i systemene. Disse blir vist som eksempler slik at de som eventuelt skal ta over og vedlikeholde nettsiden skal forstå hvordan koden er bygd opp. Kode som er installert som pakker eller direkte kopiert blir beskrevet i beskrivelse om programmet. Funksjoner som beskrives kan finnes på Use Case modellene til hvert av prosjektene. Det er også lagt til sekvensdiagrammer til vedlegg for å lettere forstå gangen i metodene ved hjelp av visuell visning. Use Case ligger som vedlegg til dette dokumentet for å se gangen i systemet. Sekvensdiagrammene ligger også vedlagt og viser gangen i funksjoner. 6.1 Klubben Logg inn Controller: Over er det et kodeavsnitt av LoggInn-metode. Det er en metode som tar inn data etter at en bruker har trykket på form. Først vil den sende tastet data til "sjekkbrukermotdb" og sjekker om personen finnes i databasen. Hvis den stemmer vil den lagre blant annet navn og medlemsnummer i Session også sjekker den om brukeren er en administrator. Om den er det 99

101 Produktdokumentasjon vil link til administrator-side vises på forsiden. Hvis bruker ikke finnes eller feil passord er tastet vil den skrive en feilmelding til bruker Glemt passord Controller: Ved glemt passord må bruker skrive inn e-posten sin. Først vil databasen sjekke om e-post til bruker finnes i databasen. Hvis den gjør det vil den prøve å generere et random passord og sette dette i databasen dere e-post og brukernavn stemmer overens. Hvis dette var vellykket vil den hente brukernavn til bruker og sende det nye passordet på e-post. 100

102 Produktdokumentasjon Vis medlemsområder Under vil det vises et eksempel på hvordan Controller, BLL, DAL og Database jobber sammen. Controller: Metoden "Dokument" har i oppgave å hente de områdene en bruker har tilgang til og så vise disse til bruker. Hvis bruker ikke har adgang vil heller ikke link til området vises. Over oppretter den en List<MedlemsOmraader> som er en liste som inneholder elementer fra MedlemsOmraader-modellen. Områdene er sikret at det ikke er mulig å navigere seg i linken til hvilket som helst område. BLL: Dette er laget som jobber mellom Controller og DAL. Den får inn medlemsnummer(parameter "i") og sender denne videre til dal. 101

103 Produktdokumentasjon DAL: I starten av controlleren oppretter den et objekt av type LINQDataContext. Denne jobber mellom DAL og SQL på en strukturert og sikker måte. Metoden er angitt til å returnere et objekt av type List<>. Innholdet i metoden tar for seg å hente data fra databasen som stemmer overens med kriteriene som blir påkrevd i forespørselen(where-funksjonen). Eventuelle data blir satt til et objekt av type List<> og returnert tilbake til BLL, så tilbake til Controller der ifra. View: Når metoden ankommer Controller igjen vil da bli hentet List<MedlemsOmraader> og listet ut på siden ved hjelp av foreach-løkke. 102

104 Produktdokumentasjon Søk etter medlemmer Controller: I Viewet der søkmedlemmer-metoden blir brukt ligger det en input form som man kan hente data fra inntastet input når metoden blir kjørt. Denne blir sendt videre til BLL og så DAL for å sjekke om det er noen data som tilsvarer inntastet tekst. Hvis det ikke stemmer overens med noe i databasen vil den returnere melding til bruker om at ingen data ble funnet. Hvis det finnes i databasen vil den sende med en ny liste av navn, men kun de som inneholder hva bruker søkte på. 103

105 Produktdokumentasjon 6.2 Gilje På Gilje sin nettside er ikke systemet lagdelt. Nedenfor vises eksempler på all kode som omhandler metoder og databasehåndtering for prosjektet Send forespørsel controller Metoden "Booking" får inn formskjema fra en bruker og bruker disse dataene til å sende e- post til Gilje sin e-post konto. Denne oppretter et objekt av "MailMessage" som er implementert i ASP.NET. Hvis den klarte å sende e-post vil den returnere tilbake til Viewet, ellers vil den skrive ut feilmelding. 104

106 Produktdokumentasjon Galleri Controller: I View'et er det et JQuery plugin script(lastet ned og installert) som styrer bildene. Dette er modifisert til å hente ut data fra databasen istedet. Bilder kan lastes opp av administrator på siden og da vil bildet legges til i mappe og filnavnet vil bli lagt i databasen. Over vises hvordan url/navnet blir hentet ut og lagt i liste med objekter. View: Over er en foreach-løkke som henter bilder fra Images/Galleri/"Filnavn". Når disse blir hentet vil JQuery script for galleri(galleria.js) vise disse på en strukturert og fin måte. 105

107 Produktdokumentasjon Registrer Administrator Controller: Over vises hvordan systemet tar seg av at en administrator skal bli registrert i systemet. Først vil den sjekke igjennom om administrator allerede finnes. Hvis den ikke gjør det vil den hente brukernavn, navn og passord. Passord vil bli sendt til hash-metode som krypterer dette før det havner i databasen. Ved eventuelle feil i inntasting eller database blir det sendt feilmelding til bruker. Undermetode for å lage kryptert passord: Over viser en ganske standard måte å kryptere passord på. Den tar for seg hasing-algoritmen "SHA256" som skal være en av de tryggeste å bruke. Deretter vil passordet som er blitt hashet lagt i et array av byte som forsterker sikkerheten. 106

108 Produktdokumentasjon 7 Kodestruktur 7.1 Lagdeling Lagdeling er kun tatt i bruk i prosjektet Klubben. Dette er fordi dette er et mer kompleks system enn Gilje og vi så et stort behov å lagdele koden(figur 43), ellers ville det endt med å være vanskelig å få kode på en ryddig og forståelig metode. De tre første lagene viser åssen prosjektene i Klubben henger sammen og siste laget som demonstrer kobling mellom DAL og database. I DAL ligger også LINQ som er et mellomlag for mellom DAL og databasen for lettere og sikrere håndtering av data. Figur

109 Produktdokumentasjon 7.2 Filer, klasser og mappestruktur Klubben Klasser Figur 11 Her er det listet opp de forskjellige klassene som vi har opprettet for prosjektet og som inneholder kode for hele systemet. Det er satt firkant rundt de forskjellige klassene som forteller hvilket prosjekt i systemet de ligger i. Under vises det mer detaljert hva de forskjellige prosjektene inneholder av mapper og filer. (Figur 58) 108

110 Produktdokumentasjon Filer Figur 12 Dette er mappestrukturen som er satt opp på Klubben(Fra venstre til høyre på Figur 58) Prosjekt Klubben - App_Data : lokale databasen(blir ikke brukt ved opplasting) - App_start : config filer som lastes opp blant annet ved oppstart - Content : CSS for de forskjellige layoutene som er bruk, og mappe for lagring av dokumenter. Her lagres også fil med feilmeldinger som oppstår på nettsiden. - Controller: Controller med alle kode - Images: Felles mappe for alle bilder som blir brukt og lastet opp på nettsiden - Scripts: JQuery and andre script som er standard inkludert de som er lastet ned i ettertid for bruk i prosjektet - Views: Inneholder alle views som blir vist. Det er sortert Views i undermapper. - Web.config: Inneholder alt det tekniske blant annet kobling til databasen Prosjekt Model, DAL, BLL - References: Forteller om hvilke implementerte funksjoner i ASP NET MVC som blir brukt og referert i prosjektet. References holder styring på hvilke lag og prosjekter som er koblet med hverandre. Hvis disse ikke hadde hatt referanse hadde de ikke klart å finne de forskjellige prosjektene. - Resten er hovedsaklig klasser som brukes til utføre operasjoner i Controller(Klubben prosjekt). 109

111 Produktdokumentasjon Gilje Klasser Her er det listet opp de forskjellige klassene som vi har opprettet for prosjektet og som inneholder kode for hele systemet. Det er satt firkant rundt de forskjellige klassene som forteller hva de forskjellige klassene er som hovedsaklig blir brukt i tillegg til Views. 110

112 Produktdokumentasjon Filer Dette er mappestrukturen som er satt opp på Gilje: - App_Data : lokale databasen(blir ikke brukt ved opplasting) - App_start : config filer som lastes opp blant annet ved oppstart - Content : CSS for de forskjellige layoutene som er bruk, og mappe for lagring av dokumenter. Her lagres også fil med feilmeldinger som oppstår på nettsiden. - Controller: Controller med alle kode - Images: Felles mappe for alle bilder som blir brukt og lastet opp på nettsiden - Models: Modeller og LINQ-designer - Scripts: JQuery and andre script som er standard inkludert de som er lastet ned i ettertid for bruk i prosjektet - Views: Inneholder alle views som blir vist. Det er sortert Views i undermapper. - Web.config: Inneholder alt det tekniske blant annet kobling til databasen 7.3 Navngiving Vi har prøvd å forholdt oss til norsk navngiving til alt av klasser og kommentarer. Dette har vi gjort i tanke for de som skal ta over systemet senere og det blir lettere å forstå betydningen av klasser og metoder. Dette ble også gjort av egne valg da det ikke var et eget bestemt krav fra oppdragsgiver. Selv om koden er skrevet på norsk har vi utelukket å bruke Æ, Ø, Å fordi dette kan skape komplikasjoner i database og for andre som skal ta over prosjektet. 111

113 Produktdokumentasjon 7.4 Database Databasemodell Diagrammene nedenfor er for Gilje og Klubben. De er løst opp fra mange-til-mange til mange-til-en og en-til-en. - PK står for primærnøkkel(primary key) - FK står for fremmednøkkel(foreign key) Klubben 112

114 Produktdokumentasjon Gilje 113

115 Produktdokumentasjon 7.5 Kommentering Det har blitt kommentert på de metodene det har vært nødvendig eller lurt å kommentere de forskjellige kodesnuttene som blir utført. Dette vil hjelpe de som skal ta over vedlikehold til å forstå koden raskere og bruke dette til oppslagsverk når det er usikkerhet i kode. Det er blitt kommentert på begge prosjektene der det er nødvendig. Noe som blir gjentatt nedover i kode blir som oftest bare kommentert en gang, så slipper det å bli mange duplikater som vil føre til mer uryddig kode. Kommenteringen baserer på at de som tar over har grunnleggende kunnskap for språket. 114

116 Produktdokumentasjon 8 Samsvar mellom kravspesifikasjon og produkt Kravspesifikasjonen har vært viktig for oss gjennom utviklingen av prosjektet og vi har forsøkt å holde oss til de kravene som ble utarbeidet i startfasen på prosjektutviklingen. Kravspesifikasjonen ble utviklet i nær dialog med oppdragsgiver gjennom møter i planleggingsfasen. 8.1 Endringer Kravspesifikasjonen har fått noen mindre justeringer underveis og èn større endring. Dette var da det ble bestemt at "" og "Klubben" skulle deles opp i to separate løsninger på hvert sitt domene. I utviklingen ville ikke dette by på store problemer, men modeller måtte gjøres om på og vi måtte skaffe to domener istedenfor bare ett. Noe av dokumentasjonen, deriblant kravspesifikasjon og produktdokumentasjonen, kan bære preg av å beskrive to forskjellige løsninger. Grunner til dette er at noe av dokumentasjonen var påbegynt i utgangspunktet, men først og fremst at oppdraget ble utført som hovedprosjekt av gruppen som avslutning på studiet i Informasjonsteknologi ved HiOA. Som hovedprosjekt var det da naturlig å samle dokumentasjonen i ett sett dokumenter som tar for seg prosjektet som èn løsning. 8.2 Avvik Krav til hjemmeside -, Gilje ønsker at brukere som besøker nettsiden skal få svar på: o Drikke / alkohol o Målgruppe o Kapasitet o Standard leieavtaler Her er det noen mangler i forhold til informasjon som ligger på nettsiden. Dette gjelder skriftlig informasjon som vi ikke har hatt tilgang til, men dette satser vi på å ordne ved levering av løsningen Designmål reservasjon - " Det skal være farger for de datoene som er ledige, opptatte eller delvis opptatt. Det skal være lett for bruker å fort oppfatte hva de forskjellige fargene betyr ved hjelp av en beskrivelse ved kalenderen." Her er fargeindikasjonen blitt enklere enn kravspesifikasjonen sier. Kalenderen markere dato og tid da det foreligger en reservasjon, men det gis ingen informasjon om dette gjelder hele lokalet. Dette kan gjelde en etasje mens den andre etasjen er ledig. Fargen på markeringen er lik uansett om lokalet er utleid for noen timer eller hele dagen. Dette kommer derimot godt frem rent visuelt siden markeringen i kalenderen markerer det aktuelle tidsrommet. Hele kalenderen er oppe til diskusjon fra oppdragsgiver så vi justerer dette ved leveranse. 115

117 Produktdokumentasjon Designmål reservasjon - " Bruker skal få bekreftelse på e-post om hvilke valg og forespørsel kunden har gjort til administrator." Dette punktet valgte vi bort da vi mente at bekreftelse på skjermen ville være bra nok. Dette vil vi se på sammen med oppdragsgiver ved leveranse. 9 Sikkerhet Det har blitt brukt samme sikkerhet for passordhåndtering, input validering, SQL-injection, på både Gilje og Klubben. 9.1 LINQ Vi jobbet mot databasen vår gjennom LINQ (Language Integrated Query). LINQ bruker vi hovedsaklig til å aksessere vår MS-SQL database. Når det blir utført database spørring fra klient vil LINQ vil det som f.eks tastes inn i en input bli gjort om til SQL parametere istedenfor for at en person har tilgang til å endre SQL-spørringen. Og dette vil hindre "SQLinjections". Eksempel: LINQ-spørring string name = inputfelt.txt; var orders = from ord in ctx.orders where ord.customername = name select ord; Når dette blir kjørt som sql vil stringen "name" bli sendt som parameter og tatt imot SELECT * FROM [dbo].[orders] WHERE [CustomerName] Dette betyr at alt en person prøver å sende med i en spørring kun vil bli satt til parameter istedenfor å ha muligheten til å sende med kjørbar SQL-kode som vil svekke sikkerheten. 116

118 Produktdokumentasjon 9.2 Registrering Når et medlem blir registrert i systemet, vil det først sjekkes at alle brukere er unike, både med brukernavn og e-post. På den måten vil det ikke forekomme noen duplikater i system, som kunne gitt feilmeldinger hvis det ikke var noe sjekk på det. Brukernavn på både Klubben og Gilje skal bestå av 3 første bokstavene i fornavn, 3 første i etternavn og 2 tall. F.eks. LARS GJESTANG blir LARGJE01. Passordet skal også splittes i et byte[] array og legges som binary data i databasen Klubben Ingen brukere skal få lov til å registrere seg selv, eller mulighet til å sende forespørsel om registrering. Dette vil hindre at uønskede personer ikke vil kunne aksessere portalen. Ved registrering av et medlem vil et medlems adgangsnivåer bli satt automatisk til 0(ingen lese- eller skrive rettigheter) for alle områder Gilje Samme gjelder som punkt over, ingen skal kunne få registrere seg selv. Her er det kun administrator som skal kunne få registrere nye administratorer. Administrator på "AdminGilje" kan registrere(og slette) administratorer på "AdminGilje" og "AdminBooking". 117

119 Produktdokumentasjon 9.3 Adgangsnivå (Klubben) En bruker blir tildelt et adgangsnivå for hvert av områdene som er registrert på Klubben. De blir lagt automatisk når administrator registrerer et medlem, der nivå blir satt til 0 som standard. Disse nivåene kan være et av tallene mellom 0-2. Forklaring av tall(oversikt over tabell og relasjoner i vedlegg): 0 - Ingen lese- eller skriverettigheter 1 - Leserettigheter, ingen skriverettigheter 2 - Både lese- og skriverettigheter Sikkerheten blir tildelt slik på grunn av at medlemmer skal kunne ha forskjellige roller på Klubben sin portal. F.eks.: Medlem 1 har adgangsnivå 2 på møtereferater og adgangsnivå 1 på styrereferater. Da vil medlem 1 kunne se alle dokumenter som ligger under møtereferater samt laste opp ny fil, men han har kun tilgang til å se dokumenter på styrereferater uten å laste opp. Medlem 2 har adgangsnivå 1 på møtereferater og adgangsnivå 2 på styrereferater. Og her vil medlem 2 kunne se alle dokumenter som ligger under møtereferater uten å laste opp ny fil, men derimot ha tilgang å se alle dokumenter på styrereferater i tillegg til å laste opp filer. Medlem 3 har adgangsnivå2 på alt samt adgangsnivå2 på administrator. Til venstre: Bruker har adgangsnivå 2 til Sanger Til høyre: Bruker kun adgangsnivå 1 for Bridge 118

120 Produktdokumentasjon 9.4 Innlogging Innloggingsfunksjonene på Gilje og Klubben er nokså like, kun litt forskjellig i kodestruktur. Figur 132 På Klubben, AdminGilje og AdminBookinger innlogingssiden den første siden som dukker opp. Den vil kreve et brukernavn på 6 bokstaver og 2 tall. Hvis bruker prøver å logge inn med feil brukernavn, passord eller andre tegn enn bokstaver og tall vil det dukke opp feilmelding som sier ifra. Inputvalidering skjer før den sender noe database forespørsler. (Ref: figur 2) "Glemt passord?"-funksjonen vil returnere bruker til ny side som ber om e-post. Hvis e-post ikke finnes i systemet vil den vise feilmelding at e-post ikke er registrert i systemet. Hvis e- post finnes vil systemet sende bruker, med riktig inntastet e-post, sitt eget brukernavn og nytt passord. 9.5 Passordhåndtering Ved registrering av bruker på AdminGilje, AdminBooking og Klubben blir passord kryptert med en krypteringsmetode som krypterer passordet med en SHA256-algoritme(vist til å være en av de sikre metodene), som vil generere en 32-bits hash. Deretter blir den satt inn i databasen i passordfeltet som er av type [byte]. Samme metode blir brukt for å sjekke om et brukers passord stemmer. public static byte[] laghash(string innpassord) { var algoritme = System.Security.Cryptography.SHA256.Create(); byte[] inndata, utdata; inndata = System.Text.Encoding.ASCII.GetBytes(innPassord); utdata = algoritme.computehash(inndata); return utdata; } 119

121 Produktdokumentasjon I metoden blir variabelen satt til et objekt som inneholder den hash-metoden som skal brukes. Før det blir hashet må stringen bli gjort om til et array av bytes og deretter blir det hashet og arrayet blir returnert. Denne kan lagres i databasen i en binary-type, men også brukes for å sjekke om et brukers passord stemmer overens med hva som ligger i databasen. 9.6 Session Ved innlogging blir en bruker tildelt en Session for å sjekke om brukeren er innlogget eller ikke. Dette bruker vi slik at andre, uten tillatelse, ikke kan skrive inn URL som fører dem frem til ønsket side. Hvis en bruker er innaktiv i mer enn 40min vil session slettes og bruker må logge inn på nytt. Session slettes også når bruker logger seg ut av systemet. Hvis det er slik at man logger ut, Det er minimalisert med Sessions på siden, da dette kjøres på server og ikke på klient. På både Klubben og Gilje vil det være liten sjanse for problem med for mange sessions, da databasen alltid vil inneholde få medlemmer i forhold til andre systemer. 9.7 Feilmeldinger Det blir kun vist feilmeldinger på brukerfeil i systemet. Dette gjelder blant annet på inputfelter(figur 2) og database spørringer som krever riktig data tastet inn av bruker. Disse feilmeldingene vil komme på samme side som man står på. Det er blitt brukt to typer feilsjekking på input. Den ene er ved feil data til database og hender etter at data fra skjermen har blitt sendt til controlleren: Feilmelding til bruker: Figur

122 Produktdokumentasjon I controller: if (brukerikkefinnes) { ModelState.AddModelError("brukernavnFeil", "Brukernavn finnes ikke"); return View(); } I new Og den andre typen som blir brukt for feil i input er å sjekke at alt som er skrevet inn er gyldig FØR noe kode bli utført på server. Dette vil hindre unødvendig bruk på servertrafikk samtidig at kun korrekt data blir lagt i databasen: Figur 15 I => m.passord) I model.class: [Required(ErrorMessage = "Passord må oppgis")] ErrorMessage = "Du må skrive et passord på minst 8 bokstaver!")] public string Passord { get; set; } Ved feil i MS-SQL eller ASP.NET kode vil feilmeldinger bli skrevet til loggfiler på server, mens en bruker vil kun få opp en standard feilmeldingsside. Ved feil når det skal hentes data blir følgende kode kjørt: 121

123 Produktdokumentasjon Controller: Figur 16 Og ved feil av innsetting/sletting av data i databasen: Controller: Figur 17 Hvis en bruker kjører kode som editerer databasen på noe vis, vil det ved feil alltid bli logget til fil på server med feilmelding og dato. Hvis det feiler på try-metoden, så vil den gå til catchmetoden og melde ifra til bruker ved hjelp av "ModelState.AddModelError": MainLayout.cshtml: Grunnen for at alt av feilmeldinger ikke blir vist til bruker er for å hindre at en person bruker feilmeldingene til ødeleggende hensikter. 122

124 Produktdokumentasjon 10 Referanser Galleria SlideShow med JQuery : CSS knapper farge: Placeholder for Editorfor: Regular expressions: Regular expressions: JavaScript C# developers: CSS generelt: ASP.NET MVC Forelesninger notater av Tor Krattebøl Team Foundation Server: Datoformatering Partial view Render Kalender Mail 123

125 Produktdokumentasjon 11 Vedlegg 11.1 Sitemap - "" Forside Bestilling Servering Galleri Om Gilje Kontakt oss Lokalet Historie Her finner du oss 11.2 Sitemap - " - Administrasjon" Nyheter Galleri Brukere Logg ut Slett nyheter Legg til nyheter Slett bilder Legg til bilder Gilje Hjemmeside Ny admin Gilje Ny admin Booking Slett admin Gilje Slett admin Booking 124

126 Produktdokumentasjon 11.3 Sitemap - " - Booking Administrasjon" Reverver Kalender Reservasjoner Logg ut Ny reservsjon Gilje Hjemmeside 11.4 Sitemap - "Klubben" Nyheter Dokumenter Medlemmer Miside Hjelp Administrasjon Logg ut Område + antall område som har tilgang til Endre profil Endre passord Logg inn Medlemmer Myheter Områder Opprett nytt medlem Endre 125

127 Produktdokumentasjon 11.5 Aktivitetsdiagram - "Registrer reservasjon" 126

128 Produktdokumentasjon 11.6 Aktivitetsdiagram - "Endre Profil" 127

129 Produktdokumentasjon 11.7 Aktivitetsdiagram - "Ny Administrator Booking" 128

130 Produktdokumentasjon 11.8 Aktivitetsdiagram - "Registrer medlem" 129

131 Produktdokumentasjon 11.9 UseCase - "" UseCase - "Klubben" 130

132 Produktdokumentasjon Sekvensdiagram - Adgangsområder Sekvensdiagram - Medlemsområder edit 131

133 Produktdokumentasjon Sekvensdiagram - Oppdater Medlemprofil Sekvensdiagram - Registrer admin 132

134 Produktdokumentasjon 133

135 2013 Hovedprosjekt 2013 Gruppe 27 Brukerdokumentasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie

136 Brukerdokumentasjon 135

137 Brukerdokumentasjon 1 Forord Dette er brukerdokumentasjonen til nettløsningene til Gilje AS. Dokumentasjonen omhandler to nettsteder, men vil bli behandlet i samme dokument da dette er en del av sluttdokumentasjonen i et hovedprosjekt utført ved Høgskolen i Oslo og Akershus. Nettløsningene vil bli omtalt under titlene "" og "Klubben". Begge løsningene er utviklet for Gilje, men har forksjellige funksjoner. "" vil være Gilje sitt ansikt utad på nettet med presentasjon, informasjon, kontaktinformasjon og mulighet for å sende forespørsel om leie av lokalet. "Klubben" er en medlemsportal for medlemmene av Klubben. Portalen har til hensikt å være en felles plass for medlemmene til å publisere nyheter, lagring av dokumenter og kontakt informasjon mellom medlemmene. Denne brukerdokumentasjonen er først og fremst beregnet på administrator og driftansvarlig til nettstedene. Brukere på nettside og portal skal få nødvendig veiledning på skjermen ved normal bruk og medlemmer av Klubben kan se "hjelp"-fanen når de er logget inn på portalen. Manualen er allikevel skrevet slik at man ikke skal trenge mer enn grunnleggende datakunnskaper for å få utbytte av manualen. 136

138 Brukerdokumentasjon 137

139 Brukerdokumentasjon 2 Innholdsliste 1 Forord Innholdsliste Presentasjon av nettstedene "" Brukerside av nettstedet Administratorside for nettstedet Administratorside for booking-del av nettstedet "Klubben" Funksjoner Tilgang Veiledning - Bruk av nettstedene "" Brukerside av nettstedet Administratorside for nettstedet Administratorside for booking-del av nettstedet "Klubben" Bruk av "Klubben" som vanlig medlem Bruk av "Klubben" som administrator Feil og rettingsmuligheter Vedlegg - Brukerveiledning "Klubben"

140 Brukerdokumentasjon 3 Presentasjon av nettstedene Her presenteres de to nettløsningene "" og "Klubben". Første del av manualen skal gi svar på hva programmene kan gjøre og den andre delen vil forklare hvordan brukeren skal gjennomføre de forskjellige oppgavene. For å holde løsningene fra hverandre blir de presentert med hver sin undertittel pr kapittel. Alle nettsidene skal gi brukeren den nødvendige informasjon for å finne frem eller bruke de forskjellige funksjonene. Om brukeren har unnlatt å skrive inn nødvendig informasjon i tekstfelt skal han/hun bli gjort oppmerksom på dette og programmet vil ikke gå videre. Lenker og tekstbokser er tydelig merket så brukeren skal orientere seg greit ved førstegangs bruk. 3.1 "" "" deles i tre deler med hvert sitt tilgangsnivå og hver sin funksjon. De ulike delene av denne nettløsningen med respektive funksjoner presenteres i dette kapittelet. Hensikten er å gi en kort innføring i de enkelte sidene med informasjon om hvem de er beregnet for og hva de har av funksjoner Brukerside av nettstedet "" er en enkel nettside som er beregnet på å gi brukeren informasjon om Gilje og deres utleielokale. Brukeren er gjester som søker på nettet etter informasjon om Gilje eller som ønsker å leie lokale i Askim eller distriktet rundt. Nettstedet skal gi informasjon, vise bilder, gi kontaktinformasjon, nyheter og informasjon om når lokalet er ledig for utleie. Om lokalet er ledig skal brukeren kunne legge inn en forespørsel som Gilje kan vurdere manuelt for så å gi tilbakemelding til brukeren. 139

141 Brukerdokumentasjon Administratorside for nettstedet For å administrere innholdet på siden er det laget en administratorside der administratoren kan gjøre endringer på enkelte elementer. For å få tilgang til dette området må brukeren ha passord og brukernavn. Designet for administratordelen er lik selve brukersiden med en viktig forskjell; for å visualisere for administratoren at han er på del av nettstedet med begrenset tilgang er bakgrunnen grå isteden for den gulaktige som brukes på brukersiden av nettstedet. Administratoren kan legge til og fjerne nyheter, legge til og fjerne bilder til galleri og administrere brukere/administratorer for både Gilje-administrasjon og bookingadministrasjon Administratorside for booking-del av nettstedet Booking har fått en egen innlogging og egen side for behandling av reservasjonsforespørsler som kommer inn. Dette er for at ansvar for utleie kan tas av andre enn Gilje selv. Designet på booking-administrasjonen er lik administratorsiden for Gilje. Grå bakgrunn med det samme gjennomgående designet som ellers på nettstedet. 140

142 Brukerdokumentasjon På booking-administrasjonen kan administratoren legge til ny utleieavtale, se ledig/utleid tid på kalender og slette reservasjoner. Reservasjoner kan sees både som liste og som elementer i kalender. 3.2 "Klubben" "Klubben" er en medlemsportal for medlemmer av Klubben. Alle som skal benytte portalen må være registrert med brukernavn og passord og må logge inn for å få tilgang til områdene. Portalen er i hovedsak en plass der medlemmer kan se nyheter som angår klubben, laste opp eller se dokumenter. Dessuten kan medlemmene se medlemsliste med kontaktinformasjon Funksjoner Funksjonene skal være selvforklarende og navigeringen skal være utformet slike at det skal være lett å finne fram uten inngående datakunnskaper. Vedlagt ligger en brukerveiledning som er lagt ut under "Hjelp" -fanen på "Klubben". Denne er ment som et skriv der medlemmene kan se hvordan de skal bruke funksjonene om de er i tvil. Designet skal gjære det enkelt for brukeren å navigere. Toppen av siden består av logo, logg-ut knapp og en meny. Denne delen er statisk og vil alltid være tilgjengelig for brukeren uansett hvor på siden han eller hun befinner seg. En del av menyvalgene vil aktivere en undermeny som gir ytterlige valg Tilgang Tilgangen er nivåbegrenset. Det vil si at brukeren er registrert med de tilgangene han eller hun skal ha. Tilgangen kan endres etter behov. Dette er noe administrator styrer. Administrator får opp en egen administrator-meny på venstre side av skjermen. Her er det tre valg som fører til administrasjon av medlemmer, nyheter og områder. 141

143 Brukerdokumentasjon 4 Veiledning - Bruk av nettstedene Funksjonene som er å finne i nettløsningene skal være selvforklarende, men her følger en veileding for bruk av funksjonene og navigering i de to løsningene. 4.1 "" De tre delene som utgjør "" sin nettløsning har svært få funksjoner og er i stor grad kun for å gi informasjon og promotere utleielokalet. Løsningen med bookingforespørsel og informasjonen på siden skal lette arbeidet med å leie ut lokalet og sørge for at Gilje blir mer synlige for potensielle kunder Brukerside av nettstedet Brukeren kommer inn på et brukergrensesnitt som er godt fra utallige nettsider rundt om på nettet. Øverste del av siden er statisk med logo og meny som gjør navigeringen rundt på nettstedet svært enkelt. I bunn av siden er en footer som markerer slutt på siden. Dette er et enkelt brukergrensesnitt som de fleste kjenner seg igjen i og brukeren vil intuitivt skjønne hvor informasjonen finnes. Veiledningen vil omfatte to enkle funksjoner for brukersiden: Se på galleri Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Se på Galleri Se bilder i stort format fra galleriet Åpner bildene i et overlappende lag på siden, velge bilder Museklikk på galleriet Når brukeren går inn på galleri via menylinjen øverst på siden kan han/hun klikke på det store bildet for å åpne dette i stort format. Bildet blir da åpnet i ett eget lag over nettsiden. Brukeren kan bla frem og tilbake med piltaster på høyre og venstre side og lukke med kryss øverst i høyre bildehjørne. 142

144 Brukerdokumentasjon Legge inn forespørsel om reservasjon Navn: Booking-forespørsel Formål: Legge inn forespørsel om leie av lokalet Hva rutinene gjør: Viser ledige datoer på kalender og sender inndata fra bruker til administrator for booking Inndata: Museklikk og innskrevet tekst i tekstbokser Hvordan bruke rutinen: Brukeren kommer inn på siden via linken "Bestilling". Her kan han se i kalenderen om ønsket dato er ledig. Deretter kan brukeren velge å legge inn en forespørsel. Brukeren fyller inn feltene "Ditt navn", "Din Epost", "Emne" og "Forespørsel" som er fritekst. Når informasjon er fylt inn kan brukeren trykke på knappen "Send epost". Forespørselen vil dermed bli sendt og behandlet av bookingansvarlig hos Gilje. 143

145 Brukerdokumentasjon Administratorside for nettstedet Brukeren kommer inn på en side som har samme design som hovedsiden. Designet skiller ved at menyvalgene er annerledes og bakgrunnen er grå for de brukerbegrensede områdene Logge inn Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Logge inn Logge inn på administratordel av nettløsningen. Sjekker og godkjenner bruker ved riktig oppgitt brukernavn og passord. Inndata i inndatafelter Logg inn er skjult for gjester og må derfor skrives manuelt inn i adressefeltet. Adressen må tillegges: "/AdminGilje". Brukeren har to felt som skal fylles inn: "Brukernavn" og "passord". Når data er fylt inn kan brukeren trykke "Logg inn". Om inndata er riktig vil brukeren komme på forside for administratordelen av nettstedet. 144

146 Brukerdokumentasjon Slette nyheter Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Slette nyheter Slette gamle nyheter Sletter nyheter fra databasen Museklikk Brukeren får listet opp nyhetene som startside på administratordelen eller ved å klikke på menyvalg "Nyheter". Under hver nyhet er det en knapp/lenke med teksten "(Slett denne nyheten)". Ved å trykke på denne bli nyheten slettet Legg til nyhet Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Legge til nyheter Legge til ny nyhet Legger til nyhet i databasen Tekstboks Ved å klikke på "Legg til nyheter" under "Nyheter" kan brukeren skrive inn tekst i tekstfeltet og så trykke på knappen "Legg til nyhet". Om det er skrevet inn noe i tekstfeltet vil nyheten legges til i databasen og brukeren går tilbake til "Slett nyheter" -siden der alle nyheter, inkludert den nyeste, listes opp. 145

147 Brukerdokumentasjon Slett bilde Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Slett bilde Slett gammelt bilde Sletter bildefil fra server og bildereferanse fra databasen Museklikk Ved å klikke på menylenken "Galleri" vil alle bildene listes opp. Under hvert bilde er det plassert en knapp/lenke med teksten "(Slett dette bildet)". Ved å klikke på denne lenken blir bildefilen slettet fra server og referansen blir slettet fra server. 146

148 Brukerdokumentasjon Legg til bilde Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Legg til bilde Legg til nytt bilde Laster opp bildefilen og lager referanse i databasen Museklikk Brukeren går via "Galleri" i menylinjen og velger "Legg til Bilder" i menyvalg på venstre side. Brukeren trykker på knappen "Velg fil" og finner frem til aktuelt bilde og trykker "Open". Brukeren bekrefter og avslutter ved å trykke på knappen "Last opp". Brukeren kommer da tilbake til "Slett bilder" -siden der alle bildene, inkludert det nyeste, er listet opp. 147

149 Brukerdokumentasjon Administrer brukere Legg til admin og slett admin er lik for Gilje og Booking -delen. Derfor blir de omtalt med totalt to eksempler: ett for å legge til og ett for å fjerne. Ny Admin har to knapper: "Ny admin Gilje" og ny admin Booking". Slett admin har to knapper: "Slett admin Gilje" og "Slett admin Booking". I eksempelet her omtales de som "Ny admin" og "Slett admin". Alle valgene finnes i menyen til venstre under menyvalget "Brukere" Legg til admin Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Legg til admin Legg til admin for henholdsvis Gilje og Booking Legger til ny administrator i databasen med passord i hashform. (Passordet kan ikke hentes ut i klartekst) Tekstbokser Brukernavn, passord og fullt navn fylles inn. Passordet vises ikke i klartekst. Når all informasjon er på plass trykker brukeren på "Registrer" 148

150 Brukerdokumentasjon Slett admin Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Slett admin Slett administrator fra nettstedet Sletter administrator fra databasen slik at kontoen ikke lenger eksisterer Museklikk Ved å klikke på "Slett admin" blir alle registrerte administratorer listet opp. Til venstre for navnet er det plassert en knapp/lenke: "Slett". Ved å klikke på denne blir den aktuelle administratoren slettet Logg ut Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Logg ut Logge ut fra Gilje Admin Logger ut. Hindrer tilgang til brukerbegrenset område uten ny innlogging Museklikk Så lenge bruker er logget inn på administratordelen av Gilje vil knappen "[LOGG UT]" være synlig til høyre under menylinja. Ved å klikke på denne blir brukeren logget ut og sendt til Gilje sin hovedside. 149

151 Brukerdokumentasjon Administratorside for booking-del av nettstedet Administrator har mulighet for å legge til/slette nyheter, legge til/slette galleribilder og legge til/slette administratorer for både nettsiden og booking Logg inn Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Logge inn Logge inn på administratorbooking Sjekker og godkjenner bruker ved riktig oppgitt brukernavn og passord. Inndata i inndatafelter Logg inn er skjult for gjester og må derfor skrives manuelt inn i adressefeltet. Adressen må tillegges: "/AdminBooking/Booking". Brukeren har to felt som skal fylles inn: "Brukernavn" og "passord". Når data er fylt inn kan brukeren trykke "Logg inn". Om inndata er riktig vil brukeren komme på forside for administratorbooking. 150

152 Brukerdokumentasjon Reserver Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Reserver Reservere utleie Legger inn en reservasjon med informasjon om hvem som skal leie, kontaktinformasjon, tid, formål osv. Inndata i inndatafelter Reserver er startsiden etter innlogging til Gilje Booking. Menyvalget "Reserver" brukes fra andre deler av GiljeBooking - siden. En reservasjon blir lagt inn ved å fylle inn feltene: "Navn", "Epost", "Tlf", "Start dato", "Slutt dato", "Formål" og "Etasje". Når all informasjon er på plass blir reservasjonen bekreftet ved å trykke på knappen "Lagre" Kalender Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Kalender Vise reservasjoner Viser reservasjoner visuelt i kalender Museklikk Kalender viser reserverte tider for lokalet. Visningen kan veksles mellom dag, uke eller måned. Det er en knapp for å komme til dagen i dag og knapper for å bla frem og tilbake i kalenderen også. 151

153 Brukerdokumentasjon Reservasjoner Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Reservasjoner Vise reservasjoner Viser reservasjoner som en liste med mulighet for å slette reservasjoner Museklikk Reservasjonene listes som en liste med all informasjon på en linje med en knapp/lenke på enden med tittel "Slett". Om man bruker denne knappen blir valgte reservasjon slettet fra databasen. Reservasjonen er dermed borte fra liste og kalender. 152

154 Brukerdokumentasjon 4.2 "Klubben" Medlemsportalen til Klubben er en felles plass for medlemmer av klubben og inneholder ikke veldig mange funksjoner. Medlemmene kan se nyheter og andre medlemmer, men den viktigste funksjonen er arkivering av dokumenter. Dokumenter kan lastes opp under forskjellige kategorier med forkjellig brukertilgang Bruk av "Klubben" som vanlig medlem Medlemmene får tilgang til de dokumentklassene de trenger. Dokumentene ligger i predefinerte kategorier og for hver enkelt bruker kan administrator velge kategorier som skal være tilgjengelig for den enkelte bruker. Selv om antall dokumentkategorier vil variere fra bruker til bruker er funksjoner og virkemåte helt lik Logg inn Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Logge inn Logge inn på "Klubben" Sjekker og godkjenner bruker ved riktig oppgitt brukernavn og passord. Inndata i inndatafelter Logg inn er den første siden brukeren kommer inn på. Dette gjelder uansett om han eller hun prøver å gå direkte til en av sidene inne på sikret område. Brukeren har to felt som skal fylles inn: "Brukernavn" og "passord". Når data er fylt inn kan brukeren trykke "Logg inn". Om inndata er riktig vil brukeren komme på forside for administratordelen av nettstedet. 153

155 Brukerdokumentasjon Laste ned dokument og slett dokument Navn: Laste ned dokument Formål: Laste ned dokument fra "Klubben" Hva rutinene gjør: Lister alle dokumenter under valgt kategori og gir mulighet til å laste ned eller slette Inndata: Museklikk Hvordan bruke rutinen: Når brukeren velger "Dokumenter" fra menylinjen vil han få opp alle tilgjengelige kategorier som en undermeny til hovedmenylinjen. Ved å velge en kategori vil brukeren få en liste med alle dokumenter i kategorien. Ved å trykke på dokumentnavnet/filnavnet vil brukeren laste ned dokumentet. Brukeren kan også velge å slette dokumentet fra portalen ved å trykke på "Slett" knappen/lenken som er plassert til høyre for filnavnet. 154

156 Brukerdokumentasjon Laste opp dokument Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Laste opp dokument Laste opp dokument på "Klubben" Laster opp valgfritt dokument til valgt kategori Inndata i inndatafelter Brukeren velger "Dokumenter" fra hovedmeny og den aktuelle kategorien det nye dokumentet skal lastes opp til. På høyre side av skjermbildet vil overskriften "Last opp fil" tydelig indikere hvor funksjonen befinner seg. Bruker må legge inn beskrivelse/navn, dato og klikke på knappen "Velg fil" for å finne filen som skal lastes opp. Når filen er valgt trykker brukeren på "Open" før knappen "Lagre" bekrefter at filen skal lastes opp. 155

157 Brukerdokumentasjon Søk i medlemmer Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Søk i medlemmer Søk i medlemsliste Søker i medlemsliste Søkefelt Når brukeren velger "Medlemmer" i hovedmenyen blir alle medlemmene listet opp. Øverst på siden er det plassert en søkeboks. Ved å skrive inn deler av navnet eller fullt navn her etterfulgt av trykk på knappen "Søk" vil kun treff i medlemslisten bli listet opp. 156

158 Brukerdokumentasjon Endre personlig informasjon og passord Navn: Endre personlig informasjon og passord Formål: Endre personlig informasjon og passord Hva rutinene gjør: Endrer personlig informasjon og passord Inndata: Tekstfelt og museklikk Hvordan bruke rutinen: Når brukeren velger "Min side" i hovedmenyen vil han/hun se personlig informasjon bli listet. I bunn av listen er det plassert to knapper/lenker: "Endre" og "Endre passord". Ved å trykke på "Endre" kan brukeren endre den personlige informasjonen som er registrert. Ved å trykke på "Endre passord" kan brukeren endre passordet sitt. For å endre passord må brukeren først taste inn gammelt passord før nytt passord og bekreft passord skrives inn. Dersom det gamle passordet er riktig og nytt passord og bekreft passord er like vil passordet være byttet. 157

159 Brukerdokumentasjon Logg ut Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Logg ut Logge ut Logger ut så brukeren må logge inn for å få tilgang til portalen igjen. Museklikk Øverst til høyre i vinduet vil knappen/lenken "[Logg ut]" hele tiden være tilgjengelig. Ved å klikke på denne vil brukeren bli logget ut og ingen av sidene på portalen vil være tilgjengelig før riktig innlogging er utført igjen. 158

160 Brukerdokumentasjon Bruk av "Klubben" som administrator Administrator har rettigheter på alle dokumentkategoriene og har muligheter til å administrere medlemmer, nyheter og områder. Alle funksjonene som andre brukere har er selvfølgelig tilgjengelig og vil ikke bli gjentatt her. Funksjoner som er unike for administrator vil presenteres i de neste underkapitlene. Ved å klikke på knappen/lenken "Administrator" oppe i høyre hjørne på nettsiden vil administratoren få opp en egen meny på venstre side av vinduet. Det er kun administratorer som får denne muligheten Endre, slett og legg til medlem Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Endre, slett og legg til medlem Endre, slette og legge til medlemmer Endrer, sletter og legger til medlemmer Tekstfelt og museklikk Ved å velge "Medlemmer" øverst på administratormenyen vil alle medlemmer i portalen listes opp. Øverst er en knapp/lenke som administrator bruker for å opprette nye medlemmer. Hvert medlem er representert på hver sin linje. Til høyre på linjen er det to knapper/lenker: "Endre" og "Slett". Ved å trykke på "Slett" blir brukeren slettet. Ved å trykke på "Endre" kan administrator endre alt av personlig informasjon på brukeren. Dessuten kan administratoren her endre hvilke dokumentkategorier brukeren skal ha tilgang til. I utgangspunktet får brukeren ikke tilgang til noen kategorier så her må alle medlemmer behandles manuelt.. 159

161 Brukerdokumentasjon Legg til og slett nyheter Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Legg til og slett nyheter Legg til og slett nyheter Legger til og endrer nyheter Tekstfelt og museklikk Ved å velge "Nyheter" i administratormenyen vil alle nyhetene bli listet opp med tittel, tekst og en knapp/lenke for å slette den aktuelle nyheten. På siden er det også to tekstfelter: "Tittel" og "Tekst" der administratoren kan fylle inn ny nyhet. Ved å klikke på knappen "Lagre" vil nyheten lagres og bli synlig for andre brukere på portalen. 160

162 Brukerdokumentasjon Endre områder Navn: Formål: Hva rutinene gjør: Inndata: Hvordan bruke rutinen: Endre områder Endre navn på områder Endrer navn på områder Tekstfelt og museklikk Ved å velge "Områder" i administratormenyen vil alle områdene bli listet opp med nummer i forkant. Det er lagt inn 7 områder men navn på områdene er valgfritt. Ved å endre navn på områder og trykke på knappen "Endre" vil endringen lagres og være synlig for alle brukere av portalen med tilgang til det aktuelle nivået. 161

163 Brukerdokumentasjon 5 Feil og rettingsmuligheter Innfelter på nettstedene blir sjekket med regular expression, det vil si at brukeren skal skrive i påkrevde felt og det som blir skrevet skal følge gitte regler for input. I dette ligger det at brukeren ikke kan taste inn informasjon som har til hensikt å skade nettstedet eller unnværer å taste inn påkrevet informasjon. Om brukeren taster inn ikke-godkjent tekst eller glemmer å fylle inn vil brukeren bli gjort oppmerksom på dette via skjermen. En melding vil fortelle om feilen og hva brukeren må gjøre for å komme videre. Deler av nettstedet som krever innlogging tester på hver enkelt side at brukeren er logget inn og godkjent. Dette er for at brukeren ikke kan skrive adresse til administratorside i adressefeltet. I tilfelle vil brukeren komme til innloggingsside i stedet for den brukerbegrensede delen. 162

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm Hovedprosjekt i informasjonsteknologi 2016 Høyskolen i Oslo og Akershus Forprosjektrapport Digitalt læreverktøy for Cappelen Damm Gruppe 26 Sofia Aittamaa - s198580@stud.hioa.no Petter Lysne - s198579@stud.hioa.no

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Entobutikk 4.PROSESSRAPPORT VÅR 2011 4.PROSESSRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen

Detaljer

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren

Detaljer

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

Dokument 3 - Prosessdokumentasjon

Dokument 3 - Prosessdokumentasjon Dokument 3 - Prosessdokumentasjon Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Dokument 3 - Prosessdokumentasjon Innholdsfortegnelse

Detaljer

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

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

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2008-18 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

Detaljer

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

Detaljer

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9 Forprosjektrapport Gruppe 17 Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen Side 0 av 9 Innholdsfortegnelse: Presentasjon - Service Broker AS - Kontaktpersoner Sammendrag Dagens situasjon Mål og

Detaljer

Skøyen, 23.01.14 Gruppe 11

Skøyen, 23.01.14 Gruppe 11 Forprosjektrapport Produktkvalitet, visitnorway.com Sammendrag Vi skal gjennomføre et produktkvalitetsprosjekt hos Creuna i forbindelse med visitnorway.com, Innovasjon Norges turistinformasjonsside. Prosjektet

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

Forprosjekt - Gruppe 12. Hovedprosjekt av

Forprosjekt - Gruppe 12. Hovedprosjekt av FORSIDE A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S Forprosjekt - Gruppe 12 Hovedprosjekt av S AJ ID, OZAI RE (S 1711 9 7), S VEEN, S IMEN (S171208),

Detaljer

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1 ID Name Duration Start Finish 1 Planlegging 95 days Mon 02.10.06 Fri 09.02.07 2 Statusrapport 20 days Mon 02.10.06 Fri 27.10.06 3 Prosjektskisse 25 days Mon 30.10.06 Fri 01.12.06 4 Prosjektweb 31 days

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

Forord... 3. Planleggingsprosess... 4. Prosjektstart... 4. Arbeidsmåte/Fremgangsmåte... 4. Begreper innenfor Scrum... 5. Datainnsamling...

Forord... 3. Planleggingsprosess... 4. Prosjektstart... 4. Arbeidsmåte/Fremgangsmåte... 4. Begreper innenfor Scrum... 5. Datainnsamling... 1 Innholdsfortegnelse Forord... 3 Planleggingsprosess... 4 Prosjektstart... 4 Arbeidsmåte/Fremgangsmåte... 4 Begreper innenfor Scrum... 5 Datainnsamling... 6 Styringsdokumenter... 6 Dagbok... 7 Rissikoplanlegging...

Detaljer

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og

Detaljer

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Kravspesifikasjon Innholdsfortegnelse

Kravspesifikasjon Innholdsfortegnelse Kravspesifikasjon Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:... 2 1.3 Kontaktsperson hos Retriever:... 2 1.4 Veileder:... 2 1.5 Bakgrunn... 3 2. Om Kravspesifikasjonen...

Detaljer

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 22.01.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Meso

Detaljer

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg

Detaljer

Gruppe 33 - Hovedprosjekt

Gruppe 33 - Hovedprosjekt Gruppe 33 - Hovedprosjekt s188080 Joakim Rishaug s181130 Sondre Sparby Boge s188098 Martin Hagen s178816 Lars Erik Kasin 1 av 7 Kravspesifikasjon Forord Kravspesifikasjonen utformes både for kunden, og

Detaljer

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

4.5 Kravspesifikasjon

4.5 Kravspesifikasjon 4.5 Kravspesifikasjon 4.5.1 Funksjonalitet og systembeskrivelse Webapplikasjonen har tre overordnede funksjoner; Opprett Spotify arrangement, Opprett SoundCloud arrangement og Bli med på arrangement. Brukere(kalt

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer

Pedagogisk regnskapssystem

Pedagogisk regnskapssystem av Benjamin Dehli og Jørgen Tellnes Innhold 1 Innledning 2 Om forprosjektet 2.1 Forprosjektgruppen 2.2 Målsetninger med forprosjektet 3 Beskrivelse av hovedprosjektet 3.1 Arbeidstittel 3.2 Prosjektgruppe

Detaljer

Styringsdokumenter. Forord

Styringsdokumenter. Forord 8 Styringsdokumenter Forord Dette er en samling av samtlige styringsdokumenter gjennom hele prosjektperioden. Styringsdokumentene er satt opp i rekkefølge i forhold til leveringsfrister Dokumentene ble

Detaljer

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av: Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

Detaljer

Tjenestebeskrivelse Webhotelltjenester

Tjenestebeskrivelse Webhotelltjenester Tjenestebeskrivelse Webhotelltjenester Sist endret: 2004-12-01 Innholdsfortegnelse 1 INTRODUKSJON... 3 1.1 GENERELT... 3 1.2 NYTTEVERDI WEBHOTELLTJENESTER FRA TELENOR... 3 2 FUNKSJONALITET... 4 2.1 INNHOLD

Detaljer

Samarbeidsløsning for FHS, Teknisk info

Samarbeidsløsning for FHS, Teknisk info Samarbeidsløsning for FHS, Teknisk info 1. Kontorstøtte Samarbeidsløsningen som FHS-kontorene har etterspurt må forholde seg til kontorstøttesystemer, e-post, kalender og kontakter. Dette har egentlig

Detaljer

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1 HiOA TDK Ingeniørfag data DATS1600 Programutvikling Eva Hadler Vihovde Prosjektoppgaven 2015 - Prosessdokumentasjon - Alternativ 1 - Forsikring - Gruppe #14 Studentnavn Marius Alexander Skjolden Hans Christian

Detaljer

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Hovedprosjekt 2008 av Audun M. Solheim, student HIST/BAIN, audun@c2i.net Oppdragsgiver:Bjørg Minnesjord Solheim, bjorg@midt-svartdal.no

Detaljer

3. Prosessrapport. Forord

3. Prosessrapport. Forord 3. Prosessrapport Forord Prosessrapporten er utarbeidet i forbindelse med hovedprosjekt våren 2015 ved Høgskolen i Oslo og Akershus. I denne rapporten vil vi beskrive prosessen bak utviklingen av publiserings-

Detaljer

Produktdokumentasjon

Produktdokumentasjon Produktdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer

Detaljer

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON CHARITY DOCTORS KRAVSPESIFIKASJON Hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo våren 2011 Gruppe 13 Muleha Nhonzi Harlem Tambwe Mufoncol Ruban Amuthalingam Page 1 of 6 1 Innledning 1.1 Innledning

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Brukerdokumentasjon for LabOra portal - forfattere

Brukerdokumentasjon for LabOra portal - forfattere Brukerdokumentasjon for LabOra portal - forfattere Skin: Dnnbest-Grey-Skin1024 Skin: Metro7 Custom LabOra web-portal er et web-basert publiseringsprogram for publisering av informasjon på hjemmesider.

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive,

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive, 1. Last ned og installer XAMPP. 2. Sjekk at alt fungerer. 3. MySQL. Vi begynner med databaseserveren, MySQL. Gå til DOS klarmelding eller ledetekst (finnes under tilbehør på startmenyen om du ikke som

Detaljer

Forprosjektrapport. Medlemsdatabase for Amnesty International Juridisk Studentnettverk. Høgskolen i Oslo og Akershus

Forprosjektrapport. Medlemsdatabase for Amnesty International Juridisk Studentnettverk. Høgskolen i Oslo og Akershus 2012 Høgskolen i Oslo og Akershus Margit Cecilie Haugen s163289 Pernille Mohn s163300 Tonje Henriksen s156049 Forprosjektrapport INNHOLDSFORTEGNELSE Presentasjon... 2 Sammendrag... 2 Om bedriften... 2

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

F O R P RO S J E K T R A P P O R T

F O R P RO S J E K T R A P P O R T A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G F O R P RO S J E K T R A P P O R T Dato for levering: 01.02.2008 Versjon Nr. 1,72 Gruppe: 08-18 Webside: http://student.iu.hio.no/~s135462/hovedprosjekt/

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Supplerende Kommunikasjon Assistent (SKA) Bachelorprosjektet går

Detaljer

Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2

Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2 PROSJEKT NR. 2007-02 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Forprosjektrapport MetaView

Forprosjektrapport MetaView Forprosjektrapport MetaView BACHELOROPPGAVE VÅREN 2014 Presentasjon Tittel: MetaView Oppgave: Utvikle en Windows 8 applikasjon som skal forenkle en liten del av MetaVision. Et verktøy for sykehus, leger

Detaljer

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006 PRESENTASJON Prosjektnr: 43E Prosjektnavn: BILs nettsider Elev: Jone Tveitane Dato: 17.12.2006 1 INNHOLDSFORTEGNELSE 1 OPPGAVESTILLER... 3 2 PROBLEMSTILLING... 3 3 HVORFOR DENNE OPPGAVE... 3 4 HVORDAN

Detaljer

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

Detaljer

S y s t e m d o k u m e n t a s j o n

S y s t e m d o k u m e n t a s j o n S y s t e m d o k u m e n t a s j o n Monitorering av produksjonsløyper ved Nasjonalbiblioteket - Project BAKE Utarbeidet av: Einar Wågan Kristian Akerhei Studium: Informasjonssystemer Innlevert: 26.5.2015

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

En innføring i bruk. Skype for Business Online. Viste du at: Skype for Business Online kan kommunisere med eksterne brukere?

En innføring i bruk. Skype for Business Online. Viste du at: Skype for Business Online kan kommunisere med eksterne brukere? Viste du at: En innføring i bruk av Skype for Business Online Skype for Business Online kan kommunisere med eksterne brukere? Skype for Business kan kommunisere med vanlig Skype? Skype for Business leveres

Detaljer

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen Prosjekt nr. 2007-11 Prosessrapport Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen, s130182 Espen Skaarer, s123590 Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

CharityDoctors. Prosessrapport

CharityDoctors. Prosessrapport CharityDoctors 1. FORORD Beskrivelse i denne rapporten tar for seg hvordan prosjektet har vært utviklet i hele prosjekt perioden. Her forklarer vi hvordan prosessen har vært og begrunnelser for de valgene

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer