QUALITÀ E TIME TO MARKET NEI PROCESSI DI SVILUPPO

Transcript

1 92 QUALITÀ E TIME TO MARKET NEI PROCESSI DI SVILUPPO Marco Daccò, Marco Iacomussi, Gaetano Rossi

2 93 La realizzazione del software è un attività complessa articolata in più fasi, in cui fin dagli albori dell informatica, si è cercato di definire appropriati modelli di sviluppo per ingegnerizzarne la produzione. Tuttavia l Ingegneria del software si differenzia perché il software è un prodotto molto malleabile ed anche human intensive, cioè che richiede un considerevole impiego di risorse umane e una forte interdipendenza e sincronismo nelle loro attività, giacché la sua produzione implica soprattutto attività di progettazione e di implementazione sull intero perimetro delle procedure informatiche di una azienda. La procedura informatica cattura e modella un processo aziendale e l insieme di queste procedure rappresenta a pieno titolo l anima digitale dell azienda stessa. In questo articolo si propongono interventi migliorativi nelle aree IT provando a coniugare al meglio due aspetti molto spesso antitetici: tempo di produzione e qualità del prodotto. NETWORK SERVIZI La Piattaforma Informatica di 1Telecom Italia L insieme degli applicativi software e delle risorse hardware utilizzati in Telecom Italia per il supporto ai processi di business ed alle operations (nel seguito Piattaforma IT) è imponente: oltre 800 sistemi software, CPU, Terabyte di storage e Terabyte di backup, un centinaio di firewall. Questi numeri fanno dell IT di Telecom Italia la più grande realtà informatica italiana. Una piattaforma IT di tali dimensioni, se da un lato garantisce di poter rispondere alle richieste di mercato sia dal punto di vista commerciale sia tecnico, d altra parte è caratterizzata da momenti d inerzia, che sono sconosciuti agli operatori green field, i quali possono contare sulla agilità processiva tipica dei newcomers. Inoltre gli impatti della manutenzione evolutiva sono minori per un operatore green field e le difficoltà di introduzione di un nuovo sistema sono confrontabili per un green field alle problematiche incontrate da un incumbent per una più semplice manutenzione evolutiva. Si osservi che le variabili legate all inserimento di nuove funzionalità IT si traducono essenzialmente in due elementi misurabili: tempi e costi di implementazione. L incumbent, rispetto all operatore green field, si trova stretto nella tagliola dei tempi e dei costi, perché da un lato deve essere pronto negli stessi tempi del green field e d altra parte la complessità della sua Piattaforma si traduce in maggiori costi di implementazione. In questa sede affronteremo le insidie del continuo ridursi del tempo disponibile per lo sviluppo del software e ci interesseremo degli impatti di tale fenomeno sulla qualità del software. La Piattaforma IT riceve sollecitazioni evolutive da differenti input: miglioramento dei processi esistenti, introduzione di nuove offerte, richieste del presidio regolatorio, correzioni di anomalie, upgrade tecnologici. Chiamiamo Prodotto Software l oggetto che l IT deve realizzare per rispondere alla richiesta evolutiva. Il fattore tempo è determinante per la qualità del Prodotto, ma tipicamente i contenuti che si chiedono al Prodotto sono esuberanti rispetto ai tempi concessi alle singole fasi del ciclo di sviluppo: perché si vuole anticipare l uscita di un prodotto o perché si deve rispettare una scadenza regolatoria oppure si pongono stringenti obiettivi di produttività. 1.1 Il technical debt La strada tipicamente seguita per produrre in tempi rapidi è quella che va verso la rischiosa riduzione della qualità del prodotto. Dare poca importanza alla qualità del prodotto, preferendo ve-

