3. Livelli di servizio specifici
3.1 Sviluppo e Manutenzione
Di seguito sono elencati i livelli di servizio specifici per le macro classi di fornitura Sviluppo e Manutenzione.
In tutti gli indicatori relativi alla macro classe di fornitura Sviluppo per i quali sarà fornita una doppia segnalazione di livelli di soglia – in giorni persona e in function point – si utilizzerà un fattore di conversione (produttività) derivato dal database ISBSG versione 11 che, in base ad un’analisi di regressione statistica centrata sulle dimensioni medie attese per tipo di intervento e considerato il mix di attività di sviluppo e manutenzione evolutiva di Lombardia Informatica S.p.A., fornisce il valore medio di 1,2 giorni persona per function point.
Si precisa che il fattore di conversione sarà utilizzato soltanto relativamente ai livelli di servizio ed esclusivamente al fine di consentire la valorizzazione degli indicatori.
Di seguito:
per “Malfunzionamento” si intende un impedimento all’esecuzione del software o il riscontro
di differenze fra l’effettivo funzionamento del software applicativo e quello atteso, come previsto dalla relativa documentazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente
per “Difetto” si intende un malfunzionamento presente nel software, rilevato durante la fase di accettazione e integrazione tecnica;
per “Anomalia” si intende un malfunzionamento presente nel software, rilevato in esercizio.
Le unità che si considerano come singoli difetti e anomalie sono l’elemento funzione e l’elemento dato che sono inseriti nel sistema di tracciamento dal Fornitore all’atto della risoluzione del malfunzionamento.
Per la misura degli Indicatori di qualità che si riferiscono al codice sviluppato (LSS_SM4, LSS_SM5, LSS_SM6, LSS_SM7, LSS_SM8 e LSS_SM9), LI ora utilizza come strumento la suite SONAR (LI si riserva nel tempo di adottare strumenti differenti). I risultati attesi di questi indicatori, sono applicati ai soli interventi di sviluppo e manutenzione riguardante software realizzato nel corso dell’appalto.
Per il software già esistente alla stipula del contratto, sarà:
eseguita una misurazione iniziale per ognuno degli indicatori (baseline)
a ogni intervento di sviluppo e manutenzione, saranno rilevati tali indicatori
sarà verificato che il loro valore non indichi una qualità inferiore alla baseline
qualora ciò occorra, saranno applicate le relative sanzioni.
LSS_SM1–MALFUNZIONAMENTI IN ACCETTAZIONE E INTEGRAZIONE TECNICA
Descrizione
Rapporto tra il numero di difetti relativi a tutte le categorie di malfunzionamento, emerse durante la fase di accettazione e integrazione tecnica e il volume dell’intervento, misurato in FP (o GGPP convertiti in FP) risultante dalla documentazione rilasciata dal Fornitore al termine della fase di realizzazione.
Unità di misura Difetti per FP (numero)
Periodo di riferimento
La fase di accettazione e integrazione tecnica
Frequenza di misurazione
Al termine della fase di accettazione e integrazione tecnica
Dati da rilevare
Numero totale di difetti (segnalati sul sistema di tracciamento) rilevati durante la fase di accettazione e integrazione tecnica (Ndifetti)
Numero di FP dell’intervento (o giorni persona convertiti in FP) (Nfp)
Formula
Risultati Attesi
(valore soglia)
Sanzione Penale
Note Qualora l’intervento preveda più fasi di accettazione e integrazione tecnica, in ragione di differenti deliverables, si conteggia la somma di tutti i difetti riscontrati
LSS_SM2–COPERTURA TEST AUTOMATICO
Descrizione Percentuale di test automatizzati
Unità di misura Numero di test (percentuale)
Periodo di riferimento
La fase di accettazione e integrazione tecnica
Frequenza di misurazione
Al termine della fase di accettazione e integrazione tecnica
Dati da rilevare Numero totale di casi di test presenti nel piano di test (Ntest)
Numero di casi di test automatizzati presenti nel piano di test (Nauto)
Formula
Risultati Attesi
(valore soglia)
Sanzione Penale
Note
Qualora l’intervento preveda più fasi di accettazione e integrazione tecnica, in ragione di differenti deliverables, si conteggia la somma di tutti i casi di test e di tutti i casi di test automatici.
Sono esclusi dal rispetto del valore di soglia gli interventi di sviluppo di universi e report realizzati con Business Object.
LSS_SM3–TEMPESTIVITÀ DELLA RISOLUZIONE DI DIFETTI RILEVATI IN ACCETTAZIONE E INTEGRAZIONE TECNICA
Descrizione
Durante la fase di accettazione e integrazione tecnica di ogni intervento, le attività per la risoluzione di difetti presenti nel software applicativo avranno una durata massima definita da LI in funzione del tipo di malfunzionamento.
Unità di misura Giorni lavorativi (numero)
Periodo di riferimento
La fase di accettazione e integrazione tecnica
Frequenza di misurazione
Al termine della fase di accettazione e integrazione tecnica
Dati da rilevare
Per ogni difetto:
Avvio del processo di risoluzione del difetto: Data, ora e minuti registrati nel sistema SGF, da parte di LI, della richiesta di intervento (Dinizio)
Rilascio della risoluzione del difetto: Data, ora e minuti registrati nel sistema SGF che l’intervento è stato completato (realizzato, testato e consegnato a LI)
(Drilascio)
Tempo di sospensione della risoluzione del difetto a causa dell’indisponibilità dell’ambiente di correzione o per ragioni non imputabili al Fornitore (Tsospensione)
Formula
Al fine di regolamentarne i livelli di servizio, i malfunzionamenti sono classificati in quattro categorie la cui definizione è inserita al paragrafo 5.3.2.1. del Capitolato Tecnico Lotto 3 e Lotto 4.
LSS-SM4-DENSITÀ DEI COMMENTI DEL SOFTWARE SVILUPPATO
Descrizione Rapporto fra il numero di righe di commento e il numero di righe di codice.
I commenti dovranno essere facilmente isolabili dalle istruzioni. Si precisa che non
sono considerati commenti le linee blank e le eventuali righe con contenuto non significativo (tratteggi, caratteri di spaziature, ecc.).
Unità di misura Numero di righe (percentuale)
Periodo di
misurazione Al termine del periodo di riferimento
Dati da rilevare
Qualora l’intervento includa l’uso di più linguaggi, l’indicatore va applicato separatamente al codice sviluppato in ogni singolo linguaggio.
Qualora l’intervento preveda più fasi di realizzazione e test del software, in ragione di differenti deliverables, l’indicatore va applicato a ogni singola fase.
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.
LSS-SM5–DENSITÀ DI CODICE DUPLICATO PRESENTE NEL SOFTWARE SVILUPPATO
Descrizione Rapporto fra il numero di righe di codice duplicato e il numero di righe di codice.
Unità di misura Numero di righe (percentuale)
Periodo di
misurazione Al termine del periodo di riferimento
Dati da rilevare Numero di linee di codice duplicate (Ndupl)
Numero di linee di codice (Ncod)
Formula
Risultati Attesi
(valore soglia)
Sanzione Penale
Note
Qualora l’intervento includa l’uso di più linguaggi, l’indicatore va applicato separatamente al codice sviluppato in ogni singolo linguaggio.
Qualora l’intervento preveda più fasi di realizzazione e test del software, in ragione di differenti deliverables, l’indicatore va applicato a ogni singola fase.
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.
LSS-SM6–DENSITÀ DELLE API PUBBLICHE DOCUMENTATE
Descrizione Rapporto fra il numero di API pubbliche documentate e il numero di API pubbliche totali.
Unità di misura Numero di API pubbliche (percentuale)
Periodo di riferimento
Durata della fase di realizzazione e test del software
Frequenza di
misurazione Al termine del periodo di riferimento
Dati da rilevare Numero di API pubbliche non documentate (Nndoc)
Numero di API pubbliche presenti (Npubapi)
Formula
Risultati Attesi
(valore soglia)
Sanzione Penale
Note
Qualora l’intervento includa l’uso di più linguaggi, l’indicatore va applicato separatamente al codice sviluppato in ogni singolo linguaggio.
Qualora l’intervento preveda più fasi di realizzazione e test del software, in ragione di differenti deliverables, l’indicatore va applicato a ogni singola fase.
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.
I seguenti Livelli di Servizio sono specifici per gli interventi sviluppati in modalità object oriented:
LSS-SM7–METODI IMPLEMENTATI IN UNA CLASSE
Descrizione
Numero di metodi per singola classe.
Questa metrica va applicata ad ogni Classe dell’intervento ed effettua il conteggio dei metodi che è una prima misura della complessità di una Classe. Troppi metodi
rendono la Classe di difficile comprensione e incrementano il rischio di errori a fronte di una modifica.
Unità di misura Numero dei Metodi implementati in una Classe (numero)
Periodo di
misurazione Al termine del periodo di riferimento
Dati da rilevare Numero dei Metodi della Classe (Nmetodi)
Formula
Risultati Attesi
(valore soglia)
Sanzione Un rilievo sull’intervento se contemporaneamente non viene rispettato il valore di soglia degli indicatori di qualità LSS-SM7 e LSS-SM9
Note
Nel conteggio dei metodi non sono considerati i getter e setter, cioè quei metodi utilizzati per leggere e scrivere le proprietà di una classe
Qualora l’intervento includa l’uso di più linguaggi, l’indicatore va applicato separatamente al codice sviluppato in ogni singolo linguaggio.
Qualora l’intervento preveda più fasi di realizzazione e test del software, in ragione di differenti deliverables, l’indicatore va applicato a ogni singola fase.
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.
LSS-SM8–LINEE DI CODICE IMPLEMENTATE IN UN METODO
Descrizione
Numero di righe di codice per singolo metodo.
Questa metrica va applicata ad ogni metodo di ogni Classe dell’intervento ed effettua il conteggio delle righe di codice applicando l’algoritmo NCSS (Non Commenting Source Statements). Questa metrica è un indicatore di complessità della Classe in quanto troppe righe di codice rendono la Classe di difficile comprensione e incrementano il rischio di errori a fronte di una modifica.
Unità di misura Numero di righe di codice implementate in un metodo (numero)
misurazione Al termine del periodo di riferimento
Dati da rilevare Numero di righe di codice presenti nel metodo (Nmetcod)
Formula
Risultati Attesi
(valore soglia)
Azioni contrattuali
Un rilievo sull’intervento se contemporaneamente non viene rispettato il valore di soglia degli indicatori di qualità LSS-SM8 e LSS-SM9
Note
Sono escluse dal rispetto del valore di soglia le seguenti tipologie di classi sviluppate in linguaggio Java:
Classi utilizzate per la generazione dei file pdf
Qualora l’intervento includa l’uso di più linguaggi, l’indicatore va applicato separatamente al codice sviluppato in ogni singolo linguaggio.
Qualora l’intervento preveda più fasi di realizzazione e test del software, in ragione di differenti deliverables, l’indicatore va applicato a ogni singola fase.
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.
LSS-SM9–COMPLESSITÀ CICLOMATICA DI UNA CLASSE
Descrizione
Valore della complessità ciclomatica.
Questa metrica va applicata ad ogni Classe dell’intervento e quantifica l’effettiva misura della dimensione funzionale espressa tramite la somma dei cammini linearmente indipendenti di tutti i moduli in essa implementati.
Unità di misura Numero di cammini ciclomatici
Periodo di
misurazione Al termine del periodo di riferimento
Dati da rilevare Numero dei cammini ciclomatici (o linearmente indipendenti) (Vg)
Numero di metodi di una classe (Nmetodi)
Formula
Si applica a tutti i metodi della classe.
Sono escluse dal rispetto del valore di soglia le seguenti tipologie di classi sviluppate in linguaggio Java:
Classi utilizzate per la generazione dei file pdf
Qualora l’intervento includa l’uso di più linguaggi, l’indicatore va applicato separatamente al codice sviluppato in ogni singolo linguaggio.
Qualora l’intervento preveda più fasi di realizzazione e test del software, in ragione di differenti deliverables, l’indicatore va applicato a ogni singola fase.
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.
I seguenti Livelli di Servizio specifici si applicano alla macroclasse Manutenzione (si applica anche per i prodotti software in garanzia):
LSS-MAC1–TEMPESTIVITÀ DI RIPRISTINO DELL’OPERATIVITÀ IN ESERCIZIO
Descrizione
Tempo per la risoluzione delle anomalie del software in esercizio.
Gli interventi di manutenzione correttiva (rientrano nel conteggio della metrica anche gli interventi che saranno eseguiti nel periodo di garanzia) effettuati a fronte di anomalie dovute al software applicativo, hanno un livello di ripristino della piena operatività in funzione della categoria di malfunzionamento.
Unità di misura Ore (numero)
Periodo di
Avvio del processo di risoluzione dell’anomalia: Data, ora e minuti di registrazione nel sistema SGF, da parte di LI, della richiesta di intervento (Dinizio)
Presa in carico della segnalazione da parte del Fornitore: Data, ora e minuti di registrazione nel sistema SGF, da parte del Fornitore, della comunicazione di aver preso in carico il problema segnalato (Dpresacarico)
Rilascio della risoluzione di una anomalia: Data, ora e minuti di registrazione
che l’intervento è stato completato (realizzato, testato e consegnato a LI
La categoria di malfunzionamento sarà assegnata da LI nel rispetto di quanto definito al paragrafo 5.2.2.1 del Capitolato Tecnico Lotto 3 e Lotto 4.
Per le modalità di conteggio delle ore si rimanda al Piano di Qualità al paragrafo 6.3.
LSS-MAC2–CASI RECIDIVI
Descrizione
Numero di interventi di manutenzione correttiva che hanno determinato ricicli correttivi di difetti o anomalie precedentemente risolte (rientrano nel conteggio della metrica anche gli interventi che saranno eseguiti nel periodo di garanzia). In questi casi, sul sistema SGF verrà espressamente classificato da LI l’intervento come caso recidivo.
Unità di misura Numero di interventi di manutenzione (numero)
Periodo di
Dati elementari da rilevare
Numero di interventi di manutenzione correttiva recidivi per lo stesso difetto o anomalia (Nrecidivi)
Formula
Valore di soglia
Sanzione Penale
Note Nessuna
LSS-MAC3–MALFUNZIONAMENTI IN ESERCIZIO DELL’APPLICAZIONE
Descrizione
Rapporto tra il numero di anomalie relative alle 4 categorie di malfunzionamento emersi nell’esercizio di un’applicazione ed il numero di FP per la medesima applicazione.
L’indicatore va rilevato per tutte le applicazioni in esercizio sia durante l’erogazione dei servizi sia durante il periodo di garanzia.
Il volume delle applicazioni di cui non si dispone della baseline e sviluppati in GG PP verrà calcolato convertendo l’impegno di sviluppo in FP.
Unità di misura Anomalie per FP (numero)
Periodo di
Numero totale di anomalie (segnalati sul sistema di tracciamento) di ciascuna applicazione in esercizio rilevati durante il periodo di riferimento (Nanomalie)
Numero totale di FP dell’applicazione, rilevato al termine del periodo di riferimento (Nfp)
Vanno considerate tutte le anomalie rilevate durante il periodo di riferimento.
Per il calcolo di questo livello di servizio saranno considerate esclusivamente le prime tre cifre decimali dopo la virgola, senza procedere ad alcun arrotondamento (e.g.
valore calcolato 0,438546; valore attribuito 0,438).
Qualora l’intervento preveda lo sviluppo o la manutenzione di più Prodotti, l’indicatore va applicato a ogni singolo Prodotto.