프로젝트 계획
- 누가, 언제, 무엇을, 어떻게 할 것인가를 사전에 결정하는 작업
- 특정한 목적을 달성하기 위하여 개발 계획 프로그램을 수립하고, 프로그램의 분석, 구현 등의 작업을 수행하는 것
- 프로젝트 계획은 관리자가 자원, 비용, 일정을 합리적으로 측정할 수 있는 체계를 제공
- 그 목적은 합리적 측정을 위한 정보발견 과정을 통해 달성
핵심 관리 대상
- 3P：사람(people), 프로세스(process), 문제(problem)
- 4P：사람(people), 프로세스(process), 제품(product), 프로젝트(project)
문제 정의
- 문제 정의: 개발의 첫 단계는 무엇을 개발할 것인가를 명확히 정의하고 개발을 계획하는 일
- 목표의 설정 : 사용자의 업무 현황을 조사․분석하고 현재 정보처리 문제점과 제약 사항을 파악
타당성 분석
- 경제적 타당성: 투자 효율성, 개발비용이나 경비 절감 → 개발 우선순위 결정
- 기술적 타당성: 사용자가 요구하는 기능과 성능의 제공 가능성 타진
- 법적 타당성: 지적 소유권, 프로그램 보호법
소프트웨어 범위
- 기능
- 성능
- 제한 조건
- 개발 인원
- 일정 계획
프로젝트 범위 관리 프로세스
- 요구사항 수집: 요구사항 수집은 프로젝트의 목표를 이루기 위해 이해관계자(stakeholder)의 요구사항을 정의하고 문서화하는 활동
- 범위 정의: 프로젝트의 범위를 기술하는 활동
- 작업 분류 체계(WBS) 작성: WBS는 프로젝트 팀에서 프로젝트의 목표를 달성하기 위해 수행해야 할 작업을 산출물 중심으로 계층적으로 작성한 구조
- 범위 검증 (Scope Verification): 프로젝트 범위 관련 산출물에 대하여 고객이나 스폰서 등 이해관계자가 검토하는 활동
- 범위 통제 (Scope Control): 프로젝트 범위에 대한 기준선 문서의 변경이 발생할 때 범위의 상태를 감시하고 변경을 통제하는 활동
비용추정
- 얼마나 노력이 들어가느냐, 결국 개발 비용을 추정하는 것
- 소프트웨어 개발 비용 예측
- 정확한 비용 예측은 매우 어려움
- 알려지지 않은 요소가 산재
- 에러 발생, 성능 저하, 엔지니어의 이직 등
- 원가의 계산이 어려움 (인건비 추정이 어려움)
- 과거의 (경험적) 데이터가 필요
예산
- 인건비 : MM(Man-Month, 인원/월)를 기초
- 경비 : 여비, 인쇄비, 재료비, 회의비, 공공요금 등
- 간접 경비 : 오버헤드(overhead)
- 회사에는 회계, 기획, 경영 등 많은 파트가 있음
비용에 영향을 주는 요소
- 제품의 크기 : 제품의 크기가 커짐에 따라 비용은 기하급수로 늘어남
- 제품의 복잡도: 응용 : 개발지원 : 시스템 = 1 : 3 : 9
- 프로그래머의 자질: 코딩, 디버깅의 능력차, 프로그래밍 언어, 응용 친숙도
- 요구되는 신뢰도 수준 : MTBF(Mean Time Between Failure)
- 기술 수준 : 개발 장비, 도구, 조직능력, 관리, 방법론 숙달
프로젝트 비용을 예측하는 방법
상향식 (Bottom-up)
- 작업에 소요되는 기간을 구하고, 여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건비를 계산
- 장점 : 작업에 드는 노력을 일일이 계획할 수 있음
- 단점 : 개인의 주관에 의한 추정이 될 가능성이 많음
하향식 (Top-down)
- 프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정
- 프로그램의 규모, LOC (Lines of code), 기능 점수 (Function Point) 등을 고려
COCOMO (COnstructive COst MOdel)
- Boehm이 제안한 원시 프로그램의 규모에 의한 비용예측 모형
- 완성될 규모의 LOC(lines of code)를 추정하고, 이를 준비된 식에 대입하여 소요 MM을 예측
- 제품의 복잡도(LOC)에 따른 분류
| 소프트웨어 유형 | 기본 공식 | ||
| 유형 | 설명 | MM | 개발기간 (TDEV) |
| Organic 프로젝트 (유기적, 조직형) |
50 KDSI(5만 라인) 이하의 프로젝트 | 2.4 × [KDSI]^1.05 | 2.5 × [MM]^0.38 |
| 일반 응용(업무) 프로그램 | |||
| Semidetached 프로젝트 (반 내장형) |
300 KDSI 이하의 프로젝트 | 3.0 × [KDSI]^1.12 | 2.5 × [MM]^0.35 |
| 트랜잭션 처리 시스템, OS, DBMS 등 | |||
| Embedded 프로젝트 (내장형) |
300 KDSI 이상의 프로젝트 | 3.6 × [KDSI]^1.20 | 2.5 × [MM]^0.32 |
| 하드웨어가 포함된 실시간 시스템, 미사일 유도, 신호기 제어 시스템 등 | |||
- KDSI : Kilo Delivered Source Instruction
- 입력 값으로 추정치에 해당함
- LOC : Lines of code → 1 KDSI = 1,000 LOC
- MM : Man-Month
- TDEV : Total DEVelopment time
- 궁극적으로 파악해야 하는 값
COCOMO 방법의 보정(Scaling)
- 기본 방법에 제품의 성격, 목표 시스템의 특성, 개발 구성원의 특성, 프로젝트 자체의 성격 등에 따라 보정
- 프로그램의 경험이 많다면 노력 예측값은 더 작아져야 함
- 실시간 처리 요구가 있다면 예측값은 더 커져야 함
- 노력 승수: 여러 조건을 고려하여 기본 방법(MM)에 곱하는 상수값
- 노력 승수에 영향을 미치는 요소
- 제품의 특성: 신뢰성에 대한 요구나 문제의 복잡도, 데이터베이스의 크기 등
- 컴퓨터 실행 : 수행 시간의 제약, 주기억장치의 제약, H/W 및 S/W의 안전성 등
- 개발자의 특성: 개발자의 응용 분야 경험 유무, 프로그래밍 언어에 대한 익숙도 등
- 프로젝트: 복잡한 소프트웨어 도구 사용이 필요한가?
- 노력 승수 테이블 예시
COCOMO II
- 1995년에 발표
- 소프트웨어 개발 프로젝트가 진행된 정도에 따라 세 가지의 다른 모델을 제시
- 각 단계에 따라 다른 계산법을 적용
- 제 1 단계: 프로토타입을 만드는 단계
- 제 2 단계: 초기 설계 단계
- 제 3 단계: 구조 설계 이후 단계
기능 점수 방법
- Function Points
- 정확한 라인 수는 예측 불가능 (COCOMO 적용이 어려움)
- 입력, 출력, 질의, 화일, 인터페이스의 개수로 소프트웨어의 규모를 나타냄
- 각 기능에 가중값이 기본이고, 복잡도에 따라 세분화함
- 총 라인 수 = FP x 원하는 언어의 1점당 LOC
- 개발 노력 = 총 라인 수 / 생산성(LOC/MM)
- 가중값
- 입력 개수: 사용자가 시스템에 제공하는 입력자료의 개수
- 출력 개수: 시스템이 사용자에게 제공하는 출력 자료의 개수
- 질의 개수: 사용자가 제공하는 대화형 질의의 개수
- 파일 개수: 시스템이 저장 및 관리하는 파일의 개수
- 인터페이스 개수: 다른 시스템과의 인터페이스 개수
