L06-Project Planning (Ch23)

[1] 프로젝트 계획 (Project Planning)

다루는 주제 (Topics covered)

• 소프트웨어 가격 책정 (Software pricing)
• 계획 주도 개발 (Plan-driven development)
• 프로젝트 일정 계획 (Project scheduling)
• 애자일 계획 (Agile planning)
• 추정 기법 (Estimation techniques)
• COCOMO 비용 모델링 (COCOMO cost modeling)

프로젝트 계획 (Project planning)

• 소프트웨어 프로젝트 관리자의 가장 중요한 업무 중 하나이다.
• 프로젝트 계획은 작업을 여러 부분으로 나누고(breaking down), 이를 팀원들에게 할당하며, 발생할 수 있는 문제를 예측하고 이에 대한 임시 해결책을 준비하는 과정이다.
• 프로젝트 시작 시 작성되는 프로젝트 계획은 작업 수행 방식을 팀과 고객에게 전달하고, 프로젝트 진행 상황을 평가하는 데 사용된다.

계획 단계 (Planning stages)

• 제안 단계 (Proposal stage): 소프트웨어 시스템을 개발하거나 제공하기 위한 계약 입찰을 할 때
• 프로젝트 시작 단계 (Startup phase): 누가 프로젝트를 수행할지, 프로젝트를 어떻게 여러 단계로 나눌지, 자원을 어떻게 할당할지를 계획할 때
• 정기적 수정 (Periodically throughout the project): 프로젝트 진행 중 경험과 모니터링 정보를 바탕으로 계획을 수정할 때

제안 계획 (Proposal planning)

• 소프트웨어 요구사항이 개략적으로만 정의된 상태에서 계획이 필요할 수 있다.
  (시스템의 주요 기능이나 목적은 정해졌지만, 세부적인 기술적 사양이나 구현 방식이 구체적으로 확정되지 않은 상태)
• 이 단계의 목표는 설정한 시스템 가격을 고객에게 제시할 수 있도록 정보를 제공하는 것이다.
• 프로젝트 가격 책정은 개발 비용을 추정하는 과정이며, 인건비, 하드웨어 비용, 소프트웨어 비용 등의 요소를 고려해야 한다.

프로젝트 시작 계획 (Project startup planning)

• 이 단계에서는 시스템 요구사항을 더 잘 이해할 수 있지만, 설계나 구현에 대한 정보는 부족하다.
• 프로젝트 예산과 인력 배치를 결정할 수 있도록 충분한 세부 사항을 포함한 계획을 수립해야 한다.
  • 이 계획은 프로젝트 자원 배분 (Project resource allocation)의 기초가 된다.
• 프로젝트 모니터링 메커니즘을 정의해야 한다.
• 애자일 개발 방식에서도 자원 할당을 위해 시작 단계의 계획이 필요하다.

개발 계획 (Development planning)

• 프로젝트 진행 상황에 따라 프로젝트 계획을 정기적으로 수정해야 한다.
• 프로젝트 일정, 비용 추정, 위험 요소를 지속적으로 재검토하고 조정해야 한다.

 

 

 

[2] 소프트웨어 가격 책정 (Software Pricing)

소프트웨어 가격 책정 (Software pricing)

• 단순히 개발 비용 + 개발자의 이익 (그러나 실제로는 단순하지 않음)
• 개발자가 소프트웨어 시스템을 만드는 데 드는 비용을 추정하여 가격을 산정함
  • 하드웨어, 소프트웨어, 출장비, 교육비, 인건비 등을 고려해야 함
• 개발 비용과 고객에게 청구하는 가격 사이에는 단순한 관계가 존재하지 않음
• 조직의 운영 방식, 경제적 요인, 정치적 요소, 비즈니스 전략이 가격 결정에 영향을 줌

소프트웨어 가격에 영향을 미치는 요소 (Factors affecting software pricing)

