Automazione_Oggi_377

69 / 120

NOVEMBRE-DICEMBRE 2014 AUTOMAZIONE OGGI 377 69
Personalizzazione delle linee guida
Una volta selezionato un gruppo base di linee guida, la fase suc-
cessiva consiste nel modificarle ed estenderle per adattarle alle
specifiche esigenze della propria organizzazione. Le linee guida
Maab possono essere personalizzate selezionando implementa-
zioni specifiche quando la linea guida Maab offre delle opzioni
(come nel caso della regola NA_0005), oppure aggiungendo det-
tagli specifici quando la regola fornisce linee guida generali (ad
esempio, specificando un compilatore per la regola NA_0026). La
personalizzazione comporta inoltre la definizione degli
standard di base, come ad esempio i punti dei segnali in
cui visualizzare le etichette (come previsto dalla regola
Maab na_0005). Inoltre, il team-fulcro può creare nuove
regole per affrontare i problemi dei flussi di lavoro non
trattati dallo standard di settore.
Distribuzione delle linee guida
La scelta migliore è quella di distribuire in più fasi le
linee guida di modellazione personalizzate, integrando
il feedback di un piccolo gruppo di utenti prima di di-
stribuire gli standard a gruppi più ampi, procedendo
come segue. Fase 1: adozione della versione di prova. Un
gruppo di circa sei-dieci persone inizia ad applicare le
linee guida ai propri modelli. Questo piccolo gruppo
monitora la frequenza con cui si verificano le eventuali
violazioni delle linee guida e segnala le eventuali diffi-
coltà incontrate nel rispettare le linee guida stesse. Questa fase
dura in genere da uno a tre mesi.
Fase 2: rettifica. In base al feedback derivante dalla Fase 1, il team-
fulcro aggiorna le linee guida. Tali aggiornamenti possono com-
portare la riscrittura delle linee guida per migliorarne la chiarezza,
la modifica della priorità e la posticipazione della distribuzione
di specifiche linee guida. Questa fase può iniziare non appena
è disponibile il feedback dalla Fase 1. Fase 3: prima distribuzione
mirata. Dopo la rettifica, le linee guida vengono distribuite a un
gruppo più ampio e utilizzate da quel gruppo per tutto il pro-
getto. Fase 4: valutazione del progetto. Una volta completato il
primo progetto (oppure un anno dopo la distribuzione), il team-
fulcro esamina il processo di distribuzione analizzando il numero
di violazioni rilevate e i problemi che si sono manifestati comu-
nemente. Oltre a seguire questo approccio di distribuzione in
più fasi, il team-fulcro deve ottenere un attivo supporto da parte
degli utenti finali. L’ accettazione delle linee guida è più probabile
quando gli utenti finali ne capiscono il valore insito nell’utilizzo e
quando le linee guida comportano un disturbo minimo nei flussi
di lavoro. Per essere maggiormente in grado di ottenere questa
approvazione e di ridurre al minimo le interruzioni dei flussi di
lavoro, il team dovrà: fornire informazioni su ciascuna linea guida,
che spieghino il problema risolto dalla linea guida stessa; fornire
strumenti automatici, ogni volta che è possibile, per ridurre o eli-
minare il peso della verifica della linea guida, si può usare Model
Advisor di Simulink per automatizzare la verifica delle linee guida
integrate, mentre per le linee guida personalizzate si può utiliz-
zare Simulink Verification and Validation; applicare le linee guida
solo nella fase pertinente dello sviluppo, l’applicazione deve es-
sere più permissiva durante lo sviluppo iniziale e diventare più
rigida man mano che il codice si avvicina alla distribuzione sui
target; fornire unmeccanismo di eccezioni da usare quando la de-
viazione da una linea guida è inevitabile o necessaria, per esem-
pio, consentire agli ingegneri di usare Model Advisor Exclusion
Editor per escludere blocchi individuali da specifici controlli della
linea guida.
Come far rispettare la conformità
alle linee guida
La conformità alle linee guida può essere fatta rispettare usando
uno strumento di verifica automatizzato come Model Advisor.
Tale compito è in genere più efficace se l’organizzazione impone
dei controlli delle linee guida come gateway per determinate
attività del flusso di lavoro di sviluppo: ad esempio, se gli inge-
gneri devono accertare la conformità dei loro modelli prima di
verificarli in un sistema di gestione delle configurazioni o prima
di generare il codice. Si può decidere di non far rispettare rigida-
mente alcune linee guida durante lo sviluppo iniziale, chiedendo
agli ingegneri di rispettarle soltanto nelle fasi successive dello
sviluppo. L’applicazione di alcune linee guida può essere più ri-
gida nel caso di progetti a virgola fissa o progetti ad alto livello
di sicurezza (safety critical), mentre può essere più permissiva nel
caso di progetti che coinvolgono moduli preesistenti. I report
sono il meccanismo principale per far rispettare le linee guida. La
reportistica ha la finalità immediata di fornire feedback all’inge-
gnere, nonché il beneficio, a lungo termine, di consentire al team-
fulcro di stabilire quali linee guida causano il maggior numero
di problemi. Nei progetti safety critical, i report possono essere
registrati nel sistema di gestione delle configurazioni insieme al
modello ed essere conservati come artefatto di sviluppo.
Acquisizione del feedback
Richiedere il feedback e rispondere a esso è essenziale per avere
successo nell’adozione degli standard di modellazione. Occorre
fare in modo che il team di progettazione abbia un modo sem-
plice per fornire il proprio feedback, dalla fase di valutazione del
progetto in poi. Non è necessario un processo di valutazione for-
male: spesso basta una semplice e-mail o un modulo web. Ideal-
mente, il team-fulcro risponde a tutti i feedback, rettificando le
linee guida o spiegando con chiarezza il motivo per cui le linee
guida vengono lasciate immutate. Il processo di acquisizione e
reazione al feedback deve ripetersi periodicamente per garantire
il miglioramento continuo e la conformità costante.
MathWorks -
Un report di Model Advisor