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

Transkript

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

2 2-1 Business Model 2-1 a) Scoping statements I Våre avgrensninger Timeregistreringssystemet (heretter kalt Systemet) skal sørge for oversikt over hva konsulentselskapet Bedrift AS bruker sine ressurser til. Systemet skal ta seg av timeregistrering av bedriftens ansatte og fakturering av kunder. Lønn og vaktliste/planlegging av prosjekt faller utenfor Systemets scope. Systemet skal kun gi en oversikt over ressursbruken (registrerte timer på hvert prosjekt, hver ansatt og hver avdeling) samt sørge for fakturering. Hver uke må hver ansatt i Bedrift AS registrere de timene vedkommende har jobbet på de ulike prosjektene, evt. om han/hun har tatt ut avspasering eller ferie. Dersom han/hun har vært syk må det også føres opp. Dette gjøres i Systemet. Alle ansatte i Bedrift AS tilhører en avdeling. Prosjektledere legger inn prosjekter og tilordner dem prosjektnummer/kode. Når en ansatt skal velge et prosjekt han/hun jobber på, får han/hun opp alle prosjekter i sin avdeling, og kan velge blant dem. Det skal gis spesifikke koder for de ulike prosjektene og disse skal i Systemet finnes i en drop-down liste. Systemet skal være web-basert, og ha innlogging med brukernavn og passord. Administrator tildeler de ansatte brukernavn og passord. Rapporter Systemet skal kunne generere ulike rapporter: - For hvert prosjekt skal man kunne få en rapport over totalt antall timer brukt på prosjektet (som grunnlag for å fakturere kunder). - For hvert prosjekt skal man kunne få en rapport over ansatte som har brukt timer på prosjektet. - For hver ansatt skal man kunne få en rapport over hvor mange timer vedkommende har jobbet på ulike prosjekter og om han/hun har avspasert, har hatt ferie eller vært syk. - For hver avdeling skal man kunne få en oversikt over hvor mange timer avdelingen har brukt på ulike prosjekter. Ferie og avspasering I Systemet skal en ansatt registrere ferie, avspasering og sykdom. De ansatte skal skrive i ettertid eller rett i forkant at de har tatt/tar ut ferie eller avspasering. Systemet skal ikke ta hånd om søknader om ferie det håndteres av bedriftens personalsystem. Bedrift AS har innført avtale om fleksitid. Opptjent avspasering skal av Systemet beregnes som antall timer arbeidet utover 37,5 timer. En ansatt har ikke lov til å ta ut avspasering på forhånd, vedkommende må ha tjent inn plusstid først. For hver ansatt beregner Systemet et timebudsjett, med antall timer/dager avspasering til gode samt antall dager ferie til gode. Antall dager hver ansatt har ferie hentes fra 2

3 bedriftens personalsystem. Når en ansatt har tatt ut avspasering eller ferie og registrert det i Systemet, skal Systemet trekke dette fra vedkommendes t imebudsjett. II Aktører og interesser Stakeholdere for Systemet Figur: Stakeholdere 3

4 Aktører i Systemet Figur: Aktører 4

5 III Overordnet virksomhetsprosess for Bedrift AS Context diagram Dette diagrammet viser den/de naturlige flyten(e) i Bedrift AS slik det fungerer i dag. Først mottar man et anbud, og velger så om man vil gå videre i anbudskonkurransen, eller droppe det hele. Så lages en enkel kravspesifikasjon i bedriften, som man videre bygger anbudet sitt på. Anbudet sendes til anbudsgiver, som så avgjør hvilket anbud som vinner. Hvis man vinner anbudet utarbeides en detaljert kravspesifikasjon. Så starter prosjektet, og alle ansatte i prosjektgruppen jobber og registrerer antall timer arbeidet på prosjektet kontinuerlig. Prosjektet avsluttes og oppdragsgiver faktureres. Figur: Context Diagram 5

