Prosessdokumentasjon 1

Transkript

1 Prosessdokumentasjon 1

2 Forord Denne rapporten inneholder dokumentasjon av prosessen og gruppens arbeid fra prosjektets start til slutt. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte finne det interessant. Det forventes at leseren av prosessdokumentasjonen har grunnleggende kunnskaper om datateknikk. Det vil si at leseren har kjennskap til programmering og systemutvikling. Hensikten med prosjektet har vært å utvikle et system som i hovedsak skal vise studentene hvor de forskjellige forelesningene foregår og i hvilke tidspunkt. Dette systemet har fått navnet RomSys fra dens utviklere. RomSys skal brukes på skjermer satt opp forskjellige steder på skolen, og vise reservasjonene for de gitte etasjene. For teknisk informasjon om RomSys henviser vi til produktrapporten. 2

3 Innholdsfortegnelse 1 Innledning Presentasjon Om bedriften Bakgrunn for oppgaven... 5 Hva er TimeEdit?... 5 Situasjonen ved prosjektstart Mål Rammebetingelser, hentet fra kravspesifikasjonen Utviklingsmetode Generelt om prosjektutvikling Om utviklingsprosesser Om utviklingsmetoder Om vårt prosjekt utviklingen av RomSys Forberedelser, planlegging og prosjektstyring Valg av hovedprosjekt (prosjektstart) Tilrettelegging fra oppdragsgiver Valg av løsning og teknologi Organisering Hjemmeside Prosjektstyring Anvendt programvare Microsoft Visual Studio Microsoft Expression Blend Microsoft SQL Server Anvendte rammeverk og programmeringsspråk ASP.NET, C# og Silverlight XML LINQ Regular Expression Windows PowerShell IIS Fremdriftsplan og arbeidsplan Kravspesifikasjon

4 4.1 Om bakgrunnen Hensikten med kravspesifikasjoner Kort systembeskrivelse Timeplan Nyheter Annet Eventuelle krav til systemkonstruksjon (tekniske krav) Utvikling Drift Utstyr Eventuelle krav til dokumentasjon Utviklingsprosess og gjennomføring Kravspesifikasjonens rolle i utviklingsprosessen Use Case-modellens rolle under utviklingsprosessen Veiledning og samarbeid Presentasjonsmøte med veileder, oppdragsgiver og faglærer i.net TimeEdit i vårt prosjekt Hovedutfordringer Innsamling av data Knytte Silverlight til database Iterasjonsbeskrivelse Iterasjon Iterasjon Iterasjon 1-ii Iterasjon Iterasjon Iterasjon Iterasjon Oppsummering Produkt Prosess Kilder

5 1 Innledning 1.1 Presentasjon Tittel: Visning av romfordeling Oppgave: Utvikle et program som henter data fra TimeEdit, og viser dette på skjermer fordelt rundt på skolen. Periode: 30. okt mai 2010 Gruppemedlemmer: Nam H. Lac, s (3AB) Sami Sarinc, s (3AB) Erlend Steen, s (3AB) Øzden Tasdelen, s (3AB) Prosjektgruppe: Intern veileder: Oppdragsgiver: Kontaktperson: Emine Göcmenoglu Høgskolen i Oslo Pb 4 St. Olavs plass, 0130 Oslo Tlf: E-post: postmottak@hio.no Thor E. Hasle E-post: Thor.Hasle@iu.hio.no Tlf: Om bedriften Høgskolen i Oslo (HiO) ble opprettet 1. august 1994 og er landets største statlige høgskole. HiO har over studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og 18 masterstudier. I tillegg tilbyr skolen et doktorgradsprogram i profesjonsstudier. Flere av høgskolens utdanningstilbud er HiO alene om å tilby i Norge. HiO satser på internasjonal utveksling. Forskning er vektlagt, og mye av fag- og forskningssamarbeidet skjer på internasjonalt nivå. 1.3 Bakgrunn for oppgaven Hva er TimeEdit? TimeEdit er en frittstående kommersiell aktør som leier ut bookings- og planleggingssystem til Høgskolen i Oslo. 5

6 Dette systemet består av: En database som kjører på TimeEdit-klienter som er installert hos enkelte brukere slik at de kan koble seg til databasen. WebTimeTables som viser timeplaner og reservasjoner på en web-side. WebReservations som benyttes til å reservere utvalgte rom både for studenter og tilsatte. Avdelingens timeplanleggere/kursplanleggere må ha tilgang til TimeEdit ved et program / en klient, TimEdit-klienten. Brukerne opprettes manuelt av teknisk ansvarlig for TimeEdit. Nærmeste leder kontakter it-tjenesten for dette. Når en ny bruker opprettes får brukeren det vanlige HiObrukernavnet og -passordet også i TimeEdit. WebTimeTables er tilgjengelig for alle, og kan benyttes til å søke opp timeplaner for enkelte klasser, forelesere eller fag. Det kan også benyttes for å sjekke om rom er ledige. Hver avdeling har sin egen søkeprofil som gir tilgang til å søke i avdelingens rom og klasser. De fleste avdelinger har linker på sin hovedside til "ferdige" timeplaner for sine klasser WebReservations benyttes til å reservere utvalgte auditorier, klasserom, møterom og grupperom. Hvilke rom som er tilgjengelig for reservasjon avgjøres av avdelingen. Noen rom er tilgjengelig for alle, noen for en enkelt avdeling, noen for tilsatte og noen for studenter. Web reservasjoner skal ikke benyttes for timeplanlegging, men for reservasjon av rom for en kort periode. Situasjonen ved prosjektstart Høgskolen har mange elever og tilbyr undervisning i en rekke forskjellige fag. Derfor er det behov for en oversikt over hva som til enhver tid foregår i de ulike undervisningslokalene, slik at studenter på skolen når som helst kan finne denne informasjonen. Per dags dato finnes det ingen løsning av den typen som er gitt oss i oppdrag. De studentene som i dag vil søke opp undervisningsinfo, må benytte en webside som gir enkelte visningsalternativer. Studenter mener at denne løsningen er mangelfull og vanskelig å bruke, og mange lar derfor være å benytte seg av den. Alle romreservasjoner gjøres på TimeEdits side. For å gjennomføre en reservasjon må du først finne et ledig grupperom i ønsket tidsintervall. Det som gjør denne siden vanskelig for mange studenter er nettopp det; Det finnes ingen søkefunksjoner for ledige grupperom. Studentene må gå inn og se på hvert enkelt rom i systemet for å se om det er ledig for reservasjon. Den eksisterende romreservasjonssiden er vist i figur 1. Vår applikasjon skal forenkle situasjonen for studenter som trenger å sette seg på et grupperom. De skal enkelt kunne se hvilke rom som har blitt reservert og hvilke som er ledige ved å bruke vårt system. Systemet er selvfølgelig ikke bare basert på problemet med å finne et ledig grupperom, men vil også være en hjelp til å finne ut hva som til enhver tid skjer i undervisningslokalene. 6

7 Figur 1: Viser alle reservasjonene til det valgte grupperommet. 1.4 Mål Hovedoppgaven til applikasjonen er å vise studentene hvor de forskjellige forelesningene foregår og i hvilke tidspunkt. Ettersom det oppstår store problemer med å finne ledige grupperom på skolen, ønsker vi å bruke et avgrenset felt i applikasjonen til å vise studentene reservasjonsstatusen for grupperommene i området. I tillegg ønsker vi å ha en nyhetsoversikt på siden, for eksempel ved hjelp av en RSS feed. Hovedmål som vi vil oppnå som en gruppe i løpet av prosjektet: Få erfaring med å gjennomføre et stort prosjekt. Få erfaring med å dokumentere et omfattende system. Få erfaring i å samarbeide med en reell oppdragsgiver. Lære å sette opp server. Få erfaring gjennom løsing av de problemene som vil oppstå under utviklingen av systemet. 1.5 Rammebetingelser, hentet fra kravspesifikasjonen Som utviklingsspråk har vi valgt C# kombinert med ASP.NET og Silverlight. Utviklingsplattformen vi har valgt er.net, siden vi nylig har gjennomført et kurs i web-applikasjoner hvor vi brukte dette verktøyet. Vi føler at det er i dette verktøyet gruppen har størst forråd av kunnskaper, og valget falt på.net med denne begrunnelsen. Løsningen vår vil være web-basert, og bestå av én sentral Windows-server som mater en eller flere klienter, heretter kalt stasjon. Stasjonene vil bli den synlige delen av applikasjonen, og skal bestå av en liten maskin med skjerm. Det kreves ikke noe annet av stasjonene enn internettilkobling og en 7

