Avdeling for ingeniørutdanning Høgskolen i Oslo. Prosjektrapport Systemutvikling (lo138a) Høst Taxisentral

Størrelse: px
Begynne med side:

Download "Avdeling for ingeniørutdanning Høgskolen i Oslo. Prosjektrapport Systemutvikling (lo138a) Høst 2010. Taxisentral"

Transkript

1 Avdeling for ingeniørutdanning Høgskolen i Oslo Prosjektrapport Systemutvikling (lo138a) Høst 2010 Taxisentral Gruppe 19 Prosjekthjemmeside: Forfattere: Larsen, Mads s Hegge, Magnus s Bergan, Bjørn s Baisa, Abdi s Dato:

2 Sammendrag Denne rapporten beskriver et prosjekt i faget systemutvikling på HiO. Prosjektet ble gjennomført høsten 2010 av en gruppe bestående av Magnus Dahl Hegge, Abdi Baisa, Mads Larsen og Bjørn Bergan. Rapporten inneholder dokumentasjon og diagrammer som beskriver planleggingsfasen av utviklingen av et taxisentralsystem. Videre arbeid med systemet etter planleggingsfasen er ikke beskrevet her da dette ikke var en del av prosjektoppgaven.

3 Innhold Sammendrag Innhold Versjonslogg 1 Introduksjon 1.1 Bakgrunn 1.2 Mål for Prosjektet 1.3 Omfang av løsning 1.4 Suksesskriteria 1.5 Antagelser 2 Tilpasning av utviklingsmodell 2.1 Beskrivelse av utviklingsmodell 2.2 Begrunnelse for tilpasninger 3 Analyse 3.1 Kravspesifikasjon 3.2 UseCase-modell UseCase-diagram Detaljerte UseCase beskrivelser 3.3 Domenemodell 3.4 Aktivitetsdiagram 4 Design 4.1 Klassediagram 4.2 Sekvensdiagram Normalflyt Avvik 4.3 Logisk arkitektur 4.4 Brukergrensesnitt 5 Vurdering 5.1 Vurdering av foreslått løsning 5.2 Vurdering av valgt utviklingsmodell 5.3 Vurdering av eget prosjektarbeid 6 Konklusjon 7 Litteraturliste

4 Versjonslogg Versjon Dato Forfatter(e) Beskrivelse av versjon Larsen, Mads s Hegge, Magnus s Bergan, Bjørn s Baisa, Abdi s Prosjektrapport er ferdig.

5 1 Introduksjon 1.1 Bakgrunn Problemstillingen, Hvordan planlegge utviklingen av et Taxisentralsystem? ble valgt fordi vi ville ha et realistisk mål for prosjektet. En taxisentral er avhengig av mange forskjellige elementer, som alle er nødvendige for å nå ett enkelt mål: Skaffe kunden transport fra A til B. For å nå dette enkle målet, må systemet være så automatisert som mulig og være enkelt for brukeren å forholde seg til. Selv om systemet er enkelt, ser vi for oss mange utfordringer som denne oppgaven vil frembringe, noe som vil gi oss nødvendig erfaring til en forhåpentligvis lang karriere innenfor IT. Da taxisystemer i dag hovedsakelig består av en kunde som ringer til en sentral, en ansatt på sentralen som tar i mot bestillingen og ringer en taxi for å videreformidle denne, ser vi for oss en stor forbedring hvis man kunne automatisere hele eller deler av denne prosessen. Dette er basert på vår egen erfaring med taxisentraler, vi har som de fleste andre hatt store problemer med å skaffe oss taxi til tider, både fordi man ikke får svar på taxisentralen og fordi man opplever at hele taxisystemet arbeider for sakte. Med vårt system vil alle som ønsker det kunne bestille en taxi ved hjelp av forskjellige medier uten å prate med en ansatt på taxisentralen. Dette mener vi vil kunne forhindre problemene med at man ikke får kontakt med taxisentralen i perioder med stor etterspørsel etter taxi. Vårt system har mulighet til å gjennomføre bestillinger selv. Vi anbefaler allikevel at ansatte er tilgjengelige for å ta i mot bestillinger for de som ønsker å prate med en virkelig person eller for å diskutere problemer kunder har hatt eller lignende. Vi ser for oss at alle taxiene i bedriften vil være utstyrt med en GPS og en nettverksforbindelse til sentralen. Taxiene vil da sende sin posisjon hvert minutt slik at sentralen har et godt bilde av hvor alle bilene befinner seg. I sentralen skal det være et kartsystem som regner ut kjøredistanse mellom kunder og taxi, og finner taxien med kortest kjøredistanse / tid til kunde. Ved å automatisk velge den ledige taxien som er nærmest kundens posisjon ved hjelp av GPS vil vi også tro at en taxi bedrift vil kunne spare penger på bensinutgifter.

6 1.2 Mål for Prosjektet 1. Systemet skal ha mulighet til å utføre ca. 90 % av sentralens oppgaver automatisk. a. Systemet skal kunne ta i mot bestilling via telefon, SMS, e-post og internett. b. Systemet skal lagre bestillinger automatisk innen 1 sekund etter de mottas. Bestillinger lagres i 24timer etter taxituren er over. c. Systemet skal lokalisere nærmeste ledige taxi av riktig type (f.eks. maxitaxi) ut i fra en database som inneholder informasjon om bilene og GPS. Søket starter med et område på 1 km². Hvis ingen ledige taxier blir funnet utvides søket med 2 km² per forsøk til en taxi blir funnet. Et forsøk skal ikke ta mer enn 5 sekunder. Hvis søket tar lenger tid enn 20 sekunder vil kunden få beskjed om dette per telefon, SMS eller , i forhold til hvordan taxien ble bestilt. d. Systemet skal videresende bestillinger til taxi innen 2 sekunder etter de har kommet inn og blitt registrert. e. Systemet skal sende ordrebekreftelse til kunde i løpet av 5 sekunder etter sjåføren har godtatt oppdraget. f. Det skal være mulig å utføre systemets oppgaver manuelt om det er behov for dette. g. En kundebehandlingsavdeling holdes åpen for å snakke med kunder om klager o.l. og for å ta imot bestillinger over tlf. h. Når systemet mottar en avbestilling vil denne automatisk sendes til gjeldene taxi i løpet av 3 sekunder. i. Systemet skal ha mulighet til å lagre reservasjoner. Dette vil gjøre det mulig for en kunde å bestille en taxi til senere. 2. Systemet skal være enkelt å bruke og ha kort opplæringstid a. Grensesnittet skal ha svært enkelt og oversiktlig design, med ikke flere en 3 alternativer per oppgave og en lineær fremgangsmåte. Ved å holde systemets design relativt likt det de fleste er vant til (Windows o.l.) vil grensesnittet ikke virke fremmed, og personer med grunnleggende datakunnskaper vil forstå det raskere.

7 3. Systemet vil ha rask behandlingstid, være svært pålitelig og ha lave krav til hardware a. Da det er en liten mengde informasjon som skal sendes fra kunde til sentral og videre til taxi (ca kb) vil dette skje i løpet av få sekunder. Maks 10. b. Dersom sjåføren ikke svarer på bestillingen i løpet av 1 minutt vil bestillingen avbrytes og sendes til neste bil. c. Programmet har lave krav til minnestørrelse, da det vil ha et ganske enkelt GUI. På klientmaskiner vil programmet ta opp mellom 5 og 10 MB RAM, og installasjonen tar ca. 200MB. 4. Prosjektet skal være ferdig utviklet og klart til presentasjon a. Alle aspekter av systemet er ferdig planlagt. b. Prosjektrapport er ferdig skrevet.

8 1.3 Omfang av løsning Et taxisentralsystem har mange forskjellige aspekter som ikke bare omfatter data. En fungerende telefonsentral vil være nødvendig, som kan rute samtaler fra eventuelle kunder til første ledige taxi, eller til et kundesenter. For at samtalen skal bli rutet til første ledige taxi, er det et par kriterier som må oppfylles: 1. Taxien må være innenfor en fornuftig avstand fra kunden, slik at kunden ikke må vente på at sjåføren f.eks. skal kjøre igjennom Oslo by. 2. Taxien må ha en måte å sende et klar signal, eller opptatt signal, til sentralen på for å gi beskjed om at den er ledig. Siden taxifirmaer har sjåfører i feltet til alle døgnets tider, er man avhengig av et kundesenter som er døgnåpent alle dager i uken. Dette er for at kunder aldri skal måtte vente på at en bil blir ledig for å få lagt inn sin bestilling dersom man ikke ønsker å gjennomføre en automatisk bestilling. Det viktigste på dette punktet er å ha et effektivt og godt bemannet kundesenter, men det er ikke noe som vi tar med i denne oppgaven, da vi vil fokusere på kommunikasjonen biler imellom, sentral til bil, bil til sentral og kunde til bil. Samtalene som kommer inn til kundesentralen vil ikke være nødvendig for oss å håndtere. Prosjektets omfang blir da alle elementer som skal fungere sammen for at en kunde skal komme seg inn i baksetet på taxien, med unntak av selve samtalen kunden utfører med sentral, eller bil.

9 1.4 Suksesskriteria Samarbeid For å gjennomføre et prosjekt så omfattende og langvarig som dette sammen med andre er godt samarbeid viktig. Samarbeid mellom gruppemedlemmene har fungert godt på tidligere prosjekter og det er derfor lite sannsynlig at problemer oppstår, men usannsynlige problemer burde også inkluderes i en risikoplan. Planlegging Planlegging av prosjekter er svært viktig. Uten en god fremdriftsplan vil arbeidet ofte bli gjort i siste liten og det vil gå ut over kvaliteten. God timeplan God planlegging inneholder gjerne en detaljert timeplan som beskriver hva gruppemedlemmene skal jobbe med. God risikoplan Når man jobber med et prosjekt over flere uker og måneder er det viktig å ha en oversikt over mulige problemer som kan oppstå og løsninger for disse. Gruppa burde være forberedt på både svært sannsynlige problemer og høyst usannsynlige problemer. Online tilgjengelighet Svært mye av arbeidet som blir gjort gjøres på internett. Rapport, notater o.l. ligger på nettet og innleveringer skjer på internett. Problemer som kan oppstå i sammenheng med dette burde være en del av risikoplanen.

10 1.5 Antagelser Ut ifra hva som er oppført under omfang, er det noen antakelser som vi må ta. Hvis vi skal planlegge et fullt fungerende taxisentral system vil det være alt for mange elementer å håndtere for gruppen vår alene. Som nevnt tidligere er det snakk om en fungerende telefonsentral, et døgnåpent hovedkontor og i de fleste tilfeller en fungerende SMS sentral. Dette vil gjøre oppgaven særdeles tung hvis alt skal bli implementert. Det vi vil fokusere på er selve kommunikasjonssystemet mellom hovedkontor, kunder og taxier. Det vil da være kommunikasjon direkte mellom kunder og taxi som står i fokus, mens samtalene mellom kunder og sentral ikke vil være vesentlige, da bestillingen uansett vil bli sendt til nærmeste ledige taxi fra sentralen. En annet aspekt vi ikke vil ta tak i er betalingssystemet. I prinsippet er ikke betalingen viktig for denne rapporten, da det er et separat system som er koblet opp mot BBS og ikke sentralen. Det vil si, i prinsippet betaler alle kunder kontant. Vi tar utgangspunkt i et taxifirma med en betraktelig mengde sjåfører og biler, som vil kunne dekke en mellomstor by. Dette vil kreve et enkelt kommunikasjonsverktøy mellom biler og sentral, slik at meldinger, og oppdatert status, kan bli sendt fram og tilbake. Et vanlig taxiselskap har gjerne en hjemmeside, og vi tar derfor utgangspunkt i at det allerede finnes en fullt fungerende hjemmeside som oppfyller de kravene vi ønsker at den skal ha. Hvis en kunde bestiller fra hjemmesiden vil det i prinsippet være helt likt som om kunden har ringt inn til hovedkontoret. Derfor er det ikke nødvendig for oss å utvikle denne. Som nevnt tidligere vil uansett bestillingen bli sendt videre til en taxi fra sentralen.

