Thiet Ke Huong Doi Tuong

  • May 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Thiet Ke Huong Doi Tuong as PDF for free.

More details

  • Words: 5,563
  • Pages: 44
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI KHOA ĐIỆN TỬ - VIỄN THÔNG

BÁO CÁO TỔNG KẾT Đề tài:

Hệ thống quản lý bệnh nhân Giáo viên hướng dẫn : Nguyễn Huyền Trang Nhóm sinh viên thực hiện: nhóm 9 Nguyễn Trung Đức (nhóm trưởng) Nguyễn Xuân Liêm Nguyễn Viết Tùng Lớp ĐT6 – K50

Hà Nội, 5-2009

Phần một 1

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

LẬP KẾ HOẠCH 2009

Chương 1: Khởi tạo dự án I- YÊU CẦU HỆ THỐNG 1. Chủ nhiệm dự án: Nguyễn Trung Đức 2. Nhu cầu kinh doanh:  Đề xuất:



3. 



4. 

 Phòng tiếp nhận bệnh nhân  Phòng quản lý hành chính Phát sinh:  Khi số lượng bệnh nhân tăng  Công nghệ thông tin ngày càng ứng dụng rộng rãi Yêu cầu kinh doanh Hệ thống quản lý hồ sơ bệnh nhân: sơ yếu lý lịch, bệnh án, quá trình điều trị và xét nghiệm, viện phí, các phản hồi của người nhà bệnh nhân. Các chức năng của hệ thống:  Tiếp nhận bệnh nhân mới  Tìm kiếm bệnh nhân  Phân bệnh nhân vào buồng bệnh  Quản lý việc xét nghiệm, phẫu thuật,... của bệnh nhân  Sửa, xóa thông tin bệnh nhân Giá trị kinh doanh Giá trị hữu hình:  Tiết kiệm giấy tờ phim ảnh  Giảm số lượng nhân viên các phòng liên quan

 Giá trị vô hình:  Giảm thời gian chờ đợi của bệnh nhân.  Giảm tiêu cực trong bệnh viện  Giảm sai sót trong y khoa  Tra cứu thông tin sức khỏe online  Tìm kiếm bệnh nhân nhanh chóng 5. Các vấn đề đặc biệt - Thời gian hoàn thành: tháng 5-2009 - Thời gian cài đặt và huấn luyện nhân viên: 3 ngày.

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

- Việc áp dụng hệ thống quản lý vào bệnh viện là hết sức cần thiết trong giai đoạn hiện nay, giúp cải thiện chất lượng phục vụ và tăng hiệu quả điều trị bệnh nhân. 2009

II- PHÂN TÍCH TÍNH KHẢ THI 1. Khả thi về kỹ thuật  Mức độ quen thuộc với ứng dụng: mức rủi ro là cao  Các nhân viên quen với giấy tờ sổ sách, không thành thạo tin học văn phòng.  Cần thời gian đào tạo việc sử dụng phần mềm thu thập dữ liệu từ các máy đo, máy chụp.  Mức độ quen thuộc với công nghệ: mức độ rủi ro là trung bình  Dữ liệu nhập bằng máy, có khả năng phát hiện lỗi nên tin cậy hơn.  Các chuyên gia cố vấn của công ty lắp đặt hệ thống sẵn sàng hỗ trợ, tư vấn cho người quản lý bệnh viện.  Kích thước của dự án  Số người tham gia: 3 người.  Thời gian: 5 tháng  Tính tương thích với hệ thống đang tồn tại: tương thích tốt  Các dữ liệu vẫn được giữ nguyên như cũ.  Phần mềm tương đối đơn giản. 2. Khả thi về kinh tế  Chi phí phát triển hệ thống: 135 triệu đồng, bao gồm:  Chi phí phần mềm: 20 triệu đồng  Chi phí phần cứng: 100 triệu đồng  Chi phí chuyển đổi dữ liệu: 10 triệu đồng  Chi phí đào tạo: 5 triệu đồng  Chi phí vận hành: 10 triệu đồng/tháng, cụ thể:  Nâng cấp phần mềm: 2 triệu đồng  Nâng cấp phần cứng: 5 triệu đồng  Bảo trì hệ thống: 1 triệu đồng  Tiền điện tăng: 2 triệu đồng/tháng  Lợi nhuận hữu hình: 24 triệu đồng/tháng  Giảm giấy tờ phim ảnh: 20 triệu đồng/tháng

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

 Giảm 1 nhân viên phòng tiếp nhận bệnh nhân: 4 triệu đồng/tháng  Giảm 2 nhân viên phòng kế toán: 10 triệu đồng/tháng  Lợi nhuận vô hình:  chịu ko tính đc   Xác định dòng tiền mặt: 2009

