Hovedprosjekt Høgskolen i Oslo 2010

Transkript

1 1

2 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Administrativsystem for Tønsberg Seilforening DATO ANTALL SIDER / BILAG 99 PROSJEKTDELTAKERE Erik Andreassen, Ehsanullah Zadran, Marit Helene Foss, Shahzeb Akhtar, Mona Aziz Hamed INTERN VEILEDER Steinar Johannesen, Førsteamanuensis, Allmennfag, HIO OPPDRAGSGIVER Tønsberg Seilforening KONTAKTPERSON Erik Fusdahl SAMMENDRAG Prosjektet består i hovedsak av å lage et arrangementsystem for Tønsberg seilforening. Dette er noe de har savnet i lang tid da de i dag bruker penn og papir og enkeltstående datadokumenter. 3 STIKKORD Administrasjonssystem Ny teknologi Organisasjon 2

3 Forord Denne rapporten er et resultat av arbeidet vi har gjennomført som et team igjennom det siste halve året i hovedprosjektet Administrasjonssystem for Tønsberg Seilforening. Denne prosjektrapporten gir en detaljert beskrivelse av alle fasene vi gikk gjennom under hovedprosjekt ved Høgskolen i Oslo, avdeling for ingeniørutdanningen våren Vi har jobbet aktivt med å formulere rapporten best mulig slik at det er forståelig også for personer uten teknisk innsikt. Språket på systemet er engelsk. Dette litt pga at Tønsberg Seilforening av og til henter inn utlandske trenere. Språkvalget er også valgt med tanke på eventuell spredning. Men vi har prøvd å holde språket enkelt. Denne rapporten kan fungere som en guide for brukere som er interessert i, eller skal sette opp et slikt system selv. Med noen små justeringer og utvidelser kan systemet implementeres og brukes i flere kommuner og eventuelt på landsbasis. Vi ønsker å rette en stor takk til noen enkelte personer - Tor Krattebøl, kontaktperson for hovedprosjekt for datalinjen som hjalp oss med finne en prosjektoppgave. - Erik Fusdahl, ekstern veileder for å ha gitt oss en tydelig og lettfattelig kravspesifikasjon. Og gitt oss den tekniske friheten til å utvikle web løsningen. Erik Andreassen Perez Shahzeb Akhtar Marit Helene foss Ehsanullah zadran Mona Aziz 3

4 Styringsdokumentasjon 4

5 Prosjektskisse Hovedprosjekt Høgskolen i Oslo, våren 2010 Prosjektskisse Sted og dato: Oslo, 04. desember Tittel: Administrasjonssystem for Tønsberg Seilforening Gruppemedlemmer: Erik Andreassen, Ehsanullah Zadran, Shahzeb Akhtar, Marit Foss, Mona Aziz Oppdragsgiver: Tønsberg Seilforening Pb. 73, 3106 Nøtterøy, Husøysund E-post: tonsberg.sf@online.no Kontaktperson: Erik Fusdahl E-post: erik.fusdahl@kemppi.com Bedriften: Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som for eksempel SpareBank1, Esso, Vakt Service og noen andre. Prosjektet: I forbindelse med arrangementer, trenger de et system som administrerer ulike vakter til enhver tid. Her er det noen krav som de har satt opp for en eventuell løsning Planlegge, tidfeste, definere og beskrive ulike vakter for ulike arrangementer - generelt for Klubbkomiteen (kiosk, kjøkken, avfall, renhold), Regattakomiteen (startbåt, sikringsbåt, bøyebåt, organisering land under arrangementer osv) Alle vakter fordeles på tilgjengelige grupper som tur/hav, jolle, etc. og hvert medlem kan følge dette på nett Alle vakter for alle arrangementer bør kunne legges ut på nett med mulighet for elektronisk påmelding/registrering av frivillige. Gjerne med aktivering av mobilnummer for utsendelse av påminnelse for vakt Arkiv for internt bruk, erfaringsdatabase med kommentarfelt, innkjøp etc. Målsetningen må være å få et enkelt effektivt system som definerer behov, administrere på melding og sender reminder til vaktene pr. mail eller mobil. Gruppen har per dags dato tenkt litt på ulike verktøy i forbindelse med å utvikle en driftsikker løsning, og har kommet frem til at en av de aktuelle kandidatene for utviklingen er utviklingsmiljøet ASP. NET med MSSQL. 5

6 Prosjektdagbok (Vi valgte og ikke legge ut dagboken på en felles fil som anbefalt da vi har jobbet mye sammen før og viste at vi kunne stole på hverandre. Eventuelle ubehagligheter tok vi heller opp på våre gruppemøter. Dagboken er derfor skrevet av samme person hele veien da vi følte at dette ble mindre rot. Dagboken er de første månedene skrevet i slutten av måneden og er basert på stikkord som er nedskrevet i løpet av måneden. Vi valgte å gjøre det slik da dette var en periode med mye gruppemøter bestående av snakking i forhold til faktisk jobbing. De andre månedene er skrevet ukentlig) Oktober 2009 I løpet av oktober har vi tenkt veldig på hva vi har hatt lyst på å jobbe med som vårt hovedprosjekt ved HiO. På våre gruppemøter så vi litt på forslagene som skolen hadde lagt ut men en del av disse var litt skumle med tanke på kompetansenivå. Noen av dem var også for små i forhold til at vi er en stor gruppe på fem personer. På møtene våre diskuterte vi også litt rundt hvem som burde være gruppeleder. Vi kom sånn delvis fram til at Erik Andreassen burde fylle denne rollen. Utenom forslagene som skolen har lagt ut har vi vært i kontakt med Østensjø Rederi og Geelmuyden-Kiese. Sistnevnte virket veldig interesserte men siden de brukte litt lang tid på å svare måtte vi dessverre se bort i fra disse. Da fristen for innlevering av statusrapport nærmet seg ( )og vi fortsatt var uten et prosjekt følte vi behovet for å snakke med Tor Krattebøl. Han var veldig behjelpelig og nevnte at han hadde fått en e-post fra Tønsberg Seilforening. Disse ønsket seg et datasystem som kunne holde litt orden på vaktposter osv. ved arrangementer som de arrangerer i sommerhalvåret. Vi diskuterte/vurderte veldig om dette passet vårt kompetansenivå og kom fram til at det kunne bli utfordrende. Men vi valgte å ta på oss dette prosjektet allikevel da litt utfordring er motiverende. En prosjektdagbok ble påbegynt og det ble Marit som fikk denne oppgaven. (Se begrunnelse og forklaring øverst). Det ble også startet et system på å dokumentere hva gruppen snakket om når de var samlet. Denne oppgaven falt i hovedsak på Marit da hun skulle skrive dagboken fortløpende gjennom prosessen. Men hun fikk også Mona med som hjelp. November 2009 Nå som prosjekt endelig var bestemt begynte vi å tenke litt forsiktig på hva slags verktøy vi ville bruke i selve utviklingen. Vi tok også kontakt med Tønsberg Seilforening på e-post og fikk en kontaktperson, Erik Fusdahl. Etter kort tid fikk vi tilsendt en e-post med noen funksjonelle krav og litt annen nyttig informasjon. Vi brukte også noen gruppemøter til å diskutere hvilket språk vi ville bruke til utviklingen av systemet. De to språkene det sto imellom var ASP.NET med MSSQL og PHP. Men noen klar avgjørelse ble foreløpig ikke tatt. Desember 2009 Etter som desember er en måned med mye eksamen og ferie ble det gjort så å si ingenting denne måneden så fort prosjektskissen var levert den 4. desember. God jul og godt nyttår. Januar 2010 (Uke 1) Etter en velfortjent ferie kom vi tilbake på skole i januar med motivasjon for å begynne med forprosjektet som skulle leveres inn i slutten av måneden. Vi snakket litt om hva vi trengte av informasjon for å komme i gang med planleggingen av prosjektet. Og vi kom da fram til at vi måtte begynne med datainnsamling. Denne uken og litt ut i neste ble satt av til dette. Vi lagde også samlet et tankekart slik at vi kunne bli enig om en måte å løse problemet vårt på. Uten om dette kartla vi hvilke kunnskaper og ferdigheter de enkelte på gruppen hadde. Siden vi har blitt ganske godt kjent gjennom de to siste årene bød ikke dette på de store overraskelsene. Men det var greit å forhøre seg om hva hver enkelt kunne tenke seg å jobbe mest med. 6

7 (Uke 2) Etter å ha jobbet med et tankekart som nå var ferdig kom vi fram til å dele prosjektet i tre deler (delprosjekter). Frontend (synlig for bruker), backend (selve systemet) og design. Med en slik fordeling tenkte vi at man konsentrerte seg mer om hver sin del samtidig som vi fikk økt samarbeid med hverandre. Men en grunnforutsetning var selvfølgelig at vi hadde kommunikasjon på høyt nivå, slik at vi visste hvordan det gikk, hva som eventuelt må endres, eller hvor det trengtes hjelp. Første utkast til fordelingen av gruppemedlemmene på de ulike delene så slik ut: Frontend: Marit Foss og Mona Aziz og Erik Andreassen. Backend: I hovedsak Erik Andreassen og Ehsanullah Zadran som en god sidekick. Design: Shahzeb Akhtar, men også Erik Andreassen og Ehsanullah Zadran som javascript og skjema ansvarlig. Ellers så ble designen og frontend noen vi ble enig om at alle har lov å kommentere på. Noe faktisk koding av system ble enda ikke påbegynt, men vi fortsatte å diskutere om ASP.NET Skulle bli det endelige språket. (Uke 3) Denne uken tok vi for oss styringsdokumenter som arbeidsplan og fremdriftsplan. Mona meldte seg frivillig til dette og da fikk hun selvsagt lov til gjøre den oppgaven. Marit skulle hjelpe til om det var et behov. Da selve kodingen ikke er påbegynt enda fikk de andre gruppemedlemmene ikke noe store oppgaver, men de skulle begynne å tenke litt på hvordan de så for seg at systemet skulle bli. Særlig da Erik og Ehsan siden deres oppgave er backend delen. Shahzeb skulle begynne å leke seg litt med design til en nettside. Arbeidsplanen ble ferdig i starten av uka. (Uke 4) Fremdriftsplanen ble ferdig i starten av uka. Utformingen av forprosjektrapporten som skulle leveres i slutten av uka ble påbegynt onsdag. Vi brukte dessuten tid på å bestemme en gruppeleder da dette ikke var gjort tidligere. Dette avgjorde vi med avstemning. Erik Andreassen ble da valgt som gruppeleder. Mona ble valgt som sekretær til Erik og fikk blant annet ansvar for å holde orden på frister. Bakgrunnen for valgene var at de begge er veldig pliktoppfyllende. Arbeidet med forprosjektrapporten ble ferdigstilt fredag 29.januar og ble levert i tide. Kontrakten mellom oss og arbeidsgiver ble også underskrevet og send til oppdragsgiver i løpet av denne uka. Februarn2010 (Uke 5) Etter at forprosjektet var levert innså vi at vi kunne trenge å møte oppdragsgiverne våre. Ehsan fikk dermed ansvaret for å starte en e-post korrespondanse slik at vi kunne få til et slikt møte. Vi var klar over på forhånd at avstanden mellom oss og oppdragsgiver, som holder til i Tønsberg, kunne bli et problem. I forbindelse med dette snakket vi en del om hvem som skulle reise til Tønsberg dersom et møte skulle holdes der. Vi kom da fram til at Erik som gruppeleder var et selvklart valg. Ehsan ble også valg da han er god til å snakke for seg og stille de riktige spørsmålene i slike sammenhenger. Hvem av oss andre som skulle dra valgte vi å avgjøre senere. Utenom det ovennevnte ble Mona satt på å skrive et første utkast til kravspesifikasjon. Fristen for å ha dette dokumentet ferdig ble satt til samme dato som møtet vi prøvde å få til. Andre arbeidsoppgaver ble tilrettelagt slik at vi hadde noe å vise fram på møtet som vi håpet å få til snart. Men det var også ment at disse dokumentene skulle hjelpe oss videre i framgangen. 7

8 Erik og Ehsan ble enige om å samarbeide om å lage et UML diagram, nærmere beskrevet et klassediagram. Tanken med dette var at de skulle få en oversikt over klasser de trengte i programmet og hvordan disse skulle snakke med hverandre. Marit skulle tegne og beskrive noen use-caser. Design ble vi enig om ikke var så viktig akkurat nå, men Shahzeb fikk allikevel i oppgave å lage et førsteutkast på en eventuell nettside. (Uke 6) Et møte med Tønsberg seilforening var nå avtalt og vi var så heldig at de kom til oss. Møtet/presentasjonen skulle holdes torsdag 11.februar kl Et rom hvor dette kunne foregå ble nå nødvendig og Mona tok på seg oppgaven å fikse dette. Det ble derfor viktig at dokumenter som klassediagrammer osv. var ferdig snarest mulig slik at disse dokumentene kunne legges inn i en powerpoint presentasjon. Powerpoint presentasjonen ble laget av Erik og Shahzeb og var ferdigstilt 10.februar. En klargjøring på hvem som skulle si hva ble også gjort denne dagen. Gruppen møtes også ca 2 timer før vi skulle treffe representantene. Noe siste endringer ble gjort på Powerpoint presentasjonen. Vi tok også en runde på hvem som skulle si hva. Et problem som imidlertid dukket opp var hvilket språk vi skulle kode i. Dette var jo ikke 100 % avgjort og det viste seg at gruppen var her ganske delt. Deler av gruppen ville kode i PHP da dette var et språk som flere kunne. Dessuten hadde noen av gruppemedlemmene dette som valgfag dette semesteret. Erik som jobber deltid i et privat firma kom med forslaget om å bruke ASP.NET MVC med Sharp architecture som er basert på domain driven design modell. (Dette språket brukes der han jobber). Dette på grunnlag av at det er generelt sikrere enn PHP og har mye større muligheter for videreutvikling. Gruppen ble til slutt enig om ASP.NET MVC når alle fordelene kom fram, men det var også mye pga av at Erik lovte å hjelpe oss med litteratur siden ingen av oss kunne akkurat denne grenen av språket fra før. Selv hadde han for øvrig nettopp lært det. ( ) Under et kort gruppemøte før selve presentasjonen gikk vi gjennom presentasjonen en gang til. Tilstede på møtet/presentasjonen var alle gruppemedlemmene, Veilederen vår fra høyskolen (Steinar Johannessen) og to representanter fra Tønsberg seilforening (Bjørnar Erikstad og Erik Fusdahl). Alt i alt virket de veldig fornøyd med hvordan vi hadde planer om å lage systemet, men noe spørsmål hadde de selvfølgelig. Men det var ingen av disse som var spesielt kritiske Noen nye ønsker til funksjonalitet dukket selvsagt opp under møtet, men det var jo forventet etter som presentasjonen vi holdt ble laget på bakgrunn av de kravene vi mottok i en tidlig e-post. (De endelige kravene kan man lese mer om i kravspesifikasjonen) Steinar virket også fornøyd og han kommenterte at det virket som at vi hadde kommet godt i gang. Etter selve presentasjonen snakket vi med Bjørnar og Erik en god del om hvordan det fungerte i dag og begge partene var enig i at deler av administrasjonen av foreningen var noe tungvint og rotete. Så de gledet seg veldig til å se hva vi kunne komme opp med som sluttprodukt. Vi ble også enig om at de skulle sende oss noen dokumenter som kunne hjelpe oss å visualisere hvordan arrangementer det dreier seg om og dagens status på planlegging/rapportføring av disse. Etter presentasjonen snakket vi i gruppen sammen om hvordan vi syntes det gikk. Vi var i grunn alle veldig fornøyd og glade for at Tønsberg seilforening hadde reagert positivt på vårt forslag til løsning. 8

