Systems Engineering e CMMI

Cari amici,

accolgo volentieri l’invito di Marco Lisi, di condividere qui alcuni concetti (senza pretese di ordine né di completezza), a proposito del Systems Engineering, inteso come approccio globale alla gestione dei progetti tecnologici complessi. Anche in previsione dell'annunciato kick-off meeting dove, avendone la possibilità, potrei tenere una piccola presentazione sull'argomento project lifecycle management e tool integrati a supporto.Premetto che già da alcuni anni ho avuto modo di conoscere il Capability Maturity Model del Software Engineering Institute del Massachussets, e, pur non iniziando un percorso di certificazione, ho comunque deciso di seguire tale metodologia, poiché la ritengo un approccio più concreto e semplice, o per meglio dire progressivo, al miglioramento metodologico nella gestione dei processi.

Per quelli che non fossero familiari con il CMMi (anche se in questo contesto è forse più facile trovare qualcuno che mi corregga qualche imprecisione :-), riassumo brevemente i fondamenti del modello, che si compone di cinque livelli.

1° LIVELLO o INIZIALE – tutto è lasciato alla professionalità delsingolo progettista; non vi è alcuna metodologia consolidata inazienda.

2° LIVELLO o RIPETIBILE – esistono in azienda metodologie direquirements management, e/o di test engineering, ma non sonogeneralizzate nè integrate; inoltre sono gestite sulla carta, ocomunque con strumenti statici (word, excel).

3° LIVELLO o DEFINITO – esiste in azienda una metodologia di projectlifecycle management, ad esempio ECSS ESA, o ISO12207 (ex MIL498), o comunque una metodologia basata sul classico modello a “V”; la metodologia si basa su strumenti software e su database relazionale;in azienda esiste anche un sistema di project management economico (work in progress e controllo dei costi di commessa); i due sistemi, PM e PLM, non sono integrati.

4° LIVELLO o GESTITO – i sistemi di PM e PLM sono integrati, esiste quindi una dashboard generale che permette di correlare i costi di commessa, la gestione dei work package, con i requisiti, le attività di test, la gestione dei problemi, la gestione dei rischi, ecc…; il sistema permette di fare analisi accurate e comparative tra diversiprogetti, diversi gruppi di progetto, periodi diversi, ecc…

5° LIVELLO o OTTIMIZZATO – le metodologie acquisite a livello 4 sono consolidate, ed il management aziendale ha sedimentato la capacità di individuare tempestivamente le necessità di innovazione tecnologica e metodologica, di fare stime accurate ed attendibili per i lavori futuri basandosi sull’esperienza passata, ben catalogata nel database aziendale. Quanto sopra è, ovviamente, una elaborazione del modello del CMMi, dal punto di vista di un softwarista – qual sono – produttore di strumenti di supporto alle metodologie. In particolare mi sono permesso di collegare, più di quanto faccia il testo del CMM stesso, la metodologia ai tool utilizzati, poiché sono convinto che questo sia l’aspetto essenziale della crescita in maturità. In effetti gli estensori del CMM sono quantomeno gli unici creatori di standard che si siano spinti ad affermare apertamente l’importanza di avere in azienda delle /procedure software/ ben comprese e generalizzate. Leggendo qualsiasi altro standard, sembrerebbe che sia sufficiente acquisire le metodologie, peraltro sempre molto complesse e pesanti, e quasi mai articolate in percorsi progressivi.Mi verrebbe da dire che, se l’ingegneria deve necessariamente curarsi degli aspetti quantitativi e programmatici dei processi, la maggior parte degli standard non sono concepiti per l’ingegneria, perché prescrivono un sapere enciclopedico, da acquisire “tutto o niente”, e che finisce quindi col risultare poco o nulla /affordable/ per chi deve far quadrare la qualità con i budget e con la schedulazione di progetto.Chiuderò questa breve nota introduttiva (augurandomi che il discorso possa continuare) con alcune considerazioni pratiche, utili perl’ingegneria di progetto, appunto. Intanto dobbiamo purtroppo notare che il nostro paese è il fanalino di coda per quanto riguarda il CMMi: vi sono infatti solamente due aziende certificate a livello 3, e nessuna a livello 4 e 5. Dai dati in mio possesso (ma potrebbero non essere aggiornatissimi), le aziende certificate a livello 5 nel mondo sono una settantina, di cui 50 in India! Gioca certamente, da noi, anche la scarsa conoscenza di questo metodo, e certamente vi sono aziende che, se sostenessero un audit, si troverebbero almeno alivello 2, ma questo non ci fa certo onore. Il livello 2 è infatti quello – dico io – dove ci si porta la qualità sulle spalle. In tutta la mia esperienza (lavoro ormai da 37 anni nel mondo dell’informaticae dell’automazione!) ho sempre dovuto constatare che nessuno (ripeto nessuno, anche se dispone di struttura e budget invidiabili) riesce ad applicare decentemente un modello a V su un progetto mediamente complesso. Infatti la documentazione diventa rapidamente troppo pesante per seguire il progetto alla velocità necessaria, e quindi dal modello a V si ripiomba inevitabilmente in un raffazzonato waterfall, basato sulla memoria dei progettisti e dei project manager. Al termine la documentazione, pur costata tanto (perché sviluppata secondo gli standard), non è stata puntualmente aggiornata secondo le change che sono intervenute nel progetto, quindi non serve a nulla. Latracciabilità non è attendibile, quindi altri soldi gettati. Al livello 3 si comincia a ragionare, perché ci siamo dotati di un sistema di project lifecycle management completamente integrato, che ci permette di gestire le change in modo veloce ed efficiente, e di avere una tracciabilità online sempre aggiornata e quindi attendibile. Trovo che su questo aspetto ci sia poca chiarezza: in genere è ormai abbastanza accettato il concetto di requirements management, mentre per quella che è la mia esperienza vedo ancora abbastanza incompresa l’importanza di un’attività di test engineering debitamente documentata e tracciata (secondo i dettami degli standard ESA e MIL). Occorre disporre di un sistema completamente integrato, che gestisca i requisiti, i test, i problemi, i rischi, i segnali di i/o, e tutti gli oggetti metodologici che vale la pena tracciare (c’è solo PTESY, al momento, che io sappia, se mi consentite il piccolo spot pubbicitario). A questo livello cominciamo a mettere la qualità al lavoro per noi, anziché lavorare noi per la qualità. E qui mi fermo, perché, al momento, non ho esperienza del livello 4 (né nella mia azienda né in altre). Con i prodotti della mia azienda,arrivo infatti a servire le esigenze del livello 3, per quanto riguarda il project lifecycle management, completamente integrato. Sarei però felicissimo di avere l’opportunità di cominciare ad integrare il nostro PLM con dei tool di controllo economico di commessa, che peraltro saprei anche come fare, già orientati alla gestione di work package, ESA/MIL style. Chissà se l’idea di creare un piccolo consorzio fra tre o quattro utenti, ed Andromeda come fornitore, cui potrebbe eventualmente aggregarsi qualche altro fornitore produttore di tool sinergici, potrebbe avere gambe per tentare l’arrampicata a livello 4? Un prodotto italiano avrebbe certamente le caratteristiche di semplicità d’uso e praticità per interessare i mercati emergenti, che come dimostra l’India, bruciano le tappe molto più velocemente, rispetto al mondo post-industriale!

Tanti Auguri per un Grande 2009! Che sia l'anno del System Engineering in Italia!
Adriano Autino