Affidabilità e Sicurezza dei Sistemi e del Software

Capitolo 4° - Gli aspetti umani della progettazione, ovvero il

Project Management Affidabilistico

Parte 1 - Fase negoziale, Gestione del Contratto, Progettazione

di A. Autino e V. de Val

1. Introduzione

2. La forza del mercato e le ragioni dell’etica

3. La progettazione affidabilistica

3.1 La fase negoziale

3.1.1 Il budget affidabilistico nell’economia del progetto

3.1.2 La verifica delle competenze

3.1.3 La trappola più frequente

3.1.4 Il contratto affidabile

3.2 La definizione dei Requisiti e delle Competenze

3.2.1 Discussione del tipo di sistema

3.2.2 Definizione dei requisiti funzionali dal punto di vista utente

3.2.3 Definizione dei requisiti affidabilistici

3.2.4 Definizione dei requisiti diagnostici

3.2.5 Metodologie di disegno e di sviluppo

3.2.6 Affidabilità di utilizzo e criticità

3.2.6.1 Analisi della natura e dei flussi del processo produttivo, di esercizio o di ricerca e delle modalità di utilizzo del sistema

3.2.6.2 L'analisi dell’interazione uomo-macchina

3.2.7 Analisi e definizione delle competenze necessarie

3.2.7.1 La presenza dell'utente finale

3.2.7.2 Competenze affidabilistiche specialistiche

3.3 Progettazione

3.3.1 Performance ed affidabilità: scelte e convenienze

3.3.2 Suggerimenti per il disegno di applicazioni ad affidabilità media

3.3.3 Suggerimenti per il disegno di applicazioni ad alta affidabilità

3.3.4 Evoluzione dell’elettronica e dell’informatica ed evoluzione della progettazione

3.3.4.1 L’uso dell’elettronica per la progettazione

3.3.4.2 Correggibilità degli errori e correzione effettiva

3.3.4.3 L’uso critico delle metodologieSul piano metodologico, il fatto che esistano ormai procedure standard e check list per ogni fase

3.3.4.4 Il riuso ponderato del software

3.3.4.5 La qualità come parte integrata ed integrante del progetto

3.3.4.6 La cultura scientifica dell’affidabilità, ovvero l’insostituibilità dell’apporto umano

3.4 Il Management

3.4.1 Gli stili di management e l’emergenza

3.4.2 La gestione del contratto

4. Ringraziamenti

1. Introduzione

Nei Capitoli precedenti (ed in altri a venire) sono trattati prevalentemente gli aspetti tecnici e tecnologici della progettazione affidabilistica, pur con l’introduzione di frequenti note sugli aspetti umani. A questo punto della trattazione gli autori hanno sentito l’esigenza di dedicare un intero capitolo all’approfondimento di tutti gli aspetti umani della progettazione, e questo è l’obiettivo del capitolo presente. In questo capitolo anche i colori sono rovesciati: in nero si discutono gli aspetti umani, in rosso saranno inserite note e precisazioni inerenti aspetti tecnici. Il lettore potrà riscontrare, in questo capitolo, qualche ridondanza su argomenti trattati in altri capitoli. Gli autori hanno discusso e deciso di accettare questo episodico inconveniente, ritenendo un valore aggiunto, nell’economia generale dell’opera, la trattazione dell’argomento dal punto di vista degli aspetti umani, dopo averlo trattato dal punto di vista tecnico.

Siamo infatti convinti che l’approccio, la filosofia, la strategia, se volete, e tutti gli aspetti metodologici abbiano un’importanza almeno pari (se non a volte superiore) rispetto agli aspetti tecnologici della progettazione di sistemi, ovviamente quando l’affidabilità e la sicurezza siano considerati requisiti fondamentali. Prova ne sia il seguente paradosso: sistemi affidabili sono stati realizzati, negli anni ‘970 e ’980, con tecnologie di gran lunga inferiori a quelle disponibili negli anni 2000; per contro molti sistemi poco affidabili vengono realizzati con le tecnologie, enormemente piu’ performanti, di cui disponiamo nei tardi anni ’90 e nel nuovo millennio.

Qual’e’ la causa di tale paradosso? Sono molte: tendenze del mercato, questioni politiche, mutamenti di paradigmi progettuali, carenze del sistema di istruzione, carenze di elaborazione filosofica, sopravalutazione di aspetti economici, sottovalutazione del valore dell’affidabilità. Per riassumere: aspetti umani, appunto.

Se vi sono carenze e valutazioni errate, occorre innanzitutto metterle in luce, per potervi porre rimedio: qualsiasi intento euristico si ferma, ristagna e fallisce, se non vi è la capacità di trovare, riconoscere ed analizzare gli errori.

Il capitolo comincia quindi con l’analizzare le cause filosofiche, politiche e di mercato, della sottovalutazione dell’affidabilità. In seguito vengono analizzate le diverse fasi del progetto, mettendo in luce il nesso tra aspetti umani ed affidabilità del sistema progettato.

2. La forza del mercato e le ragioni dell’etica

Fin dagli anni ‘990 si è venuta affermando una tendenza di mercato che si è progressivamente insediata alla guida dell’intero sviluppo economico mondiale, ed ha determinato lo sviluppo delle tecnologie informatiche: la rete delle reti, detta Internet.

Con le macchine degli anni ’980 (la cui potenza fa ridere, nel 2000, qualsiasi ragazzino appassionato di computer) si potevano realizzare sistemi ragionevolmente vicini al concetto di determinismo. Venivano controllate, in real time, decine di migliaia di grandezze analogiche e di segnali digitali, con frequenze di campionamento anche molto elevate. Nonostante l’hardware potentissimo messo a disposizione dai costruttori, negli anni 2000 appare molto più difficile, anche per sistemisti esperti, soddisfare lo stesso requisito di determinismo. Il risultato è in apparenza lo stesso. Ciò che non è lo stesso è qualcosa di essenziale (per un sistema di automazione) che si può apprezzare solo nel tempo: ciò che in inglese si definisce reliability, cioè l'effettiva disponibilità del sistema nel tempo, la sicurezza che il sistema farà sempre ciò che l’utente si aspetta, e non rischierà di fallire proprio quella volta che avrebbe dovuto gestire una situazione critica. Poiché manca l’affidabilità, il risultato è diverso, e notevolmente inferiore, perché l’affidabilità, per un sistema di automazione, è un requisito di classe superiore rispetto alla presentazione grafica accattivante ed alla possibilità del sistema di comunicare con l’esterno.

Due parole per chiarire perché parliamo di reliability, più che di availability. Availability e’ una parola dal significato alquanto specifico, in affidabilita’: essa indica la disponibilita’ del sistema nel tempo, e dipende da quanto spesso il sistema si guasta (MTBF = Medium Time Between Failures) e da quanto tempo ci voglia a ripararlo (MTTR = Medium Time To Repair). Questo significa che un sistema che si guasta molto spesso ma si ripara subito ha un’availability elevata. Ora, consideriamo un’applicazione SW che si blocca spesso ("si pianta", dicono i softwaristi). Per farla ripartire basta solitamente rilanciarla, quindi l'MTTR è molto bassa. Da questo punto di vista l’availability del SW (e sottolineo del SW) e’ elevata. Che importa se WORD si pianta ogni tanto? Basta un minuto per farlo ripartire. Ma, per un sistema di automazione, ogni volta che il SW si pianta rischia di distruggere l’impianto che controlla. Alla luce di quanto sopra possiamo affernare che, per i sistemi di automazione, l'affidabilità dipende più dalla reliability (MTBF) che dalla availability.

Le cause di tale paradosso sono culturali, e non tecnologiche: Il mercato ha decretato il primato dell’entertainment e della comunicazione in rete sull’automazione. La cultura dei sistemi deterministici è stata poi relegata in un ghetto dove non è più manutenuta e quindi non può più evolversi, o, quantomeno, non può evolversi alla stessa velocità della cultura dei sistemi stocastici, i cui requisiti di grande apertura e compatibilità (al prezzo di una elevata fallibilità) sono più adatti alle tecnologie della comunicazione. L’evoluzione dell’hardware ha messo a disposizione potenze di calcolo e dimensioni di memoria enormi rispetto alle esigenze, rendendo apparentemente obsolete le preoccupazioni riguardanti le capacità dell’hardware. Non vi sono peraltro impedimenti tecnologici hardware, è bene notarlo -- ove fosse riconosciuta l’importanza dei requisiti di affidabilità -- alla riapplicazione di una filosofia affidabilistica alla progettazione di applicazioni, soprattutto nel campo dei sistemi real time.

In altra parte di quest’opera tratteremo in dettaglio i requisiti di un sistema operativo deterministico orientato al real time, e vedremo le differenze rispetto al sistema operativo che va per la maggiore nelle applicazioni orientate alla rete. Qui ci limitiamo a notare alcune differenze eclatanti. Tutta la progettazione non finalizzata alla comunicazione in rete subisce l’enorme pressione, una vera egemonia culturale, dell’orientamento dell’informatica alla rete (per i programmatori più giovani informatica è addirittura sinonimo di rete). L’orientamento dell’informatica alla comunicazione ha decretato l’obsolescenza del concetto di sistema chiuso. Un sistema costantemente aperto è, per definizione, esposto a qualsiasi interferenza e disturbo proveniente dall’esterno, quindi assolutamente non deterministico. Mentre i sistemi operativi dell’era dell’automazione rifiutavano di eseguire un’applicazione non configurata nel contesto determinato dal progettista, i sistemi operativi dell’era internettiana eseguono qualsiasi applicazione, purchè riescano a negoziare un protocollo d’intesa anche sommario. Ne risulta spesso un decadimento delle performance della macchina "ospite". Il sistema operativo non è in grado di calcolare in anticipo se l’applicazione ha risorse sufficienti, quindi la esegue comunque, anche quando ciò metterà in crisi tutto il sistema.

Non esiste comunque alcun sistema operativo che rifiuti di eseguire un’applicazione, e neppure un sistema operativo capace di valutare quali siano le risorse richieste ad un’applicazione, soprattutto in termini di CPU. I sistemi di una volta non eseguivano nulla che non fosse configurato a livello di progetto: tutte le external dovevano essere note al linker (prima della nascita delle dll=dynamic link library). Il progettista decideva quali eseguibili lanciare, quando ed a che condizioni lanciarli, configurando lo schedulatore di sistema. Ovviamente le tecnologie oggi in uso sono quelle che hanno permesso di aprire i sistemi e quindi far decollare le comunicazioni, ma il progettista dovrebbe avere la possibilità di regredire il suo sistema, se l'obiettivo progettuale è un altro! A metà strada (sistema semiaperto) potrebbe stare, almeno, un funzione dell'OS capace di negoziare con l'applicazione intruder un budget di risorse: di quanta memoria ha bisogno l'applicazione richiedente? Fino a tot puo' entrare, altrimenti rimane fuori. L'OS, se la funzione "guardiano" è attiva, lancia solo applicazioni che rispondono, e poi abortisce brutalmente le applicazioni che, durante il lavoro, superano quanto concordato. L'utente saprebbe che tali applicazioni dichiarano il falso, e potrebbe disinstallarle sapendo di aver fatto la cosa giusta.

Viene utilizzata la grafica sempre e comunque, anche quando non è necessaria, e la grafica assorbe un’enorme quantità di risorse del sistema.

A quanto sopra si può obiettare che basta usare altri sistemi operativi. Ma, avendo poco mercato, l’utilizzo di tali prodotti presenta i rischi tipici dell’utilizzo di prodotti non standard: scarsa manutenzione, rischio di sparizione del produttore, mancanza di second source, scarso feedback da campo e quindi scarsa evoluzione.

Intendiamoci: il sistema operativo che va per la maggiore, pur non essendo un sistema operativo Hard Real Time, puo' essere più che sufficiente per la maggior parte delle applicazioni, anche con requisiti di elevata affidabilità. Il problema più grave è, come abbiamo già detto in altre parti di quest'opera, di natura culturale. I problemi indicati (uso eccessivo della grafica, caricamento di programmi senza valutazione del budget delle risorse, ecc.) sono errori non del sistema operativo, ma del progettista software, che denotano una carenza di cultura sul real-time. Inoltre la documentazione del sistema operativo in questione è un mare talmente vasto che ci si può trovare praticamente ogni cosa ed il suo contrario, e non si è mai certi che il metodo trovato non abbia controindicazioni nascoste. Non esiste la possibilità di configurare il sistema per bloccare automaticamente certe applicazioni o, se si preferisce, la macchina NT non è assolutamente in mano al progettista, bensì all'utente, spesso personale annoiato intercambiabile perché i sistemi si suppongono a prova di scimmia.

Ovviamente non possiamo cavarcela semplicemente dividendo l'Esecutivo Real-Time dall'Interfaccia Umano-Macchina, mettendole su due macchine diverse. Anche l'IUM deve essere affidabile! Un'IUM inaffidabile rende inaffidabile tutto il sistema: il sistema è in allarme e non lo si vede perché il sinottico è bloccato, oppure l'operatore crede di aver dato un comando manuale ed il comando non è uscito dalla WorkStation, oppure non si vede il feedback di un comando e, ripetendolo, si mette in crisi l'impianto. Sono tutte situazioni gravi determinate da un'IUM inaffidabile.