3 94 NETWORK SERVIZI locizzare lo sviluppo (quick and dirty), equivale - secondo Ward Cunningham (cfr. 1) - ad accumulare un debito tecnico. Un piccolo debito può accelerare lo sviluppo per periodi non troppo lunghi, ma deve essere saldato con una riscrittura o con il re factoring del codice. Compresa la stretta relazione tra la qualità dei prodotti sviluppati e il tempo speso per la produzione, la sfida che ci vedrà impegnati nel prossimo futuro consisterà nel coniugare la qualità desiderata ad un time to market sempre più stringente. Le direzioni lungo le quali muoversi sono sostanzialmente due: interventi strutturali sulle architetture IT: ad esempio, evoluzione della Piattaforma in ottica SOA, centralizzazione in strumenti di BPM della logica applicativa per aumentare la configurabilità, evoluzione delle integrazioni via middleware ; interventi sulle fasi di sviluppo del software. 2La produzione del software Le fasi principali nella produzione di un applicazione informatica possono essere a grandi linee rappresentate da: analisi dei requisiti e definizione delle specifiche tecnico/funzionali; disegno tecnico e sviluppo del software; collaudo; esercizio. E importante considerare che, una volta in esercizio, il software è soggetto alle evoluzioni dettate dalle nuove esigenze del cliente, ma anche alle correzioni che si rendono necessarie a fronte di anomalie di funzionamento. 2.1 Il contesto Telecom Italia Contestualizzando la teoria nella prassi dell IT di Telecom Italia, è innanzi- tutto importante osservare che esistono due tipologie di progetti software: progetti di medio-lungo periodo, che supportano le evoluzioni di tipo «infrastrutturale» (modello Project Based ); progetti di breve periodo, che garantiscono una risposta rapida alle mosse dei concorrenti (modello Service Creation ). La gestione del modello Project Based è assimilabile ad un cantiere industriale: noto ciò che si vuole produrre (i requisiti), si definiscono le risorse necessarie e infine si formalizza il piano di realizzazione (i rilasci). E un modello che tipicamente si applica alla realizzazione di un nuovo applicativo software o all evoluzione tecnologica e/o architetturale di un sistema esistente. Viceversa, nel modello Service Creation sono predefiniti i tempi di produzione (quando rilasciare) e le risorse disponibili (capacità produttiva allocata per i rilasci calendarizzati), la variabile è cosa produrre (nel tempo predefinito e con le risorse preassegnate). E il modello che tipicamente si adotta per far evolvere l intera Piattaforma IT (non un solo sistema) in ragione di una particolare esigenza che spesso non si chiude su un solo sistema software. Il processo basato sul modello Service Creation è sicuramente più critico di quello Project Based; qualche dato numerico può fornire l ordine di grandezza della complessità: in un anno si prendono in considerazione più di 9000 requisiti utente, di cui poco più della metà vengono mandati in produzione; un singolo requisito coinvolge mediamente dai 5 ai 40 sistemi software a seconda della sua complessità. Si pensi alle conseguenze che possono esserci in un piano che deve necessariamente coordinare sviluppi su moltissimi sistemi per garantire l erogazione di un servizio definito, in conseguenza del ritardo di consegna anche solo di un singolo sistema! Oppure si considerino gli impatti di richieste concorrenti su un solo sistema. Si può affermare che il modello Service Creation è caratterizzato da un forte accoppiamento (coupling), perché nella Piattaforma IT esistono sistemi centro stella interessati contemporaneamente da più richieste di servizio e perché tipicamente ciascuna esigenza può essere riscontrata solo con sviluppi su un numero elevato di differenti sistemi. Alla luce di quanto detto, è facile comprendere che i concetti di debito tecnico e le difficoltà di conciliare qualità e time to market sono, nel caso della Service Creation, di gran lunga più significativi che nel modello Project Based. Pertanto nel seguito ci si riferirà essenzialmente al modello Service Creation. I rilasci del software, a qualsiasi sistema siano riferiti, sono raggruppati in KIT che seguono una ben definita timeline: a titolo di esempio, sono previsti 6 rilasci all anno per kit major release, nell area dei sistemi di supporto al fisso. La vita di ciascun Kit è sostanzialmente coincidente con il ciclo di vita del software ed è riassunta nella Figura 1. La fase di analisi si differenzia nella componente di raccolta dei requisiti e in quella di definizione dei contenuti del Kit. Si individuano poi le fasi di sviluppo del software e infine di collaudo. Le attività interne a ciascuna fase sono espletate da specifiche strutture aziendali. Nella Figura 1 si evidenzia che la composizione della Piattaforma, alla release N, è data dalla Piattaforma alla Release N-1 cui si aggiungono le evoluzioni (regolatorio, mercato, business) e le modifiche indotte dalle correzioni di anomalie (bugfix), che si susseguono con cadenza pressoché settimanale. Il tempo che va dalla definizione dei requisiti al rilascio in esercizio, per un Kit di major release afferente alla linea fissa è di circa 5 mesi; di cui poco meno

4 95 regolatorio mercato Rel N1 evoluzioni business Definizione Requisiti Definizione Kit Shaping Tecnico Stime Composizione release Configurazioni Bug Fix Tempo Realizzazione Inrefacce Specifiche funzionali Sviluppo Collaudo Interno Utente Rel. N NETWORK SERVIZI Figura 1 - Timeline di produzione di un Kit Service Creation di un mese è dedicato alla fase di sviluppo (codifica). Questo modello di sviluppo, sebbene largamente utilizzato nel mondo IT e abbondantemente studiato e normato dall ingegneria del software, proprio in conseguenza della necessità di sviluppare in tempi sempre più rapidi sta portando al costante aumento del debito tecnico. La timeline per lo sviluppo di una release è pressoché costante, mentre cresce la richiesta di sviluppi da realizzare nel kit, per la pressione indotta dall esigenze di rapido time to market. Per il controllo / eliminazione del debito tecnico in letteratura si suggeriscono due approcci: fermare la fase di sviluppo di nuove funzionalità per risolvere un technical debt; l inserimento di nuove modifiche al software potrà riprendere solo quando il refactoring del codice e i nuovi test introdotti renderanno il prodotto soddisfacente; riprogettare e reimplementare il sistema, realizzare cioè un refactoring con un ciclo più lungo (della durata di mesi o anni piuttosto che di giorni). E evidente che il contesto in cui opera Telecom Italia non permette di seguire nessuno dei due approcci suggeriti, perché non si possono fermare gli sviluppi legati a nuovi prodotti e perché anche la seconda soluzione cura gli effetti e non le cause del debito. Nel seguito dell articolo si descriveranno alcune iniziative che hanno l obiettivo di migliorare la qualità e il time to market nei processi di sviluppo software; in particolare una delle iniziative si propone di introdurre nuovi Key Performance Indicators per misurare i benefici apportati. Tra i nuovi indicatori si potrebbe pensare di introdurre la misura del debito tecnico, procedendo con la valutazione del debito accumulato nel corso degli ultimi 12 mesi per poi confrontarla con analoga misura sul prossimo anno, utilizzando a tale scopo la [1] nella sua forma semplificata, che tiene in conto soltanto il costo delle bugfix. E importante sottolineare che il costo di una bugfix deve essere inteso come somma dei costi rilevabili in ciascuna fase del ciclo di vita, partendo dall analisi del problema per finire al collaudo. 2.2 Modello Colocation Si è già osservato che le strategie di riduzione del debito suggerite in letteratura, basate essenzialmente sul refactoring del codice, non sono applicabili al contesto Telecom Italia, sia perché ipotizzano, riduttivamente, che il debito sia generato solo nella fase di realizzazione, sia perché introducono un rallentamento negli sviluppi che va in direzione contraria alle spinte del time to market. E necessario perciò adottare una strategia che miri agli aspetti strutturali del problema: il tempo e la qualità. L approccio che seguiremo prende spunto dall analisi della curva (qualitativa) tempo-qualita-debito. Il debito diminuisce se a parità di tempo miglioriamo la qualità: questo approccio è valido se ipotizziamo che esistono margini di miglioramento della qualità, che probabilmente vanno ricercati in fattori organizzativi e processivi, prima che tecnologici. La maggior parte degli interventi proposti tendono a rendere più efficienti i processi esistenti,