8 nettleser som støtter Silverlight. All prosessering skjer i serveren, og informasjonen sendes ut til stasjonene via internett eller gjennom skolens eksisterende nettverk. Serveren er en maskin satt opp med Windows XP Professional SP3, konfigurert med IIS og med Microsoft SQL Server C# har mange forhåndsdefinerte ressurser, og det er derfor et allsidig språk som er enkelt å bruke i web-baserte løsninger. Det er også et objektorientert programmeringsspråk som er relativt likt Java, som vi har jobbet med i undervisningssammenheng gjennom 3 semestre. Gjennom utviklingen benytter vi programmer som er kommersielle, og ville normalt være nødt til å løse ut lisenser fra Microsoft for å skrive applikasjonen. Imidlertid er Høgskolen i Oslo medlem av et samarbeid, MSDNA (Microsoft Developer Network Academy), som gir studentene tilgang til en rekke Microsoft-produkter for bruk i undervisningssammenheng. Det var derfor mulig for oss å skrive applikasjonen i Visual Studio 2008, et program som vi alle er fortrolige med. Problemstillingen til denne oppgaven går ut på at vi skal hente ut informasjon fra TimeEdit, som er skolens eksterne leverandør av timeplanløsninger. TimeEdit er en kommersiell bedrift, og av forståelige grunner får vi ikke full tilgang til deres systemer. De har heller ikke en eksisterende løsning for å gi oss begrenset tilgang til systemet, og har ingen planer om å lage en slik løsning innenfor den tidsrammen vi har for prosjektet. Det har derfor vært en utfordring å få hentet ut den informasjonen vi trenger i henhold til oppgavens problemstilling, og vi var nødt til å finne en alternativ løsning på dette. 2 Utviklingsmetode Prosjektgruppen består av 4 studenter som har jobbet mye sammen gjennom hele studiet. Vi kjenner hverandre godt, og vet om egne og hverandres sterke og svake sider. På grunnlag av erfaringer fra tidligere prosjektarbeid sammen, har vi utarbeidet vår egen måte å jobbe på. Vi har plukket elementer fra ulike utviklingsmetoder, og kommet fram til en modell som vi mener fungerer veldig bra for vår prosjektgruppe. Her vil vi først forklare litt om utviklingsmetoder og -prosesser som har vært til inspirasjon for oss, og deretter forklare hvordan vi har brukt ulike metoder i utviklingen av vårt prosjekt. 2.1 Generelt om prosjektutvikling En utviklingsprosess baserer seg vanligvis på en utviklingsmetode. Grovt sett kan forskjellige utviklingsmetoder deles inn i lettvektsmetoder og tungvektsmetoder. Lettvektsmetoder passer best for mindre prosjekter med relativt liten bemanning og relativt kort varighet. XP (extreme Programming) trekkes ofte fram som eksempel på en lettvektsmetode. Tungvektsmetoder er motsetningen, og passer best for større prosjekter med relativt stor bemanning (eventuelt delt opp i flere team) og lengre varighet. RUP (Rational Unified Process) er mye brukt som eksempel på en tungvektsmetode. 2.2 Om utviklingsprosesser En sekvensiell utviklingsprosess bygger på at man gjør seg helt ferdig med hvert steg i utviklingen før man går videre til neste steg. Hele prosessen består av én sekvens delt opp i flere steg som gjøres 8

9 ferdig hver for seg. Et av de enkleste eksempler er en prosess som først tar for seg analyse, deretter design, så koding, og til slutt ferdigstilling/utplassering. En iterativ utviklingsprosess kjennetegnes av gjentakende metodikk man gjentar en tidligere sekvens med metodesteg. Prosjektets første fase kan være bygget opp som en sekvensiell utviklingsprosess, men skal resultere i en tidlig prototype. Deretter går denne prototypen gjennom en eller flere gjentakende faser hvor produktet evalueres, testes og forbedres. En inkrementell utviklingsprosess er delt opp i iterasjoner, og bygger seg derfor større gjennom gradvis utvikling. I hver iterasjon baserer utviklingen seg på det arbeidet som ble gjort i forrige iterasjon. Gangen i produktutviklingen blir da som følger: Analysere noe, designe noe, kode noe, analysere mer, designe mer, kode mer, analysere enda mer, designe enda mer, etc. Inkrementell integrasjon (eller iterativ og inkrementell utvikling) er en utviklingsprosess hvor kode blir skrevet og testet i små enheter (ofte kalt units), og deretter satt sammen til et fullstendig produkt ved å legge til ett element om gangen. 2.3 Om utviklingsmetoder (Den forenklede) fossefallsmodellen er strengt sekvensiell. Den er normalt beskrevet som én sekvens bestående av de fire stegene analyse, design, koding og ferdigstilling. Fossefallsmetoden slik den vanligvis blir framstilt tar utgangspunkt i at man ikke går tilbake til et tidligere steg etter at det er ferdigstilt, og den blir derfor kritisert for å ikke ha noen vei tilbake, altså at man ikke kan endre på ting som er gjort i et tidligere steg. Figur 2: Forenklet fossefallsmodell 9

10 Den opprinnelige fossefallsmodellen var mer kompleks og hadde flere steg enn den forenklede framstillingen. Den åpnet også for å gå tilbake til et tidligere steg dersom man så et behov for å gjøre endringer, selv om også den i utgangspunktet var sekvensielt konstruert. Figur 3: Opprinnelig fossefallsmodell RUP (Rational Unified Process) er en sterkt definert sekvensiell utviklingsmetode, men den skiller seg fra fossefallsmodellen hva gjelder innholdet i hvert steg. RUP har fire definerte faser (steg), hvor hver fase skal resultere i en ny versjon eller prototype av programmet, og prosessutviklingen skal foregå som en iterativ prosess. Framdriften styres av milepæler, hvorav de viktigste er overgangen fra en fase til en annen. XP (extreme Programming) prøver å redusere kompleksiteten med å følge en spesiell utviklingsprosess. Det er et mål å gjøre minst mulig unødvendig dokumentasjon, og på dette punktet er XP et motstykke til den omfattende dokumenteringen RUP skal resultere i. XP bygger på inkrementell utvikling, og det er stor åpning for å gå tilbake og endre på tidligere implementerte funksjoner. Det er stort fokus på personlig motivering og at alle programmererne skal ha en eierskapsfølelse til produktet som utvikles. Spiralmodellen kombinerer sekvensiell og iterativ utvikling ved at den består av en rekke iterasjoner, hvor hver enkelt har et sekvensielt forløp. En av fordelene som oppnås med dette, er redusert risiko gjennom at man tidlig får et fungerende produkt med få funksjoner, og prosjektet kan dermed avsluttes på kort tid og uten for store tap. Ulempen med spiralmodellen kan være at det blir vanskeligere å si nøyaktig hvor lang tid det vil ta før produktet er ferdig utviklet, og det kan derfor være en økonomisk risiko knyttet til denne løsningen; Tid er som kjent penger. 10

