Prosessdokument. Utlånssystem for datautstyr. Hovedprosjekt ved Høgskolen i Oslo. Prosjektgruppe nr 08 09

Transkript

1 Prosessdokument Utlånssystem for datautstyr Hovedprosjekt ved Høgskolen i Oslo Prosjektgruppe nr Ole Anders Eidjord Nojanaj Pongsupaht Kristoffer Skappel Johannes Urke

2

3 Utlånssystem for datautstyr Prosessdokumentasjon Forord Dette dokumentet tar for seg hvordan prosjektgruppa har arbeidet med utviklingen av et system for utlån av datautstyr. Systemet er laget for Teknotorget, avdelingen for brukerstøtte, ved Statsbygg. Denne rapporten går i detalj på hvordan vi har arbeidet sammen under planleggingen, utviklingen, hvordan vi har brukt kravspesifikasjonen, og hva resultatet har blitt. I forbindelse med dette prosjektet finnes en prosjektrapport som beskriver prosjektet og produktet som er utviklet. Prosessdokumentet er et tileggsdokument. Prosessdokumentet er rettet mot veileder, medstudenter og ansatte ved skolen, men det har vært ønskelig at den skal gi god forståelse for de uten alt for stor teknisk innsikt. Deler av dokumentet kan inneholde ord og utrykk som kan være tekniske, men disse er prøvd å forklare så godt som mulig. 3

4 Prosessdokumentasjon Utlånssystem for datautstyr Innholdsfortegnelse Forord Innledning Planlegging og metode Prosessmodell Fremdriftsplan Arbeidsplan Dagbok Tidsregnskap Webside for prosjektet Prosjektstyringswebside Kravspesifikasjon Utviklingsprosessen Analyse Logisk datamodell Datainnsamling Use case Design ER diagram Dataordbok Grensesnitt Sekvensdiagram Klassediagrammer Implementering Utvikling av grensesnitt Databaseoppsett Webserveroppsett Programmering Testing Kravspesifikasjon og dens rolle Om resultatet Oppsummering Vedlegg 1: Fremdriftsplan Vedlegg 2: Arbeidsplan Vedlegg 3: Tidsregnskap Vedlegg 4: Papirprototype 4

5 Utlånssystem for datautstyr Prosessdokumentasjon 1 Innledning I starten da vi skulle velge prosjekt, ble vi raskt enige om hva vi ønsket for hovedprosjektet. For det første ønsket vi at prosjektet skulle inneholde en hel systemutviklingsprosess som vi kunne gjennomføre helt fra start, og prosessen til ferdigstillelse av produktet. Dette innebar at vi ønsket å programmere et system, og vi hadde som mål at vi ønsket at det skulle bli et system som kunne tas i bruk etter ferdigstillelse. Vi ønsket også at det skulle utvikles med C# og ASP.NET, siden dette var noe vi ønsket å lære mer om. Ole Anders i prosjektgruppa jobber i Statsbygg, og det ble derfor naturlig å forhøre seg om det var mulig å avholde hovedprosjektet der. Ansatte ved Statsbygg kom raskt med flere forslag til prosjekter vi kunne gjennomføre. Etter samtale med May Liss Urang, som er leder ved Teknotorget på Statsbygg, kom vi fram til at et webbasert utlånssystem for datautstyr var noe som ville være nyttig for dem, samtidig som det ville være passende som hovedprosjekt for oss. Ved utarbeiding av forprosjekt så det ut til å stemme godt overens med våre tanker. Vi fikk mulighet til å gjennomføre en hel systemutviklingsprosess, og det så ut til å være mulig innenfor tidsrammene som er satt for hovedprosjektet. Ingen på gruppa har noen særlig kunnskap innen utvikling av systemer med.net, vi så derfor dette som en utfordring hvor vi kunne lære mer. Alle på gruppa har gjennomført faget Webprogrammering i.net ved siden av hovedprosjektet, noe som har vært til stor hjelp. 5

