1145 204 · WEEK 08 Midterm Progress Defense · Grocery POS Platform
สไลด์ 01 / 10
เอกสารประกอบการสอน สัปดาห์ที่ 8 รายวิชา 1145 204 โครงงานสำหรับนักศึกษาปีสอง (Sophomore Project)
SLIDE 01 / 10

การสอบนำเสนอความก้าวหน้ากลางภาค: แพลตฟอร์ม Grocery POS

แนวทางเตรียมความพร้อมโครงสร้างการนำเสนอ การสาธิตระบบตัวอย่างแบบสด กลยุทธ์ป้องกันสถาปัตยกรรมซอฟต์แวร์ และเกณฑ์ประเมินของคณะกรรมการ

บทบาทของการสอบกลางภาค (WEEK 8: MIDTERM PROGRESS DEFENSE)

การสอบกลางภาคไม่ใช่เพียงการรายงานความคืบหน้าเชิงเอกสาร แต่เป็นการตรวจสอบหลักฐานทางวิศวกรรมซอฟต์แวร์ (Working Prototype, Database Schema, Agile Velocity และ Risk Plan) ก่อนเข้าสู่ช่วงบูรณาการระบบเต็มรูปแบบในสัปดาห์ที่ 9–12

CLO1: Agile & Teamwork CLO2: Software Architecture CLO3: Risk & PDPA CLO4: Oral Defense & Demo
สัดส่วนคะแนน
20–25%
ของเกรดรวมรายวิชา (คะแนนดิบเต็ม 100 คะแนน)
ขนาดทีมโครงงาน
1–3 คน
ประเมินทั้งระดับกลุ่มและบทบาทรายบุคคล
เวลานำเสนอมาตรฐาน
12 นาที
รวมสาธิตสด + ช่วงซักถามคณะกรรมการ
ตารางฐานข้อมูลหลัก
6 ตาราง
โครงสร้าง Relational Schema สำหรับ Grocery POS
ผลลัพธ์การเรียนรู้ประจำสัปดาห์ที่ 8 (LLO): นักศึกษาสามารถสื่อสาร นำเสนอความก้าวหน้าเชิงเทคนิค และสาธิตระบบตัวอย่าง (Prototype/Demo) ของแพลตฟอร์ม Grocery POS ต่อคณะกรรมการสอบได้อย่างชัดเจน มีเหตุผลรองรับ และวางแผนปรับปรุงตามข้อเสนอแนะได้
หลักสูตร 1145 204 Sophomore Project · กลุ่มระบบขายหน้าร้านร้านค้าปลีก (Grocery POS) ใช้ปุ่มลูกศร ← / → เพื่อเปลี่ยนสไลด์
ภาพรวมรายวิชา Course Progression · From Charter to Final Defense
SLIDE 02 / 10

จุดตัดครึ่งทาง: ทำไมคณะกรรมการตรวจ "ซอฟต์แวร์ที่ทำงานได้" มากกว่าสไลด์

ตามหลัก Agile Software Development ความก้าวหน้าวัดจากซอฟต์แวร์ที่ใช้งานได้จริง ไม่ใช่ปริมาณเอกสารที่เขียนไว้

W01–03 ก่อตั้งทีมและวางกรอบ ใบตอบรับอาจารย์ที่ปรึกษา, Project Charter, SRS, User Story Backlog และ Initial Risk Register
W04–07 ออกแบบและ Sprint 1 ตั้งค่า Jira/GitHub, Git Branching, ER Diagram, API Specs, พัฒนา Core Modules และ Code Review
W08 · ปัจจุบัน Midterm Defense สอบนำเสนอความก้าวหน้าและสาธิต Prototype ต่อคณะกรรมการ (100 คะแนน)
W09–12 บูรณาการและ QA นำ Midterm Feedback Log เข้า Sprint 2, เชื่อม Frontend-Backend-DB, Risk Review และ Unit/Usability Test
W13–15 Final Defense ส่งมอบรายงานบทที่ 1–5, คู่มือติดตั้ง, Live Production URL, GitHub และสอบป้องกัน 15 นาที

จุดเปลี่ยนจาก "ข้อมูลตั้งต้น" สู่ "ระบบวิศวกรรมซอฟต์แวร์"

  • 01
    ความต่อเนื่องเชิงข้อมูล (Data Lineage): ต่อยอดจากทักษะการเตรียมข้อมูล POS ปี 1 (order_id, timestamp, category, quantity, price_per_unit, payment_method) สู่การออกแบบระบบธุรกรรมจริงในฐานข้อมูลเชิงสัมพันธ์
  • 02
    วงจรป้อนกลับสั้น (Short Iteration Feedback): การสอบ Week 8 ทำหน้าที่เสมือน Sprint Review ระดับหลักสูตร เพื่อค้นหาจุดบกพร่องของสถาปัตยกรรมก่อนสายเกินแก้
  • 03
    เกณฑ์วัดความสำเร็จ (Working Software): หากฟีเจอร์หลัก (Auth, Product Catalog, POS Cart, Stock Deduction) ยังรันผ่าน API หรือ UI ไม่ได้ ต้องแสดงความเสี่ยงและแผนแก้ไขอย่างซื่อสัตย์
AUN-QA ASSESSMENT PRINCIPLE

การสอบโครงงานเป็นการประเมินแบบอิงเกณฑ์ (Criterion-referenced Assessment) ที่ตรวจสอบทั้ง Content & Construct Validity ของ CLO1–CLO4 ผ่านหลักฐาน 3 ส่วนพร้อมกัน:

  1. คำอธิบายด้วยวาจาและการตอบคำถาม (Oral Defense)
  2. การทำงานของระบบจริง (Live Prototype)
  3. ร่องรอยการทำงานใน Git & Backlog (Process Evidence)
อ้างอิง: แผนการสอน มคอ.3 รายวิชา 1145 204 และแนวคิด Agile Principles Slide 02 — Context & Course Alignment
โครงสร้างการนำเสนอ Presentation Blueprint & Interactive Timebox Simulator
SLIDE 03 / 10

โครงสร้างสไลด์ 5 ช่วงที่กระชับ ครบประเด็น และไม่หลุดเวลา

ปรับเวลาสอบรวมและลองจับเวลาซ้อมจริง เพื่อให้ช่วงสาธิตระบบ (Live Demo) และ Q&A มีเวลาเพียงพอ

เลือกกรอบเวลานำเสนอ (ไม่รวม Q&A หรือรวมตามประกาศกรรมการ)
เวลาซ้อมปัจจุบัน
12:00
พร้อมจับเวลา 12 นาที
ช่วงที่ หัวข้อในสไลด์ หลักฐานที่ต้องโชว์ เวลา (นาที)
กฎเหล็กการจัดสัดส่วนทีม (1–3 คน)
  • A
    สมาชิกทุกคนต้องได้พูดและตอบคำถาม: เกณฑ์ด้านที่ 4 หักคะแนนทันทีหากมีสมาชิกคนใดคนหนึ่งนำเสนอคนเดียวทั้งหมด
  • B
    แบ่งตามความเชี่ยวชาญจริง: เช่น คนที่ 1 พูด Problem & Agile/Risk, คนที่ 2 อธิบาย DB Schema & API, คนที่ 3 คุม Live POS Demo
  • C
    ห้ามอ่านสไลด์ตัวอักษรแน่น: ใช้แผนภาพ ER, Burndown Chart และตัวเลขสถิติจริงบนหน้าจอแทนพารากราฟยาว
  • D
    กันเวลาฉุกเฉิน 1 นาที: เผื่อจังหวะสลับหน้าจอสไลด์ไปยังหน้าเว็บ/โปรแกรม POS จริง
เคล็ดลับ: ซ้อมพูดพร้อมสาธิตจริงอย่างน้อย 2 รอบก่อนเข้าห้องสอบ Slide 03 — Timebox & Structure
ขอบเขตระบบตัวอย่าง Grocery POS Deliverables · Week 8 Baseline vs. Post-Midterm
SLIDE 04 / 10

แพลตฟอร์ม Grocery POS: สิ่งที่ต้องทำงานได้จริงในสัปดาห์ที่ 8

แยกให้ออกระหว่างขอบเขตหลักที่ต้องโชว์ในกลางภาค (Sprint 1 + Core POS) กับฟีเจอร์ส่วนขยายใน Sprint 2–3

ต้องพร้อมสาธิตใน Week 8 (Midterm Baseline) Sprint 1 + Core MVP
  • 01
    ระบบยืนยันตัวตนและสิทธิ์ (Auth & RBAC): ลงชื่อเข้าใช้แยกบทบาท Admin / Manager / Cashier พร้อมจัดเก็บรหัสผ่านแบบ Hash
  • 02
    ฐานข้อมูลสินค้าและหมวดหมู่ (Catalog & Stock): เพิ่ม/แก้ไข/ค้นหาสินค้า Grocery ตามหมวดหมู่ กำหนดราคาต่อหน่วย หน่วยนับ และจุดสั่งซื้อซ้ำ (reorder_level)
  • 03
    หน้าจอขายหน้าร้าน (POS Checkout Flow): เลือกสินค้าลงตะกร้า คำนวณราคารวม ยืนยันการชำระเงิน (Cash / PromptPay / Credit Card) และบันทึก Orders + Order_Items
  • 04
    การตัดสต็อกอัตโนมัติ (Auto Stock Deduction): เมื่อยืนยันคำสั่งซื้อ ยอด stock_quantity ต้องลดลงทันทีและแจ้งเตือนเมื่อต่ำกว่าเกณฑ์
