HOVEDPROSJEKT. SAMMENDRAG Dette er slutt dokumentasjonen til hovedprosjektet for gruppe 17 ved Høgskolen i Oslo våren 2011

Transkript

1

2 PROSJEKT NR. 17 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT TILGJENGELIGHET ÅPEN Telefon: Telefaks: DOOA.NO - Ny nettløsning for dyrebeskyttelsen ANTALL SIDER / BILAG Eivind Steen s Håvard Schanke s Kristoffer Hals s Marius W Nilsen s INTERN VEILEDER Norun Christine Sanderson OPPDRAGSGIVER Dyrebeskyttelsen Norge avd. Oslo og Akershus KONTAKTPERSON Hege Johansen SAMMENDRAG Dette er slutt dokumentasjonen til hovedprosjektet for gruppe 17 ved Høgskolen i Oslo våren 2011 Rapporten inneholder 4 deler, en prosessdokumentasjon, en produktdokumentasjon, en brukerveiledning og vedlegg. Produktet er utvikletet i rammeverket ASP.NET STIKKORD Web programmering Microsoft ASP.NET Nettsted 1

3 Hovedinnholdsfortegnelse Prosessdokumentasjon 3 Produktdokumentasjon..27 Brukerveiledning.65 Vedlegg..88 2

4 Prosessdokumentasjon 3

5 3. Forord I desember 2010 kontaktet vi vår fremtidige veileder som hadde et potensielt hovedprosjekt. Oppdragsgiveren var Dyrebeskyttelsens lokalavdeling for Oslo og Akershus (DOOA). Hensikten med vårt prosjekt har vært å utvikle et nytt nettsted som på en enkel måte kan administreres av organisasjonenes medlemmer, uten behov for programmeringskunnskaper. Denne rapporten er i hovedsak ment for vår veileder, sensor og oppdragsgiver. Her vil vi gjøre rede for hvordan vi kom frem til våre valg. Hvorfor vi gjorde som vi valgte, og hvorfor vi valgte som vi gjorde. Det vil i denne rapporten gjort rede for de krav som står i vår kravspesifikasjon. Det kreves ingen spesiell teknisk kompetanse for å lese rapporten. Rapporten er optimalisert for papirutgaven. Vi ønsker å rette en takk til Dyrebeskyttelsens lokalavdeling for Oslo og Akershus ved Hege Johansen, og Norun Christine Sanderson, vår internveileder på oppgaven.i tillegg ønsker vi å rette en takk til Tor Krattebøl for disposisjon av server. 4

6 4. INNHOLDSFORTEGENLSE STUDIEPROGRAM:... 1 HOVEDPROSJEKT FORORD INNHOLDSFORTEGENLSE INNLEDNING OM GRUPPEN TILDELING AV OPPGAVE OM VEILEDER OM DOOA DAGENS SITUASJON PROSJEKTETS MÅL RAMMEBETINGELSER PLANLEGNING ANALYSE Konklusjon VERKTØY Microsoft Visual Studio Team Foundation Server Notepad Putty MySQL Workbench Scrumy Dropbox MediaFire Photoshop YayMicro UTVIKLINGSMETODE Scrum UTVIKLINGSPROSESS FASER Oppstartsfasen Kravspesifikasjonen Fremdriftsplan Team Foundation Server Paypal Design Utviklingsstandard Utviklingsfasen Sprintplanlegning Scrum tavle Gjennomføring av sprintene Avslutningsfasen UTFORDRINGER PayPal VIKTIGE VALG

7 7.3.1 Parprogrammering Tester CKEditor PGRFilemanager PayPal KRAVSPESIFIKASJONEN ENDRINGER BETYDNING SAMSVAR Avvik AVSLUTNING MULIGE UTVIDELSER KONKLUSJON KILDER

8 5. Innledning "Creativity is knowing how to hide your sources." - Albert Einstein 7

9 5.1 Om gruppen Gruppen består av fire dataingeniørstudenter ved Høgskolen i Oslo (HiO): Kristoffer Hals Marius W Nilsen Eivind Steen Håvard Schanke Gruppens medlemmer var bestemt en tid før prosjektet var i gang. Vi var alle enige om at vi ønsket en utviklingsoppgave, og et mål vi har hatt for prosjektet er at vårt produkt skal komme til nytte for vår oppdragsgiver. 5.2 Søkeprosess Mot slutten av september 2010, sendte vi våre første oppgavesøknader til bedrifter vi ønsket å samarbeide med på hovedprosjektet. Søknader ble sendt til BEKK, Accenture, Opera, Microsoft og Tandberg/Cisco, men ingen hadde noen oppgaver tilgjengelige som passet våre ønsker. Vi kom etterhvert i dialog med Norun - veileder for et prosjekt høgskolen hadde for DOOA. Dette var en webutviklingsoppgave, hvor vi stod fritt til å velge teknologier selv. Det var derfor mitt i blinken for oss. 5.3 Tildeling av oppgave Vi var så heldige og få tildelt oppdraget fra DOOA etter en søke og intervjuprosess. Oppgaven inneholdt allerede en liten kravspesifikasjon, men i det første møtet med vår veileder gikk det klart frem at vi sto ganske fritt til å komme med forslag og diskutere krav. 5.4 Om veileder Vår veileder på hovedprosjektet var Norun-Christine Sanderson. Siden Norun var veileder for prosjektet til DOOA, ble hun også satt til å være vår internveileder. 5.5 Om DOOA Dyrebeskyttelsen Norge avd. Oslo og Akershus (DOOA) er Norges største lokalforening tilknyttet paraplyorganisasjonen Dyrebeskyttelsen Norge. DOOA arbeider ut fra ideen om at dyr skal vises respekt, medfølelse og toleranse, samt at dyr har en egenverdi på lik linje med mennesket. DOOA har ingen ansatte og alt arbeid utføres på frivillig basis av de aktive medlemmene. 5.6 Dagens situasjon DOOA har i dag en hjemmeside som ikke dekker de behov organisasjonen krever. Hjemmesiden er uoversiktlig og meget tung å drifte. Siden driftes av flere personer, gjerne personer uten spesielle datakunnskaper, og er derfor rotete, usammenhengende og vanskelig å oppdatere. Sidens funksjonalitet er heller ikke tilstrekkende. Dagens nettbutikkløsning er ufullstendig, butikken krever ingen brukervalidering og hvem som helst kan bestille til hvem som helst. Butikken har heller ikke den velkjente handlekurven, og viser for tiden en melding om at bestillingsskjema er ute av drift. Siden overholder heller ikke den visuelle standarden dyrebeskyttelsen Norge har satt for sine lokalavdelinger. Det er en del praktisk informasjon på siden angående DOOAs arbeid, men informasjonen er i enkelte tilfeller vanskelig å finne. Siden inneholder også en del visuelle feil, som 8

10 gir et uprofesjonelt inntrykk. Lokalavdelingens styre ønsker seg derfor nye websider som kan bidra til at flere melder seg inn og bidrar økonomisk, eller på andre måter støtte deres frivillige arbeid. 5.7 Prosjektets mål Vår oppgave er å utvikle et nytt nettsted med et friskere og mer oversiktlig design. På grunn av at nettsiden driftes og vedlikeholdes av flere av organisasjonens medlemmer ønsker de seg et system som gjør det enklere å administrere sidens innhold. Siden organisasjonen er frivillig og er sterkt avhengig av donasjoner og massiv medlemsstøtte skal vi prøve å gjøre det mer fristende for potensielle medlemmer og bidragsytere. Det vil stilles store krav til brukervennlighet av administrasjonsdelen i systemet. Systemet skal på mange måter være selvforklarende. Opplæring i bruk av systemet vil bli gitt de ansvarlige i DOOA. Siden skal inneholde: - Nettbutikk med handlekurvfunksjon. - Enkel administrasjon av dyreregister - Enkel administrasjon av sidens innhold og nyhetsoppdatering. For en fullstendig oversikt over sidens krav henviser vi til kravspesifikasjonen. 5.8 Rammebetingelser Vi sto relativt fritt til å velge utviklingsplattform siden DOOA var villige til å flytte sitt nettsted til et annet webhotell hvis det viste seg nødvendig. Vi falt uten mye diskusjon ned på Microsoft sin.net plattform. Alle i gruppen har erfaring med teknologien fra før og er komfortabel med utviklingsverktøyet Microsoft Visual Studio

11 6. Planlegning Planning is bringing the future into the present so that you can do something about it now. Alan Lakein 10

