'Halstead'에 해당되는 글 1건

  1. 2009.07.10 소프트웨어 품질 측정의 척도. (2)

IT 산업이 발달하면서 제품에서 소프트웨어가 차지하는 비중이 점점 높아지고 있으며, IT 기업들이 국내 시장을 확보하거나 국산 소프트웨어의 수출을 위해서 소프트웨어 품질 확보는 이미 필수적인 문제가 되었습니다. 이러한 소프트웨어 품질의 표준화를 담당하고 있는 기구로서는 ISO ( International Organization for Standardization ) IEEE (Institute of Electrical and Electronics Engineers ) 가 대표적입니다. 전자는 제품 평가 분야, 프로세스 평가 분야, 품질시스템 구축 분야를 진행하고 있고, 후자는 일관성, 합리적 절차, 공개성과 균형성을 위해 IEEE 표준 프로젝트를 검토하는 업무를 담당하고 있습니다. 또한 국내에서는 기술 표준원 ATS ( Korean Agency for Technology and Standards ) 과 한국 정보통신 기술협회 TTA ( Telecommunications Technology Association ) 에서 소프트웨어 품질 관련 표준을 제정 및 관리하고 있습니다. 그럼 이러한 기구들에서 정해놓은 소프트웨어 품질 평가의 척도에는 어떤 것들이 있는지 이야기해보겠습니다.

 

COCOMO Model ( COnstruction Cost Model )

è           미국 TRW 사의 B. Boehem 이 소개한 1981년 원시 프로그램의 규모에 의한 비용산출 방법입니다. 이 것은 SLOC ( Source lines Of Code ), SDI ( Delivered Source Instruction ) 으로부터 비용을 예측합니다. 즉 시스템의 크기에 의존하게 됩니다. 어떤 프로그래밍 언어를 사용하느냐에 따라서 예상되는 크기가 다를 수 있고, LOC ( Lines Of Code ) 를 초기 단계에서 추정해야만 하는 어려움이 있습니다. COCOMO 의 분류기준은 크게 Basic Model, Intermediate Model, Detailed Model 세 가지를 들 수 있으며, 일반적으로 각각 응용 프로그램, 유틸리티 프로그램, 시스템 프로그램을 가리킨다고 볼 수 있겠습니다. 참고로 Intermediate COCOMO 의 비용요소들에는 다음과 같은 것들이 있습니다.

1.)    제품 속성 : 요구되는 소프트웨어의 신뢰도, 응용 데이터베이스의 크기, 제품의 복잡성.

2.)    컴퓨터 속성 : 실행시간의 성능 제한 조건, 주기억장치의 제약, 컴퓨터의 안정성, 반환 시간

3.)    인력 속성 : 분석가의 지질, 프로그래머의 지질, 응용분야의 경험, 컴퓨터와의 친숙성, 프로그래밍 언어의 경험

4.)    프로젝트 숙성 : 소프트웨어 공학 기법의 응용, 개발도구의 사용도, 개발기간의 산정

 

 

Doty Model

è           Doty Model 은 인터뷰와 문헌을 바탕으로 만들어진 Model 로써, 프로그램의 규모를 알 수 있다는 전제하에서 총공수를 구하게 되며, 공식은 다음과 같습니다.

총공수 ( MM ) = 상수 * 프로그램의 소스 코드 라인수

 

Putman Model ( 생명주기 예측모델 )

è           이미 대규모 R&D 프로젝트에 적용되었던 모델을 기초로 가설을 세울 수 있게 해 줍니다. 프로젝트의 Life Cycle 기간 동안 노력의 특수한 분포 ( Rayleigh ) 를 가정해주는 Dynamic Multivariable Model 입니다.

 

FP ( Function Point )

è           1979 , IBM Albrecht 는 소프트웨어 규모를 측정 및 예측하는 기법으로 기능 점수 ( Function Point ) 라는 것을 제안하였습니다. 그 당시 Function Point 는 소프트웨어 개발 프로젝트의 규모를 측정하기 위해서 사용되었는데, 소프트웨어 산업이 발전함에 따라 점차 공학적 접근을 통한 다양한 분야에서 쓰이고 있습니다. 벤치마킹 조사, 소프트웨어 계약과 관련된 소송, 아웃 소싱 계약, 품질 측정, 산출물의 규모 예측 등이 바로 그 것들입니다. 그럼 Function Point 를 사용하여 어떻게 분석을 하는지 알아보겠습니다.