33

3/2009 Lợi nhuận:

4/2009

5/2009

6/2009

7/2009

8/2009

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

30tr

35tr

40tr

45tr

14tr

14tr

14tr

14tr

44tr

49tr

54tr

59tr

38tr

40.3tr

40.29tr

39.08tr

67.75tr

105.75t r

146.05t r

186.34 tr

225.42 tr

2tr

2tr

2tr

2tr

2tr

2tr

Nâng cấp phần cứng

5tr

5tr

5tr

5tr

5tr

5tr

Bảo trì hệ thống

1tr

1tr

1tr

1tr

1tr

1tr

Tiền điện tăng

2tr

2.5tr

3tr

3.5tr

4tr

4.5tr

10tr

10.5tr

11tr

11.5tr

12tr

12.5tr

0

0

0

20tr

25tr

14tr

14tr

34tr

39tr

32.38tr

35.37tr

32.38tr

Nâng cấp phần mềm

Giảm lương nhân viên Tổng lợi nhuận PV của lợi nhuận PV của tổng lợi nhuận

2009

Giảm giấy tờ phim ảnh

Chi phí vận hành:

Tổng chi phí vận hành Chi phí phát triển hệ thống: Chi phí phần mềm Chi phí phần cứng Chi phí chuyển đổi dữ liệu Chi phí đào tạo Tổng triển

chi

phí

phát

Tổng chi phí PV của chi phí PV của tổng chi phí Tổng lợi nhuận – chi phí NPV hàng tháng NPV dồn lại

20tr

0

0

0

0

0

100tr

0

0

0

0

0

10tr

0

0

0

0

0

5tr

0

0

0

0

0

135tr

0

0

145tr

10.5tr

11tr

11.5tr

12tr

12.5tr

138tr

9.52tr

9.5tr

9.46tr

9.4tr

9.32tr

138tr

147.52tr

157.02t r

166.48t r

175.88 tr

185.2tr

28.5tr

33tr

37.5tr

42tr

47.5tr

25.85tr

28.5tr

30.85tr

32.9tr

35.44tr

(73.15tr )

(44.65t r)

(13.8tr)

19.1

54.54tr

(104tr) (99tr) (99tr)

Tỷ lệ hồi vốn

54.54/185.2 = 0.2945 = 29.45%

Điểm hòa vốn

4 + (32.9-19.1)/32.9 = 4.41 tháng

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

 Đồ thị điểm hòa vốn

250 2009

200 150

Benefits Cost

100 50 0 Mar- Apr- May- Jun- Jul- Aug09 09 09 09 09 09

3. Khả thi về tổ chức  Sự phù hợp về chiến lược phát triển:  Giảm được một số thủ tục không cần thiết, phù hợp chiến lược đơn giản hóa thủ tục hành chính.  Thúc đẩy tin học hóa trong bệnh viện.  Ảnh hưởng tới những người liên quan:  Người quản lý bệnh viện: giúp dễ dàng quản lý bệnh nhân, giảm bớt khó khăn trong công tác quản lý.  Nhân viên, bác sỹ: hạn chế tiêu cực, tham ô; đồng thời hỗ trợ trong việc khám chữa bệnh cho bệnh nhân.  Bệnh nhân: nhập viện dễ dàng, người nhà có thể kiểm tra tình trạng sức khỏe bệnh nhân qua mạng, viện phí minh bạch. 4. Lựa chọn dự án OK

III- QUYẾT ĐỊNH PHÊ DUYỆT Đã duyệt

Chương 2: Quản lý dự án 33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

I – XÁC ĐỊNH KÍCH THƯỚC DỰ ÁN 1. Tính toán số điểm chức năng

Các đầu vào:

2009

-

o Nhập từ bàn phím o

Nhập từ file có sẵn

o Chọn các mục cần nhập từ danh sách trong cơ sở dữ liệu o Tự động nhận dữ liệu từ các máy đo -

Các đầu ra: o Bệnh án bệnh nhân o Lý lịch bệnh nhân o Thông tin viện phí của bệnh nhân o Đơn thuốc bác sỹ o Các số liệu đo đạc o

