블로그 이미지
생각처럼

카테고리

전체보기 (209)
TOOL (1)
다이어리 (1)
Bit (200)
HELP? (0)
Total
Today
Yesterday

달력

« » 2025.2
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28

공지사항

태그목록

최근에 올라온 글

출처 탐구생활 | 크레파스
원문 http://blog.naver.com/sharon0a/110048932554

1. 소프트웨어 개발비용 산정 개요

 가. 개발비용 산정의 정의

  - 소프트웨어 규모파악(양적인 크기, 질적인 수준)을 통한 소요공수와 투입자원 및 소요기간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정

  - 발주자가 프로젝트 발주시 예정가격의 산정과 개발업자가 수주한 개발 용역에 대하여 적정한 대가를 산정할 수 있는 기준

  - 단위작업공수(비용)를 통한 총공수(총비용) 산정

 나. 규모산정의 의의

  - 소프트웨어 개발 프로젝트 계획 수립시의 소요 비용 및 기간의 산출

  - 아웃소싱 계약시의 계약 근거

 

2. 개발비용 산정시 고려요소

 가. 프로젝트 요소들

  - 문제의 복잡도(난이도, 유형)

  - 시스템크기(입출력 양식 수)

  - 시스템신뢰도(정확성, 견고성, 완전성, 일관성)

 나. 자원 요소들

  - 인적자원(관리자, 개발자, 지원체계)

  - 하드웨어자원(개발장비, 운영장비), 소프트웨어자원(개발지원 도구)

 다. 생산성 요소들

  - 개발자능력(경험, 전문지식 습득 정도)

  - 개발방법론(최신기법, 관리 방법론)

 

3. 소프트웨어 규모산정 방법

 가. 양적 규모산정 방식 - LOC(Line Of Code)근거

  1) LOC정의

   - 크기 중심 소프트웨어 측정기준으로 직접 소프트웨어 코드의 라인 수를 측정하는 방식

   - 라인수 혹은 개발별 M/M를 예측하여 이를 비용으로 변환시키는 방식

  2) 산정방법

   - 생산성 = KLOC/노력(M/M), 품질 = 오류의 수/KLOC

   - 비용 = 원/KLOC

   - 장점 : 측정하기 쉽고 이해하기 쉬움, 기존의 많은 프로젝트 측정모델들을 주요입력으로 LOC를 이용하고 있음,

              LOC를 중심으로 예측하는 자료들이 충분히 존재

   - 단점 : LOC측정은 프로그래밍 언어에 의존, LOC척도는 잘 설계된 그리고 짧은 프로그래밍일수록 불리,

             개발초기의 계획 및 분석단계에서 정확난 LOC를 측정하는것은 불가능

  3) 양적 규모산정 방식 종류

   - Doty Model : 통계를 바탕으로 규모가 대강 알려졌을 때 사용, 라인수가 상수 제곱

                        인터뷰와 문헌을 바탕으로 개발한 모델로 프로그램 규모가 알려졌다는 전제하에 총공수를 구하는 방법

                        총공수(MM): 상수*프로그램 규모(I) (규모(I) = 소스코드 라인수)

   - Putman Model(생명주기 예측 모델) : 가설을 젠제로 한 모델(대규모 연구개발 프로젝트에 적용된 모델을 기초)

   - COCOMO Model(COnstruction COst MOdel) : Boehm에 의해 63종류의 프로젝트 데이터에 기초하여 작성된 경험적인 소프트웨어 비용 견적모델

  ※ LOC기반 추정은 일단 소프트웨어를 모듈별로 분류하고 가중치를 이용하여 합리적인 LOC추정값을 얻음

 나. 양과 질을 고려한 규모산정 방식

  프로젝트 특성을 이용하여 간접적으로 규모와 복잡도를 산정하는 방식

  1) 기능점수(Function Point)

   - 정보 처리 규모와 기술의 복잡도 요인에 의하여 소프트웨어 규모 산정 방식

   - 소프트웨어의 양과 질을 동시에 고려한 방식

   - 최종 사용자 입장에서 소프트웨어 규모를 견적하는 방식

  2) Halstead의 소프트웨어 과학(Software Science)

   - 소프트웨어 규모와 난이도에 대한 척도를 이용하여 개발소요 공수 예측모형 제시 계산 공식

  3) McCabe의 회전 복잡도(Cyclomatic Complexity) 계산 공식

   - 회전복잡도 = 의사결정수 + 조건수 + 1

     의사결정수 : if then else, do while, do until 등의 의사결정 개수

     조건수 : and, or, not 등의 조건수

 

4. 소프트웨어 개발비용 산정방법의 종류

 가. 하향식 산정방법(to-down)

  일반적으로 가장 많이 사용하는 방법이며, 경험과 전문지식이 많은 개발자들이 참여한 회의에서 토론을 통하여 산정

  1) 전문가의 판단(expert judgment)

   - 소프트웨어 개발 기술에 관한 경험이 많은 전문가의 판단에 따라 비용을 산출하는 방법 - 2명 이상의 전문가에게 의뢰

   -  사소한 문제로 인한 결정이나 그룹 내의 한 사람에 의한 독단으로 가면 문제가 발생

  2) 델파이(Delphi)식 산정방법

   - 회의의 부작용을 방지하면서 전문가의 의견 일치를 얻기 위하여 1948년 랜드사(Rand Co.)에서 개발

   - 전문가의 판단 방법의 단점을 보완한 방법

   - 전문가들이 편견이나 분위기에 지배받지 않도록 조정자(coordinator)를 필요

 

 

 나. 상향식 산정방법(bottom-up)

  하향식 방법의 비과학성을 보완하기 위하여 개발할 시스템을 WBS로 정의하고, 각 구성요소에 대한 산정을 독립적으로 실시한 후 이를 합산하는 방식

  1) 원시코드 라인수 기법

   - WBS상에서 분해된 시스템의 기능들을 각각 필요한 원시코드 라인수로 산정

   - 가장 효율적인 방안은, 프로젝트 관리 목적으로 대두된 PERT(Project Evaluation and Review Technique)의 예측공식을 이용하는 것

   - 확률론에서 배타분포도에 근거하여 낙관치(optimistic estimate), 기대치(most likely estimate) 및 비관치(pessimistic estimate)의

      확률적 집합으로 예측치(expected value)와 이의 편방편차(variance)를 산출

  2)개발단계별 노력산정 기법

   - 시스템의 각 기능의 구현에 필요한 노력을 각 생명주기의 단계별로 산정하여 원시코드 라인수 기법보다 더 정확성ㅇ르 기하자는 것

   - 개발비 산정에 반영시키는 목적

 

5. 소프트웨어 개발비용 산정의 문제점 및 개선 방안

 가. 문제점

  - step수를 근간으로 한 산정이므로 산출이 어려움

  - 산정된 금액이 너무 높아서 실제 사용이 어려움

  - 정부의 최저 입찰제 구매 방식 때문에 제대로 적용되지 않음

 나. 개선방안

  - 정확하고 객관적, 일관성있는 소프트웨어 규모 산정을 위해 소프트웨어 규모 측정 표준화

  - 기능점수 모형은 기능수 계산을 대폭 축소하고 복잡도 계산의 객관성을 높여야 함

  - 정보시스템 컨설팅 및 제안서 작성에 대한 비용 산정 기준의 마련

Posted by 생각처럼
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함