procesprocessi di produzione del si di produzione del...

Julian Piagneri Ingegnere delle telecomunicazioni

ENSEA – La Sapienza

Tutore alla ElsagDatamat : Tutore alla Sapienza : Emmanuele Tordelli Roberto Cusani Responsabile del gruppo della qualità Direttore del dipartimento delle Per il prodotto ANTS Telecomunicazioni

ElsagDatamat, Roma La Sapienza, Roma

PROCESPROCESPROCESPROCESSI DI PRODUZIONE DEL SI DI PRODUZIONE DEL SI DI PRODUZIONE DEL SI DI PRODUZIONE DEL

SOFTWARESOFTWARESOFTWARESOFTWARE

&&&&

INGEGNERIA DELLA QUALITA’INGEGNERIA DELLA QUALITA’INGEGNERIA DELLA QUALITA’INGEGNERIA DELLA QUALITA’

TESI DI LAUREA SPECIALISTICA IN INGEGNERIA DELLE TELECOMUNICAZIONI

Progetto di fine di studio in azienda nell’ambito del programma ERASMUS – SOCRATES

Febbraio 2009

Processi ed ingegneria alla qualità nell’industria del software Julian Piagneri

Febbraio 2009

Prima di iniziare, vorrei ringraziare le persone senza le quali il mio progetto di fine studio non avrebbe potuto avere luogo. ElsagDatamat

Emmanuele Tordelli : Responsabile del gruppo della qualità del prodotto ANTS.

Ha messo in piedi questo stage sulla documentazione dei processi che mi ha permesso di fare il tirocinio nelle migliore condizioni, sia al livello amministrativo che per l'integrazione nel gruppo di lavoro.

Daniele Cacciani : Ingegnere nel gruppo della qualità

È stato il mio tutore di stage a ElsagDatamat, avendomi seguito durante questi sei mesi, mi è stato di grande aiuto sia sull'aspetto tecnico che per la scrittura della tesi.

SAPIENZA

Professore Roberto Cusani : Direttore del dipartimento delle telecomunicazioni alla Sapienza.

Il mio tutore di stage nella facoltà. Ha reso possibile il tirocinio a livello amministrativo della Sapienza e mi ha anche aiutato nella scrittura della tesi.

Professore Salvatore Monaco : Professore “Teoria dei sistemi” alla Sapienza.

Nonché responsabile delle relazione Francia – Sapienza e soprattutto ENSEA – Sapienza, prendendo un grande impegno in questo compito. E all’origine dello scambio SOCRATES – ERASMUS, mi ha permesso di partire a Roma nell’ambito di questo progetto.

ENSEA

Christian Faye : Direttore delle relazioni internazionale all’ENSEA.

Ha reso possibile questa partenza per Roma, lavorando con il Professore Monaco e prendendo degli impegni nelle difficoltà amministrative dell’ENSEA.


Febbraio 2009

La presente tesi tratta del lavoro fatto durante il progetto di fine formazione d’ingegnere in elettronica e telecomunicazioni in azienda.

Questa formazione è iniziata nel 2004 all’ENSEA – “Ecole Nationale Supérieure de l’Electronique et de ses Applications”, seguita,dopo due anni e mezzo, da un programma ERASMUS SOCRATES alla Sapienza di un anno e mezzo, per ottenere la specializzazione nella ingegneria delle telecomunicazioni, nell’ambito dell’accordo per l’ottenimento del doppio titolo ENSEA – SAPIENZA.

Per concludere questo percorso e passare al mondo del lavoro, ho deciso di seguire uno stage in azienda.

Il tirocinio si è svolto nel gruppo della qualità del prodotto ANTS – sistema di test per reti mobili – della società ElsagDatamat , da marzo ad agosto 2008.

Questo stage tratta del seguente argomento : “creazione di un Framework di descrizione dei processi di produzione del prodotto allo scopo di una standardizzazione interna”.

Come indica il titolo della tesi, due argomenti principali sono presentati nelle pagine che seguono, uno direttamente legato alla creazione del Framework volto al miglioramento della comprensione e alla standardizzazione dei processi di produzione ed uno che tratta più nel dettaglio le attività della Quality Assurance che ho praticato durante la mia integrazione.

Queste due parti completano la formazione scolastica e mi preparano al futuro professionale.

È sotto questo aspetto che ho orientato la scrittura della tesi.

Buona lettura…


Febbraio 2009

INDICE

Glossario Pagina 1

1 Introduzione Pagina 4

- 1.1 Lo stage Pagina 4

- 1.2 ElsagDatamat & ANTS Pagina 6

2 Creazione del Framework di descrizione Pagina 16

- 2.1 La situazione prima dello stage Pagina 16

- 2.2 L'iniziativa, come è stato creato Pagina 17

3 Struttura del Framework Pagina 21

- 3.1 Gli elementi Pagina 22

- 3.2 Chiarezza di navigazione Pagina 25

4 Struttura delle release Pagina 28

- 4.1 Feature Pagina 28

- 4.2 Livelli di release & elementi della Build Pagina 30

5 I processi descritti & i diversi ambienti Pagina 32

- 5.1 I diversi ambienti Pagina 32

- 5.2 Processo dello sviluppo Pagina 34

- 5.3 Processo del customer support Pagina 36

- 5.4 Processo di Change Management Pagina 39

- 5.5 Processo di test Pagina 43

- 5.6 Altri processi da descrivere Pagina 45

6 Quality Assurance Pagina 46

- 6.1 Test (tipi di test, QA) Pagina 46

- 6.2 Classificazione ODC Pagina 53

- 6.3 Tools and database Pagina 58

- 6.4 Schedule & Quality control Pagina 63

7 Miglioramenti previsti Pagina 74

Commenti Finali Pagina 75

Processi di produzione del software & Ingegneria della qualità Julian Piagneri

Febbraio 2009 Pagina 1/77

GLOSSARIO In questo glossario, trovate i termini specifici alla tesi e la loro definizione. ANTS : (Automatic Network Test System) Sistema installato presso una rete mobile, composto di diverse periferiche (OS, Database, …) per effettuare diversi test sulla rete. Framework : Insieme di pagine html strutturate sotto forma di frame : Menù, sottomenù, pagine … ODC : (Orthogonal Defect Classification) Metodo di classificazione ortogonale dei richieste di cambiamento su un prodotto. Permette un migliore tracciamento e una valutazione quantitativa dell’efficacia dei processi di produzione del software. Trigger : Parametro di classificazione ODC, definisce il tipo di operazione dell’utente che ha fatto emergere il difetto. RTU : (Remote Test Unit) Periferica del sistema ANTS che contiene o simula le porte (telefoni) usate nei test. RRS : (Remote Record Selector) Periferica del sistema ANTS che filtra e mette in ordine i CDR (Call Data record) che contengono le informazioni delle comunicazioni effettuate sulla rete. TTV : (Toll Ticketing Verification) Applicazione di ANTS che contiene un’insieme di funzionalità avendo il compito di fare la verifica esauriente dei CDR. OSS Server : (Operational Support System) Server centrale del sistema ANTS. Client ANTS: Interfaccia installata sul PC dell’utente, che si collega al server OS di ANTS tramite il protocollo http o https. GRA : (Global Roaming Architecture) Architettura ANTS pensata per poter essere utilizzata da diversi operatori, condividendo risorse. Questa struttura permette di effettuare i test di Roaming. Quality Assurance team : Gruppo di lavoro che ha il compito di validare il funzionamento del prodotto attraverso test di componente, funzionali e di integrazione. Ha il compito anche di gestire il controllo di configurazione del codice sorgente e di realizzare la documentazione di prodotto. Professional Service : Gruppo di lavoro che fornisce ai clienti dei servizi professionali su richiesta, quali il disegno di procedure di test, l’installazione e il dimensionamento del sistema, la configurazione etc...



Customer Support : Gruppo di lavoro che riceve, analizza e gestisce le richieste di supporto dei clienti. Project Manager : Persona in relazione diretta con il cliente. Ogni cliente ha il suo Project Manager. Product Manager : E il responsabile del prodotto, in carico di prendere le decisioni più importanti (Avviare una nuova feature, definire i contratti con i clienti, …). Step : Funzione di base per i test, direttamente integrata nel codice del software. Test Procedure : Procedura di test composta di step e descritta sotto forma di diagramma. RUP : (Rational Unified Process) Metodo di descrizione standard dei processi di produzione del software, pensato da Rational e IBM. EPF : (Eclipse Processes Framework) Tool di creazione di framework di gestione di processi. Sviluppato appositamente per descrivere i quello di tipo RUP. Ruolo : Insieme delle competenze e dei compiti associati ad una persona. Un ruolo può corrispondere a più persone e una persona può avere più ruoli. Task : Compito eseguito da uno o più ruoli. Attività : Insieme di task coordinati da eseguire in un momento del processo. Input : Prodotto in entrata ad un task in genere a cui sarà aggiunto il valore di un lavoro che diventerà output, oppure un prodotto necessario all’esecuzione del task. Output : Prodotto in uscita ad un task, creato da questo ultimo o trasformato aggiungendo all’input un valore aggiunto, oppure interamente prodotto dal task. WorkProduct : Prodotto gestito da un task : Input o Output. Release : Versione del software caratterizzata da un insieme di feature ed enhancement. Hot-Fix : Piccola “patch” del software aggiunto sul sistema senza re-installarlo interamente per risolvere un bug. WorkAround : Operazione consigliata al cliente per contornare un bug aspettando una risoluzione in una build successiva.



Build : Processo di compilazione del codice sorgente che ha come output codice compilato ed eseguibile. Feature : Una funzionalità integrata o da integrare al progetto. General Available : Build finale di una release che viene rilasciata al cliente. Defect : Richiesta interna di correzione di un’anomalia rilevata sul prodotto. Enhancement : Richiesta interna di un miglioramento del prodotto. Change Document : Richiesta esterna di correzione o miglioramento del prodotto. BVT : (Basic Validation Test) Insieme di test fatti ad ogni build per verificare le funzionalità base del sistema. CVT : (Component Verification test) Insieme di test che verificano e convalidano le feature implementate in una nuova release. Test Tracking Tool : Tool, utilizzato per tracciare lo stato dei test da eseguire. Configuration Management Tool : Tool, utilizzato per gestire lo stato di configurazione del progetto (componenti e file del software, baseline, request, etc…). Change Request Tool : Sotto-parte del “Configuration Management Tool” che gestisce le richieste di cambiamento effettuate sia dei dipendenti che degli utenti esterni all’azienda. People.Day : Unità di misura che esprime un costo di lavoro. Un People.Day è il lavoro fatto da una persona in un giorno.



1 Introduzione

Sono stato inserito dal 3 marzo 2008 nel gruppo di Quality Assurance del prodotto ANTS nell'azienda ElsagDatamat di Roma da Emmanuele Tordelli responsabile di questo gruppo, nell'ambito di uno stage di 6 mesi per concludere la mia formazione d'ingegnere.

Invece di fare una tesi in laboratorio su un argomento teorico o puramente tecnico, ho scelto di fare il mio progetto di fine di studio integrandomi nel modo dell’industria. Questa tesi conclude la mia formazione ed entra nel programma di ottenimento del doppio titolo ENSEA-SAPIENZA proposto dall’accordo SOCRATES-ERASMUS MULTILATERALE DI COOPERAZIONE Italia – Francia PER L’ATTRIBUZIONE DEL DOPPIO TITOLO). E’ stato possibile finalizzare la formazione d’ingegnere attraverso l’integrazione nel mondo del lavoro in azienda ; allo studio teorico dell’università, si sono in questo modo aggiunti concetti propri dell’industria. È questo il lavoro che sarà esposto nella presente tesi.

1.1 Lo stage

L’obiettivo principale dello stage è stato la creazione di un Framework di

descrizione dei processi di produzione del prodotto allo scopo di una standardizzazione interna.

Si tratta di un sito interattivo dove sono descritti in modo omogeneo i processi usati per produrre il software in ElsagDatamat. In seguito sarà spiegato perché e come è stato sviluppato questo Framework.

Oltre alla creazione di questo Framework, per concludere nel migliore dei modi lo stage di formazione, era importante anche imparare l'insieme delle funzionalità ed attività del gruppo di QA, anche con l'obiettivo di essere assunto. Dunque le mie attività di questi sei mesi non sono state limitate soltanto al framework, ma ho eseguito anche altri compiti che sono esposti più avanti in questo rapporto ; principalmente test, installazioni, disegno di casi di test, studio del prodotto.



Ho scelto di scrivere come tesi il rapporto del mio stage intorno a due punti principali :

A) Descrizione dei Processi e di come sono stati inseriti nel framework : L’aspetto gestionale dello stage ; comporta sia un lavoro di comprensione dei processi industriali, sia un lavoro di comunicazione in modo da raccogliere le informazioni per completare il Framework. Il lavoro su questo argomento mi permette di avere, appena entrato nel mondo dell’industria, una vista d’insieme del funzionamento dell’azienda a livello produttivo.

B) L'apprendimento delle funzionalità ed attività della QA : L’aspetto tecnico dello stage ; basato sopratutto su un lavoro pratico di esecuzione dell’insieme dei task del gruppo, e anche un’analisi teorica del lavoro del QA Manager (successivamente presentato nel capitolo 6).

