프로젝트 규모 추정

• 프로젝트 규모 추정 개요
  • 프로젝트 규모 추정 개념
    • 컴퓨터 기반 시스템에서 소프트웨어는 가장 비싼 요소
    • 소프트웨어 비용, 노력 추정 변수 : 인산, 기술, 환경, 정치
  • 비용과 노력을 추정하기 위한 방법
    • 프로젝트 후반부까지 추정을 지연시킴 : 실질적이지 못함
    • 분해 기술(Decomposition Technique) 이용 : 주요 기능들과 관련된 소프트웨어 공학 활동에 의해 분해되어 활동 별로 추정
    • 경험적 모델을 이용 : 과거 경험/프로젝트 테이터를 바탕으로 추정
      Y = f(x) Y=추정값(비용,노력), x= LOC(Line of Code), FP(Function Point)
    • 자동 추정 도구를 구입하여 이용
       
• 소프트웨어 규모 산정 방법
  • 하향식 산정 방법
    • 경험적 단어(시스템을 이해한 후), 개발자 합의(인력, 시스템 크기, 예산)
    • 전문가 감정과 델파이 방식 이용
  • 상향식 산정 방법
    • 업무 분류 구조 정의, 각 구성 요소에 대한 독립적 산정 및 집계
    • LOC 기법, 개발 단계별 인원 수 기법 이용
         
• 양적 규모 산정 방식(LOC 방식) : 소스 코드 라인 수에 근거한 규모 산정 방식
  • Doty 모델
    • 인터뷰와 문헌을 바탕으로 개발한 모델로, 프로그램 규모가 알려졌다는 전제하에 총 공수를 구하는 방법(규모(I)가 10,000행 이상 --> 기본형, 이하 --> 다변형량)
    • 총 공수(MM) : 상수 * 프로그램 규모(I) = 소스 코드 라인 수)
  • Putnam 모델
    • 가설을 전제로 한 모델(대규모 연구 개발 프로젝트에 적용된 모델을 기초)
  • COCOMO(Constructive Cost Model) 모델
    • Boehm에 의해 비즈니스, 산업계, 정부, S/W 하우스 등에서 엄선한 63종류의 프로젝트 데이터에 기초하여 작성된 경험적인 소프트웨어 비용 견적 모델
    • COCOMO 모델 의의는 가장 이해하기 쉬운 실험적 모델
  • 크기 중심 규모 산정 사례
    • 특성: 소프트웨어나 프로세스에 대한 직접적인 측정

프로젝트	LOC	노력 (M/M)	비용 (천만 원)	문서의 페이지	오류 (Error)	결함 (Defects)	인원
A	13,400	20	8	373	128	30	2
B	29,100	63	48	1317	334	92	7
C	19,500	30	35	960	274	70	5

LOC 기법 사례

• 생산성 = KLOC / 노력
  • 품질 : 오류 발생률 = 오류의 수 / KLOC, 결함 발생률 = 결함의 수 / KLOC
    비용 효율성 = 비용 / KLOC, 문서화 = 문서의 페이지 수 /KLOC
• 장.단점

장점	단점
LOC 중심으로 측정 LOC는 쉽게 계산이 가능 많은 측정 모델이 LOC를 중요한 입력값으로 사용	프로그래밍 언어에 따라 크기가 가변적 LCO의 기준이 모호하고 표준이 결여

• 적용 방법
  • 단계 1 : 모듈별로 분할
  • 단계 2 : 기능별로 LOC 추정, EV(추정 LOC) = (P + 4M +O) / 6 , Sum(EV)
  • 단계 3 : 경험 데이터 이용하여 프로젝트 비용과 개발 노력 추정
    프로젝트 비용 = KLOC * KLOC당 비용(경험치),
    개발 노력 = KLOC / 생산성(경험치)
  •    

