Raccogliendo l’invito di Lucio, vorrei valutare l’interesse dei soci a costituire un gruppo di lavoro sulle fasi Operations e Maintenance, ritenendo personalmente che meritino una trattazione piu’ approfondita nel SE Handbook.

Perche’

Il SE Handbook
descrive in modo sommario le fasi di Operations e Maintenance; sarebbe utile
aggiungere una serie di principi generali, descrivere le problematiche piu’
frequenti e fornire delle best practices da adottare nelle fasi iniziali del
ciclo di vita di un sistema, per prevenire l’insorgere di tali problematiche
quando e’ ormai tardi per porvi rimedio in modo efficace.

Obiettivo

Obiettivo del WG
e’ quello di raccogliere esperienze, da vari domini, sulle principali
problematiche a cui si fa fronte quando si deve gestire la fase di Operations e
Maintenance e identificare una serie di best practices da sottoporre ad INCOSE
per arricchire le sezioni dell’Handbook dedicate alle fasi di Operations e
Maintenance.

Temi da sviluppare

Per iniziare, vengono proposti alcuni temi da approfondire, utilizzando le esperienze dei partecipanti al gruppo allo scopo di stilare una lista delle principali problematiche e proporre delle corrispondenti best practices per affrontare tali problematiche con successo.

Ad ogni tema e’ stata associata una “catch-phrase”.

I partecipanti sono invitati a sottoporre altri temi, oltre che a sviluppare quelli elencati qui di seguito.

1 – Communication Breakdown

Spesso nei grandi programmi che si occupano di sistemi complessi, c’e’ una rigida divisione verticale (silos) tra l’entita’ che ha la responsabilita’ delle fasi di design e development e l’entita’ che ha la responsabilita’ delle fasi di operations e maintenance. Le entita’ in questione possono essere dipartimenti diversi all’interno della stessa organizzazione o organizzazioni diverse.

Spesso la mancanza di comunicazione si traduce in mancanza di cooperazione e questo rappresenta un serio ostacolo allo sviluppo di un “successful system”, come recita la definizione INCOSE del Systems Engineering.

Il motivo e’ facile da intuire: la mancanza di comunicazione e cooperazione porta a due diverse interpretazioni di cosa significhi “successful system”: quella del team di design and Development (D&D) e quella del team di Operations and Maintenance (O&M).

Alla radice di questa mancanza di comunicazione e cooperazione c’e’ la mancanza di visione di sistema: l’obiettivo finale di entrambi i gruppi dovrebbe essere quello di realizzare un “successful system”, mentre troppo spesso l’obiettivo (piu’ o meno esplicitamente dichiarato) del team di D&D e’ dimostrare di aver completato il progetto di sviluppo rispettando i vincoli di schedule e budget imposti dal management. In quest’ottica ristretta, coinvolgere il team di O&M nella definizione di requisiti e’ percepita come una perdita di tempo/soldi, cioe’ un fattore che genera un allungamento dei tempi e/o aumento dei costi (vedi punto 3 di seguito). Dal punto di vista del Project Manager, questo viene definito come rischio esterno, cioe’ un rischio di cui deve farsi carico qualcun’altro (tipicamente il Program Manager). Il terrore del Project Manager e’ quello che a fronte di una richiesta di requisiti da parte del team di D&D, il team di O&M risponda cercando di imporre un design.

Nei casi in cui il team di D&D decide di coinvolgere il team di O&M fin dalla fase di definizione dei requisiti, si puo’ incorrere in altri ostacoli, per esempio:

• Il team di O&M semplicemente non e’ stato ancora messo assieme: la fase di O&M iniziera’ tra diversi anni e il management ritiene una perdita’ di tempo/soldi identificare dei rappresentanti che partecipino da subito alle fasi di D&D
• Il team di O&M non ha ancora le idee chiare su come condurra’ le operazioni e la manutenzione, quindi preferisce non impegnarsi con precisi requisiti scritti, o fornisce requisiti formulati in termini qualitativi e generici (“user-friendly”, “high-availability”, “at least 6 months of data”, etc..) che non permettono di fare scelte di design oculate
• All’altro estremo dello spettro, ci possono essere situazioni in cui il team di O&M e’ fin troppo partecipe, cioe’ insiste nel voler specificare non i requisiti, ma il design, introducendo rumore nel processo di D&D, senza poi prendersi la responsabilita’ di eventuali effetti collaterali introdotti da scelte di design non ponderate