11 Figur 4: Spiralmodell Timeboxing, eller tidsstyring, er en måte å begrense den økonomiske usikkerheten ved utvikling etter spiralmodellen. Denne metoden bygger på at utviklerne får en definert tidsperiode til rådighet, og kunden angir et ønske om hvor mye funksjonalitet produktet skal inneholde. Rekker utviklerne ikke å implementere all funksjonaliteten innenfor den gitte tidsrammen, leveres produktet imidlertid med den grad av funksjonalitet som den tilgjengelige tiden strakk til for. Bruk av timeboxing gjør det mulig, allerede før prosjektet starter, å komme til enighet om en fast pris for det ferdige produktet, så lenge kunden er tilfreds med å motta det produktet som leveres etter endt tid. For noen oppdragsgivere er det enda viktigere at timeboxing gjør det mulig å bestemme et absolutt tidspunkt for lansering av produktet. Man kunne tenke seg at et flertall av alle prosjekt burde sorteres under kategorien timeboxing, siden de fleste opererer med en tidsfrist. Noen av prosjektene tillater imidlertid forskyving av denne tidsfristen, selv om det sannsynligvis vil være uheldig for prosjektets økonomi. Ekte timeboxing har derimot en absolutt frist, og det gjelder å skape et best mulig produkt før fristen går ut. De fleste skoleprosjekt (herunder dette hovedprosjektet) er av typen ekte timeboxing, og resultatet blir vurdert ut fra hva som er levert innen tidsfristen. 2.4 Om vårt prosjekt utviklingen av RomSys Vi har hatt som utgangspunkt at prosjektet skal utvikles med inkrementell integrasjon. Prosessen ble planlagt som 6 iterasjoner (noe som senere ble endret til 7, da vi fant ut at prosessen ble mer oversiktlig av å dele opp iterasjon 1 og heller behandle den som to enkeltstående iterasjoner.) Hver iterasjon er en egen enhet når man snakker om inkrementell integrasjon, og følgelig ble de enkeltvis testet og implementert i applikasjonen. Av praktiske årsaker fant vi det i enkelte tilfeller hensiktsmessig å arbeide med flere applikasjoner parallelt, men de ble likevel implementert enkeltvis og etter numerologisk rekkefølge. Ved prosjektstart hadde gruppen en overordnet planleggingsfase før det vi regner som utviklingsfasen. Denne overordnede planleggingen var nødvendig med tanke på at vår oppdragsgiver 11

12 hadde et ønske og en idé, men ingen definerte krav til funksjon. Det var derfor viktig å få en større oversikt og grovmasket definisjon av selve oppgaven før vi kunne tenke på utvikling av en applikasjon. I denne fasen hadde vi tidvis hyppige møter med HiO som oppdragsgiver, og her fikk vi blant annet greie på at høgskolen mente vi som prosjektgruppe stod veldig fritt til å ta avgjørelser angående applikasjonen. HiO mente at vi, som selv var studenter, visste best hva som ville være til nytte i en applikasjon som først og fremst skulle bli et hjelpemiddel for studentene ved høgskolen. Likevel har det vært viktig for oss å ha en dialog med oppdragsgiveren gjennom hele prosjektet, og de større avgjørelsene ble gjort ved at prosjektgruppen forklarte situasjonen til oppdragsgiver og la fram et forslag til løsning, mens oppdragsgiver på bakgrunn av dette har tatt selve avgjørelsen. Etter den overordnede planleggingsfasen, kom det vi har valgt å kalle utviklingsfase. Denne startet igjen med en planlegging, definisjon av kravspesifikasjoner og skissering av funksjonalitet. Imidlertid hadde vi fokus på tidlig programmering framfor tidlig dokumentasjon en idé som blant annet er uttrykt i utviklingsmetoden AUP (Agile Unified Process) og det var derfor bare de nødvendige styringsdokumenter som hadde hovedprioritet før programmeringen kunne starte. Det som kan kalles programmeringsfasen, har på mange måter også inneholdt planlegging og evaluering; Vi har tatt utgangspunkt i spiralprinsippet innenfor hver iterasjon planlegging, koding og evaluering, og eventuelt gjentagelse av disse tre punktene dersom iterasjonen ikke er klar til å implementeres. Iterasjonene har blitt lagt til applikasjonen i numerologisk rekkefølge, men samtidig har vi vært åpne for å gå tilbake og forbedre en tidligere iterasjon i de tilfellene et slikt behov har meldt seg. Etter implementering av hver iterasjon har vi testet hele systemet med de nye funksjonene. I tillegg ble hver funksjon i den grad det lot seg gjøre testet før implementering. Parallelt med programutviklingen, har vi arbeidet med den tilhørende dokumentasjon. Det har for oss vært et mål å unngå dokumentasjon som ikke tjener noe formål, i tråd med tankegangen man finner i utviklingsmetoden XP. Samtidig er prosjektet utført som bacheloroppgave / hovedoppgave i et studium ved HiO, og dette legger noen føringer for hva slags dokumentasjon som må medfølge. Vi har fått en dokumentasjonsstandard som skal følges, og selv om denne er åpen for individuelle tilpasninger, inneholder den retningslinjer man må ta hensyn til. Den første iterasjonen (iterasjon 0) inneholdt nødvendigvis en betydelig andel planlegging og dokumentasjon; vi hadde behov for å skape en overordnet skisse av applikasjonen før den kunne utvikles. Samtidig kom vi tidlig i gang med utvikling av de funksjonene vi allerede her innså var nødvendige for et fungerende sluttprodukt. I de følgende applikasjoner kunne vi i større grad fokusere på programmering, selv om også disse startet med planlegging. Iterasjon 5, som var den siste iterasjonen, ble i stor grad satt av til testing av applikasjonen, til tross for at testing har hatt fokus gjennom hele utviklingsprosessen. Her ønsket vi å bruke tid til sluttesting av det ferdige systemet, for å forsikre oss om at det fungerte etter planen. I tillegg skulle iterasjonen brukes til ferdigstilling, det vil si alt avsluttende arbeid, eventuelle feilrettinger og visuell tilpasning. 12

13 3 Forberedelser, planlegging og prosjektstyring 3.1 Valg av hovedprosjekt (prosjektstart) Vi i prosjektgruppen har arbeidet sammen i forbindelse med gruppeprosjekter siden 1.klasse og visste at vi ville få et godt samarbeid. Vi hadde derfor lyst å danne hovedprosjektgruppen sammen, og gjøre et mest mulig effektivt arbeid ut av det. I første omgang hadde vi ingen planer om hvem vi skulle arbeide for, men utvikling av et WEB-system med kombinasjon av flere språk kunne være et relevant oppdrag for oss. Det gikk ikke så langt tid før vi ble enige om oppgaven. Kort tid etter at prosjektforslagene var lagt ut på hovedprosjektsiden, hadde vi møte som prosjektgruppe. Her diskuterte vi ulike oppgaver vi kunne tenke oss, både internt gitte (fra HiO) og eksternt gitte (fra andre bedrifter). Oppdraget visning av romfordeling stod blant de prosjektforslagene som er gitt fra Høgskolen i Oslo, og dette syntes vi virket interessant. Dette var et reelt prosjekt som man kunne ha fått i arbeidslivet. Gruppen ønsket å utvikle et WEB-system med kombinasjon av flere språk, og oppdraget tilsvarte våre ønsker. Med åpent krav om funksjonalitet kunne vi utvikle og designe produktet etter vårt eget ønske. Vi kontaktet først vår oppdragsgiver HiO v/kontaktperson Thor Hasle for å vite mer om oppdraget og om dets funksjonalitet og krav, og underveis i møtet bestemte vi oss for at vi ønsket dette oppdraget Kort tid etter samtalen med Thor Hasle, fikk vi beskjed fra HiO om at oppgaven var vår. Dette gikk i orden tidsnok til å levere en prosjektskisse innen den gitte fristen, 5.desember Oppdragsgiver hadde ikke formulert noen kravspesifikasjon, og derfor begynte vi å jobbe med dette rett etter nyttår. Allerede første uken av januar hadde gruppen et møte om planlegging av prosjektet, hvor vi blant annet diskuterte hvordan systemet skulle se ut og hvilken funksjonalitet det kunne inneholde. Uken deretter hadde vi vårt første møte med intern veileder, Emine Göcmenoglu. 3.2 Tilrettelegging fra oppdragsgiver I følge oppdraget vi har fått fra oppdragsgiveren, var oppgaven å etablere skjermer i hver etasje som viste hvilke rom som skulle brukes av hvem og når. Det skulle da utvikles en applikasjon som leste data fra TimeEdit og viste disse på hensiktmessig måte på en eller flere skjermer per etasje. Men akkurat hvordan systemet skulle se ut var opp til oss Vi sto ganske fritt til å utforme annen funksjonalitet og bestemme utseende på det ferdige produktet. Oppdragsgiveren ba oss komme med egne løsninger og forslag til funksjonalitet, valg av teknologi og plassering av skjerm. Vi avgjorde i stor grad selv hvilke funksjonaliteter som ville være hensiktmessig for vår applikasjon. Applikasjonen skulle etter ønske fra skolen være åpen for videreutvikling på et senere tidspunkt. 3.3 Valg av løsning og teknologi På den måten oppgaven vår var definert la oppdragsgiver ingen føringer for valg av teknologi, og det var i stor grad opp til oss hvordan det ferdige produktet skulle se ut. Oppgaveteksten var som følger: Ingeniørutdanningens ledelse har ytret ønske om å etablere skjermer i hver etasje som viser hvilke rom som brukers av hvem når. Det må da utvikles en applikasjon som leser data fra TimeEdit og som viser disse på en hensiktsmessig måte på en eller flere skjerm per etasje. Etter å ha spurt oppdragsgiver om dette, fikk vi vite at de ikke hadde noen krav eller ønsker om hvilken plattform applikasjonen skulle leveres i, så vi som prosjektgruppe sto helt fritt til å velge 13

