Skip to main content

Kinh nghiệm thực hiện Khóa luận Tốt nghiệp



Bài viết này chủ yếu là dành cho các bạn sinh viên UIT. Đặc biệt là khoa Hệ thống Thông tin vì đặc thù và tính chất mỗi khoa khác nhau nên bài viết chỉ có tính chất tham khảo đối với những sinh viên khoa khác.
Bài viết này mình xin được chia sẻ từ trước khi bắt đầu đến sau khi kết thúc của một khóa luận tốt nghiệp.
  1. Chọn đề tài.
  2. Giáo viên hướng dẫn.
  3. Thực hiện.
  4. Báo cáo.
  5. Phản biện.
  6. Hội đồng.
  7. Kết.
  8. Tài liệu tham khảo.

Chọn đề tài.

Việc chọn đề tài cũng vừa dễ mà vừa khó. Ở đây thì sẽ có 2 hình thức để mình chọn, đó là:
  • Thực hiện đề tài mà giảng viên (GV) đưa ra.
  • Thực hiện đề tài do chính bạn hoặc nhóm sinh thực hiện đề ra.
Đối với hình thứ đầu tiên thì khá dễ dàng. Đợi đến ngày khoa công bố danh sách các đề tài thì mình thấy cái nào hay, phù hợp hoặc thích làm với GV nào thì mình chọn. Sau đó, chủ động liên hệ với GV để xem được hướng dẫn hay không? Nếu được thì sẽ làm việc với GV để lấy các yêu cầu cụ thể. Mọi thắc mắc, trong quá trình làm thì cứ tìm GVHD mà hỏi.
Đối với hình thức thứ hai, mình phải chủ động hơn rất nhiều. Từ việc ra ý tưởng thực hiện, mục đích, chọn GV, đề cương, v.v... Tất cả đều phải tự làm hết. Nhưng đối với bản thân thì mình thích làm điều mà mình muốn hơn vì khi đó, trách nhiệm của bản thân sẽ cao hơn, không ỷ lại vào người khác.
Chọn đề tài thế nào thì chỉ có bạn mới biết bạn muốn làm gì, thích gì. Nhưng mình chia sẻ các hướng mà bạn có thể chọn.
  • Nghiên cứu thuật toán để làm các ứng dụng khuyến nghị, dự đoán...
  • Viết ứng dụng quản lý.
  • Vừa nghiên cứu quy trình vừa nghiên cứu công nghệ (giống nhóm mình :D).
Lưu ý: Đối với khoa HTTT thì quy trình lúc nào cũng phải đặt ưu tiên hàng đầu. Công nghệ chỉ là phần điểm công thêm thôi. Cho nên phải đầu tư nghiên cứu sâu về quy trình nhiều hơn.
Sau đó là viết đề cương chi tiết (kế hoạch chi tiết) thực hiện đề tài. (đề cương tham khảo)

Giáo viên hướng dẫn

Chọn GVHD là một việc rất quan trọng. Vì GVHD sẽ là người la bạn, làm khó bạn, cho bạn đóng góp và cuối cùng là ... nâng đỡ cho bạn. Bởi người ta thường nói "thương cho roi cho vọt mà".
Hầu hết, các GV trong khoa thì không giỏi về công nghệ (xin lỗi thầy/cô nào nếu lỡ đọc chỗ này) nhưng về quy trình, phát hiện điểm yếu của đề tài và đưa ra gợi ý thì rất giỏi. Cho nên bạn nên chuẩn bị sẵn tâm lý là nếu làm về công nghệ là phải tự mày mò.
Trước khi ra quyết định chọn GV nào, thì bạn phải hỏi thăm một số anh/chị khóa trước xem GV nào mạnh về mảng nào rồi đưa ra quyết định. Bên cạnh đó, bạn phải xác định mình mạnh/yếu ở điểm nào để GV bổ sung các khuyết điểm đó cho bạn. Đây là yếu tố ưu tiên hàng của mình khi chọn GVHD. Ngoài ra, nếu bạn thân với GV nào thì đó cũng là một chọn hay, thân thiết thì cũng dễ dàng làm việc hơn, đúng không
Ở đây, mình có thể giới thiệu điểm mạnh của một số thầy/cô, các bạn chỉ tham khảo thôi nhé:
  • Thuật toán: Thầy Thuân, Thầy Hùng.
  • Quy trình: Cô Phụng Nguyễn, Cô Phụng Đỗ, Cô Loan Phương.
Sau khi đã xác định được 2 vấn để ở trên, việc còn lại là gửi mail cho GV để thuyết phục họ. Hình thức gửi mail thì tất nhiên là phải formal rồi và tránh trường hợp gửi cùng một lúc 2-3 GV. Cuối cùng là chờ phản hồi.

