Quality Attribute (Non-Functional Requirement)

NFR_QA

Quality Attribute คือ คุณสมบัติเชิงคุณภาพของสิ่งต่างๆ ภายในระบบที่มีการทำงาน เช่น สถาปัตยกรรมระบบ โมดูล อ็อบเจ็คต์ หน้าจอ เป็นต้น และรวมถึงคุณภาพของระบบและระหว่างระบบภายในบริบทเดียวกัน เนื่องจากสิ่งต่างๆ เหล่านี้ต้องมีการประมวลผล มี input และมี output เกิดขึ้น การจะให้ทำงานได้มีคุณภาพที่ดีจึงมีการกำหนดคุณสมบัติเชิงคุณภาพเอาไว้ โดยควรมีคุณภาพอะไรบ้างก็ขึ้นกับบริบทของระบบนั้นๆ ว่า stakeholder ต้องการระบบที่มีศักยภาพแค่ไหน

FunctionMechanismQA

การกำหนด Quality Attribute ได้มาจากการเก็บรวบรวมความต้องการประเภท Non-Functional Requirement โดยเจ้า Quality Attribute เองก็ยังแบ่งออกได้เป็น 3 ประเภท ได้แก่

  • System Quality คือ คุณภาพระบบ มีหลักๆ อยู่แค่ 6 ตัว ได้แก่ Availability, Modifiability, Performance, Security, Testability และ Usability ซึ่งเจ้า System Quality นี่ล่ะที่เราๆ มักเรียกอีกอย่างว่า ‘Non-Functional Requirement’ นั่นเอง
  • Business Quality คือ คุณภาพในเชิงธุรกิจที่ระบบได้สนองต่อธุรกิจของ stakeholder มีหลายตัว มักเป็นศัพท์ธุรกิจ อาทิ Increase Net Profit, Increase Competitiveness, Short Time to Market, Reduce Paper Work เป็นต้น ถ้าสังเกตให้ดี ก็จะร้องอ๋อ…ว่ามันก็คือ Business Goal นั่นเอง แต่ต่างๆ เล็กน้อยที่ขอบเขตและ Level of Abstraction เพราะ Business Goal เป็นการมองภาพรวมของทั้งระบบหรือทั้งโครงการ แต่ Business Quality สามารถใช้มองในระดับที่ลึกในรายละเอียดกว่าได้ เช่น Business Quality ของ Domain Layer, ของโมดูล Report Manager, ของกลไก Transaction Management, ของสถาปัตยกรรมระบบ เป็นต้น
  • Architecture Quality คือ คุณภาพของสถาปัตยกรรมระบบ ไม่ได้มองที่การทำงานแบบ System Quality แต่มองที่ประโยชน์และการนำไปใช้ มีไม่มากนัก อาทิ Conceptual Integrity, Buildability, Correctness and Completeness เป็นต้น

เราจะมาโฟกัสกันที่ System Quality หรือ Non-Functional Requirement (NFR) เป็นหลักในบทความนี้ จากนี้จะขอใช้ตัวย่อว่า ‘NFR’ แล้วกัน สำหรับการเก็บรวบรวม NFR นั้นไม่ง่ายนัก เนื่องจากเจ้า NFR เป็นความต้องการที่ ‘หิน’ เอาเรื่อง เพราะหนักในเรื่องเทคนิคมากๆ มีศัพท์เทคนิคเยอะแยะ แต่ละคำแต่ละความหมายก็ยากที่จะเข้าใจได้ง่ายๆ อุปสรรคขั้นแรกที่มักพบกันได้บ่อยก็คือช่วงการ ‘ถาม’! เพราะ NFR มันตั้งคำถามยาก เพราะจะถาม Stakeholder ยังไงดีที่จะไม่หลุดพูดศัพท์เทคนิคปวดหัวมากมายออกไป หากยิ่งพ่นศัพท์เทคนิคยากๆ ออกไป อาจทำให้ Stakeholder ออกอาการเบลอ งง และหนักสุดที่ต้องเจอแน่ๆ คือ เราต้องเสียเวลาอธิบายคำศัพท์ให้เขาฟัง ดังนั้นผู้ที่รับผิดชอบเจ้า NFR นี้จึงต้องมีทักษะอันเยี่ยมยอดทั้งด้านเทคนิคและการสื่อสาร โดยเฉพาะต้องมีภาษาพูดและภาษาเขียนที่ดี เพื่อสื่อสารให้ผู้อื่นเข้าใจได้ง่าย