6 IV Vision for change Timeregistreringssystemet skal sørge for at Bedrift AS får oversikt over hvor ressursene i bedriften brukes, eksempelvis hvilke prosjekter er mest ressurskrevende. Til nå har det ikke vært mulig å få oversikt over dette. Utfra systemet skal prosjektleder kunne fakturere kundene for korrekt antall timer brukt på kundens prosjekt. Systemet skal også vedlikeholde et timebudsjett for hver ansatt, og derfra gi oversikt over avspaseringer og ferie til gode. Bedrift AS har til nå ikke systematiskert denne prosjektoversikten, og har fakturert kunder på basis av prosjektledelsens kladdelapper. Videre er det viktig for ledelsen å få oversikt over hvilke ansatte som jobber på hvilke prosjekter, samt hvilke prosjekter som krever mest ressurser. Systemet er et web-basert verktøy som skal støtte prosessene rundt timeregistrering for de ansatte i Bedrift AS. Hovedoppgavene vil være: - Registrering av timer på hvert prosjekt for hver ansatt - Fakturering av kunder, samt generering av andre rapporter - Vedlikehold av hver ansatts timebudsjett, herunder registrering av avspasering/ferie for hver ansatt 6

7 2-1 b) Goal model Dette diagrammet viser hvilke mål Bedrift AS har med Systemet, altså hva de ønsker å oppnå. Det overordnede målet med Systemet er å få en oversikt over ressursbruken (hvor mange timer som er brukt på forskjellige ting). Dette deles opp i 2 hovedemner: - Ressursbruk for kunder, som er ment å brukes for enklere å fakturere kunder. - Ressursbruk for ansatte, som kan gi informasjon om hvor mange timer en enkelt ansatt har jobbet på et prosjekt, hvor mange timer en ansatt har vært syk, hvor mange timer en gitt avdeling har brukt på et prosjekt osv. Ressursoversikt Ressursoversikt ansatte Ressursoversikt kunde Timeoversikt prosjekt Timeoversikt ansatte Påløpt pr. avdeling Påløpt pr. ansatt Timer pr. prosjekt Timer ferie Timer avspasering Timer syk Figur: Goal Model 2-1 c) Business resource model Denne modellen er en informasjonsmodell som viser relasjonene mellom informasjonsklasser i Bedrift AS, den viser sammenhengen mellom de forskjellige enhetene i Bedrift AS som er relevant for Systemet. Figur: Business resource model 7

8 2-1 d) Business Process & Role model Denne modellen er en aktivitetsmodell som beskriver sekvensen av aktiviteter i prosessen til Bedrift AS og hvilke roller/aktører som utfører disse. Diagrammene i modellen detaljerer hvordan man ønsker å jobbe med Systemet. Det deles opp i human steg og tool steg. Et human steg gjøres av et menneske, uten noen form for interaksjon med Systemet. Et tool steg gjøres med en komponent i Systemet av et menneske. Stegene som er merket som human er derfor ikke en del av Systemet, men må være med for å sette Systemet i kontekst. De tre hovedstegene i denne bedriften er å motta og jobbe på prosjektet, å sende faktura til kunden og å levere og avslutte et prosjekt. Disse stegene er videre detaljert i nye diagrammer. I diagrammet for å motta og jobbe på prosjekt kommer timeregistrering inn, som er det sentrale for Systemet. I diagrammet for å lage faktura benytter man de registrerte timene i Systemet for å fakturere kunden, mens man i diagrammet for å avslutte og levere prosjektet bruker Systemet for å avslutte et prosjekt (sette sluttstatus). Overordnet virksomhetsprosess for Bedrift AS Prosjektarbeid Figur: Business process model 8

9 Underordnet prosess Motta og jobbe på prosjekt Figur: Underordnet prosess 9

10 Underordnet prosess Lage faktura Figur: Underordnet prosess Underordnet prosess Avslutte og levere prosjekt Figur: Underordnet prosess 10

11 2-2 Requirements Model 2-2 a) System Boundary Model Figur: System boundary model 11

12 2-2 b) Subsystem Grouping Model Figur: Subsystem grouping model 12