9 (Uke 7) Denne uken snakket vi mest om språkvalget. Erik ga oss her litt litteratur som vi kunne lese oss kloke på. Vi hadde også en kort gjennomgang av e-posten vi hadde fått fra Tønsberg seilforening med diverse informasjon. Disse dokumentene ble dessuten skrevet ut og samlet i en perm. Ingen videre arbeidsoppgaver ble gitt uten om å sjekke ut litteraturen og prøve å lese seg litt opp om ASP.NET MVC. Dette grunnet kontinuasjonseksamen uken som i år ble lagt til uke 8 ( ) hvor flere av oss skulle ha en eller flere eksamener. Og noen skulle på vinterferie med familien. ( , Uke 8) Som forutsett ble resten av måneden ganske borte og lite prosjektarbeid ble gjort. Mars 2010 (Uke 9) Etter en periode med lite jobbing på prosjektet fant vi ut at det var snart på tide å begynne selve kodingen. Vi snakket i forbindelse med dette også litt sammen om hva hver enkelt hadde fått lest av ASP.NET MVC litteraturen som Erik hadde gitt oss i slutten av februar. Alle hadde i hvert fall fått skummet igjennom og hadde nå litt peiling på hva det dreide seg om. Vi snakket også om hvordan vi skulle begynne. Erik og Ehsan meldte seg her frivillig til å lage en databasemodell, noe som er helt nødvendig for videre koding. Vi kom dessuten fram til å vente litt med frontend inntil vi visste litt mer om hvordan systemet skulle fungere. Marit og Mona fikk da i oppgave å skrive en ny versjon av kravspesifikasjonen slik at de nye kravene som kom fram under møtet/presentasjonen i februar kom med. Shahzeb skulle fortsette å designe nettsiden. (Uke 10) Med en ferdig databasemodell kunne man nå begynne kodingen. Så Erik og Ehsan satte i gang med å planlegge dette med bakgrunn i databasemodellen. Og mot slutten av uken begynte de å definere objekter. De fant også ut at det var best å gjøre kodingen hjemme hos Erik, som har en stor skjerm, så kodingen blir trolig gjort derfra framover. Et behov for å sette opp serveren dukket nå opp. Denne oppgaven fikk Shahzeb sammen med Ehsan som hjelp ved behov. Mona begynte på innledningsdelen på prosessrapporten. Marit fikk foreløpig ingen oppgave, men hjalp til der det trengtes. (Uke 11) Erik og Ehsan forsatte med kodingen på backend. Vi så etter hvert at frontend ikke lønte seg å gjøre som en egen del så Marit gjorde dette i samarbeid med Erik når det var et behov i koden. Dette ble en endring i forhold til arbeidsfordelingen som var tenkt i begynnelsen, men siden det var greit for både Mona og Erik valgte vi å fortsette med den nye arbeidsfordelingen. Mona tok seg da heller mer av rapportføring og fikk ansvar for prosessrapporten. Shahzeb jobbet litt sammen med Erik og Ehsan da dette var det beste med tanke på å tilpasse designen til systemet. (Uke 12) Kodingen og rapportføringen fortsatte. Noe test dokumenter ble også påbegynt og dette tok Mona seg av. Vi skjønte etter hvert at det ble en del arbeid på Erik som deltok aktivt i alle deler av utviklingen av systemet. Så gruppen tok en samtale om det og kom fram til at så lenge det var greit for Erik selv så var dette en 9

10 fungerende løsning på arbeidsfordelingen. Erik er en veldig ressurssterk person både faglig og praktisk og syntes dette var greit. (Uke 13) Ettersom påskeferien begynte den 29.mars ble det ikke gjort noe særlig denne uken utenom at Erik fortsatte å kode litt. April 2010 (Uke 14, ) Gruppen fikk en noe treg start etter en lang ferie, men vi kom omsider i gang igjen med koding og rapportføringen som var nødvendig å gjøre underveis i prosessen. (Uke 15- Uke 17) Koding på frontend og backend fortsatte. Samme med prosessrapporten. Designen begynte også å ta form. Ingen store problemer oppsto så et gruppemøte i uka holdt. Her snakket vi for det meste om framgangen. Vi hadde uansett tett kontakt med hverandre da flere av oss jobbet tett sammen i våre arbeidsoppgaver. Vi begynte også så vidt med testing torsdag denne uken. Marit var en del borte og ikke så deltagende i Uke 17. Dette grunnet flytting den 1.mai. Mai 2010 (Uke 18, 19) Intensiv jobbing med koding, testing av ferdige programdeler, utvikling av design og dokumentasjon skriving fortsatte. Ingen store problemer oppsto så et møte i uken og ellers jevnlig kontakt pga samarbeid eller via tlf. (Uke 20) Denne uken begynte vi å se enden på hele prosjektet. Programmet manglet nå bare litt på budsjettdelen, artikkel delen og noe knyttet til roller. Dokumenteringen nærmet seg også slutten og det sto stort sett igjen sluttføring av diverse dokumentasjon mot slutten av uken. Det eneste som fremdeles pågikk i stor grad var testing, testrapporten og brukermanualen. Som vanlig ikke noen store problemer. Ellers stort sett daglig kontakt mellom gruppemedlemmene. Ofte grunnet samarbeid om diverse oppgaver. (Uke 21) Etter en ny uke med hard jobbing var mesteparten av dokumentasjon og kodingen av selve programmet ferdig til senest lørdag 29. Det oppsto imidlertid et problem i koden knyttet til roller og dette ga oss et stort problem i forhold til å få ferdigstilt testrapport og brukermanual. Delvis også produktrapporten. I tillegg slet vi da med å få programmet over på cd i tide. Gruppen avtalte å møtes tidlig mandag morgen for å skrive ut hovedprosjektrapporten og brukermanual. Hovedprosjektrapport må være klar til levering mandag 31.mai. 10

11 (Uke 22) Levering av hovedprosjekt mandag 31. mai. Det består av tre kopier av hovedprosjektrapporten. En brukermanual og en elektronisk kopi til oppdragsgiver. En cd med systemet skal også leveres. Leveringen ble beklageligvis delvis sen grunnet problemet i koden som oppsto helt på slutten. En sluttrapport ble til slutt ferdigstilt og levert til resepsjonen i 7 etasje. 11

12 Forprosjektrapport Presentasjon Tittel: Administrativsystem for Tønsberg Seilforening Oppgave: Utvikle et administrativsystem for å registrere arrangementer og fordele vakter på de forskjellige postene ved Tønsberg seilforening. Periode: 4. Desember 2009 til 31. Mai 2010 Prosjektgruppe: Prosjektmedlemmer: Erik Andreassen, Ehsanullah Zadran, Marit Helene Foss, Shahzeb Akhtar, Mona Aziz Hamed, Veileder Steinar Johannesen, Førsteamanuensis, Allmennfag, HIO Oppdragsgiver: Tønsberg Seilforening Kontaktperson: Erik Fusdahl: Epost: Tlf: 12

13 Sammendrag Hovedprosjektet utføres for Tønsberg Seilforening, som en del av utdanningen ved Høgskolen i Oslo, avdeling for ingeniørutdanning Oppgaven går ut på å lage et administrativt datasystem for å lette arbeidet med registrering av arrangementet og vaktposter ved seilforeningen. Løsningen vår er en webapplikasjon basert. Vi skal blant annet bruke ASP. NET MVC og Microsoft Visual Studio som utviklingsmiljø. Om bedriften Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som f.eks. SpareBank1, Esso, Vakt Service og noen andre. Tønsberg Seilforening holder til på Fjærholmen rett utenfor Tønsberg. Der har de ideelle fasiliteter for å utøve deres idrett. Anlegget eies av foreningen og det har et stort ute område med eget brygganlegg og klubbhus med garderober. Foreningen har et høyt aktivitetsnivå både blant jolle seilere og tur- havseilere. De arrangerer årlig treningsleiere, nasjonale og internasjonale regattaer. Bakgrunn for prosjektoppgaven Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. I forbindelse med arrangementer, trenger de et system som administrerer ulike vakter til enhver tid. Her er det noen krav som de har satt opp for en eventuell løsning: Planlegge, tidfeste, definere og beskrive ulike vakter for ulike arrangementer - generelt for Klubbkomiteen (kiosk, kjøkken, avfall, renhold), Regattakomiteen (startbåt, sikringsbåt, bøyebåt, organisering land under arrangementer o.s.v.) Alle vakter fordeles på tilgjengelige grupper som tur/hav, jolle, etc. og hvert medlem kan følge dette på nett Alle vakter for alle arrangementer bør kunne legges ut på nett med mulighet for elektronisk påmelding/registrering av frivillige. Gjerne med aktivering av mobilnummer for utsendelse av påminnelse for vakt Arkiv for internt bruk, erfaringsdatabase med kommentarfelt, innkjøp etc. Dagens situasjon Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som f.eks. SpareBank1, Esso, Vakt Service og noen andre. Ved Tønsberg Seilforening registrerer de sine arrangementer med blant annet Excel, penn og papir. Registreringsrutinene som finnes i dag er papirbaserte, tidkrevende og lite brukervennlige. Når ledere skal arrangere noe per i dag, må informasjon om arrangementet skrives i et Excel-regneark og i Microsoft Word. Ved endringer blir regnearket oppdatert, og dokumentet i Microsoft Word blir fylt ut og arkivert. Det er en del ting som ikke fungerer optimalt med denne løsningen. Dokumenter kan forsvinne da ansatte slutter eller det kan bli forsinkelser når ansatte er meldt syke for en periode. Regnearket er ment å vise 13

14 lagerbeholdningen til enhver tid, men dette kan bli glemt, eller utfylt feil. Det er mulig at regnearket ikke blir oppdatert og papirskjemaet blir borte hvis slike situasjoner skjer. Prosjektet I forbindelse med deres mange arrangementer har de behov for et nytt system som kan administrere ulike vakter til enhver tid. Gruppen har tenkt ut en plan for å gjennomføre prosjektet ved å fordele vakter på tilgjengelige grupper som tur/hav, jolle, o.l. Medlemmene skal kunne følge dette på nettet. Vaktene skal legges ut på nettet og kanskje også mulighet for elektronisk påmelding /registrering av frivillige (kun medlemmer). Vi tenker å utforme 3 brukerroller. Medlem, som kan se ledige vakter og som kan også melde seg på. Vakt/frivillige kan se hvem som holder arrangementer og hvor de holdes. Dersom de ønsker kan de melde seg på ulike arrangementer og vakter som er blitt satt opp. Superbruker er de som har detaljert oversikt. De vil ha oversikt over alle brukere og vaktposter. De kan endre tidsbeskrivelse på alle vakter i systemet. Hvis det er behov kan de opprette/slette nye vaktposter. Som superbrukere har de tilgang til alle brukernes kontoer og erfaringsdatabase. De vil også få ansvaret for å sende nyhetsbrev. Oppretting av brukere, endring av passord, utestenging av brukere og sperre tilgang til systemet. Vedlikehold eller ingen arrangementer er også innenfor superbrukerens område. Gruppen har per dags dato tenkt litt på ulike verktøy i forbindelse med å utvikle en driftsikker løsning, og har kommet frem til at en av de aktuelle kandidatene for utviklingen er utviklingsmiljøet ASP. NET MVC med MSSQL. Mål og rammebetingelser. Rammebetingelsene er ganske frie. Men generelt sett og ut ifra vårt perspektiv så bør løsningen være et hensiktsmessig brukergrensesnitt som er enkelt å bruke uten at det skal kreve forkunnskaper innen avansert databruk. Web-løsningen er ment i utgangspunktet for administrator. Vi har valgt å programmere løsningen med ASP.NET MVC som rammeverk, og bruke Microsoft Visual Studio 2010 som utviklingsmiljø. Programmet vil kjøre på en Windows webserver. Øvrige ønsker I tillegg er det ønske om å utbedre hjemmesiden, og gjøre den litt sprekere enn den er i dag muligens med bedre layout, men ved å beholde samme struktur. Andre ønsker er et bildegalleri hvor de kan samle bilder tatt på arrangementer. Systemet bør også være tilrettelagt for videreutvikling og påbygging i fremtiden. Løsning Løsningen er en webbasert og systemet skal være koblet opp mot en database. Ved utvikling av en ren webapplikasjon, så vil systemet ligge på en intern server hos bedriften, og vil kjøres i nettleseren hos de som administrerer systemet. Siden systemet kommer til å bli utviklet i.net og kommer til å være webbasert, tenkte vi å fordele arbeidet mellom Frontend, backend og design. 14

15 Frontend: Utvikling av alt som er synlig for brukeren, f.eks. logg inn. Backend: Utvikling av systemarkitektur og struktur, med tanke på database og metoder. Vi kan si det er her selve systemet blir utviklet teknisk sett. Design: Design av brukergrensesnitt og grafikk. Med en slik fordeling kan man konsentrere seg mer om hver sin del samtidig som vi får økt samarbeid med hverandre, men en grunnforutsetning er selvfølgelig at vi har kommunikasjon på høyt nivå, slik at vi vet hvordan det går, hva som eventuelt må endres, eller hva som trengs Konklusjon Den løsningen vi lager for Tønsberg Seilforening vil gjøre hverdagen deres mye enklere ved å spare tid og ressurser. Det vil hjelpe dem med å holde registrering strukturert og oversiktlig. Administrasjonen får også en bedre oversikt over deres arrangementer. Gruppen har 20 uker for å arbeide med prosjektet. Dette betyr at vi har totalt 420 timer til prosjektarbeid som gruppe på skolen. Andre nødvendige deler av prosjektet ble gjennomført individuelt utenom gruppearbeidet. Dokumentasjonen av systemet skal leveres inn 31. Mai kl.12:00, og blir overlevert til oppdragsgiver elektronisk samme dag. Erik Andreassen Ehsanullah Zadran Marit Helene Foss Shazheb Akhtar Mona Aziz 15

16 Arbeidsplan Aktivitet Beskrivelse Ferdig Innledningsfasen Dagbok Webside Statusrapport En beskrivelse av det kontinuerlige arbeidet som blir gjort frem til prosjektet er ferdig i mai En webside for hovedprosjektet som skal brukes til å publisere dokumenter knyttet til prosjektet En beskrivelse av hva slags prosjekt som er aktuelt for oss og hvem vi har kontaktet for å få et oppdrag. Fortløpende Fortløpende Datainnsamling Forprosjektrapport Arbeidsplan Fremdriftsplan Datainnsamling av nødvendig informasjon/fakta om oppdraget. En beskrivelse av arbeidet som skal gjøres, kravspesifikasjon, hvilke mål og rammer som eksisterer per i dag Oversikt over arbeidet og dokumentasjonen som skal skrives ferdig og leveres inn for å fullføre prosjektet Oversikt over tidsberegning for de enkelte fasene som arbeidet omfatter i løpet av prosjektarbeidet utkast av kravspesifikasjon Hovedfasen Utarbeide en beskrivelse av krav som oppdragsgiver har til systemet. Skal lages i samarbeid med oppdragsgiver Design Del 1 Designe systemet (Utforme use-case diagrammer sekvensdiagram og klassediagram) Design Del 1 Endring og forbedring av diagrammer Implementering Del 1 Starte med koding Implementering Del 2 Testing og feilretting Implementering Del 3 Koding og videreutvikling av systemet Dokumentasjon Prosessdokumentasjon Skrive om prosjektets bakgrunn, underlag, arbeidsmåte og andre nødvendige deler for det produktet som er blitt utviklet. Brukerdokumentasjon Produkt manual, som beskriver og forklarer produktet Sluttrapport Den fullstendige rapporten Presentasjons Forberede oss til presentasjonen forberedelse Presentasjon Presentering av prosjektet

17 Sluttdokumentasjon 17