5 96 NETWORK SERVIZI Misura e monetizzazione del debito tecnico Qualunque tentativo di contenimento del debito non può prescindere da una preliminare misura del debito stesso, che permetterà di valutare gli effetti delle iniziative adottate. Un interessante lavoro di Gartner (cfr.2) propone un metodo per monetizzare il debito tecnico di un applicazione software, basato sul conteggio delle violazioni alle best practices di codifica, relativamente agli aspetti di sicurezza, affidabilità e manutenibilità. E disponibile sul mercato anche un prodotto software che analizza automaticamente l applicazione di cui si vuole misurare l entità del debito tecnico. Tuttavia è nostra opinione che questa tipologia di misura e di monetizzazione fornisca, nel caso specifico della Piattaforma IT di Telecom Italia e specificatamente nel caso della Service Creation, indicazioni poco significative. Infatti se da un lato è condivisibile il criterio di monetizzazione, quando riferito ad uno specifico sistema (modello Project Based), esso risulta difficilmente applicabile ad un contesto nel quale il debito non è associabile esclusivamente alla fase di realizzazione del software. E infatti evidente che ciascuna fase del ciclo di vita, nel modello Service Creation, è soggetta ai vincoli di tempo dettati dalla timeline e perciò ciascuna fase, al crescere del numero di requisiti da soddisfare, viene affrontata secondo un principio quick and dirty: i requisiti possono essere raccolti frettolosamente e sommariamente, i contenuti del Kit possono essere definiti senza la dovuta accuratezza, lo sviluppo può procedere senza particolare attenzione e con limitate verifiche, in collaudo si possono effettuare un numero ridotto di test. Perciò nel modello Service Creation la monetizzazione del debito tecnico associato al codice software per quanto importante è riduttiva e poco significativa. Occorre, invece, considerare l intero ciclo di vita, per individuare le specifiche cause del debito, definire un criterio di misura e proporre opportune azioni di contenimento. Il peso del debito tecnico va ad erodere la capacità produttiva, a spese della quantità di nuovi prodotti che si possono realizzare nel tempo prefissato. Si osservi che in prima approssimazione possiamo definire il debito come lo scostamento dalla piena qualità attesa per un prodotto, che si raggiunge al tendere all infinito del tempo di sviluppo (Figura A). L insidia principale deriva dal fatto che il debito contratto in una release non Figura A: Debito tecnico, capacità produttiva e relazione con tempo e qualità Q Nuovi Prodotti Debito (interessi) Capacità produttiva Qualità piena T Qualità erogata nel tempo T Debito t Q T Figura 2 - Curve tempo / qualità t Q T t con l obiettivo di migliorare la qualità, partendo dall analisi della situazione as-is e introducendo fattori correttivi che intervenendo su processi esistenti hanno tendenzialmente un basso costo di implementazione. Il debito diminuisce se a parità di qualità erogata aumentiamo il tempo dedicato alle varie fasi del ciclo di vita. E evidente che non potendo modificare il tempo T end-to-end -