2 – The Validation War

Il SE Handbook consiglia di eseguire la validazione del sistema nell’ambiente operativo. Questo richiede una cooperazione tra il team di O&M e il team di D&D. In assenza di tale cooperazione, il team di D&D dovra’ mettere in piedi un ambiente di validazione che in teoria dev’essere quanto poi’ possibile rappresentativo dell’ambiente operativo. In practica, in assenza di input da parte del team di O&M, il team di D&D fara’ il minimo necessario per portare a termine il progetto di sviluppo, con il rischio che importanti anomalie del sistema non vengano scoperte durante la validazione.

Se il team di O&M non e’ coinvolto nella validazione (per volonta’ propria o del team di D&D), c’e’ il rischio concreto che si scoprano importanti anomalie del sistema solo dopo la fase di Transition, con il rischio che il team di O&M non possa rispettare i suoi impegni nel tempo previsto (p. es. quando e’ stata annunciata agli utenti finali la data di roll-out di un nuovo servizio, e si e’ costretti a dichiarare un ritardo).

All’altro estremo, se un team di O&M e’ troppo coinvolto, puo’ generare due tipi di problemi:

• vuole definire anche le attivita’ di Verifica, oltre a quelle di Validazione, creando rumore
• A valle della validazione, identifica lacune del sistema (“non fa x,y e z, che invece a me servono”) senza aver mai formulato dei requisiti a riguardo

Nei casi in cui il team di O&M e’ il cliente e il team di D&D e’ il fornitore, spesso la validazione e’l’ultimo scoglio da superare prima del processo formale di accettazione (in cui la proprieta’ del sistema passa dal fornitore al cliente). Per questo motivo, si possono generare delle vere a proprie guerre di posizione, con evidenti impatti sui tempi e costi di messa in operazione del sistema.

3 – Maintain This

Un sistema sviluppato per soddisfare solamente dei requisiti funzionali, raramente soddisfera’ delle performance arbitrarie specificate dal team di O&M solo al momento della Transition. L’introduzione tardiva di requisiti di performance nel design di un sistema generera’ a valle dei problemi di maintainability, obbligando ad aumentare il numero di risorse umane necessarie a raggiungere “manualmente” i livelli di performance richiesta.

I requisiti di performance possono avere una profonda influenza sull’architettura di un sistema, e non e’ quasi mai possibile “aggiungere” dei requisiti di performance in modo indolore dopo che il sistema e’ stato progettato e realizzato.

Una delle conseguenze della mancanza di comunicazione e cooperazione tra il team di D&D e il team di O&M e’ la possibilita’ che i requisiti di performance non vengano specificati in tempo per essere utilizzati come input del processo di architectural design, con il risultato che il team di D&D faccia delle assunzioni “al ribasso” o, nella peggiore delle ipotesi, ignori completamente ogni aspetto di performance, semplicemente perche’ non c’e’ nessun requisito specifico da soddisfare.

All’estremo opposto, ci possono essere situazioni in cui il team di O&M e’ “troppo partecipe” e vuole specificare delle caratteristiche dell’architettura (p. es. creazione di istanze “prime” e “backup” per ogni sottosistema), con l’illusione di aver risolto il problema dell’affidabilita’, ma senza aver specificato dei requisiti di Availability, o senza aver tenuto conto degli aspetti di Maintainability.

Per restare in tema con l’esempio di una richiesta di duplicare un sottosistema per aumentare l’affidabilita’, se la seconda istanza e’ in “cold backup”, la duplicazione di per se non garantisce un’aumento dell’affidabilita’, se non si provvede ad assicurare che il team di Maintenance sia disponisible 24/07 per intervenire in caso di failure dell’istanza prime e attivazione dell’istanza di backup. Alternativamente (ma va specificato fin da subito), il backup dev’essere “hot backup”, e questo vuol dire che il SW va progettato per gestire due istanze in parallelo.