• 양과 질을 고려한 방식 : 소프트웨어 특성을 이용한 간접 산정 방식(규모/복잡도)
  • 기능 중심 규모 산정
    • 기능 점수(Function Point)의 개요
      • 사용자가 요구하는 소프트웨어 기능의 규모를 표현하는 단위(Unit)를 의미
        → 사용자 요구의 물리적 형태 : 제안서, 사업 계획서, 사양서, 요건 문서
      • 사용자에게 제공되는 소프트웨어의 기능적 크기를 측정하는 단위
      • 1979년 Allan Albrecht에 의해 기능 점수 소개
      • 1986년 국제 기능 점수 사용자 그룹(IFPUG)의 발족으로 활성화
      • 2003년 ISO/IEC 표준으로 승인
    • 기능 점수의 목적
      • 사용자의 요구에 의해 제공받는 기능들을 측정
      • 구현 기술과는 무관하게 소프트웨어 개발 및 유지보수의 규모를 측정
      • 측정 과정에서의 부담을 최소화하기 위해 충분히 단순해야 함
      • 소프트웨어 개발 및 유지보수의 업무량을 전 프로젝트 및 조직에 걸쳐서 일관되게 측정 → 프로젝트 및 조직 간 업무량을 비교
    • 기능 점수의 특성
      • 기능적 사용자 요구 사항 측정 : 애플리케이션이 사용자에게 제공하는 기능
      • 외부 사용자 관점에서 측정 : 애플리케이션 경계 밖의 사용자(사람 또는 타 애플리케이션)의 시작에서 측정
      • 전 생명주기에 걸쳐서 적용 : 계획, 개발, 운영 등 전 단계에서 측정 가능
      • 적용 방법론, 기술, 물리적 또는 기술적 컴포넌트와 무관하게 측정 : 기능 규모, 구조적/정보 공학적/객체 지향, 패키지/COTS 등에 무관하게 측정 가능
    • 기능 점수의 이점
      • 패키지의 모든 기능을 측정함으로써 구매한 애플리케이션 패키지의 규모를 결정하는 도구
      • 사용자 요구를 만족시키는 특정 기능을 측정함으로써 애플리케이션 패키지가 사용자 조직에 유익한지의 결정을 지원하는 도구
      • 품질과 생산성 분석을 돕기 위해 소프트웨어 제품 단위를 측정하는 도구
      • 소프트웨어 개발 및 유지 보수에 필요한 비용과 자원을 측정하는 도구
      • 소프트웨어 비교를 위한 정규화 요소
    • 기능 점수 측정 유형
      • 개발 프로젝트 : 프로젝트가 종료되어 인도된 소프트웨어의 최초 설치와 함께 사용자에게 제공된 기능을 측정하는 것
      • 개선 프로젝트 : 기존 애플리케이션의 변경 부분을 측정하는 것으로, 프로젝트 종료 후 인도된 사용자 기능에 추가, 수정, 삭제 한 부분을 의미
      • 애플리케이션 : 설치된 애플리케이션의 베이스라인 또는 설치된 기능 점수 측정
    • 기능 점수 측정 절차
      
    • 5가지 측정 항목
      • EI (External Input) : 외부 입력 측정(사용자 입력 개수)
      • EO(External Output) : 외부 출력 측정(사용자 출력 개수)
      • EQ(External inQuery) : 외부 조회 측정(사용자 질의 개수)
      • ILF(Internal Logical File) : 내부파일 개수(애플리케이션 내에서 유지되는 data)
      • EIF(External Interface File) : 외부 인터페이스 개수(다른, 애플리케이션의 ILF,애플리케이션 경계 밖에서 참조)
        
    • 생산성 = FP / 노력
      품질 : 오류 발생률 = 오류의 수 / FP, 결함 발생률 = 결함의 수 / FP
      비용 효율성 = 비용 / FP
    • 문서화 = 문서의 페이지 수 /FP
    • 장점
      • 프로그래밍 언어와 독립적
    • 단점
      • 주관적인 자료에 기초한 계사이며, 숙련된 기술이 요구됨
      • 정보를 수집하기 어렵고, 직접적인 의미를 갖지 못함
      • 사용자 관점이므로 감추어진 EI, EQ, EO를 찾기 어렵고, 사용되는 파일의 수를 정확히 찾기 어려움
    • 적용 방법(간이법)
      • 단계 1 : FP 테이블에 따른 기능 수(FC : Function Count) 계산

