สวมบท Software Architect กันเถอะ : Quality Attribute คือ?

ช่วงหนังเริ่มได้ยินปัญหาเรื่องคุณภาพของซอฟต์แวร์กันบ่อย เลยอยากเขียนแลกเปลี่ยนข้อมูลกันว่าสิ่งที่เราเรียกกันว่า Quality Attribute นั้นมีอะไรบ้าง และแต่ละ Attribute มีความสำคัญกับเราอย่างไร ทำไมบาง Project ใช้เวลาทำตั้งนาน เกินเวลา งบบานปลาย เสร็จแล้ว User กลับไม่ใช้ หรือใช้ไปบ่นไป เรามาหาคำตอบกัน

**เนื้อหาจะค่อนข้างเกี่ยวกับงานสถาปัตยกรรมซอฟต์แวร์ (Software Architecture) และศัพท์เทคนิคภาษาอังกฤษจะเยอะหน่อยนะครับ ใครที่ไม่ค่อยคุ้นเคยกับวงการนี้ก็เริ่มคุ้นเคยได้แล้ว หรือคุณจะเดินหนีมันไปก็ได้ แต่บอกไว้เลยยังไงก็หนีไม่พ้น ^_^

 

อะไรคือ Quality Attribute

ในงานพัฒนาซอฟต์แวร์ มักต้องมีการเก็บความต้องการของผู้ใช้ (Requirement Gathering) ซึ่งมักจะเจอกับความต้องการอยู่ 2 แบบใหญ่ๆคือ
Functional Requirement  (FR):   คือความต้องการในตัวระบบงาน เช่นโปรแกรมมีกี่หน้าจอ กี่ฟอร์ม กี่รายงาน การตรวจสอบข้อมูลเป็นอย่างไร ต้องเช็คกับค่าตรงไหน ใช้สูตรอะไร คลิกตรงนี้แล้วไปไหนต่อ เป็นต้น
Non-Functional Requirement (NFR): คือความต้องการที่นอกเหนือจากฟังก์ชันงาน (ส่วนใหญ๋จะเป็นในแง่ความรู้สึก) เช่น ความปลอดภัยของระบบ ความง่ายในการใช้งาน ความเร็วในการออกรายงาน การอนุญาติให้ปรับแต่งได้ง่าย ระบบสามารถเปลี่ยนภาษารองรับ AEC  ระบบต้องทดสอบได้ง่าย รองรับการขยายตัวของผู้ใช้จำนวนมากได้

เห็นไหมครับ FR กับ NFR นี่เหมือนคนละเรื่องเดียวกันเลย แต่จริงๆมันก็คือซอฟต์แวร์หรือระบบเดียวกัน ตัวอย่างเช่น ซอฟต์แวร์ที่ถึงมีประสิทธิภาพดี (+NFR) แต่ฟังก์ชันไม่รองรับตามความต้องการของผู้ใช้ (-FR) ก็ไปไม่รอด , ส่วนตรงข้ามคือซอฟต์แวร์ที่ฟังก์ชันครบ (+FR) แต่ประสิทธิภาพแย่ (-NFR) ก็ไม่มีใครอยากใช้เหมือนกัน

