목적
  • 프로젝트의 전체 범위, 노력 및 비용을 추정합니다.
  • 프로젝트 라이프사이클의 주요 이정표 및 핵심 산출물에 초점을 맞추어 프로젝트에 대한 대략적인 계획을 작성합니다.
  • 프로젝트 단계 안에 주기 세트를 정의하고 이러한 각 주기의 목표를 지정합니다.
  • 프로젝트의 스케줄 및 예산을 작성합니다.
  • 프로젝트에 대한 자원 계획을 작성합니다.
  • 프로젝트의 잘 정돈된 완료를 위해 활동을 정의합니다.
역할:  프로젝트 관리자 
빈도: 프로젝트당 한 번 
단계
입력물:    결과물:   
툴 강좌:   

워크플로우 세부사항:   

프로젝트 견적 페이지 맨 위

목적 프로젝트를 수행하는 데 필요한 작업 크기를 추정합니다.
프로젝트 제한조건을 충족시키는 최적의 스케줄을 선택합니다. 

초기 단계 중에 프로젝트에서 제안된 작업에 대한 견적을 준비해야 합니다(소프트웨어 프로젝트 견적에 대한 일반적인 논의는 [BOE81], [PUT92] 및 [MCO96] 참조). 소프트웨어 프로젝트 견적은 몇 가지 복잡한 계산에 기초하므로 세부적인 기술적 배경은 여기에서 논의하지 않습니다. 견적은 다음 네 단계의 프로세스를 따릅니다.

  1. 제품 크기 견적
  2. 전체 프로젝트 노력 및 비용 견적
  3. 제한조건 및 우선순위 적용(예: 인력 인원, 전달 날짜, 예산)
  4. 최적의 스케줄, 노력 및 비용 견적 선택

제품 크기 견적

이것은 견적 프로세스의 핵심 정보입니다. 수행할 작업 크기를 예측할 수 없는 경우 작성하는 프로젝트 스케줄은 현실과 동떨어지기 쉽습니다. 프로젝트 초반에 사용할 수 있는 소프트웨어 제품 크기를 추정하는 데에는 유추 측정법 및 분석 측정법의 두 가지 방법이 있습니다. 물론 프로젝트 후반(구현 단계 동안)에는 자세한 프로젝트 작업 명세 구조에 기초하여 보다 정밀한 상향식 견적을 준비할 수 있습니다.

유추 측정법

새 제품을 비교하는 유추 측정법을 사용하여 프로젝트 범위를 추정할 때 이전 프로젝트에서 개발된 제품(알려진 크기)을 사용하여 개발하게 됩니다. 비교하는 제품의 여러 가지 특성을 비교해야 합니다(예: 비즈니스 유스 케이스 수, 액터 수, 데이터베이스 크기/복잡도 및 온라인 및 일괄처리 프로그램의 수).

이러한 특성을 비교하여 이전 제품과 비교되는 새 제품의 상대적 크기를 추정할 수 있고 그런 후 이전 제품의 알려진 크기를 사용하여 새 제품의 예상 크기를 계산합니다. 유스 케이스 설명의 세부 레벨이 비교를 무효로 만들 수 있기 때문에 유사한 방법을 사용하여 개발된 유사한 복잡도를 가진 제품을 비교하는 것이 중요합니다.

분석 측정법

초기 단계 후반에는 새 제품에 대한 충분한 정보를 수집하게 되어 제품 크기를 추정하는 분석적인 기법을 사용할 수 있습니다. 이러한 기법은 사용 가능한 소프트웨어 제품의 기능적 설명(예: 소프트웨어 요구사항 스펙, 소프트웨어 구조 문서)에 의해 좌우되며 표준 계산 규칙을 적용하여 이러한 설명에서 크기 측정을 결정합니다. 많은 다른 측정 방법이 사양 포인트(실시간 시스템에 대한 어플리케이션의 기능 포인트 수정사항)와 예상 객체 포인트(클래스 복잡도 및 계층 구조 분석에 기초한 객체 지향 시스템의 측정법)를 포함하여 개발되어도 이러한 기법 중 가장 잘 알려진 방법은 기능 포인트 계산일 것입니다. 

IBM 웹 사이트에서 유스 케이스를 기반으로 크기를 측정하는 방법에 대해 설명하는 백서를 볼 수 있습니다. 유스 케이스는 조직 간 또는 심지어 조직 안에서도 표현 방식과 추상 레벨이 매우 다를 수 있으므로 이러한 문서를 사용하여 유스 케이스에 기초한 초기 크기를 추정하려면 조직의 유스 케이스 양식에 맞게 반드시 교정해야 한다는 사실을 알아야 합니다. 일단 교정되면 유스 케이스 작성을 위해 선택한 표준 양식을 유지하는 것이 중요합니다. 그렇지 않으면 크기 추정이 완전히 틀릴 수 있습니다.

전체 프로젝트 노력 및 비용 견적

전체 인력 노력 및 프로젝트에 대한 스케줄은 설정된 과학적 모델을 사용한 제품 크기 견적에서 계산할 수 있습니다. 오늘날 사용되는 두 가지 주목할만한 모델은 Barry Boehm에서 개발한 COnstructive COst MOdel (COCOMO)와 Larry Putnam의 Putnam Methodology입니다. 두 모델은 업계 데이터를 통해 유효성이 확인되어 왔습니다. 최신 버전의 COCOMO에 대한 자세한 정보는 COCOMOII 웹 사이트를 참조하십시오.

크기 정보를 제외한 다른 핵심 정보는 팀 생산성 측정입니다. 이 값은 전반적인 프로젝트 노력을 결정합니다. 전체 프로젝트 스케줄은 전체 노력에 비선형적으로 관련됩니다. 불행하게도 모델은 수학적으로 복잡하므로 계산을 지원하는 소프트웨어 툴을 사용하는 것이 좋습니다.

제한조건 및 우선순위 적용

거의 모든 프로젝트는 몇 가지 제한조건(예: 특정 날짜에 운반되어야 함 또는 비용은 $850,000를 초과할 수 없음) 또는 우선순위(예: 가능한 빨리 필요한 제품)를 조건으로 합니다. 고정된 제품 크기를 제공하면 팀 크기 조정에 의해 이러한 사항들은 영향 받습니다. 팀 크기와 스케줄 간의 관계는 선형적이 아니라고 판명되었으므로 과학적 모델을 사용하여 다양한 팀 크기에 기초한 많은 시나리오를 만들어야 합니다. 자동 견적 소프트웨어는 이 경우 매우 유용합니다.

최적 스케줄, 노력 및 비용 견적 선택

이제 프로젝트에 대해 광범위한 시나리오를 가지고 있으므로 프로젝트 요구사항에 가장 잘 맞는 시나리오를 검토하고 선택합니다. 이것은 제안된 대로 프로젝트의 전체 지속 기간에 대한 초기 그림을 제공하고 필요한 팀 크기와 예산을 표시합니다.

프로젝트 단계 이정표 정의 페이지 맨 위

목적 공식적으로 평가되는 프로젝트 진행 시점을 정의합니다.
각 단계에 추정된 노력 및 비용을 할당합니다. 

소프트웨어 개발 계획은 먼저 주요 이정표의 날짜 및 특성을 정의합니다(단계 참조). 이 부분의 소프트웨어 개발 계획은 프로젝트에 대한 전반적인 "로드맵"을 제공하고 프로젝트가 시작될 때(초기 단계) 작성됩니다.

초기 개발 사이클에서 프로젝트 단계를 계획하려면 다음에 기초하여 이정표에 대해 지식에 근거한 몇 가지 추측을 해야할 수 있습니다.

  • 특성 및 영역이 유사한 프로젝트 경험
  • 새로운 정도
  • 특정 환경 제한조건(예: 응답 시간, 분산 및 안전성)
  • 조직의 성숙도

유사한 특성의 다른 프로젝트에서 직접 경험한 것을 기초로 한 추측으로 각 프로젝트 단계에 전체 예상 노력 및 비용의 적절한 부분을 할당하여 초기 프로젝트 예산을 작성합니다.

이정표 목표 정의 페이지 맨 위

목적 단계를 평가하는 기준을 정의합니다. 

각 이정표는 특정 산출물에 초점을 맞춥니다. 각각은 다음 단계로의 잘 정의된 전이 시점을 제공합니다.

단계 
이정표 
목적 
초기  라이프사이클 목표  프로젝트에 대한 자원 확약 
구현  라이프사이클 구조  제품 구조의 안정화 
구축  초기 조작 성능  제품 개발 완료 
전이  제품 릴리즈  성공적인 제품 전개 

각 이정표는 프로젝트가 처리해야 하는 중요한 장애를 나타냅니다. 각 이정표에서 프로젝트는 진행/중단 의사결정에 직면합니다.

단계 안에 주기의 수, 길이 및 목표 정의페이지 맨 위

목적 각 프로젝트 단계에 계획되는 주기 수를 결정합니다.
주기에 걸쳐 상대적인 작업 할당을 결정합니다.
각 주기의 목표를 결정합니다. 

일단 프로젝트 단계 길이 결정되면 주기 수와 그 길이를 결정해야 합니다. 프로젝트 유형, 문제점 영역 및 문제점 영역의 새로운 정도에 따라 적용할 수 있는 많은 주기 패턴이 있습니다(개념: 주기도 참조).

각 주기는 산출물(진행 상황 및 품질을 평가하기 위해 사용되는 실행 가능한 제품의 릴리즈)을 만듭니다. 각 주기에는 다른 초점이 있기 때문에 주기 산출물의 기능 및 완성도는 다릅니다. 주기 목표는 주기 종료시 주기 목표의 충족 여부를 평가하기에 충분하게 특정적이어야 합니다. 초기 주기에서 목표는 보통 위험 완화 측면에서 표현되며 후반 주기에서 목표는 기능 완성도 및 품질 평가로 표현됩니다.

이정표 날짜 및 범위 정제 페이지 맨 위

목적 초기 단계 종료시 사용 가능한 정보에 기초하여 추정치를 정제합니다.  

초기 단계 끝으로 갈수록 다음 사항을 고려하여 단계는 보다 정밀하게 계획될 수 있습니다.

  • 식별된 유스 케이스 수
  • 이미 조사된 유스 케이스 복잡도
  • 식별된 위험(기술적 및 비즈니스)
  • 기능 포인트 또는 유스 케이스 메트릭
  • 프로토타입 결과

대충 구조만 잡힌 계획은 구현 단계 중에 갱신됩니다. 이것은 나머지 프로젝트 계획 빌드의 기초로 제공됩니다.

프로젝트 자원 요구사항 확인 페이지 맨 위

목적 단계/주기에 할당된 이 프로젝트에 필요한 자원 수와 유형을 정의합니다. 

노력 추정치 및 거기에서 도출된 프로젝트 스케줄에 기초하여 이제는 프로젝트 수행에 필요한 자원을 정의할 수 있습니다. 각 단계/주기에 대해 포함시켜야 하는 역할과 각각의 수를 식별하십시오.

프로젝트 종료 계획 개발 페이지 맨 위

목적 프로젝트를 순서대로 종료시키기 위한 계획을 작성합니다. 

프로젝트 종료 계획은 소프트웨어 개발 계획의 섹션 5.6 종료 계획에 설명되어 있습니다. 프로젝트 종료는 장래 참조할 메트릭 및 학습된 사항이 기록되었는지 확인하면서 프로젝트를 순서대로 종료하기 위해 수행되는 일련의 활동입니다.

종료 프로세스는 다음 조건이 충족되면 시작됩니다.

  • 모든 프로젝트 산출물이 완료되어 형상 제어에 저장된 경우
  • 승인 테스트가 완료되었고 제품이 공식적으로 고객에게 승인된 경우
  • 제품이 공식적으로 고객에게 전달된 경우

종료 활동 정의

먼저 계획에 프로젝트 종료 중에 수행할 활동을 나열하십시오. 일반적으로 다음 사항이 포함됩니다.

  • 프로젝트 사후 회의
  • 프로젝트 사후 보고서 개발
  • 프로젝트 개인 검토 종료
  • 프로젝트 결과물 성취
  • 프로젝트 인력 재지정
  • 장래 프로젝트 견적을 위해 조직의 내역 메트릭 데이터베이스에 프로젝트 메트릭 추가

종료 활동의 참여자 식별

다음에는 계획에 각 종료 활동에 포함시킬 개인들을 식별하십시오.

종료 활동에 대한 스케줄 정의

그런 후 종료 활동에 대한 스케줄을 정의하십시오. 일반적으로 이 세부사항은 프로젝트 끝으로 가면서 소프트웨어 개발 계획에 추가됩니다.



Rational Unified Process   2003.06.15