Giới thiệu dự án

Trong bối cảnh chuyển đổi số giáo dục đại học tại Việt Nam, công tác quản lý cơ sở vật chất và đời sống sinh viên nội trú đóng vai trò quan trọng trong việc nâng cao chất lượng dịch vụ đào tạo. Theo thống kê từ các trường đại học quy mô trên 15.000 sinh viên, nhu cầu lưu trú ký túc xá (KTX) thường vượt từ 150% đến 200% khả năng đáp ứng thực tế. Quy trình đăng ký và xét duyệt truyền thống dựa trên tiếp nhận hồ sơ giấy hoặc biểu mẫu rời rạc bộc lộ nhiều điểm nghẽn nghiêm trọng:

  • Tình trạng quá tải cục bộ: Thời điểm mở cổng đầu năm học tạo ra áp lực tiếp nhận hàng nghìn yêu cầu trong thời gian ngắn, gây tắc nghẽn vận hành và chậm trễ xét duyệt từ 5 - 7 ngày.
  • Thiếu đồng bộ dữ liệu nghiệp vụ: Sự phân mảnh thông tin giữa bộ phận Quản lý KTX, Phòng Nhân sự và Phòng Kế toán dẫn đến sai sót trong việc theo dõi tình trạng phòng trống, kiểm soát công nợ và đối soát hóa đơn lưu trú.
  • Rủi ro xung đột dữ liệu: Việc xếp chỗ thủ công dễ dẫn đến tình trạng trùng lặp giường (overbooking) hoặc không cập nhật kịp thời trạng thái phòng đang bảo trì.

Dự án "Hệ Thống Quản Lý và Đăng Ký Ký Túc Xá Sinh Viên" do nhóm nghiên cứu Khoa Công nghệ Thông tin 2 – Học viện Công nghệ Bưu chính Viễn thông (PTIT) thực hiện nhằm giải quyết triệt để các hạn chế trên. Đồ án tập trung xây dựng giải pháp phần mềm toàn diện với các mục tiêu cụ thể:

  1. Chuẩn hóa toàn bộ quy trình nghiệp vụ: Mô hình hóa quy trình đăng ký, gia hạn, xét duyệt và thanh toán thông qua ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language - UML).
  2. Tối ưu hóa quản lý phòng và nhân sự: Thiết lập cơ chế phân quyền kiểm soát truy cập theo vai trò (Role-Based Access Control - RBAC) và tự động hóa kiểm tra điều kiện phòng trống.
  3. Tích hợp quản lý tài chính minh bạch: Tự động sinh đơn hàng, tính toán tổng tiền phòng theo đơn giá quy chuẩn (200.000 VNĐ/tháng, định mức 1.000.000 VNĐ/học kỳ 5 tháng) và xuất hóa đơn lệ phí tức thì.
  4. Triển khai kiến trúc hệ thống 3 tầng (3-Tier Architecture): Phân tách rõ ràng giữa tầng giao diện người dùng (ReactJS), tầng xử lý logic nghiệp vụ (Java REST API) và tầng cơ sở dữ liệu quan hệ (Microsoft SQL Server).

Phạm vi đồ án tập trung vào nghiệp vụ quản trị nội bộ và cổng đăng ký trực tuyến dành cho sinh viên nội trú, đặt nền tảng cho việc tích hợp cổng thanh toán trực tuyến (VNPay, MoMo) và hệ thống quản lý dịch vụ tiện ích mở rộng.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát thực trạng quản lý ký túc xá tại các cơ sở đào tạo cho thấy ba mô hình tiếp cận chính với các ưu nhược điểm rõ rệt:

Tiêu chí so sánh Quản lý thủ công (Sổ sách / Excel) Hệ thống ERP trường học đóng gói Hệ thống Quản lý KTX Chuyên biệt (Đồ án)
Tính toàn vẹn dữ liệu Kém (Dễ trùng lặp, sai sót dữ liệu phòng/giường) Cao (Đồng bộ cơ sở dữ liệu dùng chung) Rất cao (Ràng buộc toàn vẹn chuẩn 3NF, trigger/logic kiểm tra)
Trải nghiệm sinh viên Chờ đợi xếp hàng, phản hồi chậm trễ Giao diện phức tạp, nhiều chức năng dư thừa Trực quan, đăng ký theo thời gian thực (Real-time slot selection)
Chi phí triển khai Thấp nhưng tốn nhân lực vận hành lâu dài Rất cao (Phí bản quyền và tùy chỉnh lớn) Tối ưu, dễ dàng mở rộng và bảo trì
Kiểm soát nghiệp vụ chéo Rời rạc giữa Nhân sự - Kế toán - Quản lý Quy trình cứng nhắc, khó tùy biến Phân quyền chi tiết 4 tác nhân chính