ที่เล่ามาตอนต้นเพื่อที่อยากจะบอกว่า Software Quality Attribute เนี้ยมันก็คือ Non-Functional Requirements นั้นเองแถมจำไม่ยากด้วยเพราะส่วนใหญ่จะลงท้ายด้วย -lity ทั้งนั้นเลยลองดูด้านล่าง

  • Security            ความปลอดภัย เช่นระบบล๊อกอิน การกำหนดสิทธิว่าสามารถเข้าถึงโมดูลไหนได้บ้าง การเข้ารหัส ความคงสภาพของข้อมูล การรักษาความลับของข้อมูล
  • Availability      ความพร้อมใช้งาน เช่น การทำ HA (Hi-Availability)  ระบบที่ทำงาน 7 x 24 ไม่มีวันดับ, การทำ Redundant, วิธีการ Recover ระบบหลังจากระบบล่ม
  • Scalability     การรองรับการขยายระบบในอนาคต เช่น การรองรับการเพิ่มของผู้ใช้ที่ใช้งานพร้อมๆกัน (concurrent user) จากหลักพัน เป็นหลักล้าน หรือร้อยล้าน
  • Modifiability    การรองรับการแก้ไข ปรับแต่งในอนาคต เช่นการเปลี่ยนภาษาตาม Locale ของผู้ใช้
  • Testability         การรองรับกานทดสอบ เช่นเมื่อมีการปรับเปลี่ยนความต้องการ และแก้ไขเสร็จระบบต้องทดสอบได้อย่างรวดเร็ว รองรับการทำ Unit Test
  • Portability         ย้ายระบบได้ง่าย เช่นระบบที่ทำงานบน Windows สามารถย้ายไปทำงานบน Linux หรือ Mobile App ที่เขียนครั้งเดียวทำงานได้ทั้ง Android และ iOS
  • Reliability          ความสเถียร เช่น ระบบต้องตอบสนองทุกคำร้องขอโดยไม่ผิดพลาด ไม่ใช่ส่งไป 100 request ทำเสร็จแค่ 80
  • Tractability       การตรวจสอบย้อนกลับ เช่น กรณีพบข้อผิดพลาดที่หน้าโปรแกรม ต้องสามารถตรวจย้อนกลับไปถึง เอกสาร Program spec, Requirement รวมถึงต้องรู้ด้วยว่าใครเป็นคนเขียนโปรแกรมหน้านี้
  • Interopability    การเชื่อมต่อกับระบบอื่น เช่น การเชื่อมต่อกับระบบงานอื่นในองค์กร หรือการเรียกใช้ Service อื่นจากภายนอก อย่างการต่อกับ Social API, Youtube API, Google Map API
  • Performance      ประสิทธิภาพ เช่น ระบบต้องตอบสนองด้วยความเร็วที่เท่าเดิมตลอด ไม่ใช่พอผู้ใช้ใช้งานพร้อมกันเยอะๆ จากเดิมที่แสดผลภายใน 0.001 วินาที กลับต้องรอ 10 วนาที
  • Maintainability      การดูแลรักษาง่าน เช่นระบบต้องการเปลี่ยนฐานข้อมูลใหม่ จะแค่เปลี่ยนการตั้งค่า หรือต้องรื้อพัฒนาใหม่หมด
  • Usability             ใช้งานง่าย เช่น ระบบที่ผู้ใช้สามารถใช้ได้โดยใช้เวลาในการฝึกอบรมการใช้งานน้อย หรือกรณีศึกษาของ iPhone ที่แทบจะเป็น Zero-Training เนื่องจากได้เครื่องมาก็ใช้ได้เลยแทบไม่ต้องเรียนรู้ใหม่

ที่ลิสต์มาให้ดูเป็นเพียงแค่บางส่วน จุดสังเกิตคือส่วนใหญ่การวัดคุณภาพของ Attribute แต่ละตัวมักจะวัดในแง่มุมของเวลา เป็นส่วนใหญ่ เช่นการวัด Down-Time ของ Avialability และ Scalability  การวัด response time ของ Perormance การวัด training time ของ Usablity ซึ่งหากไม่มีตัววัดพวกนี้ (Metric) เราจะไม่สามารถแบ่งแยกได้เลยว่าซอฟต์แวร์ตัวไหนมีคุณภาพมากหรือน้อย

 

แต่ละงาน (Domain) ให้ความสำคัญกับแต่ละ Attribute ไม่เหมือนกัน

ในแต่ละระบบ หรือแต่ละองค์กรจะให้ความสำคัญกับ Quality Attribute แตกต่างกันขึ้นอยู่กับประเภทของธุรกิจยกตัวอย่างเช่น
** ผมอยากให้ผู้อ่านจินตนาการตามไปด้วย ถ้าอยากดูเฉลยให้ Highlight ในกล่อง [ … ] เพื่อดูคำตอบ **

  • หน่วยงานกลาโหมต้องการพัฒนาซอฟต์แวร์เพื่อใช้ในงานความมั่นคง อันนี้คงตอบง่าย ตัวแรกที่ลอยมาเลยคือ [Security] ตัวอื่นๆอาจจะถือเป็นเรื่องรองลงมา
  • บริษัทต้องการพัฒนา Mobile App ที่รองรับทั้ง iOS, Android, และ Windows Phone  ให้กับผู้ใช้ทั่วไปอันนี้ก็ง่ายเหมือนกันคือ [Portability] รองลงมาคือ [Usability] และ [Security]
  • หน่วยงานรัฐต้องการพัฒนาระบบเพื่อเชื่อมต่อแต่ละกระทรวง ทบวง กรม ให้สามารถแลกเปลี่ยนข้อมูลกันได้ อันนี้น่าจะตอบได้นะครับคือ [Interopability]
  • ธนาคารต้องการพัฒนาระบบสำหรับทำรายการ ฝาก ถอน โอน เปิดบัญชี โดยมีสาขาจำนวนมากกระจายอยู่ทั่วประเทศ สิ่งที่ต้องการคือ [Availability] ,[Performance] , [Reliability], [Usability]
  • บริษัท ABC Startup น้องใหม่ต้องการพัฒนาระบบ Chat รุ่นใหม่เพื่อเขี่ย Line ให้พ้นจากตลาด ดูเวอร์ไปนิด แต่สิ่งที่พวกเค้าต้องคำนึงถึงเป็นอย่างแรกคือ [Scaleability], [Usability] …

สิ่งที่ผมกำลังจะสื่อให้เห็นคือแต่ละระบบ แต่ละองค์กรมันมีความเฉพาะของมันความต้องการด้านคุณภาพก็จะปรับเปลี่ยนไปตามบริบทเหล่านั้น ซึ่งแม้แต่ระบบงานลักษณะเดียวกันบ้างครั้งความต้องการด้าน Quality ก็สามารถแตกต่างกันได้

 

