INF 5120 Obligatorisk oppgave Nr 2

Transkript

1 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping statements / context statements... 2 Aktører og interesser... 3 Overordnet virksomhetsprosess... 3 Vision of change... 3 Risk analysis...4 Goal modell...4 Business resource model... 6 Business process and role model Requirements modell... 8 System boundary model... 8 Subsystem grouping modell... 9 Reference Architectual Analysis Model Use Case Scenario Modell Architect modell Interface and interaction model Component Structure Internal Design BCE Analyse BCE to Class Mapping BCE Class Diagram Platform spesific modell Deployment modell

2 1 Business model Innledende kommentarer Vi valgte å bruke Word, Powerpoint og Visio som verktøy for å løse oppgaven. Vi har brukt COMET-dokumentasjonen med tilhørende eksempler som grunnlag for oppgaveløsningen. I tillegg har vi til en viss grad brukt notater fra forelesningene. Der hvor vi ikke føler at vi ville lært noe mer med å lage diagrammer for alle komponenter, funksjoner, grensesnitt, etc. har vi valgt å kun lage for ett. Vi lagde ikke PSM-modell for systemet siden verktøyene vi brukte ikke ga noen støtte for generering av dette, og vi så ikke hensikten med å lage dette for hånd. Andre avgrensninger Systemet integrerer ikke med andre systemer (som for eksempel lønnssystem) Vi antar at systemet ikke har sikkerhetskrav (inklusive innlogging), og at dette håndteres av bedriftens eksisterende infrastruktur Motivering og oppfølging av bruk er utenfor grensene til vårt system Scoping statements / context statements Under er vist Context diagram med etterfølgende beskrivelse av aktørene. Økonomiansvarlig Ansatt Prosjektleder Context diagram 2

3 Aktører og interesser Aktører Ansatt Prosjektleder Økonomiansvarlig Interesser Registrere timer, ferie og avspasering. Få oversikt over timer. Få oversikt over påløpende timer per prosjekt. Systemeier Få oversikt over ferier og avspasering Få oversikt over timeforbuk Oppretting og support Definere prosjekter Overordnet virksomhetsprosess Under er vist en overordnet virksomhetsprosess som vi lagde ved å ta utgangspunkt i aktørene og deres interesser. Ansatt Prosjektleder Økonomiansv. Registrere timer Ta ut rapport Ta ut rapport Ta ut rapport Evaluer timeforbruk Avstemme med budsjett Lage rapport til styringsgruppe Rapporter til ledelse Overordnet virksomhetsprosess Vision of change Bedriften har i dag ikke oversikt over tidsforbruk, og ønsker å innføre timelister for å få bedre kontroll over prosjekter og den ansattes tidsforbruk. 3

4 Systemet vil gi en oversikt over ressursforbruk, og føre til økt fleksibilitet i henhold til ressursfordeling. Det vil også bli bedret oversikt for den ansatte og økonomiavdeling mht avspasering, timer og ferier noe som fører mer effektiv ressursbruk. I fremtiden kan dette systemet integreres med lønn og prosjektstyringsverktøy. Alle brukere vil få tilgang til applikasjonen. Risk analysis Systemet er så dyrt å utvikle at return of investment (ROI) er negativ. Tiltak: Lage business case Systemet ikke blir ikke brukt på grunn av manglende oppfølging Tiltak: personal og opplæringsavdeling får ansvar for innføring og motivering Manglende arkitekturvurderinger kan gjøre fremtidige endringer dyrt. Tiltak: gjør arkitekturvurding basert på IT-strategi. Vi vurderer håndtering av disse risikoene til å være utenfor scopet til oppgaven. Goal modell Figuren under viser et målhierarki samt en tabell som utdyper innholdet. Mer effektiv ressursbruk Enkel oversikt over ferie og avspasering Enkel oversikt over prosjektressurser Øke bevisshet på egen tidsbruk Enkel timeregistrering Enkel oversikt Goal Model 4

5 Mer effektiv ressursbruk Enkel oversikt over ferie og avspasering Enkel oversikt over prosjektressurser Økt bevissthet på egen tidsbruk Enkel timeregistrering Enkel oversikt For økt konkurannsedyktighet ønsket effektiv ressursbruk For at økonomiavdeling skal kunne avstemme rapporterte timer med lønnsystemer og gjøre oppfølgning. For at prosjektleder skal kunne gjøre ressursrapporter og avstemme med budsjett slik at styringsgruppe kan treffe de rette tiltak. For at ansatte lettest mulig skal kunne registrere timer For å lett kunne planlegge egen ressursbruk 5

