ระบุปัญหา

ทำไมต้องรู้

โครงงานที่ล้มเหลวส่วนใหญ่ไม่ได้ล้มเพราะเทคนิคไม่ดี แต่เพราะแก้ปัญหาผิดข้อ ทีมที่เริ่มจาก “อยากทำโดรนตรวจจับด้วย AI” มักได้ระบบที่ทำงานได้ แต่ไม่มีใครต้องการใช้ ส่วนทีมที่เริ่มจากปัญหาจริงของผู้ใช้ จะรู้ว่าต้องสร้างอะไร และรู้ว่าเมื่อไรถือว่าสำเร็จ เกณฑ์ ABET สำหรับหลักสูตรเทคโนโลยีกำหนดให้มีโครงงานที่บูรณาการทักษะทั้งด้านเทคนิคและไม่ใช่เทคนิคเพื่อแก้ปัญหา ซึ่งคือสิ่งที่วิชานี้ทำ

ทั้งวิชาใช้กรณีสมมติเดียว: โครงงานระบบโดรนตรวจแนวคลองชลประทานยาว 2 km แบบอัตโนมัติ ขยายจากโจทย์ในหน่วยความรู้แนวคิดภารกิจของคลังความรู้โดรน วิชานี้เป็นโครงงานภาคแรก จบที่ ข้อเสนอโครงงาน ส่วนการสร้างและทดสอบอยู่ในโครงงานภาคถัดไป แต่ละโมดูลมีชิ้นงานของโครงงานที่ต้องส่ง โค้ด Python ของทุกโมดูลดาวน์โหลดได้ที่ /downloads/uat-493/

ผู้มีส่วนได้เสีย

ผู้มีส่วนได้เสีย (stakeholder) คือทุกคนที่ได้รับผลหรือมีอำนาจต่อโครงงาน ไม่ใช่แค่ลูกค้า

ความต้องการของแต่ละกลุ่มอาจขัดกัน เช่น สำนักงานชลประทานต้องการภาพละเอียด แต่ชุมชนริมคลองกังวลเรื่องการถ่ายภาพบ้านเรือน การระบุตั้งแต่ต้นทำให้ออกแบบรองรับได้ เช่น กำหนดขอบเขตการถ่ายภาพและลบภาพที่ไม่เกี่ยวข้อง

ประโยคปัญหาและ ConOps

ประโยคปัญหา ที่ดีบอกว่าใครเจอปัญหาอะไร ผลกระทบคืออะไร และวัดได้อย่างไร โดย ไม่บอกวิธีแก้

• ไม่ดี: “ต้องการโดรนที่มี AI ตรวจคลอง” (บอกวิธีแก้ไว้แล้ว)
• ดีกว่า: “สำนักงานชลประทานพบจุดชำรุดของคันคลองหลังน้ำรั่วแล้วเท่านั้น เพราะเจ้าหน้าที่เดินตรวจแนว 2 km ได้เดือนละครั้ง ทำให้ซ่อมช้าและน้ำสูญเสีย”

แนวคิดการปฏิบัติการ (ConOps) ตามคู่มือวิศวกรรมระบบของ NASA อธิบายว่าระบบจะถูกใช้อย่างไรเพื่อตอบความต้องการ โดยมักเล่าตามลำดับเวลาจากมุมของผู้ใช้

ทะเบียนสมมติฐานและการประมาณขนาดภารกิจ

ทุกการประมาณในขั้นนี้ตั้งบนสมมติฐาน ทะเบียนสมมติฐาน (assumption register) บันทึกแต่ละข้อพร้อมเจ้าของข้อมูล วิธีตรวจ และสถานะ เพื่อไม่ให้สมมติฐานกลายเป็นข้อเท็จจริงโดยไม่มีใครตรวจ

import math

assumptions = {  # ค่า, เจ้าของข้อมูล, สถานะ
    "canal length m": (2000, "irrigation office map", "checked"),
    "corridor width m": (60, "site visit", "to check"),
    "footprint across track m": (90, "camera spec at 60 m height", "to check"),
    "footprint along track m": (60, "camera spec at 60 m height", "to check"),
    "forward overlap": (0.75, "mapping practice for the team", "assumed"),
    "ground speed m/s": (5.0, "flight test", "to check"),
}
v = {k: val for k, (val, _, _) in assumptions.items()}
spacing = v["footprint along track m"] * (1 - v["forward overlap"])
passes = math.ceil(v["corridor width m"] / v["footprint across track m"])
photos = passes * (math.floor(v["canal length m"] / spacing) + 1)
flight_min = passes * v["canal length m"] / v["ground speed m/s"] / 60 + 3     # + 3 นาทีขึ้นลงและเดินทาง
print(f"photo spacing {spacing:.0f} m, passes {passes}, photos {photos}, flight ≈ {flight_min:.1f} min per round")
print(f"weekly for a year: {52 * photos:,} photos, about {52 * photos * 25 / 1000:.0f} GB at 25 MB each")
unchecked = [k for k, (_, _, st) in assumptions.items() if st != "checked"]
print(f"{len(unchecked)} of {len(assumptions)} assumptions not yet checked:", ", ".join(unchecked))

photo spacing 15 m, passes 1, photos 134, flight ≈ 9.7 min per round
weekly for a year: 6,968 photos, about 174 GB at 25 MB each
5 of 6 assumptions not yet checked: corridor width m, footprint across track m, footprint along track m, forward overlap, ground speed m/s

ปฏิบัติการประจำโมดูล

ข้อผิดพลาดที่พบบ่อย

สรุป

• เริ่มจากผู้มีส่วนได้เสียและความต้องการจริง ไม่ใช่เทคโนโลยี
• ประโยคปัญหาบอกผลกระทบที่วัดได้โดยไม่บอกวิธีแก้ และ ConOps เล่าการใช้งานตามลำดับเวลา
• ทะเบียนสมมติฐานแยกสิ่งที่รู้กับสิ่งที่ต้องตรวจ และชี้ว่าต้องตรวจอะไรก่อน
• Verification คือสร้างถูกตามข้อกำหนด validation คือสร้างสิ่งที่ถูกต้อง

แบบฝึกตรวจความเข้าใจ

1. “ต้องการโดรนติดกล้องความร้อน” เป็นประโยคปัญหาที่ดีหรือไม่ เพราะอะไร
2. ภาพยาวตามแนวบิน 60 m ซ้อนทับ 80% ระยะห่างระหว่างภาพเท่าใด
3. แนวบินยาว 1,500 m ระยะห่างระหว่างภาพ 15 m ต้องถ่ายกี่ภาพ
4. คำถาม “สร้างสิ่งที่ถูกต้องหรือไม่” คือ verification หรือ validation
5. ทะเบียนสมมติฐานควรบันทึกอะไรนอกจากค่าที่สมมติ