코드 메트릭을 버그 밀도와 상관시키는 실험

누군가가 객체 지향 응용 프로그램의 버그 밀도와 코드 메트릭 (SLOC, Cyclomatic Complexity 등)을 상관시키는 실험을했는지 궁금합니다.

나는 상관 관계를 증명하거나 반증하는 실험을 찾고 있지 않지만 둘 다에서 실험을 찾고 있습니다. 나는 프로젝트의 버그 밀도가 있다고 생각 같은 묘책을 찾기 위해 노력하고 있지 않다 수도 주어진 프로젝트 또는 팀을 위해 하나 개 이상의 메트릭 상관 관계와 상관 관계가 프로젝트 / 팀의 수명 동안 변경할 수 있습니다.

내 목표는

1. 2-3 개월 동안 모든 흥미로운 지표를 측정하십시오 (우리는 이미 수중 음파 탐지기에서 상당히 많은 것을 가지고 있습니다).
2. 새로운 버그 수와 관련이있는 하나의 메트릭을 찾으십시오.
3. 왜 이런 일이 발생하는지 확인하기 위해 근본 원인 분석을 수행하십시오 (예 : 특정 설계 기술이 부족합니까?).
4. 몇 번의 반복에 대한 기술을 향상시키고 변화를 측정하십시오.
5. 헹구고 2에서 반복하십시오.

이것에 대한 경험이 없지만이 주제에 관한 논문 / 블로그를 본 것을 기억한다면 공유 할 수 있다면 감사하겠습니다.

지금 까지이 주제에 대한 정보가 담긴 다음 링크를 찾았습니다.

• 복잡한 코드에 버그가 있습니까? -프레젠테이션의 슬라이드 만.
• 변경 사항 및 버그 : 개발 활동 마이닝 및 예측 -프레젠테이션을 슬라이드합니다. 결론적으로 종속성이 많을수록 버그가 발생할 가능성이 높습니다 (이것이 일반적인 규칙이라고 생각합니다).
• 실패는 4 글자 단어입니다 -버그와 메트릭의 상관 관계에 대한 패러디입니다.

어떤 유형의 코드 기반 메트릭을 소프트웨어 결함과 연관시키려는 시도를들을 때마다 McCabe의 순환 복잡성 이라고 생각 합니다. 다양한 연구에 따르면 사이클로 틱 복잡도가 높고 결함 수간에 상관 관계가있는 것으로 나타났습니다. 그러나 크기가 비슷한 모듈을 살펴본 다른 연구에서는 (코드 줄로) 상관 관계가 없을 수 있음을 발견했습니다.

나에게 모듈의 줄 수와 순환 복잡도는 가능한 결함을 나타내는 좋은 지표가 될 수 있거나 모듈을 수정하면 결함이 주입 될 가능성이 더 큽니다. 사이클로 매틱 복잡도가 높은 모듈 (특히 클래스 또는 메소드 레벨)은 코드를 통해 독립적 인 경로가 많기 때문에 이해하기 어렵습니다. 줄 수가 증가하면 더 많은 일이 발생하기 때문에 많은 줄이있는 모듈 (특히 클래스 또는 메서드 수준)도 이해하기 어렵습니다. 지정된 규칙과 순환 복잡성에 대해 소스 코드 라인을 모두 계산할 수있는 정적 분석 도구가 많이 있으며,이를 캡처하면 낮은 매달린 과일을 잡는 것처럼 보입니다.

홀스 테드의 복잡성 조치 도 재미있을 수 있습니다. 불행히도, 그들의 타당성은 다소 논란의 여지가있는 것으로 보이므로, 나는 그것들에 의존 할 필요가 없습니다. Halstead의 조치 중 하나는 노력 또는 양 (전체 연산자 및 피연산자 측면의 프로그램 길이와 개별 연산자 및 연산자 측면의 프로그램 어휘 간의 관계)을 기반으로 한 결함 추정입니다.

CK 지표라고하는 지표 그룹도 있습니다. 이 측정 항목 모음의 첫 번째 정의는 Chidamber와 Kemerer의 AO (Object Oriented Design)를위한 측정 항목 모음이라는 제목의 논문에있는 것으로 보입니다. 클래스 별 가중 메서드, 상속 깊이 트리, 자식 수, 개체 클래스 간 연결, 클래스에 대한 응답 및 메서드의 결여 부족을 정의합니다. 그들의 논문은 계산 방법과 각 방법을 분석하는 방법에 대한 설명을 제공합니다.

