|
| Sinh viên FPTU báo cáo dự án SWP391 trước hội đồng giảng viên |
Trong hành trình học tập ngành Công nghệ Thông tin tại Đại học FPT, kỳ 5 thường được xem là một “bước ngoặt” khi sinh viên lần đầu phải thực hiện một dự án phần mềm hoàn chỉnh trong môn SWP391 - Software Development Project. Đây không phải một môn lý thuyết hay thi viết, mà là môn thiên về thực hành, yêu cầu cả nhóm áp dụng toàn bộ kiến thức đã học để xây dựng sản phẩm và báo cáo kết quả cuối môn trước hội đồng giảng viên.
Buổi báo cáo hội đồng SWP391 chính là cột mốc quan trọng, quyết định phần lớn điểm số cuối kỳ. Đây không chỉ là nơi bạn và nhóm thể hiện sản phẩm đã làm, mà còn là bài kiểm tra kỹ năng làm việc nhóm, trình bày dự án, demo hệ thống và trả lời phản biện trực tiếp.
Là người từng trải qua buổi báo cáo này và đạt 8.8 điểm, có thể nó sẽ không cao bằng những bạn khác hoặc có thể cao hơn, nhưng mình không lấy nó ra so sánh, mình muốn chia sẻ lại kinh nghiệm báo cáo SWP391 một cách chân thực và dễ áp dụng. Bài viết này trên TruongDevs sẽ chia sẻ cho bạn từng bước, từ chuẩn bị nội dung, thiết kế slide, cách thuyết trình đến xử lý câu hỏi từ hội đồng, để tự tin hơn và nâng cao cơ hội đạt điểm cao.
Giới thiệu chung về môn SWP391 và buổi báo cáo hội đồng
 |
| Môn SWP391 yêu cầu báo cáo trước hội đồng để đánh giá toàn diện kỹ năng lập trình, quản lý dự án và thuyết trình của sinh viên |
Môn SWP391 - Software Development Project tại kỳ 5 được xem như “bài test thực chiến” đầu tiên của sinh viên ngành Công nghệ Thông tin tại FPTU. Khác với các môn lý thuyết trước đó, SWP391 yêu cầu sinh viên áp dụng toàn bộ kiến thức về phân tích yêu cầu, thiết kế hệ thống, lập trình và kiểm thử để phát triển một dự án phần mềm hoàn chỉnh trong suốt học kỳ.
Điểm số của môn học này phần lớn được quyết định bởi buổi báo cáo hội đồng cuối môn, nơi nhóm sinh viên phải trình bày toàn bộ quá trình và kết quả dự án trước giảng viên và hội đồng phản biện. Buổi báo cáo thường bao gồm ba phần chính:
- Thuyết trình nội dung dự án: Giới thiệu sản phẩm, kiến trúc hệ thống, quy trình phát triển và những giá trị thực tế mà dự án mang lại.
- Demo sản phẩm trực tiếp: Trình diễn các chức năng chính, kiểm chứng tính ổn định và mức độ hoàn thiện của phần mềm.
- Phần hỏi - đáp phản biện: Giảng viên sẽ đặt câu hỏi về kỹ thuật, quy trình làm việc và những điểm cần cải thiện để đánh giá khả năng hiểu sâu và xử lý vấn đề của cả nhóm.
Là người từng trải qua kỳ báo cáo này, mình hiểu rõ áp lực và những khó khăn mà các nhóm thường gặp phải. Chính vì vậy, bài viết này được viết để chia sẻ kinh nghiệm báo cáo SWP391 thực tế, giúp bạn tránh những sai lầm phổ biến, chuẩn bị nội dung tốt hơn và tạo ấn tượng mạnh với hội đồng chấm điểm.
Câu chuyện chuẩn bị báo cáo của nhóm mình
 |
