ช่วงค่ำๆ ได้มีโอกาสเปิดอ่านหนังสือที่ได้รับมาจากตอนไปอบรมเรื่องของ Software Testing Techniques for Improving Software Quality เมื่อเดือน พฤษภาคม 2550 ได้เจอ Concept เรื่องของ Software Quality ที่น่าสนใจ ก็เลยหยิบมาแบ่งปันให้เพื่อนพ้องน้องพี่ชาว welovebug และ tester66 ได้อ่านกันครับ

ตั้งชื่อให้กับเจ้าสามเหลี่ยมนี้ว่า Software Quality Triangle โดยสามเหลี่ยมมีคุณสมบัติดังต่อไปนี้

• สามเหลี่ยมด้านเท่า ที่มีด้านทั้งสามด้านยาวเท่ากัน และมุมภายในแต่ละมุมของรูปสามเหลี่ยมมีขนาดเท่ากันคือ 60°
• มุมที่ 1 ชื่อว่า User Requirements
• มุมที่ 2 ชื่อว่า Requirements Specification
• มุมที่ 3 ชื่อว่า Software
• ความยาวระหว่างมุมทั้ง 3 มุม ชื่อว่า Gap

เราใช้ Software Quality Triangle มาเป็นตัวเล่าเรื่องของคำว่า Software Product Quality โดย แต่ละมุม จะเป็นตัวแทนของมุมมองของ Quality 3 มุมมอง คือ

• User Requirements = User’s View
• Requirements Specification = Manufacturer’s View
• Software = Software Product’s View

Gap ระหว่างมุม แต่ละมุม เป็นตัวแทนของปัจจัยที่จะทำให้ Quality ของทั้ง 3 มุม ห่างออกจากกัน ดังนั้น Concept ง่ายๆ ของเจ้า Software Quality Triangle เราจะทำยังไรเพื่อลด Gap ของแต่ละมุมลงด้วยอัตราส่วนที่เท่าๆ กันทั้ง 3 Gap เพื่อให้ได้รูปสามเหลี่ยมด้านเท่าที่เล็กที่สุดตามรูป

ทางทฤษฎี หมายถึง เราพัฒนา Software ออกมาใกล้เคียงกับ Requirements Specification ที่ถูกออกแบบ ซึ่งก็ใกล้เคียงกับ User Requirements

ทางปฏิบัติ เป็นที่ทราบกันดีว่า ยากมาก ขอย้ำว่า ยากมาก ที่จะทำให้เกิดรูปสามเหลี่ยมด้านเท่าดังกล่าว

ดังนั้นลองมาดูกันว่ามีปัจจัยอะไรบ้างที่ทำให้ไม่สามารถจะลด Gap ระหว่างแต่ละมุมลงมาได้ตามที่อยากให้เป็นไปตามทฤษฏี

User Requirements vs Requirements Specification Gap

คู่ที่ 1: User Requirements เจอกับ Requirements Specification Gap ที่เกิดขึ้นนั้นมาจากเหตุผลแบบง่ายๆ พื้นๆ เลยว่า System Analyst และ/หรือ Software Developer ไม่เข้าใจ User Requirements มากเพียงพอ และลึกซึ้ง ตัวอย่างเช่น

• เข้าใจ Requirements ไปคนละทางกับ User
• Requirements ไม่ชัดเจน คลุมเครือ
• ข้อมูล Requirements ที่มีมีอยู่ในมือ ไม่ใช่ตัวล่าสุด

ซึ่งเป็นปัญหา Classic จริงๆ (ความเห็นส่วนตัว)

อีกมุมหนึ่ง System Analyst และ/หรือ Software Developer เวลาไปพูดคุยกับ User จะพูดด้วยภาษา Technical ทีนี้ก็ไปกันใหญ่เลย พากัน งง ตีความไม่เหมือนกัน สื่อสารกันไม่รู้เรื่อง จบข่าว

ดังนั้นการลด Gap ของ User Requirements กับ Requirements Specification ควรที่จะเลือกใช้วิธี หรือภาษาที่จะใช้ในการสื่อสารกันระหว่างที่พูดคุยเรื่อง Requirements ต่างๆ ระหว่าง Users และ Technical Guys ทั้งหลาย และจะต้องจัดส่งเอกสาร หรือแจ้งให้ทุกๆ คน ที่เกี่ยวข้องกับการพัฒนา Software นั้นๆ รับทราบ เมื่อมีการเปลี่ยนแปลงใดๆ ขึ้นกับ Requirements

Requirements Specification vs Software Gap