13 2-2 c) RA Analysis Model Dekomponering: Basert på de aktørene vi har beskrevet og hva de gjør med systemet, har vi kommet fram til følgende komponenter: TimeregistreringsEditor RapportViewer ProsjektEditor AdministrasjonsEditor Component Infrastructure ProsjektService AdminService ProsjektInfo PersonalInfo Figur: Component structure bus pattern Vi har mappet subsystemene til enten en tool-, business service- eller resource servicekomponent. - TimeregistreringsEditor er en tool-komponent brukt av de ansatte. - RapportViewer er en tool-komponent brukt av alle aktører for å generere ulike rapporter, for å få oversikt over ressursbruken, herunder også fakturering. - ProsjektEditor er en tool-komponent brukt av prosjektleder for å registrere nye prosjekter (med koder). - AdministrasjonsEditor er en tool-komponent for administrator, for å drifte systemet. - AdminService er en business service komponent for å hente ut informasjon om alle ansatte fra personalsystemet (antall dager ferie etc.). - ProsjektService er en business service komponent for å kunne legge inn og hente ut informasjon om alle prosjektene (herunder også fakturering og timeregistrering). - ProsjektInfo og PersonalInfo er resource service komponenter som sørger for persistent lagring av henholdsvis ProsjektService og InformasjonsService. Alle tool-komponentene vil være tilgjengelige gjennom en web-server. 13

14 2-2 d) Use Case Scenario Model Vi har valgt å se nærmere på to av use casene, nemlig Registrer prosjekt og Registrer timer. Her følger en tekstlig beskrivelse av disse: Use case 1 Registrer prosjekt Prioritet 1 Trigger Aktører Prekondisjon Postkondisjon Beskrivelse Variasjoner En prosjektleder ønsker å legge inn et nytt prosjekt/oppdrag i systemet Prosjektleder Bedriften har mottatt et oppdrag, og tilegnet det en prosjektleder Prosjektet er lagt inn i systemet Trinn Handling 1 Prosjektleder logger seg inn med passord 2 Systemet viser en side med ansattnavn og ulike valg 3 Prosjektleder velger registrere prosjekt 4 Systemet viser skjema for registrering av prosjekt 5 Prosjektleder fyller ut skjemaet og velger registrer prosjekt 6 Systemet gir tilbakemelding om at registreringen er fullført 1a Passordet blir ikke godkjent 1a1 Systemet gir tilbakemelding om dette, og gir mulighet til å prøve igjen 5a Skjemaet er feil utfylt 5a1 Systemet gir tilbakemelding om dette, og gir mulighet til å prøve igjen 14

15 Use case 2 Registrer timer Prioritet 1 Trigger Aktører Prebetingelse Postbetingelse Beskrivelse Variasjoner En ansatt ønsker å registrere timer Ansatt En ansatt har arbeidet på et prosjekt og ønsker å registrere timene i systemet Timene er registrert i systemet Trinn Handling 1 Ansatt logger seg inn med passord 2 Systemet viser en side med ansattnavn og ulike valg 3 Ansatt velger timeregistrering 4 Systemet viser en side med oversikt over prosjekter* 5 Den ansatte velger prosjekt 6 Systemet viser skjema for timeregistrering 7 Den ansatte fyller ut skjemaet og velger registrer timer 8 Systemet gir tilbakemelding om at registreringen er fullført 1a Passordet blir ikke godkjent 1a1 Systemet gir tilbakemelding om dette, og gir mulighet til å prøve igjen 7a Skjemaet er feil utfylt 7a1 Systemet gir tilbakemelding om dette, og gir mulighet til å prøve igjen *Fra listen over prosjekter kan man også velge avspasering, syk eller ferie. Skjemaet som kommer opp er tilpasset valget den ansatte har gjort. Fremgangsmåten for den ansatte er akkurat den samme, det er derfor ikke definert egne use cases for dette. 15

16 2-3 Architecture Model 2-3 a) Interface & Interaction Specification I Grensesnittbeskrivelser for komponenter Vi har valgt å ta for oss grensesnittene IUserService for TimeregistreringsEditor Tool. samt IProsjektService og IProsjektInfo som skal sørge for at man i Systemet kan registrere timer, registrere prosjekter og vise ulike rapporter. IUserService +login(navn, passord) : status +lagprosjektliste() +finnprosjekter() : Collection +regtimer(ansatt, dato, timer, prosjid) : void +regsyk(ansatt, dato) : void +regferie(ansatt, dato) : void +regavspasering(ansatt, dato) : void IProsjektService +regtimer(ansatt, dato, timer, prosjid) : void +regsyk(ansatt, dato) : void +regferie(ansatt, dato) : void +regavspasering(ansatt, dato) : void +visrapport(type) : Rapport +regprosjekt(prosjid, beskrivelse) : void IProsjektInfo +regprosjekt(prosjid, beskrivelse) : void +genererrapport() : Rapport +regtimert(ansatt, dato, timer, prosjid) : void +regsyk(ansatt, dato) : void +regferie(ansatt, dato) : void +regavspasering(ansatt, dato) : void +finnprosjekt(prosjid) : Prosjekt +finnprosjekter() : Collection Figur: Grensesnittbeskrivelser 16

