Luận văn CNTT kiểu xây hệ thống thường có năm phần: mở đầu, cơ sở lý thuyết và công nghệ, phân tích yêu cầu, thiết kế, cài đặt và thử nghiệm, rồi kết luận. Mỗi sơ đồ phải phục vụ một quyết định; ảnh giao diện chỉ minh hoạ, không thay được thiết kế.
Người chấm luận văn CNTT đọc rất nhiều bản có cùng bộ khung, nên họ không tìm sự lạ mắt ở khung chương. Họ tìm ở bên trong: yêu cầu có đến từ người dùng thật không, thiết kế có lựa chọn và lý do không, thử nghiệm có đo điều đã hứa không. Dưới đây là khung phổ biến và cách lấp đầy từng chương cho đúng việc.
Khung chương thường gặp
Tên chương và số chương theo quy định của trường bạn; nội dung cốt lõi thì gần giống nhau ở nhiều nơi.
| Chương | Nội dung chính | Câu hỏi chương phải trả lời |
|---|---|---|
| Mở đầu | Bối cảnh, bài toán, mục tiêu, phạm vi, phương pháp, cấu trúc | Vì sao bài toán này cần giải, giải đến đâu? |
| Cơ sở lý thuyết và công nghệ | Khái niệm nghiệp vụ, giải pháp hiện có, công nghệ được chọn | Đã có những cách giải nào, vì sao chọn cách này? |
| Phân tích yêu cầu | Tác nhân, chức năng, yêu cầu phi chức năng, quy trình nghiệp vụ | Hệ thống phải làm gì, cho ai, với ràng buộc gì? |
| Thiết kế | Kiến trúc, dữ liệu, các thành phần chính, giao diện | Hệ thống được tổ chức thế nào, vì sao như vậy? |
| Cài đặt và thử nghiệm | Môi trường, các điểm cài đặt đáng chú ý, kiểm thử, kết quả | Hệ thống có làm đúng điều đã phân tích không? |
| Kết luận | Kết quả đạt được, hạn chế, hướng phát triển | Đã làm được gì, chưa làm được gì? |
Chương phân tích: sơ đồ nào thật sự cần?
Sơ đồ use case và đặc tả
Sơ đồ use case tổng quát cho thấy các tác nhân và nhóm chức năng. Nhưng phần có giá trị là đặc tả của vài use case chính: điều kiện trước, luồng chính, luồng thay thế, điều kiện sau. Đặc tả kỹ năm sáu use case quan trọng tốt hơn ba mươi sơ đồ use case con không có đặc tả.
Quy trình nghiệp vụ
Với hệ thống phục vụ một tổ chức, một sơ đồ hoạt động mô tả quy trình hiện tại và quy trình sau khi có hệ thống giúp người chấm thấy bạn thay đổi điều gì. Đây thường là sơ đồ bị bỏ qua nhưng thuyết phục nhất.
Yêu cầu phi chức năng phải đo được
“Hệ thống chạy nhanh, bảo mật” không phải yêu cầu. Viết thành “trang danh sách tải trong thời gian X giây với Y bản ghi trên máy chủ thử nghiệm” hoặc “mật khẩu được băm, phiên hết hạn sau Z phút không thao tác”. Con số do bạn đặt theo bài toán, và chương thử nghiệm sẽ đo lại đúng những con số đó.
Chương thiết kế: cho thấy quyết định, không chỉ kết quả
Kiến trúc
Một hình kiến trúc tổng thể kèm đoạn giải thích vì sao chọn kiến trúc đó: vì sao tách giao diện và máy chủ, vì sao chọn cơ sở dữ liệu quan hệ hay tài liệu, vì sao không dùng một phương án khác mà bạn đã cân nhắc. Một bảng so sánh hai ba phương án theo vài tiêu chí là cách trình bày gọn.
Thiết kế dữ liệu
Sơ đồ thực thể liên kết hoặc lược đồ quan hệ, kèm giải thích những chỗ không hiển nhiên: vì sao tách bảng này, vì sao lưu trường dư thừa này để tăng tốc truy vấn, ràng buộc toàn vẹn nào được đặt ở cơ sở dữ liệu và ràng buộc nào được kiểm ở tầng ứng dụng.
Biểu đồ lớp và tuần tự cho phần khó
Không cần biểu đồ tuần tự cho chức năng đăng nhập ai cũng biết. Hãy dành chúng cho luồng phức tạp nhất của hệ thống, ví dụ đặt lịch có kiểm tra trùng, hay đồng bộ dữ liệu khi thiết bị có mạng trở lại.
Chương mở đầu và cơ sở lý thuyết: viết gì cho đủ?
Mở đầu nói về bài toán, không nói về công nghệ
Đoạn bối cảnh nên mô tả tổ chức hoặc người dùng, quy trình hiện tại, chỗ đang tốn thời gian hay sai sót, và vì sao một hệ thống giúp được. Nhiều bản mở đầu bằng vài đoạn về sự phát triển của Internet và điện thoại thông minh; hội đồng bỏ qua những đoạn đó. Phạm vi cần ghi rõ cả điều không làm, ví dụ không tích hợp thanh toán, chỉ hỗ trợ một chi nhánh.
Cơ sở lý thuyết gồm ba phần
Thứ nhất, khái niệm nghiệp vụ cần thiết để hiểu bài toán, như quy trình nhập xuất kho hay quy tắc tính giá. Thứ hai, khảo sát các giải pháp hiện có, kể cả phần mềm thương mại hay mã nguồn mở, so sánh chúng theo vài tiêu chí để thấy chỗ trống mà hệ thống của bạn lấp. Thứ ba, công nghệ được chọn và lý do chọn, viết ngắn. Phần thứ hai thường bị bỏ quên dù đó là phần cho thấy bạn hiểu lĩnh vực.
Đưa vào thân hay để phụ lục?
Quy tắc chung: thân bài chứa thứ người đọc cần để hiểu và đánh giá; phụ lục chứa thứ cần để kiểm tra hoặc tái lập.
| Nội dung | Thân bài | Phụ lục |
|---|---|---|
| Sơ đồ use case tổng quát và đặc tả use case chính | Có | Đặc tả các use case phụ |
| Lược đồ cơ sở dữ liệu | Sơ đồ tổng quát và bảng chính | Từ điển dữ liệu đầy đủ từng trường |
| Ảnh giao diện | Vài màn hình tiêu biểu gắn với use case chính | Các màn hình còn lại |
| Ca kiểm thử | Bảng tổng hợp và các ca đáng chú ý | Danh sách đầy đủ ca kiểm thử |
| Mã nguồn | Đoạn ngắn minh hoạ ý chính | Đường dẫn kho mã hoặc trích đoạn dài hơn |
Chương cài đặt và thử nghiệm
Cài đặt: chọn điểm đáng nói
Không cần liệt kê từng thư viện hay từng tệp. Mô tả môi trường phát triển và triển khai, rồi trình bày hai ba điểm cài đặt khó nhất, có thể kèm đoạn mã ngắn hoặc giả mã. Ảnh giao diện đặt ở đây để minh hoạ use case đã phân tích, mỗi ảnh có chú thích nói người dùng đang làm gì.
Thử nghiệm: đối chiếu với phân tích
Mỗi yêu cầu chức năng chính có ca kiểm thử tương ứng, mỗi yêu cầu phi chức năng có phép đo tương ứng. Một bảng truy vết từ yêu cầu đến ca kiểm thử và kết quả giúp người chấm thấy vòng khép kín. Lỗi còn tồn tại được ghi trung thực.
Tình huống: một bản thảo nhiều ảnh, ít thiết kế
Bản thảo đầu. Một sinh viên làm hệ thống quản lý đặt sân bóng mini nộp chương thiết kế dài hai mươi trang, trong đó mười lăm trang là ảnh giao diện.
Góp ý. Người hướng dẫn hỏi: vì sao đặt sân theo khung giờ cố định thay vì giờ tự do, làm sao tránh hai người cùng đặt một khung giờ, giá theo giờ cao điểm lưu ở đâu. Không câu nào có trong bản thảo.
Bản sửa. Sinh viên chuyển phần lớn ảnh vào phụ lục, thêm mục giải thích mô hình khung giờ, một biểu đồ tuần tự cho luồng đặt sân có khoá bản ghi, một bảng so sánh hai cách lưu bảng giá. Chương ngắn lại nhưng hội đồng đọc thấy được tư duy thiết kế.
Bài học. Số trang không đo chất lượng thiết kế. Một trang giải thích vì sao chọn cách khoá bản ghi khi đặt sân có giá trị hơn mười trang ảnh giao diện, vì đó là câu hội đồng sẽ hỏi và là chỗ sinh viên chứng minh mình hiểu hệ thống từ bên trong. Trước khi nộp, thử tự hỏi với mỗi hình: nếu bỏ hình này đi, người đọc mất thông tin gì?
Câu hỏi thường gặp
Luận văn CNTT có bắt buộc dùng UML không?
Không phải mọi trường đều bắt buộc, nhưng UML là ngôn ngữ chung dễ hiểu với hội đồng. Điều quan trọng là sơ đồ đúng ký hiệu và phục vụ việc giải thích thiết kế.
Có cần chương cơ sở lý thuyết giới thiệu ngôn ngữ lập trình đã dùng không?
Không nên viết dài về những công nghệ phổ biến. Chỉ giới thiệu đủ để giải thích vì sao chọn, và dành chỗ cho phần so sánh giải pháp liên quan đến bài toán.
Nên đưa bao nhiêu ảnh giao diện vào thân luận văn?
Chỉ những màn hình gắn với use case chính, đủ để người đọc hình dung luồng thao tác. Phần còn lại đưa vào phụ lục.
Từ điển dữ liệu có cần trong luận văn không?
Nên có, thường đặt ở phụ lục, để hội đồng tra khi cần. Thân bài chỉ giữ sơ đồ tổng quát và giải thích các bảng quan trọng.
Đề tài thuật toán có dùng khung chương này không?
Không hoàn toàn. Đề tài thuật toán thường có chương bài toán và phương pháp, chương thực nghiệm và chương phân tích kết quả thay cho phân tích thiết kế hệ thống.
Viết phần hướng phát triển thế nào cho đúng?
Nêu những việc cụ thể còn thiếu và vì sao chưa làm, ví dụ chưa thử với số người dùng lớn. Tránh liệt kê tính năng mơ hồ không liên quan tới hạn chế đã nêu.