ความคาดหวังที่แตกต่างความต้องการย่อมแตกต่าง

จากหัวข้อก่อนหน้านี้ จะเห็นว่า Quality Attribute เป็นปัจจัยที่สำคัญที่ทำให้โครงการซอฟต์แวร์จะไปได้สวย หรือล่มไม่เป็นท่า ได้เลยทีเดียว ซึ่งเมื่อเรามาดูในงานพัฒนาซอฟต์แวร์ ย่มต้องเกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียมากมาย (Stake Holder) และแต่ละคนก็มีความคาดหวังที่แตกต่างกันซะด้วย ได้ปวดหัวกันละงานนี้ ลองดูตัวอย่างด้านล่าง

ความคาดหวังของผู้ใช้ (End User’s View)

ของฝั่งผู้ใช้จะต้องการเกี่ยวกับความรู้สึกเป็นส่วนใหญ่ คือ

  • ระบบที่ทำงานได้เร็ว สั่งปุ้บได้ปั้บ (Performance)
  • สามารถเข้าใช้งานได้ตลอดเวลาไม่มีการล่ม (Availability) เช่นระบบสำหรับเทรดหุ้นนี่ถ้าล่มคิดค่าเสียหายกันเป็นวินาทีเลยครับ
  • ระบบจะต้องใช้งานง่าย (Usability) ไม่ใช่อะไรก็ต้องโทรหา Support ให้ช่วยทำโน่นทำนี่ให้ตลอด ผู้ใช้เค้าก็อยากมีอารมณ์ของการได้ควบคุมระบบด้วยตัวเองบ้าง
  • ระบบต้องมีความปลอดภัยสูง (Security) ไม่ใช่ว่าพนักงานสามารถเข้าดูข้อมูลเงินเดือนที่มีแต่ผู้จัดการเท่านั้นที่ดูได้

ความคาดหวังของธุรกิจ (ฺBusiness Community View)

ส่วนของภาคธุรกิจความคาดหวังส่วนใหญ่จะเกี่ยวกับเวลาและเรื่องเงินๆทองๆ คือ

  • หลังจากคิดผลิตภัณฑ์ได้แล้วต้องสามารถนำเสนอออกสู่ตลาดได้ทันที (Time to Market) เล่นบริษัทประกันฝ่ายการตลาดคิดแบบประกันแบบใหม่ได้แต่พอไปถามทางไอทีบอกต้องปรับเปลี่ยนโปรแกรมให้รองรับก่อน กว่าจะส่ง change request กว่าจะแก้ไขกว่าจะทดสอบรวบๆ 2 เดือน ถ้าบริษัทอื่นเค้า Time to Market สั้นกว่าเค้าก็เอาลูกค้าไปหมด
  • ระบบที่พัฒนาต้องอยู่ในงบประมาณที่ตั้งไว้ และคุ้มค่าในการลงทุน (Cost and Benefits)
  • เวลาในการพัฒนาต้องสั้นส่งมอบงานไว (Project Life Time)
  • สามารถปรับเปลี่ยนได้ตามกลุ่มเป้าหมายด้านการตลาด (Targeted Market)
  • สามารถใช้งานร่วมกับระบบเดิมได้ (Integration with Legacy System)
  • รองรับการสำรองข้อมูลและดึงข้อมูลกลับ (Roll Back Schedule)

ความคาดหวังของทีมพัฒนา (Developer’s View)

ส่วนของทีมพัฒนาจะเน้นที่การลดภาระงานให้น้อยที่สุด เพราะไม่อยากเหนื่อยบ่อยๆ คือ

  • ระบบต้องปรับแต่งแก้ไขได้ง่าย (Maintainability) เช่นการจัดการโค้ด การเพิ่ม/ลดฟังก์ชันบางอย่าง
  • ระบบต้องสามารถย้ายไปทำงานกับแพลตฟอร์มอื่นได้ (Portability) เช่นจากบน Windows ย้ายไปติดตั้งบน Linux เป็นต้น
  • ระบบต้องสามารถนำสิ่งที่พัฒนาก่อนหน้านี้กลับมาใช้ใหม่ได้ (Reusability) เช่นหลักการเขียน Software Component เป็นต้น
  • ระบบจะต้องสามารถทดสอบได้ (Testability) เช่นการรองรับ automate test  เมื่อเกิดการเปลี่ยนแปลงต้องสามารถทดสอบแบบแยกจุด (Unit Test)และแบบร่วมกัน (System Integration Test)ได้ โดยใช้เวลาในการทดสอบให้น้อยที่สุดและครบตามขอบเขตการทดสอบ เพื่อรับประกันความน่าเชื่อถือของระบบ

 

บทสรุป:

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

AjBee.Me : ความรู้ดีๆ มีไว้แบ่งปัน ถ้าเห็นว่าดีก็ช่วยกันแชร์ได้ครับ ^_^