Dette dokumentet er en del av en hovedprosjektoppgave ved Høgskolen i Oslo, avdeling for ingeniørutdanning i perioden oktober 2006 mai 2007.

Transkript

1 Forord Dette dokumentet er en del av en hovedprosjektoppgave ved Høgskolen i Oslo, avdeling for ingeniørutdanning i perioden oktober 2006 mai Dokumentet er først og fremst beregnet for sensor, veiledere og andre som måtte være interessert i hvordan prosjektarbeidet har forløpt og hvordan vi har kommet frem til sluttproduktet. Dokumentet beskriver hver fase i arbeidsprosessen; planlegging, metodologi og utviklingsprosess. Oppdraggiveren for prosjektet har vært Den Demokratiske Unionen for Iransk- Kurdiske Studenter i Norge (YXD-Kurdistan) som er en kurdisk studentforening som ble opprettet i juni 2006 i Norge. Vi kom i kontakt med oppdragsgiveren gjennom en av gruppas medlemmer, som også er medlem i studentforeningen. Produktet i dette prosjektet er en webapplikasjon som skal gi brukerne mulighet til å lese studentforeningens nyheter, gjestebok, skrive innlegg i gjesteboka, lese medlemmers blogger, lage sin egen blogg, chatte med påloggede bruekere og laste ned kurdiske aviser. Se produktdokumentasjonen for full oversikt av systemet og dets funksjonalitet. Dette dokumentet, og alle andre dokumenter som ble utarbeidet i løpet av prosjektperioden, vil være tilgjengelig for nedlasting og utskrift fra vår hovedprosjekthjemmeside: For de som ønsker å prøve applikasjonen selv, kan gjøre dette ved å gå inn på hjemmesiden (adressen ovenfor) og klikke på knappen "demo". Dere vil da bli overført til testserveren for applikasjonen. Følgende brukernavn og passord kan benyttes: Medlem: Administrator: brukernavn: medlem passord: medlem@ brukernavn: admin passord: admin@ Vennligst ta kontakt med oss dersom det skulle oppstå problemer under testkjøring av programmet. Kontaktinformasjon er tilgjenglig på hjemmesiden Prosessdokumentasjon 1

2 1 Innholdsfortegnelse Forord Innholdsfortegnelse Sammendrag Innledning Om gruppemedlemmene Om oppdragsgiveren Dagens situasjon Mål Rammebetingelser Språk Utviklingsmiljø Planlegging og metode Valg av oppdragsgiver Planleggingsfasen Prosessmodell Intern organisering Prosjektansvarskart Arbeidsverktøy Verktøy Teknologi Dagbok Veileder oppgaver/samarbeid Oppdragsgiver oppgaver/samarbeid Gruppesamarbeid Om utviklingsprosessen Utvikling av produktet Forprosjektfasen Utvikling av forprosjektdokumenter Kravspesifikasjon ER diagram Oppsett av arbeidsmaskin (arbeidsmiljø) Design- og implementeringsfasen Design av databasemodellen Design av brukergrensesnittet Avslutningsfasen Problemer og utfordringer Forbedringer Kravspesifikasjon og dens rolle Utvikling av kravspesifikasjon Kravspesifikasjonens rolle i utvikling Endringer i kravspesifikasjon Kravspesifikasjonen og dagens produkt Oppsummering og konklusjoner...18 Prosessdokumentasjon 2

3 6.1 Oppsummering Hva har vi lært? Vurdering av eget arbeid Hva kunne vi ha gjort annerledes? Produktets fremtid Kilder...20 Prosessdokumentasjon 3

