การพัฒนาระบบ UBU-Quizzi :ระบบโหวตและตอบคำถามแบบเรียลไทม์สำหรับห้องเรียน

สกัดองค์ความรู้ KM: การพัฒนาระบบ UBU-Quizzi :ระบบโหวตและตอบคำถามแบบเรียลไทม์สำหรับห้องเรียน

 

ผลงาน UBU KM FAIR 2026 | ประเภทผลงาน: สายสนับสนุน | การพัฒนาระบบสารสนเทศ

 

ชื่อผลงาน: การพัฒนาระบบ UBU-Quizzi :ระบบโหวตและตอบคำถามแบบเรียลไทม์สำหรับห้องเรียน

 

ชื่อเจ้าของผลงาน: นายณัฐพล มารุตะพันธ์ สำนักเทคโนโลยีดิจิทัลและทรัพยากรการเรียนรู้

 

สรุปเป็นสาระสำคัญในมิติต่างๆ ได้ดังนี้

1. วัตถุประสงค์หลัก:

    1. พัฒนาระบบตอบสนองผู้เรียนในชั้นเรียน (Audience Response System: ARS) สำหรับโหวตและตอบคำถามแบบเรียลไทม์ที่เข้าถึงได้สะดวกผ่านเว็บเบราว์เซอร์ โดยเชื่อมต่อกับระบบยืนยันตัวตนและ  โครงสร้างพื้นฐานภายในมหาวิทยาลัย

    2. สร้างเครื่องมือสนับสนุนรูปแบบกิจกรรมที่หลากหลาย พร้อมการสรุปผลแบบเรียลไทม์

    3. ทดสอบการรองรับผู้ใช้จำนวนมากเพื่อเป็นทางเลือกใช้งานภายในองค์กร

 

2. กระบวนการใช้งานและฟังก์ชันหลัก

    1. การแบ่งบทบาทผู้ใช้งาน:

       - ผู้สอน: ยืนยันตัวตนผ่านระบบ Single Sign-On (UBU OAuth 2.0)

       - สามารถสร้างแบบทดสอบด้วยตนเอง หรือใช้ฟังก์ชัน AI Generate (GPT-5.1) ผ่าน AI Gateway ของมหาวิทยาลัย

      - สามารถควบคุมลำดับคำถาม หยุดรับคำตอบ ซ่อน/แสดงเฉลย และดูผลสรุปหลังจบเซสชัน

      - ผู้เรียน: เข้าใช้งานผ่านเว็บเบราว์เซอร์บนสมาร์ตโฟนหรือคอมพิวเตอร์โดยไม่ต้องติดตั้งแอปพลิเคชัน และไม่ต้องลงชื่อเข้าใช้ เพียงกรอกรหัส PIN 6 หลัก หรือสแกน QR Code

    2. รูปแบบคำถาม (3 โหมดหลัก):

        - Standard: คำถามปรนัยแบบไม่จำกัดเวลา

        - Timer: คำถามปรนัยแบบจับเวลา ซึ่งระบบจะคำนวณคะแนนตามเวลาที่ใช้ตอบ

        - Open-ended: คำถามตอบอิสระที่ระบบประมวลผลสรุปเป็น Word Cloud แบบเรียลไทม์

    3. กลไกความต่อเนื่อง (Rejoin): ระบบจดจำคำตอบเดิมและสถานะเซสชันของผู้เรียน ช่วยให้สามารถกลับเข้าร่วมกิจกรรมได้ทันทีเมื่อสัญญาณเครือข่ายขัดข้อง

 

3. สถาปัตยกรรมระบบและเทคโนโลยี (Tech Stack)

    1. การประมวลผล (Application Layer): พัฒนาแบบ Server-Side Rendering ด้วย Nuxt 4, Nitro และ Node.js 18 ทำงานผ่าน PM2 Cluster จำนวน 16 workers และจัดการคำขอผ่าน Nginx Reverse Proxy

    2. ระบบฐานข้อมูลและแคช: ใช้ PostgreSQL เป็นฐานข้อมูลหลัก (รองรับ Connection Pool สูงสุด 96 connections) และใช้ Redis สำหรับเก็บสถานะเซสชัน รายชื่อผู้เข้าร่วม heartbeat และผลโหวตรายข้อ

    3. กลไกการสื่อสาร: เลือกใช้ HTTP Polling แทน WebSocket เพื่อให้ทำงานร่วมกับ Reverse Proxy ได้ง่ายและขยายระบบแบบ Stateless โดยผู้เรียนจะดึงข้อมูลคำถามทุก 1 วินาที และผู้สอนปรับจำนวนผู้ตอบทุก 2–3 วินาที

    4. ความมั่นคงปลอดภัย: ยืนยันตัวตนผู้สอนด้วย JWT (HS256) อายุ 24 ชั่วโมง มีระบบป้องกัน XSS ด้วยการกรอง HTML ใน Rich Text Editor ตรวจสอบชนิดและความยาวข้อมูลนำเข้า และแปลงไฟล์ภาพเป็น WebP

 

4. ผลการทดสอบประสิทธิภาพและภาระงาน (Load Test)

    1. การรองรับผู้ใช้: ผ่านการทดสอบบนระบบจริง (Production HTTPS/Nginx) รองรับผู้ใช้งานพร้อมกันได้ถึง 1,500 คนต่อห้อง

    2. เสถียรภาพและความหน่วง: อัตราความผิดพลาด (Error Rate) เท่ากับ 0.0% และมีค่าความหน่วงในระดับ Percentile 95 (P95 Latency) เพียง 16 มิลลิวินาที

    3. Safety Margin: มีระดับความปลอดภัยรองรับภาระงานสูงกว่าการใช้งานปกติในห้องเรียนมหาวิทยาลัย (ขนาด 50–300 คน) ถึง 30–50 เท่า

 

5. ข้อจำกัดและแนวทางการพัฒนาต่อยอด

    1. การรักษาความปลอดภัยเพิ่มเติม: มีแผนเปิดใช้การตรวจสอบใบรับรอง TLS ของ UBU OAuth, การตรวจสอบ Magic Bytes ของไฟล์ภาพ และการกำหนด Rate Limiting สำหรับการส่งคำตอบ

    2. การประเมินผล: เอกสารฉบับนี้ยังไม่ได้รายงานผลประเมินด้านผลสัมฤทธิ์ทางการเรียนและความพึงพอใจของผู้ใช้งานโดยตรง ซึ่งเป็นประเด็นที่ควรดำเนินการประเมินเพิ่มเติมในระยะยาว

    3. ผลกระทบและความคุ้มค่า (Impact): การพัฒนาระบบแบบ Self-hosted ช่วยให้มหาวิทยาลัยสามารถกำกับดูแลข้อมูลภายในองค์กรได้เอง ปรับแต่งฟังก์ชันตามบริบทได้ และลดการพึ่งพาบริการเชิงพาณิชย์จากภายนอกในระยะยาว