활동:
|
목적 단일 반복에 대해 다음으로 구성된 잘 짜여진 계획 개발
|
|
역할: 프로젝트 관리자 | |
빈도: 반복당 한 번 | |
단계 | |
입력물: | 결과물: |
툴 강좌: |
워크플로우 세부사항: |
반복 자체는 실행 파일 생산에만 중점을 두는, 제한된 시간의 타스크 세트입니다. 최종 전이 반복을 제외한 모든 경우 반복은 위험 완화 및 프로젝트의 성공적인 실행을 위해 작성되는 중간 생산물입니다. 전달 가능한 실행 파일에 중점을 두면 지속적인 통합이 필요하므로 프로젝트가 기술적 위험 요소를 초기에 처리하여 부수적인 위험을 줄일 수 있습니다.
반복에는 기존 결과물에 대한 특정한 재작업량 및 재작업에 수반되는 변경이 내포되어 있습니다. 즉, 일정한 재작업에는 우수한 제품의 전달이 필요합니다. 중간 제품을 빌드하고 조기에 자주 제품 구조의 적합성을 평가하면 최종 제품의 품질은 높아지는 반면 변경에 드는 비용이 감소하여 보다 쉽게 변경을 수용할 수 있습니다.
목적 | 반복 중에 고려할 유스 케이스 또는 시나리오 세트 선택 반복 중에 처리해야 하는 비기능적 요구사항 세트 선택 |
가이드라인: 반복 계획 |
반복의 범위는 다음 네 가지 요소로 조정됩니다.
반복의 초기 계획에서 (반복 계획 개발 진행 시 프로젝트 관리자가 자원 제한조건 및 기타 전술적 고려사항을 고려하는 것이 어느 정도는 허용되기는 함). 이전 반복에서 계획된 작업이나 스케줄에 맞추기 위해 반복 범위가 줄어들어 완료되지 않은 작업인 경우 일반적으로 우선순위가 높습니다.
또한 작업 범위는 반복 지속 기간에 완료할 수 있는 최대 인력 레벨에 민감하게 조정해야 합니다. 예를 들어, 반복에서 완료된 작업의 인력을 두 배로 늘려 해당 작업을 두 배로 수행하는 것은 자원을 사용할 수 있는 경우라도 불가능합니다. 효율적으로 적용할 수 있는 대략적인 인력 수는 소프트웨어 전체 크기 및 구조로 결정되며 COCOMO II([BOE00] 참조)와 같은 예상 모델에서 이들 수치를 제공할 수 있습니다.
그런 다음, 반복 실행은 시간 제한으로 관리합니다. 즉, 종료 날짜에 맞추도록 범위 및 품질(발견되었으나 수정되지 않은 결함)을 적극적으로 관리합니다.
구현화에서 반복 목적을 정의하는 세 개의 기본 조정자가 있습니다.
반복 목적을 정의하는 기본 조정자는 위험입니다. 가능한 빨리 위험을 완화하거나 제거해야 합니다. 이는 주로 대부분의 위험을 완화해야 하는 구현화 단계에 적용되지만 위험도가 높은 위험 요소가 남아 있거나 새로운 위험이 발견된 경우 구성 단계에서도 핵심 요소가 될 수 있습니다. 그러나 구현화 단계의 목표는 구조의 기준선을 작성하는 것이므로 예를 들어, 개발될 소프트웨어의 모든 측면을 구조에서 다루도록 하는 등 기타 사항도 함께 고려해야 합니다(범위). 이 점은 앞으로의 계획(예: 팀 조직, 개발되는 코드 평가 등)에 구조가 사용되므로 중요합니다.
위험에 집중하는 것도 중요하지만 시스템의 1차 임무 개념을 기억해야 합니다. 난해한 모든 실행을 분석하는 것은 유익하지만, 핵심 기능성에 손실을 주지 않아야 합니다. 이와 관련하여 감지된 위험이 없어도 시스템의 주요 기능 또는 서비스가 실제로 처리되는지(임계도) 확인하십시오.
대부분의 위험에 대해 개발 팀이 해당 위험을 "해결"하는 일부 유스 케이스의 시나리오를 위험 목록에서 식별하십시오.
예
- 통합 위험(예: "OS Y와 올바르게 작업하는 데이터베이스 D")이 있는 경우, 매우 적더라도 일부 데이터베이스 상호 작용이 필요한 하나의 시나리오를 포함하도록 하십시오.
- 성능 위험(예: "비행기 궤도 계산 시간")이 있는 경우, 최소한 가장 분명하고 빈번한 케이스에 대해서는 이 계산을 포함하는 하나의 시나리오를 포함하도록 하십시오.
임계도의 경우 시스템이 제공하는 가장 근본적인 기능 또는 서비스가 포함되도록 하십시오. 시스템에서 제공하는 가장 일반적이고 빈번한 양식의 서비스 또는 기능을 표시하는 시나리오를 유스 케이스에서 선택하십시오. 결과물: 소프트웨어 구조 문서는 구조적으로 의미 있는 유스 케이스 또는 시나리오를 반영하도록 역할: 소프트웨어 아키텍트에서 선택한 우선순위가 지정된 유스 케이스 세트 또는 유스 케이스의 서브플로우를 제공하여 이 작업을 진행하는 데 사용됩니다.
예
- 호출 전환의 경우 초기 반복에서 일반적인 station-to-station 호출은 필수사항입니다. 이는 오류 처리 서브시스템의 조작자 형상에서 복잡한 장애 모드가 아닌 올바른 모드를 가져오는 데 매우 중요합니다.
구현화 단계의 종료에서 커버리지에는, 위험하거나 중요하지는 않지만 개발이 필요한 영역을 수정하는 시나리오가 들어 있습니다.
동시에 여러 가지 사안을 처리하는 긴 엔드-투-엔드(End-to-End) 시나리오를 작성하면 경제적입니다.
시나리오가 너무 다양한 측면, 변형 및 오류 케이스를 커버하려고 하여 너무 "방대"해 지면 위험합니다(가이드라인: 반복 계획 참조).
또한, 구현화 단계에서 일부 위험은 개인이나 프로그램의 특성(예: 팀 문화, 훈련, 툴 선택, 새 기술 등)에 의한 것이며 단순히 반복을 수행하면 이러한 위험이 완화될 수 있다는 점에 유의하십시오.
예
- 사용자 대화 상자를 포함하고(모든 필드를 포함하는 것이 아님) 서버의 데이터베이스에 저장할 한 명의 신청자 레코드를 발견된 오류가 없는 것으로 가정하여 클라이언트 워크스테이션에 작성합니다.
통합 위험(데이터베이스 및 의사소통 소프트웨어) 및 통합 사안(두 개의 다른 플랫폼 처리)이 있는 일부 주요 기능을 결합합니다. 또한 설계자는 새로 작성한 GUI 설계 툴에 친숙해져야 합니다. 마지막으로 피드백을 위해 일반 사용자에게 증명할 수 있는 프로토타입을 작성합니다.- 20,000명까지 신청자를 작성할 수 있으며 한 개인에게 200밀리초를 초과하여 액세스할 수 없습니다.
해결되지 않으면 구조에 크게 영향을 미치는 핵심 성능 사항(볼륨, 데이터 및 응답 시간)을 처리합니다.- 신청자 주소 변경을 실행 취소합니다.
설계자가 모든 "실행 취소" 기능을 설계하도록 하는 단순한 기능입니다. 이는 합리적인 비용으로 실행 취소될 수 있는 것에 대해 일반 사용자에게 일부 푸시백을 차례로 트리거합니다.- 공급 체인 관리와 관련된 모든 유스 케이스를 완료합니다.
구현화 단계의 목표는 요구사항 캡처를 완료하는 것이며 또한 세트별로 설정하는 것입니다.
프로젝트가 구성 단계로 이동하면서 특별히 예기치 않은 새로운 위험이 발견되지 않으므로 위험은 계속 핵심 조정자로 남아 있습니다. 그러나 유스 케이스를 완료하면 조정자가 됩니다. 반복은, 가장 중요한 일부 기능을 초기에 완료하여 두 번 이상의 반복 동안 완전히 테스트됨으로써 계획되었던 기능이 될 수 있습니다. 구성의 마지막에서는 전체 유스 케이스의 견고성이 기본 목표가 됩니다.
예
- 착신 전환의 모든 변형(잘못된 착신 전환 포함)을 구현합니다.
관련 기능의 세트입니다. 이 중 하나는 구현화 단계 동안 구현되었을 수 있으며 나머지 개발에 프로토타입으로 제공됩니다.- 야간 서비스를 제외한 모든 전화 교환 기능을 완료합니다.
기능의 또 다른 세트입니다.- 2대의 컴퓨터를 설정하여 한 시간에 5,000개의 트랜잭션을 완료합니다.
이전 반복에서 실제로 완료한 양(시간당 2,357개)과 비교하여 필수 성능을 향상시킵니다.- 지리 정보 시스템의 새 버전을 통합합니다.
이전에 일부 문제점이 발견되어 구조를 약간 변경한 것일 수 있습니다.- 레벨 1 및 레벨 2의 결함을 모두 수정합니다.
이전 반복에서 테스트 중 발견되었으나 즉시 수정되지 않고 지연된 결함을 수정합니다.
기본 목표는 제품 생성을 완료하는 것입니다. 반복 목적은 수정되는 버그 및 포함되는 성능 또는 사용성 향상에 따라 설정됩니다. 구성 종료 시간에 맞추기 위해 기능을 제거하거나 사용 불가능한 경우(IOC 이정표 또는 "베타") 기능을 지금 완료하거나 기능을 활성화해야 합니다(지금까지 완료한 성과를 손상시키지 않는 경우).
예
- 베타 고객 사이트에서 발견된 심각도 1 문제점을 모두 수정합니다.
품질에 관한 목표는 시장에서의 신뢰성과 관련되어 있습니다.- 일치하지 않는 데이터로 인한 시동 고장을 를 모두 제거합니다.
품질 측면의 또다른 목표입니다.- 분당 2,000개의 트랜잭션을 완료합니다.
최적화와 관련된 성능 튜닝: 데이터 구조 변경, 캐싱 및 보다 높은 성능의 알고리즘.- 다른 대화 상자의 수를 30%까지 줄입니다.
비주얼 클러터를 줄여서 사용성을 향상시킵니다.- 독일어 및 일본어 버전을 작성합니다.
시간이 부족하고 재작업을 줄이기 위해 베타는 영어 고객 전용으로 생성되었습니다.
각 반복을 통해 실행 파일 릴리즈가 작성됩니다. 릴리즈는 일반적으로 생산-품질은 아니지만(최종 전이 반복은 제외) 평가할 수는 있습니다.
초기화 반복은 일반적으로 제품의 개념을 제공하고 프로젝트 투자 승인에 필요한 지원을 구축하는 데 중점을 둡니다. 따라서 반복 릴리즈는 일반적으로 사용자 인터페이스에 대한 실제 구현 코드는 부족한, 기능적 개념 증명(Proof-of-Concept) 프로토타입입니다. 평가 기준은 사용자 승인 및 품질 측정을 지향합니다.
일부 환경의 주요 기술적 장애는 제품 투자가 제공되기 전에 초기에 처리해야 하며 평가 기준에 이들을 반영해야 합니다.
초기화 단계에 대한 평가 기준을 참조하십시오.
구현화 반복은 안정적인 구조를 구성하는 데 집중합니다. 따라서 구현화 평가 기준은 구조의 안정성 평가에 중점을 두어야 합니다. 사용할 수 있는 평가 기준은 다음과 같습니다.
핵심 목표는 구성 단계 동안 변경사항이 과도한 재작업을 발생시켜 시스템에 전체에 영향을 미치지 않도록 하는 것입니다.
구현화 단계에 대한 평가 기준을 참조하십시오.
구조 및 전이 반복은 일반적인 소프트웨어 테스트를 통해 평가되며 관리 차원(예: 파손, 결함 밀도 및 결함 발견 비율)을 변경합니다. 이러한 반복은 오류를 찾아 수정하는 데 중점을 둡니다.
검사 및 코드 검토, 기능 테스트, 성능 테스트 및 로드 테스트 등 다양한 방법으로 오류를 발견합니다. 각 기술은 특정 결함 세트를 발견하는 데 맞게 조정되며 각 기술에는 해당하는 위치가 있습니다. 해당 기술에 대한 세부사항은 Rational Unified Process 테스트 규칙에 설명되어 있습니다.
구성 단계에 대한 평가 기준을 참조하고 전이 단계에 대한 평가 기준도 참조하십시오.
반복 목표에 기반하여 반복 동안 수행할 활동 세트를 선택해야 합니다. 일반적으로 각 반복은 다음과 같은 소프트웨어 라이프사이클에 있는 모든 활동에서 부분적인 통과를 작성합니다.
해당 활동이 수행되는 정도는 반복 및 프로젝트 단계에 따라 다릅니다. 각각의 규칙(요구사항, 분석 & 설계, 테스트 등)은 프로세스 구성 동안 조직에 차례로 조정되는 일반 활동을 정의합니다.
개발되는 시나리오 또는 전체적으로 변형된 유스 케이스 및 수정되는 결함을 선택하고 간단히 개요를 작성하고 나면 영향을 받게 되는 다음 결과물을 찾아야 합니다.
그런 다음, 관련된 활동을 프로세스 규칙에서 추출하고 계획에 배치합니다. 일부 활동은 반복당 한 번 수행하고(이 예제의 경우), 일부는 클래스당, 유스 케이스당, 서브시스템당 한 번 수행해야 합니다. 활동을 명백한 종속성이 있는 활동에 연결하고, 일부 예상 작업을 할당하십시오. 프로세스에 설명된 대부분의 활동은 한 개인이나 소규모의 그룹이 몇 시간이나 몇 일에 완료할 수 있을 정도의 분량입니다.
이를 모두 완료하기 위한 반복을 수행하는 데 시간이 충분하지 않을 수도 있습니다. 반복을 확장하기 보다 최종 인도 시간을 늦추거나 반복의 횟수를 줄여서 반복 범위를 줄이십시오. 수행 단계에 따라 시나리오를 단순하게 하거나 기능을 제거 또는 사용 불가능하게 하십시오.
반복 활동 세트가 정의되면 각 프로젝트 팀 구성원에게 이를 지정해야 합니다. 사용 가능한 직원 자원 및 반복 범위에 따라 개인 또는 팀이 활동을 수행할 수 있습니다. 검토 및 검사는 팀의 고유 활동입니다. 유스 케이스 작성, 클래스 설계 및 구현 등의 기타 활동은 단독 활동입니다(주니어 팀 구성원이 조언자 역할을 하는 상급 팀 구성원과 함께 팀을 이루는 경우는 제외).
일반적으로, 팀을 이루어 다음 작업을 완료한 경우에도 각 작업 제품은 개인의 책임입니다.
단일한 의사 교환 창구가 없으면 일관성을 유지하는 것은 거의 불가능합니다.
Rational Unified Process
|