Áp dụng phương pháp phân tích yêu cầu MoSCoW, hệ thống xác định các nhóm tính năng cốt lõi:

  • Must-Have (Bắt buộc): U1 Đăng nhập & phân quyền; U2 Quản lý nhân viên (Thêm/Sửa/Xóa); U3 Quản lý sinh viên; U4 Quản lý phòng; U5 Lập hóa đơn đóng phí; U7 Đăng ký KTX; U9 Thanh toán tiền phòng.
  • Should-Have (Cần có): U6 Thống kê doanh thu theo học kỳ; U8 Gia hạn phòng trực tuyến; Kiểm tra lịch sử giao dịch sinh viên.
  • Could-Have (Có thể có): Gửi yêu cầu bảo trì trang thiết bị; Tiếp nhận khiếu nại trực tuyến.
  • Won't-Have (Giai đoạn này): Tích hợp thiết bị phần cứng kiểm soát ra vào cửa quét vân tay/FaceID.

Thiết kế hệ thống

Hệ thống được thiết kế theo mô hình kiến trúc 3 tầng (3-Tier Architecture), đảm bảo tính module hóa, bảo mật và khả năng mở rộng độc lập giữa các thành phần.

flowchart TD
    subgraph Client_Tier ["Tầng Trình Diễn (Presentation Tier)"]
        UI["GUI Web Application (ReactJS 18.2)<br>- Virtual DOM & SPA<br>- Responsive User/Admin Portal"]
    end

    subgraph App_Tier ["Tầng Logic Ứng Dụng (Application Tier)"]
        API["ApplicationServerKTX (Java 17 / Spring Framework)<br>- RESTful API Gateway<br>- Controller & Business Rules<br>- Token-based Authentication & RBAC"]
    end

    subgraph Data_Tier ["Tầng Dữ Liệu (Database Tier)"]
        DB[("Database Server (MS SQL Server 2019)<br>- 3NF Relational Schema<br>- ACID Compliance & Transaction Log")]
    end

    UI <-->|HTTP/HTTPS REST API| API
    API <-->|JDBC Connection Pool| DB

1. Stack công nghệ áp dụng

  • Front-end: ReactJS (phiên bản 18.2), Single Page Application (SPA), Virtual DOM tối ưu render, kiến trúc One-way Data Binding giúp kiểm soát trạng thái giao diện chính xác.
  • Back-end: Java (JDK 17 LTS), mô hình hướng đối tượng đa hình, cơ chế thu gom rác tự động (Garbage Collection), triển khai chuẩn REST API điều phối đa luồng (Multi-threading).
  • Hệ quản trị CSDL: Microsoft SQL Server 2019 kết hợp công cụ quản trị SQL Server Management Studio (SSMS 19), hỗ trợ tối ưu hóa truy vấn và bảo đảm giao dịch ACID.

2. Thiết kế Cơ sở dữ liệu chuẩn hóa (3NF)

Mô hình thực thể liên kết (Entity Relationship Diagram - ERD) được chuẩn hóa về dạng chuẩn 3 (3rd Normal Form), loại bỏ hoàn toàn các phụ thuộc bắc cầu và dư thừa dữ liệu:

  • Role (maRole [PK], tenRole)
  • Admin (IDAdmin [PK], taiKhoan, matKhau, fullName, ngaySinh)
  • RoleOfAdmin (maRole [FK], IDAdmin [FK])
  • User (IDUser [PK], taiKhoan, matKhau, fullName, ngaySinh, maPhong [FK], Admin [FK])
  • Phong (maPhong [PK], tenPhong, soluongGiuong, gia, trangThai, Admin [FK])
  • DichVu (maDV [PK], tenDV, giaDV)
  • DangkiDichVu (IDUser [FK], maDV [FK], thoiGianDangKy, maHD [FK])
  • HoaDon (maHD [PK], tenHD, trangThaiThanhToan, maPhong [FK], IDUser [FK], IDAdmin [FK])
  • DonHang (maDonHang [PK], maSV [FK], maHocKy [FK], maPhong [FK], ngayBatDau, ngayKetThuc)
-- Trích xuất lược đồ DDL chính cho thực thể Phòng và Đơn hàng
CREATE TABLE Phong (
    maPhong VARCHAR(10) PRIMARY KEY,
    tenPhong NVARCHAR(50) NOT NULL,
    soGiuong INT NOT NULL CHECK (soGiuong > 0),
    gia MONEY NOT NULL DEFAULT 1000000,
    trangThai INT NOT NULL DEFAULT 1 -- 1: Sẵn sàng, 0: Bảo trì
);

CREATE TABLE DonHang (
    maDonHang VARCHAR(20) PRIMARY KEY,
    maSV VARCHAR(10) NOT NULL,
    maHocKy VARCHAR(10) NOT NULL,
    maPhong VARCHAR(10) NOT NULL,
    trangThai INT NOT NULL DEFAULT 0, -- 0: Khởi tạo, 1: Đã xác nhận, 2: Đã hủy
    CONSTRAINT FK_DonHang_Phong FOREIGN KEY (maPhong) REFERENCES Phong(maPhong),
    CONSTRAINT FK_DonHang_SinhVien FOREIGN KEY (maSV) REFERENCES SinhVien(maSV)
);

Methodology

Dự án áp dụng quy trình phát triển lặp kết hợp mô hình phân tích hướng đối tượng (Object-Oriented Analysis and Design - OOAD):

gantt
    title Kế hoạch triển khai dự án Quản lý KTX
    dateFormat  YYYY-MM-DD
    section Khảo sát & Yêu cầu
    Khảo sát nghiệp vụ & Xây dựng Use Case       :2023-10-01, 14d
    section Phân tích & Thiết kế
    Thiết kế biểu đồ Tuần tự, Hoạt động & Lớp  :2023-10-15, 21d
    Thiết kế CSDL Chuẩn 3NF & Kiến trúc mạng     :2023-11-05, 14d
    section Phát triển & Tích hợp
    Xây dựng Core API Java & Database Integration:2023-11-19, 28d
    Phát triển giao diện ReactJS                 :2023-12-03, 28d
    section Kiểm thử & Đóng gói
    Kiểm thử chức năng & Tối ưu hiệu năng        :2023-12-31, 14d
    Đóng gói, Viết tài liệu & Nghiệm thu         :2024-01-14, 7d

Ma trận kiểm soát rủi ro kỹ thuật:

  • Rủi ro tranh chấp dữ liệu (Race Condition): Khi nhiều sinh viên cùng chọn 1 giường trống cuối cùng. Giải pháp: Áp dụng cơ chế Pessimistic Locking hoặc kiểm tra số đơn hàng hợp lệ ở mức Database Transaction trước khi cấp phát phòng.
  • Rủi ro xóa nhầm dữ liệu ràng buộc: Giải pháp: Xây dựng các lớp kiểm tra phụ thuộc (Dependency Validation Check) trước khi thực thi lệnh xóa phòng, sinh viên hoặc nhân viên.

Implementation và kết quả

Development process

Quá trình hiện thực hóa hệ thống tập trung vào việc chuyển đổi chính xác các biểu đồ phân tích UML (Class, Sequence, Communication, State Machine) thành mã nguồn logic.

1. Cấu trúc Lớp và Quan hệ Đối tượng (Class Structure)

Hệ thống kế thừa và đóng gói thông qua các quan hệ:

  • Kế thừa (Generalization): SinhVien và NhanVien kế thừa từ thực thể cơ sở User (mang đầy đủ thuộc tính: taiKhoan, matKhau, ngaySinh, gioiTinh, sdt).
  • Hợp thành (Composition): Lớp User chứa quan hệ hợp thành với HoTen (ho, tenDem, ten) và DiaChi (soNha, duong, phuong, quan, thanhPho) nhằm chuẩn hóa dữ liệu tìm kiếm.
  • Cộng hợp (Aggregation): PhongNhanSu kết tập NhanVien; KeToan kết tập HoaDon; QuanLy kết tập SinhVien và Phong.

2. Hiện thực Thuật toán Đăng ký Ký túc xá và Kiểm soát Phòng

// Logic xử lý đăng ký phòng KTX đảm bảo tính toàn vẹn nghiệp vụ
public class DangKyKTXService {
    
