ตัวชี้วัดเชิงวัตถุประสงค์สำหรับคุณภาพซอฟต์แวร์ [ปิด]

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

สิ่งที่ฉันสนใจคือรูปแบบที่ลึกกว่าของคุณภาพที่เกี่ยวข้องกับเครือข่าย (หรือกราฟ) ของประเภทและความสัมพันธ์ระหว่างกันของพวกเขานั่นคือประเภทใดที่อ้างถึงแต่ละประเภทจะมีกลุ่มของการเชื่อมต่อระหว่างกันอย่างชัดเจน สถาปัตยกรรมแบบฉัตรหรือตรงกันข้ามมี 'ball' ขนาดใหญ่ของการอ้างอิงประเภท (รหัส 'เสาหิน') นอกจากนี้ขนาดของแต่ละประเภทและ / หรือวิธีการ (เช่นวัดในปริมาณของรหัสไบต์ Java หรือ. Net IL) ควรให้ข้อบ่งชี้ว่ามีการใช้อัลกอริธึมที่ซับซ้อนขนาดใหญ่เป็นบล็อกก้อนใหญ่ของรหัสแทนที่จะถูกย่อยสลายได้ง่าย ชิ้น

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

ฉันยังสงสัยว่านี่เป็นความคิดที่อันตรายหรือไม่ถ้าหากผู้รับมอบฉันทะที่มีคุณภาพเป็นที่นิยมนั้นความกดดันทางธุรกิจจะทำให้นักพัฒนาต้องติดตามตัวชี้วัดเหล่านี้ด้วยค่าใช้จ่ายของคุณภาพโดยรวม (ด้านคุณภาพของพวกเขา

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

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

นี่คือกฎหมายของผลที่ไม่ตั้งใจ

คุณภาพ - ในขณะที่สำคัญ - เป็นเพียงส่วนเล็ก ๆ ของซอฟต์แวร์ ฟังก์ชั่นและคุณค่าที่สร้างขึ้นโดยซอฟต์แวร์นั้นมีความสำคัญมากกว่าคุณภาพ

ตัวชี้วัดทั้งหมดนำไปสู่กิจกรรมเพื่อเพิ่มประสิทธิภาพตัวชี้วัด ในทางกลับกันมีผลที่คุณอาจไม่ชอบ

ซอฟต์แวร์ซับซ้อนมาก มันยากที่จะเข้าใจว่ามันซับซ้อนแค่ไหน

แม้แต่สิ่งที่ "ชัดเจน" เช่นการครอบคลุมรหัสทดสอบหน่วยสามารถเสียเวลา การทำ 100% อาจต้องมีการสร้างการทดสอบที่ซับซ้อนกว่าการทดสอบรหัสเล็กน้อย การได้รับความคุ้มครอง 100% อาจเกี่ยวข้องกับค่าใช้จ่ายที่ยอมรับไม่ได้ [ทางเลือกสำหรับโค้ดเล็ก ๆ น้อย ๆ ที่ไม่ค่อยได้ใช้คือการทดสอบโดยการตรวจสอบ แต่นั่นไม่เหมาะกับเกมตัวชี้วัด 100%]

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

ฉันยังสงสัยว่านี่เป็นความคิดที่อันตรายหรือไม่ถ้าหากผู้รับมอบฉันทะที่มีคุณภาพเป็นที่นิยมนั้นความกดดันทางธุรกิจจะทำให้นักพัฒนาต้องติดตามตัวชี้วัดเหล่านี้ด้วยค่าใช้จ่ายของคุณภาพโดยรวม (ด้านคุณภาพของพวกเขา

บิงโกและไม่ "ถ้า" เกี่ยวกับมัน สิ่งนี้เรียกว่า "การวัดความผิดปกติ" และได้รับการสังเกตและเขียนหลายครั้งที่โจเอลเขียนบทความเกี่ยวกับมันในปี 2002 โดยอ้างอิงจากหนังสือของศาสตราจารย์ฮาร์วาร์ด

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

สิ่งที่ฉันสนใจคือรูปแบบที่ลึกกว่าของคุณภาพที่เกี่ยวข้องกับเครือข่าย (หรือกราฟ) ของประเภทและความสัมพันธ์ระหว่างกันของพวกเขานั่นคือประเภทใดที่อ้างถึงในแต่ละประเภท สถาปัตยกรรมแบบฉัตรหรือตรงกันข้ามมี 'ball' ขนาดใหญ่ของการอ้างอิงประเภท (รหัส 'เสาหิน')

ฟังก์ชั่นนี้จะเหมือนกับ fan-in และ fan out Fan-in จะนับจำนวนโมดูลที่เรียกโมดูลที่กำหนดและ Fan-out จะนับจำนวนโมดูลที่เรียกใช้โดยโมดูลที่กำหนด สัญญาณเตือนการใช้งานคือโมดูลที่มีพัดลมเข้าขนาดใหญ่และพัดลมขนาดใหญ่เพราะอาจบ่งบอกถึงการออกแบบที่ไม่ดีและเป้าหมายหลักสำหรับการปรับโครงสร้างใหม่หรือออกแบบใหม่

นอกจากนี้ขนาดของแต่ละประเภทและ / หรือวิธีการ (เช่นวัดในปริมาณของรหัสไบต์ Java หรือ. Net IL) ควรให้ข้อบ่งชี้ว่ามีการใช้อัลกอริธึมที่ซับซ้อนขนาดใหญ่เป็นบล็อกก้อนใหญ่ของรหัสแทนที่จะถูกย่อยสลายได้ง่าย ชิ้น

การวัดอย่างง่ายจะเป็นบรรทัดของรหัส คุณสามารถแบ่งมันเป็นบรรทัดรวมของรหัสในโครงการทั้งหมดและบรรทัดของรหัสต่อโมดูล (อาจใช้โมดูลขนาดแตกต่างกัน) คุณสามารถใช้สิ่งนี้เป็นตัวบ่งชี้การเตือนที่ระบุว่าคุณควรตรวจสอบโมดูลเฉพาะ หนังสือเกี่ยวกับการวัดคุณภาพซอฟต์แวร์และตัวชี้วัดกล่าวถึงงานบางอย่างซึ่งบ่งชี้ว่าความสัมพันธ์ระหว่างอัตราข้อบกพร่องและขนาดของโมดูลคือเส้นโค้งซึ่งข้อบกพร่องเฉลี่ยต่อ KSLOC มาพร้อมกับโมดูลที่มีขนาดระหว่าง 175 ถึง 350 SLOC

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

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

ฉันไม่แน่ใจว่าเป็นอย่างนั้น

ตัวอย่างเช่นมีการวิจัยที่แสดงให้เห็นว่าหน่วยความจำในการทำงานของมนุษย์สามารถถือวัตถุได้เพียง 7 บวก / ลบ 2เท่านั้น นี่น่าจะเป็นเรื่องที่น่าสนใจสำหรับการวัด fan-in และ fan-out - ถ้าฉันทำงานในโมดูลและมันเชื่อมต่อกับโมดูลอื่น ๆ มากกว่า 7 ชิ้นฉันอาจจะไม่สามารถติดตามสิ่งที่พวกเขาทำ โมดูลอื่นอยู่ในหัวของฉัน

นอกจากนี้ยังมีงานเกี่ยวกับข้อบกพร่องที่เกี่ยวข้องกับตัวชี้วัดเช่นความซับซ้อนของวัฏจักร เนื่องจากคุณต้องการลดข้อบกพร่องในระบบของคุณคุณสามารถระบุจุดที่ต้องการการทดสอบความพยายามมากขึ้นหรือการปรับโครงสร้างใหม่ตามที่ระบุไว้โดยความซับซ้อนของวัฏจักรสูง

ฉันยังสงสัยว่านี่เป็นความคิดที่อันตรายหรือไม่ถ้าหากผู้รับมอบฉันทะที่มีคุณภาพเป็นที่นิยมนั้นความกดดันทางธุรกิจจะทำให้นักพัฒนาต้องติดตามตัวชี้วัดเหล่านี้ด้วยค่าใช้จ่ายของคุณภาพโดยรวม (ด้านคุณภาพของพวกเขา

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

มีตัวชี้วัดหรือพร็อกซี่สำหรับคุณสมบัติมากมายที่คุณสนใจ:

1. บรรทัดของรหัส
2. แฟนเข้าพัดออก
3. อัตราความผิดพลาดต่อ 1,000 บรรทัดของรหัส
4. ความซับซ้อนของวัฏจักร
5. รหัสครอบคลุม
6. ครอบคลุมจุดตัดสินใจ
7. อัตราส่วนของข้อผิดพลาดคงที่ / แนะนำโดยกิจกรรมการบำรุงรักษา
8. การวิเคราะห์จุดฟังก์ชั่น

มีปัญหาบางอย่างกับรายการเหล่านี้ทั้งหมด:

1. งานที่ทำเพื่อเพิ่มประสิทธิภาพของตัวชี้วัด - แนวโน้มสากล เลวร้ายลงอย่างมากถ้ามีการใช้เมตริกใดเป็นพื้นฐานสำหรับการประเมินหรือให้รางวัลสำหรับทีมหรือบุคคล
2. ฉันไม่ทราบถึงตัวชี้วัดใด ๆ ที่ไม่มีบริบท นี่หมายความว่าไม่มีการเปรียบเทียบที่เป็นไปได้ในร้านค้า - เฉพาะภายในร้านค้าเมื่อเวลาผ่านไป ตัวชี้วัดที่เกิดจากการเปรียบเทียบดังกล่าวยังคงมีค่า - "เรากำลังผลิตรหัสอย่างถูกต้องมากกว่าปีที่แล้วหรือไม่"

ผลรวมของปัญหาเหล่านี้คือตัวชี้วัดเช่นนี้น่าจะมีค่าเฉพาะในวัฒนธรรมที่กว้างขึ้น - เช่น TQM การประกันคุณภาพ (ไม่ใช่การควบคุม) การปรับปรุงอย่างต่อเนื่อง kaizan ฯลฯ จำเป็นต้องกำหนดองค์ประกอบของทั้งสองวัฒนธรรม และวิธีที่จะต้องเปลี่ยน หากคุณมีคำจำกัดความของสิ่งเหล่านี้เมทริกเช่นสิ่งเหล่านี้จะกลายเป็นเครื่องมือสำคัญในการช่วยปรับปรุงคุณภาพของรหัสวิธีปฏิบัติในการทำงานความสามารถในการผลิตและอื่น ๆ หากไม่มีบริบทที่กว้างกว่านี้ จะกลายเป็นเครื่องมือของ beancounter เพื่อเพิ่มผลผลิตและลดต้นทุน และจะกลายเป็นอุปสรรคต่อการพัฒนาของพนักงาน

คุณอาจหมกมุ่นอยู่กับการวัดหรือคุณอาจหมกมุ่นอยู่กับคนที่ดีที่สุดเครื่องมือการปฏิบัติด้านวิศวกรรมและการประกันคุณภาพที่คุณสามารถจ่ายได้ ฉันจะมีความสุขมากขึ้นเมื่อมีอัจฉริยะ QA หวาดระแวงหลายคนที่ได้อ่าน 'Fooled by Randomness' และผู้ที่ต้องการทำให้เป็นอัตโนมัติมากกว่ารายงานที่จัดรูปแบบทางตัวเลขจำนวนมาก

มีปัญหาพื้นฐานเกี่ยวกับการวัด

ตัวชี้วัดทั้งหมดที่เสนอมานั้นค่อนข้างแสดงให้เห็นว่าในโลกแห่งความเป็นจริงบนโค้ดจริง ๆ นั้นมีความสัมพันธ์กันอย่างมากหรือมีความสัมพันธ์อย่างมากกับ SLOC ดิบ (บรรทัดซอร์สของโค้ด)

นี่คือสิ่งที่ฆ่าตัวชี้วัดของ Halstead ย้อนกลับไปในทศวรรษ 1970 (โดยบังเอิญวันหนึ่งแคลิฟอร์เนียปี 1978 ฉันนั่งพูดคุยกับปริญญาเอกใหม่เกี่ยวกับตัวชี้วัดของ Halstead ซึ่งเขาชี้ให้เห็น)

เมื่อไม่นานมานี้ความซับซ้อนของวงจร McCabe แสดงให้เห็นว่ามีความสัมพันธ์อย่างมากกับ SLOC ดิบจนถึงจุดที่ผู้ชายที่ทำการศึกษาสงสัยว่าเสียงดังถ้าตัวชี้วัดของ McCabe บอกเราว่ามีประโยชน์อะไรเลย

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

จากคำตอบทั้งหมดที่นี่ฉันรู้สึกงี่เง่ากับคำตอบเล็ก ๆ นี้ ดูCrap4jซึ่งพยายามจัดอันดับวิธีการในจาวาโดยดูจากว่าพวกเขาเหม็นมากแค่ไหน (โครงการดูเหมือนถูกทอดทิ้ง)

มันใช้การผสมผสานระหว่างความซับซ้อนของวงจรและการครอบคลุมการทดสอบ เหมือนกับตัวชี้วัดอื่น ๆ ทุกเกมสามารถเล่นได้