Thực hiện

Đa số đến thời điểm này thì các bạn đã đi làm. Ừ thì, bạn vẫn có thể tiếp tục đi làm và tối về nghiên cứu luận. Nhưng đây là khoảng thời gian bạn chẳng nghiên cứu được bao nhiêu. Đi làm cả ngày, tối về nghiên cứu chắc chắn là chỉ có ngủ. Để mình kể cho nghe, nhóm mình, trong khoảng thời gian 1 - 2 tháng đầu, 2 người đều đi làm, về tới nhà là não nó nhũn rồi, cố gắng thêm chỉ có được 1 chút xíu. Thế là sau tháng đó, mình quyết định xin chuyển sang part-time với tâm thế là "không được thì nghỉ", mốt tính sau nên rất thoải mái. Hoàn thành khóa luận tốt nghiệp là ưu tiên hàng đầu nên phải quyết định vậy. Kết quả khả quan hơn rất nhiều.

Bắt đầu

Thông thường khi khảo sát nghiệp vụ, nghiên cứu lý thuyết xong là nhảy ngay vào code ... code ... Khoảng thời gian trước, làm đồ án môn học cũng vậy, rất xem nhẹ báo cáo, code xong rồi viết gì cũng được. Nhưng ở luận văn thì mình được biết là thầy cô đọc báo cáo cũng rất kỹ, nên không thể qua loa được. Cho nên, mình đã thay đổi cách làm việc một chút, viết, vẽ các mô hình, format của báo cáo mình làm song song với việc code. Nên kết quá thì về sau, nhóm mình rất nhẹ về phần báo cáo và chỉ tập trung fix bugs.
Dí GVHD ngay từ đầu. Để GV biết được những gì bạn cần, sẽ làm không phải là chuyện đơn giản. Nhất là đối với các bạn nghiên cứu những vấn đề mới. Hơn nữa, GV không chỉ hướng dẫn một nhóm của bạn và công việc giảng dạy. Nên phải cố gắng giành sự chú tâm của GV để họ hiểu được vấn đề và đưa ra lời khuyên tốt nhất cho bạn. Do đó, phải có đầy đủ các thông tin liên lạc của thầy/cô để liên tục có những cuộc trao đổi với nhau.

Trong khi thực hiện

Trong quá trình hiện thực sản phẩm thì có rất nhiều thứ cần phải làm nhưng mình xin tóm gọn thành duy nhất 1 công việc đó chính là quản lý.
  • Quản lý code: "lúc còn nhỏ" khi làm nhóm thì mình thường chia ra mỗi người viết một phần xong rồi gần gần báo cáo thì nhóm ngồi lại với nhau để "gom code". Khi lớn, những project cũng lớn hơn thì việc làm này gây rất nhiều tổn hại (thời gian, lỗi, chất lượng code). Sử dụng version control là điều không thể nào bỏ qua được. Thường thì người ta sử dụng SVN và Git nhưng mình khẩn khiết, yêu cầu bạn dùng Git để quản lý. Sử dụng với GitHub hay Bitbucket đều được. Còn về việc sử dụng như thế nào thì trên mạng có rất nhiều nhưng mình cũng sẽ cố gắng lụm lặt trên mạng có bài nào hay thì sẽ giới thiệu hoặc pm FB mình nếu cần. Link nên đọc.
  • Quản lý tiến độ: bằng việc ép sử dụng weekly report nên:
    • GVHD và bạn sẽ luôn đảm bảo liên lạc với nhau.
    • Lấy điểm từ GVHD. GVHD sẽ là người quan sát nhóm bạn làm việc như thế nào. Nếu report đúng hẹn thì GVHD cũng sẽ yên tâm hơn. Điều quan trọng nữa là điểm từ GVHD rất cao (40%).
    • Động lực làm việc. Khi thực hiện report hàng tuần, trong người bạn lúc nào cũng phải nghĩ ra cách để hoàn thành một phần nào đó để "có cái mà report". Nghe có vẻ hơi tiêu cực nhưng thực ra rất tích cực đấy! :)
    • Quản lý công việc: nếu bạn đóng vai trò là một nhóm trưởng, thì việc phân công công việc rất là quan trọng. Bạn phải biết bạn sẽ làm gì và partner của bạn cũng phải biết người đó nên làm gì. Nếu không có một phân công rõ ràng thì rất dễ xảy đến tình trạng hai người làm chung 1 công việc, không thống nhất trong việc code và nhiều xung đột khác. Có thể phân công lúc đầu sẽ không chính xác, nhưng nhờ đó, bạn sẽ biết mình cần phải thay đổi gì, hoán đổi công việc ra sao.
