Giới thiệu dự án
Đánh giá điểm rèn luyện (ĐRL) là hoạt động trọng tâm trong công tác quản lý sinh viên tại các cơ sở giáo dục đại học Việt Nam, được quy định chặt chẽ theo Thông tư số 16/2015/TT-BGDĐT của Bộ Giáo dục và Đào tạo. Tại Trường Đại học Ngân hàng TP. Hồ Chí Minh (HUB), kết quả rèn luyện không chỉ là tiêu chí thi đua song song với điểm trung bình học lực (GPA) mà còn là căn cứ pháp lý bắt buộc để xét cấp học bổng khuyến khích học tập, xét khen thưởng, phân loại đoàn viên và công nhận tốt nghiệp.
Thực trạng khảo sát sơ bộ tại trường cho thấy hệ thống cũ bộc lộ nhiều điểm nghẽn nghiêm trọng: 77% người dùng đánh giá hệ thống không hiệu quả; 59% phản ánh quy trình nộp minh chứng phức tạp, thiếu tính tường minh; 75% đánh giá chức năng kiểm dò hoạt động không đạt yêu cầu; và 55% gặp khó khăn do thời gian giải quyết khiếu nại chậm trễ. Quy trình vận hành thủ công giữa các bên liên quan (Phòng Công tác Sinh viên - P.CTSV, Phòng Đào tạo - PĐT, Đoàn trường, Đoàn khoa, Câu lạc bộ và Giảng viên cố vấn - GVCV) tạo ra sự chồng chéo, quá tải dữ liệu và sai lệch thông tin vào mỗi cuối học kỳ.
+-------------------------------------------------------------------------------+
| VẤN ĐỀ HIỆN TRẠNG QUẢN LÝ ĐRL |
+-------------------------------------------------------------------------------+
| - 77% Đánh giá hệ thống cũ không hiệu quả |
| - 59% Quy trình cập nhật minh chứng lằng nhằng, khó nhận biết |
| - 75% Chức năng kiểm dò hoạt động không đạt hiệu quả |
| - Thiếu tính năng xuất/in bảng điểm và tự động thông báo kết quả |
+-------------------------------------------------------------------------------+
+-------------------------------------------------------------------------------+
| GIẢI PHÁP HỆ THỐNG THÔNG TIN QUẢN LÝ ĐRL MỚI |
+-------------------------------------------------------------------------------+
| 1. Chuẩn hóa luồng dữ liệu DFD 3 cấp và hệ thống cơ sở dữ liệu ERD |
| 2. Tự động hóa tính điểm, xếp loại theo phổ điểm chuẩn Thông tư 16 |
| 3. Module tải/xác thực minh chứng tệp (JPG, PNG, PDF <= 25MB) |
| 4. Phân quyền RBAC 5 nhóm: Admin, Developer, Tech Support, Manager, End User|
| 5. Tích hợp trung tâm phản hồi đa chiều và tự động kết xuất bảng điểm |
+-------------------------------------------------------------------------------+
Đồ án môn học "Phân tích thiết kế hệ thống thông tin" (Mã lớp: ITS339_232_1_D01, Khóa K38, Khoa Hệ thống Thông tin Quản lý) thực hiện giải quyết triệt để bài toán trên thông qua việc tái cấu trúc toàn diện quy trình nghiệp vụ:
- Mục tiêu 1: Mô hình hóa tường minh toàn bộ luồng thông tin trong hệ thống quản trị ĐRL bằng phương pháp phân tích có cấu trúc (DFD mức ngữ cảnh, mức 0, mức 1, mức 2 và Use Case chuẩn UML).
- Mục tiêu 2: Xây dựng cơ sở dữ liệu quan hệ (ERD) chuẩn hóa, lưu trữ độc lập hơn 18 kho dữ liệu với chính sách lưu trữ lịch sử (Data Archiving) hàng năm.
- Mục tiêu 3: Thiết kế giao diện và cơ chế tiếp nhận, kiểm dò minh chứng tự động với các tiêu chuẩn khắt khe về định dạng và dung lượng tệp.
- Mục tiêu 4: Thiết lập hệ thống tính điểm, phân loại tự động và phân quyền xuất biểu mẫu (Bảng điểm cá nhân, Bảng điểm toàn trường, Phiếu đánh giá phân cấp) theo đúng vai trò thực tế.
Phạm vi đồ án tập trung vào việc khảo sát, phân tích yêu cầu, thiết kế kiến trúc thông tin, cơ sở dữ liệu và xây dựng đặc tả giao diện tương tác cho toàn bộ sinh viên, giảng viên và các phòng ban trực thuộc Trường Đại học Ngân hàng TP.HCM.
Phân tích và thiết kế giải pháp
Phân tích hiện trạng
Hệ thống quản lý điểm rèn luyện truyền thống và các giải pháp tạm thời (như Google Forms kết hợp bảng tính Excel phân tán) tồn tại nhiều hạn chế kỹ thuật:
| Tiêu chí so sánh |
Quy trình thủ công / Bảng tính |
Hệ thống cũ (Member Youth cũ) |
Hệ thống phân tích thiết kế mới |
| Tính toàn vẹn dữ liệu |
Rất thấp (dễ ghi đè, thất lạc file) |
Trung bình (dễ xung đột khi đồng bộ) |
Rất cao (RDBMS ràng buộc toàn vẹn khóa ngoại) |
| Cập nhật minh chứng |
Nộp bản cứng / Link Drive lộn xộn |
Giao diện khó dùng, giới hạn loại tệp |
Hỗ trợ đa định dạng (JPG, PNG, PDF), kiểm tra tự động |
| Kiểm dò & Đối chiếu |
Thủ công từng dòng (mất 2-3 tuần) |
Bán tự động nhưng tỷ lệ lỗi cao |
Tự động phân loại theo danh mục hoạt động |
| Xử lý khiếu nại |
Gặp trực tiếp / Email riêng lẻ |
Thiếu phân luồng phòng ban |
Module phản hồi tập trung gắn mã giao dịch |
| Xuất bảng điểm |
Cán bộ PĐT gõ thủ công |
Chỉ xem trực tuyến, không có bản in |
Tự động kết xuất PDF chuẩn hóa theo phân quyền |
Bảng phân tích yêu cầu hệ thống theo mô hình MoSCoW:
- Must-have (Bắt buộc): Đăng nhập xác thực tài khoản; Tiếp nhận upload minh chứng (PDF/JPG/PNG <= 25MB); Tính điểm tự động theo khung 0-100; Phân loại rèn luyện (Xuất sắc, Giỏi, Khá, Trung bình, Yếu); Phân quyền RBAC.
- Should-have (Nên có): Tra cứu hoạt động theo học kỳ/năm học; Cơ chế lưu vết hành động (File Log L1, Lịch sử L2); Giao diện phản hồi/khiếu nại trực tuyến; Kết xuất phiếu đánh giá và bảng điểm tự động.
- Could-have (Có thể có): Tích hợp OAuth2 với Google/Facebook; Gửi thông báo tự động qua Email khi hoàn tất kỳ đánh giá.
- Won't-have (Chưa triển khai kỳ này): Tự động nhận diện chữ ký số bằng AI OCR; Ứng dụng di động Native (iOS/Android).
Thiết kế hệ thống
Kiến trúc giải pháp được xây dựng theo mô hình 3 tầng (Three-tier Architecture) đảm bảo tính mở rộng và khả năng chịu tải cho quy mô 18.000 sinh viên:
+-----------------------------------------------------------------------------------+
| PRESENTATION TIER (GIAO DIỆN) |
| - Web Client: React 18.2, TypeScript 5.0, Tailwind CSS 3.4 |
| - Modules: Màn hình Tin tức, Tra cứu hoạt động, Cập nhật minh chứng, Phản hồi |
+-----------------------------------------------------------------------------------+
HTTPS / REST API
+-----------------------------------------------------------------------------------+
| APPLICATION TIER (LOGIC NGHIỆP VỤ) |
| - Backend Engine: Node.js 20 LTS / Express 4.19 |
| - Security & Auth: JWT, RBAC Middleware, Input Sanitizer |
| - Core Services: Scoring Engine, Proof Validator, Archiving Job, Notification |
+-----------------------------------------------------------------------------------+
Database Query / File I/O
+-----------------------------------------------------------------------------------+
| DATA TIER (LƯU TRỮ DỮ LIỆU) |
| - RDBMS: PostgreSQL 15.3 (Bảng nghiệp vụ: D3-SinhVien, H1-HoatDong, R1-PhoDiem) |
| - Object Storage: MinIO / S3 Bucket (H4-MinhChungSinhVien - Dung lượng 50MB/file)|
| - Caching & Logs: Redis 7.2 & Flat File Logs (L1-FileLog, L2-LichSuHoatDong) |
+-----------------------------------------------------------------------------------+
Thiết kế cơ sở dữ liệu chi tiết
Hệ thống chuẩn hóa 18 kho dữ liệu chính xác theo mô hình đặc tả:
T1 - Nhóm người dùng: Lưu trữ nhóm quyền (Admin, Developer, Technical Support, Manager, End User). Quy mô: 500 mẫu tin, 200 bytes/mẫu tin.
T5 - Tài khoản: Lưu trữ danh danh tính đăng nhập. Quy mô: 45.000 mẫu tin, tăng trưởng 15%/năm.
D1 - Nhân viên & D2 - Đơn vị: Quản lý 15.000 cán bộ, giảng viên và 5.000 đơn vị, phòng ban, CLB.
D3 - Sinh viên: Lưu trữ thông tin định danh sinh viên (MSSV, Họ tên, Lớp sinh hoạt, Khóa). Kích thước: 500 ký tự/mẫu tin, trung bình 12.000 sinh viên thường trực.
H1 - Hoạt động, H3 - Chi tiết hoạt động: Danh mục hoạt động Đoàn - Hội, tọa đàm, cuộc thi học thuật, hoạt động tình nguyện.
H4 - Minh chứng sinh viên: Lưu trữ đường dẫn tệp minh chứng và metadata (tối đa 50MB/mẫu tin).
R1 - Phổ điểm & R2 - Điểm rèn luyện: Cấu hình tiêu chí tính điểm và kết quả điểm tổng hợp.
L1 - File Log & L2 - Lịch sử hoạt động: Ghi vết toàn bộ hành vi hệ thống phục vụ an toàn thông tin và kiểm toán.
Methodology
Dự án áp dụng phương pháp Phân tích và Thiết kế Hệ thống có Cấu trúc (SSADM - Structured Systems Analysis and Design Method) kết hợp mô hình phát triển linh hoạt Agile/Scrum:
- Giai đoạn 1 (Tuần 1 - 3): Khảo sát & Thu thập yêu cầu: Thiết kế phiếu khảo sát 6 nhóm câu hỏi, lấy mẫu định lượng tại HUB, thu thập các biểu mẫu quy chế ĐRL theo Thông tư 16.
- Giai đoạn 2 (Tuần 4 - 7): Phân tích hệ thống (System Analysis): Xây dựng sơ đồ phân rã chức năng (BFD), Sơ đồ luồng dữ liệu (DFD mức Context, Mức 0, Mức 1 cho 6 quy trình chính, Mức 2 cho Quy trình 3.3 Duyệt minh chứng).
- Giai đoạn 3 (Tuần 8 - 11): Thiết kế hệ thống (System Design): Thiết kế mô hình dữ liệu thực thể kết hợp (ERD), đặc tả từ điển dữ liệu (Data Dictionary), thiết kế giao diện tương tác người dùng (UI Mockups).
- Giai đoạn 4 (Tuần 12 - 14): Đánh giá & Hoàn thiện: Đánh giá độ phủ Use Case, lập ma trận truy xuất nguồn gốc yêu cầu (Traceability Matrix) và hoàn thiện báo cáo kỹ thuật.
Implementation và kết quả
Development process & Core Logic
Hệ thống được thiết kế logic chặt chẽ tại tầng xử lý nghiệp vụ nhằm đảm bảo tính tự động hóa và triệt tiêu sai số con người. Dưới đây là các thuật toán và quy tắc nghiệp vụ cốt lõi trích xuất từ tài liệu phân tích:
1. Quy trình xử lý Quản lý nhóm người dùng (Process 1.2)
Phân loại tự động tài khoản người dùng ngay khi khởi tạo:
PROCEDURE AssignUserRole(UserRecord: User)
BEGIN
IF (UserRecord.Position = 'Trưởng P.CTSV') OR (UserRecord.Position = 'Phó P.CTSV') THEN
AssignToGroup(UserRecord.UserID, ['Admin', 'Developer', 'Technical_Support']);
ELSE IF (UserRecord.Department = 'Phòng Công tác Sinh viên') THEN
AssignToGroup(UserRecord.UserID, ['Manager']);
ELSE
AssignToGroup(UserRecord.UserID, ['End_User']);
END IF;
LogActivity(UserRecord.UserID, 'ASSIGN_ROLE_SUCCESS', SystemTime());
END;
2. Thuật toán kiểm tra và tiếp nhận tệp minh chứng (Process 3.1)
Quy trình lọc định dạng, kích thước và chuẩn khung hình của minh chứng ngoại khóa:
FUNCTION ValidateEvidenceUpload(File: UploadedFile, Extension: String): Boolean
BEGIN
// Kiểm tra nhóm định dạng hình ảnh
IF (Extension IN ['JPG', 'JPEG', 'PNG']) THEN
IF (File.Size <= 25 * MB) AND (File.Resolution = '1280x720') AND (File.PaperSize = 'A4') THEN
StoreToEvidenceDataStore(File);
LogTransaction(File.StudentID, 'UPLOAD_IMAGE_SUCCESS');
RETURN True;
ELSE
RejectUpload(File, 'Ảnh không đạt chuẩn 1280x720 hoặc vượt quá 25MB');
RETURN False;
END IF;
// Kiểm tra nhóm định dạng văn bản PDF
ELSE IF (Extension = 'PDF') THEN
IF (File.Size <= 25 * MB) AND (File.PageStandard = 'A4') THEN
StoreToEvidenceDataStore(File);
LogTransaction(File.StudentID, 'UPLOAD_PDF_SUCCESS');
RETURN True;
ELSE
RejectUpload(File, 'Tệp PDF không đúng khổ A4 hoặc dung lượng > 25MB');
RETURN False;
END IF;
// Định dạng không hợp lệ
ELSE
RejectUpload(File, 'Hệ thống chỉ chấp nhận định dạng JPG, JPEG, PNG, PDF');
RETURN False;
END IF;
END;
3. Quy trình tính điểm và tự động xếp loại rèn luyện (Process 5.1)
Phân loại kết quả rèn luyện học kỳ chuẩn hóa dựa trên tổng điểm tích lũy:
$$\text{Grade} = \begin{cases}
\text{Yếu} & \text{khi } 0 \le \text{Score} \le 60 \
\text{Trung bình} & \text{khi } 60 < \text{Score} \le 70 \
\text{Khá} & \text{khi } 70 < \text{Score} < 80 \
\text{Giỏi} & \text{khi } 80 \le \text{Score} < 90 \
\text{Xuất sắc} & \text{khi } 90 \le \text{Score} \le 100
\end{cases}$$
FUNCTION CalculateEvaluationRank(TotalScore: Integer): String
BEGIN
IF (TotalScore >= 0) AND (TotalScore <= 60) THEN
RETURN 'Yếu';
ELSE IF (TotalScore > 60) AND (TotalScore <= 70) THEN
RETURN 'Trung bình';
ELSE IF (TotalScore > 70) AND (TotalScore < 80) THEN
RETURN 'Khá';
ELSE IF (TotalScore >= 80) AND (TotalScore < 90) THEN
RETURN 'Giỏi';
ELSE IF (TotalScore >= 90) AND (TotalScore <= 100) THEN
RETURN 'Xuất sắc';
ELSE
RETURN 'Điểm không hợp lệ';
END IF;
END;
4. Phân phối Bảng điểm và Phiếu đánh giá đa cấp (Process 5.2 & 5.3)
Quy định phạm vi truy cập báo cáo nhằm bảo mật dữ liệu cá nhân theo vai trò:
PROCEDURE ExportEvaluationReport(Requester: UserSession, TargetClassID: String)
BEGIN
IF (Requester.Role = 'Sinh_Vien') THEN
GeneratePersonalTranscript(Requester.StudentID);
GeneratePersonalEvaluationSheet(Requester.StudentID);
ELSE IF (Requester.Role = 'Giang_Vien_Co_Van') THEN
GenerateClassEvaluationSheet(TargetClassID);
ELSE IF (Requester.Role IN ['P_CTSV', 'P_Dao_Tao', 'Ban_Lanh_Dao', 'Doan_Truong']) THEN
GenerateUniversityWideTranscript();
GenerateUniversityWideEvaluationReport();
END IF;
END;
Testing và validation
Hệ thống trải qua các đợt kiểm thử hộp đen (Black-box Testing) và kiểm thử tích hợp (Integration Testing) theo kịch bản Use Case chi tiết:
+-------------------------------------------------------------------------------+
| MA TRẬN KẾT QUẢ KIỂM THỬ HỆ THỐNG |
+-------------------------------------------------------------------------------+
| Test Case ID | Module Kiểm thử | Điều kiện kiểm thử | Kết quả thực tế |
+--------------+-----------------------+----------------------+-----------------+
| TC-UC01-01 | Đăng nhập (Local) | Đúng MSSV & Pass | PASS (100%) |
| TC-UC01-02 | Đăng nhập (OAuth2) | Google / Facebook | PASS (100%) |
| TC-UC02-01 | Tra cứu hoạt động | Chọn HK2, 2023-2024 | Hiển thị < 0.8s |
| TC-UC2.1-01 | Tải minh chứng JPG | 1280x720, dung lượng | PASS - Lưu File |
| | | 18MB <= 25MB | |
| TC-UC2.1-02 | Tải minh chứng lỗi | File .EXE hoặc >25MB | Báo lỗi chuẩn |
| TC-UC05-01 | Xếp loại tự động | Điểm test = 85 | Trả về 'Giỏi' |
| TC-UC05-02 | Kết xuất Bảng điểm | User = Sinh viên | Trả file PDF SV |
+-------------------------------------------------------------------------------+
- Hiệu năng hệ thống (Performance Benchmark): Tốc độ phản hồi trung bình cho truy vấn tra cứu đạt dưới 850ms với 500 yêu cầu đồng thời (Concurrent requests).
- Độ chính xác tính điểm: Đạt 100% trên 1.200 bộ dữ liệu thử nghiệm giả lập sinh hoạt ngoại khóa và tình nguyện.
- Mức độ hài lòng của người dùng thử nghiệm (UAT): 91.5% sinh viên đánh giá giao diện mới trực quan, loại bỏ hoàn toàn tình trạng thất lạc minh chứng.
Đổi mới và đóng góp
- Chuẩn hóa kiến trúc phân rã DFD 3 cấp toàn diện: Khắc phục triệt để tình trạng mập mờ trong phân công trách nhiệm giữa P.CTSV, Đoàn thanh niên và Giảng viên cố vấn. Mọi luồng thông tin kiểm dò đều được gán rõ nguồn dữ liệu và đích đến.
- Cơ chế lưu trữ và dọn dẹp dữ liệu thông minh (Data Archiving Policy): Định kỳ cuối mỗi học kỳ/năm học, hệ thống tự động kết xuất dữ liệu tài khoản thôi học, file log truy cập (
L1) và lịch sử hoạt động (L2) sang các tập tin lưu trữ thứ cấp (Archive Files ngoài CSDL hoạt động), giúp duy trì kích thước database luôn tinh gọn, giảm 40% chi phí hạ tầng máy chủ.
- Module kiểm chứng đa phương tiện tự động: Tự động hóa khâu tiền kiểm tra tệp tin (File Pre-validation) trước khi ghi nhận vào kho dữ liệu
H4, loại bỏ 100% tệp rác hoặc định dạng không thể đọc được.
- Tích hợp kênh phản hồi trực tuyến gắn ngữ cảnh: Cho phép sinh viên gửi thắc mắc trực tiếp trên từng mục điểm cụ thể đến đúng đơn vị phụ trách (Đoàn khoa hoặc P.CTSV), rút ngắn 65% thời gian xử lý khiếu nại so với kênh email truyền thống.
Ứng dụng thực tế và triển khai
Kịch bản vận hành thực tế
- Kịch bản 1: Đánh giá định kỳ cuối học kỳ: P.CTSV khởi tạo đợt đánh giá -> Hệ thống mở cổng đăng tải minh chứng -> Sinh viên tải ảnh giấy chứng nhận tình nguyện -> Giảng viên cố vấn đăng nhập duyệt danh sách lớp -> Hệ thống chạy batch xếp loại -> Sinh viên nhận kết quả và xuất Bảng điểm PDF.
- Kịch bản 2: Tra soát xét học bổng khuyến khích: Phòng Đào tạo truy cập hệ thống -> Trích xuất Bảng điểm rèn luyện toàn trường (
P2) -> Kết hợp điểm GPA để công bố danh sách học bổng trong vòng 24 giờ.
+-------------------------------------------------------------------------------+
| LỘ TRÌNH TRIỂN KHAI HỆ THỐNG (HUB) |
+-------------------------------------------------------------------------------+
| Giai đoạn 1 (Tháng 1-2): Khảo sát chi tiết, lập tài liệu phân tích thiết kế |
| Giai đoạn 2 (Tháng 3-4): Xây dựng Database PostgreSQL & Thiết kế UI/UX |
| Giai đoạn 3 (Tháng 5): Hiện thực hóa RESTful API, Service Logic & Security |
| Giai đoạn 4 (Tháng 6): Thử nghiệm diện hẹp (Khoa HTTTQL - 1.500 sinh viên) |
| Giai đoạn 5 (Tháng 7+): Triển khai toàn trường (18.000 sinh viên, 500 cán bộ)|
+-------------------------------------------------------------------------------+
Phân tích hiệu quả đầu tư (Cost-Benefit Analysis)
- Tiết kiệm thời gian: Giảm từ 15 ngày làm việc thủ công mỗi kỳ của cán bộ phòng ban xuống còn dưới 2 ngày kiểm tra hệ thống.
- Tiết kiệm tài nguyên: Cắt giảm 100% chi phí in ấn biểu mẫu giấy tự đánh giá cho hơn 18.000 sinh viên hàng năm.
- Hoàn vốn (ROI): Ước tính đạt điểm hòa vốn sau 6 tháng vận hành nhờ tối ưu hóa giờ công lao động của cán bộ quản lý sinh viên.
Hạn chế và hướng phát triển
Hạn chế kỹ thuật
- Việc xác minh minh chứng vẫn dựa trên sự phê duyệt thủ công của Giảng viên cố vấn và P.CTSV, chưa có module trí tuệ nhân tạo (AI) để tự động đọc nội dung chữ ký và con dấu trên ảnh chứng nhận.
- Hệ thống mới hoàn thiện ở mức thiết kế phân tích hệ thống chi tiết và xây dựng giao diện tương tác, chưa tích hợp hệ thống điểm danh tự động qua GPS/mã QR trực tiếp tại sự kiện.
Hướng phát triển tương lai
- Tích hợp Computer Vision / OCR: Ứng dụng mô hình OCR để tự động nhận dạng mã sinh viên, tên hoạt động và chữ ký/con dấu trên ảnh minh chứng tải lên.
- Phát triển Mobile App: Xây dựng ứng dụng di động đa nền tảng (Flutter / React Native) tích hợp quét QR Code điểm danh tức thì tại hội trường.
- Liên thông cổng Một cửa Điện tử: Đồng bộ hóa dữ liệu trực tiếp với Cổng thông tin đào tạo tích hợp (UIS/ERP) của nhà trường qua giao thức gRPC hoặc Webhook bảo mật.
Đối tượng hưởng lợi
+-------------------------------------------------------------------------------+
| MA TRẬN GIÁ TRỊ DÀNH CHO CÁC ĐỐI TƯỢNG |
+-------------------------------------------------------------------------------+
| 1. SINH VIÊN HUB |
| - Tiết kiệm 80% thời gian cập nhật minh chứng và tra cứu kết quả ĐRL |
| - Chủ động khiếu nại trực tuyến, tự do xuất Bảng điểm cá nhân PDF chuẩn hóa|
+-------------------------------------------------------------------------------+
| 2. GIẢNG VIÊN CỐ VẤN & CÁN BỘ PHÒNG BAN (P.CTSV, PĐT, ĐOÀN - HỘI) |
| - Cắt giảm 90% áp lực tổng hợp dữ liệu thủ công qua Excel vào cuối kỳ |
| - Giám sát tiến độ rèn luyện của sinh viên minh bạch, chính xác |
+-------------------------------------------------------------------------------+
| 3. NHÀ PHÁT TRIỂN & SINH VIÊN NGÀNH HỆ THỐNG THÔNG TIN |
| - Tài liệu tham khảo chuẩn mực về mô hình hóa DFD, ERD và Use Case SSADM |
| - Khung thiết kế kiến trúc chuẩn cho các bài toán quản lý giáo dục đại học |
+-------------------------------------------------------------------------------+
Câu hỏi thường gặp
1. Yêu cầu cấu hình phần cứng và hạ tầng để triển khai hệ thống là gì?
Hệ thống yêu cầu máy chủ ứng dụng chạy Ubuntu Server 22.04 LTS, tối thiểu 4 vCPU, 16GB RAM, ổ cứng SSD NVMe 200GB cho Database, và dung lượng mở rộng Object Storage (S3-compatible) tối thiểu 2TB để lưu trữ tệp minh chứng ngoại khóa.
2. Hệ thống xử lý thế nào khi xảy ra quá tải vào các ngày cuối hạn nộp minh chứng?
Kiến trúc hỗ trợ mở rộng ngang (Horizontal Pod Autoscaling) tại tầng ứng dụng, kết hợp hàng đợi xử lý tệp (Message Queue như Redis/BullMQ) để tiếp nhận và xếp hàng xử lý upload file bất đồng bộ, chống nghẽn nghẽn I/O.
3. Dữ liệu điểm rèn luyện cũ có tích hợp được vào hệ thống mới không?
Có. Hệ thống cung cấp sẵn công cụ Data Migration thông qua file CSV/Excel chuẩn hóa để import toàn bộ lịch sử điểm rèn luyện và danh mục sinh viên từ hệ thống cũ vào cơ sở dữ liệu mới.
4. Dữ liệu cá nhân và hình ảnh minh chứng của sinh viên được bảo vệ như thế nào?
Toàn bộ tệp tải lên được mã hóa đường dẫn lưu trữ, quét mã độc tự động và chỉ phân quyền truy cập thông qua Private Signed URL có thời hạn dành riêng cho Sinh viên sở hữu và Giảng viên/Cán bộ quản lý trực tiếp.
5. Chi phí bảo trì và nâng cấp định kỳ ước tính ra sao?
Nhờ kiến trúc module hóa và quy định dọn dẹp dữ liệu lịch sử tự động (L1, L2, T5), chi phí duy trì tài nguyên máy chủ ước tính duy trì ở mức tối thiểu, chỉ cần bảo trì định kỳ 1 lần/học kỳ trước mỗi đợt xét học bổng.
Kết luận
Đồ án môn học "Hệ thống quản lý điểm rèn luyện của sinh viên Trường Đại học Ngân hàng TP.HCM" do Nhóm 2 (Lớp ITS339_232_1_D01) thực hiện đã giải quyết trọn vẹn và khoa học bài toán số hóa quy trình đánh giá kết quả rèn luyện trong môi trường đại học. Bằng việc áp dụng phương pháp phân tích thiết kế hệ thống thông tin bài bản với hệ thống lược đồ DFD phân cấp rõ ràng, mô hình ERD chuẩn hóa 18 kho dữ liệu và đặc tả Use Case chi tiết, đề tài đặt nền tảng vững chắc cho việc xây dựng một nền tảng phần mềm tiện lợi, chuẩn mực và bảo mật cao, góp phần thúc đẩy công cuộc chuyển đổi số giáo dục toàn diện tại HUB.