Năm lỗi hội đồng CNTT gặp nhiều nhất là: chương cơ sở lý thuyết chép tài liệu công nghệ, không so sánh với giải pháp đã có, dùng ảnh chụp màn hình thay cho thiết kế, không có phần đánh giá, và mã nguồn không chạy được trên máy hội đồng hay máy trình chiếu.
Những lỗi này lặp lại qua nhiều khoá vì sinh viên học cách viết từ khoá luận của khoá trước, kể cả những bản có lỗi. Phần lớn sửa được trong vài tuần nếu phát hiện sớm. Dưới đây là từng lỗi, cách nhận ra trong bản thảo của chính bạn, và cách sửa.
Lỗi 1: chương lý thuyết là bản chép tài liệu công nghệ
Biểu hiện
Hai mươi trang giới thiệu ngôn ngữ lập trình, khung phát triển, hệ quản trị cơ sở dữ liệu, mỗi phần có lịch sử ra đời, ưu nhược điểm, ví dụ “Hello World”. Nội dung lấy từ trang tài liệu chính thức hoặc bài hướng dẫn, đôi khi dịch nguyên văn.
Vì sao mất điểm
Hội đồng không cần bạn giới thiệu công nghệ phổ biến. Phần dịch hay chép từ tài liệu mà không ghi nguồn còn là đạo văn, và phần mềm kiểm trùng hay đánh dấu những đoạn này.
Cách sửa
Rút phần công nghệ xuống vài trang, chỉ giữ điều cần để hiểu thiết kế và lý do chọn. Dành chỗ cho khái niệm nghiệp vụ của bài toán và cho phần so sánh giải pháp. Đoạn nào lấy ý từ tài liệu thì diễn đạt bằng lời của bạn và ghi nguồn.
Lỗi 2: không so sánh với giải pháp đã có
Biểu hiện
Khoá luận xây hệ thống quản lý phòng trọ nhưng không nhắc tới các ứng dụng quản lý phòng trọ đang có trên thị trường. Khoá luận thuật toán không có mô hình cơ sở.
Vì sao mất điểm
Câu hỏi đầu tiên của hội đồng thường là: đã có nhiều phần mềm làm việc này, cái của em khác gì? Không có phần so sánh, bạn phải trả lời ứng khẩu.
Cách sửa
Chọn ba bốn giải pháp tiêu biểu, so sánh theo vài tiêu chí liên quan tới người dùng mục tiêu của bạn, trình bày bằng bảng. Hệ thống của bạn không cần hơn mọi mặt; nó chỉ cần có lý do tồn tại cho một nhóm người dùng cụ thể, ví dụ chủ trọ nhỏ không quen phần mềm phức tạp.
Khi so sánh, chỉ nêu những gì bạn đã kiểm tra được qua bản dùng thử hoặc tài liệu chính thức của sản phẩm đó, ghi nguồn và thời điểm xem. Nhận định kiểu “phần mềm X khó dùng” mà không có căn cứ dễ bị hội đồng hỏi ngược, và cũng không công bằng với người làm ra sản phẩm.
Lỗi 3, 4, 5: tóm tắt nhanh
Ba lỗi còn lại gắn với chương thiết kế, đánh giá và buổi trình diễn.
| Lỗi | Biểu hiện | Cách sửa |
|---|---|---|
| Ảnh chụp màn hình thay cho thiết kế | Chương thiết kế chủ yếu là ảnh giao diện, không có kiến trúc, dữ liệu, luồng xử lý | Bổ sung hình kiến trúc, lược đồ dữ liệu, biểu đồ tuần tự cho luồng khó; chuyển ảnh giao diện sang chương cài đặt và phụ lục |
| Không có đánh giá | Kết thúc bằng câu “hệ thống chạy ổn định” | Thêm bảng ca kiểm thử truy vết theo yêu cầu, đo vài yêu cầu phi chức năng, buổi dùng thử nhỏ |
| Mã không chạy trên máy hội đồng | Phụ thuộc phiên bản trên máy sinh viên, thiếu dữ liệu mẫu, cần mạng nội bộ | Đóng gói môi trường, có hướng dẫn chạy, dữ liệu mẫu, bản dự phòng chạy trên máy cá nhân |
Lỗi ít được nói tới: phạm vi và kết luận lệch nhau
Phạm vi hứa nhiều hơn làm
Phần mở đầu ghi hệ thống hỗ trợ nhiều chi nhánh, thanh toán trực tuyến, ứng dụng di động; chương cài đặt chỉ có ứng dụng web cho một chi nhánh. Hội đồng đối chiếu hai phần này rất nhanh. Cách sửa đơn giản là viết lại phạm vi cho khớp điều đã làm, chuyển phần còn lại sang hướng phát triển, thay vì cố làm thêm trong tuần cuối.
Kết luận khẳng định điều chưa đo
Câu như “hệ thống giúp cửa hàng tiết kiệm thời gian, tăng doanh thu” xuất hiện trong khi không có phép đo nào về thời gian hay doanh thu. Hoặc đo, dù chỉ đơn giản như bấm giờ một quy trình trước và sau khi có hệ thống với vài lượt thao tác, hoặc viết lại thành kỳ vọng có điều kiện.
Để phần mềm chạy được ở nơi khác máy bạn
Đóng gói môi trường
Ghi phiên bản mọi thư viện trong tệp khai báo phụ thuộc. Nếu hệ thống có nhiều thành phần (máy chủ ứng dụng, cơ sở dữ liệu, dịch vụ phụ), cân nhắc đóng gói bằng Docker để hội đồng hoặc chính bạn dựng lại được trên máy khác bằng vài lệnh. Thử dựng lại trên một máy sạch ít nhất một lần trước ngày bảo vệ.
Dữ liệu mẫu và tài khoản thử
Chuẩn bị tập dữ liệu mẫu đủ để trình diễn mọi chức năng chính, kèm tài khoản thử cho từng vai trò. Không dùng dữ liệu thật của người dùng trong buổi trình diễn.
Phương án dự phòng
Phòng bảo vệ có thể không có mạng, máy chiếu có thể không nhận độ phân giải. Mang theo bản ghi hình trình diễn các luồng chính, và kiểm tra phòng trước một ngày nếu được.
Tình huống: buổi chạy thử thất bại một tuần trước bảo vệ
Sự cố. Một nhóm hai sinh viên làm ứng dụng đặt món cho căng tin trường. Khi chạy thử ở phòng bộ môn, ứng dụng không kết nối được cơ sở dữ liệu vì cấu hình trỏ tới máy của một bạn trong nhóm.
Cách xử lý. Nhóm tách cấu hình ra tệp riêng, viết tệp Docker Compose dựng ứng dụng và cơ sở dữ liệu kèm dữ liệu mẫu, viết hướng dẫn chạy bốn bước, nhờ một bạn khác lớp làm theo trên máy của bạn ấy. Bạn ấy vướng ở bước cài đặt một gói, nhóm sửa hướng dẫn.
Ghi vào luận văn. Phụ lục có hướng dẫn cài đặt và phiên bản kho mã. Chương kết luận nhắc tới bài học về cấu hình môi trường như một hạn chế đã khắc phục.
Tự đọc bản thảo như một phản biện
Đặt bản thảo xuống hai ngày, rồi đọc lại với vai người chấm. Trả lời bằng văn bản từng câu.
- Bài toán là gì, cho ai, và vì sao các giải pháp đã có chưa đáp ứng được?
- Quyết định thiết kế quan trọng nhất là gì, đã cân nhắc phương án nào khác?
- Yêu cầu nào đã được kiểm thử, yêu cầu nào chưa?
- Phần nào do mình tự làm, phần nào dùng lại, đã ghi nhận đủ chưa?
- Nếu máy trình chiếu hỏng, mình trình diễn bằng cách nào?
Câu nào bạn trả lời không trôi, đó là chỗ phản biện thật sẽ hỏi. Sửa bản thảo cho tới khi câu trả lời nằm sẵn trong văn bản.
Các lỗi nhỏ nhưng làm mất ấn tượng
Sửa trong một buổi tối, nhưng để sót thì hội đồng nhìn thấy ngay.
- Thuật ngữ tiếng Anh và tiếng Việt dùng lẫn lộn không nhất quán cho cùng một khái niệm.
- Sơ đồ vẽ sai ký hiệu UML, mũi tên kế thừa và phụ thuộc lẫn nhau.
- Danh mục tài liệu tham khảo chỉ gồm đường dẫn trang hướng dẫn, thiếu tên tác giả và ngày truy cập.
- Ảnh giao diện có dữ liệu thử vô nghĩa hoặc dữ liệu thật của người khác.
- Phần kết luận hứa hẹn những tính năng không liên quan tới hạn chế đã nêu.
Câu hỏi thường gặp
Chương cơ sở lý thuyết của khoá luận CNTT nên dài bao nhiêu?
Không có con số chung; đủ để người đọc hiểu bài toán, các giải pháp đã có và lý do chọn công nghệ. Phần giới thiệu công nghệ phổ biến nên ngắn.
So sánh với phần mềm thương mại có cần dùng thử phần mềm đó không?
Nên dùng thử bản miễn phí hoặc bản dùng thử nếu có, và ghi rõ nguồn thông tin. Không đưa ra nhận định về tính năng bạn không kiểm tra được.
Hội đồng có yêu cầu chạy phần mềm trên máy của họ không?
Tuỳ hội đồng và quy định của trường. Thường bạn trình diễn trên máy mình, nhưng nên sẵn sàng dựng lại trên máy khác hoặc cung cấp hướng dẫn chạy.
Có cần dùng Docker cho khoá luận không?
Không bắt buộc. Docker giúp hệ thống nhiều thành phần dựng lại dễ hơn. Với ứng dụng đơn giản, tệp khai báo phụ thuộc và hướng dẫn chạy rõ ràng là đủ.
Dịch tài liệu công nghệ tiếng Anh sang tiếng Việt có phải ghi nguồn không?
Có. Dịch là dùng lại nội dung của người khác; cần ghi nguồn tài liệu gốc. Tốt hơn là tóm tắt ý cần dùng bằng lời của bạn và trích dẫn.
Còn hai tuần trước bảo vệ thì nên sửa lỗi nào trước?
Ưu tiên phần đánh giá và khả năng chạy trên máy khác, vì đây là thứ hội đồng kiểm tra trực tiếp. Sau đó rút gọn chương lý thuyết và bổ sung so sánh giải pháp.