Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Transkript

1 PROSJEKTGRUPPE 1 MGT SOFTWARE LEVERANSE 4 NY FUNKSJONALITET (ENDELIG) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson Dato: 18. november 2005 Fil: Leveranse4.pdf

2 Innholdsfortegnelse Innholdsfortegnelse «Use case»-diagrammer for ny funksjonalitet Aktører beskrivelser «Use case»-diagram «Use case»-beskrivelser Vis turnusplan Legg til ny turnuspost Endre turnuspost Slett turnuspost Sekvensdiagram Vis turnusplan Legg til turnuspost Endre turnuspost Slette turnuspost Klassediagram Før implementasjon Etter implementasjon Forskjeller før og etter implementasjon TurnusPost-klassen TurnusPlan-klassen Mangler i systemet Daglig, ukentlig og månedlig turnusplanvisning Skiftreglement Brukervennlighet Innlogging og rettigheter Annet...15 Leveanse4.pdf 18. november 2005 Side 2

3 1. «Use case»-diagrammer for ny funksjonalitet 1.1. Aktører beskrivelser Vi har valgt å dele aktørene opp i to hovedaktører. Dette fordi vi ikke ser noen hensikt i å dele opp aktørene i mindre fraksjoner. Det er hovedsaklig to oppgaver som skal utføres, den ene er å se på en turnusplan og den andre er å administrere en turnusplan. Alle skal ha tilgang til å se på gjeldende turnusplan, mens kun administrasjon, overleger og oversykepleiere skal kunne administrere denne. Vi finner ingen forskjell mellom hva en administrator, overlege og oversykepleier kan gjøre, og har derfor valgt å gruppert disse under en aktør. Aktør: Beskrivelse: Eksemple: Ansatt En samlebetegnelse for alle aktører som vil bruke systemet kun til å se på en turnusplan. Under her finner vi sykepleiere, leger, administratorer, overleger og oversykepleiere. En sykepleier som ønsker å se hvor mange og hvem som jobber førstkommende uke. Aktør: Beskrivelse: Eksemple: Ressursplanlegger Dette er en spesialisering av ansatt. En samlebetegnelse på de aktørene som har som ansvar å administrere turnusplanen, herunder legge til, endre og slette turnusposter i turnusplanen. Vi finner administrasjon, overleger og oversykepleiere under denne aktøren. En overlege legger til et arbeidsskift for en lege i førstkommende uke. Leveanse4.pdf 18. november 2005 Side 3

4 1.2. «Use case»-diagram Vi valgte å modellere de forskjellige oppgavene som skal utføres i et «use case»-diagram. Det er i hovedsak fire oppgaver som skal utøres; vise turnusplan, legge til en turnuspost, endre en turnuspost og slette en turnuspost. Det å kunne se turnusplanen skal alle ansatte ha tilgang til. Mens det er kun turnusplanlegger (overleger, oversykepleiere og adminstrasjonen) som skal ha mulighet for å legge til, endre og slette. Ansatt Vis turnusplan Legge til turnuspost Turnusplanlegger Endre turnuspost Slette turnuspost Leveanse4.pdf 18. november 2005 Side 4

5 1.3. «Use case»-beskrivelser Vis turnusplan Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Vis turnusplan Ansatt En ansatt ønsker å se gjeldende turnusplan. Det eksisterer en gjeldende turnusplan. Turnusplanen er vist og urørt. Normal hendelsesflyt: 1. Ansatt spesifiserer hvilken del av turnusplanen som skal vises. 2. Systemet validerer input. 3. Systemet viser ønsket del av turnusplanen. Variasjoner: 1. Ansatt skriver inn mangelfull data. a. Systemet opplyser om hva som er mangelfult. b. Ansatt retter input. 2. Ansatt spesifiserer data som er utenfor gjeldende turnuplan. a. Systemet opplyser om hva som er galt. b. Ansatt retter input. Relatert informasjon: Data som skal spesifiseres før systemet kan vise en del av turnusplanen, er; alle ansatte eller en enkelt og tidsintervall (dag, uke eller måned). Leveanse4.pdf 18. november 2005 Side 5

