프로젝트 규모 추정

반응형
  • 프로젝트 규모 추정 개요
    • 프로젝트 규모 추정 개념
      • 컴퓨터 기반 시스템에서 소프트웨어는 가장 비싼 요소
      • 소프트웨어 비용, 노력 추정 변수 : 인산, 기술, 환경, 정치
    • 비용과 노력을 추정하기 위한 방법
      • 프로젝트 후반부까지 추정을 지연시킴 : 실질적이지 못함
      • 분해 기술(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 다운로드 등 웹 사이트가 의도하는 행동을 취하는 비율
반응형

'밥벌이 > 소프트웨어 공학' 카테고리의 다른 글

구조적 분석  (0) 2010.10.18
요구사항 명세  (0) 2010.10.18
SOA(Service Oriented Architecture)  (0) 2010.09.20
소프트웨어 개발 방법론  (0) 2010.08.30
구조적 방법론  (0) 2010.08.30