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

Transkript

1 PROSJEKTGRUPPE 1 MGT SOFTWARE LEVERANSE 2 ANALYSE OG DESIGN (REVIDERT 1) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson Dato: 14. oktober 2005 Fil: Leveranse2.pdf

2 Levereanse II INNHOLDSFORTEGNELSE 1. USE CASE MODELL BESKRIVELSE AV AKTØRENE USE CASE MODELLENE Schedule Operation Wait List Report functions for the O/R Ward/Bed Functions Ward/bed reports Functions Reports Patient Functions Patient Reports Functions Reports BESKRIVELSE AV UTVALGT USE CASER DOMENEMODELL KRAV OPPDRAGGIVERS KRAV IKKE-FUNKJONELLE KRAV KLASSEDIAGRAM KOMMENTARER TIL KLASSEDIAGRAM KLASSEDIAGRAM Leveanse2.pdf Side 2

3 1. USE CASE MODELL Dette dokumentet er skrevet på norsk, men vi har valgt å beholde de engelske navnene på aktørene og use casene som er nevnt i kravspesifikasjonen Beskrivelse av aktørene Vi har valgt å dele aktørene inn i fire forskjellige aktører; Staff,, og Administrativ employees(). Staff er en samlebetegnelse på alle aktørene. Dette uttrykket blir brukt om oppgaver som alle de ansatte ved sykehuset har lov til å utføre. Aktør: Beskrivelse: Eksempler: Staff En samlebetegnelse på alle aktørene. Brukes om oppgaver som alle ved sykehuset har lov til å gjøre. Aktør: Beskrivelse: Eksempler: Utfører operasjoner. Har tilgang til å se på og skrive ut rapporter. Aktør: Beskrivelse: Eksempler: Medisinisk personell. Har tilgang til å se på og skrive ut rapporter. Aktør: Beskrivelse: Eksempler: Administrativ employees Tar seg av det administrative arbeidet ved sykehuset. Har tilgang til å gjøre alt i systemet Use case modellene Vi har valgt å ta utgangspunkt i de funksjonene som er listet opp i kravspesifikasjonen når vi har laget use casene. Vi har gitt administrativ employees tilgang til å gjøre alt i systemet, mens doctor og nurse har muligheten til å lage og se på rapporter. Leveanse2.pdf Side 3

4 Schedule Operation Assign doctor to operation Schedule patient to Operation room Remove doctor from operation Modify previously scheduled operation Assign staff to operation Assign nurse to operation Operation Cancellation Remove nurse from operation Assign nurse to ward Leveanse2.pdf Side 4

5 Wait List Assign Patient to Wait List Remove Patient from Wait List Modify Wait List Information View Wait List Information View Patient Wait List Information Report functions for the O/R Create report for operation rooms Create report for employees Create report for daily patients Create report for patient Leveanse2.pdf Side 5

6 Ward/Bed Functions Add a bed Delete bed Change bed info Display bed info Ward/bed reports View Bed Availability Raport for Ward View Bed Availability Report for Entire Hostpital Staff View Room Type Availability for Ward View Room Type Availability for Entire Hospital Leveanse2.pdf Side 6

7 Functions Add a nurse Delete a nurse Change nurse info Display nurse info Reports View daily schedule report View weekly schedule report Staff View monthly schedule report View nurse list report View on-call list report Leveanse2.pdf Side 7

8 Patient Functions Add a Patient Modify a Patient Check-in a Patient Check-out a Patient Display Patient Information View Patient Schedule Patient Reports Staff View patient list Leveanse2.pdf Side 8

9 Functions Add doctor Delete doctor Modify doctor information Display doctor information Reports View Listing View Daily Schedule Staff View Weekly Schedule View Monthly Schedule View 's Patient Listing Leveanse2.pdf Side 9

