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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Brukermanual for nettpublisering. frivilligsentral.no

Brukermanual for nettpublisering. frivilligsentral.no Brukermanual for nettpublisering frivilligsentral.no Innholdsfortegnelse Introduksjon 3 1 - Innlogging 4 1.1 - Logge inn 4 1.1 - Logge ut 4 2 - Grensesnitt 5 2.1 - Menyfelt 5 2.2-3 - Opprette, lagre og

Detaljer

Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428

Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428 Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428 Gruppe 1: Fredrik Melsom Klausen, Andreas Limyr, Odd-Wiking Rahlff, Tho Diu Tang 1...1 2. BUSINESS MODEL...2 2.1

Detaljer

Conference Centre Portal (CCP)

Conference Centre Portal (CCP) IN-MMO Obligatorisk oppgave 1 Brian Elvesæter mmo-oppgaver@ifi.uio.no 1 Conference Centre Portal (CCP) 2 1 Oblig 1: Problem description [1/3] The Conference Center Portal is an Internet portal that organizers

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

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

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

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

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

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

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

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

Dokument 3 - Prosessdokumentasjon

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

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

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

Detaljer

Planlegging og dokumentasjon

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

Detaljer

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

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

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

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

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

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

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

Detaljer

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

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

1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2. 1. 1 Status... 2. 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV...

1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2. 1. 1 Status... 2. 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV... Dossier Kompetanse Innholdsfortegnelse 1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2 1. 1 Status... 2 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV... 3 1.2.1 Personalia... 3 1.2.2

Detaljer

SPPR Software Project Progress Report Uke 44-45-46

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

Detaljer

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495 Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten

Detaljer

11.0.0 W i n T i d. Nyheter versjon 11.0.0 og Dashboard versjon 4.0.0 Logica Norge AS

11.0.0 W i n T i d. Nyheter versjon 11.0.0 og Dashboard versjon 4.0.0 Logica Norge AS 11.0.0 W i n T i d Nyheter versjon 11.0.0 og Dashboard versjon 4.0.0 Logica Norge AS Innholdsfortegnelse 1. OM DOKUMENTET... 4 1.1 DOKUMENTETS MÅLSETNING... 4 1.2 HVEM ER DOKUMENTET SKREVET FOR?... 4 1.3

Detaljer

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

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 30.04.2007. 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

Bytte til OneNote 2010

Bytte til OneNote 2010 I denne veiledningen Microsoft OneNote 2010 ser helt annerledes ut enn OneNote 2007, så vi har laget denne veiledningen for å gjøre det så enkelt som mulig for deg å lære forskjellene. Les videre for å

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

1 Innledning... 2. 2 Innlogging... 2. 3 Startsiden... 3. 3.1 Hovedoverskrifter... 3 4 Meny... 5. 4.1 Tilbake til startsiden... 5. 4.2 Profil...

1 Innledning... 2. 2 Innlogging... 2. 3 Startsiden... 3. 3.1 Hovedoverskrifter... 3 4 Meny... 5. 4.1 Tilbake til startsiden... 5. 4.2 Profil... Innholdsfortegnelse 1 Innledning... 2 2 Innlogging... 2 3 Startsiden... 3 3.1 Hovedoverskrifter... 3 4 Meny... 5 4.1 Tilbake til startsiden... 5 4.2 Profil... 6 4.3 Kalender... 7 4.3 Forespørsler... 8

Detaljer

Veileder til levering og godkjenning av rapporteringsdata til DBH-F

Veileder til levering og godkjenning av rapporteringsdata til DBH-F 07.06.2012 Veileder til levering og godkjenning av rapporteringsdata til DBH-F Innhold Punkt I Hvordan fungerer dette? Hva må jeg vite før jeg går i gang?... 2 Punkt II Laste opp filer... 9 Punkt III Vis

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

BRUKERMANUAL. Deviations and Reporting

BRUKERMANUAL. Deviations and Reporting BRUKERMANUAL Deviations and Reporting Forord Dette er brukermanual for CEMAsys Immediate Reporting applikasjon som er laget for iphone og Android telefoner. CEMAsys Immediate Reporting er en applikasjon

Detaljer

IT I PRAKSIS!!!!! IT i praksis 20XX

IT I PRAKSIS!!!!! IT i praksis 20XX IT I PRAKSIS 1 IT i praksis 20XX 2 IT I PRAKSIS FORORD 3 INNHOLD 4 IT I PRAKSIS Styringsmodell for utviklingsprosjekter (SBN) 5 Fra en idé til gevinstrealisering styringsmodell for utviklingsprosesser

Detaljer

De første skrittene med Norlønn

De første skrittene med Norlønn De første skrittene med Norlønn Norlønn er et nettbasert lønnssystem som er utviklet av Norlønn AS, og som kan betjenes direkte via internett, for eksempel gjennom Internet Explorer eller Mozilla Firefox.

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

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

CustomPublish.com. Brukere. Introduksjon til brukerhåndtering i CustomPublish

CustomPublish.com. Brukere. Introduksjon til brukerhåndtering i CustomPublish CustomPublish.com Brukere Introduksjon til brukerhåndtering i CustomPublish Innhold 1. Innledning 2. Ny brukergruppe 3. Ny bruker 4. Forfattere 5. Bruk 1. Innledning Når du klikker på «brukere» i administrasjonen,

Detaljer

Brukermanual. Studentevalueringssystem

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

Detaljer

Microsoft Project 2000

Microsoft Project 2000 Microsoft Project 2000 Finn Haugen TechTeach 14. august 2003 Sammendrag Dette dokumentet gir en kort introduksjon til Microsoft Project 2000 for bruk ved Høgskolen i Telemark - avdeling for teknologiske