6 Prosessdokumentasjon Utlånssystem for datautstyr 2 Planlegging og metode I starten av planleggingen valgte vi å møtes faste dager hver uke. Mandag møttes vi på HiO. Onsdag valgte vi å møtes hvis vi hadde mye å gjøre eller lå på etterskudd med noe aktivitet. Torsdag og fredag møttes vi på Statsbygg. Dette har vi fulgt gjennom hele prosjektperioden, og fra første uke i mai jobbet vi alle dager i uka. Hver uke avtalte vi hvilket klokkeslett hvert møte skulle starte og slutte, men til vanlig har vi jobbet fra kl 9 til 15. Faste møtedager har vært viktig for å kunne jobbe jevnt helt fra starten. Vi har i tillegg også jobbet noe utenom planlagt møtetid. Selv om vi har visst at uforutsette ting kan oppstå, har vi valgt å ikke lage en risikoanalyse. Dette fordi vi har vært opptatt av å jobbe jevnt fra starten av og følge fremdriftsplanen. Hvis noe uforutsett hadde skjedd, har det vært rom for å ta igjen dette på kvelder og helger, der vi ikke har en begrenset arbeidssituasjon som studenter. Alle på prosjektgruppen tok faget Webprogrammering i.net ved siden av hovedprosjektet. Ved innleveringen av obligatoriske innleveringen i det faget, opplevde vi at dette gikk ut over de planlagte møtedagene våre. Dette medførte til at vi kom noen dager på etterskudd i forhold til fremdriftsplanen. 2.1 Prosessmodell En prosessmodell er måten systemutviklingsprosjekt organiseres og arbeides med. Det finnes mange måter å organisere et prosjekt på, men noen måter er mer vanlige enn andre. Fossefall er den mest kjente og eldste prosessmodellen, hvor fasene i prosessen utføres i rekkefølge. Arbeidet på en fase begynner ikke før den foregående fasen er utført. I starten av prosjektet valgte vi å bruke fossefallmodellen, noe som kan ses tydelig på framdriftsplanen vår. Den tar en fase om gangen, før den går videre til den neste. 1 Nå i etterkant av prosjektet ser vi at mange av fasene i prosjektet har overlappet hverandre, og at vi har arbeidet noe parallelt med fasene. Spesielt mot slutten hvor implementeringsfasen har gått mye inn i testfasen. 2.2 Fremdriftsplan Fremdriftsplanen gjør at vi hele tiden vet hva og når vi skal gjøre noe. Dette er et dokument som har vært svært viktig for oss på tidligere prosjekter, så vi var klar over at vi måtte sette det opp på en god og oversiktelig måte. Vi valgte å lage en enkel fremdriftsplan med de største fasene i prosjektet, og så delte vi dem opp i aktiviteter. Når vi kom til hver aktivitet delte vi den opp i mindre oppgaver som vi la ut som en oppgaveliste på prosjektstyringswebsiden Basecamp (Se 1 Kilde: Wikipedia 6

7 Utlånssystem for datautstyr Prosessdokumentasjon kapittel 2.7 Prosjektstyringswebside for mer informasjon). Dette gjorde at vi hele tiden hadde noen mål å løse fra uke til uke. Fremdriftsplanen ligger som vedlegg 1 til dette dokumentet. Vi laget også milepæler i framdriftsplanen, som vi prøvde å sette så realistiske som mulig. Dette var noe vi tok veldig seriøst, siden vi viste at fremdriftsplanen var noe vi måtte forholde oss til gjennom hele prosjektet. På slutten av prosjektet oppdaterte vi fremdriftsplanen etter hvordan vi faktisk har arbeidet. Det viste seg at vi har vært litt på ettertid på noen punkter. 2.3 Arbeidsplan Arbeidsplanen er det dokumentet som inneholder beskrivelse av de ulike fasene i prosjektet, med detaljert beskrivelse av hver aktivitet. I starten var vi litt usikre på hva hver av fasene skulle inneholde, og vi syntes de gikk litt inn i hverandre. Dette innebærer at vi så det som viktig å lage en detaljert beskrivelse av alle fasene. For oss så var dette til hjelp ved at det ikke var usikkerhet om hva hver fase inneholdt. Arbeidsplanen ligger som vedlegg 2 til dette dokumentet. Hvem som har ansvar for hver aktivitet er også med i arbeidsplanen. Dette er ikke noe vi har fulgt nøye gjennom prosjektet siden vi for det meste har samarbeidet om hver aktivitet. Tid for når vi har forventet at hver aktivitet skal være ferdig har vi også skrevet inn i arbeidsplanen. Dette skal samsvare med fremdriftsplanen. Når hver aktivitet er ferdig har vi oppdatert arbeidsplanen, slik at vi hele tiden har vist når vi var ferdig og hvor stort avviket var. 2.4 Dagbok Dagbok har vi valgt å oppdatere hver gang vi har hatt møte eller hver gang vi har jobbet med prosjektet. Hva vi har gjort, hvor lenge vi har jobbet og hvem som var med skrev vi i dagboken. Dette har vært til stor hjelp når vi skulle begynne på sluttdokumentasjonen. Spesielt når det gjelder beregning av tidsregnskap og oppsummering om arbeidet gjennom prosjektet. Nå i ettertid ser vi at vi kunne vært flinkere til å lage en mer utfyllende dagbok. Spesielt når det gjelder hvor lenge hver person har arbeidet utenom møtetid, slik at tidsregnskapet hadde blitt helt nøyaktig. 2.5 Tidsregnskap Underveis i prosjektet har vi estimert hvor lang tid vi skal bruke på hver fase i prosjektet. På slutten laget vi det endelige tidsregnskapet som inneholder hvor mye tid vi har brukt i de ulike faser i forhold til estimatet vi satt i starten av prosjektet. I tidsregnskapet kommer det fram at vi har brukt mindre tid enn planlagt. Dette ble forårsaket av at et annet fag på skolen tok opp all tiden vår i perioder, så vi måtte gå så langt som å avlyse noen gruppemøter. At vi hadde mindre tid til rådighet forårsaket også at vi ikke hadde tid til å utføre så mye testing som planlagt. Vi hadde i utgangspunktet planlagt å utføre unit testing på programmet, men dette fikk vi ganske enkelt ikke tid til. Se vedlegg 3 for fullstendig tidsregnskap. 7

