Các thử nghiệm liên quan đến số liệu mã với mật độ lỗi

Tôi tự hỏi liệu ai đó đã thực hiện một số thử nghiệm liên quan đến số liệu mã (SLOC, Độ phức tạp theo chu kỳ, v.v.) với mật độ lỗi trong các ứng dụng Hướng đối tượng.

Tôi không tìm kiếm các thí nghiệm chỉ chứng minh hoặc từ chối một mối tương quan, nhưng trên cả hai. Tôi không cố gắng tìm một viên đạn bạc vì tôi tin rằng mật độ lỗi của dự án có thể tương quan với một hoặc nhiều số liệu cho một dự án hoặc nhóm nhất định và mối tương quan có thể thay đổi trong suốt vòng đời của dự án / nhóm.

Mục đích của tôi là

1. Đo lường tất cả các số liệu thú vị trong 2-3 tháng (chúng tôi đã có khá nhiều từ sonar).
2. Tìm một số liệu tương quan với số lượng lỗi mới.
3. Thực hiện phân tích nguyên nhân gốc rễ để kiểm tra lý do tại sao điều này xảy ra (ví dụ: Chúng ta có thiếu một kỹ năng thiết kế nhất định không?).
4. Cải thiện kỹ năng và đo lường sự thay đổi cho một vài lần lặp lại.
5. Rửa sạch và lặp lại từ 2.

Nếu bạn không có bất kỳ kinh nghiệm nào về vấn đề này, nhưng hãy nhớ xem một bài báo / blog về chủ đề này, tôi sẽ đánh giá cao nếu bạn có thể chia sẻ nó.

Cho đến nay tôi đã tìm thấy các liên kết sau với một số thông tin về chủ đề này

• Bugs có cư trú trong mã phức tạp không? - chỉ các slide từ một bài thuyết trình.
• Thay đổi và lỗi: Khai thác và dự đoán các hoạt động phát triển - Chỉ cần trình chiếu frmm một bài thuyết trình. Dòng dưới cùng càng phụ thuộc, cơ hội lỗi càng cao (tôi nghĩ đây là một quy tắc chung).
• Thất bại là một từ có bốn chữ cái - Một sự nhầm lẫn về mối tương quan giữa các lỗi và số liệu.

Bất cứ khi nào tôi nghe về những nỗ lực liên kết một số loại số liệu dựa trên mã với lỗi phần mềm, điều đầu tiên tôi nghĩ đến là độ phức tạp theo chu kỳ của McCabe . Các nghiên cứu khác nhau đã phát hiện ra rằng có một mối tương quan giữa độ phức tạp chu kỳ cao và số lượng khuyết tật. Tuy nhiên, các nghiên cứu khác xem xét các mô-đun có kích thước tương tự (về dòng mã) cho thấy có thể không có mối tương quan.

Đối với tôi, cả hai số dòng trong một mô-đun và độ phức tạp chu kỳ có thể đóng vai trò là các chỉ số tốt về các khiếm khuyết có thể xảy ra, hoặc có lẽ khả năng lớn hơn là các khiếm khuyết sẽ được đưa vào nếu sửa đổi được thực hiện cho một mô-đun. Một mô-đun (đặc biệt là ở cấp độ lớp hoặc phương thức) có độ phức tạp chu kỳ cao là khó hiểu hơn vì có một số lượng lớn các đường dẫn độc lập thông qua mã. Một mô-đun (một lần nữa, đặc biệt là ở cấp độ lớp hoặc phương thức) với số lượng dòng lớn cũng khó hiểu vì sự gia tăng các dòng có nghĩa là nhiều điều đang xảy ra. Có nhiều công cụ phân tích tĩnh hỗ trợ tính toán cả hai dòng mã nguồn theo các quy tắc cụ thể và độ phức tạp theo chu kỳ, có vẻ như việc bắt chúng sẽ lấy trái cây treo thấp.

Các biện pháp phức tạp Halstead cũng có thể thú vị. Thật không may, tính hợp lệ của chúng dường như bị tranh luận phần nào, vì vậy tôi không cần thiết phải dựa vào chúng. Một trong những biện pháp của Halstead là ước tính các khiếm khuyết dựa trên nỗ lực hoặc khối lượng (mối quan hệ giữa độ dài chương trình về tổng số toán tử và toán hạng và từ vựng chương trình về các toán tử và toán tử riêng biệt).

Ngoài ra còn có một nhóm các số liệu được gọi là Số liệu CK. Định nghĩa đầu tiên của bộ số liệu này dường như nằm trong một bài báo có tiêu đề Một bộ số liệu cho thiết kế hướng đối tượng của Chidamber và Kemerer. Họ định nghĩa các phương thức có trọng số cho mỗi lớp, độ sâu của cây kế thừa, số lượng trẻ em, khớp nối giữa các lớp đối tượng, đáp ứng cho một lớp và thiếu sự gắn kết trong các phương thức. Bài viết của họ cung cấp các phương pháp tính toán cũng như mô tả về cách phân tích từng cái.