Quindi, questa tesi presenta un doppio aspetto di quello che è stato il mio inserimento in azienda : uno con una visione generale (descrizione dell’insieme dei processi), e uno con una visione di approfondimento (attività e analisi del gruppo della qualità).

Nella presente tesi che prende forma di rapporto di stage, si fa prima, nel primo capitolo, una presentazione dell’azienda e del prodotto su cui ho lavorato.

Successivamente, nei capitoli 2 e 3 si parla del Framework stesso : perché e come è stato creato. Nel capitolo 5 presento la struttura del prodotto rilasciato.

Il capitolo 5 descrive i diversi gruppi di lavoro ed i processi associati ed espone il contenuto del Framework sinteticamente. Il capitolo 6 presente, per finire, i compiti del gruppo di Quality Assurance in un modo più dettagliato.

Infine, questa tesi tratta due concetti diversi ma legati fra loro, la parte tecnica e la parte gestionale, la prima essendo un approfondimento della seconda.

Sono molto contento di presentare questo documento, e descrivere questa esperienza di sei mesi dove ho potuto mettere in pratica la mia formazione e le mie competenze tecniche, insieme a una formazione sull'aspetto gestionale della produzione del prodotto.



1.2 ElsagDatamat & ANTS

ElsagDatamat è un azienda del gruppo Finmeccanica che lavora in diversi settori

quali la difesa, l’aerospaziale, i trasporti o le telecomunicazioni. In questo ultimo settore, l’azienda produce ANTS (Automatic Network and Services Test System) : un sistema di test per le reti mobili che si installa presso i datacenter dell’operatore per effettuare diverse simulazioni ed operazioni. Sul prodotto ANTS lavorano circa 60 persone ripartite fra le città di Roma, Bologna, Padova e Parigi.

ANTS si adatta in continuazione all’evoluzione delle tecnologie mobili. Ad oggi il

sistema può eseguire simulazioni e ottenere misurazioni relative ad operazioni quali : Videochiamata, Donwload/streaming, gestione di mail su BlackBerry, chiamata voce, dati, SMS, MMS etc … E offre ai suoi clienti tre servizi principali :

Service Assurance : Insieme dei test end-to-end che permette di verificare le QoS delle infrastrutture prendendo in conto tutte le funzionalità e i servizi che l’operatore mette a disposizione dell’utente finale della rete mobile: (Chiamate, SMS, Video chiamate, WAP\HTML navigation …).

Revenue Assurance : Permette di fare l’analisi delle fatturazioni rispetto all’uso fatto della rete. Questo tipo di procedura si fa principalmente in base alle informazioni raccolte sulla rete dell’operatore sotto forma di CDR (Call Data record).

Roaming Assurance : Permette di valutare la QoS ed il costo delle operazioni effettuate dall’operatore all’estero. Questa operazione permette di verificare gli accordi fra gli operatori dei diversi paesi.

(La descrizione di questi servizi saranno sviluppati in seguito insieme alla

presentazione della struttura del sistema 1.2.1).

ANTS è riuscito ad inserirsi su un importante segmento del mercato in Europa con clienti quali : Vodafone, TIM, H3G in Italia, SFR in Francia, Mobitel in Slovenia, Proximus in Belgio, etc....

Ma ha anche diversi clienti nel mondo come TimBrasil in Brasil, Qtel in Qatar, Ais In Tailandia, Claro in Perù, Digitel in Venezuela, etc …



1.2.1 Descrizione del sistema e sua architettura

Per poter offrire i servizi enunciati nel paragrafo precedente, il sistema ANTS è stato concepito per eseguire delle simulazioni, misure, analisi, statistiche e generazione di reports sulla rete reale.

Per questo, ANTS è costituto da diversi elementi espansi su una piattaforma e collegati alla rete dove saranno effettuati i test. Tutti questi elementi sono collegati fra di loro attraverso la rete IP, e quindi accessibili dal personale ANTS da remoto per delle eventuali configurazioni.

Schema dell’installazione del sistema ANTS su una rete mobile :

Il sistema ANTS, si sviluppa intorno ad un server centrale associato ad un database, con delle macchine periferiche collegate al server tramite la rete IP, ciascuna avente un suo ruolo :



• Macchine di simulazione :

RTU (Remote Test Unit) : È una periferica composta di porte cioè terminali mobili (o cellulari) destinati ad essere associati a delle SIM per fare delle comunicazioni sulle reti mobili. Esistono vari tipi di porte che possono simulare il comportamento di diverse tecnologie di cellulari e possono essere utilizzate su tutti i tipi di rete (GSM\GPRS, EDGE, UMTS …)

SIM Archive : È una periferica dove in appositi slot è inserita una certa quantità di SIM che vengono associate virtualmente alle porte delle RTU per simulare i diversi servizi di rete. Tipicamente un’architettura completa possiede diversi SIM Archive dove si trovano tutte le SIM che saranno associate a diverse porte sparse sulla rete

• Macchine di raccoglimento di dati della rete :

RRS (Remote Record Selector) : Questa periferica filtra e mette in ordine i CDR (Call Data record) che vengono presi dagli MSC della rete dell’operatore.

RRP (Remote Record Processor) : Questa periferica, recupera i CDR già filtrati dalla RRS e ne estrae l’informazione utile che verrà poi archiviata dal server. La RRP, spesso, è installata sulla stessa macchina della RRS (per questo, non appare sullo schema).

• Macchina di configurazione :

PC Client : Spesso è il PC personale dell’utente, dove viene installato l’interfaccia cliente tramite quale sono eseguite l’insieme delle operazioni : - Configurazione di periferiche - Configurazione di un test - Consultazione delle misure - Generazione di un grafo - …



Tramite questi dispositivi, possono essere offerti agli operatori di telefonia i servizi enunciati prima e che adesso descriveremo meglio :

• Service Assurance :

È un servizio che valuta la qualità della rete e dei servizi che offre l’operatore attraverso di essa. Queste valutazioni si fanno grazie ad un insieme di test end-to-end che prendono in conto tutte le funzionalità dell’operatore (Chiamate voce, SMS, Video chiamate, WAP\HTML navigation …). Per fare questi test, sono usate le periferiche di simulazione (RTU, SIM Archive) sempre installate intorno ad una piattaforma centrale che fornisce le istruzioni.

Da questi test sono estratte delle misure registrate sotto KPI o KQI (Key Performance Indicator o Key Quality Indicator) che permettono un analisi più efficiente dei risultati delle simulazione e la generazione di eventuali allarme. Oltre a ciò è possibile generare dei report a partir delle misure rilevate.

Schema del funzionamento per la “Service Assurance”

• Revenue Assurance :

Questo servizio offre all’operatore la possibilità di valutare l’accuratezza dell’accreditamento per poter rispondere ad un mercato sempre più competitivo e poter mantenere un alta soddisfazione dell’utente finale.

Lo scopo principale è di identificare errori di fatturazione analizzando i CDR generati dalla rete a seguito di simulazioni, effettuate dal sistema di “Service Assurance”. I CDR (Call Data Record), prodotti artificialmente dalle campagne di test,



vengono raccolti dalle periferiche RRS direttamente collegate alla rete dell’operatore. A questo fine è stato messo in piedi una funzionalità molto complessa, chiamata TTV, che analizza i CDR.

I risultati di queste analisi automatiche sono registrate sotto forma di KPI in modo da generare eventuali allarmi e fare delle analisi più chiare.

Schema del funzionamento per la “Revenue Assurance”

Il sistema permette anche di verificare la disponibilità e l’integrità dei CDR del

traffico reale in diversi punti della rete.

• Roaming Assurance :

Per le comunicazioni internazionali sempre più numerose, e anche in vista dello sviluppo delle nuove tecnologie a livello internazionale soprattutto per gli utenti professionali (i.e. videoconferences …), gli operatori hanno bisogno di valutare la QoS ed il costo delle operazioni effettuate dal cliente all’estero. Lo scopo è verificare gli accordi fra gli operatori di diversi paesi ma anche garantire la migliore qualità agli utenti in viaggio all’estero.

Globalmente, il concetto è d’offrire i servizi della “Service Assurance” usando le stesse procedure di test e raccogliendo gli stessi tipi di misure registrate nei KPI in modo da analizzarle e generare eventuali allarme.



La difficoltà è quindi di estendere i test a delle reti che prendono in conto diversi operatori e condividere le risorse fra di loro.

Per questo, occorre creare una piattaforma che prende in carico e gestisce più operatori. Questa piattaforma, il GRA (Global Roaming Architecture), permette di condividere fra gli operatori interessati a questo servizio tutte le risorse ANTS (RTU, SIM Archive, …). Il GRA è strutturato come sullo schema in seguito :

Global Roaming Arhitecture

Da i due operatori sono installate delle RTU (porte), in rete locale, sono installati sia le RTU che i SIM Archive. Dunque, per fare diversi tipi di test, le SIM presente nel SIM Archive possono essere associate alternativamente alle porte dell’operatore #1 e dell’operatore #2.



1.2.2 Struttura Software e dei test

Vediamo adesso come è strutturato ANTS a livello di componenti software. Nella prima parte, le diverse componenti installate su ogni elemento dell’architettura ; nella seconda parte, la struttura del test.

• Componenti software del sistema :

- Software per le periferiche : Sulle macchine alla periferia del server, devono girare dei software. Per alcune periferiche (SIM Archive), abbiamo un hardware dedicato, il software esegue dei task di base per fare funzionare la macchina. Per altre periferiche (RTU-PC, RRS), il sopporto hardware è proprio un PC e il software installato puo’ essere anche molto complesso complesso. Il software di un SIM archive è prevalentemente dedicato alla getsione dell SIM e alla loro virtualizzazione sulle periferiche. Il software di una RTU-PC ha invece il compito di emulare il comportamento di una cellulare e di controllare l’esecuzione dei test end-to-end (WAPMms, Imps, Streaming, videocall…).

- Server OSS : Il software installato sul server centrale che è forse la componente più complessa del sistema ha il compito di : - Schedulare i test. - Distribuire le risorse. - Effettuare le misure. - Estrarre e inserire i dati nel database. - Generare dei report. - … Per tutte queste funzionalità, sono necessari diversi sottocomponenti che costituiscono l’OSS (Website, Server FTP, servizi ANTS)

- Client : È l’interfaccia cliente, quella che connette l’utente al server. Essa è composta da diverse “User Interface” : (TP Manager, RTU Manager, Test Procedure Management, Test Designer, Test Scheduler). Questa componente è un’interfaccia grafica che può essere installata sul PC dell’utente e tramite la quale sono eseguite tutte le operazioni di configurazione e controllo del sistema ANTS



• Struttura della procedura di test :

Un test eseguito può essere di tipo standard, cioè predefinito nel sistema o concepito, ad esempio su richiesta di un cliente, con un editor di procedure a partire dagli step.

Step : Sono gli elementi base scritti che possono essere utilizzati per costituire procedure di test. (“test procedure”), agiscono inviando comandi (principalmente AT) alle porte (cellulari) prendendo in considerazioni dei parametri in input. Gli step collezionano anche misure di diversi tipi dalle periferiche, restituendole poi in output.

All’interno della procedura, sono disegnati diverse fasi sotto forma di diagrammi a partire da questi step.

Esempio semplice di una Test Procedure

La strutture di una “test procedure” è concepita secondo una struttura “TP� Phase � Step”. Sullo schema sopra, a sinistra : la TP composta di fasi, di parametri e di misure ; a destra, : la fase composta di step (funzione di base del sistema).

La “Test Procedure” ha per parametri di input tutti gli input degli step che la compongono e in output le misure di tutti gli step che la compongono.

Una volta definite, queste “Test Procedure” sono configurate tramite l’interfaccia di “Test Design” dove possono essere associate più “Test Procedure” e dove i parametri di input vengono specificati.



In una seconda fase, tramite l’interfaccia “Test Scheduler” i test possono essere schedulati, sia in modo periodico, ritardato (ad esempio : programmato per il giorno dopo), sia istantaneo (da eseguire subito).

Per concludere, ecco un schema di sintesi che mostra gli elementi che costituiscono un test :

Schema rappresentando gli elementi di test dal meno complesso al più complesso

Gli elementi dello shema :

- Step : Sono delle funzioni di base integrate direttamente nel software che agiscono e collezionano delle misure sugli elementi della rete, ad esempio facendo riferimento a dei comandi AT.

- Test Precedure : È un modello di test che viene descritto sotto forma di diagramma composto di step. In essa sono presenti i parametri di ingresso e le misure di uscita che caratterizzano il servizio modellizzato.

- Test Design : È un test disegnato con uno scopo preciso in cui è possibile valorizzare alcuni parametri in ingresso. Esso può essere composto di uno o più Test Procedure.

- Schedulazione : È l’esecuzione del “Test Design”. Alla fine della schedulazione vengono estratte le misure definite a livello di “Test Procedure”

Le schedulazioni e lo studio dei risultati dei test si possono fare da qualunque computer dove è installato il cliente ANTS collegato al server centrale.

Esso è accessibile sia dal cliente che in questo modo può osservare i risultati di test, sia dal personale di ANTS che può effettuare delle verifiche sulle funzionalità del prodotto o aiutare il cliente a configurare il sistema.



Per realizzare ed installare un sistema di test attivo e di monitoring di telecomunicazioni di questo tipo sono state definite quattro fasi principali di produzione e rilascio:

