Linea guida: Decisioni importanti per l'Implementazione
Queste linee guida descrivono importanti elementi da considerare nella personalizzazione degli aspetti di implementazione del processo.
Relazioni
Descrizione principale

Decidere come utilizzare i prodotti di lavoro

Determinare quali prodotti del lavoro  utilizzare e le relative modalità d'impiego.  Oltre ad identificare i prodotti del lavoro da utilizzare, è importante anche personalizzarli in modo da farli aderire alle necessità del progetto. 

La tabella riportata di seguito specifica i prodotti del lavoro di implementazione raccomandati e quelli facoltativi (da utilizzare ad esempio solo in certi casi). Per ulteriori considerazioni sulla personalizzazione, consultare la sezione relativa nella pagina descrittiva del prodotto del lavoro.

Prodotto di lavoro Scopo

Personalizzazione (facoltativo, consigliata)

Modello di implementazione

(Sottosistema di implementazione, Elemento di implementazione)

Il modello di implementazione si compone di codice sorgente, programmi eseguibili e tutti gli altri prodotti di lavoro necessari per progettare e gestire il sistema in un ambiente di runtime.

Un'implementazione è composta di elementi di implementazione, tra cui codice (programmi sorgenti, binari ed eseguibili) e file di informazioni, ad esempio, file di avvio o file Leggimi.

Un sottosistema di implementazione è una raccolta di elementi e altri sottosistemi di implementazione che consente di strutturare il modello di implementazione suddividendolo in parti.

Tutti i progetti software sono dotati di un modello di implementazione con elementi di implementazione compresi un minimo di codice sorgente e programmi eseguibili.

Alcuni progetti includeranno anche sottosistemi, librerie e modelli visivi.

I sottosistemi sono utili in progetti con un gran numero di elementi di implementazione da organizzare.

Piano di build di integrazione Definisce l'ordine in cui i componenti devono essere implementati, quali build creare quando si integra il sistema e come sono valutati.

Facoltativo.

Consigliata se si ha bisogno di un piano di implementazione. Da omettere solo se l'integrazione è irrilevante.



Decidere la copertura di verifica unità

Decidere il limite in base al quale verrà eseguita la verifica dell'unità e il livello di copertura del codice la  cui scala è compresa tra informale a 100% di copertura codice. Questa scala viene descritta in  Piano del test.

Il livello di copertura di verifica unità si basa spesso sulle esigenze dei tester di integrazione e di sistema, cui il codice è stato passato. Il lavoro dei tester dipende sulla qualità del codice. Se il codice ha troppi difetti, i tester di integrazione e di sistema sono costretti a rispedire il codice agli implementatori troppo spesso, il che denota un processo di sviluppo mediocre risolvibile con verifiche unità più approfondite da parte degli implementatori.

È chiaro che non ci si può aspettare un codice da unità verificata completamente privo di difetti. Tuttavia, è necessario sia stato stabilito il giusto equilibrio tra verifica unità e qualità.

Il livello di copertura di verifica unità può anche essere diverso tra le diverse fasi. Anche un progetto critico per la sicurezza che richiede una copertura codice del 100% durante costruzione e transizione, in genere non richiede lo stesso livello durante l'elaborazione, in quanto in questo stadio molte classi sono ancora solo parzialmente implementate.

Decidere come revisionare il codice

Decidere il limite di revisione del codice. 

I vantaggi di una revisione del codice sono:

  • Applicare e incoraggiare uno stile comune di codifica nel progetto. La revisione del codice è un modo efficiente di far seguire le linee guida del progetto a tutti i membri del team. Per garantire ciò, è più importante dare priorità alla revisione dei risultati di tutti gli autori e gli implementatori che a tutti i file del codice sorgente.
  • Trovare errori che i test automatizzati non trovano. Le revisioni del codice individuano gli errori rilevati in fase di verifica.
  • Per condividere conoscenza tra individui e trasferire conoscenza dagli individui più esperti ai meno esperti.

Gli svantaggi di una revisione del codice sono:

  • Richiede tempo e risorse.
  • Se non compiuta correttamente, può risultare inefficiente. Esiste il rischio la revisione del codice venga eseguita solo per necessità e non per fare da complemento alla verifica automatizzata.

Per ulteriori informazioni sulla revisione del codice, consultare anche Compito: Revisione codice.

La revisione del codice aggiunge molto valore al progetto. Tutti i progetti che iniziano a misurare i livelli di errore e gestire i problemi correlati alle revisioni del codice aumentano in rendimento. Tuttavia, in molte organizzazioni è difficile avviare le revisioni per molti motivi, tra cui:

  • Dati insufficienti raccolti per verificare se la revisione del codice funziona.
  • Eccesso di dati raccolti.
  • Implementatori che tendono ad essere molto protettivi del codice.
  • Revisioni impantanate in formalità.
  • Amministrazione delle revisioni troppo impegnativa.

Si consiglia quanto segue per ottenere il massimo dalle revisioni del codice:

  • Raccogliere tutti i dati opportuni.
  • Misurare le prestazioni delle revisioni ed esporre i risultati.
  • Utilizzare le revisioni in modo "snello".

Per ulteriori informazioni sui livelli di revisione, consultare Linea guida: Livelli di revisione.