타스크: 단계 및 반복 계획
이 타스크는 프로젝트 단계와 반복을 계획(즉 목표, 지속기간, 반복 수 등)하는 방법을 설명합니다.
원칙: 프로젝트 관리
목적

이 타스크의 목적은 다음과 같습니다.

  • 프로젝트에 대한 총 범위, 노력 및 비용을 예상합니다.
  • 제품 라이프사이클의 주요 이정표 및 핵심 인도물에 초점을 맞추고 프로젝트에 대한 대략적인 계획을 개발합니다.
  • 프로젝트 단계 내에서 반복 세트를 정의하고 이러한 반복의 각각에 대한 목표를 식별합니다.
  • 프로젝트에 대한 스케줄과 예산을 개발합니다.
  • 프로젝트에 대한 자원 계획을 개발합니다.
  • 프로젝트의 순차적인 완료를 위한 타스크를 정의합니다.
관계
단계
프로젝트 예상
목적 프로젝트를 전달하는 데 필요한 작업 크기를 예상합니다.
프로젝트 제한조건을 충족시키는 최적 스케줄을 선택합니다. 

도입/인식(Inception) 단계에서, 프로젝트에서 제안되는 작업에 대한 예상을 준비해야 합니다. (소프트웨어 프로젝트 예상에 대한 일반 정보는 [BOE81], [PUT92] 및 [MCO96] 참조). 소프트웨어 프로젝트 예상은 몇 가지 복잡한 수학을 기반으로 하므로 여기에서 상세한 기술적 배경에 대해서는 논의하지 않습니다. 예상은 다음 네 단계 프로세스를 따릅니다.

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

제품 크기 예상

이는 예상 프로세스의 핵심 입력입니다. 수행해야 하는 작업의 크기를 예상할 수 없는 경우 작성되는 모든 프로젝트 스케줄이 현실과 동떨어질 수 있습니다. 프로젝트에서 초기에 사용할 수 있는 소프트웨어 제품의 크기를 예상하는 접근 방식에는 유추에 의한 크기 조정과 분석에 의한 크기 조정의 두 가지가 있습니다. 물론 프로젝트의 나중에(정제(Elaboration) 단계에서) 자세한 프로젝트 작업분류체계(WBS)를 기반으로 하여 더 확고한 상향식 예상을 준비할 수 있습니다.

유추에 의한 크기 조정

유추에 의한 크기 조정 접근 방식을 사용하여 프로젝트 범위를 예상하는 경우, 개발 중인 새 제품을 이전 프로젝트에서 개발된(크기가 알려진) 제품과 비교합니다. 비즈니스 유스 케이스 수, 액터 수, 데이터베이스 크기/복잡도 및 온라인 및 일괄처리 프로그램의 가능한 수와 같이 비교되는 제품의 다양한 특성을 비교해야 합니다.

이러한 특성을 비교함으로써 이전 제품과 비교하여 새 제품의 상대 크기를 예상할 수 있으며, 그런 다음 이전 제품의 알려진 크기를 사용하여 새 제품에 대한 예상 크기를 계산합니다. 유스 케이스 설명의 세부사항 레벨 변화로도 비교를 무효화될 수 있으므로, 비슷한 접근 방식을 사용하여 개발되어 복잡도가 비슷한 제품을 비교하는 것이 중요함을 명심하십시오.

분석에 의한 크기 조정

도입/인식 단계의 후반부에는 분석 기법을 사용하여 제품 크기를 예상하기에 충분할 만큼 신제품에 대한 정보를 수집하게 됩니다. 이러한 기법은 사용 가능한 소프트웨어의 기능 설명(예: 소프트웨어 요구사항 스펙, 소프트웨어 아키텍처 문서)에 의존하며 표준 계수 규칙을 적용하여 이러한 설명에 대한 크기 척도를 판별합니다. 기능(feature) 점수(실시간 시스템에 적용하기 위한 기능(function) 점수의 수정) 및 예측 오브젝트 점수(클래스 복잡도 및 계층 구조의 분석을 기반으로 하는 객체 지향 시스템에 대한 척도)를 포함한 많은 다른 척도가 개발되었지만 이러한 기법 중에서 가장 잘 알려진 것은 기능(function) 점수 계수일 것입니다. 

또한 IBM 웹 사이트에서 사용 가능한 백서에서는 유스 케이스를 기반으로 하는 크기 예상 방법을 설명합니다. 이러한 백서를 사용할 때 유스 케이스에 기초한 초기 크기 예상을 수행할 때 반드시 조직의 유스 케이스 스타일에 맞게 조정해야 합니다. 유스 케이스는 조직 사이에, 심지어 조직 내에서도 추상의 수와 표현 방식에 있어서 크게 다를 수 있기 때문입니다. 일단 조정된 후에는 유스 케이스를 작성할 때 선택된 표준 스타일을 지키는 것이 중요하며, 그렇지 않으면 크기 예상에 상당한 오류가 있을 수 있습니다.

총 프로젝트 노력 및 비용 예상

기존의 과학적 모델을 사용한 제품 크기 예상으로부터 프로젝트에 대한 총 인력 노력 및 스케줄을 계산할 수 있습니다. 현재 사용하는 두 가지 유명한 모델은 Barry Boehm이 개발한 COCOMO(Constructive Cost Model)와 Larry Putnam의 Putnam Methodology입니다. 두 모델은 모두 산업 데이터에 대해 유효성이 검증되었습니다. COCOMO의 최신 버전에 대한 자세한 정보는 COCOMOII 웹 사이트를 참조하십시오.

크기 입력 외에, 다른 중요한 입력은 팀 생산성의 척도입니다. 이 값은 전체적인 프로젝트 노력을 판별합니다. 총 프로젝트 스케줄은 총 노력에 비선형적으로 관계됩니다. 불행히도 이 모델은 수학적으로 복잡하므로, 계산을 도와주는 소프트웨어 도구를 사용하는 것이 가장 좋습니다.

제한조건 및 우선순위 적용

거의 모든 프로젝트가 몇몇 제한조건(예: 특정 날짜에 출시해야 하거나 비용이 $850,000를 넘을 수 없음) 또는 우선순위(예: 제품이 가능한 빨리 필요함)의 영향을 받습니다. 고정 제품 크기가 주어지면 팀 크기에 대한 조정의 영향을 받습니다. 팀 크기와 스케줄 사이의 관계가 선형이 아님이 밝혀졌으므로, 과학적 모델을 사용하여 다양한 팀 크기를 기반으로 하는 많은 시나리오를 생성해야 합니다. 자동화된 예상 소프트웨어가 이 연습에 매우 유용합니다.

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

이제 프로젝트에 대한 폭넓은 시나리오가 준비되었으므로, 프로젝트의 요구에 가장 잘 맞는 시나리오를 검토하고 선택합니다. 이는 프로젝트의 전체 지속 기간에 대한 초기 그림을 제안된 대로 제공하고 필요한 팀 크기와 예산을 표시합니다.

프로젝트 단계 이정표 정의
목적 프로젝트 진행상태가 공식적으로 평가되는 위치를 정의합니다.
예상된 노력과 비용을 각 단계에 할당합니다. 

소프트웨어 개발 계획은 먼저 주요 이정표의 날짜와 특성을 정의합니다(단계 참조). 이 소프트웨어 개발 계획 파트는 프로젝트에 대한 전체 "로드맵"으로 기능하며 프로젝트의 시작(도입/인식(Inception) 단계)에서 작성됩니다.

초기 개발 주기에서 프로젝트에 대한 단계를 계획하려면 다음을 기반으로 이정표에 대한 몇 가지 경험에서 나온 추측이 필요할 수 있습니다.

  • 특성 및 도메인에서 비슷한 프로젝트에 대한 경험
  • 제품의 참신도
  • 응답 시간, 분배 및 안전과 같은 특정 환경 제한조건
  • 조직의 성숙도

비슷한 특성의 다른 프로젝트에서 얻은 경험을 기반으로 하는 예상을 사용하여, 총 예상 노력과 비용의 적당한 부분을 프로젝트의 각 단계에 할당하여 초기 프로젝트 예산을 작성합니다.

반복 기간 및 반복 수를 정의하는 방법에 대한 자세한 정보는  가이드라인: 소프트웨어 개발 계획을 참조하십시오.

이정표 목적 정의
목적 단계가 평가되는 기준을 정의합니다. 

각 이정표는 특정 인도물에 초점이 맞춰집니다. 각각은 다음 단계로의 잘 정의된 전이 지점을 제공합니다.

단계 
이정표 
목적 
도입/인식(Inception)  라이프사이클 목표 이정표 프로젝트에 자원 투입 
정제(Elaboration)  라이프사이클 아키텍처 이정표 제품의 아키텍처 안정화 
구현/구축(Construction)  초기 운용 능력 이정표 제품 개발 완료 
제품 릴리스 이정표 성공적으로 제품 배치 

각 이정표는 프로젝트가 넘어야 하는 중요한 장애물을 표시합니다. 즉, 각 이정표에서 프로젝트는 진행/중지 결정에 직면합니다.

단계 내에서 반복의 수, 길이 및 목표 정의
목적 각 프로젝트 단계에서 계획되는 반복 수를 결정합니다.
반복 사이에 작업의 상대적 할당을 결정합니다.
각 반복에 대한 목표를 결정합니다. 

프로젝트 단계의 길이가 결정된 후에는 반복의 수와 해당 길이가 결정되어야 합니다. 반복 기간 및 반복 수를 정의하는 방법에 대한 자세한 정보는  가이드라인: 소프트웨어 개발 계획을 참조하십시오. 프로젝트의 유형, 문제점 도메인 및 문제점 도메인의 참신성에 따라서 적용될 수 있는 많은 패턴이 있습니다(또한 개념: 반복 참조).

각 반복은 인도물, 즉 진행상태 및 품질을 평가하는 데 사용되는 실행 가능 제품인 릴리스를 생성합니다. 각 반복이 서로 다른 초점을 갖기 때문에 반복 인도물의 기능성과 완전성이 다릅니다. 반복 목적은 반복의 종료 시에 반복 목적이 달성되었는지 여부를 평가할 수 있을 만큼 충분히 구체적이어야 합니다. 초기 반복에서 목적은 대개 완화된 위험성으로 표현되며, 후기 반복에서의 목적은 기능적 완료와 품질의 척도로서 표현됩니다.

이정표 날짜 및 범위 정제
목적 도입/인식 단계의 종료 시에 사용 가능한 정보를 기반으로 예상을 정제합니다. 

도입/인식 단계의 후반부에는 다음을 고려하여 단계를 보다 정확하게 계획할 수 있습니다.

  • 식별된 유스 케이스 수
  • 이미 연구한 유스 케이스의 복잡도
  • 식별된 위험성(기술 및 비즈니스)
  • 기능 점수 또는 유스 케이스 메트릭
  • 모든 프로토타입 생성 결과

매우 개략적인 이 계획은 정제(Elaboration) 단계 중에 갱신됩니다. 이는 나머지 프로젝트 계획을 빌드하기 위한 기초로서 사용됩니다.

프로젝트 자원 조달 요구사항 판별
목적 단계/반복에 의해 할당되는 이 프로젝트에 필요한 자원의 수와 유형을 정의합니다. 

이제 노력 예상 및 여기에서 파생되는 프로젝트 스케줄을 기반으로 프로젝트를 수행하기 위해 필요한 자원을 정의할 수 있습니다. 각 단계/반복에 대해 포함되어야 하는 역할과 각각의 수를 식별하십시오.

프로젝트 완결 계획 개발
목적 프로젝트의 규칙적인 종료를 위한 계획을 개발합니다. 

프로젝트 완결 계획은 소프트웨어 개발 계획의 섹션 5.6 완결 계획에서 문서화되어 있습니다. 프로젝트 완결은 모든 메트릭과 교훈을 캡처하여 향후에 참조할 수 있도록 하면서 프로젝트를 규칙적으로 종료하기 위해 수행되는 일련의 타스크입니다.

완결 프로세스는 다음 조건이 만족되었을 때 시작됩니다.

  • 모든 프로젝트 인도물이 형상 제어 하에 완료 및 저장되었습니다.
  • 적합성 테스트가 완료되었고 고객이 제품을 공식적으로 승인했습니다.
  • 제품이 공식적으로 고객에게 전달되었습니다.

완결 타스크 정의

첫 번째, 계획에 프로젝트 완결 중에 수행할 타스크를 나열하십시오. 일반적으로 이들은 다음을 포함합니다.

  • 프로젝트 사후 회의
  • 프로젝트 사후 보고서의 개발
  • 프로젝트 인원 검토의 종료
  • 프로젝트 중간 산출물의 보존
  • 프로젝트 인력 재배정
  • 향후의 프로젝트 예상을 위해 조직 히스토리 메트릭 데이터베이스에 프로젝트 메트릭 추가.

완결 타스크를 위한 참가자 식별

다음으로, 계획에서 각 완결 타스크에 참여할 개인을 식별하십시오.

완결 타스크를 위한 스케줄 정의

그런 다음 완결 타스크에 대한 스케줄을 정의하십시오. 대개 이 세부사항은 프로젝트의 후반부에 소프트웨어 개발 계획에 추가됩니다.



핵심 고려사항

프로젝트 계획은 프로젝트 관리자가 프로젝트에 대한 특정 전달 프로세스를 인스턴스화(및 이후 실행을 관리)하는 영역입니다(중간 산출물: 개발 프로세스 참조). 이것을 보통 프로세스 규정이라고 부릅니다.

"인스턴스화된" 프로세스는 규정 가능한 프로젝트/반복/활동 계획입니다(실제 활동 및 실제 프로젝트에 대한 중간 산출물을 포함함).  전달 프로세스는 Rational Method Composer로부터 Rational Portfolio Manager(RPM)로 전달 프로세스를 가져온 후 isRepeatable 또는 hasMultipleOccurences로 설정된 활동 및 타스크를 중복하고 실제 중간 산출물을 작성하고 실제 자원을 역할에 지정하는 등의 인스턴스화 작업을 수행하여 인스턴스화될 수 있습니다. 

자세한 정보