소프트웨어 품질을 결정하기 위해 Halstead 복잡성 측정을 적용하는 작업이 있습니까?

1977 년 Maurice Howard Halstead는 소프트웨어 시스템에 대한 복잡한 측정법을 소개했습니다 는 프로그램 어휘, 프로그램 길이, 볼륨, 난이도, 노력 및 모듈의 예상 버그 수를 측정하는 . Wikipedia에 따르면, 어려움은 프로그램을 읽거나 쓸 때 프로그램을 이해하는 어려움과 관련이 있으며 노력은 시간 = (노력 / 18) 초인 응용 프로그램을 코딩하는 데 걸리는 시간으로 변환 될 수 있습니다.

데이터 및 계산이 소프트웨어 개발의 일부 측면과 관련이없는 한 측정은 쓸모가 없습니다. 그러나 특정 값 이상의 난이도에서 결함이 통계적으로 크게 증가하거나 난이도와 코드를 읽는 시간 사이의 관계가 통계적으로 나타나는 경향이있는 작업을 찾지 못했습니다 (N의 난이도는 평균 M 시간을 산출합니다) 코드 기반 이해) 또는 품질 결정에 유용한 사실 이후 (특히 쓰기 시간이 이미 측정 값으로 기록 된 이후) 시간을 계산할 수있는 모든 분석. 특히 Halstead의 버그 추정에 관심이 있습니다 (Wikipedia에 언급되지 않음)-응용 프로그램의 버그 수는 Volume / 3000 또는 Effort ^ (2/3) / 3000으로 추정 할 수 있습니다.

두 가지를 찾고 있습니다.

실제 애플리케이션에서 Halstead의 소프트웨어 복잡성 측정을 사용하여 소프트웨어 품질을 평가 한 사람이 있습니까? 그렇다면 어떻게 적용했으며 유용하고 유효하며 신뢰할 수있는 측정으로 판명 되었습니까?
소프트웨어 품질에 적용 할 때 Halstead 복잡도 측정의 타당성 (또는 무효 성)을 논의하는 설문 조사, 분석 또는 사례 연구 형태의 학술 연구가 있습니까?
SLOC (Source Lines of Code)를 사용하여 볼륨, 난이도, 노력, 시간 및 버그의 Halstead 메트릭스와 유사한 것을 계산하는 것을 보여주는 설문 조사, 분석 또는 사례 연구 형태의 학술 연구가 있습니까? 볼륨이 SLOC 수에 해당하고 난이도가 순환 복잡성 (및 기타 측정 값)에 해당 할 수 있다고 생각합니다. SLOC에서 노력, 생산성 또는 시간을 측정하는 것은 오해의 소지가 있음을 잘 알고 있습니다.

quality metrics measurement

— 토마스 오웬스
소스