18 KRAVSPESIFIKASJON Tittel: Administrasjonssystem for Tønsberg Seilforening. Oppgave: Utvikle et system som kan holde orden på vakter og budsjett ved arrangementer som foreningen holder. Periode: Januar 2010 til juni Gruppemedlemmer: Marit Foss, Erik Andreassen, Mona Aziz, Ehsanullah Zadran og Shahzeb Akhtar. Prosjektgruppe: Veileder: Steinar Johannesen. Oppdragsgiver: Tønsberg seilforening Kontaktperson: Erik Fusdahl 1 Innledning Prosjektet skal gjennomføres som en avslutning på en bachelorgrad ved HiO våren Oppgaven består av å lage et datasystem for Tønsberg seilforening som skal gjøre det enklere for foreningen å holde orden på hvilke vaktposter som er nødvendig ved ulike arrangementer som holdes. Systemet skal også gjøre det mulige for frivillige å melde seg på vakter. Løsningen vår kommer til å være webbasert og selve utviklingsarbeidet kommer til å foregå i Visual Studios Utviklingsspråket er ASP.NET MVC med Sharp architecture. 1.1 Om foreningen Tønsberg seilforening er en idrettsforening for personer interessert i seiling. Medlemmene her er spredd over et vidt spenn av aldre. Årlig, i sommersesongen, arrangerer de arrangementer som treningsleiere, nasjonale og internasjonale regattaer. Det arrangeres også fester. Disse arrangementene arrangeres ofte på deres eget område utenfor fjærholmen. 1.2 Bakgrunn for prosjektoppgaven Dagens status for foreningen er at de har mye av informasjonen rundt arrangementene på papir eller enkeltstående datadokumenter. Dette er ikke i lengen veldig praktisk i tillegg til at det blir en del rot. For eksempel ved sykdom, menneskelige feil og datatap. Foreningen ønsket seg derfor et datasystem som gjør administreringen av vakter systematisk og oversiktlig. I tillegg ønsket de at man kunne registrere seg på vakter via nettet. Kravene de kom med var: Planlegge, tidfeste, definere og beskrive ulike vakter for ulike arrangementer - generelt for Klubbkomiteen (kiosk, kjøkken, avfall, renhold), Regattakomiteen (startbåt, sikringsbåt, bøyebåt, organisering land under arrangementer o.s.v.) Alle vakter fordeles på tilgjengelige grupper som tur/hav, jolle, etc. og hvert medlem kan følge dette på nett Alle vakter for alle arrangementer bør kunne legges ut på nett med mulighet for elektronisk påmelding/registrering av frivillige. Gjerne med aktivering av mobilnummer for utsendelse av påminnelse for vakt Arkiv for internt bruk, erfaringsdatabase med kommentarfelt, innkjøp etc. 18

19 Et krav som ikke er nevnt ovenfor er at siden skal være brukervennlig, da det ikke nødvendigvis er datakyndige som skal ta siden i bruk. Per i dag har de en nettside, men denne er ikke brukt til stort annet enn informasjon. Etter et møte vi hadde med to representanter fra Tønsberg seilforening den 11.februar snakket vi litt om ønsker og krav som ikke var tidligere nevnt. Generelt var de fornøyd med tanker og ideer vi hadde rundt systemet, men de hadde allikevel en ting de ønsket å få implementert i systemet. Det var: Mulighet for å lage budsjett på arrangementer. Andre ønsker som ikke var et krav: Om det var mulig og gruppen fikk tid ville de gjerne ha en ny nettside. Per i dag har de standard siden for idrettsforeninger. Bildegalleri Utenom det hittil nevnte var egentlig det meste opp til oss av hva vi ønsket å implementere i systemet så lenge kravene var oppfylt. 19

20 2 Forord Kravspesifikasjonen er et dokument som viser rammene for prosjektet og er derfor viktig for både utvikler og oppdragsgiver. Oppdragsgiver får en oversikt over hvilke funksjoner det ferdige prosjektet i basis kommer til å bestå av samtidig som det er en beskrivelse til oss (utviklerne) om hva som er minimumskravene til systemet. Under utviklingen av systemet er tanken med kravspesifikasjonen at den skal hjelpe oss å holde en stø kurs samtidig som det hjelper oss til å komme på ideer til utvidelser som er relevante og fornuftige. Da Tønsberg seilforening ikke var spesielt datakyndig la de det meste opp til oss når det kom til utviklingsverktøy. Verktøy valget lå med andre ord helt opp til oss og vi kunne velge det vi følte var best med bakgrunn i vårt kunnskapsnivå. 20

21 Innhold 1 Innledning Om foreningen Bakgrunn for prosjektoppgaven Forord Innholdsfortegnelse... Error! Bookmark not defined. 4 Systemkrav Krav til brukersystemet Krav til administratorsystem Tekniske krav Krav til Datalagring Krav til design Krav til kode Krav til dokumentasjon Forslag til utvidelser

22 4 Systemkrav 4.1 Krav til brukersystemet Registrering av medlem 1. Dersom man ikke er medlem i foreningen fra før skal man kunne melde seg inn med unikt brukernavn og passord. 2. Det skal ikke være mulig å registrere seg flere ganger med samme e-post adresse siden e-post er brukernavnet. 3. Brukeren er aktiv med engang man er lagret i databasen. Se profil 1. Etter at man er logget inn skal man kunne se info lagret som seg selv 2. Det skal være mulig for brukeren å redigere profilen sin (For eksempel passord, adresse osv.) Logge seg inn 1. Dersom man allerede er medlem kan man logge seg inn med sitt unike brukernavn og passord. 2. Hvis personen som prøver å logge inn ikke husker passordet sitt kan han/hun få tilsendt passordet sitt på e-post på den registrerte e-post adressen. Logge ut 1. Når man er innlogget logger man ut ved å bruke logg ut knappen. Melde seg på arrangementer 1. Som et registrert medlem skal man kunne melde seg på opprettede arrangementer. 2. Man skal også ha muligheten til å melde seg av arrangementet dersom det skulle skje noe uforutsett. Melde seg på vaktposter 1. Som medlem skal man kunne melde seg som frivillig til vaktposter på opprettede arrangementer. 2. Man skal også kunne melde seg av en vaktpost (helst innenfor en tidsfrist) Lese nyheter 1. Gjester på nettsiden skal kunne lese nyheter og artikler om diverse. Liste over arrangementer 1. Som en gjest på nettsiden skal man kunne få opp en liste over planlagte arrangementer og andre festlighter. 4.2 Krav til administratorsystem Logge inn 1. Man logger inn som for vanlig medlemmer, men systemet gjenkjenner ditt personlige brukernavn og passord som en bruker med ekstra rettigheter. Logge ut 1. Når man er innlogget logger man ut ved å bruke logg ut knappen. Registrering av arrangementer (eventer) 1. Som administrator skal man kunne legge til et arrangement med startdato og sluttdato. 2. Administrator skal ha mulighet til å endre arrangementet. 3. En administrator kan sette medlemmer som administrator (event admin) for arrangementet. 22

23 Rettigheter for eventadmin 1. En eventadmin har samme rettigheter som administrator på de arrangementer som han administrerer. Registrering av poster på arrangementer 1. Administrator kan legge til vaktposter på arrangementer. 2. En administrator skal ha muligheten til å endre/slette vaktposter på arrangementer. Komiteer 1. Som administrator skal man kunne lage komiteer bestående av medlemmer 2. En administrator kan legge til ansvarsområder på komiteer Slette medlemmer 1. Administrator skal kunne slette gamle brukere i systemet. Artikler 1. En administrator skal kunne legge til artikler, nyheter og resultater på artikkeldelen. 2. Som administrator skal man kunne redigere/slette nyheter, artikler og resultater. Budsjett 1. En administrator kan lage budsjetter til arrangementer. 4.3 Tekniske krav Systemet utvikles i ASP.NET 4.0 MVC 2 med Sharp architecture 1.5 med Fluent n Hybernate Programmet vi bruker under utvikling er Visual Studios 2010 Vi bruker MSSQL 2008 til lagring av data Systemet skal kunne kjøres på en Windows Server Systemet kommer til å kreve mye RAM pga en database, utviklingsspråket.net 4.0 og siden det antakeligvis er mange brukere. Systemet antas å bruke mye plass pga bilder. 4.4 Krav til Datalagring All data lagres i MSSQL på en kjøpt eller egen serverplass All data som settes inn i databasen valideres før innsetting. 4.5 Krav til design Siden skal være brukervennlig slik at personer som ikke er spesielt datakyndige også skal kunne bruke siden. Siden skal være delikat med klare fargeskiller så den blir behagelig å benytte Siden skal være dynamisk for å minimere nedlastningstid. 23

24 4.6 Krav til kode Siden skal programmeres på en slik måte at det senere skal være enkelt å implementere nye funksjoner Bruk av navn på variabler og metoder skal være lett gjenkjennelig Ved bruk av dynamiske menyer skal det enkelt gå an å legge til nye nyhetskategorier 4.7 Krav til dokumentasjon 1. Dagbok og andre styringsdokumenter skal skrives underveis. 2. Den endelige løsningen skal dokumenteres gjennom følgende dokumentasjon: Endelig kravspesifikasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerdokumentasjon Og disse skal påbegynnes så fort det er mulig. 4.8 Forslag til utvidelser Sms varling Betaling for medlemskap og arrangementer via internett Dele artikler på Facebook Realtime om eventet Bildegalleri 24

25 Prosessdokumentasjon Sammendrag Dette dokumentet er en prosessrapport for vårt avsluttende hovedprosjekt våren 2010 ved høgskolen i Oslo, for ingeniør - avdelingen. Oppdragsgiveren vår har per dags dato en utdatert og veldig enkel nettside som kun innholder nyheter og annen informasjon for gjester og medlemmer. Når det gjelder registrering av arrangement og planlegging så tar de i bruk enkle metoder som for eksempel Microsoft Excel, og penn og papir. Denne metoden er uoversiktlig og tidskrevende. De ønsker seg nå en større webbasert løsning sammen med en plattform som gir arrangørene ved foreningen muligheten til å registrere og planlegge sine arrangementer. Denne løsningen skal imøtekomme behovet til Tønsberg Seilforening og erstatte den eksisterende løsningen deres. Gruppen skal lage et system som skal administrere ulike vakter til enhver tid for ulike arrangementer. Systemet vil inkludere alt innenfor arrangement-planlegging. Det vil si tidsfeste, definere og beskrive uliker vakter for ulike arrangementer, med mer. Applikasjonen er designet for at en eller flere datamaskiner, uavhengig av hvor i det lokale nettverket de måtte befinne seg, skal kunne koble seg via nettverk opp mot applikasjons- og databaseserveren. Det er til hensikt å ha data tilgjengelig når det enn måtte behøves. Brukergrensesnittet er grafisk, og svært enkelt å bruke. Applikasjonen er designet slik at man enkelt skal kunne navigere seg rundt med minimalt av datakunnskaper. 25

26 Forord Denne prosjektrapporten gir en detaljert beskrivelse av alle fasene vi gikk gjennom under hovedprosjekt ved Høgskolen i Oslo, avdeling for ingeniørutdanningen våren Gruppen består av 5 studenter fra anvendt datateknologi og dataingeniør linjen, som har jobbet tett sammen for å oppnå det endelige produktet. Gruppen startet i oktober med å finne et prosjekt som interesserte oss. Vi var åpne for mange temaer, så fremt det var spennende og samtidig utfordrende. Det var også viktig at det var noenlunde innenfor vårt kunnskapsnivå. Etter å ha søkt litt rundt i forskjellige bedrifter og foreninger fikk vi kontakt med Tønsberg Seilforening gjennom Tor krattebøl, som var kontaktperson for alle avgangs studenter. Tønsberg Seilforening hadde et tilbud til oss om å lage et arrangement løsning til deres forening. Gruppen undersøkte nærmere for å få innblikk i hva oppgaven gikk ut på og hva deres krav var. Da gruppen fant dette interessant kontaktet vi foreningen og meldte vår interesse og avtalte med dem at vi tok på oss oppgaven. På nyåret avtalte vi et møte med oppdragsgiver. Etter møtet var både oppdragsgiver og gruppen fornøyd med forslag til løsning. Da denne type løsning for arrangementer for seilforening er noe nytt på markedet ble det en ekstra utfordring for oss og prosjektets fremgangsmåte, og ikke minst resultat. Vi er også de første som lager og tester systemet. Dette ga oss ekstra motivasjon og vilje til å gjøre det beste ut av prosjektet. Denne rapporten kan fungere som en guide for brukere som er interessert i, eller skal sette opp et slikt system selv. Med noen små justeringer og utvidelser kan systemet implementeres og brukes i flere kommuner og eventuelt på landsbasis. Vi ønsker å rette en stor takk til noen enkelte personer - Tor Krattebøl, kontaktperson for hovedprosjekt for datalinjen som hjalp oss med prosjektoppgaven. - Erik Fusdahl, ekstern veileder for å ha gitt oss en tydelig og lettfattelig kravspesifikasjon. Og gitt oss den tekniske friheten til å utvikle webløsningen. - Ann-Mari Torvart, for å ha utarbeidet dokumentasjonsstandarden, som har vært til stor hjelp under dokumenteringsarbeidet. 26

27 Innhold 4 Innledning Om Tønsberg Seilforening Bakgrunn for prosjektoppgaven Dagens situasjon Målet med oppgaven Rammebetingelse Øvrige ønsker Utviklingsmiljø Gruppen Planlegging Generelt Datainnsamling Fremdriftsplan og arbeidsplan Utvikling av prosjektstyringsplan Forprosjektfasen Styringsprosess modell Idefasen Utformingsfasen Utdypningsfase Overgangsfasen Kompetansetilegning Dokumentasjonsfasen Testfasen Utviklingsteknologi Programmeringsspråk Løsning Andre utviklingsteknologier Arbeidsverktøy Organisering Intern organisering Ansvarskart Risikofaktorer Kvaliteten på prosjektet Brukervennlighet

28 13.02 Sikkerhet Utviklingsprosessen Generelt Kravspesifikasjonen Endringer i kravspesifikasjon Use case med beskrivelser Use Case for medlemmer Use - case for administratorer i Tønsberg Seilforening Klassediagram Avslutende del Generelt Hva vi har lært Hva kunne vært gjort annerledes Videre Konklusjon

29 4 Innledning 4.01 Om Tønsberg Seilforening Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som f.eks. SpareBank1, Esso, Vakt Service og noen andre. Tønsberg Seilforening holder til på Fjærholmen rett utenfor Tønsberg. Der har de ideelle fasiliteter for å utøve deres idrett. Anlegget eies av foreningen og det har et stort uteområde med eget bryggeanlegg og klubbhus med garderober. Foreningen har et høyt aktivitetsnivå både blant jolle seilere og tur-havseilere. De arrangerer årlig treningsleire, nasjonale og internasjonale regattaer Bakgrunn for prosjektoppgaven Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. I forbindelse med arrangementer, trenger de et system som administrerer ulike vakter til enhver tid. Her er det noen krav som de har satt opp for en eventuell løsning Planlegge, tidfeste, definere og beskrive ulike vakter for ulike arrangementer - generelt for Klubbkomiteen (kiosk, kjøkken, avfall, renhold), Regattakomiteen (startbåt, sikringsbåt, bøyebåt, organisering land under arrangementer o.s.v.) Alle vakter fordeles på tilgjengelige grupper som tur/hav, jolle, etc. og hvert medlem kan følge dette på nett Alle vakter for alle arrangementer bør kunne legges ut på nett med mulighet for elektronisk påmelding/registrering av frivillige. Gjerne med aktivering av mobilnummer for utsendelse av påminnelse for vakt Arkiv for internt bruk, erfaringsdatabase med kommentarfelt, innkjøp etc Dagens situasjon Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som f.eks. SpareBank1, Esso, Vakt Service og noen andre. Ved Tønsberg Seilforening registrer de deres arrangement med blant annet Excel, penn og papir. Registreringsrutinene som finnes i dag er papirbaserte, tidkrevende og lite brukervennlige. Når ledere skal arrangere arrangementer i dag, må informasjon om arrangementet skrives i et Excel-regneark og i Microsoft Word. Ved endringer blir regnearket oppdatert, og dokumentet i Microsoft Word blir fylt ut og arkivert. Det er en del ting som ikke fungerer optimalt med denne løsningen. Dokumenter kan forsvinne da ansatte slutter eller det kan bli forsinkelser når ansatte er meldt syke for en periode. Regnearket er ment å vise lagerbeholdningen til enhver tid, men dette kan bli glemt, eller utfylt feil. Det er mulig at regnearket ikke blir oppdatert og papirskjemaet blir borte hvis slike situasjoner skjer. 29