8 Prosessdokumentasjon Utlånssystem for datautstyr 2.6 Webside for prosjektet Dette er en webside som presenterer hovedprosjektet med alle dokumenter i ferdigstilt versjon. Her vil også prosjektrapport og prosessdokument være publisert før prosjektets slutt. I tilegg er det på denne siden vi har skrevet dagboken underveis i prosjektet. Denne websiden er noe HiO forventer at vi lager. 2.7 Prosjektstyringswebside I tidligere prosjekter i studiet har vi benyttet e post til å dele filer og sende beskjeder mellom hverandre. Vi fant ut at vi måtte gjøre dette mer effektivt i hovedprosjektet. Derfor kom vi fram til å bruke Basecamp 2, som er et webbasert prosjektstyringsverktøy. Det tok litt tid før vi kom helt inn i systemet, men etter hvert har vi fått stor utbytte av dette. Vi har benyttet systemet på følgende måter: Alle dokumenter vi arbeider med laster vi opp til denne siden. Noe som har vært spesielt nyttig med dette, er at det er mulig å laste opp nye versjoner av hver fil. Dette gjør at vi hele tiden har en historikk på hvordan hvert dokument har utviklet seg. Vi skriver beskjeder på siden hvor alle har mulighet for å kommentere beskjedene. Dette gjør at all informasjonsflyt i prosjektet er samlet på ett sted, i motsetning til slik vi har brukt e post tidligere. I tillegg har vi brukt oppgaveliste (todo liste) i systemet aktivt. Hver oppgave i listene kan tildeles en person på gruppa. Dette har vi benyttet aktivt i forbindelse med å sette oss små mål hver dag, noe vi har oppdaget at effektiviserer arbeidsmåten vår. Vi har også lagt inn milepælene fra fremdriftsplanen på denne siden. Dette har vært en hjelp til å minne oss på når hver fase skal være ferdig. Basecamp har vært et system vi har hatt veldig godt utbytte av. Noe vi ser i ettertid, er at vi kunne gitt veileder på skolen og kontaktperson på Statsbygg tilgang til systemet. Dette ville gitt større mulighet for at de kunne kommet med kommentarer og veiledning underveis. 2.8 Kravspesifikasjon Kravspesifikasjonen er et dokument som beskriver hvordan systemet skal fungere når det er ferdig. Vi har sett det som viktig å lage et system som kan bli tatt i bruk. Derfor har vi brukt mye tid på dette dokumentet for å finne ut mest fornuftig løsning for systemet. Vi har snakket med kontaktpersonen om forventning av ferdigstilt system slik at vi utvikler et riktig system. I tillegg så kjenner Ole Anders, som jobber i Statsbygg, godt til problemstillingen. Dette har til sammen 2 Se for mer informasjon om Basecamp 8

9 Utlånssystem for datautstyr Prosessdokumentasjon ført til at vi er kommet fram til en kravspesifikasjon som peker så godt som mulig fram mot det produktet Statsbygg ønsker. For detaljert beskrivelse av endringer underveis i kravspesifikasjonen se kapittel 4 Kravspesifikasjon og dens rolle. 9

