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

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Begynne med side:

Download "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

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1 ID Name Duration Start Finish 1 Planlegging 95 days Mon 02.10.06 Fri 09.02.07 2 Statusrapport 20 days Mon 02.10.06 Fri 27.10.06 3 Prosjektskisse 25 days Mon 30.10.06 Fri 01.12.06 4 Prosjektweb 31 days

Detaljer

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport.

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport. Prosjektdagbok FRA 30.1008 TIL 2.309 Uke Dato Personer tilstede 44 30.1008 48 25.1108 49 02.1208 2 8.109 Tid 10:00 12:00 12:00 12:00 Beskrivelse Vi dannet gruppe og skrev Statusrapport. Kontaktet bedrifter

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Entobutikk 4.PROSESSRAPPORT VÅR 2011 4.PROSESSRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2008-18 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05

Detaljer

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet.

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. DAGBOK Uke 43: Torsdag 28/10 Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. Uke 44: Mandag 1/11 Gruppen utformet den første statusrapporten til prosjektet.

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio.

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio. Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Prosjektdagbok hovedprosjekt våren 09

Prosjektdagbok hovedprosjekt våren 09 Prosjektdagbok hovedprosjekt våren 09 Man 25. Mai 09 Planlegging og arbeid med sluttføring Sluttføring av grensesnitt, arbeid med dokumentasjon og detaljplanlegging av sluttføring. Ons 21. Mai 09 Arbeid

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8.

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8. Aktivitetskart Planlegging dato: 29.01-09 TIL 7.2-09 Kravspesifikasjon beskrivelser Papirprototyp ER-diagram Planlegging og fastslåing av prosjekt En del av kravspesifikasjon. Grafisk visning av systemets

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Produktdokumentasjon

Produktdokumentasjon Produktdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer

Detaljer

Kravspesifikasjon Innholdsfortegnelse

Kravspesifikasjon Innholdsfortegnelse Kravspesifikasjon Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:... 2 1.3 Kontaktsperson hos Retriever:... 2 1.4 Veileder:... 2 1.5 Bakgrunn... 3 2. Om Kravspesifikasjonen...

Detaljer

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

Dokument 3 - Prosessdokumentasjon

Dokument 3 - Prosessdokumentasjon Dokument 3 - Prosessdokumentasjon Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Dokument 3 - Prosessdokumentasjon Innholdsfortegnelse

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen Prosjekt nr. 2007-11 Prosessrapport Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen, s130182 Espen Skaarer, s123590 Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Gruppelogg for hovedprosjekt 2009

Gruppelogg for hovedprosjekt 2009 Gruppelogg for hovedprosjekt 2009 Før det endelige valget på prosjektet ble tatt brukte gruppen en del tid på å finne forskjellige muligheter for oppgaveemner. Det ble blant annet kontaktet Hafslund produksjon

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Produksjonssettingsrapport

Produksjonssettingsrapport Vedlegg E2 Produksjonssettingsrapport milepæl 1 Dokumentet inneholder beskrivelse av andre del av produksjonssetting av milepel 1 den 16.03.2013. INNHOLDSFORTEGNELSE INNHOLDSFORTEGNELSE 2 1. INNLEDNING

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9 Forprosjektrapport Gruppe 17 Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen Side 0 av 9 Innholdsfortegnelse: Presentasjon - Service Broker AS - Kontaktpersoner Sammendrag Dagens situasjon Mål og

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

Detaljer

Forprosjekt. Profilhåndbok for Kommunikasjon 1. Hovedprosjekt ved Høgskolen i Gjøvik. Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne

Forprosjekt. Profilhåndbok for Kommunikasjon 1. Hovedprosjekt ved Høgskolen i Gjøvik. Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne Forprosjekt Profilhåndbok for Kommunikasjon 1 Hovedprosjekt ved Høgskolen i Gjøvik Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne Innhold Forprosjektrapport 5 Bakgrunn 5 Mål 5 Omfang 6 Avgrensninger

