Bối cảnh và vấn đề nghiên cứu
Đồ án này được thực hiện trong khuôn khổ môn học Phân Tích Kinh Doanh tại Khoa Hệ Thống Thông Tin Quản Lý, Trường Đại học Ngân hàng TP. Hồ Chí Minh, hoàn thành vào tháng 10 năm 2023. Nhóm thực hiện gồm bảy thành viên thuộc lớp DI4, dưới sự hướng dẫn của NCS. Nguyễn Thị Thu Hà.
Vấn đề thực tiễn: Hệ thống quản lý ký túc xá (KTX) hiện tại tại đơn vị khảo sát vận hành hoàn toàn thủ công. Sinh viên phải đến trực tiếp phòng quản lý để đăng ký phòng, gia hạn hợp đồng, báo sự cố hư hỏng tài sản, và thay đổi thông tin cá nhân. Ban quản lý gặp khó khăn trong việc tiếp nhận, đồng bộ thông tin giữa các bộ phận; khi một bộ phận bỏ lỡ thông tin từ bộ phận khác sẽ gây sai sót trong quản lý phòng và khách hàng. Việc quản lý số lượng dân cư lớn theo phương thức giấy tờ dẫn đến nguy cơ mất mát và khó tra cứu.
Mục tiêu đồ án:
- Phân tích yêu cầu nghiệp vụ của hệ thống thông tin quản lý KTX thông qua các hoạt động gợi mở (phỏng vấn, khảo sát).
- Xác định đầy đủ các yêu cầu chức năng, phi chức năng và tích hợp.
- Thiết kế mô hình dữ liệu (ERD), sơ đồ dòng dữ liệu (DFD), sơ đồ phân rã chức năng, và đặc tả Use Case.
- Xây dựng giao diện người dùng (UI) minh họa cho hai nhóm người dùng: Ban quản lý và Sinh viên.
Đối tượng nghiên cứu: Hệ thống thông tin quản lý ký túc xá tại Trường Đại học Ngân hàng TP. HCM, bao gồm hai nhóm người dùng chính là Ban quản lý KTX và sinh viên đang cư trú.
Phạm vi: Phân tích và thiết kế các module quản lý phòng, quản lý thông tin sinh viên, quản lý tài sản, quản lý hợp đồng thuê, và quản lý thanh toán. Thời gian thực hiện từ tháng 9 đến tháng 10 năm 2023. Sản phẩm chuyển giao là tài liệu đặc tả yêu cầu (SRS) và bản thiết kế giao diện.
Cơ sở lý thuyết và phương pháp
Khung lý thuyết và mô hình tiếp cận
Nhóm áp dụng hướng tiếp cận Change-Driven (hướng thay đổi) làm nền tảng cho toàn bộ quá trình phân tích kinh doanh. Trong đó, mô hình Agile — cụ thể là khung Scrum — được lựa chọn làm phương pháp quản lý dự án. Các khái niệm cốt lõi của Scrum được vận dụng gồm: Sprint (chu kỳ phát triển từ 1–4 tuần), Product Backlog, Sprint Backlog, Scrum Master và Product Owner. Các cuộc họp định kỳ như Daily Scrum, Sprint Planning, Sprint Review và Sprint Retrospective được đề cập như cơ chế duy trì hiệu quả nhóm.
Để ưu tiên yêu cầu, nhóm áp dụng phương pháp MoSCoW với bốn mức: Must have → Should have → Could have → Won't have, từ đó xác định thứ tự triển khai các tính năng theo mức độ thiết yếu với người dùng.
Các bên liên quan được xác định và quản lý thông qua ma trận RACI (Responsible – Accountable – Consulted – Informed), bao gồm: User (Ban quản lý KTX, Sinh viên), Business Analyst, Developer, UI/UX Designer, Tester, Product Manager, Information Assurance (chuyên gia bảo mật và cơ sở dữ liệu), Technical Lead, và Chuyên gia vận hành hệ thống.
Phương pháp thu thập và phân tích yêu cầu
Nhóm sử dụng kết hợp hai kỹ thuật gợi mở chính:
- Phỏng vấn 1-1 và phỏng vấn nhóm: Thực hiện với Ban quản lý KTX (tại Phòng họp A, ngày 20/09–25/09) và nhóm sinh viên đã từng ở KTX (tại khu tự học KTX, ngày 25/09–30/09). Công cụ: điện thoại, laptop, ghi âm, file ghi chú.
- Khảo sát bảng hỏi (Form khảo sát): Gửi đến Ban quản lý (ba người gồm Giám đốc, Bộ phận kế toán, Bộ phận kỹ thuật) và nhóm sinh viên cư trú.
Kết quả được tổng hợp thành bảng tổng hợp yêu cầu, biên bản phỏng vấn, và bảng đặc tả Use Case.
Nguồn dữ liệu
Dữ liệu sơ cấp thu thập từ phỏng vấn và khảo sát trực tiếp các bên liên quan. Không có dữ liệu thứ cấp từ nguồn bên ngoài được trích dẫn trong văn bản.
Nội dung chính theo từng chương
Chương 1: Hướng tiếp cận phân tích kinh doanh, kế hoạch và giám sát phân tích kinh doanh
Chương này trình bày nền tảng phương pháp luận. Mô hình Agile/Scrum được lý giải như khung quản lý dự án linh hoạt, cho phép chia nhỏ dự án thành các sprint ngắn, tập trung sản xuất từng phần của sản phẩm. Quy trình quản lý thay đổi theo hướng Change-Driven được mô tả qua tám bước: Thu thập yêu cầu ban đầu → Xác định và ưu tiên yêu cầu → Đánh giá yêu cầu → Phê duyệt → Thực hiện và kiểm tra → Thu thập phản hồi → Theo dõi và tối ưu hóa → Lặp lại quy trình.
Ma trận RACI được xây dựng cho sáu giai đoạn dự án: (1) Lập kế hoạch và phân tích yêu cầu, (2) Thiết kế hệ thống, (3) Phát triển và kiểm thử, (4) Triển khai, (5) Vận hành và bảo trì, (6) Đánh giá và cải tiến.
Kế hoạch hoạt động phân tích kinh doanh được chi tiết hóa kèm ước lượng chi phí nhân lực. Mức lương tham chiếu theo giờ (đơn vị VND, quy đổi 1 USD = 24.000 VND) được xác định cho từng vai trò:
| Vai trò |
Đơn giá (VND/giờ) |
| Business Analyst (BA) |
150.000 |
| Project Manager (PM) |
300.000 |
| Personal Assistant (PA) |
100.000 |
| Product Owner (PO) |
250.000 |
| Technical Analyst (TA) |
150.000 |
| Tester |
150.000 |
| UX/UI Designer |
200.000 |
| Developer (DEV) |
250.000 |
| Chuyên gia bảo mật |
250.000 |
Kế hoạch truyền thông với các bên liên quan quy định tần suất liên lạc: Sinh viên và Ban quản lý gặp trực tiếp 2 lần/tháng; Business Analyst trao đổi 5 lần/tuần; Developer hàng ngày; Tester liên tục suốt dự án; Technical Lead 2 lần/tuần.
Chương 2: Hoạt động gợi mở
Chương ghi nhận toàn bộ quá trình thu thập yêu cầu từ các bên liên quan.
Kết quả phỏng vấn Ban quản lý làm rõ các nhu cầu cụ thể: quản lý hồ sơ khách hàng thuê (mã phòng, loại phòng, trạng thái, danh sách người ở, giá phòng); chức năng lọc và tìm kiếm trong mọi module; tải file Excel thông tin điện nước lên hệ thống; lưu trữ thông tin thời hạn bảo hành tài sản; quy trình thanh toán gồm thu tiền phòng đầu học kỳ và lập hóa đơn điện nước hàng tháng; cơ chế báo sự cố hư hỏng từ sinh viên đến bộ phận phụ trách.
Kết quả khảo sát Ban quản lý (3 người: Giám đốc, Bộ phận kế toán, Bộ phận kỹ thuật) cho thấy:
- 100% đồng ý cần tính năng lọc danh sách phòng theo tầng.
- 100% đánh giá "Rất cần thiết" tính năng tải file và xem/sửa thông tin điện nước.
- 100% đồng ý cần quản lý thông tin tổng thanh toán và quản lý tài sản trên hệ thống.
- 100% xác nhận thông tin sinh viên do Ban quản lý cập nhật (không phải sinh viên tự cập nhật toàn bộ).
- 75% cho rằng hợp đồng hết hạn sẽ lưu trữ trên hệ thống.
Kết quả khảo sát Sinh viên (mẫu khảo sát mở rộng) ghi nhận:
- 70% chưa hài lòng với phòng ở hiện tại.
- 40% không hài lòng với hệ thống quản lý KTX hiện tại.
- 80% muốn thêm chức năng thanh toán thông qua hệ thống, trong đó có ý kiến đề xuất liên kết ngân hàng và ví điện tử MoMo.
- 80% muốn hóa đơn hàng tháng được lưu trữ trên hệ thống.
- 90% muốn hợp đồng được lưu trữ trên hệ thống.
Chương 3: Phân tích yêu cầu
Yêu cầu chức năng được phân chia theo hai nhóm người dùng:
Ban quản lý: Quản lý tài khoản (cấp tài khoản, đăng nhập/xuất/đổi/lấy lại mật khẩu); quản lý thông tin sinh viên (xem, tìm kiếm, tải lên/thêm/cập nhật/xóa); quản lý phòng (xem, tìm kiếm, thêm thông tin, tự động cập nhật trạng thái, nhận khiếu nại); quản lý tài sản (xem, tìm kiếm, import/thêm/cập nhật, nhận thông báo tài sản sắp hết hạn bảo trì); quản lý hợp đồng (import, thông báo sắp hết hạn, gia hạn, xem, tìm kiếm, hủy); quản lý thanh toán (import thông tin điện nước, tự động tính tổng tiền điện + nước + tiền phòng hàng tháng, xem trạng thái thanh toán).
Sinh viên: Quản lý thông tin cá nhân (xem, cập nhật một số trường); quản lý tài sản (xem danh sách, khiếu nại hư hỏng); quản lý hợp đồng (xem, yêu cầu hủy); quản lý thanh toán (xem công nợ, xem chi tiết, khiếu nại, liên kết ngân hàng, thanh toán chuyển khoản).
Yêu cầu phi chức năng bao gồm: cung cấp tài liệu hướng dẫn (bản in và trực tuyến); hệ thống có thể bảo trì trong thời gian ngắn trong khi vẫn hoạt động; tự động sao lưu khi sự cố; kiểm tra hiệu suất xử lý tải lớn; tương thích đa nền tảng và trình duyệt.
Yêu cầu tích hợp: Tích hợp cổng thanh toán (liên kết ngân hàng); xác thực thanh toán qua SMS; tích hợp với trang web và ứng dụng di động; tích hợp dịch vụ email và thông báo.
Chương trình bày User Story chi tiết cho từng chức năng và bảng đặc tả Use Case với mã định danh hệ thống (ví dụ: ADLOGIN.1, ADROOM.1–6, ADPAY.1–5, ADPROPERT Y1.1–Y4.2, ADINFOR.1–4, ADCONTRAC.T1–T5 cho Ban quản lý; USLOGIN.1, USPROPERTY.1–2, USPAY.1–5, USCONTRACT.T1, USINFOR.1–2 cho Sinh viên). Hai Use Case được đặc tả chi tiết gồm: Đăng nhập (ADLOGIN.1/USLOGIN.1) và Cập nhật thông tin điện nước (ADPAY.3), bao gồm đầy đủ Basic Flow, Alternative Flow, Exception Flow, Business Rules và Non-Functional Requirement.
Đáng chú ý, Use Case Đăng nhập quy định: người dùng nhập sai thông tin 3 lần liên tiếp sẽ bị khóa tài khoản 30 phút; timeout màn hình đăng nhập là 2 phút. Use Case Lấy lại mật khẩu quy định: OTP có hiệu lực 60 giây; nhập sai OTP 3 lần liên tiếp sẽ bị khóa tài khoản 15 phút.
Sơ đồ phân rã chức năng mô tả cây phân cấp chức năng hệ thống cho cả hai nhóm người dùng, làm rõ phạm vi từng module.
Chương 4: Lược đồ quan hệ thực thể ERD và Sơ đồ dòng dữ liệu DFD
Chương trình bày ERD (Entity Relationship Diagram) với mục đích mô tả các thực thể, thuộc tính và mối quan hệ giữa chúng nhằm cung cấp ngữ nghĩa chung cho phân tích và triển khai. Các thực thể được nhận diện từ các nghiệp vụ cốt lõi.
DFD (Data Flow Diagrams) được xây dựng cho bốn luồng nghiệp vụ chính: Quản lý hợp đồng, Quản lý thông tin sinh viên, Quản lý tài sản phòng, và Quản lý thanh toán phòng.
Chương 5–6: Thiết kế và triển khai giao diện người dùng
(Xem mục "Thiết kế và triển khai" bên dưới)
Thiết kế và triển khai
Kiến trúc giao diện
Hệ thống được thiết kế với hai phân hệ giao diện độc lập: giao diện Ban quản lý và giao diện Sinh viên, đều có màn hình đăng nhập chung với lựa chọn vai trò.
Giao diện Ban quản lý bao gồm sáu module chính truy cập từ màn hình Home (HOMEAD.1):
| Module |
Màn hình chính |
Chức năng nổi bật |
| Quản lý phòng |
ROOMAD.1–3 |
Xem danh sách, xem chi tiết người ở và tài sản, chỉnh sửa thông tin, điều chỉnh giá đồng loạt |
| Quản lý thông tin sinh viên |
INFORAD.1–2 |
Xem, thêm mới, chỉnh sửa, xóa thông tin khách hàng |
| Quản lý thanh toán |
PAYAD.1–8 |
Tải file điện nước (xlsx), xem trước dữ liệu, xem chi tiết từng phòng, xem tiền phòng theo hợp đồng, xem tổng thanh toán, lọc theo tầng/phòng/tháng/trạng thái |
| Quản lý tài sản |
PROPERTYAD.1–6 |
Xem tài sản bố trí (theo mã phòng), tài sản dự trù, tài sản hư hỏng, tài sản sắp/đã hết hạn bảo hành; bố trí và thêm mới tài sản |
| Quản lý hợp đồng |
CONTRACTAD.1–5 |
Cập nhật nhiều hợp đồng qua file (xlsx), thêm thủ công từng hợp đồng, xem chi tiết, xem hợp đồng điện tử |
| Tài khoản |
— |
Đăng nhập, quên mật khẩu (xác thực SĐT + OTP) |
Giao diện Sinh viên (tên minh họa: Võ Thị Bảo Xuyên, mã SV 030237210220) bao gồm bốn module:
| Module |
Màn hình |
Chức năng |
| Thông tin cá nhân |
USINFOR |
Xem, cập nhật SĐT và email |
| Quản lý tài sản |
PROPERTYUS.1 |
Xem danh sách tài sản phòng kèm hạn bảo hành |
| Quản lý hợp đồng |
CONTRACTUS.1 |
Xem hợp đồng điện tử |
| Quản lý thanh toán |
PAYUS.1–7 |
Xem công nợ, xem hóa đơn chi tiết (phòng + điện nước + dịch vụ khác), lịch sử thanh toán, liên kết ngân hàng (MB, VCB, TPBank, Techcombank...), thanh toán chuyển khoản với xác thực OTP |
Luồng thanh toán
Luồng thanh toán của sinh viên được thiết kế chi tiết qua bảy màn hình (PAYUS.1 → PAYUS.7): xem công nợ → xem hóa đơn chi tiết → chọn ngân hàng → xác thực OTP (hiệu lực 10 giây) → màn hình thanh toán thành công (hiển thị mã giao dịch, thời gian, tổng tiền và người nhận).
Kết quả và đóng góp
Kết quả chính:
- Bộ tài liệu đặc tả yêu cầu (SRS) đầy đủ cho hệ thống quản lý KTX, bao gồm yêu cầu chức năng, phi chức năng và tích hợp.
- Ma trận RACI phân công rõ ràng trách nhiệm cho tám vai trò qua sáu giai đoạn vòng đời dự án.
- Ước lượng chi phí nhân lực chi tiết theo từng giai đoạn, từng công việc và từng vai trò.
- Đặc tả Use Case cho hai nhóm người dùng với tổng cộng hơn 30 Use Case được mã hóa.
- Bản thiết kế giao diện minh họa gồm hơn 30 màn hình với mô tả luồng điều hướng (navigation flow) đầy đủ.
Giải pháp đề xuất:
- Số hóa toàn bộ quy trình quản lý KTX từ đăng ký phòng, gia hạn hợp đồng, báo hư hỏng đến thanh toán trực tuyến.
- Tích hợp liên kết ngân hàng cho phép sinh viên thanh toán chuyển khoản qua hệ thống.
- Tự động hóa tính toán tổng chi phí (điện + nước + tiền phòng + phí phát sinh) và cảnh báo trạng thái thanh toán.
- Cơ chế thông báo tự động khi hợp đồng sắp hết hạn và khi tài sản sắp hết hạn bảo hành.
Hạn chế và hướng nghiên cứu tiếp
Văn bản không trình bày riêng mục hạn chế. Dựa trên phạm vi đồ án, có thể nhận thấy một số giới hạn tự nhiên:
- Đồ án dừng ở giai đoạn phân tích và thiết kế (SRS + giao diện minh họa), chưa bao gồm giai đoạn lập trình, kiểm thử và triển khai thực tế.
- Mẫu khảo sát sinh viên và ban quản lý có quy mô nhỏ (ba người trong ban quản lý được ghi nhận cụ thể), mức độ đại diện cần mở rộng nếu triển khai thực tế.
- Thiết kế giao diện dừng ở dạng mockup tĩnh, chưa có prototype tương tác hoặc kiểm thử khả năng sử dụng (usability testing).
- Hướng mở rộng tiếp theo: phát triển thực tế hệ thống theo kế hoạch sáu giai đoạn đã lập, bổ sung tính năng đăng ký phòng trực tuyến mà sinh viên đề xuất.
Giá trị tham khảo
Tài liệu phù hợp tham khảo với các đối tượng sau:
- Sinh viên ngành Hệ thống Thông tin Quản lý, Công nghệ Thông tin đang học các môn Phân tích kinh doanh, Phân tích và thiết kế hệ thống thông tin: có thể tham khảo cách lập ma trận RACI, viết User Story theo chuẩn, xây dựng bảng đặc tả Use Case với đầy đủ Basic/Alternative/Exception Flow.
- Sinh viên thực hiện đồ án nhóm có chủ đề quản lý: cách tổ chức bảng phân chia công việc, kế hoạch hoạt động phân tích kinh doanh theo giai đoạn, và kế hoạch truyền thông với các bên liên quan.
- Người nghiên cứu về ứng dụng Agile/Scrum trong dự án phần mềm quy mô nhỏ: phần trình bày mô hình Agile và quy trình quản lý thay đổi Change-Driven là ví dụ ứng dụng thực tế.
- Phần ước lượng chi phí nhân lực (bảng quy đổi lương theo giờ cho từng vai trò tại Việt Nam năm 2023) có giá trị tham khảo cho các nhóm muốn lập ngân sách dự án phần mềm quy mô vừa và nhỏ.
Câu hỏi thường gặp
1. Hệ thống cho phép sinh viên tự cập nhật những thông tin cá nhân nào?
Theo kết quả phỏng vấn Ban quản lý, sinh viên có quyền cập nhật số điện thoại và email; không có quyền chỉnh sửa họ tên, CCCD và thời hạn ở phòng. Trong phần thông tin phòng, sinh viên chỉ được xem, không được chỉnh sửa.
2. Quy trình nhập thông tin điện nước lên hệ thống được thực hiện như thế nào?
Ban quản lý định kỳ đi kiểm tra và ghi chép số điện nước từng phòng, lưu vào file Excel, sau đó tải file lên hệ thống thông qua chức năng Import (màn hình PAYAD.2). Hệ thống hiển thị xem trước dữ liệu để kiểm tra trước khi xác nhận (PAYAD.3), rồi tự động tính tổng tiền điện nước và cập nhật vào trạng thái công nợ từng sinh viên.
3. Hợp đồng thuê phòng được quản lý như thế nào trên hệ thống?
Theo khảo sát, 75% Ban quản lý cho rằng hợp đồng hết hạn sẽ lưu trữ trên hệ thống (số còn lại lưu cả bản giấy). Hệ thống hỗ trợ import nhiều hợp đồng qua file xlsx, thêm thủ công từng hợp đồng, gia hạn hợp đồng dựa trên thông tin hợp đồng cũ mà không cần nhập lại, và xem hợp đồng điện tử (CONTRACTAD.5). Hệ thống cũng gửi thông báo khi hợp đồng sắp hết hạn.
4. Cơ chế bảo mật tài khoản của hệ thống được thiết kế như thế nào?
Hệ thống áp dụng xác thực hai yếu tố (tên đăng nhập/mật khẩu kết hợp OTP). Khi đăng nhập, người dùng nhập sai thông tin 3 lần liên tiếp sẽ bị khóa tài khoản 30 phút; timeout màn hình là 2 phút. Khi lấy lại mật khẩu qua SĐT, mã OTP có hiệu lực 60 giây; nhập sai OTP 3 lần liên tiếp sẽ bị khóa 15 phút.
5. Nhóm người dùng Ban quản lý có bao nhiêu Use Case và được phân chia theo chức năng nào?
Ban quản lý có hơn 25 Use Case được mã hóa, phân theo các nhóm: Đăng nhập/Quên mật khẩu (ADLOGIN.1, ADFORGET.1), Quản lý phòng (ADROOM.1–6), Quản lý thanh toán — gồm ba phân nhóm điện nước/tiền phòng/tổng thanh toán (ADPAY.1–5 mỗi nhóm), Quản lý tài sản — gồm bốn phân nhóm bố trí/dự trù/hư hỏng/bảo hành (ADPROPERTY Y1.1–Y4.2), Quản lý thông tin sinh viên (ADINFOR.1–4), và Quản lý hợp đồng (ADCONTRAC.T1–T5).
Kết luận
Đồ án môn học này cung cấp một tài liệu phân tích kinh doanh tương đối đầy đủ cho bài toán số hóa quản lý ký túc xá tại trường đại học, bao gồm từ giai đoạn thu thập yêu cầu (phỏng vấn, khảo sát) đến thiết kế mô hình (ERD, DFD, Use Case) và thiết kế giao diện người dùng cho cả Ban quản lý lẫn Sinh viên. Việc áp dụng kết hợp Agile/Scrum, ma trận RACI, phương pháp MoSCoW và quy trình Change-Driven thể hiện nỗ lực vận dụng khung lý thuyết phân tích kinh doanh có hệ thống. Kết quả khảo sát cho thấy nhu cầu số hóa rõ ràng từ cả hai nhóm người dùng, trong đó yêu cầu liên kết ngân hàng và thanh toán trực tuyến được 80% sinh viên ủng hộ. Tài liệu dừng ở giai đoạn phân tích–thiết kế và có thể được sử dụng làm đầu vào cho giai đoạn phát triển phần mềm thực tế theo lộ trình sáu giai đoạn mà nhóm đã hoạch định.