17 II Samarbeid mellom komponenter Diagrammene nedenfor viser hvordan de ulike komponentene samarbeider for å utføre to ulike use case, henholdsvis registrer prosjekt og registrer timer. UC 1 Registrer prosjekt Figur: UC - Registrer prosjekt UC 2 Registrer timer Figur: UC - Registrer timer 17

18 2-3 b) Component Structure Components Structure-modellen viser hvordan komponentene samarbeider med hverandre gjennom grensesnitt. Vi får 4 applikasjonskomponenter i Systemet: Timeregistrering AC, Rapportgenerering AC, Prosjektledelse AC og Admin AC. Figur: Component structure 18

19 TimeregistreringsEditor Tool Component Structure Diagrammet viser TimeregistreringsEditor tool-komponenten, med dets interne komponenter. TimeregistreringsEditorUS er en User Service som sørger for fasaden mot Tool en. Grensesnittet IUserService er nøyere beskrevet i et tidligere kapittel. Figur: Component structure RapportViewer Tool Component Structure Diagrammet viser RapportViewer tool-komponenten, med dets interne komponenter. RapportViewerUS er en User Service som sørger for fasaden mot Tool en. Figur: Component structure 19

20 2-3 c) Internal Design BCE Analyse for TimeregistreringsEditor Tool Denne analysemodellen er laget ut fra analyse av Use case 1 (Registrer timer) og arkitektur-komponenten Timeregistrering AC. Modellen viser forholdet mellom GUIklassene, controller-klassene og entitets-klassene. Figur: BCE analyse 20

21 En beskrivelse av BCE-klassene er gitt i tabellen under: BCE klasse LoggInnController Tilgang TimeregistreringsController LoggInn Hoved ProsjektListe RegistreringsSkjema Prosjekter Beskrivelse Styrer logg inn-prosessen. Brukeren skriver inn brukernavn og passord gjennom LoggInn klassen. Representerer tilgangsautorisasjonen. Hovedcontrolleren GUI-klasse, selve logg inn-vinduet som er det første som møter brukeren. Dette er hoved-guiklassen, og er vinduet som møter brukeren når han har logget inn. Her blir brukeren presentert for hvilke muligheter han har i systemet. Denne GUI-klassen viser en liste over de tilgjengelige prosjektene brukeren kan registrere timer på (samt avspasering, syk og ferie) GUI-klasse som viser et skjema, som brukeren må fylle ut for å registrere timer. Representerer lagrede prosjekter som er tilgjengelig for timeregistrering 21

22 2-4 Platform Specific Model 2-4 a) Component Implementation Model TimeregistreringsEditor Tool Design Class design Her er en oversikt over klassedesignen for én del av Systemet, nemlig timeregistrering. Vi har tatt utgangspunkt i BCA analysen ovenfor og mappet derfra til klasser. Foreløpig er vi ganske tidlig i utviklingsfasen og derfor har vi ikke utarbeidet noe mer spesifikt for UserService og ConfigurationService. Dessuten vil nok RegistreringsSkjemaDialogen bestå av ulike paneler, som vi på det nåværende tidspunkt ikke har klart for oss. Det vil være mye tilsvarende for de andre komponentene. Figur: Class design 22

23 2-4 b) Deployment Model Deployment modellen viser hvordan Systemet skal settes ut i Bedrift AS, med hensyn til egenskaper og konfigurasjoner for plattformen det skal kjøres på. Systemet skal være web-basert, så de ulike komponentene må ligge på en web-server. De persistente dataene (all info om prosjekter etc.) lagres i en database, og kommunikasjonen mellom web-serveren og db-serveren foregår ved bruk av JDBC-APIen. Figur: Deployment model 23