FACOLTA` DI SCIENZE MM.FF.NN CORSO DI LAUREA IN

Transcript

UNIVERSITA’ DEGLI STUDI DI NAPOLI
FEDERICO II
FACOLTA’ DI SCIENZE MM.FF.NN
CORSO DI LAUREA IN INFORMATICA
TESI DI LAUREA
Catena USAGE : Il testing in ambiente Telecom Italia
RELATORE
CANDIDATO
Prof. Eliana Minicozzi
Antonino Rizzo
TUTOR AZIENDALE
MATRICOLA
Dott. Antonio Ferraro
566/1056
Anno Accademico 2006-2007
1
Un caloroso ringraziamento alla mia famiglia, e a
chi mi ha sostenuto durante questi anni cosi
impegnativi offrendomi comprensione e serenità:
grazie mamma grazie papà.
2
INTRODUZIONE ...................................................................................................................................... 5
ORGANIZZAZIONE DELLA TESI.......................................................................................................... 6
DEFINIZIONI ACRONIMI E ABBREVIAZIONI .................................................................................. 8
CAPITOLO 1 SVILUPPO DEL SOFTWARE .......................................................................................... 8
1.1 METODOLOGIE UTILIZZATE................................................................................................................... 8
1.2 IL COLLAUDO...................................................................................................................................... 9
1.3 MODELLO DI SVILUPPO ........................................................................................................................ 10
1.3.1 Sviluppo a cascata .........................................................................................10
1.3.2 Sviluppo guidato dal collaudo .......................................................................10
1.4 FASI DI RILASCIO ................................................................................................................................. 11
1.4.1 Il collaudo Alfa..............................................................................................11
1.4.2 Il collaudo Beta..............................................................................................12
1.5 AUTOMAZIONE DEL COLLAUDO ............................................................................................................ 12
1.6 GRANULARITÀ ...................................................................................................................................... 13
1.6.1 Il collaudo di modulo.....................................................................................14
1.6.2 Il collaudo di sistema.....................................................................................15
1.7 CONOSCENZA DELLE FUNZIONALITÀ INTERNE .................................................................................... 15
1.7.1 Il collaudo a scatola bianca............................................................................15
1.7.2 Il collaudo a scatola nera ...............................................................................16
1.8 COLLAUDO FORMALE E INFORMALE .................................................................................................... 17
1.8.1 Il collaudo informale .....................................................................................17
1.8.2 Il collaudo formale.........................................................................................18
1.9 TIPOLOGIE DI COLLAUDO ..................................................................................................................... 19
1.9.1 Collaudo Prestazionale (Performance Test) ..................................................19
1.9.2 Collaudo di Carico/Volume (Load/Volume Test) .........................................20
1.9.3 Collaudo di Stress (Stress Test).....................................................................22
1.10 IL COLLAUDO DI REGRESSIONE .......................................................................................................... 23
1.11 IL COLLAUDO IN TELECOM................................................................................................................. 23
CAPITOLO 2 AREA USAGENUOVI SERVIZI DI COLLAUDO BSS ............................................................. 24
2.1 INTRODUZIONE .................................................................................................................................... 24
2.2 TIPOLOGIE DI TEST .............................................................................................................................. 25
2.2.1 Test di sistema (System test) .........................................................................25
2.2.2 Test d’integrazione .......................................................................................25
2.2.3 Test prestazionale ..........................................................................................26
2.3 PASSI FONDAMENTALI ......................................................................................................................... 27
2.3.1 Pianificazione ................................................................................................27
2.3.2 Progettazione .................................................................................................27
2.3.3 Predisposizione ambienti di collaudo ............................................................28
2.3.4 Verifica e validazione del software ...............................................................28
2.3.5 Supporto collaudo utente ...............................................................................28
2.3.6 Rilascio ad esercizio ......................................................................................29
2.4 CONTESTO DI RIFERIMENTO ................................................................................................................ 30
2.4.1 Architetura Applicativa USAGE ...................................................................30
2.4.2 Il sistema PP ..................................................................................................31
2.4.3 Il sistema MVAL...........................................................................................33
2.4.4 Operazionale traffico (OT) / PLT..................................................................34
2.4.5 Sorveglianza e Controllo (SSC) ....................................................................36
3
CAPITOLO 3 IL SISTEMA INCONTRA ................................................................................................ 38
3.2 ARCHITETTURA DEL SISTEMA .............................................................................................................. 38
3.3 ADAPTER .............................................................................................................................................. 40
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
3.3.10
Attivazione su canale d’ascolto ..............................................................42
Validazione Envelope attraverso schema XSD fornito ..........................42
Verifica SO in ambito INCONTRA .......................................................42
Validazione CIM_SO .............................................................................42
Verifica SO duplicato .............................................................................42
Trasformazione CIM enterprise in CIM INCONTRA DATI.................43
Verifica RICHIESTA IN AMBITO .......................................................43
Verifica Controlli formali.......................................................................43
Invio corretti a QD..................................................................................44
Scrittura log riepilogativo.......................................................................44
3.4 QUALITÀ SAS....................................................................................................................................... 45
3.5 QUALITÀ JAVA.................................................................................................................................... 47
3.6 STORICO............................................................................................................................................ 50
3.7 STRATEGIA DI COLLAUDO ........................................................................................................... 53
3.7.1
3.7.2
ON-LINE ................................................................................................53
BATCH...................................................................................................55
CAPITOLO 4 STRUMENTI UTILIZZATI ............................................................................................. 56
4.1 INTRODUZIONE .................................................................................................................................... 56
4.2INFODELIVERY...................................................................................................................................... 57
4.2.1
4.2.2
4.2.3
4.2.4
Introduzione............................................................................................57
Profilo DM..............................................................................................58
Profilo Sviluppo......................................................................................59
Profilo Collaudo .....................................................................................60
4.3PVCS.................................................................................................................................................... 61
4.3.1
4.3.2
4.3.3
Introduzione............................................................................................61
RILASCI SOFTWARE (RIL) ................................................................63
Schede anomalia (SM)............................................................................65
CONCLUSIONI ...................................................................................................................................... 69
4
Introduzione
La presente tesi ha lo scopo di illustrare il lavoro svolto presso l’azienda Unlimited
Software, in collaborazione con Accenture e Telecom Italia.
Il mio lavoro di Tirocinio e attuale lavoro è quello di esplorare e presentare le
problematiche del collaudo in ambiente Telecom, riguardante software destinati alla
fatturazione del traffico fisso. In Telecom è stata predisposta una catena apposita per
tale collaudo, USAGE Collection, suddivisa a sua volta in varie piattaforme, ognuna
destinata a gestire un particolare ramo della catena stessa:
-
INCONTRA (Integrazione consistenza traffico)
-
PP (Post Processing)
-
OT/PLT (Operazionale traffico)
-
MVAL (Modulo di valorizzazione)
-
SSC (Sistema di sorveglianza e controllo)
La mia attenzione è stata circoscritta al collaudo della piattaforma INCONTRA.
Nell’esame del ciclo di vita di un software (analisi, design, sviluppo, collaudo ed
esercizio), il collaudo si trova al centro, avendo così in ambiente Telecom un ruolo
fondamentale su cui tutti fanno riferimento, a partire dagli analisti fino all’Esercizio.
L’obbiettivo è quello di cercare e trovare più anomalie possibili all’interno del
softaware e a volte anche di specifiche causate da una sbagliata analisi del problema.
5
Organizzazione della tesi
La tesi consta di quattro capitoli.
Il primo capitolo presenta ed introduce le metodologie per una buona progettazione
software secondo le linee guida affrontate nello studio dell’Ingegneria del software; col
fine di porre maggiore attenzione verso la fase del test, obiettivo principale del mio
percorso di tirocinio, conclude facendo un confronto tra il collaudo teorico e quello in
ambiente Telecom, cercando di capire che tipo di collaudo viene utilizzato in Telecom e
quali modifiche sono state effettuate a tale tipologia.
Il secondo capitolo presenta i problemi relativi al collaudo dei software di fatturazione
in ambiente postpagato fisso di Telecom Italia. Tale software è parte dell’area USAGE,
specifica Area all’interno del mondo Telecom. In particolare si analizzanotutti i sistemi
che compongono tale area, lasciando al capitolo tre la presentazione di INCONTRA,
area di mia competenza.
Nel terzo capitolo viene presentata e spiegata l’architettura del sistema INCONTRA.
INCONTRA è a monte della catena USAGE, acquisisce i dati anagrafici denominati
“consistenze”, e li passa al Post Processing per l’arricchimento del cartellino. Si
analizzano nel dettaglio le varie componenti hardware e software che compongono il
sistema e in fine si elencano tutti i passi necessari per portare a termine, con esito
positivo, un collaudo per INCONTRA.
Il quarto e ultimo capitolo presenta gli strumenti che gestiscono e monitorano il
collaudo in ambiente Telecom. Si elencano tutti i software utilizzati, e ci si sofferma in
particolare su i due software basilari per il collaudo: Infodelivery e PVCS.
La tesi termina con le considerazioni finali sulle difficoltà incontrate e superate.
6
Definizioni, Acronomi e Abbreviazioni
Termine
Descrizione
CRM
Customer Relationship Management
SO
Service Order
CIM
Common Information Model
CU
Collaudo Utente
Cdr
Call Detail Record (cartellino di traffico)
NP
Number Portability
CPS
Carrier Pre Selection
CED
Centro Elaborazione Dati
PI
Proposta Implementativa
7
Capitolo1 (1)
Sviluppo del Software
In questo capitolo sono descritte le fasi fondamentali di una progettazione software.
In particolare l’importanza di avere un tool di supporto di revisioni all’interno di
progetti di collaudo.
1.1 Metodologie Utilizzate
Nella realizzazione di un progetto software il primo passo da eseguire è la scelta di uno
tra i vari modelli di processo.
Un modello di processo è un insieme di fasi prevedibili volti alla realizzazione del
software. Il loro scopo è quello di introdurre stabilità, controllo ed organizzazione ad
un’attività tendenzialmente caotica.
Solitamente le fasi che sono affrontate in un modello di processo, sono le seguenti:
-
Analisi dei Requisiti:
La raccolta dei requisiti si intensifica e si concentra sul software. Al fine di
comprendere la natura dei programmi da costruire, l’ingegnere del software deve
comprendere il dominio delle informazioni del software. I requisiti sia del
sistema sia del software devono essere documentati e riveduti insieme al cliente.
-
Pianificazione:
Vengono rianalizzati i dati raccolti nella fase d’Analisi al fine di identificare e
risolvere eventuali carenze ed ambiguità.
-
Progettazione:
La progettazione è un processo composto di varie fasi che si focalizzano su
particolari attributi distinti di un programma: struttura dei dati, architetture del
software, possibili interfacce del prodotto software e di fondamentale
importanza i dettagli procedurali (gli algoritmi).
1: Tratto da http://en.wikipedia.org/wiki/Software_testing
8
-
Costruzione:
Anche chiamata fase di generazione del codice: il progetto deve essere tradotto in
qualche linguaggio di programmazione (scelto nelle fasi di Progettazione) per
renderlo leggibile da una macchina.
-
Il Collaudo
Prima di passare al rilascio del software, per verificare che il progetto soddisfi le
attese del cliente, bisogna affrontare il Collaudo.
1.2
Il COLLAUDO
Il "software testing" è un procedimento utilizzato per individuare le carenze di
correttezza, completezza e affidabilità delle componenti software in corso di sviluppo.
Consiste nell'eseguire il software da collaudare, da solo o in combinazione ad altro
software di servizio, e nel valutare se il comportamento del software rispetta i requisiti.
In prima analisi, occorre distinguere i "malfunzionamenti" del software, dai "difetti:
- Un malfunzionamento è un comportamento del software difforme dai requisiti
espliciti o impliciti. In pratica, si verifica quando, in assenza di
malfunzionamenti della piattaforma (hardware + software di base), il sistema
non fa quello che l'utente si aspetta.
- Un difetto è una sequenza di istruzioni, sorgenti o eseguibili, che, quando
eseguita con particolari dati in input, genera un malfunzionamento. In pratica, si
ha un malfunzionamento solo quando viene eseguito il codice che contiene il
difetto, e solo se i dati di input sono tali da evidenziare l'errore. Per esempio, se
invece di scrivere "a >= 0", il programmatore ha erroneamente scritto "a > 0" in
una istruzione, si può avere un malfunzionamento solo quando viene eseguita
quell'istruzione mentre la variabile "a" vale zero.
Lo scopo del collaudo è di rilevare i difetti tramite i malfunzionamenti, al fine di
minimizzare la probabilità che il software rilasciato abbia dei malfunzionamenti nella
normale operatività. Per rilevare il maggior numero possibile di difetti, nel collaudo si
sollecita il software in modo che sia eseguita la maggior quantità possibile di codice con
svariati dati di input.
9
Le tecniche di collaudo possono essere classificate in molti modi. I principali sono i
seguenti:
•
Per modello di sviluppo: a cascata, guidato dal collaudo.
•
Per appartenenza o meno dei collaudatori all'organizzazione che modifica i
sorgenti, nonché per fase di sviluppo: Alfa, Beta.
•
Per grado di automazione: manuale, semi-automatizzato, completamente
automatizzato.
•
Per granularità: collaudo di modulo, collaudo di sistema.
•
Per livello di conoscenza delle funzionalità interne: a scatola bianca, a scatola
nera.
•
Per grado di formalità: da informale a formale.
1.3 Modello di sviluppo
1.3.1 Sviluppo a cascata
Il procedimento tradizionale di sviluppo del software, detto "a cascata", prescrive di
iniziare il collaudo appena è completata la prima versione del prodotto. I risultati del
collaudo vengono utilizzati per rivedere i requisiti, o il progetto, o il codice, e produrre
così la versione successiva.
Questo procedimento è stato sottoposto a una severa critica in quanto ha i seguenti
svantaggi:
•
Se è giunta la data prevista per il completamento del prodotto, si tende a
consegnarlo anche se il collaudo non è stato completato o ha dato esito negativo, il
che significa che probabilmente si sta consegnando un prodotto scadente.
•
Più tempo passa tra l'introduzione di un errore in un sistema e la segnalazione di
un malfunzionamento dovuto a tale errore, più risulta difficile e costoso
rimediarvi.
10
1.3.2 Sviluppo guidato dal collaudo
Un procedimento più recente, detto "guidato dal collaudo, proposto a partire dall'inizio
degli anni 1990, consiste nel considerare il collaudo una parte integrante del prodotto:
•
Quando si analizzano i requisiti del software da produrre, si analizzano i
requisiti del collaudo.
•
Quando si progetta l'architettura del software da produrre, si progetta
l'architettura del collaudo.
•
Quando si scrive il codice del software da produrre, si scrive il codice delle
routine di collaudo automatizzato o si preparano i dati e si scrivono le istruzioni
per il collaudatore manuale.
•
Quando si costruiscono gli eseguibili compilando i sorgenti, se la compilazione
va a buon fine, vengono automaticamente eseguite le routine di collaudo
automatizzato. Le prove vere e proprie vengono tuttavia relegate a una
procedura parzialmente manuale.
•
Quando si archivia o si recupera una versione dei sorgenti, si archiviano o si
recuperano tutti i suddetti documenti relativi al collaudo. Anzi, tali documenti
devono essere intesi come parti integranti dei sorgenti.
1.4 Fasi di rilascio
1.4.1 Il collaudo Alfa
Appena un software è stato costruito, prima di rilasciarlo fuori dall'azienda, viene
normalmente sottoposto a un collaudo interno all'azienda. Tale procedura viene
chiamata "collaudo Alfa".
Il collaudo Alfa può essere eseguito dagli stessi programmatori o da altro personale
dell'azienda.
Spesso, il software prodotto per il collaudo Alfa viene arricchito di istruzioni di
controllo a run-time che facilitano il rilevamento degli errori. Esempi di tali istruzioni
sono:
•
il controllo che non si acceda a indici non validi di array;
11
•
il controllo che tutta la memoria allocata venga disallocata prima della
terminazione;
•
asserzioni dichiarative scritte dal programmatore.
In alcuni casi, in particolare per lo sviluppo di software di sistema o di software
embedded, si utilizza un ambiente hardware di esecuzione che supporta specificamente
il debugging e il collaudo.
1.4.2 Il collaudo Beta
Spesso, quando un prodotto ha superato il collaudo Alfa, viene rilasciato all'esterno
dell'azienda ad alcuni clienti selezionati o anche a tutti i clienti, avvertendo gli utenti
che il prodotto rilasciato potrebbe non essere di qualità elevata e probabilmente richiede
ulteriori correzioni. Tale versione viene detta "versione Beta".
Gli utenti della versione Beta possono simulare l'utilizzo del software in casi realistici, e
inviare al produttore resoconti dei malfunzionamenti riscontrati. Tale tipo di collaudo
eseguito gratuitamente dagli utenti viene detto "collaudo Beta".
Possono esserci più versioni Beta, man mano che vengono corretti gli errori. Quando la
frequenza delle segnalazioni d'errore diventa bassa, è il momento di rilasciare la
versione ufficiale.
Anche dopo che sono state rilasciate delle versioni Beta, e quindi si è in fase di collaudo
Beta, all'interno dell'azienda può continuare il collaudo Alfa.
1.5 Automazione del collaudo
Se il collaudo consiste nell'utilizzo del prodotto quasi come se fosse la normale
operatività, si parla di "collaudo manuale".
Se il collaudo consiste nello sviluppo di apposito software che interagisce con il
software da collaudare e fornisce un rapporto di qualità in assenza di personale, si parla
di "collaudo automatizzato".
12
Tra questi due estremi, si possono avere varie posizioni intermedie, in cui parte del
lavoro è automatizzato, ma è sempre richiesta la presenza del collaudatore. In tali casi,
si parla di "collaudo parzialmente automatizzato" o di "collaudo semi-automatizzato".
Nel collaudo manuale, tipico del software interattivo, il collaudatore utilizza il software
come farebbe l'utente, ma cercando di attivare il maggior numero possibile di k e le
configurazioni più variegate. Quando il collaudatore constata un comportamento
inatteso, ne prende nota e prosegue a collaudare altre funzionalità.
Nel collaudo automatico, il collaudatore può usare due tecniche di base:
1. Scrive a mano il software di collaudo.
2. Esegue il software da collaudare in un ambiente di collaudo che registra le
operazioni dell'utente.
La prima tecnica richiede che il collaudatore sia un programmatore che conosca
l'architettura interna del software da collaudare. Il software di collaudo, tipicamente
scritto in un linguaggio ad altissimo livello, può interagire con il software da collaudare
in vari modi:
•
chiamando direttamente le singole routine di tale software;
•
chiamando le routine esportate (ossia pubblicate) da un modulo;
•
inviando al programma da collaudare dei messaggi di comunicazione tra
processi;
•
lanciando il programma da collaudare in una modalità in cui riceve due file, uno
dal quale legge i dati di input, e l'altro nel quale scrive i dati di output.
Qualunque sia la tecnica di comunicazione adottata, quando il software da collaudare
risponde, il programma di collaudo confronta le risposte ottenute con i risultati attesi. In
caso di discrepanza, viene generato un resoconto.
La tecnica della registrazione delle operazioni dell'utente può essere attuata anche da un
collaudatore che non sa programmare o che non conosce l'architettura interna del
software da collaudare. Ha tuttavia due grossi inconvenienti:
•
C'è un'alta probabilità che, quando il software da collaudare viene modificato, le
registrazioni siano improprie, e quindi da rifare.
13
•
L'ambiente di collaudo non fornisce strumenti automatici per determinare se il
software ha il comportamento atteso.
Questa tecnica è indicata per collaudi solo parzialmente automatizzati, in quanto è
sempre necessario che il collaudatore verifichi visivamente se il software si comporta
come dovrebbe.
1.6 Granularità
1.6.1 Il collaudo di modulo
Quando si costruisce un'automobile, non si ci si limita a costruire e ad assemblare i
pezzi e alla fine girare la chiave per vedere se tutto funziona. Questo per tre motivi:
•
Alcuni difetti producono malfunzionamentii solo dopo un utilizzo prolungato,
ma sono facilmente identificabili esaminando i singoli pezzi prima
dell'assemblaggio.
•
Se dopo aver girato la chiave la macchina non si accende, risulta molto difficile
capire qual è il difetto.
•
Se dopo aver girato la chiave la macchina non si accende, risulta molto costoso
smontare la macchina, sostituire il pezzo difettoso e rimontarla.
Ragionamenti analoghi valgono per il software. Pertanto, come i singoli pezzi di un
macchina vengono sottoposti al controllo di qualità prima dell'assemblaggio, così è
opportuno collaudare separatamente le singole componenti di un sistema software.
Le componenti collaudabili di un sistema software prendono il nome di "moduli" o
"unità", per cui si parla di "collaudo di modulo".
Un modulo può avere una granularità variabile da una singola routine, a un insieme di
alcune decine di routine, a un sottosistema comprendente migliaia di routine. Nella
programmazione orientata agli oggetti la tipica componente da collaudare è la classe.
14
Siccome un modulo, per definizione, non è un programma completo, mentre il concetto
stesso di collaudo richiede l'esecuzione di un programma, per eseguire il collaudo di
modulo si deve costruire un apposito programma che contiene il modulo da collaudare.
In un programma completo, tutti i moduli, eccetto quelli di livello più basso, richiamano
routine di altri moduli, e tutti i moduli, eccetto quelli di livello più alto, contengono
routine a disposizione di altri moduli.
Per costruire un programma intorno a un modulo, è necessario fornire delle routine
banali che possano essere chiamate dal modulo, finché non saranno pronte le routine
complete. Tali routine banali sono dette “stub”.
Per mandare in esecuzione il codice contenuto nel modulo occorre invocarne le routine.
Viene pertanto scritto un apposito programma che richiama le routine del modulo,
passandole in sequenza vari parametri e verificando che le routine rendano i valori
attesi. Tale programma viene detto "driver".
Normalmente, per rendere più flessibile e modificabile il collaudo, il driver preleva da
un file di dati i parametri che dovrà passare alle routine del modulo da collaudare, e
confronta i risultati ottenuti con il contenuto di un altro file di dati. Per ogni discrepanza
riscontrata tra i dati ottenuti e quelli attesi, viene generato un messaggio d'errore in un
terzo file di resoconto.
Con tale architettura, se si vuole aggiungere una combinazione di valori a quelle
esistenti, basta modificare i file di dati.
1.6.2 Il collaudo di sistema
Anche se i singoli moduli sono corretti, il sistema ottenuto integrandoli potrebbe non
esserlo. Pertanto è sempre necessario collaudare il sistema completo.
Per collaudare un sistema completo si deve utilizzare il software in modo il più
possibile simile a come verrà utilizzato nella normale operatività, ma con le seguenti
differenze:
•
Per il software interattivo, la normale operatività consiste in una persona che
interagisce con il software. Questo si ottiene con il collaudo manuale, che è
15
sempre utile, ma ha vari svantaggi. Il collaudo automatizzato di un programma
interattivo è difficile da ottenere, se non rinunciando a parte del concetto di
normale operatività.
•
Nella normale operatività di un sistema software, per ogni singola installazione
del sistema, l'utilizzo segue un certo andamento ripetitivo. Siccome nel collaudo
si deve simulare il maggior numero possibile di situazioni, normalmente si
rinuncia alla ripetitività tipica delle situazioni reali, e invece si simulano utilizzi
molto variegati.
1.7 Conoscenza delle funzionalità interne
1.7.1 Il collaudo a scatola bianca
Il collaudo effettuato richiamando direttamente le routine del software da collaudare,
viene detto "collaudo a scatola bianca". Per poter eseguire il collaudo a scatola bianca, il
collaudatore deve poter leggere la documentazione delle routine esportate dai moduli, se
non addirittura il codice sorgente.
Si tratta di un collaudo automatizzato, e tipicamente è utilizzato per il collaudo di
modulo, in quanto i singoli moduli non sarebbero altrimenti singolarmente accessibili al
collaudatore.
Le routine di collaudo a scatola bianca possono essere scritte nello stesso linguaggio
con cui è stata scritta l'applicazione, oppure con un altro linguaggio in grado di
interfacciarsi con il primo.
Normalmente, le routine da collaudare e le routine di collaudo che le invocano
costituiscono un unico processo, cioè sono linkate insieme.
Il collaudo a scatola bianca, siccome richiede l'interfacciamento con le singole routine,
può essere effettuato solamente da un programmatore, anche se non necessariamente un
membro del gruppo che ha sviluppato il software da collaudare. Normalmente è
effettuato comunque da un membro dell'organizzazione che sviluppa il software.
Un vantaggio del collaudo a scatola bianca è che permette di sondare dettagliatamente
tutte le casistiche che possono presentarsi.
16
Un altro vantaggio è che l'automazione è più facile ed efficiente.
Un altro vantaggio è che è più facile il debugging, cioè passare dal malfunzionamento
alla correzione del difetto, in quanto la segnalazione del malfunzionamento
normalmente indica il punto del codice e i valori delle variabili per cui il
malfunzionamento si è manifestato.
1.7.2 Il collaudo a scatola nera
Il collaudo effettuato accedendo al software solamente tramite l'interfaccia utente,
oppure tramite interfacce di comunicazione tra processi, viene detto "collaudo a scatola
nera".
Può essere manuale oppure automatizzato, e tipicamente è utilizzato per il collaudo di
sistema, in quanto per collaudare l'intero sistema normalmente non è necessario
richiamare singole routine.
Se si tratta di un collaudo automatizzato, le routine di collaudo sono prevalentemente
scritte in un linguaggio di livello più alto del linguaggio con cui è stata scritta
l'applicazione, a volte in un linguaggio progettato appositamente per il collaudo.
Il software da collaudare e il software di collaudo costituiscono processi distinti
comunicanti.
Per il collaudo a scatola nera manuale non è richiesta l'opera di un programmatore, e per
quello automatizzato è sufficiente un programmatore con modeste competenze. Spesso
il collaudo a scatola nera è effettuato da persone che non fanno parte dell'organizzazione
che sviluppa il software; si tratta degli utilizzatori stessi che effettuano il collaudo Beta.
Un esempio di una tecnica di collaudo a scatola nera automatizzata consiste nel
registrare l'interazione dell'utente in un file, e poi ripetere la registrazone simulando il
comportamento dell'utente.
Un vantaggio del collaudo a scatola nera sta, nei casi in cui il codice sorgente e la
documentazione di progetto sono segreti industriali, nel fatto tale collaudo può essere
effettuato anche da persone esterne all'azienda.
17
Un altro vantaggio sta nel fatto che per tale tipo di collaudo non sono necessari
programmatori esperti e che conoscano gli aspetti interni del software da collaudare.
Pertanto, si possono trovare molti più collaudatori, senza dover investire
nell'addestramento.
1.8 Collaudo formale e informale
1.8.1 Il collaudo informale
Nelle piccole organizzazioni, o per prodotti software di poco valore, in collaudo è
normalmente informale, cioè non esiste a livello organizzativo una mansione
riconosciuta come "collaudo del software".
Il programmatore, appena dopo aver apportato una modifica al software, manda in
esecuzione il software modificato e verifica interattivamente se il funzionamento è
quello atteso. Se il comportamento è insoddisfacente, apporta altre modifiche e reitera il
procedimento.
Quando il programmatore è soddisfatto del comportamento del software, invia il
software al suo superiore, che effettua un ulteriore rapido collaudo manuale. A questo
punto, se non si tratta di modifiche che devono urgentemente essere rese operative, la
nuova versione viene inviata agli utenti e al personale di assistenza come versione Beta.
Gli utenti e il personale vengono addestrati alle nuove modifiche, e tale addestramento
costituisce l'occasione per la rilevazione di ulteriori malfunzionamenti.
In tale procedimento informale di collaudo, la segnalazione di malfunzionamenti e di
nuove versioni non segue un iter ben definito. Si usano comunicazioni di persona,
telefoniche, e-mail, e appunti su biglietti.
1.8.2 Il collaudo formale
Per eseguire un collaudo formale, cioè rigorosamente pianificato, si scrive un "piano di
collaudo", in cui si descrive dettagliatamente come deve essere svolto il collaudo.
18
Ci sono due strategie fondamentali per organizzare il collaudo: la "batteria di prove", e
lo "scenario di collaudo". Spesso si utilizzano in combinazione, cioè si pianificano una
o più batterie di prove e una serie di scenari di collaudo.
Una batteria di prove è un insieme di collaudi elementari, ognuno dei quali è detto
"prova". Ogni prova ha almeno i seguenti attributi:
•
Spesso, un identificatore o numero progressivo.
•
Talvolta, una descrizione dello scopo della prova.
•
Una sequenza di operazioni necessarie per portare il sistema nelle condizioni
iniziali per la prova.
•
Una sequenza di operazioni necessarie per riportare il sistema nelle condizioni di
base dopo la prova.
•
Le dipendenze, cioè gli identificatori dei casi di prova che devono aver avuto
successo affinché abbia senso effettuae questa prova. Per esempio, se se una
prova consiste nell'aprire un file e chiuderlo, e un'altra prova consiste nel leggere
lo stesso file, la seconda prova dipende dalla prima, in quanto non ha senso
tentare di leggere un file che non è stato possibile aprire.
•
Le operazioni che sollecitano il software da collaudare.
•
Il risultato atteso.
•
Talvolta, il tempo massimo ammissibile per ricevere il risultato.
Spesso vengono aggiunti altri attributi.
Nel caso di collaudo manuale, queste informazioni possono essere stampate e tenute
come linea guida per il collaudatore. Nel caso di collaudo automatizzato, queste
informazioni sono le specifiche per il programmatore che deve realizzare il software di
collaudo.
Quando una prova viene eseguita, si registrano altre informazioni, tra cui le seguenti:
•
Autore della prova.
•
Data e ora di esecuzione.
•
Identificatore della versione collaudata.
•
Esito (successo o fallimento).
•
In caso di fallimento, breve descrizione del tipo di fallimento.
19
Uno scenario di collaudo è un utilizzo realistico non banale del software da collaudare.
Mentre le prove di collaudo considerano le funzionalità elementari, ogni scenario
prende in considerazione una tipologia di utente e una situazione verosimile e
complessa in cui tale utente può trovarsi. Il collaudo di scenario percorre tutti i passi che
l'utente percorrerebbe in tale situazione. Il collaudo Beta è di fatto un collaudo di
scenario, sebbene informale. Il collaudo di scenario è necessariamente un collaudo di
sistema, e tipicamente è manuale o semiautomatico.
1.9 Tipologie di collaudo
1.9.1 Collaudo Prestazionale (Performance Test)
Lo scopo del “performance testing” non è di rilevare errori nell’applicazione, ma di
eliminare potenziali “colli di bottiglia” e stabilire un punto di partenza per i futuri test di
regressione. Per condurre un test di questo tipo è necessario eseguirlo in un processo
controllato di misurazione e analisi. Il software sottoposto a test dovrebbe essere
abbastanza stabile in modo che le operazioni di verifica possano procedere senza
intoppi. Un insieme chiaramente definito di “cosa ci si aspetta” è essenziale per un test
significativo. Ad esempio, per un’applicazione web sarebbe necessario conoscere
almeno le seguenti due cose:
•
“carico atteso” in termini di utenti concorrenti o connessioni http,
•
“tempi di risposta” considerati accettabili.
Restando all’esempio dell’applicazione web, i colli di bottiglia potrebbero esistere a
diversi livelli, e per identificarli si possono usare differenti tool:
•
a livello applicativo, gli sviluppatori possono usare strumenti di profilatura per
scoprire inefficenze del codice
•
a livello di database, gli sviluppatori e i DBA possono usare tool specifici del
database
•
a livello di sistema operativo, i system engineers possono usare utility quali top,
vmstat, iostat (su sistemi Unix-like) e PerfMon (su Windows) per verificare
l’uso delle risorse hardware quale la CPU, memoria, aree di swap, disk I/O.
20
•
a livello di rete, i network engineers possono usare i packet sniffer quail
tcpdump, o network protocol analyzers come ethereal, e altre utility varie come
netstat, MRTG, ntop, mii-tool.
Da un punto di vista di test, queste attività sono tutte del tipo white-box, dove il sistema
è ispezionato e controllato "dall’interno verso l’esterno" e da vari angoli. Una volta
raccolte le misure e analizzate, e come risultato, si effettua un tuning applicativo.
Tuttavia, a volte si usa anche un approccio black-box effettuando un test di carico sul
sistema. Per una applicazione web, ad esempio, si usano tool che simulano un certo
numero di utenti/connessioni http concorrenti e si misura il “response times”.
1.9.2 Collaudo di Carico/Volume (Load/Volume Test)
Questo tipo di test in genere è parte del performance testing e tuning. In tale contesto,
significa aumentare costantemente il carico sul sistema tramite strumenti automatici. Per
una applicazione web, ad esempio, il carico è il numero di utenti/connessioni HTTP
concorrenti.
In letteratura, il termine load testing è di solito definito come il processo di esercizio del
sistema sotto test alimentandolo in modo da fargli eseguire i task più grandi con cui esso
può operare. Il test di carico è talvolta chiamato anche volume testing, o
longevity/endurance testing.
Esempi di volume testing:
•
test di un word processor editando un documento molto grande;
•
test di una stampante inviandogli un job molto grande;
•
test di un mail server con migliaia di mailbox utente;
•
un caso specifico di volume testing è il cosidetto “zero-volume testing”, dove il
sistema viene alimentato con task “vuoti”.
Esempi di longevity/endurance testing:
21
•
test di una applicazione client-server eseguendo il client in un loop di accessi
alla componente per un periodo di tempo esteso.
Scopi del load testing:
•
scoprire bug non emersi in fase di test, quali errori del tipo “memory
management”, “memory leaks”, “buffer overflow”, ecc.;
•
assicurare che l’applicazione soddisfa le prestazioni di “baseline” stabilite
durante il “performance testing”. Questo viene fatto effettuando un test di
regressione sull’applicazione con un specifico carico massimo.
Nonostante il “performance testing” e il “load testing” possano sembrare similari, il loro
scopo è differente. Da un lato, il “performance testing” utilizza tecniche e strumenti di
“load testing” per la misurazione e allo scopo di effettuare misure di “benchmarking”
utilizzando vari livelli di carico. Dall’altro, il “load testing” opera ad un predefinito
livello di carico, di solito il massimo carico che il sistema può accettare continuando a
funzionare regolarmente. Lo scopo non è di “rompere” il sistema sovraccaricandolo, ma
invece provare a mantenere il sistema costantemente attivo come una “macchina ben
oliata”. E’ necessario enfatizzare l’importanza di questo tipo di test. L’esperienza ha
infatti mostrato che molti bug importanti non emergono fintanto che il sistema non ha a
che fare con una mole di dati veramente vasta, come ad esempio migliaia di utenti in
repository quali LDAP/NIS/Active Directory, migliaia di caselle di posta utente su
server-mail, tabelle multi-gigabyte nei database, lunghissime gerarchie di file/directory
sui file-system, ecc. In questi casi, quasi sempre c’è l’esigenza di utilizzare tool
automatizzati che generino una tale mole di dati, ma fortunatamente con un qualunque
buon linguaggio di scripting questo risulta un compito molto facile.
1.9.3 Collaudo di Stress (Stress Test)
Lo “stress test” ha lo scopo di provare a “rompere” il sistema sotto test sovraccaricando
le sue risorse o sottraendogli risorse (in tale caso viene anche chiamato “negative
testing”). Lo scopo principale di queste attività è verificare che il sistema va in “fault” e
successivamente (eventualmente) recupera in maniera “indolore” – questo aspetto
qualitativo è noto come recoverability (sistemi fault-tolerant).
22
Mentre il “performance test” richiede un ambiente controllato e misure ripetibili, lo
stress test provoca caos e impredicibilità. Per rifare ancora un esempio per una
applicazione web, alcuni modi in cui si può stressare il sistema sono i seguenti:
•
raddoppiare il numero di utenti/connessioni HTTP previste in baseline
•
in maniera casuale spegnere e riavviare porte dei switch/router di rete che
collegano i server (via comandi SNMP ad esempio)
•
mettere offline il database, e farlo ripartire
•
effettuare un rebuild di un array RAID mentre il sistema è funzionante
•
eseguire processi che consumano risorse (CPU, memoria, disco, rete) sui webserver sui database-server.
La lista può essere ovviamente arricchita. Comunque, lo stress test non è fatto al puro
scopo di far andare in crash il sistema, ma piuttosto deve servire per osservare come il
sistema reagisce alle failure. Riesce a salvare il suo stato o va in crash
nuovamente/continuamente? Si ferma improvvisamente, bloccandosi, o in maniera
controllata? Al riavvio, è in grado di recuperare dall’ultimo stato corretto? Visualizza
messaggi di errore comprensibili all’utente, o si limita a visualizzare incomprensibili
elenchi di codice esadecimale? La sicurezza del sistema è compromessa a causa di un
failure inatteso? E così via.
1.10 Il collaudo di regressione
Uno scopo del collaudo è verificare che i nuovi prodotti e le nuove funzionalità aggiunte
a vecchi prodotti siano di alta qualità. Tuttavia, nel software capita spesso che
l'introduzione di una nuove funzionalità a un vecchio prodotto comprometta la qualità di
funzionalità preesistenti del prodotto. Pertanto, per assicurarsi la qualità del prodotto
bisognerebbe ripetere l'intero collaudo ad ogni modifica. Il collaudo di funzionalità
preesistenti e già collaudate, eseguito per assicurare che modifiche al prodotto non ne
abbiano compromesso la qualità si chiama "collaudo di regressione", in quanto si vuole
verificare se la qualità è regredita.
Se erano stati predisposti dei collaudi automatizzati, il collaudo di regressione ha
normalmente un basso costo, in quanto si tratta solo di lanciare le procedure di collaudo
esistenti, eventualmente ritoccate. Un completo collaudo di regressione manuale
23
sarebbe invece enormemente costoso, e per tale motivo normalmente il collaudo di
regressione manuale è più sbrigativo del collaudo originale.
1.11 Il collaudo in Telecom
Dopo aver preso in considerazione le diverse strategie di collaudo, possiamo introdurre
il collaudo in ambiente Telecom, cercando di capire che tipologia di collaudo viene
utilizzata.
Dopo un analisi approfondita possiamo definire il collaudo Telecom come un collaudo a
cascata, infatti una volta che Analisi (2) completa i documenti di specifica, Sviluppo
inizia a sviluppare il software consegnando una prima versione al collaudo. Da questo
punto in poi è il collaudo a dare direttive sia a Sviluppo che ad Analisi, dando direttive
sulle modifiche da fare, in modo tale che vengano sviluppate nuove specifiche o nuove
versioni del software. Come visto in precedenza lo sviluppo a cascata ha degli
svantaggi, andiamo ad analizzare come Telecom li ha risolti:
Svantaggio:
•
“Se è giunta la data prevista per il completamento del prodotto, si tende a
consegnarlo anche se il collaudo non è stato completato o ha dato esito negativo,
il che significa che probabilmente si sta consegnando un prodotto scadente”.
In Telecom si è deciso di dare più importanza alla qualità, infatti se nasce un anomalia
il giorno stesso del rilascio, la stessa fa slittare il rilascio per permettere a Sviluppo di
risolvere il problema e, a fronte del nuovo rilascio, a Collaudo di effettuare i test.
Quindi fino a quando il Collaudo non termina i test con esito positivo non viene
effettuato alcun rilascio. In questo modo non si corre il rischio di rilasciare un
“prodotto scadente”.
2: ‘Analisi’ è il nome del gruppo di lavoro che si occupa dell’analisi del problema. E’ un esempio di come si nominano in ambiente
Telecom i gruppi di lavoro
24
Capitolo 2
(3)
Area USAGE
Nuovi Servizi di Collaudo BSS
2.1 Introduzione
Il processo denominato USAGE Collection è tipico ed esclusivo dell’ambito delle
telecomunicazioni, in quanto comprende l’insieme di procedure e sistemi che
consentono la raccolta del traffico, al fine di veicolarne il contenuto ai componenti
aziendali che ne fanno utilizzo.
L’area USAGE è una specifica area all’interno del mondo Telecom, che si occupa del
collaudo software di fatturazione in ambiente postpagato fisso. A livello di collaudo
vengono effettuati tre diversi tipi di test:
-
test di sistema
-
test d’integrazione
-
test prestazionale
Di seguito vengono riportati i Sottoprocessi/attività fondamentali a supporto del
Processo di Collaudo in ambito USAGE :
Test
di Sistema
Test
d’Integrazio
ne
Test
Prestazionale
Collaudo USAGE
Pianificazion
e
Progettazion
e
Predisposizio
ne ambienti di
collaudo
Verifica e
validazione
del SW
Supporto al
collaudo
utente
Rilascio in
esercizio
Figura 1 Sottoprocessi e attività fondamentali a supporto del Processo di Collaudo in ambito Usage
3: Tratto da USAGE - Processo collaudi BSS.ppt; http://USAGE.ve.telecomitalia.local
25
2.2 Tipologie di test
2.2.1 Test di sistema (System test)
Il Test di Sistema ha l’obiettivo di verificare che siano soddisfatti i requisiti funzionali
riportati nei documenti di Specifica elaborati dal gruppo di Design.
Le esigenze di sistematicità e metodicità della progettazione dei test ne suggeriscono
l’organizzazione secondo i seguenti criteri:
- individuazione dei requisiti che descrivono le nuove implementazioni oggetto di
release (tali documenti sono contenuto nel repository documentale);
- suddivisione dei requisiti in casi di test (ogni requisito può essere verificato da uno
o più casi
di test); organizzazione dei casi di test in catene, ossia in sequenze di
elaborazione tali da riprodurre l’operatività dell’utente o da ottimizzare l'esecuzione
del test.
- Si sottopone a test di sistema ogni singola componente di USAGE.
2.2.2 Test d’integrazione
Il Test d’Integrazione si pone l’obiettivo di verificare l’intero comportamento della
catena USAGE (Post Processing, MVAL, Operazionale Traffico e PLT) includendo
anche le interfacce con i sistemi esterni.
Ciascun sistema interfacciato è inserito nell’ambiente del Collaudo Integrato dopo
essere stato precedentemente sottoposto a Test di Sistema ed aver superato lo stesso con
esito positivo.
Il Collaudo Integrato raccoglie i suddetti sistemi e ne verifica l’operatività in un
ambiente che rappresenti nel modo più fedele possibile quello di Esercizio. Ciò implica
che, nell’ambiente di Collaudo Integrato, non sono presenti interfacce fittizie, simulatori
26
o altro software di supporto allo sviluppo e non destinato all’ambiente di Esercizio. A
questa regola fanno eccezione i simulatori di traffico proveniente dai sistemi di rete.
Il Collaudo Integrato deve far riferimento, preferibilmente, a dati prelevati
dall’ambiente di Esercizio per quanto concerne le informazioni relative al Cliente,
Prodotti e Servizi in consistenza, dati di traffico, ecc., codificati all’interno di scenari
che rappresentano i processi di business end-to-end della Commercializzazione.
La progettazione dei Casi di test del Test d’Integrazione, pone pertanto la necessità di
evidenziare le “aree di integrazione ” tra la Catena USAGE ed i Sistemi interfacciati.
Nell’ambito della catena USAGE, le attività di Test di Sistema e d’Integrazione
vengono svolte da Gruppi di Lavoro distinti e caratterizzati da una forte collaborazione.
A conclusione del Test d’Integrazione viene prodotto un Rapporto di Fine Esecuzione
dove sono riportati in maniera sintetica i risultati del collaudo (Casi di test prodotti,
Anomalie aperte, Anomalie chiuse, ...) .
2.2.3 Test prestazionale
Al termine del collaudo funzionale, quando la release software è consolidata, si passa
ove necessario alla fase di test prestazionale. Il test prestazionale si rende necessario
solo a fronte di nuove architetture software oppure variazioni alle componenti software
critiche sotto il profilo prestazionale.
Il collaudo prestazionale viene svolto in ambienti che rispettano per quanto possibile
l’ambiente di Esercizio del sistema stesso. I test prestazionali sono vincolati per il
rilascio in Esercizio del software.
27
2.3 Passi fondamentali
2.3.1 Pianificazione
Il sottoprocesso procede in parallelo alle attività in carico a Sviluppo e consiste nella
definizione della strategia di collaudo e nella relativa pianificazione.
La strategia di collaudo è definita in base alla struttura del Kit definito da DM e al
contenuto informativo delle PI (Proposta implementativa). La strategia di collaudo tiene
conto anche di eventuali specifiche richieste di Test Prestazionali - provenienti da
“Application Operation” o nate internamente al Collaudo – e di Test di Integrazione,
provenienti da Technology (Rete). Definita la strategia, Collaudo effettua la relativa
pianificazione delle attività anche sulla base del Piano Generale del Kit verificato da
“Cross Support”.
Il sottoprocesso produce i documenti: “Strategia di Collaudo” e “Piano di Collaudo” in
versione 1.0
2.3.2 Progettazione
La Progettazione consiste nella definizione dei casi di test, formalizzati nel Test Book. I
casi di test progettati in questa fase hanno l’obiettivo di verificare gli aspetti funzionali,
di integrazione, prestazionali, di esercibilità. Per la progettazione dei casi di test
Collaudo utilizza inizialmente le Proposte di Implementazione emesse da DM e
successivamente la documentazione resa disponibile da Sviluppo per il completamento
della progettazione stessa con gli aspetti di maggior dettaglio.
In particolare, nella fase di progettazione Collaudo individua le necessità di collaudi
prestazionali e di integrazione in base alla documentazione tecnica ricevuta ed alle
eventuali richieste provenienti da “Gestione Applicazione” (Test prestazionali) e/o da
“Gestione Rete” (Test di Integrazione).
Se necessario, richiede a “Application Operation” dati per la successiva fase di
esecuzione dei test progettati.
28
2.3.3 Predisposizione ambienti di collaudo
Il sottoprocesso consiste nella predisposizione degli Ambienti di Collaudo per la
esecuzione dei casi di test progettatti.
Collaudo configura le componenti hw e sw di base rese disponibili da ICT Operations.
Installa inoltre eventuali simulatori forniti da sviluppo e/o realizzati internamente e/o
prodotti software specifici forniti dallo stesso sviluppo. Procede quindi – ove necessario
- a mascherare i dati ricevuti da “Application Operation”.
Installa infine il sw applicativo da collaudare.
2.3.4 Verifica e validazione del software
Il sottoprocesso consiste nella esecuzione dei casi di test progettati nella fase di
progettazione. Collaudo esegue casi di test estratti a campione dal System Test Book
fornito da Sviluppo. Riporta il risultato di tale attività nel relativo “Rapporto di
Esecuzione del System Test”. Procede quindi al controllo di qualità del sw da
collaudare eseguendo i casi di test preventivamente progettati (test funzionali, test di
integrazione, test di esercibilità ed eventuali test prestazionali). Aggiorna il Test Book
con i risultati del controllo effettuato. Utilizza i tools a disposizione per tracciare
l’esecuzione dei casi di test (Infodelivery) ed aprire le relative anomalie (PVCS).
Formalizza infine il termine delle attività con il Rapporto di Fine Collaudo e con il
Rapporto di collaudo di performance (se effettuato). Nel corso del processo, aggiorna
costantemente lo stato avanzamento delle attività e, se è il caso, il Piano di Collaudo.
2.3.5 Supporto collaudo utente
Esaurita la verifica e validazione del kit e prima del rilascio in esercizio può esser
richiesto il supporto di Collaudo per i collaudi utente previsti dal Piano di Collaudo per
alcune applicazioni. A tal proposito, Collaudo completa la predisposizione dell’
ambiente per il Collaudo Utente (in termini di dati e accessi server e client) nel rispetto
delle scadenze indicate nel Piano di CU. Garantisce quindi, il funzionamento degli
ambienti di collaudo predisposti durante le varie sessioni di collaudo utente. Predispone
29
infine delle “Segnalazioni anomalie di CU ” - come traccia delle varie anomalie
segnalate nel corso dei collaudi stessi - che inoltra al Demand Management. Il Demand
Management esamina le segnalazioni pervenute al fine di individuare le effettive
anomalie di CU.
2.3.6 Rilascio ad esercizio
Al termine della fase di collaudo del KIT - formalizzata dal Rapporto di Fine Collaudo e
dalla Comunicazione di Fine Collaudo Utente - il software e la documentazione
necessaria viene consegnato (tramite PVCS) a “Application Operation” che, in base alla
pianificazione, provvede all’installazione in ambiente di esercizio. Laddove ritenuto
necessario sarà richiesto a Collaudo, un supporto alle fasi di installazione e
configurazione svolte presso i Centro Elaborazione Dati (CED). Al termine della fase di
collaudo di patch correttive - formalizzata da Rapporto Sintetico di Collaudo “Gestione Applicazioni” richiede – se del caso - a Collaudo un supporto per la messa in
esercizio delle patch stesse.
30
2.4 Contesto di riferimento
2.4.1 Architetura Applicativa USAGE
Figura 2 Catena Usage
Possiamo suddividere la catena USAGE in cinque sottosistemi:
-
Post Processing
-
INCONTRA
-
OT/PLT
-
MVAL
-
SSC
I quali saranno di seguito descritti nel dettaglio, analizzando più approfonditamente
INCONTRA, che come su scritto è il sistema di mia competenza.
31
2.4.2 Il sistema PP
Figura 3 Sistema Post Processing
Post Processing : Controlli di Qualità e Arricchimento del Cdr.
Il sistema PP (Post Processing) effettua l’acquisizione e il controllo delle diverse
tipologie di dati di traffico, in particolare acquisisce le informazioni di consistenza
all’inizio di ogni ciclo di elaborazione e, dopo aver terminato tale fase, acquisisce i file
inviati dai sistemi di Rete e non, effettuando poi le seguenti operazioni
-
Esegue controlli strutturali e di duplicazione a livello di file e di singolo
Call Detail Record (Cdr) nell’arco di un periodo determinato
-
Esegue controlli formali su alcuni campi del record
-
Esegue il controllo d’addebitabilità con eventuale ricostruzione del
numero di chiamante (nel caso di GNR)
-
Esegue caratterizzazione delle linee attestate ad impianti Alice Voice e
del traffico intercomunicante.
32
-
Esegue controllo di Carrier Pre Selection (CPS) e Number Portability
(NP)
-
Esegue il controllo sugli invarianti in fase di sincronizzazione
-
Arricchisce il contenuto informativo dei record di traffico
-
Identifica il codice cliente chiamato per consentire il marcaggio della
chiamata ON/OFF NET in ambito Arbor
-
Verifica numero portato per chiamate verso radiomobile
-
Verifica della number portability per NNG OLO con attribuzione
dell’effettivo gestore e descrizione della numerazione portata
-
Verifica della number portability per NG OLO con attribuzione
dell’effettivo gestore e descrizione della numerazione portata
-
Esegue la cifratura del numero chiamato, della destinazione e del campo
cifre selezionate.
Il PP riceve in input da mediation i cartellini di traffico, che sono delle vere e proprie
telefonate (Cdr) , e effettua controlli formali (lunghezza del record, domini errati, …) su
ogni record del cartellino, se il record non supera questi controlli viene scartato. Dopo i
controlli formali si procede con i controlli di addebitabilità che divideranno i cartellini
in corretti o sospesi. Si classificheranno sospesi quei cartellini che non sono in grado di
essere fatturati per errori tariffari o errori su date. Effettua operazioni di arricchimento
del contenuto informativo dei record di traffico con le consistenze che gli arrivano da
INCONTRA e da altri sistemi a monte. Tutti i cartellini che passano corretti vengono
immediatamente spediti ad ARBOR (piattaforma fatturante in TELECOM) per la
fatturazione. E nello stesso tempo vengono mandati ad MVAL tutti i cartellini divisi in
sospesi, scartati e corretti. E infine invia due flussi verso SSC, il primo all’inizio del
processo elaborativo e il secondo al termine del suddetto processo. Per i record sospesi
OT si occupa di effettuare operazioni di ricircolo con eventuali forzature e di rispedirli
in input al PP per risottometterli ai controlli di addebitabilità.
33
2.4.3 Il sistema MVAL
Figura 3 Sistema MVAL
Sistema/modulo di valorizzazione (MVAL) ha il compito di valorizzare la tipologia di
traffico dei dati nello stato corretto per le varie nature dati (DIA, DARI, VoIP, Easy IP
ADSL, Alice Prepagato e WiFi) e di fornire successivamente il traffico al sistema OT e
di altri sistemi a valle. Se il processo di valorizzazione non dovesse andare a buon fine, i
Cdr non vengono trattenuti in MVAL ma vengono direttamente inviati al sistema
cliente. Nel caso risulti impossibile valorizzare un Cdr in MVAL verrà forzato sempre
l’importo con valore a zero e verrà restituito un opportuno codice di errore. La
valorizzazione del traffico standard viene effettuata al netto di offerte, promozioni e
sconti. I parametri di riferimento per la valorizzazione del traffico sono:
•
direttrice di traffico;
•
data ed ora chiamata,
•
durata conversazione;
•
natura dati;
•
caratteristiche utenza
34
2.4.4 Operazionale traffico (OT) / PLT
Figura 4 Sistema OT
Il sistema Operazionale Traffico (OT) ha il compito di gestire il database del traffico
in termini di valorizzazione, svecchiamento e storicizzazione di tutte le tipologia di
traffico suddivise nei diversi stati: corretto, sospeso, scartato.
La Piattaforma Lavorazione del Traffico (PLT) è uno strumento web-oriented a
disposizione degli operatori Telecom – appartenenti a linee funzionali differenti – per
visualizzare e/o lavorare dati di traffico.
Il sistema OT acquisisce in input tutti i cartellini provenienti da MVAL e li distribuisce
in tre DB diversi, dividendoli in sospesi, scartati e corretti. . La differenza tra scarto e
sospensione è guidata dalla possibilità e dall’interesse di recupero del XDR. In altre
parole, alcune condizioni non permettono l’azione di recupero in quanto mancano dati
essenziali, oppure vengono raccolti records non di interesse ai fini dell’addebito o ai fini
35
statitici e quindi scartati. Una volta a settimana l’OT effettua il ricircolo dei sospesi, che
consiste di ridare in input al PP tutti i sospesi, se gli stessi ritornano sospesi, tramite la
Piattaforma di Lavorazione del Traffico si effettuano le forzature. Possiamo avere due
tipi di forzature: per linea d’addebito e per data. Una volta effettuata la forzatura si
passa al secondo ricircolo che dovrebbe permettere a PP di far passare tutti i cartellini
forzati come corretti. Per sospensioni del tipo: traffico precedente/successivo
all’attivazione/cessazione viene effettuata una forzatura su data, che consiste nello
slittare la data del cartellino nel periodo valido per la fatturazione.
2.4.5 Sorveglianza e Controllo (SSC)
Figura 5 Sistema SSC
Il Sistema di Sorveglianza e Controllo (SSC) ha come obiettivo il monitoraggio
dell’efficacia e dell’efficienza del Processo di Fatturazione circa il traffico Fonia/Dati di
ogni servizio di Telecom Italia. Le fasi che saranno monitorate nel Processo di
Fatturazione nell’ambito della nuova piattaforma Siebel/Arbor sono le seguenti:
36
Mediation-Post Processing: scopo di questo sottoprocesso è di preparare i record che
documentano la singola funzione del servizio per la loro valorizzazione. Le attività
necessarie sono: la memorizzazione delle informazioni di provisioning e contrattuali per
la validazione dei Cdr, la raccolta, marcaggio ed elaborazione dei record di
documentazione ai fini dell’accounting, il trasferimento al sistema di valorizzazione dei
soli Cdr fatturabili.
Rating: con questo termine si intende il processo che valorizza il singolo record di
traffico (Cdr) calcolando il prezzo da associare al record di utilizzo del servizio raccolto
e preparato nella fase di Mediation. Il prezzo è espresso in un’unità monetaria
appropriata attraverso l’applicazione, per ogni singolo Cliente, della tariffa appropriata.
Billing: il processo di fatturazione è quello che consente di trasferire l’insieme di
informazioni di rating memorizzate relative ad un’utente in una fattura con l’importo di
pagamento.
Il sistema SSC dovrà essere alimentato dai vari flussi che impattano in Input e Output i
processi sopra elencati. I dati contenuti nei flussi saranno utilizzati per fornire misure
base e indicatori sull’andamento sia della singola fase che di più fasi insieme: i valori
che SSC fornirà per ogni misura sono relativi al numero di Cdr (in valore assoluto ed in
percentuale) e al volume trasmesso/ricevuto o la durata per il servizio VOIP.
USAGE Collection fornisce a SSC le seguenti interfacce per tutti i servizi destinati a
fatturazione:
-
Chiavi degli XDR in input da parte di tutti i sistemi di USAGE
Collection, arricchiti con attributi di fase opportuni;
-
Chiavi degli XDR corretti, sospesi e scartati in output da parte di tutti i
sistemi di USAGE Collection, arricchiti con attribuiti di fase opportuni;
37
Capitolo 3
(4)
IL SISTEMA INCONTRA
3.2 Architettura del sistema
Figura 6 Architettura INCONTRA
4: Tratto da ICT_R2_AD_SFU_SpecificheFunzionali_v3_01_12.doc; ICT_R2_QD_SFU_ IncontraDati_v4_0.doc;
ICT_R2_QD_SFU_ALL_Incontra_v3_3.doc; ICT_R2_ST_SFU_SpecificheFunzionali_2007_v2_1.doc
38
INCONTRA può essere suddiviso in due grandi blocchi, Incontra e Incontra TDI
entrambi divisi a loro volta in Incontra dati e Incontra Fonia , e Incontra TDI Dati e
Incontra TDI Fonia. Dal punto di vista hardware sono formati da tre componenti, due
data base oracle, Adapter e Storico che sono condivisi da entrambi i blocchi; e Qualità
che è il nucleo del sistema, sviluppato in SAS per Incontra e in Java per Incontra TDI.
Adapter è formato da un bus di trasferimento (TIBCO) per comunicare con Customer
Relationship Management (CRM) e OM/Rete che è la piattaforma Telecom, gestita con
Sibel, che registra i dati anagrafici dei clienti. Il canale di comunicazione è
bidirezionale, per permettere lo scambio di messaggi durante l’esecuzione dei processi
Order to Delivery con i sistemi CRM e OM/Rete. In caso di valore non ammesso per
entrambi i domini verrà attivato un processo di Eccezione.
Adapter è un vero e proprio data base Oracle, costituito da diverse tabelle per la parte
Fonia e per la parte TDI. In più è presente un ulteriore schema, contenenti le “tabelle di
frontiera” ( Qualità_Adapter), nato per ovviare il problema dell’assenza di un DB per
Qualità. La struttura del DB è cosi suddivisa:
-
OKQLD sia per dati che per fonia
-
KOQLD sia per dati che per fonia
-
RICHIESTE sia per dati che per fonia
Sulle OK CRM pubblica gli SO, i quali vengono acquisiti da Qualità che effettua i
controlli e in caso di risultato positivo li va a scrivere sulle tabelle di staging (tabelle di
appoggio sulle quali qualità prepara i dati che verranno copiati nelle tabelle di storico)
sullo STORICO, in caso errato viene inserito il record sulla KO. Da qui parte una
richiesta (resync) verso CRM, pubblicando sulla RICHIESTE il record, in modo tale da
permettere a CRM di poter rispondere al resync, pubblicando nuovamente la
lavorazione ovviando agli errori.
Qualità è visto dal Collaudo come una scatola nera, infatti essendo sviluppata in SAS o
in Java non da la possibilità di effettuare i controlli come si potrebbe fare con
ADAPTER e STORICO mediante semplici query. QUALITA’ lavora tutte i SO
presenti nelle OK con stato a ‘P’, e in base a determinati controlli logici e referenziali (i
controlli sintattici/semantici vengono effettuati già dall’Adapter), li smista sulle varie
tabelle di staging o sulle KO.
39
Una volta pubblicate le lavorazioni sulle tabelle di staging è tutto pronto per
l’inserimento sullo Storico, che fa una vera e propria copia delle staging sulle sue
tabelle effettuando schiacciamenti, aggregazioni, scarti e sospensioni.
Storico è composto da un DB Oracle strutturato su uno schema, contenente varie tabelle
distinte per Incontra e Incontra TDI, e la componente che interagisce con i sistemi a
valle (PP,OT), in quanto è storico che effettua gli scarichi che poi vengono passati via
FTP verso i sistemi a valle.
3.3 Adapter
ADAPTER si occupa dello scambio di messaggi con CRM.
La pubblicazione delle consistenze avverrà su CIM differenti attraverso Service Order,
Eventi, Resync.
I Service Order/Eventi/Resync inviati dalle piattaforme di commercializzazione, CRMR
(piattaforma residenziale) e CRMB (piattaforma Business), verranno pubblicati su bus
TIBCO a più isole da BPM, la pubblicazione avviene in maniera differente per le
diverse nature dei dati e delle interfacce : FONIA e DATI.
Gli stati previsti sono di seguito riassunti :
•
EMESSO - Richiesta di attivazione di una nuova configurazione del Servizio
•
ESPLETATO TECNICAMENTE – Stato impostato a seguito della risposta di
attivazione tecnica da parte di Rete
•
ATTIVO – Stato impostato a seguito della risposta dalla procedura ARBOR
•
CESSATO
•
ANNULLATO - Annullamento della richiesta di attivazione della nuova
– Espletamento della emissione di cessazione
configurazione del Servizio
•
ESPLETATO PARZIALE - Richiesta di attivazione/variazione/cessazione di
una nuova configurazione del Servizio
L’ADAPTER di INCONTRA, intercetta i messaggi, filtra i messaggi che non risultano
di competenza dell’isola, effettua i controlli sintattici e formali sui dati precedentemente
40
identificati, filtra i dati non d’interesse dell’isola,modella i dati corretti in formato CIM
INCONTRA, passa i dati corretti alla procedura di QUALITA’ Dati che si occuperà di
verificare la corretta sequenza logica del SO/Evento inviato e la sua consistenza nella
base dati storico, invia richieste di correzione e rinvio Adjustment/Resync a CRM.
Qualità Dati, una volta validato e arricchito il Service Order con i dati Storici e con le
informazioni proveniente da altri sistemi (LIDO per ADSL, ACL/RC per CPS…),
inserirà i dati in tabelle Oracle di Staging; i dati considerati validi verranno presi in
incarico dallo STORICO INCONTRA e inseriti nelle relative tabelle storiche.
Solo a questo punto il sistema è pronto a inviare, tramite opportune shell, le consistenze ai
sistemi PP e OT.
Di seguito l’elenco delle tabelle utilizzate ADAPTER:
Nome fisico tabella
AD_DATI_EVENTI
Descrizione
Tabella degli eventi ricevuti ricevuti da BPM
AD_DATI_KOQLD
Tabella dei Resync inseriti da QD
AD_DATI_MESSAGGI
Tabella dei messaggi ricevuti da BPM
AD_DATI_RICHIESTE
Tabella delle richieste inoltrate a BPM
AD_DATI_SERVICE_ORDER
Tabella dei SO ricevuti da BPM
AD_DATI_OKQLD
Tabella degli OK inviati a QD
AD_DATI_SCARTI
Tabella degli scarti
AD_DATI_LOG
Tabella di log
AD_FONIA_EVENTI
Tabella degli eventi ricevuti ricevuti da BPM
AD_FONIA_KOQLD
Tabella dei Resync inseriti da QD
AD_FONIA_MESSAGGI
Tabella dei messaggi ricevuti da BPM
AD_FONIA_RICHIESTE
Tabella delle richieste inoltrate a BPM
AD_FONIA_SERVICE_ORDER
Tabella dei SO ricevuti da BPM
AD_FONIA_OKQLD
Tabella degli OK inviati a QD
AD_FONIA_SCARTI
AD_FONIA_LOG
Tabella di log
AD_DT_DATI_KOQLD
Tabella dei Resync inseriti da QD per TDI
AD_DT_DATI_OKQLD
Tabella degli OK inviati a QD per TDI
AD_DT_DATI_RICHIESTE
Tabella delle richieste inoltrate a BPM per TDI
AD_DT_FONIA_KOQLD
Tabella dei Resync inseriti da QD per TDI
AD_DT_ FONIA _OKQLD
Tabella degli OK inviati a QD per TDI
AD_DT_ FONIA _RICHIESTE
Tabella delle richieste inoltrate a BPM per TDI
Tabella 1 Tabelle di Adapter
Il processo di gestione degli SO può essere schematizzato nei seguenti passi:
Attivazione sul canale d’ascolto.
Validazione attraverso schema XSD fornito.
41
Verifica SO in ambito.
Validazione CIM_SO (SO_Semplice,SO_Complesso).
Verifica SO duplicato.
Trasformazione CIM enterprise in CIM INCONTRA DATI.
Verifica richiesta in ambito.
Verifica Controlli formali.
Invio a QD.
Scrittura log riepilogativo.
3.3.1
Attivazione su canale d’ascolto
Tale attività consiste nell’ avviare tramite console TIBCO il servizio inerente i SO.
3.3.2
Validazione Envelope attraverso schema XSD fornito
Tale attività consiste nel controllo sintattico semantico (ben formato , valido) del
messaggio in formato XML ricevuto attraverso un template XSD.
In caso di errore verrà attivato un processo di eccezione verso BPM,in tal caso non
verranno inviati ulteriori messaggi da BPM verso l’sola INCONTRA fino alla
risoluzione dell’ anomalia riscontrata.
3.3.3
Verifica SO in ambito INCONTRA
Tale attività consiste nel controllare che il SO sia di competenza dell’isola INCONTRA.
In caso di errore verrà attivato un processo di eccezione verso BPM.
3.3.4
Validazione CIM_SO
Tale attività consiste nel controllo sintattico semantico (ben formato , valido) del SO in
formato XML ricevuto attraverso un template XSD .
In caso di errore verrà attivato un processo di eccezione verso BPM.
3.3.5
Verifica SO duplicato
Tale attività consiste nel controllare che non siano stati inviati all’isola INCONTRA due
o più SO identici.
42
In caso di invio ripetuto del SO verrà attivato un processo di eccezione verso BPM.
3.3.6
Trasformazione CIM enterprise in CIM INCONTRA DATI
Tale attività consiste nel filtrare i campi enterprise del SO che non interessano l’isola
INCONTRA.
3.3.7
Verifica RICHIESTA IN AMBITO
Tale attività consiste nel controllare che il TIPO_RICHIESTA sia di competenza
dell’isola INCONTRA.
La tabella riassume i valori in ambito per ADSL.
NOME CAMPO
VALORE AMMESSO
TIPO_RICHIESTA
CESSAZIONE
CAMBIO NUMERO
ATTIVAZIONE
RIATTIVAZIONE
TRASFORMAZIONE SERVIZIO
TRASLOCO (TRASLOCO CON CAMBIO NUMERO)
La tabella riassume i valori in ambito per TDI.
NOME CAMPO
VALORE AMMESSO
TIPO_RICHIESTA
ATTIVAZIONE
VARIAZIONE
CESSAZIONE
SUBENTRO ONEROSO
VOLTURA
TRASLOCO
TRASLOCO INTERNO
TRASFORMAZIONE SERVIZIO
In caso di valore non ammesso verrà attivato un processo di Inserimento scarti
3.3.8
Verifica Controlli formali
Tale attività consiste nel controllo sintattico e di dominio dei campi del CIM
INCONTRA DATI.
43
In caso di errore nei controlli verrà attivato un processo di Richiesta Adjustment verso
BPM
Non si effettuano controlli per ServiceOrder di servizi TDI
3.3.9
Invio corretti a QD
Tale attività consiste nell’inserire i SO corretti nella tabella AD_DATI_OKQLD per
servizi ADSL e
AD_DT_DATI_OKQLD per servizi TDI.
Si considerano corretti per TDI anche i msg che hanno generato richieste di adjustment.
3.3.10 crittura log riepilogativo
Tale attività consiste nello scrivere 2 file di log,uno applicativo e uno di processo.
44
3.4
Qualità SAS
Di seguito viene presentata una schematizzazione dell’architettura del sistema.
SCHEMA ARCHITETTURALE INCONTRA SAS (AS-IS)
ADAPTER
QUALITA’ DATI
ACQUISIZIONE
Qualità
OKQLD
KOQLD
RICHIESTE
FLUSSI
BATCH
SUPPORTO
CONTROLLI
Temp
STORICO
FILTRO
Scarti
ST
SG
RICREA OLAP
Olap
Figura 7 Componente Qualità di INCONTRA
45
Nel sistema QUALITA’ INCONTRA possono essere individuate le seguenti
componenti fondamentali:
• Metadata layer: questa componente costituisce il repository in cui vengono
registrati tutti i metadati utilizzati dalle componenti dell’architettura e dai
pacchetti software inclusi nella piattaforma SAS. In particolare conterranno tutte
le informazioni per:
o la connessione al DB Oracle attraverso il quale l’ADAPTER gestisce
l’invio dei SO e le richieste di resync
o i flussi bach provenienti dai sistemi:
BDA
ATOM
CRM
GATC
GSRI
o il DB interno utilizzato per la gestione dei flussi acquisiti, dei risultati e
dei log generati dai processi di controllo
o le descrizioni e documentazioni di tutti i processi di elaborazione (di
acquisizione e di controllo)
o la gestione dei profili degli utenti
• Modulo di Acquisizione: è la componente che fornisce le funzionalità per la
gestione dell’acquisizione dei dati dai sistemi sorgente.
• Modulo Controlli: è il modulo in cui vengono definite e gestite le regole di
controllo della qualità dei dati.
• Modulo di Reporting: è il modulo web che fornisce le funzionalità sia per la
creazione che per la consultazione delle informazioni sull’esito delle
elaborazioni dei flussi.
46
• Modello Dati: nel sottosistema dati vengono gestite tutte le entità dati coinvolte
nei processi di controllo della qualità dei dati. In particolare contiene:
o un sottoinsieme delle tabelle del CIM
o le tabelle per la gestione dello storico degli scarti, dei sospesi, dei log e
dei resync
o le tabelle di destinazione dei flussi
3.5
Qualità JAVA
ADAPTER
FLUSSI
BATCH
DI
RETE
OKQLD
QUALITA’ DATI
ACQUISITION
MODULE
XML EXTRACTOR
BATCH DATA
EXTRACTOR
KOQLD
DATA LOADING
APPLICATION
MODULE
CONTROLLER
SCARTI
RENDERING
STORICO
SG
PRESENTATION
MANAGER
DATA
COLLECTOR
ST
WEB LISTENER
SCARTI
SCARTI
QUALITA’
SCARTI
WEB
REPORT
VIEW
SOAP HTTP PROTOCOL
Figura 8 Componente Qualità di INCONTRA TDI
47
La tecnologia che verrà usata per sviluppare tale architettura è J2EE (Java 2 Enterprise
Edition).
Scopo l’architettura di QUALITA’ Dati sarà composta dai moduli di seguito descritti.
Acquisition Module
Sarà il modulo che si occuperà di estrarre i dati presenti sull’ADAPTER, in formato XML e di
applicare ad essi i controlli formali prima di renderli disponibili all’Application Module. Sarà
composto dai seguenti tre sotto moduli:
XML Extractor: questo modulo sarà in grado di rilevare, attraverso un listener,
l’inserimento di nuovi SO sull’ADAPTER e di acquisire gli XML, ad essi relativi, subito
dopo il loro inserimento in base dati, prendendo i dati necessari da passare al modulo
successivo;
XML Creation: sarà il modulo che si occuperà di creare il nuovo XML in base alle
regole dettate da un XSD progettato in maniera distinta per ogni macro famiglia (tipo
traffico), contenente i TAG di interesse. La costruzione del nuovo XML, verrà effettuata
mediante una istanza ad una classe java diversa a seconda del tipo traffico;
XML Parser: sarà il modulo che si occuperà di validare l’XML e fare i primi controlli
formali (obbligatorietà e di dominio) sui dati, per poi inviarli all’Application Module che
applicherà i restanti Controlli, facendo resync per invariante sulla catene di interesse, li
dove questi controlli fallissero.
Application Module
Sarà il modulo che si occuperà di fare i controlli semantici, sintattici e logici, e inserirà i dati
normalizzati nelle tabelle di Staging di STORICO. Sarà composto dai seguenti due moduli:
Controller: sarà il modulo che effettuerà tutti i controlli semantici, sintattici, di sequenza
e logici per garantire la qualità del dato nella base dati di destinazione;
Rendering: sarà il modulo che riceverà i dati controllati dal Controller e che attraverso
delle regole, inserirà gli stessi nelle tabelle di scarto, se il controllo non ha avuto esito
positivo, o di staging, se il controllo ha avuto esito positivo o nella tabella KOQLD
dell’ADAPTER, se il controllo ha causato la generazione di un resync.
48
Presentation Manager
Sarà il modulo che si occuperà di raccogliere i dati che saranno oggetto di scarto sui tre
moduli del sistema INCONTRA (ADAPTER, QUALITA’ DATI e STORICO) e li
assemblerà per il successivo passaggio degli stessi al modulo Web Report View. Sarà
composto dai seguenti sotto moduli:
Data Collector: sarà il modulo che, a seguito di una richiesta del Web Listener,
raccoglierà i dati, li elaborerà e li inserirà in un XML per permettere la lettura dei
dati al modulo web listener;
Web Listener: sarà il modulo che si occuperà di effettuare le richieste al Data
Collector e dopo aver ricevuto l’XML in risposta, contenente i dati richiesti, e
passerà l’XML così composto al modulo web report view.
Web Report View
Sarà il modulo che si occuperà della visualizzazione dei dati raccolti e assemblati dal
modulo Presentation Manager per la loro visualizzazione attraverso dei Report che
saranno pubblicati sul WEB.
49
3.6
STORICO
CRM R /B
CIM/FONIA
CIM/DATI
E-FOUNDATION
Adapter
INCONTRA
CONTROLLO
QUALITA’ DATI
INCONTRA
STORICO
Figura 9 Componente Storico di INCONTRA
L’ADAPTER di INCONTRA, nel catturare i messaggi, effettua dei controlli sintattici e
semantici sui dati dando un primo livello di certificazione strutturale e formale del
50
Service Order inviato e passa i dati corretti alla procedura di QUALITA’ Dati che si
occuperà di verificare la corretta sequenza logica del SO inviato e la sua consistenza
nella base dati storico mentre per i dati scorretti richiede tramite E-Fondation
un’operazione di adjustement a CRM.
QUALITA’ Dati una volta validato e arricchito il Service Order con i dati Storici e con
le informazioni proveniente da altri sistemi (per ADSL, ACL/RC per CPS…) inserirà i
dati in tabelle Oracle di Staging, i dati considerati validi verranno presi in incarico dallo
STORICO INCONTRA e inseriti nelle relative tabelle storiche, di conseguenza nello
STORICO INCONTRA saranno presenti tabelle temporanee di Staging riconoscibili da
suffisso ‘SG_’, tabelle storiche con suffisso ‘ST_’ , tabelle anagrafiche con suffisso
‘ANA_’ e tabelle tecniche con suffisso ‘TC_’.
Di seguito l’elenco delle tabelle:
Tipologia
Nome fisico tabella
Descrizione
Staging
SG_CONS_INCONTRA_TP
Tabella di Staging per Consistenza Telefonia Pubblica
Staging
SG_CONS_CPSNP
Tabella di Staging per associazione commerciale e tecnica per Carrier Pre Selection e Number Portabilità
Staging
SG_CONS_INCONTRA
Tabella di Staging per Consistenza Cliente
Staging
SG_CONS_ADSL_COMM
Tabella di Staging per il caricamento giornaliero da Qualità Dati della parte ADSL commerciale
Staging
SG_CIM_FONIA
Tabella di Staging per CIM Fonia da E-Foundation
Staging
SG_CIM_FONIA_AGGIUNTIVI
Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione degli aggiuntivi della linea
Staging
SG_CIM_FONIA_CIC
Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione dei CIC della linea
Staging
SG_CIM_FONIA_FITTIZI
Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione dei fittizi della linea
SG_CIM_FONIA_SVZ_AGGIUNTIVO Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione delle forniture per l’identificazione
della tipologia di ADSL
Staging
Staging
SG_CIM_FONIA_LINEA
Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione della linea telefonica old e new
Staging
SG_CIM_DATI
Tabella di Staging per CIM Dati da E-Foundation
Staging
SG_CIM_ DATI _AGGIUNTIVI
Tabella di Staging per CIM Dati da E-Foundation per la memorizzazione degli aggiuntivi della linea
Staging
SG_CIM_ DATI _FITTIZI
Tabella di Staging per CIM Dati da E-Foundation per la memorizzazione dei fittizi della linea
Staging
SG_CIM_ DATI _LINEA
Tabella di Staging per CIM Dati da E-Foundation per la memorizzazione della linea telefonica old e new
SG_CIM_DATI_SVZ_AGGIUNTIVO
Staging
Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione delle forniture per l’identificazione
Staging
SG_CIM_DATI_CIC
Tabella di Staging per CIM Dati da E-Foundation per la memorizzazione dei CIC della linea
Staging
SG_CIM_DATI_GUIDING
Tabella di Staging per Cim Dati da E-Foundation per la memorizzaione dei Guiding
Staging
SG_CLIENTE
Tabella di Staging per CIM Dati e CIM Fonia da E.Foundation per la memorizzazione dell’anagrafica Cliente.
SG_SEDE
Staging
Storico
ST_CONS_INCONTRA
Tabella Storico di INCONTRA per la consistenza cliente
ST_CONS_INCONTRA_DELETE
Tabella Storico di INCONTRA dove vengono spostate le occorrenze cancellate dalla tabella
ST_CONS_INCONTRA
Storico
Storico
Tabella di Staging per CIM Dati e Cim Fonia da E-Foundation per la memorizzazione dell’anagrafica della
Sede.
ST_CONS_CPSNP
Tabella Storico per associazione commerciale e tecnica per ADSL e WI-FI Alice Voice
51
Tipologia
Nome fisico tabella
Descrizione
Storico
ST_CONS_ADSL_COMM
Tabella storico per la memorizzazione della parte ADSL commerciale
Storico
ST_CONS_ADSL_COMM_DELETE
Tabella di Storico dove vengono spostate le cancellazioni dell’associativa ST_CONS_ADSL_COMM
Storico
ST_CONS_RESYNC
Storico
ST_CONS_EMESSI
Tabella Storico per la memorizzazione degli Emessi (Delivery Emessi)
Storico
ST_CONS_ESPLETATI
Tabella Storico per la memorizzazione degli Emessi Espletati (Delivery Emessi)
Storico
ST_GACT
Tabella Storico per GACT (Gestione Carte Telefoniche)
Storico
ST_GSRI_PIN
Tabella Storico per Sistemi di Rete Intelligenti per PIN
Storico
ST_GSRI_CLI
Tabella Storico per Sistemi di Rete Intelligenti per CLI
Storico
ST_GSRI_GNR
Tabella Storico per Sistemi di Rete Intelligenti per GNR
Storico
ST_CIM_DATI
Tabella di Storico per CIM Dati da E-Foundation
Storico
ST_CIM_DATI_AGGIUNTIVI
Tabella di Storico per CIM Dati da E-Foundation per la memorizzazione degli aggiuntivi della linea
Storico
ST_CIM_DATI_FITTIZI
Tabella di Storico per CIM Dati da E-Foundation per la memorizzazione dei fittizi della linea
Storico
ST_CIM_DATI_LINEA
Tabella Storico per CIM Dati da E-Foundation per la memorizzazione della linea telefonica old e new
ST_CIM_DATI_SVZ_AGGIUNTIVO
Tabella di Storico per CIM Dati da E-Foundation per la memorizzazione delle forniture per l’identificazione
Staging
Staging
ST_CIM_DATI_CIC
Tabella di Storico per CIM Dati da E-Foundation per la memorizzazione dei CIC della linea
Staging
ST_CIM_DATI_GUIDING
Tabella di Storico per Cim Dati da E-Foundation per la memorizzaione dei Guidino
Storico
ST_CIM_FONIA
Tabella di Storico per CIM Fonia da E-Foundation
Storico
ST_CIM_FONIA_AGGIUNTIVI
Tabella di Storico per CIM Fonia da E-Foundation per la memorizzazione degli aggiuntivi della linea
Storico
ST_CIM_FONIA_CIC
Tabella di Storico per CIM Fonia da E-Foundation per la memorizzazione dei CIC della linea
Storico
ST_CIM_FONIA_FITTIZI
Tabella di Storico per CIM Fonia da E-Foundation per la memorizzazione dei fittizi della linea
Storico
ST_CIM_FONIA_LINEA
Tabella di Storico per CIM Fonia da E-Foundation per la memorizzazione della linea telefonica old e new
ST_CIM_FONIA_SVZ_AGGIUNTIVO Tabella di Staging per CIM Fonia da E-Foundation per la memorizzazione delle forniture per l’identificazione
Storico
Anagrafiche
ANA_CLIENTE
Anagrafica Cliente
Anagrafiche
ANA_SEDE
Anagrafica Sede
Tecniche
TC_LOG_PROCESSI
Tabella tecnica per la gestione delle LOG delle procedure
Tecniche
TC_SCARTI
Tabella 2 Tabelle Storico
Possiamo distinguere due tipi di caricamento per lo STORICO di INCONTRA:
-
Caricamento iniziale
-
Caricamento giornaliero
La fase del caricamento iniziale (Start-up della procedura) delle basi dati prevede il
caricamento dal vecchio ambiente INCONTRA alimentato dall’interfaccia BDA per le
componenti Consistenza Cliente (XE_DOCAD), ADSL (XE_ASTCM) e Carrier Pre
Selection e Number portabilità (XE_CPSNP) e consistenza carte telefoniche (GACT).
52
Il caricamento giornaliero prevede l’esecuzione di una fase batch serale durante la quale
verranno estratte le diverse consistenze, da aree di appoggio, precedentemente infasate
dalla procedura di Qualità Dati.
3.7
STRATEGIA DI COLLAUDO
Elencherò passo per passo tutti gli step da seguire per portare a termine un collaudo
funzionale nell’ambiente USAGE per il sistema INCONTRA, differenziato per le
catene dati che scendono on-line tramite bus su ADAPTER, e quelle che arrivano bach
direttamente su STORICO.
3.7.1 ON-LINE
I passi da seguire per realizzare un collaudo nell’ambiente INCONTRA per la parte
ON-LINE
sono :
-- Scegliere dalle tabelle OKQLD di ADAPTER tutti gli invarianti avente
famiglia_servizio = famiglia servizio da collaudare, dando priorità all'acquisizione di
servizi che appartengono alla famiglia servizio in esame.
-- Acquisire anche i servizi appartenente alle altre famiglie servizio e verificare la loro
correttezza.
-- Acquisire anche le lavorazioni che appartengono a servizi diversi, per verificare la
corretta acquisizione.
-- Elaborare stato per stato tutte le lavorazioni nel seguente modo :
EMESSO
---> fino a STORICO
ESPLETATO ---> fino a STORICO
53
Questo vale per tutti i tipi di lavorazione, dove previsto l'emesso. Nel caso in cui ci sia
solo l'espletato, acquisire solo l'espletato.
Storicizzare sempre i dati e di verificare la completezza e la consistenza dei dati in tutte
le tabelle.
-- Prevedere l'estrazione per PP.
-- Per verificare quali sono le condizioni di valorizzazione della tabella far riferimento
alle specifiche.
-- Verificare anche il canale resync per le lavorazioni sia oggetto di collaudo e non.
-- Prevedere un regration test.
-- Prevedere anche un acquisizione massiva dei dati.
-- Provare tutte le shell di qualità ( Ripartenze ,resync, etc......).
54
3.7.2 BATCH
I passi da seguire per realizzare un collaudo nell’ambiente INCONTRA per la parte
BATCH sono :
-- Creazione dei flussi tramite un simulatore, in quanto per motivi di sicurezza non
possiamo accedere ai file reali.
-- Acquisire i file creati tramite simulatore allo step precedente.
-- Verificare la corretta valorizzazione dei campi delle tabelle, facendo riferimento alle
specifiche funzionali legate al rilascio software.
-- Prevedere uno scarico verso PP e dove opportuno per OT
-- Prevedere un regration test.
-- Prevedere anche un acquisizione massiva dei dati
-- Provare tutte le shell di qualità ( Ripartenze ,resync, etc......)
55
Capitolo 4
(5)
STRUMENTI UTILIZZATI
4.1 Introduzione
In ambiente Telecom il collaudo viene gestito e monitorato da particolari strumenti, che
sono entrati in uso da 1 gennaio 2007, cioè da quando è stata fatta l’aggregazione con
TIM, infatti tali strumenti sono stati importati dal collaudo TIM.
I più importanti sono :
-
Infodelivery
-
PVCS
Infodelivery è lo strumento in cui vengono pubblicate le documentazioni (proposte
implementative, specifiche funzionali, specifiche d’interfaccia), inoltre guida il collaudo
indicando date di rilascio e date di fine collaudo.
PVCS è lo strumento softaware che viene utilizzato per la comunicazione tra i vari
ambienti: sviluppo, collaudo esercizio. Infatti qui possiamo trovare rilasci software con
relativi manuali d’installazione (MIG), schede anomalia (SM), change requert (CR).
Putty, noto a tutti, è il software che ci permette di lavorare in remoto sulle macchine
telecom.
SQL navigator o TOAD sono interfacce per il client Oracle, sui quali possiamo
effettuare query e i vari controlli nelle tabelle.
FileZilla, utilizzato per il trasferimento via FTP dei File.
5: Tratto da Guida Infodelivery.doc; Metodologia SCM PVCS v30.pdf
56
Ultraedit, è un editor di scrittura, che grazie alle sue svariate funzioni, ci permette di
creare in maniera semplice e veloce traffico e di salvare direttamente via FTP sulle
macchine di collaudo.
3.8
Infodelivery
3.8.1 Introduzione
Infodelivery nasce dall’esigenza del settore TELECOM MD.BS.C di fornire uno
strumento che fosse di ausilio ai consulenti di Collaudo per standardizzare le operazioni,
ma al tempo stesso che fosse di supporto ai Program Manager di Collaudo per
monitorare lo stato di avanzamento delle Attività ( Errore. L'origine riferimento non
è stata trovata.).
Figura 10 Schematizzazione funzionale di Infodelivery
57
Come si può netare dalla figura, Infodelivery è composto da quattro profili:
-
DM
-
Sviluppo
-
Collaudo
-
PM VAS
Andiamo ora ad nalizzare singolarmente ognuno di essi, soffermandoci più
specificatamente sul Collaudo.
3.8.2
Profilo DM
Il ruolo DM può essere visto come quello dell’analisi, infatti dopo aver analizzato le
esigenze espresse, valutando se si tratta di nuove attività di sviluppo software o di
modifica di quelle preesistenti, inserisce in Infodelivery una nuova Attività, identificata
attraverso un codice univoco (codice AGESP) unitamente ad altre informazioni che
stabiliscono la priorità e i tempi di realizzazione dell’intervento. Periodicamente
Infodelivery, attraverso un meccanismo di acquisizione automatica, carica nel proprio
DB i dati di AGESP relativi alle Attività inserite e/o modificate rispetto all’ultimo
caricamento. La presenza in Infodelivery delle informazioni relative ad una nuova
Attività, dà il via al processo che vedrà coinvolti i DM, i team di Sviluppo, Collaudo ed
Esercizio che si tradurrà con la realizzazione e la messa in produzione di quanto
concordato. La pianificazione e le responsabilità di ogni fase del processo sono definite
nel Piano Centralizzato dei Rilasci di BSS che suddivide le Attività in fasi (Kit) a livello
annuale, ad esempio X1 relativo al mese di Gennaio, X2 a Febbraio e cosi via.
Il DM, una volta che l’Attività inserita su AGESP è visibile su Infodelivery, indica quali
Sistemi, tra quelli presenti, saranno coinvolti nella realizzazione.. Il DM effettua inoltre
l’upload dell’Agesp entro la data prevista dal Piano Centralizzato dei Rilasci di BSS.
Dopo l’associazione dell’Attività ai Sistemi coinvolti nel processo, ciascuno dei settori
di Sviluppo interessati inizierà le attività di propria competenza. I DM hanno completa
visibilità delle attività di Sviluppo potendone verificare l’avanzamento a livello di
coppia Attività/Sistema.
58
3.8.3
Profilo Sviluppo
Nel momento in cui il DM associa l’Attività ai Sistemi interessati, i settori di Sviluppo
avranno disponibile l’Attività nella loro “pending list” di Sistema: le attività preliminari
che dovranno svolgere riguardano la verifica dell’effettivo impatto dell’Attività sul
Sistema di cui sono referenti e la valutazione dei Requisiti. L’obiettivo sarà
principalmente quello di associare tutte le Attività all’interno di un Kit, tra quelli
disponibili, al fine di creare una lista “formale” da comunicare al settore di Collaudo.
Tale operazione dovrà essere fatta cercando di far conciliare la data prevista dal DM di
rilascio in esercizio dell’Attività con la data prevista di rilascio in esercizio dell’intero
Kit. Il processo prevede che venga inserita la documentazione prodotta dal settore di
Sviluppo, sia a livello di Kit che a livello di Attività per le categorie standard richieste
da Collaudo:
-
Requisiti
-
Specifiche
-
System Test
Dopo aver associato alla coppia Attività/Sistema un Kit scelto fra quelli disponibili, i
settori di Sviluppo potranno creare una scheda RU su PVCS.
Le altre informazioni che i settori di Sviluppo devono inserire in Infodelivery sono
relative alla Priorità e alla Complessità relativa alla coppia Attività/Sistema.
59
3.8.4
Profilo Collaudo
L’associazione di un’Attività ad un Kit, per un determinato Sistema rende disponibile
l’Attività al Collaudo per la lavorazione. Sulla base delle indicazioni presenti nella P.I.
del DM, il Collaudo dovrà rilasciare in Infodelivery la Strategia di Collaudo che
contiene le linee guida secondo cui sarà progettato il Collaudo ed il Piano di Collaudo
(prima versione) con il riferimento della pianificazione delle attività di collaudo.
Soltanto dopo la consegna della documentazione di Sviluppo (Requisiti, Specifiche,
System Test in Infodelivery), può iniziare la fase di progettazione del collaudo.
Le attività principali previste dal processo sono:
-
la redazione e rilascio in Infodelivery del Test Book contenente i CdT
(funzionali, integrati, prestazionali e di esercibilità). I CdT sono redatti dal
fornitore di Collaudo inizialmente secondo quanto indicato dalle P.I. dei DM e
quindi, per la definizione di dettaglio, in accordo con la documentazione
rilasciata da Sviluppo in Infodelivery; per la progettazione dei CdT integrati è
stato definito dal gruppo di “PMO”, interno al Collaudo (PMO), un documento
contenente le linee guida;
-
la predisposizione dell’ambiente di Collaudo (ove necessario);
-
il rilascio del Piano di Collaudo in Infodelivery in versione definitiva.
-
la verifica della copertura dei requisiti funzionali e delle specifiche tecniche da
parte dei System Test forniti da Sviluppo. Al termine di questa attività sarà
onere del Collaudo rilasciare in Infodelivery il Rapporto su copertura dei
System Test.
Il Test Book, perché si possa procedere all’esecuzione dei CdT che lo compongono,
deve essere validato dal responsabile TELECOM MD.BS.C che provvede prima alla
sua accettazione e quindi, previa verifica ed eventuale richiesta di
modifica/integrazione, alla sua validazione; Soltanto da questo momento può iniziare la
fase di collaudo vera e propria: i CdT, resi disponibili nella fase precedente con la
validazione del TB, devono essere approvati dal supervisore di Collaudo prima della
loro esecuzione. A valle di questa fase (transizione di stato dei CdT Progettati ->
Approvati) se sono disponibili il Software e la documentazione rilasciati da Sviluppo e
risultano terminate tutte le attività di predisposizione dell’ambiente, i collaudatori
60
possono eseguire i CdT del Test Book in conformità con quanto riportato nel Piano di
Collaudo (come attività preliminare, per la verifica della qualità del software
consegnato, vengono rieseguiti, a campione, una parte dei System Test consegnati da
Sviluppo, relativamente alle funzionalità principali da collaudare, e rilasciato in
Infodelivery il Rapporto di esecuzione a campione dei System Test). Il tracciamento
dell’attività di esecuzione dei CdT è gestito in Infodelivery attraverso lo storico dei
Lanci. Per ogni Lancio terminato con esito negativo, il Collaudo può segnalare
l’anomalia creando una scheda SM su PVCS. Alla fine del processo sarà cura degli
stessi collaudatori rilasciare in Infodelivery il Rapporto di Fine Collaudo e su PVCS il
software collaudato per l’installazione in Esercizio.
Per alcuni Sistemi è prevista una fase di Collaudo Utente. Le richieste di CU,
formalizzate in Infodelivery dai DM, vengono prese in carico dai PMO di Collaudo che,
dopo il consolidamento delle informazioni, notificano ai g.d.l. di Collaudo l’inizio delle
attività (Collaudo Utente nello stato In Corso). Le Segnalazioni create dal Cliente
durante la fase di esecuzione dei CdT di Cu sono prese in carico dai g.d.l di Collaudo
competenti che, coadiuvati da Sviluppo, devono analizzarne le motivazioni: nel caso si
tratti di un’anomalia, Collaudo aprirà una scheda SM su PVCS; se invece si tratta di un
nuovo requisito sarà Sviluppo ad aprire una scheda RU su PVCS.
3.9
PVCS
3.9.1 Introduzione
PVCS Dimensions è utilizzato per la gestione di tutto il ciclo degli interventi sul
software sia per malfunzionamenti segnalati dai gruppi di System Test, Esercizio o
Collaudo, sia per le nuove implementazioni segnalate dai gruppi di
Sviluppo/Design/Build in termini di:
-
tracciamento delle modifiche software assegnate ai fornitori o gruppi di
Sviluppo;
-
controllo delle operazioni di rilascio software da parte dei fornitori o
gruppi di Sviluppo sugli ambienti riservati a tale scopo;
61
-
inserimento nei repository di progetto degli oggetti software relazionati
alle schede di intervento;
-
prelievo degli oggetti software per l’installazione sugli ambienti di
System Test, Collaudo ed Esercizio;
-
In ambiente di Collaudo, qualora l’intervento sia ascrivibile a problemi
legati a componenti software, sarà possibile effettuare l’apertura di una
scheda di modifica (SM)
Mentre Infodelivery permette la comunicazione tra i diversi settori per quanto riguarda
documentazioni, specifiche e casi di test; PVCS permette di comunicare con gli altri
settori per i rilasci e le consegne software. I rilasci software vengono fatti tramite
particolari schede chiamate RIL, nelle quali è presente lo stato, la data di rilascio, il
nome della scheda, i pacchetti da installare nei vari ambienti e dove necessario anche un
MIG (manuale di installazione). Una volta installati i pacchetti si procede con il
collaudo vero e proprio, seguendo quanto pianificato in Infodelivery nei casi di test, nel
momento in cui un test non termina in maniera desiderata, Collaudo apre una scheda di
anomalia (SM), con la quale spiega a Sviluppo il problema riscontrato e rispedisce
indietro la RIL per un eventuale rilascio, con modifiche ai pacchetti per la risoluzione
del problema. Una volta terminato il test del software, entro le date previste su
Infodelivery, il Collaudo rilascia il software a Esercizio effettuando semplicemente un
cambio di stato (Passaggio in esercizio), il quale può provvedere all’installazione del
software.
62
3.9.2
RILASCI SOFTWARE (RIL)
Andiamo ad analizzare il ciclo di vita della scheda centrale di PVCS, con la quale
vengono effettuati i rilasci (RIL):
Figura 11 Ciclo di vita di una RIL
-
IN RILASCIO (stato iniziale)
Creazione ed apertura di una scheda (Change Document) per la formalizzazione
di un nuovo rilascio. Tale operazione viene effettuata dal gruppo di
Sviluppo/Design o dal Fornitore/Gruppo di Build cui è assegnato lo sviluppo del
software.
In questa fase, il FORN, effettua il rilascio del software creando i singoli file in
PVCS, aggiorna tutti gli attributi della scheda rilascio, evidenziando la
motivazione del rilascio ed inoltra la stessa nello stato successivo.
63
-
RILASCIATO
In questa fase, il Gruppo di Sviluppo/Design (SVI), effettua le dovute verifiche
formali sul contenuto del rilascio effettuato e inoltra la scheda nello stato
PASSAGGIO IN COLLAUDO per attivare le operazioni di allineamento
ambiente con il software rilasciato. La scheda può essere inoltrata nuovamente
nello stato IN RILASCIO nel caso in cui il rilascio non è conforme alle
aspettative oppure nello stato ANNULLATA nel caso in cui il rilascio non ha
più senso di esistere per varie motivazioni (sospensione delle attività).
-
PASSAGGIO IN COLLAUDO
Tale stato indica il termine di tutte le attività di verifica formale sul rilascio e la
richiesta da parte dello Sviluppo/Design di rendere disponibile al gruppo di
collaudo il software e la documentazione relativa.
In questa fase il Collaudo, effettuando l’azionamento della scheda nello stato
RILASCIATO A COLLAUDO, automaticamente effettua anche il passaggio
degli item relazionati alla scheda RIL nel workset COLL da cui potrà essere
prelevato per l’installazione degli ambienti del collaudo stesso.
-
RILASCIATO A COLLAUDO
Tale stato indica la disponibilità del rilascio per il gruppo di collaudo che può
prelevare il software per l’installazione degli ambienti runtime dal workset
COLL e dare inizio alle attività di validazione funzionale e/o prestazionale sui
componenti installati.
In questa fase, il Gruppo di Collaudo (GSC) provvederà ad inoltrare la scheda
rilascio nello stato COLLAUDO OK al termine delle attività di verifica
terminate con esito positivo o nello stato RICHIESTA REGRESSIONE nel caso
in cui si voglia annullare il rilascio effettuando una regressione del software ad
una diversa versione di quella installata (eseguibili corrotti, anomalie bloccanti,
ecc.); nello stato RESPINTA, nel caso in cui si voglia annullare il rilascio senza
effettuare una regressione sulle versioni software installate oppure nello stato
ANNULLATA nel caso in cui si voglia annullare il
rilascio.
64
-
COLLAUDO OK
Tale stato indica il termine delle attività di verifica sul rilascio relativo da parte
del gruppo di collaudo e che il software è pronto per essere rilasciato in
esercizio.
In questa fase, il Gruppo di Collaudo (GSC), dopo le opportune verifiche, inoltra
la scheda nello stato PASSAGGIO IN ESERCIZIO per notificare al gruppo di
Esercizio l’effettivo rilascio del software relativo. Nel caso in cui il rilascio
riguarda una release non ancora in esercizio, la scheda può essere azionata in
CHIUSA oppure rimanere in questo stato fino a
fine collaudo. La scheda sarà azionata dal gruppo GSC quando, a fine collaudo,
richiederà il passaggio in esercizio della nuova release. La scheda può essere
inoltrata anche nello stato ANNULLATA nel caso in cui si voglia annullare il
rilascio.
-
PASSAGGIO IN ESERCIZIO
Tale stato indica il termine di tutte le attività di verifica formale sul rilascio
effettuato e la volontà da parte del gruppo di supporto all’esercizio di consegnare
il software relativo.
In questa fase il gruppo di supporto all’Esercizio (GSE), effettuando
l’azionamento della scheda nello stato RILASCIATO A ESERCIZIO.
-
RILASCIATO A ESERCIZIO
Tale stato indica la disponibilità del rilascio per il gruppo di esercizio che può
prelevare il software per l’installazione degli ambienti runtime dal workset
CONS e dare inizio alle attività di installazione sul runtime relativo.
3.9.3
Schede anomalia (SM)
La scheda anomalia su PVCS Dimensions di tipo “SM” conterrà tutte le informazioni
utili prelevate dai malfunzionamenti rilevati negli ambienti di esercizio, necessari a
65
predisporre il tool PVCS Dimensions alla gestione dell’intervento di modifica da parte
delle linee di Sviluppo/Design
interessate, includendo il tracciamento degli eventuali interventi da parte del
fornitore/build e della linea di Collaudo che dovrà validare l’intervento prima della
installazione del software sugli ambienti di Esercizio. Lo stato della scheda SM viene
aggiornato in tempo reale sul Ticket Remedy di TSSC permettendo il tracciamento delle
fasi dell’intervento software anche alle linee di Esercizio.
Per i malfunzionamenti rilevati negli ambienti di collaudo, il gruppo relativo
formalizzerà una scheda PVCS di tipo “SM” direttamente con il client del tool oppure
tramite Infodelivery associando la stessa al caso di test gestito su quest’ultimo.
Dividiamo le schede SM per severità:
-
Bloccante di sistema
-
Bloccante di funzione
-
Media
-
Formale
Bloccante di sistema è la severità che viene assegnata ad una anomalia software che ha
generato un arresto di un processo; “processo terminato in errore”.
Bloccante di funzione viene assegnata ad un anomalia che ha causato un
malfunzionamento che impedisce di continuare i test; “processo terminato
correttamente, ma non compie le proprie funzionalità in maniera adeguata”.
Media, tale severità viene assegnata quando l’anomalia riscontrata riguarda un
malfunzionamento che non è bloccante per il proseguimento del collaudo; “processo
terminato senza errore, ma con qualche piccola imprecisione”.
Formale, si assegna tale severità quando ci sono incompatibilità lievi tra il software e le
specifiche, tipo errata valorizzazione di campi o domini errati: “processo terminato
correttamente, con piccole imperfezioni tra la funzionalità del software e quanto
indicato nelle specifiche” .
66
Analizzando nel particolare il ciclo di vita di una scheda SM:
Figura 12 Ciclo di vita di una SM
-
APERTA (STATO INIZIALE)
Creazione ed apertura di una scheda per la formalizzazione di un
malfunzionamento rilevato in fase di Collaudo o di Esercizio. Tale operazione
è effettuata dal Gruppo di Supporto Collaudo (GSC) nel primo caso o dal
Gruppo di Supporto all’Esercizio nel secondo. In questa fase la scheda è in
carico al gruppo SVI che effettua una analisi della modifica da effettuare e, nel
caso sia accettata, passa la scheda stessa nello stato ASSEGNATA per avviare le
operazioni di implementazione software.
Nel caso di malfunzionamenti di Collaudo, obbligatoriamente la scheda deve
essere associata ad un KIT, ad un’attività ed ad un Codice di Test messo
precedentemente in KO con la valorizzazione degli attributi “Codice KIT”,
“Codice Attività” (AGESP) e “Codice Test”.
67
-
ASSEGNATA
Tale stato indica l’inizio delle attività di modifica software da parte degli
sviluppatori del Fornitore o del gruppo di Codifica/Build interno. Al
completamento di tutte le attività di realizzazione e test unitario viene
formalizzato il rilascio del software attraverso l’apertura della scheda RIL alla
quale relazionare tutto il software rilasciato e tutte le schede SM oggetto del
rilascio. Infine la scheda SM deve essere posta nello stato RISOLTA.
-
RISOLTA
Tale stato indica che sono terminate le attività di rilascio e tutto il software
rilasciato è presente in PVCS Dimensions ed è disponibile per le operazioni
di installazione e verifica. In questa fase, il rilascio software correlato alla SM
viene verificato formalmente prima dal gruppo SVI e poi funzionalmente dal
gruppo di collaudo GSC, in entrambi i casi potrebbe essere rifiutato, in questo
caso la scheda SM sarà riportata allo stato precedente. Nel caso in cui la
risoluzione dell’anomalia non sia più utile, la scheda può essere azionata nello
stato ANNULLATA. Se invece il rilascio software supera le verifiche, il gruppo
di collaudo (GSC) inoltra la scheda nello stato CHIUSA.
-
CHIUSA
Tale stato indica la fine di tutte le attività di validazione funzionale in ambiente
di Collaudo per il malfunzionamento riscontrato.
68
Conclusioni
Il lavoro svolto in questi mesi, destinato alla clientela Telecom Italia, è stato frutto di
un’ intensa collaborazione fra i membri del gruppo di lavoro Accenture-Unlimited
Software.
La comprensione da parte mia della filosofia della fase di collaudo, mi ha permesso di
comprendere e condividere le ragioni su cui si basa la progettazione software all’interno
dell’azienda..
L’ ambiente di lavoro che mi ha visto impegnato durante il tirocinio, mi ha permesso di
affrontare le problematiche di gestione anomalie e di pianificazione dei test, con una
prospettiva diversa basata sull’ analisi e sullo studio di esse, cercando di trarre
conclusioni sulle loro possibili evoluzioni.
Nel corso del lavoro mi è diventato evidente, quanto sia di aiuto, per una realtà
aziendale di medio e grandi dimensioni, l’uso di strumenti software sviluppati per
facilitare le comunicazioni tra vari team che presiedono alle differenti fasi del ciclo di
rilascio software a favore del cliente Esercizio.
La crescita delle mie conoscenze tecniche mi pone, ora, in uno stato di maggiore
consapevolezza all’affrontare progetti di sviluppo di sistemi informatici complessi.
69
Un ringraziamento speciale al mio docente universitario
Eliana Minicozzi che mi ha offerto validissime direttive
nelle stesura della tesi. Inoltre ringrazio affettuosamente il
mio tutor aziendale e tutti i mie colleghi del team che mi
hanno seguito durante il tirocinio. Soprattutto un
caloroso grazie a tutti i colleghi di Mestre che mi hanno
accolto in maniera fantastica facendomi stare a mio
agio per tutta la durata della trasferta. Grazie
70

FACOLTA` DI SCIENZE MM.FF.NN CORSO DI LAUREA IN

Transcript

Documenti analoghi

Collaudo e Qualità del Software

Sovraccarico_ Compressori.pub - IRS

Sistema collaudo automatico di lavatrici e lavasciuga

1.67 MB - PROXIMA srl

BH-C - BATTERIE ELETTRICHE PER IL RISCALDAMENTO DELL

Sviluppa e distribuisce apparecchiature per il collaudo di disposi vi

come viene realizzato il design di un sito web?

Specialista integrazione e collaudo software

Completamento infrastruttura rete lan/wLan

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI