Piano Di Qualifica - Find and develop open source software

Piano Di Qualifica 

30 marzo 2010 

Sommario 

Questo documento contiene il Piano Di Qualifica del capitolato 

denominato SketchYourSite, commissionato dai prof. Vardanega e 

Conte in rappresentanza dell’azienda proponente Zucchetti S.P.A., da 

parte del gruppo “StormForge Labs”. 

Informazioni del documento 

Redazione M. Pegoraro, M. Broggio 

Approvazione D. Baccaglini 

Verifica M. Polato 

Stato Formale 

Uso Esterno 

Nome File piano di qualifica v5.0 

Versione 5.0 

Distribuzione StormForge Labs 

Vardanega Tullio 

Conte Renato 

1

Diario delle modifiche 

• v5.0 approvazione del documento da parte del responsabile (D. Baccaglini, 

29/03/10) 

• v4.2 veridica del documento (M. Polato, 16/03/10) 

• v4.1 correzione e sistemazione generale, aggiunta delle ultime Risorse 

Tecnologiche (M. Pegoraro, 16/03/10) 

• v4.0 approvazione da parte del responsabile (M. Broggio, 07/03/10) 

• v3.7 verifica del documento (D. Baccaglini, 07/03/10) 

• v3.4 integrazione dei contenuti in Metriche di Progetto (M. Pegoraro, 

06/03/10) 

• v3.2 integrazione dei contenuti in Tecniche e metodologie di verifica 

(M. Pegoraro, 05/03/10) 

• v3.1 riorganizzazione delle sezioni del documento e integrazione dei 

contenuti della sezione Tecniche e metodologie di verifica (M. Pegoraro, 

04/03/10) 

• v3.0 approvazione da parte del responsabile (M. Broggio, 18/02/10) 

• v2.4 integrazione della sezione Tracciamento e aggiornamento di Risorse 

Tecnologiche (M. Pegoraro, 19/02/2010) 

• v2.3 aggiunta della risorse Firebug e jQuery e ampliamento della sezione 

2.3.2 (M. Pegoraro, 18/02/2010) 

• v2.2 aggiunta della risorsa YASCA (M. Pegoraro, 16/02/2010) 

• v2.1 integrazione delle sezioni Risorse necessarie e disponibili (M. Pegoraro, 

05/02/2010) 

• v2.0 approvazione da parte del responsabile (D. Marcato, 22/01/2010) 

• v1.6 integrazione dei contenuti e correzione ortografica (M. Pegoraro, 

22/01/2010) 

SketchYourSite: Piano Di Qualifica v5.0 2/26

• v1.5 aggiunte sezioni 5. Pianificazione della validazione (M. Broggio, 

21/01/2010) 

• v1.3 aggiunte sezioni 4. Tecniche e metodologie di verifica (M. Broggio, 

21/01/2010) 

• v1.1 aggiunta sezione 3. Gestione Amministrativa della revisione (D. 

Calonego, 20/01/10) 

• v1.0 approvazione da parte del Responsabile (D. Marcato, 07/12/09) 

• v0.9 correzione errori ortografici e verifica (D. Baccaglini, 07/12/2009) 

• v0.3 correzione errori e sistemazione impaginazione (A. Trombetta, 

04/12/2009) 

• v0.1 prima stesura del documento (M. Pegoraro, 02/12/2009) 


INDICE 

Indice 

1 Introduzione 6 

1.1 Scopo del documento . . . . . . . . . . . . . . . . . . . . . . . 6 

1.2 Scopo del prodotto . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.3 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.3.1 Normativi . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.3.2 Informativi . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.4 Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2 Visione generale della strategia di verifica 8 

2.1 Organizzazione e responsabilità . . . . . . . . . . . . . . . . . 8 

2.2 Ticketing ed Automazione . . . . . . . . . . . . . . . . . . . . 8 

2.3 Pianificazione strategica e temporale delle attività di verifica . 8 

2.3.1 Fase di Analisi Preliminare . . . . . . . . . . . . . . . . 9 

2.3.2 Fase di Analisi e Progettazione . . . . . . . . . . . . . 9 

2.3.3 Fase di Realizzazione e Prototipazione . . . . . . . . . 10 

2.3.4 Fase di Verifica e Collaudo . . . . . . . . . . . . . . . . 11 

2.4 Risorse necessarie e disponibili . . . . . . . . . . . . . . . . . . 11 

2.4.1 Risorse Tecnologiche . . . . . . . . . . . . . . . . . . . 12 

2.4.2 Risorse Umane . . . . . . . . . . . . . . . . . . . . . . 14 

3 Gestione amministrativa della revisione 15 

3.1 Comunicazione della risoluzione delle anomalie . . . . . . . . . 15 

3.2 Trattamento delle discrepanze . . . . . . . . . . . . . . . . . . 15 

3.3 Procedure di controllo della qualità . . . . . . . . . . . . . . . 15 

4 Tecniche e metodologie di verifica 16 

4.1 Premessa: verifica non formale e formale . . . . . . . . . . . . 16 

4.2 Fase di Analisi Preliminare . . . . . . . . . . . . . . . . . . . . 16 

4.2.1 Verifica della Documentazione . . . . . . . . . . . . . . 16 

4.2.2 Verifica dei Requisiti . . . . . . . . . . . . . . . . . . . 17 

4.3 Fase di Analisi e Progettazione . . . . . . . . . . . . . . . . . 18 

4.3.1 Tracciamento . . . . . . . . . . . . . . . . . . . . . . . 18 

4.4 Fase di Realizzazione e Prototipazione . . . . . . . . . . . . . 19 

4.4.1 Analisi Statica . . . . . . . . . . . . . . . . . . . . . . 19 