L'OS che va per la maggiore ha, è vero, la possibilità di definire per un'applicazione il modo operativo real time, di stabilire le priorità (fino a 16) dei processi e dei thread e di disabilitare il boost dei processi da parte del sistema operativo (l'OS decide autonomamente quale processo deve essere spinto più di altri, cioè deve ricevere più risorse in un dato momento). Tuttavia nulla impedisce ad un utente annoiato di far girare, in concorrenza con i processi real time, varie istanze di un browser per internet, che a loro volta aprono popup a catena ed installano di tutto sul disco fisso, e poi lanciano in esecuzione filmini e quant'altro. Ancora una volta tocchiamo problemi culturali, più che tecnici: ma un OS Real Time evoluto dovrebbe dare al progettista ed al System Administrator gli strumenti per gestirli adeguatamente. Ad esempio metodi più certi e meno casuali per intervenire con sicurezza eliminando i driver e le applicazioni indesiderate, ed anche mettendo dei blocchi (sotto password) che impediscano la reinstallazione di certe applicazioni. In genere non si è mai certi di aver letto tutto quanto necessario allo scopo, né che alcune iniziative intraprese (apparentemente fattibili secondo la documentazione) non siano in contraddizione con esigenze basilari, visto anche che i progettisti dell'OS che va per la maggiore danno per scontato che i progettisti non devono sviluppare altro se non applicazioni internet.

L'OS che va per la maggiore non è certo un vero OS real-time. Ad esempio, il context switching tra processi non ha un tempo massimo garantito, ma neanche sotto VAX/VMS era garantito. Inoltre il clock interno non è affatto preciso, e varia di 10 ms. in più o in meno, il che ne impedisce l'utilizzo in contesti veramente hard real time. Si tratta tuttavia di un sistema che permette, se usato correttamente, di realizzare in modo affidabile il 90% delle applicazioni real-time. Se quello che si vede in giro è deprimente, la causa va ricercata nel fatto che i progettisti oggi, anche nel campo di controllo di processo, si sono formati culturalmente sul PC di casa. La cultura informatica e progettistica si può definire hobbistica: capaci di "smanettare", sempre aggiornati sull'ultima bubbola uscita sul mercato, ma incapaci di definire, disegnare e progettare una vera applicazione informatica.

VAX/VMS, il sistema operativo DEC nato e cresciuto per l'automazione, ed oggi terminato dal suo sconfinato concorrente (l'OS che va per la maggiore), può essere preso a riferimento solo fino ad un certo punto. Il fatto è che VMS (o la cultura progettuale che ne era alla base) non si è evoluto, quindi la cultura real time è ferma, ed approfitta solo marginalmente e quasi per sbaglio dell'enorme crescita tecnologica dell'hardware. Proviamo ad immaginare un OS Real Time che, invece di cedere il passo all'inizio degli anni '990 a prodotti orientati alla rete, avesse continuato la sua evoluzione, sfruttando a pieno l'evoluzione tecnologica dell'hardware. Non limitiamoci però a sognarlo, perché di tale strumento avremo un gran bisogno, quando ci sveglieremo dalla trance internettiana, e ci accorgeremo finalmente che il pianeta si sta intanto sgretolando sotto i nostri piedi.

Non c'è neppure una vera esigenza di inventare molti concetti nuovi. In passato, quando doveva fare i conti con le capacità limitate della macchina, il progettista (in particolar modo di sistemi real time) era costretto a:

  1. far stare gli algoritmi in poco spazio di memoria

  2. rendere il codice il più possibile snello, per consentire alle applicazioni real-time di girare senza sforare il ciclo macchina

  3. limitare il più possibile le dimensioni dei file di log, in modo da non riempire velocemente i dischi del sistema

  4. calcolare accuratamente il flusso di informazioni in rete, in base alle capacità della rete locale, in modo da non avere troppi conflitti (con conseguente perdita di dati, e quindi di capacità di controllo del processo)

Con il crescere della potenza dell’hardware, si è progressivamente operato un mutamento radicale di approccio, da parte del progettista. Processori a 64 bit, pentium e quant’altro, centinaia di Mbyte di memoria, dischi da centinaia di Gigabyte, danno al progettista spazio di memoria e potenza molto superiori a quanta ne serva per le applicazioni da sviluppare.

I concetti, duramente appresi in precedenza, dell’economia di risorse, sembrano non valere più nulla. Da una gestione di risorse scarse (cui la nostra storia, non solo tecnologica, ci ha dolorosamente prepaparati), siamo passati (almeno nella tecnologia elettronica) alla gestione dell’abbondanza, per la quale non siamo filosoficamente preparati.

In sé, il concetto non è difficile: per quanto i possessori di una casa piccola possano aver spesso pensato quanto starebbero meglio in una casa grande, la casa grande non è, di per sé, garanzia di ordine ed efficienza. Si può gestire male tanto uno spazio grande quanto uno piccolo. Anzi: più è grande lo spazio che abbiamo a disposizione, più spaventoso (e quindi permanente) sarà il disordine, se non siamo capaci di amministrare saggiamente il nostro spazio.

Qualcosa di analogo succede ai sistemi. Avendo a disposizione potenze enormi e spazi virtualmente illimitati, il progettista si cura poco di calcolare quanto e come la sua applicazione utilizzerà spazio e potenza di calcolo. Ne risulta un accatastamento abominevole di programmi e basi dati, fidando che l’indicizzazione ed i legami tra frammenti (grazie all’enorme potenza di calcolo) risolvano tutto. Ma così non è, e le applicazioni falliscono spesso e volentieri, le prestazioni della macchina diminuiscono con l’andar del tempo, e viene il momento in cui siamo costretti a reinstallare il sistema operativo, perché una macchina di potenza smisurata è ridotta a trascinarsi penosamente.

Si verifica, quindi, la situazione paradossale di cui parlavamo all’inizio: nonostante l’enorme crescita della potenza degli elaboratori, la progettazione affidabilistica rischia di trovarsi in un cul de sac, senza vie d’uscita. A meno che, alla forza, per molti versi stolida, dei numeri del mercato, non si riesca ad affiancare la ragione dell’etica, vale a dire le esigenze dello sviluppo umano. Occorre quindi un’entità di orientamento del mercato e degli investimenti che sia capace di dare pesi diversi a numeri che per loro stessa natura non possono che essere diversi: un peso più leggero ai numeri del mercato consumer, uno più pesante ai numeri del mercato industriale. In questo modo, anche se il rapporto tra mercato industriale e mercato consumer fosse, poniamo, 1 a 1.000.000 i prodotti industriali non rischierebbero l’estinzione, diventando, in qualche modo, una specie protetta. Se siamo capaci di tanto per salvare i panda, perché non dovremmo trovare il modo di salvare i sistemi operativi deterministici?

Noi umani (sia progettisti che utenti di sistemi informatici) dovremmo quindi acquisire migliori capacità euristiche, ad esempio la capacità di differenziare fortemente gli sforzi, per obiettivi diversi: una macchina per le telecomunicazioni, con requisiti di apertura stocastica, o addirittura euristica; una macchina per l’automazione, chiusa, con requisiti fortemente deterministici. Se il mercato tende a sopprimere tale differenziazione, significa semplicemente che non è finito il compito di entità direttive capaci di operare indipendentemente dagli scopi del mercato, magari non al di sopra o in contrasto, ma certamente tenendo conto di parametri diversi da quelli della pura domanda ed offerta.

3. La progettazione affidabilistica

Il lettore l’avrà ormai capito: gli autori di quest’opera sono convinti che, più degli aspetti tecnologici, più della potenza dell’hardware e della flessibilità del software, la progettazione di un buon sistema affidabile e sicuro si deve Alla cura nel gestire quelli che abbiamo definito Aspetti Umani.

In questo capitolo arriviamo anche a criticare le procedure e le metodologie, che pure in altre parti di quest’opera indichiamo come strumenti utili, o almeno a criticare l’uso che spesso si fa delle metodologie. Il fatto è che gli aspetti umani sono determinanti in tutte le fasi della vita di un sistema: dalla fase negoziale fino alla fase di utilizzo. Non v’è alcuna fase in cui gli umani possano disinteressarsi della progettazione e lasciar fare alla macchina, o alla metodologia (che assimiliamo qui allo stesso concetto di macchina, o ad un più generale concetto di golem programmato, ma privo di sensibilità ed esperienza), per quanto la metodologia possa essere accurata e la macchina potente.

Ed in questo capitolo osiamo anche mettere nero su bianco ciò che ogni softwarista esperto sa bene in cuor suo, e che raramente esterna, per non spaventare clienti ed utenti: mai fidarsi ciecamente dei computer, ed ancor meno del software!

Ogni volta che si fidano eccessivamente della tecnologia o delle metodologie gli umani non fanno altro che dare una possibilità al disastro. Ogni volta che il valore dell’esperienza umana viene appiattito, e si indulge in pianificazioni che trattano le persone come componenti uguali, omologhi ed interscambiabili, si sceglie, coscientemente, di dare una possibilità al disastro. Così succede anche ogni volta che si affida una metodologia, ritenuta supercollaudata e sicurissima o, come si dice in gergo, a prova di stupido, nelle mani di persone inesperte e non sufficientemente formate. Stupidi? No, presuntuosi ed ignoranti, piuttosto, ma non per colpa loro, il più delle volte per colpa dei loro responsabili, che troppo spesso non vedono l’ora di disinteressarsi dei "dettagli" e delle "technicality" per darsi arie da grandi manager!