30 4.04 Målet med oppgaven Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. I forbindelse med deres arrangementer har de behov for et nytt system som kan administrer ulike vakter til enhver tid. Gruppen har tenkt ut en plan for å gjennomføre prosjektet ved å fordele vakter på tilgjengelige grupper som tur/hav, jolle, o.l. Medlemmene skal kunne følge dette på nettet. Vaktene skal legges ut på nettet og det skal være mulighet for elektronisk påmelding / registrering av frivillige (kun medlemmer). Vi tenker å utforme tre brukerroller. Medlem, som kan se ledige vakter og som kan også melde seg på. Vakt/frivillige kan se hvem som holder arrangementer og hvor de holdes. Dersom de ønsker kan de melde seg på ulike arrangementer og poster som er blitt satt opp. Superbruker er de som har detaljert oversikt. De vil ha oversikt over alle brukere og vaktposter. De kan endre tid og beskrivelse på alle vakter i systemet. Hvis det er behov kan de opprette nye vaktposter. Som superbrukere har de tilgang til alle brukeres kontoer og erfaringsdatabase. De vil også få ansvaret for å sende nyhetsbrev og statusrapport til alle medlemmer. Oppretting av brukere, endring av passord, utestenging av bruker og Sperre tilgang til systemet (vedlikehold eller ingen arrangementer) er også innenfor superbrukerens område Rammebetingelse Rammebetingelser er ganske frie. Men generelt sett og ut ifra vår perspektiv så bør løsningen være et hensiktsmessig brukergrensesnitt som er enkelt å bruke uten at det skal kreve forkunnskaper innen avansert databruk. Web-løsningen er ment for følgende brukere - Administrator - Medlemmer - Gjester Når en bruker logger seg inn på systemet, skal denne brukeren få en side som er tilpasset etter gruppen brukeren hører til og med de rettigheten en har. Under beskriver vi korte trekk av de viktigste kravene som oppdragsgiveren vår stiller. For en fullstendig beskrivelse viser vi til krav kravspesifikasjon som er blitt utarbeidet Administrator skal ha mulighet til å gjøre følgende oppgaver etter innlogging: - Oversikt over arrangementene - Legge til/fjerne arrangementer - Legge til/fjerne vaktposter på arrangementer - Administrere nyheter - Administrere medlemmer - Oppdatering 30

31 Medlemmer skal ha mulighet til følgende etter pålogging - Endre sin egen profil - Oversikt over alle arrangementer - Melde seg på/av arrangementer - Melde seg på/av vaktposter Gjester - Lese nyheter - Liste over arrangementer 4.06 Øvrige ønsker I tillegg er det ønske om å utbedre hjemmesiden, og gjøre den litt sprekere enn den er i dag, muligens med bedre layout, men ved å beholde samme struktur. De ønsket seg også en slags album side, hvor administrator kan laste opp bilder tatt på diverse arrangementer. Systemet skal dessuten være tilrettelagt for videreutvikling og påbygging i fremtiden Utviklingsmiljø Gruppen har fått friheten til å velge selv fremgangsmåten og programmering språket for utviklingen av løsningen. Det viktigste for foreningen er at produktet er brukervennlig og har mulighet for videreutvikling. Vi fikk installert både MS Visual Studio 2008 og Microsoft SQL Server 2008 på skole maskinen vår. I praksis har vi brukt MS Visual studio 2010 og utviklingen av systemet har foregått på egne datamaskiner. Valget om programmeringsspråk stod mellom PHP, ASP. NET MVC og ASP. NET. Etter diskusjon og mye frem og tilbake ble det tatt en avgjørelse om å velge ASP. NET MVC med Sharp architecture. Bakgrunnen for dette valget var at det er et sikrere og bedre språk enn PHP og nettsiden de allerede har er basert på ASP. 31

32 5 Gruppen Gruppen består av fem studenter fra Høgskolen i Oslo, avdeling for ingeniørutdanning. Gruppen ble dannet tidlig i semesteret. Alle i gruppen har jobbet med webbaserte applikasjoner før så dette var noe felles for alle, men kunnskapen varierte fra den ene til den andre. Vi hadde lært oss den grunnleggende programmering I ASP. NET i faget Webapplikasjoner ved HiO. Dette er første gang vi går sammen for å jobbe om et så stort prosjekt. Vi kjente hverandre godt fra før og viste om hverandres svake og sterke sider, noe som var en stor fordel for oss, fordi det gjorde arbeidet med å fordele oppgaver mye enklere. Vi var målbevist og ønsket å jobbe sammen gjennom denne utfordrende og spennende tiden vi hadde foran oss. 32

33 6. Planlegging 6.01 Generelt I starten var mange ting veldig usikkert. Flere bedrifter ble kontaktet og det ble avtalt møte med eventuelle oppdragsgivere. Da vi fikk prosjektoppgaven kom vi i gang med planleggingsfasen straks etter at oppgaven var klar og bestemt. Oppdragsgiver ble kontaktet for å få deres tanker og ønsker rundt prosjektet, og med kravspesifikasjonen i fokus, satte vi oss ned sammen. Denne prosessen tok sin tid, men prosjektet ble satt i gang i midten av januar og prosjektavtalen ble signert i slutten av januar av begge parter. Alle i gruppen deltok i planleggingsfasen, hvor det ble diskutert hvordan programmet skal bygges opp, hva det skal inneholde, utforming av brukergrensesnittet osv Datainnsamling Før vi startet med planlegging av systemet var det nødvendig å skaffe oss en oversikt over dagens situasjon. Det var ingen dokumentasjon liggende, så vi måtte begynne fra bunnen av. Denne fasen gikk i hovedsak ut på å planlegge hvordan vi på en effektiv måte skulle klare å kartlegge hele IT-systemet til oppdragsgiver. Vi fikk også tilsendt informasjon av representantene fra Tønsberg seilforening som vi hadde møte med i februar måned Fremdriftsplan og arbeidsplan Vi startet tidlig med å legge opp en fremdriftsplan som vi laget i Microsoft Project. Vi delte inn fremdriftsplanen i naturlige faser med de forskjellige delene som vårt prosjekt skulle inneholde. Fremdriftsplan og arbeidsplan innholder detaljert beskrivelse av alle fasene av prosjektet og et tidspunkt på når det skulle være ferdig. Dette arbeidet var svært viktig da den fungerer som et hjelpemiddel for å holde oversikt over fremdriften i prosjektet, slik at vi har en noenlunde oversikt når ting kan forventes ferdig. Vi bestemte oss for å holde arbeidsplanen flytende, da ting fort kunne dukke opp. Dokumentene gjorde det enklere for oss å overholde frister og fremdriftsplanen vi lagde i januar klarte vi å følge nesten helt frem til mai. Vi prøvde å sette både arbeidsplanen og fremdriftsplanen opp systematisk og så realistisk som mulige 33

34 6.04 Utvikling av prosjektstyringsplan Versjon Beskrivelse Dato Innlevering 1 Statusrapport fre. 30. okt kl. 15 Innlevering 2 Prosjektskisse fre. 4. des kl. 15 Innlevering 3 Forprosjekt fre. 29. jan kl. 15 Innlevering 4 Prosjektrapport man. 31. mai 2010 kl. 12 Innlevering 5 Presentasjonen juni

35 7 Forprosjektfasen Gruppen startet på første delen av prosjektet, forprosjektfasen, i midten av januar. Forprosjektet hadde en fastsatt innleveringsfrist Vi jobbet med forprosjektrapporten i slutten av januar måned og denne ble sendt frem og tilbake mellom oss før den ble ansett som ferdig og godkjent. Den endelige utgaven av forprosjektet var svært viktig i vår videre utvikling og planlegging av systemet Styringsprosess modell Valg av styringsprinsipp avhenger av hvilke karakteristiske trekk din produksjon har og hva markedet krever! Rational Unified Process (RUP) er en programvareutviklingsprosess som bruker en gjentagende metodologi, med røtter i spiralmodellen, for å skre et resultat med høyt kvalitetsnivå. Egenskaper En av de Unike egenskapene med RUP er på alle disiplinene mer eller mindre strekker seg over alle fasene. For eksempel Vil "Testing" disiplinen starter i innledningsfasen og Ikke etter bygningsfasen som mannen kanskje skulle tro. Menn tilstedeværelsen av "Testing" vil gradvis bli høyere frem til slutten av bygningsfasen, for så en avta. Tilstedeværelsen av "testing" vil aldri forsvinne Helt. Denne egenskapen gjør Rational Unified Prosess meget motstandsdyktig mot feil og meget tilpasningsdyktig i forhold til forandring i spesifikasjonene, implementasjonen og / eller behovene. Hovedutviklingsprogramvaren for RUP er Rational Rose, utviklet av Rational Software og eid av IBM. RUP er delt i fire forksjellige faser, idefasen, utformingsfase, utdypningsfase og overgangsfase. 35

36 1. Idèfase: - Finne grensene for prosjektet og finne kravene til brukerne - Diskutere risiko og kostnader - Design og brukskvalitet - Planlegging 2. Utformingsfase - Planlegge arkitektur og systemkravene. - Produsere en prototype. - Design. - Demonstrere produktet til interessenter. 3 Utdypingsfase - Programmering. - Utvikling av programmet. - Oppnå et produkt så fort som mulig 4 Overgangsfase - Opptrening av brukere og de som skal vedlikeholde systemet, konvertere eksisterende databaser så de fungerer opp imot det nye systemet. - Feilretting Idefasen Her beskrives den innledende fasen i prosjektarbeidet. Etter at gruppen var dannet dreide mye av arbeidet seg om å orientere oss om aktuelle prosjekter vi ville jobbe med. Arbeidet med prosjektskissen var en viktig del i denne fasen, i tillegg til å opprette en prosjektdagbok og planlegge dokumentasjonsdelen. Dagbok skulle være til hjelp i alle fasene i prosjektet. Den innholder også ulemper som vi kom borti samt utfordringer gruppen møtt underveis. Denne fasen var spesielt viktig for oss, da vi her skulle planlegge disponering av tid for hver fase og oppgave under hele hovedprosjektet. Før selve prosjektet ble satt i gang ble det utarbeidet prosjektskisse. Da den var ferdig startet vi med forprosjektrapport hvor vi analyserte prosjektoppgaven og satt fokus på forenings behov. Det ble også vurderte hva slags elementer og krav som skal inngås i oppgaven og hvilke arbeidsverktøy som er nødvendig for utvikling av prosjektoppgaven. I denne fasen her spilte fremdriftsplan og arbeidsplanen en stor rolle siden dette ga oss oversikt over når innleveringene skjer og når skal de ulike delene av prosjektet være ferdige. Dette gjorde at arbeidet ble bedre organisert og ryddig. Første utkast av kravspesifikasjon ble også utarbeidet i idefasen. Det er viktig at systemet er representative, informative og enkel å bruke. I forbindelse med det ble det utviklet UML og Use- Case diagram, som gir en oversikt over hvordan system skal fungere. 36

37 Utformingsfasen I denne fasen begynte vi med å se på oppgaven fra overflaten og dermed grave oss dypere og dypere inn i oppgaven. Siden kravspesifikasjonen presenterer hvordan programmet er bygd opp og hvordan den skal fungere så er det viktig å forholde seg til den. Deretter detaljerte vi Use-Case diagrammet og lagde beskrivelser til dette. For å lese detaljer i kravspesifikasjonen refererer vi til dokumentet Kravspesifikasjon. Deretter utviklet vi risiko analyse slik at vi kunne gjøre oss forberedt til hvilke sårbarheter og trusler vi kunne ha i vente. Implementasjonen av løsningene kommer under denne fasen. Her ble ideene og kravene satt ut i livet. Det ble diskusjoner om hvilke programmeringsspråk vi skulle velge. Flertall i gruppen har mest kjennskap til programmeringsspråk PHP, C#, Java og HTML. Her var det litt uenigheter, men til slutt fant vi ut at det mest logiske og beste er å velge samme type programmeringsspråk som Tønsberg Seilforening brukte i sitt system per i dag. Programmeringsspråk som de brukte er ASP. NET. Da var den diskusjonen ferdig og ASP. NET ble valgt til programmeringen. Det var mye å kode og mye var nytt derfor under hele prosessen jobbet vi parallelt med funksjonalitet, design og brukervennlighet. For å unngå problemer ble det holdt en fortløpende kontakt innad gruppen og rådført hverandre ved problemer. Vi har tilrettelagt ider til eventuelt videreutvikling, noe som forekommer både i programkoden og i dokumentasjonen Utdypningsfase Denne fasen dreiet seg for det meste om implementering av oppgaven. Vi valgte tilslutt å programmere i ASP. NET.MVC med Sharp architecture Overgangsfasen Testing er en viktig fase under et prosjekt. Gjennom hele implementeringen ble designen og systemet testet ut og feilsøkt. Små feil i design og system ble rettet på med engang. Testrapport ble utarbeidet. Deretter lagde vi testrapporten, brukemanual, og det ble skrevet om videreutviklings muligheter for produktet Kompetansetilegning Flertall i gruppen har kun hatt grunnleggende ASP. NET så vi ble nødt til å tilegne oss en del ny kunnskap om programmeringsspråket vi faktisk valgte. Vi synes at dette virker interessant, både fordi det er et kraftig utviklingsspråk, og fordi vi ville utvikle våre programmeringskunnskaper. Først prøvde vi oss frem med MS Visual Studio 2010, slik at vi ble kjent med programmet vi skulle bruke. Vi ble gradvis kjent med funksjonene og oppbyggingen. 37