12 6.1 Analyse Vi arrangerte tidlig et møte med DOOA s representant og hadde på forhånd sendt dem en detaljert kravspesifikasjon med forslag og potensielle løsninger vi kunne tenke oss. Sammen kom vi frem til en kravspesifikasjon vi begge var fornøyd med. Det var viktig for oss å fastsette så tidlig som mulig hvilke problemer og oppgaver vi sto ovenfor. Siden vi hadde bestemt oss for å utvikle i.net var vi så heldige å få tilgang til en Team Foundation Server gjennom høgskolen. (Versjonskontroll) Denne serveren har vært viktig fordi den gjør at vi sammen kan programmere på den samme løsningen og samtidig ha kontroll på de forskjellige versjonene i utviklingsprosessen. Vi hadde liten erfaring med denne typen utviklingsserver fra før, så det gikk litt tid før vi ble dus med de rutiner og hensyn som må terpes på for å få det til å gå knirkefritt. Et sterkt ønske fra oppdragsgiver var nettbutikk med sikker betaling på nettet. Ingen hadde noe erfaring med dette fra før og vi måtte sammen sette oss inn i de mulighetene vi hadde. Vi diskuterte og leste oss gjennom alternativ som Bank ID, men det stilte en del krav som vi ikke kunne oppfylle. Blant annet en avtale med banken og egen server. Dessuten virket implementasjonen vanskelig og tung. Valget falt derfor naturlig på PayPal. Det virket enkelt å implementere, og det krever heller ingen drift etter at det er konfigurert. PayPal er også en kjent aktør innenfor netthandel og virker sikker, samt at mange brukere har erfaring med, og assosierer PayPal logoen med trygg betaling på nett. CKeditor var en annen teknologi vi fort falt ned på. Denne editoren gir administratorer av systemet mulighet til å oppdatere sidens tekst og innhold uten at det krever erfaring med HTML eller noen annen form for webdesign. Editoren er lettvint å bruke for personer med erfaring fra dokumentverktøy som for eksempel Microsoft Word eller Open Office. Vi skjønte fort at systemet kom til å basere seg på en relativt stor database i bunn. Siden vi utviklet i.net valgte vi MS SQL Vi hadde da to forskjellige måter å kommunisere med databasen på.(ado.net og LINQ SQL.) Vi hadde erfaring med begge fra før, og hadde egentlig ikke noen argumenter hverken for eller mot noen. Etter å ha lest oss litt opp og hørt med vår gamle foreleser i faget endte vi opp med LINQ SQL. Det virker enklere og noe mer moderne. Et viktig argument for oss var at LINQ var enklere i behandling av objekter. Noe det kom til å være mye av i vårt system. Det var særdeles viktig for oss før utviklingen startet at vi hadde så god oversikt over vårt fremtidige system som over hode mulig. Vi tegnet ned ER modeller og logisk skjema for databasen, og objekt modell. Vi var i god tro om at disse modellene var fullstendige og nøyaktige, men som seg hør og bør viste det seg at vi både måtte trekke fra og legge til nytt underveis. Etter at systemstruktur og funksjonalitet var gjennomdiskutert satte vi oss ned og lagde utkast til design. Det tok ikke lange tiden før et forslag var utformet og vi var selv svært fornøyd og fikk gode tilbakemeldinger fra vår oppdragsgiver Konklusjon Hvis vi ser kun på kravene i analysen ser man at vi godt kunne valgt andre teknologier for å løse de oppgavene som stod fremfor oss, men grunnet oppgavens størrelse og omfang, 11

