Trình bày đồ án như thế nào?

#sep490

Ngắn gọn

trình bày đủ (điểm 7) - chi tiết xem FLM và file rubric
có điểm nhấn để gây ấn tượng (điểm 8-9-10)

chi tiết

trước khi vào "how" ta quay lại một chút về "why"

Vì sao phải trình bày đồ án?

ở mức cơ bản nhất: phát hiện gian lận. nhóm sinh viên có thực sự là người làm ra sản phẩm này không? hay đi cóp ở đâu về, hay tệ hơn, thuê người làm hộ? cái này thì không có gì để bàn.
đánh giá năng lực diễn đạt: communication bạn có thể làm rất tốt, nhưng nếu không thể trình bày được sản phẩm của mình, vậy cần luyện trình bày cho đạt chuẩn thì mới có khả năng tham gia vào thị trường lao động, đừng có lý luận rằng "tôi chỉ biết làm, tôi không cần nói", không ai đòi hỏi bạn vừa phải code như 1 kỹ sư, vừa phải "nói như hát" ở tầm saleman, nhưng "nếu không thể trình bày" vậy thì có nghĩa là năng lực của bạn chưa đạt chuẩn, chưa đạt thì học lại cho đạt.
đánh giá tư duy: phản biện và bảo vệ quan điểm. bạn có đủ kiến thức, và tư duy để bảo vệ lập trường của mình không? hay ai nói gì cũng gật? nếu không đủ kiến thức, không đủ tư duy, vậy ở lại học thêm cho đủ rồi ra đi làm
góc nhìn đa chiều: tất cả developer, hay người làm kỹ thuật nói chung thường mắc phải nhược điểm lớn "sản phẩm của tôi là tuyệt vời", những nhận xét, góp ý của hội đồng phản biện, bao gồm các giảng viên (học thuật) và đại diện doanh nghiệp (thực tế) sẽ giúp các bạn mở rộng tầm suy nghĩ, nhận ra những lỗ hổng mà sinh viên chưa nghĩ tới (khả thi kinh tế, bảo mật, trải nghiệm người dùng v.v.)
cuối cùng: lễ trưởng thành trước buổi bảo vệ, bạn là "người học", sau buổi bảo vệ, bạn là đồng nghiệp với các kỹ sư (doanh nghiệp) và thầy cô của mình.

Vậy trình bày cái gì và như thế nào?

Nguyên tắc

không cần show hết, chỉ cần show những cái hay nhất
đồ án đó 5 sinh viên làm trong 3 tháng, nếu không thể trình bày trong 45p, vậy bạn trình bày chưa đạt.

OK, chốt lại cái dàn bài nó thế này

Intro (lựa chọn đề tài) : có lý do rõ ràng, có số liệu hỗ trợ, trình bày được 5 yếu tố
1. context (fact)
2. nỗi đau / cơ hội
3. nhu cầu / hệ thống đã có + ưu nhược
4. giải pháp
5. lợi ích dự kiến
Project management
1. mô hình & cách áp dụng mô hình vào trong dự án
2. vai trò trách nhiệm
3. cách quản lý code / docs trong dự án
4. ... other ..
Requirement
1. business workflow
2. use case diagram
3. ERD (optional)
4. Screen flow ( optional )
5. non functional requirement (optional)
Architect
1. overview technical
2. package diagram (MVC / 3 layers / microservices / clean architect / Dependency Injection / Domain Driven Design)
3. Database
4. deployment architect (optional)
Testing
1. Test plan: functional / nonfunctional unit + system + ?? công cụ / công nghệ test đơn giản: chrome + excel phức tạp: selenium + jmeter + junit + ...
2. quy trình quản lý bug
3. Test Result số lượng test case, phân bổ NAB số lượng bug
demo (20-25p)
nguyên tắc: bám theo business workflow, kể 1 câu chuyện vv user dùng hệ thống thì đạt được lợi ích gì?
1. negative cases không cần làm
2. những cái đơn giản quá: đăng ký / forgot password / view own profile : không cần
3. chuẩn bị demo data : file word text, folder images, không nhập những thứ vô nghĩa như "asdf" hay "testtest"
conclusion
1. mở bài (intro) hứa làm cái gì, đã làm được chưa?
2. tự nhận xét còn thiếu sót gì? kế hoạch tương lai để cải tiến ra sao?
3. học được gì qua dự án này