38 8 Dokumentasjonsfasen Dokumentasjonen har vi jobbet mest med i slutten av prosjektperioden. Prosjektdagboken har vært viktig i denne delen av prosjektet. Vi har gått tilbake til prosjektdagboken hvis vi ikke husket detaljert hva som hendte i de forskjellige prosjektfasene. Første delen av denne fasen skulle styringsdokumentene og sluttrapporten gjøres ferdig. Styringsdokumentasjonen inkluderer prosjektskisse, prosjektdagbok, forprosjektrapport, arbeidsplan, fremdriftsplan, kravspesifikasjon og dagbok. Mange av disse var allerede ferdig, og måtte bare settes sammen på en riktig måte. Første steg i sluttrapporten var prosessrapporten. Her legges det fram bakgrunn og underlag for det resultatet vi har kommet fram til. Den forteller kort om forholdet under arbeidet, hvilke arbeidsmåter vi valgte, kort om hvilket arbeid som er utført og hvilke utfordringer arbeidet har bydd på. Sluttdrapporten ble skrevet mot slutten av prosjektperioden. Vi hadde svært god nytte av prosjektdagboken i denne delen av prosjektet. Selv om vi har skrevet en del dokumentasjon underveis har mye av dokumentasjonen vært umulig å skrive før hele programmet var ferdigskrevet. Produktdokumentasjon, testdokumentasjon og brukermanual er eksempler på dette. Videre kom produktrapporten. I denne beskrives mer grundig hva som er gjort og hvordan dette ble utført. Siste del av sluttrapporten er brukermanual og test dokumentasjonen som skal både være til hjelp ved bruk av systemet og for videre utvikling av systemet. Etter disse fasene ble alle dokumentene satt sammen til et helhetlig bilde. Videre ble det lest korrektur og gjort redigeringer der det trengtes. Prosjektet ble trykket opp i 3 eksemplarer og levert inn i tilegg sendt elektronisk til oppdragsgiver. Videre startet arbeidet med den muntlige presentasjonen som skal holdes den 14.juni Testfasen Testing er en viktig fase under et prosjekt. Det må alltid regnes med at feil vil alltid eksistere under implementasjonen, derfor må man luke ut dem man finner og dokumentere dette for fremtidige brukere. Vi ønsket å dele denne fasen opp i to deler, når en del var ferdig, skulle gruppen selv teste for feil, funksjonalitet og brukervennlighet. For å få en objektiv mening på ting, tenkte vi å organisere en testrunde med oppdragsgiver og eventuelt noen av de ansatte mot slutten av hovedprosjektet, men det ble dessverre ikke som planlagt. Det skyldes at vi var litt uheldig med konstruksjons prosess og ble derfor ferdig rett før innlevering. Systemet ble derfor kun testet på gruppemedlemmer. For mer informasjon referer vi til testrapporten. 38

39 9 Utviklingsteknologi 9.1 Programmeringsspråk Som tidligere nevnt hadde oppdragsgiver ingen krav vedrørende verktøy som tas i bruk under utviklingen. Systemet er laget med tanke på at det skal være mulig å utvide ved senere anledninger. Siden systemet er nytt er det sannsynlighet for at foreningen kan ønske utvidelser etter hvert. Valget stod i hovedutgangspunkt mellom PHP og ASP. NET.MVC PHP Fordeler Ulemper - Svært utbredt og er på vei opp - Flere i gruppa kan språket flytende - Kommuniserer veldig godt sammen med SQL generelt - PHP assosierer med Linux, webserveren Apache og databasen MySQL - Mye må lages fra Scratch - Er et høynivå språk, og viktig å være helt presis for at maskinen ikke tolker helt feil ASP. NET Fordeler Et sikkert språk å kode i Gode muligheter for videreutvikling Brukes i næringslivet Ulemper Bundet til Windows 9.02 Løsning Et problem som imidlertid dukket opp var hvilket språk vi skulle kode i. Dette var jo ikke 100 % avgjort og det viste seg at gruppen var her ganske delt. Deler av gruppen ville kode i PHP da dette var et språk som flere kunne. Dessuten hadde noen av gruppemedlemmene dette som valgfag dette semesteret. Erik som jobber deltid i et privat firma kom med forslaget om å bruke ASP. NET MVC med Sharp architecture som er basert på domain driven design modell. Dette på grunnlag av at det er generelt sikrere enn PHP og har mye større muligheter for videreutvikling. Gruppen ble til slutt enig om ASP. NET MVC når alle fordelene kom fram. Egenansvar for alle gruppemedlemmer var å lese litteratur siden ingen av oss kunne akkurat denne grenen av språket fra før. 39

40 9.03 Andre utviklingsteknologier Andre utvilkings teknologier som ble brukt i prosjektet: MSSQL NET.MVC EXTJS - javascript framework jquery Fluent n Hybernate 10 Arbeidsverktøy Til selve utviklingen brukte vi forskjellige programmer ut ifra det vi følte var mest behagelig for oss selv og som dekket behovet. Diverse verktøy vi tok i bruk var: Microsoft Office Word 2007 All dokumentasjons arbeidet og rapporteringen foregikk her. Dette er en programvare som samtlige gruppemedlemmer hadde på hver sin bærbar Pc. Dette er et tekstbehandlingsprogram som blir brukt daglig av alle i gruppen og dermed var vi godt kjent med den. Microsoft Project Manager Ble brukt som et hjelpeprogram for å tegne fremdriftsplan. Microsoft Excel Excel ble brukt for å utarbeide arbeidsplanen raskt og enkelt. Adobe Photoshop CS Profesjonelt bildebehandlingsprogram. Programvaren er ikke gratis, men har en 30-dagers prøveperiode. Denne programvaren ble kjempenyttig ved grafisk design av Web-løsningen. Rational Rose Rational Rose er en visuell modellering og utvikling verktøyet ved hjelp av Unified Modeling Language, UML, lar programmet utvikling, datamodellering, webtjenester design, business modellering, eldre program forlengelse, og komponentbasert modellering. Microsoft Project Designet for å hjelpe prosjektledere i å utvikle planer, tildele ressurser til aktiviteter, sporing av fremdrift, styring budsjetter og analysere arbeidsmengder. 40

41 11 Organisering Intern organisering Det er naturlig i starten av et prosjekt å dele ansvarsområder og lage ansvarskart. Som gruppe har vi gjerne forskjellige bakgrunn og kunnskap, på grunnlav av det ble hvert medlem tildelt ansvarsområder etter evner og interesser. Med fokus på leveransene hadde vi faste møter 1-2 ganger i uken. Dersom vi skulle få tak i hverandre utover møtetiden vår, var alle tilgjengelige på telefon og e-post. Dessuten jobbet vi mye sammen. Med jevne mellomrom ble det arrangert gruppemøter for å gjøre opp status og fordele arbeidsoppgaver. Vi definerte og fordelte dem i gruppen. Arbeid som hadde blitt utført ble evaluert i plenum på møtet, og avgjørelser for videre fremgang ble gjort Ansvarskart Prosjektansvarskartet viser hovedoppgaver og hvilke gruppe medlemmer som har ansvar for disse oppgavene og er presenterte i Tabell 2.2 Ansvarskart er delt inn i to deler. Hovedansvarlig er den personen som har hovedansvaret, mens delansvarlig skal hjelpe til ved behov (eller for eksempel ved sykdom). Selv om vi satt opp ansvarskart samarbeidet vi iblant og byttet på de ulike ansvarsområder ettersom det var nødvendig. Ansvarsområde Hovedansvarlig Delansvarlig Prosjektleder Erik Mona Teknisk ansvarlig Erik Ehsanullah Web-utvikling Erik Shahzeb Web-design Shahzeb Erik Modellering Marit, Mona Erik Dokumentasjon Marit, Mona Resten av gruppen Back-up Erik Ehsanullah Testing Erik Ehsanullah, Shahzeb Prosessdokumentasjon Mona Marit Kvalitetssikring Marit, Mona Resten av gruppen 41

42 Rapport Marit, Mona Resten av gruppen Fremdriftsplan & Arbeidsplan Mona 42

43 12 Risikofaktorer Risikoplanlegging & Risikoplanstyring Vi har satt opp hver risikofaktor vi mener kan spille en større rolle for arbeidet med prosjektet. For hver faktor er det gitt en vurdering av sannsynligheten for at den vil oppstå. Herunder skriver vi hva konsekvensen ville bety. Til slutt har vi satt opp et par forslag til tiltak for forebygging og oppfølging av disse faktorene. Mulig risiko: For lite tid Sannsynlighet 30 % - vi jobber i et gruppearbeid basert på innleveringsfrister. Frister er viktige, og kan skape stramme vilkår for gruppearbeidet. Konsekvens Vi får ikke levert produktet i tide. Dette vil være en fatal konsekvens da det gir grunnlag for karakter. Realiteten er at tidsfristene våre er absolutte. Alternativt vil kvaliteten på produktet og rapporten bli dårligere for å kunne rekke med tiden! Tiltak Vi kan bruke strammere tidsrammer og organisere tiden bedre. Bruke en mer inkrementell metode. Sykdom / Miste personer Sannsynlighet % Det er ikke uvanlig at studenter hopper av studier. Ellers er det også en fare for at man blir syk og fraværende over i verste fall lengre tid. Konsekvens - mer arbeid blir forskjøvet på andre som kan påvirke tidsbudsjettet. Å få dårlig tid ser vi på som svært alvorlig. Det er en alvorlig konsekvens med tanke på ressurser og tidsbudsjett. Tiltak Oppmuntre hverandre til å komme seg gjennom alle vanskelige fag. Være inkluderende overfor hverandre. Konflikter innad i gruppen Sannsynlighet 20 % - Det er ikke vanskelig å finne moment i arbeidet som kan oppmuntre til krangel og uenighet. Dette kan være følgefeil av en dårlig kommunikasjon. Konsekvens Dette kan gå utover samarbeidet i gruppen. Det kan gå mye tid i krangel og diskusjon. Det kan gå utover kommunikasjon i gruppen. Derimot kan det også gi nye innspill og kreative innslag i forhold til produkt, løsninger og ideer. Konflikter sees på som alvorlige, men kan som oftest løses. Tiltak Konflikter kan løses. Må lære å se realiteten i situasjonen og klare å finne den fornuftige løsningen. Kan spørre om råd hos veileder som har en nøytral rolle i gruppen. Blindpassasjerer Tap av data Sannsynlighet 5 % - Det kan alltid være en person i gruppearbeid som ikke holder frister og ikke imøtekommer gruppas krav. Konsekvens Gruppen får problem med organiseringen og planleggingen og gjør det vanskelig å holde frister. Tiltak passe på at et gruppemedlem blir holdt ansvarlig for den oppgaven som er blitt tildelt. Ved å gi enkeltmedlemmer ansvar i forhold til en oppgave vil det gi en pliktfølelse. Dette vil medlemmet leve opp til fremfor å stå ansvarlig for at noe ikke er blitt gjort. Sannsynlighet 5 % - Miste dokumenter eller overskrive aktuelle filer Konsekvens - Stor konsekvenser dersom data må skapes på nytt, særlig hvis dette gjelder data som tok lang tid å skape. Kan være en alvorlig faktor hvis det skjer nærmere deadline. 43

44 Tiltak - Kontinuerlig ta backup, eller passe på at de seneste versjonene blir delt med andre/lagt på andre steder. Å ha all data liggende på en minnebrikke er ikke tilstrekkelig minnebrikker forsvinner. Ta gale beslutninger Sannsynlighet 30 % - det er lett å ta gale beslutninger på områder vi ikke er helt trygg på. Konsekvens fører til at prosjektet kan tape kurs mot problemstilling og løsning. Ta gale beslutninger kan være svært alvorlig. Tiltak Det er viktig at alles meninger spiller en rolle. Vi er forskjellige og har forskjellige referanser på som hva som måtte virke riktig og galt. Diskutere og vurdere sammen med veileder er også aktuelt. Mangel på kompetanse Sannsynlighet (40 %) - vi er i utgangspunktet ikke erfarne systemutviklere og er ikke eksperter i noen programvarer eller programmeringsspråk. Men vi er studenter og tilegner oss ny kompetanse ettersom vi går gjennom semesteret. Sannsynligheten for mangel på kompetanse vil derfor synke proporsjonalt med gjennomgang av pensum/øvinger. Konsekvens kan føre til at produktkvaliteten blir dårlig. Større mulighet for feil og slurv. Sløsing av tid på usikkerhet og ekstra lesing under verdifull møtetid. Tiltak kursing og lese mer. Følge opp forelesningsnotater og ukeoppgaver. Dårlig kommunikasjon Sannsynlighet 40 % kommunikasjon kan være utfordrende selv med dagens teknologi som mobiltelefoni og internett. Vi er alle forskjellige og kan oppleve misforståelser og fornærmelser i mange tilfeller. Konsekvens - Det kan oppstå misforståelser i forhold til oppgaver og ansvar. Informasjon kan komme for sent slik at mottaker ikke rekker å reagere eller handle i tide. Dårlig kommunikasjon går utover tid hvis den ikke er effektiv eller uklar. Tiltak - Bli rutinerte i metodene å ha god kommunikasjonskanalen. Vi må være direkte i tale og tekst. Vi må lytte til hverandre. Dårlig organisering Sannsynlighet 20 % - vi er i utgangspunktet ikke erfarne i systemutvikling. Konsekvens kan føre til at tid blir feilprioritet. Dårlig organisering av arbeidsinnsats og resurser kan føre til at man mister fokus på de viktige tingene. Tiltak Å ha risikofaktorer i bakhodet og tenke omhyggelig på særlig tid og ansvar. Beregne tidsblokker slik at arbeidsmengden og tidspresset blir en kontinuitet. 44

45 13 Kvaliteten på prosjektet Brukervennlighet Det har gjennom hele prosjektprosessen blitt lagt stor vekt på brukervennlighet. Både for brukere og administratorer av systemet, men også for potensielle brukere som er innom. Vi har testet systemet for å sjekke brukervennligheten på alle deler av systemet. Dette viser at bruken av oversiktlig sideoppsett, selvforklarende menyer og enkel fargebruk har gjort siden brukervennlig for alle brukere av systemet Sikkerhet Det ble foretatt backup av alt vi har gjort gjennom hele prosessen. Dokumentasjon og kildekode til programmet ble laget på forskjellige eksterne harddisker slik at vi var på den sikre siden. I tillegg hadde vi en USB-brikke for små og midlertidige backup, hvor vi kunne hente kjapt dataene fra. Sikkerhetskopiering var viktig for at data ikke skulle gå tapt. 45

46 14 Utviklingsprosessen Generelt Under utviklingen av webbaserte løsning gjennomgikk gruppen flere faser. Noen av disse fasene var avhengig av resultatene fra forrige fase for å kunne løses riktig. Utviklingsprosessen gikk det meste ganske fritt da vi ikke har fått stramme krav fra oppdragsgiver. Her var det bare å sette i gang med de forskjellige fasene ved å følge kravspesifikasjonen og de diagrammene som ble lagd Kravspesifikasjonen Siden kravspesifikasjonen presenterer hvordan programmet er bygd opp og hvordan den skal fungere så er det viktig å forholde seg til den. Vi forholdt oss mye til kravspesifikasjonen under designen og implementeringen. For mer detaljert kravspesifikasjon referer det til kravspesifikasjon dokumentet. De grunnleggende tankene har ikke forandret seg så mye etter hvert, men vi visste at det skulle forandre seg etter hvert som vi ble mer kjent med systemet og det verktøyet vi brukte. I etterkant har det vist seg å være positivt for oss at kravspesifikasjonen ikke var laget til minste detalj, fordi på den måten fikk vi litt frihet til å foreta nødvendige endringer Endringer i kravspesifikasjon Det ble underveis i prosjektet små endringer i programmet. Men den endelige kravspesifikasjonen stemme se case med beskrivelser Use-Case for medlemmer 46

47 Use-Case Aktør Prebetingelser Redigere profil Medlem Brukeren må være logget inn Postbetingelse Hendelsesflyt 1. Brukeren/administratoren redigerer de personlige opplysningene som er aktuelt å endre på og lagrer endringen(e) Alternativ flyt 1a. Systemet lagrer ikke endringen(e) Use -Case Se oversikt over arrangementer og poster Aktør Prebetingelser Medlemmer i Tønsberg Seilforening Brukeren må være logget inn Postbetingelse Hendelsesflyt 1. Den aktuelle brukeren ser på en oversikt over arrangementer i nærmeste framtid og poster som er aktuelle for arrangementet Alternativ flyt 1a. Systemet er nede 1b. Oversikten er mangelfull Use -Case Velge vakt Aktør Prebetingelser Medlemmer Brukeren må være logget inn Postbetingelse Hendelsesflyt Alternativ flyt 1. Den aktuelle brukeren velger den vakten han/hun ønsker å ta på det ønskede arrangementet og posten 1a. Brukeren får ikke valgt den ønskede vakten, posten eller arrangementet 1b. Den ønskede vakten er opptatt 47

