72
- ELETTRONICA OGGI 433 - GENNAIO/FEBBRAIO 2014
EDA/SW/T&M
VERSION CONTROL
team condividono cartelle residenti sul server se non addi-
rittura in uno schedario. Soluzioni di questo tipo rientrano
in un approccio di tipo “organize-it-into-box” (organizzare
all’interno di un contenitore). A questo punto può sorgere
spontanea la domanda se si tratti realmente di un controllo
della versione.
La complessità dello sviluppo software
Negli ultimi 20 anni i programmi software sono aumentati in
dimensione, divenendo via via più complessi. Con il rilascio
di ogni nuova versione il codice deve essere aggiornato su
base regolare per integrare caratteristiche nuove (o miglio-
rate) e correggere eventuali errori. L’industria del software,
inoltre, ha implementato procedure di sviluppo di natura
modulare, che si può considerare una sorta di riutilizzo
del progetto (design reuse). La progettazione modulare e il
riutilizzo di segmenti di codice ha comportato l’insorgere di
nuove problematiche.
Le aziende hanno scoperto che il riutilizzo dei moduli sof-
tware comporta numerosi benefici. In primo luogo i moduli
in questione hanno permesso di aumentare l’affidabilità in
quanto il software riutilizzato è già stato collaudato in siste-
mi funzionanti. Il riuso consente anche di ridurre i rischi di
processo poiché funzionalità, rischi e costo del software
già esistente sono elementi noti. Oltre a ciò il software riu-
tilizzabile sfrutta in maniera efficiente le competenze degli
specialisti in quanto le loro conoscenze sono integrate nel
software stesso.
Forse ancora più importante, i team di progetto si sono resi
conto che il riutilizzo imprime un’accelerazione alla fase
di sviluppo, grazie alla riduzione dei tempi richiesti per la
codifica e la validazione. Da qui la possibilità di soddisfare
requisiti sempre più severi in termini di time-to-market e di
generare nuove iterazioni delle versioni di un prodotto in
tempi più brevi.
In ogni caso l’implementazione di una metodologia che
prevede il riutilizzo di un progetto software non è esente da
problemi. L’applicazione generalizzata dei moduli software
non è un processo automatico. In primo luogo i moduli
devono essere manutenuti e i processi di sviluppo adattati
nelle release successive. L’incompatibilità dei moduli riuti-
lizzati tende ad aumentare a causa delle modifiche appor-
tate alle diverse versioni di un sistema, con il conseguente
aumento dei costi di manutenzione. Per essere veramente
utili, gli elementi riutilizzati devono essere rintracciabili
nella libreria, compresi e in certi casi adattati. Nelle ver-
sioni successive, l’introduzione di elementi di progetto
nuovi o aggiornati imporranno verosimilmente prerequisiti
e correlazioni alle quali gli elementi riutilizzati dovranno
necessariamente conformarsi. Ancora più problematico è
il fatto che, nell’ecosistema delle proprietà intellettuali (IP),
sono molte aziende convinte di essere le sole a potere – o
dovere - riscrivere i componenti al fine di poterli migliorare
o detenere.
Un approccio basato sul lavoro in team
All’interno di un team di sviluppo è ovvio che più persone
lavorano sul medesimo codice. Per gestire in maniera effi-
cace il team i manager devono avere la visibilità del lavoro
dei membri che compongono il team. Il primo requisito è la
disponibilità, per l’intero team, di un repository (ovvero di
un database) sicuro dove memorizzare i diversi moduli di
progetto. Una volta istituito, il team di progetto deve poter
conoscere lo storico incrementale delle modifiche fatte al
codice sorgente. Perchè il riutilizzo da parte di un team
sia veramente efficace è necessario utilizzare un metodo
efficiente sia per il check-in (memorizzazione nel repository
della copia modificata che va a sovrascrivere il file prece-
dente) sia per il check-out (estrazione di una copia di un file
dal repository e memorizzazione della copia stessa in una
cartella di lavoro) delle fonti di progetto.
Negli ultimi 20 anni I team di progetto software hanno com-
preso che un sistema efficiente per la gestione del progetto
deve semplificare la collaborazione tra i diversi membri del
team.
Come accennato poco sopra, il sistema deve anche creare
e manutenere in tempo reale uno storico incrementale delle
modifiche apportate al codice sorgente. Ciò significa che il
sistema deve acquisire i metadata per ciascuna modifica,
incluso l’autore della modifica. Ciò in pratica assicura una
tracciabilità completa, ovvero la possibilità di documenta-
re quale membro del team ha operato su un determinato
modulo, le modifiche effettuate e il periodo in cui sono state
apportate. In tal modo vengono migliorate le operazioni di
report e monitoraggio, così da permettere ai responsabili
di tracciare produttività e progressi fatti. Questi migliora-
menti, nel loro complesso, mettono tutti i componenti del
team nella condizione di rendere conto delle azioni fatte
(accountability).
Il controllo della versione
per la progettazione hardware
I team che si occupano della progettazione di schede PCB
sono composti da un numero di persone compresa tra uno
e venti: la media in linea generale è di cinque membri. In
alcuni casi, come ad esempio nelle più importanti aziende
di semiconduttori, vi possono essere anche centinaia di
FAE che sviluppano il progetto di riferimento. Solitamente,
i team di progetto di piccole-medie dimensioni conservano
i dati relativi al progetto elettronico sui rispettivi hard disk.
