타스크: 반복 계획 개발
이 타스크는 범위, 평가 기준, 활동을 정의하고 반복에 대한 책임을 지정하여 반복 계획을 작성하는 방법을 설명합니다.
원칙: 프로젝트 관리
목적

다음으로 구성되는 반복 계획을 개발합니다.

  • 타스크와 책임 지정의 세부 작업분류체계(WBS)
  • 반복 간 이정표 및 인도물
  • 반복에 대한 평가 기준
관계
기본 설명

반복 자체는 실행 파일 작성에 대해 최대한 초점을 맞추는 타스크의 시간 제한 세트입니다. 최종 전이(Transition) 반복을 제외한 모든 경우에 이는 위험성을 완화하고 성공적인 인도를 위한 프로젝트 추진에 주의를 기울이기 위해 작성되는 중간 제품입니다. 실행 가능 인도물에 집중하면 거의 연속적인 반복이 강제되어 프로젝트가 초기에 기술적 위험성을 다룸으로써 부수적인 위험을 줄일 수 있게 됩니다.

반복은 어느 정도의 재작업(기존 중간 산출물의) 및 재작업에 따른 변경을 내포합니다. 간단히 말해서, 고품질의 제품을 전달하기 위해 어느 정도의 재작업이 필요합니다. 중간 제품을 빌드하고 초기에 자주 제품 아키텍처의 적합성을 평가함으로서 변경을 작성하는 데 비용이 적게 들고 수용하기에 더 쉬우면서도 최종 제품의 품질이 향상됩니다.

단계
반복 범위 판별
목적 반복 중에 고려되어야 하는 유스 케이스 또는 시나리오 세트를 선택합니다.
반복 중에 처리되어야 하는 비기능적 요구사항 세트를 선택합니다. 
가이드라인: 반복 계획 

반복 범위는 다음 네 가지 요소에 의해 정해집니다.

  • 프로젝트에 대한 최상위 위험성
  • 시스템에 필요한 기능성
  • 프로젝트 계획에서 반복에 할당되는 시간
  • 단계 및 해당 특정 목표( 개념: 단계 참조)

반복의 초기 계획에서, 반복을 위해 이미 계획된 시간을 채우기 위한 충분한 작업이 선택됩니다. 반면 프로젝트 관리자는 반복 계획을 개발할 때 어느 정도 자원 제한조건 및 기타 전술적 고려사항을 염두에 둘 수 있습니다. 분명히, 이전 반복에 대해 계획되었지만 완료되지 않은(이전 반복의 범위가 스케줄을 맞추기 위해 축소되었기 때문에) 작업은 일반적으로 높은 우선순위를 갖습니다.

작업 범위는 또한 반복 지속 기간 동안 완료를 위해 적용될 수 있는 최대 인력 구성 레벨에 대한 현명한 접근 방식에 의해 결정되어야 합니다. 예를 들어 해당 자원이 있다고 해도 적용 인력을 두 배로 해서 반복 시 완료되는 작업이 두 배가 되는 경우는 거의 없습니다. 효율적으로 적용될 수 있는 대략적인 인력 수는 전체 소프트웨어 크기와 아키텍처에 의해 판별되며 COCOMO II([BOE00] 참조)와 같은 예상 모델에서 이러한 숫자를 얻을 수 있습니다.

반복의 실행은 시간 제한(timeboxing)으로 관리됩니다. 즉 범위와 품질(수정되지 않은 발견된 결함에 의해 표현되는)이 종료 날짜를 충족하기 위해 능동적으로 관리됩니다.

정제(Elaboration) 단계:

정제에서 반복의 목표를 정의하기 위한 다음 세 가지 기본 구동 요소가 있습니다.

  • 위험성
  • 심각도
  • 적용 범위

반복 목표를 정의하기 위한 기본 구동 요소는 위험성입니다. 가능한 빨리 위험성을 완화하거나 제거해야 합니다. 이는 대부분 정제 단계(위험성의 대부분이 완화되어야 함)의 경우이지만, 일부 위험성이 여전히 높거나 새로운 위험성이 발견되면 계속해서 구현/구축(Construction)의 핵심 요소가 될 수 있습니다. 그러나 정제 단계의 목적이 아키텍처의 기준선을 작성하는 것이므로, 개발될 소프트웨어의 모든 측면(적용 범위)을 아키텍처에서 다루도록 하는 것과 같은 다른 일부 사항을 고려해야 합니다. 이는 미래의 계획 수립(즉, 팀의 구성, 개발될 코드의 예상 등)에 아키텍처가 사용될 것이므로 중요합니다.