-

Các số liệu thống kê về số lượng bệnh nhân

Các kiểu truy vấn (tìm kiếm) o Tìm theo tên bệnh nhân o Tìm theo khoa, phòng, giường bệnh o Tìm theo số điện thoại o Tìm theo bác sỹ điều trị o Theo ngày nhập viện và xuất viện o Theo tình trạng khi nhập viện và hồ sơ bệnh án

-

Files: có 1 file duy nhất về bệnh nhân

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

-

Giao diện chương trình: o Giao diện trên máy chủ

Miêu tả

Tổng số lượng 4 6 6 1

Thấp 2x3 4x4 2x3 0x7

2009

o Giao diện trên máy trạm

Độ phức tạp TB Cao 1x4 1x6 1x5 1x7 3x4 1x6 1 x 10 0 x 15

Tổng điểm

Inputs Outputs Queries Files Program 2 0x5 1x7 1 x 10 Interface Total Unadjusted Function Points (TUFP)

16 28 25 10 17 96

2. Tính độ phức tạp xử lý hiệu chỉnh Truyền dữ liệu Khó khăn trong việc sử dụng cấu hình Đánh giá mức độ kinh doanh Hiệu quả sử dụng cho người dùng Xử lý độ phức tạp Dễ dàng trong cài đặt Nhiều vị trí Thực thi Chức năng phân phối Nhập dữ liệu online Cập nhập trực tuyến Tái sử dụng Sự dễ dàng trong thao tác vận hành Khả năng mở rộng Tổng cộng độ phức tạp xử lý (PC)

3 0 0 0 0 0 0 0 2 0 3 1 0 0 9

 Độ phức tạp xử lý hiệu chỉnh: APC = 0.65 + (0.01 x 9) = 0.74

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

 Tổng điểm chức năng đã hiệu chỉnh: TAFP = APC x TUFP = 0.74 x 96 = 71 3. Tính số dòng lệnh, nhân lực, thời gian  Sử dụng ngôn ngữ C# và Access: Số dòng lệnh = 30 x 71 = 2130 dòng lệnh

2009

 Ước lượng nhân lực: Effort = 1.4 x 2.13 = 2.98 người/tháng ≈ 3 người/tháng  Ước lượng thời gian thực hiện dự án:* Schedule Time = 3.0 x 31/3 = 4.3 tháng

II – XÂY DỰNG VÀ QUẢN LÝ KẾ HOẠCH CÔNG VIỆC 1. Cấu trúc chia nhỏ công việc (WBS) STT 1 1.1 1.1.1 1.1.2 1.1.3 1.2 1.2.1 1.2.2 1.2.3 1.2.4 2 2.1 2.1.1 2.1.2 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 3.5

Tên công việc Lập kế hoạch Khởi tạo dự án Xác định yêu cầu Phân tích tính khả thi Quyết định phê duyệt Quản lý dự án Xác định kích thước dự án Xây dựng và quản lý kế hoạch công việc Sắp xếp nhân lực cho dự án Điều phối hoạt động của dự án Phân tích Xác định yêu cầu chi tiết Xác định yêu cầu (chi tiết) Phân tích yêu cầu Mô hình hóa chức năng Mô hình hóa cấu trúc Mô hình hóa hoạt động Thiết kế Xác định chiến lược thiết kế Thiết kế cấu trúc Thiết kế giao diện Thiết kế cơ sở dữ liệu Thiết kế chương trình

Thời gian (tuần) 6 3.5 1.5 1 1 2.5 0.5

Phụ thuộ c

1.1.1 1.1.2 1.1

Trạng thái Đang làm Xong Xong Xong Xong Đang làm Xong

0.5

1.2.1

Đang làm

0.5 1 5 4 1 1 1 1 1 4 2 2 2 2 2

1.2.2 1.2.3 1

Đang làm Đang làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm Chưa làm

2.1.1 2.1 2.1 2.1 2 3.1 3.1 3.1 3.1

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân Triển khai Xây dựng hệ thông Cài đặt hệ thống

2. Biểu đồ Grantt

2 1 1

3 4.1

Chưa làm Chưa làm Chưa làm

2009

4 4.1 4.2

3. Biểu đồ PERT

...

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

2009

...

...

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

2009

III – ĐIỀU PHỐI HOẠT ĐỘNG CỦA DỰ ÁN 1. CASE tool Tool