10 1.3. Beskrivelse av utvalgt use caser Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Normal hendelsesflyt: Variasjoner: Relatert informasjon: Remove Patient from Wait List Pasient skal fjernes fra ventelisten. har rettigheter til å utføre handling. Pasient er registrert i systemet. Pasient er registrert på ventelisten. Pasient er fjernet fra venteliste. 1. fyller inn all påkrevd pasientdata. 2. Systemet validerer input. 3. Systemet ber administrator bekrefte sletting av pasient fra ventelisten. 4. bekrefter sletting av pasient fra venteliste. 5. Systemet utfører fjerning av pasient fra venteliste. 6. Systemet bekrefter at handling er utført. 1. skriver inn mangelfull pasient data. a. Systemet opplyser om hva som er mangelfult. b. retter input. 2. skriver inn pasientdata som ikke finnes i systemet. a. Systemet opplyser om at oppgitt data ikke finnes i systemet. b. retter input. 3. avbryter sletting av bruker. a. Systemet avbryter sletting av pasient fra venteliste. 4. Systemet feiler i fjerning av pasient fra venteliste. a. opplyses om at fjerning av pasient feilet. b. Systemet registrerer årsak og kontekst i en hendelseslogg. c. Systemet opplyser om årsak. d. Systemet avbryter handling. Påkrevd pasientdata: pasient ID og queue number Leveanse2.pdf Side 10

11 Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Normal hendelsesflyt: Variasjoner: Relatert informasjon: Add a Patient Pasient skal registreres i systemet. har rettigheter til å utføre handlingen. Pasient finnes ikke i systemet fra før. Pasient er registrert i systemet. Pasient har fått en unik pasient id. 1. fyller inn all påkrevd pasientdata. 2. Systemet validerer input. 3. Systemet registrerer ny pasient. 4. Systemet bekrefter at en pasient har blitt registrert. 1. skriver inn mangelfull pasient data. a. Systemet opplyser om hva som er mangelfullt. b. retter input. 2. skriver inn gal pasient data. a. Systemet opplyser om hva som er galt. b. retter input. 3. Pasienten finnes i systemet fra før a. opplyses om at pasienten allerede eksiterer b. Systemet avbryter handlingen. 4. Systemet feiler i registrering av pasient. a. opplyses om at registrering av pasient feilet. b. Systemet registrerer årsak og kontekst i en hendelseslogg. c. Systemet opplyser om årsak. d. Systemet avbryter handling. Pasientdata består av: navn, adresse, telefonnr og sykehistorie. Leveanse2.pdf Side 11

12 Use Case: Aktør: Trigger: Pre-betingelser: Post-betingelser: Normal hendelsesflyt: Create report for operation rooms ønsker å se en rapport for et operasjonsrom innenfor et gitt tidsrom. Adminstrator har rettigheter til å utføre handlingen. har et romnr, en startdato og evt. en sluttdato. Angis bare en startdato vil det bli generert en rapport for kun den dagen. Med både start og sluttdato: En rapport over operasjoner som skal utføres i operasjonsrommet er generert. Med bare startdato: En dagsrapport som i tillegg inneholder pasient navn og id, doktor navn og id, sykepleiers navn og id, type operasjon og lengden på operasjonen er generert. 1. skriver inn all påkrevd data. 2. Systemet validerer innkommende data. 3. Systemet svarer til administrator med resultatet. Variasjoner: Relatert informasjon: 1. skriver inn mangelfull data. a. Systemet opplyser om hva som er mangelfult. b. retter input. 2. skriver inn gal data. a. Systemet opplyser om hva som er galt. b. retter input. 3. skriver inn et rommnummer som ikke eksisterer eller som ikke er et operasjonsrom: a. Systemet opplyser om at et ikke eksisterende romnummer er oppgitt eller at gal type rom er forsøkt oppført som operasjonsrom. b. Systemet gir administrator en ny mulighet til å fylle inn romnummer. Påkrevd data: romnummer og startdato. Gal data vil si sluttdato er før startdato, eller/og dato finnes ikke. Leveanse2.pdf Side 12

13 Use case: Aktør: Trigger: Pre-betingelser: Postbetingelser: Normal hendelsesflyt: Variasjoner: Delete a doctor ønsker å slette en doktor. har rettigheter til å utføre handlingen. Det finnes en doktor som skal slettes fra systemet. Doktoren er slettet fra systemet. En annen doktor har overtatt oppgavene til den slettede doktoren. 1. skriver inn id-nummeret til doktoren som skal slettes. 2. skriver inn id-nummeret til doktoren som skal overta posisjonen. 3. Systemet ber administrator bekrefte sletting av doktor. 4. bekrefter sletting av doktor. 5. Systemet utfører sletting av doktor 6. Systemet bekrefter at handling er utført. 1. prøver å slette id-nummeret til en doktor som ikke eksisterer a. Systemet opplyser om hva som er galt b. retter input 2. prøver å erstatte en doktor med et id-nummer som ikke eksisterer a. Systemet opplyser om hva som er galt. b. retter input 3. avbryter sletting av doktor. a. Systemet avbryter sletting av doktor. 4. Systemet feiler ved sletting av doktor. a. opplyses om at sletting av doktor feilet. b. Systemet registrerer årsak og kontekst i en hendelseslogg. c. Systemet opplyser om årsak. d. Systemet avbryter handling. Leveanse2.pdf Side 13

