Dette dokumentet er en prosessrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

Størrelse: px
Begynne med side:

Download "Dette dokumentet er en prosessrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen."

Transkript

1 1 Sammendrag Dette dokumentet er en prosessrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. Oppdragsgiveren vår har pr dags dato en utdatert og veldig enkel nettside som kun innholder nyheter og andre informasjon for gjester og medlemmer. De ønsker seg nå et større web løsning sammen med en plattform som gir underviserne ved foreningen muligheten til å veilede og følge opp sine kursdeltagere gjennom de kursene dem holder. Denne løsningen skal imøtekomme behovet til og erstatte den eksisterende nettløsningen deres. Hovedfunksjonalitetskrav fra som skal være ved den nye løsningen i korte trekk: For administrator: - Administrere nyheter - Administrere kurs - Administrere medlemmer - laste opp bilde til en bilde katagori For Medlemmer: - Første gangs registrering - Lese interne nyheter - Redigere personlig informasjon - Melde seg opp på de forskjellige kursene som foregår (forespørsel sendes til underviseren) For kurs deltagere(voksne, barn): - Lese interne nyheter - Oversikt over de kursene deltageren har meldt seg på - Tilgang til rommene til disse kursene - Laste opp innlevering - Se på resultater, en slags portefølje Systemet skal la underviseren: - Lese interne nyheter - Oversikt over de kursene underviseren har - Legge ut kurs stoff, lekser og innleveringer på kurs rom - Avvise/ godkjenne forespørsel på kurs oppmelding fra kursdeltagere. 1 av 38

2 2 Forord Dette dokumentet gir en detaljert beskrivelse av alle fasene vi gikk gjennom under hovedprosjekt ved Høgskolen i Oslo, avdeling for ingeniørutdanningen våren Gruppen består av 3 studenter fra IT og data linjen, som har jobbet tett sammen for det endelige produktet. Gruppen startet lenge før semesteret med å finne et prosjekt som interesserte oss. Vi var åpent for både applikasjoner og web løsninger, så lenge det var spennende og samtidig utfordrende. Etter å ha søkt litt rundt i forskjellige bedrifter/ foreninger fikk vi kontakt med gjennom et av gruppemedlem (Neethiwarmen), som jobbet i foreningen. hadde et tilbud til oss om å lage en web løsning til deres forening. Gruppen hadde et møte med foreningen for å få bedre innblikk i hva oppgaven gikk ut på. Etter møte var alle i gruppen fornøyde med oppdraget, på grunn av prosjektets omfang og de forskjellige utfordringene den hadde. Vi så umiddelbart hvor mye vi kunne lære av denne oppgaven og valgte derfor å gå videre med denne oppgaven. Vi ønsker å rette en stor takk til noen enkelte personer - Ulf Uttersrud, vår veileder, som har hjulpet oss igjennom prosjekt perioden og gitt oss god og inspirerende veiledning. - Ann-Mari Torvantn, for å ha utarbeidet dokumentasjonsstandarden, som har vært til stor hjelp under dokumenteringsarbeidet. - Kulam Paramanathan, for å ha gitt oss en tydelig og lettfattelig kravspesifikasjon. Og gitt oss den tekniske friheten til å utvikle web løsningen. Neethiwarman Rasalingam Subaranchan Thanagopal Saba Munir 2 av 38

3 3 Innholdsfortegnelse 1 Sammendrag Forord Innholdsfortegnelse Innledning Litt om Dagens situasjon Mål og rammebetingelser Øvrige ønsker Utviklingsmiljø Gruppen Planlegging og metode Planlegging av prosjektet Fremdriftsplan og arbeidsplan Prosessmodell Idefasen Utdypningsfase Konstruksjonfasen / implementeringsfasen Overgangsfasen Arbeidsverktøy og utviklingsteknologi Arbeidsverktøy Utviklingsteknologi Prosjektorganisering Intern organisering Veileder Prosjektansvarskart Sikkerhetskopiering Brukergrensesnitt Kravspesifikasjonen og dens rolle Utviklingen og endringene av kravspesifikasjon Kravspesifikasjonens rolle Kravspesifikasjonen og det ferdige produktet Venter til slutt Risikofaktorer Risikofaktorer Risikoanalyse Utviklingsprosessen Use case og beskrivelser Sekvensdiagram ER-modell Avslutende del Hva har vi lært Vurdering av gruppen Konklusjon Kilder Bøker Nettsider vedlegg av 38

4 4 Innledning 4.01 Litt om er en forening som ble etablert i Dette er en forening for bosatte i Asker og Bærum. I dag har de ca 75 registrerte medlemmer over 18 år og rundt 100 elever fra alderen 6år og oppover. I tillegg til å gi faglige kurs, holdes det sportsaktiviteter og turneringer i samarbeid med andre lignende foreninger Dagens situasjon I dag har foreningen en utdatert og veldig enkel nettside som kun inneholder nyheter og andre informasjoner for gjester og medlemmer. Opplysninger om medlemmer og oppfølging av elevene foregår i dag på papir. Etter hvert som tallet på medlemmer går opp blir det mer og mer papirarbeid og leting i papir arkiveringen blir derfor et stort problem. Innlevringer, tester og andre oppgaver som per dags dato også foregår på papir er med på gjøre situasjonen enda vanskeligere for foreningen. For å holde oversikten på en systematisk og enkel måte har de i dag et behov for et nytt og større løsning. I tillegg til å publisere nyheter og andre informasjon, skal denne løsningen registrere sine medlemmer og kursdeltagere. Deretter følge opp disse kursdeltagerne gjennom en plattform. Foreningen har ingen data kyndige folk, derfor legges det vekt på at løsningen skal være mest mulig brukervennlig. En uten forkunnskaper innen data skal kunne utføre de ulike oppgavene som løsningen byr på. Vi ser på dette som en spennende oppgave, samtidig svært utfordrende og lærerikt Mål og rammebetingelser Målet med oppgaven er å utvikle en web løsning som kan gi foreningsmedlemmene, kursdeltagere og andre interesserte informasjon om kurstilbudet og aktivitetene deres samt en plattform for læring og samarbeid. Løsningen skal ha et hensiktsmessig brukergrensesnitt slik at det blir så enkelt som mulig å bruke det. Den skal ikke kreve forkunnskaper innen avansert databruk. deler sine brukere i følgende grupper: - admin - Underviser - Ledelse - kursdeltagere - gjester Når en bruker logger seg inn på systemet, skal denne brukeren få en side som er tilpasset etter gruppen brukeren hører til og med de rettigheten en har. 4 av 38