마지막으로, 위험성에 초점을 맞추는 것도 중요하지만 시스템의 기본 미션을 염두에 두어야 합니다. 모든 곤란한 문제를 해결하는 것도 좋지만 이로 인해 핵심 기능성에 해를 끼쳐서는 안됩니다. 연관되는 인지된 위험성이 없는 경우에도 시스템의 중요한 기능이나 서비스가 실제로 포함되도록(임계성) 하십시오.

위험성 목록에서 가장 손상을 주는 위험성에 대해, 개발 팀이 위험성에 "대처"하게 하는 일부 유스 케이스의 시나리오를 식별하십시오.

예제

  • "OS Y와 적절하게 동작하는 데이터베이스 D"와 같은 통합 위험성이 있는 경우 적당한 일부 데이터베이스 상호작용을 포함하는 하나의 시나리오를 포함하십시오.
  • "항공기의 항로를 계산할 시간"과 같은 성능 위험성이 있는 경우 최소한 가장 명백하고 빈번한 경우에 대해 이 계산을 포함하는 하나의 시나리오가 있어야 합니다.

임계성의 경우, 시스템이 제공하는 가장 기본적인 기능이나 서비스가 포함되도록 하십시오. 시스템이 제공하는 서비스 또는 기능의 가장 공통적이고 가장 빈번한 양식을 표시하는 유스 케이스 중에서 시나리오를 선택하십시오. 소프트웨어 아키텍처 문서가 이 노력에 사용되며, 여기에서 구조적으로 중요한 유스 케이스 또는 시나리오를 반영하기 위해 소프트웨어 아키텍처에 의해 선택되는 유스 케이스의 우선순위 세트 또는 서브 플로우를 제공합니다.

예제

  • 전화 교환의 경우, 초기 반복 중에 일반 기지국 간 호출은 분명히 꼭 필요한 것입니다. 오류 처리 서브시스템의 운영자 구성에 대한 복잡한 실패 모드보다 즉시 시작하는 것이 훨씬 더 중요합니다.

적용 범위의 경우, 정제 단계의 후반부에서 중요하거나 위험하지 않은 경우에도 개발이 필요하다고 인식되는 영역을 다루는 시나리오를 포함하십시오.

종종 한 번에 복수 문제를 다루는 시작부터 끝까지의 시나리오를 작성하는 것이 경제적입니다.

종종 시나리오가 너무 "커지는" 위험이 생깁니다. 즉 너무 많은 여러 가지 측면과 변형 및 오류 사례를 다루려고 하게 됩니다(반복 계획 참조).

또한 정제 단계에서 일부 위험성은 좀 더 인적 또는 프로그램적 특성(즉, 팀 문화, 훈련, 도구의 선택, 새로운 기법 등)을 가질 수 있으며 단순히 반복을 통해 진행하면 이러한 위험성이 완화됨을 기억하십시오.

예제

  1. 서버의 데이터베이스에 저장될 하나의 가입자 레코드를 클라이언트 워크스테이션에 작성하십시오. 이는 모든 필드를 포함하진 않지만 사용자 대화 상자를 포함하며 발견되는 오류가 없다고 가정됩니다.
    몇 가지 핵심 기능을 일부 통합 위험성(데이터베이스 및 통신 소프트웨어) 및 통합 문제(두 가지 다른 플랫폼 처리)와 결합합니다. 또한 디자이너가 새 GUI 디자인 도구를 숙지하도록 하십시오. 마지막으로 피드백을 위해 사용자에게 보여줄 수 있는 프로토타입을 작성하십시오.
  2. 최고 20,000명의 가입자를 작성할 수 있으며 한 명에 대한 액세스가 200밀리초 이하가 되도록 하십시오.
    만족되지 않은 경우 아키텍처에 극적으로 영향을 줄 수 있는 일부 중요한 성능 문제(볼륨이나 데이터 및 응답 시간)를 다룹니다.
  3. 가입자 주소의 변경을 실행 취소하십시오.
    디자이너가 모든 "실행 취소" 기능의 디자인에 대해 생각하게 하는 단순 기능입니다. 이는 다시 사용자에게 합리적인 비용으로 실행 취소될 수 있는 사항에 대한 푸시 백(push-back)을 트리거할 수 있습니다.
  4. 공급망 관리에 상대적인 모든 유스 케이스를 완료하십시오.
    정제 단계의 목적은 또한 세트별로 요구사항의 캡처를 완료하는 것입니다.

구현/구축(Construction) 단계:

