Architectural Drivers

 

 

 

ArchitectingContext

 

สถาปัตยกรรมคือต้นแบบของการพัฒนาระบบจริง และ เป็นกรอบในการดำเนินการและขับเคลื่อนกระบวนการพัฒนาระบบ

SystemMechanismQA

นอกจากมุ่งเน้นพัฒนาฟังก์ชั่นการทำงานของระบบแล้ว ต้องมุ่งเน้นกลไกการทำงานภายใน และ คุณภาพให้สอดคล้องกัน

 

  • Architectural Drivers หรือ ปัจจัยขับเคลื่อนกระบวนการทาง software architecture ได้จากการเลือก requirement ขึ้นมา (ประมาณ 20% ตามทฤษฏีของ Pareto) จาก requirement ทั้งหมด ทำโดย software architect
  • Architectural Drivers ประกอบด้วย
    • ส่วนหนึ่งจาก Business Goals (business requirements / stakeholder needs)
    • ส่วนหนึ่งจาก Non-Functional Requirements
    • ส่วนหนึ่งจาก Functional Requirements

Architectural Drivers คือตัวขับเคลื่อนสำคัญต่อกระบวนการสร้าง software architecture เปรียบเสมือนกรอบในการสร้าง software architecture

การกำหนด architectural driver ทำได้โดยใช้วิธีการทำ Requirement Measurement โดยทำ Prioritize Use Cases (ใน RUP เรียกแบบนี้) หรือการเรียงลำดับความสำคัญของ functional requirements แต่ในแนวทางของสถาบัน SEI ใช้วิธี ATAM (Architecture Trade-off Analysis Method) และ CBAM (Cost and Benefit Analysis Method) ซึ่งในทางปฏิบัติแล้วมีลักษณะคล้ายกันกับ Prioritize Use Cases  แต่ ATAM และ CBAM มีความละเอียดกว่า และชื่อ ‘Prioritize Use Cases’ ให้ความรู้สึกถึงการเน้นที่ functional requirements เพราะ Use Case หมายถึง functional requirements

พื้นฐานที่สำคัญในการวัดและประเมินเพื่อหา architectural driver คือกฏ 80/20 ของ Pareto ซึ่งเป็นนักคิดชื่อดังชาวอีตาลี มีหลักอยู่ว่า

20 ส่วนใน 100 ส่วน จะส่งผลต่ออีก 80 ส่วนที่เหลือ

หมายถึง หาก 20 ส่วนสามารถทำได้สำเร็จ ก็มีโอกาสทำให้อีก 80 ส่วนที่เหลือสำเร็จด้วยได้ และหาก 20 ส่วนล้มเหลว ก็มีโอกาสทำให้อีก 80 ส่วนที่เหลือล้มเหลวไปด้วยได้

ดังนั้นการบริหารจัดการ requirements จึงต้องวัดและประเมินหาให้ได้ว่า requirements ตัวใดที่อยู่ในส่วน 20 เปอร์เซ็นต์นี้  จากนี้จึงบริหารจัดการอย่างเป็นพิเศษ  เพราะ requirements 20 เปอร์เซ็นต์นี้คือ architectural driver นั่นเอง แสดงว่า architectural driver ก็คือ requirements หลักสำหรับการสร้าง software architecture

software architecture คือส่วนสำคัญของระบบ ประกอบด้วยกลไกและการเชื่อมโยงการทำงานที่สำคัญภายในระบบฯ มีปริมาณเฉลี่ย 20 เปอร์เซ็นต์ของระบบฯ ทั้งหมดเท่านั้น แต่หาก software architecture มีปัญหาก็สามารถส่งผลกระทบต่อส่วนอื่นอีกที่เหลืออีก 80 เปอร์เซ็นของระบบฯ ได้  ส่วนอื่นที่เหลือ 80 เปอร์เซ็นต์คือ requirements ที่ไม่ได้ถูกเลือกให้เป็น architectural ซึ่งประกอบด้วย business goals, non-functional requirements และ functional requirements นั่นเอง

คุณค่าและการทำงานของระบบฯ มิใช่วัดจากการที่ระบบฯ พัฒนาแล้วเสร็จและทำงานได้เท่านั้น เพราะดัชนีชี้วัดความสำเร็จของโครงการพัฒนาซอฟต์แวร์หรือระบบฯ คือ คุณภาพ  สมมติฐานที่มักใช้เป็นเกณฑ์ในการวัดความสำเร็จจากการที่ระบบฯ ทำงานได้ มักมาจากการเน้นที่การจัดการ functional requirements เป็นหลัก แต่ขาดการใส่ใจและให้ความสำคัญด้านคุณภาพ เฉกเช่นในอุตสาหกรรมการผลิตอื่น ๆ มีกัน

คุณค่าและการทำงานของระบบฯ จึงต้องวัดจากคุณภาพของระบบฯ ซึ่งประกอบด้วยคุณภาพที่ represent ด้วย business goals, non-functional requirements และ functional requirements และปัจจัยในการขับเคลื่อนคุณภาพเหล่านี้มาจากการมี software architecture ที่ดี โย software architecture ที่ดีก็มาจาก การจัดการ architecture drivers ที่ดี แล้ว architectural driver ล่ะคืออะไร? ก็มาจากส่วนหนึ่งของ business goals, non-functional requirements และ functional requirements นั่นเอง  นี่จึงเป็นวงจรที่มีการตอบสนองกัน สถาบัน SEI เรียกวงจรนี้ว่า Architecture-Business Cycle (ABC)  ดังนั้นระบบฯ จะมีคุณภาพที่ดีจึงต้องเริ่มจากการบริหารจัดการ requirements ที่ดีเป็นสำคัญ  และการให้น้ำหนักและความสำคัญกับ functional requirements เป็นหลักโดยมองข้ามหรือไม่ใส่ใจในการจัดการ business goals และ non-functional requirements จึงเป็นสิ่งที่ไม่ควรกระทำเด็ดขาด!

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