LEVERANSE 2 <PROJECT HOSPITAL 2005>

Transkript

1 LEVERANSE 2 <PROJECT HOSPITAL 2005> VERSJON: LEVERANSE 2.0 Gruppe 46 - Team Innovation Leveranse 2. versjon Gruppemedlemmer: Nam Duc Pham... namdp@ifi.uio.no Tofik Sahraoui...tofiksa@ifi.uio.no Cuong van Truong...cuongvt@ifi.uio.no Tor Øyvind Fluør... torof@ifi.uio.no Dagfinn Forsaa Andersen... dagfina@ifi.uio.no Dato for ferdigstillelse: 7/0 2005

2 Innhold: Oppdragsgivers krav og tekniske konsekvenser... 3 Use case diagram... 5 Beskrivelse av aktører... 6 Beskrivelse av use case... 7 Domenemodell... 9 Beskrivelse av ikke-funksjonelle krav... 0 Klassediagram... Arkitekturdesign... 2

3 Oppdragsgivers krav og tekniske konsekvenser Spesifikasjonen er svært mangelfull for hvordan det nye Project Hospital 2005 skal forholde seg til eksisterende systemer og rutiner. Her noen av områdene som kunne vært dekket: Allokering av personell, rom og tid En sentral del av Project Hospital 2005 er å allokere personell og deres tidsbruk. Systemet vi skal designe dekker bare allokering av personell til operasjoner. Det nye systemet må derfor forholde seg til eksisterende systemer og rutiner. Vi antar at det allerede finnes system(er) som har oversikt over turnusplaner, vaktlister, ferier, møter osv. Ved registrering og endring av operasjoner må vi ha tilgang til oppdatert informasjon om en persons tilgjengelighet for en gitt periode. Project Hospital 2005 må også kunne oppdatere eller melde til andre systemer når personell allokeres og de-allokeres for operasjoner. Eventuelle endringer fra eksterne systemer må også meldes til det nye systemet. Det samme kan være tilfelle med allokering av rom hvis det finnes et system som holder orden om de enkelte rom. Det vil si åpningstider, når rom er stengt på grunn av rengjøring vedlikehold med mer. Sikkerhet Det er krav om Password security system for employees. Vi har antydet en svært enkel løsning som en del av Project Hospital Det bør undersøkes om eksisterende brukerdatabaser kan benyttes og integreres. Dette vil oss en enklere løsning, gi Health Care mindre ajourhold og enklere rutiner for brukeradministrasjon. Pasientjournal og kostnadsavregning Project Hospital 2005 generer pasienthistorikk for operasjonene. Disse dataene bør leveres videre til et pasientdokumentasjonsystem. Det beregnes også kostnader for oppholdet. Hva som skal skje videre med dette beløpet sier spesifikasjonen ingen ting om, men også her er sannsynlig at dataene bør videre til andre systemer, e.g. fakturasystem, trygdesystem.

4 Kravspesifikasjonen i forhold til Sommerville En sammenligning av Sommerville's figur The structure of a requirement document og spesifikasjonen for Project Hospital 2005: Preface Introduction Glossary User requirements definition System architecture System requirement specification System models System evolution Appendices Index Dette mangler; både målgruppe for dokumentet og versjonshistorikk. En egen introduksjon mangler, men vi kan godta kapitlene «Organisation», «Primary goals» og «Password overview» som en introduksjon. Disse kapitlene inneholder også krav ang. «User security» som ikke blir utdypet senere. Mangler. Eksempel på et begrep vi har savnet en klar definisjon på er «ward». Dette er tilsynelatende beskrevet bra. Men vi finner en del detaljer som er inkonsistente eller overflødige. F.eks. Kapittel.4.3 der input blant annet er både «meeting number» og dato. Et meeting number har en dato så å oppgi begge deler er ikke nødvendig. Det er heller ikke skilt mellom MÅ-HA og KAN-HA parametre. Spesifikasjonen burde også inneholdt beskrivelese av eksisterende regler og prosedyrer som systemet må ivareta. Eksempler på dette kan være: hvilke regler som gjelder operasjonstyper og eventuelle krav til en leges kompetanse/spesialområde. hvilke krav må være oppfylt for at en pasient kan bli operert (krav til forutgående konsultasjoner og henvisning fra allmennlege og/eller spesialist) beskrivelese av eventuelle skjema som benyttes i dag. prosedyrer for godkjenning av en operasjon. Mangler. Integrasjon mot eksisterende løsninger er ikke berørt i det hele tatt. Ikke-funksjonelle krav kunne gjerne vært ytterligere detaljert. Mangler. Ikke dekket. Av spesifikasjonen kan man tolke at systemet skal håndtere to avdelinger og skal ha tre operasjonsrom. Over tid er det ikke usansynlig at både antall operasjonsrom og avdelinger endres. Dette har vi tatt høyde for i klassediagrammet. Kapitlet «HSS vital information and attributes» kunne med fordel vært flyttet til et appendiks Ingen, ut over innholdsfortegnelsen.

