« Torna agli articoli

Operations e Maintenance: proposta per un gruppo di lavoro

11 Maggio 2016 | Vittorio Torroni

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.

  1. Maggio 18, 2016 alle 3:47 pm - Lucio Tirone.

    Caro Vittorio, il tuo “abstract” mi sembra molto valido e pertinente, ti auguro di riuscire a dare il via a questo Gruppo di Lavoro. Attendiamo la bozza di Charter, che potremo condividere con gli altri Soci e diffondere sia sul Sito che nei prossimi Chapter Meeting.

Privacy

Valida dal: 02 Agosto 2018

La presente Dichiarazione di tutela della privacy entra in vigore da Agosto 2018.

 

AISE (Associazione Italiana Systems Engineering) riconosce l'importanza della protezione delle informazioni personali e si impegna ad elaborarle in modo responsabile e in conformità con le normative applicabili per la tutela dei dati personali.

La presente Dichiarazione di tutela della privacy descrive le pratiche generali adottate da AISE in materia di privacy che si applicano alle informazioni personali che raccogliamo, utilizziamo e condividiamo relativamente ai soci sia individuali che “Corporate”, ed altre organizzazioni con cui AISE ha o prevede di avere una relazione.

 

Perché e in che modo raccogliamo e utilizziamo le informazioni personali

AISE raccoglie le informazioni personali di un associato per diverse finalità, tra cui: 

 

 

 

 

 

Sarà sempre possibile decidere di non ricevere più le comunicazioni personalizzate inviando un'email all'indirizzo info@aise-incose-italia.it

Laddove affermiamo di utilizzare le informazioni personali nell'ambito di una richiesta, o per fornire i servizi richiesti, lo facciamo perché è necessario in relazione alle prestazioni dell'accordo esistente tra AISE e gli utenti soci.

Laddove affermiamo di utilizzare le informazioni personali per finalità di marketing, per il miglioramento o lo sviluppo dei nostri servizi, per motivi di sicurezza e salvaguardia o per requisiti normativi fuori dall'ambito dell'accordo o della richiesta, lo facciamo sulla base dei nostri interessi legittimi con il consenso dell'utente. 

 

La condivisione delle informazioni personali

In alcuni casi, le informazioni personali possono essere divulgate ad agenzie governative, in conformità a procedure giudiziali, ordinanze del tribunale o procedimenti legali. 

Inoltre le informazioni personali potranno essere condivise con INCOSE ai fini esclusivi della gestione dello stato di iscrizione del socio alle due associazioni. Le relazioni tra AISE ed INCOSE sono definite nel Memorandum of Agreement stipulato congiuntamente dalle due associazioni, e scaricabile dalla sezione Download del sito AISE.

 

Precisione e sicurezza delle informazioni

AISE intende proteggere le informazioni personali e mantenere l'esattezza. AISE implementa misure di sicurezza tecniche, amministrative e fisiche per proteggere le informazioni personali da accessi, utilizzi e divulgazioni non autorizzati. 

 

Periodo di conservazione

AISE non tratterrà le informazioni personali più di quanto non sia necessario per adempiere alle finalità per cui tali informazioni sono state elaborate, inclusa la sicurezza della nostra procedura di elaborazione in conformità con gli obblighi normativi e legali (ad es. controllo, contabilità e termini di conservazione legale), la gestione delle controversie e per la determinazione, pratica o difesa di diritti legali.

 

Come contattarci

Per eventuali domande riguardo alla Dichiarazione di tutela della privacy, contattare AISE all’indirizzo info@aise-incose-italia.it. Il messaggio verrà inoltrato al membro appropriato del Data Privacy Team di AISE, come il Data Protection Officer o membri del relativo team. 

Per le finalità del GDPR (Regolamento generale sulla protezione dei dati) dell'UE, il titolare del trattamento delle informazioni personali è A.I.S.E. Associazione Italiana di Systems Engineering, Via Cechov, 69 Roma Italy. 

 

 

I Diritti dell'Utente

 

È possibile richiedere l'accesso, l'aggiornamento o la correzione delle informazioni personali. Inoltre, l'utente ha il diritto di opporsi alle operazioni di marketing diretto. È possibile inviare apposita richiesta a info@aise-incose-italia.it.

È possibile che l'utente goda di diritti aggiuntivi derivanti dalle normative locali applicabili all'elaborazione. L'elaborazione delle informazioni personali è soggetta al Regolamento generale sulla protezione dei dati dell'UE ("GDPR"). In accordo al GDPR, l'utente può avere il diritto di richiedere l'eliminazione o la limitazione al trattamento e chiederne la portabilità.

 

Il diritto di sporgere reclamo

Nel caso in cui l'utente considerasse l'elaborazione delle proprie informazioni personali non conforme alle normative vigenti in materia di protezione dei dati, l'utente può sporgere un reclamo:

 

Modifiche alla nostra Dichiarazione di tutela della privacy

Occasionalmente, AISE può aggiornare la presente Dichiarazione di tutela della privacy, nonché altre dichiarazioni specifiche riguardanti la privacy. Quando ciò avviene, AISE aggiunge una nuova data in cima alla presente Dichiarazione di tutela della privacy.