Download Verifica e validazione per garantire l'affidabilità del software PDF

TitleVerifica e validazione per garantire l'affidabilità del software
LanguageEnglish
File Size2.4 MB
Total Pages56
Table of Contents
                            Colophon
1 Contesto aziendale
	1.1 L'azienda
	1.2 Organizzazione interna
		1.2.1 Gestione della qualità
	1.3 Processi aziendali
		1.3.1 Metodologie di sviluppo software
		1.3.2 Strumenti a supporto dei processi
	1.4 L'azienda e l'innovazione tecnologica
2 Lo stage
	2.1 Aspettative personali
	2.2 Scopo del progetto
		2.2.1 CMMI-DEV 1.3
	2.3 Obiettivi di progetto
	2.4 Vincoli
		2.4.1 Vincoli metodologici
		2.4.2 Vincoli temporali
		2.4.3 Vincoli tecnologici
3 Il progetto
	3.1 Introduzione
	3.2 Stile di codifica
		3.2.1 Principi base
		3.2.2 Automazione di controlli
		3.2.3 Strumenti utilizzati
	3.3 Analisi statica
		3.3.1 Principi base
		3.3.2 Tecniche di analisi
		3.3.3 Automazione di controlli
		3.3.4 Strumenti utilizzati
	3.4 Analisi dinamica
		3.4.1 Principi base
		3.4.2 Tecniche di test
		3.4.3 Attività di test
		3.4.4 Strumenti utilizzati
	3.5 Metriche di qualità
		3.5.1 Principi base
		3.5.2 Metriche implementate
	3.6 Integrazione delle automazioni
	3.7 Conclusioni
4 Valutazione retrospettiva
	4.1 Bilancio sugli obiettivi
	4.2 Bilancio formativo
	4.3 Analisi gap formativo
                        
Document Text Contents
Page 1

Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"

Corso di Laurea in Informatica

Verifica e validazione per garantire
l’affidabilità del software

Tesi di laurea triennale

Relatore
Prof. Tullio Vardanega

Laureando
Fabio Massignan

Anno Accademico 2017-2018

Page 2

Fabio Massignan: Verifica e validazione per garantire l’affidabilità del software, Tesi
di laurea triennale, c
Apr 2018

Page 28

Capitolo 3

Il progetto

3.1 Introduzione

Gli obiettivi pianificati per questo progetto miravano al raggiungimento di un
elevato grado qualitativo del software prodotto dall’azienda. Per perseguire tali
obiettivi è stato necessario mettere assieme una serie di tecnologie affidabili, in
grado di analizzare ciò che viene prodotto, fornendo degli indicatori qualitativi
quantificabili e ben dettagliati.

La necessità di perseguire una buona qualità dei prodotti software, nasce dalla
richiesta di alcuni clienti di avere dei prodotti conformi rispetto al modello CMMI-
DEV.

L’utilizzo delle tecniche che garantiscono la conformità a tale modello, però,
è avvenuta in un secondo momento rispetto allo sviluppo iniziale del software
per i sistemi Subsea. L’azienda non aveva una grande esperienza sul piano della
progettazione e dello sviluppo di un software di qualità, ha quindi prodotto una
grossa quantità di codice incontrollato e difficile da manutenere.

Come prima cosa, in continuazione con quanto è stato fatto nello stageprece-
dente, mi sono occupato di definire uno standard interno alla Divisione, contenente
serie di regole stilistiche per la stesura del codice. Queste regole servono a limitare
l’eccessiva libertà con la quale gli sviluppatori producevano il software. Abituati a
lavorare in un ambiente disorganizzato, producevano infatti del codice disordinato,
poco mantenibile e senza alcuna documentazione. L’applicazione di queste regole,
attraverso degli strumenti che segnalano direttamente le non conformità, se da una
parte portano ad uno sforzo maggiore richiesto agli sviluppatori, dall’altra garanti-
scono un codice più ordinato e leggibile. Un codice ben scritto è un prerequisito
fondamentale per le successive attività di analisi.

Una volta assicurata una certa qualità sulla scrittura del codice, ho potuto
studiare ed analizzare le varie tecnologie da applicare per l’attuazione delle me-
todologie di analisi statica e dinamica. Pietro Fiorentini S.p.A , in un’ottica di
miglioramento continuo (uno dei pilastri fondamentali sul quale è basata l’azienda),
ha visto nelle tecniche di analisi statica e dinamica una possibile area di sviluppo e
miglioramento grazie al possibile risparmio di tempo e risorse che si può raggiungere
tramite un’applicazione corretta delle tecniche di analisi. Mi sono dunque occupato
di studiare quali metodologie fossero le più utili ed interessanti per raggiungere

19

Page 29

20 CAPITOLO 3. IL PROGETTO

gli obiettivi posti da queste tecniche, ho poi realizzato una struttura di base in
grado di elaborare i dati forniti dall’applicazione delle varie metodologie e, infine,
ho iniziato l’applicazione di queste tecniche di analisi sul prodotto software.