4.4.2 Analisi Dinamica . . . . . . . . . . . . . . . . . . . . . 20 

4.5 Fase di Verifica e Collaudo . . . . . . . . . . . . . . . . . . . . 21 

4.6 Verifica dei processi . . . . . . . . . . . . . . . . . . . . . . . . 21 


INDICE 

5 Metriche di Progetto 23 

5.1 Metriche Gestionali . . . . . . . . . . . . . . . . . . . . . . . . 23 

5.2 Metriche Dimensionali . . . . . . . . . . . . . . . . . . . . . . 23 

5.3 Metriche di Complessità . . . . . . . . . . . . . . . . . . . . . 24 

5.4 Metriche Chidamber-Kemerer . . . . . . . . . . . . . . . . . . 24 

6 Pianificazione della validazione 26 

6.1 Specifica della campagna di validazione . . . . . . . . . . . . . 26 


1 Introduzione 

1.1 Scopo del documento 

Lo scopo di questo documento è gestire la qualità del prodotto pianificandone 

il processo, e accertare il raggiungimento dei requisiti decisi per la qualità. 

Questo deve assicurare che il prodotto e ogni processo siano conformi ai requisiti 

e ai piani di programma. Il piano di qualifica inoltre deve determinare 

in dettaglio i seguenti requisiti: 

• Funzionalità: Il prodotto dovrà soddisfare ogni specifica contenuta 

nel documento Analisi dei Requisiti. 

• Affidabilità: Il prodotto dovrà essere privo di errori grazie a controlli 

effettuati con vari strumenti di test. 

• Usabilità: L’utente finale del prodotto dovrà poter usare il prodotto in 

ogni sua funzionalità a prescindere dalle sue conoscenze informatiche. 

1.2 Scopo del prodotto 

L’applicativo SketchYourSite è concepito a partire da un prodotto già esistente, 

AjaxDraw, che propone creazione, manipolazione e salvataggio di 

immagini vettoriali tramite browser. SketchYourSite si propone di estendere 

AjaxDraw, aggiungendo funzionalità per la creazione vera e propria di pagine 

web, rendendolo a tutti gli effetti un disegnatore di siti web sfruttando le 

potenzialità del tag CANVAS di HTML5. Le tecnologie gestibili tramite il 

prodotto saranno HTML (versione 5), JavaScript e CSS. Funzioni avanzate 

saranno la possibilità di collegare varie pagine tra loro in modo da creare 

un proprio sito, il tutto gestito tramite un comodo e intuitivo schema grafico, 

e la compatibilità con Internet Explorer, browser molto diffuso ma senza 

supporto nativo del tag CANVAS. Il software verrà rilasciato con licenza 

GPL. 


1.3 Riferimenti 

1.3 Riferimenti 

1.3.1 Normativi 

• Apache License V2.0: http://www.apache.org/licenses/LICENSE-2.0 

• GPL: http://www.gnu.org/licenses/gpl.html 

1.3.2 Informativi 

• ISO/IEC 12207: standard comune per i Cicli di Vita del Software 

• ISO 9001-2000: descrive le terminologia e i principi essenziali dei sistemi 

di gestione qualità e della loro organizzazione 

• Slides e lezioni del corso di Ingegneria del Software, UniPD, A.A. 

2009/2010 

1.4 Glossario 

Per le spiegazioni sui termini tecnici, le abbreviazioni e gli acronimi usati 

nei documenti, si consulti il documento esterno denominato Glossario. Tali 

termini sono evidenziati mediante corsivo. 


2 Visione generale della strategia di verifica 

2.1 Organizzazione e responsabilità 

La strategia di verifica della StormForge Labs individua il preciso ruolo del 

Verificatore, colui che certifica la qualità e la conformità ai requisiti di ciò 

che viene prodotto. Si è determinata quindi una relazione gerarchica per le 

operazioni di verifica: 

• Verificatore: colui che, utilizzando tecniche e strumenti preposti, esegue 

operativamente la verifica, notificandone i risultati al Responsabile 

mediante ticketing, al quale risponde anche del proprio operato. 

• Responsabile: prende nota dell’operato dei Verificatori, relaziona i 

passi della verifica al committente, comunica eventuali errori e problemi 

per la correzione e funge da controllore della qualità per ciò che concerne 

il processo di verifica. 

2.2 Ticketing ed Automazione 

Il sistema di ticketing scelto è quello fornito gratuitamente da SourceForge 

Trac. Attraverso questo strumento è possibile avere una gestione integrale 

e multifunzionale di tutte le varie fasi della verifica e della gestione di qualità. 

Quando il Verificatore riscontra un’anomalia, un problema o un bug nel 

materiale che sta analizzando, apre un ticket nell’apposita sezione di SourceForge, 

descrivendo le problematiche riscontrate. Il ticket viene visionato 

dal Responsabile che poi l’assegna al membro opportuno per la soluzione. 

Nel ticket vengono segnati i vari sviluppi del problema fino alla chiusura che 

segna la soluzione del problema in coerenza con le norme qualitative decise. 

In ogni momento è consultabile lo storico dei ticket per avere una visione 

d’insieme per i problemi riscontrati, ordinati per priorità, tipologia, stato. 

2.3 Pianificazione strategica e temporale delle attività 

di verifica 

La strategia e il concetto di verifica sono singolarmente definiti per ogni fase 

dello sviluppo del progetto. Di seguito verranno illustrate per ogni singola 

fase in cui si renderà necessaria la verifica. Notare che di seguito viene presentata 

soltanto una visione a grandi linee delle strategie di verifica per le 

fasi successive all’analisi: il documento è stato in seguito aggiornato, presentando 

in dettaglio le tecniche di verifica nella sezione Tecniche e metodologie 