10 Prosessdokumentasjon Utlånssystem for datautstyr 3 Utviklingsprosessen Vi har valgt å dele utviklingsprosessen inn i fire deler; analyse, design, implementering og testing. Videre i dette kapittelet vil vi ta for oss hver av delene. 3.1 Analyse Det var i analysefasen vi har laget arbeidsplan og fremdriftsplan. Du kan lese mer om disse i kapittelet 2 Planlegging og metode. For å få en enkel oversikt over systemet laget vi et strukturkart. Dette har vi oppdatert underveis, slik at det hele tiden stemmer med systemet. Har noen på gruppen for eksempel vært usikre på hvordan navigeringen i systemet skal foregå, har dette dokumentet vært nyttig for å gi oversikten over systemet. Vi laget også en enkel papirprototype, som inneholder alle tenkte skjermbilder i systemet. Papirprototype var brukt for å illustrere hvordan vi har tenkt at systemet skal se, og ut for å få tilbakemelding fra kontaktpersonen. Dette viser ikke helt nøyaktig hvordan hvert bilde skal se ut, men hva hvert skjermbilde skal inneholde av knapper, tekstfelt og annen informasjon som hører med til grensesnittet. Vi har prøvd å følge papirprototypen under programmeringen, men det har vist seg at det har vært nødvendig å gjøre noen endringer for å få det til å fungere optimalt. Papirprototypen ligger som vedlegg 4 til dette dokumentet Logisk datamodell Dette er et diagram som beskriver den helt generelle funksjonaliteten til systemet. Første versjon av dette ble litt mer detaljert enn nødvendig, og etter hvert fikk vi laget et diagram som viser hoveddelene i systemet Datainnsamling I starten av analysefasen begynte vi å samle inn informasjon om Statsbygg og hvilke prosjekter de kunne tilby. Etter at prosjekt var valgt, begynte vi å hente inn informasjon om hva som var behovet, hvordan det fungerte i dag, og hvilken teknologi vi kunne bruke i utviklingen Use case Vi brukte use case diagrammet for å illustrere funksjoner som systemet inneholder. Use case diagrammet var et viktig dokument under utviklingsprosessen. Vi brukte det for å holde oversikt over funksjoner i systemet under utviklingen av strukturkart og sekvensdiagram. Vi baserte oss på use case diagrammet da vi delte inn oppgaven i implementeringsfasen. Vi har et element i use case diagrammet som heter Se logg, som skulle vise alle hendelser i systemet. På grunn av litt knapt med tid på slutten, og at ikke vi har sett dette som en viktig del av systemet, så er vi blitt enige om å ikke implementere denne modulen. 10

11 Utlånssystem for datautstyr Prosessdokumentasjon 3.2 Design Denne fasen av utviklingsprosessen brukte vi på å finne ut hvordan oppbygningen av systemet skulle være. Vi lagde flere dokumenter for å få oversikt over systemet, og forsikret oss om at vi var enige om oppbygningen. Helt i slutten av designfasen fant vi ut at det var et krav i systemet vi ikke hadde tenkt nok på. Kravet var at det skulle være mulig å begrense hvor mange enheter som kan lånes av hver utstyrstype. Vi hadde tatt med dette i design av systemet, men vi hadde også tenkt at det skulle være minst to utstyrstyper for PC er i systemet: PC Korttidslån og PC Langtidslån. Hva da hvis det er en regel i bedriften om at en ansatt bare kan låne én PC av gangen? Vi løste dette ved å gruppere utstyrstyper i kategorier. I praksis vil det si at når en oppretter en utstyrstype så skriver en også inn kategorinavn. Hvor mange enheter brukeren allerede har på lån sjekkes da mot kategorien, istedetfor utstyrstypen. Vi la til en ny tabell for kategori i ER diagrammet, og fullførte designfasen ER diagram ER diagram, databasemodell, ble utviklet ut ifra den logiske datamodellen fra analysefasen. Vi har fått veldig mye nyttig av dette diagrammet. Det ga oss et klart bilde av relasjoner mellom ulike entiteter, og brukes til å bestemme hvordan datastrukturen i applikasjonen skal bli Dataordbok Vi lagde dataordbok som en detaljert beskrivelse av alle entitetene i ER diagramet. Dataordboken ble laget hovedsaklig for de som skal videreutvikle systemet i fremtiden. Vi hadde ikke behov til å bruke den under utviklingen, fordi utviklingsverktøyene vi brukte ga oss full oversikt over databasen allerede Grensesnitt Vi fokuserte på at grensesnittet skulle være oversiktlig og enkelt for brukere å forstå slik at brukeropplæring ikke trengs. Vi mente at grensesnitt bør være ryddig og ha en fin flyt. Derfor tok vi ikke med ting som ikke er nødvendig på skjermbildene og alle begrepene som står på skjermbildene skal være kjent blant brukere. Før vi satt i gang, diskuterte vi med kontaktpersonen vår for å få fram en idé om hvordan det var ønsket at grensesnittet skulle se ut. Etterpå lagde vi en skisse av ulike skjermbilder for hver usecase ved å følge strukturkart vi hadde fra analyse fasen. Vi diskuterte med hverandre og gjorde endring på skissen slik at vi kom fram til grensesnitt som alle i gruppe var fornøyd med. Kontaktpersonen på Statsbygg fikk godkjenne den til slutt. Skissen av grensesnitt og strukturkartet har vært nyttig i implementering fasen slik at alle kunne utvikle grensesnitt i samme retning etter at oppgavene ble tildelt til gruppemedlemmene Sekvensdiagram Når vi haddde funnet ut hvordan grensesnittet skulle være, måtte vi planlegge hvordan vi skulle implementere dette i kode. Vi lagde sekvensdiagrammer for de viktigste use casene i systemet, med lagene i arktiekturen som aktører, og tegnet på beskjedene som måtte sendes mellom dem for hvert use case. Å lage disse sekvensdiagrammene ga oss bedre oversikt over hvilke klasser og metoder vi ville trenge i systemet. 11