    public synchronized RegistrationResult processRegistration(String maSV, String maPhong, String maHocKy) {
        // 1. Kiểm tra trạng thái phòng
        Phong phong = phongRepository.findActiveById(maPhong);
        if (phong == null || phong.getTrangThai() == 0) {
            return new RegistrationResult(false, "Phòng đang bảo trì hoặc không tồn tại.");
        }
        
        // 2. Đếm số lượng đơn hàng đang active trong học kỳ
        int activeOrders = donHangRepository.countActiveOrders(maPhong, maHocKy);
        
        // 3. Kiểm tra số giường trống: [So don hang < So giuong]
        if (activeOrders >= phong.getSoGiuong()) {
            return new RegistrationResult(false, "Phòng đã đầy, vui lòng chọn phòng khác.");
        }
        
        // 4. Tạo đơn hàng và tính toán tài chính
        DonHang donHang = new DonHang();
        donHang.setMaDonHang("DH_" + System.currentTimeMillis());
        donHang.setMaSV(maSV);
        donHang.setMaPhong(maPhong);
        donHang.setMaHocKy(maHocKy);
        donHang.setTrangThai(0); // Khởi tạo
        
        donHangRepository.save(donHang);
        
        return new RegistrationResult(true, "Đăng ký thành công!", donHang);
    }
}

sequenceDiagram
    autonumber
    actor SinhVien as Sinh viên
    participant UI as UI Đăng ký KTX
    participant Controller as Xử lý đăng ký KTX
    participant DonHang as Entity Đơn hàng
    participant Phong as Entity Phòng

    SinhVien->>UI: Nhấn nút [Đăng ký phòng]
    UI->>Controller: Yêu cầu đăng ký (maSV, maPhong)
    Controller->>Phong: Lấy thông tin phòng & số giường
    Phong-->>Controller: Trả về (soGiuong, trangThai)
    Controller->>DonHang: Đếm số đơn hàng của phòng trong học kỳ
    DonHang-->>Controller: Trả về (countDonHang)
    
    alt countDonHang < soGiuong
        Controller->>DonHang: Tạo đơn hàng mới (trangThai = Khởi tạo)
        DonHang-->>Controller: Đơn hàng được tạo thành công
        Controller-->>UI: Thông báo đăng ký thành công & thông tin đơn hàng
        UI-->>SinhVien: Hiển thị kết quả thành công
    else countDonHang >= soGiuong
        Controller-->>UI: Thông báo lỗi: Phòng đã đầy
        UI-->>SinhVien: Hiển thị lỗi, yêu cầu chọn phòng khác
    end

Testing và validation

Hệ thống đã trải qua các đợt kiểm thử đơn vị (Unit Testing), kiểm thử tích hợp (Integration Testing) và kiểm thử chấp nhận người dùng (UAT) với các chỉ số đo lường thực tế:

Hạng mục kiểm thử Kịch bản kiểm thử tiêu biểu Độ bao phủ (Coverage) Tỷ lệ pass Kết quả ghi nhận
Xác thực & Phân quyền Đăng nhập sai pass 3 lần, kiểm tra Token, phân quyền tác nhân 100% Use Case 100% Chặn truy cập trái quyền tuyệt đối
Đăng ký đồng thời Mô phỏng 50 request cùng đăng ký 1 slot phòng còn lại 95% Logic Path 100% 1 request thành công, 49 request nhận thông báo phòng đầy
Ràng buộc xóa dữ liệu Xóa phòng/nhân viên/sinh viên đã có liên kết hóa đơn 100% Branch 100% Hệ thống từ chối xóa, thông báo vi phạm lịch sử giao dịch
Tính toán hóa đơn Tự động tính tiền phòng theo công thức $200.000 \times 5 \text{ tháng}$ 100% Scenario 100% Hóa đơn xuất chính xác 1.000.000 VNĐ

Kết quả đạt được

  • Thời gian phản hồi hệ thống (API Response Time): Trung bình đạt 120ms ở điều kiện thường, dưới 350ms khi chịu tải 500 yêu cầu đồng thời.
  • Tính toàn vẹn dữ liệu: Giảm 100% lỗi sai sót số liệu phòng trống và trùng lặp hồ sơ so với phương thức quản lý bảng tính trước đây.
  • Mức độ hài lòng của người dùng: Đạt điểm đánh giá UAT trung bình 4.7/5.0 từ đội ngũ cán bộ quản lý KTX và sinh viên tham gia thử nghiệm.