48 Use- Case Bytte vakt Aktør Prebetingelser Medlemmer Brukeren må være logget inn Postbetingelse Hendelsesflyt 1. Den aktuelle brukeren tar kontakt med en administrator om at han/hun ønsker å bytte/slette vakt. Alternativ flyt 1a. Brukeren finner ikke kontaktinformasjon til administrator Use -Case Aktør Prebetingelser Sjekke postkasse Medlemmer Brukeren må være logget inn Postbetingelse Hendelsesflyt 1. Brukeren sjekker sin egen postkasse for e-poster mottatt fra administratorer av systemet. Dette kan være bekreftelse på bytte av vakter eller vanlige informasjonsbrev om arrangementer osv. 48

49 Use-case for administratorer i Tønsberg Seilforening Use-Case Aktør Prebetingelser Opprette arrangementer Administratorer i Tønsberg Seilforening Personen må være medlem med administratorrettigheter. Administratoren må også være innlogget med sitt unike brukernavn og passord. Postbetingelse Hendelsesflyt 1. Personen er innlogget og har tilgang som administrator 2. Administratoren får lagt inn det ønskede arrangementet i systemet Alternativ flyt 1a. Brukeren har glemt passordet og kommer ikke inn. Man vil da ha muligheten til å få midlertidig passord tilsend på registrert e-post. 1b. Systemet er nede og brukeren får ikke logget inn. Prøv igjen senere og dersom problemet vedvarer må systemansvarlig kontaktes. 2a. Administratoren får ikke laget arrangementet. Løsningen da er da å prøve igjen senere. Om problemet vedvarer må systemansvarlig kontaktes. 49

50 2b. Arrangementet vises ikke selv om det ble lagret. Systemansvarlig må kontaktes. 2c. Delen av systemet som tar seg av opprettelsen av arrangement er nede. Man må da kontakte systemansvarlig og få han til å fikse dette. Use-Case Aktør Prebetingelser Postbetingelse Hendelsesflyt Opprette poster og vakter på arrangementer Administrator i foreningen Man må være innlogget som administrator og arrangementet man ønsker å legge posten på må eksistere 1. Personen er innlogget og har tilgang som administrator. 2. Administratoren får lagt inn ønskede poster på arrangementet. Alternativ flyt 1a. Brukeren har glemt passordet og kommer ikke inn. Midlertidig passord kan da bli tilsend på registrert e-post. 1b. Systemet er nede og brukeren får ikke logget inn. Prøv igjen senere og dersom problemet vedvarer må systemansvarlig kontaktes. 2a. Arrangementet eksisterer ikke. Dersom man vet arrangementet er opprettet må systemansvarlig kontaktes. Ellers må man lage arrangementet først. 2b. Administratoren får ikke lagt inn poster på det ønskede arrangementet og systemansvarlig må kontaktes. 2c. Postene vises ikke under det respektive arrangementet selv om de ble lagret. Systemansvarlig må kontaktes UML Diagrammer. Vi har laget følgende diagrammer til systemet Avhengighetdiagram Databasemodell 50

51 15 Avsluttendedel Generelt Vi utviklet arbeids- og fremdriftsplan for hele tiden å ha en fullstendig oversikt over hva som skulle gjøres når. En kravspesifikasjon ble deretter tilsendt av oppdragsgiver, som inneholdt oppdragsgivers krav til systemet. På denne måten hadde vi en bra plan på hva som skulle gjøres og når det skulle være ferdig. Vi håper at alle brukere skal ha en positiv opplevelse ved bruk av systemet, og at det skal være en god informasjonsportal for nye brukere og ikke minst for potensielle brukere samt vi håper at oppdragsgiver er fornøyde med de løsninger vi har kommet opp med, og at de vil ha god nytte av systemet vi har utviklet for dem. Det kan ved senere tidspunkt bli aktuelt med enkelte utvidelser Hva vi har lært Det å planlegge et stort og omfattende prosjekt som man vet vil bli brukt i den daglige driften av en bedrift, og derfor stilles forventninger til, stiller store krav til oss som utviklere. Prosjektarbeidet har gitt oss mye erfaring med hvordan slike store prosjekter skal utføres, og prosessen har gitt oss innblikk i hva som er viktig å vektlegge i de forskjellige fasene prosjektet har bestått av. Vi har lært viktigheten av planlegging, og bruken av fremdriftsplan Hva kunne vært gjort annerledes Stor sett gikk utviklingen bra, men vi kunne ha satt av litt mer tid på slutten til å samkjøre dokumentene osv. Vi kunne også ha satt av mer tid i tilfelle problemer knyttet til koden Videre I løpet av prosjektet ble det opprinnelige systemet til Tønsberg seilforening forbedret og det ble satt opp et fullstendig IT-system for en forening som er avhengig av at dette fungerer optimalt. Det vil bli brukt daglig i foreningen. Vi har dokumentert alt vi har gjort og implementert, for å gjøre driften videre så enkel som mulig. 51

52 16 Konklusjon Vi har laget et godt produkt som vi tror oppdragsgiver er veldig fornøyd med. Det har vært spennende og utfordrende å utvikle et fullstendig system. Prosjektet har krevd at vi har satt oss inn i nye teknologier. Vi har dratt god nytte av god planlegging og strukturert arbeid. Samarbeidet i gruppa har fungert godt. Vi har alle vært godt motiverte, vi har hatt en god kommunikasjon og vært flinke til å utnytte hverandres sterke sider. Alt dette til sammen har gjort det gøy å jobbe med prosjektet og vært nøkkelen til at vi har fått et resultat vi er fornøyde med. Gruppen har nådd målene vi satt oss i begynnelsen av prosjektet. Vi er totalt sett veldig godt fornøyde med resultatet. Det har vært en lærerik prosess, både med tanke på programmering av valgt teknologi og gjennomføring av et så stort prosjekt. At dette også er et system som skal brukes av både kunder, ledelse Vi har fått god erfaring i kommunikasjon med arbeidsgiver og med gruppearbeid, som vi er sikre på at vi vil få god nytte av senere. Gruppa har fungert meget godt. Vi har ved enkelte anledninger hatt forskjellig syn på løsninger, men føler ved prosjektslutt at dette kun har styrket kvaliteten på arbeidet. 52

53 Produktrapport 53

54 Forord Dette dokumentet gir en detaljert beskrivelse av vår web løsningens programmessige oppbygning, illustrasjoner, diagrammer over systemet, funksjoner og database tabeller. Det skal være mulig å sette seg godt inn i systemet ved å lese denne produktdokumentasjonen. Dette dokumentet er beregnet for de som skal installere, vedlikeholde og videreutvikle systemet. Sammen med prosessrapporten skal den gi et helhetlig inntrykk av arbeidet som er utført og det produktresultat som er oppnådd. Rapporten inneholder noe fagterminologi, så det vil være nødvendig med basiskunnskaper innenfor emnetfor å få fullt utbytte av rapporten. Testrapporten og kildekode er lagt med som vedlegg. 54

55 Innhold 2 Innledning Oppdragsgiver Bakgrunn for prosjektoppgaven Dagens situasjon Målet med oppgaven Teknologier Rammebetingelse Utviklingsmiljø Nettleser Datastruktur Database Backend Frontend Sideoppsett Krav/Installasjon Klient/tjener-løsninger Produktet Sikkerhet Utvidelsesmuligheter

56 Hovedprosjekt Høgskolen i Oslo Innledning 2.1 Oppdragsgiver Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som f.eks. SpareBank1, Esso, Vakt Service og noen andre. Tønsberg Seilforening holder til på Fjærholmen rett utenfor Tønsberg. Der har de ideelle fasiliteter for å utøve deres idrett. Anlegget eies av foreningen og det har et stort uteområde med eget bryggeanlegg og klubbhus med garderober. Foreningen har et høyt aktivitetsnivå både blant jolle seilere og tur-havseilere. De arrangerer årlig treningsleiere, nasjonale og internasjonale regattaer. 2.2 Bakgrunn for prosjektoppgaven Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. I forbindelse med arrangementer, trenger de et system som administrerer ulike vakter til enhver tid. Her er det noen krav som de har satt opp for en eventuell løsning: Planlegge, tidfeste, definere og beskrive ulike vakter for ulike arrangementer - generelt for Klubbkomiteen (kiosk, kjøkken, avfall, renhold), Regattakomiteen (startbåt, sikringsbåt, bøyebåt, organisering land under arrangementer o.s.v.) Alle vakter fordeles på tilgjengelige grupper som tur/hav, jolle, etc. og hvert medlem kan følge dette på nett Alle vakter for alle arrangementer bør kunne legges ut på nett med mulighet for elektronisk påmelding/registrering av frivillige. Gjerne med aktivering av mobilnummer for utsendelse av påminnelse for vakt Arkiv for internt bruk, erfaringsdatabase med kommentarfelt, innkjøp etc. 2.3 Dagens situasjon Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. De har blant annet også noen støttespillere, som f.eks. SpareBank1, Esso, Vakt Service og noen andre. Ved Tønsberg Seilforening registrer de deres arrangement med blant annet Excel, penn og papir. Registreringsrutinene som finnes i dag er papirbaserte, tidkrevende og lite brukervennlige. Når ledere skal arrangere fester i dag, må informasjon om arrangementet skrives i et Excel-regneark og i Microsoft Word. Ved endringer blir regnearket oppdatert, og dokumentet i Microsoft Word blir fylt ut og arkivert. Det er en del ting som ikke fungerer optimalt med denne løsningen. Dokumenter kan forsvinne da ansatte slutter eller det kan bli forsinkelser når ansatte er meldt syke for en periode. Regnearket er ment å vise lagerbeholdningen til enhver tid, men dette kan bli glemt, eller utfylt feil. Det er mulig at regnearket ikke blir oppdatert og papirskjemaet blir borte hvis slike situasjoner skjer. 56

57 2.4 Målet med oppgaven Tønsberg seilforening er en organisasjon for seilinteresserte og de har mange forskjellige typer arrangementer i året. I forbindelse med deres arrangementer har de behov for et nytt system som kan administrer ulike vakter til enhver tid. Gruppen har tenkt ut en plan for å gjennomføre prosjektet ved å fordele vakter på tilgjengelige grupper som tur/hav, jolle, o.l. Medlemmene skal kunne følge dette på nettet. Vaktene skal legges ut på nettet og ha mulighet for elektronisk påmelding /registrering av frivillige (kun medlemmer). Vi tenker å utforme tre brukerroller. Medlem, som kan se ledige vakter og som kan også melde seg på. Vakt/frivillige kan se hvem som holder arrangementer og hvor de holdes. Dersom de ønsker kan de melde seg på ulike arrangementer og vakter som er blitt satt opp. Superbruker er de som har detaljert oversikt. De vil ha oversikt over alle brukere og vaktposter. De kan endre tid og beskrivelse på alle vakter i systemet. Hvis det er behov kan de opprette/slette nye vaktposter. Som superbrukere har de tilgang til alle brukeres kontoer og erfaringsdatabase. Oppretting av brukere, endring av passord, utestenging av bruker og sperre tilgang til systemet (vedlikehold eller ingen arrangementer) er også innenfor superbrukerens område. Gruppen har per dags dato tenkt litt på ulike verktøy i forbindelse med å utvikle en driftsikker løsning, og har kommet frem til at en av de aktuelle kandidatene for utviklingen er utviklingsmiljøet ASP. NET MVC 2 med MSSQL. 57

58 3 Teknologier 3.1 Rammebetingelse Rammebetingelser er ganske frie. Men generelt sett og ut ifra vår perspektiv så bør løsningen være et hensiktsmessig brukergrensesnitt som er enkelt å bruke uten at det skal kreve forkunnskaper innen avansert databruk. Web-løsningen er ment for følgende brukere - Administrator - Medlemmer Når en bruker logger seg inn på systemet, skal denne brukeren få en side som er tilpasset etter gruppen brukeren hører til og med de rettigheten en har. Under beskriver vi korte trekk av de viktigste kravene som oppdragsgiveren vår stiller. For en fullstendig beskrivelse viser vi til krav kravspesifikasjon som er blitt utarbeidet Administrator skal ha mulighet til å gjøre følgende oppgaver etter innlogging: - Oversikt over arrangementene - Lage/slette arrangementer - Opprette/slette vaktposter på arrangementer - Administrere/legge til nyheter - Administrere medlemmer - Oppdatering Medlemmer skal ha mulighet til følgende etter pålogging - Se en oversikt over alle arrangementer - Melde seg på/av events - Melde seg på /av vaktposter - Oversikt over arrangementene som medlemmet har meldt seg på - Lese nyheter 3.2 Utviklingsmiljø Database: - MS SQL Server 2008 Utviklingsspråk: - C# / ASP. NET MVC 2 med Sharp Architecture 1.5 RTM, med Fluent nhibernate(orm) og Castle Windsor - CSS json - Javascript, javascript frameworks ExtJS og jquery 58

59 - HTML - SQL 3.3. Nettleser I disse dager er det mange nettlesere på markedet og dette skaper et lite problem for utviklere, da en enkel glipp i programmeringen kan bli ignorert av en nettleser, men skape store designsmessige problemer i en annen. Nettsiden er derfor designet og programmert slik at den skal fungere optimalt uansett hvilken nettleser man benytter, så fremt den har støtte for Javascript. Det er også en fordel at nettleseren støtter CSS 3, men ikke et krav. Siden har blitt testet feilfritt med de mest kjente nettleserne, altså Internet Explorer 8, Mozilla Firefox, Google Chrome, Safari og Opera. 59

60 4 Datastruktur 4.1 Database Databasemodell Her kan vi se alle tabellene i databasen til webløsningen med relasjoner og kolonner. Fremmednøkler og primærnøkler. Denne er på formen BCNF. 60

61 4.2 Backend Datatstrukturen på backend-delen av løsningen er basert på MVC, altså Model-View-Controller Design Pattern. Det vil si at når vi skal ha en request til og fra webserveren vil dette føre til et metodekall på gjeldende kontroller. I vår løsning benytter vi oss av Domain Driven Design Pattern, det vil si at vi fordeler hele applikasjonen på forskjellige lag, altså vi har et domene som består av flere lag. På denne måten har man mye mer kontroller over applikasjonslogikk og businesslogikken. Samtidig så er det dette en fordel når man skal gjennomføre enhetstester. Vi valgte derfor å benytte oss av dette. Vi har også brukt en ORM, altså Object-Relational-Mapper, som gjør om objekter til rader og objektenes egenskaper/data til kolonner. Ved bruk at en slik teknologi kan vi sende og motta objekter direkte fra databasen til applikasjonen. Datastrukturen er som følgende: MightyEvent.Core Her ligger kjernen og businesslogikken. MightyEvent.Data Datalag MightyEvent.Web Presentasjonslag. MightyEvent.Web.Controllers Kontrollere som behandler requests og sender ønsket view og gjør kall på databaseoperasjoner for alle objekter som skal opprettes, endres, slettes eller presenteres. MightyEvent.Tests Dette er testprosjektet vårt der vi tester alle disse lagene. Hver kontroller har en Index, Create, Show, Edit, Delete-metoder i tillegg har alle kontrollere egne viewmodels, som benyttes for å aksessere data og presentere den på websiden. Det finnes noen hjelpeklasser som for eksempel CaptchaGenerator, denne har som funksjon å generere et tilfeldig bilde med tekst som skal vises på skjemaet for oppretting og endring av bruker. I webløsningen vår har vi to essensielle mapper, nemlig EventMaps og xcx2413, i mappen EventMaps legges alle oversiktskart over ulike events og i mappen xcx2413 lagres det genererte captchaer, grunnen til at vi har valgt å beholde disse filene permanent er for å kunne vite hvilken bruker som eventuelt utførte handlingen ved et angrep. EventMaps-mappen har vi også valgt å beholde filene etter at eventet eventuelt er slettet, fordi dette gir oss en mulighet for å utvide det hele med et galleri. 4.3 Frontend Webløsningens frontend er basert på javascript-framework sammen med c#, html og css. I javascriptene har vi plottet inn c# kode for å kunne generere de dynamiske etter objekter som blir sendt til siden. Dette gjør at vi lett kan gjøre endringer i kategorier, komiteer og at skjemaene en bruker fyller ut blir generert etter brukerens informasjon fra før av. Dette fører til økt brukeropplevelse. 61