요소	설명 (사례 상황)
계약 조건	고객이 개발자가 소스 코드의 소유권을 보유하고 이를 다른 프로젝트에 재사용하는 것을 허용할 경우, 소스 코드를 완전히 넘기는 것보다 낮은 가격이 책정될 수 있음
비용 추정 불확실성	비용 추정에 대한 확신이 부족한 경우, 일반적인 이익보다 더 높은 가격을 책정할 수 있음
재정 상태	재정적 어려움을 겪는 개발자는 계약을 따내기 위해 가격을 낮출 수 있음. 어려운 경제 상황에서는 폐업하는 것보다 손익분기점을 맞추는 것이 더 나음. 이익보다 현금 흐름이 더 중요해질 수 있음
시장 기회	새로운 소프트웨어 시장에 진입하기 위해 낮은 가격을 제시할 수 있음. 단기적으로 낮은 이익을 감수하더라도 향후 더 큰 이익을 얻을 기회를 마련할 수 있음. 또한, 해당 프로젝트에서 얻은 경험이 새로운 제품 개발에도 도움을 줄 수 있음
요구사항 변동성	요구사항이 변경될 가능성이 높은 경우, 계약을 따내기 위해 가격을 낮출 수 있음. 계약 체결 후에는 변경된 요구사항에 대해 추가 비용을 청구할 수 있음

 

가격 책정 전략 (Pricing strategies, pricing to win)

• 저가 책정 (Under pricing)
  • 향후 기회를 위해 직원을 유지해야 하는 경우, 계약을 따내기 위해 시스템 가격을 낮출 수 있음
  • 새로운 시장에 진입하기 위해 낮은 가격을 책정할 수 있음
• 가격 인상 (Increased pricing)
  • 고객이 **고정 가격 계약(Fixed-price contract)**을 원할 경우, 예상치 못한 리스크를 대비하기 위해 가격을 높일 수 있음

 

 

 

[3] 계획 주도 개발 (Plan-driven development)

계획 주도 개발 (Plan-driven development)

• 계획 주도(Plan-driven) 또는 계획 기반(Plan-based) 개발은 소프트웨어 개발 프로세스를 세부적으로 계획하는 접근 방식
  • 엔지니어링 프로젝트 관리 기법을 기반으로 하며, 대규모 소프트웨어 프로젝트를 관리하는 전통적인 방식
• 프로젝트 계획에는 수행할 작업, 담당자, 개발 일정, 산출물이 포함됨
• 관리자는 이 계획을 활용하여 프로젝트 의사 결정을 지원하고, 진행 상황을 측정하는 기준으로 삼음

계획 주도 개발의 장점과 단점 (Plan-driven development – pros and cons)

• 장점:
  • 초기에 세부적인 계획을 세우면 인력 가용성, 다른 프로젝트와의 충돌 등을 고려할 수 있음
  • 프로젝트 시작 전에 잠재적인 문제와 종속성을 발견할 수 있음
• 단점:
  • 개발 및 운영 환경의 변화로 인해 초기 결정 사항을 수정해야 하는 경우가 많음

프로젝트 계획 (Project plans)

• 계획 주도 개발에서는 프로젝트 계획(Project plan)을 통해 이용 가능한 자원, 작업 분할, 일정 등을 정의함
• 프로젝트 계획 구성 요소 (Plan sections)
  • 개요 (Introduction)
  • 프로젝트 조직 (Project organization)
  • 위험 분석 (Risk analysis)
  • 하드웨어 및 소프트웨어 자원 요구사항 (Hardware and software resource requirements)
  • 작업 분할 (Work breakdown)
  • 프로젝트 일정 (Project schedule)
  • 모니터링 및 보고 메커니즘 (Monitoring and reporting mechanisms)

3. 보충 프로젝트 계획 (Supplementary project plan)

계획	설명
구성 관리 계획	사용될 구성 관리 절차 및 구조를 설명한다.
배포 계획	소프트웨어 및 관련 하드웨어(필요한 경우)를 고객 환경에 어떻게 배포할지 설명한다. 기존 시스템에서 데이터를 마이그레이션하는 계획도 포함해야 한다.
유지보수 계획	유지보수 요구사항, 비용 및 노력을 예측한다.
품질 계획	프로젝트에서 사용할 품질 절차와 표준을 설명한다.
검증 계획	시스템 검증을 위한 접근 방식, 자원 및 일정을 설명한다.