- Produzione degli elementi hardware : In parte, il lavoro è realizzati da aziende subappaltate. La richiesta di una nuova macchina può venire da un cliente o internamente.

- Sviluppo dei software e test globali del sistema : Questo lavoro svolto all’interno dell’azienda ElsagDatamat, è il compito principale del gruppo di sviluppo e del gruppo della qualità.

- Installazione e deployment dal cliente : Il prodotto è orientato, come in tutta industria, verso il cliente (in questo caso gli operatori telefonici).

L’azienda è in contatto permanente con essi ed è sempre attenta alle loro esigenze grazie a dei “project manager” che collaborano direttamente con loro e quindi in qualche modo guidano l’evoluzione del prodotto.

I project manager sono inoltre responsabili di organizzare i rilasci del prodotto e i successivi “upgrade”.

- Definizione e configurazione delle “Test Procedure” : Fatte quasi sempre su richiesta del cliente, questo compito è in carico del gruppo “Professional Service”.

Poiché il sistema ANTS, evolve in continuità per poter rispondere alla domanda del mercato, il prodotto è in continua evoluzione e necessita dunque per il suo sviluppo dell’esecuzione di alcuni processi più o meno noti nell’ingegneria del software.

Questi processi fanno l’oggetto del framework.



2 Creazione del Framework di descrizione

2.1 La situazione prima dello stage

La produzione del software richiede di eseguire una serie di attività ordinate dentro

un processo e spesso ripetute ciclicamente. Il fatto che questi processi siano ben definiti, serve a rendere veloce e sistematica la produzione del software in modo da poter rispondere allo sviluppo delle tecnologie della rete mobile. I processi semplificano diverse azioni dei lavoratori in questo modo :

� Chiarificano per ogni compito quali sono i prodotti in input e quali in output, quali sono le tecniche e tool che devono essere usati.

� Che passi devono essere fatti per eseguire un compito.

Di fatto, quando una operazione (anche estremamente creativa come puo’ essere la scrittura di codice, o individuazione di una soluzione ad un problema complesso) è eseguita seguendo una metodologia ben definita e collaudata, con l’aiuto di una descrizione facilmente comprensibile, utilizzando gli strumenti e risorse adeguate, si risparmia molto tempo quindi (per l’azienda) molto denaro.

Fino ad oggi questi processi erano descritti da poche persone senza seguire un determinato standard (tipo di formato, accessibilità, etc …) e solo per necessità personale.

Quindi, quando si presentava una situazione in cui era necessario avere una visibilità delle procedure o quando era necessario insegnare un’attività ad un nuovo dipendente, le descrizioni disponibili dei processi non permettevano di rispondere alle necessità.

In generale (prima dello stage) le informazioni sui processi erano:

- Disperse : Queste descrizioni di processi erano sparse su diversi supporti a seconda della persona che l'ha scritta. (i.e. su carta, su supporto elettronico di vario tipo).

- Non omogenee : Ogni responsabile aveva descritto i suoi processi di gestione nel formato di file (Word, Excel, immagini, etc...) e sotto forma (Organigramma, albero, file Excel, etc...) dipendente dalla sua scelta.

- Incomplete : Ovviamente, non tutti processi erano stati descritti, pochissimi avevano una descrizione completa (solo quelli più importanti).



- Poco fruibili : Essendo su carta o sui computer personali, le informazioni erano accessibili a poche persone e l’acceso richiedeva troppo tempo.

È per fare fronte a questi problemi che il mio responsabile mi ha proposto questo stage.

2.2 L'iniziativa, come è stato creato il framework

L'obiettivo dello stage è stato quello di mettere fine a queste problematiche

estremamente negative (descritte nel 2.1) portando come valore aggiunto alla gestione della comunicazione la possibilità di :

- Eseguire e trasmettere i processi ai nuovi lavoratori : Ogni attività deve essere

descritta abbastanza chiaramente da potere essere compresa facilmente da un nuovo lavoratore, deve essere inoltre ritrovabile facilmente sul framework.

- Accelerare le azioni dei lavoratori : Quelle descritte nel primo paragrafo e nei processi.

- Migliorare i processi : Avendo una descrizione omogenea, i manager avranno una visibilità globale di tutti processi per poterli migliore.

Quindi è stato creato un sito interattivo, accessibile a tutti i lavoratori di ANTS,

descritto in modo omogeneo per rispondere alle necessità descritte nel 2.2. Il Framework è dunque collocato su una macchina Intranet insieme ad altri servizi

destinati ai dipendenti : Repository della documentazione, Vacation Planner, etc. Altre aziende hanno già creato una descrizione dei loro processi per uno scopo

simile al nostro. Ad esempio IBM ha creato il metodo IRUP (IBM Rational unified process) che descrive in modo standard la produzione di software distinguendo diverse fasi cicliche divise in discipline :



Ogni fase o disciplina viene descritta sotto forma di un processo comportando delle attività da svolgere ad un punto preciso del ciclo da cui entrano ed escono dei prodotti intermediari.

Ci siamo, quindi, basati su questo metodo già esistente e l’abbiamo adattato secondo l’organizzazione dei gruppi, i processi usati in ANTS e gli obiettivi del Framework.

Partendo da questa idea, ci siamo procurati una versione gratuita di EPF (Eclipse Processes Framework) che genera dei Framework di processo con una struttura predefinita.

Per realizzare il Framework è stato predefinito un calendario di lavoro all’inizio dello stage. Esso è stato programmato per periodi di un mese fissando degli obbiettivo specifici.

Segue una descrizione riassuntiva di questi obiettivi :

- Il primo mese : Imparare a usare i tool, sia quelli usati per creare il framework che quelli usati dai colleghi per lo sviluppo ed il test del prodotto.

- Il secondo mese : Eseguire e descrivere dei task semplici eseguiti principalmente della QA, seguendo un metodo standard. Studiare i concetti della QA come la classificazione ODC (vedere capitolo 6).

- Il terzo mese : Questo mese è interamente dedicato ai processi di Customer Support (Assistenza al cliente) la cui sede si trova a Padova ; in questo caso è stato necessario un lavoro di comunicazione che mi ha permesso anche, di con migliorare l’italiano aziendale.



- Il quarto mese : Continuando a completare le descrizioni di diversi task, il lavoro si orienta verso l’esecuzione di compiti d’ingegnere, quindi con un doppio significato : quello di praticare il lavoro d’ingegnere, e quello di capirne il senso nella struttura dei processi.

- Gli due ultimi mesi : I due ultimi mesi : il lavoro è stato sempre più orientato verso quello della QA. Dunque, per finire il tirocinio, ho visto in profondità il ruolo di ingegnere della qualità e sono riuscito ad essere operativo per l'inizio della mia assunzione.

Il metodo di lavoro appreso durante lo svolgimento dello stage si è basato su quattro punti essenziali :

- Prendere esempio dal metodo RUP per la descrizione di alcuni processi standard : Come qualunque lavoro d’ingegnere, la prima cosa da fare è prendere quello che è stato già fatto, per guadagnare tempo ed avere un esempio di un lavoro efficiente, l’organizzazione dei processi è stata tracciata su quella del RUP, e la descrizione di alcuni task standard quasi copiati.

- Riunire, correggere, migliorare le descrizione di processi già presenti : Come detto prima, molti processi erano stati già descritti dai loro responsabili. Dunque quando un processo o una base di processo è esistente, il lavoro è quello di capirlo ed adattarlo secondo la standardizzazione scelta per il Framework.

- Intervistare e raccogliere informazioni per descrivere processi seguiti ma non formalizzati : Questo stage è anche un’occasione di capire meglio la comunicazione aziendale, per migliorare la lingua italiana, nei suoi diversi modi di comunicazione, e permettere anche di capire il ruolo di ogni gruppo, di chi ne è responsabile o chi ci lavora.

- Ri-eseguire i processi : Un volta riunite tutte le informazioni, occorre riprodurre i processi sia per capirli a fondo che per controllare che non ci siano errori. Questa attività serve anche a dettagliare gli step per meglio descriverli (ad esempio prendere degli screenshot, etc).



Come accennato prima, il Framework deve essere sviluppato seguendo certi criteri di omogeneità e di standardizzazione, questi sono stati, in parte fissati prima dell’inizio, in parte migliorati e rivisti durante la costruzione del Framework stesso.

Questi criteri sono i seguenti :

- Formattazione e struttura (principalmente fissato da EPF) : In quello che riguarda la forma, la maggiore parte dei criteri è fissata dal tool stesso EPF, esso obbliga il realizzatore a seguire una struttura di descrizione predefinita, la struttura è quella usata anche nel metodo IRUP. (riferirsi alla struttura descritta nel capitolo successiva).

- Lingua inglese e forma del testo : A livello letterale, la lingua utilizzata è ovviamente l’inglese. (del resto molti dipendenti non conoscono l’italiano). Occorre inoltre rispettare alcune regole per la forma del testo in modo da rendere più chiara e più piacevole la lettura del framework. Queste regole sono, ad esempio, l’uso personale, la regolarità d’impostazione dei caratteri per dare più rilievo ai titoli, agli esempi etc…, convenzioni utilizzate nella scrittura. Anche se l’aspetto “forma del testo” non è l’argomento principale dello stage, per ragione di pubblicazioni, esso non può essere trascurato.

- Descrizione dei processi sotto forma di caso d’uso : Questa è la maggiore differenza rispetto alla descrizione fatta nel RUP ; nella descrizione dei processi di ANTS mettiamo un po’ a parte l’aspetto teorico o astratto per una descrizione molto vicina alla pratica. La principale ragione è quella di avere uno strumento davvero utile per tutti i lavoratori del gruppo ANTS. Per questo sarà usata una scrittura dettagliata vicina al tecnico : con dettagli delle operazioni da eseguire, screeshot, suggerimenti, esempi, etc….



3 Struttura del Framework In questo capitolo, saranno descritti gli elementi costituenti del Framework, la loro

utilità e come consultarli. L’organizzazione degli elementi è quella definita da EPF, niente di quello descritto in questo capitolo è stato concepito durante lo stage. Questo capitolo è scritto principalmente per mostrare i tool usati e dare un idea della struttura usata ed adottata.

Questa esposizione è accompagnata da qualche commento che illustra come è stata usata questa struttura per raggiungere gli obiettivi prefissati.

Il framework si presenta, come una pagina Web divisa in tre parti :

- Il menù delle principale discipline - Il menù della disciplina scelta, dove si può scegliere direttamente l'elemento

desiderato - La pagina di navigazione, dove sono descritti gli elementi scelti e dove si può

navigare con visibilità all’interno del processo.



3.1 Gli elementi del framework

Gli elementi usati e proposti da EPF sono quelli standard creati per il metodo RUP :

- Dal livello più alto : quelli che permettono di avere una visibilità sul processo - Al livello più basso : quelli che contengono informazioni dettagliate su come

eseguire i compiti. Per maggiore comprensione, la presentazione di questi elementi sarà divisa in due

paragrafi : Quelli di alto livello in un primo tempo ; e quelli di basso livello in un secondo tempo. 3.1.1 Elementi di alto livello

A questo livello si vede l’intero processo di una disciplina e in genere questo tipo di visibilità è utile a un manager ed alla comprensione di come una attività interagisce con le altre (Aspetto di visibilità).

Il framework è strutturato, in un primo luogo, in discipline (Test, sviluppo, customer support, etc...) che sono quelle in carico ai gruppi principali di ANTS

(vedere lo schema del 5.1).

Esso è composto da attività, ovvero un’insieme di compiti da eseguire che hanno uno scopo comune. Ogni attività si colloca in una fase precisa dello

svolgimento del processo.

Ogni processo è descritto sotto la forma di un diagramma di attività. Ad esempio quello del processo di test :



Questa struttura sotto forma di diagramma

presenta una buona leggibilità del processo ed un accesso veloce alla descrizione di ciascun task (per visualizzare tutti i task che compongono una attività basta un doppio click sull’icona della attività stessa).

In questo modo si aumenta la qualità del lavoro dei dipendenti, in termini di risparmio di tempo e ripetibilità delle vari operazioni (da parte dei tecnici), in termini di gestione dei processi (da parte dei manager).

Partendo con un approccio to-down la ricerca, all’interno di un processo di un determinato task da eseguire o da capire, è inoltre estremamente agevolata.

3.1.2 Elementi di basso livello

Ad un livello più basso (quando ad esempio si clicca su una determinata attività) viene data la descrizione in dettaglio dei compiti dando la possibilità di trovare un informazione precisa sul come eseguire un task, quali sono i vincoli fra essi, gli input, output, ect...

Mentre tra elementi di alto livello, quello più piccolo è l’attività cioè una fase delle

processo che ha uno scopo ben definito. Facendo “drill down” su una attività, viene esposta con più dettaglio l’aspetto più pratico e tecnico, arrivando ad una descrizione livello minuziosa di tutti gli input, gli output, gli step e i tool che vengono utilizzati per realizzare un determinato compito.

Dunque, le attività sono composte degli elementi seguenti :



Ogni attività è composta di un insieme da tasks

(compito) che sono presentati in questo modo : Al task sono associati : il ruolo responsabile, i

prodotti in input ed i prodotti in output.

Il ruolo è, descritto con quattro paragrafi

essenziali : − La descrizione − Le competenze − I tasks in cui è in carico di eseguirle − I documenti di cui è responsabile

