Architectural Requirement Context

ArchReqContext

สมัยนี้มีความต้องการเพิ่มจากแต่ก่อนหลายประเภท ประเภทหนึ่งที่เริ่มได้ยินกันบ่อยขึ้นคือ ‘Architectural Requirement’ ซึ่งในบทความนี้ขอนำเสนอในมุมบริบทสำหรับความต้องการที่มีผลต่อการออกแบบและสร้างสถาปัตยกรรมซอฟต์แวร์ และมีผลต่อซอฟต์แวร์โดยรวม

สำหรับคำว่า ‘Architectural Requirement’ หมายถึง ความต้องการสำหรับการออกแบบและสร้างสถาปัตยกรรมซอฟต์แวร์ ซึ่งจริงๆ มันก็คือ non-functional requirement หรือ quality attribute นั่นเอง แต่เนื่องจากความต้องการประเภทนี้มีความสำคัญมากๆ ต่องานสถาปัตยกรรมนั่นเอง จึงมีคนคิดความต้องการประเภทใหม่แล้วตั้งชื่อว่า ‘Architectural Requirement’ ให้มันชัดเจนไปเลยนั่นเอง

สำหรับบทความนี้มีรายละเอียดหลายประเด็น ขอให้ภาพรวมเพื่อให้เข้าใจง่ายๆ ไว้ดังนี้ครับ: เมื่อเริ่มโครงการ เราต้องวิเคราะห์ปัจจัยภายนอก แล้วดูว่า stakeholder มีความกังวลต่อเรื่องใดบ้าง พวกเขาต้องการอะไร อยากให้มีระบบไอทีอะไรไปช่วย อยากให้ระบบไอทีทำอะไรได้บ้าง เมื่อเราเข้าใจภาพรวมแล้ว ก็เก็บรวบรวมความต้องการ โดยเฉพาะ functional requirement หรือ use case และ non-functional requirement หรือ quality attribute แล้วอธิบายเป็น quality scenario ความต้องการใดที่วิเคราะห์แล้วเข้าใจแล้วรีบเอาไปเขียน test case ไม่ว่าด้าน functional test case และ non-functional test case จากนั้นรีบไปหาโซลูชั่น โซลูชั่นที่ได้ก็ต้องวิเคราะห์ประโยชน์ว่าคุ้มไหมดีไหม แล้วรีบออกแบบและพัฒนาระบบ…ประมาณนี้ครับ รูปข้างบนเป็นการอธิบายความสัมพันธ์ระหว่างประเด็นสำคัญต่างๆ อ้อ…ในงานสถาปัตยกรรมซอฟต์แวร์เน้นโซลูชั่นด้านกลไกการทำงานภายใน (architectural mechanism) มากกว่าฟังก์ชั่นนะครับ

สำหรับปัจจัยที่ควรพิจารณาต่อการระบุและวิเคราะห์ความต้องการ ซึ่งมีผล (impact) ต่อโครงการ เช่น

  • Architecture Constraint คือ ข้อจำกัดทางสถาปัตยกรรม มีหลายด้านเช่น ด้านธุรกิจ, สภาพตลาด/เศรษฐกิจ, เทคโนโลยี, ข้อมูล, องค์กร, งบประมาณ, การบริหาร
  • Architecture Principle คือ หลักการพื้นฐานทางสถาปัตยกรรม มีหลายด้านเช่น ด้านธุรกิจ, เทคโนโลยี, ข้อมูล, ความปลอดภัย, แอพพลิเคชั่น
  • Business Driver คือ ปัจจัยที่มีผลต่อการดำเนินธุรกิจ (เฉพาะ business case ที่สัมพันธ์กับโครงการนี้)
  • Business Capability คือ ความสามารถทางธุรกิจ และรวมถึงความสามารถด้านอื่น
  • Readiness คือ ความพร้อมในด้านต่างๆ เช่น นโยบาย, การบริหาร, งบประมาณ, บุคลากร

ปัจจัยเหล่านี้อาจเรียกเหมารวมๆ ว่า constraint ไปเลยก็ได้ แล้วค่อยไปแยกแยะเป็นประเภทต่างๆ อีกที ซึ่ง constraint คือ สภาวะภายนอก หรือปัจจัยภายนอกที่เป็นข้อจำกัดและเป็นแรงกดดัน ทำให้ stakeholder เกิดความกังวล (concern) เมื่อปัจจัยภายนอกส่งผลต่อความรู้สึกจึงทำให้เกิดความต้องการ ความต้องการในลำดับแรกๆ คือ business goal หรือ business requirement

ขั้นตอนหลักในการวิเคราะห์ความต้องการ (*เอาไปปรับให้เข้ากับงานก่อนนะครับ) คือ

1. ระบุ stakeholder ของโครงการ และระบุ concern ของแต่ละ stakeholder โดยวิเคราะห์แบบ outside-in คือวิเคราะห์จาก constraint ต่างๆ ที่มีผลทำให้ stakeholder กังวล

  • สร้าง matrix ระหว่าง stakeholder concern กับ constraint

2. วิเคราะห์ stakeholder concern แล้วระบุ business goal หรือ ปรับปรุง(refine) business goal หากมีอยู่แล้ว

  • สร้าง matrix ระหว่าง stakeholder concern กับ business goal

