Sistema qualità

Sistema Qualità e Conseguimento degli Obiettivi

Alla base della riuscita di qualunque progetto di automazione o di erogazione di servizi vi è l'adozione di un idoneo sistema qualità in grado di garantire, in ogni fase del processo, che i risultati ottenuti siano conformi con quelli attesi. Nel seguito viene descritta in sintesi la metodologia utilizzata da GESINF in merito al sistema qualità interno e alle metodologie applicate nelle fasi di progettazione, sviluppo e manutenzione del software e gestione dei servizi, poste in essere in relazione ai diversi campi di attività aziendali. Costituiscono elementi di base del sistema qualità aziendale i processi impiegati durante il Ciclo di Vita del Software e la metodologia e l’organizzazione adottata nelle aree di produzione per la documentazione interna ed esterna del processo di produzione e delle attività ad esso connesse, in relazione alla verifica della qualità delle stesse.

Il sistema qualità Gesinf è certificato UNI EN ISO 9001 per la progettazione, sviluppo, manutenzione, assistenza software ed erogazione di servizi cloud e saas.

Ciclo di Vita del Software

Il ciclo di vita del software è basato su una metodologia assimilabile alla cosiddetta metodologia “a cascata”, integrato con attività di verifica e revisione delle fasi atte a ridurre i rischi connessi con l’incompleta esecuzione di una delle fasi.

Secondo il modello “a cascata”, il ciclo di vita dell’applicazione passa attraverso una sequenza di fasi poste in cascata, ed in ciascuna fase riceve ingressi dalla fase precedente e produce uscite per la fasi seguente.

La rappresentazione grafica di tale modello illustra una progressione di fasi tale per cui da una fase si procede verso la fase successiva, che non prevede, nel modello prettamente teorico, tecniche per gestire i ritorni all’indietro verso fasi precedenti, e che pertanto possono divenire elementi di forte disturbo.

Il modello attualmente adottato dalla GESINF prevede le fasi descritte di seguito, in cui per ogni fase vengono evidenziate le attività che la compongono. Come sarà esplicitato più avanti le fasi descritte devono intendersi come schema di riferimento astratto sul quale viene basato il sistema qualità dell’area produzione. La successione delle fasi non deve infatti essere intesa in modo rigido, dal momento che, nel mondo reale, esiste la necessità di tornare alla fase precedente, di modificare la sequenza o di eliminare una o più fasi, in funzione delle caratteristiche del progetto, delle priorità imposte e dei problemi pratici riscontrati sul campo.

PIANO STRATEGICO

E’ lo studio iniziale di un progetto nel suo complesso, intendendo per tale la valutazione preliminare della fattibilità dello stesso ed eventualmente dei costi – benefici dell’intera applicazione. Comprende la valutazione delle alternative possibili, delle risorse umane e tecnologiche di riferimento, della tempificazione di massima.

Obiettivi		Definizione preliminare del problema Identificazione di possibili scenari che illustrino diverse strategie di soluzione Definizione dei Costi, tempi e modalità relative alle diverse scelte. Tempificazione generale del progetto.
Input		Raccolta di informazioni non formalizzate oppure l'analisi dei requisiti e dei vincoli riportati sulla documentazione fornita dal committente, quali richieste di offerta o capitolati di fornitura.
Output		Studio di Fattibilità e Piano di Azione.

ANALISI E SPECIFICA DEI REQUISITI

In questa fase viene fatta un’analisi completa dei problemi dell’utente e della sua realtà applicativa, al fine di poter specificare le caratteristiche funzionali e di qualità che l’applicazione dovrà soddisfare.

In questa fase vengono evidenziati soprattutto i requisiti funzionali, ossia cosa deve offrire l’applicazione in termini di funzionalità e le qualità di correttezza, affidabilità e robustezza del sistema. L’approccio in questa fase pone l’accento su cosa deve fare il sistema, e non sul come deve farlo, ossia senza anticipare le scelte progettuali che devono essere compiete più avanti, concentrando gli sforzi sul livello di interesse esterno dell’utente.

Obiettivi		Analizzare e Certificare i requisiti richiesti, in accordo con il committente o con le strategie di mercato (nel caso di prodotti oggetto di commercializzazione). Definire le linee guida per la successiva fase di progettazione.
Input		Conoscenze specifiche dell’azienda nell’ambito della problematica affrontata dal sistema, derivante da esperienze precedenti o informazioni acquisite da terze parti; raccolta di informazioni non formalizzate presso l’utente (nel caso di commessa); analisi dei requisiti e dei vincoli riportati sulla documentazione fornita dal committente, quali richieste di offerta o capitolati di fornitura.
Output		Documento di Specifica dei Requisiti (DSR), generalmente distinto in due livelli di dettaglio: Macro Analisi, documento di analisi generali che descrive le necessità dell’utente in termini di macro attività, generalmente per aree applicative. Il linguaggio utilizzato è normalmente quello naturale); Micro Analisi (o analisi di dettaglio, il documento che esplicita le varie funzioni richieste nell’ambito delle aree applicative. Il livello di dettaglio dovrebbe consentire la comprensione dei requisiti richiesti fino al limite in cui entrano in gioco le scelte legate alla tecnologia applicata nell’implementazione. In termini pratici tale documento rappresenta la descrizione delle aspettative dell’utente indipendentemente dalle possibilità tecniche del sistema di sviluppo. Il linguaggio impiegato è generalmente quello naturale, con integrazioni di diagrammi entità-relazioni o DFD (diagrammi di flusso dei dati).

L'analisi dei requisiti rappresenta una fase fondamentale nel ciclo di vita del software, seppure il livello di dettaglio possa variare in funzione di molti fattori, primo fra tutti la presenza o meno di standard precostituiti per la gestione di problematiche diffuse e consolidate. In tali circostanze la formalizzazione dei dettagli che rappresentano elementi imprescindibili e comunemente accettate nell’ambito del problema in oggetto può essere tralasciata a favore delle parti che invece necessitano di effettivo approfondimento.

PROGETTAZIONE

In questa fase si definisce, per successivi stadi di dettaglio, come i requisiti specificati nel DSR possano essere raggiunti attraverso una opportuna architettura hardware e software, ed attraverso un’opportuna scomposizione del sistema in sotto-sistemi, dei sotto-sistemi in moduli, dei moduli in funzioni. I livelli di dettaglio sono generalmente due:

Macro Progettazione (architettura generale)		Questa attività porta alla definizione: Dei sotto-sistemi componenti il sistema generale, generalmente coincidenti con le aree applicative definite nel DSR, e la loro composizione in moduli, elencati senza il dettaglio delle funzioni. Delle caratteristiche tecnico-funzionali del sistema ospite, generalmente in termini di requisiti e di architettura generale (hardware e software di base). Della tecnologia adottata in merito alla gestione della base dati e la sua architettura logica di insieme. Della tecnologia di implementazione, con specifico riferimento alle metodologie di sviluppo e agli specifici strumenti con i quali sarà implementato il sistema (Criteri di implementazione, linguaggi, database, tools, strumenti di supporto). Della tempificazione globale del progetto, in termini di stati di avanzamento, sessioni di valutazione degli stessi con il Committente, consegne e attivazione di servizi paralleli o successivi alla fase di produzione. In questa attività è compresa la pianificazione di eventuali prototipi da realizzare.
Progettazione esecutiva		Questa attività porta alla definizione : Delle funzionalità specifiche dei singoli moduli, delle interazioni fra gli stessi e della loro integrazione all’interno del sistema. Questo aspetto riguarda anche la definizione della coesione e dell’accoppiamento dei moduli, la loro estendibilità e riutilizzabilità all’interno di altre aree applicative. Della base dati dell’applicazione, a livello logico e fisico, dettagliata a livello di singolo campo (attributo), e delle relazioni che intercorrono tra le varie entità. Il progetto evidenzia normalmente la distribuzione della logica di accesso e gestione dei dati, delle relazioni e delle transazioni, tra sistema client e sistema server. Delle caratteristiche specifiche delle classi di uso generale (o delle procedure nel caso di sistemi non object-oriented) in termini di proprietà e metodi. Della pianificazione sull’impiego delle risorse in termini di addetti, con date di inizio e fine presunta delle attività.

Una ulteriore documentazione di progetto è la Modellazione: con tale termine si indica l’attività di specificazione dettagliata di tutte le classi e le istanze delle stesse che compongono il progetto o parte di esso, (attualmente confluiti nella metodologia denominata UML - Unified Modeling Language). Lo scopo è quello di definire in modo esatto e senza ambiguità, a diversi livelli di astrazione, tutte le informazioni relative alle classi e agli oggetti applicativi e funzionali che faranno parte del progetto (proprietà, metodi, relazioni, ereditarietà ecc.).

Obiettivi		Per la macro rogettazione : fornire un quadro di riferimento chiaro della struttura interna del sistema, delle tecniche di implementazione previste e degli strumenti idonei alla loro applicazione. Fornire un quadro di riferimento temporale per le fasi di analisi congiunta degli stati di avanzamento, con il committente. Fornire indicazioni sull’eventuale presenza e natura dei prototipi da realizzare. Per la progettazione esecutiva : Prendere il maggior numero di decisioni in merito alla realizzazione pratica del sistema nella fase progettuale piuttosto che in quella implementativa, a beneficio della qualità complessiva del prodotto finale. Tempificare e pianificare l’uso delle risorse impiegate nel progetto e gli stati di avanzamento.
Input		Documenti di Specifica dei Requisiti (DSR)
Output		Documento di Specifiche di Progetto, comprendente al livello più alto di dettaglio: Architettura generale del sistema (linguaggio naturale + DFD). Architettura del sistema ospite (linguaggio naturale). Architettura dell’applicativo (linguaggio naturale + DFD ). Specifiche di Implementazione Software (linguaggio naturale). Architettura della base dati e dei flussi informativi (linguaggio naturale + DFD). Pianificazione temporale delle attività (diagrammi tempo-attività, GANTT). A livelli inferiori di dettaglio: Descrizione Funzionale dei Moduli (linguaggio naturale + DFD). Tali documenti costituiscono anche la base per la redazione delle schede di lavoro, utilizzate nella successiva fase di implementazione e test di unità. Calendario di Sviluppo, redatto per la pianificazione delle risorse e dei tempi (diagrammi tempo-attività). Dizionario della Base Dati (diagrammi E/R o sistema di modellazione di basi di dati) Specifiche (parametri, classi, oggetti, proprietà, metodi, ritorni) delle Classi e degli oggetti applicativi e di uso generale (terminologia relativa al sistema di sviluppo utilizzato, oppure diagrammazione delle classi secondo gli standard industriali). Definizione del numero e della natura dei prototipi (linguaggio naturale).

La fase di progettazione di massima è sempre presente; per la progettazione di estensioni di sistemi (con nulle o scarse variazioni del modello logico) la progettazione di dettagli può essere ridotta all'essenziale.

SVILUPPO DEI MODULI E TEST DI UNITA’

Corrisponde all’attività implementativa vera e propria, la fase di programmazione, effettuata dallo staff di sviluppo nel rispetto delle caratteristiche di progetto. A tale attività è affiancata, in parallelo, la verifica del funzionamento dei singoli moduli, da parte dello stesso personale di sviluppo e, al completamento del modulo, da parte di personale dedicato (in dipendenza della complessità del progetto).

A tale fase è delegato il compito di fornire eventuali prototipi di uno o più moduli componenti il sistema, qualora il progetto lo preveda. Le caratteristiche funzionali dei prototipi sono state definite eventualmente nella fase progettuale.

Obiettivi		Realizzazione del software nel rispetto dei tempi e delle modalità definite in fase di progetto. Verificare la rispondenza dei singoli moduli, in fase di produzione e dopo la fase di completamento, ai requisiti di progetto e di qualità.
Input		Documenti di Specifiche di Progetto. Documenti di interscambio informazioni con l’area test.
Output		Prototipi dei Moduli per la verifica congiunta di rispondenza ai requisiti e alle aspettative del committente. Singoli Moduli Applicativi rispondenti alle caratteristiche funzionali e di qualità richieste dal progetto.

In questa fase viene prodotta una documentazione interna specifica per la corretta verifica del rispetto dei tempi e della qualità dei prodotti finiti. Tale documentazione, viene aggiornata a cura degli stessi sviluppatori o, se presente una separata unità di test, in collaborazione con quest’ultima.

INTEGRAZIONE E TEST DI SISTEMA

Questa fase viene attivata dopo il completamento di tutti o parte dei moduli che compongono il sistema, al fine di permettere la verifica dello stesso e la successiva messa a regime. E’ importante, sotto molti versi, che i test di sistema vengano eseguiti da personale non coinvolto direttamente nella precedente fase di sviluppo.

Obiettivi		Assemblare i moduli per ottenere il sistema o il sotto-sistema in oggetto. Eseguire tutte le parametrizzazioni necessarie al corretto avviamento delle procedure presso il sistema ospite definitivo. Verificare la rispondenza del sotto sistema o del sistema ai requisiti di progetto e di qualità.
Input		Documenti di Specifiche di Progetto Documenti di interscambio informazioni con l’area sviluppo
Output		Sistema complessivo o sotto-sistema per la successiva fase di installazione presso il sistema ospite. Schede di lavorazione relative al processo di integrazione, con indicazione dei tempi previsti, effettivi, degli esiti dei test e delle successive operazioni di correzione/revisione. Documento finale di rilascio del sistema o del sotto sistema, con esito e considerazioni circa il test conclusivo ed evidenziazione degli eventuali aspetti critici (parti assenti/incomplete).

In questa fase viene prodotta una documentazione interna specifica per la corretta verifica del rispetto dei tempi e della qualità dei prodotti finiti. Tale documentazione, rappresentata dalle schede di lavorazione, viene aggiornata a cura degli stessi sviluppatori ed incollaborazione con la separata unità di test.

DOCUMENTAZIONE

Questa fase è rappresentatata dall’attività di raccolta delle informazioni relative al progetto, dei documenti di analisi e di progetto, sulla base delle quali viene redatta la documentazione ad uso del committente.

L’esecuzione temporale di tale attività è variabile in funzione delle dimensioni e del materiale richiesto.

Obiettivi		Redazione di Documentazione organica ad uso utente o tecnico. Aggiornamento della documentazione rilasciata, nel caso di continuità del servizio. Redazione e aggiornamento dell'eventuale dell’help in linea.
Input		Documenti di Specifiche di Progetto Documenti di interscambio informazioni con l’area sviluppo
Output		Documentazione tecnica e utente

AVVIAMENTO, AFFIANCAMENTO E MANUTENZIONE

Questa fase comprende tutti i servizi forniti per la messa a regime del sistema, e le successive attività di manutenzione. Fanno parte delle attività del servizio e supporto clienti:

La fornitura di servizi tecnici o di consulenza specialistica connessi con la messa a regime di un sistema.
L’addestramento del personale.
Le attività di avviamento o affiancamento all’uso del sistema.
Il supporto all’uso del sistema, inteso come assistenza diretta o a distanza.
L’attività di intervento in caso di malfunzionamenti o interruzioni del sistema, su segnalazione del committente o sulla base delle informazioni in possesso dell’azienda.
La raccolta, catalogazione e valutazione delle richieste di variazioni o estensioni del sistema da parte del Committente.
L’installazione di aggiornamenti, patch, implementazioni di nuove funzionalità.
Le attività citate riportate, alle quali vanno aggiunti eventuali servizi specifici, sono trattate nella sezione specifica.

Metodologia a "Spirale"

E’ evidente che per produrre i risultati attesi il ciclo di vita del software preso a riferimento dovrebbe essere applicato nella realtà esattamente a cascata, e cioè evitando ritorni alle fasi già eseguite. Tuttavia, dal momento che nel mondo reale tale circostanza favorevole si verifica assai raramente, il ciclo di vita reale è generalmente composto da più cicli di analisi-sviluppo-valutazione, dando luogo a ciò che viene generalmente definito ciclo di vita a spirale. Questa metodologia, la più seguita nella pratica, può trovare applicazione nello sviluppo di una intera procedura gestionale come in quella di un singolo modulo, e consente di raggiungere il risultato finale (ad esempio la versione definitiva di un dato software) per successive fasi di integrazione, miglioramento ed estensione delle funzioni.
I vantaggi di tale approccio sono essenzialmente i seguenti:
L’analisi e la progettazione iniziale sono incentrati sugli aspetti principali del software, ovvero sulla sua struttura fondamentale e le funzioni necessarie, rimandando ad un secondo tempo (successivo ciclo) la definizione di dettagli funzionali che, pur migliorandone o estendendone l’utilità, non rappresentano fattori essenziali. Tale approccio porta ad una maggiore attenzione verso gli aspetti determinanti (integrità e coerenza del progetto), agevola la discussione con l’eventuale committente, e consente di ridurre i tempi.
Le decisioni in merito al miglioramento/aumento delle funzioni possono essere prese sulla base di una applicazione (o ad un modulo) già parzialmente (o anche totalmente) funzionante, e possono pertanto essere commisurate ai reali benefici che apportano. Non è infatti raro il caso che una o più delle funzioni inizialmente previste, se l’analisi iniziale è stata condotta con un eccessivo dettaglio, risultino essere state stravolte prima del termine del progetto, con aggravio di tempo maggiore di quanto non avrebbe comportato la loro realizzazione come ultima fase.
E’ possibile il rilascio preliminare di una versione funzionante (ad es. beta) che, pur rispettando i requisiti funzionali di base, sia suscettibile di perfezionamento e miglioramento, anche in virtù delle richieste del committente, e consenta un efficace test di rispondenza.
E’ possibile valutare preliminarmente l’impatto, in termini prestazionali, di nuove funzioni, qualora i tempi di esecuzione siano un fattore importante.
Il ciclo di vita a spirale viene realizzato sia attraverso l’attuazione di più cicli completi successivi, ovvero con nuove sessioni complete di analisi-progettazione-sviluppo-test, sia con l’aggiunta di requisiti e informazioni ulteriori alle varie fasi di una singola sessione. Quest’ultima prassi è generalmente adottata per le attività cicliche di sviluppo fino al rilascio al cliente di una versione successiva delle applicazioni.

Sistema Qualità nei Servizi

Come già esplicitato il ciclo di vita è di tipo “a cascata”. In tale contesto la fornitura dei servizi post-installazione rappresenta sia la fase terminale del ciclo di vita del software, che prevede il ritorno alle fase precedenti con le opportune informazioni circa le problematiche operative, sia una attività continuativa per tutto il periodo successivo alla consegna definitiva del progetto, che non necessariamente influenza nuovamente, o almeno in modo determinante, le fasi di produzione.
Con il termine Servizi & Supporto Clienti viene quindi inteso tutto l’insieme di attività che caratterizzano i rapporti ufficiali ed operativi tra l’azienda e il committente, che ha inizio all’atto della consegna definitiva del progetto e si protrae per tutto il periodo di validità della garanzia e/o di accordi contrattuali eventualmente stipulati.

Fanno parte delle attività del servizio e supporto clienti:

La fornitura di servizi tecnici o di consulenza specialistica connessi con la messa a regime di un sistema.
L’addestramento del personale.
Le attività di avviamento o affiancamento all’uso del sistema.
Il supporto all’uso del sistema, inteso come assistenza diretta o a distanza.
L’attività di intervento in caso di malfunzionamenti o interruzioni del sistema, su segnalazione del committente o sulla base delle informazioni in possesso dell’azienda.
La raccolta, catalogazione e valutazione delle richieste di variazioni o estensioni del sistema da parte del Committente.
L’installazione di aggiornamenti, patch, implementazioni di nuove funzionalità.

Le attività riportate, alle quali vanno aggiunti eventuali servizi specifici non catalogabili in una delle categorie citate, hanno in comune la necessità di essere eseguite nel rispetto di una determinata procedura ufficiale o funzionale, stabilita nel tempo, che presuppone il coinvolgimento sia dell’azienda che del committente. Per questo tipo di attività i fattori determinanti in merito alla qualità sono riassumibili nei seguenti punti:

Chiarire l’obiettivo e la natura del servizio richiesto o dovuto, in tutte le sue parti, compresa la determinazione delle risorse impiegate e le modalità di esecuzione.
Pianificare il servizio nel tempo, stabilendone date e tempi di esecuzione.
Verificare e Vagliare l’effettiva esecuzione del servizio ed il raggiungimento degli obiettivi prefissati.
Raccogliere, catalogare ed inoltrare alle aree competenti le informazioni raccolte durante l’esecuzione del servizio, che presuppongano l’attivazione di altri servizi o processi di produzione/revisione del software.
Valutare la natura e l’entità dell’attività richiesta (in termini di costo, tempi e modalità).
Distribuire le attività previste per unità produttiva, definendone le caratteristiche (tempi e modalità di esecuzione).
Verificare lo stato di avanzamento delle attività distribuite.
Coordinare le attività di test e consegna.
Convogliare le informazioni preventive e consuntive alle unità commerciali e direzionali.

E’ evidente che i fattori descritti coinvolgono una notevole mole di informazioni, e che la complessità di gestione aumenta se si considera la necessità di coordinare più risorse per la soluzione di diverse problematiche contingenti. In virtù di tale complessità l’insieme delle informazioni relative alla fornitura dei servizi di cui sopra è gestito tramite un sistema centralizzato di raccolta informazioni, basato su un software specificatamente concepito da GESINFi. Tale sistema prende il nome di SSC (Software per il Servizio & Supporto Clienti) e rappresenta lo strumento di riferimento per tutto il personale impiegato in azienda, per le unità produttive, commerciali, amministrative e direzionali.
Tramite tale strumento tutte le informazioni relative ai servizi richiesti e al loro espletamento viene gestito in una unica base dati aziendale, che permette la facile individuazione e gestione dei fattori descritti in precedenza.

Il risultato è la creazione di una struttura integrata e completamente automatizzata per la gestione dei seguenti aspetti :

Raccolta delle segnalazioni provenienti dall’esterno (Clienti) e dall’interno (unità di test). Include le richieste di informazioni, di interventi, la segnalazione di anomalie, le richieste di implementazioni e via discorrendo.
Pianificazione degli interventi presso i Clienti (appuntamenti) o di sessioni di valutazione interna (riunioni).
Resoconti delle attività di intervento presso i clienti, da un punto di vista formale (durata e modalità) e operativo (attività seguenti).
Distribuzione delle attività previste sulla base delle segnalazioni e degli interventi, per unità produttive, a livello di area (analisi, sviluppo, test e installazione) fino a livello di singolo addetto.
Resoconto sulle attività di produzione, di test e di supporto, a consuntivo.
Gestione del ciclo commerciale delle attività, integrata alle funzioni di cui sopra (richieste offerta, offerte, ordini, consegna).

La struttura complessiva dello strumento è concepita in modo da permettere ad ogni addetto l’inserimento e la consultazione delle informazioni di propria competenza, agendo dal proprio terminale, seguendo una serie di operazioni standardizzate in base alla specifica area di appartenenza. In questo modo si realizza una infrastruttura in grado di garantire:

La raccolta organica e in formato standardizzato di tutte le informazioni.
La condivisione delle informazioni tra tutte le risorse aziendali.
La distribuzione delle attività per unità produttiva e per addetto.
La possibilità di analisi delle attività previste e delle modalità di erogazioni e dei risultati ottenuti.

Relativamente alle applicazioni in tecnologia 2G il servizio di assistenza è supportato da una funzionalità di invio automatico di segnalazione al servizio clienti, in grado di trasferire automaticamente anche una vasta serie di informazioni circa la configurazione di sistema ed il contesto nel quale è emerso il problema.