13 valgte vi teknologier vi var kjent med fra før av. Slik behøvde vi ikke å lære oss nye teknologier, men kunne fokusere på å levere et komplett produkt Verktøy Microsoft Visual Studio 2010 Microsoft Visual Studio 2010 er et utviklingsverktøy fra Microsoft med støtte for.net Framework. Valget falt naturlig på denne, da alle prosjektets deltakere hadde erfaring med dette utviklingsverktøyet Team Foundation Server Team Foundation Server (TFS) er et Microsoft produkt som tilbyr versjonskontroll. TFS gjør at vi sammen kan programmere på den samme løsningen og samtidig ha kontroll på de forskjellige versjonene i utviklingsprosessen Notepad++ Notepad++ er et tekstbehandlingsverktøy som tilbyr kildekode-markeringsspråk Putty Putty er en kommando skjell emulator som lar deg koble til klienter via SSH. Putty ble brukt til å koble til en server på skolen med støtte for PHP, for å kunne teste enkelte funksjoner MySQL Workbench MySQL Workbench er et verktøy som lar deg visuelt designe databaser Scrumy Scrumy.com er en nettside som tilbyr en online scrum tavle. Ble brukt i sammenheng med utviklingsmetoden Scrum Dropbox Dropbox tilbyr gratis online lagring av filer. Ble brukt som backup utover TFS MediaFire MediaFire er en gratis fil og bilde tjeneste på nett. Som ble brukt til å distribuere dokumenter og bilder innad i gruppen Photoshop Photoshop er et bildebehandlingsverktøy fra Adobe. Ble benyttet til å designe utkast til utseende på produktet YayMicro YayMicro er en nettjeneste som tilbyr kjøp av illustrasjoner og bilder. Via kontakter i DOOA fikk vi tilbudt en del gratis bilder herfra. 6.3 Utviklingsmetode Vi var alle enige om at vi ønsket å benytte oss av en smidig utviklingsmetode i prosjektet. Vi hadde lært om denne metoden i et av fagene på HiO og hørt at de ble brukt mye i arbeidslivet. Siden vi aldri hadde benyttet oss av en smidig utviklingsmetode i et større prosjekt før, valgte vi å gjøre det nå. Vi valgte å bruke utviklingsrammeverket scrum. 12

14 6.3.1 Scrum Scrum er et smidig utviklingsrammeverk som definerer forskjellige roller, og hvordan man kan bruke smidig utvikling til å jobbe på en god måte. Definisjonene i scrum bør sees på som retningslinjer for hvordan et smidig prosjekt kan utføres. Det kan være et krevende rammeverk og benytte, da det krever et tett samarbeid med arbeidsgiver. 13

15 7. Utviklingsprosess The function of good software is to make the complex appear to be simple. - Grady Booch 14

16 7.1 Faser Oppstartsfasen Kravspesifikasjonen Nå som oppgaven og teknologiene var bestemt kunne vi starte med å fastsette kravspesifikasjonen. Oppdragsgivers krav var satt, men disse kravene var ganske brede, så vi startet med å bryte opp disse til mindre og mer spesifikke krav. Vi hadde tidligere sett at andre grupper benyttet seg av brukerhistorier med stor suksess, så vi ønsket å prøve dette vi også. En brukerhistorie er en handling av en bruker som skal føre til et resultat i applikasjonen. (Figur 1 Brukerhistorie) Det ble valgt og ikke basere seg fullt på brukerhistorier, men å benytte dem som et supplement til kravspesifikasjonen Fremdriftsplan Det var viktig å ha en overordnet fremdriftsplan, både for oss og for veileder, slik at vi hele tiden viste hvordan vi lå ann i prosjektet. (Figur 2 Fremdriftsplan) På denne måten kunne vi også gjøre endringer underveis i prosjektet slik at vi kunne komme i mål. Dette er en av styrkene ved å bruke Scrum. Et prinsipp med Scrum er at man skal ha fungerende produkter etter hver sprint, men vi valgte og bare ha dellevereanser etter hver andre sprint Team Foundation Server Vi hadde allerede fått klarering på at vi kunne bruke HiO s TFS, så vi fikk sjekket at alle gruppens medlemmer hadde de nødvendige rettighetene som behøvdes for å 15