| Nhóm mình đã dành nhiều thời gian chuẩn bị kỹ lưỡng trước ngày báo cáo SWP391, phân công nhiệm vụ rõ ràng để buổi bảo vệ diễn ra suôn sẻ |
Nhóm mình báo cáo môn SWP391 - Software Development Project vào ngày 25/07/2025, và thật sự khoảng thời gian trước buổi báo cáo là những giờ phút căng thẳng nhưng đáng nhớ nhất của kỳ này. Vì là nhóm báo cáo đầu tiên của đợt 1 (nghe nói hình như cũng là nhóm duy nhất báo cáo ngay lần 1, nhưng mình không dám khẳng định), nên áp lực càng lớn - vừa không có nhóm nào báo cáo trước để tham khảo, vừa phải đảm bảo buổi thuyết trình thật chỉn chu.
Họp nhóm “chạy nước rút” đêm trước báo cáo
Tối hôm 24/07, cả nhóm hẹn nhau họp gấp để chạy toàn bộ project từ A-Z. Chúng mình mở lần lượt từng chức năng, test đi test lại từng luồng nghiệp vụ và luồng dữ liệu để đảm bảo demo ngày mai không gặp sự cố. Trong quá trình chạy thử, vẫn phát hiện một vài điểm xử lý chưa thật logic, một số nút chức năng chưa hiển thị đúng mong đợi. Cả nhóm quyết định ngồi lại chỉnh sửa ngay trong đêm, làm cho tới khi mọi thứ hoàn thiện hơn mới dám nghỉ.
Lúc đó ai cũng mệt, nhưng nghĩ đến việc sáng hôm sau đứng trước hội đồng giảng viên, không ai muốn phần trình bày của nhóm bị “vấp” vì một lỗi nhỏ. Chính sự kỹ tính này đã giúp nhóm tự tin hơn rất nhiều.
Có mặt sớm để setup và ổn định tinh thần
Ca thi của nhóm là 7:30 - 12:00, nhưng cả nhóm quyết định 6:15 sáng đã có mặt tại phòng báo cáo. Việc đi sớm giúp chúng mình:
- Setup máy tính, kiểm tra máy chiếu và đường truyền.
- Chạy thử project một lần nữa trên máy của phòng để đảm bảo môi trường chạy ổn định.
- Chuẩn bị slide, sắp xếp thứ tự chỗ ngồi, bàn giao thiết bị và làm quen không khí phòng báo cáo.
Chính nhờ sự có mặt sớm, khi bước vào giờ báo cáo chính thức, nhóm không bị lúng túng hay vội vàng. Tinh thần thoải mái hơn, tự tin hơn để bắt đầu.
Thời lượng báo cáo và cảm nhận cá nhân
Nhóm mình trình bày tổng cộng 1 tiếng 15 phút, bao gồm phần giới thiệu dự án, demo hệ thống và trả lời câu hỏi từ hội đồng. Vì là nhóm đầu tiên, mọi thứ khá áp lực, nhưng nhờ chuẩn bị kỹ và chia phần rõ ràng nên buổi báo cáo diễn ra suôn sẻ. Cảm giác sau khi hoàn thành vừa mệt vừa nhẹ nhõm, và khi nhận kết quả điểm ngoài mong đợi, ai cũng thấy công sức cả nhóm bỏ ra xứng đáng.
Ở các phần tiếp theo, mình sẽ chia sẻ chi tiết hơn về slide nhóm đã chuẩn bị, kịch bản thuyết trình, các câu hỏi giảng viên đưa ra và cách chúng mình trả lời, để các bạn khóa sau có thêm kinh nghiệm thực tế khi đến lượt báo cáo SWP391.
Slide và kịch bản thuyết trình của nhóm mình
Để buổi báo cáo SWP391 - Software Development Project diễn ra suôn sẻ, nhóm mình đã dành khá nhiều thời gian chuẩn bị slide và xây dựng kịch bản thuyết trình rõ ràng, tránh tình trạng lúng túng hoặc bỏ sót nội dung khi đứng trước hội đồng.
Chuẩn bị slide, ngắn gọn, rõ ý, dễ theo dõi
Ngay từ khi bắt tay vào làm slide, nhóm mình đã thống nhất quan điểm: slide chỉ là công cụ hỗ trợ, không phải “bản Word phóng to” để đọc cho hội đồng nghe. Sau vài lần chỉnh sửa và tinh gọn nội dung, chúng mình chốt bố cục slide xoay quanh các phần chính sau:
- Giới thiệu dự án: Trình bày rõ tên đề tài và tên hệ thống (vì hai phần này dễ bị nhầm lẫn nếu không tách bạch). Kèm theo đó là mục tiêu và vấn đề thực tế mà dự án hướng tới giải quyết.
- Kiến trúc và công nghệ sử dụng: Mô tả tổng quan cách hệ thống hoạt động thông qua biểu đồ kiến trúc. Chỉ nêu những công nghệ quan trọng, đủ để hội đồng hình dung nền tảng chúng mình dùng để xây dựng sản phẩm.
- Chức năng chính: Chia thành từng module riêng, kèm hình ảnh giao diện minh họa để hội đồng dễ hình dung luồng sử dụng và trải nghiệm người dùng.
- Kết quả đạt được và hướng phát triển: Nêu rõ những tính năng đã hoàn thành, các giới hạn hiện tại và định hướng nâng cấp dự án trong tương lai.
Phân vai và kịch bản báo cáo
Nhóm mình thống nhất phương án trình bày rõ ràng để buổi báo cáo không bị lộn xộn. Phần slide tổng quan dự án được giao cho một thành viên thuyết trình xuyên suốt, đảm bảo mạch nội dung liền mạch và không bị ngắt quãng. Khi bước sang phần demo, ai phụ trách chức năng nào sẽ trực tiếp trình bày và demo chức năng đó, vừa cụ thể vừa đúng chuyên môn từng người đảm nhiệm.
- Trước ngày báo cáo, nhóm đã xây dựng kịch bản chi tiết cho toàn bộ buổi thuyết trình:
- Xác định luồng demo theo thứ tự hợp lý, tránh nhảy qua nhảy lại giữa các role.
- Chuẩn bị sẵn các tài khoản đăng nhập cho từng vai trò, thậm chí sử dụng chế độ ẩn danh hoặc mở sẵn nhiều tab để không mất thời gian đăng xuất - đăng nhập liên tục.
- Chốt rõ lời dẫn, thời điểm chuyển slide, thời điểm demo và ai trả lời phần nào nếu hội đồng đặt câu hỏi.
Nhờ vậy, cả buổi báo cáo chạy gọn trong 1 giờ 15 phút, không bị trùng lặp nội dung hay lúng túng khi chuyển phần, tạo cảm giác chuyên nghiệp và tự tin trước hội đồng.
Bài học rút ra
Nhìn lại, mình thấy việc chuẩn bị slide và kịch bản trước ít nhất 1-2 ngày là điều cần thiết. Nếu để sát ngày mới làm, sẽ rất dễ rơi vào tình trạng rối rắm, thiếu liên kết giữa các thành viên. Nhóm mình nhờ chuẩn bị kỹ, mỗi người biết phần của mình và hiểu tổng thể dự án nên khi giảng viên hỏi, ai cũng có thể trả lời, không phụ thuộc một người duy nhất.
Trong phần tiếp theo, mình sẽ kể chi tiết hơn về phần hỏi đáp (Q&A) với hội đồng, những câu hỏi nhóm mình nhận được và cách chúng mình xử lý, để các bạn khóa sau có thể tham khảo và chuẩn bị trước.
Những câu hỏi giảng viên hỏi và cách nhóm mình trả lời
 |