Se volete un esempio pensate al disastro dell’Ariane 5, che doveva mettere in orbita i satelliti Cluster e si è autodistrutto grazie… alla procedura PSS-05 (lo standard di qualità dell'ESA)! Il PSS-05 prescrive il riuso del software ogni volta che sia possibile, ma non prescrive evidentemente di rianalizzarne nel dettaglio l'utilizzabilità in ogni caso specifico, né di eseguire tutti i test necessari per assicurarsi che, nel nuovo sistema, non manchi nulla di essenziale. È quindi successo che, a bordo dell'Ariane 5, sia stato utilizzato un sistema di controllo precedentemente usato (e quindi molte volte positivamente collaudato!) per l'Ariane 4. L'Ariane 5 è però una macchina più complessa del suo predecessore, Ariane 4, e quindi dotata di sensoristica più complessa ed avanzata. Al sistema di controllo sono pervenuti dati che non era in grado di interpretare, poiché mancava delle parti software necessarie. Nelle fasi di integrazione, evidentemente, erano mancati anche i test che avrebbero permesso di scoprire tale mancanza. Il sistema ha quindi creduto ad un malfunzionamento, ed ha scatenato l'autodistruzione del vettore, mentre tutto procedeva invece normalmente (durante l'ascesa il sistema di bordo è programmato per autodistruggere il razzo in caso di malfunzionamenti, onde evitare il rischio di ricaduta su zone abitate). È chiara quindi la lezione: il riuso di software collaudato può essere utile, a patto che il progettista (cioè l'umano) ne rianalizzi, puntualmente ed in modo dettagliato, l'applicabilità nel nuovo caso, ed identifichi con certezza le parti nuove da aggiungere. Lo stesso vale per le procedure: conservare la procedura di un'esperienza precedente è utile perché ci permette di non dover reinventare tutti i passi di sviluppo e test da eseguire nel nuovo caso, ma dobbiamo comunque rianalizzarla, puntualmente ed in modo dettagliato, per vedere quali passi dobbiamo aggiungere, a causa della complessità specifica del nuovo sistema.

Non sarà mai possibile quindi (come sperato da schiere di burocrati avidi e senza fantasia) dare la procedura collaudata in mano ad un novellino (servo della macchina) e lavarsene le mani: serve il contributo insostituibile di un umano esperto, e di umani novellini appositamente formati da umani esperti. La macchina sarà nostra serva fedele ed efficiente, se sapremo considerarla tale, e non attribuirle poteri/saperi che essa non può avere.

3.1 La fase negoziale

L’affidabilità, come è stato già detto nei precedenti capitoli, non è qualcosa che si possa aggiungere al termine del progetto, ma una filosofia che deve informare tutte le fasi del progetto, a partire dalla fase che non viene in genere considerata da nessuna metodologia: quella del negoziato iniziale tra utente e fornitore. In questa fase occorre tener conto, almeno, dei seguenti elementi:

  1. l’affidabilità ha un suo costo, e richiede un proprio budget,

  2. il problema delle competenze necessarie, e del loro costo, va affrontato in fase negoziale,

  3. trasparenza e collaborazione sono preferibili ad orgoglio e furbizia,

  4. non esiste un implicito "stato dell’arte",

  5. non sempre conviene fissare il prezzo nel momento della scelta del fornitore,

  6. un contratto affidabile può essere il frutto solo di un lavoro di collaborazione tra utente e fornitore.

3.1.1 Il budget affidabilistico nell’economia del progetto

Se nella fase negoziale non viene dato il giusto peso ai requisiti affidabilistici, l’affidabilità, senza budget, resterà al più una vaga intenzione da parte del fornitore ed un pio desiderio da parte del cliente. Quando sarebbe il momento successivo più opportuno, per considerare le esigenze affidabilistiche? Se si analizza minimamente il problema, ci si rende conto che questo momento non verrà mai, o anche peggio: il cliente, non volendo ammettere di aver trascurato un aspetto così importante (o magari anche in buona fede), tenderà a dare per scontati i requisiti affidabilistici, esigendone l’implementazione da parte del fornitore senza costi aggiuntivi. Il fornitore, combattuto tra il rischio di apparire poco professionale e con poca esperienza, e l’intenzione di lucrare sulle "dimenticanze" del cliente, si barcamenerà in operazioni di piccolo cabotaggio, che non aggiungeranno affidabilità al sistema.

Dal punto di vista della progettazione, affrontare il problema dell’affidabilità a progettazione iniziata – quale che sia la fase – non ha senso: si tratterebbe in ogni caso di rimettere mano pesantemente a quanto già disegnato o sviluppato. Anche se cliente e fornitore avessero tardivamente concordato un’aumento del budget con obiettivi affidabilistici, reimpostare filosoficamente quanto già progettato è sempre un’operazione diseconomica ed anche … meno affidabile, sul piano dei risultati, rispetto all’aver dato fin dall’inizio il giusto peso ai requisiti affidabilstici.

Nessun dubbio, quindi, e nessun timore di passare per disinformati o di mettere in tavola problemi scontati. È proprio sul dar per scontate cose che non lo sono e sul timore di fare brutte figure che nascono i peggiori bagni di sangue (come si definiscono, in gergo degli automatari, le commesse finite male).

In fase di richiesta d’offerta il cliente ha quindi tutto l’interesse a dettagliare i requisiti affidabilistici, se possiede la cultura necessaria, oppure a richiedere esplicitamente ai fornitori di mettere in chiaro in offerta il livello di affidabilità offerto, nonché le tecnologie e metodologie che intendono utilizzare per questo specifico obiettivo. Il fornitore dimostrerà maggior professionalità, ove la richiesta d’offerta del cliente non contenga specifiche affidabilistiche, a dettagliare comunque, nella propria offerta, i contenuti affidabilistici.

Specialmente nel caso di sistemi dalla cui affidabilità dipenda poi la vita o la salute degli utenti (sistemi di trasporto spaziali, di terra, di cielo o di mare, medicali, gestione traffico, automazione d’edificio o stabilimento, per non dire che i più immediatamente identificabili) la definizione accurata del budget affidabilistico è un preciso dovere morale, sia per il committente che per i fornitori.

3.1.2 La verifica delle competenze

Fra gli aspetti critici tipici della fase negoziale, va menzionata la vendita di competenze allo scoperto. Non è infrequente, nella contrattazione riguardante sistemi informatici, che il fornitore si trovi a proporre un prodotto che è in grado di realizzare con risorse e/o competenze proprie, poniamo, soltanto al 70%. Per il restante 30% egli confida di trovarlo a sua volta sul mercato, di integrarlo nella propria fornitura e quindi arrivare comunque all’obiettivo. Questa modalità di fornitura è in genere accettata, in un contesto di mercato in cui è molto difficile, per non dire impossibile, che una sola azienda racchiuda in sé tutte le competenze necessarie per realizzare un sistema, specie se complesso. Ma l’operazione non è priva di rischi, sia per l’utente che per il fornitore: poiché non sempre il fornitore riesce ad ottenere le offerte dai potenziali subfornitori in tempo per inserire costi verificati nella propria offerta al cliente, a volte si trova ad uscire con un prezzo solo parzialmente basato sull’esperienza. La stima può quindi risultare anche clamorosamente sbagliata.

Un altro aspetto critico, nel caso di vendita di competenze allo scoperto, è quello della capacità effettiva, da parte del fornitore, di supervisionare ed integrare le parti che a sua volta subappalta. Questa viene in genere data per scontata, ma dipende, come sempre, dalla complessità dei problemi affrontati, dalla quantità e qualifica professionale delle persone che l’integratore intende impiegare, e da mille altri problemi contingenti. Ultimo, ma non per importanza, l’effettiva esperienza dell’integratore: se le competenze/esperienze mancanti riguardassero aspetti fondamentali, ad esempio, il progetto sarebbe critico fin dalla partenza.

Ancorchè data spesso per scontata, come se si trattasse di una capacità che è quasi offensivo mettere in dubbio, l’effettiva capacità di integrare parti di forniture diverse, coniugando esperienze diverse ed a volte molto distanti tra di loro, non è poi così diffusa. Spesso si tratta di inventare sul campo dei veri e propri protocolli di comunicazione tra linguaggi diversissimi, la cui diversità non è però così evidente ad un esame superficiale, quale quello che troppo spesso intercorre tra commerciali ed uffici acquisti, dove l’unico parametro determinante sembra essere l’ultima pagina dell’offerta (quello economico).

Non sarà quindi tempo perso, in fase negoziale, verificare attentamente le valutazioni e le competenze in offerta: se esistono dubbi circa le valutazioni attendere le offerte dei subfornitori, se esistono dubbi sulle effettive capacità di supervisione ed integrazione, reperire sul mercato le competenze necessarie.

3.1.3 La trappola più frequente

La trappola più frequente, nei contratti di fornitura di sistemi di automazione sta in ciò che non viene detto né tantomeno scritto nel contratto o nell’ordine. Le cause più frequenti di tali omissioni sono le seguenti:

  1. Il cliente intende dare per scontate alcune funzionalità, non esplicitandole nel contratto. Queste non entreranno quindi nel precalcolo dei costi, ma il cliente le esigerà alla fine, sostenendo che lo stato dell’arte le comprende, e che non pensava di doverle richiedere esplicitamente ad un fornitore esperto.

  2. Il fornitore intende escludere certe funzionalità dalla fornitura iniziale, in modo da tenere basso il prezzo, e battere così la concorrenza. Una volta preso l’ordine e sviluppato il sistema, quando il cliente chiederà le funzioni mancanti dovrà accordarsi per estensioni d’ordine.

  3. Il cliente ignora che certe funzioni sono necessarie. Il fornitore no, ma evita di farlo presente in fase negoziale (sperando di lucrare in seguito). Oppure anche il fornitore lo ignora: è il caso classico in cui "Dio li fa e poi li accoppia".

  4. Il fornitore ignora che certe funzioni sono necessarie. Il cliente no, ma evita di farlo presente in fase negoziale (sperando di ottenere funzioni gratis in seguito).

  5. Per timore di apparire poco esperto (e con la vaga speranza di lucrare in seguito), il fornitore dettaglia pochissimo l’offerta, vantando grande esperienza, competenza e padronanza dello "stato dell’arte" in quel genere di forniture.

  6. Oppure complesse combinazioni dei punti elencati.

Come si può vedere si tratta comunque di un misto di orgogli, furbizie e pregiudizi in cui spesso, per maggior sventura di ambedue le parti, le intenzioni omissive di una parte concordano con le intenzioni omissive dell’altra parte, sia pure per obiettivi diametralmente opposti: per il cliente pagare meno ed ottenere di più, per il fornitore guadagnare di più e dare meno.

L’esperienza dovrebbe aver ormai dimostrato che, in realtà, né i committenti né i fornitori guadagnano da situazioni contrattuali quali quelle che si vengono a determinare con accordi volutamente o per ignoranza lacunosi. Meno che meno guadagneranno gli utenti dei sistemi che dovessero fortunosamente essere messi in funzione, con storie contrattuali di questo tipo.

Per evitare questo tipo di veleno esiste un antidoto potente e di sicura efficacia: la trasparenza e la collaborazione, attenendosi a poche semplici regole.

  1. Cliente e fornitore hanno tutto l’interesse ad iniziare a collaborare sin dalla fase negoziale.

  2. Se si fa riferimento ad uno standard, o anche a norme di uso comune non scritte, dettagliare sempre di cosa si tratta e quali ne sono i requisiti fondamentali.

  3. Se si sa o si teme di non disporre di tutte le competenze necessarie, preoccuparsi da subito di definirle, reperirle e conoscerne disponibilità e costi.

3.1.4 Il contratto affidabile

Nella fase negoziale il momento più critico è quello in cui il cliente sceglie il fornitore, tra quelli che hanno presentato offerta, e decide il prezzo. Non è affatto infrequente che il fornitore che ha presentato l’offerta migliore (cioè più dettagliata) perda la gara perché il suo prezzo risulta più elevato di altri, che hanno dettagliato meno.

In questo momento tutte le carte sono in mano al cliente. Egli sa quante offerte ha ricevuto, quali sono i prezzi e quali le forniture offerte. Il livello di dettaglio e la chiarezza delle offerte dipende anche, ovviamente, dalla chiarezza della richiesta d’offerta che aveva inviato ai partecipanti alla gara. Teoricamente il cliente dovrebbe avere tutti gli elementi per decidere con consapevolezza. Eppure la sua scelta solo in un caso può essere sicura: nel caso in cui egli stesso possieda tutte le competenze necessarie per valutare tecnicamente le offerte ricevute e le capacità dei fornitori. Sappiamo bene che il caso di cui sopra è molto raro, data la vastità delle conoscenze e delle specializzazioni dell’era elettronica.

Quindi la scelta è in realtà molto difficile: si tratta di valutare competenze e capacità specialistiche che non si possiedono. Inoltre nella maggior parte dei casi l’ultima parola non spetta ai tecnici, bensì all’ufficio acquisti, e l’ufficio acquisti, del tutto digiuno di competenze tecniche, decide in base a motivazioni economiche. Può darsi, a volte, che chi ha offerto al prezzo migliore sia quello più efficiente, perché più esperto, delle forniture in questione, ma spesso è semplicemente un appartenente a una delle categorie viste al paragrafo precedente.

Inoltre, c’è un altro aspetto fondamentale, di cui tenere conto: quanto più il sistema è complesso, più aumenta la probabilità che il costo calcolato in fase di gara sia impreciso. Nel caso di sistemi molto complessi, le cui caratteristiche si avvicinino a quelle di un progetto di ricerca, il momento della scelta del fornitore non dovrebbe coincidere con quello della fissazione del prezzo.

Ne consegue, in questo caso, che i criteri di scelta prevalenti dovrebbero essere altri, rispetto a quello del prezzo. Il fornitore dovrebbe essere scelto in base a:

  1. Miglior dettaglio dell’offerta tecnica.

  2. Qualità e quantità delle domande di chiarimento tecnico.

  3. Maggior quantità e qualità di riferimenti a standard metodologici e tecnologici citati.

  4. Maggior trasparenza di obiettivi ed intenzioni, relativamente al progetto considerato.

  5. Precalcolo dei costi ed aspettative di ricavo più trasparenti.

  6. Miglior dettaglio delle competenze fornite direttamente ed indirettamente.

  7. Miglior definizione delle figure professionali che si occuperanno del progetto.

  8. Miglior disponibilità nelle fasi di commissioning e di avviamento del sistema (se queste fasi si prevedono cospicue).

  9. Valutazione più realistica delle fasi di commissioning ed avviamento del sistema.

  10. Migliori referenze nel settore applicativo considerato (nel caso dei fornitori che si propongono come esperti).

Una volta scelto il fornitore, dovrebbe iniziare una fase di chiarimento del progetto, regolata contrattualmente a time-material, in cui cliente e fornitore definiscono congiuntamente i costi del progetto, tenendo nel dovuto conto le competenze necessarie, i costi dell’affidabilità, e stimando opportunamente il peso ed il costo delle fasi di installazione e commissioning.

Solo al termine di tale fase si può pensare di comporre un contratto rispondente a criteri affidabilistici.

Il cliente non sarebbe ancora, comunque, "legato mani e piedi" al fornitore scelto. Avrebbe ancora la possibilità di affidare ad altri parti di fornitura su cui il fornitore scelto non gli desse sufficiente affidamento, o addirittura, pagato il fornitore per l’analisi svolta, di utilizzare il lavoro di chiarimento fatto per dare il lavoro ad altri, in caso di fallimento della collaborazione.

In questa procedura vi sono vantaggi per entrambi: il cliente beneficia di un periodo di "prova" del fornitore scelto, sia il cliente che il fornitore professionalmente seri hanno tutto l’interesse ad un contratto più dettagliato possibile, poiché ne risultano minimizzati i rischi di ritardi ed inefficienze in fase di inizio dell’operatività del sistema.

3.2 La definizione dei Requisiti e delle Competenze

La fase di definizione dei Requisiti è stata indicata, in altre parti di quest’opera, come la fase più critica di un progetto complesso. Una successiva discussione tra gli autori ha portato ad equilibrare in parte questo giudizio, indicando le fasi di definizione dei requisiti e quella di test come le fasi più critiche. Dovunque si ponga l’accento non v’è dubbio che la fase di definizione dei requisiti sia di estrema importanza: se non si sa bene quali risultati si vogliono ottenere sarà difficile svolgere una progettazione logica ed efficiente. Può sembrare una banalità, ma non è affatto infrequente che un progetto parta con una concezione abbastanza nebulosa o meramente macroscopica delle funzionalità che si vogliono realizzare. Ed ancora, per ignoranza, orgoglio o furberia (ma non si dirà mai abbastanza contro tali approcci tipici dell’era preindustriale) clienti e fornitori spesso non disdegnano affatto di avventurarsi su sentieri appena abbozzati con in mano contratti a prezzo fisso! Sullo sfondo si vedono già gli avvocati fregarsi le mani, pregustando laute parcelle. Se invece la definizione dei requisiti funzionali avviene, come abbiamo cercato di tratteggiare nella parte precedente, detta del Contratto Affidabile, aumentano le probabilità di sviluppare un progetto con reciproca soddisfazione delle parti.

Ma occorre parlare subito di una dimenticanza molto frequente: la definizione delle competenze. Nella stragrande maggioranza dei casi il gruppo di progetto che inizia a riunirsi per definire i requisiti del sistema non dedica sessioni specifiche alla verifica delle competenze necessarie, contro le competenze presenti. Come altri elementi di grande importanza, questo viene dato per scontato o, tutt’al più, si accetta per buona la consulenza di qualche tuttologo, molto bravo a parole. Fateci caso: questi personaggi hanno quasi sempre la puzza sotto il naso, e rifuggono dalle cosidette technicality. Si possono così spendere ore e giornate (costosissime), discutendo in astratto, in perfetto progettualese, di funzioni e costi senza mai entrare in dettaglio, né mai esaminare in concreto, anche solo a titolo di esempio, qualcuna delle funzionalità di cui si parla. Se così si facesse si scoprirebbe, in molti casi, che manca qualche competenza, e si farebbe ancora in tempo (se il precalcolo dei costi non è ancora chiuso), ad inserirla. Poiché tale analisi avviene il più delle volte a prezzo già chiuso lo spirito che prevale è quello della squadra che serra le fila, e qualche capitano coraggioso decide che se la caverà in qualche modo. Nel mondo dei sistemi non c’è nessun progettista che si tiri indietro, quando si tratta di reinventare l’acqua calda! Anzi, in genere costui è ben felice di farlo, perché intimamente convinto che sarà proprio lui a trovare la brillante soluzione che non era mai venuta in mente a nessun’altro prima. Nel 90% dei casi, ignorando il famoso stato dell’arte, farà qualcosa che è inferiore ai più banali prodotti esistenti sul mercato e, siccome l’avrà riprogettato da capo, pretenderà anche di farsi pagare tutte le ore spese nella progettazione (stiamo ovviamente estremizzando, ma la realtà non è molto lontana dalle caricature tratteggiate).

La fase di definizione dei requisiti e delle competenze, per avere speranza di centrare i suoi obiettivi (comporre il team e definire in dettaglio i costi del progetto), dovrà iterare più volte sui seguenti passi:

  1. Discussione del tipo di sistema che si vuole ottenere, delle sue caratteristiche fondamentali, dei parametri dimensionali.

  2. Definizione dei requisiti funzionali dal punto di vista utente.

  3. Definizione dei requisiti affidabilistici.

  4. Definizione dei requisiti diagnostici.

  5. Definizione delle modalità di utilizzo del sistema.

  6. Analisi e definizione delle competenze necessarie.

  7. L'analisi dell’interazione umano-macchina.

  8. Le competenze affidabilistiche specifiche del processo da controllare.

  9. Le competenze affidabilistiche specifiche delle tecnologie utilizzate per il controllo.

La natura dei passi elencati è tale da richiedere la presenza dell'utente finale, secondo i dettami metodologici della concurrent engineering.

Il contratto (o l’ordine di fornitura), se si vuole che l’affidabilità e la sicurezza abbiano veramente l’importanza che loro compete, deve comprendere:

  1. Il dettaglio dei requisiti affidabilistici, di sicurezza e di diagnostica.

  2. Delle milestone di fatturazione condizionate a prove di accettazione affidabilistiche. Tali prove, come vedremo nella parte dedicata ai test di accettazione, devono comprendere la simulazione di un numero sufficiente di guasti ed inconvenienti.

  3. L’indicazione delle figure professionali incaricate di curare lo sviluppo dei requisiti affidabilistici.

3.2.1 Discussione del tipo di sistema

L’obiettivo di questo passo di analisi è quello di definire con sufficiente confidenza almeno le seguenti caratteristiche:

  1. Se si tratta di un sistema di ricerca o di un sistema di produzione.

  2. Se è prevista una forte componente impiantistica, con conseguente dislocazione di parte del sistema d’automazione vicino agli impianti controllati, oppure si tratta di un oggetto compatto e privo di collegamenti fisici esterni (es.: satellite, veicolo spaziale, veicolo in genere).

  3. Se è richiesta una forte personalizzazione utente ed apertura del sistema, al punto da sconsigliare l’uso di semilavorati e piattaforme hardware-software commerciali.

  4. Se e quanto impatteranno le fasi di installazione a campo, commissioning ed avviamento del sistema sull’economia generale del progetto.

  5. Se il sistema sarà utilizzato da molte persone, quali sono i profili professionali previsti, se il sistema sarà presidiato continuamente oppure no, da vicino oppure in telemetria.

  6. Se sono previsti dei bus di rete e con quali funzioni di massima (es.: scambio di dati e comandi real-time, configurazione e down-load, editing, disegno, post-elaborazione risultati, statistiche, ecc…).

  7. Se vi sono criticità importanti, tali da impattare sulla stessa architettura del sistema e sulla scelta di piattaforme hardware e software (ad esempio grandezze fisiche da campionare con frequenza elevata, particolari esigenze di archiviazione di ingenti quantità di dati rilevati dal processo, ecc…).

Non si stupiscano, i lettori, per l’apparente ovvietà di quanto qui elencato. Se si pensa soprattutto alle opzioni a) e b), ed alle possibili interazioni delle due, ci si rende conto che la scelta dei fornitori è sempre molto aperta, in ogni caso, e che le brutte sorprese sono sempre possibili, anche a lavoro molto inoltrato.