แผนพัฒนาต่อใน Week 9–12 (Sprint 2–3) Post-Midterm Roadmap
  • 05
    สรุปยอดขายและ Peak Hours Analytics: แดชบอร์ดยอดขายรายวัน แยกตามหมวดหมู่สินค้า และช่วงเวลาขายดี เพื่อช่วยวางแผนเติมสต็อก
  • 06
    ระบบจัดการใบเสร็จและการคืนสินค้า (Void/Refund): ออกใบเสร็จสมบูรณ์ พร้อมตรรกะคืนสต็อกเมื่อยกเลิกบิล
  • 07
    การบูรณาการ Error Handling & Concurrency: รองรับการขายพร้อมกันหลายจุด (Locking/Transaction) และการทดสอบ Unit + Integration + Usability Test
  • 08
    Deployment บน Cloud/Production: เผยแพร่ลิงก์ระบบจริงและคู่มือติดตั้งสำหรับ Final Defense สัปดาห์ที่ 13–15
ตัวอย่าง USER STORY & ACCEPTANCE CRITERIA มาตรฐานสำหรับใช้ในสไลด์

User Story: "ในฐานะ พนักงานแคชเชียร์ (Cashier) ฉันต้องการ สแกนหรือเลือกสินค้าในตะกร้าและกดรับชำระเงินผ่าน PromptPay/เงินสด เพื่อ ออกใบเสร็จให้ลูกค้าได้อย่างรวดเร็วและตัดยอดสต็อกในคลังโดยอัตโนมัติ"
Acceptance Criteria: (1) ระบบคำนวณ subtotal และ total_amount ถูกต้อง (2) ห้ามขายเกิน stock_quantity ที่มีอยู่ (3) หาก stock_quantity ≤ reorder_level ต้องขึ้นสถานะ Low Stock ทันที

อ้างอิง: โครงสร้างชิ้นงาน POS และเกณฑ์ Sprint 1–3 Slide 04 — Grocery POS Functional Scope
สาธิตระบบสด Live Prototype Demo Checklist · Persistent Readiness Tracker
SLIDE 05 / 10

เช็กลิสต์เตรียมสาธิตระบบสด: กฎ 3 นาทีทองที่ห้ามระบบล่มต่อหน้ากรรมการ

ติ๊กตรวจสอบความพร้อมของทีมก่อนขึ้นสอบจริง ระบบจะบันทึกความคืบหน้าไว้ให้อัตโนมัติ

ความพร้อมในการสาธิตสด (DEMO READINESS)
0%

ยังไม่เริ่มตรวจสอบ — คลิกทำเครื่องหมายในรายการด้านขวา

ลำดับทองในการสาธิต (3–4 นาที):
  1. เปิดหน้า Login แสดง Role สั้นๆ (15 วินาที)
  2. สแกน/เลือกสินค้า Grocery 2–3 ชิ้น + ปรับจำนวน (45 วินาที)
  3. กดชำระเงิน + โชว์บันทึก Order และใบเสร็จ (45 วินาที)
  4. สลับดูหน้าคลังสินค้า ยืนยันว่ายอดสต็อกลดลงจริงและขึ้นแจ้งเตือน Low Stock (60 วินาที)
  5. โชว์ Error Case 1 กรณี เช่น สินค้าหมด/สั่งเกินสต็อก (30 วินาที)
รายการตรวจสอบ 10 ข้อก่อนเข้าห้องสอบ 0 / 10 รายการ
คำเตือน: เตรียม Seed Data ที่สมจริงและวิดีโอสำรอง (Backup Screen Recording) เสมอ เผื่ออินเทอร์เน็ตห้องสอบขัดข้อง Slide 05 — Live Demo Readiness
สถาปัตยกรรมซอฟต์แวร์ CLO2 · Layered Architecture & 6-Table Relational Schema
SLIDE 06 / 10

สถาปัตยกรรมแยกชั้น (Decoupled Layers) และแบบจำลองฐานข้อมูล 6 ตารางหลัก

คลิกที่ชื่อตารางด้านล่างเพื่อตรวจโครงสร้างคีย์หลัก (PK), คีย์นอก (FK) และเหตุผลการออกแบบเพื่อตอบคณะกรรมการ

