Vakt og lønnssystem - Rema 1000

Avdeling for ingeniørutdanning Høgskolen i Oslo og Akershus Prosjektrapport Systemutvikling (LO138A) Høst 2011 Vakt og lønnssystem - Rema 1000 Gruppe 8 Forfattere: Andreas Baaserud, s169982 Ravi Agnihotri, s171178 Torbjørn Martinsen, s171190 Jonathan Sætre, s169974 Herish Hashemi s169960 Dato: 25.11.2011 Side 1 av 20

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

Innholdsfortegnelse Sammendrag... 2 Versjonslogg... 4 1.0 Introduksjon... 4 1.1 Bakgrunn... 4 1.2 Mål for prosjektet... 5 1.3 Omfang av løsning... 5 1.4 Suksesskriterier... 5 1.4.1 Planlegging... 5 1.4.2 Kommunikasjon... 6 1.4.3 Samarbeid... 6 1.4.4 Risikoplan... 6 1.4.5 Involvere bruker... 6 1.5 Antagelser... 6 2.0 Tilpasning av utviklingsmodell... 6 2.1 Beskrivelse av utviklingsmodell... 6 2.2 Begrunnelse for tilpasninger... 9 3.0 Analyse... 10 3.1 Kravspesifikasjon... 10 3.1.1 Funksjonelle krav... 10 3.1.2 Ikke-funksjonelle krav... 11 3.2 Use Case Modell... 12 3.2.1 Use case diagram... 12 3.2.2 Detaljerte Use case beskrivelser... 13 3.3 Domenemodell... 14 3.4 Aktivitetsdiagram... 15 4.0 Design... 16 4.1 Klassediagram... 16 4.2 Sekvensdiagram... 17 4.3 Logisk arkitektur... 18 4.4 Brukergrensesnitt... 18 5.0 Vurdering... 19 5.1 Vurdering av foreslått løsning... 19 5.2 Vurdering av valgt utviklingsmodell... 19 5.3 Vurdering av eget prosjektarbeid... 20 6.0 Konklusjon... 20 7.0 Litteraturliste... 20 Side 3 av 20

Versjonslogg Versjon Dato Forfatter(e) Beskrivelse av versjon v1.0 25.11.2011 Ravi, Andreas, Herish, Torbjørn, Jonathan v0.9 24.11.2011 Ravi, Andreas, Herish, Torbjørn, Jonathan v0.8 24.11.2011 Ravi, Andreas, Herish, Torbjørn, Jonathan v0.7 23.11.2011 Ravi, Andreas, Herish, Torbjørn, Jonathan v0.6 4.11.2011 Ravi, Andreas, Herish, Torbjørn, Jonathan v0.3 12.10.2011 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 1-3 1.0 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

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 2011. 1.3 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 1.4.1 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

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. 1.4.3 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. 1.4.4 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. 1.4.5 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

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

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

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

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

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å 0.01-0.3 sek kostnadsramme på kr 160.000,-, 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

3.2 Use Case Modell 3.2.1 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

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

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

3.4 Aktivitetsdiagram Side 15 av 20

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

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

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

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

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 160.000,- - 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 2. 7.0 Litteraturliste [1] Systemutvikling, ISBN: 978-82-02-28605-7 [2] http://en.wikipedia.org/wiki/ibm_rational_unified_process lesedato 4.nov 2011 [3] http://no.wikipedia.org/wiki/rational_unified_process lesedato 4.nov 2011 [4] http://no.wikipedia.org/wiki/rational_unified_process#disipliner lesedato 23.nov 2011 Side 20 av 20