12 Prosessdokumentasjon Utlånssystem for datautstyr Klassediagrammer Etter vi hadde laget sekvensdiagrammer hadde vi nok informasjon til å lage klassediagrammer for systemet. Disse spesifiserte hvordan programmet skulle deles inn i klasser, og hvilke metoder og attributter hver klasse skal ha. Vi lagde ett diagram for hvert lag i arkitekturen, og etter det var vi klare til å begynne å implementere programmet. 3.3 Implementering Under implementeringsfasen ble vi enige om å dele inn programmeringsoppgavene i fire deler som vi skulle fordele mellom oss med loddtrekning. Delene var delt slik at de innehold tilnærmet lik vanskelighetsgrad, og inneholdt programmering i alle lagene i trelagsarkitekturen. Dette valgte vi fordi vi ønsket at alle på gruppa skulle lære noe, og ikke at de som kunne mest om en oppgave fikk den oppgaven. Dette har fungert veldig bra, og ført til at alle på gruppa har vært nødt til å tilegne seg kunnskap Utvikling av grensesnitt Hvordan skjermbildene skulle se ut bestemte vi i designfasen. I implementeringsfasen hadde vi planlagt å lage kode for å vise alle skjermbildene. Vi skulle så skrive koden for å få skjermbildene til å fungere som de skulle. Vi fulgte ikke planen helt, fordi noen av sidene var ganske avanserte og vanskelige å lage. Vi lot derfor noen av skjermbildene være uferdige en stund, mens vi jobbet med den underliggende koden, der vi prøvde å finne ut hvordan vi skulle lage de vanskelige skjermbildene Databaseoppsett Før vi kunne begynne å programmere måtte vi ha mulighet til å koble til databasen. I midten av februar fikk vi tilgang til en database på Statsbygg med all informasjon som trengtes for å koble til. Det vi imidlertid ikke var klar over i starten, var at det ikke var mulig å koble til med våre private pcer, noe som førte til at vi måtte låne pcer fra Statsbygg. Vi satt flere dager og prøvde å koble til databasen uten at vi fikk kontakt med den. Etter en del feilsøking og kontakt med databaseansvarlig hos Statsbygg, viste det seg at databaseserveren hadde vært nede. Og etter at den ble startet på nytt fikk vi opp en tilkobling mot databasen. For å koble til en Oracle database fra Visual Studio må det være installert et program lokalt på pcen. Pcene vi lånte fra Statsbygg har på grunn av sikkerhetsmessige årsaker et spesielt oppsett som gjør at programmer ikke kan installeres på vanlig vis. Det viste seg at Oracle Data Provider for.net 3 ikke var mulig å installere på disse pcene på grunn av det spesielle oppsettet på maskinene. Dette brukte vi mye tid på å finne en løsning på, fordi vi ønsket å ha den fleksible løsningen Oracle Data Provider gir ved å ha et grafisk grensesnitt mot databasen. Etter hvert fant vi imidlertid ut at det var mulig å kopiere inn noen filer fra Oracle sin Instant Client 4, som gjorde det mulig å koble til databasen fra Visual Studio. Dette ble ikke like fleksibelt som det vi hadde ønsket, men godt nok til at vi kunne fortsette programmeringen. 3 Informasjon om ODP.NET: 4 Informasjon om Instant Client: 12