Gli input e output (o workproducts) possono essere sotto diverse forme (Documentazione, software, codice, email, etc...) e sono gli elementi utilizzati,

prodotti o trasformati dal task. La pagina di descrizione del workproduct è, spesso, composta di una descrizione

generale e di un template che serve di esempio per capirlo meglio.

Al task, è anche spesso associata una guidance che può essere un metodo, concetto o modo d'uso, per aiutare ad eseguire il determinato task.

E finalmente, la pagina di descrizione del task contiene :

- Lo scopo : perché deve essere eseguita. - Una descrizione globale - Una descrizione “step by step” su come eseguirla, comprensibile da chiunque.

Essendo più completi e precisi questi elementi mettono a disponibilità dello staff i seguenti vantaggi (oggetto dello stage) :

- La possibilità di trovare in un punto unico qualunque informazione sui compiti dei dipendenti.

- Tutti i legami fra i ruoli, task, documenti e workproduct. - Una documentazione completa e chiara per apprendere, ad esempio, un nuovo task

non incontrato nel passato, come si relazionano i task tra loro e collaborano per l’implementazione dei processi.



3.2 Chiarezza di navigazione

Il framework permette una navigazione gerarchica di tutti questi elementi in un

modo estremamente comprensibile ed intuibile. Si offrono al personale diverse possibilità di navigazione, presentate in seguito, per trovare l’informazione ricercata, in modo agevole.

3.2.1 Il primo modo di navigazione (top down) è quello tramite il diagramma del

processo, che permette di avere una visibilità del processo e del posto dei tasks contenuti in esso.

3.2.2

Il secondo modo è quello direttamente tramite il menù della disciplina, che permette di accedere direttamente alla descrizione desiderata.



Menù sviluppato

3.2.3 Esempi di utilizzo del framework

Per concludere la presentazione della struttura del Framework, presentiamo degli

esempi concreti relativi alla sua utilità.

• Informazioni per l’inserimento di un nuovo lavoratore.

Quando un team leader ha bisogno di un nuovo lavoratore, sia all’interno che all’esterno dell’azienda, per eseguire un certo task ; ha bisogno di solo tre clic per far comparire l’insieme delle competenze richieste (queste competenze possono essere ovviamente aggiornate).

Una volta selezionata la risorsa che ha le competenze necessarie, per insegnarle bene e velocemente il suo compito, è sufficiente fare due clic per far comparire la descrizione completa dei task che deve eseguire.



• Chi è responsabile di un task, documento o prodotto ? Essendo i task che compongono un processo decine se non centinaia, spesso è

possibile anche per tecnici esperti che ci siano incomprensioni su chi ha la responsabilità di eseguire determinati compiti. Sempre con soli tre clic si può accedere all’insieme delle informazioni di ciascun processo, comprendere a fondo la descrizione di un processo e le sue attività, e risalire facilmente al ruolo responsabile di ciascun task per contattarlo.

• Che prodotti devono essere presenti prima di eseguire un task ?

Prima di mettere in funzione i meccanismi e di riunire il personale necessario ad un determinato compito, la persona responsabile del task prende conoscenza dei prodotti d’input comprese le loro descrizioni.

• Dove si trova il mio compito nel processo ? A che serviranno i prodotti del mio task ?

Ad esempio per potere scrivere bene un documento output di un determinato task,

spesso serve pensarlo anche come input del task successivo. Quindi è sufficiente andare su la pagina di descrizione del prodotto da cui ci sono i link dei task che lo useranno come input.

*

Per concludere, possiamo dire che abbiamo usufruito di una struttura già disponibile e concepita per uno scopo vicinissimo al nostro, e che l’abbiamo adattata secondo il nostro prodotto ed i nostri scopi, ottenendo un framework che risponde perfettamente agli scopi prefissati.

Nei prossimi capitoli entreremo più in dettaglio nei processi descritti nel framework.



4 Struttura delle release

Per capire a fondo i processi descritti nel framework è fondamentale chiarire il perché della esistenza di tali processi e quale è il loro obiettivo ultimo.

In realtà ogni processo è disegnato per produrre una nuova release del prodotto cioè un rilascio, per installare la nuova release presso il cliente e successivamente gestirla .

Ogni nuovo rilascio è composto da diverse features (caratteristiche) :

4.1 Feature

Una feature è una funzionalità del prodotto richiesta dal cliente o dal gruppo di marketing del prodotto. Quindi la programmazione del lavoro per la realizzazione di una nuova versione è concepita in features. 4.1.1 Esempi di features :

In questo paragrafo espongo in breve tre features che sono state implementate nel prodotto. Ho scelto arbitrariamente tre tipi di features di diversi ordini.

HTTPS : Una connessione HTTPS è usata per avere una trasmissione sicura di dati

tramite un cryptage. In ANTS, questa feature è stata sviluppata per la comunicazione WAP ; quindi sono stati implementati delle step per : la HTTPS redirection, il SSL Tunneling e il SSL Handshake.

IREG : Questa feature è relativa alla generazione di un tipo di rapporto

standardizzato richiesto dagli operatori. Quindi sono introdotte delle funzioni che permettono di estrarre delle misure specifiche,e poi di generare un rapporto in un formato standard.

Re-execution test : Questa feature, invece, semplifica la gestione dei test. Permette

semplicemente, in un primo tempo di fare comparire l’insieme dei test responsabili di un allarme e, in un secondo tempo, di ri-eseguire, con un singolo clic, i test o uno dei test con la stessa configurazione di quello che ha generato l’allarme.

Si vede da questi semplici esempi che le feature scelte per l’implementazione possono essere di tutti tipi ; step per le nuove tecnologie di telecomunicazioni, standardizzazione, semplificazione d’uso, chiarezza di visibilità, etc …



Alcune feature sono sviluppate per seguire lo sviluppo delle tecnologie in modo di essere proposte a tutti clienti ; altre, soltanto per un cliente su sua richiesta ; altre possono anche essere implementate per semplificare la vita al personale di ANTS, ad esempio : un monitoring per la vedere l’insieme dei test eseguiti da tutti clienti (usato principalmente dal Customer Support).

4.1.2 I documenti descrittivi di una feature.

Una volta che è stato deciso di sviluppare una feature, vengono prodotti dallo sviluppo, a partire dei requisiti descritti dai Project Manager a contatto con il cliente e il marketing, tre documenti che saranno usati come base per il resto dell’implementazione.

In questi documenti sono specificati in modo strutturato e dettagliato i requisiti da

raggiungere per validare la nuova feature :

• Architecture Design Specifications : In questo documento sono descritti gli impatti sulla struttura del sistema: Database

(nuove tabelle o nuove linee), Programma (Nuovi oggetti), Nuovi servizi, Interfaccia utente (Ad esempio nuove tab).

• Software Requirements Specifications : In questo documento sono descritti i requisiti della feature, in un primo tempo

l’obiettivo e lo scopo dell’implementazione. Poi, la feature è divisa in requisiti che fanno ciascuno l’oggetto di un paragrafo dove è descritto quello che deve fare la funzione e il futuro comportamento del sistema. I requisiti spesso sono descritti sotto forma di casi d’uso. Questo documento sarà usato sia dallo sviluppo, per implementare la feature, che dalla QA per testarla.

• Software Test : L’insieme dei test che deve effettuare lo sviluppo per convalidare

l’implementazione. Questi test riguardano, a parte la verifica dei requisiti, dei controlli a livello del sistema (database, memoria, funzionamento del programma) e test di unità.



4.2 Livelli di release & elementi della build

La release è quindi strutturata in livelli secondo l’importanza delle feature

implementate. Il numero identificativo di una versione del software è sotto questa forma : X1.X2.Y.Z.x ad esempio 5.3.1.0.11

Quindi essa è strutturata in cinque livelli :

- Numero della Major Release (X1.X2) (Esce circa ogni 12-18 mesi) Una nuova Major Release è avviata quando vengono introdotte delle nuove caratteristiche (features) importanti in genere cambiamenti a livello del Hardware : Nuovo schema del ambiente del sistema, nuove periferiche introdotte, etc. ; o a livello del software (ad esempio : la presentazione grafica, la struttura delle tabs, etc.).

- Numero Service Pack (Y) (Esce circa ogni 4-6 mesi) Una nuova Service Pack è avviata quando delle nuove caratteristiche importanti sono introdotte però solo a livello di software e che non cambiano radicalmente il modo di utilizzo del prodotto da parte del cliente, Questi enhancements non devono presentare rischi o stravolgere una caratteristica intera.

- Numero Patch (Z) (Esce quando è necessario) Una nuova Patch è avviata all'introduzione di piccoli enhancements, ma è avviata sopratutto per risolvere in emergenza dei defects rilevati dai clienti. I cambiamenti dovuti ad una nuova Patch riguardano soltanto alcune componenti del software. A priori, all'avvio di un Service Pack o Main Release, non si sa quante Patch seguiranno ; dipende dal numero e dall'importanza dei problemi rilevati ; può anche capitare che nessuna Patch sia realizzata per certe versioni.

- Numero Cicle Test (x) (Esce ogni settimana) Questo numero è incrementato ogni volta che esce una Build (tipicamente ogni settimana). Una build è la rigenerazione del software eseguibile a partire del codice sorgente aggiornato quotidianamente dallo sviluppo. Questo indice non appare nella copia venduta al cliente, è soltanto il numero di cicli che sono serviti per produrre una versione (X1.X2.Y.Z).



Visto la complessità del sistema ANTS e la diversità di HW e sistemi operativi, l’output di una build è composto da diversi moduli, principalmente degli InstallShield (programmi eseguibili che installano il software sulla macchina) o degli script (dei comandi per creare la struttura del database) :

- Installshield del server OS : Installa diversi elementi sul server come i servizi che

ci girano e che hanno diverse funzionalità (connessione con le periferiche, schedulazioni dei test, gestione delle risorse, gestione delle allarme, generazione di rapport, etc.). L’installShield configura anche il website da cui un utente si collega al sistema, e aggiorna anche dei chiavi di registri e delle cartelle sul disco dove sono copiati dei file necessari per il sistema e dove saranno salvati i file di tracciamento. A questa installshield è anche integrato quello del Client (Interfaccia grafica installata sul PC dell0’utente) che verrà scaricato dal server.

- Script del Database : Esistono due tipi di script : Script di creazione e di

migrazione del database. Quelli di creazione creano le tabelle e ci inseriscono i valori di base per fare girare il sistema. Quelli di migrazione trasformano il database di una certa versione di un database in un'altra ; la migrazione deve adattare il database ad una versione più recente ma senza perdere i dati essenziali per l’utente.

- RTUPC : Installshield delle periferiche RTU installate su un PC. Come per l’OS,

le componente sono dei task che hanno ciascuno la loro funzionalità come collegarsi al server, eseguire le comunicazioni, ….

- RRS : Installshield delle periferiche RRS. Stessa cosa che per le RTUPC



5 I processi descritti & i diversi ambienti

Adesso entriamo di più in dettaglio nella costituzione del Framework. L’obiettivo di questo capitolo è di fare un’introduzione sui principali processi descritti durante lo stage :

- Sviluppo - Change Management - Customer Support - Quality Assurance Vedremo che abbiamo usato due diversi metodi di descrizione : - Processo ciclico : Cioè un processo ripetuto ad ogni release e che contiene delle

fasi iterative ; è il concetto usato nel metodo RUP da cui ci siamo inspirati. - Processo di evento : Questi tipo di processo, invece si svolge dopo un evento ; un

po’ come una iterazione in informatica. Questo tipo di descrizione corrisponde, ad esempio, all’arrivo di una richiesta di un cliente dove un processo diverso può essere seguito a secondo del tipo di evento.

Questa evoluzione rispetto ai processi descritti da IBM, che usa solo dei processi

ciclici, è spiegata dal fatto che prendiamo in considerazione l’aspetto concreto d’uso oltre a quello che descrive un processo generale. Infatti, i processi ad evento sono delle procedure da seguire in un caso determinato.

5.1 I diversi ambienti

All’interno dell’ambiente di lavoro, i processi ed attività sono collegati

(comunicano) tramite i workproduct. Ciascuno interviene sulla produzione avendo la sua responsabilità e le sue competenze.

Per avere una visione globale, è descritto nell’ambiente di lavoro sotto forma di flussi di produzione (assomigliati ai WorkProduct), gestiti dai gruppi di lavoro (che eseguono i processi).



Schema semplificato dei vincoli fra le discipline

Su questo schema sono illustrati sotto forma di flussi (Quello delle “New Features” e quello dei “Defects”) in modo semplificato i legami fra le diverse discipline.



Ovviamente questo schema non descrive tutte le interazioni che avvengono nel gruppo ANTS, ma solo alcuni principali meccanismi :

- New Features : Definire, secondo le necessità dei clienti, quale sono le funzionalità da aggiungere alle prossime versioni del prodotto.

- Change Request : Risolvere i difetti trovati sia dal campo che dall'ambiente interno di test.

- Solution & Configuration : Sistemare il prodotto installato dal cliente secondo le sue necessità e le funzionalità che l’interessano.

5.2 Processo dello sviluppo

Lo sviluppo è il gruppo responsabile dell’implementazione delle nuove feature e

della risoluzione dei defect a livello del codice. 5.2.1 I requisiti Nel processo, la prima attività è di scrivere i requisiti d’implementazione a partire da

quelli del Product Manager (il documento di software requirement), questo si basa sulla compilazione di due documenti :

