Vakt og lønnssystem - Rema 1000

Størrelse: px
Begynne med side:

Download "Vakt og lønnssystem - Rema 1000"

Transkript

1 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, s Ravi Agnihotri, s Torbjørn Martinsen, s Jonathan Sætre, s Herish Hashemi s Dato: Side 1 av 20

2 Sammendrag Denne rapporten drøfter en mulig løsning som går ut på å implementere et nytt elektronisk og nettbasert system for å lette administrasjonen for deltidsansatte ved Rema Rapportens omfang strekker seg fra utarbeiding av kravspesifikasjon til tekniske modeller og en lavfidelitetsprototype. Gruppen benyttet seg av en tilpasset utgave av Unified Prosess for å nå målene den hadde satt seg, og gjennomførte til sammen syv iterasjoner i løpet av prosjektets levetid. Prototypen ble designet, og gjennom iterasjonene ble domenemodell, klasse- og sekvensdiagram utarbeidet. Til sist har gruppen gjort en vurdering av prosjektet hvor samarbeidet, utfordringer og annen kritikk nevnes. Side 2 av 20

3 Innholdsfortegnelse Sammendrag... 2 Versjonslogg Introduksjon Bakgrunn Mål for prosjektet Omfang av løsning Suksesskriterier Planlegging Kommunikasjon Samarbeid Risikoplan Involvere bruker Antagelser Tilpasning av utviklingsmodell Beskrivelse av utviklingsmodell Begrunnelse for tilpasninger Analyse Kravspesifikasjon Funksjonelle krav Ikke-funksjonelle krav Use Case Modell Use case diagram Detaljerte Use case beskrivelser Domenemodell Aktivitetsdiagram Design Klassediagram Sekvensdiagram Logisk arkitektur Brukergrensesnitt Vurdering Vurdering av foreslått løsning Vurdering av valgt utviklingsmodell Vurdering av eget prosjektarbeid Konklusjon Litteraturliste Side 3 av 20

4 Versjonslogg Versjon Dato Forfatter(e) Beskrivelse av versjon v Ravi, Andreas, Herish, Torbjørn, Jonathan v Ravi, Andreas, Herish, Torbjørn, Jonathan v Ravi, Andreas, Herish, Torbjørn, Jonathan v Ravi, Andreas, Herish, Torbjørn, Jonathan v Ravi, Andreas, Herish, Torbjørn, Jonathan v Ravi, Andreas, Herish, Torbjørn, Jonathan Komplett rapport. Kvalitetssikring av hele dokumentet Sammendrag Kapittel 5 Rettet på kapittel 2.1, 2.2, 3 og 4 Kapittel 4 + små og store rettinger i hvert kapittel. Kapittel Introduksjon 1.1 Bakgrunn Rema 1000 er Norges største dagligvarekjede bestående av enkeltbutikker drevet som selvstendige selskap. Disse enkeltbutikkene eies og drives av en butikksjef, som har et titalls ansatte under seg. Selskapet har ekspandert kraftig siden den første butikken ble opprettet i Trondheim på 70-tallet, og man kan i dag finne butikker over hele Skandinavia. Tilsammen administrerer kjeden godt over 6000 ansatte, hvor en stor andel av disse er deltidsansatte. I og med at deltidsansatte jobber mindre, og er på jobben sjeldnere, blir de også sjeldnere oppdatert på endringer og informasjon. Vi ønsker å utarbeide en løsning for å gjøre administrasjon og bruk lettere og mer effektivt. Vi ser for oss at Rema 1000 kan ha interesse av et elektronisk og nettbasert system slik at butikksjefene og deres ansatte får en bedre oversikt over vakter og arbeidstimer. Side 4 av 20

