มาแชร์ประสบการณ์ SA ให้น้องๆ COMSCI มศว

สำหรับ Blog นี้ เหมือนกับของปีก่อนหน้าครับ มาลองเป็น Public Speaker เรื่อง OOAD ที่อาจารย์ ศุภชัย ที่ มศว โดยจะเน้นการบอกเล่าประสบการณ์จาก Requirement จนได้ Application ต่อทำอย่างไร และเสริมเรื่องอื่นๆด้วยครับ อย่างปีนี้จะเป็นการวางแผน การรับมือ Cyber Security Attack ในมุมน้องจบใหม่มีส่วนอย่างไรครับ

Finding Real Pain Point

ส่วนนี้รูปแบบการนำเสนอเป็นวงกลม จุด 2 จุด Problem -> Solution ระหว่างทางเราต้องแตกปัญหาย่อยๆ ซึ่งเราต้องเข้าใจ Business Domain ต้อง ถ้าตาม DDD จะเป็นพวกภาษาถิ่น Ubiquitous Language ซึ่งการจะได้ Pain ซึ่งเป็นที่มาของปัญหา นอกจาก Business แล้ว Soft Skill จำเป็นเหมือนกัน เรื่องคน ใช่ครับ

จากให้สรุปได้เอกสาร SRS ออก โดยต้องละเอียดระดับนึง สิ่งที่สำคัญ Acceptance Criteria ที่ต้องชัดเจน และการมีส่วนร่วมของ User เพื่อให้ได้ Workflow ตกลงร่วมกัน และ UI/UX อาจจะใช้ Figma หรือ ให้ Dev ทำ Code Mock ให้และเครื่องมืออื่นๆอย่าง DDD / C4 Diagram / Use-Case จริงๆ แผนภาพอะไรก็ได้นะ ถ้าเข้าใจทุกฝ่ายก็พอ และจัดกลุ่ม Requirement หาความสัมพันธ์

นอกจากนี้ส่วน Business Requirement ยังมีส่วน Quality Attribute ที่เราลองสอบถาม หรือ ดูจากเอกสารอื่น เช่น TOR สัญญา หรือ มาตรฐานกลาง เพื่อจะได้เอามากำหนด System / Software Architecture

Selecting System / Software Architecture

ส่วนนี้ผมได้แนะนำไปว่า เราจะเลือกข้อมูลจากตรงนี้ได้ หลังๆ Quality Attribute ที่เราต้องสกัด ผมว่าเก็บมันง่ายไป จริงบางอย่างมันต้องงัดปากลูกค้าออกมาเลย 555 เพื่อที่จะเลือก Architecture ที่เหมาะสมได้ โดยผมแนะนำ

• Sync / Async
• MVC
• N-Tier > Layer Architecture / Clean Architecture
• Monolith vs Microservices

สำหรับส่วนนี้จะมีแผนภาพอย่าง Deployment Diagram ให้เห็นว่าอะไรอยู่ที่ไหน ถ้าบน Cloud เอา Service มาใส่ได้เลย C4 Diagram และมาหาดูว่าอะไรที่ Common และกำหนด Pattern ได้ เช่น Logging / API Message ครับ

สุดท้ายมาทำบันทึกลงเอกสาร ADR ครับ

Development + Test 

เข้างานแต่ละคนได้รับมอบหมายกันมาว่า ระบบ 1 อันมันทำคนเดียวไม่ได้แน่ๆ ตรงนี้การ Dev จะมีแบ่ง Requirement ย่อยลง หาความสัมพันธ์ และได้ออกมาเป็น

• Protocol โดยอาจจะเป็น
  - EndPoint อย่าง json อย่าง REST หรือ Strong หน่อยก็ GRPC
  - TextFile csv / json
  - Table ต้องมาตรงลง Schema
• การบันทึกความเข้าใจ
  - Activity Diagram
  - Sequence Diagram ใช้เยอะ
  - Class Diagram เน้นความสัมพันธ์ของ Class ส่วนพวก Attribute / Method ไปไล่ Code เอง
  - ER Diagram + Data Dictionary
• ตอน Code มีหลายแบบ Code > Test หรือ จะแบบ TDD นอกจากนี้แนะนำเทคนิคอย่างพวก Cohesion VS Coupling / Design Pattern / KISS / Yangi หรือ พวก Code Smell โดยพวกนี้ ถ้าตกลงก่อนทำงานได้จะดีมาก แต่ถ้ามันหลุดมาแล้ว มีแนะนำ Flow ใน Source Control อย่าง GitLab มีตัว merge request ตรวจสอบก่อนได้คร้บ
• สุดท้ายงานมันเรื่องซับซ้อน เราต้องมี Automation มาช่วย
  - Automate Test แนะนำการดู Coverage จะได้เห็นว่า Test เราช่วยเพิ่ม Quality ไหม หรือควรทำที่จุดอื่นๆ
  - CI/CD มันต้องตั้งเป็นอันแรกๆ เพื่อให้เราได้ Feedback ที่เร็วครับ
• Test มีส่วน Internal และ ลูกค้าทดสอบ User Acceptance Test ถ้าช่วย Requirement กำหนดได้ชัดตรงนี้จะวัดได้ง่ายครับ

นอกจากนี้มีเล่าการใช้พวก AI มาช่วยเขียน Code อย่างตัว Claude AI (ไปดูว่าไม่มี Version Dev 55 จริงมันมี) / GitHub Copilot

Go live > Transfer MA Team

หลังจากลูกค้าทดสอบเสร็จเข้าสู่ช่วง Go live และ โดยสิ่งที่เราควรทำมีการส่งต่อข้อมูลให้ทีมที่มารับช่วงต่อ

• มีเอกสาร และ KM
• ประเด็นที่คงค้าง
• Observability (Log / Trace / Metric) จริงเก็บมา และออกแบบตั้งแต่ช่วง Design > Development + Test ต้องมาแนะนำว่าต้องดูอย่างไร เป็นต้นครับ

Bonus

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

• Backup Your Service (ตามกฏ 3 2 1) และต้องมาดู Risk & Priority จากนั้นเลือกอะไรต้อง Backup หรือ ทำ Site สำรอง (DR Site) และความถี่ของแต่ละอันครับ
• Network Segmentation + Firewall + EDR
• Update Patch / Hardening / Schedule VA Scan
• Eliminate Shadow IT 
• Least Privilege
• Incident and Response Plan
• BCP / DR Site 
• Security Awareness

รวมถึงเรื่องการวางแผนการเงิน / การเขียน Blog (Second Brain) และไป พวก Tech Meetup Update ความรู้ครับ

Resource : Slide