14 teknologier og programmeringsspråk. Oppgaveteksten gir også stor grad av frihet til programutviklerne, men det kommer fram at løsningen må være tilknyttet internett. TimeEdit er skolens eksterne leverandør av timeplanløsninger, og de har en nettside hvor man kan få listet opp nødvendig informasjon for den nærmeste tiden. Med dette grunnlaget var det naturlig å bruke en web-basert løsning, og vi valgte da å bruke.net som plattform..net er en samling av teknologier rundt programvareutvikling fra Microsoft, og er i dag en av de mest brukte utviklingsplattformene i verden. Dette passet bra med vårt læringsmål, som var å få større kunnskaper om en mye brukt og ettertraktet teknologi. En positiv bieffekt av dette er at produktet er enkelt å videreutvikle ved en senere anledning, med tanke på at det finnes et stort antall programmerere med.net-kompetanse. I tillegg hadde vi i prosjektgruppen nylig gjennomført et kurs som omhandlet.net-teknologien, og følte derfor at vi hadde grunnleggende kunnskaper om denne utviklingsplattformen. Det betyr på ingen måte at vi manglet utfordringer i arbeidet med prosjektet; Vi måtte lære nye måter å bruke teknologien på, og måtte også tilegne oss kunnskaper ut over det grunnleggende for å utvikle applikasjonen vår. Som programmeringsspråk var det naturlig å velge C# når vi skulle jobbe i.net-plattformen. Dette er et foretrukket språk når man arbeider med.net-teknologien, og prosjektgruppen hadde derfor vært borti språket i det nevnte kurset. C# er et allsidig programmeringsspråk som er objektorientert og har likheter med Java. Programmering i Java hadde vi jobbet med i flere fag fordelt over 2 år, og med kunnskaper om dette språket var det lettere å tilegne seg ferdigheter i C#. ASP.NET er Microsoft sitt rammeverk for utvikling av dynamiske web-applikasjoner, og dette programmeringsspråket var en naturlig valg for presentasjonslaget i applikasjonen vår. Silverlight er et rammeverk som muliggjør integrering av multimedia, grafikk, animasjoner og interaktivitet i web-applikasjoner. Programmering i Silverlight gir produktutviklerne større muligheter til tilpasning av visuell fremstilling enn det som oppnås med vanlig HTML-koding. Med andre ord gir det oss mulighet til å tilpasse applikasjonens utseende på en måte som er uavhengig av ytre påvirkninger, som for eksempel hvilken nettleser brukeren velger å kjøre applikasjonen i. Løsningen vår består av én web-server og en eller flere klienter, heretter kalt stasjon. Stasjonene vil bli den synlige delen av applikasjonen, og skal bestå av en liten maskin med skjerm. Det kreves ikke noe annet av stasjonene enn internettilkobling og en nettleser som støtter Silverlight. All prosessering skjer i serveren, og informasjonen sendes ut til stasjonene via internett. Systemet er åpent, og det er i prinsippet mulig å vise applikasjonen på private hjemmemaskiner koblet opp mot internett, forutsatt at man kjenner URL-adressen applikasjonen ligger på. Det er derfor mulig for studenter å kjøre applikasjonen vår hjemmefra hvis skolen åpner for dette ved å frigjøre URL-en. Studentene kan da velge hvilken stasjon de vil se informasjon fra, og får se informasjon som finnes for den valgte stasjonen. Dette utgjør ingen risiko for systemet, i og med at studentene bare kan velge å vise forhåndsdefinert informasjon. All endring av systemet krever innlogging og kan bare gjøres av administrator. 3.4 Organisering Fasene i prosjektet med programmering og prosjektering, krevde en større og mer formalisert organisering av prosjektet i gruppen med tilhørende beslutnings- og ansvarsfordelinger. For å 14

15 arbeide i tråd med dette, utarbeidet vi en fremdriftsplan. Det skulle være lov å ligge foran i fremdriftsplanen, men det var ikke ønskelig å ligge bak denne. Alle på gruppen skulle holde seg orientert om prosjektets fremdrift og innhold. Hver tirsdag, onsdag og eventuelt torsdag, har vi hatt fast møtetid på HiO, hvor vi har arbeidet sammen i flere timer. For gjennomføring og kvalitetssikring av prosjektets innhold, har denne faste møtetiden vært svært viktig for hele gruppen. Vi førte ikke opp antall timer vi brukte til dokumentasjonen og til selve applikasjonen per dag, men dette prosjektet har hatt hovedfokus gjennom et helt semester. Andre fag vi hadde i tillegg til hovedprosjektet, måtte i noen tilfeller påvirke hvor mye tid vi brukte på dette prosjektet, men de har i liten grad hindret den generelle progresjonen. Enkelte dager har vi møttes på skolen for arbeidsøkter på opp til 10 timer, hvor vi kun har jobbet med hovedprosjektet. Det kan ha gått noe roligere enkelte uker, da andre fag periodevis har stilt store krav til økt arbeidsinnsats, men vi har hele tiden klart å holde oss innenfor fremdriftsplanen. 3.5 Hjemmeside Det var et krav fra skolen at vi skulle opprette en prosjekthjemmeside. Denne har vi etterstrebet å bruke til å holde oss selv og vår veileder oppdatert med informasjon. Vi opprettet en enkel og oversiktlig side, hvor ulike dokumenter ble vist etter kategori i en tabellform. 3.6 Prosjektstyring Prosjektdagboka har helt fra starten vært et ledende dokument. Den er kanskje ikke så veldig langt og detaljert, men tilskrekkelig nok til å gi oss informasjon om hva som til enhver tid har blitt gjort av gruppen gjennom hele prosjektperioden og eventuelt hvilke problemer som har oppstått For hvert møte registrerte vi dag, tid og sted, og det som var verdt å huske. På denne måten kunne veilederen følge utviklingen dag for dag med tenking, utvikling og resultater. Under dokumenteringen av denne prosessrapporten har vi hatt stor nytte av dagboka; Den har vært hovedkilden til resten av prosessdokumentasjonen siden alt var samlet og notert der. Kommunikasjonen har stort sett foregått over internett og SMS. Dokumenter har blitt sendt fram og tilbake på e-post, og beskjeder ble gitt på SMS. Vi så dette som en god løsning for å ta vare på dokumenter, og samtidig en måte å sikre at alle mottok de enkelte dokumenter. Siden vi er 4 i gruppen, fikk vi med andre ord 4 backup-er av det aktuelle dokumentet og sannsynligheten for at ting går tapt blir dermed mindre. 3.7 Anvendt programvare I tillegg til hovedmålet med prosjektet å lage en fungerende applikasjon for oppdragsgiver har det vært et mål at prosjektgruppen skulle få større kunnskap om bruken av relevant teknologi. For å utvikle vårt produkt RomSys har vi brukt den programvaren som er beskrevet her. Selv om vi kjente til all programvaren fra før, har vi gjennom prosjektarbeidet fått mye ny kunnskap om hvordan den kan brukes. All programvare vi bruker er proprietær (lisensiert) programvare fra Microsoft. Lisensene til disse programmene har vi fått fra MSDNA (Microsoft Developer Network Academy), et samarbeid som HiO er medlem av og som gir studentene tilgang til en rekke Microsoft-produkter for bruk i undervisningssammenheng. 15