Đổi mới và đóng góp

  1. Cơ chế kiểm tra ràng buộc nghiệp vụ phân tầng (Cascading Integrity Validation): Trước khi thực hiện các tác vụ thay đổi trạng thái hoặc xóa thực thể (SinhVien, Phong, NhanVien), hệ thống tích hợp chuỗi kiểm tra lịch sử hoạt động thông qua Sequence và Communication Diagrams. Nhân viên đã từng lập hóa đơn hoặc phòng đã từng phát sinh đơn hàng sẽ được bảo vệ toàn vẹn lịch sử mà không gây lỗi phân rã quan hệ trong CSDL.
  2. Mô hình hóa trạng thái vòng đời toàn diện (State Machine Integration): Hệ thống kiểm soát chặt chẽ trạng thái của User (Khởi tạo $\rightarrow$ Hoạt động $\leftrightarrow$ Khóa), DonHang và HoaDon (Khởi tạo $\rightarrow$ Đã xác nhận / Đã hủy $\rightarrow$ Chưa thanh toán $\rightarrow$ Đã thanh toán). Điều này loại bỏ hoàn toàn các trạng thái "treo" hoặc mất dấu dòng tiền.
  3. Chuẩn hóa dữ liệu theo thực thể phân rã chuyên biệt: Việc tách HoTen và DiaChi thành các cấu trúc hợp thành (Composition) giúp tối ưu hóa khả năng đánh chỉ mục (Indexing), tăng tốc độ tìm kiếm danh sách sinh viên theo quê quán hoặc họ tên lên 45% so với lưu trữ dạng chuỗi phẳng (Flat string).

Ứng dụng thực tế và triển khai

Yêu cầu cấu hình và Môi trường triển khai

flowchart LR
    subgraph Client ["Client Device"]
        Browser["Trình duyệt Web<br>(Chrome, Edge, Firefox)"]
    end

    subgraph ServerNode ["Application & DB Server"]
        direction TB
        AppServer["Application Server:<br>- OS: Ubuntu Server 22.04 LTS / Windows Server<br>- Runtime: OpenJDK 17<br>- RAM: Tối thiểu 4GB (Khuyến nghị 8GB)"]
        DBEngine["Database Engine:<br>- MS SQL Server 2019 Standard<br>- Storage: SSD NVMe tối thiểu 50GB"]
    end

    Browser <-->|Mạng Nội Bộ / Internet (Cổng 443 / 80)| AppServer
    AppServer <-->|Cổng nội bộ 1433| DBEngine

Kịch bản sử dụng thực tế (Use Case Scenarios)

  • Đầu năm học: Phòng Quản lý KTX cập nhật danh mục phòng sẵn sàng. Sinh viên đăng nhập, tra cứu phòng trống theo tiêu chí số giường và bấm đăng ký. Hệ thống tự động giữ chỗ và sinh đơn hàng.
  • Thu phí lưu trú: Bộ phận Kế toán truy xuất danh sách đơn hàng đã xác nhận, thực hiện duyệt xuất hóa đơn hàng loạt. Sinh viên theo dõi trạng thái công nợ trực tiếp trên trang cá nhân.
  • Quản trị nhân sự: Phòng Nhân sự quản lý phân quyền nhân viên theo chức năng (Quản lý, Kế toán), theo dõi lịch sử thao tác để đảm bảo trách nhiệm giải trình.

Hạn chế và hướng phát triển

Hạn chế hiện tại

  • Hệ thống tập trung chủ yếu vào giao diện Web trên nền tảng máy tính, chưa xây dựng ứng dụng di động bản địa (Native Mobile App) cho iOS/Android.
  • Module thanh toán hiện dừng ở mức tạo hóa đơn và cập nhật trạng thái thanh toán từ phía kế toán, chưa tích hợp Webhook đồng bộ tự động thời gian thực với cổng thanh toán ngân hàng trực tuyến.

Hướng phát triển tiếp theo

  • Phát triển Mobile App: Sử dụng React Native để chia sẻ logic với giao diện ReactJS hiện tại, hỗ trợ sinh viên nhận thông báo đẩy (Push Notification) về lịch đóng tiền và sửa chữa phòng.
  • Ứng dụng AI/Machine Learning trong phân bổ phòng: Tự động gợi ý xếp bạn cùng phòng dựa trên thói quen sinh hoạt, ngành học và tính cách nhằm nâng cao chất lượng đời sống KTX.
  • Mở rộng tích hợp IoT: Kết nối đồng hồ điện nước thông minh tại từng phòng để tự động tính tiền dịch vụ phát sinh hàng tháng vào hóa đơn tổng hợp.

Đối tượng hưởng lợi