6 97 venga saldato nella release successiva, nella quale perciò il debito complessivo è la somma del residuo e del nuovo debito generato. Per comprendere gli effetti del fenomeno, fissiamo la capacità produttiva (Cp), il debito (Dg) generato in una release e la capacità di restituzione (Ds) del debito in una release. Per semplicità supponiamo fisse queste quantità. E facile dimostrare che il debito DN accumulato alla release N, partendo da un ipotetica release 1 a debito iniziale nullo, vale: DN = N Dg Ds (N-1) = N (Dg-Ds) + Ds. Alla release N = (Cp Ds)/(Dg-Ds), il debito accumulato diventa pari alla capacità produttiva. Qualche esempio. Cp=100gg, Ds=10gg, Dg=20gg. Dopo 9 release il debito è pari alla capacità produttiva. Se abbassiamo la qualità (Dg=30), bastano 4 release per saturare la capacità produttiva. Dato che Ds è fisso, si conclude che l accumulazione del debito tecnico tende all infinito. E importante osservare che il debito accumulato nelle fasi a monte del processo produttivo si propaga nelle fasi a valle. Una specifica funzionale scritta con approssimazione introduce un debito nella fase di analisi: occorrerà, prima o poi, fare i conti con la specifica scritta male, emergerà un anomalia di design e sarà necessario erodere parte della capacità produttiva della fase di analisi per la scrittura della specifica correttiva. Tuttavia, se anche il software sviluppato a fronte della prima specifica fosse perfetto e realizzato a debito zero, saremo comunque costretti a spendere parte della capacità produttiva di sviluppo per rimediare all errore di analisi. A partire dalla considerazione precedente, si può affermare che il debito tecnico (o gli interessi connessi al debito) in un modello Service Creation si accumula nel periodo T ed è proporzionale al peso delle bugfix e al numero di richieste di evoluzione su requisiti rilasciati nelle release immediatamente precedenti, dietro le quali spesso si celano le approssimazioni successive con le quali si realizza un determinato requisito: Debito_medio[T] = (K*N medio_bugfix + H* Ricircolo_su_evol_recenti ) [1] Il numero medio di rilasci di bugfix deve intendersi riferito alle bugfix su funzionalità comunque sviluppate nel periodo di riferimento, per distinguerle dagli interventi imputabili a problemi architetturali o funzionali dei sistemi software. Sia Nmedio_bugfix sia Ricircolo_su_evol_ recenti sono numeri puri, senza dimen- sioni, pertanto le dimensioni del debito saranno definite dalle dimensioni assegnate alle costanti K e H, che andranno necessariamente scelte omogenee. Se, ad esempio, K ed H si esprimono in euro/rilascio, il debito sarà misurato in euro. La [1] rappresenta un modo semplificato ma efficace per calcolare il peso del debito. Si tenga conto che a rigore K ed H non sono quantità costanti, ma dipendono dal peso della bugifx o del rilascio evolutivo. Tuttavia, quanto più ampio è l intervallo di osservazione T, tanto più la variabilità di K e H viene assorbita nella media degli interventi e aumenta l affidabilità della misura. Si potrebbe scegliere per T un valore compreso tra 6 mesi ed un anno: sufficientemente lungo da consentire di mediare sul peso degli interventi, sufficientemente breve per consentire di avviare efficaci e rapide azioni correttive. E inoltre ipotizzabile un ulteriore semplificazione della [1], andando a misurare il debito tecnico in termini di spesa sostenuta per le bugfix effettuate nel periodo T, trascurando in prima approssimazione le evoluzioni dovute alle approssimazioni successive nella definizione dei requisiti. michele.barone@sscenter.it NETWORK SERVIZI dobbiamo ricercare l ottimizzazione nella distribuzione dei tempi delle singole fasi, tenendo conto dell impatto sulla qualità nelle fasi eventualmente ridotte. In tal senso si propone una specifica iniziativa ( Produrre su misura, si veda più avanti nell articolo) che introduce il concetto di tailoring negli sviluppi, per assegnare più tempo ai requisiti più critici, detraendolo ai requisiti meno strategici. Migliorare la qualità e il time to market: 3 le proposte Per le caratteristiche industriali del processo di produzione del software e in particolare per le peculiarità del modello Service Creation (tempi, volumi e accoppiamento), risulta strategico - per massimizzare la qualità del servizio e il time to market - puntare a un modello di forte automazione in tutte le sue componenti e processi dedicati (Figura 4) in base alle tipologia di prestazioni da erogare (complessità realizzativa/priorità di business). Si propongono quindi alcune iniziative di miglioramento che sono state classificate per fase del ciclo di vita dei prodotti IT e per impatti su processi e sistemi a supporto. La Figura 5 sintetizza le iniziative raggruppandole per area e per impatto mentre la Figura 6