11 2 Tilpasning av utviklingsmodell 2.1 Beskrivelse av utviklingsmodell Vi har valgt å benytte en tilpasset versjon av UP som systemutviklingsmodell. Denne modellen setter et agilt rammeverk som lett kan tilpasses, og begrenses, ved de krav som settes av målet. Modellen er en iterativ og inkrementell utviklingsprosess. Fasene (ide, utdypning, konstruksjon og overgang) gjennomgår en rekke gjentakelser. Hver iterasjon vil gi et intervall som gir en forbedring, eller utvidet versjon, av systemets funksjonalitet satt mot den forrige utgaven. Dette systemet skal ikke implementeres, så bredden av disipliner vil være begrenset. Krav og design, gjennomgå flere gjentakelser etter hvert som modellen utvikles. Prosessen er UseCasedrevet så det er de kommende brukerne av det ferdige resultatet som står i sentrum. Designet av programmet og prosessene i hele systemet skal basere seg på hvordan det vil komme bruker til nytte. 2.2 Begrunnelse for tilpasninger Opplagte tilpasninger vi vil gjøre er å fjerne implementering, drifting o.l. da dette ikke er en del av vår prosjektoppgave. De ulike fasene: Idefasen: I denne fasen får vi en oversikt over hva hovedmål, krav og omfanget til prosjektet skal være. Vi blir enige om hvordan vi skal jobbe med prosjektet, og identifiserer eventuelle risiki. Andre elementer inneholder, men er ikke begrenset til, lønnsomhetsanalyse, kostnadsanalyse, med fokus på problemforståelse og prosjektbeskrivelse, som skal samles til 1. iterasjon av oppgaven. Utdypningsfasen: I denne fasen tar vi en grundigere gjennomgang av prosjektet etter å ha fått tilbakemelding etter 1. iterasjon. Her skal kravspesifikasjonene, målene og omfanget korrelere slik at det kan utvikles en basis, men tilstrekkelig god, arkitektur for hvordan systemet skal utformes. Risiki er identifisert og håndtert. Hovedfokus vil være å ha en klar, forståelig,

12 fremgangsmåte for hvordan prosjektet skal løses, representert ved hjelp av UseCases, sekvens-, domene- og klassediagram. Fasen vil bestå av flere iterasjoner, og vil granskes nøye før vi beveger oss videre til neste fase. Konstruksjonsfasen: I denne fasen vil det jobbes med analyse og design av systemet i henhold til omfang, krav og GUI m.m. Dette skal representeres ved hjelp av skisser og ferdigstilte diagrammer. I denne fasen skal alle spesifikasjoner være ferdigstilt, og point of no return skal være nådd etter siste iterasjon. I teorien skal programmeringen også være ferdigstilt, men det vil ikke bli utført noe programmering i denne oppgaven. Overgangsfasen: Vi kommer ikke til å ta med implementering og drifting som en del av utviklingsprosessen, derfor er overgangsfasen noe irrelevant for oss. Innleveringsiterasjoner: Dette er en oversikt over innleveringer og endringene vi gjorde etter disse. De inneholder ikke de interne iterasjonene av oppgaven som vi selv har hatt før innleveringene ble gjennomført. F.eks. forskjellige versjoner av use-cases osv. 1. Iterasjon: Vi startet arbeidet med prosjektplan versjon 0.2 og påbegynte/ferdigstilte del 1-6. Etter innlevering fikk vi beskjed om at vi ikke hadde levert riktig rapport, og at arbeidet måtte gjøres igjen. 2. Iterasjon: Etter at vi fikk beskjed om at innleveringen var feil, jobbet vi igjen med prosjektplanen slik at den inneholdt rett informasjon. Kommentarene til vår innlevering hjalp oss å få en bedre pekepinn om hvor faglærer ville at vi skulle ta prosjektet. Vi skrev om del 1-6 i henhold til kommentarene, leverte inn og planen ble godkjent, men fortsatt med noen mangler som bør forbedres. Bl.a. Mål og Beskrivelse var for dårlig og måtte gjøres igjen. 3. Iterasjon: Etter 2. iterasjon fikk vi beskjed om at de funksjonelle og ikke funksjonelle kravene var gjort feil og måtte forbedres. Etter gjennomgang med studentassistenten så gjorde vi det på nytt. UseCase beskrivelsene var for svake, og måtte gjøres mer detaljert. Hvis vi ikke fikset dette ville ikke innlevering 3 bli godkjent. Etter forbedringene begynte vi arbeidet med 4.iterasjon

13 4. Iterasjon: Etter 3. iterasjon fikk vi kommentarer om en rekke småfeil på et UseCase diagram, klassediagrammet og domenemodellen. I tillegg til dette fikk vi beskjed om diverse mangler ellers i rapporten. Vi fikk hjelp av en student assistent til å forstå feilene våre bedre og forbedret de feilene som var nevnt. Flere av diagrammene våre måtte endres på, men da det ble klart hva som var galt gikk dette raskt. Når feilene var rettet skrev vi del 5 og 6 i rapporten, oppdaterte hjemmesiden og kvalitetssikret hele rapporten.

14 3 Analyse 3.1 Kravspesifikasjon Funksjonelle krav: Når det legges inn en bestilling vil systemet lokalisere nærmeste taxi ved å bruke en oversikt over ledige taxier innenfor et område på 1 km², hvis ingen taxier er innenfor dette område utvides arealet med 2 km² til en ledig taxi blir funnet. Når kunden legger inn en bestilling og den er registrert vil systemet automatisk videresende denne til den aktuelle taxien. Da dette er en svært lite krevende prosess vil dette fullføres på under 4 sekund. Hvis en kunde avbestiller en taxi skal systemet ta i mot avbestilling og videresende denne til bilen. Dette vil ta under 3 sekunder. Hvis en kunde ønsker å reservere en bil til et senere tidspunkt skal systemet ta i mot og lagre denne bestillingen. Dette vil ta under 5 sekunder for kunden å utføre. Når en kunde bestiller en taxi skal systemet automatisk velge riktig type taxi (f. eks maxi taxi hvis det er bestilt til flere en 4 personer) ut i fra informasjonen i bestillingen. Dette vil ta under 2 sekunder å utføre. Når en sjåfør har godtatt et oppdrag og systemet registrerer bilen som ikke ledig vil det automatisk sendes en ordrebekreftelse til kunden. Dette vil ta under 5 sekunder. Når kunden har betalt for reisen vil taxien automatisk etter betaling bli registrert som ledig i systemet. Dette vil ta under 2 sekunder. Systemet vil inneholde et enkelt brukergrensesnitt som er spesiallaget for kundebehandlere. Her vil kundebehandlere som tar i mot klager på telefon kunne skrive inn disse, og lagre de. Systemet vil da lagre disse i en database hvor hver klage har et unikt ID nummer. Kunden vil få oppgitt dette ID nummeret for senere referanser. Via brukergrensesnittet vil kundebehandlerne også ha mulighet til å hente frem gamle klager ved hjelp av klageid nummeret. Klagene lagres ut i fra kategori, de forskjellige kategoriene kan identifiseres med forskjellige typer klageid nummer. Hvordan klagene skal håndteres er opp til bedriften.

15 Ikke-funksjonelle krav: Systemet skal ha rask behandlingstid. Fra en bestilling kommer inn til systemet videresender denne til nærmeste taxi, går det under et sekund. Deretter skal taxisjåføren svare på om han tar oppdraget eller ikke. Det gjør han innen 1 minutt, dersom systemet ikke får noe svar innen 1 minutt, sendes forespørselen til nest nærmeste taxi, osv. Programmet som skal brukes av de ansatte skal være svært brukervennlig dvs. veldig lik Windows miljøet for lett å kunne læres av folk lave datakunnskaper. Programmet må ha kontinuerlig nettverkstilgang for å registrere lokasjonsdata. Programmet har lave krav til minnestørrelse, da det vil ha ganske enkelt GUI. På klientmaskiner vil programmet ta opp mellom 5 og 10 MB RAM, og installasjonen tar ca. 200MB. Programmet er laget med tanke på høy ytelse og god pålitelighet, da det til tider er stor trafikk hos en taxisentral. Vi sikter på 99 % oppetid, og responstiden vil som nevnt over være på under 1 på kommunikasjon fra taxi til systemet, og fra kunde til systemet. Totalt fra kunde sender inn bestilling til han får bestillingsbekreftelse skal det gå 2-5 sekunder, dersom det er lite trafikk på mobilnettverk/mailservere osv. Deretter skal kunde få bekreftelse på hvilken taxi som er på vei etter ca. 1 min. Max 5 min. Eksterne krav Systemet registrerer taxiers posisjon, sjåfører skal informeres om dette. Siden dette er en døgnåpen bedrift, må det være tilstrekkelig med ansatte for å kunne håndtere skiftrotasjonene i henhold til arbeidsmiljøloven.

16 3.2 UseCase-modell UseCase-diagram

17

18

19 3.2.2 Detaljerte UseCase beskrivelser UseCase Aktør Trigger Prebetingelser Postbetingelser Normal hendelsesflyt Bestilling Sentral / kunde / taxi Kunde bestiller taxi 1. Systemet er i funksjon 2. Kunden ønsker taxi. 3. Kunden har informasjon om hvordan han / hun bestiller taxi (f.eks. kodeord som må brukes i sms). 4. Kundens bestilling kommer frem. 1. Taxi er på vei til kunden. 2. Sentralen har registrert taxien som ikke ledig. 3. Kunden har mottatt ordrebekreftelse og vet at en taxi er på vei. 1. Kunde bestiller Taxi ved hjelp av telefon, sms, eller fra hjemmesiden. 2. Sentral / Systemet sjekker om ønsket taxi type er ledig i området. 3. Sentral registrerer bestillingen og videresender den til bilen. 4. Taxisjåføren godtar oppdraget. 5. Sentralen registrerer aktuell taxi som ikke ledig. 6. Sentralen sender ordrebekreftelse til kunden.

20 Variasjoner 1. Ingen taxier er ledig i nærheten av kunden. 2. Ingen taxisjåfører ønsker å ta oppdraget. 3. Ingen ledige taxier av typen kunden ønsker.

21 UseCase Aktør Trigger Prebetingelser Postbetingelser Normal hendelsesflyt Finn ledig taxi Taxi / sentral Sentral ønsker å lokalisere den taxien som er nærmet en adresse og er ledig. 1. Systemet kjører. 2. Systemet har internettilgang. 3. GPS i taxi fungerer. Ledig taxi funnet 1. Sentral ber systemet finne en ledig taxi i nærheten av en adresse. 2. Systemet lokaliserer taxier i et område rundt adressen. 3. Søket utvides hvis ingen taxi er nærme nok. 4. Sentral velger nærmeste ledige taxi. Variasjoner 1. Ingen ledig taxi funnet. 2. Ingen taxi funnet i området.

22 3.3 Domenemodell

23 3.4 Aktivitetsdiagram

24

25 4 Design 4.1 Klassediagram

26 4.2 Sekvensdiagram Normalflyt

27 Avvik Sekvensdiagrammet for avvik er likt det til normal flyt. Dette fordi hvis en taxi ikke er ledig eller en taxisjåfør sier nei til et oppdrag gjentas løkken til en taxi finnes. Den søker igjennom taxiene etter distanse til henteadresse, de nærmeste taxiene først.

28 4.3 Logisk arkitektur Gruppen har valgt dette designet for logisk arkitektur av systemet. Arkitekturen viser en logisk oppbygning og anvendelse av systemet. Øverst er klientens brukergrensesnitt og de forskjellige

29 kommunikasjonsmediene for å ta imot bestillinger. Det øverste laget bruker den tekniske delen for å utføre handlinger. Domene delen vil hele tiden bruke den tekniske delen for å utføre/lagre og endre på de forskjellige dataene. Vi lagde først et annet design som vi valgte ikke å bruke. Det så mer ut som en tegning enn et diagram, og vi likte ikke måten det presenterte seg på. Vi tok i bruk Gliffi som programvare for å lage den nye versjonen av arkitekturen, og likte hvor enkelt dette designet ble for å demonstrere systemets arbeidsrelasjoner. Man kan lett se hvordan alt henger sammen, og på hvilke nivåer de opererer.

30 4.4 Brukergrensesnitt Vi har valgt å holde designet på vårt brukergrensesnitt så enkelt som overhode mulig for å forsikre oss om at personer med liten erfaring med data vil kunne forstå hvordan man gjennomfører en bestilling raskt og med lite opplæring. Da det skal være mulig å gjennomføre hele bestillingsprosessen manuelt, måtte alle oppgavene inkluderes, men da dette ble svært mange valgte vi å begrense det til 3 valg per side og programmet fikk derfor flere sider. Vi følte dette var et bedre alternativ siden mange alternativer på en side kan virke forvirrende og skremmende for noen. Vi har inkludert både en fremover pil og en bakover pil, siden det kan oppstå situasjoner hvor man må gå tilbake og endre på tidligere valg, ved for eksempel misforståelser mellom kunde og kundebehandler eller hvis en feil har oppstått. Tekstboksen på høyre side av vårt brukergrensesnitt inneholder informasjon om knappen man har valgt, og teksten her vil bli vist fra man gjør valget til man går til neste side i programmet. Skisse 1. Førsteutkast For å illustrere hvordan vi ønsket at brukergrensesnittet skulle se ut mens vi diskuterte diverse design lagde vi denne skissen.

31 Skjermbilde av foreslått brukergrensesnitt Dette skjermbildet er av vårt forslag til programmets brukergrensesnitt. Vi har valgt å holde det så enkelt som mulig og relativt likt Windows miljøet for å gjøre det enklere å forstå.

32 5 Vurdering 5.1 Vurdering av foreslått løsning Denne rapporten er skrevet med tanke på at en eller flere programmerere skal lese den og forstå hvordan vi ønsker at systemet skal konstrueres. Vi mener selv at rapporten beskriver dette på en tilfredsstillende måte ved hjelp av en detaljert kravspesifikasjon og oversiktlige diagrammer, men vi følte at vi ikke kunne avgjøre om dette var godt nok selv, siden vi har skrevet rapporten, og derfor har et større grunnlag for å forstå hvordan vi mente at det skulle utformes. Vi valgte derfor å involvere en tredjepart som kunne gi oss et nytt perspektiv. Han ble informert om at vi hadde behov for å vite om det kom tydelig frem hvordan vi ønsket å konstruere systemet og hvilke oppgaver det skulle ha mulighet til å utføre. Med svært lite forklaring forsto han hvordan vi ønsket at det endelige systemet skulle være og mente det ikke var alvorlige mangler i rapporten. Når vi fikk en bekreftelse på at en person som ikke hadde vært involvert i prosjektet forsto diagrammene og hva vi ønsket å formidle konkluderte vi med at kvaliteten på vårt arbeid var god nok og vi startet arbeidet med konklusjonen og kvalitetssikringen. 5.2 Vurdering av valgt utviklingsmodell Etter å ha jobbet med dette prosjektet i lengre tid har vi kommet fram til at utviklingsmodellen vår, med tilpasninger som er gjort, fungerte veldig bra. Vi har hatt en dynamisk prosess over lengre tid som har munnet ut i denne rapporten. I starten var det problematisk å få et grep om utdypningsfasen. Det var flere misforståelser om hva vi faktisk ville fram til, men etter å ha tatt noen runder her så har det gått veldig bra. Underveis i prosjektet har vi generelt fulgt utviklingsmodellen slik den skal være, det har vært noen tilbakeslag, f.eks. å bevege oss videre til neste fase, før en fase er ferdig, men det er en del av lærdommen vi tar fra faget. Vi klarte ikke å finne en utviklingsmodell som kunne ha fungert bedre til å gjennomføre dette prosjektet. Siden vi ikke skulle programmere noe, så var det den teoretiske delen av utviklingsprosessen som har vært viktig. Dette gjør utviklingstyper som MSF, XP og Scrum vanskelig å gjennomføre, siden de alle er avhengig av brukertestinger og tilbakemelding til teamet fra arbeidsgiver.

33 5.3 Vurdering av eget prosjektarbeid I løpet av dette prosjektet har gruppen fungert godt. Alle gruppemedlemmene har klart å samarbeide, og det har alltid vært mulig å diskutere problemer med andre gruppemedlemmer og å komme med kritikk av hverandres arbeid. I planleggingsfasen av vårt prosjekt lagde vi en detaljert og omfattende risikoplan som har sørget for at det alltid har vært en løsning når det har oppstått problemer. Det har for eksempler vært sykdom innad i gruppen, men når dette har blitt et problem har oppgavene som skulle vært utført av personen som ble syk fordelt mellom resten av gruppen. De som hadde minst arbeidsmengde i denne perioden fikk da en større del av den syke personens oppgaver en de som hadde mer å gjøre. Problemer med sykdom er uunngåelig i prosjekter som dette, men vi føler vi har klart å håndtere dette svært bra. Det har til tider oppstått problemer når arbeidsmengden har blitt så stor at gruppen har fått for dårlig tid til å gjennomføre en omfattende kvalitetssikring av arbeidet før innlevering. Dette har da ført til en større arbeidsmengde før neste innleveringsdato fordi feil må rettes o.l. Problemer med arbeidsmengder i andre fag har også påvirket arbeidet med prosjektet. Til tross for dette har gruppen klart å hente seg inn før siste innlevering, og kvalitetssikringen av denne ble gjort i god tid og i flere omganger. Det har også oppstått problemer da det av og til har vært vanskelig å forstå nøyaktig hva som er gjort galt i rapporten på grunn av noe uspesifikke kommentarer på innleveringer. Når dette har oppstått har det gått med tid til å få en grundigere forklaring av personen som rettet oppgaven. At det til tider kan bli en stor arbeidsmengde burde vært forutsett og bedre planlagt, for eksempel kunne gruppen startet arbeidet med prosjektet tidligere hver måned, men som nevnt tidligere fikk gruppen organisert arbeidet bedre etter hvert som det viste seg at det var svært nødvendig for å klare å bestå faget. Det har ikke oppstått andre betydelige problemer en de som allerede er nevnt. Hadde det derimot gjort det, mener vi at vi hadde vært godt forberedt, da vi hadde en plan for å minimalisere effekten av alle problemene vi antok at kunne oppstå, f.eks. datakræsj, tap av et gruppemedlem, konflikter og leveringsproblemer. Underveis i prosjektet har vi opplevd at noen av oppgavene har vært vanskeligere å gjennomføre en andre. Vi arbeidet svært mye med å strukturere mål og kravspesifikasjon. Vi slet med å forstå nøyaktig hvordan det var ønsket at dette skulle gjøres, og fikk flere ganger beskjed om at dette burde gjøres bedre. Før vi endelig fikk godkjent disse punktene hadde vi brukt både lærebok,

34 internett, forelesningsnotater og studentassistender for å skaffe oss en god forståelse av hvordan det endelige resultatet burde se ut. Arbeidet med diagrammer har generelt vært vellykket, noe som kan være en konsekvens av at vi har sett på dette som en av de mest spennende delene av prosjektet. Noen av diagrammene har inneholdt feil, særlig i de førte fasene av prosjektet, men arbeidet med disse har for det meste gått svært bra.