Bằng duy nhất một việc quản lý tốt, mình đảm mọi người trong nhóm sẽ hoạt động tốt, kể cả GVHD. Bạn sẽ biết được mình còn những gì cần phải làm, có chậm tiến độ hay không? Nếu bí quá thì phải cắt những phần nào.

Gần kết thúc

Đến thời điểm còn 1 tháng nữa là phải báo cáo. Đối với những bạn nếu còn đi làm thì mình khuyên là làm khó công ty một lần nữa, xin nghỉ hẳn đi, xong 1 tháng em sẽ quay lại, nếu không cho thì cũng ... đi luôn. Người không vì mình, trời tru đất diệt mà. Còn bạn nào đã nghĩ từ trước rồi thì không phải suy nghĩ.
Mình khuyên các bạn nghỉ là đúng đấy nhé! Nếu bạn tiếp tục, bạn sẽ làm khổ cả 2 mà thôi. Bạn không thể tập trung vào luận văn của mình trong khi đang làm việc và cũng không thể tập trung vào công việc khi deadline luận văn nó cứ lòng vòng trong đầu. Chọn một để làm cho tốt còn hơn làm cả hai mà chẳng tốt cái nào.

Báo cáo

Hầu hết các bạn khi đến giai đoạn viết báo cáo thì rất là mệt mỏi và hầu hết các bạn đều lười việc viết này đúng không? Nhưng mình xin nhắc lại là nó rất quan trọng. GVHD, GVPB, và cả hội đồng lúc này sẽ đọc báo cáo của bạn. Không chú trọng trong việc viết này thì trước sau gì cũng phải bị viết lại thôi.
Đối với các bạn nào làm theo hướng UML thì trước khi code, như mình đã khuyên, nên dành thời gian để vẽ tất cả các mô hình.
  • Bạn sẽ biết sản phẩm của mình có những chức năng nào.
  • Thành viên trong nhóm sẽ hiểu được quy trình của phần mà bạn đó sẽ làm.
  • Vừa code vừa dò với báo cáo thì sẽ phát hiện được những chỗ không trùng khớp, nếu có thì phải xem xét lại cả hai cho đồng bộ.
Sơ đồ UML là phần tốn khá nhiều thời gian để bạn hoàn thiện. Cho nên, việc làm báo cáo ngay từ đầu sẽ dễ dàng hơn cho bạn ở giai đoạn cuối. Mình đã chứng kiến nhiều nhóm giai đoạn cuối thức ngày, thức đêm để viết báo cáo mà phải nói ... sai rất nhiều chỗ. Trong khi đó, nhóm mình chỉ tập trung vào việc fix bugs và hoàn thiện báo cáo.

Trước khi viết hoàn thiện báo cáo (mục tiêu, lời cảm ơn, phần nào nên để vào báo cáo, diễn giải...) thì mình khuyên bạn, lấy một tờ giấy ra để lên ý tưởng về những phần mà mình sẽ trình bày. Khi bắt đầu viết thì sẽ dễ dàng hơn và chắc chắn là không bị bí giữa chừng.