5 Under beskriver vi korte trekk av de viktigste kravene som oppdragsgiveren vår stiller. For en fullstendig beskrivelse viser vi til krav kravspesifikasjon som er blitt utarbeidet. Undervisere skal ha mulighet til følgende etter å ha logget inn på systemet: - oversikt over de kursene han holder tilgang til Kursrom, hvor læreren kan legge ut kurs stoff, lekser og innelevringer for kurset. Godkjenne eller avvise forespørsel om opptak til kurs fra medlemmer. Deltagere skal ha mulighet til følgende etter å ha logget inn på systemet: - få en oversikt alle kurs. - Melde på kurs. Ønsket Kurs forespørsel blir sendt til den aktuelle underviseren. Underviseren får deltager opplysninger, slik at underviseren kan vurdere om han kan godta forespørsel. - Oversikt over de kursene deltageren har meldt seg på. Tilgang til rommene til disse kursene. Laste opp oppgaver og innlevringer Se på resultater i de forskjellige kursene Admin skal ha mulighet til følgende etter å ha logget inn på systemet: - administrere nyheter - laste opp etter kategori, slette bilder - Administrere medlemmer - Administrere kurs Vanlige Medlemmer skal ha mulighet til følgende etter å ha logget inn på systemet: - lese nyheter angående foreningsmedlemmer holder flere arrangementer for sine medlemmer hvor det blir tatt massevis av bilder. Derfor ønsker de seg en slags album side, hvor admin kan laste opp bildene på nettsiden etter kategori Øvrige ønsker I tillegg er det et ønske om at det skal lages en web-basert chatte program, HelpChat, hvor læreren kan kommunisere med kursdeltagerne for å hjelpe dem med lekser. Det skal fungere slik at læreren etter en avtalt tid åpner HelpChat og hjelper elevene sine i det aktuelle kurset og deretter stenger HelpChat når lekse hjelpen er over. 5 av 38

6 4.05 Utviklingsmiljø Det kom tydelig frem fra oppdragsgiveren at løsningen skal være billigst mulig på grunn av foreningens økonomiske situasjoner. Løsningen skal støtte Internet Explorer 6.0 og nyere. Dette ble konstatert tidlig under et møte med oppdragsgiveren. Gruppen har fått friheten til å velge selv fremgangsmåten og programmering språket for utviklingen av løsningen. Det viktigste for foreningen er at produktet er enkelt som mulig for bruk og billigst mulig for dem. Selv om valget stod mellom PHP, JSP og ASP.Net som alternativer for web løsninger, ble det fort tatt en avgjørelse om å gå for PHP. Dette på grunn av at vi tok hensyn til oppdragsgiverens ønske med tanke på økonomien. Ved siden av at PHP var billig, at alle i gruppen hadde best erfaring med PHP og populariteten til PHP med tanke på videreutvikling var noen av de viktigste årsakene til valget. 5 Gruppen Gruppen består av tre studenter fra HiO, avdeling for ingeniørutdanning. Gruppen ble dannet tidlig i skole starten og felles for alle var at vi var ivrige etter å lære noe nytt. Siden vi hadde gjennom studiet jobbet mye med java applikasjon, ville vi med dette prosjektet gjøre noe annerledes. Ingen av oss, gruppe medlemmer hadde jobbet noe spesielt med web-applikasjoner før. Vi hadde lært oss det grunnleggende programmering i PHP i faget Webprogrammering i PHP ved HiO, hvor fikk vi smaken av Web applikasjon. Dermed var vi åpen for webapplikasjoner. Da vi fikk tilbud om dette prosjektet ble alle mer nyskjerige på web applikasjoner. Dermed falt valget på dette oppdraget. Etter å ha jobbet en del med java applikasjoner følte vi for å gjøre noe som var nytt og ferskt for oss. Dette er første gang vi går sammen for å jobbe om et prosjekt. Vi kjente hverandre godt og viste om hverandres svake og sterke sider, noe som var en stor fordel for oss, fordi det gjorde arbeidet med å fordele oppgaver mye enklere. Vi var målbevist og ønsket å jobbe sammen gjennom denne utfordrende og spennende tiden vi hadde foran oss. 6 av 38

7 6 Planlegging og metode 6.01 Planlegging av prosjektet Gruppen kom godt i gang med planleggingsfasen straks etter at oppgaven var klar og bestemt. Planleggingsfasen var svært viktig og hadde en avgjørende betydning for hvor lang tid vi kommer til å bruke på prosjektet. Uten god planlegging ville risikoen for å møte veggen vært svært høyt. For å unngå dette bestemte vi å bruke mye tid på planlegge grundig gjennom det vi hadde i vente. Alle i gruppen deltok i planleggingsfasen, hvor det ble diskutert hvordan programmet skal bygges opp, hva det skal inneholde, utforming av brukergrensesnittet osv.. I denne fasen fikk vi god nytte av modelleringsteknikker med bruk av UMLdiagrammer Fremdriftsplan og arbeidsplan Det ble utarbeidet en fremdriftsplan og arbeidsplan ved planleggingsfasen av dette prosjektet. Dette arbeidet var svært viktig da den fungerer som et hjelpemiddel for å holde oversikt over fremdriften i prosjektet, slik at vi har en noenlunde oversikt når ting kan forventes ferdig. Her ble det også beskrevet arbeidet i en hver fase. Det ble satt frister. Selv om oppdeling av arbeidet og fastsetting av tider var basert på antakelser hadde vi dette som noe vi kunne forholde oss til Prosessmodell Vi valgte Rational Unified Process (RUP) som vår styringsmodell for vårt prosjekt. RUP er en systemutviklingsmetode som beskriver hvordan man kan jobbe med å utvikling av prosjekt. Den beskriver hvem i gruppen som skal gjøre hva, hvordan det skal gjøre og når tid det skal gjøres. Den gir retningslinje, maler og mønstrer som kan følges og konsepter for overvåkning/måling av fremtid. En må ikke følge alt i prosessmodellen men kan plukke ut det som er nødvendig for å få et best mulig resultat. RUP reduserer risiko og øker forutsigbarhet grunnet at det er en iterativ prosessmodell, noe vi syntes var viktig å legge vekt på. Vi styrte nemlig unna fossefall modellen i frykt for at modellens lite iterative natur skulle føre til fiasko. For gruppen var det viktig med kontroll over planer, leveranser, og utviklings status, noe som denne systemutviklingsprosessen ga mulighet for. Dessuten mente vi at de ulike prosjektfasene i RUP var den beste og mest logiske måten å legge opp arbeidet på. I tillegg var friheten som modellen støttet for å jobbe fritt mellom fasene et viktig punkt, da det åpner rom for større effektivitet og gjør det lettere å gå tilbake til en tidligere fase dersom behovet skulle oppstå. 7 av 38

8 RUP består av fire faser som vist på diagrammet under. Figur 1 Ideefasen: fokus på forståelse av krav, omfang og lønnsomhet. Utdypningsfasen: fokus på planlegging, krav, arkitektur, risiko og prototyper Konstruksjonsfasen: fokus på konstruksjon, implementering og testing. Overgangsfasen: fokus på kvalitetskontroll, opplæring av brukere, tilpasning av brukerbedriftens organisasjon Idefasen Gruppen utarbeidet en dagbok tidlig i denne fasen. Slik at vi alltid hadde en oversikt over hvordan de enkelte dokumenter bygges på informasjon videre i andre dokumenter. Dagboken forteller også de problemene vi kom borti og de utfordringene vi har møtt underveis. Dette var til stor nytte da det ble lettere å utvikle sluttrapporten. Vi satt i gang med prosjektskissen. Da den var klar startet vi med prosjektet for alvor. Dette arbeidet startet med forprosjektrapporten hvor vi analyserte oppgaven og vurderte hvilke elementer som skal inngå i prosjektet. Her måtte vi ta hensyn til det økonomiske konsekvensene oppgaven innebærer og hvilke arbeidsverktøy som er nødvendige for å utvikle dette prosjektet. Ved hjelp av god kommunikasjon med oppdragsgiveren og at et av gruppemedlem jobbet der gjorde det lettere for oss å se behovet til foreningen Som nevnt tidligere lagde vi arbeidsplan og fremdriftsplan ut fra prosessmodellen vår RUP. Dette gjorde at vi hadde oversikt over hva som skulle leveres til hvilken tid på en tidlig tidspunkt, slik at vi kunne organisere oss bedre. Det ble også utviklet en første utkast av for prosjektrapporten og kravspesifikasjonen. En litt enklere versjon av Use Case diagram ble utarbeidet. Dette for at vi kunne sette fornuftige og naturlige grenser for problemområdet. 8 av 38

