La soluzione CAST Imaging consente di associare ad ogni versione di un’applicazione, intesa come un definito perimetro di analisi, un set di dati di misurazione, confrontabile con gli omologhi insiemi, afferenti alle versioni precedenti, calcolati sul medesimo perimetro, o in determinati casi anche su perimetri variabili. Dell’insieme di dati suddetto concentriamoci sull’elenco delle violazioni riscontrate durante la scansione del codice applicativo.
CAST Imaging, dispone di un nutrito insieme di regole, normate ISO 5055, di natura sintattica e architetturale, specifiche per ogni tecnologia sotto misurazione, che vengono verificate durante la scansione del codice, ove siano applicabili. La documentazione è disponibile qui:
https://technologies.castsoftware.com/rules
La contravvenzione ad una di queste regole genera una violazione. Le violazioni sono staticamente e nativamente distinte in critiche e non critiche, in osservanza a standard riconosciuti internazionalmente. Le violazioni vengono categorizzate dinamicamente, all’interno di CAST come added, solved, e pending. Le violazioni added sono quelle violazioni presenti nella versione attuale dell’applicazione, ma non nella precedente. Le solved sono violazioni presenti nella versione precedente e non più in quella attuale. Le pending sono violazioni introdotte in versioni precedenti all’attuale e ancora presenti nel codice. Inoltre, può rivelarsi opportuno prevedere una ulteriore categorizzazione statica circa le violazioni, ovvero quali delle standard per tecnologia, considerare per il calcolo degli SLA e quali poter trascurare, e modulare la gravità delle prime in sottoinsiemi (tipicamente 2 o 3; Golden, Silver, Bronze…). Le informazioni circa l’evoluzione del numero e del tipo di violazioni rilevate, sono disponibili nella vista action Plan dell’Engineering dashboard di CAST Imaging, strumento configurabile a livello di regole da tenere in considerazione e perimetro di analisi e che fornisce il link diretto al codice ove la violazione è stata rilevata (in giallo nella immagine seguente)
La determinazione del set di regole
Supponiamo di concentrare l’attenzione su un sottoinsieme di regole di quelle disponibili per tecnologia. Tale sottoinsieme viene individuato tramite colloquio fra CAST e responsabili di sviluppo e conduzione ed è strutturato usualmente mediante una partizione in regole Golden (quelle che non possono essere assolutamente presenti nel codice trasportato in produzione) e Silver (regole per le quali possa essere ipotizzabile un differimento della risoluzione o un annullamento). E’ fondamentale che la selezione delle regole sia contestualizzata alle caratteristiche delle applicazioni in gioco, in termini di esposizione intranet/internet, numero utenti, numero e funzionalità delle transazioni di business.
L’annullamento di una violazione è un evento non escludibile a priori. Tale eventualità può concretizzarsi perché la violazione è passibile di ulteriore valutazione nel contesto (ad esempio, l’utilizzo di query dinamiche è generalmente considerata una violazione critica per motivi di efficienza e di sicurezza ma può essere considerata accettabile in determinate condizioni al contorno), può essere determinata da una issue del parser, rilevata nel codice standard o autogenerato non riconoscibile come tale dalla piattaforma e quindi non in carico al fornitore. Ci sono casi in cui violazioni possono essere annullate in quanto le risorse necessarie per la modifica al codice non sono disponibili. Il differimento, questo potrebbe interessare anche regole di tipo Golden, può essere determinato da necessità di business.
Il processo di vendor Management basato sulle violazioni rilevate
Si ipotizzi che il processo preveda che nessuna violazione Golden e Silver possa raggiungere l’ambiente di produzione, con le eccezioni di cui al paragrafo precedente. Si assuma che i punti di controllo siano disseminati opportunamente nel ciclo di vita del software.
I punti di controllo
E’ certamente opportuno che il codice venga misurato appena possibile durante il ciclo di implementazione (shift left testing) e quindi si può ipotizzare di stabilire dei punti di misurazione in sviluppo, collaudo e produzione. E’ opportuno, inoltre che le misurazioni siano automatiche per ogni trasporto in ambiente di collaudo e produzione, per cui si ipotizzi una integrazione completa fra il sistema SCM (Software Configuration Manager) e la piattaforma CAST. In ambiente di sviluppo si può ipotizzare che la misurazione sia disponibile on demand, sempre integrata con il sistema SCM, ad uso esclusivo del fornitore in termini di risultati di dettaglio. In questo modo il team di sviluppo può entrare in contatto con il processo di misura immediatamente, senza vincoli particolari, effettuare test e ricicli anche molto ravvicinati e decidere di trasportare in ambiente di collaudo solo quando il CD è almeno assolutamente privo di violazioni di tipo Golden.
Il perimetro del codice sotto misurazione
Per generalizzare il discorso potremmo pensare di misurare di volta in volta le modifiche correttive ed evolutive del codice afferenti ad una specifica applicazione, individuate da un Change Document (CD) che contenga tutte le CR inerenti agli interventi suddetti. E’ previsto che più fornitori possano lavorare sulla medesima applicazione e che la piattaforma riesca a determinare quali violazioni siano effettivamente in carico al singolo fornitore. Al concetto di violazione pending si aggiunge quello di pending in charge, che in condizioni di perimetro condiviso fa riferimento allo specifico fornitore.
Gli attori coinvolti nel processo
Il Project Manager è responsabile del progetto a cui gli sviluppi software afferiscono. Il Quality Manager è responsabile dei processi di qualità e del rispetto degli SLA fissati, con compiti di supervisione dell’intero processo di misurazione, di supporto al PM e di controllo e supporto al fornitore. Il Fornitore è la figura a cui è stato demandato il compito dello sviluppo del software. Un quarto attore è rappresentato dal centro di competenza CAST, il CoE (Centre of Excellence), responsabile della gestione dell’infrastruttura CAST, della produzione della reportistica, del controllo dei processi di misura, della valutazione degli eventuali falsi positivi e in genere delle issue connesse con il processo di misurazione. Il CoE può essere chiamato in causa da PM e QM per la valutazione di quelle violazioni per cui il fornitore richiede istanza di annullamento o il prolungamento dei tempi di risoluzione. In genere nelle prime fasi di progetto il CoE è composto da consulenti CAST esterni all’azienda che ha adottato la soluzione. Programmando un adeguato percorso di crescita delle risorse interne, un maturity model, è possibile e auspicabile che il CoE diventi un gruppo completamente interno all’organizzazione e autonomo.
Descrizione del processo nell’ambito del gate di sviluppo
La misurazione dei CD in questo ambiente è di tipo on demand, a discrezione del fornitore. Inserire il processo di misurazione nelle primissime fasi del ciclo di vita del software, garantisce che chi sviluppa entri immediatamente in contatto con la piattaforma di misurazione e le sue regole. Inoltre, è auspicabile che le operazioni di analisi e rimedio avvengano quanto prima (shift-left testing) e il codice trasportato in ambiente di collaudo raggiunga tale gate con un numero minimo di violazioni, idealmente zero. Per spingere ad un utilizzo a tappeto della soluzione il fornitore si potrebbe pensare di configurare il sistema SCM (Software Configuration Manager) in modo che non possa essere trasportato in ambiente di collaudo un CD che presenti nel gate di sviluppo almeno una violazione di tipo Golden. Questo tipo di vincolo è estremamente severo e implica una scelta accuratissima delle violazioni di tipo bloccante per evitare rallentamenti eccessivi.
Lo schema di processo può essere rappresentato come da grafico seguente, tenendo conto che i blocchi di colore verde rappresentano azioni di pertinenza del fornitore, quelli blu azioni di tipo automatiche.
A questo livello non è previsto alcun blocco di controllo da parte dell’organizzazione che ha adottato la soluzione, in quanto il fornitore deve semplicemente risolvere con il minor numero di cicli possibili tutte le violazioni rilevate in carico prima del trasporto del CD in collaudo. Se il fornitore non riesce a risolvere tutte le violazioni o non reputa opportuno risolverne alcune, e non è stato definito nessun processo di blocco, il CD potrà essere trasferito comunque in ambiente di collaudo, dove è previsto un momento specifico di valutazione e gestione delle violazioni, con possibili interazioni fra Fornitore, PM, QM e CoE.
Descrizione del processo di misura nel Gate di collaudo
La misurazione dei CD in questo ambiente è automatica: ogni CD trasportato viene sottoposto a misurazione con un report di violazioni inviato al fornitore e contestualmente al PM e al Quality Manager dell’Azienda.
Lo schema di processo può essere rappresentato come da grafico seguente, tenendo conto che i blocchi di colore verde rappresentano azioni di pertinenza del fornitore, quelli blu azioni di tipo automatiche e i blocchi di colore rosso afferiscono attività di pertinenza del PM, del Quality Manager con la partecipazione eventuale del CoE.
Il check point è la fase in cui PM e QM valutano lo stato del CD in termini di violazioni in carico e ne richiedono la risoluzione immediata. Da parte sua il fornitore può richiedere la verifica di eventuali sospetti falsi positivi, l’annullamento di specifiche violazioni, dettagliandone i motivi, e la richiesta di procrastinare la risoluzione di alcune altre per motivi legati al business. Il parere su tali richieste viene espresso, dopo un confronto, dal PM e dal Quality Manager con l’eventuale supporto, se necessario, del CoE CAST.
Riguardo alle violazioni residue, che andranno risolte immediatamente, se fosse necessario un nuovo test utente (UAT), il CD verrà riportato in ambiente di sviluppo. In caso contrario sarà possibile effettuare le modifiche di rimedio nel perimetro dell’ambiente di collaudo ove avverrà una successiva misurazione di verifica.
Descrizione del processo di misura del CD nel Gate di produzione
Il trasporto in ambiente di produzione di ogni CD viene sottoposto automaticamente alla misura. Come nel gate di collaudo i risultati sono resi noti in tempo reale al fornitore e contestualmente al PM e al Quality Manager. Risulta evidente che, da come è stato strutturato il processo nel gate immediatamente precedente, non dovrebbero essere rilevate violazioni sul codice, e la misurazione è volta solo a confermare l’assenza di violazioni nel CD in transito.
Lo schema di processo può essere rappresentato come da grafico seguente, tenendo conto che i blocchi di colore verde rappresentano azioni di pertinenza del fornitore, quelli blu azioni di tipo automatiche e i blocchi di colore rosso di pertinenza del PM e del Quality Manager con l’ausilio del CoE CAST.
Lo schema è stato disegnato in questo modo perché non si può assumere con certezza che non possano venire rilevate violazioni e quindi è previsto comunque un blocco di check point di verifica. Anche in questo caso potrà essere avviato un colloquio fra PM, QM e Fornitore per la gestione delle violazioni rilevate e verificarsi casi di annullamento.
Riguardo alle violazioni residue, quelle ritenute dal PM e QM da risolversi comunque e immediatamente, se fosse necessario un nuovo test utente, il CD verrebbe retrocesso in ambiente di sviluppo. In caso contrario sarà possibile effettuare le modifiche e la misurazione in fase di post avvio con tempi fissati dal PM e dal QM.
In assenza di violazioni residue, il passaggio in produzione sarà completato e l’attività inerente al trasporto del CD potrà considerarsi chiusa.
SHARE