13 Utlånssystem for datautstyr Prosessdokumentasjon I tilegg valgte vi å sette opp en egen Oracle database som ble plassert ut mot internett hjemme hos Ole Anders, slik at vi også hadde mulighet til å ha en felles database mens vi programmerte og testet på våre private pcer. Alle problemer med Oracle tok mer tid enn forventet og førte til at vi kom en del på etterskudd. Vi antar at det kan ha ført til en forsinkelse på ca. 2 uker Webserveroppsett Som webserver ønsket Statsbygg at vi bruker Internet Information Services (IIS). Andreas Liaker, som arbeider ved avdelingen IT drift, gav oss lokale administratorrettigheter til en server med IIS. Oppsett av denne gikk uten store problemer. Vi måtte installere støtte for.net Framework 3.5 og støtte for tilkobling mot Oracle database. Dette er beskrevet detaljert i prosjektrapporten Programmering I forbindelse med uviklingen av systemet støtte vi på noen utfordringer som kom litt overraskende på oss. Som nevnt tidligere var en av de største utfordringene at vi ikke fikk tilgang til Statsbygg sitt lokalnett, og at vi hadde problemer med pcene vi fikk låne fra Statsbygg. Vi hadde bestemt oss for å bruke Microsoft Team Foundation Server som er et versjonskontrollsystem 5 som gjorde at vi kunne arbeide med det samme prosjektet uten å måtte sende filene mellom hverandre slik vi har gjort i tidligere prosjekter. Denne serveren ble satt opp hjemme hos Ole Anders, sammen med Oracle serveren. Dette gjorde at vi fikk et testmiljø vi kunne arbeide på når vi ikke var på Statsbygg, med felles database og kildekoden samlet på samme sted. Vi kunne nå jobbe på våre egne pcer med tilgang til versjonskontrollsystemet og tilgang til Oracle databasen. Dette førte til at vi fikk en veldig fleksibel utviklingsfase, hvor vi kunne programmere og teste programmet både på Statsbygg, skolen, og hjemme hos hver enkelt. Når vi skulle publisere systemet på webserveren i Statsbygg eller utvikle tilkoblingen mot Active Directory, koblet vi oss til med en av pcene vi hadde fått utlevert av Statsbygg. Under programmeringsfasen laget vi systemet slik at det automatisk sjekket om det befant seg på Statsbygg, eller ikke. Hvis det ikke var på Statsbygg, så hadde vi laget metoder som emulerte Active Directory. På denne måten hadde vi mulighet til å kjøre programmet selv om vi ikke var på lokalnettet til Statsbygg. 5 Et versjonskontrollsystem (eng: source control) er programvare som kan holde orden på de forskjellige versjonene av en eller flere datafiler. Når en fil oppdateres eller forandres, slettes ikke den gamle versjonen, men blir lagret i en database som inneholder tidligere versjoner av filene. Gamle versjoner kan hentes fram, og det er mulig å vise forskjeller mellom de forskjellige versjonene og lage utviklingsgrener fra disse versjonene. Kilde: Wikipedia. 13

14 Prosessdokumentasjon Utlånssystem for datautstyr 3.4 Testing Når det gjelder testing så hadde vi beregnet å bruke mye tid på dette. Vi hadde avtalt å bruke like mye tid som vi beregnet å bruke på programmering. Grunnen til at vi valgte å sette det opp slik var at vi mener at mye av testing skjer parallelt med programmering, og dette er også noe vi har opplevd underveis i prosjektet. Mye av tiden under programmeringsfasen går til feilsøking og testing av systemet. På fremdriftsplanen har vi skrevet at vi skulle utføre unit testing som en stor del. Vi hadde planer om å utføre denne form for testing, både fordi vi på en forelesning hadde fått høre at dette var en svært viktig del av testing, men også fordi vi ønsket å lære hvordan dette gjennomføres. Men på grunn av tidspress på slutten av prosjektperioden, har vi dessverre ikke fått tid til å lære oss om hvordan unit testing skal gjennomføres, derfor ble den ikke gjennomført etter planen. Siden de ansatte på teknotorget bruker forskjellige nettlesere har vi underveis i programmeringen testet at utlånssystemet vises likt i følgende nettlesere; Internet Explorer, Firefox og Opera. Har det vært forskjeller har disse blitt rettet opp. Vi har skrevet en testdokumentasjon som tar for seg hver modul i systemet, og denne tar for seg en liste med alt vi har testet, og resultatet av dette. 14

15 Utlånssystem for datautstyr Prosessdokumentasjon 4 Kravspesifikasjon og dens rolle Kravspesifikasjonen vår har gått igjennom mange versjoner. Det viser seg at den første versjonen ikke er så ulik den siste versjonen. Krav har blitt lagt til eller fjernet mens vi har jobbet med analysen, men hovedkravene var klare fra første versjon. De største endringene i kravspesifikasjonen var da vi la til andre tilhørende dokumenter, da de ble ferdige (use casediagram, ER diagram). Under analysefasen var kravspesifikasjonen det dokumentet vi brukte for å kommunisere med oppdragsgiveren. Vi lagde en versjon av kravspesifikasjonen, viste den til May Liss, og lagde ny versjon med tilbakemeldingen vi fikk. Når vi jobbet med design og implementering av systemet, var kravspesifikasjonen det dokumentet som styrte hvilken funksjonalitet vi designet inn i systemet. Den sørget også for at alle var klar over hvordan systemet skulle være, så alle på gruppen dro i samme retning. Kravspesifikasjonen er en ganske nøyaktig beskrivelse av systemet vi har laget. Det er noen få krav som ikke har blitt oppfylt, eller bare delvis oppfylt. Disse er mindre viktige krav. For eksempel mulighet til å sortere på alle felter på listene i systemet, eller altfor tidkrevende og kompliserte metoder som ikke er viktige for funksjonaliteten. Men også mulighet for å se lagerbeholdning på en tidligere dato og tidligere periode, som vil være krevende å lage siden det må lages oppslag på nesten alle tabellene i systemet. 15