แผนผังสถาปัตยกรรมแยกส่วน UI ออกจาก Business Logic
1. Presentation (UI) POS Screen / Cart Inventory Dashboard Low-Stock Alerts หลักการแยกส่วน: ห้ามคำนวณตัดสต็อก ในโค้ดฝั่งหน้าจอตรงๆ 2. API & Business Logic Auth & Role Guard Checkout & Tax Calc Atomic Stock Service ข้อดีในการสอบ: เขียน Unit/API Test ได้โดยไม่ต้องพึ่ง UI 3. Relational DB Users · Categories Products · Inventory Orders · Order_Items ACID Transaction ป้องกันสต็อกติดลบ เมื่อยิงออเดอร์พร้อมกัน
หลัก Agile Clean Architecture: เมื่อแยก UI ออกจาก Business Rules ทำให้สามารถสร้าง Automated Acceptance Tests และตรวจจับข้อผิดพลาดของ API Contracts ได้ตั้งแต่เนิ่นๆ (หลีกเลี่ยง Code Rot)
สำรวจโครงสร้างฐานข้อมูล 6 ตาราง (ER SCHEMA EXPLORER)
อ้างอิง: Relational Database Schema ในเอกสารโครงการ POS และ Agile Clean Architecture Slide 06 — Architecture & Schema
กลยุทธ์การตอบคำถาม Architecture Defense & Committee Q&A Simulator
SLIDE 07 / 10

ตอบคำถามเชิงเทคนิคอย่างไรให้ได้คะแนนเต็ม: หลักเหตุผล + Trade-off + แผนสำรอง

เลือกคำถามยอดฮิตของคณะกรรมการสอบกลางภาค เพื่อเปรียบเทียบคำตอบที่ควรเลี่ยงกับคำตอบระดับวิศวกรรม

เลือกคำถามจำลองจากคณะกรรมการ (5 สถานการณ์)
จำไว้เสมอ: หากยังไม่สมบูรณ์ ให้ยอมรับข้อจำกัดอย่างตรงไปตรงมา พร้อมระบุ Issue/Sprint ที่จะแก้ในสัปดาห์ที่ 9–11 Slide 07 — Q&A Defense Strategy
ความเสี่ยงและ PDPA CLO3 · Concurrency Risk Mitigation & Data Privacy
SLIDE 08 / 10

เจาะลึกความเสี่ยงอันดับ 1 ของ Grocery POS: สต็อกตัดขนานพร้อมกันและการคุ้มครองข้อมูล PDPA

คณะกรรมการประเมิน CLO3 จากความสามารถในการมองเห็นความเสี่ยงเชิงเทคนิคที่เกิดขึ้นจริง ไม่ใช่แค่ความเสี่ยงทั่วไป

1. ความเสี่ยงตัดสต็อกขนานพร้อมกัน (Race Condition) High Impact

เมื่อร้าน Grocery มีเครื่องแคชเชียร์ 2 จุดขายสินค้าตัวสุดท้ายพร้อมกัน หากอ่านค่าสต็อกก่อนแล้วค่อยอัปเดตแยกกัน ยอดสต็อกจะผิดพลาดหรือติดลบ

แนวทาง ผลลัพธ์เมื่อขายพร้อมกัน 2 จุด (เหลือ 1 ชิ้น)
แบบไม่มี Transaction ทั้งเครื่อง A และ B อ่านเจอว่าเหลือ 1 → ขายซ้ำได้ 2 ชิ้น (สต็อกเพี้ยน)
Atomic Update + DB Lock ใช้ BEGIN TRANSACTION และเงื่อนไข WHERE stock >= qty → เครื่อง A สำเร็จ เครื่อง B ได้แจ้งเตือนสต็อกไม่พออย่างปลอดภัย
2. จริยธรรมข้อมูลและ PDPA ในชุดข้อมูล POS Privacy by Design
  • 01
    Data Minimization (เก็บเท่าที่จำเป็น): ระบบขายหน้าร้านทั่วไปไม่จำเป็นต้องบังคับเก็บเลขบัตรประชาชนหรือเบอร์โทรลูกค้าลงในตารางวิเคราะห์ยอดขาย
  • 02
    Anonymization ก่อนวิเคราะห์: หากมีการส่งออกข้อมูลไปวิเคราะห์พฤติกรรมการซื้อหรือ Peak Hours ต้องลบข้อมูลระบุตัวตน (PII) ออกจาก Dataset เสมอ
  • 03
    Credential & Access Control: แยกสิทธิ์ Cashier กับ Manager ห้ามส่ง password_hash กลับใน API Response เด็ดขาด
สิ่งที่ต้องเตรียมเข้าตาราง Risk Register ในสไลด์: ระบุ (1) รหัสความเสี่ยง (2) โอกาสเกิด × ผลกระทบ (3) มาตรการป้องกัน (Mitigation Plan) และ (4) สถานะปัจจุบันหลังทดสอบใน Sprint 1
อ้างอิง: Project Risk Management & PDPA Compliance ในเอกสารโครงงานและสัปดาห์ที่ 11 Slide 08 — Risk & PDPA
เกณฑ์ประเมิน 100 คะแนน Evaluation Committee Rubrics · Self-Assessment Simulator
SLIDE 09 / 10

เกณฑ์การประเมินคณะกรรมการ (4 ด้าน × 25 คะแนน): ประเมินทีมของคุณก่อนขึ้นสอบจริง

ปรับคะแนนจำลองทั้ง 4 ด้านเพื่อดูระดับคุณภาพตาม Rubric จริงของรายวิชา 1145 204 และส่งออกผลประเมินเป็นไฟล์ CSV

ผลประเมินรวมจำลอง (MIDTERM SCORE SIMULATOR)
84
/ 100 คะแนน
ระดับคุณภาพ ช่วงคะแนน (ต่อด้าน 25) ความหมายตามเกณฑ์
ดีเยี่ยม 22–25 ระบบและหลักฐานครบสมบูรณ์ แสดงความเข้าใจเชิงลึก
ดี 18–21 ชัดเจน ครอบคลุม มีจุดปรับปรุงเล็กน้อย
พอใช้ 14–17 ทำงานได้บางส่วน ขาดความลึกหรือเวลาเกินกำหนด
ปรับปรุง 0–13 ไม่พร้อมสาธิต หรือตอบคำถามเชิงเทคนิคไม่ได้
อ้างอิง: เกณฑ์ประเมิน Midterm Progress Defense (CLO1–CLO4) สำหรับ Google Classroom Rubric Slide 09 — Committee Rubrics
บทสรุปและแผนปฏิบัติ 48-Hour Action Plan & Post-Midterm Feedback Loop
SLIDE 10 / 10

เตรียมพร้อม 48 ชั่วโมงก่อนสอบ และเปลี่ยนข้อเสนอแนะเป็นพลังของ Sprint 2

ข้อเสนอแนะจากคณะกรรมการในสัปดาห์ที่ 8 คือข้อมูลตั้งต้นสำคัญของงานสัปดาห์ที่ 9–12 และความสำเร็จของ Final Defense

แผนปฏิบัติการ 48 ชั่วโมงก่อนขึ้นสอบ (PRE-DEFENSE)
  • T-48h
    Freeze Branch & Clean Commits: รวมโค้ดที่เสถียรเข้าสาขาหลัก ตรวจสอบ README.md และล้างไฟล์ขยะออกจาก Repository
  • T-24h
    เตรียมข้อมูลตัวอย่าง & วิดีโอสำรอง: รีเซ็ต Seed Data ให้สะอาด พร้อมอัดคลิปสาธิตความยาว 3 นาทีสำรองไว้ในเครื่อง
  • T-12h
    ซ้อมจับเวลาเต็มรูปแบบ: ซ้อมพูดครบทุกคนตาม Timebox 12 นาที พร้อมฝึกตอบคำถามเชิงเทคนิค 5 ข้อจาก Slide 07
  • T-01h
    ตั้งคนจด Midterm Feedback Log: มอบหมายสมาชิก 1 คนจดทุกคำแนะนำของกรรมการระหว่าง Q&A แบบคำต่อคำ
เส้นทางต่อยอดหลังกลางภาค (WEEK 9–15 BRIDGE)
  • W09
    Midterm Feedback Log & Sprint 2: ปรับ Product Backlog ตามความเห็นคณะกรรมการและพัฒนาฟีเจอร์ระดับสูง
  • W10
    System Integration & API Alignment: เชื่อม Frontend–Backend–DB ครบวงจร พร้อม API Docs และ Error Handling
  • W11
    Risk & Quality Review: อัปเดต Risk Log จริงที่เกิดระหว่างพัฒนาและปิดปัญหาคอขวด
  • W12–15
    QA Testing & Final Defense: Unit/Integration/Usability Test (W12) ก่อนส่งมอบระบบ Live URL และรายงานฉบับสมบูรณ์ (W13–15)
สรุปภาพรวมความพร้อมของทีมคุณตอนนี้:
1145 204 Sophomore Project · ขอให้นักศึกษาทุกทีมนำเสนอความก้าวหน้าได้อย่างมั่นใจ Slide 10 — Action Plan