목적
|
반복 중에 고려되어야 하는 유스 케이스 또는 시나리오 세트를 선택합니다.
반복 중에 처리되어야 하는 비기능적 요구사항 세트를 선택합니다.
|
가이드라인: 반복
계획
|
반복 범위는 다음 네 가지 요소에 의해 정해집니다.
-
프로젝트에 대한 최상위 위험성
-
시스템에 필요한 기능성
-
프로젝트 계획에서 반복에 할당되는 시간
-
단계 및 해당 특정 목표( 개념: 단계 참조)
반복의 초기 계획에서, 반복을 위해 이미 계획된 시간을 채우기 위한 충분한 작업이 선택됩니다. 반면 프로젝트 관리자는 반복 계획을 개발할 때 어느 정도 자원 제한조건 및 기타 전술적 고려사항을 염두에 둘 수
있습니다. 분명히, 이전 반복에 대해 계획되었지만 완료되지 않은(이전 반복의 범위가 스케줄을 맞추기 위해 축소되었기 때문에) 작업은 일반적으로 높은 우선순위를 갖습니다.
작업 범위는 또한 반복 지속 기간 동안 완료를 위해 적용될 수 있는 최대 인력 구성 레벨에 대한 현명한 접근 방식에 의해 결정되어야 합니다. 예를 들어 해당 자원이 있다고 해도 적용 인력을 두 배로 해서 반복 시
완료되는 작업이 두 배가 되는 경우는 거의 없습니다. 효율적으로 적용될 수 있는 대략적인 인력 수는 전체 소프트웨어 크기와 아키텍처에 의해 판별되며 COCOMO II([BOE00] 참조)와 같은 예상 모델에서 이러한 숫자를 얻을 수 있습니다.
반복의 실행은 시간 제한(timeboxing)으로 관리됩니다. 즉 범위와 품질(수정되지 않은 발견된 결함에 의해 표현되는)이 종료 날짜를 충족하기 위해 능동적으로
관리됩니다.
정제에서 반복의 목표를 정의하기 위한 다음 세 가지 기본 구동 요소가 있습니다.
반복 목표를 정의하기 위한 기본 구동 요소는 위험성입니다. 가능한 빨리 위험성을 완화하거나 제거해야 합니다. 이는 대부분 정제 단계(위험성의 대부분이 완화되어야 함)의 경우이지만, 일부 위험성이 여전히
높거나 새로운 위험성이 발견되면 계속해서 구현/구축(Construction)의 핵심 요소가 될 수 있습니다. 그러나 정제 단계의 목적이 아키텍처의 기준선을 작성하는 것이므로, 개발될 소프트웨어의 모든
측면(적용 범위)을 아키텍처에서 다루도록 하는 것과 같은 다른 일부 사항을 고려해야 합니다. 이는 미래의 계획 수립(즉, 팀의 구성, 개발될 코드의 예상 등)에 아키텍처가 사용될 것이므로 중요합니다.
마지막으로, 위험성에 초점을 맞추는 것도 중요하지만 시스템의 기본 미션을 염두에 두어야 합니다. 모든 곤란한 문제를 해결하는 것도 좋지만 이로 인해 핵심 기능성에 해를 끼쳐서는 안됩니다. 연관되는 인지된 위험성이
없는 경우에도 시스템의 중요한 기능이나 서비스가 실제로 포함되도록(임계성) 하십시오.
위험성 목록에서 가장 손상을 주는 위험성에 대해, 개발 팀이 위험성에 "대처"하게 하는 일부 유스 케이스의 시나리오를 식별하십시오.
예제
-
"OS Y와 적절하게 동작하는 데이터베이스 D"와 같은 통합 위험성이 있는 경우 적당한 일부 데이터베이스 상호작용을 포함하는 하나의 시나리오를 포함하십시오.
-
"항공기의 항로를 계산할 시간"과 같은 성능 위험성이 있는 경우 최소한 가장 명백하고 빈번한 경우에 대해 이 계산을 포함하는 하나의 시나리오가 있어야 합니다.
임계성의 경우, 시스템이 제공하는 가장 기본적인 기능이나 서비스가 포함되도록 하십시오. 시스템이 제공하는 서비스 또는 기능의 가장 공통적이고 가장 빈번한 양식을 표시하는 유스 케이스 중에서 시나리오를
선택하십시오. 소프트웨어 아키텍처 문서가 이 노력에 사용되며, 여기에서 구조적으로 중요한 유스 케이스 또는 시나리오를 반영하기 위해 소프트웨어 아키텍처에 의해 선택되는 유스 케이스의 우선순위 세트 또는 서브 플로우를 제공합니다.
예제
-
전화 교환의 경우, 초기 반복 중에 일반 기지국 간 호출은 분명히 꼭 필요한 것입니다. 오류 처리 서브시스템의 운영자 구성에 대한 복잡한 실패 모드보다 즉시 시작하는 것이 훨씬 더 중요합니다.
적용 범위의 경우, 정제 단계의 후반부에서 중요하거나 위험하지 않은 경우에도 개발이 필요하다고 인식되는 영역을 다루는 시나리오를 포함하십시오.
종종 한 번에 복수 문제를 다루는 시작부터 끝까지의 시나리오를 작성하는 것이 경제적입니다.
종종 시나리오가 너무 "커지는" 위험이 생깁니다. 즉 너무 많은 여러 가지 측면과 변형 및 오류 사례를 다루려고 하게 됩니다(반복 계획 참조).
또한 정제 단계에서 일부 위험성은 좀 더 인적 또는 프로그램적 특성(즉, 팀 문화, 훈련, 도구의 선택, 새로운 기법 등)을 가질 수 있으며 단순히 반복을 통해 진행하면 이러한 위험성이 완화됨을 기억하십시오.
예제
-
서버의 데이터베이스에 저장될 하나의 가입자 레코드를 클라이언트 워크스테이션에 작성하십시오. 이는 모든 필드를 포함하진 않지만 사용자 대화 상자를 포함하며 발견되는 오류가 없다고
가정됩니다.
몇 가지 핵심 기능을 일부 통합 위험성(데이터베이스 및 통신 소프트웨어) 및 통합 문제(두 가지 다른 플랫폼 처리)와 결합합니다. 또한 디자이너가 새 GUI 디자인 도구를 숙지하도록
하십시오. 마지막으로 피드백을 위해 사용자에게 보여줄 수 있는 프로토타입을 작성하십시오.
-
최고 20,000명의 가입자를 작성할 수 있으며 한 명에 대한 액세스가 200밀리초 이하가 되도록 하십시오.
만족되지 않은 경우 아키텍처에 극적으로 영향을 줄 수 있는 일부 중요한 성능 문제(볼륨이나 데이터 및 응답 시간)를 다룹니다.
-
가입자 주소의 변경을 실행 취소하십시오.
디자이너가 모든 "실행 취소" 기능의 디자인에 대해 생각하게 하는 단순 기능입니다. 이는 다시 사용자에게 합리적인 비용으로 실행 취소될 수 있는 사항에 대한 푸시 백(push-back)을
트리거할 수 있습니다.
-
공급망 관리에 상대적인 모든 유스 케이스를 완료하십시오.
정제 단계의 목적은 또한 세트별로 요구사항의 캡처를 완료하는 것입니다.
프로젝트가 구현/구축(Construction) 단계로 이동하면서 위험성이 중요한 구동 요소로 남아 있게 됩니다(특히 의심되지 않았던 위험성이 새로 밝혀지기 때문에). 그러나 유스 케이스의 완전성이 구동 요소가 되기
시작합니다. 둘 이상의 반복 중에 철저히 테스트될 수 있도록 초기에 가장 핵심 기능 중 일부를 완료하도록 시도하면서 기능별로 반복을 계획할 수 있습니다. 구현/구축(Construction)의 후반부로 갈수록 전체
유스 케이스의 견고함이 기본 목적이 됩니다.
예제
-
오류가 있는 것을 포함하여 자동 착신 서비스의 모든 변형을 구현하십시오.
이는 관련 기능 세트입니다. 이들 중 하나가 정제 단계에서 구현되었을 수 있으며 나머지 개발을 위한 프로토타입으로 동작합니다.
-
야간 서비스를 제외한 모든 전화 교환수 기능을 완료하십시오.
다른 기능 세트입니다.
-
두 컴퓨터 설정에서 시간당 5,000건의 트랜잭션을 달성하십시오.
이를 통해 이전 반복에 실제로 달성된 내용(2,357/시간)에 상대적으로 필수 성능을 단계적으로 높일 수 있습니다.
-
Geographical Information System의 새 버전을 통합하십시오.
이는 이전에 발견된 몇 가지 문제점으로 필요하게 된 적당한 아키텍처 변경일 수 있습니다.
-
모든 레벨 1 및 레벨 2 결함을 수정하십시오.
이전 반복의 테스트 중에 발견되었는데 즉시 수정되지 않고 지연된 결함을 수정합니다.
제품의 생성을 완료하는 것이 기본 목적입니다. 반복의 목표는 수정되는 버그의 형태로 설정되며 여기에는 성능 또는 사용성의 개선이 포함됩니다. 구현/구축(Construction)의 끝(IOC 이정표 또는 "베타")에
적시에 도달하기 위해 기능이 삭제(또는 사용 불가능)되어야 한 경우, 지금까지 달성된 것을 위태롭게 하지 않는 한 해당 기능을 지금 완료하거나 켤 수 있습니다.
예제
-
베타 고객 사이트에서 발견되는 모든 심각도 1 문제점을 수정하십시오.
품질로 표현되는 목표는 시장에서의 신뢰성과 관련될 수 있습니다.
-
일치하지 않는 데이터로 인한 모든 시작 장애를 제거하십시오.
품질로 표현되는 또 다른 목표입니다.
-
분당 2,000건의 트랜잭션을 달성하십시오.
데이터 구조 변경, 캐싱 및 더욱 적절한 알고리즘의 몇 가지 최적화를 포함한 성능 조정입니다.
-
서로 다른 대화 상자 수를 30% 줄이십시오.
시각적으로 어지러운 부분을 줄여 사용성을 개선하십시오.
-
독일어 및 일본어 버전을 작성하십시오.
시간 부족 및 재작업 축소를 위해 베타는 영어 고객만을 위해 작성되었습니다.
|