• Architecture Design Specifications : In questo documento sono descritti gli impatti sulla struttura del sistema: Database

(nuove tabelle o nuove linee), Programma (Nuovi oggetti), Nuovi servizi, Interfaccia utente (Ad esempio nuove tab).

• Software Test : L’insieme dei test che deve effettuare lo sviluppo per convalidare

l’implementazione.



5.2.2 Il processo

Il processo di sviluppo è di tipo ciclico e

molto legato a quello della QA : La QA testa le feature implementate dallo sviluppo e lo sviluppo corregge i defect dichiarati dalla QA…

Fino ad oggi, siamo arrivati ad una

descrizione dei processi di sviluppo non definitiva inspirata dal processo ciclico classico ; lo sviluppo è descritto nel RUP in due parti : Analysis&Design e Implementation. In ANTS sono stati formalizzati i processi di implementazione ed una piccola parte del design cioè la definizione dell’implementazione.

Processo di sviluppo

L’implementazione delle feature di una release, si svolge in due fasi principali :

• Inizialmente, una volta che i requisiti sono stati definiti, la feature è codificata fine a che sono completati i “software test”. Quando questi sono finiti, si dichiara la “Feature Completed” della release.

• Successivamente, ogni feature inizia ad essere testata dalla QA ; a questo punto, lo sviluppo dovrà correggere i defect rilevati ed introdurre dei piccoli enhancement di usabilità.



5.3 Processo del Customer support

Il Customer Support (CS) tratta, insieme ai Project Manager le richieste dei clienti

(dichiarazione di bug o richiesta di miglioramento). Globalmente, il compito è di analizzare le richieste del cliente, come esito si può avere una risposta diretta del CS (Nel caso in cui la conosce), oppure un indirizzamento della richiesta verso un altro gruppo che può essere : Quality Assurance, Professional Service, Hardware management.

Questo processo, un po’ particolare rispetto agli altri descrive le attività del customer

support usando un formato di processo ad evento invece che un processo a ciclo come descritto nell’introduzione di questo capitolo.

5.3.1 Tipo di request e processi

Il flusso di attività seguito dipende fondamentalmente dal tipo di richiesta.



Quando il CS riceve una richiesta (via email, telefono, applicazione web, …), essa

viene prima analizzata e, se non è rifiutata (i.e. ad esempio il contratto di supporto è scaduto), è orientata verso uno di questi processi :

- Software Defect : Quando si presuppone che il problema venga dal software quindi

dal codice la cui risoluzione è in carico allo sviluppo. (La riproduzione del Defect in un ambiente controllato è però in carico alla QA).

- Hardware Defect : Quando si presuppone che il problema venga da un elemento hardware, fornito dalle aziende subappaltate .

- Information Request : Una semplice richiesta del cliente (in genere relativa ad una configurazione del sistema) che necessita soltanto un informazione o una descrizione dettagliata di passi da eseguire.

- Assistance Request : Quando la richiesta del cliente chiede una configurazione particolare e complessa, ad esempio la creazione di una nuova TP.

- Enhancement Request : Quando il cliente chiede un miglioramento del prodotto e quindi riguarda il software.

- Hardware Request : Quando la richiesta del cliente necessita l’installazione di una nuova componente hardware.

5.3.2 Ticket life cycle

Il workproduct su cui lavora principalmente il customer support è il ticket ovvero il file di tracciamento di una richiesta di un cliente. Esso viene aperto alla richiesta del cliente e chiuso alla risoluzione del problema.

Esso segue un ciclo che varia secondo il tipo di richiesta .



Ciclo del ticket

Il ticket viene scalato in certi casi verso altri gruppi in modo da raccogliere le informazioni necessarie alla risoluzione del caso. Una volta che la richiesta è risolta : Enhancement o defect trasmesso alla QA, problema risolto dal cliente, informazione trasmessa al cliente, etc ; il ticket è chiuso ed archiviato.

5.3.3 Tipi di soluzioni

La finalità del customer support è ovviamente quella di fornire una soluzione al cliente. Nel caso di defect od enhancement, tre tipi di soluzioni sono possibili :

- Release & ServicePack :

In caso di un defect non bloccante o di enhancement non urgente o di una feature da sviluppare, normalmente si decide di introdurre la modifica nella release successiva. In questo caso, il problema rimane sulla versione installata presso il cliente e si dovrà aspettare la prossima release per problema risolvere il caso. Spesso, per aggirare il problema, una soluzione di workaround (descritta in seguito) è fornita al cliente



- Hot-Fix & Patch : Questo tipo di soluzione permette di rispondere in un modo veloce ad una richiesta di un cliente se si tratta di un caso d’emergenza. La risoluzione in questo caso viene fornita fuori dalle date fissate per i rilasci, le due alternative sono : - Hot-fix : Effettuata nella maggiore parte delle volte nel caso di un defect bloccante, la hot-fix è in genere installata “a caldo” richiedendo la sostituzione solamente di qualche file. - Patch : nel caso di una soluzione un po’ più complessa che richiede la sostituzione di un intero modulo software, serve la rigenerazione di una build e la ri-installazione del prodotto. In questo caso si crea una nuova versione in cui sarà incrementato l’ultima cifra dell’indice della release (ed esempio : 5.4.1.0 � 5.4.1.1) e che avrà i sui requisiti descritti in un release notes. Spesso, una patch può riguardare soltanto un cliente.

- WorkAround : Un workaround è una soluzione provvisoria per aggirare un difetto senza apportare modifiche al codice e all’installato. Una soluzione di workaround è sempre fornita al cliente, quando è possibile. Ad esempio, uso di un interfaccia diversa, rinomina di una cartella, etc.

5.4 Processo di Change Management

Questa disciplina ha il compito di controllare i cambiamenti e mantenere l’integrità

del prodotto. Questo lavoro si fa in appoggio su diversi workset che contengono il lavoro fatto per ogni versione.

La disciplina sarà illustrata in questo sottocapitolo presentando le attività seguenti : - Estrazione della build - Gestione dei workset - Gestione delle richieste



5.4.1 Overview del processo Il processo di Change Management è anch’esso ciclico (vedere 5.6 per più

informazioni). Esso è composto di un’attività “Manage Change Request” (Gestione delle richieste) che avviene durante l’esecuzione di tutte le altre attività.

Queste ultime sono le attività di pianificazione delle procedure di controllo di configurazione e di cambiamento (possono essere aggiornate o modificate con l’evoluzione del prodotto) che sono seguite dall’attività di creazione degli ambienti di progetto. La gestione dei workset, che sarà descritto, nel paragrafo 5.4.3, è forse è il più importante dei compiti relativi a questa attività.

Si tratta di creare uno “spazio” sui cui gli sviluppatori possono lavorare ad una stessa versione del software contemporaneamente.

Infine seguono le attività ripetute più frequentemente : (ad ogni build) ; che comprendono,fra altro, l’estrazione della build, da cui il prodotto in output (i pacchetti di installazione) sono il prodotto principale in input al processo di test.



5.4.2 Estrazione della build Il processo di build prevede l’estrazione, tramite uno strumento di controllo di

configurazione del codice sorgente, di tutti i file relativi ai moduli ANTS della versione che deve essere rilasciata..

Dopo che sono stati selezionati i file opportuni, essi vengono salvati sotto forma di baseline e compilati tramite gli script di build.

Schema del task di estrazione di build

Una baseline è una “foto” del workset in un momento preciso dell’implementazione.

Alla creazione di essa, l’integrator deve garantire che il workset sia correttamente aggiornato con tutti i file che sono stati cambiati dagli sviluppatori.

L’estrazione dei file dalla baseline, si fa sia in modo completo (tutti i file vengono estratti, ma questa procedura richiede molto tempo), sia in modo “delta” (vengono estratti solo i file che sono stati cambiati rispetto alla build precedente).

5.4.3 Gestione dei workset Tutti i file che costituiscono i progetti sono inseriti dagli sviluppatori su diversi

workset secondo le versioni corrispondenti. Il principale compito dell’integrator è di gestirli tramite dei task quali : creazione di workset a partire dalla baseline, integrazione del workset, confronto dell’evoluzione dei workset.



Schema di gestione di workset

Su questo schema sono illustrati tre dei compiti del Integrator :

- Creazione di workset a partire dalla baseline : Al fine di anticipare il lavoro degli sviluppatori, il workset sul quale verranno caricati i file della versione successiva (sull’esempio : 1.2.0.0) è creato facendo l’import dei file dell’ultima baseline disponibile.

- Confronti dell’evoluzione dei workset : Successivamente alla creazione di un nuovo workset, diversi defect devono essere ancora risolti sulla 1.1.0.0 ; questi, devono essere assolutamente riportati sul nuovo workset (1.2.0.0). Per diverse build, un confronto è fatto dall’integrator per controllare che i defect siano stati risolti in entrambi i workset. Questo task è eseguito confrontando l’ultima baseline di ciascun workset a quella precedente.

- Integrazione di workset : Su questo esempio, si sviluppa una patch 1.1.0.1 per risolvere alcuni defect minori rimanenti nella 1.1.0.0. Quando è stata dichiarata la GA della patch, le evoluzioni effettuate in essa devono essere integrate nel workset della nuova versione (1.2.0.0). In questo task delicato, l’integrator deve sostituire nella 1.2.0.0 i file corretti senza danneggiare le sue nuove feature.

Concludiamo questo paragrafo facendo una transizione verso il capitolo successivo ed osservando che la convalidazione ed il miglioramento di una release dalla parte della QA si svolge dalla FC della release alla “General Available” (GA). La GA è la dichiarazione di una versione rilasciabile al cliente, il processo di test è descritto nel capitolo 6.



5.5 Processo di test

Il processo di test è quello che è eseguito principalmente dal team di Quality

Assurance, il cui obiettivo è anche quello di valutare la qualità del prodotto tramite test opportuni. I vari compiti di questo gruppo di lavoro (nel quale ho effettuato lo stage) saranno esposti nel capitolo successivo, i principali sono :

� Esecuzioni di vari tipi di test, classificazione delle richieste di cambiamento per il

controllo della qualità, i tool usati, validazione della documentazione di prodotto,

automatizzazione dei processi di test.

Approfittiamo di questo ultimo paragrafo sui processi per concludere sulla struttura di un processo di tipo ciclico (come per i processi di sviluppo e Change Management visti prima) prendendo esempio su quello di test. Può essere scomposta in quattro parti :

- Pianificazione, concezione e definizione : Prima tappa nel processo che permette di stabilire come saranno eseguiti i controlli ed il ramo iterativo.

- Controllo e verifica dei processi : Quasi sempre presente, è un attività eseguita in “parallelo” alle altre attività che permette di controllare o di “portarci delle modifiche.

- Esecuzione o ramo principale : la maggiore parte del tempo iterativo

- Autorizzazione o convalidazione : opzionale, serve ad esempio per convalidare il rilascio di un workproduct.



il processo ciclico prende questa forma :

Ad esempio, per il processo di test :



5.6 Altri processi da descrivere

Prima di passare all’ultimo capitolo della tesi che esporre il lavoro della Quality

Assurance, presentiamo tre processi fondamentali per ANTS ma che non è stato introdotto nel framework per mancanza di tempo ; saranno però descritti nei mesi successivi (fuori stage).

5.6.1 Il deployment

Principalmente in carico ai Project Manager lavorando presso i clienti ; questo processo comprende tutte le attività che permettono di mettere in piedi e gestire il sistema al campo. Questo processo è di tipo ciclico.

5.6.2 Il processo di documentazione

È l’insieme delle attività che producono i documenti essenziali per ANTS :

- Installation Manual : Una guida per gli amministratori del server ANTS, del sistema ANTS e altro staff tecnico. Il manuale descrive le configurazioni, i prerequisiti hardware e software, procedure di installazione delle varie componenti e operazioni di amministrazione, manutenzione e troubleshooting del sistema.

- User Manual : Una guida per gli utenti ANTS, come amministratori, test designer, test supervisor, etc. Il manuale descrive come utilizzare le feature di ANTS grazie alla spiegazione delle interfacce e di pratici use case.

- Release Note : Una guida che contiene tutto ciò che è nuovo in ogni release. Contiene anche i difetti corretti, i known bug e i workaround.

- Referance Handbook: Una guida per utenti e tecnici che contiene una raccolta delle informazioni più importanti di ANTS.

5.6.3 Il processo di Product Management

È il processo eseguito dal team responsabile del prodotto ANTS. Praticamente, tutte le attività che portano alle decisioni maggiori per il prodotto (accordi con i clienti, introduzione di feature importante, decisione delle deadline, etc.).



6 Quality Assurance

Con questo sesto capitolo inizia la seconda parte della tesi, dove saranno esposte le attività relative al Quality Assurance ; gruppo in cui ho lavorato.

Vengono con descritte le tecniche apprese che userò dopo la fine dello stage.

6.1 Test (tipologia di test, QA)

La caratteristica dei test della qualità rispetto a quelli dello sviluppo, discussi nel paragrafo 4.2.2, è di testare le feature senza avere accesso al codice sorgente (black box testing). Le funzionalità testate sono verificate come verranno utilizzate dal cliente e sono divise in quattro categorie :