Può darsi che sia stato scelto un fornitore che ha esperienza di progetti di ricerca, poiché i committenti sono ricercatori e quindi vogliono un sistema aperto, e sono disposti a tollerare una minor compatibilità con gli standard commerciali. Può darsi che il fornitore scelto abbia esperienza di progetti di ricerca e poca o nulla esperienza di controllo di processo su impianti industriali o simili, e quindi sia poco consapevole del peso della fase di commissioning. Può darsi invece che il fornitore scelto possieda prodotti e semilavorati già collaudati e sicuramente rispondenti agli standard commerciali correnti, ma sia poco disponibile ad aprire e personalizzare più di tanto i propri prodotti, e quindi abbia in serbo notevoli e sgradite sorprese, se richiesto di personalizzare il sistema.

Se si è scelto di realizzare un sistema con caratteristiche di ricerca (elevata interrompibilità dei cicli, possibilità di cambiare parametri in corsa, elevata possibilità di rilevamento dei risultati di prova, libertà per il ricercatore di dare comandi in concorrenza con la procedura automatica, ecc…) ed il processo controllato coinvolge potenze fisiche notevoli, occorre essere coscienti del fatto che le problematiche affidabilistiche aumentano in modo notevole, quindi trascurare tali problematiche equivale a corteggiare spudoratamente l’entropia.

L’obiettivo di questo passo di analisi è quindi quello di capire bene fin dove arriva l’esperienza e la disponibilità del fornitore scelto e rimediare quindi (non avendo ancora fissato il budget si è ancora in tempo) ad eventuali carenze individuate. Potrebbe essere necessario, ad esempio:

  1. Reperire sul mercato competenze impiantistiche o sistemistiche particolari.

  2. Analizzare determinate categorie di piattaforme commerciali esistenti (ad es. sistemi SCADA, database relazionali per la costruzione del database di sistema, PLC, schede micro-processore, bus di campo) per verificare se i gradi di apertura, personalizzabilità ed interfacciabilità sono sufficienti oppure occorre realizzare piattaforme ad hoc.

  3. Reperire competenze tecnologiche inerenti il o i processi da controllare, per acquisire confidenza sulle funzioni e sulla complessità dei sistemi di controllo da realizzare.

  4. Valutare aspetti architetturali del sistema, il peso da dare alla gestione allarmi, alla diagnostica, alla sicurezza in generale.

  5. Valutare il peso da dare all’affidabilità ed alla disponibilità del sistema, come indirizzi generali, da utilizzare poi nella definizione dei requisiti di affidabilità e sicurezza, e nella conseguente scelta di soluzioni hardware e software.

  6. In base alla valutazione di cui sopra, reperire eventualmente competenze specialistiche in affidabilità e sicurezza dei sistemi.

3.2.2 Definizione dei requisiti funzionali dal punto di vista utente

Questo passo di analisi è trattato in modo approfondito nel Capitolo 3 (3.2 - Definizione dei requisiti). Aggiungiamo, qui, soltanto una raccomandazione. Non sempre il committente di un sistema di automazione possiede le competenze necessarie per definire autonomamente i requisiti utente del sistema. In questi casi è prassi comune che il fornitore collabori con l’utente nella definzione dei requisiti funzionali.

In molti casi però, da questa collaborazione, nascono strane specifiche ibride, in cui il punto di vista del softwarista è stato imposto all’utente più di quanto sarebbe utile ed opportuno. Il documento che risulta non è ancora un software requirements documents, ma non è neppure il modello funzionale del sistema che farebbe l’utente, astraendo completamente dalle decisioni di natura architetturale informatica che devono necessariamente venire dopo.

In caso di collaborazione del fornitore alla stesura dei requisiti funzionali, il fornitore dovrebbe quindi limitare il proprio apporto quasi agli aspetti di editing del documento:

  1. curare che il documento abbia una struttura logica ed una buona indicizzazione,

  2. verificare la completezza e l’equilibrio degli argomenti,

  3. richiedere maggiori spiegazioni ed approfondimenti dove necessario,

  4. far presenti eventuali contraddizioni e sollecitarne la soluzione.

Il documento deve contenere, in forma chiara, i requisiti utente, assolutamente liberi da condizionamenti del software che verrà.

La discussione sui requisiti utente deve comprendere, ovviamente, anche, le esigenze di natura affidabilistica e diagnostica. Sarà il fornitore ad introdurre questo argomento, nel caso il cliente non lo facesse: spesso il cliente tende a dare per scontate molte cose, salvo poi meravigliarsi quando si accorgerà che argomenti per lui tanto essenziali da ritenere superfluo persino parlarne non erano affatto considerati essenziali dal fornitore!

3.2.3 Definizione dei requisiti affidabilistici

Definito il grado di affidabilità – alto, medio, basso -- del sistema da progettare, si passa a definire in dettaglio i requisiti di affidabilità.

Avendo già definito nei precedenti capitoli gli accorgimenti tecnici e metodologici da utilizzare per realizzare un’applicazione affidabile, ci concentriamo qui sugli aspetti di valutazione e decisione, fornendo criteri per aiutare sia l’una che l’altra. Indichiamo inoltre su quali componenti del sistema intervenire, per determinare il grado di affidabilità scelto.

Un’applicazione a bassa affidabilità è tipicamente un’applicazione che può interrompersi ed abortire, persino richiedere lo spegnimento ed il re-boot della macchina, senza che ne vengano danni di sorta, oltre alla perdita di tempo dell’operatore. Su questo caso non ci dilunghiamo, ovviamente, essendo fuori dello scopo di questa trattazione.

Definiamo ad affidabilità media un’applicazione che sopporti un certo tasso di indeterminazione, un clock di macchina che non spacca il microsecondo, qualche ritardo di visualizzazione dei dati, qualche raro hang-up dell’interfaccia umano-macchina. Nessuna grandezza di processo richiede tempi di campionamento al di sotto dei secondi, l’eventuale crash di qualche sistema, ancorchè fastidioso, è comunque recuperabile senza gravi danni.

Definiamo ad alta affidabilità un’applicazione tendente al determinismo totale, i cui requisiti fondamentali riassumiamo di seguito:

  1. il clock di macchina deve essere preciso al microsecondo;

  2. non devono verificarsi arresti imprevisti o hang-up del sistema;

  3. le anomalie e le cause di allarme (sia del processo che del sistema di controllo) devono essere tutte gestite mediante opportune azioni automatiche o di richiesta intervento operatore;

  4. il refresh dell’interfaccia umano-macchina deve essere sicuro e privo di blocchi e congelamenti inattesi dei dati visualizzati;

  5. si tratta di un’applicazione dalla cui affidabilità dipendono vite umane o valori materiali ingenti.

Alcuni suggerimenti per la progettazione di sistemi a media ed alta affidabilità sono dati più avanti. Per una dettagliata espozione dei requisiti e dei criteri di progettazione affidabilistici si veda anche il capitolo 3 di quest’opera.

3.2.4 Definizione dei requisiti diagnostici

Come nel caso dei requisiti affidabilistici, saltare la definizione dei requisiti diagnostici può portare a spiacevoli sorprese in fase di accettazione del sistema. Essa ha l’obiettivo di definire:

  1. Quale livello di dettaglio diagnostico si richiede per l’impianto: singolo dispositivo elettromeccanico, singolo attuatore, singolo sensore, macchina, impianto, rilevamento dell’usura delle parti usurabili, altro.

  2. Quale livello di dettaglio diagnostico si richiede per il sistema di controllo: singolo dispositivo elettronico, schede di i/o, unità di controllo locali, nodi, reti e bus di comunicazione, WorkStation, periferiche, altro.

  3. La strategia diagnostica del sistema: diagnostica online, routine diagnostiche da eseguire periodicamente, aggiunta o meno di hardware dedicato alla diagnostica.

  4. La strategia diagnostica dell’impianto: diagnostica real-time integrata nelle sequenze di automazione, routine diagnostiche da eseguire periodicamente, aggiunta o meno di parti elettromeccaniche dedicate alla diagnostica.

  5. La strategia di gestione degli allarmi: classificazione in base alla gravità, soglie di allarme per le grandezze analogiche, azioni automatiche di emergenza, possibilità di abilitare/disabilitare allarmi o gruppi di allarmi.

  6. Su quali interfacce umano-macchina deve manifestarsi la diagnostica, con quali gradi di richiesta di attenzione in relazione alla gravità dei problemi rilevati.

  7. Quale dettaglio si richiede nel log degli allarmi: log su disco, tutte le transizioni o solo le segnalazioni di allarme, altro.

Sarà compito del sistemista operare in modo che le strategie impostate si traducano in standard progettuali, da applicare nella realizzazione del software di controllo.

Specialmente se vi sono molte parti d’impianto fornite da diversi fornitori, il compito del sistemista è particolarmente critico. Qualora l’integratore di sistema non abbia provveduto a richiedere ai processisti di seguire determinati standard nella stesura delle specifiche di controllo ed automazione, ogni processista seguirà il suo metodo: quelli più informati in materia di automazione potranno fornire le specifiche in forma di pseudo codice, altri in formato ladder diagram, altri ancora in formato tabellare o discorsivo. Qualche processista può spingersi fino ad indicare i controlli (strategia diagnostica real-time) da eseguire sul buon fine dei comandi, altri ritengono che questo sia responsabilità del sistemista di automazione. Sui compiti dell’integratore di sistema sia in fase di integrazione che in fase di richiesta delle specifiche ai vari fornitori torneremo comunque più in dettaglio.

Il sistemista dovrà curare che il disegno architetturale dei vari software di controllo ed automazione sia omogeneo con le strategie progettuali impostate, quali che siano i gradi di dettaglio delle specifiche date dai processisti.

3.2.5 Metodologie di disegno e di sviluppo

Si vedano i capitoli 2 e 3 di questa stessa opera, per una panoramica delle metodologie e della loro applicabilità. In questo capitolo, dedicato agli aspetti umani ed al modo di utilizzare le tecnologie e le metodologie, vogliamo focalizzare l’attenzione sulla necessità, prima di gettarsi a capofitto nella progettazione, di soffermarsi a ragionare su quanto segue:

  1. verificare l’effettiva applicabilità della metodologia scelta al caso specifico che stiamo affrontando;

  2. sfrondare la metodologia scelta da parti inutili nel caso specifico;

  3. aggiungere alla metodologia parti necessarie e mancanti nel caso specifico;

  4. se la metodologia risulta da un progetto precedente verificarne attentamente la riapplicabilità nel caso attuale;

  5. definire un metodo di progettazione sicuro ed efficiente, che garantisca lo sviluppo-aggiornamento della documentazione progettuale contestualmente allo sviluppo stesso.

L’adattamento e l’uso della metodologia dovrebbe conformarsi alle seguenti semplici regole:

  1. la metodologia deve essere d’aiuto ai progettisti, quindi deve essere la metodologia che serve i progettisti, e non viceversa;

  2. non in tutti i casi è conveniente utilizzare gli strumenti della metodologia; ad esempio nel caso delle metodologie Object Oriented l’importante è la filosofia della programmazione ad oggetti, non l’uso pedissequo dei case tool (per quanto i tool forniscano alcuni innegabili vantaggi);

  3. la tecnologia è in continua evoluzione, ed a volte le metodologie sono indietro; ad esempio l’uso eccessivo della carta (retaggio dell’era industriale) può appesantire il lavoro e causare crisi di rigetto della metodologia da parte dei progettisti; ad esempio l’uso dei database relazionali e dell’internet possono essere di grande aiuto, specialmente quando il gruppo di progetto non è localmente concentrato;

  4. una progettazione iniziata seguendo una metodologia e poi proseguita senza (le scadenze urgono e "non c’è tempo", "la documentazione si finirà in seguito") risulterà in molti casi peggiore che se non si fosse usata alcuna metodologia;

  5. il gruppo di progetto deve essere convinto che la procedura scelta ed opportunamente personalizzata è utile e funzionale all’economia del progetto;

  6. il gruppo di progetto deve essere impegnato ed incoraggiato positivamente ad apportare correzioni ed aggiunte alla metodologia durante il lavoro;

  7. anche quando si utilizzano massicciamente le metodologie di sviluppo il "signore" del progetto è comunque il progettista; metodologie, tecnologie, piattaforme hardware e software, sono strumenti per raggiungere l’obiettivo: lo sviluppo di un sistema affidabile e sicuro.

3.2.6 Affidabilità di utilizzo e criticità

Quello della definizione delle modalità di utilizzo del sistema e della conseguente individuazione delle criticità che ne derivano è un altro capitolo spesso disatteso, nella progettazione dei sistemi. Eppure, se condotta per tempo, nella fase di definizione dei requisiti del sistema, quest’analisi può evitare costose riprogettazioni in seguito. Identifichiamo, almeno, i seguenti passi di analisi:

  1. Analisi della natura e dei flussi del processo produttivo o di ricerca, e delle modalità di utilizzo del sistema.

  2. Analisi dell’interazione uomo-macchina, dei comportamenti e delle esigenze delle persone che utilizzeranno il sistema, dell’interazione del sistema con operatori ed utenti umani.

  3. Analisi dell'interazione umana in un ciclo critico o potenzialmente critico, ipo-attenzione ed iper-attenzione.

  4. Definizione del profilo professionale e del numero delle persone che utilizzeranno il sistema.

  5. Analisi della logistica d'impianto, della quantità ed ubicazione delle stazioni di lavoro, degli orari di presidio delle stazioni di lavoro.

3.2.6.1 Analisi della natura e dei flussi del processo produttivo, di esercizio o di ricerca e delle modalità di utilizzo del sistema

Questo passo di analisi deve accertare, sia pure con l’approssimazione inevitabile in fase di studio, almeno i seguenti elementi:

  1. Le quantità di materiali e/o risorse utilizzate da ogni ciclo produttivo.

  2. Le quantità prodotte (se si tratta di un processo produttivo) o di dati di esperimento prodotti (se si tratta di un impianto di ricerca) da ogni ciclo automatico.

  3. La quantità di cicli automatici prevista nell’unità di tempo considerata, a regime e durante la fase di avviamento del sistema.

  4. L’occorrenza o meno di cicli automatici in concorrenza.

  5. Le modalità di utilizzo del sistema da parte degli utenti: maggiore interattività umano-macchina (riscontrabile in situazioni di ricerca o in situazioni produttive dotate di un servizio ricerca e sviluppo) o maggiore autonomia del sistema (riscontrabile in macchine automatiche che operano in ambienti nocivi o inaccessibili agli umani o in situazioni produttive caratterizzate da impianti altamente automatizzati e poco presidiati).

  6. I risultati attesi dai futuri utenti del sistema.

  7. Eventuali abitudini e procedure consolidate con l’uso di sistemi precedenti, che gli utenti ritengono utili e non intendono abbandonare.

L’accertamento di quanto sopra, possibilmente condotto mediante accurate interviste con il personale tecnico futuro utente del sistema è di grande importanza, e puo’ costituire la differenza tra un sistema utilizzato al 100% ed uno a malapena tollerato. Non è superfluo ricordare che contano non solo gli aspetti tecnici, ma anche quelli umani: se coinvolti fin dall’inizio i futuri utenti sentiranno di aver dato un proprio contributo alla progettazione del sistema, e saranno poi entusiasti di iniziare ad utilizzarlo.

3.2.6.2 L'analisi dell’interazione uomo-macchina

Anche nel caso in cui il nostro sistema di automazione non sia connesso all’internet, quindi sia isolato localmente, occorre considerare che le modalità di utilizzo sono assai diverse, tra il livello dell’automazione di base (gestito mediante PLC o MicroProcessori) ed il livello di interfaccia umano-macchina del livello 3. Al livello dell’automazione di base e, più in generale, nell’area del real time deterministico, le modalità di lavoro sono le seguenti:

  1. le funzioni sono ripetitive, ben scandite da cicli di lavoro predefiniti;

  2. la quantità di dati scambiati in rete è più o meno costante;

  3. non vengono aggiunti nuovi nodi o sottratti nodi al sistema se non riaprendo il progetto;

  4. una volta avviato il ciclo in modalità automatica, si richiede l’intervento dell’operatore solo in caso di anomalie del processo.

Al contrario, al livello delle interfacce esterne del sistema, le modalità di lavoro sono le seguenti:

  1. le funzioni sono poco ripetitive, caratterizzate da occupazione episodica di certe WorkStation per la creazione di cicli, la valutazione ed elaborazione di risultati, la soluzione di problemi riscontrati;

  2. le quantità di dati scambiati in rete possono variare molto, a seconda delle attività in corso da parte degli operatori del sistema;

  3. possono essere aggiunti o sottratti nodi alla rete locale, secondo le esigenze degli utenti;

  4. una volta avviato il ciclo automatico sul sistema real time, l’interattività degli utenti può continuare sul livello 3, per condurre attività di gestione o programmazione in parallelo all’esecuzione del ciclo automatico.

Come si vede si tratta di due modi di lavorare completamente diversi, e suscettibili di disturbarsi a vicenda, se gestiti su un’unica rete o in modo confuso. È quindi sempre fortemente raccomandato, che si voglia o meno adottare una tradizionale divisione in livelli, dedicare almeno due bus di rete diversi, per i due ambienti principali di un sistema di automazione: un bus chiuso e totalmente deterministico (che definiamo Real Time Bus), per la parte real time; un bus aperto per la parte di interfaccia esterna off-line (che definiamo Management Bus). Vedere anche, per un esempio, la pagina A&S_Esempio_1.

Quanto detto vale come criterio generale di utilizzo di un sistema di automazione. L’analisi puntuale dovrà individuare, con sufficiente approssimazione, le modalità di interazione tra gli utenti umani ed il sistema.

Questa fase dovrà quindi individuare:

  1. Il flusso operativo di massima del sistema a regime:

  1. editing delle procedure automatizzate di produzione o di esperimento,

  2. setup del sistema,

  3. setup dell’impianto,

  4. esecuzione delle procedure automatizzate

  5. elaborazione/valutazione/archiviazione dei risultati della produzione o dell’esperimento,

  6. e tutte le operazioni di routine, connesse all’utilizzo del sistema.

  1. Le operazioni non routinarie, di manutenzione/amministrazione del sistema.

  2. Quali parametri di programmazione del sistema conviene raggruppare in file o tabelle.

  3. Il grado di facilità d’uso delle interfacce umano-macchina, in relazione alle figure professionali previste.

  4. L’opportunità di utilizzare database relazionali per custodire i valori di setup e di programmazione del sistema e generare file di interfaccia verso gli eseguibili del sistema.

  5. Eventuali criticità nell’utilizzo del sistema, ad esempio momenti in cui l’interattività umano-macchina debba essere particolarmente sincronizzata, a causa di peculiarità del processo.

  6. Particolarità di cui tenere conto nelle fasi di integrazione e test del sistema.

  7. Prima bozza del piano lavori delle fasi di integrazione, installazione e commissioning.

3.2.7 Analisi e definizione delle competenze necessarie

Abbiamo più volte accennato, anche in precedenti capitoli, alle competenze necessarie per sviluppare un progetto. Si tratta, secondo gli autori, dell’aspetto più importante e critico nella progettazione di sistemi real-time affidabilistici. Ed è anche, in molti casi, l’elemento più difficile da valutare: come abbiamo già accennato, spesso il committente non ha le conoscenze necessarie per giudicare, ed i fornitori sono bravissimi a millantare competenze che non hanno. Anche quando entrambe le parti sono in buona fede, è molto facile incorrere nella sottovalutazione di aspetti che, a tempo dovuto, richiederanno il loro prezzo in ore non previste e non messe a budget. L’analisi e la definzione delle competenze necessarie al progetto è quindi un processo assai critico, delicato, spesso non breve, e sempre in bilico tra il rischio di offendere la buona fede di chi si presenta con le proprie vere competenze ed il rischio di incorrere in spaventosi buchi di competenza, che si manifesteranno nelle fasi più critiche del progetto.

Con grande umiltà il fornitore deve acconsentire di buon grado, e con spirito scientifico, ad approfondire l’analisi delle competenze. Con spirito scientifico, cioè senza alcuna vergogna, poiché quel sapere universale che molti vantano è quanto di più impossibile ed antiscientifico, dal punto di vista culturale. Il cliente, dal canto suo, deve saper distinguere tra chi detiene onestamente alcune competenze (in genere derivanti dall’esperienza fatta) ed è in grado di individuare razionalmente quelle che gli mancano ed i tuttologi che si spacciano per esperti di qualsiasi cosa perché convinti di sapersi inventare qualsiasi competenza meglio degli esperti.

Quando si individuano competenze mancanti con il giusto spirito scientifico, comunque, i guai non sono finiti. Supponiamo che, individuata l’esigenza, il fornitore (integratore di sistema) abbia cercato un subfornitore: occorre ancora capire se l’integratore di sistema è in grado di (o se sta allocando sufficienti risorse per) gestire il subfornitore, cioè di dargli le informazioni necessarie per svolgere la sua parte di lavoro e poi di integrare effettivamente la parte, una volta sviluppata. In certi casi, quando la tematica da affrontare è molto complessa, l’integratore decide, invece di fare da passacarte, di mettere direttamente in contatto il subfornitore con il committente o con il processista fornitore della parte d’impianto interessata. A volte la delega è così spinta che l’integratore finisce per essere informato solo "per conoscenza" di quanto si sta sviluppando tra il proprio subfornitore ed il processista: vale a dire che una bella pila di fax si accumula sulla scrivania del capo-progetto, che questi leggerà quando avrà tempo, oppure li passa al sistemista che ha mille compiti più prioritari, visto che quel subfornitore sembra cavarsela da solo. Tutti sembrano contenti, ed anche il project manager sogghigna soddisfatto, perché vede svilupparsi quella parte del lavoro senza che molte costose ore del sistemista vengano a gravare sulla commessa. In realtà, che cosa sta succedendo? Qualcosa di molto pericoloso:

  1. L’integratore di sistemi non sta facendo il suo mestiere di supervisore del progetto (per il quale, comunque, è pagato).

  2. Il subfornitore mette insieme, con il processista, un software che forse funzionerà in modalità stand alone, ma sarà probabilmente molto difficile da integrare con il resto del sistema.

  3. L’applicazione degli standard metodologici di qualità, di affidabilità e di diagnostica non è verificata, e lasciata alla buona volontà del subfornitore (al quale si è "data tutta la documentazione di progetto", pensando con questo di aver fatto il proprio dovere).

La gestione di competenze esterne alla propria azienda, in un progetto complesso, è un’attività a sua volta complessa e critica. È sufficiente mancare nell’individuazione tempestiva di un problema o di un’esigenza (e qui entriamo nei compiti del capo-progetto e del project manager), e possono avere inizio storture metodologiche che andranno a ripercuotersi inevitabilmente sulle fasi di integrazione, commissioning, collaudo ed accettazione del sistema, prolungandone insopportabilmente i tempi, con grande disperazione di tutte le parti coinvolte.

Gli aspetti che occorre maggiormente curare, per quanto riguarda le competenze, sono i seguenti.

3.2.7.1 La presenza dell'utente finale

La presenza dell'utente finale è quasi sempre indispensabile sin dalle fasi inziali del progetto, secondo i dettami del concurrent engineering, metodologia anch'essa nata in casa DEC negli anni ruggenti dell'automazione. Anche quando l'utente finale sia del tutto digiuno di cultura informatica, è però l'unico che ha (o dovrebbe avere) idea di che cosa realmente si richiede al sistema che si sta progettando. Può sembrare assurdo, ma non è così infrequente che il gruppo di progetto parta a disegnare un sistema sulla base di qualche esempio o esperienza precedente, senza curarsi di discuterne a fondo i requisiti con l'utente finale. Le differenze tra il sistema progettato e quello che serve all'utente vengono a galla durante le prove di accettazione, e da lì inizia la progettazione vera, in condizioni, manco a dirlo, di emergenza e strozzatura di risorse. In tale contesto i primi a soccombere, posto che fossero mai nati, saranno i requisiti affidabilistici.

Se l'utente finale, come a volte succede, non ha competenze tecniche sufficienti per discutere i requisiti funzionali del sistema, è meglio saperlo all'inizio, quando ancora c'è tempo (e budget) per cercare le competenze mancanti.

3.2.7.2 Competenze affidabilistiche specialistiche

Le competenze affidabilistiche necessarie possono essere di due tipi:

  1. le competenze affidabilistiche specifiche delle tecnologie utilizzate per il controllo;

  2. le competenze affidabilistiche specifiche del processo da controllare.

Le competenze del tipo a) dovrebbero essere detenute dal fornitore che ha vinto la gara per il sistema di controllo ed automazione. Se si scopre che tale fornitore non le possiede, forse è il caso di riaprire la gara, o sicuramente almeno di affiancare a costui qualcuno che le possieda.

Le competenze del tipo b) a volte sono detenute dal fornitore del sistema di controllo ed automazione. Quando un sistemista ha alle spalle una lunga esperienza di sviluppo di sistemi di controllo di un processo tecnologico specifico, è inevitabile che abbia finito per assorbirne le problematiche essenziali. Tuttavia, potendo scegliere, la presenza del processista è sempre preferibile, anche quando il sistemista d'automazione ostenti una buona conoscenza della materia. Si tratta infatti sempre di una conoscenza da informatico, e non da tecnologo processista. Solo quest'ultimo sa davvero quando la pressione in un dato componente di questo impianto, diventa potenzialmente pericolosa. L'informatico può aver visto casi analoghi e sapere perfettamente come disegnare il controllo affidabile di tale componente, ma la sua responsabilità si ferma al sistema di controllo, ed è pericoloso chiedergli di estenderla al processo.

Per contro, il processista a volte ostenta una grande conoscenza dei sistemi di controllo del proprio impianto. Anche questo è inevitabile, ed è perfettamente plausibile, da parte di un processista con sufficiente esperienza alle spalle, visto che si fa automazione di processo computerizzata da più di vent'anni. E non scordiamo mai che tutti quanti smanettano poco o tanto con il PC di casa, e ritengono, a ragione o a torto, di saperne quanto gli altri. Tuttavia è meglio lasciare al sistemista di automazione la responsabilità di disegnare gli algoritmi affidabilistici e diagnostici.

Ora, se il sistema viene disegnato senza una discussione preventiva approfondita dei requisiti affidabilistici tra il processista ed il sistemista, è molto facile trovarsi, al momento dell'integrazione, con un sistema inaffidabile, e senza budget per riprogettarne l'affidabilità.

3.3 Progettazione

3.3.1 Performance ed affidabilità: scelte e convenienze

Un aspetto pressochè sconosciuto a chi non si sia mai occupato specificamente di applicazioni affidabilistiche è la forbice di scelta tra performance ed affidabilità.

Si può essere indotti a pensare che più un sistema (una macchina, un sistema operativo, o un software applicativo) è potente e performante più è affidabile. Siamo indotti a questo errore dalla nostra cultura industriale, se volete in particolare per quanto riguarda le automobili. Tuttavia, anche limitandoci alle auto, occorre notare quanto segue: è vero che un'auto potente è più affidabile di una piccola utilitaria, ma solo se la si usa al 60% della sua potenza. Se la spingiamo al massimo inevitabilmente scendiamo nella curva dell'affidabilità. Inoltre bisogna tenere presente il tipo di prestazioni che richiediamo ad una determinata vettura: se pretendiamo, ad esempio, di partecipare ad un rally in montagna con una Rolls Royce, andremo probabilmente incontro a brutte sorprese.

Ma il paragone più corretto sarebbe un altro. Pensiamo alla differenza tra un aereo da turismo ed un cacciabombardiere. Indiscutibile che il secondo sia enormemente più potente, ma siamo certi che sia più sicuro ed affidabile? In assoluto certamente sì ma l'affidabilità globale comprende le condizioni di utilizzo (ecco perché parliamo spesso dell'affidabilità di utilizzo di un sistema). Ora, un cacciabombardiere è una macchina a rischio totale. Pensateci bene: si tratta di una macchina disegnata per operare in teatri di guerra, dove la cosa più probabile è lasciarci le penne (o per il pilota o per i suoi bersagli). Sicuramente il progettista aveva in mente la potenza offensiva del mezzo, più che la sicurezza del pilota, già per definizione a rischio.

Con questo paragone siamo già più vicini alla macchina informatica, ma l'era elettronica presenta ancora altri aspetti, del tutto peculiari, rispetto a quanto eravamo abituati a vedere e giudicare nell'era industriale. Ad esempio, il fatto che non si vede proprio nulla. Del motore truccato su un'utilitaria si sentiva il ruggito appena acceso, mentre il chip a 800 Mhz montato in un vecchio case 286 non fa alcun rumore diverso. Inoltre, nell'evoluzione di prodotti informatici, alcuni fattori (prima poco influenti) hanno assunto importanza rilevante. Si pensi soltanto, ad esempio, alla progressiva soluzione dei problemi e bachi di una piattaforma che consegue al suo utilizzo, ed al conseguente feedback che viene dagli utenti.

Ecco che, per quanto riguarda i sistemi elettronici ed informatici, conviene avere ben chiara la differenza tra esigenze prestazionali ed affidabilistiche e, nel caso i requisiti del nostro progetto si sbilancino maggiormente verso le esigenze affidabilistiche, scegliere piattaforme conseguenti. I parametri da tener presente sono almeno i seguenti:

Parametro

Obiettivo performance

Obiettivo affidabilità

Età del prodotto (+ o - recente)

+

-

Potenza + o - vicina allo stato dell'arte

+

-

Tipo di processore + o - consolidato

-

+

Tipo di periferiche + o - consolidate

-

+

Diffusione + o - estesa sul mercato

-

+

Uso + o - spinto della grafica

+

-

Piattaforma + o - aperta

+

-

Dimensione di memoria ram + o - estesa

+

+

Dimensione di memoria di massa + o - estesa

+

+

Come si vede, solamente in due casi (dimensione della memoria ram e di massa) le esigenze affidabilistiche e prestazionali coincidono. Per tutti gli altri parametri sono invece contrastanti.

Si noti anche la contraddittorietà intrinseca di alcuni parametri, se presi in assoluto. Per quanto riguarda infatti la diffusione sul mercato, si devono paragonare piattaforme omogenee: non avrebbe infatti senso paragonare i numeri di una piattaforma consumer con quelli di una professional. (ovviamente, posto che esistano sul mercato vere piattaforme professional…).

3.3.2 Suggerimenti per il disegno di applicazioni ad affidabilità media

Nella maggior parte dei casi ad affidabilità media è sufficiente utilizzare le piattaforme commerciali più in voga, curando al massimo la pulizia architetturale del software e disegnando ad hoc accurate procedure di governo delle risorse del sistema. Non è infatti assolutamente vero che il software delle ultime generazioni sia in grado di badare a se stesso e di tenere in ordine la casa. I dischi e la memoria ram si riempiono via via di ciarpame inutile, e di dischi si frammentano finchè il sistema diventa inutilizzabile. Molta enfasi va posta, se si decide di utilizzare sistemi operativi non specificamente orientati al real time, sull’amministrazione del sistema.

La definizione dei requisiti di affidabilità di un sistema ad affidabilità media avrà quindi cura di specificare, tra l’altro:

  1. Le modalità di utilizzo del sistema operativo e delle piattaforme software in relazione ai carichi di lavoro.

  2. Le raccomandazioni per l’eliminazione dal sistema operativo di tutte le funzioni inutili, suscettibili di inutile appesantimento del sistema.

  3. La lista, chiusa, delle applicazioni da installare sulle workstation del sistema.

  4. I requisiti di eventuali procedure, anche automatiche, di pulizia e riassetto periodico del sistema.

Per realizzare alcune delle soluzioni indicate potrà essere necessario ricercare l’aiuto di sistemisti esperti nell’uso e nella customizzazione del sistema operativo e delle piattaforme utilizzate.

3.3.3 Suggerimenti per il disegno di applicazioni ad alta affidabilità

Per quanto riguarda le applicazioni ad alta affidabilità, è consigliabile intervenire con criteri precisi su tutti i livelli di scelta, anche modellando l’architettura del sistema separando nettamente i livelli a maggior esigenza deterministica da quelli che richiedono meno tale requisito.

Diversi criteri devono essere applicati in fase di definzione dei requisiti affidabilistici del sistema, per ottenere un sistema ad elevata affidabilità:

Il criterio filosofico consiste nel recuperare, anche se la potenza di calcolo e le capacità di memoria delle macchine dell’era internettiana suggeriscono di farne a meno, la cultura sistemistica dei progettisti di sistemi real time degli anni ’80, che erano costretti a:

  1. Far stare gli algoritmi in poco spazio di memoria.

  2. Rendere il codice il più possibile snello, per consentire alle applicazioni real-time di girare senza sforare il ciclo macchina.

  3. Limitare il più possibile le dimensioni dei file di log, in modo da non riempire velocemente i dischi del sistema.

  4. Calcolare accuratamente il flusso di informazioni in rete, in base alle capacità della rete locale, in modo da non avere troppi conflitti (con conseguente perdita di dati, e quindi di capacità di controllo del processo).

Quanto sopra è molto importante: non c’è sistema, per quanto potente, che prima o poi non vada in crash se gestito in maniera disordinata e noncurante.

Il sistema operativo deve essere scelto tra quelli che danno certezza, almeno, dei seguenti requisiti regressivi:

a) ambiente operativo chiuso: solo le applicazioni predefinite dal progettista possono essere installate ed eseguite;

b) blocco totale del download, dell’installazione e dell’esecuzione di qualsiasi applicazione non desiderata;

c) blocco totale della negoziazione di protocollo con applicazioni sconosciute;

d) mappatura di memoria delimitata: rilocazione dei programmi e delle aree dati consentita, ma entro limiti ben precisi, stabiliti dal progettista;

e) priorita' dei processi imponibile, eliminando completamente il boost automatico dell'OS, a livello di macchina, e non solo di applicazione;

f) schedulazione dei processi in esecuzione rigidamente controllabile;

g) definizione e controllo totale delle istanze di uno stesso processo, routine o thread in esecuzione;

h) determinazione e controllo totale dello swap su disco delle applicazioni;

i) determinazione e controllo completo dell'allocazione e del rilascio delle risorse (memoria ram e disco), in modo da avere la certezza del livello di 'pulizia' delle aree utilizzate;

j) controllo totale della frammentazione dei file su disco fisso: poter decidere se e quanta frammentazione dei file di disco tollerare, e poter mettere in moto funzioni capaci di ripristinare immediatamente dopo l'uso (se non durante) il livello di pulizia desiderato;

e) chiusura deterministica delle interfacce del sistema, a livello di progettazione;

f) blocco totale dell’apertura di interfacce non autorizzate durante l'utilizzo del sistema.

È interessante notare che, per realizzare la maggior parte dei requisiti elencati, si tratta di regredire a funzionalità ben note nei sistemi operativi dell’era pre-rete. I sistemi operativi e le piattaforme utilizzate per la rete sono di gran lunga più complessi del sistema operativo qui sopra abbozzato.

Avendo bene in testa gli obiettivi, ben delimitati, dell’affidabilità dei sistemi real time, si tratta quindi, in primo luogo, di un lavoro di pulizia, eliminando tutto ciò che ad un sistema real time non serve.

Qualora non si trovi un sistema operativo rispondente ai requisiti affidabilistici definiti, ed i compromessi possibili siano comunque distanti dagli obiettivi, occorre valutare la possibilità di costruirsi autonomamente uno schedulatore real time, magari utilizzando librerie di routine standard di basso livello, per la gestione delle periferiche, delle linee seriali, delle reti.

Le piattaforme software (SCADA, database, archiviazione, elaborazione dati) devono essere scelte con altrettanta cura, fra quelle che consentono la definizione di ruotine utente, e che permettono al progettista di definire in dettaglio i criteri di schedulazione dei vari task, le regole di allocazione e rilascio delle risorse, la strategia di occupazione della memoria ram e di archiviazione dei dati su disco.

La scelta delle piattaforme hardware deve essere condotta con mentalità aperta e scevra da pregiudizi. Tra coloro che si occupano di automazione di base, vi sono tradizionalmente due scuole distinte, che spesso convivono all’interno delle stesse aziende: la scuola dei PLC e la scuola dei MicroProcessori. Ambedue le scuole hanno parecchie buone ragioni per sostenere il proprio orentamento, negano le buone ragioni dell’altra scuola, e non si piegherebbero mai ad utilizzare la tecnologia dell’altra scuola, per un’applicazione ritenuta critica. In realtà, le due tecnologie si sovrappongono in moltissimi casi, benchè vi siano, agli estremi, convenienze nell’utilizzo dell’una o dell’altra. Ad esempio, in molti casi di embedded-software, vale a dire di software a bordo di veicoli, sia automatici che abitati, di spazio, di cielo, di terra o di mare, o a bordo di utensili, apparecchiature, di qualunque cosa non sia installata e fissa, è consigliabile l’uso di MicroProcessori, data anche la loro maggior versatilità di montaggio. Anche in quei casi che richiedono la progettazione di hardware ad hoc (ad esempio meccanismi di puntamento laser, la cui elettronica di controllo deve rispondere a requisiti di elevatissima velocità di reazione, dell’ordine dei microsecondi) è consigliabile l’uso di MicroProcessori. In tutti i casi, invece, di installazione fissa, che richiedano l’implementazione di loop di controllo e regolazione (PID), o movimento assi, o tracciamento di parti in movimento, se le frequenze del processo sono dell’ordine dei millisecondi, è certamente conveniente l’uso di un PLC. Dotati di sistemi operativi multitasking, di schede periferiche intelligenti specializzate per gli usi industriali più frequenti (PID, movimento assi, comunicazione in rete, ecc…), di librerie di blocchi software parametrici di calcolo, di costruzione robusta adatta all’uso in officina, queste macchine rappresentano certo la soluzione più economica ed affidabile, ed in genere rispondono sufficientemente ai requisiti deterministici, per quanto riguarda l’automazione di base. Ovviamente anche un buon MicroProcessore, su cui sia sviluppato il software ad hoc, necessario e sufficiente al suo compito, può rispondere altrettanto bene.

La maggior parte dei problemi, per l’affidabilità, non nasce del resto al livello dell’automazione di base, bensì ai livelli superiori, nelle aree dell’interfaccia umano-macchina, e dell’interfaccia con il mondo esterno e con la rete. È questa una fascia applicativa che viene in genere servita con piattaforme hardware di tipo Personal Computer, WorkStation, File Server. È questa l’area in cui è più facile (specie per chi non ha precedente esperienza, e si improvvisa progettista di sistemi real time) fare confusione. Ciò si deve anche alla sovrapposizione (di cui parlavamo in precedenti paragrafi), in questa fascia, di sistemi operativi e piattaforme applicative non orientate al real time, ma ad altri tipi di applicazioni (telecomunicazioni, entertainment, home, ecc…).

Ecco perché parliamo di criteri architetturali. Essi consistono nell’identificazione precisa di ciò che deve funzionare in real time: se, ad esempio, il loop di un algoritmo di controllo si chiude su una macchina al di sopra del livello 2, tutto il livello 2, il bus di comunicazione del livello 2 e la macchina di servizio su cui si chiude il loop dovranno essere comprese nell’area deterministica. Si veda anche il Capitolo 3 di quest’opera (3.3 – Disegno).

3.3.4 Evoluzione dell’elettronica e dell’informatica ed evoluzione della progettazione

3.3.4.1 L’uso dell’elettronica per la progettazione

Una cultura del real time affidabilistico in evoluzione dovrebbe essere in grado di non farsi dominare e sabotare dalla parallela evoluzione della cultura della comunicazione in rete ed, al contempo, di saperla utilizzare per i propri fini progettuali.

Vi sono, infatti, aspetti estremamente singolari e contraddittori nella pratica progettuale degli stessi artefici dell'era elettronica. Dimostrandosi del tutto conformi al noto detto popolare, secondo cui il calzolaio in genere va in giro con scarpe bucate e sgangherate, i progettisti di sistemi elettronico-informatici usano ben poco l'elettronica per la progettazione. Essi preferiscono ancora utilizzare metodologie e strumenti propri dell'era industriale, prima fra tutti le carta. In questo modo le metodologie di qualità finiscono col rappresentare un peso per il progettista, e quindi vengono disattese proprio nelle fasi più critiche (integrazione, test e commissioning).

Esperienze tanto avanzate quanto isolate hanno permesso di accertare la grande utilità di almeno due strumenti informatici, per il Project Management Affidabilistico: i database relazionali e l'internet.

Su piattaforme relazionali sono stati realizzati strumenti per:

  1. la gestione ed il tracciamento dei requisiti funzionali e software;

  2. la gestione ed il tracciamento dei test ai vari livelli di integrazione, ed il loro tracciamento rispetto ai requisiti;

  3. il tracciamento dei problemi scoperti durante l'esecuzione dei test, rispetto ai test ed ai requisiti violati, registrandoli direttamente in formato elettromnico durante l'esecuzione dei test;

  4. la documentazione, l'armonizzazione e la registrazione della storia dei segnali di i/o;

  5. la generazione di i/o table;

  6. l'identificazione automatica di discrepanze ed eccezioni tra liste diverse di segnali di i/o.

Si è verificato che quanto sopra permette, almeno, di:

  1. avere una gestione di qualità del progetto anche nelle fasi di integrazione di sistema e di commissioning;

  2. avere una metodologia di qualità che aiuta il progettista e ne semplifica il lavoro, anziché appesantirlo e complicarlo;

  3. migliorare enormemente l'efficienza delle riunioni di pianificazione / valutazione delle attività di test, infatti i problemi tecnici sono già scritti e selezionabili da database, viene così risparmiata tutta la riscrittura (precedentemente fatta a mano, sulla carta) degli aspetti tecnici;

  4. avere grande flessibilità e facile evolvibilità di strumenti di generazione di database e procedure di test.

La messa online, ovviamente sotto password, di tutta la documentazione di progetto ha sveltito enormemente tutta la procedura di distribuzione/commento/riedizione dei documenti progettuali.

3.3.4.2 Correggibilità degli errori e correzione effettiva

L’elettronica, ed ancor di più l’informatica, hanno portato i sistemi automatici ad un grado di flessibilità molto elevato, inimmaginabile nella precedente era della meccanica. Tale evoluzione ha determinato un’aumento vertiginoso dei gradi di libertà dei progettisti: poiché gli errori del progetto informatico sono molto più correggibili (rispetto ad esempio ad errori della progettazione meccanica), la mente del progettista è molto più libera di indirizzarsi agli aspetti concettuali, e ci si può permettere sempre di più il lusso di progettare il sistema in astratto, prescindendo dai tecnicismi e dai dettagli, che si confida possano essere poi risolti a livello procedurale, applicando sistematicamente le metodologie di progettazione affidabilistica e di qualità.

Davvero eccellente, in teoria, ma i risultati pratici non sempre danno ragione alla teoria. Come succede spesso a noi umani, la libertà ci ha forse un po’ dato alla testa, ed occorre rimediare.

In concreto, il fatto che, grazie alle tecnologie informatiche, gli errori siano divenuti correggibili, non significa che siano sempre e certamente corretti. Sta ancora a noi umani correggerli, prendendo in considerazione tutto ciò che nessuna intelligenza elettronica, per quanto evoluta, non è (e non sarà mai) in grado di considerare. Per quanto potente e veloce, la macchina esegue infatti nulla più (e qualche volta nulla meno) di quanto la nostra fantasia è stata capace di programmare in essa.

La ricerca degli errori di progettazione e di implementazione non si può considerare conclusa quando è terminata l'esecuzione di una procedura di test. È bensì un processo di reiterazione di prove, finchè l'umano (esperto) non ritiene di poter rischiare di cominciare ad usare il sistema.

3.3.4.3 L’uso critico delle metodologie

Sul piano metodologico, il fatto che esistano ormai procedure standard e check list per ogni fase progettuale, non significa che tali procedure siano complete e corrette, né che siano sempre e certamente applicate per intero.

Un tragico errore sta nel riporre eccessiva fiducia nella tecnologia e nelle procedure.

Occorre tener presente che qualsiasi procedura o metodologie, se ha funzionato in casi precedenti, non è detto che funzioni o sia sufficiente nel caso attuale.

Ogni metodologia e procedura va sempre considerata, in prima istanza, necessaria ma non sufficiente, per il progetto concreto che abbiamo per le mani, per le seguenti ragioni:

Anche in questo caso, come per la ricerca degli errori, il riesame di procedure e metodologie "collaudate" è compito preciso di umani esperti. Mai e poi mai si deve lasciare una persona priva di esperienza da sola a condurre una qualsiasi attività di riesame o di test.

Inoltre si deve sempre tener presente che, in materie in continua evoluzione come l'elettronica e l'informatica, possano esistere metodologie e procedure capaci di durare nei secoli. Se evolve la tecnologia, devono evolvere anche la metodologia, e l'evoluzione sia dell'una che dell'altra sono compito di umani esperti.

Ecco perché, più che di metodologie, preferiamo parlare di filosofia e cultura progettuale: retaggi umani, appunto.

3.3.4.4 Il riuso ponderato del software

Il sogno di qualsiasi imprenditore o manager del mondo informatico: avere un set di librerie software, il più possibile completo, una serie di semilavorati collaudati ed assemblabili, che permetta di diminuire il margine di rischio delle commesse, e di poter fare stime dei tempi d'implementazione finalmente realistiche.

Ma, per il software, ed ancora di più, vale il discorso già fatto per le metodologie. È possibile, certo, il riuso di parti software già collaudate, ma non ci si può esimere dal ripetere l'analisi per intero, allo scopo di verificarne attentamente l'applicabilità al nuovo caso concreto: se dobbiamo controllare una nuova versione di una macchina, più complessa e potente di quella precedente, sarà difficile che il software di controllo sviluppato per la versione precedente sia sufficiente.

Certo che si tratta di un software collaudato, funzionante ed accettato dal cliente, certo che la quality assurance ci era costata sangue e sudore, ma era sufficiente per il controllo di un'altra macchina.

Converrà considerare, in prima istanza, la nuova macchina completamente diversa da quella vecchia. Procedendo con l'analisi, si tratteranno come eccezioni i casi, ben analizzati e documentati, di possibile riutilizzo di parti software esistenti, e non il contrario.

Quanto sopra implica anche, per esempio, che il commerciale non deve dar per scontata la riutilizzabilità di software esistente, al momento di quotare lo sviluppo del progetto (si veda anche la trattazione della fase negoziale, in questo setsso capitolo): è preferibile avvertire il cliente che il prezzo stabilito è quello del caso peggiore, e che potrà diminuire se l'analisi dimostrerà la riutilizzabilità di software esistente.

Una possibile obiezione potrebbe allora essere la seguente: ma, allora, dove sta il vantaggio del riuso del sw? Non avevano allora ragione i softwaristi degli anni '980, che riprogettavano da capo ogni volta, portandosi dietro, da un progetto all'altro, tuttalpiù la filosofia ed il know-how personali?

Verrebbe da dar loro in parte ragione, effettivamente, ma solo in parte: è vero che devo rifare l'analisi, ed è anche vero che, se devo poterlo riusare, il sw deve essere molto modulare e ben documentato (quindi lo sviluppo mi sarà costato di più). È vero anche che le ore risparmiate non sono quelle del sistemista o dell'analista, ma quelle del programmatore (che costano meno). Ma il vantaggio esiste, ed è comunque ragguardevole: sicuramente le routine riutilizzate non presentano errori interni. Ovviamente non è affatto detto che non facciamo errori di utilizzo, di assemblaggio, o di altro genere, però un pezzo di codice che ha superato positivamente dei test di accettazione possiede un notevole valore aggiunto.

3.3.4.5 La qualità come parte integrata ed integrante del progetto

A quasi vent'anni dall'introduzione dei vari standard di qualità (Total Quality, ISO 9000, ESA PSS05, ecc…), sarebbe tempo di trarre un bilancio critico, un riesame, per usare un termine molto usato da tali metodologie. I rilievi critici si possono sostanzialmente riassumere come segue:

  1. tutti gli standard di qualità si basano pesantemente su modulistica cartacea, trascurando le possibilità offerte dall'elettronica e dall'informatica;

  2. le procedure di qualità appesantiscono e complicano il lavoro dei progettisti, anziché semplificare ed aiutare;

  3. i quality manager sono in genere figure burocratiche, che non vivono all'interno del progetto, ma si comportano come uno sportello, cui i progettisti devono portare i moduli di Non Conformità debitamente compilati;

  4. le raccomandazioni espresse da tali "gran sacerdoti" assomigliano spesso ai pronunciamenti di un oracolo, espressi in linguaggio qualitese, del tutto incomprensibile;

  5. tali raccomandazioni risultano il più delle volte impossibili da soddisfare senza mandare il progetto in spaventoso ritardo.