| Nhóm mình đã tổng hợp các câu hỏi thường gặp và cách trả lời rõ ràng, logic để ghi điểm trước hội đồng trong báo cáo SWP391. |
Nhóm mình gặp khá nhiều câu hỏi “xoáy” từ hội đồng, đa phần liên quan tới logic hệ thống đặt vé xe và tính thực tế khi vận hành. Nhờ đã chuẩn bị trước và hiểu rõ từng chức năng, chúng mình cố gắng trả lời rõ ràng, dù có vài điểm còn chưa hoàn thiện.
Các câu hỏi nổi bật trong buổi bảo vệ
Lỗi hiển thị Check-in / Check-out
Giảng viên hỏi về việc logic hiển thị không nhất quán giữa tài xế và nhân viên khi thao tác check-in, check-out. Chúng mình giải thích đang lưu trạng thái cơ bản nhưng chưa có chức năng xem lại lịch sử trên cả 2 phía. Nhóm ghi nhận đây là điểm thiếu sót cần bổ sung.
Xử lý khi hủy chuyến phụ thuộc quá nhiều vào tài xế
Hội đồng hỏi nếu tài xế hủy chuyến thì các bên khác (staff/admin) có được thông báo và xử lý tiếp theo như thế nào. Thực tế, hiện tại hệ thống cho phép tài xế hủy và staff xác nhận nhưng chưa có quy trình rõ ràng nếu driver tự ý hủy. Chúng mình trả lời đây là logic chưa xử lý xong, sẽ bổ sung bước xác nhận 2 chiều và thông báo đồng bộ sau này.
Staff Invoice Incident có được đánh giá sao không?
Câu hỏi về việc incident có phản ánh vào phần đánh giá sao của chuyến xe. Hiện tại nhóm chưa tích hợp, chỉ ghi nhận incident ở mức thông tin nội bộ. Chúng mình thừa nhận tính năng này chưa hoàn thiện.
Quản lý tuyến đường (Manage Routes)
Giảng viên hỏi hệ thống tính toán thời gian giữa các điểm dừng như thế nào (VD: Cần Thơ - Hậu Giang mất bao lâu). Chúng mình trả lời hiện tại dữ liệu này lưu cố định trong code, chưa đồng bộ với DB, và chưa có công thức tính động theo thực tế di chuyển. Đây là điểm nhóm dự kiến cải thiện.
Mã thanh toán giả lập
Hội đồng hỏi tại sao mã thanh toán không quyết định tình trạng đặt vé. Chúng mình trả lời do chưa tích hợp cổng thanh toán thật, phần này chỉ giả lập để hoàn thành chức năng cơ bản.
Thông báo đặt vé thành công không đẩy lên đầu trang chủ
Giảng viên góp ý UX chưa tốt. Chúng mình ghi nhận và hứa bổ sung phần hiển thị nổi bật hơn.
Cancel Request - xử lý chưa rõ ràng
Khi hủy vé, hệ thống thiếu thông báo về việc driver đã đồng ý hay chưa. Chúng mình giải thích logic này chưa được triển khai triệt để, cần bổ sung trạng thái trung gian để tránh mâu thuẫn dữ liệu.
Các tình huống thực tế của tài xế
Giảng viên đặt tình huống: nếu khách xuống trạm dừng rồi bị lỡ chuyến (đi vệ sinh, ra trễ) thì driver lưu trạng thái như thế nào? Hiện tại hệ thống chưa hỗ trợ ghi chú linh hoạt trong check-in/out, cần nâng cấp để ghi nhận trường hợp này.
Use Case, ERD, SDS
- Use Case: Một số chức năng thiếu trong sơ đồ, view trip detail không nằm trong use case của guest, bus ticket không nằm dưới manage ticket,…
- ERD: Chưa chuẩn hóa, thiếu khóa ngoại, ký hiệu sai.
- SDS: Một số bước trong flow chưa rõ đích đến, ID và liên kết DB chưa thống nhất.
Chúng mình trả lời trung thực, thừa nhận còn nhiều lỗi về thiết kế của mình và lấy đó làm bài học để khắc phục và sửa lỗi.
Kinh nghiệm nhóm mình rút ra
- Không chỉ biết code, mà phải hiểu logic thực tế của ngành vận tải, từ việc tính giờ, xử lý hủy chuyến đến trải nghiệm người dùng.
- Chuẩn bị trước câu hỏi logic, vì hội đồng thường xoáy vào các tình huống thực tế hơn là lý thuyết.
- Demo trên mobile và nhiều role trước, tránh bị “bắt bài” khi giảng viên test ngoài kịch bản.
- Không ngại thừa nhận lỗi, nhưng phải kèm phương án khắc phục để thể hiện tinh thần cầu thị và hiểu vấn đề.
Lời khuyên để báo cáo SWP391 đạt kết quả tốt
 |