การถามเกี่ยวกับ NFR ไม่ใช่อยู่ๆ ไปถาม stakeholder ว่าอยากให้ระบบมีคุณภาพอะไรบ้าง? อยากให้คุณภาพด้าน Availability อย่างไร? อยากให้มีคุณภาพด้าน Performance แค่ไหน? อยากให้มีคุณภาพด้าน Modifiability แบบใด? อยาก…. แค่นี้ Stakeholder ก็มึนแล้ว แล้วเราก็มักจะได้ NFR มาในแบบ ‘เมฆๆ’ คลุมเครือและกว้างเป็นทะเล

การระบุ NFR จึงมักอธิบายออกมาด้วยการบรรยายเป็นเรื่องราว ถึงสถานการณ์สำคัญขณะที่ระบบกำลังทำงาน (ต้องจินตนาการไปถึงอนาคตหน่อย) ที่ Stakeholder มีความกังวล (Concern) มาก โดยเรียกสถานการณ์สำคัญว่า ‘Scenario’ หรือเรียกเต็มๆ ว่า ‘Quality Scenario’ แนะนำว่าให้เรียกแบบเต็ม เพราะถ้าใช้คำว่า Scenario เฉยๆ มันดูกว้างไป เผื่อสื่อสารกับผู้อื่น อาจเข้าใจสับสนได้ เพราะในงานไอทีมี Scenario หลายประเภท เช่น Business Scenario, Test Scenario, Use Case Scenario เป็นต้น องค์ประกอบหลักๆ ของ Quality Scenario ประกอบด้วย

  • Stimulus คือ สิ่งเร้าหรือสิ่งกระตุ้น ในทางไอทีอาจคุ้นกับคำว่า ‘Trigger Event’ ที่ทำให้สถานการณ์สำคัญนั้นๆ เกิดขึ้น (ไม่มีอะไรในโลกเกิดขึ้นได้ด้วยตัวมันเอง เมื่อมีสิ่งหนึ่งเกิดขึ้น สิ่งอื่นจึงเกิดขึ้นเป็นลำดับตามๆ กันมา) ให้นึกถึง Storyboard หรือ Snapshot เช่น ระบบประมวลผลเพราะผู้ใช้ submit transaction
  • Source of Stimulus คือ แหล่งที่มาของสิ่งเร้า หรือตัวที่ก่อให้สิ่งเร้ามันเกิดขึ้นมา จะเป็นคนหรืออุปกรณ์ก็ได้
  • Artifact คือ สิ่งต่างๆ ที่เกี่ยวข้องมีผลต่อสถานการณ์สำคัญนั้นๆ เป็นอะไรก็ได้ จะระบบ โมดูล ฮาร์ดแวร์ ทรานแซกชั่น เน็ตเวิร์ก เอกสาร เป็นต้น เจ้า Artifact นี่กำหนดยาก ถ้าไม่แม่นในคุณภาพนั้นๆ จริงๆ จะนึกออกยาก และจะทำให้รวบรวมได้ไม่สมบูรณ์ครอบคลุม หรืออาจคลาดเคลื่อนได้
  • Environment คือ สภาพแวดล้อมขณะระบบกำลังทำงาน เช่น Degraded Mode, Normal Mode เป็นต้น
  • Response คือ การตอบสนองของระบบ เมื่อสิ่งเร้าเกิดขึ้น ดังนั้น Response จะสัมพันธ์กันกับ Stimulus
  • Response Measure คือ ตัววัดการตอบสนองของระบบ หรือเรียกว่าตัวชี้วัดก็ได้ เพราะคุณภาพใดๆ ต้องมีตัวชี้วัดเสมอ ซึ่งจะแตกต่างกันไปตามแต่ละคุณภาพ

สำหรับ stimulus กับ source of stimulus ลองศึกษาทางพุทธดูก็ได้ครับในเรื่อง ปฏิจจสมุปบาท และ อิทัปปัจจยตา จะช่วยให้เข้าใจลึกซึ้งขึ้นเยอะเลย หรือ ศึกษา เซน ก็ได้ครับ

สำหรับ response measure เป็นสิ่งสำคัญมากสำหรับการอธิบาย NFR หรือ Quality Attribute เนื่องจากความต้องการที่ดีควรมีตัวชี้วัด ซึ่ง response measure ก็คือตัวชี้วัดคุณภาพด้านนั้นๆ นั่นเอง

เราสามารถใช้ NFR หรือ Quality Attribute เป็นกรอบหรือ influence ให้กับทีมงานเพื่อออกแบบและพัฒนาระบบให้ได้คุณภาพตามที่กำหนด เช่น ดังรูปด้านล่าง

FunctionQuality

