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

Størrelse: px
Begynne med side:

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

Transkript

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

2 INNHOLD INNHOLD Introduksjon Bakgrunn mål Prosjektbeskrivelse Antagelser og begrensninger utviklingsmodell Suksesskriteria Risiko og tiltak rapportoversikt. 4 2 beskrivelse av omfang prosjektorganisasjon og plan prosjektorganisasjon roller og ansvar milepæler og aktiviteter oversikt prosjekt plan arbeidsmåte ( way of working ) prosjekthjelpemidler. 5 4 Kostnader admin rapportering og møter dokumenthåndtering timeregistrering informasjon. 6 6 referanser.. 6

3 VERSJONSLOG Versjon Dato Forfatter(e) Beskrivelse av versjon Larsen, Mads s Hegge, Magnus s Bergan, Bjørn s Baisa, Abdi s Kap 1 ferdig Kap 2 ferdig Kap 3-6 ferdig

4 1 Introduksjon. 1.1 Bakgrunn Problemstillingen, Hvordan planlegge utviklingen av et Taxisentral system 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å det være mulig å for kunden å ha et lettforståelig system å forholde seg til, men 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. 1.2 Mål Målet for prosjektet vil være og øke effektiviteten til et taxifirma med 25-30%. Dette skal gjøres ved hjelp av et godt og enkelt kommunikasjonsvertøy mellom kunde, sentral og bil, som har lav responstid. Det skal kunne bestilles taxi ved hjelp av kortest mulig interaksjon mellom kunde og sentral/bil. Kunden skal med dette systemet ha mulighet til å bestille taxi både med sms, telefon og e-post. Kunden skal få bekreftelse på bestilling umiddelbart og respons med en gang en bil har blitt sendt ut. Systemets hendelsesforløp vil være at sentralen mottar bestilling, finner nærmeste ledige taxi av riktig type (taxi med plass til riktig antall passasjerer, bagasje o.l.), sentralen sender bestillingen til taxien og bekreftelse til kunden. Systemet vil selvfølgelig også inneholde funksjoner for å avbestille taxi og registrering av klager. Vi forventer å legge frem løsningen i løpet av Desember Hovedmål Prosjektet skal være ferdig utviklet og klart til presentasjon Kunden skal ha mulighet til å bestille taxi ved hjelp av telefon, internett eller sms. Delmål 1 Behandlingstiden for bestilling av taxi med det nye systemet vil være 12% raskere. Kunden skal få bekreftelse på bestilling via SMS eller e-post i løpet av få sekunder. Delmål 2 Opplæringsperioden for systemet skal maksimum være 5 dager. Lengde på kurs for å gi nye ansatte en rask innføring i systemet anbefales å være 4 timer.

5 Delmål 3 Taxibedrifter vil spare ca 20% i bensinutgifter på grunn av kortere reiseveier siden nærmeste taxi alltid tildeles.

6 1.3 Prosjektbeskrivelse Dette prosjektet handler om å planlegge og vise fremgangsmåten for utviklingen av et system. Vi har valgt å planlegge et taxisentralsystem som skal lokalisere taxier, vise status (opptatt eller ledig), sende bestillinger til taxi og registrere klager. Systemet skal kunne ta i mot bestillinger fra sms, e-post og telefon, og kunden skal alltid få bekreftelse på bestilling, om dette er på sms, e- post eller telefon avhenger av bestillingsmetode. Dagens systemer er svært tradisjonelle og sliter ofte med å ta i mot bestillinger i perioder med stor pågang. Bestillinger taes ofte i mot kun over telefon og samtalen med kunden og bestillingen tar gjerne for lang tid. Med vårt system vil det ideelt sett kun være antall taxier som kan føre til at kunder ikke får lagt inn bestilling. I noen tilfeller vil selvfølgelig antall ansatte på sentralen være relevant, da det er begrenset hvor mange bestillinger en ansatt kan håndtere. Vi ser for oss at et system som brukes av en taxisentral vil ha svært høye krav til brukervennelighet, pålitelighet og effektivitet da man ønsker å bli ferdig med en bestilling så raskt som mulig for å kunne ta i mot neste. Derfor har vi valgt å gi dette en høy prioritet.

7 1.4 Antagelser og begrensninger 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 smssentral. Dette vil gjøre oppgaven særdeles tung hvis alt skal bli implimentert. Det vi vil fokusere på er selve kommunikasjonssystemet mellom hovedkontor, kunde 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. Dvs, 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 taxifirma har gjerne en hjemmeside, vi tar utgangspunkt i at det allerede finnes en fullt fungerende hjemmeside som allerede 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 at 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. 1.5 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 gjentagelser etter hvert som modellen utvikles. Prosessen er Use Casedrevet 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. 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.

8 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, fremgangsmåte for hvordan prosjektet skal løses, representert ved hjelp av use cases, 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: rasjon. 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 pekepinne 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 forberdres. 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

9 gjort feil og måtte forbedres. Etter gjennomgang med stud.ass så gjorde vi det på nytt. Use case 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

10 1.6 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 usansynelige problemer burde også inkluderes i en risikoplan. Planlegging Planlegging av prosjekter er svært vikig. 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 uke og mnd er det viktig å ha en oversikt over mulige problemer som kan oppstå og løsninger for disse. Gruppa burde være forbredt 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.

11 1.7 Risiko og tiltak Risiko Sannsynlighet Konsekvens Tiltak Sykdom hos en eller flere gruppemedlemmer. Høy Akseptabel. Arbeid må utsettes eller gjøres av andre på gruppa. Det blir mer arbeid på resten av gruppa og det kan oppstå tidspress. Syke gruppemedlemmer må være flinke til å ha kontakt med gruppen for å sikre at arbeidet blir gjort av noen andre PC-krasj. Middels Alvorlig. PC problemer fører til tap av data og/eller utsettelse av arbeid. Ta backup, jobbe på google docs for å unngå tap av dokumenter. Gruppa klarer ikke å samarbeide Leveringsproble mer grunnet pc/ internett problemer. Lav Akseptabel. Hvis gruppa ikke klarer å samarbeide vil arbeidsmiljøet bli dårlig. Middels Alvorlig. For sen levering resulterer i dårligere karakter / stryk. Gruppa vår har fungert fint tidligere, det burde ikke bli problem nå. Fortsette å ha god kommunikasjon innad i gruppen for å forhindre eventuelle problemer. Levere i god tid, på den måten kan man levere fra en annen pc eller et annet sted hvis noe går galt.

12 Noen slutter i gruppa. Lav Alvorlig. Mye større arbeidsmengde Arbeidsoppgavene til personen som slutter må fordeles på en rettferdig måte innad i gruppa. Konflikter Middels Akseptabel. Vanskelige arbeidsforhold Hvis det skulle oppstå konflikt innad i gruppa må andre medlemmer megle mellom partene som er uenige.

13 1.8 Rapportoversikt Kap 1: En introduksjon til prosjektet, med våre antagelser, suksesskriteria o.l. Kap 2: Inneholder beskrivelse av prosjektets omfang og en kort beskrivelse av hver leveranses innhold. Kap 3: Beskriver hvordan arbeidet har blitt organisert, oppgavefordeling, hvilke hjelpemiddler som har vært i bruk o.l. Kap 4: Prosjektets kostnadsdetaljer. Kap 5: Administrativ dokumentasjon som møte referater og timeregistrering. Kap 6: Referanser til kilder som har blitt tatt i bruk i løpet av prosjektarbeidet.

14 2 Beskrivelse av omfang Leveranse 1: Prosjektplan v0.2 Inneholder informasjon om prosjektets struktur, våre arbeidsmetoder, hjelpemidler, en detaljert risikoplan og ansvarsfordeling. Leveranse 2: Prosjektplan v1.0 Prosjektrapport v0.3 Inneholder komplett og oppdatert prosjektplan. Prosjekt rapport kap 1(introduksjon) som beskriver prosjektets mål, antagelser, suksesskriteria og omfang. Kap 2 (tilpasning av utviklingsmodell) beskriver utviklingsmodell og tilpasninger. Og påbegynt kravspesifisering og use case modellering. Leveranse 3: Oppdatert prosjektplan Prosjektrapport v0.6 Inneholder kap 1 og 2 av prosjektrapport som beskrevet tidligere (oppdatert etter behov). Kapittel 3 (analyse) inneholder diagrammer og analyse og Kapittel 4 som inneholder sekvensdiagram, klassediagram, logisk arkitektur og foreslått brukergrensesnitt. Leveranse 4: Prosjektrapport v1.0 Komplett prosjektrapport hvor alle systemet er ferdig planlagt og alle kapitler i rapporten er oppdaterte.

15 3 Prosjektorganisasjon og plan 3.1 Prosjektorganisasjon Google docs vil bli brukt og disponibel av alle i gruppen. Slides vil bli brukt som hjelpemidel av alle i gruppen til forskjellige punkter. Forelesningene vil være en individuel ressurs som hver i gruppen vil bruke til individuelt arbeid. Microsoft programvare vil bli brukt av alle i gruppen. Gruppen vil utdype mer på dette punktet i versjon 1.0

16 3.2 Roller og ansvar Rolle Ansvar Navn Kompetanse Tidsperiode Leder Organisering Abdi Baisa Ingen Untill he dies or we find someone better Sekretær Revisjon Bjørn Bergan Allmennutdanning Prosjektets lengde Faktasjekker / webansvarlig Sjekke påstander og kildehenvisn inger, drifte hjemmesida Magnus Dahl Hegge Internettsøk - guru Prosjektets lengde Djevelens advokat Kritisere og skape idemyldring Mads Larsen Nordlending / kritiker Prosjektets lengde 3.3 Milepæler og aktiviteter <Milepæl 1>: o Aktiviteter: Versjon 0.2 av prosjektplanen er ferdig. Hjemmesiden er opprettet. o Leveranse(r): Versjon 0.2 av rapporten med link til hjemmeside.

17 <Milepæl 2>: o Aktiviteter: Prosjektrapport versjon 0.6 er ferdig. o Leveranse(r): Prosjektrapport versjon 0.3 og Prosjektplan versjon 1.0. <Milepæl 3>: o Aktiviteter: Prosjektrapport versjon 0.6 er ferdig. o Leveranse(r): Prosjektrapport versjon 0.6 og Prosjektplan versjon 1.0 (hvis oppdatert siden leveranse 2). <Milepæl 4>: o Aktiviteter: Prosjektrapport versjon 1.0 er ferdig. o Leveranse(r): Prosjektrapport versjon 1.0 og Prosjektplan versjon 1.0 (hvis oppdatert siden leveranse 2).

18 3.4 Oversikt prosjekt plan ål Beskriv prosjektaktivitetene med et Gant-kart (ved hjelp av Microsoft Project eller lignende). 3.5 Arbeidsmåte ( way of working ) Del 1-3 av prosjektrapporten vil bli utført i lag og med oppdeling av punkter og planlegge arbeidet framover. Vil vil jobbe sammen hver dag på skolen på grupperom eller via Online google docs. Det vil generelt være lite individuelt arbeid. Del 4 vil vi jobbe sammen i grupperom og dele opp arbeid, men fortsatt jobbe sammen i gruppe og generelt lite individuelt arbeid. 3.6 Prosjekthjelpemidler Spesifiser hvilken verktøy og lignende som vil bli benyttes (for eksempel Rational Rose eller annet for modellering). Vi vil bruke Microsoft Project eller excel til å lage en framdriftsplanm, eller et Gant diagram. Vi vil bruke Google Docs for å arbeide med alt skriftlig. Vi vil bruke Microsoft Visio 2007 for modellering i prosjektet. Vi vil bruke Internett, pensumbøker og forelesningsnotater for og finne stoff.

19 4 Kostnader Det vil være 4 utviklere. Prosjektets varighet vil være 3 måneder. Arbeidstiden per dag vil være 8 timer. Timesbetalt per utvikler vil være 300 kr timen. Leie av lokaler: Andre kostnader kan forekomme i løpet av prosjektet som fks. programvare og teknisk utstyr: kr. Beregnet total kostnad kr

20 5 Admin 5.1 Rapportering og møter Vi vil ha generel diskusjon hver dag ved starten av dagen om statusen på prosjektet. Vi vil etter behov hvis det trengs ved f.eks tidsmangel, sykdom eller fravær holde møte for å få skuta på rett kjør. 5.2 Dokumenthåndtering Vi vil bruke Google docs online for dokument håndtering og felles arbeid. Google docs gjør det mulig for alle sammen og jobbe med samme dokument i sanntid. Vi vil laste ned prosjektrapporten lokalt i jevne mellomrom for og sikre oss backup av dokumenter. 5.3 Timeregistrering Vi vil bruke en tabell som viser hvor mange timer vi har brukt på hver fase av prosjektet og antall timer hver og sammen vi har arbeidet. Leveranse 1 timetabell. Navn Timer Totalt Individuelt Sammen Mads Larsen ca 85 ca 15 ca 70 Bjørn Bergan ca 85 ca 15 ca 70 Abdi Baisa ca 85 ca 15 ca 70 Magnus Hegge ca 85 ca 15 ca 70

21 5.4 Informasjon Løsninger som allerede brukes vil vi studere og hente ut informasjon om som hjelp til utvikling av våre egne løsninger. Dette kan være f.eks gant diagram, tabeller og modeller. 6 Referanser Slides fra forelesning Forelesning Systemutvikling Applikasjoner og databaser av Thor E. Hasl. Cappelen akademisk forlag. ISBN

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

Avdeling for ingeniørutdanning Høgskolen i Oslo. Prosjektrapport Systemutvikling (lo138a) Høst 2010. Taxisentral Avdeling for ingeniørutdanning Høgskolen i Oslo Prosjektrapport Systemutvikling (lo138a) Høst 2010 Taxisentral Gruppe 19 Prosjekthjemmeside: http://gruppe19.lmdahl.no/ Forfattere: Larsen, Mads s156151

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

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

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

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

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

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

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

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

Kap 11 Planlegging og dokumentasjon s 310

Kap 11 Planlegging og dokumentasjon s 310 Kap 11 Planlegging og dokumentasjon s 310 11.1 Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid:

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

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

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

Hensikten med denne delen av kurset. Objektorientering hva er det? Objektets egenskaper. Best practises ved programvareutvikling Objektorientert systemutvikling, litt UML og Rational Unified Process (RUP) UML Distilled kap. 2 Hensikten med denne delen av kurset Å lære og øve på modelleringsteknikker Å lære om gode designprinsipper

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

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

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

Prosjektoppgave INF3290 høsten 2017

Prosjektoppgave INF3290 høsten 2017 Prosjektoppgave INF3290 høsten 2017 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

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

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

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG UKESOPPGAVER 7 REPETISJON GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon

Detaljer

Forprosjektrapport. Gruppe 31

Forprosjektrapport. Gruppe 31 Forprosjektrapport Gruppe 31 1 Presentasjon Oppgave: Finne et kodespråk som kan være med på å forbedre kundetilfredsheten og brukervennligheten ved bruk av Telenor sine websider. Periode: 14. januar til

Detaljer

Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.

Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt. Forside Eksamen i IN1030 for Våren 2018. Ingen hjelpemidler tillatt. I dette oppgavesettet har du mulighet til å svare med digital håndtegning (oppgave 1, 4 og 5). Du bruker skisseark du får utdelt. Det

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

Oppgave 1: Multiple choice (20 %)

Oppgave 1: Multiple choice (20 %) Oppgave 1: Multiple choice (20 %) For alle oppgavene gjelder at det bare er ett riktig svar. No Spørsmål Svar A Svar B Svar C Svar D 1 Kanban er et eksempel på: Prosess Software prosess Prosess modell

Detaljer

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2 Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av

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

Prosjektoppgave INF3290 høsten 2017

Prosjektoppgave INF3290 høsten 2017 Prosjektoppgave INF3290 høsten 2017 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

Detaljer

SPPR Software Project Progress Report Uke 38-39

SPPR Software Project Progress Report Uke 38-39 SPPR Software Project Progress Report Uke 38-39 Heiskontrollsystem Gruppe 7 Gunhild Kristiansen, Arne Enger Hansen, Cecilie Vådahl, Kristian Vågen, Magnus Asbjørnsen, Martin Stenmark Høgskolen i Østfold

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

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002 SLUTTRAPPORT gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen 25. november 2002 1 Innhold 1 Sammenligning ressursforbruk 3 2 Erfaringer fra prosjektgjennomføring

Detaljer

Prosjektoppgave INF3290 høsten 2018

Prosjektoppgave INF3290 høsten 2018 Prosjektoppgave INF3290 høsten 2018 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

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

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

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

Detaljer

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

Software Development Plan (1. utkast)

Software Development Plan (1. utkast) Software Development Plan (1. utkast) Høgskolen i Sørøst-Norge Fakultet for teknologiske fag Institutt for elektro, IT og kybernetikk SDP 12/01/2018 Systemutvikling og dokumentasjon/ia4412 Innholdsfortegnelse

Detaljer

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller

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

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

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

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

Use Case-modellering. INF1050: Gjennomgang, uke 04

Use Case-modellering. INF1050: Gjennomgang, uke 04 Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram

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

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Greta Hjertø og Tore Berg Hansen 30.08.2005 Revidert av Kjell Toft Hansen

Detaljer

Prosjektkategori: Forprosjektrapport Fritt tilgjengelig X Omfang i studiepoeng: 20 Fritt tilgjengelig etter:

Prosjektkategori: Forprosjektrapport Fritt tilgjengelig X Omfang i studiepoeng: 20 Fritt tilgjengelig etter: Avdeling for ingeniørfag PROSJEKTRAPPORT Prosjektkategori: Forprosjektrapport Fritt tilgjengelig X Omfang i studiepoeng: 20 Fritt tilgjengelig etter: Fagområde: Konstruksjonsteknikk Rapporttittel: Kvalitetssikring

Detaljer

Prosjektplan v1.7 (Revidert utgave 2)