5 1.2 Mål for prosjektet 1. Lage et forslag til løsning for et nettbasert system som håndterer detaljert journalføring av skiftliste og lønnsoversikt. Dette skal effektivisere personlig administrasjon både i og utenfor arbeidstid. a. Ansatte skal ha oversikt over egen lønn og arbeidstid. b. Butikksjef skal ha en oversikt over ansattes lønn og arbeidstid. c. Skal gjøre det enklere for ansatte å bytte vakter. 2. Foreslått løsning skal være ferdig til 25. november Omfang av løsning Butikksjefene og de ansatte opplever frustrasjon i forbindelse med vaktplaner, lønnsberegning og kommunisering med den løsningen de har i dag, og som vi skal forbedre i vårt system. Om en person ikke har mulighet til å møte opp, må butikksjefen ofte ringe vilkårlig rundt og finne en erstatter. Det samme gjelder hvis en ansatt vil bytte bort vakten sin, eller evt ønsker flere vakter. Vaktplanen og generell informasjon publiseres på papirform på en oppslagstavle som betyr at de ansatte må enten dra til jobben eller ringe for å få vite arbeidstider og få informasjon. Dette gjør at det blir vanskelig å gjøre endringer på kort varsel samtidig som det er svært tungvint for de ansatte. Vaktplanen er på tabellform og preges av mye kluss og rot etterhvert som tidrommet til vakter forandres og ansatte bytter vakter mellom seg. Lønnen utarbeides utifra de papirbaserte vaktplanene og hvordan regnskapsfører tolker forskjellige håndskrifter og kluss. Dette medfører ofte at ansatte får feil lønn. Kluss og rot i vaktplanen øker også sannsynligheten for missforståelser om hvem som skal på jobb når. Løsningens omfang begrenser seg til å løse problemene over. 1.4 Suksesskriterier Planlegging God planlegging er helt nødvendig for å lykkes i et prosjekt. Uten planlegging får man ikke en god oversikt over hva som skal gjøres til enhver tid og hvilke ressurser man trenger. Side 5 av 20

6 1.4.2 Kommunikasjon I et prosjekt er det svært viktig å ha god kommunikasjon innad i prosjektgruppen. Dette for at vi til enhver tid skal kunne holde oss oppdatert over hva andre gjør og har gjort, for så å få frem hvor langt vi har kommet mot et endelig resultat Samarbeid Det er viktig å ha et godt miljø innad i gruppen, da dette fører til bedre effektivitet og økt framdrift av prosjektet. Bruk av e-post, telefon, Skype, Facebook og Google Docs er hjelpemidler vi skal bruke til å oppnå nettopp en strømlinjeformet utvikling Risikoplan Å ha en oversiktlig risikoplan kan være veldig nyttig om ting går galt. En god risikoplan gir en oversikt over hvordan situasjoner enkelt kan håndteres før man mister kontroll over prosjektets utvikling. Det er også nyttig å være bevisst på risikoene i prosjektet Involvere bruker Det å involvere bruker i både planleggings- og utviklingsfasen er et av de viktigste verktøyene for å lage et program som kommer til å bli likt av brukerne. En bruker kan bety flere ting, og de brukerne vi ønsker å ha hyppig kontakt med er daglig leder og deltidsansatte (med andre ord de som kommer til å bruke programmet). 1.5 Antagelser Rema 1000 bruker per i dag et system for administrering av lønn som driftes fra sentralt hold og dekker alle butikker. Vi har ikke som mål at vårt system skal integreres i dette systemet, selv om det ville vært det optimale. Vi antar at Rema 1000 ønsker i første omgang å implementere systemet i én butikk. Basert på erfaringene herfra skal det være enkelt å utvide systemet slik at data fra flere butikker kan inngå i samme system. 2.0 Tilpasning av utviklingsmodell 2.1 Beskrivelse av utviklingsmodell I prosjektet skal vi benytte Rational Unified Process, tilpasset til vårt prosjekt, som utviklingsmodell. Rational Unified Process, herved kalt RUP, er en produktutviklingsfilosofi som er svært utbredt, bl.a. i IBM og Microsoft. Det er et rammeverk som er ment for å skreddersys til hver prosjektgruppe ved at de velger ut elementene fra RUP som er relevante for deres behov. Et viktig prinsipp i RUP er at prosessen er inkrementell, det vil si at ting skjer litt og litt. Side 6 av 20

7 Det er ikke et mål i seg selv at alt skal gjøres ferdig med en gang, derfor gjør man litt og litt ettersom man har nok informasjon. Da blir det ikke like stor jobb å oppdatere, til forskjell fra i for eksempel fossefallmodellen, der alt gjøres ferdig med en gang. Når man gjør ting om igjen, kalles det iterasjoner. RUP deles inn i fire faser. Hver av disse fire fasene består av en eller flere (gjerne mange) iterasjoner. Fasene er: Idéfase, utdypningsfase, konstruksjon og overgang. Vi skal gjøre tre av fasene: Idéfase, utdypningsfase og en (forkortet) konstruksjon. Disipliner i RUP er oppgaver eller prosesser. Under følger en forklaring av hver av de 9 disiplinene i RUP og vår tilpasning av dem: Disiplin [4] Business modelling (Forretningsmodellering) Requirements (Kravspesifisering) Analysis and Design (Analyse og design) Implementation (Gjennomføring) Test (Testing) Beskrivelse beskrivelsene er sitert fra kilde [4] - Opprette en bedre forståelse og kommunikasjon mellom forretnings utviklere og software utviklere. - Forstå strukturen og dynamikken til forretningen/organisasjonen/interessenten som skal bruke systemet. - Finne nåværende problemstillinger og mulige forbedringer. - Beskrive hva systemet skal gjøre. - Lage et Bruksmønster Diagram. - Skal vise hvordan systemet vil bli realisert i gjennomføringsfasen. - Resultere i en design- og analysemodell. - Implementere klasser og objekter i systemet. - Teste og utvikle komponenter til systemet. - Sette sammen de ulike delene til et system. - Bekrefte interaksjonen mellom objekter. - Bekrefte riktig integrasjon av alle komponenter i systemet. - Bekrefte at alle behovene i systemet er implementert riktig. - Finne og identifisere feil i systemet og korrigere disse før utviklingsfasen. Vår tilpasning Punkt en droppes. Disiplinen begrenses til det som har med lønn eller vaktplaner å gjøre. Som normalt. Kun use-case, domenemodell, klassediagram, sekvensdiagram, aktivitetsdiagram, logisk arkitektur og lavfidelitetsprototype. Droppes helt. Droppes helt. Side 7 av 20

8 Deployment (Utplassering) Configuration and Change Management (Konfigurering og endringsledelse) Project Management (Prosjektledelse) Environment (Omgivelser) - Produsere en produktutgivelse. - Distribuere produktet til interessenter. - Drive support for produktet. - Konfigurasjonsledelse. - Forandringsforespørsel ledelse. - Status og mål ledelse. - Risiko behandling. - Planlegging av prosjektet. - Overvåking av prosessens utvikling. - Beskrive aktivitetene som er nødvendig for utviklingsprosessen. - Forberede prosjekt-spesifikke midler. - Lage en utstyrsliste over nødvendig utstyr for prosjektet. Droppes helt. Som normalt. Som normalt (men på liten skala). Som normalt (men på liten skala). Våre faser, disipliner og iterasjoner Iterasjoner Idéfasen: Iterasjon 1 Kort planleggingsfase på 1 uke. Forretningsmodellering og kravspesifikasjon påbegynnes. Vi finner en løsning for omgivelser. Bestemmer oss for ledelsesform og -struktur. Vi påbegynner som analyse fra disiplinen analyse og design. Side 8 av 20

9 Utdypningsfase: Iterasjon 1 Jobber videre med forretningsmodellering og kravspesifisering. Fortsetter analyse og begynner med Use-case diagram. Konfigurering og endringsledelse begynner her og fortsetter til levering. Utdypningsfase: Iterasjon 2 Lager første utkast til kravspesifikasjon. Begynner på domenemodell, klassediagram og lavfidelitetsprototype. Kan hende man finner ut at det trengs å lære mer om bedriften. Begynner på prosjektrapport. Utdypningsfase: Iterasjon 3 Kravspesifisering oppdateres ettersom man får mer informasjon. Jobber videre med analyse og design ved å begynne på sekvensdiagram, aktivitetsdiagram. Fortsetter på domenemodell, klassediagram og lavfidelitetsprototype. Lærer oss mer om bedriften dersom det trengs. Fortsetter med prosjektrapport Konstruksjonsfase: Iterasjon 1 Analyse og design fortsetter ved at vi begynner på logisk arkitektur og jobber videre med de andre. Oppdaterer diagrammene som ikke er bra nok. Fortsetter med prosjektrapport. Kravspesifikasjon oppdateres dersom det trengs. Konstruksjonsfase: Iterasjon 2 Jobber mot utkast på UML diagrammer, samt lavfidelitetsprototype. Vi skriver ferdig utkast til kapitlene evaluering, introduksjon og oppsummering i prosjektrapporten, som gjøres nesten ferdig. Konstruksjonsfase: Iterasjon 3 Vi skriver evaluering, introduksjon og oppsummering ferdig. Vi kvalitetssikrer hele prosjektrapporten. Sjekker spesielt språk, utforming og konsistens mellom modeller. Rapporten leveres. 2.2 Begrunnelse for tilpasninger Idéfase En ganske kort idéfase med kun én iterasjon, fordi det er et ganske lite prosjekt. Utdypningsfase Utdypningsfasen utføres nesten som vanlig, minus brukertesting og utvikling. Konstruksjon Grunnen til at vi har færre iterasjoner enn normalt i denne fasen er at prosjektet er begrenset og vi skal ikke utvikle selve systemet. Vi utfører med andre ord mindre i denne fasen enn hvis vi skulle ha utviklet produktet. Overgang Vi dropper alt i fasen overgang, da dette faller utenfor prosjektets omfang. Disipliner Business modelling (Forretningsmodellering): Vi gjør kun en svært begrenset forretningmodellering, da produktet kun omfatter en liten del av bedriftens virksomhet, og ikke avhenger av så mange andre ting. Side 9 av 20