계획 수립 프로세스 (The planning process)

계획 수립 시 가정 사항 (Planning assumptions)

• 프로젝트 계획을 정의할 때, 낙관적인 가정보다는 현실적인 가정을 해야 한다.
• 프로젝트 진행 중에는 항상 예상치 못한 문제가 발생하며, 이는 프로젝트 지연으로 이어질 수 있다.
• 초기 가정과 일정은 이러한 예기치 않은 문제를 고려해야 한다.
• 계획에 여유 기간(Contingency)을 포함하여, 문제가 발생하더라도 일정이 심각하게 지연되지 않도록 해야 한다.

위험 완화 (Risk mitigation)

• 개발 작업 중 심각한 문제가 발생하여 일정 지연이 예상될 경우, 프로젝트 실패 위험을 줄이기 위해 위험 완화 조치를 수행해야 한다.
• 이러한 조치와 함께 프로젝트를 다시 계획해야 한다.
  • 프로젝트 제약 사항 및 산출물을 고객과 재협상해야 할 수도 있다.
  • 작업 완료 일정을 새로 수립하고 고객과 합의해야 한다.

 

 

 

[4] 프로젝트 일정 관리 (Project scheduling)

프로젝트 일정 관리

• 프로젝트 일정 관리란 프로젝트 작업을 개별 작업으로 분할하고, 이 작업들이 언제 어떻게 실행될지를 결정하는 과정이다.
• 각 작업을 완료하는 데 필요한 기간, 투입 인력 및 담당자를 추정해야 한다.
• 또한, 작업별로 필요한 자원을 추정해야 한다.
  • 예를 들어, 서버의 디스크 공간, 특수 하드웨어(예: 시뮬레이터)에서 소요되는 시간, 출장 예산 등을 고려해야 한다.

프로젝트 일정 관리 활동

• 프로젝트를 개별 작업으로 분할하고, 각 작업을 완료하는 데 필요한 시간과 자원을 추정한다.
• 인력을 최적화하기 위해 작업을 병렬적으로 조직한다.
• 작업 간의 의존성을 최소화하여, 하나의 작업이 완료될 때까지 다른 작업이 대기하는 상황을 방지한다.
• 프로젝트 관리자의 직관과 경험에 따라 일정 계획이 달라질 수 있다.

프로젝트 일정 계획 과정

일정 문제 (Scheduling problems)

• 문제의 난이도를 추정하고 해결 비용을 계산하는 것은 어렵다.
• 생산성은 작업에 참여하는 인원의 수에 비례하지 않는다.
• 프로젝트가 늦어지고 있을 때 인원을 추가하면, 오히려 커뮤니케이션 오버헤드로 인해 더 늦어진다.
• 예상치 못한 일이 항상 발생하므로, 계획에 여유 시간을 포함해야 한다.

일정 표현 (Schedule presentation)

• 프로젝트 일정을 설명하기 위해 일반적으로 그래픽 표기법을 사용한다.
• 프로젝트를 작업 단위로 나누어 표현하며, 개별 작업은 너무 작아서는 안 되며 1~2주 정도의 기간이 적당하다.
• 캘린더 기반 (Calendar-based)
  • 바 차트(Bar charts)는 프로젝트 일정을 표현하는 가장 일반적인 방법이며, 시간에 따른 활동 또는 자원을 나타낸다.
• 활동 네트워크 (Activity networks)
  • 작업 간의 의존성을 보여준다.

프로젝트 활동 (Project activities)

• 프로젝트 활동(작업)은 기본적인 계획 요소이며, 각 활동은 다음을 포함한다.
  • 일정 기간 (일 또는 개월 단위)
  • 인력 투입 예상치 (인-일 또는 인-월 단위)
  • 완료 기한
  • 명확한 종료 기준 (예: 문서 작성, 리뷰 미팅 개최, 모든 테스트의 성공적 실행 등)

마일스톤과 산출물 (Milestones and deliverables)

