1145 204 · WEEK 13

การจัดทำเอกสารโครงงานและคู่มือผู้ใช้ — กรณีศึกษา Grocery POS Platform

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 ถูกสรุปเป็นข้อมูลเชิงตัดสินใจได้จริง (หน่วย: บาท/ชั่วโมง)

9,000 6,000 3,000 0 3,520 08–10 4,600 10–12 5,150 12–14 3,140 14–16 8,240 16–18 ช่วงพีคเลิกงาน 6,610 18–20
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

คู่มือการติดตั้งระบบ: ความต้องการของระบบและการตั้งค่าสภาพแวดล้อม

คู่มือติดตั้งที่ดีต้องช่วยให้ผู้ประเมินหรือผู้ดูแลร้านรายใหม่สามารถนำซอฟต์แวร์ไปติดตั้งบนเครื่องใหม่ได้สำเร็จโดยไม่ต้องเดา เลือกสภาพแวดล้อมเพื่อตรวจดูการตั้งค่าที่แนะนำ

.ENV.DEVELOPMENT.EXAMPLE

          
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) และวิธีตรวจสอบความสมบูรณ์หลังเปิดบริการ

STEP 1–2 · CLONE, INSTALL & DB MIGRATION
# 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
STEP 3–4 · BUILD, START & HEALTH CHECK
# 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 แนบส่งทีมได้

READINESS SCORE
0%
ผ่านแล้ว 0 จาก 12 รายการ
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.