ถ้าพูดกันตามตัวอักษรเลยก็บอกได้ว่า Gap ที่เกิดขึ้นระหว่าง Requirements Specification และ Software เกิดขึ้นจาก Software Developer ไม่ coding ตาม Requirement Specification หรือ Solution Design หรือ Technical Specification ที่ถูกออกแบบไว้ ตัวอย่างเช่น

• Technical Specification คลุมเคลือ ไม่ชัดเจน เนื่องจาก User Requirements ไม่ชัดเจน
• Requirements มีการเปลี่ยนแปลงเกิดขึ้น ขณะที่ทำการพัฒนา Software ถูกเพิ่มเข้าไป แต่ไม่เข้าไปแก้ไขตัว Technical Specification
• Software Developer เพิ่ม Functions หรือ Features เข้าไปเอง
• Software Developer ละเลย Requirement บางข้อไป เนื่องจาก หา Solution ไม่ได้

แต่การที่ไม่พัฒนา Software ตาม Specification ที่ถูกออกแบบไว้ บางครั้งก็เป็นผลดี หากว่า Software Developer รู้ว่าการออกแบบนั้นผิด และจะทำให้ Software ที่ถูกพัฒนาออกมาไม่ตรงตามความต้องการของ User ไม่ว่าจะไปรู้มาด้วยกรณีใดๆ

ดังนั้นการลด Gap ระหว่าง Software และ Requirements Specification นั้น ในขั้นตอนการพัฒนา Software จะต้องมีการควบคุม และตรวจสอบกันเองในทีมว่า Software กำลังถูกพัฒนาเป็นไปตามการออกแบบที่วางไว้ และหากมีข้อสงสัยใดๆ จะต้องจัดการหาคำตอบให้ไวที่สุด

แต่หาก Software Developer พัฒนา Software ที่ไม่ตรงตาม User Requirements ออกมาด้วยขั้นตอนการควบคุมที่ดี ก็ไม่ได้ช่วยลด Gap ที่เกิดขึ้นได้ ดังนั้นส่วนที่าำคัญที่สุดคือ การลด Gap ระหว่าง User Requirements กับ Requirements Specification จะดีที่สุด

Software vs User Requirements Gap

พูดกันง่ายๆ เลยว่า Gap ระหว่าง Software กับ User Requirements จะแปรผันตาม Gap ของ

• User Requirements กับ Requirements Specification
• Requirement Specification กับ Software

หาก Gap ของทั้ง2 สั้นเท่าไร Software ที่ถูกพัฒนาออกมาก็จะใกล้เคียงกับความต้องการ และความคาดหวังของ User

หาก Gap ของทั้ง 2 ห่างกัน ทีมพัฒนา Software งานเข้า อย่างแน่นอน เพราะจะต้องทำการแก้ไข Software นั้น จนกว่า User จะพอใจ และยอมรับ ซึ่งจะก่อให้เกิด Cost ตามมาทันที

Software Quality Triangle ในความเป็นจริง

รูปทรงของสามเหลี่ยม Software Quality Triangle จะขึ้นอยู่กับ Gap ทั้ง 3 ด้าน ตามที่ได้อธิบายไปตามข้างต้น เราลองมาดูกันว่าในความเป็นจริงนั้น สามเหลี่ยม Software Quality Triangle ที่มีด้านทั้งสามด้านยาวเท่ากัน และมุมภายในแต่ละมุมของรูปสามเหลี่ยมมีขนาดเท่ากันคือ 60° จะแปรแปลี่ยนไปเป็นรูปทรงใดได้บ้าง

แบบที่ 1

• Poor understanding of requirements
• Corrected during software development
• Software meets user requirements

แบบที่ 2

• Poor understanding of requirements
• Good software development
• Software does not meet user requirements

แบบที่ 3

• Good understanding of requirements
• Poor software development
• Software does not meet user requirements

แบบที่ 4

• Poor understanding of requirements
• Poor software development
• Software does not meet user requirements

สุดท้าย

ทั้ง 4 รูปแบบ เป็นเพียงตัวอย่างของรูปทรงของสามเหลี่ยม Software Quality Triangle ที่มักจะเกิดขึ้น โดยมองมุมของความพึงพอใจของ User ฝากลองนั่งคิดดูเล่นๆ ว่า ณ ปัจจุบัน หรือคิดย้อนกลับไปในอดีต ที่ผ่านมา Software ที่เพื่อนพ้องน้องพี่ได้เข้าไปเกี่ยวข้องในการพัฒนา ตรงกับรูปทรงใดครับ

เอกสารอ้างอิง: Software Testing Techniques for Improving Software Quality