기능 점수 분석법 ( Function Point Analysis ) 의 핵심은 개발자 중심의 관점에서 벗어나 사용자 관점에서 소프트웨어 개발 규모를 측정한다는 데에 있습니다. COCOMO LOC 에 기반하여 소프트웨어 규모를 파악하는 데 반하여, 기능 점수 분석법에서는 사용자의 요구 기능을 분석하여 소프트웨어 규모를 파악하게 됩니다. 사용자의 요구 기능이라 함은 데이터를 조작 ( 저장, 삭제, 이동 등 ) 하는 트랜잭션 기능 따위를 말하는 것입니다. 이렇게 함으로써 기술적 요구사항과는 독립적으로 개발 및 유지보수 소프트웨어 규모를 측정하는 것이 기능 점수 분석법의 목적입니다. 기능 점수를 측정하는 절차는 다음과 같습니다.



측정 유형의 결정

측정 범위와

경계 결정

데이터 기능 측정

트랜잭션 기능 측정

UFP 산정.

VAF 확정

AFP 산정

* UFP : Unadjusted Funtion Point

* VAF : Value Adjustment Factor s

* AFP : Adjusted Function Point

Halstead 의 소프트웨어 복잡성 척도 ( Halstead Complexity Measures )

è           이 것은 복잡도를 방법으로써 프로그램에서 사용된 연산자 / 피연산자의 개수와 종류,발생 빈도 간의 관계 등을 이용하게 됩니다. 이 방법의 장단점은 다음과 같습니다.

Advantage

1.)    프로그램의 구조를 깊게 분석할 필요가 없습니다.

2.)    에러율과 유지보수 비용을 예측할 수 있습니다.

3.)    계산 방법이 단순합니다.

4.)    어떤 프로그래밍 언어에 대해서도 사용이 가능합니다.

단점

1.)    완성된 코드에 의존해야 합니다.

2.)    Predictive estimating model 에 대해서는 거의 사용하지 못 합니다.

 

McCabe 의 회전 복잡도 ( Cyclomatic Complexity )

è           McCabe 의 회전 복잡도는 상세 설계가 완료된 후부터 사용이 가능하며, 프로그램의 제어 흐름도를 기반으로 분석하게 됩니다. 그래프를 이용하게 되는데 각 노드 안에 처리 작업을 나타내고, 화살표로 제어의 흐름을 표시하게 됩니다. 그리고 각각의 개수를 세어서 복잡도를 계산하게 되는데 공식은 다음과 같습니다.

Cyclomatic Complexity (G) = 화살표의 수 노드 수 + 2

복잡도가 낮을수록 프로그램이 구조적으로 안정되었다는 의미이며, 높을수록 프로그램이 비 구조적이며 불안정하다는 의미입니다.

 

LOC ( Line Of Code )

è           말 그대로 프로그램 코드의 라인 수, 다시 말해 크기를 중심으로 개발자의 관점에서소프트웨어를 측정하는 방법입니다. 다음과 같은 공식들에 의해 측정이 이루어집니다.

생산성 = KLOC ( K Line Of Code )

비용 = 오류의 수 / KLOC

문서화 = 문서의 페이지 수 / KLOC

LOC 의 가장 큰 장점은 측정하기가 매우 쉽다는 것입니다. LOC 를 중심으로 예측하는 자료들이 이미 많이 존재하기 때문이기도 합니다. 하지만 프로그래밍 언어에 dependency 가 있으며 개발 초기나 기획 단계에서는 정확한 LOC 측정이 불가능하다는 단점이 있습니다.

 

 프로그래머가 완전하게 테스트했다고 믿는 소프트웨어도 보통은 로직 경로의 55~60%만 테스트된 경우가 많다고 합니다. 현재의 개발 부서와 검증 부서가 나뉘어지게 된 것도 그런 이유에서 비롯된 것이 아닌가 생각을 해 봅니다. 

Posted by 행복한 프로그래머 궁금쟁이박

댓글을 달아 주세요

  1. BlogIcon 박영식 2010.01.19 11:40  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다.ㅋ