16 Microsoft Visual Studio 2008 Dette er en IDE (Integrated Development Environment) for.net-rammeverket. Visual Studio inkluderer blant annet en code editor (skriveprogram for datakode) som støtter IntelliSense (Microsofts autofullfør-funksjon for skriving av datakode), en debugger (feilsøkingsfunksjon) og en kompilator, og denne programvaren har vært vårt viktigste verktøy under utviklingen av RomSys. SILVERLIGHT 3 TOOLKIT FOR VISUAL STUDIO 2008 SP1 Dette er en plug-in til Visual Studio som muliggjør bruken av Silverlight-kontroller og -verktøy i applikasjoner som utvikles med denne programvaren. Microsoft Expression Blend 3 Dette er en programvare for utvikling av grafisk brukergrensesnitt for web-applikasjoner. Det er et interaktivt WYSIWYG-verktøy for utforming av XAML-basert grensesnitt. (WYSIWYG står for What You See Is What You Get, og henspiller på at innholdet som vises under redigering er svært likt det endelige resultatet.) Microsoft SQL Server 2005 Dette er en databaseserver for relasjonsmodellerte databaser. Denne programvaren fulgte med installasjonen av Microsoft Visual Studio 2008, og derfor valgte vi å benytte dette databaseverktøyet. 3.8 Anvendte rammeverk og programmeringsspråk ASP.NET, C# og Silverlight ASP.NET er et rammeverk som er utviklet av Microsoft for å la programmerere bygge dynamiske web-applikasjoner. Dette rammeverket muliggjør utvikling med alle språkene i.net-teknologien. C# er et objektorientert programmeringsspråk som er foretrukket for.net-rammeverket. Silverlight er et rammeverk for web-applikasjoner, og integrerer multimedia, grafikk, animasjoner og interaktivitet i et enkelt kjøringsmiljø. XML Extensible Markup Language er et universelt og utvidbart markeringsspråk. XML muliggjør deling av strukturerte data mellom flere informasjonssystemer. Det brukes også til koding av dokumenter og for kommunikasjon mellom ulike dataformater. Formatet er vanlig tekstformat, og dette bidrar til at innholdet er leselig også for mennesker. LINQ Language Integrated Query er en komponent i.net-rammeverket som forenkler bruken av spørresetninger i.net-språkene. Ved å bruke LINQ, kan man unngå SQL-spørresetninger, og i stedet skrive spørringene i C#. Spørresetningene kan brukes til å søke opp, filtrere og hente ut data i databaser eller XML-filer. Ved å skrive spørresetningene i C# fremfor SQL, oppnår vi to fordeler: For det første eliminerer vi risikoen for SQL-injections; I tillegg oppnår vi bedre struktur ved å holde oss til kun å bruke C# i programkoden. Regular Expression Regular Expressions (regelmessig framstilling), refereres også til som regex eller regexp, tilfører i databehandling en kortfattet og fleksibel måte for matching av tekst. Regex kan identifisere spesielle bokstaver, ord eller et mønster av bokstaver. En regular expression er skrevet i et språk som kan 16

17 tolkes av en regular expression processor, et program som enten fungerer som en parser generator eller undersøker tekst og identifiserer deler som samsvarer med en gitt spesifikasjon. Regular expression brukes i mange tekstbehandlingsprogrammer, hjelpesystemer og programmeringsspråk til å identifisere og behandle tekst basert på mønstre. Skriptspråk som Perl, Ruby og Tcl har en regex-motor innebygd i sin syntax. Windows PowerShell Windows PowerShell er et oppgavebasert kommandolinjeskall og skriptspråk, som særlig er tiltenkt systemadministratorer. PowerShell inkluderer interaktiv prompting og et skriptmiljø som kan benyttes uavhengig. I lang tid har Windows fokusert på det grafiske grensesnittet, mens kommandolinjen og automatiseringsmulighetene med script ikke har hatt den høyeste prioriteringen. Løsningen som Windows tidligere hadde var svært avansert, og inkluderte mange uavhengige grensesnitt som ikke nødvendigvis fungerte på tvers av hverandre. Windows PowerShell er et mye mer komplett system, og er derfor en stor forbedring på dette punktet. PowerShell miljøet er like interaktivt som BASH, like programmerbart som Perl og produksjonsorientert. Dette er det beste av det beste. PowerShell er også bygd på.net, vi får dermed objekter til miljøet. Vi får referanser til prosessene, og med disse referansene kan vi jobbe med utdataene på en helt ny måte, hvor vi aktivt kan utføre handlinger på utdataene vi får. IIS Internet Information Services, tidligere kalt Internet Information Server, er en webserver-applikasjon og sett av funksjonsmoduler som er skapt av Microsoft for bruk med Microsoft Windows. Den er en av de mest populære webservere i verden. I mars 2010 betjente IIS 24 % av alle websider. Protokollene som støttes av IIS 7 inkluderer: FTP, FTPS, SMTP, NNTP og HTTP/HTTPS. 3.9 Fremdriftsplan og arbeidsplan Fremdriftsplanen ble satt opp tidlig i prosjektet. Sammen med denne ble det også utarbeidet en god, strukturert arbeidsplan som iterasjon for iterasjon viste arbeidet som skulle gjøres fra start til prosjektavslutning. Begge dokumentene er vedlagt. 4 Kravspesifikasjon Her gjengis kravspesifikasjonen i sin helhet, slik den har blitt nedtegnet tidligere i prosjektarbeidet. Talemåten her vil derfor kunne avvike noe fra den øvrige dokumentasjonen, og noe informasjon kan virke overflødig. 4.1 Om bakgrunnen Høgskolen i Oslo (HiO) er landets største statlige høgskole med studenter. HiO tilbyr både bachelor- og masterstudier, og ett doktorgradsprogram. Høgskolen har mange elever og tilbyr undervisning i en rekke forskjellige fag. Derfor er det behov for en oversikt over hva som til enhver tid foregår i de ulike undervisningslokalene. 17

18 Prosjektet skal resultere i et program som enkelt viser hva som til en hver tid skjer i et gitt område av skolen. Vi ønsker i tillegg å implementere en nyhetsoversikt i programmet. Programmet skal gjøre det mulig å sette opp skjermer som viser timeplanen for et område, for eksempel en gitt etasje. 4.2 Hensikten med kravspesifikasjoner Hovedhensikten med kravspesifikasjonen er å sette krav til funksjonaliteten for vårt produkt, RomSys. Kravene setter rammer og begrensninger, og vi får en oversikt over hvilke funksjonaliteter som skal implementeres. Tanken bak dette dokumentet er å gjøre det enklere for sensor og veileder å evaluere prosjektet. I tillegg vil det være et styringsdokument for oss gjennom hele prosjektarbeidet. Formulering av kravene har blitt satt underveis i prosjektet, både av oss og arbeidsgiver. 4.3 Kort systembeskrivelse Timeplan Sluttproduktet skal vise en timeplan, sortert på hvilket rom den aktuelle hendelsen foregår i. For forelesningssaler skal systemet vise informasjon om den nåværende forelesningen (fag, starttid, sluttid og hvor forelesningen foregår), samt en liste over de neste forelesningene som skal foregå i samme rom (med fag og start- og sluttid). For lab-rom (eksempelvis data-lab) skal det være en tilsvarende visning. I tillegg skal programmet inneholde en liste over grupperom, samt vise om disse er reserverte eller ledige. Nyheter Sluttproduktet skal ha en form for nyhetsvisning med nyheter som er aktuelle for HiO. Dette kan gjøres ved hjelp av en eller flere av HiOs egne RSS-feed. Annet Sluttproduktet skal inneholde en logo, klokke og dato/kalender. 4.4 Eventuelle krav til systemkonstruksjon (tekniske krav) Utvikling Som server har vi valgt å bruke en maskin med operativsystem Windows XP Professional SP3. Maskinen som brukes som server skal være satt opp med IIS for at den skal kunne brukes som webserver, og Microsoft SQL Server 2005 (medfølgende i installasjonen av Visual Studio 2008) som vi bruker i arbeidet med database. Som plattform bruker vi.net, med hovedvekt på ASP.NET kombinert med C# som programmeringsspråk. For det visuelle bruker vi Silverlight 3. Som utviklingsplattform for applikasjonen har vi valgt Visual Studio 2008, og for å utvikle databasen må vi bruke en extension til Microsoft SQL Server Drift Programmet skal være mest mulig selvgående. Det skal være en innloggingsside med mulighet for enkel administrasjon av programmet. 18