5 Check in Patient include Put Patient on Waiting List extend Register Patient Receptionist extend View Patient info Modify a Patient Check Out Patient Doctor Operation Cancellation Admin View Operation list Nurses extend Schedule operation Modify Scheduled Operation include include Check Doctor Availability extend include Notify Doctors and Nurses Check Nurses Availability Check Room Availability Diagram: /corporate/inf320p46/usecases:/systemdesign/klassediagram/usercaseleggpasient.ucd: Status: working Changed: Thu Oct 06 9:0:29 W. Europe Daylight Time 2005 Page: of

6 Beskrivelse av aktører Beskrivelse Eksempler Beskrivelse Eksempler Beskrivelse Eksempler Beskrivelse Eksempler Resepsjonist. To person fra de fem administrative personene. Ansatt som resepsjonist fra rekrutterte selskaper. Ta imot bestilling, registrere ankomst og kanselleringer. Sykepleie En person som er ansatt i sykehuset. Det er i alt 30 sykepleier ved sykehuset. Hente pasient til operasjonsrom, assistere legen og pleier pasienten. Har tilgang til pasientens informasjoner og rapporter. Lege En person som er ansatt i sykehuset. Legen er spesialisert i et område og har ansvar for medisiner til pasienter. Opererer. Har tilgang til å se pasientens informasjoner og rapporter. Administrasjonen. Administrative personer som er ansatt i sykehuset. Der av 2 av dem er ansatt som resepsjonist av rekrutterte selskaper. Sette sammen en gruppe til operasjon. Har tilgang til det meste i systemet.

7 Beskrivelse av use case Use case Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Legge pasient i venteliste. Resepsjonist. en har fått beskjed om å legge inn pasienter i venteliste velger å legge pasient i venteliste. Pasient må være registrert. Pasient ligger i venteliste.. System ber om pasient id, varighet, behandling, prioritets kø. 2. oppgi nødvendige data. 3. Systemet validerer innkomne data. 4. Systemet ber aktør om godkjenning av data. 5. Pasient blir lagt i venteliste..0 Feil input data. Oppgi nødvendige data på nytt. 2.0 kansellerer ved godkjenning av data. 2. Oppgi nødvendige data på nytt. Use case Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Use case Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Operasjonskansellering. Resepsjonist, administrasjon en ønsker å avbestille operasjon. en velger å kansellere operasjon. Operasjonstimen blir kansellert.. Systemet ber om meeting number. 2. en må oppgi et meeting number. 3. Systemet validere data 4. System ber om godkjenning. 5. Operasjon blir kansellert..0 Feil input data.. Oppgi meeting number på nytt. 2.0 en kansellerer ved godkjenning av data. 2. Oppgi meeting number nr på nytt. Sette sammen en operasjon. Administrasjon. en ønsker å sette sammen en operasjon en velger å sette sammen en operasjon og at personalet og nødvendige resurser er tilgjengelige. Operasjon blir opprettet.. en oppgir tidspunkt til operasjon skal foregår. 2. Systemet gir en oversikt over tilgjengelige personal og resurser for oppgitt tidspunkt.

8 Variasjoner Relatert informasjon 3. en velger nødvendige personal og resurser til operasjonen. 4. Systemet ber aktøren om godkjenning av data. 5. Operasjonen blir opprettet..0 Feil input data.. må legge ny input data. 2.0 kansellerer ved godkjenning av data. 2. må legge ny input data. 3.0 Ingen tilgjengelig personal/resurser i den oppgitt tidspunktet. 3. må oppgi ny tidspunkt. Use case Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Vise pasient informasjon. Resepsjonist, sykepleie, lege, administrasjon. en ønsker å se pasient informasjon. en velger å se pasient informasjon. en få se pasient informasjon.. Systemet ber om pasient id eller navn. 2. en oppgir nødvendige informasjoner. 3. Systemet validerer input data. 4. en få se all informasjon til pasient..0 Pasienten ikke eksisterer i databasen.. Ber en om å oppgi ny input data. 2.0 Feil input data 2. Ber en om å oppgi ny input data. Use case Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Vise operasjonsliste. Resepsjonist, sykepleie, lege, administrasjon. en ønsker å se operasjonslisten. en velger å se operasjonslisten. en få se operasjonslisten.. Systemet ber om en dato 2. en oppgir de nødvendige informasjonene. 3. Systemet validerer input data 4. en få se operasjonslisten..0 Feil input data. en må oppgi ny input data.