17 kunne lese og skrive filer fra TFS. Etter at alle hadde de nødvendige rettighetene gikk vi igjennom hvordan man brukte TFS og lagde rutiner for dette Paypal Siden igjen av oss før hadde implementert PayPal i et system startet vi med å lese litt på dokumentasjonen tilgjengelig på PayPal sine hjemmesider, samtidig som vi testet det ut på helt enkle HTML-sider. Det viste seg at PayPal tilbøy flere måter å implementere deres funksjoner på. De har blant annet sitt eget API, men her følte vi at dokumentasjonen var utilstrekkelig. En annen måte å sende informasjon til PayPal på var igjennom html forms, dette virket veldig enkelt å implementere så valget falt på sistnevnte måte (Det skulle senere vise seg at dette valget bø på et annet problem vi ikke forutså på dette tidspunktet, forklart nærmere i avsnitt 7.2.1) Design Vi ønsket å designe en nettside som kunne formidle at dette var en seriøs dyrevernorganisasjon og at brukere på siden lett kunne finne ut hva slags nettsted de var kommet til. Samtidig ønsket vi å begrense informasjonen og holde forsiden ryddig og oversiktlig. Vi fikk tilsendt en profilhåndbok utstedt av Dyrebeskyttelsen, som dikterte logo bruk, farge valg og teksttyper. Dette begrenset våre valg noe, men samtidig slapp vi å ta stilling til nettopp disse tingene. Vi fikk en link av vår veileder til et nettsted av Jakob Nielsens webside om brukervennlighet på nett. Vi leste igjennom en del av hans artikler, og hadde dette i bakhodet mens vi designet. Dette førte blant annet til Jeg ønsker og: linjen. Ideen bak denne var å gi brukere enkle veier til de stedene som generte penger for DOOA, og at det skulle være lett for brukere å finne frem til hovedfunksjonene til nettsiden. Som man ser er denne linjen et supplement til den tradisjonelle menylinjen Utviklingsstandard Vi hadde tidligere erfart at variabelnavn måtte være selvforklarende, selv når man jobbet på en oppgave alene. Ekstra viktig var det for oss nå, da vi jobbet sammen om en løsning og når andre deltakere skulle benytte seg av våre metoder. Dette gjelder også når andre skal videreutvikle eller lese koden vi skriver. Derfor var vi veldig nøye på at vi skulle alltid gi variabler og metoder selvforklarende navn, uten unntak. Vi valgte å bygge opp nettløsningen etter en kjent lagdelingsstandard som er mye brukt på store.net systemer i næringslivet og i profesjonelle utviklingsmiljøer (se figur.3 - lagdeling) 16

18 (Figur 3 - lagdeling) DAL - Behandler alle forespørsler til og fra databasen. LINQ to SQL - Er et auto generert lag som oversetter informasjonen mellom DAL og DB. BLL - Behandler data. Laget sørger for sikkerhet og tester mesteparten av dataen som blir sendt igjennom. Presentasjonslaget - Inneholder HTML, CSS og alle aspx filer, samt tilhørende C#- kode. I tillegg valgte vi her å ha en logisk mappestruktur som skilte de forskjellige filene. (se Figur 4 - Mappestruktur) Model- inneholder alle klasse-objektene, det er tomme klasser som bare inneholder attributtene til objektet. Det er en speiling av mange av tabellene i databasen. (Figur 3 - Mappestruktur) Lagdeling er viktig i store systemer fordi det opprettholder en orden. Mange utviklere kan jobbe med forskjellige deler av systemet i forskjellige lag. Det fører igjen til at klasser og objekter får høy kohesjon. Samtidig er det enklere for 17

19 programmerere som kommer etter oss og sette seg inn i koden og strukturen som er valgt Utviklingsfasen Da vi var ferdig med oppstartsfasen begynte vi å programmere applikasjonen vår den 3. februar. Vi hadde valgt å bruke scrum og fulgte derfor et fast mønster for hver iterasjon i utviklingsfasen Sprintplanlegning I starten av hver sprint hadde vi et møte hvor vi bestemte hva vi skulle gjennomføre i løpet av sprinten. Det ble da valgt oppgaver fra kravspesifikasjonen, støttet av brukerhistoriene der de fantes, som skulle fullføres i løpet av sprinten. Vi opplevde det som vanskelig å beregne hvor lang tid hver oppgave faktisk ville ta så vi bestemte oss for å begynne med de kravene oppdragsgiver mente var viktigst. Dette medførte at ved sprintslutt så hadde vi ikke alltid ferdig de funksjonene vi sa ved starten av sprinten. Dette var et kompromiss vi valgte å fortsette med, da vi har opplevd at oppgaver ofte tar lenger tid en først planlagt. Vi følte også at ved å gjøre det på denne måten, sikret vi oss at ingen vesentlige funksjoner ikke rakk å bli ferdigstilt før leveranse Scrum tavle Ved enden av hvert sprintplanlegningsmøte når vi hadde valgt oss oppgaver som skulle gjennomføres, ble disse ført opp på den digitale scrum-veggen, scrumy.com. Tavlen var et viktig hjelpemiddel for oss i utviklingsfasen. Ved hjelp av tavlen, kunne prosjektets deltakere alltid se hvilke oppgaver som gjenstod i sprinten, og kunne lett finne hva som fortsatt måtte gjøres Gjennomføring av sprintene Det ble hold morgenmøte hver morgen, før arbeidet startet for dagen. På morgenmøte snakket vi om hva vi hadde gjort dagen før, og hva vi hadde planer om å gjøre i løpet av dagen. Vi følte dette var en god måte å ha oversikt over hva hver enkelt gjorde og hvordan de lå ann. Etter morgenmøte ble det enten fortsatt med å ferdigstilte valgte oppgaver, eller så ble det valgt en ny oppgave fra Scrum tavlen. Siden vi hadde valgt og ikke benytte os av par-programmering, valgte alle seg en oppgave hver. Dette gjorde vi for å forsøke å rekke alle punktene i kravspesifikasjonen, men det medførte at det ikke ville bli skrevet enhetstester til mange av funksjonene våre. Derfor måtte vi sørge for å teste funksjonene våre etter endt sprint. Vi gjennomførte dette ved å la de andre på gruppen gjøre brukertester, og der det var mulig fikk vi utenforstående til å teste Avslutningsfasen Prosjektets avsluttende del består i hovedsak av dokumentasjon. Selv om vi har prøvd å være nøye med å dokumentere hele prosessen etterhvert som vi har fullført har det for det meste blitt rablet ned i stikkordsform. Avslutningen består nå i å skrive mer kjøtt på beinet. Litt småplukk er også oppdaget på utviklingssiden ettersom vi har hatt systemet ute til bruk for venner og bekjente. 18