프로젝트가 구현/구축(Construction) 단계로 이동하면서 위험성이 중요한 구동 요소로 남아 있게 됩니다(특히 의심되지 않았던 위험성이 새로 밝혀지기 때문에). 그러나 유스 케이스의 완전성이 구동 요소가 되기 시작합니다. 둘 이상의 반복 중에 철저히 테스트될 수 있도록 초기에 가장 핵심 기능 중 일부를 완료하도록 시도하면서 기능별로 반복을 계획할 수 있습니다. 구현/구축(Construction)의 후반부로 갈수록 전체 유스 케이스의 견고함이 기본 목적이 됩니다.

예제

  1. 오류가 있는 것을 포함하여 자동 착신 서비스의 모든 변형을 구현하십시오.
    이는 관련 기능 세트입니다. 이들 중 하나가 정제 단계에서 구현되었을 수 있으며 나머지 개발을 위한 프로토타입으로 동작합니다.
  2. 야간 서비스를 제외한 모든 전화 교환수 기능을 완료하십시오.
    다른 기능 세트입니다.
  3. 두 컴퓨터 설정에서 시간당 5,000건의 트랜잭션을 달성하십시오.
    이를 통해 이전 반복에 실제로 달성된 내용(2,357/시간)에 상대적으로 필수 성능을 단계적으로 높일 수 있습니다.
  4. Geographical Information System의 새 버전을 통합하십시오.
    이는 이전에 발견된 몇 가지 문제점으로 필요하게 된 적당한 아키텍처 변경일 수 있습니다.
  5. 모든 레벨 1 및 레벨 2 결함을 수정하십시오.
    이전 반복의 테스트 중에 발견되었는데 즉시 수정되지 않고 지연된 결함을 수정합니다.

전이(Transition) 단계:

제품의 생성을 완료하는 것이 기본 목적입니다. 반복의 목표는 수정되는 버그의 형태로 설정되며 여기에는 성능 또는 사용성의 개선이 포함됩니다. 구현/구축(Construction)의 끝(IOC 이정표 또는 "베타")에 적시에 도달하기 위해 기능이 삭제(또는 사용 불가능)되어야 한 경우, 지금까지 달성된 것을 위태롭게 하지 않는 한 해당 기능을 지금 완료하거나 켤 수 있습니다.

예제

  1. 베타 고객 사이트에서 발견되는 모든 심각도 1 문제점을 수정하십시오.
    품질로 표현되는 목표는 시장에서의 신뢰성과 관련될 수 있습니다.
  2. 일치하지 않는 데이터로 인한 모든 시작 장애를 제거하십시오.
    품질로 표현되는 또 다른 목표입니다.
  3. 분당 2,000건의 트랜잭션을 달성하십시오.
    데이터 구조 변경, 캐싱 및 더욱 적절한 알고리즘의 몇 가지 최적화를 포함한 성능 조정입니다.
  4. 서로 다른 대화 상자 수를 30% 줄이십시오.
    시각적으로 어지러운 부분을 줄여 사용성을 개선하십시오.
  5. 독일어 및 일본어 버전을 작성하십시오.
    시간 부족 및 재작업 축소를 위해 베타는 영어 고객만을 위해 작성되었습니다.
반복 평가 기준 정의

각 반복의 결과는 실행 가능한 릴리스입니다. 릴리스는 일반적으로 프로덕션 품질은 아니지만(최종 전이(Transition) 반복의 경우 제외) 평가할 수는 있습니다.

도입/인식(Inception) 반복 평가

도입/인식 반복은 일반적으로 제품 개념의 증명 및 프로젝트 자금 조달을 승인하기 위해 필요한 지원 빌드에 초점을 맞춥니다. 결국 반복 릴리스는 간단한 사용자 인터페이스 아래에 실제 구현 코드가 없는 기능적 개념 검증 프로토타입입니다. 평가 기준은 사용자 적합성 및 정성적 척도를 지향합니다.

일부 환경에서는 자금 조달이 제공되기 전에 중요한 기술적 난관이 제품 도입/인식에서 극복되어야 합니다. 그 경우 평가 기준에서 이를 반영해야 합니다.

정제(Elaboration) 반복 평가

정제 반복은 안정된 아키텍처 작성에 중점을 둡니다. 결과적으로 정제 평가 기준은 아키텍처의 안정성 평가에 초점을 맞춰야 합니다. 사용할 수 있는 척도는 다음과 같습니다.

  • 인터페이스 안정성(또는 파손)
  • 아키텍처의 변경 비율(아키텍처 기준선과 비교)
  • 핵심 기능성의 성능