Về mặt tài liệu học thuật phân tích các số liệu này, bạn có thể quan tâm đến Phân tích thực nghiệm về số liệu CK cho độ phức tạp của thiết kế hướng đối tượng: Ý nghĩa đối với các khiếm khuyết phần mềm, được tác giả bởi Ramanath Subramanyam và MS Krishna. Họ đã phân tích ba trong số sáu số liệu CK (phương pháp trọng số cho mỗi lớp, khớp nối giữa các đối tượng được phân loại và độ sâu của cây thừa kế). Liếc qua tờ giấy, có vẻ như họ thấy đây là những số liệu có khả năng hợp lệ, nhưng phải được giải thích một cách thận trọng vì "cải thiện" người ta có thể dẫn đến những thay đổi khác cũng dẫn đến xác suất lỗi cao hơn.

Phân tích thực nghiệm về các số liệu thiết kế hướng đối tượng để dự đoán các lỗi nghiêm trọng cao và thấp, được tác giả bởi Yuming Zhou và Hareton Leung, cũng kiểm tra các số liệu của CK. Cách tiếp cận của họ là xác định xem họ có thể dự đoán các khiếm khuyết dựa trên các số liệu này hay không. Họ phát hiện ra rằng nhiều số liệu của CK, ngoại trừ độ sâu của cây thừa kế và số lượng trẻ em) có một số mức ý nghĩa thống kê trong việc dự đoán các khu vực có thể xác định được khuyết điểm.

Nếu bạn có tư cách thành viên của IEEE, tôi sẽ khuyên bạn nên tìm kiếm trong Giao dịch của IEEE về Kỹ thuật phần mềm để biết thêm các ấn phẩm học thuật và Phần mềm IEEE cho một số báo cáo ứng dụng và thực tế hơn. ACM cũng có thể có các ấn phẩm liên quan trong thư viện kỹ thuật số của họ .

Tôi đã thảo luận về mối tương quan có thể có trong một trong những bài đăng trên blog của tôi :

Sự thay đổi giữa độ phức tạp của chu kỳ và mật độ lỗi: Đây có phải là vấn đề thực sự không?

Câu trả lời là không. Giữ kích thước không đổi, các nghiên cứu cho thấy không có mối tương quan giữa CC và mật độ khuyết tật. Tuy nhiên, có hai mối tương quan thú vị khác để nghiên cứu:

Đầu tiên là: CC có tương quan mạnh với thời gian phát hiện và sửa lỗi không? Nói cách khác, nếu CC thấp hơn, chúng ta sẽ mất ít thời gian hơn để gỡ lỗi và sửa lỗi?

Cái thứ hai là: CC có tương quan mạnh với Tỷ lệ phản hồi lỗi (FFR, số lỗi trung bình dẫn đến việc áp dụng một thay đổi hoặc sửa một lỗi) không?

Nó cần điều tra nhiều hơn để xem có ai đã từng nghiên cứu mối tương quan này theo kinh nghiệm chưa. Nhưng, cảm giác ruột của tôi và phản hồi tôi nhận được từ các đội tôi làm việc là có mối tương quan tích cực mạnh mẽ giữa độ phức tạp chu kỳ ở một bên và thời gian phát hiện và sửa chữa khiếm khuyết hoặc tác động thay đổi ở phía khác.

Đây là một thử nghiệm tốt để làm. Hãy cảnh giác cho kết quả!

Trong cuốn sách Code Complete, tr.457, Steve McConnell nói rằng "độ phức tạp của dòng điều khiển rất quan trọng vì nó có tương quan với độ tin cậy thấp và lỗi thường xuyên". Sau đó, ông đề cập đến một vài tài liệu tham khảo hỗ trợ mối tương quan đó, bao gồm cả chính McCabe (người được cho là đã phát triển số liệu độ phức tạp chu kỳ). Hầu hết những ngày trước việc sử dụng rộng rãi các ngôn ngữ hướng đối tượng, nhưng vì số liệu này áp dụng cho các phương thức trong các ngôn ngữ đó, các tài liệu tham khảo có thể là thứ bạn đang tìm kiếm.

Những tài liệu tham khảo đó là:

• McCabe, Tom. 1976. "Một biện pháp phức tạp." Giao dịch của IEEE về Kỹ thuật phần mềm, SE-2, số 4 (tháng 12): 308-20
• Shen, Vincent Y., et al. 1985. "Xác định phần mềm dễ bị lỗi - Một nghiên cứu thực nghiệm." Giao dịch của IEEE về Kỹ thuật phần mềm SE-11, số 4 (tháng 4): 317-24.
• Ward, William T. 1989. "Ngăn ngừa lỗi phần mềm bằng cách sử dụng số liệu phức tạp của McCabe." Tạp chí Hewlett-Packard, tháng 4, 64-68.

Từ kinh nghiệm của riêng tôi, số liệu của McCabe, vì nó có thể được tính toán bởi một chương trình trên nhiều phần mã, rất hữu ích trong việc tìm kiếm các phương thức và hàm bị biến đổi quá mức và có xác suất cao chứa lỗi. Mặc dù tôi chưa tính toán, việc phân phối lỗi trong các hàm phức tạp chu kỳ cao so với các hàm phức tạp chu kỳ thấp, việc điều tra các hàm đó đã cho phép tôi phát hiện ra các lỗi lập trình bị bỏ qua.