บทที่ 2 กระบวนการพัฒนาซอฟต์แวร์และแผนการดำเนินงาน (Software Development Process & Project Plan)
บทนี้แสดงภาพรวมเชิงบริหารวิศวกรรมซอฟต์แวร์ ตั้งแต่การเลือกใช้มาตรฐานสากล ISO/IEC 29110 ในการวางโครงสร้างวงจรชีวิตซอฟต์แวร์ (Software Development Life Cycle) การใช้การพัฒนาซอฟต์แวร์แบบวนซ้ำ (Iterative Development Model) ไปจนถึงการจำแนกทรัพยากร วิเคราะห์ความเสี่ยง และกลยุทธ์ทางสถาปัตยกรรมเทคโนโลยีที่ตอบโจทย์เงื่อนไขเป้าหมายอย่างเป็นรูปธรรม
สารบัญ
- 2.1 ภาพรวมกระบวนการพัฒนาซอฟต์แวร์ (Overview of Software Development Process)
- 2.2 รูปแบบและขั้นตอนการพัฒนา (Development Model)
- 2.3 แผนการดำเนินงาน (Project Plan)
- 2.4 การประเมินทรัพยากรและความพยายาม (Effort & Resources)
- 2.5 ขอบเขตและข้อจำกัด (Scope & Limitations)
- 2.6 เครื่องมือและเทคโนโลยี (Technology Stack)
- 2.7 การจัดการการกำหนดค่า (Configuration Management)
- 2.8 การจัดการความเสี่ยง (Risk Management)
- 2.9 สถิติโครงการ (Project Statistics)
- 2.10 บทสรุปกระบวนการพัฒนา (Chapter Summary)
2.1 ภาพรวมกระบวนการพัฒนาซอฟต์แวร์ (Overview of Software Development Process)
โครงการ TaijiFlow AI เลือกใช้มาตรฐาน ISO/IEC 29110 – Software Life Cycle Profiles and Guidelines for Very Small Entities [12] เป็นกรอบบริหารจัดการและพัฒนาซอฟต์แวร์ตลอดทั้งโครงการ มาตรฐานดังกล่าวถูกออกแบบมาสำหรับองค์กรหรือทีมพัฒนาขนาดเล็ก (ไม่เกิน 25 คน) จึงสอดคล้องกับบริบทของโครงการการค้นคว้าอิสระฉบับนี้ ซึ่งดำเนินการโดยนักพัฒนาเพียง 1 คน ภายใต้การให้คำแนะนำของผู้เชี่ยวชาญเฉพาะด้าน (Domain Expert) ทางฝั่งมวยไท้เก๊ก
เหตุผลในการนำมาตรฐาน ISO/IEC 29110 มาบังคับใช้ มี 3 ประการสำคัญ ได้แก่
- ประการแรก สามารถกำหนดกรอบเอกสารที่ตรวจสอบย้อนกลับได้ ครอบคลุมตั้งแต่แผนโครงการ (Project Plan) ไปจนถึงคู่มือการใช้งาน (User Manual)
- ประการที่สอง ช่วยสร้างกลไกเชื่อมโยงความสัมพันธ์ (Traceability) เริ่มจากการรวบรวมความต้องการ ไปสู่การออกแบบ และจัดทำเป็นกรณีทดสอบอย่างเป็นรูปธรรม
- ประการที่สาม เอกสารทั้งหมดที่จัดทำขึ้น จะกลายเป็นโครงสร้างพื้นฐานที่มั่นคง สำหรับการส่งมอบให้ผู้พัฒนาใน Phase 2 และ 3 ต่อไป
ISO/IEC 29110 กำหนดสองกระบวนการหลักที่โครงการนี้นำมาใช้ ได้แก่ Project Management (PM) Process และ Software Implementation (SI) Process
ภาพที่ 2.1 ภาพรวมวัฏจักรการพัฒนาซอฟต์แวร์ตามมาตรฐาน ISO/IEC 29110
2.1.1 กระบวนการบริหารจัดการโครงการ (Project Management Process)
กระบวนการ PM ครอบคลุมการวางแผน ควบคุม และปิดโครงการ ซึ่งในทางปฏิบัติโครงการนี้ดำเนินการผ่าน 3 กิจกรรมหลัก ดังแสดงลำดับขั้นตอนในภาพที่ 2.2
ภาพที่ 2.2 กระบวนการบริหารจัดการโครงการ (Project Management Process Overview)
ขั้นตอนที่มีความสำคัญเฉพาะต่อโครงการนี้
PM.01 – Project Planning: จัดทำเอกสาร Project Plan กำหนดปัญหา วัตถุประสงค์ ขอบเขต แผนทรัพยากร และ Gantt Chart พร้อมวางแผนการจัดทำเอกสาร SRS, SDD และ Test Plan ล่วงหน้าก่อนเริ่มพัฒนา เพื่อให้ทุก artifact มีเป้าหมายชัดเจน
PM.02 – Project Execution & Control: ติดตามความคืบหน้าผ่าน Progress Status Record ซึ่งบันทึกกิจกรรมและสถานะในแต่ละเวอร์ชัน บันทึกการเปลี่ยนแปลงผ่าน Change Request (CR-01 ถึง CR-03) เช่น CR-01 ที่เกิดเมื่อพบว่า Body Calibration เดิมไม่รองรับผู้ฝึกที่มีสัดส่วนที่แตกต่างกันมาก แต่ผู้เชี่ยวชาญยืนยันว่าความแตกต่างเหล่านี้ส่งผลต่อความยุติธรรมของการประเมินท่ารำจริง
PM.03 – Project Closure: เตรียมสิ่งส่งมอบครบถ้วนเมื่อระบบและเอกสารเสร็จสมบูรณ์ ได้แก่ ซอร์สโค้ด เอกสารชุด ISO 29110 และคู่มือ เพื่อส่งมอบสถาบันและประกอบการสอบป้องกันโครงการ แผนภูมิความสัมพันธ์และกิจกรรมได้ถูกสรุปเพิ่มเติมไว้ดังมุมมองในภาพที่ 2.3
ภาพที่ 2.3 แผนภูมิแสดงความสัมพันธ์ในกระบวนการ PM (PM Process Flow Diagram)
ตัวอย่างที่แสดงให้เห็นว่ากระบวนการ PM ทำงานจริงคือช่วง v1.3.0 ซึ่งทีมพัฒนาตรวจพบว่าโครงสร้างเอกสารและการตั้งชื่อ UML ไม่สอดคล้องกัน จึงบันทึก Change Request และดำเนินการปรับโครงสร้างทั้งหมดอย่างเป็นระบบ พร้อมอัปเดต CHANGELOG และ Progress Status Record ให้สะท้อนสถานะจริง รายละเอียดกิจกรรมและหมวดหมู่เอกสารหลักที่เกี่ยวข้อง สามารถจำแนกได้ดังตารางที่ 2.1
ตารางที่ 2.1 กิจกรรมในกระบวนการ Project Management Process
| รหัส | กิจกรรม | เอกสารหลักที่เกี่ยวข้อง |
|---|---|---|
| PM.01 | Project Planning | Project Plan, Gantt Chart, SRS (ฉบับร่าง) |
| PM.02 | Project Execution & Control | Progress Status Record, Change Request, CHANGELOG |
| PM.03 | Project Closure | Test Record, Configuration Item Table, User/Admin Manual |
2.1.2 กระบวนการพัฒนาซอฟต์แวร์ (Software Implementation Process)
กระบวนการ SI ครอบคลุมตั้งแต่การวิเคราะห์ความต้องการไปจนถึงการส่งมอบผลิตภัณฑ์ใน 6 ขั้นตอนต่อเนื่อง สิ่งสำคัญของกระบวนการนี้คือแต่ละขั้นตอนมีเอกสาร output ที่ชัดเจน และ output ของขั้นตอนหนึ่งจะเป็น input ของขั้นตอนถัดไป ทำให้สามารถตรวจสอบย้อนกลับได้ตลอดสาย ดังภาพประกอบที่ 2.4
ภาพที่ 2.4 กระบวนการพัฒนาซอฟต์แวร์ (Software Implementation Process Overview)
ขั้นตอนที่มีความสำคัญเฉพาะต่อโครงการนี้
- SI.02 (Requirements Analysis): ความท้าทายคือการแปลงหลักการมวยไท้เก๊กที่เป็นนามธรรม (เช่น "ใช้เอวเป็นแกน") ให้เป็น Functional Requirements ที่ชัดเจนและตรวจสอบได้ ผลลัพธ์คือ SRS ที่ระบุ 12 Use Cases และ FR 12 ข้อ
- SI.03 (Architecture & Design): เป็นจุดที่ตัดสินใจสถาปัตยกรรม 4-Layer และออกแบบ Heuristics Engine ทั้ง 9 ข้อ ซึ่งถูกออกแบบมาเพื่อตอบโจทย์ "จลนศาสตร์ (Kinematics)" โดยเฉพาะ การออกแบบที่ชัดเจนในขั้นนี้ทำให้ SI.04 สามารถพัฒนาแต่ละ Rule แยกกันได้โดยไม่ก้าวก่ายกัน
- SI.04 (Construction): ดำเนินการคู่ขนานกับการเขียน Unit Test (SI.05 บางส่วน) โดยใช้แนวทาง Test-first สำหรับ Heuristics Logic เพื่อให้มั่นใจว่าสูตรคณิตศาสตร์ถูกต้องก่อน integrate
- SI.05 (Software Integration & Testing): เน้นการทดสอบความแม่นยำของ Heuristics Module เมื่อทำงานร่วมกับ UI แบบ Real-time โดยมีการเก็บผลทดสอบ (Test Record) ครอบคลุมทั้ง Unit Level และ Integration Level เพื่อพิสูจน์ความเสถียรของระบบ
- SI.06 (Software Delivery): ขั้นตอนการส่งมอบผลิตภัณฑ์ซอฟต์แวร์ที่สมบูรณ์ พร้อมคู่มือการใช้งานและเอกสารประกอบทั้งหมดที่จัดทำขึ้นตามมาตรฐาน เพื่อให้มั่นใจว่าระบบพร้อมสำหรับผู้ใช้งานจริงและผู้ที่จะเข้ามารับช่วงต่อในการพัฒนา
โครงสร้างความเชื่อมโยงระดับระบบวิศวกรรมของผลลัพธ์ในแต่ละก้าว ถูกออกแบบกรอบไว้ดังแสดงในภาพที่ 2.5
ภาพที่ 2.5 แผนภูมิแสดงลำดับการพัฒนาซอฟต์แวร์ (SI Process Flow Diagram)
เพื่อให้ครอบคลุมตามมาตรฐานและบรรลุผลลัพธ์การจัดการที่ดีเยี่ยม จึงได้กำหนดกล่องรายการตรวจสอบ (Checklist) ดังตารางที่ 2.2
ตารางที่ 2.2 รายการตรวจสอบกระบวนการ ISO/IEC 29110
| No. | กระบวนการ | เอกสาร | สถานะ |
|---|---|---|---|
| 1 | Project Planning (PM.01) | Project Plan | ✅ |
| 2 | Requirements Analysis (SI.02) | SRS | ✅ |
| 3 | Architecture & Detailed Design (SI.03) | SDD + UML Diagrams (45 ไฟล์) | ✅ |
| 4 | Configuration Management | CI Table (179+ items) + CHANGELOG | ✅ |
| 5 | Software Construction (SI.04) | Source Code (69 ไฟล์) | ✅ |
| 6 | Integration & Testing (SI.05) | Test Plan + Test Record (75 กรณี) | ✅ |
| 7 | Project Monitoring (PM.02) | Progress Status Record + Change Request | ✅ |
| 8 | Product Delivery (SI.06) | User Manual + Admin Manual | ✅ |
ณ เวอร์ชัน v1.3.2 กระบวนการทั้ง 8 รายการข้างต้นเสร็จสมบูรณ์ 100% โดยมีการเชื่อมโยงความสัมพันธ์ของสิ่งส่งมอบดังแสดงในภาพที่ 2.6
ภาพที่ 2.6 ความเชื่อมโยงของสิ่งส่งมอบ (Artifact Traceability Relationship)
แผนภาพที่ 2.6 แสดงสายสัมพันธ์การตรวจสอบย้อนกลับ (Traceability) ของโครงการ โดยเริ่มจากการสกัดความต้องการของผู้ใช้เข้าสู่เอกสาร SRS ซึ่งทำหน้าที่เป็นแม่แบบในการออกแบบโครงสร้างใน SDD และนำไปสู่การพัฒนา Source Code ในชุดเดียวกันนี้ ระบบได้กำหนดกลไกการตรวจสอบสองระดับ คือการตรวจสอบความถูกต้องรายโมดูล (Unit Test) เพื่อยืนยันตรรกะทางเทคนิค และการตรวจสอบความสอดคล้องกับความต้องการของผู้ใช้ในขั้นตอนสุดท้าย (UAT) เพื่อยืนยันว่าระบบสามารถทำงานได้จริงตามวัตถุประสงค์ที่ตั้งไว้ในเบื้องต้น
ส่วนที่ยังดำเนินการอยู่คือการจัดทำรายงานฉบับสมบูรณ์ (Final Report) และการเตรียมสอบป้องกันโครงการ
2.2 รูปแบบและขั้นตอนการพัฒนา (Development Model)
โครงการ TaijiFlow AI ใช้ Iterative Development Model แทนที่จะพัฒนาทุกท่าและทุกฟีเจอร์พร้อมกัน โดยใช้หลักการ Depth-first คือเริ่มจากการพัฒนาท่าม้วนไหมพื้นฐานด้วยมือขวา (Right-Hand Clockwise Silk Reeling) เป็นกรณีทดสอบหลัก (Primary Case Study) เพื่อพัฒนาให้ถูกต้องสมบูรณ์ทั้ง Pipeline ก่อนจะขยายครอบคลุมท่าทั้งหมดตามที่กำหนดไว้ในขอบเขต
เหตุผลที่เลือกแนวทางนี้มีสองด้าน ด้านเทคนิค: กฎฮิวริสติก (Heuristics) แต่ละข้อมีความซับซ้อนของสูตรทางคณิตศาสตร์และการประมวผลพิกัดสูง การทดสอบรูปแบบการเคลื่อนไหวเดียวให้สมบูรณ์ก่อนช่วยยืนยันความถูกต้องของสายการประมวลผล (MediaPipe Landmark → Heuristic Calculation → Scoring → Feedback) ได้อย่างแม่นยำ ด้านการจัดการ: ช่วยให้สามารถนำเสนอระบบต้นแบบที่ทำงานได้จริง (MVP) ในระยะแรก และรับข้อมูลป้อนกลับจากผู้เชี่ยวชาญ (SME) ก่อนที่จะขยายการพัฒนาไปสู่ท่าอื่นๆ ซึ่งกระบวนทัศน์นี้แสดงเป็นวงจรการทำงานซ้ำได้ดังภาพที่ 2.7
ภาพที่ 2.7 รูปแบบการพัฒนาแบบวนซ้ำ (Iterative Development Model)
ฟีเจอร์ทั้งหมดถูกจัดกลุ่มเป็น 3 Iteration ตามระดับความสำคัญ (MoSCoW) และความซับซ้อนของการพัฒนา เพื่อให้ได้ระบบที่เสถียรที่สุดในฟังก์ชันหลักก่อนขยายสู่ส่วนติดต่อผู้ใช้ ดังตารางที่ 2.3
ตารางที่ 2.3 Iteration Plan (MoSCoW Priority)
| Iteration | เป้าหมาย | ฟีเจอร์หลัก (Key Features) | FR ที่ครอบคลุม |
|---|---|---|---|
| 1 (Must) | Core AI Pipeline ทำงานได้ | MediaPipe + Calibration + Heuristics 9 ข้อ + Skeleton Overlay + Ref Data Collector | FR-01, 02, 03, 04, 10 |
| 2 (Should) | Feedback & User Experience ครบ | Score Summary, TTS Feedback, Replay, Survey, Tutorial | FR-05, 06, 09, 11, 12 |
| 3 (Could) | Advanced Features | Gesture Control, Flow State Mode (โหมดฝึกต่อเนื่อง) | FR-07, 08 |
Iteration 1 ถือเป็น MVP (Minimum Viable Product) ที่ตอบคำถาม RQ1 ได้โดยตรง — ว่าระบบสามารถตรวจจับท่าทางและให้ข้อมูลป้อนกลับตามหลักมวยได้ถูกต้องหรือไม่ ก่อนที่จะพัฒนาส่วนขยายด้านประสบการณ์ผู้ใช้ (UX) ให้สมบูรณ์ใน Iteration 2 และ 3 ทั้งนี้ ผลลัพธ์จากการพัฒนาในแต่ละ Iteration จะถูกนำไปประเมินประสิทธิภาพในบทที่ 4 รวมถึงสรุปและอภิปรายผลรวบยอดในบทที่ 5 ตามลำดับ
2.3 แผนการดำเนินงาน (Project Plan)
2.3.1 แผนการดำเนินงาน Phase 1
ภาพรวมแผนงานระยะเวลา Phase 1 ประกอบด้วยความเชื่อมโยงทางเป้าหมายดังขอบเขตที่แสดงในภาพที่ 2.8
- ระยะที่ 1: การเตรียมการและออกแบบ (Preparation & Design)
- ระยะที่ 2: การพัฒนาและสร้างระบบ (Implementation)
- ระยะที่ 3: การทดสอบและประเมินผล (Testing & Evaluation)
- ระยะที่ 4: การสรุปผลและจัดทำเอกสารฉบับสมบูรณ์ (Finalization & Documentation)
ภาพที่ 2.8 ภาพรวมแผนการดำเนินงาน (Project Plan Overview)
ระยะที่ 1: การเตรียมการและออกแบบ (Preparation & Design)
จุดเริ่มต้นของเอกสารจะร่างด้วยกรอบเตรียมการและออกแบบโครงสร้าง ดังรายละเอียดในภาพที่ 2.9
ภาพที่ 2.9 แผนการดำเนินงานระยะที่ 1: การเตรียมการ (Project Plan Phase 1)
1.1 การรวบรวมและประมวลผลข้อมูลต้นแบบ (Ground Truth Data Collection & Processing)
ดำเนินการบันทึกวิดีโอการรำท่าม้วนไหม 4 ท่าหลัก (มือขวา-ตามเข็ม, มือซ้าย-ตามเข็ม, มือขวา-ทวนเข็ม, มือซ้าย-ทวนเข็ม) ใน 3 ระดับ (นั่ง, ยืน, ยืนย่อ) จากครูผู้เชี่ยวชาญ
ประมวลผลวิดีโอเพื่อสกัดข้อมูลพิกัดข้อต่อ 3 มิติ (3D Landmarks) ในแต่ละเฟรม
จัดเก็บข้อมูลพิกัดในรูปแบบไฟล์ JSON ที่มีโครงสร้างมาตรฐานและจัดทำเอกสารกำกับ
ผลลัพธ์ที่ได้: ชุดข้อมูลต้นแบบ (Ground Truth Dataset) ในรูปแบบไฟล์ JSON
1.2 การจัดทำเอกสารข้อกำหนดและการออกแบบ (Requirements & Design Documentation)
จัดทำเอกสาร ข้อกำหนดความต้องการซอฟต์แวร์ (Software Requirements Specification - SRS)
ออกแบบสถาปัตยกรรมของระบบ (System Architecture) และส่วนติดต่อผู้ใช้ (UI/UX)
ออกแบบตรรกะและสูตรคำนวณสำหรับ Heuristics Engine
จัดทำเอกสาร การออกแบบซอฟต์แวร์ (Software Design Document - SDD)
ผลลัพธ์ที่ได้: เอกสาร SRS และ SDD ฉบับสมบูรณ์
1.3 การเตรียมสภาพแวดล้อมในการพัฒนา (Development Environment Setup)
สร้าง Repository ของโครงการบน GitHub และกำหนดโครงสร้างโฟลเดอร์มาตรฐาน
ติดตั้งไลบรารีและเครื่องมือที่จำเป็นสำหรับการพัฒนา Front-end (HTML/CSS/JS), เครื่องมือสร้าง UI/UX และ Jest สำหรับหน่วยทดสอบรหัส (Unit Testing)
ตั้งค่าสภาพแวดล้อมสำหรับการพัฒนา (Local Development Environment) เพื่อให้พร้อมสำหรับการเขียนโค้ด
ผลลัพธ์ที่ได้: สภาพแวดล้อมในการพัฒนาที่พร้อมใช้งาน และ Repository บน GitHub
ระยะที่ 2: การพัฒนาและสร้างระบบ (Implementation)
เมื่อโครงสร้างพร้อม จะเข้าสู่กระบวนการเขียนโค้ดเพื่อพัฒนาระบบจริง ดังขั้นตอนย่อยในภาพที่ 2.10
ภาพที่ 2.10 แผนการดำเนินงานระยะที่ 2: การพัฒนา (Project Plan Phase 2)
2.1 การพัฒนาส่วนติดต่อผู้ใช้และโครงสร้างหลัก (Core System & UI Development)
เขียนโค้ด HTML, CSS, และ JavaScript เพื่อสร้างส่วนติดต่อผู้ใช้ (UI)
พัฒนาฟังก์ชันการทำงานพื้นฐาน เช่น การเปิดเว็บแคม, การแสดงวิดีโอ และการทำงานของปุ่มและเมนูต่างๆ
ผลลัพธ์ที่ได้: หน้าเว็บแอปพลิเคชันที่สามารถแสดงภาพจากกล้องและมี UI ครบถ้วน
2.2 การพัฒนา Heuristics Engine (Heuristics Engine Development)
พัฒนาแบบ "เจาะลึกทีละท่า" (Depth-first) โดยเริ่มจากท่าม้วนไหมพื้นฐานด้วยมือขวา (Right-Hand Clockwise Silk Reeling) เป็นลำดับแรก
พัฒนาฟังก์ชันสำหรับกฎเกณฑ์ (Heuristics) ให้ครบทั้ง 3 ระดับการฝึก (นั่ง, ยืน, ยืนย่อ)
เขียน Unit Test ด้วย Jest ควบคู่ไปกับการพัฒนาแต่ละฟังก์ชัน เพื่อตรวจสอบความถูกต้องของตรรกะ
ผลลัพธ์ที่ได้: Heuristics Engine ที่สามารถวิเคราะห์ท่ารำต้นแบบได้อย่างสมบูรณ์ พร้อม Unit Test ที่มีความครอบคลุม (Coverage) ตามเกณฑ์
2.3 การบูรณาการระบบ (System Integration)
เชื่อมต่อส่วนติดต่อผู้ใช้ (UI) เข้ากับ Heuristics Engine
พัฒนาตรรกะในการรับค่าจากเมนู (ท่าที่เลือก, ระดับที่เลือก) เพื่อเรียกใช้ฟังก์ชันการวิเคราะห์ที่ถูกต้อง
พัฒนาวิธีการแสดงผลข้อมูลป้อนกลับ (Feedback) บนหน้าจอแบบ Real-time
ผลลัพธ์ที่ได้: ซอฟต์แวร์ต้นแบบ TaijiFlow AI เวอร์ชันแรกที่ทำงานได้ครบทุกท่า
ระยะที่ 3: การทดสอบและประเมินผล (Testing & Evaluation)
ถัดมาคือกระบวนการสำรวจประสิทธิภาพและวิเคราะห์กลุ่มเป้าหมายเชิงสถิติ ดังภาพที่ 2.11
ภาพที่ 2.11 แผนการดำเนินงานระยะที่ 3: การทดสอบ (Project Plan Phase 3)
3.1 การเตรียมการประเมินผล (Evaluation Preparation)
จัดทำ “แผนการทดสอบ” (Test Plan) และเขียน “กรณีทดสอบ” (Test Cases) สำหรับการทดสอบซอฟต์แวร์และการประเมินผลกับผู้ใช้
จัดทำเครื่องมือที่ใช้ในการเก็บข้อมูลฉบับสมบูรณ์ (แบบสอบถาม, แนวคำถามสัมภาษณ์, เอกสารขอความยินยอม)
ดำเนินการคัดเลือกและนัดหมายกลุ่มตัวอย่าง (5-10 คน) ตามเกณฑ์ที่กำหนด
ผลลัพธ์ที่ได้: เอกสาร Test Plan ฉบับสมบูรณ์, เครื่องมือเก็บข้อมูลที่พร้อมใช้งาน, และรายชื่อผู้เข้าร่วมการทดสอบ
3.2 การดำเนินการทดสอบและประเมินผล (Execution of Testing & Evaluation)
ดำเนินการทดสอบประสิทธิภาพของระบบ (Performance Testing) เพื่อวัดค่าจำนวนเฟรมที่แสดงผลในหนึ่งวินาที (FPS: Frames Per Second) และการใช้ทรัพยากร
จัดกิจกรรมการทดลองกับผู้ใช้งานกลุ่มตัวอย่าง และดำเนินการเก็บข้อมูล (บันทึกวิดีโอ, ตอบแบบสอบถาม, สัมภาษณ์)
ผลลัพธ์ที่ได้: ข้อมูลดิบจากการทดสอบทั้งหมด (Raw Data)
3.3 การวิเคราะห์และปรับปรุงระบบ (Analysis & Refinement)
วิเคราะห์ข้อมูลเชิงปริมาณและคุณภาพที่รวบรวมได้
สรุปผลการทดสอบ, ระบุข้อผิดพลาด (Bugs) และจุดที่ควรปรับปรุง
ดำเนินการแก้ไขข้อผิดพลาดที่สำคัญและปรับปรุงระบบตามข้อเสนอแนะที่ได้รับ
ผลลัพธ์ที่ได้: “รายงานสรุปผลการทดสอบ” (Test Report) และ “ซอฟต์แวร์ต้นแบบเวอร์ชันปรับปรุง” (Stable Version)
ระยะที่ 4: การสรุปผลและจัดทำเอกสาร (Finalization & Documentation)
ปิดท้ายด้วยการจัดทำรายงานสมบูรณ์และแพคเกจผลลัพธ์โครงการ ดังภาพที่ 2.12
ภาพที่ 2.12 แผนการดำเนินงานระยะที่ 4: การสรุปผล (Project Plan Phase 4)
4.1 การเขียนรายงานฉบับสมบูรณ์ (Final Report Writing)
นำผลการวิเคราะห์จากระยะที่ 3 มาเขียนในบทที่ 4 (ผลการศึกษา) และบทที่ 5 (สรุปและอภิปรายผล)
เรียบเรียงและขัดเกลารายงานทั้งหมด พร้อมจัดทำเอกสารอ้างอิงและภาคผนวก
ผลลัพธ์ที่ได้: รายงานการค้นคว้าอิสระฉบับสมบูรณ์
4.2 การจัดทำเอกสารโครงการ (Project Documentation)
ตรวจสอบและปรับปรุงเอกสารทั้งหมด (SRS, SDD, Test Plan, Decision Log)
ผลลัพธ์ที่ได้: ชุดเอกสารประกอบโครงการที่สมบูรณ์
4.3 การเตรียมการนำเสนอ (Presentation Preparation)
จัดทำสไลด์นำเสนอสำหรับสอบป้องกันโครงการ
ฝึกซ้อมการสาธิต (Demo) การใช้งานซอฟต์แวร์ต้นแบบ
ฝึกซ้อมการนำเสนอทั้งหมดเพื่อให้เป็นไปตามเวลาที่กำหนด
ผลลัพธ์ที่ได้: สื่อนำเสนอฉบับสมบูรณ์ และความพร้อมในการสอบป้องกันโครงการ
2.3.2 Gantt Chart
แผนการดำเนินงานของโครงการครอบคลุม 6 เดือน (พฤศจิกายน 2568 – พฤษภาคม 2569) ตาม Project Plan ซึ่งแบ่งเป็น 5 ส่วน สอดคล้องกับ Phase การทำงานในเอกสาร ดังปรากฏในโครงสร้างเวลาของแผนภูมิที่ 2.13
ภาพที่ 2.13 แผนภูมิแกนต์แสดงระยะเวลาดำเนินการ (Gantt Chart)
Note: Gantt Chart มี Buffer ในสองจุดสำคัญ — หลัง Implementation (buffer1) และหลัง UAT (buffer2) ซึ่งสะท้อนว่าโครงการตระหนักถึงความไม่แน่นอนในขั้นตอนบูรณาการระบบและการรับ feedback จากผู้ใช้จริง การจัด Buffer ล่วงหน้าทำให้ไม่ต้องตัดฟีเจอร์ออกเมื่อพบปัญหา
2.3.3 Milestones
แผนงานกำหนด 5 Milestone หลักตลอดโครงการ แต่ละ Milestone แทนการเปลี่ยนผ่านระหว่าง Phase สำคัญ และต้องมีเอกสารหรือผลที่จับต้องได้ก่อนจะเดินหน้าต่อ ตามจุดชี้วัดที่สรุปในตารางที่ 2.4
ตารางที่ 2.4 รายละเอียดไมล์สโตน (Milestones)
| Milestone | ชื่อ | เงื่อนไขผ่าน | เวอร์ชัน | สถานะ |
|---|---|---|---|---|
| M1 | Requirement Approval | SRS และ Project Plan ผ่านการตรวจสอบ | v0.1 | ✅ |
| M2 | Design Complete | SDD + UML Diagrams ครบ สถาปัตยกรรมได้รับการอนุมัติ | v0.3 | ✅ |
| M3 | Core Features | Heuristics 9 ข้อ + Realtime Feedback ทำงานได้ Unit Test ผ่าน | v1.2.0 | ✅ |
| M4 | Testing Complete | UAT ผ่าน Traceability Record และ Test Record เสร็จสมบูรณ์ | v1.3.0 | ✅ |
| M5 | Project Closure | รายงานฉบับสมบูรณ์ + นำเสนอสำเร็จ | v1.3.x | ⏳ |
Milestone 4 เป็นจุดที่โครงการลงทุนเวลามากที่สุด เนื่องจากต้องจัดทำ Traceability Record ฉบับสมบูรณ์ที่เชื่อมโยง IRS 24 ข้อ → UTC 72 กรณี → STC 3 กรณี รวมถึงแก้ไขปัญหาเชิงโครงสร้างเอกสาร (Milestone 5 ภายใน v1.3.0) ก่อนที่ UAT จะมีความน่าเชื่อถือเต็มที่
2.3.4 สิ่งส่งมอบ (Deliverables)
รายการข้อมูลความคาดหวังผลผลิตของโครงการ ได้ถูกรวบรวมไว้เป็นหมวดหมู่ตามตารางที่ 2.5
ตารางที่ 2.5 รายการสิ่งส่งมอบ (Deliverables)
| No. | สิ่งส่งมอบ | รูปแบบ | กำหนด |
|---|---|---|---|
| 1.1 | Project Proposal | PDF / Markdown | เดือนที่ 1 |
| 1.2 | Project Plan + SRS | PDF / Markdown | เดือนที่ 1–2 |
| 1.3 | SDD + UML Diagrams (45 ไฟล์) | PDF / Markdown | เดือนที่ 2 |
| 2.1 | TaijiFlow AI Web Application | Web App (Vercel) | เดือนที่ 3–4 |
| 2.2 | Heuristics Engine 9 ข้อ | JavaScript Modules | เดือนที่ 3–4 |
| 3.1 | Test Plan + Test Record | PDF / Markdown | เดือนที่ 5–6 |
| 3.2 | Traceability Record + CI Table | PDF / Markdown | เดือนที่ 5–6 |
| 3.3 | User Manual + Admin Manual | PDF / Markdown | เดือนที่ 6 |
| 3.4 | Final Report (Thesis) | PDF / Markdown | เดือนที่ 6 |
2.4 ทรัพยากรและความพยายาม (Effort and Resources)
โครงการนี้พัฒนาโดยทีมขนาดเล็ก โดยผู้พัฒนาหลักทำหน้าที่ควบรวมทั้ง Full Stack Development, AI/CV Engineering และ Project Management พร้อมรับคำแนะนำจากที่ปรึกษาสองด้าน ได้แก่ ที่ปรึกษาด้านวิศวกรรมซอฟต์แวร์ และผู้เชี่ยวชาญมวยไท้เก๊ก (SME) สำหรับการออกแบบ Heuristics และตรวจสอบความถูกต้องของ feedback ทั้งนี้ การแจกแจงเพดานกำลังประเมินไว้ล่วงหน้า ได้แสดงไว้ดังตารางที่ 2.6
ตารางที่ 2.6 การประมาณความพยายาม (Effort Estimation)
| Phase | ระยะเวลา | Effort โดยประมาณ | ผู้รับผิดชอบ |
|---|---|---|---|
| Planning & Management | 4 สัปดาห์ | 40–50 ชั่วโมง | Developer |
| Design (SDD + Architecture) | 4 สัปดาห์ | 40–60 ชั่วโมง | Developer |
| Core Development | 8 สัปดาห์ | 120–150 ชั่วโมง | Developer |
| Testing & Evaluation | 4 สัปดาห์ | 60–80 ชั่วโมง | Developer |
| Documentation & Thesis | 4 สัปดาห์ | 40–60 ชั่วโมง | Developer |
| รวม | ~6 เดือน | ~300–400 ชั่วโมง |
ช่วงการทำงานที่บริโภคทรัพยากรมากที่สุดคือ Core Development ซึ่งต้องอาศัยเวลามากกว่า 120–150 ชั่วโมง ตัวเลขประมาณการที่สูงนี้เกิดจากความซับซ้อนของ Heuristics Engine กฎเกณฑ์เชิงตรรกะแต่ละข้อจำเป็นต้องมีการคิดค้นสูตรคำนวณ การนำสูตรไปวิเคราะห์เปรียบเทียบกับข้อมูลต้นแบบ (Ground Truth) ที่สกัดจากผู้เชี่ยวชาญเพื่อปรับจูนค่าเกณฑ์ประเมิน (Threshold Tuning) ตลอดจนการทำซ้ำในระดับ Unit Test กระบวนการเหล่านี้ต้องอาศัยวงจรพัฒนาที่วนซ้ำหลายรอบ (Iteration) เพื่อบรรลุความถูกต้องแม่นยำจนถึงระดับที่สามารถนำมาใช้งานจริงได้ตามมาตรฐานของศาสตร์มวยไท้เก๊ก
2.5 ขอบเขตและข้อจำกัด (Scope and Limitations)
2.5.1 ภาพรวมขอบเขตและแผนการพัฒนาระยะยาว (Scope Overview and Roadmap)
TaijiFlow AI ถูกวางแผนไว้เป็น 3 Phase ตามระดับความซับซ้อนของเนื้อหาและเทคโนโลยี โดย Phase 1 (รายงานฉบับนี้) เป็นจุดเริ่มต้น ส่วน Phase 2 จะขยายเนื้อหาและเพิ่มระบบผู้ใช้ และ Phase 3 จะนำ AI ขั้นสูงมาใช้สำหรับการรำแบบอิสระ (ไม่จำกัดท่า) เพื่อให้เห็นภาพรวมของการดำเนินงาน โครงการ TaijiFlow AI กำหนดขอบเขตครอบคลุม 3 ด้านหลัก ดังนี้
1. ขอบเขตด้านเนื้อหามวยไท้เก๊ก (Taiji Content Scope):
- สกุลมวย: มวยไท้เก๊ก "สกุลเฉิน" (Chen-style Taijiquan) เท่านั้น
- ชุดท่า: "ท่าม้วนไหม" (Silk Reeling / Chán Sī Jìn) เท่านั้น
- รูปแบบท่า: เน้น "ท่าม้วนไหมมือเดียว" (Single-Hand) ใน Phase 1, "ท่าม้วนไหมสองมือ" (Double-Hand) ใน Phase 2 และ "ท่าม้วนไหม เคลื่อนไหว" (Silk Reeling, Moving) ใน Phase 3
- ระดับการฝึก: รองรับความสูง 3 ระดับ ได้แก่ "นั่ง, ยืนตรง, และยืนย่อ" (Sitting, Standing, Squatting) ซึ่งโครงร่างขอบเขตและแผนการพัฒนาเหล่านี้สะท้อนชัดในภาพที่ 2.14 และสรุปลำดับขั้นสู่ตารางที่ 2.7
ภาพที่ 2.14 ภาพรวมขอบเขตและโรดแมพการพัฒนา (Scope Overview and Roadmap)
ตารางที่ 2.7 แผนการพัฒนาโครงการ (Project Roadmap)
| หัวข้อ | Phase 1 (รายงานนี้) | Phase 2 | Phase 3 |
|---|---|---|---|
| ท่าที่รองรับ | มือเดียว 4 ท่า 3 ระดับ | สองมือ 8 ท่า 3 ระดับ | รำอิสระ (ไม่จำกัดท่า) |
| โหมดการฝึก | ยืนอยู่กับที่ | ยืนอยู่กับที่ | รวมการเคลื่อนที่ (Footwork) |
| ระบบผู้ใช้ | ไม่มี Login | Login + Training History | Multi-user + Community |
| AI Engine | Heuristics Rule-based | Heuristics + ML Classifier | Deep Learning + Reinforcement Learning |
| มุมกล้อง | เว็บแคมเดียว (2D) | เว็บแคมเดียว (2D) | หลายมุมมอง / 3D Estimation |
| ข้อมูลสะสม | Session-only (Local) | Server + User History | Research Dataset สำหรับ DL/RL |
2. ขอบเขตด้านระบบซอฟต์แวร์ (Software System Scope):
- แพลตฟอร์ม: พัฒนาในรูปแบบ "เว็บแอปพลิเคชัน" (Web Application) ที่เข้าถึงได้ผ่านเบราว์เซอร์
- ฟังก์ชันหลัก: การวิเคราะห์ท่าทางและให้ข้อมูลป้อนกลับเชิงคุณภาพแบบทันที (Real-time Feedback)
- การรองรับภาษา: สนับสนุนการแสดงผลและเสียง (TTS) 2 ภาษา ได้แก่ ภาษาไทย และภาษาอังกฤษ
- การปรับรูปแบบ (Theming): รองรับโหมดสว่าง (Light Mode) และโหมดมืด (Dark Mode) เพื่อความสบายตา
- ระบบผู้ใช้: Phase 1 จะไม่มีระบบจัดการผู้ใช้ และไม่มีการเก็บประวัติการฝึกระยะยาว จะพัฒนาต่อไปใน Phase 2
- แบบจำลอง AI: ใช้การปรับปรุง (Adapt) จาก Pre-trained Model (MediaPipe) โดยไม่มีการสร้าง/ฝึกโมเดลใหม่
3. ขอบเขตประชากรและกลุ่มเป้าหมาย (Target Population):
- ผู้ฝึกมวยไท้เก๊กสกุลเฉินในระดับเริ่มต้นถึงระดับกลาง (Beginner to Intermediate)
- เน้นผู้ที่สนใจเครื่องมือสำหรับ "การฝึกซ้อมด้วยตนเอง" (Solo Practice)
- ผู้ใช้งานที่สามารถเข้าถึงคอมพิวเตอร์และเชื่อมต่อเว็บแคมมาตรฐานได้
2.5.2 รายละเอียดขอบเขตการดำเนินงาน Phase 1 (Detailed Phase 1 Scope)
การดำเนินงานใน Phase 1 เพื่อพัฒนาต้นแบบ (Prototype) ของระบบ TaijiFlow AI โดยใช้แนวคิดการใช้ Heuristics Engine ในการประเมินคุณภาพมวยไท้เก๊กผ่านท่าม้วนไหมมือเดียว โดยเลือกท่าม้วนไหมมือเดียว (Single-Hand Silk Reeling) 4 ท่า ซึ่งเป็นท่าพื้นฐานที่สำคัญที่สุด และแบ่งเป็น 3 ระดับ (Level 1–3) ตามระดับความยากง่ายและความเหมาะสมกับผู้ฝึก ดังระบุชั้นประเมินในตารางที่ 2.8 และรายชื่อท่ารำในตารางที่ 2.9
ตารางที่ 2.8 รายละเอียดระดับการฝึก (Training Levels)
| ระดับ | ชื่อเรียก | ลักษณะการฝึก | วัตถุประสงค์หลัก |
|---|---|---|---|
| Level 1 | ท่านั่ง (Sitting) | ฝึกเฉพาะส่วนบน | เน้นการหมุนวงแขนให้เป็นวงกลมที่ถูกต้อง |
| Level 2 | ท่ายืน (Standing) | ฝึกส่วนบนและเอว | เน้นการทำงานสัมพันธ์ระหว่างเอวและแขน |
| Level 3 | ท่ายืนย่อ (Squatting) | ฝึกส่วนบน เอว และขา | เน้นการถ่ายน้ำหนักและรากฐานที่มั่นคง |
ตารางที่ 2.9 ท่าม้วนไหมที่รองรับใน Phase 1
| ท่า | ชื่อภาษาจีน | ลักษณะการเคลื่อนไหว |
|---|---|---|
| มือขวาตามเข็ม | 右顺缠 (yòu shùn chán) | วนตามเข็มนาฬิกา (Inside-out) |
| มือขวาทวนเข็ม | 右逆缠 (yòu nì chán) | วนทวนเข็มนาฬิกา (Outside-in) |
| มือซ้ายตามเข็ม | 左顺缠 (zuǒ shùn chán) | วนตามเข็มนาฬิกา (Outside-in) |
| มือซ้ายทวนเข็ม | 左逆缠 (zuǒ nì chán) | วนทวนเข็มนาฬิกา (Inside-out) |
ภาพประกอบรูปลักษณะทางกายภาพของท่าทางม้วนไหมระดับฝึกซ้อม 4 รูปแบบหลัก แสดงให้เห็นรายละเอียดดังภาพที่ 2.15 ถึง 2.18 ด้านล่างนี้
ภาพที่ 2.15 ท่าม้วนไหมพื้นฐานด้วยมือขวา (Right-Hand Clockwise Silk Reeling)
ภาพที่ 2.16 ท่าม้วนไหมพื้นฐานด้วยมือขวา (Right-Hand Counter-Clockwise Silk Reeling)
ภาพที่ 2.17 ท่าม้วนไหมพื้นฐานด้วยมือซ้าย (Left-Hand Clockwise Silk Reeling)
ภาพที่ 2.18 ท่าม้วนไหมพื้นฐานด้วยมือซ้าย (Left-Hand Counter-Clockwise Silk Reeling)
2.5.3 ข้อจำกัดและเงื่อนไขการใช้งาน (Limitations and Constraints)
โครงการกำหนดข้อจำกัดและเงื่อนไขเพื่อให้ระบบสามารถทำงานได้อย่างมีประสิทธิภาพสูงสุด ดังนี้
1. ข้อจำกัดด้านเทคนิคและสภาพแวดล้อม (Technical & Environment):
- สเปกคอมพิวเตอร์: แนะนำ Intel Core i5 Gen 8 หรือ Apple M1 ขึ้นไป, RAM 8 GB และเว็บแคมความละเอียด 720p เพื่อรักษาอัตราเฟรมเรตให้นิ่ง
- เบราว์เซอร์: ทำงานสมบูรณ์บน Google Chrome และ Microsoft Edge (PC/Mac) ส่วนอุปกรณ์พกพาจะทำงานในโหมด Lite
- สภาพแสงและความเป็นส่วนตัว: ต้องการสภาวะแสงที่ส่องสว่างเพียงพอต่อการระบุข้อต่อ และประมวลผลวิดีโอแบบ Local 100% เพื่อความปลอดภัย
2. ข้อจำกัดเชิงเนื้อหาและฟังก์ชัน (Functional Constraints):
- ขอบเขตท่ารำ: "ไม่ครอบคลุม" การเคลื่อนที่ของเท้า (Footwork), ท่ารำสองมือ และท่ารำอิสระใน Phase 1
- มุมมองกล้อง: ระบบอาศัยกล้อง 2D ตัวเดียว หากมีการหันตัวจนเกิดการบังกัน (Occlusion) อาจทำให้ความแม่นยำในการวิเคราะห์ลดลง
- การจัดการข้อมูล: ไม่มีการเก็บประวัติผู้ใช้ระยะยาว (No Persistent History) โดยจะแสดงผลลัพธ์แบบ Session-to-session เท่านั้น
2.6 เครื่องมือและเทคโนโลยี (Technology Stack)
2.6.1 เทคโนโลยีที่ใช้
การตัดสินใจด้านเทคโนโลยีใน Phase 1 ถูกกำหนดโดยข้อกำหนดสำคัญสามข้อ ได้แก่ (1) ผู้ใช้ต้องไม่ต้องติดตั้งซอฟต์แวร์เพิ่มเติม (2) วิดีโอต้องไม่ออกจากเครื่องผู้ใช้ และ (3) ระบบต้องทำงานได้บนคอมพิวเตอร์ทั่วไปโดยไม่ต้องใช้ GPU เฉพาะทาง ข้อกำหนดเหล่านี้นำไปสู่การเลือก Web-only Architecture กับ Client-side Processing เป็นหลัก ตามบัญชีเครื่องมือในตารางที่ 2.10
ตารางที่ 2.10 เครื่องมือและเทคโนโลยี
| กลุ่ม | เครื่องมือ | เหตุผลการเลือก |
|---|---|---|
| UI/UX Design | Figma, Mermaid.js | วาด Wireframe และ Diagram ที่ฝังใน Docs ได้โดยแปลงเป็นไฟล์ภาพ |
| Front-End | HTML5, CSS3, JavaScript ES6 Modules | ไม่ต้อง Build step, รองรับ Browser ทุกประเภท, ง่ายต่อการ Debug |
| Computer Vision | MediaPipe Pose (WASM/WebGL) | Real-time 33 Landmarks บน Browser ไม่ต้องใช้ GPU, Client-side 100% |
| Audio Feedback | Web Speech API (TTS) | Built-in ใน Browser, รองรับไทย/อังกฤษ ไม่ต้อง subscription |
| Gesture Control | MediaPipe Gesture Recognizer | Hands-free UX ลด Touch-points ขณะรำ ใช้ Library เดิม |
| Cloud Hosting | Vercel | Deploy อัตโนมัติจาก GitHub, CDN, ฟรีสำหรับ Static Hosting |
| Survey Backend | Google Apps Script + Sheets | Serverless, ฟรี, รับข้อมูล UAT โดยไม่ต้องดูแล Server |
| Testing | Jest | มาตรฐาน JS Testing, รองรับ Mock, รัน 72 UTC + 3 ITC ได้ |
| Documentation | Docsify | Markdown-native, ไม่ต้อง Build, เข้าถึง URL ได้ตรง |
| Version Control | Git + GitHub | ติดตาม History, Branch สำหรับ Feature, Diff สำหรับ CR Review |
2.6.2 กลยุทธ์การออกแบบสถาปัตยกรรม 4-Layer
เพื่อให้สอดคล้องกับแนวทางการพัฒนาซอฟต์แวร์มาตรฐาน ISO/IEC 29110 โครงการจึงกำหนดสถาปัตยกรรม 4-Layer Client-Side Architecture เป็นโครงสร้างพื้นฐานในการออกแบบ เพื่อให้ระบบมีความเป็นอิสระต่อกัน (Decoupled) และง่ายต่อการปรับปรุงในระยะยาว โดยแบ่งความรับผิดชอบออกเป็น 4 ชั้นหลัก
- Presentation Layer: รับผิดชอบส่วนติดต่อผู้ใช้ (UI) การแสดงผลภาพ (Canvas Overlay) ทำหน้าที่เปลี่ยนข้อมูลดิบจากการประมวลผลให้เป็น Visual Feedback ที่เข้าใจง่าย และการจัดการ Theme (Light/Dark Mode) เพื่อความสบายตา
- Business Logic Layer: หัวใจของระบบที่รวบรวม Heuristics Engine, ระบบประเมินผล (Scoring), และตัวควบคุมวงจรการฝึก (Training Flow) โดยถูกออกแบบให้ไม่ยึดติดกับส่วนแสดงผล (UI-Agnostic)
- Data Layer: จัดการข้อมูลที่ใช้ในระบบ ทั้งพิกัดท่ารำอ้างอิง, ข้อมูลการฝึกรายเซสชัน และการจัดการ Localization (i18n) สำหรับ 2 ภาษา พร้อมระบบจดจำค่ากำหนดล่าสุดของผู้ใช้ (Persistence)
- External APIs Layer: ส่วนเชื่อมต่อกับหน่วยประมวลผลภายนอก ได้แก่ MediaPipe Pose สำหรับการตรวจจับร่างกาย, Web Speech API สำหรับเสียงฝึกสอน และ Google Apps Script สำหรับการจัดเก็บผลการทดสอบ
การตัดสินใจใช้สถาปัตยกรรมที่แยกชั้นชัดเจนเช่นนี้ (รายละเอียดการออกแบบทางเทคนิคเชิงลึกในบทที่ 3) มีวัตถุประสงค์สำคัญต่อกระบวนการพัฒนา 2 ประการ คือ
- ความสามารถในการทดสอบ (Testability): การแยก Business Logic ออกจาก Presentation อย่างเด็ดขาด ทำให้สามารถเขียน Unit Test สำหรับสูตรคำนวณ Heuristics ทุก Rule ได้ทันทีโดยไม่ต้องเปิดเบราว์เซอร์ ซึ่งช่วยลดระยะเวลาในการ Debug ลงอย่างมาก
- ความยืดหยุ่นต่อการเปลี่ยนแปลง (Maintainability): รองรับแนวทางการพัฒนาแบบ Iterative Model โดยสามารถปรับปรุงหน้าตา UI หรือเปลี่ยนเทคโนโลยีตรวจจับท่าทาง (External APIs) ได้ใน Phase 2 โดยไม่กระทบต่อตรรกะการประเมินผลท่าทางที่เป็นแกนกลางของระบบ
2.7 การจัดการการกำหนดค่า (Configuration Management)
เพื่อให้มั่นใจว่า artifact ทุกชิ้นในโครงการมีความถูกต้องและสามารถตรวจสอบย้อนกลับได้ โครงการจึงกำหนดแนวทางการจัดการการกำหนดค่า (CM) ตามมาตรฐาน ISO/IEC 29110 โดยเน้นที่การควบคุมการเปลี่ยนแปลงอย่างเป็นระบบและการระบุรายการที่สำคัญอย่างชัดเจน
2.7.1 กระบวนการควบคุมการเปลี่ยนแปลง (Change Control Process)
เพื่อให้การพัฒนาซอฟต์แวร์เป็นไปอย่างต่อเนื่องและลดความเสี่ยงจากข้อผิดพลาดที่ไม่ได้ตั้งใจ โครงการจึงกำหนดกระบวนการควบคุมการเปลี่ยนแปลงทุกครั้งที่มีการแก้ไข artifact ที่อยู่ในระดับ Baseline แล้ว โดยต้องผ่านขั้นตอน 4 ระยะ ดังแสดงในภาพที่ 2.19
ภาพที่ 2.19 แผนภูมิกระบวนการควบคุมการเปลี่ยนแปลง (Change Control Process Flow)
กระบวนการควบคุมการเปลี่ยนแปลงมีเป้าหมายหลักในการป้องกันผลกระทบข้างเคียงจากการแก้ไขโค้ดหรือเอกสาร โดยต้องมีการประเมินผลกระทบ (Impact Analysis) และได้รับความเห็นชอบก่อนดำเนินการทุกครั้ง เพื่อให้องค์ประกอบหลากมิติในโครงการมีความสอดคล้องกันตลอดเวลา
2.7.2 รายการสิ่งกำหนดค่า (Configuration Items)
เพื่อให้กระบวนการควบคุมข้างต้นครอบคลุมทุกส่วนประกอบ โครงการจึงจัดทำบัญชีรายการสิ่งกำหนดค่า (Configuration Item Table) เพื่อติดตาม artifact ทุกชิ้นที่เป็นส่วนหนึ่งของโครงการ โดยแบ่งออกเป็น 8 หมวดหมู่หลักตามตารางที่ 2.11
ตารางที่ 2.11 หมวดหมู่ Configuration Items
| หมวด | รหัส | ตัวอย่างรายการ |
|---|---|---|
| Management Documents | CI-MGMT | Project Plan, CR-01–CR-03, CHANGELOG, README |
| Technical Documents | CI-DOC | SRS, SDD, Test Plan, Test Record, Manuals |
| Web/UI Application | CI-WEB | index.html, app.css, script.js, landing pages |
| Source Code Logic | CI-SRC | heuristics_engine.js, rule_*.js, session_manager.js |
| UML Diagrams | CI-DIAG | uc_.puml, ac_.puml, sq_.puml, ar_.puml |
| Media & Screenshots | CI-MEDIA | ภาพประกอบคู่มือ, screenshots |
| Static Assets | CI-ASSET | ไอคอน, ฟอนต์, manifest.json |
| Reference Data | CI-DATA | JSON ท่ารำ, วิดีโอต้นแบบ |
2.7.3 บันทึกการขอเปลี่ยนแปลง (Change Request Record)
จากการรันกระบวนการควบคุมใน Phase 1 โครงการได้มีการบันทึกรายการเปลี่ยนแปลงที่สำคัญที่ผ่านการอนุมัติและนำไปสู่การปรับปรุงระบบต้นแบบ โดยรายละเอียดการเปลี่ยนแปลงที่สำคัญถูกจัดเก็บลงตารางที่ 2.12
ตารางที่ 2.12 Change Requests ที่เกิดขึ้นใน Phase 1:
| CR | เนื้อหา | เหตุผล | CI ที่ได้รับผลกระทบ |
|---|---|---|---|
| CR-01 | เปลี่ยน Rule 1 จาก Position-based → Shape-based | ผู้เชี่ยวชาญระบุว่าเส้นทางการเคลื่อนไหวสำคัญกว่าตำแหน่ง | CI-SRC: rule_path_shape.js, CI-DOC: SDD |
| CR-02 | เพิ่ม NEW Rule Coordination (Rule 9) | พบว่า 8 Rules ไม่ครอบคลุม หลักการ "บน-ล่างสัมพันธ์" | CI-SRC: rule_coordination.js, CI-DOC: SRS FR-03 |
| CR-03 | เพิ่ม Flow State Mode (โหมดฝึกต่อเนื่อง) | UX Testing พบว่าผู้ฝึกต้องการโหมดสมาธิที่ลด UI noise | CI-WEB: UI layer, CI-SRC: flowstate_controller.js |
โดยสรุป การจัดการการกำหนดค่าที่เข้มงวดนี้ช่วยให้โครงการรักษา "ความสมบูรณ์ของผลิตภัณฑ์" (Product Integrity) ได้อย่างยั่งยืน และช่วยให้ผู้พัฒนาในระยะถัดไปสามารถสืบค้นประวัติการตัดสินใจและโครงสร้างของทรัพยากรทั้งหมดได้อย่างรวดเร็วและแม่นยำ
2.8 การจัดการความเสี่ยง (Risk Management)
การระบุและประเมินความเสี่ยงล่วงหน้าเป็นส่วนหนึ่งของ PM.01 ใน ISO/IEC 29110 โดยโครงการให้ความสำคัญกับการบริหารจัดการความเสี่ยงทางด้านเทคนิคและคุณภาพซอฟต์แวร์อย่างเป็นระบบเพื่อให้ระบบมีความเสถียรสูงสุด
2.8.1 วงจรการบริหารจัดการความเสี่ยง (Risk Management Cycle)
เพื่อให้การจัดการความเสี่ยงเป็นไปตามมาตรฐาน ISO/IEC 29110 โครงการจึงกำหนดวงจรการบริหารจัดการที่ชัดเจนและครอบคลุมตลอดช่วงชีวิตการพัฒนา ซึ่งวงจรนี้เป็นรากฐานในการระบุและติดตามสถานะความเสี่ยงในแต่ละขั้นตอน ดังแสดงในภาพที่ 2.20
ภาพที่ 2.20 วงจรการติดตามและควบคุมความเสี่ยง (Risk Monitoring & Control Cycle)
โครงการกำหนดวงจรการทบทวนความเสี่ยงทุกครั้งหลังสิ้นสุดรอบการพัฒนา (Iteration) เพื่อระบุความเสี่ยงใหม่และปรับปรุงแผนรับมือให้ทันสมัยอยู่เสมอ โดยมีเกณฑ์การประเมินและวิธีการวิเคราะห์ระบุไว้ในหัวข้อถัดไป
2.8.2 เกณฑ์การประเมินและการจัดระดับความเสี่ยง (Risk Assessment Criteria and Matrix)
โครงการกำหนดเกณฑ์การให้คะแนนความเสี่ยงแบบ 3x3 โดยพิจารณาจาก โอกาสเกิด (Likelihood: L) และผลกระทบ (Impact: I) ดังแสดงในตารางที่ 2.13 เพื่อนำค่าทั้งสองมาคำนวณเป็นระดับความเสี่ยงจากผลคูณของ L x I ตามเมทริกซ์ในตารางที่ 2.14
ตารางที่ 2.13 เกณฑ์การประเมินโอกาสและผลกระทบ (Risk Scale Criteria)
| ระดับ | โอกาสเกิด (Likelihood: L) | ผลกระทบ (Impact: I) |
|---|---|---|
| 1 (ต่ำ) | เกิดขึ้นได้ยาก (น้อยกว่า 10%) | ไม่กระทบฟังก์ชันหลัก ผู้ใช้ยังใช้งานได้ปกติ |
| 2 (กลาง) | เกิดขึ้นเป็นครั้งคราว (10% - 40%) | กระทบฟังก์ชันรอง ผู้ใช้ต้องใช้ความพยายามเพิ่ม |
| 3 (สูง) | เกิดขึ้นบ่อยหรือเกือบทุกครั้ง (> 40%) | ระบบหยุดทำงาน หรือให้ผลลัพธ์ที่ผิดพลาด |
ตารางที่ 2.14 เมทริกซ์ระดับความเสี่ยง (Risk Matrix 3x3)
| L \ I | 1 (ต่ำ) | 2 (กลาง) | 3 (สูง) |
|---|---|---|---|
| 3 (สูง) | 🟡 3 (กลาง) | 🟠 6 (สูง) | 🔴 9 (วิกฤต) |
| 2 (กลาง) | 🟢 2 (ต่ำ) | 🟡 4 (กลาง) | 🟠 6 (สูง) |
| 1 (ต่ำ) | 🟢 1 (ต่ำ) | 🟢 2 (ต่ำ) | 🟡 3 (กลาง) |
เกณฑ์คะแนน: 🟢 1-2 = ต่ำ (Low), 🟡 3-4 = ปานกลาง (Medium), 🟠 6 = สูง (High), 🔴 9 = วิกฤต (Critical)
2.8.3 แผนการรับมือและจัดการความเสี่ยง (Risk Mitigation Plan)
โครงการได้ระบุความเสี่ยงทางเทคนิค 8 ข้อที่เฉพาะเจาะจงกับระบบ AI บนเว็บเบราว์เซอร์ พร้อมกำหนดแผนป้องกันและแผนสำรองสำหรับความเสี่ยงที่มีนัยสำคัญ ดังแจกแจงไว้ในตารางที่ 2.15
ตารางที่ 2.15 การประเมินความเสี่ยง (Risk Assessment Table)
| ID | ภัยคุกคาม / ความเสี่ยง | โอกาสเกิด | ผลกระทบ | ระดับความเสี่ยง | กลยุทธ์การจัดการ (Mitigation Strategy) |
|---|---|---|---|---|---|
| RM-01 | FPS ตกในอุปกรณ์สเปคต่ำ | 3 | 3 | 🔴 9 (วิกฤต) | ป้องกัน: ใช้ WASM และลด Shadow rendering สำรอง: หาก FPS < 15 ให้ปิด Skeleton coding |
| RM-02 | แสงไม่เพียงพอ คุณภาพ Pose ลดลง | 2 | 2 | 🟡 4 (กลาง) | ป้องกัน: ออกแบบระบบ lighting_manager เตือนก่อนรำ |
| RM-03 | Calibration (T-Pose) ไม่สำเร็จ | 2 | 2 | 🟡 4 (กลาง) | ป้องกัน: มี Tutorial วิดีโอสอนการยืนที่ถูกต้อง |
| RM-04 | Network Error ขณะส่งผล Survey | 1 | 1 | 🟢 1 (ต่ำ) | ป้องกัน: ใช้ LocalStorage fallback เพื่อส่งข้อมูลภายหลัง |
| RM-05 | Browser ไม่รองรับ Canvas WebGL | 1 | 3 | 🟡 3 (กลาง) | ป้องกัน: Compatibility Check ก่อนเข้าแอปพลิเคชัน |
| RM-06 | กล้องถูกบล็อก Permission Denied | 2 | 3 | 🟠 6 (สูง) | ป้องกัน: มีหน้าจอ Pre-permission อธิบายเหตุผล สำรอง: แสดงวิดีโอสอนการตั้งค่าราย Browser |
| RM-07 | เสื้อผ้าทำให้ Pose คลาดเคลื่อน | 2 | 2 | 🟡 4 (กลาง) | ป้องกัน: ใช้ Noise Filter และคำแนะนำการแต่งกาย |
| RM-08 | MediaPipe API เปลี่ยนเวอร์ชัน | 1 | 3 | 🟡 3 (กลาง) | ป้องกัน: Pin versioning ในไฟล์ configuration |
โดยสรุป กระบวนการจัดการความเสี่ยงที่เข้มงวดนี้ช่วยให้โครงการสามารถรับมือกิจกรรมที่ไม่คาดคิดได้อย่างมีระบบ โดยเฉพาะในระดับวิกฤต (Critical) และระดับสูง (High) ซึ่งแผนงานเหล่านี้จะถูกติดตามและประเมินผลอย่างต่อเนื่องในบทที่ 4 เพื่อยืนยันความเสถียรของระบบในสภาวะการใช้งานจริง
2.9 สถิติโครงการ (Project Statistics)
สถิติต่อไปนี้สะท้อนขอบเขตงานจริงที่ดำเนินการใน Phase 1 (v1.3.x) แบ่งเป็นสถิติเชิงซอร์สโค้ดในตารางที่ 2.16 และสถิติเอกสารในตารางที่ 2.17
ตารางที่ 2.16 สถิติซอร์สโค้ดและไลบรารี (Source Code Statistics)
| ประเภทไฟล์ | จำนวน | หมายเหตุ |
|---|---|---|
| JavaScript Modules | 60 | รวม Heuristics Rules, Controllers, Managers, Utils |
| CSS Style Sheets | 4 | รวม Mobile-responsive, Dark Mode และ Animation |
| HTML Documents | 5 | รวม Main App, Collector, Result Summary และ Landing |
| รวมไฟล์โค้ด | 69 | พัฒนาด้วยสถาปัตยกรรม Clean Code และ Separation of Concerns |
ตารางที่ 2.17 สถิติเอกสารและงานออกแบบ (Artifact Statistics)
| ประเภทเอกสาร | จำนวน | หมายเหตุ |
|---|---|---|
| UML / Technical Diagrams | 45 | วาดด้วย PlantUML และ Mermaid.js |
| Technical Doc (ISO 29110) | 18 | ครอบคลุม PM และ SI Artifacts |
| Media Assets (ภาพประกอบ) | 37 | รวม Reference Photos และ UI Icons |
| Session Logs (Audit Trail) | 45 | บันทึกการตัดสินใจและการเปลี่ยนแปลง |
| Thesis & Appendix | 18 | รายงานฉบับสมบูรณ์ (Markdown) |
| ข้อมูลย่อยอื่นๆ (Configuration) | 16 | ข้อมูลโครงแบบอื่นๆ ย่อย |
| รวมทั้งสิ้น | 179 | อ้างอิงตามตาราง Configuration Item Table |
สัดส่วนซอร์สโค้ดต่อเอกสาร (69 ต่อ 179 ไฟล์) สะท้อนให้เห็นว่าโครงการนี้ให้ความสำคัญกับการตรวจสอบด้านมาตรฐานและทำเอกสารโครงการมากกว่าปริมาณการเขียนโค้ด ซึ่งเป็นหัวใจสำคัญของการดำเนินงานตามมาตรฐาน ISO/IEC 29110 อย่างครบวงจร
2.10 บทสรุปประจำบท (Chapter Summary)
ตลอดเนื้อหาในบทที่ 2 นี้ ได้เปิดเผยให้เห็นโครงสร้างการดำเนินงานทางวิศวกรรมซอฟต์แวร์และการบริหารโครงการที่เข้มงวดภายใต้กรอบของ ISO/IEC 29110 การแบ่งระยะการดำเนินงาน เป้าหมายหลักในแต่ละเฟส แผนปฏิบัติการ ตลอดจนการจัดการความเสี่ยงและทรัพยากร แสดงให้เห็นถึงทิศทางที่ให้ความสำคัญกับเสถียรภาพและคุณภาพเป็นหลัก ผลลัพธ์เชิงตัวเลขและกลไกการควบคุมในทุกระดับเหล่านี้ ล้วนเป็นการวางรากฐานความเชื่อมั่นที่จะนำพาไปสู่ความเข้าใจเชิงลึกของการออกแบบระบบ ซึ่งจะถูกอธิบายรายละเอียดในบทที่ 3 (System Design and Implementation) ลำดับถัดไป