di verifica, divise per fase di progetto. 


2.3 Pianificazione strategica e temporale delle attività di verifica 

2.3.1 Fase di Analisi Preliminare 

Qui ha luogo la verifica nel momento in cui gli Analisti producono un documento, 

sebbene non definitivo ma in forma consistente. Per consistente 

s’intende comprensivo di sufficienti contenuti da possedere un valore informativo 

intrinseco che gli conferisce qualità. Il Verificatore controlla che non 

vi siano errori ortografici, sintattici o di battitura, che non vi siano paragrafi 

incompleti e che il documento sia pienamente comprensibile. Terminato il 

controllo, il Verificatore provvederà a segnalare al Responsabile gli eventuali 

errori riscontrati tramite apposito ticket, senza apportare correzioni (poichè 

ciò esula dal suo ruolo). 

Quindi, le fasi attraversate da un documento sono: 

• Redazione: il documento viene scritto, anche parzialmente, dai redattori. 

• Verifica: il Verificatore controlla la qualità del documento come illustrato 

in questo stesso paragrafo. 

• Convalida: il Responsabile prende atto degli eventuali errori rinvenuti 

dal Verificatore con l’apertura da parte di quest’ultimo di un ticket 

apposito, e li comunica alla redazione per la correzione. In caso il 

documento superi la verifica con la chiusura del ticket, il Responsabile 

provvede a trasmettere il documento al Committente. 

L’identica procedura per la verifica della qualità dei documenti è utilizzata 

per la documentazione anche nelle fasi successive. Altri dettagli si possono 

trovare sulla sottosezione Ticketing ed Automazione di questo stesso documento. 

Per quanto concerne le tecniche di verifica dei requisiti determinati in fase 

di analisi, si veda la sottosezione Fase di Analisi Preliminare nella sezione 

Tecniche e metodologie di verifica in questo stesso documento. 

2.3.2 Fase di Analisi e Progettazione 

Nella progettazione vengono individuate due fasi, in ognuna delle quali si 

individuano diversi compiti per i Verificatori. 

• Progettazione architetturale: in questa fase il compito dei Verificatori 

è controllare le scelte architetturali dei Progettisti, assicurandosi 

che rispettino ogni requisito imposto dal Committente, nonchè qualsiasi 

requisito opzionale preventivato; fanno capo al Responsabile il quale 


2.3 Pianificazione strategica e temporale delle attività di verifica 

comunicherà gli errori ai Progettisti. Ogni dettaglio architetturale deve 

seguire i pattern previsti. Per maggiori dettagli sull’architettura di alto 

livello si rimanda al documento Specifica Tecnica. 

• Progettazione in dettaglio: qui i Verificatori controllano che la progettazione 

continui seguendo le linee guida determinate durante la fase 

di progettazione architetturale. 

Con l’aiuto del documento centrale della fase di Progettazione, ovverosia la 

Specifica Tecnica e diagrammi allegati, si controllerà l’adesione del progetto 

al documento Norme di Progetto, agli standard scelti e ai seguenti aspetti 

critici: 

• Coerenza e correttezza delle scelte architetturali; 

• Completezza delle classi rispetto al tracciamento in entrambi i sensi. 

La relazione classi-funzionalità deve essere completa e biunivoca; 

• Significativa scelta dei nomi di classi e metodi; 

2.3.3 Fase di Realizzazione e Prototipazione 

Viene compiuto dai Verificatori un controllo della consistenza e della correttezza 

del codice scritto, nonchè della sua qualità. Ciò verrà effettuato in un 

lasso di tempo considerevole, durante l’intera realizzazione del progetto: ogni 

piccola parte indipendente dal contesto attraverserà una primaria verifica di 

correttezza, così da permettere modularità nella verifica del codice, e quindi 

efficienza e completezza della verifica. 

La verifica del codice prodotto in fase di realizzazione viene sottoposto a due 

tipi di verifica: 

• Verifica Statica: consiste nell’esaminare i listati preliminarmente e 

manualmente, senza eseguirne il codice, così da trovare velocemente 

gli errori sintattici più grossolani. Esistono diverse tecniche che fanno 

parte della verifica statica: Inspection e Walkthrough, ad esempio, due 

diversi procedimenti di debugging in assenza di esecuzione del codice; si 

può inoltre ricorrere all’uso di un analizzatore di codice, un software che 

analizza il sorgente senza eseguirlo (un esempio è Y.A.S.C.A., descritto 

in questo stesso documento nella sezione Risorse necessarie e disponibili, 

sottosezione Risorse Tecnologiche). La spiegazione della procedura 

dettagliata di verifica statica verrà data nella fase di Realizzazione in 

questo stesso documento. 


2.4 Risorse necessarie e disponibili 

• Verifica Dinamica: queste tecniche, invece, prevedono la verifica tramite 

l’esecuzione del codice e attività di testing come Black Box (verifica 

che ogni funzione produca i risultati attesi in tutte le condizioni in cui 

essa possa eseguire, includendo test su valori tipici e valori statisticamente 

inattesi immessi da utenti senza conoscenza delle caratteristiche 

interne del prodotto) e White Box (verifica che il programma esegua 

correttamente in ogni condizione e che le condizioni logiche contenute 

eseguano correttamente in ogni possibile cammino previsto, in un 

utilizzo standard dell’applicativo). Altre tecniche verranno aggiunte e 

descritte in seguito, nella sezione apposita. 

2.3.4 Fase di Verifica e Collaudo 

In questa fase il gruppo dei Verificatori si propone di testare il prodotto completo, 

evidenziando errori di assemblaggio, carenze in efficienza, completezza, 

affidabilità e usabilità. Inoltre, verrà controllata la conformità del prodotto 

