การทดลองที่สัมพันธ์กับตัวชี้วัดโค้ดกับความหนาแน่นของบั๊ก

ฉันสงสัยว่ามีคนทำการทดลองบางอย่างที่สัมพันธ์กับตัวชี้วัดโค้ด (SLOC, Cyclomatic Complexity และอื่น ๆ ) ด้วยความหนาแน่นของข้อบกพร่องในแอปพลิเคชัน Object Oriented หรือไม่

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

เป้าหมายของฉันคือ

1. วัดตัวชี้วัดที่น่าสนใจทั้งหมดสำหรับ 2-3 เดือน (เรามีโซนาร์ค่อนข้างน้อย)
2. ค้นหาหนึ่งเมตริกที่สัมพันธ์กับจำนวนข้อบกพร่องใหม่
3. ทำการวิเคราะห์สาเหตุที่แท้จริงเพื่อตรวจสอบสาเหตุที่เกิดขึ้น (เช่นเราขาดทักษะการออกแบบบางอย่างหรือไม่)
4. พัฒนาทักษะและการวัดการเปลี่ยนแปลงสำหรับคู่ของมัน
5. ล้างและทำซ้ำจาก 2

หากคุณไม่มีประสบการณ์เกี่ยวกับเรื่องนี้ แต่จำไว้ว่าให้ดูกระดาษ / บล็อกเกี่ยวกับเรื่องนี้ฉันจะขอบคุณถ้าคุณสามารถแบ่งปันได้

จนถึงตอนนี้ฉันได้พบลิงค์ต่อไปนี้พร้อมข้อมูลบางอย่างเกี่ยวกับเรื่องนี้

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

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

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

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

นอกจากนี้ยังมีกลุ่มของตัวชี้วัดที่รู้จักกันในชื่อตัวชี้วัด CK คำจำกัดความแรกของชุดเมทริกนี้ดูเหมือนจะอยู่ในกระดาษชื่อ A Metrics Suite สำหรับการออกแบบเชิงวัตถุโดย Chidamber และ Kemerer พวกเขากำหนดวิธีการถ่วงน้ำหนักต่อชั้นความลึกของต้นไม้มรดกจำนวนเด็กการมีเพศสัมพันธ์ระหว่างคลาสวัตถุการตอบสนองสำหรับชั้นเรียนและการขาดการทำงานร่วมกันในวิธีการ บทความของพวกเขาให้วิธีการคำนวณเช่นเดียวกับคำอธิบายของวิธีการวิเคราะห์แต่ละคน

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

การวิเคราะห์เชิงประจักษ์ของตัวชี้วัดการออกแบบเชิงวัตถุสำหรับการทำนายความผิดปกติระดับสูงและต่ำที่ประพันธ์โดย Yuming Zhou และ Hareton Leung ยังตรวจสอบตัวชี้วัด CK อีกด้วย วิธีการของพวกเขาคือการพิจารณาว่าพวกเขาสามารถทำนายข้อบกพร่องตามตัวชี้วัดเหล่านี้ได้หรือไม่ พวกเขาพบว่าตัววัด CK จำนวนมากยกเว้นความลึกของต้นไม้มรดกและจำนวนลูก) มีระดับนัยสำคัญทางสถิติในการทำนายพื้นที่ซึ่งข้อบกพร่องอาจอยู่

หากคุณมีสมาชิก IEEE ฉันขอแนะนำให้ค้นหาในธุรกรรม IEEE บนวิศวกรรมซอฟต์แวร์เพื่อการตีพิมพ์ทางวิชาการและซอฟต์แวร์ IEEEเพิ่มเติมเพื่อรายงานและการใช้งานจริงเพิ่มเติม พลอากาศเอกนอกจากนี้ยังอาจจะมีสิ่งพิมพ์ที่เกี่ยวข้องในของพวกเขาห้องสมุดดิจิตอล

ฉันได้พูดถึงความสัมพันธ์ที่เป็นไปได้ในหนึ่งในโพสต์บล็อกของฉัน :

ความสัมพันธ์ระหว่างความซับซ้อนของวัฏจักรกับความหนาแน่นของบัก: นี่เป็นปัญหาจริงหรือไม่?

คำตอบคือไม่ การรักษาขนาดคงที่การศึกษาไม่แสดงความสัมพันธ์ระหว่าง CC และความหนาแน่นของข้อบกพร่อง อย่างไรก็ตามมีอีกสองความสัมพันธ์ที่น่าสนใจในการศึกษา:

สิ่งแรกคือ: CC มีความสัมพันธ์อย่างมากกับระยะเวลาในการตรวจจับและแก้ไขข้อบกพร่องหรือไม่? กล่าวอีกนัยหนึ่งถ้า CC ต่ำกว่าเราจะใช้เวลาดีบักน้อยลงและแก้ไขข้อบกพร่องได้หรือไม่

ข้อที่สองคือ: CC มีความสัมพันธ์อย่างมากกับอัตราส่วนความคิดเห็นผิดพลาด (FFR) จำนวนข้อบกพร่องเฉลี่ยซึ่งเป็นผลมาจากการใช้การเปลี่ยนแปลงเดียวหรือแก้ไขข้อบกพร่องหนึ่งข้อ) หรือไม่

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

นี่เป็นการทดลองที่ดีที่ต้องทำ แจ้งเตือนผล!

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

การอ้างอิงเหล่านั้นคือ:

• McCabe ทอม 2519 ได้ "วัดความซับซ้อน" ธุรกรรม IEEE เกี่ยวกับวิศวกรรมซอฟต์แวร์ SE-2 หมายเลข 4 (ธันวาคม): 308-20
• Shen, Vincent Y. , et al. 2528 ได้ "ระบุข้อผิดพลาด - แนวโน้มซอฟต์แวร์ - การศึกษาเชิงประจักษ์" ธุรกรรม IEEE เกี่ยวกับวิศวกรรมซอฟต์แวร์ SE-11, no.4 (เมษายน): 317-24
• วอร์ดวิลเลียมตัน 2532 ได้ "การป้องกันข้อบกพร่องซอฟต์แวร์ใช้ McCabe ซับซ้อนของตัวชี้วัด" Hewlett-Packard Journal, เมษายน, 64-68

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