[SE] L06 - 요약

프로젝트 계획

1) 과정

(1) 작업을 여러 부분으로 나누고, 이를 팀원들에게 할당한다.

(2) 이를 통해 발생할 수 있는 문제를 예측하고, 이에 대한 임시 해결책을 준비한다.

2) 목적

(1) 작업 수행 방식을 팀과 고객에게 전달한다.

(2) 프로젝트 진행 상황을 평가하는데 사용된다.

계획 단계

: 계획 단계는 제안 계획, 프로젝트 시작 계획, 개발 계획 총 세 단계로 나누어진다.

1) 제안 단계

: 소프트웨어 시스템을 개발하거나 제공하기 위한 계약 입찰 과정

(1) 상황

: 소프트웨어 요구사항만 간단하게 작성된 상태

(2) 목표

: 설정한 시스템 가격을 고객에게 제시할 수 있도록 정보를 제공하는 것

(3) 가격 책정

: 개발 비용을 추정하는 과정 (인건비, 하드웨어 비용, 소프트웨어 비용 등의 요소를 고려)

2) 프로젝트 시작 단계

(1) 결정 사항

• 누가 프로젝트를 시작할지 결정
• 프로젝트를 어떻게 여러 단계로 나눌지 결정
• 자원을 어떻게 할당할지 결정

(2) 문제점

: 시스템 요구사항을 더 잘 이해할 수 있지만, 설계나 구현에 대한 정보는 부족하다.

(3) 할 일

• 프로젝트 예산과 인력 배치를 결정할 수 있도록, 충분한 세부 사항을 포함한 계획을 수립하기
  • 이 계획은 프로젝트 자원분배의 기초가 된다.
• 프로젝트 모니터링 메커니즘을 정의하기
  • 프로젝트 진행 상황을 추적하고 평가할 수 있는 체계를 마련하는 것

(4) 특징

: 애자일 개발 방식에서도 자원 할당을 위해 시작 단계의 계획이 필요하다.

3) 전반적인 프로젝트의 정기적 수정

: 경험과 진행 상황을 반영하여 계획을 수정하는 과정

(1) 할 일

• 프로젝트 계획을 정기적으로 수정하기
• 프로젝트 일정, 비용 추정, 위험 요소를 지속적으로 재검토하고 조정하기

소프트웨어 가격 책정

1) 의미 및 방식

• 단순하게 보면, 개발 비용과 개발자의 이익을 합친 가격이다.
• 소프트웨어 시스템을 만드는 데 드는 비용을 추정하여 가격을 산정한다.
• 개발 비용과 고객에게 청구하는 가격 사이에는 단순한 관계가 존재하지 않는다.
• 조직의 운영 방식, 경제적 요인, 정치적 요소, 비즈니스 전략이 가격 책정에 영향을 준다.

2) 고려할 점

: 하드웨어, 소프트웨어, 출장비, 교육비, 인건비 등을 고려한다.

소프트웨어 가격에 영향을 미치는 요소

1) 계약 조건

: 고객이 개발자가 소스 코드의 소유권을 보유하고, 이를 재사용하는 것을 허용할 경우, 소스 코드를 완전히 넘기는 것보다 낮은 가격이 책정될 수 있다.

2) 비용 추정의 불확실성

: 비용 추정에 대한 확신히 부족한 경우, 일반적인 이익보다 더 높은 가격을 책정할 수 있다.

3) 재정 상태

• 재정적 어려움을 겪는 경우, 계약을 따내기 위해 가격을 낮출 수 있다.
• 어려운 경제 상황에서는 폐업보다는 손익 분기점을 맞추는 것이 더 낫다.
• 이익보다 현금 흐름이 더 중요할 수 있다.

4) 시장 기회

• 새로운 시장에 진입하기 위해 낮은 가격을 제시할 수 있다.
• 단기적으로 낮은 이익을 감수해도, 향후 더 큰 이익을 얻을 기회를 마련할 수 있다.
• 해당 프로젝트에서 얻은 경험이 새로운 제품 개발에도 도움을 줄 수 있다.

5) 요구사항 변동성

요구사항이 변경될 가능성이 높은 경우, 계약을 따내기 위해 가격을 낮출 수 있다.