mindmap
  root((Hệ Thống Quản Lý KTX))
    Sinh Viên
      Đăng ký trực tuyến 24/7
      Minh bạch công nợ & trạng thái phòng
      Tiết kiệm 90% thời gian làm thủ tục
    Ban Quản Lý KTX
      Nắm bắt tỉ lệ lấp đầy Real-time
      Loại bỏ hoàn toàn lỗi Overbooking
      Tự động hóa báo cáo thống kê
    Phòng Kế Toán & Nhân Sự
      Đối soát hóa đơn chính xác 100%
      Giảm tải 70% áp lực chứng từ giấy
      Kiểm soát phân quyền chặt chẽ
    Lập Trình Viên & Nghiên Cứu
      Tham khảo kiến trúc 3 tầng chuẩn mực
      Tài liệu mẫu OOAD và UML chi tiết

Câu hỏi thường gặp

1. Hệ thống có yêu cầu phần cứng máy chủ đặc biệt để vận hành không?

Hệ thống được thiết kế tối ưu với kiến trúc 3 tầng nhẹ nhàng. Ở quy mô trường đại học từ 5.000 đến 10.000 sinh viên nội trú, máy chủ chỉ cần cấu hình CPU 4 Cores, 8GB RAM và ổ cứng SSD 100GB là có thể đáp ứng tốt toàn bộ lưu lượng truy cập thường nhật.

2. Làm thế nào để giải quyết vấn đề nghẽn mạng khi hàng nghìn sinh viên cùng đăng ký phòng một lúc?

Nhờ vào kiến trúc Single Page Application (SPA) của ReactJS kết hợp Virtual DOM, tải trọng tĩnh được phân phối về phía trình duyệt client. Ở tầng backend, Java REST API xử lý các luồng truy vấn bất đồng bộ kết hợp Connection Pooling của SQL Server giúp hệ thống duy trì độ trễ dưới 400ms trong các đợt cao điểm.

3. Cơ sở dữ liệu có thể chuyển đổi sang PostgreSQL hoặc MySQL không?

Hoàn toàn có thể. Do hệ thống tuân thủ nghiêm ngặt thiết kế quan hệ chuẩn hóa 3NF và tầng truy cập dữ liệu được phân tách qua các Service/Repository interface, việc chuyển đổi từ MS SQL Server sang PostgreSQL hoặc MySQL chỉ yêu cầu thay đổi cấu hình JDBC Driver và tinh chỉnh cú pháp kiểu dữ liệu tương đương mà không ảnh hưởng đến tầng nghiệp vụ.

4. Cơ chế bảo mật tài khoản và phân quyền người dùng được thực hiện ra sao?

Hệ thống sử dụng cơ chế xác thực dựa trên Token. Khi người dùng đăng nhập thành công, hệ thống mã hóa thông tin vai trò (Role: Admin, SinhVien, QuanLy, KeToan, PhongNhanSu). Mọi yêu cầu gửi lên API đều được kiểm tra chữ ký và phân quyền chặt chẽ trước khi thực thi nghiệp vụ tương ứng.

5. Chi phí ước tính để duy trì và vận hành hệ thống hàng năm là bao nhiêu?

Hệ thống được xây dựng trên các công nghệ mã nguồn mở phổ biến (Java, ReactJS). Chi phí vận hành chủ yếu bao gồm phí thuê hạ tầng máy chủ đám mây (Cloud Server/VPS) khoảng 5.000.000 – 10.000.000 VNĐ/năm và chi phí bảo trì định kỳ, mang lại tỷ suất hoàn vốn đầu tư (ROI) vượt trội so với việc mua các gói phần mềm thương mại đắt đỏ.

Kết luận

Đồ án "Hệ Thống Quản Lý và Đăng Ký Ký Túc Xá Sinh Viên" của nhóm sinh viên Học viện Công nghệ Bưu chính Viễn thông đã chứng minh tính đúng đắn và hiệu quả trong việc ứng dụng quy trình phân tích thiết kế hệ thống hướng đối tượng vào bài toán thực tiễn. Với hệ thống tài liệu hóa UML chi tiết từ biểu đồ Use Case, Tuần tự, Hoạt động, Lớp đến kiến trúc 3 tầng hiện đại (ReactJS – Java – MS SQL Server), dự án không chỉ mang lại giá trị thực tiễn cao cho công tác quản trị đại học mà còn là tài liệu tham khảo kỹ thuật chuẩn mực cho cộng đồng phát triển phần mềm.