เลือกข้ามไปยังสไลด์ที่ต้องการ (กดปุ่มลูกศรซ้าย/ขวาบนคีย์บอร์ดได้)
SLIDE 01 · WEEK 2 OVERVIEW Practiced Level (P) คณะวิทยาศาสตร์ มหาวิทยาลัยอุบลราชธานี

การกำหนดขอบเขตและโจทย์ปัญหา

Project Scope & Problem Statement — เปลี่ยน Pain Point ในโลกจริงให้เป็นโครงงานด้าน Data Science และ Software Innovation ที่วัดผลและส่งมอบได้จริงภายใน 15 สัปดาห์

รหัสวิชาและหน่วยกิต
3(0-6-3)

1145 204 โครงงานสำหรับนักศึกษาปีสอง (ปฏิบัติ 6 ชม./สัปดาห์)

ขนาดทีมที่กำหนด
1–3 คน

โครงงานเดี่ยวหรือกลุ่มตามใบงาน Project Inception Package

กรอบเวลาพัฒนา
15 สัปดาห์

ครอบคลุม Inception, Sprint 1, Midterm และ Sprint 2 จนถึง Deploy

ชิ้นงานหลักสัปดาห์ที่ 2
Charter

Draft Project Proposal / Project Charter (ส่วนที่ 2 ของใบงาน W1–3)

YEAR 1 · 1145 103

Reinforced (R)

สกัดและทำความสะอาดข้อมูลจาก Log/CSV คำนวณสถิติพื้นฐาน และตระหนักถึง PDPA ในงานเดี่ยวหรือกลุ่มเล็ก

YEAR 2 · 1145 204 (ปัจจุบัน)

Practiced (P)

พัฒนาซอฟต์แวร์และวิเคราะห์ข้อมูลแบบทีมด้วย Agile/Scrum ฐานข้อมูล 3NF บริหารความเสี่ยง และสอบป้องกัน

YEAR 3 · 1145 310 & 317

Mastery (M)

Capstone Project 1 ปีการศึกษาเต็ม บูรณาการ AI/Big Data ขั้นสูง (DS) หรือ Cloud Microservices (SI)

หัวข้อหลักในการบรรยายและปฏิบัติการวันนี้:
01 วิเคราะห์โจทย์ปัญหา DS & SI 02 กำหนด Scope & SMART ใน 15 สัปดาห์ 03 กรณีศึกษา Grocery POS Platform 04 ร่าง Project Charter และกิจกรรม Lab
SLIDE 02 · OUTCOME ALIGNMENT มคอ.3 รายวิชา 1145 204 & มคอ.2 หลักสูตร DSSI 2568

ทำไมสัปดาห์ที่ 2 จึงเป็นจุดชี้ขาดความสำเร็จของโครงงาน

เชื่อมโยง Lesson Learning Outcome (LLO) สัปดาห์ที่ 2 เข้ากับสมรรถนะ YLO2, CLO1–CLO3 และใบงานรวมสัปดาห์ที่ 1–3

LLO สัปดาห์ที่ 2 (มคอ.3)

"สำรวจโจทย์ปัญหาและวิเคราะห์ขอบเขตโครงงานด้าน Data Science / Software Innovation ได้อย่างเหมาะสม"

ในแผนการประเมินผลของรายวิชา (Evaluation Plan) งานช่วงสัปดาห์ที่ 1–4 ถูกประเมินอย่างต่อเนื่องทั้งในรูปแบบ การประเมินระหว่างกระบวนการเรียนรู้ (15%) และ การประเมินชิ้นงาน (20%) เพื่อป้องกันปัญหาขอบเขตใหญ่เกินกำลังหรือโจทย์ไม่ตอบปัญหาจริงตั้งแต่ต้นเทอม

บทบาทในใบงานรวมสัปดาห์ที่ 1–3 (Project Inception Package)

งานสัปดาห์ที่ 2 คือ ส่วนที่ 2: ร่างข้อเสนอโครงงาน (Project Proposal / Charter) ซึ่งต้องส่งรวมกับใบจัดตั้งทีม (W1) และ SRS / User Story Backlog (W3) เป็นไฟล์ PDF ฉบับรวม 1 ไฟล์

ความเชื่อมโยงกับ CLO และ PLO
  • CLO1 (Agile & Team): แบ่งบทบาทในทีม 1–3 คนและกำหนดเป้าหมายที่ทีมรับผิดชอบร่วมกันได้จริง
  • CLO2 (Software Eng): วางรากฐานสู่การออกแบบ SRS, User Stories และฐานข้อมูล 3NF ในสัปดาห์ถัดไป
  • CLO3 (Risk & Analysis): ประเมินความเป็นไปได้เชิงเทคนิคและจำกัดความเสี่ยง Scope Creep ตั้งแต่ต้น
  • PLO1 & PLO2 (P): วิเคราะห์ปัญหาจากข้อมูลองค์กรและออกแบบซอฟต์แวร์ตามหลักวิศวกรรม
  • PLO5 (PDPA & Ethics): ระบุขอบเขตข้อมูลส่วนบุคคลที่ต้องปกปิดหรือขออนุญาตตั้งแต่ขั้นกำหนดโจทย์
Data Science (DSLO1–2)

ฝึกใช้ข้อมูลจริงเพื่อหา Insight, คำนวณ Reorder Point หรือสร้างโมเดลทำนายเบื้องต้นที่ช่วยตัดสินใจในองค์กร

Software Innovation (SILO1–2)

ฝึกบูรณาการเครื่องมือทันสมัย ออกแบบระบบที่เสถียร ปลอดภัย และติดตั้งใช้งานจริงบน Cloud ได้

YLO2 Milestone

นักศึกษาปี 2 ต้องก้าวข้ามจากการเขียนสคริปต์เดี่ยว ไปสู่การส่งมอบระบบหรือ Data Product ที่ทำงานร่วมกันได้

SLIDE 03 · PROBLEM DISCOVERY หัวข้อที่ 1: การสำรวจและวิเคราะห์โจทย์ปัญหาด้าน Data Science & Software Innovation

แยก "อาการของปัญหา" ออกจาก "รากปัญหาที่แก้ได้ด้วยระบบ"

โจทย์ที่ดีต้องไม่ได้เริ่มจาก "อยากใช้เทคโนโลยีอะไร" แต่เริ่มจาก "ใครกำลังประสบปัญหาอะไร ข้อมูลใดมีอยู่จริง และวัดผลดีขึ้นได้อย่างไร"

STEP 01

Pain Point จริง

ระบุขั้นตอนที่ช้า ผิดพลาดซ้ำ หรือสูญเสียต้นทุนในธุรกิจ/หน่วยงาน (เช่น สต็อกขาด หรือคีย์ข้อมูลซ้ำซ้อน)

STEP 02

ผู้ได้รับผลกระทบ

ใครคือผู้ใช้หลัก (เช่น แคชเชียร์ เจ้าของร้าน ผู้จัดการคลัง) และมีความถี่ในการใช้งานบ่อยเพียงใด

STEP 03

ความพร้อมของข้อมูล

มีข้อมูล Transaction, CSV หรือ Logs ให้ทดสอบหรือไม่ หากต้องเก็บใหม่ต้องไม่ติดข้อจำกัด PDPA

STEP 04

คุณค่าที่วัดผลได้

ระบุผลลัพธ์เชิงปริมาณก่อน-หลัง (เช่น ลดเวลาเช็กสต็อก, แจ้งเตือนก่อนสินค้าหมดล่วงหน้า)

มิติการวิเคราะห์ โจทย์สาย Software Innovation (SI) โจทย์สาย Data Science (DS)
จุดเน้นของปัญหา กระบวนการทำงานติดขัด ขาดระบบรวมศูนย์ การทำงานซ้ำซ้อน หรือข้อมูลไม่ซิงค์กัน มีข้อมูลจำนวนมากแต่ขาดการวิเคราะห์เชิงลึก ไม่รู้แนวโน้มหรือจุดตัดสินใจที่แม่นยำ
แนวทางแก้ปัญหา (Solution) ออกแบบ Web/App Workflow, Relational DB (3NF), API, ระบบสิทธิ์ และ Automated Testing Data Pipeline ทำความสะอาดข้อมูล, Exploratory Analytics, โมเดลพยากรณ์/แนะนำ, Dashboard
หลักฐานความสำเร็จ Working Software ที่ทำงานครบ User Stories, API ถูกต้อง, ผ่าน Unit/Integration & Usability Test Data Insights ที่นำไปตัดสินใจได้จริง, Dashboard ชัดเจน, ค่าชี้วัดโมเดล (เช่น MAE, Precision)
สูตร "Elevator Test Statement" สำหรับสรุปโจทย์ปัญหาให้คมชัดใน 3 ประโยค:

"สำหรับ [กลุ่มผู้ใช้งานเป้าหมาย] ที่ประสบปัญหา [Pain Point หลัก], ระบบ [ชื่อโครงงาน] เป็น [ประเภทซอฟต์แวร์/Data Product] ที่ช่วยให้ [ประโยชน์สำคัญที่วัดได้] แตกต่างจากวิธีเดิมตรงที่ [จุดเด่นของแนวทางใหม่]"

SLIDE 04 · SMART OBJECTIVES หัวข้อที่ 2: การกำหนดวัตถุประสงค์และขอบเขตโครงงานที่วัดผลได้

เปลี่ยนเป้าหมายกว้าง ๆ ให้เป็นวัตถุประสงค์แบบ SMART

ตามกรอบประกันคุณภาพ AUN-QA วัตถุประสงค์ที่ดีต้องสังเกตและประเมินได้ชัดเจน เพื่อใช้ตรวจรับงานในวันสอบ Midterm และ Final Defense

S · Specific

จำเพาะเจาะจง

ระบุชัดว่าพัฒนาระบบอะไร สำหรับผู้ใช้กลุ่มใด ครอบคลุมโมดูลใดบ้าง

M · Measurable

วัดผลได้

มีตัวเลขหรือเกณฑ์ชี้วัด เช่น จำนวน Test Cases, Test Coverage, เวลาตอบสนอง หรือค่าความแม่นยำ

A · Achievable

ทำได้จริง

สอดคล้องกับทักษะและจำนวนสมาชิก (1–3 คน) ไม่ต้องพึ่งทรัพยากรที่เข้าไม่ถึง

R · Relevant

ตรงประเด็น

แก้ Pain Point ใน Problem Statement และตอบโจทย์สาย DS/SI ของรายวิชา

T · Time-bound

มีกรอบเวลาชัด

แบ่งส่งมอบเป็น Milestone ได้ภายใน 15 สัปดาห์ (MVP สัปดาห์ 8, Final สัปดาห์ 15)

ตัวอย่างที่ควรหลีกเลี่ยง (คลุมเครือ)
  • "เพื่อพัฒนาระบบร้านค้าออนไลน์ให้ทันสมัยและใช้งานง่าย" (วัดผลไม่ได้ ไม่ระบุโมดูลและผู้ใช้)
  • "เพื่อใช้ AI ทำนายยอดขายให้แม่นยำที่สุดเท่าที่จะทำได้" (ไม่มีเกณฑ์ชี้วัด ไม่มีกรอบข้อมูลและเวลา)
  • "เพื่อสร้างแพลตฟอร์มระดับองค์กรรองรับทุกสาขาทั่วประเทศ" (ใหญ่เกินกำลังคนปี 2 ใน 15 สัปดาห์)
ตัวอย่างที่ดีตามหลัก SMART (วัดผลได้)
  • "พัฒนาระบบ POS หน้าร้านและตัดสต็อกคลังสินค้าแบบ 3NF สำหรับร้านขายของชำ 1 สาขา พร้อมแจ้งเตือนสินค้าใกล้หมดภายใน 15 สัปดาห์"
  • "สร้างโมเดลคำนวณ Reorder Point และ Dashboard สรุปสินค้าขายดี/ชั่วโมงเร่งด่วน โดยผ่านการทดสอบ Usability จากผู้ใช้จริงอย่างน้อย 5 ราย"
SLIDE 05 · 15-WEEK FEASIBILITY วางแผนตามโครงสร้าง มคอ.3 รายวิชา 1145 204

กรอบเวลาจริง 15 สัปดาห์: อย่าออกแบบ Scope เกินจำนวนชั่วโมงที่มี

รายวิชา 3(0-6-3) มีเวลาทำงานมาตรฐาน 9 ชม./สัปดาห์/คน รวมประมาณ 135 ชั่วโมงต่อคนตลอดภาคการศึกษา

ช่วงสัปดาห์ ระยะพัฒนา (Phase) กิจกรรมและเป้าหมายหลักตาม มคอ.3 จุดตรวจสอบสำคัญ (Gate)
W1 – W3 Inception Phase ตั้งทีม 1–3 คน (W1) → กำหนดโจทย์และ Scope (W2) → เขียน SRS, User Stories & Risk Plan (W3) ส่ง Project Inception Package
W4 – W7 Sprint 1 (Core MVP) ตั้ง Agile Board & Git Workflow (W4) → ออกแบบ Architecture, ER 3NF & API (W5) → พัฒนา Core Module & Code Review โค้ดแกนหลักทำงานได้จริง
W8 Midterm Defense สอบนำเสนอความก้าวหน้ากลางภาคและสาธิต Working Prototype ต่อคณะกรรมการ รับ Feedback ปรับ Backlog
W9 – W13 Sprint 2 & QA ปรับปรุงตาม Feedback + พัฒนาฟีเจอร์หลักวิชาเอก (W9–10) → Integrate API (W11) → Risk Review & Testing/Usability (W12–13) ส่ง Sprint 2 & QA Package
W14 – W17 Deploy & Final จัดทำรายงาน 5 บทและคู่มือ (W14) → ติดตั้งบน Cloud/Production (W15) → สอบป้องกัน Final Defense (W16–17) Live System + GitHub + Report
งานเดี่ยว (1 คน) น่าจะทำได้
~135 ชม.

โฟกัส 1 ระบบย่อยที่จบสมบูรณ์ (เช่น POS Checkout + 3NF DB หรือ Analytics Dashboard เฉพาะทาง)

ทีมขนาด 2 คน น่าจะทำได้
~270 ชม.

แบ่งงานชัดเจน เช่น คนที่ 1 Frontend + UX/Testing, คนที่ 2 Backend + DB/Analytics พร้อม Daily Standup

ทีมขนาด 3 คน น่าจะทำได้
~405 ชม.

รองรับระบบครบวงจร (POS + คลังสินค้า + โมดูลวิเคราะห์ข้อมูล/แจ้งเตือน + CI/Deploy) ต้องบริหาร Git Branch อย่างเคร่งครัด

SLIDE 06 · INTERACTIVE TOOL ทดลองปรับขนาดทีมและโมดูลเพื่อเช็ก Feasibility ใน 15 สัปดาห์

Scope & Feasibility Estimator: โครงงานของทีมคุณ "พอดี" หรือ "เกินกำลัง"

เลือกจำนวนสมาชิก สายโครงงาน และฟีเจอร์ที่ตั้งใจทำ เพื่อประเมินภาระงาน (Story Points และชั่วโมง) เทียบกับเพดานเวลา 15 สัปดาห์

1. จำนวนสมาชิกในทีม (ตามเกณฑ์ใบงานสัปดาห์ที่ 1–3)
2. เลือกฟีเจอร์/โมดูลที่ต้องการใส่ในขอบเขตโครงงาน (In-Scope)
ผลการประเมินความเป็นไปได้ (15 สัปดาห์)
ภาระงานประเมิน
190 ชม.
เพดานกำลังคนทีม
270 ชม.
อัตราการใช้กำลังคน (รวมเผื่อ Buffer สอบ/เอกสาร 25%) 70%
เหมาะสมมาก: อยู่ในเกณฑ์ "ดีเยี่ยม" ของ Rubric ด้านขอบเขตและความเป็นไปได้

มี Buffer เพียงพอสำหรับการทำ Documentation 5 บท, แก้ไขตาม Feedback กลางภาค และทดสอบระบบก่อนสอบ Final

หมายเหตุ: คำนวณจากเกณฑ์ 3(0-6-3) = 9 ชม./สัปดาห์/คน × 15 สัปดาห์ (135 ชม./คน) โดยควรสงวนเวลา 20–25% สำหรับเอกสารและการสอบป้องกัน
SLIDE 07 · CASE STUDY หัวข้อที่ 3: กรณีศึกษาตัวอย่างระบบ Grocery POS Platform

Grocery POS Platform: จากปัญหาหน้าร้านค้าปลีกสู่ขอบเขตโครงงานปี 2

ประยุกต์โครงสร้างระบบ POS ร้านค้าสู่บริบทร้านขายของชำ/ซูเปอร์มาร์เก็ตขนาดเล็ก (Grocery) ที่มีสินค้าหลากหลาย SKU และวันหมดอายุ

Problem Statement ตัวอย่าง (Grocery Store):

ร้านขายของชำท้องถิ่นมีสินค้ากว่า 800–1,500 SKU แต่ยังจดบันทึกยอดขายด้วยกระดาษหรือสเปรดชีต ทำให้เกิดปัญหาคิดเงินช้าในช่วงเร่งด่วน สต็อกสินค้าหมดโดยไม่รู้ตัว สินค้ากลุ่มนม/เบเกอรีหมดอายุค้างสต็อก และเจ้าของร้านไม่มีข้อมูลประกอบการสั่งซื้อสินค้าเข้าคลังอย่างมีระบบ

In-Scope (ทำจริงใน 15 สัปดาห์ · ปี 2 Practiced)
  • POS Checkout: ค้นหา/สแกนรหัสสินค้า คำนวณยอดรวม รับเงินสด/PromptPay QR และออกใบเสร็จ
  • Batch & Expiry Inventory: ตัดสต็อกอัตโนมัติตามล็อตสินค้า พร้อมแจ้งเตือนสินค้าต่ำกว่า Reorder Point และใกล้หมดอายุ
  • Sales & Reorder Analytics: คำนวณจุดสั่งซื้อใหม่ (ROP) แสดงสินค้าขายดี และช่วงเวลาเร่งด่วน (Peak Hours)
  • QA & Deployment: ทดสอบ Unit/Integration Test และติดตั้ง Live Web App สำหรับ 1 สาขา
Out-of-Scope (ตัดออก เพื่อต่อยอดปี 3 Mastery)
  • Multi-Branch Cloud Microservices: สถาปัตยกรรม Kubernetes แยกหลาย Service รองรับหลายสิบสาขาพร้อมกัน
  • Offline-First Hardware Sync: ระบบแคช Local IndexedDB และเชื่อมต่อเครื่อง EDC/ลิ้นชักเก็บเงินจริง
  • Deep Learning Forecasting: โมเดล LSTM พยากรณ์ร่วมกับข้อมูลสภาพอากาศและจราจรหลายปี
  • ระบบบัญชีภาษีเต็มรูปแบบ: การออกใบกำกับภาษีอิเล็กทรอนิกส์ (e-Tax) และเชื่อมกรมสรรพากร
Core Relational Tables (Normalized to 3NF)

• Users (user_id, username, password_hash, role_enum)
• Categories (category_id, category_name, shelf_zone)
• Products (product_id, category_id, barcode, sku_name, unit_price, reorder_point)
• Inventory_Batches (batch_id, product_id, qty_remaining, cost_per_unit, expiry_date)
• Orders (order_id, user_id, order_datetime, total_amount, payment_method, status)
• Order_Items (order_item_id, order_id, batch_id, quantity, subtotal)
จุดสังเกตด้านวิศวกรรมข้อมูล (ปี 2)

ความแตกต่างสำคัญระหว่างร้านกาแฟกับ Grocery POS คือการเพิ่มตาราง Inventory_Batches เพื่อติดตามวันหมดอายุ (FEFO: First-Expired, First-Out) และ barcode สำหรับค้นหาสินค้าความเร็วสูงหน้าร้าน

ความเสี่ยงทางเทคนิคที่ต้องวางแผน (CLO3): กรณีสินค้า 1 ชิ้นถูกตัดสต็อกพร้อมกันจาก 2 หน้าจอ (Concurrency / Race Condition) ต้องใช้ Database Transaction เพื่อรักษาความถูกต้องของยอดคงเหลือ

ตัวอย่าง Agile User Stories
  • Cashier: "ในฐานะพนักงานแคชเชียร์ ฉันต้องการสแกนบาร์โค้ดสินค้าและเลือกวิธีชำระเงิน เพื่อคิดเงินและออกใบเสร็จให้ลูกค้าได้ภายใน 30 วินาที"
  • Store Manager: "ในฐานะผู้จัดการร้าน ฉันต้องการดูรายการสินค้าที่ต่ำกว่า Reorder Point และใกล้หมดอายุใน 7 วัน เพื่อวางแผนสั่งซื้อและจัดโปรโมชันลดราคาได้ทันเวลา"
  • Analyst / Owner: "ในฐานะเจ้าของร้าน ฉันต้องการดูรายงานยอดขายแยกตามหมวดหมู่และช่วงเวลา Peak Hours เพื่อจัดตารางพนักงานและสต็อกสินค้าให้เหมาะสม"
จริยธรรมและความเป็นส่วนตัวข้อมูล (PLO5 / PDPA)

ในการเก็บข้อมูลการขายหรือประวัติสมาชิก (Loyalty) เพื่อนำไปวิเคราะห์หรือทดสอบระบบ:

  • ไม่เก็บข้อมูลส่วนบุคคลที่ไม่จำเป็น (Data Minimization) เช่น เลขบัตรประชาชน
  • ทำการ Mask / Anonymize เบอร์โทรศัพท์หรือรหัสสมาชิกก่อนนำข้อมูลไปวิเคราะห์บน Dashboard
  • ใช้ password_hash สำหรับบัญชีผู้ใช้และแยกสิทธิ์ Admin กับ Cashier ชัดเจน
SLIDE 08 · DUAL-TRACK LENS ปรับจุดเน้นของ Grocery POS Platform ให้เหมาะกับความถนัดของทีม

โจทย์ Grocery POS เดียวกัน แต่เน้นจุดขายคนละมุมตามสายวิชาเอก

นักศึกษาปี 2 สามารถเลือกโฟกัสเชิงลึกด้าน Software Innovation หรือ Data Science บนฐานข้อมูลร้านขายของชำเดียวกันได้

แนวทาง A: เน้น Software Innovation (SILO1 / SILO2)

Grocery POS & Transaction-Safe Inventory System

ปัญหาหลักที่โฟกัส: ความเร็วและความถูกต้องในการขายหน้าร้าน การตัดสต็อกแบบ Real-time และความเสถียรของระบบ

  • สถาปัตยกรรม: REST API แยก Frontend/Backend ชัดเจน พร้อม Error Handling และ Transaction Lock ป้องกันสต็อกติดลบ
  • ฟีเจอร์เด่น: ระบบตะกร้าแบบ Hotkey/Barcode, คืนสินค้า/ยกเลิกบิล, แจ้งเตือนสต็อกและวันหมดอายุอัตโนมัติ
  • การวัดผล: Automated Unit/Integration Test Coverage, API Latency หน้าร้าน, Usability Test กับผู้ใช้จริง
แนวทาง B: เน้น Data Science (DSLO1 / DSLO2)

Grocery Sales Analytics & Smart Reorder Platform

ปัญหาหลักที่โฟกัส: การสั่งซื้อของเข้าร้านด้วยความรู้สึกทำให้เงินจมหรือของขาด และการวางสินค้าไม่สอดคล้องพฤติกรรมซื้อ

  • ท่อลำเลียงข้อมูล: Data Cleaning & Aggregation จาก Transaction Logs สู่ Analytics Views
  • ฟีเจอร์เด่น: คำนวณ Reorder Point (ROP) & Safety Stock จากสถิติจริง, Market Basket Analysis (สินค้าที่มักซื้อคู่กัน), Dashboard ผลกำไร
  • การวัดผล: ความแม่นยำในการเตือน Reorder, Rule Support/Confidence ในการแนะนำโปรโมชันจัดเซตสินค้า
คำแนะนำสำหรับทีมผสม (Hybrid 2–3 คน):

หากทีมมีทั้งคนที่ถนัดพัฒนาเว็บและคนที่ถนัดวิเคราะห์ข้อมูล แนะนำให้ใช้ โมเดลแบ่งแกนกลาง + 1 โมดูลเสริม เช่น ทำ Core POS + 3NF Inventory ให้เสร็จใน Sprint 1 (สัปดาห์ที่ 7) แล้วใช้ Sprint 2 เพิ่ม Dashboard วิเคราะห์ Reorder Point หรือ Association Rules

SLIDE 09 · DRAFT PROJECT CHARTER หัวข้อที่ 4: คำแนะนำการจัดทำ Draft Project Proposal / Project Charter

แบบร่าง Project Charter และเช็กลิสต์เตรียมส่งงานสัปดาห์ที่ 2

ตรวจสอบองค์ประกอบทั้ง 4 ส่วนตามใบงาน Project Inception Package พร้อมทดลองร่าง Elevator Statement ของทีมคุณ

องค์ประกอบใน Draft Proposal (ส่วนที่ 2) เกณฑ์ระดับ "ดีเยี่ยม" (22–25 / 25 คะแนน)
1. ชื่อโครงงาน (ไทยและอังกฤษ) สื่อถึงระบบและขอบเขตชัดเจน ไม่กว้างเกินจริง
2. ความสำคัญและที่มาของปัญหา ระบุ Pain Point จริง กลุ่มผู้ได้รับผลกระทบ และหลักฐาน/บริบทปัญหาชัดเจน
3. วัตถุประสงค์ & ขอบเขต (15 สัปดาห์) วัดผลแบบ SMART, แยก In/Out-of-Scope ชัด, เหมาะกับกำลังคน 1–3 คนและ YLO2
4. ผู้ใช้งานเป้าหมาย & ประโยชน์ ระบุ User Roles ครบ ประโยชน์เชื่อมโยงผลลัพธ์จริงและตระหนักด้าน PDPA
พื้นที่ทดลองร่าง Project Charter ของทีม (บันทึกอัตโนมัติ)
เช็กลิสต์ก่อนส่ง Draft Charter (6 ข้อ)
ความพร้อมปัจจุบัน: 0 / 6 รายการ
SLIDE 10 · WEEK 2 LAB & NEXT STEPS ห้องปฏิบัติการ SC242 / SC244 · ปฏิบัติการ 6 ชั่วโมง

กิจกรรมปฏิบัติการสัปดาห์ที่ 2 และภารกิจเตรียมพร้อมสู่สัปดาห์ที่ 3

ลงมือวิเคราะห์โจทย์ ปรับขอบเขตกับอาจารย์ผู้สอน และสรุป Draft Project Charter ให้เสร็จสมบูรณ์ภายในคาบปฏิบัติการ

ACTIVITY 01 · 90 นาที

Problem Discovery Matrix

แต่ละทีมระดมสมองระบุ 2–3 โจทย์ปัญหาจริงรอบตัวหรือจากสถานประกอบการ แล้วประเมินความพร้อมของข้อมูล (Data Availability) เพื่อคัดเลือก 1 โจทย์หลัก

ACTIVITY 02 · 120 นาที

Scope Calibration & SMART

เขียนวัตถุประสงค์ SMART 3–4 ข้อ และตาราง In-Scope / Out-of-Scope โดยตรวจสอบกำลังคน (1–3 คน) ด้วยเกณฑ์ 15 สัปดาห์ไม่ให้เกิด Scope Creep

ACTIVITY 03 · 150 นาที

Draft Charter & 5-Min Pitch

จัดทำเอกสาร Draft Project Proposal (ส่วนที่ 2) ความยาว 1–2 หน้า และนำเสนอ 5 นาทีต่อทีมเพื่อรับคำแนะนำจากอาจารย์และเพื่อนร่วมชั้น

สิ่งที่ต้องเตรียมต่อสำหรับสัปดาห์ที่ 3 (Requirements & Risk):
  • นำ Draft Charter ที่ผ่านการปรับปรุงแล้วมาแตกเป็น Functional & Non-Functional Requirements (SRS)
  • เขียน User Story Backlog พร้อมประเมิน Story Points เบื้องต้น
  • จัดทำ Initial Risk Register & Mitigation Plan เพื่อส่งรวมใน ใบงานรวมสัปดาห์ที่ 1–3 (PDF)
ช่องทางปรึกษาอาจารย์นอกเวลาเรียน (มคอ.3)

ผู้สอน: อาจารย์ ดร.วิชิต สมบัติ และ อาจารย์ ดร.ทศพร จูฉิม

เวลาให้คำปรึกษา: ทุกวันจันทร์ เวลา 13.00 – 16.00 น. (แจ้งนัดหมายล่วงหน้าอย่างน้อย 1 วัน)

สถานที่ / ช่องทาง: ห้องพัก SC204 อาคารวิจัย คณะวิทยาศาสตร์ มหาวิทยาลัยอุบลราชธานี หรือ Google Meet / LINE / อีเมล wichit.s@ubu.ac.th

อ้างอิงเนื้อหา: มคอ.3 รายวิชา 1145 204 โครงงานสำหรับนักศึกษาปีสอง · มคอ.2 หลักสูตร วท.บ. วิทยาการข้อมูลและนวัตกรรมซอฟต์แวร์ (ปรับปรุง พ.ศ. 2568) · คู่มือใบงาน Project Inception Package ใช้ปุ่มลูกศร ◄ ► บนคีย์บอร์ดเพื่อเปลี่ยนสไลด์