Phase

MS Word MS PowerPoint MS Project IBM Rational Rose MS Visual C# MS Access Stand-Alone Xpress 2

Lập kế hoạch x x x

Phân tích

Thiết kế

Triển khai

x x

x x

x x

x x

x

x

x

2. Quản lý rủi ro a) Rủi ro 1: Hệ thống được lập trình bằng C#, là một ngôn ngữ mới, các thành viên cần mất một khoảng thời gian nhất định để học. - Mức độ rủi ro: tương đối cao - Mức độ tác động lên dự án: làm tăng thời gian thực hiện dự án (khoảng 3 tháng để học C#) - Cách khắc phục: trước tiên các thành viên đã biết ngôn ngữ C# cần nhanh chón hướng dẫn cơ bản cho các thành

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

b)

viên còn lại, trong khi làm việc phát sinh nhiều vấn đề khác thì sẽ hỏi thêm. Rủi ro 2: khi làm phần mềm thu thập dữ liệu tự động từ các máy đo và máy chụp chiếu, do đó cần tìm hiểu cấu tạo các loại máy này và nguyên tắc truyền dữ liệu. Mức độ rủi ro: tương đối cao Mức độ tác động lên dự án: cần có máy để thử phần mềm, đồng thời cần thêm thời gian tìm hiểu. Cách khắc phục: có thể đến các bệnh viện lớn đã áp dụng hệ thống này để tìm hiểu thêm. Rủi ro 3: người nhà bệnh nhân vẫn chưa có kinh nghiệm với việc tra cứu nơi bệnh nhân nằm điều trị bằng phần mềm. Mức độ rủi ro: bình thường Mức độ tác động lên dự án: cần thêm thời gian làm phần hướng dẫn cho người nhà bệnh nhân. Khắc phục: trên trang web của bệnh viện cần có phần hướng dẫn chi tiết, đồng thời khi người nhà đến làm thủ tục nhập viện cũng cần có sách hướng dẫn. Rủi ro 4: việc sử dụng máy tính đối với người nhà bệnh nhân là rất khó khăn đăc biệt đối với người nhà bệnh nhân ở quê lên Mức độ rủi ro: bình thường Mức độ tác động lên dự án: làm một số chức năng của hệ thống không được sử dụng đến Khắc phục: cần có nhân viên chuyên về máy tính hỗ trợ người nhà bệnh nhân Rủi ro 5: Các nhân viên trong bệnh viện không thành thạo tin học văn phòng, cũng như phần mềm thu thập dữ liệu từ các máy đo Mức độ rủi ro: bình thường Mức độ tác động lên dự án: kéo dài thời gian của pha triển khai Khắc phục: trong quá trình thực hiện dự án cần tiến hành song song việc đào tạo tin học văn phòng và sử dụng phần mềm liên quan cho các nhân viên. 2009

c) d) e) -

-

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Phần hai PHÂN TÍCH HỆ THỐNG

2009

Chương 1: Mô hình hóa chức năng I – BIỂU ĐỒ HOẠT ĐỘNG (ACTIVE DIAGRAM) 1. Mức cao nhất

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

2009

2. Chức năng thêm mới bệnh nhân

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

3. Chức năng quản lý sửa xóa (xuất viện) 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

4. Chức năng tìm kiếm bệnh nhân 2009

5. Chức năng quản lý khám chữa bệnh

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

6. Chức năng quản lý tài chính 2009

II – BIỂU ĐỒ CA SỬ DỤNG (USECASE) 1. Các bản mô tả usecase

a) Usecase đăng nhập Tên Use Case : Đăng nhập

ID:

1

Importance high

Level:

Tác nhân chính : Người quản trị, Bác sỹ, Người nhà BN Kiểu Use Case : Cần thiết. (hoặc BN) Những người tham gia và quan tâm : Người quản trị, Người nhà BN (hoặc BN) - đăng nhập vào hệ thống để thực hiện các công việc của mình. Mô tả vắn tắt: Mô tả quá trình người quản trị, người nhà BN (hoặc BN) đăng nhập vào hệ thống Khởi sự :

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân -

Người quản trị: đăng nhập vào hệ thống và thực hiện thêm, sửa, xóa thông tin bệnh nhân: cập nhật viện phí, chế độ bảo hiểm của bệnh nhân, tình trạng bệnh nhân …và tìm kiếm bệnh nhân.