기능유형	Count	단순	보통	복잡	기능 수(FC)
외부입력	[ ] *	3	4	6	= [ ]
외부출력	[ ] *	4	5	7	= [ ]
외부조회	[ ] *	3	4	6	= [ ]
내부 논리 파일	[ ] *	7	10	15	= [ ]
외부 인터페이스 파일	[ ] *	5	7	10	= [ ]

   

• 단계 2 : 복잡도 조정 값 계산
  • 14개 기술적 복잡도 요소에 영향도(0~5의 정수로 표시)를 평가하여 합산
  • 총 영향도(0~70) = 항목(14개) * 영향도(0~5)
    --> 기술적 복잡도(TCF) = 0.65 + 0.01 * 총 영향도
  • 14개 요소(통신,분산처리,시스템 성능, 사용빈도, 트랜잭션율, 온라인 요구, 온라인 복잡도, 파일 갱신, 재사용성, 처리 복잡성, 유지보수성, 회복성, 이식성, 분산성)
     
• 단계 3 : FP 계산
  • FP = FC(기능 수) * TCF(기술적 복잡도)
       
• 단계 4 : 경험 데이터를 이용하여 프로젝트 비용과 개발 노력 추정
  프로젝트 비용 = FP * FP당 비용(경험치), 개발노력 = FP / 생산성(경험치)
•    

• Halstead의 소프트웨어 과학(Software Science)
  • 프로그램의 복잡도를 측정하는 방법
  • 소프트웨어의 연산자(Operators)와 피연산자(Operands)의 종류와 수를 사용
  • 4개의 기본 엔터티
    • n1 : 프로그램 내에서 유일한 서로 다른 연산자의 수(종류)
    • n2 : 프로그램 내에서 유일한 서로 다른 피연산자의 수(종류)
    • N1 : 연산자의 총 발생 수
    • N2 : 피연산자의 총 발생 수
  • 파생 엔티티(Deruved Entities)
    • Vocabulary Size : n = n1 + n2
    • 프로그램 길이(Program Length) : N = N1 + N2
    • 프로그램 규모(Program Volume) : V = N log2n
    • 추상화 레벨(Level of Abstraction) : L = (2/n1) * (n2/N2)
    • 소요 공수(Program Effort) : E = V / L
    • Halsted가 제시한 방식의 프로그램 소프트웨어 규모는
      "(연산자 수 + 피연산자 수) X log2(연산자의 종류 + 파연산자의 종류)"
    • 기본 엔터티 도출
    • 파생 엔터티 도출
         
• McCabe의 사이클로메틱 복잡도(Cyclomatic Complexity)
  • McCabe는 프로그램의 이해 난이도는 주로 그 프로그램에 대한 제어 흐름 그래프의 복잡도에 의해서 결정된다는 사실을 관찰
  • 접속 그래프 G의 사이클로 메틱 수는 그래프 내에 있는 일차 독립 경로수이며,
    V(G) = E - n + 2p, (E = 연겨선의 수, n = 노드의 수, p = 접속된 성분의 수)
     
    
  •    
  • 그림에서 V(G)는 5이며, 출력 노드 f에서 입력 노드 a를 연결시키는 점선은 하나의 접속 그래프를 만들기 위해 추가
  • McCabe는 단일 엔트리, 단일 엑시트 구조를 갖는 프로그램에 대해 V는 술어의 수에 1을 더한 것과 같다는 사실을 입증
  • McCabe는 사이클로메틱 복잡도, 테스트의 용이성, 루틴들의 신뢰도 사이에는 강한 상관 관계가 있다고 주장
       

• 전환율 : 웹 사이트 방문자가 제품구매, 회원등록, S/W 다운로드 등 웹 사이트가 의도하는 행동을 취하는 비율