− BVT (Basic Validation Test) : Ogni volta che è rilasciata una nuova build, la nuova versione è installata su l’ambiente di test della QA. Il primo test da effettuare è quindi di verificare che le funzionalità di base girino correttamente. L’obiettivo è quello di verificare che non ci siano regressioni rispetto alla build precedente. Quando si avvia una nuova major release, si definisce l’insieme dei test del BVT che contiene le “test procedure” convalidanti tutte le componenti considerate “fondamentali ” per il sistema. * L’installazione deve essere interamente convalidata altrimenti la build viene dichiarata invalida e deve essere dopo le opportune correzioni rigenerata. * Un punto importante del BVT è che tutti gli step (descritti nel 1.2.2,) devono essere ri-eseguiti. Infatti, come descritto nel 1.2.2, gli step sono gli elementi di base che eseguono le operazioni comunicazione sulle periferiche e che estraggano le misure dalla rete ; una misura errata sarebbe inaccettabile !! * E’ importante anche che diversi tipi periferiche siano utilizzati : Tutti i tipi di porte (GSM/GPRS, UMTS, etc…), tutti tipi di SIM (italiane, straniere, pre-pagate, etc …) e tutti tipi di rete (2G, 3G, linee fisse, etc…). * Vengono poi ri-testate le interfacce principali e altre funzionalità ritenute fondamentali.



Il BVT si svolge dunque in tre parti : 1) Preparazione dell’ambiente ovvero controllo della sua installazione In questa tappa si re-installano tutte le componenti del sistema, per due scopi : controllare che l’installazione di una piattaforma ANTS vada bene, eseguire tutti i test successivi sull’ambiente rinnovato. 2) Esecuzione degli scenari In questa tappa vengono processate diverse “Test procedure” da cui l’insieme permette di convalidare le funzionalità di tutti gli step e i componenti base del sistema. 3) Test straordinari Alcuni test molto più pesanti e lunghi da eseguire, non possono essere fatti ad ogni build, quindi vengono effettuati alcune volte durante l’implementazione ; ad esempio due volte : una all’inizio ed uno alla fine del lavoro su una release. Ad esempio, questo è il caso dei test TTV (Toll Ticketing Verification), una funzionalità che controlla i CDR (Call Details Record) proveniente dalla rete. Verificare questa funzionalità necessita una grande preparazione ed un ambiente particolare (Emulazione di CDR, manipolazioni dirette sul database, etc.), e quindi non può essere eseguito ciclicamente in un modo semplice come gli altri test.

− CVT (Component and Verification test) & SVT (Scenario Verification Test) : Questi test sono quelli effettuati per convalidare l’implementazione delle nuove feature ; assomigliano molto a quelli fatti dallo sviluppo (descritti nel documento “Software Test”) a differenza che riguardano soltanto l’aspetto utente (cioè di alto livello). Mentre i test di CVT tendono a verificare nel dettaglio una singola funzionalità o interfaccia, quelli di SVT, si focalizzano su casi d’uso reale di utilizzo del sistema.

− Non-regression test : I test di “Non-regression” sono l’insieme dei test di una feature già effettuati su una versione anteriore, che devono essere ri-eseguiti sulla versione corrente. Ovviamente, non tutte le vecchie feature vengono ri-testate (perché sarebbe troppo costoso), ma solo quelle per cui è stato valutato che l’implementazione di nuove feature possa averle alterate.



− Test BETA : Il test BETA riguarda in genere soltanto una major release (versione della forma X1.X2.0.0.x), perché è quella che contiene i cambiamenti i più importanti all’architettura, e quindi è suscettibile ad un’alta possibilità di errori al momento dell’installazione sull’ambiente di produzione di un cliente. Si installa, quindi, su ambiente di pre-produzione presso il cliente una nuova versione, e si effettuano anche con la collaborazione del cliente stesso, dei test di base di tutte le feature (Quelle di non-regression come quelle nuove).

− Test di performance & scalability : Un altro tipo di test, per approfondire la valutazione del prodotto, sono i test di performance. Questi servono a valutare la capacità del prodotto di eseguire i compiti per cui è stato pensato risorse con la massima efficienza possibile. Per maggiore chiarezza, andiamo, in questo paragrafo, a sviluppare meglio come sono eseguiti questi, come sono analizzati i risultati e qual è la loro utilità. Ci focalizzeremo ora su alcuni aspetti di performance, quelli a cui tipicamente si è più sensibili in ANTS :

• Test di velocità – Paragoni fra le versioni

Questo test ha lo scopo di misurare la fluidità quindi la velocità di esecuzione dei task del software.

La valutazione avviene come paragone fra diverse versioni del prodotto per una funzionalità che ha le stesse caratteristiche tra una versione e l'altra. Se si presentano delle valutazione scostamenti negativi, è necessario capire da che cosa è dovuto il presunto rallentamento.

I rallentamenti di esecuzione possono essere dovuti a diversi casi, ad esempio :

− Query (carico di dati sul database)

In ANTS alcuni task del prodotto caricano una grande quantità di dati sul database.

Questo processo deve avvenire in modo efficiente.



Possibili soluzioni per rimediare a questo problema sono :

- Creazione di un secondo database dove sono copiate e ri-organizzate alcune tabelle, in modo da effettuare meno richieste sul database principale

- Pulizia, compattazione del database : ricerca, cancellazione, compattazione di dati che sovraccaricano il DB (dati non usati dal sistema)

- Per i dati trasmessi sul Client ANTS installato sul PC locale una soluzione puo’ essere la compressione o archiviazione di dati ridondati in locale.

− Il software stesso (ad esempio, iterazioni troppo pesanti)

Può essere anche il software stesso responsabile di una esecuzione lenta. Tipicamente si tratta di ricercare le iterazioni inutilmente troppo pesanti o di ripensare proprio le funzione troppo lunghe da eseguire.



− Utilizzo della bandwidth in modo poco efficiente (caso che riguarda sopratutto le reti lente)

Nel processo di test normale, il sistema è analizzato e validato sulla rete dell'azienda, una rete di buona qualità quindi veloce. In questo modo è raramente rilevata una feature che usa troppe risorse di rete. In questo modo esiste un alto rischio che il prodotto sia installato con gravi problemi qualora il sistema agisca in presenza di una rete lenta. (Caso tipico, dato che le periferiche RTUPC, sono generalmente dispiegate su tutto il territorio su cui opera l’operatore e collegate al server centrale tramite rete internet).

Per diminuire la probabilità che questo rischio si verifichi, vengono effettuate delle misure nel modo seguente (paragrafo successivo) :

• Test di uso della banda passante – Paragoni fra le versioni

In questo tipo di test si misura la quantità di dati scambiati sulla rete.

Installando un software di osservazione della rete sulla macchina dov'è installato una componente del sistema, si può fare un analisi sia quantitativa che temporale. Ad esempio per il Client.

− Analisi temporale : Il migliore modo di avere una buona visibilità è di rilevare un cronogramma delle attività del Client sulla rete :

Queste misure si fanno installando un software apposito sul PC dove è installato il Client.



Osserviamo nell’esempio della figura sopra tre tipi di comunicazione Ethernet :

* Una, al lancio del Client * Una, al login * Una, ciclica per controllare la connessione fra il Client e il Server

Da questa analisi si fanno delle conclusioni su come e dove migliorare gli scambi di dati fra il Client ed il server.

− Analisi comparativa : Una volta integrate le modifiche degli sviluppatori, si fa un analisi comparativa fra le due versioni (quella di prima delle modifiche e quella dopo), per constatarne i miglioramenti. Un’analisi comparativa si può anche fare fra due versioni, disponibili per il cliente, per valutare quale è quella con le migliore performance.

Ad esempio, in questo caso, constatiamo che nella seconda versione nessuno dato è scambiato prima del login

Oltre alle analisi sul lancio del Client, altri tipi di test di performance possono essere effettuati sul feature diversi. Queste analisi permettono sia di rilevare alcuni difetti non visibile facendo gli altri test di QA, sia di capire come migliorare le performance riducendo il traffico di rete, ad esempio :

- Copiando delle tabelle in locale al PC client dove vengono aggiornate quando è necessario, questo per evitare di trasmettere ripetutamente le stesse informazioni sulla rete.



- Introdurre un parametro di periodo di “refresh”, in modo di adattare l’intervallo di richiesta dei dati al server e l’aggiornamento dell’interfaccia a secondo della qualità della rete.

• Emulazione di reti

Un altro tipo di test più approfondito, è quello di analizzare il comportamento del sistema secondo la qualità della rete in cui è installato.

Questa analisi si presenta sotto forma di paragoni della stessa versione del prodotto al variare di diverse qualità di rete.

Una rete con dei disturbi virtuali è emulata grazie ad una macchina dove è installato un software appropriato (nel nostro caso : “Network Impairement Emulator Tool”).

Esempio : Valutare se è meglio usare il Client in locale o in remoto sulla macchina del server secondo la qualità di rete.

Per realizzare questo test sono stati messi in piedi due ambienti di test :

In tutti e due i casi, l’emulatore di rete si trova tra il PC dell’utente e il server. Nella prima configurazione il Client ANTS è installato sul PC utente, mentre nella seconda configurazione il Client ANTS è installato sul server e l’interfaccia è remotizzata tramite un tool di terze parti (CITRIX), l’idea è di capire, a secondo delle condizioni di rete, che configurazione del Client è meglio suggerire all’utente del sistema.

Per fare variare la qualità della rete, si gioca con questi tre parametri : Band Width,

latency e packet loss.



Con questa simulazione è stato concluso che a partire da certo livello di disturbo della rete (Band Width=256 Kb/s e latency=25ms), verrà raccomandato di installare il Client ANTS sul server e virtualizzarlo tramite un tool apposito chiamato CITRIX sul PC dell’utente.

Nel concetto più generale, i risultati dei test di performance vengono utilizzati nel modo seguente :

Dal manager dello sviluppo, per decidere di migliorare le funzionalità che rallentano il sistema.

Dal project manager, per dare raccomandazioni al cliente ed optare per un installazione più efficiente.

6.2 Classificazione ODC

La classificazione ODC è un concetto molto importante per il gruppo della qualità, è

la teoria che permette un classificazione chiara dei problemi rilevati sul prodotto e delle richieste di miglioramento. Questa teoria permette anche di condividere fra i lavoratori dei diversi gruppi le informazioni sui problemi e gli eventuali rimedi.

Quando un defect è rilevato, esso viene trattato e risolto da più persone, bisogna allora avere un modo di comunicazione chiaro e standard :

− Il tipo di defect − Quando è stato creato − Come è stato creato − Dove è stato creato − Che ha rilevato il defect − Come è stato rilevato − Il modulo corretto − Il tipo di correzione − Etc. Per ciò si usa una classificazione ortogonale di ogni defect (ODC : Orthogonal

Defect Classification), dove un valore è attribuito a dei parametri indipendenti fra di loro che caratterizzarono il defect.



In un secondo tempo, per potere determinare l'andamento sullo stato qualitativo del prodotto, viene usata questa stessa classificazione per analizzare statisticamente :

− I tipi di defect più frequenti − Le parti del prodotto più difettose − La gravità media dei defect rilevati − L'impatto dei defect a livello di uso del prodotto − Etc. Alla classificazione partecipa sia il tester che lo sviluppatore.

6.2.1 Quella del tester è relativa all'aspetto visibile del defect, quindi molto vicino a quello che incontrerebbe l'utente se il difetto non fosse intercettato. Il tester riempe tre valori :

- Activity : Che stava facendo l'utente quando ha rilevato il defect. - Trigger : Che ambiente o condizione ha fatto apparire il defect. - Impact : Che livello dell’uso è affetto dal defect.



6.2.2 Quella dello sviluppatore, invece, riguarda le origini del defect nella struttura del software. Lo sviluppatore riempie cinque valori :

- Target : In che parte di lavoro è stato creato il defect (requirements, design, code,

build/package, ect.) - Type : Che tipo di defect è. - Qualifier : Se è colpa di un omissione, di un errore nell’ implementazione - Source : Quale è la sorgente del defect (sviluppo, librerie esterne, ect.) - Age : In che versione del prodotto è stato introdotto il defect

6.2.3 Scrittura dei “New feature” test

Ritorniamo adesso ai test sulle nuove “Features” della QA. Essi sono quelli che condurranno a una parte dell’autorizzazione del rilascio, quando saranno tutti completati. Per ogni feature, una serie di test case vengono scritti seguendo un gerarchia sulla valutazione di essi, che parte della semplice verifica di esistenza della nuova feature fino a verifiche ben più complesse.

Al di là di essere testate secondo i requisiti,,vengono aggiunti dei test in considerazione della diversità di eventi e condizioni che possono presentarsi dopo l’installazione sui sistemi dei clienti.

Quindi, colui che scrive questi test case per le nuove “feature” deve pensare all’insieme delle azioni che può eseguire l’utente e al comportamento che potrebbe avere il sistema.

La procedura di scrittura dei test case deve rispettare le seguenti caratteristiche :

1) Tempo da dedicare alla esecuzione di un test case

I manager decidono il tempo da dedicare al test di ogni feature tenendo conto dei delle stime effettuate durante la stesura dei test case.

La stima viene fatta prendendo in considerazione :

- Il tempo di comprensione della nuova feature da parte del tester - La probabilità di rilevazione di errori (stima del numero di difetti per feature) -Il tempo necessario a gestire la comunicazione (contattare i diversi team quando

appare un’incomprensione o un defect) - Il tempo per la descrizione e classificazione di un difetto.