-

Người nhà BN (hoặc BN): Đăng nhập xem và tìm kiếm các thông tin về bệnh nhân, buồng nằm viện, viện phí cập nhật theo ngày.

2009

Loại: Bao hàm. Các mối quan hệ : Kết hợp (Association): Người quản trị, Người nhà BN (hoặc BN). Bao hàm (Include): Thêm mới, sửa, xóa thông tin bệnh nhân, quản lý khám chữa bệnh, quản lý tài chính, và tìm kiếm bệnh nhân. Mở rộng (Extend ): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: 1. 2. 3. 4.

Người sử dụng đăng nhập vào hệ thống. Hệ thống xác nhân tính hợp lệ của tài khoản. Người sử dụng lựa chọn công việc muốn thực hiện. Người sử dụng thoát khỏi hệ thống

Các luồng sự kiện con:

Các luồng sự kiện ngoại lệ : -

Nếu tài khoản không hợp lệ thì hệ thống yêu cầu người dùng đăng nhập lại. Thoát khỏi hệ thống.

b) Usecase thêm mới bệnh nhân Tên Use Case : Thêm Mới Bệnh Nhân Tác nhân chính : Người quản trị

ID: 2

Importance Level: high

Kiểu Use Case : Cần thiết, chi tiết

Những người tham gia và quan tâm : -

Người quản trị thêm mới bệnh nhân vào CSDL.

-

Người nhà bệnh nhân (hoặc BN) : Cung cấp thông tin cho người

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

quản trị. -

Bác sỹ: Khám sơ bộ để phân bệnh nhân vào buồng bệnh

Mô tả vắn tắt:

2009

Use case mô tả công việc nhập thông tin bệnh nhân mới vào CSDL. Khởi sự : Người quản trị nhập thông tin bệnh nhân mới, số tiền tạm ứng của BN, tình trạng nhập viện của BN và phân BN vào Buồng. Loại : Mở rộng Các mối quan hệ : Kết hợp (Association): Người quản trị, Phòng hành chính Bao hàm (Include) : Mở rộng (Extend ): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: 1. Người quản trị đăng nhập vào hệ thống.

2. Hệ thống kiểm tra tính hợp lệ của tài khoản. 3. Người quản trị thực hiện tìm thông tín về bệnh nhân (nếu là bệnh

nhân cũ) hoặc tạo bản ghi mới ( nếu là bệnh nhân mới ). 4. Nhập các luồng thông tin mới. 5. Thoát khỏi hệ thống. Các luồng sự kiện con : Các luồng sự kiện ngoại lệ : -

Nếu tài khoản không hợp lệ thì hệ thống yêu cầu người dùng đăng nhập lại.

-

Thoát khỏi hệ thống.

c) Usecase sửa xóa bệnh nhân Tên Use Case : Sửa Xóa Bệnh Nhân

ID: 3

Importance Level:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Tác nhân chính : Người quản trị Những người tham gia và quan tâm :

high Kiểu Use Case : Cần thiết, chi tiết

-

Người quản trị sửa, xóa bệnh nhân tùy vào công việc.

-

Bác sĩ quyết định thời gian bệnh nhân xuất viện.

-

Người nhà yêu cầu bệnh nhân xuất viện sớm hơn hoặc muộn hơn.

2009

- Phòng hành chính thanh toán viện phí khi bệnh nhân xuất viện Mô tả vắn tắt: Use case mô tả công việc sửa, xóa thông tin về bệnh nhân. Khởi sự : Người quản trị : • sửa đổi, cập nhật thông tin về bệnh nhân, lưu vào CSDL. • Xóa thông tin về bệnh nhân khi có yêu cầu của bệnh nhân. Loại : Mở rộng Các mối quan hệ : Kết hợp (Association): Người quản trị, Phòng tài chính Bao hàm (Include) : Mở rộng (Extend ): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: 1. Người quản trị đăng nhập vào hệ thống.

2. Hệ thống kiểm tra tính hợp lệ của tài khoản. 3. Người quản trị thực hiện cập nhât thông tín về bệnh nhân ( nếu có

sự thay đổi ) hoặc xóa bệnh nhân khỏi CSDL ( nếu đủ điều kiện xuất viện ). 4. Lưu các luồng thông tin mới. 5. Thoát khỏi hệ thống. Các luồng sự kiện con : Các luồng sự kiện ngoại lệ : -