• 계약 체결 후에는 변경된 요구사항에 대해 추가 비용을 청구할 수 있다.

가격 책정 전략

1) 저가 책정

(1) 예시1 : 기회를 위해 직원을 유지해야 하는 경우, 계약을 따내기 위해

(2) 예시2 : 새로운 시장에 진입하기 위해

2) 가격 인상

(1) 고객이 고정 가격 계약을 원할 경우, 프로젝트 예상치 못한 리스크를 대비하기 위해

계획 주도(기반) 개발

1) 의미

: 소프트웨어 개발 프로세스를 세부적으로 계획하는 접근 방식

2) 특징

(1) 엔지니어링 프로젝트 관리 기법을 기반으로 한다.

(2) 대규모 소프트웨어 프로젝트를 관리하는 전통적인 방식이다.

(3) 관리자는 이 계획을 활용하여 프로젝트 의사 결정을 지원하고, 진행 상황을 측정하는 기준으로 삼는다.

3) 포함될 내용

(1) 수행할 작업 / 담당자 / 개발 일정 / 산출물

4) 장점

(1) 초기에 세부적인 계획을 세우면, 인력 가용성과 다른 프로젝트와의 충돌 등을 고려할 수 있다.

(2) 프로젝트 시작 전에, 잠재적인 문제와 종속성을 발견할 수 있다.

5) 단점

(1) 개발 및 운영 변화로 인해, 초기 결정 사항을 수정해야 하는 경우가 많다.

프로젝트 계획 구성 요소

• 개요 : 프로젝트의 목표와 범위를 간략히 설명한다.
• 프로젝트 조직 : 역할과 책임을 정의하고 팀 구성을 설명한다.
• 위험 분석 : 프로젝트 진행 중 발생할 수 있는 위험 요소를 식별하고 대응 방안을 마련한다.
• 하드웨어 및 소프트웨어 자원 요구사항 : 개발 및 운영에 필요한 장비와 소프트웨어를 정리한다.
• 작업 분할 : 프로젝트를 작은 단위의 작업으로 나누고 각 작업의 책임을 지정한다.
• 프로젝트 일정 : 주요 마일스톤과 작업 일정, 마감 기한을 계획한다.
• 모니터링 및 보고 메커니즘 : 프로젝트 진행 상황을 추적하고 보고하는 방법을 정한다.

보충 프로젝트

1) 의미

: 프로젝트를 원활하게 진행하기 위해 필요한 추가적인 계획

2) 단계

(1) 구성 관리 계획 : 프로젝트에서 사용될 소스 코드, 문서, 데이터 등을 어떻게 관리할지 정하는 계획

(2) 배포 계획 : 개발이 완료된 소프트웨어를 고객 환경에 어떻게 배포할지에 대한 계획 (데이터의 마이그레이션 계획도 포함)

(3) 유지보수 계획 : 소프트웨어가 운영된 후 발생할 요구사항, 비용 및 노력을 예측하는 계획

(4) 품질 계획 : 프로젝트에서 적용할 품질 관리 절차와 표준을 정하는 계획

(5) 검증 계획 : 소프트웨어가 요구사항을 만족하는지 확인하기 위한 검증 절차를 정의

계획 수립 시 가정 사항

• 낙관적인 가정 보다는 현실적인 가정을 해야 한다.
• 프로젝트 진행 중, 예상치 못한 문제가 발생하고, 프로젝트 지연으로 이어질 수 있음을 고려해야 한다.
• 프로젝트 초기에 설정한 일정과 목표는 변동 가능성이 크므로, 어느 정도의 유연성을 갖도록 해야 한다.
• 계획에 여유기간을 포함하여, 문제가 발생해도 일정이 심각하게 지연되지 않도록 해야 한다.

위험 완화

1) 상황

: 개발 작업 중 심각한 문제가 발생해 일정 지연이 예상될 경우

2) 할 일

• 프로젝트 실패 위험을 완화하기 위해 위험 완화 조치를 수행해야 한다.
• 아래의 조치를 고객과 함께 프로젝트를 다시 계획해야 한다.
  • 프로젝트 제약 사항 및 산출물을 재협상
  • 작업 완료 일정을 새로 수립하고 합의

프로젝트 일정 관리

1) 의미