10 Analysis and Design (Analyse og design): Vi lager kun modellene: use-case, domenemodell, klassediagram, sekvensdiagram, aktivitetsdiagram, logisk arkitektur og lavfidelitetsprototype. Dette fordi det er et lite prosjekt. Implementation (Gjennomføring), Test (Testing) og Deployment (Utplassering) Droppes fordi vi ikke skal utvikle systemet. 3.0 Analyse 3.1 Kravspesifikasjon Funksjonelle krav Programmet skal tilby følgende funksjoner: Arbeidsgiver: Skal kunne: sette opp vaktplan godkjenne eller avslå ferieforespørsler se oversikt over hver av sine ansattes: feriegrunnlag vakter antall timer jobbet opptjent lønn betalt skatt kontaktinfo Arbeidstaker: Skal kunne: se vaktplan markere egen vakt ønskes byttet bytte til seg vakter som andre ønsker byttet spørre om ferie se på egne lønn og timeoversikt, det vil si: Antall timer jobbet Opptjent lønn Betalt skatt Bør kunne se de andre ansattes kontaktinfo Side 10 av 20

11 3.1.2 Ikke-funksjonelle krav Ikke-funksjonelle krav kan også kalles kvalitetsønsker. Løsningen: Skal ha en oppetid på 98% rask svartid på sek kostnadsramme på kr ,-, dette skal dekke utgifter i form av kost, utstyr, transport, serverleie og lønn god brukervennlighet, også for ansatte som bruker teknologi lite Skal være intuitiv å bruke Bør ha kildekode som er ryddig enkelt kan videreutvikles takler endringer Side 11 av 20

12 3.2 Use Case Modell Use case diagram I infotavla legger arbeidsgiver ut nyttig info for arbeidstakere, som f.eks: informasjon om møter, julebord, holdninger/verdier angående kundeservice og informasjon om nye rutiner. Blå streker gjelder for arbeidsgiver. Røde streker gjelder for arbeidstaker. Use case: Endre Ansatt Info kan kun arbeidstaker endre sin personlige informasjon; telefonnr, adresse, epostadresse. Arbeidsgiver har rettigheter til å endre all informasjon. Side 12 av 20

13 3.2.2 Detaljerte Use case beskrivelser Use case Aktor Trigger Pre-betingelser Post-betingelse Opprette vaktplan Arbeidsgiver Arbeidsgiveren vil opprette vaktplan. Arbeidsgiver velger å opprette vaktplaner. Arbeidsgiver har fått tillatelse, eller feilmelding oppstår. Normal hendelsesflyt 1. Arbeidsgiveren kan: a. Går inn på funksjonen: dupliker nyeste vaktplan x ganger fremover b. Skriv inn antall (x) ganger fremover. Systemet: c. Systemet sjekker om vaktene er utfylt etter kravene. Hver vakt skal ha en grense på 12 timer pr.vakt, ved mer enn det, får man en advarsel. d. Systemet viser antall timer for en uke for hver enkelt ansatt. Variasjon a1. Det finnes ikke en forrige vaktplan. c1. Dersom en vakt ikke blir fylt inn pga. godkjent ferieforespørsel, får arbeidstaker melding om dette, og han kan sette opp en annen ansatt. Use case Aktor Trigger Pre-betingelse Post-betingelse Bytte vakter Arbeidstaker Arbeidstaker vil bytte vakter Arbeidstakeren velger å bytte en vakt Arbeidstakeren har fått tillatelse eller feilmelding oppstår. forts. neste side Side 13 av 20

14 Normal hendelsesflyt 1. Arbeidstakeren (kan): a. Går inn i vaktplanregisteret. b. Skal føre inn år og ukenr. c. Går inn på vaktplan for angitt ukenr. d. Skal føre inn dato. e. Går inn på vakt for angitt dato. f. Skal høyreklikke på ønsket vakt for endring. g. Brukere skal velge ønsket valg i nytt vindu. i. Brukere kan velge: 1. Bytte vakten sin med en annen ansatt, skal skrive ansatt nummeret til han/hun som skal ta vakten. 2. Å markere vakt for å gjøre tilgjengelig for andre kollegaer. 2. Variasjon Systemet g.i.1 Finner ikke ansatt nummer. g.i.1.2 Får ikke fylt inn ansatt nummer. g.i.2 Får ikke markert vakt som tilgjengelig. g.1 Endring av vaktplanen går ikke igjennom. Vi anser dette som de to viktigste use-case beskrivelsene, grunnet dette er to viktige deler av hovedomfanget for systemet. 3.3 Domenemodell Side 14 av 20

15 3.4 Aktivitetsdiagram Side 15 av 20

16 4.0 Design 4.1 Klassediagram I klassediagrammet har vi bevisst valgt å ikke liste opp set-metoder, get-metoder og parametere i metoder. Setmetoder og get-metoder mener vi er innlysende at er med, og at de derfor bare opptar plass. Parameterverdiene i metodene var vanskelige å holde styr på og endte med å bare skape rot, derfor tok vi bort de vi hadde. Vi vet dette gjør at diagrammet ikke beskriver løsningens struktur like godt. Variabelen VaktIDArray er en array som representerer en vakt, på indeks 0 ligger ukedag som indeks(1-7) og på indeks 1 ligger vaktnummer(1- antall vakter den dagen). Side 16 av 20

17 4.2 Sekvensdiagram Sekvensdiagram for usecase: Bytte Vakt Side 17 av 20

18 4.3 Logisk arkitektur 4.4 Brukergrensesnitt Dette er et vindu for en ansatt som vil gjøre endringer på vaktplanen: Ved innlogging presenteres brukeren med følgende vindu som standard (standardvindu kan selv defineres av brukeren). Her vises en kalender med vakter brukeren er satt opp på. Klikker han på en dato vises alle kolleger som er satt opp den dagen. Kolleger som ønsker å bytte vakt er flagget med et utropstegn ved navnet sitt. Klikker brukeren på Side 18 av 20

19 dette vises en meny hvor han kan sende en forespørsel om å bytte vakt. Ønsker brukeren å bytte vakt eller søke om fri høyreklikker han på datoen vakten er satt opp på og velger Ønsker bytte / Ønsker fri. Brukeren kan også klikke på sine kollegers navn og se deres timeplan. Navnet nederst til høyre for kalenderen oppdateres da med kollegaens navn. Ellers er det også mulig å vise vaktplanen i ukesvisning ved å klikke på skillearket over kalenderen. Øverst er det en menybar hvor brukeren kan velge mellom ulike valg. Klikker brukeren på navnet sitt nederst til venstre kan han oppdatere personalia og tilpasse siden som nevnt ovenfor. 5.0 Vurdering 5.1 Vurdering av foreslått løsning Vi har laget en grundig kravspesifikasjon, der vi har lagt til krav ettersom vi kom dypere i utviklingen. Designet vi leverer er enkelt og brukervennlig, samtidig som det er gjennomtenkt i forhold til at det skal være plass til alt. Samtidig som det er behagelig for brukeren med mye luft og store knapper i designet, blir det også enkelt å videreutvikle løsningen uten at det blir trangt om plassen. Hadde vi hatt mer tid, kunne vi derimot utviklet en lavfidelitetsprototype for mobile enheter. Modelleringen er gjort iterativt, noe som har ført til at alle modeller er oppdaterte og konsistente. Med grundig kravspesifikasjon og god kvalitet på identifiserte krav, modellering og lavfidelitetsprototype kan vi si at foreslått løsning formidler våre meninger og vurderinger på en meget bra måte. 5.2 Vurdering av valgt utviklingsmodell Utviklingsmodellen som ble bruk er vår egen spesialtilpasning av Rational Unified Process. De største tilpasningene vi gjorde var å droppe fasen overgang og disiplinene Implementation (Gjennomføring), Test (Testing) og Deployment (Utplassering). Vi planla og gjennomførte en inndeling i 7 iterasjoner. Ved 4. iterasjon innså vi at løsningen bydde på flere problemer enn det vi først forestilte oss. Under utviklingsprosessen dukket det stadig opp nye ideer og forslag som vi ikke hadde tatt hensyn til i kravspesifikasjonen. Men siden vi hadde en iterativ utviklingsprosess, måtte vi ikke gjøre mange endringer på det vi tidligere hadde laget, vi bare la til det nye og endret litt. Dette er ett av flere eksempler på at utviklingsprosessen har fungert svært bra. Dersom vi hadde brukt fossefallsmodellen som utviklingsmodell, ville vi i eksemplet over ha måttet brukt mye tid på å oppdatere og endre gamle, ferdige dokumenter og modeller, og sløst bort tid i forhold til vår modell. Side 19 av 20

20 5.3 Vurdering av eget prosjektarbeid Vi bestemte oss tidlig for å holde møter jevnlig, og dette har fungert bra. På hvert møte gikk vi i gjennom det som skulle være klart til møtet, vi avgjorde vi hva som måtte gjøres til neste møte og fordelte ansvar til hver enkelt. Alle har vist interesse og engasjement for å påta seg arbeidsoppgaver. Noe som kunne ha fungert bedre, er at i perioder med stor arbeidsmengde grunnet leveranser i andre emner nedprioriterte de fleste medlemmene jobbing med prosjektet. Vår risikohåndtering underveis har fungert bra. Fordi vi er fem medlemmer, var det enkelt å ta over arbeidet til en annen dersom han ble syk eller ikke kunne møte opp. Vi benyttet av oss Google Docs, Dropbox og Skype gjennom hele prosjektet, dette hjalp også dersom noen ikke kunne være fysisk tilstede på et møte. 6.0 Konklusjon Gruppen har kommet til den slutning at: - det var hensiktsmessig å benytte seg av en tilpasset utgave av Rational Unified Prosess for utviklingsprosessen i forhold til prosjektets størrelse. - kostnadene ikke overskred budsjettet på kr ,- - foreslått løsning, med modeller og lavfidelitetsprototype, er av høy kvalitet og kan brukes i videreutviklingen av produktet. - beslutningen om å lage en nettbasert løsning var bra med tanke på fremtidig videreutvikling og tilpasning til mobile enheter. Vårt forslag til videreutvikling er å utvikle en tilleggsløsning som er tilpasset smarttelefoner. Mål 1. var å Lage et forslag til løsning for et nettbasert system som håndterer detaljert journalføring av skiftliste og lønnsoversikt. Dette skal effektivisere personlig administrasjon(...). Dette målet mener vi ble oppnådd. Gruppen sluttførte rapporten den 25. november 2011, etter planen, og nådde mål nummer Litteraturliste [1] Systemutvikling, ISBN: [2] lesedato 4.nov 2011 [3] lesedato 4.nov 2011 [4] lesedato 23.nov 2011 Side 20 av 20

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

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

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

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

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

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

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

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

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

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

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

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1 Innhold Innledning... 2 Faseplan... 2 Iterasjonsplanlegging... 3 Oppstartsfasen... 3 Artefaktene i oppstartsfasen... 4 Utdypingsfasen... 5 Konstruksjonsfasen... 5 Overføringsfasen... 6 Litteratur... 7

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:

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

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 LEVERANSE 4 NY FUNKSJONALITET (ENDELIG) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson Dato:

Detaljer

UML-Unified Modeling Language

UML-Unified Modeling Language UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 11 UML modellering og use case. Gruppetime INF1055 UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav

Detaljer

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

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

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

INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel

INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel 2-1 Business Model 2-1 a) Scoping statements I Våre avgrensninger Timeregistreringssystemet

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

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

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

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av

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

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

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

Forslag til løsning. Oppgave 1

Forslag til løsning. Oppgave 1 Forslag til løsning Eksamen 2003 Oppgave 1 A) Lag en Business Model (COMET) for krisehåndteringssystemet. B) Diskuter fordeler og ulemper ved bruk av COMET i forhold til (Rational) Unified Process for

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

University of Oslo Department of Informatics. INF Modellering med objekter Oblig 2, V2004. Skrevet av:

University of Oslo Department of Informatics. INF Modellering med objekter Oblig 2, V2004. Skrevet av: University of Oslo Department of Informatics INF5120 - Modellering med objekter Oblig 2, V2004 Skrevet av: Gruppe 16 Geir Atle Hegsvold (gahegsvo) Harald Maalen (haralm) André Sollie (andresol) 2 Index

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

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering Use case realisering Designmodellering 31.01.2005 Kirsten Ribu UML-Unified Modeling Language Use Case diagram Klassediagram Oppførselsdiagrammer Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

Bachelorprosjekt 2015

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

Detaljer

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

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

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

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

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Rune Steinberg International Development Manager ERP INF1050 Systemutvikling Vår 2009 - Copyright Rune Steinberg 2009 1 Innledning

Detaljer

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Innledning Læringsmål Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Forstå hvorfor systemutviklingsprosessen er viktig Forstå de viktigste prinsippene for ulike prosesser

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

Vedlegg Side 83 av 155

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

Detaljer

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse Dagens forelesning Kravspesifikasjon Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? Noen resultater fra et UML-eksperiment

Detaljer

Hvordan bruke Helsegris for veterinær Innhold:

Hvordan bruke Helsegris for veterinær Innhold: Hvordan bruke Helsegris for veterinær Innhold: 1. Logge seg inn i Helsegris som veterinær 2. Godta vilkårene for å bruke Helsegris 3. Oppdatere kontaktinformasjonen 4. Kommer alltid til meny/forsiden ved

Detaljer

Innføring i BrandMaker Markedsplanlegger https://mp.mam.no. Media Asset Management AS http://www.mam.no

Innføring i BrandMaker Markedsplanlegger https://mp.mam.no. Media Asset Management AS http://www.mam.no Innføring i BrandMaker Markedsplanlegger https://mp.mam.no Media Asset Management AS http://www.mam.no Innholdsfortegnelse: Innholdsfortegnelse:... 2 Hva er BrandMaker Markedsplanlegger?... 3 Hva trenger

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

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

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer INF5120 - Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer alence@ifi.uio.no) 1 2 2-1: Business Model... 5 Scoping Statements Context Statements... 5 Goal modell...

Detaljer

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav? Kravspesifikasjon Kravspesifikasjon Erik Arisholm Simula Research Laboratory & Institutt for Informatikk Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? o Noen resultater

Detaljer

Kravspesifikasjon. 14. oktober 2002

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

Detaljer

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

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

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

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

Kvalitetskrav til løsninger

Kvalitetskrav til løsninger Prosjektoppgaven Kvalitetskrav til løsninger Noen retningslinjer for å styre beslutningene deres finnes i form av hva brukere forlanger av software (og hardware): Brukbarhet. - Produktet skal være selvforklarende

Detaljer

INF5120 - Oblig 2. Hour Registration System (HRS)

INF5120 - Oblig 2. Hour Registration System (HRS) INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon...

Detaljer

Geometra. Brukermanual. Telefon: 64831920

Geometra. Brukermanual. Telefon: 64831920 Geometra Brukermanual Telefon: 64831920 Innhold GENERELT...3 Hva er Geometra?...3 Om PDF tegninger...3 KOM I GANG!...5 Start programvaren og logg inn...5 Grunnleggende funksjoner:...6 Lag et prosjekt,

Detaljer

Så hva er affiliate markedsføring?

Så hva er affiliate markedsføring? Så hva er affiliate markedsføring? Affiliate markedsføring er en internettbasert markedsføring hvor Altshop belønner deg for hver kunde som du rekrutterer til Altshop. Vi vil ta godt hånd om dem for deg

Detaljer

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31 Kravspesifikasjon Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31 Forord Denne kravspesifikasjonen inneholder retningslinjer for oss og for det vi skal utvikle. Den inneholder funksjonelle

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

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

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

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

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

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

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

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

Gruppe 23. Rapport D2, MMI. Prototypen. Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under.

Gruppe 23. Rapport D2, MMI. Prototypen. Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under. Rapport D2, MMI Prototypen Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under. Man lager en ny avtale ved å trykke på knappen add event oppe i høyre hjørne. For å komme

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

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

Leveranse 2. September 27, 2002