Nếu tài khoản không hợp lệ thì hệ thống yêu cầu người dùng đăng nhập lại.

-

Thoát khỏi hệ thống. d) Usecase tìm kiếm bệnh nhân

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Tên Use Case : Tìm kiếm

ID: 4

Importance Level:

Tác nhân chính : Người quản trị,

high Kiểu Use Case : Chi tiết, nhanh

bệnh nhân, người nhà bệnh nhân,

chóng

2009

bác sỹ Những người tham gia và quan tâm : -

Người quản trị : Thực hiện tra cứu nhanh để có thể cập nhật, sửa đổi, tìm kiếm thông tin hệ thống.

-

Người nhà bệnh nhân, bệnh nhân, bác sỹ: Thực hiện tra cứu các

thông tin. Mô tả vắn tắt: Use case đưa ra các nội dung được tra cứu cho người xem. Khởi sự : Người sử dụng đăng nhập hệ thống, tiến hành chọn danh mục muốn tra cứu theo. Hệ thống sẽ trả về các thông tin có liên quan theo danh mục đã được chọn tra cứu. Loại : Mở rộng. Các mối quan hệ : Kết hợp (Association): Người quản trị, cán bộ. Bao hàm (Include:

Quản lý thông tin cá nhân, quản lý công

tác, quản lý phát triển nhân sự. Mở rộng (Extend ): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: 1. Người quản trị đăng nhập hệ thống, nhập các thông tin vào các

chức năng quản lý thông tin cá nhân, quản lý công tác, quản lý phát triển nhân sự. 2. Hệ thống tổng hợp, phân tích các thông tin. 3. Người sử dụng đăng nhập hệ thống. 4. Người sử dụng yêu cầu đưa ra các thông tin đã thống kê theo một tiêu chí nhất định 5. Hệ thống trả về các thông tin theo yêu cầu. 6. Người sử dụng thoát khỏi hệ thống. 33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Các luồng sự kiện con : Các luồng sự kiện ngoại lệ : Nếu tài khoản không hợp lệ thì hệ thống yêu cầu người dùng đăng 2009

-

nhập lại. -

Thoát khỏi hệ thống. e) Usecase quản lý khám chữa bệnh

Tên Use Case : Quản lý khám chữa bệnh Tác nhân chính : Người quản trị,

ID: 5

Importance Level:

high Kiểu Use Case : Chi tiết, cần thiết

bác sỹ Những người tham gia và quan tâm : -

Người quản trị : lưu thông tin khám chữa bệnh từ bác sỹ

-

Bác sỹ: tiến hành khám chữa bệnh, viết hồ sơ bệnh án lưu vào cơ

sở dữ liệu Mô tả vắn tắt: Use case quản lý các thông tin sau khi bệnh nhân khám chữa bệnh. Khởi sự : -

Bác sỹ: Sau khi tiến hành công tác khám chữa bệnh, kết quả mỗi lần khám sẽ được bác sỹ viết vào bệnh án điện tử, chuyển đến người quản trị.

-

Người quản trị: sắp xếp, lưu trữ thông tin.

Loại : Mở rộng. Các mối quan hệ : Kết hợp (Association): Người quản trị, bác sỹ Bao hàm (Include): Mở rộng (Extend ): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: 1. Bác sỹ đăng nhập hệ thống, viết hồ sơ bệnh án và kết quả xét

nghiệm. Một số thông tin được tự động lưu vào hệ thống. 2. Người quản trị quản lý lại các thông tin từ bác sỹ.

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Các luồng sự kiện con : Các luồng sự kiện ngoại lệ : Nếu tài khoản không hợp lệ thì hệ thống yêu cầu người dùng đăng 2009

-

nhập lại. -

Thoát khỏi hệ thống. f) Usecase quản lý tài chính

Tên Use Case : Quản lý tài chính Tác nhân chính : người quản trị

ID: 6

Importance Level: high

Kiểu Use Case : Chi tiết, cần thiết

Những người tham gia và quan tâm : Người quản lý: Theo dõi, kiểm soát tình hình tài chính của bệnh viện, các khoản phí cần đóng của bệnh nhân. - Bệnh nhân: Biết các khoản cần đóng. Mô tả vắn tắt: -