9 Utdypningsfase Vi startet denne fasen med å detaljere kravspesifikasjonen, det ble lagt flere utkast før vi kunne si oss fornøyde. Deretter detaljerte vi Use Case diarammen og lagde beskrivelser til dette. Det ble også lagd sekvensdiagrammer til de 3 viktigste Use Casene. Deretter utviklet vi risiko analyse slik at vi kunne gjøre oss forberedt til hvilke sårbarheter og trusler vi kunne ha i vente. Til slutt begynte vi med å designe ER modellen som vi gjorde endringer på underveis etter hvert som vi fikk nyere ider tanker Konstruksjonfasen / implementeringsfasen Denne fasen dreiet seg for det meste om implementering av oppgaven. Vi valgte å programmere i PHP, JavaScript, Ajax, HTML, DOM og CSS. Vi var flinke til å teste underveis, slik styrte vi unna problemer som eventuelt kunne dukket opp i det siste lite. Vi har tilrettelagt metoder og ider til eventuelt videreutvikling, noe som forekommer både i programkoden og i dokumentasjonen Overgangsfasen I denne fasen testet og feilsøkte vi det ferdige produktet. Vi fant noen små feil i produktet som vi rettet på med engang. Vi utarbeidet en testrapport og skrev mer om det ferdige produktet i produktrapporten. Deretter lagde vi brukemanual, og det ble skrevet om vireutviklings muligheter for produktet Arbeidsverktøy og utviklingsteknologi Det var ingen krav fra oppdragsgiveren vår når det gjaldt arbeidsverktøy og uviklingsteknologi. Dermed stod vi ganske fritt til å velge det verktøyet vi trengte i denne perioden Arbeidsverktøy Microsoft Office Word 2007 All dokumentasjons arbeidet og rapporteringen foregikk her. Dette er en programvare som samtlige gruppemedlemmer hadde på hver sin bærbar Pc. Dette er et tekstbehandlingsprogram som blir brukt daglig av alle i gruppen og dermed var vi godt kjent med den. Microsoft Office Excel 2007 Ble brukt som et hjelpe program for tegne fremdriftsplan I Gant form og for å utarbeide arbeidsplanen. Raskt og enkelt. ArgoUml v0.24 Gratis og enkel tegneprogram for UML-diagrammer. Mye brukt under planleggingfasen og underveis hvor det ble utviklet en del diagrammer. 9 av 38

10 Notepad Ble tatt raske og korte notater underveis. Ble brukt en del for raskt titting av kildekode filer. Enkel og vennlig program. Adobe Photoshop CS Profesjonelt bildebehandlingsprogram. Programvaren er ikke gratis, men har en 30dagers prøveperiode. Denne programvaren ble kjempenyttig ved grafisk design av Web-løsningen. Paint Alltid vært der for å gjøre kjappe endringer i grafikk bilder. DbDesigner 4 Open source visuelt database designer for MySql. Her ble det utviklet ER-modell for web løsningen vi utviklet. Gratis og enkel program som har betydd mye for prosjektet vårt. Notepad ++ v4.9 Her ble selve løsningen utviklet. Dette er en Gratis og raskt programvare. Lar en redigere både tekstfiler, CSS-stilark og hva enn det måtte være. PHPMyAdmin Ble brukt som et hjelpeverktøy for å administrere MySql databasen gjennom et Webgrensesnitt. Selv om vi brukte mysql sitt kommandolinje program, var denne programvaren nyttig i blant for raske endringer og spørringer Utviklingsteknologi HTML HTML er vi nesten nødt til å bruke for skape brukergrensesnittet. PHP PHP er et server-side script. Det vil si at koden ligger på serveren og blir kjørt derfra. Når en bruker kommer og ser på nettsiden, vil han ikke se kildekoden, men den html-teksten som PHP-koden genererer. PHP er et nyttig verktøy til å lage dynamiske websider. Med PHP får vi også programmere mot database som er svært viktig i denne oppgaven. Og PHP er gratis. MySql Verdens mest populære åpen - source database. Vi brukte dette til å opprette database og kommunisere mot den. 10 av 38

11 Ajax Ajax, Asynchronous JavaScript and XML, er veldig populær for tiden pga dens måte å kommunisere med serveren. Vi brukte Ajax for å øke nettsidenes interaktivitet, hastighet og brukskvalitet der vi følte vi trengte. Javascript og DOM Selv om vi brukte Ajax, ble også ren javascript brukt en god del for å tilføre dynamiske elementer til nettsidene vi lagde. DOM kommer også i bilde, fordi vi brukte det for å hente de objektene vi trengte for å manipulere med Javascript. CSS Ble brukt til å definere utseende på filer skrevet i HTML. Fungerer med andre som stilark for HTML. Med CSS kunne vi skille layout koden fra selve programkoden slik at vi hadde bedre kontroll over denne delen. Dette gjorde også at det ble mer oversiktlig for utvikleren Prosjektorganisering Intern organisering Da vi skulle kom i gang med prosjektet bestemte vi oss for å fordele ansvaret for de forskjellige hoveddelene vi skulle jobbe med. Etter flere prosjektarbeid gjennom utdanningsperioden så vi viktigheten ved dette når vi kom til det store prosjektet. Derfor ble det straks dannet et prosjektansvarskart, vises lenger nede. Like etter ble det bestemt internt i gruppen om å ha faste møtedager. Vi måtte ta hensyn til de andre fagene vi hadde i dette semesteret. Derfor kom vi fram til å ha 3 faste møtedager i uken. Det ble: Mandager 10:00 14:00 Tirsdager 12:30 17:00 Torsdager 10:00 16:00 Siden skolen hadde noen grupperom for hovedprosjektarbeid, fikk vi reservert et fast rom som ble møtestedet for oss for disse dagene. Dersom vi skulle få tak i hverandre utover møtetiden vår, var alle tilgjengelige på telefon og epost. 11 av 38

12 Veileder Vi fikk tildelt Ulf Uttersrud som veileder i starten av perioden. Med denne veilederen hadde vi en fast møte dag en gang i uken. Veilederen vår har fulgt opp prosjektet vårt fra et nært hold og sikret et hensiktmessig fremdrift. Under møte med veilederen legges det fram statusen i prosjektet. Og veilederen pleier å komme med innspill i form av gode råd og god og inspirerende veiledning. Vi er veldig takknemlig for all støtten og hjelpen vi har fått fra Ulf Uttersrud. 12 av 38