35 6 Konklusjon For dette prosjektet valgte vi å sette Hvordan planlegge utviklingen av et Taxisentralsystem? som målsetning. Dette var et åpent mål, men allikevell krevende. For og virkelig oppnå dette målet var det nødvendig å skaffe seg en god forståelse av faget systemutvikling, og relevant pensum. Når oppgaven ble løst, og rapporten var klar til levering, hadde vi fått den grunnleggende kunnskapen som var nødvendig for å oppnå målet vi hadde satt for prosjektet. Utviklingen har vært noe tidkrevende, og har til tider vært særdeles frustrerende, siden vi aldri var helt sikre på om det som ble levert i de ulike iterasjonene av rapporten var korrekt. Selv med noen tilbakeslag underveis klarte vi å forholde oss til de tidsrammer som ble satt opp i planleggingsfasen uten store vanskeligheter. Takket være denne planleggingen klarte vi også å forutse den relativt store arbeidsmengden som dette prosjektet ville skape, noe som forårsaket et budsjett som ikke ble sprengt grunnet uforutsette hendelser, feil kalkulering av tid eller tilbakefall på grunn av feil i systemets struktur. Underveis i prosjektet har vi hele tiden jobbet for å finne ut hva, om det eventuelt er noe i det hele tatt, som kunne bli gjort bedre. Dette har ført til en flytende kvalitetskontroll over hele prosjektets gang. Nå som prosjektet er ferdigstilt, så mener vi at det eringeting som kan bli gjort bedre. Det er litt problematisk å føye til noe under dette punktet, for hvis vi kommer på noe som kan gjøres bedre, så gjøre vi det før konklusjonen blir ferdigskrevet. Det var viktig for oss å oppnå målet om å automatisere en svært stor del av taxisentralens oppgaver. Ved hjelp av automatisering kan et system driftest mye lettere, med færre kostnader og høyere effektivitet. Ved hjelp av diagrammer og kravspesifikasjon har vi påvist at dette kan gjennomføres og vil gi bedriften mange fordeler i forhold til de som fortsatt baserer seg på callcenter uten automatisering. Vi har valgt å ha svært omfattende mål for systemet vi har planlagt. Som man kan se i del 1.2. i denne rapporten er det oppført mange og detaljerte mål. Prosjektets hovedfokus har alltid vært å oppfylle disse målene på en realistisk gjennomførbar måte. Når systemet var ferdig planlagt var målene vi satte opp i startfasen av prosjektet oppnådd og systemet inneholdt alle elementene som var nødvendig for å oppnå funksjonaliteten vi ønsket. Hendelsesflyten i taxisentralens operasjoner har gjort det mulig for oss å planlegge et system med en svært oversiktlig struktur. Som man kan se i våre diagrammer, er det ikke vanskelig å forstå hvordan systemet skal arbeide, og i hvilken rekkefølge operasjonene skal utføres. Det har også vært en prioritet og holde rapporten oversiktlig og diagrammene enkle nok til at

Avdeling for Ingeniørutdanning Høgskolen i Oslo. Prosjektplan. Systemutvikling (lo138a) Høst 2010. Taxisentral. Forfattere:

Avdeling for Ingeniørutdanning Høgskolen i Oslo. Prosjektplan. Systemutvikling (lo138a) Høst 2010. Taxisentral. Forfattere: Avdeling for Ingeniørutdanning Høgskolen i Oslo Prosjektplan Systemutvikling (lo138a) Høst 2010 Taxisentral Gruppe 19 Prosjekthjemmeside: http://gruppe19.lmdahl.no/ Forfattere: Bergan, Bjørn s161593 Baisa,

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

Vakt og lønnssystem - Rema 1000

Vakt og lønnssystem - Rema 1000 Avdeling for ingeniørutdanning Høgskolen i Oslo og Akershus Prosjektrapport Systemutvikling (LO138A) Høst 2011 Vakt og lønnssystem - Rema 1000 Gruppe 8 Forfattere: Andreas Baaserud, s169982 Ravi Agnihotri,

Detaljer

S Y S T E M U T V I K L I N G ( L O 1 3 8 A )

S Y S T E M U T V I K L I N G ( L O 1 3 8 A ) A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S P R O S J E K T R A P P O RT S Y S T E M U T V I K L I N G ( L O 1 3 8 A ) H Ø S T 2011 GRUPPE 24:

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. Gruppe 34. Magnus Dahl Hegge s153549

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549 Forprosjektrapport Gruppe 34 Bjørn Bergan Abdi Baisa Mads Larsen s161593 s156140 s156151 Magnus Dahl Hegge s153549 Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste

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

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

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

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

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

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

Planlegging og dokumentasjon

Planlegging og dokumentasjon Planlegging og dokumentasjon Edgar Bostrøm. - leilighetsnotat, etterutdanningskonferansen, 17.02.2010, noe revidert. Generelle kommentarer: Begrunnelse for hovedområdet Planlegging og dokumentasjon : o

Detaljer

Derfor er forretningssystemet viktig for bedriften

Derfor er forretningssystemet viktig for bedriften Innhold Derfor er forretningssystemet viktig for bedriften... 2 Når er det på tide å bytte forretningssystem?... 2 Velg riktig forretningssystem for din bedrift... 3 Velg riktig leverandør... 4 Standard

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

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

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

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

INSTALLASJONSVEILEDNING FOR KALK2010 KALKULASJONSPROGRAM

INSTALLASJONSVEILEDNING FOR KALK2010 KALKULASJONSPROGRAM INSTALLASJONSVEILEDNING FOR KALK2010 KALKULASJONSPROGRAM NORGES BYGGMESTERFORBUND Brukerveiledning: http://www.kalk2010.no/help.aspx Support: http://www.kalk2010.no/contact.aspx MINIMUMSKRAV Kalk2010 er

Detaljer

DOMAINING AS GRUPPENR.24

DOMAINING AS GRUPPENR.24 A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O PROSJEKTPLAN SYSTEMUTVIKLING (LO138A) HØST 2011 DOMAINING AS GRUPPENR.24 Forfattere: s171633, Truc Tran, s171171, My

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA Sist oppdatert 18.02.2010 INNHOLD INNHOLD... 1 HVA ER CABINWEB... 2 HVA KAN DU BRUKE CABINWEB TIL?... 3 HVA ER NYTT I CABINWEB VERSJON 2.0...

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

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

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

Humanware. Trekker Breeze versjon 2.0.0.

Humanware. Trekker Breeze versjon 2.0.0. Humanware Trekker Breeze versjon 2.0.0. Humanware er stolte av å kunne introdusere versjon 2.0 av Trekker Breeze talende GPS. Denne oppgraderingen er gratis for alle Trekker Breeze brukere. Programmet

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

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

