Có bất kỳ công việc nào trong việc áp dụng các biện pháp phức tạp Halstead để xác định chất lượng phần mềm không?

Năm 1977, Maurice Howard Halstead đã giới thiệu các biện pháp phức tạp của mình cho các hệ thống phần mềm , bao gồm các phép đo từ vựng chương trình, thời lượng chương trình, khối lượng, độ khó, nỗ lực và số lượng lỗi ước tính trong một mô-đun. Theo Wikipedia, khó khăn liên quan đến khó khăn trong việc hiểu chương trình khi đọc hoặc viết nó và nỗ lực có thể được dịch thành thời gian cần thiết để mã hóa một ứng dụng trong đó Thời gian = (Nỗ lực / 18) giây.

Một phép đo là vô ích trừ khi dữ liệu và tính toán liên quan đến một số khía cạnh của phát triển phần mềm. Tuy nhiên, tôi chưa tìm thấy bất kỳ công việc nào nói rằng độ khó của một giá trị nhất định hoặc cao hơn có xu hướng gia tăng đáng kể về mặt khiếm khuyết hoặc mối quan hệ giữa khó khăn và thời gian để đọc mã (độ khó của N mang lại trung bình M giờ sử dụng hiểu cơ sở mã) hoặc bất kỳ phân tích nào về khả năng tính toán Thời gian sau khi thực tế có ích trong việc xác định chất lượng (đặc biệt là do thời gian viết nên đã được ghi lại như một phép đo). Tôi đặc biệt quan tâm đến ước tính lỗi của Halstead (không được đề cập trên Wikipedia) - số lượng lỗi trong ứng dụng có thể được ước tính theo Tập / 3000 hoặc Nỗ lực ^ (2/3) / 3000.

Tôi đang tìm kiếm hai điều:

• Có ai đã sử dụng các biện pháp phức tạp phần mềm của Halstead trong một ứng dụng trong thế giới thực để đánh giá chất lượng phần mềm chưa? Nếu vậy, làm thế nào bạn áp dụng chúng và chúng hóa ra là một phép đo hữu ích, hợp lệ và / hoặc đáng tin cậy?
• Có nghiên cứu học thuật nào dưới dạng khảo sát, phân tích hoặc nghiên cứu trường hợp thảo luận về tính hợp lệ (hoặc tính vô hiệu) của các biện pháp phức tạp Halstead khi áp dụng cho chất lượng phần mềm không?
• Có nghiên cứu học thuật nào dưới dạng khảo sát, phân tích hoặc nghiên cứu trường hợp chứng minh việc sử dụng Mã nguồn (SLOC) để tính toán một số thứ tương tự như các số liệu Halstead về Khối lượng, Độ khó, Nỗ lực, Thời gian và Lỗi không? Tôi nghi ngờ rằng Khối lượng có thể chỉ tương ứng với số SLOC và Độ khó có thể tương ứng với độ phức tạp chu kỳ (và có thể các biện pháp khác). Tôi cũng nhận thức rõ rằng việc đo lường nỗ lực, năng suất hoặc thời gian trong SLOC có khả năng gây hiểu nhầm.

Microsoft Research đã thực hiện một số công việc trong lĩnh vực này. Kiểm tra trang này: http://research.microsoft.com/en-us/people/nachin/ . Mặc dù không đặc biệt dựa trên Halstead, Nachi và nhóm của anh ta đã thực hiện một số điều tra bằng cách sử dụng Halstead, độ phức tạp theo chu kỳ, khuấy mã và các biện pháp khác để đánh giá rủi ro và sự mong manh tương đối để thực hiện thay đổi trong các lĩnh vực mã. Ngoài ra còn có một bài viết thú vị về hiệu quả tổ chức cũng đóng một vai trò lớn nhưng đó không phải là chủ đề. :)

Có khá nhiều nghiên cứu như vậy. Google là bạn của bạn.

Số liệu của Halstead không được ủng hộ khi chứng minh rằng tất cả chúng đều có mối tương quan chặt chẽ với SLOC (dòng mã nguồn). Tại thời điểm đó, việc đo SLOC trở nên dễ dàng hơn và được thực hiện với nó.

Đây là kết quả từ Google Sách .

Khối lượng Halstead tương quan với SLOC rất thú vị nhưng hạn chế. Thống kê cơ bản: tương quan tuyến tính không phải là bắc cầu. X tương quan với Y, Y tương quan với Z KHÔNG Ý NGH thatA rằng X tương quan với Z.