Halstead의 메트릭 작업은 30-40 년 전에 더 수행되었으며 SLOC와의 강력한 상관 관계가 거의 즉시 발견 되었기 때문에 지난 15 년 동안 결과를 찾는 데 어려움을 겪을 것입니다. (이것은 UT Austin ca. 1977의 새로운 교수진 후보의

— 연설에서 비롯된 것입니다

고마워 질문을 업데이트하고 검색 노력이 더 오래된 논문을 다시 초점을 맞출 것입니다.

— 토마스 오웬스

답변:

Microsoft Research는이 영역에서 일부 작업을 수행했습니다. 이 페이지 확인 http://research.microsoft.com/en-us/people/nachin/을 . 비록 Halstead를 기반으로하지는 않았지만 Nachi와 그의 팀은 Halstead, 순환 복잡성, 코드 이탈 및 코드 영역의 변경에 대한 상대 위험 및 취약성을 평가하기위한 기타 조치를 사용하여 일부 조사를 수행했습니다. 또한 조직의 효율성이 어떻게 큰 역할을하는지에 관한 흥미로운 논문이 있습니다. 그러나 그것은 주제가 아닙니다. :)

— 니틴
소스

나는 그 중 일부를 읽어야 할 것입니다. 확실히 내가 관심있는 일이지만, 나는 (적어도 지금은), 특히 Halstead에 관심이 있으므로 여기서 초점을 맞출 것입니다. 더 많은 시간이 걸리면 읽을 수 있도록 사이트를 북마크에 추가했지만 당분간 +1이 있습니다.

— 토마스 오웬스

McCabe의 순환 복잡도는 실제 코드에서 원시 SLOC와 매우 밀접한 상관 관계가 있음을 보여주었습니다.

— John R. Strohm

그러한 연구는 꽤 있습니다. Google은 친구입니다.

Halstead의 지표는 모두 원시 SLOC (소스 코드 라인)와 밀접한 상관 관계가 있음을 입증했을 때 호의를 얻지 못했습니다. 이 시점에서 SLOC 측정이 쉬워지고 완료됩니다.

다음은 Google 도서 의 결과입니다 .

— 존 알 스트롬
소스

나는이 질문을하기 전에 인터넷 검색을 해 왔으며 아직 출판 된 논문이나 다른 평판 좋은 출처를 찾지 못했습니다. 또한 SLOC 관련 메트릭이 어떻게 나빠질 수 있는지 알지 못합니다. SLOC / 시간은 열악한 생산성 측정 기준이지만 일반적으로 다른 SLOC 기반 메트릭 (예 : 결함 / SLOC)이 유효한 것으로 간주됩니다.

— 토마스 오웬스

@Thomas : Halstead의 측정 항목이 SLOC와 "관련"되는 것이 아니라 강력한 상관 관계가 있다는 것입니다. 통계 102. Y와 X가 서로 밀접하게 관련되어 있다는 것은 Y / X 비율이 모든 데이터 세트에 대해 본질적으로 일정하다는 것을 의미합니다. 이 경우 X를 측정하기가 더 쉬운 경우 Y를 측정하는 데 아무런 의미가 없습니다. Y는 실제로 X에서 아직 모르는 것을 말하지 않기 때문입니다.

— John R. Strohm

말이 되네요 Halstead의 메트릭은 고유하고 총 연산자 수와 피연산자 수를 기반으로합니다. 프로그램이 길수록 전체 운영자 / 피연산자가 더 많고 더 뚜렷한 운영자 / 피연산자가 더 많을 것이라는 것은 상식입니다. Volume and Difficulty (볼륨 및 난이도)의 지표는 운영자 / 운영자 대신 SLOC를 사용하여 얻을 수 있습니다. 그러나 노력, 시간 및 버그 메트릭스의 유효성, 응용 프로그램 및 의미 (또는 의미가 없음)는 다루지 않습니다. 연산자 / 피연산자 대신 SLOC를 사용하여 계산할 때도 이러한 메트릭이 시스템에 대해 의미있는 것을 말합니까?

— 토마스 오웬스

SLOC는 계산하기 쉽고 더 유용 할 것입니다. SLOC의 추정치는 PSP 및 TSP에서 추적되는 몇 가지 비용 추정 기술에 의해 사용되며 결함 밀도와 같은 다른 메트릭에 사용될 수 있습니다. SLOC를 계산하는 것이 연산자 / 피연산자를 계산하는 것보다 낫습니다. 둘째, 지금까지 답하지 않은 것은 노력, 시간 및 버그의 측정치가 어떤 측정 값을 사용하는지에 관계없이 유효성입니다. SLOC로 계산하는 것이 더 나을 수도 있지만 동의하더라도 아무 의미가 있습니까?

— 토마스 오웬스

@ThomasOwens : 아마 아닙니다. 노력, 시간 및 버그가 모두 SLOC와 밀접한 상관 관계가있는 경우 지정된 크기의 모든 프로그램에 동일한 시간과 노력이 소요되고 동일한 수의 버그가 있음을 알려줍니다. 처음 두 가지는 SLOC 기반 추정 (예 : COCOMO)의 기반이며 물이 젖었다는 것과 같습니다. 세 번째는 실제로 도움이되지 않습니다.

— John R. Strohm

Halstead Volume이 SLOC와 관련이 있다는 것은 흥미롭지 만 제한적입니다. 기본 통계 : 선형 상관 관계는 전이되지 않습니다. X는 Y와 상관 관계가 있고 Y는 Z와 상관 관계가있다

— 사용자 1704475
소스

X와 Y가 단순히 상관되고 Y와 Z가 단순히 상관 될 때, 그렇습니다. X와 Z는 처음 두 상관에서 상대적으로 높은 잡음 레벨 때문에 반드시 상관 될 필요는 없습니다. X와 Y가 강한 상관 관계가 있고 Y와 Z가 강한 상관 관계가 있으면 노이즈가 거의 발생하지 않으며 X와 Z가 상관되는 경우가있을 가능성이 높습니다.

— John R. Strohm