| Một số lời khuyên quan trọng giúp nhóm bạn trình bày tự tin, trả lời câu hỏi mạch lạc và đạt điểm cao trong buổi báo cáo SWP391. |
Qua trải nghiệm thực tế báo cáo SWP391 của nhóm mình, mình nhận ra rằng điểm cao không chỉ phụ thuộc vào project chạy được, mà còn nằm ở cách chuẩn bị, trình bày và xử lý câu hỏi của hội đồng. Dưới đây là những kinh nghiệm mình đúc kết - có thể áp dụng cho hầu hết các hệ thống, không chỉ riêng hệ thống đặt vé xe:
Hiểu dự án của bạn như một sản phẩm thật
Đừng dừng lại ở việc “làm đúng yêu cầu đề bài”, hãy đặt mình vào vai người dùng cuối và khách hàng thật sự để thấy các tình huống thực tế có thể xảy ra.
Nếu hệ thống bạn liên quan đến quy trình nghiệp vụ (bán hàng, vận tải, quản lý kho, học trực tuyến,…), cần hiểu rõ logic vận hành ngành đó để trả lời khi giảng viên “xoáy”.
Chuẩn bị kỹ trước ngày báo cáo
- Họp nhóm và chạy thử toàn bộ flow ít nhất 1-2 lần trước báo cáo. Chạy cả các luồng chính, luồng phụ, luồng lỗi để tránh bất ngờ khi giảng viên test ngoài kịch bản.
- Kiểm tra giao diện trên nhiều thiết bị (PC, laptop, mobile) nếu hệ thống hỗ trợ responsive.
- Chuẩn bị dữ liệu test rõ ràng, đủ các role để chuyển đổi nhanh khi demo.
Slide và demo ngắn gọn - logic - dễ theo dõi
- Slide là điểm tựa, không phải bản word đọc lại. Giữ khoảng 20-25 slide, chữ ít, hình ảnh nhiều.
- Màu sắc slide nên đồng bộ với giao diện sản phẩm để tạo cảm giác chuyên nghiệp.
- Demo nên bám sát use case quan trọng trước, tránh lan man khiến hết giờ mà chưa trình bày xong điểm mạnh của hệ thống.
Phân vai và kịch bản rõ ràng
- Có một leader dẫn dắt tổng quan, sau đó chuyển phần demo cho từng thành viên phụ trách module.
- Luyện tập cách “chuyền bóng” giữa các thành viên để mạch thuyết trình không bị ngắt.
- Chuẩn bị tài khoản đăng nhập sẵn để không mất thời gian đăng xuất - đăng nhập nhiều lần.
Dự đoán trước câu hỏi và câu trả lời
- Hội đồng thường xoáy vào logic hệ thống, các tình huống thực tế, khả năng xử lý lỗi, bảo mật, phân quyền, dữ liệu,…
- Liệt kê các câu hỏi tiềm năng và phân công ai trả lời câu nào để không lúng túng.
- Nếu câu trả lời chưa làm được, thành thật nhận lỗi và đưa phương án khắc phục, thay vì trả lời vòng vo.
Chú ý tài liệu và thiết kế
- Use Case, ERD, SDS, GL… phải đầy đủ chức năng, thống nhất tên gọi, khóa chính - khóa ngoại, dữ liệu liên kết chặt chẽ.
- Tránh “bản vẽ cho có”, vì hội đồng rất hay bắt lỗi thiết kế trước khi nhìn vào code.
- Hình ảnh trong tài liệu không bị vỡ, căn lề đẹp để tạo cảm giác chỉn chu.
Thái độ và teamwork trong buổi báo cáo
- Giữ tinh thần bình tĩnh, tự tin, đừng hoảng loạn nếu bị hỏi khó.
- Không cắt lời nhau khi trả lời giảng viên, để leader kiểm soát luồng chính.
- Mỗi thành viên phải nắm tổng quan dự án, không chỉ biết phần mình làm.
Một buổi báo cáo SWP391 đạt kết quả tốt cần sự kết hợp của chất lượng hệ thống, cách trình bày, và độ chín trong xử lý tình huống. Điểm số cao không phải do “may mắn”, mà đến từ chuẩn bị kỹ lưỡng và teamwork ăn ý.
Kết luận
Báo cáo cuối kỳ SWP391 là một trải nghiệm vừa áp lực vừa đáng nhớ, khi đây là môn kiểm tra toàn bộ quá trình phát triển phần mềm của nhóm trong kỳ học. Nhóm mình đạt điểm khá cao nhờ sự chuẩn bị kỹ lưỡng, teamwork ăn ý và không ngại “chạy thử, chỉnh sửa đến phút cuối cùng” trước giờ bảo vệ.
Mình chia sẻ những kinh nghiệm báo cáo SWP391 này với mong muốn giúp các bạn khóa sau tự tin hơn, tránh lặp lại những lỗi mà nhóm mình và nhiều nhóm khác từng gặp.
Nếu thấy bài viết hữu ích, hãy để lại bình luận hoặc câu hỏi bên dưới, mình sẽ giải đáp chi tiết về cách chuẩn bị, xây dựng kịch bản báo cáo và xử lý câu hỏi từ hội đồng, dựa trên trải nghiệm thực chiến của nhóm mình.
Đừng quên chia sẻ bài viết này cho bạn bè cùng lớp, để cả nhóm đều nắm được các mẹo quan trọng, giúp buổi báo cáo SWP391 diễn ra trôi chảy và đạt điểm cao nhất nhé!
