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


14

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에서 노력, 생산성 또는 시간을 측정하는 것은 오해의 소지가 있음을 잘 알고 있습니다.

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

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

답변:


5

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


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

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

0

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

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

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


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

1
@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

0

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


X와 Y가 단순히 상관되고 Y와 Z가 단순히 상관 될 때, 그렇습니다. X와 Z는 처음 두 상관에서 상대적으로 높은 잡음 레벨 때문에 반드시 상관 될 필요는 없습니다. X와 Y가 강한 상관 관계가 있고 Y와 Z가 강한 상관 관계가 있으면 노이즈가 거의 발생하지 않으며 X와 Z가 상관되는 경우가있을 가능성이 높습니다.
John R. Strohm
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.