: 프로젝트 작업을 개별 작업으로 분할하고, 이 작업들이 언제 어떻게 실행될지를 결정하는 과정

2) 추정해야 할 일

• 각 작업을 완료하는 데 필요한 기간
• 각 작업에 투입되는 인력 및 담당자
• 각 작업 별로 필요한 자원

3) 고려할 점

프로젝트를 개별 작업으로 분할하여, 각 작업을 완료하는 데 필요한 시간과 자원을 추정한다.

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

4) 문제점

• 문제의 난이도를 추정하고, 해결 비용을 계산하는 것은 어렵디.
• 생산성은 작업에 참여하는 인원의 수에 비례하지 않는다.
• 프로젝트 딜레이 발생할 때, 인원을 추가하면, 소통의 오버헤드로 더 딜레이된다.
• 항상 예상치 못한 일이 발생한다.

5) 표현법

: 일반적으로 그래픽 표기법을 사용한다.

(1) 작업 단위

• 프로젝트를 작업 단위로 나누어 표현한다.
• 개별 작업이 너무 작어서는 안 되며, 1~2주 정도의 기간이 적당하다.

(2) 종류

• 캘린더 기반 : 가장 일반적인 바 차트를 활용하여 프로젝트의 일정과 진행 상태를 표현하고, 시간에 따른 활동 또는 자원을 나타낸다.
• 활동 네트워크 : 작업 간의 의존성을 보여준다.

(3) 작업(활동)의 포함 내용

• 일정 기간 (일 또는 개월 단위)
• 인력 투입 예상치 (인-일 또는 인-월 단위)
• 완료 기한
• 명확한 종료 기준

마일 스톤과 산출물

1) 마일스톤

: 프로젝트 일저에서 진행 상황을 평가할 수 있는 지점 (ex. 시스템을 테스트 팀에 인도하는 시점, 주요 기능 개발 완료, 첫 번째 프로토타입 배포)

2) 산출물

: 고객에게 전달되는 작업 결과물 (ex. 시스템 요구사항 문서, 설계 문서, 코드베이스, 테스트 보고서, 사용자 매뉴얼)

애자일 계획

1) 애자일 소프트웨어 개발 방법

• 반복적 접근 방식
• 소프트웨어를 점진적으로 개발하여 고객에게 제공

2) 특징

• 각 증분의 기능은 사전에 계획되지 않고, 개발 과정에서 결정된다.
• 증분에 포함할 기능은 진행 상황과 고객의 우선순위에 따라 결정된다.
• 고객의 요구사항과 우선순위는 변경될 수 있으므로, 이러하 변경을 수용할 수 있는 유연한 계획이 필요하다.

견적 기법

1) 의미

: 소프트웨어 개발에 필요한 노력과 비용을 추정하는 방식

2) 종류

(1) 경험 기반 기법

: 관리자가 과거 프로젝트와 해당 도메인의 경험을 바탕으로, 미래의 노력 요구 사항을 추정한다.

• 본질적으로 관리자는 과거 경험을 바탕으로 판단하여, 노력 요구 사항을 예측한다.
• 프로젝트에서 생산해야 할 산출물과 개발할 소프트웨어 구성 요소 또는 시스템을 식별한다.
• 이를 스프레드시트 등에 문서화하고, 개별적으로 추정한 후 총 소요 노력을 계산한다.
• 문제점
  • 새로운 소프트웨어 프로젝트가 이전 프로젝트와 유사하지 않을 수 있다.
  • 소프트웨어 개발 환경은 빠르게 변화한다.
  • 이러한 기술을 다뤄본 경험이 없다면, 기존 경험이 노력 추정에 도움이 되지 않을 수 있어, 정확한 비용과 일정 추정이 어려워진다.

(2) 알고리즘 기반 비용 모델링

: 제품의 속성과 프로세스 특성 등의 요소를 사용하여, 수학적 공식을 통해 프로젝트 노력을 계산한다.

• 비용은 다음과 같은 요소를 기반으로 수학적 함수로 추정된다.

A: 조직별 상수 (예: 소프트웨어 유형)

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

추적의 불확실성

1) 주요 특징

• 수직축은 불확실성 수준을 나타내며, 0.25x에서 4x까지 범위를 보인다.
• 프로젝트의 타당성 조사(Feasibility) 단계에서 불확실성이 가장 높다(약 4x).
• 프로젝트가 진행됨에 따라 불확실성은 점진적으로 감소한다.
• 코딩 및 최종 배포(Delivery) 단계에 이르면 불확실성이 매우 낮아진다(1x에 가깝다).

2) 의미

• 이 그래프는 프로젝트 관리의 중요한 원칙을 보여준다. 프로젝트 초기에는 알려지지 않은 요소가 많아 불확실성이 높고, 프로젝트가 진행될수록 더 많은 정보를 수집하고 결정을 내리면서 불확실성이 줄어든다.
• 초기 단계(타당성 조사와 요구사항)에서는 변동성이 가장 크고, 후반부 단계(코딩과 배포)에서는 훨씬 더 예측 가능해진다. 이는 구현 단계로 나아가기 전에 철저한 계획, 요구사항 수집, 설계에 시간과 노력을 투자하는 것이 중요함을 상기시킨다.

추정의 정확도

: 소프트웨어 시스템의 크기는, 개발이 완료된 후에야 정확히 알 수 있다.

1) 최종 크기에 영향을 미치는 요인

• 재사용된 시스템 및 구성 요소 사용 여부
• 프로그래밍 언어
• 시스템 배포 방식

2) 특징

• 개발이 진행될수록, 크기 추정의 정확도가 높아진다.
• B(소프트웨어 복잡도 또는 기능성 평가) 와 M(프로세스, 제품, 개발 속성을 고려한 조정 계수) 요소는 추정자의 주관적인 판단에 따라 다를 수 있다.

COCOMO 비용 모델링

1) 의미

• 과거의 프로젝트 데이터를 바탕으로 개발 비용을 예측하는 모델이다.
• 특정 회사나 소프트웨어에 의존하지 않고, 누구나 참고할 수 있도록 정리된 모델이다.
• COCOMO 2는 현대적인 개발 방식과 코드 재사용 등의 요소를 반영하여 개선된 모델이다

2) COCOMO 2 모델

: 점점 더 상세한 소프트웨어 비용 추정치를 제공하는 여러 하위 모델을 포함한다.

(1) 하위 모델

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

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

: 애플리케이션 포인트 생산성(AP Productivity)은 개발자의 경험과 도구의 성숙도에 따라 소프트웨어 개발 속도를 측정하는 개념이다.

개발자의 경험과 역량매우 낮음낮음보통높음매우 높음

ICASE 성숙도와 역량	매우 낮음	낮음	보통	높음	매우 높음
PROD (NAP/월)	4	7	13	25	50

1) 주요 요소

(1) 개발자의 경험과 역량

: 개발자의 실력과 경험이 높을수록 생산성이 증가한다

(2) ICASE 성숙도와 역량

: ICASE(통합 컴퓨터 지원 소프트웨어 엔지니어링) 도구가 얼마나 발전했는지에 따라 생산성이 달라진다.

(3) PROD (NAP/월)

: NAP(정규화된 애플리케이션 포인트) 기준으로 한 달에 처리할 수 있는 작업량을 나타낸다.

애플레케이션 구성 모델

: 애플리케이션 구성 모델은 프로토타입 프로젝트나 재사용이 많은 프로젝트에서 개발 노력을 예측하는 데 사용된다

1) 공식

• PM (Person-Month, 인월): 프로젝트를 완료하는 데 필요한 개발 노력(사람-개월 단위).
• NAP (Normalized Application Points, 애플리케이션 포인트 개수): 소프트웨어의 복잡도를 반영한 크기 단위.
• PROD (Productivity, 생산성): 개발자가 한 달 동안 처리할 수 있는 애플리케이션 포인트.
• %reuse (재사용 비율): 기존 코드를 재사용하는 비율(%)로, 높을수록 개발 노력이 줄어든다.

2) 쉽게 설명하면

• 만약 새로운 기능을 100% 새로 개발해야 한다면, 개발자들은 모든 코드를 처음부터 작성해야 하므로 더 많은 시간이 필요하다.
• 반면, 기존 코드를 50% 재사용할 수 있다면, 절반의 코드만 새로 작성하면 되므로 개발 시간이 줄어든다.

초기 설계 모델

: 초기 설계 모델은 소프트웨어 요구사항이 확정된 이후, 개발에 필요한 노력을 추정하는 방법이다.

1) 공식

• PM (Person-Month, 인월): 프로젝트를 완료하는 데 필요한 노력(사람-개월 단위).
• A (초기 보정값): 일반적으로 2.94로 설정됨.
• Size: 프로젝트 크기를 나타내는 KLOC(천 단위 코드 라인).
• B (규모 지수, 1.1~1.24 범위):
  • 프로젝트의 혁신성, 개발 유연성, 위험 관리, 프로세스 성숙도 등에 따라 결정됨.
• M (조정 인자): 프로젝트 환경과 관련된 다양한 요소를 곱한 값.

2) M 값 계산 방법 (with 곱셈 계수 (Multipliers))

(1) 공식

M=PERS×RCPX×RUSE×PDIF×PREX×FCIL×SCED

(2) 곱셈 계수

: 개발자 역량, 비기능 요구사항, 개발 플랫폼에 대한 친숙도 등을 반영

요소설명

PERS (Personnel Capability)	개발자의 능력 수준, 개발자의 역량
RCPX (Product Complexity)	소프트웨어의 복잡도, 제품 신뢰성
RUSE (Required Reusability)	코드 재사용 요구 수준, 필요한 재사용 정도
PDIF (Platform Difficulty)	개발 플랫폼의 난이도, 플랫폼 난이도
PREX (Process Maturity & Experience)	개발 프로세스의 성숙도와 경험, 개발자의 경험
FCIL (Facilities)	개발 환경(도구, 하드웨어 등), 팀 지원 시설
SCED (Required Development Schedule)	일정상의 제약, 요구되는 일정

3) 쉽게 설명하면

1. 프로젝트 크기(코드 라인 수, Size)가 클수록 개발 시간이 늘어난다.
2. B 값이 클수록(즉, 혁신적인 프로젝트일수록) 개발 난이도가 올라가면서 시간이 더 걸린다.
3. M 값은 개발자의 능력, 코드 복잡도, 재사용 가능성, 플랫폼 난이도 등 다양한 요소를 고려하여 조정된다.

4) 예시

Size = 50 KLOC, B = 1.15, M = 1.2

→ 계산 결과, 약 170 인월(person-month) 필요

재사용 모델

1) 의미

: 소프트웨어 개발에서 기존 코드를 재사용하면 개발 시간을 줄이고 비용을 절감할 수 있다. 하지만, 모든 코드가 바로 사용 가능한 것은 아니므로, 재사용 유형에 따라 필요한 개발 노력을 다르게 계산해야 한다.

2) 재사용 유형

(1) 블랙박스 재사용 (Black-box reuse)

• 기존 코드를 변경 없이 그대로 사용하는 경우.
• 개발자는 코드 작성이 아니라 통합하는 작업만 필요함.
• 예) 오픈소스 라이브러리를 가져와서 사용하는 경우.

(2) 화이트박스 재사용 (White-box reuse)

• 기존 코드를 수정하여 사용하는 경우.
• 코드 이해, 수정, 통합 등의 추가 작업이 필요함.
• 예) 기존 모듈을 일부 변경하여 새로운 기능을 추가하는 경우.

3) 계산 방법

(1) 생성된 코드의 경우:

PM = (ASLOC × AT/100) / ATPROD

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

(2) 코드를 이해하고 통합해야 하는 경우:

ESLOC = ASLOC × (1 - AT/100) × AAM

• ESLOC: 새 코드에 해당하는 소스 코드 라인 수
• AAM: 코드 변경, 코드 통합 이해, 재사용 결정 비용을 반영한 조정 계수

4) 예시

(1) 블랙박스 재사용 예제

• 재사용 코드 10,000줄 (ASLOC = 10,000)
• 자동 변환 80% (AT = 80%)
• 엔지니어 생산성 = 500줄/인월 (ATPROD = 500)
• PM 계산PM=10,000×80100×500=8,000500=16 인월PM=100×50010,000×80=5008,000=16 인월
• 즉, 16개월의 개발 노력이 필요함.

(2) 화이트박스 재사용 예제

• 재사용 코드 10,000줄 (ASLOC = 10,000)
• 자동 변환 50% (AT = 50%)
• AAM = 1.2 (코드 수정, 통합 난이도 반영)
• ESLOC 계산ESLOC=10,000×(1−50100)×1.2=10,000×0.5×1.2=6,000 줄ESLOC=10,000×(1−10050)×1.2=10,000×0.5×1.2=6,000 줄
• 즉, 6,000줄을 새로 개발하는 것과 비슷한 노력이 필요함.

아키텍처 이후 모델

1. 의미

소프트웨어 개발이 진행됨에 따라 보다 정확한 비용과 일정 예측이 필요하다.

아키텍처 이후 모델은 초기 설계 모델과 유사하지만, 더 많은 요인을 반영하여 비용을 추정한다.

1. 초기 설계 모델과 비교

구분초기 설계 모덻아키텍처 이후 모델

공식	PM = A × Size^B × M	PM = A × Size^B × M
곱셈 계수	7개 사용	17개 사용 (더 정교한 추정)
코드 크기	KLOC (천 단위 코드 라인)	새로운 코드, 재사용 코드, 수정 코드 반영
적용 시점	요구사항 확정 후	아키텍처 설계 완료 후
예측 정확도	비교적 낮음	더 정밀한 비용 추정 가능

• 즉, 아키텍처 이후 모델은 더 많은 요인을 고려하여 예측 정확도를 높인다.

1. 지수 계산에 영향을 주는 요인들이다.

규모 요인설명

아키텍처/위험 해결	프로젝트의 위험 분석 정도를 반영 (낮으면 분석 부족, 높으면 철저한 분석)
개발 유연성	개발 프로세스의 유연성 (낮으면 정해진 프로세스, 높으면 클라이언트가 목표만 설정)
선례성	조직이 유사 프로젝트를 수행한 경험 정도 (낮으면 경험 없음, 높으면 완전 숙련)
프로세스 성숙도	조직의 개발 프로세스 성숙도 반영 (CMM 레벨 기반)
팀 응집력	개발팀의 협업 수준 (낮으면 협업 어려움, 높으면 원활한 협업)

✔ 이 요인들은 프로젝트의 난이도를 결정하며, 최종적인 노력(PM) 산정에 영향을 준다.

4) 곱셈 계수 (Multipliers)

: 곱셈 계수는 프로젝트의 특성을 반영하여 노력(PM)을 조정하는 요소이다.

카테고리설명

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

✔ 곱셈 계수를 고려하여 프로젝트의 실제 개발 비용과 기간을 산정한다.

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

: 예제 데이터를 기반으로 한 노력 추정 방식이다.

항목승수값

신뢰성 (Reliability)	매우 높음 → 1.39 / 매우 낮음 → 0.75
복잡성 (Complexity)	매우 높음 → 1.3 / 매우 낮음 → 0.75
메모리 제약 (Memory Constraints)	높음 → 1.21 / 없음 → 1
도구 사용 (Tool Usage)	낮음 → 1.12 / 매우 높음 → 0.72
일정 (Schedule)	가속됨 → 1.29 / 일반적 → 1

✔ COCOMO 모델에서는 이러한 요소를 조정하여 최종적인 개발 인월(person-month)을 계산한다.

예제 비교

1. 고난이도 프로젝트 (복잡성이 높고, 신뢰성이 중요)
   • COCOMO 초기 추정치: 730 인-월
   • 조정된 최종 노력(PM): 2,306 인-월
2. 낮은 난이도 프로젝트 (신뢰성이 낮고, 복잡성이 적음)
   • COCOMO 초기 추정치: 295 인-월
   • 조정된 최종 노력(PM): 295 인-월

프로젝트 일정(TDEV) 및 인력 배치

1. 프로젝트 일정과 인력 배치를 추정하는 공식

• TDEV : 프로젝트 표준 일정 (단위 : 개월)
• PM : 노력(person-month) 계산값
• B : 규모 요인에 따른 지수 (1.01 이상)

✔ 이 공식은 프로젝트에 필요한 총 개발 시간을 예측하는 데 사용된다.

2) 인력 배치 고려 사항

• 개발 기간을 인력 수로 단순히 나눌 수 없다.
• 프로젝트 단계별로 필요한 인력 수가 다르다.
• 너무 많은 인력을 빠르게 투입하면 오히려 일정이 지연될 수 있다.