19 Når programmet er i drift, skal det være mulig å definere et nytt område, og velge hvilke rom som skal inngå i dette området. Hver stasjon skal settes opp for å vise et område, applikasjonen skal kjøre automatisk når dette først er gjort. Planen er at konfigurasjonen skal settes opp én gang, og ikke kreve øvrig vedlikehold uten hvis det er ønskelig å opprette nye eller slette gamle rom/områder. Utstyr For hver stasjon som skal driftes, trenger man en widescreen skjerm, en PC med internettilkobling og nettleser som støtter Silverlight 3. I tillegg trenger systemet én maskin satt opp med Windows XP Professional SP3 og IIS. 4.5 Eventuelle krav til dokumentasjon Alle gruppene er pålagt å følge en dokumentasjonsstandard: Torvatn, A. M. (2007) "Hovedprosjekter i data/it - Dokumetasjonsstandard". Dokumentasjonsstandarden er utarbeidet av førstelektor Ann-Mari Torvatn. Hun har i mange år undervist faget "Menneske-maskin-interaksjon" og har samtidig utarbeidet et kompendium for faget. Denne dokumentasjonsstandarden er et bearbeidet utdrag fra kompendiet. Ann-Mari Torvatn gikk av med pensjon per 1. januar Hvis det skulle være spørsmål i tilknyting til dette kan hun nås via epostadressen annmari.torvatn@senior.hio.no 5 Utviklingsprosess og gjennomføring 5.1 Kravspesifikasjonens rolle i utviklingsprosessen Hovedhensikten med kravspesifikasjonen er å sette krav til funksjonaliteten for vårt produkt. Oppdragsgiver hadde ingen formulerte krav da vi startet, med hadde et ønske om noen funksjoner som skulle dekkes av applikasjonen. Det ble derfor viktig for oss å utarbeide en kravspesifikasjon før vi kunne gå i gang med programmeringen, ellers ville vi risikert å skrive ubrukelig kode fordi vi ikke visste hva som var målet med applikasjonen. Kravspesifikasjonen måtte utarbeides så tidlig som mulig, sånn at programmeringen kunne starte uten for store forsinkelser. Den ble derfor et viktig dokument allerede fra starten av prosjektet. Vår kravspesifikasjon ble først satt opp punktvis og i stikkordsmessig form, og deretter utarbeidet for å tilfredsstille forventningene til et slikt dokument. Den har blitt et av våre viktigste verktøy for å vite hva vi skulle tilføye av funksjoner i applikasjonen, og har blitt nøye fulgt opp og tilpasset for til enhver tid å representere oppdragsgivers ønsker om den ferdige applikasjonen. Vi mener at vi har klart å følge kravspesifikasjonen hele veien, og at applikasjonen vi presenterer er i tråd med dette dokumentet. 5.2 Use Case-modellens rolle under utviklingsprosessen Det har blitt laget use case modeller og beskrivelser for praktisering av krav der vi følte dette har vært hensiktsmessig. Oppdragsgiveren har ikke hatt noe ønske om eller krav om at UML skulle brukes i det hele tatt, men vi fikk en anbefaling fra intern veileder om å lage use case modeller. Use Case modellen har vært nyttig under opprettelsen av administrasjonssidene. Modellen gjorde at vi enkelt fikk oversikt over hvilke funksjoner som skulle legges til og hvordan 19

20 funksjonene måtte kodes, hvilke typer administrator som skulle ha tilgang til de ulike funksjonene, samt likheter og ulikheter mellom de to ulike administrator-typene. Det var use case modellen som inspirerte oss til å lage to forskjellige innloggingssider det er typen administrator-bruker som avgjør hvilken side innlogget bruker kommer til. Til use case modellering har vi brukt programmet Violet UML Editor. For mer informasjon om diagrammer og beskrivelser vennligst se vedlegg om Usecase Modeller. 5.3 Veiledning og samarbeid Samarbeidet vårt med veilederen, Emine Gøcmenoglu, har vært veldig godt gjennom hele perioden. Hun har alltid vært villig til å møte oss og stilt opp når vi har hatt behov for det. Til å starte med, etter et forslag fra Emine Gøcmenoglu, bestemte vi oss for å ha en fast møtetid med henne hver onsdag. Denne avtalen varierte litt etter hvert som vi kom i gang med prosjektet, når det gjelder dag og tid, og i noen perioder har vi henvendt oss til henne bare ved behov. Dersom det var noe vi sto fast på eller ønsket mer informasjon om, har hun vært flink til å komme med gode og raske tilbakemeldinger. Med andre ord kan vi kort og godt si at Emine har vært en god veileder for oss. 5.4 Presentasjonsmøte med veileder, oppdragsgiver og faglærer i.net Med veilederens hjelp arrangerte vi et møte til den 09/03-10 for å presentere vår applikasjon til oppdragsgiver og Tor Krattebøl. Tor Krattebøl underviser i.net, derfor har vi valgt å invitere ham til presentasjonen. Vi tenkte det kunne være nyttig å ha en faglærer som kunne gi oss innspill og forslag til forbedring av applikasjonen. Under dette møtet fikk vi mange nyttige tilbakemeldinger, hvorav det var en del forbedringsforslag. Alle forslagene ble notert ned, og etter møtet hadde prosjektgruppen et vurderingsmøte hvor vi tok opp hver tilbakemelding for seg. For hvert punkt vurderte vi da nytteverdien av den foreslåtte funksjonen, hvor mye arbeid som måtte til for å implementere den og hvordan det ville påvirke applikasjonen visuelt. Selv om vi fant mulighet til å implementere de fleste foreslåtte funksjoner, var det enkelte av funksjonene vi ikke fant det hensiktsmessig å ta med. Som eksempel kan her nevnes et ønske om at innlogget administrator kunne velge hvor mange undervisningslokaler som skal vises i applikasjonens hovedvindu; det var da tenkt at administrator kunne velge mellom å vise 1, 2, 4, 6 eller 8 undervisningslokaler. (Det er selvfølgelig mulig å vise flere eller færre enn 6 undervisningslokaler med applikasjonen som den er nå også, men da vil det kunne oppfattes som at applikasjonen har et tomrom der det er satt av plass til flere rom; den foreslåtte ideen var derfor at hvert rom skulle vises over et større område hvis administrator valgte å vise kun 2 stykker.) Vi hadde tidligere tenkt på hvor mange undervisningslokaler som var hensiktsmessig å vise, men nå tok vi det opp til ny vurdering. En slik endring ville kreve at vi måtte skrive om store deler av applikasjonen, og derfor valgte vi å tegne opp skjermbildet slik det ville se ut med denne funksjonen før vi begynte å programmere den. Vi klarte imidlertid ikke å finne en måte å vise et annet antall rom uten at vi syntes det påvirket negativt den visuelle oppfatningen av applikasjonen. Dette resultatet, kombinert med den arbeidsmengden det ville kreve, samt at vi ikke kunne komme på noe tilfelle der funksjonen ville ha stor nytteverdi, gjorde at vi valgte å ikke programmere denne funksjonen. Møtet med veileder, oppdragsgiver og den nevnte foreleser resulterte imidlertid også i at vi gjorde noen endringer i henhold til deres forslag. Den første var ganske enkelt et ønske om å vise HiOlogoen på administrasjonssidene. Logoen hadde vi allerede lagt inn i visningsdelen av applikasjonen, men nå ble den lagt til også på innloggings-/administrasjonssidene. Det var også et ønske om at 20

21 administrator skulle kunne velge hvor mange sekunder det skal gå mellom visningen av hvert skjermbilde hvis det er lagt inn mer enn 6 undervisningslokaler. Dette la vi inn som et valg med rullegardin-liste eller drop down list i administrasjonssiden. På møtet ble det også ytret et ønske om at applikasjonen skulle ha en funksjon for å ikke vise grupperom-kontrollen i de tilfeller der stasjonen kun er tilknyttet undervisningsrom. Dette løste vi ved å programmere at applikasjonen automatisk lar være å vise denne kontrollen for en stasjon hvor ingen av de tilknyttede rommene er grupperom. I tillegg har vi gjort noen redaksjonelle endringer av feilmeldinger i applikasjonen som en følge av tilbakemeldingene vi fikk på dette møtet. Videre ble det foreslått at administrator skulle kunne velge om RSS-en skal vises på skjerm eller ikke, og dette tok vi da opp til vurdering. Imidlertid vurderte vi det dit hen at RSS kan være ønskelig for enkelte brukere, og vi kunne ikke komme på noen situasjon hvor det ville være direkte hensiktsmessig å ikke ha denne visningen. I tillegg viste en brukerundersøkelse gjort mot studenter ved datalinjen at flertallet var positive til å få se RSS. I tillegg kom det under møtet et forslag om å fjerne Tilbake til ny stasjonsregistrering -linken fra administrasjonssiden når det har blitt opprettet en ny stasjon. Her er vi uenige, idet vi mener at denne linkens synlighet kan forenkle prosessen med å legge inn flere stasjoner i samme økt. Med tanke på at linken ikke medfører noen som helst ulempe, valgte vi derfor å la denne bli stående. Figur 5: Et skjermbilde av "Ny stasjon" siden 5.5 TimeEdit i vårt prosjekt TimeEdit er skolens eksterne leverandør av timeplanløsninger. Dette er en kommersiell bedrift som tilbyr sin tjeneste til HiO, men har for øvrig ingen tilknytning til skolen. Vår kilde til informasjon om romreservasjoner i dette prosjektet var TimeEdit. Av forståelige grunner kunne vi ikke få full tilgang til deres systemer, og de hadde ingen eksisterende løsning for å gi oss begrenset tilgang til systemene. Det har derfor vært en utfordring å få hentet ut den informasjonen 21