• 마일스톤은 프로젝트 일정에서 진행 상황을 평가할 수 있는 지점을 의미하며, 예를 들어 시스템을 테스트 팀에 인도하는 시점이 될 수 있다.
• 산출물은 고객에게 전달되는 작업 결과물이며, 예를 들어 시스템의 요구사항 문서가 포함된다.

작업, 기간 및 의존성 (Tasks, durations, and dependencies)

작업	노력(인-일)	기간(일)	의존성
T1	15	10
T2	8	15
T3	20	15	T1 (M1)
T4	5	10
T5	5	10	T2, T4 (M3)
T6	10	5	T1, T2 (M4)
T7	25	20	T1 (M1)
T8	75	25	T4 (M2)
T9	10	15	T3, T6 (M5)
T10	20	15	T7, T8 (M6)
T11	10	10	T9 (M7)
T12	20	10	T10, T11 (M8)

활동 바 차트 (Activity bar chart)

인력 배정 차트 (Staff allocation chart)

다양한 도구 (Various tools)

• Basecamp
• Asana
• Trello
• Monday.com
• Microsoft Project
• Spreadsheet(?)
• ...

 

 

 

[5] 애자일 계획 (Agile planning)

애자일 계획 (Agile planning)

• 애자일 소프트웨어 개발 방법은 반복적 접근 방식이며, 소프트웨어를 점진적으로 개발하여 고객에게 제공한다.
• 계획 기반 접근 방식과 달리, 각 증분(Increments)의 기능은 사전에 계획되지 않고 개발 과정에서 결정된다.
  • 증분에 포함할 기능은 진행 상황과 고객의 우선순위에 따라 결정된다.
• 고객의 요구사항과 우선순위는 변경될 수 있으므로, 이러한 변경을 수용할 수 있는 유연한 계획이 필요하다.

 

 

 

[6] 견적 기법 (Estimation techniques)

견적 기법 (Estimation techniques)

• 조직에서는 소프트웨어 개발에 필요한 노력과 비용을 추정해야 한다. 이를 위한 두 가지 기법이 있다.
  • 경험 기반 기법 (Experience-based techniques)
    • 관리자가 과거 프로젝트와 해당 도메인의 경험을 바탕으로 미래의 노력 요구 사항을 추정한다.
    • 본질적으로 관리자는 과거 경험을 바탕으로 판단하여 노력 요구 사항을 예측한다.
  • 알고리즘 기반 비용 모델링 (Algorithmic cost modeling)
    • 제품의 속성(예: 크기)과 프로세스 특성(예: 개발자의 경험) 등의 요소를 사용하여 수학적 공식을 통해 프로젝트 노력을 계산한다.

추정의 불확실성 (Estimate uncertainty)

경험 기반 접근법 (Experience-based approaches)

• 경험 기반 기법은 과거 프로젝트에서 수행된 소프트웨어 개발 활동과 소요된 노력을 기반으로 판단한다.
• 일반적으로 프로젝트에서 생산해야 할 산출물과 개발할 소프트웨어 구성 요소 또는 시스템을 식별한다.
• 이를 스프레드시트 등에 문서화하고, 개별적으로 추정한 후 총 소요 노력을 계산한다.
• 여러 사람이 참여하여 개별적인 추정을 공유하고 설명하도록 하면 추정의 신뢰도를 높일 수 있다.

경험 기반 접근법의 문제점 (Problem with experience-based approaches)

• 경험 기반 기법의 문제는 새로운 소프트웨어 프로젝트가 이전 프로젝트와 유사하지 않을 수 있다는 점이다.
• 소프트웨어 개발 환경은 빠르게 변화하며, 웹 서비스, 애플리케이션 시스템 설정, HTML5 등 새로운 기술을 사용할 수 있다.
  • 이러한 기술을 다뤄본 경험이 없다면, 기존 경험이 노력 추정에 도움이 되지 않을 수 있어 정확한 비용과 일정 추정이 어려워진다.

알고리즘 기반 비용 모델링 (Algorithmic cost modelling)

• 비용은 다음과 같은 요소를 기반으로 수학적 함수로 추정된다.
  • A: 조직별 상수 (예: 소프트웨어 유형)
  • Size: 코드 크기에 대한 평가
  • B: 소프트웨어 복잡도 또는 기능성 평가 (1~1.5)
  • M: ㅌ
• Effort = A × (Size^B) × M
• 비용 추정에서 가장 일반적으로 사용되는 제품 속성은 코드 크기(SLOC: Source Lines of Code, 소스 코드 라인 수)이다.
• 대부분의 모델은 유사하지만, A, B, M 값이 다를 수 있다.

추정 정확도 (Estimation accuracy)

• 소프트웨어 시스템의 크기는 개발이 완료된 후에야 정확히 알 수 있다.
• 최종 크기에 영향을 미치는 요인:
  • 재사용된 시스템 및 구성 요소 사용 여부
  • 프로그래밍 언어
  • 시스템 배포 방식
• 개발이 진행될수록 크기 추정의 정확도가 높아진다.
• B와 M 요소는 추정자의 주관적인 판단에 따라 다를 수 있다.

알고리즘 모델의 효과성 (Effectiveness of algorithmic models)

• 알고리즘 기반 비용 모델은 시스템 개발에 필요한 노력을 체계적으로 추정할 수 있다. 하지만, 이 모델들은 복잡하고 사용하기 어렵다.
• 속성이 많고, 각 속성의 값을 추정하는 데 불확실성이 크다.
  • 이러한 복잡성 때문에 알고리즘 기반 비용 모델링은 주로 대형 기업에서 활용되며, 특히 국방 및 항공우주 시스템 엔지니어링 분야에서 많이 사용된다.

 

 

 

[7] COCOMO 비용 모델링

COCOMO 비용 모델링

• 프로젝트 경험을 기반으로 한 실증적 모델
• 특정 소프트웨어 벤더에 종속되지 않은 독립적인 모델로 잘 문서화됨
• 1981년 최초 버전(COCOMO-81)부터 시작하여 여러 버전을 거쳐 COCOMO 2까지 발전
• COCOMO 2는 다양한 소프트웨어 개발 방식, 재사용 등을 반영

COCOMO 2 모델

• COCOMO 2는 점점 더 상세한 소프트웨어 비용 추정치를 제공하는 여러 하위 모델을 포함
• 하위 모델:
  • 애플리케이션 구성 모델: 기존 구성 요소를 조합하여 개발할 때 사용
  • 초기 설계 모델: 요구사항이 정해졌지만 설계가 시작되지 않은 경우 사용
  • 재사용 모델: 재사용 가능한 구성 요소를 통합하는 데 필요한 노력 계산
  • 아키텍처 이후 모델: 시스템 아키텍처가 결정되고 추가 정보가 제공된 후 사용

COCOMO 비용 추정 모델

애플리케이션 포인트 생산성

개발자의 경험과 역량	매우 낮음	낮음	보통	높음	매우 높음
ICASE 성숙도와 역량	매우 낮음	낮음	보통	높음	매우 높음
PROD (NAP/월)	4	7	13	25	50

• ICASE: 통합 컴퓨터 지원 소프트웨어 엔지니어링 (Integrated Computer-Aided Software Engineering)

애플리케이션 구성 모델

• 프로토타입 프로젝트 및 재사용이 많은 프로젝트 지원
• 공식:
  • PM = ( NAP × (1 - %reuse/100 ) ) / PROD
    • PM: 인월(person-month) 단위의 노력
    • NAP: 애플리케이션 포인트 개수
    • PROD: 생산성

초기 설계 모델

• 요구사항이 확정된 이후 추정 가능
• 알고리즘 모델의 표준 공식 기반
• PM = A × Size^B × M
  • M = PERS × RCPX × RUSE × PDIF × PREX × FCIL × SCED
  • A = 초기 보정값에서 2.94
  • Size = KLOC(천 단위 코드 라인)
  • B = 프로젝트의 혁신성, 개발 유연성, 위험 관리, 프로세스 성숙도 등에 따라 1.1~1.24 범위

곱셈 계수 (Multipliers)

• 개발자 역량, 비기능 요구사항, 개발 플랫폼에 대한 친숙도 등을 반영
  • RCPX: 제품 신뢰성과 복잡성
  • RUSE: 필요한 재사용 정도
  • PDIF: 플랫폼 난이도
  • PREX: 개발자의 경험
  • PERS: 개발자의 역량
  • SCED: 요구되는 일정
  • FCIL: 팀 지원 시설

재사용 모델

• 변경 없이 재사용되는 블랙박스 코드와 통합을 위해 수정이 필요한 코드 반영
• 두 가지 유형 존재:
  • 블랙박스 재사용: 코드 변경 없이 사용 → 필요한 노력(PM) 계산
  • 화이트박스 재사용: 코드 수정 후 사용 → 새 코드 크기(KLOC) 계산 후 비용 조정

재사용 모델 추정 1

• 생성된 코드의 경우:
• PM = (ASLOC × AT/100) / ATPROD
  • ASLOC: 생성된 코드 라인 수
  • AT: 자동 생성 코드의 비율(%)
  • ATPROD: 엔지니어의 코드 통합 생산성

재사용 모델 추정 2

• 코드를 이해하고 통합해야 하는 경우:
• ESLOC = ASLOC × (1 - AT/100) × AAM
  • ESLOC: 새 코드에 해당하는 소스 코드 라인 수
  • AAM: 코드 변경, 코드 통합 이해, 재사용 결정 비용을 반영한 조정 계수

아키텍처 이후 모델

• 초기 설계 모델과 동일한 공식을 사용하지만 7개가 아닌 17개의 곱셈 계수 포함
• 코드 크기 추정 방식:
  • 새로 개발할 코드 라인 수
  • 재사용 모델을 기반으로 변환한 신규 코드 라인 수ㅌ
  • 요구사항 변경에 따라 수정해야 할 코드 라인 수

지수 항(B) 계산

5가지 규모 요인에 따라 결정 (다음 표 참고)

• 이들의 합을 100으로 나눈 후 1.01을 더해 결정
• 예제: 새로운 도메인에서 프로젝트 수행, 클라이언트가 개발 프로세스 미정의, 위험 분석 없음, CMM 레벨 2
  • 선례성(Precedentedness): 새로운 프로젝트(4)
  • 개발 유연성(Development flexibility): 클라이언트 미참여 - 매우 높음(1)
  • 아키텍처/위험 해결: 위험 분석 없음 - 매우 낮음(5)
  • 팀 응집력(Team cohesion): 새로운 팀 - 보통(3)
  • 프로세스 성숙도(Process maturity): 일부 통제 가능 - 보통(3)
• 규모 요인(B) = 1.17 (16/100 + 1.01)

아키텍처 이후 모델에서 지수 계산에 사용되는 규모 요인

규모 요인	설명
아키텍처/위험 해결	수행된 위험 분석의 정도 반영. '매우 낮음'은 분석이 거의 없고, '매우 높음'은 철저한 분석을 의미
개발 유연성	개발 프로세스의 유연성 반영. '매우 낮음'은 정해진 프로세스, '매우 높음'은 클라이언트가 목표만 설정하는 경우
선례성	조직이 해당 유형 프로젝트를 경험한 정도. '매우 낮음'은 경험 없음, '매우 높음'은 완전한 숙련
프로세스 성숙도	조직의 프로세스 성숙도 반영. CMM 성숙도 설문지에 따라 측정되며, 일반적으로 CMM 레벨을 5에서 빼서 추정
팀 응집력	개발 팀의 협업 수준 반영. '매우 낮음'은 협업 어려움, '매우 높음'은 원활한 협업

곱셈 계수 (Multipliers)

• 제품 속성(Product attribute)
  • 개발 중인 소프트웨어의 필수 특성
• 컴퓨터 속성(Computer attributes)
  • 하드웨어 플랫폼에 의해 강제되는 제약사항
• 개인 속성(Personnel attributes)
  • 프로젝트에 참여하는 인원의 경험과 역량 반영
• 프로젝트 속성(Project attributes)
  • 특정 소프트웨어 개발 프로젝트의 특성 반영

비용 결정 요인이 노력 추정에 미치는 영향

항목값	1.17
시스템 크기(재사용 및 요구사항 변동성 요소 포함)	128,000 DSI (전달된 소스 명령어)
비용 요인 없는 초기 COCOMO 추정치	730 인-월
신뢰성	매우 높음, 승수 = 1.39
복잡성	매우 높음, 승수 = 1.3
메모리 제약	높음, 승수 = 1.21
도구 사용	낮음, 승수 = 1.12
일정	가속됨, 승수 = 1.29
조정된 COCOMO 추정치	2,306 인-월

항목값	1.17
신뢰성	매우 낮음, 승수 = 0.75
복잡성	매우 낮음, 승수 = 0.75
메모리 제약	없음, 승수 = 1
도구 사용	매우 높음, 승수 = 0.72
일정	일반적, 승수 = 1
조정된 COCOMO 추정치	295 인-월

 

프로젝트 기간과 인력 배치

• 노력 추정과 더불어, 관리자는 프로젝트 완료에 필요한 일정 기간과 인력 배치 시점을 추정해야 한다.
• 일정 기간은 COCOMO 2 공식으로 추정할 수 있다.
  • TDEV = 3 × (PM)의 (0.33+0.2*(B-1.01))승
  • TDEV: 프로젝트의 표준 일정
  • PM은 노력 계산값이며, B는 위에서 설명한 대로 계산된 지수(B는 초기 프로토타이핑 모델의 경우 1)이다. 이 계산은 프로젝트의 표준 일정을 예측한다.
• 프로젝트 수행에 필요한 시간은 프로젝트에 참여하는 인원 수와 독립적이다.

인력 요구 사항

• 인력 요구 사항은 개발 기간을 일정으로 나누어 계산할 수 없다.
• 프로젝트에 참여하는 인원 수는 프로젝트 단계에 따라 달라진다.
• 프로젝트에 참여하는 인원이 많아질수록 일반적으로 총 노력량도 증가한다.
• 인력을 너무 빠르게 확충하면 일정 지연과 연관될 가능성이 크다.

핵심 사항

• 시스템의 가격은 단순히 개발 비용과 개발 회사의 이윤만으로 결정되지 않는다. 조직적 요인에 따라 위험 증가를 보상하기 위해 가격이 상승하거나, 경쟁력을 확보하기 위해 가격이 낮아질 수 있다.
• 소프트웨어는 종종 계약을 따내기 위해 가격이 책정되며, 이후 시스템 기능이 해당 가격에 맞게 조정된다.
• 계획 기반 개발은 프로젝트 활동, 예상 노력, 활동 일정 및 각 활동의 책임자를 정의하는 완전한 프로젝트 계획을 중심으로 조직된다.
• 프로젝트 일정 관리는 프로젝트 계획의 일부를 다양한 그래픽 표현으로 구성하는 것을 포함한다. 활동 기간과 인력 배치 일정을 보여주는 바 차트가 가장 일반적으로 사용된다.
• 프로젝트 마일스톤은 특정 활동 또는 활동 집합의 예측 가능한 결과를 의미하며, 각 마일스톤에서는 진행 상황에 대한 공식 보고서가 경영진에 제출되어야 한다. 납품물은 프로젝트 고객에게 전달되는 작업 결과물이다.
• 애자일 계획 게임은 전체 팀이 프로젝트 계획에 참여하는 방식으로 진행된다. 계획은 점진적으로 개발되며, 문제가 발생하면 기능을 축소하여 일정 지연을 방지한다.
• 소프트웨어 추정 기법은 경험 기반(관리자가 필요한 노력을 판단) 또는 알고리즘 기반(추정된 프로젝트 매개변수를 바탕으로 노력량을 계산)으로 나뉜다.
• COCOMO II 비용 모델은 성숙한 알고리즘 기반 비용 모델로, 프로젝트, 제품, 하드웨어 및 인력 속성을 고려하여 비용을 추정한다.