13 Prosjektansvarskart Ansvarsområde Hovedansvarlig Delansvarlig Prosjektleder Saba Programmering Nithiwarman Subaranchan Web-utvikling Saba Nithiwarman Web-design Subaranchan Nithiwarman Modellering Saba Subaranchan, Nithiwarman Dokumentasjon Subaranchan Saba Back-up Nithiwarman Saba, Subaranchan Testing Nithiwarman Saba, Subaranchan Slik ansvarskartet viser, ble det tildelt en hovedansvarlig og delansvarlig. Delansvarlig ble satt opp fordi vi regnet med hjelp fra hverandre ved de forskjellige delene Sikkerhetskopiering Det ble foretatt backup av alt vi laget hovedsakelig på en ekstern harddisk. I tillegg hadde vi en USB-brikke for småe og midlertidige backup, hvor vi kunne hente kjapt dataene fra. Sikkerhetskopiering var viktig for at data ikke skulle gå tapt. 13 av 38

14 6.07 Brukergrensesnitt Low fidelty prototype Low fidelty prototype trenger ikke å se ut som selve grensesnitte som skal bli utviklet, så lenge det utfører det samme handlingen. Tanken med low fidelty prototype er at vi skal få tilbakemeldinger om samspillet mellom grensesnitt og brukeren ved å evaluere en fidelty prototype. Vi tok hensyn til disse tilbakemeldinger vi fikk av testpersoner som vi har utført en test på dette. Vi valgte å sette med studenter fra andre retningslinjer ved HiO til å teste prototypen vårt som ikke er hyppige databrukere. Vi valgte å lage low fidelty prototype av noen sentrale sider av vår web applikasjon. Figur 10 Admins nyhet side 14 av 38 Figur 11 Kursdeltager laste opp innleveringer

15 15 av 38

16 7 Kravspesifikasjonen og dens rolle Kravspesifikasjonen beskriver bakgrunn for og formål med systemet vi skal bygge, hvilke behov som finnes og hvilke tekniske rammer prosjektet skal gjennomføres innenfor. Derfor har den hatt en sentral rolle gjennom hele prosjekt perioden Utviklingen og endringene av kravspesifikasjon Arbeidet med kravspesifikasjon kom like etter at vi hadde gjennomført forprosjektrapporten. Vi fikk vite noen av de hovedfunksjonaliteten av oppdragsgiveren vår,, allerede ved de første møtene vi hadde med dem. Selv om var klare i sine hovedfunksjonaliteten, fikk vi friheten til å legge til alt etter som vi fant det hensiktmessig for løsningen. Og det var et ønske fra dem vi skulle komme med forslag til utvidelser og implementering av disse funksjonaliteten i løsningen. Et godt dokumentert forprosjektrapport var et godt utgangspunkt for å komme i gang med kravspesifikasjon. Med dette klarte vi å danne et bilde som gjorde at utviklingen av kravspesifikasjon til enklere jobb. Som påpekt over var det også en stor fordel at vi hadde et av gruppemedlemmene ansatt hos oppdragsgiveren. Basert på alt dette ble det utarbeidet et første utkast til kravspesifikasjon. Dette ble lagt fram til oppdragsgiveren og noe små endringer ble foretatt etter dette møtet. Den oppdaterte kravspesifikasjonen er et selvstendig dokument og er å finne som en del av sluttrapporten Kravspesifikasjonens rolle Kravspesifikasjon har hatt en sentral rolle i utviklingen av denne løsningen. Ved tvil og andre tifeller har den vært til stor hjelp. Den har minnet oss mye ved hver titting av den, hva vi skal få gjort og den har gitt ideer for hvordan vi skal gi form for noen funksjoner. Som for eksempel ved hjelp av kravspesifikasjon fikk vi dannet oss navigasjonsmodeller for hvordan vi kan bygge nettsidene og hvordan de skal henge sammen. Med andre ord, kravspesifikasjon har vi hatt bruk for gjennom hele perioden alt fra implementeringsdel til og med dokumenteringensdel Kravspesifikasjonen og det ferdige produktet Venter til slutt Vi har innfridd alle kravene til oppdragsgiveren vår. Slik oppdragsgiveren ønsket seg fikk vi lagt til flere funksjonalitet enn det som ble krevd. Vi fikk implementert flere funksjoner som var hensiktmessige og naturlige å ta med. Dette kommer fram i kravspesifikasjon sammen med de hovedfunksjonaliteten oppdragsgiveren ønsket seg. 16 av 38

17 8 Risikofaktorer 8.01 Risikofaktorer Risiko Type Beskrivelse Endring i antall gruppemedlemmer Prosjekt Endring i ledelse Prosjekt Gruppemedlemmer slutter, blir syke, ikke tar ansvar (før prosjektet er ferdig) Ny ledelse med andre/flere krav Arbeidsfordeling Prosjekt Endring i systemet Prosjekt Undervurdering Prosjekt Endring i teknologi Forespørsel Pris Prosjekt Forretning Prosjekt Tidsberegning Prosjekt Konkurranse Forretning Påkjenninger innenfra/utenfra Prosjekt / Forretning Software Prosjekt CASE verktøy Arbeidsforhold Produkt Prosjekt Skeivt, der et medlem må gjøre hele jobben Bruker lenger tid på gjennomføring Prosjektet har blitt undervurdert/feilvurdert Ny teknologi overtar Større eller lavere enn akseptert Høyere eller lavere enn akseptabelt Beregning av tid for kravet er feilvurdert Et konkurrerende produkt er på markedet før systemet er ferdig Systemet blir påvirket av andre ting (for eksempel vær, brann, strømbrudd, virus, tyveri osv.) Systemet blir ikke levert til avtalt tid Verktøyet dekker ikke behovene Dårlig arbeidsmiljø, lite samarbeid, støy, 17 av 38

18 8.02 Risikoanalyse Risiko Sannsy nlighet 0-1 Konsekvens 0-10 Rangering Følge Tiltak Forandring i ledelse 0,3 5 1,5 Alvorlig Flere møter Gruppemedlemm er blir syke 0,7 2 1,4 Alvorlig Lik kompetanse hos alle Gruppemedlemm er ikke gjør jobben sin Gruppemedlemm er slutter 0,4 3 1,2 Alvorlig Møter, samarbeide 0,05 6 0,3 Alvorlig Dårlig planlegging 0,2 5 1 Alvorlig Dårlig arbeidsmiljø 0,2 4 0,8 Alvorlig Tidspress 0,3 3 0,9 Støy i lokalet 0,5 3 1,5 Katastr ofal Alvorlig Lik kompetanse, møte, fordele jobben, samarbeide Møter, jobbe effektivt, kutte ned krav hvis mulig, samarbeide Møter, samarbeide, arrangere felles sammenkomst Møter, arbeide effektivt, kutte ned krav hvis mulig Møter, hindre støy Dårlig innemiljø 0,3 2 0,6 Alvorlig Kvalitetssikring 0,5 3 1,5 Mangel på kompetanse 0,4 5 2 Katastr ofal Alvorlig Tap av data 0, Angrep utenfra 0, ,5 Katastr ofal Alvorlig Angrep innenfra 0, ,5 Alvorlig Strømbrudd 0,1 7 0,7 Feil på hardware 0,2 6 1,2 Aksept abelt Alvorlig Forespørsel på en vare 0,4 3 1,2 Aksept abelt Systemfeil 0,3 6 1,8 Alvorlig Møter, lufting, rengjøring, Jevnlige kontroller Skaffe informasjon, prate med andre gruppemedlemmer Backup Brannmur, installere antivirusprogrammer Brannmur, installere antivirusprogram, passord Backup Tilgang til hardware Bestille i god tid, skaffe eksternt, ha som lagervare Kurs, lese dokumentasjon, 18 av 38