2) Rispetto della gerarchia di esecuzione dei test case.

I test case sono vincolati tra di loro secondo una struttura ad albero, i test più precisi e a più alta complessità possono essere fatti solo dopo avere convalidato la funzionalità di base. La testabilità dipende dalla convalidazione di un test case “padre”

Ad esempio :

3) Rispettare la proporzionalità dei Trigger :

I difetti sono rilevati solo se si testano in certe condizioni (dimensione “Trigger” dell’ODC), ad esempio alcuni defect si riproducono solo quando il sistema è sotto stress),dunque prima della scrittura dei test case è definita proporzione che conviene seguire nella definizione del tipo di test da effettuare. Essa è stabilita a seconda delle osservazioni statistiche fatte sui difetti provenienti dal cliente.(cf : 5.4.3).



Ad Esempio puo’ essere stabilito che i test case seguano questa proporzionalità :

50% di coverage : Verificare i requisiti come definiti. dallo sviluppo, concentrandosi sulla funzionalità offerta al cliente.

20% di variation : Verificare che non appaiono defect prendendo in considerazione un uso del sistema non descritto nei requisiti.

15% di Workload\Stress : Mettere il sistema sotto stress o sotto caricato.

15% di Recovery Path : Verificare che i dati non si perdano e che i processi ricomincino dove si erano fermati,dopo un reset del sistema.

Una volta definiti tutti i test case vengono caricati nel “Test Tracking Tool” (descritto nel 6.3) e serviranno per tracciare l’evoluzione dell’implementazione.



Ecco un cronogramma dei test effettuati settimanalmente :

Cronogramma dei Test

Ogni settimana esce una nuova build (“x” di X1.X2.Y.Z.x), poi ricomincia il ciclo di

test, che prende in conto il BVT e i test CVT.

La prima riga rappresenta l’implementazione della prima versione di una Major

Release (X1.X2.0.0) che si svolge in circa 20 settimane e che finisce con l’aggiunto di test “Non-regression” e test BETA.

Le altre righe rappresentano le altre versioni della Major Release (con Service Pack e/o Patch), in cui non sono integrati né i test “Non-regression” né i test BETA.

6.3 Tools and database

Un altro punto nella qualità è il tracciamento delle modifiche sul prodotto ; cioè memorizzare l’insieme delle informazioni sia su l’andamento dell’implementazione delle features che sui defect rilevati. Le informazioni sono, quindi, memorizzate su dei database in un formato standard, che ogni lavoratore deve saper leggere e scrivere. Questi tool sono accessibili a tutti i lavoratori di ANTS sia di Roma che delle altre città d’Italia o dell’estero.



In seguito, descriverò i due tool appoggiati su database usati nella Quality Assurance, uno tratta l’andamento dei test di qualità da effettuare, l’altro tratta i defect rilevati.

6.3.1 Test Tracking Tool

Questo è un tool di tracciamento dei test da effettuare basato su un database, dove, all’inizio dell’integrazione di una nuova release, si carica tramite un file “.UML” o “.XMI” i test case scritti per la implementazione del piano di test vi si registrano per ogni test le seguente informazioni :

- Il nome del test - Il tester a chi è stato assegnato il test - Il tempo richiesto per eseguirlo - Il tipo di test SVT, CVT, etc. - Il trigger del test (i.e. coverage, variation etc) - La componente da verificare. - Etc.

Poi, dall’interfaccia Web Based si possono esporre i test case filtrati in modi diversi ad esempio secondo la feature che riguarda, secondo il tester in carico, secondo la componente sotto test etc.

Questo database sarà, durante i test, aggiornato dai tester, completando le seguenti informazioni :

- Stato del test : completato, fallito o bloccato - Percentuale di completamento - Identificativo dei defect trovati

6.3.2 Change Request Tool

Questo è un tool, basato su un database, dove sono centralizzate tutte le richieste fatte sul prodotto.

Nel Change Request tool sono conservate le richieste di cambiamento che vengono sia dall’interno che dall’esterno. Una richiesta può essere : un enhancement (miglioramento), un defect (difetto o bug del software) o una richiesta che riguarda l’hardware.



Noi, ci concentreremo sulla gestione delle richieste e come vengono veicolate verso le persone che ci devono lavorare.

Ogni volta che una richiesta parte da un tester o da chiunque altro, una “request” è aperta sul “Change Request Tool” ; dove vengono completati diversi campi fra cui i più importanti sono :

- Il titolo, che fa capire di che cosa si tratta.

- Una descrizione dettagliata, “step by step” nel caso di un difetto per permette agli altri lavoratori di poter riprodurlo.

- I campi ODC, descritti nel capitolo precedente

- La Design-part (modulo) del prodotto che riguarda il difetto. Ad ogni Design-part è associata una persona o un gruppo di persone verso cui sarà trasmessa la richiesta.

Una volta creata, la richiesta segue un ciclo di vita dove, ad ogni stato della richiesta, corrisponde un ruolo responsabile di un’attività :

I ruoli che dovranno trattare la presente richiesta di cambiamento sono :

- Il customer support : Il gruppo che gestisce i problemi rilevati dal cliente

- Tester : Esegue i test sia i test di riproduzione della richiesta di cambiamento (se si tratta di un defect) che di verifica alla risoluzione della richiesta di cambiamento.

- QA Manager : Decide come e verso chi va aperto un richiesta di cambiamento quando quello è rilevato dal Customer Support.



- Development Leader : È quello che analizza la richiesta di cambiamento per verificare se riguarda veramente lo sviluppo o meno, e poi, se si, l’orienta verso lo sviluppatore in carico della parte affetta

- Developer : In questo ambito, ha in carico di risolvere la richiesta di cambiamento

Vediamo ora come si svolgono le operazioni nelle diverse fasi della richiesta esposte nello schema sopra :

- OPEN : Una richiesta di cambiamento si apre quando un bug è rilevato dal

cliente e trasmesso dal customer support. Allora, il gruppo della QA deve prima riprodurre il presunto difetto sul suo ambiente di test. Poi, designare quale parte del software è affetta. Se il problema rilevato è analizzato come non defect del prodotto, allora esso è rifiutato con una spiegazione, e va in REJECTED. Una richiesta di cambiamento si apre, ovviamente, anche dal tester in seguito ai test direttamente effettuati sul sistema della QA.

- ANALYZED : In questa fase la richiesta di cambiamento è in carico al leader

dello sviluppo, che studia più in profondità e a livello tecnico il caso. Se la richiesta di cambiamento è autorizzata, allora essa va in ASSIGNED verso gli sviluppatori associati alla/le design-part ; se invece non è autorizzato (mancanza di informazioni da parte da quello che ha fatto la richiesta, difetto non esistente o già dichiarato, etc.), la richiesta va in REJECTED.

- ASSIGNED : È la fase in cui si risolve a codice la richiesta di cambiamento.

Una volta che il problema è risolto, lo sviluppatore mette la richiesta di cambiamento in TEST.

- TEST : Prima di questa fase, normalmente la richiesta di cambiamento è stata

risolta ; il tester va a verificarlo se il problema è effettivamente risolto lo stato della richiesta diventa CLOSED, altrimenti va nello stato FAILED.

- FAILED : Se la richiesta di cambiamento va nello stato FAILED, allora ritorna

allo sviluppatore per la correzione.



- REJECTED : La richiesta di cambiamento può essere rifiutata se il problema non si riproduce sull’ambiente di test della QA, o se servono maggiori informazioni per riprodurre il problema, o se ad esempio si è capito che il problema è dovuto ad un errore nella configurazione.

E gli stati finali sono questi due :

- CLOSED : La procedura avviata rispetto ad un defect o enhancement è chiusa. Il problema è stato riconosciuto e risolto. - CANCELED : La procedura avviata rispetto alla richieste è chiusa ma il problema non è stato riconosciuto ; e nessuna azione è stata fatta dallo sviluppo.

Ecco uno schema che mostra l’uso dei database di tracciamento :



I due task “Test Schedule Control” e “Test Quality Control” eseguiti dal QA manager sono descritti nei paragrafi successivi.

6.4 Schedule & Quality control

In questa parte saranno presente due attività in carico al Quality Assurance Manager che permettono di controllare l’andamento dell’implementazione di una release a livello temporale, quantitativo e qualitativo.

6.4.1 Prerequisiti e documenti

Per valutare gli aspetti evocati nell’introduzione, è necessario avere a disposizione una basa d’informazione sicura.

Per la valutazione temporale si consulta il tracciamento sul “Test Tracking Tool”.

Invece per la valutazione qualitativa, si consulta il tracciamento dei defect sul “Change Request Tool”.

6.4.2 Schedule control

Per rispettare le date fissate con il cliente, è necessario avere un controllo dell’evoluzione e dell’implementazione.

Questo viene fatto seguendo l’andamento dei test (completati o rimanenti) rispetto ad una previsione iniziale, con l’aiuto di un foglio di calcolo (tipo Excel).

Per quanto riguarda la previsione sulla durata del test, essa viene fatta, nel task “Define Evaluation Mission”, a partire dalle stime dei tempi per le operazioni seguenti :

− Installazione del sistema all’inizio del ciclo di test

− BVT (Basic Validation Test) : aggiornamento del sistema con le nuove build, compresi i test di funzionamento di base del prodotto.

− Tempo richiesto per eseguire i test di qualità di CVT, SVT e performance.

− Test di “no-regression” finali.



− Test sulle richieste di cambiamento che dipende dal numero di bug aspettati che si stima si troveranno durante il consolidamento della release,

− Nel caso di alcune feature per cui i requisiti non sono stati interamente definiti, si fa, oltre alle valutazioni descritte sopra, una stima pessimista corrispondente ad un coefficiente che può andare fino a un aumento del 50% per le feature molto poco descritte.

� La stima finale è espressa in Giorni.Uomo. Per comodità, questa quantità è tradotta in punti, ANTS usa 1 Giorno.Uomo = 80 punti.

Si assegna questa quantità di lavoro (espresso in punti) tra i diversi lavoratori secondo le loro disponibilità :

In questo modo, si può prevedere un calendario, associato ad una curva, del lavoro da realizzare (espresso in punti) ripartito sulla scala temporale.

Curva di previsione del lavoro

Si può vedere su questa curva, una ripartizione lineare, più due periodi piani

corrispondenti alle ferie, e un accelerazione alla fine dovuta all’arrivo di un nuovo tester.

Il secondo compito (effettuato nell’attività “Verify Test Approach”) è di aggiornare settimanalmente questo calendario. Quindi si faranno ciclicamente queste operazioni :

- Riportare le informazioni di tracciamento aggiornate sul “Test Tracking Tool”, esse servono per comprendere quanto lavoro è stato fatto effettivamente.

- Aggiornare le nuove disponibilità dei lavoratori.



Si compara il lavoro previsto con quello realizzato ; se l’andamento del lavoro è nei tempi prefissati, allora, tutto è a posto, si aspetta la settimana successiva.

Se si verifica un ritardo, (curva viola sotto quella blu) allora deve essere decisa un azione correttiva del tipo :

- Ridistribuire dei test ad un altro tester, - Assegnare un altro lavoratore ai test, - Fare ore supplementari di lavoro. - Ect.

6.4.3 Product quality control

Questo compito riguarda proprio la qualità del prodotto, analizzando le richieste di cambiamento registrati sul “Change Request Tool”. Esse saranno sia in base al loro andamento temporale che secondo la teoria ODC.

In questo capitolo sarà esposto qualche aspetto presentando tre attività :

• Evoluzione temporale dei defect

Un output della validazione di una release è la scoperta di defect, è necessario controllarne la ripartizione nel tempo.



Curva della risoluzione dei defect (dalla FC alla GA)

La ripartizione ideale dei defect risolti durante l'implementazione di una release

deve seguire una forma a campana che ha il suo massimo alla metà del tempo previsto per il consolidamento della release. (Nella figura è riportato l’andamento ideale, e reale della distribuzione delle richieste di cambiamento su di una release).

Cumulativo dei defect introdotti nello sviluppo delle nuove features prima della FC e dei defect dovuti agli enhancement successivi alla FC.

Questa curva invece descrive l’andamento cumulativo dei defect ed enhancement

rispetto al tempo di implementazione di una release. Si vede in maniera netta che la quantità di defect aumenta all'introduzione di enhancement.

Un enhancement è una richiesta di cambiamento o aggiunta di funzionalità ad una feature. Essi sono introdotti una volta che la feature è integrata nel sistema (anche con



alcuni bug), dopo la FC, quando con l’utilizzo si può vedere e immaginare tutti i piccoli miglioramenti necessari al buon funzionamento della feature che sono stati pensati al momento della descrizione dei requisiti.

Un enhancement viene trattato come un defect, quindi integrato nel codice ma senza una definizione preliminare dei requisiti. Questo, anche permettendo di gestire gli enhancement velocemente, ha un inconveniente : quello di avere una maggiore probabilità di introdurre un defect durante la codifica dell’enhancement.

Una intera feature descritta con requisiti precisi e dettagliati invece può presentare pochi bug in quanto sono stati pensati prima sia i test fatti direttamente dallo sviluppo che il metodo di implementazione (paragrafo 4.2.2).

Per concludere il paragrafo sulla ripartizione temporale dei defect, osserviamo con questo grafico l’andamento dei defect entranti (aperti dai tester) rispetto a quelli risolti ; in altri termini, lo scarto temporale di risoluzione.