Use case mô tả tình hình tài chính, các khoản thu chi của bệnh viện. Khởi sự : Người quản lý đăng nhập hệ thống, nhập các khoản thu, các thông số cơ bản, hệ thống sẽ tổng hợp và tính toán. Loại : Mở rộng Các mối quan hệ : Kết hợp (Association): Người quản lý, phòng hành chính Bao hàm (Include) : Mở rộng (Extend ): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: 1. Người quản lý đăng nhập hệ thống. 2. Hệ thống kiểm tra tính hợp lệ của tài khoản.

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

3. Người quản lý nhập các thông số cơ bản, các khoản dựa trên các số liệu của phòng hành chính 4. Hệ thống tính toán, tổng hợp và đưa dữ liệu ra. 5. Người quản lý thoát khỏi hệ thống. Các luồng sự kiện con : 2009

Các luồng sự kiện ngoại lệ : -

Nếu tài khoản không hợp lệ thì hệ thống yêu cầu người dùng đăng nhập lại.

-

Thoát khỏi hệ thống.

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

2. Biểu đồ ca sử dụng a) Usecase hệ thống 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

b) Usecase thêm mới bệnh nhân 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

c) Usecase sửa xóa bệnh nhân 2009

III - HIỆU CHỈNH DỰ ÁN BẰNG PHƯƠNG PHÁP ĐIỂM USE CASE 1. Bảng trọng lượng tác nhân chưa hiệu chỉnh (UAWT) Loại tác nhân Đơn giản Averag e

Kết

Mô tả

Trọng số

Số lượng

Hệ thống ngoài với API dễ xác định

1

0

0

Hệ thống ngoài với giao thức cơ sở, vd HTTP, TCT/IP, hoặc cơ sở dữ liệu

2

0

0

quả

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Comple x

Human

3

4

Tổng trọng lượng tác nhân chưa hiệu chỉnh (UAW)

12 12

2009

2. Bảng trọng lượng use case chưa hiệu chỉnh Loại use case

Mô tả

Trọng lượng

Số lượng

Kết quả

Đơn giản

1 – 3 transactions

5

2

10

Trung bình

4 – 7 transactions

10

3

30

Phức tạp

> 7 transactions

15

0

Tổng trọng lượng use case chưa hiệu chỉnh (UUCW)

 Điểm usecase chưa hiệu chỉnh (UUCP)

40

= UAW + UUCW

= 40 + 12 = 52  Các yếu tố phức tạp về công nghệ

STT T1 T2 T3

T4

T5 T6 T7 T8 T9

Mô tả Hệ phân bố Thời gian đáp ứng hoặc thực thi các đối tượng Mức độ hiệu quả của người sử dụng hệ thống Độ phức tạp của quá trình xử lý trong hệ thống Khả năng tái sử dụng code Dễ cài đặt Dễ sử dụng Tính linh động Dễ thay đổi

Trọng số

Giá trị được gán

Weighte d Value

2

(0 – 5) 5

1

5

5

1

4

4

1

5

5

1

3

3

0.5 0.5 2 1

4 5 4 4

2 2.5 8 4

Notes

10

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Tính đồng thời Đòi hỏi an ninh đặc biệt Khả năng truy cập bởi

1 1 1

2 5 5

T13

thành phần thứ ba Đòi hỏi đặc biệt về đào

1

3

2 5 5 2009

T10 T11 T12

3

tạo Technical Factor Value (TFactor)

Technical Complexity Factor (TCF)

58.5

= 0.6 + (0.01 * TFactor)

= 0.6 + (0.01 * 58.5) = 1.185  Các yếu tố về môi trường

STT E1

E2 E3 E4 E5 E6 E7 E8

Trọng

Mô tả

số

Giá trị được gán(0 – 5)

Trọng

Note

lượng

s

Familiarity with system development process

1.5

2

3

being used Application experience Object-oriented experience Lead analyst capability Motivation Requirements stability Part time staff Difficulty of programming

0.5 1 0.5 1 2 -1

2 1 4 4 4 0

1 1 2 4 8 0

-1

4

-4

language

Environmental Factor Value (EFactor)

15

Environmental Factor (EF) = 1.4 + (- 0.03 * EFactor) = 1.4 + (- 0.03 * 15) = 0.95

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Adjusted Use Case Points (UCP)

= UUCP * TCF * ECF = 52 x 1.185 x 0.95 2009

= 58.539

(tổng số lượng Efactor E1 đến E6 có giá trị được gán <3) + (số lượng E7 đến E8 có giá trị được gán >3) = 4, nên lấy PHM = 28 Effort in Person Hours