6 1.3.2.Legg til ny turnuspost Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Legg til ny turnuspost Turnusplanlegger En turnuspost skal opprettes. Turnusplanlegger har rettigheter til å utføre handling. En turnusplan finnes. En turnuspost er blitt opprettet. Normal hendelsesflyt: 1. Turnusplanlegger skriver inn all påkrevd turnuspost data. 2. Systemet validerer input. 3. Systemet registrere ny turnuspost 4. Systemet bekrefter at en turnuspost har blitt registrert. Variasjoner: 1. Turnusplanlegger skriver inn mangelfull data a. Systemet opplyser om hva som er galt b. Turnusplanlegger retter input. 2. Administrator skriver inn gal turnusplan data. a. Systemet opplyser om hvilke data som er ugyldige. b. Turnusplanlegger retter opp input. 3. Turnusposten finnes i systmet fra før a. Systemet opplyser om at turnusposten allerede eksisterer. b. Systemet avbryter handlingen 4. Systemet feiler i registrering av ny turnuspost. a. Turnusplanlegger opplyses om at registrering av ny turnusposten feilet. b. Systemet registrerer årsak og kontekst i en hendelseslogg. c. Systemet opplyser om årsak. d. Systemet avbryter handling. Relatert informasjon: Nødvendig informasjon om turnuspost vil si: Dato, tidspunkt, avdeling, person-id. Leveanse4.pdf 18. november 2005 Side 6

7 1.3.3.Endre turnuspost Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Endre turnuspost Turnusplanlegger En turnuspost skal endres. Turnusplanlegger har rettigheter til å utføre handlingen. En turnusplan finnes. En turnuspost er registrert i systemet. En turnuspost er endret. Normal hendelsesflyt: 1. Turnusplanlegger velger turnuspost som skal endres. 2. Turnusplanlegger endrer på ønsket data. 3. Systemet validerer den oppdaterte turnusposten. 4. Systemet utfører endringene. Variasjoner: 2. Turnusplanlegger skriver inn mangelfull data. a. Systemet gir tilbakemelding om hvilke data som mangler. b. Turnusplanlegger retter input 3. Systemet feiler i endring av turnuspost. a. Administrator opplyses om at endring av turnuspost feilet. b. Systemet registrerer årsak og kontekst i en hendelseslogg. c. Systemet opplyser om årsak. d. Systemet avbryter handling. Relatert informasjon: Nødvendig informasjon om turnuspost vil si: Dato, tidspunkt, avdeling, person-id. Leveanse4.pdf 18. november 2005 Side 7

8 1.3.4.Slett turnuspost Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Slett turnuspost Turnusplanlegger Turnusplanlegger ønsker å slette en turnuspost Turnusplanlegger har rettigheter til å utføre handling. En turnusplan finnes. En turnuspost er registrert i systemet. En turnuspost er fjernet fra systemet. Normal hendelsesflyt: 1. Turnusplanlegger velger turnuspost som skal slettes 2. Systemet ber turnusplanlegger bekrefte sletting av turnuspost 3. Turnusplanlegger bekrefter sletting 4. Systemet utfører sletting av turnuspost 5. Systemet bekrefter at handlingen er utført. Variasjoner: 1. Turnusplanlegger velger turnuspost som ikke eksisterer. a. Systemet opplyser om hva som er galt b. Turnusplanlegger retter input 2. Turnusplanlegger avbryter sletting av turnuspost a. Systemet avbryter slettingen 3. Systemet feiler under sletting av turnuspost. a. Turnusplanlegger opplyses om at sletting av turnusposten feilet. b. Systemet registrerer årsak og kontekst i en hendelseslogg. c. Systemet opplyser om årsak. d. Systemet avbryter handling. Relatert informasjon: Nødvendig informasjon om turnuspost vil si: Dato, tidspunkt, avdeling, person-id. Leveanse4.pdf 18. november 2005 Side 8

9 2. Sekvensdiagram Her er sekvensdiagrammene for de fire hovedforløpene beskrevet i kapittel 1.3. Vi har valgt å modellere kun normal hendelsesflyt Vis turnusplan Ansatt :DisplayTurnusPlanGui :HandleTurnusPlan :Turnusplan :TurnusPost getturnusplan() getturnusplan() getturnusplan() getturnuspost() liste liste liste turnuspost 2.2. Legg til turnuspost Turnusplanlegger :TurnusGui :AddTurnus :Turnusplan beginaddturnuspost() enableturnuspostscheme() addturnuspost() addturnuspost() addturnuspost() createturnuspost() :TurnusPost Leveanse4.pdf 18. november 2005 Side 9

10 2.3. Endre turnuspost Turnusplanlegger :TurnusGui :ModifyTurnusPost :Turnusplan :TurnusPost requestturnuspost() requestturnuspost() requestturnuspost() requestturnuspost() enableturnuspostscheme() turnuspost turnuspost turnuspost modifyturnuspost() modifyturnuspost() modifyturnuspost() modifyturnuspost() 2.4. Slette turnuspost Turnusplanlegger :TurnusGui :ModifyTurnusPost :Turnusplan :TurnusPost requestturnuspost() requesturnuspost() requestturnuspost() requestturnuspost() turnuspost turnuspost turnuspost enableturnuspostscheme() deleteturnuspost() deleteturnuspost deleteturnuspost deleteturnuspost Leveanse4.pdf 18. november 2005 Side 10

