domenica 12 aprile 2015

La complessità dei sistemi informativi - parte 3

Delineare qualificare e quantificare il sistema e l’ambito.



Il primo passo per misurare la complessità è di definire e delineare il nodo; elemento di base della “rete di relazioni del sistema informativo” che dinamicamente nel tempo si genera, in modo stocastico, in concomitanza delle diverse situazioni in cui i singoli nodi sono attivati e si trovano  ad interagire con gli altri per erogare i servizi a essi richiesti.
Alcune considerazioni preliminare sono d’obbligo e in particolare riguardano in:
 
·       primo luogo, ai criteri con cui si desidera disaggregare e riaggregare il sistema informativo. Il livello di atomicità del nodo (di seguito chiamato Modulo) che può essere la singola transazione,  l’insieme di funzioni appartenenti a un data applicazione, un sistema applicativo, un pacchetto, l’intero sistema applicativo o una qualsiasi altra entità che abbia una propria consistenza e validità per misurarne la sua complessità. 
·       secondo luogo, il modulo, una volta definito, viene considerato alla stregua di un “black box” e si focalizzerà l’attenzione sui flussi di ingresso,  di uscita e sui risultati perseguiti che costituiranno le variabili caratteristiche del funzionamento dello stesso modulo. 
·       terzo luogo non è richiesta alcuna definizione di come il modulo si relazione con gli altri poiché i legami e le regole saranno automaticamente determinati dalla suite software di Ontonix.

Indipendentemente del livello di atomicità scelto, per determinare quali sono le variabili che caratterizzano il comportamento di un modulo non  si può prescindere nell’avere una visione d’insieme che tenga conto anche delle contrapposizione di interessi e di finalità: 
·       della domanda, ovvero misurare la complessità dalla prospettiva di chi utilizza il sistema informativo, per svolgere le proprie attività e per raggiungere gli obiettivi di business. Lo scopo, in questo caso, è di comprendere quanto la complessità sia un fattore abilitante, efficiente, e efficace,  dell’operatività di chi utilizza le funzionalità di un dato modulo oppure quanto sia un vincolo identificando le variabili che contribuiscono maggiormente al vincolo stesso; 
·       dell’offerta, ovvero misurare la complessità dalla prospettiva di chi è addetto alla predisposizione e messa in opera del sistema informativo, al suo funzionamento e alla sua gestione e governo. Lo scopo è, quindi, di comprendere quanto il modulo è robusto e stabile e quindi quanto la complessità sia un vincolo, o meno, nell’erogazione del servizio e nel mettere a disposizione le funzionalità, nei tempi nei costi e con qualità richieste di  chi utilizza il modulo;
·       dei contesti, ovvero dell’ecosistema, in cui il modulo interagisce, caratterizzato da risorse date e da una forte variabilità sulla disponibilità delle stesse determinata dai cambianti delle priorità e delle esigenze nonché dall’operatività. Lo scopo è, quindi, di comprendere i comportamenti del modulo negli ambienti operativi in cui lo stesso deve competere e contendersi risorse finite. Questo consentirebbe di misurare il livello di fragilità o di robustezza del modulo quando sta svolgendo il suo ruolo operativo così come  la sua facilità a recepire gli adeguamenti necessari  al fine di svolgere nuove funzionalità e/o di migliorare le sue prestazioni.
 
Tenendo presente i diversi punti di vista, le variabili che descrivono la complessità di un modulo possono essere raggruppate secondo il seguente schema in cui la componente:
 ·       Business raggruppa sia le variabili che hanno un impatto sulla produttività e l’efficienza dell’utilizzatore (n° di inconvenienti, tempo di utilizzo, tempo di inattività, tempo di indisponibilità, n° di operazioni eseguite, volumi business trattati, n° di call all’help desk, tempo speso nella risoluzione di un problema, …)  sia quelle che riguardano l’allineamento alle esigenze organizzative e di business (n° di problemi, n° di  problemi risolti, n° di problemi demandati, n° problemi aperti, n° nuove funzionalità, n° di miglioramenti, n° di adattamenti o correzioni delle funzionalità in essere, tempo di supporto …….).
 ·       Sicurezza riguarda le variabili che permettono di misurare i rischi operativi del modulo (n° di intrusioni interne ed esterne; tempo di recupero, n° di reclami, tempo di soluzione, …….).
 ·       Funzioni include tutte quelle variabili del modulo “as is” che descrivono quanto sono utilizzate le funzionalità del modulo (n° di transazioni eseguite, n° di servizi erogati ad altri moduli, n° di servizi richiesti ad altri moduli) e la stabilità dello stesso modulo (n° di cambiamenti, n° di abend  per transazione, tempo di risoluzione, n° di abend aperti, n° di abend risolti ….).
 ·       Infrastruttura riguarda le variabili che descrivo l’ecosistema tecnologico le cui singole componenti sono necessarie per rendere fruibile il modulo stesso all’utilizzatore finale (disponibilità, indisponibilità, n° inconvenienti, n° di cambiamenti, tempo di ripristino, …..).
 ·       Run time include le variabili che descrivo il modulo quando lo stesso opera nell’ambiente fisico in cui deve contendere e contendere le risorse a disposizione. Esse riguardano l’utilizzo delle diverse risorse tecnologhe (Unità di servizio utilizzate, disponibilità, tempo di indisponibilità, n° di accessi, n° di querry, ….) e le prestazioni del modulo (tempo di risposta per transazione, n° di inconvenienti, durata degli inconvenienti …….).
 ·       AD&M riguarda le variabili che descrivo il processo di adeguamento funzionale in cui il modulo deve contendersi le risorse disponibili (function points o linee di codice introdotte o rimosse, risorse impiegate, elapsed time ………) sia per rispondere a esigenze organizzative e di business che tecnologiche di scalabilità e prestazionali. 
Una volta che è stato definito, qualificato il modello occorre passare alla fase successiva di  rilevazione e  raccolta delle osservazioni le quali, oggettivamente e temporalmente, quantificano le variabili che descrivono il modulo  oggetto di analisi (stati vettori).  Le osservazioni delle variabili potrebbero avere una base temporale diversa tra di esse così come in alcuni momenti l’osservazione potrebbe essere non disponibile. Entrambe le situazioni sono propriamente gestiste dalla soluzione Ontonix. In oltre tanto più alto è il numero di osservazioni e più consistente è il risultato conseguito.
 

Nessun commento: