AI-Powered System Analysis & Design ออกแบบระบบตั้งแต่ Requirement ถึง Architecture

รายละเอียดหลักสูตร

อบรม 2 วัน วันละ 6 ชั่วโมง รวม 12 ชั่วโมง (09:00-16:00 น.) รูปแบบบรรยายพร้อม Workshop ลงมือทำกับโจทย์ระบบจริง ระดับ Beginner ถึง Intermediate เครื่องมือที่ใช้เป็นโอเพนซอร์สหรือมีแบบใช้ฟรีเกือบทั้งหมด ผู้เรียนเตรียมบัญชี ChatGPT หรือ Claude มาเอง ผู้เรียนจะได้ชุด Prompt Template สำหรับงาน SA ทุกขั้นตอน ไฟล์ Diagram ตัวอย่าง Mermaid และ PlantUML และ Template เอกสารออกแบบระบบกลับไปใช้งานจริง เนื้อหาเน้นวิธีคิดและกระบวนการออกแบบ จึงปรับไปใช้กับเครื่องมือ AI ตัวอื่นได้เมื่อเทคโนโลยีเปลี่ยน

Day 1: จาก Requirement สู่ Data Model

Section 1: AI ในงานวิเคราะห์และออกแบบระบบ

• ขั้นตอนงาน SA แบบเดิมและจุดที่กินเวลามากที่สุดจนทีมมักข้ามไป
• งานที่ AI ช่วยได้ดีเทียบกับงานที่ยังต้องอาศัยการตัดสินใจของคน
• ภาพรวมเส้นทางทั้งหมด: Requirement, Use Case, Process Flow, ER Diagram, API, Architecture, Test
• แนวคิด Diagram as Code และเหตุผลที่ควรเก็บงานออกแบบไว้ใน Git
• การเตรียมเครื่องมือและการตั้งค่าให้พร้อมใช้ตลอดสองวัน

Section 2: เก็บและเรียบเรียง Requirement ด้วย AI

• ความต่างระหว่าง Business, Functional และ Non-functional Requirement
• การใช้ AI ช่วยสรุปบันทึกการประชุมและถอดความต้องการออกมาเป็นข้อ ๆ
• การเขียน Requirement ให้ชัดเจน วัดผลได้ และไม่กำกวม
• การให้ AI ตรวจหาความต้องการที่ขัดแย้งกันเองและจุดที่ยังขาดข้อมูล
• การจัดลำดับความสำคัญและการทำ Requirement Traceability
• Lab: แปลงบันทึกการประชุมดิบให้เป็นเอกสาร Requirement ที่พร้อมใช้

Section 3: Use Case และ Actor

• การระบุ Actor และขอบเขตของระบบให้ชัดก่อนเริ่มเขียน Use Case
• การแตก Requirement เป็น Use Case พร้อม Main Flow และ Alternate Flow
• การเขียนเงื่อนไขก่อนและหลังการทำงานให้ครบถ้วน
• การสร้าง Use Case Diagram ด้วย PlantUML และการปรับแก้เป็นโค้ด
• ข้อผิดพลาดที่พบบ่อย เช่น Use Case ละเอียดเกินไปหรือกว้างเกินไป
• Lab: สร้าง Use Case Diagram จาก Requirement ของโจทย์ตนเอง

Section 4: Process Flow และ Sequence Diagram

• การเขียน Business Process Flow ให้เห็นลำดับงานและผู้รับผิดชอบ
• การใช้ Mermaid เขียน Flowchart และการจัดวางให้อ่านง่าย
• การเขียน Sequence Diagram เพื่ออธิบายการคุยกันระหว่างส่วนของระบบ
• การจัดการเงื่อนไข การวนซ้ำ และกรณียกเว้นใน Diagram
• Lab: เขียน Process Flow และ Sequence Diagram ของกระบวนการหลักด้วย Mermaid

Section 5: ER Diagram และการออกแบบฐานข้อมูล

• การถอด Entity และความสัมพันธ์ออกมาจาก Requirement และ Use Case
• การกำหนด Primary Key, Foreign Key และ Cardinality ให้ถูกต้อง
• หลักการ Normalization และเมื่อใดที่การ Denormalize คุ้มกว่า
• การสร้าง ER Diagram ด้วย Mermaid และการแปลงเป็นสคริปต์สร้างตาราง
• Lab: ออกแบบ ER Diagram แล้วสร้างตารางจริงบน PostgreSQL เพื่อทดสอบ

Section 6: ตรวจทาน Data Model ก่อนไปต่อ

• การใช้ AI ตรวจสอบว่า Data Model รองรับทุก Use Case ที่เขียนไว้หรือไม่
• การทดสอบด้วยข้อมูลตัวอย่างและ Query จริงเพื่อหาจุดที่ออกแบบพลาด
• การพิจารณาปริมาณข้อมูลและ Index ที่จำเป็นตั้งแต่ตอนออกแบบ
• Lab: ตรวจทานและปรับ Data Model ของตนเองจนรองรับทุก Use Case

Day 2: จาก API สู่ Architecture และ Test

Section 7: ออกแบบ API ด้วย OpenAPI

• การถอดรายการ API ที่ต้องมีออกมาจาก Use Case
• หลักการออกแบบ REST: การตั้งชื่อ Resource, การเลือก Method และรหัสสถานะ
• การเขียนสเปกด้วย OpenAPI พร้อม Request, Response และ Error Model
• การใช้ AI ช่วยร่างสเปกและการตรวจว่าครอบคลุมทุกกรณี
• การใช้สเปกให้ทีม Frontend และ Backend ทำงานคู่ขนานได้ตั้งแต่ยังไม่มีระบบจริง
• Lab: เขียนสเปก OpenAPI ของระบบตนเองและตรวจสอบความถูกต้อง

Section 8: ออกแบบสถาปัตยกรรมระบบ

• องค์ประกอบของสถาปัตยกรรม: ส่วนหน้าจอ ส่วนประมวลผล ฐานข้อมูล และบริการภายนอก
• การเลือกรูปแบบสถาปัตยกรรมให้เหมาะกับขนาดทีมและความซับซ้อนของงาน
• การเขียน Architecture Diagram ด้วย Mermaid และการปรับแต่งด้วย Draw.io
• การระบุ Non-functional Requirement ลงในผัง เช่น ความปลอดภัยและการรองรับโหลด
• Lab: ร่างสถาปัตยกรรมของระบบตนเองพร้อมอธิบายเหตุผลของทุกองค์ประกอบ

Section 9: Test Scenario และ Test Case

• การแตก Test Scenario ออกมาจาก Use Case ให้ครบทั้งกรณีปกติและกรณียกเว้น
• การเขียน Test Case ที่ระบุเงื่อนไขเริ่มต้น ขั้นตอน และผลลัพธ์ที่คาดหวัง
• การใช้ AI ช่วยหากรณีทดสอบที่คนมักมองข้าม เช่น ค่าขอบเขตและข้อมูลผิดรูปแบบ
• การเชื่อม Test Case กลับไปยัง Requirement เพื่อให้ตรวจสอบความครอบคลุมได้
• Lab: สร้างชุด Test Scenario จาก Use Case ของระบบตนเอง

Section 10: การตรวจทานคุณภาพงานออกแบบ

• จุดที่ AI มักพลาดในงานออกแบบระบบและวิธีตรวจจับ
• การตรวจความสอดคล้องระหว่าง Requirement, Use Case, Data Model และ API
• การใช้ AI เป็นผู้ตรวจทานอีกชั้นด้วยการให้ตั้งคำถามกลับแทนการให้คำตอบ
• การจัดการเมื่อความต้องการเปลี่ยนและต้องแก้เอกสารทั้งชุด

Section 11: การส่งมอบเอกสารออกแบบระบบ

• องค์ประกอบของเอกสารออกแบบระบบที่ทีมพัฒนานำไปใช้ต่อได้จริง
• การจัดเก็บ Diagram as Code ไว้ใน Git และการทำให้เอกสารอัปเดตตามโค้ด
• การนำเสนองานออกแบบให้ผู้บริหารและผู้ใช้เข้าใจโดยไม่ต้องลงรายละเอียดเทคนิค
• Lab: ประกอบเอกสารออกแบบระบบฉบับสมบูรณ์จากงานที่ทำมาทั้งสองวัน

Section 12: Capstone และการนำไปใช้จริง

• โจทย์: ออกแบบระบบหนึ่งตัวครบทุกขั้นตอนตั้งแต่ Requirement จนถึง Test Scenario
• การนำเสนอเหตุผลของการตัดสินใจออกแบบในแต่ละจุด
• แนวทางนำกระบวนการนี้ไปใช้กับงานจริงและการปรับให้เข้ากับทีม
• Workshop: นำเสนอผลงานและทบทวนการออกแบบร่วมกันกับวิทยากร