22 vi trenger i henhold til oppgavens problemstilling, og vi var nødt til å finne en alternativ løsning på dette. HiO har heller ingen tilgang til TimeEdit sine systemer, men har en nettside hvor all undervisning kan listes ut. Denne nettsiden har noen få forhåndsprogrammerte valg for sortering, og selv om disse funksjonene normalt er utilstrekkelig for både studenter og skolens ansatte, ga de likevel en mulighet for å hente ut nødvendig informasjon, om enn på en uryddig måte. Figur 6: TimeEdit sin nettside med søkefunksjon 5.6 Hovedutfordringer Her vil vi beskrive de største utfordringene vi møtte på under arbeidet med prosjektet vårt. I tillegg til disse utfordringene, kan det nevnes at vi hadde litt problemer med bruken av IIS i starten. Dette skyldtes imidlertid ikke problemer rundt IIS, men det faktum at vi aldri før hadde arbeidet med denne teknologien. For utfyllende informasjon om hvordan vi løste problemene, henviser vi til iterasjonsbeskrivelsene og produktdokumentasjonen. Innsamling av data Utgangspunktet for vårt prosjekt var annerledes enn det man vanligvis finner for tilsvarende hovedprosjekt. Oppgaven bygger på å vise informasjon fra en database, og normalt finnes det to hovedkategorier av en slik oppgave. Den første kategorien er i de tilfeller databasen er ikkeeksisterende, og den må da bygges som en del av prosjektoppgaven og prosjektgruppen sitter på alle rettigheter; I motsatt fall eksisterer det en database, gjerne administrert av oppdragsgiver, og det finnes måter å gi prosjektgruppen fulle eller begrensede rettigheter. I vårt tilfelle var situasjonen annerledes: Det eksisterte en database, men verken vi eller oppdragsgiver hadde de nødvendige rettigheter for tilgang disse rettighetene eies av TimeEdit, en ekstern bedrift som tilbyr en tjeneste til HiO. Den første utfordringen vår ble derfor innsamling av relevante data. Dette er noe man anser som uproblematisk i de fleste prosjekter, og det regnes derfor ikke for å være en stor oppgave. For oss var dette derimot et problem som måtte løses før vi kunne ta fatt på det man normalt ser på som selve prosjektoppgaven å behandle de innsamlede data og benytte dem i arbeidet med applikasjonen. 22

23 Knytte Silverlight til database En annen utfordring oppstod fordi vi ønsket å utvikle applikasjonen i Silverlight for å få et pent tilpasset brukergrensesnitt. Av sikkerhetsmessige årsaker har Silverlight ingen funksjon for å lese direkte fra en fil eller fra databasen, og dermed hadde vi ingen direkte mulighet til å la Silverlightapplikasjonen benytte de data vi hadde samlet inn, og vi måtte finne alternative måter å gjøre dette på. 6 Iterasjonsbeskrivelse For å kunne gi en lettfattelig beskrivelse av arbeidsprosessen, har vi her valgt å beskrive prosjektets iterasjoner enkeltvis. Vi mener at dette bidrar til en kronologisk og oversiktlig forståelse av arbeidet vi har gjort. Vi planla prosjektet som en prosess bestående av 6 iterasjoner. Underveis i arbeidet innså vi at det ville være mer oversiktlig å dele opp den ene iterasjonen i to enkeltstående deler, og den endelige prosessen ble derfor inneholdende 7 iterasjoner. Flere ganger gjennom prosjektet har gruppen jobbet parallelt med 2 eller flere iterasjoner. Dette har vi gjort av praktiske hensyn, enten fordi det har vært nødvendig å vite hvordan neste iterasjon skulle se ut for å fullføre den iterasjonen vi i utgangspunktet jobbet med, eller fordi det med tanke på tilgjengelig arbeidskraft har vært mest hensiktsmessig at noen startet på neste iterasjon samtidig som andre sluttførte den vi jobbet med. 6.1 Iterasjon 0 Dette er på mange måter den største iterasjonen i prosjektet; Ikke nødvendigvis fordi hver oppgave er spesielt stor eller krevende, men fordi iterasjonen består av mange punkter og omhandler ulike deler av prosjektet. Vi ønsket at den første iterasjonen skulle sette oss inn i alle deler av prosjektet, og den måtte derfor resultere i flere overordnede valg og skisser. Oppgaver: Skissere applikasjonen og funksjonaliteter. Valg av teknologier. Sette opp server og installere programmer. o Operativsystem: Windows XP Pro (SP3) o Remote desktop o IIS o Microsoft Visual Studio 2008 (SP1) o Expression Blend 3 o Silverlight 3 toolkit for Visual Studio 2008 (SP1) o Database: Microsoft SQL Server 2005 Skissere overordnet kravspesifikasjon. Skrape webside til XML: Skrive en applikasjon som kan hente ut data fra TimeEdit sin nettside og lagre de hentede data til en XML-fil. Vurdere ulike utviklingsmodeller. 23

24 Det første prosjektgruppen måtte gjøre, var å skissere hvilken løsning vi skulle lage. Denne skisseringen omfattet blant annet use case-diagrammer, som vi har brukt flere ganger underveis i implementeringsfasen. Oppdragsgiver hadde ikke noen krav eller ønsker til hvilken plattform applikasjonen skulle leveres i, så vi som prosjektgruppe sto helt fritt til å velge teknologier og programmeringsspråk. Ut fra oppgaven vi hadde fått med å hente informasjonen fra TimeEdit sine nettsider, var det naturlig å bruke en web-basert løsning. Vi valgte å bruke Visual Studio som programmeringsverktøy og.net som plattform. Som programmeringsspråk valgte vi å bruke ASP.NET, C# og Silverlight. Når vi hadde valgt å bruke en web-basert løsning, var det klart at vi trengte vi en web-server. Ettersom vi også hadde valgt å bruke.net, måtte vi bruke IIS (Internet Information Services). Det var naturlig å bruke Microsoft Windows som operativsystem når vi valgte Microsofts.NET-løsning som utgangspunkt for programmering. For detaljert beskrivelse av oppsettet for server og programmer, henviser vi til produktdokumentet. Kravspesifikasjonen var for oss et viktig dokument å få på plass tidlig i prosjektet; Ikke som et ferdig dokument, men som en overordnet mal. HiO som vår oppdragsgiver hadde ikke noen formulert kravspesifikasjon, og det var derfor nødvendig å definere deres ønsker og behov. I møter med vår kontaktperson i HiO fikk vi et inntrykk av hvilken funksjonalitet oppdragsgiveren ønsket fra applikasjonen, og deretter måtte formulere det som et skriftlig dokument. På den måten var det vi som forfattet kravspesifikasjonen, mens HiO godkjente at det vi hadde skrevet samsvarte med ønskene de hadde. Oppdraget vårt krever at vi henter ut informasjon fra TimeEdit, som er skolens eksterne leverandør av timeplanløsninger. TimeEdit er en kommersiell bedrift, og av forståelige grunner får vi ikke full tilgang til deres systemer. De har heller ikke en eksisterende løsning for å gi oss begrenset tilgang til systemet, og har ingen planer om å lage en slik løsning innenfor den tidsrammen vi har for prosjektet. Det har derfor vært en utfordring å få hentet ut den informasjonen vi trenger i henhold til oppgavens problemstilling, og vi var nødt til å finne en alternativ løsning på dette. Skolen har ingen tilgang til TimeEdit sine systemer, men har en nettside hvor all undervisning kan listes ut. Denne nettsiden har noen få forhåndsprogrammerte valg for sortering, men denne er vanligvis utilstrekkelig for både studenter og skolens ansatte. De har imidlertid en løsning som lister ut alle reservasjoner og forelesninger i en gitt bygning, med et valgfritt tidsintervall fra 30 minutter til 24 timer framover i tid. Se figur 7 og 8. 24