7 98 NETWORK SERVIZI Figura 3 Raccolta delle esigienze del Cliente e stesura del documento di requisiti, con le successive attività di analisi e validazione dei requisiti fino alla definizione del documento di Shaping Tecnico e la composizione delle release con prima stima 50% 17% Produzione e la validazione del documento di specifiche funzioni, verifica delle stime di progetto e consuntivazione delle attività di analisi Design e sviluppo della soluzione, esecusione dei test di sistema (system test) Programmazione Analisi Sviluppo Collaudo 11% Totale Interventi (10) 32% 5% 5% Fase di Analisi (1) Fase di Collaudo (3) 17% 33% 47% 33% 50% Modifiche di processo Estensione dei tool di supporto esistenti Introduzione di nuovi tool di supporto 17% 50% Esecusione del collaudo integrato e del collaudo utente e gestione dei rilasci in produzione 33% 17% 16% Figura 4 - Suddivisione - per fase del ciclo di vita - delle iniziative di miglioramento Fase Ciclo Programmazione Proposta Basi solide per piani robusti Fase di Programmazione (2) Fase di Sviluppo (3) Cross (1) 67% 50% 50% Estenzione dei sistemi IT esistenti Potenziamento dell infrastruttura tecnologica Modifiche del processo Estensione tool IT Prima classe su misura Analisi Requisiti in piattaforma Sviluppo Collaudo Cross associa le iniziative alle fasi del ciclo di vita e agli impatti sui processi e sui sistemi a supporto. Introduzione tool IT Offriamo ordine Team building per un Team as a building Ricominciamo a fare la storia : evolviamo il modello di offerta Estensione sistemi IT Potenza infrastrutturata Lucidiamo l officina Mettiamo il tubo al test In pista con il Cliente Misure in qualità per qualità su misura 3.1 Basi solide per piani robusti L iniziativa si propone di ridurre il margine d incertezza insito nel modello Service Creation (cfr. 2.1), avvicinandolo, per quanto possibile, alle caratteristiche del più lineare modello Project Based. E necessario anticipare le stime sugli sviluppi, così da rendere più efficace la pianificazione dal parte del committente e più efficiente l ingaggio delle fabbriche. La capacità produttiva delle fabbriche è praticamente costante nel tempo, mentre le richieste della Service Creation creano picchi di carico: l idea è di definire una sorta di masterplan delle iniziative di maggior peso (che tuttavia non possono essere considerate Project Based), allocandole opportunamente nel tempo (le basi solide ), così da avere un idea chiara della residua capacità produttiva in ogni Kit, per saturarla al meglio con le richieste impulsive della Service Creation (i Piani robusti). Per garantire l efficacia della proposta è opportuno il coinvolgimento precoce Figura 5 - Impatti delle iniziative di miglioramento