Leveranse 2. September 27, 2002 Leveranse 2 gruppe 42 Nils-Kristian Liborg (brukergrensesnitt), Bente Brevig (beskrivelser, aktørbeskrivelser, diagram, kvalitetssikring), Tom Olav Bruaas (beskrivelser), Eirik Lied (beskrivelser, diagram,

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

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

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

Detaljer

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

Brukermanual Kandidat AFRs webportal for kandidater

Brukermanual Kandidat AFRs webportal for kandidater Brukermanual Kandidat AFRs webportal for kandidater Oppdatert manual kan lastes ned fra http://afr.norsktest.no Side 1 av 8 Innholdsfortegnelse Innholdsfortegnelse... 2 1. Praktisk informasjon... 3 2.

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

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

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

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

Detaljer

Brukerveiledning. Madison Møbler Administrasjonsside

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

Detaljer

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

1 Introduksjon til designmodellen - del B 2

1 Introduksjon til designmodellen - del B 2 Innhold Introduksjon til designmodellen - del B 2 2 UseCase 3 2. Usecasediagram........................... 3 2.2 Aktørbeskrivelser.......................... 4 2.3 Hendelsesforløp og sekvensdiagram for

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. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

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

Detaljer

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

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

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

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

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

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

En enkel lærerveiledning

En enkel lærerveiledning En enkel lærerveiledning ~ 1 ~ Innhold INNLEDNING... 3 Hva?... 3 Hvorfor?... 3 INN- og UTLOGGING... 4 Innlogging... 4 Utlogging... 5 Lærerinnlogging/-utlogging... 5 OUTLOOK / EPOST... 6 Skrive epost...

Detaljer

Evaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet

Evaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet Evaluering av It-systemer i et forvaltningsperspektiv Drift, vedlikehold og videreutvikling av IT-systemet Bakgrunnen IT-systemer har ofte lenger levetid enn forventet er ofte forretningskritiske utvikler

Detaljer

Innledning. Persona. For å ta for oss noen målgrupper kan vi tenke oss:

Innledning. Persona. For å ta for oss noen målgrupper kan vi tenke oss: Øving D1 i MMI Innledning Til oppgaven har jeg valgt å vurdere nettsidene www.netcom.no og www.telenor.no. Disse to telegigantene har en stor kundegruppe og gir da en større varians av målgruppen. Til

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

Opplæring i MinGat 6.0

Opplæring i MinGat 6.0 Opplæring i MinGat 6.0 Nytt i MinGat 6.0 Forespørsel på annen avdeling uten å bytte nivå Retur av mangelfulle forespørsler Virtuelle brukerprofiler automatisk tilgang i MinGat til nye avdelinger du blir

Detaljer

SPPR Software Project Progress Report Uke 42-43

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

Detaljer

Vedlegg LMC intranett

Vedlegg LMC intranett Vedlegg LMC intranett H12D02 Jarl-Håvard Holen Ole-Martin Larsen Fredrik Sethne-Andersen André Ritari Vedlegg 1 Resultater av kortsortering. Kortsortering Bruker 1, Salg: Kortsortering Bruker 2, Teknisk:

Detaljer

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey Mamut Open Services Mamut Kunnskapsserie Kom i gang med Mamut Online Survey Kom i gang med Mamut Online Survey Innhold MAMUT ONLINE SURVEY... 1 KOM I GANG MED MAMUT ONLINE SURVEY... 3 MAMUT-BRUKERE: OPPRETT

Detaljer

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering. Bakgrunn Modellering har lenge vært et kjent begrep innen systemutvikling. På 80-tallet ble metoder som Yourdon/Demarco og Gane&Sarson brukt for å lage dataflyt-diagrammer. Etter hvert ble disse integrert

Detaljer

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentasjon Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentsjon 23/04/2018 Systemutvikling og dokumentasjon/ia4412

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

Kostnaden ved å ikke involvere eldre i digitaliseringen. Hege Louise Borge Andrea Leikvold

Kostnaden ved å ikke involvere eldre i digitaliseringen. Hege Louise Borge Andrea Leikvold Kostnaden ved å ikke involvere eldre i digitaliseringen Hege Louise Borge Andrea Leikvold Hva handlet oppgaven om? Problemstilling Hva er kostnaden av å digitalisere offentlige tjenester? Hvordan opplever

Detaljer

Prosjektoppgave våren 2007

Prosjektoppgave våren 2007 Prosjektoppgave våren 2007 Innledning Formålet med kurset er å bli i stand til å delta i utviklingen av informasjonssystemer. Dette innebærer: å kjenne til bruken av informasjonssystemer, å kjenne til

Detaljer

Kort veiledning for avsendere og hentesteder

Kort veiledning for avsendere og hentesteder Kort veiledning for avsendere og hentesteder Side 1 Innholdsfortegnelse Innholdsfortegnelse Kort veiledning for avsender/hentested, ver 6.0 Daglige Oppgaver Før henting (korriger mengder) Legge inn merknader

Detaljer