20 7.2 Utfordringer PayPal Som nevnt tidligere valgt vi og ikke benytte oss av PayPal s API, men isteden gå for den enklere metoden med å sende informasjon til PayPal via html forms. Problemet var at i.net må alle serverkontroller plasseres i en <form> tag, denne tagen må også inneholde attributtene: runat= server. <form runat="server">...html + server controls </form> (Figur 3 form i. NET, Det som da skjer, er at formen alltid blir sendt til seg selv. Med andre ord betyr det at man ikke kan sende informasjon til PayPal via html forms, fordi informasjonen i PayPal-formen aldri blir sendt til PayPal. Løsningen her ble å lage en.net side som ikke inneholder <form runat= server > tagen. Ved å fjerne denne tagen fra en side kunne vi heller ikke bruke noen kontroller, siden websiden ikke vil bli tolket av serveren. Ved å gjøre dette oppstod det et nytt problem: Hvordan skal vi sende riktig verdier til PayPal? Etter litt leting på Microsoft sine sider kom vi frem til at vi kan bruke en metode som heter Response.Write og skrive informasjon til PayPal formen uten at vi behøvde å ha innholdet i en <form runat= server > tag.. ( I paypal.aspx lagde vi ett skjema som automatisk ble postet, og på denne måten kunne vi bestemme hvilke verdier vi ville sende til PayPal CSS Da vi først satte i gang med å konvertere designet til HTML og CSS brukte vi Google Chrome for å se hvordan denne nettleseren visuelt oversatte koden vi skrev. Da vi hadde fått Google Chrome til å oversette koden til å bli vist på den måten vi ønsket, testet vi flere nettlesere for å se hvordan de oversatte koden. Vi viste utfallet før vi sjekket: Opera, FireFox og Safari oversatte innholdet slik som forventet, på samme måte som Chrome, mens Internett Explorer oversatte annerledes*. Blant annet fordi enkelte CSS3 elementer ikke tolkes i Internett Explorer (Microsoft.com: CSS Compatibility and Internet Explorer - Med en markedsandel i underkant av 25 % (W3schools.com: Web Statistics and Trends - 19

21 var det viktig at også Internett Explorer kunne oversette innholdet slik vi ønsket. For å løse dette brukte vi betingede kommentarer(microsoft.com: Conditional Comments - Betingede kommentarer lot oss bestemme at Internett Explorer skulle lese fra en annen CSS-fil en de andre nettleserne. Koden ble testet på de tre foregående versjonene av IE og virket tilfredsstillende på den nyeste versjonen (IE 9), men hadde noen visuelle mangler på de foregående. (IE 8 og IE 7). Som et overordnet valg har vi valgt at sidene våre ikke skalerer, men er satt til en fast størrelse. Websiden vises best i vinduer med minimum 1000 piksler. Denne størrelsen og måten og designe på kan man finne igjen på flere kjente nettsider, blant annet facebook og vg.no CKEditor Når vi først satte i gang med CKEditor, virket det som en problemfri editor som var forholdsvis enkel å implementere på siden vår. Teksten kunne endres og styles mer eller mindre akkurat sånn som vi hadde sett for oss at det skulle. Problemet derimot, kom da vi skulle legge til et bilde sammen med f.eks. en artikkel, og dette skyldtes at den nåværende editoren ikke hadde en integrert bilde opplastning. Vi valgte derfor en midlertidig løsning, som ble å bruke den allerede eksisterende opplastningsfunksjonen i asp.net. Dette fungerte helt greit, men vi var mildt sagt misfornøyde med utseende av dette, og var veldig interessert i å få til opplastningen via selve editoren. Etter mange søk fant vi en løsning, som gikk ut på å bruke et annet opplastningsverktøy som het PGRFileManager, men her møtte vi også det neste problemet med opplastningen, som var at vi ble avhengig av å ha PHP også, noe som ikke var tilgjengelig på dotnet serveren fra skolen. Dette gjorde at vi da måtte finne et annet web-hotell som kunne tilby både IIS og PHP for å få alt til å fungere nøyaktig slik vi ville mens vi utviklet Sende auto generert mail Vi har basert systemet vårt på at mye av kommunikasjonen med brukeren foregår gjennom standardiserte epostmeldinger. I starten bød ikke dette på problemer og funksjonaliteten ble implementert tidlig i prosjektet. Etter en tid fant vi ut at SMTP serveren (smtp.servetheworld.net) vi benyttet oss av blokkerte informasjonen vi ville sende igjennom. Dette førte til at vi måtte opprette en ny konto hos gmail og benytte oss av deres SMTP servere. Dette har hittil fungert knirkefritt Oppgavens størrelse Vi stod ganske fritt til å bestemme oppgavens størrelse selv, så lenge oppdragsgivers krav ble gjennomført. Vi ønsket virkelig at vårt produkt skulle bli tatt i bruk etter leveranse, så kravspesifikasjonen vår ble ganske lang. Det var mange ting som måtte på plass for at vi skulle kunne levere ett produkt som vi kunne være fornøyd det. Alt i alt førte dette til stor kravspesifikasjon som var ryggraden i vår utviklingsprosess. 20

22 7.3 Viktige valg Parprogrammering Vi valgte og ikke bruke parprogrammering i vårt prosjekt. Vi valgte dette fordi oppgavens størrelse var såpass stor at vi trengte at alle deltakerne kunne bidra med ny funksjonalitet hele tiden. Dette valget medførte at vi måtte være nøye på og overholde kodestandarden vi hadde satt, slik at vi kunne bruke de andres koder uten å ha behov for å lese igjennom koden deres på forhånd Tester Testingen ble utført i flere steg. Først ble koden testet av utvikleren selv, for deretter å bli sendt videre til de andre i gruppen for videre testing. Eksterne testere ble hentet inn for å utelukke feil/mangler vi selv hadde oversett CKEditor Vi hadde behov for en WYSIWYG tekst og HTML tekstbehandler for web*. Valget falt på CKEditor, en gratis tekstbehandler som henter mange kjente ikoner og funksjonaliteter fra mer kjente tekstbehandlingsverktøy som Microsoft Word og Open Office. Det fantes en versjon som var kompatibel med.net rammeverket, og ved å bruke denne kunne vi sørge for at brukere av produktet uten kjennskap til HTML, kunne formatere og redigere artikler på en vanlig måte. *What You See Is What You Get er et prinsipp i tekstbehandlingsprogramvare og i sideombrekkingsprogrammer (også i HTML-editorer): Det du ser på skjermen når du skriver inn teksten, ser likedan ut som på utskriften. I tekstbehandlingsprogram uten WYSIWYG ser man teksten i en enklere form på skjermen, mens den endelige formateringen først kommer til syne på utskriften.( PGRFilemanager For å kunne få full nytte av CKEditor, hadde vi behov for en måte å sette inn bilder i teksten på. PGRFilemanager er en plugin som kan implementeres i CKEditor. Eneste baksiden ved denne var at det krevde en server med støtte for PHP. Serveren vi hadde fått tildelt et område på fra HiO hadde ikke PHP installert, og vi fikk derfor ikke testet at dette fungerte i løsning vår. Vi lagde derimot ett test prosjekt i PHP som vi lastet opp på en server med støtte for PHP og verifiserte at pluginen virket. Fordi webhotellet DOOA benytter seg av har både IIS og PHP, kunne vi bruke PGRFilemanager i prosjektet PayPal Det var et ønske fra oppdragsgiver å implementere mulighet for betaling på nett. Vi kikket på noen alternativer, men valget falt på PayPal. Vi valgte dette av flere grunner: - PayPal krevde ikke tilgang til egen server. - Enkelt og implementere. - Gratis. - Blir av mange assosiert med sikker betaling på nettet. 21

23 22

24 8. Kravspesifikasjonen Good programmers use their brains, but good guidelines save us having to think out every case. (Francis Glassborow) 23

25 Da kravspesifikasjonen skulle utvikles, kontaktet vi oppdragsgiver for å høre deres ønsker og eventuelle krav de måtte ha til websiden. Deres ønsker og krav, i tillegg til våre ideer, dannet grunnlaget for kravspesifikasjonen. Kravspesifikasjonen ble sett på som en kontrakt mellom gruppen og oppdragsgiver, men vi stod fritt til å gjøre endringer for det bedre. 8.1 Endringer Første versjon av kravspesifikasjonen ble skrevet i forprosjektfasen. Denne var basert på ønsker vi fikk fra oppdragsgiver, og de ideer vi hadde for funksjonaliteten til nettsiden ved prosjektslutt. Når vi begynte å planlegge i planleggingsfasen ble det fort klart at kravspesifikasjonen var for lite detaljert. Kravspesifikasjonen bestod av for mange komplekse krav. Siden vi tidligere at avklart at vi kunne endre på kravspesifikasjonen fritt, begynte vi å dele opp de komplekse kravene, til mindre mer spesifikke krav. Første versjon av kravspesifikasjonen inneholdt hva nettsiden skulle gjøre. Etter endringene beskrev andre versjon av kravspesifikasjonen mer i detalj hva systemet måtte gjøre for at nettsiden skulle få den funksjonalitet som var ønsket. Vi var på dette tidspunktet fornøyd med kravspesifikasjonen vår, men etter hvert da vi var kommet i gang med utviklingen så vi at behovet for noen punkter i kravspesifikasjonen falt bort. Siden vi har så kategorisert nyhetsoppdatering valgte vi å utelate bloggen. 8.2 Betydning Etter en del endringer og arbeid med kravspesifikasjonen, følte vi alle at vi hadde god kontroll på hva som skulle utvikles. Da vi begynte med og prototype og utvikle GUI, så vi at vi med fordel kunne hadde en mer spesifikk kravspesifikasjon for dette, men vi valgte og ikke gjøre endringer i kravspesifikasjonen da oppdragsgiver ønsket å godkjenne utseende. Kravspesifikasjonen tydeliggjorde hvilken funksjonalitet oppdragsgiver og gruppen ønsket for systemet, i tillegg hadde oppdragsgiver sagt at enkelte krav var viktigere enn andre. Siden vi benyttet oss av Scrum som utviklingsmetode, og hadde en Scrum-tavle, kunne vi hele tiden flytte punkter fra kravspesifikasjonen over til tavlen. Det ble startet med de viktigste funksjonalitetene fra oppdragsgiver og implementasjon av de grunnleggende kravene for å tilfredsstille disse funksjonalitetene. Når vi var ferdig med en sprint, kunne vi enkelt bestemme hvilke punkter i kravspesifikasjonen som var viktige å implementere og flytte disse over til tavlen vår. Siden det ble gjort på denne måten kunne vi også enkelt jobbe flere personer mot en funksjonalitet, og dermed også sørge for at denne ble ferdig i løpet av sprinten. 8.3 Samsvar Vi føler at produktet vårt samsvarer veldig godt med kravspesifikasjonen vi kom frem til, selv om enkelte ting måtte gjøres litt annerledes en først planlagt. Dette var ofte på kodenivå og hadde lite eller ingen betydning for hvordan funksjonaliteten virket Avvik Det ble noen avvik fra kravspesifikasjonen. Disse avvikene var: - Søke i nyhetsarkiv og på sidene. - Ingen blog implementert. 24