25 Figur 7: Søkefunksjoner i TimeEdit Figur 8: Opplisting av alle data i TimeEdit Som figurene viser, lister TimeEdit ut alle data i en tabellform. Denne tabellen er i HTML, og dataene er ikke sortert på noen annen måte enn at alt listes kronologisk etter starttidspunkt. For å kunne nyttiggjøre oss denne informasjonen, måtte vi derfor få det over på en form vi kunne jobbe videre med. Vi benytter oss av en teknikk som kalles Web-skraping (engelsk: Web Scraping). Ved hjelp av Regular-Expressions kunne vi filtrere den nødvendige informasjonen fra TimeEdit sin løsning, og skrive denne ned til en XML-fil. Denne XML-filen er vår applikasjons datakilde. Se figur 9. 25

26 Figur 9: Utsnitt av XML-fil 6.2 Iterasjon 1 Oppgaver: Opprette en database. Skrive algoritmer for filtrering av data. Web-skrapingen fra iterasjon 0 gav oss data om registrerte forelesninger og reservasjoner, og den ble lagret i et format som gjorde det mulig å behandle dataene. For å kunne nyttiggjøre oss av dette, måtte vi imidlertid ha et system for sortering av data, og da ble det nødvendig å opprette en database. Oppdraget vårt går ut på å vise relevante forelesninger og reservasjoner for et gitt område, heretter kalt stasjon. Databasen inneholder informasjon om hvilke stasjoner som er opprettet, og hvilke rom hver stasjon omfatter. Visual Studio 2008 kommer med et innebygget databaseverktøy kalt Microsoft SQL Server Av hensyn til effektivitet og enkelhet, valgte vi å bruke dette verktøyet i stedet for mer avanserte programmer. Microsoft SQL Server dekker alle behov vi har i forhold til oppretting og håndtering av databaser. For mer detaljert informasjon om dette, henviser vi til produktdokumentet. 6.3 Iterasjon 1-ii Oppgaver: Opprette en side for administrering av applikasjonen. Da vi var ferdige med algoritmer for filtrering av data, trengte vi en side hvor vi kunne bestemme hva som skulle vises. Dette var nødvendig for å teste algoritmene i praksis; Vi kunne bruke administrasjonssiden til å knytte gitte data til en stasjon, for deretter å kontrollere at de utsendte data samsvarte med forventningene. Administrasjonssiden er bygget opp på en måte som gjør at man må logge på for å få tilgang til funksjonene. Dette er et valg vi har gjort for å gjøre det mulig å ha siden liggende offentlig ute på internett. En innlogget administrator («Standard»-bruker) kan opprette/endre/slette stasjoner, 26

27 opprette/endre/slette rom og velge hvilke rom som skal være knyttet til hver stasjon. En innlogget superadministrator («Admin»-bruker) kan i tillegg opprette nye brukere, slette eksisterende brukere eller endre informasjonen til en bruker. På funksjonene i administrasjonssiden er det lagt inn hensiktsmessige valideringer på data som blir skrevet inn av brukeren. (For detaljert informasjon om dette, henviser vi til produktdokumentet.) Vi fikk imidlertid et problem med å lage validering på feltet «romtittel», som er den unike koden hvert rom har i reservasjonssystemet til TimeEdit. Grunnen til dette, er at rommene har blitt tildelt veldig ulike romtitler noen er tildelt koder som P35-PH322 eller P52-A357a, andre har koder som pp35-u1011 eller p44-v-2u31, andre igjen har koder som -Eksamrom, og atter andre har koder som fg18-k105. (Alle de oppramsede romkodene er reelle eksempler hentet fra TimeEdit sin reservasjonsside.) Som man kan se av dette, er romkodene skrevet på mange ulike former, og vi vet ikke om vi har oppdaget alle de ulike variantene som er brukt. Vi har ikke tilgang til TimeEdit sin database, og kan derfor ikke forhåndsregistrere alle rommene som finnes. På grunn av dette problemet, har det vært umulig for oss å legge inn validering på hva administrator skriver i feltet «romtittel», og alt ansvar ligger derfor på den innloggede brukeren når det gjelder å skrive inn riktige opplysninger i dette feltet. (Hvis et rom blir feilregistrert, må det slettes for deretter å legge inn et nytt rom med riktige opplysninger.) 6.4 Iterasjon 2 Oppgaver: Lage et visuelt rammeverk for applikasjonen. Lage algoritmer for lesing og visning av RSS-feeder. For å se hvilke opplysninger (rom og reservasjoner) som ble knyttet til de ulike stasjonene, trengte vi en side som kunne vise stasjonene. Det er denne delen av programmet som studentene vil se når applikasjonen settes i drift. Det viktigste elementet i denne delen av applikasjonen, er det visuelle, og derfor valgte vi å bruke Silverlight når vi skrev denne siden. Silverlight gjør det mulig å gi nettsiden et pent brukergrensesnitt utover det som er tilgjengelig med vanlig HTML. En ulempe vi oppdaget med Silverlight, var at den ikke kunne lese direkte fra en fil eller fra databasen. Derfor måtte vi opprette en web-service som stod for kommunikasjonen mellom databasen og Silverlight-applikasjonen, og mellom XML-filer og Silverlight-applikasjonen. Parallelt med det visuelle rammeverket, begynte vi å programmere kontroller for å lese inn og skrive ut RSS-elementer. RSS var noe ingen i gruppen hadde arbeidet med tidligere, så vi måtte lære oss dette på egen hånd. Imidlertid var det god hjelp å finne i den kunnskapen vi hadde opparbeidet oss i arbeidet med XML-filer. Grunnen til dette, er at RSS-filer er skrevet i XML-format, og lesing av RSS skjer derfor på samme måte som lesing av en hvilken som helst annen XML-fil. 6.5 Iterasjon 3 Oppgaver: Lage kontroller for visning av forelesningssaler og klasserom. Lage kontroller for visning av grupperom. 27

28 Da rammeverket var ferdig, kunne vi begynne å legge til innhold i visningsdelen av applikasjonen. I Silverlight er det mulig å lage egne kontroller for visning av ulike data. En kontroll er i denne sammenheng et visuelt brukergrenseelement. Det første som måtte på plass, var presentasjon av undervisningen som foregår på skolen. Dette ble den første egendefinerte kontrollen vi laget i Silverlight. Det var viktig for oss å skille mellom ulike undervisningslokaler (klasserom, auditorier og laboratorier), i og med at undervisningen vil foregå i ulik form avhengig av hvilken type lokale den foregår i. Derfor vises all undervisning i samme kontroller, men vi har lagt inn et tekstfelt som beskriver hva slags type lokale det er snakk om. Se figur 10. Figur 10: Presentasjon av undervisningslokaler I tillegg til undervisningslokaler, har det vært viktig for oss å vise grupperom i applikasjonen. Det er ofte vanskelig å finne ledige grupperom, og vi anså det derfor for å være et nyttig tillegg for studentene, selv om skolen i utgangspunktet ikke hadde definert det som et ønske. Det var imidlertid ikke hensiktsmessig å vise grupperom på samme måte som undervisningslokaler, og vi måtte derfor lage en egen visningsmetode for disse. Dette ble den andre kontrollen vi laget i Silverlight-applikasjonen. Grupperom som er reservert markeres med rødt, mens grupperom som er ledige for reservasjon markeres med grønt. Se figur 11. Figur 11: Grupperom 6.6 Iterasjon 4 Lage en kontroll for RSS-visning Lage kontroller for logo, klokke og dato Etter å ha lagt inn undervisninger og grupperom, laget vi en kontroll for å vise nyheter fra HiO sin RSS-feed. I tillegg laget vi en kontroll for å vise HiOlogoen i applikasjonen. For å bedre brukervennligheten, la vi til kontroller for klokke og dato i applikasjonen. Visuelt oppdaget vi at det så fint ut med en analog urskive øverst i websiden, i tillegg til at vi la inn digital klokke og dato nederst på siden. Det er imidlertid mye arbeid å kode en analog klokke, og det krever Figur 12: RSS-visning 28