Detaljer

Introduksjon i bruk av Microsoft Outlook 2003 med Exchange for NHH

Introduksjon i bruk av Microsoft Outlook 2003 med Exchange for NHH Introduksjon i bruk av Microsoft Outlook 2003 med Exchange for NHH Innhold Introduksjon i bruk av Microsoft Outlook 2003 med Exchange for NHH... 1 Innhold... 1 Introduksjon... 2 Grensesnitt... 3 Sende

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

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

IST Skole Fravær - Foresatt

IST Skole Fravær - Foresatt IST Skole Fravær - Foresatt Velkommen til en ny skole! IST tar nå steget fra kun å levere programvare til å forenkle og utvikle alle skolens funksjoner. Våre løsninger tar hånd om prosessene fra den dagen

Detaljer

Ferieoverføring g2 2015-2016

Ferieoverføring g2 2015-2016 Ferieoverføring g2 2015-2016 1 cgi.com 2015 CGI GROUP INC. Ferieoverføring 2015 2016 WinTid holder orden på den ansattes ferieregnskap. I januar hvert år må dette gjøres opp, slik at den ansatte får flyttet

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

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

Visma.net Expense. Rask. Riktig. Enkelt. Derfor kommer du til å like Visma.net Expense

Visma.net Expense. Rask. Riktig. Enkelt. Derfor kommer du til å like Visma.net Expense Rask. Riktig. Enkelt. Derfor kommer du til å like Visma.net Expense Alltid tilgjengelig og oppdatert Kjøreutgifter direkte inn i løsningen Tilknyttet kredittkort Ingen dobbeltregistrering Enkel integrasjon

Detaljer

Hjelp / Brukerveiledning for MinSkyss (klikk på emne)

Hjelp / Brukerveiledning for MinSkyss (klikk på emne) OBS! Veiledningen er litt eldre enn siste versjon av selve systemet. Derfor stemmer ikke alle bilder i MinSkyss med det som står her. Til gjengjeld har vi fått inn infoknapper i bilden når du fylle utsøknaden.

Detaljer

Snake Expert Scratch PDF

Snake Expert Scratch PDF Snake Expert Scratch PDF Introduksjon En eller annen variant av Snake har eksistert på nesten alle personlige datamaskiner helt siden slutten av 1970-tallet. Ekstra populært ble spillet da det dukket opp

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni, 2008 Eksamen

Detaljer

Brukskvalitet. Bruk og nytte av systemet

Brukskvalitet. Bruk og nytte av systemet Brukskvalitet Bruk og nytte av systemet Fem grunner til at systemer er vanskelige å bruke Systemet er tilpasset maskinen og arbeidsoppgaven - ikke brukeren Brukerenes arbeidsoppgaver endres raskt, mens

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Hvordan søke om pre-lei i nettportalen NordLEI

Hvordan søke om pre-lei i nettportalen NordLEI Hvordan søke om pre-lei i nettportalen NordLEI I nettportalen NordLEI kan klienter søke om pre-lei for sine juridiske enheter. Videre tilbyr NordLEI også såkalt assistert registrering (pre-lei-søknad på

Detaljer

Ny designmanual og ny StudentWeb. Brukerforum 2012 Kathy Foss Haugen

Ny designmanual og ny StudentWeb. Brukerforum 2012 Kathy Foss Haugen Ny designmanual og ny StudentWeb Brukerforum 2012 Kathy Foss Haugen Felles uttrykk på nett FUN-prosjekt i Seksjon for utvikling av nasjonale informasjonssystemer (SUN) NetLife Research AS Prosjekt Designmanual

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

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

Detaljer

Meeting Reservation System

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

Detaljer

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

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

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

Detaljer

Brukerveiledning e-postsystem

Brukerveiledning e-postsystem 1 Brukerveiledning e-postsystem Innholdsfortegnelse Pålogging:....... 2 Opprette e-post:..... 4 Vedlegg:.... 4 Kalender:... 7 Visning: 7 Ny avtale:.... 7 Invitere deltakere:.... 9 Bytte passord på konto

Detaljer

hypernet Direkte Brukerdokumentasjon for foresatte Version 1.0

hypernet Direkte Brukerdokumentasjon for foresatte Version 1.0 hypernet Direkte Brukerdokumentasjon for foresatte Version 1.0 Innholdsfortegnelse hypernet Direkte for foresatte...3 Infotavle... 3 Innlogging for foresatte... 3 Tjenester for innlogget foresatt... 4

Detaljer

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler

Detaljer

Brukerveiledning for e-postløsning Desember 2011

Brukerveiledning for e-postløsning Desember 2011 Brukerveiledning for e-postløsning Desember 2011 Versjon 1.0 Side 1 av 6 Innledning Altibox har valgt å fokusere på en helt ny e-post løsning som vil kunne gi brukere bedre funksjonelle muligheter i tiden

Detaljer

BRUKERDOKUMENTASJON WEB for Avdelingsleder En beskrivelse av hvordan avdelingsledere benytter. WEB-løsningen i Bluegarden Tidregistrering

BRUKERDOKUMENTASJON WEB for Avdelingsleder En beskrivelse av hvordan avdelingsledere benytter. WEB-løsningen i Bluegarden Tidregistrering BRUKERDOKUMENTASJON WEB for Avdelingsleder En beskrivelse av hvordan avdelingsledere benytter WEB-løsningen i Bluegarden Tidregistrering August 2011 INNHOLDSFORTEGNELSE: Dokumentgodkjenning og historikk

Detaljer