62 4.4 Sideoppsett Hovedsiden er brukervennlig og viser nyheter og nyeste events, samt andre sportsnyheter. Dette er en hovedside som har dynamisk innhold basert på linker man har trykket på. Hovedside er standard design som er lik for alle brukergrupper: I forbindelse med at vi utvikler denne i.net benytter vi oss av MasterPage og alle Viewene fra kontrollerne kommer i MainContentHolder og SidebarContentHolder. 4.5 Krav/Installasjon Krav for kjøring av applikasjonen: Windows Server 2008 R2 IIS 7.0 MSSQL 2008 MVC 2 Installasjon: Man må installere overnevnte software/programvare samt overføre løsningsmappen til webserveren rootkatalog og kjøre et SQL-script for oppretting av database. 62

63 4.6 Klient/tjener-løsninger I forbindelse med kommunikasjon mellom frontend og backend har vi lagt inn både validering av inputdata både fra klientens og serveren side. På denne måten sikrer vi at dataen er konsistente og beholder sin integritet, det vil si høy pålitelighet. 63

64 5 Produktet Gjeste sider Medlemssider Disse sidene fungerer som helt vanlige nyhetssider og informasjonsssider for gjester. Her kommer foreningene med de tilbudene den tilbyr og arrangementer som skjer i de forskjellige periodene. Her kan gjester som ønsker melde seg til arrangementer, men da må de registrer seg først. Disse sidene er kun tilgjengelige for registrerte medlemmer som logger seg med brukernavn og passord. Hensikten med denne delen er at den skal fungere som en plattform hvor medlemmer selv kan melde seg opp til ønsket arrangement får mer oppdaterte informasjon om arrangementer, hvilke medlemmer som har meldt seg og andre nyttige informasjon. Administrator sider Denne delen skal la en administrator administrere de to andre delene av systemet. Administrator logger seg inn med brukernavn og passord. Han skal administrere ved å legge til/ registrere, redigere og slette: Arrangementer Vaktpost Vaktliste Komité Ansvarsområder Medlemmer Budsjett Bilder Nyheter 64

65 6 Sikkerhet Får å melde seg til event må man være registrert medlem og ha fått tildelt et brukernavn og passord. For passord er det brukt md5 algoritme(message-digest algorithm 5). MD5 er en sjekksumalgoritme og en internettstandard (RFC 1321), som brukes av en mengde forskjellige sikkerhetsapplikasjoner og for å sjekke integriteten til datafiler. MD5-algoritmen lager en 128-bits (16 byte) sjekksum, som vanligvis oppgis som et 32-tegns heksadesimalt tall. Med tanke på at dette er en stor forening og at den har mange brukere er det stor sannsynlig at foreningen blir utsatt for angrep utenfra. Derfor brukte vi denne teknikken fordi den krypterte passordet ikke kan dekrypteres tilbake. 7 Utvidelsesmuligheter - Mobilvarslingssystem for bytting av vakter - Realtimeinformasjon om startede events - Bildegalleri 65

66 Testrapport 66

67 Forord Hensikten med denne rapporten er å beskrive hvordan vi har utført tester på brukersystemet vårt som vi har laget for Tønsberg Seilforening i forbindelse med hovedprosjektet Innhold 3. Innledning: Enhetstesting av systemet ved å kode tester Firefox addons: Skjermbilde av løsningen i forskjellige nettlesere: Instant validering: Datalagring, datasletting, dobbeltlagring: Testing GUI: Navigering: Språk Systemet i bruk av tilfeldige personer:

68 3. Innledning: Det er en veldig vanskelig og krevende jobb å lage et feilfritt system. Testing er en vesentlig del av programmering, og mye tid brukes nettopp på testing av systemer for å rette opp feil. Jo mer et system blir testet desto sikrere vil det være. Vi har selvsagt brukt mye tid på testing. Vi har tatt utgangspunkt i vår prosessmodell for utføring av tester. Vi har skrevet tekst koder som sjekker at en metode utføres riktig og at den utfører nøyaktig den oppgaven det er ment for. I tillegg har vi selv tatt i bruk systemet i en lengre periode for å finne eventuelle feil og rette dem opp. Systemet har blitt testet underveis mens den var under utvikling, men den største testingen ble utført etter at systemet var ferdig. Det har også blitt lagt vekt på brukergrensesnitt og design, og selvsagt har det blitt testet en del. Systemet har blitt testet i flere forskjellige nettlesere og fungerer like bra på alle sammen. Nettlesere vi har testet med er: Internet Exploerer, Firefox, Chrome, Opera og Safari. Vi avsluttet testing ved å be to tilfeldige studenter for å utføre noen oppgaver vi hadde skrevet på forhånd. Målet med dette var å se om systemet var nok brukervennlig, kanskje noen andre opplevde noe feil, samt se om brukermanualen var til hjelp. 68

69 4. Enhetstesting av systemet ved å kode tester Enhetstesting går ut på at det testes objektets integritet og pålitelighet. Vi la ut relevante feilmeldinger for å gjøre det lettere for å finne frem til feilen og rette den opp. Her skal alle feltene testet. Her er et unitest som viser hvordan vi kan sjekk at det er en admin på eventet. Dersom testen består, vil det se ut som på skjermbilde nedenfor: I motsatt tilfelle vil man få en feilmelding. Feilmeldingen har vi skrevet inn selv, for å gjøre det lettere for å finne frem til feilen. Følgende en skjermbilde av en feil som vi har utført med vilje for å vise frem hvordan det fungerer. Vi fikk dessverre ikke sjanse til å ta et skjermbilde av en feil som ikke var med vilje. Som det ses på skjermbilde, har testen feilet og på det markerte feltet, helt til høyre kommer den feilmeldingen som vi skrev i unitesten. Når det er mange tester, og det aktuelle feltet inngår flere steder, vil det ikke være nok med en så generell feilmelding. Her kommer ASP.NET MVC innbygde funksjonen til nytte for å lokalisere feilen, og bruke minimal med tid for å finne frem til feilen i den aktuelle filen. Skjermbilde under viser feilmeldingen vi la inn, denne meldingen er markert med rødt. Rett under det finner vi filnavnet, og linje nummeret. Dersom det klikkes på det vil man komme rett til den aktuelle linjen i fila og 69

70 feilen kan rettes, og testen kan kjøres på nytt til den er initialisert. Vi har skrevet en test for hver klasse for å sjekke at de egenskapene er initialisert. Følgende legger vi til et skjermbilde av testsesjonen etter å ha kjørt dem alle sammen. Skjermbilde viser antall tester som har feilet, antall vellykket tester, og antall tester som har blitt ignorert. I vår tifelle er det ingen tester som har feilet, total antall vellykket tester er 47, og ingen tester har blitt ignorert. I og med at det er mange tester deler vi det i flere skjermbilder: 70

71 Dersom vi trykker på det som er markert rødt i skjermbilde ovenfor, vil alle testene som tilhører denne klassen skjule seg. Det som er markert blå er det totale antall tester som finnes i denne klassen, og de sjekker integritet av egenskapene. I skjermbilde ovenfor har vi skjult alle unitestene til sine tilhørende klasser. 71

72 Det er også mulig å bruke NCover for å få oversikt over hvor mange prosent av hver enkel del av de forskjellige datalagene som er testet. 72

73 5. Firefox addons: Systemet vårt er testet i de forskjellige nettlesere for å dekke de flestes behov, samt ha et ha plattform uavhengig system. Siden ser ut likt i alle nettlesere. Vi har brukt Firefox oftere enn de andre lesere, det på grunn av nyttige addons nettleseren har. Blant annet Firebug og Web Devoloper Toolbar. Firebug har vi brukt flittig i forbindelse med live redigering. På denne måten har vi spart veldig mye tid, og spart oss for unødvendig frustrasjon. Nedenfor er et skjermbilde av løsningen vår i Firefox med Firebug, som er i bruk. 73

74 6. Skjermbilde av løsningen i forskjellige nettlesere: Som nevnt er det viktig at siden er plattform uavhengig og vises identisk i de fleste nettlesere. Her er skjermbilde av siden tatt fra forskjellige nettlesere: Internet Explorer 8: 74

75 Firefox: Opera: 75

76 Chrome: 76

77 Safari: Skjermbildene ovenfor er minimert med tanke på plass, men de kan forstørres dersom det er ønskelig. 77

78 7. Instant validering: Løsningen vår har en instant validering, noe som innebærer at man får beskjed umiddelbart dersom en eller flere feltene er utelatt. Det gir en bedre brukeropplevelse, samt sparer brukernes tid i det lange løpet. Nedenfor er et eksempel på det: Skjemaet ovenfor er betydelig større enn det som er vist på bilde. Blant annet finnes det tre knapper nederst til høyre og de ser slik ut: Siden skjemaet (Add new event) ikke er ferdig utfylt, som påkrevd, vil Save-knappen ikke lagre noe form for data. Det vil komme opp en melding som ber brukeren om å fylle de/det eventuelle feltene/feltet. Vi har også testet å skrive inn JavaScript i Description delen, i skjemaet, for å teste om det er mulig å kjøre ondsinnet kode. Da fikk vi instant relevant feilmelding og fikk informasjon om at JavaScript er ulovlig. 78

79 8.Datalagring, datasletting, dobbeltlagring: Systemet er sjekket med tanke på datalagring, og alt data som er ment å lagre lagres i databasen. Det er mulighet for å hente ut data av autoriserte brukere. Alle tabellene er på BCNF form. Det finnes ingen duplikater. Det er også mulig å slette data. Sletting, legging og redigering av data er begrenset til en rolle. Det er kun bruker med administrator rolle som kan utføre de nevnte oppgavene. En vanlig bruker vil få en feilmelding dersom det prøves forsøk på slike handlinger. Dersom det legges in nytt data, før det godkjennes, vil det sjekkes om det finnes noe identisk fra før av. Hvis det er tilfelle vil systemet hindre det og brukeren vil få melding om at data finnes allerede i systemet. 79

80 9. Testing GUI: Vi startet med å lage en tegning av websiden på papiret om hvordan det skulle se ut og hvor skulle de forskjellige delene plasseres. Deretter lagde vi et bilde av det i Adobe photoshop. Vi jobbet med design av websiden samtidlig som vi programmerte resten av systemet. En viktig del av designvalget har vært at vi alltid har sett websiden fra brukerens vinkel, og endret på designet underveis. Skal en webside klare å tiltrekke seg flest mulig brukere, er det ikke bare innhold som telles. Design er avgjørende når det gjelder fornøyde besøkere. Farger på en webside skal heller ikke være for sterke slik at brukeren ikke orker å bruke mer enn noen minutter på websiden. Etter en del prøving av forskjellige farger, valgte vi å bruke Cyan. Tekstfarge som er blitt brukt er svart, og hvit enkelte steder, som for eksempel på hurtigmenyen. Bakgrunnfarge under Utvidbarmeny er svart med grå skrift. Kontrastene gjør at teksten blir godt synlig. Et skjermbilde av hurtigmenyen. Faksimile, MightyEvents Vi har valgt forkjellige måter om å gi beskjed til brukeren, enten det er snakk om bekreftelsesmeldinger eller feilmeldinger. Grunn til forskjellige metoder er fordi det falt naturlig. De fleste steder vil det være en popup som forsvinner etter at brukeren har trykket OK-knappen. Enkelte steder er det blitt brukt popup som forsvinner etter bestemt tidspunkt. Alle popup meldingene har Cyan bakgrunn med svart skrift. Andre steder har vi brukt den klassiske måten å formidle feilmeldingene til brukere. Her er det brukt rød skrift med rosa bakgrunn, og en såkalt feilmeldingsikon. Skjermbilde nedenfor viser et eksempel: 80

81 10. Navigering: Det er essensielt å finne frem til riktig side enklest mulig. Vi har valgt en utvidbarmeny, og på den måte har vi sørget for at siden ikke er uoversiktlig og fullt av linker overalt. Det er mulig å få tilgang til det meste via hurtigmeny øverst. Vi har ikke noe meny på venstre eller høyre side. På høyre side har vi laget en sidebar hvor de nyeste events skal vises der, og i tillegg er det plass til sponsorer både på vestre og høyre side av websiden. 81

82 11. Språk Det er viktig å bruke et språk som enhver bruker kan forstå. Det er viktig å ikke bruke tekniske ord og uttrykk som kan fremme tvil og fort kan misforstås. Systemet er beregnet for folk/brukere med minimalt datakunnskap. Vi har valgt engelsk, og enhver som kan lese og skrive engelsk skal i utgangs punkt ikke ha noe problem med å benytte seg av systemet/websiden. Grunn til at vi valgte engelsk er at det ble nevnt av oppdragsgivere at det hender de får besøk av utenlandske trenere og utøvere. Derfor synes vi at det er greit det er en entydig webside mange andre enn de som kan norsk, kan benytte seg av. Websiden vil bli mer kjent på nettet når det er på engelsk. Optimalisering av websiden for søk på nettet er opp til oppdragsgivere. 82

83 12. Systemet i bruk av tilfeldige personer: Vi fikk to tilfeldige personer til å bruke noen minutter for å prøve å bruke systemet vårt. Det var lov å bruke brukermanual til systemet. Oppgavene er skrevet på forhånd: Person 1: Navn: Abdi. Avdeling: Sykepleier. Datakunskap: Gjennomsnitt. Oppgaver: Opprett et nytt bruker på systemet. Opprett et event. Meld deg på et event, og meld deg som frivilling på en vaktpost. Han så litt på brukermanualen, og satte i gang. Oppretting gikk greit. Oppretting av event gikk ikke så bra, som forventet. Da fikk han en relevant feilmelding. Før han kom frem til oppretting av event, måtte han se litt i brukemanualen litt. Han Klarte å melde seg på event, og han klarte å melde seg på vaktpost som frivilling. Person 2: Navn: Christin Yrke: VGS Student. Datakunskap: Grunnlegende. Oppgaver til Christin: Du er admin med brukernavnet Admin og passord Admin123, logg deg inn. List opp alle evets som finnes på systemet. Slett event som starter den Slett deg selv fra systemet. Si gjerne ifra hva som skjedde. Hun så rundt i brukermanualen, og logget seg inn som admin. Hun listet opp alle events. Hun brukte litt mer tid på å finne frem til eventet som starter Hun ble litt skuffet at hun ikke klarte å slette seg fra systemet. Etter å ha lest feilmeldingen skjønte hun meningen med at hun ikke kunne slette seg. Den siste admin skal nemlig ikke gå an å slette. Takk til Abdi og Christin som brukte noen minutter på å teste systemet vårt. 83

84 Brukermanual 84

85 Innhold Innlogging:...86 Registrering...87 Etter vellykket innlogging:...87 Oppretting av event:...88 Hvordan kan jeg melde meg på en event? Hvordan kan jeg delta som frivillig?...90 Hvordan kan jeg melde meg av en event?...91 Hvordan opprette post?...92 Hvordan publisere en artikkel på siden?...93 Drifting av websiden...95 Kilder...99 Bøker...99 Ressurssider fra nett

