빌드는 최종 제품에서 제공될 성능의 서브세트를 실제로 보여주는 시스템의 일부 또는 시스템의 조작 버전입니다. 빌드는 각각 일반적으로 소스 코드 컴파일 및 링크 프로세서에 의해 기타 요소로부터 구성된 하나 이상의 구현 요소(종종 실행 가능)로 구성됩니다.   
역할:  통합자 
선택 가능성/발생 시기:  각 반복 동안.
템플리트 및 보고서: 
     
예: 
     
UML 표시:  <<build>>로 스테레오타입화된 구현 모델(최상위 레벨 패키지 또는 구현 서브시스템)의 패키지. 
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

구현의 기타 요소에서 구성된 빌드의 목적은 런타임 기능과 시스템 성능의 테스트 가능한 서브세트를 전달하기 위함입니다. RUP가 반복 중에 구성되는 빌드의 시퀀스를 제안하고 구현 시스템의 요소가 추가되거나 향상됨에 따라 각각으로 성능을 추가합니다.  빌드는 시스템의 모든 레벨에서 구성되고 단일 또는 여러 서브시스템을 포함합니다. 그러나 RUP에서는 결과물: 통합 빌드 계획에 정의된 빌드에 특히 신경을 기울입니다. 왜냐하면 해당 빌드가 반복의 완료로 이어지는 디딤돌이기 때문입니다.  시스템 크기 또는 복잡도가 이를 보증하는 경우, 통합 빌드 계획이 여러 계획으로 세분화되어 개별 서브시스템에 대해 다룹니다.

구현자가 여러 이유의 장치 테스트(예: 적절한 대로 구현자의 개인용 개발 작업공간 및 서브시스템과 시스템 통합 작업공간에서의 요소 사용)를 위해 비공식적 빌드를 구성할 수 있음을 참고로 하십시오. 그러나 용어가 여기에서 사용된 대로 빌드는 통합자에 의해 결과물: 통합 빌드 계획에 정의된 대로 구현자가 전달한 요소의 식별된 버전으로부터 서브시스템 또는 시스템 통합 작업공간으로 구성될 수 있습니다.

특성 페이지 맨 위

특성 이름 

간략한 설명 

UML 표시 

설명  빌드의 간략한 텍스트 설명  "간단한 텍스트" 유형의 태그값 
구현 서브시스템  빌드에 표시된 서브시스템  메타 연관 "표시"를 통하거나 반복적으로 메타 집합 "소유"를 통해 소유 
요소  서브시스템이 소유한 빌드의 구현 요소  메타 집합 "소유"를 통해 반복적으로 소유 
통합 빌드 계획 참조  해당 통합 빌드 계획의 세부사항 빌드 설명 참조  태그값 

시기 페이지 맨 위

각 반복에 대해 빌드가 결과물: 통합 빌드 계획에 정의된 대로 구성됩니다. RUP는 임의의 특정 타이밍과 빈도가 필요하지 않습니다. 이는 프로젝트의 특정 필요를 위해 선택됩니다. 올바른 자동화 정도로 일별 빌드 전략을 채택하여 구현자에게서 규칙적인 요소 스트림을 가져와 통합하고 결과적으로 생긴 빌드를 밤새 테스트하는 것은 확실히 가능합니다. 이는 모든 프로젝트, 특히 긴 회귀 테스트가 필요한 대형 프로젝트에는 적합하지 않습니다.

책임 페이지 맨 위

통합자가 빌드 제품에 대한 책임이 있습니다. 개발이 다음에 시스템으로 통합될 서브시스템을 중심으로 계획된 경우(연관 팀과 함께), 통합자 역할을 하는 여러 개인(예: 서브시스템 레벨 통합을 수행하기 위해 각 서브시스템 팀에 한 명과 시스템 레벨 통합을 수행하기 위한 한 명)이 있을 수 있습니다.

사용자 정의 페이지 맨 위

그러나 빌드는 확실히 필수적이며 프로젝트가 작성하는 빌드의 종류는 라이프사이클 동안에 변경됩니다. 초기 단계에서의 관심사는 문제점을 보다 잘 이해하고 고객과 의사소통하는 방법으로서 프로토타입을 작성하는 것입니다. 구현화 시에는 안정된 구조를 작성하고 구성시에는 기능성을 추가하는 것입니다. 전이시, 소프트웨어가 배송 가능 품질에 도달하는지 확신하는데 초점이 이동합니다.



Rational Unified Process   2003.06.15