Nhiều bạn làm khóa luận phần mềm ngành CNTT biết mình sẽ xây một ứng dụng hay hệ thống cụ thể, nhưng không biết đóng khung phần lý luận thế nào để hội đồng công nhận đây là một nghiên cứu, không chỉ là một sản phẩm lập trình. Design Science Research (DSR) là khung phương pháp luận được xây dựng đúng cho việc này — có nguồn gốc học thuật rõ ràng, áp dụng được vào cấu trúc chương quen thuộc. Nếu đề tài của bạn bắt nguồn từ một đợt thực tập, bài báo cáo thực tập tốt nghiệp ngành CNTT chuyển thành khóa luận hướng dẫn cách chuyển đổi, còn bài này tập trung vào cách đóng khung phương pháp luận cho một sản phẩm phần mềm.
Design Science Research là gì và ai đề xuất khung này?
Design Science Research được hệ thống hóa bởi Alan R. Hevner, Salvatore T. March, Jinsoo Park và Sudha Ram trong bài báo «Design Science in Information Systems Research», đăng trên tạp chí MIS Quarterly năm 2004 (tập 28, số 1, trang 75-106). Khác với nghiên cứu khoa học hành vi (behavioral science) chỉ giải thích hoặc dự báo hiện tượng, DSR coi việc tạo ra một sản phẩm (artifact) — có thể là mô hình, phương pháp, hoặc một hệ thống phần mềm — chính là đóng góp nghiên cứu, miễn là sản phẩm đó giải quyết một vấn đề thực tế và được đánh giá nghiêm túc, thay vì chỉ được mô tả là «đã hoàn thành» mà không có bằng chứng nó hoạt động tốt hơn cách làm cũ.
Bảy nguyên tắc hướng dẫn của Hevner gồm những gì?
| Nguyên tắc | Ý nghĩa |
|---|---|
| 1. Design as an Artifact | Nghiên cứu phải tạo ra một sản phẩm cụ thể — mô hình, phương pháp, hoặc hệ thống |
| 2. Problem Relevance | Sản phẩm phải giải quyết một vấn đề thực tế và có ý nghĩa với tổ chức/người dùng |
| 3. Design Evaluation | Phải đánh giá sản phẩm một cách nghiêm túc bằng phương pháp phù hợp (thử nghiệm, khảo sát người dùng, đo hiệu năng) |
| 4. Research Contributions | Nghiên cứu phải có đóng góp rõ ràng cho sản phẩm, nền tảng lý thuyết, hoặc phương pháp thiết kế |
| 5. Research Rigor | Áp dụng phương pháp nghiêm ngặt trong cả việc xây dựng lẫn đánh giá sản phẩm |
| 6. Design as a Search Process | Thiết kế là một quá trình tìm kiếm lặp lại giữa các giải pháp khả thi, không phải làm đúng ngay từ lần đầu |
| 7. Communication of Research | Trình bày kết quả rõ ràng cho cả người làm kỹ thuật lẫn người quản lý/hội đồng không chuyên sâu kỹ thuật |
Không phải khóa luận nào cũng cần thỏa mãn đầy đủ và chi tiết cả bảy nguyên tắc như một bài báo học thuật đầy đủ — nhưng nêu rõ đã cân nhắc từng nguyên tắc, dù ngắn gọn, giúp chương cơ sở lý luận không chỉ là mô tả công nghệ mà thể hiện được tư duy nghiên cứu. Nếu chưa chọn được đề tài phần mềm cụ thể, bài đề tài đồ án tốt nghiệp ngành Công nghệ thông tin có 30 hướng chốt được trong hai tuần để tham khảo trước khi áp dụng khung DSR này.
Ánh xạ DSR vào cấu trúc năm chương của khóa luận Việt Nam thế nào?
Cấu trúc chương quen thuộc (Mở đầu — Cơ sở lý luận — Phương pháp — Kết quả/Triển khai — Kết luận) có thể ánh xạ trực tiếp vào chu trình DSR: Chương 1 (Mở đầu) nêu vấn đề thực tế cần giải quyết (Problem Relevance); Chương 2 (Cơ sở lý luận) trình bày các giải pháp/công nghệ nền tảng đã có và khoảng trống chưa được giải quyết; Chương 3 (Phương pháp) mô tả quy trình thiết kế sản phẩm — đây chính là nơi trình bày chu trình tìm kiếm lặp lại (Design as a Search Process), gồm các phiên bản thử nghiệm trước khi đến bản cuối; Chương 4 (Kết quả/Triển khai) trình bày sản phẩm hoàn chỉnh và kết quả đánh giá (Design Evaluation) — kiểm thử chức năng, đo hiệu năng, hoặc khảo sát người dùng thử; Chương 5 (Kết luận) nêu rõ đóng góp của sản phẩm (Research Contributions) và hạn chế.
Ví dụ minh họa áp dụng DSR vào một đề tài CNTT cụ thể trông như thế nào?
Ví dụ minh họa (giả định) cho đề tài xây dựng một hệ thống quản lý đặt lịch khám bệnh cho phòng khám tư nhân quy mô nhỏ: vấn đề thực tế (Problem Relevance) là phòng khám hiện đặt lịch qua điện thoại, gây nhầm lẫn và quá tải giờ cao điểm; sản phẩm (Artifact) là một ứng dụng web đặt lịch trực tuyến; quy trình thiết kế (Search Process) gồm ba phiên bản thử nghiệm, mỗi phiên bản được góp ý bởi nhân viên phòng khám trước khi hoàn thiện; đánh giá (Evaluation) gồm kiểm thử chức năng và khảo sát mức độ hài lòng của nhân viên/bệnh nhân dùng thử; đóng góp (Contribution) là quy trình số hóa đặt lịch có thể áp dụng cho các phòng khám quy mô tương tự, không chỉ riêng phòng khám đã thử nghiệm. Điểm quan trọng cần lưu ý trong ví dụ này: đóng góp không nằm ở việc «tôi đã viết được một ứng dụng» mà nằm ở quy trình và bài học rút ra được — điều gì khiến phiên bản 1 và 2 chưa đạt yêu cầu của nhân viên phòng khám, và những điều chỉnh nào ở phiên bản 3 đã giải quyết được vấn đề đó. Đây chính là phần thường bị bỏ sót nhất khi sinh viên chỉ nộp sản phẩm cuối cùng mà không kể lại quá trình tìm kiếm giải pháp.
Đóng khung đúng phương pháp luận cho một khóa luận phần mềm là bước quyết định để hội đồng công nhận đây là nghiên cứu, không chỉ là bài tập lập trình. Tesify giúp bạn viết nhanh hơn các chương lý luận và phương pháp trong khi bạn vẫn là người xây dựng sản phẩm và chịu trách nhiệm về nội dung khóa luận.
Hỏi đáp về Design Science Research trong khóa luận ngành CNTT
DSR có bắt buộc dùng cho mọi khóa luận phần mềm không?
Không bắt buộc — nếu khóa luận chỉ đơn thuần lập trình lại một hệ thống có sẵn không giải quyết vấn đề mới, DSR có thể không phù hợp. DSR phát huy tác dụng tốt nhất khi sản phẩm giải quyết một vấn đề thực tế chưa có giải pháp tốt.
Khác biệt giữa DSR và chọn hướng «luận văn dự án phần mềm» là gì?
«Luận văn dự án phần mềm» (so với luận văn truyền thống) là một lựa chọn về định dạng của khóa luận, được bàn trong bài luận văn dự án phần mềm hay luận văn truyền thống cho ngành Khoa học dữ liệu; DSR là một khung phương pháp luận để đóng khung nội dung lý luận và phương pháp bên trong một khóa luận dự án phần mềm đã chọn — hai quyết định này bổ sung cho nhau, không thay thế nhau. Kế hoạch thời gian cho từng giai đoạn thiết kế lặp lại cũng nên được lập cụ thể, xem thêm bài so sánh 3 kế hoạch thời gian làm luận văn ngành Khoa học dữ liệu.
Có cần đọc toàn bộ bài báo gốc của Hevner không?
Nên đọc ít nhất phần tóm tắt và phần bảy nguyên tắc hướng dẫn, vì đây là phần được trích dẫn nhiều nhất và áp dụng trực tiếp vào khóa luận — không nên chỉ trích dẫn tên khung mà không hiểu nội dung bảy nguyên tắc.
Sản phẩm phần mềm cần đạt mức độ hoàn thiện nào để được coi là một Artifact hợp lệ?
Không cần là sản phẩm thương mại hoàn chỉnh — một nguyên mẫu (prototype) chức năng đầy đủ cho các tình huống sử dụng chính đã đủ để đánh giá, miễn là được mô tả trung thực về mức độ hoàn thiện, không phóng đại thành sản phẩm sẵn sàng triển khai thực tế nếu chưa đạt đến đó.
Có cần dùng đúng thuật ngữ tiếng Anh của Hevner hay có thể dịch sang tiếng Việt?
Có thể dịch sang tiếng Việt (ví dụ «sản phẩm thiết kế» cho Artifact) miễn là nhất quán trong toàn bài, nhưng nên giữ thuật ngữ gốc trong ngoặc đơn ở lần xuất hiện đầu tiên để hội đồng dễ đối chiếu với tài liệu gốc.
Đánh giá sản phẩm (Design Evaluation) có nhất thiết phải là khảo sát người dùng không?
Không — có thể là kiểm thử chức năng, đo hiệu năng kỹ thuật (thời gian phản hồi, độ chính xác), hoặc so sánh với giải pháp hiện có, tùy loại sản phẩm và câu hỏi nghiên cứu, không nhất thiết phải qua khảo sát người dùng. Ví dụ, một hệ thống xử lý dữ liệu nội bộ có thể đánh giá bằng độ chính xác và tốc độ xử lý so với quy trình thủ công trước đó, trong khi một ứng dụng hướng người dùng cuối thường cần thêm khảo sát mức độ dễ sử dụng để đánh giá đầy đủ.
Có thể áp dụng DSR cho một đề tài không phải phần mềm không?
Có — DSR ban đầu áp dụng cho hệ thống thông tin, nhưng khung tương tự cũng phù hợp cho các sản phẩm thiết kế khác (mô hình, quy trình, phương pháp) miễn là sản phẩm giải quyết một vấn đề thực tế và được đánh giá nghiêm túc.
Nếu chu trình thiết kế chỉ có một phiên bản (không lặp lại) thì có được không?
Được, nhưng nên nêu rõ đây là giới hạn về thời gian của một khóa luận đại học trong phần hạn chế nghiên cứu, vì nguyên tắc Design as a Search Process trong khung gốc khuyến khích quá trình lặp lại nhiều vòng.
DSR có phải là khung duy nhất cho khóa luận phần mềm không?
Không — một số khóa luận chọn khung phát triển phần mềm thông thường (ví dụ mô hình thác nước hoặc Agile/Scrum) để mô tả quy trình kỹ thuật, không đóng khung theo hướng nghiên cứu học thuật. DSR phù hợp hơn khi khóa luận cần nhấn mạnh đóng góp nghiên cứu bên cạnh sản phẩm kỹ thuật, còn Agile/Scrum phù hợp hơn khi trọng tâm là mô tả quy trình quản lý dự án.
Có cần trình bày cả bảy nguyên tắc thành bảy mục riêng trong khóa luận không?
Không bắt buộc phải tách thành bảy mục riêng biệt — có thể lồng ghép các nguyên tắc vào đúng chương tương ứng theo cách ánh xạ đã nêu ở trên, miễn là người đọc nhận ra được từng nguyên tắc đã được cân nhắc ở đâu trong bài, không cần liệt kê máy móc theo đúng thứ tự bảy nguyên tắc gốc.