Prodotto di lavoro: Build
Questo artefatto produce una versione operativa di un sistema o di parte di esso, che dimostra un sottoinsieme di capacità che verranno fornite nel prodotto finale. Una build comprende uno o più elementi di implementazione (spesso eseguibili), ognuno costruito da altri elementi, in genere da un processo di compilazione e che si collega ad un codice sorgente.
Scopo

Lo scopo di una build, costruita da altri elementi dell'implementazione, è di distribuire un sottoinsieme testabile di funzioni runtime e di capacità del sistema. RUP (Rational Unified Process) suggerisce di costruire una sequenza di build durante un'iterazione, aggiungendo ad ognuna delle capacità ogni volta che vengono aggiunti o aggiornati degli elementi dai sottosistemi di implementazione.  Le build possono essere costruite a tutti i livelli di un sistema, includendo singoli sottosistemi o più sottosistemi, ma in RUP il punto focale sono le build definite nel the Prodotto di lavoro: Piano di build di integrazione, poiché si tratta delle fasi cruciali per il completamento dell'iterazione.  Se la dimensione o la complessità del sistema lo consentono, il Piano di build di integrazione può essere ridefinito in più piani, che si occupano dei singoli sottosistemi.

Un implementatore può creare delle build informali per diversi motivi, ad esempio verificare un'unità, utilizzando gli elementi provenienti dallo spazio di lavoro privato dell'implementatore e dagli spazi di lavoro di integrazione del sottosistema e del sistema, come ritenuto opportuno. Tuttavia, nel termine utilizzato qui, le build vengono create da un'integratore, dalle versioni identificate degli elementi distribuiti dagli implementatori negli spazi di lavoro di integrazione del sottosistema o del sistema, come definito nel Prodotto di lavoro: Piano di build di integrazione.

Proprietà
Facoltativo
PianificatoYes
Personalizzazione
Opzioni di rappresentazioneRappresentazione UML: Pacchetto nel modello di implementazione (il pacchetto del livello superiore o un sottosistema di implementazione) stereotipato come <<build>>. 

I build sono ovviamente obbligatori, tuttavia, i tipi di build che un progetto produce modifica nel ciclo di vita. Nella fase di inizio, l'interesse potrebbe essere di produrre prototipi come modo per comprendere meglio il problema o comunica con il cliente; in elaborazione, per produrre un'architettura stabile e in costruzione, per aggiungere funzionalità. In transizione, l'attenzione si sposta per assicurare che il software raggiunga una qualità consigliabile.