Una volta definite ed implementate le attività di analisi, avendo quindi generato
una base dati iniziale con i risultati delle varie applicazioni di questi metodi, ho
potuto rendere quantificabili i risultati ottenuti. Ho perciò scelto ed applicato delle
metriche di misurazione di qualità del prodotto software. Grazie a queste metriche
è possibile capire immediatamente quanto il prodotto stia migliorando rispetto
alle versioni precedenti nelle quali non era stato previsto alcun tipo di controllo.
Con queste misurazioni è possibile anche dimostrare al cliente finale che il software
prodotto è sempre controllato, fornendo un risultato tangibile di qualità.

Il progetto di stage è articolato dunque in quattro fasi principali: analisi dello
stile di codifica, analisi statica del codice, analisi dinamica e misurazione delle
metriche di qualità.

Per ognuna di queste fasi, in linea con il modello di ciclo di vita del software
adottato dall’azienda, sono state pianificate delle attività principali da eseguire.
Dopo una prima analisi preliminare delle richieste del progetto, dell’architettura
esistente, e di quanto era già stato prodotto dagli stage precedenti, sono passato ad
analizzare e a pianificare in dettaglio l’utilizzo dei vari strumenti, per poter garantire
una soluzione ottimale alle varie richieste. A seguito di questa pianificazione, basata
anche sull’utilizzo di best-practice esistenti, ho continuato con la realizzazione e
l’integrazione degli strumenti con i sistemi di gestione di processi già utilizzati
dall’azienda.

In questo capitolo verranno esplicitate nel dettaglio tutte le fasi del progetto e
gli aspetti fin qui accennati. Per ogni fase saranno specificate le motivazioni delle
scelte effettuate, i principi base che hanno supportato l’applicazione degli strumenti,
le regole, i controlli effettivamente implementati e come questi strumenti sono stati
eseguiti ed integrati nel sistema esistente.

3.2 Stile di codi�ca
Uno stile di codifica unificato tra tutti i programmatori è un prerequisito fonda-
mentale per molte ragioni: la prima riguarda il fatto che, in tutto il ciclo di vita di
un prodotto software, la maggior parte del tempo viene dedicata alla manutenzione.
Solitamente questa attività viene affidata a una persona diversa dallo sviluppatore
che ha scritto quel particolare pezzo di codice, e avere uno stile di scrittura uniforme
e aderente anche ad alcuni standard, facilita molto questa fase.

Condividere uno standard comune di codifica comporta anche molti altri benefici:
aumenta la condivisione e la comunicazione tra i diversi sviluppatori, dà la possibilità
agli altri membri del reparto Ricerca e Sviluppo con competenze informatiche di
visionare ed eventualmente modificare il codice prodotto, evita molti errori banali
aumentando così sia la qualità generale del codice che il lavoro di squadra.

Avere un numero fissato di regole e convenzioni, poi, aiuta molto le attività
di verifica e validazione infatti, avere un codice scritto sempre nello stesso modo
e che quindi sia standardizzato permette di facilitare e velocizzare la stesura e
l’automazione delle procedure di test.

Page 55

46 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

S
Sistemi embedded: tutti quei sistemi elettronici di elaborazione digitale a micro-
processore progettati appositamente per una determinata applicazione ovvero non
riprogrammabili dall’utente per altri scopi, spesso con una piattaforma hardware
ad hoc, integrati nel sistema che controllano ed in grado di gestirne tutte o parte
delle funzionalità richieste.

Page 56

Bibliografia

CMMI model https://it.wikipedia.org/wiki/Capability_Maturity_Model

DRY principle https://it.wikipedia.org/wiki/Don%27t_Repeat_Yourself

Guide to the Software Engineering Body of Knowledge (SWEBOK
V3) P. Bourque and R.E. Fairley, eds., IEEE Computer Society, 2014

ISO/IEC 9126

KISS principle https://en.wikipedia.org/wiki/KISS_principle

Manuale della qualità Pietro Fiorentini, Manuale della Qualità, QM03 Rev.03

MISRA C https://www.iar.com/about-us/newsroom/press/?releaseId=
1823165

Pietro Fiorentini, Chi siamo: https://www.fiorentini.com/it/it/chi_
siamo

Principi Lean Thinking: https://www.leanthinking.it/cosa-e-il-lean-thinking/
principi/

Seven principles of software testing Bernard Meyer

SOLID principle https://en.wikipedia.org/wiki/SOLID_(object-oriented_
design)

Static Analysus for Software Verification Leon Moonen, University of Oslo
http://www.uio.no/studier/emner/matnat/ifi/INF4290/v10/undervisningsmateriale/
INF4290-StaticAnalysis.pdf

The power of Ten Gerard J. Holzmann, 2006

47

https://it.wikipedia.org/wiki/Capability_Maturity_Model
https://it.wikipedia.org/wiki/Don%27t_Repeat_Yourself
https://en.wikipedia.org/wiki/KISS_principle
https://www.iar.com/about-us/newsroom/press/?releaseId=1823165
https://www.iar.com/about-us/newsroom/press/?releaseId=1823165
https://www.fiorentini.com/it/it/chi_siamo
https://www.fiorentini.com/it/it/chi_siamo
https://www.leanthinking.it/cosa-e-il-lean-thinking/principi/
https://www.leanthinking.it/cosa-e-il-lean-thinking/principi/

Similer Documents