86 Bruker manual Innlogging: Når systemet er oppe og kjører, kan man trykke på sign in og brukeren får denne ruten. Her kan brukeren taste inn brukernavn og passord dersom vedkommende er eksisterende medlem. For øvrig har vi valgt at e-post skal være brukernavnet. Eksistrenede kunder kan be systemet om å lagre brukernavn og passord, slik at vedkommende slipper å taste det inn ved neste besøk. Det er mulig å få tilsendt brukernavn/passord for eksisterende kunder, dersom de har glemt det. Dersom man er ny og ikke er registrert, kan man registrere seg. Etter vellykket registrering er man en aktiv bruker. En bruker på systemet består av roller, komiteer, events og frivillige. 86

87 Registrering Deretter vil man få følgende skjermbilde: n. I dette skjemaet ovenfor er alle feltene på krevd, og skal fylles ut. Til venstre ser står hva som skal skrives inn, og inne i feltene er det blank tekst som en ekstra pekefinger på å gjøre brukeren obs på hva som skal stå inne der, og dermed forminke fare for feil inndata. Datofeltet skal fylles ut etter formatet dd.mm.yyyy. Når det gjelder kjønn, skal man krysse av enten for Male eller Female, altså Mann eller Kvinne. Når det gjelder feltet Zipcode, kan kun tall skrives inn der. Det samme gjelder feltet Phone også, men tallene i Phone feltet skal begynne med + tegn. feltet er sikret, og her skal kun en gyldig e-post adresse skrives inn, altså på følgende formatet: @domain.com. (eller.net,.gov osv). I feltet Password skal den kommende brukeren taste inn et selvvalgt passord. Alt som skrives inn i dette feltet, vil bli byttet med stjerner, grunnet sikkerhet. I feltet Confirm password skal det skrives nøyaktig det som ble skrevet i feltet Password. Deretter vil systemet sjekke om de to feltene er like. Dersom feltene er ulike vil brukeren få en relevant feilmelding, og blir bedt om å rette feilen. Det siste feltet brukeren må fylle ut, er en såkalt valideringstekst som er et bilde med tekst som genereres hver gang brukeren går på denne siden. Grunn til at dette er i bildeformat er at en del roboter kan lese vanlig tekst og dermed registrere seg som vanlig bruker som kan ha onde hensikter. Etter vellykket innlogging: Etter vellykket innlogging kommer brukeren til den siden vedkommende var på før innlogging. Når en bruker er logget inn, kommer brukerinfo på sidebar lengst til høyre. 87

88 En bruker har mulighet til å redigere profilen sin. Ved å holde musen over Logged in as, vil man få nede en profile, kan man se profilen sin/redigere den. Alle feltene er obligatoriske, og må fylles ut. Dersom man glemmer en eller flere felter, vil man få en relevant feilmelding, og brukeren blir bedt om å fylle ut det aktuelle feltet. Det siste feltet brukeren må fylle ut, er en såkalt valideringstekst som er et bilde med tekst som genereres hver gang brukeren går på denne siden. Grunn til at dette er i bildeformat er at en del roboter kan lese vanlig tekst og dermed registrere seg som vanlig bruker som kan ha onde hensikter. Dette er et sikkerhetstiltak som vi anser som nødvendig. Og det vil gjøre brukeren mer obs på hva som er skrevet inn. N Når en bruker holder musa over Logged in as <ditt brukernavn> vil man få informasjon som hvilken rolle vedkommende har, hvilke komiteer vedkommende er medlem av, om han/hun er admin, om han/hun er admin av noen komiteer samt deltakelse i frivillig arbeid. Oppretting av event: Det er kun administratorer som kan opprette en event. dersom det er en vanlig bruker som vil ha tilgang til denne siden, får vedkommende en relevant feilmelding. Event administrator kan legge til flere administratorer dersom det er ønskelig. Alle medlemmer kan se detaljer om en event, det er også mulig å melde seg på det. Administratorer kan opprette, slette, redigere og se informasjon om en event. Admin får tilgang til denne siden ved å klikke på Events på navigeringsmenyen. En event har gjerne detaljer som navn, type, beskrivelse, startdato, sluttdato, kapasitet, minimum aldersgrense. Vi har i tillegg ordnet med en oversiktskart. Kartet kommer til nytte når man oppretter en post på eventet. Da er det bare å markere på kartet hvor det skal ligge. nedenfor er et eksempel på hvordan en admin kan opprette kan opprette en event: 88

89 Feltene Name og Type er obligatoriske og skal fylles ut. Ved manglende data vil brukeren få en relevant feilmelding og blir bedt å fylle den/de aktuelle feltene. For Description har vi laget et tekstområde der og det er mulig å skrive en lengre beskrivelse av eventet. Her har man mange muligheter. Man kan endre på tekststørrelse og farge. En kan velge teksttype blant en del forskjellige teksttyper. Bakgrunn farge kan også endres. Det er mulighet for å legge inn linker. Man kan justere teksten på midtstilt, venstre- og høyrestilt. Det er også mulig å lage liste/punkter. For avanserte brukere har finnes det mulighet for kildevisning av det som er skrevet inn. Dersom brukeren er på kildevisning, kan det skrives inn html koder, og når vedkommende kommer tilbake til vanlig visning, vil alt av html kode bli tolket i nettleseren. Denne knappen ligger lengst til høyre i menyfeltet. Feltet Capacity er felt for maksimalt kapasitet for eventet. Systemet har kapasitet for uendelig mange deltakere for en event. Men i og med at systemet er tilrettelagt Tønsberg seilforening, er denne grensen satt ned til Men det kan endres etter ønske. Feltene Start date og Stop date er for start og sluttdato. En kan skrive inn dato manuelt etter dd.mm.yyyy formatet. For å forbedre brukeropplevelsen, er det lagt inn en kalender til høyre for de aktuelle feltene. Det er mulig å trykke på kalenderen og velge ønsket dato. Det er mulighet for å bla seg frem og tilbake både måneder og år. Vi har valgt å ikke ha validering på Start date. Det vil si at det er mulig å legge inn en event i fortid. Dette på grunn av at Tønsberg seilforening kan ha mulighet til å loggføre gamle event og digitalisere det. Det er ikke mulig å avslutte et event før den er startet. Forsøk på det vil føre til en veiledende feilmelding. 89

90 Feltet Minimum age brukes til å skrive inn aldersgrense på det aktuelle eventet. I tilfelle et medlem forsøker å melde seg på et event som har høyre aldersgrense enn alderen til vedkommende, vil en feilmelding bli vist på skjermen og vedkommende vil ikke få lov til å melde seg på eventet. Image feltet brukes til å laste opp oversiktskart. Dette gjøres ved å klikke på Choose a file. Etter det vil brukeren få et nytt vindu, der kan brukeren navigere seg til dit oversiktskartet ligger, velge det og trykke Upload. Etter vellykket opplasting vil oversiktskartnavnet stå i feltet, og default bilde vil endres til det nye oversiktskartet. Nederst i skjemaet finnes det tre forkjellige knapper som heter henholdsvis Save, Reset og Cancel. Ved å trykke på Save knapp, vil endringene lagres. Reset tømmer skjemaet og oversiktskartet vil forsvinne, i stedet vil default bilde komme opp igjen. Ved bruk av Cancel knapp sendes brukeren til Events. Hvordan kan jeg melde meg på en event? Hvordan kan jeg delta som frivillig? En bruker kan se alle events. Det gjøres ved å navigere seg til Events Show all. Her blir alle events listet opp, det nyeste kommer øverst. Det nyeste vil være synlig, med alle detaljer. De andre vil være skjult i et slags gardin, navnet vil være synlig. Dersom det klikkes på navnet, kommer resten av detaljene. Det skjules igjen ved å trykke på navnet på eventet. Brukeren kan melde seg på dersom det er ønskelig. Det gjøres ved å trykke på Attend this event knappen. Dersom brukeren trykker på Attend as volunteer melder brukeren seg på som en frivillig. Etter å ha trykket knappen får brukeren en bekreftelsesmelding som kommer øverst på siden, meldingen blir synlig i 15 sekunder, etter det forsvinner den. Denne bekreftelsesmeldingen ser slikt ut: 90

91 Hvordan kan jeg melde meg av en event? En bruker som har meld seg på et event, kan melde seg av. Det gjøres ved å holde musen over Logged in as <brukernavn> og trykke på My events. Her vil det komme en side som viser alle events brukeren deltar i. Da er det bare å finne frem til eventet brukeren vil melde seg av og trykke på Remove yourself from this eventknappen. Skjermbilde nedenfor viser hvordan brukeren kan melde seg av eventet. Det som er sirklet i rødt viser hvor mange som har meldt seg på eventet. Det tallet vil variere avhengig av hvor mange som melder seg av/på? Når Remove yourself from this event-knappen er trukket, avmelding som frivillig gjøres på samme måte, men i stedet trykkes knappen Remove yourself as volunteer. Vil man få en melding som bekrefter avmeldingen, denne meldingen kommer øverst på skjermen og vil være synlig i 15 sekunder, etter det forsvinner meldingen og brukeren er avmeldt fra eventet. Det er mulig å melde seg på et event selv om brukeren har meldt seg av det samme eventet før. Men påmelding må skje før eventet starter, og det må være ledig kapasitet. Dersom de to kravene ikke er oppfylt, vil det ikke være mulig å melde seg på. Da kommer en relevant feilmelding. 91

92 Hvordan opprette post? Det er kun administrator som kan opprette en post. En post skal selvsagt opprettes til en event som eksisterer. brukeren til en side som ser slikt ut: Denne siden viser event navn, kapasitet, antall poster som er lagt for eventet, start og stoppdato, hvem som er administrator(er). I tillegg er det mulig å redigere, se eventdetaljer, opprette ny post og slette eventet. Dersom det er flere events som er opprettet vil de også bli listet. Ved å klikke på Create new post får brukeren mulighet til å opprette en ny post for det eventuelle eventet. Følgende skjemaet vil bli vist I skjemaet ovenfor er alle feltene påkrevd. Oversiktskartet (i dette tilfelle pingvinbilde) kommer automatisk opp. Kartet vil være det samme som det tilhørende event kartet. Her skal det bare markeres hvor på kartet posten skal være. Det er bare å holde musen inne og dra. Etter det er det bare å trykke Save. Posten vil bli lagret. 92

93 Hvordan publisere en artikkel på siden? Systemet er tilrettelagt for publisering av artikler. Det er brukere med adminrolle som kan publisere slike artikler. Ved å holde musa over Article på utvidbarmenyen kan man klikke på Create new. Da får man en side som ser ut som skjermbilde nedenfor: Skjemaet har felter som Title, Header, Main, Footer. De representerer henholdsvis tittel, overskrift, hovedteksten og bunntekst. Alle de feltene er påkrevd og skal fylles. Ved mangel vil brukeren få en feilmelding. Videre inneholder artikkelen to ruter, den ene heter Available, og den andre heter Selected. Altså kategorier som er tilgjengelig og de som er valgt for å publisere artikkelen. En artikkel kan publiseres på så mange kategorier som admin bare vil. Det er bare å dobbelklikke kategorien vedkommende vil publisere artikkel på, da vil den kategorien flyttes til Selected (Valgt). Alternativ kan man bruke dra og slipp teknikken. Det er mulig å markere flere kategorier og dra til høyre, da vil artikkelen automatisk bli publisert på de valgte kategoriene. Det er også mulig å laste opp et bilde per artikkel. Man kan klikke Choose a file, og deretter navigere seg dit ønsket bilde ligger, og laste det opp. Brukeren vil få forhåndsvisning av bilde, dersom vedkommende vil ha et annet bilde, er det fult mulig. Navnet av det valgte bilde vil da komme inni feltet Image. Bilde er ikke obligatorisk å laste opp. En artikkel kan fint publiseres uten bilde. 93

94 nest nederst er det et felt som heter Picturetext, altså bildetekst. Her skal bildeteksten stå. Dette feltet skal KUN fylles dersom et bilde er valgt på forhånd. Teksten fra dette feltet vil nemlig komme under bilde når artikkelen er publisert. Det er derfor også viktig at teksten fra dette feltet forklarer bilde. Den aller siste knappen på dette skjemaet ligger nederst til høyre og heter Save. Ved å trykke denne knappen vil artikkelen bli publisert. Dersom feltene ikke er riktig fylt, vil det komme en forklarende feilmelding, og brukeren vil bli bedt om å rette opp feilen(e). 94

95 Drifting av websiden Med denne hosting her har vi ubegrenset med plass og båndbredde e-post kontoer er også inkludert dersom dere ønsker å ta i bruk. Vil dere ønske å ha flere eller ubegrenset med e-post kontoer, kan vi prøve å komme i dialog med Ipower slik at vi får utvidet avtale med ekstra e-post kontoer med pristillegg. Denne pakken inneholder alle nødvendig verktøy for drift og statistikk av siden. Det er også muligheter for integrasjoner av nettbutikk. Inkludert i denne pakken er det også markedsføringsverktøy som for eksempel Yahoo! Search Marketing og Google AdWords TM Her er oversikten over hva som er inkludert i pakken: BASIC FEATURES Disk Space Bandwidth Unlimited Unlimited Your-Name.com (Free, Personalized Domain Name) International Domain Name Support Domains Allowed 25 POP3 Accounts: Supports Outlook, Thunderbird, etc Forwarding Accounts & Autoresponders 1000 Browser-based (WebMail) Website Creator Site Builder by CM4all CGI-BIN, PHP 4 & 5 Support Perl Support MySQL Databases 5 Server Side Includes FrontPage 2003 Extensions Website Statistics (AWStats) Web Hosting Control Panel (vdeck 3.0) Guest Book: GBook Bulletin Board: phpbb 95

96 Blogging Software: WordPress Active Server Pages (ASP) Support ASP.NET 2.0/3.0 with AJAX ODBC Support for Access Databases SSL Secure Server Password-protected Directories Real Audio & Video Macromedia Shockwave MIDI File Support Customizable MIME Types 100% Wind Powered High Performance Dell PowerEdge Servers Microsoft IIS 6 Web Server Software Multiple Gigabit & Fiberoptic on Diverse Backbones NetApp Snapshot Data Backups Cisco Routers Using BGP4 Protocol UPS Power Backup 24/7 Network Monitoring MARKETING TOOLS $25 Yahoo! Search Marketing Credit $50 Google AdWords Credit Google Webmaster Tools PRICE PER PACKAGE Google Custom Search Engine 3-Month Price + $30 Setup $ Month Price + $30 Setup $

97 12-Month Price (Free Setup) + Free Domain $ Month Price (Free Setup) + Free Domain $6.95 SMS-Varsling: Et av ønskene fra Tønsberg Seilforening var SMS varsling. Vi har undersøkt tre forkjellige leverandører som leverer denne tjenesten. Leverandørene vi undersøkte var sorenso.no, PSWinCom Intouch, og Sveve.no. Vi valgte Sveve.no på grunn av at denne tjenesten dekker behovene samt ønskene Tønsberg seilforening har. Og den er billigst blant kandidatene. SveveVarsling har en funksjonalitet hvor man kan sende SMS/MMS fra PC/Mac. Man kan planlegge utsendelse på planlagt dat/tidspunkt, og man kan sende til enkelt person og grupper. Det er mulig å lage så mange grupper man vil. Ofte brukte meldinger kan lagres. Import mulighet fra Excel er tilstede. Man kan velge avsender navn/nummer selv, for eksempel TBS Event/2010. Svar på meldinger fra brukere kan vises direkte på skjermen om ønskelig. Det viktigste i forbindelse med denne pakken er at det er muligheter for API /integrasjon, noe som gjør at dette lar seg implementere direkte i deres løsning. I Tønsberg seilforening er det vanlig at en del vakter blir byttet, gjerne av både bruker og administrator. I denne forbindelsen kan Svevevarsling være en effektiv måte å varsle de involverte at en endring har funnet sted. Priser og betingelser: 97