11 3. Klassediagram 3.1. Før implementasjon Dette er klassediagrammet som vi kom frem til i design fasen. Vi bygget da videre på klassediagrammet som vi fikk ved å la Tau UML lage et klassediagram fra den utdelte, delvis implementerte koden. Vi la så til klassene «TurnusPlan» og «TurnusPost» med det vi anså som riktig assosiasjoner. Ward OperationRoom Nurse WardRegister +numberofwards : int = 1 +changebed(ward_ : String, room_ : String, bed_ : String, +createbed(s : String[]) : +getbedlist(w : String, r : String) : String[] +removebed(ward_ : String, +hasward r : String, b : String) +displaybed(ward_ : String, room_ : String, bed_ : String) : String[] +changeroom(ward_ : String, room_ : String, +removeroom(ward_ : String, s : String) +createroom(s : String[]) : +getroomlist(s : String) : String[] +displayroom(ward_ : String, room_ : String) : String[] +changeward(ward_ : String, +removeward(ward_ : String) +createward(s : String[]) : +gettype(ward_ : String, room_ : String) : String +getward(s : String) : Ward +getwardinfo(s : String) : String[] +getwardlist() : String[] +displayward(ward_ : String) : String[] Patient -name : String +fnr : String -address : String -phone : String -status : String +$create( +compareid(fnr : String) : +removefromwaitlist() +haspatient +number : String +name : String +type : String name_ : String, type_ : String) +createroom(s : String[]) : +gettype(room_ : String) : String +removeroom(s : String) +displayroom(room_ : String) : String[] +hasroomr +changeroom(room_ : String, +changebed(room_ : String, bed_ : String, +removebed(r : String, b : String) +createbed(s : String[]) : +getbedlist(s : String) : String[] +displaybed(room_ : String, bed_ : String) : String[] +getroomlist() : String[] +giverom() +addresources(info : String) +modifyresources(info : String) +removeward(w : Ward) «interface» Serializable +numberofstaffneeded : int type_ : String, avaialble_ : String, ward_ : Ward) Room +number : String +type : String +available : String +numberofbeds : int +equipment : String[] type_ : String, available_ : String, #haswardward : Ward) +modifyroom(info : String) +displaybed(bed_ : String) : String[] +createbed(s : String[]) : +getbedlist() : String[] +removebed(b : String) +changebed(bed_ : String, #hasbed Bed +nrofbed : String +available : String +number : String +type : String #room +$create(room_ : Room) +$create@1(number_ : String, type_ : String, available_ : String, room_ : Room) +getinfo() +kindof : String +$create(name_ : String, fnr_ : String, address_ : String, phone_ : String, pager_ : String, kind_ : String) RecoveryRoom +timeinrecovery : int type_ : String, avaialble_ : String, ward_ : Ward) Object #haspatient #hasappointments +kindof : String Doctor +$create(name_ : String, fnr_ : String, address_ : String, phone_ : String, pager_ : String, kind_ : String) TurnusPlan +addturnuspost(date : Date, fnr : String) : +deleteturnuspost(turnuspostid : int) : +modifyturnuspost(turnuspostid: int) : +getturnusplanday(dato: Date) : String[] 1 PatientRegister -numberofpatient : int +locatepatient(fnr : String) +checkfnr(fnr : String) +checkout(fnr : String) +modifypatient(fnr : String) +addpatient( : +deletepatient(s : String) +changepatient( +getpatients() : String[][] +getpatientinfo(choice : String) : String[] EmployeeRegister +numberofemployee : int +addemployee(s : String[]) : +deleteemployee(s : String) +getemployees() : String[][] +getemployeeinfo(choice : String) : String[] -hasemployee +changeemployee( +locatepersonell(info : String, time : String, date : String) +compareinfo(info : String, time : String, date : String) +getoncall(type : String) +modifyemployee(id : String) Employee name : String fnr : String address : String phone : String pager : String +setschedule(time : String, date : String) +compareinfo(info : String, time : String, date : String) +assignpersonell(date : String) +removepersonell(date : String) 1 -hasemployee TurnusPost -turnuspost : int -fnr : String -shift : int -hasturnuspost +$create(turnuspost : int, date : Calendar, fnr : String, shift : int) Leveanse4.pdf 18. november 2005 Side 11

12 3.2. Etter implementasjon Da vi hadde fått implementert den nye funksjonaliteten, brukte vi igjen Tau UML for å generere et klassediagram fra den nye versjonen av HSS. Forholdet mellom dette nye klassediagrammet og det vi lagde i designfasen, er kommentert i neste kapittel. WardRegister Ward Room +numberofwards : int = 1 +changebed(ward_ : String, room_ : String, bed_ : String, +createbed(s : String[]) : +getbedlist(w : String, r : String) : String[] +removebed(ward_ : String, r : String, b : String) +displaybed(ward_ : String, room_ : String, bed_ : String) : String[] +changeroom(ward_ : String, room_ : String, +removeroom(ward_ : String, s : String) +createroom(s : String[]) : +getroomlist(s : String) : String[] +displayroom(ward_ : String, room_ : String) : String[] +changeward(ward_ : String, +removeward(ward_ : String) +createward(s : String[]) : +gettype(ward_ : String, room_ : String) : String +getward(s : String) : Ward +getwardinfo(s : String) : String[] +getwardlist() : String[] +displayward(ward_ : String) : String[] PatientRegister -numberofpatient : int +locatepatient(fnr : String) +checkfnr(fnr : String) +checkout(fnr : String) +modifypatient(fnr : String) +addpatient( : +deletepatient(s : String) +changepatient( +getpatients() : String[][] +getpatientinfo(choice : String) : String[] +haspatient +hasward +number : String +name : String +type : String name_ : String, type_ : String) +createroom(s : String[]) : +gettype(room_ : String) : String +removeroom(s : String) +displayroom(room_ : String) : String[] +changeroom(room_ : String, +changebed(room_ : String, bed_ : String, +removebed(r : String, b : String) +createbed(s : String[]) : +getbedlist(s : String) : String[] +displaybed(room_ : String, bed_ : String) : String[] +getroomlist() : String[] +giverom() +addresources(info : String) +modifyresources(info : String) +removeward(w : Ward) «interface» Serializable #hasward +hasroomr +number : String +type : String +available : String +numberofbeds : int +equipment : String[] type_ : String, available_ : String, ward : Ward) +modifyroom(info : String) +displaybed(bed_ : String) : String[] +createbed(s : String[]) : +getbedlist() : String[] +removebed(b : String) +changebed(bed_ : String, #room +nrofbed : String +available : String +number : String +type : String Bed +$create(room_ : Room) +$create@1(number_ : String, type_ : String, available_ : String, room_ : Room) +getinfo() TurnusPlan #hasbed +kindof : String Nurse +$create(name_ : String, fnr_ : String, address_ : String, phone_ : String, pager_ : String, kind_ : String) RecoveryRoom +timeinrecovery : int type_ : String, avaialble_ : String, ward_ : Ward) OperationRoom +numberofstaffneeded : int type_ : String, avaialble_ : String, ward_ : Ward) #haspatient Object +kindof : String #hasappointments Doctor +$create(name_ : String, fnr_ : String, address_ : String, phone_ : String, pager_ : String, kind_ : String) Patient -numberofturnuspost : int -name : String +fnr : String -address : String -phone : String -status : String +$create( +compareid(fnr : String) : +removefromwaitlist() Employee name : String fnr : String address : String phone : String pager : String +setschedule(time : String, date : String) +compareinfo(info : String, time : String, date : String) +assignpersonell(date : String) +removepersonell(date : String) EmployeeRegister +numberofemployee : int +addemployee(s : String[]) : +deleteemployee(s : String) -hasemployee +getemployees() : String[][] +getemployeeinfo(choice : String) : String[] +changeemployee( +locatepersonell(info : String, time : String, date : String) +compareinfo(info : String, time : String, date : String) +getoncall(type : String) +modifyemployee(id : String) -fnr : String -shift : int TurnusPost +$create(date : Calendar, fnr : String, shift : int) +addturnuspost(date : Calendar, fnr : String, shift : int) : +deleteturnuspost(turnuspostid : Object[]) : +modifyturnuspost(list : Object[], old : Object[]) +getturnusplan() : Object[][] +getturnuspost() : Object[][] +getturnuspostinfo(choice : Object[]) : Object[] -hasturnuspost -date Calendar Leveanse4.pdf 18. november 2005 Side 12

13 3.3. Forskjeller før og etter implementasjon Vi har ikke gjort så mange store forandringer i koden fra det første klassediagrammet. De klassene det har blitt gjort noen forandringer i er TurnusPost.java og TurnusPlan.java. Disse vil bli beskrevet mer detaljert under. I tillegg er objektet Calendar tatt med i det nye klassediagrammet TurnusPost-klassen Klassebeskrivelse før implementasjon: -turnuspostid:int -dato:date -fnr:string TurnusPost +$create(turnuspostid : int, dato : Date, fnr : String) Klassebeskrivelse etter implementasjon: -fnr : String -shift : int TurnusPost +$create(date : Calendar, fnr : String, shift : int) I klassen turnuspost har vi valgt å lagre en dato som et Calendarobjekt i steden for et Date objekt. I første utkaste hadde vi glemt å ta med et felt som sier hvilket skift det er snakk om. Dette er tatt med i den endelige versjon. Vi trodde vi kom til å trenge et felt for å skille turnuspostene fra hverandre, og lagde derfor en turnuspostid felt i det første utkastet. Dette viste seg å være unødvendig, og feltet har blitt fjernet TurnusPlan-klassen Klassebeskrivelse før implementasjon: TurnusPlan +addturnuspost(date : Date, fnr : String) : +deleteturnuspost(turnuspostid : int) : +modifyturnuspost(turnuspostid: int) : +getturnusplanday(dato: Date) : String[] Leveanse4.pdf 18. november 2005 Side 13

14 Klassebeskrivelse etter implementasjon: TurnusPlan -numberofturnuspost : int +addturnuspost(date : Calendar, fnr : String, shift : int) : +deleteturnuspost(turnuspostid : Object[]) : +modifyturnuspost(list : Object[], old : Object[]) +getturnusplan() : Object[][] +getturnuspost() : Object[][] +getturnuspostinfo(choice : Object[]) : Object[] Vi trodde først vi ikke trengte noen felter i turnusplan, men for å gjøre ting litt lettere opprettet vi et felt, numberofturnuspost, som angir hvor mange turnusplaner det finnes i systemet. For å følge opp den utdelte koden valgte vi å ta i mot et objekt array i steden for en turnuspostid i metodene. Vi har også lagt til noen metoder for å hente ut data på forskjellige måter. Leveanse4.pdf 18. november 2005 Side 14

15 4. Mangler i systemet 4.1. Daglig, ukentlig og månedlig turnusplanvisning I følge kravspesifikasjonen var det viktigste at systemet skulle kunne håndterer daglige, ukentlige og månedlige oversikter for hele sykehuset og de ulike avdelingene. Grunnet dårlig tid og liten prosjektgruppe har vi bare implementert en månedlig oversikt for hele sykehuset. Det er i denne oversikten ikke mulig å se hvilken avdeling den ansatte jobber ved. Dette ble avklart noe sent med arbeidsgiver da vi håpet vi skulle, med litt ekstra innsats, rekke å implementert det før tidsfristen Skiftreglement Kravspesifikasjonen sier at det skal taes hensyn til eksisterende lover og regler for hvor lenge det er lov å jobbe i et strekk uten hvile, og hvor mange timer det er lov til å jobbe totalt i løpet av en uke. Dette har heller ikke blitt implementert i koden. Det er mulig å gå inn å se på turnusplanen, og manuelt finne ut hvor mange timer en ansatt er satt opp til å jobbe. Dette er mer tungvint, men da vi så det viktigere å få lagret turnusposten og vist den, har vi sett bort i fra dette punktet. Dette vil så klart bli tatt med i neste versjon av systemet Brukervennlighet Vi har en del mindre viktige mangler og mulige feilsituasjoner i programmet som det også er ønskelig å få rettet til neste versjon. Generelt vil vi gjøre systemet mer brukervennligheten, blant annet ved å implementere en mulighet for å se vaktene til kun en ansatt og ha forskjellige detaljeringsnivå i turnusplanen for dag, uke og måned. En annen fin funksjon hadde vært å se turnusplanen mens man fyller ut en ny turnuspost, og etter at posten er ferdig utfylt Innlogging og rettigheter Det er ikke implementert noe innlogginssystem i programmet, noe som gjør at det ikke skilles på brukere, og alle har mulighet til å gjøre alt. I følge kravspesifikasjonen og use-casene skal i første omgang administrasjonen, overlege(avdelingssjef) og oversykepleier ha tilgang til ressursplanleggingen, men dette kan altså alle som har tilgang til HSS utføre Annet Av mindre mangler vi hadde et ønske om å implementere, kan det nevnes at det kun vises fødselsnummer og ikke navnet til den ansatte når man velger «change», «delete» eller «display». Feilsjekking på input er heller ikke optimalisert, og det er blant annet mulig å registrere turnusposter bak over i tid. Dette er kun mindre mangler, men ved å rette opp disse manglene ved et senere tidspunkt vil også bl.a. brukervennligheten øke. Leveanse4.pdf 18. november 2005 Side 15