1 INNLEDNING... 2. 1.1 Om Altinn... 2. 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3. 2.1 Nedlasting... 3. 2.2 Registrering...

1 INNLEDNING... 2. 1.1 Om Altinn... 2. 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3. 2.1 Nedlasting... 3. 2.2 Registrering... INNHOLD Mamut for Altinn INNHOLD 1 INNLEDNING... 2 1.1 Om Altinn... 2 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3 2.1 Nedlasting... 3 2.2 Registrering... 5 2.3 Opprett en bruker... 7

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

PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300

PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300 Mal for prosjektbeskrivelse PROSJEKTBESKRIVELSE/PLAN PROSJEKT OR2-300 Evt. detaljer i vedlegg med referanse frå de ulike delene Prosjekt (tittel): Sol energi. Dato, signatur:.. Lasse Moen Ola Sundt Melheim....

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

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

Datastrukturer og Algoritmer

Datastrukturer og Algoritmer TOD 063 Datastrukturer og Algoritmer Forside fra lærebokens Nord Amerikanske utgave Tar for seg praktisk problemstilling: Hvordan håndtere containere som blir lastet fra containerskip i en travel havn

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

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 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 prosjektets rammer

Detaljer

INF2120 Prosjektoppgave i modellering. Del 1

INF2120 Prosjektoppgave i modellering. Del 1 INF2120 Prosjektoppgave i modellering Del 1 Håkon Ulvestad haakonu@ifi.uio.no Jonas Winje jonaw@ifi.uio.no Amaia Santacoloma amaiac@ifi.uio.no Rakel Johnsen rakelj@ifi.uio.no Våren 2006 Innledning Prosjektoppgaven

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

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten +

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten + INF 2120 Innlevering 1 Levert av Gruppe 4 Anders Bakken (andeba) Are O. Pedersen (arep) Daniel M. Wittwer (danielmw) Naima Akram (naimaa) Ronnie Østgaard (ronnieo) Kravspesifikasjoner til trafikanten +

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

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

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 27. mai, 2011 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 27. mai, 2011 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Åsveien 9, 3475 Sætre Telefon: +4731305656 Mobiltelefon: +4790840810 Faks: +4731305852 E-post: rontech@rontech.no www.rontech.no.

Åsveien 9, 3475 Sætre Telefon: +4731305656 Mobiltelefon: +4790840810 Faks: +4731305852 E-post: rontech@rontech.no www.rontech.no. Åsveien 9, 3475 Sætre Telefon: +4731305656 Mobiltelefon: +4790840810 Faks: +4731305852 E-post: rontech@rontech.no www.rontech.no Gekab Merkesystem - Snarvei til mer effektiv merking Systemet er beregnet

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

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. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

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

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

Brukerdokumentasjon Promed Online Booking