4 1 Sammendrag Dette prosjektet er utviklet av to studenter som et hovedprosjekt ved Høgskolen i Oslo, avdeling for ingeniørutdanning i perioden oktober 2006 mai Oppgaven har gått ut på å utvikle en webapplikasjon for oppdragsgiverens nettside ( Hensikten med oppgaven var å gi studentforeningen en nettside som er enklere å administrere og mer interaktiv for deres medlemmer. Vårt produkt er en applikasjon som gir dynamisk distribusjon av informasjon. Med dette mener vi at brukerne av systemet skal kunne legge til, endre eller fjerne innholdet på sidene fra et brukergrensesnitt. Systemet kan deles opp i tre lag; presentasjonslag, applikasjonslag og databaselag. Presentasjonslaget består av alle visuelle komponenter som man ser på siden (bilder, tekst, knapper, tekstfelt, etc.). Koden for presentasjonslaget har vi delt i tre forskjellige filtyper; *.css (definerer stilen for designet), *.master (felles ramme for alle sidene) og *.aspx (selve layouten og designet). Mesteparten av koden som ligger i disse filene kan man se i nettleseren ved å åpne kildekoden til siden. Programkoden (applikasjonslaget) har vi i separate filer (*.aspx.cs), såkalte code-behind filer. Hver code-behind fil er knyttet til en aspx-side med samme navn og kan kun benyttes av denne siden. Mens de globale metodene, som er tilgjengelig for hele applikasjonen, er lagt i en egen mappe (App_Code). Verken code-behind filene eller de globale metodene er tilgjengelige for brukeren. Den siste delen av systemet er databaselaget. Her lagres alt data som brukerne publiserer. All tekst lagres i databasen, mens bilder og filer lastes opp til egne mapper på serveren og den relative stien og navnet på filen lagres i databasen. Vi har også delt applikasjonen inn i tre forskjellige roller; administrator, medlem og anonym. Den sistnevnte er ikke implementert som en egen rolle i systemet siden det er enkelt å finne ut om brukeren er anonym eller ikke. Men vi vil fortsatt nevne den for at leseren skal få en bedre forståelse av applikasjonen. På figuren under kan vi se hvor mye av systemet hver av rollene har tilgang til. Vi ser også at brukere i alle tre roller kan lese fra databasen og skrive til den. Figur 1.1 Rollefordeling i systemet Prosessdokumentasjon 4

5 2 Innledning Dette kapittelet gir en beskrivelse av prosjektgruppa, oppdragsgiveren og deres ønsker for produktet, samt rammebetingelser og mål for oppgaven. 2.1 Om gruppemedlemmene Gruppen består av to studenter ved Høgskolen i Oslo, avdeling for ingeniørutdanning, som har samarbeidet tidligere i flere andre prosjekter ved skolen. Vi valgte å jobbe sammen i dette prosjektet på grunn av den gode erfaringen vi hadde fra de tidligere prosjektene og fordi vi begge hadde store ambisjoner med hovedprosjektet. Frem til det siste semesteret har vi jobbet mest med Java. Vi ønsket derfor å jobbe med noe nytt i dette prosjektet, noe vi ikke hadde jobbet med tidligere. Vi diskuterte to forskjellige muligheter med oppdragsgiveren. Den ene var å bruke JavaServer Faces (JSF) og den andre var å bruke ASP.NET. Begge teknologiene var nye for oss. Vi lærte litt om JSF i valgfaget "Webapplikasjoner" i høstsemesteret og vi tok valgfaget "Webprogrammering i.net" i vårsemesteret. Vi kunne med andre ord ingenting om ASP.NET før det siste semesteret. Så vi måtte lære så mye som mulig om denne teknologien underveis. Vi tok begge to ansvar for dokumentasjon og programmering. Hvis en av oss hadde oppdatert noe, så sendte han det til den andre. På den måten hadde vi hele tiden en oppdatert versjon av både applikasjonen og dokumentasjonen. Vi jobbet selvsagt med forskjellige oppgaver når vi jobbet hver for oss, så vi ikke skulle gjøre det samme begge to. 2.2 Om oppdragsgiveren YXD-Kurdistan er en kurdisk studentforening som ble opprettet i juni 2006 i Norge. Organisasjonen er en del av en større studentforening som finnes i andre land med hovedkontor i Nord-Irak. YXD-kurdistan i Norge har mer enn 60 medlemmer. Unionen er et mellomledd mellom kurdiske studenter og faginstitutter på universiteter og høyskoler. Organisasjonen jobber for integrering av kurdiske studenter i Norge, hjelper elever ved å delta i prosjekter i samarbeid med forskjellige videregående skoler i Oslo, holder seminarer for forfattere og studenter og deres familie og venner, og hjelper med faglige kunnskaper for kurdiske og ikke kurdiske organisasjoner i Norge. 2.3 Dagens situasjon Studentforeningen har en eksisterende nettside ( som er bygget opp av PHP og MySQL. Den virker kun som en informasjonskilde for medlemmer og andre besøkende. Når vi kontaktet organisasjonen var de veldig åpne for nye idéer. Vi diskuterte forskjellige muligheter for nettsiden som ville gjøre den mer appellerende for deres medlemmer. Til slutt ble vi Prosessdokumentasjon 5

6 enige om en løsning - denne er beskrevet mer detaljert i resten av dette dokumentet. 2.4 Mål Hovedmålet med oppgaven er å lage et medlemsregistersystem for YXD. Systemet skal gjøres sikkert ved å kombinere ferdige løsninger i ASP.NET 2.0 (som blant annet krypterer innloggingsdata) og innloggingskontroll og rollefordeling. Resultatmålet vårt er å lage en webapplikasjon som skal være brukervennlig og enkel å oppdatere og utvikle i fremtiden. Både medlemmene og administratoren skal kunne bruke systemet uten å ha behov for spesielle datakunnskaper. Oppgavens læringsmål er å bli kjent med nye teknologier og å kunne bruke disse til å lage en mer avansert, men brukervennlig, nettside. 2.5 Rammebetingelser Punktene nedenfor er korte sammendrag fra rammer som ble satt i samarbeid med oppdragsgiveren, for en fullstendig oversikt bør leseren lese gjennom kravspesifikasjonen Språk Vi har tilpasset hele applikasjonen til det norske og det kurdiske språket. For å få til dette har vi måttet lage en todelt applikasjon. Slik at hver funksjon ble lages to ganger, en på norsk og en på kurdisk. Vi synes at dette var en fornuftig fremgangsmåte, spesielt på grunn av den store forskjellen på de to språkene. Dersom vi hadde gjort det motsatt, at vi tilpasset språket til applikasjonen, så hadde vi endt opp med et produkt som likner på mange av dagens kurdiske nettsider, hvor bare teksten er oversatt til kurdisk mens resten av siden egentlig er ment for et annet språk. Vi har sett mange eksempler på dette, og det er verken pent eller brukervennlig Utviklingsmiljø Vi har sett på to muligheter til å løse denne oppgaven på. Den ene var å lage applikasjonen i ASP.NET og den andre var å bruke JavaServer Faces (JSF). Vi har diskutert dette med oppdragsgiveren, men har ikke fått noen spesifikke krav når det gjelder plattform, verktøy eller språk. De hadde derimot noen ønsker: Applikasjonen skal være forholdsvis enkel å teste og sette ut i drift. Det skal ikke være vanskelig å endre applikasjonen senere. Programmeringsspråket skal være forholdsvis kjent og utbredt, slik at det ikke vil være noe problem å finne utviklere som kan vedlikeholde og videreutvikle systemet. Det viktigste argumentet for mange, når det gjelder valg av utviklingsmiljø, er vanligvis hvilke som er gratis og hvilke som koster penger. Svaret vi fikk fra oppdragsgiveren var at det ikke spilte så stor rolle for dem hvilke av de to vi brukte, siden de uansett betaler for et webhotell. Uansett hvilken av dem vi valgte å bruke, måtte de kjøres på en helt annen server enn den studentforeningen bruker i dag. Valget vårt ble til slutt ASP.NET med C# som Prosessdokumentasjon 6

7 løsning på denne oppgaven. Utviklingsmiljøet vi vil benytte oss av er Microsoft Visual Studio Generelt sett er JSF- og.net-løsninger ganske like i kvaliteten av deres løsninger. En av grunnene til at vi valgte.net er at det er mer populært og har dermed flere utviklere tilgjengelig enn hva tilfellet er for JSF. I tillegg har ASP.NET flere verktøy som passer utmerket for denne typen av applikasjoner. Prosessdokumentasjon 7

8 3 Planlegging og metode Dette kapittelet tar for seg hvordan vi planla arbeidet fra idéfase til ferdig produkt og hvilke arbeidsmetoder som ble brukt. 3.1 Valg av oppdragsgiver Gruppen ble introdusert til studentforeningen gjennom ett av gruppemedlemmene, Asad Fattahi, som er medlem i foreningen. Vi kontaktet YXD-Kurdistan tidlig på høsten og tilbød dem å utvikle nettsiden deres med flere spennende funksjoner som medlemmene deres kunne benytte seg av. 3.2 Planleggingsfasen Planleggingen av prosjektet begynte i oktober. Vi visste fra samtaler med oppdragsgiver omtrent hva de ville ha. Så for å få en oversikt over oppgaven, begynte vi med å lage en røff skisse av applikasjonen. Vi forsette så med å lage en forprosjektrapport og en fremdriftsplan. Deretter begynte vi å sette sammen en kravspesifikasjon sammen med oppdragsgiveren. Siden studentforeningen ikke hadde noen kravspesifikasjon vi kunne jobbe med, så måtte vi selv lage en kravspesifikasjon med de krav vi selv følte var naturlig for denne oppgaven. Deretter forklarte vi det vi hadde skrevet i kravspesifikasjonen og diskutere med oppdragsgiver hva som skal være med og hva som ikke skal være med. Vi har måttet gå tilbake til kravspesifikasjonen et par ganger for å gjøre noen endringer som oppdragsgiveren kom med i ettertid. Men disse har vært enkle å implementere siden det bare var noen småting som skulle forandres. Vi bestemte oss for å delegere oppgavene mellom oss etter hvor vi hadde størst kompetanse. Se ansvarskart under avsnitt Når vi begynte å programmere benyttet vi tradisjonell bottom-up programmering der vi programmerte en funksjon, testet og gikk videre. Dette var en naturlig måte å gjøre det på med tanke på hvordan sidene i ASP.NET er bygget opp. Mesteparten av de funksjonene som vi skulle utvikle passer best dersom de ligger på hver sin side. Siden hver side har en egen codebehind fil som inneholder programkoden for den siden, så er det veldig enkelt å separere funksjonene fra hverandre. Det er derfor veldig enkelt å legge til nye funksjoner eller fjerne eksisterende funksjoner Prosessmodell Som styringsmodell for vårt prosjekt har vi valgt Rational Unified Process (RUP). Dette er en styringsmodell som er blitt standard for de fleste tunge aktørene i programvareindustrien. RUP beskriver: Hvem som gjør hva, hvordan og når Retningslinjer Prosessdokumentasjon 8

9 Maler/Mønstre Verktøyhjelp Fremdrift RUP er delt inn i fire faser: Idéfase Utdypningsfase Konstruksjonsfase Overgangsfase I løpet av denne fasen ble visjon, forretningscase og omfang av prosjektet klarlagt. I løpet av denne fasen ble mesteparten av arkitekturen ferdig. På slutten av konstruksjonsfasen skal betaversjonen av vår tjeneste være klar til utprøving hos oppdragsgiver. På slutten av denne fasen skal vi ha en endelig versjon av tjenesten. RUP er både iterativ og inkrementell. Hvert delprodukt som vi lager underveis i prosjektet vil ha flere utgaver. RUP er også en Use Case drevet prosess. En Use Case-modell dokumenterer kravene. Den viser hva systemet gjør for hvem, og viser nytteverdi for aktøren. Use case diagrammet er under kapittel 7.1 i kravspesifikasjonen Intern organisering Vårt prosjekt har blitt styrt som en matriseorganisasjon, dvs. at styringen har gått på tvers av medlemmene i gruppen. Asad ble valgt som prosjektansvarlig, han er også den som har hatt mest kontakt med oppdragsgiver. Ernad har vært prosjektsekretær, han har hatt ansvar for dokumentasjonsstyring. Se også prosjektansvarskart i neste punkt Prosjektansvarskart Det var en god hjelp å ha ansvarsroller, men begge tok ansvar for det som måtte gjøres av arbeid på tvers av ansvarsområdene. ANSVARSOMRÅDE Prosjektleder Hovedansvarlig for programmering Hovedansvarlig for back-up Ansvarlig for modellering Webansvarlig Hovedansvarlig for brukergrensesnitt Hovedansvarlig for dokumentasjon ANSVARLIG Asad Asad Asad Begge to Ernad Ernad Ernad Prosessdokumentasjon 9

10 3.3 Arbeidsverktøy Siden oppdragsgiveren ikke hadde noen krav til arbeidsverktøy, så stod vi ganske fritt for å velge de verktøyene som vi skulle benytte oss av i utviklingsperioden Verktøy Her har vi beskrevet verktøy som vi har benyttet i prosjektet. Vi har nevnt hvilke av disse verktøyene som er gratis og hvilke som ikke er det, for å vise at selv de som ikke er studenter kan utvikle den samme applikasjonen uten ekstra kostnader. Dette er også viktig for oppdragsgiveren å vite dersom de senere skulle ansette noen til å vedlikeholde og/eller videreutvikle systemet. Microsoft Visual Studio 2005 Dette var hovedverktøyet for utviklingen av applikasjonen. Vi brukte Visual Studio til å skrive ASP, HTML, C#, SQL og til å lage CSS stiler for sidene. Visual Studio var gratis for oss fordi vi som studenter kan laste ned gratisversjonen. Men det finnes flere gratisalternativer for Visual Studio, som for eksempel Microsoft Visual Web Developer 2005 Express Edition. Internet Information Services 5.1 Internet Information Services (IIS) er et webserverprogram for Windows plattformen. IIS ble brukt som en testserver på arbeidsmaskinen som vi har satt opp på skolen. Vi benyttet den for å se hvordan applikasjonen ville oppføre seg på en server. IIS er gratis, men kan ikke installeres på XP Home. IBM Rational Rose Data Modeler Professional Edition v Rational Rose ble brukt til Use Case modellering. Dette programmet er ikke gratis, men kan brukes i en prøveperiode på 30 dager. Det finnes også noen gratisprogrammer for modellering. DB Designer 4 Vi brukte DB Designer til å designe databasemodellen (ER diagrammet). Dette programmet er gratis. Adobe Photoshop CS Vi brukte Photoshop til redigering av alle grafiske komponenter i prosjektet. Dette programmet er ikke gratis, men kan benyttes i en prøveperiode på 30 dager. Det finnes også gode gratisverktøy som kan brukes til bilderedigering, men vi er mer vant med dette. TextPad TextPad er et verktøy for mer avansert tekstredigering enn det som er mulig med Notepad (standard editor i Windows). Vi brukte TextPad til rask redigering av html, css, ASP og C# kode. Dette er nyttig når man trenger å endre noen få linjer med kode og har ikke tid til (eller ikke vil bruke tid på) å starte Visual Studio. TextPad kan man laste ned og bruke gratis. Microsoft Office Word Microsoft Office Word ble brukt til å lage dokumentene og rapportene gjennom prosjektperioden. Prosessdokumentasjon 10

11 Microsoft Office Excel Microsoft Office Excel ble brukt til å lage fremdriftsplan ettersom Excel-arkene allerede er delt opp i rader og kolonner som gjør det enklere å lage diverse planer. I stedet for Microsoft Office kan man også bruke Open Office til å lage dokumenter og regneark. Open Office har mange av de samme funksjonene som MS Office, men den er gratis. Webmail og MSN Messenger/Yahoo! Messenger Grunnen til at vi benyttet både MSN og Yahoo! er at vi har forskjellige e-post kontoer. MSN Messenger og Yahoo! Messenger er to programmer som har gjort samarbeidet betraktelig enklere, spesielt i slutten av prosjektperioden. Ved hjelp av disse programmene kunne vi snakke/chatte med hverandre over Internet når vi satt hjemme og jobbet. Men fordi de to programmene ikke har støtte for filoverføring seg imellom, så måtte vi bruke skolens webmail til å sende filer mellom hverandre. Både MSN og Yahoo! Messenger er gratis Teknologi Her har vi beskrevet følgende teknologier som vi har benyttet i prosjektet. C# C# (uttales C sharp) er et programmeringsspråk for objektorientert programmering. Språket er basert på programmeringsspråkene C++ og Java. ASP Active Server Pages (ASP) er en teknologi for å lage websider som inneholder server-side scripts. HTML En ASP side består av både ASP kode og HTML (Hypertext Markup Language) kode. CSS CSS (Cascading Style Sheets) er stilark for HTML. Ved hjelp av CSS får man en mer oversiktlig layout på websidene. Stilarkene er også mye enklere å gjøre endringer på. SQL SQL (Structured Query Language) er et språk som benyttes til å formulere og kjøre operasjoner mot databaser. Vi trengte ingen innføring i dette ettersom vi var kjent med det fra relasjonsdatabase kurset fra pensumet vårt. 3.4 Dagbok Ettersom vi var kun 2 på gruppa så hadde vi konstant kontakt med hverandre og holdt hverandre oppdatert. Vi valgte å føre dagboka i slutten av uka, på fredager. Den inneholder hvilke oppgaver vi skulle gjøre den uka, hva som ble gjort og viktige merknader. Dagboka ble publisert på nettsiden til hovedprosjektet og er arrangert etter ukenummer. Prosessdokumentasjon 11

12 3.5 Veileder oppgaver/samarbeid I forbindelse med prosjektarbeidet har vi hatt faste møter, hvor vi kunne få oppfølging fra veilederen. Vårt samarbeid med veileder har gått ut på å få godkjent ulike ideer, samt få svar på spørsmål relatert til prosjektoppgavens gjennomføring. Utviklingen av systemet, og dokumentasjonen har gått veldig bra, men det var likevel fint å kunne få veileder til å se over ting og si ifra om noe burde vært gjort annerledes. 3.6 Oppdragsgiver oppgaver/samarbeid Gjennom hele prosjektperioden har vi vært i kontakt med oppdragsgiveren og det har vært en god dialog mellom gruppen og oppdragsgiveren. Selv om utviklingsmiljøet vårt var på skolen, så var oppdragsgiver alltid i kontakt med oss via e-post. Og siden et av gruppemedlemmene var medlem i studentforeningen, så fikk gruppen kontakt med oppdragsgiver personlig om det var noe som måtte drøftes. 3.7 Gruppesamarbeid Med kun to medlemmer på gruppen har samarbeidet vært veldig bra. Det har vært god forståelse for hverandres meninger, og begge har hatt mulighet til å komme med sine innspill. Vi fordelte noen av arbeidsoppgavene etter hvor vi hadde størst kompetanse, men mesteparten av oppgavene ble gjort av begge to. Ved tid til annen gikk vi gjennom ting og foreslo hva som var bra og dårlig. Vi merket også den negative siden ved å være to på gruppen. Arbeidsmengden har vært mye større enn det vi var vant med fra tidligere prosjekter. Spesielt ved slutten av prosjektperioden. Prosessdokumentasjon 12

13 4 Om utviklingsprosessen Dette kapittelet beskriver enkelte av utfordringene vi møtte og hvordan de ble løst. 4.1 Utvikling av produktet Hovedsakelig begynte utviklingen av nettstedet etter at mesteparten av planleggingen var satt. Selv om vi hadde begynt å utvikle noen av funksjonene allerede før planleggingsfasen var ferdig, så regnet vi ikke disse som en del av nettstedet. Det var mer for å prøve ut den nye teknologien. Vi var ganske ivrige med å sette i gang med kodingen fordi vi ikke hadde gjort noen liknende oppgaver tidligere. Etter at spesifikasjonene og modellene av systemet var klare, følte vi at det grunnleggende for å bygge opp prosjektet var på plass. Men vi forventet at det ville dukke opp endringer etter hvert. Det første vi gjorde var å bygge opp databasestrukturen, da all data som blir benyttet av systemet ville bli lagret her. Deretter startet vi utviklingen av nettstedet. Det ble lagt vekt på å få gjennomført alle punktene som oppdragsgiver hadde definert i kravspesifikasjonen. 4.2 Forprosjektfasen I forprosjektfasen brukte vi mest tid på å få på plass detaljene og strukturen i systemet. Det var viktig for oss å være mest mulig forberedt før vi gikk løs på kodingen av systemet. Det er også viktig å være klar over at vi ikke kunne være forberedt på alt fordi vi visste veldig lite om.net teknologien på denne tiden Utvikling av forprosjektdokumenter Selve innhentingen av informasjon for prosjektet ble gjort fortløpende, mens den grunnleggende informasjonen var ferdigsatt etter møtet med oppdragsgiveren. På dette grunnlaget fikk vi en oversikt over hva slags forventinger oppdragsgiveren hadde til prosjektet og dens fremtid. Basert på informasjonen vi samlet inn lagde vi en forprosjektrapport ettersom de viktigste elementene var ferdigsatt. Vi brukte tid til å lage forprosjektrapporten ettersom både arbeids- og fremdriftsplanene ville bygges på den Kravspesifikasjon Vi laget kravspesifikasjonen uti fra den informasjonen vi samlet inn under de første samtaler med oppdragsgiver. Den første utgaven skrev vi på egenhånd, og presenterte senere på et møte med oppdragsgiver. Deretter gikk vi grundig gjennom punktene i kravspesifikasjonen og endret det som måtte endres og fikk svar på enkelte ting vi ikke var sikre på. Se kapittel 5 for mer informasjon om kravspesifikasjonen, eller Del II i dette dokumentet for fullstendig kravspesifikasjon. Prosessdokumentasjon 13

14 4.2.3 ER diagram Når kravspesifikasjonen var revidert begynte vi arbeidet med å sette opp databasen for hele systemet. Vi lagde et ER-diagram for tabellene og databaserelasjonene i systemet Oppsett av arbeidsmaskin (arbeidsmiljø) Vi hadde et fast arbeidssted på skolen, så vi kunne jobbet både hjemme og på skolen. Vi sørget for at programmene var installert både på våre private maskiner og på skolemaskinen. Men etter hvert som applikasjonen ble tyngre, fikk vi mer og mer problemer med maskinen på skolen. Den var helt enkelt for gammel og treg. Det tok en evighet for Visual Studio å starte og kjøre applikasjonen. Vi har derfor brukt våre egne maskiner, både hjemme og på skolen. Det var ingen forskjell på programvaren, vi brukte akkurat de samme programmene som vi hadde på skolemaskinen. 4.3 Design- og implementeringsfasen Dette kapittelet tar for seg designet av databasen og brukergrensesnittet Design av databasemodellen I løpet av den perioden da vi jobbet med kravspesifikasjonen begynte vi å få en "følelse" av hvordan systemet skulle fungere. Så vi syntes at det var best å vente med å designe databasemodellen til vi ble ferdige med kravspesifikasjonen. For da ville vi ha et mer helhetlig bilde av systemet og dets funksjoner. På den måten kunne vi forhindre en del endringer av databasen senere i utviklingsperioden. Vi begynte først med å sette opp et ER diagram med de viktigste tabellene slik at vi kunne få oversikt over det grunnleggende. Deretter utvidet vi dette diagrammet til en mer utfyllende modell av databasen, med kolonnenavn, indekser, nøkler, relasjoner, etc. Vi har også tatt med tabellene som blir generert av Visual Studio, siden disse er veldig viktige i applikasjonen. Selve ER diagrammet kan man finne under kapittel 7.2 i kravspesifikasjonen Design av brukergrensesnittet Som vi har nevnt tidligere, så begynte vi veldig tidlig med kodingen av de enkelte funksjonene i applikasjonen. Det var litt rotete i begynnelsen, siden vi ikke hadde fått på plass et brukergrensesnitt. Dette var en slags eksperimenteringsfase for oss, hvor vi tenkte mest på funksjonaliteten og logikken bak de enkelte funksjonene. Grunnen til at det ble gjort på denne måten var for å teste de to teknologiene, JSF og.net, mot hverandre. Når vi først hadde bestemt oss for hvilket utviklingsspråk vi skulle benytte oss av, kunne vi sette i gang med den "offisielle" applikasjonen. Brukergrensesnittet kom på plass noen uker uti utviklingsperioden. Vi prøvde ut flere forskjellige designmaler før vi kom frem til en design som vi begge likte og som vi syntes passet for denne applikasjonen. Når vi viste frem produktet med det nye designet til oppdragsgiveren så var de kjempefornøyde og vi fikk mye ros for det arbeidet vi hadde gjort så langt. Dermed anså vi brukergrensesnittet som ferdig. Figur 4.1 på neste side er en skisse av grensesnittet, den er ganske selvforklarende. Prosessdokumentasjon 14

15 Figur 4.1 GUI skisse 4.4 Avslutningsfasen Da vi gikk over til avslutningsfasen, hvor vi skulle teste og finjustere applikasjonen, var det en funksjon som vi ikke var ferdige med, nemlig forumet. Det var nok tid igjen til å gjøre ferdig denne, men helt siden vi viste frem applikasjonen til oppdraggiveren har vi fått flere krav om endringer. Dette gjelder mest småting (linker, ekstra paneler, opplasting av aviser, mm.) som er enkle å implementere, men som tar tid. Så vi bestemte oss for å forklare situasjonen til oppdragsgiveren og høre hva de mente. Vi fikk som svar at de heller ville ha de endringene som de kom med i ettertid enn forumet. Dette var selvfølgelig en god nyhet for oss, for nå kunne vi bruke mer tid på testing av systemet. Noe vi håper vil bidra til et mer solid og stabilt produkt. 4.5 Problemer og utfordringer Vi har møtt mange utfordringer på veien, spesielt på begynnelsen på grunn av manglende kunnskaper om de nye teknologiene. Men dette har heldigvis også hjulpet oss til å forstå og lære mye mer om de nye verktøyene og språkene. Det var også bra at vi begge hadde valgfaget i.net samtidig som vi holdt på med dette prosjektet. Vi lærte utrolig mye i løpet av de første månedene takket være det faget, og vi hadde samtidig en lærer vi kunne snakke med dersom vi hadde problemer. Oppdragsgiveren var også veldig hjelpsom. De hjalp oss Prosessdokumentasjon 15

16 ved å diskutere om forskjellige alternativer og løsninger på de problemene vi fikk underveis. De største problemene vi hadde var med noen av de nye verktøyene vi brukte. For eksempel Visual Studio og IIS, som vi ikke hadde noe kjennskap til før dette prosjektet. Vi brukte mye tid på å konfigurere dem og finne frem til de innstillingene som vi trengte. Det verste er når vi får en feilmelding som vi aldri har sett før. Da tar det litt tid før man har funnet ut hva meldingen betyr og hvordan man fikser den. 4.6 Forbedringer Vi mener at vi har oppfylt de krav som oppdragsgiver hadde satt, men det er alltid muligheter for forbedringer. Systemet er utviklet etter kravspesifikasjonen og fungerer utmerket. Vi har sagt oss villige til å fortsette å utvikle applikasjonen en stund til, noe oppdragsgiveren ikke hadde noen innvendinger til. Prosessdokumentasjon 16

17 5 Kravspesifikasjon og dens rolle Dette kapittelet forteller litt kravspesifikasjonen og dens betydning for prosjektarbeidet. 5.1 Utvikling av kravspesifikasjon Som vi har påpekt tidligere i denne rapporten har ikke oppdragsgiveren hatt noen ferdig spesifikasjon av kravene for produktet. Vi har derfor måttet samle inn så mye informasjon som mulig om det produktet de var ute etter, slik at vi kunne sette opp et førsteutkast av kravspesifikasjonen. Vi vet fra tidligere prosjekter at kravspesifikasjonen er særdeles viktig for utviklingen av produktet, ikke bare i begynnelsen men gjennom hele utviklingsprosessen. Det var derfor viktig for oss å lage denne så detaljert som mulig. Når førsteutkastet av spesifikasjonen var ferdig, så vi nøye gjennom den sammen med oppdragsgiver. Det har blitt en del endringer siden førsteutkastet, og kravspesifikasjonen har gått mye frem og tilbake mellom oss og oppdragsgiver. Grunnen til dette var at oppdragsgiver ikke hadde helt klare krav til det endelige produktet. Så når vi skulle sette de tekniske detaljene for produktet, måtte vi sjekke med oppdragsgiver om disse var godkjent eller om det skulle gjøres på en annen måte. 5.2 Kravspesifikasjonens rolle i utvikling Kravspesifikasjonen har fungert som en veldig god kontrakt mellom oss og oppdragsgiveren. Den ble brukt i særdeles stor grad i design- og utviklingsfasen, men også senere i prosjektet. Den har vært en sentral kilde under utviklingen og vi brukte kravspesifikasjonen som en spilleregel til å oppnå de forskjellige målene. 5.3 Endringer i kravspesifikasjon De fleste endringene som har forekommet var i begynnelsen, under utviklingen av kravspesifikasjonen. Dette var stort sett mindre justeringer av de enkelte funksjonene i applikasjonen. Den eneste store endringen som har forekommet, var å fjerne diskusjonsforumet fra applikasjonen og i stedet lage en side for opplasting av aviser (PDF- og Word-dokumenter), og en side for publisering av linker. 5.4 Kravspesifikasjonen og dagens produkt Som vi nevnte tidligere, så har kravene i kravspesifikasjonen blitt endret en del siden begynnelsen av prosjektet. Disse endringene har alle kommet fra oppdragsgiveren underveis i utviklingsperioden. Og for å kunne følge fremdriftsplanen har vi måttet holde tempoet oppe, vi har derfor ikke hatt mye tid til å gå tilbake hele tiden for å dokumentere alle disse endringene i kravspesifikasjonen. Prosessdokumentasjon 17

18 6 Oppsummering og konklusjoner Her kommer en oppsummering av prosjektarbeidet, det vi har lært og den erfaringen vi har tilegnet oss i løpet av prosjektperioden. 6.1 Oppsummering Hovedprosjektet har uten tvil vært vellykket på flere områder. Vi er meget fornøyde med valg av oppdragsgiver og engasjementet fra kontaktpersonen i studentforeningen. Vi er også fornøyde med det produktet som vi har utviklet og den lærdommen vi har tilegnet oss i de forskjellige teknologiene, som vi vet brukes i høy grad i arbeidslivet. Det har vært både oppturer og nedturer. Vi fikk en litt vanskelig start siden vi valgte å jobbe med en ny teknologi, men vi har heldigvis fått god bruk for de systemutviklingsteknikker som vi har lært oss opp gjennom årene på ingeniøravdelingen på høgskolen. Til tider kan vi også ha følt at arbeidsmengden har vært stor og at tiden ikke alltid strakk til, men vi har ikke blitt presset av oppdragsgiver til å jobbe ekstra mye av den grunn. Læreviljen og nysgjerrighet har vært stor drivkraft til at vi har utviklet et produkt som begge parter er meget fornøyd med. Etter hvert ble vi også mer kjent med miljøet rundt oss, og da gikk det bare den positive retningen. 6.2 Hva har vi lært? Dette har vært et stort utviklingsprosjekt som har først og fremst gitt oss mye erfaring i hvordan det er å utvikle et produkt fra en idé til selve implementeringen. Det har vært veldig mye å gjøre, men til gjengjeld har vi løst en oppgave slik det var forventet. Selv om vi til å begynne med følte at vi hadde alt planlagt, vet vi nå at det alltid kan dukke opp et problem. Erfaringsmessig stemmer dette, men vi har lært å løse problemer som dukker opp, slik at vi klarer å fokusere på det som skal gjøres. Et godt eksempel på dette er databasen. Vi trodde vi hadde en god oversikt over hvordan databasen ville være, men ettersom vi begynte med utviklingen av systemet måtte vi endre databasen flere ganger. Dette har ført til at vi sitter igjen med en erfaring av at selv et godt planlagt prosjekt vil forandres ettersom prosjektet utformer seg. Av alle de fagene vi har hatt på skolen i løpet av disse tre årene mener vi at hovedprosjektet har gitt oss mest lærdom på så kort tid. Vi har blitt kjent med nye og spennende teknologier som er veldig aktuelle. Men vi er veldig glad for at vi gjennomgikk de mindre utviklingsprosjektene tidligere i utdanningen. De har gitt oss nok erfaring og kunnskap til å kunne utføre et stort og omfattende prosjekt som dette. Prosessdokumentasjon 18

19 6.3 Vurdering av eget arbeid Vi er også fornøyde med vår egen innsats. Vi har jobbet som et team og ikke enkelte individer, og hvis vi har hatt behov for hjelp så har vi stilt opp for hverandre. Interessen og ambisjonene har vært like høye og begge har jobbet mot å skape et så godt som mulig produkt og lære mest mulig under hele prosjektet. Gruppearbeid er noe vi har god erfaring med fra tidligere i studiet, og dette er blitt enda mer forsterket etter dette prosjektet. Selv om det kan være stor kontrast mellom hvordan folk arbeider, så har vi klart å fordele arbeidet slik at vi har nådd våre mål. 6.4 Hva kunne vi ha gjort annerledes? Selv om vi er veldig fornøyde med det arbeidet vi har gjort og hvordan utviklingsprosessen har forløpt, så er det to ting vi skulle ønske vi hadde gjort annerledes. Vi skulle ha disponert tiden bedre slik at vi kunne skrive en mer utfyllende dokumentering enn det vi har gjort. En annen ting er at vi skulle hatt en person til på gruppa. Prosjektet viste seg å være mye større enn det vi hadde forventet oss og vi følte ofte at tiden ikke strakk til. 6.5 Produktets fremtid Vi har laget et veldig godt grunnlag for et interaktivt nettsted som studentforeningen kan benytte seg av til å gi sine medlemmer et sted hvor de kan samle seg og utveksle tanker og meninger. Produktet vi har laget har enorm potensial for videreutvikling. Det er en type applikasjon som kan utvides med massevis av funksjonalitet. Her er noen eksempler; oppretting av bildealbum, opplasting av video- og musikkfiler, intern meldingstjeneste, e-post tjeneste, avstemninger, brukerdefinerte layout (bakgrunnsbilder og farger), tekstmeldingstjeneste mot mobiltelefoner og andre funksjoner som er tilpasset mobile enheter, og mye mer. Vi har sagt oss villige til å jobbe videre på dette produktet etter at hovedprosjektet er ferdig, noe som er virket veldig interessant for oppdragsgiveren. Prosessdokumentasjon 19

20 7 Kilder Bøker: Programming ASP.NET - 3rd Edition (Jesse Liberty & Dan Huritz) Core C# and.net (Stephan C. Perry) Databaser (Kjell Toft Hansen & Tore Mallaug) ASP.NET 2.0 With C# (Chris Hart, Johan Kauffman, David Sussman, Chris Ullman) Beginnning C# 2005 Databases (James Huddleston) Database Processing (David M. Kroenke) Nettkilder: Prosessdokumentasjon 20