8 99 di tutte le strutture IT fin dalla fase di concept degli sviluppi. 3.2 Requisiti in piattaforma Per evitare o ridurre che nel processo di lavorazione dei circa requisiti utente/anno ci si limiti allo scambio di con attachement MMS, il che introduce rallentamenti sul processo di consultazione e accesso allo storico delle informazioni, si propone l introduzione di una piattaforma di gestione documentale integrata e di collaboration che consenta di archiviare in modo centralizzato i documenti, oltre che avere un accesso profilato al dato in base alla tipologia di documento. 3.3 Prima classe su misura Oggi esistono modalità diverse e diversi momenti temporali in cui viene comunicata a IT l importanza di business delle circa prestazioni gestite ogni anno. Attualmente l informazione è disponibile solo a ridosso dell avvio della fase di collaudo (ultimo mese del ciclo produttivo), non consentendo di gestire l item in maniera differenziata già dalle fasi precedenti del ciclo. Si propone di introdurre una nuova procedura operativa che a seconda del momento in cui l informazione di priorità di business venga resa disponibile, permetta di avere un trattamento premium. L informazione deve essere tracciata sui sistemi aziendali di supporto al processo produttivo, in modo da raggiungere istantaneamente le oltre persone che lavorano nella produzione SW. Tale procedura consente di implementare processi premium da associare alle prestazioni strategiche e, più in generale, di implementare una gestione del flusso processivo secondo le logiche del tailoring, al fine di massimizzare la qualità. 3.4 Offriamo ordine Si ribadisce l essenzialità di un unico punto in cui venga descritto in modo completo, aggiornato e facilmente consultabile il portafoglio delle varie offerte commerciali aziendali in termini di tipologia offerte, periodo di validità, caratteristiche. 3.5 Team building per un Team as a building Si propone di rivedere le regole di attribuzione delle attività di sviluppo, con l obiettivo di costruire un Team IT solido, stabile e affidabile. Sulla base della strategicità, delle priorità e del peso degli sviluppi, si definirà l allocazione (interna o in outsourcing) delle attività afferenti alle diverse fasi del ciclo produttivo,, con particolare riferimento alla fase di realizzazione dove si terrà conto prevalentemente delle conoscenze che sono caratteristiche dell ambiente IT di Telecom Italia. rispetto a quelle che sono più general purpose (es. conoscenza linguaggi di programmazione) e pertanto di più semplice reperimento sul mercato.. L iniziativa, operando sinergicamente con altre proposte (Basi solide, Prima Classe) contribuirà al complessivo efficientamento dell IT e al conseguente miglioramento della qualità dei prodotti IT. 3.6 Evolviamo il modello di offerta La dinamicità del mercato impone di avere a disposizione un processo di delivery di nuove offerte/servizi snello ed efficace, nonché la continua manutenzione dei sistemi in ottica di massima parametrizzazione, riutilizzo e affidabilità delle componenti applicative progettate. La declinazione dei nuovi servizi/offerte sui vari sistemi (CRM, Billing,...), che avviene tipicamente mediante la proliferazione di diversi tool di configurazione, è spesso causa di inefficienze. Per fronteggiare questi problemi si propone di evolvere i sistemi a supporto dell evoluzione del modello di offerta, oltre che di adottare un tool di configurazione unico sui diversi sistemi, come ad esempio XCS (expert Configuration System) già attivo in Azienda. 3.7 Potenziamo gli ambienti di collaudo e delle aree di test La fase di collaudo del SW è particolarmente rilevante per i miglioramenti sia della Qualità (capacità di individuare il maggior numero dei difetti prima della messa in produzione), che del Time To Delivery (è l ultima fase di un ciclo complesso ed in quanto tale non ha margine per recuperare i ritardi). Sul fronte dell aumento dell efficacia del collaudo (capacità di individuazione dei difetti SW) si propone di stendere gli ambienti HW/SW tra loro integrati per la verifica delle catene applicative sia per le attività evolutive che per quelle di manutenzione correttiva (bugfix)e di dotare tali ambienti di data base (con dati opportunamente trattati secondo le procedure previste dal Regolatore) il più possibile rappresentativi della complessità e variabilità degli ambienti di produzione. Sul fronte sia dell efficacia, che dell efficienza si opta per: estendere l approccio di Continous Integration (automazione dei test di non regressione) avviato in ambito del Test di Sistema alle fasi di Collaudo Funzionale ed Integrato; dotarsi di uno strumento per l automazione dell esecuzione delle cate- NETWORK SERVIZI