Poiché molto spesso accade che, quando si deve tentare di rispettare le milestone progettuali, le metodologie di qualità vengono semplicemente accantonate in attesa di "tempi migliori" (leggi "mai"), qualsiasi contributo metodologico che consenta di conservare una gestione di qualità anche nelle fasi di emergenza rappresenta un incalcolabile passo in avanti, rispetto alla realtà attuale.

Un primo passo, nella direzione di standard di qualità funzionali (e non più di ostacolo) alla progettazione, consiste semplicemente nel fare il contrario di quanto elencato più sopra. E quindi:

  1. usare il più possibile l'elettronica e dall'informatica nella gestione di tutte le attività significative di progetto, soprattutto la definizione di requisiti, procedure di test, integrazione ed accettazione (si veda "L’uso dell’elettronica per la progettazione", qualche paragrafo più sopra);

  2. studiare per ogni caso progettuale specifico l'applicazione delle metodologie capace di aiutare i progettisti e semplificarne il lavoro;

  3. portare il quality manager all'interno del progetto, oppure incaricare un progettista tecnico del compito di gestire la qualità;

  4. discutere le raccomandazioni della qualità, verificarne l'applicabilità al caso concreto e studiare il modo migliore di applicarle;

  5. studiare il modo per risparmiare tempo, gestendo il progetto con qualità (la chiave sta spesso nel trovare modi prendere velocemente note metodologicamente complete e ritrovare velocemente le annotazioni).

3.3.4.6 La cultura scientifica dell’affidabilità, ovvero l’insostituibilità dell’apporto umano

L'insieme dei fattori che abbiamo fin qui elencato (la resa della cultura real time all'informatica della rete, la deresponsabilizzazione rispetto alla gestione delle risorse hw, per non citarne che due) ha determinato un vero e proprio degrado culturale: un tremendo calo di attenzione attiva, da parte dei progettisti, nel controllare e ricontrollare scientificamente, vale a dire applicando al proprio agire progettuale i principi galileiani della sperimentazione scientifica, che non da’ mai nulla per scontato.

Formazione al metodo scientifico e formazione umanista (cioè capace di trasmettere l’immenso valore dell’essere umano), quindi: due categorie anche un po’ carenti nei nostri programmi scolastici.

Un'analisi spassionata e puntuale del problema, condotta secondo principi di mercato e di etica umanista, porterebbe ad identificare due distinte scuole informatiche, ambedue con pari dignità e diritto di cittadinanza.

L’indirizzo della generalizzazione planetaria della comunicazione non è infatti, in sé, sbagliato. Tale indirizzo diventa pericoloso se concepito come totalizzante, unico ed in alternativa ad altre opzioni essenziali. Non avendo in sé l’esigenza dell’affidabilità e della sicurezza dei sistemi, l’indirizzo comunicativo della tecnologia rischia di sopprimere la cultura dei sistemi deterministici, in particolare di controllo di processo in real time. Diamo di seguito alcuni requisiti, per la creazione delle due scuole menzionate:

1) La realtà naturale, ed anche di molte interazioni uomo-natura, è irrimediabilmente (e meravigliosamente) stocastica.
2) Per i propri obiettivi di comunicazione e collaborazione l’uomo ha l’esigenza di sviluppare sistemi il più possibile aperti. Tali sistemi risulteranno ad essere, per forza di cose, stocastici. In questo la rete tenderà ad assomigliare ad un sistema naturale, dotato di una propria evoluzione e differenziazione basato su crescita, differenziazione, mortalità, nuova differenziazione di nodi ed agglomerati al suo interno. (Si vedano anche i concetti di K.A.Ehricke, del "metabolismo dell’informazione")
3) Per i propri obiettivi di sopravvivenza e sviluppo l’uomo ha l’esigenza di costruire sistemi di interazione uomo-natura il più possibili affidabili e predittibili, vale a dire deterministici. Di tali sistemi deve essere possibile, in percentuale tendente al 100%, predire gli esiti ed il comportamento.
4) Per soddisfare ai requisiti dell’affidabilità e del determinismo, un sistema deve necessariamente essere un sistema chiuso, di cui siano rigidamente determinati i requisiti dal progettista, in primo luogo i requisiti di interfaccia con:

a) il processo controllato, che continua, poiché naturale o comunque aperto agli influssi della circostante natura, ad essere stocastico

b) e con l’operatore umano, anch’egli, per sua natura, stocastico.
5) Possiamo quindi affermare che il sistema deterministico, date le condizioni a) e b) del punto precedente, viene ad essere un agente di sicurezza che si interpone tra due sistemi stocastici (uomo e natura).
6) Requisiti di sicurezza possono essere definiti, in fase di progettazione, sia in favore dell’uomo che della stessa natura.
7) Rigidamente definite a livello progettuale dovranno essere, in un sistema deterministico, anche le interfacce in rete locale chiusa, verso eventuali sistemi cooperanti.
8) Sia i sistemi stocastici che quelli deterministici sono realizzabili unicamente per mezzo dell’elettronica e dell’informatica.
9) Ogni confusione di indirizzi, requisiti, obiettivi, tra le due progettazioni, può portare solo a risultati negativi, soprattutto nel campo dei sistemi deterministici.
10) Ne consegue che l’informatica dovrà contemplare due scuole ben separate, e due indirizzi ben delineati, in cui si coltivino con attenzione i diversi scopi e finalità per cui sono nate:
a) quello dell’apertura stocastica, per i sistemi di comunicazione,
b) quello della chiusura deterministica, per i sistemi affidabilistici.
11) Quanto sopra, per quanto riguarda l’informatica, che è la tecnologia dominante e fondamentale, nell’era del metabolismo dell’informazione.

3.4 Il Management

3.4.1 Gli stili di management e l’emergenza

Vi sono capi progetto che si occupano esclusivamente di tenere in ordine la documentazione di progetto (compito immane, va riconosciuto), e si ostinano ad usare la carta, lasciando il computer ai tecnici, come se fosse un disonore, per un capo progetto, utilizzare mezzi elettronici. Inutile dire che il progetto così non viene affatto governato né gestito. Le informazioni non vengono smistate, ma si lascia interamente ai sistemisti la responsabilità di cercarsi le informazioni, di rispondere alle domande interne ed esterne.

Sull’altro versante troviamo capi-progetto che non lasciano letteralmente respirare i loro sistemisti, avocano a sé qualsiasi decisione, non si fidano di nessuno e -- come se fossero in emergenza continua -- annullano la struttura del gruppo andando a reperire informazioni ed a dare disposizioni anche ai programmatori più giovani ed inesperti. Ovviamente questo tipo di capo progetto (come anche quello precedente) finisce col trovarsi molto presto in emergenza ed in drammatico ritardo sulle scadenze. È quando inizia ufficialmente la fase dell’emergenza (che continuerà fino alla fine del progetto), che questi capi progetto si sentono a loro agio: in emergenza tutto diventa possibile, i meeting di pianificazione diventano sessioni di analisi per capire che cosa è veramente essenziale, e quindi non si può rimandare a un mitico, quanto mai arrivabile, dopo.

In emergenza lo sforzo eccezionale diventa la norma. Si può chiedere al gruppo di progetto di lavorare più di dieci ore al giorno e durante i week-end, e si può circolare con quell’aria di "sono qui che sto facendo di tutto per salvare il progetto" che giustifica qualsiasi ritardo ed errore analitico precedente. Ovviamente, se la filosofia è quella di fare solo l’indispensabile, e poiché pochissimi considerano indispensabile l’affidabilità e la sicurezza: molto più importante dimostrare che il sistema funziona, in modo da passare le milestone contrattuali e poter fatturare! Di qui l’esigenza (vedi il paragrafo "Il contratto affidabile") di inserire esplicitamente nel contratto milestone legate alla prova dei requisiti affidabilistici.

Per tornare all’emergenza, non c’è dubbio che, se un progetto entra in emergenza cronica ed incurabile (periodi d’emergenza episodici sono pressochè inevitabili in un progetto complesso), ammesso che l’azienda fornitrice avesse le competenze sufficienti, è evidente che:

  1. Il capo progetto ha fallito, e non aveva sufficienti competenze, o esperienza, per svolgere il suo compito.

  2. Molto probabilmente nel gruppo di progetto manca qualche competenza essenziale, che il capo progetto non è stato in grado di identificare, né in fase di analisi né successivamente.

  3. Molto probabilmente non è stata svolta una parte importante del lavoro di progettazione, perché si è pensato che fosse compito di qualcun altro, ed il capo progetto non ha allocato risorse per controllare che venisse effettivamente svolto.

  4. Da parte del management dell’azienda fornitrice, lasciare che il progetto vada avanti in quelle condizioni significa, a parte i danni economici, procurarsi una referenza negativa sul mercato.

Alle situazioni di emergenza, invece, le aziende reagiscono in genere nei modi più scomposti ed inefficaci:

L’emergenza cronica non dovrebbe mai essere accettata come un male inevitabile, in nessun progetto, ed a maggior ragione nel caso in cui affidabilità e sicurezza abbiano un peso rilevante. Come abbiamo visto, infatti, affidabilità e sicurezza sono in genere i primi elementi giudicati "sacrificabili" sull’altare della pianificazione d’emergenza.

Appena ha il sentore di un’emergenza grave, che potrebbe cronicizzarsi, l’integratore di sistema serio ha il dovere di:

  1. interrompere il lavoro;

  2. identificare le cause della situazione (non necessariamente le colpe, che spesso risultano da concorsi di cause): se si tratta principalmente di problemi di gestione o di problemi tecnici;

  3. cercare, se necessario all’esterno, le competenze necessarie da integrare nel gruppo di progetto;

  4. ripianificare i lavori, razionalizzando il ritardo, in modo da assicurare il rientro dall’emergenza ed il proseguimento dei lavori in condizioni di non-emergenza.

3.4.2 La gestione del contratto

Per quanto un contratto possa essere dettagliato e stilato mediante un’analisi attenta, è molto difficile che arrivi a coprire, specie nel caso di progetti di ricerca, tutti gli aspetti che si rendono via via evidenti, specialmente quando si inizia ad utilizzare il sistema. Se è logico e comprensibile che clienti e fornitori cadessero come allocchi in queste trappole negli anni ‘980, durante il boom dell’automazione industriale, è molto meno logico (e quindi più sospetto) che continuino a caderci dopo tante esperienze già fatte. La soluzione sembra semplice: tutto quello che è scritto nel contratto è dovuto, tutto ciò che non è scritto, se richiesto dal cliente, comporta un costo aggiuntivo, da rinegoziare. Allora perché, specie nei progetti di grandi dimensioni e complessità, si litiga continuamente, e si rischia spesso di arricchire gli avvocati?

Succede quando una, o tutte e due le parti, cominciano a perdere la fiducia di riuscire a farsi capire dall’altra parte. Quando i problemi non risolti di comune accordo si accumulano, le emergenze diventano croniche, e le parti si sono stancate anche di logorarsi in riunioni inconcludenti e di scambiarsi fax velenosi ognuno si rinchiude in se stesso, intimamente convinto che l’altro è un incompetente se non peggio, e che non si può "cavar sangue da una rapa". Si viene quindi ad instaurare una sorta di divisione ideologica, tra chi prende le parti del cliente e chi prende le parti del fornitore: ogni affermazione di chiunque viene letta secondo le lenti ideologiche, e non vi è più modo di risolvere i problemi. Il progetto va avanti lo stesso, solo grazie alla testardaggine dei tecnici, ed a volte, se si ha fortuna, senza chiasso qualche tecnico si prende di fatto delle responsabilità per cui non è pagato né incaricato ed, in qualche modo, porta a termine il progetto, pensando ad una gloria ed a riconoscimenti che ovviamente non avrà (il progetto è ormai troppo screditato e circondato da un alone negativo).

La ricetta per non trovarsi nelle condizioni appena esposte non è ovviamente semplice, e non esiste un antidoto facile ed immediato, una sorta di pillola o vaccinazione contro l’ideologizzazione della gestione contrattuale.

Il contratto deve prevedere alcune attività fondamentali, che consentano di affrontare e risolvere i problemi, in estrema sintesi:

  1. Assicurare un luogo manageriale in cui i tecnici possano affrontare e risolvere i problemi al riparo dalle diatribe contrattuali

  2. Il metodo della collaborazione tra utenti e fornitori nelle fasi critiche

  3. Primo: risolvere i problemi. Secondo: discutere il costo e chi deve pagare

  4. Gestione affidabilistica dei subcontrattori e dei subfornitori

  5. Organizzazione di meeting tecnici e di integrazione

Su quanto qui introdotto torneremo più approfonditamente nella seconda parte di questo capitolo.

La seconda parte di questo capitolo coprirà, in linea di massima, le fasi di test, integrazione, commissioning ed accettazione del sistema.

4. Ringraziamenti

Gli autori ringraziano in particolare Aldo Turati (ASIC) che, con i suoi commenti, ha contribuito alla stesura del presente capitolo. 

AA, VDV - TDF 3/2000 - 15/10/2000