16 Prosessdokumentasjon Utlånssystem for datautstyr 5 Om resultatet Utlånssystemet vi har utviklet gjennom dette halvåret er et fullt kjørbart system. Det er utrullet på en server på Statsbygg, og er tilgjengelig for bruk av de ansatte. På grunn av at det vil være en omstillingsfase for de ansatte å begynne å bruke systemet, og en del underbemanning de siste månedene, er det imidlertid ikke tatt stilling fra Statsbygg sin side om det skal brukes i bedriften. Det er også stilt spørsmål fra systemavdelingen i Statsbygg om hvem som skal ha vedlikeholdsansvar for systemet i ettertid. Ferdig system stemmer godt med kravspesifikasjon, use case diagram og use case beskrivelse. Bortsett fra en liten del av systemet som skulle vise logg over alle hendelser i systemet. Dette var ikke noe krav fra bedriften, men noe vi mente kunne gi en oversikt over alt som skjer i systemet. Underveis under utviklingen så vi at modulene rapporter og statistikk viser nærmest alle hendelser som skjer i systemet. Dermed besluttet vi at dette ikke skulle prioriteres, så lenge vi fikk litt begrenset med tid mot slutten av prosjektet. Vi er stolte av at vi har klart å lage et system som er laget for å fungere sammen med Statsbyggs Active Directory, Oracle database og e postserver. Alt dette er noe vi har sett på som en utfordring helt fra starten. Deler av det har virkelig vært en utfordring. Vi er fornøyd med programmet, og vi tror virkelig det kan komme til nytte i bedriften. Dette er noe vi har håpet hele veien, spesielt fordi vi ønsket å lage noe som faktisk kunne brukes. 16

17 Utlånssystem for datautstyr Prosessdokumentasjon 6 Oppsummering Alle på prosjektgruppen hadde lite kunnskap om webutvikling med.net i starten av prosjektet. Gjennom dette halvåret har vi gjennom faget Webprogrammering.NET og gjennom dette prosjektet opparbeidet oss kunnskap om C# og.net. På grunn av at vi delte programmeringsoppgaven inn i tilnærmet like deler har alle på gruppen måtte tilegne seg kunnskap om dette. Fra før hadde vi heller ingen kunnskap om Oracle databaser. Dette er noe vi har måtte tilegne oss underveis i prosessen. I forbindelse med dette har vi brukt mye søk på internett, og kommet med spørsmål til databaseansvarlig på statsbygg. I starten av prosjektet var vi litt usikre på hvordan utvikling med Visual Studio og.net skulle gjøres, og derfor har vi brukt en del tid på å lære oss hvordan bygge opp et slikt prosjekt. Skulle vi utviklet et nytt program nå i ettertid, eller gjort det på nytt, så hadde vi hatt en mye bedre forutsetning for å lage godt strukturert kode. Hadde vi fått mulighet til å utføre prosjektet på nytt så ville vi nok startet med programmeringen noe tidligere, og satt av mer tid til testing av systemet. I tillegg kunne vi vært mer beviste på å bruke use case beskrivelsen under programmeringen. På slutten av prosjektet har vi fått litt tidsmangel. Etter det vi kan se så har dette oppstått på grunn av at vi har måttet være borte noe på grunn av sykdom, uforvetet reisevirksomhet og at det har tatt litt mer tid enn antatt med tilkobling mot Oracle. Vi er godt fornøyd med prosjektet, og føler vi har fått stor utbytte av å gjennomføre det. Både når det gjelder programmering og gjennomføringen av hele prosjektprosessen. 17

18

19 Vedlegg til prossessdokument Vedlegg 1: Fremdriftsplan Vedlegg 2: Arbeidsplan Vedlegg 3: Tidsregnskap Vedlegg 4: Papirprototype

20

21 Vedlegg 1 Fremdriftsplan juni mai januar februar mars april Uke ANALYSE Strekforklaring BLÅ:Antatt arbeidstid GUL: Slik vi har arbeidet Eksamensuke Påske 1. feb Datainnsamling Forprosjekt Arbeidsplan Fremdriftsplan Kravspesifikasjon Use Case Strukturkart DESIGN ER diagram Grensesnitt Dataordbok UML diagrammer IMPLEMENTERING Utvikling av grensesnitt Databaseoppsett Serveroppsett Programmering TESTING Unit testing Testdokumentasjon Browsertesting/tilpassing Utrulling Side 1 av 2

22 Vedlegg 1 Fremdriftsplan januar februar mars april mai juni Uke Dokumentasjon Styringsdokumentasjon 23. mai Produktdokumentasjon Brukerdokumentasjon Prosessdokumentasjon Forberede Presentasjon 10. jun Presentasjon jun Overlevering Side 2 av 2