핵심 목적은 구현/구축(Construction) 단계 중의 변경사항이 시스템 전체에 파급되지 않도록 하는 것입니다. 그래야 과다한 재작업이 유발되지 않습니다.

구현/구축 및 전이 반복 평가

구현/구축 및 전이 반복은 파손, 결함 밀도 및 결함 발견 비율과 같은 전통적 소프트웨어 테스트 및 변경 관리 차원에서 측정됩니다. 이러한 반복에서는 오류를 수정할 수 있도록 오류를 찾는 데 초점을 맞춥니다.

오류는 검수 및 코드 검토, 기능 테스트, 성능 테스트 및 로드 테스트의 여러 가지 방법으로 발견됩니다. 각 기법은 특정한 결함 세트를 발견하기 위한 것이며 각각 고유한 영역을 갖습니다. 이러한 기법에 대한 특정 내용은 Rational Unified Process 테스트 원칙에서 논의됩니다.



반복 활동 정의

반복의 목적을 기반으로 반복 중에 수행될 타스크 세트를 선택해야 합니다. 일반적으로 각 반복은 소프트웨어 라이프사이클에서 모든 타스크를 부분적으로 통과(pass through)합니다.

  • 필수 기능성을 연습하는 유스 케이스 및 시나리오가 선택됩니다.
  • 유스 케이스(또는 시나리오) 동작이 연구되고 문서화됩니다.
  • 필수 동작을 제공하는 서브시스템 및 클래스 사이에서 동작이 분석되고 할당됩니다.
  • 클래스 및 서브시스템이 디자인, 구현 및 유닛 테스트됩니다.
  • 시스템이 전체적으로 통합 및 테스트됩니다.
  • 외부 릴리스(알파, 베타 및 GA(General Availability))를 위해 제품이 적당한 양식으로 패키지되고 사용자 환경으로 전이됩니다.

이러한 타스크가 수행되는 정도는 프로젝트의 반복 및 단계에 따라 다릅니다. 개별 원칙(요구사항, 분석 및 디자인, 테스트 등)이 일반 타스크를 정의하며, 이는 다시 프로세스 구성 중에 조직에 맞게 사용자 조정됩니다.

영향을 받는 중간 산출물 및 관련 타스크 식별

개발될 시나리오 또는 본격적인 유스 케이스(및 수정할 결함 포함)를 선택하고 간략하게 스케치한 후 어느 것이 영향을 받을 중간 산출물인지 찾아야 합니다.

  • 어떤 클래스를 재검토해야 합니까?
  • 영향을 받거나 작성될 서브시스템은 무엇입니까?
  • 수정될 가능성이 있는 인터페이스
  • 갱신해야 하는 문서

그런 다음 프로세스 원칙에서 관련되는 타스크를 추출하고 이들을 계획에 포함하십시오. 일부 타스크는 반복당 한 번 수행되고 일부는 클래스, 유스 케이스, 서브시스템당 한 번 수행되어야 합니다. 명백한 종속성과 함께 타스크를 연결하고 일부 예상되는 노력을 할당하십시오. 프로세스에 대해 설명되는 타스크의 대부분은 몇 시간에서 몇 일 내에 한 사람 또는 아주 적은 규모의 사용자 그룹이 수행할 수 있을 만큼 작습니다.

반복 시 이들을 모두 수행하기 위한 충분한 시간이 없음을 알게 될 수 있습니다. 반복을 확장(따라서 최종 전달 시간을 연장하거나 반복 수를 줄임)하는 대신 반복에 대한 욕심을 버리십시오. 단계에 따라서 시나리오를 더 단순하게 하거나 기능을 제거 또는 사용 불가능하게 하십시오.

책임 배정

반복에 대한 타스크 세트는 정의된 후 개별 프로젝트 팀 구성원에게 배정되어야 합니다. 사용 가능한 인적 자원과 반복 범위에 따라서 타스크는 개인이나 팀에 의해 수행될 수 있습니다. 검토 및 검수는 당연히 팀 타스크입니다. 유스 케이스 작성 또는 클래스 디자인 및 구현과 같은 기타 타스크는 단독적입니다(조언자 역할을 하는 선임 팀 구성원과 함께 신입 팀 구성원이 팀을 구성하는 경우는 제외).

일반적으로 각 중간 산출물은 해당 작업이 팀에 의해 수행되는 경우에도 개인의 책임이어야 합니다.

  • 유스 케이스
  • 서브시스템
  • 클래스
  • 테스트 및 테스트 계획
  • 기타

한 명의 담당자가 없으면 일관성을 보장하기가 매우 어렵습니다.



핵심 고려사항

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

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

자세한 정보