Operazione: Integrazione del sistema
Questo compito illustra come integrare il sottosistema di implementazione a piccoli pezzi in un build.
Discipline: Implementazione
Relazioni
RuoliEsecutore primario: Esecutori aggiuntivi:
InputObbligatorio: Facoltativo:
  • Nessuno
Output
Utilizzo del processo
Passi
Accettazione del sottosistema e produzione di build intermedi

All'inizio di questo compito, i sottosistemi di implementazione sono stati prodotti in modo da soddisfare i requisiti del successivo (quello di 'destinazione') build descritto in Prodotto di lavoro: Piano di build di integrazione, ricordando che nel Piano di build di integrazione potrebbe essere definita la necessità di più build in un'unica iterazione. In base alla complessità ed al numero di sottosistemi integrati, è spesso più efficace produrre il build di destinazione in più fasi, aggiungendo ulteriori sottosistemi ad ogni fase, e producendo una serie di 'mini' build intermedi, così, ciascun build pianificato per una iterazione potrà, a sua volta, ottenere la propria sequenza di build intermedi transitori. Questi andranno soggetti ad un minimo test di integrazione (solitamente un sottoinsieme dei test descritti nel Piano di build di integrazione per questo build di destinazione) per assicurare che ciò che viene aggiunto sia compatibile con ciò che è già presente nello spazio di lavoro di integrazione del sistema. Con questo approccio dovrebbe così essere più semplice isolare e diagnosticare i problemi.  

L'integratore accetta i sottosistemi prodotti in maniera incrementale nello spazio di lavoro di integrazione del sistema risolvendo nel processo qualsiasi conflitto di incorporazione.  Si consiglia di eseguire questa operazione al contrario rispetto alla struttura a livelli, accertandosi che le versioni dei sottosistemi siano congruenti e considerando la possibilità di importare. L'incremento dei sottosistemi viene compilato e collegato in build intermedi, forniti poi a colui che esegue il test per permettere un minimo test di integrazione nel sistema.

Diagramma descritto nel testo associato.

questo diagramma mostra un build prodotto in tre incrementi. Alcuni sottosistemi sono unicamente necessari come stub, per permettere la compilazione ed il collegamento con altri sottosistemi e fornire il comportamento di run-time essenziale.

L'incremento finale di una sequenza produce il build di destinazione, come pianificato nel Piano di build di integrazione. Una volta sottoposto a minima verifica, si crea una linea di base iniziale o previsionale, facendo riferimento a Compito: Creazione della linea di base nella sezione Gestione della configurazione. Il build viene poi messo a disposizione del personale di test per una verifica completa del sistema. La natura ed il dettaglio di questi test saranno quelli pianificati nel Piano di build di integrazione, con il build finale di un'iterazione soggetta a tutti i test in esso definiti.

Promozione delle linee di base
Una volta che un build ha superato i vari livelli di test, le linee di base associate vengono promosse di conseguenza. Ciò avviene richiamando Compito: Promozione delle linee di base nella sezione Gestione della configurazione. La promozione è una sorta di contrassegno delle linee di base al superamento o meno di un determinato livello di test. I nomi dei livelli di promozione sono definiti dal Ruolo: Gestore della configurazione come parte della definizione dei criteri di configurazione del progetto. I livelli di promozione sono utili agli utenti delle linee di base: ad esempio, un implementatore vorrà sapere se una linea di base è stabile e se sia stata verificata in precedenza, prima di aggiornare (o prima di ridefinire le linee di base) uno spazio di lavoro di sviluppo privato in uno spazio di lavoro di integrazione del sistema.
Ulteriori informazioni