23 Arbeidsplan Vedlegg 2 Arbeidsplan Anvarlig Aktivitet Beskrivelse Planlagt Utført Ole Ole Nojanaj Nojanaj Johannes Nojanaj Dannet gruppe Statusrapport Opprettet gruppe, og lette etter prosjektoppgave. Et dokument om hvordan vi ligger an, og hva vi har gjort for å finne prosjektoppgave Prosjektskisse Foreløpig beskrivelse av prosjektoppgaven Samarbeidsavtale Avtale mellom arbeidsgiver og HiO ANALYSE Datainnsamling Forprosjekt Arbeidsplan Fremdriftsplan Kravspesifikasjon Use Case Møter med veileder og kontaktpersoner hos oppdragsgiver. Analyse av hva som skal gjøres og en avgrensing av oppgaven. En liste med de viktigste aktivitetene i prosjektarbeidet. Gantt skjema, med dato for når hver aktivitet skal være ferdig. Avtale med oppdragsgiver om hva som kal gjøres. Diagram over aktivitet som kan utføres med systemet. Uke 2 Uke Kris Strukturkart Struktur over programmet. Papirprototype. Uke 5 DESIGN Kris ER diagram Diagram over struktur til databasen. Uke 6 Nojanaj Grensesnitt Bestemme hvordan programmet skal se ut. Johannes Dataordbok Skal beskrive objektene i en database Uke 8 Uke 3 Uke 3 Uke 5 Uke 5 Ole UML diagrammer Klassediagram, sekvensdiagram. Uke 8 IMPLEMENTERING Nojanaj Utvikling av grensesnitt Lage grensesnittet med ASP.NET, HTML, og CSS. Uke 9 Johannes Databaseoppsett Lager et skript for å sette opp Oracledatabasen. Ole Serveroppsett Uke 10 Johannes Programmering Programmere systemet med C# og PL/SQL. Uke 17 Tja. Uke Uke Uke Uke Uke Uke Uke Uke 7 Uke Uke Uke Uke 9 Uke Uke Uke Uke TESTING Ole Unit testing (foregår under programmering) Uke 17 Johannes Testdokumentasjon Kris Browsertesting/tilpassing Lager rapport før testing, og fyller inn resultater etter utført testing. Sjekke at systemet fungerer i alle nettleserne i bruk på bedriften. Uke 19 Uke 19 Nojanaj Utrulling Prøvetid med utvalgte ansatte. Uke 19 Ole Johannes DOKUMENTASJON Styringsdokumentasjon Produktdokumentasjon Inneholder prosjektskisse, prosjektdagbok, forprosjektrapport, arbeidsplan, fremdriftsplan og kravspesifikasjon. Beskrivelse av systemets egenskaper og funksjon. Nojanaj Brukerdokumentasjon Brukermanual detaljert veiledning. Ole Prosessdokumentasjon Uke Uke Uke Uke Johannes Forberede presentasjon Uke 24 Kris Presentasjon Uke 24 10, Uke Uke Uke Uke Uke Uke Uke Uke Side 1 av 1

24

25 Tidsregnskap Vedlegg 3 Tidsregnskap Tidsforbruk til ulike utviklingsfasene Estimert Faktisk bruk Analyse Design Implementering Testing Dokumentasjon Total Total arbeidstid per medlem Total arbeidstid for hele prosjektet Programmerings ansvar Ole A. Eidjord 299,25 Utstyr: Legg til, endre, slett, utstyrsliste Utstyrstype: Legg til, endre, slett, utstyrstypeliste forside: beholdningsoversikt, vedlikeholdsliste DAL for Autentisering Nojanaj Pongsupaht 285 Utlån: låne ut utstyr med/uten reservasjon, forlenge lån Reservasjon (admin): Legge til, endre og slette reservasjon Reservasjon (ansatt): Legg til, slette reservasjon Johannes Urke 266,75 Innleveringssidene E post systemet Brukerliste Statsbygg membership provider Kistoffer Skappel 233,25 På Statsbygg koden Rapport: oversiktside, utstyrliste, utlånsliste, reservasjonsliste Innstillinger Videre implementerte autentisering: Kobling mot AD, kobling mot DB Side 1 av 5

26 Vedlegg 3 Tidsregnskap Tidsregskap Dato Ole A. Eidjord Nojanaj Pongsupaht Johannes Urke Kristoffer Skappel Totalt Side 2 av 5

27 Tidsregnskap Vedlegg Påskeferie Side 3 av 5

28 Vedlegg 3 Tidsregnskap Side 4 av 5

29 Tidsregnskap Vedlegg Total min Total time 299, ,75 233, ,25 Side 5 av 5