6 Business resource model Figuren under viser de sentrale entitene i informasjonsmodellen og relasjonen mellom disse, samt en beskrivende tabell. Ansatt Prosjekt Timer Ferie Avspasering Business information model/domain model Resource Timer Ansatt Ferie Avspasering Prosjekt Description De timene en ansatt har jobbet for et prosjekt (eventuelt ferier/avsparing) Ansatt i bedrifter som timer knyttes mot Timer som tas ut i ferie Timer som avspaseres Prosjekt som timer knyttes mot 6

7 Business process and role model Modellen under viser hvordan målene spesifisert i goal model understøttes av aktivitetsdiagrammet for overordnet virksomhetsprosess. Mer effektiv ressursbruk Enkel oversikt over ferie og avspasering Enkel oversikt over prosjektressurser Øke bevisshet på egen tidsbruk Enkel timeregistrering Enkel oversikt Evaluer timeforbruk Avstemme med budsjett Registrere timer Ta ut rapport (fra ansatt) Goal Model 7

8 2 Requirements modell System boundary model Modellen under viser hvilke use case som er innefor grensene til vårt system, samt hvilke aktører som benytter disse. 8

9 Subsystem grouping modell Modellen under viser hva vi anser som en logisk oppdeling av systemet i subsystemer. 9

10 Vi har valgt følgende use case for detaljering. De andre vil følge samme mønster. Use Case 4: Få oversikt over påløpte timer per prosjekt Priority 2 Goal For at prosjektleder skal kunne gjøre ressursrapporter og avstemme med budsjett slik at styringsgruppe kan treffe de rette tiltak. Actors Prosjektleder Pre-condition Timer må registrert, og prosjekt må være opprettet. Post-condition Ingen tilstandsendring i systemet. Facade Quality Requirements Det må være mulig å hente ut rapporter i alle populære webbrowsere. Scenario Hente ut oversikt over registrerte timer per prosjekt i rapporteringsform. Description 1. Gå til prosjektrapport 2. Angi prosjektidentitet 3. Angi ønsket periode 4. Vis rapport over timeforbruk for aktuelt prosjekt fordelt på ansatte og periode Prioriteten er satt ut i fra at deler av systemet vil fungere uten denne funksjonaliteten. 10

11 Reference Architectual Analysis Model Systemet vårt er såpass begrenset at vi har valgt å la subsyststemene identifisert i subsystem grouping modell være komponentene i vårt system. Vi har valgt oppdelingen basert på funksjonalitet vi logisk sett mener hører sammen, istedenfor å lage en tool -komponent for hver rolle. Grunnen til dette er at vi tror dette fører til et mer robust system, og at flere av personene vil inneha mer enn en rolle. Use Case Scenario Modell Use Case er detaljert i Subsystem Grouping Model. Sekvensdiagram kommer i Architectual Model. 11

12 3 Architect modell Herfra og ut har vi gjort avgensningen at vi kun ser på komponenten RapporteringServide. Interface and interaction model 12

13 Interface modell for Rapporteringsservicekomponenten: Interface Identification Purpose Operational signature IRapporteringService Ansvarlig for å tilby alle rapporter i systemet. Relatert til Use Case: 3, 4, 5, 6. hentprosjektrapport (Input: prosjektid, periode. Output: Rapport) hent hentferieavspaseringrapport (Input: Ansatt, Output: Rapport) henttimerapport( Input: Ansatt, Output: Rapport) Scenarios - Non-functional Rapporter må leveres på HTML-format. requirements Max ventetid er 20 sekunder. Protocols Java Interaction diagramet under viser en operasjon, hentprosjektrapport, de andre operasjonene vil være tilsvarende. 13

14 ITimeInfo er ikke beskrevet i Interface Specification ovenfor, men vil være tilsvarende IRapporteringsService som er beskrevet. Component Structure På grunn av vår avgrensning om å kun gå videre med en komponent, blir denne modellen lik Interface and Interaction model beskrevet tidligere i dette kapittelet. Internal Design BCE Analyse Under har vi gjort en BCE-analyse på bakgrunn av hva vi antar vil være skjermbilder i systemet. 14

15 BCE to Class Mapping Modellen under viser hvordan vi gikk fra skjermbilder til GUI-klasser. ProsjektrapportManager Åpne Prosjekt Søk opp periode Rapporter timeforbruk ÅpneProsjektDialog SøkPeriodeDialog RapporDialog 15

16 BCE Class Diagram Figuren under viser sammenhengen mellom GUI-klassene tegnet i et klassediagram. 16

17 4 Platform spesific modell Deployment modell Under er et deploymentdiagram som viser hvordan vi ser for oss at applikasjonen vil se ut i et kjøremiljø. Merk at komponentene på serveren vil kjøre i en applikasjonsserver, mens komponenten på klienten vil kjøre i en webbrowser. 17