14 Use case: Aktør: Trigger: Pre-betingelser: Postbetingelser: Normal hendelsesflyt: Variasjoner: Relatert informasjon: Display doctor information Staff Staff ønsker å vise informasjon om en doktor. Staff har rettigheter til å utføre handlingen. Staff har en id eller et navn på en doktor. Informasjon om en doktor har blitt vist. 1. Staff fyller inn all påkrevd doktordata. 2. Systemet validerer input. 3. Systemet viser doktor informasjon. 1. Staff skriver inn mangelfull data. a. Systemet opplyser om hva som er mangelfult. b. Staff retter input. 2. Staff skriver inn gal data. a. Systemet opplyser om hva som er galt. b. Staff retter input. Påkrevd data: doktor id eller doktor navn. Leveanse2.pdf Side 14

15 2. DOMENEMODELL Leveanse2.pdf Side 15

16 3. KRAV 3.1. Oppdraggivers krav Oppdragsgiveren har som krav at systemet skal være enkelt, konsistent, og gi brukeren kort vei til målet. Ut i fra disse kravene om enkelhet og kort vei til målet er vi derfor nødt til å begrense hvem som får tilgang til hva, slik at vi ikke gir bruker en haug med muligheter som aldri benyttes og bare ligger i veien. Fjerner vi unødvendigheter innfører vi også enkelhet. Det er også et godt poeng å ikke gi unødvendige rettigheter slik at brukere uten den nødvendige opplæringen kan gå inn og endre på informasjon. Om vi i tillegg har et konsistent menysystem vil dette gjøre innlæringsperioden kortere, og på denne måten fremme et enkelt og lettvint system, med lave krav til opplæring for flertallet av arbeiderne. Høyere krav til opplæring setter vi dermed over til den minste gruppen, som består av administrasjonen. Disse vil derfor også få tildelt høyest mulig tilgangsnivå. Vi skal prøve så godt vi kan på å opprettholde kravet om maksimum menydybde på 3 nivåer, men det kan hende at dette kravet vil utgå på mindre brukte funksjoner hos administrator, siden det er administrator som sitter med høyest tilgangsnivå. Kravet om støtte for mus, samt familiære omgivelser som flertallet er kjent med ser vi på som en selvfølge om ikke annet er ønsket Ikke-funkjonelle krav Det er mange brukere med ulike datakunnskaper som skal bruke systemet. Det er derfor viktig at brukergrensesnittet er oversiktlig og enkelt å bruke. Systemet skal være menybasert, men siden det også skal brukes av mer erfarne brukere skal det finnes hurtigtaster til de mest vanlige funksjonene. Menyene skal ikke ha en menydybde som er dypere enn 3 for å unngå å bruke tid på å lete fram. Systemet består av to hovedfunksjonaliteter, en som tar for seg planleggingen og en supportdatabase som inneholder informasjon om pasienter, leger, sykepleiere, avdelinger og operasjonsrom. Den første funksjonaliteten vil bli mest brukt, og brukerne skal derfor ha direkte tilgang til disse fra hovedmenyen. Det skal være mulig for systemet å generere alle slags rapporter som er nødvendige for sykehuset, men det skal i tillegg finnes en del standardrapporter som er forhåndsbestemte i systemet. Siden den daglige driften av sykehuset vil avhenge mye av systemet er det viktig at HSS er stabilt og driftsikkert. Mye av dataen i systemet vil være nødvendig for driften av sykehuset. Hvis systemet er nede må de ansatte ha tilgang til backup så operasjoner og andre viktige oppgaver kan gå som planlagt. I første omgang vil vi ikke implementer dette i vår løsning, men legge til rette for at det kan komme et ønske om det i en senere løsning. Her vil det være naturlig å gå i videre dialog med oppdagsgiver, men intill da lar vi det ligge. Systemet vil bli brukt daglig av mange brukere. Det er derfor viktig med god ytelse for å unngå lang ventetid og for å sikre tilgang til riktig data. Leveanse2.pdf Side 16