Detaljer

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av: Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:

Detaljer

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

Detaljer

Forprosjektrapport. HMI Lab løsning for industriell IT Gruppe 21. Tor Arne Trogersen, Ajwan Mamshi, Karzan Salihi

Forprosjektrapport. HMI Lab løsning for industriell IT Gruppe 21. Tor Arne Trogersen, Ajwan Mamshi, Karzan Salihi Forprosjektrapport HMI Lab løsning for industriell IT Gruppe 21 Tor Arne Trogersen, Ajwan Mamshi, Karzan Salihi 17. januar 2014 1 Prosjektgruppen Tor Arne Torgersen Utdanner seg som dataingeniør, fordi

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell.

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell. statusrapport 2 I produksjon av webside for skjerdingen høyfjellshotell STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell 1 29. APRIL 2010 http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen

Detaljer

Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2

Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2 PROSJEKT NR. 2007-02 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

Detaljer

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009 Nettside, Webshop og Beregningsmodell Hovedprosjekt våren [Type the abstract of the document here. The abstract is typically a short summary of the contents of the document. Type the abstract of the document

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Oppdragsgiver: Statsbygg Kontaktperson: May Liss Urang. Veileder: Norun-Christine Sanderson, HiO

Oppdragsgiver: Statsbygg Kontaktperson: May Liss Urang. Veileder: Norun-Christine Sanderson, HiO LISENSSYSTEMET 29.01.2010 Forprosjektrapport Oppdragsgiver: Statsbygg Kontaktperson: May Liss Urang Veileder: Norun-Christine Sanderson, HiO Skrevet av prosjektgruppe 10-24 Nam Nguyen, s148093 Ingolf Nistad,

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg

Detaljer

Kravspesifikasjon. 1 Prosjektfakta. Medlemsregister for YXD-Kurdistan. Prosjektnummer: 07 09. Ernad Fajkovic

Kravspesifikasjon. 1 Prosjektfakta. Medlemsregister for YXD-Kurdistan. Prosjektnummer: 07 09. Ernad Fajkovic Kravspesifikasjon 1 Prosjektfakta Prosjekttittel: Medlemsregister for YXD-Kurdistan Prosjektnummer: 07 09 Gruppemedlemmer: Oppdragsgiver: Kontaktperson: Intern veileder: Asad Fattahi Ernad Fajkovic YXD-Kurdistan

Detaljer

Styringsdokumenter. Forord

Styringsdokumenter. Forord 8 Styringsdokumenter Forord Dette er en samling av samtlige styringsdokumenter gjennom hele prosjektperioden. Styringsdokumentene er satt opp i rekkefølge i forhold til leveringsfrister Dokumentene ble

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

HØGSKOLEN I SØR-TRØNDELAG Avdeling for teknologi Studieprogram for elektro- og datateknikk 7004 TRONDHEIM. Antall Sider/bilag: 17 / 8 Gruppedeltakere:

HØGSKOLEN I SØR-TRØNDELAG Avdeling for teknologi Studieprogram for elektro- og datateknikk 7004 TRONDHEIM. Antall Sider/bilag: 17 / 8 Gruppedeltakere: HØGSKOLEN I SØR-TRØNDELAG Avdeling for teknologi Studieprogram for elektro- og datateknikk 7004 TRONDHEIM Forprosjektrapport Oppgaves tittel: Interaktiv Robot Gitt dato: 07.09.2009 Innleveringsdato: 28.09.2009

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Forord... 3. Planleggingsprosess... 4. Prosjektstart... 4. Arbeidsmåte/Fremgangsmåte... 4. Begreper innenfor Scrum... 5. Datainnsamling...

Forord... 3. Planleggingsprosess... 4. Prosjektstart... 4. Arbeidsmåte/Fremgangsmåte... 4. Begreper innenfor Scrum... 5. Datainnsamling... 1 Innholdsfortegnelse Forord... 3 Planleggingsprosess... 4 Prosjektstart... 4 Arbeidsmåte/Fremgangsmåte... 4 Begreper innenfor Scrum... 5 Datainnsamling... 6 Styringsdokumenter... 6 Dagbok... 7 Rissikoplanlegging...

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

Tekniske Krav Aditro Lønn

Tekniske Krav Aditro Lønn 1 (6) Tekniske Krav Aditro Lønn Tekniske krav 2 (6) Innhold 1 Tekniske krav... 3 1. Generelt... 3 2. Database server... 3 3. Applikasjons-server / Klient... 4 4. Web server... 5 5. Klient... 5 6. Filserver...

Detaljer

Huldt & Lillevik Ansattportal. - en tilleggsmodul til Huldt & Lillevik Lønn. Teknisk beskrivelse

Huldt & Lillevik Ansattportal. - en tilleggsmodul til Huldt & Lillevik Lønn. Teknisk beskrivelse Huldt & Lillevik Ansattportal - en tilleggsmodul til Huldt & Lillevik Lønn Teknisk beskrivelse Huldt & Lillevik er trygghet Trygghet er å vite at løsningen du bruker virker, hver eneste dag, enkelt og

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Forprosjekt. Gruppe: H09B03. HIØ, Sarpsborg

Forprosjekt. Gruppe: H09B03. HIØ, Sarpsborg Forprosjekt HIØ, Sarpsborg 1 INNHOLDSFORTEGNELSE Innhold INNHOLDSFORTEGNELSE... 2 1. MÅL OG RAMMER... 3 1.1 Bakgrunn... 3 1.2 Prosjektmål... 3 Effektmål... 3 Resultatmål... 4 1.3 Rammer... 4 2. OMFANG...

Detaljer

Skøyen, 23.01.14 Gruppe 11

Skøyen, 23.01.14 Gruppe 11 Forprosjektrapport Produktkvalitet, visitnorway.com Sammendrag Vi skal gjennomføre et produktkvalitetsprosjekt hos Creuna i forbindelse med visitnorway.com, Innovasjon Norges turistinformasjonsside. Prosjektet

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

Forprosjektrapport H10E02 25.03.2010. Tilknytning av små vindkraftverk til 22 kv fordelingsnett. Gruppemedlemmer:

Forprosjektrapport H10E02 25.03.2010. Tilknytning av små vindkraftverk til 22 kv fordelingsnett. Gruppemedlemmer: Forprosjektrapport Tilknytning av små vindkraftverk til 22 kv fordelingsnett. H10E02 25.03.2010 Gruppemedlemmer: Markus Fagerås Stian Dahle Johansen Stein Ove Jensen HØGSKOLEN I ØSTFOLD Avdeling for ingeniørfag

Detaljer

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006

PRESENTASJON. Prosjektnr: 43E Prosjektnavn: BILs nettsider Jone Tveitane Dato: 17.12.2006 PRESENTASJON Prosjektnr: 43E Prosjektnavn: BILs nettsider Elev: Jone Tveitane Dato: 17.12.2006 1 INNHOLDSFORTEGNELSE 1 OPPGAVESTILLER... 3 2 PROBLEMSTILLING... 3 3 HVORFOR DENNE OPPGAVE... 3 4 HVORDAN

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

Innholdsfortegnelse. Side 118 av 135

Innholdsfortegnelse. Side 118 av 135 Forord Dette produktet er endel av hovedprosjektoppgaven til gruppe 33 vår 2011. Produktet har som hensikt å lagre SMS meldinger i en Noark standard. Leseren av denne brukermanualen skal ikke trenge noen

Detaljer

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra.

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra. Visjonsdokument 1 Introduksjon Dette prosjektet er gitt av Svend Andreas Horgen, og gjennomføres som en prosjektoppgave i faget TDAT3022-A 14H Systemutviklingsprosjekt ved HiST, AiTEL. Hensikten med dette

Detaljer

Forprosjekt bachelor-oppgave 2012

Forprosjekt bachelor-oppgave 2012 Forprosjekt bachelor-oppgave 2012 Oppgave nr. 4.- Styring av instrumenter. Skrevet av Jan Ingar Sethre. 1 Innhold 1. Mål og rammer... 3 1.1 Bakgrunn... 3 1.2 Mål for prosjektet... 3 1.3 Rammer og forutsetninger...

Detaljer

Publiseringsløsning for internettsider

Publiseringsløsning for internettsider Publiseringsløsning for internettsider Hva er Edit? Edit er et verktøy for publisering og vedlikehold av nettsider. Tidligere har det å vedlikeholde en nettside vært en tungvinn prosess, men nå kan alle

Detaljer

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2008

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2008 Prosjektoppgave: Bildedatabase TDT4145 Datamodellering og Databasesystemer Våren 2008 NB! Kun for de som ikke tar fellesprosjektet. Innledning I løpet av de siste årene har det blitt stadig mer vanlig

Detaljer

Tekniske krav. Installasjonsrekkefølge. Operativsystem og web-server. Maskinvare. .Net Framework 2.0. ASP.Net AJAX 1.0

Tekniske krav. Installasjonsrekkefølge. Operativsystem og web-server. Maskinvare. .Net Framework 2.0. ASP.Net AJAX 1.0 Tekniske krav Operativsystem og web-server Windows 2000 med IIS 5.0 eller høyere Windows 2000 Server med IIS 5.0 eller høyere Windows XP med IIS 5.0 eller høyere Windows 2003 Server med IIS 6.0 eller høyere

Detaljer

HOVEDPROSJEKT I DATA VÅR 2011

HOVEDPROSJEKT I DATA VÅR 2011 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

Mandag 09. januar 2012 Torsdag 12. januar 2012 Søndag 15.januar 2012 Mandag 16. januar 2012 Onsdag 18. januar 2012 Torsdag 19.

Mandag 09. januar 2012 Torsdag 12. januar 2012 Søndag 15.januar 2012 Mandag 16. januar 2012 Onsdag 18. januar 2012 Torsdag 19. Dagbok HP_22 Mandag 09. januar 2012 I dag møtte vi veileder Larissa Sjarbaini for første gang. Hva som ble tatt opp på møtet kan leses ut ifra sakslisten i dokumentet HP22_uke02_Erik_møte.pdf. Videre skrev

Detaljer

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12 1 av 6 1.Innledning 1.1Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables

Detaljer

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Kravspesifikasjon for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Administrering av SafariSøk

Administrering av SafariSøk Administrering av SafariSøk Administrering av SafariSøk Revisjonshistorie Revisjon $Revision: 1.6 $ $Date: 2003/08/05 12:44:02 $ Innholdsfortegnelse 1. Om programmet... 1 Generelt... 1 2. Fremgangsmåter...

Detaljer

S y s t e m d o k u m e n t a s j o n

S y s t e m d o k u m e n t a s j o n S y s t e m d o k u m e n t a s j o n Monitorering av produksjonsløyper ved Nasjonalbiblioteket - Project BAKE Utarbeidet av: Einar Wågan Kristian Akerhei Studium: Informasjonssystemer Innlevert: 26.5.2015

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Tjenestebeskrivelse Webhotelltjenester

Tjenestebeskrivelse Webhotelltjenester Tjenestebeskrivelse Webhotelltjenester Sist endret: 2004-12-01 Innholdsfortegnelse 1 INTRODUKSJON... 3 1.1 GENERELT... 3 1.2 NYTTEVERDI WEBHOTELLTJENESTER FRA TELENOR... 3 2 FUNKSJONALITET... 4 2.1 INNHOLD

Detaljer