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 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 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.
|