19 kontroller Møter, ha nok og riktig utstyr Tilfredsstillende utstyr 0,05 4 0,2 Alvorlig Budsjettsprik 0,4 5 2 Manglende antivirus programvare Vær 0,05 5 0,25 Katastr ofal Alvorlig Kontroll på møter, kutte ned krav hvis mulig Skaffe antivirus programvare 0,15 3 0,45 Streik 0,05 3 0,15 Katastr ofal Alvorlig Backup, følge med værmeldingen Møter Forseint forandring i programmet 0,3 5 1,5 Alvorlig Uprøvd teknologi 0,2 5 1 Systemet er ikke kompatibelt med hardware Brann 0, ,1 Katastr ofal Alvorlig 0, ,1 Alvorlig Møter, jobbe effektivt, bedre planlegging, endre krav hvis nødvendig Teste systemet flere ganger Skaffe riktig hardware som er kompatibelt med systemet Brannslukningsapparat, Sjekke ledninger og kontrollere sikringer, brannkurs 9 Utviklingsprosessen Da vi kom til selve utviklingsprosessen også kalt implementerings delen gikk det meste for seg ganske smertefritt, takket være den tiden og det arbeidet vi la under planleggingsfasen. Her var det bare å sette i gang med utviklingen ved å følge kravspesifikasjonen og de diagrammene vi hadde laget Use case og beskrivelser Use case modeller viser bruken og oppførselen av et system. Samtidig viser den hvem som er aktøren og hva systemet skal gjøre for dem. Vi utarbeidet disse use case diagrammene under planleggingen- og tidlig i utdypningsfasen av web- løsningen. Disse diagrammene har gått gjennom en del forandringer. Disse gir en rask oversikt over systemets primære funksjoner. Vi har derfor valgt å inkludere diagrammene og utvalgte use case beskrivelser her. 19 av 38

20 Figur 2 Diagrammet forteller hva systemet skal gjøre ved Gjesterside. 20 av 38

21 BESKRIVELSE BLI MEDLEM Use Case Bli medlem Aktør Gjesten Trigger Ny person ønsker å bli medlem. Pre - betingelser Gjesten må være +18 er ha foresatte id Post - betingelser 1. Profilen blir opprettet eller 2. Gjesten har fått feilmelding Normal hendelsesflyt Variasjoner Gjesten klikker seg inn på registrere linken Systemet viser skjema for å registrere seg. Gjesten fyller ut riktig info i skjemaet Gjesten trykker lagre knappen Systemet sjekker om alle nødvendige feltene er fylt Systemet sørger for å lagre profilen på riktig plass i minnen Systemet gir et bruker navn til gjesten 5a. alle feltene er ikke fylt inn 5a1. Systemet informerer dagligleder om at alle feltene ikke riktig fylt inn, og går ikke videre før det er gjort. 21 av 38

22 Figur 3 Diagrammet forteller hva systemet skal gjøre (kravene) ved Adminsider. 22 av 38

23 BESKRIVELSE BLI MEDLEM Use Case Bli medlem Aktør Gjesten Trigger Ny person ønsker å bli medlem. Pre - betingelser Gjesten må være +18 er ha foresatte id Post - betingelser 1. Profilen blir opprettet eller 2. Gjesten har fått feilmelding Normal hendelsesflyt Variasjoner Gjesten klikker seg inn på registrere linken Systemet viser skjema for å registrere seg. Gjesten fyller ut riktig info i skjemaet Gjesten trykker lagre knappen Systemet sjekker om alle nødvendige feltene er fylt Systemet sørger for å lagre profilen på riktig plass i minnen Systemet gir et bruker navn til gjesten 5a. alle feltene er ikke fylt inn 5a1. Systemet informerer dagligleder om at alle feltene ikke riktig fylt inn, og går ikke videre før det er gjort. 23 av 38

24 BESKRIVELSE LEGG TIL NYHETER Use Case Legg til nyheter Aktør Admin Trigger Ny Nyhet skal legges til Pre - betingelser Det har kommet en ny nyhet som skal legges til Post - betingelser 1. Ny Nyhet er legget til eller 2. Admin har fått feilmelding Normal hendelsesflyt Admin taster inn brukerpassord Systemet kommer inn på admin siden Admin trykker på Nyhet linken som ligger menyen til venstre. Systemet åpner den angitte linken med. Admin går til legg til nyhet fanen. Systemet henter frem den angitt fanen. Admin fyller ut det skjema med tittel, ingress, forfatter trykker legg til Systemet legger i databasen Systemet henter frem skjema for å legge til selveste nyheten Admin skriver inn nyhets tekst og trykker på legge til knappen Systemet legger til nyheten. Systemet gir beskjed om at nyheten er lagt til Variasjoner 1a. feil passord brukernavn 1a1. Systemet ber om å skrive passord brukernavn på nytt Relatert informasjon Svar på spørsmål er fritekst. 24 av 38

25 BESKRIVELSE REGISTRER KURS Use Case Registrer Kurs Aktør Admin Trigger Ny kurs skal registreres Pre - betingelser Det har kommet ny kurs som ikke er registeret Post - betingelser 1. Ny kurs er registrert eller 2. Admin har fått feilmelding Normal hendelsesflyt Variasjoner Admin taster inn brukerpassord Systemet går inn på admin sidene Admin klikker på kurs linken. Systemet åpner den angitte linken Admin klikker på registrer kurs fanen Systemet viser registrerings skjema Admin skriver inn nødvendig informasjonen Systemet sjekker om alle feltene er fylt Systemet gir beskjed om at kurset er registrert 1a. feil passord brukernavn 1a1. Systemet ber om å skrive passord brukernavn på nytt 8a. alle feltene er ikke fylt 8a1. Systemet informerer admin om hvilken felt som ikke er fylt, og går ikke videre før dette blir gjort Relatert informasjon Svar på spørsmål er fritekst 25 av 38