9 Room roomnumber maxbed Bed bednumber Hospital Waitingroom RecoveryRoom name costprday BedCalendar StaffCalender Ward OperatingRoom name wardnr roomnumber Staff staffid name adress phonenumber pagernumber Operation meetingnumber startdatetime Nurse Doctor TreatmentType WaitingList specialization name description operationduration numberofdoctors numberofnurses recoveryduration priority indate queuenumber PatientJournal fromdate todate cost Patient patientid name address phonenumber Diagram: /corporate/inf320p46/usecases:/analysis/domenemodell/domenemodell.cad: Status: working Changed: Thu Oct 06 20:37:49 W. Europe Daylight Time 2005 Page: of

10 Beskrivelse av ikke-funksjonelle krav Systemet som helhet Det første og kanskje viktigste kravet for systemet skal være pålitelighet. Systemet skal gi pålitelig skedulering av operasjoner og det skal gi brukerne en trygghet om at de dataene som er lagret i systemet er riktige. Det er viktig at man gjør overgangen fra tidligere systemer så enkel som mulig. Dette kan gjøres ved at systemet er logisk byget opp og at kommandoene som brukes er enkle å forstå. Systemet skal være så bra at det gir brukerne økt selvtillit i arbeidet de utfører og det skal skape en trygghet på arbeidsplassen. Generelt skal det gjøre hverdagen på sykehuset enklere og mer strukturert. Brukergrensesnittet Brukergrensesnittet skal være enkelt men samtidig raskt å bruke. Det er viktig at brukerne blir raskt fortrolig med systemet. Dette kan gjøres ved å gjøre utseende og følelsen av systemet likt andre systemer de ansatte er vant med. Brukergrensesnittet skal være klart og konsist slik at brukeren aldri er i tvil om hva en funksjonalitet gjør. Det er også viktig at systemet legger til rette for avanserte brukere slik at disse kan arbeide effektivt.

11 Authenticator -userid : String -password : Password -role : String -lastlogin : DateTime +adduser() +deluser() +changeuser() +changepassword() authenticates users in Hospital +name : String +costprday : Unsigned int contains Room +roomnumber : Unsigned int #maxbed : Unsigned int +addbed() +removebed() +avaliablebeds() Waitingroom RecoveryRoom contains Bed +bednumber : Unsigned int +ChangeInfo() +DisplayInfo() Has contains has UserInterface +scheduleoperation() +check-inpatient() +check-outpatient() ReportGenerator +operationroom() +employees() +dailypatients() +patient() +bedavailability() +roomavailability() +staffdailyschedule() +staffweeklyschedule() +staffmonthlyschedule() +stafflist() +staffon-calllist() +patientlist() StaffCalender +checkifavalable() +createbooking() +removebooking() has Nurse contain Ward OperatingRoom contains +name : String +roomnumber : Unsigned int +wardnumber : Unsigned int +addstaff() +removestaff() +addroom() +removeroom() Staff #staffid : Unsigned int #name : String #adress : String #phonenumber : Unsigned int #pagernumber : Unsigned int +changeinfo() +displayinfo() PatientJournal Doctor +specialization : String +fromdate : Date +todate : Date +cost : Unsigned int Performes Assists in works in has is performed in Operation +meetingnumber : Unsigned int +startdatetime : DateTime +adddoctor() +removedoctor() +addnurse() +removenurse() has Patient -patientid : Unsigned int -name : String -address : String +displayinfo() +changeinfo() BedCalendar +checkifavalable() +createbooking() +removebooking() is of type is listed in TreatmentType +name : String +description : String +operationduration : Time +numberofdoctors : Unsigned int +numberofnurses : Unsigned int +recoveryduration : Time is of type WaitingList -priority : Int -indate : Date -queuenumber : Unsigned int -phonenumber : Unsigned int +addpatient() +removepatient() +poppatient() +displaylist() Diagram: /corporate/inf320p46/usecases:/systemdesign/klassediagram/umlklassediagram.cad: Status: working Changed: Thu Oct 06 20:35:04 W. Europe Daylight Time 2005 Page: of

12 UI Swing Domain Pasient Handling Operation Handling View infomation Technical Services Logging Persistence Security Diagram: /corporate/inf320p46/usecases:/systemdesign/klassediagram/arkitektur.ucd: Status: working Changed: Thu Oct 06 9:03:2 W. Europe Daylight Time 2005 Page: of