= UCP * PHM = 58.539 x 28 = 1639.092

Chương 2: Mô hình hóa cấu trúc Mô tả thẻ CRC (Class Responsibility Collaboration Card): •

Người:

Front: Class name: NgườiID: 1Type: Concrete, domainDescription: Associated Use Cases: ResponsibilitiesCollaboratorsBack: Attributes: Họ và tên Ngày sinh Mã số - Giới tính Địa chỉ Quốc tịch Điện thoại - Aggregation (has-parts): - Generalization: - Other associations:

(string) (date) (string) (boolean) (string) (string) (char)Relationship:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

• Người quản trị Front: 2009

Class name: Người quản trịID: 1Type: Concrete, domainDescription: Quản lý thực hiện thêm, sửa, xóa, tìm kiếm, quản lý khám chữa bệnh của bệnh nhân, quản lý tài chính…. Associated Use Cases: Usecase hệ thống 1Responsibilities - Đăng nhập hệ thống - Thêm bệnh nhân. - Xoá, sửa bệnh nhân. - Tìm kiếm bệnh nhân. - Quản lý khám chữa bệnh. - Quản lý tài chính. Collaborators Tài khoản Hồ sơ bệnh án Hồ sơ bệnh án Hồ sơ bệnh án Hồ sơ bệnh án Hồ sơ bệnh án Back:

Attributes: Relationship:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

• Bệnh nhân Front: 2009

Class name: Phòng hành chínhID: 1Type: Concrete, domainDescription: Thực hiện thêm, sửa, xóa.Associated Use Cases: Usecase hệ thống 1Responsibilities

- Đăng nhập hệ thống - Tìm kiếm bệnh nhân Collaborators

Tài khoản Hồ sơ bệnh án Back:

Attributes:

Relationship: - Aggregation (has-parts): tài khoản - Generalization: Người - Other associations

• Người nhà bệnh nhân 33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Front: 2009

Class name: Người nhà bệnh nhân

ID: 1

Type: Concrete, domain

Description: Tìm kiếm bệnh nhân.

Associated Use Cases: Usecase hệ thống 1

Responsibilities

Collaborators

- Đăng nhập hệ thống

Tài khoản

- Tìm kiếm bệnh nhân.

Hồ sơ bệnh án

Back:

Attributes:

Relationship: - Aggregation (has-parts): tài khoản - Generalization: Người - Other associations:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Hồ sơ bệnh án



Front:

2009

Class name: hồ sơ bệnh án

ID: 1

Description:

Associated Use Cases:

Responsibilities

Type: Concrete, domain

Collaborators

Back:

Attributes: -

Ngày giờ nhập viện. Lý do nhập viện Mã số bệnh nhân Khoa Phòng bệnh Giường bệnh Bệnh sử: các triệu chứng bệnh hiện tại, diễn biến bệnh từ lúc nhập viện tới lúc khám. Tiền căn: các bệnh từng mắc trước đây Tiền viện phí tạm ứng

Relationship: - Aggregation (has-parts): - Generalization: Người - Other associations:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

• Tài khoản Front: 2009

Class name: tài khoản

ID: 1

Description:

Associated Use Cases:

Responsibilities

Type: Concrete, domain

Collaborators

Back:

Attributes: -

Tên đăng nhâp Mật khẩu

Relationship:

- Aggregation (has-parts): - Generalization: - Other associations:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

• Bác sỹ Front:

2009

Class name: bác sĩ

ID: 1

Description:

Associated Use Cases:

Responsibilities

Type: Concrete, domain

Collaborators

- Tìm kiếm

Hồ sơ bệnh án

- Quản lý khám chữa bệnh

Hồ sơ bệnh án

Back:

Attributes:

Relationship: - Aggregation (has-parts): tài khoản - Generalization:Người - Other associations:

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Sơ đồ lớp 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Sơ đồ đối tượng 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Chương 3 Mô hình hóa hoạt động 2009

Sequence Diagram: chức năng thêm mới bệnh nhân

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Collaboration diagram: chức năng thêm mới bệnh nhân 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Statemachine diagram: đối tượng TÀI KHOẢN 2009

33

Báo cáo tổng kết – Hệ thống quản lý bệnh nhân

Thiết kế lớp quản lý dữ liệu: MAPPING RDBMS 2009

33

Related Documents