ทำอย่างไรให้ได้ A สำหรับบทความวิชาสัมมนาและโครงการพิเศษในส่วนของ Advisor

1. การเขียนรายงานความก้าวหน้า ควรทำให้ครบถ้วนเหมือนกับรายงานฉบับสมบูรณ์ เนื่องจากว่า ถ้าคุณทำมาแค่บางส่วนในรายงานความก้าวหน้า และค่อยมาเพิ่มเนื้อหาให้ครบในฉบับสมบูรณ์ ผมจะไม่สามารถตรวจฉบับสมบูรณ์ก่อนได้ และ คณะกรรมการก็จะได้รับรายงานฉบับสมบูรณ์ที่คุณส่งมานี้ไปอ่าน ในกรณีที่ไม่สามารถทำเช่นนี้ได้ ก็พยายามเขียนรายงานความก้าวหน้า ให้ครบถ้วนมากที่สุดเท่าที่จะทำได้ อย่างไรก็ตาม คุณควรจะกำหนดโครงร่างทั้งหมดของรายงานมาแล้ว นั่นคือ ในรายงานจะประกอบไปด้วยกี่หัวข้อ (หรือกี่บท) อะไรบ้าง เช่น สมมติว่า คุณมีทั้งหมด 6 หัวข้อ แต่เพิ่งเขียนได้แค่ 4 หัวข้อแรก คุณก็ควรบอกว่า หัวข้อที่ 5 และ 6 คืออะไร จะอธิบายถึงอะไร และมีหัวข้อย่อยอะไรบ้าง 5.1, 5.2, ..., 6.1, 6.2, ...

2. สำหรับคนที่ทำเรื่องการพัฒนาระบบ ในสัมมนาควรจะรวมถึงการวิเคราะห์และออกแบบระบบ นั่นหมายถึงคุณควรจะมี context diagram, data flow diagram, E-R diagram และ data dictionary ที่ผ่านการ normalization มาเรียบร้อยแล้ว ส่วนในวิชาโปรเจ็ค ก็จะรวมเนื้อหาเหล่านี้ เข้าด้วยกับ การทำ implementation ซึ่งรวมถึงการใช้ระบบ ตัวอย่างหน้าจอ และรายงานหลักๆของระบบ ปัญหาหรือข้อจำกัดที่พบ ข้อเสนอแนะในการพัฒนาระบบต่อไป

3. เนื้อหาหรือทฤษฎีเกี่ยวกับ SDLC หรือ database ไม่จำเป็นต้องอธิบายในรายละเอียด เนื่องจากเป็นที่ทราบกันดีอยู่แล้ว เพียงแค่อธิบายว่าเราใช้วิธีการใด หรือรูปแบบใด ในการทำ SDLC หรือ ใช้ database อะไร เมื่อนำความรู้ของ SDLC ใน stage ต่างๆมาประยุกต์ใช้กับระบบของเรา รายละเอียดของการประยุกต์ใช้ในแต่ละ stage จะไป ปรากฎในบทใด เช่น เราเลือกใช้วิธี .......... ของ SDLC ในการพัฒนาระบบ (หรือ SDLC แบบ ......... และอาจมีการใส่ reference(s) ไว้ที่นี่ได้ ผู้อ่านจะได้ไปศึกษารายละเอียดเพิ่มเติม ถ้าต้องการ) โดยในขั้นตอนแรก คือ การระบุปัญหาและศึกษาความเป็นไปได้ โดยบทที่ 2 จะอธิบายปัญหาว่า ระบบที่เราต้องการสร้างคืออะไร มีหน้าที่อย่างไร ขอบเขตแค่ไหน นั่นคือ เราต้องการระบบที่สามารถทำอะไรได้บ้าง จากนั้น เราจะต้องศึกษาวิเคราะห์ความเป็นไปได้ในด้านต่าง ๆ ว่าคำตอบสำหรับปัญหาของเราคืออะไร เพราะอะไรจึงเลือกวิธีนี้ ในขั้นตอนที่ 2 เป็นการวิเคราะห์ระบบ ในขั้นตอนนี้ จะเป็นการ ....... ซึ่งแสดงรายละเอียดในบทที่ 3 ต่อมาเป็น .................