3. วิเคราะห์ด้านธุรกิจในมิติต่างๆ เช่น business scenario, business case, SWOT, strategy map  ในระดับ stakeholder concern, business goal คือพื้นที่ด้านแก่นปัญหาของระบบ (problem domain space)

  • สร้าง matrix ระหว่าง business scenario กับ business goal

4. หาแนวทาง (solution) โดยวิเคราะห์หาว่าควรมีระบบ/แอพพลิเคชั่นอะไร และควรมีความสามารถ (feature) อะไร ที่ตอบสนองต่อ business goal และ stakeholder concern ได้ จากนั้นสร้าง ในระดับ feature นี้คือพื้นที่ด้านแนวทางแก้ไขปัญหาของระบบ (solution space)

  • สร้าง matrix ระหว่าง feature กับ business goal

5. วิเคราะห์ feature เพื่อระบุ functional requirement หรือ use case

  • สร้าง matrix ระหว่าง use case กับ feature

6. วิเคราะห์ feature และ business scenario เพื่อระบุ quality scenario ซึ่งหมายถึงสถานการณ์ (ให้มองเป็นช็อตๆ เหมือนช็อตภาพยนตร์ หรือ snap shot) ว่าระบบที่กำลังพัฒนานี้ มีสถานการณ์หรือเหตุการณ์สำคัญใดบ้าง โดยให้คำนึงถึง stakeholder concern และ business goal เป็นจุดยึดเหนี่ยวหรือเป้าหมายสำคัญ

  • สร้าง matrix ระหว่าง quality scenario กับ business scenario, quality scenario กับ business goal แต่หากไม่ได้ทำ business scenario ให้สร้างเฉพาะคู่หลังพอ

7. แต่ละ quality scenario ต้องระบุด้วยว่าสัมพันธ์กับ quality attribute หรือ non-functional requirement ใด

  • สร้าง matrix ระหว่าง quality scenario กับ quality attribute

8. วิเคราะห์ requirements ทั้ง use case และ quality scenario เพื่อระบุ test scenario โดยควรแยกเป็น functional test scenario และ architectural หรือ non-functional test scenario หรือจะเป็น test scenario ที่รวมทั้งด้าน functional และ non-functional เลยก็ได้ แต่ผู้วิเคราะห์ต้องมีทักษะที่ชำนาญพอ และคนคำนึงถึงกระบวนการด้าน testing และคนที่จะ test ด้วย

  • สร้าง matrix ระหว่าง test scenario กับ quality scenario และ test scenario กับ use case

9. วิเคราะห์ test scenario โดยเชื่อมโยงกันให้จำแนกและให้สอดคล้องกับ stakeholder concern, business goal, feature, use case, quality scenario เพื่อระบุ, ออกแบบ และสร้าง test case ต่อไป โดยควรแยกเป็น functional test case และ architectural test case เสมอ ไม่ควรรวมกัน ยกเว้นว่าชำนาญพอ

  • สร้าง matrix ระหว่าง functional test case กับ test scenario และ functional test case กับ use case

10. ทำความเข้าใจ use case ที่วิเคราะห์แล้ว และ functional test case เพื่อวิเคราะห์และออกแบบระบบในส่วน system functional หรือ system functionality  โดยในขณะเดียวกันก็ทำความเข้าใจ quality scenario ที่วิเคราะห์แล้ว และ architectural test case เพื่อวิเคราะห์และหาแนวทาง (architectural strategy)

  • สร้าง matrix ระหว่าง architectural test case กับ test scenario และกับ quality scenario

11. สำหรับ architectural strategy (หรือเรียกว่า architectural tactic หมายถึงกลวิธีทางสถาปัตยกรรม) ควรระบุ architectural pattern, architectural style ที่ใช้ด้วย ซึ่งจริงๆ ควรระบุ design pattern ด้วย เพราะ design pattern ใช้บ่อย

12. โดย architectural strategy ต้องระบุด้วยว่ามีประโยชน์ (utility) ต่อ quality scenario ใดบ้าง ครอบคลุมแค่ไหน จากนั้นก็ประเมินสถาปัตยกรรม (architecture evaluation)

  • สร้าง matrix ระหว่าง architectural strategy กับ quality scenario

13. นำ architectural strategy ที่ผ่านการประเมินเบื้องต้นมาวิเคราะห์, ออกแบบ และสร้าง architectural mechanism (กลไกทางสถาปัตยกรรม) ซึ่งต้องระบุด้วยว่าสนับสนุน system functionality ใดบ้าง ในทางกลับกันคือ มี system functionality ใดและมาเรียกใช้ (call) architectural mechanism ใดบ้าง

14. สร้าง matrix ระหว่าง

  • architectural strategy กับ architectural mechanism
  • architectural mechanism กับ architectural mechanism
  • architectural mechanism กับ system functionality
  • system functionality กับ system functionality

 

สำหรับ matrix คืออะไร? สามารถเข้าไปอ่านได้ในบทความในหมวดนี้ครับ -> Requirement Attribute, Traceability, Matrix

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

 

ไว้จะเขียนบทความเกี่ยวกับปัจจัยภายนอก (Architecture Constraint) กันแบบละเอียดๆ อีกทีนะครับ เพราะสำคัญมากๆ ทั้งกับการพัฒนาซอฟต์แวร์ และการบริหารโครงการ

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s