3
มีการประยุกต์ใช้มาตรการความซับซ้อนของ Halstead ในการพิจารณาคุณภาพซอฟต์แวร์หรือไม่
ในปี 1977 Maurice Howard Halstead ได้แนะนำมาตรการความซับซ้อนของระบบซอฟต์แวร์ซึ่งรวมถึงการวัดคำศัพท์ของโปรแกรมความยาวของโปรแกรมปริมาตรความยากความพยายามและจำนวนข้อผิดพลาดโดยประมาณในโมดูล ตามวิกิพีเดียความยากลำบากเกี่ยวข้องกับความยากลำบากในการทำความเข้าใจโปรแกรมเมื่ออ่านหรือเขียนและความพยายามสามารถแปลเป็นเวลาที่ใช้ในการเขียนโปรแกรมประยุกต์ที่เวลา = (ความพยายาม / 18) วินาที การวัดไม่มีประโยชน์เว้นแต่ว่าข้อมูลและการคำนวณจะเกี่ยวข้องกับการพัฒนาซอฟต์แวร์ อย่างไรก็ตามฉันไม่พบงานใด ๆ ที่ระบุว่าความยากลำบากของค่าบางค่าหรือสูงกว่ามีแนวโน้มเพิ่มขึ้นอย่างมีนัยสำคัญทางสถิติในข้อบกพร่องหรือความสัมพันธ์ระหว่างความยากลำบากและเวลาในการอ่านรหัส (ความยากลำบากของ N การทำความเข้าใจฐานรหัส) หรือการวิเคราะห์ใด ๆ ที่สามารถคำนวณเวลาหลังจากข้อเท็จจริงที่เป็นประโยชน์ในการกำหนดคุณภาพ (โดยเฉพาะตั้งแต่เวลาที่จะเขียนควรได้รับการบันทึกเป็นการวัดแล้ว) ฉันสนใจโดยเฉพาะอย่างยิ่งในการประเมินข้อผิดพลาดของ Halstead (ซึ่งไม่ได้กล่าวถึงใน Wikipedia) - จำนวนข้อบกพร่องในแอปพลิเคชันสามารถประมาณได้โดย Volume / 3000 หรือ Effort ^ (2/3) / 3000 ฉันกำลังมองหาสองสิ่ง: มีใครบ้างที่ใช้มาตรการความซับซ้อนของซอฟต์แวร์ของ Halstead ในแอปพลิเคชันที่ใช้งานจริงเพื่อประเมินคุณภาพซอฟต์แวร์ ถ้าเป็นเช่นนั้นคุณใช้พวกเขาอย่างไรและพวกเขากลายเป็นการวัดที่มีประโยชน์ถูกต้องและ / หรือเชื่อถือได้หรือไม่ มีงานวิจัยเชิงวิชาการในรูปแบบของการสำรวจวิเคราะห์หรือกรณีศึกษาที่กล่าวถึงความถูกต้อง (หรือความไม่ถูกต้อง) ของมาตรการความซับซ้อนของ Halstead เมื่อนำไปใช้กับคุณภาพของซอฟต์แวร์หรือไม่ …