Tipicamente, la maggior parte dei defect della FC è rilevata, e in grande quantità, nella prima parte dell’implementazione ; lo sviluppo non ha, allora, la capacità di risolverli subito, ed essi vengono risolti in seguito in modo ripartito. Nella seconda metà dell’implementazione rimangano solo alcuni defect ; lo sviluppo riesce dunque a ridurre significativamente la quantità di defect.



• Severity resolution

Adesso entriamo un po' più nell’analisi qualitativa del prodotto prendendo in considerazione la gravità del defect rilevati.

Ogni defect scoperto viene aperto con uno dei cinque livelli di gravità seguenti.

- Blocking : Defect che causa la cessazione completa di una parte del prodotto e che non può essere aggirato con una soluzione di tipo WorkAround.

- High : Defect che ha un impatto importante sul modo in cui funziona il prodotto o blocca completamente una funzionalità importante del prodotto che non può essere contornata con un WorkAround.

- Medium : Defect che non ha un impatto considerabile sulla funzionalità o che blocca una funzionalità che può, però, essere contornato con un WorkAround

- Low : Defect che non ha impatto sulle funzionalità, che non modifica le informazioni essenziali ma crea dei disturbi minori.

- Zero : Defect che non ha impatto sul funzionamento del prodotto (Defect del tipo : messaggio scritto male …)

Oltre a dare visibilità sulla serietà dei difetti e quindi sulla qualità, questa classificazione interviene nella priorità di risoluzione ; quelli a più alta priorità vengono risolti prima.

Ogni settimana (insieme al Test Schedule Control), è rilevata la quantità di defect per severità, così si disegna un diagramma delle priorità.



Dunque, i defect di alta priorità devono essere risolti all'inizio dell'implementazione per lasciare quelli di bassa gravità alla fine ; questo per due ragioni fondamentali :

− Qualità : È la motivazione più ovvia, in considerazione del caso in cui ci sarà un ritardo nell'implementazione ; il prodotto viene rilasciato con difetti a basso impatto.

− Dipendenza : Certi defect a bassa priorità dipendono da un defect più grave (Un difetto importante crea una serie di piccoli altri difetti). Quindi, lavorare prima sui defect di alta priorità permette di andare più veloce nella risoluzione di altri bug è chiaro sbloccare dei test.



• Paragone Trigger ed Impact cliente/QA Per ottimizzare i test rispetto e renderli piu’ vicini ad un utilizzo reale del sistema da

parte del cliente vengono confrontati le richieste di cambiamento del cliente con quelle interne della QA.

Si realizza un istogramma dei difetti rilevati sui sistemi installati dai clienti, con due delle tre caratteristiche ODC del tester : Il Trigger e l’Impact.

In pratica, si confrontano le operazioni che hanno fatto insorgere un problema e la loro conseguenza.

Grazie a questa analisi, si può osservare il comportamento e le necessità di ogni cliente.

Un esempio :

Ecco il paragone dei defect rilevati da due cliente per una stessa release.

Si vede per tutti e due che gli impatti sono Capability (il rispetto dei requisiti) e

Usability (la difficoltà d’uso), che sono tipicamente quelli dichiarati di più sia dai clienti che dalla QA.

Invece la differenza viene dal trigger quindi dal tipo di situazione e azioni fatte sul sistema che hanno condotto agli errori.

Questo diagramma rivela che la QA ha rilevato una maggioranza di defect di tipo Coverage (su una singola funzionalità), il cliente invece è stato impedito molto di più da dei problemi di Sequencing (sequenze di un insieme di funzionalità) e Variation (uso dei componenti in un modo diverso di quello descritto nei requisiti).



Questo conduce alla conclusione che il cliente fa un uso più complesso del software ed usa le funzionalità a volte in modo diverso da come sono state pensate.

Quindi, per future release, saranno effettuati più test di tipo Variation o Sequencing, modificando la proporzionalità dei test CVT da definire (cf : 6.2.3).

6.5 Process Quality Control

Al QA Manager non viene solo richiesto di garantire la qualità del prodotto del suo

progetto e dei processi utilizzati nel progetto stesso ma anche di contribuire al miglioramento di tutti i processi. Come spiegato prima, i processi di gestione dei progetti sono gli attrezzi dei lavoratori e sono utilizzati da loro, il QA manager è responsabile per migliorarli.

Questa attività non può rispondere per forza ad un processo predefinito, ma si tratta di dare prova d’iniziativa, innovazione e creatività.

Una modifica di processo può essere di qualsiasi tipo e di varie dimensioni, può essere creato un processo nuovo o migliorato uno durante l’uso.

Il framework, che è l’oggetto di questo stage, è un output di questa attività di miglioramento continuo dei processi.

Tipicamente il QA Manager si basa sui due concetti sviluppati sotto per eseguire questa attività :

• Analisi costi-benefici

Nel migliorare i processi si deve tenere conto dell’equilibrio tra costi e benefici.

Ad esempio un miglioramento che riduce le attività di correzione del prodotto, si traduce in una più elevata produttività, minori costi e aumento della soddisfazione dei clienti.



Ad esempio :

Ad esempio in figura il miglioramento propone un prodotto con meno difetti all’uscita dallo sviluppo (facendo magari più test di unità, tipicamente meno costose del test funzionale fatto dal team di QA), che richiede meno tempo di test da parte del team di QA.

Se il rapporto costi-benefici è peggiore di quello del processo iniziale, il processo non viene proposto.

L’equilibrio costi-benefici si può migliorare anche direttamente riducendo il costo delle attività, ad esempio l’automazione di un task, la standardizzazione delle procedure per risparmiare tempo, etc.

• Benchmarking

Il benchmarking è il confronto tra le pratiche del progetto, effettive o pianificate, e quelle di altri progetti al fine di produrre idee per il miglioramento e fornire una base di misurazione delle prestazioni. Gli altri progetti possono essere all’interno dell’azienda o esterni e possono riguardare la stessa area applicativa o aree diverse.

Esistono delle “best practices” per identificare gli step da migliorare nei processi :

Il piano di miglioramento dei processi è un elemento che descrive i passaggi necessari per analizzare i processi ; tali passaggi aiutano a identificare gli sprechi e le attività senza valore aggiunto producendo un aumento di valore per il cliente.

Di seguito ne vengono descritti alcuni:



Confini dei processi : consente di descrivere lo scopo, l'inizio e la fine dei processi, i loro input e output, i dati eventualmente necessari ed il responsabile dei processi.

Configurazione dei processi : è un diagramma di flusso dei processi che semplifica l'analisi con le interfacce identificate.

Metriche dei processi : consentono di mantenere il controllo sullo stato dei processi, principalmente usando dei metodi di tracciamento (Salvataggio su database, classificazione ODC, etc…).

Obiettivi per il miglioramento delle prestazioni : orientano le attività di miglioramento dei processi.

La creazione del framework risponde alle due prime parti del piano sopra.

Possiamo pure dire che è un miglioramento di questi due primi task avendo una descrizione standard, esaustiva e permanente.

Per concludere questo capitolo sul controllo di qualità :

Il gruppo di qualità è responsabile della validità del prodotto prima del rilascio al cliente sia a livello del prodotto stesso che a livello dei processi. Le verifiche si fanno sulla base di predizioni teoriche associate ad un controllo permanente dell’andamento della qualità, e riassunte in una analisi finale.

Tutte queste operazioni conducono ad una versione GA (General Available) che è la versione che può essere rilasciata ai clienti.

Il manager della qualità è il primo a dare l’autorizzazione di GA quando sono verificati i seguenti criteri :

- Tutti test predefiniti sono stati completati - Nessuno defect High o Blocking non risolto - La curva dei “Defect Incoming” è in saturazione

I project manager devono tutti accettare i problemi noti che possono rimanere nella versione GA (con severity minore ad high) e dichiarare di poterli gestire con i clienti.



7 Miglioramenti previsti

Sei mesi è ovviamente un periodo troppo corto per costruire un Framework completo su tutti i processi di produzione del gruppo ANTS. Non tutto è stato descritto e quello che è stato descritto non è sempre giusto o completo.

Siamo però arrivati ad un punto dove tre strutture di processi stabili sono disponibili e dove la maggior parte dei task più frequenti sono descritti.

Questo permette di avere una documentazione efficiente per la formazione di nuovi lavoratori sui task, ed avere un framework navigabile e quindi migliorabile da la parte di tutti i team.

Per il futuro, il framework evolverà secondo questi tre punti :

- Concludere il framework

Per concludere il lavoro fatto durante lo stage, occorre completarlo con l’insieme delle attività presentate nel capitolo 5 ; allora il framework sarà perfettamente funzionante per migliorare i processi da parte dei manager e per risparmiare tempo nell’eseguire dei task.

- Standardizzazione

Il framework ha per obiettivo principale di standardizzare la descrizione dei processi. Abbiamo anche come ambizione di estendere questa metodologia all’insieme dei lavoratori dell’azienda che lavorano su prodotti diversi da ANTS ; o anche, in futuro, a gruppi che non riguardano l’aspetto produttivo dell’azienda (ad esempio : l’amministrazione, risorse del personale…)

- Un Framework in evoluzione

Questo framework non avrà mai una versione definitiva e sarà regolarmente aggiornato per diverse ragioni.

I task sono spesso aggiornati, aggiunti, cancellati o sostituiti sia per migliorare il prodotto che i processi ; per maggiore leggibilità, una parte intera del framework può anche essere ristrutturata. L’aspetto positivo è che il framework è stato pensato dall’inizio con questa intenzione di estenderlo e di ottimizzarlo continuamente durante l’esecuzione dei processi stessi.



Commenti Finali Per finire il mio percorso di studio, ho seguito uno stage nel mondo dell’industria al

fine di iniziare il mio progetto professionale.

In futuro dovrò riuscire a portare un contributo alle tecnologie di punta, nel mondo delle telecomunicazioni, avendo la capacità di creare ed innovare con soluzioni rispondenti alle necessità richieste dalla società.

Avevo necessità di andare al di là dell’aspetto tecnico insegnato in facoltà ed ormai imparato, e di assimilare delle conoscenze complementari che mi permettessero di mettere in pratica l’insegnamento scolastico, cioè quelle che riguardano l’aspetto gestionale.

Dopo un colloquio, ho accettato l’argomento di stage proposto da Emmanuele Tordelli, che porta direttamente sui processi industriali nell’ambito di software per reti di telecomunicazioni e che quindi sembrava rispondere a quello che mi interessava.

Con questo progetto di fine studio fatto in azienda, il contributo ed il guadagno è doppio : l’azienda mi apporta delle conoscenze nell’ambito della formazione, io, contribuisco a migliorare il suo prodotto.

Le conoscenze globali, che sono utile al di fuori del gruppo ANTS, sono :

- Visione globale del funzionamento di un azienda - Pianificazione di un lavoro e valutazione del suo costo - Aspetti teorici sulla classificazione ODC e sul metodo RUP - Tecniche di implementazione per il software - Metodo di descrizione delle feature per lo sviluppo - Criteri di convalidazione per il rilascio (verifica delle feature, controllo delle

performance, etc.) - Gestione dei casi dei clienti - Struttura completa di un sistema informatico installato su rete mobile - Conoscenze generali dei test da effettuare su reti mobile e del funzionamento dei

servizi che la rete mette a disposizione dell’utente finale (i.e Wap Navigation,

VideoCall, DataCall, etc.)



Il contributo al prodotto è :

- Il framework.. - L’investimento dell’azienda sulla mia formazione che mi ha reso operativo per il

gruppo team della qualità.

A questo, è stato aggiunto una formazione tecnica proprio nel team di QA allo scopo di un’assunzione che comprende :

- Tutte le conoscenze globali esposte prima - Conoscenza del sistema ANTS - Conoscenza del personale ANTS e le loro responsabilità - Scrittura ed esecuzione dei test case.

Ancora mancano molti punti da migliorare e da imparare su cui intendo lavorare in seguito :

- Mettere in pratica i processi che ho scritto. Purtroppo, per la maggiore parte, li ho scritti in base a spiegazioni e non sono state assimilate e che potranno essere assimilate solo con la pratica.

- Comprendere meglio la parte di gestione economica. Questa è una parte molto importante per capire il funzionamento dell'azienda e le decisione processi che vengono prese.

- Lavorare più vicino al cliente. - Lavorare alla comunicazione in cui ho ancora un ritardo importante, dovuto al fatto

di essere straniero in Italia. - Ovviamente approfondire tutto quello che ho già fatto.

Un altro punto molto arricchente è che lo stage ha permesso di migliorarmi, a titolo personale oltre che professionale su :

- La lingua italiana - Il linguaggio e la comunicazione aziendale - L’amministrazione italiana



* **

Finalmente, sono contentissimo di essere riuscito ad aver terminato questo progetto di doppio titolo, che mi ha permesso di imparare : la lingua e la cultura italiana, il lavoro aziendale in Italia, ma anche approfondire le mie conoscenze tecniche e specializzarmi in telecomunicazioni nell'università La Sapienza.

Grazie a questa esperienza potrò, in futuro, contribuire allo sviluppo dell'Europa, ringraziando ancora una volta tutti quelli che mi hanno permesso di fare questo progetto.

Julian Piagneri Ingegnere delle Telecomunicazioni

procesprocessi di produzione del si di produzione del...

Documents