finale con tutti i requisiti concordati nella fase di analisi. Si distinguono due 

fasi: 

• Alpha Test: la fase preliminare di collaudo del prodotto all’interno 

del team, prima del rilascio ufficiale. 

• Beta Test: la fase successiva all’alpha test. Il prodotto viene rilasciato 

ad alcune persone, avvisandole che il prodotto è in uno stato di beta 

test e che può presentare una qualità non ottimale e può necessitare 

di alcune correzioni. Gli utenti sono quindi tenuti a comunicare al 

gruppo gli eventuali malfunzionamenti. I Verificatori hanno il compito 

di notificare eventuali errori. 

Maggiori dettagli sulle strategie di controllo del codice in fase di Verifica 

verranno definite in seguito, poichè è su questa fase che vengono effettuati i 

controlli in profondità riguardanti la qualità del codice. 


Di seguito l’elenco delle risorse utilizzate dal gruppo fino e non oltre la data 

dell’ultima versione di questo documento: 



2.4.1 Risorse Tecnologiche 

• Browser: Firefox v3.5, Opera v10.0, Chrome v3.0.197.11, Safari v4.0 

e Internet Explorer v8.0. Utilizzati per la documentazione e per il test 

del prodotto. I rispettivi siti di riferimento sono: 

http://www.mozilla-europe.org/it/firefox per Firefox, 

http://www.opera.com per Opera, 

http://www.google.com/chrome per Chrome, 

http://www.apple.com/it/safari per Safari, 

http://www.microsoft.com/italy/windows/internet-explorer per Internet 

Explorer. 

• Sourceforge: il sito http://www.sourceforge.net offre un hosting completo 

per un progetto, compreso un servizio di SVN repository essenziale 

per la gestione dei file. Oltre a questo, il servizio prevede un bug 

tracker interno, un efficiente sistema di ticketing per le notifiche e la 

gestione delle versioni per documenti e file. 

• Tortoise SVN 1.6.6: é parte di un set di strumenti per lo sviluppo. In 

particolare, Tortoise SVN é un client Subversion multipiattaforma rilasciato 

con licenza GPL. Il sito di riferimento è http://tortoisesvn.tigris.org. 

• L ATEX1.7.0: un potente editor testuale basato sul paradigma WYSIW- 

YG (What You See Is What You Get), da utilizzato per la redazione 

dei documenti. Il sito di riferimento è http://www.latex-project.org. 

• Texmaker 1.9.2: si tratta di un editor per linguaggio L ATEXrilasciato 

con licenza GPL Permette un’agile gestione del potente linguaggio di 

editing, automatizzando numerose funzioni. Il sito di riferimento è 

http://www.xm1math.net/texmaker. 

• Gantt Project 2.0.10: un programma di gestione e creazione dei 

Diagrammi di Gantt, utilizzati per la pianificazione delle attività del 

progetto e per le varie mansioni dei componenti del team. Il sito di 

riferimento è http://ganttproject.biz. 

• ArgoUML 0.28.1: programma open-source di modellazione scritto 

in Java utile per realizzare grafici UML, quali use case, diagrammi 

classe, diagramma di sequenza e altri. Il sito di riferimento è 

http://argouml.tigris.org. 

• Eclipse 3.5.1 Galileo: ambiente di sviluppo open-source IDE multilinguaggio 

e multipiattaforma. Il sito di riferimento è http://eclipse.org. 



È stato utilizzato con due dei suoi numerosi plug-in: Aptana (http://www.aptana.org), 

un supporto per la programmazione HTML, CSS e JavaScript, e Subversive 

(http://www.eclipse.org/subversive) per il supporto SVN integrato 

in Eclipse. 

• jQuery 1.4.1: sono potenti librerie di sviluppo JavaScript, mirate 

ad ottenere il massimo dell’efficienza in poche istruzioni, aumentando 

l’astrazione del linguaggio JavaScript a un livello più alto. Il sito di 

riferimento è http://jquery.com. 

• Apache 2: la più diffusa piattaforma server Web modulare open source. 

Offre numerose funzioni: data transport, internetworking, collegamento, 

il tutto integrato con un’elevata sicurezza. Il sito di riferimento 

è httpd://apache.org. 

• PHP 5.2: acronimo ricorsivo di PHP: Hypertext Preprocessor. Si tratta 

di un linguaggio di scripting lato server open source, con paradigma 

orientato agli oggetti e sintassi C-like debolmente tipizzata. Utilizzato 

principalmente per applicativi web lato server, puó essere usato anche 

per semplice scripting o applicazioni standalone. Il sito di riferimento 

è http://php.net.com. 

• MySQL 5: consiste in un DBMS (Data Base Management System) 

relazionale multipiattaforma, rilasciato con licenza GPL. É interfacciabile 

con un numeroso insieme di linguaggi e copre attualmente gran 

parte della sintassi base dello standard SQL. Il sito di riferimento è 

http://mysql.it. 

• Firebug 1.5: Un fondamentale addon per il browser Firefox, consente 

il debug approfondito del codice HTML e JavaScript. Consente di modificare 

facilmente stile e layout della pagina, e di visionare le modifiche 

in tempo reale. Il sito di riferimento è http://getfirebug.com. 

• Y.A.S.C.A. 2.1: acronimo di Yet Another Source Code Analyzer, è un 

applicativo multilinguaggio estendibile che permette l’analisi statica del 

codice. Infatti ne viene eseguita una scansione con successivo report che 

mette in evidenza errori, istruzioni obsolete o deprecate, offuscamento 

del codice. Verrà usato in modo profondo durante la successiva fase di 

Verifica. Il sito di riferimento è http://yasca.org. 

• OxyProjectMetrix 1.8: è un tool per il calcolo delle metriche, utilizzabile 

anche per Javascript; infatti, ogni misuratore valido per il C 

si può applicare al Javascript con alcuni accorgimenti. In particolare, 



OxyProjectMetrics è stato utilizzato per le metriche dimensionali. Il sito 

di riferimento è http://www.techinceptions.com/CodeMetrics.html. 

• SourceMonitor 2.5.1: ulteriore tool per il calcolo delle metriche, utilizzabile 

anche per Javascript. Si è rilevato utile per il calcolo della complessità 

ciclomatica. Il sito di riferimento è http://www.campwoodsw.com/sourcemonitor.ht 

• JsUnit 2.2: è un porting del celebre JUnit di Java, per Javascript. 

Consente di automatizzare la fase di analisi dinamica tramite la definizione 

di una batteria di test (su pagina HTML) eseguiti automaticamente 

dal software stesso. Il sito di riferimento è http://www.jsunit.net. 

2.4.2 Risorse Umane 

Ogni persona collaborante al progetto e interagente con i suoi processi è 

considerata una risorsa umana. Ogni risorsa umana deve essere inquadrata 

e identificata in un ruolo ben preciso. Attualmente, il team di sviluppo 

presenta la seguente suddivisione di ruoli per la fase di Analisi Preliminare: 

• Responsabile: ha la responsabilità decisionale nel progetto. Visiona il 

ticket degli errori trovati dai Verificatori, e fa sì che chi di dovere li corregga. 

Comunica con il committente e consegna allo stesso i documenti 

prodotti. 

• Amministratore: ha funzione di controllo dei processi nel progetto. 

• Analista: elenca i requisiti del progetto, valuta eventuali requisiti 

opzionali e/o desiderabili da essere inclusi nel progetto. 

• Progettista: determina l’architettura del prodotto e stende le linee 

guida che dovranno successivamente essere seguite dal programmatore. 

• Verificatore: verifica che i documenti siano corretti, chiari e completi. 

Verifica che il prodotto sia corrispondente ai requisiti, privo di errori, 

efficiente e usabile. 

• Betatester: interviene nell’ultima fase del collaudo. Rappresenta un 

campione dell’utilizzatore finale al quale viene sottoposto il prodotto 

da testare: errori e malfunzionamenti verranno segnalati e conseguentemente 

eliminati. 

Per maggiori informazioni sull’organizzazione e divisione dei ruoli per il 

gruppo StormForge Labs si rimanda al documento Piano di Progetto. 


3 Gestione amministrativa della revisione 

3.1 Comunicazione della risoluzione delle anomalie 

Il Verificatore ha l’onere di comunicare al Responsabile le eventuali anomalie 

riscontrate in fase di correzione. La notifica avviene tramite apertura di 

un ticket interno visionato dal Responsabile, il quale poi lo assegna ai vari 

componenti del gruppo a seconda del ruolo più adatto per l’analisi e l’eventuale 

soluzione del problema sollevato. Una volta corrette tutte le anomalie 

nel prodotto dai componenti designati dal Responsabile il ticket relativo al 

materiale revisionato viene chiuso. Il Responsabile quindi prende atto della 

correzione avvenuta e convalida il prodotto. 

3.2 Trattamento delle discrepanze 

Individuata una discrepanza il Verificatore apre un ticket interno, il quale 

viene gestito dal Responsabile in modo analogo alla risoluzione delle anomalie. 

3.3 Procedure di controllo della qualità 

Effettuato un controllo di qualità coordinato dagli Amministratori ed eseguito 

dai Verificatori, viene redatto un documento con la vertenza del test, la 

procedura impiegata per la verifica, e il risultato di quest’ultima con specifica 

di congruenza con i criteri di qualità stabiliti. 


4 Tecniche e metodologie di verifica 

4.1 Premessa: verifica non formale e formale 

Ogni tecnica di verifica descritta in questo documento è applicata a prodotti 

e processi del progetto SyS. Tuttavia, vi è una distinzione tra procedimenti 

di verifica non formali e formali. 

• Non formale: i risultati della verifica hanno la funzione di ottenere un 

risultato privo di errori, anomalie od omissioni, dirigendo chi crea il 

prodotto verificato a un risultato migliore. Tuttavia, la verifica rimane 

interna, non venendo documentata né venendone riportati i risultati; 

non è obbligatoria la pubblicazione in documento. 

• Formale: la verifica eredita tutte le funzioni della verifica non formale, 

assieme con la nuova caratteristica di essere usata per dimostrare 

la qualità del lavoro svolto a committenti e proponenti di progetto. I 

risultati di questo tipo di verifica sono pubblicati su un documento correlato 

con la natura della verifica stessa, e possono essere visionati da 

chi chiunque sia nella lista di distribuzione. Le tecniche di verifica formali 

sono il tracciamento diretto e inverso, tutte le metriche applicate 

alla verifica, alcuni dei test più importanti della fase di Realizzazione e 

Prototipazione, alpha-test e beta-test; rientrano nella categoria di verifica 

formale anche gli incontri con il proponente in cui si presentano i 

prototipi previsti dal ciclo di vita scelto, poichè consistono in attività 

di verifica vere e proprie. 

4.2 Fase di Analisi Preliminare 

4.2.1 Verifica della Documentazione 

I documenti prodotti dovranno seguire il seguente iter di verifica, con successiva 

segnalazione degli errori eseguita come sopra spiegato. 

• Verifica tipografica: tramite lettura e/o controllo ortografico andranno 

identificati gli errori di battitura, correggendoli. Rientra qui la 

correzione degli accenti e interpunzione varia. 

• Verifica della sintassi: tramite lettura e/o controllo sintattico automatico 

si correggeranno le sviste sulla costruzione delle frasi, rendendole 

corrette e scorrevoli. 


4.2 Fase di Analisi Preliminare 

• Verifica dell’impaginazione: in questa fase si controllerà che la struttura 

del documento stessa sia corretta: indentazione, capoversi, struttura 

dell’indice, struttura di titoli e sottotitoli, formato, dimensione e 

allineamento delle immagini e di rispettive didascalie, numerazione di 

pagina, header e footer di pagina. 

• Verifica della consistenza logica: si tratta del controllo sui concetti 

espressi dalle frasi, che devono essere complete, non prolisse ed avere 

un buon contenuto informativo. I contenuti devono ricadere nelle giuste 

sezioni e sottosezioni. 

• Verifica di struttura e contenuto: in questa ultima fase il controllo è sui 

contenuti effettivi del documento, i quali devono ricalcare la struttura 

definita per il documento stesso. Si valuta qui il valore informativo 

dello scritto: esso deve adempire alle aspettative e agli scopi previsti 

per il documento stesso. 

4.2.2 Verifica dei Requisiti 

È fondamentale eseguire un’accurata e corretta analisi dei requisiti iniziali 

in quanto lo svolgimento di essa in maniera superficiale o errata potrebbe 

portare ad un risultato che non soddisfa le richieste e quindi al fallimento 

del progetto: è provato che la riuscita o il fallimento di un progetto dipen- 

dono in larga parte dalla qualità dell’Analisi dei Requisiti. 

È importante 

quindi studiare a fondo le richieste presentate nel capitolato d’appalto e successivamente 

effettuare una scrupolosa e minuziosa verifica di ciò che si è 

estrapolato. Si ricollega anche a questa parte la verifica dell’usabilità del 

prodotto e della sua efficienza, i cui test avvengono in fase di Collaudo e 

che devono essere entrambe perfettamente in linea con i requisiti tracciati 

precedentemente dagli Analisti. 

Questi i controlli effettuati sui requisiti derivati dalla fase di Analisi (contenuti 

nel documento Analisi dei Requisiti): 

• Chiarezza formale, per evitare le ambiguità; 

• Indipendenza dei requisiti, per evitare le sovrapposizioni e le dipendenze 

tra essi; 

• Univocità dei requisiti; 

• Eliminazione dei requisiti resi obsoleti dalle scelte in fase di Progettazione; 


4.3 Fase di Analisi e Progettazione 

• Corretta classificazione dei requisiti (progettuali, funzionali, prestazionali, 

di vincolo o di qualità, e tra questi la suddivisione in obbligatori, 

opzionali o desiderabili). 

4.3 Fase di Analisi e Progettazione 

Questa verifica viene effettuata controllando il rispetto delle norme di progetto 

stabilite e l’aderenza allo standard UML adottato (le versione 2.0). In 

fase di Progettazione architetturale vanno verificate: 

• Correttezza delle associazioni; 

• Correttezza della cardinalità delle associazioni stesse; 

• Adeguatezza delle scelte architetturali generali in base ai requisiti; 

• Completezza delle classi in rispetto dei requisiti corrispondenti; 

• Significativa scelta dei nomi delle classi. 

E in fase di Progettazione in dettaglio: 

• Completezza dei singoli componenti in base alle scelte architetturali 

generali; 

• Significativa scelta dei nomi delle componenti. 

4.3.1 Tracciamento 

Il tracciamento consiste nello stendere una tabella dove ogni singolo componente 

architetturale del progetto viene relazionato con il corrispettivo/i 

requisito/i previsto nella fase di Analisi dei Requisiti, nonché ogni requisito 

opzionale successivamente aggiunto, che é/sono stato/i da lui soddisfatto/i. 

Grazie alla tecnica del tracciamento risulta immediato avere una visione dell’adempimento 

dei requisiti stabiliti, in quanto ha il fine di mostrare il collegamento 

tra ciò che viene prodotto durante i vari processi e i requisiti descritti 

dal capitolato d’appalto. Per il ciclo di vita da noi scelto è previsto un tracciamento 

in avanti per controllare che le relazioni tra gli ingressi e le uscite di 

ogni fase siano corrette. 

È previsto anche un tracciamento in senso inverso 

per assicurare che il risultato soddisfi effettivamente le richieste iniziali. 

Le risultanze del tracciamento possono essere consultate nel documento Specifica 

Tecnica. 


4.4 Fase di Realizzazione e Prototipazione 


Le tecniche di verifica sotto descritte avranno inizio a tempo inoltrato in 

fase di Realizzazione, per avere il loro culmine nell’ultima fase, di Verifica e 

Collaudo. 

4.4.1 Analisi Statica 

Come già specificati in precedenza, l’Analisi Statica consiste in attività di 

verifica del codice effettuate senza l’esecuzione dello stesso, quindi ad un 

livello più alto ed esterno rispetto all’opposta Analisi Dinamica. 

Gli obiettivi di questo tipo di verifica sono: 

• Facilità di lettura e comprensibilità del codice; 

• Manutenibilità del codice (si deve rendere facilmente correggibile, collaudabile 

ed espandibile); 

• Riusabilità del codice; 

Le tecniche di Analisi Statica utilizzate per questo progetto sono: 

• Tutte le tecniche di verifica descritte prima di questa sezione (che ovviamente 

ricadono nella definizione data di Analisi Statica), compresi 

gli incontri con il proponente. 

• Revisioni: le periodiche revisioni del progetto con presentazione dello 

stato d’avanzamento dei lavori presso i committenti possiedono tutte 

le caratteristiche della verifica statica, per cui ricadono sotto questa 

categoria. 

• Walkthrough: consiste nella lettura critica del codice ad ampio spettro, 

senza presupposti iniziali. Si simulano diverse esecuzioni del codice 

verificandone il buon fine. Questa tecnica di verifica verrà applicata 

sulle classi più importanti, a causa della sua onerosità. 

• Inspection: contrariamente alla regola precedente, è una tecnica di lettura 

mirata, con lo scopo di individuare errori critici frequenti. Alla 

lettura viene controllato il codice tenendo conto della seguente lista di 

errori da individuare: 

– Segmentation fault sulla lettura degli array; 

– Corretto uso della clausola break del costrutto switch; 

– Corretto uso della clausola default del costrutto switch; 



– Corretto incremento o decremento delle variabili di controllo dei 

cicli; 

– Corretto uso degli operatori == e =; 

– Assenza di variabili non inizializzate; 

– Corretta visibilità delle variabili; 

– Presenza di un controllo sugli input, per escludere gli ingressi non 

attesi. 

• Scansione Automatica: il programma Y.A.S.C.A., già descritto in questo 

documento, verrà usato per eseguire scansioni approfondite del codice 

da noi steso, a diversi livelli di tolleranza. Gli errori rinvenuti 

(sintassi, istruzioni obsolete) verranno corretti immediatamente. 

4.4.2 Analisi Dinamica 

Si definisce Analisi Dinamica ogni test che venga effettuato con l’esecuzione 

vera e propria del codice scritto. Anche in questo caso, come nell’Analisi Statica, 

la verifica può essere processata manualmente o in modo automatico. 

Il tool che aiuterà in questa fase è JsUnit, che verrà descritto approfonditamente 

nella sezione Risorse Tecnologiche. 

Vi sono quattro tipologie di test in programma per questa fase: 

• Test di unità: in questa sottofase iniziale ci si concentra sui singoli 

componenti. A sua volta, vi sono due tipologie di test: funzionale e 

strutturale. Il test funzionale serve a sincerarsi della bontà dell’output 

del componente a fronte di un certo numero di diversi input scelti, 

attesi. Viceversa, nel test strutturale si punta a testare ogni percorso 

implementativo interno all’unità, verificandone l’intera logica; molto 

più costoso, verrà utilizzato a fondo con criterio e solo dove necessario. 

• Test d’integrazione: a questo livello si verifica la capacità di ogni componente 

d’integrarsi con gli accoppiati, ossia ogni altro componente 

da cui dipende. L’assemblaggio dei componenti seguirà gli schemi architetturali 

dettati nel documento Specifica Tecnica. Qui si verifica 

inoltre possibilità di riuso e di estensibilità, nonchè la manutenibilità 

dei componenti. 

• Test di sistema: a questo punto il sistema è stato completamente assemblato, 

e si giunge al livello in cui la verifica s’incentra sul soddisfacimento 

dei requisiti determinati in fase iniziale. 


4.5 Fase di Verifica e Collaudo 

• Test di accettazione: consiste nel collaudo finale, e si divide in Alpha 

Test e Beta Test. Si rimanda alla sezione Pianificazione della 

Validazione per maggiori dettagli. 

Le caratteristiche secondo le quali i test saranno identificati e indicizzati sono: 

• Scopo del test: da definirsi in modo preciso, piò essere di natura 

funzionale, prestazionale o di gestione della componente. 

• Oggetto del test: componente, componenti da integrare oppure intero 

sistema. 

• Ripetibilità del test: le prove devono essere perfettamente deterministiche. 

A uguale input deve corrispondere il medesimo output, in un 

numero qualsiasi di test. 

Gli elementi di un singolo test, che andranno poi a costituire lo scheletro del 

report dei test acclusi nelle Misurazioni di Progetto, sono i seguenti: 

• Test Case: gli estremi di una singola prova. Input, output corrispondenti 

e informazioni su ambiente e stato del sistema. 

• Test Suite: una batteria di test suite. Questi ultimi devono essere 

scelti per coprire il maggior numero di casi possibile pur mantenendo 

una fattibilità del test. 

• Test Procedure: i passi effettuati con i dati di Test Suite, automatizzati 

o meno; descritti in modo tale da garantire la ripetibilità del test. 

4.5 Fase di Verifica e Collaudo 

La fase di Verifica e Collaudo vedrà un controllo di qualità che andrà a 

continuare i test descritti sotto la fase di Relizzazione e Prototipazione. Le 

rimanenti verifiche consistono nelle metriche applicate al progetto e ai test 

di collaudo; la prima è esaurientemente spiegata nella sezione Metriche di 

Progetto, mentre la seconda nella sezione Pianificazione della Validazione, 

che descrive le ultimissime fasi del progetto. 

4.6 Verifica dei processi 

I processi cominciati ma non ancora finiti devono essere verificati secondo 

le norme descritte in questo documento. Una volta terminati vengono valutati 

per comprendere se, come e dove migliorarli. La qualità dei processi 

è garantita dalla loro organizzazione interna basata sul principio Plan, Do, 


4.6 Verifica dei processi 

Check, Act (PDCA). Qualsiasi processo può essere visto come un ciclo di 4 

momenti: 

• Plan (Pianificazione): determinare obiettivi e destinatari, determinare 

metodi per raggiungere gli obiettivi, impegnarsi nell’istruzione e nella 

formazione. 

• Do (Esecuzione): il processo viene avviato seguendo la pianificazione 

decisa al punto precedente. 

• Check (Controllo): l’esito del processo viene analizzato e valutato come 

descritto in questo documento, con le tecniche di verifica previste; in 

questo modo si comprende se il processo corrisponde ai requisiti. 

• Act (Azione): vengono applicate le azioni di correzione determinate dai 

feedback di verifica. 

Figura 1: Diagramma del paradigma Plan Do Check Act 


5 Metriche di Progetto 

In questa sezione sono presentate le metriche di progetto, ossia la definizione 

delle grandezze di misura che ci permetteranno di stimare la qualità di 

prodotti e processi. Sono divise in categorie, a seconda della natura e del 

prodotto o processo che vanno a misurare. Di seguito la descrizione delle 

metriche stesse: i risultati dei rilievi del progetto si potranno trovare nel 

documento Misurazioni di Progetto. 

5.1 Metriche Gestionali 

In questa sezione vengono descritte le metriche adottate a livello gestionale 

del progetto. Segneranno la qualità della gestione delle risorse temporali ed 

economiche. 

• BCWS (Budgeted Cost of Work Scheduled): costo previsto per il completamento 

del progetto, alla data corrente. 

• ACWP (Actual Cost of Work Performed): costo del lavoro effettivamente 

svolto sino ad ora, alla data corrente. 

• BAC (Budget At Completion): budget rimasto a disposizione per il 

completamento del progetto, alla data corrente. 

• BV (Budget Variance): indica se alla data corrente si è speso di più 

o di meno rispetto a quanto previsto nel budget alla data corrente. È 

un indicatore che ha un valore unicamente contabile e finanziario. Se 

BV è maggiore di 0 significa che il progetto sta spendendo il proprio 

budget con minor velocità di quanto pianificato, viceversa se negativo. 

BV = BCWS − ACWP. 

Le unità di misura dei costi verranno specificate nel documento Misurazioni 

di Progetto. 

Si è scelto di attenersi alle metriche gestionali più semplici da utilizzare. 

Questo perché adottare una misurazione più ampia avrebbe chiesto di stimare 

il valore di mercato del progetto ad ogni fase, stima al di fuori delle 

possibilità e dell’esperienza del team di sviluppo. 

5.2 Metriche Dimensionali 

• LOC (Lines Of Code): conteggio delle linee di codice. Questa variabile, 

delle più semplici, è di significato notoriamente variabile in funzione del- 


5.3 Metriche di Complessità 

la capacità espressiva del linguaggio/i utilizzati e comprende qualsiasi 

cosa scritta nei file sorgente. 

• CLOC (Comment Lines Of Code): conteggio delle linee di commento 

all’interno del codice. 

• CC (Comment Percentage): percentuale delle linee di commento a fronte 

delle linee totali di codice. La percentuale dovrebbe attestarsi su un 

20-30% del codice per avere sufficiente significato. 

• ELOC (Effective Lines Of Code): misura l’ammontare delle linee di 

codice effettivo. 

• ECP (Effective Code Percentage): si tratta della percentuale del codice 

effettivo rispetto al codice totale. 

5.3 Metriche di Complessità 

• CC (Cyclomatic Complexity): metrica significativa dal punto di vista 

prestazionale, è atta a misurare la complessità dei metodi, e a verificare 

che essa rimanga sotto una soglia tollerabile. È definita come il minimo 

numero di test per testare esaurientemente il metodo sotto analisi. 

Vista la natura della metrica, atta a misurare linguaggi più procedurali 

di quelli usati, ne verrà fatto un uso molto mirato. 

5.4 Metriche Chidamber-Kemerer 

Queste metriche sono state create appositamente per valutare la bontà del 

codice scritto in un linguaggio orientato agli oggetti. Sebbene il Javascript 

non offra un vero e proprio modello a oggetti ben si presta per la valutazione 

sotto queste metriche, poichè aiutano a valutare la buona progettazione 

dell’architettura del sistema. 

• WMC (Weighted Methods per Class): definita come la media delle complessità 

ciclomatiche dei metodi implementati per classe, permette di 

definire la difficoltà di manutenzione di una classe, che è proporzionale 

alla complessità dei vari metodi. Inoltre, benchè la completezza e 

la buona struttura delle classi dipenda da un elevato numero di metodi, 

bisogna ricordare che in questo modo viene anche abbassata la 

versatilità della classe in vista di un riuso. 

• CBO (Coupling Between Objects): questa metrica si occupa delle dipendenze 

tra le varie classi, ed è definita come il numero di classi dello 


5.4 Metriche Chidamber-Kemerer 

stesso package con le quali la classe in esame è accoppiata, ossia dalle 

quali dipende. La crescita incontrollata delle dipendenze tra classi 

ostacola fortemente riuso ed estensibilità del codice. 


6 Pianificazione della validazione 

6.1 Specifica della campagna di validazione 

La validazione del prodotto finale è un’attività fondamentale per gli sviluppatori 

in quanto si prova che il software rispecchi i requisiti e li esegua nel 

modo voluto. Uno degli obiettivi di questo test è controllare l’effettivo funzionamento 

del prodotto finale ed eventualmente segnalare la presenza di errori 

(quali bug o quant’altro) che nel caso verranno corretti secondo le procedure 

adottate. In mancanza di riscontro di errori, si certifica l’effettivo funzionamento 

del prodotto. 

La campagna di validazione si svolgerà in due fasi: 

• Alpha test: test eseguito internamente all’azienda; si provvede ad eseguire 

l’applicativo per controllare che rispetti le specifiche richieste. 

Sarà guidato dai diagrammi di casi d’uso, e avrà anche come obiettivo 

l’ultimissima verifica di aderenza ai requisiti dell’intero progetto. 

• Beta test: il prodotto viene distribuito al committente e ad una ristretta 

cerchia di tester esterni all’azienda per verificare in maniera più 

ampia e diversificata il rispetto dei requisiti e l’integrità strutturale. Ai 

betatester viene fornito il Manuale Utente e il sistema di ticketing per 

eseguire il report dei problemi riscontrati.

Piano Di Qualifica - Find and develop open source software

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?