Tuy nhiên, mặc dù đã chuẩn bị sớm nhưng nhóm mình vẫn vấp phải nhiều lỗi vì chưa quen với dạng báo cáo và GVHD của mình sửa báo cáo rất kỹ. Mỗi lần bạn xem lại báo cáo, mình đảm bảo lúc nào bạn cũng thấy lỗi để sửa. Và để tránh tình trạng in tổng cộng 9 cuốn báo cáo như mình :( thì bạn nên xem trước mẫu của khoa đưa ra và dựa vào đó viết để phù hợp nhất với chuẩn chung. Nhờ có sự đầu tư đúng mức, cho nên báo cáo của nhóm cũng được xem là khá chất lượng.

Hơn nữa, báo cáo này sẽ được lưu lại ở khoa và SV khóa sau sẽ đọc lại khi cần. Việc trau chuốt cho nó không phải là một việc thừa đúng không? Bạn muốn mấy đứa em đọc lại rồi chửi rủa mình không?
Ya, it's up to you!

Phản biện

Phần này sẽ chiếm 40% tổng điểm của bạn, nên phải đảm bảo không để rơi rớt điểm trong phần này nhé.

Quay ngược thời gian trở về với tuổi thơ, khi báo cáo đồ án môn học, mình thường là người trình bày chính và lỗi mình hay mắc đó là không có một thứ tự rõ ràng và bỏ sót những phần mình đã làm mà không trình bày. Rút kinh nghiệm, trước khi phản biện, nhóm mình đã viết ra giấy thứ tự demo các chức năng (sẽ trình bày cái gì) rồi khi gặp GVPB thì cứ thế mà thao thao bất tuyệt. Đảm bảo, bạn sẽ không rơi rớt phần nào. Hơn nữa, GVPB cũng sẽ đánh giá bạn tốt hơn do có chuẩn bị tốt. Bằng chứng là GVPB của nhóm đã nhờ nhóm ghi lại tờ giấy nguệch ngoạc thứ tự demo của mình để cô dễ dàng xem lại hơn.

Slide trình bày là một phần không ép buộc nhưng không nên thiếu. Bạn nên chuẩn bị nó giống y chang những gì bạn sẽ trình bày trước Hội đồng luôn. Khi nghe bạn trình bày vậy, GV cũng sẽ thích hơn vì có sự chuẩn bị tốt và quan trọng hơn nữa là nhận được những lời đóng góp cho slide cũng như phần trình bày của bạn.

Kỹ năng trình bày slide thì bạn cố gắng tham gia mấy lớp huấn luyện hoặc trên mạng cũng có nhiều lắm. Cơ bản là, không phải cái gì cũng để vào slide vì nhiều quá chẳng ai đọc, mà cũng đừng ít quá vì nhiều khi người nghe không nghe được gì đó thì có thể nhìn vào slide mà hiểu bạn đang nói gì.
Cứ bình tĩnh, tự tin, phần này giống y báo cáo đồ án môn học nhưng có điều là sẽ bị xoáy kỹ hơn, hỏi nhiều hơn và thời lượng có thể lên đến 4-6 tiếng. Nên chuẩn bị các câu hỏi mà GV có thể hỏi. Đây là danh sách các câu hỏi nên xem qua do Thầy Trí tổng hợp. Link

Hội đồng

Trước khi ra hội đồng, các nhóm làm khóa luận nên mời một số giáo viên để tổ chức buổi báo cáo thử. Nhằm để GV nhận xét về toàn phần trình bày của bạn. Mọi năm thì thầy DPL, thầy Hùng, và GV trẻ như thầy Trí, thầy Huy sẽ tham gia đóng góp cũng như đặt câu hỏi để bạn phải trả lời.
Sau khi nhận được những nhận xét về slide, phần trình bày từ GVPB, GVHD, báo cáo thử thì bạn sẽ là người xem xét và dung hòa các ý kiến đó lại để ra một bản cuối cùng.

Phần demo thì mình khuyên là nên dùng demo thật, thú vị hơn và thầy/cô trong Hội đồng có hỏi thì lấy nó ra trình bày sẽ nhanh hơn. Tuy nhiên, rủi ro hơi cao nên phải có phương án B kèm theo đó là quay video.

Phần hỏi đáp thì nếu như bạn đầu tư đúng mức vào nó thì bạn sẽ trả lời được hết các câu hỏi thôi. "Nên chuẩn bị trước các bảng số liệu so sánh" để làm bằng chứng và đọc lại các câu hỏi tham khảo mà thầy Trí mà mình đã cung cấp.

Nếu bạn không giỏi trình bày như mình thì tốt nhất là viết ra giấy toàn bộ những bình sẽ trình bày sau đó thì ... dường như là học thuộc lòng :3. Nghe vậy thôi chứ không khó, nhìn vào slide là nhớ hết và tưởng tưởng mình đang đứng trước Hội đồng. Cứ thế độc thoại.

Ah, các bạn nhớ là thông thường thì Hội đồng rất là căng thẳng, nếu bạn có khả năng làm gì đó vui vui thì nên làm để mọi người cảm thấy thư giản hơn, đỡ mệt mỏi hơn và tạo một chút thiện cảm đối với bạn.

Kết

Mình chỉ muốn tặng các bạn 2 câu:
"Cái nào cũng có cái giá của nó."
"Sự chuẩn bị tốt chẳng bao giờ là thừa."
Cuối cùng thì bạn sẽ nhận được những gì xứng đáng với công sức bạn đã bỏ ra. Mình chắc chắn!
Say thanks if you like.
Share it if you're interested in.
Chúc các bạn thành công như mình đã từng.
Thân chào và quyết thắng (^.^)

Một số tài liệu

  1. Báo cáo nhóm mình. http://goo.gl/6n1cjN
  2. Đề cương thực hiện. http://goo.gl/cQyEUr
  3. Slide trình bày. http://goo.gl/S6mZof | Slideshare: http://goo.gl/88xzxg
  4. Các câu hỏi cần chuẩn bị. http://khanhtran.xyz/public/thesis/luu-y.pdf
  5. Cách vẽ UML đúng chuẩn. http://goo.gl/4u3bhF
  6. How to Do a Presentation http://www.wikihow.com/Do-a-Presentation-in-Class
  7. Source code https://github.com/khanhtran3005/hope (Code này là original, chưa chỉnh sửa gì từ khi báo cáo xong, đọc lại thấy chục tháng trước viết "chuối" thật :3 ) -- update Sep 12th, 2015

Comments

Popular Posts