Prosjektplan v1.7 (Revidert utgave 2) Prosjektplan v1.7 (Revidert utgave 2) gruppe 42: Nils-Kristian Liborg (kap.5), Bente Brevig (kap.5), Tom Olav Bruaas (kap: 3.4, 4.1), Eirik Lied (kap: 3.4, 4.1) Hege Lid Pedersen (dokumentasjon, kap: 1,

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

1. PRINT & MFP LØSNINGER 2. DOKUMENTHÅNDTERING 3. IT-SERVICES 4. DIGITAL SIGNAGE & AV

1. PRINT & MFP LØSNINGER 2. DOKUMENTHÅNDTERING 3. IT-SERVICES 4. DIGITAL SIGNAGE & AV 1. PRINT & MFP LØSNINGER 2. DOKUMENTHÅNDTERING 3. IT-SERVICES 4. DIGITAL SIGNAGE & AV 1. JOBBER MED DE STØRSTE GLOBALE LØSNINGENE ELLER ET LITE KONTORMILJØ SÅ ER HVERT PROSJEKT NØYE GJENNOMFØRT MED KUNDENS

Detaljer

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

Detaljer

Forprosjektrapport. Hovedprosjekt våren 2009. Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen

Forprosjektrapport. Hovedprosjekt våren 2009. Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen Forprosjektrapport Hovedprosjekt våren 2009 Gruppenr. H09E03 Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen Styre- og loggsystem for en testjigg HØGSKOLEN I ØSTFOLD Avdeling for ingeniørfag Postadresse:

Detaljer

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12 Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering

Detaljer

11 Planlegging og dokumentasjon

11 Planlegging og dokumentasjon 11 Planlegging og dokumentasjon Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid: Programmerer

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer

Detaljer

Software Development Plan

Software Development Plan Software Development Plan Værsystem Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SDP 03/04/2018 Systemutvikling og dokumentasjon/ia4412

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

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig

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

Undervisningsopplegg i matematikk. Med fokus på bruk av IKT

Undervisningsopplegg i matematikk. Med fokus på bruk av IKT Undervisningsopplegg i matematikk Med fokus på bruk av IKT Innholdsfortegnelse Innledning... 3 Målsetning... 3 Valg av programvare... 3 Evaluering... 4 Undervisningsopplegget... 5 Arbeidsmetoder... 5 Temaliste...

Detaljer

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle Del - leveranse Del 2 Inf 2120 fredag 29.4 Gruppe 1 Knut Johannes Dahle AV Catrine Myhre (catrinem@ifi.uio.no) Mehdi Zare (mehdiz@ifi.uio.no) Odd Christer Brovig (oddcb@ifi.uio.no) Christer Aas (chrisva@ifi.uio.no)

Detaljer

Prosjektrapport Gruppenr FigureGame 3.0

Prosjektrapport Gruppenr FigureGame 3.0 Vedlegg 1. Prosjektavtale Avtale mellom: Reidar Kvadsheim, oppdragsgiver og Robin Juliussen, Olaf Nikolai Hansen og Inger Lill Nystad Prosjektets navn: Figure Game 3.0 Wrath of the Configuration 1. Prosjektets

Detaljer

Prosjektrettet systemarbeid

Prosjektrettet systemarbeid Prosjektrettet systemarbeid Funksjonsmodellering Faglærer: Kjell Toft Hansen Funksjonsmodellering Fra prosjektets brukerkravdokument: Kap. 3.1 Krav til funksjoner Kravene til funksjoner beskriver hva bruker

Detaljer

Kravhåndtering. INF1050: Gjennomgang, uke 03

Kravhåndtering. INF1050: Gjennomgang, uke 03 Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle

Detaljer

Prosjektoppgave INF3290 høsten 2016

Prosjektoppgave INF3290 høsten 2016 Prosjektoppgave INF3290 høsten 2016 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

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

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

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

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

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren

Detaljer

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson PROSJEKTGRUPPE 1 MGT SOFTWARE PROSJEKTPLAN LEVERANSE 1 (REVIDERT 1) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Store Prosjektledelse: Store Kvalitetssikring: Tommy Jansson Dato: 03. oktober 2005

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

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006 Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................

Detaljer

Idèfase. Skisse. Resultat

Idèfase. Skisse. Resultat ? Idèfase Skisse Planlegging Gjennomføring Resultat Bakgrunn: Utviklingssenter for sykehjem og hjemmetjenester (USHT) Troms har stor tro på prosjektorientert arbeid. Derfor legges det til rette for utviklingsarbeid

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

PROSJEKTBESKRIVELSE. Morten Ohren STUDENTNUMMER

PROSJEKTBESKRIVELSE. Morten Ohren STUDENTNUMMER PROSJEKTBESKRIVELSE Morten Ohren STUDENTNUMMER Innhold Bakgrunn... 2 Behov... 2 Om Eiendomsdrift SA... 2 Idèvurdering... 2 Personlig input... 2 Forutsetninger og rammeverk... 2 Tid... 2 Ressurser og materiell...

Detaljer

Requirements & Design Document

Requirements & Design Document Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 03/04/2018 Systemutvikling og dokumentasjon/ia4412

Detaljer

Thursday, August 19, 2010. Web-prosjekt

Thursday, August 19, 2010. Web-prosjekt Web-prosjekt Om kurset Organisering av kurset Består av to hoveddeler: Webpublisering Prosjektarbeid Motivasjon Web Lære å utvikle websider Lære prinsipper for brukervennlighet og tilgjengelighet Skrive

Detaljer

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

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

Detaljer

FORPROSJEKTRAPPORT FOR BACHELOROPPGAVE

FORPROSJEKTRAPPORT FOR BACHELOROPPGAVE FORPROSJEKTRAPPORT FOR BACHELOROPPGAVE Automatisert styring av feilsituasjoner (I NELFO`s prøvestasjon for elektrofagarbeidere) Gruppe B18E01 Magnus H Borgen Magne Johansen Sander Berg 23.Mars 2018 Høgskolen

Detaljer

INF1510: Obligatorisk oppgave 2: prosjektforslag

INF1510: Obligatorisk oppgave 2: prosjektforslag INF1510: Obligatorisk oppgave 2: prosjektforslag Prosjektgruppe: G0Gr33n! Vi er fire jenter og to gutter som har forskjellig bakgrunn i forhold til erfaring og kunnskap. Vi forventer å lære mer om brukerorientert

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

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017 Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering

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

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

Prosjektoppgave INF3290 høsten 2015

Prosjektoppgave INF3290 høsten 2015 Prosjektoppgave INF3290 høsten 2015 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere som studenter. Samtidig vet vi at aktiv deltakelse i prosjektarbeidet

Detaljer

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

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

Detaljer

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

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

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

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

Forprosjekt. Gruppe: H09B03. HIØ, Sarpsborg

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

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

Detaljer

Repository Self Service. Hovedoppgave våren 2010

Repository Self Service. Hovedoppgave våren 2010 Forprosjektrapport for Repository Self Service Hovedoppgave våren 2010 Christer Berg (070604 07HBDRA) Ron Stangvik (070427 07HBDRA) 1 Innholdsfortegnelse 1. MÅL OG RAMMER...3 1.1. Bakgrunn...3 1.2. Prosjektmål...3

Detaljer

Kjennetegn. Enhetlig skriveradministrasjon Utskriftspolicy Produktbasert jobbehandling Administrasjon av utskriftskø APPLIKASJONER.

Kjennetegn. Enhetlig skriveradministrasjon Utskriftspolicy Produktbasert jobbehandling Administrasjon av utskriftskø APPLIKASJONER. Utskriftsstyring Kjennetegn Enhetlig skriveradministrasjon Utskriftspolicy Produktbasert jobbehandling Administrasjon av utskriftskø APPLIKASJONER Utskriftsstyring Fargestyring Web til utskrift Variabel

Detaljer

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning

Detaljer

I. Innholdsfortegnelse

I. Innholdsfortegnelse 2008 FORPROSJEKT -KONSEKVENSER AV NS-EN 1992-1-1 H08B03 Sarpsborg 13. mars 2008 FORPROSJEKT RAPPORT Side 2 I. Innholdsfortegnelse Tittelside...1 I. Innholdsfortegnelse... 2 II. Prosjektdirektiv... 3 A.

Detaljer

Prosjektmandat Prosjektmandatet forteller om:

Prosjektmandat Prosjektmandatet forteller om: Tiende gang. Et utvalg fra fagets hjemmesider NB! Case osv. er ikke tatt med Hvilke metoder og tilnærmingsmåter passer for krevende prosjekter og endringsoppgaver? Prosjekt og prosjektarbeid Et prosjekt

Detaljer

Syste m documentation

Syste m documentation Syste m documentation Innholdsfortegnelse 1 Oversikt... 2 1.1 Beskrivelse av det grafiske bilde av applikasjonen:... 3 2 Tekniske krav... 4 2.1 Krav for applikasjonen:... 4 2.2 Krav som ikke MÅ være med

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

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

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