ตัวอย่างการกำหนด response measure หรือ ตัวชี้วัด (KPI) 4 ตัว ให้ architect กับ developer ออกแบบและพัฒนาคอมโพเน้นต์ ‘Check Out’

 

System Quality หรือ กล่าวได้ว่า NFR ที่พบได้ในระบบทั่วไปสมัยนี้ได้แก่

  • Availability หมายถึง ความพร้อมของสิ่งนั้นๆ เช่น ระบบพร้อม (ไม่ล่ม)
  • Performance หมายถึง ประสิทธิภาพ โดย performance เป็นคุณภาพที่ขึ้นกับผลิตภัณฑ์ เช่น ระบบไอที ก็สนใจเรื่องความเร็วซึ่งเกิดจากประสิทธิภาพการประมวลผลและการใช้ทรัพยากร
  • Modifiability หมายถึง ความสามารถที่สิ่งนั้นๆ ปรับปรุงแก้ไขได้ง่าย สะดวก มีความยืดหยุ่น มีผลกระทบข้างเคียงน้อย
  • Security หมายถึง ความปลอดภัย
  • Testability หมายถึง ความสามารถในการทดสอบ เช่น โมดูลสำคัญของระบบจะอยู่ลึกลับซับซ้อนแค่ไหนก็ต้องทดสอบได้ และต้องทดสอบด้วยวิธีการที่เหมาะสม
  • Usability หมายถึง การใช้งานที่ง่าย ได้ประโยชน์ สร้างประสบการณ์ที่ดีแก่ผู้ใช้ เป็นมิตรกับผู้ใช้ จึงมักเกี่ยวกับหน้าจอ หรืออินเตอร์เฟส
  • Scalability หมายถึง ความสามารถในการรองรับการขยายตัวของระบบได้ ซึ่งอาจเกิดจากมีปริมาณโหลดที่เพิ่มขึ้น
  • Interoperability หมายถึง ความสามารถในการทำงานร่วมกันได้ระหว่าง โมดูล หรือ ระหว่างระบบ หรือ ระหว่าง คอมโพเน้นต์ เป็นต้น โดยปราศจากข้อจำกัด เช่น ระบบบัญชีเขียนด้วย Java ต้องทำงานร่วมกับระบบการเงินที่เขียนด้วย C#.NET

 

QA_Avail

QA_Mod

QA_Perf

QA_Sec

 

Quality Attribute อื่นๆ

  • Extensibility หมายถึง ความสามารถในการเพิ่มเติมความสามารถ (ฟีจเจอร์) ภายหลังได้ โดยไม่กระทบระบบเดิม
  • Reliability หมายถึง ความน่าเชื่อถือ (การประมวลผล การคำนวณ และความรู้สึก)
  • Portability หมายถึง ทำงานข้ามสภาพแวดล้อมได้ เช่น แพลตฟอร์มเปลี่ยน, database เปลี่ยน
  • Integrability หมายถึง ทำงานติดต่อกับ legacy system หรือ ระบบภายนอกได้
  • Supportability หมายถึง รองรับ…? ได้ (เช่น OS, virtual machine, hardware ….)
  • Customizibility หมายถึง customize ได้ (เช่น หน้าจอ)
  • Safety หมายถึง ความปลอดภัยต่อชีวิตและทรัพย์สิน
  • Maintainability หมายถึง ดูแลจัดการได้

 

สรุป

โดยทั่วไปเรามักได้ยินคำว่า ‘Non-Functional Requirement’ กันมากกว่าคำว่า ‘Quality Attribute’ จริงๆ แล้วมีความหมายแตกต่างกันเล็กน้อยเท่านั้น ถ้าไม่ซีเรียสอะไรมากจะใช้คำว่าอะไรก็ใช้ไปเถอะครับ 🙂 เอาให้คุยกันในทีมรู้เรื่องและเข้าใจกันง่ายก็พอ เพราะทั้ง 2 คำเป็นประเด็นที่เกี่ยวกับคุณภาพ ซึ่งเป็นสิ่งสำคัญมากๆ

การเก็บรวบรวมความต้องการ รวมถึงการวิเคราะห์ และ บริหารความต้องการ จึงควรทำกับความต้องประเภทนี้กันด้วยนะครับ สำคัญมากๆ

ผมพบว่าตลอดในช่วงปี 2550 เป็นต้นมา มีองค์กรในบ้านเราจำนวนมากตื่นตัวและเริ่มให้ความสำคัญกับความต้องการประเภทนี้กันมากขึ้น หันมาทำกันมากขึ้น เพราะทุกคนตระหนักแล้วว่า…คุณภาพระบบสำคัญไม่แพ้ฟังก์ชั่น

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