26 BESKRIVELSE REGISTRER UNDERVISER Use Case Registrer Underviser Aktør Admin Trigger Ny underviser skal registreres Pre - betingelser Det har kommet ny underviser som ikke er registeret Post - betingelser 1. Ny underviser er registrert eller 2. Admin har fått feilmelding Normal hendelsesflyt Variasjoner Admin taster inn brukerpassord Systemet går inn på admin sidene Admin klikker på underviser linken. Systemet åpner den angitte linken Admin klikker på registrer underviser fanen Systemet viser registrerings skjema Admin skriver inn nødvendig informasjonen Systemet sjekker om alle feltene er fylt Systemet gir beskjed om at underviser er registrert 1a. feil passord brukernavn 1a1. Systemet ber om å skrive passord brukernavn på nytt 8a. alle feltene er ikke fylt 8a1. Systemet informerer admin om hvilken felt som ikke er fylt, og går ikke videre før dette blir gjort Relatert informasjon Svar på spørsmål er fritekst og rullegardin BESKRIVELSE REGISTRER KURS PÅ UNDERVISER Use Case Registrer kurs på underviser Aktør Admin Trigger kurs skal registreres på en underviser Pre - betingelser Det er en kurs som ikke har underviser Post - betingelser 1. Kurs er registrert eller 2. Admin har fått feilmelding Normal hendelsesflyt Variasjoner Admin taster inn brukerpassord Systemet går inn på admin sidene Admin klikker på underviser linken. Systemet åpner den angitte linken Admin klikker på registrer kurs på underviser fanen Systemet viser registrerings skjema Admin skriver inn nødvendig informasjonen Systemet sjekker om alle feltene er fylt Systemet gir beskjed om at kurset er registrert 1a. feil passord brukernavn 1a1. Systemet ber om å skrive passord brukernavn på nytt 8a. alle feltene er ikke fylt 8a1. Systemet informerer admin om hvilken felt som ikke er fylt, og går ikke videre før dette blir gjort 26 av 38 Relatert informasjon Svar på spørsmål er fritekst

27 27 av 38

28 BESKRIVELSE REDIGER KURS Use Case Rediger Kurs Aktør Admin Trigger Admin ønsker å redigere eksisterende kurs Pre - betingelser Kurs er registrert Post - betingelser Normal hendelsesflyt Variasjoner Relatert informasjon 1. Kurs er redigert eller 2. Admin har fått feilmelding Admin taster inn brukerpassord Systemet gir beskjed om at admin er innlogget Admin klikker in på kurs linken Systemet åpner den angitte linken Admin klikker på oppdater/ slett fanen Systemet ramser opp alle kurs med oppdater knapp Admin klikker på oppdater knappen Admin oppdatere kurset Admin trykker på oppdatert knappen Systemet oppdaterer kurset 1a. feil passord brukernavn 1a1. Systemet ber om å skrive passord brukernavn på Svar på spørsmål kan være fritekst eller avkrysningsbokser med alternativer. 28 av 38

29 Figur 4 Diagrammet forteller hva systemet skal gjøre (kravene til) ved underviser sidene. 29 av 38

30 BESKRIVELSE LEGGE UT KURS INFO/ NYHETER Use Case Legge ut kurs info/ nyheter Aktør Underviser Trigger Underviser ønsker å legge ut kurs info / nyheter Pre - betingelser Underviser er logget inn i systemet Post - betingelser 1. Kurs info / nyheter blir lagt ut eller 2. Underviser har fått feilmelding Normal hendelsesflyt Relatert informasjon Underviser kikker på en bestemt kurs Systemer åpner kurssiden Underviser klikker på legg til info/ nyheter Systemet laster opp siden Underviser laster opp den ønskende filen Systemet laster opp den ønskende filen Svar på spørsmål kan være fritekst eller avkrysningsbokser med alternativer. Use Case BESKRIVELSE SLETTE KURSSTOFF Slette kursstoff Aktør Underviser Trigger Underviser ønsker å slette eksisterende kursstoff Pre-betingelser Observasjons data er registret Post-betingelser 1. kursstoff blir slettet eller 2. Underviser har fått feilmelding Normal hendelsesflyt Underviseren klikker på det bestemte kurset Systemet åpner kurssiden Underviser klikker på en bestemt kursstoff linken og sletter den. Systemet ber om bekreftelse. Underviser bekrefter. Systemet sletter det angitte kursstoffet. 30 av 38

31 Figur 5 Diagrammet forteller hva systemet skal gjøre (kravene til) ved sidene til en underviser. 31 av 38

32 BESKRIVELSE INNLEVERING Use Case Registrere innlevering Aktør Kursdeltager Trigger Kursdeltager ønsker å registrere en innlevering Pre - betingelser Kursdeltager er logget inn i systemet Post - betingelser 1. Innlevering registrert eller 2. Kursdeltager har fått feilmelding Normal hendelsesflyt Variasjoner 4a. alle feltene er ikke fylt 4a1. Systemet informerer admin om hvilken felt som ikke er fylt, og går ikke videre før dette blir gjort Relatert informasjon Kursdeltager kikker på innleveringer linken Systemer åpner innleverings skjema Kursdeltager fyller ut de nødvendige feltene Systemet sjekker om alle felter er fylt Systemet laster opp innleveringen Svar på spørsmål kan være fritekst eller avkrysningsbokser med alternativer. 32 av 38

33 9.02 Sekvensdiagram Sekvensdiagrammer modellerer hva som skjer i en prosess med hensyn på hvilke objekter som snakker sammen og i hvilken sekvens (rekkefølge) det skjer. Vi valgte å lage 3 utvalgte sekvensdiagrammer. Disse diagrammene viser hendelsesflyt i hver sin Use Case. Bli medlem Figur 6 33 av 38

34 Innlevering Figur 7 Registrer kurs Figur 8 34 av 38

35 9.03 ER-modell ER-modellen omfatter alle data som skal inngå i en database og er en abstrakt modell uavhengig av databasesystem. Vi har utviklet ER -modellen til 3NF. Under ser vi en modell med tabller som hører til databasen abtf_no: Figur 9 35 av 38

36 9 Avslutende del 9.01 Hva har vi lært Gjennom dette prosjektet har vi lært oss å jobbe mot et felles mål. Vi hadde en utfordring foran oss, fordi dette prosjektets omfang var relativt stort. Ingen av oss har gjort noen prosjekter på denne størrelsen før. I et prosjekt arbeider som dette her hvor flere individer er innblandet har sammenarbeid et sentral rolle, noe vi har innsett etter denne prosjekt perioden. Det å ha tålmodighet og lytte til hverandre er svært viktig. Nye innspill kan være forfriskende og kanskje kommer det fram noe som man selv ikke har tenkt på. Vi føler at dette er nøkkelen til sammenarbeid suksessen, hvert fall i vårt tilfelle. Denne sammenarbeides erfaringen har vært svært lærerik og vil bety mye for oss i frem tiden. Det å faktisk skulle levere et produkt til en kunde, er det største utfordringen, det skal virke slik etter oppgitte ønsker fra oppdragsgiver. Og folk må kunne stole på produktet og dets funksjonalitet. Brukerne av systemet har sine forventninger til produktet. Vi har derfor fått erfare hvor viktig det er med testing av programmet. Det var en drivkraft å vite at det vi gjorde skulle bli brukt til noe, ikke bare sett på for så å bli kastet. Vi har også innsett viktigheten av å dokumentere underveis. Det letter arbeidet i sluttfasen av prosjektet. Vi har lært å arbeide under tidspress og å ta avgjørelser om hva som skal prioriteres når noe må vike for noe annet. Vi oppdaget viktigheten av å arbeide strukturert å jevnt, samt å samarbeide for å utveksle erfaringer Vurdering av gruppen Gruppemedlemmene har mye tilfelles, noe som har ført til et trivelig og sunt arbeidsmiljø underveis i prosjektet. Kommunikasjonen/samarbeidet i gruppen har fungert bra, både via dagboken, telefonkonferanser, internett og på møter. Det har vært diskusjoner rundt enkelte avgjørelser, men ingen konflikter i gruppen. Diskusjonene har vi håndtert bra mellom oss. Det har blitt satt opp to obligatoriske møter i uken, all fravær skulle meldes til gruppelederen på forhånd, slik at det ikke blir noen misforståelser internt i gruppen. Gruppelederen står ansvarlig for å tilpasse møtene etter hvor mye arbeidsbehov det er, et møte kan godt gå på overtid hvis behovet er til stede. Oppmøte har gått greit selv om gruppemedlemmene har ulik timeplan, alle har vært fleksible og tigjenglige. 36 av 38

37 9.03 Konklusjon Med godt samarbeid i gruppen gjennom hele prosjekt perioden og med god planlegging i idefasen mestret vi dette prosjektet meget bra. Dette har vært en spennende og ny type prosjekt med tanke på dem vi er vant til før. Detter vært meget lærerik periode hvor vi har utforsket flere forskjellige og nye programmeringsspråk under et og det samme prosjektet. Selv om vi har hatt vanskelige tider har vi kommet ut av dette ved hjelp av veilederens støtte og den oppmuntrende holdningen hans, som vi setter stor pris på. Vi har hele tiden fokusert på at dokumentasjonen skal være detalj- og innholdsrik, slik at de som eventuelt skal videreutvikle programmet får en lettere jobb. Selv om dette ble noen ombestemmelser fra oppdragsgiverens side, ble dette taklet henholdsvis godt fra vår side. Dette hadde vi egentlig regnet med, siden det er ganske vandlig med små endringer i virkelige arbeides livet. Vi har vi hatt stort faglig utbytte av å arbeide med den teknologien vi har benyttet. Dette er, som studenter, den første web - applikasjonen vi har utviklet fra tanke til ferdig produkt, og både vi og vår oppdragsgiver er meget fornøyde med det resultatet vi har fått. 37 av 38

38 10 Kilder 10.1 Bøker Hovedprosjekter i data/it Dokumentasjonsstandard, av Ann-Mari Torvatn. Webprogrammering i PHP, Skrevet av Svend Andreas Horgen. Grunnleggende systemutvikling, Skrevet av Gunnar Gurholt og Thor E.Hasle Databaser, Skrevet av Kjell Toft Hansen og Tore Mallaug 10.2 Nettsider vedlegg Vedlegg 1 Navigasjonsmodeller 38 av 38

Kravspesifikasjon Gruppe nr ABTF

Kravspesifikasjon Gruppe nr ABTF 1 Presentasjon Tittel: Web-løsning for ABTF Utvikle en Web-løsning helt fra bunnen av, samt med en Oppgave: plattform som gir underviseren muligheten til å veilede og følge opp sine elever gjennom kurset.

Detaljer

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. 1 Sammendrag Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. Vår oppdragsgiver, ABTF hadde et ønske om en større web

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

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

Entobutikk 3.TESTRAPPORT VÅR 2011

Entobutikk 3.TESTRAPPORT VÅR 2011 3.TESTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne testrapport er skrevet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo, ingeniørutdanning, våren 2011. Rapporten beskriver testingen av hele

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

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

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender Hovedprosjekt Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport Presentasjon Sted og dato Oslo, Jan 9, 2011 Prosjekt tittel Periode K-skjema og ferie kalender Utvikle et registreringssystem

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

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

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

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

Forprosjektrapport. Gruppe Januar 2016

Forprosjektrapport. Gruppe Januar 2016 Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning

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

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

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg Forprosjektrapport Presentasjon Tittel Bakerman AS Website Oppgave Utvikle ett websted for Bakerman AS der hvor de kan promotere seg selv og kommunisere med kundene sine. Periode 4. Januar 2010 til 17.

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

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

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113)

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113) Forprosjektrapport Gruppe 14 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren 2015 Sted: Høgskolen i Oslo og Akershus Dato: 23.01.2015 Tittel: Gruppemedlemmer: Oppgave: Oppdragsgiver:

Detaljer

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg.

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg. Forprosjektrapport Presentasjon Tittel: Inventardatabase Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg. Prosjektperiode: 2/12-08 23/05-08. Prosjektgruppe:

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

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007.

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007. PROSJEKT NR. 2007-16 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Panther

Detaljer

Entobutikk 1.KRAVSPESIFIKASJON VÅR 2011

Entobutikk 1.KRAVSPESIFIKASJON VÅR 2011 1.KRAVSPESIFIKASJON VÅR 2011 1 DELKAPITTEL 1 INNLEDNING Kravspesifikasjonen er svært nyttig sett i forhold til produktet vi ønsker å utvikle. Dokumentet regnes som et av de viktigste i hovedprosjektet

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Forprosjektrapport For gruppe 20:

Forprosjektrapport For gruppe 20: Forprosjektrapport For gruppe 20: Kevin Johnny Galåen s135768 Ali Emre Yildirim s135573 Danh Tran s141712 Vibeke Askeland s141436 Fullført: 30.01.2009 Table of Contents Forprosjektrapport... 1 For gruppe

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

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

TESTRAPPORT - PRODSYS

TESTRAPPORT - PRODSYS TESTRAPPORT - PRODSYS PRODSYS-DATASYSTEM FOR ÅS PRODUKSJONSLAB AS GRUPPE 12 CHRISTOPHER CONRADI STEFFEN DIEDRICHSEN ROMAN KOVALENKO INFORMASJONSTEKNOLOGI, INGENIØRUTDANNINGEN, HØYSKOLEN I OSLO 1. FORORD

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

Use Case Modeller. Administrator og standardbruker

Use Case Modeller. Administrator og standardbruker Vedlegg 1 Use Case Modeller Administrator og standardbruker 2 Use case Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet

Detaljer

Hovedprosjekt 2011 HO912A. Securitas IT portal. Forprosjektrapport. Adeel Yousaf Khan s Mats Klingenberg Naustdal s Stig Arild Ysterud

Hovedprosjekt 2011 HO912A. Securitas IT portal. Forprosjektrapport. Adeel Yousaf Khan s Mats Klingenberg Naustdal s Stig Arild Ysterud Hovedprosjekt 2011 HO912A Securitas IT portal Forprosjektrapport Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335 Stig Arild Ysterud s155483 1 Innhold

Detaljer

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02 FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02 1 INNHOLDSFORTEGNELSE PRESENTASJON 03 SAMMENDRAG 04 BEDRIFT 05 Om bedriften 05 Dagens situasjon 05 MÅL OG RAMMEBETINGELSER 06 Funksjonalitet

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

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

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

Forprosjektrapport ElevApp

Forprosjektrapport ElevApp Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse

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

Forprosjektrapport Bacheloroppgave 2017

Forprosjektrapport Bacheloroppgave 2017 Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon

Detaljer

Styringsdokumenter. Studentevalueringssystem

Styringsdokumenter. Studentevalueringssystem Styringsdokumenter Studentevalueringssystem Forord Dette er en samling av alle styringsdokumentene gjennom prosjekt perioden. Styringsdokumentene er satt opp i rekkefølge i forhold til perioden de ble

Detaljer

Gruppe 43. Hoved-Prosjekt Forprosjekt

Gruppe 43. Hoved-Prosjekt Forprosjekt Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141

Detaljer

Forprosjekt. Høgskolen i Oslo, våren

Forprosjekt. Høgskolen i Oslo, våren Forprosjekt Høgskolen i Oslo, våren 2011 ------------------------------------------ Presentasjon Tittel: Oppgave: Database og nettside for Nor Dagligvarer Import AS Utvikle et databasesystem for bedriften

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

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. 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

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

Testdokumentasjon Presentasjon

Testdokumentasjon Presentasjon Testdokumentasjon 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

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

InfoRed Publisering. - produktbeskrivelse.  TalkPool WebServices Postboks Åneby InfoRed Publisering - produktbeskrivelse www.talkpool.no TalkPool WebServices Postboks 90 1484 Åneby InfoRed Produktbeskrivelse 2 Sammendrag InfoRed Publisering er produktet for å administrere en hel informasjonstjeneste,

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

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

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

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

Detaljer

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens

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

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

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

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

TESTRAPPORT   Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

Prosessrapport. IT-infrastruktur. Prosessrapport. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008

Prosessrapport. IT-infrastruktur. Prosessrapport. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008 IT-infrastruktur Prosessrapport Mathias Hagen Balagumar Rajaratnam Høgskolen i Oslo Avdeling for Ingeniører 23. mai 2008 Høgskolen i Oslo Hovedprosjekt i data, 2008 Gruppe 8 side 0 PROSJEKT NR. 08-08 Studieprogram:

Detaljer

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON CHARITY DOCTORS KRAVSPESIFIKASJON Hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo våren 2011 Gruppe 13 Muleha Nhonzi Harlem Tambwe Mufoncol Ruban Amuthalingam Page 1 of 6 1 Innledning 1.1 Innledning

Detaljer

Brukerveiledning. Madison Møbler Administrasjonsside

Brukerveiledning. Madison Møbler Administrasjonsside Brukerveiledning Madison Møbler Administrasjonsside 1 1. Forord 1.1 Produktet Produktet blir konstruert som et nytt produkt da kunde/bruker ikke har noe eksisterende løsning, derfor er dette den nåværende

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

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument

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

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

1. Introduksjon. Glis 13/02/2018

1. Introduksjon. Glis 13/02/2018 SDP GLIS Espen Buø Innholdsfortegnelse 1. Introduksjon... 2 2. Gruppebeskrivelse og ansvarsområder... 3 3. Risikoanalyse... 4 4. Hardware og softwarekrav for brukeren... 5 5. Behov for prosjektet... 6

Detaljer

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

Detaljer

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

Detaljer

Gruppe Forprosjekt. Gruppe 15

Gruppe Forprosjekt. Gruppe 15 Forprosjekt Gruppe 15 Marius Ylven Westgaard - s236797 - Anvendt Datateknologi Lise Janbu Eide - s236361 - Dataingeniør Lavanja Jeyenthiran - s236346 - Dataingeniør Kristian Pedersen - s236728 - Anvendt

Detaljer

Prosjektdagbok. Gruppe 9. Gruppemedlemmer. Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741)

Prosjektdagbok. Gruppe 9. Gruppemedlemmer. Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741) Prosjektdagbok Gruppe 9 Gruppemedlemmer Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741) Månedsoppsummering: Mai Arbeidet har vært tungt siden vi har måttet flytte

Detaljer

Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5 1 Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5 FRA LEVERANSE 1 (GRUPPE 2)...5 TILLEGG I FORUTSETNINGER... 5 REVIDERT UTGAVE AV SPESIFIKASJON FRA

Detaljer

Generell brukerveiledning for Elevportalen

Generell brukerveiledning for Elevportalen Generell brukerveiledning for Elevportalen Denne elevportalen er best egnet i nettleseren Internett Explorer. Dersom du opplever kompatibilitets-problemer kan det skyldes at du bruker en annen nettleser.

Detaljer

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter

Detaljer

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8 Testdokumentasjon 1 Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte

Detaljer

Kravspesifikasjon. 14. oktober 2002

Kravspesifikasjon. 14. oktober 2002 Kravspesifikasjon gruppe 42 Nils-Kristian Liborg (brukergrensesnitt), Bente Brevig (beskrivelser, aktørbeskrivelser, diagram, kvalitetssikring), Tom Olav Bruaas (beskrivelser), Eirik Lied (beskrivelser,

Detaljer

Prosessrapport. Nettside, Webshop og Beregningsmodell. Magnus Eriksen, s Øyvind Schjelderupsen, s Peder Sundbø, s141795

Prosessrapport. Nettside, Webshop og Beregningsmodell. Magnus Eriksen, s Øyvind Schjelderupsen, s Peder Sundbø, s141795 Prosessrapport Nettside, Webshop og Beregningsmodell. Eriksen, s141765 Schjelderupsen, s141758 Sundbø, s141795 1 Innholdsfortegnelse Forord...3 Innledning...3 Gruppen...3 Bedriften...3 Tanker rundt prosjektet...4

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

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

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

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

Entobutikk 2.PRODUKTRAPPORT VÅR 2011

Entobutikk 2.PRODUKTRAPPORT VÅR 2011 2.PRODUKTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne produktrapporten inneholder detaljer om produktet vi har utviklet samt programmessig oppbygning, illustrasjoner, diagrammer over produktet, funksjoner

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

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

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

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

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

Byggeweb Prosjekt Brukerveiledning Arbeidsområdet

Byggeweb Prosjekt Brukerveiledning Arbeidsområdet BIM2Share AS Byggeweb Prosjekt Side 1/12 Byggeweb Prosjekt Brukerveiledning Arbeidsområdet Innhold 1 Arbeidsområdet... 2 1.1 Strukturen i arbeidsområdet... 2 1.2 Opplasting av filer... 2 1.3 E-post-varsling

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

Detaljer

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00)

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00) Dagbok Januar Uke 2 (7.1-11.1) Vi har lest halvveis på standard dokumentasjon og jobbet med forprosjektrapport. Vi har hatt vårt første møte med den interne veilederen vår Tor Hasle. Vi fortalte om at

Detaljer

Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri. Av Anders Refsahl

Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri. Av Anders Refsahl Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri Av Anders Refsahl Innhold Firma/Oppgavestiller Problemstilling Hvorfor denne oppgaven Løsning av oppgaven Resultater Videre arbeid Firma/Oppgavestiller

Detaljer

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009

AirDog Hovedprosjekt ved Høgskolen i Oslo 2009 2 1 Innledning Vi har jobbet i en iterativ utviklingsprosess og hver funksjon i applikasjonen har blitt fortløpende testet før den har blitt godkjent i Pivotal Tracker. Testene i denne rapporten er utført

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

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord. Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey

Detaljer