4. เนื่องจากผมไม่ได้มีหน้าที่ที่ต้องติดตามงานของคุณ แต่ ดังที่ผมได้บอกใน homepage ว่า คุณมีหน้าที่ที่จะรายงานความก้าวหน้าเป็นระยะๆ เพื่อผมจะได้รู้ว่าคุณยังเดินถูกทางอยู่หรือไม่ และถ้าคุณได้พยายามเต็มที่แล้วกับการทำงาน แต่ยังมีปัญหา ไม่ว่าเรื่องใดๆ ควรจะปรึกษาผม เนื่องจากในอดีต น.ศ.บางท่านไม่ค่อยได้มาติดต่อผม จนกระทั่งใกล้จะสอบ project ก็ขอ demo ให้ผมดู ปรากฏว่า เขาผิดตั้งแต่การวิเคราะห์และออกแบบระบบแล้ว สิ่งที่ควรทำคือ จะต้องกลับไปแก้ design ใหม่ ซึ่งแน่นอน ต้องส่งผลกระทบถึง application ที่สร้างจวนจะสมบูรณ์อยู่แล้ว ดังนั้น อย่าปล่อยให้สายเกินไป น.ศ.บางท่านเข้ามาคุยช่วงการวิเคราะห์และออกแบบ และเป็นที่เห็นตรงกันว่า design ที่ถูกต้อง เหมาะสม และควรจะเป็น จะเป็นอย่างไร แต่พอนำมา demo ให้ผมดู ปรากฏว่า ไม่ใช่สิ่งที่สรุปกัน โดยอ้างเหตุผลว่า ถ้าทำตาม design นั้น เขาไม่สามารถ coding หรือ สร้าง query ตามที่ต้องการได้ เนื่องจาก เงื่อนไขการสร้าง query มันยากหรือซับซ้อนเกินไป เช่น SELECT ซ้อน SELECT หลายๆตัว แต่นั่นคือสิ่งที่คุณจะต้องทำ ดังนั้น หลังจากที่คุณได้ design ที่ถูกต้องแล้ว (normalized แล้ว) ไม่ควรเอาปัญหาที่คุณไม่สามารถ coding ได้ เป็นข้ออ้างในการแก้ design (ซึ่งจะเป็นแบบ unnormalized)

ต่อไปนี้เป็นเกณฑ์ส่วนตัวที่ผมใช้พิจารณา ในการให้เกรดคุณ ในส่วนต่างๆของ advisor ในวิชาสัมมนาและโปรเจ็ค ทั้งในรายงานและตอนสอบ พลาดข้อใดไป อาจมีสิทธ์ไม่ได้ “A”

q ส่วนใหญ่พวกคุณจะใช้ Microsoft Word ในการเขียนบทความ ซึ่งมีคุณสมบัติในการตรวจคำสะกดอยู่แล้ว ดังนั้น ขอให้ใช้มันให้เป็นประโยชน์ บทความที่คุณส่งมาควรสะกดคำต่างๆให้ถูกต้องทั้งหมด ทั้งไทยและอังกฤษ

q รูปแบบและองค์ประกอบต่างๆของรายงาน เป็นไปตามที่กำหนดในคู่มือวิชาสัมมนาและโปรเจ็ค

q การอ้างอิง และการเขียนเอกสารอ้างอิง (สำหรับสัมมนา) หรือบรรณานุกรม (สำหรับโปรเจ็ค) ถูกต้อง โดยสามารถศึกษาได้จากคู่มือวิชาโปรเจ็ค (การที่คุณไม่มีการใช้การอ้างอิงในเนื้อหาส่วนใด แสดงว่าคุณรู้เรื่องในส่วนนั้นๆมาแล้ว ถ้าเป็นเรื่องที่คุณเพิ่งจะรู้ โดยไปอ่านมา ค้นคว้ามา หรือศึกษามา ก็ต้องมีการเขียนการอ้างอิง ว่าอ้างมาจากแหล่งที่มาที่ใด ไม่ว่าจะเป็นการลอกข้อความนั้นมาตรงๆ หรือนำมาสรุปเป็นคำพูดของคุณเอง)

q ในรายงานมีเลขหน้าครบถ้วน

q คุณภาพของเนื้อหาเป็นไปอย่างที่ควรจะเป็น เช่น สำหรับคนที่ทำเกี่ยวกับการพัฒนาระบบ

· การวิเคราะห็และออกแบบระบบในสัมมนา จะต้องมี context diagram, data flow diagram, E-R diagram และ data dictionary ครบ หรือในโปรเจ็ค ก็ควรรวมถึงปัญหาหรือข้อจำกัดที่พบ ข้อเสนอแนะในการพัฒนาระบบต่อไป

· การวิเคราะห็ความสัมพันธ์ของข้อมูลในระบบ จะต้องครบถ้วนและถูกต้อง ข้อมูลจะต้องผ่านการ normalization ถูกต้อง

· การตั้งชื่อ attribute ต่างๆ ให้เป็นไปตามหลัก naming convention ดังในหนังสือ “Database Systems” ของ Peter Rob และ Carlos Coronel หลีกเลี่ยงการใช้ homonyms และ synonyms

หมายเหตุ สามารถอ่านเอกสารเพิ่มเติมที่ homepage ของผม http://www.kmitl.ac.th/~klpattar/citation.pdf