이러한 지표를 분석하는 학술 문헌 측면에서, 객체 지향 설계 복잡성에 대한 CK 지표의 경험적 분석 : Ramanath Subramanyam 및 MS Krishna가 저술 한 소프트웨어 결함에 대한 영향에 관심이있을 수 있습니다. 그들은 6 개의 CK 측정 항목 중 3 가지 (클래스 당 가중 방법, 객체 분류 간의 결합 및 상속 깊이 트리)를 분석했습니다. 이 문서를 살펴보면 이들이 잠재적으로 유효한 지표라는 것을 알았지 만, "개선"하면 다른 변경으로 이어질 수 있고 결함의 가능성이 커질 수 있으므로주의해서 해석해야합니다.

Yuming Zhou와 Hareton Leung이 작성한 높고 낮은 심각도 오류 예측을위한 객체 지향 설계 메트릭의 실증 분석은 CK 메트릭도 검사합니다. 그들의 접근 방식은 이러한 메트릭을 기반으로 결함을 예측할 수 있는지 확인하는 것이 었습니다. 그들은 상속 심도 트리와 자식 수를 제외한 많은 CK 지표가 결함이 발견 될 수있는 영역을 예측하는 데 어느 정도의 통계적 유의성이 있음을 발견했습니다.

IEEE 멤버십을 보유한 경우 소프트웨어 엔지니어링 의 IEEE 트랜잭션에서 보다 많은 학술 출판물을 검색하고 IEEE 소프트웨어 를 통해보다 실제적이고 적용 가능한 보고서를 검색하는 것이 좋습니다 . ACM은 또한 디지털 도서관 에 관련 출판물이있을 수 있습니다 .

내 블로그 게시물 중 하나 에서 가능한 상관 관계에 대해 논의했습니다 .

Cyclomatic Complexity와 Bugs density 간의 상관 관계 : 이것이 진짜 문제입니까?

내 대답은 아니오 야. 크기를 일정하게 유지하면서 CC와 결함 밀도간에 상관 관계가없는 것으로 나타났습니다. 그러나 연구 할 다른 두 가지 흥미로운 상관 관계가 있습니다.

첫 번째는 CC가 결함을 감지하고 수정하는 기간과 밀접한 관련이 있습니까? 즉, CC가 낮 으면 디버그 및 결함 수정에 더 적은 시간을 소비 할 것입니까?

두 번째는 CC가 결함 피드백 비율 (FFR, 하나의 변경을 적용하거나 하나의 결함을 수정함으로써 발생하는 평균 결함 수)과 강한 상관 관계가 있는가?

이 상관 관계를 실험적으로 연구 한 사람이 있는지 더 조사해야합니다. 그러나 내 직감과 내가 일하는 팀에서 얻은 피드백은 한쪽의 순환 복잡성과 결함 감지 및 수정 기간 또는 다른 쪽의 변경 영향 사이에 강한 상관 관계가 있다는 것입니다.

이것은 좋은 실험입니다. 결과에주의하십시오!

Steve McConnell은 Code Complete, p.457 책에서 "제어 흐름 복잡성은 중요도가 낮고 오류가 자주 발생하기 때문에 중요합니다"라고 말합니다. 그런 다음 McCabe 자신 (순환 복잡도 메트릭을 개발 한 것으로 인정)을 포함하여 해당 상관 관계를 지원하는 몇 가지 참조를 언급합니다. 이들 중 대부분은 객체 지향 언어를 널리 사용하기는했지만이 지표가 해당 언어 내의 메소드에 적용되므로 참조가 원하는 것일 수 있습니다.

그 참조는 다음과 같습니다

• 맥케이브, 톰 1976. "복잡성 측정." 소프트웨어 공학에 관한 IEEE 거래, SE-2, no. 4 (12 월) : 308-20
• Shen, Vincent Y. 등 1985. "오류가 발생하기 쉬운 소프트웨어 식별-경험적 연구." 소프트웨어 엔지니어링에 관한 IEEE 거래 SE-11, 4 번 (4 월) : 317-24.
• Ward, William T. 1989. "McCabe의 복잡성 메트릭을 사용한 소프트웨어 결함 방지." Hewlett-Packard Journal, 4 월, 64-68.

필자의 경험에 따르면 McCabe의 메트릭은 많은 코드 섹션의 프로그램으로 계산할 수 있으므로 지나치게 복잡하고 오류가 포함될 가능성이 높은 방법과 함수를 찾는 데 유용합니다. 비록 높은 순환 복잡도 함수와 낮은 순환 복잡도 함수 사이의 오류 분포를 계산하지는 않았지만 이러한 함수를 조사하면 간과 된 프로그래밍 오류를 발견 할 수있었습니다.