Brukerdokumentasjon Promed Online Booking Brukerdokumentasjon Promed Online Booking Informasjon om ProMed og online booking... 2 Systemkrav... 2 Internettoppkobling (hvis du bruker Norsk Helsenett)... 3 Internettoppkobling (hvis du ikke bruker

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

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

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

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er

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

https://nhh.itslearning.com/

https://nhh.itslearning.com/ e-læringssystemet https://nhh.itslearning.com/ Sist oppdatert 08.09.2009 10:07 1 1. Hva er It s Learning? It's Learning er et e-læringssystem hvor du finner elektronisk informasjon om alle våre kurs/studier,

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

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING 1 Word 1.1 Gjør ting raskt med Fortell meg det Du vil legge merke til en tekstboks på båndet i Word 2016 med teksten Fortell meg hva du vil gjøre.

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

Prosjektplan. Tonje Brubak, 080437 Per Kristian Svevad, 100202 10HBINDA - Høgskolen i Gjøvik - 22. januar, 2013

Prosjektplan. Tonje Brubak, 080437 Per Kristian Svevad, 100202 10HBINDA - Høgskolen i Gjøvik - 22. januar, 2013 Prosjektplan Tonje Brubak, 080437 Per Kristian Svevad, 100202 10HBINDA - Høgskolen i Gjøvik - 22. januar, 2013 0. Innholdsfortegnelse 0. INNHOLDSFORTEGNELSE... 2 1. MÅL OG RAMMER... 3 1.0. BAKGRUNN...

Detaljer

µθωερτψυιοπασδφγηϕκλζξχϖβνµθωερτ ρτψυιοπασδφγηϕκλζξχϖβνµθωερτψυιο πασδφγηϕκλζξχϖβνµθωερτψυιοπασδφγ ξχϖβνµθωερτψυιοπασδφγηϕκλζξχϖβν

µθωερτψυιοπασδφγηϕκλζξχϖβνµθωερτ ρτψυιοπασδφγηϕκλζξχϖβνµθωερτψυιο πασδφγηϕκλζξχϖβνµθωερτψυιοπασδφγ ξχϖβνµθωερτψυιοπασδφγηϕκλζξχϖβν θωερτψυιοπασδφγηϕκλζξχϖβνµθωερτ ψυιοπασδφγηϕκλζξχϖβνµθωερτψυιοπ ασδφγηϕκλζξχϖβνµθωερτψυιοπασδφγη ϕκλζξχϖβνµθωερτψυιοπασδφγηϕκλζξχ Prosjektplan / Arbeidsplan ϖβνµθωερτψυιοπασδφγηϕκλζξχϖβνµθ Bacheloroppgave

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

Brukerhåndbok CabinWeb Bruker

Brukerhåndbok CabinWeb Bruker Brukerhåndbok CabinWeb Bruker Applikasjon: CabinWeb Laget av: Delfi Data AS (www.delfi.no) Versjon 1.11 Dato 06.11.2006 Historie 1.1 Revisjon utgave 1.11 Lagt til Kartmodul Innledning CabinWeb er et system

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

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

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

Visma.net Approval. Nyheter og forbedringer versjon 1.40.1

Visma.net Approval. Nyheter og forbedringer versjon 1.40.1 Visma.net Approval Nyheter og forbedringer versjon 1.40.1 Visma.net Approval - Nyheter og forbedringer versjon 1.40.1 Innhold Visma.net Approval 1.40.1... 2 Brukergrensesnitt... 2 Prosessoversikt Informasjon

Detaljer

Meeting Reservation System

Meeting Reservation System Meeting Reservation System Oblig1c-1 Gruppe 8 Frode Revheim, Sven-Erik Nilsen, Terese Haug, Rolf Vassdokken Krav Vise møteromsoversikt Vise tilgjengelige rom for en gitt tidsperiode og med tilgjengelig

Detaljer

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000 Drosjesentralen I-120: Obligatorisk oppgave 2, 2000 Frist Mandag 20. November 2000 kl.10:00, i skuff merket I120 på UA. Krav Se seksjon 4 for kravene til innlevering. Merk krav om generisk løsning for

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer

Gruppe 33 - Hovedprosjekt

Gruppe 33 - Hovedprosjekt Gruppe 33 - Hovedprosjekt s188080 Joakim Rishaug s181130 Sondre Sparby Boge s188098 Martin Hagen s178816 Lars Erik Kasin 1 av 7 Kravspesifikasjon Forord Kravspesifikasjonen utformes både for kunden, og

Detaljer

Visma ERP POS. Utvid økonomisystemet med en brukervennlig kasseløsning

Visma ERP POS. Utvid økonomisystemet med en brukervennlig kasseløsning Visma ERP POS Utvid økonomisystemet med en brukervennlig kasseløsning En moderne og funksjonell kasseløsning kasseløsning Det lønner seg å utvide økonomisystemet med integrert kassefunksjonalitet. I alle

Detaljer

Brukerveiledning. for student hjemmeeksamen

Brukerveiledning. for student hjemmeeksamen Brukerveiledning for student hjemmeeksamen Oppdatert 27. mars 2015 1 Innhold Innledning Pålogging Godkjente nettlesere Din oversikt over prøver og eksamener Gjennomføre eksamen Navigere i eksamensoppgaven

Detaljer

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes Krav og terminologi Krav Et utsagn som gjelder produktet vi skal teste og evaluere. Vi skal vurdere graden av sannhet i kravet opp mot funksjonen i produktet Funksjonelle krav Beskriver tjenestene produktet

Detaljer

Utforskeren. Stille gode spørsmål

Utforskeren. Stille gode spørsmål Utforskeren Stille gode spørsmål Utforskeren 8-10 En «mal» for timene? Kognisjon og metakognisjon I praksis handler kognisjon om kunnskap (hvor mange meter er det i en kilometer), ordforståelse (hva er,

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

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

Brukermanual for nettskolen

Brukermanual for nettskolen Brukermanual for nettskolen Versjon 2.2 28.3.2012 Innhold 1 Innledning... 3 2 Innlogging og din profil... 3 2.1 Personlig profil... 3 3 Hovedlinker... 4 3.1 Infoside... 4 3.1.1 Eksamensinfo... 4 3.1.2

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

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300 Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 27. juni, 2006 Eksamen

Detaljer

Installere programvare gjennom Datapennalet - Tilbud

Installere programvare gjennom Datapennalet - Tilbud NTNU Trondheim Norges Teknisk- Naturvitenskapelige Universitet Datapennalet Installere programvare gjennom Datapennalet - Tilbud Påmeldingsinfo Hvordan tjenesten fungerer Krav til utstyr Uttesting av programvareformidling

Detaljer

Prosjektplan Bacheloroppgave 2014. André Moen Libæk, Erik Sørlie, Vegar Tangen

Prosjektplan Bacheloroppgave 2014. André Moen Libæk, Erik Sørlie, Vegar Tangen Prosjektplan Bacheloroppgave 2014 André Moen Libæk, Erik Sørlie, Vegar Tangen Innhold 1. Mål og rammer... 3 1.1 Bakgrunn... 3 1.2 Prosjektmål... 3 1.2.1 Effektmål... 3 1.2.2 Resultatmål... 3 1.3 Rammer...

Detaljer

Start et nytt Scratch-prosjekt. Slett kattefiguren, for eksempel ved å høyreklikke på den og velge slett.

Start et nytt Scratch-prosjekt. Slett kattefiguren, for eksempel ved å høyreklikke på den og velge slett. Norgestur Introduksjon Bli med på en rundreise i Norge! Vi skal lage et spill hvor du styrer et helikopter rundt omkring et kart over Norge, mens du prøver å raskest mulig finne steder og byer du blir

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

trinn! Instruksjon For Windows 7.4 og nyere versjoner.

trinn! Instruksjon For Windows 7.4 og nyere versjoner. Lag din fotobok i 10 enkle trinn! Instruksjon For Windows 7.4 og nyere versjoner. 1 Velg ut de beste bildene dine. Velg ut bildene du vil bruke i fotoboken og legg dem i en separat mappe på PC en. (Minimum

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

Kommuneforlaget Avvikshåndtering Administratordokumentasjon Versjon 2.1.0 Table of Contents

Kommuneforlaget Avvikshåndtering Administratordokumentasjon Versjon 2.1.0 Table of Contents Table of Contents Tildel utildelte avvik... 2 Tildel forfalte avvik...3 Søk etter bruker... 4 Opprett lokal bruker...5 Endre lokal bruker... 6 Endre avviksbehandler for bruker... 7 Synkroniser brukerinformasjon

Detaljer

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015 Brukerveiledning For importapplikasjon til Naturbase Versjon 17. mars 2015 Innhold 1. Innledning... 2 1.1 Rutiner for å legge data inn i Naturbase... 2 1.2 Leveranseinstrukser... 3 2. Om leveranse av data

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

Intelligente Handlevogner

Intelligente Handlevogner Intelligente Handlevogner Kravspesifikasjon Prosjekt I Systemutvikling ved Høgskolen I Gjøvik våren 2005. Audun Klundby Asbjørn Konstad Hans Einar Øverjordet 03HBINDA Kilde: www.windowsfordevices.com 1.

Detaljer

GS1 Validering. effektiv validering av elektroniske meldinger

GS1 Validering. effektiv validering av elektroniske meldinger GS1 effektiv validering av Implementering av Implementering av Fordeler for Fordeler brukereforav GS1 validering GS1 Norway GS1 Norway Nye brukere opplever ofte implementeringen av elektroniske meldinger

Detaljer

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

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

Brukte studieteknikker

Brukte studieteknikker Brukte studieteknikker Forfattere Celine Spjelkavik Michael Bakke Hansen Emily Liane Petersen Hiske Visser Kajsa Urheim Dato 31.10.13! 1! Innhold 1. Problemstillinger...3 2. Innsamlingsstrategi.4 2.1 Metode..4

Detaljer