9 100 NETWORK SERVIZI ne di test propedeutiche (ovvero dei test che devono essere eseguiti necessariamente prima di tutti gli altri in quanto consentono la predisposizione dei data set necessari) In pista con il Cliente: migliorare il Collaudo Utente Le attività di collaudo utente sono di fondamentale importanza per la qualità del prodotto finale IT; tali attività oggi non seguono sempre un processo standardizzato, per questo si propone ad esempio di implementare nei tool di supporto IT funzionalità ad hoc per supportare la gestione delle pianificazioni e l esecuzione dei Collaudi Utente e creare relativa reportistica di avanzamento lavori. Multimeter: Misure di Qualità per Qualità su Misura La misura di un fenomeno è utile se contribuisce al suo miglioramento, quindi se supporta la creazione di valore. Una misura crea valore se è oggettiva, quindi condivisa e comprensibile a chi, analizzandola, deve indirizzare azioni correttive o di miglioramento, e per ultimo fruibile, quindi disponibile nei tempi e nelle modalità opportune. Pertanto è opportuno definire dei Key Performance Indicator condivisi tra IT e le sue linee committenti in Azienda per abilitare ad esempio un reporting che sia multicanale e multidimensionale (per multicanalità si intende la disponibilità delle misure su strumenti e per multidimensionalità si intende la possibilità di aggregare/disaggregare le misure in funzione delle esigenze specifiche del report). Conclusioni La produzione del software è un processo human intensive e quindi poco automatizzabile; perciò i metodi di ingegnerizzazione per quanto l ingegneria del software sia in continua evoluzione non sono sufficienti a definire un contesto di sviluppo totalmente deterministico, al contrario di quanto solitamente avviene negli altri settori industriali. Le conseguenze di questa caratteristica specifica del software si amplificano allorquando il mercato chiede una produzione sempre più rapida e a costi sempre più contenuti: la qualità dei prodotti può diminuire e questa diminuzione di qualità si paga in termini di anomalie, continue revisioni dei prodotti e perdita d immagine verso i clienti. Lo sviluppo quick and dirty equivale a tutti gli effetti all accumulo di un debito tecnico, che può essere monetizzato ed espresso in euro. Il debito tecnico è insidioso, perché si autoalimenta (debito genera debito) e perché riduce la capacità produttiva efficace. Anche la piattaforma IT di Telecom Italia non sfugge a questa dura realtà, in special modo per quella vasta categoria di sviluppi (Service Creation) che sono realizzati per rispondere in tempi rapidi alle spinte evolutive. Siamo però certi che esistano margini di ottimizzazione dei processi produttivi che potrebbero incrementare la qualità e contribuire alla riduzione del debito tecnico marco.dacco@telecomitalia.it erminiomarco.iacomussi@telecomitalia.it gaetano.rossi@sscenter.it Acronimi BPM: Business Process Management BSS: Business Support Systems FP: Function points DMO: Domestic Market Operations KPI: Key Performance Indicator KPO: Key Performance Objective MOI: Mano d opera d impresa PDO: Profilo d offerta SOA: Service Oriented Architecture Bibliografia [1] Ward Cunningham, The WyCash Portfolio Management System ; doc/oopsla92.html. [2] Gartner white papers, How to Monetize Application Technical Debt.

10 101 Marco Daccò Ingegnere gestionale, vanta una esperienza di oltre 15 anni nel settore ICT per la industry delle Telecomunicazioni. A metà anni novanta ha partecipato allo start up della prima joint venture tra Telecom Italia e Bell Atlantic (oggi Verizon) per la realizzazione dell attuale polo ICT di Trento. Fino al 2000 ha seguito progetti informatici per la divisione statunitense, occupandosi di Service Activation xdsl e Servizi Near Video On Demand. Attualmente è responsabile della programmazione tecnica della domanda informatica del Mercato Domestico all interno della divisione di Information Technology. Marco Iacomussi Laureato in Economia e Commercio nel 1995 entra in Telecom Italia. Dal 1996 al 1999 partecipa, per la componente IT, a diverse iniziative Internazionali di merge & acquisition da parte di TIM, supportando le fasi di start-up delle iniziative e nel 1998 è responsabile della start-up di Amena in Spagna per il lancio del servizio Prepaid. Nel Maggio 1999 diventa responsabile dello sviluppo dei sistemi OSS nell ambito dell IT di Wind Telecomunicazioni. Nel 2000 rientra in TIM per assumere la responsabilità della domanda e sviluppo dei sistemi BSS di TIM. Oggi è responsabile della Qualità e Processi IT della funzione IT di Telecom. Gaetano Rossi Laureato in Biologia Molecolare entra in So.Ge.I. nel 1989 per occuparsi di produzione SW anche in ambito TLC. Nel 1991 entra in Telesoft dove ha la responsabilità di un laboratorio di produzione SW presso la filiale di Mosca per poi assumere la responsabilità di progetti di rinnovamento della piattaforma IT, tra cui WFM, Designer e A-TOM. Nel 2005 prende in carico la responsabilità della sede di Napoli della SW Factory OSS di Telecom Italia. Da Maggio 2010 dirige il Polo di Napoli della SW&Testing Factory di SSC, dove risiedono le attività di sviluppo per ambiti rilevanti della piattaforma IT di Telecom Italia.