SLIDE 01
หลักสูตร วท.บ. วิทยาการข้อมูลและนวัตกรรมซอฟต์แวร์ (DSSI)
เปลี่ยนซอฟต์แวร์ที่ใช้งานได้ ให้เป็นผลงานที่ส่งมอบได้จริง
การบรรยายสัปดาห์ที่ 13 มุ่งเน้นการจัดทำชุดเอกสารส่งมอบฉบับสมบูรณ์สำหรับโครงงานชั้นปีที่ 2 (1145 204) โดยใช้แพลตฟอร์มจุดขายร้านค้าปลีกและคลังสินค้า (Grocery POS Platform) เป็นกรณีศึกษาหลัก
4 องค์ประกอบหลักของการส่งมอบในสัปดาห์ที่ 14–15
-
DELIVERABLE 01 · PDF
รายงานโครงงานฉบับสมบูรณ์ (บทที่ 1–5)
ครอบคลุมที่มาของปัญหา ข้อกำหนดความต้องการ (SRS) สถาปัตยกรรมฐานข้อมูล ผลการทดสอบ และสรุปผล
-
DELIVERABLE 02 · PDF + ENV
คู่มือการติดตั้งระบบ (Deployment Guide)
ระบุสเปกขั้นต่ำ การตั้งค่าตัวแปรสภาพแวดล้อม (.env) สคริปต์ฐานข้อมูล และการตรวจสอบหลังติดตั้ง
-
DELIVERABLE 03 · PDF + SOP
คู่มือการใช้งานสำหรับผู้ใช้งานปลายทาง (End-User Manual)
อธิบายขั้นตอนปฏิบัติงานตามบทบาทผู้ใช้ (แคชเชียร์ ผู้จัดการคลัง ผู้ดูแลระบบ) พร้อมตารางแก้ไขปัญหาเบื้องต้น
-
DELIVERABLE 04 · APA 7TH + REPO
การอ้างอิงทางวิชาการและซอร์สโค้ดบน GitHub
รายการอ้างอิงมาตรฐาน APA 7th Edition คู่กับ Live System URL และไฟล์ README.md ที่สมบูรณ์
DURATION
15 สัปดาห์
ขอบเขตโครงงานสำหรับทีม 1–3 คน
ASSESSMENT WEIGHT
50 / 50
อาจารย์ที่ปรึกษา 50% + คณะกรรมการสอบ 50%
MARTIN'S FIRST LAW OF DOCUMENTATION
ผลิตเอกสารเฉพาะส่วนที่มีความจำเป็นและสร้างคุณค่าชัดเจน
เอกสารที่ดีในงานวิศวกรรมซอฟต์แวร์ไม่ได้วัดจากจำนวนหน้า แต่ต้องตอบคำถาม 3 ข้อได้ทันที:
ระบบแก้ปัญหาอะไร (รายงาน 5 บท), ติดตั้งให้ทำงานอย่างไร (Deployment Guide), และ พนักงานหน้าร้านใช้งานอย่างไร (User Manual)
SLIDE 02
AGILE VS. ACADEMIC RIGOR
สมดุลระหว่าง เอกสารแบบ Agile กับ มาตรฐานวิชาการ AUN-QA
ความเข้าใจผิดที่พบบ่อยคือ Agile แปลว่า "ไม่ต้องเขียนเอกสาร" ทั้งที่จริงแล้ว Agile เน้นเอกสารที่กระชับ มีชีวิต และตรวจสอบย้อนกลับได้ (Traceability)
SLIDE 03
FINAL REPORT ARCHITECTURE
โครงสร้างรายงานฉบับสมบูรณ์ บทที่ 1–5 และการเชื่อมโยงข้อมูล
รายงานทางวิชาการที่ดีต้องมีเส้นด้ายเชื่อมโยงตั้งแต่ปัญหาในบทที่ 1 ไปจนถึงบทสรุปในบทที่ 5 คลิกเลือกแต่ละบทด้านซ้ายเพื่อตรวจสอบองค์ประกอบบังคับสำหรับ Grocery POS Platform
SLIDE 04
CHAPTERS 1 & 2 DEEP DIVE
เจาะลึก บทที่ 1–2: นิยามปัญหาหน้าร้านค้าปลีกและกรอบจริยธรรมข้อมูล
การเขียนบทที่ 1 และบทที่ 2 ต้องชี้ให้เห็นช่องว่างของระบบเดิม (Pain Points) และระบุมาตรฐานทางเทคนิคกับกฎหมาย PDPA อย่างเป็นรูปธรรม
CHAPTER 01 · PROBLEM & SCOPE
การกำหนดขอบเขตที่พัฒนาได้จริงใน 15 สัปดาห์
-
ปัญหาหลักของร้านขายของชำ (Problem Statement):
จดบันทึกรายการขายด้วยมือ ทำให้ไม่ทราบต้นทุนคงคลังแบบ Real-time สินค้าหมดอายุหรือขายดีไม่ถูกแจ้งเตือนล่วงหน้า และเกิดความเสี่ยงสต็อกติดลบเมื่อคิดเงินพร้อมกัน
-
การตั้งวัตถุประสงค์แบบวัดผลได้:
ใช้คำกริยาที่ตรวจสอบได้ เช่น "พัฒนาเว็บแอปพลิเคชัน POS ที่คำนวณยอดขายและตัดสต็อกอัตโนมัติ" แทนคำกว้าง ๆ อย่าง "เพื่อให้ร้านค้าทันสมัยขึ้น"
-
ขอบเขตของโครงงานปี 2 (Practiced Level):
เน้นระบบ Single-branch POS ฐานข้อมูล Relational (3NF) การจัดการสต็อกและการแจ้งเตือน (ยังไม่ขยายไปสู่ AI Forecasting หรือ Microservices หลายสาขาซึ่งเป็นขอบเขตของปี 3)
CHAPTER 02 · LITERATURE & PDPA
หัวข้อทบทวนวรรณกรรมที่ต้องปรากฏใน Grocery POS
| หัวข้อทบทวน |
ประเด็นที่ต้องวิเคราะห์เปรียบเทียบ |
| ซอฟต์แวร์ POS ในท้องตลาด |
เปรียบเทียบฟีเจอร์ ข้อจำกัด และค่าใช้จ่ายของระบบร้านค้าปลีก 2–3 ราย เพื่อยืนยันเหตุผลของการพัฒนา |
| Tech Stack & 3NF DB |
อธิบายเหตุผลในการเลือก Node.js / Python และฐานข้อมูลเชิงสัมพันธ์ที่รองรับ ACID Transaction |
| Agile & Scrum 3 Sprints |
หลักการ User Story, Acceptance Criteria และ Burndown Chart สำหรับงานทีม 1–3 คน |
| จริยธรรมข้อมูล (PDPA) |
หลักการ Data Minimization: ลบเบอร์โทรศัพท์และรหัสบัตรประชาชนลูกค้าออกจากชุดข้อมูลรายงานสรุปยอดขาย |
SLIDE 05
CHAPTER 3 · DATABASE & AGILE ARTIFACTS
เจาะลึก บทที่ 3: สถาปัตยกรรมฐานข้อมูล Grocery POS และหลักฐาน Agile
บทที่ 3 ต้องแสดง ER Diagram ระดับ 3NF, User Stories และแผนบริหารความเสี่ยง คลิกเลือกตารางฐานข้อมูลด้านล่างเพื่อตรวจโครงสร้างฟิลด์มาตรฐาน
AGILE ARTIFACTS IN CH 03
ตัวอย่าง User Story และ Acceptance Criteria
User Story: "ในฐานะพนักงานแคชเชียร์ (Cashier) ฉันต้องการสแกนบาร์โค้ดและตัดยอดสินค้าในคลังอัตโนมัติ เพื่อออกใบเสร็จและป้องกันการขายสินค้าเกินจำนวนคงเหลือ"
ACCEPTANCE CRITERIA (GIVEN-WHEN-THEN)
Given สินค้า "นมสดพาสเจอร์ไรส์ 1 ลิตร" มีคงเหลือ 3 ขวด
When แคชเชียร์กดชำระเงินจำนวน 2 ขวด
Then ระบบบันทึกคำสั่งซื้อ ลดคงเหลือเป็น 1 ขวด และสร้างแจ้งเตือนทันทีเพราะต่ำกว่า reorder_level
RISK MITIGATION IN CH 03
ความเสี่ยง: การตัดสต็อกขนานพร้อมกัน (Race Condition)
ระบุแนวทางแก้ไขในรายงานบทที่ 3 ด้วยการใช้ Database Transaction ร่วมกับ SELECT ... FOR UPDATE หรือ Atomic Update เพื่อไม่ให้ยอดสต็อกติดลบเมื่อมีจุดขายมากกว่า 1 เครื่อง
SLIDE 06
CHAPTERS 4 & 5 · EVALUATION & ROADMAP
เจาะลึก บทที่ 4–5: การรายงานผลเชิงประจักษ์และสรุปผลโครงงาน
บทที่ 4 ต้องนำเสนอหลักฐานการทดสอบระบบและรายงานวิเคราะห์ยอดขายจริง ไม่ใช่เพียงการวางภาพหน้าจอ (Screenshot) เปล่า ๆ ส่วนบทที่ 5 คือการตอบวัตถุประสงค์ทีละข้อ
CHAPTER 04 · SAMPLE ANALYTICS OUTPUT
ตัวอย่างแผนภูมิรายงานยอดขายแยกตามช่วงเวลา (Peak Hours)
แสดงให้กรรมการเห็นว่าข้อมูลจากตาราง Orders ถูกสรุปเป็นข้อมูลเชิงตัดสินใจได้จริง (หน่วย: บาท/ชั่วโมง)
CHAPTER 04 · TEST EVIDENCE SUMMARY
ตารางสรุปผลการทดสอบระบบ (Test Results Matrix)
| รหัสทดสอบ |
กรณีทดสอบ (Grocery POS) |
ผลลัพธ์ |
| TC-01 |
สแกนบาร์โค้ด + คำนวณภาษี/ส่วนลด + ใบเสร็จ |
PASS |
| TC-02 |
ตัดสต็อกพร้อมกัน 2 แคชเชียร์ (Concurrency) |
PASS |
| TC-03 |
แจ้งเตือนเมื่อ stock_quantity ≤ reorder_level |
PASS |
| TC-04 |
ตรวจ Log หลังขาย: ไม่เก็บ PII ลูกค้า (PDPA) |
PASS |
CHAPTER 05 · PROGRESSION TO YEAR 3
แนวทางต่อยอดโครงงานสู่ชั้นปีที่ 3 (Mastery Level)
ระบุข้อเสนอแนะเชิงวิชาการในบทที่ 5 เช่น การต่อยอดฝั่ง Data Science (ระบบ AI ทำนายยอดขายและแนะนำสินค้า) หรือฝั่ง Software Innovation (ปรับสู่ Microservices / Event-Driven บน Cloud เพื่อรองรับหลายสาขา)
SLIDE 07
DEPLOYMENT GUIDE · PART 1
คู่มือการติดตั้งระบบ: ความต้องการของระบบและการตั้งค่าสภาพแวดล้อม
คู่มือติดตั้งที่ดีต้องช่วยให้ผู้ประเมินหรือผู้ดูแลร้านรายใหม่สามารถนำซอฟต์แวร์ไปติดตั้งบนเครื่องใหม่ได้สำเร็จโดยไม่ต้องเดา เลือกสภาพแวดล้อมเพื่อตรวจดูการตั้งค่าที่แนะนำ
SYSTEM REQUIREMENTS (PREREQUISITES)
ข้อกำหนดขั้นต่ำที่ต้องระบุในคู่มือติดตั้ง
- Runtime & Engine: Node.js v20 LTS หรือ Python 3.11+, npm/pip
- Database Server: PostgreSQL 15+ หรือ MySQL 8.0+ (รองรับ ACID)
- POS Peripherals (อุปกรณ์ต่อพ่วง): เครื่องอ่านบาร์โค้ด USB (HID Keyboard Mode), เครื่องพิมพ์ใบเสร็จความร้อน 58mm/80mm
- Browser Support: Chrome / Edge เวอร์ชันล่าสุดสำหรับหน้าจอแคชเชียร์
SECURITY RULE · GIT HYGIENE
ห้าม Commit ไฟล์ .env ที่มีรหัสผ่านจริงลง GitHub
ให้ส่งมอบเฉพาะไฟล์ .env.example ที่มีชื่อตัวแปรและคำอธิบาย และเพิ่ม .env ใน .gitignore เสมอ
SLIDE 08
DEPLOYMENT GUIDE · PART 2
ขั้นตอนการติดตั้ง Step-by-Step และรายการทดสอบหลังติดตั้ง (Smoke Test)
แบ่งคำสั่งติดตั้งออกเป็นขั้นตอนเรียงลำดับชัดเจน พร้อมระบุผลลัพธ์ที่คาดหวัง (Expected Output) และวิธีตรวจสอบความสมบูรณ์หลังเปิดบริการ
# 1. ดึงซอร์สโค้ดและติดตั้งไลบรารี
git clone https://example.com/team/grocery-pos.git
cd grocery-pos && npm ci
# 2. คัดลอกค่าเริ่มต้นและสร้างตารางฐานข้อมูล 3NF + ข้อมูลสินค้าเริ่มต้น
cp .env.example .env
psql "$DATABASE_URL" -f database/schema.sql
psql "$DATABASE_URL" -f database/seed_grocery_items.sql
# 3. สร้าง Build สำหรับ Production และเริ่มการทำงาน
npm run build
npm run start
# 4. ตรวจสอบสถานะ API และการเชื่อมต่อฐานข้อมูล
curl -i http://localhost:3000/api/health
# Expected: HTTP/1.1 200 OK {"status":"ok","db":"connected"}
POST-DEPLOYMENT SMOKE TEST
5 รายการตรวจสอบทันทีหลังติดตั้งเสร็จ
-
1. ตรวจสอบบัญชีเริ่มต้น (Default Auth):
เข้าสู่ระบบด้วยบัญชี Admin/Cashier ทดสอบ และบังคับเปลี่ยนรหัสผ่านเริ่มต้นทันที
-
2. ทดสอบ Schema & Seed Data:
เปิดหน้าคลังสินค้า ต้องพบหมวดหมู่ (เช่น เครื่องดื่ม ของแห้ง ผักผลไม้) และสินค้าเริ่มต้นครบถ้วน
-
3. ทดสอบวงจรขาย 1 รายการ (End-to-End Checkout):
คิดเงิน 1 รายการด้วย PromptPay หรือเงินสด แล้วตรวจตาราง
Inventory_Stock ว่าลดลงตรงตามจำนวนที่ขาย
-
4. ทดสอบแจ้งเตือนจุดสั่งซื้อใหม่ (Low Stock Alert):
ขายสินค้าจนต่ำกว่า
reorder_level ระบบต้องแสดงป้ายแจ้งเตือนทันที
-
5. ตรวจสอบการพิมพ์ใบเสร็จ (Receipt Print Preview):
ตรวจสอบการตัดขอบกระดาษ 58mm/80mm และยอดรวมภาษีให้ตรงกัน
SLIDE 09
END-USER OPERATION MANUAL
คู่มือการใช้งานตามบทบาทผู้ใช้ และตัวจำลองการคิดเงิน Grocery POS
คู่มือผู้ใช้ต้องแบ่งตามสิทธิ์การเข้าถึง (role_enum) เพื่อไม่ให้พนักงานสับสนกับเมนูที่ไม่เกี่ยวข้อง ทดลองสลับบทบาทและลองกดจำลองสถานการณ์หน้าร้านทางขวา
INTERACTIVE POS SOP SIMULATOR
จำลองการขายหน้าร้าน (Use Case: Check Out Item)
สต็อกนมสด: 5
POS TERMINAL LOG
พร้อมรับออเดอร์: กดปุ่ม "1. สแกนบาร์โค้ด" เพื่อดูการทำงานปกติ (Primary Course) หรือกด "2. บาร์โค้ดเสีย" เพื่อดูขั้นตอนทางเลือก (Alternative Course)
SLIDE 10
SOP DESIGN & TROUBLESHOOTING
หลักการเขียนขั้นตอนปฏิบัติงาน (SOP) และตารางแก้ไขปัญหาเบื้องต้น
ผู้ใช้ปลายทางไม่ใช่โปรแกรมเมอร์ คู่มือจึงต้องใช้ภาษาที่ตรงไปตรงมา มีลำดับเลขกำกับภาพหน้าจอ ระบุผลลัพธ์ที่ควรเห็น และมีตารางแก้ปัญหาเฉพาะหน้า
TROUBLESHOOTING MATRIX · GROCERY POS
ตัวอย่างตารางแก้ไขปัญหาเบื้องต้นในคู่มือผู้ใช้
| อาการที่พบหน้าร้าน |
สาเหตุที่เป็นไปได้ |
วิธีแก้ไขเบื้องต้น (Self-Service) |
| สแกนบาร์โค้ดแล้วไม่ขึ้นรายการสินค้า |
ฉลากชำรุด หรือยังไม่ได้เพิ่มสินค้าเข้าฐานข้อมูล |
พิมพ์รหัสสินค้าหรือชื่อสินค้าในช่องค้นหาด้วยตนเอง หากยังไม่พบให้แจ้งผู้จัดการเพิ่ม SKU |
| ระบบขึ้นเตือน "สินค้าคงเหลือไม่เพียงพอ" |
สต็อกในระบบหมด หรือมีแคชเชียร์อีกเครื่องเพิ่งตัดยอดไปก่อนหน้า |
ตรวจนับสินค้าจริงบนชั้นวาง หากมีสินค้าให้ผู้จัดการร้านปรับยอดรับเข้า (Stock Adjustment) |
| ชำระ PromptPay แล้วยังไม่ขึ้นยืนยัน |
อินเทอร์เน็ตหน้าร้านช้า หรือยังไม่ได้กดตรวจสถานะซ้ำ |
กดปุ่ม "ตรวจสอบสถานะการโอน" 1 ครั้ง ตรวจสอบสลิปของลูกค้า และติดต่อฝ่าย Support หากซ้ำซ้อน |
| เครื่องพิมพ์ใบเสร็จไม่ออกกระดาษ |
กระดาษหมด ฝาเครื่องปิดไม่สนิท หรือสาย USB หลวม |
เปิดฝาเปลี่ยนม้วนกระดาษ 58mm ปิดให้ดังคลิก แล้วสั่ง "พิมพ์ใบเสร็จย้อนหลัง" ในเมนูประวัติขาย |
ANATOMY OF GOOD USER MANUAL
4 กฎเหล็กของการเขียนคู่มือผู้ใช้
-
1. ภาพหน้าจอต้องมีหมายเลขกำกับ (Callouts):
วงกรอบสีน้ำเงินพร้อมเลข 1, 2, 3 ชี้ตำแหน่งปุ่มจริง ตรงกับข้อความอธิบายทีละขั้น
-
2. แยกขั้นตอนปกติ (Primary) กับข้อยกเว้น (Exception):
อธิบายสิ่งที่ต้องทำเมื่อเกิดข้อผิดพลาด เช่น กรอกราคาผิดหรือยกเลิกบิล
-
3. บอกผลลัพธ์หลังคลิกทุกครั้ง:
เช่น "เมื่อกดปุ่ม 'ยืนยันการขาย' ระบบจะเปิดหน้าต่างพิมพ์ใบเสร็จอัตโนมัติ"
-
4. ระบุช่องทางขอความช่วยเหลือ (Support Contact):
ระบุเวลาทำการ ผู้รับผิดชอบ และข้อมูลที่ผู้ใช้ต้องแจ้งเมื่อเกิดปัญหา (รหัสข้อผิดพลาด / ภาพหน้าจอ)
SLIDE 11
ACADEMIC INTEGRITY · APA 7TH EDITION
การอ้างอิงทางวิชาการมาตรฐาน APA 7th Edition สำหรับรายงานโครงงาน
ข้อมูล ทฤษฎี เอกสารกรอบแนวคิด หรือซอฟต์แวร์ทุกชิ้นที่นำมากล่าวอ้างในบทที่ 1–5 ต้องมีการอ้างอิงในเนื้อหา (In-text Citation) สอดคล้องกับบรรณานุกรมท้ายเล่ม 100%
SLIDE 12
FINAL SUBMISSION READINESS
รายการตรวจสอบความพร้อมก่อนส่งมอบงาน สัปดาห์ที่ 14–15
ตรวจสอบสถานะเอกสารทั้ง 4 หมวดก่อนนัดสอบป้องกันโครงงาน สถานะที่ติ๊กเลือกจะถูกบันทึกอัตโนมัติและสามารถส่งออกเป็นไฟล์ CSV แนบส่งทีมได้
FINAL DEFENSE PACKAGE
สไลด์สอบป้องกันโครงงาน (15 นาที)
- นาทีที่ 1–3: ปัญหาและวัตถุประสงค์ (เชื่อมโยง Grocery POS)
- นาทีที่ 4–7: สถาปัตยกรรม 3NF, Agile Sprints & ความเสี่ยง
- นาทีที่ 8–12: Live Demo ระบบจริง (หน้าร้าน + ตัดสต็อก + รายงาน)
- นาทีที่ 13–15: ผลการทดสอบ สรุปผล และข้อเสนอแนะ
SOURCES & REFERENCES
เอกสารอ้างอิงประกอบการสอนสัปดาห์ที่ 13
1. หลักสูตร วท.บ. สาขาวิชาวิทยาการข้อมูลและนวัตกรรมซอฟต์แวร์ (ปรับปรุง พ.ศ. 2568) และ มคอ.3 รายวิชา 1145 204.
2. ตุ๊กตาโครงงานชั้นปี 1–3 ระบบ POS ร้านค้าและแนวทางส่งมอบงาน 1145 204.
3. Guide to AUN-QA Assessment at Programme Level (Version 4.0).
4. Martin, R. C. (2006). Agile Principles, Patterns, and Practices in C#.
5. Scaled Agile (2023) และ Thoughtworks Agile Maturity Model.