17 4. KLASSEDIAGRAM 4.1. Kommentarer til klassediagram Siden det er flere sykepleiere og leger som kan delta på en operasjon, har vi laget to egne klasser for å håndtere dette. For rom har vi valgt å ha en parameter som angir hvilken type rom det er snakk om, venterom, rehabiliteringsrom eller operasjonsrom. For operasjonsrom har vi valgt å lage en spesialisering, siden denne har noen andre metoder enn de andre rommene. Et sykehus har en venteliste og derfor er denne knyttet til sykehuset og ikke til f.eks en avdeling. På denne listen er det mange poster som inneholder pasientinformasjon i tillegg til varighet, behandlingstype og prioritetsnummer. Vi synes dette virket mest hensynsmessig da en pasient kan stå på flere ventelister for ulike behandlinger. Vi har valgt å la en pasient tilhøre et rom, og på dette rommet finnes det senger som pasienten kan bruke. Dette er gjort fordi en pasient først kan ligge på et venterom, så et operasjonsrom og til slutt et rehabiliteringsrom. I kravspesifikasjonen er det nevnt et meetingnumber for å identifisere en operasjon. Vi har valgt å kalle denne variablene for operasjonsid, da vi fant dette navnet mer beskrivende enn meetingnumber. Alle andre variabler som brukes til å identifisere klasene har fått navn som slutter på Id, som for eksempel romid, sykepleierid osv. Leveanse2.pdf Side 17

18 4.2. Klassediagram 1..* har Ansatt -navn:string -adresse:string -tlfnr:string -personsokernr:string +visansatttimeplan():void 1 er ansatt ved Seng -avdelingsidr:int -romid:int -sengid:int -Ledig:bool +leggtilseng():boolean +slettseng():boolean +endreseng():boolean +visseng():void 0..* 1 harstår i Sykehus -navn:string -adresse: string -orgnr:string -tlfnr:string +visledigesenger():void +visromtypeledighet():void 1 1..* tilhører består av Avdeling -avdelingsid:int -type: string -rom:list +leggtilsykepleier():boolean +visledigesenger():void +visromtypeledighet():void 1 1..* Rom tilhører -romid:int -type:string består av Operasjonsrom +visromtimeplan():void +visdagensoperasjoner():void 1 ligger i 1 1 tilhører har 1 tilhører Venteliste +visventliste():list 1 tilhører 0..* består av 0..* har VentelistPost -administratorid:int -pasientid:int -varighet:time -behandlingstype:string -prioritetsnr:int +endrepost():boolean 0..* 1 har tilhører Pasient -pasientid:int -navn:string -adresse:string -tlfnr:string -sykehistorie:string +leggtilpasient():boolean +endrepasient():boolean +sjekkinnpasient():boolean +sjekkutpasient():boolean +leggtilventeliste():boolean +slettfraventeliste():boolean +visventelisteposter():list +vispasient():void +vispasienttimeplan():void +visalle():void 0..* har 1 har Sykepleier -sykepleierid:int +leggtilsykepleier():boolean +slettsykepleier():boolean +endresykepleier():boolean +vissykepleier():void +vissykepleierdag():void +vissykepleieruke():void +vissykepleiermnd():void +visalle():void +visvaktliste():void SykpleierOperasjon 0..* tilhører 1 har 0..* tilhører 0..* 1 tilhører har Operasjon 1..* -operasjonsid:int -romid:int -dato:date -varighet:time -rehabiliteringsdato:date -rehabiliteringstid:time -behandlingstype:string -pasientnr:int -doktorid:int +leggtilpasient():boolean +endreoperasjon():boolean +slettoperasjon():boolean +leggtildoktor():boolean +slettdoktor():boolean +leggtilsykepleier():boolean +slettsykepleier():boolean Doktor +leggtildoktor():boolean +slettdoktor():boolean +endredoktor():boolean +visdoktor():void +visdoktordag():void +visdoktoruke():void +visdoktormnd():void +visalle():void +visvaktliste():void +vispasientliste():void 1 1..* 1 tilhører har DoktorOperasjon tilhører har Leveanse2.pdf Side 18